데모에서 프로덕션으로: AI 개발 라이프사이클

"AI로 만들기" 시리즈 10편

---

아무도 잘 이야기하지 않는 묘지가 있다.

데모에서 완벽하게 작동했던 AI 프로젝트들로 가득 차 있다. 창업자가 투자자에게 보여줬다. 팀이 박수를 쳤다. 준비된 데이터셋과 세 명의 테스트 사용자로 프로토타입이 완벽하게 돌아갔다. 모두가 흥분했다.

그리고 라이브로 갔다. 실제 사용자. 실제 데이터. 실제 규모. 실제 엣지 케이스. 그리고 하나씩 균열이 나타났다.

AI가 결제 고객에게 자신 있게 틀린 답을 줬다. 하루 1만 건의 API 호출이 얼마나 드는지 아무도 계산하지 않아서 비용이 폭등했다. 실제 부하에서 시스템이 느릿느릿 기어갔다. 사용자가 전체를 망가뜨리는 입력을 찾아냈다. 테스트에서 좋게 들렸던 응답이 프로덕션에서는 어색하게 들렸다. 실제 사용자들이 팀이 예상한 것과 다른 질문을 했기 때문에.

데모는 작동했다. 제품은 그렇지 않았다.

이것이 대부분의 AI 빌더들이 빠지는 간극이다. 잘 못 만들어서가 아니다. 데모 사고방식과 프로덕션 사고방식이 근본적으로 다른 분야이기 때문이다. 이 글은 프로덕션 사고방식에 관한 것이다.

---

데모-프로덕션 간극

데모는 최선의 경우를 보여주도록 최적화된다. 프로덕션 시스템은 예상하지 못한 것들을 포함한 모든 경우를 처리해야 한다.

데모에서 프로덕션으로 갈 때 변하는 것:

이 전환들 중 불가능한 것은 없다. 하지만 각각은 의도적인 설계가 필요하다. 데모가 작동했다고 자동으로 일어나는 것은 없다.

---

1단계: 프로토타입에서 파일럿으로

첫 번째 전환은 데모에서 전체 프로덕션으로가 아니다. 데모에서 실제 사용자와의 통제된 파일럿으로다.

파일럿은 모든 것을 지켜볼 수 있을 만큼 작고, 망가졌을 때 수동으로 고칠 수 있고, 규모에 헌신하기 전에 프로덕션이 실제로 어떤 모습인지 배울 수 있다.

좋은 파일럿의 모습:

• 테스트 계정이 아닌 실제 사용자 10-50명
• 엄선된 예시가 아닌 실제 데이터
• 스크립트된 시나리오가 아닌 실제 작업
• 무언가 잘못됐을 때 사용자가 알려줄 수 있는 피드백 메커니즘
• 당신이나 팀 누군가가 정기적으로 결과물을 지켜보는 것

파일럿에서 배우는 것:

• 실제 사용자가 실제로 무엇을 묻거나 입력하는가? (거의 항상 예상과 다름)
• AI가 실패하거나, 환각을 일으키거나, 잘못 느껴지는 결과물을 만드는 곳은?
• 얼마나 빨라야 하는가? (사용자는 개발자보다 훨씬 인내심이 없다)
• 실제 사용량에서 실제로 얼마가 드는가?
• 예상하지 못한 어떤 엣지 케이스가 나타나는가?

전체 출시로 바로 가는 것으로 파일럿을 건너뛰지 마라. 파일럿은 프로덕션이 실제로 무엇을 요구하는지 배우는 곳이다. 아직 흡수할 수 있는 비용으로.

---

2단계: 신뢰성 엔지니어링

프로덕션 시스템은 실패한다. 문제는 언제 실패하느냐가 아니라 언제, 어떻게, 그리고 실패했을 때 무슨 일이 일어나는가다.

AI 실패를 우아하게 처리하기

AI 결과물은 확률적이다. 때로는 틀리거나, 불완전하거나, 부적절할 것이다. 시스템이 망가지거나 당황스럽게 만들지 않고 이것을 처리해야 한다.

중요한 것에 대해 원시 AI 결과물을 사용자에게 직접 전달하지 마라. 결과물이 전달되기 전에 의미가 있는지 확인하는 검증을 구축하라. 예상한 형식인가? 존재하는 것들을 참조하는가? 길이가 합리적인가?

AI가 실패하거나, 타임아웃되거나, 유효하지 않은 것을 반환하면 무슨 일이 일어나는가? 계획을 가져라. 우아한 폴백 — "응답을 생성할 수 없었습니다, 직접 연락하는 방법이 있습니다" — 이 망가진 경험보다 무한히 낫다.

틀렸을 때 실제 결과가 있는 것, 의료 질문, 법적 세부사항, 재무 권고에는 인간 검토 단계를 구축해라. AI가 초안을 작성한다. 인간이 승인한다.

레이턴시: 속도는 기능이다

사용자는 참을성이 없다. 응답하는 데 3-4초 이상 걸리면 평균적인 사람은 프로세스를 포기한다.

전략들:

• 스트리밍 응답 — 응답이 생성되는 대로, 글자 하나씩 보여줘라. 사용자는 총 생성 시간이 같아도 스트리밍 응답을 더 빠르게 인식한다.
• 캐싱 — 같거나 비슷한 질문이 반복적으로 질문되면 응답을 캐시해라. 이미 생성한 것을 다시 생성하지 마라.
• 모델 티어링 — 단순한 작업에는 빠르고 저렴한 모델을 써라. 가장 유능한(그리고 가장 느린) 모델은 진정으로 필요한 작업을 위해 남겨둬라.
• 비동기 처리 — 즉각적인 응답이 필요하지 않은 작업(보고서 생성, 배치 분석)은 백그라운드에서 처리하고 완료되면 알림을 보내라.

모니터링: 볼 수 없는 것을 고칠 수 없다

프로덕션에서는 항상 무슨 일이 일어나는지 가시성이 필요하다.

모니터링할 것:

• 응답 레이턴시 (요청이 얼마나 오래 걸리는가?)
• 오류율 (얼마나 자주 실패하는가?)
• AI 결과물 품질 (응답이 실제로 좋은가? 자동화된 지표만이 아닌 샘플링과 인간 검토가 필요하다)
• 요청당 비용 (예상한 만큼 지출하고 있는가?)
• 사용 패턴 (누가, 무엇을, 언제, 어떻게 사용하는가?)

Langfuse, Helicone, Langsmith 같은 도구들이 AI 애플리케이션 모니터링을 위해 특별히 만들어졌다. 모든 프롬프트, 모든 응답, 모든 레이턴시 측정을 기록하고 사용자가 알리기 전에 문제를 발견할 수 있는 대시보드를 제공한다.

규칙: 출시 전에 모든 것을 계측하라. 라이브 시스템에 모니터링을 나중에 추가하는 것은 고통스럽고 가장 가시성이 필요한 기간에 눈을 감고 운영했다는 의미다.

---

3단계: 비용 아키텍처

이것이 가장 많은 AI 프로젝트를 죽이는 단계다. 제품이 작동하지 않아서가 아니라 경제성이 안 맞아서.

AI API 호출은 돈이 든다. 데모 규모에서 비용은 사소하다. 월 몇 달러. 수천 명의 사용자가 각각 수십 건의 요청을 하는 프로덕션 규모에서 숫자는 매우 불편하게 빠를 수 있다.

아무도 미리 하지 않는 비용 계산

출시 전에 사용자 1인당 월 비용을 계산하라.

요청당 비용 = (입력 토큰 × 입력 가격) + (출력 토큰 × 출력 가격)
사용자당 일일 요청 수 × 30 = 사용자당 월 요청 수
사용자당 월 요청 수 × 요청당 비용 = 사용자당 월 비용

그리고 물어봐라: 계획된 가격으로 실행 가능한 마진이 남는가?

실제 숫자 (근사치, 2026년 중반):

• Claude Sonnet 4.6: 입력 토큰 백만당 약 $3, 출력 토큰 백만당 약 $15
• GPT-5.2: 입력 토큰 백만당 약 $10, 출력 토큰 백만당 약 $40
• Claude Haiku 4.5: 입력 토큰 백만당 약 $0.25, 출력 토큰 백만당 약 $1.25

일반적인 채팅 상호작용은 입력 토큰 1,000개와 출력 토큰 500개를 사용할 수 있다. Sonnet 4.6 가격으로 상호작용당 약 $0.003, 100번 상호작용에 $0.30. 관리 가능하다.

하지만 시스템에 큰 컨텍스트(긴 문서, 긴 대화 이력), 복잡한 추론 작업, 또는 많은 순차적 에이전트 단계가 포함되면 비용이 빠르게 배가된다. 항상 헌신하기 전에 숫자를 실행해봐라.

비용 제어 전략

프롬프트 압축: 짧은 프롬프트는 비용이 덜 든다. 불필요한 맥락을 제거해라. 긴 이력을 전부 전달하는 대신 요약해라. 절약되는 모든 토큰이 절약되는 돈이다.

모델 티어링: 단순한 작업은 저렴한 모델로, 복잡한 작업은 유능한 모델로 라우팅해라. Haiku에서 $0.001이 드는 분류 작업이 Opus에서 실행될 필요가 없다.

캐싱: 일반적인 응답을 캐시해라. 비싼 계산을 캐시해라. 반복적으로 요청되는 모든 것을 캐시해라.

배치 처리: 많은 API가 비실시간 요청에 50% 할인된 배치 가격을 제공한다. 사용 사례가 즉각적인 응답이 필요하지 않다면 모든 것을 배치 처리해라.

사용 한도: 사용자당 한도를 설정해라. 인색해서가 아니라, 단일 폭주 사용 패턴이 알아채기 전에 예상치 못한 비용을 만들 수 있기 때문이다.

---

4단계: 확장 아키텍처

100명의 사용자에게 작동하는 것이 10,000명에게는 종종 망가진다. AI가 달라서가 아니라, 주변 인프라가 부하를 위해 설계되지 않았기 때문이다.

상태 비저장 vs 상태 저장 설계

