일반적인 순위표가 당신을 잘못된 선택으로 유도하기 전에, 당신의 사용 사례에 맞는 올바른 LLM을 선택하기 위한 실질적인 가이드.

상상해 보세요. 당신은 모든 리더보드(Leaderboard) 최상단에 있는 LLM으로 교체했습니다. 비용은 기존에 지불하던 것의 4배가 듭니다. 2주 후, 당신은 다시 이전 모델로 돌아갑니다. 왜냐하면 실제 프롬프트(Prompt)를 적용했을 때 성능이 더 나빴기 때문입니다. 해당 모델은 출력 형식(Output format)을 약 3분의 1의 확률로 망가뜨렸지만, 기존에 사용하던 더 저렴한 모델은 거의 그런 일이 없었습니다. 리더보드가 틀린 것은 아니었습니다. 단지 당신의 프로젝트가 중요하게 여기는 그 어떤 것도 측정하지 않았을 뿐입니다.

리더보드가 계속해서 당신에게 거짓말을 하는 이유

공개 리더보드는 정확히 한 가지 용도로 유용합니다. 어떤 모델들이 대략적으로 동일한 계층(Tier)에 있는지 파악하는 것입니다. 그 이상의 부분에서, 리더보드는 당신이 아마도 묻고 있지 않은 질문에 답하고 있습니다.

리더보드는 대개 학술적인 성격의 고정된 작업 세트, 즉 추론 퍼즐, 시험 문제, 코딩 챌린지, 광범위한 상식 등을 통해 집계된 성능을 측정합니다. 당신의 사용 사례는 거의 확실히 그보다 더 좁을 것입니다. 어쩌면 당신은 깨끗한 JSON을 안정적으로 반환하는 모델이 필요할 수도 있습니다. 어쩌면 매우 특정한 어조를 유지하는 모델이 필요할 수도 있습니다. 어쩌면 하루에 만 번씩 실행해야 하기 때문에 빠르고 저렴한 모델이 필요할 수도 있으며, 이 경우

더 나은 접근 방식이 여기 있습니다. 복잡하지 않습니다. 대부분 다섯 가지 사항에 대해 의도적으로 접근하느냐의 문제입니다.

1. 실제 프롬프트(Prompts)로 테스트 세트 구축하기

이것이 핵심이며, 사람들이 건너뛰는 단계입니다.

일반적인 질문으로 벤치마크(Benchmark)를 수행하지 마세요. 애플리케이션이 실제로 보내는 실제 프롬프트를 추출하거나, 이를 밀접하게 반영하는 수십 개의 프롬프트를 작성하세요. 만약 당신의 제품이 고객 지원 티켓(Support tickets)을 요약한다면, 테스트 세트는 실제 고객 지원 티켓이어야 합니다. 제품 설명을 작성한다면, 실제 제품 데이터여야 합니다. 테스트 세트가 실제 트래픽(Live traffic)에 가까울수록, 벤치마크는 실제 동작을 더 잘 예측합니다.

수천 개가 필요하지는 않습니다. 일반적인 사례와 가장 까다로운 에지 케이스(Edge cases)를 포괄하는 잘 선택된 20~50개의 프롬프트가 그 어떤 거대한 학술적 벤치마크보다 더 많은 것을 알려줄 것입니다. 의도적으로 특이한 사례들을 포함하세요. 에지 케이스는 모델들이 실제로 성능 차이를 보이는 지점이며, 일반적인 순위(Ranking)가 평균화하여 없애버리는 바로 그 지점입니다.

2. "더 나은" 것이 실제로 무엇을 의미하는지 글로 정의하기

"더 나은"은 이 전체 과정에서 가장 비용이 많이 드는 단어입니다. 왜냐하면 당신이 성공을 정의하지 않았다는 사실을 숨기고 있기 때문입니다.

무엇인가를 비교하기 전에, 좋은 답변이 충족해야 하는 조건을 글로 적고, 이를 검증 가능한 형태로 만드세요. "요약이 고품질이어야 한다"가 아니라, 기계나 주의 깊은 독자가 확인할 수 있는 항목이어야 합니다:

• 출력물에 포함되어야 할 필드(Fields)가 포함되어 있는가?
• 유효한 JSON인가, 혹은 당신의 스키마(Schema)와 일치하는가?
• 배포 가능한 길이 이내인가, 혹은 필요한 최소 길이를 초과하지 않았는가?
• 지연 시간(Latency) 예산 범위 내에 있으며, 비용 상한선(Cost ceiling)을 넘지 않았는가?

이 중 일부는 기계적인 요소로, 자동으로 확인할 수 있습니다. 다른 요소들은 어조(Tone)나 사실적 정확성(Factual accuracy)에 대한 판단의 영역이며, 이러한 경우에는 직접 출력물을 읽거나 강력한 모델이 작성된 기준에 따라 평가하도록 해야 합니다 (LLM-as-a-judge라고 알려진 접근 방식). 어떤 방식이든 핵심은 동일합니다. '품질'이라는 모호한 개념을 점수를 매길 수 있는 구체적인 항목들로 전환하는 것입니다. 테스트를 시작하기 전에 무엇이 '더 나은지' 정의할 수 없다면, 당신은 그저 우연히 마음에 드는 출력물을 선택하고, 자신의 선호도를 결과라고 조용히 부르게 될 뿐입니다.

