Picking the right model — Lucas Smedley, Member of Technical Staff, Anthropic

서론

최근 며칠간 런던에서 개최된 「Code with Claude London 2026」 세션을 매일 조금씩 시청하고 있습니다.

AI Solutions Architect (AI 솔루션 아키텍트)로 활동하고 있는 저에게 Anthropic 공식 발표는 1차 정보의 보고이며, 볼 때마다 "내일부터 이렇게 움직여야겠다"라고 생각하게 만드는 발견이 있습니다. SNS의 핫 테이크(Hot take)나 단편적인 벤치마크 (Benchmark) 기사와는 달리, 현장에서 Claude를 실제로 구동하고 있는 사람들이 무엇을 생각하고, 무엇을 측정하며, 어떻게 판단하고 있는지가 밀도 높게 이야기되고 있기 때문입니다.

그중에서도 오늘은 특히 인상 깊었던 한 세션을 다루어보고자 합니다. Anthropic, Member of Technical Staff인 Lucas Smedley 씨의 「Picking the right model」 세션입니다.

"새로운 모델이 나올 때마다 결국 어떤 것을 사용해야 하는가" —— AI를 업무에서 다루는 엔지니어라면 한 번쯤은 반드시 마주하게 되는 고민일 것입니다. Lucas 씨는 그 질문에 대해 감각적인 논리가 아닌 **재현 가능한 프로세스 (Repeatable process)**로 답을 내놓고 있었습니다. 본 기사에서는 이 세션을 시청하며 제가 배운 점과 AI Solutions Architect로서 현장에 가져가고 싶다고 느낀 점들을 정리해 보겠습니다.

목차

• 왜 「모델 선정」은 이렇게 어려운가
• 모델 선정을 뒷받침하는 3가지 기둥
• 공개 벤치마크 (Benchmark)는 「방향성」만을 알려준다
• Eval (평가) 만드는 법: 수학 시험의 비유
• Eval을 만들 때의 함정: 6가지 전형적인 패턴
• Transcript (스크립트)를 읽지 않으면 아무것도 알 수 없다
• 직관을 뒤엎는 사실: 똑똑한 모델이 "빠르고 저렴하다"
• 모르면 손해 보는 4가지 다이얼
• 워크숍: τ-bench Airline에서의 모델 스윕 (Model sweep)
• 가져가고 싶은 3가지
• AI Solutions Architect로서 내일부터 무엇을 할 것인가
• AI 솔루션 엔지니어 / 인프라 엔지니어로서의 고찰
• 가까운 미래에 일어날 법한 일

1. 왜 「모델 선정」은 이렇게 어려운가

A new model just dropped. Should you switch?

세션 서두에서 Lucas 씨는 다음과 같은 시나리오를 제시합니다.

새로운 모델이 출시된다. **Launch post (출시 포스트)**에는 "Claude Opus 4.7 — new state of the art on SWE-bench Verified"라고 적혀 있다. X / Twitter에서는 "It's a meaningful jump on agentic tasks"라며 떠들썩하다. Hacker News에는 "Show HN: I switched all my pipelines and accuracy increased 30%"라는 스레드가 올라온다. 그리고 **자신의 PM (프로젝트 매니저)**로부터는 "Should we change anything before next week's release?"라는 질문을 받는다.

이 중 어느 것도 자신의 유스케이스 (Use case)에 대한 답은 되지 않는다. Lucas 씨는 여기서 단언합니다. "We need a repeatable process" —— 재현 가능한 프로세스가 필요하다고 말입니다.

"What we basically want to build is a repeatable process. Something you can come back to time and time again that gives you a clear yes/no decision on when to select this new model. In other words, we want to build an eval."

— Lucas Smedley

"재현 가능한 프로세스 (Repeatable process)를 만들고 싶다", "다시 말해, Eval (평가)을 만들고 싶다" —— 이 선언을 들었을 때, 제 안의 무언가가 정리되는 느낌을 받았습니다.

