멀티 세션과 서브에이전트

한 세션에 모든 일을 몰아 시키면 대화가 길어지고 결과가 흐려집니다. 이 장은 일을 여러 세션과 서브에이전트로 나누는 이유와 규칙, 세션 사이에 일을 넘기는 인계 문서, 컨텍스트를 관리하는 방법을 다룹니다.

왜 나누는가

컨텍스트 오염

Claude가 한 번에 볼 수 있는 내용의 범위를 컨텍스트라고 합니다. 대화가 길어질수록 컨텍스트에는 지나간 시도, 폐기된 초안, 탐색하다 만 파일 내용이 쌓입니다. 이 잡음이 많아지면 처음 정한 목표가 흐려지고, 이미 버린 방안이 다시 튀어나오기도 합니다. 공식 문서는 같은 교정을 두 번 했는데도 틀리면 세 번째 교정을 덧붙이기보다 대화를 비우고 배운 점을 담아 새로 쓰는 편이 낫다고 안내합니다(모범 사례 문서, 2026년 11월 기준).

병렬 처리

서로 의존하지 않는 일은 동시에 진행하면 전체 시간이 줄어듭니다. 자료 조사와 문서 틀 잡기는 서로 기다릴 필요가 없습니다.

핵심 일을 나누는 기준은 "서로의 결과를 기다리지 않아도 되는가"와 "맥락이 섞이면 해로운가"입니다. 둘 중 하나라도 해당하면 나눕니다.

여러 세션을 돌리는 규칙

세션은 Claude와 나누는 하나의 작업 대화입니다. 여러 세션을 동시에 쓸 때는 다음 규칙을 지킵니다.

1. 한 세션에는 한 가지 일만 맡깁니다. 세션 이름도 그 일로 짓습니다(예: 경쟁사 조사, 보고서 본문 작성).
2. 두 세션이 같은 파일을 동시에 고치게 하지 않습니다. 한쪽의 수정을 다른 쪽이 덮어쓰거나 서로 충돌합니다. 파일 소유를 세션별로 나눕니다. 조사 세션은 조사/ 폴더만, 작성 세션은 초안/ 폴더만 씁니다.
3. 세션 사이에서 일을 넘길 때는 대화 내용을 통째로 복사하지 않고 인계 문서를 거칩니다(뒤에서 설명).
4. 조사처럼 읽기만 하는 세션은 계획 모드나 읽기 전용 권한으로 돌립니다. 실수로 파일을 바꿀 가능성이 없어야 병렬로 안심하고 돌릴 수 있습니다.
5. 동시에 켜는 세션은 사람이 확인할 수 있는 수만큼만 둡니다. 처음에는 2~3개로 시작합니다.

코드 프로젝트에서는 세션마다 별도 작업 복사본(워크트리, git worktree)을 주는 방식이 공식 문서에 안내되어 있습니다. 편집이 서로 충돌하지 않도록 각 세션에 독립된 체크아웃을 주는 방법이며, 데스크탑 앱은 이런 세션을 나란히 돌리는 기능을 제공합니다(모범 사례 문서). 코드를 다루지 않는 업무에서는 위의 폴더 분리 규칙만으로 충분합니다.

서브에이전트: 전문가 팀처럼 일 맡기기

서브에이전트는 한 세션 안에서 특정 종류의 일을 맡는 보조 Claude입니다. 공식 문서에 따르면 각 서브에이전트는 자기만의 컨텍스트 창, 지침, 도구 접근 권한을 갖고 독립적으로 일한 뒤 결과 요약만 본 대화에 돌려줍니다(서브에이전트 문서, 2026년 11월 기준). 자료를 뒤지느라 생긴 긴 중간 기록이 본 대화에 쌓이지 않는다는 점이 장점입니다. 반대로 서브에이전트는 본 대화의 기록을 보지 못하므로, 맡기는 지시문에 필요한 맥락을 직접 써 줘야 합니다.

