6개월 전 저는 저의 로컬 AI 설정을 작성했고, 한 독자가 이를 북마크했다가 지난주에 이를 재현하려고 시도한 후, 절반 정도가 제가 실제로 실행하는 것과 일치하지 않는다며 혼란스러워하는 이메일을 저에게 보냈습니다. 타당한 지적입니다. 스택(Stack)은 조용히 부식됩니다. 그래서 여기 저의 2026년 중반 상태를 공유합니다: 무엇이 여전히 디스크 상의 자리를 차지하고 있는지, 무엇을 삭제했는지, 그리고 어디로 조용히 클라우드로 돌아갔는지에 대해서 말이죠.

아래의 숫자와 의견들에 대한 맥락을 말씀드리자면: 저는 스마트 컨트랙트(Smart Contract) 보안 작업을 수행하며, 적당한 GPU가 장착된 머신의 WSL2 위에서 모든 것을 실행합니다. 또한 저는 로컬 모델(Local-model) 작업을 취미가 아닌 제품 출시의 일환으로서 1년 넘게 매일 수행해 오고 있습니다.

여전히 유지 중: 런타임(Runtime)으로서의 Ollama

Ollama는 로컬 스택의 중심을 유지하고 있으며, 솔직히 다른 대안들과는 비교조차 되지 않습니다. 저는 제어력을 위한 llama.cpp 직접 사용, 속도를 위한 몇몇 새로운 서빙 레이어(Serving layer) 등 대안들을 시도해 보았지만, 한 가지 지루한 이유 때문에 계속 다시 돌아오게 됩니다. 바로 API가 안정적이며 제가 구축한 모든 것이 이 API와 통신한다는 점입니다. 저의 감사 도구(Audit tooling), 쉘 스크립트(Shell scripts), 에디터 설정(Editor config) 모두가 localhost:11434를 가리키고 있으며, 1년 동안 깨지지 않고 그곳을 가리켜 왔습니다.

이러한 안정성은 미미한 초당 토큰 수(Tokens-per-second) 이득보다 더 중요합니다. 모델 업데이트가 출시되면, ollama pull 한 번이면 끝납니다. 동일한 API 형태를 가진 훨씬 더 나은 무언가가 나타나는 날에는 오후 한때를 투자해 바로 전환할 것입니다. 이것이 바로 여러분이 처해 있기를 원하는 바로 그 위치입니다.

여전히 유지 중: 두 가지 크기, 서로 다른 역할을 수행하는 qwen2.5-coder

저는 두 개의 모델을 실행하며, 그 비중은 놀라울 정도로 안정적으로 유지되었습니다:

qwen2.5-coder:1.5b는 반사적 모델(Reflex model)입니다. 이는 깊이보다 속도가 더 중요한 모든 작업을 처리합니다: 빠른 "이 diff가 무엇을 하는가" 요약, 커밋 메시지(Commit message) 초안 작성, 더 무거운 패스(Pass)를 거치기 전 파일의 사전 필터링, 그리고 저의 파이프라인(Pipeline) 내부의 작은 분류 작업("이 파일이 사용자 입력을 처리하는가, 예 또는 아니오") 등이 해당됩니다. 제 머신에서 호출하는 것을 전혀 의식하지 못할 정도로 충분히 빠르며, 그것이 바로 핵심입니다. 호출하기를 망설이게 되는 모델은 결국 호출하지 않게 되는 모델이 됩니다.

qwen2.5-coder:7b는 사고 모델 (thinking model)입니다. 코드 리뷰 (Code review), 보안 분류 (security triage), 구조화된 결과 추출 (structured findings extraction), 생소한 코드 설명하기 등이 그 역할입니다. 이 모델은 JSON 스키마 (JSON schema)를 준수하고 함수 전체에 걸쳐 논리를 유지한다고 신뢰할 수 있는 가장 작은 모델입니다. spectr-ai의 1차 로컬 분석은 이 모델에서 실행됩니다.

