요즘 카카오를 비롯한 빅테크들이 '에이전틱 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와 사람의 경계는 어디인가? 댓글로 같이 이야기 나누고 싶다.
Top comments (0)