제3자: 마이크로소프트 지원 쇼 – DSE가 마이크로소프트 지원 서비스를 가속화하는 방법 (6화).

좋은 질문입니다. 엔터프라이즈 아키텍트 매니저로서 저희 팀은 여러 기관에서 오랫동안 제공해 온 서비스들을 검토한 끝에 '지정 지원 엔지니어(DSE)'를 도입했습니다. 이들은 엔터프라이즈 아키텍트이지만 지원 엔지니어 역할을 수행하며, 고객에게 최상의 서비스를 제공합니다. 저희 목표 중 하나는 고객과의 관계를 구축하는 것입니다.

그것이 우리에게 중요한 이유는, 예를 들어 여러분이 휴대폰 통신사에 전화해서 지원을 받을 때, 어떤 상담원을 만나게 될지 모르는 경험을 해보셨을 테니까요. 때로는 좋은 상담원을 만나기도 하지만, 때로는 같은 상황을 반복해서 설명해야 할 때도 있습니다. 그리고 다음 날 다시 전화하면, 어쩌겠어요? 또 다른 상담원과 통화하게 되죠. 그 모든 이야기를 처음부터 다시 시작해야 합니다.

가능하다면 고객에게 그런 경험을 주고 싶지 않았습니다. 어떻게 해야 할까요? 우리는 고객 조직의 일부가 됩니다. 바로 DSE 역할이 그것입니다: 그들은 고객을 위해 해당 기술을 소유하고 그에 관한 모든 것을 알고 있습니다.

그 책임의 일부는 티켓에 내부 메모를 남겨두는 것입니다. 그러면 엔지니어들이 심각도 1, 2, 3, 4 수준의 장애/수리 티켓을 열 때, 해당 기술에 정통하고 모든 것을 알고 있는 DSE(기술 지원 담당자)가 배정되어 있다는 점이 명확해집니다. 따라서 엔지니어들은 많은 초기 준비 작업을 생략할 수 있습니다. 여기에는 다음과 같은 질문들이 포함될 수 있습니다: "배경 상황은 어떤가요? 과거 상황은 어땠나요? 이런 문제를 유발했을 환경적 요인은 무엇인가요?"

우리 엔지니어들이 이러한 책임감을 바탕으로 격차를 해소하고 도움을 줄 수 있다는 점이 좋습니다. 때로는 기술에 매우 정통하여 추가적인 아이디어를 제시할 수 있기 때문이죠. 이는 순수한 사후 대응 서비스가 사전 대응 서비스에 의해 지원되는 형태입니다: 해당 환경을 이미 숙지한 다른 전문가로부터 배우고, 고객이 같은 설명을 반복해야 하는 상황을 방지하는 것이죠.

우리가 가진 또 다른 주요 목표는 현재 기술이 극도로 융합되어 있다는 현실과 관련이 있습니다. 마이크로소프트가 고속도로를 만들지 않아서 정말 다행입니다. 차선이 없으니까요—모든 차량이 충돌할 테니까요. 이렇게 수많은 '차량'들이 충돌하는 상황에서, SQL을 아는 기술자가 있다면 해당 시스템의 문제가 Intune으로 넘어갈 수 있고, 그 문제가 Azure나 M365로도 번질 수 있습니다. 그러면 문제가 완전히 뒤섞이게 되죠. 즉, 처리 중인 문제나 기술, 업그레이드, 사전 예방적 서비스의 80%는 SQL과 관련될 수 있습니다. 나머지 20%는 다른 어떤 것이든 될 수 있죠.

미국 클라우드 업계에서는 흔한 일이지만, 다른 조직들—저는 컨설팅 업계에서 40년을 일해왔습니다—에서는 흔치 않습니다. 정말 좋은 점은, 제가 말씀드렸듯이, 대응형 서비스와 사전 예방형 서비스를 통합하여 고객에게 완벽한 솔루션을 제공한다는 것입니다. 고객사가 마이크로소프트 관련 문제의 나머지 20%를 해결하기 위해 다른 기술 전문가의 도움이 필요할 경우, 저희는 SQL, SharePoint, Power BI 등 해당 티켓 해결에 필요한 모든 분야의 기술자를 투입합니다. 저희가 모두 해결해 드립니다.

지난주에 한 번 있었어요. 포춘 100대 기업 중 아주 큰 기업의 CEO—아마 100보다 낮은 순위의 기업일 거예요—가 팀즈 회의에서 프레젠테이션을 하고 있었죠. 회의에는 80명 이상의 최고 경영진들이 참석했습니다. 그런데 발표 중이던 우리 고객사가 회의에서 강제로 퇴장당했습니다. 이는 좋지 않은 인상을 남겼습니다. 즉, 팀즈 회의 내 누군가가 발표자를 퇴장시킬 권한을 가졌다는 뜻이니까요.

