AI 위협 모델링(Threat Modeling)이란? AI를 만들기 전 위험을 그려보는 방법

TL;DR

AI 위협 모델링은 AI 서비스가 어떻게 작동하는지 먼저 그린 뒤, 누가 어떤 경로로 데이터·지시문·도구를 잘못 쓰게 만들 수 있는지 찾아 대응책을 정하는 과정입니다. 생성형 AI와 AI 에이전트는 자연어 입력, 외부 문서, 연결 도구, 사용자 권한이 함께 움직이므로 모델 답변만 따로 점검해서는 부족합니다.

초보자는 이를 “AI가 어디서 잘못될 수 있는지, 출시 전에 지도처럼 그려보는 안전 점검”으로 이해하면 됩니다.

핵심 3줄 요약

• 핵심 1
  AI 위협 모델링은 문제 발생 뒤의 사고 분석이 아니라, 설계 단계에서 위험한 경로를 미리 찾는 활동입니다.
• 핵심 2
  AI에서는 입력 프롬프트뿐 아니라 파일·검색 결과·연결 도구·권한·출력 사용처까지 함께 범위에 넣어야 합니다.
• 핵심 3
  결과물은 ‘완전 안전’ 선언이 아니라, 우선 막을 위험과 담당자·검증 방법을 정리한 실행 목록입니다.

이 글에서 다룰 내용

AI 위협 모델링의 한 문장 정의는 무엇인가요?

AI 위협 모델링은 AI 시스템의 데이터 흐름, 권한, 연결 지점, 사용 시나리오를 살펴보고 공격·오용·실수로 생길 수 있는 위험과 대응책을 체계적으로 정리하는 활동입니다.

NIST는 위협 모델링을 데이터, 애플리케이션, 시스템, 환경처럼 논리적 대상의 공격과 방어 측면을 모델링하는 위험 평가의 한 형태로 설명합니다. AI에 적용할 때는 기존 소프트웨어의 로그인·API·네트워크 경로뿐 아니라 모델 입력, 검색 문서, 메모리, 도구 호출, 자동 실행 결과까지 함께 봐야 합니다.

한 줄 정리: AI 위협 모델링은 “우리 AI가 무엇을 믿고, 무엇을 할 수 있으며, 그 경로가 어떻게 악용될 수 있는가?”를 출시 전에 답하는 작업입니다.

생성형 AI에서는 왜 더 중요할까요?

일반 프로그램은 정해진 버튼과 코드 경로를 중심으로 동작합니다. 반면 생성형 AI는 사용자의 자연어를 지시로 해석하고, 문서·웹 검색·데이터베이스·외부 도구와 연결될 수 있습니다. 같은 기능이라도 입력 문장, 참조 문서, 권한 설정에 따라 예상 밖의 결과가 나올 수 있습니다.

Microsoft의 AI 위협 모델링 안내는 AI 시스템이 확률적으로 동작하고 자연어 지시를 처리하기 때문에 데이터와 제어 경로가 흐려질 수 있으며, 개별 구성 요소보다 연결 경계에서 실패가 발생할 수 있다고 설명합니다. 그래서 “모델이 유해한 답을 하는가”만 묻지 말고 다음 질문까지 넓혀야 합니다.

• 누가 이 AI에 질문하거나 파일을 넣을 수 있나요?
• AI는 어떤 문서와 데이터를 검색할 수 있나요?
• AI가 호출할 수 있는 도구는 무엇이고, 각 도구의 권한은 어디까지인가요?
• AI의 답변이나 도구 실행 결과를 사람이 확인하기 전에 어디에 사용하나요?
• 문제가 생겼을 때 중단·기록·복구할 방법이 있나요?

핵심 인사이트: AI의 위험은 모델 안에만 있지 않습니다. 모델이 읽는 정보, 연결된 도구, 실행 권한, 사람이 결과를 믿고 사용하는 방식이 함께 위험 표면을 만듭니다.

