Agentforce(에이전트포스) 도입을 준비하는 팀이 권한 설계를 가장 늦게 미룹니다. 데모를 먼저 만들고, 답 품질을 다듬고, 보안은 마지막에 검토하는 순서입니다. 그러나 Agentforce 데이터 보안은 마지막에 붙이는 통제가 아니라 처음부터 그려야 하는 설계입니다. 에이전트는 사람과 다른 방식으로 데이터에 닿기 때문입니다. 같은 역할을 맡은 상담원이 화면에서 보지 못했을 필드를, 에이전트는 자연어 요약 한 문장 안에 흘릴 수 있습니다. 이 글은 에이전트를 새로운 행위자로 보고, 권한 모델과 데이터 마스킹과 개인정보 보호법(PIPA) 통제를 어떻게 다시 설계해야 하는지 정리합니다.
문제의 출발점은 단순합니다. 사람의 권한은 화면과 보고서 단위로 정해집니다. 상담원은 특정 화면에서 특정 필드만 봅니다. 에이전트는 화면이 아니라 데이터에 직접 질의하고, 그 결과를 자연어로 다시 구성합니다. 그래서 권한 경계가 한 칸이라도 헐거우면, 에이전트는 사람이라면 닿지 않았을 데이터를 답에 섞어 냅니다. 이것은 모델 품질의 문제가 아니라 접근 통제의 문제입니다.
에이전트는 새로운 행위자입니다
조직의 권한 모델은 대부분 사람을 기준으로 만들어졌습니다. 프로파일, 역할 계층, 공유 규칙, 필드 수준 보안. 이 모든 통제는 화면을 보는 사용자를 전제합니다. 에이전트가 등장하면 전제가 깨집니다. 에이전트는 어떤 사용자 맥락에서 실행되는지, 그 맥락이 어떤 데이터까지 읽고 쓸 수 있는지가 새로 정의돼야 합니다.
핵심은 에이전트가 실행되는 사용자 컨텍스트입니다. 에이전트는 자신만의 권한을 갖지 않고, 정해진 사용자 또는 게스트 맥락의 권한을 빌려서 동작합니다. 그 맥락에 넓은 권한이 붙어 있으면, 에이전트도 그만큼 넓게 봅니다. 흔한 실수는 구축 편의를 위해 시스템 관리자에 가까운 강한 권한으로 에이전트를 띄우고, 그 설정을 프로덕션까지 끌고 가는 것입니다. 그 순간 에이전트는 조직의 거의 모든 데이터에 닿는 단일 창구가 됩니다.
그래서 권한 경계는 사람 기준이 아니라 에이전트 실행 맥락 기준으로 다시 그어야 합니다. 먼저 에이전트가 답해야 하는 질문의 목록을 만들고, 각 질문에 필요한 최소 데이터를 정의합니다. 그 최소 집합만 허용하는 전용 권한 세트를 만들고, 에이전트의 실행 맥락에 그 권한만 부여합니다. 최소 권한 원칙을 사람이 아니라 에이전트에 적용하는 것입니다. 이렇게 하면 에이전트가 무엇을 볼 수 있는지가 설정 한 곳에 모이고, 보안팀이 검토할 단일 지점이 생깁니다.
Einstein Trust Layer와 데이터 마스킹
Salesforce는 에이전트가 데이터를 다룰 때 거치는 보안 계층으로 Einstein Trust Layer(아인슈타인 트러스트 레이어)를 제공합니다. 이 계층은 민감 데이터를 LLM에 보내기 전에 마스킹하고, 응답을 다시 받을 때 복원하며, 입력과 출력을 감사 로그로 남깁니다. 또한 외부 모델 제공자가 입력 데이터를 학습에 쓰지 않도록 데이터 보존을 차단합니다. 한국 엔터프라이즈의 보안팀이 가장 먼저 확인하는 지점이 바로 이 데이터 보존과 마스킹 동작입니다.
다만 Einstein Trust Layer는 도구이지 설계가 아닙니다. 무엇이 민감 데이터인지, 어떤 필드를 마스킹할지, 어디까지 노출을 허용할지 선언하는 일은 설계자의 몫입니다. 주민등록번호나 카드 번호 같은 식별 정보는 기본 패턴으로 잡히지만, 조직마다 다른 민감 필드, 예컨대 신용 등급, 의료 이력, 계약 단가 같은 항목은 직접 분류해 마스킹 대상으로 등록해야 합니다. 이 분류를 건너뛰면, 마스킹 기능이 켜져 있어도 정작 보호해야 할 데이터가 그대로 모델에 전달됩니다.
그다음은 grounding(그라운딩) 정책입니다. grounding은 에이전트가 답을 만들 때 참조하는 데이터의 범위를 정합니다. 어떤 객체, 어떤 레코드, 어떤 필드를 답의 근거로 삼을지를 지정하는 작업입니다. grounding 범위를 넓게 열어 두면 답의 정확도는 올라가지만, 그만큼 민감 데이터가 답에 섞일 위험도 커집니다. 정확도와 노출 위험은 같은 손잡이에 달려 있습니다. 그래서 grounding 범위는 질문 유형별로 따로 정하고, 답에 꼭 필요한 데이터만 근거로 묶는 편이 안전합니다.
마지막은 프롬프트 가드레일입니다. 에이전트가 권한 밖 정보를 요청받았을 때 어떻게 거절할지, 어떤 조건에서 사람에게 넘길지를 지시에 명시합니다. 가드레일이 비어 있으면, 사용자가 교묘하게 질문을 바꿔 권한 경계를 우회하려는 시도에 에이전트가 그대로 응합니다. 다만 프롬프트만으로 통제를 세우면 우회 여지가 남으므로, 데이터 접근 자체를 권한 세트로 막은 위에 프롬프트 가드레일을 더하는 이중 구조가 안전합니다.
PIPA 통제를 에이전트에 맞게 다시 봅니다
기술적 통제가 자리를 잡아도, 한국 엔터프라이즈에는 개인정보 보호법(PIPA)이라는 별도의 관문이 있습니다. 에이전트가 고객의 개인정보를 다루는 순간, 그 처리는 PIPA의 적용 대상이 됩니다. 보안팀이 검토하는 항목은 네 가지로 정리됩니다.
첫째는 수집 근거입니다. 에이전트가 참조하는 개인정보가 애초에 어떤 동의나 법적 근거로 수집됐는지, 그리고 AI 에이전트가 그 데이터를 처리하는 일이 원래 수집 목적의 범위 안에 있는지 확인합니다. 상담 응대용으로 받은 데이터를 에이전트가 마케팅 판단에 쓴다면, 목적 외 이용에 해당해 별도 근거가 필요합니다.
둘째는 위탁 처리입니다. Salesforce와 그 하부의 모델 제공자가 데이터를 처리하는 한, 이들은 수탁자가 됩니다. 위탁 처리 계약과 수탁자 관리 의무가 정리돼 있어야 하고, 데이터가 거치는 경로가 문서로 남아 있어야 합니다.
셋째는 국외 이전 동의입니다. Einstein Trust Layer가 데이터 보존을 막더라도, 처리 과정에서 데이터가 국외 인프라를 거친다면 국외 이전에 해당할 수 있습니다. 어떤 데이터가 어느 리전에서 처리되는지를 확인하고, 필요한 동의나 고지가 갖춰졌는지 점검합니다.
넷째는 보관기간입니다. 에이전트의 대화 로그와 감사 기록에도 개인정보가 담깁니다. 이 로그를 얼마나 보관하고 언제 파기할지가 PIPA의 보관기간 원칙에 맞아야 합니다. 감사를 위해 로그를 남기는 일과 보관기간을 지키는 일은 함께 설계해야 합니다.
이 네 가지를 프로덕션 직전에 점검하면, 동의를 다시 받거나 위탁 계약을 다시 맺어야 하는 상황이 생깁니다. 그 작업은 몇 주가 아니라 몇 달이 걸립니다. PIPA 검토를 파일럿 설계 단계로 끌어와, 데이터 처리 경로를 보안팀과 먼저 합의해 두는 편이 결국 빠릅니다. 이 합의 과정은 Agentforce 파일럿이 프로덕션에서 멈추는 이유에서 다룬 프로덕션 준비도 진단과 같은 시점에 시작하는 것이 자연스럽습니다.
ISMS 맥락에서 본 에이전트 거버넌스
많은 한국 기업이 ISMS 또는 ISMS-P 인증 체계 안에서 정보보호를 운영합니다. 에이전트는 이 체계 안에서 새로운 자산이자 새로운 접근 주체로 등록돼야 합니다. 기존 인증 범위가 사람과 시스템을 전제로 그려졌다면, 에이전트라는 행위자가 더해지면서 접근 통제와 로그 관리, 위탁 관리 항목을 다시 점검할 필요가 생깁니다.
실무에서 중요한 것은 에이전트의 모든 데이터 접근과 행동이 추적 가능해야 한다는 점입니다. 누가, 정확히는 어떤 에이전트가, 언제, 어떤 데이터에 닿았고, 어떤 행동을 했는지가 감사 로그에 남아야 합니다. Einstein Trust Layer의 감사 로그가 이 기록의 토대가 되지만, 그 로그를 조직의 SIEM이나 로그 관리 체계에 연결해 두지 않으면 인증 심사에서 증빙이 끊깁니다. 에이전트가 행동하는 권한을 가진 경우라면, 그 행동의 범위와 한도, 사람에게 넘기는 조건까지 운영 문서에 명시해 두어야 합니다.
거버넌스의 무게 중심은 결국 운영 주체에 있습니다. 파일럿을 외부 SI가 구축하더라도, 에이전트의 권한 변경과 가드레일 조정, 로그 검토를 내부 보안팀이 이어받을 수 있어야 합니다. 구축은 외부가 맡더라도 통제 권한은 내부가 쥐고 있어야, 인증 체계 안에서 책임 소재가 분명해집니다. 이 운영 모델을 누가 어떻게 설계할지는 Agentforce 아키텍처 진단에 정리해 두었습니다.
핵심 정리
Agentforce 데이터 보안은 모델 위에 덧붙이는 기능이 아니라, 에이전트를 새로운 행위자로 보고 처음부터 그리는 설계입니다. 정리하면 다음과 같습니다.
- 에이전트는 실행 맥락의 권한으로 동작합니다. 답에 필요한 최소 데이터만 허용하는 전용 권한 세트를 만들고, 강한 권한으로 띄우지 않습니다.
- Einstein Trust Layer의 마스킹과 grounding은 도구입니다. 무엇이 민감 데이터인지 분류하고 노출 범위를 선언하는 일은 설계자의 몫입니다.
- PIPA는 수집 근거, 위탁 처리, 국외 이전 동의, 보관기간 네 가지로 점검합니다. 프로덕션 직전이 아니라 파일럿 설계 단계에서 보안팀과 합의합니다.
- ISMS 맥락에서 에이전트는 새로운 접근 주체입니다. 모든 데이터 접근과 행동을 추적 가능하게 만들고, 통제 권한을 내부가 쥐고 있어야 합니다.
지금의 권한 설계가 18개월 뒤의 사고 위험을 결정합니다. 에이전트를 행위자로 보고 최소 권한과 마스킹과 PIPA 통제를 초기에 정리한 조직은, 새 사용 사례를 더할 때마다 같은 보안 기반을 재사용합니다. 반대로 통제를 나중에 붙이려는 조직은 사용 사례가 늘 때마다 같은 검토를 다시 받습니다. 데모를 통과하는 에이전트가 아니라 보안 심사와 PIPA 검토를 통과하는 에이전트를 목표로 한다면, 권한 모델과 데이터 마스킹과 PIPA 처리 경로부터 그려야 합니다.
