로컬 LLM으로 업무 자동화를 만들 때, 모델을 몇 개 써야 할까

사내에 AI를 도입하려는 회사가 가장 먼저 부딪히는 질문이 있습니다. "모델 하나면 되는 것 아닌가요?"

듀오랩스는 온프레미스 LLM만으로 도는 AI 자동화 플랫폼을 만들면서, 이 질문에 측정으로 답해야 했습니다. 결론부터 말하면 역할에 따라 여러 개가 필요하고, 큰 모델이 항상 답도 아닙니다. 이 글은 그 과정에서 나온 숫자와 판단 기준을 정리한 것입니다.

왜 이 주제가 중요한가

클라우드 AI(ChatGPT API 같은 것)를 쓰면 모델 선택을 고민할 일이 거의 없습니다. 가장 좋은 모델 하나를 쓰고 요금을 내면 됩니다.

온프레미스는 다릅니다. 회사 안에서 모델을 직접 돌리면 세 가지가 달라집니다.

1. 비용이 사용량에 비례하지 않습니다. 글자 수만큼 돈을 내지 않습니다.
2. 데이터가 회사 밖으로 나가지 않습니다. 고객 계약서나 상담 기록을 외부 API에 보내지 않아도 됩니다. 중소기업에서는 이 한 가지가 도입 여부를 가르기도 합니다.
3. 대신 모델이 덜 똑똑하고 느립니다. 온프레미스에서 돌릴 수 있는 크기의 모델은 클라우드 최상급 모델만큼 하지 못합니다.

세 번째가 핵심입니다. 그 격차를 설계로 메워야 하고, 그 첫 단계가 모델 선택입니다.

핵심 개념

모델 이름의 7b, 2.4b가 뜻하는 것

b는 billion, 파라미터(모델 내부의 조절 손잡이) 개수입니다. 7b면 70억 개입니다.

파라미터가 많을수록 대체로 똑똑하지만, 파일이 커지고 느려집니다. 24억 개짜리 모델은 파일이 1.6GB 남짓이고, 320억 개짜리는 20GB에 가깝습니다.

모델은 "쓰기 전에 올려야 하는" 무거운 파일입니다

이게 온프레미스에서 특히 중요합니다. 모델을 쓰려면 디스크에서 메모리로 통째로 올려야 하고, 크기에 따라 수십 초에서 2분까지 걸립니다. 한 번 올려두면 그다음부터는 즉시 응답합니다.

이 성질이 나중에 성능 문제의 원인이 됩니다.

자주 나오는 용어

용어	뜻
토큰	AI가 글을 세는 단위. 한국어는 대략 글자 1개가 1~2토큰
임베딩	문장을 숫자 목록으로 바꾸는 것. 뜻이 비슷하면 숫자도 비슷해져 검색에 씁니다
RAG	사내 문서를 검색해 그 내용을 근거로 답하게 하는 방식
툴 콜링	AI가 스스로 계산기·검색 같은 외부 기능을 호출하는 것
환각	AI가 근거 없는 내용을 그럴듯하게 지어내는 것
콜드 로드	모델을 메모리에 처음 올리는 것. 수십 초가 걸립니다

실제 적용 포인트

1. 역할을 나누면 작은 모델로도 충분한 자리가 보입니다

저희는 역할을 여섯 가지로 나눴습니다.

역할	하는 일	요구되는 능력
챗	대화하며 도구를 골라 씀	툴 콜링, 대화 품질
빠른 판정	문의 분류 같은 짧은 결정	속도, 일관성
구조화 추출	글에서 표 뽑기	정해진 형식 준수
한국어 생성	번역·요약·콘텐츠	문장 품질
비전	명함·영수증 사진 읽기	한글 OCR
임베딩	문서 검색용 변환	다국어 의미 이해

역할을 나누고 나면 **"이 자리는 작은 모델로 충분하다"**가 보입니다. 실제로 문의 분류는 24억 파라미터 모델이 70억·80억짜리보다 더 정확하고 3배 빨랐습니다(같은 시험 21회 기준 100% 대 90.5%).

분류는 창작이 아니라 판단이기 때문입니다. 속도가 중요한 자리에 큰 모델을 놓는 것은 낭비입니다.

2. 다만 작은 모델은 "지시문이 길어지면" 무너집니다

같은 24억 파라미터 모델을 회의록 요약에도 쓰려다 되돌렸습니다. 요구사항이 5줄(요약 + 참가자 + 결정 + 할 일 규칙)로 늘어나자 이렇게 됐습니다.

