⭐ Spring AOP, 🤔 Proxy로 정리해보자!

AOP(Aspect Oriented Programming)

: 관점 지향 프로그래밍

스프링 어플리케이션은 대부분 특별한 경우를 제외하고는 MVC 웹 어플리케이션에서는 Web Layer, Business Layer, Data Layer 로 정의.

• Application Layer : REST API를 제공하며, Client 중심의 로직 적용
• Business Layer : 내부 정책에 따른 logic를 개발하며, 주로 해당 부분을 개발
• Data Layer : 데이터 베이스 및 외부와의 연동을 처리

스프링 DI가 의존성(new) 주입이라면,

⭐ 스프링 AOP는 로직(code) 주입이라고 볼 수 있다.

로깅, 보안, 트랜잭션, validation 등등 공통된 기능을 모아놓아 반복적으로 나타나는 부분이 있는데 이를 횡단관심(cross-cutting concern)이라고 한다.

✨ AOP는 핵심 비즈니스 로직에 영향을 받게 하지 않고 반복적인 공통 부분을 모듈화해 몰아주는 기술이다.

IoC 컨테이너와 AOP Proxy

Spring에는 크게 2가지 프록시 구현체를 사용한다. JDK PROXY(=Dynamic PROXY) 와 CGLib이다. Spring AOP는 PROXY의 매커니즘을 기반으로 AOP PROXY를 제공하고 있다.

위 그림처럼 Spring AOP는 사용자의 특정 호출 시점에 IoC 컨테이너에 의해 AOP를 할 수 있는 Proxy Bean을 생성해준다.

동적으로 생성된 Proxy Bean은 타깃의 메서드가 호출되는 시점에 부가기능을 추가할 메서드를 자체적으로 판단해 가로채어 부가기능을 주입한다. 이를 호출시점에 동적으로 위빙을 한다해 런타임 위빙(Runtime Weaving)이라고 한다.

Spring AOP는 런타임 위빙 방식을 기반으로 하고 있고, Spring 에서는 상황에 따라 JDK Proxy와 CGLib방식을 통해 Proxy Bean을 생성해준다.

프록시란?

JDK PROXY와 CGLib를 선택하는 기준

프록시의 사전적 정의는 '대리인'으로, 간단하게 설명하면 내가 어떤 객체를 사용하려고 할 때 해당 객체에 직접 요청하는 것이 아닌 중간에 가짜 프록시 객체(대리인)를 두어서 프록시 객체가 대신해서 요청을 받아 실제 객체를 호출해 주도록 하는 것이다.

스프링에서 사용되는 프록시 기술은 크게 두 가지로 나눌 수 있습니다.

1) JDK 동적 프록시

JDK 동적 프록시는 자바에서 제공하는 기본적인 프록시 기술입니다.
자바의 ⭐ 인터페이스를 기반으로 동작하며, 인터페이스의 구현 클래스를 자동으로 생성하여 프록시 객체를 생성합니다. 인터페이스의 메소드를 호출하면 프록시 객체는 InvocationHandler를 통해 해당 메소드를 호출하고 부가 기능을 추가합니다.

JDK 동적 프록시 기술을 사용하면 개발자가 직접 프록시 클래스를 만들지 않아도 된다. 이름 그대로 프록시 객체를 동적으로 런타임에 개발자 대신 만들어준다. 그리고 동적 프록시에 원하는 실행 로직을 지정할 수 있다.

JDK 동적 프록시 기술 덕분에 적용 대상 만큼 프록시 객체를 만들지 않아도 된다.

결과적으로 프록시 클래스를 수 없이 만들어야 하는 문제도 해결하고, 부가 기능 로직도 하나의 클래스에 모아서 단일 책임 원칙(SRP)도 지킬 수 있게 되었다.

적용후!

⭐ JDK 동적 프록시 - 한계

* JDK 동적 프록시는 인터페이스가 필수이다.

JDK 동적 프록시는 자바의 리플렉션 기술을 사용한다! 자, 그러면 리플레션 기술을 알아보자!

리플렉션은 런타임에 메서드나 필드를 찾아서 호출하기 때문에 정적 호출보다 훨씬 느리고 CPU 자원을 더 많이 소모한다.