한 줄로 말하면 일의 일부를 떼어 별도의 Claude에게 맡기고 결과만 받아 오는 방식입니다. 혼자 할 때와 맡길 때는 다음이 다릅니다.

맡기는 말은 단순합니다.

서브에이전트를 나눠서 동시에 해줘.

쓰기 좋은 때는 네 가지입니다.

• 자료 여러 개를 각각 읽어야 할 때
• 문서 20개처럼 많은 것을 나눠 동시에 요약하거나 조사할 때
• 크고 여러 파일로 나뉜 데이터를 나눠 훑으며 정합성을 확인할 때
• 관점이 여러 개 필요할 때(세 관점으로 각각 검토해 비교)

서브에이전트의 모델은 따로 정하지 않으면 보통 본 대화의 모델을 따르지만, 비용을 줄이려고 가벼운 모델을 쓰는 서브에이전트도 있습니다. 결과가 중요한 일이면 중간 이상 등급의 모델을 쓰도록 직접 지정합니다. 정의 파일의 model 항목이나 지시로 정하며, 값의 종류와 우선순위는 서브에이전트 문서에서 확인합니다(2026년 11월 기준). 등급을 고르는 기준은 1장과 2장에 있습니다.

액티전스 사용설명서는 이 구조를 사람의 팀 업무에 비유합니다.

• 오케스트레이터: 전체 흐름을 조율하고 결과를 통합하고 품질을 점검하는 본 세션
• 서브에이전트 A: 자료 수집
• 서브에이전트 B: 분석과 요약
• 서브에이전트 C: 초안 작성

각 서브에이전트는 이전 단계의 잡음 없이 깨끗한 컨텍스트로 시작합니다. 이를 새 눈(Fresh Eyes)이라고 부릅니다. 같은 사람이 쓰고 같은 사람이 검토하면 실수를 놓치기 쉽습니다. 검토를 따로 맡긴 서브에이전트는 작성 과정의 맥락 없이 결과만 보기 때문에 다른 시각으로 점검합니다.

팀 방식으로 얻는 것은 네 가지입니다.

• 집중: 각자 필요한 맥락만 갖고 깊이 처리합니다.
• 속도: 의존하지 않는 일을 동시에 진행합니다.
• 재개: 단계별 상태를 문서로 남기면 중간에 끊겨도 이어갈 수 있습니다.
• 품질: 마지막에 통합하고 점검하는 단계가 있어 한 명이 다 한 결과보다 안정적입니다.

주의할 점도 있습니다. 서브에이전트는 따로 쓰는 만큼 사용량이 더 듭니다. 서브에이전트의 요청도 본 대화와 같은 사용 한도에 포함된다고 공식 문서에 안내되어 있습니다. 작은 일에 쓰면 오히려 손해입니다.

서브에이전트를 만드는 방법

서브에이전트는 이름과 설명이 적힌 마크다운 파일로 정의합니다. 프로젝트 폴더의 .claude/agents/에 두면 그 프로젝트에서, 사용자 폴더의 ~/.claude/agents/에 두면 모든 프로젝트에서 쓸 수 있습니다. Claude에게 "검토 전담 서브에이전트를 만들어 줘"라고 요청하면 파일을 대신 써 줍니다. 읽기만 하는 역할에는 파일을 수정할 수 없도록 도구를 제한하는 것이 안전합니다. 세부 설정은 공식 문서를 확인합니다.

역할 분담 예시(가상의 예)입니다.

인계 문서: 세션을 건너 일을 넘기는 법

새 세션은 이전 대화를 기억하지 못합니다. 그래서 세션을 바꾸거나 다른 사람에게 일을 넘길 때는 인계 문서를 만듭니다. 대화를 통째로 붙이는 것보다 짧고 정확합니다.

