이 한 장 을 오래 들여다봤다. 위 는 모델 별 가격표, 아래 는 Agents’ Last Exam — 비용 대 점수 산점도다. “어느 모델 이 제일 좋냐” 라는 질문 에 답 하는 그림 이 아니다. “어느 모델 을, 어떤 일 에, 얼마 에 쓸 것 인가” 를 묻는 그림 이다. 백엔드 엔지니어 로서 이걸 어떻게 읽는지 정리 한다.

LLM 가격표 + Agents' Last Exam 비용-점수 산점도

0. 먼저 — 이건 순위표 가 아니라 프론티어 다

가격표 를 보자 (1M 토큰 당 입력/출력):

모델 입력 출력
Claude Fable 5 $10 $50
GPT-5.6 Sol $5 $30
Sol Fast (Cerebras) $12.5 $75
GPT-5.6 Terra $2.50 $15
GPT-5.6 Luna $1 $6

(참고: Claude 쪽 은 Opus 4.8 이 $5/$25, Sonnet 4.6 이 $3/$15, Haiku 4.5 가 $1/$5 로 같은 계단 을 이룬다.)

핵심 은 — 가격 이 10배 차이 난다 는 것. Luna($1) 와 Fable 5($10) 사이. 그런데 아래 산점도 를 보면, 점수(Score) 는 10배 차이 가 안 난다. 30%대 에서 50%대 로, 기껏 1.5~2배. 즉 비용 은 선형 이 아니고, 점수 는 로그 에 가깝다. 마지막 몇 % 의 지능 이 가장 비싸다.

이건 순위표 가 아니라 파레토 프론티어 다. “제일 좋은 모델” 은 없다. “이 예산 에서 최선” 인 모델 이 있을 뿐.

1. 왜 비용 축 인가 — 에이전트 는 한 번 안 부른다

벤치마크 이름 이 왜 하필 Agents’ Last Exam 이고, 왜 x축 이 비용 일까.

에이전트 는 한 요청 에 모델 을 수십~수백 번 부른다. 도구 호출, 재시도, 서브에이전트, 반성 루프… 챗 한 번 이면 토큰 몇 천 이지만, 에이전트 한 작업 이면 수백만 토큰 이다. 그래서 단가 차이 가 그대로 곱해진다. Fable 5 로 도는 에이전트 와 Luna 로 도는 에이전트 는, 같은 작업 에 비용 이 10배 벌어진다.

그러니 에이전트 벤치마크 를 “점수” 로만 보면 안 된다. “점수/달러” 로 봐야 한다. 이 산점도 가 정확히 그걸 그린다 — 오른쪽 위 로 갈수록 비싸고 똑똑하지만, 진짜 봐야 할 건 각 점 의 기울기(가성비) 다.

2. 그래서 나는 티어링 한다 (인스턴스 타입 고르듯)

이건 낯선 문제 가 아니다. 백엔드 에서 인스턴스 타입 고르는 것 과 똑같다. 모든 워크로드 를 최상위 스펙 에 올리지 않는다 — 부하 와 중요도 에 맞춰 티어 를 나눈다. 모델 도 그렇게:

작업 모델 티어 이유
분류·요약·라우팅·대량 배치 최저가(Luna/Haiku 급) 쉬운 일 에 비싼 두뇌 낭비 금지
일반 코딩·대화·대부분 중간(Terra/Sonnet 급) 가성비 스위트스팟
최난도·장기 에이전트·정합성 결정 최상위(Fable 5/Opus 급) 틀리면 비싼 일 에만

내가 멀티 에이전트 글 에서 “서브에이전트 는 싼 모델 로, 오케스트레이터 는 좋은 모델 로” 라고 쓴 게 이거다. 한 작업 안 에서도 모델 을 섞는다. 라우팅 은 Haiku 급, 최종 판단 은 Opus 급. 비용 은 아래 티어 가, 품질 은 위 티어 가 책임 진다.

