Agent Teams 재검증: 단독 실행과의 대조 실험에서 AC 건수에 2배 차이가 난 이유

이전 실험에는 근거의 허점이 있었다

이전에 비밀번호 생성 앱을 소재로 Claude Code의 Agent Teams 기능으로 설계 비판 하네스(Harness)를 4개 에이전트로 구성하는 실험을 했다. "에이전트 간에 논의가 자연스럽게 발생했다"는 관찰 결과는 얻었지만, 리뷰 단계에서 중대한 문제가 발견되었다.

최종 성과물의 건수(수락 조건(AC) 14건, 역시나리오 18건, MVP 7개 파일 구성, 확장 포인트 6종)가, 동일한 소재를 단독 에이전트로 돌린 별도 기사의 결과와 완전히 일치했다.

별도로 생성해서 우연히 일치한 것인지, 한쪽이 다른 쪽의 성과물을 참조한 것인지 실행 로그로는 구분할 수 없었다. 즉, 기사의 핵심인 "Agent Teams를 사용하면 이렇게 변한다"라는 주장에 대해 성과물 수준의 근거를 확보하지 못한 것이다.

그래서 소재를 바꾸어, 단독 실행과 팀 실행을 상호 불가시(Invisible) 상태에서 동시에 돌리는 대조 실험을 다시 설계했다. 이 기사는 그 결과에 관한 것이다.

Agent Teams란

통상적인 서브 에이전트 호출은 부모에서 자식으로 이어지는 일방향 구조다.

메인 Claude → 서브 에이전트 A(태스크 실행) → 결과를 반환

Agent Teams는 가로 방향의 메시징(에이전트 간의 직접 통신)을 추가하는 실험적 기능으로, 환경 변수로 활성화한다.

# settings.json의 env 섹션에 추가
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

순차 실행과 Agent Teams 구조의 차이

순차 실행에서는 1개의 에이전트가 4개의 역할을 차례대로 수행한다.

Agent Teams에서는 역할마다 에이전트를 나누어, 되돌아오는 통신로가 생긴다.

점선이 되돌아오는 통신이다. 순차 실행에는 이전 페이즈로 돌아가는 경로가 없다. 여기까지는 지난번과 동일한 설명이지만, 문제는 "그 통신이 실제로 성과물에 어떻게 반영되는가"를 독립적으로 확인할 수 없었다는 점에 있다.

대조 실험 설계

소재

자작 AoE4 빌드 오더 지원 도구(Python/Tkinter 제작, 항상 최상단에 위치하는 오버레이)에 대한 기능 추가를 소재로 삼았다. 요구사항은 한 줄만 주었다.

"빌드 오더의 실행 결과를 기록하여, 나중에 목표와의 차이를 되돌아볼 수 있게 해줘"

신규 개발이 아닌 기존 코드베이스에 대한 기능 추가로 정한 것은 의도적이다. 기존의 책임 경계(타이머 제어, OCR 감지, 빌드 편집)가 있는 만큼, "어디까지를 신규 모듈로 만들 것인가", "기존 코드에 어디까지 손을 댈 것인가"라는 설계 판단이 발생하기 쉽기 때문이다.

독립성을 보장하기 위해 실시한 5가지 대책

지난번 최대의 결함은 "독립적으로 생성되었음을 증명할 수 없었다"는 점에 있었다. 이번에는 대책을 먼저 결정한 후 실행했다.

4번째가 은근히 효과적이다. 지난번에는 에이전트가 과거의 성과물을 보고 건수를 끌어왔을 가능성을 배제할 수 없었다.

5번째에 대해서는, 결과적으로 모든 페이즈에서 자기 신고와 실제 카운트가 일치했다. 차이는 발생하지 않았다. 다만 검증 과정에서, 나의 grep 패턴이 허술하여 실제보다 많은 수를 반환한 적이 한 번 있었다(헤더 행을 중복으로 잡았다). 에이전트의 신고가 아니라 검증하는 쪽이 틀린 것이었기에, 대조 절차 그 자체에도 정밀도가 필요함을 실감했다.

단독 실행과 팀 실행은 동일 요구사항·동일 대상 코드에 대해 병렬로 실행했다. 단독 버전은 4개 페이즈(Socrates → Popper → DbC → Gall)를 1개의 에이전트가 순서대로 수행하는 기존 방식, 팀 버전은 4개의 에이전트로 나뉘어 메시징으로 연계하는 방식이다.

결과 1: 가장 큰 차이는 AC(수락 조건)에서 나타났다

단독 6건에 대해 팀 13건. 2배 이상의 격차가 벌어졌다.

원인은 Popper의 푸시백(Pushback)에 있다. 단독 실행은 "AC를 작성한다" → "그것을 스스로 비판한다"를 동일한 컨텍스트에서 수행하기 때문에, 자신이 직전에 작성한 항목을 부정하기 어렵다. 팀 실행에서는 Popper가 별도의 컨텍스트에서 6건의 이의를 제기했고, Socrates가 5건을 수용하고 1건을 DbC에 위임한 결과, AC가 12건에서 13건으로 늘어났으며 내용 또한 바뀌었다.

