🔥 Gemma 4를 MacBook에서 돌려 Codex CLI 에이전트 코딩을 해봤다

#Gemma 4#Codex CLI#로컬 LLM#llama.cpp#에이전트 코딩

1060자

12분

강의 목차

tool calling 정확도가 13배 뛰었다
실험 셋업: MacBook Pro vs Dell GB10
삽질의 역사
- Mac: Ollama는 포기하고 llama.cpp로
- GB10: vLLM 실패, Ollama 성공
벤치마크: 속도가 아니라 품질이다
- 속도 역전의 비밀: MoE 아키텍처
그래서 로컬 모델, 쓸 만한가
참고 자료

content image

솔직히 "로컬 모델로 에이전트 코딩"이라는 말을 들으면 반사적으로 의심부터 했다. 파일을 읽고, 코드를 쓰고, 테스트를 돌리고, 패치를 적용하는 게 에이전트 코딩인데 — 로컬 모델이 tool calling을 제대로 할 수 있어야 이 중 어느 하나라도 가능하다. 이전 세대 모델들은 이걸 못 했다. 100번 중 93번 실패하는 수준이었다.

그런데 Daniel Vaughan의 이 글을 읽고 생각이 바뀌었다. Gemma 4를 자기 맥북에 올려서 Codex CLI를 돌려봤는데, 진짜로 된다는 거다. 하루를 꼬박 투자해서 삽질한 기록이 생생하게 담겨 있어서, 나도 한번 정리해 봤다.

tool calling 정확도가 13배 뛰었다

로컬 에이전트 코딩이 갑자기 가능해진 건 한 가지 숫자 때문이다.

Gemma 3 27B의 tau2-bench function calling 정확도는 6.6%였다. 100번 tool call을 시도하면 93번 실패한다는 뜻이다. 에이전트가 파일 하나 읽는 것도 운에 맡겨야 하는 수준. 이런 모델을 Codex CLI에 연결해봤자 의미가 없다.

Gemma 4 31B는 같은 벤치마크에서 86.4%를 찍었다. 6.6에서 86.4로. 이건 점진적 개선이 아니라 카테고리 자체가 바뀐 것이다. "안 되던 게 되기 시작했다"가 가장 정확한 표현이다.

2026년 4월 2일에 릴리즈된 Gemma 4는 네 가지 크기로 나온다. E2B, E4B, 26B MoE, 31B Dense. 에이전트 코딩에 쓸 만한 건 위쪽 두 개다. Daniel Vaughan이 테스트한 것도 이 둘이다.

실험 셋업: MacBook Pro vs Dell GB10

Daniel은 두 대의 머신을 준비했다.

머신 1: 24GB M4 Pro MacBook Pro

모델: Gemma 4 26B MoE (Q4_K_M 양자화)
추론 엔진: llama.cpp (Homebrew 설치)
메모리 대역폭: 273 GB/s LPDDR5X

머신 2: Dell Pro Max GB10

모델: Gemma 4 31B Dense (Q4_K_M 양자화)
추론 엔진: Ollama v0.20.5
메모리: 128GB 통합 메모리, NVIDIA Blackwell GPU
메모리 대역폭: 273 GB/s LPDDR5X

베이스라인: 클라우드 GPT-5.4 (high reasoning effort)

세 환경 모두 Codex CLI v0.120.0에서 동일한 코드 생성 태스크를 실행했다. codex exec --full-auto로 parse_csv_summary 파이썬 함수를 작성하고, 에러 핸들링을 넣고, 테스트를 쓰고, 실행까지 하는 전체 사이클이다.

삽질의 역사

두 머신 모두 첫 시도에서 실패했다. 이 부분이 원문에서 가장 읽을 만한 대목이다.

Mac: Ollama는 포기하고 llama.cpp로

처음에는 Ollama로 시작했다. 가장 간단한 경로니까. 그런데 두 가지 버그가 동시에 터졌다.

첫 번째, v0.20.3의 스트리밍 버그. Gemma 4의 tool call 응답이 tool_calls 배열이 아니라 reasoning 출력 쪽으로 잘못 라우팅된다. 모델이 도구를 호출하려고 하는데 하네스가 그걸 독백으로 인식하는 거다.

두 번째, Flash Attention 프리즈. Gemma 4의 하이브리드 어텐션 아키텍처(256차원 슬라이딩 윈도우 + 512차원 글로벌 헤드)를 Ollama의 FA 커널이 Apple Silicon에서 제대로 처리하지 못한다. 500토큰 넘는 프롬프트에서 행이 걸리는데, Codex CLI의 시스템 프롬프트만 27,000토큰이다. 시작도 못 하고 멈춘다.

llama.cpp로 갈아탔다. 작동하는 서버 커맨드의 플래그 6개가 전부 필수다:

bash

llama-server \
  -m /path/to/gemma-4-26B-A4B-it-Q4_K_M.gguf \
  --port 1234 -ngl 99 -c 32768 -np 1 --jinja \
  -ctk q8_0 -ctv q8_0

bash

llama-server \
  -m /path/to/gemma-4-26B-A4B-it-Q4_K_M.gguf \
  --port 1234 -ngl 99 -c 32768 -np 1 --jinja \
  -ctk q8_0 -ctv q8_0

