이전 기사: https://zenn.dev/satoh_y_0323/articles/c03402ef534316

C3 GitHub: https://github.com/satoh-y-0323/claude-code-conductor / PyPI: https://pypi.org/project/claude-code-conductor/ / 공식 문서: https://satoh-y-0323.github.io/claude-code-conductor/

본 기사의 범위: 직접 만든 멀티 에이전트 프레임워크(Multi-agent Framework) C3 (Claude Code Conductor)의 v2.32.0 이후 (v2.33.0 / v2.34.0) 이야기입니다. 메인은 v2.34.0에서 추가한── 구현에 들어가기 전에, 설계와 계획을 design-critic이 검토하도록 하는 것입니다.

제3자로서 적대적으로 의심하는 감사 에이전트입니다. 계기는 X(구 Twitter)에서 흘러나온 한 편의 블로그였습니다. 직접 만들어 보았더니, 그 「의심꾼」이 첫 업무에서 저 자신의 설계 허점을 8개나 찾아내었기에 그 전말을 적어보려 합니다.

서론 ── 「구현에 들어가서야 깨닫는 것」을 없애고 싶다

C3로 무언가를 만들 때, 워크플로우는 /start 명령으로 **히어링(Hearing) → 설계(Design) → 계획(Planning) → 구현(Implementation) → 리뷰(Review)**가 하나로 이어져 있습니다. 각 페이즈의 구분점에서 승인 게이트(Approval Gate)가 들어가는 것이 기본 구조입니다.

이 플로우를 저 자신도 자주 사용합니다만, 몇 번 해보며 깨달은 약점이 있었습니다. 설계하고, 계획하고, 막상 구현에 들어가고 나서야 「아, 여기를 다 채우지 못했네」라며 조정이 발생하는 것입니다. 전제가 무너져 있거나, 요구사항(Requirement)의 해석이 갈리거나, 계획에 태스크(Task)가 하나 빠져 있거나 하는 식입니다. 본래라면 설계·계획 단계에서 없앴어야 할 재작업(Rework)입니다.

코드에 대해서는 C3에 code-reviewer / security-reviewer라는 「작성된 것을 제3자가 공격하는」 에이전트가 있습니다. 하지만 설계나 계획에 대해서는 그 "공격하는 역할"이 없었습니다. 인터뷰어(Interviewer)도 아키텍트(Architect)도 설계를 만드는 쪽이기 때문에, 자신의 설계 허점은 구조적으로 보이지 않습니다.

그때, 딱 적절한 자극이 외부에서 찾아왔습니다.

계기 ── X에서 평가받던 「자동화된 의구심」

어느 날 아침, 사용자(즉, 이 C3를 함께 키워나가는 동료나 저 자신)로부터 "X의 포스트에서 이 블로그가 실무에서 효과적이라고 평가받고 있다. 영어라 잘 모르겠지만 궁금하다"라며 URL 하나를 전달받았습니다.

'My Automated Doubt Development Process'라는 기사였습니다. 요지는 다음과 같습니다 ──

AI에게 너무 자유롭게 코드를 쓰게 하여 「AI 지원 개발에 대한 신뢰」를 잃었다. 그것을 되찾기 위해, "의심하는 것(Doubt)"을 인간이 하는 대신, 여러 전문 에이전트에게 자동으로 시킨다. 설계 페이즈에서는 "Assumption Excavator(전제 발굴자)" · "Gap Analyzer(공백 분석가)" · "Ambiguity Mapper(모호성 매퍼)"와 같은 전문 서브 에이전트가 사양(Specification)을 다각도로 감사하여, 구현 전에 허점을 씻어낸다.

읽는 순간 든 생각은 "이거, C3가 계속 해왔던 것의 설계 페이즈 버전이다"였습니다. C3는 원래 「AI의 성과물을 다른 AI가 의심하게 만드는」 검증 루프(Verification Loop)의 집합체입니다. 코드에는 리뷰어(Reviewer)가 있습니다. 그렇다면 설계·계획에도 "의심꾼"을 두면 된다. 이전 기사에서 "향후 개선은 자신의 푸시가 아니라 사용하는 사람의 체감을 기점으로 하겠다"라고 썼는데, 바로 그 말대로 외부의 자극이 기점이 되었습니다.

