23장. 로컬 AI 모델 선택하기

1. 로컬 AI에서 모델 선택이 중요한 이유

앞 장에서는 로컬 LLM 실행 환경을 만드는 방법을 살펴보았다.

Ollama, LM Studio, llama.cpp 같은 도구를 사용하면 개발 PC나 사내 서버에서 로컬 모델을 실행할 수 있다.
간단한 질문을 던져보고, API 서버 형태로 호출하고, 백엔드와 연결하는 기본 구조도 이해했다.

이제 다음 질문이 생긴다.

어떤 모델을 써야 할까?

로컬 AI에서는 모델 선택이 매우 중요하다.

클라우드 AI를 사용할 때는 제공자가 모델 실행 환경을 관리해준다.
개발자는 모델명을 고르고 API를 호출하면 된다.

하지만 로컬 AI에서는 모델 선택이 곧 실행 가능 여부와 품질, 속도, 메모리 사용량을 결정한다.

예를 들어 다음과 같은 차이가 생긴다.

작은 모델:
내 PC에서도 실행 가능
응답 속도 빠름
하지만 복잡한 추론은 약할 수 있음

큰 모델:
답변 품질이 좋을 수 있음
하지만 많은 RAM이나 VRAM 필요
응답 속도가 느릴 수 있음

로컬 모델을 고를 때는 단순히 “가장 유명한 모델”을 고르면 안 된다.

다음 기준을 함께 봐야 한다.

- 내 하드웨어에서 실행 가능한가
- 한국어 답변 품질이 괜찮은가
- 코드 작업에 강한가
- 요약이나 분류에 적합한가
- RAG 답변에 잘 맞는가
- 라이선스상 사내 사용이나 상업적 사용이 가능한가
- 응답 속도와 동시 처리 성능은 충분한가

로컬 AI 모델 선택은 성능만의 문제가 아니다.

우리 업무, 데이터, 하드웨어, 보안 정책, 운영 방식에 맞는 모델을 고르는 과정이다.

2. 로컬 LLM 모델의 기본 분류

로컬에서 사용할 수 있는 LLM은 매우 많다.

처음 보면 모델 이름만 봐도 복잡하다.

Llama
Mistral
Qwen
Gemma
Phi
DeepSeek
Code Llama
StarCoder
Yi

모델마다 특징이 다르고, 같은 계열 안에서도 크기와 버전이 다양하다.

초보자는 먼저 큰 분류부터 이해하는 것이 좋다.

로컬 LLM은 대략 다음 기준으로 나눌 수 있다.

1. 일반 대화형 모델
2. 코드 특화 모델
3. 한국어 또는 다국어 성능이 좋은 모델
4. 경량 모델
5. 긴 컨텍스트 모델
6. 임베딩 모델

각 모델 유형은 쓰임새가 다르다.

여기서 주의할 점이 있다.

생성형 LLM과 임베딩 모델은 역할이 다르다.

생성형 LLM은 답변을 만든다.

질문:
하트 충전 후 반영되지 않을 때 어떻게 안내해야 해?

생성형 LLM:
고객에게 결제 승인 여부와 충전 반영 상태를 확인하도록 안내해야 합니다.

임베딩 모델은 답변을 만들지 않는다.
문장이나 문서를 숫자 벡터로 바꿔 검색에 사용한다.

문서
→ 임베딩 모델
→ 벡터
→ 유사도 검색

RAG를 만들려면 보통 둘 다 필요하다.

임베딩 모델:
관련 문서 검색

생성형 LLM:
검색된 문서를 바탕으로 답변 생성

로컬 AI 모델을 선택할 때는 “답변 생성용 모델”과 “검색용 임베딩 모델”을 구분해야 한다.

3. Llama 계열 모델

Llama 계열은 로컬 LLM을 이야기할 때 가장 자주 등장하는 모델 계열 중 하나다.

오픈소스 LLM 생태계에서 널리 사용되고, 여러 도구에서 지원하며, 다양한 크기와 변형 모델이 존재한다.

