Hermes가 모든 것을 늘 들고 있지 않고 필요할 때 꺼내게 만든 방법-4계층 컨텍스트 캡슐과 progressive tool disclosure로 고정 입력을 37.61% 줄인 사례

📝 한줄 요약

대화의 맥락을 잃지 않으려면 모든 과거 대화·도구·메모리를 매번 모델에게 보여줘야 한다고 생각하기 쉽다. 이번 작업에서는 오히려 상시 규칙, 활성 캡슐, 검색 기억, 원본·증거를 네 층으로 분리하고, 도구는 tool_search로 필요할 때만 공개하도록 바꿨다. 기능과 원본을 삭제하지 않은 채 시스템 프롬프트와 도구 스키마의 고정 입력을 175,950B에서 109,775B로 37.61% 줄였고, 백업·설정·테스트·새 프로세스 통합 검증을 따로 통과시켰다.

바쁘시면 이것만 읽어도 됩니다.

• 맥락을 지키는 방법은 모든 정보를 상시 주입하는 것이 아니라 정보마다 맞는 저장소와 호출 시점을 정하는 것이다.

• 장기 메모리에는 오래 유지되는 사실만 남기고, 현재 작업 상태는 프로젝트 캡슐, 과거 대화는 세션 검색, 원문은 canonical에서 확인하도록 분리했다.

• 도구 99개를 전부 노출하는 대신 35개만 즉시 보여주고, 64개는 검색 시점까지 지연했다.

• 실제 MCP 포함 도구 스키마는 131,211B에서 66,283B로 49.48% 줄었다.

• 6개 활성 프로필에는 기능 삭제가 아니라 tools.tool_search.enabled 한 경로만 적용했다.

• 백업 9/9 해시 일치, 설정 6/6, tool-search 테스트 39/39, fresh-process MCP 통합을 확인했다.

• 시간·비용·정답률 개선은 측정하지 않았으므로 성과 수치로 만들지 않았다.

• 새 세션부터 적용되는 구조이며, 이미 실행 중이던 Slack 세션은 재구성하지 않았다.

🎯 이런 분들께 도움됩니다

• AI 에이전트의 대화가 길어질수록 시스템 프롬프트가 비대해지는 운영자

• MCP·플러그인 도구가 늘어 모델이 도구 설명만 읽는 비용을 줄이고 싶은 사람

• 장기 메모리, 프로젝트 상태, 세션 기록, 원본 문서를 어디에 저장할지 기준이 필요한 사람

• 여러 전문 에이전트가 같은 맥락을 공유하되 서로의 세부 작업까지 모두 들고 다니지 않게 만들고 싶은 팀

• compaction만으로 해결되지 않는 컨텍스트 오염과 복원 문제를 운영 규칙으로 다루려는 사람

😫 문제 상황 — “맥락 유지”가 “전부 상시 주입”으로 변하고 있었다

처음 질문은 단순했다.

컨텍스트는 어떻게 관리해야 맥락을 유지하면서도 효율적일까?

하지만 실제 환경에서 컨텍스트라고 부르던 것은 한 종류가 아니었다.

“잊지 않게 하자”는 선의로 장기 메모리에 완료 작업, 임시 경로, 세부 절차를 계속 넣으면 다음 작업에서 오히려 오래된 상태가 튀어나올 수 있다. 모든 도구를 미리 보여주면 사용 가능한 기능은 많아 보이지만, 모델이 읽고 구분해야 할 스키마도 함께 늘어난다.

문제의 핵심은 컨텍스트 창의 절대 크기보다 현재 단계에서 유효한 정보와 나중에 검색할 정보를 구분하지 않은 것이었다.

🌱 첫 번째 전환점 — 컨텍스트를 저장소가 아니라 “작업 메모리”로 보기

