초보자를 위한 모델 선택법

온디바이스 LLM에서 초보자가 가장 많이 하는 실수는 의외로 설치가 아닙니다. 모델을 너무 크게 고르는 것입니다.

처음에는 누구나 비슷한 마음입니다. "가장 성능 좋은 모델을 받으면 되지 않을까?" 그런데 로컬 환경에서는 이 생각이 자주 함정이 됩니다. 서버실에서는 큰 모델이 정의일 수 있지만, 내 노트북과 데스크톱에서는 이야기가 다릅니다. 좋은 결과의 절반은 '내 장비에 맞는 모델'을 고르는 데서 결정됩니다.

쉽게 말해 보겠습니다. 모델 선택은 운동화 고르기와 비슷합니다. 기록이 가장 좋은 신발이 아니라, 내 발에 맞고 내가 실제로 뛸 수 있는 신발이 좋은 신발입니다. LLM도 마찬가지입니다. 벤치마크 1등 모델보다, 내 RAM과 VRAM 안에서 안정적으로 돌아가고, 내가 원하는 작업을 꽤 잘 해내는 모델이 더 좋은 선택입니다.

이 장에서는 초보자가 헷갈리기 쉬운 다섯 가지를 차례대로 정리합니다.

• 모델 크기를 읽는 법

• 디스크 크기와 실행 메모리를 구분하는 법

• 한국어 성능을 보는 기준

• 라이선스를 확인하는 습관

• Q4·Q5·Q8 같은 양자화 수준을 고르는 기준

목표는 단순합니다.

"무슨 모델을 받아야 하지?"라는 막막함을, "내 경우엔 이 정도가 맞겠구나"라는 판단으로 바꾸는 것입니다.

1단계: 먼저 모델 이름보다 사용 목적을 적자

모델을 고르기 전에 가장 먼저 해야 할 일은 허깅페이스를 여는 것이 아닙니다. 내가 이 모델로 무엇을 할지 한 문장으로 적는 것입니다.

이 순서가 중요한 이유는, 같은 LLM이라도 잘하는 일이 조금씩 다르기 때문입니다. 어떤 모델은 한국어 대화가 자연스럽고, 어떤 모델은 코드와 구조화 출력이 강하고, 어떤 모델은 작은 크기 대비 속도가 뛰어납니다. 그래서 "좋은 모델"이라는 말만으로는 부족합니다. 정확히는 "내 작업에 좋은 모델"이어야 합니다.

예를 들어 목적은 대략 이렇게 나뉩니다.

• 개인용 로컬 챗봇

• 문서 요약과 Q&A

• 코드 작성 보조

• RAG용 답변 생성

• 구조화 출력과 API 응답

문서 요약 도구를 만들 사람과, 코딩 보조를 만들 사람은 같은 모델을 골라도 만족도가 다릅니다. 한국어 문서 요약이 목적이라면 한국어 이해력과 문체 안정성이 중요하고, 로컬 API 서버가 목적이라면 구조화 출력과 형식 준수 성향이 더 중요합니다.

초보자에게는 아주 단순한 문장을 권합니다.

"나는 이 모델로 무엇을, 어느 기기에서, 어느 정도 속도로 하고 싶은가?"

이 한 줄이 정해지면, 그다음부터는 모델 후보를 버리는 일이 쉬워집니다. 모델 선택은 최고를 찾는 과정이라기보다, 나와 안 맞는 후보를 빠르게 제외하는 과정에 가깝습니다.

2단계: 파라미터 수를 보고 대략적인 체급부터 잡자

모델 이름 뒤에 붙는 3B, 7B, 8B, 14B, 32B 같은 숫자는 보통 파라미터 수 규모를 뜻합니다. 아주 거칠게 말하면, 숫자가 클수록 모델이 더 많은 표현력을 가질 가능성이 있지만, 그만큼 메모리와 연산량도 커집니다.

초보자에게는 복잡한 이론보다 체급 감각이 먼저 필요합니다.

0.5B~4B급: 가벼운 입문용

이 체급은 "일단 내 기기에서 돌아가게 해 보자"에 잘 맞습니다. 메모리가 빠듯한 PC, 구형 노트북, 모바일·엣지 실험에서는 매우 소중합니다. 다만 답변의 깊이, 긴 문맥 유지, 복잡한 추론은 더 큰 모델보다 아쉬울 수 있습니다.

