에이전트 구축, 서브 에이전트를 메인 에이전트 루프에 통합해야 할 상황

Applied AI팀은 기업용 에이전트에서 라우터, 플래너, 도메인별 서브에이전트를 메인 루프에 통합해 성과를 낸 사례를 소개했다. 한 기업은 십여 개의 전문 서브에이전트 때문에 브랜드에 맞는 일관된 경험을 유지하기 어려웠고 레이턴시도 늘어났다. 다른 고객은 멀티 에이전트 구성을 단일 루프와 비교했더니 후자의 실행 시간이 약 2배 빨랐다고 보고했다. 한편 서브에이전트를 남겨도 되는 조건으로는 컨텍스트 비대화로 인한 성능 저하, 버릴 수 있는 새 컨텍스트에서의 병렬 작업, 도구 선택의 어려움이나 지시 충돌 등 세 가지를 제시했다.

대규모 조직에서 자주 나타나는 실패로는 에이전트 간 컨텍스트 전달 과정의 누락, 팀마다 서브에이전트가 난립하는 서브에이전트 범람, 각 팀이 시스템 프롬프트에 문장을 하나씩 덧붙여 모순이 생기는 Frankenprompt, 지나치게 국소적인 평가, 레이턴시 증가를 꼽았다. 대응책으로는 스킬을 통한 컨텍스트의 단계적 공개와 도구 검색을 통한 도구의 단계적 공개를 권장한다. 공유 컨텍스트가 요약 전달보다 더 풍부한 출력을 만들었고, Claude Code의 시스템 프롬프트도 80% 이상 줄였다고 한다. 모델 성능이 향상되면서 하네스 쪽 요소가 필요 없어지는 경우도 늘었다고 밝혔다.

전환은 단계적으로 진행한다. 먼저 중앙 팀이 관리하는 엔드투엔드 평가 세트와, 각 스킬을 담당하는 팀이 만드는 작은 평가 세트를 준비한다. 10건 안팎의 골든 예시만으로도 시작할 수 있다. 이후 결합이 강한 전문 에이전트를 통합할지, 서브에이전트를 도구로 호출할지, 프롬프트를 스킬로, API 호출을 MCP 도구로 바꿀지 정하고, 통합한 버전과 남겨 둔 버전의 평가를 비교한다. 지원 에이전트 검증에서는 통합으로 레이턴시는 줄었지만 기존에 잘 되던 처리 일부가 깨졌다. 이 문제는 두 번의 실행 중 한 번에서만 나타났기 때문에, 각 작업을 여러 번 실행해 보라고 권장한다.

여러 팀이 함께 일하는 방식으로는 각 팀의 담당을 에이전트에서 스킬과 도구로 옮기고, 작은 중앙 팀이 시스템 프롬프트와 전체 품질을 관리하는 형태를 제시한다. 도구는 API별이 아니라 사용자 의도별로 묶으며, 정의가 30~50개를 넘으면 선택 정확도가 떨어지기 쉽다고 본다. 도구 쪽에서 전제 조건과 권한을 확인하고, 거부도 모델이 읽을 수 있는 형태로 반환한다. 도구 묶음은 /skill-creator와 /skill-doctor로 정리할 수 있다. 전환을 돕는 도구로는 /claude-api build-eval, prompt-audit, hillclimb, cost-optimize 스킬을 연결한 마이그레이션 키트와 데모도 준비되어 있다.