시작 동기는 '의존 탈출'이 아니라 '토큰 절약'이었다
거창하게 시작하지 않았다. AI 없이도 살 수 있다는 걸 증명하려 한 게 아니라, 그냥 토큰이 아까웠다. 한 주에 수억 토큰을 태우며 5시간·주간 한도를 연달아 바닥냈다. 마침 Gemma 4가 나오며 로컬 모델 성능이 좋아졌다는 이야기가 돌았고, "가벼운 일은 로컬로 돌리면 되겠다"는 계산이 섰다.
그런데 토큰 아끼려고 시작한 일이, 어느새 'AI에 이렇게까지 기대도 괜찮은가'라는 질문 앞에 나를 세워놓았다.
집 PC: 12GB GPU의 벽
먼저 집 윈도우 PC에 Ollama를 깔고 Gemma 계열 모델을 올렸다. 결론은 빨랐다. 12GB로는 컨텍스트가 너무 작아 실전에 거의 쓸 수 없었다.
이유를 짚자면: GPU 메모리는 모델 가중치를 올리고, 남은 걸로 KV 캐시(어텐션이 참조하는 키·밸류 텐서)를 채운다. KV 캐시는 컨텍스트 길이에 비례해 선형으로 불어난다. 코딩 에이전트가 도구 정의와 파일 맥락만으로 수만 토큰을 쓰는데, 가중치 올리고 남은 자투리 메모리로는 그 창을 감당하기 어렵다.
회사 맥북 4대 클러스터: 새로운 벽들
마침 회사에 놀고 있는 맥북 4대가 있었다. 남는 장비를 묶어 사내용 로컬 에이전트를 꾸리기 시작했다. 단일 머신에선 보이지 않던 문제들이 줄줄이 나왔다.
첫 응답이 느렸다. 풀 툴 컨텍스트(약 22k 토큰) prefill에 약 60초가 걸렸다. 클라우드의 즉답에 길든 손에는 너무 긴 시간이었다.
더 뼈아픈 건 트레이드오프였다. Ollama에는 prefix KV 캐시가 있다. 같은 시스템 프롬프트·도구 정의를 재사용하면 prefill을 건너뛴다. 실측으로 약 3.2초 → 0.03초, 100배 차이가 났다.
그런데 요청을 4대에 분산하면 매번 새 세션이 되면서 이 캐시가 죽는다. 빠르게 하려면 캐시를 살려야 하고, 캐시를 살리려면 한 곳에 붙어 있어야 한다. 분산과 캐시가 정면으로 충돌했다.
캐시 동작 원리와 게이트웨이 구조 설계 과정은 원문에서 자세히 다룬다.
👉 k3nta.com 원문 전체 읽기
엔진 교체와 게이트웨이 패턴으로 풀다
Ollama는 유휴 상태가 되면 모델을 내려버렸고, keep_alive=-1로 붙잡아도 긴 요청에선 매번 60초가 다시 났다. Ollama를 버리고 llama.cpp의 llama-server로 갈아탔다. 프로세스가 살아 있는 한 모델을 내리지 않아 캐시가 지속됐다.
분산 문제는 구조를 바꿔 풀었다. 게이트웨이 한 곳에서 페르소나·검색·맥락을 붙인 완성된 프롬프트를 만들어 워커로 넘겼다. 워커가 각자 프롬프트를 조립하면 공백 하나 차이로도 llama.cpp의 prefix 캐시 매칭이 깨진다. 게이트웨이가 결정론적으로 프롬프트를 완성해 넘기니 분산하면서도 캐시를 높은 확률로 유지할 수 있었다.
26B MoE가 12B Dense보다 빠른 이유
처음엔 더 가벼운 Gemma 12B면 충분할 줄 알았다. 그런데 12B가 26B보다 오히려 느렸다.
26B는 MoE(Mixture of Experts) 모델이다. 토큰 하나를 처리할 때 실제로 켜지는 전문가는 약 4B뿐이다(모델명 26b-a4b의 a4b가 '활성 4B'). 반면 12B는 dense라 매 토큰마다 12B 전부가 연산에 들어간다.
토큰 생성은 메모리 대역폭이 병목인 작업이다. 26B-MoE는 토큰당 4B만 읽으면 되는데 12B-dense는 12B를 통째로 긁어와야 한다. '작은 모델이 빠르다'는 직관은 dense 모델끼리일 때만 맞다.
그래도 복잡한 추론과 대규모 리팩터링은 여전히 클라우드가 안정적이었다. "로컬로 다 옮긴다"가 아니라 "가벼운 일만 로컬로"라는 계산이 실측 앞에서 더 좁아졌다.
보안 이슈에 막히다
사내 협업 도구들과 본격 연동하려던 시점에 멈췄다. 협업 도구 곳곳에 자격증명이 평문으로 노출돼 있었다. 로컬 LLM이 그 도구들을 에이전트 맥락으로 빨아들이면, 질문에 답하다 평문 자격증명이 흘러나오거나 에이전트가 권한 밖 동작을 할 위험이 있었다. 프로젝트는 보류됐다.
토큰 아끼려는 실험이 역설적으로 조직의 보안 위생을 들춰낸 셈이다.
그래서, AI 의존과 정면으로 마주쳤다
클라우드 AI가 먹통이 되면 손을 놓게 된다. AI 없이 코딩을 못 하는 건 아닌데, 효율이 극악으로 떨어진다. 한 줄씩 직접 칠 시간에 AI가 복구되길 기다리며 프롬프트를 다듬는 편이 낫다고 느낄 정도로.
fallback 전략은 있다. 한 모델이 죽으면 다른 모델을 쓴다. 그런데 둘 다 죽으면? 셋 다 구독해야 한다. 쓰지도 않는 안전망에 매달 비용을 붓는 셈이다. 그리고 세 모델이 한꺼번에 죽는다면, 지금으로선 답이 보이지 않는다.
이 말에 팀원들도 깊이 공감했다. 혼자만의 과민함이 아니라, 우리 모두가 같은 절벽 위에 서 있었다.
로컬 LLM은 답이었나 — 부분적으로만
비용 절감과 프라이버시, "끊겨도 돌아간다"는 안심은 실재했다. 하지만 첫 응답 60초와 품질 천장은 분명한 벽이었다.
더 값진 수확은 따로 있었다. AI를 블랙박스가 아니라, 내가 직접 운영하고 튜닝하는 대상으로 끌어내렸다는 것. KV 캐시, prefill, 양자화, 컨텍스트 길이를 손으로 만지는 동안, 역설적으로 의존이 아니라 이해가 늘었다.
AI 의존을 줄이는 건 더 강한 모델이 아니라 내가 만든 시스템이었다. 서버가 죽어도 내 검증 기준과 기록과 원리 이해는 죽지 않는다. 거기까지 만들어두는 것이, 지금 내가 찾은 답이다.
맥북 4대 셋업 상세, 게이트웨이 구조, 운영 중 마주친 함정들은 원문에서 이어진다.
👉 원문 전체 읽기 — k3nta.com