이는 조직 내 잘못된 설정 때문이었으며, 당시 조직에 전달된 메시지와 타이밍이 문제였습니다. 결국 CEO가 팀즈 회의에서 쫓겨났고, 이는 매우 좋지 않은 모습으로 비쳤습니다.

따라서 그들은 Sev. 1 사례를 열었습니다. 팀즈(Teams) 관련 DSE(주 담당자)가 있었습니다. 그래서 해당 내부 메모("로브, 이 기술에 대한 우리 DSE가 누구지? 그에게 연락하는 게 좋을 것 같아.") 때문에 수리/복구 담당자가 팀의 DSE에게 알렸습니다.

그는 전화 회의에 참여하자마자 30분도 채 되지 않아 상황을 분석하고 정확히 무엇이 잘못되었는지 파악한 뒤, 향후 같은 일이 재발하지 않도록 방지 정책을 수립하도록 지원했습니다. 이제 CEO가 발표 중일 때 다른 사람이 그를 회의에서 강제로 퇴장시킬 이유가 전혀 없습니다.

해당 과정 전체가 매우 빠르게 진행되었는데, 이는 환경의 복잡성 수준, 문제의 성격, 그리고 문제 해결에 참여한 주체들 때문이었다.

고객은 또한 마이크로소프트가 이 문제를 검토해 주길 원한다고 결정했습니다.

마이크로소프트는 우리의 분석(이미 완료된 상태), 프로젝트 계획, 해결 방안 진행 방식을 검토한 지 10분 만에 답변을 주었습니다. 마이크로소프트 소속 전문가들은 직접 이렇게 말했습니다. "우리가 다르게 할 것은 없습니다. 바로 이렇게 처리해야 합니다."

해당 문제를 매우 신속하게 처리하여 고객과 다시 통화를 연결하고, 전체 문제를 해결한 후 향후 재발 방지를 확실히 했습니다. 이러한 민첩한 대응과 해결은 DSE의 헌신 없이는 불가능했을 것입니다.

네—이런 일은 매일 발생하니 드문 일이 아닙니다! 티켓이 접수되고 엔지니어가 고객과 처음 통화를 할 때 많은 데이터 수집이 이루어집니다. 그들은 다음과 같은 질문을 할 것입니다: "고객님의 상황을 알려주세요. 왜 저희에게 연락하셨나요? 무슨 일이 발생했나요? 환경은 어떤 상태인가요? 몇 명의 사용자가 영향을 받았나요?" 그들은 이 모든 과정을 거치게 됩니다.

다시 말해, 내부 메모 덕분에 DSE가 호출되어 기술 담당자에게 배경 정보를 제공할 수 있습니다. 이로 인해 문제 해결 범위를 좁히는 데 큰 도움이 되어 티켓이 해결 프로세스를 시작하는 데 걸리는 시간을 단축할 수 있습니다.

그건 마치 당신과 제가 막 대화를 시작한 사이인데, 우리 가족들이 함께 시간을 보내기로 계획하는 상황과 같아요. 당신에게 아이가 몇 명인지, 우리가 함께 무엇을 할지도 모르지만—그래도 그런 질문들을 꼭 해야 해요.

음, 내가 당신을 더 오래 알고 지낸 친구를 통해 이미 딸이 없다는 걸 알고 있다고 치자. 그러니까 딸들이 좋아하는 활동에 관한 질문은 할 필요가 없겠네. 그냥 질문의 수를 절반으로 줄여서 아이들 놀이 약속을 어떻게 잡을지 결정하는 데 도움을 주려는 거야.

그러니까 딸이 몇 살인지, 뭘 좋아하는지 같은 쓸데없는 질문들을 잔뜩 할 필요는 없겠네요. 당신의 오랜 친구는 고객에게 있어서 DSE(디지털 서비스 전문가)와 같습니다. 고객의 디지털 환경과 IT 인프라를 더 잘 이해하는 전문가로서, 고객의 성공을 돕는 방법에 대한 논의에 새로 참여한 이들을 지원할 수 있죠.

당신의 오랜 친구(이 시나리오에서 DSE)가 당신에게 12살짜리 아들이 야구광이라고 말해줬다고 가정해봅시다. 제가 당신과의 대화에 참여할 때쯤이면, 우리는 이미 그 질문들을 다시 좁혀가고 있는 셈입니다. 그렇게 하면 아들이 축구를 좋아하는지 야구를 좋아하는지에 대한 이야기를 더 줄일 수 있죠. 아들이 진짜로 필요한 것이 무엇인지 바로 파악할 수 있습니다.