예를 들어, 한 개발자가 직접 테스트한 결과에 따르면, 동일한 객체를 8천만 번 생성하고 필드를 설정하는 작업에서:

- 리플렉션 사용: 약 42초, CPU 사용률 44%
즉, 약 8~10배 느리고 CPU 부하도 훨씬 큼.

JDK 동적 프록시는 내부적으로 java.lang.reflect.Proxy를 사용해서 메서드를 호출할 때마다 InvocationHandler.invoke()를 통해 리플렉션으로 메서드를 찾아 실행해. 이 과정이 반복되면 성능 저하가 누적되기 때문에, 스프링에서는 CGLIB처럼 바이트코드를 직접 조작해서 정적 호출에 가까운 방식을 선호하게 된 거야.

이런 이유로, 스프링 부트는 인터페이스 유무와 상관없이 더 빠르고 유연한 CGLIB를 기본값으로 채택한 것이다!

참고로 우리가 CGLIB를 직접 사용하는 경우는 거의 없다. 이후에 설명할 스프링의 ProxyFactory 라는 것이 이 기술을 편리하게 사용하게 도와주기 때문에, 너무 깊이있게 파기 보다는 CGLIB가 무엇인지 대략 개념만 잡으면 된다.

📌 jdk 동적 프록시 vs CGLIB 라이브러리 테스트

https://velog.io/@jaeyeon93/리플렉션은-얼마나-느릴까

2) CGLIB Proxy

CGLIB (Code Generation Library) Proxy는 JDK Dynamic Proxy와 달리 인터페이스가 아닌 클래스를 기반으로 동작합니다.

런타임에 클래스의 서브클래스를 생성하여 프록시 객체를 생성합니다.

💥 단, 상속이 불가능한 final 클래스나 private 생성자를 가진 클래스는 프록시 객체를 생성할 수 없습니다.

메소드 호출 시 프록시 객체는 MethodInterceptor를 통해 해당 메소드를 호출하고 부가 기능을 추가합니다.

CGLIB란?

CGLIB 라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.

• CGLIB는 바이트코드를 조작해서 동적으로 클래스를 생성하는 기술을 제공하는 라이브러리이다.
• CGLIB를 사용하면 인터페이스가 없어도 구체 클래스만 가지고 동적 프록시를 만들어낼 수 있다.
• CGLIB가 동적으로 생성하는 클래스 이름은 다음과 같은 규칙으로 생성된다.
  대상클래스$$EnhancerByCGLIB$$임의코드
  참고로 다음은 JDK Proxy가 생성한 클래스 이름이다.
  proxyClass=class com.sun.proxy.$Proxy1

이 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있다.

가짜 프록시 객체는 실제 request scope 와는 관계가 없다. 그냥 가짜이고, 내부에 단순한 위임 로직만 있고, 싱글톤처럼 동작한다.

request scope 프록시 동작

스프링에서는 프록시 객체를 사용하기 위해 빈으로 프록시를 만들 수 있다.

⭐ 그 프록시를 request scope 프록시라고 한다.

request scope 프록시란, HTTP 요청 단위의 스코프를 가지는 빈(Bean)에 대한 프록시 객체를 의미합니다.

이러한 프록시 객체는 실제 빈이 처음 요청될 때 생성되며, 그 후에는 요청에 대한 모든 빈의 참조가 이 프록시 객체로 전달된다.

이 프록시 객체는 해당 요청 범위 내에서 빈의 생명주기를 관리하고, 빈이 스코프에서 제거될 때 해당 빈의 destroy() 메서드를 호출하여 빈이 제대로 종료되도록 보장한다.

이를 통해, Spring 애플리케이션에서 Request scope 빈을 쉽게 사용할 수 있으며, 빈이 요청 범위 내에서만 존재하고 다른 요청에서는 재사용되지 않도록 할 수 있다.

