신뢰도 높고 가성비 좋은 로컬 AI 모델 구축하기 🖤 Claude·ChatGPT처럼 쓰는 법

클라우드 AI API는 편리하지만 사용량에 비례해 비용이 늘어나고, 민감한 코드나 문서를 외부 서버로 보내야 한다는 부담이 있다.

반면 로컬 LLM은 초기 설정만 끝나면 정액 비용(전기료 수준)으로 무제한에 가깝게 쓸 수 있고, 데이터가 내 PC를 벗어나지 않는다.

이 글에서는 로컬 LLM을 실제 업무에 쓸 수 있는 수준으로 세팅하는 과정을 런타임 선택 → 모델 선택 → 설치 → ChatGPT/Claude 스타일 UI 구성 → 개발 환경 연동 순서로 정리한다.

1. 왜 로컬 LLM인가: 클라우드 API와의 트레이드오프

항목	클라우드 API (Claude, GPT 등)	로컬 LLM
최상위 품질	우위	근접했지만 아직 소폭 열세
비용 구조	토큰당 종량제	하드웨어 초기 투자 + 전기료 정액
데이터 프라이버시	외부 전송 필요	PC 내부에서 완결
응답 속도	네트워크 의존	하드웨어 스펙 의존, 오프라인 가능
설정 난이도	낮음 (API 키만 있으면 끝)	초기 러닝커브 존재

민감한 사내 코드 리뷰, 개인 일기·메모 요약, 반복적인 대량 텍스트 처리처럼 "품질보다 프라이버시·비용"이 중요한 작업에는 로컬 LLM이, 최고 난이도의 추론·복잡한 에이전트 작업에는 여전히 클라우드 API가 유리하다. 실무에서는 대부분 하이브리드로 정착한다 — 평소 작업은 로컬, 고난이도 작업만 클라우드로 폴백하는 방식이다.

2. 런타임 선택: Ollama vs LM Studio vs llama.cpp vs vLLM

로컬 LLM은 "모델 파일"과 "그 모델을 구동하는 런타임"이 분리되어 있다. 같은 모델도 런타임에 따라 속도와 편의성이 달라진다.

• Ollama: CLI 기반, 설치 후 명령어 한 줄로 모델을 받고 바로 대화 가능. REST API가 OpenAI API와 호환되는 형태로 제공되어 기존 OpenAI SDK 코드를 거의 그대로 재사용할 수 있다. 개인 개발 환경에 통합할 때 가장 무난한 선택.
• LM Studio: GUI 앱. 모델 브라우저에서 양자화 옵션·메모리 요구량을 한눈에 보고 받을 수 있어 입문자에게 친화적이다. 다만 최신 모델 지원이 Ollama보다 다소 느리고, 클로즈드 소스라는 점은 참고할 부분.
• llama.cpp: 위 두 도구의 내부 엔진에 가까운 저수준 런타임. 세부 튜닝(스레드 수, GPU 레이어 오프로드 등)을 직접 제어하고 싶을 때, 특히 Apple Silicon Metal 가속을 최대로 끌어낼 때 유리하다.
• vLLM: 다수 사용자를 동시에 서빙해야 하는 프로덕션 환경용. PagedAttention으로 메모리 단편화를 줄이고 동시 요청 처리량을 크게 높인다. 팀 내부에 로컬 AI 서버를 하나 두고 여러 명이 공유하는 구조라면 이쪽이 정답.

결론: 개인 개발자 워크플로우에는 Ollama로 시작하는 것이 가장 합리적이다. 이후 이 글도 Ollama 기준으로 진행한다.

3. 하드웨어별 모델 선택 가이드

로컬 LLM 품질은 대부분 "파라미터 수"가 아니라 "내 GPU/RAM에 맞는 가장 큰 모델을 얼마나 잘 양자화해서 돌리는가"로 결정된다. 양자화(Q4, Q5, Q8)는 모델 가중치를 낮은 비트로 압축하는 기법으로, Q4_K_M 정도면 품질 손실 대비 용량 절감 효과가 커서 사실상 표준으로 쓰인다.

