spring PART.스프링 컨테이너 계층, 싱글톤 컨테이너

서론

※ 이 포스트는 다음 강의의 학습이 목표임을 밝힙니다.

https://www.inflearn.com/roadmaps/373

 

본론

- 빈 팩토리와 어플 컨텍스트

 

최상위에 빈 팩토리가 있고 그 밑에 빈 팩토리를 상속받는 어플 컨텍스트가 있습니다. 어플 컨텍 밑에 어노테이션 컨텍스트 구현 클래스가 있습니다.

> 빈 팩토리가 스프링 컨테이너의 최상위 인터페이스이고 스프링 빈을 관리하고 조회하는 역할을 담당합니다.

 

 

- 어플리케이션 컨텍스트란?

빈 팩토리의 기능을 상속받습니다. 둘의 차이는 빈 팩토리가 주는 빈 관리하고 조회하는 것에 공통적으로 가지는 부가 기능이 있습니다. 사실 어플 컨텍스트가 빈 팩토리 뿐만아니라 다른 인터페이스의 다중 상속을 받고 있습니다. 따라서 어플 컨텍만 사용합니다.

 

- xml로 해보기

스프링 컨테이너는 다양한 형식의 설정 정보를 받아드릴 수 있게 유연하게 설계되어있습니다. 우리가 이전에 appconfig.class로 어노테이션 컨테스트에 설정 정보를 지정했는데 appconfig.xml로 지정하는 방법이 있습니다.

 

- 스프링 빈 설정 메타 정보 beanDefinition

스프링 빈이 이렇게 xml, class 등 다양한 설정 형식을 지원하는 것은 beandefinition이라는 추상화 덕분입니다. bean 정보에 대한 것을 추상화 시킨 것입니다. 이것도 역할과 구현을 분리한 것입니다. 스프링 컨테이너는 자바 코드인지, xml인지 몰라도 됩니다. 오직 beandifinition만 알면 됩니다.

 

빈 디피니션을 빈 설정 메타 정보라고 합니다. @Bean을 하면 빈 하나당 각각 메타 정보가 생깁니다.(ApplicationContextInfoTest 테스트할 때 getBeanDefinitionNames가 있는데 이것도 메타 정보를 가져오는 것이었습니다.) 스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈을 생성합니다.

스프링 컨테이너는 빈 데피니션에만 의존하지 자바코드인지 xml인지 모릅니다. 빈 데피니션 자체가 인터페이스입니다.

 

어플리케이션 컨텍스트 구현체 중에 어노테이션 컨텍스트가 있었고 들어가보면 어노테이션 빈 데피니션 리더가 있습니다. 얘가 appconfig.class 설정정보를 읽어서 빈 메타 정보를 만드는 애입니다. 리더를 이용해서 자바코드의 설정정보를 읽습니다. 그렇게 빈 데피니션을 만듭니다. 

 

이전에 getBeanDefinitionNames와 for문으로 메타정보를 출력해봤습니다. 이 메타정보가 있고 이를 기반으로 실제 객체를 스프링 빈에 등록하는 것입니다. 스프링이 다양한 형태의 설정 정보를 beanDefinition으로 추상화해서 사용하는 것 정도만 이해하면 됩니다. 또한 스프링을 등록하는 방법은 2가지로 하나는 직접 개발자가 작성하는 것과 factoryBean을 사용하는 것으로 AppConfig을 쓰는 것은 factoryBean을 쓰는 방식입니다.

 

- 웹 어플리케이션과 싱글톤

싱글톤 패턴을 들어봤을 것입니다. 객체가 JVM에 딱 하나만 있어야하는 패턴을 말합니다.

 

스프링은 기업용 온라인 서비스 기술을 지원하기 위해 탄생했습니다. 대부분의 스프링 어플은 웹 어플리케이션입니다. 웹 어플은 보통 여러 고객이 동시에 요청을 합니다.

 

그림을 보면 클라 ABC 세명이 동시에 멤버 서비스를 요청을 하면 우리가 만든 AppConfig(@Configuration 안한 new AppConfig한 것)는 메모리 멤버 레포를 생성을 해서 멤버 서비스를 반환할 것이고 이걸 3명한테 반환해 줄 것입니다. 그러면 고객이 3번 요청하면 멤버 서비스 객체가 3개가 생깁니다. 이게 어떤 문제냐면 웹 어플은 고객이 계속 요청을 하는 어플인데 뭔가 요청이 올 때마다 객체를 만들어야하는게 지금 문제입니다.

 

