DEV Community: Seonho Kim

AI를 '일잘러 동료'로 두기 - 기획부터 코드 검증까지, 내가 SDLC를 자동화한 방식

Seonho Kim — Thu, 18 Jun 2026 08:26:44 +0000

요즘 카카오를 비롯한 빅테크들이 '에이전틱 AI'를 화두로 던진다. AI가 스스로 판단하고 도구를 호출해 일을 끝낸다는 그림이다. 멋지지만, 현장에서 일하는 개발자로서 솔직한 의문이 들었다. 대부분의 기업은 AI-Native가 아니라 AX(AI Transformation)를 한다. 처음부터 AI로 설계된 조직이 아니라, 기존 업무 위에 AI를 얹는 쪽이다. 그렇다면 답은 'AI에게 운전대를 넘기는 것'이 아니라 따로 있지 않을까.

내 입장: AI-Native 말고 AI-Optional

나는 AI를 협업자이자 지식창고이자 일잘러 동료로 뒀다. 전부 맡기지 않는다. 판단과 책임은 사람이 쥐고, 반복·검색·정합성 검증처럼 AI가 압도적으로 잘하는 구간만 위임한다. 이 'AI-Optional' 방식으로 내 SDLC 생산성은 체감상 95% 이상 올라갔다.

무대: 통합물류 포트폴리오

검증 무대는 OMS·WMS·TMS를 묶은 이벤트 드리븐 통합물류 시스템이다. 다만 이 글의 주인공은 물류 도메인이 아니라 그걸 만든 방법론이다.

파이프라인 종단: 어디까지 AI, 어디서 사람

기획 → DDD 용어집 → 화면설계 → 아키텍처 → 화면 개발 → 패턴·코딩·스타일 검증. 이 흐름을 한 줄로 꿰었다.

AI가 맡은 것: 용어집과 화면설계의 연결 추적, 코드가 컨벤션·아키 규칙을 어겼는지 검증, 반복 코드 생성.
사람이 결정한 것: 도메인 경계(Bounded Context), 트랜잭션 정책, "이 화면이 정말 이 업무를 푸는가"라는 본질.

경계는 단순하다. 틀리면 비싼 결정은 사람이, 빠르면 이득인 반복은 AI가.

도구의 역할

RAG = 지식창고. 설계서·용어집·표준을 물으면 근거째 답한다.
n8n = 자동화. 검증·동기화 같은 일을 사람 손 없이 흘려보낸다.
Claude Code = 일관성 검증자. 용어집부터 코드 패턴까지 끝단의 정합성을 본다.

이벤트 드리븐과 three.js로 물류 가시성(visibility)을 확보한 이야기는 다음 글에서 따로 풀겠다.

회고: '95%'의 진짜 의미

95%는 'AI가 95%를 짰다'가 아니다. 결정에 쓸 시간을 그만큼 더 확보했다는 뜻이다. 잘 통한 건 정합성 검증과 지식 검색이었고, 끝내 사람이 쥐어야 했던 건 도메인 판단과 책임이었다.

에이전틱 AI에게 운전대를 줄지 고민 중이라면, 먼저 '옆자리 동료'로 앉혀보길 권한다. 당신의 파이프라인에서 AI와 사람의 경계는 어디인가? 댓글로 같이 이야기 나누고 싶다.

2026-06-09-welcome-ai-optional

Seonho Kim — Tue, 09 Jun 2026 04:45:25 +0000

AI 없이도 AI 수준 결과물

기업이 AI 개발 도입을 망설이는 진짜 이유는 "AI가 일을 못 해서"가 아니다.
AI가 한 일을, AI 없이는 아무도 검증·재현하지 못해서다.

핵심 한 줄

AI가 있으면 30초, 없으면 15분. 그러나 결과물은 100% 동일하다.

비결은 단순하다. AI에게 시키는 모든 것을 먼저 문서·체크리스트로 만든다.
AI는 그 문서를 자동 실행할 뿐이고, AI가 없으면 사람이 같은 문서를 손으로 따른다.

