주요 LLM 계열 한눈에 보기: 무엇이 어떻게 다른가

"어떤 모델이 제일 좋나요"라는 질문에는 답하기 어렵습니다. 작업에 따라 답이 달라지고, 답이 나오는 속도로 상황이 바뀌기 때문입니다. 오늘 1위인 모델이 다음 달에도 1위라는 보장이 없고, 순위표에서 앞선 모델이 실제 업무에서 더 낫다는 보장도 없습니다.

더 유용한 질문은 "모델들은 어떤 축에서 다른가" 입니다. 축을 알면 새 모델이 나와도 자기 기준으로 판단할 수 있습니다. 이 글은 개별 모델의 순위를 매기는 대신 그 축을 정리합니다.

이 글에는 벤치마크 점수, 가격, 컨텍스트 길이 같은 구체적인 수치가 없습니다. 의도적으로 뺐습니다. 이런 값은 수시로 바뀌므로 각 제공사의 공식 문서에서 직접 확인하시는 편이 정확합니다. 여기서는 바뀌지 않는 구분 기준을 다룹니다.

가장 큰 갈림길: 가중치를 받을 수 있는가

모델을 나누는 가장 실질적인 기준은 성능이 아니라 배포 방식입니다. 이 선택이 비용 구조, 데이터 흐름, 운영 부담, 법적 검토 범위를 모두 바꿉니다.

API로만 제공되는 모델은 제공사의 서버에서 실행됩니다. 사용자는 네트워크로 요청을 보내고 결과를 받습니다. 모델 파일 자체는 공개되지 않습니다. 대표적으로 Anthropic의 Claude, OpenAI의 GPT, Google의 Gemini 계열이 여기에 해당합니다.

가중치가 공개된 모델은 파일을 내려받아 자체 인프라에서 실행할 수 있습니다. Meta의 Llama, Mistral, Qwen, Google의 Gemma 계열 등이 있습니다. 상당수는 API 형태로도 제공되므로 두 방식을 함께 쓸 수 있습니다.

데이터가 외부로 나갈 수 없는 환경이라면 이 선택은 성능 비교보다 먼저 결정됩니다. 반대로 트래픽이 불규칙하고 운영 인력이 적다면 API가 현실적입니다.

같은 계열 안의 크기 구분

대부분의 제공사는 한 계열 안에 여러 크기를 둡니다. 이름은 다르지만 구조는 비슷합니다.

• 대형 — 어려운 추론, 복잡한 지시, 긴 문맥 처리에 강합니다. 느리고 비쌉니다.
• 중형 — 대부분의 실무 작업에 적당한 균형점입니다.
• 소형 — 분류, 추출, 요약처럼 범위가 좁은 작업에 적합합니다. 빠르고 저렴합니다.

흔한 실수는 모든 작업에 가장 큰 모델을 쓰는 것입니다. 고객 문의를 카테고리로 분류하는 데 최고급 모델을 쓸 이유는 없습니다. 작업별로 다른 모델을 배치하는 라우팅 구조가 비용과 속도를 크게 개선하는 경우가 많습니다.

반대 실수도 있습니다. 여러 단계의 추론이 필요한 작업에 소형 모델을 쓰고 프롬프트만 계속 고치는 경우입니다. 모델 급을 한 단계 올리면 바로 해결되는 문제를 오래 붙들게 됩니다.

계열별 성향 차이

같은 급이라도 계열마다 성향이 다릅니다. 이 차이는 사전학습·파인튜닝·정렬의 데이터와 정책에서 나옵니다.

답변 길이와 형식. 어떤 모델은 묻지 않아도 구조화된 긴 답을 내놓고, 어떤 모델은 짧게 답합니다. 프롬프트로 조정할 수 있지만 기본 성향은 남습니다.

지시 준수 방식. 제약을 엄격히 지키는 쪽과 맥락을 살펴 유연하게 해석하는 쪽이 있습니다. 정해진 형식이 중요하면 전자가, 모호한 요청을 다루려면 후자가 편합니다.

거절 범위. 같은 요청에도 모델마다 거절 여부가 다릅니다. 의료·법률·보안처럼 민감한 주제를 다루는 서비스라면 실제 요청 샘플로 미리 확인해야 합니다.

한국어 품질. 영어 성능과 한국어 성능이 비례하지 않습니다. 맞춤법, 존댓말 일관성, 한국 고유 맥락 이해에서 차이가 납니다. 반드시 한국어 실제 입력으로 직접 테스트해야 합니다.

코드 성향. 설명을 많이 붙이는 모델과 코드만 내놓는 모델, 최신 문법을 즐겨 쓰는 모델과 보수적인 모델이 있습니다.

선택할 때 실제로 봐야 할 축

순위표 대신 다음을 확인하세요. 대부분 공식 문서에서 찾을 수 있습니다.

입력 형태. 텍스트만 되는지, 이미지·PDF·음성을 받는지. 문서 처리가 필요하다면 필수 조건입니다.

컨텍스트 길이. 한 번에 넣을 수 있는 분량입니다. 다만 길다고 항상 좋은 것은 아닙니다. 컨텍스트 윈도우에서 다룹니다.

구조화 출력 지원. JSON 스키마 강제, 함수 호출 지원 여부. 시스템에 연결하려면 중요합니다.

스트리밍. 사용자 대면 서비스라면 체감 속도에 직접 영향을 줍니다.

