Claude Code에서 큰 규모의 태스크를 한 세션에서 통째로 맡기면, 대개 다음과 같은 상황이 발생합니다.

• 도중에 전반부의 결정을 잊어버림
• 파일을 넘나드는 수정 과정에서 일관성이 깨짐
• 컨텍스트 (Context)가 넘쳐서 정확도가 떨어짐
• "결국 파일 하나씩 직접 다시 지시하게 되는" 상황에 처함

원인은 모델의 지능 문제가 아니라, 하나의 컨텍스트에 모든 것을 집어넣는 설계에 있습니다.

이를 해결하는 것이 바로 **서브 에이전트 (Sub-agent)**입니다. 태스크를 분할하여 별도의 컨텍스트에서 병렬로 실행함으로써, 부모 세션(Parent Session)을 가볍게 유지하면서도 큰 작업을 처리할 수 있습니다.

이 기사에서는 서브 에이전트를 '기능으로서 알고 있는' 상태에서 '실무에서 제대로 활용할 수 있는' 상태로 나아가기 위한 구체적인 패턴 5가지를 소개합니다. 모두 복사해서 오늘부터 바로 시도해 볼 수 있습니다.

서브 에이전트는 부모 세션으로부터 분리된 독립적인 컨텍스트를 가진 별도의 Claude입니다.

부모 세션 (당신이 대화하고 있는 상대)
├─ 서브 에이전트 A (독립 컨텍스트)
├─ 서브 에이전트 B (독립 컨텍스트)
...

중요한 점은 다음 두 가지입니다.

• 서브 에이전트의 작업 이력은 부모의 컨텍스트를 소비하지 않음 — 각 서브 에이전트는 자신의 윈도우에서 작업하며, 부모에게는 '결과(최종 보고)'만을 반환합니다.
• 여러 개를 병렬로 실행할 수 있음 — 독립적인 태스크라면 동시에 던져서 대기 시간을 압축할 수 있습니다.

즉 서브 에이전트는 '병렬 처리'인 동시에, 컨텍스트의 분산 투자이기도 합니다. 이 점을 이해하고 있느냐에 따라 활용법이 달라집니다.

가장 효과가 크지만, 가장 많이 간과되는 것이 바로 이것입니다.

큰 태스크의 시작에는 반드시 '코드베이스를 읽고 현황을 파악하는' 페이즈(Phase)가 있습니다. 여기서 읽어들인 파일 내용은 구현 페이즈에서는 거의 필요하지 않습니다. 그럼에도 불구하고 같은 세션에서 계속 진행하면, 조사 시의 방대한 파일 내용이 부모 컨텍스트에 계속 남아 있게 됩니다.

Before (1개 세션에서 전부 수행):

"인증 관련 부분을 리팩토링해줘. 우선 src/auth/ 하위 내용을 전부 읽어서
현황을 파악한 뒤에 구현해줘"
→ src/auth/ 의 모든 파일 내용이 부모 컨텍스트에 계속 자리 잡음
...

After (조사를 서브 에이전트에게 위임):

"서브 에이전트로 src/auth/ 하위를 조사해 주세요.
보고해주길 바라는 것은 다음 3가지뿐입니다:
1. 현재 인증 방식 (JWT / 세션 등)
...

서브 에이전트는 방대한 파일을 읽지만, 부모에게 반환되는 것은 요약된 3가지뿐입니다. 부모 컨텍스트는 수십 줄 정도만 소비합니다. 그 후, 이 요약을 바탕으로 구현을 지시합니다.

포인트: 서브 에이전트에 대한 지시에는 "무엇을 보고해주길 원하는가"를 반드시 적어야 합니다. 이것이 없으면 서브 에이전트는 읽은 내용을 전부 장문으로 반환하여, 어렵게 분리한 효과가 희석됩니다.

서로 의존하지 않는 태스크는 한꺼번에 병렬로 기동하는 것이 정석입니다.

"다음 3가지를 각각 별도의 서브 에이전트로 병렬 실행해 주세요.
서로 의존 관계는 없습니다.
1. src/components/UserList.tsx 를 구현
...

순차적으로 진행하면 3개 태스크만큼의 시간이 걸리지만, 병렬이라면 가장 느린 1개 태스크만큼의 시간으로 끝납니다.

병렬로 하면 안 되는 케이스도 있습니다. 태스크 간에 의존성이 있을 때(B의 구현 결과를 C가 참조하는 등)는 병렬로 진행하면 한쪽이 미완성인 상태로 진행되어 버립니다. 그 경우에는 의존 순서에 따라 순차적으로 던져주세요.

판단 기준은 간단합니다.

서브 에이전트는 부모의 대화 흐름을 공유하지 않습니다. 당신이 10번의 대화를 거쳐 쌓아 올린 전제 조건을 서브 에이전트는 아무것도 모르는 상태에서 시작합니다.

따라서 지시는 **그 자체만으로 완결되는 '계약서'**로서 작성해야 합니다. 최소한 다음 4가지 요소를 포함해 주세요.