작은 모델은 장난감 같아 보여도, 용도를 좁히면 의외로 쓸 만합니다. 짧은 질답, 간단한 분류, 초안 작성, UI 보조 문구 생성처럼 역할을 좁히면 충분히 실용적일 수 있습니다.

7B~9B급: 가장 무난한 실전 입문 체급

이 구간은 지금도 로컬 LLM의 대표적인 출발점입니다. 이유는 간단합니다. 품질과 자원 요구량의 균형이 좋기 때문입니다.¹²

적절히 양자화한 7B~8B급 모델은 일반적인 노트북과 데스크톱에서도 충분히 시도할 수 있고, 대화·요약·기초 코드 보조까지 꽤 넓은 범위를 커버합니다. 초보자라면 대부분 이 구간에서 첫 성공 경험을 만드는 것이 좋습니다.

12B~14B급: 품질은 올라가지만 장비 부담도 커진다

이쯤부터는 "확실히 더 낫다"는 느낌이 오는 경우가 많습니다. 특히 구조화 출력, 추론, 코드, 긴 문서 처리에서는 7B~8B보다 나은 경우가 자주 보입니다. 대신 메모리 여유가 부족한 장비에서는 속도와 안정성이 금방 나빠질 수 있습니다.

즉, 이 체급은 무조건 좋은 것이 아니라 장비가 받쳐 줄 때 빛나는 선택입니다.

27B~32B급 이상: 품질 욕심이 날 때 보이는 체급

이 구간은 매력적입니다. 하지만 온디바이스 입문자에게는 자주 과한 선택입니다. 메모리와 발열, 속도, 초기 설정 난이도까지 생각하면 첫 실습부터 피곤해질 확률이 높습니다.

처음에는 큰 모델을 동경하기 쉽지만, 실제로 자주 쓰는 모델은 한 단계 작은 모델인 경우가 많습니다. 빠르고, 덜 뜨겁고, 덜 까다롭기 때문입니다.

3단계: 디스크 크기와 실행 가능 크기는 다르다

여기서 초보자가 자주 넘어집니다. 모델 파일이 4.5GB니까 메모리도 4.5GB면 되겠다고 생각하는 순간입니다. 실제로는 그렇지 않습니다.

실행할 때는 모델 파일만 있는 것이 아닙니다. 추가 작업 메모리, 프롬프트 처리 버퍼, 컨텍스트, 그리고 특히 KV 캐시까지 고려해야 하므로 실제 요구량은 더 커집니다.¹

그래서 모델 선택에서는 파일 크기만 보지 말고, 이렇게 생각해야 합니다.

"내 장비가 이 모델 파일을 저장할 수 있는가?"보다 "이 모델을 여유 있게 계속 돌릴 수 있는가?"

초보자를 위한 아주 거친 출발선은 이 정도면 충분합니다.

이 표는 절대 법칙이 아닙니다. 하지만 초보자에게는 "내가 지금 어느 체급을 봐야 하는지"를 빠르게 정해 주는 지도 역할을 합니다.

4단계: 한국어 성능은 '다국어 지원' 한 줄로 판단하면 안 된다

한국어 사용자는 여기서 한 번 더 생각해야 합니다. 모델 카드에 "multilingual"이라고 적혀 있다고 해서, 한국어가 정말 자연스럽고 안정적이라는 뜻은 아닙니다.

한국어는 단순 번역체 출력만 잘하면 끝나는 언어가 아닙니다. 높임말, 문장 종결, 조사, 맥락 압축, 한국식 업무 문서 표현 같은 요소가 많습니다. 그래서 한국어 실사용 품질은 영어 벤치마크 점수만 보고 판단하기 어렵습니다.

초보자에게는 모델 이름을 외우기보다 비교 기준을 먼저 잡는 편이 더 안전합니다.

한국어 품질을 볼 때 체크할 것

• 답변이 번역투가 심하지 않은가

• 존댓말/반말이 흔들리지 않는가

• 조사와 문장 종결이 어색하지 않은가

• 한국어 문서 요약에서 숫자·고유명사를 잘 보존하는가

• 같은 질문을 영어보다 한국어로 넣었을 때 품질 차이가 너무 크지 않은가

