Hermes 에이전트가 작업 컨텍스트를 잊어버리지 않게 하는 방법 (2026)

현재 에이전트 실행이 컨텍스트를 처리하는 방식

실행은 시작 시점에 컨텍스트를 받습니다. 사용자의 지침, 목표, 접근 가능한 파일이나 도구 등이 이에 해당합니다. 에이전트가 작업을 수행하면서 자체 컨텍스트 창 내부에서 이해도(예: 이 서비스가 해당 로직을 소유함, 이 접근 방식은 실패함, 이 제약 조건이 중요함 등)를 구축합니다. 실행이 완료되면 이러한 컨텍스트 창은 폐기됩니다. 실행 결과를 기록할 저장소가 없기 때문에, 이전 실행에서 아무리 많은 것을 배웠더라도 다음 실행은 다시 시작 프롬프트부터 시작하게 됩니다.

멀티 에이전트가 문제를 악화시키는 기술적 이유

멀티 에이전트 시스템은 문제를 해결하기는커녕 오히려 배가시킵니다. 각 에이전트는 자체 컨텍스트 창을 가지며, 이를 공유하지 않습니다. 핸드오프(handoff)는 메시지나 요약본을 전달할 뿐, 그 뒤에 숨겨진 추론 과정을 전달하지 않습니다. 따라서 수신하는 에이전트는 결론을 도출해낸 제약 조건을 모른 채 결론만 물려받게 됩니다. 병렬로 작동하는 에이전트들은 서로가 무엇을 확인했는지 볼 수 없기 때문에 동일한 조사를 중복해서 수행하거나 상충되는 결정을 내릴 수 있습니다. 그리고 실행이 끝나면 N개 에이전트 분량의 학습 내용이 한 번에 사라집니다.

이로 인해 발생하는 비용

모든 실행은 독립적으로 작동하는 에이전트 수만큼 곱해진 '재탐색 비용(rediscovery tax)'을 지불합니다. 실행 간에 결정 사항이 다시 논쟁거리가 되므로, 지난주에 기각된 접근 방식이 다음 주에 다시 나타납니다. 핸드오프 과정에서 정확도가 떨어져, 기술적으로는 올바르지만 두 단계 전에 설정된 제약 조건을 위반하는 결과물이 나오기도 합니다. 그리고 지식이 누적되지 않습니다. 열 번째 실행도 첫 번째 실행보다 더 나은 정보를 갖지 못합니다.

시작 프롬프트에 모든 정보 채워 넣기

표준적인 해결책은 아키텍처, 컨벤션, 제약 조건, 이전 결정 사항 등 모든 것을 시작 지침에 미리 채워 넣는 것입니다. 이 방법은 작동하며 실제로 대부분의 사람들이 사용하는 방식입니다. 하지만 수동적이고, 다루기 힘들어지며, 각 에이전트에게 필요하든 그렇지 않든 매 실행마다 토큰 비용이 발생하고, 사용자가 포함하는 것을 기억해 낸 내용만 담을 수 있습니다.

하나의 긴 실행 유지하기

단일 실행 내에 머무르면 컨텍스트가 보존됩니다. 하지만 컨텍스트 창이 가득 차서 압축(compaction)이 시작되면 가장 초기 세부 정보(보통 요구 사항)부터 누락되기 시작합니다. 또한 실행이 길어지면 실패 비용이 커집니다. 단 한 번의 잘못된 단계가 누적된 많은 상태를 망칠 수 있습니다.

수동으로 작성한 핸드오프 노트 및 파일

실행 사이에 디스크에 상태 노트(수행된 작업, 결정된 사항, 다음 단계)를 기록하는 것은 현실적이고 합리적인 임시 해결책입니다. 하지만 이 역시 완전히 수동이며, 바쁜 상황에서는 생략하기 쉽고, 다음 실행에서 쿼리하기보다는 다시 읽고 재해석해야 하는 텍스트를 생성할 뿐입니다.

공통적인 장벽: 이러한 방법 중 어느 것도 에이전트에게 실행 경계를 넘어서 유지되거나 에이전트 간에 공유되는 쿼리 가능한 메모리를 제공하지 못합니다. 이는 OpenClaw가 에이전트 상태를 잊어버리는 이유 및 작업 컨텍스트를 잊어버리는 이유와 동일한 근본적인 공백입니다.

