서비스 개발의 우선순위

성능을 위해 편리함을 양보해 줄 플랫폼 사용자는 없다.

서비스 개발의 본질에 대해서 나의 생각이 완전히 바뀐 일이 있었다.

2014년 하반기. 나는 "어스토리 재팬"이라는 일본인을 대상으로 하는 여행 플래닝 서비스를 개발 하였다.

일본인을 대상으로 하는 일본어 플랫폼이기 때문에 일본인 사용자의 의견이 듣고 싶었던 우리 팀은 일본인 교환 학생 10여명을 초청 하여 회의실에서 직접 사용하게 하고, 바로 피드백을 받는 자리를 갖게 되었다.

흔치 않은 기회 였다.

문의사항이라던지 Q/A게시판, 이메일 또는 전화를 통해 유저의 의견을 듣게 되는 경우는 있지만, 이런 식으로 직접 자리를 만들어서 사용자의 서비스 이용을 눈으로 관찰 하고, 의견을 바로 들어 볼 수 있는 경험은 그 전 에도, 후 에도 주어 지지 않았기 때문이다.

어쩌면 대부분의 개발자도 경험 할 수 없었을 것이다. 나에게는 정말 큰 자리 였다.

하지만 나는 이 자리에서 반성 할 수 밖에 없었다.

왜냐하면 일본인 학생들이 불편하다고, 좀 더 개선되었으면 좋겠다고 말했던 것들 중 일부는 내가 비효율 적이고, 관리도 용이 하지 않으며, 오류를 유발 할 수 있는 부분이라고 주장하며 축소 또는 삭제했던 기능도 있었다.

그 자리가 끝나고 우리팀은 오픈한지 2주만에 리뉴얼을 결정 하였고, 한달 동안 작업하여 다음 버전을 내놓았다.

오픈한지 2주만에 리뉴얼을 결정한 것을 보면 다른 팀원들도 어쩌면 나와 비슷한 생각을 했던 것 같다.

4개월 이상의 시간 동안 "어스토리"사무실에서 어스토리 직원들과 일정내에 만들기 위해 크런치 모드라는 말이 의미가 없을 정도로 열심히 만들었던 서비스였다. 이제는 어스토리 직원들의 도움을 받을 수 없기 때문에 혼자서 개발해야 함에도 이를 바로 수용 했던 것은 나 역시 그날 느낌 점을 반성하고 개선하고자 했던 마음이 간절 했기 때문이였다.

기획자도 디자이너도 개발자도 이견이 없었다. 어쩌면 우리는 사용자가 아니라 우리가 만족 할 서비스를 만들려고 했던 것 같다.

개발자의 입장에서 본 그 날의 느낌은 내가 정말 중요 한 것을 놓치고 있었다는 느낌이였다.

사실 대부분의 사용자는 해당 서비스가 AWS를 사용하건, CDN을 사용하건 또는 어떤 언어로 개발 되었는지 어떤 프레임워크를 선정 하였는지 또는 Database를 사용하였는지, 어떤 어떤 로직을 사용하였는지, 정렬에 어떤 알고리즘을 이용하였는지, 백업 및 복구 계획이 어떻게 되는지, 백업 정책은 어떻게 되는지, 보안 정책은 어떤지 전혀 관심이 없다.

그 것은 오로지 나 또는 우리 팀의 문제이지 사용자에게는 중요하지 않다. 물론 위와 같은 과정이 곧 궁극적으로는 사용자를 위해서 고려되어야만 하는 부분인 것은 맞다. 하지만 내가 이야기 하려고 하는 것은 우선순위이다.

중복되는 API가 여러번 호출 되는 것이 문제라고? 비슷한 API가 여러개 존재 하면 관리가 용이 하지 않다고? 물론 최적화된 API를 효율적으로 호출하게 하는 것은 당연히 중요하다. 하지만 그 것을 위해서 사용자가 불편을 감수 할 필요는 없다. 

어쩌면 이것 저것 합리화 할 명분을 만들어 내면서 결국은 내가 편하게 개발 할 수 있고, 내가 관리하기 용이하고 또는 내 커리어에 도움이 될 만한 기술을 사용 할 수 있는 환경으로 진행 하려 했던 것이다. 

가장 우선순위가 높은것은 결국 내가 아니라 사용자다.

사용자가 편리하고 유용한 기능을 구현하는 것이 우선이고, 그 기능을 어떻게 하면 오류가 덜 나고, 효율적으로 관리 할 수 있도록 만들거나 개선 할 수 있을까를 고민하는게 개발자의 일이 아니던가?

우리는 사용자를 만족 시킬 수 있는 서비스를 만드는 것이 목표라는 것. 그 것을 잊으면 서비스가 아니라 도대체 무엇을 만드는 걸까?

그 날 내가 느꼈던 감정을 잊지 않고, 다시 한번 상기 해 본다.