제품 사양서를 먼저 쓰고 나서 고객을 찾으면 R&D 과제는 보기 좋게 정리되지만 위험한 방향으로 굳어집니다. 특히 정부 R&D 제출 직전에는 시장규모, 성장률, 정책 부합성, 기술 차별성을 빠르게 채우게 되는데, 그 자료만으로는 “누가 지금 이 문제 때문에 돈이나 시간을 잃고 있는가”라는 질문에 답하지 못합니다. R&D 고객발굴·시장검증 체크리스트의 목적은 시장이 크다는 말을 반복하는 것이 아니라, 제품개발 전에 고객의 실제 고통, 현재 대안, 구매 판단, 파일럿 조건을 요구사항으로 바꾸는 것입니다.

이 글은 상용화 로드맵, 컨소시엄 파트너 선정, 평가 지표 해석, 규제 샌드박스·파일럿 실행, 최종보고서 증빙 패키지를 대신하지 않습니다. 그 글들은 각각 후속 사업화, 협력 구조, 심사 항목, 실증 제도, 과제 종료 증거를 다룹니다. 여기서는 그보다 앞선 단계, 즉 연구개발계획서를 쓰기 전 또는 제품 요구사항을 확정하기 전에 “고객 문제를 검증했는가”를 확인합니다. 결론부터 말하면, 좋은 시장검증은 시장규모 슬라이드가 아니라 인터뷰 기록, 초기 수용자 기준, 지불의사 신호, 경쟁 대안 비교, 파일럿 파트너 조건, 고객 고통에서 기능 요구사항까지 이어지는 추적표로 남아야 합니다.

**빠른 결론**

R&D 고객발굴·시장검증 체크리스트는 “이 시장이 크다”를 증명하는 자료가 아닙니다. 제품개발 전에 문제 인터뷰로 고객의 현재 행동을 확인하고, 초기 수용자를 고통 강도와 구매권한으로 좁히며, 지불의사 증거를 예산·대체비용·다음 행동으로 분리해야 합니다. 정부 R&D 제출용으로는 고객 발언을 기능명으로 바로 바꾸지 말고, 고객 고통 → 사용 맥락 → 요구사항 → 검증 지표 → 과제 목표의 순서로 추적 가능하게 남겨야 합니다.

R&D 고객발굴·시장검증은 시장규모가 아니라 고객 행동을 묻는다

NSF I-Corps는 과학자와 엔지니어가 실험실 밖으로 나가 고객발굴 과정을 통해 발명의 시장 잠재력을 빠르게 평가하도록 설계된 프로그램입니다[S1]. National Teams 과정에서는 7주 동안 최소 100명의 잠재 고객 인터뷰를 요구합니다[S2]. 숫자 자체를 그대로 따라야 한다는 뜻은 아닙니다. 중요한 것은 시장검증을 책상 위 조사나 설문 링크가 아니라, 실제 잠재 고객과의 반복 인터뷰로 다룬다는 관점입니다.

정부 R&D 제출에서도 같은 원칙이 필요합니다. 2026년 중소기업 기술개발 지원사업 통합 공고는 신기술·신제품 개발과 공정혁신에 필요한 기술개발 비용 지원을 안내하고, 사업별 자격과 세부 공고를 확인하라고 밝힙니다[S6]. 즉 “지원사업이 있다”는 사실과 “우리 과제가 시장에서 검증됐다”는 사실은 별개입니다. TIPA가 안내한 2026년 중소벤처 기술혁신 지원정책도 민관공동 기술개발에서 1단계 기술·시장검증, 2단계 R&D, 3단계 기술사업화 패키지로 이어지는 흐름을 제시합니다[S8]. 기술개발 전 시장검증이 별도 단계로 다뤄지는 이유는, 기술 우수성만으로 제품개발 방향이 안전해지지 않기 때문입니다.

