R&D 주제를 고를 때 팀이 먼저 묻는 질문은 대개 "기술적으로 가능한가"입니다. 그런데 제품개발 과제에서는 기술 가능성보다 앞서 걸리는 문이 있습니다. 시제품이 전기용품인지, 생활용품인지, 무선 기능이 들어가는지, 건강·진단·치료 표현을 쓰는지, 개인정보나 가명정보를 처리하는지, 클라우드·앱·플랫폼 보안 인증이 필요한지에 따라 연구 범위와 일정이 달라집니다. 이 검토를 과제 선정 뒤로 미루면 제안서 문장은 좋아 보여도 실제 개발 단계에서 시험비, 인증 기간, 데이터 반출 제한, 광고 표현 수정, 실증특례 필요성이 뒤늦게 튀어나옵니다.
이 글은 법률 자문이 아닙니다. 특정 제품이 어떤 허가·인증을 반드시 받아야 한다고 단정하지도 않습니다. 대신 제품개발팀이 R&D 주제를 선택하기 전에 "어떤 규제·인증 질문을 누구에게 확인해야 하는가"를 빠르게 나누는 위험 선별표를 제공합니다. 기존 rndatlas의 선행조사, 사업화 로드맵, 데이터 관리계획 글이 각각 기술근거·상용화증거·연구기록을 다뤘다면, 이 글은 그보다 앞선 단계에서 인증 대상, 안전·개인정보·보안 제약, 시험기관, 증거기록을 한 장으로 묶는 데 집중합니다.
빠른 결론
R&D 주제 후보가 제품으로 이어질 가능성이 있다면 아이디어 회의에서 바로 네 가지를 분리해야 합니다. 첫째, KC·전파·의료기기처럼 제품군별 사전 인증이나 허가가 있는지 확인합니다. 둘째, 개인정보·보안·안전 데이터를 쓰는지 확인합니다. 셋째, 어느 시험기관 또는 담당기관에 사전 문의해야 하는지 정합니다. 넷째, "해당 없음"이라고 판단한 근거까지 증거기록으로 남깁니다. 이 네 칸이 비어 있으면 과제 선정 후 일정과 예산이 흔들릴 가능성이 큽니다.
R&D 규제·인증 리스크는 기술 난이도보다 제품 경계에서 먼저 생깁니다
규제 리스크는 "위험한 제품"에만 생기지 않습니다. 같은 센서 모듈이라도 산업설비 내부에서 쓰는 부품인지, 소비자가 충전해 쓰는 전기제품인지, 어린이가 만질 수 있는 생활용품인지, 무선 송수신을 하는 기자재인지에 따라 확인 경로가 달라집니다. 같은 알고리즘도 연구용 분석 도구인지, 의료적 판단을 보조한다고 광고하는 소프트웨어인지, 개인정보를 계속 수집하는 서비스인지에 따라 검토해야 할 법령과 기관이 달라집니다.
과제 선정 전 검토의 목적은 정답을 확정하는 것이 아니라 막히는 경로를 빨리 보이게 하는 것입니다. 국가기술표준원은 전기용품 안전관리에서 안전인증, 안전확인, 공급자적합성확인 등 위해 수준에 따른 절차를 나눠 안내합니다[S1]. 국립전파연구원은 방송통신기자재 등에 대해 적합인증, 적합등록, 자기적합확인, 잠정인증 중 해당 절차를 받아야 한다고 설명합니다[S3]. 식품의약품안전처 의료기기전자민원시스템은 의료기기 1등급 신고, 2등급 인증, 3·4등급 허가 등 민원 범위를 구분해 안내합니다[S4]. 이 자료들이 말해 주는 핵심은 간단합니다. 연구 주제가 "기술"에서 "제품"으로 바뀌는 순간 분류 질문이 먼저 필요합니다.
제품개발팀이 흔히 놓치는 부분은 "아직 연구 단계라서 괜찮다"는 표현입니다. 연구·개발 목적의 면제나 실증특례가 있을 수는 있지만, 그것은 아무 기록 없이 진행해도 된다는 뜻이 아닙니다. 어린이제품 안전인증 면제 조건처럼 연구·개발이나 수출 목적 제조·수입이 별도 확인 대상이 될 수 있고[S7], ICT 규제샌드박스처럼 법령이 모호하거나 불합리할 때 신속처리·임시허가·실증특례를 검토하는 제도도 있습니다[S8]. 그러므로 과제 선정 회의에서는 "인증이 필요하다/필요 없다"보다 "면제, 사전문의, 실증특례, 정식시험 중 어느 경로를 확인해야 하는가"가 더 안전한 질문입니다.
과제 선정 전 1차 분류표: KC·전파·의료기기·개인정보·보안을 한 번에 봅니다
R&D 후보가 여러 개라면 처음부터 자세한 법령 검토를 할 필요는 없습니다. 대신 제품 경계가 바뀌는 질문을 표로 나누면 됩니다. 전원 연결, 배터리, 무선통신, 인체 접촉, 건강·진단 표현, 어린이 사용 가능성, 개인정보 처리, 클라우드 운영, 외부 실증 장소, 해외 반출 여부가 1차 분류 기준입니다. 이 질문 중 하나라도 "예"라면 연구계획서의 기능명만으로는 부족합니다. 적용 제품군, 시험기관, 제출자료, 데이터 처리근거, 사용자 고지 방식까지 별도 칸을 만들어야 합니다.
| 선별 질문 | 먼저 확인할 경로 | 과제 선정 전에 남길 증거 |
|---|---|---|
| 전원, 충전기, 배터리, 모터, 가열부가 있는가 | KATS·Safety Korea의 전기용품·생활용품 안전관리 대상 | 제품 구성도, 모델 구분, 전기적 사양, 시험 필요성 메모 |
| 블루투스, 와이파이, LTE, RFID, 센서 송수신이 있는가 | 국립전파연구원 적합성평가와 지정시험기관 | 무선모듈 사양, 주파수, 통신방식, 기존 인증 모듈 사용 여부 |
| 진단, 치료, 건강상태 판단, 의료기관 사용을 암시하는가 | MFDS 의료기기 허가·인증·신고 경로 | 사용목적 문장, 대상 사용자, 출력값의 의미, 광고 표현 초안 |
| 개인정보, 위치, 생체, 영상, 음성, 로그를 수집하는가 | 개인정보보호위원회·개인정보 포털 가이드라인 | 수집항목 목록, 가명처리 필요성, 접근권한, 보관·파기 기준 |
| 정보통신서비스, 클라우드, 대규모 이용자 데이터가 있는가 | KISA ISMS-P 또는 보안관리체계 요구사항 | 시스템 구성도, 보호대책, 외부접속, 취약점 점검 계획 |
| 기존 규정으로 출시·실증이 막히거나 모호한가 | ICT 규제샌드박스 신속처리·임시허가·실증특례 | 막히는 규정, 실증범위, 이용자 보호조치, 책임분담 초안 |
이 표의 목적은 "모든 기관을 방문하라"가 아닙니다. 각 후보 주제가 어느 문에서 멈출 수 있는지 비교하는 것입니다. 예를 들어 같은 AI 센서 과제라도 공장 내부 불량검사 장비라면 전기·전파·산업안전 질문이 먼저 오고, 피부상태를 판정해 소비자 앱에 보여주는 제품이라면 의료기기성, 개인정보, 광고 표현, 보안 질문이 먼저 옵니다. 주제의 기술 난이도가 비슷해도 인증 리스크가 다르면 R&D 예산, 기간, 참여기관 구성이 달라져야 합니다.
KC와 전파 적합성평가는 시험기관과 모델 구분을 초기에 고정해야 합니다
KC 관련 검토에서 가장 위험한 문장은 "나중에 인증 받으면 된다"입니다. 국가기술표준원 안내에 따르면 안전인증 대상 전기용품은 국내 제조의 경우 출고 전, 수입제품은 통관 전 모델별 안전인증을 받아야 하는 구조입니다[S1]. 안전확인이나 공급자적합성확인도 제품 설명서, 시험결과서, 표시 기준 같은 자료가 필요할 수 있습니다[S2]. 제품개발팀 입장에서는 "인증 신청서"보다 먼저 모델 구분을 정해야 합니다. 배터리 용량, 어댑터, 외함 재질, 무선모듈, 펌웨어 기능이 바뀌면 같은 연구성과라도 다른 모델로 취급될 수 있기 때문입니다.
전파 적합성평가도 비슷합니다. 국립전파연구원은 방송통신기자재 제조·판매·수입 전에 적합성평가를 받아야 하는 제도를 안내하고, 지정시험기관 현황을 공개합니다[S3][S9]. 연구팀이 이미 인증된 무선모듈을 쓴다고 해서 완제품 검토가 자동으로 끝나는 것은 아닙니다. 안테나, 외함, 전원부, 펌웨어, 통신 방식, 판매 형태가 완제품 기준의 판단에 영향을 줄 수 있습니다. 따라서 R&D 과제 후보에서 무선 기능이 보이면 "모듈 인증서가 있다"로 끝내지 말고 완제품 기준의 문의 필요성을 표시해야 합니다.
KC·전파 검토에서 피해야 할 판단
- 시제품이라 판매 전까지는 아무 시험도 필요 없다고 단정하는 말
- 기존 부품 인증서만으로 완제품 인증 가능성을 확정하는 말
- 시험기관 한 곳의 비공식 답변을 전체 제품군 판단으로 확대하는 말
- 모델명, 부품 변경, 펌웨어 버전 변경이 인증 범위에 미치는 영향을 기록하지 않는 방식
초기 증거기록은 복잡할 필요가 없습니다. 제품 후보별로 전원 방식, 소비자 접촉 여부, 무선 기능, 사용 장소, 판매·실증 계획, 모델 변경 가능성을 한 장에 적습니다. 그 다음 KATS 안내, Safety Korea 인증정보 검색, RRA 적합성평가 검색, 지정시험기관 목록 중 어느 경로를 확인했는지 남깁니다. "해당 없음"도 기록 대상입니다. 나중에 기능이 추가되면 왜 다시 검토해야 하는지 비교할 수 있기 때문입니다.
의료기기성과 개인정보는 기능보다 표현과 데이터 흐름을 함께 봐야 합니다
의료기기 리스크는 센서의 정밀도만으로 결정되지 않습니다. 제품이 무엇을 측정하는지, 출력값을 어떻게 설명하는지, 사용자가 그 값을 어떤 의사결정에 쓰게 되는지, 광고 문구가 진단·치료·예방을 암시하는지에 따라 검토 강도가 달라집니다. MFDS 의료기기전자민원시스템은 1등급 신고, 2등급 인증, 3·4등급 허가 등 민원 범위를 구분하고 있으며[S4], 의료기기 구매 안내에서도 허가·인증·신고 받은 제품 사용을 강조합니다[S5]. R&D 단계에서는 "의료기기가 아니다"라고 쓰기보다 사용목적 문장을 따로 떼어 놓고 전문가 확인이 필요한 지점을 표시하는 편이 안전합니다.
개인정보 검토도 마찬가지입니다. 2026년 3월 개정된 가명정보 처리 가이드라인은 데이터 활용 환경 변화에 맞춘 위험도 기반 판단 체계를 안내합니다[S6]. 제품개발팀은 수집항목만 적어서는 부족합니다. 원자료, 가명처리본, 분석결과, 모델 학습 산출물, 로그, 제3자 제공자료를 나누고, 각 자료에 접근할 역할과 보관기간을 기록해야 합니다. 특히 영상·음성·생체·위치 정보가 들어가면 연구 편의보다 재식별 가능성, 결합 가능성, 외부 반출 제한을 먼저 봐야 합니다.
R&D 후보 평가표에는 의료기기성과 개인정보를 같은 줄에 두지 말고 서로 영향을 주는 칸으로 배치하는 것이 좋습니다. 예를 들어 피부 이미지로 건강 위험도를 보여주는 앱은 의료기기성 검토와 개인정보·가명정보 검토가 동시에 필요합니다. 반대로 공장 설비의 진동 데이터를 분석하는 과제는 의료기기성은 낮아도 영업비밀, 보안, 현장 반출 제한이 중요할 수 있습니다. 두 경우 모두 "데이터를 쓴다"는 말은 같지만 필요한 증거는 완전히 다릅니다.
보안 인증과 규제샌드박스는 개발 뒤 해결책이 아니라 설계 제약입니다
보안은 제품 출시 직전에 붙이는 체크박스가 아닙니다. KISA의 ISMS-P 안내는 신청, 계약, 심사, 보완조치, 심의, 인증서 발급으로 이어지는 인증심사 절차를 제시합니다[S10]. 모든 R&D 과제가 ISMS-P 인증 대상이라는 뜻은 아니지만, 개인정보와 주요 정보자산을 다루는 서비스라면 관리체계, 보호대책, 개인정보 처리 단계별 요구사항을 초기에 검토해야 합니다. 특히 외부 클라우드, 원격 업데이트, 관리자 페이지, 고객 데이터 분석 기능이 있으면 보안 요구사항이 연구범위와 개발 아키텍처를 바꿀 수 있습니다.
규제샌드박스는 "규제를 피하는 방법"이 아니라 법령이 모호하거나 기존 규정과 신기술이 맞지 않을 때 실증 범위와 이용자 보호조치를 정해 검토받는 경로입니다. NIPA의 ICT 규제샌드박스 안내는 신속처리, 임시허가, 실증특례를 구분해 설명합니다[S8]. 과제 선정 전에는 샌드박스 신청 여부를 확정하기보다 어느 기능이 현행 규정과 충돌하는지, 실증 장소와 대상자는 누구인지, 사고·피해 발생 시 어떤 보호조치를 둘 것인지를 기록하면 됩니다. 이 기록이 없으면 "혁신 서비스"라는 문장은 있지만 실제 실증 설계는 비어 있게 됩니다.
보안과 샌드박스 검토는 인증 담당자만의 일이 아닙니다. 기획자는 사용 시나리오와 약관·고지 문구를, 개발자는 시스템 구성도와 로그 흐름을, 연구책임자는 실증 목표와 제외 범위를, 사업 담당자는 고객·기관 협력 조건을 함께 정리해야 합니다. 초기 2주 안에 이 네 역할이 같은 표를 보지 않으면, 나중에 보안심사나 실증협의에서 서로 다른 제품을 설명하게 됩니다.
시험기관 문의 전에는 질문서와 증거기록 폴더를 먼저 만듭니다
시험기관이나 담당기관에 문의하기 전에는 "이 제품 인증이 필요한가요"라는 한 줄 질문만 보내지 않는 편이 좋습니다. 기관은 제품 구분, 사용목적, 사양, 판매·실증 형태, 부품 구성, 변경 가능성에 따라 답을 달리할 수 있습니다. 질문이 흐리면 답도 흐립니다. 과제 선정 단계에서는 정식 신청서가 아니라도 제품 개요, 기능 범위, 대상 사용자, 사용 장소, 데이터 흐름, 예상 모델, 문의하고 싶은 판단 지점을 한 페이지로 정리해야 합니다.
증거기록 폴더는 다음 다섯 묶음이면 충분합니다. 첫째, 제품·서비스 정의입니다. 기능 목록, 제외 기능, 사용목적 문장, 광고에 쓰지 않을 표현을 넣습니다. 둘째, 인증·시험 문의 기록입니다. 문의일, 기관명, 담당부서, 질문서, 회신 요지를 보관합니다. 셋째, 데이터·보안 기록입니다. 수집항목, 가명처리 여부, 접근권한, 보관기간, 외부 반출 조건을 넣습니다. 넷째, 실증·사용자 보호 기록입니다. 실증 장소, 참여자, 위험고지, 사고 대응, 중단 기준을 적습니다. 다섯째, 결정 로그입니다. 왜 이 R&D 주제를 유지·수정·보류했는지 한 문단으로 남깁니다.
| 증거기록 묶음 | 최소 파일 | 나중에 막는 문제 |
|---|---|---|
| 제품·서비스 정의 | 기능범위표, 사용목적 문장, 제외기능 목록 | 의료기기성·전파·KC 문의 때 제품 설명이 매번 바뀌는 문제 |
| 인증·시험 문의 | 기관별 질문서, 회신일, 회신 요약 | 비공식 답변을 과장하거나 출처를 잃는 문제 |
| 데이터·보안 | 데이터 흐름도, 접근권한표, 가명처리 판단 메모 | 개인정보·보안 요구사항을 개발 뒤에 발견하는 문제 |
| 실증·사용자 보호 | 실증범위, 고지문 초안, 사고 대응 기준 | 규제샌드박스나 현장실증에서 보호조치가 빈약한 문제 |
| 결정 로그 | 주제 유지·수정·보류 사유 | 과제 선정 회의의 판단 근거가 사라지는 문제 |
이 폴더는 평가자를 설득하기 위한 장식이 아닙니다. 팀 내부 의사결정의 안전장치입니다. "KC는 나중에", "개인정보는 개발하면서", "보안은 출시 전에"라는 문장이 보이면 결정 로그에 위험으로 남겨야 합니다. 반대로 공식 안내와 시험기관 문의를 통해 현재 단계에서 확인할 수 있는 범위와 아직 확정할 수 없는 범위를 나눴다면, 그 주제는 불확실성이 있어도 관리 가능한 후보가 됩니다.
R&D 주제 후보를 통과·수정·보류로 나누는 30분 체크 절차
회의 시간이 짧다면 30분만 써도 1차 선별은 가능합니다. 처음 5분은 제품 경계를 정합니다. 최종 산출물이 부품인지, 완제품인지, 소프트웨어인지, 데이터셋인지, 서비스인지 말합니다. 다음 10분은 KC·전파·의료기기·개인정보·보안·샌드박스 표에 예·아니오·불명확을 표시합니다. "불명확"은 실패가 아니라 문의가 필요한 지점입니다. 그 다음 10분은 가장 큰 일정 리스크를 고릅니다. 시험기간, 허가·인증 범위, 데이터 반출, 외부 실증, 보안심사 중 무엇이 과제 기간을 흔들 수 있는지 봅니다. 마지막 5분은 다음 행동을 정합니다. 시험기관 문의, 개인정보 검토, 제품 표현 수정, 주제 범위 축소, 컨소시엄 파트너 추가 중 하나가 나와야 합니다.
통과 후보는 인증·규제 질문이 없다는 뜻이 아닙니다. 질문이 작고, 확인 경로가 분명하고, 과제 기간 안에서 처리할 수 있다는 뜻입니다. 수정 후보는 기술 주제는 좋지만 제품 표현이나 데이터 흐름, 실증범위를 바꾸면 위험이 줄어드는 경우입니다. 보류 후보는 핵심 기능이 정식 허가·인증, 장기 임상·실증, 높은 보안 인증, 복잡한 개인정보 결합 없이는 설명되지 않는 경우입니다. 이 판단은 사업성을 낮게 보는 것이 아니라 R&D 과제의 범위와 일정에 맞지 않는 위험을 분리하는 작업입니다.
내부 링크 흐름도 이 기준에 맞춰 잡으면 좋습니다. 기술 차별성과 선행근거가 약하다면 R&D 제안서 선행조사 체크리스트로 돌아갑니다. 과제 종료 뒤 시장·인증·고객 증거를 나누고 싶다면 R&D 결과 사업화 로드맵 체크리스트를 봅니다. 개인정보와 연구데이터 기록이 핵심이면 R&D 데이터 관리계획과 연구기록 체크리스트가 다음 단계입니다. 일정과 예산 신호를 함께 보려면 2026 R&D 예산과 사업일정 읽기를 연결하면 됩니다.
이 체크리스트가 대신 판단하지 않는 것과 마지막 확인 기준
이 글의 체크리스트는 법령 해석, 허가 가능성, 인증 면제 여부, 개인정보 적법성, 의료기기 해당성, 보안 인증 취득 가능성을 대신 판단하지 않습니다. 특히 의료기기, 전파, KC, 개인정보, 보안, 규제샌드박스는 제품 사양과 사용맥락이 바뀌면 결론도 바뀔 수 있습니다. 따라서 최종 제안서나 개발계약서에 넣기 전에는 담당기관, 지정시험기관, 개인정보·보안 전문가, 분야별 규제 담당자에게 현재 사양 기준으로 다시 확인해야 합니다.
마지막 기준은 세 문장입니다. 첫째, "우리 제품 후보가 어떤 인증·허가·신고·시험·문의 경로에 걸릴 수 있는지 알고 있다." 둘째, "해당 없음으로 본 항목도 왜 그렇게 판단했는지 출처와 날짜를 남겼다." 셋째, "인증과 규제 확인 때문에 바뀔 수 있는 기능, 일정, 예산, 데이터 처리 범위를 과제 선정표에 반영했다." 이 세 문장이 준비되면 R&D 주제 선정은 단순한 아이디어 투표가 아니라 실행 가능한 제품개발 위험 선별이 됩니다.