Llama 계열이 많이 사용되는 이유는 다음과 같다.

- 로컬 실행 도구에서 지원이 좋다.
- 사용자와 커뮤니티가 많다.
- 다양한 크기의 모델이 있다.
- 여러 파생 모델과 튜닝 모델이 존재한다.
- 일반 대화, 요약, RAG 실험에 두루 사용하기 좋다.

예를 들어 처음 로컬 AI를 실험할 때 Llama 계열의 작은 모델을 사용하면 기본적인 대화와 요약을 테스트하기 쉽다.

사용 예:
- 개발 개념 설명
- 고객 문의 요약
- 내부 문서 요약
- 간단한 RAG 답변 생성
- 문장 다듬기

하지만 Llama 계열이라고 해서 모든 모델이 똑같이 좋은 것은 아니다.

모델 크기, 튜닝 방식, 양자화 수준에 따라 품질과 속도가 달라진다.

작은 Llama 계열 모델:
개인 PC에서 실행하기 쉬움
속도 빠름
복잡한 추론은 제한적

큰 Llama 계열 모델:
품질 좋을 수 있음
더 많은 메모리 필요
운영 서버 필요 가능성 높음

또 한국어 품질은 모델 버전과 튜닝에 따라 다르다.

영어 답변은 괜찮은데 한국어 설명이 어색할 수 있다.
반대로 다국어 성능이 개선된 모델은 한국어 답변이 꽤 자연스러울 수 있다.

따라서 Llama 계열을 사용할 때는 직접 테스트해야 한다.

테스트 질문:
- 한국어 기술 설명
- 고객 문의 요약
- 우리 서비스 도메인 용어
- JSON 응답 형식
- 문서에 없는 내용 거절

Llama 계열은 로컬 AI의 기본기를 익히기에 좋은 선택지다.
하지만 운영에 쓰기 전에는 반드시 업무 데이터로 검증해야 한다.

4. Mistral 계열 모델

Mistral 계열 모델도 로컬 AI에서 많이 사용된다.

Mistral 계열은 상대적으로 효율적인 모델로 알려져 있고, 작은 크기에서도 준수한 성능을 내는 모델들이 있다.

로컬 환경에서는 “내 하드웨어에서 얼마나 빠르게 쓸 수 있는가”가 중요하다.
그런 점에서 효율적인 모델은 장점이 있다.

Mistral 계열이 잘 맞을 수 있는 작업은 다음과 같다.

- 간단한 요약
- 문장 정리
- 짧은 분류
- 내부 도구용 챗봇
- 개발 보조 실험
- RAG 답변 생성 실험

예를 들어 관리자 도구에서 신고 내용을 간단히 분류하는 기능을 만든다고 해보자.

입력:
사용자가 욕설이 포함된 채팅을 신고함

출력:
{
  "category": "abuse",
  "priority": "medium"
}

이런 작업은 매우 큰 모델이 아니어도 가능할 수 있다.

다만 Mistral 계열도 한국어 품질은 모델에 따라 차이가 있다.
영어 중심 데이터에서 강한 모델은 한국어 업무에 바로 쓰기 어려울 수 있다.

따라서 다음 항목을 테스트해야 한다.

- 한국어 질문 이해력
- 한국어 답변 자연스러움
- JSON 형식 준수
- 요약 품질
- 도메인 용어 처리
- RAG에서 참고 문서만 사용하는지

Mistral 계열은 경량성과 효율성을 고려할 때 좋은 후보가 될 수 있다.
하지만 한국어 서비스에 적용할 때는 반드시 한국어 기준으로 평가해야 한다.

5. Qwen 계열 모델

Qwen 계열은 다국어와 코드 작업에서 자주 언급되는 모델 계열이다.

로컬 AI에서 Qwen 계열을 검토하는 이유는 다음과 같다.

