Tool, skill, or subagent? Decomposing an agent that outgrew its prompt

출처 https://youtu.be/mWvtOHlZM-I · 채널 Claude (Anthropic) · 길이 00:45:06 포맷 “Code with Claude London” 컨퍼런스의 핸즈온 워크숍. Anthropic Applied AI팀 William Steuk가 슬라이드로 문제를 제시한 뒤, 청중과 함께 Claude Code(Opus 4.7, xhigh effort)를 사용해 시스템 프롬프트·툴·서브에이전트를 차례로 리팩터링하며 eval 점수를 62%에서 92%까지 끌어올리는 과정을 라이브로 진행한다. 원본 자막: raw/transcripts/2026-07-11-tool-skill-or-subagent.en.srt

한눈에 보는 요약

“처음엔 다 합리적이었던 선택들이 누적되면 발목을 잡는다.” 재고관리 에이전트 StockPilot은 요구사항이 늘어날 때마다 시스템 프롬프트에 정책을 덧붙이고, 새 기능마다 툴이나 서브에이전트를 추가한 결과 400줄 프롬프트·12개 툴(3개는 서브에이전트 래퍼)짜리 오케스트레이터가 됐고, eval 점수가 83%(설계 스펙)에서 실측 62%까지 떨어졌다.
12개 eval 태스크(R1-R9 회귀, F1-F3 실패모드) × 5종 그레이더로 정량 측정한다. 실패 원인을 코드로 추적한 대표 사례가 R8: 시스템 프롬프트 안에서 리오더 공식·프로모 정책·예측 해석이 서로 다른 섹션에 흩어져 있어, 에이전트가 3.1배 프로모 승수를 언급은 하면서도 실제 계산식에는 반영하지 못하고 베이스라인 평균에 anchoring되는(FAIL, -46%) 현상이 발생했다.
세 가지 원인 → 세 가지 처방. ① “모델이 툴이 해야 할 일을 대신 하고 있다”(compute-over-context 위반) → 필터링/정렬을 서버사이드 Python으로 이관, ② “출력 형식이 강제되지 않는다”(typed-contract 누락) → 스킬에 JSON 계약을 명시, ③ “정책·포맷을 매 호출마다 재추론한다”(policy-as-skill 누락) → 400줄 프롬프트를 15줄로 줄이고 정책은 5개 스킬로 이관(progressive disclosure).
12개 커스텀 툴을 Bash/Read/Write 3개로 통합했다. “context-dumper”(395행 CSV를 통째로 넘기던 툴)는 서버사이드 Python 한 줄로, “subagent-hider”(자유서술 텍스트를 반환해 파싱 실패를 유발하던 서브에이전트 래퍼)는 JSON 계약을 강제하는 스킬로, “trivial write”(3줄짜리 함수)는 그냥 bash 명령으로 대체됐다. F1 태스크 기준 토큰 216,365 → 7,628(~28배), 비용 $2 \to$ 0.07(~30배), 벽시계 시간 328s → 164s(~2배)로 개선됐다.
서브에이전트는 딱 하나만 남겼다 — forecasting. 예측 로직만 메인 컨텍스트와 분리해 별도 세션으로 두되, 기존처럼 “툴로 감싸 프리텍스트 응답을 파싱”하는 대신 Claude Managed Agents(CMA)의 네이티브 callable_agents 기능으로 전환해, 세션 추적·JSON 계약·병렬화 가능성을 확보했다.
최종 결과: 15줄 시스템 프롬프트 + 5개 스킬(온디맨드 로드) + 0개 하드코딩 서브에이전트 + callable_agents 1개 → eval 92%(11/12). 마지막 3대 교훈은 “단순하고 조합 가능한 프리미티브가 모델 지능과 함께 확장된다”, “조직 절차는 온디맨드로 로드하라(스킬)”, “evals는 제품 비전과 함께 진화해야 한다.”

장면별 상세 설명

[00:20] 1. 타이틀 슬라이드 — 발표자 소개

장면 1 — "Tool, skill, or subagent?" 타이틀 슬라이드와 발표자

