기술 지원

지원 조직은 원래 한 줄이었습니다. 들어온 문의를 들어온 순서대로 처리했습니다. 대부분의 문의가 비슷한 무게였을 때는 그 방식이 잘 돌아갔습니다. 비밀번호를 못 찾겠다는 질문과 청구서를 다시 받고 싶다는 요청은 둘 다 3분이면 끝납니다.

그런데 제품이 고객사의 다른 시스템과 엮이면서 무게가 다른 문의가 섞여 들어왔습니다. 사내 계정 체계와 연동이 안 된다는 신고, 문서 8만 건을 옮겼는데 1,200건이 빠졌다는 신고, 특정 브라우저에서만 저장이 실패한다는 신고입니다. 이런 건은 답을 아는 것이 아니라 원인을 찾아야 하는 일이라 한 건에 반나절에서 이틀이 걸립니다.

그 건들이 같은 줄에 서 있으면 뒤쪽이 통째로 막힙니다. 담당자가 오전 내내 연동 문제 하나를 붙들고 있으면 그 사이 들어온 비밀번호 문의 서른 건이 대기합니다. 첫 답변까지 두 시간이던 평균이 아홉 시간이 되고, 기다리던 고객은 같은 문의를 다른 창구로 한 번 더 보냅니다. 기술 지원은 그 줄을 따로 낸 자리입니다. 깊이 파야 하는 건을 전담으로 빼내면 앞줄의 속도가 돌아오고, 그 건 자체도 제대로 다뤄집니다.

넘어오는 건의 종류는 대체로 넷입니다.

1. 연동 문제 — 고객사 계정 체계나 다른 도구와 붙이는 과정에서 막힌 건입니다. API 요청이 거절되는 이유를 찾는 일이 여기 속합니다. API 는 프로그램끼리 주고받기로 약속해 둔 창구입니다.
2. 데이터 문제 — 옮긴 자료가 일부 빠졌거나 글자가 깨졌거나 권한이 잘못 붙은 건입니다. 무엇이 몇 건 어긋났는지를 먼저 세는 것이 일의 절반입니다.
3. 재현이 필요한 오류 — 특정 조건에서만 나는 문제입니다. 고객 환경을 알아내 같은 상태를 만들어 봐야 원인이 보입니다.
4. 성능 문제 — 느려졌다는 신고입니다. 느린 것이 우리 쪽인지 고객사 네트워크인지 가리는 것이 첫 단계입니다.

처리 순서도 정해져 있습니다. 재현하고, 원인을 좁히고, 우회 방법을 먼저 주고, 근본 원인은 개발팀에 넘깁니다. 세 번째가 이 역할의 실질입니다. 고쳐 주는 것이 아니라 오늘 일할 수 있게 만드는 것이 먼저입니다. 특정 브라우저에서 저장이 실패하면 원인을 찾는 동안 다른 브라우저로 안내합니다.

기록도 업무에 들어갑니다. 지원 티켓에 재현 조건과 확인한 것과 남은 가설을 적어 둡니다. 지원 티켓은 접수된 문의 한 건으로, 번호와 담당자와 상태가 붙어 있습니다. 같은 증상이 석 달 뒤에 다시 들어오면 그때 쓴 기록이 유일한 단서입니다.

이 자리가 필요해지는 시점은 기업 고객이 생길 때입니다. 개인이 카드로 결제하는 제품에는 깊이 파야 하는 문의가 드물게 들어오지만, 구성원 200명 회사와 계약하면 연동과 데이터 이전이 반드시 따라옵니다. 그래서 첫 기업 계약과 함께 이 역할을 누가 맡을지 정하게 됩니다.

계약에도 걸립니다. 지원 응답 약속은 몇 시간 안에 첫 답을 주겠다고 정해 둔 기준인데, 기업 고객에게는 이것을 두 층으로 적습니다. 첫 답변은 두 시간 안, 원인 규명 경과 보고는 하루 안 같은 식입니다. 깊이 파는 건에는 해결 시점을 약속할 수 없어서 대신 보고 주기를 약속합니다.

제품 쪽으로도 이어집니다. 같은 연동 문제가 고객사 넷에서 반복되면 그건 고객마다의 사정이 아니라 제품이 그 상황을 못 다루고 있다는 뜻입니다. 기술 지원이 분기마다 반복 건을 세어 넘기면 개발 우선순위가 바뀝니다. CSM이 고객의 계획을 듣고 가져오는 요구와 달리, 이쪽은 이미 막혀 있는 것을 숫자로 가져옵니다. CSM 은 담당 고객에게 먼저 연락해 제품으로 성과를 내도록 돕는 담당자입니다.

"이건 1차에서 풀 수 있는 건이 아닙니다. 기술 지원으로 올리겠습니다."

난이도에 따라 줄을 바꾸는 판단입니다.

"원인은 아직 못 찾았고, 우선 다른 브라우저로 쓰실 수 있게 안내드렸습니다."

우회로 먼저 막고 원인은 따로 판다는 보고입니다.

"같은 연동 오류가 이번 분기에 고객사 네 곳에서 났습니다. 제품 쪽에서 봐야 할 것 같습니다."

반복 건수를 근거로 제품 변경을 요구하는 말입니다.

페이지덱에는 기술 지원을 전담하는 사람이 아직 없습니다. 태오가 개발과 겸해서 맡고 있고, 넘어오는 건은 하루 평균 두 건입니다. 대신 넘기는 기준을 문장으로 적어 두었습니다. 도움말 문서로 답할 수 없고, 고객 환경을 알아야 하고, 30분 안에 원인이 짚이지 않는 건입니다. 셋 중 둘에 걸리면 올라옵니다.

태오는 하루 중 오후 두 시간만 이 일을 봅니다. 나머지 시간은 제품을 만듭니다. 시간을 잘라 두지 않았던 두 달 동안 개발 일정이 두 번 밀렸습니다. 넘어온 건이 셋을 넘는 날에는 그날 안에 다 보지 않고 우회 안내만 먼저 보내고 다음 날 이어서 봅니다.

기술 지원을 개발자가 하기 싫어하는 일을 맡는 자리로 보는 경우가 많습니다. 만드는 쪽이 위고 고치는 쪽이 아래라는 느낌이 섞이기 때문입니다. 다만 이 자리에서 하는 일은 만드는 일과 다른 능력을 요구합니다. 모르는 환경에서 재현 조건을 알아내려면 고객과 대화해 정보를 끌어내야 하고, 원인을 다 찾기 전에 오늘 쓸 방법을 판단해 내놓아야 합니다. 이 판단을 잘하는 사람은 드뭅니다. 하위 업무로 다루면 그 사람은 기회가 생기는 대로 개발로 옮기고, 남는 자리는 다시 겸업으로 돌아갑니다.

처리한 건수로 성과를 보는 것도 흔한 문제입니다. 지원 조직의 다른 자리를 건수로 재니 같은 잣대를 쓰게 됩니다. 하지만 이 자리의 건은 한 건에 반나절이 들고 개수가 적습니다. 건수로 재면 쉬운 건을 골라 처리하는 쪽으로 움직이고, 어려운 건은 며칠씩 미뤄집니다. 여기서 볼 것은 두 가지입니다. 우회 안내까지 걸린 시간과, 같은 증상이 다시 들어온 비율입니다. 뒤쪽이 낮아지면 원인을 제대로 잡고 있다는 뜻입니다.