다만, 본론에 들어가기 전에 작은 릴리스 이야기를 하나 더 하겠습니다.

전채 요리: v2.33.0 ── 「만약을 위해 써두었던 한 줄」을 지우기

design-critic 이전에, v2.33.0라는 수수한 정리 릴리스를 거쳤습니다. 이것도 일단 「의심하는」 이야기이므로 가볍게 다루겠습니다.

C3에는 「승격 규칙(Promotion Rule)」이라는 메커니즘이 있어서, .claude/rules/promoted/에 둔 규칙이 Claude Code에 상시 로드됩니다. 이를 배포하는 CLAUDE.md의 말미에, 오랫동안 ** @rules/promoted/index.md를 @import 하는 한 줄**과 「이곳은 수동으로 편집하지 말 것」이라는 주석을 적어두었습니다.

그런데 Claude Code의 공식 사양을 확인해보니, .claude/rules/는 서브 디렉토리를 포함하여 재귀적으로 자동 로드된다는 것이었습니다. 즉

@import를 쓰지 않아도, rules/promoted/ 안의 내용은 자동으로 context에 포함됩니다. 즉, **굳이 import를 하는 한 줄은 불필요한 코드(redundant)**였던 셈입니다. 게다가 "파일 전체가 c3 update로 덮어씌워지는 배포물"인데, 특정 섹션에만 "수동 편집 금지"라고 적어두는 것은 오히려 오해를 불러일으킬 수 있습니다. "아마 필요 없을 것"이라며 그냥 지우기에는 위험하므로, 검증 환경에서 실제로 /context를 출력하여, @import 없이도 승격 규칙(promoted rules)이 제대로 로드되고 있음을 눈으로 확인한 뒤에 제거했습니다 (v2.33.0). "만약을 위해 적어두었던 방어적인 한 줄"이 사실은 사양을 이중화하고 있었을 뿐이라는 이야기는 흔히 있는 일입니다. 동작은 완전히 불변이며, 파괴적 변경(breaking change)은 없습니다.

...라는 정리를 마치고, 본론으로 들어가겠습니다.

본론: v2.34.0 design-critic ── 설계·계획의 「의심꾼」을 추가하다

무엇을 만들었는가

블로그의 수법을 그대로 전부 이식하면 무거워지기 때문에, C3의 규모에 맞춰 덜어냈습니다. 만든 것은 1체의 read-only 서브 에이전트 design-critic과, 이를 호출하는 **감사 게이트(audit gate)**입니다.

design-critic은 요구사항·설계·계획 리포트를 읽고, **3가지 렌즈(lens)**로 적대적 감사를 수행합니다.

• 전제 발굴 [DC-AS] ── 암묵적인 전제를 열거하고, 그것이 요구사항·설계·기존 코드에 의해 뒷받침되는지 확인합니다. 뒷받침되지 않는 전제는 구현 중에 무너집니다.
• 모호성 [DC-AM] ── 구현자가 해석에 따라 갈릴 수 있는 기술. 여러 가지 읽기 방식이 성립하는 요구사항·설계.
• 누락 [DC-GP] ── 요구사항 ↔ 설계 ↔ 계획 간의 추적성(traceability) 결여. 요구사항에는 있는데 계획 태스크에는 없는 경우, 에러 처리가 빠져 있는 경우 등.

블로그에서는 여러 에이전트로 나누었지만, C3에서는 1체에 3가지 렌즈를 집약했습니다. 같은 리포트를 3번 읽게 하는 것은 토큰 낭비이며, 개인 개발 규모라면 이 정도로 충분합니다. 배치는 계획 단계(C) 직후 · 구현(D) 직전에, opt-in(매번 필수 사항이 아니라 중요한 변경이 있을 때만 끼워 넣을 수 있는 방식) 게이트로서 넣었습니다.

사용자의 한마디로 설계의 구멍 하나가 메워졌다

이 부분이 이번에 가장 좋았던 순간입니다.

