This post is also available in the following languages. Japanese, English

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

LY Corporation의 기술 컨퍼런스인 Tech-Verse 2026의 공식 기사입니다.

AI 코딩에서 어려운 점은 더 이상 코드를 생성하는 것이 아닙니다. 진짜 어려운 부분은 그 밖의 모든 과정입니다. 의도를 명확한 스펙으로 바꾸고, 가정을 점검하며, 구현을 확인하고, 리뷰어가 신뢰할 수 있는 PR(pull request)을 준비하는 일입니다.

저희는 이 조율 과정을 ‘제안자(proposer)’와 ‘도전자(challenger)’라는 전문가 간의 단계별 토론 구조로 재설계했습니다. 각 단계는 스펙과 구현, 리뷰 준비가 완료된 PR 패키지라는 고유한 산출물을 만듭니다. 제안자는 산출물을 발전시키고, 도전자는 단계마다 서로 다른 방식으로 이를 검증합니다. 스펙 단계에서는 소크라테스식 질문을 던지고, 빌드 단계에서는 근거를 바탕으로 반론을 제기하며, 전달 단계에서는 최종 준비 상태를 점검합니다. ‘조율자(orchestrator)’는 수정, 상위 보고(escalation), 다음 단계 진행 여부를 결정합니다.

저희의 CI(continuous integration) 흐름에서는 이슈가 토론을 거친 스펙, 브랜치, 테스트된 구현, 리뷰 준비가 완료된 PR로 자연스럽게 이어집니다. 최종 판단은 여전히 사람 엔지니어가 내리지만, 이제 각 단계 간 인수인계를 수동으로 조율할 필요는 없습니다.

이 글에서는 이 파이프라인이 어떻게 작동하고 어디서 문제가 발생하는지 살펴보고 진정한 레버리지가 단순히 코드를 빨리 생성하는 것이 아닌 이유를 설명합니다. 핵심은 사람이 신경 쓰기 전에 AI가 스스로 자신의 작업을 입증하도록 만드는 것입니다.

문제: 사람이 조율하는 과정이 병목이다

LY Corporation의 ‘10x Faster(참고)’는 각 수동 단계를 더 빠르게 만드는 것만으로는 이룰 수 없습니다. 프로세스 자체를 근본적으로 재설계해야 합니다. 의도를 어떻게 스펙으로 바꾸고, 가정을 어떻게 검증하며, 구현을 어떻게 확인하고, 리뷰어에게 어떻게 충분한 근거를 제공하는지까지 모두 다시 설계해야 합니다.

여기서 불편한 진실은, AI로 소프트웨어를 만들 때 진짜 병목은 종종 AI의 코드 생성 능력이 아니라 그 주위를 둘러싼 사람의 조율이라는 것입니다. 우리는 스펙을 작성하고, AI에게 초안을 요청하고, 초안을 검토하고, 부족한 부분을 보충하고, 코드를 요청하고, 테스트를 실행하고, 실패 테스트 내용을 다시 복사해 붙이고, 차분(diff)을 검토하고, PR 설명을 요청하고, 결과에 문제가 없는지 판단합니다. AI는 각 개별 단계는 빠르게 처리하지만, 처리한 뒤에는 우리가 다음 단계를 조율할 때까지 대기합니다.

이것이 바로 ‘AI 보조(AI-assist)’ 방식입니다. 기존 프로세스에 AI를 얹는 접근 방식으로, 개별 단계는 빨라지지만 실제로 비용이 많이 드는 부분인 의도, 구현, 검증, 리뷰, 전달 사이의 조율 계층은 그대로 남아 있습니다.

이 문제를 해결하는 현실적인 방향은 엔지니어의 판단을 배제하는 것이 아니라 엔지니어를 복잡하고 반복적인 중간 조율 작업에서 벗어나게 하는 것입니다. 이런 관점에서 저희 팀은 기존과는 조금 다른 접근 방식을 테스트해 왔습니다. 하나의 어시스턴트에게 일련의 프롬프트를 입력하는 기존 방식을 벗어나, 개발을 전문화된 AI 역할들이 하나의 팀처럼 조율돼 구조적으로 협업하는 것으로 다루는 것입니다.

핵심 아이디어: 여러 AI 에이전트가 함께 생각하게 만들기

