Claude Code로 AI 사업팀 만들기 (1) — 서브에이전트 협업을 포기했다가 이름 하나로 되살렸다

[AI 페르소나 포함] 이 글에 등장하는 ‘총괄’·’소싱 데스크’ 등 각 역할은 실존 인물이 아니라 인공지능(AI)에 기반한 역할 페르소나입니다. 실제 인물·경력·자격과 무관합니다.

📌 시리즈 — Claude Code로 AI 사업팀 만들기

• 1편 · 서브에이전트 협업을 포기했다가 이름 하나로 되살렸다 (현재 글)
• 곁가지 · No agent named ‘general-purpose’ is reachable — 이름을 붙이면 회신이 돌아온다

하루 동안 설계를 두 번 버렸고, 세 번째로는 설계가 아니라 내가 내린 진단을 버렸다.

첫날 기록이다. 아직 아무것도 팔지 않았다. 제품도 채널도 없고 첫 게시물조차 안 나갔다. 성과 기록이 아니라 작업 기록이라, 무엇을 명령했고 그게 무엇을 실행시켰고 결과가 어땠는지를 시간순으로 남긴다. 따라 해보려는 사람이 같은 자리에서 같은 벽을 만나도록.

뭘 하려는가 — 14:45의 명령

시작은 이 한 덩어리다. 브레인스토밍 소집 명령(/bmad-party-mode)에 붙여 그대로 넣었다.

지금부터 한국에서 만들어서 판매되는 제품을 소개하는 사이트를 만들어서 우리나라 제품이 좋다는 것을 홍보해서 우리나라 기업들의 제품 판매량이 늘게 만들게 할거야. 그러려면 사업 영업 기획 디자인 마케팅 개발 재무 법무 md 쇼호스트 작가 피디 등 10년차 이상의 전문 에이전트들이 모여서 어떻게 사업을 진행시켜야 할지 브레인스토밍부터 진행했으면 좋겠어. (…) 나의 아이디어는 일단 소싱과 홍보가 핵심이여야 한다고 생각해. 그래서 이 사이트와 sns 가 사람들을 많이 끌어모아서 브릿지 역할을 시작하는 것이였고, 이게 잘 되면 그 다음에 수익화 모델을 생각하는 것이였어.

여기에 세 가지가 이미 들어 있다. 무엇을 팔 것인가(한국에서 만든 제품), 어떻게 굴릴 것인가(직군별 전문 에이전트를 모아 의사결정에 상시 참여시킨다), 어느 순서로 갈 것인가(1단계 소싱·홍보로 사람을 모으는 브릿지, 수익화는 그다음).

이 명령이 만든 결과물이 12인 전문가 보드와 벤치마크 조사다. 소싱·콘텐츠·그로스·플랫폼·게이트로 데스크를 나눈 편성도 여기서 나왔다.

보드가 처음 한 일은 성공·실패 사례를 규칙으로 바꾸는 작업이었다. 광고비로 매출을 사다 무너진 사례가 있어 초기 유료 광고 0원이 규칙이 됐고, 품질 사고 자체보다 은폐형 대응으로 무너진 사례가 있어 단점 언급을 콘텐츠 포맷에 내장하는 것이 규칙이 됐다. 이렇게 근거를 붙여 규칙으로 박아두면, 나중에 누가 “이번만 광고 좀 태우자”고 할 때 반박 대신 문서를 펴면 된다.

한 가지는 미리 정해뒀다. 결정은 전부 근거와 함께 기록하고, 누구든 근거를 들고 오면 다시 연다. 오늘 이 규칙이 실제로 쓰였다 — 뒤에 나올 3차가 그 사례다.

어떤 방식으로 — 18:00의 규칙 세 개

방식은 내가 정한 게 아니라 명령으로 못이 박혔다. 아래는 발췌다(생략은 (…)로 표시).

1. 현재 기준에서 추가 비용이 드는것 없이 진행한다. poc 돌려서 반응이 있다고 판단될때 업그레이드한다. (…)
2. 총괄의견 대로 진행한다. 스프린트를 진행하면서 발생되는 이슈에 대한건 데일리 보고서를 만들어서 내가 볼 수 있도록 서버에 업로드한다. (…)
3. 직원이 작업하다가 문제가 생기면 (…) 코덱스 처럼 서로 의견을 나누면서 진행하는 방식으로 적용해서 해야 이 프로젝트가 성공할 수 있다. 배치를 돌려서 한시간에 한번씩 정해진걸 진행하면 이프로젝트는 거북이가 될 것이다. 스프린트 개념과 맞지 않음. 따라서 배치보다 서로 요청해서 확인/응답 하는 방식으로 조치해라. (…)

