리더보드 1등 LLM, 토스에서도 1등일까? - Toss Benchmark 구축기

새 모델이 나올 때마다 우리는 먼저 리더보드를 봅니다. 모델의 지능이 얼마나 높은지, 수학을 잘 푸는지, 코드를 잘 짜는지. 점수가 높으면 자연스럽게, 이 모델이면 우리 서비스도 더 좋아지겠다는 기대를 하게 되죠.

하지만 실제 서비스에 붙여 보면 꼭 그렇지만은 않습니다. 영어를 잘 이해하는 모델이 한국어 정책을 잘 읽는다는 보장은 없고, 추론(Reasoning) 모드에서 높은 점수를 얻은 모델이 빠른 응답이 필요한 운영 환경에서도 같은 성능을 낸다는 보장도 없습니다. 무엇보다 범용 시험을 잘 푸는 것과 토스 도메인 업무를 처리하는 것은 다른 능력입니다.

LLM Modeling 팀은 토스의 다양한 업무에 맞는 모델을 평가하기 위해 Toss Benchmark를 만들었습니다. 한정된 GPU 자원에서 서빙할 모델을 선별하고, Toss Foundation 모델이 갖춰야 할 능력을 정하기 위한 기준입니다. 먼저 토스에서 LLM에 어떤 일을 맡기고 있는지 살펴보겠습니다.

토스는 LLM으로 어떤 문제를 풀고 있을까

토스에서는 상품 카탈로그를 만들고, 카드 약관을 분석하고, 광고를 검수하는 데 LLM을 활용합니다. 토스쇼핑 입점 판매자와 상품 운영에 필요한 안내와 협의를 진행하는 음성 에이전트, 도구로 고객 정보를 조회하는 상담 에이전트처럼 대화와 행동을 이어가는 사례도 있습니다. 금융 서비스뿐 아니라 커머스, 광고, 사내 개발·운영까지 적용 범위가 넓습니다.

아래는 각 영역에서 LLM을 활용하는 사례의 일부입니다.

Toss Benchmark는 이처럼 다양한 업무에 사용할 모델을 비교하기 위해 실제 데이터와 프롬프트를 모아 성능을 측정하고, 평가 대상을 계속 추가하고 있습니다.

이 글에서는 토스 업무에 맞는 평가 기준을 만들고, 실제 업무 성능과의 관계를 확인한 과정을 소개합니다. 이를 통해 어떤 모델을 서빙하고, Toss Foundation 모델에서 어떤 능력을 강화할지 판단하는 기준을 살펴봅니다.

Toss Benchmark는 무엇을 평가할까

Toss Benchmark는 한국어 범용 성능과 토스 도메인 성능을 함께 봅니다. 한국어 범용 평가는 모델의 기본 능력을 넓게 확인하고, 도메인 평가는 실제 업무 처리와 그 업무에 공통으로 필요한 능력을 확인합니다.

한국어 범용 성능은 왜 따로 측정할까

공개 리더보드는 후보 모델을 비교할 때 유용합니다. 하지만 평가에 사용한 언어나 추론 설정이 실제 서비스와 다르면, 같은 모델도 성능과 순위가 달라질 수 있습니다.

프롬프트 언어가 바뀌면 성능과 순위도 바뀐다

한국어 서비스에 사용할 모델이라면, 영어 평가에서의 강점이 한국어 요청에서도 유지되는지 확인해야 합니다. 이를 보기 위해 수학과 코딩은 같은 문제의 영어 원문과 한국어 번역본으로 평가했습니다.

아래 표는 순위 역전이 나타난 구간을 발췌한 것입니다. 영어 점수 순으로 정렬했으며, 순위는 각 표에 포함된 모델 안에서 다시 매겼습니다. 전체 리더보드 순위를 뜻하지는 않습니다.

수학: 같은 문제의 한국어 번역본

코딩: 같은 문제의 한국어 번역본

수학에서는 영어 점수가 81.74점인 gemma-4-26B-A4B-it보다 79.74점인 Qwen3.6-27B가 한국어에서 앞섰습니다. 코딩에서도 영어에서는 Qwen3.5-122B-A10B가 Qwen3.6-27B보다 높았지만, 한국어에서는 순서가 바뀌었습니다.

