IoC 와 DI

[JM-220]

📆 일자: 26년 8월 16일(일) : 일주일 미루어졌는데 어제 깜박해서 지금이라도 발제합니다.

Spring을 쓰면 개발자가 직접 객체를 만들지 않고, Spring이 대신 객체를 만들어서 필요한 곳에 넣어줍니다. 이렇게 객체를 만들고 관리하는 걸 프레임워크에 맡기는 걸 IoC(제어의 역전)라고 하고, 그 객체를 실제로 넣어주는 방법을 DI(의존성 주입)라고 합니다. 이번 스터디에서는 IoC와 DI가 각각 무엇이고 왜 쓰는지 쉽게 이해해보려고 합니다.

🤔오늘의 질문

1. IoC(제어의 역전)란 무엇인가요? 쉬운 말로 설명해주세요.
2. DI(의존성 주입)란 무엇이며, 우리가 직접 객체를 만들지 않고 Spring이 대신 넣어주면 뭐가 좋은가요?
3. IoC와 DI는 서로 어떤 관계인가요?

[k9425mino]

1. IoC(제어의 역전)란 무엇인가요? 쉬운 말로 설명해주세요.

IoC(Inversion of Control, 제어의 역전) 은 프로그램의 실행 흐름을 내가 직접 관리하지 않고, 외부에서 관리하도록 맡기는 것이다.

보통 우리가 직접 요리를 한다고 생각해보자.

나
 ↓
재료 준비
 ↓
요리
 ↓
그릇 준비
 ↓
완성

내가 무엇을 언제 할지 전부 직접 결정한다.

그런데 식당에 가면 다르다.

나 → "김치찌개 주세요"
          ↓
      식당 직원
          ↓
    재료 준비 → 요리 → 제공

나는 "김치찌개를 만들어 달라"고만, 실제 요리 과정은 식당이 관리한다.

이것이 IoC의 핵심적인 느낌이다.

프로그래밍에서는, 예를 들어 객체가 다른 객체를 필요로 한다고 해보자.

IoC가 없다면:

class Computer {
	private Keyboard keyboard = new Keyboard();
}

Computer가 직접 Keyboard를 만들어버린다. 즉, Computer가 객체의 생성과 사용을 모두 통제한다.

IoC를 적용하면:

class Computer {
	private Keyboard keyboard;
	
	public Computer(Keyboard keyboard) {
		this.keyboard = keyboard;
	}
}

이제 Computer는 Keyboard를 직접 만들지 않는다. 누군가 밖에서 만들어서 넣어준다.

Keyboard keyboard = new Keyboard();
Computer computer = new Computer(keyboard);

객체를 만드는 제어권이 Computer에서 외부로 넘어간 것이다. 그래서 "제어의 역전"이라고 부른다.

그리고 IoC를 구현하는 대표적인 방법이 DI(Dependency Injection, 의존성 주입)이다.

IoC
└── 제어권을 외부에 맡기는 큰 개념
     │
     └── DI
          └── 필요한 객체를 외부에서 주입받는 방법

---

2. DI(의존성 주입)란 무엇이며, 우리가 직접 객체를 만들지 않고 Spring이 대신 넣어주면 뭐가 좋은가요?

DI(Dependency Injection, 의존성 주입) 는 쉽게 말하면, 객체가 필요한 객체(의존성)를 직접 만들지 않고, 외부에서 만들어서 넣어주는 것이다. 앞에서 설명한 IoC(제어의 역전)를 구현하는 대표적인 방법이라고 볼 수 있다.

DI가 없다면? 예를 들어 OrderService가 PaymentService를 필요로 한다고 해보겠다.

public class OrderService {

    private PaymentService paymentService;

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

여기서는 OrderService가 직접

new PaymentService()

를 사용해서 객체를 만든다.

즉, PaymentService가 필요하니까 자신이 직접 만드는 구조이다.

DI를 사용하면?

public class OrderService {

    private PaymentService paymentService;

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

이제 OrderService는 PaymentService를 직접 만들지 않는다. 외부에서 넣어준다.

PaymentService paymentService = new PaymentService();

OrderService orderService =
		new OrderService(paymentService);

여기서

PaymentService
      ↓
OrderService에 주입
      ↓
OrderService가 사용

이것이 의존성 주입(DI)이다.

Spring을 사용하면 우리가 일일이 객체를 생성하고 연결할 필요가 줄어든다.

예를 들어:

@Service
public class PaymentService {
}

@Service
public class OrderService {
	private final PaymentService paymentService;
	