발표자 William Steuk는 Anthropic 엔지니어링 팀 소속으로 “Applied AI”팀에 속해 있으며, 사내 엔지니어링 작업과 고객사와 함께 에이전트를 구축하는 일을 병행한다고 소개한다. 도입부는 청중에게 익숙한 시나리오를 던진다 — 문제를 잘 해결하는 에이전트를 배포했는데, 몇 주 뒤 요구사항이 추가되고 또 추가되기를 반복하다 보니 시스템 프롬프트가 수백 줄이 되고 툴과 서브에이전트가 수십 개로 늘어나며, 정작 이전에 잘 되던 부분에서 회귀(regression)가 나타나기 시작했다는 것. 이 세션은 그런 “비대해진 에이전트”를 시뮬레이션한 뒤 tool/skill/subagent 중 무엇을 언제 써야 하는지 결정하는 과정을 핸즈온으로 다룬다.

[02:50] 2. Meet Stock Pilot — 실습에 쓸 에이전트

장면 2 — "Meet Stock Pilot!" 소개 슬라이드

이번 워크숍 전체에서 다룰 에이전트는 StockPilot — 중견 아웃도어 장비 리테일러를 위한 재고관리 에이전트로, 250개 SKU·3개 창고·12개 공급사·90일치 판매 이력을 다룬다. 핵심 기능은 여섯 가지: 재주문 시점 아래로 떨어진 SKU를 감시·플래그(Monitor and flag), 프로모·계절성을 반영한 수요 예측(Forecast demand), 가격/리드타임/신뢰도를 비교해 공급사 선택(Choose suppliers), 발주서 생성·ERP 갱신(Place orders), Slack·이메일 알림(Notify ops), 주간 운영 리포트 작성(Report weekly). 개별 기능은 전혀 복잡하지 않지만, 문제는 이 기능들이 아키텍처 현대화 없이 시간이 지나며 계속 덧붙여졌다는 데 있다.

[03:35] 3. “Built right… for early 2025” — 처음 아키텍처의 실체

장면 3 — StockPilot 초기 아키텍처 다이어그램(오케스트레이터, 12개 툴, 3개 서브에이전트)

슬라이드 부제가 이 세션의 핵심 메시지를 요약한다 — “만들어질 당시엔 모든 선택이 defensible했다. 병목은 누적에서 생긴다.” StockPilot 오케스트레이터는 Messages API 위에 직접 구현한 while-loop(핸드롤드 하네스)이며, 당시 스펙 기준 ~400줄 프롬프트로 71% eval을 냈다. 그 아래 12개 인라인 툴이 있는데, get_stock_level/list_low_stock/create_purchase_order 같은 데이터 툴부터 forecast_demand/compare_supplier_quotes/generate_weekly_report까지 다양하고, 이 중 세 개(forecast_demand, compare_supplier_quotes, generate_weekly_report)는 실제로는 얇은 래퍼일 뿐 내부적으로 별도의 서브에이전트(forecasting/procurement/writing subagent)를 완전히 왕복 호출한 뒤 산문(prose) 결과를 반환한다. “12개 인라인 툴 — 모든 결과가 raw로 컨텍스트에 덤프된다”는 캡션이 뒤에 나올 문제의 원인을 미리 짚어준다.

[05:10] 4. 12개 eval 태스크 × 5종 그레이더

장면 4 — R1R9(회귀), F1F3(실패모드) eval 표

평가 체계는 두 부류다. R로 시작하는 회귀(regression) 태스크(R1R9)는 단순 조회부터 발주·리드타임·사이클카운트 같은 쓰기 경로, 재주문 추천·14일 예측 같은 수치 계산, 그리고 주간 리포트 구조까지 다룬다. 그레이더는 exact_match/set_match/action_taken/numeric_tolerance(±2025%)/llm_judge로 태스크 성격에 맞게 다르다. F로 시작하는 실패모드(failure mode) 태스크(F1F3)는 더 복잡한 멀티턴 시나리오로, 일일 저재고 스윕(F1, 효율성까지 함께 채점하는 복합 그레이더), 프로모 시 재주문 추천(F2, 수치 신뢰도 존재 여부를 정규식으로 체크), 10건 일괄 저재고 알림의 비용(F3, 출력 토큰 5,000 이하 여부)을 평가한다. 특히 R8(“Mean anchoring”)과 F1(“Stockout management”)·F2(“Recommendation quality”)·F3(“What do 10 routine alerts cost us?”)는 볼드로 강조돼 있어, 이후 실습에서 집중적으로 다뤄질 실패 사례임을 예고한다. 최종 점수는 (PASS + ½·PASS-SLOW) / 12로 계산하며, 참고 범위는 before/after starter 기준 6375%, after는 83~100%다.

