AI 프로젝트가 지연되는 이유: 데모와 프로덕션 사이의 간극

대부분의 AI 프로젝트가 일정을 맞추지 못하는 이유는 한 가지입니다. 데모가 문제의 쉬운 20%를 증명했고, 모든 사람이 마치 그것이 전체 작업인 것처럼 일정을 계획했기 때문입니다. 해결책은 날짜를 약속하기 전에 지루한 80%(데이터, 통합, 평가 (evals), 엣지 케이스 (edge cases))의 범위를 정하고, 고객에게 "완료"를 위해 실제로 무엇이 필요한지 말하는 것입니다.

저는 생업으로 딜리버리 (delivery)를 운영하고 있습니다. 저는 완벽했던 금요일의 데모가 3개월간의 고된 작업으로 변하는 것을 목격해 왔으며, 이는 거의 항상 동일한 계획 실수로 거슬러 올라갑니다. 그러니 시간이 실제로 어디에 소요되는지, 그리고 제가 현재 어떻게 그 주변 범위를 설정하는지 설명해 보겠습니다.

데모는 신뢰성이 아닌 역량의 측정치입니다

데모는 누군가가 엄선한 입력값으로 실행됩니다. 데이터는 깨끗하고, 사용자는 협조적이며, 해피 패스 (happy path)가 유일한 경로입니다. 이것은 속임수가 아닙니다. 그것이 데모의 목적입니다. 하지만 이는 실제 시스템을 어렵게 만드는 모든 조건을 제거하며, 바로 이 점 때문에 작동하는 프로토타입 (prototype)이 인도 날짜에 대해 거의 아무것도 알려주지 않는 것입니다.

이 패턴은 업계 전반에 걸쳐 유지됩니다. 다듬어진 파일럿 (pilot)은 6~~12주 동안 실행되지만, 그 뒤에 따르는 프로덕션 배포 (production deployment)는 6~~12개월 동안 실행됩니다. 대부분의 AI 실패는 모델 자체보다는 조직적이고 운영적인 문제에서 발생합니다. 데모 타임라인이 출시까지 이어진다고 가정하는 계획을 읽을 때, 저는 프로젝트가 시작되기도 전에 어디서 지연이 발생할지 알 수 있습니다.

시간이 실제로 소요되는 곳

실제 AI 구축을 분석할 때, 모델 작업은 케이크가 아니라 한 조각일 뿐입니다. 시간은 다음 항목들에 숨어 있습니다:

아무도 문서화하지 않은 시스템과의 통합 (Integration). 레거시 인터페이스 (Legacy interfaces), 머신 액세스를 고려하여 설계되지 않은 인증 (Auth), 12년 동안 일관성 없이 쌓인 데이터가 있는 CRM 등이 여기에 해당합니다. 팀들은 에이전트 (Agent) 개발이 아니라, 커넥터 (Connectors)를 만드는 데 구축 시간의 대부분을 일상적으로 소비합니다.
데이터 준비도 (Data readiness). 데이터를 정제 (Cleaning), 구조화 (Structuring), 거버넌스 (Governing) 하는 것은 실제 엔지니어링이며, 계획했든 그렇지 않든 일정에 포함됩니다. 많은 프로젝트가 이 단계에서 정체됩니다.
평가 (Evals). 완료되었음을 측정할 수 있기 전까지는 기능이 완료되었다고 말할 수 없습니다. 그 측정 체계를 구축하는 것 자체가 그 자체로 하나의 산출물 (Deliverable) 입니다.
매력적이지 않은 엣지 케이스 (Edge cases). 깔끔하지 않은 20%의 입력값들은 에이전트가 작은 오류들을 누적시켜 고객이 보게 될 잘못된 답변을 만들어내는 지점입니다.

이 중 어느 것도 데모 (Demo)에서는 나타나지 않습니다. 하지만 이 모든 것들은 번다운 차트 (Burndown)에는 나타납니다.

현재 제가 범위를 산정하는 방식

