[Spring] 의존관계 주입 방법

📋 목차

---

01. [Spring] 스프링 핵심 원리
02. [Spring] 좋은 객체 지향 설계의 5가지 원칙 (SOLID)
03. [Spring] 객체 지향 설계와 스프링   
04. [Spring] OCP와 DIP 고려하기
05. [Spring] 객체 지향 원리 적용 - 새로운 할인 정책 개발
06. [Spring] AppConfig 리팩터링    
07. [Spring] Ioc, DI Container  
08. [Spring] 스프링 컨테이너 생성  
09. [Spring] 싱글톤 컨테이너  
10. [Spring] Component Scan And Auto wired Start
11. [Spring] 의존관계 주입 방법    
12. [Spring] Bean Life Cycle Call Back
13. [Spring] Bean Scope

 

 

📌 다양한 의존관계 주입 방법

---

의존관계 주입은 크게 4가지 방법이 있는 것이에요.

첫째. 생성자 주입

둘째. Setter 주입

셋째. Field 주입

넷째. 일반 Method 주입

 

    📍 생성자 주입

이름 그대로 생성자를 사용하여 의존 관계를 주입하는 것이에요.

특징이라고 한다면 생성자 호출시점에 딱 한번만 호출되며, 불변 혹은 필수 의존관계에서 주로 사용한답니다.

 

 

위와 같이 생성자가 한 개만 존재한다면 @Autowired는 생략 가능하답니다! 참고로 이건 Spring Bean에만 해당하는 것이에요.

 

    📍 Setter 주입

수정자 주입이라고도 할 수 있는데, 수정자라는 단어는 들어본 적이 없는것이에요.

Setter주입의 특징은 선택 혹은 변경 가능성이 있는 의존 관계에서 사용하는 것이고, Java Bean Property 규약의 Setter Method 방식을 사용하는 것이에요.

 

 

💡 참고 :
1. @Autowired의 기본 동작은 주입할 대상이 없으면 Exception을 터트린다.
    주입할 대상이 없어도 동작하게 하기 위해서는 @Autowired(required = false)로 지정해주어야 한다.

2. Java Property, Java에서는 옛날부터 Filed의 값을 직접 변경하지 않고, Setter와 Getter를 사용하여 값을
   읽거나, 수정하는 규칙을 만들었는데, 이것을 Java Bean Property 규약이라고 한다.

 

 

 

 

 

    📍 Field 주입

필드를 통해서 주입하는 방식을 필드 주입이라고 하는 것이에요.

이 방식의 특징은 Code가 간결하기 때문에 많은 개발자들이 사용하고자 하지만, 외부에서 변경이 불가능하기 때문에 Test 하기가 매우 힘들다는 단점이 있는 것이에요.

또한, DI Framwork가 없다면 아무것도 할 수 없기 때문에 되도록 사용하지 않는 것이 좋은 방법인 것이에요.

Application의 실제 Code과 관계 없는 Test Code

Spring Configuration을 목적으로 하는 @Configuration 같은 곳에서만 특별한 용도로 사용되는 방식이랍니다.

 

 

 

💡 참고 :

1. 순수 Java Test Code에는 당연히 @Autowired가 동작하지 않는다. @SpringBootTest처럼
    Spring Container를 Test에 통합한 경우에만 사용 가능

2. 아래 코드와 같이 @Bean 에서 매개변수에 의존관계는 자동으로 주입. 수동 등록 시 자동 등록된 Bean의
    의존 관계가 필요할 때 문제 해결 가능 

 

 

 

 

    📍 사용자 정의(일반) Method 주입

이것은 사용자가 만든 Method를 통해 의존 관계를 주입하는 방식인 것이에요.

특징이라고 한다면 한번에 여러 Field를 주입 받을 수 있는데, 일반적으로 잘 사용하지 않는다고 해요.

 

 

 

💡 참고 :

의존 관계 자동 주입은 Spring Container가 관리하는 Spring Bean이어야 동작
Spring Bean이 아닌 Class에서 @Autowired Code를 적용해도 아무 기능도 동작하지 않음

 

 

 

 

📌 Option 처리

---

의존 관계를 주입할 Bean이 없다고 해도 동작 시키고 싶을 때가 있는 것이에요.