• ProxyMode를 설정하게 되면, 의존성 주입을 통해 주입되는 빈은 실제 빈이 아닌 해당 빈을 상속받은 가짜 프록시 객체이다.
• 스프링은 CGLIB이라는 바이트 코드를 조작하는 라이브러리를 사용해서 프록시 객체를 주입해준다.
• 프록시 객체 내부에는 실제 빈을 요청하는 로직이 들어있어, 클라이언트의 요청이 오면 그때 실제 빈을 호출해준다.(실제 빈의 조회를 필요한 시점까지 지연 처리)
• 프록시 객체는 원래 빈을 상속받아서 만들어지기 때문에 클라이언트 입장에서는 실제 빈을 사용하는 것과 똑같은 방법으로 사용하면 된다.
• @Scope 애노테이션의 proxyMode 옵션을 사용하여 설정할 수 있다.

@Component //클래스가 아닌 인터페이스라면 ScopedProxyMode.INTERFACE 
@Scope(proxyMode = ScopedProxyMode.TARGET_CLASS) //프록시 설정 
public class HelloBean { 
	public void hello() { ... } 
} 

@Service 
public class HelloService { 
//실제 HelloBean 객체가 아닌 가짜 프록시 객체
	@Autowired HelloBean helloBean; 

	public void method() { 
    //실제 요청이 일어날 때 프록시 객체는 실제 HelloBean의 메서드를 호출해준다. 
    helloBean.hello(); 
    } 
}

printProxyBean() 메서드를 호출해보면 자동 의존 주입을 통해 받은 HelloBean객체는 가짜 프록시 객체임을 알 수 있다.

//printProxyBean 메서드 호출 결과 
ProxyHelloBean: HelloBean$$EnhancerBySpringCGLIB$$35c7aa62
RealHelloBean: HelloBean

request scope 프록시 특징

프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있다.

사실 Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 ✅ 지연처리 한다는 점이다.

단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다. 이것이 바로 다형성과 DI 컨테이너가 가진 큰 강점이다.

꼭 웹스코프가 아니어도 프록시는 사용할 수 있다.

💥 CGLIB 제약 -> final

클래스 기반 프록시는 상속을 사용하기 때문에 몇가지 제약이 있다.

• 부모 클래스의 생성자를 체크해야 한다. CGLIB는 자식 클래스를 동적으로 생성하기 때문에 기본생성자가 필요하다.
• 클래스에 final 키워드가 붙으면 상속이 불가능하다. CGLIB에서 예외가 발생한다.
• 메서드에 final 키워드가 붙으면 해당 메서드를 오버라이딩 할 수 없다. => CGLIB에서는 프록시 로직이 동작하지 않는다.

⭐ 스프링 부트가 CGLIB를 기본 프록시 방식으로 채택한 이유!

1. 인터페이스 없이도 프록시 생성 가능
   JDK 동적 프록시는 반드시 인터페이스가 있어야만 동작해. 반면 CGLIB는 클래스를 상속해서 프록시를 만들기 때문에, 인터페이스가 없어도 프록시 생성이 가능하지. 요즘은 인터페이스 없이도 빈을 정의하는 경우가 많아지면서, CGLIB의 유연성이 더 빛을 발하게 됐어.

2. 성능 개선
   예전에는 CGLIB가 상대적으로 느리다고 여겨졌지만, JDK 프록시는 리플렉션 기반이라서 오히려 성능이 떨어지는 경우도 있어. 특히 메서드 호출이 빈번한 경우엔 CGLIB가 더 나은 성능을 보이기도 해.

3. Spring Boot의 자동 구성 철학과 잘 맞음
   스프링 부트는 개발자가 인터페이스를 꼭 만들지 않아도 빠르게 개발할 수 있도록 설계됐잖아. 그래서 인터페이스 유무에 상관없이 일관된 방식으로 프록시를 생성할 수 있는 CGLIB가 더 자연스러운 선택이 된 거야.

4. 의존성 문제 해결
   예전에는 CGLIB가 외부 라이브러리였기 때문에 신뢰성이나 의존성 관리 측면에서 부담이 있었지만, Spring 3.2부터는 spring-core에 내장되면서 이런 문제가 사라졌어.

물론 여전히 spring.aop.proxy-target-class=false 설정을 통해 JDK 프록시로 바꿀 수도 있어. 하지만 요즘은 대부분의 경우 CGLIB가 더 실용적이라 기본값으로 자리 잡은 것이다.

