Agentforce 360 Platform이 GA(General Availability)로 전환되면서 AI 에이전트 거버넌스를 둘러싼 논의가 추상적 수준을 벗어났다. 한국 기업 CIO·CTO 입장에서 이 릴리스가 중요한 이유는 기능 목록이 늘어서가 아니라, Agentforce 거버넌스와 AI 에이전트 컴플라이언스, 엔터프라이즈 제어를 위한 아키텍처 레이어가 플랫폼 수준에서 처음으로 통합됐기 때문이다.
Agentforce 360이 바꾼 것: 기능이 아니라 제어 구조
Agentforce 360의 핵심 변화는 네 가지 구성 요소에 있다. Agentforce Builder의 재설계, Agent Script 가드레일, Agentforce Voice, 그리고 Intelligent Context다.
이 중 거버넌스 관점에서 가장 중요한 것은 Agent Script 가드레일이다. 기존 Agentforce 아키텍처에서 Topics(범위)와 Actions(도구), Instructions(행동)는 개발자가 정의하되 런타임 제어는 Atlas Reasoning Engine에 위임됐다. 에이전트가 어떤 경로로 추론했는지 사후 감사가 어려웠고, 특정 발화나 행동을 사전에 차단하는 메커니즘이 플랫폼 레이어에 없었다.
Agent Script 가드레일은 이 구조를 바꾼다. 에이전트가 특정 Topics 범위를 벗어나려 할 때 Instructions 레이어에서 차단하는 것이 아니라, 스크립트 수준에서 허용 경로를 명시적으로 정의한다. 결과적으로 에이전트의 행동 범위가 코드가 아니라 선언적 정책으로 관리된다. 이는 한국 기업 환경에서 품의 기반 승인 프로세스와 직접 연결된다. 에이전트가 무엇을 할 수 있고 무엇을 할 수 없는지를 비기술 담당자도 검토할 수 있는 형태로 문서화할 수 있게 됐다.
Intelligent Context는 또 다른 축이다. 에이전트가 대화 맥락을 유지하는 방식이 Data Cloud의 Data Graphs와 통합되면서, 어떤 데이터가 어떤 추론에 사용됐는지 추적 가능성이 높아졌다. 개인정보 보호법(PIPA) 관점에서 이것은 단순한 편의 기능이 아니다. 에이전트가 고객 데이터를 활용해 응답을 생성할 때 어떤 정보가 처리됐는지 기록하는 것은 PIPA 제15조 처리 목적 명확화 및 제22조 동의 관리와 직결된다.
한국 기업의 AI 에이전트 컴플라이언스 공백
한국 대기업과 금융권에서 Agentforce 도입을 검토할 때 반복적으로 등장하는 장벽이 있다. 에이전트가 어떤 근거로 어떤 행동을 했는지 감사 로그를 어떻게 남기느냐는 질문이다.
이 질문이 어려운 이유는 기술적 문제가 아니다. Atlas Reasoning Engine의 추론 과정은 본질적으로 확률적이고, 동일한 입력에 대해 동일한 경로를 보장하지 않는다. 기존 SI 기반 시스템에서 감사 담당자가 기대하는 결정론적 로그와 근본적으로 다르다.
Agentforce 360이 이 공백을 완전히 해소하지는 않는다. 그러나 Agent Script 가드레일과 Agentforce Testing Center의 조합은 실용적인 접근을 가능하게 한다. 에이전트가 실제로 취할 수 있는 Actions의 범위를 사전에 제한하고, 그 제한이 선언적 정책으로 버전 관리되면, 감사 로그의 완전성보다 정책 준수 여부를 검증하는 방향으로 컴플라이언스 프레임워크를 재설계할 수 있다.
금융감독원 IT 내부통제 가이드라인이나 ISMS 인증 요건에서 AI 시스템에 대한 구체적 기준이 아직 성숙하지 않은 상황에서, 이 접근은 현실적이다. “에이전트가 무엇을 했는가”를 완전히 기록하는 것보다 “에이전트가 무엇을 할 수 없도록 설계됐는가”를 증명하는 것이 현재 규제 환경에서 더 방어 가능한 포지션이다.
Agentforce 프로덕션 준비도 평가 기준에서 다룬 것처럼, 에이전트를 프로덕션에 올리기 전 거버넌스 체계를 설계하는 것이 사후 패치보다 비용이 훨씬 낮다.
SI 의존 구조에서 거버넌스 소유권 문제
한국 기업 Salesforce 환경의 구조적 특성 중 하나는 플랫폼 설정과 커스터마이징의 상당 부분이 SI 파트너에 위임돼 있다는 점이다. 이 구조에서 Agentforce 거버넌스 소유권은 어디에 있어야 하는가.
Agentforce 360의 Agentforce Builder 재설계는 이 질문을 더 날카롭게 만든다. Builder가 로우코드 인터페이스를 강화하면서 비기술 담당자도 Topics와 Instructions를 수정할 수 있게 됐다. 이것은 접근성 향상이지만, 동시에 거버넌스 리스크다. SI가 초기 설계한 에이전트 행동 범위를 내부 담당자가 의도치 않게 변경할 수 있는 경로가 생긴다.
엔터프라이즈 제어 관점에서 필요한 것은 변경 관리 레이어다. 구체적으로는 세 가지다.
- 변경 승인 프로세스: Topics, Actions, Instructions, Agent Script 가드레일의 변경이 Salesforce DevOps Center 또는 외부 CI/CD 파이프라인을 통해 승인 후 배포되도록 강제하는 구조
- 역할 분리: Builder 접근 권한을 에이전트 설계자(SI 또는 내부 아키텍트)와 정책 검토자(컴플라이언스, 법무)로 분리하는 권한 모델
- 정책 버전 관리: Agent Script 가드레일을 소스 코드처럼 버전 관리하고, 각 버전이 어떤 비즈니스 요건에 근거했는지 추적하는 문서 체계
이 세 가지가 없으면 Agentforce 360의 거버넌스 기능은 플랫폼 레이어에만 존재하고 조직 레이어에는 착지하지 못한다. 기능이 있다고 거버넌스가 되는 것이 아니다.
PIPA와 Agentforce Voice: 음성 채널의 데이터 처리 문제
Agentforce Voice는 이번 릴리스에서 가장 주목받는 기능 중 하나지만, 한국 기업 환경에서는 가장 신중하게 접근해야 하는 영역이기도 하다.
음성 채널에서 에이전트가 고객과 상호작용할 때 발생하는 데이터는 텍스트 채널과 다른 PIPA 처리 요건을 가진다. 음성 녹취는 개인정보 보호법상 민감 정보 처리에 준하는 동의 요건이 적용될 수 있으며, 음성 데이터가 Data Cloud Data Streams를 통해 수집되고 Identity Resolution을 거쳐 Unified Individual 프로필에 연결될 경우 데이터 처리 목적과 보존 기간에 대한 명시적 정책이 필요하다.
실무적으로 Agentforce Voice를 PIPA 준수 방식으로 운영하려면 최소 세 가지를 설계 단계에서 결정해야 한다. 첫째, 음성 데이터의 Data Cloud 내 보존 기간과 삭제 정책. 둘째, 음성 상호작용에서 수집된 데이터가 마케팅 활성화 Segments에 사용되는지 여부와 그에 따른 동의 범위. 셋째, 음성 데이터의 국외 이전 여부와 표준 계약 조항(SCC) 또는 동등한 보호 수준 확보 방안.
이 결정들은 아키텍처 결정이기도 하다. Agentforce Voice를 Data Cloud와 얼마나 깊게 통합할지는 기능 요건이 아니라 컴플라이언스 요건이 먼저 결정해야 한다.
거버넌스 체계 설계의 실질적 출발점
Agentforce 360 GA를 계기로 AI 에이전트 거버넌스 체계를 구축하려는 조직이라면, 플랫폼 기능 탐색보다 먼저 해야 할 것이 있다.
에이전트가 접근할 수 있는 데이터와 수행할 수 있는 Actions의 범위를 비즈니스 프로세스 단위로 명세화하는 작업이다. 이것이 Agent Script 가드레일 설계의 입력이 되고, Prompt Builder의 Field Generation 템플릿 범위를 결정하며, Data Cloud Segments와 Calculated Insights 중 어떤 것을 에이전트에 노출할지를 결정한다.
이 명세가 없으면 Agentforce Builder에서 무엇을 설정해야 할지 알 수 없다. 플랫폼이 아무리 강력한 거버넌스 도구를 제공해도, 조직이 “에이전트가 무엇을 해야 하는가”에 대한 합의 없이 구현을 시작하면 결국 사후 제한 작업이 반복된다.
Agentforce와 PIPA 데이터 보안 설계에서 다룬 데이터 접근 범위 설계 원칙이 이 명세 작업의 기반이 된다.
엔터프라이즈 제어 체계를 플랫폼 수준에서 구현하려는 조직은 Agentforce 아키텍처 서비스에서 설계 접근 방식을 확인할 수 있다.
핵심 정리
- Agent Script 가드레일은 감사 로그 완전성 문제를 우회하는 실용적 접근이다. 에이전트가 무엇을 할 수 없는지를 선언적 정책으로 증명하는 것이 현재 한국 규제 환경에서 더 방어 가능하다.
- Agentforce Builder의 로우코드 강화는 거버넌스 리스크를 동반한다. SI 위임 구조에서 내부 담당자의 무통제 변경을 막으려면 DevOps 파이프라인 기반 변경 관리가 필수다.
- Agentforce Voice는 PIPA 처리 요건을 아키텍처 설계 단계에서 결정해야 한다. 음성 데이터의 Data Cloud 통합 깊이는 기능 요건이 아니라 컴플라이언스 요건이 먼저 결정한다.
- Intelligent Context와 Data Graphs의 통합은 추적 가능성을 높이지만, 동시에 처리 목적 명확화 의무를 강화한다. 어떤 데이터가 추론에 사용됐는지 기록 가능해진다는 것은 그 기록에 대한 책임도 생긴다는 의미다.
- 거버넌스 체계의 실질적 출발점은 플랫폼 설정이 아니라 에이전트 행동 범위 명세다. 비즈니스 프로세스 단위의 명세 없이 Agentforce 360의 거버넌스 기능을 구현하면 사후 제한 작업이 반복된다.