사람이 각 단계 사이의 모든 인수인계를 직접 챙기지 않는다면 시스템은 어떻게 최종 리뷰 전에 버그를 잡고, 가정을 검증하며, 에지(edge) 케이스를 드러낼 수 있을까요? 수동 체크포인트를 하나 더 넣을 수도 있겠지만 이는 병목에 이름만 바꿔 붙이는 것과 다름없습니다. 단일 AI 체커를 추가할 수도 있지만 이는 또 다른 단일 시각 리뷰로 귀결되는 경우가 많습니다.

답은 AI의 역할을 제안자와 도전자라는 두 팀으로 나누고, 각 팀이 단계별로 서로 다른 책임을 맡아 구조화된 프로토콜을 이용해 토론하게 만드는 것입니다. 이 방법이 효과적인 이유는 페어 프로그래밍이 효과적인 이유와 같습니다. 다만 두 사람이 아니라, 두 팀의 AI 전문가가 서로를 지속적으로 견제하고 검증하는 것입니다.

여기서 중요한 것은 정확한 역할 이름이 아닙니다. 설계 원칙은 단 하나입니다. 스펙, 구현, 리뷰, 검증, 전달을 하나의 일반적인 어시스턴트 응답으로 통합하는 대신, 각각을 별개의 책임으로 분리하는 것입니다. 엔지니어링 책임을 분리하고, 각 측이 근거에 기반해 주장하도록 만들며, 조율자가 언제 다음 단계로 넘어갈지 결정하도록 만듭니다.

AI 네이티브 개발(AI-native development)은 이런 전문가들이 공통된 산출물을 중심으로 협업하도록 프로세스를 재설계합니다. 사람은 중간 단계에서 발생하는 번거로운 세부 조정 및 인수인계 작업에서 벗어나지만, 소유권이나 판단 권한은 그대로 유지합니다. 그 과정에서 에이전트는 자동으로 탐색하고, 다듬고, 검증하고, 작업을 패키징합니다. 기본적으로 사람은 전략적인 단계에서만 개입합니다. 시작할 때 의도를 정의하거나, 마지막에 결과를 승인하거나, 시스템이 명시적으로 문제를 상위로 보고할 때 방향을 제시합니다.

작동 방식: 세 단계와 하나의 스펙 기반 파이프라인

워크플로는 세 가지 핵심 요소로 구성됩니다. ‘스펙 → 빌드 → 전달’입니다. 여기에 이 워크플로를 지원하는 ‘두 팀의 전문가’와 ‘수정, 상위 보고, 다음 단계 진행을 결정하는 조율자’가 있습니다.

워크플로의 순서는 의도한 것입니다. 스펙 단계가 가장 중요하기 때문입니다. 스펙은 이후 모든 단계에서 반드시 지켜야 하는 계약을 정의합니다. 이 계약에는 목표, 제약 조건, 해석된 요구 사항, 명시적 가정, 미해결 질문, 제안된 접근 방식, 완료 정의가 포함됩니다.

이런 점에서 이 방식은 ‘스펙 주도 개발(spec-driven development)’의 한 형태라고 볼 수 있습니다. 스펙은 문제의 요구 사항에 따라 짧을 수도 있고 길 수도 있지만 어느 쪽이든 워크플로를 제어하는 핵심 산출물이 되어야 합니다. 빌드 에이전트는 단순히 ‘합리적으로 보이는’ 대로 작업하는 게 아니라 합의된 스펙에서 테스트와 검증을 먼저 도출한 뒤 스펙과 검증 설계 모두를 기준으로 구현합니다. 전달 에이전트도 차분을 단순히 요약하는 것이 아니라 구현이 스펙을 충족하는지 입증합니다. 스펙이 부실하면 전체 파이프라인도 부실해집니다. 스펙이 정확해야 이후 단계에서 최적화하고 이의 제기하고 검증할 구체적인 대상이 생깁니다.