액티전스 스킬 중 Session-Handoff는 이 문서를 만들어 줍니다. 부록 B에 정리되어 있습니다. 좋은 인계 문서에는 다음이 들어갑니다.

• 변경한 것(CHANGE): 이번 세션에서 바꾼 것과 확정된 결과물
• 유지할 것(KEEP): 앞으로도 바꾸지 않을 것
• 하지 않을 것(OUT_OF_SCOPE): 이번 범위에서 일부러 뺀 것
• 결정과 근거: 무엇을 선택했고 왜 그랬는지, 폐기한 방안과 폐기 이유
• 다음 세션이 처음에 할 일: 읽을 파일과 첫 지시문

시행착오의 과정은 적지 않습니다. 인계 문서에 필요한 것은 확정된 결과와 결정의 이유이지 헤맨 기록이 아닙니다.

컨텍스트 관리: 요약하고, 비우고, 새로 시작한다

컨텍스트가 길어졌을 때의 수단은 세 가지입니다.

• 요약(compact): 대화를 요약해 컨텍스트를 줄입니다. 무엇을 남길지 지정하면 좋습니다. 공식 문서는 "API 변경과 테스트 명령을 남겨라"처럼 초점을 주는 방식을 예로 듭니다. 긴 대화는 자동으로 요약되기도 합니다.
• 비우기(clear): 관련 없는 새 일로 넘어갈 때 대화를 비웁니다. 비용도 아끼고 앞 일의 영향도 없앱니다.
• 새 세션: 일의 성격이 바뀌었다면 인계 문서를 쓰고 새 세션에서 시작합니다.

일의 한 단위가 끝났다면 비우고 시작하는 편이 대체로 낫습니다. 같은 실수를 두 번 고쳤는데도 반복된다면 대화를 비우고 배운 것을 담은 새 지시문으로 다시 시작합니다.

대규모 검토 맡기기 (동적 워크플로)

서브에이전트를 일일이 지시하지 않고, Claude가 작업에 맞는 스크립트를 써서 많은 서브에이전트를 한꺼번에 지휘하게 하는 방식이 있습니다. 공식 문서는 이를 동적 워크플로(dynamic workflows)라고 부릅니다. 이 책에서는 대규모 검토 모드라고 줄여 부릅니다. 일을 맡길 때 "워크플로로 해 줘"라고 말하는 식으로 요청하며, 이름과 호출 방법, 제공 범위는 자주 바뀌므로 공식 문서에서 확인합니다(2026년 11월 기준).

보통 모드와 비교하면 다음과 같습니다.

중간 결과를 대화창이 아닌 스크립트가 들고 있다는 점이 규모를 키우는 원리입니다. 공식 문서는 이 방식이 한 대화로 감당하기 어려운 분량에 맞고, 서로의 결과를 교차 검증하게 만들 수도 있다고 설명합니다. 다만 교차 검증으로 누락과 오류가 얼마나 줄지는 일마다 다르니 단정하지 않습니다.

켜는 때와 끄는 때를 나눠 둡니다.

• 켜는 때: 규정이나 계약의 전수 대조, 제출물 일괄 검토, 틀리면 곤란한 자료
• 끄는 때: 문장 다듬기, 짧은 질문. 사용량만 크고 얻는 것이 없습니다.

처음에는 자료 일부로 작게 시험해 사용량을 가늠한 뒤 범위를 넓힙니다. 공식 문서는 한 번의 실행이 같은 일을 대화로 처리할 때보다 훨씬 많은 사용량을 쓸 수 있다고 안내합니다.

프롬프트 예(가상의 예)입니다.

워크플로로 해 줘. 이 규정 문서 3개를 비교해서 서로 충돌하는 조항을 전부 찾아줘.
찾은 조항마다 다른 에이전트가 원문과 다시 대조해서 검증해줘.

핵심 이 모드가 줄이는 것은 검증에 드는 시간이지 검증의 책임이 아닙니다. 충돌 조항으로 지목된 것은 사람이 원문과 대조해 확인합니다.