더 최신 모델들이 저를 유혹했냐고요? 끊임없이 그랬습니다. 제 VRAM (Video RAM) 용량에 맞는 코더 튜닝 (coder-tuned) 릴리스들을 대부분 시도해 보았습니다. 몇몇은 서류상 성능(paper)이 더 좋았습니다. 하지만 신뢰할 수 있는 수준으로 만들기 위해 몇 달이 걸렸던 프롬프트 (prompts)와 출력 파싱 (output parsing)을 다시 튜닝할 만큼 제 실제 작업에서 눈에 띄게 더 나은 모델은 없었습니다. 전환 비용 (Switching costs)은 실재하며, "벤치마크에서 5% 더 나은 성능"은 그 비용을 상쇄하지 못합니다.

중단: 로컬 자동 완성 (autocomplete) 실험

이 부분은 인정하기 고통스러웠습니다. 한동안 인라인 에디터 자동 완성, 즉 고스트 텍스트 (ghost-text) 방식의 로컬 모델을 실행했었는데, 2월쯤 이를 껐고 그 이후로 전혀 그리워하지 않았습니다.

문제는 품질이 아니라 지연 시간 심리학 (latency psychology)이었습니다. 자동 완성은 거의 즉각적이지 않으면 도움을 주기보다 방해가 됩니다. 제 하드웨어에서 유용한 제안을 할 만큼 충분히 좋은 모델들을 사용했을 때, 완성된 코드가 도착하는 시점은 제가 이미 제 방식대로 타이핑을 시작한 직후였습니다. 즉, 제가 지나쳐 버리는 제안들을 위해 24시간 내내 GPU 메모리를 지불하고 있었던 셈입니다. 특히 자동 완성의 경우, 실시간 추론 (real-time inference)이 가능할 만큼 충분히 빠른 하드웨어를 갖추고 있거나, 아니면 차라리 없는 편이 낫습니다. 저는 코드는 직접 작성하고, 모델은 코드를 읽는 용도로 남겨둡니다.

중단: 모델 동물원 (model zoo)

한때 제 디스크에는 수많은 모델이 있었습니다. 일반 채팅 모델, 한 번 벤치마킹했던 임베딩 모델 (embedding model), 중단된 세 가지 파인튜닝 (fine-tune) 실험 모델, 두 번 사용했던 비전 모델 (vision model)까지. 합쳐서 세 자릿수 기가바이트(GB)에 달하는 용량이 아무것도 하지 않은 채 자리만 차지하고 있었습니다.

깨달음은 이것이었습니다: 제가 실제로 사용한 모델은 단 두 개뿐이었습니다. 나머지는 모두 사용하기 위해서가 아니라 수집하기 위해 모아둔, AI 버전의 '읽지 않은 책들'과 같았습니다. 저는 대대적인 정리(purge)를 단행하여 두 개의 모델만 남겼고, 새로운 모델은 영구적으로 유지될 자격을 얻기 위해 30일의 시간을 가져야 하며, 그렇지 못하면 ollama rm으로 삭제한다는 규칙을 세웠습니다. 디스크 공간은 저렴하지만 주의력(attention)은 그렇지 않으며, 모델 동물원은 작업 대신 만지작거리는 데 시간을 낭비하게 만듭니다.

버려진 것: 내 코드베이스에 대한 로컬 RAG

저는 임베딩(embedding) 기반의 "내 저장소와 채팅하기" 설정을 구축했습니다. 만드는 과정은 즐거웠지만 사용하는 데는 쓸모가 없었습니다. 코드의 경우, 약간의 고민을 곁들인 grep이나 ripgrep이 거의 매번 시맨틱 검색(semantic search)을 압도했습니다. 왜냐하면 코드에서는 보통 제가 찾고자 하는 문자열(literal string)을 정확히 알고 있기 때문입니다.
RAG 스택은 유지 관리해야 할 인덱스(index)를 추가했을 뿐만 아니라, 신뢰를 깎아먹을 정도로 자주 근처에 있지만 틀린 청크(chunk)를 반환했습니다. 후회 없이 삭제했습니다.