각 단계에서 전문화된 에이전트 실행은 제안자나 도전자 중 한쪽에 배정됩니다. 여기서 ‘에이전트’란 Claude Code, Codex, OpenCode 같은 도구에서 사용하는 코딩 에이전트 인터페이스의 실행 단위를 의미하며, 조율자가 각각에게 전문적인 역할을 부여합니다. ‘에이전트 팀’은 같은 단계에서 서로 반대편에 서서 부여받은 역할을 수행하는 실행 그룹을 의미합니다. 집단 지성(hivemind)을 공유하는 대규모 자율 시스템 집합체와는 다릅니다. 현재 각 실행은 제한된 프롬프트와 자체 컨텍스트, 동일한 작업 공간의 산출물에 접근할 수 있는 권한만 가질 수 있도록 구현해 놓았습니다. 여기서 팀이라는 비유는 각 실행이 모든 책임을 하나의 일반적인 답변으로 통합하는 대신 특정 엔지니어링 관점에서 주장하도록 강제한다는 점에서 유용합니다.

조율자는 제안자와 도전자 사이에 위치해 토론이 주제에서 벗어나면 방향을 바로잡고, 교착 상태를 해소하며, 단계를 계속할지, 수정할지, 다음 단계로 넘어갈지 판결합니다. 구체적인 역할은 단계별로 달라지는데요. 스펙과 빌드 단계에서는 수렴을 이끄는 중재자(mediator)이고, 전달 단계에서는 출시할 만한 근거가 충분한지 판단하는 심사위원(jury)입니다.

각 단계는 서로 다른 전문가 초점과 토론 전략을 결합해 진행됩니다. 근본적으로 각 단계의 목표가 서로 다르기 때문입니다.

단계	제안자 초점	도전자 초점	토론 전략
스펙	코드베이스를 조사하고 요구 사항을 종합	모호성, 숨은 가정, 리스크를 드러냄	소크라테스식 질문: 주장이나 해결책 제시 없이 질문만
빌드	스펙에서 테스트와 검사를 설계한 뒤 변경을 구현하고 유지	검증 설계, 커버리지, 보안, 성능, 수용 기준, 유지보수성에 도전	적대적 리뷰: 테스트나 코드, 실행 근거에 대한 구체적인 증거를 확보한 후 이의 제기
전달	PR 요약, 근거, 리뷰 맵 준비	준비 상태, 근거 품질, 시각화 정확성 검증	배심원식 토론: 어느 쪽도 스스로를 판정하지 않으며 조율자가 결정

실제로 각 초점은 requirements-synthesizer, security-analyst, test-coverage-reviewer, technical-writer, evidence-verifier 등 다양한 전문 역할로 매핑됩니다.

큰 흐름에서 보면 아래와 같이 동일한 토론 패턴이 세 단계 모두에서 반복됩니다.

중요한 점은 각 단계가 직감이 아니라 근거에 기반한다는 것입니다. 스펙 컨텍스트는 워크스페이스와 Jira 티켓, Confluence 페이지, 설계 문서, 사고 노트 등의 다양한 외부 프로덕트 소스에서도 가져올 수 있습니다. 에이전트는 구현을 시작하기 전에 기존 API, 테스트, 의존성, 관습 등의 컨텍스트를 활용해 더 나은 질문을 던집니다. 이어서 빌드 단계는 테스트 우선 방식으로 진행합니다. 제안자는 프로덕션 코드를 바꾸기 전에 승인된 스펙을 예상 작동, 에지 케이스, 추가 또는 수정할 테스트, 실행 명령으로 변환합니다. 도전자는 코드 작성 전이나 작성하는 동안에 이 검증 설계에 이의를 제기할 수 있으므로, 단순한 녹색 체크 표시로 승인 검증 누락을 숨길 수 없습니다. 빌드 단계의 리뷰는 양방향으로 진행됩니다. 제안자는 도전자의 이의 제기를 거부할 수 있지만, 이를 위해서는 실행 경로나 컴파일/린트 출력, 실패 테스트 등 구체적 증거가 필요합니다. 전달 단계에서는 결과를 리뷰어가 신뢰할 수 있는 패키지로 만듭니다. 무엇이 바뀌었는지, 어디를 먼저 봐야 하는지, 어떤 검사를 통과했는지, 남은 리스크는 무엇인지, 도전자가 이미 어떤 시도를 했는지까지 담습니다.

프로토콜 작동 모습

