에러처리의 중요성, ... POST, GET의 차이

엘리스에서 교육을 받는 과정에서 배운 것은 아니지만, 코치님께서 코드리뷰를 해주시는 과정에서 세심하게 에러처리에 대한 부분을 놓치지 않고 똑같은 로직 상관없이 대부분 체크해주셨다. 

 

당시 프론트에서 어지간한 검증은 해서 넘어올 것이라는 안일한 생각이 있었는데, 그렇다고 한들 에러처리는 당연한 것이지만 해서 나쁠 것이 없기에 최대한 하는 것이 좋겠다고 생각했었다.

추가로는 나중에 입사해서 내가 직접 api를 설계, 구현하고 테스트하는 과정에 있다면..

 

'답답하고 오래걸리더라도 뭘 해도 다 안되다가 가능할 때만 db에 전송해야겠다. '정도는 생각했던 것 같다. 

 

 

이번에 회사에 입사해서 회사코드들을 보며 숨이 막히는 상황들이 참 많은데, 

여러모로 코치님께 배운 여러가지에 대해 감사함을 마구마구 느끼고 있다...!

오늘은 그 중 에러처리의 중요성에 대해 피드백하며 포스팅하려 한다. 

 

처리 결과

먼저 결론부터 보여주자면 다음과 같다. 

특정 값을 검색하는 API에 대한 응답시간을 체크하는데, 에러처리를 하기 전에는 166ms / 후에는 6ms가 소요되었다. 

약 27배의 차이인데, 이는 당장 복잡하지 않은 검색이라 이정도 차이가 있기도 하고 166ms 자체가 심기가 불편할 정도로 답답함을 느낄 속도는 아니다보니 누군가는 쉽게 넘어갈 수 있을지 모르겠다. 

1) 에러처리 전

2) 에러처리 후

 

당연히 차이가 날 수밖에 없다. 에러 처리 전에는 요청값을 그대로 로직을 거쳐 DB에서 확인하는 과정을 취하고 그 값을 가져와서 빈 배열로 반환하고 있는데, 에러처리 후에는 요청값을 확인하고 빈 값임을 확인하고 바로 더 로직이 작동하지 않고 에러를 던진다. 

 

 

그리고 에러처리 이외에도 응답시간 뿐 아니라 비용적으로도 절감할 수 있는 요소가 저 짧은 SQL과 URI에서도 보였다. 

>> http 메서드

처음 코드를 받았을 때 확인한 것은 POST다. SQL문에서도 당당히 보이듯 SELECT 외에 다른 행동은 보이지 않는다. 조회는 당연히 GET으로 보내야 하는 것이 아닌가? 싶은데, 선임께 여쭤보니 당장 납품이 되어 있고, 클라이언트와 같이 바꿔야 하는 부분이니 이 부분은 넘겨야 될 것 같다고 하셨다. 

물론 로그인처럼 body로 보내야 할 이유가 있다면.. 그나마 이해할 수 있지만 단순히 검색하는 것인데 body로 보내고 있어서 잘 이해할 수는 없지만, 서버에서만 끝나는 문제는 아니다보니 당장은 넘어가고, 추후에 바쁜 시기가 지나면 프론트와 소통하려 한다. 

 

*GET으로 보내는 것의 장점

만약 여기서 GET으로 보낸다면 ? 캐싱의 가능성이 있어 추후 접근시 빠르게 접근할 수도 있기도 하고

무엇보다 .. 내가 짠돌이라 그런지는 모르겠는데 비용절감의 부분이 중요하다고 여겨진다.

당장 이 검색api는 해당되지 않지만, 전송하는 데이터에 따라 POST와 GET의 비용에 차이가 있어 굳이 POST로 보낼 이유가 없다면 GET으로 보내는 것이 비용절감할 수 있는 요소 중 하나로 생각하고 있다. 

 

아래는 AWS에서 S3에 대해 메서드별로 금액을 측정하고 있다. 

 

 

 

코멘트

  사실 비용적인 측면을 떠나서 당연히 혼자 모든 것을 구성한다면 상관없겠지만 다른 개발자들과 소통하며 협업하기 위해서는 코드의 의도를 명확히 함이 중요하다고 생각한다. API 명세서에 POST라고 되어 있어서 당연히 뭔가 생성한다고 머릿속에 박혀있는데 조회만 하고 있으니 벙 쪘는데, 덕분에 메서드의 중요성을 많이 깨닫고 있다. 

 

  또한 에러처리 전후로 소모되는 리소스도 대폭 줄일 수 있어 서버의 부하를 최대한 피할 수 있지만 금전적으로도 POST와 GET은 10배넘게 금액의 차이가 있다. 물론 S3의 기준이고 이미지는 서버 자체에서는 단순히 이미지로 주고받기 때문에 저 금액으로 비유할 수는 없지만 말하고자 하는 것은 post와 get의 비용차이가 이정도는 아니더라도 굳이 post로 보낼 이유가 없는 것을 비용을 들여가면서 부과할 필요는 없다고 생각한다.