데모의 격차 (The demo gap)

AI 데모는 프로덕션 (Production) 환경이 공유하지 않는 조건 하에서 작동합니다. 데모는 시스템을 잘 아는 사람이 통제된 환경에서, 특정 입력값에 대해 성공하도록 지시된 모델을 사용하여 선별된 입력 세트를 실행합니다. 반면 프로덕션은 시스템 설계자가 예상하지 못한 조합으로, 지침을 읽지 않는 사용자들이 보내는 임의의 입력값을 받습니다.

데모와 프로덕션 사이의 격차는 AI의 문제가 아닙니다. 이는 AI로 인해 실패 모드 (Failure modes)가 더 미묘해짐에 따라 더 가시화되는 엔지니어링 (Engineering) 문제입니다. 전통적인 소프트웨어 시스템은 예외 (Exception)를 발생시키거나 에러를 반환합니다. AI 시스템은 확신에 찬 것처럼 들리지만 틀린 답변을 생성하며, 이는 대규모 환경에서 감지하기가 훨씬 더 어렵습니다.

실질적인 결과: 대부분의 AI 파일럿 (Pilot) 프로젝트가 실패하는 이유는 모델이 나쁘기 때문이 아닙니다. 모델이 실패하고 있을 때 이를 알 수 있는 데 필요한 인프라 (Infrastructure)를 팀이 구축하지 않았기 때문입니다. 구체적인 원인은 왜 AI 파일럿이 실패하는가에서 다룹니다.

구현이 실제로 무너지는 지점

가장 빈번하게 발생하는 실패 지점들을 빈도순으로 나열합니다.

평가 프레임워크 (Evaluation framework)의 부재. 팀은 사용자가 보고하거나 비즈니스 지표가 변할 때까지 시스템이 실패하고 있다는 사실을 알지 못합니다. 그 시점에는 이미 피해가 누적된 상태입니다. 지속적인 평가가 없다면, 모델이나 데이터가 변경될 때 개선인지 퇴보인지 구분할 방법이 없습니다.

그럴듯하지만 무관한 콘텐츠를 반환하는 검색 (Retrieval). 시스템이 관련 있어 보이는 문서를 찾아내고, 모델이 그 문서를 사용하여 답변을 구성하면, 답변은 확신에 찬 것처럼 들리지만 실제 질문에 대해서는 사실 관계가 틀리게 됩니다. 이는 RAG (Retrieval-Augmented Generation)를 사용하는 시스템에서 가장 흔한 실패 모드입니다.

설계 범위를 벗어난 입력(out-of-distribution inputs)에 대한 처리가 없습니다. 시스템은 팀이 사용자들이 할 것이라고 상상한 입력들에 대해서만 테스트되었습니다. 실제 사용자들은 다른 질문을 하고, 다른 언어를 사용하며, 오타를 내고, 시스템이 파악하지 못하는 암시적인 맥락을 포함합니다. 가드레일 (guardrails)이 없는 시스템은 무언가 잘못되었다는 신호를 보내지 않은 채 이러한 사례들에 대해 잘못된 답변을 생성합니다.

프로덕션 환경에서의 모니터링이 없습니다. 실패 패턴이 보이지 않게 쌓여갑니다. 몇 주에 걸쳐 발생하는 답변 품질의 점진적인 드리프트 (drift)는 누군가가 비즈니스 지표의 변화를 알아차리기 전까지는 어떤 대시보드에도 나타나지 않습니다.

평가 (Evaluation) 요구사항

평가 프레임워크 (evaluation framework)가 없는 프로덕션 AI 시스템은 개선할 수 없는 시스템입니다. 프롬프트 (prompt) 변경이 상황을 개선했는지 악화시켰는지 말할 수 없습니다. 모델 업데이트가 무언가를 망가뜨렸는지 알 수 없습니다. 실제 개선과 통계적 노이즈 (statistical noise)를 구분할 수 없습니다.

평가는 소프트웨어 엔지니어링 의미에서의 테스트 (test)가 아닙니다. 소프트웨어 테스트 세트는 시스템이 사양 (specification)에 따라 동작하는지 확인합니다. AI 평가 (evaluation)는 당신이 정의하고 문제에 대한 이해가 진화함에 따라 함께 진화하는 기준에 대해, 답변 품질의 분포가 시간이 지남에 따라 어떻게 변하는지를 측정합니다.

이 과정은 연속적입니다: 프로덕션 입력을 샘플링하고, 정의된 기준에 따라 모델의 출력을 레이블링 (labeling)하며, 품질 분포가 시간이 지남에 따라 어떻게 변하는지 측정하고, 분포가 성능 저하를 나타내는 방식으로 이동할 때 경고를 보냅니다. 우리는 LLM 평가 (LLM evals)에서 이를 구축하는 방법을 다룹니다.