정확한 페이로드는 단계별로 다르지만 그 구조는 모두 같습니다. 각 전문가 에이전트 실행은 단계별 컨텍스트를 받아서 필요하면 워크스페이스 근거를 검사한 뒤 조율자가 파싱하고 비교하며 다음 라운드로 넘길 수 있도록 엄격하게 잘 구조화한 JSON을 반환합니다(여기서 라운드란 제안자와 도전자 간의 완전한 토론 교환과 조율자의 결정까지 포함한 한 사이클을 말합니다). 각 에이전트는 하나의 실시간 컨텍스트 창을 공유하지 않습니다. 대신 지속적으로 공유되는 상태는 워크스페이스와 생성된 산출물, 조율자가 쌓아놓는 기록(transcript)입니다.

스펙 단계는 이후 모든 단계를 위한 계약을 만들기 때문에 앞서 설명한 패턴이 가장 명확하게 드러납니다. 하나의 라운드는 단순히 스펙을 리뷰하는 것이 아니라 작은 상태 머신처럼 작동합니다. 각 턴에는 명확히 정의된 역할과 제한된 응답 형식이 있고, 스펙을 수정할지, 다른 리뷰를 요청할지, 남은 불확실성이 너무 커서 진행을 중단할지 결정한 판단이 포함됩니다.

출력은 긴 에세이가 아니라 구조화된 JSON입니다. 각 턴은 같은 형식을 유지하므로, 해당 턴에서 사용하지 않는 필드는 비어 있습니다. 예를 들어 도전자의 질문 턴은 다음과 같습니다.

{
  "turn": "questions",
  "status": "needs-revision",
  "summary": "The spec needs one scope boundary before build.",
  "specialistInputs": [
    {
      "name": "ambiguity-reviewer",
      "stance": "caution",
      "opinion": "The named endpoint is clear, but neighboring search-like endpoints are not explicitly in or out of scope."
    }
  ],
  "decisionRationale": "Preserving the named scope avoids accidental broadening while letting the Proposer write a bounded assumption into the spec.",
  "payload": {
    "ready": false,
    "interpretation": {
      "requirements": [],
      "constraints": [],
      "definitionOfDone": [],
      "assumptions": [],
      "openQuestions": []
    },
    "questions": [
      {
        "id": "Q1",
        "severity": "major",
        "section": "constraints",
        "question": "Should the implementation be limited to the existing `/api/search` route, leaving other search-like endpoints unchanged unless explicitly named?",
        "whyItMatters": "Without this boundary, the build phase might change unrelated endpoints. Preserving the named scope is a safe default if documented in the spec.",
        "requiresUserInput": false,
        "assumptionRisk": "low",
        "confidence": 0.85
      }
    ],
    "answers": []
  }
}

이것이 중요한 이유는 프로토콜이 불확실성과 장애물을 구분하기 때문입니다. 모호함이 적고, 되돌릴 수 있으며, 기존 워크스페이스 근거로 경계를 정할 수 있다면 제안자는 그 가정을 스펙에 기록하고 그대로 진행할 수 있습니다. 반대로 누락된 답변이 안전하지 않거나, 파괴적이거나, 외부 제약이 있거나, 실질적으로 되돌리기 어렵다면 시스템은 추측해서 임의로 진행하지 않고 반드시 상위로 보고합니다.

빌드와 전달 단계에서도 같은 구조화된 토론 아이디어를 사용하지만 페이로드는 다릅니다. 빌드 단계는 테스트 우선 검증 설계, 실행 근거, 리뷰 이슈를 accepted, rejected, compromised로 매핑한 결과와 그 근거 및 증거를 함께 남깁니다. 전달 단계는 그 결과를 PR 본문, 테스트 근거, 리뷰어 가이드로 패키징합니다. 여기서 공통점은 에이전트가 단순히 글을 작성하는 것이 아니라 다음 단계에서 검증 가능한 구조화된 근거를 남긴다는 점입니다.

각 전문가의 역할을 강화하는 스킬

전문가의 역할은 역할 프롬프트만으로 충분하지 않습니다. 유용한 관점을 제공하는 ‘보안 분석가’라는 역할은 재사용할 수 있는 스킬(변경된 엔드포인트에 대한 위협 모델링, 인증 경계 확인, 입력 유효성 검사 리뷰, 구체적인 공격 시나리오 생성 스킬 등)과 결합할 때 훨씬 더 강력해집니다. 요약하면 역할은 에이전트가 무엇에 집중해야 하는지 정의하고, 스킬은 어떻게 작동해야 하는지 정의합니다.

