U Mobile의 에이전틱 운영, 답변을 넘어 승인된 조치로 확장

사례 연구에 따르면 U Mobile의 에이전틱 운영은 이제 6개 부서에서 150개가 넘는 시나리오를 다루며, 티켓 감소율은 최대 84.5%에 이른다. AiDaH 플랫폼은 도구와 작업을 조율하는 소프트웨어인 에이전틱 AI를 사용하면서도, 실제 가입자 변경에는 사람의 승인을 유지한다.

이러한 구분은 이 사례를 익숙한 지원 어시스턴트와 완전 자율 운영이라는 약속 사이에 놓이게 한다. 답변을 만드는 일과 변경을 승인하는 일에는 서로 다른 책임이 따른다. 기회를 만드는 지점은 계정 변경의 통제 가능성을 해치지 않으면서 조사 업무를 줄이는 데 있다.

Google Cloud와 One NZ는 유용한 비교 사례를 제공한다. 이들의 작업 역시 AI 분석을 운영 워크플로와 연결한다. 기업 구매자에게 질문은 더욱 구체적으로 변하고 있다. 소프트웨어는 얼마나 많은 조사를 완료할 수 있으며, 권고안에는 어떤 근거가 수반되고, 조치의 책임은 누가 계속 지는가?

U Mobile의 에이전틱 운영은 에스컬레이션 전에 조사를 수행한다

운영상의 변화는 다른 팀이 사례를 넘겨받기 전에 해당 사례를 조사하는 방식에 관한 것이다.

AiDaH 배포 관련 설명은 2026년 11월 4일에 공개됐다. U Mobile은 에이전트를 배포하고 연결하기 위한 AWS 인프라인 Amazon Bedrock AgentCore에서 AWS 및 Axrail과 함께 이 플랫폼을 구축했다.

연대기는 중요하다. 프로덕션 도입은 2026년 3분기에 시작됐으며, 9개월 이정표는 최초 파일럿 이후의 진전을 의미한다. 보고된 티켓 비교는 1월부터 9월까지를 포괄한다.

프로덕션 사례 중 하나는 부가 서비스 구매 실패였다. AiDaH는 거래를 막고 있던 보류 중 주문을 식별했다. 이는 지원 상호작용이 유용한 응답을 제공하기 전에 여러 시스템에 걸친 조사를 요구할 수 있는 이유를 보여준다.

분석상 중요한 점은 이 조사가 워크플로 내에서 차지하는 위치다. 작성 어시스턴트는 누군가 관련 근거를 수집한 뒤 설명을 개선한다. 운영 에이전트는 더 이른 단계에 참여해 어떤 설명과 조치가 타당한지 결정하는 정보를 조립할 수 있다.

이처럼 이른 개입은 구매자가 평가해야 할 대상을 바꾼다. 불완전한 계정 정보에 기반한다면 매끄러운 응답은 거의 안심할 근거가 되지 못한다. 반대로, 차단 조건을 식별하고 검토자에게 진행에 충분한 근거를 제공하는 간결한 판단은 가치가 있을 수 있다.

실패한 거래를 설명하는 것과 그 원인을 식별하는 것의 차이를 생각해 보자. 설명은 고객이 경험한 일을 확립한다. 진단은 증상과 다른 시스템이 해결해야 할 조건을 구분해야 한다.

바로 여기서 에스컬레이션은 중요한 경계가 된다. 에스컬레이션은 적절하게 소유권을 이전할 수 있지만, 미완의 조사를 넘길 수도 있다. 수신 팀이 여전히 수리를 수행하더라도, 그 이전을 더 잘 파악된 상태로 만든다면 에이전트 플랫폼은 그 공로를 인정받을 만하다.

따라서 독자는 진단, 권고, 승인, 실행을 구분해야 한다. 이 단계들은 운영 사슬을 이루며, 한 단계의 개선이 다른 모든 단계에서 동등한 진전을 입증하지는 않는다. 더 빠른 진단은 무제한적인 통제를 뜻하지 않으면서도 여전히 유용하다.

보류 중 주문 사례는 구체적인 해석을 뒷받침한다. 시스템 간 근거는 지원 응답을 더 실행 가능하게 만들 수 있다. 이는 다른 모든 시나리오가 얼마나 안정적으로 수행되는지, 권고안이 얼마나 자주 수정되어야 하는지, 고객이 결과를 어떻게 경험하는지를 입증하지는 않는다.

