[스프링 핵심 원리 - 고급편 ] #03. 템플릿 메서드 패턴과 콜백 패턴(2)

[Pracrobo]

전략패턴 - 시작

코드

Test > trace > strategy > ContextV1Test

package hello.advanced.trace.strategy;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

@Slf4j
public class ContextV1Test {

    @Test
    void strategyV0() {
        logic1();
        logic2();
    }

    private void logic1() {
        long startTime = System.currentTimeMillis();
        log.info("비즈니스 로직1 실행");
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime ={}", resultTime);

    }

    private void logic2() {
        long startTime = System.currentTimeMillis();
        log.info("비즈니스 로직2 실행");
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime ={}", resultTime);

    }
}

실행

전략 패턴 - 예제 1

이번에는 동일한 문제를 전략 패턴으로 사용해서 해결해본다

변하지 않는 부분은 Context 로 두고 변하는 부분은 Strategy 라는 인터페이스를 만들고 해당 인터페이스를 구현하도록 해서 문제를 해결한다

상속이 아니라 위임/구성으로 문제를 해결하는 것이다. Strategy 로 위임

전략패턴에서 Context 는 변하지 않는 템플릿 역할을 하고 Strategy 는 변하는 알고리즘 역할을 한다.

GOF 디자인 패턴에서 정의한 전략 패턴의 의도는 다음과 같다

알고리즘 제품군을 정의하고 각각을 캡슐화하여 상호교환 가능하게 만들자. 전략을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다.

• interface

trace > strategy > code > strategy

package hello.advanced.trace.strategy.code.strategy;

public interface Strategy {
    void call();
}

• logic1

StrategyLogic1

package hello.advanced.trace.strategy.code.strategy;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class StrategyLogic1 implements Strategy {
    @Override
    public void call() {
        log.info("비즈니스 로직1 실행");
    }
}

• 변하는 알고리즘은 Strategy 인터페이스를 구현하면 된다 여기서는 비즈니스 로직1을 구현했다.

• logic2

package hello.advanced.trace.strategy.code.strategy;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class StrategyLogic2 implements Strategy {
    @Override
    public void call() {
        log.info("비즈니스 로직2 실행");
    }
}

trace > strategy

package hello.advanced.trace.strategy.code.strategy;

import lombok.extern.slf4j.Slf4j;

/**
 * 필드에 전략을 보관하는 방식
 */
@Slf4j
public class ContextV1 {
    private Strategy strategy;

    public ContextV1(Strategy strategy) {
        this.strategy = strategy;
    }

    public void execute() {
        long startTime = System.currentTimeMillis();
        strategy.call(); //위임
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime ={}", resultTime);

    }
}

ContextV1은 변하지 않는 로직을 가지고 있는 템플릿 역할을 하는 코드이다. 전략 패턴에서는 이것을 컨텍스트(문맥) 이라고 한다.

쉽게 이야기해서 컨텍스트(문맥)는 크게 변하지 않지만, 그 문맥 속에서 ‘Strategy’ 를 통해 일부 전략이 변경된다 생각하면 된다.

Context 는 내부에 Strategy strategy 필드를 가지고 있다.

• private Strategy strategy;

이 필드에 변하는 부분인 Strategy의 구현체를 주입하면 된다. (생성자를 통해 의존관계 주입을 하고 있다) 전략 패턴의 핵심은 Context는 Strategy 인터페이스에만 의존한다는 점이다. 덕분에 Strategy 의 구현체를 변경하거나 새로 만들어도 Context 코드에는 영향을 주지 않는다.

스프링에서 의존관계 주입에서 사용하는 방식이 이 전략 패턴이다.

테스트 코드 작성 - strategyV1 (전략패턴)

   @Test
    void strategyV1() {
        StrategyLogic1 strategyLogic1 = new StrategyLogic1();
        ContextV1 contextV1 = new ContextV1(strategyLogic1);
        contextV1.execute();

        StrategyLogic2 strategyLogic2 = new StrategyLogic2();
        ContextV1 contextV2 = new ContextV1(strategyLogic2);
        contextV2.execute();
    }

