데모 격차 (The demo gap)

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

데모와 프로덕션 사이의 격차는 AI의 문제가 아닙니다. 이는 엔지니어링 (Engineering) 문제이며, AI는 실패 모드 (Failure modes)가 데이터베이스 오류나 널 포인터 (Null pointer)보다 더 미묘하기 때문에 이 문제를 더 눈에 띄게 만듭니다. 전통적인 소프트웨어 시스템은 무언가 잘못되면 예외 (Exception)를 발생시킵니다. 하지만 AI 시스템은 그럴듯하게 들리지만 틀린 답변을 생성하며, 피해가 발생할 때까지 아무도 이를 알아차리지 못합니다.

AI 파일럿 (Pilot)을 운영해 본 모든 팀은 이와 유사한 경험을 했습니다. 시스템은 데모에서 아름답게 작동하고, 내부 테스트 중에도 잘 작동하지만, 실제 사용자에게 도달하면 무언가 어긋납니다. 즉시 지목할 수 있는 방식으로 고장 난 것은 아니지만, 시연했던 장소에서 보여준 것만큼 일관되게 좋지 않습니다. 왜 그런지를 이해하는 것이 이러한 문제를 겪지 않는 무언가를 구축하기 위한 시작점입니다.

구현이 실제로 실패하는 지점

빈도순으로 나열한 가장 흔한 실패 지점들입니다. 첫째: 평가 프레임워크 (Evaluation framework)가 없습니다. 따라서 팀은 사용자가 보고하거나 비즈니스 지표 (Business metric)가 변할 때까지 시스템이 실패하고 있다는 사실을 알지 못합니다. 평가 (Evals)가 없는 시스템은 눈을 가리고 비행하는 것과 같습니다. 변경 사항을 적용해도 그것이 도움이 되었는지 해가 되었는지 알 수 없습니다. 업데이트를 배포하고 나서야 고객 지원 티켓 (Support tickets)을 통해 회귀 (Regressions)를 알게 됩니다.

둘째: 그럴듯하지만 관련 없는 콘텐츠를 반환하는 검색 (Retrieval)으로 인해, 확신에 찬 어조의 틀린 답변을 생성하는 경우입니다. 이는 해당 용어가 통상적으로 의미하는 방식의 환각 (Hallucination)은 아닙니다. 모델은 잘못된 자료를 바탕으로 올바르게 추론하고 있는 것인데, 이는 검색 레이어 (Retrieval layer)가 키워드 매칭 (Keyword match)으로는 관련 있어 보이지만 모델이 실제 질문에 답하는 데 필요한 것은 아닌 것을 반환할 때 발생합니다.

셋째: 설계 분포 (Design distribution)를 벗어난 입력에 대한 처리가 없는 경우로, 이로 인해 에지 케이스 (Edge cases)가 에러를 발생시키거나 에러로 처리되었어야 할 출력을 생성하게 됩니다. 모든 시스템에는 경계 (Boundary)가 있습니다. 설계된 입력값들과 그 외의 모든 것들 사이의 경계 말입니다. 그 경계에서 어떤 일이 일어날지는 아키텍처적 결정 (Architectural decision) 사항이지만, 대부분의 팀은 의도하기보다는 기본 설정값에 따라 이를 결정합니다.

넷째: 프로덕션 환경에서의 모니터링 (Monitoring)이 없는 경우로, 이로 인해 실패 패턴이 보이지 않게 축적되다가 비즈니스 문제로서 수면 위로 드러나게 됩니다. 비즈니스 수준에서 문제가 가시화될 때쯤이면, 시스템은 대개 이미 몇 주 동안 실패해 온 상태입니다.

평가 요구사항 (The evaluation requirement)

평가 프레임워크 (Evaluation framework)가 없는 프로덕션 AI 시스템은 개선할 수 없는 시스템입니다. 프롬프트 (Prompt) 변경이 상황을 개선했는지 악화시켰는지 알 수 없습니다. 모델 업데이트가 무언가를 망가뜨렸는지 알 수 없습니다. 새로운 카테고리의 입력이 올바르게 처리되고 있는지 알 수 없습니다.