시장규모 슬라이드는 배경 자료입니다. 목표 시장이 충분히 큰지, 성장성이 있는지, 정책 방향과 맞는지를 설명하는 데 필요합니다. 그러나 시장규모는 고객의 구매 행동을 대신하지 못합니다. “국내 시장 1조 원”이라는 문장은 누가 예산을 집행하는지, 지금 어떤 대체재를 쓰는지, 왜 기존 방식으로는 부족한지, 새 제품을 받아들이려면 어떤 조건이 필요한지를 말해주지 않습니다. 그래서 R&D 시장검증의 첫 문장은 “시장규모는 얼마인가”가 아니라 “이 고객은 지금 어떤 문제를 어떤 방식으로 버티고 있는가”여야 합니다.

**시장자료와 검증증거의 차이**

<table>

<thead>

<tr><th>자료 유형</th><th>쓸 수 있는 곳</th><th>부족한 점</th></tr>

</thead>

<tbody>

<tr><td>시장규모·성장률</td><td>제안서 배경, 산업 필요성, 정책 부합성</td><td>실제 고객의 구매 이유와 도입 조건을 보여주지 못함</td></tr>

<tr><td>고객 인터뷰 기록</td><td>문제 정의, 요구사항, 초기 수용자 기준</td><td>표본이 좁으면 시장 전체 주장으로 과장되기 쉬움</td></tr>

<tr><td>지불의사·예산 신호</td><td>사업화 가능성, 가격 가설, 우선 기능 선정</td><td>말뿐인 호감과 실제 예산 행동을 분리해야 함</td></tr>

<tr><td>파일럿 조건서·파트너 레터</td><td>실증 조건, 수요처 요구 사양, 과제 목표 검증</td><td>의례적 의향서이면 검증력이 약함</td></tr>

</tbody>

</table>

문제 인터뷰는 기능 설명 전에 고객의 현재 우회 행동을 잡는다

문제 인터뷰의 핵심은 우리 기술을 설명하는 것이 아니라 고객이 이미 겪고 있는 불편을 추적하는 것입니다. Steve Blank의 고객개발 모델은 초기 기업 활동을 Customer Discovery, Customer Validation, Customer Creation, Company Building으로 나누고, Customer Discovery를 고객 앞에서 문제와 니즈에 대한 가설을 테스트하는 단계로 설명합니다[S5]. Lean Startup 원칙도 “이 제품을 만들 수 있는가”보다 “이 제품을 만들어야 하는가”와 “지속 가능한 사업을 만들 수 있는가”를 먼저 묻습니다[S4].

R&D팀은 인터뷰 질문을 기능명 중심으로 만들기 쉽습니다. “AI 자동 분석 기능이 있으면 쓰시겠습니까”, “정확도 95%면 구매하시겠습니까”, “이 기능이 있으면 업무가 좋아질까요” 같은 질문은 대부분 긍정 답변을 받습니다. 하지만 긍정 답변은 검증 증거가 아닙니다. 문제 인터뷰에서는 고객의 과거 행동을 물어야 합니다. 최근 언제 그 문제가 발생했는지, 누가 처리했는지, 얼마의 시간이 들었는지, 어떤 임시방편을 썼는지, 그 임시방편 때문에 생긴 비용이나 위험이 무엇인지 확인합니다.

예를 들어 제조 검사 자동화 과제를 준비한다면 “불량 판정 AI가 필요합니까”보다 “최근 3개월 동안 오판정 때문에 재작업, 고객 클레임, 납기 지연이 발생한 사례가 있었습니까”를 묻습니다. 의료기기 소프트웨어라면 “대시보드가 있으면 좋습니까”보다 “현재 어떤 지표를 엑셀이나 수기로 옮기며, 그 과정에서 누가 어떤 오류를 책임집니까”를 묻습니다. 공공기관 대상 솔루션이라면 “시범사용 의향이 있습니까”보다 “현재 같은 문제를 어떤 예산 항목, 계약 방식, 내부 승인 절차로 처리합니까”를 확인합니다.

좋은 인터뷰 기록은 문장 그대로 저장하는 데서 끝나지 않습니다. 고객 발언을 문제, 원인, 현재 대안, 손실, 구매권한, 도입 제약으로 나눕니다. “좋다”, “필요하다”, “관심 있다”는 발언은 검증력이 약합니다. 반대로 “월 2회 야간 작업이 생긴다”, “기존 장비 로그와 맞지 않으면 현장 반발이 있다”, “보안팀 승인이 없으면 파일럿도 어렵다”, “내년 예산 편성 전에 성능 비교표가 필요하다” 같은 발언은 요구사항으로 바꿀 수 있습니다.

