최근에는 개발에 대한 깊이있는 논의를 크게 할 기회가 없었다.
개발할 일은 많지만 사람이 없으니. 당장 내 코가 석자다. 사람들이 매니저 역할에 집중하라고 하지만, 그럼 님이 좀 개발해주던지!
최근에 석자 코 줄이기에 매진하다가 응답 코드를 이야기하는 대화에 참견할 기회가 있었다. 한동안 못해보던 색다른 경험이어서 그런지 각자의 투지도 있었던 것 같다. 상반된 두가지 견해가 충돌하는 상황이지만 각각이 가진 Pros & Cons가 있기에 함 적어본다.
1003 코드가 뭘 의미하는건가요?
이야기는 이렇게 시작했다.
파트너사 담당자: 파트너사에서 우리 시스템을 연동할 때 간간히 1003 응답 코드가 내려온다고 문의를 받았는데 이거 뭔 의미인가요?
개발자: 회원 API 서버 조회 결과가 없는 경우에 그 응답을 내려줍니다.
파트너사 담당자: 코드에 대해 전달이 안된 것 같은데 다른 코드도 있나요?
개발자: 1001은 참여 제한, 1002는 조건 불일치 입니다.
…
이 대화에서 내가 주목한 포인트는 “1003” 이라는 Custom 코드다. 어라? 왜 HTTP Status code를 사용하지 않았지?
이 포인트에서 대화가 이어진다.
나: 이거 따로 코드를 정의하지 말고 HTTP Status code를 사용하는게 더 좋을 것 같네요.
개발자: API 서비스가 아니고, 서비스의 취지에 HTTP Status code가 부합하지 않습니다.
나: 4XX 계열 코드에 보면 404, 409, 411 코드들이 맥락에 부합하는 것 같은데?
개발자: 세분화된 오류 코드를 제공해줘야 파트너사에서 최적화된 플레이어 동선(UX)를 제공할 수 있습니다.
나: 상세한 오류 코드를 제공하는건 보안 측면에서 좋지 않습니다.
개발자: 기획 과정에서 이미 확정된 사항이고, 이를 지원할려면 세분화된 코드를 지원해야합니다.
나: 필요한 부분에서 기획을 변경하는 것도 개발자가 해야할 일입니다.
…
마지막 “나”의 말은 무지 꼰대스럽다. 아마도 듣는 사람 입장에서는 불편했을 것 같다. ㅎㅎ
개발자의 입장
별도의 최적화된 코드를 제공해줌으로써 파트너사가 개발한 서비스는 문제가 발생했을 때 문제점을 바로 파악할 수 있다. 파트너사에서 신경을 좀 더 쓴다면 코드와 1:1 대응되는 사람이 읽을 수 있는 메시지를 사용자에게 제공할 수 있다.
더구나 이 코드는 최종 사용자에게 최적화된 UX를 제공할 수 있는 기반이 된다. 사용자가 고생하는 혹은 막힌 문제를 정확하게 이야기해줄 수 있다. 입력의 문제라면 친절하게 어느 입력이 어떻게 문제인지를 지적해줄 수도 있다. 이 부분은 대부분의 기획자들이 원하는 바다. 기획자의 기획 의도를 충실히 지원하고 싶다면… HTTP Status Code와 같은 범용 코드로는 부족하다.
나의 입장
별도의 코드는 읽을 수 있는 문자 형태(Mnemonic)으로 파트너사에게 제공되지 않는다. 이 서비스에만 유효한 단순 숫자일 뿐. 결국 산출물(문서)로 작성하고 관리해야 한다. 반면 HTTP Status Code는 만국 공통어. 심지어 개발자가 아니더라도 이 숫자의 의미를 아는 사람들이 좀 된다. 굳이 엉뚱하게 쓰지 않는다면 문서도 만들 필요가 없다. 이미 알려진 의미대로 해석하면 될테니까.
문제점 파악은 최적화된 로그가 정답 아닐까? 특정 상황에 딱 떨어지는 오류 코드는 시스템을 비집고 들어올려는 해커들에게도 데이터와 로직의 특성을 알려주는 가이드북이다. 진단과 분석을 할려면, 필요한 정보를 안전한 곳에 남기고 안전하게 볼 수 있어야 한다.
UX의 최적화를 세분화와 상황별 텍스트 메시징으로 보는 것은 좀 아닌 것 같다. 이런 방식은 한 5년 10년전에 먹히던 방식이다. 예전에는 친철하게 노출해준 텍스트를 읽지 않는 사용자들이 잘못이라는 비난이 먹혔다. 하지만 우리가 살고 있는 시대는 모바일을 넘어 동영상과 VR시대다. 텍스트는 읽히지 않는다. 그나마 아이콘과 이모티콘 정도를 봐줄 뿐.
과정의 시대가 아니라 빠른 결과가 되려 더 중요한 것이 요즘이다. 친절히 과정을 설명해주는 것보다는 빠르게 진행할 수 있으면 최고다. 간단히 되면 되는거고, 안되면 안되는 것을 똑 부러지게 이야기해주는게 모두에게 좋은 요즘 시대다.