Anthropic은 컨텍스트를 무한 저장소가 아니라 제한된 attention budget으로 보고, 원하는 결과에 필요한 가장 작은 고신호 토큰 집합을 찾는 일을 context engineering이라고 설명한다. LangChain도 이를 write, select, compress, isolate로 나눈다.

이 관점에서 보면 “보존할 것”과 “지금 모델에게 보여줄 것”은 같은 질문이 아니다.

보존 범위는 넓게
현재 주입 범위는 좁게
결론을 낼 때는 원본으로 다시 검증

그래서 하나의 거대한 메모리 대신 네 층을 만들었다.

그림 1. 새 공용 운영 규칙에서 파생한 구조 카드다. UI 스크린샷이 아니며, “항상 넣기 → 필요할 때 찾기 → 원본으로 검증하기”라는 책임 경계를 시각화했다.

L0 — 상시 규칙

매 세션에서 반드시 필요한 정보만 둔다.

• 에이전트의 정체성과 안전 규칙

• 오래 유지되는 사용자 선호

• 환경과 작업 방식의 안정 사실

여기에는 임시 TODO, 완료된 작업 일지, 곧 바뀔 경로·ID·해시를 넣지 않는다.

L1 — 활성 캡슐

프로젝트 단위로 다음만 유지한다.

• 목표와 완료 조건

• 확정 결정과 이유

• 완료·진행·차단 상태

• 원본·산출물 좌표

• 다음 행동

캡슐은 매 메시지마다 갱신하지 않고 작업 시작, 결정 변경, 단계 전환, 인계, 압축, 완료 같은 경계에서만 갱신한다.

L2 — 검색 기억

세션 DB, DEVLOG, Chronicle, 프로젝트 문서는 계속 보존하되 매번 넣지 않는다. 새 요청에서 프로젝트·기간·출처 키를 뽑고, 후보만 검색한 뒤 필요한 메시지와 문서를 읽는다.

L3 — 원본·증거

원문, 실행 로그, 캡처, 해시, 최종 산출물은 사실 원장으로 남긴다. 요약과 캡슐이 원본과 충돌하면 원본을 우선하고 캡슐을 고친다.

이 구조에서 요약은 탐색용 지도이고 canonical은 최종 사실 원장이다.

🔧 두 번째 전환점 — 메모리 문제와 도구 문제를 따로 풀기

1. 장기 메모리를 안정 사실 중심으로 압축

Hermes의 장기 메모리는 세션 시작 때 시스템 프롬프트에 고정 주입된다. 따라서 자주 바뀌는 정보를 넣으면 용량만 차지하는 것이 아니라 다음 세션의 판단에도 영향을 준다.

이번 작업에서는 다음 기준으로 정리했다.

그 결과 MEMORY는 2,171자에서 1,545자로 28.83%, USER 프로필은 1,339자에서 1,057자로 21.06% 줄었다. 삭제한 것은 원본 대화가 아니라 상시 주입할 이유가 부족한 중복·일시 상태였다.

2. 도구를 삭제하지 않고 점진적으로 공개

더 큰 변화는 도구 스키마에서 나왔다. 모든 MCP·플러그인 도구를 비활성화하면 고정 입력은 줄어도 기능이 끊긴다. 그래서 기능을 제거하지 않고 다음 브리지를 남겼다.

필요한 기능 발생
→ tool_search로 후보 검색
→ tool_describe로 정확한 스키마 로드
→ tool_call로 실행

즉, 도구 inventory는 넓게 유지하고 모델-facing 도구면은 좁게 유지했다.

그림 2. 검증 영수증의 before/after 값에서 자동 생성한 데이터 파생 카드다. 실제 MCP 포함 도구 스키마와 시스템 프롬프트+도구 고정 입력의 구조적 차이를 보여 주며, 비용·속도·정답률 향상을 의미하지는 않는다.

⚙️ 실제 적용 과정

1. 먼저 변경 전 상태를 동결했다

• 기본 프로필과 전문 프로필 설정·메모리 파일 9개를 백업했다.