VRAM/통합 메모리	추천 모델	용도
8GB 이하	Gemma 9B급, Llama 3.x 8B급 (Q4)	간단한 요약, 기본 챗봇
16GB	Qwen3 14B, Phi-4 14B (Q4)	코드 보조, 일반 작업
24GB (RTX 4090 등)	Qwen3 30B급, DeepSeek 계열 Flash/Distill (Q4)	코딩 보조, 다중 도구 호출
48GB+ / Mac Studio 고사양	70B급 모델 (Q4)	복잡한 추론, 자율 에이전트

참고할 점:

• 한국어 사용 비중이 높다면 Qwen 계열이 토크나이저 효율이 좋아 같은 컨텍스트 길이 대비 실질적으로 더 많은 한글을 담을 수 있다. 대부분의 모델은 영어 중심 토크나이저라 한글 문서가 영어보다 2~3배 많은 토큰을 소비하므로, "128K 컨텍스트"라고 광고돼도 한글 기준 체감 컨텍스트는 절반 이하로 줄어든다는 점을 감안해야 한다.
• 코딩 특화 작업에는 Qwen-Coder 계열이나 DeepSeek-Coder 계열이 범용 모델보다 낫다.
• 라이선스도 확인 필요: Llama 계열은 Meta Community License(대규모 사용자 기준 상업 이용 제한 조항 존재)이고, Qwen·Mistral·Gemma 계열은 대부분 Apache 2.0으로 상업 이용이 자유롭다.

3-1. 구글 Gemma는 어떤가

Gemma는 Llama·Qwen과 함께 로컬 LLM의 주요 축 중 하나다. 몇 가지 특징을 짚어보면:

• 가벼운 체급에서 성능이 좋다: Gemma 3 4B가 Chatbot Arena 기준 GPT-4급 모델과 근접한 점수를 받은 적이 있을 만큼, 동급 파라미터 대비 성능이 좋은 편이다. VRAM이 넉넉지 않은 노트북·미니PC 환경에 특히 잘 맞는다.
• 한국어를 포함한 CJK 토큰화 효율이 좋다: Gemini 계열과 같은 SentencePiece 토크나이저(약 26만 vocab)를 써서 한국어·중국어·일본어를 처리할 때 다른 모델보다 토큰 소비가 적은 편이다. 앞서 언급한 "한글은 토큰을 많이 먹는다"는 문제가 Gemma 계열에서는 상대적으로 덜하다.
• 최신 버전은 Gemma 4: 2026년 4월 정식 공개되었고 E2B/E4B(모바일·경량 디바이스용), 26B-A4B(MoE), 31B 4가지 구성으로 나온다. 이후 두 체급 사이 공백을 메우는 12B 모델도 추가됐다. 전량 Apache 2.0 라이선스라 상업적 사용에 제약이 없고, 도구 호출(function calling)도 새로 지원한다.
• 주의할 점: Ollama 환경에서 과거 Gemma 3 토크나이저가 일부 희귀 한글 음절('괭', '뼉' 등)을 제대로 인코딩하지 못하는 이슈가 커뮤니티에서 보고된 적이 있다. 일반적인 대화·문서 작업에는 지장이 없는 수준이지만, 정확한 한글 처리가 중요한 프로덕션 파이프라인이라면 최신 Ollama 버전에서 직접 검증해보는 것이 안전하다.

# Gemma 4 계열 (VRAM 16GB 내외)
ollama pull gemma4:12b

# 가벼운 환경 (8GB 내외)
ollama pull gemma4:4b

결론: 코딩 보조는 Qwen 계열, 순수 한국어 대화·요약·경량 환경은 Gemma 계열이라는 역할 분담으로 두 모델을 함께 두고 쓰는 것도 실전에서 흔한 조합이다.

4. 실전 설치: Ollama + 모델 다운로드

# macOS
brew install ollama

# Linux
curl -fsSL https://ollama.ai/install.sh | sh

# Windows: ollama.com에서 설치 파일 다운로드

# 버전 확인
ollama --version

모델 다운로드는 명령어 한 줄이면 끝난다.

# Ollama 서버 실행 - 일단 우선되야 하는 작업 다음 명령어를 켜놓은 터미널이 하나 필요하다
ollama serve

# 범용 모델 실행 (없으면 자동 다운로드)
ollama run qwen3:14b

