[2024-2 Spring Boot 스터디] 조상혁 #6주차

이 글은 스프링 핵심 원리 - 기본편을 기반으로 작성되었습니다.

 

이번 주차는 다음주가 시험주간인 관계로 가장 중요하다고 생각했던 부분인

자동등록과 수동등록을 언제 사용할 것인가를 정리해 볼까한다.

 

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

 

제목에서 설명하는 자동과 수동은 빈 객체의 등록 즉 설정파일에 대해서 말하는 것이다.

 

이번 강의를 들으면서 깨달은 것 중에 이미 만들어 진 것을 쓰면 개발도 편하고 오류도 적어진다...!!

라는 교훈을 얻었는데 이 깨달음을 얻게 하는데 1등 공신이 자동등록이다.

 

실제로 자동등록은 어노테이션  @Component , @Controller , @Service , @Repository 이것들로 딸깍.. 하면

스프링 부트가 알아서 스캔하여 잘 만들어 주는데 ,

 

내가 수동으로 등록하면 객체들 다 하나하나 쓰고 OCP,DIP 위반하진 않았나 확인하고 만약 프로젝트의 크기가 

커진다면 그 많은 설정들을 모두 확인해야한다는게 이걸 했던 옛 개발자들을 저절로 존경하게 된다.

 

따라서 그냥 거의 대부분 자동등록을 사용한다고 생각하면 될 것 같다.

 

그럼 수동 빈 등록은 쓸모가 없는가?

 

수동 빈 등록은 기술 지원 빈인 기술적 문제나 AOP ( 공통관심사 ) 의 처리에서 유용하게 사용될 수 있다.

데이터베이스의 연결이나, 공통 로그 처리와 같은 업무를 위한 기반 기술 공통 기술들은 수동으로 등록하여 사용한다.

 

왜 수동을 쓰는가?

 

업무 로직은 기능이 매우 많고 유사한 패턴이 존재하는 반면에 , 기술 지원 로직은 업무 로직보다 수가 매우 적고 

공통관심사 이기에 매우 광범위하게 사용된다. 그렇기에 자동으로 등록해 놓을 경우 이 로직을 사용하기 위에 

찾는 작업이 필요하고 이는 작업에 불편함을 초래한다. 보다 빠른 개발을 위해서는 접근하는 창구가 따로 있다면

찾기도 편하고 쓰기도 편하다. 따라서 수동으로 설정파일을 만들어 기술 지원 빈을 등록해 놓아야 강사님이 말씀하신

" 한눈에 보기 좋은 파일 " 이 된다. 

 

장황하게 설명했지만 사실 많이 쓰는 로직 보기 편하게 하기 위해서 수동으로 설정파일을 관리한다! 로 줄일 수 있겠다.

 

또 수동 빈 등록이 필요할 때

 

기술 지원 로직 이외에도 빈 등록이 필요할 때가 있는데 바로 " 다형성 " 이 많이 필요할 경우이다.

 이번 주차 강의중에서는 ` DiscountService ` 가 의존관계 자동 주입으로 ` Map ` 에 주입을 받는 상황을 생각 해보자. 

라는 가정을 하고 이름과 코드만 보고 파악할 수 있는가?? 를 예시로 들어 주셨다.

 

아마 코드를 따라가며 확인할 수 있겠지만 이는 좀 귀찮은 작업이며 사실 하나하나 다 따라가는 것은 시간 낭비이다.

설상가상으로 나 혼자 개발이 아닌 다른 개발자가 그냥 이렇게 주었다면 도통 알 수 없을 지도 모른다..

 

그렇기에 이런 다형성이 많이 필요한 경우에는 자동등록시에 한 패키지에 묶어주는 것이 좋고

되도록이면 수동등록을 통해 한번에 의존관계와 주입을 확인할 수 있도록 만들어 주는 것이 모두가 행복해지는 길이다.

 

GPT 가 다시 설명해주는 다형성에서 수동등록이 필요한 이유

