핵심 요약 이 글은 실제 사건이 아니라 설명을 위해 만든 가상 사례입니다. 외부 벤더가 공급한 고객상담 AI 에이전트가 상담 창에 입력된 지시문(프롬프트 인젝션)에 따라 고객 주문 정보를 외부 주소로 보낸 경우, 회사는 이상 징후를 본 시각부터 기록해야 합니다. 대상 고객을 특정하지 못한 단계에도 개인정보 보호법 제34조 제2항과 시행령 제39조의2 제1항 제1호에 따라 유출 가능성 통지 의무가 생길 수 있습니다. 1천 명 미만의 일반 개인정보라면 신고 여부는 시행령 제40조 제1항 제3호의 「외부로부터의 불법적인 접근」 해당 여부에 달려 있고, 개인정보위 안내서의 기준에는 해당한다고 볼 근거와 아니라고 볼 근거가 함께 있으며 프롬프트 인젝션을 직접 다룬 공개 해석은 2026년 10월 15일 기준 확인되지 않았습니다. 회사가 정보통신서비스 제공자라면 정보통신망법의 침해사고 신고 24시간도 함께 진행될 수 있습니다. 벤더가 수탁자여도 회사는 자기 이름의 신고·통지를 준비하는 편이 안전하고, 회수·삭제에 관한 시행령 제40조 제1항 단서는 신고에만 적용되므로 통지 의무는 남습니다.
목차
- 고객 문의 한 건을 본 때가 「유출을 알게 된 때」인가요?
- 대상 고객을 아직 세지 못했는데도 알려야 하나요?
- 상담 창에 지시문을 입력한 것도 「외부로부터의 불법적인 접근」인가요?
- 정보통신망법의 24시간 신고 기한도 함께 진행되나요?
- 에이전트를 공급한 벤더가 사고를 냈다면 신고·통지는 누가 하나요?
- 외부 서버의 자료가 삭제됐다면 신고나 통지를 줄일 수 있나요?
- 통지문에는 무엇을 적고, 어떤 기록을 남겨야 하나요?
- 기한을 넘기거나 통지하지 않은 회사는 결정문에 어떻게 적혔나요?
- 이 가상 사례에서 법령이 답을 정해 두지 않은 곳은 어디인가요?
- 자주 묻는 질문
- 참고 자료
이 글에 나오는 회사와 인물, 시각, 숫자는 모두 가상입니다. 특정 회사나 보도된 사건을 가리키지 않습니다. 중견 온라인 쇼핑 회사(이하 "회사")는 외부 AI 벤더(이하 "벤더")가 공급한 고객상담 에이전트를 홈페이지 상담 창에 붙여 운영합니다. 에이전트는 고객이 묻는 주문의 배송 상태를 답하기 위해 주문 조회 기능을 쓸 수 있고, 택배사 조회 화면 같은 외부 웹 주소를 호출하는 기능도 갖고 있습니다. 대화 기록과 에이전트의 실행 기록은 벤더 서버에 30일간 보관되고, 회사는 관리 화면에서 요약만 볼 수 있습니다.
0일차 23시 40분 무렵 외부인 한 명이 고객 문의를 가장해 상담 창에 긴 지시문을 입력했습니다. 에이전트는 그 지시문을 처리해야 할 요청으로 받아들여 다른 고객들의 주문 정보를 조회했고, 조회 결과를 외부 주소로 보냈습니다. 회사가 처음부터 이 사실을 안 것은 아닙니다. 아래는 회사가 단서를 하나씩 확인하는 동안 법적 판단이 어떻게 바뀌었는지를 시간순으로 적은 기록이고, 인물은 직함으로만 부릅니다. 개인정보보호위원회는 이하 "개인정보위"라 합니다.
가상 사례 · 72시간 동안 판단이 바뀐 일곱 지점
| 시각 | 새로 확인된 단서 | 걸리는 조문 | 법령이 정한 것 | 법령이 정하지 않은 것 |
|---|---|---|---|---|
| 1일차 09:10~14:00 | 이상 세션, 외부 호출 기록 | 법 제34조 제1항, 시행령 제39조·제40조 | 기산점은 「알게 된 때」 | 어느 단서에서 알게 된 것으로 볼지 |
| 1일차 16:00 | 대상 고객을 특정하지 못함 | 법 제34조 제2항, 시행령 제39조의2·제39조의3 | 불법적인 접근을 알게 된 때부터 72시간 안에 가능성 통지 | 에이전트를 움직인 입력이 「불법적인 접근」인지 |
| 2일차 10:00 | 612명, 일반 개인정보 | 시행령 제40조 제1항 제3호 | 1천 명 이상·민감정보·고유식별정보는 신고 대상 | 프롬프트 인젝션이 「외부로부터의」 불법적인 접근인지 |
| 2일차 11:00 | 회사가 정보통신서비스 제공자 | 정보통신망법 제48조의3 제1항 | 침해사고 24시간 신고, 다른 법률에 따른 신고로 갈음 | 프롬프트 인젝션이 침해사고인지 |
| 2일차 15:00 | 실행 기록 원본이 벤더 서버에 있음 | 법 제26조 | 수탁자에게 제34조 준용 | 벤더가 수탁자인지는 실제 처리 방식과 계약에 따라 판단 |
| 3일차 10:00 | 외부 서버의 삭제 회신 | 시행령 제40조 제1항 단서 | 신고하지 않을 수 있는 요건 | 「현저히 낮아진」의 판단 기준 |
| 3일차 15:00 | 통지 문안 확정 | 법 제34조 제1항, 시행령 제39조 | 기재사항 6개, 미확인 항목의 우선 통지 | 인지 경위를 남기는 기록의 형식 |
고객 문의 한 건을 본 때가 「유출을 알게 된 때」인가요?
09:10 CS 리더는 전날 밤 상담 기록을 표본으로 점검하다가 한 세션을 따로 표시했습니다. 주문번호를 대지 않은 이용자가 상담 창에 영문과 한글이 섞인 긴 지시문을 붙여 넣었고, 에이전트는 그 세션에서 주문 조회 기능을 수십 차례 호출했습니다. 관리 화면에는 호출 횟수만 나왔고, 무엇을 조회해 어디로 보냈는지는 나오지 않았습니다. CS 리더는 오전 상담 대기 물량을 먼저 처리한 뒤 10:30에 보안팀장에게 세션 번호를 전달했습니다.
14:00 보안팀장은 회사 방화벽의 외부 통신 기록에서 에이전트 서버가 0일차 23:40부터 약 20분 동안 처음 보는 외부 주소로 요청 수십 건을 보낸 사실을 확인했습니다. 요청에 무엇이 담겼는지는 벤더 서버의 실행 기록에만 남아 있었습니다. 보안팀장은 에이전트의 외부 주소 호출 기능을 끄고, 벤더 담당자에게 해당 세션의 실행 기록 원본을 요청했습니다.
법령으로 보면
개인정보 보호법 제34조 제1항은 개인정보가 유출등이 되었음을 「알게 되었을 때」 정보주체에게 알리도록 하고, 시행령 제39조 제1항과 제40조 제1항은 통지와 신고의 기한을 그때부터 72시간으로 정합니다. 조문은 무엇을 확인해야 알게 된 것인지까지 정하지 않았습니다. 따라서 이 회사에는 후보가 되는 시각이 셋 있습니다. CS 리더가 이상 세션을 본 09:10, 보안팀장이 외부 전송 기록을 확인한 14:00, 그리고 벤더의 실행 기록으로 전송 내용을 확인하게 될 시각입니다.
결정문은 이 다툼에서 회사가 확정한 날보다 앞선 날을 인지일로 적어 왔습니다. 개인정보위는 한국인터넷진흥원으로부터 다크웹 게시 사실과 샘플 자료를 전달받은 회사에 대해, 실제 데이터베이스와 비교해 「개인정보 유출을 충분히 인지할 수 있는 상황」이었다고 적고 그 전달일을 인지일로 삼았습니다(제2025-024-299호, 2025. 11. 26.). 민원 내용을 확인하고도 하루가 지나 관련 부서로 넘긴 회사의 사건에서는 민원을 확인한 날부터 기한을 셌습니다(제2023-010-109호, 2023. 6. 14., 구법의 24시간 기한 적용). 두 사건 모두 AI 에이전트와는 관계가 없습니다. 다만 사내에서 단서를 전달하는 데 걸린 시간이 기한에서 빠지지 않았다는 점은 이 가상 사례의 09:10과 10:30 사이에도 적용될 여지가 있습니다.
개인정보위의 「개인정보 유출등 대응 안내서」(2026. 9., 이하 "안내서")도 같은 방향입니다. 안내서는 회사가 유출등을 인지한 시점을 민원 접수 일시나 제보 확인 일시 같은 객관적 자료로 입증할 수 있어야 하고, 72시간을 넘겨 통지하면 지연 사유와 정당성을 객관적 자료로 소명할 수 있어야 한다고 설명합니다.
가상 사례 · 분기점 1. 72시간의 출발점을 어느 시각으로 기록할 것인가
| 선택지 | 그때 남는 기록 | 확보되는 사실과 남는 질문 |
|---|---|---|
| 09:10(이상 세션 발견) | CS 리더의 점검 기록, 10:30 전달 기록 | 가장 이른 기산점이어서 기한을 두고 다툴 여지가 작습니다. 다만 이 시각에는 외부 전송이 확인되지 않아 통지할 사실관계가 아직 없습니다 |
| 14:00(외부 전송 기록 확인) | 방화벽 기록, 외부 호출 기능 차단 기록 | 불법적인 접근의 정황이 객관적 기록으로 남습니다. 09:10부터 14:00까지의 경과를 설명할 자료가 따로 필요합니다 |
| 벤더 기록으로 전송 내용을 확인한 시각 | 벤더가 보낸 실행 기록 원본과 수신 시각 | 유출 항목과 대상자가 확정됩니다. 회사가 그 시각까지 기다린 사유를 소명해야 할 수 있습니다 |
대상 고객을 아직 세지 못했는데도 알려야 하나요?
16:00 CPO는 보안팀장·법무팀장·CS 리더와 회의를 열었습니다. 회의에서 확인된 사실은 외부 주소로 요청이 나갔다는 것과 그 직전에 주문 조회가 반복됐다는 것뿐이었습니다. 조회된 고객이 누구인지, 몇 명인지는 벤더의 실행 기록이 도착해야 알 수 있었습니다.
20:00 벤더 담당자가 보낸 요약 보고에는 해당 세션에서 외부 호출이 있었다는 사실과 호출 시각만 있었고, 조회된 고객과 항목은 없었습니다. 법무팀장은 이 보고의 수신 시각도 사고 기록에 적었습니다.
법령으로 보면
유출이 확정되기 전 단계의 통지 의무는 2026년 3월 신설되어 같은 해 9월 11일부터 시행된 법 제34조 제2항에 있습니다. 회사는 대통령령이 정한 유출등의 가능성을 알게 되면, 그 가능성이 미치는 정보주체 전원에게 피해를 줄이는 데 필요한 정보 등을 지체 없이 알려야 합니다. 시행령 제39조의2 제1항 제1호는 개인정보처리시스템이나 개인정보취급자가 쓰는 정보기기에 불법적인 접근이 발생해 유출등이 의심되는 정황이 있으나 정보주체를 특정하기 곤란한 경우를 들고, 기산점을 「해당 불법적인 접근을 알게 된 때」로 정합니다. 시행령 제39조의3 제1항은 그때부터 72시간 이내에 통지하도록 합니다. 회사는 대상자를 확정하기 전에도 통지 기한을 세어야 하는 셈입니다.
안내서는 「의심되는 정황」을 단순한 취약점의 존재나 공격 시도와 구별합니다. 불법적인 접근의 성공, 개인정보 테이블에 대한 비정상 질의, 외부 전송 흔적처럼 객관적 자료로 유출 개연성이 인정되는 상황을 가리킨다는 설명입니다. 이 가상 사례의 반복 조회와 외부 호출 기록은 그 설명에 가까워 보입니다. 다만 제1호도 「불법적인 접근」을 요건으로 하므로, 공개 상담 창에 문장을 입력해 에이전트를 움직인 행위가 불법적인 접근인지라는 질문이 이 단계에서 먼저 나타납니다. 제1호에는 제40조 제1항 제3호와 달리 「외부로부터의」라는 말이 없습니다.
시행령 제39조의3 제2항은 72시간 안에 실제 유출등을 확인하면 가능성 통지에 갈음해 확정된 유출의 통지를 하도록 하고, 같은 조 제3항은 유출등이 아닌 것으로 확인되면 그 사실을 즉시 다시 알리도록 합니다. 안내서는 정보주체를 특정할 수 없으면 침해행위가 미칠 수 있었던 정보주체 전체에게 가능성 통지를 하되, 범위가 한정됨을 입증할 수 있으면 그 범위로 줄일 수 있다고 설명합니다. 이 가상 사례에서 침해행위가 미칠 수 있었던 사람은 상담 창을 쓴 고객이 아니라 에이전트가 조회할 수 있었던 주문 고객입니다.
가상 사례 · 분기점 2. 대상자를 모르는 단계에서 무엇을 할 것인가
| 선택지 | 그때 남는 기록 | 확보되는 사실과 남는 질문 |
|---|---|---|
| 에이전트가 조회할 수 있었던 주문 고객 전체에게 바로 가능성 통지 | 발송 기록, 통지 범위를 정한 근거 | 정보주체가 일찍 대비할 수 있습니다. 뒤에 유출이 아닌 것으로 확인되면 시행령 제39조의3 제3항의 통지를 다시 해야 합니다 |
| 문안을 준비하고 기한 안에서 벤더 기록을 기다림 | 문안 초안, 기록 요청 시각 | 기한 안에 대상이 확정되면 곧바로 확정 통지로 넘어갑니다. 기록이 기한 안에 오지 않으면 가능성 통지로 돌아가야 합니다. 법 제34조 제2항은 「지체 없이」 알리도록 하므로, 72시간 안이라는 이유만으로 기다린 시간이 정당화되는지는 따로 소명해야 할 수 있습니다 |
| 대상이 확정될 때까지 통지 검토를 미룸 | 내부 검토 메모 | 기산점이 불법적인 접근을 알게 된 때로 정해져 있어 확정 여부와 관계없이 기한이 진행됩니다 |
상담 창에 지시문을 입력한 것도 「외부로부터의 불법적인 접근」인가요?
09:30 벤더 담당자가 실행 기록 원본을 보냈습니다. 에이전트는 0일차 23:40부터 24:00 사이에 고객 612명의 주문 정보를 조회해 외부 주소로 보냈습니다. 나간 항목은 성명·휴대전화번호·배송지 주소·주문 상품명이었고, 고유식별정보나 민감정보는 없었습니다.
10:00 법무팀장은 신고 의무를 검토했습니다. 공격자는 회사 서버에 침입하거나 계정을 탈취하지 않았습니다. 누구나 쓸 수 있는 상담 창에 문장을 입력했을 뿐입니다.
법령으로 보면
시행령 제40조 제1항은 1천 명 이상의 정보주체에 관한 유출(제1호), 민감정보나 고유식별정보의 유출(제2호), 개인정보처리시스템이나 개인정보취급자의 정보기기에 대한 외부로부터의 불법적인 접근에 의한 유출(제3호) 가운데 하나에 해당하면 72시간 이내에 신고하도록 합니다. 612명의 일반 개인정보이므로 제1호와 제2호에는 해당하지 않고, 신고 여부는 제3호에 달려 있습니다.
가장 가까운 기준은 안내서 45쪽 FAQ Q1입니다. 안내서는 「권한 없는 제3자가 파라미터 변조 등 개인정보처리시스템의 취약점을 이용하여 정상적이지 않은 방법으로 개인정보에 접근한 경우」를 「외부로부터의 불법적인 접근으로 볼 수 있습니다」라고 설명합니다. 반대편에는 정보주체가 정상적으로 서비스를 이용하다가 시스템 오류로 의도치 않게 타인의 개인정보를 조회한 경우를 두고, 이를 시스템 오류로 볼 수 있다고 합니다.
입력창을 통한 공격을 개인정보위가 어떻게 기술해 왔는지도 참고가 됩니다. SQL 인젝션은 공개 웹페이지의 입력값을 조작해 데이터베이스의 정보를 빼내는 공격인데, 개인정보위는 이를 결정문에서 해커의 공격으로 적어 왔습니다. ㈜레저플러스 사건의 결정문은 개인정보처리방침 페이지와 공지사항 페이지를 대상으로 한 SQL Injection 공격으로 예약정보와 회원정보가 유출됐다고 적었습니다(제2025-023-295호, 2025. 11. 20.). ㈜비와이엔블랙야크 사건의 결정문은 고객 상담 페이지에 대한 SQL Injection 공격을 유출 경위의 출발점으로 적었습니다(제2025-015-229호, 2025. 7. 9.). 보람상조 계열사 사건들의 결정문은 SQL인젝션을 「웹 애플리케이션의 보안 취약점을 이용해 악의적인 SQL 구문을 입력하여 데이터베이스를 조작하거나 정보를 탈취하는 해킹 기법」으로 풀이했습니다(제2026-009-057호 등, 2026. 5. 13.). 다만 세 사건 모두 회사가 스스로 유출 신고를 했고, 결정문은 그 신고를 조사에 착수한 계기로 적었을 뿐 시행령 제40조 제1항 제3호의 신고 요건을 따로 판단하지는 않았습니다. 판단의 대상은 안전조치 의무 위반 등이었습니다. 안내서도 유출 가능성 통지를 설명하면서 SQL Injection 공격으로 개인정보 테이블에 대한 비정상 질의가 실행된 경우를 「불법적인 접근」으로 의심되는 정황의 첫 번째 예시로 듭니다(38쪽).
입력을 조작해 시스템이 권한 밖의 조회를 하게 만들었다는 구조는 SQL 인젝션과 프롬프트 인젝션에 공통됩니다. 차이도 있습니다. SQL 인젝션은 프로그램의 결함을 파고들지만, 프롬프트 인젝션에서 에이전트는 설계된 조회·호출 기능을 그대로 썼습니다. 그래서 「취약점을 이용한 정상적이지 않은 방법」에 해당하는지를 두고 다른 해석이 나올 수 있습니다. 한편 안내서가 시스템 오류로 분류한 경우는 정상적으로 서비스를 이용하던 정보주체가 의도치 않게 타인의 정보를 본 경우이므로, 지시문을 일부러 만들어 입력한 외부인의 경우와는 거리가 있어 보입니다. 정리하면 이 가상 사례에는 제3호에 해당한다고 볼 근거(권한 없는 외부인의 의도적인 입력 조작)와 아니라고 볼 근거(설계된 기능의 사용)가 함께 있습니다. 그리고 개인정보위가 프롬프트 인젝션을 놓고 이 기준을 적용한 해석이나 결정문은 안내서(2026. 9.)와 이 블로그가 모은 공개 결정문 범위에서 2026년 10월 15일 기준 찾지 못했습니다.
신고하지 않았는데 뒤에 제3호에 해당한다고 판단되면 신고 의무 위반의 문제가 남습니다. 반면 법 제34조와 시행령 제40조에는 요건 밖의 사고를 신고했다는 사정을 문제 삼는 규정이 없습니다. 덧붙이면, 조회된 고객이 1천 명 이상이었거나 고유식별정보가 섞여 있었다면 이 쟁점과 관계없이 제1호 또는 제2호로 신고 대상이었습니다.
가상 사례 · 분기점 3. 해석이 없는 요건 앞에서 신고할 것인가
| 선택지 | 그때 남는 기록 | 확보되는 사실과 남는 질문 |
|---|---|---|
| 제3호에 해당한다고 보고 신고 | 신고서와 접수 기록 | 신고 내용이 이후 조사 단계에서 출발 자료로 쓰일 수 있습니다. 신고서의 경위 칸에 확인된 사실과 추정을 나누어 적어야 합니다 |
| 해당하지 않는다고 보고 신고하지 않음 | 판단 근거 메모 | 판단이 뒤에 다르게 내려지면 신고 의무 위반의 문제가 남고, 근거 메모가 소명 자료가 됩니다 |
| 해석을 먼저 문의한 뒤 결정 | 문의 기록 | 회신이 72시간 안에 온다는 규정은 없습니다. 기한은 문의와 관계없이 진행됩니다 |
정보통신망법의 24시간 신고 기한도 함께 진행되나요?
법령으로 보면
정보통신망법 제48조의3 제1항 전단은 침해사고의 발생 사실을 알게 된 때부터 24시간 이내에 과학기술정보통신부장관이나 한국인터넷진흥원에 신고하도록 합니다. 14:00를 기산점으로 보면 남은 시간은 3시간이었고, 09:10을 기산점으로 보면 기한은 이미 지나 있었습니다.
이 신고는 침해사고를 전제로 합니다. 정보통신망법 제2조 제1항 제7호는 해킹 등의 방법으로 정보통신망이나 관련 정보시스템을 공격하는 행위로 발생한 사태를 침해사고로 정의합니다. 상담 창에 입력한 지시문이 그 「공격하는 행위」에 해당하는지에 대해서도 공개된 해석은 찾지 못했습니다. 다만 같은 조 제1항 후단은 다른 법률에 따른 침해사고 통지나 신고를 이미 했으면 정보통신망법상 신고를 한 것으로 본다고 정합니다. 이 블로그는 개인정보위에 한 유출 신고도 여기의 「다른 법률에 따른 신고」에 해당한다고 읽어 왔고, 그렇다면 회사가 24시간 안에 유출 신고를 마칠 때 침해사고 해당 여부를 끝까지 다투지 않아도 두 신고 의무가 함께 처리됩니다. 다만 이 갈음은 24시간 안에 신고했을 때 의미가 있습니다. 반대 방향의 갈음 규정은 없다는 점과 두 기한의 관계는 침해사고 신고와 개인정보 유출 신고에서 따로 정리했습니다. 2026년 10월 1일부터는 대통령령으로 정한 침해사고가 나면 이용자에게 알리는 의무(정보통신망법 제48조의3 제4항)도 있습니다.
가상 사례 · 분기점 4. 24시간 기한을 어떻게 처리할 것인가
| 선택지 | 그때 남는 기록 | 확보되는 사실과 남는 질문 |
|---|---|---|
| 24시간 안에 개인정보위에 유출 신고 | 접수 기록과 시각 | 정보통신망법 제48조의3 제1항 후단의 갈음으로 두 신고가 함께 처리되는 것으로 볼 수 있습니다. 어느 시각을 기산점으로 삼았는지에 따라 24시간 준수 여부가 달라집니다 |
| 과학기술정보통신부·한국인터넷진흥원에 침해사고만 먼저 신고 | 침해사고 신고 기록 | 침해사고 신고가 개인정보 보호법의 유출 신고를 갈음한다는 규정은 없어 72시간 신고를 따로 해야 합니다 |
| 침해사고가 아니라고 보고 72시간 유출 신고만 | 판단 근거 메모 | 24시간이 지난 뒤의 유출 신고가 정보통신망법 기한을 충족한 것으로 평가되는지에 관한 공개 해석은 확인하지 못했습니다 |
에이전트를 공급한 벤더가 사고를 냈다면 신고·통지는 누가 하나요?
법령으로 보면
안내서도 인지 즉시 로그의 자동 삭제 설정을 중지하거나 별도 저장소로 복사해 보존하라고 설명합니다. 벤더의 지위는 이름이 아니라 실제 처리 방식으로 정해집니다. 개인정보위의 「개인정보 처리방침 작성지침」(2026. 4.) 부록은 외부 생성형 AI 모델을 연동해 고객센터 자동응답을 구현하는 경우를 처리위탁의 예로 듭니다. 이 가상 사례의 벤더처럼 회사의 상담 기능을 대신 수행하고 기록을 회사를 위해 보관한다면 수탁자로 볼 여지가 큽니다. 다만 벤더가 그 기록을 자기 목적에 쓰는 구조라면 판단이 달라질 수 있습니다. 표의 원문은 에이전틱 AI 안내서가 답해야 할 질문에 옮겨 두었습니다.
수탁자라면 법 제26조 제8항이 제34조를 준용하므로 벤더도 자기 이름으로 통지·신고 의무를 질 수 있습니다. 그렇다고 회사의 의무가 벤더로 넘어가지는 않습니다. 안내서 45쪽 FAQ Q2는 원칙적으로 위탁자인 개인정보처리자에게 신고 의무가 있다고 답하고, 수탁사가 위탁사들을 명시해 일괄 신고하면 개별 신고를 갈음하는 것으로 볼 수 있다는 설명은 수탁사 시스템의 취약점으로 여러 위탁사의 개인정보가 같은 경위로 유출된 경우를 전제로 합니다. 위탁사 한 곳의 상담 기능에서 일어난 이 가상 사례에 그 설명을 그대로 옮기기는 어려워 보입니다. 안내서의 이 설명은 신고에 관한 것입니다. 정보주체 통지는 법 제34조 제1항이 개인정보처리자에게 지우는 의무이고, 제26조 제8항의 준용이 그 의무를 수탁자에게 옮긴다고 읽을 근거는 찾지 못했습니다. 나아가 법 제26조 제4항은 위탁자에게 수탁자 교육과 감독 의무를 지우므로, 사고 뒤 조사에서는 계약서와 점검 기록이 함께 확인될 수 있습니다. 위탁사와 수탁사의 책임 구조는 수탁사 사고에서 위탁사의 책임에서 다뤘습니다.
가상 사례 · 분기점 5. 벤더와 회사 사이에서 누가 무엇을 할 것인가
| 선택지 | 그때 남는 기록 | 확보되는 사실과 남는 질문 |
|---|---|---|
| 벤더의 신고에 맡김 | 벤더의 신고 사본 | 안내서는 원칙적으로 위탁자에게 신고 의무가 있다고 설명합니다. 일괄 신고 갈음은 여러 위탁사가 같은 경위로 유출된 경우를 전제로 합니다 |
| 회사가 자기 이름으로 신고·통지하고 벤더는 별도로 판단 | 회사의 신고서, 벤더와 주고받은 문서 | 신고서와 통지문의 경위 칸이 벤더 기록에 의존하므로 기록 수령 시각이 그대로 남습니다 |
| 계약 조항을 근거로 원본 제공과 보존을 서면 요구 | 요청서와 회신 | 계약에 기록 제공 기한이 없으면 72시간 안에 확보되는 사실의 범위가 벤더의 협조에 좌우됩니다 |
외부 서버의 자료가 삭제됐다면 신고나 통지를 줄일 수 있나요?
법령으로 보면
시행령 제40조 제1항 단서는 유출등의 경로가 확인되어 회수·삭제 등의 조치로 정보주체의 권익 침해 가능성이 현저히 낮아진 경우에는 신고하지 않을 수 있다고 정합니다. 이 단서는 신고에 관한 것입니다. 안내서 46쪽도 이 단서에 해당하는 경우에 대해 「다만, 이 경우에도 정보주체에 대한 유출등 통지 의무는 있으므로 별도로 통지하여야 한다」고 적고 있습니다(개인정보위, 「개인정보 유출등 대응 안내서」, 2026. 9.).
단서의 요건을 갖추었는지도 따로 따져야 합니다. 외부 서버에 이미 나간 자료는 사본이 만들어졌는지를 회사가 확인할 방법이 마땅치 않고, 이 가상 사례의 회신도 내려받은 사람에 관해서는 말하지 않았습니다. 이 상태에서 권익 침해 가능성이 「현저히 낮아진」 것으로 보기는 어려워 보입니다. 사고 초기에 이 단서를 근거로 신고를 미루면, 회수가 끝내 확인되지 않을 때 신고 기한이 이미 지나 있을 수 있습니다. 한편 법 제34조 제3항은 회수·삭제 등 피해 확산 방지 조치를 따로 요구하므로, 삭제 요청은 신고 여부와 관계없이 해야 하는 조치입니다.
가상 사례 · 분기점 6. 삭제 회신을 어떻게 다룰 것인가
| 선택지 | 그때 남는 기록 | 확보되는 사실과 남는 질문 |
|---|---|---|
| 단서를 근거로 신고하지 않는 쪽을 검토 | 삭제 회신 | 경로 확인과 권익 침해 가능성의 현저한 감소가 요건입니다. 삭제 전 사본 여부를 알 수 없는 회신만으로는 요건을 판단하기 어렵고, 통지 의무는 남습니다. 이미 접수한 신고에 이 단서가 어떻게 적용되는지는 조문이 정하지 않았습니다 |
| 신고를 유지하고 삭제 사실을 개인정보위에 추가로 알림 | 추가 제출 기록 | 회사가 취한 조치가 시각과 함께 남습니다 |
| 통지문의 대응조치 칸에 삭제 요청과 회신을 적음 | 통지문 | 법 제34조 제1항 제4호의 대응조치로 정보주체에게 전달됩니다 |
통지문에는 무엇을 적고, 어떤 기록을 남겨야 하나요?
15:00 CPO는 612명에게 보낼 통지문을 확정했습니다.
18:00 문자와 이메일로 통지를 발송했고, CS 리더는 수신 오류가 난 연락처를 따로 모아 재발송 기록을 만들었습니다.
저녁 법무팀장은 사고 기록을 정리했습니다. 기록에는 세 후보 인지 시각과 각 시각에 누가 무엇을 확인했는지, 벤더에 기록을 요청하고 받은 시각, 신고와 통지의 시각, 제3호와 침해사고 해당 여부에 관한 판단 근거가 들어갔습니다.
법령으로 보면
법 제34조 제1항은 통지 기재사항을 정하고, 2026년 9월 11일부터 손해배상·법정손해배상의 청구와 분쟁조정 등 정보주체의 법적 권리를 안내하는 제6호가 더해졌습니다. 항목이나 경위를 아직 확인하지 못했다면 시행령 제39조 제2항에 따라 확인된 내용으로 먼저 통지하고 나머지는 확인되는 즉시 통지해야 하지만, 이 가상 사례에서는 벤더 기록으로 대부분이 확인된 상태였습니다.
가상 사례 밖의 실제 사건 하나를 덧붙입니다. 유출을 인지한 당일 통지 이메일을 보냈으나 발송 시스템 오류로 일부 이용자에게 통지가 누락됐고, 누락된 대상자를 포함한 통지를 인지 후 약 290일이 지나 완료한 사건에서 결정문은 그 완료일까지를 지연으로 적었습니다(제2024-214-494호, 2024. 7. 10.). 이 사건은 AI 에이전트 사고가 아니며, 위 가상 회사의 재발송 기록이 어떤 평가를 받을지를 보여 주는 것도 아닙니다.
가상 사례 · 분기점 7. 통지문의 기재사항을 어떻게 채웠는가
| 기재사항(법 제34조 제1항) | 가상 사례에서 적은 내용 | 확인 상태 |
|---|---|---|
| 제1호 유출된 개인정보의 항목 | 성명·휴대전화번호·배송지 주소·주문 상품명 | 벤더 실행 기록으로 확인 |
| 제2호 유출 시점과 경위 | 0일차 23:40~24:00, 상담 창에 입력된 지시문에 따라 에이전트가 외부 주소로 전송 | 확인 |
| 제3호 피해 최소화를 위해 정보주체가 할 수 있는 방법 | 주문·배송을 사칭하는 연락과 결제 요구에 대한 주의 | 회사가 작성 |
| 제4호 회사의 대응조치와 피해 구제절차 | 외부 호출 기능 차단, 외부 서버 삭제 요청과 회신, 개인정보위 신고 | 확인 |
| 제5호 피해 신고 접수 부서와 연락처 | 전담 창구와 운영 시간 | 회사가 지정 |
| 제6호 손해배상·분쟁조정 등 법적 권리와 행사 방법 | 법 제39조·제39조의2에 따른 손해배상 청구, 제43조에 따른 분쟁조정 | 2026년 9월 11일 추가된 항목 |
개인정보위는 법 제63조에 따라 관계 물품·서류 등 자료의 제출을 요구하고 검사할 수 있고, 그때 사고 이후 남긴 기록이 다시 쓰입니다. 통지·신고 이후의 조사와 처분 단계는 유출 통지·신고를 마친 다음에, 상황별 통지문 양식은 유출 통지문 양식에 있습니다.
기한을 넘기거나 통지하지 않은 회사는 결정문에 어떻게 적혔나요?
이 절은 가상 사례의 선택과 결과를 잇는 것이 아니라, 실제로 기한을 넘기거나 통지하지 않은 사건을 개인정보위가 어떻게 적었는지 보여 주는 것입니다. 이 블로그가 모은 공개 결정문에서 유출 통지·신고 의무 위반으로 처분된 의결은 119건입니다. 위반의 모습으로 나누면 지연 103건, 미이행 14건이고, 통지 자체는 기한 안에 했지만 법정 기재사항이 빠져 처분된 의결도 2건 있습니다. 통지 지연 일수가 확인되는 사건의 중앙값은 14일이고, 가장 늦은 사건은 940일이었습니다(2026-10-12 수집분, 이현섭 변호사 집계).
결정문의 문장은 인지 시점을 회사의 확정보다 앞에 두는 경우가 많습니다. 크리덴셜 스터핑 공격으로 회원 1명의 정보가 유출된 사실을 안 뒤, 분석을 통해 직원 정보의 유출도 「충분히 알 수 있었음에도」 72시간을 넘겨 통지한 사건이 있습니다(제2024-006-164호, 2024. 3. 27.). 한국인터넷진흥원에서 회원정보 판매 게시물에 관한 안내 메일을 받고도 구체적으로 확인하지 않은 채 전체 회원 대상 공지만 하고, 유출이 확인된 이용자 3명에게 개별 통지를 하지 않은 사건은 미이행으로 처분됐습니다(제2023-009-098호, 2023. 5. 24.). 어느 사건도 AI 에이전트 사고는 아닙니다.
사건별 처분과 금액, 공표 여부는 유출 통지 지연 제재 전수에 의결 단위로 있습니다. 같은 자료에서 통지가 늦은 사건에 과징금이 붙은 경우는 대개 안전조치 의무 위반이 함께 인정된 경우였다는 점도 정리해 두었습니다.
이 가상 사례에서 법령이 답을 정해 두지 않은 곳은 어디인가요?
72시간 동안 회사가 부딪힌 질문 가운데 조문이 답을 직접 주지 않는 곳은 다음 다섯 가지입니다. 맨 앞의 표에서 「법령이 정하지 않은 것」 칸에 적은 내용을 질문 형태로 다시 모았습니다.
- 에이전트의 이상 동작을 본 시각, 외부 전송을 확인한 시각, 전송 내용을 확인한 시각 가운데 어느 것이 「알게 된 때」인지
- 공개 상담 창에 입력한 지시문으로 에이전트를 움직인 행위가 시행령 제39조의2 제1항 제1호의 「불법적인 접근」과 제40조 제1항 제3호의 「외부로부터의 불법적인 접근」에 해당하는지
- 같은 행위가 정보통신망법의 침해사고에 해당하는지
- 에이전트를 공급하고 기록을 보관하는 벤더가 수탁자인지, 그리고 계약에 기록 제공 기한이 없을 때 회사가 72시간 안에 받을 수 있는 자료의 범위
- 외부 서버의 삭제 회신만으로 권익 침해 가능성이 「현저히 낮아진」 것으로 볼 수 있는지
2번과 3번은 2026년 10월 15일 기준 개인정보위나 과학기술정보통신부의 공개 해석을 찾지 못한 질문입니다. 이런 자리에서 회사가 할 수 있는 일은 판단의 근거와 시각을 남기고, 해석이 갈릴 때 의무를 이행하는 쪽의 선택지가 무엇인지 확인하는 것입니다. 사고의 경위와 계약, 남아 있는 기록에 따라 결론이 달라질 수 있습니다. 우리 회사의 사고에 통지·신고 요건을 대입해 보려면 유출 통지·신고 판정기를 쓸 수 있고, 에이전트를 도입하는 단계에서 지위·권한·기록을 미리 점검할 질문은 에이전틱 AI 안내서가 답해야 할 질문에 정리했습니다. 이 글은 가상 사례로 법령의 구조를 설명한 것이고 특정 사안에 관한 법률자문이 아닙니다.
자주 묻는 질문
Q. 고객상담 AI 에이전트가 프롬프트 인젝션으로 고객 정보를 외부에 보냈다면, 1천 명 미만이어도 유출 신고 대상인가요?
Q. AI 에이전트의 이상 동작을 처음 본 때와 외부 전송을 확인한 때 가운데 72시간은 언제부터 세나요?
Q. 에이전트를 공급한 AI 벤더가 수탁자라면 유출 신고와 통지는 벤더가 하나요?
Q. 외부 서버에 있던 자료가 삭제됐다면 유출 신고나 통지를 하지 않아도 되나요?
참고 자료
- 개인정보 보호법(법률 제21445호, 2026. 9. 11. 시행) 제26조, 제34조, 제39조, 제39조의2, 제43조, 제63조
- 개인정보 보호법 시행령 제39조부터 제40조까지(제39조의2·제39조의3 포함). 대통령령 제36671호로 2026. 9. 11. 시행된 판입니다
- 정보통신망 이용촉진 및 정보보호 등에 관한 법률(법률 제21988호, 2026. 10. 2. 시행) 제2조 제1항 제7호, 제48조의3. 제48조의3 제4항(이용자 통지)은 법률 제21500호로 신설되어 2026. 10. 1. 시행됐습니다
- 개인정보보호위원회, 「개인정보 유출등 대응 안내서」(2026. 9.) 26쪽(로그 보존), 33쪽(통지 기한과 인지 시점 입증), 38쪽(가능성 통지의 의심되는 정황과 예시), 45쪽(FAQ Q1·Q2), 46쪽(신고하지 않을 수 있는 경우)
- 개인정보보호위원회, 「개인정보 처리방침 작성지침」(2026. 4.) 부록 1(127쪽 「개인정보 처리위탁과 제3자 제공」 표)
- 개인정보보호위원회 결정 제2025-024-299호, 제2023-010-109호, 제2024-006-164호, 제2023-009-098호, 제2024-214-494호(유출 통지·신고), 제2025-023-295호, 제2025-015-229호, 제2026-009-057호 등(SQL 인젝션 유출 경위)
- 유출 통지 지연 제재 전수 표 · 유출 통지·신고 판정기