Claude Code로 『가상 조직』을 2주간 운영하며 깨달은 서브 에이전트 (Sub-agent) 설계의 지뢰 5가지

개인 개발로 AI 뉴스 배포 SaaS 「DAINews」를 만들고 있는 fumi(@fumikun_gengen)입니다. SES 엔지니어 × 개인 개발자로서, Claude Code에 「비서」 「마케팅 부문」 「개발 부문」을 부여하는 운영을 2026-05-06부터 계속하고 있습니다. .claude/agents/에 16개 파일, .claude/rules/에 7개 파일을 보유한 상태로 13일이 지났으며, 정리해 보니 성공한 이야기보다 지뢰를 밟은 이야기가 더 많아서 밟은 순서대로 5가지를 정리합니다.

Claude Code에 「비서 → 각 부서」 구조를 갖게 한다는 발상은 저의 독창적인 것이 아닙니다. Shin-sibainu 님이 공개하고 있는 cc-company (MIT 라이선스)라는 Claude Code 플러그인을 YouTube 영상에서 우연히 발견했고, 영상을 끝까지 본 후 바로 제 환경에서 실행해 본 것이 시작이었습니다.

당시 저는 SES 인프라 엔지니어로 본업을 수행하면서, 개인적으로 DAINews라는 AI 뉴스 배포 SaaS를 만들고 있었고, 추가로 자신의 note나 Qiita에서의 발신 운영도 병행하고 있었습니다. 세 방향으로 흩어진 태스크(Task)와 판단 재료를 에디터 안에서 혼자 전부 감당하는 것은 물리적으로 한계가 있었습니다. 「비서가 있고, 필요하면 부서가 세워진다」라는 모델을 처음 보았을 때, 이것이야말로 내가 찾던 구조 그 자체라고 느꼈습니다.

실제로 실행해 보니 처음 며칠은 순수하게 즐거웠습니다. 하지만 2주간 운영해 보니, cc-company의 골격에 fumi 가상 조직 나름의 살을 붙여가는 과정에서 5가지 「설계의 지뢰」를 밟게 되었습니다. 본 기사는 그 기록입니다.

공식 문서의 단순 복사가 아니라, 리포지토리 내의 결의 ID (D118 / D130 / MKT-006 등)로 뒷받침할 수 있는 범위 내에서 작성합니다.

그전에, 13일 동안 조직이 어떻게 변했는지 간략히 보여드리겠습니다. 처음에는 cc-company의 순수한 상태, 즉 「비서가 있고 필요하면 부서가 세워진다」뿐이었던 것이, 13일 후에는 부서 7 / 서브 에이전트 (Sub-agent) 16 / 횡단 규칙 7까지 확장되었습니다.

2026-05-06 (시작 시점)

2026-05-19 (13일 후 / 현재)

팽창하는 속도는 예상 이상이었으며, 이 확장 과정에서 밟은 지뢰들은 다음과 같습니다.

#	지뢰	발견일	수정 비용
1	서브 에이전트에서 Task 툴이 작동하지 않음	2026-05-15	오케스트레이션 (Orchestration) 방식의 전면 재설계
2	크로스 리뷰 (Cross-review)의 독립성이 동일 세션에서 오염됨	2026-05-15	review-mode 플래그 신설
3	ID 채번의 임시 라벨 운용이 사고를 부름	2026-05-16	5개 파일 다층 방어 + /id-assign 스킬
4	「개성」이 AI에 의해 균질화됨	지속 관측	「fumi 관리 마커」를 구조로 강제
5	Auto 모드와 파괴적 조작의 경계가 모호함	2026-05-09	자기 모순 감지 규칙 (60초 이내 재독)

「5선」이 아니라 밟은 순서대로 나열합니다.

2026-05-15, 마케팅 부문을 8개 서브 에이전트 체제로 확장하는 동작 확인 테스트 (MKT-006)를 실행하고 있었습니다. 설계 의도는 「비서 → Task(mkt-editor) → mkt-editor 내부에서 Task로 mkt-reviewer-tone과 mkt-reviewer-fact를 병렬 기동」하는 3단계 구성입니다.

