Sun이 남긴 질문: 기술이 뛰어나도 고객의 전화는 받아야 합니다

핵심 요약

• Sun은 Java와 Solaris 같은 기술을 남겼지만 2010년 Oracle에 인수됐습니다.
• Sun의 흥망을 고객 지원 문제 하나로 설명할 수는 없습니다.
• 기업 고객에게는 제품 성능만큼 장애 대응과 후속 조치도 중요합니다.
• 뛰어난 엔지니어가 있어도 꾸준히 고객을 지원하려면 조직이 뒷받침해야 합니다.

새로운 기술을 고를 때는 성능과 기능부터 눈에 들어옵니다. 하지만 업무가 멈추면 “얼마나 빠른가”보다 “누가 연락을 받고 해결해주는가”가 급해집니다. Sun Microsystems의 역사를 돌아볼 때도 두 질문을 함께 떠올려볼 만합니다. 기술이 뛰어나다는 평가만으로는 회사의 앞날까지 알 수 없기 때문입니다.

Java를 만든 회사도 독립 기업으로 살아남지는 못했습니다

Sun은 뛰어난 기술을 여럿 남겼습니다. 프로그래밍 언어이자 실행 플랫폼인 Java, 서버 운영체제 Solaris는 컴퓨팅 역사에 오래 남은 기술입니다.

브라이언 캔트릴(Bryan Cantrill)이 Sun에서 개발에 참여한 DTrace도 그중 하나입니다. 실행 중인 시스템 안에서 무슨 일이 벌어지는지 들여다보는 도구입니다. 문제가 생겼을 때 추측에만 기대지 않고 시스템이 실제로 어떻게 동작하는지 확인하도록 돕습니다.

이런 기술을 만든 Sun도 2010년 Oracle에 인수됐습니다. 기술의 영향력이 크다고 해서 독립 기업으로 살아남을 수 있는 것은 아니었습니다.

그렇다고 이 사실만으로 “Sun은 고객 전화를 받지 않아서 실패했다”고 결론 내릴 수는 없습니다. Sun의 흥망을 고객 지원 하나로 설명하기에는 무리가 있습니다. 다만 뛰어난 기술을 만든 회사라도 고객이 그 기술을 계속 믿고 쓰게 하려면 무엇이 필요한지는 생각해볼 수 있습니다.

고객은 기술과 함께 ‘문제가 생긴 다음’을 삽니다

가령 회사의 주문 시스템이 멈췄다고 해보겠습니다. 담당자는 공급업체에 연락합니다. 당장 알고 싶은 내용은 분명합니다.

문제를 맡은 사람이 누구인지, 지금 무엇을 확인하고 있는지 알아야 합니다. 다음 안내를 언제 받을 수 있는지도 중요합니다.

복구에는 시간이 걸릴 수 있습니다. 하지만 연락마저 끊기면 고객은 더 기다려야 할지, 다른 대책을 실행해야 할지 판단하기 어렵습니다. 시스템이 멈춘 데다 업무를 어떻게 이어갈지도 막막해집니다.

그래서 첫 응답과 문제 해결은 구분해서 봐야 합니다. 문의를 접수했다는 자동 메일은 곧바로 보낼 수 있습니다. 하지만 실제 담당자가 상황을 파악하고 해결을 책임지려면 그에 맞는 준비가 필요합니다.

“고객의 전화를 받는다”는 말도 이런 뜻으로 볼 수 있습니다. 연락할 곳을 마련하는 것에서 그치지 않고, 고객이 다시 업무를 시작할 때까지 누군가 책임지고 문제를 맡아야 합니다.

뛰어난 엔지니어 한 명으로는 지원 체계를 만들 수 없습니다

어려운 장애를 단번에 해결하는 엔지니어는 회사에 큰 도움이 됩니다. 다만 모든 문제가 그 사람에게 몰리면, 휴가를 가거나 회사를 떠났을 때 회사 전체가 장애 대응에 어려움을 겪습니다.

개인의 실력에 기대던 일을 회사가 꾸준히 해내려면 담당자 사이에 정보가 잘 오가야 합니다. 지원 담당자는 필요한 정보를 모으고, 개발팀은 이를 바탕으로 고객이 겪는 문제를 재현할 수 있어야 합니다. 담당자가 바뀌어도 앞서 조사한 내용을 이어받아야 합니다.

이때 중요한 것이 인계입니다. 고객이 부서를 옮겨 다니며 같은 설명을 되풀이해야 한다면, 회사 안에서 전달했어야 할 내용을 고객이 대신 전달하고 있는 것입니다.

기술 조직은 어려운 문제를 풀었을 때 보람을 느낄 수 있습니다. 하지만 고객에게는 해결책을 자신의 환경에서 쓸 수 있는지, 같은 문제가 다시 생기지 않는지가 중요합니다. 회사의 지원도 거기까지 이어져야 합니다.

성능표와 함께 지원 체계도 살펴야 합니다

지금의 클라우드나 AI 서비스를 고를 때도 마찬가지입니다. 제품 도입을 검토한다면 시연 화면과 성능 수치를 보는 데서 그치지 말고 다음 사항도 확인해야 합니다.

• 긴급한 장애가 생겼을 때 실제 담당자에게 연락할 방법이 있습니까?
• 약속한 응답 시간이 문의 접수까지인지, 담당자가 대응을 시작할 때까지인지 분명합니까?
• 문제를 해결한 뒤 원인과 재발 방지 조치를 설명받을 수 있습니까?

공급업체도 이런 질문을 스스로 해봐야 합니다. 평균 응답 시간이 짧아도 자기 요청이 오랫동안 방치된 고객은 지원이 빠르다고 느끼기 어렵습니다. 처리한 문의 건수만 세다 보면, 해결한 줄 알았던 문제로 고객이 여러 번 다시 연락한 사실을 놓칠 수도 있습니다.

회사가 지원 업무를 잘 운영하는지는 이런 문제를 찾아 줄이는 과정에서 드러납니다. 고객이 어느 단계에서 오래 기다리는지 살피고, 다음 담당자에게 넘어갈 때 책임질 사람이 사라지지는 않는지 확인해야 합니다.

Sun이 남긴 기술은 지금도 돌아볼 가치가 있습니다. 그 역사를 보며 함께 생각할 대목은 좋은 기술을 만든 뒤에도 고객이 믿고 쓰도록 뒷받침하는 일이 남는다는 것입니다. 지금 쓰거나 만드는 서비스에서도 문제가 생겼을 때 누가 끝까지 맡을지 분명해야 합니다.