본문으로 건너뛰기
고급약 40분

식약처 인허가에서 QA가 준비하는 것 — 디지털의료제품법·적합성 확인보고서·검증 및 유효성확인 보고서·변경허가

국내 의료기기 소프트웨어 인허가는 2025년 1월 시행된 디지털의료제품법 체계로 옮겨 가고 있다. 디지털의료기기의 정의와 제품코드·등급 결정에 소프트웨어 안전성 등급이 쓰이는 방식, 허가 신청 시 제출하는 디지털의료기기소프트웨어 적합성 확인보고서의 항목, 검증 및 유효성확인 보고서의 추적표·시험 환경·분석적 성능 시험, 인공지능 제품의 학습·시험 데이터 기재, 변경허가가 필요한 소프트웨어 변경의 판단, 우수 관리체계 인증과 전자적 침해행위 보안지침을 QA의 산출물 관점에서 다룬다.

  • #식약처
  • #디지털의료제품법
  • #디지털의료기기소프트웨어
  • #적합성확인보고서
  • #검증및유효성확인
  • #변경허가
  • #인허가

개념

법이 바뀌면 제출 서류의 이름이 바뀐다

한국에서 의료기기는 오랫동안 「의료기기법」과 「체외진단의료기기법」으로 관리됐다. 인공지능·로봇·가상융합 기술이 적용된 제품이 늘면서, 이런 제품의 특성에 맞춘 「디지털의료제품법」 이 제정되어 2025년 1월 24일 시행됐다. 디지털의료·건강지원기기 관련 규정은 2026년 1월 24일 부터 시행됐다. 하위 고시와 민원인 안내서가 2025년에 대거 제·개정되었고, 식약처는 2025년 5월 7일 디지털의료기기 관련 가이드라인 6종을 제·개정하면서 디지털의료기기소프트웨어 허가·심사 가이드라인 을 새로 제정했다.

QA에게 중요한 사실은 요구하는 검증의 실질은 IEC 62304·ISO 14971·IEC 62366-1과 크게 다르지 않지만, 제출 양식·용어·판단 기준이 새 체계로 정리됐다 는 것이다. 레슨 1~5에서 만든 증거를 새 양식에 정확히 옮기는 것이 이 레슨의 목표다. 이 분야의 안내서는 개정이 잦으므로 모든 판단은 신청 시점의 법령·고시·민원인 안내서 판본 으로 하고, 프로젝트 문서에 판본을 적는다.

디지털의료제품의 범위

디지털의료제품법은 세 가지를 다룬다.

구분요지
디지털의료기기지능정보·로봇·정보통신 등 디지털기술이 적용된 의료기기(체외진단의료기기 포함)로서 질병의 진단·치료·예후 관찰, 치료 반응·결과 예측, 치료 효과·부작용 모니터링, 재활 보조 등의 목적
디지털융합의약품디지털의료기기 등과 조합된 의약품
디지털의료·건강지원기기디지털의료기기에 해당하지 않지만 의료·건강 지원 목적의 기기 (2026.1.24 시행)

디지털의료기기소프트웨어는 형태로 두 가지다.

  • 독립형 — 하드웨어에 결합되지 않고 범용 컴퓨터·태블릿·스마트폰 같은 환경에서 운영되며, 그 자체로 디지털의료기기에 해당하는 소프트웨어 (예: 영상 분석 AI, 디지털치료기기)
  • 내장형 — 디지털의료기기에 설치되거나 연결되어 제어·구동하거나 데이터를 저장·처리하는 소프트웨어

가이드라인은 별도 표시 기능·사용자 화면 없이 기기를 제어하는 펌웨어 수준의 소프트웨어, 제조·개발용 소프트웨어, 품질관리용 소프트웨어를 적용 범위에서 제외한다. 품질관리용 소프트웨어는 인허가 제출 대상은 아니지만 품질관리기준 차원의 밸리데이션 대상이라는 점(레슨 4)을 기억하자.

제품코드·등급 결정에 소프트웨어 안전성 등급이 들어간다

디지털의료기기는 「디지털의료제품의 분류 및 등급 지정 등에 관한 규정」에 따라 제조사가 먼저 제품코드와 등급을 판단 해서 신청한다. 제품코드는 주된 사용목적(검사·진단· 치료·임상적 관리 유도·정보제공 등), 적용된 디지털기술 유형(독립형 소프트웨어·인공지능·지능형 로봇·초고성능컴퓨팅·가상융합), 기본 유형과 형태로 구성된다.

