AI 프로젝트 체크리스트: 발주 전 실패 막는 7가지 점검 항목 (2026)

AI 프로젝트 실패의 상당수는 개발이 아니라 착수 전에 결정된다. 문제 정의·데이터 준비·요구사항 명세·업체 선정·중간 점검·보안·운영비까지 반복되는 7가지 실패 패턴을, 계약서에 서명하기 전 스스로 던져야 할 발주자 관점의 AI 프로젝트 체크리스트 질문으로 뒤집어 정리했다.

AI 도입을 결정한 기업이 가장 먼저 검색하는 것 중 하나가 'AI 프로젝트 체크리스트'다. 그런데 막상 손에 잡히는 체크리스트 대부분은 개발이 시작된 뒤의 진행 관리 항목에 머문다. 정작 프로젝트의 성패는 코드 한 줄 쓰기 전, 발주사가 무엇을 정의하고 무엇을 준비했느냐에서 갈린다. 현장에서 실패로 기록된 AI 프로젝트를 거꾸로 되짚어 보면 공통점은 기술이 아니라, 착수 전에 빠뜨린 몇 개의 점검 항목에 있다. 이 글은 반복되는 실패 패턴 7가지를 발주자 관점의 AI 프로젝트 체크리스트로 뒤집어 정리한다.

AI 프로젝트는 왜 개발이 아니라 착수 전에 실패하는가

Gartner는 생성형 AI 프로젝트의 최소 30%가 PoC(개념 증명) 단계 이후 폐기될 것으로 전망한 바 있다(Gartner 보도자료, 2024-07-29). 이후 실제 폐기율은 그 전망을 웃도는 것으로 보고되고 있다. 주목할 점은 중단의 원인이 대부분 모델 성능이 아니라는 것이다. 실패한 프로젝트를 해부해 보면 알고리즘이 부족했던 경우보다, 애초에 무엇을 만들지 합의되지 않았거나 학습할 데이터가 없었거나 발주사와 개발사가 서로 다른 그림을 그리고 있던 경우가 압도적으로 많다.

Gartner가 꼽은 폐기 사유도 데이터 품질 부족, 리스크 통제 미비, 비용 급증, 불명확한 사업 가치였다. 넷 다 모델 성능이 아니라 착수 전 준비의 문제다. 즉 AI 프로젝트 실패의 상당수는 기술 문제가 아니라 기획·데이터·소통 문제이며, 이 세 가지는 모두 개발 착수 이전 단계에 속한다. 그래서 정말 필요한 것은 진척률을 관리하는 도구가 아니라, 계약서에 서명하기 전에 스스로 던져야 할 AI 프로젝트 착수 전 준비사항 목록이다.

실제로 한 중견 제조기업은 '고객 상담 데이터를 학습한 AI 챗봇'을 목표로 외주를 맡겼지만, 착수 뒤에야 상담 기록이 통화 녹취뿐이고 텍스트화된 데이터가 존재하지 않는다는 사실이 드러났다. 데이터를 확보하고 정제하는 데만 두 달이 추가로 들면서 프로젝트는 PoC 문턱에서 멈췄다. 모델이 부족했던 것이 아니라, 착수 전에 학습 데이터의 존재 여부를 확인하지 않은 것이 실패의 진짜 원인이었다. 아래 7가지는 이처럼 반복적으로 관찰되는 실패 패턴을, 발주사가 계약 전에 먼저 확인할 수 있는 질문으로 바꾼 것이다.

현장에서 반복되는 7가지 실패 패턴은 무엇인가

1. 문제 정의 없이 "AI를 한번 써보자"로 시작한다

가장 흔한 첫 단추다. "일단 AI를 도입해야 한다"는 조급함에서 출발한 프로젝트는 정작 어떤 문제를 풀지 정하지 못한 채 예산부터 잡는다. 목표가 흐리면 성공의 기준도 없어, 무엇을 만들어도 "이게 맞나"라는 질문이 끝나지 않는다.

> 점검 질문: 이 AI가 해결할 문제를 한 문장으로 정의했는가? "무엇을, 얼마나, 어떻게 개선하면 성공"인지 숫자로 말할 수 있는가?

