"PoC는 잘 끝났는데, 그다음이 없더라고요." 지난달 서울의 한 제조사 임원회의 뒤풀이 자리에서 들은 말이다. 회의실 화이트보드에는 파일럿 지표가 초록색으로 남아 있었고, 담당 팀장은 웃고 있었지만 눈은 조금 지쳐 있었다. 데모까지 8주, 그리고 그 뒤로 다섯 달째 아무도 그 도구를 쓰지 않는다고 했다.
이 시리즈를 시작할 때 이야기했던 문제로 다시 돌아온 셈이다. 지난 회에서 다룬 실패 5대 패턴이 왜 반복되는가. 대부분은 기술이 부족해서가 아니라, 어느 지점에서 어떤 산출물을 남겨야 하는지 합의가 없기 때문이다. 8편에 걸쳐 짚어온 이야기의 매듭을 지금 짓는다. 개념·유형에서 시작해 ROI·스택·비용·보안·실패패턴까지 살펴봤다면, 마지막 남은 질문은 하나다. "그래서 월요일부터 무엇을 어떻게 시작하는가."
왜 87%는 프로덕션에 못 가는가
Gartner는 2024년 조사에서 AI 프로젝트의 87%가 프로덕션에 도달하지 못한다고 보고했다. S&P Global의 2025년 자료를 보면 프로토타입에서 프로덕션까지 평균 8개월이 걸리고, 결국 도달하는 비율은 48% 수준이다. 87%라는 숫자는 무섭게 들리지만, 뒤집어 읽으면 이렇다. 진짜 어려운 구간은 모델을 붙이는 8주가 아니라 그다음 5~6개월이라는 것.
같은 시기 Gartner는 조금 다른 각도의 숫자도 내놓았다. 생성형 AI 프로젝트의 30%가 PoC 이후 폐기되며, 주된 이유는 거버넌스 부재와 불명확한 ROI다. 반대로 구조화된 파일럿 절차를 거친 조직은 12개월 안에 ROI를 보고할 확률이 2.5배 높다는 관찰도 있다. 결국 성패는 "모델을 얼마나 잘 튜닝했나"가 아니라 "단계를 얼마나 잘 설계했나"에서 갈린다.
솔직히 말하면, 처음 이 시장에 들어왔을 때는 그 반대라고 생각했다. 좋은 모델과 좋은 데이터만 있으면 나머지는 자연스럽게 붙을 줄 알았다. 실제로는 그 "자연스러운 붙음"이라는 부분이 프로젝트 예산의 절반을 먹는다.
단계 0 — 시작 전에 정해둘 세 가지
업계에서는 최근 이 구간을 "Phase 0"이라 부른다. PoC를 시작하기 전에 세 가지를 문서로 못박아 두는 팀이 pilot purgatory를 벗어난다는 관찰이다. 평가 기준, 배포 파이프라인, 거버넌스 승인 라인. 반대로 "일단 가장 멋진 데모부터 만들고 하드닝은 나중에"를 택한 팀은 대부분 5개월째에 멈춘다.
실무적으로는 반나절짜리 워크숍 한 번이면 충분하다. 이 도구가 성공했다고 판단할 정량 지표는 무엇인가. 프로덕션에 올릴 때 어떤 파이프라인을 통과해야 하는가. 개인정보·기밀문서가 걸릴 때 누가 최종 승인하는가. 이 세 문장에 답이 없다면 아직 PoC를 시작할 준비가 안 된 것이다. 3회에서 다룬 ROI·KPI 설계와 6회의 보안·거버넌스가 여기서 합쳐진다.
단계 1 — 진단 (2~3주)
진단은 회의실에서 시작하지만 답은 늘 현장에 있다. 우리가 클라이언트와 하는 진단은 세 트랙으로 병행한다. 업무 트랙에서는 팀별로 하루에 시간이 얼마나 어디에 녹는지, 반복 작업이 몇 건인지 관찰한다. 데이터 트랙에서는 사내 문서·티켓·매뉴얼이 어디에 어떤 포맷으로 흩어져 있는지 지도를 그린다. 시스템 트랙에서는 접근 권한 체계와 감사 로그가 지금 어디까지 준비돼 있는지 확인한다.
이 단계의 산출물은 딱 두 개면 된다. 하나는 후보 유스케이스 3~5개에 각각 예상 절감 시간과 리스크를 붙인 표, 다른 하나는 첫 번째 파일럿 대상 하나에 대한 성공 정의 한 문단. 30건짜리 문서 산출물은 오히려 위험 신호다. 무엇이 중요한지 결정하지 못했다는 뜻이기 때문이다.
단계 2 — PoC (6~8주)
업계 컨센서스로 잘 짜인 내부용 도구는 8~12주면 프로덕션 준비까지 갈 수 있다. 이 중 앞의 6~8주가 PoC 구간이다. 2회에서 비교한 RAG·파인튜닝·프롬프트 중 어느 조합으로 갈지는 진단에서 이미 결정돼 있어야 한다. 이 단계에서 새로 아키텍처를 뒤엎는 팀은 대개 프로덕션에 못 간다.
PoC 종료 조건은 데모 성공이 아니라 세 가지 답이다. 첫째, 진단에서 정의한 KPI를 실제 사용자 20~30명이 2주간 돌렸을 때 얼마나 움직였는가. 둘째, 그 과정에서 나온 오답·환각·권한 이슈를 어떻게 로깅하고 분류했는가. 셋째, 다음 단계로 넘어가는 데 필요한 예산·인력·거버넌스 승인이 확보됐는가. 이 세 문장에 답이 없으면 PoC를 연장하기보다 종료하고 재설계하는 편이 낫다.
단계 3 — 본구축 (2~3개월)
본구축에서 가장 자주 무너지는 부분은 놀랍게도 모델이 아니라 접점이다. 사내 SSO, 문서 저장소, 티켓 시스템, 감사 로그 서버, 알림 채널. 이 다섯 군데를 어느 하나 빠뜨리면 배포 후 3주 안에 사용자 이탈이 시작된다. 헬로티가 2026년 관찰한 국내 사례에서도 "PoC는 성공했는데 왜 아무도 안 쓸까"의 답은 대부분 이 다섯 접점 중 하나에 있었다.
이 구간의 산출물은 세 가지다. 프로덕션 파이프라인(모델 배포·롤백·A/B), 운영 대시보드(응답 품질·비용·사용량·거절률), 사용자 온보딩 자료(2쪽 이내 가이드와 30분 세션). 세 번째를 가볍게 봤다가 낭패 본 팀을 여럿 봤다. 좋은 도구도 첫 30분에 좌절하면 다시 안 열린다.
단계 4 — 운영·추가개발 (지속)
Presenc AI의 2026년 6월 보고를 보면 대형 기업의 85~90%가 이미 최소 한 개의 프로덕션 LLM을 굴리고 있다. 1년 전 65%에서 껑충 뛰었다. 이 숫자가 의미하는 바는 명확하다. "도입 여부"는 이미 끝난 논쟁이고, 앞으로 3년의 경쟁은 "운영을 얼마나 잘 굴리는가"에서 갈린다.
운영 단계는 크게 세 개의 리듬으로 굴러간다. 매주 리듬에서는 사용량·거절률·품질 스코어를 본다. 매월 리듬에서는 5회에서 다룬 비용 구조를 실제 청구서와 대조하고, 프롬프트·검색 인덱스·문서 신선도를 점검한다. 분기 리듬에서는 유스케이스를 재평가하고, 새로 붙일 부서·업무를 결정한다. 이 리듬을 팀 내부에 이식하지 못한 채 파트너에게만 맡겨두면 6개월 안에 도구가 화석이 된다.
파트너를 고를 때 물어봐야 할 다섯 문장
진단부터 운영까지 전 구간을 함께 갈 파트너를 고를 때 실무자가 물어봐야 할 질문은 다섯 개다. 이 다섯 개에 구체적으로 답하지 못하면 데모가 아무리 좋아도 재고할 필요가 있다.
- 운영 6개월째의 SLA와 응답 절차를 계약서에 어떻게 쓰는가
- 모델 업데이트·프롬프트 변경·문서 신선도 관리의 책임 분담은 어떻게 되는가
- 내부 인력에게 운영을 이관하는 로드맵과 산출 문서는 무엇인가
- 실패했을 때의 롤백·데이터 삭제·감사 로그 보존 절차는 어떻게 되는가
- 다음 유스케이스로 확장할 때의 재사용 가능한 자산(파이프라인·평가셋·거버넌스 문서)이 남는가
다섯 번째 질문이 특히 중요하다. 좋은 파트너는 프로젝트가 끝나도 조직 안에 근육을 남긴다. 나쁜 파트너는 자기가 없으면 아무것도 못 돌아가게 만든다.
매듭 — 8편의 이야기를 한 장으로
여기까지 8편이었다. 1회에서 다룬 자사 데이터 LLM의 개념과 유형에서 시작해 방식·ROI·스택·비용·보안·실패패턴을 지나 오늘의 실행 플랜에 도착했다. 8편을 따라오신 분이라면 이제 하나가 분명해졌을 것이다. 자사 LLM은 "기술 도입 프로젝트"가 아니라 "조직의 새로운 근육을 만드는 일"이라는 사실.
30%가 PoC에서 폐기되고 87%가 프로덕션에 못 가는 시장에서, 반대편의 소수에 서기 위한 조건은 화려한 모델이 아니라 진단·PoC·본구축·운영의 네 단계를 지루할 만큼 성실하게 밟는 일이다. 8주 만에 데모가 끝났다고 축배를 들 것이 아니라, 그 데모가 6개월 뒤에도 매일 열리고 있는지를 물어야 한다.
저희 5years+는 한국·일본의 중견·중소기업을 대상으로 진단부터 운영까지 전 구간을 함께 굴러온 팀입니다. 자사에 맞는 도입 로드맵이 필요하시다면 도입 로드맵 무료 설계 상담에서 현재 상황을 편하게 말씀 주십시오. 시리즈는 여기서 매듭짓지만, 실제 실행은 지금부터 시작입니다.