처음에 저는 게이트의 설계를 "design-critic이 구멍을 발견하면, 계획 단계(planner)로 되돌려 수정한다"라고만 생각했습니다. 그것을 설명했더니, 사용자로부터 다음과 같은 답변이 돌아왔습니다.

"내용에 따라 다르겠지만, 요구사항에는 포함되어 있었으나 설계에서 누락이나 모호함이 발생한 경우라면, planner의 계획 단계로 되돌려도 설계의 누락은 수정할 수 있지 않을까요?"

……맞는 말이었습니다. 설계 기인 문제를 계획 단계로 되돌려도, planner는 설계를 고치지 않습니다. 근본적인 문제가 고쳐지지 않는 것이죠. 저의 초기 안에는 허점이 있었습니다.

흥미로운 점은, 이 자체가 「자동화된 의구심」을 인간이 수행하고 있는 구도라는 것입니다. design-critic이라는 도구를 설계하는 도중에, 사용자가 저의 설계를 의심하여 진짜 결함을 하나 찾아낸 것입니다. 승인 게이트에서 대화한다는 C3의 기본 구조가 효과를 발휘한 순간이었습니다.

이 지적을 받고, 설계를 **「층별 라우팅(layered routing)」**으로 수정했습니다. 각 발견 사항(finding)에 기인 층(A 요구사항 < B 설계 < C 계획) 태그를 붙여서,

• 요구사항 기인이라면 → **페이즈 A (interviewer)**로
• 설계 기인이라면 → **페이즈 B (architect)**로
• 계획 기인이라면 → **페이즈 C (planner)**로

와 같이, 문제가 발생한 층으로 핀포인트로 되돌립니다. 설계의 구멍은 설계 층에서 고쳐지고, 계획도 연쇄적으로 다시 만들어집니다. code-reviewer가 발견한 코드 문제를 코드 층에서 고치는 것과 같은 논리를 설계·계획에도 적용한 것입니다.

그리고 첫 업무 ── 자기 자신의 설계 구멍을 8개나 찾아내다

구현을 마치고, 수락 기준(acceptance criteria)으로서 "실제로 design-critic을 한 번 실행하여, 3가지 렌즈의 지적이 제대로 나오는지, 층별 라우팅이 작동하는지"를 확인하기로 했습니다.

대상은 design-critic 자신의 설계·계획 리포트로 정했습니다. 이른바 도그푸딩(dogfooding)입니다. 스스로를 스스로 감사하게 만드는 것이죠.

그 결과, design-critic은 자기 자신의 설계 구멍을 8건 찾아냈습니다.

• 전제 발굴 (Premise Discovery)에서 3건, 모호함 (Ambiguity)에서 2건, 누락 (Omission)에서 3건 ──
  3가지 렌즈(Lens) 모두에서 지적이 나옴 - 원인 계층도 A요건 2건, B설계 4건, C계획 2건으로,
  A/B/C에 제대로 배분함 (계층별 라우팅 (Layered Routing)이 실제 데이터에서 작동함을 증명)

게다가 내용이 진짜였습니다. 예를 들어 ──

" (누락·계획 원인) ── 방치하면 리포트가 계속 쌓이게 될, 진짜 버그. 즉시 수정 필요. /start

의 아카이브 처리 과정에, design-critic이 내는 리포트 (design-review-report)가 포함되어 있지 않음" -
"최상류 계층으로 되돌린다(Return to the highest upstream layer)라고 한 문장으로 적혀 있지만, '허용된 지적(Allowed指摘)'의 계층은 되돌아갈 목적지에 영향을 미치는지 모호함" (모호함·설계 원인) ── 구현자 (LLM)의 해석에 따라 갈릴 여지. 한 문장을 추가하여 명확화. -
"design-critic은 신규 에이전트이므로, (전제 발굴·설계 원인) ── c3 update

를 한 직후의 세션에서는 "등록되지 않아 기동할 수 없는 것"이 아닌가?"

마지막 것이 특히 효과적이었습니다. 사실 시험 운행을 하려고 design-critic을 호출했더니, 정말로 Agent type 'design-critic' not found 에러가 뜨며 기동할 수 없었습니다. Claude Code는 세션 시작 시에 에이전트 정의를 읽어오기 때문에, 현재 세션에서 새로 생성한 에이전트는 해당 세션에서 사용할 수 없습니다. 다음 세션부터 유효해집니다.

