Agentforce 운영 모델을 조직도와 대시보드로 착각하는 팀이 많습니다. 프로덕션에서 깨지는 것은 화면이 아닙니다. 누가 Subagent를 고칠 수 있는지, 누가 Action을 추가할 수 있는지, 품질이 떨어졌을 때 누가 에이전트를 멈추는지가 비어 있으면 에이전트는 매일 조금씩 다른 시스템이 됩니다.
PoC에서 한 업무 흐름을 검증한 것과, 그 경계를 매주 유지하는 것은 다른 일입니다. Agentforce PoC 방법론이 승인 가능한 판단 기록을 만드는 단계라면, 이 글은 그 다음 단계입니다. 프로덕션에 올라간 뒤에도 같은 경계를 누가 지키고, 어떤 증거로 변경을 허용할지를 계약으로 고정하는 방법입니다.
Agentforce 운영 모델이 정해야 하는 네 가지 변경 권한
Salesforce는 2026년 4월부터 agent topic을 subagent로 부릅니다. 기능은 바뀌지 않았습니다. 공식 Subagent 문서는 Subagent를 에이전트가 맡을 한 가지 일로 정의합니다. Action은 그 일에 쓰는 도구이고, Instruction은 그 안에서 결정을 내리는 기준입니다. 이름, 분류 설명, 범위, 지침, 액션이 한 묶음입니다.
운영 모델이 정해야 하는 것은 이 묶음의 소유권입니다. 네 권한을 한 팀, 특히 구축 SI에 몰아주면 프로덕션은 구축의 연장이 됩니다.
업무 범위는 어느 Subagent를 켜 둘지입니다. 환불 상담과 내부 정책 검색을 한 에이전트에 넣으면 실패 원인이 섞입니다. 이 권한은 업무 책임자가 집니다. 플랫폼 팀이 이름을 정하고 사업부가 나중에 추인하는 순서는 반대로 갑니다.
실행 도구는 어느 Action이 조회만 하는지, 외부 상태를 바꾸는지입니다. 조회와 변경은 같은 위험 수준이 아닙니다. 이 권한은 플랫폼과 보안이 함께 집니다. 업무 팀이 “한 줄만 추가해 달라”고 요청해도, 변경 Action은 별도 승인입니다.
행동 기준은 Instruction입니다. 거절 조건, 인계 조건, 근거 없는 답을 만들지 말라는 문장이 여기에 있습니다. 초안은 업무 책임자가 씁니다. 시험과 배포는 플랫폼이 맡습니다. 지침 문장을 운영 콘솔에서 바로 고치는 권한을 SI나 개별 상담 리더에게 주면, 어제 시험한 경계가 오늘 사라집니다.
중단 권한은 품질 저하, 오분류, 권한 이탈이 보일 때 에이전트나 Subagent를 비활성화하는 결정입니다. 이 권한은 운영 책임자가 집니다. 중단 기준이 없으면 관측 화면은 구경거리가 됩니다.
관측 수치는 주간 안건이지 합격 점수가 아닙니다
Salesforce의 Agentforce Observability는 두 용도를 구분합니다. Agent Optimization은 해결되지 않은 상호작용, 지식 공백, 세션 추적을 깊게 봅니다. Agent Analytics는 토픽, 평균 피드백, 인계율, 이탈율, 중단 세션 같은 효과 지표를 봅니다. 낮은 품질 점수의 토픽, 오해석, 처리되지 않은 대화를 표시합니다.
이 수치가 운영 모델이 되려면 주간 회의의 안건이 되어야 합니다. 각 항목은 다섯 갈래 중 하나로 끝납니다. 이번 주는 관찰만. Instruction 수정. Action 제한. Subagent 비활성화. 데이터나 권한 문제로 아키텍처 검토. “점수를 올리자”는 결정이 아닙니다.
새로고침 주기도 의사결정 주기에 맞춰야 합니다. 같은 문서는 Session Tracing 데이터 모델이 약 30분, 분석 지표가 45~60분, Moments와 품질 점수가 하루, 태그가 일주일에 한 번 갱신된다고 적습니다. 품질 점수를 오전에 보고 오후에 지침을 고치면, 그 점수는 아직 어제 대화를 보고 있을 수 있습니다.
실시간처럼 보이는 신호는 다른 층입니다. Agent Health Monitoring은 Salesforce Foundations 또는 Agentforce 1 Editions가 있는 Enterprise, Performance, Unlimited에서 오류율 급등이나 높은 지연 같은 조용한 실패를 거의 실시간으로 알립니다. 알림 평가 주기는 10분이고, 알림 도착은 3분에서 7분입니다. Salesforce가 그다음에 적는 순서는 분명합니다. 조사하고, 개선하고, 시험하고, 배포한 뒤 다시 모니터링합니다. 사고 대응과 주간 개선을 한 회의에서 섞으면 둘 다 느려집니다.
관측을 켜는 것만으로 이 루프는 생기지 않습니다. Observability 설정 문서는 Session Tracing과 Data Model, Agentforce Optimization을 켜고 Access Agentforce Optimization, Tableau Next 권한, Data Cloud User를 부여하라고 합니다. 추적 모델을 켠 이후에 생긴 대화만 분석에 올라갑니다. 운영팀에 이 권한이 없으면 대시보드는 구축 파트너의 화면으로 남습니다.
Session Tracing을 쓰면 상호작용마다 분류된 Subagent가 TopicApiName으로 Data 360 데이터 모델에 남습니다. 오분류가 반복되면 지침을 늘리기 전에, 이름이 겹치거나 분류 설명이 비슷한 Subagent가 있는지를 먼저 봅니다. 공식 문서도 이름이 겹치지 않게 쓰라고 못 박습니다.
변경은 샌드박스 Testing Center를 통과한 뒤에만 올립니다
운영 중 가장 비싼 습관은 고객 민원에 반응해 프로덕션 Instruction을 고치는 일입니다. 한 줄이 작아 보입니다. 그 한 줄이 허용 업무, 금지 업무, 인계 조건을 한꺼번에 움직입니다.
Agentforce Testing Center는 응답 정확도, Subagent 인식, Action 실행, 지식 검색, 완전성, 일관성, 간결성, 지연, 지침 준수를 평가합니다. 에이전트는 비결정적이므로 넓은 시나리오에서 시험하라고 적혀 있습니다. 같은 페이지의 경고가 더 중요합니다. 테스트가 CRM 데이터를 바꿀 수 있으니 Testing Center는 샌드박스에서만 씁니다.
운영 승인 기준은 “좋은 문장”이 아닙니다. 올바른 Subagent로 갔는가. 허용된 Action만 호출했는가. 정보가 없을 때 추측하지 않았는가. 권한 밖 요청을 거절했는가. 이 네 가지가 샌드박스에서 다시 통과해야 프로덕션 변경입니다.
Summer ‘26부터 Testing Center 시험 자체는 Einstein Request와 Flex Credit을 쓰지 않습니다. Data 360 조회는 여전히 과금됩니다. Testing Center 고려사항에 그렇게 적혀 있습니다. 과금이 줄었다고 프로덕션에서 바로 시험하라는 뜻이 아닙니다. 데이터 변경 위험이 남아 있습니다.
테스트 세트도 운영 자산입니다. 정상 요청, 정보 누락, 애매한 표현, 금지 요청, 권한 밖 요청, Action 실패를 고정해 두고, Instruction이나 Action이 바뀔 때마다 같은 세트를 다시 돌립니다. 세트가 없으면 녹색 결과는 이번 민원만 달랜 기록입니다.
데이터와 권한 계층이 아직 흔들린다면 운영 루프보다 그 진단이 먼저입니다. 프로덕션 준비도에서 막히는 데이터 접근과 권한 경계를 정리하지 않은 채 지침만 고치면, 시험은 같은 실패를 반복합니다.
한국 조직에서 운영 모델이 비는 지점
가장 흔한 공백은 구축과 운영의 이음새입니다. SI가 Subagent와 Action을 만들고, 내부 팀은 채널만 받습니다. 장애가 나면 SI에 수정을 요청하고, 그 수정은 프로덕션에서 이뤄집니다. 이 구조에서는 운영 모델이 없습니다. 구축 계약만 있습니다.
품의에도 같은 구멍이 납니다. 기능 목록과 라이선스는 있고, 변경 승인자, 중단 권한, 시험 환경, 운영 권한 세트는 없습니다. 결재선이 통과해도 다음 주에 Instruction을 누가 고칠지는 여전히 공란입니다.
관측을 구축 산출물로만 넣는 경우도 많습니다. Session Tracing을 켜 두었는데 운영 담당자에게 Optimization 권한이 없습니다. 데이터가 쌓이기 시작하는 시점도 설정 이후입니다. 오픈 당일 대시보드가 비어 있다고 제품이 고장난 것이 아닙니다.
개인정보 보호법(PIPA) 검토를 오픈 전에 한 번만 하고 운영 루프 밖에 두는 패턴도 위험합니다. Action이 조회하는 객체나 외부 호출이 바뀌면 처리 목적과 위탁 범위가 같이 움직입니다. 이 글은 법률 자문이 아닙니다. 변경 계약에 개인정보 담당자의 재검토 조건을 넣는 것은 운영 설계입니다.
내부가 승인 권한과 시험 세트를 쥐고, SI는 샌드박스 구현과 테스트 자동화만 맡는 편이 안전합니다. 이 경계를 프로그램 통제로 고정해야 한다면 서비스 안내에서 검토 범위와 산출물을 확인할 수 있습니다.
첫 업무 흐름이 안정되기 전에 두 번째 부서로 넓히면 안 됩니다. 새 Subagent를 추가할 때마다 범위, Action, 시험 세트, 인계 조직을 다시 승인합니다. 한 에이전트의 성공을 다른 부서의 자동 승인으로 읽으면, 운영 모델은 첫 확대로 끝납니다.
핵심 정리
- Agentforce 운영 모델은 조직도가 아니라 Subagent, Action, Instruction, 중단의 변경 권한을 나눈 계약입니다.
- 관측 화면의 품질 점수와 인계율은 합격선이 아닙니다. 관찰, 지침 수정, Action 제한, 비활성화, 아키텍처 검토 중 하나로 끝나야 합니다.
- Testing Center는 샌드박스에서 쓰고, 운영 승인은 Subagent 분류, 허용 Action, 거절, 인계가 다시 통과했는지로 판단합니다.
- Session Tracing과 Health Monitoring은 권한이 운영팀에 있고, 설정 이후 대화만 보인다는 전제에서만 작동합니다.
- SI는 구현과 시험 자동화를 맡을 수 있습니다. 업무 범위와 프로덕션 변경 승인을 외부에 넘기면 운영은 구축의 연장이 됩니다.
