오픈 웨이트 모델 vs API 모델: Hermes로 도메인 특화 모델 소유하기

오픈 웨이트 모델 vs API 모델: Hermes로 도메인 특화 모델 소유하기

프롬프트에서 시작해 하네스까지 왔다면, 마지막 단계는 모델 자체를 소유하는 거예요. Nous Research의 Hermes 오픈 모델·함수 호출 표준·데이터 플라이휠을 코드와 함께 정리했어요.

모델을 빌리는 대신 소유하는 단계예요. 오픈 웨이트 모델을 쓰는 이유, API 모델과의 선택 기준, Nous Research Hermes(4.3)의 특징과 함수 호출 표준, 도메인 특화 모델용 데이터를 모으는 플라이휠을 정리했어요.

글 · TRAIL Labs Research최종 수정
오픈 모델HermesNous Research파인튜닝오픈 웨이트

진화의 마지막 단계는 모델을 빌리는 대신 직접 소유하는 거예요. 여기까지 우리는 모델을 빌려 썼어요. 채팅창에 프롬프트를 넣고(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 태그)은 다르지만 발상은 같아요. 출력을 인터페이스로 강제하는 것. 그래서 프런티어 모델용으로 설계한 검증·훅 로직을 오픈 모델로 옮길 때도 어댑터 정도만 바꾸면 대부분 재사용할 수 있어요.

참고자료

  1. [1]Hermes 3 기술 보고서 (arXiv)
  2. [2]Hermes-Function-Calling (GitHub, Nous Research)
  3. [3]Hermes 3 Llama 3.1 8B (Hugging Face)

요약

  • 오픈 웨이트 모델은 비용·데이터 프라이버시·도메인 커스터마이징을 직접 통제할 수 있게 해줘요.
  • Nous Research의 Hermes 계열은 시스템 프롬프트 준수·함수 호출에 강한 오픈 모델로, 모델·에이전트·하네스를 통째로 열어 두고 있어요.
  • Hermes Function Calling 표준은 <tools>/<tool_call>/<tool_response> 태그로 tool_use와 같은 발상(출력을 인터페이스로 강제하기)을 구현해요.
  • 잘 설계된 하네스는 실행마다 규격화된 데이터를 남겨, 그 데이터로 오픈 모델을 도메인에 맞게 길들이는 플라이휠이 돌아가요.

TRAIL Labs가 왜 이렇게 일하는지

연구자 창업자가 측정과 처방의 근거를 어떻게 세우는지, 세 제품이 회사와 어떤 관계인지는 회사 소개에 정리했고, 날마다 일하는 방식은 따로 적어 두었습니다.

다른 글

같은 주제로 이어 읽기

이 글은 TRAIL Labs 카테고리에 속해요. 같은 카테고리 글 16편을 한자리에서 볼 수 있어요. TRAIL Labs 카테고리 글 전체 보기