효과적인 서브에이전트 설계하기
이제 서브에이전트를 만드는 방법을 알았으니, 실제로 효과를 발휘하게 만드는 패턴을 살펴보겠습니다. 제대로 구성되지 않은 서브에이전트는 방향을 잃거나, 너무 오래 실행되거나, 메인 에이전트가 사용할 수 없는 결과물을 만들어냅니다. 이를 해결하는 방법은 네 가지로 요약됩니다: 좋은 설명 작성하기, 출력 형식 정의하기, 장애물 보고하기, 도구 접근 제한하기입니다.
서브에이전트 설정 데이터가 사용되는 방식
메인 컨텍스트 창 에이전트에게 메시지를 보내면, 사용 가능한 모든 서브에이전트의 이름과 설명이 시스템 프롬프트에 포함됩니다. 이것이 메인 에이전트가 어떤 서브에이전트를 언제 실행할지 결정하는 방식입니다. 서브에이전트가 자동으로 트리거되는 시점을 더 잘 제어하고 싶다면, 조정해야 할 것이 바로 이름과 설명입니다.
설명은 두 번째 역할도 수행합니다. 메인 에이전트가 서브에이전트를 실행할 때, 작업을 시작하기 위한 입력 프롬프트를 작성합니다. 이때 설명을 해당 프롬프트 작성의 지침으로 사용합니다. 따라서 설명은 서브에이전트가 언제 실행되는지만 제어하는 것이 아니라 -- 서브에이전트가 무엇을 하도록 지시받는지도 결정합니다.
입력 프롬프트를 형성하는 설명 작성하기
코드 리뷰 서브에이전트를 예로 들어보겠습니다. 일반적인 설명을 사용하면, 메인 에이전트는 "git diff를 사용해 현재 변경 사항을 찾으세요"와 같은 입력 프롬프트를 작성할 수 있습니다. 이는 모호합니다. 서브에이전트는 어떤 파일이 중요한지 스스로 파악해야 합니다.
설명을 "검토하길 원하는 파일을 에이전트에게 정확히 알려줘야 합니다"와 같은 내용으로 업데이트하면, 메인 에이전트는 이제 검토할 실제 파일을 나열하는 훨씬 더 구체적인 입력 프롬프트를 작성하게 됩니다.
이 동일한 기법은 다양한 유형의 서브에이전트에서도 효과가 있습니다. 예를 들어, 웹 검색 서브에이전트의 설명에 "인용 가능한 출처를 반환하세요"를 추가하면, 메인 에이전트가 작업을 위임할 때 해당 지침을 포함하게 됩니다.
출력 형식 정의하기
서브에이전트에 적용할 수 있는 가장 중요한 개선 사항은 시스템 프롬프트에서 출력 형식을 정의하는 것입니다. 이는 두 가지 효과를 가져옵니다:
- 자연스러운 중단 지점을 만듭니다 -- 서브에이전트는 형식의 각 섹션을 채우면 작업이 끝났다는 것을 알게 됩니다.
- 서브에이전트가 너무 오래 실행되는 것을 방지합니다. 출력이 정의되어 있지 않으면, 서브에이전트는 충분한 리서치가 이루어졌는지 판단하기 어려워하며 필요 이상으로 훨씬 오래 실행되는 경향이 있습니다.
다음은 코드 리뷰 서브에이전트를 위한 구조화된 출력 형식의 예시입니다:
검토 내용을 구조화된 형식으로 제공하세요:
- 요약: 검토한 내용과 전반적인 평가에 대한 간략한 개요
- 심각한 문제: 즉시 수정해야 하는 보안 취약점, 데이터 무결성 위험, 또는 로직 오류
- 주요 문제: 품질 문제, 아키텍처 불일치, 또는 중대한 성능 우려 사항
- 사소한 문제: 스타일 불일치, 문서화 누락, 또는 사소한 최적화 사항
- 권장 사항: 개선 제안, 리팩터링 기회, 또는 적용할 모범 사례
- 승인 상태: 코드가 병합/배포할 준비가 되었는지 또는 변경이 필요한지에 대한 명확한 진술
이 형식은 서브에이전트에게 진행할 명확한 체크리스트를 제공합니다. 모든 섹션이 채워지면, 서브에이전트는 멈춰도 된다는 것을 알게 됩니다.
장애물 보고하기
서브에이전트가 작업 중에 우회 방법을 발견했을 때 -- 예를 들어 의존성 문제를 해결하거나 특정 명령어에 특정 플래그가 필요하다는 것을 알게 되었을 때 -- 이러한 세부 사항은 반환하는 요약에 나타나야 합니다. 그렇지 않으면, 메인 스레드가 동일한 해결책을 스스로 다시 찾아내야 하며, 이는 시간과 토큰을 낭비하게 됩니다.
드러내고 싶은 종류의 정보에는 다음이 포함됩니다:
- 설정 문제 또는 환경 특이사항
- 작업 중 발견한 우회 방법
- 특별한 플래그나 설정이 필요했던 명령어
- 문제를 일으킨 의존성 또는 임포트
이 정보를 얻는 방법은 출력 형식에서 명시적으로 요청하는 것입니다. 출력 템플릿에 "발생한 장애물" 섹션을 추가하면 이 정보를 안정적으로 드러낼 수 있습니다.
- 발생한 장애물: 검토 과정에서 발생한 장애물을 보고하세요. 여기에는 설정 문제, 발견한 우회 방법, 또는 환경 특이사항이 포함될 수 있습니다. 특별한 플래그나 설정이 필요했던 명령어를 보고하세요. 문제를 일으킨 의존성이나 임포트를 보고하세요.
도구 접근 제한하기
모든 서브에이전트가 모든 도구에 접근할 필요는 없습니다. 서브에이전트가 실제로 해야 할 일이 무엇인지 생각하고, 그 작업에 필요한 도구만 제공하세요. 이는 두 가지 효과를 가져옵니다: 의도하지 않은 부작용을 방지하고, 여러 서브에이전트를 사용할 때 각 서브에이전트의 역할을 더 명확하게 만듭니다.
일반적인 서브에이전트 유형에 대한 도구 접근을 생각하는 방법은 다음과 같습니다:
- 리서치 / 읽기 전용 서브에이전트 --
Glob,Grep,Read만 필요합니다. 실수로 파일을 수정할 수 없습니다. - 코드 리뷰어 --
git diff를 실행하고 변경 사항을 확인하기 위해Bash접근이 필요하지만, 여전히Edit이나Write는 필요하지 않습니다. - 스타일링 / 코드 수정 에이전트 -- 이 경우에는
Edit과Write접근 권한을 부여합니다. 서브에이전트의 역할이 실제로 코드를 변경하는 것이기 때문입니다.
종합하기
효과적인 서브에이전트는 네 가지 특징을 공유합니다:
- 구체적인 설명 -- 설명은 서브에이전트가 언제 실행되는지와 어떤 지침을 받는지를 제어합니다. 이 두 가지를 모두 조정할 수 있도록 작성하세요.
- 구조화된 출력 -- 시스템 프롬프트에 출력 형식을 정의하여 서브에이전트가 작업이 끝났음을 알고 메인 스레드가 사용할 수 있는 정보를 반환하도록 하세요.
- 장애물 보고 -- 출력 형식에 우회 방법, 특이사항, 문제점을 위한 섹션을 포함하여 메인 스레드가 이를 다시 찾아낼 필요가 없도록 하세요.
- 제한된 도구 접근 -- 서브에이전트에게 실제로 필요한 도구만 제공하세요. 리서치에는 읽기 전용, 리뷰어에는 bash, 코드를 변경해야 하는 에이전트에만 edit/write를 제공하세요.
이러한 패턴 각각은 그 자체로는 단순하지만, 함께 적용하면 막연하게 도움을 주려는 서브에이전트를 제시간에 작업을 마치고 명확하게 보고하는 집중력 있고 예측 가능한 작업자로 바꿔줍니다.