-> 테스트

진짜 고객이 요청할 때마다 객체가 생기나 테스트를 해보자 test에 패키지를 만들고 싱글톤을 시험해보자 스프링 없는 순수 Di 컨테이너를 보고 문제점이 뭔지 보자 그리고 스프링과 비교를 해보겠습니다.

 

public class SIngletonTest {
    @Test
    @DisplayName("스프링 없는 순수한 DI 컨테이너")
    void pureContainer() {
        AppConfig appConfig = new AppConfig();

        //조회 1 : 호출할 떄 마다 객체를 생성
        MemberService memberService1 = appConfig.memberService();

        //조회 2 : 호출할 떄 마다 객체를 생성
        MemberService memberService2 = appConfig.memberService();

        System.out.println("memberService1 = " + memberService1);
        System.out.println("memberService2 = " + memberService2);

        Assertions.assertThat(memberService1).isNotSameAs(memberService2);
    }
}

호출할 때마다 객체를 생성하나 조회를 해보자 레퍼런스 값이 다른 것을 확인해보면 다른 객체인 것을 알 수 있습니다. 이렇게 되면 JVm에 객체가 계속 올라갑니다. 웹 어플은 고객의 요청이 하루에 초당 5만개의 객체가 생겨서 매우 안 좋습니다. 

 

★ 스프링 없는 순수한 자바 DI 컨테이너는 요청이 올 때마다 객체를 새로 생성합니다. 메모리 낭비가 심합니다. 이를 해결하는 좋은 방안이 있고 해당 객체를 딱 하나만 생성하고 공유하게 설계를 하면 됩니다! 

 

- 싱글톤 패턴

앞서 있던 문제를 해결해보자 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴입니다. 한 JVM에서는 객체가 딱 하나만 있어야합니다. 방법이 여러개 있습니다. 결론은 똑같은 객체 인스턴스를 2개 이상 생성하지 못하게 막아야합니다. 코드로 보겠습니다.

 

=> 싱글톤 패턴 구현

public class SingletonService {
    private static final SingletonService instance = new SingletonService();

    public static SingletonService getInstance() {
        return instance;
    }

    private SingletonService() {}

    public void logic() {
        System.out.println("싱글톤 객체 로직 호출");
    }
}

test에 싱글톤 서비스를 만듭니다.(강사님 왈 : 메인 메서드에 안 만들고 test에 합니다. = test는 메인에 짜듯이 짜야합니다.) 자기 자신의 객체를 내부에 private로 가지고 있는데 static으로 가지고 있습니다. 이렇게 하면 static으로 하여 딱 하나만 생기게 됩니다.

> 멤버 서비스 같은 서비스인데 싱글톤으로 객체 하나만 생성되게 코드를 짠 것입니다. 멤버 서비스도 이렇게 짜면 싱글톤을 따릅니다. 게터를 만들고 이렇게 하면 객체가 생성이 될 때 자기자신을 참조를 해서 instance에 넣어놓습니다. 

> 이제 중요한데 메인에서는 new로 하면 내가 객체 인스턴스를 private로 감추려고 했는데 안됩니다. 그래서 private 생성자를 씁니다. 로직을 하나 만들어두자 이러면 완벽한 싱글톤이 됩니다. 자바가 딱 뜨면서 객체를 내부에 딱 하나 가지고 있고 이 인스턴스를 참조할 수 있는 것은 return instance 밖에 없고 생성은 아무도 못합니다. (new로 못하니)

 

-> 설명

1. static 영역에 객체 instance를 미리 하나 생성해서 올려둡니다.
2. 객체 인스턴스가 필요하면 오직 get 메서드를 통해서만 조회할 수 있고 이메서드를 호출하면 static이니 항상 같은 인스턴스를 반환합니다.
3. 딱 1개의 객체 인스턴스만 존재해야 하므로, 생성자를 private로 막습니다. 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막습니다.(JVM 생길 때 만드어야지 그 외 new로는 못 만들게 만듭니다.)

 