여기서 볼 것은 점수 하락 자체뿐 아니라 모델 간 우위가 유지되는지입니다. 같은 요구사항을 담은 문제라도 한국어로 제시했을 때 후보 모델의 순서가 달라질 수 있었습니다.

지식: 한국어권의 지식과 문화적 맥락도 확인하기

지식은 수학·코딩과 평가 방식이 다릅니다. 같은 문제를 번역한 것이 아니라 영어와 한국어에서 각각 다른 벤치마크를 사용했습니다. 한국어 평가는 한국어권의 지식과 문화적 맥락을 다루는 벤치마크로 구성했습니다.

영어 평가에서는 Qwen3.5-122B-A10B와 Qwen3.5-35B-A3B가 이 다섯 모델 중 앞섰지만, 한국어 평가에서는 gemma-4-26B-A4B-it가 가장 높았습니다. 수학·코딩 비교가 같은 문제를 한국어로 제시했을 때의 변화를 확인한다면, 지식 평가는 한국어 서비스에서 필요한 지식 범위에서도 모델이 잘하는지를 확인합니다. 두 비교는 서로 다른 질문에 답하지만, 공개 영어 평가만으로 모델을 선택하기 전에 한국어 환경에서 다시 측정해야 한다는 점으로 이어집니다.

추론 설정에 따라 성능은 어떻게 달라질까

언어를 맞추는 것만으로 평가 조건이 같아지지는 않습니다. 모델이 답변을 내기 전에 추론 과정을 생성하는 Reasoning 모드는 문제 해결에 도움이 될 수 있지만, 서비스에서는 비용과 응답 시간 때문에 이를 끄거나 최소화하기도 합니다. 충분한 추론을 허용했을 때의 점수와 실제 운영 설정에서의 점수를 구분해야 하는 이유입니다.

그렇다면 Reasoning을 끄면 모든 모델의 성능이 비슷하게 내려갈까요? 같은 모델을 두 실행 방식으로 평가한 코딩 결과를 비교했습니다. 아래 표는 점수 하락 폭이 큰 순서로 정렬했습니다.

코딩 — 모델마다 다른 Reasoning 설정의 영향

GLM-5.1은 Reasoning을 껐을 때 30.6점, Kimi-K2.6은 26.4점 낮아졌습니다. 반면 gemma-4-26B-A4B-it의 차이는 6.0점이었습니다. 같은 코딩 평가에서도 설정 변경에 따른 하락 폭이 모델마다 크게 달랐습니다.

순서도 달라졌습니다. Reasoning을 켰을 때 GLM-5.1은 78.7점으로 DeepSeek-v4-pro의 76.9점보다 높았지만, 껐을 때는 각각 48.1점과 57.8점으로 역전됐습니다. 추론을 허용한 평가에서 더 높은 모델을 골라도, 실제 서비스에서 추론을 끄면 다른 모델이 더 나을 수 있다는 뜻입니다.

공개 벤치마크 점수는 해당 평가에 사용한 언어와 모델 설정에서 얻은 결과입니다. 앞서 살펴본 것처럼 한국어로 요청하거나 Reasoning 설정을 바꾸면 모델 간 순위도 달라질 수 있습니다. 공개 점수를 참고하되, 우리 서비스에서 사용할 언어와 추론 설정에 맞춰 평가하면 모델의 적합성을 더 정확하게 판단할 수 있습니다.

Toss Benchmark는 이런 차이를 반영해 토스의 서비스 환경에 맞는 평가 결과를 제공합니다. 공개 리더보드의 순위에 더해, 우리 업무에서 필요한 품질을 내는지 살펴보기 위한 기준입니다.

범용 성능만으로는 왜 부족할까

한국어와 모델 설정을 맞춰 평가하더라도 실제 업무에서 요구하는 능력은 별도로 확인해야 합니다.

예를 들어 상품명을 표준 속성으로 바꿔 카탈로그에 넣는 업무를 생각해 보겠습니다. 실제 서비스 프롬프트는 아래처럼 정보의 역할과 출력 원칙을 정의합니다.

