Overview

서비스되는 프로젝트에 첫 커밋(Commit)했던 순간이 아직도 생생합니다. 직원이 10명 남짓이던 시절, 특정 데이터를 삭제할 때나 쓰던 관리자 페이지였는데요. 당시엔 MVC Pattern, Transaction 등 아무것도 몰랐기 때문에 실수를 반복했습니다. (팀장님으로부터 피드백도 많이 받았죠.) 어떤 실수였는지 궁금하시죠? 오늘은 두 번 다시 겪고 싶지 않은 실수들과 깨달은 몇 가지 이야기와 개발자가 꼭 지켜야할 것을 소개하겠습니다.

사용자를 생각하는 마음

예전에는 로직을 짤 때 실패하는 케이스를 깊게 생각하지 않았습니다. 왜냐하면 “나는 기능을 만들고, 사용자는 내가 만든 기능을 쓴다.”고 생각했기 때문입니다. 요구 사항대로 동작하게 만들고, 예외 케이스는 사용자의 책임으로 돌렸습니다. 하지만 이런 태도로 개발하면 UI/UX는 발전할 수 없고, 서비스도 개선될 수 없으며, 사용자의 불만만 생긴다는 걸 곧 알게 되었죠.

작년 이맘때쯤 브랜디 앱에 진열될 상품 관리 페이지를 개발했습니다. 요건에 기재된 내용을 요약하면 아래와 같았습니다.

제시된 요건

등록 가능한 상품의 개수는 ‘무제한’이다.
하나의 페이지에 여러 구좌를 관리하는 영역이 들어갔으면 좋겠다.
상품 조회 화면에는 ‘누적 판매량’과 ‘7일 판매량’ 항목이 추가되어야 한다.

우선 ‘무제한’이라는 단어에 각 관리 영역마다 max-height를 지정했는데요. 여러 관리 영역이 하나의 페이지에 들어가더라도 스크롤을 많이 하지 않아도 되게 작업했습니다. 이뿐만이 아닙니다. 중복된 상품을 등록할 수도 있기 때문에 그것에 대한 유효성도 추가했죠. 하지만 막상 프로덕션(production)에 배포되니 직원들의 피드백이 쏟아졌습니다.

“상품을 등록하고 다시 관리 페이지에 진입하려니 시간이 오래 걸려요.”
“상품이 중복됐다고 alert이 뜨는데 어떤 상품이 겹치는지 알 수는 없나요? 혹시… 일일이 찾아야 해요?” 2)
“상품 setting 후에 등록을 했는데 다시 보니 안 되어있어요!”

“아뿔싸, ’무제한’이라는 단어를 보고 max-height 값만 떠올리다니!”
드러난 이슈들을 수정하면서 반성하고 또 반성했습니다. 등록된 상품들을 가져와서 페이지에 렌더링(rendering)할 때, 상품 수가 많을수록 뷰 페이지의 로딩 속도는 느려진다는 걸 예측하지 않았습니다. 심지어 하나의 페이지에 여러 구좌를 관리할 수 있도록 개발했으니, 불러와야 할 상품은 수백, 수천 개였을 겁니다. 직원들은 하염없이 페이지만 바라보며 불만을 터트릴 수밖에 없었고요. 이후엔 페이지에 진입하자마자 상품 목록을 가져오지 않고, 특정 버튼을 눌렀을 때 ajax로 상품을 로딩하는 방식으로 개선했습니다.

당시 개발했던 진열 관리 화면

상품 등록이 잘 안 된다는 이슈는 로컬(local) 및 스테이징(staging) 서버에서 재현되지 않아 고개를 갸웃거렸는데요. 프로덕션(production) 정보를 보고 나서야 원인을 잡을 수 있었습니다. ajax를 이용해 POST로 전송할 수 있는 array의 최대 사이즈가 정해져 있다는 걸 알게 된 것이죠.1) 결국 JSON 형태로 바꾸어 데이터를 전송하고, 서버사이드에서 배열을 다시 변환해 로직을 수행하도록 개선했습니다.

