
오픈 웨이트 모델 vs API 모델: Hermes로 도메인 특화 모델 소유하기
프롬프트에서 시작해 하네스까지 왔다면, 마지막 단계는 모델 자체를 소유하는 거예요. Nous Research의 Hermes 오픈 모델·함수 호출 표준·데이터 플라이휠을 코드와 함께 정리했어요.
모델을 빌리는 대신 소유하는 단계예요. 오픈 웨이트 모델을 쓰는 이유, API 모델과의 선택 기준, Nous Research Hermes(4.3)의 특징과 함수 호출 표준, 도메인 특화 모델용 데이터를 모으는 플라이휠을 정리했어요.
진화의 마지막 단계는 모델을 빌리는 대신 직접 소유하는 거예요. 여기까지 우리는 모델을 빌려 썼어요. 채팅창에 프롬프트를 넣고(1편), 코드를 맡기고(2편), 루프를 넘기고(3편), 그 주변에 하네스를 설계했죠(4편).
> 'LLM 활용의 진화' 시리즈 ⑤편(마지막). ① 프롬프팅 · ② 바이브 코딩 · ③ 에이전트 · ④ 하네스 엔지니어링 · ⑤ 오픈 모델.

왜 모델을 소유하나요
프런티어 모델을 API로 빌리는 건 편하지만 대가가 있어요. 가격·정책이 바뀌면 끌려가고, 데이터를 밖으로 보내야 하고, 우리 도메인에 맞게 모델을 바꿀 수 없어요. 오픈 웨이트 모델은 이 셋을 뒤집어요. 표로 정리하면 이래요.
| 구분 | 비용 통제 | 데이터 프라이버시 | 도메인 커스터마이징 |
|---|---|---|---|
| 프런티어 API | 가격·정책 변경에 끌려감 | 데이터를 외부로 전송 | 프롬프트·RAG 수준으로 제한 |
| 오픈 웨이트 모델(예: Hermes) | 인프라 비용만 통제 | 자체 인프라 안에서 처리 | 직접 파인튜닝 가능 |
대표적인 게 Nous Research의 Hermes 계열이에요. 가장 최근 버전인 Hermes 4.3(2025년 8월, ByteDance의 Seed 36B 기반)까지, Hermes는 시스템 프롬프트 준수·스티어링·함수 호출에 강한 오픈 모델로 자리 잡았어요 [1][3]. 흥미로운 건 Nous가 모델만 내놓는 게 아니라, 오픈 에이전트 프레임워크(Hermes Agent)와 네이티브 데스크톱 앱(Hermes Desktop, 2026년 공개, MIT)까지 함께 연다는 거예요. 모델 + 에이전트 + 하네스를 통째로 소유할 수 있는 거죠.
함수 호출도 표준이 있어요
1편에서 본 구조화 출력(tool_use)을 기억하시나요? 오픈 모델에도 같은 게 있어요. Hermes Function Calling 표준 [2]은 도구 정의(JSON 스키마)를 <tools>에, 호출을 <tool_call>에, 결과를 <tool_response>에 담아요.
<!-- Hermes 함수 호출 — 도구 정의는 JSON 스키마로 <tools> 안에 -->
<tools>
[{"name": "emit_slides",
"parameters": {"type": "object",
"properties": {"slides": {"type": "array"}},
"required": ["slides"]}}]
</tools>
<!-- 모델은 이 형식으로 호출해요 -->
<tool_call>
{"name": "emit_slides", "arguments": {"slides": [/* … */]}}
</tool_call>
형식만 다를 뿐, 1편의 tool_use와 정확히 같은 발상이에요. 출력을 인터페이스로 강제하기. 그래서 프런티어 모델용으로 설계한 하네스를, 오픈 모델로 거의 그대로 옮길 수 있어요.
하네스가 곧 데이터 공장이에요
여기서 4편의 부수 효과가 살아나요. 잘 설계된 하네스는 모든 실행마다 규격화된 데이터를 남겨요. 입력 → 도구 호출 → 검증된 출력. 이건 그대로 instruction-tuning 데이터셋이에요.
그러면 플라이휠이 돌아요. 하네스를 많이 쓸수록 도메인 데이터가 쌓이고 → 그 데이터로 오픈 모델(예: Hermes)을 우리 도메인에 파인튜닝하고 → 기존 워크플로우가 그대로 평가 기준(eval)이 되고 → 더 잘 맞는 모델이 다시 하네스를 돌려요. 우리 생성 파이프라인이 tool_use로 남기는 구조화 출력과, 검증에 쓰는 held-out judge가 바로 이 플라이휠의 원료예요.
솔직히 이 단계는 아직 가설에 가까워요. 충분한 데이터, 품질 관리, 지속적 투자가 전제죠. 하지만 방향은 분명해요. 모델을 빌리는 데서, 모델·하네스·데이터를 통째로 소유하는 쪽으로요.
시리즈를 마치며
다섯 단계를 지나왔어요. 채팅창에 프롬프트를 치고, 바이브로 만들고, 루프를 에이전트에 넘기고, 주변에 하네스를 설계하고, 끝내 모델 레이어까지 소유하는 데까지. 관통하는 한 줄은 이거예요. LLM 활용은 개인의 센스가 아니라, 팀이 설계하고 소유하는 시스템으로 넘어가고 있어요.
우리가 콘텐츠 자동화를 만드는 방식도 정확히 이 궤적 위에 있어요. 프롬프트를 인터페이스로 다루고, 생성에 검증을 붙이고, 하네스로 품질의 저점을 높이고, 그 데이터로 더 나아지는 것. Trail Studio는 그 시스템을 콘텐츠에 적용한 결과예요.
자주 묻는 질문
오픈 웨이트 모델이 프런티어 모델보다 항상 나은가요?
아니요. 최신 프런티어 모델의 최고 성능을 오픈 웨이트가 항상 따라잡는 건 아니에요. 대신 비용·데이터 프라이버시·도메인 커스터마이징을 직접 통제해야 하는 상황에서 유리해요. 두 선택지는 대체재라기보다 용도가 다른 도구예요.
Hermes 같은 오픈 모델을 도입하려면 데이터가 얼마나 필요한가요?
정해진 최소량은 없지만, 하네스가 남긴 '입력 → 도구 호출 → 검증된 출력' 기록이 쌓일수록 파인튜닝 품질이 올라가요. 그래서 오픈 모델 도입은 하네스를 먼저 갖춘 다음에 자연스럽게 따라오는 단계예요.
함수 호출 표준이 다르면 하네스를 다시 짜야 하나요?
형식(JSON tool_use vs XML 태그)은 다르지만 발상은 같아요. 출력을 인터페이스로 강제하는 것. 그래서 프런티어 모델용으로 설계한 검증·훅 로직을 오픈 모델로 옮길 때도 어댑터 정도만 바꾸면 대부분 재사용할 수 있어요.
참고자료
요약
- 오픈 웨이트 모델은 비용·데이터 프라이버시·도메인 커스터마이징을 직접 통제할 수 있게 해줘요.
- Nous Research의 Hermes 계열은 시스템 프롬프트 준수·함수 호출에 강한 오픈 모델로, 모델·에이전트·하네스를 통째로 열어 두고 있어요.
- Hermes Function Calling 표준은 <tools>/<tool_call>/<tool_response> 태그로 tool_use와 같은 발상(출력을 인터페이스로 강제하기)을 구현해요.
- 잘 설계된 하네스는 실행마다 규격화된 데이터를 남겨, 그 데이터로 오픈 모델을 도메인에 맞게 길들이는 플라이휠이 돌아가요.
다른 글

