Agentforce(에이전트포스) PoC가 끝나면 스폰서 손에는 판단 기록이 남아야 합니다. 진행, 보완 후 재시험, 중단 중 하나를 고를 수 있는 증거입니다. 데모에서 자연스러운 답을 한 번 얻기는 쉽지만, 실제 요청을 어디까지 맡길지 판단할 근거는 따로 만들어야 합니다. 프로덕션도 같은 논리로 엽니다. 에이전트는 닿을 수 있는 데이터와 허용된 권한 안에서만 답하므로, 파일럿이 문턱에서 멈추면 원인을 프롬프트 문장보다 그 아래층에서 먼저 찾습니다.
판단 기록이 답해야 할 네 가지
PoC가 “가능성은 확인했다”로 끝나면 다음 회의는 의견 대 의견이 됩니다. 플랫폼 팀은 기능을 봤다고 말하고, 보안 팀은 데이터 경로를 묻고, 운영 팀은 실패하면 누가 처리하는지 묻습니다. 판단 기록은 이 질문에 PoC 안에서 답합니다.
- 에이전트가 처리해도 되는 요청은 무엇입니까?
- 반드시 사람에게 넘길 요청은 무엇입니까?
- 에이전트가 읽는 데이터와 호출하는 Action에는 어떤 권한 경계가 적용됩니까?
- 오류나 예상 밖 요청을 발견하면 누가 어떤 변경을 승인합니까?
Salesforce 용어로는 Subagent가 업무 범위를 나누고, Action이 에이전트가 수행할 일을 연결하고, Instruction이 그 경계 안의 행동을 정합니다. Agentforce DX 테스트 문서는 에이전트 테스트를 질문이나 명령을 보내고 응답 행동이 기대와 맞는지 확인하는 작업으로 설명합니다. 그래서 평가 대상은 답변의 어조보다 분류, Action 선택, 인계, 거절입니다.
이 기준은 시작 전에 운영 책임자가 승인합니다. 결과를 보고 기준을 고치면 설계를 결과에 맞춘 기록이 남습니다. 2022년 Disneyland Paris에서 저는 통합 파트너를 고르기 전에 B2B 프로세스를 감사하고 Salesforce 목표 모델을 정리했습니다. PoC에도 같은 순서가 맞습니다. 진행 여부를 가를 기준은 파트너가 데모를 만들기 전에 고객 조직이 씁니다.
한 업무 흐름을 고르고 거절 경로부터 적습니다
고객 서비스, 영업 지원, 지식 검색을 한 에이전트에 넣으면 결과가 좋아도 무엇이 작동했는지 알 수 없고, 나빠도 어디를 고칠지 알 수 없습니다. 업무마다 데이터, 권한, 예외 처리, 책임자가 다르기 때문입니다. 한 업무 흐름이면 충분합니다. 예를 들어 직원이 이미 접근할 수 있는 지식 문서에서 정책을 찾고, 근거 문서를 함께 보여 주고, 확신할 수 없으면 담당 팀으로 넘기는 흐름입니다. 되돌리기 쉽고, 검색 품질, 권한, 인계, 기록을 한 번에 시험합니다.
그다음 성공 경로보다 거절 경로를 먼저 한 문서에 적습니다.
- 허용 요청: 처리하는 요청 유형과 필요한 입력값
- 금지 요청: 답하거나 실행하지 않는 요청
- 인계 조건: 정보가 없거나, 요청이 애매하거나, 권한 확인이 필요할 때 받는 사람
- Action 경계: 조회, 제안, 기록, 외부 변경 중 허용하는 범위
- 복구 방식: 잘못된 답이나 호출을 발견한 뒤 중지, 수정, 재시험을 승인하는 사람
조회 결과를 보여 주는 일과 외부 시스템 상태를 바꾸는 일은 위험 수준이 다릅니다. 첫 PoC에는 상태를 바꾸는 Action을 넣지 않는 편이 낫고, 꼭 필요하면 대상을 제한하고 사람의 승인과 되돌림 방법을 미리 설계합니다. “테스트 환경이니 괜찮다”는 설명은 권한 설계를 대신하지 못하고, 실제 개인정보를 편의상 PoC에 넣지도 않습니다.
시험 표에는 판정이 두 개 있습니다
테스트 케이스는 정상 요청, 정보 누락, 애매한 표현, 금지 요청, 권한 밖 요청, Action 실패를 포함합니다. 케이스마다 입력 문장, 기대 Subagent, 허용하거나 금지한 Action, 필수 응답 요소, 인계 여부를 적습니다. 기대 결과는 “좋은 답변”처럼 평가자마다 다르게 읽히는 말 대신 “문서 X만 근거로 답하고, 근거가 없으면 담당 부서로 넘긴다”처럼 확인할 수 있는 조건으로 씁니다.
첫 판정은 에이전트 행동입니다. 올바른 Subagent, 허용된 도구, 인계나 거절을 플랫폼 팀이 주도해 확인합니다. 둘째 판정은 운영 적합성입니다. 그 행동이 부서 정책, 책임 분장, 데이터 접근 원칙에 맞는지를 업무 책임자와 보안 또는 개인정보 담당자가 봅니다.
실패한 케이스는 문제가 있는 층을 가리킵니다. 에이전트가 권한 없는 정보를 보여 주었다면 Instruction을 길게 쓰기 전에 데이터 접근, 사용자 권한, Action 입력과 출력 중 어디가 뚫렸는지 봅니다. 계속 인계만 한다면 지식 소스의 범위, 분류 기준, 인계 조건 중 무엇이 좁은지 봅니다.
종료 판단과 프로덕션 준비 조건
종료 회의는 진행, 보완 후 재시험, 중단 중 하나로 끝납니다. 진행 후보가 되려면 허용 요청과 금지 요청을 구분했고, Action 경계가 시험에서 지켜졌고, 인계가 작동했고, 실패 케이스마다 원인과 담당자가 기록돼 있어야 합니다. 보류 신호도 같은 문서에 남깁니다. 테스트마다 다른 원인으로 예상 밖 Action이 호출되는 경우, 데이터 소유자나 업무 책임자가 없는 경우, 성공 판단이 예외 권한이나 비현실적인 테스트 데이터에 기댄 경우, 수정 후 이전 테스트를 다시 통과하는지 확인할 방법이 없는 경우입니다.
진행으로 결론이 나도 프로덕션은 다섯 조건이 갖춰졌을 때 엽니다.
| 조건 | 스폰서가 확인할 내용 |
|---|---|
| 데이터 | 에이전트가 답할 질문 목록이 있고, 질문마다 필요한 데이터 위치와 에이전트의 접근 여부가 표시돼 있습니다. |
| 권한 | 에이전트가 어떤 사용자 맥락에서 실행되는지, 그 맥락이 무엇까지 허용하는지 적혀 있습니다. |
| 중단 담당자 | 품질이 떨어질 때 에이전트를 끌 사람과 기준이 오픈 전에 정해져 있습니다. |
| 시험 세트 | PoC 세트가 변경마다 다시 돌리는 회귀 세트로 넘어가 있습니다. |
| 지원 경로 | 인계된 요청을 받는 팀이 실제로 있고, 인원과 근무 시간이 인계 조건과 맞습니다. |
필요한 데이터에 닿지 못하는 문제와 닿아서는 안 되는 데이터에 닿는 문제는 수정 방법이 다릅니다. 앞의 문제는 권한 매핑에서 풀어야 합니다. 연결이 있어도 매핑이 없으면 에이전트는 그 데이터를 보지 못합니다. 뒤의 문제는 보안 모델에서 풀어야 합니다. 사람 기준으로 만든 권한 모델은 에이전트라는 새 행위자를 고려하지 않았습니다. 어느 쪽도 프롬프트를 다듬거나 모델을 바꿔서는 풀리지 않습니다.
개인정보 처리 경로는 파일럿 설계 단계에서 보안 팀과 합의합니다. 오픈 직전에 검토를 시작하면 동의나 위탁 계약을 다시 받아야 할 수 있고, 그 일은 스프린트 하나로 끝나지 않습니다. SI가 파일럿을 구축했다면 운영 권한을 내부 팀이 이어받는 날짜도 이때 정합니다. 프로덕션 이후 변경 권한을 나누는 방법은 Agentforce 운영 모델에서 다룹니다.
확인할 항목
- PoC 시작 전에 운영 책임자가 승인한 합격 기준이 문서로 있습니까?
- 종료 문서로 진행, 보완 후 재시험, 중단 중 하나를 고를 수 있습니까?
- 테스트 케이스마다 기대 Subagent, 허용 Action, 인계 여부가 적혀 있습니까?
- 에이전트가 실행되는 사용자 맥락을 한 문장으로 설명할 수 있습니까?
- 오픈 전에 에이전트를 끌 사람의 이름이 정해져 있습니까?