저는 PlanGate라는 AI 코딩 에이전트(AI Coding Agent)를 위한 경량 거버넌스 하네스(Governance Harness)를 개인 OSS로서 개발하고 있습니다.

v8.7.0에서는 「자기 진화 프레임(Steering Loop / Trace Timeline / Dogfooding Eval)」을 주축으로 삼을 계획이었습니다. 그런데 Claude Code / Codex CLI / Gemini CLI 3종을 구분하여 사용하며 5 라운드의 디스커션을 진행한 결과, 최종적으로 v8.7.0의 주축은 「자기 진화 기능」에서 「OSS 정비(단계적 도입 가이드 · Plugin 성숙화 · 버저닝 안정성)」로 재편되었습니다.

이 기사는 그 2일간의 의사결정 프로세스 실천 기록입니다. 멀티 에이전트(Multi-agent) 토론을 「어떻게 설계했는지」, 「어디서 무엇이 뒤집혔는지」, 「결국 어떻게 결정되었는지」를 재현 가능한 패턴으로 남깁니다.

참고로, 본 기사의 「Round 1~5」는 남아 있는 5개의 토론 로그를 기사용으로 5단계로 재구성한 명칭입니다. 실제로는 각 로그 안에서 여러 번의 주고받음(서브 라운드)을 거쳤으며, 원본의 라운드 번호와 1대 1로 대응하는 것은 아닙니다. 「Round 3: Gemini」도 시계열상의 세 번째라는 의미가 아니라, 5단계 중 외부 지견과 대조한 페이즈를 가리킵니다.

TL;DR

• 발단은 SpeakerDeck의 Steering Loop(관측 루프)에 관한 강연. 이를 자사 프로덕트에 도입하는 방침을 Claude × Codex로 3회 반복하여 다듬음
• Round 3에서 Gemini를 통해 외부 지견과 대조하자, OpenTelemetry GenAI / Token 필수화 / multi-judge AC 등 여러 「업계 상식」 권장 사항이 나옴
• Round 4에서 동일한 Codex에게 Devil's Advocate(악마의 변호인)를 요청하자, Gemini가 권장한 다수의 사항을 「PlanGate의 현실적 제약에 맞지 않는다」며 뒤집음
• Round 5에서 「외부 OSS 이용자 관점」을 넣는 순간, 토론의 전제였던 「자기 진화를 v8.7.0의 주인공으로 만든다」는 것 자체가 벗겨짐
• 결과적으로 v8.7.0의 주축은 OSS 정비(단계적 도입 가이드 / Plugin 성숙화 / 버저닝 안정성)로 재편되었고, 자기 진화 기능은 optional / experimental로 격하됨

합의를 만드는 토론이 아니라, 서로 다른 관점에서 전제를 깨뜨리러 가는 토론을 돌리면 로드맵의 주축 자체가 움직입니다.

발단: Steering Loop 강연을 읽다

계기는 SpeakerDeck에 공개되어 있던 Practical Harness Engineering — Understanding Steering Loops라는 강연 자료였습니다.

요점은 AI 에이전트의 실행을 events.ndjson과 같은 추가형 로그로 남겨, 모든 제어점을 replay 가능하게 하는 「관측 루프(Observation Loop)」를 만드는 것입니다. PlanGate에는 이미 events.ndjson 기반의 Metrics v1이 있으며, 이를 Trace Timeline / Dogfooding Eval로 발전시킬 구상을 가지고 있었기에, 강연 내용과 자신의 구상을 맞추어 보고 싶었습니다.

여기서부터 기사상에서 5단계로 정리한 디스커션이 시작됩니다.

Round 1-2: Codex로 Steering Loop와 자기 진화 축을 다듬다

첫 2 라운드는 Codex CLI로 진행했습니다. Codex는 「동일한 전제를 공유한 채 심층 분석과 비판을 번갈아 가며 내놓는다」는 특성이 있어, 내부 설계의 세부 사항을 다듬는 데 적합합니다.

Round 1 (Steering Loop 강화 방침): events schema를 v2로 올리는 안을 제시하자, Codex가 「파괴적 변경(breaking change)이 아니라 schema 1.1 additive bump로 충분하다」고 답변했습니다. schema 호환성은 제가 간과했던 부분이었으며, 여기서 방침이 수정되었습니다. 동시에 Trace Timeline v1 + Gate Event Normalization을 신규 PBI(Product Backlog Item)로 기표하는 안이 정리되었습니다.