- 다국어 성능이 좋은 모델들이 있다.
- 코드 관련 작업에 강한 변형 모델들이 있다.
- 다양한 크기의 모델이 제공된다.
- 로컬 실행 환경에서 많이 테스트된다.

한국어를 포함한 다국어 작업을 고려한다면 Qwen 계열은 후보에 넣어볼 만하다.

예를 들어 다음 기능을 생각해볼 수 있다.

- 한국어 고객 문의 요약
- 한영 번역 초안
- 한국어 개발 문서 요약
- 코드 설명
- JSON 기반 분류
- RAG 답변 생성

Qwen 계열 중 코드 특화 모델을 사용하면 코드 작성이나 설명에 도움이 될 수 있다.

사용 예:
- 함수 설명
- SQL 쿼리 분석
- 코드 리팩토링 제안
- 테스트 케이스 초안 생성
- 에러 로그와 코드 흐름 연결

다만 코드 특화 모델이라고 해서 모든 개발 업무를 잘하는 것은 아니다.

코드는 문법만 맞으면 되는 것이 아니다.

- 기존 아키텍처와 맞는가
- 비즈니스 로직을 이해했는가
- 보안 문제가 없는가
- 성능상 문제는 없는가
- 테스트가 가능한 구조인가

AI가 만든 코드는 반드시 사람이 검토해야 한다.

Qwen 계열은 로컬 AI에서 꽤 실용적인 선택지가 될 수 있지만, 다른 모델과 마찬가지로 하드웨어, 품질, 라이선스를 함께 검토해야 한다.

6. 코드 특화 모델

개발자가 로컬 AI를 사용하는 대표적인 이유 중 하나는 코드 작업이다.

코드 특화 모델은 일반 대화형 모델보다 코드 생성, 코드 설명, 리팩토링, 버그 분석에 초점을 맞춘 모델이다.

대표적으로 다음 작업에 사용할 수 있다.

- 함수 설명
- 코드 주석 생성
- 테스트 코드 초안
- 리팩토링 제안
- SQL 쿼리 설명
- 에러 메시지 분석
- 코드 리뷰 보조

예를 들어 다음과 같은 요청을 할 수 있다.

아래 PHP 코드를 읽고,
개인정보가 로그에 남을 가능성이 있는 부분을 찾아줘.

또는 다음처럼 쓸 수 있다.

아래 SQL 쿼리의 성능상 문제를 설명하고,
인덱스 관점에서 개선 방향을 제안해줘.

코드 특화 모델은 내부 코드가 외부로 나가지 않게 하려는 목적에도 잘 맞는다.

내부 소스 코드
→ 로컬 코드 모델
→ 코드 설명 또는 리뷰 초안

하지만 코드 특화 모델을 사용할 때는 특히 조심해야 한다.

AI가 제안한 코드는 그럴듯해 보이지만 실제로는 틀릴 수 있다.

- 컴파일되지 않을 수 있다.
- 라이브러리 사용법이 틀릴 수 있다.
- 보안 처리가 빠질 수 있다.
- 기존 코드 스타일과 맞지 않을 수 있다.
- 비즈니스 로직을 잘못 이해할 수 있다.

따라서 코드 특화 모델은 “자동 개발자”가 아니라 “코드 검토 보조자”로 보는 것이 안전하다.

코드 특화 모델을 평가할 때는 다음 질문을 던져보면 좋다.

- 우리 언어 스택을 잘 이해하는가?
- PHP, Go, TypeScript, SQL 등 실제 사용하는 언어에서 품질이 어떤가?
- 프레임워크 관례를 잘 따르는가?
- 보안 취약점을 잘 찾아내는가?
- 테스트 코드가 실제로 실행 가능한가?
- 없는 라이브러리나 가짜 API를 만들어내지 않는가?

로컬 코드 모델은 내부 코드 보호에는 유리하다.
하지만 품질 검증 없이 운영 코드에 반영하면 위험하다.

7. 한국어 성능을 반드시 확인해야 한다

로컬 AI 모델을 선택할 때 한국어 성능은 매우 중요하다.