RAG 할루시네이션 방어 전략: 유형을 나누고 검증 자동화의 한계 알기
RAG는 외부 문서를 검색해 답변 근거로 쓰는 기법이지만 검색·생성 단계 모두에서 할루시네이션이 생겨요. 소스 미참조와 소스 왜곡 유형의 차이, 막는 법, AI 답변 검증을 자동화할 때의 한계를 정리했어요.

GEO 데이터 AI 에이전트 설계 원칙: 구조화 도구 호출, 되돌릴 수 없는 작업 막기
GEO 데이터를 다루는 AI 에이전트를 설계할 때 지키는 원칙이에요. 텍스트 파싱과 구조화 도구 호출의 차이, 되돌릴 수 없는 작업을 막는 법, 평가 없이 배포하면 위험한 이유를 정리했어요.

하네스 엔지니어링이란? 같은 LLM인데 결과가 다른 이유
에이전트를 안전하고 일정하게 굴리는 건 모델 주변의 하네스예요. 프롬프트 엔지니어링과의 차이, 스코프된 도구·훅·컨텍스트 계층화·검증 루프, MCP self-call, AI 에이전트 팀 운영의 저점을 높이는 법이에요.
같은 주제로 이어 읽기
- AI 에이전트란? 모델이 스스로 루프를 돌 때 권한과 승인 게이트OpenClaw(전 Moltbot)가 띄운 자율 AI 에이전트를 정리했어요. 프롬프트와 에이전트의 차이, 에이전트에 넓은 권한을 주면 생기는 위험, 사람 승인 게이트를 두는 이유예요.
- 바이브 코딩(vibe coding)이란? 한계와 AI 코드 검증 루프바이브 코딩은 의도만 말하면 AI가 코드를 만드는 방식이에요. 무엇을 풀었고 어디서 깨지는지(한계), 에이전트 코딩과의 차이, AI가 만든 코드에 검증 루프를 붙이는 법을 정리했어요.
- 퍼스트파티 데이터가 뭐예요? 서드파티 쿠키 이후 마케팅 활용법서드파티 쿠키가 사라지는 시대에 고객 의도를 직접 보여주는 퍼스트파티 데이터의 뜻, 서드파티 데이터와의 차이, 마케터가 마케팅에 활용하는 전략을 쉽게 정리했어요.
이 글은 TRAIL Labs 카테고리에 속해요. 같은 카테고리 글 16편을 한자리에서 볼 수 있어요. TRAIL Labs 카테고리 글 전체 보기