그날 오후에 계산을 해보았습니다. 오후 2시부터 8시까지 — 6시간 동안 — 저는 Cursor에서 16개의 서브에이전트(subagents)를 열었습니다. 4개씩 4개 파동으로, 모두 병렬로 실행되었습니다. 합산된 결과물은 약 500KB의 문서였으며, 이는 대략 중편 소설 한 권 정도의 분량입니다.

제품 측면에서는, Cloudflare Worker가 Stripe 전용에서 Stripe + Creem 병렬 결제로 업그레이드되었습니다. 4개의 실제 제품이 프로덕션 환경에서 운영 중입니다. 12개의 모든 웹훅 (webhook) 이벤트 유형이 엔드투엔드 (end-to-end)로 검증되었습니다.

이 모든 것을 저 혼자 해냈습니다. 하지만 혼자서 한 것은 아닙니다.

서브에이전트 (subagent)란 무엇인가

Cursor (Claude Code, Cline, Aider도 마찬가지)는 메인 에이전트 (main agent)로부터 서브에이전트 (subagents)를 생성할 수 있습니다. 각 서브에이전트는 독립적인 작업 프롬프트 (task prompt), 독립적인 컨텍스트 윈도우 (context window), 독립적인 모델 인스턴스 (model instance)를 가집니다. 또한 도구 (tools)를 호출하고, 파일을 읽고, 파일을 쓸 수 있습니다.

작업이 완료되면, 서브에이전트는 결과를 메인 에이전트에게 반환하며, 메인 에이전트는 이를 통합합니다.

핵심적인 속성은 **병렬성 (parallelism)**입니다. 4개의 서브에이전트가 동시에 각각 30분 동안 실행되면, 메인 에이전트는 실제 시간 30분 만에 120분 분량의 결과물을 얻게 됩니다.

그날 왜 16개를 열었는가

프로젝트는 B2B 데이터 API인 datenix.xyz입니다. 주요 작업은 Creem 결제를 Cloudflare Worker에 연결하는 것이었습니다. 이는 구체적이고 기술적이며, 혼자서 할 수 있는 작업입니다.

하지만 동시에 저는 다음과 같은 작업들이 필요했습니다:

• Creem의 전체 API 연구 (43개의 엔드포인트 (endpoints), 12개의 웹훅 (webhook) 유형, 다양한 페이로드 (payload) 형태)
• Creem과 Stripe 비교 및 주 결제 수단 결정
• 기존 워커 (worker) 코드 분석 및 통합 지점 결정
• 가격 티어 (pricing tiers) 설계
• 완전한 테스트 스위트 (test suite) 작성
• 관리자 CLI 작성
• 모니터링 스크립트 작성
• 랜딩 페이지 재작성 (신뢰 및 안전 블록, 소개 페이지, 문의 페이지, 환불 배지 추가)
• KYC 승인 패턴 조사 (Creem의 공개 사례 연구, 거절 사례)
• 런칭 런북 (launch runbook) 작성 (KYC 이후 6개 명령어)
• SESSION_HANDOFF 작성 (다음 에이전트가 이어받을 수 있도록)
• 구축할 가치가 있는 플릿 레이어 (fleet-layer) 추상화가 있는지 결정
• TypeScript로 마이그레이션할지 여부 결정

이 모든 것을 혼자서 했다면 3일이 걸렸을 것입니다. 만약 이 모든 것을 단일 서브에이전트 (subagent)에게 맡겼다면, 컨텍스트 윈도우 (context window)가 폭발했을 것입니다.

분할 정복 (Divide and conquer). 각 서브에이전트는 하나의 집중된 작업을 맡고, 4.7-fast 모델을 사용하여 3040분 내에 완료합니다. 4개를 병렬로 실행하면 약 한 시간 만에 4,0005,000단어 분량의 심층 분석 보고서 4개를 얻을 수 있습니다.

Wave는 나의 시간 단위입니다

나는 서브에이전트들을 4개 단위의 웨이브 (wave)로 구성했습니다. 이유는 다음과 같습니다:

• 4개는 복잡하지 않습니다 — Cursor UI가 4개 서브에이전트의 상태를 동시에 표시할 수 있습니다.
• 각 웨이브 완료 → 결과 검토 → 다음 웨이브 결정 → 긴밀한 피드백 루프 (feedback loop)
• 4개 웨이브 = 하나의 완전한 반복 (iteration) (탐색 → 설계 → 구축 → 마무리)

그날의 4개 웨이브:

• W48 — Creem 탐색 (전체 API 레퍼런스 / Stripe 비교 / 통합 계획 / 가격 책정)
• W49 — 구축 (TypeScript 프로바이더 / 관리자 CLI + 모니터 / 랜딩 v4 / 테스트 스위트)
• W50 — 마무리 (출시 런북 / 리팩터링 계획 / 부트스트랩 강화 / SESSION_HANDOFF 통합)
• W51 — KYC 심층 분석 (승인 패턴 / 제품 허용 가능성 / 랜딩 다듬기 / CN 지급 전략)