영어 벤치마크에서 성능이 좋은 모델이라도 한국어 실무 문서에서는 품질이 떨어질 수 있다.

한국어 성능이 부족하면 다음 문제가 생긴다.

- 질문 의도를 잘못 이해한다.
- 답변이 어색하다.
- 기술 용어를 이상하게 번역한다.
- 존댓말과 반말이 섞인다.
- 한국어 문서 요약에서 핵심을 놓친다.
- 도메인 용어를 엉뚱하게 해석한다.

예를 들어 방송 플랫폼에서 “하트”, “후원”, “방송”, “BJ”, “충전”, “환불” 같은 용어는 일반적인 의미와 서비스 도메인 의미가 섞여 있다.

AI가 이를 일반 단어로만 이해하면 잘못된 답변을 할 수 있다.

질문:
하트 충전 후 반영이 안 될 때 고객센터 안내문 작성해줘.

나쁜 답변:
마음의 상처를 치유하는 방향으로 안내...

좋은 답변:
결제 승인 여부와 서비스 내 하트 충전 반영 상태를 확인하도록 안내...

한국어 성능은 직접 테스트해야 한다.

테스트 문항은 실제 업무에 가까워야 한다.

- 고객 문의 요약
- 운영 공지 초안
- 장애 보고서 요약
- 개발 문서 설명
- 정책 문서 질의응답
- 채팅 메시지 분류
- 방송 도메인 용어 설명

또 문체도 확인해야 한다.

- 너무 딱딱하지 않은가
- 너무 가볍지 않은가
- 관리자 문서에 맞는 문체인가
- 고객 안내문으로 쓸 수 있는가
- 기술 문서로 자연스러운가

한국어 서비스에 로컬 AI를 적용하려면, 모델 벤치마크보다 실제 한국어 업무 샘플 테스트가 더 중요하다.

8. 모델 크기와 하드웨어 요구사항

로컬 AI 모델을 선택할 때 모델 크기는 매우 중요하다.

모델 이름에 붙는 7B, 8B, 14B, 32B 같은 표현은 모델의 파라미터 수를 의미한다.

7B:
약 70억 개 파라미터

14B:
약 140억 개 파라미터

32B:
약 320억 개 파라미터

일반적으로 모델이 클수록 더 복잡한 패턴을 처리할 가능성이 있다.
하지만 실행에 필요한 메모리와 연산량도 증가한다.

단순화하면 다음과 같다.

물론 모델 크기만으로 품질이 결정되지는 않는다.

좋은 데이터로 튜닝된 작은 모델이, 목적에 맞지 않는 큰 모델보다 나을 수도 있다.

하지만 로컬 실행에서는 크기가 곧 현실적인 제약이다.

모델이 너무 크면:
- 실행이 안 될 수 있다.
- 응답이 매우 느릴 수 있다.
- GPU VRAM이 부족할 수 있다.
- 동시 요청을 처리하기 어렵다.

처음에는 7B 또는 8B급 모델로 시작하는 것이 좋다.

처음 실습:
7B~8B급 모델

품질 비교:
14B급 모델

서버 검토:
32B 이상 모델

고성능 운영:
GPU 서버와 동시성 설계 필요

하드웨어도 함께 봐야 한다.

CPU:
모델 실행은 가능하지만 느릴 수 있음

RAM:
모델을 메모리에 올리는 데 필요

GPU:
응답 속도를 높이는 데 중요

VRAM:
큰 모델을 GPU에서 실행할 때 핵심

저장공간:
모델 파일을 보관하는 데 필요

로컬 AI 모델 선택은 “좋은 모델을 고르는 일”이 아니라 “내 환경에서 실제로 쓸 수 있는 모델을 고르는 일”이다.

9. 양자화 모델을 이해해야 한다

로컬 AI에서 자주 등장하는 개념이 양자화다.

양자화는 모델이 사용하는 숫자의 정밀도를 줄여서 메모리 사용량을 낮추는 방식이다.