등급은 사용목적의 의료적 영향과 성능 저하·오작동 시 직·간접 피해 수준 을 함께 고려한다. 식약처 업무 안내서는 이 피해 수준을 소프트웨어 안전성 등급 으로 판단하도록 안내한다.

소프트웨어 안전성 등급정의등급 결정 시 조정
A부상이나 신체적 피해가 발생할 가능성이 없음피해 없음 (−1)
B심각하지 않은 부상(경상)이 발생할 가능성이 있음변동 없음
C심각한 부상 또는 사망이 발생할 가능성이 있음심각한 부상은 변동 없음, 사망 가능성은 +1

정의는 IEC 62304의 A·B·C와 같은 방향이다(레슨 1). 가이드라인의 안전성 등급 판단 예시는 기능별로 위해 요인·위해·심각도·발생 가능성·위험을 적고 소프트웨어 오류로 인한 위험의 발생 가능성은 100%로 간주 한다. 레슨 1·2에서 본 "소프트웨어는 고장 난다고 가정한다"가 국내 안내서에도 그대로 들어가 있다.

여기서 QA가 챙길 실무 포인트가 있다. 안내서는 여러 판본과 여러 문서에 걸쳐 같은 정의를 반복하는데, 본문 서술과 표의 표현이 어긋나 보이는 곳이 생길 수 있다. 이럴 때는 정의 표와 상위 규정(허가·인증·신고·심사 및 평가 등에 관한 규정의 별표)을 기준으로 삼고, 판단이 제출 자료에 영향을 주면 담당 부서에 확인해 그 기록을 남긴다. 등급 판단 근거는 적합성 확인보고서에 들어가므로 판단의 출처 가 중요하다.

디지털의료기기소프트웨어 적합성 확인보고서

허가 심사 시 소프트웨어에 대해 제출하는 핵심 서류가 디지털의료기기소프트웨어 적합성 확인보고서 (규정 별지 서식)와 소프트웨어 검증 및 유효성확인 자료 다. 적합성 확인보고서는 개발 당시 작성된 문서를 확인하기 위한 보고서로, 항목마다 내용을 요약하고 「디지털의료기기 제조 및 품질관리기준」에 따른 제조소의 해당 문서 관리번호 를 함께 적는다. 가이드라인이 안내하는 항목을 QA 산출물과 대응시키면 이렇다.

적합성 확인보고서 항목요약할 내용레슨 1~5의 산출물
명칭 등 정보, 소프트웨어 명칭·버전제품명·제품코드·등급, 대표 모델 소프트웨어 버전형상관리 식별
소프트웨어 형태·기능적 특성내장형·독립형·기타, 제어·측정·분석·진단·데이터 전송·표시 기능아키텍처 문서
소프트웨어 안전성 등급등급과 판단 근거레슨 1 등급 판정, 레슨 2 위험 분석
사용목적기능별 사용목적사용 사양 (레슨 3)
운영환경하드웨어·OS·SOUP의 운영환경레슨 1 SOUP 목록, 레슨 5 SBOM
소프트웨어 개발 — 개발 계획개발 규격·방법·도구, 검증·위험관리·형상관리 계획개발 계획서, 시험 계획서
소프트웨어 개발 — 요구사항 분석요구사항 수립, 위험통제수단, 요구사항 검증 방법SRS, 위험 추적표
소프트웨어 개발 — 구현아키텍처·상세 설계SDS
소프트웨어 개발 — 검증 및 유효성확인제출하는 V&V 자료 요약V&V 보고서
소프트웨어 개발 — 배포검증 결과, 잔여 이상 목록 평가 결과, 배포 버전·개발 환경·보관레슨 1 잔존 이상 평가
유지보수 및 문제해결유지보수 계획, 문제 보고·수정 분석·해결 검증레슨 1 문제 해결 프로세스
위험관리위해 상황·위험통제수단·위험통제수단의 검증·변경의 위험관리레슨 2 구현·효과 검증
형상관리소프트웨어 식별·변경관리·상태 기록형상관리 계획·기록

표를 보면 IEC 62304의 5~9장 구조가 그대로 들어 있다. 레슨 1의 산출물 체계를 갖춘 조직이라면 적합성 확인보고서는 문서 관리번호를 찾아 요약하는 일 이다. 체계가 없는 조직은 이 서식을 채우다가 산출물이 없다는 것을 처음 발견한다.

