MVP·PoC·프로토타입은 무엇이 다른가요?

세 용어는 무엇을 확인하려고 만드나요?

세 가지의 차이는 완성도가 아니라 확인하려는 질문입니다. 프로토타입은 "이런 모양과 순서가 맞나"를 묻고, PoC(개념검증)는 "이 방식이 기술적으로 되나"를 묻고, MVP는 "실제 사용자가 이걸 쓰고 반응하나"를 묻습니다. 답을 보여 줄 상대도 다릅니다. 앞의 둘은 내부 구성원과 개발사가 보면 결론이 나지만, MVP는 바깥의 사용자가 써 봐야 결론이 납니다.

용어가 섞이는 이유는 셋 다 "아직 다 만들지 않은 것"으로 보이기 때문입니다. 그러나 덜 만든 이유가 서로 다릅니다. 프로토타입은 만들지 않아도 되는 부분을 비워 둔 것이고, PoC는 확인할 구간만 남기고 나머지를 뺀 것이고, MVP는 검증할 가설 하나에 필요한 흐름만 남긴 것입니다. 무엇을 왜 비웠는지가 다르니 검수할 때 봐야 할 것도 달라집니다.

세 용어 가운데 널리 인용되는 정의가 있는 것은 MVP뿐입니다. 에릭 리스는 MVP를 "가장 적은 노력으로 고객에 대한 검증된 학습을 최대한 얻을 수 있게 하는 새 제품의 버전"으로 적었고, 이름과 달리 최소한의 제품을 만드는 일이 목적은 아니라고 덧붙였습니다. 기준이 크기가 아니라 고객에게서 무엇을 배웠는지에 있다는 뜻입니다. MVP 자체의 구성과 측정 지점은 MVP란 무엇인가요에서 따로 다뤘으니, 이 글에서는 나머지 두 용어와의 경계만 봅니다.

같은 방문 예약 서비스로 비교하면

아파트 방문 예약을 받는 서비스를 준비한다고 하겠습니다. 프로토타입은 방문자가 날짜를 고르고 동·호수를 입력하고 완료 화면까지 가는 순서를 클릭되는 화면으로 만들어 경비실 담당자에게 보여 주는 것입니다. 입력한 내용이 저장되지 않아도 "이 순서로 쓰시겠습니까"라는 질문에는 답이 나옵니다.

PoC는 막힐 가능성이 있는 한 구간만 떼어 시험합니다. 기존 출입 통제 장치에 예약 정보를 넘길 수 있는지, 입주민 명부와 대조가 되는지를 확인하는 식입니다. 사용자 화면이 없어도 되고 담당자 혼자 실행해 결과를 확인해도 되지만, 되는지 안 되는지 판정 기준은 미리 정해 두어야 합니다. "연동이 됐다"는 말만으로는 끝나지 않습니다. 예약 100건을 보내 몇 건이 장치에 반영됐는지, 실패한 건이 어떤 형태로 확인되는지까지 정해 두어야 결과를 다음 결정에 쓸 수 있습니다.

MVP는 한 동이라도 실제 방문자가 예약을 넣고 경비실이 그 예약을 보고 처리하는 상태까지 가야 합니다. 화면 수는 적어도 되지만 접수에서 확인까지 한 줄기는 끊기지 않아야 하고, 몇 건이 들어와 몇 건이 실제 방문으로 이어졌는지 세어야 결론이 생깁니다.

무엇을 만들고 무엇을 만들지 않나요?

구분	프로토타입	PoC	MVP
확인할 질문	이 흐름과 화면이 맞나	이 방식이 되나	사용자가 쓰고 반응하나
보여 줄 상대	내부·현장 담당자	개발자·연동 담당	실제 사용자
자료 저장	필요 없음	시험용 자료만	실제 자료로 저장
끝내는 조건	순서 합의	판정 기준 충족	측정한 사용 결과

표에서 가장 자주 어긋나는 줄은 세 번째입니다. 실제 자료를 저장하지 않는 산출물을 MVP라고 부르면 출시 뒤에 사용자 자료를 담을 구조를 다시 만들게 됩니다.

순서대로 다 거쳐야 하나요?

아닙니다. 세 가지는 단계가 아니라 질문에 따라 고르는 수단입니다. 화면 순서에 이견이 없고 기술적으로 막힐 데가 없다면 앞의 둘을 건너뛰고 바로 MVP로 가도 됩니다. 반대로 연동할 장비나 외부 시스템이 있으면 MVP 일정을 잡기 전에 그 구간만 PoC로 확인하는 편이 안전합니다.

예산을 한 번만 쓸 수 있다면 PoC와 MVP를 하나의 산출물로 묶지 않는 편이 낫습니다. 묶으면 연동이 늦어질 때 사용자에게 내보낼 흐름이 같이 밀리고, 결국 둘 중 어느 질문에도 답하지 못한 상태로 기간이 끝납니다.

앞 단계 산출물을 그대로 이어 쓸 수 있나요?

대개 그렇지 않습니다. 프로토타입 화면은 합의를 얻는 순간 역할이 끝나므로 버리는 것을 전제로 만드는 편이 빠릅니다. 재사용을 염두에 두고 제대로 만들기 시작하면 확인하려던 질문보다 작업이 커집니다.

PoC 코드도 그대로 운영에 올리기 어렵습니다. 권한, 오류 재시도, 기록처럼 운영에 필요한 부분이 빠진 상태로 "되는 것만" 확인한 결과이기 때문입니다. 다만 PoC에서 알아낸 규격과 제약, 즉 어떤 형식으로 주고받아야 하고 어디서 실패하는지는 MVP 설계에 그대로 쓰입니다. 그래서 PoC를 맡길 때는 코드와 함께 확인 결과를 글로 남겨 달라고 요청하시는 편이 좋습니다.

발주할 때 섞이면 생기는 일

용어가 섞인 채 견적을 받으면 비용과 검수 기준이 함께 흔들립니다. 프로토타입을 기대하고 받은 견적에 서버 구축과 회원 기능이 들어와 금액이 몇 배가 되거나, MVP라고 부른 산출물에 실제 사용자가 접근할 통로가 없는 상태로 검수에 들어가는 경우입니다.

그래서 계약서와 제안요청서에는 용어 대신 산출물을 적는 편이 안전합니다. "클릭 가능한 화면 몇 개", "지정한 장비와의 연동 성공 판정 기준", "실제 사용자 접수가 가능한 흐름 하나와 측정 항목"처럼 적으면 어느 용어를 쓰더라도 검수 기준이 같아집니다.

지금 정할 한 가지

이번 개발로 확인하려는 질문을 한 문장으로 적어 보시기 바랍니다. 그 문장이 모양에 관한 것이면 프로토타입, 기술에 관한 것이면 PoC, 사용자 반응에 관한 것이면 MVP가 맞는 자리입니다. 질문이 두 개 이상이면 어느 것을 먼저 확인할지도 정해 두어야 범위가 다시 벌어지지 않습니다.

네오렉트에 문의하실 때는 확인하려는 질문 한 문장, 지금 가진 자료와 연동해야 할 시스템, 결과를 언제까지 봐야 하는지를 함께 보내 주시면 세 가지 중 어느 범위로 잡을지부터 같이 정리해 드립니다.