Popper의 지적 중, 단독 버전에는 대응하는 기술이 전혀 없는 3건을 든다(지면 관계상 발췌하였으며, 원문의 일부를 생략하였다).

PB-04（대상 AC-11）:
「기록 처리는 예외로 인해 중단되지 않으며, 타이머 본체의 동작을 방해하지 않는다」라는 표현은,
사용자가 관측할 수 있는 수락 조건(Acceptance Criteria)이라기보다 구현상의 방어적 프로그래밍 (Defensive Programming)
...

PB-05가 특히 상징적이다. AC를 작성한 본인이 「친절한 마음으로 추가한 항목」을 나중에 스스로 삭제하는 것은 구조적으로 일어나기 어렵다. 팀 실행에서는 별개의 컨텍스트를 가진 Popper가 외부에서 보고 지적하고, Socrates가 이를 수용하여 삭제했다. 이러한 종류의 「자신의 결과물에 대한 부정」은 동일 에이전트의 순차 실행에서는 나타나기 어렵다.

참고로, AC 건수가 많다는 것 자체가 품질의 우열을 의미하지는 않는다. Scope creep(범위 확장)을 1건 줄인 반면, 경계 조건 및 실패 계통의 분할을 통해 총수는 늘어났다. 여기서 말할 수 있는 것은 「별개의 컨텍스트로부터의 비판에 의해, AC 군의 내용이 단독 실행과는 다른 형태로 변했다」는 사실뿐이다.

결과 2: 건수가 같더라도 설계는 별개 (INV)

수치만 보면 INV(불변 조건, Invariant)는 양쪽 모두 8건으로 일치한다. 하지만 설계 판단으로서는 별개였다.

단독 버전의 INV는 「이 IF를 호출한 후 이렇게 된다」라는 절차 중심적인 기술이 중심이었다. 팀 버전은 「차분값은 디스크에 영속화하지 않고, 원천 데이터로부터 매번 계산한다」와 같이, 데이터 모델에 관한 설계 원칙으로서 독립적으로 정의되어 있었다.

건수의 일치는 설계의 일치를 의미하지 않는다. 이는 지난번 기사가 「건수가 일치했다」는 단 한 점 때문에 발목을 잡혔던 것과 같은 함정이며, 이번에도 다른 형태로 빠져들 뻔했다. 건수만 보고 「동등한 결과물」이라고 판단하는 것은 위험하다는 것을 대조 실험 자체가 보여주고 있다.

결과 3: 팀 실행에서만 관찰된 「논점의 3단 릴레이」

팀 측에서는 하나의 논점이 3개의 페이즈를 거쳐 위임되는 거동이 관찰되었다.

Socrates ──PB-06을 위임──> DbC ──PB-DBC-01을 위임──> Gall

Socrates → DbC: 「차분값을 영속화할 것인가, 매번 계산할 것인가」는 수락 조건 수준에서 결정할 문제가 아니라고 판단하여 위임 -
DbC → Gall: 「빈 세션을 어디까지 유지할 것인가」는 계약(IF/INV)만으로는 결정할 수 없는 제품 스코프(Product Scope)의 판단이라며 위임

Gall의 최종 판단은 「MVP에서는 필터링하지 않고 전부 유지한다」였으며, 그 이유는 가역성(Reversibility)이었다.

「유지한다」는 가장 가역적인 선택이다. 나중에 삭제 기능이나 필터 기능을 추가하는 것은 언제든 가능하지만, 「생성을 차단하는」 구현을 먼저 넣어버리면, 나중에 「사실 빈 세션에도 의미가 있었다」라는 요구사항이 왔을 때 돌이킬 수 없게 된다.

각 페이즈가 「자신의 책무로는 결정할 수 없는 것」을 명시하며 다음으로 넘겼고, 제품 판단을 내리는 페이즈까지 도달했다. 지난번에 관찰할 수 있었던 것은 1회 왕복(Popper → Socrates)뿐이었으며, 3단 릴레이는 이번이 처음이다.

단독 버전에는 이러한 구조가 없다. 한 명의 에이전트가 전부 결정하기 때문에 애초에 위임이 발생할 수 없다. 단독 버전에서도 유사한 논점(차분값의 저장 방식)이 다뤄지지만, 하나의 문맥 안에서 자기 완결적으로 결정하고 있으며, 「누군가에게 던진다」는 움직임은 일어나지 않는다.

지난번 (비밀번호 생성기)와의 비교

지난번 일치했던 6개 항목 중, 이번에는 5개 항목이 일치하지 않았다.

