데모는 모델이 단 한 번 그 일을 수행할 수 있음을 증명합니다. 제품은 누구도 본 적 없는 입력값에 대해, 누군가가 예측해야 하는 가격으로, 매번 그 일을 수행할 것임을 약속합니다. 사람들이 흔히 말하는 "마지막 10%"의 거의 모든 것은 이 두 문장 사이의 거리이며, 그것은 결코 10%가 아닙니다.

데모가 허용받는 가정들

데모는 나쁜 결과물이 아닙니다. 그것은 명시적인 범위를 가진 정당한 실험이며, 데모가 빠른 이유는 제품은 허용되지 않는 네 가지 가정을 허용받기 때문입니다. 이를 기록해 두는 것은 고장 난 항목들의 목록을 작성하는 것보다 유용합니다. 왜냐하면 여러분이 곧 맞닥뜨리게 될 모든 운영 환경(production)에서의 놀라운 상황들은 바로 이 네 가지 가정 중 하나가 만료되었기 때문입니다.

• 입력값은 당신이 선택한 것들이다. 데모는 종종 무의식적으로, 잘 작동했기 때문에 선택된 예시들에 의해 구동됩니다. 제품은 사용자가 무엇을 붙여넣든 그에 따라 구동됩니다.
• 단 하나의 샘플이 곧 동작 방식이다. 데모는 프롬프트(prompt)를 몇 번 실행했고 출력값은 좋았습니다. 아무도 꼬리 부분(tail)을 보지 않았는데, 꼬리를 확인하려면 수백 개의 샘플이 필요하기 때문입니다.
• 비용은 호출당 수치이다. 누군가는 가격에 토큰(token) 수를 곱했습니다. 하지만 아무도 토큰 수의 분포에 재시도(retries)의 분포를 곱하지 않았습니다.
• 사람이 존재한다. 데모를 실행하는 사람은 모든 출력값을 읽고, 나쁜 것은 조용히 버리며, 다시 표현합니다. 그 사람이 바로 품질 계층(quality layer)이며, 제품을 출시할 때는 그 사람이 함께 출시되지 않습니다.

네 번째 가정은 가장 큰 하중을 견디고 있으며 가장 눈에 띄지 않습니다. 데모는 사람이 루프 안에 포함된(human-in-the-loop) 시스템이며, 여기서 사람은 내레이터(narrator) 역할까지 겸하기 때문에 보이지 않습니다.

입력 분포가 가장 먼저 무너진다

가장 먼저 무너지는 것은 거의 모델의 품질이 아닙니다. 실제 입력값은 더 길고, 더 지저분하며, 다국어이고, 비어 있거나, 적대적(adversarial)이거나, 중복되거나, 혹은 텍스트로 예상했던 것의 스크린샷일 수 있습니다. 데모 프롬프트는 실제로 들어오는 데이터의 좁은 단면(narrow slice)에 불과한 입력 형태에 맞춰 작성되었습니다.

이 메커니즘은 해결책을 제시해주기 때문에 정확하게 명시할 가치가 있습니다. 프롬프트는 분포 외 입력 (out-of-distribution input)에 대한 동작이 정의되지 않았으며 예고되지도 않은 하나의 프로그램입니다. 즉, 타입 에러 (type error)도, 예외 (exception)도, 빈 결과값도 발생하지 않습니다. 대신 프롬프트 작성자가 전혀 고려하지 않았던 무언가로부터 계산된, 유창한 답변이 나옵니다. 따라서 실패는 에러가 아닌 콘텐츠의 형태로 나타나며, 당신의 모니터링 시스템 중 그 어떤 것도 콘텐츠를 감시하고 있지 않습니다.

가장 저렴한 대응책은 더 나은 프롬프트가 아닙니다. 그것은 코퍼스 (corpus, 말뭉치)입니다. 프롬프트가 완성되기 전에 베타 테스트, 해당 기능이 대체하고 있는 수동 프로세스, 고객 지원 대기열 등에서 50개에서 100개 정도의 실제 입력을 추출하여 읽어보세요. 당신이 놓치고 있는 사양 (specification)의 대부분은 그 더미 속에 있으며, 이를 확인하는 데는 단 한 번의 오후 시간만이 소요됩니다. 이는 곧 당신의 골든 데이터셋 (golden dataset)이 될 코퍼스이므로, 오후 시간을 두 번 낭비할 필요가 없습니다.

그다음은 당신이 샘플링하지 못한 분산 (variance)

두 번째 실패 원인은 모델은 하나의 분포 (distribution)이고, 데모는 그 분포로부터 추출된 하나의 표본 (draw)이라는 점입니다. 5개의 좋은 출력값은 90%의 성공률과 일치할 수 있습니다. 만약 해당 기능이 하루에 천 번 실행된다면, 이는 훌륭한 데모일 수는 있으나 나쁜 제품이 됩니다. 매일 100개의 잘못된 출력이 발생하며, 그 각각은 실험에 동의하지 않은 특정 사용자 앞에 놓이게 되기 때문입니다.

