8장. 서브에이전트: 1인 개발팀 만들기

혼자 제품을 만들다 보면 묘한 착각에 빠진다. 분명 혼자인데, 머릿속에는 네 명이 동시에 떠든다.

"이거 진짜 필요한 기능 맞아?" "구조부터 다시 잡아야 하는 거 아냐?" "일단 돌아가게 만들자." "잠깐, 이거 나중에 사고 난다."

이 네 목소리는 각각 PM, 아키텍트, 구현자, 리뷰어다. 문제는 이들이 줄을 서서 말하지 않는다는 데 있다. 혼자 일할수록 기획과 구현과 검토가 한 세션 안에서 뒤엉키고, 그 결과는 익숙하다. 계획은 흐려지고, 구현은 조급해지고, 리뷰는 자기합리화로 끝난다.

서브에이전트는 이 혼선을 잘라내는 도구다. Claude Code의 서브에이전트는 별도 컨텍스트, 별도 시스템 프롬프트, 별도 도구 권한, 별도 모델 선택을 가진 독립 작업자다.¹ 쉽게 말해, 혼자 일하되 한 번에 한 역할만 제대로 하게 만드는 장치다.

이 장의 핵심은 단순하다. 솔로 빌더에게 필요한 것은 더 많은 AI가 아니라, 더 분명한 역할 분리다. 역할이 분리되면 사고의 질이 올라가고, 역할이 병렬화되면 처리량이 올라간다. 둘 다 얻을 수 있다.

8.1 서브에이전트가 해결하는 문제와 만드는 문제

서브에이전트를 처음 접하면 이렇게 이해하면 된다. 메인 세션이 감독이라면, 서브에이전트는 특정 임무를 맡는 전문 스태프다. 탐색은 탐색가에게, 구조 판단은 아키텍트에게, 수정은 구현자에게, 검증은 리뷰어에게 맡긴다. Claude Code에는 Explore, Plan, general-purpose 같은 내장 서브에이전트도 있고, 사용자가 .claude/agents/나 ~/.claude/agents/에 직접 커스텀 에이전트를 만들 수도 있다.¹

왜 이게 중요할까. 혼자 개발할 때 가장 비싼 비용은 토큰만이 아니다. 역할 전환 비용이 더 크다. 방금까지 로그를 뒤지던 머리로 곧바로 아키텍처 결정을 내리고, 그 상태로 코드를 수정한 뒤, 같은 머리로 자기 코드를 리뷰하면 대개 세 가지가 벌어진다.

• 탐색 결과가 메인 컨텍스트를 어지럽힌다.

• 구현자가 아키텍트인 척 큰 결정을 슬쩍 해 버린다.

• 리뷰어가 이미 작성된 코드에 정서적으로 끌려간다.

서브에이전트는 이 세 문제를 꽤 우아하게 줄여 준다. 탐색 결과는 별도 컨텍스트에 격리되고, 역할별 시스템 프롬프트로 행동 기준을 분리할 수 있으며, 읽기 전용 권한을 준 리뷰어는 "수정해 버리기" 대신 "문제를 지적하기"에 집중한다.¹²

하지만 좋은 소식만 있는 것은 아니다. 서브에이전트는 문제를 해결하는 동시에 새로운 문제도 만든다. 가장 흔한 것은 핸드오프 손실이다. PM이 만든 요구사항이 아키텍트에게 요약 전달되며 빠지고, 아키텍트의 제약이 구현자에게 충분히 전달되지 않으면, 구현자는 나쁜 뜻 없이도 엉뚱한 결정을 한다. 멀티 에이전트 워크플로에서 반복적으로 나타나는 실패 모드가 바로 이런 문맥 드리프트, 병렬 충돌, 침묵한 가정이다.³