"위험관리" 항목의 위험통제수단의 검증 과 "배포" 항목의 잔여 이상 목록 평가 결과 가 QA가 가장 직접적으로 쓰는 칸이다. 요약에 "검증 완료"만 쓰지 말고, 구현 검증과 효과 검증이 각각 어느 보고서의 어느 절에 있는지 관리번호로 가리킨다.

검증 및 유효성확인 보고서 — 무엇이 들어가야 하나

가이드라인은 검증 및 유효성확인(V&V) 보고서 예시를 제공한다. 예시에서 읽어 낼 수 있는 구조는 이렇다.

구성내용QA 포인트
개요·대상제품·소프트웨어 버전, 주요 변경과 주요 변경이 아닌 변경의 정의시험 대상 버전과 제출 버전 일치
추적표요구사항(SRS) → 설계(SDS) → 단위·통합·시스템 시험 ID, 위험(SRM) 연결레슨 1 추적표, 레슨 2 위험 ID
시험 결과시험별 결과와 수행자반복 가능성 (레슨 1)
분석적 성능 시험평가 지표(AUROC·민감도·특이도 등)와 정의, 시험 환경, 데이터, 결과모듈 36 레슨 3 분류 성능 평가
시험 환경하드웨어 사양, 소프트웨어 환경(GPU 드라이버·런타임·라이브러리 버전), 전처리 조건모듈 31 레슨 2 환경 기재
학습·시험 데이터 정의 (AI 제품)수집 데이터 중 학습·검증·테스트로 쓰는 항목, 분할데이터 누수·분포

AI 기반 소프트웨어에서 가장 자주 보완 요구를 받는 곳이 시험 환경과 데이터 정의 다. 분석적 성능 시험 결과가 "AUROC 0.93"이라도, 어느 버전의 모델을 어떤 런타임과 라이브러리 버전에서 어떤 데이터로 쟀는지 없으면 재현할 수 없다. 모델 학습에 쓴 데이터와 시험 데이터가 같은 기관·같은 기간에서 나와 분리가 불충분하면 성능이 부풀려진다.

[분석적 성능 시험 기록 — 요약 형식]
대상:          ○○ 예측 소프트웨어 v1.03.12 (모델 가중치 해시 기록)
평가 지표:      AUROC (95% 신뢰구간), 민감도·특이도 (임계값 고정: 설계 문서 SDS-035)
시험 데이터:    기관 3곳, 수집 기간 2023~2024, 학습 데이터 기관과 **다른** 기관 1곳 포함
              환자 단위 분할 확인(같은 환자의 영상이 학습·시험에 동시에 없음)
시험 환경:      GPU 모델·메모리, 드라이버·CUDA 버전, 추론 런타임, 전처리 라이브러리 버전
              → 운영환경(적합성 확인보고서)과 일치 여부
결과:          AUROC 0.91 (0.88~0.94), 민감도 0.87, 특이도 0.84
하위군:        연령대·성별·장비 제조사별 결과 (모듈 36 레슨 4 편향)
수행자·일시:    시험자 2인, 날짜

"환자 단위 분할"과 "하위군 결과"는 규정 양식에 칸이 없더라도 심사관이 질의하는 단골 항목이다. 인공지능기술이 적용된 디지털의료기기의 임상시험방법 설계 가이드라인(2025)도 함께 확인한다. 성능 평가 지표 표현(예: ROC 곡선 대신 AUC 수치로 표준화) 같은 세부가 그 안내서에서 정리되었다.

임상시험 자료가 필요한가 — 분석적 성능으로 갈음되는 경우

디지털의료기기는 원칙적으로 임상시험 등 평가에 관한 자료가 필요하지만, 가이드라인은 제출 면제·대체가 가능한 경우를 안내한다. 예를 들어 임상적 유효성을 표방하지 않는 기능이나, 식약처장이 인정하는 임상표준데이터 등을 활용한 분석적 성능 검증 으로 갈음할 수 있는 경우가 있다. 이때 V&V 자료의 분석적 성능 시험이 임상적 사용 환경을 고려했는가 가 판단 근거가 된다.

QA에게 이것은 분석적 성능 시험의 설계 품질이 임상시험 수행 여부 — 즉 몇 달~몇 년의 일정과 큰 비용 — 를 좌우할 수 있다는 뜻이다. 실제 사용 환경의 영상 장비·입력 품질· 환자 분포를 시험 데이터가 반영하는지를 초기부터 설계한다.