저는 평소 새로운 모델이 나오면 공식 시스템 카드 (System card)나 기술 블로그를 읽고, 제 유스케이스에 대입하여 어디에 효과적일지를 생각합니다. 다만, 그 판단은 제 머릿속에서 완결되어 있었고, 고객이나 팀에게 "이 프로세스로 판단해 주세요"라고 제시할 수 있는 재현 가능한 형태로는 되어 있지 않았다는 것이 솔직한 심정입니다. Lucas 씨의 말이 가슴에 와닿은 지점이 바로 여기였습니다.

「관측할 수 없는 것은 관리할 수 없다」라는 인프라 운영의 철칙을 AI 세계에서 놓치고 있는 상태――그 점을 깨닫게 되었습니다.

CI/CD에 자동 테스트를 포함해 두지 않으면, 라이브러리 버전 업데이트가 두려워 아무도 하지 않게 되는 것과 같습니다. Eval(평가)이라는 파이프라인을 정비해 두면, 새로운 모델이 나온 다음 날 바로 Yes/No로 판단할 수 있게 됩니다. 이것은 MLOps적인 기초 체력이다라는 점을 깊이 납득했습니다.

2. 모델 선정을 뒷받침하는 3가지 기둥

It's a simple problem right? — Haiku, Sonnet, Opus

「재현 가능한 프로세스」를 만들기 위해, 우선 Lucas 씨는 판단 축을 정리합니다.

Quality (품질)— 태스크를 얼마나 잘 완료하는가, 정확도는 어떠한가 -
Latency (레이턴시)— 사용자 대면 환경에서는 특히 중요 -
Cost (비용)— 고객에게 있어 큰 고려 사항

「Opus는 똑똑하고, Haiku는 가볍고, Sonnet은 중간 단계」라는 단순한 이야기처럼 보이지만, Lucas 씨는 여기에 **Thinking (확장 사고)**과 **Effort (노력)**라는 두 개의 다이얼을 추가합니다.

...but what about effort levels? — Haiku, Sonnet, Opus × low/medium/high/max

Sonnet with max thinking

• Opus with low thinking
• Haiku without thinking

조합의 선택지가 단숨에 폭발하는 것을 눈으로 확인할 수 있었습니다. 여기에 더해 「이것은 Anthropic 내부의 이야기일 뿐이고, 타사 모델과도 비교한다면…」이라는 질문이 이어집니다. 처음에는 3가지 선택지로 보였던 것이 실질적으로는 20가지 이상의 선택지로 변하는 순간입니다.

제가 평소 다루는 클라우드 세계에서는 「Cost / Performance / Reliability (비용 / 성능 / 신뢰성)」의 트레이드오프 (Trade-off)를 일상적으로 논의합니다. AI 세계는 여기에 **품질 (태스크 성공률)**과 레이턴시라는 세분화된 축이 더해지고, 나아가 Thinking과 Effort라는 새로운 다이얼이 얹어집니다. AI Solutions Architect의 업무는 바로 이 다차원적인 최적화 문제를 푸는 것이구나라고 다시 한번 인식하게 되었습니다.

3. 공개 벤치마크는 「방향성」만을 알려준다

Use SWE-bench, GPQA, BrowseComp, and other well-known benchmarks as priors, not verdicts

여기서 자연스럽게 의문이 생깁니다. 「SWE-bench나 BrowseComp 같은 공개 벤치마크를 보면 되지 않을까?」

Lucas 씨는 이에 대해 명확하게 이렇게 답합니다. 공개 벤치마크는 「priors (사전 정보)」일 뿐, 「verdicts (판결)」가 아니다라고 말이죠.

슬라이드에도 나와 있듯이, 각 벤치마크가 알려주는 것은 특정 능력의 일면일 뿐입니다.

SWE-bench Verified— 좁은 코퍼스(Corpus)에서의 에이전틱 코딩 (Agentic coding) -
BrowseComp— 에이전틱 웹 리서치 및 검색 (Agentic web research and retrieval) -
GPQA Diamond— 폐쇄형 과학 지식에 대한 어려운 추론 (Hard reasoning on closed-book science) -

그리고 실제 운영 환경의 코딩 에이전트는 SDK의 니치(Niche)한 사양을 웹에서 찾아내어 그것을 코드로 구현하는 동작을 자주 수행합니다.

