IoC(Inversion of Control)
1. 문제 제기(왜 IoC가 필요한가?)
- 전통적인 프로그래밍에서는 개발자가 프로그램의 흐름을 직접 제어함
- 객체 생성, 의존성 주입, 실행 순서 등을 모두 개발자가 관리
- 프로젝트가 커질수록 코드 복잡도가 올라가고 유지보수가 어려워짐
2. 개념(IoC란 무엇인가?)
프로그램의 제어 흐름을 개발자가 아니라 프레임워크나 외부 컨테이너가 담당하는 설계 원리
- 제어권이 개발자에서 프레임워크로 뒤바뀜
3. 예시
Spring Framework(Java)에서 개발자가 @Autowired 같은 어노테이션을 달면, 스프링 컨테이너가 알아서 객체 생성 + 의존성 주입 실행
4. 관련 개념
- DI(Dependency Injection)
- IoC를 구현하는 가장 흔한 방법
- 객체가 스스로 의존성을 만들지 않고 외부에서 주입
5. 장단점
장점
- 유지보수성: 객체 간 결합도(coupling) 낮아짐 -> 코드 수정 시 영향 최소화
- 테스트 용이성: Mock 객체 주입 가능 -> 단위 테스트 편리
- 생산성: 개발자는 비즈니스 로직에 집중할 수 있음
단점
- 제어 흐름 파악이 어려움: 직접 호출하지 않아 "언제 어떻게 실행되는지"를 파악하기는 힘듦
Bean
Spring 컨테이너가 생성하고 관리하는 객체
->@Component를 붙이면 Spring이 Bean으로 등록해준다.
즉, 직접 new를 통해 만들지 않아도 Spring이 알아서 만들어서 필요할 때 주입해준다.
Bean으로 등록했을 때의 이점
① 의존성 자동 주입 (DI: Dependency Injection)
필요한 객체를 new 하지 않고, @Autowired나 생성자를 통해 자동으로 주입받을 수 있음
② 싱글톤 관리 (기본 Scope)
기본적으로 Bean은 싱글톤으로 관리됨 (필요할 때마다 하나만 생성해서 공유)
③ 생명주기 관리 가능 (@PostConstruct, @PreDestroy)
Spring이 객체를 생성하고 초기화한 후에 실행할 코드나, 종료 전에 처리할 로직을 지정 가능
④ AOP 적용 가능 (공통 로직 분리)
Bean으로 등록된 객체는 Spring이 프록시로 감싸므로 트랜잭션 처리, 로깅, 보안 검사 같은 기능을 자동 삽입 가능
⑤ 환경 설정 연동 (@Value, @ConfigurationProperties)
Bean으로 등록된 객체는 설정파일(application.properties, .yml)에서 값을 주입받을 수 있음
⑥ 테스트에 최적화 (스프링 컨테이너 테스트 연동)
Bean으로 등록된 클래스는 @SpringBootTest 등과 함께 통합 테스트 환경에서 쉽게 주입 가능
프록시(Proxy)
대리인(Proxy)이라는 뜻으로, 실제 객체(Real Object)를 감싸서 대신 일을 처리하는 객체
- 클라이언트는 프록시 객체를 통해 실제 객체에 접근
- 목적:
- 접근 제어(보안, 권한 검사)
- 부가 기능 추가(로그, 성능 측정, 트랜잭션 관리 등)
Proxy와 Spring Bean
- 스프링에서 Bean을 직접 반환하는 게 아닌 프록시 객체를 반환하는 경우가 많음
- 스프링은 Bean에 부가 기능(AOP)을 붙여야 할 때가 많기 때문
- 개발자가 보는 건 UserService 같은 Bean이지만, 실제로는 UserService를 감싼 프록시 객체를 IoC 컨테이너가 대신 제공하는 것
장점
- 투명성: 개발자 입장에서 프록시가 있는지 몰라도 됨. 그냥 원래 객체처럼 사용 가능
- 관심사 분리: 핵심 로직(비즈니스)과 부가 기능(로그, 보안, 트랜잭션)을 분리 가능
- 유연성: 다양한 부가 기능을 런타임에 쉽게 적용 가능