코드를 보면 의존관계 주입을 통해 ContextV1에 Strategy의 구현체인 strategyLogic1 을 주입하는 것을 확인할 수 있다.

이렇게해서 Context 안에 원하는 전략을 주입한다. 이렇게 원하는 모양으로 조립을 완료하고 난 다음에 context1.execute()를 호출해서 context 를 실행한다.

전략 패턴 실행 그림

1. Context 에 원하는 Strategy 구현체를 주입한다.
2. 클라이언트는 context를 실행한다.
3. context는 context 로직을 시작한다.
4. context 로직 중간에 strategy.call() 호출해서 주입받은 strategy 로직을 실행한다.
5. context 는 나머지 로직을 실행한다.

실행결과

• 템플릿 메서드와 다른점 : 구현체가 implements 로 자식이 부모에게 의존 (코드 변경 가능성 있음) vs interface에만 의존
• 전략패턴이 위임을 사용해 좀 더 안정적이다.

전략 패턴 - 예제2

전략패턴도 익명 내부 클래스를 사용할 수 있다.

    @Test
    void strategyV2() {
        Strategy strategyLogic1 = new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        };
        ContextV1 context1 = new ContextV1(strategyLogic1);
        context1.execute();
    }

실행

logic2

        Strategy strategyLogic2 = new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        };
        ContextV1 context2 = new ContextV1(strategyLogic2);
        context2.execute();
        

실행

로그찍기

• *log*.info("strategyLogic1={}" ,strategyLogic1.getClass());
• *log*.info("strategyLogic2={}" ,strategyLogic2.getClass());

    @Test
    void strategyV2() {
        Strategy strategyLogic1 = new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        };
        ContextV1 context1 = new ContextV1(strategyLogic1);
        log.info("strategyLogic1={}", strategyLogic1.getClass());
        context1.execute();

        Strategy strategyLogic2 = new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        };
        ContextV1 context2 = new ContextV1(strategyLogic2);
        log.info("strategyLogic2={}", strategyLogic2.getClass());
        context2.execute();
    }

실행

• $ 와 같이 익명 내부 클래스가 생성된 것을 확인할 수 있다.

ContextV1Test - 추가

• inline으로 합치기 - ctrl+alt_N

    @Test
    void strategyV3() {
        ContextV1 context1 = new ContextV1(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        });
        context1.execute();

        ContextV1 context2 = new ContextV1(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        });
        context2.execute();
    }

• 기존 코드에서 인라인으로 합쳐서 변수를 받아서 넣는 방법을 인라인으로 바꿔준다.
• 단축키 : Ctrl+ Alt + N

ContextV1 contextx = new ContextV1(() -> *log*.info("비즈니스 로직 실행"));

• lambda로 변경
• 단축키 : Alt + Enter

    @Test
    void strategyV4() {
        ContextV1 context1 = new ContextV1(() -> log.info("비즈니스 로직1 실행"));
        context1.execute();

        ContextV1 context2 = new ContextV1(() -> log.info("비즈니스 로직2 실행"));
        context2.execute();
    }

• 실행결과 똑같음
• 결과적으로 리팩토링한 것

정리

    /**
     * 전략 패턴 익명 내부 클래스 2
     */
    @Test
    void strategyV3() {
        ContextV1 context1 = new ContextV1(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        });
        context1.execute();

        ContextV1 context2 = new ContextV1(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        });
        context2.execute();
    }

• 익명 내부 클래스를 변수에 담아두지 말고 생성하면서 바로 ContextV1에 전달해도 된다.

    /**
     * 전략 패턴 - 람다
     */
    @Test
    void strategyV4() {
        ContextV1 context1 = new ContextV1(() -> log.info("비즈니스 로직1 실행"));
        context1.execute();

        ContextV1 context2 = new ContextV1(() -> log.info("비즈니스 로직2 실행"));
        context2.execute();
    }

