검색 엔진을 구성하는 법

검색은 단순한 inverted index 조회가 아니라, 언어별 localization, 뉴스성 freshness 판단, knowledge graph와 product index의 동시 질의, 고객별 예외 경로까지 얹히며 금세 복잡한 20+ 노드 그래프로 변한다.

여기에 수천 개의 AI agent가 각자 다른 요구를 갖고 있고, 코드까지 agent가 작성하는 현실이 더해지면서 전역 제약과 요구사항을 일관되게 유지하기가 어려워진다. Exa는 이 문제를 해결하기 위해 검색 파이프라인 오케스트레이터 Canon을 만들었다.

Canon은 검색 경로를 DAG로 정의해 실행기(executor)가 병렬성을 자동으로 처리하게 만든다. 예시처럼 retrieve와 fetch_content를 노드로 분리해 두면, 실행기는 의존성을 보고 동시에 돌릴 수 있는 작업을 병렬화하고, 전체 요청을 하나의 그래프로 추적할 수 있다.

DAG가 제공하는 핵심 이점은 다음과 같다.

• Automatic Parallelism: 의존성이 없는 노드를 자동 병렬 실행해 지연 시간을 줄인다.
• Durable execution: 노드가 실패해도 그 지점부터 재시도할 수 있다.
• Introspectability: 그래프 자체가 데이터이므로 시각화, 검증, 분석이 쉽다.
• Definition / execution 분리: 같은 그래프를 테스트에서는 동기 실행, 프로덕션에서는 분산 실행, 프리뷰에서는 dry-run으로 돌릴 수 있다.

다만 DAG가 만능은 아니다. 이벤트 루프처럼 스케줄할 작업이 아니라 상태와 이벤트가 중심인 구조, 정확한 순서가 중요한 consensus protocol, 수렴할 때까지 반복하는 feedback loop에는 맞지 않는다.

Canon의 목표는 쿼리 전에 전체 검색 경로를 미리 보고, 실행 후에는 추적 가능하게 만드는 것이다. 이전처럼 순차 함수 호출과 if/else, 수동 에러 체크에 의존하면 reranker 교체나 fallback 확인, URL 누락 원인 분석이 매우 어려웠지만, Canon은 검색 경로를 serializable graph로 컴파일해 어떤 노드에서 URL이 떨어졌는지와 그 이유를 정확히 추적하게 해준다.

런타임은 pull-based로 동작해 downstream consumer가 값을 요구할 때만 upstream subtree를 실행한다. 이 구조 덕분에 laziness와 cancellation propagation이 자연스럽게 생기고, diamond dependency에서는 memoization으로 중복 계산을 막는다.

결국 Canon은 검색 파이프라인의 모든 invocation boundary에서 timing, inputs, outputs, decision을 기록하고, 에러에는 실패한 노드와 upstream context를 자동으로 덧붙인다. 노드가 직접 외부 네트워크 호출을 해버리면 이런 통제가 불가능해지므로, 모든 로직을 공통 인터페이스 아래에 두는 것이 핵심이다.