초기 수용자 세분화는 업종보다 고통 강도와 구매권한으로 좁힌다

초기 수용자는 “모든 제조업체”, “병원 전체”, “공공기관”, “중소기업”처럼 넓게 잡으면 찾을 수 없습니다. Strategyzer의 Value Proposition Canvas는 고객의 jobs-to-be-done, pains, gains를 구분하고, 고객 증거에서 얻은 인사이트를 바탕으로 제품-시장 적합성을 조정하라고 설명합니다[S3]. 이 관점에서 보면 초기 수용자 세분화는 업종 분류가 아니라, 같은 일을 수행하는 고객 중 누가 더 큰 고통과 더 빠른 도입 이유를 가졌는지 찾는 작업입니다.

초기 수용자를 나눌 때는 네 가지 기준이 유용합니다. 첫째, 고통 강도입니다. 문제가 불편한 정도인지, 비용·납기·규제·안전·고객 이탈로 이어지는지 분리합니다. 둘째, 현재 대안의 불만입니다. 고객이 이미 돈을 쓰고 있거나, 내부 인력을 투입하거나, 임시 도구를 조합하고 있다면 문제 강도가 높습니다. 셋째, 구매권한입니다. 사용자와 구매자가 다르면 인터뷰도 분리해야 합니다. 넷째, 도입 제약입니다. 보안, 인증, 데이터 반출, 기존 장비 연동, 현장 교육, 유지보수 조건이 초기 도입을 막는지 확인합니다.

IRIS의 2026년 10대 메가프로젝트 기술산업화 공고는 시장성·사업화 가능성이 우수한 과제에 대해 더 큰 지원 규모가 가능하다고 안내하고, 사업화 단계에서 수요처 요구 사양 도출, 후속 R&D, 시제품 제작·개조, 실증·검증, 인증, 양산 및 수출 지원을 연결합니다[S9]. 여기서 “수요처 요구 사양”은 제품개발 후에 꾸며 넣는 문장이 아니라, 초기 수용자를 좁히는 기준입니다. 어떤 수요처가 어떤 조건에서 기존 대안을 버릴 수 있는지 모르면 요구 사양도 흐려집니다.

초기 수용자 세그먼트는 작게 시작해야 합니다. “반도체 후공정 검사기업 중 월 1회 이상 고객사 품질 리포트를 제출하고, 오판정 재검토에 2명 이상이 투입되며, 기존 장비 로그를 외부 시스템과 연동할 수 있는 기업”처럼 좁혀야 인터뷰와 요구사항이 살아납니다. 이렇게 좁힌 세그먼트는 시장규모 슬라이드에서는 작아 보일 수 있습니다. 그러나 제품개발 전에는 넓은 시장보다 빠른 학습이 가능한 고객군이 더 중요합니다.

지불의사 증거는 좋다는 말보다 예산·대체비용·다음 행동으로 본다

지불의사는 “얼마면 사겠습니까”라는 질문으로 확인되지 않습니다. 고객은 아직 제품을 보지 않았고, 내부 예산과 승인 절차도 검토하지 않았으며, 경쟁 대안과 비교하지 않았을 수 있습니다. 그래서 R&D 시장검증에서는 지불의사를 세 단계로 나눠야 합니다. 첫째, 현재 비용입니다. 고객이 지금 문제를 해결하기 위해 쓰는 인건비, 장비비, 외주비, 지연 비용, 불량 비용, 규제 대응 비용을 확인합니다. 둘째, 예산 경로입니다. 구매 예산인지, R&D 협력 예산인지, 시험평가 예산인지, 유지보수 예산인지 분리합니다. 셋째, 다음 행동입니다. 기술자료 요청, 내부 담당자 소개, 파일럿 조건 협의, 유료 PoC 견적 요청처럼 실제 행동이 있었는지 봅니다.