지속 가능한 구성은 모든 에이전트가 읽을 수 있고 에이전트의 수명보다 오래 유지되는, 실행 외부의 메모리 레이어입니다. MemoryLake는 프로젝트 지식, 결정 사항, 제약 조건을 한 번만 저장하면 검색 가능하고, 두 소스가 충돌할 때 감지할 수 있는 Git 스타일의 버전 관리를 제공하며, 종단간 암호화되어 내부 데이터의 보안을 유지합니다. 이는 그동안 멀티 에이전트 작업에서 결여되었던 공유 기반이 됩니다.

1단계: API 키 생성

MemoryLake에 로그인하고 키를 생성한 후 첫 번째 요청을 보내세요. 약 30초 정도 소요됩니다.

2단계: 첫 번째 메모리 업로드

실행 시마다 계속 재탐색하게 되는 아키텍처 및 시스템 문서, 상시 제약 조건, 결정 기록, 런북 등을 업로드하세요. 문서, 이미지 및 기타 파일 모두 지원됩니다. 그런 다음 각 실행의 결론을 한 줄 메모리로 캡처하여 진행 상황이 초기화되지 않고 누적되도록 하세요.

3단계: AI 및 에이전트 연결

API 키를 사용하여 Hermes를 연결하세요. MemoryLake는 Hermes Agent를 전용 통합 기능으로 지원하므로, 에이전트는 시작할 때 붙여넣은 정보에 의존하는 대신 실행 중에 공유 컨텍스트를 검색할 수 있습니다. 동일한 메모리를 MCP 또는 API를 통해 Claude, Codex, OpenClaw 및 기타 에이전트에서도 사용할 수 있으므로, 여러 도구에 걸친 워크플로우가 하나의 사실 소스(source of truth)를 바탕으로 작동합니다.

N배로 늘어나는 비용

단일 에이전트가 컨텍스트를 재구축하는 것도 비용이지만, 5개의 에이전트가 병렬로 각각 재구축하는 것은 5배의 비용이 듭니다. 이는 동일한 재탐색에 소비되는 토큰과 실제 시간(wall-clock time)일 뿐만 아니라, 서로의 추론 과정을 볼 수 없어 두 에이전트가 상충되는 결정을 내릴 때 발생하는 정량화하기 어려운 비용까지 더해집니다.

재도출 대신 검색 활용하기

공유 레이어를 사용하면 각 에이전트는 해당 단계에 정확히 필요한 제약 조건이나 결정 사항을 가져오고, 핸드오프는 손실이 많은 요약본 대신 공유 메모리에 대한 포인터를 전달합니다. 실행은 충분한 정보를 바탕으로 시작되고, 에이전트는 조사를 중복해서 수행하지 않으며, 충돌은 배포되기 전에 감지됩니다. MemoryLake의 Token Saving Calculator를 통해 사용량에 따른 토큰 절약 효과를 예측해 볼 수 있습니다.

매 실행이 끝날 때 결론 기록하기

실행당 날짜가 기재된 한 줄(수행된 작업, 결정된 사항, 실패 원인 등)을 기록하는 것이 고립된 실행을 누적된 진행 상황으로 전환하는 방법입니다. 이는 다음 실행에서 쿼리할 수 있는 형태의 자동화된 핸드오프 노트입니다.

제약 조건을 프롬프트에만 넣지 말고 검색 가능하게 만들기

시작 프롬프트에만 존재하는 제약 조건은 한 번의 압축(compaction)만으로도 무시될 수 있습니다. 검색 가능한 메모리에 있으면 어떤 단계의 어떤 에이전트든 이를 확인할 수 있습니다.

워크플로우별 스코프 지정

워크플로우나 프로젝트당 하나의 메모리 스코프를 유지하면 검색의 정확도가 높아지고, 한 파이프라인의 제약 조건이 다른 파이프라인의 에이전트에 영향을 미치는 것을 방지할 수 있습니다.

Hermes는 에이전트 조율을 잘 수행하지만, 스스로 기억하는 능력은 부족합니다. 각 실행은 프롬프트에서 시작하고, 각 에이전트는 자체 창만 보며, 학습된 모든 것은 실행이 끝나면 사라집니다. 이 때문에 멀티 에이전트 작업은 지식을 누적하지 못하고 계속 재탐색을 반복하게 됩니다. 시스템에 공유 영구 메모리를 제공하면 상황이 반전됩니다. 에이전트들은 공통된 사실을 통해 조율하고, 핸드오프 과정에서 추론이 유실되지 않으며, 열 번째 실행은 아홉 번의 실행 동안 누적된 지식을 바탕으로 시작됩니다. 이제 에이전트를 빈 방으로 다시 내몰지 마세요.