이 셋은 뒤에 나오는 모든 반려가 튀어나오는 칼이다. 1번은 유료 호스팅을 잘랐고, 3번은 그날 짜둔 자동화를 통째로 잘랐다. 원칙이 추상적으로 들리는 건 대개 아직 아무것도 안 잘라봤기 때문이다.

따라 하려면 이것부터 — 15:02의 명령

순서상 위 규칙보다 먼저 들어온 명령이 하나 있다.

세션에 기록되는 모든 로그를 저장해 / 컴팩트해도 다시 찾을 수 있게. / 그리고 이거는 클로드 전역에 스킬로 발행하고 발행된 스킬은 프로젝트마다 실행하게해

지금 이 글이 성립하는 이유가 그 명령이다. 오늘 실제로 앞 세션의 명령 원문을 “남아 있지 않다”고 판단했다가, 보존해둔 아카이브에서 전부 복원했다. 대화가 길어지면 앞부분은 요약으로 접히고, 접힌 것은 기억이 아니라 추정이 된다. 에이전트로 사업을 굴려보려는 사람이 제일 먼저 깔아야 할 것은 조직도가 아니라 이 보존 장치다.

덧붙이면, 이 보존은 전역 스킬로 만들어 프로젝트마다 실행되게 했다. 프로젝트 하나에만 붙여두면 다음 프로젝트에서 같은 실수를 반복한다.

1차 붕괴 — “24시간”을 시계로 번역했다

17:30에 총괄 체제 명령이 들어왔다.

나는 개입을 최소화 할거야. 그래서 이 사업을 맡을 총괄 에이전트가 필요해. (…) 데일리로 해야하는 것 위클리로 해야하는 것 먼슬리로 해야하는 것 분기별 aar 해야할 것들을 모두 진행해. / 이 모든건 에이전트들이 24시간 돌아갈 수 있도록 하는게 핵심이야.

이 명령을 받아 총괄이 내놓은 계획에는 정해진 시각마다 도는 클라우드 루틴이 6개 있었다. 데일리 지표 수집, 소싱 스캔, 위클리 점검, 먼슬리 정리, 분기 리뷰. 시각까지 박혀 있었다.

왜 그렇게 나왔냐면 “24시간 돌아간다”를 “정해진 시각에 자동으로 기동한다”로 번역했기 때문이다. 사람이 안 봐도 뭔가 돈다는 그림이 24시간처럼 보인다. 위 명령 어디에도 크론이라는 말은 없는데도 그렇게 됐다.

30분 뒤 18:00의 규칙 3번이 그걸 부쉈다. “한시간에 한번씩 정해진걸 진행하면 거북이가 된다”는 문장이 정확히 그 6개를 가리켰다. 클라우드에서 돌리면 돈도 든다(1번). 6개 전부 폐기했다.

폐기하고 나니 더 큰 문제가 남았다. 배치를 지우면 “24시간”이 사라지는 게 아니라 정의를 다시 써야 한다. 새로 잡은 정의는 이것이다.

24시간 = 기계가 켜져 있는 동안 배치 대기 없이 즉시 반응하는 상태.

정시까지 기다리는 구간이 없다는 것. 그게 배치 대비 이점의 전부다. 케이던스는 유지하되 방아쇠만 바꿨다.

폐기한 배치	무엇으로 대체했나
데일리 지표 수집	플랫폼 데스크가 계측 변화를 감지하면 그 자리에서 보고
소싱 스캔	소싱 데스크가 상시 후보 큐를 채우고, 판정이 필요해지면 즉시 게이트에 질의
위클리·먼슬리·분기	총괄이 큐 상태를 보고 소집 (시각 고정이 아니라 이벤트 기준)

2차 붕괴 — 질문은 갔는데 답이 안 왔다

19:05에 Sprint 0 시작이 들어왔다. 이제 데스크들이 실제로 일해야 한다.

Sprint 0의 목표는 성장이 아니라 계측이었다. 무엇이 얼마나 도는지 재는 판을 먼저 깔자는 것이고, 그러려면 데스크들이 각자 작업을 집어 가야 한다.

여기서 규칙 3번이 걸린다. 막히면 다른 데스크에게 직접 물어서 답을 받는다. 소싱 데스크가 판단이 막히면 법무 데스크에게 그 자리에서 묻고, 답을 받아 계속 간다. 총괄을 거치면 그건 결재선이지 협업이 아니다.