이러한 경계는 이 사례를 유용하게 유지한다. 기업 AI 보도는 바뀐 작업 단위를 식별할 때 더 많은 정보를 제공한다. 여기서 그 단위는 주로 유창성으로 평가되는 대화가 아니라, 승인된 조치로 이어지는 조사다.

유사한 시스템을 평가하는 구매자에게 관련 비교 대상은 동일한 사례에 대한 이전 워크플로다. 직원들은 이전에 어떤 근거를 수집했고, 어떤 인계를 거쳐야 했으며, 권고안이 도착한 뒤에도 어떤 업무가 남는가?

지원 팀은 AI 가치에 대해 다른 기준에 직면한다

지원 어시스턴트는 직원들이 채팅 인터페이스를 사용하는 것만으로가 아니라, 미해결 업무를 줄일 때 운영 가치를 얻는다.

압박은 우선 기업 소프트웨어 구매자와 지원 기능을 판매하는 공급업체에 가해진다. 시스템이 조사를 조립하는 데 도움을 줄 수 있다면, 응답 초안 작성은 더 좁은 제안이 된다. 구매자가 생성된 텍스트 전후에 무엇이 일어나는지 물을 이유가 있다.

그렇다고 초안 작성이 무의미해지는 것은 아니다. 특히 고객이 이해하기 쉬운 다음 단계를 필요로 할 때 명확한 설명은 중요하다. 그러나 작성 품질과 운영 완료는 서로 다른 비즈니스 질문에 답하므로 별도로 측정해야 한다.

직원은 기록을 찾는 데 같은 시간을 쓰면서도 더 명확한 메시지를 만들 수 있다. 또 다른 직원은 관련 근거로 뒷받침된 더 짧은 설명을 받고 사례를 더 빨리 마무리할 수 있다. 이 결과들은 서로 다르게 평가받아야 한다.

이 분석은 직원 생산성에 관한 대화도 바꾼다. 인터페이스 안에서 절약되는 시간은 전체 그림의 일부일 뿐이다. 구매자는 업무가 사라지는지, 다른 대기열로 이동하는지, 아니면 원래 문제가 해결되지 않아 나중에 되돌아오는지를 살펴봐야 한다.

지원 조직은 불필요한 인계가 줄어드는 것을 합리적으로 가치 있게 여길 수 있다. 그러나 에스컬레이션 수 감소에는 맥락이 필요하다. 직원들이 더 많은 사례를 직접 해결하고 있을 수도 있고, 어려운 사례를 에스컬레이션하기를 주저하고 있을 수도 있다. 고객 결과는 이 두 설명을 구분하는 데 도움이 된다.

관리자는 AI가 어떤 추가 업무를 만드는지도 살펴봐야 한다. 근거 검토, 권고안 수정, 통합 유지에는 모두 주의가 소모된다. 신뢰할 수 있는 생산성 평가는 생성된 결과물을 공짜 운영 역량으로 간주하지 않고 그 노력을 반영한다.

개발자에게 압박은 범위와 관련된다. 데모는 신중하게 선택한 질문과 예측 가능한 도구 응답으로 성공할 수 있다. 운영 서비스는 누락된 기록, 상충하는 근거, 사용할 수 없는 시스템, 호출자의 권한을 넘는 요청을 처리해야 한다.

이러한 상황은 기능과 유지 관리되는 역량의 차이를 드러낸다. 누군가는 각 도구의 의미, 정보의 최신성, 실패 시 동작을 책임져야 한다. 모델 선택만으로는 이러한 책임을 해결할 수 없다.

지식 관리 역시 이 운영 모델의 일부가 된다. 지원 권고안은 기술적으로 타당할 수 있지만 오래된 정책 문서와 충돌할 수 있다. 팀은 어떤 출처가 결정을 지배하는지, 그리고 누가 그 출처를 유지하는지 알아야 한다.

같은 조직적 문제는 엔지니어링 지식 베이스에서도 나타난다. 유용한 검색은 관련성 있고 유지 관리되는 자료를 찾는 데 달려 있다. 운영 에이전트는 검색된 정보가 제안된 시스템 변경에 영향을 줄 수 있으므로 또 다른 책임을 더한다.