• 익명 내부 클래스를 자바8부터 제공하는 람다로 변경할 수 있다. 람다로 변경하려면 인터페이스에 메서드가 1개만 있으면 되는데 여기에서 제공하는 Strategy 인터페이스는 메서드가 1개만 있으므로 람다로 사용할 수 있다

package hello.advanced.trace.strategy.code.strategy;

public interface Strategy {
    void call();
}

• 람다 내용은 자바 기본 문법

• 지금까지 일반적으로 이야기하는 전략패턴에 대해서 알아보았다. 변하지 않는 부분을 Context에 두고 변하는 부분을 Strategy 를 구현해서 만든다.

• 그리고 Context의 내부 필드에 Strategy 를 주입해서 사용했다.

선 조립 후 실행

• 여기서 이야기하고 싶은 부분은 Context 의 내부 필드에 Strategy 를 두고 사용하는 부분이다.
• 이 방식은 Context 와 Strategy를 실행하기 전에 원하는 모양으로 조립해두고 그 다음에 Context를 실행하는 선 조립 후 실행 방식에서 매우 유용하다.
• Context와 Strategy를 한번 죕하고 나면 이후로는 Context를 실행하기만 하면 된다. 우리가 스프링으로 애플리케이션을 개발할때 애플리케이션 로딩 시점에 의존관계 주입을 통해 필요한 의존관계를 모두 맺어두고 난 다음에 실제 요청을 처리하는 것과 같은 원리이다.
• 이 방식의 단점은 Context와 Strategy를 조립한 이후에는 전략을 변경하기가 번거롭다는점이다. Context 에 setter를 제공해서 Strategy를 넘겨받아 변경하면 되지만, Context 를 싱글톤으로 사용할때는 동시성 이슈 등 고려할 점이 많다.
• 그래서 전략을 실시간으로 변경해야하면 차라리 이전에 개발한 테스트 코드처럼 Context를 하나 더 생성하고 그곳에 다른 Strategy 를 주입하는 것이 더 나은 선택일 수 있다.

이렇게 먼저 조립하고 사용하는 방식보다 더 유연하게 전략패턴을 사용하는 방법은 없을까?

전략패턴 - 예제 3

Context의 필드에 Strategy 를 주입해서 사용한다.

package hello.advanced.trace.strategy.code.strategy;

import lombok.extern.slf4j.Slf4j;

/**
 * 전략을 파라미터로 전달 받는 방식
 */
@Slf4j
public class ContextV2 {

    public void execute(Strategy strategy) {
        long startTime = System.currentTimeMillis();
        strategy.call(); //위임
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime ={}", resultTime);

    }
}

ContextV2는 전략을 필드로 가지지 않는다. 대신에 전략을 execute()가 호출되때마다 항상 파라미터로 전달받는다.

package hello.advanced.trace.strategy;

import hello.advanced.trace.strategy.code.strategy.ContextV2;
import hello.advanced.trace.strategy.code.strategy.StrategyLogic1;
import hello.advanced.trace.strategy.code.strategy.StrategyLogic2;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

@Slf4j
public class ContextV2Test {
    /**
     * 전략 패턴 적용
     */
    @Test
    void strategyV1() {
        ContextV2 context = new ContextV2();
        context.execute(new StrategyLogic1());
        context.execute(new StrategyLogic2());

    }
}

• 단축키 introduce variable : ctrl+alt+v
• Context와 Strategy 를 선조립 후 실행 하는 방식이 아니라 Context를 실행할때마다 전략을 인수로 전달한다. 클라이언트는 Context를 실행하는 시점에 원하는 Strategy를 전달할 수 있다. 따라서 이전 방식과 비교해서 원하는 전략을 저더욱 유연하게 변경할 수 있다.
• 테스트 코드를 보면 하나의 Context 만 생성한다. 그리고 하나의 Context 에 실행 시점에 여러 저략을 인수로 전달해서 유연하게 실행하는 것을 확인할 수 있다.

