Agentforce 도입을 시작한 많은 팀이 같은 지점에서 멈춥니다. 데모에서는 에이전트가 매끄럽게 답하는데, 프로덕션 전환을 앞두면 답의 품질이 무너집니다. 대부분은 원인을 프롬프트에서 찾습니다. 문제는 프롬프트가 아닙니다. 문제는 그 아래에 있는 데이터와 권한 구조입니다.
여섯 달짜리 파일럿이 성과를 내지 못하는 조직을 보면, 모델이 약한 것이 아니라 데이터가 굶주려 있습니다. 에이전트는 자신이 닿을 수 있는 데이터만큼만 똑똑합니다. 그 경계를 정하는 것은 Prompt Builder 템플릿이 아니라 아키텍처입니다. 이 글은 Agentforce 도입에서 파일럿이 프로덕션 문턱에 멈추는 구조적 원인을 짚고, 한국 엔터프라이즈가 무엇을 먼저 진단해야 하는지 정리합니다.
문제는 프롬프트가 아닙니다
Agentforce(에이전트포스)의 Atlas Reasoning Engine은 LLM 추론 계층입니다. 최근에는 이 계층이 특정 모델에 묶이지 않고 OpenAI, Anthropic, Gemini 등 원하는 LLM을 선택해 구성하는 개방형 구조로 바뀌었습니다. 이 변화가 종종 오해를 낳습니다. 모델을 바꾸면 답이 좋아질 것이라는 기대입니다. 추론은 입력으로 받은 맥락 위에서만 동작합니다. 어떤 LLM을 붙이든, 에이전트가 고객의 최근 주문 상태를 모른다면 그것은 추론이 약해서가 아니라 그 데이터가 grounding 범위 밖에 있기 때문입니다. 게다가 업무의 진입점이 CRM 화면에서 Slack 대화창으로 옮겨가면서, 사용자가 화면에서 직접 확인하던 정보를 이제는 에이전트가 대화 한 줄로 대신 확인해 줘야 합니다. 데이터 접근의 공백이 그만큼 더 선명하게 드러납니다.
실무에서 파일럿이 멈추는 패턴은 두 가지입니다. 첫째, 필요한 데이터에 에이전트가 접근하지 못합니다. Zero Copy 방식으로 외부 시스템 데이터를 복사 없이 실시간으로 끌어오는 구조가 표준이 되면서 이 문제가 저절로 풀렸다고 생각하기 쉽지만, 데이터를 옮기지 않는 것과 에이전트가 그 데이터에 접근 권한을 갖는 것은 전혀 다른 문제입니다. 주문 이력은 ERP에, 상담 기록은 별도 콜센터 시스템에 있고, 연결 파이프가 있어도 권한 매핑이 없으면 에이전트는 여전히 둘 다 보지 못합니다. 둘째, 접근해서는 안 되는 데이터에 에이전트가 닿습니다. 권한 모델이 사람을 기준으로 설계돼 있고, 에이전트라는 새로운 행위자를 고려하지 않았습니다.
두 경우 모두 프롬프트를 아무리 다듬어도, 모델을 아무리 바꿔도 해결되지 않습니다. 첫 번째는 데이터 파이프라인 문제이고, 두 번째는 보안 모델 문제입니다. 프롬프트 튜닝은 이 두 가지가 정리된 다음에야 효과를 냅니다. 순서를 거꾸로 잡으면, 팀은 몇 주를 프롬프트에 쓰고도 같은 자리에 머뭅니다. 이 구분을 초기에 해 두면, 이후의 모든 개선이 어느 계층의 문제를 풀고 있는지 분명해집니다.
프로덕션 준비도를 가르는 세 가지 계층
프로덕션 준비도를 한 덩어리로 보면 원인을 놓칩니다. 세 계층으로 나누어 따로 진단합니다.
첫 번째는 데이터 접근입니다. 에이전트가 답해야 하는 질문의 목록을 만들고, 각 질문에 필요한 데이터가 지금 Salesforce 안에 있는지, 아니면 Zero Copy로 연결된 외부 시스템에 있는지 확인합니다. Data Cloud의 Data Streams로 끌어올 것과 원본 위치에 두고 실시간 참조만 할 것을 구분하고, 어느 쪽이든 Identity Resolution이 고객을 하나의 Unified Individual로 묶고 있는지 점검합니다. Customer 360이 흩어져 있으면 에이전트는 같은 고객을 여러 사람으로 봅니다. 접점 3,000개 이상의 조직에서는 이 분절이 기본값에 가깝고, 데이터가 원본 자리에 있든 복제돼 있든 Identity Resolution ruleset을 먼저 정리하지 않으면 데이터 접근 문제는 풀리지 않습니다.
두 번째는 보안 모델입니다. 사람의 권한은 프로파일과 공유 규칙으로 정해집니다. 에이전트는 어떤 사용자 맥락에서 실행되는지, 그 맥락의 권한이 무엇까지 허용하는지 정의해야 합니다. LLM을 자유롭게 선택하는 개방형 구조에서는 한 가지가 더 따라옵니다. 어떤 질문이 어떤 외부 모델로 넘어가는지, 그 경로에서 민감 데이터가 어떻게 마스킹되는지입니다. Einstein Trust Layer가 마스킹을 처리하지만, 무엇이 민감 데이터이고 어느 모델 라우팅에 어떤 통제가 적용되는지 선언하는 것은 설계자의 몫입니다. 이 단계를 건너뛰면, 에이전트가 권한 밖 데이터를 답에 노출하는 사고가 프로덕션에서, 혹은 외부 모델로의 전송 과정에서 발생합니다.
세 번째는 액션 계층입니다. 에이전트가 정보를 읽는 데서 끝나지 않고 행동까지 한다면, 그 행동의 범위를 Topics와 Actions로 명확히 그어야 합니다. Slack 대화 안에서 환불을 처리할 수 있는가, 한도는 얼마인가, 어떤 조건에서 사람에게 넘기는가. 업무의 진입점이 Slack으로 옮겨가면서 액션이 실행되는 접점도 늘었고, 그만큼 가드레일을 확인해야 할 표면도 넓어졌습니다. 이 경계가 모호하면 에이전트는 데모에서만 안전합니다. Agentforce Testing Center에서 CRM 화면과 Slack 대화 양쪽의 경계 밖 행동을 미리 시험하지 않으면, 그 시험은 프로덕션에서 고객을 상대로 일어납니다.
이 세 계층을 분리해 보면, 파일럿이 어디서 막혔는지 한 번에 드러납니다. 대개 한 계층이 아니라 데이터 접근과 보안 모델 두 곳이 동시에 막혀 있습니다. 그래서 한 가지만 고쳐도 답 품질이 절반밖에 회복되지 않고, 팀은 다시 프롬프트나 모델 선택을 의심합니다.
진단을 시작하는 순서
세 계층을 동시에 손대면 어디서 효과가 났는지 알 수 없습니다. 순서가 중요합니다.
질문 목록부터 만듭니다. 에이전트가 실제로 답해야 하는 질문 스무 개를 적고, CRM 화면에서 나오는 질문인지 Slack 대화에서 나오는 질문인지, 각각에 필요한 데이터와 행동을 표시합니다. 이 목록이 진단의 기준선이 됩니다. 다음으로 각 질문을 데이터 접근, 보안, 액션 세 계층에 대고 통과 여부를 표시합니다. 통과하지 못한 질문이 어느 계층에 몰려 있는지가 우선순위를 정해 줍니다.
대부분의 조직에서 가장 많이 막히는 곳은 데이터 접근입니다. Zero Copy로 연결이 됐다고 해서 이 계층이 자동으로 통과되지는 않습니다. 그래서 Data Cloud 데이터 모델과 Identity Resolution을 먼저 정리하고, 그 위에서 보안 모델과 LLM 라우팅 통제를 다시 그린 다음, 마지막으로 액션 범위를 좁혀 가는 순서가 안전합니다. 프롬프트와 모델 선택은 이 세 가지가 자리를 잡은 뒤 마지막에 다듬습니다. 이 순서를 지키면, 각 단계의 효과를 따로 측정할 수 있습니다.
이 진단은 한 번에 끝나는 작업이 아닙니다. 질문 목록은 비즈니스가 에이전트에 기대하는 범위가 넓어질수록, 그리고 접점이 Slack으로 확장될수록 함께 자랍니다. 그래서 처음부터 모든 질문을 담으려 하기보다, 가장 빈도가 높은 질문 스무 개로 시작해 데이터와 권한을 정리하고, 그 범위가 안정되면 다음 묶음을 더하는 방식이 현실적입니다. 좁게 시작해 단단하게 넓히는 편이, 넓게 시작해 어디가 약한지 모르는 것보다 빠릅니다.
한국 기업이 자주 놓치는 함정
기술적 준비가 끝나도 프로덕션 승인이 나지 않는 경우가 많습니다. 한국 엔터프라이즈에는 고유한 통제 지점이 있습니다.
개인정보 보호법(PIPA)이 첫 번째입니다. 에이전트가 고객 데이터를 다룬다면, 그 데이터의 수집 근거, 처리 위탁, 국외 이전 동의가 정리돼 있어야 합니다. Data Cloud와 Agentforce가 데이터를 처리하는 위치와 경로를 보안팀이 검토할 수 있게 문서로 만들어 두지 않으면, 기술이 준비돼도 승인 단계에서 멈춥니다. 품의 결재선에 올릴 때, 이 문서가 없으면 검토는 다음 분기로 넘어갑니다.
두 번째 함정은 SI 인수인계입니다. 파일럿을 SI 업체가 구축한 경우, 운영을 누가 맡을지 초기에 정하지 않으면 프로덕션 전환에서 책임 공백이 생깁니다. 에이전트의 거버넌스, 모니터링, 가드레일 조정을 내부 팀이 이어받을 수 있는지가 승인의 숨은 조건입니다. 구축은 외부가 맡더라도, 운영 권한과 변경 절차는 내부가 쥐고 있어야 합니다. Salesforce 거버넌스 운영 모델을 함께 설계하는 것이 그래서 중요합니다. 이 주제는 SI 의존도를 줄이는 거버넌스 운영 모델에서 더 다룹니다.
핵심 정리
Agentforce 도입의 성패는 프롬프트 품질이 아니라 그 아래의 아키텍처에서 갈립니다. 정리하면 다음과 같습니다.
- 답 품질이 불안정하면 데이터 접근과 권한 경계부터 봅니다. 프롬프트 튜닝과 LLM 선택은 그 다음입니다.
- 프로덕션 준비도는 데이터 접근, 보안 모델, 액션 계층 세 가지로 나누어 진단합니다. 한 덩어리로 보면 원인이 묻힙니다.
- Zero Copy와 개방형 LLM 아키텍처는 통합과 모델 선택의 유연성을 높이지만, 권한 매핑과 라우팅 통제를 대신 설계해 주지는 않습니다.
- PIPA 통제와 데이터 처리 경로는 파일럿 설계 단계에서 보안팀과 합의합니다. 프로덕션 직전에 시작하면 일정이 무너집니다.
- SI가 구축한 파일럿은 운영 인수인계 경로를 초기에 정합니다. 책임 공백이 승인을 막습니다.
지금의 파일럿 설계가 18개월 뒤의 운영 비용을 결정합니다. 데이터 접근과 권한을 초기에 정리한
