Claude Code에 24개의 전문가 역할을 부여한 후, 이를 이용해 내 에이전시를 재구축했다

요약(TL;DR) — 몇 달 전, 저는 혼자서 기능을 출시하기 위해 Claude Code에 16개의 전문가 역할을 부여했다는 글을 올렸습니다. 저는 16개에서 멈추지 않았습니다. 이제 24개가 되었으며, 제가 실제로 중요하게 생각하는 변화는 그 숫자가 아닙니다. 저는 모든 감사자(auditor)를 코드를 건드릴 수 없는 **읽기 전용 탐색기 (read-only finder)**와 플래그가 지정된 부분만 변경하는 **범위 제한 수정기 (scoped fixer)**로 분리했습니다. 6개의 슬래시 명령어(slash commands)는 11개가 되었습니다. 전체 시스템은 이제 원클릭 플러그인 설치 (one-command plugin install) 방식이 되었습니다. 그런 다음 저는 당연한 일을 했습니다. 에이전트 팀을 제 자신의 회사로 향하게 하여, 첫 번째 고객(client zero)으로서 Creative Brain의 사이트를 그것으로 재구축했습니다. 클라이언트 저장소(repo)에서 실행하던 것과 동일한 수집(gather) → 위임(delegate) → 검증(verify) 루프를 사용했습니다.

시작점

첫 번째 기사를 읽어보셨다면, 한 단락 요약은 다음과 같습니다: 저는 1인 창업자입니다. 저는 하나의 오케스트레이터(orchestrator) 세션이 컨텍스트(context)를 수집하고, 좁은 범위의 전문가에게 위임하며, 출력을 검증하는 일만 수행하는 Claude Code 플러그인을 구축했습니다. 16명의 전문가, 6개의 슬래시 명령어, memory/ 폴더 내의 파일 기반 메모리, 그리고 런타임(runtime)에서 위험한 동작을 차단하는 안전 후크(safety hooks)가 포함되어 있습니다. 아이디어 단계에서 스테이징(staging)까지 1시간 미만으로 소요되며, 모든 것이 저장소(repo) 내에 있고 새로운 SaaS는 필요하지 않습니다.

그 시스템은 작동했습니다. 그래서 저는 계속해서 구축해 나갔습니다. 이것은 "16개에서 멈추지 않았다"는 업데이트이며, 그다음은 제가 실제로 자랑스럽게 생각하는 부분, 즉 시스템이 저로 하여금 _무엇을 할 수 있게 했는지_에 대한 내용입니다.

그림 1 — 하나의 오케스트레이터가 컨텍스트를 수집하고 위임하며, 각 전문가는 자신만의 깨끗한 컨텍스트 창(context window)에서 작업합니다.

가장 중요했던 단 하나의 변화: 탐색과 수정을 분리하다

제가 변경한 가장 중요한 사항은 인원수가 아닙니다. 바로 이것입니다.

이전에는 단일 에이전트가 "버그를 찾고 동시에 수정"했습니다. 효율적으로 들리죠. 하지만 실제로는 다음과 같았습니다: "14개의 문제를 발견함 — 그리고 그 과정에서 관련 없는 파일 3개를 조용히 재작성함." 전형적인 모습입니다. 하나의 에이전트가 문제를 발견함과 동시에 패치(patch)를 진행하면, 의욕이 과해지기 마련입니다. 인증(auth) 체크 하나를 강화해달라고 요청하면, 그 과정에서 다른 파일 3개를 "정리"해 버립니다. 그러면 당신의 디프(diff)는 미스터리가 되고 리뷰는 무용지물이 됩니다.

그림 2 — 안티 패턴(anti-pattern): 발견과 수정을 모두 수행하는 단일 에이전트는 제한 없는 폭발 반경(blast radius)을 가집니다.

그래서 저는 모든 감사자(auditor)를 둘로 나누었습니다:

• Finder(탐색자)는 읽기 전용(read-only)입니다. 이들은 디프(diff)를 스캔하고 구조화된 보고서를 전달합니다. 이들은 말 그대로 코드를 건드릴 수 없습니다. 이들의 도구 허용 목록(allowlist)에는 쓰기 권한이 없습니다.
• Fixer(수정자)는 그 보고서를 받아 플래그(flag)가 지정된 부분만 변경합니다. 그 외에는 아무것도 하지 않습니다.

루프는 다음과 같이 변합니다: 탐색 → 내가 읽음 → 범위가 지정된 수정(scoped fix). 읽기 전용 감사, 그 다음 내가 검토, 마지막으로 정확히 한 가지 일만 수행하는 수정입니다. 검토 가능하고, 지루하며, 안전합니다. 모든 에이전트의 폭발 반경(blast radius)이 하나의 작업으로 축소되었습니다.