# 코딩 모델 다운로드
ollama pull qwen2.5-coder:14b
ollama pull qwen2.5-coder:1.5b

# 임베딩 모델 다운로드
ollama pull nomic-embed-text

한국에서 Hugging Face·Ollama 저장소 다운로드 속도가 저녁 시간대에 느려지는 경우가 있으므로, 대용량 모델(40GB 이상)은 새벽 시간대 다운로드를 권장한다.

5. Claude/ChatGPT처럼 쓰기: Open WebUI로 채팅 UI 구성

Ollama 자체는 CLI/API만 제공하므로, ChatGPT 같은 웹 채팅 UI가 필요하면 Open WebUI를 얹는다. 대화 기록 저장, 멀티 세션, 시스템 프롬프트 저장, RAG용 문서 업로드까지 지원해 체감상 상용 챗봇과 거의 동일한 경험을 제공한다.

# Docker로 Open WebUI 실행 (Ollama가 로컬에서 이미 실행 중이라는 가정)
docker run -d \
  --name open-webui \
  -p 3000:8080 \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

이후 http://localhost:3000 접속 → 계정 생성 → 좌측에서 다운로드한 모델 선택하면 바로 채팅 가능하다. 문서 업로드 후 #파일명으로 참조하면 자동으로 RAG 파이프라인이 동작한다.

더 가벼운 대안이 필요하면 Msty나 Jan도 고려할 만하다. 두 앱 모두 로컬 모델과 클라우드 API(OpenAI, Anthropic 등)를 하나의 UI에서 토글할 수 있어, "평소엔 로컬, 필요할 때만 클라우드" 워크플로우에 적합하다.

6. 개발 환경에 연동하기: OpenAI SDK로 로컬 모델 호출

프론트엔드/백엔드 코드에서 로컬 모델을 호출할 때는 Ollama의 OpenAI 호환 엔드포인트를 그대로 활용하면 된다. 기존에 OpenAI API로 작성된 코드의 baseURL과 apiKey만 바꾸면 동작한다.

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "http://localhost:11434/v1",
  apiKey: "ollama", // 로컬이라 실제로는 검증하지 않지만 필수 파라미터라 아무 값이나 넣는다
});

async function chat(prompt: string) {
  const response = await client.chat.completions.create({
    model: "qwen3:14b-instruct",
    messages: [{ role: "user", content: prompt }],
    stream: false,
  });

  return response.choices[0].message.content;
}

스트리밍 응답도 동일한 패턴으로 처리할 수 있다.

const stream = await client.chat.completions.create({
  model: "qwen3:14b-instruct",
  messages: [{ role: "user", content: prompt }],
  stream: true,
});

for await (const chunk of stream) {
  process.stdout.write(chunk.choices[0]?.delta?.content ?? "");
}

도구 호출(Function Calling)도 지원되지만 주의할 점이 있다. Ollama의 도구 호출은 Mistral, Llama 3.x, Qwen 2.5 이상처럼 함수 호출용으로 학습된 모델에서만 안정적으로 동작하며, OpenAI API의 tool_choice로 특정 도구 호출을 강제하거나 스트리밍 중 도구 호출 응답을 받는 기능은 아직 완전히 지원되지 않는다. 프로덕션에 강제 호출 로직이 필요하다면 프롬프트 엔지니어링으로 보완하거나, LangChain 같은 프레임워크의 파서를 함께 쓰는 편이 안전하다.

7. VS Code와 연동하기: Continue vs Cline

채팅창을 오가는 대신 에디터 안에서 바로 로컬 모델을 쓰고 싶다면 VS Code 확장을 붙이면 된다. 둘 다 Ollama를 기본 프로바이더로 지원하며 API 키 없이 바로 연결된다.

• Continue: GitHub Copilot과 비슷한 자동완성 + 채팅 사이드바 구조. 여러 LLM 프로바이더를 한 확장에서 자유롭게 전환할 수 있어, "평소엔 로컬 Qwen, 어려운 작업만 Claude"처럼 모델을 역할별로 나눠 쓰기 좋다.
• Cline: 채팅 보조를 넘어 파일 생성·터미널 명령 실행·브라우저 조작까지 수행하는 자율 에이전트형 도구. Plan(계획) → Act(실행) 두 단계로 나뉘어 있어 코드를 바꾸기 전에 계획을 검토할 수 있다.

