데스크톱 프로그램에 로컬 LLM을 넣을까 — 설치 파일이 수 GB가 되는 딜레마

PART 01왜 이게 딜레마인가: 가벼움이 내 프로그램의 정체성이다

내가 만드는 프로그램들은 가볍고 빠른 걸 내세운다. 메모 앱 BoltMemo는 앱 크기 약 1MB, 실행 0.054초 수준을 앞에 걸어 두었다. 이런 숫자를 내세우는 이유는 분명하다. 사용자가 무거운 프로그램에 질려서 대안을 찾다가 내 프로그램에 오기 때문이다.

그런데 로컬 LLM은 정반대의 물건이다. 모델 파일 자체가 무겁다. 번역을 그럭저럭 해내는 크기의 모델만 해도 수 GB다. 프로그램 본체가 수십 MB인데 모델이 그 백 배쯤 되는 상황이 된다. 설치 파일을 받다가 "이게 PDF 편집기 맞나" 싶어지는 순간, 지금까지 쌓은 인상이 한 번에 무너진다.

위 모델 크기는 정확한 값이 아니라 흔히 보이는 범위다. 같은 파라미터 수라도 양자화 방식과 모델 구조에 따라 수백 MB씩 차이가 난다. 그래도 방향은 분명하다. 작게 갈수록 번역 품질이 눈에 띄게 떨어지고, 쓸 만한 품질을 원하면 GB 단위를 피할 수 없다.

PART 02모델 크기와 품질, 그리고 하드웨어 편차

로컬 번역의 품질은 모델 크기에 크게 좌우된다. 이건 일반적으로 알려진 경향이다. 1B급 모델은 짧은 문장은 그럭저럭 옮기지만, 전문 용어가 섞인 문서나 긴 문단에서는 문맥을 놓치기 쉽다. 7~8B급으로 올라가야 "읽을 만한" 번역에 가까워진다는 게 많은 사람들의 경험이다.

더 골치 아픈 건 하드웨어다. 같은 모델이라도 GPU가 있는 PC와 CPU만 있는 PC의 속도 차이가 크다. CPU만으로 돌리면 한 페이지 번역에도 한참 기다려야 할 수 있다. 요즘 나오는 NPU 탑재 노트북은 또 다른 경로가 필요하고, 지원 수준도 제조사와 드라이버마다 제각각이다. 내 프로그램을 쓰는 PC 사양이 넓게 퍼져 있다는 걸 생각하면, "누구에게나 비슷한 경험"을 약속하기 어렵다.

실행 엔진도 고려해야 한다. 로컬 모델을 돌리는 대표적인 방법은 llama.cpp 계열 엔진이고, Ollama 같은 도구는 그걸 쓰기 쉽게 감싸서 로컬 서버로 띄워 준다. 엔진을 내 프로그램에 직접 넣으면 그 엔진의 업데이트와 GPU 지원까지 내가 책임져야 한다. 엔진 하나 넣는 일이 생각보다 큰 약속이라는 뜻이다.

PART 03네 가지 선택지 비교

결국 로컬 LLM 기능을 넣는 방법은 네 가지로 좁혀진다. 본체에 모델을 같이 넣는 방법, 모델을 따로 받게 하는 방법, 사용자가 이미 돌리는 로컬 서버에 연결하는 방법, 그리고 아예 클라우드 API를 쓰는 방법이다.

(1) 본체에 번들: 제일 쉬워 보이고 제일 나쁘다

사용자 입장에서는 설치하면 바로 되니까 편하다. 하지만 번역을 안 쓰는 대다수 사용자까지 수 GB를 받아야 한다. PDF 편집만 하려는 사람에게 번역 모델을 강제로 떠안기는 셈이다. 업데이트도 문제다. 프로그램 본체의 작은 버그 하나를 고쳐도, 설치 파일 구조에 따라서는 수 GB를 다시 내려받게 될 수 있다. 나는 이 방식은 고려 대상에서 뺐다.

(2) 선택형 모델 팩: 원하는 사람만 받는다

기본 설치는 지금처럼 가볍게 두고, 번역 기능을 켜려는 사람에게만 "모델 팩을 받으시겠습니까"를 묻는 방식이다. 팩을 크기별로 두 개쯤 두면 저사양 PC 사용자는 작은 팩을, 품질을 원하는 사람은 큰 팩을 고를 수 있다. 팩은 본체와 별도로 갱신하니까 본체 업데이트가 가볍게 유지된다. 대신 내가 엔진과 모델 배포를 책임져야 해서 손이 많이 간다.

(3) 이미 가진 로컬 서버 연결: 이미 해 본 방식

이 방식은 낯설지 않다. 내가 만든 한칸(HanKan, 엑셀 대체 AI 스프레드시트)은 이미 사용자가 가진 AI 서버나 API 키를 연결하는 방식을 지원한다. vLLM 같은 OpenAI 호환 서버 주소를 넣으면 그쪽 모델을 쓴다. API 키는 Windows 자격 증명 관리자에 보관한다. Ollama도 OpenAI 호환 엔드포인트를 제공하니, 같은 구조로 붙일 수 있다.

// OpenAI 호환 엔드포인트에 번역 요청을 보내는 최소 예시
async function translate(baseUrl, model, text, apiKey) {
  const res = await fetch(baseUrl.replace(/\/$/, '') + '/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      ...(apiKey ? { Authorization: 'Bearer ' + apiKey } : {}),
    },
    body: JSON.stringify({
      model,
      temperature: 0.2,
      messages: [
        { role: 'system', content: '다음 글을 자연스러운 한국어로 번역하라. 서식은 유지하라.' },
        { role: 'user', content: text },
      ],
    }),
  })
  if (!res.ok) throw new Error('번역 서버 응답 오류: ' + res.status)
  const data = await res.json()
  return data.choices[0].message.content
}