전략 패턴 파라미터 실행 그림

1. 클라이언트는 Context를 실행하면서 인수로 Strategy를 전달한다.
2. Context는 execute()로직을 실행한다.
3. Context는 파라미터로 넘어온 strategy.call() 로직을 실행한다.
4. Context의 execute()로직이 종료된다.

코드 - 전략패턴 익명 내부 클래스

    /**
     * 전략 패턴 익명 내부 클래스
     */
    @Test
    void strategyV2() {
        ContextV2 context = new ContextV2();
        context.execute(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        });
        context.execute(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        });
    }

코드 조각을 넘긴다고 생각하면 된다.

코드 - 전략패턴 익명 내부 클래스 : 람다

    /**
     * 전략 패턴 익명 내부 클래스2, 람다
     */
    @Test
    void strategyV3() {
        ContextV2 context = new ContextV2();
        context.execute(() -> log.info("비즈니스 로직1 실행"));
        context.execute(() -> log.info("비즈니스 로직2 실행"));
    }

• 람다를 사용해서 코드를 더 단순하게 만들 수 있다.

정리

ContextV1은 필드에 Strategy 를 저장하는 방식으로 전략패턴을 구사했다.

• 선 조립 후 실행 방법에 적합하다.
• Context를 실행하는 시점에는 이미 조립이 끝났기 때문에 신경쓰지 않고 단순히 실행만 하면 된다.

ContextV2 는 파라미터에 Strategy를 전달하는 방식으로 전략패턴을 구사했다.

• 실행할때마다 전략을 유연하게 변경할 수 있다.
• 단점 역시 실행할때마다 전략을 계속 지정해주어야 한다는 점이다.

템플릿

지금 우리가 해결하고 싶은 문제는 변하는 부분과 변하지 않는 부분을 분리하는 것이다.

변하지 않는 부분을 템플릿이라 하고 그 템플릿 안에서 변하는 부분에 약간 다른 코드 조각을 넘겨서 실행하는 것이 목적이다.

ContextV1 , ContextV2 두가지 방식 다 문제를 해결할 수 있지만 어떤 방식이 더 나아보이는가?

지금 우리가 원하는 것은 애플리케이션 의존 관계를 설정하는 것처럼 선 조립, 후 실행이 아니다. 단순히 코드를 실행할때 변하지 않는 템플릿이 있고 그 템플릿 안에서 원하는 부분만 살짝 다른 코드를 실행하고 싶을 뿐이다.

따라서 우리가 고민하는 문제는 실행 시점에 유연하게 실행 코드 조각을 전달하는 ContexV2 가 더 적합하다.

• 디자인 패턴은 의도가 중요하다~

템플릿 콜백 패턴 - 시작

ContextV2는 변하지 안흔 템플릿 역할을 한다. 그리고 변하는 부분은 파라미터로 넘어온 Strategy 의 코드를 실행해서 처리한다. 이렇게 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 콜백 Callback 이라 한다.

콜백 정의

프로그래밍에서 콜백 또는 콜애프터 함수(call-after function)는 다른 코드의 인수로서 넘겨주는 실행가능한 코드를 말한다 콜백을 넘겨받는 코드는 이 콜백을 필요에 따라 즉시 실행할 수도 있고 아니면 나중에 실행할 수도 있다.

콜백 코드들

void strategyV3()

log.info("비즈니스 로직1 실행")

void strategyV2()