그외 프록시를 활용한 기술

JPA Lazy loading

Jpa 조회기능 중 lazy loading 을 통해 proxy로 호출

Spring AOP Advice(프록시 팩토리를 사용하면)

Advice는 프록시에 적용하는 부가 기능 로직이다.
이것은 JDK 동적 프록시가 제공하는 InvocationHandler 와
CGLIB가 제공하는 MethodInterceptor 의 개념과 유사한다.

둘을 개념적으로 추상화 한 것이다. 프록시 팩토리를 사용하면 둘 대신에 Advice를 사용하면 된다.

• @Transactional 아노테이션이 대표적인 예

자세한 건 이 블로그 참조
https://velog.io/@mooh2jj/스프링-트랜잭션-AOP-이해

@Transactional 을 사용하면 스프링의 트랜잭션 AOP가 적용된다.
트랜잭션 AOP는 기본적으로 프록시(Proxy) 방식을 사용한다.

간단히 정리하자면,

@Transactional 을 적용하면 프록시 객체가 요청을 먼저 받아서(위임) 트랜잭션을 대신 처리하고, 실제 객체를 호출해주는 것이다.

이 밖에 @Cachable, @Async 도 있다.

참고 블로그

• https://developer-hm.tistory.com/45 [Springbom]
• https://tonylim.tistory.com/77
• 김영한 스프링고급 원리 - <동적 프록시 기술> 편
• https://velog.io/@chullll/Transactional-과-PROXY

⭐ 그래도 interface를 사용하는 이유! -> Jdk 프록시

Spring Boot 2.x에서는 AOP 적용 시 프록시 객체 생성 방식이 기본적으로 CGLIB(구현 클래스 기반) 으로 바뀌었지만, 인터페이스를 사용하는 이유는 여전히 많고, 그 중 하나가 테스트에서 더 유리하기 때문입니다.

1) 코드의 확장이 쉬워 유지보수성이 있다!

2) 테스트코드 작성시, 목객체들로 불러와 더 빠른 테스트코드을 만들 수 있다!

✅ Mockito 같은 라이브러리는 인터페이스 기반의 Mock 객체(@Mock, @InjectMock)를 더 단순하게 생성해요. (물론 클래스도 가능하지만 제약이 있어요)

그리고 이러면, 인터페이스 기반 구조에서는 대상 객체의 의존성만 Mock 처리해, 단위 테스트 범위를 명확히 제어할 수 있어요.

---

🔥 오해하기 쉬운 부분 정리

내용	설명
CGLIB 기반이라 인터페이스가 무의미하다?	❌ 인터페이스 없으면 CGLIB 쓰는 거고, 있으면 여전히 JDK Proxy를 우선 시도해요
테스트 코드에서 인터페이스가 꼭 필요하다?	✅ 인터페이스 기반이면 테스트 작성이 더 유리하고 깔끔한 구조로 가능해요
구현 클래스도 Mock 가능하다?	✅ 가능하지만, final 클래스/메서드 등 제약 존재

---

Spring Boot 2.x에서 AOP용 프록시가 CGLIB 기반으로 바뀌었더라도, 인터페이스를 사용하면 테스트 코드 작성 시 Mock 객체를 더 쉽게 구성할 수 있어 빠르고 안정적인 단위 테스트가 가능하다.

class로 service를 만들시,

class OrderService {
    private final PaymentService paymentService = new PaymentService();

    public boolean processOrder(int amount) {
        return paymentService.pay(amount);
    }
}

@Test
void processOrder_realPaymentService() {
    OrderService orderService = new OrderService();

    boolean result = orderService.processOrder(1000);

    assertThat(result).isTrue(); // 실제 결제 로직이 실행됨
}

interface로 service 만든 방식

public interface PaymentService {
    boolean pay(int amount);
}

public class OrderService {
    private final PaymentService paymentService;

    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    public boolean processOrder(int amount) {
        return paymentService.pay(amount);
    }
}

