8화. 좋은 PoC는 숙제를 늘린다?

분명 데이터 넣고 잘 돌아갔는데?

"고생하셨어요. 그런데 이 정도라면 저희가 직접 하거나, 다른 자동화 도구를 만들어 하는 것과 차이를 느끼기 힘들어요."

예전에 한 고객사의 PoC (Proof of Concept) 결과 발표 자리에서 들었던 말입니다.

정확한 당시 표현을 그대로 옮기기는 어렵지만, 뉘앙스가 그랬습니다.

아, 이럼 안 되는데.

영업의 촉이 말합니다. 땀이 또 흐릅니다.

고객이 제공한 데이터를 플랫폼에 넣었습니다. 준비했던 기능도 작동했고, 보여주기로 한 결과도 보여줬습니다.

이것도 얼마나 힘들었는데.

그런데 고객이 궁금했던 것은 다른 것이었습니다.

이걸 쓰면 지금 하던 일이 어떻게 달라지고, 그 결과를 직원들이 실제 업무에서 어떻게 활용하게 되는지까지 화면과 문서로 보여줘야 하는 것 아니냐는 이야기였습니다.

PoC에서 너무 많은 걸 바라는 것 같으면서도, 틀린 말은 아니었습니다.

'된다'는 것은 보여줬어도, '그래서 왜 이걸 써야 하는가, 그리고 어떻게 달라지는가'까지는 보여주지 못했던거죠.

그 자리가 더 뼈아팠던 이유가 있습니다.

그 PoC에 두 달 가까이가 들어갔습니다.

우리 엔지니어가 붙었고, 파트너 인력도 여러 명 투입됐습니다. 고객사에서도 데이터와 현업 담당자가 시간을 냈습니다. 데이터를 받는 데만 몇 주가 지나갔습니다.

그렇게 두 달치 엔지니어 시간과 파트너 리소스를 써서 우리가 만들어낸 결론은 결국 이것인 셈이었습니다.

"잘 됩니다."

고객이 그 자리에 오기 전부터 대체로 짐작하고 있던 문장입니다.

당연히 잘 되어야죠. 

발표 자료 표지의 우리 로고와 파트너 로고를 보면서, 이 정도면 꽤 잘 끝난 PoC라고 생각했던 대가는 컸습니다.

진짜 비용은 인건비만이 아니었습니다.

PoC만 끝나면 승인 프로세스로 넘어갈 거라고 내부에 호언장담해둔 말이 무너진 것, 그리고 그동안 만나지 못한 다른 고객들이었습니다.

우리는 제품이 실제로 잘 돌아가는 것을 보여주려 했습니다

고객은 그 제품이 들어간 자기 업무를 확인하고 싶어 했습니다.

같은 PoC라는 말을 쓰면서도 기대하고 있던 것이 달랐습니다.

우리는 고객 데이터를 제품에 넣고 약속했던 기능이 작동한다는 것을 보여주는 데 집중했습니다. 당시 우리에게는 그게 그간의 익숙한 PoC 방식이었습니다.

고객은 그다음을 보고 싶어 했습니다.

이걸 실제로 도입하면 무엇이 달라지는지.

기존 방식이나 다른 자동화 도구보다 무엇이 나아지는지.

그리고 이 결과를 보고 실제 프로젝트를 시작할 이유가 생기는지.

익숙함이 주는 함정

돌아보면 그 두 달이 그렇게 흘러간 데는 우리 안의 익숙함도 한몫했습니다.

그렇다고 누구 한 사람이 일을 잘못해서 생긴 문제는 아니었습니다.

영업은 기회를 만들었고, 프리세일즈는 기술을 검증했습니다. 함께한 파트너는 실제 작업의 상당 부분을 맡았고, 고객도 데이터와 현업 인력을 내줬습니다.

각자 맡은 일은 했습니다.

문제는 그 사이였습니다.

영업이 고객의 요구사항을 받아 오면 어느 순간 프리세일즈와 파트너에게 넘어갑니다.

"고객이 이 데이터를 넣어서 이 기능이 되는지 보고 싶답니다."

그러면 프리세일즈와 파트너는 데이터를 받고 환경을 만들고, 요청받은 기능을 구현해 결과를 보여줍니다.

역할은 깔끔했습니다.