NSF SBIR Phase I awardee 안내는 I-Corps가 상업적 기회 평가, product-market fit 판단, 비즈니스 모델 검증, beachhead market 식별을 돕는다고 설명합니다[S7]. 이 문장을 R&D 제안서로 옮기면, 지불의사 증거는 “고객이 좋아했다”가 아니라 “어떤 초기 시장에서 어떤 비즈니스 모델 가설을 검증할 수 있는가”로 정리해야 합니다. 특히 B2B·딥테크 과제에서는 사용자가 곧 구매자가 아닐 수 있습니다. 현장 엔지니어가 강하게 원해도 구매부서가 예산 항목을 찾지 못하면 지불의사는 아직 약합니다.

지불의사 증거를 과장하지 않는 것도 중요합니다. 무료 샘플을 받아보겠다는 말은 구매의사가 아닙니다. NDA 체결은 관심의 증거일 수 있지만 예산의 증거는 아닙니다. “도입되면 좋겠다”는 말은 문제 인식의 증거일 수 있지만 우선순위의 증거는 아닙니다. 반대로 고객이 기존 외주비를 알려주거나, 내부 승인자를 소개하거나, 파일럿 성공 기준을 논의하거나, 유료 테스트 범위를 물었다면 지불의사 신호로 기록할 수 있습니다.

**지불의사로 세면 안 되는 신호**

  • “좋네요”, “필요해 보입니다”처럼 비용·일정·책임자가 없는 반응
  • 무료 샘플, 무료 PoC, 정부지원금이 있을 때만 참여하겠다는 답변
  • 사용자는 원하지만 구매부서, 보안부서, 품질부서 확인이 없는 상태
  • 시장규모와 성장률만 있고 고객의 현재 대체비용이 없는 슬라이드

파일럿 파트너 레터는 의향서가 아니라 검증 조건표로 작성한다

파일럿 파트너 레터는 이름이 들어간 종이 한 장이 아닙니다. 고객발굴 단계에서 가치가 있는 레터는 “우리가 관심 있다”보다 “이 조건에서 검증하겠다”에 가깝습니다. 레터에는 고객 문제, 파일럿 범위, 제공 데이터 또는 현장 조건, 성공 기준, 중단 기준, 보안·책임 조건, 담당자 역할, 후속 논의 조건이 들어가야 합니다. 그래야 정부 R&D 제출 때도 고객 수요가 단순 친분이 아니라 요구사항의 출처로 작동합니다.

파일럿 파트너 레터를 만들 때 가장 흔한 실패는 파일럿을 판매 약속처럼 쓰는 것입니다. 정부 R&D 심사나 내부 투자 검토에서 파일럿 레터는 “선정 보장”이나 “매출 보장”이 아닙니다. 오히려 검증 조건이 없는 의향서는 약한 증거입니다. 좋은 레터는 조심스럽습니다. “당사는 A 문제를 B 조건에서 확인하고 있으며, C 기능 범위의 시제품이 D 성능과 E 운영 조건을 충족하는지 F 기간 동안 검토할 의향이 있다”처럼 검증 범위와 조건을 밝힙니다.

IRIS 글로벌 클러스터 R&BD 공고는 글로벌 PoC를 사업화 가능성 검증을 위한 기술·제품 실증으로 설명하고, 기술사업화 성과창출과 지속가능성 확보를 강조합니다[S10]. 이 공고가 이 글의 대상 과제를 직접 의미하는 것은 아니지만, 파일럿 레터를 해석하는 데 중요한 기준을 줍니다. PoC나 파일럿은 “홍보용 고객명”이 아니라 사업화 가능성을 검증하는 조건이어야 합니다. 고객명보다 중요한 것은 검증할 기능, 고객 환경, 성공 기준, 후속 판단입니다.

**파일럿 파트너 레터에 넣을 검증 조건**

<table>

<thead>

<tr><th>항목</th><th>약한 표현</th><th>강한 표현</th></tr>

</thead>

<tbody>

<tr><td>문제</td><td>업무 효율 개선에 관심</td><td>월 2회 이상 발생하는 재검토 작업과 납기 지연을 줄이는지 확인</td></tr>

<tr><td>범위</td><td>시제품 테스트 가능</td><td>1개 라인, 6주, 기존 로그 데이터와 병행 비교</td></tr>

<tr><td>성공 기준</td><td>성능이 좋으면 검토</td><td>오판정 재검토 시간 30% 감소 또는 품질팀 수동 확인 건수 감소</td></tr>