쉬운 예시로 AI 위협 모델링을 이해해 볼까요?

사내 고객 상담 AI가 있다고 가정해 보겠습니다. 이 AI는 고객의 질문을 받고, 주문 조회 도구와 정책 문서를 검색한 뒤 답변을 만듭니다. 일부 요청은 상담원에게 넘기고, 일부는 자동으로 답합니다.

먼저 시스템을 간단히 그립니다.

1. 고객이 채팅창에 질문을 입력합니다.
2. AI가 정책 문서와 주문 정보를 조회합니다.
3. AI가 답변을 만들거나 상담원에게 전달합니다.
4. 상담원 또는 고객이 답변을 바탕으로 환불·주소 변경 같은 후속 행동을 합니다.

그다음 각 지점에서 “무엇이 잘못될 수 있는가?”를 묻습니다.

• 고객이 문서 안에 숨긴 지시문으로 AI의 규칙을 바꾸려 하면 어떻게 되나요?
• 주문 조회 도구가 본인 주문만 보도록 제한되어 있나요?
• 환불 실행처럼 되돌리기 어려운 행동은 AI가 단독으로 할 수 있나요?
• 오래된 정책 문서를 검색해 잘못된 안내를 만들면 누가 발견하나요?
• 상담원에게 전달된 내용에 고객의 불필요한 개인정보가 포함되지는 않나요?

마지막으로 위험마다 대응을 붙입니다. 예를 들어 외부 문서는 신뢰할 수 없는 입력으로 분리하고, 주문 조회는 사용자 본인 확인이 끝난 경우에만 허용하며, 환불 실행은 사람 승인 단계를 둡니다. 정책 문서는 버전과 갱신일을 관리하고, 중요한 도구 호출은 로그로 남깁니다.

예시: “AI가 환불을 잘 설명한다”는 품질 테스트의 질문입니다. “다른 사람의 주문을 조회하거나 사람 승인 없이 환불을 실행할 수 있는가”는 위협 모델링의 질문입니다.

AI 위협 모델링은 어떤 순서로 하나요?

복잡한 보안 전문 용어부터 시작할 필요는 없습니다. 작은 AI 기능이라도 아래 순서로 정리하면 실무 대화가 쉬워집니다.

1. AI가 하는 일과 하지 말아야 할 일을 적습니다

AI의 목적을 한 문장으로 쓰고, 절대 해서는 안 되는 행동도 함께 적습니다. 예를 들어 “배송 상태를 안내한다”는 목적과 “본인 확인 없이 주문 정보를 공개하거나 환불을 확정하지 않는다”는 제한을 같이 둡니다.

2. 입력·데이터·도구·출력을 한 장에 연결합니다

사용자 입력, 업로드 파일, 검색 문서, 데이터베이스, 모델, API 도구, 답변 화면, 자동 실행 지점을 화살표로 연결합니다. 이 그림은 정확한 기술 다이어그램일 필요가 없습니다. 정보와 권한이 어디로 이동하는지 보이면 충분합니다.

3. 신뢰 경계를 표시합니다

외부 고객 입력, 공개 웹 문서, 내부 정책 문서, 직원 전용 데이터, 결제·환불 같은 실행 도구는 같은 수준으로 믿을 수 없습니다. 신뢰도가 달라지는 경계마다 검증과 권한 확인이 필요한지 묻습니다.

4. 위험 시나리오를 우선순위로 정합니다

모든 가능성을 똑같이 다루지 않습니다. 고객 데이터 노출, 금전 거래, 계정 변경, 유해한 안내처럼 영향이 큰 사례부터 정리합니다. 각 사례에는 발생 조건, 예상 피해, 현재 방어책, 남은 조치를 기록합니다.

5. 대응책과 검증 방법을 붙입니다