요약 결과:  "회의 주요 내용:"    ← 9글자로 끝남
결정 추출:  3건 중 3건 → 2건으로 하락

같은 지시를 준 80억 파라미터 모델은 242글자짜리 제대로 된 요약을 냈습니다.

실무 기준: 필드 서너 개짜리 단순 분류는 작은 모델, 문장 여러 개를 조건에 맞춰 써야 하는 일은 중간 크기 이상. 이 경계는 모델마다 다르니 실제 프롬프트로 시험해 봐야 압니다.

3. 큰 모델이 항상 낫지 않습니다

코드 관련 작업에 쓸 모델로 320억 파라미터와 140억 파라미터를 같은 시험으로 비교했습니다.

항목	320억	140억
SQL 생성 정확도	4/4	4/4
코드 결함 검출	4/4	4/4
질의당 시간	73~108초	16~19초
메모리 점유	20.5GB	8.4GB

정확도 이득이 0인데 5배 느리고 2.5배 무겁습니다. 큰 쪽을 탈락시켰습니다.

파라미터 수는 성능의 상한을 정할 뿐, 특정 작업의 실제 성능을 보장하지 않습니다. 작업으로 재보는 것 말고는 방법이 없습니다.

4. 설치된 모델의 절반 이상은 못 씁니다

서버에 있던 22종을 전부 같은 방식으로 돌려본 결과 8종만 통과했습니다. 탈락 사유가 도입을 검토하는 분들께 더 유용할 것 같습니다.

유형	증상
추론형 모델	답하기 전 "생각"을 길게 하는데, 그 생각이 출력 예산을 다 써서 정작 답이 0글자로 나왔습니다(93초 걸려서)
툴 문법 누출	도구를 쓸 때 get_weather(city="서울") 같은 내부 문법을 답변 본문에 그대로 출력했습니다
한글 OCR 붕괴	영수증 상호를 엉뚱한 단어로 읽고, 품목을 아예 지어냈습니다
런타임 미지원	모델 파일은 받아져 있는데 실행 엔진이 그 구조를 지원하지 않아 아예 뜨지 않았습니다
긴 대화에서 붕괴	짧은 시험은 다 통과하고, 도구 15개를 쥔 실제 대화에서 의미 없는 문자열을 뱉었습니다

마지막 항목이 특히 중요합니다. 단발 시험만 믿으면 안 됩니다. 실제 사용 형태(도구를 여러 개 쥐고, 대화를 여러 턴 이어가는)로 시험해야 드러납니다.

5. 모델이 여러 개면 "메모리에 몇 개나 올려둘 수 있나"가 성능을 좌우합니다

이번에 겪은 문제입니다. 기능을 옮겨 다닐 때 화면이 멎었습니다. 번역을 쓰다가 챗으로 가면 수십 초, 심하면 2분을 기다렸습니다.

원인은 실행 엔진(Ollama)의 동시 상주 모델 수 제한이었습니다. 기본값이 3인데, 저희는 5개가 필요했습니다.

책상에 책을 3권만 펼쳐둘 수 있는데 5권을 번갈아 봐야 하는 상황입니다. 4번째 책을 펴려면 하나를 덮어 꽂아야 하고, 그 책이 다시 필요하면 찾아서 다시 펴야 합니다. 이걸 스와핑이라고 합니다.

메모리가 부족해서가 아니라 설정이 묶여 있어서 생긴 문제였습니다. 여유가 충분한데도 3개만 올리고 있었습니다.

OLLAMA_MAX_LOADED_MODELS   기본값 3 → 필요한 수만큼
OLLAMA_KEEP_ALIVE=-1       한 번 올린 모델을 계속 유지

두 설정을 맞추자 다섯 모델이 모두 상주하고, 번갈아 써도 스와핑이 사라졌습니다.

효과를 정확히 말하면 이렇습니다.

이전:  [모델 올리기 50~126초]  +  [답 만들기]
지금:  [모델 올리기 0초]        +  [답 만들기]

기능	이전	지금
문의 스코어링(표 4행)	53초	25초
클레임 분류(표 5행)	7초	7초

모든 게 빨라진 게 아니라, 스와핑에 당하던 것만 빨라졌습니다. 두 번째 기능은 원래 상주 중이었기에 얻을 것이 없었습니다. 표를 많이 만드는 작업은 여전히 시간이 걸립니다 — 그건 글자를 하나씩 생성하는 시간이라 상주와 무관합니다.