쉽게 말하면 큰 모델을 더 가볍게 실행하기 위한 기술이다.

원본 모델은 많은 메모리를 필요로 한다.

원본 모델:
메모리 사용량 큼
품질 좋음
실행 부담 큼

양자화 모델은 더 적은 메모리로 실행할 수 있다.

양자화 모델:
메모리 사용량 작음
개인 PC에서도 실행 가능
품질은 일부 손실 가능

모델 파일 이름에 Q4, Q5, Q8 같은 표현이 붙는 경우가 있다.

대략적으로 이해하면 다음과 같다.

처음 로컬 모델을 실행할 때는 Q4나 Q5 양자화 모델을 많이 사용한다.

왜냐하면 개인 PC나 일반 개발 장비에서 실행하기 쉽기 때문이다.

하지만 중요한 작업에서는 품질도 확인해야 한다.

Q4 모델:
빠르고 가벼움
하지만 정확성이 중요한 작업에서는 품질 저하 가능

Q8 모델:
더 무겁지만 답변 품질이 나을 수 있음
하드웨어 여유가 필요

양자화 수준에 따른 차이는 모델마다 다르다.
무조건 Q8이 좋고 Q4가 나쁘다고 단정하면 안 된다.

실무에서는 같은 질문 세트로 비교하는 것이 좋다.

같은 모델의 Q4, Q5, Q8 비교:
- 응답 품질
- 응답 속도
- 메모리 사용량
- JSON 형식 준수
- 한국어 답변 자연스러움

양자화는 로컬 AI를 현실적으로 사용할 수 있게 해주는 중요한 기술이다.
하지만 품질 손실 가능성을 이해하고 사용해야 한다.

10. 라이선스 확인은 필수다

오픈소스 모델이라고 해서 모든 용도로 자유롭게 사용할 수 있는 것은 아니다.

로컬 AI 모델을 선택할 때는 라이선스를 반드시 확인해야 한다.

특히 사내 업무 도구나 외부 사용자 서비스에 적용할 계획이라면 더 중요하다.

모델 라이선스에서 확인해야 할 항목은 다음과 같다.

- 상업적 사용이 가능한가
- 사내 업무 도구에 사용할 수 있는가
- 외부 사용자에게 서비스로 제공할 수 있는가
- 모델을 수정하거나 재배포할 수 있는가
- 출력 결과 사용에 제한이 있는가
- 특정 규모 이상의 기업 사용 제한이 있는가
- 별도 고지 의무가 있는가

개인 테스트에서는 문제가 되지 않던 모델도, 회사 서비스에 붙이면 문제가 될 수 있다.

개인 실험:
로컬에서 모델 테스트

사내 도구:
직원들이 업무에 사용

외부 서비스:
고객이나 사용자에게 AI 기능 제공

각 단계마다 라이선스 검토 수준이 달라져야 한다.

특히 모델을 외부 사용자 서비스에 사용할 경우에는 법무나 보안 담당자와 함께 확인하는 것이 좋다.

라이선스 확인을 소홀히 하면 나중에 모델 교체가 필요할 수 있다.

이미 서비스에 적용
→ 라이선스 제한 발견
→ 모델 교체 필요
→ 품질 재검증
→ 운영 리스크 발생

따라서 모델 후보를 고를 때는 성능과 함께 라이선스를 초기부터 확인해야 한다.

11. 작업별 모델 선택 기준

모델은 작업에 따라 다르게 선택해야 한다.

하나의 모델로 모든 작업을 처리하려고 하면 품질이나 비용, 속도에서 손해를 볼 수 있다.

고객 문의 요약

고객 문의 요약에는 한국어 이해력과 요약 품질이 중요하다.

중요 기준:
- 한국어 자연스러움
- 핵심 문제 파악
- 개인정보 포함 방지
- 짧은 답변 생성
- 추정하지 않는 태도