변경허가 — 어떤 소프트웨어 변경이 심사를 부르는가

출시 후 소프트웨어는 계속 바뀐다. 모든 변경이 변경허가 대상은 아니다. 가이드라인은 허가 항목의 기재사항이 변경되는지 로 판단하도록 안내한다.

변경 유형변경허가가 필요한 경우 (가이드라인 예시 요지)해당하지 않는 경우
사용목적·핵심 성능기능이 추가·변경되어 '모양 및 구조'·'부분품 또는 구성요소'·'성능(기능) 또는 특성'·'사용목적'·'시험규격' 기재사항이 바뀜 (예: 폐결절 검출에 폐암 예측·진단 성능 추가)단순 오기 수정, 핵심 성능이 아닌 기재사항
알고리즘(분석 방법)분석 대상·기법이 바뀌어 작용원리·성능·시험규격이 바뀜 (예: 규칙 기반 → 딥러닝, CT → CT+MRI 입력 추가)분석 기법과 무관한 '사용방법' 기재 변경
개발언어·운영환경'부분품 또는 구성요소' 기재사항이 바뀜 (예: 운영환경 Windows → Android)같은 운영체계 안의 버전 변경 (예: Windows 7 → 10)
통신통신 기술·목적 추가로 '정보통신체계도' 기재사항이 바뀜 (예: Android → Android·iOS, 제어 → 제어·유지보수·업데이트)단순 오기
사용적합성에 영향을 주는 UI변경허가(인증) — 독립형 소프트웨어 사용적합성 가이드라인 참조 (레슨 3)—

QA가 할 일은 모든 변경에 대해 이 판단을 기록으로 남기는 것 이다. 모듈 38 레슨 5의 게이트에 "인허가 영향 검토" 경고 규칙을 넣고, 모듈 39 레슨 9의 인증 영향 판정과 같은 방식으로 운영한다.

[변경의 인허가 영향 판단 기록 — v1.04.0]
변경 내용:        전처리 라이브러리 버전 업그레이드, 결과 화면 색상 변경, 모델 재학습(같은 구조·데이터 12% 추가)
허가 기재사항 영향:
  부분품 또는 구성요소   — 라이브러리 버전은 기재 수준 확인 → 기재 버전 형식(1.03.XX)상 영향 없음
  성능(기능) 또는 특성  — 재학습으로 성능 수치 변동, 기재 성능 하한 충족 여부 확인 필요 → 분석적 성능 재시험 FT-104
  작용원리·시험규격     — 구조·분석 대상 동일, 영향 없음
  사용적합성            — 색상 변경이 경고 표시 구분에 영향 → 레슨 3 변경 영향 분석 UE-CI-07
판단:            변경허가 대상 아님 (근거: 가이드라인 판본, 재시험 결과)
                단, 재학습 성능이 기재 하한 미달 시 변경허가 검토로 전환
확인:            RA 담당, QA 리드

모델 재학습 이 인공지능 제품에서 가장 어려운 판단이다. 구조와 분석 대상이 같아도 성능이 달라지면 기재 성능과의 관계를 확인해야 하고, 학습 데이터가 크게 바뀌면 작용원리 변경으로 볼 여지도 생긴다. 재학습 절차와 판단 기준을 사전에 문서화 해 두는 것이 안전하다.

우수 관리체계 인증과 전자적 침해행위 보안지침

디지털의료제품법은 두 가지 제도를 새로 두었다.

우수 관리체계 인증 — 식약처는 품질관리체계, 안전관리, 전자적 침해행위 보호 조치 등을 평가해 디지털의료기기 제조업자 등에 우수 관리체계 인증을 할 수 있다. 인증을 받으면 제조·수입 허가·인증·신고에 필요한 자료의 일부를 면제하거나 제출 시기·방법을 달리 할 수 있다. 인증 유효기간은 3년이다. QA 관점에서 이 인증은 레슨 1~5의 체계를 조직 수준에서 평가받는 것 이고, 평소 산출물 체계가 갖춰져 있으면 제품마다 반복되는 제출 부담을 줄이는 길이다.