-> 테스트

이걸 가지고 테스트 해보자 new로 하려고 하니 딱 private라고 막힙니다. 

 

 

@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용")
void singletonService() {
    SingletonService singletonService = SingletonService.getInstance();

    //조회 2 : 호출할 떄 마다 객체를 생성
    SingletonService singletonService2 = SingletonService.getInstance();

    System.out.println("singletonService = " + singletonService);
    System.out.println("singletonService2 = " + singletonService2);
    
    Assertions.assertThat(singletonService).isSameAs(singletonService2);
}

기존과 비슷하게 스프링 없이 한던것처럼 조회를 해보겠습니다. getInstance로 해야하고 이래야만 동일한 객체를 다루게 됩니다. 자바가 뜰 때 생성한 것을 가져다 쓰는 것이고 생성하는데 드는 비용이 한 1000이라면 참조를 가져오는 비용이 1입니다. 둘이 같냐고 테스트를 해보면 맞습니다.

 

이렇게 싱글톤 패턴을 구현했습니다. 이제 우리는 멤버 서비스 같은 애들이 하나만 생성되기를 원했으니 AppConfig에서 싱글톤 패턴을 다 적용하면 됩니다. 그런데 그렇게 할 필요가 없습니다. 왜냐! 스프링 컨테이너를 쓰면 스프링 컨테이너가 기본적으로 객체를 싱글톤으로 만들어서 관리를 해줍니다. 요청이 1000개가 와도 객체를 하나도 안만들고 처음에 등록된 있는 객체를 그대로 재활용해줍니다.

 

-> 싱글톤 패턴의 문제점

1. 코드를 치기 귀찮습니다. 구현하는 코드 자체가 많이 들어갑니다.
2. 클라이언트가 구체 클래스에 의존해야합니다. ex) AppConfig에 싱글톤을 적용하려면 멤버 서비스 구현 클래스에 싱글톤 패턴 코드를 작성하고 AppConfig에서 MemberServiceImpl.getInstance로 꺼내야합니다. 구체클래스 . 이라서 구체 클래스에 의존하여 DIP를 위반합니다.

> 그런데 스프링 프레임워크는 싱글톤의 단점을 전부 다 해결하고 객체를 싱글톤으로 관리해줍니다.

 

- 싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤으로 관리합니다. 지금까지 우리가 사용했던 스프링 빈이 싱글톤으로 관리되는 빈입니다.

 

> 처음에 AppConfig를 보고 빈 객체를 등록을 할 때 미리 빈 객체를 생성을 해서 관리를 해줍니다. 그러면 getBean으로 조회하면 미리 생성된 객체를 조회해줍니다. 계속 똑같은 애를 조회해줍니다. 스프링 컨테이너는 싱글톤 역할을 합니다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 합니다. 

 

-> 테스트

@Test
@DisplayName("스프링 컨테이너 싱글톤")
void springContainer() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    //조회 1 : 호출할 떄 마다 객체를 생성
    MemberService memberService1 = ac.getBean("memberService", MemberService.class);

    //조회 2 : 호출할 떄 마다 객체를 생성
    MemberService memberService2 = ac.getBean("memberService", MemberService.class);
}

정말로 객체를 싱글톤으로 작성하지 않았는데 공유하나 테스트해보자 순수 자바 DI 컨테이너 test를 스프링 컨테이너로 바꾸면 됩니다.(왜냐면, 스프링을 쓰기 전 방식이 순수 자바 DI 컨테이너로 appConf를 new로 생성하는 똑같이 DI를 하는 목적이었습니다. 그걸 스프링으로 바꾼게 @Configuration이었습니다.) 실행해보면 둘이 같은 객체가 나옵니다. 스프링이 처음에 자기가 등록한 객체를 반환해주는 것입니다.

 

 

결과를 보면 스프링 컨테이너 덕분에 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유하면서 효율적으로 재사용 할 수 있습니다. 이게 스프링 프레임워크를 쓰는 이유 중 하나입니다! 참고로 스프링은 싱글톤 말고 요청할 때마다 새로운 객체를 생성해서 반환하는 기능도 제공합니다. 빈 생명주기와 관련된 것으로 아주 그렇게 가끔(0.001%) 만들 수도 있습니다.

 

 