너무 큰 모델이 반드시 필요한 것은 아니다.
중간 크기의 모델로도 충분할 수 있다.

채팅 메시지 분류

채팅 메시지 분류는 빠른 응답과 일관성이 중요하다.

중요 기준:
- 빠른 응답
- 짧은 입력 처리
- 정해진 category 반환
- JSON 형식 준수
- 대량 처리 가능성

이 작업은 작은 모델이나 경량 모델이 잘 맞을 수 있다.

장애 로그 분석

장애 로그 분석은 단순 요약보다 어렵다.

중요 기준:
- 로그 패턴 이해
- 원인과 추정 구분
- 확인 항목 제시
- 근거 없는 단정 방지
- 긴 입력 처리

가능하면 더 품질 좋은 모델을 사용하거나, 로그를 먼저 정제한 뒤 모델에 전달하는 것이 좋다.

코드 리뷰

코드 리뷰는 코드 특화 모델을 고려할 수 있다.

중요 기준:
- 사용하는 언어 이해
- 프레임워크 관례 이해
- 보안 취약점 탐지
- 테스트 관점 제안
- 가짜 API 생성 방지

코드 리뷰 결과는 반드시 사람이 검토해야 한다.

RAG 답변 생성

RAG에서는 검색된 문서를 근거로 답해야 한다.

중요 기준:
- 참고 문서만 사용
- 문서에 없는 내용 거절
- 출처 표시
- 긴 문맥 처리
- 질문 의도 파악

RAG 모델은 지시를 잘 따르는지가 중요하다.
문서 밖 내용을 자꾸 지어내는 모델은 RAG에 적합하지 않다.

12. 모델 평가용 질문 세트 만들기

모델을 선택할 때는 직접 평가해야 한다.

인터넷에서 본 평가표나 모델 순위만 믿으면 안 된다.
우리 업무에 맞는 질문으로 테스트해야 한다.

모델 평가용 질문 세트를 만들어두면 좋다.

예를 들어 다음과 같이 구성할 수 있다.

1. 고객 문의 요약 20건
2. 채팅 메시지 분류 20건
3. 장애 로그 분석 10건
4. 코드 설명 10건
5. SQL 성능 분석 10건
6. 문서 기반 질문 20건
7. 모르는 질문 10건
8. JSON 응답 테스트 20건

각 질문에는 평가 기준을 붙인다.

평가 기준:
- 답변이 정확한가
- 핵심을 빠뜨리지 않았는가
- 불필요한 추정을 하지 않았는가
- 한국어가 자연스러운가
- JSON 형식을 지키는가
- 응답 시간이 적절한가
- 민감 정보를 포함하지 않는가

예를 들어 RAG용 평가 질문은 이렇게 만들 수 있다.

참고 문서:
하트 환불은 사용 전 상태에서만 가능하다.
이미 사용한 하트는 환불할 수 없다.

질문:
이미 사용한 하트도 환불할 수 있나요?

기대 답변:
제공된 문서 기준으로 이미 사용한 하트는 환불할 수 없다고 답해야 한다.

모르는 질문도 반드시 넣어야 한다.

참고 문서:
충전 미반영 처리 절차만 제공

질문:
다음 달 이벤트 일정 알려줘.

기대 답변:
제공된 문서에서는 확인할 수 없다고 답해야 한다.

AI 모델은 아는 질문에 답하는 능력만큼, 모르는 질문을 거절하는 능력도 중요하다.

13. 모델 선택 결과를 기록해야 한다

모델을 테스트한 뒤에는 결과를 기록해야 한다.

테스트할 때는 좋아 보였는데, 나중에 왜 그 모델을 선택했는지 기억하지 못하면 문제가 된다.

모델 평가 기록에는 다음을 남기면 좋다.

예를 들어 다음처럼 기록할 수 있다.

모델:
example-llm-8b-q5

용도:
고객 문의 요약, 간단한 분류