이 기준은 모델 카드보다 실제 샘플 대화에서 더 잘 드러납니다. 즉, 한국어 모델 평가는 "이 모델이 유명한가"보다 "내가 실제로 넣을 한국어 질문에서 잘 버티는가"를 봐야 합니다.

한국어 최우선 vs 범용성 우선

실전에서는 보통 두 갈래 판단이 필요합니다.

• 한국어 문장 자연스러움이 최우선이면 한국어 평가가 좋은 모델을 먼저 본다

• 도구 호출, 코드, 구조화 출력, 넓은 생태계가 중요하면 범용성이 강한 글로벌 모델 계열을 먼저 본다

둘 중 어느 쪽이 중요한지 먼저 정하지 않으면, 추천 글을 많이 볼수록 더 헷갈리게 됩니다.

5단계: 라이선스를 안 보면, 기술보다 먼저 프로젝트가 멈춘다

초보자가 모델을 고를 때 가장 자주 놓치는 것이 라이선스입니다. 그런데 실무에서는 성능보다 먼저 문제가 되는 경우도 많습니다.

여기서 아주 중요한 원칙 하나만 먼저 기억하세요.

GGUF 파일을 누가 변환해서 올렸는지는 라이선스를 바꾸지 않습니다.

즉, 허깅페이스에서 어떤 사용자가 친절하게 GGUF를 만들어 배포했다고 해도, 실제 사용 조건은 원본 모델 라이선스를 따라갑니다.

최소한 아래 네 가지는 꼭 확인하는 습관을 들이세요.

라이선스 문서는 재미없습니다. 하지만 읽지 않으면 더 큰 재미없는 일이 생깁니다.

6단계: 초보자의 기본값은 'Instruct + GGUF + Q4_K_M'이다

이제 양자화 이야기로 들어가겠습니다. 이미 앞 장에서 GGUF와 양자화의 큰 그림을 봤다면, 여기서는 "그래서 뭘 받으면 되느냐"에 집중하면 됩니다.

먼저 아주 실전적인 결론부터 말하겠습니다.

초보자의 첫 선택은 보통 Instruct 모델의 GGUF, 그리고 Q4_K_M 양자화입니다.

왜 하필 이 조합일까요?

Instruct 모델은 사람의 지시를 따르도록 다듬어진 버전이라, 채팅과 질문 응답에서 훨씬 다루기 쉽습니다. 반대로 Base 모델은 원석에 가깝습니다. 로컬 실습 첫날에는 원석보다 완성형이 낫습니다.

그리고 Q4_K_M은 llama.cpp 생태계에서 오랫동안 가장 무난한 기본값으로 자리 잡은 양자화 중 하나입니다. 파일 크기를 크게 줄이면서도 품질 손실을 비교적 잘 억제해, 입문용 로컬 실행에 잘 맞습니다.¹³

7단계: Q4, Q5, Q8은 이렇게 고르면 된다

양자화는 어려워 보이지만, 초보자는 세 가지만 먼저 익히면 됩니다.

Q4_K_M: 가장 추천되는 출발점

Q4_K_M은 보통 크기와 품질의 균형이 가장 좋다고 평가됩니다. 대부분의 일반 대화·요약·질답 작업에서 충분히 실용적입니다.¹³

이런 경우에 특히 좋습니다.

• 일단 돌아가게 하고 싶다

• 16GB 안팎 장비에서 시작한다

• 처음이라 비교 기준이 없다

Q5_K_M: 여유가 있다면 품질을 한 단계 올리는 선택

Q5_K_M은 Q4보다 조금 더 크고 무겁지만, 품질 손실이 덜한 편입니다. 코드, 추론, 문장 안정성에서 더 낫다고 느끼는 경우가 많습니다.¹³

장비에 여유가 있고, 첫 실습에서 이미 Q4가 잘 돌아간다면 다음 비교 대상으로 가장 좋은 후보가 Q5_K_M입니다.

Q8_0: 품질은 좋지만 초보자 기본값은 아니다

Q8_0은 원본에 가까운 품질을 노릴 수 있지만, 파일이 커지고 자원 사용도 늘어납니다. 그래서 Q8_0은 "품질 비교용"이나 "메모리가 넉넉한 장비"에서 더 어울립니다. 첫 선택으로는 다소 무거울 수 있습니다.

