Spring/SpringCore - advance8

• 

  스프링 핵심원리( 심화 ) - 프록시 패턴과 데코레이터 패턴(2) 앞서, 추가되었던 요구사항과 함께 지금까지 만들어 온 로그 추적기에 대한 내용 역시 정리해보자. 기존 요구사항→ 모든 Public 메서드의 호출과 응답 정보를 로그로 출력 → 애플리케이션의 흐름을 변경하면 안됨 - 로그를 남긴다고 해서 비즈니스 로직의 동작에 영향을 주면 안됨→ 메서드 호출에 걸린 시간 → 정상 흐름과 예외 흐름 구분 - 예외 발생 시 예외 정보가 남아야 함→ 메서드 호출의 깊이 표현 → HTTP 요청을 구분 - HTTP 요청 단위로 특정 ID를 남겨 어떤 HTTP 요청에서 비롯된 것인지 명확하게 구분할 수 있도록 한다. - 트랜잭션ID (DB 트랜잭션 ❎) 예시 하지만, 지금까지 개발한 로그 추적기는 위의 요구사항을 만족하기 위해서 기존 코드를 많이 수정해야 하는 상황이다. .. Spring/SpringCore - advance 2025. 8. 23.

• 스프링 핵심원리( 심화 ) - 프록시 패턴과 데코레이터 패턴(1) 이번에는 스프링을 이루는 핵심 디자인 패턴의 일부로 프록시 패턴에 대해서 알아보자. 앞서 다뤘던, 템플릿 콜백 패턴을 비롯하여 공통 로직을 최대한 애플리케이션의 전반적으로 걸쳐 재사용할 수 있도록 하는 방법에 대해서 알아봤었다. 그러나, 여전히 로그 기능 추가로 인한 코드의 수정이 불가피하였다. 그리고 이는 개발자에게 가장 큰 문제로 남게 된다. 따라서 원본 코드의 수정을 필요로하지 않으며, 로그 추적기를 적용할 수 있는 방법에 대해 알아보기 위한 방법을 목표로 내용을 정리해보겠다. 기존 코드의 작동에서 아래와 같은 요구사항이 추가되었다. 요구사항 추가 - 원본 코드 수정없이 로그 추적기를 적용하라. - 특정 메소드는 로그를 출력하지 않도록 하라. → 보안상 일부는 로그를 출력하지 않는 기능 - 다.. Spring/SpringCore - advance 2025. 8. 10.

• 

  스프링 핵심원리( 심화 ) - 로그 추적기와 디자인패턴( 템플릿 콜백 패턴 ) 앞서 다룬 내용으로 ContextV1, ContextV2는 변하지 않는 템플릿 역할을 담당하였다. 그리고 변하는 부분을 Strategy 인터페이스로 정의하고 파라미터로 넘겨받아 해당 구현체의 코드를 실행하여 처리하도록 구성했었다. 이와 같이 다른 코드의 인수로 넘겨주는 실행 가능한 코드를 콜백(CallBack)이라고 부른다. 콜백이란?콜백은 다른 코드를 파라미터로 넘겨주는 실행 가능한 코드를 일컫어 표현한다. 콜백을 넘겨받는 코드는 이 콜백을 필요에 따라 실행하는 것이다. 즉, CallBack은 코드의 실행이 코드를 넘겨준 곳의 뒤에서 실행된다는 의미이다. 지금까지 다룬 코드를 기준으로 설명하자면, ContextV2 예제에서 콜백은 Strategy에 해당한다.여기에서 클라이언트가 직접 Strategy.. Spring/SpringCore - advance 2025. 5. 30.

• 

  스프링 핵심원리( 심화 ) - 로그 추적기와 디자인패턴( 전략 패턴 ) 앞서 로그 추적기를 개발하면서 템플릿 메서드 패턴을 적용하여로그 추적기 기능 관련 코드가 중복되는 현상을 상속과 오버라이딩을 사용하는 템플릿 메서드 패던을 적용하여 개선하였다. 하지만, 상속을 통한 해결에는 결합도가 높아지고, 단일 상속의 한계가 존재하는 등의 상황이 후에 도출될 수 있다. 따라서 상속보단 조합의 방향성을 가지고 서비스 로직마다 변하는 부분과 변하지 않는 부분( 로그 추적기 )을 분리하여 개선하는 방법으로 전략 패턴을 적용해보자. 전략 패턴 적용 전략 패턴은 템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴이다.그 구체적인 방법은 상속이 아닌 위임(조합)을 사용하는 것이다. 템플릿 메서드 패턴의 구조와 전략 패턴의 구조를 비교하여 이해해보자.먼저, 템플.. Spring/SpringCore - advance 2025. 3. 16.