또 다른 문제는 가짜 팀의 탄생이다. 에이전트를 네 개 만들었다고 팀이 생기는 건 아니다. 오히려 역할이 겹치면 회의만 늘어난다. PM도 계획을 세우고 아키텍트도 계획을 세우고 구현자도 다시 계획을 세우면, 혼자 일하는데도 승인 라인이 세 겹이 된다. 그러면 속도가 느려질 뿐 아니라, 누가 최종 책임자인지도 흐려진다.

그래서 첫 원칙은 분명하다. 서브에이전트는 사람 수를 늘리는 도구가 아니라 책임 경계를 선명하게 만드는 도구다. 역할이 모호하면 숫자만 늘어난다.

8.2 PM, 아키텍트, 구현자, 리뷰어 4단계 파이프라인 설계

솔로 빌더에게 가장 실용적인 기본 팀은 네 역할이면 충분하다. PM, 아키텍트, 구현자, 리뷰어. 여기에 QA나 보안 리뷰어를 더 붙일 수도 있지만, 처음부터 조직도를 크게 그릴 필요는 없다. 이 네 역할만 잘 서도 혼자 일하는 방식이 확 달라진다.

먼저 각 역할의 책임을 한 줄씩 못 박자.

• PM은 "무엇을 왜 만드는가"를 정리한다.

• 아키텍트는 "어디를 어떻게 바꿀 것인가"를 결정한다.

• 구현자는 "실제로 바꾸고 검증하는 일"을 맡는다.

• 리뷰어는 "이 변경이 문제를 만들지 않는가"를 따진다.

이 구분이 중요한 이유는, 네 역할이 서로 다른 산출물을 가져야 하기 때문이다. 산출물이 다르면 역할이 덜 섞인다.

PM은 짧은 기능 브리프를 만든다. 여기에는 사용자 문제, 성공 기준, 범위 밖 항목, 미해결 질문만 있으면 된다. 좋은 PM 에이전트는 화려한 문서를 쓰지 않는다. 오히려 구현자가 바로 움직일 수 있는 작은 티켓 묶음을 만든다.

아키텍트는 브리프를 받아 구조 결정을 내린다. 어떤 파일이 바뀌는지, 기존 패턴을 따를지 새 추상화를 만들지, 성능·보안·마이그레이션 리스크는 무엇인지 정리한다. 여기서 중요한 것은 '멋진 설계'가 아니라 구현자가 임의 판단하지 않아도 되게 만드는 제약 문서를 만드는 일이다. 길게 쓰기보다 ADR 한 장처럼 짧고 단단해야 한다.³

구현자는 가장 실용적이어야 한다. 아키텍트가 정한 경계 안에서 파일을 수정하고, 테스트를 추가하고, 필요한 명령을 실행해 결과를 확인한다. 구현자가 구조까지 다시 결정하기 시작하면 파이프라인이 무너진다. 구현자는 질문할 수는 있지만, 큰 방향을 재정의하면 안 된다.

리뷰어는 마지막 방어선이다. 그런데 여기서 자주 오해가 생긴다. 리뷰어의 목적은 '모든 걸 다시 생각하는 것'이 아니다. 리뷰어는 diff 중심으로 위험을 찾고, 아키텍처 제약 위반이 있는지, 테스트 누락이 있는지, 보안상 거슬리는 부분이 있는지 우선순위별로 정리해야 한다. 즉, 재설계자가 아니라 검증자여야 한다.

이 네 단계를 연결하면 다음과 같은 흐름이 나온다.

PM → 아키텍트 → 구현자 → 리뷰어

하지만 실전에서는 이 흐름을 조금 더 정교하게 다루는 편이 좋다. PM과 아키텍트는 대부분 순차 실행이 맞다. 문제 정의가 흐린데 구조를 먼저 잡으면, 예쁜 오답이 나온다. 반면 구현과 리뷰는 분해와 병렬화의 여지가 크다. 예를 들어 구현자는 프론트엔드와 백엔드로 나눌 수 있고, 리뷰어는 품질 리뷰와 보안 리뷰로 분리할 수 있다.

