어떤 LLM을 고를까

RAG를 만들 때 큰 결정 하나가 어떤 LLM을 쓸 것인가다. 성능·기능·비용이 제각각인 수많은 모델이 있고, 선택은 시스템의 속도·품질·예산에 큰 영향을 준다. 이번 편은 정량 지표로 후보를 좁히고, 품질 벤치마크로 최종 선택하는 방법을 정리한다.

 

 

1. 정량화하기 쉬운 지표

먼저 쉽게 수치화되는 차이들이다.

• 모델 크기(parameters) — 소형은 10~100억, 대형은 1,000~5,000억 이상. 대형이 대체로(항상은 아님) 더 뛰어나지만 항상 더 비싸다.
• 비용 — 보통 100만 토큰당 고정 가격이며 입력·출력 토큰 가격이 다를 수 있다. 새롭고 크고 유능한 모델일수록 비싸다.
• context window — LLM이 프롬프트+completion을 합쳐 처리할 수 있는 최대 토큰 수. 한도가 커도 토큰당 과금은 그대로다.
• 지연(latency) — 첫 토큰까지 시간, 초당 토큰 수. 실시간 상호작용이 중요하면 다른 성능을 조금 양보하더라도 빠른 모델을 택할 수 있다.
• 학습 컷오프(training cutoff) — 학습 데이터가 반영하는 마지막 시점. RAG라도 최신 컷오프가 대체로 유리하다(특히 최근 사건을 다뤄야 할 때).

그림 1. 정량 지표 — 모델 크기, 비용, context window, 지연, 학습 컷오프.

 

 

 

2. 정량화하기 어려운 것 — 품질

정량 지표는 후보를 좁히는 데 도움이 되지만, 정작 가장 중요한 건 품질이고 이건 수치화가 훨씬 어렵다. 여기서 품질은 복잡한 수학 추론 능력부터 읽기 좋은 텍스트를 만드는 것까지 모두를 뜻한다. 이 여러 차원을 비교하려고 수많은 벤치마크가 존재한다. 단일 권위 있는 목록은 없지만, 어떤 종류가 있는지 알면 내 프로젝트에 맞는 것을 고를 수 있다.

그림 2. 품질은 다면적이고 벤치마크도 많다. 단일 권위 목록은 없고, 크게  3가지 유형 으로 나뉜다.

 

 

 

3. 자동 벤치마크 (Automated)

첫 유형은 자동 벤치마크다. 코드로 채점 가능한 과제로 점수를 매긴다 — 특정 분야의 객관식 시험이나, 답을 컴퓨터가 쉽게 검증하는 수학·코딩 문제 같은 것들이다. 대표 예가 MMLU(Massive Multitask Language Understanding)로, STEM·인문·법률 등 57개 과목을 객관식으로 다룬다. 모델 제공사가 마케팅에 자주 인용하므로 프로젝트에 맞는 것을 찾기 쉽다.

그림 3. 자동 벤치마크 — 코드로 채점(객관식·수학·코딩). 예: MMLU(57개 과목).

 

 

 

4. 사람 평가 벤치마크 (Human-scored)

두 번째는 사람 평가다. 보통 익명의 두 LLM이 같은 프롬프트에 답하게 하고, 사람 평가자가 더 나은 답을 고른다. 그 결과를 체스 순위에 쓰는 ELO 알고리즘에 넣어 비교 리더보드를 만든다. 대표 호스트가 LLM Arena로, 가장 널리 인용되는 순위 중 하나다. 사람 평가는 자동 벤치마크가 잡기 어려운 미묘한 품질을 포착한다. 둘이 대체로 일치하지만, 엇갈릴 때 성능의 중요한 뉘앙스가 드러난다.

그림 4. 사람 평가 — 익명 두 모델을 비교시켜 선호를 고르고 ELO로 순위화(예: LLM Arena).

 

 

 

5. LLM-as-a-judge

세 번째는 LLM-as-a-judge다. 한 LLM이 다른 LLM의 답을 채점한다. 심판 LLM은 기준 정답(reference answers)을 갖고, 평가 대상이 정답에 얼마나 가까운 답을 내는지로 승률(win rate)을 산출해 모델을 비교한다. 장점은 싸고 유연하다는 것. 단점은 심판을 세심히 보정해야 한다는 것 — 심판은 자기 계열 모델의 답을 선호하는 경향이 있다(OpenAI GPT는 GPT를, Google Gemini는 Gemini를). 재보정으로 이 편향을 줄일 수 있다.

그림 5. LLM-as-a-judge — 심판 LLM이 기준 정답과 비교해 승률을 낸다. 싸고 유연하나 자기 계열 선호 편향 주의.

 

 

 

6. 좋은 벤치마크의 조건

• 관련성 — 내 프로젝트와 무관한(예: 코드 안 만드는데 코드 생성) 벤치마크는 도움이 안 된다.
• 난이도 — 모든 모델이 잘 보면 변별력이 없다. 고/저 성능을 구분할 만큼 어려워야 한다.
• 재현성 — 실행마다 점수가 크게 흔들리지 않고, 제공사가 인용한 결과가 검증 가능해야 한다.
• 실제 성능과 정합 — 프로그래밍 벤치마크에서 잘하면 실제로도 코드를 잘 짜야 한다.

주의할 함정이 데이터 오염(data contamination)이다. LLM은 인터넷에서 긁은 수조 토큰으로 학습하므로, 벤치마크 데이터셋이 학습 데이터에 포함됐을 수 있다. 그러면 이미 문제·답을 본 셈이라 과대 성능을 보인다. 실제 성능과의 정합은 개발자 포럼 등을 확인해 검증할 필요가 있다.

그림 6. 좋은 벤치마크 — 관련성·난이도·재현성·실제 성능 정합. 데이터 오염을 조심한다.

 

 

 

7. 벤치마크 포화 — 빠르게 낡는다

대부분의 eval에서 반복되는 패턴이 있다. 처음엔 평균 점수가 낮다가, 불과 몇 년 만에 모델들이 인간 전문가 수준에 도달한다. 이렇게 거의 모든 상위 모델이 만점 근처를 받으면 그 벤치마크는 포화(saturated)됐다고 하고, 변별력을 잃는다. 그러면 더 어려운 새 벤치마크가 도입되지만 그것도 곧 포화된다. 핵심은 오늘 나온 모델이 몇 년 전보다 훨씬 낫고, 지금 고른 모델도 언젠가 더 나은 모델로 교체해야 한다는 것이다.

그림 7. 벤치마크는 시간이 지나면 포화된다 — 새로운 모델은 대체로 옛 모델을 능가한다.

 

결론. LLM 선택은 중요하지만 한시적인 결정이다. 비용·지연 같은 정량 지표로 후보를 좁히고, 다양한 품질 지표로 용도에 맞는 모델을 고른다. 모델이 워낙 빨리 좋아지므로, 언젠가 새 모델로 교체할 것을 전제로 설계하는 편이 낫다.

 

다음 글부터는 고른 LLM을 실제로 다루는 프롬프트 엔지니어링으로 넘어간다 — 먼저 검색된 맥락으로 augmented prompt를 구성하는 방법이다.