커다란 청구서가 약속한 듯 한꺼번에 날아들었다.

GitHub Copilot이 정액제에서 토큰 기반 청구로 바꾼 첫날, 사용자 게시판은 항의로 가득 찼다. GitHub Copilot의 토큰 기반 청구 전환 첫날 반응. HedgieMarkets, x.com/hedgiemarkets — Pro+ 구독자가 2시간 만에 월 크레딧 60%를 소진했다. 같은 주에 Prof G Markets는 2026년 상반기에만 5만 건을 넘긴 ‘AI 해고’ 뒤편의 다른 계산서를 펼쳤다. 해고가 줄였다는 인건비보다 그 자리를 메운 AI가 더 비싼 경우가 잦았고, 미국 AI 스타트업의 상당수는 이미 10배에서 30배 싼 중국 오픈소스 모델로 갈아탄 뒤였다. Scott Galloway·Ed Elson, “Is AI More Expensive Than the Employees It’s Replacing?”, Prof G Markets, 2026-06-01. profgmarkets — 미국 AI 스타트업 80%가 중국 오픈소스를 쓴다는 추정. 비슷한 시기 John Burn-Murdoch는 파이낸셜타임스에서 ‘생산성 깔때기’라는 그림을 그렸다. 생성된 코드 줄 수는 17.3배로 불었는데 실제 릴리스는 30% 느는 데 그쳤다. M. Demirer·L. Musolff·L. Yang, “Writing Code vs. Shipping Code,” NBER Working Paper 35275, 2026. nber.org/papers/w35275. 프레임은 John Burn-Murdoch, FT Data Points, 2026-06-04.

자기 키보다 긴 청구서를 받아 들고 놀라는 서소영 보조금이 걷히자, 가려져 있던 단가가 한꺼번에 드러났다.

토큰을 많이 태울수록 좋다는 ‘토큰맥싱’이 한 분기 만에 끝난 까닭도 여기 있다. 토큰맥싱이 한 분기 만에 저문 과정은 지난 글에서 다뤘다. 토큰맥싱은 왜 한 분기만에 끝났나. 한계비용이 0에 가깝던 동안에는 토큰을 들이붓는 쪽이 합리적이었다. 단가가 돌아오자 합리적인 선택지가 뒤집혔다. 이 비용을 감당할 수 있나? 항상 프론티어 모델을 사용해야 하나? 대체할 수 있는 방법은 없을까? 질문들 앞에서 새로운 지표가 등장한다. 단순히 모델의 능력을 따지는 게 아니라 모델의 능력을 전력으로 나눈 값, 곧 와트당 지능이다.

스탠퍼드 Scaling Intelligence Lab이 2025년 11월에 내놓은 IPW(intelligence per watt) 연구는 이 질문을 지표로 만들었다. 20종 넘는 로컬 모델과 8종 가속기에 실제 쿼리 100만 건을 돌려, 20B 이하 로컬 모델이 단일턴 쿼리의 88.7%를 정확히 답하고, 와트당 지능이 2023년부터 2025년 사이 5.3배 개선됐음을 보였다. Saad-Falcon et al., “Intelligence per Watt,” Stanford Scaling Intelligence Lab, 2025. arXiv:2511.07885 · intelligence-per-watt.ai.

이 글은 두 가지를 정리한다. 하나는 무게중심이 프론티어 클라우드에서 로컬로 얼마나 옮겨왔는가. 다른 하나는 막상 로컬 모델을 책상에 들이려 할 때 무엇이 기다리는가. 와트당 지능이 좋아졌지만, 실제로 그 모델을 에이전트 루프에 끼워 넣는 일 사이에는 생각보다 넓은 골짜기가 있기 때문이다.

먼저 결론을 표로 둔다.

로컬에 맡길 일프론티어 API에 남길 일
코드 자동완성, 단순 리팩터복잡한 아키텍처 설계, 긴 추론 체인
요약, 번역, 포맷 정리수천 토큰을 소비하는 멀티턴 에이전트
민감 데이터가 끼는 작업응답 지연이 곧 이탈인 실시간 서비스
비동기 배치 작업신뢰성이 중요한 프로덕션 도구 호출

아래는 이 표가 왜 이렇게 갈리는지를 풀어 쓴 것이다.

새로운 기준, 와트당 지능

IPW 연구에서 가장 흥미로운 지점은 숫자가 아니라 비유다. 저자들은 개인용 컴퓨터가 메인프레임을 밀어낸 과정을 소환한다.

