Salesforce가 Agentforce Coworker를 발표하면서 강조한 것은 하나의 에이전트가 Salesforce, Slack, Microsoft Teams, ChatGPT, Claude를 넘나들며 동일한 컨텍스트를 유지한다는 점입니다. 미국 시장에서는 이를 “헤드리스 AI 팀원”이라는 아키텍처 혁신으로 다룹니다. 그런데 한국 CIO·CTO 입장에서 먼저 질문해야 할 것은 다르습니다. 개인정보가 조직 경계를 넘어 여러 외부 서비스로 이동할 때, 그 경로가 PIPA(개인정보 보호법) 위반 지점을 만드는가입니다. Agentforce PIPA 컴플라이언스는 이제 기능 검토가 아니라 품의 문서의 필수 항목이 되었습니다.
Agentforce Coworker가 데이터 주권 문제를 만드는 이유
Agentforce Coworker의 핵심 설계는 단일 에이전트 인스턴스가 여러 채널의 요청을 받아 Atlas Reasoning Engine에서 추론하고, 각 채널에 맞는 응답을 반환하는 구조입니다. 문제는 이 과정에서 개인정보가 어디까지 이동하는지가 채널마다 다르다는 데 있습니다.
Slack이나 Microsoft Teams 연동은 대부분 조직 내부 워크스페이스에서 종료됩니다. 반면 ChatGPT나 Claude를 통한 인터페이스는 구조적으로 외부 LLM 벤더의 API 엔드포인트를 거칩니다. 에이전트가 고객 문의를 처리하며 이름, 연락처, 거래 이력 같은 개인정보를 프롬프트 컨텍스트에 포함시키는 순간, 그 데이터는 Salesforce 조직 밖으로, 그리고 상당수의 경우 한국 밖으로 나갑니다.
PIPA는 개인정보의 국외 이전(제28조의8)과 위탁 처리(제26조)를 명확히 구분해서 규제합니다. 국외 이전은 정보주체의 별도 동의 또는 법정 예외 요건이 필요하고, 위탁 처리는 수탁자 관리·감독 의무와 계약서 명시 사항이 따릅니다. Agentforce Coworker처럼 하나의 에이전트가 여러 외부 채널로 컨텍스트를 뿌리는 구조에서는, 채널별로 이 두 가지 규제 프레임 중 어느 쪽이 적용되는지를 사전에 매핑해두지 않으면 감사 시점에 설명할 수 없는 데이터 흐름이 생깁니다.
더 근본적인 문제는 이것이 기능 하나를 껐다 켰다 하는 수준의 이슈가 아니라는 점입니다. 에이전트의 Topics 범위 설정, Actions 권한 부여 방식, Instructions에 담긴 행동 지침이 전부 데이터 이동 경로를 결정합니다. 즉 Agentforce PIPA 컴플라이언스는 배포 이후 점검 항목이 아니라 설계 단계의 아키텍처 결정입니다.
채널별 데이터 이동 경로를 어떻게 통제하는가
실무에서 작동하는 접근은 채널을 신뢰 등급으로 나누고, 각 등급에 맞는 Data Streams와 Action 권한을 별도로 설계하는 것입니다.
신뢰 등급 분리. Salesforce 조직 내부, Slack/Teams 같은 사내 협업 채널, ChatGPT/Claude 같은 외부 인터페이스 세 계층으로 나눕니다. 각 계층에 노출되는 DMO(Data Model Object) 필드 자체를 다르게 구성합니다. Identity Resolution ruleset으로 통합된 Unified Individual 프로필에서, 외부 채널로 나가는 Action은 마스킹되거나 최소화된 필드셋만 참조하도록 제한합니다.
Prompt Builder 템플릿 통제. Flex 템플릿을 채널별로 분리 설계하는 것이 핵심입니다. 내부 Slack 채널용 템플릿은 전체 고객 컨텍스트를 참조할 수 있어도, ChatGPT 연동용 템플릿은 PII를 제거한 요약 데이터만 프롬프트에 삽입하도록 구성합니다. 이 분리를 하지 않으면 동일한 프롬프트 로직이 모든 채널에 재사용되면서, 가장 취약한 채널의 노출 수준이 전체 시스템의 실제 노출 수준이 되어버립니다.
Actions 권한의 최소화. 에이전트가 실행할 수 있는 Action은 채널마다 다른 스코프를 가져야 합니다. 예를 들어 Salesforce 내부에서는 고객 레코드 업데이트 Action이 허용되어도, 외부 LLM 채널에서 트리거된 요청은 조회 전용 Action으로 제한하는 식입니다. Action 정의 시점에 “이 Action이 어느 채널에서 호출되었는가”를 조건으로 넣는 설계가 실질적인 통제 지점이 됩니다.
MuleSoft를 통한 승인된 게이트웨이. 외부 LLM 벤더와의 연동을 Salesforce 네이티브 커넥터에만 의존하지 않고 MuleSoft 계층을 경유하도록 구성하면, 데이터 이동 로그를 중앙에서 수집하고 국외 이전 여부를 실시간으로 태깅할 수 있습니다. 이는 개인정보 국외 이전 기록 의무를 충족하는 데 필요한 감사 추적을 만드는 가장 실용적인 방법입니다.
Agentforce Testing Center 활용. 배포 전 테스트 시나리오에 “PII가 외부 채널 응답에 노출되는가”를 명시적 검증 항목으로 포함해야 합니다. 대부분의 조직이 Testing Center를 응답 정확도 검증에만 사용하는데, 정확도와 데이터 노출은 별개의 검증축입니다.
이 다섯 가지 통제 지점을 데이터 흐름도로 그려보면 다음과 같은 구조가 됩니다.
[Salesforce Org / Data Cloud]
│
Identity Resolution → Unified Individual
│
┌────┴────┬─────────────┐
│ │ │
Slack/Teams ChatGPT/Claude 내부 Agentforce UI
(신뢰 등급 A) (신뢰 등급 C) (신뢰 등급 A)
│ │ │
전체 필드셋 마스킹 필드셋 전체 필드셋
│ │ │
조회+쓰기 조회 전용 조회+쓰기
Action Action Action이 구조를 품의 문서에 포함시키면, 법무팀과 정보보호팀이 국외 이전 항목과 위탁 처리 항목을 채널별로 명확히 구분해 검토할 수 있습니다. Identity Resolution 설계와 PIPA 대응 사이의 연결 고리는 별도로 다룬 Identity Resolution이 중복을 처리하는 방식에서 더 구체적으로 다뤘습니다.
대부분의 조직이 놓치는 실행 함정
이론적으로는 채널 분리가 당연해 보이지만, 실제 프로젝트에서는 몇 가지 지점에서 무너집니다.
첫째, SI가 표준 배포 템플릿을 그대로 이식하는 경우입니다. 글로벌 표준 구성에는 채널별 신뢰 등급이라는 개념 자체가 없는 경우가 많습니다. SI 파트너가 “이미 검증된 구성”이라며 그대로 배포하면, ChatGPT 채널과 내부 Slack 채널이 동일한 Prompt Builder 템플릿과 동일한 Action 권한을 공유하게 됩니다. 이 상태에서는 감사 시점에 데이터 흐름을 설명할 방법이 없습니다.
둘째, Action 권한을 배포 초기에 넓게 설정한 뒤 좁히지 않는 경우입니다. 개발 단계에서는 테스트 편의를 위해 모든 채널에 동일한 권한을 부여하고, 운영 전환 시점에 채널별로 재조정해야 하는데 이 단계가 누락되는 사례가 흔합니다. 운영 전환 체크리스트에 “채널별 Action 권한 재검토”가 명시적 항목으로 없으면 이 작업은 거의 항상 생략됩니다.
셋째, 로그 보존과 국외 이전 기록의 불일치입니다. Platform Events나 Data Streams 로그는 기술적으로 존재하지만, 이 로그가 “어느 개인정보가 언제 어느 국가의 어느 벤더로 이전되었는가”라는 PIPA 요건에 맞는 형태로 정리되어 있지 않은 경우가 많습니다. 로그가 있다는 것과 규제 대응이 가능한 형태로 로그가 구조화되어 있다는 것은 다른 문제입니다.
넷째, ISMS 인증 범위와 Agentforce 배포 범위의 불일치입니다. 기존 ISMS 인증 심사 시점에는 존재하지 않았던 외부 LLM 연동 채널이 새로 추가되는 것이므로, 인증 갱신 시점에 이 채널이 심사 범위에 포함되는지를 별도로 확인해야 합니다. 이를 놓치면 인증은 유지되지만 실제 운영 범위와 인증 범위가 어긋나는 상태가 됩니다.
이런 함정들의 공통점은 하나입니다. 기술 구성 자체는 문제가 없어 보이는데, 그 구성이 규제 요건과 매핑되어 있지 않다는 점입니다. Agentforce PIPA 컴플라이언스 검토는 기능 테스트가 아니라 데이터 흐름과 법적 요건의 대조 작업이어야 합니다. Agentforce 도입 초기 단계에서 governance 구조를 어떻게 설계해야 하는지는 PIPA 시대의 Agentforce 데이터 보안 설계에서 더 자세히 다뤘습니다.
앞으로의 방향
Agentforce Coworker 같은 멀티채널 확장은 앞으로 더 빠르게 늘어날 것입니다. Salesforce 로드맵 자체가 헤드리스 배포와 외부 LLM 연동을 표준 옵션으로 만드는 방향으로 가고 있기 때문입니다. 이 흐름에서 한국 기업이 취해야 할 태도는 신규 채널을 막는 것이 아니라, 채널이 추가될 때마다 신뢰 등급 재평가와 Action 권한 재검토가 자동으로 트리거되는 governance 프로세스를 만드는 것입니다.
지금 채널 세 개를 수동으로 검토하는 것은 가능하지만, 내년에 다섯 개, 그다음 해에 여덟 개가 되면 수동 검토는 무너집니다. Data 360의 Data Graphs와 Calculated Insights를 활용해 채널별 노출 필드와 Action 권한을 코드로 관리하고, 변경 시점마다 자동 검증하는 구조를 지금 만들어두는 조직과, 그때그때 수동으로 대응하는 조직의 격차는 채널 수가 늘어날수록 벌어집니다.
기업의 Agentforce 거버넌스 검토가 필요하다면 Salesforce 딜리버리 서비스를 통해 채널별 데이터 흐름 진단부터 시작하는 것이 순서입니다.
핵심 정리
- Agentforce Coworker는 Salesforce, Slack, Teams, ChatGPT, Claude를 넘나드는 헤드리스 구조이며, 채널마다 개인정보 이동 경로와 적용되는 PIPA 규제 프레임(국외 이전 vs 위탁 처리)이 다릅니다.
- Agentforce PIPA 컴플라이언스는 배포 후 점검 항목이 아니라 Topics, Actions, Instructions 설계 단계에서 결정되는 아키텍처 문제입니다.
- 실무 통제는 채널 신뢰 등급 분리, 채널별 Prompt Builder 템플릿 분리, Action 권한 최소화, MuleSoft 게이트웨이를 통한 이전 로그 수집, Agentforce Testing Center의 PII 노출 검증 다섯 가지로 구성됩니다.
- 가장 흔한 실패는 SI의 표준 템플릿 그대로 이식, 운영 전환 시 Action 권한 재조정 누락, 로그는 있으나 PIPA 요건에 맞게 구조화되지 않은 상태, ISMS 인증 범위와 실제 배포 범위의 불일치입니다.
- 채널 수가 늘어날수록 수동 검토는 한계에 부딪히므로, Data Graphs와 Calculated Insights 기반의 자동 governance 트리거를 지금 설계해두는 것이 다음 단계입니다.
