Agentforce(에이전트포스) 운영 모델의 중심은 변경 권한입니다. 어느 Subagent를 켤지, 어느 Action이 외부 상태를 바꿔도 되는지, 누가 Instruction을 고치는지, 누가 에이전트를 멈추는지가 적혀 있지 않으면 에이전트는 민원이 들어올 때마다 프로덕션에서 조금씩 달라집니다. PoC는 한 업무 흐름을 한 번 검증하고, 운영 모델은 그 경계를 매주 지킵니다. PoC가 남겨야 할 판단 기록은 Agentforce PoC에서 프로덕션까지에서 다룹니다.
네 가지 변경 권한
Salesforce는 2026년 4월부터 agent topic을 subagent로 부르고, 기능은 그대로입니다. 공식 Subagent 문서는 Subagent를 에이전트가 맡는 한 가지 일로 정의합니다. Action은 그 일의 도구이고, Instruction은 판단 기준입니다. 이 묶음을 다루는 네 권한을 한 팀, 특히 구축을 맡은 SI에 몰아주면 프로덕션은 구축의 연장이 됩니다.
업무 범위, 곧 어느 Subagent를 켜 둘지는 업무 책임자가 정합니다. 환불 상담과 내부 정책 검색을 한 에이전트에 넣으면 실패 원인이 섞이므로, 새 Subagent는 Action, 시험 세트, 인계 조직과 함께 다시 승인합니다.
실행 도구, 곧 어느 Action이 조회만 하고 어느 Action이 외부 상태를 바꾸는지는 플랫폼 팀과 보안 팀이 함께 정합니다. 업무 팀이 “한 줄만 추가해 달라”고 해도 상태를 바꾸는 Action은 별도 승인을 거칩니다.
행동 기준은 Instruction입니다. 거절 조건, 인계 조건, 근거 없이 답하지 말라는 문장이 여기에 들어갑니다. 초안은 업무 책임자가 쓰고, 시험과 배포는 플랫폼 팀이 맡습니다. 운영 콘솔에서 문장을 바로 고치는 권한을 SI나 상담 리더에게 주면, 어제 시험한 경계가 오늘 사라집니다.
중단 권한, 곧 품질 저하, 오분류, 권한 이탈이 보일 때 에이전트나 Subagent를 끄는 결정은 운영 책임자가 쥡니다. 중단 기준은 파일럿 전에 문서로 적습니다. 모든 조직에 맞는 숫자는 없습니다. 미리 적어 둔 기준과 그 기준을 발동할 한 사람이 필요합니다.
최소 산출물은 한 장짜리 변경 계약입니다.
| 변경 | 승인 | 실행 | 시험 | 되돌림 |
|---|---|---|---|---|
| Subagent 추가 | 업무 책임자 | 플랫폼 팀 | 샌드박스, 전체 시험 세트 | Subagent 비활성화 |
| Action 추가·변경 | 플랫폼 팀과 보안 팀 | 플랫폼 팀 또는 SI | 샌드박스, 실패 케이스 포함 | Action 해제 |
| Instruction 수정 | 업무 책임자 | 플랫폼 팀 | 같은 시험 세트 재실행 | 이전 버전 재활성화 |
| 긴급 중단 | 운영 책임자 | 운영 책임자 | 재개 전 시험 | 미리 정한 인계 경로 |
L’Occitane Group의 일본·프랑스 Service Cloud 딜리버리(2023-2024)에서는 본사와 APAC 팀의 변경이 하나의 검증 경로를 거쳤습니다. 에이전트에는 이 원칙이 더 필요합니다. Instruction 한 줄이 허용 업무, 금지 업무, 인계 조건을 한꺼번에 움직이기 때문입니다.
작성 권한도 운영 결정입니다
에이전트 작성 도구는 캔버스, 스크립트 보기, 시뮬레이션으로 에이전트를 빠르게 쓰게 해 줍니다. 작성 권한을 의도해서 배정하지 않으면 여러 사람이 범위가 겹치는 Subagent를 만들고, 사고가 나도 어느 범위의 문제인지 가릴 수 없습니다. 샌드박스와 프로덕션에서 누가 에이전트를 만들고 고칠지는 플랫폼 책임자가 정하고, 명단으로 남기고, 릴리스마다 다시 봅니다.
Instruction을 고칠 권한과 업무 규칙을 바꿀 권한은 서로 다릅니다. Instruction은 모델이 해석하는 문장입니다. 환불 한도나 본인 확인처럼 반드시 지켜야 하는 규칙은 권한, 검증 규칙, 스크립트의 결정적 단계, 사람의 승인 중 하나에 둡니다. Instruction에만 적힌 규칙은 시험을 통과해도 다음 대화에서 보장되지 않습니다.
SI는 구축과 시험 자동화를 맡을 수 있습니다. 업무 범위, 지식 문서와 데이터의 소유, 프로덕션 변경 승인은 내부에 남깁니다. 설정 파일을 저장해 두었다고 되돌릴 수 있는 상태가 되지는 않습니다. 시험을 통과한 이전 버전과, 그 버전을 다시 켤 권한이 있는 담당자가 있어야 합니다.
관측 수치는 주간 안건입니다
Agentforce Observability는 해결되지 않은 상호작용과 세션 추적을 깊게 보는 Agent Optimization과, 인계율과 이탈율 같은 효과 지표를 보는 Agent Analytics를 나눕니다. 이 수치는 주간 회의 안건에 올라가고 각 안건이 다음 다섯 결과 중 하나로 끝날 때 운영 모델이 됩니다.
- 이번 주는 관찰만 합니다.
- Instruction을 수정합니다.
- Action을 제한합니다.
- Subagent를 비활성화합니다.
- 데이터나 권한 문제로 넘겨 검토합니다.
“점수를 올리자”는 이 목록에 없습니다. 누가 무엇을 바꾸는지 정하지 않기 때문입니다.
회의 주기는 데이터 갱신 주기에 맞춥니다. 같은 문서에 따르면 Session Tracing 데이터 모델은 약 30분, 분석 지표는 45~60분, Moments와 품질 점수는 하루, 태그는 일주일 단위로 갱신됩니다. 오전에 본 품질 점수는 오후에 Instruction을 고칠 때까지도 어제 대화를 반영할 수 있습니다. 데이터는 추적을 켠 뒤의 대화부터 쌓이고, 운영 팀에 분석 권한이 없으면 대시보드는 구축 파트너의 화면으로 남습니다.
사고 대응은 다른 경로로 갑니다. Agent Health Monitoring은 오류율 급등이나 높은 지연 같은 조용한 실패를 10분 주기로 평가해 거의 실시간으로 알립니다. 이 알림은 운영 책임자의 중단 권한으로 보내고, 개선은 주간 회의로 보냅니다. 오분류가 반복되면 Instruction을 늘리기 전에 이름이나 분류 설명이 겹치는 Subagent부터 찾습니다.
변경은 샌드박스 시험을 통과한 뒤에만 올립니다
운영에서 가장 비싼 습관은 고객 민원에 반응해 프로덕션 Instruction을 바로 고치는 일입니다. Agentforce Testing Center는 응답 정확도, Subagent 인식, Action 실행, 지침 준수 등을 평가하고, 시험이 CRM 데이터를 바꿀 수 있으니 샌드박스에서 쓰라고 경고합니다.
프로덕션 변경은 샌드박스에서 네 가지를 다시 통과해야 합니다. 올바른 Subagent로 분류했는가, 허용된 Action만 호출했는가, 정보가 없을 때 추측하지 않았는가, 권한 밖 요청을 거절했는가입니다. 이 기준 뒤에 있는 시험 세트(정상 요청, 정보 누락, 애매한 표현, 금지 요청, 권한 밖 요청, Action 실패)는 운영 자산이고, 변경마다 다시 돌립니다. 세트가 없으면 녹색 결과는 민원 한 건을 달랜 기록일 뿐입니다.
Action이 새 객체를 읽거나 새 외부 시스템을 호출하면 개인정보 처리 목적과 위탁 범위도 함께 움직이므로, 변경 계약에 개인정보 담당자의 재검토 조건을 넣습니다. 그리고 첫 업무 흐름이 안정되기 전에는 두 번째 부서로 넓히지 않습니다. 한 에이전트의 성공이 다른 부서의 승인을 대신하지는 않습니다.
확인할 항목
- Subagent 추가, Action 추가, Instruction 수정, 긴급 중단마다 승인자, 실행자, 시험 환경, 되돌림 방법이 한 장에 적혀 있습니까?
- 프로덕션에서 Instruction을 고칠 수 있는 사람을 명단으로 댈 수 있습니까?
- 반드시 지켜야 하는 규칙이 Instruction에만 적혀 있지는 않습니까?
- 주간 회의의 각 안건이 다섯 결과 중 하나로 끝납니까?
- 중단 기준이 파일럿 전에 문서로 있고, 발동할 사람이 정해져 있습니까?