[논문 리뷰] HyperTool — 에이전트의 도구 호출 단위를 다시 설계하기

한 줄 요약

HyperTool은 LLM 에이전트가 도구를 하나씩 호출하고 결과를 다시 읽고 다음 도구를 고르는 방식을 줄인다. 대신 여러 도구 호출과 중간값 처리를 하나의 실행 가능한 코드 블록 안에 넣어, 모델에게는 큰 단위의 도구 실행 하나만 보이게 만든다.

논문이 지적하는 핵심 문제는 명확하다.

지금의 tool-augmented agent는 너무 낮은 수준의 실행 과정을 모델의 reasoning trace에 노출한다.

내가 보기엔 이 논문은 “도구를 더 많이 붙이자”가 아니라, 도구 호출의 추상화 레벨을 어디에 둘 것인가를 묻는 글이다. Hermes나 Claude Code 같은 에이전트 하네스에서도 바로 중요한 주제다.

배경: step-wise tool call의 피로감

일반적인 에이전트 도구 호출은 이런 식으로 흘러간다.

1. 검색 도구 호출
2. 결과 관찰
3. 파일 읽기 도구 호출
4. 결과 관찰
5. JSON 파싱
6. 다시 검색
7. 중간값 조합
8. 최종 답변

사람 입장에서는 “그냥 최신 논문 몇 개 찾아서 표로 정리해줘” 같은 하나의 요청인데, 모델 입장에서는 매번 다음 결정을 해야 한다.

문제는 이 중 상당수가 실제로는 추론이 아니라 deterministic workflow라는 점이다.

예를 들어:

results = search("HyperTool arxiv")
paper = select_first_arxiv(results)
metadata = fetch_arxiv_metadata(paper.id)
summary = normalize(metadata.summary)

이런 흐름은 모델이 매 단계마다 토큰을 써서 고민할 필요가 없다. 검색 결과를 받고, ID를 뽑고, API를 부르고, 필드를 정리하는 것은 대부분 로컬 프로그램이 훨씬 잘한다.

HyperTool은 이 mismatch를 execution-granularity mismatch라고 부른다.

핵심 아이디어: 도구 호출을 코드 블록으로 접기

HyperTool의 제안은 단순하지만 강하다.

모델이 기존 도구들을 직접 하나씩 호출하는 대신, 하나의 HyperTool 호출 안에 코드를 작성한다. 그 코드는 기존 도구들의 schema를 그대로 호출할 수 있고, 반환값을 변수에 담고, 중간값을 조작하고, 필요한 subroutine을 로컬에서 처리한다.

개념적으로는 이런 느낌이다.

# model-visible outer call: HyperTool
papers = arxiv.search(query="tool-augmented agents MCP", max_results=5)
selected = [p for p in papers if "tool" in p.title.lower()]
metadata = [arxiv.get(p.id) for p in selected]
return summarize(metadata)

중요한 점은 모델에게 노출되는 단위가 바뀐다는 것이다.

기존 방식:

LLM -> tool A -> observation -> LLM -> tool B -> observation -> LLM -> tool C

HyperTool 방식:

LLM -> HyperTool(code that calls A, B, C locally) -> observation

즉, deterministic한 low-level dataflow를 trace 밖으로 접어 넣는다. 모델은 “무엇을 달성할지”와 “큰 실행 계획”에 집중하고, 세부 값 전달과 반복 작업은 실행 환경이 담당한다.

왜 중요한가: context, latency, accuracy

이 접근이 중요한 이유는 세 가지다.

1. Context 낭비를 줄인다

step-wise 방식은 모든 호출, 관찰, 중간값이 모델의 context에 남는다. 특히 MCP나 browser automation처럼 observation이 큰 도구는 금방 trace가 지저분해진다.

HyperTool은 중간값을 로컬 변수로 처리한다. 모델에게 필요한 최종 observation만 돌려주면 된다.

모델 context에 남길 것: 최종 요약, 실패 원인, 핵심 결과
로컬에 숨길 것: 반복 호출 로그, 임시 JSON, 중간 필터링 결과

이 차이는 장기 작업에서 크다. 에이전트가 30분 동안 일하면, 성능 병목은 모델 지능보다 trace hygiene이 되는 경우가 많다.

2. Latency를 줄인다

매 tool call마다 모델 round-trip이 들어가면 느리다. 특히 “도구 A 결과에서 id를 뽑아 도구 B에 넣는다” 같은 단순한 흐름까지 모델을 거치면 latency가 누적된다.

HyperTool은 여러 호출을 하나의 외부 호출로 묶는다. 로컬 실행은 빠르고, 모델 호출 횟수는 줄어든다.

3. 정확도가 오른다

논문은 MCP-Universe에서 HyperTool이 Qwen3 계열 모델의 평균 정확도를 크게 높였다고 보고한다.

• Qwen3-32B: 15.69% → 35.29%
• Qwen3-8B: 9.93% → 33.33%

흥미로운 건 작은 모델에서 효과가 더 극적으로 보인다는 점이다. 작은 모델일수록 긴 trace에서 중간 상태를 안정적으로 관리하기 어렵다. HyperTool은 그 부담을 실행 환경으로 넘긴다.

기존 agent framework와의 차이

LangChain, MCP, OpenAI function calling, Claude tool use 모두 도구 호출 인터페이스를 제공한다. 그런데 대부분의 기본 abstraction은 여전히 “한 번에 하나의 도구 호출”에 가깝다.