2. 데이터를 준비하지 않은 채 개발에 들어간다

두 번째 패턴은 데이터다. AI는 데이터로 학습하거나 데이터를 검색해 답하는데, 정작 그 데이터가 존재하지 않거나 흩어져 있거나 품질이 낮은 상태에서 개발이 시작된다. 중복 문서, 버전이 뒤섞인 매뉴얼, 표가 깨진 PDF를 그대로 넣으면 아무리 좋은 모델도 엉뚱한 답을 내놓는다.

> 점검 질문: 학습·검색에 쓸 데이터가 실제로 존재하는가? 누가 정제 책임을 지고, 최신 정본과 폐기본을 어떻게 구분하는가?

3. "ChatGPT처럼 만들어 주세요"라고 요구한다

요구사항 명세 부재의 전형이다. 참조 제품 이름만 던지고 세부 사양을 개발사에 위임하면, 발주사가 상상한 결과물과 실제 납품물 사이에 간극이 벌어진다. 이 간극은 대개 프로젝트 후반, 되돌리기 어려운 시점에 드러난다.

> 점검 질문: 입력·출력·예외 처리·성공 기준을 문서로 적었는가? 이것이 곧 AI 외주 요구사항 정의서 작성법의 출발점이다.

4. 가격표만 보고 업체를 고른다

견적서의 총액만 비교하는 순간 함정이 시작된다. 같은 금액이라도 유사 도메인 경험이 있는 팀과 처음 해보는 팀, 계약서에 적힌 인력이 실제로 투입되는 팀과 이름만 빌려주는 팀은 결과가 전혀 다르다. 특히 'AI 개발'과 일반 웹·앱 개발을 구분하지 못하는 업체는, 화면은 그럴듯하게 만들어도 모델의 정답률과 데이터 파이프라인에서 무너진다.

> 점검 질문: 유사한 AI 프로젝트 레퍼런스가 있는가? 계약서의 핵심 인력이 실제로 투입되며, AI 성능을 책임지는 담당자가 명시돼 있는가?

5. 중간 점검 없이 최종물을 기다린다

착수 후 최종 납품일까지 통째로 맡기는 방식은 리스크를 마지막 날로 몰아넣는다. 방향이 어긋나 있어도 확인할 지점이 없어, 문제를 발견했을 때는 이미 재작업 비용이 커진 뒤다. AI 프로젝트는 특히 데이터를 넣어 보기 전에는 성능을 장담하기 어렵기 때문에, 2~4주 단위로 실제 데이터에서 정답률을 확인하며 방향을 조정하는 반복 검수가 일반 개발보다 더 중요하다.

> 점검 질문: 2~4주 단위로 중간 산출물을 검수하는 일정과, 기준 미달 시 보완 절차가 계약에 명시돼 있는가?

6. 보안·개인정보를 후순위로 미룬다

"일단 만들고 나중에"라는 접근은 AI에서 특히 위험하다. 사내 문서와 고객 데이터가 외부 모델 학습에 흘러들거나 접근 권한이 열려 있으면, 완성도와 무관하게 프로젝트 전체가 무효가 된다.

> 점검 질문: 데이터 격리(온프레미스·VPC), 외부 학습 비사용, 접근 권한 분리가 계약 조항으로 담겼는가?

7. 출시 후 운영 비용을 계산하지 않는다

마지막 패턴은 계약서에서 가장 자주 누락되는 항목이다. LLM API 호출료, 벡터DB, 인프라를 합친 운영비는 트래픽에 따라 월 100만~500만 원 선이며, 대고객 서비스는 이를 넘기기도 한다. 초기 구축비만 비교하면 도입 6개월 뒤 예상 밖의 청구서를 마주한다.

> 점검 질문: 12개월 운영비(API·인프라·유지보수)를 초기 견적과 함께 받았는가?

착수 전 체크리스트를 요구사항 정의서로 옮기는 법