3. 속도 는 세 번째 축 이다 — Sol Fast(Cerebras)

표 에서 눈 에 띄는 건 Sol Fast (Cerebras) — 같은 Sol 인데 $5→$12.5 로 더 비싸다. 더 똑똑 해서 가 아니라 더 빠르기 때문 이다. Cerebras 웨이퍼 칩 으로 토큰 을 훨씬 빨리 뽑는다.

즉 축 이 하나 더 있다 — 지능 × 비용 × 속도. 속도 는 돈 주고 사는 것 이다. (Claude 의 Fast Mode 도 같은 발상 — 같은 모델, 2.5배 속도, 프리미엄 가격.)

언제 속도 를 사나? 사람 이 기다리는 곳. 대화형 코딩, 실시간 응답. 배치·야간 작업 은 느려도 되니 안 산다. 설계 세 축 에서 지연-처리량 을 저울질 하던 것 과 똑같은 판단 이, 모델 선택 에서도 나온다.

4. 프론티어 는 움직인다 — 한 모델 과 결혼 하지 마라

6개월 전 이 표 는 완전히 달랐고, 6개월 뒤 도 다를 것 이다. GPT-5.6 의 Sol/Terra/Luna 삼단 구성, Gemini 3.1, Cerebras… 프론티어 는 계속 재편 된다.

그래서 실무 에서 중요한 건 “지금 1등 이 누구냐” 가 아니라 “모델 을 갈아끼울 수 있게 짜뒀느냐” 다:

  • 모델 을 설정값(config) 으로 빼둔다. 코드 에 claude-opus-4-8 을 박지 않는다.
  • 어댑터 뒤 에 둔다 — PSA/헥사고날 처럼, 모델 은 갈아끼우는 부품.
  • 프롬프트·평가셋 을 모델 독립적 으로. 새 모델 나오면 같은 eval 을 돌려 비교 한다.

모델 은 상품(commodity) 이 되어가고, 프론티어 위 에선 다들 비슷 해진다. 차이 를 만드는 건 모델 이 아니라, 그 모델 을 태운 하네스 — 게이트·검증·기억·조합. 평범한 모델 도 좋은 하네스 위 에선 비범 하게 굴러가고, 최고 모델 도 하네스 없이는 데모 에 그친다.

5. 실전 체크리스트 — 모델 고를 때 내가 묻는 것

  1. 이 작업, 틀리면 얼마나 비싼가? — 싸면 싼 모델, 비싸면 좋은 모델. (실계좌 매매 판단 ≠ 로그 분류)
  2. 호출 횟수 가 몇 번 곱해지나? — 에이전트/루프 면 단가 가 곱해진다. 티어 를 낮춰라.
  3. 사람 이 기다리나? — 그럼 속도 를 사고, 아니면 아끼라.
  4. 가장 싼 모델 로 먼저 돌려봤나? — 되면 그걸로 끝. 안 되는 것만 위 티어 로 승격.
  5. 모델 을 갈아끼울 수 있나? — config + 어댑터 + eval. 프론티어 는 움직인다.

맺으며

이 그림 이 주는 진짜 교훈 은 “Fable 5 가 제일 세다” 가 아니다. “모델 선택 은 성능 문제 가 아니라 비용-품질-속도 를 저울질 하는 자원 계획 문제” 라는 것. 인스턴스 타입 고르듯, 저장소 티어 나누듯 — 익숙한 엔지니어링 판단 이 여기서도 반복 된다.

가장 똑똑한 모델 을 쓰는 게 아니라, 각 일 에 맞는 모델 을 쓰는 것 이 잘 쓰는 것 이다. 그리고 어떤 모델 이 오든 흔들리지 않으려면, 결국 모델 밖 의 구조 — 티어링, 어댑터, eval, 하네스 — 를 잘 짜두는 수밖에 없다.

모델 은 갈아끼우는 부품 이고, 오래 남는 건 그걸 끼우는 골격 이다.