목요일 밤 11시, 테스트 통과 여부만 확인하고 PR을 승인하던 경험이 있는가. 솔직히 말하면 나도 있다. 코드 리뷰가 의례적인 절차로 전락하는 순간, 팀의 품질 방어선은 사실상 무너진다. 그리고 그 문제를 'AI한테 다 맡기면 되지 않냐'는 단순한 발상으로 접근하면 금방 또 다른 벽에 부딪힌다. 하나의 커다란 프롬프트에 '스타일, 로직, 보안을 한꺼번에 봐줘'라고 던지면 200줄을 넘는 diff부터 출력이 흐릿해진다. '에러 핸들링을 고려하세요', '변수명을 더 명확하게'—매번 똑같은 다섯 줄. 이건 AI의 한계가 아니라 설계의 한계다.
단일 에이전트의 함정: 나쁜 관리자처럼 AI를 쓰고 있었다
dev.to에 공개된 멀티에이전트 코드 리뷰 파이프라인 구축 사례는 이 문제를 예리하게 짚는다. 저자의 통찰은 단순하지만 강력하다—"나는 AI에게 나쁜 관리자가 저지르는 실수를 반복하고 있었다. 한 사람에게 스타일, 로직, 보안을 동시에 맡기는 것." 역할 분리가 해법이다. 스타일 체커(Claude Haiku), 로직 리뷰어(Claude Sonnet), 보안 스캐너(Claude Sonnet) 세 에이전트를 GitHub Actions 위에서 Promise.all()로 병렬 실행하고, 오케스트레이터가 결과를 중복 제거·포맷팅해 PR 코멘트 하나로 정리한다. 비용도 리뷰 1회당 총 $0.07 수준으로 현실적이다. 스타일 체커에 Haiku를 쓰는 이유는 명확하다—깊은 추론이 필요 없는 패턴 매칭에 Sonnet 비용을 낭비할 이유가 없다. 반면 로직 리뷰어는 diff만이 아니라 수정된 파일 전체를 컨텍스트로 받아 WebSocket 핸들러의 레이스 컨디션 같은 것까지 잡아낸다. 역할에 맞는 모델을, 역할에 맞는 컨텍스트와 함께.
설계 단계에서도 같은 원리가 작동한다
코드 리뷰의 역할 분리 논리는 아키텍처 설계 단계에도 그대로 적용된다. 아키텍처 결정이 비싼 이유는 코드로 쓰이지 않기 때문이다. 슬랙 스레드, 화이트보드 사진, 그 자리에 있던 사람의 기억 속에만 남는다. 잘못됐을 때 스택 트레이스가 나오지 않는다. 6개월 후 '왜 이게 이렇게 바꾸기 어렵지?'라는 질문만 남는다. dev.to의 아키텍처 결정 프롬프트 가이드는 AI가 이 피드백 루프를 '몇 주'에서 '몇 분'으로 압축할 수 있다고 주장한다—그리고 이건 과장이 아니다. 단, 조건이 있다. 컨텍스트를 제대로 구성했을 때만.
핵심은 Claude의 컨텍스트 윈도우를 예산처럼 쓰는 것이다. 시스템 개요, 기술 스택, 결정을 강제하는 제약 조건은 필수다. 팀 규모와 시니어리티, 스케일 수치(RPS, 데이터 볼륨)는 관련될 때 포함한다. 결정과 무관한 컴포넌트의 구현 세부사항, 6개월 이상 된 히스토리, 소스 코드는 과감히 잘라낸다. '요구사항을 시스템 컴포넌트로 분해해줘'라는 프롬프트는 각 컴포넌트의 단일 책임, 입출력, 그리고 모호한 부분을 함께 뽑아내게 설계한다. 모호성 플래그가 붙은 항목은 기술 설계 문서가 아니라 제품팀에 가져갈 질문 목록이 된다. 트레이드오프 비교 프롬프트는 구현 복잡도, 운영 복잡도, 확장성 상한선, 출시 속도, 팀 역량 적합도, 데이터 일관성 보장, 마이그레이션 가역성까지 차원을 명시한다. 그래야 '직관'이 아니라 '표면화된 트레이드오프'로 결정할 수 있다.
컨텍스트 드리프트를 막는 서브에이전트 병렬 관점
설계 논의를 메인 에이전트와 오래 이어가다 보면 또 다른 문제가 생긴다. 에이전트가 대화의 프레이밍에 갇히거나, 슬슬 동조하기 시작한다. 새로운 각도가 사라지는 것이다. Claude Code 서브에이전트 병렬 관점 활용 사례는 이 문제를 흥미롭게 해결한다. 서브에이전트는 메인 에이전트의 대화 컨텍스트를 공유하지 않는다. 콜드 스타트다. 바로 그 점이 가치다.
패턴은 이렇다. 현재 논의를 파일로 저장한 뒤, 세 개의 서브에이전트를 다른 관점으로 스폰한다—LLM 관점("이게 모델이 파싱하기 쉬운가?"), 소프트웨어 아키텍트 관점("1년 후에도 이 설계가 버텨낼까?"), 엔드유저 관점("5분 안에 이해할 수 있는가?"). 각 결과를 별도 파일로 저장하고 메인 에이전트가 이를 새 입력으로 받아 논의를 재개한다. 수렴하면 문서를 업데이트하고, 미해결 이슈가 남으면 라운드를 반복한다. 부수 효과도 크다. 라운드별 파일이 쌓이면서 "왜 이걸 이렇게 결정했지?"에 대한 답이 문서로 자동 누적된다. 의사결정 트레일이 생기는 것이다.
실제로 이 패턴이 효과를 발휘한 사례를 보면 설득력이 높다. OVERVIEW.md 자동 로딩 여부를 논의하던 중, LLM 관점 서브에이전트는 "모델은 헬프풀니스 훈련 때문에 더 많은 컨텍스트를 읽는 쪽으로 체계적으로 편향돼 있다"고 진단했다. 아키텍트 관점은 실행 편향이 아니라 문서 구조 자체의 역할 충돌을 지적했다. 엔드유저 관점은 실제 사용 빈도를 기준으로 자동화 자체를 기각했다. 세 관점 모두 소프트 룰을 버렸고, 결론은 명확해졌다. 한 에이전트가 대화 맥락에 갇혀있었다면 나오지 못했을 결론이다.
세 패턴이 가리키는 하나의 원리
멀티에이전트 코드 리뷰, 아키텍처 결정 프롬프트, 서브에이전트 병렬 관점—세 사례는 서로 다른 단계의 이야기처럼 보이지만 하나의 원리로 수렴한다. AI에게 역할을 분리해서 줘야 한다. 하나의 에이전트에 모든 것을 던지면 컨텍스트가 희석되고, 출력이 일반화되고, 대화가 길어질수록 편향이 누적된다. 역할이 좁을수록 판단이 날카로워진다.
이걸 팀 워크플로우에 적용할 때 현실적인 진입점은 단계적 도입이다. 코드 리뷰 자동화부터 시작하는 게 ROI가 가장 빠르다. GitHub Actions 위에 Claude API를 연결하는 스크립트는 하루면 붙일 수 있고, 즉각적인 가시적 효과가 있다. 설계 단계 프롬프트 템플릿은 팀 위키에 공유 자산으로 올려두면 표준화가 쉽다. 서브에이전트 병렬 관점 패턴은 설계 결정이 막혔을 때 꺼내 쓰는 도구로 시작하면 된다.
팀에서 진짜 물어봐야 할 질문
도구 도입보다 중요한 건 팀이 이 패턴을 받아들이는 방식이다. '멀티에이전트 리뷰가 내 코드를 틀렸다고 하면 누가 최종 판단하는가?'—이 질문에 답이 없으면 파이프라인은 노이즈 소스가 된다. 에이전트의 판단에 이의를 제기하고, 프롬프트를 조정하고, 결과를 해석하는 역할이 팀 내에 명확히 있어야 한다. AI가 생성한 코드 리뷰 코멘트를 검증 없이 수용하는 팀과, 에이전트 출력을 출발점으로 삼아 인간 판단을 더하는 팀 사이의 품질 격차는 시간이 갈수록 벌어진다.
전망: 오케스트레이션이 핵심 역량이 된다
AI 에이전트 개수가 늘어날수록 오케스트레이션 능력이 팀의 핵심 역량이 된다. 단일 에이전트를 잘 프롬프팅하는 것은 개인 생산성의 문제다. 역할 분리된 에이전트 네트워크를 설계하고 운영하는 것은 팀 인프라의 문제다. 설계 단계의 의사결정 문서화, 코드 리뷰의 자동화된 1차 방어선, 그리고 컨텍스트 드리프트를 막는 병렬 관점—이 세 축을 연결하면 AI는 개발자 옆에 앉은 동료가 아니라 팀 워크플로우에 내장된 인프라가 된다. 그게 AI-First 팀 리빌딩의 실질적인 목적지다.