공통 추출 정책
- 상품명 안의 정보를 ‘판매 상품’, ‘호환 대상’, ‘옵션’, ‘구성’, ‘모델명’ 등 역할에 맞는 속성으로 분리한다.
- 대표 상품명에는 실제 구매하는 물건을 식별하는 정보만 남긴다. 호환 대상, 구성 수, 사은품처럼 별도 속성으로 관리하는 정보는 대표 상품명에 넣지 않는다.
- 수량과 단위는 카테고리별 표준 단위로 정규화하되, 상품의 의미가 바뀌는 환산은 하지 않는다

아래는 입력 상품명 및 추출 속성 예시입니다. (브랜드·머신·제품명은 가상의 명칭)

입력 상품명:
캐치프레소 모비오 더블 에스프레소 멜로아 캡슐 3슬리브, 총 255g

{
  "브랜드": "캐치프레소",
  "상품명": "더블 에스프레소 멜로아 캡슐",
  "호환 기기": "캐치프레소 모비오 머신",
  "수량": "30EA",
  "총중량": "255g"
}

여기서 모비오는 캡슐의 맛이나 상품명이 아니라 사용할 수 있는 머신을, 더블은 두 개 묶음이 아니라 커피의 종류를 뜻합니다. 또 캐치프레소 모비오 캡슐은 한 슬리브에 10개가 들어간다는 정보를 알아야 3슬리브를 30EA로 바꿀 수 있습니다. 이런 해석은 범용적인 문자열 처리만으로는 안정적으로 하기 어렵고, 카테고리별 상품 지식과 서비스 정책을 함께 알아야 합니다

이 업무에서 도메인 지식은 상품명 속 정보의 의미를 해석하는 데 필요하고, 정책 준수는 그 정보를 정해진 속성과 형식으로 바꾸는 데 필요합니다. Toss IFBench와 Toss Knowledge는 이 두 능력을 각각 평가하기 위해 만들었습니다.

토스 도메인 성능을 평가하는 방법

토스 도메인 성능은 다음 세 종류의 평가로 나눴습니다.

이미 정답 데이터가 있는 업무는 운영 태스크로 직접 평가할 수 있습니다. IFBench와 Knowledge는 개별 업무의 평가 데이터가 없어도 도메인 성능을 파악할 수 있는 공통 기준입니다.

Toss IFBench: 정책을 이해하고 지키는 능력

토스의 LLM 업무에는 정책이 긴 프롬프트로 들어가는 경우가 많습니다. 상품 속성을 추출할 때의 출력 형식, 고객 문의를 분류할 때의 기준, 두 상품이 같은지 판단하는 규칙이 그 예입니다.

Toss IFBench는 상품 속성 추출과 상품 동일성 판단, 두 업무의 실제 서비스 프롬프트에서 규칙 기반으로 채점할 수 있는 지시와 판단 기준을 추렸습니다. 그리고 개별 업무의 표현에 묶이지 않도록 일반화해, 토스 도메인에서 필요한 정책 이해와 준수 능력을 평가합니다.

형식만 맞추는 것과 규칙을 따르는 것은 다릅니다

상품 속성 추출에는 보통 여러 조건이 한꺼번에 들어갑니다. 예를 들어 ‘JSON으로 답할 것’, ‘키는 정해진 순서로 쓸 것’, ‘수량은 EA 단위를 붙일 것’처럼요. 조건을 하나라도 놓치면 서비스가 결과를 그대로 쓰기 어려워집니다.

형식 지시 평가는 이 조건들을 지시 단위로 나누어 각각 확인합니다. 덕분에 단순히 그럴듯한 JSON을 내는지를 넘어, 프롬프트에 적힌 세부 규칙을 빠뜨리지 않고 읽는지 볼 수 있습니다.

판단 지시는 한 단계 더 나아갑니다. 같은 상품 쌍을 두고, 판단 규칙만 바꿔 두 번 묻습니다.