3. 다른 모든 조건을 일정하게 유지하라 (Hold everything else constant)

아이디어가 단순하고 끊임없이 무시되기 때문에 짧게 다루겠습니다.

가능하다면 동일한 날에, 동일한 설정과 동일한 온도(Temperature)로, 동일한 프롬프트(Prompt)를 사용하여 모든 모델을 실행하십시오. 모델 간에 프롬프트를 바꾸거나, 하나는 온도 0에서 테스트하고 다른 하나는 0.7에서 테스트한다면, 당신은 더 이상 모델을 측정하는 것이 아닙니다. 당신은 당신 자신의 일관성 부족을 측정하고 있는 것입니다. 통제된 비교(Controlled comparison)야말로 벤치마크가 의미를 갖는 유일한 이유입니다. 의도하지 않은 변수가 움직이는 순간, 당신의 결과는 증거가 아닌 이야기가 되어버립니다.

4. 모델은 같은 답을 두 번 주지 않으므로, 여러 번 실행하라

이 부분은 충분히 잘 알고 있다고 자부하는 사람들을 포함하여 거의 모든 사람을 실수하게 만드는 지점입니다.

LLM은 결정론적(Deterministic)이지 않습니다. 동일한 프롬프트를 동일한 모델에 다섯 번 보내면 다섯 개의 서로 다른 답변을 얻을 수 있으며, 때로는 의미가 다를 수도 있습니다. 따라서 단 한 번의 실행은 측정이 아닙니다. 그것은 일화(Anecdote)일 뿐입니다. 만약 모델 A가 모델 B를 한 번 이겼다면, 그것은 당신에게 거의 아무런 정보도 주지 못합니다. 왜냐하면 다시 실행했을 때 결과가 뒤집히는 것을 볼 수 있기 때문입니다.

어딘가에 문신으로 새겨둘 가치가 있는 주의 사항은 다음과 같습니다: 한 번 목격한 차이는 그것이 유지된다는 것을 증명하기 전까지는 차이가 아닙니다. 각 프롬프트에 대해 각 모델을 여러 번 실행하십시오. 단일 최적 답변이 얼마나 좋았는지만 보지 말고, 각 모델이 얼마나 일관적인지(consistent)를 확인하십시오. 그리고 만약 당신이 어떤 모델이 그저 그날 운이 좋았던 것이 아니라 다른 모델보다 진정으로 더 낫다고 주장하고 싶다면, 그것은 느낌(vibes)의 문제가 아니라 통계(statistics)의 문제입니다. 유의성 검정(Significance testing)이 존재하는 이유는 바로 무작위 노이즈(random noise)와 실제 격차를 구분할 수 있게 하기 위함입니다. 당신이 실제로 구매하게 되는 것은 최고 성능(peak performance)이 아니라 일관성(consistency)인 경우가 많습니다.

5. 비용과 속도는 각주가 아니라 정답의 일부입니다

당신의 사용 사례(use case)에 가장 적합한 모델은 거의 항상 사용 가능한 모델 중 가장 똑똑한 모델은 아닙니다. 그것은 당신이 감당할 수 있는 가격과 속도로 충분히 괜찮은 성능을 내는 모델입니다.

품질 수치를 확보했다면, 비용과 지연 시간(latency)을 바로 옆에 두고 정직하게 트레이드오프(trade-off)를 살펴보십시오. 비용은 10배 더 들고 속도는 절반인 상태에서 품질이 2% 향상되는 것은 대부분의 워크로드(workload)에 있어 최악의 거래이며, 소수의 경우에는 완벽하게 좋은 거래가 될 수 있습니다. 당신이 어느 쪽에 속하는지는 전적으로 당신의 사용 사례에 달려 있으며, 이것이 바로 여기서 다루는 핵심 주제입니다. 대량의 백그라운드 작업(high-volume background job)과 소량의 고위험 법률 요약 작업(low-volume, high-stakes legal summarizer)은 동일한 모델을 선택해서는 안 되지만, 리더보드(leaderboard)는 기꺼이 두 작업 모두를 동일한 비싼 옵션으로 유도할 것입니다. 당신이 무엇을 최적화(optimizing)하려 하는지 결정한 다음, 당신의 품질 기준을 통과하는 가장 저렴한 모델이 승리하게 하십시오.

정직한 문제: 이 모든 것을 수동으로 하는 것은 고된 작업입니다

위의 모든 내용은 원칙적으로는 간단하지만, 실제로는 진정으로 지루한 일입니다.