대응은 ‘주의한다’로 끝나면 안 됩니다. 권한 분리, 사람 승인, 입력 검증, 검색 문서 검토, 로그, 알림, 제한된 테스트 계정처럼 실행 가능한 조치를 정합니다. 변경 뒤에는 실제로 제한이 작동하는지 테스트합니다.

실전 팁: 회의가 길어지면 먼저 ‘고객 정보 노출’, ‘권한 없는 실행’, ‘신뢰할 수 없는 문서의 지시문’, ‘잘못된 답변의 자동 사용’ 네 가지부터 점검해 보세요. 작은 서비스도 가장 큰 위험부터 줄일 수 있습니다.

위협 모델링, 레드팀, 보안 테스트, AI 영향평가는 어떻게 다른가요?

네 용어는 모두 AI 위험을 줄이는 데 쓰이지만, 시작점과 결과물이 다릅니다.

• AI 위협 모델링: 설계와 흐름을 보고 가능한 위험 경로와 대응책을 정리합니다. “무엇이 잘못될 수 있는가?”가 중심입니다.
• AI 레드팀: 공격자나 까다로운 사용자 관점에서 실제로 실패를 유도해 봅니다. 위협 모델에서 정한 위험 시나리오를 시험하는 데 활용할 수 있습니다.
• 보안 테스트: 인증, 권한, 취약점, 설정, API 같은 기술 통제를 검사합니다. AI 위협 모델링은 이 범위를 모델 입력·데이터·도구·출력 흐름까지 확장합니다.
• AI 영향평가: AI 도입이 사람, 업무, 공정성, 개인정보, 운영에 미칠 영향을 폭넓게 검토합니다. 위협 모델링은 그중 공격·오용·실수로 이어지는 경로를 더 구체적으로 다룹니다.

Microsoft의 AI/ML 위협 모델링 문서는 기존 보안 개발 수명 주기의 위협 모델링을 보완하며, AI·ML 특유의 위협과 완화 방법을 논의하도록 돕는다고 설명합니다. NIST의 적대적 머신러닝 보고서는 생성형 AI에서도 회피, 데이터 오염, 개인정보, 오용 관련 공격과 완화책을 공통 언어로 정리합니다.

비교 정리: 위협 모델링은 위험 지도를 만들고, 레드팀은 그 지도 속 위험을 시험하며, 보안 테스트는 기술적 방어가 작동하는지 확인하고, 영향평가는 도입 전체의 영향을 살핍니다.

AI 도구를 쓸 때 이 용어는 언제 도움이 되나요?

AI 위협 모델링은 대형 서비스를 만드는 팀만의 일은 아닙니다. 챗GPT, 제미나이, 클로드 같은 도구를 업무에 연결하거나 AI 에이전트로 반복 작업을 자동화할 때도 좋은 질문 목록이 됩니다.

• 사내 문서 검색 AI: 어떤 문서를 검색 대상에 넣을지, 퇴사자·외부 협력사 문서가 섞이지 않는지 확인할 때
• 고객 응대 AI: 답변만 하는지, 주문 조회·쿠폰 발급·환불 요청 같은 도구까지 실행하는지 구분할 때
• 마케팅 자동화: AI가 만든 문구나 고객 분류 결과가 승인 없이 발송·광고 집행으로 이어지지 않게 할 때
• 개발용 AI 에이전트: 읽기 권한과 배포·삭제 권한을 분리하고, 민감한 비밀값이 로그나 프롬프트에 들어가지 않게 할 때

중요한 점은 AI에게 모든 위험을 물어 해결책을 맡기는 것이 아닙니다. 실제 데이터·권한·업무 책임을 아는 사람이 범위와 승인 기준을 정해야 합니다.

AI 위협 모델링에서 주의할 점은 무엇인가요?

주의: 위협 모델링을 한 번 했다고 안전이 보장되지는 않습니다. 모델, 프롬프트, 검색 문서, 연결 도구, 권한, 업무 절차 중 하나만 바뀌어도 위험 지도를 다시 확인해야 합니다.