context.execute(**new Strategy() {
	@Override
	public void call() {
		log.info("비즈니스 로직1 실행");
	}**
}

public class ContextV2Test > void strategyV1()

new StrategyLogic1()

쉽게 이야기해서 callback은 코드가 호출(call)은 되는데 코드를 넘겨준 곳의 뒤(back)에서 실행된다는 뜻이다.

• ContextV2 예제에서 콜백은 Strategy 이다.
• 여기에서는 클라이언트에서 직접 Strategy를 실행하는 것이 아니라 클라이언트가 ContextV2.execute()를 실행할때 Strategy를 넘겨주고 ContextV2 뒤에서 Strategy 가 실행된다.

자바 언어에서 콜백

• 자바 언어에서 실행 가능한 코드를 인수로 넘기려면 객체가 필요하다. 자바 8부터는 람다를 사용할 수 있다.
• 자바 8 이전에는 보통 하나의 메소드를 가진 인터페이스를 구현하고 주로 익명 내부 클래스를 사용했다
• 최근에는 주로 람다를 사용한다.

템플릿 콜백 패턴

• 스프링에서는 ContextV2 와 같은 방식의 전략 패턴을 템플릿 콜백 패턴이라 한다. 전략 패턴에서 Context 가 템플릿 역할을 하고 Strategy 부분이 콜백으로 넘어온다 생각하면 된다.
• 참고로 템플릿 콜백 패턴은 GOF 패턴 아니고 스프링 내부에서 이런 방식을 자주 사용하기 때문에 스프링 안에서만 이렇게 부른다. 전략 패턴에서 템플릿과 콜백 부분이 강조된 패턴이라 생각하면 된다.
• 스프링에서는 JdbcTemplate , RestTemplate , TransactionTemplate , RedisTemplate 처럼 다양한 템플릿 콜백 패턴이 사용된다. 스프링에서 이름에 XxxTemplate 가 있다면 템플릿 콜백 패턴으로 만들어져 있다 생각하면 된다.
  

템플릿 콜백 패턴 - 예제

• Context → Template
• Strategy → Callback

package hello.advanced.trace.strategy.code.template;

public interface Callback {
    void call();
   
}

package hello.advanced.trace.strategy.code.template;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class TimeLogTemplate {

    public void execute(Callback callback) {
        long startTime = System.currentTimeMillis();
        callback.call(); //위임
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime ={}", resultTime);

    }
}

Test 코드

package hello.advanced.trace.strategy.code.strategy;

import hello.advanced.trace.strategy.code.template.Callback;
import hello.advanced.trace.strategy.code.template.TimeLogTemplate;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

@Slf4j
public class TemplateCallbackTest {
    /**
     * 템플릿 콜백 패턴 - 익명 내부 클래스
     */

    @Test
    void callbackV1() {
        TimeLogTemplate template = new TimeLogTemplate();
        template.execute(new Callback() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        });
        template.execute(new Callback() {
            @Override
            public void call() {
                log.info("비즈니스 로직 2 실행");
            }
        });
    }
}

실행

lambda

    @Test
    void callbackV2() {
        TimeLogTemplate template = new TimeLogTemplate();
        template.execute(() -> log.info("비즈니스 로직1 실행"));
        template.execute(() -> log.info("비즈니스 로직 2 실행"));
    }

실행

• 별도의 클래스를 만들어서 전달해도 되지만 , 콜백을 사용할 경우 익명 내부 클래스나 람다를 사용하는 것이 편리하다.
• 물론 여러 곳에서 함께 사용되는 경우 재사용을 위해 콜백을 별도의 클래스로 만들어도 된다.

템플릿 콜백 패턴 - 적용

• 이제 템플릿 콜백 패턴을 애플리케이션에 적용시켜보자.

package hello.advanced.trace.callback;

import hello.advanced.trace.TraceStatus;
import hello.advanced.trace.logtrace.LogTrace;

public class TraceTemplate {
    private final LogTrace trace;

    public TraceTemplate(LogTrace trace) {
        this.trace = trace;
    }

    public <T> T execute(String message, TraceCallback<T> callback) {

        TraceStatus status = null;
        // 타입에 대한 정보를 객체 생성때로 미룸
        try {

            status = trace.begin(message);
            // 로직호출
            T result = callback.call();
            trace.end(status);
            return result;

        } catch (Exception e) {
            trace.exception(status, e);
            throw e;

        }
    }
}

• TraceTemplate 는 템플릿 역할을 한다.
• execute() 를 보면 message 데이터와 콜백인 TraceCallback callback 을 전달받는다.
• <T> 제네릭을 사용했다. 반환타입을 정의한다.