클라우드가 여전히 확실히 승리하는 영역

솔직한 이야기를 해보겠습니다. 저는 로컬 전용(local-only)이 아니며, 그런 척하지도 않습니다.

긴 컨텍스트 (Long context). 모델이 전체 프로토콜, 여러 계약서, 그리고 그들 사이의 상호작용을 모두 머릿속에 담아야 할 때, 그것은 제 하드웨어가 원활하게 실행할 수 있는 범위를 넘어섭니다. 그런 작업은 Claude가 맡습니다.

에이전트적 작업 (Agentic work). 모델이 계획을 세우고, 도구(tool)를 사용하며, 결과를 읽고, 경로를 조정하는 다단계 작업입니다. 작은 로컬 모델들은 세 번째 단계에서 무너지거나, 맥락을 놓치거나, 루프(loop)에 빠집니다. 에이전트 형태의 작업은 무엇이든 두 번 생각할 것도 없이 클라우드로 보냅니다.

최종 판단 (Final-pass judgment). 저의 보안 파이프라인은 깔때기 구조입니다. 로컬 모델이 모든 것에 대해 넓고, 저렴하며, 프라이빗한 1차 검사를 수행하고, 신호(signal)가 가장 높은 후보들이 최종 판결을 위해 프런티어 모델(frontier model)로 넘어갑니다. 로컬 레이어의 역할은 비싼 레이어의 입력값을 작게 만드는 것입니다.

이 과정에서 나타난 패턴은 계획된 것은 아니었지만 매우 깔끔합니다: 로컬 모델은 읽고 필터링하며, 클라우드 모델은 추론하고 결정합니다.

비용

루프에 로컬 모델을 도입하기 전에는, 집중적인 감사(audit) 작업 중에 모든 것을 클라우드 API로 보냈을 때 월간 청구서가 저를 움찔하게 만들 정도였습니다. 월 중간에 대시보드를 확인하게 되는 그런 종류의 비용 말입니다.

이제 로컬 레이어(local layer)가 원시 토큰 볼륨(raw token volume)의 대부분을 흡수합니다. 모든 요약, 모든 분류, 모든 1차 검토가 오직 전기 요금만을 발생시킬 뿐입니다. 클라우드에 남은 것은 훨씬 더 적은 수의, 훨씬 더 난도가 높은 호출(calls)과 대화형 작업을 위한 구독료뿐입니다. 저의 총 AI 지출은 제 워크플로우를 전부 클라우드 버전으로 사용했을 때의 비용 중 극히 일부에 불과하며, 그만큼 중요한 점은 비용이 일정하고 예측 가능하다는 것입니다. 저는 더 이상 제 도구 사용량을 제한하지 않으며, 제한 없이 사용할 수 있는 도구는 더 많이 사용되게 되고, 이는 다시 복리로 작용합니다.

금전적이지 않은 항목도 하나 있습니다. NDA(비밀유지계약)가 체결된 계약 코드는 1차 검토 과정 동안 절대 제 기기를 벗어나지 않습니다. 보안 관련 업무의 경우, 일부 고객들은 저보다 이 점을 더 중요하게 여깁니다.

스택(stack) 요약

Runtime:      Ollama on WSL2
Fast model:   qwen2.5-coder:1.5b  (요약, 분류, 사전 필터링)
Deep model:   qwen2.5-coder:7b    (검토, 구조화된 결과물, 분류/트리아지)
...

지난 6개월을 관통하는 주제가 있다면, 그것은 바로 '뺄셈'입니다. 스택은 더 작아짐으로써 더 좋아졌고, 모든 삭제 작업은 남은 구성 요소들을 더 신뢰할 수 있게 만들었습니다.

여러분은 올해 자신의 설정에서 무엇을 제외했나요? 그리고 그것이 그리운가요?