이는 구체적인 구매 질문을 만든다. 공급업체는 더 나은 읽기와 쓰기 방식을 제공하는가, 아니면 정의된 조사를 완료하는 지원 방식을 제공하는가? 둘 다 가치가 있을 수 있지만, 서로 바꿔 쓸 수 있는 성공 기준을 가져서는 안 된다.

단기적으로 예상되는 영향은 더 까다로운 평가 과정이다. 구매자는 공급업체에 사례가 워크플로를 통과하는 과정을 보여주고, 종속성을 드러내며, 실패를 설명하도록 요구할 수 있다. 이는 챗봇 데모의 설득력보다 더 강력한 비교 기반이다.

AgentCore는 경계를 지우지 않고 도구를 연결한다

중요한 아키텍처 질문은 에이전트가 도구 주변의 규칙을 유지하면서 운영 도구에 어떻게 도달하는가이다.

AWS는 AgentCore Gateway를 에이전트와 도구 및 기타 서비스를 연결하는 액세스 지점으로 설명한다. 이는 에이전트가 도구를 발견하고 호출하는 표준 인터페이스인 Model Context Protocol, 즉 MCP를 지원한다.

문서는 해당 게이트웨이를 통해 기존 서비스 인터페이스와 기능을 노출하는 방법을 설명한다. 이는 연결 메커니즘을 확립한다. 하지만 그 자체로 특정 도구가 올바른 비즈니스 작업을 수행하는지를 확립하지는 않는다.

이러한 구분은 통합이 계속해서 이야기의 중심에 남는 이유를 설명한다. 표준 인터페이스는 도구를 더 쉽게 발견하고 호출하게 할 수 있다. 기업은 여전히 그 호출이 무엇을 의미하는지, 언제 유효한지, 결과를 어떻게 해석해야 하는지를 정의해야 한다.

“주문 확인”이라는 이름의 도구에는 모호함의 여지가 남는다. 가장 최근 주문을 반환하는가, 모든 미처리 주문을 반환하는가, 아니면 특정 채널의 주문만 반환하는가? 인터페이스 자체가 정의하지 않은 비즈니스상의 모호함을 에이전트가 안정적으로 해결할 수는 없다.

같은 문제는 실패 응답에도 적용된다. 누락된 기록, 거부된 요청, 사용할 수 없는 백엔드는 서로 다른 조건을 나타낸다. 도구가 이들을 빈 결과로 축소한다면, 다음 추론 단계는 오해를 부르는 근거에서 시작된다.

이는 AiDaH에 관한 추가 주장이라기보다 설계상 함의다. 에이전트를 기업 시스템에 연결하는 플랫폼에 대화형 계층 이상이 필요한 이유를 설명한다. 도구 경계의 품질이 조사의 품질을 결정한다.

AWS는 또한 게이트웨이 액세스와 다운스트림 서비스에 도달하기 위해 사용되는 자격 증명을 구분한다. 실무적으로 게이트웨이에 접근할 권한과 백엔드 작업을 수행할 권한은 신중한 구성이 필요하다. 구매자는 두 경계를 모두 검토해야 한다.

이는 인증과 권한 부여가 서로 다른 질문에 답하기 때문에 중요하다. 인증은 신원을 확립한다. 권한 부여는 그 신원이 특정 리소스에 대해 어떤 작업을 수행할 수 있는지를 결정한다. 식별 가능한 직원 신원이 있다고 해서 요청된 모든 조치에 대한 권한이 있다는 뜻은 아니다.

운영 에이전트에서는 이러한 구분이 요청 전체에 걸쳐 유지돼야 한다. 에이전트가 그럴듯한 지시를 구성할 수 있다는 사실이 백엔드가 이를 수락하는 이유가 되어서는 안 된다. 비즈니스 시스템은 작업 자체에 대해 강제 가능한 한계를 가져야 한다.

유용한 비유는 여러 애플리케이션에 접근 권한을 받은 서비스 데스크 직원이다. 공유 인터페이스는 탐색을 단순화할 수 있지만, 모든 애플리케이션의 권한을 하나로 합쳐서는 안 된다. 인터페이스의 편의성은 기본적인 책임 구조를 보존해야 한다.

표준 도구 연결은 평가 기회도 만든다. 구매자는 도구 정의, 허용되는 입력, 예상 출력, 오류 동작을 검토할 수 있다. 이러한 산출물은 대화 샘플과 함께 검토할 수 있는 구체적 자료를 제공한다.

