「Fable 5는 나 자신보다 더 신뢰한다」 Claude Code 개발자에게 듣다【Code w/ Claude Tokyo 현지 참가 리포트】

서론

6/10, Anthropic이 일본에서 처음으로 개최한 개발자 이벤트 Code w/ Claude Tokyo에 참가하고 왔습니다.

행사장 사인과 도쿄의 거리 풍경

게다가 이날은 우연히도 (아니, 노렸던 것이겠지만) Claude Fable 5의 출시 당일이었습니다. 행사장 전체가 "오늘 아침에 나온 그거, 벌써 써봤어?"라는 분위기로 시작되는, 좀처럼 얻기 힘든 날이었습니다.

저는 손해보험 재팬(Sompo Japan)에서 AI 에이전트 시스템을 개발하고 있는 엔지니어입니다. 매일 Claude Code로 에이전트의 오케스트레이션 (Orchestration)을 구성하고 있는 입장에서, "내부 관계자에게 묻고 싶은 것"들을 준비해 참가했습니다.

이 글에서 다루는 내용:

• 워크숍 및 세션에서 들을 수 있었던 실전 지식
• 행사장에서 Claude Code 개발 엔지니어와 직접 대화할 기회가 있었고, 그곳에서 들은 생생한 이야기 (본 기사의 메인 내용)
• 금융 엔터프라이즈에서 AI 에이전트를 개발하고 있는 실무자로서의 인사이트

TL;DR — 핵심 요약 5가지

• Fable 5는 "빨라진 것은 아니지만, 똑똑해졌기 때문에 결과적으로 빠르다". 내부 관계자의 체감상 1개 태스크의 소요 시간이 절반으로 줄고, 인간의 리뷰는 5회에서 1~2회로 감소
• 비용 최적화의 정석은 3가지: prompt caching / 컨텍스트 (Context)를 짧게 유지하기 (자주 compact 수행) / 모델 라우팅 (Model Routing) (탐색 계열 작업은 Haiku로)
• eval(평가)에 은탄환(Silver Bullet)은 없다. 고객 데이터에서 좋은 사례를 골라 꾸준히 만들어야 한다. "비밀스러운 테크닉은 없다, 직접 할 수밖에 없다" — eval의 중요성은 거의 모든 세션에서 반복적으로 언급된, 사실상의 이벤트 숨은 테마였습니다
• plan(계획)에 검증 단계를 상세히 적으면, 에이전트는 되묻지 않고 몇 시간 동안 자율 주행한다 — 무인 운용 및 에스컬레이션 (Escalation) 설계의 핵심
• 병목 구간은 코딩에서 상류(요구사항·설계)와 검증·리뷰로 이동했다. 이는 Anthropic 사내에서도 마찬가지이며, 조직론 세션의 중심 테마였습니다

행사장 모습

키노트 행사장. 만석입니다

키노트 + 여러 워크숍·토크 + 프로덕트 데모라는 구성으로, 직접 손을 움직이는 계열과 이야기를 듣는 계열이 균형 있게 섞인 하루였습니다. 샌프란시스코, 런도에 이어 세 번째 도시이며, 일본 개최는 처음이라고 합니다.

참고로 저는 워크숍을 닥치는 대로 돌아다니는 전략을 택했기 때문에, 메인 스테이지의 토크는 거의 듣지 못했습니다 (웃음). 키노트나 사례 세션에 대한 리포트는 다른 분들의 기사에 맡기고, 이 글은 "직접 해보는 방"에서 얻은 이야기에 집중하겠습니다.

휴식 공간에는 로고가 새겨진 컵케이크(Microsoft Foundry 제공)도 있음

세션 하이라이트 (실전 지식이 농축된 3가지)

돌아본 세션 중 3가지를 엄선하여 소개합니다.

1. The thinking lever — effort와 「3종류의 토큰」

Claude의 effort 파라미터 (low / medium / high / max)의 설계 사상을 내부 관계자가 해설하는 세션입니다. 개인적으로 가장 머릿속이 정리된 것은, 에이전트가 소비하는 토큰을 3종류로 분류하는 사고방식이었습니다.

종류	용도
Planning tokens	계획·추론 (Thinking)
Action tokens	도구 호출(Tool Call)·코드 실행
Text tokens	사용자에게 보내는 답변·질문·요약