• 백업 manifest의 SHA-256과 실제 파일을 다시 계산해 9/9 일치를 확인했다.

• Slack 라우팅, 인증정보, compressor 설정은 변경 대상에서 제외했다.

• 세션·canonical·원본은 삭제하지 않는 경계를 먼저 정했다.

2. 공용 운영 계약을 문서화했다

• CONTEXT-MANAGEMENT 운영 규칙

• 프로젝트별 CONTEXT-CAPSULE 템플릿

• 이번 작업의 완료 캡슐

• 검증 영수증

이 네 가지가 생기면서 “무엇을 기억할까?”가 “어디에, 얼마나 오래, 어떤 근거와 함께 둘까?”로 바뀌었다.

3. 6개 프로필에 같은 도구 공개 원칙을 적용했다

기본 TARDIS, 문서 변환, 이미지, 지식 라이브러리, 법률 참모, 금융 전문 프로필에 같은 설정 경로를 적용했다. 변경된 config 경로는 tools.tool_search.enabled 하나뿐이었고 Slack 라우팅은 6/6 동일했다.

4. 세션 DB는 삭제 없이 optimize만 수행했다

FTS 인덱스 2개를 비파괴 optimize했다. 다만 실행 중 기록이 계속 추가되어 DB 크기는 7,652.0MB에서 7,652.9MB가 됐다. 따라서 이를 “공간 정리 성공”이라고 부르지 않고 검색 인덱스 구조 정리, 공간 회수 없음으로 기록했다.

📊 실제로 달라진 수치

가장 큰 절감은 문장을 몇 줄 줄인 데서가 아니라 사용하지 않을 도구 스키마를 미리 싣지 않은 것에서 나왔다.

하지만 이 표는 다음을 증명하지 않는다.

• 응답 시간이 37.61% 빨라졌다는 뜻이 아니다.

• 토큰 과금이 정확히 37.61% 줄었다는 뜻이 아니다.

• 정답률이나 회상 정확도가 향상됐다는 뜻이 아니다.

이번에 측정한 것은 고정 입력의 바이트와 노출 도구 수다. 운영 성능은 이후 실제 세션 관찰로 별도 측정해야 한다.

🧪 “파일을 썼다”와 “작동한다”를 분리해 검증

설정 파일에 값을 넣었다는 사실만으로 새 구조가 작동한다고 볼 수 없었다. 검증을 네 층으로 나눴다.

그림 3. 실행 영수증에서 파생한 완료 경계 카드다. live telemetry가 아니며 새 세션 적용, 현재 세션 불변, 외부 메모리 provider 미도입을 함께 표시했다.

🧯 구체적인 실패와 수리

실패 1 — 기본 prompt-size만으로는 live MCP 절감을 증명하지 못했다

처음에는 시스템 프롬프트 크기만 비교하면 충분하다고 생각할 수 있었다. 그러나 실제 병목은 런타임에서 합쳐지는 MCP 도구 스키마였다. 정적 수치만으로는 tool_search가 새 프로세스에서 어떤 도구 배열을 만드는지 증명할 수 없었다.

그래서 fresh-process 통합 프로브를 추가했다.

MCP 도구 실제 발견
→ progressive disclosure 적용 전 도구 배열 조립
→ 적용 후 도구 배열 조립
→ 도구 수와 직렬화 바이트 비교
→ 검색 브리지로 지연 도구 발견 가능 여부 확인

이 프로브에서 모델에 즉시 노출되는 도구가 99개·131,211B에서 35개·66,283B로 줄고, 별도의 검색 inventory에서는 MCP 도구 67개가 발견된다는 점을 확인했다. 64개 지연 도구 수와 67개 MCP 발견 수는 측정면이 다르므로 합치지 않았다. 측정면을 고친 뒤에야 절감 수치를 채택했다.

