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