개념 검증(PoC)을 진행하라

이 단계를 왜, 지금 해야 할까?

II-1작게 시작하되 배움은 빠르게

• 자원을 어느 정도 확보했으면 이제 솔루션의 실제 버전을 만들 차례
• 초기 버전은 앞으로 대규모로 판매할 제품보다 훨씬 작고 단위당 비용도 훨씬 높을 수밖에 없음
• 완전한 상용 규모로 구축하는 데 수년의 시간과 수백만 달러가 들 수 있기 때문
• 개념 검증(PoC)의 목표 = 작지만 의미 있는 규모에서 기술을 검증 · 가능하다면 그 과정에서 수익까지
• 소프트웨어 스타트업은 빠른 반복으로 성장 — 실리콘밸리의 「빠르게 실패하고 다시 시도하라」
• 하드웨어·딥테크에서도 반복 자체는 더없이 중요. 다만 「빠르게」라는 대목은 그대로 적용하기 어려움
• 복잡한 물리적 시스템은 몇 주·몇 달 안에 수정하는 일이 아예 불가능할 수도 있음
• 그렇더라도 무엇을 왜 만드는지 의도를 분명히 + 할 수 있는 한 빠르게 배워 나갈 것
• 이 단계의 개념 검증은 10단계 시장 도약 경로와 맞물릴 것
• 10단계 = 가장 단순하고 빠르게 만들 수 있는 버전으로 진입할 교두보 시장을 정의
• 이번 단계 = 그 버전을 실제로 만드는 방법

II-2개념 검증 — 입증이 붙은 이름

• 초기 버전을 가리키는 용어는 매우 다양 → 이 책은 그중 개념 검증(Proof of Concept)을 쓰기로 함
• 고른 이유 — 반복할 때마다 솔루션에 관해 중요한 무언가를 입증해야 한다는 점을 강조
• 프로토타입 — 기술적 검증 + 앞으로 복제·대량 생산할 수 있는 결과물이라는 뉘앙스
• 파일럿 — 잠재 고객과 함께 진행하는 현장 테스트에 방점
• 개념 검증은 두 측면을 모두 아우름
• TRL(Technology Readiness Level) 프레임워크로 보면 TRL 3~6, 경우에 따라 TRL 7까지 해당할 수 있음
• 상용 규모로 가는 과정에서 개념 검증은 여러 차례 진행하게 될 가능성이 높음
• 단계마다 기술의 서로 다른 측면을 검증하고 초기 고객에게 새로운 가치를 전달
• 완전한 상용 규모를 구축하기 시작했다면 그때는 이미 개념 검증 단계를 넘어선 것 — 대략 TRL 7 또는 TRL 8

II-3MVBP와 겹치되 같지는 않음

• MVBP(최소 실행 가능한 비즈니스 제품) = 고객이 실제로 돈을 낼 의향이 있는 제품의 가장 기본적인 형태
• Disciplined Entrepreneurship 프레임워크의 Step 22 에 해당하는 개념
• 개념 검증이 다른 점 = 비즈니스 타당성만 따지지 않고 기술적 타당성에 더 큰 비중
• 경우에 따라 두 개념은 겹침 — 개념 검증에서 수익까지 내면 그때는 개념 검증이 곧 MVBP. 다만 늘 그렇지는 않음
• 두 개념이 갈라지는 핵심 지점 하나 — 컨시어지 MVBP
• 자동화 체계를 갖추기 전, 고객·사용자 개개인에게 맞춤형으로 직접 지원하는 방식
• 대표적으로 소프트웨어 자동화 전에 팀원이 데이터를 손으로 입력해 주는 경우
• 딥테크 기반 기후·에너지 벤처에는 유용하지 않은 경우가 많음 — 대개 이미 수요가 검증된 상품을 팔기 때문
• 예 — 새 에너지 생산 기술이라면 컨시어지 버전이 커다란 바퀴 위를 하루 종일 달려 에너지를 만드는 일이 될지도 모름. 몸만 녹초, 남는 것은 「사람들이 에너지를 원한다」는 이미 알던 사실뿐
• 일반적으로 우선순위가 가장 높은 요소는 기술적 타당성
• 전기나 화학 제품처럼 이미 수요가 있는 상품을 생산하는 경우라면 더욱
• 순서 — 솔루션이 기본적으로 작동함을 먼저 입증 → 그다음 돈 낼 의향이 있는 고객에게 가치를 줄 수 있음을 입증 (20단계)

