지원 티켓 30% 감소의 배경: Microsoft ESS 에이전트는 정확도보다 신뢰를 먼저 배웠습니다
AI 헬프데스크가 정확한 답을 빠르게 주는데도 직원들이 사용하지 않는다면, 모델이나 답변 품질만 개선하면 될까요? Microsoft의 내부 경험은 그보다 넓은 문제를 보여줍니다. 직원들은 에이전트가 자신이 이미 시도한 일을 이해하는지, 해결하지 못하면 어디로 연결되는지를 함께 판단했습니다.
Microsoft Digital은 2025년 가을 30만 명이 넘는 직원과 contingent staff에게 Employee Self-Service(ESS) Agent를 출시했습니다. 초기에는 정확도, 응답 품질, 기술 성능에 집중했지만 기대보다 약한 도입 결과를 보고 사용자 연구를 진행했습니다.
그 연구에서 드러난 핵심은 신뢰였습니다. 이 글은 Microsoft의 ESS 운영 사례를 바탕으로, 한국 조직의 IT·HR·사내 서비스 담당자가 AI 지원 경험을 설계할 때 무엇을 바꿔야 하는지 설명합니다.
도입은 기능 문제가 아니라 사람의 문제이기도 합니다
Microsoft는 Wipro의 전략 디자인 조직인 Designit과 함께 정성 연구, UX 설계, 도입 분석을 수행했습니다. 여러 지역의 직원 인터뷰·포커스 그룹, 피드백 분석, 지원 workflow와 에이전트 상호작용을 살폈습니다.
직원들은 단순히 “답이 맞는가”만으로 서비스 방식을 고르지 않았습니다. 감정, 기대, 습관, 이전 지원 경험도 선택에 영향을 줬습니다.
스프레드시트나 티켓 시스템에서는 사용자가 기계를 조작한다는 명확한 모델이 있습니다. 반면 에이전트와는 대화하고 추가 설명을 주고받습니다. 따라서 기술적으로 유능한 것만으로는 충분하지 않고, 상황을 이해하고 시간을 존중하는 상호작용이 필요했습니다.
직원은 에이전트를 열기 전에 이미 여러 일을 했습니다
연구에서 중요한 발견은 지원에 들어오기 전의 맥락이었습니다. 많은 직원이 동료에게 물어보고, 문서를 찾아보고, 기존 도구와 자체 문제 해결을 시도한 뒤 ESS를 열었습니다.
그런 직원에게 이미 해 본 조치를 반복 권하면 좌절감이 커집니다. 에이전트의 개별 답변이 일반적으로 맞더라도 전체 지원 여정에서는 도움이 되지 않을 수 있습니다.
Microsoft는 사용자 맥락을 알려진 장애·문제와 연결하고, 상황에 맞는 자가 해결을 제시하며, 필요하면 사람 상담원에게 원활하게 연결해야 한다고 설명합니다. 지원 채널 사이에서 맥락이 사라져 처음부터 설명해야 하는 상황도 신뢰를 떨어뜨립니다.
“해결 못 하면 사람에게 연결해 드립니다”를 명확히
직원이 가장 불안해하는 지점 중 하나는 자가 해결의 막다른 골목에 갇히는 것입니다. ESS가 해결하지 못하면 live agent로 연결한다는 점을 알리면, 직원이 처음부터 에이전트를 찾아올 이유가 생깁니다.
Microsoft의 원칙은 자가 해결을 강요하는 것이 아닙니다. 처음에는 다른 지원 수단으로 가는 신뢰할 수 있는 입구로 사용해도 괜찮습니다. 적절한 도움을 꾸준히 제공하고, 도움이 되지 않을 때 신속하게 연결하면 직원이 경험을 바탕으로 자가 해결을 선택하게 된다는 접근입니다.
연구 결과를 구체적인 에이전트 행동으로 바꾸기
연구팀은 신뢰가 깨지는 상황과 그때 필요한 행동을 짝지었습니다.
| 신뢰를 떨어뜨리는 상황 | 설계 방향 |
|---|---|
| 같은 문제 해결 절차를 반복하는 루프 | 이미 시도한 조치를 인정하고 다음 경로를 제시 |
| 직원의 상황과 동떨어진 답변 | 사용자의 맥락과 알려진 장애·문제를 연결 |
| 답변에 확신이 부족한 상황 | 한계와 불확실성을 명확하게 전달 |
| 사람에게 연결할 시점이 불명확 | 연결 가능 여부와 다음 단계를 설명 |
| 채널 이동 시 맥락 소실 | 전체 지원 여정의 연속성을 고려 |
원문은 ESS의 성격과 상황별 행동 지침도 정의했다고 설명합니다. 이는 단순히 친근한 말투를 추가하는 작업이 아니라, 직원의 실제 필요에 맞는 지원 행동을 테스트하고 개선하는 일입니다.
한국 조직에 적용한다면 “이미 재부팅하고 VPN도 다시 연결했습니다” 같은 요청에서 같은 조치를 다시 강요하지 않는지, 에이전트가 해결하지 못한 경우 연결 절차를 설명하는지 점검할 수 있습니다. 이 예시는 원문의 설계 원칙을 적용한 제안입니다.
Microsoft가 보고한 결과와 해석 범위
| 지표 | 원문의 내부 운영 결과 |
|---|---|
| 생성되는 IT 지원 티켓 | 전체적으로 30% 감소 |
| 지원 여정을 에이전트로 시작하는 직원 비율 | 신뢰 구축 활동 전 27%에서 50%로 증가 |
| 초기 출시 대상 | 2025년 가을, 직원·외부 인력 합계 30만 명 이상 |
27%에서 50%로의 변화는 23%포인트 상승입니다. 30%는 IT 지원 티켓 생성 감소이지, 모든 직원 문제의 해결률이나 인력 감축률이 아닙니다.
원문은 연구와 설계 변경 뒤의 내부 성과를 보고하지만, 통제 실험이나 상세 측정 기간·산식을 제시하지 않습니다. 다른 회사에서 같은 수치가 나온다고 보장하거나, 신뢰 설계 하나만으로 모든 감소가 발생했다고 단정해서는 안 됩니다.
도입 담당자가 확인할 체크포인트
정확도와 응답 속도는 여전히 기본 요건입니다. 여기에 다음 항목을 더해야 합니다.
- 직원이 에이전트 사용 전·중·후에 무엇을 하는지 연구합니다.
- 사용자가 이미 시도한 조치를 인식하고 존중하도록 설계합니다.
- 할 수 있는 일, 한계, 사람 연결 방식을 처음부터 명확히 안내합니다.
- 반복 루프, 맥락 소실, 불명확한 다음 단계 같은 신뢰 저하 상황을 평가합니다.
- 직원의 피드백이 실제 개선에 반영됐음을 알려 피드백 루프를 닫습니다.
- 첫 사용뿐 아니라 자발적 재사용과 지원 시작 경로를 측정합니다.
제품의 일반 기능 목록보다 직원이 일을 계속할 수 있게 해주는 지원 경험의 연속성을 목표로 삼는 것이 원문의 메시지입니다.
ESS 소개 영상
원문이 연결한 Employee Self-Service Agent 소개 영상입니다. 신뢰 구축 연구 자체의 실험 영상이라고 단정하지 않고, ESS 경험을 이해하는 참고 자료로 활용하면 됩니다.
마무리: 직원이 선택하는 첫 지원 창구를 만드세요
AI 지원의 성공은 사용자를 자동화 경로에 묶어두는 것이 아닙니다. 자신이 겪는 문제를 이해하고, 이미 들인 노력을 존중하며, 필요할 때 사람에게 이어주는 경험이라면 직원이 자연스럽게 다시 찾아올 수 있습니다.
이 글은 Microsoft 내부 도입 사례이며 새 GA·프리뷰 출시 공지가 아닙니다. 우리 조직에서는 제품의 지원 조건과 도입 준비 자료를 별도로 확인하되, 성공 기준은 “에이전트를 배포했다”가 아니라 직원이 믿고 시작하며 다시 사용하는가로 잡는 편이 좋습니다.
출처: Microsoft Inside Track Blog, Building trust in AI-powered support at Microsoft: Our Employee Self-Service agent story.
자세한 내용은 원문 참조.