11/11 사례만으로는 부족할 때: FalkorDB를 이용한 발생 조사관 구축

열한 명의 사람이 아팠습니다. 모든 11개 사례에서 두 가지 재료가 나타났고, 두 공급업체가 동률을 이루었습니다.

사례 건수는 검색 범위를 좁혔지만, 어떤 로트(lot)가 책임자인지는 알려주지 못했습니다. 이 동률을 깨기 위해서는 노출 건수와 독립적인 증거가 필요했고, 조사관이 결론에 도달하는 과정을 정확히 보여줄 방법이 필요했습니다.

이것이 FalkorDB 트랙의 Graph Hacks 2026 프로젝트인 BatchZero의 배경이었습니다.

발생과 포트 메리디안은 가상의 장소입니다. BatchZero는 조사 워크플로우를 시연하기 위해 합성 데이터를 사용하며, 실제 공중 보건 시스템이 아닙니다.

발생을 그래프로 표현해야 하는 이유?

조사는 관계를 따라갑니다:

사람(Person) → 사례(Case) → 노출(Exposure) → 메뉴 항목(Menu item) → 재료(Ingredient) → 로트(Lot) → 공급업체(Supplier) → 선적(Shipment)

질문은 단순히 “이 사례들이 공통적으로 무엇을 가지고 있었는가?”에 그치지 않습니다. 또한 “어떤 시설이 그 재료를 제공했는가? 어떤 로트를 받았는가? 그 로트들은 어디로 이동했는가? 우리가 결국 식별하게 될 출처를 뒷받침하는 증거는 무엇인가?”라는 질문도 포함합니다.

그래프는 이러한 연결된 경로를 직접 추적할 수 있게 해줍니다. BatchZero에서는 사례 및 공급망 데이터가 가설(hypotheses), 증거(evidence), 에이전트 세션(agent sessions), 도구 호출 기록(tool-call records)과 함께 FalkorDB에 저장됩니다.

예를 들어, 공통 재료 쿼리는 사례에서 사람을 거쳐 노출 이벤트로, 메뉴 항목 및 재료까지 순회합니다:

MATCH (c:Case)<-[:HAS_CASE]-(p:Person)-[:PARTICIPATED]->(e:ExposureEvent)
      -[:INVOLVES]->(m:MenuItem)-[:CONTAINS]->(i:Ingredient)
WHERE c.case_id IN $case_ids
...

이 순회는 공통 노출 그림을 제공합니다. 하지만 어떤 재료가 발생의 원인인지 증명하지는 못합니다.

동률을 깨뜨릴 수 없는 끈

다음 단계는 독립적인 증거를 찾는 것이었습니다. BatchZero 모델은 분리된(isolates) 유전체 매치(genomic matches)를 그래프 노드와 관계로 격리합니다. 환자 분리균은 배치(lot) MG-4417과 관련된 환경 분리균과 최대 2개의 SNP에서 일치했습니다. 경쟁하는 상추 배치인 LET-2210에서는 시나리오 내에 일치하는 분리균이 없었습니다.

이 증거는 조사 방향을 바꿨습니다: MG-4417이 주요 출처 가설이 되었고, 경쟁 가설은 기각되었습니다. 데모의 중요한 부분은 단순히 답 자체가 아니라, 증거에서 답으로 이어지는 과정입니다.

그럴듯한 기록이라도 틀릴 수 있다

저희는 시간적 함정(temporal trap)도 포함했습니다. 한 노출 기록이 환자의 증상 발현일 이후로 날짜가 지정되어 있었습니다. 만약 에이전트가 검색된 모든 기록을 유효하다고 취급한다면, 그 식사는 오해를 불러일으키는 단서가 될 수 있습니다.

BatchZero는 노출 날짜를 환자 발생 시점과 병원체의 잠복기(incubation window)와 비교합니다. 창밖의(out-of-window) 기록은 출처에 대한 증거로 사용되는 대신, 유효한 노출 세트에서 제외됩니다.

이것이 저희가 탐구하고자 했던 차이점입니다: 검색은 기록을 찾을 수 있지만, 조사는 그 기록이 말이 되는지 결정해야 합니다.

서로 다른 책임감을 가진 네 개의 에이전트

BatchZero는 워크플로우를 네 가지 역할로 모델링합니다:

1. 접수 담당관 (Intake Officer): 초기 사례 파일을 작성합니다.
2. 클러스터 분석가 (Cluster Analyst): 사례들을 비교하고 후보 가설을 개발합니다.
3. 공급망 추적자 (Supply Chain Tracer): 재료, 배치, 공급업체 및 선적품을 추적합니다.
4. 브리핑 담당관 (Briefing Officer): 발견 사항과 대응 조치를 준비합니다.

각 역할은 자체 도구 세트를 가진 별도의 MCP 서버 서브 프로세스를 사용합니다. 이러한 기능들은 순서를 강제하는 데 도움이 됩니다: 예를 들어, 클러스터 분석가는 해당 행동이 자신의 도구 표면(tool surface)에 노출되지 않으면 리콜 초안을 작성할 수 없습니다.

저희는 MCP를 사용하여 사용 가능한 행동들이 프롬프트의 지침에만 의존하기보다 런타임 설정의 일부가 되도록 했습니다.

결론은 증거를 추적할 수 있을 때 검토하기가 훨씬 쉽습니다. BatchZero는 도구 호출(tool call)과 세션 기록을 그래프에 저장하며, 증거는 이를 생성한 도구 호출로 역추적됩니다.

이는 다음과 같은 경로를 만듭니다:

가설 → 증거 → 도구 호출 → 세션

이 그래프는 또한 조사 가설과 추출된 사실을 포함하여 에이전트 메모리(agent memory)도 저장합니다. 즉, 시스템은 발생 상황 자체와 이를 조사하는 동안 구축된 추론 과정 모두를 표현할 수 있습니다.

데모 재현 가능하게 만들기

실시간 데모는 일반적인 이유로 실패할 수 있습니다: 누락된 API 키, 네트워크 문제, 또는 모델 사용량 제한(rate limit) 등이 그 예입니다. BatchZero는 에이전트 인터페이스를 교체 가능하도록 유지합니다. Groq API 키가 있으면 Groq가 도구 루프(tool loop)를 구동할 수 있고, 그렇지 않으면 결정론적 리플레이(deterministic replay)가 FalkorDB를 대상으로 동일한 워크플로우를 따릅니다.

저장소에는 리플레이를 세 번 실행하는 벤치마크 명령어(benchmark command)가 문서화되어 있습니다:

python -m batchzero.demo.replay --benchmark 3

이 프로젝트는 세 번의 모든 벤치마크 실행에서 정확한 출처 식별을 보고합니다. 데모와 구현은 BatchZero 저장소에서 이용 가능하며, 워크스루 비디오에서는 UI에서 진행되는 조사를 보여줍니다.

우리가 배운 것들

몇 가지 교훈이 눈에 띄었습니다:

• 결정을 유도하는 관계를 모델링합니다. 그래프의 유용한 부분은 다이어그램상의 모양이 아니라, 조사 과정의 일부로 노출(exposure), 공급(supply), 그리고 유전체학적(genomic) 관계들을 순회할 수 있는 능력 자체였습니다.
• 카운트를 시작점으로 취급합니다. 공유된 노출(Shared exposure)은 후보군을 좁혔지만, 결정을 내리기 위해서는 독립적인 증거가 필요했습니다.
• 추론하기 전에 기록을 검증합니다. 기록이 존재하더라도 관련 시간 범위 밖에 있을 수 있습니다.
• 출처(provenance)를 결론에 가깝게 유지합니다. 증거를 생성한 도구 호출(tool call)과 연결하면 결과를 더 쉽게 재구성할 수 있습니다.
• 능력(capabilities)을 사용하여 프로세스를 강화합니다. 역할 범위가 지정된 도구(Role-scoped tools)는 에이전트가 해당 단계에서 일부 유효하지 않은 행동을 할 수 없게 만듭니다.

이 합성 시나리오의 출처는 로트(lot) MG-4417이었습니다. 이 그래프는 어떤 가설이 승리했는지뿐만 아니라, 그것을 뒷받침하는 증거와 조사 과정이 어떻게 그곳에 도달했는지 설명하는 데 도움을 주었습니다.

만약 결정이 여러 연결된 개체(entities)를 거쳐 증거를 따르는 것에 의존하는 시스템을 구축하고 있다면, 어떤 표현 방식과 감사 추적(audit trails)이 효과가 있었는지 듣고 싶습니다.