8단계: 한국어에서는 너무 낮은 비트 양자화를 더 조심하자

실전 비교에서는 한국어가 공격적인 양자화에 더 민감하게 느껴지는 경우가 자주 있습니다. 특히 Q3 이하로 내려가면 한국어 문장 자연스러움, 조사 안정성, 답변 밀도에서 아쉬움이 커질 수 있습니다.

이 말은 "Q3가 절대 나쁘다"가 아닙니다. 정말 메모리가 부족한 환경에서는 Q3도 소중합니다. 다만 한국어 품질이 중요하다면 Q4_K_M을 기본선으로 잡고, 가능하면 Q5_K_M까지 비교해 보는 편이 안전하다는 뜻입니다.

9단계: 사용 목적별로 모델을 고르는 빠른 기준

이제 가장 궁금한 질문으로 들어가 보겠습니다.

"그래서 내 경우엔 뭘 받으면 되나요?"

경우 1: 일단 내 PC에서 첫 성공을 만들고 싶다

이 경우에는 욕심을 줄이는 것이 정답입니다. 4B 안팎 또는 7B~8B Instruct GGUF를 보고, 양자화는 Q4_K_M부터 시작하세요. 이 단계에서는 최고의 품질보다 실행 성공, 속도 감각, 프롬프트 반응 확인이 더 중요합니다.

경우 2: 한국어 대화와 문서 요약이 가장 중요하다

한국어 샘플을 꼭 직접 넣어 보세요. 모델 카드의 "multilingual" 표기만 믿기보다, 실제 한국어 문체와 숫자 보존, 요약 안정성을 확인하는 편이 훨씬 중요합니다.

경우 3: JSON, 형식 준수, 에이전트 구성이 중요하다

이 경우에는 모델 카드에 구조화 출력, tool calling, function calling 같은 힌트가 있는지 먼저 보세요. 한국어 문장 맛보다 형식 일관성이 더 중요할 수 있습니다.

경우 4: 코딩 보조나 논리적인 답변이 중요하다

Q5_K_M 이상을 고려할 가치가 큽니다. 코드와 추론 쪽은 양자화 차이가 체감으로 나타나는 경우가 있어, Q4에서 아쉽다면 Q5로 한 단계 올려 보는 것이 좋습니다.³

경우 5: 모바일·엣지에 가까운 작은 장비다

이때는 큰 모델을 억지로 밀어 넣는 것보다, 처음부터 0.5B~4B급 소형 모델을 보는 편이 훨씬 현실적입니다. 온디바이스에서는 "작지만 빠르고 꾸준한 모델"이 "크지만 거의 못 쓰는 모델"보다 훨씬 낫습니다.

10단계: 초보자를 위한 추천 조합 예시

아래 표는 아주 실전적인 출발점입니다. 정답표는 아니지만, 첫 모델을 고를 때 방향을 잡아 줍니다.

이 표의 핵심은 화려한 모델 이름이 아닙니다. 내 장비와 내 목적이 먼저다라는 원칙입니다.

11단계: 모델 카드에서 꼭 봐야 할 체크포인트

허깅페이스 페이지를 열었을 때, 초보자는 종종 다운로드 버튼만 봅니다. 하지만 실제로는 아래 항목을 먼저 보는 습관이 훨씬 중요합니다.

Instruct인지 Base인지

대부분의 로컬 챗봇, 요약, 문답 실습은 Instruct가 더 적합합니다. Base 모델은 튜닝 재료에 가깝습니다.

GGUF가 준비되어 있는지

llama.cpp를 바로 쓸 생각이라면 GGUF 파일이 잘 정리되어 있는지부터 확인하세요. 파일명에 양자화 종류가 명확히 적혀 있으면 더 좋습니다.

라이선스가 무엇인지

성능보다 먼저 봐야 하는 항목입니다. 상업 여부가 조금이라도 걸려 있다면 반드시 읽어야 합니다.

컨텍스트 길이와 용도

문서 요약, RAG, 긴 회의록 처리처럼 입력이 길다면 컨텍스트 길이도 봐야 합니다. 하지만 초보자는 긴 숫자에 너무 현혹되기보다, 내 장비가 그 설정을 감당하는지를 같이 봐야 합니다.

