제어의 역전(IOC) 톺아 보기

제어의 역전 톺아 보기

오늘은 제어의 역전(Inversion of Control, IoC)의 개념과 현대 소프트웨어 개발에서 이 개념이 중요한 이유를 알아보겠습니다.

또한 전통적인 방식과 IoC 방식의 코드를 비교하여 두 접근 방식의 차이를 살펴보고, 마지막으로 IoC가 제공하는 장단점을 정리해볼게요.

 

IoC란 무엇인가?

---

제어의 역전

제어의 역전(Inversion of Control, IoC)은 객체 생성과 의존성 연결 같은 제어 권한을 애플리케이션 코드가 아니라 외부(컨테이너나 프레임워크)가 담당하도록 하는 설계 원칙입니다.

 

기존에는 개발자가 직접 흐름을 제어했지만, IoC에서는 외부가 이 역할을 대신합니다. 즉, 제어의 주도권이 코드 내부에서 외부로 이동하는 구조가 IoC의 핵심입니다.

 

전통적인 방식

class TraditionalService {
    private Dependency dependency;
    
    public TraditionalService() {
        this.dependency = new Dependency();
    }
    
    public void doSomething() {
        dependency.performAction();
    }
}

class Dependency {
    public void performAction() {
        // 비즈니스 로직
    }
}

• 서비스 클래스가 의존 객체를 직접 생성합니다(new Dependency()).
• 의존성 관리가 코드 내부에 집중되어 있습니다.
• 제어 흐름의 중심이 서비스 코드에 있어 결합도가 높아지고 확장성이 떨어집니다.

즉, 모든 책임이 서비스 내부에 모이기 때문에 변경에 취약하고 유지보수가 어려워집니다.

 

IoC 방식

class IocService {
    private Dependency dependency;
    
    public IocService(Dependency dependency) {
        this.dependency = dependency;
    }
    
    public void doSomething() {
        dependency.performAction();
    }
}

class IocContainer {
    public static void main(String[] args) {
        Dependency dependency = new Dependency();
        IocService service = new IocService(dependency);
        service.doSomething();
    }
}

• 의존 객체는 서비스 내부가 아닌 외부(IocContainer)에서 생성합니다.
• 서비스는 생성자를 통해 의존성을 주입받아 사용합니다.
• 서비스는 자신의 역할만 수행하며, 객체 생성과 연결은 외부가 관리합니다.

즉, IocService는 제어 흐름을 직접 관리하지 않고, IocContainer가 객체 생성과 조합을 담당합니다. 이 구조가 바로 제어의 역전이며 IoC의 핵심입니다.

 

 IoC가 제공하는 가치

---

낮은 결합도

@Service
class Service {
    private final Repository repository;
    
    @Autowired
    public Service(Repository repository) {
        this.repository = repository;
    }
    
    public void performAction() {
        repository.saveData();
    }
}

Service는 Repository의 구현 방식을 알 필요가 없습니다.

구현이 바뀌어도 서비스 코드는 영향을 받지 않아 유지보수성이 높습니다.

 

테스트 용이성

class ServiceTest {

    @Test
    void performAction_callsRepositorySave() {
        // Mock 생성
        Repository mockRepository = Mockito.mock(Repository.class);

        // Service에 Mock 주입
        Service service = new Service(mockRepository);

        // 실행
        service.performAction();

        // 검증
        Mockito.verify(mockRepository).saveData();
    }
}

의존 객체를 외부에서 주입하기 때문에 테스트 환경에서는 실제 구현 대신 Mock이나 Stub을 주입해 독립적으로 테스트할 수 있습니다.

 

코드 재사용성 증가

@Repository
class UserRepository {
    public void saveUser(User user) { /* ... */ }
}

@Service
class UserService {
    private final UserRepository repository;

    @Autowired
    public UserService(UserRepository repository) {
        this.repository = repository;
    }
}

@Service
class AdminService {
    private final UserRepository repository;

    @Autowired
    public AdminService(UserRepository repository) {
        this.repository = repository;
    }
}

IoC를 사용하면 동일한 구성 요소(Repository, Utility 등)를 여러 서비스에서 재사용할 수 있어 중복 구현을 줄일 수 있습니다.

 

유지보수 및 확장성 향상

서비스는 인터페이스에만 의존하므로, 실제 구현체를 교체해도 서비스 코드를 수정할 필요가 없습니다.
새로운 기능이 필요하면 구현체만 추가하거나 교체하면 됩니다.

 

기존 구조

interface PaymentGateway {
    void pay(int amount);
}

@Component
class KakaoPayGateway implements PaymentGateway {
    public void pay(int amount) { /* ... */ }
}

@Service
class OrderService {
    private final PaymentGateway gateway;

    @Autowired
    public OrderService(PaymentGateway gateway) {
        this.gateway = gateway;
    }

    public void order(int amount) {
        gateway.pay(amount);
    }
}

 

새 구현체 추가(서비스 수정 없음)

@Component
class TossPayGateway implements PaymentGateway {
    public void pay(int amount) { /* ... */ }
}

 

설정만 교체하면 끝

@Configuration
class PaymentConfig {

    @Bean
    public PaymentGateway paymentGateway() {
        return new TossPayGateway(); // 기존 KakaoPay → TossPay로 교체
    }
}

 

서비스(OrderService)는 그대로 두고도 결제 방식 변경이 가능합니다.

 

IoC의 단점

---

높은 학습 난이도

IoC는 주로 Spring과 같은 프레임워크와 함께 사용되기 때문에, 초기에 개념과 어노테이션, 컨테이너 동작 방식 등을 이해해야 합니다. 이로 인해 학습 부담이 커질 수 있습니다.

 

내부 동작의 복잡성

프레임워크가 객체 생성과 생명주기를 모두 관리하므로 초기화 과정이 복잡해지고, 이 과정에서 추가적인 성능 비용이 발생할 수 있습니다.

 

IoC와 프레임워크의 관계

---

프레임워크와 라이브러리를 구분하는 핵심 기준 중 하나는 제어권이 어디에 있는가입니다. IoC 적용 여부가 이를 명확하게 보여 줍니다.

프레임워크 vs 라이브러리

프레임워크

프레임워크가 프로그램의 제어 흐름을 주도하며, 개발자는 프레임워크가 정의한 규칙에 따라 코드를 작성합니다. 이 과정에서 IoC가 적용됩니다.

 

라이브러리

개발자가 필요할 때 직접 호출해 사용하는 도구로, 제어권은 개발자에게 있습니다. IoC는 적용되지 않습니다.

 

즉, 프레임워크는 IoC를 기반으로 동작하는 경우가 많지만, 라이브러리는 제어권을 개발자가 유지하는 구조입니다.

 

제어의 역전(IoC)은 객체 생성과 의존성 관리를 외부에 위임해 시스템을 더 유연하고 유지보수하기 쉬운 구조로 만드는 핵심 설계 개념입니다.

다음 글에서는 IoC를 구현하는 대표적인 방식인 의존성 주입(DI, Dependency Injection)을 살펴볼게요 :)