Salesforce PIPA 데이터 국외 이전 검토에서 가장 위험한 문장은 “한국에서 쓸 조직이니 리전만 확인하면 된다”입니다. 저장 위치는 확인해야 하지만, 국외 이전 판단은 데이터가 어디에 저장되는지만 묻지 않습니다. 어떤 업무가 어떤 개인정보를 어느 처리자에게 보내고, 그 경로를 누가 승인하고 바꾸는지까지 계약 전에 닫아야 합니다.
개인정보 보호법(PIPA)의 국외 이전 규정은 데이터 이동의 근거와 통제를 다룹니다. 국가법령정보센터의 개인정보 보호법과 개정법 시행 안내는 국외 이전의 요건이 동의 하나로 환원되지 않으며, 이전 중지 명령의 법적 근거도 마련됐다고 설명합니다. 이 글은 법률 자문이 아닙니다. 법무팀, 개인정보보호책임자, Salesforce 운영 책임자가 같은 사실을 검토할 수 있게 만드는 계약 전 작업의 구조를 다룹니다.
리전 선택은 시작점일 뿐입니다
인스턴스가 어느 지역에서 운영되는지는 중요한 사실입니다. 그러나 그것만으로 저장, 처리, 지원, 로그, 외부 연동의 경로가 모두 같은 국가에 머문다고 결론내릴 수는 없습니다. Salesforce의 Trust and Compliance Documentation도 서비스와 인스턴스별 문서를 확인하도록 안내합니다. 제품군 이름이나 판매 제안서의 지역 문구를 조직별 처리 경로의 증명으로 바꾸면 안 됩니다.
문제는 “Salesforce가 어디에 있나”가 아닙니다. 문제는 특정 업무 흐름에서 개인정보가 어디로 나가고, 누가 그 이동을 설명할 수 있나입니다. 고객센터가 Case를 열어 처리하는 흐름, 포털이 Contact를 생성하는 흐름, 외부 시스템이 API로 레코드를 읽는 흐름은 각각 다른 검토 대상입니다. 같은 조직 안에서도 데이터 필드와 목적, 호출 주체, 오류 처리 방식이 다르면 하나의 답으로 묶을 수 없습니다.
계약 전에는 기능 목록보다 데이터 흐름 목록을 먼저 만드십시오. 각 흐름에 시작 시스템, 수신 시스템, 개인식별 가능 필드, 처리 목적, 저장 여부, 전송 시점, 운영 책임자를 적습니다. 이 목록이 없으면 DPA, 보안 부속서, 개인정보 처리방침, 설정 화면이 서로 다른 대상을 말하게 됩니다. 승인 문서는 있는데 실제 API 호출은 그 범위 밖에 있는 상태가 가장 늦게 발견됩니다.
계약 전에 닫아야 할 7개 확인 항목
첫 항목은 업무 목적입니다. “CRM 운영”은 목적이 아닙니다. 예를 들어 고객 문의 분류, 계약 갱신 알림, 파트너 포털 인증처럼 데이터가 쓰이는 업무 단위로 쪼개야 합니다. 목적이 넓으면 필요 필드를 줄일 기준도 사라집니다.
둘째는 데이터 항목입니다. 객체 이름만 적지 말고 실제 필드를 봐야 합니다. 이름, 연락처, 고객번호, 상담 내용, 첨부파일, 자유 입력 메모는 노출 위험과 필요성이 다릅니다. 테스트 환경의 복제 데이터와 운영 오류 로그도 목록에서 빠지기 쉽습니다. 개인정보가 아닌 값이라고 단정하기 어려운 식별자도 별도 판단이 필요합니다.
셋째는 수신자와 역할입니다. Salesforce, 계열사, 하위 처리자, SI, 고객사가 직접 계약한 외부 서비스는 같은 역할이 아닐 수 있습니다. 누가 처리 목적과 수단을 정하는지, 누가 지시에 따라 처리하는지, 누가 사고와 변경을 통지하는지 계약 문서에서 분리해 둬야 합니다. 이 구분은 책임을 회피하려는 표가 아니라, 문제가 생겼을 때 확인할 창구를 정하는 작업입니다.
넷째는 실제 이동입니다. 저장 위치만이 아니라 브라우저에서 들어온 값, API 요청, 배치 파일, 통합 미들웨어, 실패 재시도 저장소, 지원 요청에 붙는 자료를 모두 확인합니다. 외부 시스템을 연결한 뒤에는 정상 처리만 보지 말고 실패한 메시지가 어디에 남는지도 확인해야 합니다. 운영에서 개인정보가 가장 오래 남는 곳이 주 데이터베이스가 아닐 때가 있습니다.
다섯째는 적용 근거와 고지입니다. PIPA 제28조의8의 어느 경로가 해당하는지는 계약 관계, 수신자, 이전 방식, 목적, 최신 하위 규정과 사실관계에 따라 달라집니다. 기술팀이 “계약이 있으니 충분하다”고 판단하거나, 법무팀이 데이터 흐름을 보지 못한 채 조항만 검토하는 방식은 모두 불완전합니다. 법무팀이 적용 근거를 판단할 수 있도록 기술팀은 이전되는 항목, 국가 또는 지역, 시점, 수신자, 처리 목적을 검증 가능한 형태로 제공해야 합니다.
여섯째는 보관과 삭제입니다. 국외 이전 검토는 전송 시점에 끝나지 않습니다. 대화 기록, 감사 로그, 통합 오류 큐, 백업, 테스트 복제본은 별도 보관 규칙을 가질 수 있습니다. 계약 종료나 사용 중단 시 어떤 자료가 어떤 절차로 삭제되는지, 삭제 완료를 어떤 기록으로 확인하는지까지 책임표에 넣어야 합니다.
일곱째는 변경 통제입니다. 새 Integration User, 새 Connected App, 새 Flow, 필드 추가, 외부 Action, 지원 범위 변경은 데이터 흐름을 바꿀 수 있습니다. 변경 요청서에 개인정보 항목과 국외 이전 영향 확인란을 넣고, 영향이 있는 변경은 법무·보안 검토로 넘기는 기준을 정하십시오. 연 1회의 문서 갱신보다 이 통제가 더 중요합니다. 실제 경로는 배포와 설정 변경으로 먼저 바뀌기 때문입니다.
계약 문서와 설정 화면을 같은 증적으로 봅니다
계약 검토의 산출물은 조항 목록만으로 충분하지 않습니다. 운영팀이 다시 확인할 수 있는 증적 묶음이 필요합니다. 한 흐름마다 계약상 처리자와 목적, Salesforce 설정 또는 통합 설정의 근거, 실제 호출을 확인한 날짜, 책임자, 다음 재검토 조건을 연결합니다.
이 구조는 품의에도 도움이 됩니다. 비용이나 일정만 올린 문서는 “국외 이전은 검토 중”이라는 빈칸을 남깁니다. 반대로 승인 대상 업무, 허용 필드, 금지 필드, 수신자, 보관 기간, 변경 승인자를 한 장으로 정리하면 CIO와 개인정보보호책임자가 무엇을 승인하는지 구분할 수 있습니다. 계약 협상과 구현 일정이 충돌할 때도 어느 결정을 미루면 어떤 흐름이 멈추는지 보입니다.
2025년 개인정보보호위원회는 Kakao Pay와 Apple 등의 국외 이전 관련 위반을 제재하면서, 정보주체가 위탁 처리와 국외 이전을 알 수 없었던 문제를 지적했습니다. 해당 PIPC 제재 발표는 Salesforce 계약의 사실관계를 판단하는 자료가 아닙니다. 다만 “처리자는 계약서에 있으니 운영팀은 확인하지 않아도 된다”는 접근이 위험하다는 점은 분명히 보여 줍니다. 실제 수신자와 처리 목적, 고지와 운영 사실을 서로 대조해야 합니다.
SI가 구현을 맡더라도 고객사가 규제 책임을 넘길 수는 없습니다. SI는 흐름도와 설정 증적을 만들고, 고객사는 처리 목적과 승인 기준을 결정하며, 법무와 개인정보보호 조직은 적용 근거와 고지 요건을 판단해야 합니다. 각자의 산출물이 같은 흐름 ID를 참조하지 않으면, RACI는 있어도 검토가 연결되지 않습니다.
운영 변경이 새 검토를 촉발하는 시점
국외 이전 검토를 프로젝트 종료 문서로 보관하면 다음 변경에서 바로 낡습니다. 운영 책임자는 변경이 생길 때마다 전체 법률 검토를 다시 열 필요는 없습니다. 대신 어떤 변경이 기존 흐름의 필드, 수신자, 목적, 보관, 지역을 바꾸는지 판별할 수 있어야 합니다.
예를 들어 기존 통합에 이메일 주소를 추가하는 변경은 단순 매핑 수정처럼 보일 수 있습니다. 그러나 이전에 승인된 흐름이 고객번호만 전송하도록 설계됐다면, 처리되는 개인정보와 고지의 범위가 달라질 수 있습니다. 반대로 화면 문구만 바꾸고 데이터 경로와 처리 목적이 변하지 않는 배포는 같은 수준의 검토를 요구하지 않을 수 있습니다. 판단 기준은 기능의 크기가 아니라 처리 사실의 변화입니다.
이 기준을 운영위원회와 배포 절차에 넣으면, 개인정보 검토는 배포를 막는 마지막 관문이 아니라 설계 조건이 됩니다. 이미 운영 중인 조직은 Agentforce와 PIPA 데이터 흐름 검토에서 다룬 방식처럼 저장, 추론, 외부 호출을 분리해 현재 경로부터 다시 그릴 수 있습니다. 복구 작업은 오래된 문서를 다시 쓰는 일이 아니라, 현재 설정과 계약의 불일치를 찾아 닫는 일입니다.
서비스 제공자에게 모든 답을 기대하기보다, 조직이 확인해야 할 질문을 먼저 고정하는 편이 낫습니다. 서비스 맥락과 프로그램 통제 방식도 같은 원칙을 따릅니다. 운영 가능한 결정은 기능 설명이 아니라 책임자, 증적, 다음 검토 시점을 함께 갖습니다.
핵심 정리
- Salesforce PIPA 데이터 국외 이전 검토는 리전 선택이 아니라 업무 흐름별 사실 확인입니다. 저장 위치, API, 오류 저장소, 지원 자료, 외부 연동을 분리해 봐야 합니다.
- 계약서와 설정은 같은 흐름을 설명해야 합니다. 처리자, 목적, 데이터 항목, 보관과 변경 기준이 서로 다른 문서에 흩어져 있으면 승인 근거가 약해집니다.
- 법무팀은 적용 근거를 판단하고, 기술팀은 검증 가능한 처리 사실을 제공합니다. 한쪽이 다른 쪽의 일을 대신하면 빠진 항목이 남습니다.
- 새 필드, 새 수신자, 새 통합, 목적 변경은 재검토 신호가 될 수 있습니다. 변경 규모가 아니라 개인정보 처리 사실이 달라졌는지로 판단합니다.
- 법률 자문은 별도로 받아야 합니다. 이 프레임은 그 검토가 실제 Salesforce 운영과 연결되게 만드는 관리 도구입니다.
