나는 명령어 하나를 실행하여 Hivemind를 나의 실제 Claude Code 이력에 연결했고, 약 2분 후 Hivemind는 내가 실제로 어떻게 일하는지를 설명하는 19개의 재사용 가능한 기술(skills)을 작성해냈다. 그러고 나서 Hivemind는 한 가지 기술의 작성을 거부했는데, 그 이유는 내 저장소(repository)에 이미 해당 패턴이 문서화되어 있었기 때문이다.

그 거부의 순간이 바로 이 도구가 나의 주의를 끄는 순간이었다. 대부분의 "AI 메모리 (AI memory)" 제품들은 모든 것을 쌓아두고 그것을 기능이라고 부른다. 하지만 이 제품은 판단(judgment call)을 내렸다. 나는 하루를 투자하여 Hivemind를 나의 실제 운영 중인 Claude Code 설정에 연결하고, 이를 망가뜨려 보기도 하고, 소스 코드를 통해 실제 버그를 추적하며, 이것이 실제로 무엇을 하는지 측정했다. 다음에 이어지는 내용은 솔직한 버전이다: 얻은 것(wins), 그리고 비용이 발생하는 부분들.

Hivemind는 Activeloop의 코딩 에이전트(coding agents)를 위한 지속 학습(continual-learning) 레이어이다. 이 도구는 에이전트 세션을 트레이스(traces)로 캡처하고, 반복되는 패턴을 추출하여 SKILL.md 파일로 만들며, 해당 기술과 회상된 메모리(recalled memory)를 팀 내의 모든 에이전트에게 다시 제공한다. Claude Code, Cursor, Codex 및 기타 몇몇 도구들이 이에 해당한다. 핵심 제안은 간단하다: 오늘 아침 주니어 직원이 사용한 에이전트가 지난주 시니어 직원의 에이전트가 알아낸 내용 덕분에 더 똑똑해졌다는 것이다.

명령어 한 줄 설치, 그리고 README에서 생략된 두 가지 사항

설정은 정말로 명령어 하나를 실행한 뒤 브라우저 로그인을 하는 것이 전부다.

npm i -g @deeplake/hivemind
hivemind install --only claude
hivemind login

README에서 광고하지 않는 두 가지 사항이 있습니다. 첫째, 이 도구는 Node 22 버전을 요구하는데, 저는 20.19.5 버전을 사용 중이었습니다. 엔진 경고(engine warning)가 떴음에도 불구하고 설치 및 실행은 되었지만, 이는 지원되지 않는 조합이므로 이를 기반으로 구축하기 전에 반드시 알아두어야 합니다. 둘째, 첫 번째 쓰기 작업 시 메모리 테이블(memory table)이 아직 존재하지 않았고, create-table 호출이 pg_type_typname_nsp_index에서 중복 키 경합(duplicate-key race)을 일으켰습니다. 하지만 몇 초 내에 재시도하여 스스로 복구(self-healed)되었고, 클라우드에 capture ok를 기록했습니다. 데이터 손실은 없었지만, 스스로 복구되는 콜드 스타트(cold start) 현상은 주목할 만한 부분입니다.

2분 만에 내 세션에서 추출한 19가지 기술

이 부분이 바로 제품을 판매하는 핵심 요소입니다. 저는 제 Claude Code 이력을 대상으로 마이너(miner)를 실행했고, 그 결과 각각의 프론트매터(frontmatter)에 실제 출처(provenance)를 가지고 있으며 서로를 상호 참조하는 19개의 명명된 기술(skills)이 생성되었습니다.

name: detached-remote-ml-jobs
source_sessions:
- e2f3cd85-54b8-45bf-87e4-9952f50eb6ac
...

이것들은 단순한 껍데기(stubs)가 아니었습니다. staged-ablation-cost-optimization은 제가 GPU 예산을 투입하기 전에 저렴한 실행을 테스트하는 방식을 포착했습니다. debug-silent-container-failures는 작업 상태가 '성공(green)'으로 표시되더라도 이를 불신하고 실제 컨테이너 로그를 읽는 저의 정확한 습관을 포착했습니다. detached-remote-ml-jobs는 심지어 이름으로 idempotent-ml-pipeline-stages와 연결되어 있었습니다. 이 도구는 제가 일하는 방식을 읽어내고, 제가 직접 작성하는 것보다 더 명확하게 기록해 주었습니다.

나를 감명시킨 부분: 내 문서가 이미 다루고 있는 내용은 학습을 거부했다

저는 봇을 제 텔레그램(Telegram) 알림 체계에 연결했던 세션들을 추출해 달라고 요청했습니다. 결과는 후보가 0개였으며, 도구는 그 이유를 제게 알려주었습니다.

[96ba8816] 0개의 기술 후보(skill candidate) ... bot-tg-fabric 배선 워크플로우(wiring workflow)
는 이미 CLAUDE.md에 문서화되어 있으며 대부분 저장소(repo)에 특화되어 있음. 반복 가능한 실수 패턴(repeatable-mistake pattern)이 감지되지 않음.