그런데, @Autowired만 사용하게 되면 required Option의 Default Value가 true로 되어 있어서 자동 주입 대상이 없으면 Exception이 터지는 것이에요.

 

자동 주입 대상을 Option으로 처리하는 방법은 아래와 같답니다.

1. @Autowired(required=false) : 의존 관계 자동 주입할 대상이 없을 경우 Setter 자체가 호출되지 않는다.
2. org.springframwork.lang.@Nullable : 자동 주입 대상이 없다면 null이 입력된다.
3. Optional<> : 자동 주입 대상이 없으면 Optional.empty가 입력된다.

 

 

 

위에서 사용한 Member Instance는 Spring Bean이 아닌 것이에요.

따라서 setNoBean1()은 @Autowired(requred=false)로 설정되어 있어 Method 자체가 아예 호출되지 않는 것이에요.

 

 

📖 Test 결과

 

 

 

 

💡 참고 :

@Nullable, Optional은 Spring 전반에 걸쳐 지원.
이것은 생성자 자동 주입에서 특정 Field에만 사용도 가능

 

👨‍🏫 김영한 강사님의 조언

생성자 주입을 선택하라!

과거 Setter 주입과 Field 주입을 많이 사용했다만, 최근에는 Spring을 포함한 DI Framwork 대부분이 생성자 주입을 권장한다. 가장 큰 이유는 불변이며, 세부 이유는 아래와 같다.

첫째 : 대부분 의존관계 주입은 한번 실행되면 Application 종료 시점까지 의존 관계를 변경할 일이 없으며,                 오히려 대부분 의존관계는 Application이 종료 될때까지 변하지 않는 것이 99%정도 된다.
         즉, 불변해야 한다.

둘째 : Setter 주입 사용 시 setXxx Method를 public으로 열어두어야 하며, 이는 다른 개발자들과 협업할 때나,
         다른 Client가 원치 않는 값으로 변경을 할 수 있기 때문에 위험하다.

셋째 : 누군가 실수로 변경할 수도 있고, 변경하면 안되는 Method를 열어두는 것은 좋은 설계가 아니다.

넷째 : 생성자 주입은 인스턴스를 생성할 때, 딱 한번만 호출되므로, 이 후 호출되는 일이 없기에 불변하게
        설계할 수 있다. 

 

 

    📍 누락

Framwork 없이 순수 Java Code를 단위 Test 하는 경우 아래와 같이 Setter 의존 관계인 경우라면 어떨까요?

 

 

@Autowired가 framwork 안에서 동작할 땐 의존관계가 없으면 오류가 발생하나, 아래 Code는 Framwork 없이 순수 Java Code로만 단위 Test를 하고 있는 것이에요.

 

 

 

위의 Test 결과는 어떻게 나왔을까요? 바로 NPE(Null Point Exception)이 터지는 것이에요. 그 이유는 memberRepository, discountPolicy 모두 의존관계 주입이 누락 되었기 때문이랍니다.

 

생성자 주입을 사용하게 되면 의존 관계 주입 Data가 누락되었을 때, Compile Error가 발생하는 것이에요.

그리고, IDE에서 바로 어떤 값을 필수로 주입해야 하는지 알려준답니다!

 

 

    📍 Final Keyword

생성자 주입을 사용하게 되면 Field에 final Keyword를 사용할 수 있는 것이에요. 그래서 생성자에서 혹시라도 값이 설정되지 않는 Error를 Compile 시점에서 막아주는 것이에요.

 

 

생성자 Body를 자세히 보면 필수 Field인 discountPolicy에 값을 설정해주어야 하는데, 이 부분이 누락된 것이에요.

 

 

Compile Error는 사랑이고, 선배 개발자들에 배려인 것이에요.

 

💡 참고 :

Setter 주입을 포함 나머지 주입 방식은 모두 생성자 이후에 호출된다.
때문에 Field에 final Keyword를 사용할 수 없다.
오직 생성자 주입 방식에서만 final Keyword를 사용할 수 있다.

 

 

정리하자면

생성자 주입 방식을 사용하는 여러가지 이유가 있지만, Framwork를 의존하지 않고, 순수 Java의 특징을 잘 살리는 방법인 것이에요.

기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우 Setter 주입 방식을 차선책으로 부여하는 방법도 있는 것이에요. 즉, 둘 다 사용할 수 있다는 것이지요.

