헤르메스 사용하는데 로컬 LLM에게 RSS 수집을 시켰더니 "못 한다"고 했습니다 — 그런데 거짓말이었습니다
헤르메스에게 RSS 수집을 시켰더니 거절했습니다
오픈소스 AI 에이전트 헤르메스(Hermes Agent)에 작은 로컬 모델(Gemma 4B)을 붙여서 실험을 하나 해봤습니다. 매일 아침 RSS 피드 5개를 수집해서 필터링하고 보고서를 만들라는 지시였습니다.
헤르메스는 Nous Research가 만든 자기 개선형 에이전트로, 40개 넘는 빌트인 도구를 가지고 있습니다. 웹 브라우저 자동화, 파일 처리, API 호출 같은 도구들이에요. 단순한 RSS 수집 정도는 충분히 할 수 있어 보였습니다.
돌아온 답은 의외였어요.
"수집된 데이터 없음 — 정보 수집을 위한 외부 RSS 피드 접근 도구가 제공되지 않아 데이터를 수집할 수 없습니다. 저는 외부 웹사이트에 직접 접근하여 RSS 피드를 구독하거나 동적으로 데이터를 스크래핑하는 기능이 제한적입니다."
이 답변을 보고 떠오른 의문이 있었습니다. ChatGPT나 Claude는 웹 검색을 잘하잖아? 모델이 달라서 그런가?
확인하려고 헤르메스에게 다시 물어봤습니다. "지금 너에게 어떤 도구가 있는지 알려줘."
"browser_navigate, browser_click, browser_scroll, browser_snapshot, browser_vision — 이 도구들은 실시간 검색 엔진보다는, 특정 URL에 접속하여 그 내용을 탐색하는 기능에 더 가깝습니다."
여기서 명백한 모순이 보였습니다. 모델이 직접 "특정 URL 접속은 가능하다"고 말했습니다. 그리고 RSS는 정적인 XML URL입니다. URL이 이미 다 주어져 있어서 검색이 필요하지도 않아요. 그런데 결론은 "불가능"이었습니다.
자기 발에 자기가 걸려 넘어진 답변이었어요.
LLM과 에이전트의 차이부터 다시 정리해야 했습니다
이 사건을 이해하려면 먼저 짚어야 할 게 있어요. "AI 에이전트"라고 부르는 것의 본체가 실제로 무엇인지입니다.
LLM은 텍스트를 받아 텍스트를 뱉는 함수입니다. 본인은 웹 접근도, 파일 읽기도, API 호출도 못 합니다. "지능"이 있다는 인상은 학습 데이터의 풍부함에서 오는 것이지, 행위 능력에서 오는 게 아니에요.
진짜 에이전트는 세 가지의 결합입니다.
LLM (의사결정 두뇌)
도구 (실제로 외부와 상호작용하는 함수들 — fetch, search, exec 등)
루프 ("LLM 호출 → 도구 호출 요청 파싱 → 도구 실행 → 결과를 LLM에 다시 던지기" 반복)
이 셋 중 하나라도 빠지면 에이전트가 아니라 챗봇입니다.
ChatGPT의 웹 검색, Claude의 web_search, Gemini grounding 모두 이 구조입니다. 모델이 진화한 게 아니라 도구를 묶어서 파는 것이에요. API 호출 한 번처럼 보이지만 내부는 멀티 호출 루프입니다.
헤르메스도 마찬가지입니다. 큰 모델을 연결하면 잘 동작하는 도구 세트가, 작은 로컬 모델을 연결하니 같은 도구를 쓰지 못하고 거절했습니다. 도구는 같은데 두뇌가 달랐을 때 결과가 완전히 달라진 셈입니다.
그러면 다음 질문이 따라옵니다. 작은 모델은 왜 같은 도구를 쓰지 못했을까요?
작은 모델은 능력이 부족한 게 아니라 자기를 잘못 판단합니다
처음에는 단순하게 "작은 모델이라 추론이 약해서"라고 생각했어요. 그런데 위 답변을 다시 보면, 추론은 멀쩡합니다. 도구 이름을 정확히 나열하고, 각 도구의 기능 범위도 정확히 설명했어요.
문제는 다른 곳에 있었습니다. "추론 능력"이라는 말은 사실 여러 가지로 쪼개진 능력들의 합 이었습니다.
구성요소 | 정의 | 작은 모델 상태 |
|---|---|---|
기본 논리 추론 | A→B, B→C 따라서 A→C 같은 명제 추론 | 무난함 |
작업 분해 | 복합 작업을 실행 가능한 단위로 쪼개기 | 약함 |
다단계 일관성 | 5번째 스텝에서도 1번째 맥락 유지 | 3~4스텝부터 무너짐 |
메타인지 | "내가 이걸 할 수 있는가" 자기 평가 | 거의 항상 과소평가 방향으로 틀어짐 |
기본 논리는 잘 합니다. 그런데 자기가 할 수 있는 일을 자기가 정확히 평가하지 못합니다. 이게 메타인지 실패입니다.
작은 모델이 어려운 작업 앞에서 보이는 회피 패턴을 정리하면 네 단계입니다.
카테고리 오분류: "RSS"를 "실시간/동적/어려운 것"으로 잘못 라벨링
회피 합리화: 그럴듯한 거절 문장 생성 ("도구 범위를 넘어선다", "기능적 한계")
계획 깊이 부족: 4스텝 이상 체이닝이 필요한 작업에서 1스텝도 시작하지 않음
자기 모순 무자각: "URL 접속은 가능"이라고 말하면서 동시에 "URL 기반 RSS는 불가능"이라고 함. 두 진술이 충돌해도 인지 못 함
특히 강한 RLHF가 들어간 작은 모델일수록 "겸손한 거절"이 디폴트로 박혀 있어서 어지간한 작업도 빠져나가려고 합니다. 못 하는 게 아니라 "안 하기로 잘못 판단" 한 거예요.