그러한 절제야말로 핵심입니다. 모든 것을 부호화(codify)하는 메모리 계층은 헤쳐 나가야 할 노이즈가 되어버립니다. 이 게이트(gate)는 이미 기록되어 있지 않은, 명확하지 않으면서도 반복 가능한 실수(gotchas)만을 유지합니다. 문서화가 잘 된 저장소에서는 올바르게 거절하며, 이를 통해 당신의 기술 라이브러리는 신호(signal)로 밀도 있게 유지됩니다.

동일한 버그, 두 개의 에이전트: 하나는 기술이 있었고, 하나는 없었다

주장은 쉽기에, 저는 통제된 테스트를 수행했습니다. 동일한 프롬프트, 성공했다고 보고하지만 실제로는 아무것도 하지 않는 조용한 Azure 컨테이너 작업(container job)을 대상으로 했습니다. 한 대의 새로운 에이전트는 부호화된 debug-silent-container-failures 기술을 범위(scope) 내에 가지고 있었고, 다른 하나는 그렇지 않았습니다.

기술이 있는 에이전트는 이를 명명하고 정확한 근본 원인(root cause)을 먼저 제시했습니다: 예외(exception)를 삼켜버리고 종료 코드 0을 반환하는 try/except 블록 때문에 오케스트레이터(orchestrator)가 성공으로 보고한다는 것이었습니다. 기술이 없는 에이전트는 일반적인 디버깅 체크리스트를 제공하고 가장 먼저 Log Analytics 배선(wiring)을 시도했으며, 근본 원인을 전혀 드러내지 못했습니다. 제 과거 세션에서 추출된 기술이 새로운 에이전트를 동일한 문제에 대해 측정 가능한 수준으로 더 똑똑하게 만들었습니다. 이것이 바로 작동하고 있는 전파(propagation)의 약속입니다.

내 기기에서 회상(Recall) 기능이 작동하지 않아, 추적하여 수정했다

기본 설정 상태에서 메모리 회상(memory recall)은 저에게 아무런 도움이 되지 않았습니다. 세션 요약(session summaries)의 모든 백필(backfill)이 실패하여 회상할 내용이 없었고, 모든 회상 이벤트는 hit=none으로 기록되었습니다. 이것은 홍보성 기사들이 건너뛰는 종류의 문제입니다. 저는 대신 번들 소스(bundle source)를 직접 파고들었습니다.

wiki-summary 워커(worker)는 각 세션을 요약하기 위해 Haiku를 사용하여 cla -p를 셸 실행(shell out)하며, 4개의 동시성(concurrency)과 세션당 120초의 고정된 타임아웃(timeout)을 가집니다. 제 컴퓨터에는 5MB에서 18MB에 이르는 세션 트랜스크립트(transcripts)가 있습니다. 작은 세션에 대한 Haiku 요약조차 단독으로 약 91초가 걸렸기 때문에, 18MB 트랜스크립트가 포함된 배치(batch)를 4개 병렬로 실행하면 모든 작업이 120초를 초과하게 되어 프로세스가 종료(killed)됩니다. 파이프라인이 고장 난 것이 아니었습니다. 자원이 고갈(starved)된 것이었습니다.

저는 제가 중요하게 생각하는 세션들의 요약을 배치 경로 외부에서 스테이징(staging)한 다음, 이를 클라우드 테이블(cloud table)로 플러싱(flushing)하는 방식으로 문제를 해결했습니다. 그 후, 회상(recall) 기능이 작동하기 시작했습니다.

{"event":"injected","mode":"semantic","score":0.68}

실제 관련성 점수(relevance score)와 함께 컨텍스트(context)에 주입된 시맨틱 회상(Semantic recall)입니다. 임베딩(embeddings) 데몬(daemon)이 필요할 때마다 생성되었고, 제대로 작동했습니다.

회상이 이득을 주는 지점과 조용히 비용을 발생시키는 지점

이것은 매우 중요하기 때문에 솔직하게 나누어 설명하겠습니다. 저는 캐시 제어(cache-controlled) A/B 테스트를 수행했습니다. 동일한 작업에 대해 메모리를 켰을 때와 껐을 때를 비교했으며, 캐싱이 속일 수 없는 지표로서 턴(turns) 수를 측정했습니다.