effort는 이 배분을 "대략적인 우선순위 지정"으로 컨트롤하는 다이얼이며, 발표자의 비유를 빌리자면 "디자이너나 엔지니어를 고용할 때, 시간당 단가를 마이크로매니지먼트하는 것이 아니라 우선순위를 전달하는 것과 같다". adaptive thinking은 그 진화형으로, 단계마다 "생각할 것인가·얼마나 생각할 것인가"를 모델 스스로 결정한다 ("2+2"에 굳이 사고 토큰을 사용하지 않는다)는 정리였습니다.

평소 막연하게 /effort를 전환하던 입장으로서, "무엇을 증감시키고 있는가"에 대한 해상도가 높아진 것이 수확입니다.

2. The prompting playbook — 사고가 나는 것은 언제나 「너무 강한 지시」

통신 기업의 고객 지원 봇을 주제로, 실제 프로ンプト(Prompt)의 실패 사례를 수정해 나가는 핸즈온(Hands-on) 세션입니다. 케이스 스터디가 구체적이어서 좋았습니다.

케이스 1: 너무 신중한 모델

「고객에게 잘못된 플랜 정보를 절대 내보내지 마라」라는 강력한 지시 때문에, 수중에 있는 올바른 데이터까지 내보내기를 주저하게 된 사례. 수정 방법은 「고객 계정의 스냅샷은 신뢰할 수 있는 데이터이며, 직접 답변해도 좋다」라고 명시하는 것. never / always 계열의 규칙은 효과가 너무 강력하다는 교훈입니다.

케이스 1의 해결 슬라이드. 「방어적인 패치(defensive patch)는 축적되어 서로 모순되기 시작한다」라는 Best practice란이 인상적입니다

케이스 2: 계산을 프롬프트(Prompt)로 억지로 해결하려 하지 마라

일할 계산(proration)이 부정확할 때 → 프롬프트에 「중요!」, 「매우 중요!!」라고 덧붙여도 수학적 정확도는 1mm도 올라가지 않는다. 정답은 계산 도구(tool)를 전달하고, 모델에게는 「도구를 호출할지 직접 답변할지」를 판단하게 하는 것입니다.

케이스 3: 에스컬레이션(Escalation) 경계는 「양면」을 작성하라

비용 지표를 너무 의식하게 만든 결과, 사람에게 넘겨야 할 청구 트러블까지 스스로 해결하려고 했던 사례. 규칙에는 반드시 역방향 가이드(「단, 청구 트러블은 항상 사람에게」)를 세트로 작성해야 합니다.

이 외에도 XML 태그를 이용한 구조화, 오래된 조건문 삭제와 같은 「프롬프트 위생(prompt hygiene)”, 그리고 모든 변경 전후로 eval을 돌린다는 대원칙. 모두 사소해 보이지만, 실제 환경에서 봇(bot)을 운용하고 있는 사람일수록 와닿는 내용이었다고 생각합니다.

3. Build a proactive agent workflow — 에이전트 자동화 「Routines」 데모

GitHub의 이벤트나 cron을 트리거로 에이전트 워크플로우를 자동 실행하는 Routines 데모. 구성 요소는 세 가지입니다:

Trigger: 스케줄 / GitHub 이벤트(issue·PR·릴리스·라벨) / Webhook -
Connector: 에이전트가 사용할 수 있는 도구·MCP 서버 -
Human-in-the-loop: 실행 중인 세션을 사람이 라이브로 감시하고 중간에 개입할 수 있음

데모는 「GitHub에 issue가 생성됨 → 에이전트가 문서를 일본어로 번역하여 PR을 생성함」이라는 일본 개최다운 내용이었습니다. 실행 중인 에이전트에 사람이 개입하여 궤도를 수정할 수 있다는 점이 인상적이었습니다. CI 연동 무인 운용을 직접 구축하고 있는 입장에서는, 이러한 방향의 공식 지원은 반가운 흐름입니다.

Trigger는 Schedule / Release / Label 기반 등 유연하게 설정할 수 있다

【메인】Claude Code 개발 엔지니어에게 전부 물어보고 왔다

자, 이제 본론입니다. 회장에서 Claude Code를 개발하고 있는 엔지니어분과 직접 이야기할 기회가 있었습니다. 다음은 개인적인 견해 및 체감으로서 전달받은 내용의 요지입니다.