DSE에서 얻을 수 있는 것들은 모두 그런 것들이고, 이제 진짜 필요한 게 뭔지에 대한 이야기로 바로 넘어갈 수 있겠네요. 타격 시 타점을 올리는 데 도움을 줄 코치가 필요한 걸까요? 만약 그렇다면, 플레이데이트에 배팅 티를 가져가지 않을 거예요. 아이가 전혀 필요로 하지 않을 테니까요.

DSE 덕분에 우리는 문제의 핵심으로 바로 접근할 수 있으며, 배경 설명에만 국한된 대화를 피할 수 있습니다. 배경 이야기는 훌륭하지만 당면한 과제를 해결해주지는 않습니다. DSE는 환경에 대한 깊은 이해를 바탕으로 문제 해결 팀이 여러 가지 가능성을 배제하는 데 도움을 줄 수 있습니다.

문제 해결을 해본 적이 있다면, 전문가들이 해결책을 찾기 위해 문제를 좁혀가는 데 많은 시간을 할애해야 한다는 것을 알 것입니다. DSE는 우리가 그 과정을 훨씬 더 빠르게 좁혀갈 수 있도록 도와줍니다.

현재 마이크로소프트의 에스컬레이션 지원 방식은 여러 조직을 활용하는 것을 포함하며, 개인정보 보호법으로 인해 해당 정보를 공유하는 것이 종종 허용되지 않습니다.

예를 들어 지원 직원이 근무를 마치고 시계가 5시가 되었다면, 해당 에스컬레이션 티켓을 다른 공급업체로 넘기게 될 수 있습니다. 그러나 개인정보 보호 문제로 인해 첫 번째 공급업체로부터 일부 데이터를 확보할 수 없게 되는데, 이는 어느 쪽도 마이크로소프트 직원이 아니기 때문입니다.

모두 "V-Dash"로, 이는 "벤더(vendor)"를 의미하며 해당 직원들에게 티켓에 대한 벤더 수준의 접근 권한만 제공합니다.

저희 직원들은 모두 US Cloud 소속이므로 저희 측 절차는 매우 간단합니다. US Cloud를 통해 티켓을 열면 DSE 담당자나 문제 해결 담당자와 상담하게 됩니다.

그리고 이들은 모두 서로 대화하고 데이터를 공유할 수 있으며, 암호화되고 종단 간(endpoint-to-endpoint)으로 안전한 방식으로 이루어집니다. 우리 기술자들은 개방적이고 자유롭게 소통할 수 있습니다.

그리고 티켓 해결을 지원하기 위해 인력을 투입해야 할 경우, 엔터프라이즈 아키텍트 수준의 전문가를 동원하여 전체적인 그림을 파악하고 조각들을 조합할 수 있습니다. 때로는 매우 복잡하여 서로 다른 분야의 여러 전문가들이 함께 해결책을 모색해야 할 때도 있습니다. 고장 수리 티켓은 이제 거의 명확한 경우가 없으며, 여러 기술과 문제가 복합적으로 얽혀 있습니다. 우리는 이러한 팀들을 투입할 역량을 갖추고 있습니다.

다른 벤더들은 해당 분야를 통합하지 못해 에스컬레이션 처리 시 상당한 시간이 소요됩니다. 그들은 일종의 틀에 박히고 사일로화되어 있죠. SQL 담당자가 자신의 업무를 처리한 후 티켓을 SharePoint 담당자에게 넘기면, 그 담당자는 자신의 작은 부분을 처리하고 Power BI 담당자에게 넘기는 식으로 이어집니다.

한편, 시간이 계속 흘러가고 있는데도 여전히 문제가 해결되지 않고 있잖아요? 상황이 진전되지 않고 있어요. 정말 답답합니다. 좋은 경험이 아니며, 엔지니어들이 전환 시점을 파악하기가 매우 어렵습니다. 스스로에게 "SQL에서 SharePoint로, 다시 Power BI로 언제 전환해야 하지? 언제쯤 끝나는 거지?"라고 자문해야 하는 상황입니다.

그리고 누가 실수를 했는지(의도치 않았지만 여전히 비난이 오가는) 서로를 탓하는 일이 많습니다. 그들은 '아마도'라는 표현을 사용하는데, 이는 고장 수리 요청을 처리할 때 문제 해결과 해결책 마련에 전혀 도움이 되지 않습니다.

내가 고객이라면, 나는 확실한 답변을 원한다. 나는 답을 원하며, 바로 시작하고 실행에 옮기고 싶다.