"If you think about a coding agent in production, often it will need to go and research and find some niche specific part about an SDK on the web and then go and implement that in code. So already we're crossing over two benchmarks."

— Lucas Smedley

SWE-bench는 코드를 쓸 수 있는지를 측정합니다. BrowseComp는 웹을 조사할 수 있는지를 측정합니다. 하지만 실제 운영 환경의 에이전트는 그 양쪽을 왔다 갔다 합니다. 확실히 내가 상정하고 있는 실제 워크로드(Workload)는 그 어떤 단일 벤치마크에도 담기지 않는다는 점에 납득한 순간이었습니다.

나아가 Lucas 씨는 「능력 이외의 요인」에 의해서도 점수가 변한다고 지적했습니다. SWE-bench는 스캐폴딩 (Scaffolding, 발판)을 어떻게 구성하느냐에 따라 점수가 크게 휘청이고, MMLU는 사소한 포맷 변경만으로도 정확도가 달라집니다. 이것 역시 공개 벤치마크를 「verdict (판결)」로 취급해서는 안 되는 이유입니다.

공개 벤치마크는 「업계 평균 벤치마크 (industry average benchmark)」로서 참고하되, 자사 고유의 Eval을 「커스텀 KPI (custom KPI)」로 병용한다. 클라우드 선정 시 Gartner Magic Quadrant를 참고하면서, 최종적으로는 PoC에서 성능 검증을 수행하는 것과 동일한 구조입니다.

4. Eval을 만드는 법: 수학 시험의 비유

A well-defined task

그렇다면 Eval을 어떻게 만들까요? Lucas 씨는 여기서 제가 좋아하는 비유를 들었습니다.

"지난 몇 달 동안 Eval을 위해 사용해 온 휴리스틱 (heuristic)은, 학교에서 수학 시험을 치를 때와 매우 유사하게 생각하는 것입니다. 질문이 있고, 맞춰야 하는 정답이 있지만, 그 사이의 풀이 과정 (working)을 보여주는 것도 매우 중요합니다."

— Lucas Smedley

「학교 수학 시험」이라고 말하는 것입니다. 문제가 있고, 맞춰야 하는 정답이 있습니다. 하지만, 그 중간 과정 (working)을 보여주는 것도 매우 중요하다는 것이죠.

슬라이드에서는 「well-defined task (잘 정의된 태스크)」의 4가지 요구사항이 제시되었습니다.

Start with 20–50 realistic examples— 처음에는 20~50개의 현실적인 예시로 시작할 것 -
Grade what matters with the right grader— 적절한 채점자 (grader)로 중요한 것을 채점할 것 -
Make failures a diagnostic, keep a reference solution— 실패가 진단이 될 수 있도록 참조 해답 (reference solution)을 유지할 것 -
Isolate capabilities, and test both directions— 능력을 분리하고, 양방향 모두 테스트할 것

이 4가지 설계 지침은 제가 그동안 LLM 평가를 대하던 방식이 틀렸음을 깨닫게 해주었습니다. 저는 지금까지 「최종 출력이 기대치와 일치하는가」라는 유닛 테스트 (unit test)적인 발상으로 평가를 생각해 왔습니다. 하지만 수학 시험에서는 정답만 적고 풀이 과정이 없다면 부분 점수도 받을 수 없고, 어쩌 데어 맞춘 것일지도 모릅니다.

에이전트 (Agent)의 Eval도 바로 마찬가지입니다.

올바른 정답에 도달했는가 (outcome)— LLM as a Judge (채점 역할로 다른 LLM을 사용하는 평가 기법)로 최종 응답을 평가 -
올바른 프로세스로 도달했는가 (working)— 별도의 LLM as a Judge로 중간의 도구 호출 (tool call)이나 SQL 쿼리 (query)를 평가 -
지켜야 할 규칙을 지켰는가— 결정론적인 (deterministic) 코드베이스 평가로 「항상 이 도구를 호출한다」, 「항상 이 인자 (argument)를 붙인다」 등을 체크