// 예: 같은 PC에서 돌아가는 로컬 서버
// translate('http://localhost:11434', 'some-model', pageText)

이 방식의 장점은 프로그램이 전혀 무거워지지 않는다는 점이다. 모델 선택, GPU 활용, 업데이트는 전부 사용자 쪽 서버가 맡는다. 단점도 분명하다. 일반 사용자에게 "로컬 서버를 띄우고 주소를 넣으라"는 건 진입 장벽이 높다. 이미 Ollama 같은 도구를 쓰는 사람에게는 최고의 방식이지만, 그렇지 않은 사람에게는 사실상 없는 기능이다.

(4) 클라우드 API: 편하지만 이 요청의 핵심을 놓친다

품질만 보면 클라우드 API가 가장 좋을 수 있다. 설치 크기도 안 늘고 저사양 PC에서도 빠르다. 하지만 이번 요청은 "인터넷 없이"였다. 그 조건을 정면으로 어긴다.

PART 04내가 고른 방향: 기본은 가볍게, 모델은 원하는 사람만

네 가지를 따져 본 뒤 내 입장은 정리됐다. 본체 번들은 하지 않는다. 클라우드 API는 이미 있는 AI 도우미 같은 기능에는 쓸 수 있어도, "오프라인 번역"이라는 이름으로 내놓을 수는 없다. 남는 건 (2)와 (3)이다.

둘은 경쟁 관계가 아니다. 로컬 서버 연결은 구현 부담이 작고 이미 비슷한 걸 만들어 봤으니 먼저 붙이기 쉬운 쪽이다. 모델 팩은 더 많은 사람에게 닿지만 준비할 게 많다. 순서를 정한다면 나는 연결 방식이 먼저라고 본다. 다만 이건 방향일 뿐이고, 언제 어떤 형태로 나온다고 약속할 단계는 아니다.

PART 05결정 전에 따져 볼 실무 체크리스트

로컬 LLM 기능을 넣을지 고민하는 다른 개발자에게도 쓸모 있을 것 같아, 내가 따져 본 항목을 정리해 둔다. 기술보다 운영과 사용자 경험 쪽 질문이 많다는 게 포인트다.

마지막 항목은 한칸을 만들면서 몸으로 배운 부분이다. 로컬 서버라도 인증 키를 쓰는 경우가 있고, 클라우드 API 키는 말할 것도 없다. 이런 값을 설정 파일에 평문으로 두면 PC를 같이 쓰는 사람이나 백업 과정에서 새어 나가기 쉽다. Windows라면 자격 증명 관리자에 맡기는 게 가장 무난하다.

업데이트 부담도 과소평가하기 쉽다. 모델은 계속 새로 나온다. 번들 방식이면 "더 좋은 모델이 나왔으니 바꿔 주세요"라는 요청이 올 때마다 수 GB짜리 새 버전을 내야 한다. 분리해 두면 이 요청에 훨씬 가볍게 대응할 수 있다.

자주 묻는 질문

로컬 LLM을 프로그램에 넣으면 설치 파일이 얼마나 커지나요?

모델 크기에 따라 다르지만, 7~8B급 모델을 4비트로 양자화해도 대략 4~5GB 정도로 알려져 있다. 3B급은 약 2GB, 1B급은 1GB 안팎이다. 실행 엔진까지 더하면 본체 크기가 작은 프로그램일수록 상대적 증가 폭이 매우 크다.

오프라인 PDF 번역에 어느 정도 크기의 모델이 필요한가요?

짧은 문장만이라면 작은 모델로도 어느 정도 되지만, 전문 용어가 섞인 긴 문서를 읽을 만하게 옮기려면 7~8B급 이상이 필요하다는 경험담이 많다. 품질은 모델 크기에 크게 좌우되므로, 실제 문서로 직접 시험해 보고 정하는 것이 좋다.

CPU만 있는 PC에서도 로컬 LLM 번역이 되나요?

돌아가긴 하지만 느릴 수 있다. 모델이 클수록, 문서가 길수록 대기 시간이 길어진다. GPU나 NPU가 있으면 빨라질 수 있지만 지원 수준이 하드웨어와 드라이버마다 달라 모든 PC에서 같은 경험을 기대하기는 어렵다.

Ollama 같은 로컬 서버를 데스크톱 프로그램에 연결할 수 있나요?

Ollama는 OpenAI 호환 엔드포인트를 제공하므로, 프로그램이 OpenAI 호환 API를 지원하면 서버 주소만 바꿔 연결할 수 있다. 이 방식은 프로그램 크기를 키우지 않는 대신 사용자가 서버를 직접 설치하고 관리해야 한다는 진입 장벽이 있다.

클라우드 번역 API를 쓰면 안 되는 이유가 있나요?

품질과 속도만 보면 좋은 선택일 수 있다. 다만 문서 내용이 외부 서버로 전송되므로, 기밀 문서나 개인 서류처럼 유출이 걱정되는 경우에는 맞지 않는다. 오프라인 번역을 찾는 사람 상당수가 바로 그 이유 때문에 찾는다.

참고 자료

• llama.cpp (GitHub)
• Microsoft Learn — 자격 증명 관리자