Q. Fable 5, Opus 4.8에서 무엇이 가장 변했나요?

모델의 응답이 빨라진 것이 아니다. 다만

똑똑하기 때문에, 결과적으로 빠르다.

Opus 4.8에서는 「이 부분이 다르다, 저 부분도 다르다」며 수정 지시를 반복해야 해서 하나의 태스크에 1시간이 걸렸다면, Fable 5에서는 30분 만에 끝난다.

4.8은 솔직히 완전히 신뢰할 수 없는 부분이 있었지만, Fable 5는 나 자신보다 더 신뢰하고 있다.

릴리스 당일에 내부 관계자로부터 직접 들은 「나 자신보다 더 신뢰하고 있다」는 말은 상당한 임팩트가 있는 표현(power word)이었습니다. 가격은 Opus 4.8의 2배(입력 $10 / 출력 $50 per 1M 토큰)이지만, 인간의 리뷰 시간으로 비용을 회수할 수 있는가라는 관점으로 바라봐야 할 것입니다.

Q. 사내에서는 Claude Code에 어느 정도 의존하고 있나요?

매일 Claude Code로 Claude Code를 만들고 있다.

이제 스스로는 거의 코드를 쓰지 않는다.

에이전트는 날마다 다르지만, 나는 하루에 10개 이상의 에이전트를 병렬로 돌리고 있다.

dogfooding은 상상 이상으로 철저하며, 사내에서는 토큰 사용량을 신경 쓰지 않고 사용할 수 있는 환경이라고 합니다. 「PM도 디자이너도 모두 Claude를 사용하고 있다」는 이야기도 있었는데, 이는 후술할 「상류 병목(upstream bottleneck)」 이야기로 이어집니다.

Q. 여러 AI 모델로 크로스 리뷰(cross-review)를 시키는 것은 괜찮은 방법인가요?

저희 팀에서는 PR 리뷰를 여러 AI 모델로 상호 체크하는 운용을 하고 있어서, 본사에서는 어떻게 보는지 물어보았습니다.

크로스 체크는

매우 좋은 아이디어다. 확실히 에러를 줄여주고, 출력의 질을 높인다.

환각 (Hallucination) 대책으로서 「다시 한번 체크해줘」를 반복하게 하는 것은 실제로 효과가 있다.

다만, 나는 최종적으로는 모든 코드를 직접 리뷰하고 있다.

「AI에게 전적으로 맡기지 않고 마지막에는 인간이 본다」라고 본사의 엔지니어가 말하는 것은, 안심할 수 있는 요소이기도 하며, 「리뷰의 완전 자동화는 아직 멀었다」라는 현재 위치를 표명하는 것이라고 받아들였습니다.

Q. 에이전트의 비용이 부담스럽습니다. 최적화의 정석은?

에이전트 시스템의 비용으로 고민하고 있으며, 엔지니어의 마음으로는 전부 최강 모델로 밀어붙이고 싶다고 상담했더니:

Prompt caching (프롬프트 캐싱)은 하지 않을 이유가 없다. Agentic (에이전트적) 워크플로우에서는 특히 효과적이다. 초장기 컨텍스트 (Long context)는 그 자체로 비용이 높다. 수시로 compact (압축) 하여 컨텍스트를 짧게 유지하는 모델 라우팅 (Model routing)은 실제로 효과가 있다. 예를 들어 Claude Code의 Explore agent는 파일 읽기를 Haiku로 수행한다. — 다만 유일한 정답은 없다. 직접 시도해 보는 수밖에 없다.

세 번째는 가볍게 언급되었지만, Claude Code의 내부 구현이 「탐색은 저렴한 모델, 핵심은 강력한 모델」로 라우팅을 하고 있다는 실례로, 자체적인 멀티 에이전트 (Multi-agent) 구성에 그대로 도입할 수 있는 지견입니다.

「Beyond the basics with Claude Code」 슬라이드에서. 컨텍스트 윈도우 (Context window)는 「상자」이고, 당신은 「패키지 매니저」 — 너무 많이 채워 넣지 말라는 감각을 한마디로 표현한 명문구였습니다.

Q. 워크플로우의 「최적해」는 어떻게 찾나요?