그런데 고객과 나눴던 긴 이야기가 여러 역할을 거쳐 넘어가다 보면 어느 순간 요구사항 몇 줄이 되기 쉽습니다.

    지금 그 일을 어떻게 하고 있는지.

    이미 무엇을 해봤는지.

    그런데도 정확히 어디에서 막히고 있는지.

    그래서 이번 PoC를 통해 무엇을 새롭게 알아내야 하는지.

각자 맡은 일을 하는 사이 이런 질문을 서로 놓쳤던 것 같습니다.

결국 두 달을 쓰고도 고객이 이미 알고 있던 곳에서 별로 앞으로 나가지 못했습니다.

그래서 영업이 가져와야 하는 것도 조금 달라집니다.

영업은 PoC의 출발지점을 더 깊게 확인해야 합니다.

프리세일즈의 역할도 조금 달라집니다.

전달받은 요구사항을 바로 구현 항목으로 바꾸기 전에 질문을 한 번 더 해 볼 필요가 있습니다.

    정말 이것이 먼저 확인해야 할 문제인지.

    어디까지 잘 되고 어디서부터 깨지는지.

    실제 데이터에서는 어떤 예외가 생기는지.

필요하다면 고객이 처음 요청하지 않은 것도 다시 묻고 시험해봐야 합니다.

질문 하나를 더 하면 일이 하나 더 생길 것 같아 피하고 싶을 때도 있습니다.

그런데 일을 늘리지 않으려다, 정작 확인해야 할 것까지 줄여버리면 곤란합니다.

영업에게 기술을 대신하라는 것도, 프리세일즈에게 영업을 하라는 것도 아닙니다.

고객의 이야기가 역할 사이를 넘어갈 때 기능요구사항으로만 남지 않게 하자는 이야기입니다.

영업은 고객의 현재 상황을 더 자세히 가져오고, 프리세일즈와 파트너는 그 현재에서 출발해 고객과 우리 모두 아직 확인이 더 필요한 영역을 찾아냅니다.

영업이 "고객이 이걸 보고 싶답니다"만 가져오고, 프리세일즈와 파트너가 "됩니다"만 돌려주는 방식으로는 비싼 데모를 만들기 쉽습니다.

작은 프로젝트 느낌의 PoC

그 뒤 비슷한 기회를 진행할 때는 조금 다르게 접근했습니다.

이번에는 제품의 기능 구현으로 범위를 제한하지 않았습니다.

    어떤 업무를 볼지.

    어떤 데이터를 적용할지.

    무엇이 나오면 의미가 있을지.

이번 PoC에서 무엇까지 알아내야 의미가 있을지부터 인터뷰하고 정리했습니다.

그다음 시나리오를 만들고, 필요한 부분은 가벼운 개발로라도 붙였습니다.

이번에도 목표한 대로 다 되지는 않았습니다.

예상하지 못한 문제도 있었고, 보안이나 권한처럼 추가로 풀어야 할 일도 생겼습니다. 우리 힘만으로 해결할 수 없는 일도 있었습니다.

기술보다 실제 업무가 어떻게 흘러가는지, 필요한 데이터가 어디에 있고 누가 접근할 수 있는지를 확인하는 데 더 오래 걸렸습니다.

PoC인데 왜 이렇게 복잡한가 싶었죠. 이렇게 까지 해야 하나 싶기도 하고요.

그런데 이상하게도 두 번째 PoC에서는 고객의 반응도, 다음 단계도 더 선명했습니다.

PoC를 했더니 해결해야 할 숙제가 더 늘어난 셈인데도 말이죠.

그런데 MIT Project NANDA가 2025년 발표한 기업 AI 도입 조사에서도 비슷한 이야기가 보였습니다.

기업들이 AI 벤더를 평가할 때 중요하게 본 것 중 하나가 자신들의 업무 흐름을 얼마나 깊이 이해하는가였습니다.

인터뷰에는 이런 말도 나옵니다.

"대부분의 벤더는 우리 결재나 데이터 흐름이 어떻게 돌아가는지 모른다."

적어도 우리만 마주친 문제는 아니었던 것 같습니다.

예전 PoC도 원래 무언가를 알아내기 위한 과정이긴 했습니다

제가 담당했던 일부 장비나 기능 중심 제품에서는 고객 환경에서도 약속한 성능이 나오는지, 특정 기능이 제대로 작동하는지를 확인하는 것 자체가 새로운 그리고 중요한 정보였습니다. 제품 설명 때 화려하게 말했던 기능들이 제대로 작동하지 않는 제품들도 있었으니까요. 