평가 (Evaluation)는 소프트웨어 엔지니어링 관점에서의 테스트 (Testing)가 아닙니다. 이는 프로덕션 입력을 샘플링 (Sampling)하고, 모델 출력을 레이블링 (Labeling)하며, 품질의 분포 (Distribution)가 시간이 지남에 따라 어떻게 변하는지 측정하는 지속적인 프로세스입니다. 목표는 단순히 점수를 달성하고 넘어가는 것이 아닙니다. 목표는 특정 날에 당신의 시스템이 지난주와 동일한 방식으로 작동하고 있는지를 알려주는 수치를 갖는 것입니다.

그러한 수치가 없다면, AI 품질에 관한 모든 대화는 일화적 (Anecdotal)일 뿐입니다. 누군가가 나쁜 경험을 했거나 좋은 경험을 했다는 식의, 분포 (Distributions)가 아닌 개별 사례를 바탕으로 추론하게 됩니다. 사용자가 10명일 때는 이 방식이 통할지 모르지만, 규모가 커지면 완전히 무너집니다.

LLM evals에서 평가 프레임워크 (evaluation framework)를 구축하는 방법을 다루었습니다. 요약하자면 다음과 같습니다: 레이블이 지정된 입력 세트와 예상 출력 (expected outputs), 이를 바탕으로 시스템을 자동으로 실행할 방법, 그리고 통과와 실패를 구분하는 임계값 (threshold)이 필요합니다. 이 임계값은 모든 배포 전에 반드시 확인되어야 합니다.

검색 (Retrieval) 및 지식 관리 (knowledge management)

대부분의 프로덕션 AI 애플리케이션은 검색 (retrieval)에 의존합니다. 즉, 시스템이 유용한 답변을 생성하기 전에 적절한 문서, 적절한 정책, 적절한 제품 정보, 적절한 계정 기록을 찾아내야 합니다. 검색은 실제 프로덕션 AI 시스템이 가장 많이 실패하는 지점이며, 실패 양상이 생성 (generation) 문제처럼 보이기 때문에 디버깅하기 가장 어려운 부분입니다.

실패 양상은 관련이 있어 보이지만 모델이 실제로 필요로 하는 것은 아닌 것을 반환하는 검색입니다. 이는 데이터 품질 문제, 임베딩 모델 (embedding model) 문제, 그리고 청킹 전략 (chunking strategy) 문제가 동시에 발생하는 현상입니다. 문서는 지식 베이스 (knowledge base)에 존재합니다. 임베딩은 이를 벡터 공간 (vector space)의 어딘가에 배치합니다. 쿼리 (query)가 도착하여 10개의 구절을 검색했는데, 그중 9개는 인접한 주제의 것이고 단 하나만이 중간에 파묻힌 정답입니다. 모델은 10개 모두를 바탕으로 추론하여, 기술적으로는 틀린 9개의 정보에 의해 뒷받침되는 답변을 생성합니다.

프로덕션 환경에서 검색을 제대로 수행하려면 생성 단계와는 별도로 검색 단계를 위한 평가 프레임워크를 구축해야 하지만, 대부분의 팀은 그렇게 하지 않습니다. 그들은 시스템을 엔드 투 엔드 (end-to-end)로 평가하며, 답변이 틀리면 프롬프트 (prompt)를 수정합니다. 하지만 실제 문제는 검색이었습니다. 프롬프트 변경은 아무런 효과가 없으며, 이제 팀은 왜 자신들의 변경 사항이 작동하지 않는지 혼란에 빠지게 됩니다.

실질적인 해결책은 검색 평가 (retrieval eval)입니다. 일련의 테스트 쿼리 세트에 대해 어떤 문서가 관련이 있는지 레이블을 지정하고, 검색 시스템을 실행한 뒤, 상위 결과에 올바른 문서가 얼마나 자주 나타나는지 측정하는 방식입니다. 이 수치는 생성 품질 (generation quality)과는 별도로 추적해야 합니다. 왜냐하면 각각을 개선하기 위한 레버 (levers)가 서로 다르기 때문입니다.

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

프로토타입의 성능은 부하가 걸린 프로덕션 환경의 성능과 전혀 다릅니다. 개발 단계에서 800밀리초 (milliseconds)가 걸리던 응답은, 데이터베이스가 활성화(warm)되어 있고 수백 명의 동시 사용자가 모델을 호출하며, 검색 계층 (retrieval layer)이 실제 지식 베이스를 대상으로 실제 작업을 수행하는 프로덕션 부하 상황에서는 2초가 됩니다.

