Salesforce 계약 전 검토에서 가장 위험한 문장은 “한국에서 쓸 조직이니 리전만 확인하면 된다”입니다. 저장 위치는 반드시 확인해야 하지만 출발점일 뿐입니다. 개인정보 국외 이전 판단은 어떤 업무가 어떤 개인정보를 어느 수신자에게 보내는지, 그 경로를 누가 승인하고 바꾸는지까지 묻습니다. 이 노트는 법무팀, 개인정보 보호책임자와 함께 준비하는 확인 목록이며 법률 자문이 아닙니다.
리전은 출발점입니다
개인정보 보호법(PIPA)의 국외 이전 규정은 데이터 이동의 근거와 통제를 다룹니다. 개인정보 보호법 영문본과 개인정보보호위원회의 개정법 시행 안내에 따르면 국외 이전 요건은 동의 하나로 환원되지 않으며, 이전 중지 명령의 법적 근거도 생겼습니다.
인스턴스가 운영되는 지역은 중요한 사실입니다. 그렇다고 저장, 처리, 지원, 로그, 외부 연동이 모두 같은 국가에 머문다고 결론 내릴 수는 없습니다. Salesforce도 Trust and Compliance Documentation에서 서비스별 문서를 확인하도록 안내합니다. 제안서에 적힌 지역 문구는 조직별 처리 경로를 증명하지 못합니다.
검토 단위는 업무 흐름입니다. 상담원이 Case를 처리하는 흐름, 포털이 Contact를 만드는 흐름, 외부 시스템이 API로 레코드를 읽는 흐름은 서로 다른 검토 대상입니다. 그래서 계약 전에는 기능 목록보다 데이터 흐름 목록을 먼저 만듭니다. 흐름마다 시작 시스템, 수신 시스템, 식별 가능한 필드, 처리 목적, 저장 여부, 전송 시점, 운영 책임자를 적습니다. 이 목록이 없으면 DPA, 보안 부속서, 개인정보 처리방침, 설정 화면이 각기 다른 대상을 설명하게 됩니다.
계약 전에 닫을 7개 항목
- 업무 목적. “CRM 운영”은 목적이 아닙니다. 고객 문의 분류, 계약 갱신 알림, 파트너 포털 인증처럼 업무 단위로 나눕니다. 목적이 넓으면 필드를 줄일 기준도 사라집니다.
- 데이터 항목. 객체 이름이 아니라 실제 필드를 봅니다. 이름, 연락처, 고객번호, 상담 내용, 첨부파일, 자유 입력 메모는 위험도가 서로 다릅니다. 테스트 환경의 복제 데이터와 오류 로그도 목록에 넣습니다.
- 수신자와 역할. Salesforce, 계열사, 하위 처리자, SI, 고객사가 직접 계약한 외부 서비스는 역할이 다를 수 있습니다. 누가 목적과 수단을 정하고, 누가 지시에 따라 처리하고, 누가 사고와 변경을 통지하는지 계약 문서에서 구분합니다.
- 실제 이동 경로. 저장 위치뿐 아니라 API 요청, 배치 파일, 통합 미들웨어, 실패 메시지 재시도 저장소, 지원 요청에 붙는 자료까지 확인합니다. 개인정보가 가장 오래 남는 곳이 주 데이터베이스가 아닐 때도 있습니다.
- 적용 근거와 고지. PIPA 제28조의8 가운데 어느 경로에 해당하는지는 계약 관계, 수신자, 이전 방식, 목적, 사실관계에 따라 달라집니다. 판단은 법무팀이 내립니다. 기술팀은 이전 항목, 국가 또는 지역, 시점, 수신자, 목적을 검증 가능한 형태로 넘깁니다.
- 보관과 삭제. 대화 기록, 감사 로그, 통합 오류 큐, 백업, 테스트 복제본은 보관 규칙이 따로 있을 수 있습니다. 계약 종료 시 무엇을 어떤 절차로 삭제하고, 삭제 완료를 어떤 기록으로 확인하는지 책임표에 넣습니다.
- 변경 통제. 새 Integration User, 새 Connected App, 새 Flow, 필드 추가, 외부 Action은 데이터 흐름을 바꿀 수 있습니다. 변경 요청서에 개인정보 항목과 국외 이전 영향 확인란을 넣고, 영향이 있으면 법무·보안 검토로 넘기는 기준을 정합니다.
일곱째 항목이 연 1회 문서 갱신보다 중요합니다. 실제 경로는 배포와 설정 변경으로 먼저 바뀌기 때문입니다.
Agentforce와 생성형 AI 기능을 켤 때
Agentforce나 Prompt Builder를 켜면 흐름 목록에 새 줄이 생깁니다. 국가별 투자 발표나 Hyperforce 소개 자료는 특정 조직의 추론, 로그, Data 360 데이터가 어디서 처리되는지 증명하지 않습니다. 같은 7개 항목을 세 지점에 다시 적용합니다.
- Data 360 수집과 Identity Resolution. 수집 필드, 소스 위치, 테넌트 위치, 매칭 키, 보유 기간, 접근 권한을 확인합니다. 매칭 키는 최소한의 식별자로 제한하고, 민감한 식별자는 필요성과 보호 조치를 따로 승인받습니다.
- Prompt Builder 입력. 템플릿에 들어가는 필드, 마스킹이 실제로 적용되는지, 관여하는 모델 제공자와 하위 처리자, 입력·출력·감사 로그 보관 기간을 확인합니다. Trust Layer 기능을 켰다고 PIPA 검토가 끝나지는 않습니다.
- Action의 외부 호출. MuleSoft, Apex, Flow, External Services가 외부 시스템을 부르면 Salesforce 계약 밖의 처리자와 지역이 추가될 수 있습니다. 입력·출력 필드, 인증 주체, 오류 로그, 재시도 저장소까지 흐름도에 넣습니다.
토큰화와 가명처리는 노출을 줄입니다. 다만 재결합 가능성과 키 관리 방식에 따라 여전히 개인정보일 수 있으므로, 국외 이전 검토가 사라진다고 전제하면 안 됩니다. 템플릿 쪽 통제는 Prompt Builder 거버넌스 노트에서 따로 다룹니다.
계약서와 설정을 같은 증적으로 봅니다
검토 결과는 조항 목록만으로 부족합니다. 흐름마다 계약상 처리자와 목적, 설정이나 통합 구성의 근거, 실제 호출을 확인한 날짜, 책임자, 다음 재검토 조건을 한 묶음으로 연결합니다. 승인 대상 업무, 허용 필드, 금지 필드, 수신자, 보관 기간, 변경 승인자를 한 장에 정리하면 품의 단계에서 CIO와 개인정보 보호책임자가 각자 무엇을 승인하는지 구분됩니다.
개인정보보호위원회는 2025년 Kakao Pay와 Apple 등의 국외 이전 관련 위반을 제재하면서, 정보주체가 위탁과 국외 이전 사실을 알 수 없었던 점을 지적했습니다(PIPC 발표). 이 사건이 Salesforce 계약의 사실관계를 판단해 주지는 않습니다. 다만 “처리자는 계약서에 있으니 운영팀은 확인하지 않아도 된다”는 접근이 위험하다는 점은 분명히 보여 줍니다.
SI가 구현을 맡아도 고객사의 책임은 넘어가지 않습니다. SI는 흐름도와 설정 증적을 만들고, 고객사는 처리 목적과 승인 기준을 정하며, 법무팀과 개인정보 보호 조직은 적용 근거와 고지 요건을 판단합니다. 세 산출물이 같은 흐름 ID를 참조하지 않으면 RACI가 있어도 검토는 서로 이어지지 않습니다.
변경이 새 검토를 부르는 시점
국외 이전 검토를 프로젝트 종료 문서로 보관하면 다음 변경에서 바로 낡습니다. 변경할 때마다 전체 법률 검토를 다시 열 필요는 없습니다. 대신 운영 책임자가 어떤 변경이 필드, 수신자, 목적, 보관, 지역을 바꾸는지 판별할 수 있어야 합니다.
예를 들어 기존 통합에 이메일 주소를 추가하는 변경은 단순한 매핑 수정처럼 보입니다. 그러나 승인된 흐름이 고객번호만 보내도록 설계됐다면, 처리되는 개인정보와 고지 범위가 달라집니다. 반대로 화면 문구만 바꾸고 경로와 목적이 그대로인 배포라면 같은 수준의 검토가 필요 없을 수 있습니다. 판단 기준은 기능 크기보다 처리 사실이 바뀌었는지입니다.