<tr><td>책임 조건</td><td>자료 제공 협조</td><td>보안 승인 후 익명화 데이터 제공, 현장 담당자 1명 지정</td></tr>

<tr><td>후속 판단</td><td>향후 구매 검토</td><td>파일럿 결과 검토회의 후 유료 PoC, 공동개발, 구매 검토 중 하나로 결정</td></tr>

</tbody>

</table>

경쟁 대안과 대체재는 없다고 쓰지 말고 현재 해결법을 적는다

딥테크 R&D 제안서에서 “직접 경쟁사가 없다”는 문장은 자주 나오지만, 시장검증에서는 거의 도움이 되지 않습니다. 고객은 이미 문제를 어떤 방식으로든 해결하고 있습니다. 엑셀, 외주, 수기 점검, 기존 장비의 불완전한 기능, 인력 추가 투입, 해외 솔루션, 아무것도 하지 않기까지 모두 대체재입니다. 경쟁 대안을 적는 이유는 경쟁사를 깎아내리기 위해서가 아니라, 고객이 왜 지금의 방식을 바꿀 만큼 고통을 느끼는지 확인하기 위해서입니다.

경쟁 대안 분석은 기능 비교표보다 고객 선택 기준으로 정리해야 합니다. 고객이 현재 대안을 쓰는 이유는 가격일 수도 있고, 내부 승인 관성일 수도 있으며, 보안 검토가 끝난 도구라서일 수도 있습니다. 새 제품이 기술적으로 우수해도 도입 비용, 교육 부담, 데이터 이전 위험, 유지보수 책임이 크면 고객은 기존 대안을 유지합니다. 따라서 “우리 기술이 더 정확하다”는 주장만으로는 부족합니다. “고객이 기존 대안을 버릴 조건”을 써야 합니다.

Lean Startup의 build-measure-learn 원칙은 아이디어를 제품으로 만들고, 고객 반응을 측정한 뒤, 전환 또는 지속 여부를 학습하는 반복을 강조합니다[S4]. 이 반복은 경쟁 대안 분석에도 적용됩니다. 첫 인터뷰에서 경쟁 대안을 완전히 맞히려고 하지 말고, 고객이 실제 쓰는 해결법을 듣고 가설을 수정해야 합니다. 대체재가 예상과 다르면 기능 우선순위도 바뀝니다. 예를 들어 고객이 비싼 장비보다 수기 확인을 대체재로 쓰고 있다면, 고급 기능보다 데이터 입력 부담과 현장 교육 비용이 더 큰 장벽일 수 있습니다.

고객 고통에서 기능 요구사항까지 추적표로 연결한다

시장검증의 마지막 산출물은 예쁜 인터뷰 요약이 아니라 요구사항 추적표입니다. 고객 발언을 곧바로 기능명으로 바꾸면 위험합니다. “리포트가 필요하다”는 발언은 자동 리포트 기능을 의미할 수도 있지만, 사실은 감사 대응용 원본 로그 보존, 내부 승인용 요약표, 고객사 제출용 PDF, 규제기관 제출용 증빙을 각각 의미할 수 있습니다. 그래서 고객 고통, 사용 맥락, 현재 대안, 기능 요구사항, 검증 지표, R&D 목표를 한 줄로 연결해야 합니다.

요구사항 추적표는 정부 R&D 제출 전에도 유용합니다. 평가 지표 글에서 다루는 점수표 해석과 달리, 여기서의 목적은 고객 문제와 연구개발 목표가 끊기지 않도록 만드는 것입니다. “정확도 95% 달성” 같은 기술 목표가 고객 고통과 연결되지 않으면 시장검증 증거가 약해집니다. 반대로 “검사 재확인 시간을 줄여야 한다 → 기존 수기 확인은 하루 2시간 걸린다 → 자동 후보군 표시가 필요하다 → 재확인 시간 30% 감소를 파일럿에서 측정한다”처럼 이어지면 기능과 검증 지표가 같은 방향을 봅니다.

**고객 고통-기능 요구사항 추적표 예시**

<table>

<thead>

