# 12장: 지식 엔지니어링을 위한 로컬 모델

> **한 문장으로:** 로컬 모델은 자신의 하드웨어에서 전체 지식 harness를 실행할 수 있게 한다 ——사적이고, 무료이며, 점점 더 클라우드 API와 경쟁력 있다.
>
> **왜 중요한가:** 지식 베이스가 민감한 데이터를 포함하거나, 자신의 노트로 모델을 fine-tune하고 싶다면, 로컬 추론이 모든 것을 자기 통제 아래 두는 유일한 경로다.

이전 장들은 클라우드 API 접근을 대체로 가정하는 지식 엔지니어링 스택을 기술한다 ——자신의 context window를 Anthropic, OpenAI, 또는 Google에 보내고 응답을 받기. 이는 대부분의 사용자에게 잘 작동한다. 그러나 클라우드 추론이 실용적이지 않거나 바람직하지 않은 실무자 부분이 늘어나고 있다: 민감한 기업 데이터로 작업하는 사람, 엄격한 데이터 거주 요구사항을 가진 관할에 있는 사람, 그리고 자신이 컴파일한 지식으로 모델을 fine-tune함으로써 루프를 완전히 닫고 싶은 사람.

본 장은 로컬 모델과 지식 엔지니어링의 교차를 다룬다. GPU 구매 가이드, 벤치마크 비교, 양자화 기법은 다루지 않는다 ——그 주제들은 다른 자원에서 잘 다뤄진다. 대신, 모델을 자신의 인프라 안으로 가져올 때 중요한 아키텍처 결정에 초점을 맞춘다.

---

## 지식 엔지니어링에 로컬이 중요한 이유

세 가지 힘이 지식 시스템에서 로컬 모델 채택을 추진한다:

**정책이 아니라 아키텍처로서의 프라이버시.** 내부 회사 문서에 RAG를 실행할 때, 모든 쿼리가 문서 청크를 클라우드 제공자에게 보낸다. 데이터 처리 협약이 도움이 되지만, 표면적을 제거하지는 않는다. 로컬 추론으로는, 데이터가 머신을 결코 떠나지 않는다. 법무 회사, 의료 조직, 정부 기관에게 이는 선호가 아니라 ——요구사항이다.

**스케일에서의 비용.** 지속적 백그라운드 프로세스 ——vault 린팅, 자동 노트 컴파일, 주기적 재인덱싱 —— 를 실행하는 지식 시스템은 하루에 수천 건의 API 호출을 만들어 낸다. 클라우드 가격에서 이는 빠르게 쌓인다. 소비자 하드웨어에서 실행되는 로컬 모델은 초기 셋업 후 쿼리당 한계 비용이 0이다. 항상 켜진 지식 유지 (Karpathy 아키텍처의 Lint 연산)에 대해, 로컬 추론은 경제학을 완전히 바꾼다.

**Fine-tuning 엔드게임.** 이것이 아마도 가장 설득력 있는 이유다. 지식 베이스가 충분한 품질에 도달하면 ——Ingest 연산을 통해 컴파일된 잘 구조화된, 상호 링크된 수백 개의 노트 —— 그것은 깨끗한 합성 데이터셋이 된다. 이 데이터셋으로 작은 로컬 모델을 fine-tune하여, 런타임에 검색을 필요로 하지 않고 자신의 도메인을 본질적으로 "아는" 모델을 산출할 수 있다. 지식이 context window가 아니라 가중치에 있다.

---

## 아키텍처: 로컬 모델이 들어가는 곳

지식 harness의 모든 구성 요소가 로컬 추론으로부터 동등하게 이득을 얻는 것은 아니다. 여기 로컬 모델이 가장 가치를 제공하는 곳이 있다:

### 임베딩 모델 (높은 가치)

임베딩은 어떤 RAG 파이프라인의 토대이다. vault에 노트를 더할 때마다, 유사도 검색을 위해 벡터로 변환되어야 한다. 이는 대량, 저복잡도 연산이다 ——로컬 추론에 완벽하다.

인기 있는 선택:
- **nomic-embed-text** (137M 파라미터): 강력한 범용 임베딩, CPU에서 실행
- **mxbai-embed-large** (335M): 더 높은 품질, 적당한 하드웨어에서도 다룰 만함
- **bge-m3** (568M): 다국어, 혼합 언어 콘텐츠를 가진 vault에 탁월

이 모델들은 GPU 없이 어떤 현대 노트북에서도 실행할 만큼 작다. 로컬과 클라우드 임베딩 (OpenAI의 text-embedding-3, Cohere의 embed) 사이의 품질 차이는 현저히 좁아졌다 ——대부분의 지식 관리 사용 사례에 대해 로컬 임베딩은 충분하다.

Ollama로 로컬 실행:
```
ollama pull nomic-embed-text
```

### 쿼리와 추론 (중간 가치)