실패 2 — 비대화식 OAuth 한 건이 전체 MCP 실패처럼 보일 수 있었다

통합 프로브에서 기존 OAuth 연결 한 건은 비대화식 갱신 HTTP 400으로 실패했다. 이를 전체 tool-search 실패로 뭉개지 않았다.

• progressive disclosure 조립: PASS

• 다른 MCP 도구 발견: 67개

• 해당 OAuth의 새 연결: 필요할 때 대화형 재인증

기능 성공과 인증 경계를 분리한 것이다.

실패 3 — optimize가 디스크 공간을 돌려주지 않았다

FTS optimize 명령은 정상 종료됐지만 저장 공간은 줄지 않았다. 따라서 “DB 최적화 성공”을 “용량 감소 성공”으로 바꾸어 쓰지 않았다. 이번 단계의 결과는 인덱스 2개 정리이며, 세션 삭제와 공간 회수는 수행하지 않았다.

✅ Before와 After

🧾 Trace · Proof · Verdict · Repair

Trace

문제 정의
→ 외부 context-engineering 사례 조사
→ 현재 프로필·메모리·세션·도구면 진단
→ 변경 전 9개 파일 백업
→ 4계층 운영 규칙과 캡슐 템플릿 작성
→ MEMORY·USER 안정 사실 중심 압축
→ 6개 프로필에 tool_search 점진 공개 적용
→ FTS 비파괴 optimize
→ 정적 prompt-size 한계 발견
→ fresh-process MCP 통합 프로브
→ 검증 영수증·DEVLOG·Chronicle
→ 사례게시글과 데이터 파생 증거 카드

Proof

• 변경 전 백업 9/9 SHA-256 일치

• 6개 프로필 설정 검사와 Slack 라우팅 불변 확인

• tool-search 테스트 39/39 통과

• fresh-process MCP 통합 통과

• 99개→35개, 131,211B→66,283B read-back

• 공용 규칙·캡슐·템플릿·JSON 영수증 파싱과 해시 확인

• 데이터 파생 SVG 3개 XML 파싱·미러 해시·시각 QA 통과

Verdict

context_operating_standard: PASS
context_capsule: PASS
memory_profile_compaction: PASS
progressive_tool_disclosure: PASS
fresh_process_integration: PASS
current_live_session_reassembly: NOT_RUN
external_memory_provider: NOT_RUN
session_deletion: NOT_RUN
measured_quality_or_latency_gain: NOT_MEASURED

Repair

• “더 많이 넣어야 맥락이 유지된다”를 “수명별로 보존하고 필요할 때 선택한다”로 고쳤다.

• 장기 메모리의 임시 상태를 캡슐·DEVLOG·세션 검색으로 이동했다.

• 도구를 끄는 대신 검색 브리지로 점진 공개했다.

• 정적 prompt-size 대신 실제 MCP를 포함한 새 프로세스 통합 수치를 사용했다.

• 공간이 회수되지 않은 optimize와 비대화식 OAuth 실패를 성공 범위 밖에 남겼다.

📋 재사용 가능한 컨텍스트 관리 체크리스트

[ ] 먼저 시스템 프롬프트, 메모리, 도구 스키마, 세션 저장소를 따로 측정한다.
[ ] 원본·세션·설정을 변경하기 전에 해시 포함 백업을 만든다.
[ ] 정보를 상시 규칙, 활성 상태, 검색 기억, 원본·증거로 분류한다.
[ ] 장기 메모리에는 오래 유지되는 사실만 둔다.
[ ] 프로젝트 상태는 캡슐에 두고 경계 시점에만 갱신한다.
[ ] 절차는 skill, 실행 사실은 DEVLOG, 관계 기록은 Chronicle에 둔다.
[ ] 모든 도구를 끄기 전에 progressive disclosure를 검토한다.
[ ] 설정 파일뿐 아니라 새 프로세스의 실제 도구 배열을 검증한다.
[ ] source·backup·artifact·receipt의 해시를 다시 읽는다.
[ ] 현재 세션과 새 세션의 적용 경계를 구분한다.
[ ] 입력 감소와 속도·비용·정답률 개선을 같은 주장으로 만들지 않는다.
[ ] 실패한 인증·검색·optimize 경로를 전체 성공과 분리한다.