- 싱글톤 방식의 주의점

 

객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 주의할 게 있습니다. 객체를 하나만 생성해서 같은 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지하게 설계하면 안됩니다. 무상태로 설계를 해야합니다. 여기서 싱글톤 빈은 멤버 서비스 같이 빈에 등록되는 애들입니다.

 

1. 특정 클라이언트에 의존적인 필드가 있으면 안된다
2. 특정 클라가 값을 변경할 수 있는 필드가 있으면 안된다.
3. 가급적 읽기 전용만 되야한다 값을 수정하면 안된다.(멤버 서비스는 읽는 것만 있지 필드도 없고 바꿀 값도 없다)
4. 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, threadlocal등을 사용해서 써야한다.(파라미터= 매개변수로 줘서 지금 이 순간에만 사용하게 영역을 줘야하고, 전역이 아닌 지역으로 줘서 값이 유지되게 하면 안된다.)

스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다! 

 

-> 문제점 예시( ★ 실무에서 자주 발생하는 예시 )

public class StatefulService {
    private int price; // 상태를 유지하는 필드
    public void order(String name, int price){
        System.out.println("name = " + name + ", price = " + price);
        this.price = price; //여기가 문제!
    }
    public int getPrice() {
        return price;
    }
}

 

Stateful 서비스(유지되는 빈)를 만들고 price라는 상태를 유지하는 필드가 있습니다. 주문과 관련된 것으로 주문 가격을 저장하는 예제입니다. 

 

@Configuration
public class TestConfig {
    @Bean
    public StatefulService statefulService() {
        return new StatefulService();
    }
}

이게 서비스고 이걸 AppConfig에 빈 등록해서 사용할 것입니다.

 

class StatefulServiceTest {
    @Test
    void statefulServiceSingleTon() {
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(TestConfig.class);

        StatefulService statefulService1 = applicationContext.getBean(StatefulService.class);
        StatefulService statefulService2 = applicationContext.getBean(StatefulService.class);

        //Thread A : A사용자 10000원 주문
        statefulService1.order("userA", 10000);

        //Thread B : B사용자 20000원 주문
        statefulService2.order("userB", 20000);

        int price = statefulService1.getPrice();
        System.out.println("price = " + price);
    }
}

테스트 클래스를 만들고 TestConfig에 등록하고 test 코드에 컨테이너를 만듭니다. getBean으로 statefulService를 두개 꺼내고 쓰레드 A에서 10000원 주문하고 쓰레드 B에서 20000원을 주문했습니다. 여기서 쓰레드 A가 주문 금액을 조회하면 10000원이 나와야하는데 20000원 나올것입니다. A가 주문하고 조회하는 사이에 B가 끼어들어서 주문하고 A가 주문을 조회하는 상황입니다.

> 우리가 기대하길 1만원이 나오길 바랬는데 2만원이 나왔습니다. 이게 같은 StatefulService 객체를 쓰기 때문입니다. 배민에서 A가 1만원을 주문했는데 실제 카드에 긁힌게 2만원인 상황입니다.(이런 공유되는 필드가 있으면 안된다는 것입니다.) A가 값을 바꾸려고 하려는게 문제입니다. 2.에서 특정 클라가 값을 변경할 수 있는 필드가 있으면 안된다고 했습니다.(필드가 애초에 있으면 안됩니다.)

 

// StatefulService 무상태 코드
public class StatefulService {
//    private int price; // 상태를 유지하는 필드
    public int order(String name, int price){
        System.out.println("name = " + name + ", price = " + price);
        return price;
    }
//    public int getPrice() {
//        return price;
//    }
}

// 테스트 무상태 코드
class StatefulServiceTest {
    @Test
    void statefulServiceSingleTon() {
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(TestConfig.class);

        StatefulService statefulService1 = applicationContext.getBean(StatefulService.class);
        StatefulService statefulService2 = applicationContext.getBean(StatefulService.class);

        //Thread A : A사용자 10000원 주문
        int userAPrice = statefulService1.order("userA", 10000);

        //Thread B : B사용자 20000원 주문
        int userBPrice = statefulService2.order("userB", 20000);

//        int price = statefulService1.getPrice();
        System.out.println("price = " + userAPrice);
    }
}