팀들이 과소평가하는 한 가지 포인트: 평가 프레임워크는 첫 번째 사고가 발생한 후가 아니라, 프로덕션 배포 전에 존재해야 합니다. 사후에 평가를 구축하는 것은 품질 기준을 보정할 적절한 프로덕션 데이터를 가지고 있지 않기 때문에 더 어렵습니다.

검색 및 지식 관리

대부분의 프로덕션 AI 애플리케이션은 검색 (Retrieval)에 의존합니다. 즉, 시스템은 유용한 응답을 생성하기 전에 올바른 문서, 올바른 정책, 올바른 제품 정보, 올바른 계정 기록을 찾아내야 합니다. 검색이 없다면 모델은 훈련 시에 가졌던 지식으로만 작동하게 되는데, 여기에는 귀사의 특정 데이터가 포함되어 있는 경우가 거의 없습니다.

핵심적인 실패 방식은 관련이 있어 보이지만 모델이 실제로 필요로 하는 것은 아닌 것을 검색 결과로 반환하는 것입니다. 이는 모델의 문제가 아닙니다. 이는 데이터 품질, 임베딩 (Embedding) 모델, 그리고 청킹 (Chunking) 전략이 동시에 얽힌 문제입니다. 동일한 질문이라도 문서가 어떻게 분할되었는지, 그리고 임베딩이 어떻게 훈련되었는지에 따라 한 임베딩 세트에서는 올바른 문서를 반환하고 다른 세트에서는 잘못된 문서를 반환할 수 있습니다.

프로덕션 환경에서 검색을 성공시키려면 생성 (Generation) 단계와 별개로 검색 단계를 위한 평가 프레임워크 (Evaluation Framework)를 구축해야 합니다. 최종 응답만을 평가한다면, 문제가 검색된 내용에 있는지 아니면 검색된 내용을 바탕으로 생성된 내용에 있는지 분리하여 파악할 수 없습니다. 두 단계 모두 각각의 자체적인 지표 (Metrics)가 필요합니다.

저희는 RAG란 무엇인가와 벡터 데이터베이스 (Vector Databases)에서 검색 아키텍처를 자세히 다루었습니다.

프로덕션에서의 지연 시간(Latency) 및 비용

프로토타입의 성능은 부하가 걸린 프로덕션 환경의 성능과 전혀 다릅니다. 개발 단계에서 800밀리초가 걸리던 응답은 지원 인프라가 수백 개의 동시 요청으로 분산되는 프로덕션 부하 상황에서는 2초가 됩니다. 테스트 시 쿼리당 몇 센트가 들던 시스템은 하루에 수만 개의 쿼리로 확장되면 예산에서 상당한 비중을 차지하는 항목이 됩니다.

지연 시간(Latency)과 비용을 결정하는 아키텍처 결정은 성능 장애(Performance incident)가 발생했을 때 발견되는 것이 아니라, 프로덕션 배포 전에 내려져야 합니다. 여기에는 다음 사항들이 포함됩니다: 각 작업에 어떤 모델을 사용할 것인가(많은 하위 작업에는 더 작은 모델로도 충분합니다), 어디에 캐싱(Caching)을 도입할 것인가, 병렬 호출(Parallel calls) 대 순차 호출(Sequential calls)을 어떻게 구조화할 것인가, 그리고 각 요청 유형에 실제로 필요한 컨텍스트(Context)의 크기는 얼마인가 하는 점입니다.

과소평가된 지렛대: 대부분의 시스템은 무엇이 관련 있는지 결정하는 것보다 모든 것을 포함하는 것이 더 간단하기 때문에, 각 요청에 필요한 것보다 훨씬 더 많은 컨텍스트를 전송합니다. 컨텍스트 선택을 최적화하면 모델이 처리하는 토큰(Token) 수가 줄어들기 때문에 비용과 지연 시간을 동시에 줄일 수 있습니다. 비용에 대해서는 AI 에이전트 비용은 얼마나 드는가에서 구체적으로 다룹니다.

모니터링 및 장애 대응

프로덕션 AI 시스템은 전통적인 소프트웨어 장애와는 다른 방식으로 실패합니다. 시스템은 예외(Exception)를 발생시키지 않습니다. 대신 잘못되거나 쓸모없는 응답을 생성하며, 이것이 실패에 해당하는지는 정의된 컨텍스트와 품질 기준에 따라 달라집니다. 가용성(Availability)과 HTTP 에러율만으로는 이를 포착할 수 없습니다.