PC는 성능으로 메인프레임을 추월해서 이긴 것이 아니다. 워크스테이션 시대는 개인 기기의 전력 예산 안에서 사람들의 요구를 충족할 수 있게 된 순간에 열렸다. 성능 곡선이 메인프레임을 따라잡기 한참 전에, “이 정도면 내 책상 위 전력으로 충분하다"는 지점이 먼저 왔다.

저자들은 로컬 AI도 같은 곡선 위에 있다고 본다. 단일 가속기 효율로 클라우드를 이기는 그림이라기보다, 충분히 좋아진 와트당 지능과 똑똑한 라우팅이 만나면 시스템 전체의 에너지와 비용 곡선이 꺾인다는 쪽이다.

초창기 애플 1을 가리키는 서소영과, 살짝 과부하된 거대 메인프레임 초창기 개인용 컴퓨터는 거대한 메인프레임보다 성능이 뛰어나서 확산된 것이 아니었다.

이 관점이 중요한 이유는, 로컬 모델이 프론티어 모델을 벤치마크에서 꼭 이길 필요가 없다는 말이기 때문이다. 로컬 모델이 해야 할 일은 내 작업의 대부분을 차지하는 평범한 쿼리를, 내가 감당할 전력과 지연 안에서 처리하는 것이다.

로컬 모델 이야기는 어느 모델이 제일 똑똑한가의 문제로 끝나지 않고, 일감을 어디로 보낼지 정하는 분배의 문제로 넘어간다. 그 분배를 맡는 것이 라우터다. IPW가 말하는 88.7%가 그 평범한 다수다. 로컬로 처리 가능한 쿼리 비율은 2023년 23.2%에서 2025년 71.3%로 올라왔다. 하이브리드 라우팅으로 무거운 것만 클라우드에 넘기면 클라우드 단독 대비 에너지 64%, 비용 59%가 절감된다.

로컬이 실용이 된 순간

지표가 좋아진 데는 두 흐름이 겹쳤다.

하나는 오픈웨이트 모델의 약진이다. DeepSeek-R1은 수학과 코딩에서 OpenAI o1과 비슷한 수준의 결과를 공개 API 단가 기준 20배 안팎 싼 값에 낸다. DeepSeek-V3 Technical Report, arXiv:2412.19437. R1 대 o1 공개 API 단가 비교는 시점에 따라 대략 20~30배 범위로 보고된다. Qwen3는 Apache 2.0으로 풀려 상업적 사용에 부담이 없고, 일부 벤치마크에서 더 비싼 폐쇄 모델을 앞선다. Qwen3 Technical Report, arXiv:2505.09388. OpenRouter가 공개한 사용량 집계에서 오픈웨이트 모델은 2025년 말 전체 토큰 사용량의 약 3분의 1에 달한다는 수치가 나왔다. OpenRouter, “State of AI” 사용량 리포트, openrouter.ai/state-of-ai. 점유율은 집계 기간·모델 분류에 따라 달라질 수 있다. Airbnb의 Brian Chesky가 “빠르고 싸고 충분히 좋다"는 이유로 Alibaba Qwen에 크게 의존한다고 말한 것이 더는 별난 선택이 아니다.

다른 하나는 온디바이스 추론 스택이 성숙한 것이다. 맥에서는 Apple Silicon에 최적화된 MLX와 llama.cpp가 생산 수준 속도를 낸다. Ollama는 깃허브 스타 9만을 넘기며 사실상의 표준 런처가 됐다. 양자화도 한몫했다. Q4_K_M으로 누르면 원본 대비 메모리를 4분의 1만 쓰면서 정확도는 대부분의 작업에서 95% 안팎을 지킨다. 통합메모리 32GB면 30B급, 64GB 이상이면 70B Q4가 돌아간다. M4의 뉴럴 엔진이나 Snapdragon X2의 80 TOPS NPU 같은 전용 칩도 경량 모델을 거든다. Apple Silicon 프레임워크 비교, arXiv:2511.05502. 양자화·하드웨어 티어 수치는 동 자료 및 공개 벤치마크 종합. 맥 이야기가 자주 나오지만 책상 위 노트북만의 사정은 아니다. 리눅스와 엔비디아 GPU 위에서는 vLLM이 같은 역할을 맡아 서버 한 대로 여러 요청을 동시에 처리한다. 개인 기기냐 사내 추론 서버냐에 따라 손에 잡는 도구가 갈릴 뿐, 와트당 지능이라는 잣대와 라우팅이라는 해법은 양쪽에서 똑같이 작동한다.

여기까지가 좋은 소식이다. 그런데 이 모델을 막상 내 작업 흐름에 끼우려 들면, 멋진 슬라이드에는 나오지 않는 문제들이 줄줄이 터진다.

굴려 보면 만나는 세 개의 벽