중요한 것은 메인 세션이 지휘자 역할을 해야 한다는 점이다. 서브에이전트는 독립적으로 작업하지만, 무한히 서로를 다시 호출하며 자라나는 조직은 아니다. Claude Code의 서브에이전트 구조에서는 메인 세션이 작업을 분해하고 결과를 합치는 쪽이 더 안정적이다.¹

아래처럼 아주 얇은 팀부터 시작하면 된다.

---
name: pm
description: 새 기능 요청을 작은 작업 단위와 명확한 성공 기준으로 정리한다.
tools: Read, Grep, Glob
model: sonnet
---

당신은 PM이다.
요구사항을 다음 형식으로 정리하라.
- 사용자 문제
- 성공 기준
- 범위 밖
- 미해결 질문
- 구현 티켓 3~7개

---
name: architect
description: 기능 브리프를 바탕으로 수정 범위와 구조 제약을 정한다.
tools: Read, Grep, Glob
model: opus
---

당신은 아키텍트다.
다음 형식으로만 답하라.
- 바뀌는 파일/모듈
- 설계 결정
- 피해야 할 선택
- 리스크
- 구현 순서

---
name: implementer
description: 승인된 설계에 따라 코드를 수정하고 테스트로 검증한다.
tools: Read, Edit, Write, Grep, Glob, Bash
model: sonnet
---

당신은 구현자다.
설계 제약을 벗어나지 말고 최소 변경으로 구현하라.
수정 후 테스트 또는 빌드로 확인하라.

---
name: reviewer
description: 변경사항을 diff 중심으로 검토하고 위험도를 분류한다.
tools: Read, Grep, Glob, Bash
model: sonnet
---

당신은 리뷰어다.
반드시 critical, warning, suggestion으로 나눠 보고하라.
스타일 취향보다 버그, 회귀, 보안, 테스트 누락을 우선하라.

이 구성이 좋은 이유는 화려해서가 아니다. 각자 무엇을 하지 말아야 하는지가 분명하기 때문이다. PM은 구현하지 않고, 아키텍트는 수정하지 않고, 구현자는 재설계하지 않고, 리뷰어는 덮어쓰지 않는다. 혼자 일할수록 이 선이 생명줄이 된다.

8.3 도구 권한 화이트리스팅: 필요한 만큼만 쥐여 주기

서브에이전트를 만들 때 가장 먼저 떠오르는 유혹은 이거다. "어차피 내가 쓰는 건데 전부 열어 두자." 하지만 바로 이 생각 때문에 자동화가 무서워진다. 서브에이전트의 진짜 장점은 똑똑함이 아니라 예측 가능성인데, 권한을 다 열어 두는 순간 예측 가능성이 급격히 떨어진다.

공식 문서와 실무 가이드가 공통으로 강조하는 원칙도 같다. description은 구체적으로 쓰고, 권한은 최소한으로 시작하고, 한 에이전트는 한 책임만 맡겨라.¹² 특히 솔로 빌더는 "나 혼자니까 괜찮겠지"라고 느슨해지기 쉬운데, 그럴수록 도구 권한을 더 보수적으로 잡는 편이 좋다.

tools는 허용 목록이고, disallowedTools는 금지 목록이다. 실전에서는 화이트리스트를 먼저 정하고, 꼭 필요한 추가 안전장치만 disallowedTools로 막는 식이 안정적이다. 리뷰어에게 Edit와 Write를 줄 이유는 거의 없다. 반대로 구현자에게 Bash를 주더라도, 실제로는 테스트·빌드·린트 정도만 필요할 가능성이 크다.

예를 들어 리뷰어는 이렇게 시작하면 된다.

---
name: reviewer
description: 코드 변경 직후 회귀, 보안, 테스트 누락을 점검한다.
tools: Read, Grep, Glob, Bash
disallowedTools: Edit, Write
model: sonnet
---

