서브에이전트를 효과적으로 활용하기

You know how to create sub agents and design them well. 서브 에이전트를 만들고 잘 설계하는 방법을 이미 알고 있어요. Now, let's cover when they actually help and when they get in the way. 이제 실제로 도움이 될 때와 방해가 될 때를 살펴보겠습니다. Simply put, the difference comes down to whether the intermediate work matters to your main thread. 간단히 말해, 차이는 중간 작업이 메인 스레드에 중요한지에 달려 있어요. When exploration is separate from execution, sub agents shine. 탐색과 실행이 분리되어 있을 때, 서브 에이전트는 빛을 발합니다. When each step depends on what the previous step discovered, well, information gets lost in the handoff process. 각 단계가 이전 단계의 발견에 의존할 때, 정보는 인계 과정에서 손실됩니다. Sub agents excel at research tasks where you just need an answer, not the journey. 서브 에이전트는 답만 필요하고 과정은 필요 없는 리서치 작업에 탁월해요. Consider investigating how authentication works in an unfamiliar code base. 낯선 코드베이스에서 인증이 어떻게 작동하는지 조사하는 경우를 생각해 보세요. Well, the main thread might need to know where is the JWT validated, but doesn't need to see every file that was searched. 메인 스레드는 JWT가 어디서 검증되는지만 알면 되고, 검색된 모든 파일을 볼 필요는 없어요. A research sub agent can read dozens of files, trace through function calls, and explore different code paths. 리서치 서브 에이전트는 수십 개의 파일을 읽고, 함수 호출을 추적하고, 다양한 코드 경로를 탐색할 수 있어요. All that exploration stays in the sub agent's context. 그 모든 탐색은 서브 에이전트의 컨텍스트 안에 머물어요. Your main thread receives JWT validation happens in middleware/auth.js at line 42, called from the Express router and route/api.js, or something like that. 메인 스레드가 받는 내용은 이렇습니다: JWT 검증은 middleware/auth.js의 42번 줄에서 일어나며, Express router와 route/api.js에서 호출됩니다, 뭐 이런 식이죠. Claude reviews work more effectively when the code is presented as being authored by someone else. 코드가 다른 사람이 작성한 것으로 제시될 때 Claude는 더 효과적으로 리뷰해요. If you build a feature over many turns with your main thread, asking the main thread to then review it often doesn't give the best feedback. 메인 스레드와 여러 번의 대화로 기능을 만들면, 메인 스레드에 리뷰를 요청해도 최선의 피드백이 나오지 않는 경우가 많아요. Claude was involved in creating it, so it has trouble seeing it with fresh eyes. Claude가 만드는 데 관여했기 때문에 새로운 시각으로 보기가 어렵습니다. A reviewer sub agent sees the changes in a separate context. 리뷰어 서브 에이전트는 변경 사항을 별도의 컨텍스트에서 봅니다. It runs get diff, reads the modified files, and applies its specialized review criteria without the history of how the code was written. git diff를 실행하고, 수정된 파일을 읽고, 코드가 작성된 이력 없이 전문화된 리뷰 기준을 적용해요. And this separation also lets you encode project-specific review standards in the sub agent system prompt, ensuring consistent review criteria across the team. 이 분리 덕분에 서브 에이전트의 system prompt에 프로젝트별 리뷰 기준을 넣을 수 있고, 팀 전체에서 일관된 리뷰 기준을 보장할 수 있어요. Claude Code's default system prompt emphasizes concise, code-focused response. Claude Code의 기본 system prompt는 간결하고 코드 중심의 응답을 강조해요. And this works great for coding, but not for everything. 코딩에는 딱 맞지만, 모든 것에 맞지는 않아요. So, one is a copywriting sub-agent with instructions about tone, audience, and style. 그래서, 톤·대상 독자·스타일에 대한 지침이 있는 카피라이팅 서브 에이전트가 필요합니다. This will produce better marketing text than the main thread would. 이렇게 하면 메인 스레드보다 더 나은 마케팅 텍스트를 만들 수 있어요. Claude Code's default prompt tends towards concise, technical writing, which really isn't what you want for a landing page or email campaign, unless you want to put your customers to sleep. Claude Code의 기본 프롬프트는 간결하고 기술적인 글쓰기 방향으로 치우쳐 있어요. 랜딩 페이지나 이메일 캠페인에는 맞지 않습니다. 고객을 잠들게 만들고 싶지 않다면요. A copywriting sub-agent can have completely different instructions about voice and structure. 카피라이팅 서브 에이전트는 보이스와 구조에 대해 완전히 다른 지침을 가질 수 있어요. A styling sub-agent that at mentions your design system files will apply consistent CSS patterns. 디자인 시스템 파일을 언급하는 스타일링 서브 에이전트는 일관된 CSS 패턴을 적용해요. When the sub-agent runs, those files load into the context automatically, so it knows your color variables, spacing conventions, and component patterns before it even starts writing any CSS. 서브 에이전트가 실행될 때, 그 파일들이 컨텍스트에 자동으로 로드되어, CSS 작성을 시작하기 전에 색상 변수·간격 규칙·컴포넌트 패턴을 이미 알고 있어요. Sub-agents that claim expertise rarely help. 전문성을 주장하는 서브 에이전트는 거의 도움이 되지 않아요. Prompts like, "You are a Python expert." or "You are a Kubernetes specialist." add no value because Claude already has that knowledge. "당신은 Python 전문가입니다" 또는 "당신은 Kubernetes 전문가입니다" 같은 프롬프트는 가치를 더하지 않아요. Claude가 이미 그 지식을 갖고 있으니까요. The overhead of launching a sub-agent, losing visibility into its work, and compressing its findings into a summary only makes sense when the sub-agent does something that the main thread can't. 서브 에이전트를 실행하고, 작업 가시성을 잃고, 결과를 요약으로 압축하는 오버헤드는 서브 에이전트가 메인 스레드가 할 수 없는 것을 할 때만 의미 있어요. Like applying a custom system prompt or keeping exploratory work isolated. 커스텀 system prompt를 적용하거나 탐색 작업을 격리된 상태로 유지하는 것처럼요. Sequential sub-agent pipelines create problems. 순차적 서브 에이전트 파이프라인은 문제를 일으켜요. Consider a three-agent flow. 세 에이전트 흐름을 생각해 봐요. One to reproduce a bug, one to debug it, and one to fix it. 하나는 버그를 재현하고, 하나는 디버그하고, 하나는 수정합니다. Pipelines work when tasks are truly independent. 파이프라인은 작업이 진정으로 독립적일 때 작동해요. They fail when each step depends on discoveries from the previous step. 각 단계가 이전 단계의 발견에 의존하면 실패합니다. Test runner sub-agents tend to hide information you need. 테스트 러너 서브 에이전트는 필요한 정보를 숨기는 경향이 있어요. When tests fail, you want the full output to diagnose issues. 테스트가 실패하면, 문제를 진단하기 위해 전체 출력이 필요해요. A sub-agent that returns a test failed forces you to create additional debug scripts to get details that would have been visible in direct output. "테스트 실패"만 반환하는 서브 에이전트는 직접 출력에서 보였을 세부 정보를 얻기 위해 추가 디버그 스크립트를 만들게 해요. Testing has showed that the test runner pattern performed worse among all configurations. 테스트 결과, 테스트 러너 패턴이 모든 구성 중 가장 낮은 성능을 보였어요. Across the series, we covered how sub-agents work as isolated threads that return summaries. 이 시리즈에서 서브 에이전트가 요약을 반환하는 격리된 스레드로 어떻게 작동하는지 다뤘어요. How to create them with the /agents command, and how to design them with structured outputs and specific descriptions. /agents command로 만드는 방법, 구조화된 출력과 구체적인 설명으로 설계하는 방법도요. Use them for research, reviews, and tasks needing custom system prompts. 리서치·리뷰·커스텀 system prompt가 필요한 작업에 활용하세요. But, avoid them for expert claims, multi-step pipelines, and test runners. 하지만 전문성 주장·다단계 파이프라인·테스트 러너에는 피하세요. The key question, does the intermediate work matter? 핵심 질문: 중간 작업이 중요한가요? If not, then delegate it. 중요하지 않다면, 위임하세요.