항상 생성자 주입은 사용해야 하는 것이에요. 그리고, 가끔 차선책이 필요하다면 Setter 주입을 사용하는 것이 좋답니다.

Field 주입은 그냥 이런게 있구나 정도만 알면 되는 것이에요.

 

반응형

 

📌 Lombok과 최신 Trand

---

강사님께서는 개발을 하다보면 대부분 다 불변 사항이고, 그래서 Field에 final Keyword를 붙이게 된다고 하셨어요.

그런데, 생성자도 만들어야 하고, 주입 받은 값을 대입하는 Code도 만들어야 하고, 넘나 할게 많은 것이에요.

Field 주입을 좀 더 편하게 할 수 있는 방법은 무엇이 있을까요?

 

그럴 때 등장하는 것이 바로 Lombok인 것이에요.

Lombok Library가 제공하는 @RequiredArgsConstructor 기능을 사용하면 final이 붙은 Field를 모아 생성자를 자동으로 만들어 주는 것이에요.

 

 

Lombok이 Java의 Annotion Processor라는 기능을 이용하여 Compile 시점에 생성자 Code를 자동으로 생성해 주는 것이에요. 실제 Class를 열어보면 생성자가 추가되어 있답니다.

 

 

정리하자면

 

최근 생성자를 딱 한개를 두고, @Autowired를 생략하는 방법을 주로 사용한답니다.

여기에 Lombok Library의 @RequiredArgsConstructor를 함께 쓴다면 위의 기능은 다 쓸 수 있고, Code 또한 깔끔하게 정리되는 효과를 누릴 수 있는 것이에요.

 

 

    📍 Lombok 적용 방법

         👉 build.gradle

 

 

1. [Macbook]
   preferences => plugin => lombok 검색 및 설치 (IDE 재시작 필요)
2. [Windows]
   File => Settings => plugin => lombok 검색 및 설치 (IDE 재시작 필요)
3. 임의 Test를 만든 뒤 @Getter, @Setter가 동작하면 정상

 

 

 

 

 

📌 조회 빈 2개 이상 - 문제

---

@Autowired는 자료형 Type으로 조회를 하는 것이에요.

 

 

자료형 Type으로 조회를 하기 때문에 아래 Code와 유사하게 동작하는 것이에요. (단, 실제 더 많은 기능 제공)

 

AnnotationConfigApplicationContext.getBean(AppConfig.class);

 

자료형 Type으로 조회를 하게 되면 선택된 Bean이 2개 이상일 때 Exception이 터지는 것이에요.

 

 

위와 같이 있는 상태에서 의존 관계를 자동 주입으로 하게 되면 어떻게 될까요?

 

 

바로바로 NoUniqueBeanDefinitionException이 터지는 것이에요.

 

NoUniqueBeanDefinitionException: No qualifying bean of type 
'hello.core.discount.DiscountPolicy' available: expected single matching bean 
but found 2: fixDiscountPolicy,rateDiscountPolicy

 

위의 내용을 해석 해보면 하나의 Bean이 있을 줄 알았는데, fixDiscountPolicy와 rateDiscountPolicy 2개를 발견해 버렸다고 하네요.

 

이 때, 하위 자료형 Type으로 지정할수도 있으나, 하위 자료형 Type으로 지정하는 것은 DIP 위반 사항이고, 유연성이 떨어지는 것이에요. 이름만 드르고, 완전히 똑같은 Type의 Spring Bean 2개가 있을 때는 또 해결도 안 되는 것이에요.

Spring Bean을 수동 등록해서 문제를 해결할 수도 있겠지만, 의존 관계 자동 주입에서 해결하는 여러 방법이 존재하는 것이에요.

 

 

 

📌 @Autowired Field Name, @Qualifier, @Primary

---

조회 대상 Bean이 2개 이상일 땐 그럼 어떻게 자동 주입에서 해결할 수 있을까요?

첫째 : @Aurowired Field Name Matching

둘째 : @Qualifier => @Qualifier끼리 Matching => Bean Name Matching

셋째 : @Primary 사용

 

 

    📍 @Autowired Field Name Matching

@Autowired는 자료형 Type Matching을 먼저 한 뒤에 여러 Bean이 있으면 Field Name, 매개 변수 이름으로 Bean Name을 추가 Matching 하는 것이에요.

 

 