전자적 침해행위 보안지침 — 해킹·데이터 유출·서비스 거부 공격 같은 전자적 침해행위로부터 디지털의료기기를 보호하는 조치와, 침해 발생 시 신고·조치, 취약점 감시 등을 정한 고시다. 업무 안내서는 침해행위 발생을 인지한 경우의 의무 보고사항 과 취약점을 확인한 경우의 권고사항 을 구분해 안내한다. 레슨 5의 출시 후 취약점 대응 계획이 국내에서는 이 지침과 연결된다. 사이버보안 허가·심사 가이드라인(레슨 5)의 요구사항별 적용·검증 근거 표와 함께, 침해 신고·조치 절차가 실제로 동작하는지 (연락 경로·판단 기준· 기록)를 모의 훈련으로 시험해 두면 좋다.

국내·해외 제출을 같은 증거에서 만든다

국내 인허가와 미국·유럽 제출을 동시에 준비하는 회사는 증거를 따로 만들면 안 된다. 모듈 39 레슨 9의 증거 대응표 방식을 쓴다.

증거                         식약처 적합성 확인보고서 항목   FDA 제출            EU MDR 기술문서
SRS·추적표                    요구사항 분석                Software Requirements  —
위험 추적표 (구현·효과 검증)     위험관리                     Risk Management File   ISO 14971 파일
잔존 이상 평가                 배포                        Unresolved Anomalies   —
분석적 성능 시험               V&V 보고서                   Performance Testing    성능 평가
사용적합성 총괄 평가            사용적합성 자료               Human Factors Report   IEC 62366-1 파일
SBOM·보안 시험                 사이버보안 자료              Cybersecurity (524B)   EN IEC 81001-5-1

용어와 서식은 다르지만 증거는 같다. 이것이 레슨 1에서 "62304는 무엇을 하라고 하지, 어떻게 하라고 하지 않는다"로 시작한 이유다. 산출물 체계를 표준에 맞춰 두면 제출처별 서식은 번역의 문제가 된다.

실무에서 왜 필요한가

국내 디지털 헬스 기업, 특히 AI 영상 분석·디지털치료기기 회사가 인허가 일정에서 가장 자주 막히는 곳은 기술이 아니라 제출 자료의 구조와 판단 근거 다. 적합성 확인보고서의 관리번호가 가리키는 문서가 없거나, V&V 보고서의 시험 환경이 운영환경과 다르거나, 모델 재학습 후 변경허가 판단 기록이 없는 경우다. 법 체계가 새로 바뀐 시기에는 회사마다 해석이 엇갈려 보완 요구가 늘어난다.

QA가 이 자료를 RA(인허가) 담당과 함께 만들면, 인허가 문서가 실제 개발·시험 기록과 일치 하게 된다. 의료기기 QA 채용 공고에서 "인허가 대응 경험", "V&V 문서 작성", "IEC 62304 기반 문서화"가 반복되는 이유다. 면접에서는 "모델 재학습 후 변경허가 대상인지 어떻게 판단하고 무엇을 재시험했는가"가 실무 경험을 가장 잘 드러내는 질문이다.

실습 과제

과제 1 — 형태와 적용 범위 (10분)

아래 소프트웨어가 디지털의료기기소프트웨어 허가·심사 가이드라인 적용 대상인지, 독립형·내장형 중 무엇인지 판단한다.

1. 흉부 X-ray 에서 폐결절 의심 부위를 표시하는 클라우드 AI 서비스
2. 초음파 장비에 설치되어 영상을 재구성하는 소프트웨어
3. 의료기기 제조 라인의 검사 장비 제어 소프트웨어
4. 불면증 인지행동치료 앱
5. 사용자 화면 없이 인슐린 펌프 모터만 제어하는 펌웨어

과제 2 — 적합성 확인보고서 초안 (30분)

본인이 아는(또는 가상의) 독립형 디지털의료기기소프트웨어에 대해 적합성 확인보고서 항목표를 채운다. 각 항목의 요약 두세 줄과 가리킬 문서 관리번호(가상)를 쓰고, 산출물이 없는 항목을 따로 표시한다.

과제 3 — 분석적 성능 시험 기록 검토 (15분)

아래 기록에서 심사 질의가 예상되는 부분을 모두 찾는다.

대상: 뇌출혈 검출 AI (버전 미기재)
지표: 정확도 96%
데이터: 협력 병원 A 의 2024년 CT 5,000건, 무작위 8:2 분할 (학습:시험)
환경: 사내 GPU 서버
결과: 정확도 96%, 민감도 92%

과제 4 (선택) — 변경허가 판단 (15분)

