[R&D랩 컬럼] 고객의 불편을 R&D 문제로 바꾸는 문제정의 워크숍
고객의 말에서 증상·원인·검증기준을 분리해 기술개발 과제로 전환하는 실습법
AI추천글 · 핵심 요약
고객의 불편은 곧바로 R&D 문제가 되는 것이 아니라 고객 상황, 관찰된 증상, 원인 가설, 기존 해결책의 한계를 분리해 검증해야 한다. 문제정의 워크숍에서는 사실과 추정을 구분한 뒤 핵심 개발성능과 시험방법으로 이어지는 문제문장을 완성한다.
고객의 불편을 들었다고 바로 R&D 과제가 되는 것은 아니다. “불편하다”, “느리다”, “오류가 많다”는 말은 현상에 가깝다. 연구개발 문제는 누가 어떤 상황에서 무엇 때문에 어려움을 겪고 있으며, 기존 방법으로 해결되지 않는 원인이 무엇인지 설명해야 한다. 그래야 개발할 기술과 검증할 성능이 자연스럽게 이어진다.
고객의 말은 출발점이지 문제정의의 결론이 아니다
고객 인터뷰에서 나온 요구를 그대로 개발기능으로 옮기면 과제가 흔들리기 쉽다. “자동화 기능이 필요하다”는 말만으로는 왜 자동화가 필요한지, 어느 과정의 어떤 손실을 줄여야 하는지 알 수 없다. 먼저 고객이 실제로 하는 일, 반복되는 실패, 손실과 우회행동을 확인해야 한다. 요구기능보다 문제상황을 먼저 기록하는 이유다.
공식 사실: 국가연구개발혁신법 제10조는 선정평가에서 연구개발과제의 창의성과 수행계획의 충실성, 연구개발 역량, 성과 활용 가능성과 파급효과, 사업 추진계획과의 부합성 등을 보도록 규정한다. 시행령 제12조는 다른 연구개발과제와의 차별성, 연구개발 주제·목표·수행방식의 차이도 평가하도록 정한다. 개별 사업의 평가항목과 배점은 공고문이 우선이다.
문제정의 보드는 네 칸으로 나눈다
멘토K 실무 제안: 워크숍에서는 포스트잇을 ‘고객 상황–관찰된 불편–원인 가설–R&D 문제’ 네 칸에 배치한다. 첫째, 고객 상황에는 사용자·업무·환경을 적는다. 둘째, 관찰된 불편에는 발생 빈도, 시간, 비용, 품질 저하처럼 확인 가능한 현상을 쓴다. 셋째, 원인 가설에는 공정, 소재, 알고리즘, 데이터, 장비 등 기술적으로 검증할 원인을 적는다. 넷째, R&D 문제에는 기존 방법의 한계와 새 기술이 해결해야 할 핵심 성능을 한 문장으로 정리한다.
포스트잇 색도 구분한다. 파란색은 고객에게 확인한 사실, 초록색은 내부에서 세운 원인 가설, 흰색은 추가 확인이 필요한 질문으로 정한다. 색 구분은 사실과 추정을 섞지 않게 해준다. 인터뷰 한두 번의 의견을 시장 전체의 사실로 확대하지 않는 것도 중요하다.
증상과 원인을 분리해야 개발목표가 보인다
예를 들어 “검사 시간이 길어 납기가 지연된다”는 것은 증상이다. 원인이 영상 판독 정확도인지, 시료 준비시간인지, 장비 교체시간인지에 따라 개발과제는 전혀 달라진다. 이 사례와 수치는 특정 기업의 실제 데이터가 아니라 가상 예시다. 워크숍에서는 현장기록, 작업일지, 불량·민원 데이터, 인터뷰 메모로 원인 가설을 검증한다.
좋은 문제문장은 다음 구조를 갖는다. “어떤 고객이 어떤 상황에서 어떤 원인 때문에 어떤 손실을 겪고 있으며, 기존 방법은 어떤 기술적 한계로 이를 해결하지 못한다.” 이 문장 뒤에 목표 성능과 시험방법을 붙일 수 있어야 연구개발 문제로 발전한 것이다.
90분 문제정의 실습의 진행 순서
- 사실 수집: 고객 발언, 관찰기록, 공정·서비스 데이터를 한 장에 모은다.
- 증상 분리: 불편, 손실, 우회행동을 원인 가설과 따로 놓는다.
- 원인 검증: 확인된 원인과 추정 원인을 표시하고 추가 조사 질문을 만든다.
- 기술문제 전환: 기존 해결방법의 한계와 필요한 핵심 성능을 연결한다.
- 평가 관점 점검: 사업목적, 차별성, 수행 가능성, 성과 활용과 한 흐름인지 확인한다.
2026년 중소벤처기업부 R&D 공고도 IRIS를 통해 연구개발계획서 작성 가이드를 안내한다. 다만 실제 신청에서는 반드시 해당 사업의 최신 공고, 연구개발계획서 양식, 평가기준과 제출서류를 다시 확인해야 한다.
워크숍이 남겨야 할 결과물
문제정의 워크숍의 결과는 아이디어 목록이 아니다. 고객문제 한 문장, 사실·가설 구분표, 원인 검증 질문, 기존 해결책 한계, 핵심 개발성능, 다음 조사계획이 남아야 한다. 이 여섯 가지가 준비되면 과제명, 연구목표, 개발내용, 성능지표 작성으로 넘어갈 수 있다. 반대로 근거가 부족하다면 서둘러 계획서를 쓰기보다 고객과 현장을 다시 확인하는 것이 빠른 길이다.
자주 묻는 질문
고객이 요구한 기능을 바로 R&D 목표로 쓰면 안 되나요?
요구기능은 해결수단에 가깝습니다. 먼저 고객이 어떤 상황에서 어떤 손실을 겪는지, 그 원인이 무엇인지 확인해야 핵심 개발성능과 검증방법을 일관되게 설계할 수 있습니다.
문제정의 단계에서 최소한 어떤 근거를 모아야 하나요?
고객 인터뷰 메모, 현장 관찰기록, 공정·서비스 데이터, 불량·민원·작업시간 자료처럼 문제의 발생과 영향을 확인할 수 있는 근거를 모읍니다. 확인된 사실과 내부 가설은 반드시 구분합니다.
문제정의 워크숍은 몇 시간 과정이 적합한가요?
사전 자료가 준비된 조직은 2~4시간 특강·실습으로 핵심 프레임을 익힐 수 있습니다. 실제 과제를 대상으로 인터뷰 근거, 원인 가설, 개발성능과 검증계획까지 완성하려면 8~16시간 실습 워크숍이 적합합니다.
참고 자료와 확인일
- 국가연구개발혁신법 제10조(연구개발과제 및 수행 연구개발기관의 선정) · 확인 2026-10-06
- 국가연구개발혁신법 시행령 제12조(연구개발과제 및 연구개발기관에 대한 선정평가) · 확인 2026-10-06
- IRIS 2026년도 중소벤처기업부 R&D 사업공고 및 연구개발계획서 작성 가이드 안내 · 확인 2026-10-06
공식 자료의 사실과 별도로 본문의 실습 방법은 멘토K의 실무 제안이다. 사업별 자격·배점·비용 기준은 해당 최신 공고와 지침을 확인해야 한다.
R&D 교육·강의·워크숍 상담
중소기업·스타트업 실무자와 평가기관 연구원을 대상으로 문제정의 실습 8~16시간 실습 워크숍을 진행한다. 교육 목적과 참여자의 경험 수준에 맞춰 사례와 실습을 구성한다.
맞춤 강의·워크숍 상담 신청 시 교육 대상·참여 인원·희망 주제·희망 일정을 남겨 주시기 바란다. 상담: 02-2168-3071 / misiceo@naver.com
#정부지원R&D #R&D문제정의 #중소기업R&D #스타트업R&D #R&D사업계획서 #과제기획 #고객인터뷰 #문제정의워크숍 #R&D교육 #멘토K