[09:25] 5. R8 딥다이브 — 프로모 예측이 왜 틀렸나

장면 5 — R8 eval의 실제 터미널 출력과 grader FAIL 상세

SKU-0116의 프로모 월 예측 태스크(R8)를 구체적으로 뜯어본다. 베이스라인은 하루 12유닛, 60일 전 이력에 3.2배 프로모 스파이크가 있었으니 목표는 12×30×2.5=900유닛 근처여야 한다. 실제 터미널 로그를 보면 에이전트는 서브에이전트로부터 “베이스라인 하루 12유닛, 프로모 승수 ~3.1배(2월 프로모가 10일간 372유닛을 움직인 데이터 기준)“까지는 정확히 뽑아냈다. 문제는 그다음 계산 단계 — reorder formula: avg_daily × horizon × safety = 12 × 30 × 1.35 ≈ 486 units로, 승수 3.1배가 산술식에 전혀 반영되지 않은 채(← lift never applied) 1.35라는 엉뚱한 안전계수만 곱해졌다. 그레이더는 목표 대비 -46%로 FAIL 처리하며 “anchored on mean?”이라는 코멘트를 남긴다. 왼쪽 설명이 원인을 짚는다: 리오더 공식·프로모 정책·예측 해석이 ~400줄 프롬프트의 서로 다른 섹션에 흩어져 있고, 에이전트는 서브에이전트의 산문에서 “~12/day”만 추출해 공식에 대입할 뿐, 언급된 lift는 산술식까지 이어지지 않는다. 이는 모델 능력 문제가 아니라 에이전트를 둘러싼 정보(컨텍스트) 구조의 문제라는 것이 이 세션 전체의 핵심 진단이다.

[11:40] 6. Claude Managed Agents 소개

장면 6 — "Claude Managed Agents" 정의 슬라이드

워크숍은 Messages API 위에 직접 만든 기존 에이전트(“before” 폴더)를 Claude Managed Agents(CMA) 로 마이그레이션하는 것으로 시작한다. CMA는 “하네스와 매니지드 인프라를 제공”해 세션 관리, 수천~수만 유저로의 안전한 스케일링을 오프로드하고, 개발자는 툴·스킬·서브에이전트에 대한 아키텍처 결정에만 집중할 수 있게 해준다. 로컬에서 빠르게 만들고 실행하는 것과, 그 에이전트를 원격 호스팅해 동시에 수천 명이 쓰게 만드는 것 사이에는 인프라·스케일링·메모리·보안 문제가 끼어드는데, CMA가 그 부담을 대신 진다는 설명이다.

[13:35] 7. 핸즈온 워크숍 안내

장면 7 — 워크숍 링크와 이름이 적힌 안내 슬라이드

여기서부터 청중은 노트북을 열고 워크숍 링크로 이동해 agent-decomposition이라는 이름의 실습 저장소를 받는다. 저장소는 uv sync로 의존성을 설치하고 API 키를 .env에 넣는 것으로 시작하며, repo 안에는 before(Messages API로 직접 만든 원본 에이전트)와 starter(CMA에 배포할 버전) 두 폴더가 있다. uv run evals --agent before로 12개 eval의 베이스라인을 확인하고, uv run deploy starter로 CMA에 배포한 뒤 uv run evals --agent starter로 비교하는 흐름이다.

[17:45] 8. Claude Code로 베이스라인 eval 실행 — 62%

장면 8 — Claude Code 터미널, uv run evals 실행 결과와 F1 root-cause 설명 시작