Round 2 (자기 진화 축의 망라): 「자기 진화」라고 한마디로 말하던 것을 15개 축, 4개 계층으로 분해했습니다. 여기서 Codex가 내놓은 정리가 흥미로웠는데, Steering Loop는 자기 진화의 중심이 아니라 관측·재현의 기반에 불과하다는 결론에 도달했습니다. 중심은 「평가 → 학습 → 거버넌스 (Governance)」라는 루프 쪽이라고 말이죠.

이 시점에서 저는 「Trace Timeline v1을 v8.7.0의 주인공으로 세우면 된다」고 생각했습니다. Round 2의 결론을 Codex 단독으로 도출한 직후였기에 자신감도 있었습니다. 여기까지는 합의 형성 (Consensus building)의 루프입니다.

Round 3: Gemini로 외부 지견과 대조하기

Round 3에서는 지금까지의 결론을 Gemini CLI에 전달하여, 업계 및 학계의 유사 프레임워크와 대조하도록 했습니다. Gemini는 웹 검색을 결합하여 외부 소스를 인용할 수 있으므로, 「우리들의 설계가 업계의 어떤 흐름을 타고 있는가」를 확인하는 용도에 적합합니다.

Gemini로부터는 구체적인 인용과 함께 다음과 같은 대응 관계가 돌아왔습니다.

여기까지는 「업계의 주류와 일치한다」는 긍정적인 대조 결과입니다. 문제는 그 이후로, Gemini가 「PlanGate가 간과하고 있는 관점」으로서 다음 사항들을 「포함해야 한다」고 권장해 온 것입니다.

• OpenTelemetry GenAI Semantic Conventions 준수 (gen_ai.prompt / gen_ai.usage.tokens 등의 표준 속성명)
• Token / Cost attribution의 필수 필드화 (events.ndjson에 토큰 사용량과 모델명을 필수 항목으로 포함)
• LLM-as-a-Judge의 불확실성 관리 (동일한 트레이스 (Trace)를 여러 Judge에 걸쳐 일치율을 산출)

외부 소스 URL과 함께, 모두 업계 사례로서 타당해 보였습니다. 저는 순순히 「이것들은 v8.7.0에 도입하는 것이 좋겠다」고 생각했습니다.

Round 3 종료 시점에는 Gemini의 권장 사항을 전부 반영하는 방향으로 굳어지고 있었습니다.

Round 4: 동일한 Codex에게 Devil's Advocate를 의뢰하기

여기서 의도적으로 경로를 바꿨습니다. Round 3의 Gemini 권장 사항을, Round 1-2와 동일한 Codex에게 「Devil's Advocate (악마의 대변인)로서 비판해 달라」고 전달한 것입니다.

「동일한 에이전트에게 찬성과 반대를 별도의 라운드에서 말하게 하는 것」은 합의 형성 편향 (Consensus bias)을 깨뜨리는 데 효과적이었습니다. Codex의 Devil's Advocate 라운드 결론은 명쾌했으며, Gemini의 권장 사항 중 다음 사항들을 철회 또는 연기해야 한다고 판정했습니다.

• OpenTelemetry GenAI 준수 → 철회. 이유는 PlanGate가 단일 세션 중심이라 분산 트레이싱 (Distributed tracing)이 필요 없는 단계이므로, 독자적인 schema 위에 OTel 호환 레이어 (Layer)를 얹는 유지비가 외부 OSS 가치를 상회하기 때문.
• Token / Cost 필수화 → 철회. 이유는 events.ndjson에 필수 필드를 추가하면 기존 리더 (Reader)가 망가지기 때문. additive 방식으로 「있다면 사용한다」는 것이 타당함.
• multi-judge consensus를 AC에 포함 → 철회. 이유는 현재 PlanGate에 Judge는 C-3/C-4 게이트 2종뿐이라, 일치율을 측정할 대상이 없기 때문.
• "Promising Trace" 플래그 기능 → 연기. Tesla Data Engine의 사상은 이해할 수 있으나, v8.7.0 단계에서 도입하면 「관측 기능」보다 「분류 기능」이 앞서게 되어 목적이 흐려짐.