다형성에서 수동 등록이 유리한가?

1. 구현체 간 선택 및 관리 용이성
   다형성을 지원하는 코드에서 인터페이스를 구현한 여러 클래스 중 하나를 선택해야 할 때, 이를 프로그래밍적으로 명시하거나 동적으로 선택할 필요가 있을 수 있습니다.
   예를 들어, 특정 조건에 따라 다른 빈을 사용할 경우 수동 등록으로 명시적 제어가 가능합니다.

   @Bean
   public PaymentProcessor paymentProcessor() {
       if (usePayPal) {
           return new PayPalPaymentProcessor();
       } else {
           return new CreditCardPaymentProcessor();
       }
   }

2. 복잡한 의존성 설정
   구현체가 의존하는 추가 빈이나 설정값이 복잡하게 얽혀 있는 경우, 수동 등록을 통해 빈 생성 과정을 세밀히 관리할 수 있습니다.

   @Bean
   public ReportGenerator reportGenerator(DependencyA a, DependencyB b) {
       return new CustomReportGenerator(a, b, additionalConfig);
   }

3. 조건부 빈 생성
   다형성을 사용할 때 특정 환경(예: 프로파일, 조건)에 따라 구현체를 변경해야 하는 경우도 수동 등록이 적합합니다.
   예를 들어, @Conditional 애너테이션과 함께 사용하면 스프링 컨텍스트 내 조건부 로직을 추가할 수 있습니다.

   @Bean
   @Conditional(OnProductionEnvironment.class)
   public NotificationService productionNotificationService() {
       return new EmailNotificationService();
   }
   
   @Bean
   @Conditional(OnDevelopmentEnvironment.class)
   public NotificationService devNotificationService() {
       return new ConsoleNotificationService();
   }

4. 다중 구현체를 관리하는 팩토리
   여러 구현체를 다뤄야 할 경우 팩토리를 통해 수동으로 빈을 등록하는 것이 더 직관적입니다.

   @Bean
   public ShapeFactory shapeFactory(List<Shape> shapes) {
       return new ShapeFactory(shapes);
   }

 

---

자동 등록보다 수동 등록이 필요한 이유

자동 등록(@Component, @Service, 등)은 스프링이 구현체를 자동으로 감지하고 주입하지만, 아래의 제약이 있을 수 있습니다:

1. 이름 충돌 문제
   같은 타입의 여러 구현체를 자동으로 감지할 경우, 어느 것을 주입해야 할지 명확히 하기 어려움.
2. 동적 로직의 필요성
   런타임에서 조건적으로 구현체를 선택해야 할 때 자동 등록은 유연성이 떨어짐.
3. 구성 관리의 복잡성
   특정 구현체가 다른 빈에 강하게 의존하고 이를 커스터마이징해야 한다면, 수동 등록으로 처리하는 것이 더 효과적.

---

결론

다형성을 많이 사용하는 상황에서 수동 빈 등록은 명시성, 유연성, 조건부 제어 등의 장점을 제공합니다. 특히, 런타임 조건에 따라 구현체를 선택하거나 복잡한 의존성 트리를 관리해야 할 때 적합합니다. 이를 통해 코드는 더 읽기 쉽고 유지보수가 쉬워질 수 있습니다.

 

후기..

 

이번 학기도 다 끝나간다. 

이제 2학년을 마치는데 1학년 때보다 꼼수만 늘고 아직 아는 것도 별로 없는 것 같다.

지금도 불안하고 앞으로도 불안하겠지만 항상 하던데로 그냥 하다보면 또 새로운 기회가 오지 않을까 싶다.

이제 스프링, NodeJs 를 해봤으니 다음은 FastAPI를 해서 제미니를 서빙해볼까...? 하는 생각도 들고 

맛보기 그만하고 하나를 우직히 파볼까도 생각이 든다.

군대 갔다오면 초기화 라는데 군대가서 공부.. 해야지.. 다들 건강하길..