발표자는 Opus 4.7 · xhigh effort로 설정한 Claude Code를 열어 uv run evals --agent before를 백그라운드로 실행한다. 결과는 7/12 = 62% — 슬라이드에서 봤던 71%보다도 낮다. 곧바로 “이 eval 결과를 이해하도록 도와줘, 핵심 이슈가 뭐야?”라고 물으면, Claude가 실패를 네 가지 뚜렷한 문제로 클러스터링해준다. 첫 번째로 짚은 F1(“Daily low-stock sweep”)은 328초·216,000토큰을 쓰며 타임아웃 — list_low_stock이 400행짜리 상품 데이터를 통째로 컨텍스트에 던져 넣고 모델이 그걸 눈으로 훑는 구조라는 게 초기 진단이다.

[19:10] 9. 근본 원인 3가지 — 프레임워크 원칙으로 매핑

장면 9 — Claude가 정리한 세 가지 root-cause 테마

이어서 “왜 이런 문제가 생겼는지 테마로 정리해줘(RCA)“라고 요청하자, Claude가 세 가지 원칙 위반으로 정리한다. ① 모델이 툴이 해야 할 일을 대신 하고 있다 → compute-over-context 위반: R2(SKU 2개 누락)·F1(328초·216k토큰) 모두 서버사이드에서 필터링해야 할 일을 모델이 덤프된 데이터를 눈으로 스캔하며 처리하고 있었다 — list_low_stock이 400행을 그대로 반환하는 게 원인. ② 출력 형식이 강제되지 않는다 → typed-contract 누락: F2에서 신뢰도가 숫자 대신 “fairly confident” 같은 산문으로 돌아와, 프롬프트나 툴 스키마 어디에도 숫자 필드를 강제하는 장치가 없다는 게 원인 — SKILL.md에 JSON 계약을 박아두면 해결된다. ③ 정책·포맷이 매 호출마다 재도출된다 → policy-as-skill 누락: R8(프로모 예측 -34%)은 프로모가 예측에 미치는 영향에 대한 성문화된 규칙이 없어 평균에 anchoring, F3(15k 출력토큰)는 알림 템플릿이 없어 매번 처음부터 다시 쓰고, R9(374k 토큰·11턴, 통과는 함)는 주간 리포트 구조를 스킬에서 따르지 않고 매번 재발명한다. 메타 패턴: “before-agent는 raw 툴을 쥔 제너럴리스트다. 모든 실패는 구조화되어야 할 무언가(필터 로직·출력 스키마·정책·템플릿)가 대신 매 실행마다 재도출되는 사례다.”

[24:10] 10. 시스템 프롬프트 → 스킬로 — Cycle 1

장면 10 — 416줄 LEGACY_PROMPT 대 SHORT_PROMPT+스킬 비교 설명

첫 리팩터링 사이클. 발표자는 “시스템 프롬프트가 너무 길다, 스킬로 대체할 수 있을까?”라고 묻는다. Claude의 분석: LEGACY_PROMPT는 416줄인데 이게 매 턴마다 로드된다 — 리오더 규칙도 공급사 순위도 리포트 구조도 전혀 건드리지 않는 17k토큰짜리 단순 재고 조회(R1) 한 번에도 전부 실려간다. 게다가 .claude/skills/ 아래 이미 존재하는 5개 스킬 파일이 같은 정책 영역을 다루고 있어(reorder-policy/SKILL.md 하나만 해도 ~35개 섹션 — 의사결정 규칙·프로모 처리·에스컬레이션 매트릭스), 결국 LEGACY_PROMPT 안에 전부 중복돼 있던 셈이다. 스킬의 progressive disclosure 구조는 이렇다: CMA는 평소엔 각 스킬의 description: 필드(한 줄, ~50토큰)만 컨텍스트에 상주시키고, 모델이 태스크가 해당 스킬과 맞는다고 판단할 때만 SKILL.md 본문 전체를 읽는다 — 재고 조회는 재주문 정책에 대해 한 푼도 안 내지만, 재주문 태스크는 필요한 순간에 전체 비용을 낸다. 이미 준비된 SHORT_PROMPT(agent.py:66-84)는 “비즈니스 정책은 스킬에 있다 — 정책 적용 전 관련 스킬을 로드하라”고 명시하는데, 프롬프트만 바꾸고 스킬을 활성화하지 않으면 모델은 정책이 아예 없는 상태가 되고, 반대로 스킬만 켜고 프롬프트를 안 바꾸면 정책이 416줄 프리앰블과 스킬 양쪽에 중복된다 — 그래서 둘을 반드시 페어링해야 한다는 설명이다. 프레임워크 원칙: policy-as-skill + progressive disclosure.

