벤치마크 1등 모델이 매출 1등이 아닌 이유

• 핵심: 시험 성적 1등이 장사 1등은 아니라는 관점으로 언어모델 선택 기준을 정리합니다 [1]
• 맥락: 벤치마크와 답변 비교만으로 모델을 고르면 실제 사용자의 반응은 놓치기 쉽습니다 [2][3]
• 관점: 비용 대비 효과를 가르는 것은 모델의 성능 점수가 아니라 사용자의 행동 기록입니다 [1]

사장님, 더 비싼 재료를 쓰면 단골이 늘까요. 답은 사장님이 더 잘 아십니다. 재료가 좋아져도 손님이 체감하지 못하면 계산대 앞 줄은 길어지지 않습니다. 언어모델 이야기도 같습니다. 시험 점수가 가장 높은 모델을 골랐는데 손님 반응이 그대로라면, 고른 기준 자체를 의심해 볼 필요가 있습니다. 이 글은 실제 사용자의 전환율과 비용으로 모델을 비교하는 A/B 테스트라는 발상을 따라가며, 눈앞의 점수보다 행동 기록이 중요한 이유를 차분히 살펴봅니다.

왜 벤치마크 1등이 정답이 아닐까

LLM은 손님 질문에 답하는 말 잘하는 아르바이트생과 같습니다. A/B 테스트는 같은 메뉴를 간판만 바꿔 걸고 어느 쪽에 손님이 더 오는지 보는 장사 실험과 같습니다.

흔히 AI 기능에 쓸 모델을 고를 때 벤치마크 보고서를 봅니다. 프롬프트를 여러 번 돌려보고 답변을 나란히 비교합니다 [1]. 그런데 그렇게 고른 모델이 실제 서비스에서도 좋은 선택인지는 별도로 확인해야 합니다. 비싼 모델을 쓴다고, 답변이 길고 자세하다고 해서 사용자가 서비스를 오래 쓰거나 결제를 더 많이 하는 것은 아니기 때문입니다 [1].

기존 도구들의 공백도 짚어 볼 대목입니다. 사용자 지표를 보는 도구와 언어모델 지표를 보는 도구는 따로 있었고, 둘을 묶어 하나의 흐름으로 보면서 테스트하기는 어려웠습니다 [1]. Langfuse 같은 관측 도구는 모델의 동작을 들여다보고 [2], PostHog 같은 분석 도구는 사용자의 행동을 기록합니다 [3]. 운영자가 진짜로 알고 싶은 것은 따로 있습니다. 특정 모델을 쓸 때 비용 대비 매출을 일으키는 사용자 행동이 얼마나 되는지, 다른 모델로 바꾸면 그 수치가 어떻게 달라지는지입니다 [1].

핵심 변화 3가지

비교 기준이 바뀌는 지점을 표로 정리했습니다.

구분	기존 선택 방식	행동 기준 선택 방식	남는 질문
고르는 기준	벤치마크 점수와 답변 인상 비교 [1]	실제 트래픽을 나눠 비용과 사용자 행동을 함께 비교 [1]	점수가 아니라 반응을 묻고 있는가
보는 지표	사용자 지표와 모델 지표를 따로 확인 [2][3]	호출 비용과 이후 행동을 하나의 흐름으로 확인 [1]	돈과 반응이 한 화면에 보이는가
바꾸는 근거	보고서와 인상 평가로 교체 결정	모델별 성과 지표를 비교해 트래픽 비율 조정 [1]	바꿔도 된다는 근거가 숫자로 있는가

핵심 변화 3가지 — 매장 작업대에서 사장의 손이 태블릿 비교표를 확인하는 장면, 이전·변화 대비

표가 던지는 결론은 하나입니다. 좋은 답변이 아니라 자주 쓰이는 답변이 남습니다.

기술과 비용을 깊게 보면

라우터와 이벤트 연결로 보는 구조

라우터는 홀 서빙 동선을 나누는 매니저와 같습니다. 이벤트는 계산대 영수증에 찍히는 기록과 같습니다.

이 도구의 발상은 단순합니다. 실제 서비스의 트래픽을 모델별로 나누고, 호출 비용과 이후 사용자 행동을 함께 비교합니다 [1]. 언어모델 라우터에 사용자 분석을 붙인 조합이라고 이해하면 가깝습니다 [1]. 예컨대 글쓰기 도구의 초안 생성 기능에 두 모델을 연결하고 트래픽을 10% 대 90%처럼 나눕니다 [1]. 사용자가 초안을 만들고 저장하거나 공유하고 결제하는 과정을 각각 이벤트로 연결한 뒤, 초안 대비 저장과 공유 비율, 결제 비율 같은 성과 지표를 모델별로 비교합니다 [1]. 결과를 보고 비용 대비 효과가 좋은 쪽으로 트래픽 비율을 조정합니다 [1].

여기서 수치가 말하는 바를 짚고 넘어갑니다. 10% 대 90% 같은 분할은 작은 비중으로 새 모델을 시험 삼아 올려보는 안전장치입니다. 전량을 한 번에 바꾸는 도박이 아니라 일부 손님으로 먼저 반응을 보는 장사 수완과 같습니다.

연동 방식도 눈여겨볼 점입니다. OpenAI SDK의 base_url과 헤더를 설정하는 방식으로 붙으며 [1], 공식 API 레퍼런스가 설명하는 표준 호출 규격을 그대로 씁니다 [4]. 초안 생성과 첨삭처럼 기능을 나눠 각각 비교할 수도 있습니다 [1].

게이트웨이와 통계적 유의성이 말하는 것

게이트웨이는 주방 입구에서 주문을 배분하는 패스와 같습니다. 통계적 유의성은 사흘 장사로 단정하지 않고 한 달 장사로 판단하는 신중함과 같습니다.

속도와 안정성을 위해 게이트웨이는 Go 기반으로 만들었고 Goroutine으로 동시성을 챙겼다고 합니다 [1]. SDK와 게이트웨이 여러 단계에 fallback과 failover를 두어 어떤 경우에도 고객사 서비스에 영향이 없도록 했다는 설명입니다 [1]. A/B 테스트의 통계적 유의성에 관한 이론적 요소도 반영하려 노력 중이라고 밝힙니다 [1].

이 대목에서 생각해 볼 점이 있습니다. 실험 결과가 우연인지 실력인지 가리는 절차 없이 숫자만 보면 장사가 아니라 운에 맡기는 셈입니다. 유의성이라는 개념은 그 운과 실력을 가르는 저울과 같습니다.

왜 알아두면 좋은가

이 글의 주제는 가게에 당장 붙이는 도구가 아닙니다. 그럼에도 알아둘 가치가 있습니다. AI를 고를 때 가격표와 성적표만 보는 습관에서 벗어나 손님의 실제 반응을 묻는 습관으로 시선을 옮겨 주기 때문입니다. 비용 관점에서 AI를 고르는 일은 AI 개발 유지보수 3년 비용 비교 정리와 함께 보면 시야가 넓어집니다. 아래 두 자료는 원문엔 없지만 배경 이해를 위해 추가 확인한 공식 문서입니다. 표준 호출 규격을 설명한 OpenAI API 레퍼런스 [4]와 행동 데이터 분석의 기본을 다룬 Google Analytics 개발자 문서 [5]입니다.