조직도에 넣기 전에 한 번 돌려보기로 했다. 소싱 역할과 법무 역할을 각각 띄우고, 소싱 쪽에 “법무에게 직접 물어보고 답을 받아와라”를 시켰다.

질문은 갔다. 법무 쪽 로그에 질문이 그대로 도달해 있었고 답변까지 만들어져 있었다.

답이 안 왔다. 소싱 쪽은 열네 번 되물었으나 받은 건 0건이었다. 화면에는 대기 표시만 떴다. 그리고 법무 쪽 끝에 이런 줄이 남아 있었다.

No agent named 'general-purpose' is reachable

오진 — 나는 이걸 구조의 한계로 읽었다

그때 내린 판단은 이랬다.

서브에이전트에는 타입명만 있고 고유 주소가 없다. general-purpose는 이름이 아니라 종류다. 내려보낼 때는 문제가 안 되지만 답을 돌려보낼 때는 특정 개체를 지목해야 하는데, 회신처가 종류 이름이라 배달 대상이 확정되지 않는다. 그러니 형제끼리의 왕복은 애초에 성립하지 않는 구조다. 옵션을 몇 개 바꿔봤지만 아무것도 달라지지 않았고, 그게 판단을 굳혔다.

여기서 조직도를 갈아엎었다. 서브에이전트로는 수평 대화가 안 되니 각 데스크를 독립 세션으로 띄워야 한다고 결론냈다. 세션에는 이름이 붙으니 답이 제자리로 돌아온다는 논리였다. 문서 두 개를 그 전제로 다시 썼고, 세션 간 메시징을 지원하는 버전인지 확인하는 데 시간을 더 썼고, 대안이 될 만한 외부 도구를 뒤졌다.

전부 “서브에이전트는 안 된다”는 전제 위에서 한 일이다. 그 전제가 맞았다면 조직은 데스크마다 세션을 하나씩 띄우고, 사람이 그 세션들을 띄우고 닫는 것을 관리하는 모양이 됐을 것이다.

이 판단이 문서에 들어갔다는 게 더 문제였다. 정본 문서에 “서브에이전트로는 안 된다”가 근거와 함께 적히면, 그다음 결정들은 전부 그 문장 위에 얹힌다.

반증 — 이름을 붙이니 답이 돌아왔다

조직도를 확정하기 직전에 걸린 게 하나 있었다.

독립 세션이 되는 이유를 적으려는데, 근거가 “세션에는 이름이 붙어서”였다. 그 문장을 쓰다가 되물었다. 그러면 서브에이전트에 이름을 붙이면 어떻게 되나. 실패한 시험에서 나는 이름을 준 적이 없었다. 안 바꿔본 조건이 하나 남아 있었던 것이다.

그래서 프롬프트를 고쳐 같은 시험을 다시 돌렸다. 핵심은 이 두 줄이다.

너는 MADE IN KOREA 프로젝트의 법무데스크이고, 네 이름(주소)은 gate-desk다. (…) 반드시 SendMessage로 질문자에게 답을 돌려보낸다. 받은 메시지의 from 속성값을 그대로 to에 넣는다. (…)

질문하는 쪽에는 거짓 보고를 막는 지시를 같이 걸었다. 이게 없으면 “물어봤고 답을 받은 것 같다”는 요약이 돌아와서, 성공인지 아닌지가 흐려진다.

답장이 도착하면 최종 텍스트로 정확히 이렇게 반환한다: 왕복성공 / 받은답변: <법무데스크가 보낸 답변 원문 그대로> (…) 거짓 보고 절대 금지. 실제로 답장 메시지를 받았을 때만 왕복성공이라고 해라. 네가 답을 지어내면 이 테스트 전체가 무의미해진다.

돌아온 값은 왕복성공이었다. 소싱 쪽이 상대의 회신 원문을 그대로 들고 있었다.

구조의 한계가 아니었다. 이름을 안 줘서 주소가 안 생겼던 것이다.

해소 — 이름이 곧 주소다

고칠 것은 구조가 아니라 프롬프트 한 줄이었다. 데스크는 반드시 이름을 붙여 띄운다. 이름이 있으면 답이 제자리로 돌아오고, 총괄을 경유할 이유가 없어진다.

독립 세션을 따로 띄울 필요도, 외부 도구를 붙일 필요도 없어졌다. 데스크 다섯 개를 각각 세션으로 띄우고 관리하려던 계획이, 프롬프트에 이름 한 줄을 넣는 것으로 줄었다. 저녁에 그린 그림이 오후에 그린 그림보다 단순하다. 설계가 복잡해지고 있으면 대개 진단이 틀린 것이다. 총괄(CHIEF)은 사용자와의 접점과 소집·중재만 맡고, 데스크끼리는 직접 주고받는다.