@Test
void processOrder_mockedPaymentService() {
    // PaymentService -> Mock객체로  
    PaymentService mockPaymentService = amount -> amount < 5000;
    OrderService orderService = new OrderService(mockPaymentService);

    boolean result = orderService.processOrder(3000);

    assertThat(result).isTrue(); // 로직만 검증 가능
}

결론!

📌 구현 클래스로 DI하지 말자! 인터페이스로 하자!

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {

	// PaymentService 구현클래스
    @Mock
    PaymentService paymentService; // ⚠️ final 붙여진 클래스라면, 문제 발생 가능

    @InjectMocks
    OrderService orderService;  

    @Test
    void test() {
	 // ❌ 런타임 오류 발생 가능
 	when(paymentServiceImpl.pay(anyInt())).thenReturn(true);
        
    }
}

💡그러면 스프링부트의 어노테이션들은 전부 프록시기반으로 동작?

결론은 아니야! 하지만 대부분의 어노테이션들이 그래!

스프링 부트에서 어노테이션들이 동작하는 방식을 보면, 많은 경우 프록시 기반으로 동작한다고 볼 수 있어.

특히 AOP(Aspect-Oriented Programming) 기능을 활용하는 어노테이션들—예를 들면 @Transactional, @Async, @Cacheable 같은 것들—은 내부적으로 프록시를 생성해서 동작을 가로채는 방식으로 구현돼.

하지만 모든 어노테이션이 프록시 기반인 건 아니야. 예를 들어 @RestController, @GetMapping 같은 어노테이션은 프록시보다는 리플렉션 기반의 메타데이터 처리에 가깝고, 스프링이 애플리케이션 시작 시점에 이를 스캔해서 관련 설정을 등록하는 식으로 동작해.

즉, "대부분 프록시 기반이다"라고 생각해도 크게 틀리진 않지만, AOP나 DI(의존성 주입) 같은 영역에서 특히 그렇고, 일부 어노테이션은 다른 방식으로 동작한다!

횡단관심(공통 모듈)

횡당관심으로 뭐가 있을까?

ex. 로깅, 시간측정, 보안, 트랜잭션 등

출처: https://expert0226.tistory.com/200 [여름나라겨울이야기]

만약, 모든 메서드의 호출 시간을 측정하고 싶다면?

@Component
@Aspect
public class TimeTraceAop {

    /**
     * AOP 설정
     * @param joinPoint 실행할 메소드
     * @return 실행 결과
     * @throws Throwable 예외 발생 시
     */
    @Around("execution(* com.dsg.mallapi..*(..))")
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        System.out.println("START: " + joinPoint.toString());
        try {
            return joinPoint.proceed();
        } finally {
            long finish = System.currentTimeMillis();
            long timeMs = finish - start;
            System.out.println("END: " + joinPoint.toString() + " " + timeMs + "ms");
        }
    }

}

AOP 구성요소

/**
 * 시간 측정 AOP
 * 메서드마다 적용
 */
@Component
@Aspect
public class TimeTraceAop {


    /**
     * AOP 설정
     * @param joinPoint 조인 포인트
     * @return 실행 결과
     * @throws Throwable 예외 발생 시
     */

//    execution(* com.dsg.mallapi..*(..))
    @Pointcut("execution(* com.dsg.mallapi..*(..))")
    private void timeTracePointcut() {}


    @Around("timeTracePointcut()")
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        System.out.println("START: " + joinPoint.toString());
        try {
            return joinPoint.proceed();
        } finally {
            long finish = System.currentTimeMillis();
            long timeMs = finish - start;
            System.out.println("END: " + joinPoint.toString() + " " + timeMs + "ms");
        }
    }

}

• ✨ Aspect : 모듈
  - Advice와 Pointcut의 조합

  • 애플리케이션이 가지고 있어야 할 로직과 그것을 실행해야 하는 지점을 정의한 것, Aspect는 핵심로직과 떨어진 부가기능을 의미하는 데 쓰인다.
  • @Aspect : 클래스에 AOP 설정을 붙여주는 어노테이션

• ✨ JointPoint : 합류 지점, 메소드 실행시점
  - 횡단 공통(Crosscutting Concerns) 모듈이 삽입되어 동작할 수 있는 실행 가능한 특정 위치
  - 메소드 호출, 메소드 실행 자체, 클래스 초기화, 객체 생성 시점 등