이는 미묘한 통계적 관점이 아니며, 데모가 설득력 있게 느껴졌다는 이유로 일상적으로 간과되곤 합니다. 해결책은 기계적입니다. 이 기능에 대해 허용 가능한 실패율 (failure rate)이 얼마인지 결정한 다음, 그 비율을 더 나쁜 비율과 구별할 수 있을 만큼 충분히 샘플링하십시오. 95%와 85%를 구분해야 한다면 수십 개의 예시가 필요하고, 99%와 97%를 구분해야 한다면 수백 개가 필요합니다. 정확히 몇 개가 필요한지에 대한 산술적 계산은 평가 클러스터의 통계 페이지 (the statistics page in the evaluation cluster)에서 다룹니다.

관련된 함정은 데모를 평가한 사람과 동일한 사람이 동일한 예시를 사용하여 동일한 자리에서 데모를 튜닝했다는 점입니다. 그것은 평가 (evaluation)가 아니라 맞춤 (fitting)입니다. 반복 (iteration) 과정 동안 보지 않는 별도의 홀드아웃 데이터셋 (held-out slice)을 유지하는 것은 데모를 증거로 바꾸는 가장 작은 규율입니다.

그다음은 비용이며, 이 또한 분포입니다

세 번째 가정은 조용히 만료됩니다. 누군가가 데모 프롬프트로부터 호출당 비용을 계산하고 예상 볼륨 (expected volume)을 곱했습니다. 그 곱셈의 모든 항은 과소평가되었으며, 대신 수행해야 할 산술의 형태는 다음과 같습니다. 각 입력에 대해 본인만의 수치를 사용하십시오. 핵심은 값이 아니라 구조입니다.

cost_per_served_request =
      (input_tokens_p50  * input_price)
    + (output_tokens_p50 * output_price)
...

이러한 항들 중 세 가지는 데모에는 전혀 존재하지 않습니다. 재시도 정책 (retry policy), 폴백 (fallback), 그리고 보통 두 번째 호출 (second call)이 없습니다. 가드레일 (guardrail), 분류기 (classifier), 그리고 판정기 (judge)는 모두 나중에 추가되며, 각각은 예측 (forecast)에 아무도 포함하지 않은 요청당 하나의 호출입니다. 데모 비용이 모델 호출 한 번이었던 기능은 프로덕션 (production) 단계에서 쉽게 세 번의 호출에 도달할 수 있으며, 원래 숫자가 업데이트 가능한 공식으로 기록되지 않았기 때문에 예측은 결코 수정되지 않았습니다.

간극의 나머지 절반은 데모에 p99가 없다는 점입니다. 토큰 수 (Token counts)는 긴 오른쪽 꼬리 (long right tail)를 가집니다. 예를 들어 사용자가 계약서 전체를 붙여넣는 경우입니다. 여러분의 용량 (capacity), 타임아웃 (timeouts), 그리고 사용자당 지출 한도 (per-user spend cap)는 중앙값 (median)이 아닌 꼬리 (tail)에 맞춰 크기가 결정됩니다.

간극을 메우는 빌드 순서

각 단계가 다음 단계를 추측이 아닌 측정 가능한 것으로 만들기 때문에, 특정 순서로 진행할 때 간극을 가장 저렴하게 메울 수 있습니다.

단계별 설명

모델은 5단계가 되어서야 나타나고, 프롬프트는 거의 등장하지 않는다는 점에 주목하십시오. 이것이 바로 데모와 제품 간의 실제 격차를 보여줍니다: 데모는 모델 자체에 관한 것이었고, 제품은 그 주변을 둘러싼 모든 것(everything that surrounds it)에 관한 것입니다. 이 주변 환경 중 엔지니어링적인 부분—마감일, 재시도, 성능 저하(degradation)—은 별도의 작업 영역이며 잘 이해되어 있습니다. 하지만 그 위에 있는 부분은 팀들이 건물을 짓는 것처럼 느껴지지 않기 때문에 건너뛰는 부분입니다.

요청 비용이 추정치가 아니라 기록되는 경우, 5단계가 더 솔직하게 유지하기 쉽습니다. 여러분이 선택하는 모델에 대한 토큰당 가격은 모델 카탈로그에 나열되어 있으며, 위 공식에서 프로덕션 단계에 필요한 두 가지 숫자—p50 및 p99에서의 토큰 수—는 월별 총액에서 도출할 수 있는 것이 아니라 요청(per-request) 필드입니다.

관련 자료

• 반전 패턴: 기본 인터페이스로서의 채팅 (Anti-Pattern: Chat as the Default Interface)
• 반전 패턴: 느낌으로 평가하기 (Anti-Pattern: Evaluating by Vibes)
• AI 제품 출시 전 체크리스트 (A Checklist Before You Ship Anything AI)