서사
어느날 팀원에게 Suwiki 의 시험정보를 구매하는 과정에서 중복구매가 발생 했다는 소식을 들었다.
먼저 휴대폰을 켜서 IOS 에서도 같은 현상이 일어나는지 확인을 하였다.
또한 전화를 통해, 안드로이드 휴대폰을 가지고 있는 팀원에게 이 문제에 대해서 확인을 요청하였다.
IOS, 안드로이드 모두 중복구매가 막혀있었지만, 웹 (프론트) 에서만 중복구매 현상이 발생하였다.
문제
비즈니스 로직의 암호화
기존 시험정보 응답 객체이다.
아무리 봐도, 고객이 해당 시험정보를 구매 여부를 확인 할 수 있는 필드가 없다.
이 코드를 구현했던 나 조차도, 한참동안 코드를 뒤적이는 행위를 하게되었다.
기존에는 isExamDataExist(시험정보 데이터가 있는지 알려주는 상태값) 이 True 인데, data 가 빈 리스트가 내려오면 해당 유저는 시험정보를 구매하지 않았다고 판단하는 로직으로 되어있었다.
실제 구현자가 아니면, 절대 알 수 없도록 암호화가 되어있던 것이다.
[실제 구현 했던 사람도 헷갈리는 현상이 벌어졌다.]
서버 2차 검증의 부재
서버에서 2차로 중복구매를 막아놨어야 했는데, 클라이언트에 중요한 검증로직들을 모두 책임 전가하였다.
서버에서 한번 더 검증하는 로직이 있었다면, 이러한 상황이 발생하지 않았을 것이다.
구체화
웹 프론트엔드에서 코드를 리팩토링 하는 과정에서 API 응답값에 명시적인 값이 없어 시험정보 구매 여부 확인 과정이 제외되어서 이런 문제가 발생하였다.
개선
- 응답값을 명시적으로 내려주었다.
추후 새로운 사람이 들어올 수도 있고, 코드 작성자 조차도 시간이 지나 잊어버릴 수 있다는 것을 몸소 깨달았다.
API 응답을 명시적으로 보내줌으로서, 해당 API 를 통해 어떤 데이터를 가져와야하고, 이 데이터로 어떤 행위를 해야 하는지 유추 할 수 있도록 만들었다.
- 서버에서 2차 검증하는 로직을 추가하였다.
클라이언트에게 중요한 비즈니스로직의 검증의 책임을 전가 하는 것 보다는,
오히려 데이터를 관리하는 서버측에서 검증의 책임을 하는 것이 더 적합하다고 판단하였다.
더하여, 클라이언트와 서버 모두 검증을 하는 것도 신뢰성 측면에서는 큰 이점이 있다고 판단하였다.
아무래도 금전적으로 구매를 한 정보를 다루기 때문에, 데이터의 신뢰성 측면에서 더 개선을 하였다.
결론
서비스의 비즈니스로직 과 응답은 모두 명시적이어야 한다.
자신만 또는 자신의 팀원만 알아들을 수 있는 로직은 지양 해야한다 라는 점을 크게 느꼈다.
검증로직은 아끼지 말자.
특히 검증 로직을 클라이언트에게 전가하는것은 책임의 분할이 아닌 회피이다.