엉킨 톱니 기계와 반복 출력 말풍선에 씨름하며 당황한 서소영 툴콜이 깨지고, 기기를 통째로 잡아먹고, 속도가 발목을 잡는다.

로컬 모델을 실제로 도입한 사람들의 후기를 모으면, 고생담이 세 갈래로 갈린다.

1. 에이전트 루프에 끼우는 일이 전부 수작업이다

채팅창에 질문을 던지는 것과, 모델을 도구 호출이 오가는 에이전트 루프에 넣는 것은 난이도가 다른 일이다.

가장 흔한 증상은 도구 호출이 깨지는 것이다. 한 사용자는 llama3.2:3b가 tool_calls 필드를 비워 둔 채, 실행해야 할 JSON을 그냥 본문 텍스트로 길게 설명하더라고 적었다. 에이전트는 도구를 부르는 대신 “이런 JSON을 부르면 됩니다"라는 벽 같은 문장을 생성하고, 작업은 멈춰버린다. ollama/ollama GitHub Issue #13519 (2025.12). 추론 모델의 의미 단위 반복은 llama.cpp 샘플러 논의(#21375 등)에서 다뤄진다. 추론 모델에서는 다른 증상이 나온다. Qwen3나 DeepSeek-R1이 생각 단계에서 의미는 같고 토큰만 다른 문장을 끝없이 반복하며 빠져나오지 못한다. 토큰 단위로 도는 기존 repeat_penalty로는 이 의미 단위 반복을 못 잡는다.

해법은 대체로 세 갈래다. 첫째, 모델을 잘 고른다. 7B 이하는 도구 호출 신뢰도가 낮으니 최소 Qwen2.5-14B나 Mistral Small 24B처럼 함수 호출이 검증된 모델에서 시작한다. 둘째, 엔드포인트와 템플릿을 정확히 맞춘다. Ollama의 OpenAI 호환(/v1) 경로와 네이티브 경로는 도구 호출 포맷이 달라, 한쪽에서 멀쩡하던 것이 다른 쪽에서 깨진다. 셋째, 출력 자체를 문법으로 강제한다. llama.cpp의 GBNF 같은 grammar 제약을 걸면 모델이 토큰을 뱉는 단계에서 스키마를 벗어나지 못한다. temperature를 0에 가깝게 낮추는 것만으로 포맷 일관성이 눈에 띄게 좋아지기도 한다.

2. 기기 한 대를 통째로 잡아먹는다

로컬 추론은 점잖게 자원을 나눠 쓰지 않는다. 모델 하나가 VRAM과 통합메모리를 거의 다 차지한다. 그래서 IDE의 코파일럿을 켠 채로 같은 기계에서 별도 추론 세션을 하나 더 띄우려 들면 곧장 막힌다.

한 엔지니어는 라우팅 실험을 적으며 “유휴 상태 뒤 첫 쿼리가 8초 걸렸다. Ollama가 모델을 메모리에 올리는 시간이었고, 그대로 타임아웃이 났다"고 했다. M. Hannecke, “Implementing LLM Model Routing: A Practical Guide with Ollama and LiteLLM,” Medium. 두 모델을 번갈아 쓰면 전환마다 30초에서 100초씩 재로딩이 붙는다. 한 명이나 두 명만 붙어도 기계가 포화한다는 후기도 흔하다.

이 벽은 큰 모델 하나에 전부 거는 대신 구조를 바꿔 푼다. 작은 라우터 모델(3B에서 7B)을 상시 메모리에 올려 두고 들어온 요청을 분류한 뒤, 무거운 것만 큰 모델을 깨워 넘긴다. vLLM의 PagedAttention은 KV 캐시 낭비를 크게 줄여 같은 메모리로 동시 요청 처리량을 두 배에서 네 배로 올린다. 2025년에 추가된 vLLM의 슬립 모드는 모델을 완전히 내렸다 다시 올리는 대신 0.3초에서 0.8초 만에 깨운다. 전체 재로딩이 수십 초인 것과 비교하면 차이가 크다. 양자화로 한 모델의 발자국을 줄여 두 번째 모델이 들어설 자리를 내는 것도 기본기다.

3. 초당 토큰 수가 프론티어를 못 따라간다