자신의 vault에 대한 질문에 답하기 위해 로컬 모델을 사용하는 것 ——Query 연산 —— 은 트레이드오프가 더 미묘해지는 곳이다. 클라우드 모델 (Claude Opus, GPT-4o)은 여전히 복잡한 추론, 다단계 종합, 미묘한 지시 따르기에서 의미 있게 더 낫다. 그러나 단순 검색 기반 Q&A ("지난 달에 X에 대해 무엇을 썼는가?")에 대해서는 7–14B 파라미터 범위의 로컬 모델이 잘 수행한다.

실용적 옵션:
- **Qwen3-14B**: 강력한 다국어 성능, Apache 2.0 라이선스
- **Llama 3.3-8B**: 빠른 추론, 구조화된 지시 따르기에 좋음
- **DeepSeek-R1-Distill-7B**: 전체 R1에서 증류된 추론 능력, MIT 라이선스
- **Gemma 3-12B**: Google의 효율적 아키텍처, 구조화된 출력에 좋음

가장 잘 작동하는 패턴은 **계층적 접근**이다: 일상 쿼리와 vault 유지에는 로컬 모델을 사용하고, 복잡한 종합과 창의적 작업에는 클라우드 API로 에스컬레이션한다. 이는 progressive disclosure의 harness engineering 원칙이 모델 선택에 적용되는 방식을 반영한다 ——각 작업에 최소 능력 모델을 사용하라.

### 지식 컴파일 (높은 가치)

Ingest 연산 ——원시 출처를 읽고 구조화된 위키 페이지로 컴파일 —— 은 놀랍게도 로컬 모델에 잘 맞는다. 작업이 잘 정의되어 있다: 기사를 읽고, 핵심 점을 추출하고, wikilink를 가진 구조화된 노트를 생성한다. 좋은 지시 따르기를 가진 14B 모델이 이를 신뢰할 수 있게 다룰 수 있다. 특히 출력 형식이 시스템 prompt에 정확히 명시된 경우.

이는 경제학 논변이 가장 강한 곳이다. Web Clipper가 하루에 5–10 기사를 캡처하고 각 컴파일이 2–3분의 추론을 받는다면, 이를 로컬에서 실행하는 것은 지식 베이스가 한계 비용 0으로 지속적으로 자란다는 것을 의미한다.

### Vault 유지 (높은 가치)

Lint 연산 ——모순, 진부함, 고립된 노트를 스캔 —— 은 로컬 추론에서 엄청나게 이득을 얻는 배치 프로세스이다. API 비용을 걱정하지 않고 매시간, 매일, 또는 백그라운드에서 지속적으로 실행할 수 있다. 로컬 모델이 vault를 스캔하고, 문제를 표시하고, 건강 보고서를 생성한다 ——모두 데이터가 머신을 떠나지 않고.

---

## Fine-Tuning 엔드게임

Andrej Karpathy는 많은 실무자가 이제 추구하고 있는 비전을 개관했다: LLM이 유지하는 위키가 충분한 품질에 도달하면, 그것을 사용해 개인 Small Language Model (SLM)을 fine-tune하라.

워크플로우:

1. **컴파일**: 수개월의 Ingest 연산을 통해 지식 베이스를 컴파일하라. 위키가 잘 구조화된, 상호 링크된 수백 개 노트로 자란다.
2. **추출**: 위키에서 훈련 쌍을 추출하라: 각 노트가 (질문, 답) 쌍이 되거나, (context, completion) 쌍이 된다.
3. **Fine-tune**: LoRA 또는 QLoRA를 사용해 이 데이터셋으로 작은 모델 (1–3B 파라미터)을 fine-tune하라.
4. **배포**: fine-tune된 모델을 로컬에 배포하라. 그것은 이제 검색 없이 자신의 가중치에서 자신의 도메인에 관한 질문에 답한다.

이는 RAG를 완전히 대체하지 않는다 ——fine-tune된 모델은 여전히 최근 정보와 특정 디테일을 위해 검색에서 이득을 얻는다. 그러나 검색 부담을 극적으로 줄인다. 모델이 자신의 도메인의 기초 개념, 관계, 패턴을 "안다." RAG는 단지 새롭거나 매우 특정한 정보로 보충할 필요가 있다.

이 파이프라인을 위한 도구들은 성숙하다:
- 효율적 fine-tuning을 위한 **Unsloth** (2배 더 빠름, 60% 더 적은 메모리)
- 관리되는 훈련 구성을 위한 **Axolotl**
- fine-tune된 모델의 로컬 추론을 위한 **MLX** (Apple Silicon) 또는 **llama.cpp**

---

## 통합 패턴

### 패턴 1: 보편 백엔드로서의 Ollama

Ollama는 OpenAI 호환 API로 로컬 모델을 실행하는 통합 인터페이스를 제공한다. 이는 OpenAI API와 작동하는 어떤 도구도 base URL을 바꿈으로써 로컬 모델로 향할 수 있음을 의미한다:

```
base_url: http://localhost:11434/v1
model: qwen3:14b
```

이는 LangChain, LlamaIndex, Dify, 그리고 대부분의 RAG 프레임워크와 작동한다. Obsidian 사용자에게는 Smart Connections와 같은 플러그인이 클라우드 API 대신 로컬 Ollama 모델을 사용하도록 구성될 수 있다.

### 패턴 2: 하이브리드 클라우드-로컬

대부분의 사용자에게 가장 실용적인 아키텍처:
- **로컬**: 임베딩, vault 유지, 일상 쿼리, 지식 컴파일
- **클라우드**: 복잡한 추론, 창의적 종합, 다단계 에이전트 워크플로우

이는 진정으로 그것을 요구하는 작업에 대한 프런티어 모델 능력 접근을 유지하면서, 대량 연산에 로컬 추론의 프라이버시와 비용 이점을 제공한다.

### 패턴 3: 로컬 모델과 함께하는 MCP

Model Context Protocol은 Ollama의 OpenAI 호환 엔드포인트를 통해 로컬 모델과 작동한다. 이는 로컬 지식 출처 ——자신의 vault, 자신의 데이터베이스, 자신의 파일 시스템 —— 에 연결되고 그것들을 로컬에서 실행되는 모델에 제공하는 MCP 서버를 만들 수 있음을 의미한다. 전체 지식 harness가 자신의 머신에서 실행된다.

---

## 본 장이 다루지 않는 것

본 장은 의도적으로 다음을 생략한다:
- **하드웨어 권장**: GPU 선택, VRAM 요구사항, 클라우드 GPU 임대는 r/LocalLLaMA의 위키와 Ollama 문서 같은 자원에서 광범위하게 다뤄진다.
- **모델 벤치마크**: 순위는 매월 변한다. 현재 순위는 [Open LLM Leaderboard](https://huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard)를 확인하라.
- **양자화 디테일**: GGUF 형식, INT4 vs INT8, 품질/속도 트레이드오프는 llama.cpp와 Ollama 커뮤니티에서 잘 문서화되어 있다.
- **훈련 인프라**: 멀티 GPU 셋업, 분산 훈련, 클라우드 훈련 플랫폼은 지식 엔지니어링의 범위 밖이다.

여기서의 초점은 아키텍처적 질문이다: 로컬 모델이 자신의 지식 harness 어디에 맞고, 그것들이 무엇이 가능한지를 어떻게 바꾸는가?

---

## 핵심 시사점

1. **로컬 임베딩은 망설일 것이 없다.** 품질 격차가 닫혔고, 비용은 0이며, 프라이버시 이점은 절대적이다. RAG를 실행한다면, 임베딩을 로컬에서 실행하라.

2. **계층적 추론이 실용적 선택이다.** 일상 연산에는 로컬, 복잡한 추론에는 클라우드. 7B 모델이 프런티어 모델이 더 잘하는 일을 하도록 강제하지 마라.

3. **컴파일 사용 사례는 과소평가되어 있다.** Ingest를 로컬에서 실행하는 것은 지식 베이스가 비용 0으로 지속적으로 자랄 수 있음을 의미한다. 이는 지식 유지의 경제학을 바꾼다.

4. **Fine-tuning은 시작점이 아니라 엔드게임이다.** 위키를 먼저 만들어라. 수백 개의 품질 노트를 컴파일하라. 그 다음에 fine-tune하라. 훈련 데이터 ——자신의 위키 —— 의 품질이 결과 모델의 품질을 결정한다.

5. **프라이버시는 아키텍처 결정이다.** 지식이 민감한 정보를 담고 있다면, 로컬 추론은 선택이 아니다. 처음부터 그것을 위해 설계하라.

---

## Sources

- Ollama: [https://ollama.ai](https://ollama.ai)
- llama.cpp: [https://github.com/ggml-org/llama.cpp](https://github.com/ggml-org/llama.cpp)
- Unsloth: [https://github.com/unslothai/unsloth](https://github.com/unslothai/unsloth)
- Karpathy, Andrej. "LLM Wiki" pattern --- Gist defining the raw → wiki → schema layered architecture and the Ingest / Compile / Lint / Query operations referenced throughout this chapter. [https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)
- Open LLM Leaderboard: [https://huggingface.co/spaces/open-llm-leaderboard](https://huggingface.co/spaces/open-llm-leaderboard)
- Nomic Embed: [https://huggingface.co/nomic-ai/nomic-embed-text-v1.5](https://huggingface.co/nomic-ai/nomic-embed-text-v1.5)
- r/LocalLLaMA: [https://reddit.com/r/LocalLLaMA](https://reddit.com/r/LocalLLaMA)

---

*이전 장: [11장 — LLM 지식 엔지니어링의 핵심 순간들](11-timeline.md)*