눈치챈 것은 제가 아니라 비서 역할을 하는 Claude 쪽이었습니다. 테스트 실행 중에 병렬 에이전트 (Agent) 기동이 작동하지 않는다는 것을 상대방이 먼저 감지하여 보고해 왔고, 저는 그 출력을 보고 나서야 비로소 「아, 설계 쪽이 잘못되었을지도 모르겠다」라고 의심하기 시작했습니다. 거기서부터 판정까지, 10~15분 정도는 「내 쪽의 프롬프트 (Prompt)가 잘못된 게 아닐까」라고 생각하며 .claude/agents/mkt-editor.md를 열어 지시문을 수정해 보거나, Task 툴의 사양을 Anthropic Docs에서 다시 읽어보기도 했습니다. 돌이켜보면 그 전에도 백그라운드 잡 (Background job)이 도중에 멈춘 흔적을 몇 번 목격했고, 그때마다 비서에게 「이거 괜찮나요? 확인해 주세요」라고 말하곤 했습니다. 지금 생각하면, 그 멈춤 현상의 일부도 서브 에이전트에서 Task가 연쇄되지 않는 구조에서 기인했을 가능성이 높습니다.

결론적으로, 서브 에이전트(Sub-agent)화된 mkt-editor 내부에서는 Task 툴이 동작하지 않습니다. 이에 대한 대응으로

Agent(subagent_type: mkt-editor)

방식을 버리고, 비서(main conversation)가 직접 수행하는 방식으로 변경했습니다.

mkt-editor.md를 읽어서 역할을 겸임하고, 각 서브 에이전트를 main에서 직접 에이전트(Agent)로 기동하는

기존(NG) — 서브 에이전트화된 mkt-editor로부터 하류(downstream) Task가 실행되지 않음

신규(OK) — 비서가 main에서 mkt-editor 역할을 겸임하며, 각 서브 에이전트를 병렬로 기동

교훈은 **「독립 컨텍스트(Independent Context)」 ≠ 「서브 에이전트 내에서 동일한 툴을 모두 사용할 수 있음」**입니다. Task의 전파는 첫 번째 소규모 태스크(Small Task)에서 동작 확인을 해두는 것이 안전합니다.

관점이 다른 리뷰어(Reviewer) 2명을 배치하는 구성에서는, 전제 조건이 서로의 리뷰를 참조하지 않는 것이어야 합니다(인지 편향을 분리하기 위함). 동일 세션 내에서 순차적으로 기동하면, 후발 리뷰어가 선발 리뷰의 md 파일을 읽어버리는 오염(Contamination) 리스크가 구조적으로 존재합니다.

대응책으로 review-mode 플래그를 정의했습니다.

reviewer: tone
review-mode: parallel-agents # 동일 메시지 내에서 병렬 기동 (세션 분리로 보장)

parallel-agents는 구조(Structure)이며, independent(병렬 불가 시)는 선언(Declaration)으로 보장합니다. 후자의 경우 본문 말미에 "다른 한쪽은 참조하지 않았음"이라는 푸터(Footer)를 반드시 추가합니다. 순차 기동은 편해 보이지만, 구조적으로 독립성이 깨지기 때문에 수정 비용 측면에서 손해입니다.

2026-05-16의 결의 로그(Decision Log)를 보면, D118-D123까지 "가상 라벨 예약" 메모가 남아 있습니다. 브레인스토밍(Brainstorming) 중에 "D118로 하자"라고 번호를 부여했는데 → 다른 결의가 먼저 D118을 점유 → D125를 기안할 때 번호를 조정해야 하는 상황이 연속적으로 발생했습니다. ENG-028 / ENG-029에서도 동일한 종류의 충돌이 발생했습니다.

번호를 다시 매기는 작업을 3번 정도 반복했을 때, 이것은 인간이 머릿속으로 원자성(Atomicity)을 보장할 수 있는 스코프가 아니라고 판단했습니다. decisions.md를 grep 하여 D118을 찾고, 다른 파일의 가상 라벨과 대조하는 작업이 명백히 뇌의 캐시(Cache)만으로는 감당할 수 없는 수준이 되었습니다. 다음 날 아침 바로 /id-assign 스킬을 작성하기 시작하여 D132로 기록에 남겼고, 자신의 의지에 의존하지 않고 채번(Numbering)을 구조로 제어하는 방침으로 전환했습니다. 본업인 SES와 병행하며 개인 운영을 돌리는 입장에서는, "다음에는 같은 밤을 보내지 않기 위한" 투자 비용이 훨씬 저렴했습니다.

교훈은 **「채번 → 즉시 쓰기를 1턴 내에 완결」**하는 것이며, 가상 라벨은 금지입니다. 대응책은 /id-assign 스킬 신설입니다(D132).

/id-assign d # → D133 (원자적으로 확정)
/id-assign mkt # → MKT-012
/id-assign dai-mkt # → DAI-MKT-009

병렬 기안 워크플로우에서는, 공유 리소스(ID 공간)에 대한 쓰기 경합(Write Contention)을 구조적으로 제거하는 것이 설계 판단의 핵심입니다.