이와 같은 방식으로 전문성을 모듈화할 수 있습니다. 테스트 엔지니어는 경계 테스트 생성 스킬을, 배포 문서 작성자는 의사 결정 근거를 보존하는 PR 설명 작성 스킬을, 시각화 전문가는 차분을 다이어그램으로 바꾸는 리뷰 맵 스킬을 가져올 수 있습니다. 팀이 익힌 더 나은 리뷰 패턴을 하나의 거대한 프롬프트에 묻어두는 대신 재사용 가능한 방법으로 만들 수 있습니다.

에이전트 간 토론은 어떻게 수렴하는가

자연스럽게 드는 의문이 있습니다. 에이전트들이 끝없이 토론만 하지는 않을까요?

각 라운드는 ‘제안자 제시 → 도전자 평가 → 조율자 결정’이라는 엄격한 구조를 따릅니다. 조율자는 계속 진행, (논의가 주제에서 벗어났을 때) 방향 재설정, 부분 합의 수용, 라운드 종료 중 하나를 선택할 수 있습니다. 여기서 포인트는 해결된 이슈가 다음 라운드에서는 자동으로 제외된다는 것입니다. 이에 따라 각 라운드마다 토론 범위가 좁아집니다. 예를 들어 5개 이슈 중 3개가 1라운드에서 해결되면, 2라운드는 남은 2개에만 집중합니다.

모든 작업에서 극적인 발견이 나오지 않아도 됩니다. 중요한 것은 각 단계가 불확실성을 줄이고 구조화된 근거를 남긴다는 점입니다. 신뢰는 우연에 기대는 리뷰가 아니라 반복 가능한 통제에서 나옵니다.

무엇이 이 시스템을 신뢰할 수 있게 만드는가

세 가지 엔지니어링 메커니즘이 파이프라인이 라운드를 낭비하거나 비생산적인 루프에 빠지지 않게 만듭니다.

메커니즘	해결되는 문제	핵심 아이디어
복잡도 라우팅	모든 작업에 전체 토론이 필요한 것은 아님	복잡도를 분류해 리스크에 따라 토론 강도를 조정
진동 감지	A→B→A 수정 루프는 토큰을 낭비함	반복되는 실패 신호를 감지해 재설계로 상위 보고
이전 내용 구조화	이전 내용을 기록한 그대로로는 미래 실행을 알려주지 못함	결과를 스키마 기반 조언 신호로 압축

먼저 복잡도 라우팅을 살펴보겠습니다. 모든 작업에 동일한 토론 강도가 필요하지는 않습니다. 토론 강도를 조정하기 위해 ‘스펙 정제 리뷰’라는 과정을 통해 실제로 확인한 소스 파일이나 외부 참조 등 사용 가능한 구현 컨텍스트를 수집해서 작업 복잡도를 추정합니다. 이 작업 복잡도를 기반으로 토론이 활성화됐을 때 단순한 작업은 가벼운 전문가 토론만 거치고, 보안에 영향을 미치는 변경 등 중요한 작업은 추가 라운드를 거치게 만듭니다. 즉 리스크에 비례해 비용을 투입하는 것입니다.

위 그림에서 ‘Light specialist pass’란 최소한의 전문가 리뷰를 의미하고, ‘one full round’는 여러 라운드로 확장하지는 않는 제안자와 도전자 간의 완전한 의견 교환을 의미합니다.

다음으로 진동 감지입니다. AI 코딩 도구를 일주일 이상 사용해 봤다면 이런 루프를 경험해 보셨을 것입니다. 테스트 하나를 고쳐달라고 하면 다른 테스트가 망가지고, 이를 고치면 다시 원래 테스트가 실패합니다. 각 수정은 진전처럼 보이지만 멀리서 보면 루프에 빠져 있는데 에이전트는 현재 오류에만 집중하기 때문에 이를 인지하지 못하는 경우가 많습니다. 이런 현상은 단일 에이전트 워크플로에서 가장 답답하게 느껴지는 실패 상황입니다. 에이전트는 열심히 일하며 토큰을 쓰지만 결국 한 발자국도 진전하지 못합니다.

