PoC에서 높았던 정확도가 운영에서 급락하는 5가지 원인과, PoC 단계에서 미리 검증할 수 있는 체크리스트를 제시한다.
PoC 데모 당일, 경영진 앞에서 92%가 찍혔다. 금융사 고객 문의 Agent — 의도 분류 정확도였다. 다양한 질문 유형을 포함시켰다고 생각했다. 예산이 승인됐다. 3개월 뒤 운영에 올렸다. 하루 1,000건의 실제 민원이 들어왔고, 정확도는 64%였다. 테스트 환경에서 만든 '다양성'과 실제 민원의 표현 복잡도는 완전히 다른 세계였다.
이건 이 팀만의 실수가 아니다. IDC가 2025년 발표한 조사에 따르면, AI PoC의 88%가 실제 운영 단계에 진입하지 못한다[1]. 33개의 PoC를 진행했을 때 운영까지 가는 것은 단 4개다. Forrester는 더 가혹하다 — 지속적인 운영으로 이어지는 AI 프로젝트는 10~15%에 불과하다[2]. 매번 같은 이유로 터진다.
왜 이런 일이 생기는가? "PoC 환경과 운영 환경이 다르다"는 답변은 맞지만 쓸모가 없다. 어디가, 왜, 얼마나 다른지를 알아야 막을 수 있다.
이 글에서 인용하는 92%, 64%는 실제 산업 데이터와 연구를 조합해 재구성한 수치다.
핵심부터 말하면: 운영 정확도는 모델 정확도가 아니라 시스템 정확도다. PoC에서 측정한 것은 모델의 능력이었다. 운영에서 무너지는 것은 시스템의 구조다.
PoC는 고정된 데이터셋에서 끝나지만, 운영은 사용자 피드백이 시스템을 실시간으로 바꿔야 하는 학습의 시작이다. 이 구조 없이 진입하면 정확도는 최초 배포 시점에서 더 이상 개선되지 않는다.
5개 레이어에서 동시에 발생하며, 각각 다른 대응이 필요하다.
PoC에서는 "대표적인 100건"으로 테스트한다. 운영에서는 하루 1,000건의 실제 요청이 들어온다. Microsoft Research가 대형 클라우드 공급사 2곳의 실제 배포를 분석한 결과, 데이터 분포 변화(data drift — 실제 입력이 테스트 데이터와 점점 달라지는 현상)는 프로덕션 ML 모델의 정확도를 최대 40% 떨어뜨렸다[3]. 빈번한 재학습을 해도 분포 변화 자체를 막지 못했다.
금융사 고객 문의 Agent 예시: PoC에서는 "계좌 잔액 조회", "이체 한도 확인" 같은 정형 질문으로 테스트했다. 운영에서 들어온 것은 "어제 새벽에 모르는 사람한테 돈이 나갔는데 이거 보이스피싱인가요 아닌가요 환불되나요" 같은 복합 질문이었다. 하나의 요청 안에 상황 설명 + 분류 요청 + 조치 요청이 섞여 있다. PoC 테스트셋에 없던 유형이다.
PoC는 의도적으로 edge case(예외 상황 — 테스트 시 상정하지 않은 입력)를 배제한다. 더 정확히 말하면 PoC 시점에는 edge case가 뭔지 모른다. 운영 2주가 지나야 비로소 "이런 것도 들어오는구나"를 알게 된다.
Zillow Offers가 대표적인 사례다. 주택 가격 예측 AI는 정상적인 데이터에서는 잘 작동했다. 운영에서 팬데믹 기간 급등장이라는 edge case가 터졌다. 주택 매입 과잉 → 5억 달러 이상 손실 → 사업 폐쇄[4]. PoC 테스트셋에는 없던 시나리오였다.
이 edge case들이 전체 정확도를 끌어내린다. 나머지 정상 요청에서는 여전히 90% 이상의 정확도가 나오기 때문에, 평균 지표만 보면 "왜 갑자기 떨어졌지?"가 된다. 특히 RAG 기반 시스템(검색해서 답변을 생성하는 구조)은 검색 실패가 곧 답변 실패로 이어지기 때문에, edge case의 영향이 더 빠르게 나타난다.
PoC는 순차적으로 한 건씩 처리한다. 운영에서는 동시에 50건, 100건이 들어온다. Stateful Agent(대화 맥락을 기억하는 Agent)의 경우, 동시 요청이 같은 context window(AI가 한 번에 처리하는 대화 공간)를 공유하면 state(각 사용자의 대화 상태)가 오염된다.
arXiv 연구에 따르면, LLM의 context 길이가 100K 토큰에 도달하면 에이전트 성능이 50% 이상 저하된다[5]. AugmentCode가 자사 에이전트 시스템 버그를 분석한 결과, 발생한 버그의 70% 이상이 상태 관리 문제로 추적됐다[6].
예를 들어, 보험 문의와 대출 문의가 같은 세션에 섞이면, Agent는 첫 번째 고객의 보험 정보로 두 번째 고객의 대출 질문에 답변한다. PoC에서는 동시 요청이 없었기 때문에 발견되지 않은 버그다.
PoC에서 Agent가 호출하는 API는 테스트 서버다. 응답 시간 50ms, 가용률 100%. 운영에서 Agent가 호출하는 것은 레거시 시스템이다. 응답 시간 2~5초, 간헐적 timeout, 주말 배치 작업 중 불가.
Tool call(Agent가 외부 API를 호출해 정보를 가져오는 동작)의 지연이 길어지면 두 가지 일이 벌어진다. 첫째, 사용자가 이탈한다. 연구에 따르면 고객의 2/3가 AI 응답을 2분 이상 기다리지 않는다[7]. LLM 애플리케이션에서는 총 응답 시간보다 TTFT(첫 번째 토큰 생성 시간 — 사용자가 첫 글자를 보기까지 걸리는 시간)이 더 중요하다. 스트리밍이 없으면 레거시 연동의 지연이 그대로 사용자 대기 시간이 되고, 이탈로 이어진다[8]. 둘째, 이탈한 사용자의 요청은 피드백 데이터에서 사라진다. 모델은 완료된 요청만 학습하게 되고, 분포가 서서히 왜곡된다. 지연은 단순한 UX 문제가 아니라 정확도 하락의 숨은 원인이다.
PoC에서 테스터는 Agent가 이해할 수 있는 방식으로 질문한다. 실제 사용자는 그렇지 않다.
이런 행동 패턴은 PoC에서는 발생하지 않는다. 그리고 이것들이 정확도를 두 자릿수 이상 떨어뜨리는 주요 변수가 된다.
"의도적 실패 테스트"는 맞는 방향이지만, 각 레이어별로 검증 항목이 다르다:
입력 분포 변화
Edge case
State 충돌
연동 불안정
사용자 행동
이 5가지를 PoC 단계에서 검증하지 않으면, 운영 전환 후 3개월 안에 "이거 왜 이러지?"가 시작된다.
플랫폼 도구에 대해: Azure, Google Vertex AI, AWS SageMaker는 drift detection을 제공한다. 그러나 이 도구들은 "문제가 생겼다"를 감지할 뿐이다. 왜 생겼는지, 시스템 어느 레이어를 어떻게 바꿔야 하는지는 설계 단계에서 결정된다. 플랫폼과 시스템 설계는 서로를 대체할 수 없다.
위 검증을 모두 수행하면 PoC 기간이 2~3개월 늘어난다. PoC를 빨리 끝내라는 경영진의 압박과, 운영에서 터지지 않으려는 기술팀의 필요 사이에 충돌이 발생한다.
McKinsey 분석에 따르면, 파일럿 단계를 넘어 전사 스케일에 성공하는 AI 프로젝트는 10% 미만이다[9]. 나머지 90%는 PoC 단계에서 "작동한다"고 판단했지만 스케일링에서 실패했다. 4주를 더 쓰는 것이 운영 6개월 후 전면 재작업보다 저렴하다. 정확도가 흔들리면 재시도 호출과 휴먼 개입이 늘어나고, 비용은 지수적으로 증가한다.
현실적 타협안: 2단계 PoC를 제안한다.
Phase 1만으로 운영 결정을 내리면, IDC가 말한 "PoC의 88%는 운영에 도달하지 못한다"는 통계의 나머지 88%에 포함된다[1].
이 글에서 다룬 5가지 리스크 — 입력 분포 변화, edge case 폭발, state 충돌,
연동 불안정, 사용자 행동 예측 불가 — 는 플랫폼 선택만으로 해결되지 않는다.
하지만 플랫폼이 이 리스크를 감지하고 대응하는 구조를 갖추고 있는지는
도입 전에 반드시 확인해야 한다.
체크리스트: 플랫폼에 물어볼 5가지 질문
리스크 레이어 / 플랫폼에 확인할 질문
Alli는 이 5가지를 어떻게 풀고 있을까?
엔터프라이즈 환경에서의 구체적인 접근 방식이 궁금하다면 →