• 

  스프링 핵심원리( 심화 ) - 로그 추적기와 디자인패턴( 템플릿 메서드 패턴 ) 지금까지 요구사항을 충족하며 로그 추적기를 만들어 왔고,파라미터를 넘기는 불편함과 동시성 문제를 해결하기 위해 ThreadLocal까지 도입하였다.  그리고 로그 추적기를 도입한 코드의 상태는 아래와 같다. @RestController@RequiredArgsConstructor@Slf4jpublic class OrderControllerV3 { private final OrderserviceV3 orderservice; private final LogTrace logTrace; @GetMapping("/v3/request") public String request(String item) { TraceStatus status = null; try{ .. Spring/SpringCore - advance 2025. 2. 19.

• 

  스프링 핵심원리( 심화 ) - 로그 추적기와 동시성( ThreadLocal 사용 ) 앞서 로그 추적기를 구현함에 파라미터로 로그의 동기화를 위해 TraceId를 넘기는 방법을 선택했었다.이러한 구현에는 모든 로직에 파라미터를 추가하는 번거로움이나 컨트롤러가 없는 다른 서비스의 호출에 사용하지 못하는 문제가 있었다. 따라서 로그 추적 객체가 스스로 상태값을 변경할 수 있도록 로직을 개선하였다.하지만, 객체 내부의 인스턴스 필드로 상태값을 저장하는 구현은 다중 스레드가 접근하는 경우 동시성 문제를 야기하였다.  그리고 이번 포스팅에서는 동시성 문제를 해결할 수 있는 ThreadLocal에 대해서 다뤄보겠다. ThreadLocalThreadLocal은 특정 하나의 쓰레드만 접근할 수 있는 저장소를 제공한다.  즉, 사용자 a와 사용자 b 각자를 인식하여 저장소를 제공하고 정해진 저장소를 통해.. Spring/SpringCore - advance 2025. 2. 16.

• 

  스프링 핵심원리( 심화 ) - 로그 추적기와 동시성( 로그 추적기 개발과 동시성 문제 ) 로그 추적기 개발 앞서 로그 추적기를 구현하였다.그리고 해당 로그를 출력함에 있어 트랜잭션ID 와 level 수준을 나타내기 위해 TraceId객체를 파라미터로 넘기도록 구현이 필요하였다.  그런데, 이러한 방식은 모든 메서드들에 파라미터를 추가해야하는 문제를 야기한다.TraceId를 파라미터로 넘기지 않으면서도 문제를 해결할 방법에 대해서 알아보자. 이런 문제 지점들을 해결하기 위해 로그 추적기를 더 발전시킬 것이다.먼저, 향후 다양한 구현체로 변경할 수 있도록 LogTrace 인터페이스를 만든다.public interface LogTrace { TraceStatus begin(String message); void end(TraceStatus status); void exception.. Spring/SpringCore - advance 2025. 2. 15.

• 

  스프링 핵심원리( 심화 ) - 로그 추적기와 동시성( 로그 추적기 개발 ) 로그 추적기의 필요성서비스가 점차 거대해지고 사용되는 소스 코드와 클래스가 수 십만 라인에 수 백개 이상이 존재한다면, 점차적으로 운영 환경에서의 모니터링과 운영이 중요해진다. 특히 성능적인 이슈와 관련하여 병목과 같은 현상에서 병목의 발생 지점을 파악하거나 예외 발생 지점 등을 파악하는 것이 필요해진다. 그리고 이러한 지점들을 로그로 남기는 것이 어플리케이션의 실행과 운영에서 상태 파악과 많은 문제들에 대한 힌트를 제공할 수 있기에 중요한 부분이다.  따라서 로그 추적기를 개발하면서 다음과 같은 요구 사항들을 구현해보자.요구사항 ✅ 모든 PUBLIC 메서드의 호출과 응답 정보를 로그로 출력 ✅ 애플리케이션의 흐름을 변경하면 안됨   로그를 남긴다고 해서 비즈니스 로직의 동작에 영향을 주면 안됨 ✅ 메서.. Spring/SpringCore - advance 2025. 2. 14.