AI 상호작용은 가장 단순하게 상태 비저장으로 설계된다. 각 요청이 독립적이고, 필요한 모든 맥락을 포함하고, 이전 요청의 서버 측 상태에 의존하지 않는다. 상태 비저장 시스템은 수평으로 확장된다. 서버를 더 추가하면 더 많은 요청을 처리한다.

상태 저장 시스템, 즉 서버가 대화 이력, 사용자 맥락, 또는 진행 중인 에이전트 상태를 유지하는 시스템은 확장하기 어렵다. 상태 저장 AI 기능을 구축한다면 서버 메모리가 아닌 적절한 데이터베이스를 상태로 사용해라.

속도 제한은 친구다

모든 AI 제공자는 속도 제한을 시행한다. 분당 최대 요청 수. 낮은 사용량에서는 절대 도달하지 않는다. 프로덕션 규모에서는 도달할 수 있다.

속도 제한 오류를 우아하게 처리하도록 시스템을 설계해라:

• 한도 근처일 때 요청을 큐에 넣어라
• 지수 백오프를 구현해라 (1초 후 재시도, 그 다음 2초, 4초, 8초...)

프롬프트는 인프라다

프로덕션에서 프롬프트는 단순한 지시가 아니다. 코드다. 애플리케이션 코드와 마찬가지로 버전 제어, 테스팅, 배포 프로세스가 필요하다.

프롬프트를 변경할 때:

• 실제 입력의 대표 샘플에 대해 변경을 테스트해라
• 새 결과물을 이전 것과 비교해라
• 점진적으로 배포해라. 완전히 출시하기 전에 트래픽의 일부에서 A/B 테스트
• 무언가 잘못되면 즉시 롤백할 수 있어야 한다

프롬프트를 일회성 텍스트로 취급하고 프로덕션에서 무심코 변경하는 팀은 디버그하기 어려운 방식으로 것들을 망가뜨린다.

---

프로덕션 체크리스트

데모에서 프로덕션으로 이동하기 전에 이것을 검토하라:

신뢰성

• AI 결과물에 검증 레이어 있음
• AI 실패 시 우아한 폴백 있음
• 고위험 결과물에 인간 검토 있음
• 의미 있는 사용자 메시지로 오류 처리

성능

• 해당하는 곳에 스트리밍 응답 적용
• 응답 캐싱 전략 있음
• 다른 작업 복잡성에 모델 티어링 적용
• 레이턴시 목표 정의 및 테스트됨

비용

• 사용자당 월 비용 계산됨
• 목표 규모에서 마진 검증됨
• 비용/품질에 맞게 모델 선택 최적화됨
• 사용 한도 및 알림 설정됨

모니터링

• 레이턴시 모니터링 활성화
• 오류율 모니터링 활성화
• 알림과 함께 비용 모니터링 활성화
• 결과물 품질 샘플링 프로세스 정의됨

확장

• 상태 비저장 설계 검증됨
• 속도 제한 처리 구현됨
• 프롬프트 버전 제어 중
• 배포 및 롤백 프로세스 테스트됨

---

핵심만 짚자면

데모 사고방식과 프로덕션 사고방식은 근본적으로 다른 분야다. 데모는 최선의 경우를 보여준다. 프로덕션은 모든 경우를 처리한다. 처음부터 모든 경우를 위해 설계해라.

출시 전에 항상 파일럿을 해라. 실제 데이터로 실제 사용자 10-50명이 엄선된 입력으로 1,000시간의 테스트보다 프로덕션이 요구하는 것에 대해 더 많은 것을 가르쳐준다.

모델에 헌신하기 전에 비용을 계산하라. 사용자당 월 비용, 계획된 가격으로, 현실적인 사용량으로. 놀라운 청구서를 받은 후가 아닌 출시 전에 이 숫자를 실행해라.

출시 전에 모든 것을 계측해라. 레이턴시, 오류, 비용, 결과물 품질. 볼 수 없는 것을 고칠 수 없다. 모니터링을 나중에 추가하는 것은 고통스럽다. 미리 해라.

그리고 프롬프트를 지시가 아닌 인프라로 취급해라. 버전 제어, 테스팅, 점진적 배포, 롤백. 프로덕션에서 무심코 변경되는 프롬프트는 기다리고 있는 프로덕션 인시던트다.

---

더 깊이 배우고 싶다면

이 글은 프로덕션 라이프사이클을 다뤘다. 송재희의 AI Development Guide는 더 깊이 들어간다 — 다양한 유형의 AI 애플리케이션을 위한 특정 아키텍처 패턴, AI 결과물 품질을 위한 평가 프레임워크 구축 방법, 첫 번째 100명 사용자에서 첫 번째 10만 명으로 확장하는 방법 포함.

📱 Apple Books ▶️ Google Play Books 🌐 전 플랫폼 구매 (Books2Read)

---

다음 편: "리스크, 환각, 책임 있는 AI" — 모든 빌더가 AI의 실패 모드, 법적 노출, 그리고 설계에 의해 신뢰할 수 있는 시스템을 구축하는 방법에 대해 알아야 하는 것.