따라서 더 넓은 메커니즘은 기술적이면서도 조직적이다. 에이전트 인프라는 재사용 가능한 연결을 제공할 수 있고, 기업 팀은 비즈니스 의미와 권한을 제공한다. 결과 시스템의 신뢰성은 이 계층들 사이의 관계만큼만 보장된다.

이 점에서 U Mobile의 에이전틱 운영은 통신업을 넘어 관련성을 가진다. 이전 가능한 질문은 공유 에이전트 인터페이스가 시스템 소유권을 명확히 유지하면서 조정 업무를 줄이는지 여부다. 연결된 도구의 카탈로그가 커지는 것은 그 도구들이 이해 가능하고 관리 가능하게 남아 있을 때만 유용하다.

Google과 One NZ는 경쟁이 향하는 방향을 보여준다

경쟁 비교는 운영 워크플로를 향해 이동하고 있지만, 서로 다른 배포 환경에는 여전히 서로 다른 측정 기준이 필요하다.

2026년 3월, Google Cloud와 Future Connections는 확장된 자율 네트워크 프레임워크를 설명했다. 발표에서는 데이터 중심 에이전트와 음성 네트워크 에이전트를 소개했으며, One NZ는 후자를 도입하고 있다.

Google의 설명은 네트워크 도메인 전반의 정보를 연결하고 이를 진단 및 시정 권고에 활용하는 데 초점을 둔다. 이는 한 아키텍처가 다른 아키텍처보다 우수하다는 독립적 증거가 아니라 공급업체가 보고한 역량이다.

이 비교는 잘못된 경쟁 구도를 만들지 않으면서 시장의 방향을 파악하는 데 도움이 된다. 고객 지원 조사와 네트워크 품질 관리는 서로 다른 도구, 위험, 결과를 수반한다. 티켓 감소를 네트워크 모니터링 결과와 직접 비교할 수는 없다.

두 접근 방식이 공유하는 점은 증거와 조치 사이의 거리를 줄이려는 시도다. 이 공통 목표는 공급업체가 추론 능력을 고립된 형태로 제시하기보다, 자사 시스템이 운영 프로세스에 어떻게 부합하는지 설명해야 한다는 압박을 만든다.

구매자에게 이는 워크플로 선택을 전략적 결정으로 만든다. 계정 조사를 목적으로 한 도입은 계정 조사 기준으로 평가해야 한다. 음성 품질을 겨냥한 도입에는 해당 운영 문제에 관한 증거가 필요하다.

이 구분은 구매 과정에 참여해야 하는 사람에게도 영향을 미친다. 대화형 인터페이스는 주로 직원 생산성 팀과 관련 있어 보일 수 있다. 운영 변경을 제안하는 시스템에는 애플리케이션 소유자, 보안 담당자, 서비스 결과에 책임을 지는 팀의 의견이 필요하다.

이처럼 폭넓은 참여는 조달을 더디게 만들 수 있지만, 더 나은 질문을 이끌어낼 수도 있다. 어떤 시스템이 권위 있는 증거를 제공하는가? 변경은 누가 승인하는가? 실행 전에 다른 작업이 같은 리소스를 수정하면 어떻게 되는가?

이 질문들은 모든 클라우드 제공업체에 적용된다. 에이전트의 모델 계열이 이를 해결해 주지는 않으며, 프로토콜 이름이 이런 문제를 없애지도 않는다. 구매자는 전체 워크플로가 상충하거나 불완전한 정보를 어떻게 처리하는지 공급업체가 보여주기를 기대해야 한다.

도입 범위와 운영 깊이 사이에도 차이가 있다. 또 다른 시나리오를 추가하면 적용 범위는 넓어진다. 기존 시나리오 내의 예외를 처리하면 새로운 대표 기능을 추가하지 않고도 신뢰성을 개선할 수 있다.

따라서 광범위한 도입은 기능 목록에서 더 발전해 보일 수 있지만 상당한 수준의 사람 개입을 요구할 수 있다. 반면 더 좁은 도입은 정의된 작업을 더 일관되게 완료할 수 있다. 공통된 결과 측정 기준이 없다면, 범위나 자율성 어느 쪽도 충분한 순위를 제공하지 못한다.

주목할 만한 경쟁은 재사용 가능한 운영 기반을 둘러싼 것이다. 플랫폼이 명확한 권한, 의미 있는 증거, 관리 가능한 지원 부담을 유지하면서 도메인을 추가할 수 있다면 확장성을 더 쉽게 평가할 수 있다.

