금요일 저녁 이슈가 하나 등록되었다.

4 min readDec 26, 2017

지난 금요일 우리의 이슈 시스템에 이슈가 하나 등록되었다.

버그의 상태가 너무 자세히 기술되어 있어서 크리스마스 내내 머릿속을 떠나지 않았다.

고객이 이슈를 정리하면서 어떤 생각이었을까라고 생각하니 쉽사리 휴식을 즐기기 어려웠다.

아이들과 모든 일정을 마무리하고 저녁 9시쯤 노트북을 켜고 버그를 잡기 시작했다.

보고된 버그는 치명적이었고, 새벽 2시쯤 패치하여 배포하였다.

그리고 나는 고객의 피드백을 기다리고 있었다.

혹시나 피드백이 오지 않으면 문제없다고 생각하려고 했다.
대부분 고객은 이슈를 제기한 이후에 답변에 대한 피드백을 잘 주지 않는다.
사실 우리가 원하는 피드백은 아래 정도다

“아 문제없이 작동합니다.”

그런데 고객은 또다시 장문의 PPT 파일로 또 다른 버그를 올렸다.

오늘 아침 전화를 걸었다.
처음에 그는 운전 중이라며 짧게 전화를 하려고 했었으나 결국 즐거운 통화를 30분 가량 했다.

제품 관리자로서 버그 이슈가 발생하면 먼저 미안한 마음부터 든다.
“조금 더 신경 써서 개발했어야 했어”라며 자책한다.

그런데 고객과의 통화해서 또 새로운 사실을 알게 되었다.

“프로그램의 버그를 너무 빨리 포기 합니다.”

제품을 구매했기 때문에 완벽한 제품을 받아야 하겠지만, 완벽한 제품이 어디 있겠습니까? 라며 운을 띄운 그는 66년생 개발자였다.

그는 통화를 통해 다양한 MariaDB 관련 제품을 사용하고 있고, 그중에서 가장 쓸만한 제품이라고 말했고, 그리고 기술지원 내용을 보며 지속적해서 버그를 해결해 주고 있음을 인지했다고 했다.

그리고 본인은 어떤 제품이든 버그를 찾아내면 우리에게 보낸 것처럼 이슈를 정리해서 보내 준다고 했다.

그런데 우리는 가끔 제품의 버그가 나면 이렇게 생각한다

언젠가 고쳐지겠지!
누가 신고했겠지!
제품이 왜 이 모양이야!
한국 제품이 뭐 그렇지!
좋은 제품이 아니군!

나도 한때 이렇게 생각했다.

내가 신고하면 고쳐주기는 하겠어?
언제 고쳐줄지 어떻게 알아?
일하기도 바쁜데 이슈를 언제 올리나?
아! 잘 좀 만들지!
내가 만들어도 이렇게는 안 만들겠다.
UX가 이게 뭐야?
등등등

내부에서 나름대로 품질 테스트를 한다고 해도 현장과 같을 수는 없다.
우리에게 올라온 미해결 이슈가 아직도 엄청 많다.

한때 개발자를 보호한다는 명목 아래 기술지원팀이 고객 이슈를 정리하고 개발자에게 넘겨준 적이 있었다.
그러나 개발자는 고객이 어떤 생각으로 이슈를 제기하고 버그를 패치하고 기능을 개선했을 때 어떤 감동을 받는지 안다는 것은 개발자로서 최고의 행운이 아닐까 생각한다.

이 이슈를 하나씩 제거하다보면 분명 더 튼튼한 제품이 될 것이다.
그래서 우리에게 이슈는 재산과 다름없다.

제품이라는 것은 고객이 구매해야 하는 것이어야 한다.
고객과의 피드백이 잦아질수록 뭔가 특별한 유대감 같은 게 생긴다.
그리고 안개가 끼어 있던 방향성이 맑아지고, 해야 할 일이 더 명확해졌다.

고객이 얼마나 사 줄것이고 얼마나 유지보수를 해줄 것인가를 인지하는 순간부터 회사 매출을 예상할 수 있고, 더 많은 피드백을 받을 수 있도록 다양한 고객을 확보해야 하기에 우리는 더 가격을 내릴 수밖에 없다는 생각을 한다.

또 다른 생각은 고객과의 통화에서 50대 개발자로 살아가는 것은 특별해서가 아니라 이런 꼼꼼함이 있기 때문이라고 생각하게 되었다.

나 또한 그 고객처럼 50대 개발자로 살아가야겠다는 생각을 가지게 되었다.

SQLGate에서 사용하고 있는 서비스

이슈 관리 시스템 — http://www.zendesk.com
고객센터 — https://channel.io/ko