기고 | 클라우드 애플리케이션 '지원에 대한 참고사항'

기업 내 헬프데스크는 지난 수십 년간 현업 사용자의 애플리케이션 관련 지원 업무를 수행해왔다. 그러나 클라우드 앱들이 등장하면서 양상은 바뀌고 있다. 여기 클라우드 시스템 지원과 관련해 참고할 만한 조언를 공유한다.

클라우드 컴퓨팅은 이를 사용하는 기업과 IT 모두에게 많은 전략적 자유와 장기적인 탄력성을 제시한다. 기존의 기업용 애플리케이션으로는 불가능했던 부분들이다. 그러나 배치 규모가 클 경우 예측성이 떨어지는 문제가 발생한다. 또 지원을 위해 새로운 요건이 일부 필요하기도 하다.

필자가 끊임없이 강조했듯, CRM 애플리케이션은 다른 기업용 애플리케이션과는 다르다. 사용자의 습관과 필요 때문에 그렇다. 일반적으로, 세일즈 및 마케팅 담당자들은 프로세스 원칙이나 데이터 품질 같은 소소한 세부 사항보다는 (외관이나 실제 모두에 있어) 성과에 더 높은 우선순위를 부여한다. 또 시장 경쟁 환경의 변화와 세일즈 모델의 발전도 함께 고려하는 특성을 가지고 있다. 따라서 상당한 수준의 변화를 더 자주 수용해야만 하는 시스템을 원한다.

클라우드와 CRM을 결합하면 내부 지원 부서들이 일부 스트레스를 받을 수 있다. 세일즈 영역이 분리되거나 협력업체를 재정립해야 한다면, 리드 라우팅(Lead Routing)과 계정 소유권, 기회 검증 규칙을 재빨리 바꿀 필요성이 제기되기 마련이다.

이러한 변화들은 문제 발생을 초래할 수 있다. 그리고 문제가 잠복해 있다면, 수백 건의 주문을 잘못 처리하기까지 문제를 알 수 없을 수도 있다.

기존의 헬프 데스크 인프라스트럭처는 이런 고차원적인 문제를 해결하지 못한다. 이렇게 되면 정치적인 대화가 오고 가다 서로를 비난하는 상황이 초래되는 경우도 많다. 따라서 클라우드 시스템을 지원하기 위한 베스트 프랙티스를 살펴볼 필요가 있다.

• 모든 건 아키텍처와 설정 관리로부터 비롯된다. 클라우드 CRM에서 진짜 두려운 문제들은 CRM 시스템이라는 좁은 범위에서는 발생하지 않는다. 회계나 주문 처리, 이커머스(E-commerce), 포털, 또는 그 밖의 다른 고객 대면 애플리케이션과의 통합점에서 문제가 발생한다.

CRM 시스템에서는 무언가를 바꾸기가 말 그대로 몇 시간이면 가능할 정도로 간단하다. 하지만 반드시 그렇게 하란 법도 없고, CRM의 변경 내용이 다른 시스템으로 정확히 전파된다는 보장도 없다. 따라서 코드와 데이터 모델, 더 나아가 피크리스트 값의 의미를 바꿨을 때의 결과를 살펴보는 설정 관리 프로세스가 필요하다.

이는 골치거리가 될 수 있다. 대규모 클라우드 배치에 대한 관리 센터가 없기 때문이다. 애플리케이션마다 컨트롤 패널과 대시보드가 있다. 그러나 SME 패널을 통해서 인터페이스와 매시업 전반에 걸친 변경에 따른 결과를 측정할 수 있어야 한다.

• 관찰이 가능해야 한다. 최상의 조건에서도 애플리케이션 전반에 걸친 문제를 해결하기란 까다롭다. 클라우드의 헐거운 결합 때문이다. (이는 클라우드의 장점이기도 하다.) 따라서 개발 초기에 오류 처리와 생산을 위한 사용 동안 진단 기록을 쓰는 로깅 클래스(Logging classes)를 준비해둬야 한다. 애플리케이션마다 로깅을 보충하기 위해 중앙 클라우드 서비스에 오류 로그를 보관해야 한다.

• 매끄럽게 배치해야 한다. 클라우드 컴퓨팅은 상대적으로 새로운 기술이다. 특히 산업용 기반은 진행 중인 기술이라고 할 수 있다. 수작업으로 스크립트와 체크리스트를 준비해 배치를 해야 하며, 항상 발전할 수 있도록 세부 사항을 준비해야 한다. 버그 패치이든 애자일(Agile) 릴리즈 사이클이든, 프로세스는 반복 가능해야 하며, 신뢰할 수 있어야 하는 동시에, 가능한 간소화되어 있어야 한다.

• 클라우드 설계와 도입, 배치에 있어서의 문제들과 관련해 공개된 정보가 있을 것이다. 특정 클라우드 벤더가 이 모든 정보를 제공하지는 않는다. 따라서 여기 저기서 정보를 수집해 결합해야 한다. 클라우드 애플리케이션과 관련된 세부사항을 개별적으로, 그리고 집합적으로 문서화 해야 한다.

지원 팀은 이 밖에도 표준 테스트 사례와 예상 결과, 알려진 문제들에 대한 해결책을 필요로 하게 될 것이다. 위키(Wiki), 구글 독스, 공유 폴더 중 무엇을 사용하던 간에, 누구나가 문서를 참조할 수 있어야 한다. 또 모든 IT 팀원들은 이런 문서를 실시간으로 업데이트할 수 있어야 한다. 또 정보는 명료해야 한다. 협력해 문제를 푸는데 도움이 되기 때문이다. 분명하지 않다면 문서화를 하지 말아야 한다.

• 민첩한 부서로 자리매김해야 한다. CRM 설정이나 데이터에 버그가 있으면 여러 것들이 틀어질 수 있다. 이 경우 지원팀은 빠르게 협력해 작업을 해야 하며, 매일 작업을 분류하고 우선순위를 정하는 회의를 가져야 한다.

그리고 이런 회의에는 똑똑한 QA 담당자를 참여시키는 것이 좋다. 문제 해결 과정을 지원할 수 있고, 고장을 처리하는 일정을 수립하는 역할을 하기 때문이다. 사실 제대로 된 회의를 매일 10분씩 갖는 것도 쉽지만은 않다. 특히 내부 지원 팀이 1개 국가 이상을 책임지고 있다면 더욱 그럴 것이다.

• 우선순위를 매기는 것이 가장 중요하다. 지원과 관련해 가장 난감한 문제들은 일정이 급박할 때 발생하는 경향이 있다. 따라서 정말 중요한 소수의 문제에 집중해 잡음을 피해야 한다. 버그에 대한 우선순위와 심각성을 처리하는 전통적인 방식 뿐 아니라, 조직에 영향을 미치는 피크리스트, 클라우드 시스템에 영향을 미치는 피크리스트, 재 업무가 필요한 주문과 관련된 수치 매트릭스를 사용한다.

이들 중 일부 경우에는 새로운 업무 처리방식이 필요할 수도 있다. 하지만 일반적으로 기존 지원 부서에 이관이 가능하다. 결론을 내리자면 정말 중요한 사항에 한층 효율적으로 대응하는 것이 중요하다. 여러 시스템에 확산되어 있는 문제의 경우에도 마찬가지이다. 또 비용 증가를 피해야 한다.

*David Taber는 '세일즈포스닷컴 성공의 비밀'의 저자이자 세일즈로지스틱스의 CEO다. ciokr@idg.co.kr