결론부터: 11개 부서는 만들 수 있다. 하지만 '실제로 작동하는 것은 4개 부서'였다

저는 주식회사 Joinclass에서 Claude Code의 서브 에이전트를 부서에 비유한 'AI-CEO Framework'를 거의 1년 가까이 운영해 왔습니다.
.claude/agents/ 에는 17개의 에이전트 정의가 있고, .company/departments/ 에는 11개의 부서 디렉토리가 있습니다.

2026년 2월에 Agent Teams가 발표되었을 때, 저 역시 '이것으로 정말 AI 조직을 만들 수 있겠다'고 생각했습니다. 이 글은 그 이후의 정리 결과를 담고 있습니다. 도입을 고려하는 분들께 먼저 답을 드립니다.

에이전트 정의를 늘리는 비용은 거의 제로에 가깝다. 하지만 부서를 '가동시키는' 비용은 부서마다 누적된다.

• 11개 부서 중 실제로 자율 실행 메커니즘이 구현된 것은 4개 부서(개발・마케팅・영업・출판)
• 나머지 7개 부서의 STATE.md는 반년 이상 업데이트되지 않은 것이 4개 있었다.
• 적정 규모는 '매출에 직결되는 3~4개 부서'. 그 이상은 정의만 만들어도 조직이 되지 않는다.

아래에서 왜 그렇게 되었는지 구현과 숫자로 보여드리겠습니다.

'부서가 작동하고 있다'의 정의를 먼저 정하기

Agent Teams에 대해 이야기하기 전에, 무엇을 기준으로 부서가 가동되고 있다고 할지 정의하지 않으면 논의가 겉돌게 됩니다. 저의 정의는 세 가지입니다.

• 정기 실행 트리거가 존재한다 (launchd 작업) 부서의 STATE.md가 사람의 손을 거치지 않고 업데이트된다.
• 출력이 Slack에 도착하여 CEO가 판단 자료로 사용하고 있다.

이 정의로 볼 때, 11개 부서 중 해당되는 것은 auto-dept-dev.sh, auto-dept-marketing.sh, auto-dept-sales.sh, auto-dept-publishing.sh 네 개가 관리를 하고 있는 부서뿐이었습니다.

작동 여부 확인은 어려운 것을 하지 않았습니다. STATE.md의 업데이트 날짜만 보는 것입니다. 이것은 매월 1일에 실행되는 auto-agent-health-check.sh 구현 그 자체입니다.

# .company/scripts/auto-agent-health-check.sh (발췌)
STALE_DEPTS=""
CURRENT_DATE=$(date +%s)
...

10월 7일 기준으로 이것을 수동으로 실행한 결과는 다음과 같습니다.

솔직히 말하자면, cs(고객 지원)와 hr(인사)는 초기 설정 이후 한 번도 업데이트되지 않았습니다. 에이전트 정의는 훌륭하게 존재합니다. 하지만 호출되지 않습니다. 정의 파일의 수와 조직의 규모는 별개입니다. 이것이 첫 번째 배움입니다.

왜 7개 부서가 멈췄나: 한 번의 호출에 대한 고정 비용

부서를 늘려도 작동하지 않았던 이유는 의욕의 문제가 아니라 코스트 구조의 문제였습니다.

9월에 무인 실행 중인 claude -p의 실질적인 비용을 측정했습니다. 이전까지의 비용 기록은 자가 신고한 개략치였고, 한 종류의 작업만 기록하고 있었습니다. 측정해 보니, '2+2는?'이라고 묻기만 하는 단 한 번의 호출에도 0.27~0.47달러가 들었습니다.

내역을 분석해보니 캐시 생성에 약 41,000 토큰이 사용되었습니다. 그중 자사 파일(CLAUDE.md・에이전트・스킬 정의)은 고작 5,800 토큰에 불과했고, 나머지는 Claude Code 측의 고정 오버헤드였습니다. 즉 프롬프트를 줄여도 싸지지 않습니다. 줄일 수 있는 것은 호출 횟수뿐입니다.

