지난 1년간 'AI PoC 했다가 본 프로젝트로 못 넘어갔다'는 회사를 여럿 봤습니다. 공통점이 하나 있었습니다. 기술이 부족해서 실패한 경우는 거의 없었다는 것입니다. 대부분은 PoC를 시작하는 방식 자체가 처음부터 잘못되어 있었습니다.

Plan AI가 2주 파일럿(PoC)을 설계할 때 가장 먼저 점검하는 3가지 함정을 공유합니다. 이미 PoC를 진행 중이거나, 이제 시작하려는 회사라면 시작 전에 한 번 점검해 볼 가치가 있습니다.

1. 측정 지표가 없는 PoC

가장 흔한 실패 패턴입니다. 'AI로 뭔가 자동화해보자'는 막연한 목표로 시작해서, 14일 후에 작동하는 데모를 만들어 놓고도 '이게 잘 된 건지 안 된 건지'를 아무도 판단하지 못하는 상황.

판단이 불가능한 PoC는 본 프로젝트로 넘어갈 수 없습니다. 의사결정자는 늘 '우리가 이걸 더 키우면 무엇이 좋아지는가?'를 묻기 때문입니다. 답이 없으면 예산이 안 나옵니다.

해결: PoC를 시작하기 전에 단 하나의 숫자를 합의하세요.

이 숫자가 없는 PoC는 시작하지 마세요. 14일 후에 결과를 두고 회의실에서 토론이 벌어지는 순간 그 PoC는 이미 죽은 겁니다.

2. 범위가 너무 넓은 PoC

'우리 회사의 CS 업무 전체를 AI로 자동화하는 PoC를 14일에 해주세요.' 들으면 야심차 보이지만 실패가 예약된 요청입니다.

CS 업무 전체는 14일은커녕 6개월짜리 프로젝트입니다. 14일 안에 전체를 건드리려고 하면 어느 것도 제대로 안 됩니다. 결과는 '데모는 돌아가는데 실제로는 못 쓴다'가 됩니다.

PoC의 본질은 '전체를 작게 만드는 것'이 아니라 '가장 아픈 한 점을 진짜로 푸는 것'입니다.

해결: 자동화하고 싶은 업무를 종이에 쭉 나열한 다음, 각 항목 옆에 두 개의 숫자를 적으세요.

두 숫자를 곱한 값이 가장 큰 항목 딱 하나가 PoC 대상입니다. 나머지는 본 프로젝트로 미룹니다. 이 한 점을 14일 안에 90% 자동화하면, 의사결정자는 그 다음 예산을 망설이지 않습니다.

세 번째 함정이 가장 조용히 PoC를 죽입니다. 개발팀과 임원만 있고, 실제로 그 업무를 매일 하는 사람이 빠진 PoC.

이런 PoC는 14일 후에 멋진 데모가 만들어집니다. 임원진은 만족합니다. 그런데 막상 현장에 배포하면 아무도 안 씁니다. 이유는 늘 비슷합니다. '기존 워크플로와 안 맞는다', '오히려 더 번거롭다', 'AI가 잘못 답하면 책임을 누가 지냐.'

PoC가 진짜로 검증해야 하는 건 '이 시스템이 작동하는가'가 아니라 '이 시스템이 매일 그 업무를 하는 사람의 손에서 살아남는가'입니다. 후자가 검증되지 않으면 본 프로젝트는 똑같이 실패합니다.

해결: PoC 첫 주에 반드시 실제 사용자 1~2명을 인터뷰하세요. 둘째 주에는 그들에게 직접 써보게 하고 피드백을 받으세요. 결과 발표 자리에 그 사용자가 같이 앉아 '이거 매일 쓸 수 있겠다'라고 말해야 PoC가 성공한 것입니다. 임원의 박수만으로는 부족합니다.

세 가지 함정을 한 줄로 요약하면 이렇습니다.

좋은 PoC는 하나의 숫자, 하나의 업무, 한 명의 사용자로 설계됩니다.

Plan AI가 2주 파일럿(PoC)에서 가장 먼저 하는 일은 코드를 짜는 것이 아니라, 이 세 가지를 합의하는 것입니다. Day 1~2가 분석에 통째로 들어가는 이유입니다. 이 합의가 끝나면 PoC의 절반은 이미 성공한 것이나 다름없습니다.

PoC를 고민하고 있다면, 코드 쓰기 전에 종이 한 장 들고 위 세 가지부터 채워보세요. 답이 안 나오면 그 PoC는 아직 시작할 준비가 안 된 것입니다.