주제를 바꾸면 숫자는 달라지기 때문에, 지난번의 일치는 「같은 주제를 같은 절차로 풀었더니 숫자가 맞아떨어졌을 뿐」이었을 가능성이 높다.

다만 확장 포인트(Extension Point)만은 지난번과 이번 모두 팀 버전이 6종으로 일치한다. 지난번의 일치는 재현되지 않았으나, 이번에 이 1개 항목이 동일한 숫자가 된 것이 우연인지는 판정할 수 없다. 이 부분은 계속해서 「미확인」 상태로 취급한다.

한계 (솔직하게 기술함)

이번 대조 실험에도 한계가 있다. 이 부분을 생략하면 지난번과 완전히 똑같은 실수를 반복하게 되므로, 일부러 자세히 적는다.

단독 실행의 완료 시각은 팀 측의 최종 결과물이 생성된 시각보다 늦었다. 즉, 단독 버전이 돌아가고 있는 동안, 동일한 디렉토리에는 이미 팀 버전의 출력 파일이 존재하고 있었다.

각 에이전트에게는 "상대의 출력을 절대로 열지 마라"라고 명시적으로 지시하고 있다. 실제로 단독 버전의 성과물을 검증한 결과, 팀 버전 고유의 어휘(Socrates, Popper, 푸시백(Pushback)과 같은 역할명이나 용어)는 0건이었다. 적어도 "그대로 복사했다"는 흔적은 없다.

하지만, "읽지 않았다는 것"을 적극적으로 증명하지는 못했다. 어휘가 혼입되지 않았다는 것은 참조하지 않았다는 증거는 될 수 있어도, 참조하지 않았다는 증명은 되지 않는다. 파일의 존재 자체가 노이즈로서 영향을 미쳤을 가능성을 제로로 만들 수는 없다.

다음에 다시 실험한다면, 디렉토리를 물리적으로 분리하거나 실행 타이밍을 엇갈리게 하여 한쪽이 완전히 끝난 뒤에 다른 한쪽을 시작하는 것이 확실하다. 이번에는 그 정도의 대책까지는 강구하지 않았다.

이 실험에서 말할 수 있는 것과 말할 수 없는 것

말할 수 있는 것

• 동일한 요구사항으로 단독 실행과 팀 실행을 돌렸을 때, AC(Acceptance Criteria) 건수에 2배 이상의 차이가 났다 (6건 vs 13건)
• 차이의 원인은 별도의 컨텍스트(Context)로부터 오는 비판에 있다. 구체적인 푸시백(Pushback) 내용을 제시할 수 있다
• 건수가 같더라도 설계 판단이 다른 경우가 있다 (INV의 예)
• 논점이 3단계 릴레이되는 동작은 팀 실행에서만 관찰되었다

말할 수 없는 것

• "팀 실행이 더 우수하다" — 품질 평가를 수행하지 않았다. AC가 많은 것이 반드시 좋은 것은 아니다. 스코프 크립(Scope creep)을 줄인 반면, 분할로 인해 건수가 늘어났으므로 단순한 우열의 지표가 될 수 없다.
• "N번 중 N번 재현된다" — 각 방식은 한 번씩만 실행했다. 이번 차이가 안정적으로 나타나는지는 반복 실험을 통해 확인할 필요가 있다.
• 지난 기사의 건수 일치가 무엇이었는지 — 본 실험에서는 지난번의 재현 실험을 수행하지 않았기 때문에, 여전히 원인을 특정하지 못하고 있다.

요약

지난 기사는 "논의가 자연 발생했다"는 경험을 축으로 삼았으나, 성과물 수준의 뒷받침이 부족하여 공개를 보류했었다. 이번에는 독립성을 담보하는 대책을 먼저 결정한 후, 단독 실행과 팀 실행을 동시에 돌리고 실제 파일의 ID를 grep으로 검증하는 단계까지 다시 수행했다.

알아낸 점은 세 가지다.

• AC 건수에 2배 이상의 차이가 났으며, 그 원인(별도 컨텍스트로부터의 푸시백)을 구체적으로 제시할 수 있었다.
• 건수가 일치하더라도 설계의 내용이 달라질 수 있다. 이는 지난번의 실패를 다른 각도에서 반복할 뻔했던 지점이기도 하다.
• 독립성 대책을 강구했음에도, "상대의 출력이 같은 장소에 존재하고 있었다"라는 한계는 완전히 해소하지 못했다.

Agent Teams라는 기능 자체는 아직 실험 단계이지만, 이번에 밟은 절차——출력처의 분리, 상호 참조 금지, 건수 유도 배제, 실제 파일 검증——는 멀티 에이전트(Multi-agent) 구성의 효과를 주장할 때 최소한으로 필요한 절차라고 생각한다. 다음에는 디렉토리의 물리적 분리까지 깊이 들어가 이 한계를 하나 더 없애고 싶다.

좋아요와 댓글로 반응해 주시면 큰 힘이 됩니다!

Discussion