Agentforce 360 Platform이 GA(General Availability)로 전환되면서 Intelligent Context 기능이 전면에 등장했다. 이 기능은 에이전트가 추론 시점에 고객 프로필, 과거 상호작용, 실시간 행동 데이터를 동적으로 참조할 수 있게 한다. 기술적으로는 강력하지만, Agentforce PIPA 컴플라이언스 관점에서 보면 이 기능은 한국 기업에 새로운 종류의 리스크를 만들어낸다. 기존의 “어떤 데이터를 저장하는가”라는 질문이 “에이전트가 추론 중에 어떤 데이터를 참조하는가”로 바뀌었기 때문이다.
Intelligent Context가 실제로 하는 일
Agentforce 360의 Intelligent Context는 Atlas Reasoning Engine(추론 엔진)이 응답을 생성하기 전에 Data Cloud의 Data Graphs와 Calculated Insights를 실시간으로 조회하는 구조다. 에이전트가 고객 문의를 처리할 때, 단순히 CRM 레코드를 참조하는 것이 아니라 Identity Resolution을 통해 통합된 Unified Individual 프로필 전체를 컨텍스트 윈도우에 주입한다.
이 구조의 아키텍처적 의미는 명확하다. 에이전트의 응답 품질이 높아지는 만큼, 추론 과정에서 처리되는 개인정보의 범위도 넓어진다. 기존 챗봇은 세션 내 입력값만 처리했다. Intelligent Context를 활성화한 Agentforce 에이전트는 고객이 현재 세션에서 제공하지 않은 정보, 즉 과거 구매 이력, 이전 상담 내용, 행동 기반 세그먼트 레이블까지 추론에 활용한다.
Data Graphs는 사전 계산된 조인(pre-computed join)을 구체화 뷰(materialized view) 형태로 제공하기 때문에, 에이전트가 조회하는 시점에 어떤 데이터가 포함되어 있는지 운영팀이 정확히 파악하지 못하는 경우가 많다. 이것이 PIPA 리스크의 핵심이다.
개인정보 보호법(PIPA)이 요구하는 것과 Intelligent Context의 충돌
개인정보 보호법(PIPA)은 개인정보 처리 목적의 명확성, 최소 수집 원칙, 처리 목적 외 이용 금지를 핵심 원칙으로 한다. Intelligent Context 아키텍처는 이 세 가지 원칙 모두와 긴장 관계를 형성한다.
첫째, 처리 목적의 명확성 문제다. 고객이 배송 문의를 위해 상담을 시작했을 때, 에이전트가 그 고객의 마케팅 세그먼트 정보나 이탈 위험 점수를 컨텍스트로 참조한다면, 이는 원래 수집 목적인 “고객 서비스 제공”의 범위를 벗어날 수 있다. PIPA 제15조와 제18조는 수집 목적 외 이용에 대해 별도 동의를 요구한다.
둘째, 최소 수집 원칙이다. Intelligent Context가 Data Graph 전체를 컨텍스트 윈도우에 주입하는 방식은, 특정 상담에 실제로 필요한 정보만 처리한다는 원칙과 충돌한다. 에이전트가 응답 생성에 실제로 사용한 데이터 필드와 컨텍스트로 주입된 데이터 필드는 다르다. 그러나 PIPA는 “사용한 것”이 아니라 “처리한 것” 기준으로 규제한다.
셋째, 처리 위탁 문제다. Agentforce의 추론이 Salesforce 인프라에서 실행된다는 것은, 한국 기업 입장에서 개인정보 처리 위탁 계약(위탁 처리 계약)을 Salesforce와 체결해야 함을 의미한다. 이는 이미 많은 기업이 처리하고 있지만, Intelligent Context가 Data Cloud의 어떤 DMO(Data Model Object)를 어떤 조건에서 참조하는지를 위탁 계약서에 명시하는 수준까지 요구된다. 현재 대부분의 위탁 계약은 이 수준의 세분화를 포함하지 않는다.
관련 아키텍처 설계 원칙은 Agentforce 에이전트 설계와 거버넌스 가드레일에서 더 자세히 다루고 있다.
한국 기업이 실제로 직면하는 아키텍처 판단
문제를 인식하는 것과 해결하는 것은 다르다. Intelligent Context를 비활성화하면 Agentforce 360의 핵심 가치를 포기하는 것이고, 그대로 활성화하면 PIPA 리스크를 안고 가는 것이다. 이 이분법은 잘못된 프레임이다.
실제로 작동하는 아키텍처는 컨텍스트 범위를 에이전트 Topics 단위로 제어하는 방식이다. Agentforce의 Topics는 에이전트가 처리할 수 있는 업무 범위를 정의하고, 각 Topic에 연결된 Actions는 어떤 데이터 소스를 조회할 수 있는지를 결정한다. 이 구조를 활용하면 “고객 서비스 에이전트”와 “마케팅 개인화 에이전트”를 분리하고, 각각이 참조할 수 있는 Data Graph의 범위를 다르게 설정할 수 있다.
구체적으로는 다음 세 가지 제어 레이어가 필요하다.
- Data Graph 범위 제한: 고객 서비스 목적의 에이전트에는 거래 이력, 현재 주문 상태, 서비스 이력만 포함된 별도의 Data Graph를 구성한다. 마케팅 세그먼트, 행동 기반 점수, 이탈 예측 지표는 이 Graph에서 제외한다.
- Prompt Builder 템플릿 감사: Flex 템플릿을 사용할 경우, 템플릿이 참조하는 Merge Field가 어떤 DMO에서 오는지를 문서화하고, 이를 개인정보 처리 방침의 처리 항목 목록과 대조한다.
- Agent Script 가드레일: Agent Script의 Instructions 레이어에서 특정 데이터 카테고리(예: 민감 정보, 금융 정보)를 에이전트가 응답에 포함하지 못하도록 명시적으로 제한한다.
이 세 레이어를 조합하면 Intelligent Context의 기능적 이점을 유지하면서 PIPA가 요구하는 목적 제한 원칙을 구조적으로 구현할 수 있다.
SI 의존도가 높은 한국 기업 환경에서는 이 설계 결정이 프로젝트 초기에 이루어지지 않으면 나중에 수정하기 어렵다. SI 파트너가 Data Graph를 단일 통합 뷰로 구성하고 모든 에이전트가 이를 공유하는 방식으로 구현하면, 나중에 에이전트별 컨텍스트 범위를 분리하는 작업은 Data Cloud 데이터 모델 전체를 재설계하는 수준의 작업이 된다.
Agentforce PIPA 컴플라이언스 설계에서 대부분이 놓치는 지점
Agentforce PIPA 컴플라이언스를 논의할 때 가장 많이 놓치는 지점은 로그와 감사 추적이다.
PIPA는 개인정보 처리 내역의 기록 보관을 요구한다. Agentforce의 Atlas Reasoning Engine이 어떤 컨텍스트 데이터를 참조해서 어떤 응답을 생성했는지는 기본 설정으로는 충분히 기록되지 않는다. Agentforce Testing Center는 에이전트 동작 검증을 위한 도구이지, 운영 환경의 감사 로그를 생성하는 도구가 아니다.
실제로 필요한 것은 Platform Events를 활용한 에이전트 추론 이벤트 로깅이다. 에이전트가 특정 고객 레코드를 컨텍스트로 참조할 때마다 Platform Event를 발행하고, 이를 별도의 감사 로그 저장소에 기록하는 구조가 필요하다. 이 구조가 없으면 개인정보 침해 사고 발생 시 “어떤 에이전트가 어떤 데이터를 처리했는가”를 소명하기 어렵다.
두 번째로 놓치는 지점은 정보주체 권리 대응이다. PIPA는 정보주체가 자신의 개인정보 처리 내역 열람을 요청할 권리를 보장한다. Intelligent Context를 통해 에이전트 추론에 사용된 데이터가 이 열람 요청의 대상이 되는지, 그리고 그 데이터를 어떻게 추출해서 제공할 것인지에 대한 프로세스가 없는 경우가 대부분이다.
Data Cloud의 Unified Individual 프로필은 Identity Resolution을 통해 여러 소스의 데이터를 통합한 결과물이다. 이 프로필에서 특정 정보주체의 데이터만 추출하고, 어떤 소스에서 어떻게 통합되었는지를 설명하는 것은 기술적으로 복잡한 작업이다. 이 프로세스를 사전에 설계하지 않으면, 열람 요청이 들어왔을 때 대응 자체가 불가능해진다.
Agentforce 아키텍처 전반의 거버넌스 설계 접근법은 /ko/services/agentforce-architecture에서 확인할 수 있다.
핵심 정리
- Agentforce 360의 Intelligent Context는 에이전트 추론 시점에 Data Cloud의 Unified Individual 프로필 전체를 참조할 수 있어, PIPA의 처리 목적 제한 원칙과 구조적 긴장을 형성한다.
- 컨텍스트 범위 제어는 에이전트 Topics 단위로 설계해야 하며, 고객 서비스 목적과 마케팅 목적의 Data Graph를 분리하는 것이 PIPA 대응의 출발점이다.
- Prompt Builder Flex 템플릿이 참조하는 DMO 필드 목록을 개인정보 처리 방침의 처리 항목과 대조하는 작업은 GA 전환 전에 완료해야 한다.
- Platform Events 기반의 에이전트 추론 이벤트 로깅 없이는 PIPA가 요구하는 처리 내역 기록 보관 의무를 충족하기 어렵다.
- SI 파트너가 단일 통합 Data Graph를 구성하는 방식으로 구현하면 나중에 에이전트별 컨텍스트 분리가 데이터 모델 재설계 수준의 작업이 된다. 이 결정은 프로젝트 초기에 이루어져야 한다.
