핵심 요약 제휴 API 응답에 요청하지 않은 개인정보가 섞여 오고 받은 쪽이 그것을 보유하게 되는 일은 예외적인 사고가 아닙니다. 개인정보위가 2026년 7월 8일 공개한 사례에서는 안심번호만 전송하도록 정책을 바꾼 회사의 API가 실제로는 휴대전화번호까지 보내고 있었고, 받는 쪽 시스템에 13.5만 명분이 보관돼 있었습니다. 위탁이든 제3자 제공이든 받은 쪽은 법 제16조(최소수집), 제21조(파기), 제30조(처리방침), 제34조(통지·신고), 제64조의2(과징금)의 수범자가 됩니다.
제휴사와 연동하면서 우리가 쓰기로 한 것은 주문번호와 수령인 이름뿐입니다. 그런데 응답 JSON을 열어 보면 휴대전화번호 필드가 함께 옵니다.
화면에는 쓰지 않습니다. 개발자는 무시하도록 짜 두었습니다. 그래도 값은 우리 서버까지 왔고, 연동 로그에는 응답 전문이 그대로 적립되고 있습니다.
이 상태를 법은 어떻게 볼까요.
이런 일이 실제로 얼마나 있나?
개인정보보호위원회는 2026년 7월 8일 API를 통한 개인정보 유출 예방을 당부하면서 세 가지 사례를 공개했습니다.
한 회사는 권한 관리가 되지 않은 API에 비정상 접근이 이루어져 약 3,700만 명의 이름·주소·이메일·전화번호·생년월일 등이 유출됐습니다. 다른 회사는 이용자 보호를 위해 휴대전화번호 대신 안심번호만 전송하는 것으로 정책을 바꿨는데, 실제 API는 휴대전화번호도 함께 전송하고 있었고 타사 시스템에 약 13.5만 명분이 보관된 사실이 확인됐습니다. 또 다른 회사는 최신 API에는 다중 인증을 적용해 두었으나 계속 동작하던 오래된 API를 통해 별도 권한 확인 없이 고객 데이터를 조회할 수 있었습니다.
개인정보위는 같은 자료에서 API를 제공받아 서비스를 운영하는 사업자도 응답 데이터에 서비스와 무관한 개인정보가 포함되어 있는지 확인하고 즉시 제거해야 한다고 명시했습니다. 점검 대상이 제공하는 쪽에만 있지 않다는 뜻입니다.
위탁인지 제공인지부터 정해야 하나?
받은 쪽의 지위를 논할 때 위탁이냐 제3자 제공이냐를 먼저 가르려는 경우가 많습니다. 이 국면에서는 그 구분이 결론을 바꾸지 않습니다.
법 제26조 제8항은 수탁자에 관하여 제15조부터 제18조까지, 제21조, 제30조, 제31조, 제34조, 제64조의2 등을 준용하면서 ‘개인정보처리자’를 ‘수탁자’로 본다고 정합니다.
위탁이면 준용으로, 제3자 제공이면 자기 자격으로 걸립니다. 어느 경로를 타든 받은 쪽이 같은 조문의 수범자가 됩니다.
“우리가 요청한 적 없다"는 항변이 되나?
법 제16조 제1항은 목적에 필요한 최소한의 개인정보를 수집하도록 정하고, 이어서 최소한의 개인정보 수집이라는 입증책임은 개인정보처리자가 부담한다고 못 박았습니다.
기준은 요청 여부가 아니라 보유 여부입니다. 연동 규격서에 없는 항목이 응답에 실려 왔고 그것을 걸러내지 않은 채 저장했다면, 최소수집을 입증할 자료는 남지 않습니다.
목적이 없는 데이터는 파기 대상이기도 합니다. 법 제21조 제1항은 처리 목적이 달성되었거나 그 개인정보가 불필요하게 되었을 때 지체 없이 파기하도록 정합니다. 애초에 쓸 목적이 없었던 항목은 받은 그 순간부터 여기에 해당할 여지가 큽니다.
처리방침과 어긋나는 것이 왜 문제가 되나?
시행령 제31조 제1항 제1호는 ‘처리하는 개인정보의 항목’을 처리방침에 적도록 정합니다. 법 제30조 제1항 제8호가 위임한 필수 기재사항입니다.
처리방침에 없는 항목이 데이터베이스에 들어 있으면, 그 불일치는 조사가 시작되기 전에 이미 문서로 존재하는 상태가 됩니다.
개인정보위는 2026년 처리방침 평가에서 법령 준수 여부와 함께 실제 개인정보 처리 현황과의 일치성을 평가 항목으로 두고 있고, 올해는 7개 분야 52개 서비스가 대상입니다. 평가와 조사는 별개 절차이지만, 보는 지점이 같습니다.
사고가 나면 누가 신고하나?
받은 쪽 시스템에서 데이터가 나갔다면 통지·신고 의무자는 받은 쪽입니다. 법 제34조 제1항은 개인정보처리자가 유출등을 알게 되었을 때를 기준으로 의무를 지우고, 데이터의 출처를 요건으로 삼지 않습니다.
과징금도 마찬가지입니다. 법 제64조의2 제1항 제9호는 개인정보가 유출된 경우를 과징금 사유로 들고, 단서에서 제29조에 따른 안전성 확보 조치를 다한 경우를 면제 사유로 둡니다. 우리가 수집한 것이 아니라는 사정은 두 조문 어디에도 적혀 있지 않습니다.
유출을 인지한 뒤의 절차 전체는 개인정보 유출 인지 후 72시간 안에 해야 할 일과 하면 안 되는 일에 정리해 두었습니다.
제공한 쪽에는 무엇을 물을 수 있나
연동 규격서에 없는 항목을 보낸 것이 계약 위반으로 구성될 여지는 있습니다. 다만 받은 쪽이 걸러내지 않은 사정이 함께 평가되므로, 계약서에 응답 항목의 범위와 초과 전송 시의 처리 의무가 적혀 있는지에 따라 결론이 갈립니다.
이 구조는 위탁 사고에서 위탁사와 수탁사 사이에 벌어지는 책임 배분과 같은 축에 있습니다. 그 부분은 수탁사 직원의 실수로 개인정보가 유출됐을 때 위탁사의 책임 범위에서 다뤘습니다.
이 문제가 조사에서 드러나는 방식
이 사안은 확인 비용이 거의 들지 않습니다. API 응답 스키마 한 장과 처리방침 한 페이지를 나란히 놓으면 됩니다. 포렌식도, 로그 분석도 필요하지 않습니다.
연동 규격서와 그 변경 이력은 언제부터 그 항목을 보유했는지를 가리키는 자료가 됩니다. 정책을 바꿨는데 API는 그대로였다면, 바꾼 시점의 회의록과 배포 기록이 오히려 인지 시점을 앞당기는 근거로 읽힐 수 있습니다.
지금 할 수 있는 점검은 세 가지를 나란히 놓는 일입니다. 응답 필드 목록, 처리방침에 적힌 항목, 실제 저장 컬럼과 로그. 셋이 어긋나는 지점이 그대로 답이 됩니다.
자주 묻는 질문
API 응답으로 받기는 했지만 저장하지 않고 버렸습니다. 그래도 문제가 되나요?
저장하지 않았다는 사실을 스스로 입증할 수 있어야 합니다. 개인정보 보호법 제16조 제1항은 목적에 필요한 최소한의 수집이라는 점의 입증책임을 개인정보처리자에게 지우고 있습니다. 실무에서는 애플리케이션 코드가 해당 필드를 쓰지 않더라도 접근로그·에러로그·중계 서버 캐시에 값이 남는 경우가 많으므로, 응답 필드 목록과 실제 저장·기록 지점을 함께 확인해야 판단이 가능합니다.
제휴사와 위탁계약을 맺고 받은 데이터인데, 그러면 제공한 쪽 책임 아닌가요?
위탁으로 구성해도 받은 쪽이 의무에서 빠지지는 않습니다. 법 제26조 제8항은 수탁자에 관하여 제15조부터 제18조까지, 제21조, 제30조, 제31조, 제34조, 제64조의2 등을 준용하면서 ‘개인정보처리자’를 ‘수탁자’로 본다고 정하고 있습니다. 위탁이면 준용으로, 제3자 제공이면 자기 자격으로 걸리므로 구분과 무관하게 같은 조문의 수범자가 됩니다.
제휴사가 보내준 항목이라 우리 처리방침에는 쓰지 않아도 되지 않나요?
보유하고 있다면 써야 합니다. 시행령 제31조 제1항 제1호는 ‘처리하는 개인정보의 항목’을 처리방침 필수 기재사항으로 정하고 있고(법 제30조 제1항 제8호 위임), 기준은 어디에서 왔는지가 아니라 지금 처리하고 있는지입니다. 개인정보위는 2026년 처리방침 평가에서 실제 개인정보 처리 현황과의 일치성을 평가 항목으로 두고 있습니다.