주소는 이렇게 고정했다. 이름은 영문·숫자·하이픈 범위로만 지었다.

데스크	주소
소싱	src-desk
콘텐츠	con-desk
그로스	grw-desk
플랫폼	plt-desk
게이트 (법무·재무)	gate-desk

띄울 때 지킬 것도 규약으로 박았다. 이 중 셋째·넷째는 오늘 실제로 부딪쳐서 알게 됐고, 앞의 둘은 그 과정에서 정리한 것이다.

1. 프롬프트 안에 자기 주소를 알려준다. 이름을 붙이는 것과 그 이름을 당사자에게 알려주는 것은 별개 작업이다. 자기 이름을 모르면 남에게 회신처를 못 알려준다.
2. 회신에 쓸 도구를 같이 준다. 처음 실패한 그 서브에이전트에는 살아있는 상대를 조회할 수단조차 없었다. 이름과 도구가 같이 빠져 있어서 어느 쪽이 결정적이었는지는 못 가렸다 [미검증].
3. 한 이름에 데스크는 하나만 살려둔다. 같은 이름으로 두 번 띄우면 주소가 갈라져 메시지가 반려된다.
4. 물어볼 상대를 먼저 띄운다. 질의 경로에 있는 데스크가 안 떠 있으면 질문이 갈 곳이 없다.

        [총괄]  ← 사용자와의 유일한 접점, 게이트 판정
          │  (소집·중재만. 모든 대화가 여기를 지나가지 않는다)
 ┌──────┬──┴───┬──────┬──────┐
[SRC]  [CON]  [GRW]  [PLT]  [GATE]
 └──────┴──────┴──────┴──────┘
     서로 직접 묻고 답한다 (총괄 경유 없음)
          │
   [queue/ 공유 게시판]  ← 무엇이 열려 있고 무엇이 막혔는지

공유 게시판을 따로 둔 이유가 있다. 오간 말은 세션이 닫히면 사라지지만 무엇을 결정했고 왜 그렇게 했는지는 남아야 한다. 대화는 휘발돼도 되고 결정은 휘발되면 안 된다.

하루 동안 확인한 것을 전부 적으면 이렇다. ✅는 이 기계에서 직접 돌려본 것, ❌는 돌려서 안 된 것이다.

검증 항목	결과	근거
ListAgents로 살아있는 세션 조회	✅ 작동	이 기계에서 스무 개 남짓한 피어 세션이 이름과 함께 조회됨
백그라운드 에이전트에 메시지 보내 깨우기	✅ 작동	대기 상태 에이전트가 수신 후 실행 상태로 전환
서브에이전트 A → B 질문 전달	✅ 작동	소싱 역할의 질문이 법무 역할에 도달, 답변까지 생성됨
서브에이전트 B → A 직접 회신 (이름 없을 때)	❌ 실패	회신처가 타입명뿐이라 도달 불가. 질문한 쪽은 열네 번 되물었으나 0건
서브에이전트 B → A 직접 회신 (이름 있을 때)	✅ 성공	gate-desk·src-desk로 재시험 → 회신 원문 수신
세션 간 메시징 (독립 세션끼리)	✅ 작동	다른 세션에 실제 발신 성공
전부 로컬 실행, 추가 과금 없음	✅ 확인	클라우드 실행 아님 (규칙 1 충족)
tmux (분할 화면용)	✅ 설치 완료	tmux 3.7c
Claude Code 버전	✅ 2.1.241	세션을 돌린 에디터 확장을 프로세스로 대조해 확인(터미널 PATH의 CLI는 당시 2.1.220으로 별개 설치본). 세션 간 메시징은 2.1.224에서 추가(macOS·Linux)

공식 릴리스노트에도 한 기계 안의 대화형 세션이 고유한 이름을 유지한다는 항목이 있다. 이름이 주소 역할을 한다는 게 이미 적혀 있었던 셈이다. 재현 절차와 원문 인용은 곁가지 글에 정리해뒀다 → No agent named ‘general-purpose’ is reachable — 이름을 붙이면 회신이 돌아온다.