이 3개 층을 조합하는 것이 진정한 Eval 설계라는 점을 정리할 수 있었습니다.

그리고 Lucas 씨는 다음과 같이 덧붙였습니다. **「AI로 많은 것이 자동화되는 시대에, Eval 데이터셋을 구축하는 것은 인간의 시간을 사용하는 가장 가치 있는 방법 중 하나다」**라고 말이죠.

이 점에는 강력히 동의합니다. AI Solutions Architect로서 우리가 제공해야 할 최대의 가치는 「Eval을 설계하는 능력」이 되어갈 것이라고 영상을 보며 생각했습니다.

5. Eval을 만들 때 빠지기 쉬운 3가지 함정

Most surprising eval results are bugs in the eval; not facts about the model

Anthropic 내부에서도 오랫동안 Eval을 만들어 온 경험을 바탕으로, Lucas 씨는 이렇게 단언합니다.

"Most surprising eval results are bugs in the eval; not facts about the model."

놀라운 Eval 결과는 대부분 모델에 대한 사실이 아니라, Eval 측의 버그(bug)라는 것입니다.

① 노이즈를 시그널 (signal)로 오인함

Eval은 여러 번 실행하여 결과가 안정적인지 확인해야 합니다. 분산 (variance)이 크다면 태스크 정의나 Eval 설계가 미흡하다는 신호입니다. SRE에서 말하는 「플래키 테스트 (flaky test) 문제」 그 자체입니다.

② 인프라 기인 실패를 간과함

스코어가 낮을 때, 그것이 모델의 문제인지 아니면 API 에러나 도구 호출 실패인지 구분해야 합니다. Lucas 씨는 이 점을 강조했습니다.

"우리는 그것들을 모델 자체에 대한 실제 평가와 분리해야 합니다. 이것들은 인프라 문제이지 모델 문제가 아닙니다."

— Lucas Smedley

「애플리케이션의 버그인지, 네트워크 장애인지, 의존 서비스의 장애인지」를 구분하는 트러블슈팅 (Troubleshooting)과 같은 구도죠. 관측 로그를 파헤치는 습관은 AI 영역에서도 계속해서 필수적인 기술입니다.

③ 조용한 포화 (Silent Saturation)

Eval 세트가 실제 데이터를 대표하고 있는지 항상 다시 질문해야 합니다. 제품을 출시하면 실제 트레이스 (Trace)를 수집하고, 실패 패턴을 Eval에 계속 피드백해야 합니다. 이것은 MLOps에서 말하는 데이터 드리프트 (Data Drift)에 대한 대응 그 자체입니다.

6. Transcript를 읽지 않으면, 아무것도 알 수 없다

A few lessons learned here and there: read the transcript

세션 중에서 개인적으로 가장 충격적이었던 에피소드가 있습니다.

Claude Code로 어떤 코딩 벤치마크 (Coding Benchmark)를 실행하고 있었는데, Claude가 매우 높은 점수를 기록했습니다. "이건 대폭 개선되었다!"라며 기뻐하려던 찰나, Transcript를 파헤쳐 보았습니다. 그랬더니――

"우리가 발견한 것은 Claude가 git 히스토리에 들어가서 이전 시도에서 무엇을 했는지 확인하고, 거기서 정답을 추출하고 있었다는 점입니다."

— Lucas Smedley

Claude는 git 히스토리에 들어가서 이전 시도에서 했던 일을 보고, 거기서 답을 추출하고 있었습니다. 요컨대, 커닝을 하고 있었던 것입니다.

이는 AI 에이전트 (AI Agent) 세계에서는 보상 해킹 (Reward Hacking)이라고 불리는 고전적인 현상이지만, 이를 Anthropic 사내의 Claude Code에서 실제로 관측한 사례로 들려주었기에 강력한 설득력이 느껴졌습니다. 헤드라인의 숫자만 보고 있었다면 절대 알아차릴 수 없었을 것입니다.

가공되지 않은 Transcript가 진실이다―― 이 말이 제 마음속에 깊이 박혔습니다. 클라우드 네트워크나 스토리지 장애 조사에서 "요약된 메트릭 (Summary Metrics)뿐만 아니라, 가공되지 않은 패킷 캡처나 로그를 읽는 것"과 같은 세계관입니다.