눈에 잘 보이지 않는 지뢰입니다. 초안을 쓰게 하면 확실히 "깔끔한 글"이 나오지만, 다시 읽어보면 누가 써도 이럴 것 같은 문장이며, 대만 출신 SES 엔지니어가 개인 개발을 하며 겪은 지뢰를 쓰고 있다는 배경이 전부 사라져 있습니다. 바로 개성 상실(Depersonalization) 입니다.

대응은 구조로 합니다. 초안에 **「수작업 마커(Hand-touch Marker)를 3~4곳 배치한다」**는 규칙을 설정하고, 티켓의 frontmatter에 mkt-writer-marker-count: 3-4를 작성하여 grep으로 강제 확인합니다. 마커가 포함되지 않은 초안은 재작업입니다. 골자는 AI에게 쓰게 하고, 나중에 자신이 직접 채워 넣습니다. 본 기사에도 4곳이 들어가 있으며, 공개 전에 제가 직접 채워 넣는 페이즈가 필수적으로 포함되어 있습니다. 개성을 지키는 것을 의지에 맡기면 잊어버리기 때문에, 구조로 강제하는 단계까지 설계에 반영했습니다.

2026-05-09, eng-pm이 "Fumi 씨에게 에스컬레이션(Escalation) 필요"라고 티켓에 적은 직후에, 대상 작업(리포지토리 신규 생성)을 실행하는 자기모순 사례가 발생했습니다.

Auto 모드의 "질문하기보다 합리적인 가정(Reasonable assumptions over asking)" 방침은 리포지토리 신규 생성, 삭제, 가시성(Visibility) 변경에는 적용되지 않습니다. gh repo create / delete / archive

、gh repo edit --visibility / rename / transfer

、git push --force

계열은 Auto 모드에서도 명시적 승인이 필수입니다.

대응책은 자기 모순 탐지 규칙 (Self-contradiction detection rule) 추가: 티켓에 「fumi님께 에스컬레이션 필요」라고 작성한 직후 60초 이내에, 대상 섹션을 재독하여 선언과 모순되지 않는지 체크하는 것입니다. ~/.claude/settings.json의 permissions.ask에도 대상 명령어를 추가하여, 툴 호출(Tool call) 레벨에서 탐지하는 다층 방어(Multi-layered defense)입니다. 에이전트의 상식에 의존하지 않고, 설정 파일 + 자기 모순 탐지의 2단계로 보호하는 것이 결과적으로 Auto 모드를 오래 계속 사용하는 비결이었습니다.

다음에 검증하고 싶은 것은, 5개 축 중 「개성 (Personality)」이 부문 분기 시 어디까지 유지되는가입니다. DAINews 공식 계정과 개인 블로그 fumi 명의로는 말투를 의도적으로 바꾸고 싶은데, 서브 에이전트(Sub-agent) 수가 늘어날수록 초안은 평준화되는 방향으로 흐릅니다. Phase 4에서는 DAI-MKT 계열을 독립 부문으로 분기할지를 판단할 예정이며, 이때 「부문별 톤 정의를 어디에 두어야 평준화를 방지할 수 있는가」가 중심 과제가 됩니다. fumi 관리 마커(fumi-managed marker)의 구조 강제가 다중 계정 체제에서도 살아남을 수 있을지, 다음에는 실전에서 써보고 싶습니다.

5가지는 별개로 보이지만, 모두 「서브 에이전트의 수가 늘어날 때 무엇을 구조적으로 담보할 것인가」라는 측면을 가지고 있습니다. 독립성 / 순서 / 권한 경계 / 개성 / 거버넌스(Governance)의 5개 축입니다. 에이전트 수보다 「충돌이나 오염을 구조적으로 방지하고 있는가」가 운영상 수 배는 더 중요하다고 느끼고 있습니다. 후속 소식은 별도 기사로 전하겠습니다.

• Claude API의 프롬프트 캐싱 (Prompt Caching)을 실무에 투입하기 전에 정리해 두어야 할 6가지 설계 판단 — 동일한 Claude 계열이지만, 서브 에이전트 설계와는 별개 축인 「비용·레이턴시(Latency) 측면에서 구조를 어떻게 설계할 것인가」를 다루고 있습니다.

출처·참고:

• Claude Code Sub-agents: code.claude.com/docs/en/sub-agents
• 리포지토리 내 ID (D118-D123 / D129 / D130 / D132 / MKT-006 / ENG-028 / ENG-029)는 2026-05-06 ~ 2026-05-17 운영 로그에 실제로 존재하는 번호입니다.
• 본 기사의 수치 (16개 에이전트 / 7개 규칙 파일 / 13일간)는 2026-05-19 시점의 실제 수치입니다.