테스트 시 쿼리당 몇 푼 정도의 비용이 들던 시스템도 규모가 커지면 상당한 비용이 됩니다. 지연 시간과 비용을 결정하는 아키텍처 결정 사항들, 즉 어떤 모델을 사용할지, 컨텍스트 (context)를 얼마나 포함할지, 캐싱 (cache)을 할지, 어떤 작업을 병렬로 실행할지 등은 장애 검토 (incident review) 중에 발견되는 것이 아니라 프로덕션 배포 전에 결정되어야 합니다.

대부분의 팀은 우연히 자신들의 지연 시간 및 비용 프로필을 발견하게 됩니다. 서비스를 출시하면 시스템이 예상보다 느려지고, 그제야 반응적으로 최적화를 시작합니다. 출시 후에 가능한 최적화는 출시 전에 가능한 최적화의 부분 집합에 불과합니다. 모델 선택이나, 더 큰 모델로 라우팅하기 전에 분류를 위해 더 작은 특화 모델을 사용할지 여부와 같이 영향력이 매우 큰 결정들은 나중에 변경하기 비용이 많이 드는 아키텍처 결정이기 때문입니다.

우리는 비용에 대해 AI 에이전트 비용 (AI agent cost)에서 구체적으로 다루었습니다. 핵심은 비용과 지연 시간을 개발 단계에서 측정하여 추정하는 것이 아니라, 배포 전에 현실적인 부하 상황에서 프로파일링해야 한다는 점입니다.

모니터링 및 장애 대응 (Monitoring and incident response)

프로덕션 AI 시스템은 전통적인 소프트웨어 장애와는 다른 방식으로 실패합니다. 시스템이 예외(Exception)를 발생시키지 않기 때문입니다. 대신 틀렸거나 도움이 되지 않는 답변을 생성하며, 그것이 문제가 되는지 여부는 문맥(Context)에 따라 달라집니다. 예를 들어, 사용자가 요약을 요청했는데 기술적으로는 정확하지만 가장 중요한 핵심을 놓친 요약이 제공되었다면, 이것을 실패라고 볼 수 있을까요? 이는 사용 사례(Use case)에 따라 다릅니다. 전통적인 모니터링으로는 이 질문에 답할 수 없습니다.

모니터링은 단순히 가용성(Availability)과 에러율(Error rate)뿐만 아니라 품질 지표(Quality metrics)를 추적해야 합니다. 이는 출력물을 샘플링하고, 이를 평가기(Evaluators)를 통해 실행하며, 시간에 따른 품질 분포를 추적하고, 분포가 변화할 때 알림(Alert)을 보내는 것을 의미합니다. 이때 알림은 "시스템이 다운되었습니다"가 아니라, "최근 24시간 동안 수용 가능하다고 평가된 출력물의 비율이 8%포인트 하락했습니다"가 되어야 합니다.

AI 시스템을 위한 장애 대응(Incident response) 또한 전통적인 소프트웨어의 장애 대응과는 다릅니다. 모델은 블랙박스(Black box)이며 "좋은 상태(Good state)"는 결정론적 함수(Deterministic function)가 아닌 출력물의 분포이기 때문에, 동일한 방식으로 알려진 정상 상태로 롤백(Roll back)할 수 없습니다. 대신 이전의 프롬프트(Prompt), 이전의 검색 설정(Retrieval configuration), 또는 이전의 모델 버전으로 롤백할 수 있으며, 이를 위해서는 무엇이 언제 변경되었는지 알 수 있는 관측성(Observability) 인프라가 갖춰져 있어야 합니다.

우리는 AI 관측성(AI observability)에서 계측(Instrumentation)에 대해 다루었습니다. 핵심 요구 사항은 모든 프로덕션 요청이 재현 가능한 충분한 정보와 함께 로그로 기록되어야 한다는 점입니다. 즉, 입력값(Input), 검색된 문맥(Retrieved context), 모델 출력(Model output), 지연 시간(Latency), 그리고 비용(Cost)이 포함되어야 합니다. 이것이 없다면 장애 조사(Incident investigation)는 추측에 의존할 수밖에 없습니다.

프로덕션 레디(Production-ready)의 실제 의미

'프로덕션 레디(Production-ready)'라는 용어는 종종

