모호한 엔지니어링 문제를 해결하기 위해 AI 위원회(AI Councils)를 활용하는 방법

소프트웨어 아키텍처 및 전달을 위한 실용적인 AI 위원회(AI Council) 워크플로우

하나의 AI 어시스턴트는 유용하지만, 항상 충분한 것은 아니다

자동 완성(autocomplete) 이상의 용도로 AI 코딩 어시스턴트를 사용해 보았다면, 아마 다음과 같은 패턴을 발견했을 것입니다. 단일 모델 워크플로우(single-model workflows)는 빠르게 수렴합니다. 때로는 너무 빠르게 말이죠.

당신은 문제를 설명합니다. 모델은 해결책을 제안합니다. 그 해결책은 합리적으로 보입니다. 당신은 그것을 구현합니다. 그러다 3일 후, 리뷰나 통합 과정에서 아키텍처가 경계 조건(boundary condition)을 고려하지 않았거나, 더 간단한 대안이 존재했거나, 혹은 설계가 분리되어 있어야 할 두 가지 요소를 결합(coupled)했다는 사실을 발견하게 됩니다.

이것은 모델의 실패가 아닙니다. 프로세스의 실패입니다. 단일 모델은 — 아무리 능력이 뛰어나더라도 — 자신의 프레임워크 안에서 조기에 결론을 내리고 그 안에서 정교화(refine)를 진행할 수 있습니다. 두 번째 엔지니어가 하는 것처럼 자신의 가정을 스스로 의심하지 않을 수 있습니다.

소스 기반 코딩 에이전트(Source-grounded coding agents) — Qoder, Codex, Claude Code, Cursor, Devin, Copilot Agent 또는 이와 유사한 에이전트형 코딩 환경(agentic coding environments)과 같은 도구들 — 는 실제 코드베이스 내에서 작동하기 때문에 매우 강력합니다. 이들은 저장소(repository) 내에서 작업하고, 관련 파일을 검사하며, 가시적인 컨벤션(conventions)을 따르고, 환경이 지원하는 경우 검증 명령을 실행할 수 있습니다. 하지만 소스 그라운딩(source grounding)이 아키텍처의 사각지대를 제거해주지는 않습니다. 이는 모델이 _무엇이 존재하는지_를 알고 있다는 의미일 뿐입니다. 모델이 _현재 존재하는 것이 당신이 다음에 구축하려는 것에 적합한 기반인지_를 의심할 것이라는 보장은 없습니다.

모호한 엔지니어링 문제 — 횡단적 리팩토링(cross-cutting refactors), 불분명한 소유권 경계(ownership boundaries), 복잡한 기능에 대한 사양 작업(specification work) — 를 해결할 때, 하나의 어시스턴트만으로는 항상 충분하지 않습니다. 모델이 나빠서가 아니라, 비판(critique)은 제안(proposal)과는 별개의 기능이기 때문입니다.

더 진행하기 전에, 이것은 AI 위원회(AI councils)가 완전히 새로운 아이디어라는 주장은 아닙니다.

이러한 더 넓은 패턴은 이미 다양한 형태로 존재합니다: LLM 위원회(LLM councils), 멀티 에이전트 토론(multi-agent debate), 역할 기반 리뷰(role-based review), 자기 비판 워크플로우(self-critique workflows), 그리고 멀티 에이전트 소프트웨어 개발 시스템(multi-agent software development systems) 등이 그것입니다. 제가 여기서 설명하고자 하는 것은 이보다 더 좁고 실용적인 범위, 즉 제가 소프트웨어 아키텍처(architecture) 및 전달(delivery) 작업을 위해 이 아이디어를 어떻게 운영(operationalizing)해 왔는지에 대한 것입니다.

유용한 질문은 "여러 모델이 동일한 문제를 검토할 수 있는가?"가 아닙니다. 우리는 이미 그것이 가능하다는 것을 알고 있습니다.

진정으로 유용한 질문은 이것입니다: 어떻게 하면 이를 명확한 역할(roles), 중단 기준(stop criteria), 소스 근거(source grounding), 구현 분리(implementation separation), 감사(audit), 그리고 인간의 거버넌스(human governance)를 갖춘 반복 가능한 엔지니어링 워크플로우(engineering workflow)로 전환할 것인가?