왜 중요한가

복원력: API 할당량이 끊겨도 표준이 무너지지 않는다.
신뢰: "AI가 왜 그렇게 검증했나"를 문서로 그대로 설명할 수 있다.
온보딩: 신입은 문서로 배우고, 경력자는 AI로 가속한다. 기준은 같다.

이 글은 8-C 콘텐츠 자동화 파이프라인으로 게시되는 첫 글입니다. 주제 수집부터
대본 작성, 멀티채널 게시까지 — AI가 엔진이 되고, 사람이 핸들을 잡습니다.

한 번 쓰고 여러 곳에 — 직접 만든 콘텐츠 배포 파이프라인(POSSE)

Seonho Kim — Tue, 09 Jun 2026 04:13:37 +0000

블로그를 운영하다 보면 늘 같은 고민에 부딪힌다. "내 사이트에 쓸까, 아니면 사람이 많은 플랫폼에 쓸까?"

내 사이트에 쓰면 자산은 쌓이지만 초기 트래픽이 없다.
외부 플랫폼(Dev.to, Velog)에 쓰면 도달은 좋지만 내 것이 아니다.

둘 다 갖고 싶었다. 그래서 POSSE 패턴으로 파이프라인을 직접 만들었다.

POSSE — Publish on Own Site, Syndicate Elsewhere

원칙은 단순하다.

원본(canonical)은 내 사이트에. 외부에는 복제하되 원문 링크를 박는다.

핵심은 rel="canonical"이다. 복제본이 원문을 가리키면 검색엔진은 중복으로 처벌하지 않고
원본에 점수를 몰아준다. 즉 내 사이트는 자산으로 쌓이고, 외부는 유입을 끌어온다.

파이프라인 구조

전체 흐름은 4단계다.

수집: Hacker News·RSS에서 IT/AI 주제를 모은다 (키 불필요)
선별: 키워드·인기도로 점수화해 상위 주제를 고른다
작성: 대본/본문을 생성한다
배포: 내 블로그(원본) → Dev.to(API 자동) → Velog(붙여넣기 초안)

복제 단계는 이렇게 생겼다.

// 내 블로그가 원본임을 명시하며 Dev.to에 복제
await fetch("https://dev.to/api/articles", {
  method: "POST",
  headers: { "api-key": KEY, "content-type": "application/json" },
  body: JSON.stringify({
    article: {
      title,
      body_markdown: body,
      published: true,
      canonical_url: "https://comfunny.com/blog/" + slug, // ← 핵심
    },
  }),
});

설계에서 가장 중요했던 결정

"AI가 없어도 동작해야 한다."

생성 단계는 AI가 있으면 AI가, 없으면 템플릿이나 사람이 채운다. 어느 쪽이든
파이프라인의 나머지(수집·배포·상태기록)는 똑같이 굴러간다. 도구가 빠져도
시스템이 멈추지 않게 만드는 것 — 이게 자동화를 오래 끌고 가는 비결이라고 믿는다.

또 하나, 영상 채널은 솔직하게 분리했다. 텍스트 대본만으로 유튜브·릴스를
올릴 수는 없다(영상 파일이 필요하다). 그래서 블로그는 완전 자동, 영상은
별도 렌더 큐로 위임했다. 할 수 없는 걸 할 수 있는 척하지 않는 게 설계의 정직함이다.

결과

이제 글 하나를 쓰면:

내 블로그에 원본이 남고(자산)
Dev.to에 자동 복제되어 글로벌 개발자에게 닿고(도달)
Velog용 초안까지 손에 들어온다

그리고 각 글이 어느 채널에 나갔는지는 관리자 대시보드에서 한눈에 본다.

마치며

"많이 쓰는 것"보다 "한 번 잘 써서 여러 곳에 닿게 하는 것"이 오래 간다.
도구는 거들 뿐, 자산은 내 도메인에 쌓인다.

이 글은 그 파이프라인이 직접 배포했습니다.