• ✨Pointcut: 어떤 포인트(Point)에 기능을 적용할지 하지 않을지 잘라서(cut) 구분하는 것이다.
  - Pointcut은 어떤 클래스의 어느 JoinPoint를 사용할 것인지를 결정하는 필터 패턴

  • 가장 일반적인 Pointcut은 ‘특정 클래스에 있는 모든 메소드 호출’로 구성

• ✨ Around : 대상 메서드의 실행 전후에 Aspect가 적용될 수 있게 도와준다.

  • @Around 어드바이스는 대상 메서드의 실행을 감싸서 전/후 처리를 수행할 수 있습니다.

• ✨ Advice : 프록시가 호출하는 조언(부가 기능) 단순하게 프록시 로직이라 생각하면 된다.
  - Advice는 관점(Aspect)의 실제 구현체로 결합점에 삽입되어 동작할 수 있는 코드

  • Advice 는 결합점(JoinPoint)과 결합하여 동작하는 시점에 따라 before advice, after advice, around advice 타입으로 구분
  • 특정 JoinPoint에 실행하는 코드

• Advisor : 단순하게 하나의 포인트컷과 하나의 어드바이스를 가지고 있는 것이다. 쉽게 이야기해서 Pointcut + Advice이다.

• Weaving :
  - Pointcut으로 지정한 핵심 관심 메소드가 호출될 때, 어드바이스에 해당하는 횡단 관심 메소드가 삽입되는 과정.
  - Weaving을 통해서 비즈니스 메소드를 수정하지 않고도 횡단 관심에 해당하는 기능을 추가하거나 변경할 수 있다.

즉, AOP는

JoinPoint를 실행 → Pointcut으로 지정한 메소드가 호출되는 순간 Advice 메소드가 실행
Advice 메소드 삽입→ Aspect 설정에 따라 Weaving 처리.

주요 어노테이션

@Timer

✨@Aspect : 자바에서 널리 사용하는 AOP 프레임워크에 포함되며, AOP를 정의하는 class에 해당

✨@Pointcut : 기능을 어디에 적용시킬지, 메소드? Annotation? 등 AOP를 적용시킬 지점을 결정

✨ @Around : Before / after 모두 제어

@Before : 메소드 실행하기 이전
@After : 메소드가 성공적으로 실행 후, 예외가 발생되더라도 실행
@AfterReturing : 메소드 호출 성공 실행 시 (Not Throws)
@AfterThrowing : 메소드 호출 실패 예외 발생 (Throws)

AOP 동작 과정

1) Before Advice : 포인트컷으로 지정된 메소드를 호출 시 메소드가 실행되기 전에 처리할 내용을 기술하기 위해 사용

2) After Returning Advice : 포인트컷으로 지정된 메소드가 정상적으로 실행되고 나서, 메소드 수행 결과로 생성된 데이터를 리턴하는 시점에 동작. 비지니스 메소드의 결과로 얻은 결과 데이터를 이용하여 사후 로직을 추가할 때 사용된다.

3) After Throwing Advice : 포인트컷으로 지정한 메소드가 실행되다가 예외가 발생하는 시점에 동작. 예외 처리 어드바이스를 설정할 때 사용한다.

4) After Advice : 예외 발생 여부에 상관없이 무조건 수행되는 어드바이스를 등록할 때 사용.

5) Around Advice : 다른 Advice는 실행 전/후의 수행되는 처리를 위해서 설정했다면 Around Advice는 클라이언트의 메소드 호출을 가로챈 뒤 실행 전/후의 처리를 동시에 처리할 수 있다.

AOP 활용 예시

• https://velog.io/@mooh2jj/스프링-트랜잭션-AOP-이해

• https://velog.io/@mooh2jj/Spring-Boot-AOP로-메서드-실행-시간-로깅하기

---

참고

• 김영한 AOP 고급 강의
• 패스트캠퍼스 스프링 강의
• https://soft91.tistory.com/69 [너와 나의 프로그래밍]
• https://expert0226.tistory.com/200 [여름나라겨울이야기]