대부분의 AI 데모는 작동합니다. 대부분의 AI 시스템은 그렇지 않습니다.
이 두 문장 사이의 간격이 팀에게 몇 주, 때로는 몇 달의 손실을 안깁니다. 모델은 괜찮습니다. 노트북에서 프롬프트도 잘 보입니다. 그런데 실제 데이터가 들어오면 파이프라인이 무너집니다.
이것은 모델 문제가 아닙니다. 파이프라인 설계 문제입니다.
작동하는 데모와 작동하는 시스템의 차이
데모는 선별된 입력으로 실행됩니다. 시스템은 모든 것을 처리해야 합니다.
데모에서는 문서 길이, 응답 형식, 타이밍을 직접 통제합니다. 프로덕션에서는 사용자가 새벽 2시에 40,000토큰짜리 실적 발표 트랜스크립트를 제출하고, 분류 단계가 타임아웃되며, 하위 단계는 그 이유를 알지 못합니다.
팀들이 여기서 몇 주를 잃는 이유는 잘못된 방향으로 디버깅하기 때문입니다. 프롬프트를 조정합니다. 모델을 교체합니다. 실제 문제는 아무도 실패 경로를 설계하지 않았다는 것입니다.
작동하는 시스템은 각 단계가 실패했을 때 무슨 일이 일어나는지 정의합니다. 작동하는 데모는 그럴 필요가 없습니다.
세 가지 구체적인 실패 유형
1. 토큰 예산 초과
요약 단계를 구축합니다. 평균 800토큰짜리 기사로 구성된 테스트 세트에서는 잘 작동합니다. 배포합니다. 사흘 후, SEC 공시 문서 배치가 파이프라인에 들어옵니다. 평균 길이: 18,000토큰. 실행당 비용이 20배 급등합니다. 지연 시간은 세 배가 됩니다. 200토큰 요약을 기대하던 하위 단계는 이제 1,400토큰을 받아 자체 컨텍스트 윈도우를 초과합니다.
해결책은 더 나은 모델이 아닙니다. 해결책은 LLM 호출 전에 예산 게이트를 두는 것입니다. 입력 길이를 측정하고, 긴 문서를 청킹 경로로 라우팅하며, 출력 길이 제약을 명시적으로 적용하는 단계입니다. 한 번 작성하면 조용히 영원히 실행됩니다.
2. 타임아웃 연쇄 장애
단계 A가 LLM을 호출합니다. 단계 B는 단계 A를 기다립니다. 단계 C는 단계 B를 기다립니다. 단계 A에 30초 타임아웃을 설정합니다. 부하가 걸리면 LLM 공급자가 35초를 소요합니다. 단계 A가 타임아웃됩니다. 단계 B는 아무것도 받지 못하고 null 참조 오류를 던집니다. 단계 C는 실행되지 않습니다. 어떤 단계도 명시적으로 실패하지 않았기 때문에 파이프라인은 성공을 보고합니다. 그냥 멈춘 것입니다.
이것이 연쇄 장애입니다. 각 단계가 독립적으로 설계되었기 때문에 발생합니다.
해결책은 단계 간 명시적 실패 계약입니다. 각 단계는 성공, 실패, 무응답의 세 가지 상태를 처리해야 합니다. 배포 전에 무응답 경로를 테스트합니다. 시간당 300개의 기사를 처리하는 뉴스 수집 파이프라인에서 처리되지 않은 타임아웃 하나가 누군가 알아채기 전에 40개의 기사를 조용히 누락시킬 수 있습니다.
3. 무음 분류 드리프트
이것은 더 느리고 발견하기 어렵습니다.
인바운드 리드를 산업별로 라우팅하는 분류기를 구축합니다. 첫 달에는 잘 작동합니다. 세 달째가 되면 입력 분포가 변합니다. 영업팀이 새로운 버티컬을 타겟팅하고, 인바운드 메시지의 언어가 바뀌었으며, 분류기는 이제 리드의 18%를 잘못 라우팅합니다. 오류 없음. 알림 없음. 그냥 잘못된 출력만 있습니다.
무음 드리프트는 시스템이 정상으로 보이기 때문에 위험합니다. 로그는 깨끗합니다. 지연 시간은 정상입니다. 피해는 대시보드가 아닌 비즈니스 결과에 누적됩니다.
해결책은 정기적 재평가를 위한 기준 세트입니다. 레이블이 붙은 예시 50개를 유지합니다. 일정에 따라 분류기를 이 세트에 실행합니다. 주 1회면 보통 충분합니다. 정확도가 임계값 아래로 떨어지면 알림을 보냅니다. 분류기를 고정된 컴포넌트가 아니라 성능이 저하되는 컴포넌트로 취급합니다.
실제로 이를 수정하면 어떤 모습인가
뉴스 수집 및 분류 파이프라인을 예로 들겠습니다. 12개의 RSS 피드에서 기사를 가져와 주제별로 분류하고 하위 소비자에게 라우팅합니다.
강화 전:
- 입력 길이 검사 없음. 긴 기사 하나가 배치 전체를 멈춥니다.
- 타임아웃이 HTTP 레이어에만 설정됨. LLM 레벨 행업은 보이지 않습니다.
- 분류 정확도를 출시 시 한 번 수동으로 확인.
강화 후:
- 입력 게이트가 4,000토큰을 초과하는 기사를 모델에 도달하기 전에 거부하거나 청킹합니다. 배치 중단이 0으로 줄어듭니다.
- 각 LLM 호출에 15초 하드 타임아웃과 로깅된 폴백이 있습니다. 연쇄 장애가 멈춥니다.
- 60개 기사 기준 세트가 매주 일요일 실행됩니다. 정확도가 88% 아래로 떨어지면 Slack 알림이 트리거됩니다. 드리프트가 몇 달이 아닌 며칠 안에 포착됩니다.
이 수정 중 어느 것도 더 나은 모델을 필요로 하지 않았습니다. 파이프라인을 프롬프팅 문제가 아닌 엔지니어링 문제로 취급하는 것이 필요했습니다.
패턴
위의 모든 실패 유형은 공통된 근본 원인을 공유합니다. 파이프라인이 정상 경로를 위해 설계되었다는 것입니다.
프로덕션 시스템은 비정상 경로, 즉 예산 초과, 누락된 응답, 점진적 성능 저하에 대한 명시적 설계가 필요합니다. 이 설계 작업은 화려하지 않습니다. 더 나은 데모를 만들지 않습니다. 90일째에도 첫날과 동일하게 실행되는 시스템을 만듭니다.
지루한 것이 이깁니다.
AI 파이프라인을 구축 중이고 배포 전에 실패 경로에 대한 검토가 필요하다면, 대화 시작하기 →