도구 숙련도가 곧 워크플로우 경쟁력이다
Claude Code를 '그냥 쓰는' 팀과 '설계해서 쓰는' 팀의 격차는 생각보다 빠르게 벌어지고 있다. Claude Code 제작자 Boris Cherny가 공개한 15가지 고급 기능 목록(via GeekNews)을 보면, 대부분의 팀이 전체 기능의 20%도 활용하지 못하고 있다는 걸 금방 알 수 있다. /loop, /batch, 세션 포크, git worktree 병렬 처리—이것들은 단순한 편의 기능이 아니다. 워크플로우 자체를 재설계할 수 있는 레버다.
핵심 기능 3개만 제대로 써도 팀 구조가 달라진다
실무에서 즉시 임팩트가 큰 기능을 추리면 세 가지다.
첫째, /loop와 /schedule. 최대 1주일 단위 자동 반복 실행이 가능하다. PR 관리, 코드 리뷰 자동 처리, 오래된 PR 정리까지—반복성 높은 DevOps 작업을 사람이 아니라 에이전트가 돌리게 된다. /loop 5m /babysit으로 코드 리뷰와 리베이스를 자동화하거나, /loop 1h /pr-pruner로 방치된 PR을 정리하는 식이다. 팀에서 '누군가는 해야 하는데 아무도 안 하는' 작업들이 여기에 해당한다.
둘째, /batch. 수십에서 수천 개의 워크트리 에이전트를 병렬로 팬아웃시킨다. 대규모 코드 마이그레이션이 대표 케이스다. 레거시 API 교체, 의존성 일괄 업데이트, 스타일 가이드 적용 같은 작업을 직렬로 처리하면 며칠이 걸릴 일이 병렬로는 시간 단위로 끝난다. 단, /batch는 작업 범위를 인터뷰 방식으로 파악한 후 분산하기 때문에, 태스크 경계가 명확하게 분리되는 작업에 써야 한다. 의존성이 얽힌 작업에 무작정 쓰면 충돌 지옥을 만날 수 있다.
셋째, Hooks. PreToolUse로 모든 bash 명령을 로그 기록하고, PermissionRequest로 민감한 권한 요청을 WhatsApp으로 라우팅해 직접 승인하는 방식은 에이전트 거버넌스의 기초 레이어다. 에이전트가 자율적으로 실행되는 만큼, 결정론적 제어 포인트를 라이프사이클 단계마다 삽입하는 게 필수다.
DGE: AI 리뷰어를 자가 논쟁시키면 뭐가 달라지나
dev.to에 공개된 DGE(Dialogue-driven Gap Extraction) 패턴은 기존 AI 코드 리뷰의 맹점을 정확히 찌른다. 일반 AI 리뷰는 '뭐가 없는지'를 체크리스트 방식으로 찾는다. CSRF 보호 없음, HTTPS 미적용, MFA 누락—유효하지만 어떤 auth 가이드에서도 볼 수 있는 지적이다.
DGE는 다르다. Columbo, Socrates, Picard 같은 캐릭터들이 설계 결정 자체를 논쟁한다. "JWT를 왜 썼나? 서버가 하나면 세션으로도 충분한데"—이런 질문은 일반 AI 리뷰가 절대 하지 않는다. 주어진 전제를 수용하고 그 위에서 개선점을 찾는 것과, 전제 자체를 의심하는 것은 근본적으로 다른 검토 방식이다.
실험 결과도 흥미롭다. 동일한 auth API 스펙에 DGE와 일반 AI를 동시에 돌렸을 때, 일반 AI가 찾은 갭이 28개로 DGE의 9개보다 3배 많았다. 하지만 DGE만 발견한 3개—JWT 선택 근거 부재, 토큰 만료 정책과 앱 유형 불일치, OAuth 추가 시 스키마 파괴—는 단순 누락이 아니라 설계 판단의 오류였다. 더 중요한 발견은 '격리 실험'에서 나왔다. DGE와 같은 컨텍스트에서 실행한 일반 AI는 15개 갭만 찾았지만, 격리된 서브프로세스에서 실행하자 28개로 늘었다. AI가 무의식적으로 DGE의 결과를 회피했다는 뜻이다. 리뷰 도구들을 격리해서 병렬 실행하는 것 자체가 품질 관리 전략이 된다.
실제 프로젝트에서 DGE가 발견한 취약점은 더 날카롭다. Path Traversal + API 노출, RW 마운트 + 자동 승인 조합으로 인한 파일 파괴, 메타데이터 레이스 컨디션 + 자동 승인 오작동—이 세 가지는 각각 단독으로는 알려진 취약점이지만, DGE 캐릭터들이 서로의 발견을 연결해 '공격 체인'으로 조합했다. 단순 목록 나열이 아니라 시나리오 기반 위협 모델링에 가깝다.
4-에이전트 아키텍처: 오케스트레이터가 없으면 그냥 프롬프트 체인이다
dev.to에서 공개된 4-에이전트 시스템 아키텍처는 멀티 에이전트 설계의 핵심 원칙을 실증한다. Claude Code(백엔드/인프라), GPT 기반 에이전트(코드 리뷰/대량 생성), Gemini 기반 에이전트(프론트엔드/디자인), 로컬 LLM(오프라인/프라이빗 작업)—각 에이전트는 자신의 도메인 밖에 개입하지 않는다.
핵심은 오케스트레이터다. 오케스트레이터는 AI가 아니라 결정론적 상태 머신이다. 무엇을 다음에 실행할지, 어떤 제약 조건 안에서 실행할지, 언제 완료로 판정할지—이 세 가지를 소프트웨어가 통제한다. 에이전트가 알아서 다음 작업을 결정하게 두면 어느 순간 시스템 전체가 예측 불가능해진다. 이건 'AI를 믿어야 한다'의 문제가 아니라, 현재 LLM의 구조적 한계다.
공유 상태 메모리도 중요하다. 에이전트 A가 만든 결과물을 에이전트 B가 컨텍스트 없이 이어받으면 불일치가 생긴다. 모든 에이전트가 동일한 상태 파일을 읽고 쓰는 구조는 세션 간 컨텍스트 손실을 막는 가장 단순한 해결책이다. 그리고 각 파이프라인 단계마다 검증 게이트—자동 테스트, 린팅, 독립 리뷰 에이전트—를 삽입해 나쁜 출력이 다음 단계로 전파되지 않도록 차단한다.
이 아키텍처로 1주일 안에 5개 프로덕션 웹앱, 58개 AI 제너레이터, 100개 3D 오브젝트를 1인이 출시했다는 결과는—과장을 감안하더라도—멀티 에이전트 오케스트레이션의 실질적 레버리지를 보여준다.
팀에 적용할 때 현실적으로 따질 것들
세 사례를 종합하면 AI-First 워크플로우 재설계의 실행 순서가 보인다.
1단계: Claude Code 기능 감사. 팀이 현재 어떤 기능을 쓰고 어떤 기능을 모르는지 목록화한다. /loop, /batch, Hooks 세 가지만 제대로 도입해도 반복성 DevOps 작업의 상당 부분을 에이전트로 전환할 수 있다.
2단계: 리뷰 파이프라인에 DGE 삽입. 스펙 리뷰나 아키텍처 결정 단계에서 DGE를 한 사이클 돌리는 것만으로 설계 단계의 블라인드 스팟을 줄일 수 있다. 설치는 npm install @unlaxer/dge-toolkit && npx dge-install 한 줄이다. 진입 장벽이 낮다.
3단계: 오케스트레이터 설계. 에이전트를 추가하기 전에 제어 레이어를 먼저 설계한다. 에이전트 역할 분리, 공유 상태 구조, 검증 게이트 위치—이 세 가지가 없는 멀티 에이전트 시스템은 그냥 비싼 프롬프트 체인이다.
학습 곡선에 대해 솔직하게 말하면: /batch와 오케스트레이터 설계는 팀원 대부분에게 2~4주의 실험 기간이 필요하다. DGE는 설치 후 바로 쓸 수 있지만, 캐릭터와 대화 패턴을 조합하는 데 익숙해지는 데 1~2주는 잡아야 한다. 단, 이 투자는 한 번으로 끝난다. 패턴을 익힌 팀원은 이후 워크플로우 설계 역량이 영구적으로 올라간다.
전망: 도구 사용자에서 워크플로우 설계자로
Claude Code의 고급 기능들, DGE의 구조화된 논쟁 패턴, 4-에이전트 오케스트레이터 아키텍처—이 세 가지가 가리키는 방향은 같다. AI 도구를 '잘 쓰는' 수준에서, AI 에이전트들이 실제로 일하는 파이프라인을 '설계하는' 수준으로의 전환이다.
앞으로 팀에서 가장 희소한 역량은 코딩 실력이 아니라, 에이전트 역할을 분리하고 제어 레이어를 설계하며 검증 게이트를 적재적소에 배치하는 능력이 될 것이다. 이건 새로운 기술이 아니다. 시스템 설계의 사고방식을 AI 에이전트 레이어로 확장하는 것이다. 테크 리드가 AI 시대에 여전히 필요한 이유가 바로 여기 있다.