시스템이 모든 배포 전에 통과 기준(passing threshold)을 갖춘 명확한 평가 프레임워크(evaluation framework)를 갖추고 있을 때, 비로소 프로덕션 레디(production-ready)라고 할 수 있습니다. 생성 레이어(generation layer)와 별도로 평가되며, 자체적인 품질 지표(quality metric)와 통과 기준을 가진 검색 레이어(retrieval layer)가 있어야 합니다. 지연 시간(latency)과 비용은 개발 부하(development load)가 아닌 실제 부하(realistic load) 하에서 프로파일링되어야 합니다. 설계 분포(design distribution)를 벗어난 입력값을 우아하게 처리하는 가드레일(guardrails)이 필요하며, 이는 확신에 찬 오답을 내놓는 대신 유용한 정보를 반환하거나 명확하게 거절하는 것을 의미합니다.

사용자가 문제를 보고하기 전에 품질 저하를 드러내는 모니터링(monitoring)이 필요합니다. 즉, 품질 분포(quality distribution)는 가끔 샘플링하는 것이 아니라 지속적으로 추적되어야 합니다. 그리고 모니터링이 문제를 포착했을 때를 대비한 사고 대응 절차(incident response procedures)가 있어야 합니다. 즉, 누구에게 페이지(page)가 전송되는지, 무엇을 가장 먼저 확인하는지, 롤백(rollback) 옵션은 무엇인지가 정의되어 있어야 합니다.

이것이 기준입니다. 이 기준에 미치지 못하는 모든 것은 파일럿(pilot)이지 프로덕션 시스템이 아니며, 그 격차는 최악의 순간에 드러나는 경향이 있습니다. 테스트 중이나 내부 검토 중이 아니라, 비즈니스가 시스템에 의존하기 시작한 출시 6주 후에 말입니다.

조직적 차원

프로덕션 AI는 기술적인 이유뿐만 아니라, 조직이 이를 단순한 소프트웨어 인도(software delivery) 프로젝트처럼 취급하기 때문에 실패합니다. 그 사고 모델은 다음과 같습니다: 기능 범위를 정하고, 구축하고, 테스트하고, 배포하면 끝입니다. 그리고 팀을 다음 프로젝트로 이동시킵니다. 이 모델은 AI 시스템의 경우 특정한 방식으로 무너집니다.

AI 시스템은 일반적인 소프트웨어 시스템이 요구하지 않는 방식의 지속적인 유지보수(ongoing maintenance)를 필요로 합니다. 모델이 개선되면, 모델의 새로운 버전은 입력값의 일부에서 이전과 다르게 동작합니다. 사용자의 행동이 변하거나 비즈니스가 시스템에 요구하는 사항이 변함에 따라 데이터 분포(data distribution)가 이동합니다. 비즈니스 요구사항이 변하면 평가 기준(evaluation bar)도 이동합니다. 이 모든 과정은 누군가가 시스템을 능동적으로 관리하고, 여전히 제대로 성능을 내고 있는지 측정하며, 조정을 수행할 것을 요구합니다.

초기 개발에는 예산을 책정하지만 지속적인 운영에는 책정하지 않는 팀은 결국 몇 달에 걸쳐 조용히 성능이 저하되는 시스템을 갖게 됩니다. 모델 제공업체가 새로운 버전을 출시하면, 팀은 자신들의 특정 사용 사례(use case)에 대해 먼저 평가하지 않고 업그레이드를 진행합니다. 기반 데이터가 변경됨에 따라 지식 베이스(knowledge base)는 노후화되지만, 아무도 임베딩(embeddings)을 갱신하지 않습니다. 평가 프레임워크(evaluation framework)는 한 번 구축된 후 업데이트되지 않아, 더 이상 설계된 목적대로 측정하지 못하게 됩니다.

올바른 조직 모델은 결과물을 전달하고 떠나버리는 프로젝트 팀이 아니라, 시스템에 대한 지속적인 소유권을 가진 제품 팀입니다. 이는 예산 편성, 인력 충원, 그리고 성공을 측정하는 방식에 영향을 미칩니다. 질문은 "기능을 출시했는가?"가 아니라, "출시 6개월 후에도 그 기능이 여전히 제대로 작동하고 있는가?"가 되어야 합니다.

이것이 데모에서만 작동하는 AI와 엔드 투 엔드로 구축된 프로덕션 AI (production AI built end to end) 사이의 차이점입니다. 이는 기술의 문제가 아닙니다. AI 시스템을 지속적인 운영 요구 사항을 가진 제품으로 취급하고, 이를 지원할 인프라, 프로세스 및 팀 구조를 구축하는 것에 관한 문제입니다.

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