Agent는 프롬프트가 아니라 구조로 좋아진다
Anthropic Code w/ Claude 2026 Agent Decomposition 세션을 보고 정리한 글입니다.
Agent 개선은 긴 프롬프트가 아니라 Eval → Skill → Tool → Subagent 구조 재설계로 합니다.
원본 링크
- X 영상: 淘沙者(TheSandPicker) 공유 영상
- 공식 세션 페이지: Tool, skill, or subagent? Decomposing an agent that outgrew its prompt
- 워크숍 코드: anthropics/cwc-workshops — agent-decomposition
공개 검색 기준으로 YouTube 원본 URL은 확인하지 못했습니다. 현재 확인 가능한 공개 영상은 X에 업로드된 44분 38초 녹화본이고, 공식 원문은 Claude 세션 페이지와 GitHub 워크숍 저장소입니다. YouTube 공개본이 확인되면 링크를 교체하겠습니다.
한 줄 요약
Agent가 복잡해져 성능이 떨어질 때, 더 좋은 모델이나 더 긴 system prompt를 찾기 전에 다음 순서로 봐야 합니다.
Eval 실행 → 실패 원인 분류 → Prompt 축소 → Skill 분리 → Tool 정리 → Subagent 재판단 → Eval 재실행
예제: StockPilot
영상의 예제는 야외용품 리테일러를 위한 재고관리 Agent StockPilot입니다.
- 재고 부족 감지
- 수요 예측
- 공급업체 선택
- 발주서 작성
- 주간 리포트 작성
| 항목 | Before | After |
|---|---|---|
| System prompt | 402 lines | 15 lines |
| Tools | 12개 | 핵심 primitive 중심 |
| Hardcoded subagents | 3개 | 0개, runtime decision |
| Eval score | 약 71% | 약 92% |
| F1 daily sweep | 488초, 102 tool calls | 약 100초, 3 scripts |
핵심은 지식을 버리는 것이 아닙니다. 항상 context에 넣던 지식을 필요한 순간에만 로드하도록 바꾸는 것입니다.
1. Eval 없이 Agent를 고치지 않는다
Agent 개선은 감으로 하지 않습니다. Eval 점수로 hill climbing 합니다.
Eval은 정답 여부만 보지 않습니다.
- pass/fail
- latency
- turn count
- tool call 수
- token usage
- 비용
- output format
- LLM-as-judge 품질 평가
즉 Agent 품질은 정확도 + 비용 + 속도 + 운영 안정성을 같이 봐야 합니다.
2. System prompt는 짧아야 한다
나쁜 패턴은 새 요구사항, 예외, 보고서 형식, 정책이 생길 때마다 system prompt에 계속 추가하는 것입니다.
system prompt에는 다음만 남깁니다.
- Agent의 역할
- 전역 안전 규칙
- 작업 원칙
- tool / skill / subagent를 선택하는 상위 기준
나머지는 skill로 뺍니다.
- 도메인 정책
- 계산 절차
- 보고서 템플릿
- 예외 처리 규칙
- 특정 업무에서만 필요한 지식
이 방식이 progressive disclosure입니다. 필요한 정보만 그때그때 context에 공개합니다.
3. Tool은 custom tool보다 primitive부터
Agent에게 처음부터 업무별 custom tool을 많이 붙이지 말고, 인간이 컴퓨터에서 쓰는 기본 능력을 먼저 줍니다.
- 파일 읽기
- 파일 쓰기
- bash
- code execution
- web search
- todo list
- filesystem navigation
CSV 분석을 예로 들면, CSV 전체를 context에 반환하지 말고 Agent가 Python script를 작성해 필요한 결과만 가져오게 합니다.
데이터를 모델 머리에 다 넣지 말고, 모델에게 컴퓨터를 쓰게 하라.
4. Subagent는 두 경우에만 쓴다
Subagent는 유용하지만 비쌉니다. 다음 둘 중 하나일 때만 씁니다.
- 병렬로 많은 Claude를 던지고 싶을 때: deep research, web search, codebase exploration, 여러 후보안 탐색
- fresh mind가 필요할 때: 코드 리뷰, 독립 검증, forecasting
반대로 subagent의 output이 단순 숫자 하나라면 보통 subagent가 아니라 tool이나 code execution이 맞습니다.
판단표
| 상황 | 선택 | 이유 |
|---|---|---|
| 항상 필요한 역할/원칙 | System prompt | 모든 작업에 적용 |
| 특정 작업에서만 필요한 절차 | Skill | 필요할 때만 context 로드 |
| 파일/CSV/계산/탐색 | Code execution / bash | token 절약, 정확도 상승 |
| 명확한 외부 API 호출 | Custom tool | I/O와 권한이 명확할 때 |
| 여러 Agent가 공유하는 표준 도구 | MCP | 재사용과 거버넌스 |
| 병렬 탐색 또는 독립 검증 | Subagent | 별도 context가 가치 있을 때 |
| 단순 기능 추가 | Subagent 금지 | 복잡도만 증가 |
실제 적용 절차
- 현재 Agent 구조를 inventory 한다.
- 최소 eval 10개를 만든다.
- 실패 원인을 prompt, skill, tool, subagent, data, eval 문제로 분류한다.
- system prompt를 10~30줄 수준으로 줄인다.
- 업무 절차는 skill로 이동한다.
- custom tool을 primitive tool로 대체할 수 있는지 본다.
- subagent는 병렬성 또는 fresh context가 없으면 제거한다.
- 수정 후 eval을 다시 돌린다.
바로 쓰는 체크리스트
- system prompt 길이를 잰다
- 항상 필요한 정보와 가끔 필요한 정보를 나눈다
- 가끔 필요한 정보는 skill로 뺀다
- custom tool을 primitive tool로 대체할 수 있는지 본다
- subagent는 병렬성/fresh mind가 없으면 제거한다
- 최소 10개 eval을 만든다
- token, latency, tool call 수를 같이 본다
- 수정할 때마다 eval을 다시 돌린다
- 좋아진 것만 merge한다
마무리
이 세션의 핵심은 “AI assistant를 많이 만들라”가 아닙니다.
Agent는 프롬프트로 커지는 것이 아니라, 구조로 성장해야 한다.
System prompt는 짧게. 업무 지식은 Skill로. 데이터 처리는 Code execution으로. Subagent는 꼭 필요할 때만. 개선은 Eval로 증명.