첫째, 모델만 보고 시스템 전체를 놓치지 않아야 합니다. AI 앱의 위험은 자주 검색 연결, 파일 업로드, 권한 설정, 자동 실행 도구 같은 통합 지점에서 커집니다.

둘째, 실서비스나 타인의 시스템을 허가 없이 시험하면 안 됩니다. 테스트 대상, 계정, 데이터, 허용 행동, 중단 기준을 정한 승인된 환경에서 진행해야 합니다.

셋째, ‘위험 없음’이라는 결론보다 근거와 남은 위험을 기록하는 편이 낫습니다. 어떤 데이터 흐름을 확인했고, 무엇을 아직 테스트하지 못했는지 남겨야 다음 변경 때 다시 검토할 수 있습니다.

넷째, 보안팀만의 문서로 만들지 않는 것이 좋습니다. 제품 담당자, 개발자, 운영자, 개인정보 담당자가 함께 보면 실제 사용 흐름과 책임 경계를 더 정확히 찾을 수 있습니다.

자주 묻는 질문

Q1. AI 위협 모델링은 개발자만 해야 하나요?

아닙니다. 기술 구현은 개발자가 자세히 볼 수 있지만, 어떤 데이터가 민감한지, 어떤 행동에 사람 승인이 필요한지, 잘못된 답변이 어떤 업무 피해로 이어지는지는 기획·운영·보안 담당자가 함께 알아야 합니다.

Q2. 프롬프트 인젝션 점검만 하면 충분한가요?

충분하지 않습니다. 프롬프트 인젝션은 AI가 신뢰하지 말아야 할 지시문을 따르게 만드는 한 가지 위험입니다. 위협 모델링은 그 밖에도 과도한 도구 권한, 개인정보 노출, 잘못된 검색 문서, 자동 실행, 로그 관리 같은 경로를 함께 봅니다.

Q3. AI 위협 모델링을 하면 레드팀은 하지 않아도 되나요?

아닙니다. 위협 모델링은 우선 점검할 위험을 정하는 데 도움이 되고, 레드팀은 실제 실패 가능성을 시험하는 데 도움이 됩니다. 서비스의 영향도와 기능 범위에 맞춰 두 활동을 연결하는 편이 좋습니다.

Q4. 챗GPT 같은 외부 AI 도구를 단순히 쓰는 팀에도 필요한가요?

네. 자체 모델을 만들지 않아도 사내 문서 업로드, 외부 서비스 연결, 자동화 권한 부여가 있다면 데이터가 어디로 가고 어떤 행동까지 가능한지 점검할 가치가 있습니다. 다만 서비스 제공자의 모델 자체 보안이 아니라, 우리 조직의 사용 설정과 업무 흐름에 초점을 맞춰야 합니다.

Q5. 가장 먼저 기록할 항목은 무엇인가요?

AI의 목적, 입력 출처, 접근 데이터, 연결 도구와 권한, 자동 실행 여부, 사람 승인 지점, 로그와 중단 방법입니다. 이 일곱 가지가 보이면 우선 위험 시나리오를 논의할 기반이 생깁니다.

출처

마무리

AI 위협 모델링은 AI를 쓰지 말자는 절차가 아닙니다. AI가 읽는 정보, 할 수 있는 행동, 사람이 결과를 믿고 사용하는 지점을 먼저 확인해 더 안전하게 쓰기 위한 설계 습관입니다.

감자나라ai님처럼 AI 도구와 자동화를 업무에 붙일 때는 새 기능을 켜기 전에 “이 AI는 무엇을 읽고, 무엇을 실행하며, 누가 최종 확인하는가?” 세 질문부터 적어 보세요. 그 짧은 점검이 데이터 노출과 권한 오작동을 줄이는 출발점이 됩니다.