AI 에이전트를 위한 멀티버스 구축: 모든 행동을 수백 개의 그래프 복사본에서 리허설합니다

AI 에이전트들이 실제 시스템에서 행동하기 시작했습니다. 데이터베이스를 정리하고, 키를 회전시키고, cron job을 이동시키고, 서비스를 확장합니다. 그 행동 자체는 위험한 경우가 거의 없습니다. 위험한 것은 변경되는 대상에 조용히 의존하는 모든 것입니다.

그래서 Graph Hacks (WeMakeDevs × FalkorDB)를 위해 저는 Multiverse를 구축했습니다: 에이전트가 어떤 행동을 하기 전에, 회사 수백 개의 복사본에서 그 행동을 리허설하고, 무엇인가 중요한 것이 얼마나 자주 깨지는지 계산하며, 답이 명확하게 안전할 때만 통과시킵니다.

• 🎬 데모 비디오: 아래
• 🔗 라이브 데모: https://multiverse-cqzs.onrender.com (무료 서버라 첫 방문 시 깨어나는 데 몇 분이 걸릴 수 있습니다)
• 💻 코드: https://github.com/TarunMhanta30/multiverse

문제점: "아무도 이 테이블을 사용하지 않습니다"

이 프로젝트 전체가 구축된 시나리오입니다.

클린업 에이전트가 orders_archive를 살펴봅니다. 어떤 서비스도 여기에 의존한다고 선언하지 않았습니다. 설정 파일에도 언급되지 않습니다. 모든 정적 검사에 따르면 삭제해도 안전합니다.

하지만 접근 로그는 카탈로그가 모르는 것을 알고 있습니다: tax_filing_job이 지난 5회 중 4회 동안 아카이브를 읽었습니다. 이것을 삭제하면 다음 분기 세금 신고 작업이 깨집니다.

실제 기업들은 이런 연결고리로 가득 차 있습니다. 어떤 것은 확실합니다 (Kubernetes 배포가 다른 서비스의 주소로 구성됩니다). 많은 것은 단지 아마도 실제인 경우입니다: 예전에 테이블을 읽었던 작업, 여전히 비밀(secret)을 사용할 수도 있는 오래된 런북 스크립트. '예/아니오' 의존성 검사는

Multiverse는 회사를 FalkorDB 내의 그래프로 취급하며, 불확실한 연결(link)은 알려진 편향을 가진 동전으로 간주합니다.

계획을 리허설하려면:

1. GRAPH.COPY를 사용하여 회사 그래프를 스냅샷합니다.
2. 각 미래에 대해 스냅샷의 새 복사본을 만듭니다.
3. 그 복사본에서 모든 불확실한 연결(link)에 대해 주사위를 굴립니다: 이 미래에서는 그것이 실제인가? 해당 기간 동안 수동으로 실행된 작업(hand-run job)이 사용되었는가?
4. 변경 사항을 적용하고, Cypher를 사용하여 한 번에 한 단계씩 실패가 퍼져나가도록 합니다.
5. 무엇이 고장 났는지 읽어본 후, 복사본을 삭제합니다.

각 미래는 화면의 하나의 사각형이 됩니다. 주황색은 비즈니스적으로 중요한 무언가가 고장 났음을 의미합니다. 충분한 미래를 거치면, Multiverse는 중요 요소가 고장 날 확률을 알게 되며, 이 확률이 5% 이상이면 해당 계획은 **차단(blocked)**됩니다.

의견이 아닌 증거로부터 그래프 구축하기

데모에 사용된 회사는 **Boutique Inc.**이며, 이 회사의 12개 서비스와 Redis는 Google의 실제 Online Boutique Kubernetes 매니페스트에서 수정 없이 가져온 것입니다. 모든 *_SERVICE_ADDR 환경 변수는 CALLS 간선(edge)이 됩니다. 백 오피스(청구, 세금 및 분석 작업, 데이터베이스, 비밀 정보, 소유자 및 13개월 액세스 로그)는 합성(synthetic)이며, 앱 전체에서 합성으로 표시됩니다.

제가 스스로 지킨 규칙은 다음과 같습니다: 수동으로 신뢰도 수치를 입력하지 않는다. 모든 연결에는 증거로부터 계산된 rule과 confidence가 부여됩니다:

작업을 수행하는 Cypher

각 미래(future)의 핵심은 그 미래 자체의 복사본 안에서 실행되는 단계별 파동입니다:

UNWIND $frontier AS f
MATCH (x:Asset)-[r:CALLS|READS|WRITES|USES_SECRET|DEPENDS_ON|FED_BY]->(y:Asset {name: f})
WHERE NOT r.key IN $inactive
...

파동이 일어나기 전에, 주사위가 이 미래에서 '아니다'라고 말한 링크들은 단순히 복사본에서 삭제됩니다:

MATCH ()-[r]->() WHERE r.key IN $keys DELETE r

하드 링크(hard links)는 의존하는 자산(dependent asset)을 끊고, 소프트 링크(soft links)는 그것을 저하시키며, 데이터 피드(data feeds)는 오래됩니다. 이 상태들은 복사본에 다시 기록되고, 읽혀지며, 그 복사본은 폐기됩니다.

런칭 데이(Launch day)는 같은 그래프를 다르게 사용합니다. 모든 서비스의 부하는 전면 문에서의 트래픽을 모든 경로를 따라 곱한 것이 되는데, 이는 단일 쿼리(single query)로 나타납니다:

MATCH p = (e:Asset {name: $entry})-[:CALLS|READS|WRITES*0..8]->(y:Asset)
WHERE all(r IN relationships(p) WHERE r.calls_per_request IS NOT NULL)
RETURN y.name, sum(reduce(f = 1.0, r IN relationships(p) | f * r.calls_per_request))

여기에 용량을 나누면 각 서비스의 한계점, 예를 들어

고정된 1,000개의 미래(futures)를 실행하는 것은 느리고 무의미합니다. Multiverse는 한 번에 25개의 미래를 추가하고 각 배치 후에 95% Wilson 구간을 계산합니다. 전체 구간이 5% 안전선 위 또는 아래로 명확해지는 즉시 중단됩니다. 명확한 블록(BLOCK)은 보통 25개에서 50개의 미래가 필요합니다.

만약 불확실한 것이 계획의 효과에 도달할 수 없다면, 모든 미래는 동일할 것이므로 정확히 하나를 실행하고 그렇게 알려줍니다. '정확하다(Exact)'는 지름길이 아니라 실제 답변입니다.

리플레이: 블랙박스 없음

모든 미래는 재현 가능합니다. 같은 계획과 같은 리플레이 코드는 동일한 순서로 동일한 주사위를 굴립니다. 아무 스퀘어에서나 **리플레이(Replay)**를 누르면 새로운 복사본에서 다시 실행되며, 모든 FalkorDB 명령어는 실행되는 대로 표시되고 실패가 실제 쿼리 결과와 함께 그래프 전체에 퍼집니다.

메모리: 한 번 질문하고, 다시 추측하지 않기

판결이 불확실한 링크에 달려 있을 때, Multiverse는 해당 소유 팀에게 질문합니다. 여기서는 Finance가

함께(Together), 청구는 다운된 데이터베이스를 대상으로 02:00에 실행되고 지급 결제(payouts)가 중단됩니다.

Multiverse 내의 에이전트들은 행동을 취하는 대신 계획을 제안합니다. 각 제안은 단독으로 리허설될 뿐만 아니라, 시간과 그래프에서 겹치는 모든 다른 활성 계획들과 함께 리허설됩니다. 두 번째 계획이 보류되고, Multiverse는 가장 빠른 안전한 슬롯을 찾습니다.

168개의 시간별 시작 시간을 순진하게(naively) 확인하는 것은 168번의 리허설을 의미합니다. 하지만 동일한 실행 작업과 겹치는 계획들을 보는 시작 시간들은 동일한 미래를 생성하므로, Multiverse는 이들을 그룹화하고 각 그룹을 한 번만 리허설합니다: 168개의 시작 시간, 3번의 리허설.

질문할 수 있는 기업의 두뇌(company brain)

동일한 그래프는 FalkorDB에 내장된 알고리즘을 사용하여 회사 자체에 대한 질문에도 답합니다:

• algo.betweenness는 병목 지점(chokepoints)을 찾습니다 (대부분의 의존성 경로가 거치는 checkoutservice).
• algo.pageRank는 모든 것이 궁극적으로 의존하는 자산인 **기초(foundations)**를 찾습니다.
• algo.WCC는 다른 어떤 것과도 연결되지 않은 그룹, 즉 **섬(islands)**을 찾아내고, 이는 정리 도우미(cleanup finder)에 공급되어 각 후보를 실제 리허설로 증명합니다.
• shortestPath는 한 자산이 다른 자산에 의존하는 이유를 설명합니다.
• 전체 텍스트 인덱스(full-text index)가 Ctrl K 검색을 구동합니다.

Multiverse는 13개의 MCP 도구(rehearse, propose_plan, execute_approved_plan, find_safe_window, evidence, recall 등)를 노출합니다. Claude Desktop 또는 모든 MCP 클라이언트는 이 도구들을 사용할 수 있으므로, 실제 AI 에이전트는 행동하기 전에 리허설을 거칩니다. 모든 도구 호출은 메모리 그래프(memory graph)에 기록되며, 웹 콘솔에서 에이전트 활동을 실시간으로 보여주는 방식도 바로 이것입니다: 메모리 그래프는 콘솔, MCP 서버, 명령줄 사이의 공유 버스 역할을 합니다.

FalkorDB를 통해 배운 점

• GRAPH.COPY가 핵심 트릭입니다. 모든 미래에 회사의 완전하고 쓰기 가능한 사본을 제공함으로써 엔진이 단순해졌습니다. 미래는 단순히 "복사(copy), 일부 엣지 삭제, 파급(ripple), 읽기(read), 제거(drop)"의 과정일 뿐입니다. 되돌리기 로직도 없고, 실제 그래프에 위험을 주지도 않습니다. 모든 리허설 전후에 지문 인식 확인(fingerprint check)을 하는 것이 실제 회사가 손상되지 않았음을 증명합니다.
• 사본은 순차적입니다. FalkorDB는 복사를 위해 포크(forks)를 생성하므로, 미래들이 하나씩 실행됩니다. 제 노트북에서는 각각 약 0.1초가 소요되며, 이 중 대부분이 사본을 만드는 과정 자체에 사용됩니다. 이것이 바로 적응형 정지(adaptive stopping)와 "정확한(exact)" 모드가 매우 중요했던 이유입니다.
• 그래프 두 개가 하나보다 낫습니다. 회사(증거로부터 재구축 가능)를 메모리(영구적)와 분리함으로써 리셋이 안전해졌고, "세션 간 기억"이라는 개념을 문자 그대로 실현할 수 있었습니다.
• 읽기 전용 쿼리는 안전 기능입니다. GRAPH.RO_QUERY 덕분에 LLM이 작성한 Cypher를 실행하는 것이 합리적이었습니다.

증명

자체 테스트(python selftest.py)는 자체 그래프에 대해 17가지 검사를 수행합니다. 예를 들면:

• 300개의 미래가 증거가 예측하는 값의 표준 오차(standard errors) 3 이내에 위치함
• 재생된 12개의 미래가 기록과 정확히 일치함
• 엣지 하나를 추가하면 답이 바뀌므로, 아무것도 사전 계산되지 않음
• 종속성(dependency)을 수정하면 BLOCK 상태가 SAFE로 바뀜
• 각각 안전한 두 개의 계획은 함께 블록 처리됨
• 모든 리허설은 실제 그래프를 변경하지 않고 모든 사본을 삭제함

솔직한 한계점

• 백 오피스는 합성(synthetic)입니다. 온라인 부티크 부분만 실제입니다.
• 리플(ripple)은 재시도(retries), 시간 초과(timeouts) 또는 'A이거나 B이면 충분하다'와 같은 중복성(redundancy)이 아닌, 하드 의존성(hard), 소프트 의존성(soft), 그리고 오래된(stale) 의존성을 모델링합니다.
• '그래프에 질문하기(Ask the graph)'의 품질은 모델이 작성하는 Cypher만큼만 좋으므로, 항상 Cypher가 표시됩니다.

사용해보기