두 도구 모두 VS Code 확장 마켓플레이스에서 검색해 설치하면 되고, 커맨드라인으로도 설치 가능하다.

# Continue 설치
code --install-extension Continue.continue

# Cline 설치
code --install-extension saoudrizwan.claude-dev

Continue + Ollama 설정

Continue는 config.yaml 한 파일에서 모델, 규칙, MCP 서버를 함께 관리한다.

add chat model 누른 뒤, 하단에 config file 누르면 파일이 열린다.

 

 

name: Main Config
version: 1.0.0
schema: v1

models:
  - name: Qwen3 14B
    provider: ollama
    model: qwen3:14b
    apiBase: http://localhost:11434
    roles:
      - chat
      - edit
      - apply

  - name: Qwen2.5 Coder 1.5B
    provider: ollama
    model: qwen2.5-coder:1.5b
    apiBase: http://localhost:11434
    roles:
      - autocomplete

사이드바는 Cmd/Ctrl+L(채팅), 인라인 편집은 Cmd/Ctrl+I로 호출한다.

나는 autocomplete는 가벼운걸로 세팅했다.

 

설정하면 !! 이제 해당 모델을 선택할 수 있다.

 

Cline + Ollama 설정

Cline은 사이드바 아이콘 클릭 → API Provider에서 Ollama 선택 → Base URL(http://localhost:11434)과 모델명만 지정하면 끝난다. 이후 자연어로 작업을 지시하면 Plan 모드에서 변경 계획을 먼저 보여주고, 승인하면 Act 모드로 넘어가 실제로 파일을 수정·명령을 실행한다.

8. 프로젝트 규칙 파일 작성하기: CLAUDE.md 대신 무엇을 쓰나

Claude Code에서 CLAUDE.md에 프로젝트 컨벤션을 적어두던 것처럼, VS Code용 로컬 AI 도구에도 같은 역할을 하는 규칙 파일이 있다. 다만 도구별로 파일명과 형식이 다르다는 점이 중요하다.

도구	규칙 파일	특징
Claude Code	CLAUDE.md	프로젝트 루트 1개 파일, 자유 형식 마크다운
Cline	.clinerules/ 디렉터리 (또는 단일 .clinerules 파일)	여러 파일로 분리 가능, YAML frontmatter로 특정 경로에만 적용되는 조건부 규칙 지원
Continue	config.yaml의 rules 필드	모델 설정과 한 파일에서 관리
범용 표준	AGENTS.md	Anthropic·OpenAI·Block이 함께 만든 Agentic AI Foundation 표준. Cursor, Aider, GitHub Copilot, Cline 등 대다수 도구가 지원

실무에서는 AGENTS.md 하나를 기본으로 두고, 도구별 특수 기능(경로별 조건부 규칙 등)이 필요할 때만 .clinerules/를 추가로 쓰는 방식이 가장 유지보수가 쉽다. Cline은 .clinerules/와 별개로 AGENTS.md도 함께 읽어 병합하기 때문에 두 파일을 굳이 중복 관리할 필요가 없다.

# AGENTS.md

## 프로젝트 개요
Next.js 14 App Router 기반 프론트엔드 프로젝트 (Pulsefolio)

## 개발 명령어
- 설치: `pnpm install`
- 개발 서버: `pnpm dev`
- 테스트: `pnpm test`
- 빌드: `pnpm build`

## 코드 스타일
- TypeScript strict 모드
- 함수형 컴포넌트만 사용, 클래스 컴포넌트 금지
- 세미콜론 없음, 작은따옴표 사용

## 주의사항
- .env, **/secrets/* 파일은 절대 읽거나 수정하지 말 것
- DB 마이그레이션 SQL은 실행 전 항상 사람이 리뷰

Cline처럼 경로별로 다른 규칙을 적용하고 싶다면 .clinerules/ 디렉터리에 파일을 나눠 YAML frontmatter로 적용 범위를 지정한다.

---
paths:
  - "src/components/**"
  - "src/hooks/**"
---
# 프론트엔드 컴포넌트 규칙
- Tailwind CSS만 사용, CSS Module 금지
- 커스텀 훅으로 재사용 가능한 로직 분리
- 컴포넌트는 하나의 책임만 갖도록 유지

규칙 파일 작성 시 실전 팁:

• 규칙 파일의 모든 텍스트는 매 요청마다 컨텍스트에 포함되므로 장황하게 나열하지 말고 핵심만 압축한다.
• 모델이 기본적으로 잘 지키는 규칙은 지운다. 규칙을 빼고 실행해봤을 때 결과가 달라지지 않으면 불필요한 규칙이다.
• 특정 모듈에만 해당하는 맥락은 전역 규칙 대신 @파일경로 멘션으로 그때그때 전달하는 편이 컨텍스트를 아낀다.

9. RAG·에이전트까지 확장하려면: AnythingLLM

사내 문서 검색, 개인 지식베이스 챗봇처럼 RAG가 필요한 경우 AnythingLLM을 고려할 만하다. Ollama를 백엔드로 두고 워크스페이스 단위로 문서·임베딩·모델 설정을 묶어 관리할 수 있으며, LanceDB를 기본 벡터 DB로 내장하고 있어 별도 인프라 없이도 바로 RAG 파이프라인을 구성할 수 있다. Docker로 셀프호스팅 빌드가 제공돼 Open WebUI와 마찬가지로 컨테이너 하나만 띄우면 된다.

docker run -d \
  --name anythingllm \
  -p 3001:3001 \
  -v anythingllm-storage:/app/server/storage \
  --add-host=host.docker.internal:host-gateway \
  mintplexlabs/anythingllm

8. 실제로 부딪히는 현실적인 이슈들

• 한글 토큰 소비량: 앞서 언급했듯 같은 분량이라도 한글은 영어보다 2~3배 많은 토큰을 쓴다. 긴 한국어 문서를 다룰 계획이라면 광고 스펙상 컨텍스트 길이보다 훨씬 보수적으로 잡아야 한다.
• 전기료: "공짜"라는 인식과 달리 GPU를 상시 가동하면 실제 비용이 발생한다. 예를 들어 24GB급 GPU를 추론 부하 50% 수준으로 하루 종일 돌리면 월 3만 원 내외의 추가 전기료가 나온다는 것이 일반적인 체감 수준이다. 다만 이는 클라우드 API 종량 비용보다는 거의 항상 저렴하다.
• 최신 모델 지원 시차: LM Studio나 GUI 기반 도구는 최신 모델 지원이 Ollama보다 며칠에서 몇 주 늦는 경우가 많다. 최신 모델을 빠르게 써보고 싶다면 Ollama 쪽이 유리하다.
• 품질 체감 기준: 대략 7B급은 예전 GPT-3.5 대체 수준, 14B~30B급은 상용 최상위 모델의 상당 부분을 대체할 수 있는 수준, 70B급 이상은 일부 작업에서 프런티어 모델과 근접한 수준으로 보는 것이 합리적이다. 다만 복잡한 다단계 추론이나 최신 정보가 필요한 작업에서는 여전히 상용 최상위 모델과 격차가 존재한다.

9. 마무리: 어떤 조합으로 시작할까

• 처음 시작: Ollama 설치 → qwen3:14b-instruct 또는 본인 하드웨어에 맞는 모델 pull → Open WebUI로 채팅 UI 구성
• 개발 워크플로우에 통합: Ollama의 OpenAI 호환 API를 기존 코드에 그대로 연결
• 문서 기반 RAG가 필요할 때: AnythingLLM으로 워크스페이스 구성
• 팀 단위 공유 서버가 필요할 때: vLLM으로 프로덕션급 서빙 전환

로컬 LLM은 더 이상 "실험용 장난감" 수준이 아니라, 프라이버시가 중요하거나 반복적인 작업이 많은 워크플로우에서는 실질적인 대안이 될 만큼 성숙했다. 클라우드 API를 완전히 대체하기보다는, 평소 작업은 로컬로 처리하고 고난이도 작업만 클라우드로 넘기는 하이브리드 구조로 시작하는 것을 추천한다.