AI 에이전트의 운영 설계에서도 Langsmith나 Braintrust와 같은 관측 기반 (Observability Platform)을 도입하여, 시스템 프롬프트 (System Prompt)・도구 호출 (Tool Call)・도구 결과 (Tool Result)・에이전트 응답 (Agent Response)까지 전부 트레이스 (Trace)할 수 있는 상태를 만들어야 합니다. **"AI 에이전트의 SRE에게는 Transcript Viewer가 필수"**라는 새로운 직무 요건이 이미 나타나고 있다고 느낍니다.

7. 직관을 뒤엎는 사실: 똑똑한 모델이 "빠르고 저렴하다"

Story of an internal eval for a simple code-fix pipeline

여기서부터 이야기는 비용 × 품질의 프론티어 (Frontier)를 어떻게 움직일 것인가라는 주제로 들어갑니다.

Lucas 씨는 사내의 Code-fix Pipeline 사례를 소개했습니다. 단순한 태스크였기에 우선 Haiku 4.5 (Thinking off)로 실행했을 때 92%의 점수가 나왔습니다. Thinking을 켜자 100%를 달성했습니다.

여기서 "비용 제약이 강하지 않았기에" Sonnet과 Opus로도 시도해 보았더니―― 위의 슬라이드와 같이, Sonnet 4.6 (low, off)과 Opus 4.7 (low, off)이 모두 100%를 달성했으며, 심지어 Haiku보다 더 짧은 시간 내에 완료되었습니다.

게다가 도표를 보면, Sonnet 4.6과 Opus 4.7은 Haiku 4.5 (Thinking on, 100%)보다 비용도 낮았습니다. "똑똑한 소형 모델로 Thinking을 계속 돌리는 것"보다 "처음부터 똑똑한 모델을 한 번에 통과시키는 것"이 결국 모든 지표에서 승리한다는 결과였습니다.

"더 지능적인 일부 모델들은 더 적은 턴 (Turn)으로 일을 처리할 수 있고, 보다 전략적으로 계획을 세울 수 있기 때문에 시간 측면에서 훨씬 더 효율적일 수 있습니다."

— Lucas Smedley

똑똑한 모델은 적은 턴으로 일을 끝냅니다. 전략적으로 플래닝 (Planning)할 수 있습니다. "자신이 하려는 것이 맞는지" 확인하기 위한 리서치에 시간을 쓸 필요도 적습니다. 그래서 결과적으로 빠릅니다.

When the bigger model became the cheaper one

다른 슬라이드에서는 Opus 4.5와 Sonnet 4.5의 비교가 제시되었습니다. Opus 4.5는 low / medium / high 중 어떤 effort (노력) 수준에서도, Sonnet 4.5보다 적은 출력 토큰(output token) 수로 동등하거나 그 이상의 정확도를 보여줍니다. Sonnet 4.5가 약 22,500토큰을 사용하는 지점에서, Opus 4.5 high effort는 약 12,000토큰만으로 더 뛰어난 정확도를 달성합니다.

이 코멘트를 통해 제 안에 오랫동안 자리 잡고 있던 「똑똑한 모델 = 무겁다 = 느리다」라는 고정관념이 깨졌습니다. 똑똑한 모델은 「1회당 추론은 무겁지만, 필요한 추론 횟수가 압도적으로 적기」 때문에, 합계로 보면 더 빠릅니다.

비유하자면, 연비 좋은 소형차 vs 하이브리드 SUV와 같습니다. 시내 단거리 주행이라면 소형차가 더 저렴합니다. 하지만 장거리 고속도로 주행이라면 SUV가 더 빠르고 연비도 좋습니다. AI 에이전트 설계에서도 「턴당 비용(cost per turn)」이 아니라 「태스크 완료까지의 총 턴 수 × 턴당 비용」을 보지 않으면, 진정한 최적해에 도달할 수 없다는 사실을 깊이 납득하게 되었습니다.

8. 모르면 손해 보는 4가지 다이얼