그래서 우리는 세 가지 영역을 다루게 되었습니다. 그중 하나는 프로젝트 자문 서비스입니다 . 고객은 마이크로소프트 제품 관련 질문을 가지고 저희에게 찾아와 전문가의 도움을 받을 수 있습니다. 질문 내용은 전문적인 조언이 필요한 모든 사항이 될 수 있습니다. 예를 들어 인터페이스에 새로 생긴 버튼, 마이크로소프트가 시행한 새로운 정책으로 인해 특정 기능이 중단될 예정이라는 공지, 또는 일정 기간 내에 업그레이드해야 하는 사항 등이 포함됩니다.

우리는 클라우드를 소유하지 않고 단지 임대할 뿐입니다. 따라서 임차인인 우리는 '집주인'이 언제든지 "다음 주에 벽을 보라색으로 칠할 거야. 준비해 둬"라고 말할 수 있다는 점을 감안해야 합니다.

그래서 우리는 "아직 준비가 안 됐어요! 벽에 그림이 걸려 있어서 보라색으로 바꿀 수 없어요"라고 말하죠. 그러면 고객들이 우리에게 와서 묻습니다. "이걸 걱정해야 하나요? 벽을 보라색으로 칠하면 저에게 영향이 갈까요? 무슨 일이 생길까요?"

그것을 우리는 프로젝트 자문 티켓이라고 부릅니다. 고객은 단순히 질문을 주고받을 필요가 있을 수도 있고, 아니면 계획을 가지고 있을 수도 있습니다. 우리는 나서서 준비를 도울 수 있습니다: "이렇게 진행하겠습니다. 못을 제거하고, 스패클을 발라 메울 겁니다. 그런 다음 마이크로소프트에서 와서 보라색으로 칠할 수 있습니다."

그런데 우리는 어떻게 대비해야 할까요? 우리가 놓친 부분이 있을까요? 예를 들어, 페인트칠할 때 바닥용 방수포가 없다면 벽은 보라색이 될 뿐만 아니라 바닥 일부도 보라색이 될 것입니다. 페인트가 흘러내리거나 떨어지기 때문이죠. 바로 이런 과정들을 프로젝트 자문을 통해 고객이 해결할 수 있도록 돕는 것입니다.

컨설팅 서비스에서 다음으로 진행하는 것은 본격적인 프로젝트 배포입니다. 여기서 프로젝트란 해결하는 데 15시간 이상 소요되는 모든 작업을 의미합니다. 예를 들어 300대의 서버를 업그레이드하는 작업일 수도 있고, 마이그레이션이나 인수합병을 수행하는 경우일 수도 있습니다. 인수합병 시 실제 합병 작업을 진행하고 이메일 주소를 변경하며 데이터를 양측 간에 이동시키는 등의 작업을 수행합니다.

15시간 이상 소요되는 프로젝트의 경우 비용이 수천 달러에 달할 수 있습니다. 이는 해당 조직의 규모와 US Cloud의 지원이 얼마나 필요한지에 따라 달라집니다.

프로젝트 작업 시에는 직접 참여하여 전폭적인 지원을 제공합니다. 일반 직원 기록이 아닌 컨설팅 기록을 작성합니다.

우리는 프로세스 운영을 지원할 수 있는 전문 인력을 보유하고 있습니다. 종종 시간이 부족해지는 경우가 있기 때문이죠. 관리자에게 "금요일까지 완료하겠다"고 약속했지만, 시간이나 해당 업무를 수행할 전문 인력이 부족해 금요일까지 마치지 못할 때도 있습니다. 대규모 프로젝트의 경우 여러 사람의 협력이 필요하기 때문에 추가 인력이 필요한 경우가 있습니다. 저희는 기술 컨설턴트와 엔터프라이즈 아키텍트들이 나서서 이를 수행할 수 있습니다.

그들은 말 그대로 직접 손을 대고 여러분 팀을 위해 일할 수 있습니다. 제가 컨설팅 로그라고 말하는 이유는, 아시다시피 우리는 많은 테스트와 파일럿을 진행하지만 가끔 예상치 못한 변수가 발생하기 때문입니다. 계정 내에 뭔가 다른 점이 있거나 조직 내에서 진행 중인 일이 있는데, 새로운 프로세스를 실행하기 전까지는 아무도 이를 다루지 않았던 경우가 있죠. 그런 경우 우리는 즉시 방향을 전환하여 즉석에서 해결할 수 있습니다.

저희 컨설팅 서비스의 마지막 단계는 앞서 언급한 바와 같이 DSE입니다. DSE는 고객사가 팀의 연장선으로 완전히 통합될 수 있도록 맞춤형 프리미엄 서비스를 제공하는 저희의 세 번째 솔루션으로, 고객에게 매우 만족스러운 경험이 됩니다.