의료기관 RAG 보안 구축 전 먼저 점검한 7가지
의료기관 RAG 보안은 개인정보 법령 체크리스트만으로는 채워지지 않는 별도의 기술 영역입니다. 검색 권한 분리, 프롬프트 인젝션 방어, 벡터DB 보호, 외부 API 데이터 흐름, 출력 검증, 접속기록, 벤더 평가까지 구축 전에 점검해야 할 일곱 가지를 정리했습니다.
의료기관 RAG 보안이란 검색 증강 생성 시스템이 환자 정보와 임상 지식을 다루는 전 과정에서 접근 권한, 입력·출력 데이터, 외부 연동 지점을 체계적으로 통제하는 일을 의미합니다. 저는 여러 병원의 AI 도입 논의를 지켜보며, 개인정보보호법 체크리스트를 다 채운 곳에서도 정작 RAG 구조 자체의 허점은 그대로 남아 있는 경우를 자주 봤습니다.
의료기관 RAG 보안, 왜 지금 따로 점검해야 할까?
RAG 특유의 공격 표면이란?
2026년 8월 현재 시행 중인 AI 기본법은 보건의료 제공·이용체계에 활용되는 인공지능시스템을 고영향 인공지능으로 분류할 가능성이 높다고 밝히고 있습니다. 위험관리방안 수립과 안전성 확보 조치가 권고를 넘어 의무 수준으로 올라온 셈입니다. 그런데 실무에서는 개인정보보호법상 안전조치 의무를 채우는 데만 집중하고, RAG라는 아키텍처 자체가 만드는 새로운 공격 표면은 놓치는 경우가 많습니다. OWASP가 발표한 LLM 애플리케이션 보안 위험 목록은 검색증강생성을 안전장치가 아니라 새로운 공격 표면으로 규정하며, 벡터·임베딩 취약점을 별도 항목으로 다룹니다. 의료기관처럼 민감한 데이터를 다루는 환경일수록 이 구분이 중요하다고 생각합니다.
| 순번 | 점검 항목 | 핵심 위험 | 우선 확인 사항 |
|---|---|---|---|
| 1 | 검색 계층 접근 권한 | 부서 간 정보 교차 노출 | 문서 권한과 벡터DB 권한 일치 여부 |
| 2 | 프롬프트 인젝션 방어 | 검색 문서에 숨은 악성 지시 실행 | 색인 전 콘텐츠 정화 절차 |
| 3 | 벡터DB·임베딩 보호 | 임베딩 역산으로 원문 복원 | 벡터 저장소 별도 접근 통제 |
| 4 | 외부 API 데이터 흐름 | 환자 정보의 기관 외부 전송 | 위탁 계약과 데이터 최소화 |
| 5 | 출력 검증 | 서로 다른 환자 정보 혼입 | 근거 인용·출처 표시 강제 |
| 6 | 접속기록·질의 로그 | 무단 열람 사후 추적 불가 | 질의 로그 별도 보관 여부 |
| 7 | 외부 벤더 보안 평가 | 재위탁 관리 공백 | 계약서상 보안 조항 명시 |
검색 계층 접근 권한은 부서별로 분리되어 있는가?
벡터DB는 “권한 없는 검색”을 막지 못한다
의료기관 RAG 보안 설계에서 가장 먼저 걸리는 지점은 검색 계층입니다. RAG는 질문이 들어오면 벡터DB에서 의미상 유사한 문서 조각을 찾아 언어모델에 넘기는데, 이 검색 단계에 별도의 접근 통제가 없으면 원무팀 직원의 질문에도 정신건강의학과 진료 기록 조각이 함께 검색되어 넘어갈 수 있습니다. 원본 문서에 접근권한이 걸려 있어도, 벡터DB로 재색인되는 순간 그 권한 정보가 함께 이관되지 않으면 소용없다는 점이 실무에서 자주 간과됩니다.
어떤 직군이 어떤 문서 컬렉션을 검색할 수 있는지 표로 정리하고, 벡터DB 색인 시점에 원본 권한 태그를 함께 이관하는 절차를 마련합니다.
프롬프트 인젝션 방어 체계는 마련되어 있는가?
사용자가 아니라 문서가 공격자가 될 수 있다
프롬프트 인젝션은 OWASP가 2년 연속 1순위 위험으로 꼽은 항목입니다. RAG 환경에서는 사용자가 직접 악성 질문을 입력하지 않아도, 색인된 문서 안에 숨겨진 지시문이 검색되어 언어모델에 전달되는 간접 인젝션이 더 위협적입니다. 외부에서 업로드된 자료나 협력기관 공유 문서에 특정 안내를 유도하는 문구가 숨어 있으면, 사용자는 평범한 질문만 했을 뿐인데 조작된 답이 나올 수 있습니다.
검색증강생성은 환각을 줄이는 데는 도움이 되지만, 그 자체로 프롬프트 인젝션을 막는 보안 장치는 아닙니다. 근거 인용 기능과 입력 정화 절차는 별도로 설계해야 합니다.
색인 전 문서에서 마크다운·HTML 태그와 숨겨진 지시문을 걸러내는 정화 절차가 있는지, 시스템 프롬프트와 검색된 외부 콘텐츠가 모델 입력에서 명확히 구분되는지 확인이 필요합니다.
벡터DB와 임베딩 데이터는 별도로 보호되고 있는가?
임베딩도 원문처럼 보호해야 하는 이유
임베딩은 문서를 숫자로 바꾼 결과일 뿐이라 원문보다 안전하다고 여겨지기 쉽지만, 실제로는 벡터에서 원본 텍스트의 상당 부분을 역으로 복원하는 임베딩 역산 공격이 보고되어 있습니다. 벡터 저장소를 원본 문서 시스템과 같은 수준의 보호 대상으로 취급하지 않으면 접근권한이나 암호화 정책에서 사각지대가 생깁니다.
외부 LLM API로 나가는 데이터는 통제되고 있는가?
무엇이, 어디까지 나가는지 확인한다
자체 서버가 아닌 외부 LLM·임베딩 API를 쓰는 구조라면, 검색된 문서 조각과 사용자 질문이 그대로 기관 밖 서버로 전송됩니다. 개인정보 보호법은 위탁 계약 시 처리 목적 제한, 재위탁 통제, 수탁자에 대한 관리·감독을 명시하도록 요구하는데, AI API 계약에서는 이 조항이 표준 약관에 묻혀 누락되는 경우를 실무에서 종종 확인했습니다.
API로 전송되는 필드에서 식별정보를 사전에 제거했는지, 로그 보관·재사용 여부를 계약서에 명시했는지, 처리 지역과 재위탁 범위를 확인했는지를 봐야 합니다.
답변에 서로 다른 환자 정보가 섞여 나갈 위험은 없는가?
검색은 맞아도 생성이 틀릴 수 있다
접근 권한이 정확히 걸려 있어도, 언어모델이 여러 검색 결과를 요약하는 과정에서 서로 다른 환자나 사례의 정보를 하나의 답처럼 섞어 버리는 위험은 별개로 존재합니다. 저는 실제로 근거 문장을 인용하지 않고 요약만 하도록 설계된 프로토타입에서, 유사한 두 사례가 하나의 진행 상황처럼 뭉뚱그려지는 결과를 검토한 적이 있습니다.
가상의 병원 도입 사례인 iDOC AI 구축 과정에서는, 답변마다 근거 문서 조각을 함께 표시하도록 설계를 바꾼 뒤에야 검토자가 두 환자 사례가 섞인 답변을 빠르게 걸러낼 수 있었습니다. 근거 표시가 없었다면 매끄러운 문장 뒤에 숨은 오류를 알아채기 어려웠을 것입니다.
답변에 근거 조각의 출처를 함께 표시하도록 강제하는지, 근거 없이 생성된 문장을 자동으로 걸러내는 절차가 있는지 확인해야 합니다.
접속기록과 질의 로그는 충분히 남고 있는가?
제도도 이미 이 방향으로 움직이고 있다
의료법은 전자의무기록에 추가기재·수정이 있을 때 접속기록을 별도로 보관하도록 정하고 있는데, 국회는 2026년 5월 단순 열람 행위까지 접속기록 보관 의무를 확대하는 의료법 개정안을 통과시켰습니다. RAG 시스템의 질의 로그도 같은 맥락에서 다뤄야 한다고 판단합니다. 누가, 언제, 어떤 질문으로 어떤 문서 조각을 검색했는지가 남지 않으면 사고 발생 시 원인 추적 자체가 불가능합니다.
결국 중요한 것은 개인정보 법령 준수와 RAG 아키텍처 보안을 별개의 과제로 보고 둘 다 챙기는 일입니다.
질의 로그를 EMR 접속기록과 동일한 수준으로 별도 보관하는지, 평소와 다른 대량 검색이나 반복 조회를 자동으로 탐지하는 절차가 있는지 점검이 필요합니다.
외부 벤더의 보안 수준은 검증되었는가?
계약서가 보안 수준을 증명하지 않는다
RAG 구축을 외주로 진행하는 경우, 벤더가 실제로 어떤 보안 인증을 갖췄고 하위 인프라를 어디에 재위탁하는지까지 확인하는 병원은 많지 않습니다. 한국인터넷진흥원의 AI 보안 안내서는 AI 공급망 보안과 에이전트·모델·API 권한 관리를 국가 차원의 대응 과제로 다루고 있으며, 저는 이 지점이 병원 규모와 무관하게 계약 단계에서 가장 자주 빠지는 항목이라고 봅니다.
재위탁 범위, 보안 인증 여부, 사고 발생 시 통지 기한을 계약서에 구체적으로 담고, 정기 점검 조항을 별도로 두는 편을 권장합니다.
| 도입 단계 | 핵심 점검 항목 | 주요 담당 |
|---|---|---|
| 기획·설계 단계 | 부서별 접근권한 매트릭스, 데이터 분류 기준 | IT·정보보호팀 |
| 벤더 계약 단계 | 재위탁 조항, 보안 인증, 데이터 처리 목적 제한 | 법무·구매팀 |
| 구축·색인 단계 | 콘텐츠 정화 절차, 임베딩 저장소 접근 통제 | 개발·보안팀 |
| 운영·모니터링 단계 | 질의 로그 검토, 출력 이상 탐지 | 운영·정보보호팀 |
| 정기 재점검 단계 | 접근권한 재검토, 벤더 보안 재평가 | 정보보호팀 |
자주 묻는 질문
의료기관 RAG 보안은 개인정보보호법 체크리스트와 어떻게 다른가요?
개인정보보호법 체크리스트는 법적 의무 이행에 초점을 두지만, RAG 보안은 검색·생성 구조 자체가 만드는 공격 표면을 다룹니다. 두 가지는 상호보완적입니다.
프롬프트 인젝션은 왜 RAG 시스템에서 특히 문제가 되나요?
사용자가 아니라 색인된 문서 안에 숨은 지시문이 공격 경로가 될 수 있어, 평범한 질문에도 조작된 답변이 나올 위험이 있습니다.
벡터DB에 저장된 데이터도 유출 위험이 있나요?
네, 임베딩 벡터에서 원문 일부를 역으로 복원하는 공격이 보고돼 있어 벡터 저장소도 원본과 동일한 수준으로 보호해야 합니다.
외부 LLM API를 쓰면 환자 정보가 무조건 외부로 나가나요?
반드시 그런 것은 아니지만, 위탁 계약과 데이터 최소화 설정을 확인하지 않으면 의도치 않게 넘어갈 수 있습니다.
소규모 의원도 이 정도까지 준비해야 하나요?
규모와 무관하게 핵심은 검색 권한 분리와 로그 보관이며, 조직 크기에 맞춰 최소 항목만이라도 갖추길 권장합니다.
접속기록은 얼마나 오래 보관해야 하나요?
구체적 기간은 관련 법령과 기관 내부 규정에 따라 달라질 수 있어 국가법령정보센터 등 공식 채널 확인이 정확합니다.
도입 전 점검은 누가 주도해야 하나요?
IT·정보보호 담당자만의 몫이 아니라 임상·법무·운영 부서가 함께 참여해야 실효성이 높다고 생각합니다.
정리하며
의료기관 RAG 보안은 한 번의 점검으로 끝나지 않습니다. 검색 권한, 인젝션 방어, 벡터 저장소, 외부 API, 출력 검증, 접속기록, 벤더 평가라는 일곱 축을 설계 단계부터 함께 고려해야 운영 이후 사고를 줄일 수 있습니다. 지금 단계에서 이 일곱 가지 질문에 명확히 답할 수 있는지부터 확인해보시길 권장합니다.
참고 출처
- OWASP, 「OWASP Top 10 for LLM Applications & Generative AI 2025」, 2025.
- 한국인터넷진흥원(KISA), 「인공지능(AI) 보안 안내서」, 2025.12.
- 개인정보보호위원회, 「생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서」, 2025.08.
- 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」, 시행 2026.01.22.
- 의료법 제23조(전자의무기록) 및 2026년 개정안(접속기록 보관 의무 확대).
- 개인정보 보호법 제26조·제29조 및 시행령 제30조.
- 한국인터넷진흥원, 「2025년 사이버 위협 동향 및 2026년 전망」.
진료실에서 필요한 지식을
근거 기반 iDOC-AI 가 보조합니다.
iDOC AI는 검증된 의료 데이터를 근거로 콘텐츠 정확도를 보강하는 의료 지식 RAG 서비스입니다.