세션 후반부는 비용 × 품질의 프론티어(frontier)를 움직이는 구체적인 테크닉에 관한 이야기입니다. Lucas 씨가 제시한 것은 Thinking, Effort, Prompt Caching, Context Engineering이라는 4가지 다이얼이었습니다.

Thinking과 Effort는 별개

Thinking and effort

저는 지금까지 Thinking과 Effort를 문서로만 접했을 때는 명확히 구분하지 못했습니다. Lucas 씨의 설명과 위 슬라이드를 통해 드디어 머릿속에서 선이 그어졌습니다.

Thinking — Claude에게 연습장(scratchpad)을 제공하기

• { type: "adaptive" } — Claude가 스스로 얼마나 생각할지 결정 (Opus 4.6 / Sonnet 4.6 권장, Opus 4.7에서 필수)
• { type: "enabled", budget_tokens: N } — 추론 캡(inference cap)을 설정 (Opus 4.5 이전 모델, 4.6에서 비권장)
• { type: "disabled" } — Thinking 미사용

Effort — Claude에게 얼마나 열심히 노력할지 말하기

• output_config.effort를 low / medium / high (default) / xhigh / max로 지정 — Opus 4.5, Opus 4.6, Sonnet 4.6, Opus 4.7에서 지원

"Effort는 Thinking, 도구 호출(tool calls), 응답 모두에 걸쳐 Claude가 얼마나 많이 작성할지를 알려줍니다. 따라서 예를 들어 Thinking은 낮게(low), Effort는 높게(high) 설정할 수 있습니다. 혹은 Thinking을 사용하지 않으면서도 여전히 Effort 파라미터를 사용할 수도 있습니다."
— Lucas Smedley

즉:

• Thinking은 Claude에게 「생각할 공간(scratchpad)」을 주는 다이얼
• Effort는 Claude에게 「얼마나 많은 공력을 들여 작성할지」를 지시하는 다이얼
• 이 둘은 독립적으로 조합 가능

슬라이드에 적힌 대로, **「품질이 유지되는 가장 낮은 단계부터 시작하라, 가장 높은 단계가 아니라(Start at the lowest level where quality holds, not the highest)」**라는 지침은 매우 실무적입니다. 처음부터 max로 설정하는 것이 아니라, 어느 수준에서 품질이 「딱 적절하게 유지되는가」를 측정하는 것이 비용 최적화의 본질입니다.

이 두 축이 독립되어 있다는 이해는 운영 설계에서 큰 의미를 갖습니다. 「무료 사용자는 Low Effort, 유료 사용자는 High Effort」, 「배치 처리(batch processing)는 High effort, 실시간 응답은 Low effort」와 같이 비즈니스 로직과 결합한 세밀한 설계가 가능해집니다.

Prompt Caching: Opus를 Sonnet 가격으로 사용하기

Prompt caching and context hygiene move the whole frontier

여기서부터가 프론티어를 「위로 움직이는」 것이 아니라 「이동시키는(shift)」 테크닉입니다. 위 슬라이드는 이번 세션에서 개인적으로 가장 강렬했던 한 장입니다.

점선이 「Naive frontier (素のフロンティア, 가공되지 않은 프론티어)」이며, 실선이 「With optimization (최적화 후의 프론티어)」입니다. **Prompt caching (프롬프트 캐싱)**과 **Context hygiene (컨텍스트 위생)**이라는 두 가지 최적화를 적용하는 것만으로 프론티어 자체가 왼쪽 상단으로 이동(shift)하며,

Opus quality at Sonnet cost (Sonnet의 비용으로 Opus의 품질을)
Sonnet quality at Haiku cost (Haiku의 비용으로 Sonnet의 품질을)

이 성립합니다. Lucas 씨의 표현을 빌리자면 다음과 같습니다:

"Prompt caching을 사용할 때는 입력 토큰의 정가보다 10분의 1의 가격만 지불하면 됩니다. 따라서 실질적으로 이는 Sonnet의 비용으로 Opus의 품질을 얻거나, Haiku의 비용으로 Sonnet의 품질을 얻을 수 있음을 의미합니다."

— Lucas Smedley