0. 들어가며

로컬 LLM으로 충분하겠지?

요즘 또 Hermes Agent가 핫하다길래 노트북(ZenBook, 16GB RAM)에서 Hermes Agent를 구동하려고 했습니다. 공짜로요. Ollama를 띄우고 로컬 LLM을 붙이면 될 거라 생각했죠.

그 생각이 얼마나 순진했는지 깨닫게 된 건 5번의 연속된 실패 덕분이었습니다.

1. 첫 번째 시도: Gemma 4 26B — 메모리의 벽

가장 먼저 웅장한 성능을 약속하는 가장 최신의 젬마, Gemma 4 26B 모델을 돌려봤습니다.

❌ Error: HTTP 500: model requires more system memory
           (18.3 GiB) than is available (14.1 GiB)

당연한 거였어요. VRAM도 없고 16GB RAM을 가진 ZenBook에서 가용 메모리는 14.1GiB였는데, 26B 모델은 당당히 18.3GiB의 시스템 메모리를 요구했습니다. Ollama가 모델을 올리다가 메모리 부족(OOM)으로 포기해버렸습니다.

이 에러 메시지를 먹고 자라야 나중에 버틸 수 있어..

교훈: 모델 크기 욕심은 RAM 용량 앞에서는 부질없습니다. 물리적인 한계는 극복할 수 없죠.

2. 두 번째 시도: Gemma 4 e4b — 무한 로딩의 굴레

“그렇다면 메모리에 맞는 걸 쓰자!” 싶어 젠북의 한계선에 딱 맞는 Gemma 4 e4b 모델을 받았습니다. 모델을 올리고 설정 마법사를 통해 에이전트를 연결했습니다.

그런데 말을 걸어도 아무런 응답이 없었습니다.

“분명 모델 사이즈는 맞췄는데, 왜 로딩만 계속되고 모델 옆에 연결 실패를 알리는 빨간불이 뜨지?”

원인은 **에이전트의 타임아웃(Timeout)**이었습니다. 젠북의 내장 그래픽 속도로는 모델을 RAM에 온전히 올리고 스탠바이 상태를 만드는 데 시간이 너무 오래 걸렸고, 성격 급한 Hermes Agent는 “서버가 응답하지 않는다”며 연결을 끊어버린 겁니다. (아마 직전 OOM의 여파로 메모리가 제대로 정리되지 않은 탓도 컸겠죠.)

교훈: 모델이 메모리에 들어간다고 끝이 아닙니다. 구동(Load) 속도도 에이전트의 타임아웃 조건에 맞아야 합니다.

3. 세 번째 시도: Gemma 2 9B — “Tool 지원 안 함” 에러

체급을 낮춰 16GB RAM에서도 여유 있게 돌아가는 Gemma 2 9B 모델로 내렸습니다. 메모리도 잘 들어오고 속도도 문제없었습니다.

그런데…

ERROR [20260414_205733_fdabf3] root: Non-retryable client error:
Error code: 400 - {'error': {'message':
'registry.ollama.ai/library/gemma2:9b does not support tools',
'type': 'invalid_request_error'}}

“does not support tools”

여기서 깨달았어요. Hermes Agent는 단순한 문장 이어쓰기 챗봇이 아니었습니다. 도구(Tools)를 사용할 줄 알아야 하는 에이전트였죠.

Gemma 2 9B 베이스 모델은 에이전트 프레임워크가 던지는 도구 파라미터 구조를 인식하지 못합니다.

도구를 모르는 모델은 에이전트라 할 수 없어요

교훈: Function Calling과 Tool Use 기능이 없는 모델은 에이전트의 “손가락”이 없는 거나 마찬가지입니다.

4. 네 번째 시도: Llama 3.1 8B — 느림의 극치

이번엔 도구 사용(Tool Use)을 공식적으로 완벽 지원하는 표준모델로 알려진 Llama 3.1 8B를 써봤습니다. Hermes에 연결했고 초기 설정도 무사히 마쳤습니다. “안녕?”이라고 물었죠.

…하지만 5분이 지나도 대답이 없었습니다. 그리고 에이전트 로그를 확인해보니:

INFO agent.model_metadata: Cached context length llama3.1:8b@http://localhost:11434/v1
-> 131,072 tokens

문제가 보였습니다. 131K (131,072) 토큰.

에이전트는 넉넉한 작업을 위해 모델의 최대 컨텍스트 윈도우를 한꺼번에 잡아먹으려 시도합니다. 내장 그래픽 환경의 ZenBook에서 128K에 달하는 거대한 컨텍스트를 유지하면서 동시에 아래 작업을 처리해야 했던 겁니다.