그림 3 — 분리: 읽기 전용 Finder가 문제를 보고하면, 범위가 지정된 Fixer가 플래그가 지정된 부분만 변경합니다.

그림 4 — 이전에는 한 번의 움직임이 모든 것에 영향을 미쳤습니다. 이후에는 각 에이전트가 정확히 하나의 작업으로 범위가 제한됩니다.

이러한 제약 조건은 그것이 부재하여 고통을 겪기 전까지는 보이지 않는 종류의 것입니다. 만약 코딩 에이전트 (coding agents)를 운영한다면, 당신은 실제로 "수정 (fix)" 단계가 무엇을 건드릴 수 있는지 제약을 두고 있습니까, 아니면 그저 운에 맡기고 있습니까?

지난 포스트 이후 무엇이 더 변했는가

수치들이 변했습니다. 빌드 상태가 이제 희망적인 수치가 아니라 디스크 상의 실제 파일과 대조되어 조정되기 때문에, 저는 이 수치들을 정확하게 전달하고자 합니다.

• 16명의 전문가 → 24명. 명단이 늘어났지만, 이는 주로 감사자 (auditors)가 두 배로 늘어났기 때문입니다 (기존에는 하나의 결합된 에이전트였던 것이 탐색자 (finder)와 수정자 (fixer)로 분리됨). 여기에 몇 가지 새로운 역할이 추가되었습니다.
• 6개의 슬래시 명령어 (slash commands) → 11개. 롤백 작성자 (rollback-author), 성능 프로파일러 (performance profiler), BRD-to-roadmap 명령어, 변경 로그 빌더 (changelog builder) 등이 추가되었습니다.
• 설정 스크립트 (setup script) → 단일 명령 플러그인 설치. 이전에는 설정 스크립트가 필요했습니다. 이제는 /plugin install 하나면 별도의 스캐폴딩 (scaffolding) 단계 없이 전체 명단을 사용할 수 있습니다.

그림 5 — 네 개의 그룹으로 나뉜 24명의 전문가 — 감사 그룹은 탐색자/수정자가 두 배로 늘어난 곳입니다.

그림 6 — 6개의 명령어가 11개가 되었습니다: 롤백 (rollback), 성능 프로파일러 (perf profiler), BRD→roadmap, 변경 로그 빌더 (changelog builder) 등.

마지막 항목은 들리는 것보다 훨씬 더 중요합니다. 단일 명령 설치는 "내가 나를 위해 만든 것"과 "다른 사람도 실제로 실행할 수 있는 것" 사이의 차이입니다. 에이전트, 명령어, 훅 (hooks), 메모리 모델 (memory model)을 포함한 전체 명단이 단 한 번의 동작으로 설치됩니다.

그림 7 — /plugin install 명령 한 번으로 전체 명단을 불러옵니다. 별도의 설정 스크립트가 필요 없습니다.

내가 모든 것을 걸고 신뢰하는 규칙

위의 모든 내용은 하나의 원칙에 기반하며, 이는 첫 번째 글을 쓴 이후로 변하지 않았습니다.

안전 장치(safety gates)는 프롬프트(prompt)가 아니라 런타임(runtime)에 존재해야 합니다. 프롬프트는 무시될 수 있지만, 런타임 게이트는 무시될 수 없습니다.

Claude Code의 훅(hook) 시스템은 라이프사이클 이벤트(lifecycle events)에서 스크립트를 실행하며, 저는 이를 사용하여 엄격한 제한 사항을 강제합니다. 예를 들어, 강제 푸시(force push) 금지, 루트(root) 근처에서의 rm -rf 금지, 저의 명시적 승인 없는 프로덕션 배포(production deploy) 금지, 그리고 모든 쓰기 작업의 감사 로그(audit log) 추가 등이 있습니다. 이것들은 자신감 넘치는 모델이 합리화하며 넘어갈 수 있는 시스템 프롬프트(system prompt) 상의 정중한 요청이 아닙니다. 이것들은 훅(hook)입니다. 런타임 계층(runtime layer)에서 실행됩니다. AI는 이를 무시할 수 없습니다.

탐색자(finder)와 수정자(fixer)를 분리한 것도 한 단계 더 깊게 들어간 동일한 아이디어입니다. 탐색자가 읽기 전용(read-only)이라는 것은 프롬프트에 파일을 수정하지 말아 달라고 정중하게 요청하는 문장이 아니라, 쓰기 도구 허용 목록(write-tool allowlist)이 비어 있다는 뜻입니다. 제약 사항은 권고 사항이 아니라 구조적인 것입니다. 이것이 바로 제가 이 시스템을 프로덕션 환경에 투입할 수 있을 만큼 신뢰하는 이유입니다.

