5개의 Hermes 프로필을 하나의 팀으로: 핵심은 메모리 경계 설정이었음

지난 몇 달간 Hermes를 가지고 놀면서, 단순히 멋진 CLI 어시스턴트로 사용하는 수준을 금방 넘어섰음. 내 목표는 내가 일일이 컨텍스트를 떠먹여 주지 않아도 장기 프로젝트에서 협업할 수 있는 로컬 에이전트의 전문 팀을 만드는 거였음.

내 설정: Mac Studio (M2, 64GB RAM)에서 Ollama 구동. 빠른 일상 작업용으로 DeepSeek V4를, 더 무거운 코딩/디버깅 작업용으로 70B급 추론 모델을 사용함.

이건 그냥 내 실수투성이 여정일 뿐이고, 다른 누군가의 삽질을 줄여주길 바랄 뿐임.

처음엔 아주 순진하게 Hermes의 내장 프로필을 사용해서 역할을 나눴음: 코더, 리서처, 라이터, 운영자. 각자 고유한 설정과 메모리를 가졌지. 처음엔 잘 작동했고 각 에이전트가 자기 일을 잘 해냈음. 하지만 일주일 뒤 벽에 부딪혔음: 에이전트들이 완전히 고립되어 있었음.

내 코더는 Docker 볼륨 권한 문제 하나 디버깅하는 데 한 시간을 썼음. 다음 날, 운영 에이전트가 뭔가를 배포하다가 똑같은 문제에 부딪혔는데 아무것도 모르는 상태였음. 처음부터 다시 시작하고, 똑같은 멍청한 질문을 하고, 똑같은 실패한 명령어를 반복했음. 이건 팀이 아니라, 서로 만난 적도 없는 기억상실증 걸린 프리랜서 집단이었음.

나는 이게 "공유가 부족해서" 그런 줄 알고, 모든 프로필의 MEMORY .md 파일을 서로에게 cat으로 들이붓는 엉망진창 배시 스크립트를 짰음. 그게 내 최악의 실수였음.

코더의 메모리는 스택 트레이스, 에러 로그, 실패한 명령어들로 가득 찬 쓰레기장이 됐음. 동기화 후 라이터에게 간단한 블로그 포스트 초안을 써달라고 했더니, 돌아온 결과물은 정신 나간 수준이었음: 문장 중간에 무작위 코드 스니펫이 들어가고, 로컬 파일 경로가 사방에 널려있고, 말투는 마치 커널 패닉이 온 것 같았음. 페르소나 전체가 오염된 거임.

2주 동안 머리를 쥐어뜯다가 깨달았음: 문제는 메모리를 공유할지 말지가 아니라, 무엇을 공유할지였음. 진짜 팀은 동료의 지저분한 초안이나 실패한 시도를 전부 읽지 않음. 그들은 원시적인 뇌 데이터가 아니라, 합의된 사실과 검증된 해결책을 공유함.

그 후, Hermes용 로컬 메모리 플러그인인 MemOS를 테스트해 봤음. 밝히자면, 난 이 프로젝트와 아무런 관련이 없고 그냥 써본 사용자일 뿐임. 나한테 딱 와닿았던 건 화려한 기능이 아니라 메모리 모델이었음: 프로젝트 수준의 사실을 위한 공개 메모리, 프로필별 비공개 메모리, 그리고 원시 데이터 동기화 대신 재사용 가능한 기술(skills).

나는 모든 근거(ground truths)를 공개 공간에 넣었음: "우리는 pnpm을 사용함", "운영 환경은 Hetzner에 있음", "게시물에 외부 링크 금지". 모든 에이전트가 이걸 읽을 수 있음. 하지만 디버그 로그, 실패한 시도, 글쓰기 취향 같은 지저분한 것들은 비공개로 남겨둠. 교차 오염이 하룻밤 사이에 멈췄음.

다른 좋은 점은 공유 기술임. 이제 코더가 Docker 문제를 해결하면, 플러그인이 최종 해결책을 재사용 가능한 기술로 추출함. 일주일 뒤 운영자가 같은 문제에 부딪히면, 그 기술을 불러와서 실행함. 더 이상 바퀴를 다시 발명할 필요가 없음.

이제 워크플로우가 내가 상상했던 대로 작동함. 리서처는 공개 메모리에 핵심 내용을 추가하고, 라이터는 자기 말투를 유지하면서 그 사실들을 바탕으로 문서를 작성함. 우리가 공유 지식을 쌓아가면서 시스템은 시간이 지날수록 더 좋아짐.

완벽하진 않고 아직 조정할 게 많음. 하지만 가장 큰 교훈은 이거임: 멀티 에이전트 설정에서 더 많은 컨텍스트를 들이붓는다고 이기는 게 아님. 무엇을 공유하고 무엇을 공유하지 않을지에 대해 명확한 경계를 긋는 것으로 이기는 거임.

혹시 같은 메모리 문제로 고생하고 있다면 직접 찾아보길 바람. 다른 방법이 안 통했다면 시도해 볼 가치가 있음.