들어가며

이 글에서는 서버 개발자인 나와 프론트 개발자 동료가 아주 작고 사소한 UX 문제를 해결하기 위해 Web UI와 API 서버 인터페이스를 리팩토링한 과정을 설명한다. 둘이서 UX 문제를 두고 고민하며 지금 생각하니 매우 개발자 중심적인 해결책을 나열하다가, 고객 중심으로 생각을 옮김으로 간단히 문제를 해결했던 경험을 기록해 보았다.

배경

우리에게 아래와 같이 두개의 입력 에디트 박스(AZ, EL)와 하나의 전송 버튼이 있었다. 사용자가 입력 에디트 박스에 값을 입력하고 전송 버튼을 클릭하면 API 서버로 하나의 JSON 메시지가 전송된다.

사용자가 AZ, EL 모두를 입력하고 전송 버튼을 클릭한다고 가정하고 프로토타입을 개발했다.

그리고 우리는 Web UI 와 API 서버 간에 아래와 같은 형식의 메시지를 정의해 두었다. 하나의 메시지에 두개의 AZ(azimuth), EL(elevation) 파라미터가 동시에 전송되도록 설계했다.

문제점

프로토타입을 테스트 하다 보니 단순한 예외 케이스가 생각났다.

"사용자가 AZ만 입력하고, EL은 빈칸으로 두고 전송 버튼을 클릭하면 어떻게 처리해야 하는 거지?"

Clean 하지 않은, 중심을 잃은 해결책

둘이서 즉흥적으로 머리를 맞대고 아래와 같은 해결책을 생각나는 대로 말하기 시작했다.

A : "전송 버튼을 누르면 EL에 0값을 줄까?"
B : "아니지, 사용자가 EL에 의도적으로 0을 입력한 것과는 구분되어야 하잖아"
A : "그럼 EL을 NULL로 전송하면 되겠다?"
B : "안될건 없는데 서버에서 NULL 처리를 해서 분기 처리를 해야하는데..."
A : "귀찮으면 전송 버튼을 누르면 사용자가 마지막에 입력한 값을 내부적으로 보내줄까?"
B : "사용자가 한 번도 값을 입력한 적이 없는 상황도 있고, 뭔가 직관적이지 않은 것 같은데..."
A, B : "우리 생각좀 해보고 다시 얘기하자"

고객 중심으로 이동

자리로 돌아와 차근히 문제를 다시 돌아 보며, 한 가지 질문을 던져보았다.

"고객이 원하는게 뭘까?"

B : '고객은 AZ 값만 그냥 바꾸고 싶은거야'
B : '고객은 EL에 0 값을 주거나, 마지막 값을 입력하고 싶은게 아니라, 그냥 AZ만 입력하고 싶은거야'

맞다. 우리는 API로 전달되는 메시지가 하나라는 스스로 정한 제약 사항에 갖혀서 사용자가 입력하고 싶은 AZ가 아니라 EL을 어떻게 처리 할지 온갖 고민을 하고 있었던 것이다.

Clean 한, 해결책

생각이 여기까지 이르자. 해결책은 너무나 단순했다. 사용자가 아래와 같이 AZ만 입력하고 전송버튼을 누르면 API로 AZ 값만 전달해 줄 수 있도록 메시지를 분리하면 되는 것이었다.

아래와 같이 하나로 합쳐져 있던 AZ, EL 메시지를 개별적인 두개의 메시지로 분리해서 문제를 클린하게 해결했다.

마치며

사실 문제 자체는 너무 간단한 것이지만, 개발자 스스로 정한 제약에서 빠져나와 고객의 입장에서 단순하게 문제를 해결했다는 사고의 패턴은 중요한 의미를 가지는 것 같아 이렇게 글까지 남겨보게 되었다. 앞으로 개발할 때도 아래 질문을 자주 던지자. 훨씬 단순한 해결책이 나올지도 모르니.

"고객이 원하는게 뭘까?"