<tr><th>고객 고통</th><th>현재 대안</th><th>기능 요구사항</th><th>검증 지표</th></tr>

</thead>

<tbody>

<tr><td>불량 판정 재검토에 매주 품질팀 시간이 소요됨</td><td>엑셀 로그 정리와 수기 샘플 확인</td><td>기존 장비 로그를 불러와 의심 구간을 자동 표시</td><td>재검토 시간 30% 감소, 누락 건수 0건</td></tr>

<tr><td>보안 승인 없이는 외부 클라우드 분석 사용 불가</td><td>내부 서버에서 제한적 분석</td><td>온프레미스 설치 옵션과 익명화 데이터 처리</td><td>보안 체크리스트 통과, 데이터 반출 없음</td></tr>

<tr><td>구매부서가 신규 솔루션 예산 항목을 찾지 못함</td><td>유지보수 예산 또는 외주 분석비로 임시 처리</td><td>유료 PoC 견적 범위와 유지보수 비용 구조 제시</td><td>예산 담당자 검토 회의 진행, 견적 요청 여부</td></tr>

</tbody>

</table>

추적표에는 “고객이 원한다”라는 열을 만들지 않는 것이 좋습니다. 원하는 기능 목록은 끝없이 늘어납니다. 대신 “고통이 반복되는가”, “현재 대안에 비용이 있는가”, “구매권한자에게 전달되는 지표인가”, “R&D로 해결할 기술 불확실성이 있는가”, “파일럿에서 측정 가능한가”를 봅니다. 이 다섯 질문에 답하지 못하는 기능은 제품개발 첫 버전에 넣지 않는 편이 안전합니다.

정부 R&D 제출 전 30분 고객발굴 체크리스트

제출 전 30분 점검은 문장을 더 멋지게 고치는 시간이 아닙니다. 고객발굴 증거가 과제 목표와 연결되는지 확인하는 시간입니다. 첫째, 문제 인터뷰 목록을 봅니다. 고객군별로 최소한 사용자, 구매자, 영향자, 내부 승인자를 구분했는지 확인합니다. 인터뷰 수가 적더라도 고객 역할이 분리되어 있으면 배울 수 있습니다. 반대로 같은 유형의 지인 인터뷰만 반복했다면 검증력이 약합니다.

둘째, 초기 수용자 기준을 한 문장으로 씁니다. “제조기업”이 아니라 “불량 재검토 비용이 반복되고 기존 장비 로그 접근이 가능하며 품질팀과 구매부서가 모두 파일럿 판단에 참여하는 제조기업”처럼 적습니다. 셋째, 지불의사 증거를 정리합니다. 현재 대체비용, 예산 항목, 유료 PoC 가능성, 견적 요청, 내부 승인자 소개 중 무엇이 확인됐는지 표시합니다. 넷째, 파일럿 파트너 레터를 검증 조건표로 바꿉니다. 고객명, 담당자, 범위, 데이터, 성공 기준, 중단 기준, 후속 판단을 분리합니다.

다섯째, 경쟁 대안을 현재 행동 기준으로 씁니다. 경쟁사가 없다는 문장을 지우고 고객이 지금 쓰는 해결법을 적습니다. 여섯째, 요구사항 추적표를 봅니다. 모든 핵심 기능이 고객 고통과 검증 지표에 연결되는지 확인합니다. 일곱째, 시장규모 슬라이드를 다시 해석합니다. 시장규모는 배경이며, 검증 주장은 인터뷰·대체비용·파일럿 조건·추적표로 뒷받침되어야 합니다.

**30분 최종 점검**

  • 문제 인터뷰가 기능 설명 전에 고객의 현재 행동을 기록했는가?
  • 초기 수용자가 업종이 아니라 고통 강도, 현재 대안, 구매권한, 도입 제약으로 좁혀졌는가?
  • 지불의사 증거가 호감 발언이 아니라 예산, 대체비용, 다음 행동으로 남았는가?
  • 파일럿 파트너 레터에 고객명보다 검증 범위와 성공 기준이 먼저 보이는가?
  • 경쟁 대안에 직접 경쟁사뿐 아니라 고객의 현재 우회 행동이 포함됐는가?
  • 고객 고통, 기능 요구사항, R&D 목표, 검증 지표가 한 줄로 추적되는가?
  • 시장규모 슬라이드를 시장검증 증거처럼 쓰지 않았는가?