반대로 새 도메인마다 광범위한 예외 처리가 필요하다면, 겉으로 보이는 플랫폼 우위는 더 면밀히 살펴볼 필요가 있다. 직원에게는 일관된 하나의 인터페이스가 보이더라도 통합 작업은 여전히 상당할 수 있다.

AiDaH를 지켜보는 독자에게 Google과의 비교는 승자를 가리키기보다 맥락을 제공한다. 여러 공급업체가 운영에 참여하는 시스템을 추진하고 있다. 이들의 다음 과제는 그 참여의 범위, 품질, 결과를 측정 가능하게 만드는 것이다.

티켓 감소에는 분모와 안전성 기록이 필요하다

티켓 수 감소는 고무적인 운영 신호지만, 인과관계를 입증하거나 모든 고객 결과를 측정하지는 못한다.

이 사례 연구는 개통 및 네트워크 티켓 84.5%, 일반 문의 81.6%, 청구 및 과금 48.7% 감소를 내부 측정 결과로 제시한다. 이는 모든 운영 전반의 총감소가 아니라 범주별 결과다.

독자가 그 규모를 평가하려면 공개된 비율에 뒷받침하는 맥락이 필요하다. 절대 건수는 대규모 운영 변화와 더 작은 범주에 적용된 큰 비율을 구분해 줄 수 있다. 비교 가능한 수요 데이터는 업무량 자체가 변했는지 판단하는 데 도움이 된다.

전후 비교는 다른 설명의 가능성도 남긴다. 프로세스 변경, 제품 수정, 계절성, 분류 관행은 모두 티켓 수에 영향을 미칠 수 있다. 이는 U Mobile의 보고에 대한 의혹이 아니라 측정 설계에 관한 질문이다.

고객 결과는 또 다른 필수 관점을 제공한다. 티켓으로 이어지지 않은 사례는 성공적으로 해결된 경우일 수도, 다른 곳에서 미해결 상태로 남은 경우일 수도 있다. 재접촉, 재개방, 완료 측정은 이러한 가능성을 구분하는 데 도움이 된다.

안전성 문제는 물량 문제와 별개다. 시스템은 업무량을 줄이면서도 때때로 부적절한 조치를 권고할 수 있다. 구매자에게는 생산성 증거와 함께 이러한 오류의 빈도와 결과에 관한 증거가 필요하다.

OWASP는 과도한 자율권을 AI 시스템이 불필요한 기능, 권한 또는 자율성을 보유할 때 발생하는 위험으로 설명한다. 권고 사항에는 제한적인 도구 접근, 최소 권한, 중대한 결과를 낳는 조치에 대한 승인이 포함된다.

이 프레임워크는 일반적인 비판적 관점을 제공할 뿐 AiDaH에 대한 판단은 아니다. 적절한 질문은 프롬프트가 모호하거나 검색된 자료에 오해를 유도하는 지시가 포함된 상황까지 포함해, 에이전트에게 허용된 행동이 의도된 작업과 일치하는지다.

사람의 승인도 마찬가지로 신중하게 평가할 필요가 있다. 검토자가 영향을 받는 리소스, 뒷받침하는 증거, 제안된 변경을 확인할 수 있다면 확인 절차는 실질적인 통제를 유지할 수 있다. 모호한 권고는 그러한 검토를 더 어렵게 만든다.

검토자는 조사 맥락을 잃지 않고 조치를 거부하거나 방향을 바꿀 수 있어야 한다. 그렇지 않으면 승인 인터페이스는 업무를 계속 진행하기 위해 단순히 수락을 유도하는 병목 지점이 될 위험이 있다.

이는 공개되지 않은 구현 세부 사항을 설명하는 내용이 아니라 평가 기준이다. 기업 구매자가 승인을 안전성의 충분한 증거로 보기 전에 무엇을 검토해야 하는지 보여준다.

Ericsson의 신뢰할 수 있는 통신 AI 분석도 도입에는 성능 측정 이상의 것이 필요하다고 주장한다. 신뢰성의 일부로 시스템 추적 가능성, 신뢰성, 보안, 책임성을 강조한다.