[26:35] 11. 툴의 세 가지 패턴 — Cycle 2

장면 11 — context-dumper/subagent-hider/trivial-write 세 가지 툴 패턴 분석

“툴에 대해 뭘 할 수 있을까? bash/read/write로 대체하고 싶다”고 요청하자, Claude가 삭제 전에 먼저 list_low_stock이 매번 실제로 무엇을 반환하는지 근거를 확인한 뒤 세 가지 패턴으로 정리한다. ① Context-dumper: list_low_stock이 매 호출마다 395행짜리 CSV를 통째로 넘겨, 모델이 눈으로 훑어 상위 N개 긴급 SKU를 찾아야 했다(F1 타임아웃·R2 누락의 원인) — Python 한 줄로 (on_hand - reorder_point) 기준 정렬 후 상위 20개만 컴팩트 JSON으로 반환하면 계산이 모델 머릿속이 아니라 샌드박스에서 일어난다. ② Subagent-hider(산문 반환): forecast_demand는 문자 그대로 subagents.forecasting_subagent(sku, context_note=note)를 호출해 자유서술 텍스트를 받아오고, compare_supplier_quotes도 같은 구조다 — F2의 신뢰도가 “fairly confident”로 나오고 0.72 같은 숫자로 안 나온 게 여기서 비롯됐다. forecasting/supplier-selection 스킬에 JSON 반환 형식을 못 박으면 해결된다. ③ Trivial write: create_purchase_order는 딕셔너리를 만들어 JSONL에 append하는 3줄짜리 함수라 bash python -c 'json.dumps(...)' >> sinks/purchase_orders.jsonl이 툴 정의 오버헤드 없이 똑같은 일을 한다. 덤으로 scope 판단도 하나 짚는다 — search_web_for_disruptions는 캔드 텍스트만 반환하는 스텁인데, 웹/뉴스 모니터링은 애초에 이 재고 에이전트의 책임 범위가 아니라 별도 서비스로 분리해야 한다는 것.

[29:05] 12. 툴 → 프리미티브 매핑 표

장면 12 — 12개 커스텀 툴이 bash/read/write + 스킬로 치환되는 코드 diff와 표