커뮤니티와 양자화본 관리 상태

GGUF가 여러 양자화로 잘 제공되고, 사용자 후기가 많은 모델은 초보자에게 훨씬 유리합니다. 문제를 만났을 때 참고할 정보가 많기 때문입니다.

12단계: 초보자가 특히 자주 하는 모델 선택 실수

여기서는 피해야 할 함정을 짚어 보겠습니다.

첫 번째 실수는 가장 큰 모델이 가장 좋은 선택이라고 믿는 것입니다. 실제로는 한 단계 작은 모델이 더 자주, 더 안정적으로, 더 만족스럽게 쓰이는 경우가 많습니다.

두 번째 실수는 영어권 추천 모델을 그대로 가져오는 것입니다. 영어에서 좋은 평가를 받아도 한국어 문체나 맥락에서는 아쉬울 수 있습니다.

세 번째 실수는 라이선스를 나중에 보자고 미루는 것입니다. 개인 실험이라면 괜찮아 보여도, 프로젝트가 커질수록 발목을 잡습니다.

네 번째 실수는 Q8이면 무조건 좋고 Q4면 무조건 나쁘다고 생각하는 것입니다. 로컬에서는 Q4_K_M이 오히려 가장 현명한 선택인 경우가 많습니다.¹³

다섯 번째 실수는 Base 모델을 받아 놓고 왜 답이 이상한지 고민하는 것입니다. 초보자의 첫 실습은 거의 항상 Instruct가 더 낫습니다.

13단계: 결국 가장 안전한 선택 공식은 이것이다

지금까지를 한 줄 공식으로 줄이면 이렇습니다.

상업 여부를 먼저 정하고 → 장비 체급을 보고 → 한국어 우선인지 범용 우선인지 고르고 → Instruct GGUF를 선택한 뒤 → Q4_K_M으로 시작하고 필요하면 Q5_K_M으로 올린다.

이 순서대로 고르면, 적어도 "왜 이 모델을 받았는지 나도 모르겠다"는 상태는 피할 수 있습니다.

초보자에게 가장 추천하는 출발 전략은 아주 단순합니다.

첫째, 7B~8B급 Instruct 모델을 본다.

둘째, 한국어가 중요하면 한국어 샘플을 직접 비교한다.

셋째, 상업 목적이면 라이선스를 먼저 통과시킨다.

넷째, 양자화는 Q4_K_M부터 시작한다.

다섯째, 만족스럽지 않으면 모델 체급을 올리기 전에 Q5_K_M을 먼저 비교해 본다.

이렇게 가면 불필요한 시행착오가 크게 줄어듭니다.

정리: 모델 선택은 기술이 아니라 예산 배분이다

온디바이스 LLM에서 모델 선택은 단순한 취향 문제가 아닙니다. 메모리 예산, 속도 예산, 품질 예산, 라이선스 예산을 나누는 일에 가깝습니다.

조금 더 큰 모델을 쓰면 품질이 올라갈 수 있습니다. 하지만 속도와 안정성이 희생될 수 있습니다. 더 높은 양자화 품질을 쓰면 답변은 좋아질 수 있습니다. 하지만 메모리 부담이 늘어납니다. 한국어에 강한 모델을 고르면 문장이 자연스러울 수 있습니다. 하지만 다른 기능이나 생태계가 약할 수 있습니다.

즉, 모델 선택은 정답 찾기가 아니라 균형 잡기입니다.

그리고 초보자에게 가장 좋은 균형점은 대개 여기서 시작합니다.

7B~8B급 Instruct GGUF, Q4_K_M, 그리고 내 목적에 맞는 모델 계열 하나.

이 출발점만 잘 잡아도 로컬 LLM 구축의 첫 고비는 이미 절반 넘게 넘은 셈입니다.

다음 장에서는 이제 이 모델을 실제로 돌릴 준비를 하겠습니다. Windows, macOS, Linux, Android에서 llama.cpp 환경을 어떻게 갖추는지, 어디서부터 손대면 덜 헤매는지 차근차근 들어가 보겠습니다.

참고

¹llama.cpp quantization documentation

²Which Quantization Should I Use? A Unified Evaluation of llama.cpp Quantization on Llama-3.1-8B-Instruct

³Complete Guide: Q4 Q5 Q8 Quantization Explained