짧고 문서화가 잘 된 코딩 작업에서는 선제적 회상(proactive recall)이 상황을 악화시켰습니다. 평균적으로 약 75% 더 많은 턴과 23% 더 많은 비용이 발생했습니다. 저는 세 가지 와이어링(wiring) 작업을 수행했습니다. 메모리를 껐을 때는 각각 4턴이 걸렸습니다. 메모리를 켰을 때는, 하나는 실제로 3턴으로 개선되었지만, 하나는 7턴으로 늘어났고, 다른 하나는 에이전트(agent)가 맞지 않는 주입된 패턴(injected pattern)을 강제로 적용하려 시도하면서 11턴까지 불어났습니다. 이는 평균 4턴이 7턴으로 늘어난 것입니다. 에이전트가 주변적으로 관련된 메모리를 끌어들여 탐색(exploring)을 하게 만든 것입니다. 이는 회상 기능에 적합하지 않은 워크로드(workload)이며, 해결책은 관련성 임계값(relevance threshold)을 높이거나 짧은 요청에 대해서는 선제적 회상을 끄는 것입니다.

설계된 워크로드(workload) 내에서 Hivemind는 탁월한 성능을 발휘합니다. 저는 로컬 파일이 전혀 없는 상태의 새로운 에이전트에게, 이전 세션에서 제가 로그인 감지 버그를 어떻게 수정했는지 물었습니다. 에이전트는 정확한 verify_login 로직, 세션 ID, 그리고 커밋(commit)을 메모리에서 즉시 추출해냈습니다. 이것이 진정한 교차 세션 회상(cross-session recall)이며, 다른 방법으로는 얻을 수 없는 기능입니다. 문서가 이미 답을 제공하는 작업이 아니라, 메모리 집약적인 작업에 사용하십시오.

아무도 마케팅하지 않는 숨겨진 기능: 라이브 코드 그래프 (Live Code Graph)

Hivemind는 동일한 트레이스(traces)를 통해 저장소의 AST 그래프(AST graph)도 구축합니다. 제가 가진 모노레포(monorepo)의 경우, 237개 파일에 걸쳐 2449개의 노드(nodes)와 4333개의 엣지(edges)로 구성되었으며, 파일 시스템처럼 쿼리(query)가 가능했습니다. 이 그래프는 제가 의도적으로 사용한 벤더 복사(vendored-copy) 패턴, 즉 동일한 알림 클라이언트의 9개 복사본을 정확히 찾아냈으며, 호출(call) 및 임포트(import) 엣지를 줄 번호와 함께 매핑했습니다. 파일을 열기 전에 중요한 파일을 찾기 위한 빠른 인덱스(index)로서 진정으로 유용하며, 해결할 수 없는 부분에 대해서는 솔직하게 명시합니다.

활성화하기 전에 주의할 점

가장 큰 주의 사항은 개인정보 보호(privacy)입니다. 캡처(Capture)는 현재 작업 중인 프로젝트뿐만 아니라 조직 전체의 모든 프로젝트에 걸쳐 이루어집니다. 저의 공유 메모리(shared memory)에는 관련 없는 민감한 작업의 요약본들이 축적되었고, 이는 워크스페이스에 추가된 누구든 읽을 수 있으며 회상(recall) 기능을 통해 관련 없는 세션에서도 나타날 수 있습니다. 요약본 자체는 정확한 함수 로직과 커밋 SHA를 포함할 정도로 높은 충실도(high fidelity)를 가집니다. Hivemind가 이미지 태그와 같은 일부 비밀 정보(secrets)를 가려주기는 하지만, 클라우드 구독 및 워크스페이스 ID는 그대로 노출되었습니다. 프로젝트별로 워크스페이스를 사용하고, 팀원을 추가하기 전에 반드시 검토하십시오.

마치며

Hivemind는 하나의 이름 아래 두 개의 제품을 담고 있습니다. 실제 세션을 새로운 에이전트(Agent)를 입증 가능하게 날카롭게 다듬어주는 재사용 가능한 기술(Skills)로 변환하는 코드화 엔진(Codification engine)은 매우 뛰어나지만 마케팅이 부족한 상태입니다. 선제적 회상(Proactive recall) 기능은 메모리 집약적인 작업에서는 강력하지만, 문서화된 짧은 작업에서는 부담이 될 수 있으므로, 모든 곳에서 신뢰하는 기본 설정이 아니라 직접 조정해야 하는 설정으로 취급하십시오. 만약 팀 전체에서 코딩 에이전트(Coding agents)를 운영한다면, 기술 계층(Skill layer)만으로도 이번 주에 설치할 가치가 충분합니다. 다만 먼저 워크스페이스(Workspaces)의 범위를 지정하십시오. 그리고 상태 표시가 초록색이라고 해서 당신의 업무가 실제로 수행되었다는 뜻은 결코 아니라는 점을 기억하십시오.

리소스 및 참고 문헌 (Resources & References)

• GitHub의 Hivemind (activeloopai/hivemind)
• Hivemind 제품 페이지 (deeplake.ai)
• Deep Lake 문서 (Deep Lake documentation)
• LoCoMo 롱 컨텍스트 메모리 벤치마크 (LoCoMo long-context memory benchmark) (arXiv)
• Y Combinator Launch의 Hivemind

원문은 Medium에 게시되었습니다.