예를 들어 면도기 1개와 10개 묶음은 기본 규칙에서는 다른 상품이지만, ‘수량 차이는 무시한다’는 규칙에서는 같은 상품입니다. 모델이 상품 자체만 보고 “당연히 다르다”고 답한다면 한 문제는 맞혀도 다른 한 문제에서 틀립니다. 이 방식은 원래 판단을 고집하는 모델과 프롬프트 규칙에 맞춰 판단을 바꾸는 모델을 구분합니다.

두 지시 유형에서 모델의 성능은 실제로 다르게 나타났습니다. 아래 차트는 IFBench 종합 점수 상위 5개 모델을 대상으로, 형식 지시와 판단 지시 점수를 나란히 보여줍니다.

\* reasoning을 완전히 끌 수 없어 reasoning_effort=low 조건으로 측정했습니다.

gemini-3.8-flash와 gemma-4-31b-it는 판단 지시에서 모두 83.2점으로 공동 1위입니다. 하지만 형식 지시에서는 gemini-3.8-flash가 78.0점, gemma-4-31b-it가 56.2점으로 21.8점 차이가 납니다. 규칙에 따라 판단을 바꾸는 능력과, 여러 출력 조건을 빠뜨리지 않고 지키는 능력은 같지 않습니다. 정책 준수 능력을 보려면 두 축을 함께 봐야 합니다.

Toss Knowledge: 토스 도메인 지식을 평가하는 방법

Toss Knowledge는 토스 업무에 필요한 도메인 지식을 평가합니다. 첫 대상으로 커머스를 택한 것은 상품 검수·카탈로그 생성·상품 매칭 등 다양한 업무가 브랜드·규격·옵션에 대한 공통 지식을 요구하기 때문입니다.

이 지식을 평가하기 위해 아래 다섯 영역의 4지선다 문항을 구성했습니다.

이런 질문을 합니다

아래는 평가 문항의 예시입니다. (브랜드 이해·상품 이해 예시의 브랜드와 제품명은 가상의 명칭으로 바꾸고, 일부 설명을 재구성)

브랜드 이해

다음 중 브랜드 ‘로에빈’에 대한 설명으로 옳은 것은?

① 테니스 라켓과 운동복을 주력으로 판매하는 스포츠 브랜드 ② 냄비와 프라이팬을 주력으로 판매하는 주방용품 브랜드 ③ 의류와 가방을 주력으로 판매하는 패션 브랜드 ④ 유리컵과 접시를 주력으로 판매하는 식기 브랜드

예시에서 설정한 정답: ③

이커머스 용어

제조사가 제품의 기획·설계·개발까지 직접 하고, 판매 기업은 자사 브랜드만 붙여 파는 생산 방식은?

① 3PL　② OEM　③ ODM　④ OBM

정답: ③

상품 이해

다음 중 상품 ‘그립온 토르빗’에 대한 설명으로 옳은 것은?

① 전선 피복을 자동으로 벗기는 스트리퍼 ② 단자를 압착할 때 사용하는 래칫형 압착기 ③ 버튼으로 턱 간격을 조절하는 워터펌프 플라이어 ④ 손잡이를 잠가 물체를 고정하는 바이스 플라이어

정답: ③

최신 정보 접근 여부의 영향을 줄이기 위해, 출시 후 충분한 시간이 지났고 현재도 활발히 거래되는 브랜드·상품을 중심으로 문항을 구성했습니다. 지나치게 쉬운 문항을 제외하고 새 문항을 보충했으며, 정답 보기의 길이가 단서로 작용하지 않도록 조정했습니다.

채점은 정답을 각 보기 위치에 한 번씩 배치해 네 차례 평가한 정답률의 평균(avg@4)을 사용했습니다. 특정 보기 위치에 대한 선호가 점수에 미치는 영향을 줄이기 위한 방식입니다.

주요 5개 모델을 축별로 보면, 같은 상위권 모델이라도 강점은 다릅니다. gemma-4-31b-it는 다섯 축 모두 89~97점으로 고른 성능을 보입니다. 반면 GPT-5.4-mini는 이커머스 용어에서 76점으로 크게 낮고, GLM-5.3-flash는 상품 스펙 97점에 비해 상품 이해 81점으로 차이가 큽니다. gemma-4-26b-a4b-it도 이커머스 은어는 97점이지만 상품 이해는 81점입니다. 즉, 종합 순위가 비슷해도 서비스에서 주로 묻는 지식 축에 따라 더 적합한 모델은 달라질 수 있습니다.