이 설정의 느낌은 이렇다. "읽고, 찾고, diff 보고, 테스트 로그 확인은 해도 좋다. 하지만 네 손으로 파일을 바꾸지는 마라." 리뷰 품질은 오히려 이렇게 해야 오른다. 수정 권한이 있으면 에이전트는 문제를 잘 설명하기보다 얼른 고쳐 버리려는 쪽으로 기울기 쉽다.

구현자는 조금 다르다.

---
name: implementer
description: 승인된 설계대로 최소 변경을 구현하고 검증한다.
tools: Read, Edit, Write, Grep, Glob, Bash
model: sonnet
permissionMode: default
---

여기서도 핵심은 "모든 걸 다 해도 된다"가 아니다. 구현자에게 쓰기 권한은 필요하지만, 그것이 곧 무제한 자율성을 뜻하진 않는다. 구현자는 아키텍처를 갈아엎는 사람도 아니고, 배포를 밀어 넣는 사람도 아니다. 그래서 보통은 default 같은 보수적 권한 모드에서 시작하는 편이 맞다.¹

화이트리스팅을 설계할 때는 세 가지 질문이 특히 유용하다.

• 이 역할이 읽기만 하면 되는가?

• 이 역할이 셸 명령을 써야 한다면, 왜 필요한가?

• 잘못 움직였을 때 가장 비싼 실수는 무엇인가?

리뷰어라면 가장 비싼 실수는 "좋은 척하면서 코드를 건드리는 일"이다. 구현자라면 "프로젝트 규칙을 무시한 대규모 변경"일 수 있다. 아키텍트라면 "충분한 조사 없이 구조를 단정하는 일"이다. 이 질문을 먼저 던지면 권한 설계가 쉬워진다.

그리고 꼭 기억할 점이 하나 더 있다. description이 곧 라우팅 규칙이라는 사실이다. 설명이 흐리면 Claude가 언제 누구를 불러야 하는지 헷갈린다.¹² "코드 잘 보는 에이전트" 같은 설명은 대개 실패한다. 반면 "코드 변경 직후 보안·성능·테스트 누락을 점검하는 리뷰 에이전트"는 훨씬 잘 작동한다. 좋은 서브에이전트는 프롬프트보다도 description에서 절반이 결정된다고 봐도 과장이 아니다.

8.4 병렬 실행으로 작업 시간 1/4로 줄이기

서브에이전트의 가장 짜릿한 장면은 병렬 실행이다. 혼자 일하는데도 일이 동시에 굴러간다. 이 감각은 한 번 맛보면 다시 돌아가기 어렵다.

다만 여기서 중요한 오해를 먼저 풀자. "PM, 아키텍트, 구현자, 리뷰어를 모두 병렬로 돌린다"는 뜻은 아니다. 그렇게 하면 PM이 아직 문제도 정의하지 않았는데 구현자가 코드를 쓰고, 리뷰어는 없는 diff를 검토하게 된다. 병렬화는 의존성이 끊긴 구간에서만 해야 한다.

좋은 기본 패턴은 이렇다.

첫째, PM과 아키텍트는 짧게 순차 처리한다. 여기서 기능 브리프와 ADR이 나온다.

둘째, 구현 단계에서 병렬화를 건다. 예를 들어 인증 기능 추가라면 프론트 로그인 화면, 백엔드 세션 처리, 문서 갱신은 서로 다른 파일 경계를 가지는 경우가 많다. 이때 구현자를 둘 이상 두면 벽시계 시간은 크게 줄어든다.

셋째, 리뷰도 병렬화한다. 일반 코드 리뷰, 보안 리뷰, 테스트 누락 점검은 서로 다른 관점이라 동시에 돌리기 좋다. 메인 세션은 마지막에 이 결과를 합쳐 사람이 읽기 쉬운 한 장으로 정리하면 된다.

예를 들어 직렬로 하면 이런 작업이 40분 걸린다고 해 보자.