HyperTool은 다음 레벨의 질문을 한다.

도구를 호출할 수 있게 하는 것만으로 충분한가? 아니면 도구 호출들을 구성하는 작은 프로그램을 실행할 수 있어야 하는가?

나는 후자에 가깝다고 본다.

실무 자동화에서 자주 나오는 작업은 대개 이런 형태다.

검색 -> 후보 필터링 -> 원문 조회 -> 메타데이터 정규화 -> 파일 업데이트 -> 검증

이걸 매번 모델-visible step으로 펼치면, 모델은 “생각”보다 “배관”에 토큰을 쓴다. 좋은 하네스는 배관을 숨기고, 판단이 필요한 지점만 모델에게 남겨야 한다.

Hermes 관점에서 읽기

Hermes에는 이미 비슷한 패턴이 있다. execute_code가 대표적이다.

• 단일 tool call이 아니라 여러 파일 읽기, 터미널 실행, 결과 필터링을 Python 코드 안에서 처리한다.
• 큰 output을 그대로 context에 넣지 않고, 필요한 요약만 출력한다.
• 반복/조건/파싱 같은 deterministic logic을 모델 trace 밖으로 뺀다.

즉, HyperTool은 연구 논문 형태로 정리된 agent tool orchestration의 실무 감각에 가깝다.

내가 이 논문에서 가장 유용하다고 느낀 포인트는 이것이다.

모델이 잘해야 하는 일:
- 목표 해석
- 어떤 정보가 필요한지 결정
- 실패 시 전략 수정
- 최종 판단과 설명
 
모델이 굳이 직접 할 필요 없는 일:
- JSON 필드 뽑기
- 여러 페이지 반복 조회
- 중간값 변수 관리
- deterministic transform
- 단순 retry loop

이 경계를 잘 나누는 것이 agent harness 설계의 핵심이다.

구현할 때의 주의점

HyperTool류 인터페이스를 실제 시스템에 넣을 때는 장점만 있는 게 아니다.

1. 보안 sandbox가 필수다

모델이 코드 블록을 작성하고 그 코드가 도구를 호출한다면, 사실상 작은 프로그램을 실행하는 것이다. 파일 접근, 네트워크 접근, credential 접근 권한을 명확히 제한해야 한다.

최소한 다음이 필요하다.

- 허용된 tool schema만 호출
- 파일 시스템 scope 제한
- 네트워크 allowlist 또는 timeout
- secret 출력 차단
- 실행 로그 보존

도구 호출을 접어 넣을수록 관찰 가능성이 줄어들기 때문에, sandbox와 audit log는 더 중요해진다.

2. 실패 디버깅이 어려워질 수 있다

step-wise trace는 장황하지만 디버깅은 쉽다. 어디서 실패했는지 모델과 사람이 모두 볼 수 있다.

HyperTool은 중간 과정을 숨기므로, 실패 시에는 잘 설계된 error report가 필요하다.

{
  "success": false,
  "failed_at": "arxiv.get",
  "input": "2606.13663",
  "error": "timeout",
  "retryable": true
}

단순히 “HyperTool failed”만 반환하면 오히려 나빠진다.

3. 모든 작업을 접으면 안 된다

판단이 필요한 지점까지 코드 안에 숨기면 모델의 장점이 사라진다. 예를 들어 “어떤 논문이 블로그에 더 적합한가”는 로컬 필터보다 모델 판단이 더 낫다.

좋은 기준은 이렇다.

반복 가능하고 검증 가능한 작업 -> HyperTool 안으로
맥락 판단과 취향이 필요한 작업 -> 모델 trace에 남기기

실무 적용 패턴

내가 바로 적용한다면 다음 세 가지 패턴부터 쓸 것 같다.

패턴 1. Research bundle

입력: 주제
HyperTool 내부:
- arXiv 검색
- 공식 블로그/RSS 검색
- 중복 제거
- 최신순 정렬
- source quality score 계산
출력: 후보 5개와 근거 링크

AI 블로그의 trend radar 같은 작업에 잘 맞는다.

패턴 2. Repo inspection bundle

입력: 변경 요청
HyperTool 내부:
- 관련 파일 검색
- symbol 후보 추출
- package script 확인
- 최근 git diff 요약
출력: 수정 후보 파일과 위험도

코딩 에이전트에서 매번 search_files, read_file, git status를 하나씩 펼치는 대신 한 번에 묶을 수 있다.

패턴 3. QA bundle

입력: 생성된 파일 경로
HyperTool 내부:
- frontmatter 검사
- MDX 특수문자 검사
- typecheck 실행
- build dry-run
출력: pass/fail과 수정 가능한 오류 목록

블로그 자동 작성에서는 특히 유용하다. 생성은 모델이 하되, 검증은 deterministic하게 돌리는 편이 낫다.

내 결론

HyperTool은 “도구를 쓰는 에이전트”에서 “도구 워크플로우를 프로그래밍하는 에이전트”로 넘어가는 흐름을 보여준다.

에이전트 성능을 높이기 위해 항상 더 큰 모델이 필요한 것은 아니다. 때로는 모델이 봐야 할 실행 단위를 잘 설계하는 것만으로도 정확도와 비용 구조가 크게 바뀐다.

내가 가져갈 설계 원칙은 하나다.

참고 자료

• HyperTool: Beyond Step-Wise Tool Calls for Tool-Augmented Agents
• MCP 공식 소개
• Hermes Agent 문서