이렇게 하면 Field Name이 rateDiscountPolicy이기 때문에 정상 주입 되는 것이에요.

필드 이름 매칭은 먼저 자료형 타입 매칭을 시도한 뒤 그 결과에 따라 여러 빈이 있을 때 추가로 동작하는 것이에요. 

 

 

정리하자면

@Autowired는 자료형 타입 매칭을 하며, 매칭 결과가 2개 이상일 때 필드 이름, 매개 변수(파라미터) 이름으로 빈 이름을 매칭하는 것이에요.

 

 

    📍 @Qualifier

@Qualifier는 추가 구분자를 붙여주는 거라고 생각하면 되는 것이에요.

즉, 의존 관계 주입을 할 때 추가적인 방법을 제공하는 것이에요. 이 친구는 빈 이름을 변경하는 것이 아니랍니다.

 

 

위의 코드와 같이 빈 등록을 할 때 @Qualifier를 붙여주면 되는 것이고, 주입시에 등록한 이름을 적어주면 되는 것이에요.

 

 

         👉 생성자 자동 주입 예시

 

 

 

         👉 Setter 자동 주입 예시

 

 

 

만약 @Qualifier로 주입 할 때 @Qualifier("mainDiscountPolicy")를 못 찾게 된다면 어떻게 될까요?

그렇게 되면 mainDiscountPolicy라는 이름의 스프링 빈을 추가로 찾는 것이에요.

 

👨‍🏫 김영한 강사님의 조언

@Qualifier는 @Qualifier를 찾는 용도로만 사용합시다!

 

아래 코드와 같이 수동 빈 등록시에도 @Qualifier를 사용할 수 있는 것이에요.

 

 

 

정리하자면

 

첫째 : @Qualifier끼리 매칭

둘째 : 빈 이름 매칭

셋째 : NoSuchBeanDefinitionException 발생

 

 

 

    📍 @Primary 사용

@Primary는 우선순위를 정하는 것이라고 보면 되는 것이에요.

@Autowired 시 여러 빈이 매칭되면 @Primary가 붙어있는 곳이 최우선권을 갖는 것이에요.

 

 

위와 같이 했다면 FixDiscountPolicy보다 RateDiscountPolicy가 우선권을 갖게 되는 것이에요.

 

그렇다면 @Primary와 @Qualifier 중 어떤 것을 사용하면 좋을까요?@Qulifier의 단점은 의존 관계 주입 시 다음과 같이 모든 Code에 @Qualifier를 붙여줘야 한다는 것이에요.

 

 

하.지.만 @Primary는 이럴 필요가 없다는 장점이 있지요!

 

 

         👉 @Primary, @Qualifier 활용

코드에서 자주 사용하는 Main DB의 Connection을 획득하는 스프링 빈이 있고, 코드에서 특별한 기능으로 가끔 하용하는 Sub DB의 Connection을 획득하는 빈이 있다고 가정할 때, Main DB의 Connection을 획득하는 스프링 빈츤 @Primary를 적용해서 조회하는 곳에서 @Qulifier 지정 없이 편리하게 조회하고, Sub DB Connection Bean 획득 시에는 @Qualifier를 지정하여 명시적으로 획득 하는 방식으로 사용한다면 코드를 깔끔하게 유지할 수 있는 것이에요.

물론 이 때 Main DB의 스프링 빈을 등록할 때, @Qualifier를 지정해주는 것도 가능하답니다!

 

그렇다면 둘 중 누가 우선권을 가질까요?

@Primary는 Default Value처럼 동작하는 것이고, @Qulifier는 매우 상세하게 동작하는 것이에요. 

스프링은 자동보다 수동이 넓은 범위의 선택권 보다는 좁은 범위의 선택권이 우선 순위가 높은 것이에요. 따라서 여기서는 @Qualifier가 우선권이 높답니다!

 

 

 

📌 조회한 빈이 모두 필요할 땐? List와 Map!

---

의도적으로 해당 자료형 타입의 스프링 빈이 모두 다 필요한 경우도 있는 것이에요.

예를 들어 할인 서비스를 제공한다고 가정할 때, 클라이언트가 할인의 종류 (고정형, 확률형)을 선택할 수 있다고 가정한다면 스프링을 사용하여 전략 패턴을 구현할 수 있는 것이에요.

 