저희 시스템은 에이전트가 자가 수정(self-fix)을 시도할 때 그 과정 전반에 나타나는 실패 신호를 추적합니다. 현재 실패가 두 단계 전과 같고 한 단계 전과 다르다면, 즉 전형적인 A→B→A 진동이라면 자가 수정 루프를 멈추고 같은 수정 사이클을 또 반복하는 대신 최신 결과를 도전자 리뷰로 라우팅합니다.

Step 1: error A
Step 2: fix A → error B
Step 3: fix B → error A  ← same as Step 1. Loop detected.
                         → stop iterating, escalate for redesign

여기서 진동을 감지할 수 있게 만드는 것이 바로 다중 에이전트 구조입니다. 물론 단일 에이전트도 ‘이 오류를 전에 봤다’고 감지할 수는 있습니다. 하지만 그다음에 무엇을 할 수 있을까요? 그냥 더 열심히 시도할까요? 반면 토론 구조는 상위 보고할 대상, 관점이 다른 팀을 제공합니다.

마지막으로 이전 내용 구조화를 살펴보겠습니다. 각 실행이 끝난 뒤 시스템은 이전 내용의 전체 기록을 그대로 저장하지 않습니다. 재사용 가능한 교훈을 작은 스키마에 기반해 압축합니다. 어떤 패턴이 나타났는지, 심각도는 어땠는지, 어떤 범주의 근거가 이를 뒷받침했는지, 얼마나 자주 나타났는지, 신뢰도는 어느 정도인지, 최근 작업은 무엇이었는지, 제안된 완화책은 무엇이었는지 등을 담습니다. 이전 내용은 다음과 같은 형식으로 프롬프트에 다시 들어갈 수 있습니다.

- repeated-failure-check validation:rate-limit-concurrency:major
  (seen 3x, confidence 0.65);
  mitigation: Add or update tests for changed behavior paths, then rerun relevant checks;
  root causes: test-gaps, trust-boundary

여기서 중요한 제약은 이렇게 남긴 이전 내용이 ‘판단’이 아니라 ‘경고 라벨’, 즉 조언 신호로 작용한다는 점입니다. 전문 역할에게 어디를 먼저 봐야 하는지 알려주기는 하지만 여전히 주장 입증은 현재의 근거를 이용해야 합니다. 과거 패턴이 현재 실행을 추가로 검토하게 할 수는 있지만, 자동으로 실패로 처리하게 할 수는 없습니다. 이 제약을 통해 시스템은 과거 패턴을 보고 학습하되 메모리가 검증되지 않은 편향에 빠지지 않게 합니다.

이 방식을 언제 써야 하는가

이 파이프라인은 무엇이 올바른 상태인지 근거로 명확히 정의할 수 있을 때 사용해야 합니다. 명확한 의도와 수용 기준이 있고, 코드와 테스트, 로그, 차분 등으로 검증할 수 있는 경우에 사용해야 합니다.

이 방식은 비동기 CI 기반 작업에서 가장 강력하게 작동합니다. 이슈가 스펙 논의, 빌드, 검증을 거쳐 리뷰 준비가 완료된 PR로 이어집니다. 사람은 판단이 필요한 체크포인트에서 의도를 명확히 만들고, 리스크 경계를 설정하며, 결과를 승인하거나 범위를 다시 지정합니다.

가장 일반적인 흐름은 다음과 같습니다.

이 방식이 적합한 경우는 다음과 같습니다.

CI 기반 이슈-PR 자동화
테스트 가능한 인수 기준이 있는 소규모 및 중간 규모 구현 작업
재현 가능한 실패, 로그, 코드 경로가 있는 버그 수정
보안, 성능, 테스트, 유지 보수 도전자가 가치를 더할 수 있는 리스크에 민감한 변경 작업

올바른 상태의 정의가 아직 합의되지 않은 경우에는 이 방식을 피하는 것이 좋습니다. 탐색적 프로덕트 결정, 불명확한 요구 사항, 구체적 근거로 검증할 수 없는 작업에는 반드시 의사 결정 과정에 사람이 들어가야 합니다.

파이프라인은 자신의 소스 코드 변경도 제안할 수 있지만, 이는 제안 전용 작업으로만 허용합니다. 브랜치와 PR이 필수이고, 스스로 머지하는 것은 금지하며, CI 우회나 새 권한 추가, 승인 없는 파괴적 작업도 금지합니다.