실제로 이를 실행하려면 각 제공업체(provider)의 API에 맞춰 코드를 작성해야 하는데, 이 API들은 저마다 미세하고 짜증 나는 방식으로 서로 다릅니다. 응답(responses)을 비교 가능한 형태로 정규화(normalizing)해야 합니다. 토큰(tokens)을 계산하여 모델별 비용으로 변환해야 합니다. 변동성(variance)에 대응하기 위해 모든 과정을 여러 번 실행하고, 결과를 수집한 다음, 관찰된 격차가 실제인지 확인하기 위해 통계 분석을 수행해야 합니다. 비교 한 번에 오후 내내 걸립니다. 여러 모델에 대해 반복 실행과 유의성(significance) 검토를 포함하여 제대로 수행하려면, 돌이킬 수 없는 며칠의 시간을 허비하게 됩니다. 그러고 나면 다음 달에 세 개의 새로운 모델이 출시되고, 당신은 이 모든 과정을 다시 실행하고 싶어 하며, 실제로 그렇게 하게 됩니다.

저는 매 프로젝트마다 이 테스트 환경(harness)을 다시 구축하는 것에 지쳤고, 그래서 이를 수행해 주는 명령줄 도구(command-line tool)를 만들었습니다. 이 도구는 10개 제공업체의 모델들에 대해 동일한 프롬프트(prompts)를 나란히 실행하고, 2단계에서 언급한 통과/실패(pass-or-fail) 체크를 적용하며, 변동성을 처리하기 위해 실행을 반복합니다. 또한 신뢰 구간(confidence intervals)과 함께 유의성 검정(significance tests)을 대신 수행하여(이를 통해 실제 격차와 노이즈를 구분할 수 있습니다), 모델별 비용과 지연 시간(latency)을 추적하므로 5단계의 트레이드오프(trade-off)가 표에 바로 나타나게 됩니다. 프롬프트를 지정하고 기준을 설정하기만 하면 비교 결과가 제공됩니다.

하지만 기술(technique)이 도구(tool)보다 더 중요합니다. 이 글의 모든 내용은 소프트웨어를 사용하든, 스프레드시트와 많은 인내심을 사용하든 상관없이 작동합니다. 이 다섯 가지 단계가 바로 기술(skill)입니다. 도구는 단지 그 과정을 더 빠르게 만들어 줄 뿐이며, 새로운 모델이 출시될 때마다 동일한 배관 작업(plumbing)을 다시 작성하는 수고를 덜어줄 뿐입니다. 판단(무엇을 테스트할지, 당신에게 '더 나음'이란 무엇인지, 어떤 트레이드오프를 수용할 용의가 있는지)은 당신의 몫이며, 그래야만 합니다. 어떤 도구도 이를 대신 결정해 줄 수 없으며, 이를 대신해 준다고 주장하는 도구가 있다면 약간의 의구심을 가져야 합니다.

직접 시도해보고 싶다면, 설치는 한 번이면 충분합니다:

pip install cli-modelarium

소스 코드와 문서는 GitHub에서 확인할 수 있습니다: https://github.com/lavellehatcherjr/cli-modelarium

패키지 페이지는 PyPI에서 확인할 수 있습니다: https://pypi.org/project/cli-modelarium/

결론 (The bottom line)

리더보드 (Leaderboards)는 "좋음"이라는 일반적인 개념을 기준으로 모델의 순위를 매깁니다. 하지만 당신은 일반적인 "좋음"을 위해 무언가를 만드는 것이 아닙니다. 당신은 특정 작업 (task), 특정 제약 조건 (constraints), 특정 예산 (budget), 그리고 당신에게는 매우 치명적이지만 해당 리더보드의 거의 누구에게도 중요하지 않은 특정 실패 모드 (failure modes)를 고려하여 구축하고 있습니다.

핵심 기술은 의도적으로 행동하는 것입니다. 당신의 실제 프롬프트 (prompts)로 테스트하고, 결과를 확인하기 전에 무엇이 더 나은 것인지 정의하며, 변수 (variables)를 일정하게 유지하고, 답을 신뢰할 수 있을 만큼 충분히 반복해서 실행하며, 품질 (quality)을 비용 (cost) 및 속도 (speed)와 비교하여 가중치를 두어야 합니다. 그렇게 한다면, 때로는 비싼 최상위 순위 모델이 정말로 가장 적합하다는 것을 발견하게 될 것입니다. 하지만 더 자주 발생하는 일은, 순위표에서 5위에 묻혀 있던 더 저렴하고, 빠르고, 안정적인 무언가를 찾아내는 것입니다. 어느 쪽이든, 당신은 추측하는 대신 확실히 알게 될 것입니다.

리더보드는 시작점일 뿐입니다. 당신만의 벤치마크 (benchmark)가 정답입니다.

저는 통계, 단언 (assertions), 비용 추적 (cost tracking)을 통해 LLM 출력을 나란히 비교할 수 있는 오픈 소스 CLI인 cli-modelarium을 개발했습니다. 이 내용이 유용했다면, 해당 도구는 GitHub와 PyPI에서 동일한 이름으로 찾아보실 수 있습니다.