	@Autowired
	public OrderServcie(PaymentService paymentService) {
		this.paymentService = paymentService;
	}
}

Spring이 애플리케이션을 실행하면서 필요한 객체를 관리하고,

Spring
 │
 ├── PaymentService 객체 생성
 │
 └── OrderService 생성
       │
       └── PaymentService 주입

해준다.

즉, 개발자는 "OrderService는 PaymentService가 필요하다."라고 관계만 알려주고, 객체를 생성하고 연결하는 작업은 Spring에게 맡길 수 있다.

핵심적인 장점은 결합도를 낮추고 유지보수와 테스트를 쉽게 만든다는 것이다.

• ① 객체 간 결합도가 낮아짐: 직접 마들면 OrderService가 PaymentService의 구체적인 구현에 강하게 묶인다. 반면 DI를 사용하면 외부에서 어떤 객체를 넣어줄지 결정할 수 있다.
• ② 테스트하기 쉬워짐: 실무에서 중요한 요소로, 예를 들어 실제 결제 서비스 대신 테스트용 객체를 넣을 수 있다. OrderService의 코드를 수정하지 않고도 다른 구현체를 넣어서 테스트할 수 있다.
• ③ 객체 생성과 관리의 책임을 Spring에게 맡길 수 있음: 애플리케이션이 커지면 객체가 수십 개, 수백 개로 늘어날 수 있다. 직접 관리하면 객체들의 의존성 관계를 개발자가 직접 생성하고 연결해야 한다. Spring을 사용하면 Spring 컨테이너가 객체(Bean)의 생성과 의존성 연결을 관리한다.

---

3. IoC와 DI는 서로 어떤 관계인가요?

IoC는 "제어권을 외부에 맡기는 개념"이고, DI는 "그렇게 제어권을 넘기기 위해 사용하는 방법"이다.

IoC
│
│  "객체의 생성·관리·제어를 외부에서 하도록 하자"
│
└── DI
     "필요한 객체를 외부에서 주입해주자"

[ IoC — 큰 개념 ]

원래 객체가 직접 다른 객체를 만들고 관리한다.

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

OrderService가 PaymentService의 생성까지 직접 통제한다.

IoC를 적용하면 이 제어권을 외부로 넘긴다.

[ DI — IoC를 구현하는 방법 ]

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

OrderService가 PaymentService를 직접 생성하지 않고, 외부에서 전달받는다.

Spring에서는 이 역할을 Spring 컨테이너가 담당한다.