• 28개의 도구 정의 로드
• 76개의 스킬 설명 읽기
• 대화 제목 자동 생성

8B 모델조차 이 어마어마한 맥락(Context)을 씹어 삼키느라 지연(Latency)이 5분을 훌쩍 넘겨버렸습니다.

널 5분 기다릴거였으면 그냥 내가 일을 하겠지..

교훈: 에이전트는 매우 방대한 프롬프트와 컨텍스트 공간을 필요로 합니다. 사양이 낮으면 영원한 로딩(Timeout)에 빠질 수밖에 없습니다.

5. 다섯 번째 시도: Llama 3.2 3B — 여전히 9분의 지옥

“모델 파라미터가 더 작으면 계산량이 줄어드니까 빠르지 않을까?”

그래서 용량이 단 2GB에 불과한 Llama 3.2 3B 모델을 선택했습니다. 하지만 응답이 오는 데 걸린 시간은 9분.

로그를 확인해보니 본질적인 원인은 여전히 같았습니다:

INFO agent.model_metadata: Cached context length llama3.2:3b@http://localhost:11434/v1
-> 131,072 tokens

가벼운 3B 모델이라도, 에이전트가 우겨넣는 131K라는 끔찍한 컨텍스트 공간을 처리하는 과정은 똑같았습니다.

• 처음 6분: 131K 메모리 공간 할당 및 스왑(Swap) 사투
• 다음 2분: 28개 도구 + 76개 스킬 프롬프트 해석
• 마지막 1분: 아주 짧은 실제 답변 텍스트 생성

교훈: 로컬 모델 크기의 문제가 아니었습니다. Hermes Agent가 기본적으로 깔고 들어가는 막대한 시스템 자원 요구사항 자체가 개인용 랩탑의 한계를 완전히 벗어난 것이었죠.

6. 최종 깨달음: Hermes Agent에 필요한 진짜 “눈높이”

5번의 뼈아픈 실패를 통해 확실히 정리된 기준입니다.

Hermes Agent는 단순 LLM이 아니라 도구 기반 에이전트

• 20개의 도구를 모델에게 주입시켜야 함
• 76개의 스킬을 동시에 맥락으로 관리(도구와 스킬은 아마 openclaw 마이그레이션으로 인해 생긴 것 같습니다만)
• 131,072 토큰 (128K) 컨텍스트 윈도우 할당을 기본 시도
• 백그라운드 모델 프로세스와 동시 통신

로컬 LLM 환경 테스트 성적표

결국 ① 64K 이상의 메모리 공간을 1초 만에 렌더링할 수 있는 엄청난 통신망이나 고사양 GPU, 그리고 ② 완벽한 Function Calling 능력 이 두 가지가 필수였습니다. 저사양의 Linux 기반 랩탑으로 어떻게든 비벼보려 했던 시도 자체가 잘못된 것이었습니다.

7. 결론: 클라우드 LLM 인프라가 정답이다

Hermes Agent는 저사양 리눅스 환경에서 로컬 LLM으로는 사실상 운영이 불가능합니다. 타임아웃, OOM, 도구 파라미터 오류만 잔뜩 겪게 됩니다.

나는 이제 알아요. 프레임워크의 진정한 힘을 쓰려면 고성능 LLM API가 필수라는 걸.

해결책: 기존의 모든 시도를 폐기하고, 깔끔하게 외부 구동망과 타협했습니다.

# 로컬 Ollama를 버리고 OpenRouter API 선택
hermes setup
→ Provider: 2. OpenRouter (또는 유료 API)
→ Model: Gemma 4 26B, Claude, GPT-4 등

허영심을 버리고 가벼운 노트북은 지시만 내린 채, 무거운 추론 작업은 클라우드 API에 맡겼을 때 비로소 Hermes Agent가 미친 듯한 속도와 도구 조작 능력을 보여주었습니다.

8. 마치며

이번 우분투 삽질기에서 얻은 가장 큰 교훈은 이렇습니다.

돈을 아껴보겠다고 최신 기술을 무조건 로컬로 내 방구석 노트북에서 굴리려 해선 안 된다.

저처럼 로컬 환경에서 에이전트를 자립시켜보겠다고 OOM과 무한 타임아웃 굴레에 빠진 분이 계신다면, 지금이라도 당장 Ctrl+C를 누르세요. 그리고 편안하게 클라우드 LLM을 연동하세요. 당신의 시간, 인내심, 그리고 무거운 쿨링 작업을 덜어줄 소중한 랩탑의 생명을 구하는 길입니다.

Happy agenting! 🤖