로컬 LLM은 환상적이며, 놀라운 속도로 계속해서 발전하고 있습니다. 저는 Claude나 ChatGPT와 같은 거대 클라우드 기업에 의존하는 것보다 로컬 환경을 선호할 수밖에 없는 확고한 이유가 있습니다. 그렇기 때문에 저는 로컬 모델을 실제 일상적인 워크플로우에 통합하기 위해 끊임없이 노력해 왔습니다.
하지만 시도해 본 사람이라면 누구나 알겠지만, 직접 구축하는 방식(DIY)에는 분명한 주의 사항과 단점이 따릅니다.
가장 큰 걸림돌은 컨텍스트 윈도우(context window)입니다. LLM으로부터 더 나은 답변을 얻으려면 더 많은 컨텍스트를 제공해야 합니다. 하지만 컨텍스트는 비용이 많이 듭니다. 컨텍스트 윈도우가 차기 시작하면 모델의 속도와 품질 모두 저하되기 시작합니다. 그렇다면 우리는 어떻게 해야 할까요?
제가 깨달은 문제는 LLM 자체가 아니었습니다. 문제는 제가 LLM을 원래 의도되지 않은 작업에 사용하고 있었다는 점이었습니다. 그리고 그 해결책은 제가 완전히 무시하고 있었던 아주 작은 모델에 있었습니다.
LLM과 컨텍스트 문제
정말로 비용이 많이 듭니다
언어 모델을 사용하는 경험의 절반은 모델 앞에 무엇을 제시하느냐에 달려 있습니다. 모호하고 빈약한 프롬프트를 주면 모호하고 빈약한 답변을 얻게 됩니다. 더 나은 답변을 얻으려면 LLM에 더 많은 컨텍스트를 제공해야 합니다.
문제는 컨텍스트에 비용이 많이 든다는 점입니다. 클라우드 모델에서 더 많은 컨텍스트는 더 많은 토큰을 의미하며, 더 많은 토큰은 더 높은 비용을 의미합니다. 로컬 환경에서는 컨텍스트 윈도우의 모든 토큰이 생성 과정에서 처리되어야 하므로 추론 속도가 느려집니다. 특히 로컬 모델의 경우 이 문제가 더욱 중요합니다.
우리는 이미 더 작은 기기와 더 엄격한 제약 조건 속에서 작업하고 있습니다. 질문할 때마다 전체 문서를 컨텍스트 윈도우에 쏟아붓는 것은 경험을 적극적으로 저하시킵니다. 모델은 실제로 중요한 부분을 추론하는 대신 정보를 끌고 다니는 데 너무 많은 에너지를 소비하게 됩니다.
제가 이 문제를 해결할 수 있었던 것은 임베딩 모델(embedding model) 덕분이었습니다.
임베딩 모델
로컬 LLM의 숨은 공신
|  출처: All Things N |
| 이 2D 뷰는 예시를 위한 것입니다. 실제 임베딩은 훨씬 더 많은 차원을 사용합니다. |
문제의 그 작은 모델이 바로 임베딩 모델입니다. 임베딩 모델은 크기가 다양하지만, LLM과 비교하면 정말 작습니다. 임베딩 모델이 하는 일은 다소 추상적이지만, 최선을 다해 설명해 보겠습니다.
임베딩 모델은 텍스트 조각을 가져와 긴 숫자 목록으로 변환합니다. 이 목록을 벡터라고 하며, 수학적 공간에서 텍스트의 의미를 나타냅니다.
대략 같은 의미를 가진 두 문장은 해당 공간에서 서로 가까운 벡터를 생성합니다. 서로 아무런 관련이 없는 두 문장은 멀리 떨어져 있게 됩니다.
이것은 키워드 검색이 아닙니다. 모델은 일반적인 검색창처럼 정확한 키워드에 신경 쓰지 않습니다. 임베딩 모델은 의미론적 유사성을 이해합니다.
제 설명과 차트로도 부족하다면, 아래의 YouTube 쇼츠가 이 주제를 잘 다루고 있습니다:
이 패턴을 RAG라고 합니다
RAG는 검색 증강 생성(Retrieval-Augmented Generation)의 약자입니다. 모든 지식을 모델 자체에 학습시키는 대신, 벡터 데이터베이스에 외부적으로 보관하고 필요할 때 관련 부분만 검색한다는 개념입니다. 모델의 역할은 답변 생성이라는 본연의 기능에 집중하게 됩니다.
먼저, 임베딩 모델이 문서를 처리하여 각 텍스트 조각을 벡터로 변환합니다. 이 벡터들은 전용 데이터베이스(ChromaDB나 Qdrant 등, 둘 다 로컬 기기에서 실행 가능)에 저장됩니다. 이 과정은 한 번만 수행됩니다.
그런 다음 질문을 하면, 동일한 임베딩 모델이 사용자의 질문도 벡터로 변환합니다. 데이터베이스는 유사도 검색을 실행하여 질문과 의미가 가장 가까운 조각들을 찾아냅니다. 이 조각들은 원래 질문과 함께 컨텍스트로서 LLM에 전달됩니다. LLM은 이를 해석하는 역할을 합니다.
여러분은 이미 알지 못하는 사이에 이 기술의 혜택을 누리고 있습니다. 구글의 연구 보조 도구인 NotebookLM은 수천 단어 분량의 소스를 무료로 입력할 수 있게 해줍니다. 구글이 토큰에 대해 유독 관대한 것일까요?
아닙니다. 그것이 바로 임베딩의 힘입니다. 모든 쿼리마다 모든 소스를 모델에 로드하는 것이 아니라, 관련 있는 내용만 저렴하고 즉각적으로 검색하는 것입니다. 무거운 작업은 거의 비용이 들지 않는 프로세스로 오프로드됩니다.
물론 여러분의 환경은 매우 다를 수 있습니다
|  |
| 설정은 훌륭하게 작동하지만, 결과물이 단순한 LLM 응답일 뿐이라 공유할 만한 멋진 스크린샷은 없습니다. |
로컬 LLM의 가장 즉각적인 사용 사례는 문서 활용입니다. 이를 위해 인기 있는 로컬 LLM 인터페이스인 LM Studio에서 별도의 설정 없이 이 아이디어를 체험해 볼 수 있습니다. LM Studio는 이미 RAG가 내장되어 있습니다. “embedding model updated”라는 알림이 바로 그 때문입니다. LLM과의 새로운 대화에서 RAG MCP가 활성화되어 있는지 확인한 다음 문서를 업로드하기만 하면 됩니다. 기본적으로는 그것이 전부입니다.
저는 제 Obsidian 저널 항목을 지속적으로 임베딩하고 싶었지만, 위 방식으로는 충분하지 않았습니다. 더 영구적인 무언가를 위해서는 임베딩 모델을 다운로드하여 LLM과 함께 호스팅하는 것을 권장합니다.
저는 mxbai-embed-large-v1을 사용합니다. 다른 옵션으로는 embeddinggemma-300m이 있습니다. 이들은 모두 대형 임베딩 모델이지만, 실질적으로는 약 500MB의 저장 공간을 차지하며 GPU로 쉽게 완전히 오프로드할 수 있습니다.
여기서부터는 선택지가 있습니다. OpenNotebook과 같은 미리 빌드된 앱을 사용할 수 있습니다. 이는 본질적으로 자체 호스팅되는 NotebookLM 클론이며, 호스팅 중인 LLM 및 임베딩 모델을 연결하기만 하면 됩니다. 그곳에 소스를 업로드하고 앱 내에서 사용할 수 있습니다.
하지만 이 역시 쿼리를 위해 OpenNotebook을 사용해야 한다는 제약이 있습니다. 저는 더 많은 유연성을 원했습니다.
그래서 저는 Qdrant를 벡터 데이터베이스로 설정했습니다. (Docker 덕분에) 설정이 매우 쉽습니다. 그런 다음 간단한 Python 스크립트를 사용하여 임베딩 모델과 상호 작용하고 파일을 Qdrant 데이터베이스에 임베딩할 수 있습니다.
그 후 이 모든 것을 MCP 서버로 패키징하여 OpenClaw에 연결했습니다. 이제 제 에이전트는 모든 것을 소모하지 않고도 관련 컨텍스트를 가져올 수 있게 되었습니다. MCP 서버의 장점은 거의 모든 다른 AI 인터페이스에 연결할 수 있다는 것입니다. Claude Code, Codex, Antigravity 모두 MCP 서버를 지원합니다.
임베딩은 "문서" 그 이상을 넘어섭니다
지속적인 경험을 위해 사용하세요
마크다운(Markdown)은 2026년의 프로그래밍 언어입니다. 거대 언어 모델은 언어를 입력받아 언어를 출력합니다. 단어가 곧 프로그래밍 언어인 셈입니다.
자신만의 AI 에이전트가 있다면, 지속적인 메모리를 위해 임베딩 모델이 필수적입니다. 그렇지 않다면 모든 새로운 메시지에 과거의 모든 대화를 컨텍스트로 보내야 합니다. 당연히 대규모 환경에서는 불가능합니다. 속도가 느려지고, 토큰 제한에 걸리며, 경험을 저하시킵니다. 임베딩 모델은 시스템이 선택적으로 정보를 처리할 수 있게 해줍니다.
따라서 워크플로우는 다음과 같이 구성될 수 있습니다: OpenClaw나 사용 중인 에이전트가 대화 기록을 마크다운으로 유지합니다. 해당 파일들은 임베딩 모델을 통해 벡터 데이터베이스에 임베딩됩니다. OpenClaw가 과거 대화 내용(메모리)에 접근해야 할 때마다 벡터 데이터베이스를 쿼리하여 기억해야 할 정확한 정보를 가져올 수 있습니다.
이는 인간의 기억 방식과 거의 정확히 일치합니다. 가장 친한 친구와 대화를 시작할 때 자기소개를 하고, 이름을 말하고, 지금까지 함께한 모든 일을 나열하지는 않죠(특별히 강조하려는 경우가 아니라면요!). 아닙니다. 그런 사건들은 이미 그곳에 있습니다. 필요할 때 회상되는 것이죠.
저는 이를 제 저널에 사용해 왔으며, 로컬 LLM이 제 Obsidian 볼트와 연동되도록 만드는 데 있어 획기적인 진전이었습니다. 사용 사례가 무엇이든, 이 파이프라인을 구축해 보시길 권장합니다. LLM이 모든 컨텍스트를 짊어지는 것을 멈추고 중요한 정보만 검색하기 시작하면, 전체적인 경험이 완전히 달라질 것입니다.