[회고] 사용자가 아닌 나를 위한 설계였다

이번 포스트는 웹 서비스를 유지보수하다 든 생각을 주저리주저리 적어볼 생각이다.

 

웹 서비스를 개발하고 운영하다 보면, 기획 단계에서 '많이 쓰이겠지' 싶었던 기능이 막상 출시 후엔 거의 사용되지 않는 경우가 있다. 그렇다고 없애버리기엔 가뭄에 콩 나듯 찾는 사용자가 있어, 애매하게 살아남은 기능들이 생기기 마련이다.

 

서비스에는 두 가지 동작 방식이 있는데, 데이터베이스에 연동해 결과를 저장하고 관리하는 DB 모드와, 별도 저장 없이 사용 후 휘발되는 Standalone 모드다.

 

문제의 기능은 Standalone 모드에만 존재했는데, 이 기능을 쓰려고 Standalone을 켜는 수준이었다. 이 기능 하나를 위해 4~5개의 페이지를 따로 만들고, API 쿼리 파라미터 분기 처리도 하면서 기술 부채도 심했다. 결국 Standalone 모드를 deprecated하고, 해당 기능을 DB 모드에 편입하기로 팀내 결정되었다.

 

문제는 다음이었는데 기존 DB는 애초에 이 기능을 크게 고려하지 않고 설계된 터라, 사용량도 많지 않은 기능 하나를 위해 DB를 준-재설계 수준으로 손봐야 할지, 아니면 로직으로 어떻게든 온몸 비틀기를 해야 할지 고민을 했다.

 

두 방식의 트레이드오프는 명확했다. DB 테이블을 수정하면 기존 DB 모드에서 제공하는 서드파티 기능들을 추가로 활용할 수 있지만, 변경 범위가 코드베이스의 절반에 가까울 만큼 방대했다. 반면 로직으로 온몸 비틀기를 택하면 코드량은 줄일 수 있지만, 서드파티 연동이 불가능해져 미래 요구사항에 유연하게 대응하기 어려워진다. 머릿속으로는 트레이드오프를 정리해두고 있었지만, 막상 결론을 내리려니 쉽지 않았다.

 

그때 팀장님이 한 가지 조언을 해주셨다. 실제 사용자에게 직접 물어보라는 것이었다. 이에 따라 현 사용자들을 대상으로 간단한 설문을 진행했다. 기능을 앞으로도 사용할 의향이 있는지, DB 모드로 편입될 경우 사용 빈도가 늘어날 것 같은지, 서드파티 기능에 대한 수요가 있는지를 물었다.

 

결과는 서드파티 기능에 대한 니즈는 아예 없었고, 사용자들이 가장 기대하는 건 이 기능이 DB 모드로의 편입, 그 자체였다. 설문 전까지만 해도 '확장성'과 '사용성'을 명분 삼아 DB 테이블을 수정하는 쪽으로 마음이 거의 기울어 있었는데, 그 선택이 아무도 쓰지 않는 거대하고 복잡한 서비스로 이어질 뻔했다는 걸 깨달았을 때 적잖이 충격이었다.

 

돌이켜보면, 그 결정의 이면에는 주니어로서 DB 스키마 수정 같은 굵직한 작업을 경험해보고 싶다는 욕심이 있었던 것 같다. '확장성'과 '사용성'이라는 그럴듯한 명분을 내세웠지만, 그 밑에는 그냥 해보고 싶다는 개인적인 동기가 깔려 있었다. 사용자가 원하는 것과 무관한 이유로 기술적 방향을 정하려 했던 셈이다. 합리적인 의사결정과는 거리가 멀었다. 뭐, 그런 기회는 나중에 더 적절한 때가 오겠지.