해당 글은 예전 제 깃헙 블로그에 작성했던 글을 옮겨적으며 수정한 글입니다.
문제 발생
2021년 1월 쯤 회사에서 진행했던 프로젝트의 스프링 부트 기반 백오피스 페이지 애플리케이션을 5개월 후인 2021년 6월 쯤에 유지보수할 일이 있었다. 애플리케이션에 신규 비즈니스 로직을 추가하고 기존 로직들을 수정한 뒤 테스트하고 문제없이 동작하는 것을 확인한 후에 배포했다. 그런데 로컬, 개발 환경에서는 이상없던 애플리케이션의 수정 요청 API가 스테이징 서버와 운영 서버에서 정상적으로 작동되지 않았다. 정확하게는 수정 API 요청들을 보냈음에도 애플리케이션까지 해당 요청들이 들어오지 않았다.
원인 파악
처음에는 리팩토링하다 실수를 저지른 것으로 생각해 애플리케이션 소스코드에서 원인을 찾으려고 했지만, 수정한 코드에 문제는 없어보였다. 고민하다가 배포된 서버 환경의 차이 때문일지도 모른다는 생각에 서버 환경을 정리해봤다.
| 환경 | Web Server | WAS |
|---|---|---|
| 로컬 | Tomcat(Embedded) | Tomcat(Embedded) |
| 개발 | nginx | Tomcat |
| 스테이징 | webtob | Jeus |
| 운영 | webtob | Jeus |
이렇게 정리해봤을 때 해당 이슈가 발생하는 스테이징 서버와 운영 서버의 Web Server나 WAS 중 한군데에 그 원인이 있겠다고 생각했고, Web Server와 WAS의 로그들을 확인했다. 원인은 Web Server인 webtob에서 요청으로 들어오는 HTTP Method를 제한하고 있는 것이었다.
기존프로젝트에서는 HTTP Method를 GET, POST만 사용하고 있었는데 유지보수 과정에서 PUT, DELETE를 사용하는 API를 추가하게 되었다. 그러나 webtob에서는 보안을 위해 GET, POST만 허용하고 있었기 때문에, PUT을 사용하던 수정 요청 API들이 전부 막혀 애플리케이션 단까지 로그가 가지 않은 것이다.
해결
프로젝트의 여건 상 Web Server를 수정하여 HTTP Method 제한을 풀 수는 없었고, 애플리케이션 단에서 사용하는 HTTP Method들을 전부 GET, POST로 변경하는 방향으로 해당 이슈를 해결했다. 개인적으로 이 때 HTTP 에 대한 강의를 들었던 직후라 Restful한 API를 만들어보고자 하는 욕구가 충만할 때였고 그런 방향과는 정반대로 애플리케이션을 수정한다고 느껴 굉장히 아쉬웠다.