• 코드베이스 구조 파악 10분

• 백엔드 구현 10분

• 프론트엔드 구현 10분

• 리뷰와 검증 10분

이걸 잘 쪼개면 벽시계 시간은 10분짜리 네 덩어리의 합이 아니라, 앞단 순차 작업 몇 분 + 뒤단에서 가장 오래 걸린 작업 하나에 가까워진다. 그래서 체감상 "한 명이 네 명처럼 움직인다"는 느낌이 생긴다. 1/4이라는 말은 마법 주문이 아니라, 독립 가능한 작업을 독립시켰을 때 생기는 효과다.

하지만 병렬화에는 조건이 있다. 아래 세 경우가 특히 잘 맞는다.

• 읽기 중심 탐색 작업

• 서로 다른 디렉터리나 모듈을 수정하는 구현 작업

• 관점이 분리된 검토 작업

반대로 같은 파일을 두 구현자가 동시에 수정하게 만들면, 사람 팀에서의 머지 충돌이 그대로 재현된다. 멀티 에이전트도 결국 협업 시스템이기 때문에, 파일 경계와 책임 경계를 먼저 나누지 않으면 빨라지지 않는다.³

실전에서는 이렇게 생각하면 쉽다.

"병렬화는 사람을 더 넣는 게 아니라, 대기 시간을 줄이는 일이다."

혼자 작업할 때 가장 많이 낭비되는 시간은 손이 아니라 머리가 기다리는 시간이다. 테스트 돌리는 동안 멍하게 있거나, 로그 읽는 동안 구현이 멈추거나, 리뷰 기다리느라 다음 판단을 못 내리는 시간이 길다. 서브에이전트는 이 기다림을 잘게 잘라낸다.

그렇다고 모든 걸 병렬로 돌리면 또 다른 문제가 생긴다. 결과를 합치는 비용이 커진다. 리포트 세 개가 오고, 구현 diff 두 개가 오고, 로그 분석 하나가 더 오면, 마지막에 메인 세션이 편집장이 되어야 한다. 그래서 병렬화의 기준은 단순하다. 합치는 비용보다 동시에 돌리는 이익이 클 때만 병렬화하라.

솔로 빌더의 기본 운영법으로는 다음 정도가 적당하다.

• 작은 버그 수정: 서브에이전트 0~1개

• 일반 기능 추가: PM 1개, 아키텍트 1개, 구현자 1~2개, 리뷰어 1개

• 영향 범위 큰 변경: 구현자 2~3개, 리뷰어 2개까지 병렬

이 정도만 지켜도 체감 속도는 꽤 달라진다. 중요한 건 숫자가 아니라 의존성 그래프를 보는 습관이다.

8.5 서브에이전트 게이트키핑 함정 피하기

서브에이전트를 도입한 뒤 가장 자주 빠지는 함정은 의외로 기술 문제가 아니다. 조직 문제다. 정확히 말하면, 혼자 만든 작은 에이전트 팀이 갑자기 관료제가 되는 문제다.

나는 이것을 게이트키핑 함정이라고 부른다. 아키텍트가 모든 수정 전에 승인하려 들고, 리뷰어가 사소한 스타일 문제까지 배포 차단처럼 다루고, PM이 애매한 요구사항을 계속 다시 문장만 다듬고 있으면 벌어진다. 혼자 일하는데도 일은 늦고, 책임은 흐리고, 피로만 올라간다.

증상은 비교적 분명하다.

• 작은 CSS 수정에도 아키텍트 검토를 거친다.

• 구현자가 결정할 수 있는 사소한 문제까지 매번 되묻는다.

• 리뷰어가 차단 사항과 제안을 구분하지 않는다.

• PM 문서가 구현보다 길어진다.

• 결과적으로 메인 세션이 계속 중재만 하느라 실제 일이 늦어진다.