II-4개념 검증 전에 가정부터

• 개념 검증은 하나하나가 반드시 무엇인가를 입증할 것
• 구축에 앞서 어떤 핵심 가정을 검증할지부터 정의
• 핵심 가정을 찾아내고 쪼개는 일은 어렵지 않고 오히려 흥미로운 과정일 수 있음
• 그런데도 많은 기업가가 이 단계를 건너뛰고 직관이나 기존 연구로 대신함
• 기술·비즈니스·고객 행동에 관한 가정을 실제로 검증하는 과정을 다른 것으로 대체하지 말 것 — 규율을 지킬 것
• 출발점 = TEA(기술경제성 분석) → 개념 검증으로 입증하거나 반박할 수 있는 가설 목록을 작성
• 가정은 시장에 관한 것일 수도 기술에 관한 것일 수도 있음. 어느 쪽이든 의도를 갖고 명확하게 정의
• 핵심 가정이 갖춰야 할 다섯 가지 특성
• Specific 구체성 — 매우 구체적이고 상세할 것
• Singular 단일성 — 가정 하나에 요소 하나. 문장에 and 가 들어가면 나누거나 단순화하라는 신호
• Important 중요성 — 솔루션의 성패에 매우 큰 영향을 미칠 것
• Measurable 측정 가능성 — 정량적으로 측정 + 서로 다른 상황을 편향 없이 비교
• Testable 테스트 가능성 — 테스트할 수 없는 가정은 의미 없음

II-5간결함이 속도 격차를 줄이는 데 도움

• 미 해군 엔지니어들이 오랫동안 적용해 온 원칙 KISS — “keep it simple, stupid”, 무식해 보이더라도 단순하게 만들라는 뜻
• 기후·에너지 벤처에는 한 단어만 바꾼 “keep it scrappy, stupid” — 간결하고 기민하게 만들라는 제안
• 개념 검증을 가능한 한 간결하게 구축 → 시간과 비용을 최소화할 수 있음
• 하드웨어·딥테크는 소프트웨어만큼 빠르게 반복 개선하기 어려움 → 간결함이 그 격차를 줄이는 데 도움
• 간결하게 = 제한된 자원을 최대한 활용할 창의적인 방법을 찾는다는 뜻
• 부품은 가능한 한 시중에서 구매. 자체 설계는 검증할 핵심 가정과 직접 관련된 구성 요소만
• 규모도 작게 시작. 가정을 검증하는 데 필요한 최소한의 기능만
• 개념 검증은 기술적 타당성 입증 + 초기 수익으로 가는 가장 빠른 경로여야 함

II-6공용 공간은 쓰되 안전은 예외 없이

• 가능하다면 처음부터 자체 연구소·작업장을 차리기보다 공용 공간과 장비를 활용
• 좋은 후보 — 지역의 기술 인큐베이터 · 대학 · 기업 · 연구 시설
• 지금은 북미 최대의 기후테크 인큐베이터로 성장한 그린타운 랩스(Greentown Labs)도 처음에는 창업가들이 함께 낡은 창고를 빌리는 데서 출발
• 어디에서 구축하든 적절한 안전 수칙은 반드시 준수
• 간결함이 곧 무책임함을 뜻하지는 않음 — 빠르게 움직이는 일도 중요하나 구성원 모두의 안전과 건강 역시 그만큼 중요
• 안전을 소홀히 하면 소송에 휘말릴 수 있고, 소송은 벤처를 실패로 이끄는 지름길
• 물론 간결한 접근이 아예 불가능한 경우도 있음
• 일부 기후·에너지 솔루션은 규모가 크거나 위험성이 높아 소형 버전을 만들 수 없기 때문
• 이럴 때는 프로젝트의 특성을 감안해 안전성과 효과성을 지키는 범위 안에서 최대한 간결한 접근

사례