그런데 AI나 여러 시스템과 데이터를 연결하는 플랫폼형 제품에서는 상황이 조금 달라지고 있습니다.

고객은 제품을 미리 조사하고 다른 제품과 비교할 수 있습니다.

범용 AI를 직접 써볼 수도 있고, 간단한 자동화라면 직접 만들어보는 것도 쉬워졌습니다.

그러니 고객 데이터를 제품에 넣고

"보세요. 이렇게 작동합니다."

라고 보여주는 것만으로는 새롭게 알게 되는 것이 별로 없을 수 있습니다.

첫 번째 PoC가 딱 그랬습니다.

고객은 자기 데이터도, 사람이 직접 할 수 있다는 것도, 다른 자동화 방법이 있다는 것도 이미 알고 있었습니다.

우리는 거기에 이 제품이 작동한다는 정보 하나를 추가해준 셈이죠.

두 달을 써서.

좋은 PoC라면 고객이 시작하기 전에는 미처 몰랐거나 놓쳤던 부분을 하나쯤 찾아내야 하지 않을까요.

    실제로 무엇이 나아지는지.

    어디에서 막히는지.

    확대하려면 무엇이 더 필요한지.

    처음에는 생각하지 못했던 다른 방법은 없는지.

PoC가 끝났는데 고객이 시작하기 전보다 아는 것이 별로 늘지 않았다면, 잘 만든 데모일 수는 있어도 좋은 PoC였는지는 다시 생각해봐야 합니다.

그리고 새롭게 알아낸 사실은 결국, 전에는 못 하던 판단을 가능하게 해야 합니다.

게다가 AI가 이 기준을 더 높이고 있습니다.

시나리오를 만들고, 코드를 작성하고, 데이터를 정리하고, 결과 자료를 만드는 일은 훨씬 빨라졌습니다.

고객도 직접 조사하고 간단한 프로토타입을 만들 수 있습니다.

그러니 '작동하는 무언가'를 만들어 보여주는 것 자체의 희소성은 점점 낮아질 수 있습니다.

그럴수록 중요한 것은 무엇을 만들었느냐가 아닙니다.

무엇을 새롭게 알아냈느냐. 그리고 그 사실 때문에 무엇을 다르게 판단하게 됐느냐.

PoC와 실제 프로젝트 사이

Gartner는 2024년 7월, 2025년 말까지 생성형 AI 프로젝트의 최소 30%가 PoC 이후 중단될 것으로 예상했습니다. 2026년 1월 발표에서는 2025년 말 기준 최소 50%가 PoC 이후 중단됐다고 밝혔습니다.

두 숫자를 직접 비교할 수는 없습니다. 하나는 예측이고 다른 하나는 이후에 발표한 수치니까요.

제게 더 눈에 들어온 것은 두 자료에서 중단 이유로 데이터 품질, 리스크 통제, 비용, 불명확한 비즈니스 가치가 반복됐다는 점입니다.

앞서 언급한 MIT Project NANDA 조사에서도 비슷한 간극이 보입니다.

업무에 내장되는 특화형 AI 도구는 60%가 검토됐지만, 파일럿 단계에 이른 비율은 20%, 성공적으로 운영에 적용됐다고 분류된 비율은 5%였습니다.

그래서 정확한 비율보다 눈이 갔던 부분은 기술을 검토하고 파일럿을 해보는 것과 실제 업무에 안착시키는 것 사이의 갭입니다.

기술은 빠르게 발전했는데 실제 프로젝트로 넘어갈 때 만나는 문제는 여전히 남아 있다는 거죠.

두 달을 써서 "됩니다"만 남긴 우리의 PoC는 저 문제들 중 어느 것도 줄여주지 못했습니다.

PoC를 베이스캠프로

물론 모든 PoC를 작은 본 프로젝트처럼 할 수는 없습니다.

비용도, 책임도, 범위도 다릅니다.

성능 자체가 구매 기준인 장비나 단일 기능 제품이라면 정확한 기능·성능 검증만으로 충분할 수 있습니다.

그렇기에 PoC에서 Production 수준의 보안과 연동, 운영 환경까지 모두 만들어놓자는 것도 아닙니다.

그러면 본 프로젝트를 돈도 제대로 못 받고 먼저 하는 일이 될 수도 있습니다.

PoC는 Production이 아니지만, Production으로 갈 수 있는 길은 보여줘야 합니다.

그래서 요즘의 PoC와 Pilot을 저는 본 프로젝트로 올라가기 위한 베이스캠프에 가깝다고 생각합니다.