16 ~ 30번째 Line	32 ~ 49번째 Line

 

위의 코드를 살펴보면 DiscountService는 Map으로 모든 DiscountOPolicy를 주입 받는 것이에요.

이 때, fixDiscountPolicy, rateDiscountPolicy가 주입 되는 것이에요.

discount()는 discountCode로 "fixDiscountPolicy"가 넘어오면 map에서 fixDiscountPolicy 스프링 빈을 찾아 실행하는 것이에요. 물론! "rateDiscountPolicy"가 넘오면 rateDiscountPolicy를 찾아 실행하겠지요.

 

Map<String, DiscountPolicy>는 map Key에 스프링 빈의 이름을 넣어주고, 그 값으로 DiscountPolicy 객체 자료형 타입으로 조회한 모든 스프링 빈을 담아주는 것이에요.

List<DiscountPolicy>는 DiscountPolicy 객체 자료형 타입으로 조회한 모든 스프링 빈을 담아주는 것이에요.

만약 해당하는 자료형 타입의 스프링 빈이 없으면, 빈 컬렉션이나 Map을 주입한답니다.

 

💡참고 : 스프링 컨테이너를 생성하면서 스프링 빈 등록

스프링 컨테이너는 생성자에 클래스 정보를 받는다. 여기에 클래스 정보를 넘기면 해당 클래스가 스프링 빈으로 자동 등록된다.

new AnnotationConfigApplicationContext(AutoAppConfig.class,DiscountService.class);

위 코드는 2가지로 나누어 볼 수 있다.

첫째 : new AnnotionConfigApplicationContext()를 통해 스프링 컨테이너 생성
둘째 : AutoAppConfig.class, DiscountService.class를 매개변수로 넘기면서 해당 클래스를 자동으로 스프링
        빈으로 등록

결국 스프링 컨테이너를 생성하면서, 해당 컨테이너에 동시에 AutoAppConfig, DiscountService를 스프링 빈으로 자동 등록

 

 

 

 

📌 자동, 수동의 올바른 실무 운영 기준

---

    📍 편리한 자동 기능이 Default!

어떤 경우에 컴포넌트 스캔과 자동 주입을 사용하고, 어떤 경우에 설정 정보를 만들어서 수동으로 빈을 등록하고, 의존관계도 수동으로 주입할까요?

결과적으로 스프링이 나오고, 시간이 지날수록 자동을 선호하는 추세라고 합니다.

스프링은 @Component 뿐 아니라, @Controller, @Service, @Repository처럼 Layer(계층)에 맞추어 일반적인 Application Logic을 자동으로 Scan할 수 있도록 지원하는 것이에요.

거기에 최근 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고, 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록 되도록 설계 한 것이에요.

설정 정보를 기반으로 Application을 구성하는 부분과 실제 동작하는 부분을 명확하게 나누는 것이 이상적이나, 개발자 입장에서 스프링 빈을 하나 등록할 때, @Component만 넣어주면 끝나는 일을 @Configuration이 붙어 있는 설정 정보에 가서 @Bean을 Method마다 하나하나 붙이고, 인스턴스(객체)를 생성하고, 주입 대상을 일일이 적어주는 과정은 현타가 오게 만드는 것이에요.

또 관리할 스프링 빈이 많아서 설정 정보가 커지게 된다면 설정 정보를 관리하는 것 자체도 굉장한 부하가 걸리게 될 것이랍니다.

그리고, 결정적으로 자동 빈 등록을 사용해도 OCP, DIP를 위반하지 않을 수 있는 것이에요.

 

         👉 수동 빈 등록을 사용하면 좋을 때

Application은 크게 업무 로직과 기술 지원 로직으로 나눌 수 있는 것이에요.

• 업무 로직 빈 : Web을 지원하는 Controller, 핵심 비즈니스 로직이 있는 Service, Data Layer의 로직을 처리하는 Repository 등이 모두 업무 로직으로 보통 비즈니스 요구사항을 개발할 때 추가되거나, 변경되는 곳이다.
  • 업무 로직은 숫자도 매우 많고, 한번 개발해야 하면 Controller, Service, Repository처럼 어느정도 유사 패턴이 존재. 이런 경우 자동 기능이 유리하며, 보통 문제가 발생해도 어떤 곳에서 문제가 발생했는지 명확하게 파악하기 쉬운 부분이다.