다단계 에이전트 워크플로우를 구축하고 있는데, 이것이 최적인지 아니면 너무 과하게 만들고 있는 것인지 모르겠다는 고민을 던졌습니다.

Eval (평가)이 전부다. Eval set (평가 세트)은,

수중에 있는 고객 데이터에서 좋은 사례를 골라 만든다. 직접 만들어도 좋다.

비밀스러운 테크닉은 없다. 좋은 eval을 만드는 것은 수고와 시간이 들지만, 할 수밖에 없다.

기대했던 「비책」은 존재하지 않았습니다. 반대로 말하면, eval만 만들면 본사와 같은 선상에서 싸울 수 있다는 뜻이기도 합니다.

참고로 이것은 이분만의 개인적인 견해가 아니라, 돌이켜보면 이날은 eval이 이벤트 전체를 관통하는 공통 테마였습니다. 모델 선정 워크숍 「Picking the right model」은 통째로 「공개 벤치마크는 당신의 유스케이스 (Use case)를 거의 커버하지 못한다. 자체적인 eval set을 만들고, 여러 모델 × effort (노력) 설정을 전수 조사하여 최적의 구성을 찾아라」라는 내용이었고, 「The prompting playbook」의 대원칙도 「모든 변경의 전후로 eval을 돌린다」였습니다. 어떤 세션도 파고들면 결국 마지막은 eval 이야기로 귀결되었습니다.

Q. 병렬 에이전트, 인간의 리뷰가 따라가지 못하지 않을까요?

맞는 말씀입니다.

인간의 리뷰 대역폭 (Bandwidth)이 병목 (Bottleneck)이 된다.

그렇기에 Fable 5가 효과적이다. Opus 4.8에서는 하나의 결과물에 5번의 리뷰가 필요했다면, 1~2번, 때로는 한 번에 OK가 된다.

나머지는 AI 스스로 체크하게 하는 공정 (자동 코드 리뷰, 크로스 체크)을 늘리면 전체 속도가 빨라진다.

「병렬 수를 늘리는」 방향이 아니라 「1회당 리뷰 부하를 낮추는」 방향으로 해결한다는 정리는 무릎을 탁 치게 만드는 통찰이었습니다.

Q. 무인 운용 시, 언제 인간에게 에스컬레이션 (Escalation)해야 할까요?

headless 모드에서의 무인 운용에 대해 물었더니, 이것이 개인적으로 가장 큰 수확이었습니다.

headless는 사내에서도 대량으로 사용하고 있다. 코드 리뷰도, 데스크톱 앱도 VS Code 확장도 Web 버전도, headless 위에 만들어져 있다.

미래의 방향성은 「처음에 시간을 들여서, 정말 좋은 plan (계획)을 만드는 것」이다. plan에 충분한 정보가 있다면, 에이전트는 인간에게 되묻지 않고 장시간 자율적으로 동작할 수 있다.

특히 plan에 테스트나 명확한 검증 단계를 적어두면, 완료를 스스로 검증할 수 있으므로 자율성이 크게 올라간다. Fable 5라면, 좋은 plan을 넘겨주면 몇 시간은 스스로 돌아간다.

「에스컬레이션 규칙을 정교화하는」 것이 아니라 「애초에 되물을 필요가 없는 plan을 처음에 만드는」 발상의 전환. 저희 팀에서도 계획 주도 (plan에 수락 조건을 다 적은 뒤 구현 에이전트에게 넘기는) 운용을 짜고 있었기에, 방향성에 대한 든든한 확인이 되었습니다.

Q. 코딩이 빨라진 결과, 병목이 상류로 이동하지 않았나요?

맞습니다. 그리고 해결책은 아직 없습니다.

코딩은 모델이 능숙하게 처리해 줍니다. 제 업무는 설계, 미팅, 비즈니스 요구사항(Business Requirements) 이해로 바뀌었습니다. 그 부분은 아직 AI가 해결하지 못했습니다.

다만, 스펙(spec)을 작성하는 것도 AI의 도움을 받고 있으며, 사내에서는 PM도 디자이너도 모두 Claude를 사용하고 있습니다.

"해결책은 아직 없다"라고 솔직하게 말해준 것이 오히려 가장 신뢰할 수 있는 답변이었습니다. 요구사항과 디자인이 병목(Bottleneck)이 되는 시대는 Anthropic 사내에서도 이미 시작된 듯합니다.