"뇌출혈 검출 AI에 뇌경색 의심 표시 기능을 베타로 추가하고, 기존 뇌출혈 모델도 데이터 30%를 추가해 재학습"하는 변경에 대해 본문 형식의 인허가 영향 판단 기록을 쓴다.

자가 체크리스트

  • 디지털의료제품법의 시행 시점과 디지털의료기기·디지털융합의약품·디지털의료·건강지원기기의 구분을 안다
  • 독립형·내장형 디지털의료기기소프트웨어와 가이드라인 적용 제외 범위를 구분할 수 있다
  • 소프트웨어 안전성 등급이 디지털의료기기 등급 결정에서 조정 요소로 쓰이는 방식을 설명할 수 있다
  • 안내서 판본·정의 표·상위 규정을 판단 출처로 기록해야 하는 이유를 안다
  • 적합성 확인보고서 항목과 IEC 62304 산출물을 대응시키고 문서 관리번호로 가리킬 수 있다
  • V&V 보고서의 추적표·시험 환경·분석적 성능 시험·학습·시험 데이터 정의를 설계할 수 있다
  • 분석적 성능 시험의 설계가 임상시험 자료 제출 판단에 영향을 줄 수 있음을 안다
  • 변경허가가 필요한 소프트웨어 변경 유형을 판단하고 판단 기록을 남길 수 있다
  • 우수 관리체계 인증과 전자적 침해행위 보안지침이 QA 산출물과 어떻게 연결되는지 말할 수 있다
  • 국내·해외 제출 자료를 같은 증거에서 만드는 대응표를 쓸 수 있다

흔한 실수

식약처 서식을 채우면서 산출물을 새로 만든다. 서식은 기존 산출물을 요약하고 가리키는 것이다.

등급 판단의 출처를 남기지 않는다. 안내서 판본과 정의 표를 근거로 적는다.

분석적 성능 결과만 적고 시험 환경·데이터 분할을 생략한다. 재현할 수 없는 성능은 심사에서 질의로 돌아온다.

환자 단위가 아니라 영상 단위로 무작위 분할한다. 같은 환자가 학습·시험에 섞이면 성능이 부풀려진다.

모델 재학습을 일상적 유지보수로만 처리한다. 기재 성능·작용원리와의 관계를 매번 판단하고 기록한다.

국내용과 해외용 증거를 따로 만든다. 용어는 번역하고 증거는 하나로 유지한다.

참고 자료

낯선 말 풀이

이 레슨에 나온 약어입니다. 본문에서도 처음 나올 때 점선으로 표시해 두었습니다 (제목과 링크 글자는 그대로 둡니다).

QA — 품질보증
만든 것이 쓸 만한지 확인하고, 애초에 덜 망가지게 만드는 방법을 정하는 일. "테스트"는 그 일의 일부다.
IEC — 국제전기기술위원회
전기·전자 분야의 국제 규격을 만드는 단체.
ISO — 국제표준화기구
여러 나라가 모여 "이건 이렇게 하자"를 문서로 정하는 단체. 그 문서 자체를 번호로 부른다.
AI — 인공지능
사람이 규칙을 일일이 적지 않아도 데이터에서 규칙을 찾아 판단하는 소프트웨어.
OS — 운영체제
기기를 돌리는 바탕 프로그램 — 윈도우, 맥, 안드로이드 같은 것.
SOUP — 출처가 불분명한 소프트웨어
우리가 만들지 않아서 어떻게 만들어졌는지 모르는 채 가져다 쓰는 부품 코드.
SBOM — 소프트웨어 구성 명세서
제품에 어떤 부품 코드가 어느 버전으로 들어갔는지 적은 부품 목록.
ID — 식별자
무엇 하나를 다른 것과 구별하기 위해 붙인 이름이나 번호.
GPU — 그래픽처리장치
비슷한 계산을 한꺼번에 많이 하는 데 특화된 부품. 그림과 기계학습에 쓰인다.
ROC — 판정 기준을 바꿔 가며 그린 성능 곡선
"얼마나 깐깐하게 판정할지" 를 바꿔 가며, 맞게 잡은 비율과 잘못 잡은 비율을 그림으로 그린 것.
AUC — 곡선 아래 면적
분류를 얼마나 잘하는지 하나의 숫자로 요약한 값. 1에 가까울수록 좋다.
UI — 사용자 인터페이스
사람이 직접 보고 누르는 부분 — 화면, 버튼, 입력창.

용어집 전체 보기