체감 속도는 숫자로 보면 분명하다. M3나 M4 맥스급에서 70B Q4 모델은 초당 6~10토큰 언저리다. llama.cpp GitHub Discussion #4167 및 Apple Silicon 실측 모음. 70B Q4 기준 M3/M4 Max에서 6~15 t/s 범위. 짧은 답이면 견딜 만하지만, 에이전트가 여러 턴을 돌며 긴 출력을 누적하는 작업에서는 지연이 쌓여 손이 멈춘다. 한 후기는 첫 응답이 초당 8토큰으로 나오는 걸 두고 “페인트 마르는 걸 지켜보는 기분"이라 적었다. “How I Doubled My Local LLM’s Speed,” Medium / “Local LLM Code Completions Are Slow,” DEV Community. 대화형 작업에서 초당 20토큰 아래로 떨어지면 대부분의 사용자가 멈춘 것으로 느낀다는 관찰도 있다.

속도를 끌어올리는 손잡이는 여럿이다. 작은 모델이나 활성 파라미터가 적은 MoE 구조를 고르는 것이 가장 직접적이다. 투기적 디코딩(speculative decoding)은 조건이 맞으면 두세 배까지 올려 주지만, MoE 모델에서는 거꾸로 느려지는 경우가 보고됐으니 dense 모델에서만 믿는 편이 안전하다. KV 캐시 양자화, 플래시 어텐션, 컨텍스트 길이 축소도 각각 여유를 만든다. 그래도 안 되면, 무거운 추론은 클라우드로 넘기는 하이브리드가 정답이다.

그래서 어떻게 시작하나

세 칸 사다리를 오르며 클라우드 구름으로 손을 뻗는 서소영 작게 시작해 한 칸씩. 무거운 것만 클라우드로 폴백한다.

실제로 도입한 사람들이 권하는 경로는 의외로 소박하다. 처음부터 라우팅이니 vLLM이니를 고민할 필요가 없다.

1단계, 5분짜리 첫 경험. ollama pull로 Llama 3.1 8B Q4를 받아 채팅과 요약, 단순 코드 작업부터 굴려 본다. 통합메모리 16GB 맥이나 16GB VRAM GPU면 체감이 온다. 목적은 성능 측정이 아니다. “내 기계에서 이게 이만큼 되는구나” 하는 현실 감각을 얻는 것이다.

2단계, 단발 에이전트 호출. 코드 작업이면 Qwen2.5-Coder 14B나 32B로 올린다. 루프에 넣기 전에 curl로 단발 도구 호출을 먼저 테스트해, 이 모델이 함수 호출을 제대로 뱉는지부터 확인한다. 여기서 1번 벽을 미리 만나 두는 편이 낫다.

3단계, 라우팅. LiteLLM 같은 프록시를 앞에 두고 작업을 세 층으로 나눈다. 포맷팅이나 단순 조회 같은 다수(대략 70%)는 3B 모델에, 중간 추론(20%)은 7B에, 멀티스텝 계획(10%)은 32B에 보낸다. 그리고 복잡한 추론이나 타임아웃은 클라우드로 폴백한다. 라우팅을 짜 본 한 엔지니어는 비용 절감보다 더 큰 이득으로 “라우팅이 LLM이 실제로 무슨 일을 하는지 이해하도록 강제한다는 점"을 꼽았다.

이 분담이 맨 앞의 표다. 로컬은 자주 일어나고 가벼우며 지연에 너그러운 일을 맡고, 프론티어는 드물지만 무겁고 신뢰가 중요한 일을 맡는다.

작업 분배를 다시 할 시간

일감 카드를 로컬 바구니와 API 바구니로 분류하는 서소영 이건 로컬로, 저건 API로. 자기 작업표부터 나눠 보는 일.

토큰맥싱이 끝난 자리에 들어선 질문은 “가장 큰 모델이 무엇인가"에서 “이 일에 맞는 적절한 지능을 가진 모델이 무엇인가"로 옮겨갔다. 와트당 지능은 그 질문을 재는 자이고, 로컬 모델은 그 자 위에서 빠르게 올라오는 선택지다.

당장 모든 걸 로컬로 내릴 이유는 없다. 로컬이 못 넘는 영역은 여전히 또렷하다. 가장 좋은 70B 로컬 모델도 복잡한 추론에서 프론티어와 10점에서 20점쯤 벌어지고, 100만 토큰 컨텍스트를 광고하는 모델도 실제로 믿고 쓸 수 있는 범위는 절반 남짓이다. 프라이버시나 규제 때문에 로컬을 고르는 경우와 순수하게 비용 때문에 고르는 경우도 구분해야 한다. 규제 탓이라면 느린 속도도 감수하지만, 비용 때문이라면 얘기가 달라진다.

그래도 방향은 분명하다. 한번 자기 작업 목록을 펼쳐 놓고, 어느 칸을 로컬에 넘기고 어느 칸을 프론티어에 남길지 표로 나눠 보는 일. 거기서부터 자기 손에 맞는 분담이 시작된다.