★ 스프링 빈은 항상 무상태로 설계해야합니다. 무상태로 바꾸는 것을 보자 지역변수 파라미터를 쓰라고 했으니 지역변수로 바꿔서 사용자 A, B의 값이 다르게 만들어버립니다.

 

 

- @Configuration과 싱글톤

Appconf를 보면 이상한 게 있습니다. 만약 스프링 빈이 멤버 서비스를 호출하면 new로 멤버 서비스 impl을 생성하면서 멤버 레포를 호출합니다. 그러면 new 메모리 멤버 레포가 생성이 됩니다.

> 그 다음에 오더 서비스를 빈으로 생성하면 new로 멤버 레포를 또 호출합니다. 이렇게 되면 메모리 멤버가 new로 두번 호출됩니다.

 

근데 이러면 자바 코드상으로는 싱글톤이 깨지는 거 아닌가??  ✅

이를 스프링이 어떻게 해결하는지 test 코드로 실험을 해보겠습니다.

package hello.core.member;

public class MemberServiceImpl implements MemberService{
    MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }

    @Override
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }

    // 싱글톤인지 확인하기 위함
    public MemberRepository getMemberRepository(){
        return memberRepository;
    }
}

주문 서비스랑 멤버 서비스에 둘 다 멤버 레포를 선언하니 둘을 비교해 보면 되는 것이고 코드만 보면 둘이 다른 객체가 들어가야 합니다. 

 

-> test 클래스 작성

public class ConfigurationTeset {

    @Test
    public void configurationTest(){
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberServiceImpl memberService = applicationContext.getBean(MemberServiceImpl.class);
        OrderServiceImpl orderService = applicationContext.getBean(OrderServiceImpl.class);
        MemberRepository memberRepository = applicationContext.getBean(MemberRepository.class);

        MemberRepository memberRepository1 = memberService.getMemberRepository();
        MemberRepository memberRepository2 = orderService.getMemberRepository();

        System.out.println("memberRepository1 = " + memberRepository1);
        System.out.println("memberRepository2 = " + memberRepository2);
        System.out.println("memberRepository = " + memberRepository);
    }

}

스프링 빈에 등록할 때 두 번 호출되는 멤버 레퍼가 같은 건지 체크하는 용이니깐 스프링 컨테이너를 만들고 컨테이너에서 멤버 서비스와 오더 서비스를 꺼내서 둘의 멤버 레포를 꺼내서 비교해보겠습니다.

 

출력해보면 같은 겁니다! 거기다 진짜 멤버 레포도 꺼내서 출력해보면 같은 겁니다!

 

-> 어떻게 된 걸까요??

분명 스프링 빈이 멤버 서비스랑 주문 서비스 호출하면서 메모리 멤버 레포 new 두번을 할텐데 말입니다. 확인해보면 멤버 레포 객체는 모두 같은 인스턴스를 공유해서 사용합니다. 한마디로 같은애가 생겨서 사용됐을 것입니다. 근데 AppConf  코드만 봤을 때는 다른 객체가 생성이 되야합니다.

@Bean
    public MemberService memberService(){
        System.out.println("AppConfig.memberService");
        return new MemberServiceImpl(memberRepository());
    }
    @Bean
    public MemberRepository memberRepository()  {
        System.out.println("AppConfig.memberRepository");
        return new MemoryMemberRepository();
    }
    @Bean
    public OrderService orderService() {
        System.out.println("AppConfig.orderService");
        return new OrderServiceImpl(memberRepository(), rateDiscountPolicy());
    }

> 실험을 통해 확인해보자 각 appcon의 각 메서드에서 출력을 해보겠습니다. 결과가 어떻게 나와야할까요? 먼저 appconf.memberservice를 출력할 거고 new를 하면서 멤버 레포를 출력할거고 이처럼 메서드를 호출하는대로 출력이 되야할 것입니다. 최종적으로는 멤버 레포가 3번이 호출이 되어야 합니다.

 

근데 돌려보면 우리의 의도와는 완전히 다르게 bean이 등록되면서 각 한 번씩 호출되고 멤버 레포가 1번만 호출됐습니다.

 