그렇다면 기업에서 작은 모델은 쓸모없을까요
여기서 결론을 "작은 모델은 못 쓴다"로 가면 안 됩니다. 위치가 다를 뿐이에요.
작은 모델은 기획자/실행자로는 부족하지만 판단자로는 충분합니다.
작은 모델이 잘하는 위치
"이 글이 AI 관련인가? Y/N" 같은 단일 분류
짧은 요약
형식 변환 (JSON → CSV 등)
키워드 추출
작은 모델이 못 하는 위치
멀티스텝 자율 실행
도구 체이닝
장기 계획
복합 의사결정
이걸 운영에 적용하면 하이브리드 아키텍처가 자연스럽게 나옵니다.
[큰 brain 1개] = Claude API / Gemini Pro / 큰 로컬 모델
│
├── 도구 호출 (web, file, db 등)
│
└── [작은 worker N개] = 로컬 소형 모델
├── 분류 작업
├── Y/N 판단
└── 단순 요약큰 brain은 기획, 작업 분해, 도구 호출을 담당합니다. 결정론적이고 반복적인 서브태스크는 작은 worker로 위임합니다.
이 구조의 이점이 명확합니다.
API 비용 절감: 분류·라벨링은 단가가 싼 작은 모델로
프라이버시: 민감 데이터는 로컬 작은 모델로 처리
속도: 단순 작업에 큰 모델 API 왕복 안 함
안정성: 큰 brain은 메타인지가 멀쩡해서 작업 분해를 잘 함
비슷한 발상은 이미 다른 곳에서도 적용하고 있어요. RAG 시스템에서 의도 분석·매니저 라우팅 같은 내부 판단은 가벼운 모델로, 사용자 대면 답변 생성은 무거운 모델로 분리한 구조였습니다.
같은 발상을 에이전트 구조에 확장하면 하이브리드 아키텍처가 됩니다.

도구 설계가 모델보다 더 ROI가 높을 때가 많습니다
이번 헤르메스 실험에서 배운 한 가지가 더 있어요.
LLM 자체에 너무 큰 기대를 걸지 않는 게 좋습니다. 진짜 차별화는 도구 설계에서 나옵니다.
"AI로 X를 자동화하고 싶다"는 요청이 들어오면, 그게 진짜 묻는 건 "X를 자동화하는 데 필요한 도구 세트가 무엇이고 어떻게 묶을 것인가" 입니다. 같은 모델이라도 도구가 다르면 가능한 일이 완전히 달라져요.
기업 입장에서 우선순위는 이렇습니다.
도구를 잘 설계하는 것 (가장 ROI 높음)
하이브리드 아키텍처로 모델 역할 분담 (비용·안정성)
모델 갈아 끼우기 (대부분 가장 ROI 낮음)
업계 자료를 봐도 같은 흐름이 보입니다. Anthropic이나 OpenAI가 새 모델을 발표할 때 강조하는 건 모델 자체의 성능보다 점점 더 도구 사용(tool use), 컴퓨터 사용(computer use), 에이전트 워크플로우 같은 도구 결합 능력이 됐어요. 모델 단독의 가치는 점점 줄어들고, 도구와의 결합이 본체로 옮겨가고 있습니다.
마무리
로컬 LLM에 RSS 수집을 시켰더니 "할 수 없다"고 거절한 사건에서 출발해 세 가지 통찰을 얻었습니다.
첫째, LLM은 LLM일 뿐이고, 에이전트는 그 주변에 묶인 도구와 루프와의 결합입니다. ChatGPT나 Claude의 웹 검색이 잘 동작하는 건 모델이 다른 게 아니라 벤더가 도구를 같이 묶어 팔기 때문 입니다.
둘째, 작은 모델의 한계는 지식이나 능력 부족이 아니라 메타인지 실패 입니다. 자기가 할 수 있는 일을 자기가 정확히 평가하지 못해서, 가능한 작업도 그럴듯한 핑계로 거절합니다.
셋째, 그래서 기업에서는 하이브리드 아키텍처 가 자연스러운 답입니다. 큰 brain이 기획·작업 분해·도구 호출을 담당하고, 결정론적 서브태스크는 작은 worker로 위임하는 구조입니다. API 비용도 줄고, 프라이버시도 챙기고, 안정성도 좋아집니다.
기업에서 AI 도입을 검토하고 있다면 모델 선택보다 도구 설계와 모델 역할 분담에 먼저 시간을 쓰시길 추천합니다. 그게 ROI가 가장 높은 영역이었어요.