Devil's Advocate (악마의 대변인) 라운드는 한 걸음 더 나아가, 가상적인 반대 PBI (Product Backlog Item)로서 Run Outcome Review v1 (run 단위의 회고 5개 항목 템플릿: 목적 / 실행 요약 / 실패 지점 / 배움 / 다음 액션)을 역제안해 왔습니다. Trace Timeline이 「관측의 기반」을 제공하는 반면, Run Outcome Review는 「회고의 양식」을 그대로 배포하기 때문에, OSS 이용자에게 가치가 전달되기까지의 거리가 짧다는 주장입니다.

이 시점에서, Round 3에서 「업계 정합성」이라며 납득했던 내용이 절반 이상 뒤집혔습니다. 외부 지견은 권위가 아니라 검증 대상임을 뼈저리게 깨닫게 된 라운드였습니다.

Round 5: 외부 OSS 이용자 관점에서 주축을 재편성하기

Round 4까지의 모든 논의 전제는 「나(저자)의 운용」이었습니다. PlanGate를 OSS로 공개하고 있음에도, 4개 라운드 내내 외부 이용자의 존재가 암묵적이었던 것입니다.

Round 5에서는 Codex에게 「지금까지의 모든 논의가 1인 운용을 전제로 했다는 점을 인정한 상태에서, 신규 OSS 이용자 및 3~10인 규모 팀 도입 관점에서 비판적으로 재평가해 달라」고 요청했습니다.

돌아온 결론 중 특히 뼈아프게 다가온 것은 다음 한 줄이었습니다.

PlanGate의 OSS 가치는 「AI 개발의 안전한 양식을 배포하는 것」이지, 「저자의 운용 로그를 고도화하는 것」이 아니다.

이로써 로드맵의 전제가 무너졌습니다. Codex의 정리 내용에 따르면, 외부 이용자에게 있어 진정한 가치는 다음 3가지이며, Trace Timeline 중심으로는 어느 것도 직접적으로 충족할 수 없습니다.

• 자신의 AI 개발 run이 왜 실패했는지 나중에 설명할 수 있다
• 팀 단위로 plan / review / handoff의 품질을 맞출 수 있다
• PlanGate 자체의 업데이트로 인해 기존 운용이 망가지지 않는다고 판단할 수 있다

그리고 v8.7.0의 최우선 과제 3건으로서, 자기 진화 기능이 아닌 다음 사항들을 주축으로 삼아야 한다고 제안해 왔습니다.

• #226 단계적 도입 가이드 (Level 1: plan 승인만 수행 → Level 5: eval / timeline까지의 단계 정의)
• #224 Plugin 성숙도 향상 (plugin 해결 순서 / prefix / 업데이트 절차 / 중복 install 방지)
• #225 버저닝 안정성 정책 (breaking change vs additive의 정의, 기존 TASK artifact의 처리 방식)

「자기 진화」라는 단어 자체도 외부 표현으로는 run review / timeline / regression check와 같은 실무 어휘로 대체해야 한다는 의견이었습니다.

결론: 로드맵을 Option B에서 Option D로 재편성

Round 5까지의 결론을 반영하여 v8.7.0 milestone을 재편성했습니다. 기존 계획(Option B)과 확정판(Option D)의 차이점은 다음과 같습니다.

주축 3건이 모두 바뀌었습니다. 기존 계획에서 주인공이었던 Trace Timeline v1은 experimental(실험적 기능)로 격하되었고, Run Outcome Review v1은 부차적인 역할로 내려갔으며, 대신 OSS 정비 3건이 P0(최우선 순위)로 올라갔습니다.

로드맵 수정과 README / philosophy에 대한 본질적 가치 메시지 반영은 별도의 PR로 나누어 머지(merge) 완료했으며, 밀려난 PBI는 다음 마일스톤으로 이관했습니다.

실제로 반영한 PR / Issue

멀티 에이전트 토론의 실전 Tips

이 프로세스에서 범용화할 수 있는 실전 Tips 4가지를 추출했습니다.

1. 에이전트의 역할을 처음에 정해둘 것

3종의 에이전트를 「구분하여 사용」했습니다만, 실제로 효과적이었던 것은 역할 분담을 명시한 것이었습니다.

• Claude (Opus 4.7): 통합 및 진행 역할. 답변자라기보다는 각 라운드의 질문을 구조화하고, Codex / Gemini의 답변을 받아 결론을 다음 라운드로 전달하는 입장. 3종을 동등한 답변자로 나열한 것이 아님
• Codex CLI: 심층 분석 및 비판 역할. 동일한 전제를 공유한 채 반복할 수 있으며, Devil's Advocate (악마의 대변인) 역할도 수행 가능
• Gemini CLI: 외부 지식 역할. 웹 검색과 인용 URL을 통해 「업계 사례와의 대조」에 사용

