서브에이전트를 만들고 잘 설계하는 방법은 알고 있습니다. 이제 핵심 질문은 이것입니다: 서브에이전트가 실제로 도움이 되는 때는 언제이고, 오히려 방해가 되는 때는 언제일까요? 그 차이는 단 하나로 귀결됩니다 -- 중간 작업 과정이 메인 스레드에 중요한가 여부입니다.

서브에이전트가 빛을 발하는 경우

서브에이전트는 탐색과 실행이 분리되어 있을 때 가장 효과적입니다. 작업의 각 단계가 이전 단계에서 발견한 내용에 의존한다면, 그 작업은 메인 스레드에서 처리하는 것이 좋습니다. 하지만 결과만 필요하고 과정은 중요하지 않다면, 서브에이전트에게 위임하세요.

서브에이전트가 특히 뛰어난 작업은 다음과 같습니다:

• 결과가 필요할 뿐, 찾아가는 과정을 단계별로 볼 필요가 없는 경우
• 탐색 작업이 메인 스레드의 컨텍스트를 복잡하게 만들 수 있는 경우
• 새로운 시각이나 커스텀 시스템 프롬프트가 작업에 도움이 되는 경우

리서치 작업

리서치는 서브에이전트의 대표적인 활용 사례입니다. 낯선 코드베이스에서 인증이 어떻게 동작하는지 조사하는 경우를 생각해보세요. 메인 스레드는 JWT가 어디서 검증되는지만 알면 됩니다. 탐색 과정에서 검색한 모든 파일을 볼 필요는 없습니다.

리서치 서브에이전트는 수십 개의 파일을 읽고, 함수 호출을 추적하고, 다양한 코드 경로를 탐색할 수 있습니다. 모든 탐색 과정은 서브에이전트의 컨텍스트 안에 머뭅니다. 메인 스레드는 다음과 같은 깔끔한 요약만 받습니다:

JWT validation happens in middleware/auth.js line 42,
called from the Express router in route/api.js

서브에이전트가 힘든 작업을 대신 처리했습니다. 메인 스레드는 다음 단계로 나아가는 데 필요한 정보만 정확히 받습니다.

코드 리뷰

Claude는 코드가 다른 사람이 작성한 것으로 제시될 때 더 효과적으로 리뷰합니다. 메인 스레드에서 여러 턴에 걸쳐 기능을 개발한 후 같은 스레드에 리뷰를 요청하면, 피드백이 약해지는 경우가 많습니다. Claude가 코드 작성에 관여했기 때문에 새로운 시각으로 바라보기 어렵습니다.

리뷰어 서브에이전트는 별도의 컨텍스트에서 변경 사항을 검토합니다. git diff 를 실행하고, 수정된 파일을 읽으며, 코드가 작성된 과정에 대한 기억 없이 전문화된 리뷰 기준을 적용합니다. 이러한 분리 덕분에 서브에이전트의 시스템 프롬프트에 프로젝트별 리뷰 기준을 담아, 팀 전체에서 일관된 리뷰 기준을 보장할 수 있습니다.

커스텀 시스템 프롬프트

Claude Code의 기본 시스템 프롬프트는 간결하고 코드 중심의 응답을 강조합니다. 코딩에는 훌륭하지만, 모든 작업에 적합한 것은 아닙니다.

커스텀 시스템 프롬프트를 사용하면 서브에이전트가 메인 스레드보다 확실히 더 나은 결과를 내는 두 가지 사례가 있습니다:

• 카피라이팅 서브에이전트 -- 톤, 대상 독자, 스타일에 대한 지침을 제공합니다. Claude Code의 기본 프롬프트는 간결한 기술 문서 작성 방향으로 치우치는데, 랜딩 페이지나 이메일 캠페인에는 맞지 않습니다. 카피라이팅 서브에이전트에는 문체와 구조에 대해 완전히 다른 지침을 부여할 수 있습니다.
• 스타일링 서브에이전트 -- 디자인 시스템 파일을 가리킵니다. 서브에이전트가 실행될 때 해당 파일들이 컨텍스트에 자동으로 로드되므로, CSS 작성을 시작하기도 전에 색상 변수, 간격 규칙, 컴포넌트 패턴을 이미 파악하고 있습니다.

서브에이전트가 해가 되는 경우

서브에이전트를 실행하는 오버헤드 -- 작업 과정의 가시성 손실과 결과를 요약으로 압축하는 것 -- 는 서브에이전트가 메인 스레드로는 할 수 없는 일을 할 때만 정당화됩니다. 주의해야 할 세 가지 흔한 안티패턴이 있습니다.

전문가 주장

전문성을 주장하는 서브에이전트는 거의 도움이 되지 않습니다. "당신은 Python 전문가입니다" 또는 "당신은 Kubernetes 전문가입니다"와 같은 프롬프트는 아무런 가치를 더하지 않습니다. Claude는 이미 그 지식을 갖고 있기 때문입니다. 소위 전문가 서브에이전트가 할 수 있는 일 중 메인 스레드가 직접 할 수 없는 것은 없습니다.

순차적 파이프라인

순차적 서브에이전트 파이프라인은 문제를 일으킵니다. 버그를 재현하는 에이전트, 디버깅하는 에이전트, 수정하는 에이전트로 구성된 3단계 흐름을 생각해보세요. 파이프라인은 작업이 진정으로 독립적일 때만 작동합니다. 각 단계가 이전 단계의 발견에 의존할 때는 실패하는데 -- 버그 수정은 거의 항상 그렇습니다. 에이전트 간 인계 과정에서 정보가 손실됩니다.

테스트 러너

테스트 러너 서브에이전트는 필요한 정보를 숨기는 경향이 있습니다. 테스트가 실패하면 문제를 진단하기 위해 전체 출력이 필요합니다. "테스트 실패"만 반환하는 서브에이전트는 직접 출력에서 바로 확인할 수 있었을 세부 정보를 얻기 위해 추가적인 디버그 스크립트를 만들도록 강제합니다. 테스트 결과에 따르면 테스트 러너 패턴은 모든 구성 중에서 가장 낮은 성능을 보였습니다.

판단 기준

서브에이전트 사용 여부를 결정할 때, 스스로에게 한 가지 질문을 하세요: 중간 작업 과정이 중요한가?

답이 아니오라면 -- 최종 결과만 필요하다면 -- 서브에이전트에게 위임하세요. 답이 예라면 -- 진행 과정을 보고 반응해야 한다면 -- 메인 스레드에서 처리하세요.

서브에이전트를 활용할 때:

• 리서치 및 탐색
• 코드 리뷰
• 커스텀 시스템 프롬프트가 필요한 작업

서브에이전트를 피해야 할 때:

• 실질적인 능력을 더하지 않는 "전문가" 페르소나
• 각 단계가 이전 단계에 의존하는 다단계 파이프라인
• 디버깅을 위해 전체 출력이 필요한 테스트 실행