최근 사내에서 신규로 출시한 웹서비스의 유지 보수 및 기능 고도화 작업을 진행하고 있다.
프론트와 백엔드 개발은 혼자서 담당하고 인프라 쪽만 데브옵스 개발자 분들이 도와주고 계시는데, 프론트와 백엔드를 모두 담당하면서 얻게 된 깨달음이 있어 기록을 남긴다.
사이드 프로젝트로 간단한 앱을 만드는 프로젝트를 6개월 째 진행하고 있는데, 해당 프로젝트에서는 백엔드만 담당하여 API의 응답 값이 프론트에서 어떻게 다뤄지는지에 대한 고민을 해보지 못했다. 단순히 프론트 개발자분과 약속을 통해, 응답 데이터에 status, data, message 정보를 담아 보내기로(badRequest, notfound, internal server error 등 모든 예외에 대한 응답을! ) 약속만 하고 그냥 그 약속을 지키기만 했다.
그러다가 회사 업무를 하면서, 한가지 이슈를 통해 응답 처리에 대한 고민을 하게 되었다. 이슈는 다음과 같다.
쿠폰을 발급하는 기능을 구현하였고, 해당 유저가 쿠폰을 이미 발급받은 경우(디비에 발급받은 쿠폰이 있는지 조회) 커스텀하게 만든 Response 객체에 data로 badRequest를 담아서 리턴하도록 API를 만들었는데(약간은 다르지만 사이드 프로젝트에서 하던 방식과 비슷하게) 프론트단에서 실행해보면 중복으로 발급해도 정상적으로 동작을 하는 것 처럼 보이는 것이다.
크롬 개발자 모드로 들어가보니 서버는 응답으로 badrequest를 데이터로 반환하였지만 응답 상태는 200(초록불)이었던 것이다. 또한 프론트 코드에서는 try,catch문으로 로직이 작성되었기 때문에 해당 응답은 정상처리가 되어 별도의 다른 처리를 하지 않았던 것.
이 때 선택지는 두가지임을 깨달았다.
첫번째로 try,catch로 예외를(여기서는 쿠폰이 이중발급되는 상황) 처리하는 것이 아닌 응답 데이터 값으로 조건문을 통해 처리하는 것.
두번째로 서버에서 응답 객체를 반환하는 것이 아닌, 예외를 발생(throw)시키고 프론트엔드에서는 try catch를 통해 해당 예외를 처리하는 것.
그리고 try catch와 예외발생으로 처리하는 것이 해당 기능을 잘 사용하는 것이고, 또 로직적으로 깔끔하다는 것을 꺠달았다.
또한 이전에 서버 관점에서만 생각할 때, 예외를 발생시키면 프론트에서 어떻게 처리하는지 추측이 안되서 예외를 최대한 발생안시키려고( js에도 try catch가 당연히 있음을 알았음에도, 프론트의 코드를 볼일이 없었으니 어떻게 처리하는지를 몰랐다.) 했었는데 이 때 추측하지 못했던 것들을 깨닫게 되었다.
처음 사내에서 해당 프로젝트를 담당하면서 고민이 많았는데 (프론트, 백엔드 두가지 모두 맡게되어) 두 가지를 모두 담당함으로써 얕지만 새로 얻는 지식들이 있음을 느끼고 있다.