그림 8 — 훅(Hooks)은 런타임 계층에서 도구의 라이프사이클을 제어합니다. 위험한 명령은 실행되기 전에 차단됩니다.

그리고 나는 내 회사를 '클라이언트 제로'로 만들었다

이 부분이 제가 실제로 쓰고 싶었던 내용입니다.

수년간 Creative Brain은 크리에이티브 및 웹 개발 스튜디오였습니다. 훌륭한 작업을 수행했지만, 가격 책정과 속도는 다른 모든 업체와 마찬가지로 몇 주 단위의 범위 설정과 시간당 비용 청구 방식으로 운영되었습니다. AI 네이티브 에이전시(AI-native agency)로의 전환은 단순히 로고를 바꾸는 것이 아니었습니다. 그것은 구축하는 방식의 변화였습니다. 그리고 단 한 명의 고객에게도 "우리는 통제된 AI 에이전트 팀과 함께 결과물을 전달합니다"라고 판매하기 전에, 저 스스로를 **클라이언트 제로(client zero)**로 만들었습니다.

그래서 저는 저의 24인 전문가 Claude Code 팀을 creativebrain.ca에 투입하여 사이트 전체를 재구축했습니다:

• 전체 /services 아키텍처 (architecture)
• 무료 /tools 제품군 및 /seo-tools 제품군
• 완전한 커스텀 일러스트레이션 시스템 — 스톡 이미지나 아이콘 라이브러리 채우기용이 아닌, 하나의 일관된 패밀리로 직접 제작한 SVG
• 토큰(tokens)을 포함하여 문서화된 실제 디자인 시스템 (design system)

이 루프(loop)는 제가 클라이언트의 저장소(repo)에서 실행하던 방식과 정확히 일치했습니다. 기획자(planner)가 사양(spec)을 정의했고, 빌더(builders)가 작성했으며, 읽기 전용 파인더(finders)가 감사(audit)했습니다. 저는 검토하고 배포(ship)했습니다:

기획자가 사양 초안 작성        → 제가 승인
빌더가 구현                 → 파인더가 감사 (읽기 전용) → 제가 검토
제가 배포

수집(gather) → 위임(delegate) → 검증(verify). 예전에는 23주가 걸리던 사이트 프로젝트가 34일간의 집중적인 세션으로 압축되었습니다. 왜냐하면 제가 타이핑을 하는 것이 아니라, **결정(deciding)**을 하고 있었기 때문입니다.

그림 9 — 클라이언트 제로: 에이전시 자신의 사이트를 대상으로 한 동일한 수집→위임→검증 루프.

솔직한 부분 (이 또한 변하지 않았습니다)

AI가 취향(taste)을 대체하지는 못했습니다. 모든 디자인 결정, 모든 "아니요, 그건 아닙", 모든 브랜드 결정은 저의 것이었습니다. 에이전트들은 저에게 판단력이 아닌 레버리지(leverage)를 제공했습니다. 그리고 그것이 여전히 본질적인 업무입니다. 첫 번째 글과 마찬가지로 몇 가지 솔직한 한계점을 말씀드리자면 다음과 같습니다:

• 새로운 저장소(repo)의 첫날에는 느립니다. 전문가들에게는 읽어볼 수 있는 memory/가 필요합니다. 3일 차에는 날아다니지만, 1일 차에는 일일이 손을 잡아줘야 합니다.
• 마이그레이션(Migrations)은 여전히 저를 불안하게 만듭니다. 저는 모든 Supabase 마이그레이션 코드를 한 줄씩 읽습니다. 감사자(auditor)는 제2의 의견일 뿐, 최종 결정권이 아닙니다.
• 여전히 아름다운 것을 디자인할 수는 없습니다. 정확하고 접근성(accessible) 있는 컴포넌트(components)는 가능합니다. 하지만 취향(taste)은 안 됩니다. 그것은 저의 몫입니다.
• 토큰(tokens) 비용이 발생합니다. 24명의 전문가가 실행되면 무시할 수 없는 수준의 diff 예산을 소모합니다. 대안과 비교했을 때 여전히 압도적으로 유리하지만, 공짜는 아닙니다.

이 중 어느 것도 면책 조항이 아닙니다. 이것이 바로 이 시스템을 안전하게 실행할 수 있는 이유입니다. 저는 신뢰할 수 없는 지점이 정확히 어디인지 알고 있으며, 그 경계 주변에 안전장치(gates)를 구축해 두었습니다.

그림 10 — 결과물: 23주가 소요되는 스튜디오 프로젝트를 집중적이고 의사결정 중심적인 34일의 세션으로 압축함.

그렇다면 이제 제안(pitch)은 무엇인가