사용량과의 관계

여러 세션과 서브에이전트는 같은 계정의 사용량을 함께 씁니다. 병렬로 돌릴수록, 대규모 검토 모드를 켤수록 한도에 빨리 다가갑니다. 한도 숫자는 요금제마다 다르고 바뀌므로 요금제 페이지에서 확인합니다. 2장에서 요금제를 고르는 기준을 다뤘습니다. 실무에서는 다음 방식이 효율적입니다.

• 단순하고 짧은 일은 한 세션에서 끝냅니다.
• 병렬은 조사처럼 맥락이 길고 서로 독립적인 일에만 씁니다.
• 세션을 오래 열어 두지 말고 일이 끝나면 닫습니다.

실습

조사 세션과 작성 세션을 나누고 인계하기

업무 주제 하나(예: 신규 서비스 소개 자료)를 고릅니다. 세션 두 개를 따로 열어 진행합니다. 폴더는 조사/와 초안/으로 나눕니다.

조사 세션에 입력합니다.

주제: [주제]. 이 세션의 역할은 조사 하나야. 조사/ 폴더에만 파일을 만들고 다른 폴더는 건드리지 마.
핵심 질문 5개를 먼저 제안해 줘. 내가 확정하면 각 질문에 답이 되는 자료를 찾아 출처와 함께 정리해 줘.
확인하지 못한 것은 "미확인"으로 표시해. 끝나면 조사/인계.md를 만들어 줘. 포함할 것: 확정된 사실, 미확인 항목, 결정과 근거, 작성 세션이 가장 먼저 읽을 파일.

작성 세션에 입력합니다.

이 세션의 역할은 초안 작성 하나야. 조사/인계.md를 읽고, 거기 적힌 확정된 사실만 써서 초안/초안1.md를 만들어 줘.
"미확인" 항목은 본문에 사실처럼 쓰지 말고 문서 끝에 확인 필요 목록으로 따로 모아 줘.
조사/ 폴더는 읽기만 하고 수정하지 마.

끝난 뒤 인계 문서만으로 작성 세션이 일을 이어갔는지, 빠진 정보는 없었는지 점검하고, 빠진 항목을 다음 인계 문서의 항목으로 추가합니다.

선택 과제

• 자료 3~5개를 서브에이전트로 나눠 동시에 요약시킵니다. 같은 자료를 한 대화창에서 차례로 시킨 결과와 속도, 누락을 비교합니다.
• 가상의 규정 문서 3개를 만들어 충돌 조항 전수 대조를 보통 모드와 대규모 검토 모드로 각각 돌립니다. 결과와 사용량을 비교하고, 최종 확인은 사람이 원문과 대조해서 합니다.
• 세션을 두 개 이상 동시에 띄워 서로 다른 일을 맡겨 봅니다. 세션 이름과 맡긴 일이 한눈에 구분되는지 확인합니다.

정리

• 일을 나누는 이유는 컨텍스트 오염을 막고 독립된 일을 병렬로 처리하기 위해서입니다.
• 한 세션에는 한 가지 일만 맡기고, 두 세션이 같은 파일을 동시에 고치지 않게 소유를 나눕니다.
• 서브에이전트는 자기 컨텍스트에서 일하고 요약만 돌려주는 전문가이며, 읽기 전용 검토 역할에 특히 적합합니다.
• 서브에이전트는 낮은 등급 모델로 배정될 수 있으니 중요한 일에는 중간 이상 등급을 지정하고, 규모가 큰 전수 검토에는 대규모 검토 모드를 쓰되 확인은 사람이 합니다.
• 세션을 넘길 때는 확정된 결과, 결정과 근거, 다음 할 일만 담은 인계 문서를 씁니다.
• 병렬과 서브에이전트는 사용량을 더 쓰므로 맥락이 길고 독립적인 일에만 씁니다.