• 기술 지원 빈 : 기술적인 문제, 공통 관심사(AOP - 이것을 잘 모르신다면 [Spring Boot] AOP에 관심을 주세요!)를 처리할 때 주로 사용. DB 연결, 공통 Log 처리와 같은 업무 로직을 지원하기 위한 하부 기술 혹은 공통 기술들
  • 기술 지원 로직은 업무 로직과 비교해서 그 수가 매우 적고, 보통 Application 전반에 걸쳐 광범위하게 영향을 미치는 곳. 또한, 업무 로직은 문제가 발생했을 때, 어디가 문제인지 명확하게 알 수 있으나, 기술 지원 로직은 적용이 잘 되고 있는지 아닌지 파악하기 어려운 경우가 많다. 때문에 이런 기술 지원 로직들은 수동 빈 등록이 유리할 수 있으며, 명확하게 알 수 있게 하는 것이 좋다.
    • 같은 주제를 갖은 Class들을 한 Package에 정리하기
    • 최상위 위치 (Root Path)에 설정 정보들을 위치 시키기.

 

Application에 광범위하게 영향을 미치는 기술 지원 인스턴스는 수동 빈으로 등록해서 설정 정보에 바로 나타나게 하는 것이 유지보수에 유리한 것이에요.

 

 

         👉 비즈니스 로직 중 다형성을 적극 활용할 때

의존 관계 자동 주입에서 위에 기술한 [📌 조회한 빈이 모두 필요할 땐? List와 Map!] 이 부분에 다시 관심을 주세요!

DiscountService가 의존 관계 자동 주입으로 Map<String, DiscountPolicy>에 주입을 받는 상황이라면 여기에 어떤 빈들이 주입될지 각 빈들의 이름은 무엇일지 코드만 보고 한번에 알 수 없는 것이에요. 물론 개인이 개발했다면 알 수 있겠지만, 남이 개발한 코드를 받는다면 어떨까요?

이럴 경우 자동 등록을 사용하고 있다면 파악을 위해 여러 코드를 옮겨 다니며, 파악을 해야 하는 것이에요.

위와 같은 상황일 때, 수동 빈으로 등록하거나, 자동으로 한다면 특정 패키지에 같이 묶어 두는 것이 좋은 것이에요.

핵심은 딱 보고, 이해가 되어야 하닌까요!

 

이 부분을 별도 설정 정보를 만들고, 수동으로 등록한다고 하면 아래와 같은 것이에요.

 

 

위 설정 정보만 봐도 한 눈에 빈의 이름은 물론(rateDiscountPolicy, fixDiscountPolicy) 어떤 빈들이 주입될지 파악할 수 있는 것이에요. (Method의 Body부) 그래도 빈 자동 등록을 사용하고 싶다면 파악하기 좋게 DiscountPolicy의 구현 빈들만 따로 모아 특정 Package에 저장하는 것도 방법일 수 있는 것이에요.

 

💡 참고 :

스프링과 스프링 부트가 자동으로 등록하는 수 많은 빈들은 예외.
이런 부분들은 스프링 자체를 잘 이해하고, 스프링의 의도대로 잘 사용하는 게 중요.
스프링 부트의 경우 DataSource 같은 DB Connection에 사용하는 기술 지원 로직까지 내부에서 자동으로 등록.
이런 부분은 Manual을 참고해서 스프링 부트가 의도한대로 편리하게 사용하는 게 좋다.

반면 스프링 부트가 아니라 내가 직접 기술 지원 객체를 스프링 빈으로 등록할 땐 수동으로 등록하는 게 유리

 

 

정리하자면

 

편리한 자동 기능을 사용하는 것이 일단 기본!

직접 등록하는 기술 지원 객체는 수동으로 등록하는 것이 좋다.

다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자!

 

(다형성이 무엇인지 알고 싶으신다면 [Java] 다형성(polymorphism)에 관심을 주세요!)

 

 

---

 

 

주니하랑의 글이 마음에 드셨나요? 구독과 공감! 그리고, 댓글 그리고 방명록은 주니하랑에게 많은 힘이 됩니다.