diff 나레이션: 12개 툴이 전부 사라지고 LEGACY_TOOLS: list[str] = []가 되며, 이제 에이전트에는 agent_toolset_20260401(Bash/Read/Write/Task)과 cycle 1에서 활성화한 5개 스킬만 남는다. 표로 정리된 치환 내역은 이렇다: get_stock_level/get_sales_velocity/get_supplier_catalog → CSV 위 bash(awk, 소규모 Python), list_low_stock → Python 스크립트로 top-N JSON 반환(F1/R2 수정), forecast_demand → forecasting 스킬이 인라인 계산과 Task(forecaster) 위임을 JSON 계약으로 라우팅, compare_supplier_quotes → supplier-selection 스킬에 따른 Python 정렬, create_purchase_order/update_erp_record → bash 또는 Write로 /mnt/user/sinks/*.jsonl에 append. 발표자가 세션 초반 강조했던 원칙 — **“사람처럼 컴퓨터 앞에 있을 때 쓰는 프리미티브(파일시스템 탐색, 코드 실행, 웹 검색, 할일 목록)로 먼저 시작하고, 필요할 때만 커스텀 툴을 추가하라”**가 여기서 구체적인 diff로 실현된다. CMA를 쓰면 이런 컴퓨터형 프리미티브가 기본 제공되므로 코드 실행·파일시스템 접근용 툴을 직접 짤 필요가 없다는 점도 언급된다.

[32:05] 13. 재배포 후 F1 재실행

장면 13 — "Deploy landed. Running F1" 터미널 로그

에이전트 ID·파일 해시 등 배포 메타데이터가 스크롤되며 “Deploy landed. Running F1”이 뜬다 — 툴 정리를 마친 버전을 CMA에 다시 배포하고 F1 eval을 재실행하는 순간이다. 발표자는 이 과정에서 MCP에 대한 팁도 짚는다: 툴을 만들 때는 ① 먼저 Claude Code형 프리미티브(웹 검색·코드 실행·파일시스템)로 시작하고, ② 그 에이전트 전용 커스텀 툴을 추가하고, ③ 여러 클라이언트가 공유해야 하는 표준화된 툴 묶음일 때만 MCP 서버로 퍼블리시하라는 순서다. MCP로 바로 달려가는 고객이 많지만 중복되는 MCP 서버가 난립하며 문제가 생기는 경우가 흔하다고 지적하며, CLI·API를 코드 실행으로 직접 호출하는 방식이 MCP보다 컨텍스트 오염이 적은 경우도 있다고 덧붙인다.

[34:05] 14. F1의 Before/After — 극적인 경제성 개선

장면 14 — F1 FAIL→PASS 전후 비교표(시간·토큰·비용)

Cycle 0(before) 대 Cycle 1+2(after)의 F1 지표가 표로 뜬다: 결과 FAIL(예산 초과)→PASS, 벽시계 시간 328초→164초(~2배 빠름), 토큰 216,365→7,628(~28배 절감), 턴 수 7→5, 비용 ~ $2 \to$ 0.07(~30배 절감). 216k→7.6k 토큰 하락은 compute-over-context가 작동한 직접적 증거로 설명된다 — 395행짜리 list_low_stock 덤프가 사라지고 사이드박스에서 정렬해 상위 N개만 반환하는 방식으로 바뀌었고, 416줄 LEGACY_PROMPT 프리앰블이 ~~18줄 SHORT_PROMPT + 필요할 때만 로드되는 스킬로 바뀌었으며, 산문을 왕복하던 subagent-hider 구조가 사라졌기 때문이다. starter 에이전트가 참고 범위(63~~75%)를 이미 웃도는 성과를 냈고, 여기까지는 단일 태스크(F1) 기준이라 12개 전체 스위트를 재실행해 회귀가 없는지 확인하자는 제안으로 이어진다.

[36:05] 15. 서브에이전트 재검토 — Cycle 3

장면 15 — 기존 서브에이전트 배선 방식과 CMA callable_agents 설명

“이제 서브에이전트를 보자. 현재 포캐스터 서브에이전트는 툴로 노출돼 있는데, 어떻게 개선할 수 있을까? CMA의 네이티브 callable_agents를 쓸 수 있을까?”라는 질문에 Claude가 먼저 현재 배선을 근거로 확인한다. 2025년식 forecast_demand 툴은 내부적으로 두 번째 Messages API 호출을 하는 Python 함수이고(agents/before/subagents.py:62-83), 반환 타입은 그냥 str — 서브에이전트에게 “자연스럽게 써라, 숫자가 포함된 명확한 문장으로 끝내라”고 지시한 뒤 오케스트레이터가 그 산문에서 숫자를 파싱한다. F2의 수치 신뢰도가 여기서 사라진 것(“medium confidence” → 추출할 숫자 없음)이다. 메인 에이전트 입장에서 이 위임은 완전히 불투명하다 — 툴을 호출했고 텍스트를 돌려받았을 뿐, 세션 추적도 타입이 있는 핸드오프도 병렬화 가능성도 없다. 반면 CMA의 callable_agents는 config에 "wants_forecaster": True만 설정하면 deploy가 자동으로 네 가지를 처리한다: 별도의 stockpilot-forecaster 에이전트를 자체 시스템 프롬프트(통계 계산 후 {forecast_qty, confidence, method, flags} 형태의 엄격한 JSON 반환을 지시)와 함께 프로비저닝하고, forecaster에게는 bash+read만 부여하며(write·web 없음), callable_agents를 통해 starter 에이전트에 붙인다.

[39:05] 16. 포캐스터 서브에이전트 프로비저닝 — 한 줄 diff

장면 16 — "wants_forecaster": True 한 줄 diff와 F2 배포 로그

diff는 정확히 한 줄, "wants_forecaster": True — 이 한 줄로 deploy가 stockpilot-forecaster(bash+read 전용, 자체 컨텍스트 윈도우, 같은 CSV를 마운트)를 프로비저닝하고 callable_agents로 starter에 연결한다. 예상되는 eval 변화: F2(프로모 재주문+수치 신뢰도)는 신뢰도가 {"forecast_qty": 1240, "confidence": 0.72, "method": "rolling_mean_with_promo_lift", "flags": ["promo_next_month"]} 같은 서브에이전트의 구조화된 반환에서 직접 오게 되어 프로세 파싱보다 깨끗한 provenance로 PASS할 것으로 예상되고, R8(프로모 월 예측)도 같은 메커니즘으로 계속 PASS하되 인라인 계산이 아니라 콜러블 위임을 거치게 되며, 예측을 트리거하는 태스크에서 메인 에이전트의 토큰 비용도 소폭 줄 것으로 본다 — 더는 90일치 이력을 자기 컨텍스트에 로드하지 않기 때문이다. 배포 후 F2를 재실행하는 로그가 이어진다.

[41:05] 17. 최종 아키텍처 — “One agent. Five skills. Subagents only when a skill says so.”

장면 17 — 최종 아키텍처 요약(15줄 프롬프트, 5개 스킬, 0개 하드코딩 서브에이전트, 92%)

세 사이클을 거친 최종 결과가 숫자 네 개로 요약된다: 시스템 프롬프트 15줄, 스킬 5개(온디맨드 로드), 하드코딩 서브에이전트 0개, eval 점수 92%(11/12). 아키텍처 다이어그램은 StockPilot(Claude Managed Agents)가 claude-sonnet-4-6 위에서 15줄 시스템 프롬프트로 돌며, 세 갈래로 뻗는다 — 5개 스킬(reorder-policy·supplier-selection·forecasting·notify-templates·weekly-report), agent_toolset(Bash·Read·Write), 그리고 callable_agents → forecaster(CMA의 멀티에이전트 프리미티브). 맨 아래 캡션이 전체를 한 줄로 정리한다 — “12개 인라인 툴 → agent_toolset + 5개 스킬 + callable_agents.” 시작할 때의 400줄·12툴·3서브에이전트 오케스트레이터와 정확히 대비되는 그림이다.

[43:35] 18. 마무리 — 3가지 교훈

장면 18 — "Take what you learned back home" 3가지 takeaway 슬라이드

세션을 세 가지 교훈으로 마무리한다. ① 단순하고 조합 가능한 에이전트가 모델 지능과 함께 확장된다 — bash·스킬·서브에이전트 같은 기초 프리미티브 위에 설계하면 역량이 늘어나는 동시에 컨텍스트 관리도 더 효율적이 된다. ② 조직 절차는 온디맨드로 로드하라 — 시스템 프롬프트에서 컨텍스트를 덜어내 스킬로 옮기면 에이전트가 태스크에 필요한 것만 로드하게 된다. ③ Evals는 제품 비전과 함께 진화해야 한다 — 모델 역량이 계속 바뀌는 만큼 evals도 함께 바뀌어야, 실제로 신경 쓰는 것을 측정하고 있는지 확인할 수 있다. 왼쪽에는 platform.claude.com/docs의 managed-agents·callable_agents·skills 문서 경로가, 본문 상단에는 “evals를 hill climbing 사이클로 계속 돌려라 — 베이스라인을 잡고, 아키텍처를 조정하고, 다시 eval을 돌려 개선을 확인하는 과정을 반복하라”는 핵심 조언이 담겨 있다.

핵심 개념·용어 메모

Hill climbing — eval로 베이스라인을 잡고, 아키텍처를 한 단계씩 조정하고, 다시 eval을 돌려 개선폭을 확인하는 반복 사이클. Anthropic이 내부적으로 에이전트를 개선할 때 쓰는 핵심 방법론으로 세션 전체를 관통한다.
compute-over-context — 모델이 눈으로 데이터를 스캔·계산하게 하지 말고 서버사이드(샌드박스) 코드가 계산을 대신 하게 하라는 원칙. 원인: 툴이 필터링/정렬 없이 raw bulk 데이터를 반환하면 느리고 비싸고 손실이 생긴다.
typed-contract (출력 스키마 강제) — 툴/스킬 반환값에 JSON 계약을 명시해 “fairly confident” 같은 산문이 아니라 confidence: 0.72 같은 파싱 가능한 값이 나오게 하는 것.
policy-as-skill + progressive disclosure — 정책·포맷·템플릿을 시스템 프롬프트에 상시 상주시키지 말고 스킬로 옮겨, 평소엔 description: 한 줄(~50토큰)만 로드하고 모델이 필요하다고 판단할 때만 SKILL.md 전체를 읽게 하는 구조.
Claude Managed Agents (CMA) — 하네스·세션 관리·스케일링 인프라를 Anthropic이 대신 맡아주는 배포 플랫폼. 개발자는 태스크·아키텍처(툴/스킬/서브에이전트)에만 집중할 수 있다.
callable_agents — CMA의 네이티브 서브에이전트 primitive. config에서 "wants_X": True 한 줄로 별도 에이전트를 프로비저닝·연결하며, 세션 추적·JSON 계약·로깅이 자동으로 따라온다. “툴로 감싸 산문을 파싱”하던 기존 방식(subagent-hider)의 대안.
서브에이전트를 쓰는 두 가지 대표 상황 — ① 병렬로 많은 Claude를 문제에 투입할 때(딥리서치, 코드 탐색), ② 원본 컨텍스트에 오염되지 않은 “새로운 시각”이 필요할 때(코드 작성자와 리뷰어를 분리하듯, 예측 로직을 메인 대화와 분리).
인간형 프리미티브 우선 원칙 — 사람이 출근해서 쓰는 도구(파일시스템, 브라우저/웹검색, 코드 실행, 할일 목록)로 먼저 시작하고, 필요한 만큼만 커스텀 툴을 추가하라는 설계 원칙. CMA는 이런 프리미티브를 기본 제공한다.
MCP를 쓰는 순서 — ① Claude Code형 프리미티브 → ② 에이전트 전용 커스텀 툴 → ③ 여러 클라이언트가 공유해야 하는 표준 툴 묶음일 때만 MCP 서버로 퍼블리시. MCP는 컨텍스트 오염을 유발할 수 있어 코드 실행(CLI/API 직접 호출)이 대안이 되기도 한다.
eval 채점 방식 — (PASS + ½·PASS-SLOW) / 12. 그레이더 5종: exact_match, set_match, action_taken, numeric_tolerance(±20~25%), llm_judge, 그리고 F1/F2/F3에는 복합·정규식·효율성 그레이더가 추가로 쓰인다.

등장한 사람·조직·키워드

William Steuk(Anthropic Applied AI팀), Anthropic, Claude Managed Agents(CMA), Claude Code, Opus 4.7, StockPilot(실습용 재고관리 에이전트), Code with Claude London(컨퍼런스), agent-decomposition(워크숍 저장소명), Messages API, MCP, Bash/Read/Write(agent_toolset), SKILL.md, callable_agents.

원문 인용 모음

[01:32] “So, if this is you, you’re not alone. We see this type of scenario happen pretty commonly with customers and actually with ourselves included in that.”
[10:12] “A hint here is that the reason for this is that we have a context problem. So, this isn’t a model problem. It’s an issue with… the information that we’re surrounding the model with.”
[22:47] “Leave the system prompt only for the information that Claude needs in its mind, regardless of the task that you give it. Skills are fantastic for packaging information that Claude is going to need some of the time, not all of the time.”
[26:32] “Whenever we build agents, we lean into the same primitives that we as humans have access to… code execution and the navigation of a file system, the keeping of a to-do list, the ability to search the web.”

description	Code with Claude 워크숍 — 비대해진 에이전트를 스킬·프리미티브 툴·callable_agents로 재설계해 eval 62%→92% 개선
tags	ai-agents, anthropic, claude-code, harness, youtube

LLM Wiki

탐색기