Agentforce PoC 방법론의 출발점은 화면이 아니다. 어떤 운영 결정을 내리기 위해 무엇을 확인할지부터 정해야 한다. 데모에서 자연스러운 답변을 한 번 얻는 일은 쉽다. 실제 고객이나 직원의 요청을 어느 범위까지 맡길지 판단할 근거를 만드는 일은 다르다.
PoC가 끝난 뒤에도 “가능성은 확인했다”만 남으면 다음 단계는 다시 의견 대 의견이 된다. 플랫폼 팀은 기능을 봤다고 말하고, 보안 팀은 권한과 데이터 경로를 묻고, 운영 팀은 실패했을 때 누가 처리할지를 묻는다. 이 질문을 PoC 안에 넣지 않으면 기간이 짧아도 비용은 결코 작지 않다.
이 글은 특정 업종의 정답을 제시하지 않는다. 대신 한국 기업이 Agentforce PoC를 품의와 운영 승인에 쓸 수 있는 판단 구조를 제시한다. 범위를 좁히는 이유, 측정해야 할 행동, 실패를 처리하는 방식, 다음 투자를 보류해야 하는 신호를 한 계약으로 묶는 방법이다.
Agentforce PoC의 산출물은 에이전트가 아니라 승인 가능한 판단 기록입니다
PoC의 첫 산출물은 Agentforce 에이전트가 아니다. “이 업무 흐름을 이 조건에서 운영 후보로 올릴 수 있는가”라는 질문에 답하는 판단 기록이다. 이 기록이 없으면 PoC는 구현 팀의 실험으로 끝나고, 운영 전환 때 같은 논의를 다시 시작한다.
판단 기록에는 네 가지가 있어야 한다. 첫째, 사용자가 어떤 요청을 했을 때 에이전트가 처리해도 되는지다. 둘째, 어떤 요청은 반드시 사람에게 넘겨야 하는지다. 셋째, 에이전트가 참조하는 데이터와 호출하는 Action에 어떤 권한 경계가 적용되는지다. 넷째, 오류나 예상 밖의 요청을 발견했을 때 누가 어떤 변경을 승인하는지다.
이 순서는 기술 구성보다 먼저 정해야 한다. Topics는 업무 범위를 나누고, Actions는 에이전트가 수행할 일을 연결하며, Instructions는 그 경계 안에서의 행동을 설명한다. Salesforce는 에이전트 테스트를 사용자의 질문, 진술 또는 명령을 보내고 응답 행동이 기대와 맞는지 확인하는 작업으로 설명한다. 공식 Agentforce DX 테스트 문서에서 확인할 수 있다.
이 정의가 중요한 이유는 답변 문장만 평가하면 안 되기 때문이다. 승인 가능한 PoC는 답변의 어조와 함께 다음을 확인해야 한다. 올바른 Topic으로 분류했는가. 허용된 Action만 선택했는가. 필요한 정보가 없을 때 추측 대신 멈추거나 사람에게 넘겼는가. 요청자가 권한 없는 정보를 요구했을 때 거절했는가.
운영 책임자는 이 기준을 시작 전에 승인해야 한다. 나중에 테스트 결과를 보고 기준을 고치면, 결과가 설계를 검증한 것이 아니라 설계가 결과에 맞춰진 것이 된다. 특히 PIPA 적용 대상 데이터가 포함될 수 있는 흐름이라면, 실제 개인정보를 실험 편의상 넣는 방식도 피해야 한다. PoC 데이터와 운영 데이터의 경계, 접근 역할, 보관 기간은 보안 검토에서 별도 항목으로 남겨야 한다.
한 개의 업무 흐름과 한 개의 실패 경계를 고정해야 합니다
Agentforce PoC에서 가장 흔한 범위 오류는 고객 서비스, 영업 지원, 지식 검색을 한 에이전트에 함께 넣는 일이다. 각 업무가 유사해 보여도 필요한 데이터, 권한, 예외 처리, 책임자가 다르다. 여러 흐름을 한 번에 넣으면 결과가 좋아도 무엇이 작동했는지 알 수 없고, 결과가 나빠도 어디를 고쳐야 하는지 알 수 없다.
PoC에는 한 업무 흐름이면 충분하다. 예를 들어 내부 직원이 이미 접근 권한을 가진 지식 문서에서 정책을 찾고, 답변에 근거 문서를 함께 제시하며, 확신할 수 없는 경우 담당 팀으로 넘기는 흐름을 고를 수 있다. 이 선택은 고객에게 영향을 주는 변경을 바로 실행하는 흐름보다 되돌리기 쉽다. 동시에 검색 품질, 권한, 인계, 운영 기록이라는 핵심 문제를 시험할 수 있다.
업무 흐름을 고른 뒤에는 성공 경로보다 거절 경로를 먼저 적는다. 다음 항목은 한 문서에서 서로 연결돼야 한다.
- 허용 요청: PoC가 처리하는 요청의 유형과 필요한 입력값입니다.
- 금지 요청: 정책상 답하지 않거나 실행하지 않아야 하는 요청입니다.
- 인계 조건: 정보가 없거나, 요청이 애매하거나, 권한 확인이 필요한 경우의 처리 주체입니다.
- Action 경계: 조회, 제안, 기록, 외부 변경 중 무엇을 허용하는지입니다.
- 복구 방식: 잘못된 답변이나 잘못된 호출을 발견한 뒤 중지, 수정, 재시험을 누가 승인하는지입니다.
여기서 중요한 구분이 있다. 조회 결과를 제시하는 일과 외부 시스템의 상태를 바꾸는 일은 같은 위험 수준이 아니다. PoC 첫 단계에는 외부 변경 Action을 넣지 않는 편이 낫다. 외부 변경이 사업 가설을 검증하는 데 꼭 필요하다면, 변경 대상을 제한하고 사람의 승인 단계와 되돌림 방법을 미리 설계해야 한다. “테스트 환경이니 괜찮다”는 설명은 권한 설계를 대신하지 못한다.
Agentforce가 제공하는 도구를 평가할 때도 이 경계를 유지해야 한다. Agentforce DX 안내 문서는 VS Code와 CLI, 조직의 Agentforce Testing Center UI, Testing API를 테스트 수단으로 제시한다. 이 수단은 에이전트 동작을 반복 확인하는 데 도움이 된다. 다만 어떤 업무를 운영에 허용할지, 어떤 오류를 중단 사유로 볼지는 조직의 운영 정책이 결정해야 한다.
범위를 좁히면 덜 야심 차 보일 수 있다. 그러나 이 방식이 다음 예산 판단에는 더 유리하다. 한 흐름의 실패 원인을 분리해 기록할 수 있기 때문이다. 데이터가 부족한지, Instruction이 모호한지, Action 계약이 불완전한지, 권한이 맞지 않는지를 같은 테스트에서 구분할 수 있다.
테스트는 답변 품질과 실행 경계를 따로 검증해야 합니다
PoC의 테스트 표는 “정답률” 한 줄로 끝나면 안 된다. 생성형 에이전트는 같은 요청에서도 문장 표현이 달라질 수 있다. 운영에서 더 중요한 것은 허용된 업무 경계를 지켰는지, 필요한 경우 멈췄는지, 근거가 없는 내용을 사실처럼 말하지 않았는지다.
테스트 케이스는 최소한 정상 요청, 누락된 정보, 애매한 표현, 금지된 요청, 권한 밖 요청, Action 실패를 포함해야 한다. 각 케이스마다 입력 문장, 기대 분류, 허용 또는 금지된 Action, 필수 응답 요소, 인계 여부를 기록한다. 기대 결과는 “좋은 답변”처럼 평가자마다 달라지는 문장으로 쓰지 않는다. 예를 들어 “문서 X만 근거로 답하고, 근거가 없으면 담당 부서로 인계한다”처럼 확인 가능한 조건으로 쓴다.
Salesforce의 테스트 실행 문서는 테스트 결과에서 각 테스트 케이스의 구성 요소와 성공 또는 실패 여부를 확인하는 방식을 설명한다. 이 기능을 쓰더라도 테스트 데이터와 기대 결과의 품질은 자동으로 보장되지 않는다. 기대 결과가 모호하면 녹색 결과가 나와도 운영 위험은 남는다.
따라서 테스트 표에는 두 개의 판정을 둔다. 첫 판정은 에이전트 행동이다. 올바른 범주로 갔는지, 허용된 도구를 썼는지, 인계 또는 거절을 했는지 확인한다. 둘째 판정은 운영 적합성이다. 그 행동이 해당 부서의 정책, 책임 분장, 데이터 접근 원칙에 맞는지 확인한다. 첫 판정은 플랫폼 팀이 주도할 수 있다. 둘째 판정에는 업무 책임자와 보안 또는 개인정보 담당자가 참여해야 한다.
Instruction도 테스트 대상이다. Salesforce의 Agentforce Instructions 작성 가이드는 명확한 목적, 범위, 제약, 예외 처리의 중요성을 설명하고, 결과를 바탕으로 Instructions, Actions, Topics를 조정하는 반복 작업을 권장한다. 이 반복은 문구를 계속 바꾸는 작업이 아니다. 실패한 테스트가 어떤 경계를 드러냈는지 파악하고, 그 경계를 어느 구성 요소에서 통제할지 결정하는 작업이다.
예를 들어 에이전트가 권한 없는 정보를 제시했다면 먼저 프롬프트 문장을 더 길게 쓰는 방식은 위험하다. 데이터 접근, 사용자 권한, Action 입력과 출력, Instruction 중 어느 층이 실패했는지 확인해야 한다. 반대로 정보가 부족할 때 계속 인계한다면, Knowledge 소스의 범위가 맞지 않는지, 질문 분류가 지나치게 좁은지, 인계 기준이 과도한지 검토해야 한다. 같은 현상도 원인은 다르다.
PoC 종료 기준은 다음 투자와 보류를 함께 결정해야 합니다
PoC 종료 회의에서 “성공”이라는 단어만 쓰면 다음 단계의 범위가 다시 불분명해진다. 종료 문서는 투자, 보완 후 재시험, 중단 중 하나를 선택할 수 있어야 한다. 이를 위해 종료 기준을 수치 하나가 아니라 증거 묶음으로 관리한다.
투자 후보로 올릴 수 있는 조건은 다음과 같다. 정해진 업무 흐름에서 허용된 요청과 금지된 요청을 구분했다. 허용된 Action 경계가 테스트에서 지켜졌다. 정보가 부족하거나 정책상 처리할 수 없는 요청에서 정해진 인계가 작동했다. 실패 케이스마다 원인과 담당자가 기록됐다. 운영 책임자가 다음 단계에서 필요한 데이터, 권한, 지원 체계를 확인했다.
반대로 보류해야 할 신호도 명확히 남긴다. 테스트마다 다른 원인으로 예상 밖의 Action이 호출된다. 데이터 소유자와 업무 책임자가 정해지지 않았다. 사람에게 넘기는 흐름이 실제 운영 조직에서 처리될 수 없다. PoC 성공 판단을 위해 예외 권한이나 비현실적인 테스트 데이터에 의존했다. 수정할 때마다 이전 테스트를 다시 통과하는지 확인할 방법이 없다.
이 기록은 SI와 내부 팀의 역할도 분명히 한다. SI는 설정, 통합, 테스트 자동화에서 기여할 수 있다. 하지만 업무 범위, 금지 업무, 인계 기준, 운영 승인 조건은 내부 책임자가 소유해야 한다. 이 소유권이 없으면 PoC 결과는 외부 파트너의 시연 자료가 되고, 이후 변경 비용과 책임은 조직 안에 남는다.
PoC 다음 단계에서 바로 전사 확대를 결정할 필요는 없다. 한 업무 흐름이 기준을 통과했다면 다음 단계는 같은 통제 구조를 유지한 제한된 운영 시험이 될 수 있다. 그때도 새 업무 흐름을 추가할 때마다 범위, 권한, 테스트, 인계 조건을 다시 승인해야 한다. 첫 PoC의 성공을 다른 부서의 자동 승인으로 해석하면 안 된다.
Agentforce 운영 준비도에서 확인해야 할 책임 경계와 변경 통제는 이 글에서 더 구체적으로 다룹니다. 서비스 범위와 독립적 검토가 필요한 조직은 서비스 안내에서 검토 방식과 산출물의 범위를 확인할 수 있습니다.
핵심 정리
- Agentforce PoC 방법론은 데모 완성도가 아니라 운영 판단에 필요한 증거를 만드는 방식이어야 합니다.
- 한 개의 업무 흐름과 한 개의 책임 경계를 정하면, 실패 원인을 데이터, 권한, 지침, Action 계약으로 나눠 볼 수 있습니다.
- 테스트는 답변 문장뿐 아니라 Topic 분류, 허용된 Action, 거절, 인계가 약속대로 작동하는지 확인해야 합니다.
- 종료 문서는 투자 조건과 보류 신호를 함께 남겨야 합니다. 그래야 다음 예산과 운영 승인에서 같은 논의를 반복하지 않습니다.