U Mobile의 에이전트 기반 운영에 대한 시사점은 명확하다. 생산성과 통제에는 병행하는 증거가 필요하다. 에스컬레이션 감소는 효율성 주장을 뒷받침할 수 있다. 신뢰할 수 있는 실행, 효과적인 검토, 복구 가능한 실패는 별도의 평가가 필요하다.

인용된 사례 연구만으로는 독립 감사를 거친 성능 비교가 확립되지 않는다. 독자는 보고된 결과를 진지하게 받아들이면서도 이 한계를 유지할 수 있다. 가장 유용한 후속 자료는 운영 개선과 그 한계를 더 쉽게 재현하고 검토할 수 있게 해줄 것이다.

해결 품질, 통제된 실행, 확장을 지켜봐야 한다

다음으로 유용한 증거는 운영 결과와 에이전트에 부여되는 권한 범위를 연결할 것이다.

향후 몇 달 동안 주목할 첫 번째 신호는 더 풍부한 해결 측정이다. 절대 티켓 건수, 업무량 맥락, 재접촉, 재개방 사례는 보고된 감소가 직원과 고객에게 무엇을 의미하는지 설명하는 데 도움이 된다.

에스컬레이션 감소가 지속적인 해결과 동시에 나타난다면 이러한 공개는 효율성 해석을 강화할 것이다. 업무가 단지 다른 곳으로 이동하거나 고객이 같은 미해결 문제로 반복해서 돌아온다면 그 해석은 약화될 것이다.

두 번째 신호는 통제된 실행에 관한 증거다. 독자는 완료된 조사, 제안된 변경, 승인된 변경, 성공한 변경 사이의 명확한 구분을 찾아야 한다. 각각은 운영 사슬에서 서로 다른 지점을 나타낸다.

오류, 개입, 복구에 관한 증거가 함께 제시된다면 더 자동화된 실행은 의미가 있을 것이다. 이러한 측정 없이 권한만 확대하면 기능 목록이 늘어나더라도 시스템 평가가 더 어려워질 것이다.

세 번째 신호는 추가 운영 도메인으로 확장하는 품질이다. 새로운 적용 범위는 중요하지만, 이를 유지하는 데 필요한 노력도 중요하다. 통합 작업과 지속적인 소유권에 관한 증거는 아키텍처가 계속 관리 가능한지 보여줄 것이다.

새 워크플로가 명확한 통제를 물려받고 비교 가능한 결과 증거를 생산한다면 확장은 플랫폼 주장을 강화할 것이다. 각각의 추가 요소가 제대로 이해되지 않은 예외나 해결되지 않은 책임을 초래한다면 그 주장은 약화될 것이다.

이러한 신호 어느 것도 출시일을 예측하거나 향후 발표를 만들어낼 필요가 없다. U Mobile, 그 파트너 또는 유사 운영자가 추가 결과를 공개할 때마다 독자가 평가할 수 있는 구체적인 공개 사항이다.

기업 팀에게 이는 다음 에이전트 발표를 읽는 실용적인 방법을 제공한다. 변경된 작업 단위에서 시작하고, 결과를 뒷받침하는 증거를 식별하며, 권한이 사람에서 소프트웨어로 이전되는 지점을 살펴보라.

이 글의 핵심 비교는 보조 조사와 연결된 운영 작업의 대비로 남는다. 진전은 더 적은 미해결 인계, 더 명확한 증거, 정의된 범위 내에서 신뢰할 수 있는 조치로 나타나야 한다. 그러한 결과 없이는 더 자율적이라는 명칭이 큰 의미를 더하지 못한다.

U Mobile의 에이전트 기반 운영을 직접 평가하려면 초기 요청부터 검증된 해결까지 대표 사례 하나를 따라가 보라. 에이전트가 어떤 정보를 수집했는지, 어떤 권고에 검토가 필요했는지, 승인된 조치가 효과가 있었음을 시스템이 어떻게 확인했는지 질문하라. 직원 검토 노력과 이후의 재접촉을 포함해 이 과정을 이전 워크플로와 비교하라. 누락된 증거나 거부된 권고가 한계를 더 분명히 드러내는 실패 사례에도 같은 수준의 검토를 적용하라. 그런 다음 실용적인 질문을 던져라. 이 플랫폼은 고객의 문제를 해결된 상태로 남기며, 조직이 무슨 일이 있었는지 설명할 수 있게 하는가? 그것이 다음 도입 업데이트에서 찾아야 할 증거다.