체감은 여러 기능을 오갈 때 가장 큽니다.

주의할 점

실패가 조용한 것이 가장 위험합니다

한글 OCR이 무너진 모델은 오류를 내며 멈추지 않았습니다. 그럴듯한 거짓 데이터를 만들어냈습니다. 영수증 상호를 잘못 읽어도 화면은 멀쩡해 보입니다.

그래서 정답을 아는 자료로 검증해야 합니다. 저희는 정답이 정해진 가상 영수증·명함을 만들어 필드별로 채점했습니다. "그럴듯해 보인다"로는 절대 판단할 수 없습니다.

형식만 지키고 내용을 빠뜨리는 경우가 있습니다

AI에게 정해진 표 형식으로 답하게 하는 기법(스키마 강제)을 쓸 때, 모델이 일부 칸을 통째로 빠뜨리는 일이 있었습니다. 형식 검사는 통과하는데 표에 빈 칸이 생깁니다.

모든 항목을 필수로 지정하고 **"값이 없으면 빈 칸으로 두고 지어내지 마라"**를 함께 지시하니 해결됐습니다. 한쪽만 하면 안 됩니다 — 필수 지정만 하면 모델이 빈 칸을 채우려고 값을 만들어냅니다.

모델이 신뢰성 있게 못 하는 판단은 단정적으로 보여주지 마세요

문서 두 버전을 비교해 "이 변경이 누구에게 불리한가"를 판정하는 기능을 만들었습니다. 조항을 찾고 무엇이 달라졌는지 정리하는 것은 정확했지만, 유불리 방향은 5건 중 2건을 틀렸습니다. 계약 당사자 관계를 추론해야 하는 판단이라 어려웠습니다.

프롬프트를 세 번 고쳐도 남았습니다. 네 번째 시도 대신 표시를 바꿨습니다 — "위험"을 "위험(참고)"로 하고 "최종 판단은 사람이 하세요"를 명시했습니다.

계약서 검토에서 틀린 빨간 표시는 없는 것보다 나쁩니다. AI 기능을 설계할 때 "얼마나 정확한가"만큼 **"틀렸을 때 어떻게 보이는가"**가 중요합니다.

프롬프트를 두 번 고쳐도 안 되면 설계를 의심하세요

가상 데이터를 만드는 기능이 이상한 값을 냈습니다. 금지 문구를 넣고, 구체적 예시까지 넣었는데도 재현됐습니다. 세 번째에 원인을 다시 보니 프롬프트가 아니라 구조 문제였습니다 — 칼럼이 매번 달라지는 데이터를 고정된 3칼럼 틀에 억지로 밀어 넣고 있었습니다. 틀을 바꾸니 바로 해결됐습니다.

프롬프트 조정은 빠르게 시도할 수 있어서 계속 붙잡기 쉽습니다. 두 번 실패하면 한 발 물러서서 구조를 보는 편이 빠릅니다.

듀오랩스가 보는 관점

온프레미스 AI 도입을 검토하시는 분들께 이 글에서 가져가실 만한 것은 세 가지입니다.

첫째, "어떤 모델이 제일 좋냐"는 질문보다 "어떤 일을 시킬 것이냐"가 먼저입니다. 일을 역할로 쪼개면 작은 모델로 충분한 자리가 드러나고, 그만큼 서버 부담과 응답 시간이 줄어듭니다.

둘째, 모델 선택은 벤치마크 점수가 아니라 실제 업무로 재야 합니다. 저희가 탈락시킨 모델 중에는 공개 벤치마크 성적이 좋은 것도 있었습니다. 한국어 영수증을 읽히거나 도구를 쥐여주고 대화를 시켜보면 결과가 달라집니다.

셋째, 도입 후에도 측정이 남아야 합니다. 저희는 모든 AI 실행을 기록으로 남깁니다(어떤 모델로, 몇 초, 성공/실패). 이번 스와핑 문제도 그 기록에서 "왜 이 기능만 유독 느리지?"를 발견한 것이 시작이었습니다. 측정되지 않는 것은 개선되지 않습니다.

---

저희는 이 원칙들을 실제로 도는 플랫폼으로 확인하고 있습니다. 모델 선택·역할 배치·측정 방식은 고객사 환경에 그대로 이식할 수 있는 형태로 정리해 두었습니다. 온프레미스 AI 도입을 검토 중이시라면 편하게 문의해 주세요.