이 함정은 서브에이전트를 너무 많이 만들어서 생기기도 하지만, 더 자주 일어나는 원인은 역할의 승인권을 과도하게 준 것이다. 아키텍트는 제약을 정하는 사람이지, 모든 줄을 허가하는 사람이 아니다. 리뷰어는 리스크를 드러내는 사람이지, 자기 취향을 헌법으로 만드는 사람이 아니다.

게이트키핑을 피하려면 운영 규칙을 미리 정해 두는 편이 좋다.

• 차단 기준과 제안 기준을 분리하라. 리뷰어는 critical만 작업 중단 사유로 올리고, 나머지는 warning이나 suggestion으로 남겨야 한다.

• 에스컬레이션 조건을 명시하라. 구현자가 모든 질문을 올리는 대신, 보안·데이터 손실·스키마 변경처럼 비싼 결정만 사람이나 아키텍트에게 올리게 한다.

• 핸드오프 문서를 짧게 유지하라. PM 브리프 한 장, ADR 한 장, 리뷰 요약 한 장이면 충분하다. 문서가 길수록 전달 오류는 오히려 늘어난다.³

• 작은 변경에는 작은 파이프라인을 써라. README 수정, 문구 변경, 단순 스타일 수정까지 4단계 팀을 태우지 마라.

• 역할 중복을 줄여라. PM과 아키텍트가 둘 다 리스크 목록을 길게 만들 필요는 없다. 한쪽이 만들고 한쪽은 구조 제약만 더하면 된다.

특히 솔로 빌더는 "AI가 더 꼼꼼해야 하니까 체크를 많이 넣자"는 방향으로 흐르기 쉽다. 하지만 실제로는 반대다. 체크포인트가 많아질수록 속도는 느려지고, 느려질수록 사람은 검토를 대충 읽게 된다. 결국 품질도 떨어진다.

좋은 서브에이전트 팀은 회사 흉내를 잘 내는 팀이 아니다. 작은 팀이 작은 팀답게 빠르게 움직이도록 설계된 팀이다. 솔로 빌더에게 필요한 것은 10단계 승인 프로세스가 아니라, 딱 필요한 순간에만 작동하는 얇은 게이트다.

그래서 마지막 원칙은 이것이다. 서브에이전트는 나를 막기 위해 쓰는 게 아니라, 내가 더 큰 실수만 피하게 만들기 위해 쓴다. 작은 결정은 더 빨라져야 하고, 큰 결정만 더 신중해져야 한다. 이 균형을 잡는 순간부터 에이전트 팀은 귀찮은 절차가 아니라 진짜 가속 장치가 된다.

혼자 개발하는 사람의 가장 큰 약점은 인력이 적다는 것이 아니다. 역할이 한 몸 안에서 섞인다는 데 있다. PM의 질문, 아키텍트의 걱정, 구현자의 조급함, 리뷰어의 의심이 한 세션에서 뒤엉키면, 빠른데 불안하거나 신중한데 느려진다.

서브에이전트는 이 뒤엉킴을 역할로 잘라낸다. 그리고 역할이 분리된 순간, 혼자 일하는 사람도 비로소 팀처럼 사고할 수 있다. 이 장에서 만든 PM·아키텍트·구현자·리뷰어 파이프라인은 거창한 멀티 에이전트 시스템이 아니다. 오히려 반대다. 혼자서도 지치지 않고, 속도와 품질을 같이 가져가기 위한 최소 팀이다.

다음 장에서는 이 팀이 특정 순간에 자동으로 움직이게 만드는 장치, 즉 Hooks를 다룬다. 역할을 나눴다면, 이제 그 역할이 언제 개입할지도 정해야 한다.

참고

¹Create custom subagents - Claude Code Docs

²Claude Code Subagent 만들기: 실무에서 바로 쓰는 설계/구현 가이드

³The Multi-Agent Assembly Line: How AI Planner-Architect-Implementer-Tester-Reviewer Teams Are Replacing the Solo Dev Loop