【태스크】 무엇을 만들/조사할 것인가 (1줄로)
【입력】 읽어야 할 파일 · 전제 조건
【제약】 지켜야 할 규칙 · 금지 사항
...

구체적인 예시:

【태스크】 src/api/users.ts に 사용자 검색 엔드포인트 추가
【입력】 기존의 src/api/users.ts 와 prisma/schema.prisma 를 참조
【제약】
...

이 형식을 지키는 것만으로도 서브 에이전트(Sub-agent)가 '멋대로 해석하여 폭주하는 현상'을 급격히 줄일 수 있습니다. 반대로, 모호한 한마디(예: "사용자 검색을 추가해줘")로 던지면, 전제 조건을 모르는 서브 에이전트는 상상으로 내용을 채워버립니다.

서브 에이전트를 사용하기 시작하면, 자기도 모르게 부모 세션(Parent Session)에도 작업을 시키고 싶어집니다. 이것이 컨텍스트(Context)를 넘치게 만드는 함정입니다.

역할을 명확히 나눕니다.

부모 세션 (당신이 직접 대화하는 곳)
└ 역할: 태스크 분할 · 지시 · 결과물 리뷰 · 통합
→ 코드 구현 자체는 시키지 않음
...

부모가 직접 대량의 파일을 읽거나 긴 코드를 작성하게 되면, 결국 부모 컨텍스트가 비대해져서 서브 에이전트를 사용하는 의미가 퇴색됩니다. **"부모는 사령탑, 자식은 실무"**를 철저히 지키는 것이 요령입니다.

실무 플로우로 구성하면 다음과 같습니다.

1. 부모: 태스크를 3개로 분할하고, 각각에 대한 계약서(Contract)를 작성함
↓
2. 부모: 3개를 서브 에이전트에게 전달 (독립적이라면 병렬 실행)
...

서브 에이전트는 독립된 컨텍스트에서 동작하기 때문에, 부모가 파악하지 못한 전제의 차이가 발생할 수 있습니다.

• A와 B가 동일한 함수 이름을 서로 다른 의미로 구현함
• 공통 타입 정의(Type Definition)에 대해 각자 다르게 해석함
• 한쪽이 변경한 파일을 다른 한쪽이 과거의 전제로 참조함

이를 방지하려면, 통합 단계(Integration Phase)에서 부모가 명시적으로 검증하도록 해야 합니다.

"3개 서브 에이전트의 결과물을 통합합니다. 다음 사항을 확인해 주세요:
1. 3자 간에 타입 정의 · 함수 시그니처(Function Signature)에 모순이 없는가
2. import 경로의 정합성
...

"병렬 실행으로 빠르다"는 장점은, 이 검증 단계를 생략하는 순간 쉽게 사라집니다. 속도와 정확성은 세트로 설계해야 합니다.

서브 에이전트는 단순히 "기능을 알고 있다"는 것만으로는 효과를 볼 수 없습니다. 태스크를 어떻게 나누고, 어떻게 계약을 작성하며, 어떻게 통합할 것인가라는 설계가 뒷받침되어야 비로소 부모 컨텍스트를 가볍게 유지하면서도 큰 규모의 작업을 처리할 수 있습니다.

여기서 언급한 5가지 유형은 모두 오늘 세션부터 바로 시도해 볼 수 있습니다. 우선 "유형 1: 조사와 구현을 분리"만이라도 적용해 본다면, 컨텍스트 유지 능력이 체감될 정도로 달라질 것입니다.

이 글에서 소개한 서브 에이전트 설계를 실제 프로젝트에 적용하려면, 토대가 되는 CLAUDE.md와 폴더 구조가 있어야 원활합니다. 제가 사용 중인 스타터 구성을 무료로 공개하고 있습니다.

무료 스타터 (GitHub):

CLAUDE.md 템플릿 · Hooks 샘플 · 기본 폴더 구성이 포함되어 있습니다. 우선 이것을 토대로 위의 유형 1부터 시도해 보세요.

더 나아가 서브 에이전트 분할 · 병렬 실행 · 계약 설계 등을 "실행 가능한 스킬 파일"로 정리한 패키지도 준비되어 있습니다. 로컬에서 /명령어 형태로 호출할 수 있는 구조로 되어 있어, 매번 프롬프트를 다시 작성하는 번거로움을 줄여줍니다.

스타터 팩 (¥1,980): CLAUDE.md 템플릿 7종 · Hooks · MCP 설정
https://streamsolty.gumroad.com/l/gliwz

워크플로우 OS (¥9,800): 79개의 스킬 + 워크플로우 3개 + 프롬프트 10종

우선 무료 리포지토리부터 시도해 보시고, 더 체계적으로 사용하고 싶을 때 검토해 주셔도 충분합니다. 이 글의 유형들만 활용해도 효과는 나타납니다.

최신 팁은 X에서도 발신하고 있습니다: @k___n___t_1125