이 방식의 트레이드오프와 한계

다음은 여러 관점에서 이 방식의 트레이드오프와 한계를 살펴보고 완화할 수 있는 방법을 정리한 표입니다.

관점	현실	완화책
비용	단일 에이전트 실행에 비해 토큰 사용량이 많음	복잡도 라우팅으로 사소한 작업은 가벼운 한 라운드로 제한하고, 지연 로딩(lazy-loading)으로 매번 모든 소스 파일, 차분, 참조, 기록을 프롬프트에 붙여 넣지 않음
지연 시간	작업당 수 분 소요	실시간 코딩이 아니라 비동기 파이프라인에 적용
대규모 스펙	한 번의 실행으로 매끄럽게 해결하기는 여전히 어려움	큰 문제를 중간 및 작은 문제로 쪼개고, 사람 확인이 필요한 결정을 분리(현재 스펙 분해 작업 진행 중)
사각지대	양쪽 팀이 같은 부분을 놓칠 수 있음	서로 다른 시스템은 서로 사각지대가 다른 경향이 있기 때문에 모델/프로바이더가 다양해지면 공유된 실패 모드를 줄일 수 있음
소유권	토론이 엔지니어링 책임을 대체하지 않음	사람이 여전히 의도를 정의하고, 경계를 승인하며, 프로덕션 결과를 책임짐

이 방식을 도입하기 위한 추가 비용이 그만한 가치가 있을까요? 많은 프로덕션 대상 변경에서는 놓친 버그 하나가 추가 토론 라운드보다 훨씬 큰 비용이 들 수 있습니다. 반대로 단순 버전 업데이트에는 토론이 낭비입니다. 복잡도 라우팅과 지연 로딩은 비용을 리스크와 근거 필요성에 따라 조절합니다. 멀티 에이전트 토론은 판단을 완전히 대체하는 것이 아니라 사람이 승인하기 전에 보다 일관된 판단을 적용하기 위한 방법입니다.

현재 상황 및 향후 계획

저희는 이 시스템을 CI를 포함해 매일 사용하고 있습니다. ‘hello world’ 수준의 데모가 아니라 명확한 수용 기준이 있는 소규모 및 중간 규모 변경 작업에 실제로 적용하고 있으며, 직접 사용해 본 결과 단일 패스(single-pass) 어시스턴트 워크플로보다 더 탄탄한 스펙을 만들고 더 일찍 문제를 발견할 수 있었습니다.

완벽하지는 않습니다. 토론이 잘못 수렴하는 경우도 있고, 대규모 스펙은 여전히 잘 안 되며, 탐색적 작업은 빌드 단계 전에 리서치가 필요한 경우가 많고, 실제로 비용 오버헤드도 존재합니다. 이에 따라 Human-in-the-loop를 의도적으로 유지하고 있습니다. 목표는 시스템이 항상 옳다고 가장하는 것이 아닙니다. 사람이 수동으로 조율하는 작업을 줄이면서 정말 판단이 필요한 순간에는 사람을 개입시키는 것입니다.

다음 로드맵은 위험도가 낮은 변경 작업에 대한 스펙 분해와 신뢰도 기반 승인에 초점을 맞추고 있으며, 신속한 토론 수렴과 명확한 검증이 목표입니다. 핵심은 ‘모든 것을 자동으로 머지하자’가 아닙니다. 진짜 가치는 사람이 수동으로 작업하는 인수인계를 줄이고, 리뷰 루프 병목을 해소하며, 최종 판단을 내리기 전에 일관된 기술 검증 단계를 추가하는 것에 있습니다.

따라서 더 유용한 질문은 ‘AI가 코드를 작성할 수 있는가?’라는 단순한 질문이 아니라, ‘AI가 자신의 작업을 입증하고, 검증받고, 사람이 더 빠르게 결정할 수 있는 충분한 근거를 남기게 하는 프로세스는 무엇인가?’입니다. 저희는 이 질문에 대한 답으로 상반된 관점의 전문가 간의 상호 작용을 반복 가능하게 만들어 매일 코드를 릴리스하는 방식에 통합할 수 있는 이 파이프라인을 만들었습니다.