AI 에이전트끼리 토론한다면? 멀티 에이전트 협업으로 재설계하는 개발 프로세스 (새 탭에서 열림)

AI 코딩의 병목은 코드 생성 속도가 아니라 의도 정의, 가정 검증, 구현 확인, 리뷰 준비를 사람이 직접 조율하는 데 있다. LY Corporation은 이를 해결하기 위해 제안자와 도전자 AI 팀이 스펙·빌드·전달의 세 단계에서 토론하고, 조율자가 수정·상위 보고·진행 여부를 결정하는 파이프라인을 설계했다. 목표는 사람의 판단을 없애는 것이 아니라, 사람이 검토하기 전에 AI가 자신의 작업을 근거와 함께 입증하도록 만드는 것이다.

사람이 조율하는 AI 보조 방식의 한계

• 기존 방식에서는 AI가 스펙 작성, 코드 생성, 테스트, PR 설명 등을 빠르게 수행한다.
• 그러나 각 단계 사이에서 사람이 다음 작업을 요청하고, 실패 결과를 전달하고, diff와 PR을 검토해야 한다.
• 따라서 개별 작업은 빨라져도 의도·구현·검증·리뷰·전달 사이의 조율 비용은 그대로 남는다.
• 진정한 생산성 향상은 각 단계를 단순히 가속하는 것이 아니라, 수동 인수인계를 프로세스에서 제거하는 데 있다.

제안자와 도전자로 나뉜 AI 협업

• 제안자는 산출물을 작성하고 단계가 진행될수록 이를 발전시킨다.
• 도전자는 제안자의 결과를 검증하며, 단계별로 서로 다른 관점에서 문제를 제기한다.
  • 스펙 단계: 소크라테스식 질문으로 모호성·누락을 찾는다.
  • 빌드 단계: 테스트와 실행 결과 등 근거를 바탕으로 반론한다.
  • 전달 단계: 구현과 PR이 최종 리뷰에 충분한지 점검한다.
• 역할을 분리하면 하나의 AI가 스펙, 구현, 검증, 리뷰를 모두 낙관적으로 처리하는 문제를 줄일 수 있다.
• 사람은 시작 시 의도를 정의하고, 결과를 승인하거나, 해결하기 어려운 문제가 상위 보고될 때 주로 개입한다.

스펙·빌드·전달 파이프라인

스펙: 이후 작업의 계약 정의

• 스펙은 다음 내용을 포함한다.
  • 목표와 제약 조건
  • 해석된 요구 사항
  • 명시적 가정
  • 미해결 질문
  • 제안된 접근 방식
  • 완료 정의
• 빌드 에이전트는 “합리적으로 보이는” 구현을 임의로 선택하지 않고, 승인된 스펙에서 테스트와 검증 계획을 도출한다.
• 스펙이 부실하면 이후 구현과 리뷰의 기준도 불명확해지므로 전체 파이프라인이 약해진다.
• 기존 API, 테스트, 의존성, 코딩 관습, Jira·Confluence·설계 문서 등을 조사해 질문과 가정을 구체화한다.

빌드: 테스트 우선 구현과 반론

• 제안자는 코드를 수정하기 전에 스펙을 다음 항목으로 변환한다.
  • 예상 동작
  • 에지 케이스
  • 추가·수정할 테스트
  • 실행 명령
• 도전자는 구현 전이나 구현 중에 검증 설계 자체를 문제 삼을 수 있다.
• 제안자가 도전자의 이의를 거부하려면 실행 경로, 컴파일·린트 출력, 실패 테스트 등 구체적인 증거를 제시해야 한다.
• 단순히 테스트가 녹색이라는 사실만으로 검증 누락을 숨길 수 없도록 설계됐다.

전달: 리뷰 가능한 PR 패키지

• 최종 산출물은 코드뿐 아니라 리뷰어가 신뢰할 수 있는 PR 패키지다.
• 패키지에는 다음 정보가 포함된다.
  • 무엇이 변경되었는가
  • 어떤 파일과 영역을 먼저 봐야 하는가
  • 어떤 검사와 테스트를 통과했는가
  • 남은 위험과 불확실성은 무엇인가
  • 도전자가 어떤 문제를 제기했고 어떻게 처리했는가
• 전달 단계의 조율자는 중재자라기보다 출시 가능성을 판단하는 심사위원 역할을 한다.

조율자와 구조화된 토론 프로토콜

• 조율자는 제안자와 도전자 사이에서 토론을 관리한다.
• 주요 책임은 다음과 같다.
  • 논의가 주제에서 벗어나면 방향 수정
  • 교착 상태 해소
  • 산출물 수정 요청
  • 안전하지 않은 불확실성의 상위 보고
  • 다음 단계 진행 여부 결정
• 스펙과 빌드에서는 수렴을 이끄는 중재자 역할을 하고, 전달 단계에서는 근거가 충분한지 판정한다.
• 각 에이전트는 제한된 프롬프트와 자체 컨텍스트를 사용하며, 공통으로 접근하는 것은 워크스페이스·산출물·조율자가 누적한 기록이다.
• 에이전트 간 실시간 공동 컨텍스트 대신 구조화된 산출물과 transcript를 통해 협업한다.

JSON 기반 상태 머신

• 각 토론 라운드는 제안자와 도전자의 교환 및 조율자의 결정을 포함한다.
• 에이전트는 긴 에세이가 아니라 조율자가 파싱할 수 있는 엄격한 JSON을 반환한다.
• JSON에는 상태, 요약, 전문가 의견, 판단 근거, 요구 사항, 제약, 완료 정의, 가정, 질문 등이 담긴다.
• 예를 들어 /api/search만 변경할지 인접한 검색 엔드포인트까지 포함할지 불명확하면, 도전자는 범위 경계를 명시적인 질문으로 제기한다.
• 모호성이 작고 기존 근거로 안전하게 판단할 수 있으면 제안자가 가정으로 기록하고 진행한다.
• 반대로 답이 없으면 위험하거나 파괴적이거나 되돌리기 어려운 문제라면 추측하지 않고 사람에게 상위 보고한다.

전문 역할과 근거 중심 검증

• 각 단계에는 목적에 맞는 전문 역할이 배정된다.
  • requirements-synthesizer: 요구 사항 정리
  • security-analyst: 보안 위험 분석
  • test-coverage-reviewer: 테스트 범위 검토
  • technical-writer: 전달 문서 작성
  • evidence-verifier: 구현과 검증 근거 확인
• 중요한 판단은 직감이 아니라 코드, 테스트, 문서, 실행 결과 같은 근거에 기반한다.
• 핵심은 여러 AI를 단순히 병렬 실행하는 것이 아니라, 서로 다른 책임과 관점을 부여해 주장과 반론을 구조화하는 데 있다.

실용적인 결론

AI 코딩 시스템을 설계할 때는 코드 생성 에이전트 하나를 더 빠르게 만드는 것보다, 스펙부터 PR 전달까지의 인수인계를 자동화하는 것이 더 큰 효과를 낼 수 있다. 특히 스펙을 계약으로 명확히 만들고, 단계별 도전과 근거 제출을 강제하며, 위험한 가정은 사람에게 상위 보고하도록 구성하는 것이 핵심이다.