실제 운영 성능과도 연결될까

공통 평가 기준을 만든 뒤에는 기존 운영 업무의 성능과 연결되는지 확인했습니다. 공개 범용 지표인 AAII(Artificial Analysis Intelligence Index), Toss IFBench 형식 지시, Toss Knowledge를 각각 운영 태스크 평균 점수와 비교했습니다.

평가의 공정성을 위해, 벤치마크 데이터 구성 시 참고했던 운영 태스크는 상관관계 분석 대상에서 제외했습니다. 벤치마크를 만드는 데 참고한 업무와 평가 대상을 분리해, 다른 운영 업무의 성능과도 연결되는지 확인했습니다.

상관계수는 두 가지를 함께 봤습니다. Spearman ρ는 모델들의 순위가 함께 움직이는 정도이고, Pearson r은 점수 차이의 크기까지 비례하는 정도입니다. 둘 다 +1에 가까우면 관계가 강하고, 0에 가까우면 뚜렷한 상관이 관찰되지 않았다는 뜻입니다.

세 그래프는 같은 11개 모델을 비교합니다. 점 하나는 모델 하나이며, 가로축은 각 지표의 점수, 세로축은 동일한 운영 태스크의 평균 점수입니다. 점선은 점수 사이의 선형 추세, 음영은 그 추세의 95% 신뢰구간으로, Pearson r이 나타내는 관계입니다.

Toss IFBench 형식 지시 점수가 높은 모델은 운영 태스크 평균도 높은 경향을 보였습니다. 서비스 프롬프트에서 뽑은 정책 준수 평가가 기존 업무 성능을 판단할 때 참고할 만한 정보를 담고 있다는 결과입니다.

Knowledge도 운영 태스크 평균과 양의 상관을 보였습니다. 하지만 여러 업무를 합친 평균만으로는 커머스 지식이 어떤 업무의 성능과 연결되는지 알기 어렵습니다. 그렇다면 실제 커머스 운영 태스크를 따로 살펴보면 어떨까요? 같은 모델 집합에서 각 커머스 태스크의 점수와 Knowledge 점수를 비교했습니다. 아래는 높은 상관이 관찰된 상품 분류·그룹화·검수 결과입니다.

상품 분류·그룹화·검수에서는 커머스 지식 점수가 높은 모델이 업무 점수도 높은 경향을 보였습니다. 이를 통해 Toss Knowledge가 측정하는 커머스 지식이 실제 운영 성능과도 연결된다는 점을 확인할 수 있었습니다.

모델 비교와 추천으로 연결하기

평가 결과는 사내 GenAI Portal의 모델 카탈로그에서 확인할 수 있습니다. 사용 가능한 모델의 평가 결과와 서빙 지표를 한 화면에서 비교하고, 새 모델이 등록되면 같은 기준으로 평가해 추가합니다.

업무 목적을 입력하면 에이전트가 평가 결과를 바탕으로 후보 모델을 제안합니다. 예를 들어 상품 카테고리 분류를 요청하면, 분류 규칙 준수와 상품 이해에 관련된 점수를 비교해 우선 후보와 비교 후보를 제안하고 추천 근거를 설명합니다.

Foundation 모델의 개발 기준으로 활용하기

Toss Benchmark는 현재 개발 중인 Toss Foundation 모델의 개발 목표를 정하는 데도 활용하려고 합니다. 한국어 이해, 정책 준수, 도메인 지식 중 어떤 능력을 강화해야 하는지 파악하고, 학습 전후의 평가 결과를 비교해 개선 여부를 확인하는 기준입니다.

마치며

현재 Toss Benchmark를 다음 세 방향으로 확장하려고 합니다.

앞으로도 실제 업무에서 얻은 사례를 평가에 반영하고, 그 과정에서 확인한 모델의 특성과 평가 경험을 공유하려고 합니다. 이 글이 각자의 서비스에 맞는 모델 평가 기준을 고민하는 데 도움이 되었으면 합니다. 감사합니다.