이 체크리스트가 답하지 않는 범위를 분리해야 문서가 선명해진다

이 글의 체크리스트는 제품개발 전 고객 문제와 시장검증 증거를 정리하는 용도입니다. 과제 종료 후 사업화 증거를 정리하려면 [R&D 결과 사업화 로드맵 체크리스트](/guide/rnd-commercialization-roadmap-checklist)로 넘어가는 편이 맞습니다. 공동연구기관이나 수요기업의 역할 분담이 흔들린다면 [R&D 컨소시엄 파트너 선정 체크리스트](/guide/rnd-consortium-partner-checklist)가 더 직접적입니다. 공고의 평가 항목을 제안서 목차로 바꾸는 작업은 [정부 R&D 평가 지표 체크리스트](/guide/rnd-evaluation-indicator-checklist)에서 다룹니다. 제도형 실증, 규제특례, 테스트베드 경로는 [정부 규제샌드박스·파일럿 실증 체크리스트](/guide/rnd-government-sandbox-pilot-checklist)로 분리해야 합니다. 과제 수행 후 최종보고서와 증빙 폴더를 정리하는 일은 [정부 R&D 최종보고서 증빙 패키지 체크리스트](/guide/rnd-final-report-evidence-checklist)가 맞습니다.

R&D 고객발굴·시장검증 체크리스트의 마지막 질문은 간단합니다. “우리는 고객이 겪는 문제를 고객의 언어로 설명할 수 있는가, 그리고 그 문제를 해결하기 위해 고객이 이미 쓰는 돈·시간·절차를 알고 있는가.” 이 질문에 답하지 못하면 시장규모가 커도 제품 요구사항은 흔들립니다. 반대로 답할 수 있다면 제안서의 기술 목표, 파일럿 조건, 사업화 계획은 더 차분해집니다. 시장검증은 심사위원에게 보여주기 위한 장식이 아니라, 만들지 않아도 될 기능을 줄이고 먼저 검증해야 할 요구사항을 고르는 안전장치입니다.

R&D 고객발굴·시장검증 체크리스트 작성에 참고한 출처

  • [S1] [NSF, About I-Corps](https://www.nsf.gov/funding/initiatives/i-corps/about-i-corps)
  • [S2] [NSF, National Teams Applicants - I-Corps](https://www.nsf.gov/funding/initiatives/i-corps/national-teams-applicants)
  • [S3] [Strategyzer, Value Proposition Canvas](https://www.strategyzer.com/library/the-value-proposition-canvas)
  • [S4] [The Lean Startup, Methodology](https://theleanstartup.com/principles)
  • [S5] [Steve Blank, Customer Development](https://steveblank.com/tag/customer-development/)
  • [S6] [기업마당, 2026년 중소기업 기술개발 지원사업 통합 공고](https://www.bizinfo.go.kr/sii/siia/selectSIIA200Detail.do?pblancId=PBLN_000000000116943)
  • [S7] [NSF SBIR, For awardees - Phase I](https://seedfund.nsf.gov/resources/awardees/phase-1/)
  • [S8] [중소기업기술정보진흥원, 2026년 바뀌는 중소벤처 기술혁신 지원정책 안내](https://tipa.or.kr/s040101/view/id/16695)
  • [S9] [IRIS, 2026년도 10대 메가프로젝트 기술산업화 사업공고](https://www.iris.go.kr/contents/retrieveBsnsAncmView.do?ancmId=016294&bsnsAncmSn=1&bsnsYyDetail=2026&chngRcveDeFro=2025%2F12%2F23&chngRcveDeTo=2026%2F01%2F30&sorgnBsnsCd=S050521)
  • [S10] [IRIS, 2026년 글로벌 클러스터 R&BD](https://www.iris.go.kr/contents/retrieveBsnsAncmView.do?ancmId=017832&bsnsAncmSn=1&bsnsYyDetail=2026&chngRcveDeFro=2026%2F05%2F04&chngRcveDeTo=2026%2F05%2F20&sorgnBsnsCd=S049683)