Anthropic의 Applied AI 엔지니어인 Will이 런던에서 개최된 Code with Claude London 행사에서 발표한 “Tool, skill, or subagent? Decomposing an agent that outgrew its prompt” 워크숍 내용의 상세 정리 및 해석 노트입니다.
이 발표는 에이전트의 요구사항이 늘어남에 따라 시스템 프롬프트와 도구 목록이 기하급수적으로 비대해지고, 이로 인해 과거에 잘 수행하던 작업에서 오히려 성능 퇴행(Regression)이 일어나는 문제를 해결하기 위한 에이전트 아키텍처 분해(Decomposition) 방법론을 제안합니다.
클립 1: 프롬프트 비대화 문제와 성능 퇴행 (00:20 - 02:10)
This pattern continued and continued until before you know it, your system prompt had grown to become several hundred lines long. You have dozens of tools and sub-agents that exist for your agent. And because of the complexity, you’ve started to see regressions in the areas that your agent was previously accelerating in.
해석
에이전트가 최초 런칭 시점에는 매우 좁은 문제를 훌륭히 해결하지만, 비즈니스 요구사항이 점증함에 따라 지속적으로 예외 처리 지침과 세부 규칙들을 시스템 프롬프트에 추가 접합(bolt on)하게 됩니다. 이 과정에서 에이전트 루프의 시스템 프롬프트는 수백 줄이 되고 도구의 개수는 수십 개로 늘어나며, 결과적으로 컨텍스트 윈도우 내부의 정보 간에 모순이 발생하여 에이전트가 이전에 잘하던 영역에서 성능 퇴행이 발생하게 됩니다. 이 문제를 해결하기 위해 에이전트 개발자는 **도구(Tool), 스킬(Skill), 서브에이전트(Subagent)**라는 에이전트 프리미티브(Primitives)를 명확하게 분해하여 배치해야 합니다.
클립 2: Stock Pilot 아키텍처 분석 및 평가(Evals) 실패 사례 (03:30 - 05:40)
Folks, today the agent is facilitated by a single orchestrator. … The agent has a system prompt, as I mentioned, that’s grown to be about 400 lines long. It has 12 different tools. Three of those tools happen to be wrappers around sub agents…
해석
워크숍에서 예시로 든 재고 관리 에이전트인 Stock Pilot은 400줄에 가까운 시스템 프롬프트, 12개의 도구, 그리고 개별 컨텍스트를 가지는 3개의 서브에이전트를 호출하는 구조로 구성되어 있었습니다. 이 비대해진 구조는 세 가지 전형적인 평가(Evals) 실패를 유발합니다:
- F1 실패(저재고 탐색): 올바른 재고 조사는 수행하지만 매우 비효율적이고 구불구불한 흐름으로 도구를 중복 호출하여 평가 기준을 만족하지 못함.
- F2 실패(주문 프로세스): 오케스트레이터와 서브에이전트 간의 소통 부재(Communication Breakdown)로 인해 서브에이전트가 작업을 올바르게 끝냈음에도 오케스트레이터가 이를 제대로 전달받지 못해 실패함.
- R8 실패(프로모션 수요 예측): 시스템 프롬프트 곳곳에 흩어져 있는 두 개 이상의 서로 다른 정책이 상충하여 모델이 3.1배 대신 1.35배를 곱하는 등 수치 예측을 hallucinate 함.
클립 3: 언덕 오르기(Hill Climbing)와 Claude Managed Agents (10:30 - 12:55)
So, folks, our objective in this workshop will first be to run our suite of evals. We’re going to triage the issues and we’re going to update the design of our agent accordingly. And then, we’re going to do something that we call internally hill climbing towards eval improvement. … Claude managed agents essentially allows us to offload the messiness that comes with maintaining an agentic harness in scaling agents safely and securely…
해석
프롬프트가 비대해진 에이전트를 성공적으로 최적화하기 위해서는 **Evals(평가 모델)**을 기반으로 설계 변경을 수행한 뒤 재측정하여 성과를 점진적으로 개선하는 언덕 오르기(Hill Climbing) 방식을 취해야 합니다. 또한, 로컬에서 잘 도는 에이전트도 보안, 샌드박싱, 동시성 스케일링 등의 인프라 이슈를 마주하게 되는데, 이를 offload 하기 위해 Anthropic의 CMA (Claude Managed Agents) 서비스와 같은 관리형 환경을 도입함으로써 에이전트 내부 아키텍처 설계와 프리미티브 분해에만 집중할 수 있게 됩니다.
클립 4: 에이전트 프리미티브 (1) — 단계적 공개(Progressive Disclosure)를 위한 스킬(Skill) 도입 (21:00 - 23:30)
The first thing that we’ll talk about is skills. … skills are packaged and composable information that Claude has the ability to pull into context whenever Claude realizes that it needs that information to complete a particular task.
해석
**스킬(Skill)**은 에이전트가 항상 머릿속에 담고 있어야 하는 기본 지침(시스템 프롬프트)과 달리, 특정 조건이나 상황에서만 필요로 하는 비즈니스 로직과 절차서들의 패키지입니다. 모든 정보를 시스템 프롬프트에 쏟아붓지 않고 스킬 디렉토리에 나누어 둠으로써, 모델은 평상시에는 15줄 정도의 아주 얇은 시스템 프롬프트만 유지하다가, 사용자 요청에 따라 필요한 스킬만 골라서 컨텍스트에 단계적으로 로드(Progressive Disclosure)하게 됩니다. 이를 통해 컨텍스트 오염과 지침 간 충돌을 원천 차단하고 비용을 획기적으로 낮출 수 있습니다.
클립 5: 에이전트 프리미티브 (2) — 컴퓨터 인터페이스 도구와 토큰 최적화 (26:10 - 29:05)
Whenever we build agents, we lean into the same primitives that we as humans have access to. … giving Claude a bash tool so that Claude can write a quick Python script and reason across the results … is much more effective than just uploading the entire CSV into Claude’s context window.
해석
에이전트의 **도구(Tool)**를 설계할 때 흔히 저지르는 실수는 분석이나 처리를 위한 ad-hoc API나 전용 도구들을 수십 개씩 연결하는 것입니다. Anthropic은 인간이 일하는 방식처럼 **기본 컴퓨터 프리미티브(컴퓨터 조작, Bash 코드 실행, 웹 브라우징, 파일 탐색)**를 최소한으로 쥐여주고, 모델이 이 도구들을 이용해 스스로 로직을 해결하도록 하는 구조를 지향합니다. 예를 들어, 대용량 CSV 파일의 데이터를 오케스트레이터가 전부 읽어들여 컨텍스트를 오염시키는 대신, 코드 실행 도구(Bash)를 통해 파이썬 스크립트를 작성하여 데이터를 로컬에서 처리·필터링하고 그 결과값만 해석하게 하는 방식이 훨씬 토큰 효율적이고 저렴하며 강력합니다.
클립 6: 에이전트 프리미티브 (3) — 독립적인 맥락(Fresh Mind)을 위한 서브에이전트 배치 (35:45 - 38:30)
The two main use cases where … we see subagents initially as being really effective is first when you want to throw a lot of Claude at a problem… The second case … is when you need a fresh mind to look at a problem. … you do not want to be the same person that is writing and also reviewing your code.
해석
**서브에이전트(Subagent)**는 아예 격리된 컨텍스트 윈도우를 갖고 실행되는 독립된 에이전트입니다. 서브에이전트가 필요한 순간은 크게 두 가지입니다:
- 집중 투하(Heavy parallelization): 넓은 범위를 한 번에 탐색하거나 깊은 리서치가 필요해 여러 개의 클로드 인스턴스를 병렬로 돌려야 할 때.
- 독립된 맥락(Fresh Mind): 작업에 대한 편향을 제거해야 할 때. 코드를 작성한 주체(오케스트레이터)가 자신이 짠 코드를 직접 리뷰하게 하면 바이어스가 생기므로, 앞선 맥락이 전혀 없는 깨끗한 머리(Fresh Context)를 가진 독립 서브에이전트를 생성하여 코드 리뷰나 정합성 검증을 맡기는 설계가 이상적입니다.
클립 7: 최종 분해 아키텍처 및 핵심 테이크어웨이 (40:50 - 44:40)
When we build agents, we start with a single agent loop that it that is equipped with very simple primitives … progressive disclosure through skills … and this idea of hill climbing is a concept that we lean on really heavily at Anthropic.
해석
최종 아키텍처 개선 결과, Stock Pilot은 다음과 같이 단순하면서도 강력하게 진화했습니다:
- 오케스트레이터: 400줄에 달하던 대형 프롬프트가 단 15줄의 단순한 루프 제어 프롬프트로 변경되었습니다.
- 도구: 12개에 달하던 특정 기능 도구들을 컴퓨터 프리미티브(Bash, Read, Write) 3개로 대폭 줄여 토큰과 비용을 감축했습니다.
- 스킬: 재고 모니터링 정책, 프로모션 규칙 등 수많은 정책 지침들을 스킬로 분리하여 필요시 동적으로 로드하게 했습니다.
- 서브에이전트: 예측 모델에 선입견을 주는 것을 방지하기 위해
Forecaster를 별도 서브에이전트로 완전히 분리해 독립시켰습니다. 결과적으로 토큰 사용량과 API 비용이 획기적으로 낮아지면서, Evals 통과율은 62%에서 92%로 크게 개선되었습니다.
내 생각
Will이 제시한 Tool, Skill, Subagent의 분해 기준은 갈수록 거대화되는 단일 에이전트 시스템이 반드시 도달해야 하는 아키텍처 방향성을 정확하게 짚고 있습니다. 이는 본 블로그의 핵심 테마인 하네스 엔지니어링(Harness Engineering) 및 **컨텍스트 엔지니어링(Context Engineering)**과 직결됩니다.
에이전트가 점차 프롬프트 크기의 한계에 다다르고, 규칙들이 상충하면서 스스로의 한계에 봉착할 때, 우리는 이를 해결하기 위해 두 가지 원칙을 관철해야 합니다:
첫째, 경계가 획정된 컨텍스트(Bounded Context)의 수립입니다. 오케스트레이터의 두뇌에 모든 규칙과 정책을 상주시키는 것은 데이터베이스의 모든 레코드를 메모리에 적재하겠다는 것과 다름없습니다. 프롬프트는 제어 흐름(Control Flow)과 라우팅에만 집중하게 하고, 상세 비즈니스 지침들은 스킬로 모듈화하여 필요에 따라 **단계적으로 노출(Progressive Disclosure)**시키는 설계가 에이전트의 정신적 과부하를 막는 핵심 열쇠입니다.
둘째, 도구의 범용화(Generic Tools)입니다. 특정 함수나 REST API 하나하나를 개별 도구 스키마로 정의하여 전달하면 모델의 도구 호출 복잡성(Tool Selection Entropy)이 극도로 증가하여 에러가 빈번해집니다. 인간이 컴퓨터를 다룰 때 개별 하드웨어가 아닌 CLI/IDE/Browser라는 단 몇 개의 범용 인터페이스를 거치는 것처럼, 에이전트에게도 파이썬 실행기(Bash)나 범용 파일 리더 같은 컴퓨터 프리미티브를 주고 스스로 코드를 작성해 해결하게 만드는 설계가 에이전트의 능력을 극대화하며 동시에 토큰 비용을 최소화하는 지름길입니다.
에이전트가 “멍청해지고 있다”거나 “프롬프트가 길어져서 말을 안 듣는다”고 판단된다면, 그것은 모델의 한계가 아닙니다. 도구, 스킬, 서브에이전트의 역할 분담이 유기적으로 이루어지지 않아 발생한 아키텍처 엔트로피의 상승일 뿐입니다. 우리는 Evals라는 객관적인 나침반을 들고, 아키텍처를 잘게 쪼개어 가며 끊임없이 Hill Climbing을 시도해야 합니다.
댓글
GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.