피부 사진 정리에서 질병 판단 지원으로: 앱 기능을 추가할 때 달라지는 검토
사진 정리 앱에 질환 분석 기능을 더하는 가상 사례로 기능·사용목적과 의료기기 해당 여부 검토를 연결합니다.
피부 사진을 날짜별로 모아 보여주던 앱에 피부 질환의 가능성을 분석하는 기능을 넣는다면, 기획 단계에서 의료기기 해당 여부를 검토할 이유가 생깁니다.
화면이 하나 늘어서가 아니라, 앱이 제공하는 결과가 질병 판단에 사용되도록 기능과 목적이 달라지기 때문입니다.
이 글은 국내 출시를 준비하는 소프트웨어 기획·개발 실무자를 위한 설명입니다.
아래 앱은 차이를 설명하기 위한 가상 사례이며, 실제 제품에 대한 식약처의 해당 여부 판단 사례가 아닙니다.
같은 사진을 받아도 제공하는 결과가 다릅니다
첫 번째 기획은 일반 스마트폰 사진을 날짜별로 정렬하고 개인이 다시 찾아볼 수 있게 하는 앨범입니다.
피부 상태를 분석하거나 질병 가능성을 계산하는 기능은 두지 않았다고 가정합니다.
두 번째 기획은 같은 사진에서 특징을 분석하여 특정 피부 질환의 가능성에 관한 결과를 제공하고, 그 결과를 질병 판단에 활용하도록 설계합니다.
| 비교할 항목 | 사진 정리 기능 | 추가하려는 질환 분석 기능 |
|---|---|---|
| 입력 | 사용자가 보관하려는 일반 사진 | 질환 가능성 분석에 사용할 피부 사진 |
| 처리 | 촬영일 정렬, 사진 검색 | 사진 특징 분석과 질환 관련 결과 산출 |
| 출력 | 날짜별 사진 목록 | 질환 가능성에 관한 분석 결과 |
| 기획한 활용 | 개인 사진을 찾아보기 | 질병 판단을 지원하기 |
| 검토의 초점 | 가정한 기능·목적과 실제 구현의 일치 | 의료 목적의 결과 제공에 따른 해당 여부 검토 |
입력 자료가 같더라도 처리와 결과의 사용목적은 달라질 수 있습니다.
화면은 가상 기능을 비교한 자체 개념도이며 실제 환자 자료나 진단 결과가 아닙니다.
여기서 앨범이라는 이름만으로 비의료기기라고 확정하지는 않습니다.
의료용 영상의 표시·처리, 의료기기와의 연결, 다른 진단 기능과의 결합 등 실제 구성에 따라 검토할 조건이 달라집니다.
위 비교는 의료용 영상 시스템 전반에 대한 제외 기준을 설명하는 표가 아닙니다.
‘판단’이라는 단어보다 무엇을 위한 판단인지가 중요합니다
사진을 촬영일에 따라 분류하는 소프트웨어도 내부적으로 비교와 선택을 수행합니다.
이런 연산이 있다는 사실만으로 의료기기라고 판단할 수는 없습니다.
이번 사례에서 달라지는 것은 피부 질환의 가능성이라는 결과를 만들어 질병 판단을 돕는 목적입니다.
「디지털의료제품법」 제2조제2호는 디지털 기술이 적용된 의료기기 등을 전제로, 질병의 진단·치료나 예후 관찰 등을 위한 제품을 디지털의료기기의 범위에 포함합니다.
식약처의 디지털의료제품 안내도 독립형 소프트웨어를 관련 기술에 포함하고 의료 목적의 제품을 설명합니다.
따라서 앱 형태라는 이유만으로 검토 대상에서 빠지는 것은 아닙니다.
[근거 1·2]
‘가능성’이나 ‘참고용’이라는 표현도 기능 검토를 대신하지 않습니다.
결과의 표현 방식과 함께 어떤 분석을 수행하고 누가 어떤 판단에 쓰도록 제공하는지를 구체적으로 살펴야 합니다.
의사가 최종 판단한다는 조건 역시 그 앞단 소프트웨어가 수행하는 역할을 설명하는 정보로 다룹니다.
화면을 보기 전에 입력·처리·출력·사용을 연결합니다
실무에서는 기능 이름보다 실제 동작을 한 줄로 적어보는 편이 유용합니다.
다음은 MedQraft의 기획 검토 제안이며 법정 신청서 양식은 아닙니다.
사용자가 피부 사진을 입력하면, 소프트웨어가 사진의 특징을 분석해 질환 가능성에 관한 결과를 제공하고, 지정된 사용자가 이를 질병 판단을 돕는 정보로 활용한다.
이 문장에는 아직 결정해야 할 부분이 남아 있습니다.
사용자는 일반인인지 의료인인지, 어느 질환과 어느 신체 부위를 대상으로 하는지, 사진의 취득 조건은 무엇인지, 출력이 무엇을 의미하는지 등입니다.
확인되지 않은 성능 수치나 대상을 문장에 채워 넣지 않고, 결정된 사항과 미정 사항을 나누어 기록합니다.
기획 검토에서는 사진 입력부터 결과가 사용되는 지점까지 이어서 봅니다.
이 흐름은 가상 앱의 기능 설명이며, 진단 알고리즘이나 성능이 검증되었다는 뜻은 아닙니다.
화면에는 ‘분석 결과’라고 쓰여 있어도, 개발 요구사항에는 단순 정렬만 적혀 있다면 같은 제품을 설명하고 있지 않습니다.
반대로 기획서는 개인 기록이라고 적었는데 실제 기능이 질환 가능성을 산출한다면, 그 차이를 먼저 해소해야 해당 여부 검토에 필요한 제품 설명을 만들 수 있습니다.
기능 추가 전후의 기획서를 이렇게 비교합니다
| 기록할 내용 | 이번 가상 사례에서 구체화할 사항 |
|---|---|
| 대상과 사용자 | 누구의 어떤 피부 사진을 누가 입력하고 결과를 읽는가 |
| 실제 처리 | 날짜별 정렬만 하는가, 질환 관련 특징을 분석하는가 |
| 출력의 의미 | 사진 목록인가, 질환 가능성이나 다른 의학적 정보인가 |
| 사용목적 | 결과를 개인 기록 조회에 쓰는가, 질병 판단 지원에 쓰는가 |
| 사용 환경과 연결 | 단독 앱인가, 의료기기·진료 시스템과 연결되는가 |
| 미정 사항 | 분석 대상, 사용 조건, 결과의 한계 중 무엇이 아직 결정되지 않았는가 |
변경 전후 화면과 기능 설명을 나란히 두면 새 기능이 단순한 화면 개선인지, 제품의 목적에 영향을 주는 변경인지 드러납니다.
이 단계에서 정리한 자료는 해당 여부를 문의할 때도 제품을 일관되게 설명하는 데 도움이 됩니다.
애매한 경우에는 기능·사용목적·작동 원리와 결과 예시를 갖추어 식약처의 해당 여부 검토 경로를 확인합니다.
[근거 3]
해당 여부와 등급·허가 검토는 구분합니다
이번 사례의 결론은 ‘질환 분석 기능을 넣었으니 특정 등급으로 확정된다’가 아닙니다.
실제 제품의 기능과 사용목적을 바탕으로 의료기기 해당 여부를 검토하고, 그 결과에 따라 적용되는 분류·등급과 허가 등 후속 요건을 검토하는 순서입니다.
앱 화면만으로 등급이나 필요한 시험 목록을 단정하지 않습니다.
먼저 검토할 제품을 구체적으로 정의하고 해당 여부를 판단할 근거를 마련합니다.
이후 적용되는 분류·등급·허가 요건을 검토합니다.
자체 정리한 업무 흐름이며 공식 판정 절차를 대체하지 않습니다.
검토회의에서는 세 질문이면 논점을 좁힐 수 있습니다.
새 기능이 만들어내는 결과는 무엇인지, 그 결과를 사용자가 무엇을 판단하는 데 쓰도록 하는지, 기획서와 실제 화면·동작이 그 목적을 같은 뜻으로 설명하는지입니다.
답이 달라진다면 기능 목록에 한 줄을 추가하는 데서 끝내지 않고 제품 정의를 함께 갱신합니다.
의료기기에 해당하지 않는다는 판단이 모든 관련 제도에서 제외된다는 뜻은 아닙니다.
국내에는 디지털의료·건강지원기기라는 별도 범주도 있으므로 실제 제품의 목적과 기능에 맞춰 적용 범위를 살펴야 합니다.
[근거 2]
관련 글
- 의료기기 소프트웨어 요구사항과 시험 근거: 제품의 기능·목적을 구체화한 다음 요구사항과 시험 근거를 연결할 때 참고할 글입니다.
- MedQraft 인사이트 전체 보기: 관련 인허가·설계·시험 실무 글을 함께 볼 수 있습니다.
출처와 확인 범위
- 국가법령정보센터, 디지털의료제품법 제2조제2호.
시행 2026년 10월 8일 법령의 디지털의료기기 정의 확인. - 식품의약품안전처 의료기기전자민원시스템, 디지털의료제품 민원안내.
디지털의료제품 범위, 독립형 소프트웨어 기술, 디지털의료·건강지원기기 안내 확인. - 정부24, 의료기기 해당 여부 검토 신청.
해당 여부 검토 민원 경로 참고.
확인일: 2026년 10월 22일.
국내 제도 기준입니다.
가상 앱 비교, 기획 문장과 점검 질문은 MedQraft의 자체 설명입니다.
실제 제품의 해당 여부나 등급에 대한 식약처 판정 사례로 인용하지 않습니다.