24GB에서는 모든 플래그가 의미를 가진다. -np 1은 단일 슬롯으로 제한해서 KV 캐시 메모리 폭발을 막는다. -ctk q8_0 -ctv q8_0은 KV 캐시를 양자화해서 940MB를 499MB로 줄인다. --jinja는 Gemma 4의 tool calling 템플릿에 필수다. -m에 GGUF 직접 경로를 쓰는 건, -hf 플래그가 1.1GB짜리 비전 프로젝터를 몰래 다운로드해서 OOM 크래시를 내기 때문이다.

Codex CLI 설정에서 web_search = "disabled"도 넣어야 한다. Codex CLI가 보내는 web_search_preview 도구 타입을 llama.cpp가 거부하기 때문이다. 이 중 어느 하나도 공식 문서에 제대로 정리된 곳이 없다.

GB10: vLLM 실패, Ollama 성공

원래 계획은 vLLM이었다. 그런데 vLLM 0.19.0의 컴파일된 익스텐션이 PyTorch 2.10.0 기준으로 빌드되어 있고, aarch64 Blackwell(sm_121)에서 사용 가능한 CUDA 지원 PyTorch는 2.11.0+cu128뿐이다. ABI가 다르다. ImportError.

결국 Ollama v0.20.5가 답이었다. Apple Silicon에서 터지던 스트리밍 버그가 NVIDIA에서는 재현되지 않는다. ollama pull gemma4:31b, SSH 터널로 포트 포워딩, codex --oss -m gemma4:31b. 첫 시도에 작동.

Mac 셋업에 오후 내내 걸렸고, GB10은 1시간이었다.

벤치마크: 속도가 아니라 품질이다

세 환경의 결과가 극적이다.

클라우드 GPT-5.4: 타입 힌트, 예외 체이닝, boolean 타입 감지, 깔끔한 헬퍼 함수. 데드 코드 제로. 테스트 5개 첫 시도에 통과. 65초.

GB10 (31B Dense): 타입 힌트나 boolean 감지는 없지만 에러 핸들링이 탄탄하고 데드 코드가 없다. 테스트 5개, 첫 시도, tool call 3번. 7분.

Mac (26B MoE): 구현 도중 타입 추론 루프를 작성하다 포기하고 아래에 다시 쓰면서 "Actually, let's simplify"라는 주석을 소스에 남겼다. 테스트 파일은 5번 만에 작성. 매번 셸 heredoc 쿼팅에서 문법 오류가 터졌다. Tool call 10번. 4분 42초.

속도 역전의 비밀: MoE 아키텍처

llama-bench 기준 Mac이 GB10보다 토큰 생성이 5.1배 빠르다. 두 머신의 메모리 대역폭이 273 GB/s로 동일한데 이 차이는 어디서 올까.

답은 MoE(Mixture of Experts) 아키텍처에 있다. 토큰 생성은 메모리 대역폭에 병목이 걸린다. 매 토큰마다 활성 파라미터를 메모리에서 읽어야 하기 때문이다.

31B Dense는 매 토큰마다 312억 개 파라미터를 전부 읽는다. Q4 양자화 기준 약 17.4GB. 273 GB/s로 나누면 초당 약 10토큰.

26B MoE는 128개 전문가 중 8개만 활성화해서 토큰당 38억 개만 읽는다. 약 1.9GB. 같은 대역폭에서 초당 52토큰. 같은 파이프에 5분의 1만 흘려보내니까 5배 빠른 거다.

그런데 핵심은 여기다. Mac이 5.1배 빠르게 토큰을 생성했는데도 전체 작업은 30%만 빨랐다 (4분 42초 vs 6분 59초). 속도의 이점 대부분을 재시도가 잡아먹었다. 10번의 tool call 대 3번. 5번의 실패한 테스트 작성. 치우지 않은 데드 코드.

느리지만 한 번에 맞추는 모델이, 빠르지만 여러 번 돌려야 하는 모델을 이겼다.

클라우드 모델이 이걸 가장 극명하게 보여준다. 가장 빠른 시간, 가장 적은 토큰, 가장 높은 품질. 65초에 만점.

그래서 로컬 모델, 쓸 만한가

Daniel의 결론은 "하이브리드"다. codex --profile local로 반복 작업이나 프라이버시가 중요한 코드에 쓰고, 복잡한 작업은 클라우드를 유지한다. Codex CLI의 프로파일 시스템이 전환을 플래그 하나로 만들어주니까 가능한 전략이다.

이 글에서 진짜 중요한 건 벤치마크 숫자가 아니다. Gemma 3에서 4로 넘어오면서 tool calling이 6.6%에서 86.4%로 뛴 것, 그게 전부다. "안 되는 것"에서 "되는 것"으로의 전환. 이 한 단계가 로컬 에이전트 코딩을 현실로 만든 진짜 변화다.

클라우드 모델의 품질에는 아직 못 미친다. GPT-5.4가 65초에 해치운 걸 로컬은 5~7분 걸리고, 코드 품질도 한 수 아래다. 하지만 세 환경 모두 "작동하는 코드와 통과하는 테스트"를 만들어냈다. API 비용이 부담되거나, 코드가 외부 서버를 떠나면 안 되거나, 클라우드가 죽었을 때 백업이 필요하다면 — 이제 로컬이 진지한 선택지다.

Gemma 4가 나온 지 2주도 안 됐다. Ollama의 Apple Silicon 버그가 수정되고, 양자화 기법이 개선되면 상황은 또 달라질 것이다. "로컬에서 에이전트 코딩이 되느냐"라는 질문에 대한 답은 이 글로 나왔다. 된다. 다만 아직 완벽하지는 않을 뿐이다.