RAG 파이프라인이 세 번 다운된 이유는 단계 간 데이터 형식 불일치
한 개발자의 이 지난달 세 차례 장애를 일으켰는데, 매번 원인이 같았다. 여러 처리 단계를 거치는 에서 각 단계가 다음 단계로 넘기는 데이터의 형식(스키마)이 명확히 정해져 있지 않아서 생긴 문제였다. 첫 번째 장애에서는 검색 단계가 순위가 매겨진 조각(chunk) 대신 일반 문장을 반환했는데, 이 오류는 두 단계 뒤에서야 드러났다. 두 번째 장애에서는 프롬프트를 살짝 수정한 뒤 정보 추출 단계가 결과값에서 항목 두 개를 빠뜨렸고, 요약 단계는 빈 값을 받고도 이를 그럴듯하게 채워 넣어 오류를 숨겼다.
세 번째 장애에서는 도구를 호출하는 에이전트가 정해진 형식의 JSON 대신 단순 문자열을 반환했다. 원인을 찾는 데 두 시간이 걸렸지만 고치는 데는 코드 한 줄이면 충분했다. 모두 한 단계의 출력 형식이 바뀌었는데 다음 단계는 예전 형식을 그대로 기대하면서, 실제 서비스에 배포되기 전까지 아무도 이를 잡아내지 못한 경우였다. 에이전트 빌더로 여러 기업용 워크플로를 다루면서 이 문제를 진지하게 고민하게 됐다고 한다.
어려운 부분은 에이전트 하나가 답을 잘 내놓게 만드는 게 아니라, 단계 간 데이터 전달(핸드오프)에서 형식이 몰래 바뀌는 걸 막는 것이었다. 각 단계 사이에 계약(정해진 규칙)을 적용하고 나서야 이런 장애가 멈췄다. 스키마가 잘못된 추론 자체를 막아주지는 않지만, 형식이 어긋나는 문제를 실제 장애로 번지기 전에 잡아낸다.
핵심 포인트
- 이 한 달 새 세 번 다운됐는데 원인은 매번 같았음 — 단계 간 출력 형식이 몰래 바뀌는 문제
- 검색 단계가 순위 매겨진 조각 대신 일반 문장을 반환해 두 단계 뒤에서야 오류 발견
- 프롬프트를 살짝 수정한 뒤 추출 단계가 항목을 빠뜨렸고, 다음 단계가 빈 값을 그럴듯하게 채워 오류를 숨김
- 에이전트가 정해진 JSON 형식 대신 단순 문자열을 반환한 사례도 있었음
- 단계 사이에 계약을 두자 이런 장애가 멈췄음 — 스키마는 잘못된 추론은 못 고치지만 구조적 문제는 조기에 잡아냄