- configuration과 바이트 코드 조작의 마법

이게 스프링이 싱글톤을 보장하는 원리입니다. 스프링 컨테이너는 싱글톤 레지스트리입니다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야합니다. 그런데 스프링이 작성된 자바 코드까지 어떻게 하기는 어렵습니다. 저 자바 코드만 봤을 떄는 분명 3번 호출돼야하는게 맞습니다. 이 비밀은 @config를 적용한 appconf에 있습니다.

 

-> conf test

@Test
public void configurationDeep() {
    ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
    AppConfig bean = applicationContext.getBean(AppConfig.class);

    System.out.println("bean = " + bean);
}

test 코드를 작성합니다. 어플리케이션 컨텍스트에서 getbean으로 appconfig를 조회해보겠습니다. (어노테이션 머플리케이션 컨텍스트에서 appconf를 .class로 넘기면 appconf도 스프링 빈에 등록이 됩니다.) 

 

> 꺼내서 출력을 해보면 getclass로 클래스 타입을 보면 원래는 class hello.core.AppConfig까지만 나오는게 정상인데 $$뒤에 이상한게 붙었습니다. cglib뭐 이렇게 붙어있습니다. 

 

-> 설명

순수한 클래스라면 class hello.core.AppConfig까지 나옵니다. 이것은 내가 만든 클래스가 아닙니다. 스프링이 빈을 등록하는 과정에서 조작을 해서 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppCong 클래스를 상속받은 임의의 다른 클래스를 만들고 그 다른 클래스를 스프링 빈으로 등록한 것입니다. 

스프링 컨테이너에는 이름은 appConfig인데 다른애가 등록되어 있는 것입니다. 내가 만든 객체가 아닌 임의의 다른 클래스가 바로 싱글톤이 보장되도록 해줍니다.

 

-> 임의의 클래스 코드를 보자

appconfig를 상속 받은 거니깐 같은 용도로 쓰일 것인데 클래스들을 생성해서 return하는 코드가 짜여져 있을 것이고 보면 멤버 레포지토리를 반환하는 메서드가 어버라이딩이 되어있고 만약 멤버 레포가 이미 스프링 컨테이너에 등록되어 있으면 스프링 컨테이너에서 찾아서 반환해라고 되어있고 그래서 한번만 호출이 되는 것입니다. 컨테이너에 없으면 new 메모리 멤버 레포를 부모인 AppConf처럼 실행해라고 되어 있는 것입니다.

> 결론을 말해보자면 걍 한번만 호출되도록 AppConf가 오버라이딩되어 짜여지도록 스프링에서 해주는 것입니다. 참고로 AppconfCGLIB은 Appconf의 자식이므로 Appconf 타입으로 getBean으로 조회할 수 있습니다.(부모타입으로 조회하면 자식타입 모두 조회)

 

 

-> @Configuration을 안붙이면?

스프링이 자동으로 붙여줍니다. @Configuration을 붙이면 CGLIB 기술을 사용해서 싱글톤을 보장을 해줍니다. 만약 안 붙이고 @Bean만 붙이면? 문제가 있습니다. 

> 뺴고 실행하면 CGLIB이 안나오고 AppConf가 호출되고 멤버 레포가 3번 new로 호출됩니다. 당연합니다. CGLIB에 if else로 오버라이딩된 것인데 Appconf가 호출되니 당연히 자바 코드 그대로 3번 new 됩니다. 멤버 레포는 전부 다 다른 애가 생깁니다. 싱글톤이 완벽하게 깨집니다. 또한 스프링 빈에 등록된 객체가 아니고 실제 new로 생성된 스프링 컨테이너가 관리하는 애가 아닙니다.

> 이처럼 Configuration을 안붙이면 스프링 컨테이너가 관리도 안해주고 싱글톤도 보장이 안됩니다. @Bean만 사용해도 스프링 빈으로 등록되지만 싱글톤은 보장이 되지 않습니다. 즉 처음에 스프링에 AppConfig.class를 지정해서 스프링 빈에 등록되는 것은 맞지만 memberRepository()처럼 의존 관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지 않습니다. 그냥 @Configuration 사용하는게 좋습니다.