RAG 파이프라인이 3일 연속으로 죽자, 저는 그것이 죽을 것이라고 가정하고 재구축했습니다.

문서 수집(document-ingestion) 파이프라인이 3일 연속으로 작동을 멈춘 후, 저는 '작동할 것이다'라는 믿음을 버리고 다음 하나의 가정을 중심으로 수집 계층을 재구축했습니다. 바로 그것은 죽을 것이다는 가정입니다.

이후 이 시스템은 127개의 대화 코퍼스(~8.2M 문자, ~11,400 청크)에 걸쳐 5번의 세션 종료(session kills)와 19번의 워치독 재시작을 견뎌냈으며 — 손실된 대화는 없고, 중복도 없습니다.

실제로 중요했던 것들 (순서대로)

멱등성 쓰기(Idempotent writes) (upserts) — 재실행 시 중복이 발생하지 않아 충돌 비용이 없습니다.
작업을 설명하는 내용보다 먼저 체크포인트 작성 — 사이드카가 멈춘 정확한 지점부터 재개됩니다.
각 벡터 스토어 쓰기를 서브프로세스에서 처리 — 한 부분이 하나의 대화를 오염시키지만, 전체 실행은 그렇지 않습니다.
청크별 로깅(Per-chunk logging) — '조용한' 프로세스를 종료시키는 워치독이 작동하는 프로세스도 종료시킬 수 있습니다. 따라서 로그는 진실을 말해야 합니다.
로깅 속도에 맞춰 보정된 만료 시간(staleness timeout)을 가진 워치독 — 알려진 하나의 결합 요소이며, 문서화되었습니다.

임베딩 모델, 벡터 DB 선택, 프레임워크. 모두 교체 가능합니다. 실질적인 제품은 복원력 아키텍처입니다.

완전히 로컬 환경: 8GB MacBook Air에서 Ollama + nomic-embed-text + ChromaDB를 사용하며, 클라우드도 API 키도 계정도 없습니다. 비행기 모드에서도 안전합니다.

3일간의 부분이 로깅 오류가 아니라 시스템 오류로 진단된 밤, 그리고 제가 재시작 횟수를 완료 횟수로 세는 대신 수정해야 했던 기록을 포함한 전체 설계 근거는 다음에서 공개되었습니다: The Cache Is Not the Corpus

자신의 오류를 숨기는 기록은 문서화가 아니라 홍보입니다.

다음 시리즈에서는, 감시견(watchdog) 대 하트비트(heartbeat) 디자인이 운영자들로부터 살아남는 AI 시스템을 구축하는 데 무엇을 가르쳐 주는지 다룹니다. 관심 있으시면 팔로우해주세요.