Backend/Spring

앞선 포스트에서 Log4j2의 MDC(ThreadContext)를 활용해 로그 분리를 시도하던 중, RoutingAppender와 RollingFileAppender의 차이에 대한 궁금증이 생겼다. 두 Appender는 겉보기에는 비슷해 보이지만 전혀 다른 목적과 동작 방식을 가지고 있으며, 이를 명확히 이해하지 않으면 로그 설계가 복잡해지고 운영 효율도 떨어질 수 있다. 따라서 이번 글에서는 두 Appender의 차이점, 사용 목적, 장단점을 비교하고 실제 예제와 함께 어떻게 활용할 수 있는지 정리해보려 한다.RollingFileAppender란?RollingFileAppender는 하나의 로그 파일에 지속적으로 로그를 기록하다가, 일정 조건(시간, 용량 등)을 만족하면 자동으로 새 로그 파일로 롤링(..

로그는 단순한 출력 그 이상으로,운영 시스템에서는 로그만으로 장애 원인을 추적하고, 요청 흐름을 파악하며, 비즈니스 통계를 유추하기도 한다. 그러나 로그가 뒤엉켜 있다면? 그건 오히려 디버깅을 방해하는 노이즈가 될 수 있다.따라서 이번 글에서는 로그 분리 전략 (요청별 vs 계층별)과 요청별 로그 분리를 위한 MDC 사용법에 대해 알아보려 한다.🧭로그 파일 분리 기준✅1. 계층별 로그 분리예시: Controller, Service, DAO 별 로그 파일장점계층별 흐름 추적에 용이단위 테스트/모듈 테스트 시 유용단점하나의 요청 흐름이 여러 로그에 흩어짐 → 디버깅이 번거로움실 운영에서는 요청 단위 흐름 추적이 어려움 ✅2. 요청별 로그 분리예시: API 요청별 로그 파일 생성 (/sendMessage, ..

예외 처리는 모든 애플리케이션에서 반드시 고려해야 할 요소이다. 하지만 프로젝트 규모가 커질수록 처리해야 할 예외는 많아지고,이걸 전역(Global)으로 처리할지, API별로 따로(Local) 처리할지에 대한 고민이 생기게 된다.따라서 이번 글에서는 전역 예외 처리와 개별 예외 처리의 개념과 차이, 그리고 어떤 기준으로 나눠야 할지 알아보려 한다.예외 처리 전략의 목적예외 처리는 단순히 오류를 막기 위한 기술이 아니라, 서비스 품질과 운영 효율성을 위한 전략을 의미한다. 예외 처리의 핵심 목적은 다음과 같다.사용자에게 명확하고 친절한 에러 메시지 제공클라이언트가 적절한 조치를 취할 수 있도록 상태 코드 제공로그를 통해 운영자가 원인 추적 및 진단 가능예외 상황을 비즈니스 흐름에 포함하거나 복구 처리 ..

로그를 자주 찍는 습관이 익숙하지 않다 보니,운영 중 문제가 발생해도 원인을 추적하기 어려운 경우가 많다. 로그는 단순한 디버깅을 넘어 운영에 꼭 필요한 기능이다.따라서 이번 글에서는 로그를 왜 찍어야 하는지, 주의할 점은 무엇인지에 대해 정리해보려 한다.📌 로그란 무엇인가요?로그(log)란 프로그램이 실행되는 동안 남기는 기록을 말한다.개발자와 운영자는 이 로그를 통해 프로그램의 흐름, 오류 위치, 데이터 상태 등을 확인할 수 있다. 운영 환경에서는 화면 출력이 불가능하기 때문에, 로그 파일만으로 문제를 추적하고 진단해야 한다.이 때문에 로그는 "운영의 눈"이라고도 불린다고 한다. 예시 로그 2025-07-29 10:32:11 INFO - 사용자 로그인 성공 - userId=kim✅ 로그를 찍는 이..

개발을 하다 보면, 구조는 비슷하지만 애매하게 다른 DTO를 하나의 CRUD 함수에 통합할지, 아니면 각각 따로 만들어야 할지 고민되는 순간이 있다.이번번 REST API 개발을 하면서 엔드포인트는 거의 같지만, DTO가 조금씩 달라서 공통화하기 애매한 상황을 여러 번 겪었다. 그래서 이번 글에서는 DTO가 달라도 공통 로직을 재사용할 수 있는 4가지 패턴을 정리해보려고 한다.문제 상황메시지 발송 API를 만든다고 한다면,@Datapublic class SmsSendRequestDto { private String phoneNumber; private String message;}@Datapublic class MmsSendRequestDto { private String phoneNum..

Spring 레거시 프로젝트에서 외부 JSON API를 연동하다 보면 snake_case와 camelCase 매핑 문제가 자주 발생한다.Spring Boot라면 한 줄 설정으로 끝날 일이지만, 레거시 환경에서는 DTO 바인딩이 깨져 필드가 전부 null로 들어오는 난감한 상황을 맞이하게 된다. 여러 대안을 시도했지만 한계가 있었고, 결국 DTO 대신 JsonNode로 JSON을 먼저 받고 이후 DTO로 변환하는 방식으로 우회했다.이번 글에서는 이 과정을 간단히 공유하려 한다.문제 상황요청 JSON은 아래와 같이 들어온다.{ "sender_key": "asa5gew9...", "message_type": "BASIC", "template_code": "A001_01", "callback_number..

기존 스프링 레거시 코드를 보다가 ModelMap이라는 클래스를 접했다.컨트롤러에서 처리한 데이터를 뷰로 넘기기 위해 사용하는 객체로, 전통적인 서버사이드 렌더링 방식에서는 흔히 쓰이던 방식이라고 한다. 하지만 REST API 개발을 하면서 기존 코드처럼 ModelMap을 사용하려 했더니 실제로는 잘 쓰이지 않는다는 것을 알게 되었다.왜 같은 Spring MVC 기반인데 REST API에서는 ModelMap이 필요하지 않는지 궁금했다. 따라서 이번 글에서는 ModelMap이 무엇인지, 언제 사용되며 REST 개발에서는 왜 거의 쓰이지 않는지 정리해보려 한다.ModelMap이란 무엇인가?Spring MVC에서 ModelMap은 Controller와 View 사이에서 데이터를 전달하기 위한 객체이다. 전통적..

커스텀 Validator를 새로 만들고 톰캣을 실행했더니, org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.example.CustomValidator' available라는 에러가 발생했다. 원인은 Bean 등록 누락이었고, @Service를 추가해서 해결했지만왜 이런 문제가 생기는지 궁금했다. 따라서 이번 글에서는 Spring 서비스 컴포넌트 생성 시 발생하는 Bean 주입 이슈와 해결 방법을 정리해보려 한다.왜 서비스 컴포넌트 Bean 주입 문제가 발생할까?Spring은 IoC 컨테이너가 Bean을 생성하고 의존성을 주입한다.하지만 아래와 같은 경우 컨테이너가 정상적으로 Bea..

Spring 프로젝트 구조를 설계하던 중, 웹 페이지가 필요 없는 REST API 프로젝트였기 때문에 전통적인 MVC 구조에서 View(V) 계층은 제외되었다. 초기에는 Controller - Service - ServiceImpl - Dao 형태로 단순하게 시작했지만,여러 API에서 반복되는 공통 검증 로직이 등장하면서 같은 코드를 재사용할 수 있는 구조가 필요해졌다.이때 구조를 어떻게 나눌지 고민하다가, Validator와 Handler 계층을 도입하게 되었다. 하지만 시간이 지나면서 Handler의 역할이 단순 분기 처리에 그치게 되었고,결국 이 책임은 다시 Service로 흡수되면서 Handler는 제거되었다. 이번 글에서는 그 과정에서 겪은 고민을 바탕으로, 계층 분리의 기준과 실무적 판단에 대..

클라이언트가 보내는 요청 데이터에 대해 필수 여부, 길이 제한, 형식 검사 등을 수행해야 할 때, 그 책임을 어디에 둘 것인지에 따라 코드의 가독성, 재사용성, 테스트성이 크게 달라지게 된다. 이번 글에서는 Spring 기반의 프로젝트에서 유효성 검사를 어디에 두는 것이 적절한지, 그리고 각 위치별 장단점과 사용 시점에 대해 정리해보려 한다.✅ 유효성 검사란?유효성 검사(Validation)는 클라이언트가 보낸 데이터가 시스템이 요구하는 조건을 만족하는지 확인하는 과정이다. 예시빈 값 검사숫자 범위 검사날짜 형식 검사enum 값 제한JSON 구조의 필수 속성 체크 📍 유효성 검사를 할 수 있는 위치들Spring에서는 보통 다음과 같은 위치에서 유효성 검사를 수행한다. 위치 설명 1. Controll..