이는 배포 대상 사용자에게도 발생합니다. c3 update로 design-critic이 내려오더라도, 해당 세션에서는 작동하지 않으며 재기동해야 비로소 사용할 수 있습니다. design-critic 스스로가 이 전제의 붕괴를 '전제 발굴' 렌즈로 지적해냈다는 것은 너무나 완벽한 상황이었습니다 (시험 운행은 어쩔 수 없었기에, 제가 design-critic의 페르소나를 입고 대신 수행했습니다). 이 주의 사항은 CHANGELOG와 릴리스 노트에 명시해 두었습니다.

설계의 구멍을 메우기 위해 만든 기능이, 첫 업무에서 자신의 설계 구멍을 8개나 찾아냈다. 기능의 의의를 기능 스스로가 증명해 준 격입니다. 가벼운 3건은 그 자리에서 수정했고, 나머지도 기록했습니다.

업무·개인 개발에 활용할 수 있는 점

1. 「만드는 쪽」과 「의심하는 쪽」을 나누면 효과적이다

설계를 만든 본인은 자신의 설계 구멍이 보이지 않습니다. 이는 능력의 문제가 아니라 구조의 문제입니다. 따라서 "만드는 역할"과 "의심하는 역할"을 별개의 인격(별도의 에이전트·별도의 리뷰어)으로 나누는 것만으로도 보이는 구멍이 늘어납니다. 팀 리뷰가 효과적인 것과 같은 이치를 설계·계획 같은 상류 단계에도 가져올 수 있습니다. AI를 사용한다면 더욱이 "같은 모델에게 자기 채점을 시키지 않는" 설계가 효과적입니다.

2. 지적은 「올바른 계층」으로 되돌리지 않으면 고쳐지지 않는다

리뷰에서 구멍이 발견되었을 때, 그것을 어느 공정으로 되돌릴지를 틀리면 아무리 고쳐도 근본적인 문제가 남습니다. 설계 원인을 구현 담당자에게 통째로 떠넘겨도 대증요법에 불과합니다. 문제가 발생한 계층까지 거슬러 올라가 되돌려야 합니다. 당연해 보이지만, 서두르다 보면 가장 하류(가까운 곳)로 떠넘기기 쉬운 부분입니다. 이번에는 사용자의 한마디 덕분에 이 구멍을 깨달을 수 있었습니다.

3. 만든 검증 도구는 먼저 자신을 향하게 한다

새로운 리뷰 메커니즘이나 체크 도구를 만들었다면, 첫 번째 대상으로 「그 자체의 설계·성과물」을 설정하십시오. 도그푸딩 (Dogfooding)은 동작 확인과 가치 검증을 동시에 할 수 있으면서도, 가장 가차 없는 대상입니다. 이번에 design-critic을 자신에게 향하게 했더니, 진짜 버그(아카이브 누락)와 운용상의 치명적인 주의 사항(세션 재기동)이 모두 나왔습니다. 외부에 내놓기 전에 스스로 먹어보는 것입니다.

4. 외부의 자극을 자신의 문맥으로 번역한다

계기는 「X(구 트위터)에서 평가받던 영어 블로그」였습니다. 그대로 전부 따라 하기에는 너무 무겁습니다 (다중 에이전트·40개 규모의 이야기도 있음). 자신의 프레임워크 규모와 기존 구조에 맞춰 번역하고, 효과적인 부분만 골라냅니다 (3가지 렌즈를 하나로 집약·기존 승인 플로우에 탑승). 자극을 통째로 삼키지 말고, 자신의 문맥에 맞게 사이즈를 조절하십시오.

5. 「만약을 위한 한 줄」은 사양을 확인하고 삭제한다

v2.33.0의 @import 제거 사례처럼, 「만약을 위해」 혹은 「방어적으로」 작성한 설정이 사실은 공식 사양과 중복되어 있는 경우가 자주 있습니다. 무서워서 삭제하지 못하고 남겨두기 쉽습니다. 하지만 1차 사양을 확인하고, 실제 기기에서 동작을 살펴본 뒤, 중복이라는 것을 알게 되었다면 당당하게 삭제하십시오. 설정 파일은 덧셈으로 비대해지기 쉬우므로, 가끔은 뺄셈을 하는 눈이 필요합니다.

