“GPT 써요? Claude요? Gemini요?”
같은 질문을 주변 개발자에게 던져 보면 답이 제각각이다.
“저는 GPT요. 도구 통합 생태계가 제일 넓어서요.”
“Claude요. 코딩 에이전트는 이게 제일 안정적이에요.”
“Gemini요. 1M 컨텍스트가 사기예요.”
“Gemma 4 31B 같은 오픈웨이트 라인이요. 사내 데이터라 외부 API로 못 보내거든요.”
다 맞는 말이다. 상황이 다를 뿐이다. 그런데 라인업 비교만 가지고 글을 쓰면 두 달 만에 낡는다. 매주 새 모델이 나오고, 가격표는 한 달 만에 바뀌고, 어제 1등 벤치마크가 오늘 3등으로 내려간다.
그래서 이 글은 ‘지금 라인업 중 누가 1등인가’를 정리하지 않는다. 대신 ‘어떤 라인업이 와도 같은 방식으로 결정하게 해주는 기준’을 정리한다. AI Decoded 시리즈의 외전이고, 1년 뒤에도 같은 틀로 의사결정할 수 있는 evergreen 프레임을 목표로 한다.
결론 먼저: 먼저 탈락 조건, 그다음 가중치
‘한 줄 요약: AI 모델 선택은 두 단계로 나눈다. 1) 절대 넘기면 안 되는 Hard Gate, 2) 통과한 모델끼리 9가지 기준 가중치 점수.’
1단계 — Hard Gate: 통과 못 하면 후보 자체에서 빠짐
| 탈락 조건 | 질문 |
|---|---|
| 데이터 정책 | 우리 데이터가 모델 학습에 쓰이면 안 되는가? |
| 보존 기간 | 요청·응답 로그가 일정 기간 이상 보존되면 안 되는가? |
| 리전 | EU·한국·특정 클라우드 리전 안에서 처리돼야 하는가? |
| 폐쇄망 | 외부 API 호출 자체가 불가능한가? |
| 라이선스 | 오픈웨이트 모델을 상업적으로 사용할 수 있는가? |
| 운영 SLA | 장애 시 대체 모델·fallback을 구성할 수 있는가? |
이 조건을 통과하지 못하면 ‘성능이 1등이라도 후보에서 제외’다. 아무리 좋은 모델이라도 사내 정책이 막으면 못 쓴다.
2단계 — Weighted Score: 통과한 모델끼리 점수표
| # | 기준 | 무엇을 보나 |
|---|---|---|
| 1 | 작업 성격 | 대화/코딩/추론/멀티모달/RAG/에이전트 — 어디에 강한가 |
| 2 | 컨텍스트 윈도우 | 한 번에 넣을 수 있는 토큰. 긴 문서·코드베이스에 직결 |
| 3 | 도구 호출 안정성 | function calling이 망가지지 않고 인자 스키마를 지키는가 |
| 4 | 구조화 출력 | JSON 모드·schema 강제·스트리밍 정확도 |
| 5 | 가격 구조 | 입력·캐시·출력·reasoning·도구·멀티모달 단가 |
| 6 | Latency | TTFT(첫 토큰까지) + throughput |
| 7 | 데이터 정책·컴플라이언스 | (Hard Gate 통과 후) 보존·감사·계약 디테일 |
| 8 | 로컬 가능 여부 | 오픈웨이트 라인 존재. 폐쇄망 옵션 |
| 9 | 운영 안정성·언어 성능 | rate limit·가용성·alias 정책·한국어 |
잠깐 — 벤치마크 점수는 왜 답이 아닌가
‘MMLU, HumanEval, GPQA, AIME, LiveCodeBench…’ 모델 비교를 보면 늘 등장하는 점수표다. 매번 1점이라도 더 높은 모델이 발표되고, 그 모델이 다음 달엔 추월당한다.
문제는 세 가지다.
첫째, ‘학습 누출(data contamination)’. 공개된 벤치마크가 학습 데이터에 섞여 있을 수 있어서 점수가 부풀려질 수 있다. 둘째, ‘평가 분포가 내 작업과 다르다.’ MMLU 점수는 광범위한 지식·문제풀이 능력을 보는 데는 유용하지만, 내 업무가 사내 위키 RAG인지·장기 코딩 에이전트인지·한국어 고객 상담인지까지 직접 말해주지는 않는다. 셋째, ‘벤치마크 최적화(eval gaming).’ 모델 회사들도 평가 점수를 올리려고 학습·튜닝을 그쪽에 맞춘다.
그래서 벤치마크는 ‘대략의 체급’을 보는 데까지만 쓰고, 마지막 결정은 항상 ‘내 작업으로 직접 A/B 테스트’다. (시리즈 7편 ‘평가와 하네스’ 참고.)
9가지 기준 자세히
1. 작업 성격 — 어디에 쓰는 모델인가
‘한 줄 요약: 모델은 같은 IQ가 아니다. 코딩·추론·멀티모달·도구 호출·RAG는 각자 강점이 다르다.’
같은 frontier 모델이라도 어떤 자리에서는 1등, 어떤 자리에서는 3등이다. 작업 성격을 먼저 분류해야 한다.
| 작업 결 | 봐야 할 강점 |
|---|---|
| 일반 대화·요약·번역 | 대화 자연스러움, 길이 제어, 다국어 |
| 코딩(자동완성/리팩토링) | 코드 이해, diff 정확도, IDE 통합 |
| 코딩 에이전트(터미널·파일 조작) | tool_use 안정성, 긴 루프, 자기 수정 |
| 추론(수학·복잡 분석) | reasoning 모드, 단계적 문제 해결, 검산 능력, 긴 분석 일관성 |
| 멀티모달(이미지·영상·오디오) | 입력 모달리티 폭, 결과 정밀도 |
| RAG | 긴 컨텍스트, 인용 정확도, ‘모르겠다’ 거부 능력 |
| 에이전트(자율 실행) | 도구 호출 + 멀티턴 + 안전 정책 |
이 결을 먼저 잡으면 9개 기준의 가중치가 자동으로 좁혀진다.
2. 컨텍스트 윈도우 — 한 번에 얼마나 넣을 수 있나
‘한 줄 요약: 긴 문서·코드베이스를 다루면 결정적. 다만 큰 게 항상 답은 아니고, RAG와 짝으로 본다.’
2026년 4월 기준 주요 frontier API들은 수십만~100만 토큰급 컨텍스트를 제공한다. 다만 컨텍스트 윈도우는 모델·상품·API 경로마다 다르므로, 최종 선택 전에는 반드시 해당 모델의 공식 문서를 확인해야 한다.
봐야 할 포인트:
- ‘실효 컨텍스트’: 광고 컨텍스트와 ‘실제로 멀리 있는 토큰까지 정확히 참조하는가’는 다르다. needle-in-a-haystack 류 평가로 측정.
- ‘입력 vs 출력 비대칭’: 입력 컨텍스트가 1M이라고 해서 출력도 1M인 것은 아니다. 대부분의 모델은 입력과 최대 출력 토큰이 비대칭이다. 긴 답을 생성해야 한다면 입력만 보고 안심하면 안 된다.
- ‘비용’: 큰 컨텍스트는 비싸다. ‘긴 컨텍스트는 RAG의 대체재가 아니라 보완재’다. 무작정 큰 컨텍스트에 다 넣는 것보다 ‘검색·필터링·요약으로 좁힌 뒤 필요한 부분만 넣는’ 편이 비용·정확도 모두 유리한 경우가 많다.
작은 챗봇에는 가중치 1, 코드베이스 분석에는 가중치 5.
3. 도구 호출 안정성 — function calling이 망가지지 않는가
‘한 줄 요약: 에이전트 시나리오라면 모델 IQ보다 이게 더 중요할 수 있다. 느낌이 아니라 숫자로 본다.’
도구 호출은 ‘겉으로는 다 지원’한다. 차이는 안정성에서 난다.
- ‘인자 스키마 준수’: JSON 인자에 필수 필드가 빠지거나 타입을 어기는 빈도.
- ‘도구 선택 정확도’: 여러 도구 중에서 진짜 필요한 도구를 부르는가.
- ‘루프 안정성’: 도구 호출 → 결과 → 다음 호출의 멀티턴 흐름에서 망가지지 않는가.
- ‘parallel tool calls’: 한 번에 여러 도구를 호출할 수 있는가.
도구 호출 안정성은 느낌으로 판단하지 말고 숫자로 본다.
| 측정 항목 | 의미 |
|---|---|
| schema validation 실패율 | JSON 인자가 스키마를 못 지키는 비율 |
| 잘못된 도구 선택률 | 의도와 다른 도구를 호출하는 비율 |
| tool call retry 횟수 | 한 작업당 평균 재시도 |
| tool loop 중단률 | 멀티턴 루프가 중간에 끊기는 비율 |
| 사람 승인 없이 실행되면 안 되는 도구 호출 비율 | 위험 도구의 무단 호출 |
에이전트 서비스라면 이 지표들이 모델 벤치마크보다 더 중요할 수 있다.
4. 구조화 출력 — JSON 모드는 얼마나 단단한가
‘한 줄 요약: JSON mode와 JSON Schema 강제는 다르다. 자유 텍스트가 아니라 “스키마를 지키는 응답”이 필요한 자리에 직결.’
- ‘JSON mode’: ‘유효한 JSON’을 만들 가능성을 높이는 기능. 정확한 schema 준수까지는 보장하지 않는다.
- ‘JSON Schema 강제 (Structured Outputs 등)’: 정해진 필드·타입·enum을 지키게 하는 기능. 컴파일러처럼 강제.
이 둘은 다르다. ‘JSON으로만 받으면 충분’한 자리에는 JSON mode, ‘스키마를 어기면 파이프라인이 깨지는’ 자리에는 schema 강제.
추가로 봐야 할 것:
- ‘실패 모드’: 스키마를 못 지킬 때 빈 JSON·부분 JSON·예외 중 무엇을 반환하는가.
- ‘스트리밍 시 정확도’: 토큰 스트리밍 중에도 JSON이 깨지지 않는가.
API 응답을 그대로 다른 시스템으로 흘려보내는 자리(파이프라인, 배치 분석)에서는 가중치가 높다.
5. 가격 구조 — 단가 표만 보지 말 것
‘한 줄 요약: 토큰 단가표만 보고 예산을 잡으면 거의 항상 빗나간다. 토큰 카테고리별 과금으로 본다.’
API 비용은 단순 곱셈이 아니다. 대략 이렇게 나눠서 본다.
- 일반 입력 토큰
- 캐시 hit/read 입력 토큰 (대개 크게 할인)
- 출력 토큰
- reasoning/effort로 늘어난 출력 또는 내부 토큰
- batch 처리 토큰 (대개 50% 수준 할인)
- 도구 호출 비용
- 이미지/오디오/영상 입력 비용
- 리전·데이터 레지던시·장문 컨텍스트 multiplier
즉 비용 계산은 ‘총 토큰 × 단가’가 아니라 ‘토큰 종류별 사용량 × 각 단가’에 가깝다.
‘Prompt caching’은 ‘반복되는 입력을 싸게 다시 쓰는 장치’이지, 모든 입력을 자동으로 공짜로 만드는 기능은 아니다. 공급자에 따라 cache write에는 별도 비용이 붙고, cache read/hit만 크게 할인되는 구조가 많다. 따라서 캐시 히트율이 낮은 워크로드에서는 기대한 만큼 비용이 줄지 않는다.
‘Reasoning 모델’은 사용자가 보지 못하는 내부 토큰이 비용에 영향을 준다. OpenAI 계열 reasoning tokens는 응답에 보이지 않지만 output tokens로 과금된다. Anthropic 쪽도 ‘extended thinking + thinking budget_tokens’ 같은 옵션이 정확도와 토큰 비용의 트레이드오프 자리다. 따라서 reasoning 모델은 정확도뿐 아니라 ‘hidden token spend’까지 함께 측정해야 한다.
가격 비교는 ‘단가표가 아니라 내 워크로드 시뮬레이션’으로 한다.
6. Latency — 응답 시간은 두 가지로 나뉜다
‘한 줄 요약: TTFT(첫 토큰까지)와 throughput(전체 속도)을 따로 본다.’
- ‘TTFT(time-to-first-token)’: 사용자가 답이 시작되는 걸 보기까지 시간. 챗봇 체감을 결정.
- ‘Throughput(tokens/sec)’: 첫 토큰 이후 흐르는 속도. 긴 답·배치 작업에 영향.
- ‘Reasoning 모드’: ‘생각’하는 모델은 TTFT가 수 초~수십 초로 길어진다. 정확도와 트레이드오프.
- ‘Streaming 안정성’: 중간에 끊기거나 재정렬되는가.
실시간 챗봇이면 TTFT 가중치 5, 야간 배치 분석이면 가중치 1.
7. 데이터 정책 — Hard Gate가 될 수도, Weighted Score가 될 수도
‘한 줄 요약: 데이터 정책은 점수가 아니라 탈락 조건이 될 수 있다. “성능 1등인데 정책이 애매한 모델”은 선택지가 아니다.’
시리즈 10편(신뢰성과 책임)에서 다룬 내용을 의사결정 기준으로 가져온다.
데이터 정책을 볼 때는 ‘회사 이름’만 보면 안 된다. 같은 공급자라도 제품 라인에 따라 정책이 다르다.
| 라인 | 봐야 할 것 |
|---|---|
| 개인용 챗봇 (ChatGPT 무료/Plus, Claude Free/Pro 등) | 학습 사용 여부의 기본값과 opt-out 옵션 |
| 개발자 무료 API | 학습 사용 여부, 보존, rate limit |
| 유료 API | 기본 학습 미사용 정책, 보존 기간, abuse monitoring |
| Enterprise / Business 계약 | DPA, SLA, 감사 로그, zero retention 옵션 |
| 클라우드 마켓플레이스 경유 (AWS Bedrock, Google Vertex AI 등) | 클라우드 사업자의 데이터 처리 책임, 리전, 격리 |
이 다섯 가지는 데이터 학습 사용 여부, 보존 기간, 리전, 감사 로그 조건이 다를 수 있다. 따라서 “OpenAI는 안전한가?”, “Claude는 학습에 쓰나?”처럼 묻지 말고 ”우리가 쓰는 정확한 제품·요금제·계약에서 어떤 데이터 정책인가?”를 확인해야 한다.
‘데이터 정책은 점수 항목이 아니라 탈락 조건이 될 수 있다.’ 사내 소스코드, 고객 개인정보, 금융 거래 데이터가 들어간다면 ‘성능은 1등인데 데이터 정책이 애매한 모델’은 후보 자체에서 빠진다. 그래서 결론 표 1단계(Hard Gate)에 데이터 정책이 들어가 있고, 9가지 기준에서는 ‘Hard Gate 통과 후 디테일 비교’로 다시 등장한다.
8. 로컬 가능 여부 — API only인가, 오픈웨이트 라인이 있는가
‘한 줄 요약: 폐쇄망·민감 데이터·고정 비용 시나리오에서 오픈웨이트 라인의 존재 자체가 결정적.’
- ‘API only(GPT, Claude, Gemini frontier)’: 가장 좋은 품질, 가장 빠른 업데이트. 단 호출 자체가 로컬·폐쇄망 안에만 머물지는 않는다 — Enterprise 계약, 클라우드 마켓플레이스 경유, 리전 격리 옵션에 따라 데이터 흐름이 달라진다.
- ‘오픈웨이트(Gemma, Qwen, Mistral, Llama 라인)’: 폐쇄망·온프레미스·고정 비용 가능. 다만 폐쇄망·비용·데이터 통제에서 강한 대신, 최신 frontier API 대비 추론·도구 호출·멀티모달·긴 컨텍스트 품질에서 차이가 날 수 있다.
- ‘하이브리드’: 민감 데이터는 로컬, 일반 데이터는 frontier API.
자세한 내용은 시리즈 9편(로컬 LLM 운용) 참고.
9. 운영 안정성·언어 성능
‘한 줄 요약: 1등 모델도 죽으면 0점. 한국어 못 하면 -10점. 그리고 모델은 성능보다 운영에서 문제가 더 자주 난다.’
- ‘Rate limit / 가용성’: 트래픽 피크에 buckling이 없는가, 장애 빈도와 SLA.
- ‘Fallback 모델 지원’: 1차 모델 장애 시 자동으로 2차로 가는 구조를 짤 수 있는가.
- ‘안정 라인 vs 실험 라인’: preview/beta vs GA. 운영은 GA 라인을 고른다.
- ‘모델 alias 정책’:
latestalias를 쓸지, 고정 버전 ID를 쓸지. alias는 편하지만 어느 날 모델이 조용히 바뀌어 회귀가 날 수 있다. - ‘Deprecation notice’: 모델 종료 예고를 얼마나 일찍·명확히 주는지. 갑자기 deprecate되면 마이그레이션 일정이 망가진다.
- ‘장애 공지·status page’: 운영 중 장애를 공식적으로 추적할 수 있는지.
- ‘Quota 증설 절차’: 트래픽 증가 시 rate limit을 빠르게 늘릴 수 있는지. 영업 채널이 필요한 경우가 많다.
- ‘한국어 품질’: frontier 모델이라도 한국어 정교함은 차이 난다. 도메인 어휘·존댓말·맞춤법까지.
- ‘도메인 특화’: 의료·법률·금융 어휘가 자연스러운가.
운영 서비스에선 가중치가 절대 낮을 수 없다.
시나리오로 가중치 적용해보기
‘한 줄 요약: 같은 9가지 기준이라도 가중치가 달라지면 “내 1등 모델”이 완전히 바뀐다.’
세 가지 가상 시나리오로 가중치 차이를 본다. (가중치 1~5, 합계 비교용. Gate 항목은 통과/탈락만.)
| 기준 | 사내 RAG 챗봇 | 코딩 에이전트 | B2C 일반 챗봇 |
|---|---|---|---|
| 1. 작업 성격 | RAG 적합 ★★★★★ | 코딩 에이전트 ★★★★★ | 대화 자연스러움 ★★★★ |
| 2. 컨텍스트 윈도우 | ★★★★★ (긴 문서) | ★★★★ (코드베이스) | ★★ |
| 3. 도구 호출 안정성 | ★★★ | ★★★★★ | ★★ |
| 4. 구조화 출력 | ★★★ (인용 포맷) | ★★★ | ★★ |
| 5. 가격 구조 | ★★★★ | ★★★ | ★★★★★ (대량) |
| 6. Latency | ★★★ | ★★★ | ★★★★★ (TTFT) |
| 7. 데이터 정책 | Gate (사내 데이터) | Gate (코드 IP) | ★★★ |
| 8. 로컬 가능 여부 | ★★★★ (옵션) | ★★ | ★ |
| 9. 운영·언어 | ★★★★★ (한국어) | ★★★★ | ★★★★★ |
세 시나리오의 1등 모델이 같을 가능성은 거의 없다. 사내 RAG는 ‘Hard Gate(데이터 정책) 통과 + 컨텍스트 + 한국어’에서 강한 모델, 코딩 에이전트는 ‘Gate 통과 + 도구 호출 + 코딩’이 강한 모델, B2C 챗봇은 ‘TTFT + 가격 + 한국어’가 강한 모델이 각각 1등으로 올라온다.
가중치를 종이에 적어 두는 게 핵심이다. 다음 달에 새 모델이 나와도 같은 가중치 표를 다시 매기면 된다.
실제 평가표 템플릿
‘한 줄 요약: 글에서 본 내용을 그대로 옮길 수 있는 표. 복붙해서 팀과 함께 채우면 된다.’
| 기준 | 가중치(1~5) | 모델 A | 모델 B | 모델 C |
|---|---|---|---|---|
| 데이터 정책 | Gate | 통과/탈락 | 통과/탈락 | 통과/탈락 |
| 리전·레지던시 | Gate | 통과/탈락 | 통과/탈락 | 통과/탈락 |
| 라이선스(오픈웨이트일 때) | Gate | 통과/탈락 | 통과/탈락 | 통과/탈락 |
| 작업 성격 적합성 | 5 | |||
| 컨텍스트 윈도우 | 4 | |||
| 도구 호출 안정성 | 5 | |||
| 구조화 출력 | 3 | |||
| 가격 구조 | 4 | |||
| Latency | 3 | |||
| 로컬 가능 여부 | 2 | |||
| 운영 안정성·한국어 | 5 |
계산은 단순하다.
가중치 점수 = 가중치 × 모델 점수 총점 = 모든 가중치 점수의 합
‘단, Gate 항목을 하나라도 통과하지 못한 모델은 총점과 무관하게 후보에서 제외’한다. 점수가 1등이라도 데이터 정책이 막히면 못 쓴다는 게 이 표의 핵심이다.
이 표를 PR 템플릿이나 사내 위키에 박아두면, 새 모델이 나올 때마다 점수만 다시 매기면 된다.
모델 변경에도 살아남는 설계
‘한 줄 요약: 모델은 라이브러리처럼 갈아끼울 수 있게 설계한다. 코드에 모델 이름을 박지 마라.’
라인업이 매주 바뀌는 환경에서 코드 곳곳에 gpt-..., claude-..., gemini-... 같은 모델명을 직접 박아두면 매번 마이그레이션이 사고가 된다. 다음 네 가지를 미리 깔아두면 갈아끼우는 비용이 크게 준다.
- ‘모델 이름은 설정 파일·환경 변수에’: 코드에서 직접 부르지 말고 외부 설정으로 주입. 시리즈 8편(Spring AI)의 ChatClient 패턴 참고.
- ‘LLM Gateway / Provider Adapter 계층’: 한 ChatClient 인터페이스 위에 여러 공급자를 갈아끼울 수 있게 한다. 공급자별 차이는 adapter에 격리. (Java/Spring 독자라면 Maven/Gradle의 Bill of Materials와는 다른 개념이다.)
- ‘평가 하네스를 먼저 만들어둔다’: 모델을 바꿀 때 ‘내 작업 골든 세트’에서 회귀가 있는지 자동 검증. 도메인 대표 질문 + edge case + 안전 케이스 30~50개면 시작 충분. 시리즈 7편(평가와 하네스) 그대로.
- ‘모델 라우터’: 위험도 낮은 작업은 작고 싼 모델로, 어려운 작업만 frontier로. 라우팅을 가운데 두면 모델 교체가 라우팅 규칙 한 줄 변경으로 끝난다.
[입력]
↓
[난이도 분류기 (작은 모델)]
├─ 단순 분류·요약 → 소형 모델
├─ 일반 대화·코딩 → 표준 모델
└─ 복잡 추론·긴 분석 → frontier 또는 reasoning 모델
↓
[도구 호출 / 응답 후처리(스키마·출처 검증) / 관측·로그·청구]
추가로, 운영 메트릭은 ‘모델 이름과 분리’해 추적한다. 요청당 latency(TTFT/total)·input/output tokens·cache_hit·model_id·error_class를, 일일로는 cost·p50/p95 latency·error rate·fallback 발동 횟수를. 이렇게 두면 모델을 갈아끼워도 비교가 일관된다.
이 형태가 한 번 깔리면 라인업 비교 글이 쓸모 있어진다. ‘이 기준에 더 잘 맞는 모델’을 찾을 때마다 바로 갈아끼우면 된다.
마치며: 다음 글에서 라인업 비교
이 글의 메시지는 한 문장이다. ”라인업이 아니라 기준을 먼저 고른다. 그리고 점수 매기기 전에 탈락 조건부터 본다.”
요약하면:
- ‘Hard Gate가 먼저, Weighted Score가 다음.’ 데이터 정책·리전·폐쇄망·라이선스·SLA를 통과하지 못하면 후보에서 제외.
- ‘최고 모델은 없다.’ 9가지 기준의 가중치가 시나리오마다 달라진다.
- ‘벤치마크는 체급 확인용.’ 마지막 결정은 내 작업으로 직접 A/B.
- ‘가격은 단가표가 아니라 토큰 카테고리별 시뮬레이션.’ caching·batch·reasoning까지 포함.
- ‘데이터 정책은 회사 이름이 아니라 정확한 제품 라인·요금제·계약’으로 본다.
- ‘모델은 갈아끼울 수 있게 설계.’ 코드에 모델명 박지 말고 Gateway/Adapter + 평가 하네스 + 라우터.
”탈락 조건을 먼저, 점수는 그다음. 모델 이름은 설정 파일에. 라인업은 분기마다 갱신해도 프레임은 1~2년을 간다.”