베이스캠프에서 정상까지 올라갈 필요는 없습니다.

하지만 어디로 갈지, 무엇이 더 필요한지, 어디가 위험한지는 알아야 다음으로 올라갈 수 있습니다.

PoC도 마찬가지입니다.

끝났을 때 적어도 네 가지는 남아 있어야 합니다.

      예: 우리 데이터로도 목표 정확도가 나온다.

   2. 새롭게 알게 된 것 — PoC 전에는 고객도 우리도 몰랐던 것

      예: 병목은 정확도가 아니라 부서 간 데이터 권한이었다.

   3. 아직 모르는 것 — 이번 범위에서 확인하지 못한 것

      예: 물량이 열 배가 되면 어떻게 되는지.

   4. 다음 단계의 조건 — 확대하려면 무엇이 더 필요한지

      예: 레거시 시스템 연동과 담당 조직 지정.

그리고 마지막으로,

그래서 이제 무엇을 결정할 수 있는가.

이 네 질문은 끝나고 나서 회고용으로만 채우는 것이 아닙니다.

시작할 때 미리 그려두고, PoC를 진행하면서 하나씩 채워가는 편이 낫습니다.

특히 두 번째 칸이 비어 있다면,

비용을 들여 데모를 한 번 더 한 셈입니다.

반대로

"이 방식으로는 하면 안 되겠다."

라는 결론을 본 프로젝트 전에 얻었다면, 그것도 좋은 PoC일 수 있습니다.

좋은 PoC는 해야 할 이유만 만드는 것이 아니라, 지금 방식대로는 하지 말아야 할 이유도 빨리 만들어줍니다.

PoC가 무사히 끝나기만을 바라는 것보다, 본 프로젝트에서 만날 문제를 이때 먼저 만나는 편이 낫습니다.

다시 처음의 결과 발표 자리로 돌아가 봅니다.

"이 정도라면 저희가 직접 하거나, 다른 자동화 도구를 만들어서도 할 수 있어요."

돌이켜보면 고객이 궁금했던 것은 결국 두 가지였습니다.

이번 PoC를 통해 전에 몰랐던 무엇을 새롭게 알게 됐는지.

그리고 그걸 가지고 이제 무엇을 다르게 판단할 수 있는지.

우리는 제품이 작동한다는 것을 증명할 준비는 해갔습니다.

두 달치 리소스를 쓰고 나서야, 우리가 준비하지 않은 질문이 그것이었다는 걸 알았습니다.

다음 PoC를 시작한다면 기능 목록을 열기 전에 고객에게 먼저 물어보시면 좋겠습니다.

"이번 PoC가 끝났을 때 무엇을 알게 되면, 지금 망설이는 결정을 할 수 있을 것 같으세요?"

고객이 답하지 못한다면 그것도 중요한 정보입니다.

아직 이 PoC로 무엇을 확인하려는지 충분히 정리되지 않았을 수 있으니까요.

두 달을 쓰기 전에 알아낼 수 있는 일입니다.

PoC라는 이름은 예전과 같습니다.

하지만 AI와 플랫폼이 고객의 일 안으로 더 깊이 들어가고, 고객 스스로 할 수 있는 일도 많아질수록 그곳에서 증명해야 하는 것은 조금씩 달라지고 있습니다.

댓글 질문

PoC에서 계획했던 기능과 결과는 잘 나왔는데, 막상 고객 반응은 기대와 달랐던 경험이 있으신가요?

그때 무엇이 빠져 있었나요?

다음 편 예고

CRM을 켤 때마다 만나는 수많은 Sales Methodology들.

BANT, MEDDICC, SPIN….

잘 쓰면 고객과 사업기회를 보는 눈이 되지만, 어느 순간 빈칸을 채우는 일이 고객을 이해하는 일보다 중요해지기도 합니다.

다음 편에서는 Sales Methodology가 현장의 판단을 돕는 지도인지, 일을 위한 또 하나의 일이 되는지 고민해봅니다.

참고 자료

Gartner, Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025, 2024년 7월 29일.

Gartner, Arun Chandrasekaran, Why 50% of GenAI Projects Fail — And How to Beat the Odds, 2026년 1월 26일.

MIT Project NANDA, The GenAI Divide: State of AI in Business 2025 (Aditya Challapally 외-2025년 7월. 52개 조직 인터뷰, 153명 설문, 300건 이상 공개 사례 검토 기반).