모니터링은 단순히 가용성과 에러율뿐만 아니라 품질 지표(Quality metrics)를 추적해야 합니다. 이는 프로덕션 출력물을 샘플링하여 자동 평가기(Automated evaluators)로 실행하고, 시간에 따른 품질 분포를 추적하며, 품질 분포가 성능 저하를 나타내는 방식으로 변할 때 경고를 보내는 것을 의미합니다. 서버가 다운될 때만 알려주는 모니터링 시스템은 프로덕션 환경의 AI에는 적합하지 않습니다.

사고 대응(Incident response) 또한 AI를 위한 구체적인 절차가 필요합니다. 응답 품질이 저하된 것을 감지했을 때 무엇을 해야 합니까? 근본 원인(모델 변경, 데이터 드리프트(Data drift), 입력 분포의 변화, 검색(Retrieval) 문제)을 식별하기 위한 프로세스는 무엇입니까? 프롬프트(Prompt)나 모델 업데이트가 상황을 악화시켰을 때의 롤백(Rollback) 프로세스는 무엇입니까? 저희는 AI 관측성 (AI observability)에서 계측(Instrumentation)에 대해 다룹니다.

프로덕션 준비(Production-ready)가 실제로 의미하는 것

시스템이 다음을 갖추었을 때 프로덕션 준비가 되었다고 합니다:

• 배포 전 정의된 승인 임계값(Approval threshold)을 포함한 명확한 평가 프레임워크 (Evaluation framework)
• 생성(Generation) 레이어와 별도로 평가되며 자체적인 지표를 가진 검색(Retrieval) 레이어
• 개발 환경뿐만 아니라 실제 부하 상황에서 프로파일링된 지연 시간(Latency) 및 비용
• 확신에 찬 듯한 잘못된 응답을 반환하지 않고, 실패 사례를 우아하게 처리하는 가드레일 (Guardrails)
• 사용자가 보고하기 전에 품질 저하를 드러내는 모니터링
• 모니터링이 포착한 사례에 대한 사고 대응 절차

이것이 표준입니다. 이보다 못한 것은 파일럿(Pilot)이지, 프로덕션 시스템이 아닙니다. 이 구분이 중요한 이유는 파일럿과 프로덕션 시스템의 운영 비용, 리스크, 기대치가 완전히 다르기 때문입니다. 파일럿을 프로덕션처럼 취급하는 것은 나타나기까지 몇 달이 걸리고 수정 비용도 많이 드는 문제를 만드는 가장 흔한 방식입니다.

조직적 차원

프로덕션 AI가 실패하는 이유는 기술적인 이유뿐만 아니라, 조직이 이를 시작, 중간, 끝이 있는 소프트웨어 인도 프로젝트로 취급하기 때문입니다. 배포를 완료하면 전달된 것으로 간주하고 다음 프로젝트로 넘어갑니다. AI 시스템은 그렇게 작동하지 않습니다.

AI 시스템은 주변 환경이 끊임없이 변화하기 때문에 지속적인 유지보수 (maintenance)가 필요합니다. 모델이 개선되면서 기본 동작이 변하고, 사용자가 변함에 따라 프로덕션 데이터 분포 (data distribution)가 변하며, 비즈니스 요구사항이 변하고, 문제에 대한 이해가 진화함에 따라 평가 기준 (evaluation pattern)이 이동합니다. 1월에는 잘 작동하던 시스템이 누군가 의도적인 변경을 수행하지 않았음에도 3월에는 성능이 저하될 수 있습니다.

초기 개발 비용은 책정하지만 지속적인 운영 (operation) 비용은 책정하지 않는 팀은 결국 몇 달에 걸쳐 조용히 성능이 저하되는 시스템을 갖게 됩니다. 올바른 모델은 프로젝트가 아니라 제품 (product)입니다. 시스템에 대한 지속적인 소유권 (ownership), 지속적으로 모니터링되는 품질 지표 (quality metrics), 그리고 무기한으로 작동하는 개선 프로세스를 갖춘 팀이 필요합니다.

이것이 AI를 확장(scale)할 수 있는 조직과 실제 프로덕션에 도달하지 못하는 파일럿 프로젝트만 쌓아가는 조직 사이의 차이입니다. 이 결정은 기술적인 문제가 아니라 주로 조직적인 문제입니다.

원문은 studiolabsai.com에 게시되었습니다. Studio Labs는 엔터프라이즈 팀을 위한 프로덕션 AI를 구축합니다. 상담 예약하기.