평가 결과:
한국어 요약은 자연스러움.
JSON 분류는 20건 중 18건 성공.
긴 장애 로그 분석은 품질 부족.
응답 속도는 개발 PC 기준 평균 5초.

판단:
고객 문의 요약 PoC 후보로 사용.
장애 분석 용도로는 부적합.

이런 기록이 있으면 나중에 모델을 교체하거나 개선할 때 도움이 된다.

모델 A에서 모델 B로 변경
→ 같은 평가 세트로 비교
→ 품질, 속도, 메모리 사용량 비교
→ 변경 여부 결정

모델 선택은 한 번으로 끝나지 않는다.
모델은 계속 나오고, 하드웨어도 바뀌고, 업무 요구사항도 바뀐다.

따라서 평가 기록을 남기는 습관이 중요하다.

14. 처음 로컬 모델을 고를 때 추천하는 접근

처음 로컬 AI를 시작할 때는 욕심을 줄이는 것이 좋다.

처음부터 가장 큰 모델을 돌리려고 하면 설치와 성능 문제에 막힐 수 있다.

추천하는 접근은 다음과 같다.

1. 작은 모델로 로컬 실행 흐름을 익힌다.
2. 한국어 질문과 요약을 테스트한다.
3. JSON 응답과 RAG 지시 준수를 확인한다.
4. 같은 질문을 여러 모델에 던져본다.
5. 속도와 품질을 비교한다.
6. 모델 크기를 조금씩 키워본다.
7. 실제 업무 데이터로 평가한다.
8. 용도별 후보 모델을 나눈다.

예를 들어 다음처럼 나눌 수 있다.

개인 개발 실습:
가벼운 7B~8B급 모델

고객 문의 요약 PoC:
한국어 요약 품질이 좋은 중간 모델

코드 분석:
코드 특화 모델

RAG:
지시 준수와 문서 기반 답변이 좋은 모델

민감 로그 분석:
내부 서버에서 실행 가능한 모델

처음부터 “우리 회사 표준 모델”을 정하려고 하지 않아도 된다.

먼저 작업별로 후보를 정하고, 실제 업무 샘플로 테스트하면서 좁혀가는 것이 좋다.

15. 정리

로컬 AI에서 모델 선택은 매우 중요하다.

클라우드 AI와 달리 로컬 AI는 모델을 직접 실행해야 하므로, 모델 품질뿐 아니라 하드웨어 요구사항, 응답 속도, 메모리 사용량, 라이선스까지 함께 봐야 한다.

Llama 계열은 로컬 AI 실험과 일반 대화, 요약, RAG에 널리 사용된다.
Mistral 계열은 효율적인 모델 후보로 볼 수 있다.
Qwen 계열은 다국어와 코드 작업에서 검토할 만하다.
코드 특화 모델은 내부 코드 설명, 리뷰, 테스트 코드 생성에 활용할 수 있다.

하지만 어떤 계열이든 한국어 성능은 반드시 직접 테스트해야 한다.
우리 서비스의 도메인 용어, 고객 문의, 운영 로그, 개발 문서에 대해 실제로 쓸 만한지 확인해야 한다.

모델 크기도 중요하다.
7B, 14B, 32B 같은 크기는 품질뿐 아니라 실행 가능 여부와 연결된다.
양자화 모델은 적은 메모리로 실행할 수 있게 해주지만, 품질 손실 가능성도 있다.

또한 오픈소스 모델을 사내 도구나 외부 서비스에 사용하려면 라이선스를 확인해야 한다.

모델 선택은 감으로 하면 안 된다.
작업별 평가 질문 세트를 만들고, 응답 품질, 속도, JSON 준수율, RAG 적합성, 한국어 품질, 라이선스를 기록해야 한다.

이 장에서 기억해야 할 핵심은 하나다.

로컬 AI 모델 선택은 “가장 유명한 모델을 고르는 일”이 아니라,
우리 하드웨어에서 실행 가능하고, 우리 업무 데이터에서 쓸 만한 모델을 찾는 과정이다.

23장 핵심 요약