데모는 제품이 아닙니다

원문은 lavkesh.com에 게시되었습니다.

저는 이런 일이 발생하는 것을 수십 번 목격했고, 저 자신도 한두 번 이상 직접 경험했습니다. 유스케이스 (use case)를 선정하고, 모델 (model)에 연결하고, 프롬프트 (prompt)를 작성하고, 샘플 데이터를 입력하면 작동합니다. 그냥 작동하는 수준이 아닙니다. 매우 인상적이죠. 이해관계자 (stakeholders)들에게 보여주면 회의실의 열기는 대단합니다. 누군가는 "이게 바로 우리가 필요했던 것입니다"라고 말합니다. 다른 누군가는 얼마나 빨리 출시할 수 있는지 묻습니다.

6개월 후, 팀은 그것을 처음부터 다시 구축하고 있습니다. 아이디어가 틀렸기 때문이 아닙니다. 데모를 작동하게 만든 요소가 프로덕션 시스템 (production system)을 작동하게 만드는 요소와 다르기 때문이며, 아무도 그 차이를 고려하여 설계하지 않았기 때문입니다.

가장 먼저 무너지는 것은 평가 (evaluation)입니다. 데모에서 평가는 데모를 실행하는 사람입니다. 출력을 보고, 맞게 보이면 다음으로 넘어갑니다. 프로덕션에서는 아무도 모든 출력을 지켜보지 않습니다. 자동화된 평가 (automated evaluation)가 필요하며, 처음부터 이를 위해 설계되어 있어야 합니다. 즉, 구축을 시작하기 전에 무엇이 '좋은' 것인지 정의했어야 한다는 의미입니다.

두 번째로 무너지는 것은 프롬프트 (prompt)입니다. 데모에서의 프롬프트는 여러분이 가진 예시들에 맞춰 작동하도록 작성됩니다. 실제 사용자 입력의 분포 (distribution)에 대해서는 테스트되지 않았으며, 실제 입력은 여러분이 계획한 것보다 항상 더 생소하고 다양합니다. 실제 사용 첫 주에는 어떤 데모도 예측할 수 없었던 문제들이 드러납니다.

세 번째는 비용 (cost)입니다. 데모 토큰 (tokens)은 추적하지 않는다는 의미에서 무료입니다. 프로덕션 토큰은 비용이 발생하며, 특히 원래의 아키텍처 (architecture)가 데모에는 적합하지만 프로덕션에서는 진정으로 낭비적인 방식으로 모델을 호출했다면, 규모가 커질 때 비용 계산이 맞지 않는 경우가 많습니다.

네 번째는 모델 그 자체입니다. 여러분은 프로젝트를 시작할 당시에 최신이었던 모델을 기준으로 구축했습니다. 이제 더 새로운 모델이 출시되었습니다. 성능도 더 좋고 사용하고 싶겠지만, 모델을 교체한다는 것은 모든 것을 다시 테스트해야 함을 의미합니다. 모델 버전마다 동일한 프롬프트(Prompt)라도 서로 다른 출력(Output)을 생성하기 때문입니다.

이 과정을 잘 수행하는 팀들은 몇 가지 습관을 공유하는 경향이 있습니다. 그들은 평가(Evaluation)를 사후 고려 사항이 아닌 인프라(Infrastructure)로 취급합니다. 그들은 기능을 구축하기 전에 평가 체계(Evals)를 먼저 구축하며, 이를 통해 '이런 식'이라고 데모를 가리키는 대신 성공의 기준을 구체적으로 정의하도록 강제합니다.

그들은 모델을 애플리케이션 로직(Application logic)으로부터 분리합니다. 모델은 의존성(Dependency)입니다. 모델은 인터페이스(Interface)를 가집니다. 애플리케이션의 나머지 부분은 해당 인터페이스 뒤에 어떤 모델이 있는지 알 필요도 없고 신경 쓰지도 않습니다. 이는 주변의 모든 것을 다시 작성하지 않고도 모델을 교체, 업데이트 및 버전 관리할 수 있음을 의미합니다.

그들은 비용 모니터링(Cost monitoring)을 단순한 감사 메커니즘이 아니라 아키텍처(Architectural) 결정에 정보를 제공하는 피드백 루프(Feedback loop)로서 초기부터 구축합니다. 토큰 사용량(Token usage)은 단순한 청구 항목이 아니라 엔지니어링 지표(Engineering metric)입니다.

데모는 제품을 만들 가치가 있다는 증거입니다. 그것이 제품 그 자체는 아닙니다. 이 구분은 프로젝트를 시작한 지 6개월이 지나 팀원들이 지쳐가고, 데모를 좋아했던 이해관계자(Stakeholder)가 왜 이렇게 오래 걸리느냐고 묻기 전까지는 아주 까다로운 말처럼 들릴 것입니다.