사실 이 테마는 조직론 세션인 「Running an AI-native engineering org」(Claude Code 팀의 엔지니어링 리더 강연)의 핵심 메시지 그 자체이기도 했습니다. 강연자는 "코딩은 더 이상 엔지니어링의 병목이 아니다. 그 전제를 바탕으로 만들어진 프로세스는 재검토가 필요하다"라고 말했습니다. 과거의 병목이었던 작업(코드 작성, 테스트, 리팩터링)의 부하가 급감한 대신, 새로운 병목은 **검증, 리뷰, 부서 간 협업, 보안과 같은 "코딩의 주변 영역"**으로 옮겨갔다는 정리입니다.

조직 측면의 변화도 구체적이었습니다:

• 설계 논의는 문서가 아니라 프로토타입과 PR(Pull Request)로 진행한다. "3가지 아키텍처 안을 화이트보드에서 논의하는 대신, 3개의 PR을 생성하여 직접 비교한다" — 역할의 경계가 허물어지고 있다. 디자이너가 코드를 커밋하고, PM이 프로토타입을 만든다. 커밋의 거의 100%가 Claude-assisted(Claude의 도움을 받은 상태)이다.
• 그리고 "오래된 프로세스를 없앨 명시적인 허가를 내준다" — 프로세스는 저절로 사라지지 않기 때문이다.

개인의 체감(업무가 설계와 요구사항 이해로 변화)과 조직으로서의 재설계(검증과 리뷰가 새로운 병목)를 동일한 현상으로서 양면에서 들을 수 있었던 것은, eval(평가)과 더불어 이날의 또 다른 큰 발견이었습니다.

금융 엔터프라이즈 실무자로서의 인사이트

마지막으로, 손보재팬(Sompo Japan)에서 실서비스 운영을 염두에 두고 AI 에이전트를 개발하고 있는 입장에서 얻은 인사이트를 정리합니다.

• 계획 주도(Plan-driven) + 검증 단계의 내재화를 철저히 할 것
  "plan에 검증 단계를 상세히 적어두면 몇 시간 동안 스스로 작동한다"는 에이전트 운영의 설계 지침으로서 가장 중요합니다. 수락 조건(Acceptance Criteria)이나 테스트를 나중에 추가하는 것이 아니라, plan의 필수 항목으로서 처음부터 써넣어야 합니다.
• eval set 구축을 앞당길 것
  자사 유스케이스의 실제 데이터로 eval을 만드는 작업은 지루하고 뒤로 미루기 쉽지만, "비밀스러운 기술은 없다, 직접 해야 한다"라고 본사 측에서 말한 이상 실행할 수밖에 없습니다. 이는 모델이 업데이트될 때마다 "품질이 향상되었는가"를 측정할 수 있는 토대가 됩니다.
• 비용 설계에 caching / compact / 라우팅을 처음부터 포함할 것
  특히 "탐색형 서브 에이전트는 Haiku를 사용한다"는 전략은 Claude Code 본체와 동일한 패턴이므로, 자신 있게 채택할 수 있습니다.
• 리뷰 대역폭(Review Bandwidth) 해소 수단으로 Fable 5를 검증할 것
  가격이 2배더라도, 5번 필요했던 리뷰가 1~2번으로 줄어든다면 총비용 측면에서 역전할 수 있습니다. 다만 엔터프라이즈 환경에서는 클라우드 프로바이더를 통해 모델을 이용하는 경우가 많으므로, 신규 모델 제공 지연(Lag) 여부는 주의 깊게 살펴봐야 합니다.

요약

• Fable 5 출시 당일이라는 최고의 타이밍에 1차 정보를 듬뿍 얻을 수 있었던 하루였습니다.
• 세션의 실천적 지식(effort의 3가지 토큰 분류, prompt hygiene, Routines)은 모두 내일부터 바로 적용할 수 있는 내용이었습니다.
• 그리고 만든 당사자와 직접 대화할 수 있는 기회는 무엇과도 바꿀 수 없습니다. 다음 행사가 열린다면, 그것만으로도 갈 가치가 충분합니다.

마지막으로, 질문에 친절하게 답해주신 Anthropic 관계자 여러분, 감사합니다.

전리품. 문어 인형(Clawd)이 귀엽다.

Discussion