에이전트 간 통신을 붙여주는 외부 도구도 다섯 개 검토했고 전부 반려했다. 인기순이 아니라 원칙순으로 잘랐다 — 권한 체계를 훼손하는가, 비용이 붙는가, 이미 세운 문서 체계와 부딪치는가. 별이 6만 개대인 것과 한 자릿수인 것이(2026-08-24 조회) 같은 기준에서 탈락했고, 목록과 근거는 정본 문서에 남겼다. 품질 평가가 아니라 우리 제약조건 아래에서의 선택 기록이다. 다른 제약을 가진 팀에게는 다른 결론이 나올 수 있다.

이 글의 존재 이유

실측을 했다는 게 요점이 아니다. 실측은 했는데 그 결과를 잘못 읽었다는 게 요점이다.

회신이 실패했다는 관측은 정확했다. 거기서 “이 기능은 이런 구조다”로 건너뛴 것이 틀렸다. 실측은 데이터를 주지 원인을 주지 않는다. 그런데 실패한 시험을 보면 원인이 대상 쪽에 있다고 읽고 싶어진다 — 내 시험 설계가 틀렸을 가능성보다 도구의 한계라는 설명이 편하기 때문이다. 그 오진의 대가로 조직도를 한 번 갈아엎었고, 필요 없는 문서 수정과 도구 조사를 했다.

같은 날 두 번째 오판도 같은 모양이었다. 버전이 낮아서 안 되나 싶어 터미널에서 claude --version을 찍었더니 낮은 숫자가 나왔고, “구버전이라 안 되는 것”이라고 판단했다. 실제로 돌고 있던 건 에디터 확장이었고 그쪽은 최신이었다. 터미널에서 잡히던 건 아무 상관 없는 별개 설치본이었다. 눈에 보이는 숫자를 실행 주체와 대조하지 않은 것이다. 문서와 요약을 그대로 믿은 사고도 하나 더 있었다 — 버전 정보를 요약본으로 받았다가 존재하지 않는 버전을 믿을 뻔했고, 원문 파일을 직접 뒤져서 걸렀다.

하루에 두 번, 같은 형태로 틀렸다.

🧭 기획자·사업자라면 ① 도구 문서의 약속과 실제 도달은 다른 값이다. “에이전트끼리 협업합니다”는 대개 사실이지만 어느 조건에서 되는지는 안 적혀 있다. 기능 소개를 조직 설계의 전제로 그대로 옮기면 나중에 사람이 그 빈틈을 메우게 된다. ② 중앙집중은 선택이 아니라 부산물로 생긴다. 회신 경로가 없다는 것 하나만으로 모든 대화가 총괄을 지나가는 구조가 될 뻔했다. 조직도가 아니라 정보가 실제로 흐르는 경로를 그려봐야 안다. ③ 한 번 확인했다고 끝이 아니다. 실패한 시험을 보면 먼저 의심할 것은 대상의 기능이 아니라 내 시험 설계다. 결론을 조직도에 박기 전에 “내가 안 바꿔본 조건이 있나”를 한 번 물어라. 이 질문 하나가 잘못 잡은 방향을 되돌렸다.

아직 안 끝났다

그날 저녁 기준으로 남은 건 보드 문서 여덟 개, 그리고 버린 설계 두 개와 버린 진단 하나다.

닫히지 않은 것부터 적어둔다.

세션이 닫히면 팀도 죽는다. 이 구조는 총괄 세션이 살아 있는 동안만 성립한다. 세션을 닫으면 데스크도 멈춘다. 진짜 무인 상주는 유료 호스팅 영역이라 규칙 1에 걸려 채택하지 않았다. 지금의 “24시간”에는 기계가 켜져 있는 동안이라는 단서가 붙어 있다.

토큰은 데스크 수에 비례해 늘어난다. 데스크마다 독립 컨텍스트를 들고 있어서 그렇다. 추가 과금은 없지만 사용량은 늘고, 필요 이상으로 안 띄우는 것 말고는 대응책이 없다.

한 이름에 데스크는 하나뿐이다. 같은 이름으로 두 번 띄우면 주소가 갈라져 메시지가 반려된다. 데스크를 여럿 띄워 굴리기 시작하면 이름 관리가 곧 운영 부담이 된다는 뜻인데, 그 규모에서 어떻게 되는지는 아직 안 해봤다.

2편에서는 이 팀에게 실제 일을 시킨다. 계측 기반을 깔고 소싱 기준표를 만드는 작업이 큐에 올라가 있고, 데스크들이 서로 물어가며 그걸 끝낼 수 있는지가 다음 글의 내용이다. 오늘 확인한 건 두 데스크 사이에서 답이 돌아온다는 것까지다. 그게 일이 되는지는 아직 모른다.