올해 초 OpenClaw가 출시되어 깃헙에서 폭풍을 일으킬 때의 나는 OpenClaw가 철저한 쓰레기이고 스캠인 프로젝트에 이렇게나 많은 관심이 모인다는 사실이 너무 어이가 없게 느껴졌다. 그렇게 판단한 근거는 결국 OpenClaw도 클로드 코드, 코덱스와 동일한 하나의 하네스일 뿐이고, 그 중에서도 가장 위험한 형태의 하네스라고 판단했기 때문이다. 이것이 위험하다고 생각한 첫 번째 이유는 이미 AI가 내린 판단으로 인해 생기는 문제가 많은데, 그 잘못된 판단으로 인한 실행을 위임한다는 것은 사용자가 책임질 수 없는 영역까지 위임하는 것이 위험하다고 생각했으며, 두 번째는 책임의 영역이 넓어지면서 다루는 문제의 영역이 넓어지고, 결국 자연스럽게 더 넓은 영역의 개인 정보를 침해할 것이라고 생각했기 때문이다.
이 개인정보 문제에 대해 관대한 사람들이 절대 다수인 입장에서 설득력이 높지는 않다고 느끼고 결국 이미 나오던 말을 재방송하는 격이라 새삼스럽지만, 나는 GPT 등장 이후로 역사상 사용자의 개인정보를 수집하기 가장 쉬운 시대가 되었다고 생각한다. 모델 공급자들은 사람들이 일반적으로 자신의 친구들이나 가족들에게도 하지 못할 개인적인 정보를 아주 손쉽게 획득하고 있으며, 심지어 이를 학습에 사용하고 있다. 채팅이라는 인터페이스가 사용자의 경계심을 무너뜨리기 쉽기 때문에 이런 모델을 통한 정보 유출은 결국 사용자가 어떤 정보를 줄지 판단하고 선제적으로 제한하는 것 외에는 방법이 없다고 생각하고, 그래서 나는 코딩용 AI는 코딩 외에 사용하지 않고, 일반 목적 AI는 가능한 한 가치중립적인 이야기를 위주로 대화했었다. Meta가 프런티어 모델 경쟁에서 실패한 것이 정말 다행이다.
점점 확대되는 하네스의 권한 및 책임과 모델 공급자의 정보 독점적 지위를 회피할 수 있는 방법에 대해 생각하면서 개인적인 관심은 점점 로컬 모델 쪽으로 기울기 시작했다. 엄밀히는 조금 다르겠지만, 오픈 웨이트 모델들 및 로컬 모델들1은 결국 데이터가 디바이스 밖으로 나가지 않는다는 점에서 보안상 압도적 강점이 있다고 생각한다. 다만 데이터센터의 압도적 연산력을 활용할 수 있는 클라우드 모델들에 비해 성능이 부족할 수밖에 없음을 감수하는 것이 모든 장점을 잡아먹는다. 민감 정보를 처리할 수 있다고 로컬 모델을 세팅해서 온갖 작업을 시켰더니 작업 내용을 다 지워버리거나 기본 프롬프트만으로도 맥락 부족에 허덕이면 아무 짝에도 쓸모없을 것이다.
이후 몇 달이 지나는동안 몇 가지 코믹한 사건들이 터지긴 했지만 OpenClaw클가 일으켰다고 할만한 재앙적인 사건은 없었다. 생각보다 주어지는 하네스의 자유도에 비해 모델이 할 수 있는 기상천외한 일은 별로 없었던 듯하다. 그만큼 OpenClaw를 잘 쓰는 사례도 소수로 남았으며, 나머지 사용자들에게는 채팅 인터페이스랑 별반 다르지 않거나 거기에서 캘린더 조금 만지작거리는 정도의 장난감으로 남은 듯하다. 열풍이 지나간 후에 아주 보수적인 샌드박스에서 실행해 본 경험으로는, 역시 권한을 적게 줄수록 할 수 있는 것들도 줄어들 수밖에 없음을 느꼈다.
이 때 즈음 갑작스럽게 오픈 웨이트 모델의 경쟁 시대가 열렸었는데, 프런티어 모델들의 경쟁에 비하면 별 볼일 없을 수 있어도 나에게는 로컬에서 두세 세대 전 프런티어 모델과 몇몇 부분에서 경쟁하는 점수를 낸다는 점이 놀라웠다. 이번에는 반드시 테스트해봐야겠다는 생각으로 맥 스튜디오를 구해서 그때부터 본격적으로 로컬 모델에 대해 공부하기 시작했다. 이제 1달차가 되어가는 김에 공부했던 내용들을 정리하는 차원에서 글을 남긴다.
왜, 무엇을
입출력이 무엇이 되었든 모델은 멀리서 보면 하나의 API 엔드포인트일 뿐이라 뭔가 생산적인 것을 하지 않으면 토이 프로젝트로 만든 todo list의 백엔드보다 쓸모가 없다. 코딩이라는 일정한 입력이 주어지는 과제를 해결하기에는 로컬 모델의 강점이 살지 않는다. 결국 OpenClaw처럼 실행의 영역에 손을 대서 일반적인 AI로 할 수 없는 월권 행위의 가능성을 열어줘야겠다고 생각했고, 그렇게 찾던 중 OpenClaw의 유사품 Hermes를 찾아보게 되었다.
이 때 즈음하여 유행어처럼 떠돌던 하네스 엔지니어링에 대해서도 나를 비롯한 사람들의 이해도가 늘어갔다고 생각한다. 내가 느낀 하네스가 만들어내는 가장 큰 차별점은 스스로 문제를 개선할 수 있는가였다고 생각한다. 모델의 성능이 나빠 특정 도메인의 물건들을 잘 구별하지 못한다고 해도, A와 B는 다르다라는 사실이 기억되기만 해도 최소한 A와 B를 구분하는 문제에 대해서는 같은 모델 대비 월등한 성능을 보여줄 것이다. 스스로를 개선할 수 있는 추가 프롬프트는 여러 가지가 있겠지만 결국 기억의 문제로 회귀하는 느낌을 받았다. 기억이 잘 관리되어 중요한 내용들이 맥락에 많이 남고 중요하지 않은 내용들은 장기 기억 장치에 저장되는 구조의 하네스는 몇 번 대화하고 나면 답변이 크게 나아지는 경험을 많이 했었다.
Hermes는 무엇보다 이 메모리 엔진을 plain text부터 복잡한 외부 서비스까지 폭넓게 선택할 수 있다는 점이 선택에 큰 영향을 끼쳤다. 사용하다보면 종종 사용자와의 답변이 끝난 뒤에도 API 호출을 통해 다른 여러 동작들을 하는 것을 확인할 수 있었는데, 해당 호출을 통해 메모리를 보강하든 사용자 정보를 업데이트하든 자가 개선 동작들을 수행하는 점이 내가 하고자 하는 실험과도 결이 맞는다고 생각하여 선택하게 되었다.
로컬 모델 시작하기
기기
로컬 모델은 다분히 자본이 많이 들어가는 취미생활이며 장비빨이 매우 중요하다. 특히나 장비 가격이 계속 오르고 있는 시기에는 더더욱. 아직 오른 가격이 반영되지 않았던 것도 맥 스튜디오를 선택한 계기 중 하나였다.
장비를 선택하는 제1기준은 메모리(VRAM)여야 한다. 일단 메모리에 모델 및 필요 여유 공간을 올리지 못하면 아무 것도 시작할 수 없다. 일반적인 컴퓨터를 세팅하게 되면 CPU가 사용하는 영역의 메모리(RAM)와 GPU가 사용하는 영역의 메모리(VRAM)이 있어 VRAM에 올려야 할 내용이 있으면 일단 RAM에 올라가야 하기 때문에 메모리 요구량이 크게 올라간다. 모델 크기가 40GB면 (최소 여유 10GB를 더해) 50+50=최소 100GB는 있어야 하는 것이다. 애플 기기들은 특이하게 CPU와 GPU가 쓸 메모리 공간을 구분하지 않은 설계를 선택하여 두 칩이 같은 영역에 읽고 쓸 수 있도록 설계하여, 위의 예시에서 50GB만으로 40GB 모델을 올릴 수 있게 되는 것이다.
두 번째는 성능일텐데, 모델들이 결과물을 낼 수 있도록 연산을 가속하는 방식이 크게 다르다. Nvidia와 애플만 두고 보면 각각 CUDA와 Metal이라는 프로토콜을 통해 연산을 가속하는데, 이 가속 여부에 따라 연산 속도가 크게 차이나기 때문에 한쪽 방식으로 최적화된 백엔드(후술)는 다른 기기에서는 끔찍한 성능을 보인다. 일반적으로 같은 가격의 장비를 기준으로 비교하면 일반적으로 CUDA 최적화된 모델이 Nvidia에서 실행될 때 성능이 Metal 최적화된 모델이 애플 기기에서 실행될 때에 비해 배 이상으로 빠르다.
모델
결국 제일 중요한 것은 어떤 수준의 성능을 가진 모델까지 내 기기에 구겨넣을 수 있을지가 될 것이다. 최근 있었던 잇따른 프런티어 로컬 모델들의 공개로 비교해볼 옵션이 크게 늘어났다. 소비자 수준 기기의 성능 한계치에 맞추게 되다 보니 자주 선택되는 선택지들은 VRAM 50~100GB 급에서는 google의 gemma4-31B, gemma4-26B-A4B, qwen의 qwen3.6-27B, qwen3.6-35B-A3B 정도로 좁혀진다.
gemma 계열의 장점은 다국어 지원이 잘 된다는 것으로, thinking을 켰을 때 한국어로 질문하면 생각도 한국어로 하는 것을 볼 수 있다. 단점은 가장 큰 모델끼리 비교했을 때 qwen과 비교하여 추론 성능이 조금 부족하고 툴 호출이 잘 되지 않는 경우가 있다. qwen3.6은 직접 사용해보면 추론 성능이 상당함을 느낄 수 있을 정도로 모델의 퀄리티가 좋다. 툴 호출도 매우 잘해 다국어 지원을 제외하면 동 성능대에서는 정말 높은 만족감을 준다. 31B 모델의 경우 적당한 양자화 수준에서도 매우 높은 확률로 세차장 문제2를 잘 추론해내었다.
백엔드
모델 자체는 거대한 숫자들의 뭉치에 가깝고 이를 우리가 사용할 수 있는 API로 변경하기 위해서는 모델을 로드하여 서빙하는 백엔드가 있어야 한다. 가장 유명한 로컬 모델 백엔드는 ollama라는 프런트엔드로 유명한 llama.cpp일 것이다. 대부분의 모델 양자화 등이 llama.cpp를 기준 백엔드로 삼고 있다. 반면 애플 진영은 몇 가지 선택지가 더 있는데, Metal의 API를 래핑한 라이브러리 MLX를 사용하는지에 따라 모델의 토큰 생성 속도가 크게 달라지기 때문에 MLX를 사용하는 백엔드들이 몇 개 더 있다. 가장 기반이 되는 mlx-lm, 비전 모델 지원을 추가한 mlx-vlm, SSD를 캐시로 사용하는 것이 특징인 omlx 등이 있다.
백엔드 프로세스를 통해 모델을 로드하고 나면 드디어 모델과 첫 대화를 나눌 수 있다. OpenAI 또는 Anthrophic의 API 스펙대로 질문하면 SSE의 형태로 stream 된 응답을 받을 수 있다. 이제 이 endpoint에 하네스를 붙이면 드디어 제품처럼 쓸 수 있는 AI가 나온다. claude code, codex, pi와 같은 코딩 하네스를 붙일 수도 있고 open-webui와 같은 UI를 붙여 ChatGPT처럼 쓸 수도 있다. 그래도 이렇게 구성된 API의 가장 대표적인 사용처는 OpenClaw, Hermes와 같은 명령어 실행이 가능한 agent들일 것이다. 나는 모델은 macOS 위에서 동작하는 프로세스로 두고 모든 agent들의 실행 환경을 docker로 샌드박싱하여 구성했다.
성능
실사용에서 성능은 모델의 크기의 영향을 일차적으로 받고 이외에도 구조나 학습된 방식에도 영향을 받는다. 아주 거칠게 요약하면 토큰과 상호작용하는 파라미터의 수가 계산에 걸리는 시간을 결정하는데, 이 상호작용하는 파라미터의 수가 모델의 크기와 설계에 영향을 받는다. 모델 뒤에 붙는 -NB, -NT와 같은 숫자들의 파라미터의 수로, 27B 모델은 파라미터가 270억개 있는 것이다.
내가 주로 사용하는 qwen3.6-27B 와 같은 모델은 dense 모델들로, 모든 토큰이 모든 파라미터와 상호작용한다. dense 모델의 애플 실리콘에서의 토큰 생성 속도는 꽤나 절망적인 편으로, M3 Ultra 기준 prefill 200tok/s, 생성 최대 30tok/s 평균 20tok/s 정도가 나온다.
qwen3.6-35B-A3B와 같은 모델들은 35B 파라미터 중 3B만 실제로 활성화된다는 뜻으로, 각종 “전문가” 라우팅을 통해 활성 토큰의 수를 줄이는 기법으로 MoE(Mixture of Experts) 모델로 불린다. 상호작용하는 파라미터의 수가 작으므로 생성에 필요한 컴퓨팅이 적어 훨씬 나은 tok/s를 얻을 수 있다. 하지만 내가 직접 경험했을 때는 dense 모델과 MoE 모델은 파라미터 수가 비슷해도 dense 쪽의 결과물이 MoE의 것과 너무 차이나서 MoE 모델을 선택할 수 없었다.
20tok/s의 생성 속도는 지금까지 경험했던 프런티어 모델들 중 가장 느린 버전을 상상하면 대충 맞다(나는 GPT-4 극초기를 떠올렸다). 여기서 문제를 더 키우는 것은 하네스로, 지금까지 측정했던 모든 숫자들은 한 번에 하나의 요청만 처리한다는 전제 하에 얻은 숫자인데 동시에 여러 요청을 보내기 시작한다. 클라우드와 다르게 병렬화가 안되는 로컬에서는 2개의 동시 요청도 굉장히 버거워진다. 대화가 길어지고 맥락이 커지기 시작하면 한 작업을 시켜놓고 몇 분씩 걸리기 때문에 기다리는 동안 다른 일을 하고 오는 경우도 부지기수다.
경제성
맥 스튜디오의 경우 GPU 100% 풀가동중일 때 소비 전력이 150W 정도로 안정적으로 유지된다. 전기료를 생각하면 로컬 모델의 토큰비는 거의 공짜에 가깝다. 실제로 내가 사용하는 등급의 모델이 얼만큼의 가치에 거래되는지를 알려면 OpenRouter나 Fireworks 등에서 같은 모델의 API 가격 및 비슷한 패턴으로 사용했을 때 과금되는 양을 보면 되며, 이러한 방식으로 테스트했을 때 생각보다 토큰(및 크레딧)이 상당히 빨리 녹는다는 사실을 알 수 있다. 외부 호스팅된 오픈 웨이트 모델을 사용하여 하네스를 테스트해보면 클로드 코드 풀타임 사용 시나리오 같은 상황에서 클로드 구독 비용을 살짝 넘어가는 정도로 과금이 되는데, 모델 성능과 토큰 생성 속도의 차이를 생각하면 클로드와 GPT의 100 플랜은 매우 가성비가 뛰어난 것이다.
그래서 무엇을 했나?
여러 번의 테스트를 통해 결국 모든 일을 로컬 모델로 수행하는 것은 불가능하며 결국 원래의 질문인 전체 워크플로우에서 위임할 수 있는 부분을 잘 정하는 것이 중요하다는 결론에 도달했다. 가능한 한 보안과 개인정보에 관련 없는 작업들을 다른 모델로 위임하고 정말 중요한 일만 기기 내에서 실행하도록 구성해야 최선의 결과를 얻을 수 있었다. 그래서 원래 하나였던 Hermes agent 배포를 세 개로 늘리고 각 agent에 역할과 제한된 접근 권한을 부여하고, 칸반 보드 및 웹훅을 통한 상호 소통을 구현하여 책임과 권한 분리가 이루어졌다. 로컬 모델이 수행하는 작업에서 많은 맥락을 요구하거나 긴 대화를 요구하는 작업들은 철저히 배제하고 정말 중요한 일만 위임되도록 구성하고 나서야 모델의 끔찍하게 느린 속도를 커버할 수 있는 생산성이 나오기 시작했다.
이렇게 구성하고 나서 수행한 작업이라고는, 아직까지는 아주 많은 토이 프로젝트들을 빠른 시간 안에 만들고 버렸음이 전부이다. 본격적인 결과가 나오기 시작하기 전부터 이런 복잡한 세팅이 필요한지, 결국 더 좋은 하네스를 찾기만 하는 무의미한 여정이 되지 않을지에 대한 고민 또한 있었는데, 현재는 audacity-to-push-never-read-codes 글을 쓰면서도 들었고 현재 더 확고해진 코드 대신 테스트, 운영, 모니터링, 이슈 대응을 효율화해야 생산성 향상을 이룰 수 있다는 관점에서 앞으로도 더 좋은 오케스트레이션 구조, 책임과 권한 구조와 이를 잘 제한할 방법에 대한 고민을 끝없이 해야겠다고 생각하게 되었다.
총평
로컬 모델은 이전부터 장단점이 명확했으나 예전과 현재 희생해야 하는 것의 내용은 달라졌다고 생각한다. 예전에는 품질 측면에서 상대가 안되었다면, 현재의 오픈 웨이트 모델들은 (언어적 측면만 제외하면) 퀄리티에 불편함이 전혀 없는 수준이다. 진짜 문제는 높은 하드웨어적 장벽 및 느린 토큰 생산 속도였다. 이 느린 토큰 생성 속도를 생산성에 방해가 되지 않는 수준까지 끌어올리는데 들어간 노력은 자가 개선 정도로는 한참 부족했으며 사람의 개입을 크게 요구했다. 클라우드 모델들의 보안 및 개인정보 문제에 대한 걱정이 없었다면 순식간에 해결했을 일들이 이 속도의 병목 때문에 밀리는 것을 보면 모델의 걸출한 성능에 비해 활용처가 매우 좁아진다는 사실이 안타까웠다.
결과적으로는 비싸고 오래 걸리면서 결과가 마땅치는 않은 실험이었지만, 실제로 로컬 모델의 대화 수준에 대해 어림을 가지게 되면서 큰 배움을 얻었다고 생각한다. 로컬 모델과 클라우드 모델의 장단점에 대해 생각하기 시작한 부분부터 지금의 복잡한 하네스를 구성하기까지 수많은 사용자의 개입이 있었으며, 모델이 생각하고 스스로를 개선하기도 하지만 이 프로젝트 전체적으로 봤을 때 결국 사용자인 나의 학습과 경험이 남았다는 점이 이전까지 AI 피로에 묻혀 잊고 있었던 엔지니어링의 즐거움을 다소 되찾아준 듯하다.