역할을 정하지 않고 3종을 병렬로 던지면, 각각이 「종합적으로 답변하는」 모드로 들어가 차이가 나지 않습니다. 저는 이번에 라운드 시작 전에 Claude 측의 프롬프트로 3종의 역할을 명문화한 뒤 실행했습니다.

2. 「합의 라운드」와 「반증 라운드」를 분리하기

Round 1-3까지는 합의를 쌓아가는 라운드였고, Round 4가 반증 라운드였습니다. 동일한 에이전트에게 연속해서 찬성과 반대를 내놓게 하는 설계는 합의 형성 편향 (Conformity Bias)을 끊는 데 효과적입니다.

특히 Round 4를 「Round 3의 결론을 비판해 줘」라고 명시한 것이 효과적이었습니다. 비판의 대상 범위를 좁히면, Devil's Advocate 라운드가 「전부 반대」로 흐르지 않고, 철회 / 연기 / 유지라는 세 가지 선택지 중 하나로 답해 줍니다.

저는 다음에 Round 4를 「찬성 측 Codex」와 「반대 측 Codex」의 2개 세션으로 나누어, 별도의 컨텍스트 (Context)에서 충돌시켜 볼 생각입니다. 동일 세션 내의 Devil's Advocate보다, 전제 공유가 끊어지는 만큼 반증이 더 날카로워질 것이라는 가설을 검증하고 싶기 때문입니다.

3. 외부 지식은 권위가 아니라 검증 대상으로 다루기

Round 4에서 효과적이었던 것은, 「Gemini의 권장 사항을 그대로 전달하며 비판해 줘」가 아니라, 「우리들의 현실적 제약 (단일 세션 중심 / Judge는 2종뿐 / 1인 운영)을 먼저 명시한 뒤, 그 제약에 비추어 비판해 줘」라고 요청한 것이었습니다. 제약을 먼저 전달하면, Devil's Advocate 라운드가 「전부 반대」가 아니라 「철회 / 연기 / 유지」의 세 가지 선택지로 구체적으로 답해 줍니다.

외부 지식을 그대로 채택하려는 흐름이 생길 때일수록, 저는 「인용이 옳은가」가 아니라 「우리들의 제약에 대해 타당한가」를 별도의 라운드에서 검증하도록 하고 있습니다.

4. 「외부 이용자 관점」은 마지막이 아니라 처음에 넣기

이것은 반성할 점이기도 합니다. Round 5에서 처음으로 「외부 OSS 이용자 관점」을 넣었더니, 논의의 전제가 무너지며 주축이 움직였습니다. 본래는 더 이른 단계, 가능하다면 Round 1에서 「이것은 누구를 위한 기능인가」를 확정해 두었어야 했습니다.

OSS의 기능 설계에서 논의를 진행한다면, 첫 라운드에서 「제작자 개인 최적화 vs 외부 이용자 가치」의 판별 축을 명시해 두면 후반부에 전제 붕괴를 일으키지 않고 넘어갈 수 있습니다. 저는 다음부터 Round 1의 프롬프트 서두에 「이 기능은 누구의, 어떤 과제를 해결하는가」를 필수 항목으로 작성하고, 각 라운드의 결론을 그 축으로 반드시 한 번씩 대조하는 운용을 할 생각입니다.

마치며

5 라운드의 디스커션(Discussion)을 통해, 저는 v8.7.0의 주축을 Trace Timeline에서 OSS 정비로 재편했습니다. 표면적인 결과는 「마일스톤의 재편」이지만, 본질적으로 얻은 것은 **「합의보다 서로 다른 관점을 가치로 만드는 논의 방법」**이었습니다.

에이전트를 「편리한 상담 상대」로서 1종만 사용하면 합의는 빨리 이루어지지만 전제는 무너지지 않습니다. 역할을 나눈 3종에게 합의 라운드와 반증 라운드를 설계하여 돌리면, 자신이 놓치고 있었던 전제 그 자체에 도달할 수 있습니다.

이 프로세스는 어떤 OSS / 프로덕트 설계에도 응용할 수 있다고 느낍니다. 다음에 중요한 설계 판단을 내릴 때도 같은 패턴으로 논의를 구성할 생각입니다.