7가지 점검 질문은 머릿속에만 두면 힘을 잃는다. 실무에서 이것을 실제로 작동시키는 방법은, 각 항목을 한 장의 문서로 옮겨 계약서에 첨부하는 것이다. 이렇게 정리한 문서가 곧 AI 개발 외주 프로젝트 체크리스트이자, 발주사와 개발사가 같은 그림을 공유하는 요구사항 정의서가 된다.

점검 축	정의서에 명시할 항목

문제 정의	해결할 과제, 성공 지표(숫자), 대상 사용자
데이터	데이터 소재·품질·정제 책임 주체
요구사항	입력·출력 명세, 성능 기준(정답률·응답속도)
업체·인력	레퍼런스, 투입 인력, 산출물 일정
보안	데이터 격리·권한·외부 학습 비사용
운영	12개월 운영비, 유지보수 범위

이 표의 오른쪽 칸이 채워지지 않은 상태로 시작하는 프로젝트일수록, 착수 이후 "그건 계약에 없었다"는 분쟁이 반복된다. 반대로 발주 전에 여섯 축을 문서로 합의해 두면 업체 선택과 비용 협상의 주도권이 발주사 쪽으로 넘어온다.

좋은 AI 프로젝트는 착수 전에 결정된다

AI 프로젝트의 성패는 개발이 시작된 뒤가 아니라 계약서에 서명하기 전에 대부분 정해진다. 문제 정의, 데이터 준비, 요구사항 명세, 업체 선정, 중간 점검, 보안, 운영비 — 이 일곱 축을 담은 AI 프로젝트 체크리스트를 발주사가 먼저 이해하고 질문할 때, 많은 프로젝트가 주저앉는 PoC 단계를 넘어설 확률이 비로소 올라간다.

각 실패 패턴의 구체적 사례와 예방법은 treesoop.com의 AI 프로젝트 실패 7가지 이유 가이드에서, 계약 단계에서 확인할 조항은 AI 개발사 계약 전 체크리스트에서 더 깊이 확인할 수 있다. 좋은 AI 프로젝트는 좋은 질문에서 시작된다.

자주 묻는 질문

Q. 데이터가 아직 정리되지 않았는데 외주를 맡겨도 되나요?

맡길 수 있습니다. 다만 데이터 정제를 계약 범위에 명시적으로 넣어야 합니다. 정제 공수를 빼고 견적을 받으면 착수 후에 반드시 추가 비용 협상이 생깁니다. 데이터 상태를 모르겠다면 사전 분석을 별도 계약으로 짧게 끊는 방법도 있습니다.

Q. PoC와 본개발을 한 계약으로 묶는 게 좋나요, 나누는 게 좋나요?

나누는 편이 발주사에 유리한 경우가 많습니다. PoC 결과가 기대에 못 미쳤을 때 빠져나갈 지점이 생기기 때문입니다. 대신 PoC 성공 기준을 숫자로 미리 못 박아야 판단이 가능합니다.

Q. 성공 기준을 숫자로 정하기 어려운 과제는 어떻게 하나요?

정답률 같은 단일 지표가 어렵다면 대체 지표를 씁니다. 처리 시간 단축률, 사람이 재작업한 비율, 응답까지 걸린 시간 같은 운영 지표가 현실적입니다. 중요한 건 완벽한 지표가 아니라 합의된 지표입니다.

Q. 12개월 운영비를 개발사가 미리 산정해 줄 수 있나요?

트래픽 가정을 함께 주면 가능합니다. 월 예상 호출량, 문서 규모, 동시 사용자 수를 전제로 범위를 받아 두세요. 전제 없이 받은 운영비 견적은 나중에 무의미해집니다.

Q. 중간 검수를 2~4주 단위로 하면 일정이 늘어나지 않나요?

전체 일정은 오히려 줄어드는 경우가 많습니다. 방향이 어긋난 채 최종 납품까지 간 뒤의 재작업 비용이 중간 검수 공수보다 훨씬 크기 때문입니다.

AI 프로젝트 착수를 앞두고 일곱 축 중 무엇이 비어 있는지 판단이 서지 않는다면 나무숲에 편하게 문의해 주세요.