지난 글에서는 모델 여러 개를 한 기능 안에서 함께 쓰는 구조를 봤다. 그 구조를 만들기 전에 반드시 지나가는 자리가 하나 있다. 애초에 어떤 모델을 후보로 놓을 것인가.
이 질문은 대개 회의에서 이렇게 처리된다. 누군가 새 모델의 벤치마크 표를 띄우고, 누군가 "우리가 쓰는 건 좀 답답하다"고 말하고, 한 시간쯤 지나 결론 없이 끝난다. 6주 뒤 새 모델이 나오면 같은 회의를 다시 한다. 문제는 모델이 아니라 결정을 내리는 방식에 절차가 없다는 것이다.
절차가 있으면 회의는 30분에 끝나고, 6주 뒤에는 처음부터 다시 하는 대신 바뀐 항목만 다시 잰다.
모델보다 자리를 먼저 적는다
"우리는 어떤 모델을 쓸까"는 사실 답할 수 없는 질문이다. 제품 안에 모델을 부르는 자리가 여럿이고 자리마다 요구가 다르기 때문이다. 문서를 분류하는 자리, 초안을 쓰는 자리, 도구를 부르며 여러 단계를 도는 자리는 서로 다른 문제다.
그래서 시작은 자리 하나를 골라 그 자리의 요구를 글로 적는 것이다. 적을 것은 다섯 가지다.
- 입력과 출력의 모양 — 얼마나 긴가, 구조화된 출력이 필요한가, 이미지가 들어오는가
- 실패했을 때 무슨 일이 일어나는가 — 사용자가 다시 누르면 되는가, 잘못된 값이 다른 시스템으로 흘러가는가
- 하루 몇 건인가, 몰리는 시간대가 있는가
- 응답을 얼마나 기다려 줄 수 있는가 — 사람이 화면을 보고 있는가, 배치로 도는가
- 이 자리에 들어오는 데이터가 어디까지 나가도 되는가
이걸 적고 나면 후보 목록은 이미 절반쯤 정리된다. "실패하면 잘못된 값이 결제 시스템으로 간다"고 적은 순간, 구조화 출력을 못 맞추는 모델은 후보에서 빠지기 때문이다.
하드 제약으로 먼저 자른다
하드 제약은 아무리 품질이 좋아도 못 쓰게 만드는 조건이다. 점수로 절충되지 않으므로 가장 먼저, 가장 빠르게 적용한다. 이 단계는 모델을 한 번도 호출하지 않고 문서만 읽어도 끝난다.
| 제약 | 확인할 것 | 흔한 탈락 사유 |
|---|---|---|
| 데이터 위치·규정 | 어느 리전에서 처리되는가, 학습에 쓰이는가 | 계약이 허용하지 않는 리전 |
| 실효 컨텍스트 | 최대 길이가 아니라 그 길이에서도 정확한가 | 최대치는 크지만 뒤쪽을 놓친다 |
| 모달리티 | 이미지·오디오·PDF를 직접 받는가 | 이미지를 별도 파이프라인으로 빼야 한다 |
| 구조화 출력 | 스키마를 강제할 수단이 있는가 | 프롬프트로만 부탁할 수 있다 |
| 도구 호출 | 병렬 호출·강제 호출을 지원하는가 | 한 번에 하나씩만 부른다 |
| 배포 형태 | 자체 호스팅이 필요한가, API로 충분한가 | 폐쇄망 요구 |
| 라이선스 | 상용 이용과 재배포 조건 | 조건부 상용 허용 |
| 가용성 | 속도 한도, 지역별 제공, 폐기 예고 기간 | 몇 달 뒤 사라질 모델 |
마지막 줄을 자주 빠뜨린다. 모델은 언젠가 폐기된다. 폐기 예고 기간이 얼마인지, 후속 모델로 옮길 때 프롬프트를 다시 손봐야 하는지가 1년짜리 기능에서는 품질 몇 퍼센트보다 큰 문제가 된다.
골든셋으로 잰다
제약을 통과한 후보가 서넛 남았다면 이제 재야 한다. 여기서 공개 리더보드를 보는 것은 시간 낭비에 가깝다. 리더보드는 "일반적으로 똑똑한가"를 재고, 우리가 알고 싶은 것은 "우리 문서에서 우리 형식으로 우리 판단 기준에 맞게 하는가"이기 때문이다. 둘의 순위는 자주 어긋난다.
필요한 것은 골든셋이다 — 우리 작업에서 뽑은 입력과, 사람이 확인한 정답 혹은 채점 기준을 짝지어 둔 묶음을 말한다. 100건이면 시작할 수 있고 300건이면 대부분의 자리에서 충분하다. 중요한 것은 개수보다 구성이다.
- 평범한 요청 — 실제 분포에서 그냥 뽑는다. 전체의 절반쯤
- 어려운 요청 — 길거나, 애매하거나, 예외 규칙이 걸린 것
- 과거에 틀렸던 요청 — 사고가 났던 입력을 모아 둔다. 가장 값이 나가는 부분이다
- 안 해야 하는 요청 — 거절해야 하거나 되물어야 하는 입력
여기서 비교를 망치는 함정이 하나 있다. 같은 프롬프트를 그대로 여러 모델에 넣고 점수를 비교하는 것이다. 프롬프트는 대개 지금 쓰는 모델에 맞춰 오래 다듬어져 있어서, 그대로 옮기면 새 모델은 제 실력을 못 낸다. 반대로 새 모델용으로 이틀을 손보고 기존 모델은 그대로 두면 반대 방향으로 틀어진다.
공평하게 하려면 후보마다 같은 손질 예산을 준다. 모델당 두 시간이면 두 시간, 프롬프트 수정 세 번이면 세 번으로 정해 두고 그 안에서 각자 최선을 만든 뒤 재는 것이다. 예산을 정해 두는 것 자체가 핵심이다 — 정해 두지 않으면 손질 시간이 곧 편애가 된다.
채점은 가능한 한 자동으로 만든다. 정확히 맞아야 하는 항목은 문자열 비교로, 형식은 스키마 검사로, 나머지는 채점 기준을 적은 판정 모델로 잰다. 판정 모델을 쓴다면 사람이 채점한 30건과 얼마나 일치하는지 한 번은 확인해 둔다.
비용과 지연은 마지막에, 그러나 정확하게
품질을 재고 나면 남은 것은 산수다. 그런데 이 산수를 틀리게 하는 방식이 몇 가지 있다.
가장 흔한 것은 입력 단가만 보는 것이다. 실제 청구서는 이렇게 생겼다.
출력 단가는 입력의 서너 배인 경우가 흔하고, 추론 모델은 답을 내기 전에 생각을 길게 하므로 눈에 보이는 답이 짧아도 이 몇 배로 뛴다. 답의 길이가 아니라 청구되는 토큰 수로 재야 한다. 골든셋을 돌릴 때 응답의 사용량 필드를 그대로 기록해 두면 이 계산은 표 하나로 끝난다.
프롬프트 캐시를 쓰는 자리라면 캐시 적중 시 단가도 따로 넣는다. 앞부분이 긴 시스템 프롬프트로 고정된 자리에서는 이 항목이 총액의 순위를 바꾸기도 한다.
지연은 평균이 아니라 p95로 본다. 평균이 같아도 꼬리가 두 배 긴 모델이 있고, 사용자가 기억하는 것은 그 꼬리다. 스트리밍을 쓴다면 첫 토큰까지의 시간을 따로 재는 편이 낫다 — 총 시간이 조금 길어도 첫 글자가 빨리 나오면 체감은 반대가 된다.
이제 점을 찍는다.
품질 하한과 비용 상한이 상자를 만들고, 그 안에 들어온 점 중 가장 싼 것을 고른다. 하한 아래는 아무리 싸도 못 쓰고, 상한 오른쪽은 아무리 좋아도 못 쓴다. 이 상자를 미리 정해 두는 것이 요령이다. 점을 다 찍은 뒤에 정하면 마음에 드는 점이 들어오도록 선을 옮기게 된다.
상자 안이 비어 있다면 그것도 결과다. 후보를 늘리는 대신, 작업을 쪼개거나 검색으로 문맥을 줄이거나 파인튜닝을 검토할 자리라는 신호다.
결정을 파일로 남긴다
여기까지 왔으면 결정을 짧게 적어 저장소에 둔다. 이 파일이 있으면 두 달 뒤 "왜 이걸 쓰기로 했더라"에 5분이 아니라 5초가 걸린다.
자리: 지원 티켓 분류
결정: small-tier-v3
날짜: 2026-08-18
탈락: large-tier-v2 (비용 상한 초과), open-7b (구조화 출력 미달)
근거: 골든셋 240건 정확도 0.91, p95 1.2초, 요청당 0.0004달러
다시 볼 조건:
- 골든셋 정확도가 0.88 아래로 내려갈 때
- 티켓 형식이 바뀌어 골든셋을 갱신할 때
- 분기 1회 정기 점검마지막 항목이 이 파일의 핵심이다. 재평가 트리거를 미리 적어 두면 새 모델 출시가 회의의 시작 신호가 되지 않는다. 새 모델이 나왔다는 사실은 우리 자리의 조건을 아무것도 바꾸지 않는다. 조건이 바뀌었을 때, 혹은 정해 둔 주기가 왔을 때 재면 된다. 그리고 그때 다시 재는 일은 처음보다 훨씬 싸다 — 골든셋과 채점기가 이미 있기 때문이다.
자주 보는 오판 넷
한 번의 인상적인 실패로 모델을 바꾼다. 누군가 슬랙에 붙인 이상한 답변 하나가 교체 논의를 시작시킨다. 그 입력을 골든셋에 넣고 후보 전부를 돌려 보면 대개 다른 모델도 비슷하게 틀린다. 사례는 증거가 아니라 새 골든셋 항목이다.
최신 모델을 반사적으로 채택한다. 새 모델이 우리 자리에서 더 나은지는 재 보기 전에는 모른다. 특히 프롬프트가 길게 다듬어진 자리에서는 처음엔 오히려 나쁘게 나오는 일이 흔하다.
모든 자리를 한 모델로 통일하려 한다. 관리가 편해 보이지만, 가장 어려운 자리의 요구가 모든 자리의 비용을 정하게 된다. 분류 한 줄에 최상위 모델 요금을 내는 구조가 이렇게 만들어진다.
품질 차이를 표본 크기 없이 말한다. 골든셋 100건에서 정확도 0.90과 0.93은 사실상 구분되지 않는다. 차이가 작으면 "차이 없음"으로 읽고 비용과 지연으로 고르는 편이 정직하다.
정리하면
모델 선정은 취향의 문제로 보이지만, 절차를 적어 두면 대부분 기계적으로 풀린다. 자리의 요구를 적고, 하드 제약으로 자르고, 골든셋으로 재고, 상자 안에서 가장 싼 것을 고르고, 다시 볼 조건과 함께 기록한다.
이 절차의 진짜 이득은 이번 결정이 아니라 다음 결정에서 나온다. 골든셋과 채점기와 결정 기록이 남아 있으면, 다음 모델이 나왔을 때 우리가 할 일은 논쟁이 아니라 표를 한 번 더 채우는 일이 된다.
읽어주셔서 감사합니다. 😊