웨이브 사이에는 약 15~20분 동안의 통합 과정을 거칩니다 — 각 서브에이전트의 결과물을 프로젝트에 반영하고 충돌 여부를 확인합니다.

프롬프트 (Prompt)는 서브에이전트가 가진 유일한 조종 핸들입니다

서브에이전트는 단기 기억이 없습니다. 생성될 때마다 새로운 컨텍스트 (context)를 가집니다. 오직 프롬프트에 있는 내용만 알고 있습니다.

나쁜 프롬프트 → 서브에이전트의 이탈.

나의 서브에이전트 프롬프트 템플릿은 다음과 같습니다:

컨텍스트 (Context, 검증된 사실) · 이미 확인된 내용, 코드가 위치한 곳, 설정된 환경 변수 (env vars) 등을 알려주는 5~10줄의 내용. 이는 서브에이전트가 추측하는 것을 방지합니다.

자매 프로젝트 자산 (Sister-project asset) · 형제 프로젝트에서 재사용할 수 있는 것을 알려주는 3~5줄의 내용. 바퀴를 다시 발명하는 것을 방지합니다.

목표 (Goal) · 산출물을 명시하는 1~2개의 단락.

전달 사항 (Deliver) · 정확히 무엇을 생성해야 하는지 나열한 섹션들, 각 섹션은 수백 단어 분량.

제약 사항 (Constraints) · 명시적인 금기 사항, 예: "이 파일은 절대 건드리지 말 것", "500~800단어로 압축하여 반환할 것", "허위 사실 생성 금지".

예산(Budget) · 30~40분. 따라서 시간 범위(time envelope)를 알게 됩니다.

출력 위치(Write to) · 명시적인 출력 경로.

이 템플릿을 사용했을 때, 서브에이전트의 표류율(drift rate)은 약 10%입니다. 표류가 발생하면 근본 원인은 보통 제 Context 섹션이 충분히 구체적이지 않았기 때문이며, 서브에이전트가 추측했기 때문입니다. 이는 신입 직원을 온보딩하는 것과 같은 원리입니다.

현실 점검(Reality check)이 제가 지불하는 가장 큰 비용입니다

서브에이전트를 사용할 때 가장 큰 위험은 **자신감 있는 허위 사실 생성(confident fabrication)**입니다.

그날의 W52 웨이브에서 네 개의 서브에이전트 중 세 개가

메인 에이전트(main agent)가 반드시 해야 할 일

메인 에이전트는 단순한 오케스트레이터(orchestrator)가 아닙니다. 다음과 같은 몇 가지 필수 과업이 있습니다:

1. 각 웨이브(wave)의 출력물을 프로젝트에 단계적으로 반영(Stage): 구문(syntax), 경로 충돌(path collisions), 명명 규칙(naming) 등을 확인합니다. 서브에이전트(subagent)가 작성한 내용을 읽어야 합니다 — 정말로 제대로 읽어야 합니다. 한 번은 W49-2의 관리용 CLI에서 작은 비동기 래핑(async-wrapping) 버그가 있었는데, 메인 에이전트가 5분 만에 이를 잡아냈습니다.

2. 인수인계(handoff) / 할 일(TODO) / 결정 사항(DECISIONS) 업데이트: 다음 웨이브의 서브에이전트가 최신 상황을 읽을 수 있도록 합니다. 긴 프로젝트에서는 쉽게 건너뛰기 쉬운 부분입니다.

3. 각 웨이브의 출력물 압축(Compact): 서브에이전트의 보고서는 3,0005,000단어에 달합니다. 이를 다음 웨이브에 그대로 입력하면 컨텍스트 윈도우(context window)가 버티지 못합니다. 메인 에이전트는 이를 200500단어 요약본으로 압축하여, 핵심 결정 사항만을 다음 웨이브로 전달해야 합니다.

4. 어떤 서브에이전트의 제안을 채택할지 결정: W50-2는 "TypeScript 리팩토링을 Y1로 미루자"고 제안했고, 이를 채택했습니다. W49-2는 "KV 캐시(KV cache) 레이어를 추가하자"고 제안했지만, 채택하지 않았습니다 — 아직 트래픽이 캐싱을 정당화할 수준은 아니기 때문입니다.

하루에 16개는 너무 많은가

그날 업무가 끝날 무렵, 메인 에이전트의 컨텍스트(context)는 거의 가득 찼습니다. 여기서 더 늘어난다면 재개(resume) 기능을 사용하여 새로운 세션을 시작해야 했을 것입니다.

대략적인 추정치는 다음과 같습니다:

• 각 서브에이전트의 압축된 반환값 ~500–1,000 토큰(tokens)
• 메인 에이전트의 처리 과정, 자체 코드 수정, 도구 호출(tool calls), 서브에이전트당 토큰 오버헤드 포함 ~3,000–5,000 토큰
• 16개 서브에이전트 사용 시 메인 컨텍스트 내 ~50,000–80,000 토큰

