RAG 파이프라인 반복 장애의 원인은 핸드오프 형식 변화였고 JSON Schema 계약으로 해결했다

커뮤니티 반응은 실무 경험에 기반한 공감이 많았을 가능성이 크다. 핸드오프 스키마 계약을 도입해 조기 실패를 유도하는 접근이 비용·시간 절감에 기여한다는 실무적 타당성이 강조되었다. 다만 스키마로는 모델의 추론 오류를 막을 수 없다는 점이 공통적인 유의점으로 제기되었다.

• 각 컴포넌트의 출력에 대해 명세화된 JSON Schema를 정의하고 배포 파이프라인에서 유효성 검사를 통과하지 못하면 즉시 실패하도록 설정하라.
• 핸드오프 스키마를 버전 관리하고 스키마 진화 절차를 문서화해 프롬프트 튜닝이나 코드 변경 시 스키마 업데이트를 의무화하라.
• 런타임에서는 스키마 위반 로깅을 상세히 남기고 CI 단계에서 샘플 데이터로 스키마 회귀 테스트를 자동화하라.

Reranker

— 검색 단계가 반환한 후보 결과에 점수를 매겨 순위를 재정렬하는 구성요소로서 입력은 검색 결과(문서 조각 또는 문장)이고 출력은 각 후보에 대한 점수화된 메타데이터이다. 이 글 맥락에서는 reranker가 정량화된 청크(스코어+메타)를 기대했으나 자유형 텍스트가 들어와 파이프라인 오류가 발생한 핵심 포인트이다. 재랭커의 출력 형식 불일치는 downstream 컴포넌트가 구조적 가정을 깨뜨리는 계기가 된다.

Entity Extraction

— 원문에서 이름·개체·속성 등을 추출해 구조화된 키-값 형태로 반환하는 처리 단계로 입력은 텍스트이며 출력은 고정된 키를 가진 JSON 유사 객체이다. 해당 글에서는 프롬프트 수정으로 일부 키가 누락되어 downstream 요약기가 null을 받았고 빈 값을 채우면서 오작동이 발생했다는 사례가 제시되었다. 엔티티 추출 결과의 스키마 일관성이 전체 워크플로 안정성에 직접적인 영향을 미친다.

Summarizer

— 입력 텍스트나 구조화된 엔티티를 받아 간결한 요약 텍스트를 생성하는 구성요소로, 입력의 누락·형식 변화에 민감하여 null이나 빈 필드를 문맥적으로 보완해 출력할 가능성이 있다. 글에서는 요약기가 null을 받자 자신 있게 공란을 채워 잘못된 결과를 내는 문제가 실제 장애로 이어졌다고 보고되었다. 따라서 요약 결과의 신뢰성은 전 단계 출력의 형식 보증에 크게 의존한다.

Structural Drift

— 컴포넌트 간 데이터 교환 규약이 시간이 지나며 의도치 않게 변형되어 형식·스키마가 흐트러지는 현상으로, 입력→처리→출력의 기대 형식이 서서히 달라지는 과정이다. 글에서는 프롬프트 튜닝이나 코드 변경 후 한 단계에서 형식이 바뀌고 다음 단계가 옛 형식을 가정해 장애가 발생하는 일이 반복된다고 기술되었다. 구조적 드리프트는 조기 검출이 어렵고 발견 시점이 지연될수록 원인 규명 비용이 급증한다.

Tool Agent

— 외부 도구나 서비스와 상호작용하며 결과를 구조화된 형태로 반환해야 하는 에이전트로서 입력 요청을 처리해 JSON이나 특정 타입의 응답을 내놓는 역할을 수행한다. 본문에서는 툴 에이전트가 기대한 typed JSON 대신 평문 문자열을 반환해 워크플로가 실패한 사례가 제시되어 핸드오프의 명확한 계약 필요성을 부각시켰다. 툴 에이전트의 응답 타입 검증 부재는 생산 환경에서 시간 소모적 디버깅을 유발한다.