요약

이번 릴리스(v2.33.0〜v2.34.0)는,

v2.33.0: CLAUDE.md의 불필요한 @import 한 줄을 사양을 실기 확인한 후 제거 (동작 변화 없는 정리)

v2.34.0: 구현 전에 설계와 계획을 적대적으로 의심하는 design-critic 추가. 3가지 렌즈(전제 발굴 / 모호함 / 누락) + 원인 계층 태그 + 계층별 라우팅(Layered Routing)의 두 가지 핵심 기능입니다. 메인 기능인 design-critic은 X(구 Twitter)에 올라온 블로그를 기점으로 시작되었으며, 사용자의 날카로운 한마디로 설계의 구멍 하나가 메워졌고, 마지막에는 도그푸딩(Dogfooding)을 통해 스스로의 구멍을 8개나 찾아냈습니다. **'의심하는' 행위를 워크플로(Workflow)에組み込む(組み込む)**는, C3가 계속해 온 일의 자연스러운 연장선입니다.

'구현에 들어간 뒤에 깨닫는 상황'이 줄어들지는 않을지는 앞으로 실제로 사용해 보며 확인해야 합니다. 단 한 번의 도그푸딩으로 말할 수 있는 것은 "의도한 지적이 나왔고, 계층별 라우팅이 효과가 있었다"까지이며, "재작업(Rework)이 정말로 줄어들었는가"에 대해서는 아직 데이터가 없다는── 하는 솔직한 한계도 지난번에 이어 적어둡니다.

C3를 써보고 싶다면 ── 시작하기

pip install claude-code-conductor
cd your-project
c3 init # .claude/ 에 에이전트 정의·skill·hook 이 전개됨

그다음은 Claude Code에서 /start.
**히어링(Hearing) → 설계(Design) → 계획(Planning) → 구현(Implementation) → 리뷰(Review)**가 하나의 워크플로로 이어져 있으며, 각 페이즈(Phase)의 구분점에 승인 게이트(Approval Gate)가 들어갑니다. 이번부터는 계획과 구현 사이에 design-critic의 opt-in 감사 게이트를 끼워 넣을 수 있습니다(중요한 변경 시에만 온(On) 상태로 사용). 설계·계획의 전제 붕괴·모호함·누락을 구현 전에 낱낱이 파헤쳐서, 문제가 발생한 계층으로 되돌려 수정할 수 있습니다. 발산하며 생각하고 싶을 때는 /brainstorm을 사용하세요. 어댑터는 Claude / Codex / Cursor / OpenCode 4개에 대응합니다(c3 init --platform ..., 단 design-critic의 워크플로 통합은 현재 Claude Code에서만 가능). 한 가지 주의할 점: design-critic은 신규 에이전트이므로, c3 update를 한 직후의 세션에서는 실행할 수 없습니다(Claude Code가 세션 시작 시에 정의를 읽기 때문). 다음 세션부터 유효해집니다.

"이런 기능이 필요하다", "이 부분이 이상하다" 하는 점이 있다면 Issue나 PR로 언제든 편하게 말씀해 주세요.

링크

• C3 GitHub: https://github.com/satoh-y-0323/claude-code-conductor
• C3 PyPI: https://pypi.org/project/claude-code-conductor/
• C3 공식 문서: https://satoh-y-0323.github.io/claude-code-conductor/
• v2.33.0 릴리스 노트: https://github.com/satoh-y-0323/claude-code-conductor/releases/tag/v2.33.0
• v2.34.0 릴리스 노트: https://github.com/satoh-y-0323/claude-code-conductor/releases/tag/v2.34.0
• 착상 원문 블로그 (My Automated Doubt Development Process): https://www.alexself.dev/blog/automated-doubt
• 이전 기사 (동적 루브릭화와 3가지 「하지 않기로 한 판단」 / C3 v2.31.0〜v2.32.0): https://zenn.dev/satoh_y_0323/articles/c03402ef534316

Discussion