데이터 취급 정책. 입력이 학습에 쓰이는지, 보관 기간은 얼마인지, 리전 선택이 가능한지. 기업 환경에서는 성능보다 먼저 확인할 항목입니다.

버전 고정. 모델이 조용히 업데이트되면 그동안 맞춰 둔 프롬프트가 깨질 수 있습니다. 특정 버전을 고정할 수 있는지, 구 버전 지원 기간은 어떻게 되는지 확인하세요.

지역과 지연시간. 서버 위치에 따라 응답 속도가 달라집니다.

벤치마크를 믿기 어려운 이유

공개 벤치마크는 참고 지표일 뿐 선택 근거로는 약합니다.

오염 문제. 벤치마크 문제가 학습 데이터에 섞여 들어가면 점수가 실력을 반영하지 않습니다. 웹에 공개된 데이터셋일수록 이 위험이 큽니다.

작업 불일치. 수학 경시 문제를 잘 푸는 능력이 사내 문서 요약 품질과 직결되지 않습니다.

언어 차이. 대부분의 주요 벤치마크가 영어 기준입니다. 한국어 성능을 보장하지 않습니다.

측정 조건 차이. 프롬프트 형식, 샘플링 설정, 시도 횟수에 따라 점수가 달라집니다. 같은 모델도 조건에 따라 다른 숫자가 나옵니다.

실무 선택 순서

1. 제약 조건을 먼저 확정합니다. 데이터를 외부로 보낼 수 있는가, 예산 상한은 얼마인가, 응답 시간 요구는 어느 정도인가. 여기서 후보가 크게 줄어듭니다.
2. 필수 기능을 확인합니다. 이미지 입력, 구조화 출력, 스트리밍 등 없으면 안 되는 것들.
3. 후보 2~3개로 좁힙니다. 남은 후보 중 중형급을 기본으로 놓습니다.
4. 자체 평가셋으로 비교합니다. 실제 입력으로 품질·속도·비용을 함께 측정합니다.
5. 작업별로 나눕니다. 전체를 한 모델로 통일할 필요는 없습니다. 간단한 작업은 소형으로 내리면 비용이 줄어듭니다.
6. 교체 가능하게 설계합니다. 특정 모델에 강하게 묶이지 않도록 호출부를 추상화해 두면 나중에 갈아타기 쉽습니다.

모델 이름을 읽는 법

모델 이름에는 선택에 필요한 정보가 생각보다 많이 들어 있습니다. 표기 방식은 제공사마다 다르지만 대체로 다음 요소로 구성됩니다.

• 계열 이름 — 제품군을 나타냅니다.
• 세대나 버전 번호 — 숫자가 클수록 새 세대인 경우가 일반적이지만, 제공사마다 번호 체계가 달라 계열 간 비교에는 쓸 수 없습니다.
• 크기 등급 — 같은 세대 안의 대·중·소를 구분하는 이름이나 숫자입니다.
• 날짜나 스냅샷 표기 — 특정 시점에 고정된 버전을 뜻합니다.

실무에서 특히 중요한 것은 고정 버전과 별칭(alias)의 차이입니다. latest처럼 최신 버전을 가리키는 별칭을 쓰면 제공사가 모델을 교체할 때 호출 결과가 조용히 달라질 수 있습니다. 프로덕션에서는 날짜가 붙은 고정 버전을 쓰고, 교체는 평가를 거친 뒤 의도적으로 하는 편이 안전합니다.

preview, experimental, beta 같은 표기가 붙은 모델은 예고 없이 바뀌거나 종료될 수 있습니다. 실험에는 좋지만 서비스의 기본 모델로 두기에는 위험이 있습니다.

흔한 오해

"파라미터가 크면 무조건 낫다." 크기는 여러 요인 중 하나입니다. 학습 데이터의 질, 학습 방법, 정렬 품질이 함께 작용합니다. 잘 만들어진 중형 모델이 대충 만든 대형 모델보다 나은 경우가 흔합니다.

"한 모델로 통일해야 관리가 쉽다." 호출부를 잘 추상화했다면 작업별로 다른 모델을 쓰는 편이 비용과 품질 모두에 유리한 경우가 많습니다.

"최신 모델이 항상 낫다." 새 모델이 특정 작업에서는 이전 버전보다 못한 경우도 있습니다. 교체 전에 자체 평가셋으로 확인해야 합니다.

정리

• 모델을 나누는 가장 실질적인 기준은 성능이 아니라 API 전용인가 공개 가중치인가입니다.
• 한 계열 안의 대·중·소형은 작업 난이도에 맞춰 골라야 하며, 모든 작업에 대형을 쓸 이유는 없습니다.
• 계열마다 답변 길이, 지시 준수 방식, 거절 범위, 한국어 품질에 성향 차이가 있습니다.
• 선택 시에는 입력 형태, 컨텍스트, 구조화 출력, 데이터 정책, 버전 고정을 확인하세요.
• 공개 벤치마크는 오염·작업 불일치·언어 차이 때문에 선택 근거로 약합니다.
• 자기 데이터로 만든 평가셋이 가장 믿을 만하며, 모델 교체 시 회귀 테스트로도 쓰입니다.

참고 자료

• Anthropic — 모델 개요 문서 — Claude 계열 사양과 선택 기준
• Hugging Face — Open LLM 모델 허브 — 공개 가중치 모델과 라이선스 확인
• Google Machine Learning Crash Course — LLM — 모델 규모와 성능의 관계