예외 메시지 관리 방법에 대한 조언 요청: Enum vs. Database

Question

안녕하세요,저는 현재 Spring Boot를 사용하여 REST API를 개발하고 있으며, 예외 처리를 위해 커스텀 예외와 함께 Enum을 사용하여 HTTP 상태 코드와 에러 메시지를 관리하고 있습니다. 모든 서비스에서 재사용할 수 있도록 하나의 커스텀 예외를 구현하였고, 서비스에서 발생하는 예외를 catch하여 Enum에서 정의된 코드와 메시지를 사용해 클라이언트에게 통일된 형식의 에러 응답을 반환하도록 하였습니다. 이 응답에는 시간, 예외 메시지, HTTP 상태 코드가 포함됩니다.하지만, 이 방식에 대해 피드백을 받았습니다. Enum에서 예외 메시지를 관리하면, 메시지를 수정할 때마다 애플리케이션을 재배포해야 한다는 지적이었습니다. 대신, 예외 메시지를 데이터베이스에서 관리하는 것이 수정 시 애플리케이션의 재배포 없이 유연하게 대응할 수 있다고 제안받았습니다.이에 대해 몇 가지 의문이 생겼습니다:데이터베이스를 사용하면 예외 메시지 관리를 위한 테이블을 생성하고 유지보수해야 합니다. 이는 추가적인 작업과 관리가 필요하다는 의미인데, 이 접근 방법의 장점이 Enum을 사용하는 것보다 클까요?Enum이나 데이터베이스 모두 새로운 예외 메시지가 생기면 관련 로직을 수정해야 합니다. 데이터베이스 방식이 이 문제에 있어 실제로 더 유연한가요?CI/CD 파이프라인(예: Jenkins)을 구축해두면, Enum에 변경사항이 생겨도 애플리케이션을 손쉽게 재배포할 수 있습니다. 이 경우, Enum을 사용하는 것이 여전히 불리한가요?이러한 점들에 대한 여러분의 의검과 경험을 듣고 싶습니다. 특히, 예외 메시지를 관리하는 데 있어 Enum과 데이터베이스 중 어느 쪽이 더 효과적인지, 실제로 어떤 방법을 사용하시는지 공유해주시면 감사하겠습니다.

세브라이드 · Answer

Enum이 낫지 않을까요? 데이터베이스 방식은 데이터베이스 장애가 일어나면...;

더미 · Answer

메시지를 추가하거나 수정할일이 많다면 데이터베이스 아니면 enum도 상관없습니다.

옥다방고양이 · Answer

✅️대부분의 대기업, 공공기관 프로젝트에 보면, 메시지관리(예외메시지, 에러메세지,경고메시지,사용자메시지 등등)는 모두 데이타베이스에서 관리하는게 일반적입니다.&#x1f449;이유는, 새로운 상품(or 서비스) 추가,삭제,변경 될때마다, 관련 메시지도 추가,삭제,변경 해야되는데,,, 그때마다 배포를 다시 하지 않기 위해서입니다.

wharup · Answer

예외 메시지를 소스 코드에 넣거나, 배포 없이 변경할 수 있도록 외부에 설정하는 것은 각각 장점과 단점이 있습니다.그래서 현재 상황에 장/단점이 얼마나 중요한가에 따라 판단해야겠지요;;만약에 에러 메시지가 사용자 화면에 직접 표시되는거라면, 서버단 소스에 넣는건 바람직하진 않습니다.특히 SPA와 API 서버로 구성이라면, UI에 메시지 문구를 변경했다고 API 서버를 배포하는건 잘 안맞겠지요.반대로 사용자에게 보이는 메시지가 아니고, API를 사용하는 개발자의 디버깅용이라면 소스 코드에 있더라도 괜찮을 것 같습니다. 변경이 필요하면 서두를 필요 없이 다음 서버 배포할 때 배포하면되니까요. 저는 REST API는 다양한 크기/구성의 클라이언트가 호출할 수 있으므로 화면에 보이는 메시지는 API 응답으로 보내는게 맞지 않는다고 생각합니다. 그래서 API가 에러 코드를 보내면, SPA가 메시지를 선택해서 표시하는걸 좋아합니다. 메시지 문구는 SPA와 함께 배포하고요.

커피한잔마시고1 · Answer

예외 메시지를 DB로 추가해도 서버 재배포는 해야하죠.왜냐하면 예외처리 로직(예외 처리관련 소스코드 추가)이 추가되기 때문입니다.그렇다는건 DB를 쓰든 Enum을 쓰든 서버 재배포를 해야한다는 건데, 말씀하신 서버 재배포 문제점이 해당되는 지 궁금하네요.

집킨 · Answer

예외 메세지 조회하려고 DB 커넥션을 쓰기엔 커넥션이 너무 소중합니다

엡실론 · Answer

데이터 베이스 방식의 장점은 서버 배포 없이 간단하게 데이터 베이스에 저장된 데이터만 수정하면 된다 인데, 반대로 말하면 이게 굉장한 단점입니다.따로 파일로 관리하는 경우는 git이나 다른 형상 관리 툴로 버전 관리가 되고, 누가 이 문구를 왜 수정했는지 알 수도 있고, 실수로 수정하면 롤백도 간단합니다.데이터베이스는 누가 날려 먹을 수도 있고, 따로 작업하지 않으면 수정 이력보기도 힘들고, 잘 못 수정한 경우 백업에서 복구할 수는 있지만 git에서 롤백하는 것보다는 복잡합니다.관리의 편리함, 서비스의 안정성 vs 배포의 속도, 용이성 에서 필요한 걸 선택하시면 됩니다. CI/CD가 잘 되어 있으면 배포가 어려운 것도 아니고, 배포의 속도가 빠른게 꼭 좋은건 아니라 저라면 데이터베이스는 절대 피합니다.

신입개발자n · Answer

선배님들의 의견이 각자 다들 다르시군요

장독깨기 · Answer

어떤 방식을 쓰든 크게 상관 없어 보입니다.데이터베이스에 관리하면 특정 상황에서는 배포가 필요 없을 수 있지만, 추가, 삭제 등은 어짜피 배포가 필요합니다.케이스마다 배포하고 말고 이런 식으로 운영하는 건 좀 별로란 생각이 듭니다.그럼 Enum 으로 하는 것이 유리하냐. 딱히 그렇다 말 할수는 없습니다.그니까, 굳이 유불리를 따질 필요가 없는거죠.관리해야 할 메시지가 많고 일관성을 지키고 싶고 그걸 쳐다보는 사람이 개발자 외에도 많아요.그럼, 데이터베이스로 관리하는 것이 편할 수 있습니다. 개발자 입장에서도 편합니다.이게 아니라면, 그냥 소스 레벨에서 관리해도 됩니다. 가급적 별도 파일에서 관리하는 것이 좋겠죠.근데, 전 이것도 귀찮아서 그냥 소스에 메시지 추가해 넣습니다. 별로 바람직하지 않지만, 게을러서 귀찮은게 더 커요. :)

예외 메시지 관리 방법에 대한 조언 요청: Enum vs. Database

9개의 답변

기술 목록