팀장님의 질문도 기억에 남습니다. 팀장님은 단호하게 물었죠.
“쿼리 돌아가는 건 확인했어?”
일정이 급급하다는 이유로 쿼리를 확인하는 과정을 간과했습니다. 데이터는 당연히 0건으로 나왔지만 조건에 부합하는 데이터가 없어서인지, 잘못된 질의 때문인지는 의심하지 않았던 것이죠. 팀장님은 말했습니다.
“네가 자꾸 실수하면 사용자는 우리 시스템을 신뢰할 수 없을 거야.”

PRODUCT_REGIST_DATETIME BETWEEN NOW() AND NOW() - 7
나 : 7일동안 등록된 상품 데이터를 가져와주세요.
데이터베이스 : …???

주위를 관심 있게 둘러보는 눈

지난 번에 쓴 신입개발자를 위한 코드의 정석을 보면 ‘모든 개발조직은 좋은 품질의 소프트웨어를 개발할 수 있는 개발자를 원한다’는 문장이 있습니다. 좋은 품질과 가치 있는 서비스를 만드는 건 개발자가 당연히 가져야 할 책임과 소신입니다. 서비스에 대한 이해도 어느 정도 필요하고요. 그렇지 않으면 엉뚱한 서비스가 나옵니다.

재작년, 브랜디 커머스 웹 1.0 버전을 개발했을 땐 e-commerce에 대한 이해도가 거의 없었습니다. 유사한 서비스들의 레퍼런스를 진행하고 개발을 시작해야 했는데 그저 상상력에 의존한 채 UI/UX 개발을 진행했었습니다. 그때 느꼈던 걸 몇 가지 정리해보겠습니다.

유사한 서비스를 적극적으로 사용하자!
사람들은 많이 쓰는 서비스의 UI/UX에 익숙합니다. 그러므로 유명하면서도 비슷한 목적을 수행하는 다른 서비스들을 사용해보세요. 그 분야에 대한 센스가 무럭무럭 커질 겁니다. 더 나아가서는 사람들이 익숙하다고 느끼는 것보다 훨씬 더 편한 UI/UX를 떠올릴 수도 있겠지요!
다른 개발자의 생각도 물어보자!
같은 문장을 보고도 다르게 해석하듯, 같은 서비스를 개발하는 개발자들도 저마다 솔루션은 다릅니다. 자신은 괜찮다고 생각하더라도 다른 개발자에게 꼭 물어보세요. 미처 생각하지 못했던 의견들이 나올 수 있습니다. 즉, 많은 커뮤니케이션이 더 좋은 개발을 돕는 것이죠.
개발하기 쉬운 서비스 말고, 사용자가 쓰기 편한 서비스로 만들자!
일정에 쫓기면 당장 개발하기 편한 방법을 선호할 수도 있습니다. 개발자의 주관적인 판단이 UI/UX를 망칠 수 있는데도 말이죠. 실수는 자신이 만회해야 합니다. 눈앞의 것을 생각하지 말고, 사용자를 생각하며 개발합시다. 사용자가 기분 좋게 서비스를 이용하는 게 훨씬 뿌듯하잖아요.

Conclusion

무수한 실패담 중에 기억나는 몇 가지만 추렸습니다. 과거의 코드나 실수의 이력들을 글로 써 보니 ‘전부 내 경험이 되었구나’라는 생각이 듭니다. 지금 이 글을 읽고 있는 당신은 어떤 실수를 해보셨나요? 손해 보는 경험은 없습니다. 분명 언젠가는 도움이 될 거예요.

주석
1)이 때문에 상품을 등록할 때, 스크립트에서 array로 담아 전송하면 데이터가 누락되어 제대로 등록되지 않거나 에러가 발생할 수 있는 결함이 있었다.
2)중복된 상품을 화면에 표시해주는 기능은 여러 상황으로 인해 개선하지 못했다. 이후에는 발생하는 문제의 사유를 사용자에게 친절히 알려주어서 원하는 결과를 얻도록 힘쓰고 있다.

참고

글
김우경 | 커머스 개발팀
kimwk@brandi.co.kr

브랜디, 오직 예쁜 옷만