저는 데모를 기준으로 추정하는 것을 그만두었습니다. 저는 프로덕션 요구사항 (Production requirements)을 기준으로 추정하며, 누군가 프로토타입 (Prototype)을 작성하기 전에 이를 정의합니다. 이는 저희 Shanti Infosoft에서 The AI demo works. That's the problem. 라고 주장하는 내용과 일치합니다. 즉, 프로덕션에 무엇이 필요한지 먼저 정의한 다음, 그것을 향해 구축해 나가는 것입니다.

날짜를 확정하기 전 저의 범위 산정 (Scoping) 체크리스트는 다음과 같습니다:

실제 입력 분포 (Input distribution)는 무엇인가? 데모의 예시 3개가 아니라, 지저분한 1,000개의 데이터입니다.
이것이 어떤 시스템과 접촉하며, 상대측의 통합 (Integration) 담당자는 누구인가? 문서화되지 않은 인터페이스는 제 추정치에 완충 시간 (Buffer)이 필요한 가장 흔한 이유입니다.
작동 여부를 어떻게 알 수 있는가? 수락 테스트 (Acceptance test)를 작성할 수 없다면, 그 기능은 범위가 산정된 것이 아니라 그저 희망 사항일 뿐입니다.
모델이 틀렸을 때 어떤 일이 발생하는가? 인간 참여 (Human in the loop), 폴백 (Fallback), 신뢰도 임계값 (Confidence threshold) 등이 필요합니다. 이것은 설계 작업이며 시간이 소요됩니다.
출시 후 누가 이것을 운영하는가? 모니터링 (Monitoring)과 소유권 (Ownership)은 2단계에서 생각할 사후 과제가 아니라, "완료"의 일부입니다.

그다음 저는 위험이 가장 높은 부분, 대개 통합 (Integration) 및 데이터 (Data) 단계에 버퍼 (Buffer)를 추가하고, 이를 숨기기보다는 고객에게 명시적으로 보여줍니다. 버퍼가 없는 일정은 낙관적인 것이 아닙니다. 그것은 잘못된 것이며, 모두가 최악의 시점에 그 사실을 깨닫게 됩니다.

핵심 요약 (Key takeaways)

데모는 이상적인 조건에서의 역량을 증명합니다. 데모가 실제 인도 날짜를 예측해주지는 않습니다.
데모에서 생략되는 80%를 계획하십시오: 통합 (Integration), 데이터 준비도 (Data readiness), 평가 (Evals), 엣지 케이스 (Edge-case) 처리, 그리고 운영 (Operations)입니다.
파일럿 (Pilot)은 몇 주 단위이지만, 프로덕션 (Production)은 몇 달 단위입니다. 프로토타입 (Prototype)이 아니라 프로덕션 요구사항을 기준으로 추정하십시오.
수락 테스트 (Acceptance test)를 작성할 수 없다면, 해당 기능의 범위 (Scope)가 아직 정해지지 않은 것입니다.
위험이 존재하는 곳에 버퍼를 배치하고, 왜 그곳에 버퍼가 필요한지 고객에게 보여주십시오.

자주 묻는 질문 (FAQ)

실제 AI 프로젝트는 얼마나 걸리나요? 통합 및 데이터의 복잡성에 따라 다르지만, 솔직하게 말하자면 6주 만에 완성된 파일럿이라도 프로덕션 수준의 경화 (Hardening) 작업에는 여전히 몇 달이 필요할 수 있습니다. 경화 작업을 나중에 발견하게 두지 말고, 명시적으로 범위 (Scope)에 포함하십시오.

왜 AI 추정치는 자주 틀리나요? 데모에 닻을 내리기 (Anchored) 때문입니다. 데모는 의도적으로 까다로운 조건들을 제거한 상태이므로, 데모를 기준으로 추정하면 실제로 일정을 잡아먹는 작업들을 건너뛰게 됩니다.

AI 타임라인의 리스크를 줄이는 가장 좋은 방법은 무엇인가요? 프로토타입을 만들기 전에 프로덕션에서