Controller

package hello.advanced.app.v5;

import hello.advanced.trace.callback.TraceCallback;
import hello.advanced.trace.callback.TraceTemplate;
import hello.advanced.trace.logtrace.LogTrace;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController // @Controller + @ResponseBody
public class OrderControllerV5 {
    private final OrderServiceV5 orderService;
    private final TraceTemplate template;

    public OrderControllerV5(OrderServiceV5 orderService, LogTrace trace) {
        this.orderService = orderService;
        this.template = new TraceTemplate(trace);
    }

    @GetMapping("/v5/request")
    public String request(String itemId) {
        return template.execute("OrderController.request()",
            new TraceCallback<>() {
                @Override
                public String call() {
                    orderService.orderItem(itemId);
                    return "ok";
                }
            });
    }
}

• this.template = new Template(trace) : trace 의존 관계 주입을 받으면서 필요한 TraceTemplate 템플릿을 생성한다. 참고로 TraceTemplate 을 처음부터 스프링 빈으로 등록하고 주입받아도 된다. 이 부분은 선택이다.
• template.execute(.., new TraceCallback() {...} : 템플릿을 실행하면서 콜백을 전달한다. 여기서는 콜백으로 익명 내부 클래스를 사용했다.

Service

package hello.advanced.app.v5;

import hello.advanced.trace.callback.TraceTemplate;
import hello.advanced.trace.logtrace.LogTrace;
import org.springframework.stereotype.Service;

@Service
public class OrderServiceV5 {
    private final OrderRepositoryV5 orderRepository;
    private final TraceTemplate template;

    public OrderServiceV5(OrderRepositoryV5 orderRepository, LogTrace trace) {
        this.orderRepository = orderRepository;
        this.template = new TraceTemplate(trace);
    }

    public void orderItem(String itemId) {
        template.execute("OrderService.orderItem()", () -> {
            orderRepository.save(itemId);
            return null;
        });
    }
}

Repository

package hello.advanced.app.v5;

import hello.advanced.trace.callback.TraceTemplate;
import hello.advanced.trace.logtrace.LogTrace;
import org.springframework.stereotype.Repository;

@Repository
public class OrderRepositoryV5 {
    private final TraceTemplate template;

    public OrderRepositoryV5(LogTrace trace) {
        this.template = new TraceTemplate(trace);
    }

    public void save(String itemId) {
        template.execute("OrderRepository.save()", () -> {
            if (itemId.equals("ex")) {
                throw new IllegalArgumentException("예외발생! ");
            }
            sleep(1000);
            return null;
        });
    }

    private void sleep(int millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

정리

템플릿 메서드 패턴, 전략 패턴, 그리고 템플릿 콜백 패턴까지 진행하면서 변하는 코드와 변하지 않는 코드를 분리했다. 그리고 최종적으로 템플릿 콜백 패턴을 적용하고 콜백으로 람다를 사용해서 코드 사용도 최소화 할 수 있었다.

한계

그런데 지금까지 설명한 방식의 한계는 아무리 최적화를 해도 결국 로그 추적기를 적요하기 위해서 원본 코드를 수정해야 한다는 점이다. 클래스가 수백개이면 수백개를 더 힘들게 수정하는가 조금 덜 힘들게 수정하는가의 차이가 있을뿐 코드를 다 수정해야하는 본질적인것은 마찬가지이다ㅣ.

개발자의 게으름에 대한 욕심은 끝이 없다.

수많은 개발자가 이 문제에 대해서 집요하게 고민해왔고 여러가지 방향으로 해결책을 만들어왔다.

지금부터 원본 코드를 손대지 않고 로그 추적기를 적용할 수 있는 방법을 알아보자.

프록시의 개념을 이해해야 한다.

참고

지금까지 설명한 방식은 실제 스프링 안에서 많이 사용되는 방식이다. ``XxxTemplate" 을 만나면 이번에 학습한 내용을 떠올리면 된다.