200K 컨텍스트를 가진 모델이라면 20~30개의 서브에이전트를 더 수용할 수 있습니다. 하지만 메인 에이전트가 혼잡해질수록 출력 품질은 낮아집니다.

저의 현재 실질적인 한계치는 세션당 12~16개의 서브에이전트입니다. 이를 초과하면 새로운 세션을 시작하고, 새로운 메인 에이전트가 인수인계 문서(handoff doc)로부터 작업을 재개하도록 합니다. 이것이 제가 세션 종료 시 SESSION_HANDOFF를 강박적으로 작성하는 이유입니다.

직관에 반하는 결론

메인 에이전트가 코드를 적게 작성할수록, 전체 시스템의 생산량은 늘어납니다.

그날 저는 개인적으로 약 1,000줄 정도를 타이핑했습니다. 나머지는 서브에이전트들이 작성했습니다. 하지만 제 시간은 다음 작업에 투입되었습니다:

• 서브에이전트 (subagent) 프롬프트 작성 (각 500800단어 × 4개 = 웨이브당 2,0003,000단어)
• 결과물 읽기 (각 500~1,000단어)
• 파일 스테이징 (Staging), 구문 검사 (syntax checks), 테스트 실행
• 다음 웨이브 결정

이것은 개발자 (developer)의 업무라기보다 테크 리드 (tech-lead)의 업무에 더 가깝습니다.

저는 이전에는 AI 도구의 가치가 저를 대신해 코드를 작성해 주는 것에 있다고 생각했습니다. 그날 제 생각은 바뀌었습니다. AI 도구의 진정한 가치는 제가 동시에 여러 가지를 생각할 수 있게 해주는 것일지도 모릅니다. 인간의 뇌는 한 번에 하나의 작업만 수행합니다. 하지만 인간은 네 명의 서브에이전트를 감독할 수 있습니다.

이것이 실제 일상적인 패턴이 된 방식

이제 복잡한 작업에 직면하면 저는 적극적으로 자문합니다: "이 작업을 4개의 병렬 서브에이전트로 나눌 수 있을까?"

고객이 3개의 버그를 보고합니다. 예전의 저라면: 순차적으로 수정했을 것입니다. 지금의 저라면: 3개의 서브에이전트를 생성하여 각각 하나씩 수정하게 하고, 메인 에이전트가 테스트 및 통합을 수행합니다. 처리량이 3배가 됩니다.

시장 조사: "datenix의 가격을 $X로 할 것인가, $Y로 할 것인가." 예전의 저라면: 혼자서 몇 시간 동안 구글링을 했을 것입니다. 지금의 저라면: 3개의 서브에이전트를 활용합니다. 하나는 경쟁사 가격 책정, 하나는 타겟 포럼의 사용자 불편 사항, 하나는 단위 경제성 (unit economics)을 담당합니다. 메인 에이전트가 결정을 종합합니다.

이 패턴은 1인 제품 개발 작업에 완벽하게 부합합니다. 솔로 개발자 (Solo dev)는 빠르지만 싱글 스레드 (single-threaded) 방식이라 무언가를 놓치기 쉽습니다. 서브에이전트와 함께라면 커버리지는 더 넓어지고 결정의 품질은 더 높아집니다.

서서히 커지는 걱정

제 자신의 코딩 기술이 퇴화할 정도로 서브에이전트에 의존하게 될까 봐 약간의 우려가 있습니다.

저는 여전히 핵심 로직은 직접 작성합니다 — 12개 이벤트 웹훅 디스패처 (webhook dispatcher), HMAC 검증기 (validator), D1 마이그레이션 (migration) 등입니다. 테스트, 문서, 관리용 CLI, 조사 보고서와 같은 주변적인 작업만 서브에이전트에게 맡깁니다.

그리고 메인 에이전트는 서브에이전트가 작성한 모든 줄을 반드시 읽어야 합니다. 승인해야 합니다. 그렇지 않으면 프로덕션 버그가 발생했을 때 어디서부터 시작해야 할지 갈피를 잡지 못하게 됩니다.

1인 제품 구축은 당신의 뇌가 가장 큰 자산임을 의미합니다. 도구는 뇌를 대체하는 것이 아니라 증폭시키는 것입니다.

그날 일과를 마치고 종료하기 전, 저는 전체 세션 타임라인을 담은 30KB 분량의 핸드오프 (handoff) 문서를 작성했습니다. 왜냐하면 저는 알고 있기 때문입니다. 내일 아침이면 오늘 다루었던 세부 사항의 60%는 제 머릿속에서 사라질 것이라는 사실을 말입니다. 하지만 서브에이전트 (subagents)들은 잊지 않을 것입니다. 왜냐하면 그들 자체가 바로 그 문서이기 때문입니다.