Hermione는 어떻게 동작할까: OpenClaw로 멀티 에이전트 리서치 파트너 만들기

이전 글을 올리고 나서 가장 많이 받은 질문이 이거였어요.

“좋아요. 근데 Hermione는 실제로 어떻게 돌아가요?”

짧게 말하면, Hermione는 “기억력이 비정상적으로 좋은 단일 슈퍼 에이전트”가 아닙니다.

OpenClaw의 세션 도구를 기반으로 만든 워크플로우 패턴이에요. 한 에이전트가 다른 에이전트의 세션 히스토리를 읽고, 작업을 위임하고, 결과를 다시 하나의 내러티브로 묶는 구조죠.

비슷한 시스템을 직접 만들고 싶은 분들을 위해, 실전 관점으로 정리해볼게요.

한 줄 아키텍처

Hermione가 잘 작동하는 이유는 역할을 분리했기 때문입니다.

  • Harry: 실행 담당 (코딩, 구현, 디버깅)
  • Hermione: 오케스트레이션 담당 (기획, 요약, 글쓰기, 리뷰)

핵심은 “어느 모델이 더 똑똑한가”가 아니에요. 역할 경계를 명확히 두고, 그 경계를 OpenClaw 도구로 연결한 게 핵심입니다.

핵심 세션 도구 4개

OpenClaw 세션 도구의 중심은 이 네 가지입니다.

  • sessions_list
  • sessions_history
  • sessions_send
  • sessions_spawn

공식 개념 문서: docs/concepts/session-tool.md

1) sessions_list

사용 가능한 세션 목록을 보여줍니다. (main, group, cron, hook, node 등) 세션 탐색용이에요.

2) sessions_history

대상 세션의 대화 히스토리를 가져옵니다. “다른 에이전트가 이미 한 작업을 읽는다”는 동작의 핵심입니다.

3) sessions_send

다른 세션으로 메시지를 보내고, 필요하면 응답까지 기다릴 수 있습니다. 에이전트 간 핸드오프에 좋아요.

4) sessions_spawn

격리된 서브에이전트 실행을 비동기로 시작하고, 끝나면 다시 알려줍니다. 오래 걸리는 백그라운드 작업에 좋아요.

소스코드에서 확인한 포인트

동작을 정확히 확인하려고 로컬 OpenClaw 소스를 직접 확인했습니다.

A) 히스토리 접근은 가능하지만, 정책으로 막힌다

createSessionsHistoryTool (dist/reply-DRsqbakU.js, 대략 41601줄 이후)에서 확인되는 것:

  • 세션 키를 안전하게 해석
  • 샌드박스 가시성 제한(restrictToSpawned) 적용
  • 에이전트 간 접근 시 tools.agentToAgent 정책 검사
  • chat.history 호출 후 필요 시 tool 메시지 필터링

즉, Hermione가 Harry 세션을 읽을 수 있는 건 “프롬프트 꼼수”가 아니라 정책 허용 하의 공식 경로입니다.

B) 에이전트 간 메시지도 명시적 가드레일이 있다

createSessionsSendTool (대략 42076줄 이후):

  • 샌드박스 가시성 제한 적용
  • agentToAgent가 꺼져 있거나 allowlist에 없으면 cross-agent send 거부
  • provenance를 inter_session으로 명시

에이전트 간 라우팅이 1급 기능으로 구현돼 있다는 뜻입니다.

C) 서브에이전트 폭증을 막는 제한이 있다

createSessionsSpawnTool (대략 42400줄 이후):

  • 서브에이전트가 다시 sessions_spawn을 호출하는 건 금지 (sessions_spawn is not allowed from sub-agent sessions)
  • allowAgents 규칙으로 cross-agent spawn 제어

이게 없으면 “에이전트가 에이전트를 낳는” 폭주가 금방 생깁니다.

안전 모델이 중요한 이유

이 패턴을 복제하려면 여기가 가장 중요합니다.

OpenClaw가 기본으로 잡아주는 안전 장치:

  1. 샌드박스 세션 도구 가시성 기본값은 spawned-only
  2. agent-to-agent 접근은 명시적 활성화 + allowlist 필요
  3. 서브에이전트는 재귀적으로 서브에이전트를 spawn할 수 없음

관련 문서:

  • docs/concepts/session-tool.md
  • docs/gateway/configuration-reference.md (tools.agentToAgent, agents.defaults.subagents)

이 제약이 없으면 멀티 에이전트 구조는 생각보다 빨리 혼란스러워집니다.

Hermione가 실제로 하는 일

일상 워크플로우는 대략 이렇습니다.

  1. Harry가 구현하고, 세션에 의사결정 로그를 남긴다
  2. Hermione가 필요한 히스토리를 읽는다 (sessions_history)
  3. Hermione가 맥락과 의사결정 이유를 재구성한다
  4. 문서와 글 초안을 만든다
  5. 내가 리뷰하고 방향을 잡는다

즉 Hermione는 “비서”라기보다, 실행 결과와 최종 산출물 사이를 잇는 리서치/요약 오퍼레이터에 더 가깝습니다.

나만의 “Hermione” 패턴 만들기 체크리스트

복잡하게 시작할 필요 없습니다.

  1. 에이전트 1개 대신 역할 2개로 시작
    • 실행 담당
    • 오케스트레이션/문서 담당
  2. 오케스트레이터에 세션 도구를 부여
    • sessions_list, sessions_history (필요 시 sessions_send)
  3. tools.agentToAgent는 꼭 allowlist 기반으로 제한
  4. 정말 필요하기 전까지는 spawned-only 가시성 유지
  5. “문서 산출”을 done-definition에 포함

그리고 제일 중요한 한 줄:

데모가 얼마나 똑똑해 보이는지가 아니라, 실제 산출물 품질로 판단하세요.

마무리

Hermione를 유용하게 만드는 건 “초능력 기억”이나 “마법 프롬프트”가 아닙니다.

시스템 설계의 결과예요.

  • 역할 분리
  • 세션 간 명시적 인터페이스
  • 정책 기반 접근 제어
  • 문서화 루프

하나만 가져간다면 이거예요.

에이전트 워크플로우를 채팅 트릭이 아니라 소프트웨어 아키텍처처럼 설계하세요.

신뢰성은 거기서 나옵니다.

Source Notes

로컬 OpenClaw 빌드에서 확인한 코드:

  • /opt/homebrew/lib/node_modules/openclaw/dist/reply-DRsqbakU.js
    • createSessionsHistoryTool (~41601)
    • createSessionsSendTool (~42076)
    • createSessionsSpawnTool (~42400)

확인한 문서:

  • /opt/homebrew/lib/node_modules/openclaw/docs/concepts/session-tool.md
  • /opt/homebrew/lib/node_modules/openclaw/docs/gateway/configuration-reference.md