             Spring Container
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
 PaymentService 생성     OrderService 생성
                              │
                              │ 주입
                              ↓
                       PaymentService

DI 외에도 템플릿 메서드, 이벤트 기반 구조 등 제어 흐름을 외부 프레임워크가 결정하는 다양한 형태가 IoC에 포함될 수 있다.

[paiwhy]

1. IoC(제어의 역전)란 무엇인가요? 쉬운 말로 설명해주세요.

→ 제어의 역전은 소프트웨어 개발에서 코드의 흐름과 객체 관리를 외부로 넘김으로써 프로그램의 유연성과 확장성을 높이는 설계 패턴

자바를 예로 들어 main()이라는 메서드로 프로그램의 시작을 제어하고 필요한 객체를 생성하고 메서드를 호출하며 프로그램 실행되는 흐름을 관리 대규모 제작을 하게될경우에 비효율적으로 객체간 의존성이 복잡해지고 코드의 결합도가 높아져 해결하기 위해 제어의 역전을 사용

2. DI(의존성 주입)란 무엇이며, 우리가 직접 객체를 만들지 않고 Spring이 대신 넣어주면 뭐가 좋은가요?

객체가 직접 필요한 다른 객체를 만드는 대신 외부에서 생성된 객체를 전달 받아 사용하는 디자인 패턴으로 객체간의 결합도를 낮추고 유연한 코드를 짤 수 있게 됩니다
직접 객체를 만들지 않고 spring 컨테이너에 직접 넣어달라고 등록하면 좋은 이유는 코드를 바꾸지 않고 주입되는 객체만 교체할 수 있고 테스트와 유지보수에 용이합니다.

3. IoC와 DI는 서로 어떤 관계인가요?

DI(Dependency Injection) 의존성을 외부에서 주입받고
Ioc(Inversion of Control) 코드 흐름을 제어하는 주체가 바뀌는 것을 의미한다

객체간의 관계를 외부에서 결정하고 주입하기에 객체가 제어권을 가지지 않아도 되는 제어의 역전 상태가 유지되는 관계이다

[JM-220]

1. IoC(제어의 역전)란 무엇인가요? 쉬운 말로 설명해주세요.

IoC 는 제어의 흐름을 내가 아니라 프레임워크가 가져가는 것이다. 이름 그대로 제어권이 뒤집힌다.

내가 발제를 냈으니 예시를 좀 자세히 써보면, 원래 코드는 이렇게 생겼다.

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

여기서 흐름의 주도권은 OrderService 에 있다. 언제 PaymentService 를 만들지, 어떤 구현체를 만들지, 언제 버릴지 전부 내가 정한다. 라이브러리를 쓸 때가 이런 구조이다. 내가 필요할 때 내가 호출한다.

프레임워크는 반대이다. 내가 프레임워크를 호출하는 게 아니라, 프레임워크가 내 코드를 호출한다. 나는 클래스를 만들어서 @Service 같은 걸 붙여두고, 언제 만들어지고 언제 불릴지는 스프링이 정한다. "Don't call us, we'll call you" 라고 표현하는 걸 봤는데 이게 제일 와닿았다.

여기서 객체를 만들고 관리해주는 스프링 쪽 주체가 IoC 컨테이너이고, 컨테이너가 관리하는 객체를 빈(Bean) 이라고 부른다.

한 가지 정리해두고 싶은 건, IoC 가 스프링이 만든 개념은 아니라는 점이다. 이벤트 리스너를 등록해두면 이벤트가 발생할 때 프레임워크가 내 함수를 불러주는 것도 IoC 고, 템플릿 메서드 패턴에서 부모가 흐름을 정하고 자식이 일부만 채우는 것도 IoC 이다. 스프링은 이걸 DI 라는 방식으로 구현한 것뿐이다.

2. DI(의존성 주입)란 무엇이며, 우리가 직접 객체를 만들지 않고 Spring이 대신 넣어주면 뭐가 좋은가요?

DI 는 객체가 필요로 하는 다른 객체를 자기가 만들지 않고, 밖에서 넣어주는 것이다.

위의 코드를 이렇게 바꾸면 DI 이다.

public class OrderService {
    private final PaymentService paymentService;

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

new 가 사라졌다. 이제 OrderService 는 PaymentService 를 "쓰기만" 하고 "만들지는" 않는다. 누가 만들어서 넣어줄지는 밖의 문제가 된다. 스프링을 안 써도 이렇게 짤 수 있고, 스프링은 이 "밖" 을 자동화해주는 것이다.

뭐가 좋은가

• 결합도가 낮아진다. new PaymentService() 를 직접 쓰면 OrderService 는 그 구체 클래스에 묶인다. 생성자로 받으면 인터페이스 타입으로 받을 수 있고, 그러면 구현체를 갈아끼워도 OrderService 코드는 안 건드려도 된다. (카드결제 → 카카오페이로 바꾸는 상황)
• 테스트가 쉬워진다. 이게 체감상 제일 크다고 생각한다. 내부에서 new 를 하면 테스트할 때 그 객체를 가짜로 바꿀 방법이 없어서, OrderService 테스트를 돌리는데 실제 결제 api 가 호출된다. 생성자로 받으면 그냥 mock 객체를 넣어주면 끝이다.
• 객체 관리를 안 해도 된다. 스프링 빈은 기본이 싱글톤이라, 여러 곳에서 PaymentService 를 주입받아도 인스턴스는 하나이다. 직접 하면 싱글톤 관리 코드를 내가 짜야 한다.
• 의존 관계가 드러난다. 생성자 파라미터만 보면 이 클래스가 뭘 필요로 하는지 다 보인다. 파라미터가 7개쯤 되면 "이 클래스가 하는 일이 너무 많은 것 아닌가" 를 바로 알 수 있는데, 필드에서 new 를 하면 이게 안 보인다.

주입 방법은 생성자 / 세터 / 필드(@Autowired) 세 가지가 있는데 생성자 주입이 권장된다. final 을 붙일 수 있어서 불변이 보장되고, 순환참조가 있으면 실행 시점이 아니라 애플리케이션 뜰 때 바로 터져서 빨리 알 수 있다고 함.

3. IoC와 DI는 서로 어떤 관계인가요?

IoC 가 목적(개념)이고 DI 는 그걸 이루는 수단(구현 방법) 중 하나이다. 포함 관계로 보면 IoC ⊃ DI.

• IoC : "제어권을 프레임워크에 넘긴다" 라는 넓은 원칙.
• DI : 그중에서도 "의존 객체를 밖에서 주입한다" 는 구체적인 방법.

그래서 DI 를 쓰면 IoC 를 하는 것이지만, IoC 를 한다고 해서 반드시 DI 인 건 아니다. 위에서 말한 템플릿 메서드 패턴이나 이벤트 콜백도 DI 없이 IoC 이다.

원래는 스프링을 IoC 컨테이너라고 부르는데 왜 굳이 DI 라는 말을 따로 쓰나 싶었는데, 찾아보니 IoC 라는 말이 너무 넓어서 마틴 파울러가 "우리가 말하는 그 IoC 는 정확히는 의존성 주입이다" 라고 이름을 붙인 게 시작이라고 한다. 그래서 두 단어가 거의 같이 붙어 다니는 것 같다.

[9ga0]

1. IoC(제어의 역전)란 무엇인가요? 쉬운 말로 설명해주세요.

IoC(Inverison of Control)는 객체를 만들고 관리하는 주체가 개발자에서 Spring으로 바뀌는 것입니다.
원래 개발자가 필요한 객체를 Car car = new Car(); 과 같이 직접 만들어야했다면, Spring에서는 객체 생성과 관리 등을 Spring 컨테이너가 담당할 수 있게 되는 것입니다. 쉽게 말해, "내가 가지던 객체 생성 및 관리 제어권을 Spring에게 넘긴다." 는 의미가 됩니다.

2. DI(의존성 주입)란 무엇이며, 우리가 직접 객체를 만들지 않고 Spring이 대신 넣어주면 뭐가 좋은가요?

DI(Dependency Injection)는 어떤 객체가 필요로 하는 다른 객체를 외부에서 넣어주는 것입니다. 예를 들어 Car가 Engine을 필요로 한다고 할 때,

//직접 만들면, Car가 스스로 Engine을 생성하기 때문에, Car와 Engine 두 클래스가 강하게 연결됩니다.
class Car {
	private Engine engine = new Engine();
}

//DI를 적용하면, Car는 Engine을 밖에서 받아서 사용하며, Spring에서는 이렇게 Engin 객체를 만들어 필요한 Car에 주입하는 방식이 사용됩니다.
class Car {
	private final Engine engine;
	public Car(Engine engine){
		this.engine = engine;
	}
}

DI를 적용했을 때의 가장 큰 장점은 객체 사이의 결합도가 낮아진다는 것입니다. Car는 원래 자동차의 기능에만 집중하면 되고, Spring이 알아서 어떤 엔진을 사용할지 결정하고, 그 엔진을 생성하기 때문에 객체의 책임이 명확해지고, 유지보수나 테스트에 용이합니다.

3. IoC와 DI는 서로 어떤 관계인가요?

DI는 IoC를 구현하는 대표적인 방법이라고 볼 수 있습니다. 먼저 IoC는 객체를 생성하고 관리하는 제어권을 개발자가 아닌 외부(Spring 등)에게 맡기는 것입니다. 이때 필요한 객체를 생성하지 않고 가져오는 방법 중 하나가 외부에서 만든 것을 주입받는다는 개념의 DI(의존성 주입)입니다.

즉 "Spring은 DI를 통해 IoC를 구현한다."라고 표현할 수 있습니다.

추가 공부 예정)

Spring의 다음 개념인 IoC Container → Bean → @Component → @Autowired
https://shinsunyoung.tistory.com/133

[eunji719]

1. 기존에는 내가 필요한 객체를 직접 만들어서 어떤 구현체를 쓸지 까지 스스로 결정했다. 이제는 이 결정권을 컨테이너에게 넘겨 프레임 워크가 자동으로 만들어 준다고 하여 ‘역전’된다고 표현한다. 가장 많이 쓰는 프레임워크인 스프링에서 역전되는 제어권은 객체의 생성, 의존관계 연결, 생명주기 관리 이 세가지이다. 내 코드가 흐름의 주인이어서 필요한 객체를 내가 new로 만들고 만든 객체의 메서드를 내가 원할 때 호출하고 다 쓰면 내가 마음대로 정리할 수 있다. 라이브러리도 마찬가지이다. 이 방식에서는 제어권은 온전히 내 코드에 있다고 말할 수 있다. 그런데 프레임워크를 쓰면 이 관계가 뒤집힌다. 하나의 메서드를 만들어 두면, 실제로 그걸 언제 부르고, 몇번 부르고, 어떤 스레드에서 부를지, 언제 소멸할지는 전부 컨테이너가 정한다.
2. 의존성 주입이란 객체의 생성과 사용 관심사를 분리하는 설계 방식이다. 스터디 때 우리가 자주했던 main이나 config패키지에 미리 객체를 만들어 놓은 다음 각 클래스에서 생성자 주입 받아 쓰는 방식을 생각하면 된다. 객체지향 설계에서는 클래스가 자기 위에 계층을 모르게 하여, 즉 구체클래스 말고 인터페이스에만 의존하게 하여 최대한 수정을 줄여주는 방향으로 코드를 설계하는 것이 중요하다. 이렇게 코드를 짜면, 구현체를 바꿔도 사용하는 쪽 코드는 수정할 필요가 없기 때문에 훨씬 효율적인 구조가 된다. 스프링 프레임워크에서는 @Autowired 어노테이션 하나면 생성자 주입을 쉽게 할 수 있다!
3. 의존성 주입과 제어의 역전의 관계는 IoC는 원칙이고 DI는 그 원칙을 구현하는 구체적 방법 중 하나이다. 즉 IoC는 객체를 누가 만들고 관리할지에 대한 방향의 전환이고, DI는 그 전환을 실현하는 구체적 기술이라고 생각하면 편하다.

[dnnals]

기본 질문

1. IoC(제어의 역전)란 무엇인가요? 쉬운 말로 설명해주세요.

IoC는 프로그램의 제어 흐름을 개발자가 직접 다루는 것이 아니라, 외부 프레임워크나 컨테이너에 위임하는 소프트웨어 디자인 원칙입니다. 개발자 주도 방식은 개발자가 직접 객체를 생성하고, 필요한 의존성을 만들어 결합하는데 비해 IoC 방식은 객체의 생성, 생명주기 관리, 의존성 연결을 외부 컨테이너가 대신 수행합니다. 이렇게 되면 개발자는 직접 new 키워드로 객체를 직접 생성하지 않아도 되고, 의존 객체를 찾아 연결할 필요가 없으며 객체 소멸, 생명 주기 관리를 하지 않아도 되고, 또 구현체를 손쉽게 교체할 수 있습니다.

2. DI(의존성 주입)란 무엇이며, 우리가 직접 객체를 만들지 않고 Spring이 대신 넣어주면 뭐가 좋은가요?

DI(의존성 주입)이란 클래스가 필요한 다른 객체를 직접 만들지 않고, 외부에서 전달받아 사용하는 것입니다. 의존성 주입은 생성자 주입, 세터 주입, 필드 주입 등이 있고, 의존성 주입으로 Spring이 대신 주입을 해준다면 직접 조립하던 controller, service, repository를 어노테이션만으로 Spring이 대신 조립해 줍니다. 그리고 객체의 생명주기와 객체의 무분별한 생성을 관리해줍니다. 결론적으론 생산성, 유연성, 유지보수성을 극대화해줍니다.

3. IoC와 DI는 서로 어떤 관계인가요?

DI는 IoC를 실현하기 위한 대표적인 방법 중 하나입니다. IoC는 프로그램의 흐름이나 객체의 생성, 관리를 개발자가 직접하지 않고 외부에 넘기는 개념이라면 DI는 IoC라는 원칙을 ‘객체 간의 의존 관계’에 특화하여 구체적인 코드로 구현해 낸 디자인 패턴입니다.