💬 재사용 가능한 프롬프트

현재 Hermes Agent의 컨텍스트를 맥락 손실 없이 경량화해 주세요.

1. 시스템 프롬프트, MEMORY·USER, 도구·MCP 스키마, 세션 저장소를 각각 측정합니다.

2. 변경 전 설정과 메모리를 SHA-256 manifest와 함께 백업합니다.

3. 정보를 L0 상시 규칙, L1 활성 프로젝트 캡슐, L2 검색 기억, L3 canonical 원본·증거로 분류합니다.

4. 장기 메모리에는 1주 이상 유지될 안정 사실만 남기고, 절차는 skill, 작업 상태는 capsule, 실행 사실은 DEVLOG·Chronicle로 이동합니다.

5. 도구를 삭제하지 말고 tool_search → tool_describe → tool_call 점진 공개를 우선 검토합니다.

6. 정적 설정 확인뿐 아니라 새 프로세스에서 실제 MCP를 포함한 도구 수와 스키마 바이트를 before/after로 측정합니다.

7. 라우팅·인증·compressor·원본·세션 삭제는 별도 승인 없이는 변경하지 않습니다.

8. 백업, 설정, 단위 테스트, 통합 테스트, 검색, 산출물 read-back을 서로 다른 Gate로 보고합니다.

9. 측정하지 않은 비용·속도·정답률 효과는 만들지 않습니다.

🌍 다른 업무에 적용한다면

이 구조는 AI 에이전트 외의 지식 업무에도 그대로 적용할 수 있다.

• 법률 검토: 법체계와 안정 원칙은 L0, 현재 사건 쟁점은 L1, 과거 의견서 검색은 L2, 조문·판례 원문은 L3로 둔다.

• 문서 변환: 변환 규칙은 skill, 현재 배치 상태는 capsule, 과거 변환 기록은 DEVLOG, 원본 PDF·HWP는 canonical로 둔다.

• 여행 계획: 고정 선호는 L0, 확정 일정은 L1, 후보 장소와 이전 대화는 L2, 항공·예약·운영시간 원문은 L3로 둔다.

• 멀티에이전트 운영: 총괄 에이전트는 캡슐과 결정만 공유하고, 전문 에이전트의 긴 탐색 결과는 각 작업공간에 남긴 뒤 결론·근거·불확실성만 인계한다.

중요한 것은 저장소 이름이 아니라 상시 주입, 선택 검색, 원본 검증의 책임을 섞지 않는 것이다.

🚧 아직 확인하지 않은 것

• 실제 장기 운영에서의 회상 정확도 변화

• 평균 입력 토큰·비용·응답시간 변화

• 도구 선택 오류율 변화

• 외부 메모리 provider와의 비교 실험

• 현재 진행 중 세션의 도구 배열 재조립

• 비대화식 OAuth가 실패한 연결의 대화형 재인증

이 항목은 구조적 절감 수치로 대체할 수 없다. 실제 회상 실패나 성능 변화가 관찰될 때 다음 단계 실험으로 다룬다.

📚 참고자료

• Anthropic, Effective context engineering for AI agents
  https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

• LangChain, Context Engineering
  https://blog.langchain.com/context-engineering-for-agents/

• OpenAI Developers, Compaction
  https://developers.openai.com/api/docs/guides/compaction

• Hermes Agent, Persistent Memory
  https://hermes-agent.nousresearch.com/docs/user-guide/features/memory

• Liu et al., Lost in the Middle: How Language Models Use Long Contexts
  https://arxiv.org/abs/2307.03172