이 포스트에서 "AI 위원회(AI council)"는 특별한 플랫폼을 의미하지 않습니다. 이는 단순히 의도적으로 서로 다른 역할을 가진 여러 AI 컨텍스트(contexts)가 동일한 제안을 검토하는 것을 의미합니다.

제가 이 워크플로우를 우연히 발견하게 된 과정

저는 거창한 전략이 아니라 필요에 의해 처음으로 여러 AI 모델을 상담하기 시작했습니다.

직접적인 계기는 토큰(token) 및 컨텍스트(context) 제한이었습니다. 저는 에이전트 기반 코딩 환경(agentic coding environment)에서 복잡한 사양(specification) 작업을 하고 있었는데, 컨텍스트 창(context window)이 가득 차고 있었습니다. 문제 설명 전체와 기존 코드베이스(codebase)의 컨텍스트, 그리고 의미 있는 피드백을 주고받는 비판(critique) 과정을 단일 세션에 모두 담을 수 없었습니다. 그래서 저는 다른 모델들에게 제안의 조각들을 독립적으로 검토해 달라고 요청하기 시작했습니다.

초기 과정은 엉망이었습니다. 코딩 에이전트의 아키텍처 제안을 다른 모델에 복사한 뒤 "이것의 문제점이 무엇인가요?"라고 묻고, 그 응답을 다시 복사해 가져왔습니다. 때로는 제 에이전트의 접근 방식이 확립된 패턴과 일치하는지 확인하기 위해 생소한 분산 시스템(distributed systems) 개념에 대해 다른 모델에게 묻기도 했습니다. 때로는 또 다른 모델에게 트레이드오프(trade-off) 결정에 대해 악마의 대변인(devil's advocate) 역할을 해달라고 요청하기도 했습니다.

일관된 순서도 없었습니다. 정의된 역할도 없었습니다. 중단 기준도 없었습니다. 피드백은 무작위 순서로 들어왔습니다. 이견(objections)은 일관되게 추적되지 않았습니다. 대화는 너무 길어질 수 있었습니다. 저는 충분히 들었다고 느껴질 때까지, 혹은 창 사이를 복사해서 붙여넣는 것에 인내심이 바닥날 때까지 작업을 계속하곤 했습니다.

하지만 이러한 혼란스러운 상태에서도 저는 한 가지 사실을 발견했습니다. 최종 사양(specs)이 더 좋아졌다는 점입니다. 미미하게 좋아진 수준이 아니라, 눈에 띄게 좋아졌습니다. 외부 비판(external critique)을 다시 입력하면 제 코딩 에이전트(coding agent)의 제안이 의미 있는 방식으로 변화했습니다. 가설(Assumptions)들이 표면화되었습니다. 더 단순한 대안들이 나타났습니다. 엣지 케이스(Edge cases)들이 구현 단계가 아닌 감사(audit) 단계 이전에 포착되었습니다.

서로 다른 모델들은 서로 다른 사각지대(blind spots)를 드러냈습니다. 프로세스는 작동했습니다. 단지 구조(structure)가 필요했을 뿐입니다.

진짜 통찰: 더 많은 모델의 문제가 아니었다

여러 차례 실행해 본 결과, 개선은 _더 많은 모델_로부터 오는 것이 아니라는 점을 깨달았습니다. 네 개의 모델이 모두 "좋아 보입니다"라고 말하는 것은 아무런 도움이 되지 않습니다. 모델의 수만 늘리는 것은 오히려 노이즈(noise)를 생성할 수 있습니다.

개선은 다음과 같은 구체적인 구조적 특성에서 비롯되었습니다:

역할 분리 (Role separation): 각 외부 모델은 비판자(critic), 단순화 도구(simplifier), 시스템 사고가(systems thinker)와 같이 암묵적으로 서로 다른 역할을 수행하고 있었습니다. 이러한 역할을 명시적으로 지정했을 때 피드백은 더욱 날카로워졌습니다.
구조화된 비판 (Structured critique): "이것을 검토해줘"라고 요청하면 모호한 응답이 생성됩니다. 반면 "이 제안에서 가장 큰 세 가지 아키텍처 리스크(architectural risks)를 식별해줘"라고 요청하면 실행 가능한(actionable) 피드백이 생성됩니다.
이의 제기 추적 (Objection tracking): 기록부(ledger)가 없으면 피드백은 유실됩니다. 이의가 제기되었다가 조용히 묻혀버리곤 합니다. 추적(Tracking)은 문제 해결을 강제합니다.
일급 시민으로서의 합성 (Synthesis as a first-class step): 다섯 개의 응답을 수동으로 조정하는 것은 소모적이며 오류가 발생하기 쉽습니다. 합성을 명시적인 작업으로 만들고, 실제 코드베이스를 바탕으로 주장을 검증할 수 있는 소스 기반 에이전트(source-grounded agent)가 이를 수행하게 함으로써, 합성을 신뢰할 수 있는 프로세스로 전환했습니다.
소스 그라운딩 (Source grounding): 합성 에이전트는 현실에 기반하여 검증합니다. 외부 모델은 추측(speculate)하지만, 소스 기반 에이전트는 코드 내에서 실제로 무엇이 사실인지 확인합니다.
별도 단계로서의 구현 감사 (Implementation audit as a separate phase): 코드를 작성하는 것과 코드를 검토하는 것은 서로 다른 인지 모드(cognitive modes)입니다. 이들을 서로 다른 컨텍스트(contexts)로 분리하면 독립성이 유지됩니다.
인간 거버넌스 게이트 (Human governance gates): 인간이 모든 것을 수동으로 합성하지는 않습니다.

하지만 언제 멈출지, 언제 진행할지, 그리고 어떤 리스크를 수용할지는 인간이 결정합니다.

"가치는 더 많은 모델을 요구하는 데 있지 않았습니다. 가치는 AI 사용을 관리되는 엔지니어링 워크플로우 (engineering workflow)로 전환하는 데 있었습니다."

이러한 차이는 중요합니다. "AI 브레인스토밍 (AI brainstorming)"은 쉽게 무시될 수 있습니다. 하지만 정의된 역할, 추적된 이의 제기 (objections), 합성 작업 (synthesis operations), 그리고 거버넌스 게이트 (governance gates)를 갖춘 엔지니어링 프로세스는 추론하고, 개선하며, 신뢰할 수 있는 대상입니다.

하나의 다이어그램으로 보는 워크플로우

문제 정의 (Problem Statement)
  → 소스 기반 아키텍트 에이전트 (Source-Grounded Architect Agent)
    → AI 위원회 역할 기반 비판 (AI Council Role-Based Critique)
...

단계별 세부 분석:

문제 정의 (Problem Statement) — 인간이 문제를 명확하게 정의합니다. 이는 다른 모든 단계의 입력값이 됩니다.
소스 기반 아키텍트 에이전트 (Source-Grounded Architect Agent) — 전체 리포지토리 (repository) 접근 권한을 가진 코딩 에이전트가 아키텍처 옵션, 트레이드오프 (trade-offs), 그리고 검토를 위해 명시적으로 표시된 미결 질문들을 포함한 초기 제안서를 생성합니다.
AI 위원회 역할 기반 비판 (AI Council Role-Based Critique) — 각 위원회 역할(별도의 컨텍스트 또는 창에서)은 동일한 제안서를 전달받고, 자신에게 할당된 관점을 통해 이를 검토합니다. 응답은 역할 라벨이 유지된 상태로 수집됩니다.
피드백 합성 (Feedback Synthesis) — 모든 위원회 응답은 소스 기반 에이전트에게 다시 전달되며, 에이전트는 피드백을 비판적으로 평가하여 합의 사항, 충돌 사항, 그리고 실행 가능한 항목들을 식별합니다.
이의 제기 원장 + 미결 질문 (Objection Ledger + Open Questions) — 이의 제기 사항은 상태, 심각도, 해결 여부와 함께 추적됩니다. 새로운 이의 제기가 추가되거나, 해결된 항목은 표시됩니다.
인간 거버넌스 게이트 (Human Governance Gate) — 인간이 원장을 검토하고 결정합니다: 여전히 차단 요소가 되는 이의 제기가 남아 있는가? 의미 있는 미결 질문이 있는가? 만약 그렇다면, 위원회 단계를 한 번 더 반복합니다. 그렇지 않다면, 명세(spec) 단계로 진행합니다.
명세 + 구현 계획 (Spec + Implementation Plan) — 아키텍트 에이전트는 수용된 모든 피드백과 해결된 이의 제기 사항을 반영하여 명세와 계획을 작성합니다.
실행 에이전트 (Executor Agent) — 별도의 컨텍스트가 계획을 구현합니다. 이 컨텍스트는 설계 논쟁이 아닌 순수하게 구현에만 집중합니다.

Auditor Agent (감사 에이전트) — 또 다른 별도의 컨텍스트가 승인된 사양(spec) 및 계획에 따라 구현 내용을 감사합니다. 독립적인 검토를 수행합니다.

Audit-Driven Remediation (감사 기반 수정) — 감사 결과에 따라 변경이 필요한 경우, 해당 내용은 다시 실행자(executor)에게 전달됩니다. 인간이 이 루프를 승인합니다.
Human Final Approval (인간의 최종 승인) — 인간이 최종 상태를 검토하고 커밋(commit), PR(Pull Request) 생성, 또는 배포(ship) 여부를 결정합니다.

역할 모델 (The Role Model)

역할	일반적인 도구	목적	출력물
Source-Grounded Architect (소스 기반 설계자)	리포지토리 접근 권한이 있는 에이전트 기반 코딩 환경	소스에 기반한 제안서 작성, 피드백 합성, 사양(spec) 작성	초기 제안서, 합성 보고서, 사양(spec) + 계획
...

도구에 관한 참고 사항: Qoder, Codex, Claude Code, Cursor, Devin, Copilot Agent 또는 이와 유사한 에이전트 기반 환경은 리포지토리를 조사하고, 코드에 대해 추론하며, 파일을 편집하고, 검증 명령을 실행하며, 별도의 작업 컨텍스트를 지원할 수 있다면 소스 기반 역할을 수행할 수 있습니다. 위원회 검토자(council reviewer) 역할은 역량 있는 모든 AI 모델이 수행할 수 있습니다.

역할 할당에 관한 참고 사항: 동일한 기본 모델이 여러 역할을 맡을 수 있습니다. 중요한 것은 각 역할이 자신만의 컨텍스트에서 작동한다는 점입니다. "비판적 검토자(Critical Reviewer)" 역할을 수행하는 모델은 동시에 "설계자(Architect)" 컨텍스트를 보유해서는 안 됩니다. 역할 분리는 N개의 서로 다른 모델 제공자를 요구하는 것이 아니라, 관점의 독립성을 보존하는 것에 관한 것입니다.

이의 제기 장부 (The Objection Ledger)

이것이 바로 AI의 논의를 엔지니어링 거버넌스(engineering governance)로 전환하는 요소입니다. 추적(tracking)이 없다면 피드백 루프는 순환 논리에 빠지게 됩니다. 이의 제기가 제기되고 논의되지만, 해결 없이 조용히 묻혀버리곤 합니다. 이의 제기 장부는 피드백이 모호한 의견 교환으로 변질되는 것을 방지합니다. 이의 제기를 명시적이고, 추적 가능하며, 해결 가능한 상태로 만듭니다.

위원회 단계 동안 제기된 모든 이의 제기는 다음과 같이 기록됩니다:

ID	이의 제기 (Objection)	제기자 (Raised By)	심각도 (Severity)	상태 (Status)	해결책 (Resolution)	근거 (Rationale)
OBJ-001	X와 Y 사이의 결합(Coupling)으로 인해 배포 의존성 발생	Critical Reviewer	High	Resolved	어댑터 경계(adapter boundary) 도입	런타임 오버헤드 없이 배포를 분리(Decouples)함
...

상태 (Statuses):

Open (미결) — 제기되었으나 아직 처리되지 않음
Accepted (수락) — 이의 제기가 타당함; 변경 사항이 적용될 예정임
Rejected (거부) — 이의 제기를 검토했으나 채택하지 않음 (근거 필요)
Deferred (보류) — 타당하지만 이번 반복(iteration) 범위에서는 명시적으로 제외됨
Resolved (해결) — 수락되었으며 그에 따른 변경 사항이 완료됨

위원회 라운드(Council rounds)가 종료되는 조건:

차단 요소가 되는 미결 질문(open questions)이 남아있지 않을 때
해결되지 않은 심각한 이의 제기가 남아있지 않을 때
수락된 이의 제기에 대한 상응하는 변경 사항이 제안서에 반영되었을 때
거부된 이의 제기에 대해 문서화된 근거가 있을 때
보류된 항목이 범위 외(out of scope) 또는 향후 과제로 명시적으로 표시되었을 때

6개월 후, 여러분은 이 원장(ledger)을 살펴보고 아키텍처가 왜 현재와 같은 모습인지 이해할 수 있습니다. 이것은 단순한 프로세스 오버헤드가 아니라, 감사가 가능한 의사결정 기록(auditable decision record)입니다.

인간이 루프 안에 있지만, 통치자(Governor)로서 존재함

멀티 모델 워크플로(multi-model workflows)에 대한 흔한 오해는 인간이 복사-붙여넣기의 병목 구간이 된다는 것입니다. 즉, 다섯 개의 응답을 수동으로 읽고, 정신적으로 충돌을 조정하며, 제안서를 직접 손으로 다시 쓰는 상황을 말합니다.

이 방식은 그렇게 작동하지 않습니다.

소스에 근거한 에이전트(source-grounded agent)가 합성(synthesis)을 수행합니다. 에이전트는 모든 위원회 응답을 읽고, 합의 사항과 충돌 사항을 식별하며, 실제 코드베이스를 바탕으로 각 이의 제기를 평가한 뒤, 구조화된 합성 보고서(synthesis report)를 생성합니다. 인간은 무엇도 수동으로 조정할 필요가 없습니다.

인간이 책임지는 영역은 다음과 같습니다:

위원회 피드백이 충분한 시점을 결정하는 것 — 반복(iteration)을 언제 중단할 것인가
명세서(spec) 작성 단계로의 전환을 승인하는 것 — 방향성을 확정하기 위한 최종 승인(green light)
감사(audit) 후 수정 사항을 승인하는 것 — 무엇을 수정하고 무엇을 연기할지 결정
감사 회차를 몇 번까지 진행할지 결정하는 것 — 수확 체감(diminishing returns)의 법칙이 존재함
최종 결과물에 대한 리스크를 수용하는 것 — 모든 책임은 여기서 끝남

"AI가 대부분의 작업을 수행합니다. 인간은 게이트(gates)를 소유합니다."

이는 '수동 작업자로서의 인간'보다는 '엔지니어링 매니저(engineering manager)로서의 인간'에 더 가깝습니다. 당신은 종합(synthesis)을 수행하는 것이 아닙니다. 당신은 프로세스를 거버넌스(governing)하고 결과물에 대한 책임을 수용하는 것입니다.

설계자(Architect), 실행자(Executor), 감사자(Auditor)를 분리하는 이유

이것은 이론적인 결정이 아니라 실무적인 결정입니다.

설계자(Architect) 컨텍스트는 추론 과정을 축적합니다: 원래의 문제, 위원회 피드백, 종합 보고서(synthesis reports), 이의 제기 대장(objection ledger), 그리고 설계 근거(design rationale) 등이 포함됩니다. 이 컨텍스트는 좋은 명세서(spec)를 작성하는 데 필수적이지만, 구현(implementation) 세션에 포함되면 혼란을 줄 수 있습니다.

실행자(Executor) 컨텍스트는 승인된 명세서(spec)와 계획을 바탕으로 새롭게 시작합니다. 이는 순수하게 구현(implementation) — 파일 변경, 테스트 작성, 통합(integration) — 에만 집중합니다. 설계에 대한 논쟁은 없습니다. "접근 방식을 재고해야 할까요?"와 같은 질문도 없습니다. 명세서(spec)는 곧 명세서(spec)일 뿐입니다.