이 사실을 바탕으로 모든 무인 실행을 하나의 래퍼(wrapper)를 통하도록 했습니다.

# .company/scripts/lib/claude-run.sh
claude_run() {
local label="$1"; shift
...

핵심 포인트는 세 가지입니다.

• --output-format json으로 응답 텍스트뿐만 아니라 실질적인 비용을 추출하고 -
  --max-budget-usd 3로 폭주 상한선을 설정합니다 (1개 부서당 1회 3달러를 초과하면 설계가 잘못된 것입니다) -
  레이블을 붙여 cost-tracker.json에 누적시키고, 부서별 월간 비용이 보이는 상태로 만듭니다.

부서 스크립트 측에서는 이 래퍼만 호출합니다. 출판 부서의 실제 사례를 담았습니다.

.company/scripts/auto-dept-publishing.sh (발췌)

source "/Users/kyoagun/workspace/one-ceo/.company/scripts/lib/claude-run.sh"
RESULT=$(claude_run dept-publishing --effort low -p "
...
"

--effort low

과 --allowedTools "Read,Bash"

은 의도적이다. 정기 보고서에 높은 추론 비용이 필요하지 않으며, 쓰기 권한을 주면 '보고서와 함께 STATE.md를 수정하는' 사고가 발생한다. 부문 에이전트의 권한은 해당 부문의 업무에 필요한 최소한으로 제한한다.

여기까지 만들고 알게 된 것은, 부문을 하나 '운영'하게 되면 매일 호출할 경우 월 최소 10~15달러의 고정 비용이 발생한다는 것이다. 7개 부문을 모두 매일 가동하면, 그것만으로도 월 100달러를 초과한다. 매출이 없는 CS 부문이나 HR 부문에 그 금액을 지출할지 판단하기 어려웠다. 그래서 중단했다. 중단한 것이 옳았다.

Agent Teams로 무엇이 바뀌고, 무엇이 변하지 않는가

Agent Teams는 여러 에이전트가 한 세션 내에서 협력하며 메시징으로 직접 연계되는 구조이다. 나의 .claude/agents/

의 설계는 원래 '하나의 오케스트레이터가 부문 에이전트를 총괄하는' 형태였기 때문에, 사상적으로는 궁합이 좋다.

변화하는 것.

부문 간 인계(Handover)가 자동화된다. 지금은 '출판 부문이 EPUB을 만들고 → 마케팅 부문이 SNS 배포를 하는' 과정 사이에서, 내가 Slack을 보고 다음 작업을 시작하고 있다. 이것이 불필요해진다 -
1세션의 문맥(Context)을 공유할 수 있다. 각 작업이 독립적이면, 같은 .company/STATE.md

를 4번 다시 읽어야 한다. 한 번으로 끝난다.

변하지 않는 것.

1부문을 가동할 때마다의 고정 비용은 사라지지 않는다. Agent Teams는 에이전트 간의 연계를 편리하게 하지만, 각 에이전트의 토큰 소비를 줄이는 것은 아니다. 오히려 상시 협력시키면, 움직이지 않는 부문까지 문맥을 소모한다 -
'운영할 가치가 없는 부문'은 Agent Teams로 해도 가치가 없다. CS 부문에 문의가 오지 않는다면, 팀에 넣어도 일거리가 없다.

즉, Agent Teams는 '조직을 크게 만드는 도구'가 아니라, 이미 가동 중인 소수의 부문을 더 밀접하게 연계시키는 도구이다. 11개 부문을 1팀으로 할 계획은, 이 글을 쓰면서 철회했다.

적정 규모를 결정하는 방법: 매출에 연결된 부문부터

도입을 고려하는 사람들을 위해, 내가 지금 당장 취할 절차를 작성한다.

1. 매출이 발생하는 업무 라인을 센다. 우리 회사의 경우 출판, 위탁 개발, SaaS의 3가지이다. 부문은 이것에 1대1로 대응시킨다. '회계 부문', '법무 부문'은 나중으로 미뤄도 좋다. 월 1회의 결산이나 계약 검토는 필요할 때 스킬로서 호출하면 충분하다.

2. 부문별로 '가동의 정의'를 한 줄로 작성한다. '매주 수요일에 모든 도서의 상태를 Slack에 올린다'와 같이, 트리거(Trigger)・출력처・빈도까지 정한다. 이것을 쓸 수 없는 부문은 만들지 않는다.

3. 모든 부문을 동일한 래퍼(Wrapper)에 통과시키고, 부문별 월 비용을 본다. 위 claude_run

와 같은 것을 처음부터 준비해야 한다. 비용이 보이지 않는 상태로 부문을 늘리면, 나처럼 반년 후에 재정비(棚卸し)를 해야 하는 상황이 된다.

4. 30일간 업데이트가 없는 부문을 감지한다. 월별 건강 점검을 돌려 중단된 부문을 시각화한다. 멈춰 있는 것 자체가 나쁜 것은 아니다. 멈춰 있는데 '11개 부문 운영 중'이라고 주장하는 것이 문제이다.

함정과 검증 방법

실제로 해보고 걸린 점 3가지.

부문 에이전트의 정의가 비대해진다. 규칙을 계속 추가한 CLAUDE.md가 1,000줄을 넘었을 때, 에이전트가 지시와 반대로 움직이기 시작했다. 지금은 오케스트레이터의 지시는 200줄 이내로 제한하고, 부문 고유의 상세 내용은 각 에이전트 정의에 분리하고 있다.

쓰기 권한 사고. 부문 에이전트에게 Write

을 준 상태로 정기 실행하면, 보고서 대신 파일을 덮어쓸 때가 있다. 정기 보고서 계열은 --allowedTools "Read,Bash"

으로 고정하고, 쓰기가 필요한 부문만 승인 대기열(Approval Queue)을 거치게 했다.

검증은 로그로. 각 부문 스크립트는 .company/scripts/logs/auto-dept-*.log

에 시작・결과・종료를 남긴다. '작동하는지' 확인하는 것은 Slack을 보는 것보다 tail

을 하는 것이 낫다.

이것이 더 확실하다.

tail -n 3 .company/scripts/logs/auto-dept-publishing.log
python3 -c "import json;d=json.load(open('.company/scripts/cost-tracker.json'));print(len(d))"

이를 통해 '마지막 실행 일시'와 '비용 기록 건수'를 알 수 있다. 이 두 가지가 멈춰 있다면, 해당 부서는 존재하지 않는 것과 같다.

결론: AI에게 조직을 만드는 것이 아니라, 조직의 형태를 AI에 맞추는 것

1년이 지나고 남은 것은 11개 부서가 아닌 4개였다. 나는 여러 번 'AI는 무엇이든 만들 수 있지만, 무엇이든 팔 수 있는 것은 아니다'라고 써왔지만, 부서도 마찬가지다. AI는 어떤 부서라도 정의할 수 있지만, 어떤 부서라도 가동시킬 수는 없다.

Agent Teams는 강력하다. 하지만 그 강력함은 부서를 늘리는 방향이 아니라, 소수의 가동 부서를 깊게 연계시키는 방향에 사용되어야 한다. 도입을 결정하는 입장의 사람들에게 전하고 싶은 것은 에이전트의 수를 경쟁하지 말라는 것이다. 가동 중인 부서의 수와, 그 부서가 창출하는 매출만 봐주었으면 좋겠다.

이 기사의 원료가 된 운영 전체 그림(launchd・Hooks・Skills・비용 측정・Agent Teams 이행 계획)은 도서 『Claude Code 완전 자동화 바이블』에 정리되어 있다. 다른 서적과 함께 아래에서 확인하실 수 있다.

Discussion