Hollywood Principle

Hollywood Principle

Hollywood Principle 은 객체지향 설계 및 프레임워크 설계에서 널리 쓰이는 원칙으로, “Don’t call us, we’ll call you” 라는 문구로 대표된다. 이 원칙은 저수준 (구현) 모듈이 고수준 (프레임워크, 추상화) 모듈을 직접 호출하는 것이 아니라, 고수준 모듈이 저수준 모듈을 필요할 때 호출하도록 구조를 설계한다. 이를 통해 의존성 부패 (Dependency Rot) 를 방지하고, 시스템의 유연성, 확장성, 테스트 용이성을 높인다. 대표적으로 Inversion of Control, Dependency Injection, Observer, Template Method, Strategy 패턴 등에서 적용된다.

핵심 개념

Hollywood Principle 은 **“Don’t call us, we’ll call you”**라는 문구로 요약되며, 저수준 컴포넌트는 고수준 컴포넌트의 호출을 기다리는 방식으로 제어 흐름을 관리한다. 느슨한 결합, 의존성 부패 방지, 확장성 및 테스트 용이성 확보를 목적으로 하며 프레임워크 설계, 이벤트 기반 시스템, 디자인 패턴 (Observer, Template Method, Strategy 등) 에 적용된다.

1. 제어의 역전 (Inversion of Control, IoC)
   • 프로그램의 제어 흐름이 애플리케이션 코드가 아닌 외부 프레임워크에서 결정되는 원칙
   • 전통적인 “call” 방식에서 “callback” 방식으로의 패러다임 전환
2. 콜백 메커니즘 (Callback Mechanism)
   • 특정 이벤트나 조건 발생 시 자동으로 호출되는 함수나 메서드
   • 비동기 프로그래밍과 이벤트 처리의 핵심 메커니즘
3. 의존성 주입 (Dependency Injection, DI)
   • 객체가 필요한 의존성을 생성하지 않고 외부에서 제공받는 방식
   • 객체 생성과 사용의 책임을 분리하여 결합도를 낮춤
4. 이벤트 기반 아키텍처 (Event-driven Architecture)
   • 이벤트의 발생과 처리를 중심으로 시스템을 설계하는 방식
   • Publisher-Subscriber 패턴의 기반이 되는 아키텍처 스타일
5. 느슨한 결합 (Loose Coupling)
   • 컴포넌트 간 의존성을 최소화하여 변경에 대한 영향을 줄이는 설계 방식
   • 높은 응집도 (High Cohesion) 와 함께 소프트웨어 품질의 핵심 지표
6. 프레임워크 vs 라이브러리 구분
   • 프레임워크: 애플리케이션 코드를 호출하는 주체
   • 라이브러리: 애플리케이션 코드에 의해 호출되는 대상
7. Publisher-Subscriber 패턴
   • 이벤트 발행자와 구독자 간의 비동기 통신을 지원하는 패턴
   • 일대다 통신과 느슨한 결합을 동시에 실현

배경 및 필요성

Hollywood Principle 은 1980 년대 후반 객체지향 프로그래밍의 발전과 함께 등장했다. Martin Fowler 가 1988 년으로 그 기원을 추적하였으며, 할리우드 오디션에서 흔히 듣는 “Don’t call us, we’ll call you” 문구에서 이름이 유래되었다.

필요성:

• 코드의 재사용성 향상
• 컴포넌트 간 결합도 감소
• 테스트 가능성 증대
• 확장성과 유지보수성 개선
• 관심사의 분리 실현

주요 기능 및 역할

1. 제어 흐름 관리: 프레임워크가 애플리케이션의 실행 흐름을 제어
2. 의존성 관리: 객체 간 의존성을 외부에서 주입하여 관리
3. 이벤트 처리: 비동기적 이벤트 발생과 처리를 조율
4. 생명주기 관리: 객체의 생성, 초기화, 소멸을 프레임워크가 관리
5. 확장점 제공: 플러그인이나 확장 모듈을 위한 훅 (Hook) 제공

특징

• 비침입적 (Non-intrusive): 비즈니스 로직에 프레임워크 코드가 침투하지 않음
• 선언적 (Declarative): 설정이나 어노테이션을 통한 선언적 프로그래밍
• 확장가능 (Extensible): 새로운 구현체를 쉽게 추가할 수 있는 구조
• 테스트 친화적: Mock 객체를 쉽게 주입하여 단위 테스트 용이

핵심 원칙

1. “Don’t call us, we’ll call you”: 능동적 호출에서 수동적 대기로의 전환
2. 제어권 위임: 애플리케이션 코드가 제어권을 프레임워크에 위임
3. 인터페이스 기반 설계: 구체 클래스 대신 인터페이스에 의존
4. 관심사 분리: 비즈니스 로직과 인프라스트럭처 코드의 분리

작동 원리

• 저수준 컴포넌트 (플러그인, 리스너 등) 는 고수준 컴포넌트에 등록만 한다.
• 고수준 컴포넌트 (프레임워크, 이벤트 디스패처 등) 가 필요할 때 저수준 컴포넌트를 호출한다.

sequenceDiagram
    participant Client as Client Code
    participant Framework as Framework
    participant Callback as Callback Handler
    
    Note over Client,Callback: 1. 등록 단계 (Registration Phase)
    Client->>Framework: register(callback)
    Framework->>Framework: store callback in registry
    
    Note over Framework: 2. 대기 단계 (Waiting Phase)
    Note over Framework: Framework waits for events/conditions
    
    Note over Framework: 3. 트리거 단계 (Triggering Phase)
    Framework->>Framework: Internal event occurs
    
    Note over Framework,Callback: 4. 호출 단계 (Invocation Phase)
    Framework->>Callback: "Don't call us, we'll call you"
    
    Note over Callback: 5. 실행 단계 (Execution Phase)
    Callback->>Callback: Execute business logic
    
    Note over Framework: 6. 반환 단계 (Return Phase)
    Callback->>Framework: Return control/result
    Framework->>Client: Optional: notify completion

Hollywood Principle 의 작동 원리는 다음과 같은 단계로 구성된다:

1. 등록 단계 (Registration): 클라이언트 코드가 프레임워크에 콜백이나 핸들러를 등록
2. 대기 단계 (Waiting): 클라이언트는 능동적으로 호출하지 않고 대기
3. 트리거 단계 (Triggering): 프레임워크 내부에서 특정 이벤트나 조건 발생
4. 호출 단계 (Invocation): 프레임워크가 등록된 콜백을 호출
5. 실행 단계 (Execution): 클라이언트의 비즈니스 로직 실행
6. 반환 단계 (Return): 제어권이 프레임워크로 돌아감

구조 및 아키텍처

Hollywood Principle 은 고수준 모듈이 제어 흐름을 담당하고 저수준 모듈은 콜백, 이벤트 등록, 추상 클래스 상속 등을 통해 호출될 수 있는 상태를 유지하는 구조이다.

graph TB
    subgraph "Hollywood Principle 전체 아키텍처"
        Framework[Framework/Container]
        
        subgraph "필수 구성요소 (Essential Components)"
            Registry[Callback Registry]
            EventManager[Event Manager]
            LifecycleManager[Lifecycle Manager]
        end
        
        subgraph "선택 구성요소 (Optional Components)"
            ConfigManager[Configuration Manager]
            SecurityManager[Security Manager]
            MonitoringManager[Monitoring Manager]
        end
        
        subgraph "클라이언트 구성요소 (Client Components)"
            ClientCode[Client Code]
            CallbackHandlers[Callback Handlers]
            EventListeners[Event Listeners]
        end
        
        Framework --> Registry
        Framework --> EventManager
        Framework --> LifecycleManager
        Framework -.-> ConfigManager
        Framework -.-> SecurityManager
        Framework -.-> MonitoringManager
        
        ClientCode --> CallbackHandlers
        ClientCode --> EventListeners
        
        Registry --> CallbackHandlers
        EventManager --> EventListeners
        LifecycleManager --> ClientCode
        
        style Framework fill:#e8f5e8
        style Registry fill:#e3f2fd
        style EventManager fill:#e3f2fd
        style LifecycleManager fill:#e3f2fd
        style ConfigManager fill:#fff3e0
        style SecurityManager fill:#fff3e0
        style MonitoringManager fill:#fff3e0
        style ClientCode fill:#fce4ec
        style CallbackHandlers fill:#f3e5f5
        style EventListeners fill:#f3e5f5
    end

구성요소

구현 기법

Dependency Injection (의존성 주입)

• 제어 역전: 객체 생성과 의존성 주입을 컨테이너가 담당
• 핵심: " 객체를 직접 생성하지 말고, 주입받아 사용하세요 "

graph TD
    subgraph "Dependency Injection Pattern"
        DI_Container[DI Container]
        DI_Service[Service Interface]
        DI_ServiceImpl[Service Implementation]
        DI_Client[Client Class]
        
        DI_Container -->|creates & injects| DI_ServiceImpl
        DI_Container -->|creates & injects| DI_Client
        DI_Client -.->|depends on| DI_Service
        DI_ServiceImpl -.->|implements| DI_Service
        
        style DI_Container fill:#e8f5e8
        style DI_Service fill:#e3f2fd
        style DI_ServiceImpl fill:#fff3e0
        style DI_Client fill:#fce4ec
    end

정의: 객체가 필요한 의존성을 생성하지 않고 외부에서 주입받는 기법
구성:

• Injector (주입자): 의존성을 제공하는 주체
• Service (서비스): 주입될 의존성 객체
• Client (클라이언트): 의존성을 필요로 하는 객체

목적: 객체 생성과 사용의 책임 분리, 결합도 감소
실제 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Spring Framework 예시
@Service
public class OrderService {
    private final PaymentService paymentService;
    
    // 생성자 주입
    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

Observer Pattern (관찰자 패턴)

• 제어 역전: 상태 변화 알림을 Subject 가 주도
• 핵심: " 변화를 감지하면 우리가 알려드리겠습니다 "

graph TD
    subgraph "Observer Pattern"
        Subject[Subject]
        Observer1[Observer 1]
        Observer2[Observer 2]
        ObserverN[Observer N]
        
        Subject -->|"notifyObservers()"| Observer1
        Subject -->|"notifyObservers()"| Observer2
        Subject -->|"notifyObservers()"| ObserverN
        
        Observer1 -.->|subscribe| Subject
        Observer2 -.->|subscribe| Subject
        ObserverN -.->|subscribe| Subject
        
        style Subject fill:#e8f5e8
        style Observer1 fill:#e3f2fd
        style Observer2 fill:#e3f2fd
        style ObserverN fill:#e3f2fd
    end

정의: 객체의 상태 변화를 여러 관찰자에게 자동으로 알리는 패턴
구성:

• Subject (주제): 상태 변화의 주체
• Observer (관찰자): 변화를 감지하고 처리하는 객체

목적: 일대다 의존성 정의, 느슨한 결합 실현
실제 예시:

1
2
3
4
5
6
7
8
9

// JavaScript EventEmitter 예시
const EventEmitter = require('events');
const emitter = new EventEmitter();

emitter.on('dataChanged', (data) => {
    console.log('Data updated:', data);
});

emitter.emit('dataChanged', { id: 1, value: 'new data' });

Template Method Pattern (템플릿 메서드 패턴)

• 제어 역전: 알고리즘 실행 순서를 상위 클래스가 제어
• 핵심: " 전체 흐름은 우리가 관리하고, 세부사항만 구현하세요 "

graph TD
    subgraph "Template Method Pattern"
        AbstractClass[Abstract Template Class]
        ConcreteClass1[Concrete Class 1]
        ConcreteClass2[Concrete Class 2]
        
        AbstractClass -->|calls| Hook1["primitiveOperation1()"]
        AbstractClass -->|calls| Hook2["primitiveOperation2()"]
        
        ConcreteClass1 -.->|implements| Hook1
        ConcreteClass2 -.->|implements| Hook2
        
        ConcreteClass1 -->|extends| AbstractClass
        ConcreteClass2 -->|extends| AbstractClass
        
        style AbstractClass fill:#e8f5e8
        style ConcreteClass1 fill:#e3f2fd
        style ConcreteClass2 fill:#e3f2fd
        style Hook1 fill:#fff3e0
        style Hook2 fill:#fff3e0
    end

정의: 알고리즘의 골격을 정의하고 하위 클래스에서 세부 단계를 구현하는 패턴
구성:

• Abstract Class (추상 클래스): 템플릿 메서드 정의
• Concrete Class (구체 클래스): 세부 단계 구현

목적: 알고리즘 구조 고정, 세부 구현의 변경 허용
실제 예시:

1
2
3
4
5
6
7
8
9

// Spring JdbcTemplate 예시
public abstract class JdbcTemplate {
    public final List<T> query(String sql, RowMapper<T> mapper) {
        // 1. 연결 획득
        // 2. SQL 실행
        // 3. 결과 처리 (mapper 콜백 호출)
        // 4. 연결 해제
    }
}

Event-driven Programming (이벤트 기반 프로그래밍)

• 제어 역전: 이벤트 발생과 처리를 이벤트 버스가 조율
• 핵심: " 이벤트가 발생하면 우리가 처리하겠습니다 "

graph TD
    subgraph "Event-Driven Pattern"
        EventProducer[Event Producer]
        EventBus[Event Bus]
        EventConsumer1[Event Consumer 1]
        EventConsumer2[Event Consumer 2]
        EventQueue[Event Queue]
        
        EventProducer -->|publish| EventBus
        EventBus -->|enqueue| EventQueue
        EventQueue -->|dispatch| EventConsumer1
        EventQueue -->|dispatch| EventConsumer2
        
        EventConsumer1 -.->|subscribe| EventBus
        EventConsumer2 -.->|subscribe| EventBus
        
        style EventProducer fill:#e8f5e8
        style EventBus fill:#e3f2fd
        style EventQueue fill:#fff3e0
        style EventConsumer1 fill:#fce4ec
        style EventConsumer2 fill:#fce4ec
    end

정의: 이벤트 발생에 따라 프로그램 흐름이 결정되는 프로그래밍 방식
구성:

• Event Producer (이벤트 생산자): 이벤트를 발생시키는 주체
• Event Bus (이벤트 버스): 이벤트 전달 매개체
• Event Consumer (이벤트 소비자): 이벤트를 처리하는 주체

목적: 비동기적 상호작용 처리, 시스템 간 결합도 감소
실제 예시:

1
2
3
4
5
6
7

// Node.js 이벤트 루프 예시
const fs = require('fs');

fs.readFile('data.txt', (err, data) => {
    if (err) throw err;
    console.log(data); // 콜백이 호출됨
});

장점과 단점

• 장점은 시스템의 유연성, 테스트성, 재사용성, 구조적 품질을 대폭 향상시킴
• 단점은 시스템의 추상화 수준 증가, 학습 난이도, 디버깅/성능 관리 부담
• **현대 프레임워크 (Spring, NestJS, Angular 등)**는 이러한 장단점을 구조적으로 흡수할 수 있도록 다양한 도구 (DevTools, AOP, 트레이싱 등) 를 함께 제공

도전 과제

• IoC 기반 설계는 유연성과 확장성의 장점이 크지만, 동시에 복잡성과 학습 비용, 디버깅 어려움이라는 단점이 동반된다.
• 이러한 도전 과제를 해결하기 위해선 설계 명확화, 도구 활용, 문서화, 교육 체계화가 필수이다.
• 특히 로깅/모니터링/트레이싱 도구는 실무에서 IoC 설계의 가시성과 유지보수성을 확보하는 핵심 도구이다.

분류에 따른 종류 및 유형

실무 적용 예시

활용 사례

사례 1: 주문 처리 시스템에서 이메일 알림 처리

시나리오: 주문 처리 시스템에서 이메일 알림 처리

시스템 구성:

• OrderService: 주문 처리 및 이벤트 발행
• EmailNotificationService: 이벤트 리스너로 동작하여 메일 발송
• EventDispatcher: 이벤트 관리 및 분배

Workflow 다이어그램:

sequenceDiagram
  participant OrderService
  participant EventDispatcher
  participant EmailService

  OrderService->>EventDispatcher: emit(OrderCreated)
  EventDispatcher->>EmailService: on(OrderCreated)
  EmailService->>EmailService: sendEmail()

Workflow:

1. 주문 생성 요청 → OrderService
2. 이벤트 발행: OrderCreated
3. EmailService 가 해당 이벤트 수신 후 이메일 발송

역할 요약:

사례 2: 온라인 쇼핑몰 주문 처리 시스템

시나리오: 대규모 온라인 쇼핑몰에서 주문 처리 시 여러 서비스가 협력하여 작업을 수행하는 시스템
시스템 구성 요소:

1. OrderService (주문 서비스): 주문 생성 및 관리
2. EventPublisher (이벤트 발행자): 시스템 이벤트 발행
3. PaymentService (결제 서비스): 결제 처리
4. InventoryService (재고 서비스): 재고 관리
5. EmailService (이메일 서비스): 알림 이메일 발송
6. EventBus (이벤트 버스): 이벤트 중개 및 라우팅
   시스템 구성:

graph TB

    %% Frontend Layer
    subgraph "👤 Frontend Layer"
        User[사용자]
    end

    %% Service Layer
    subgraph "⚙️ Service Layer"
        OrderController[주문 컨트롤러]
        OrderService[주문 서비스]
        EventPublisher[이벤트 발행자]
        EventBus[이벤트 버스]
        PaymentService[결제 서비스]
        InventoryService[재고 서비스]
        EmailService[이메일 서비스]
        LoggingService[로깅 서비스]
        ShippingService[배송 서비스]
        NotificationService[알림 서비스]
    end

    %% Infra Layer (간접적 표현)
    subgraph "💾 Infra Layer"
        Database[(DB 또는 큐 시스템)]
    end

    %% 흐름 정의
    User -->|"1.주문 요청"| OrderController
    OrderController -->|"2.주문 처리"| OrderService
    OrderService -->|"3.이벤트 발행"| EventPublisher
    EventPublisher -->|"4.주문 생성 이벤트"| EventBus

    EventBus -->|"5.결제 처리"| PaymentService
    EventBus -->|"6.재고 차감"| InventoryService
    EventBus -->|"7.이메일 발송"| EmailService
    EventBus -->|"8.로깅"| LoggingService

    PaymentService -->|결제 완료 이벤트| EventBus
    InventoryService -->|재고 차감 이벤트| EventBus
    EventBus -->|배송 준비 이벤트| ShippingService
    ShippingService -->|배송 시작 이벤트| EventBus
    EventBus -->|알림 발송| NotificationService

    %% Infra 연계 표현
    PaymentService --> Database
    InventoryService --> Database
    LoggingService --> Database

Hollywood Principle 의 역할:

1. 이벤트 기반 아키텍처: 각 서비스는 직접 호출하지 않고 이벤트를 통해 통신
2. 느슨한 결합: 서비스 간 직접적인 의존성 없이 독립적 운영
3. 확장성: 새로운 서비스 추가 시 기존 코드 변경 없이 이벤트 구독만 추가
4. 비동기 처리: 블로킹 없이 여러 작업을 동시에 처리

Workflow:

1. 사용자가 주문 요청을 보냄
2. 주문 컨트롤러가 요청을 받아 주문 서비스에 전달
3. 주문 서비스가 " 주문 생성 " 이벤트를 이벤트 버스에 발행
4. Hollywood Principle 적용: 이벤트 버스가 등록된 서비스들을 호출
5. 각 서비스가 독립적으로 작업 수행 (결제, 재고 차감, 이메일 발송)
6. 작업 완료 후 결과를 다시 이벤트로 알림
7. 최종적으로 사용자에게 주문 완료 응답 전송

sequenceDiagram
    participant User as 사용자
    participant Controller as 주문 컨트롤러
    participant OrderSvc as 주문 서비스
    participant EventBus as 이벤트 버스
    participant PaymentSvc as 결제 서비스
    participant InventorySvc as 재고 서비스
    participant EmailSvc as 이메일 서비스
    participant ShippingSvc as 배송 서비스
    
    Note over User,ShippingSvc: 주문 처리 워크플로우
    
    User->>Controller: 1. 주문 요청 (POST /orders)
    Controller->>OrderSvc: 2. 주문 생성 요청
    OrderSvc->>OrderSvc: 3. 주문 데이터 검증 및 저장
    OrderSvc->>EventBus: 4. "OrderCreated" 이벤트 발행
    
    Note over EventBus: Hollywood Principle 적용점:<br/>"우리가 필요한 서비스들을 호출할게요!"
    
    par 병렬 처리 (Parallel Processing)
        EventBus->>PaymentSvc: 5a. 결제 처리 콜백 호출
        PaymentSvc->>PaymentSvc: 결제 API 호출
        PaymentSvc->>EventBus: "PaymentCompleted" 이벤트
    and
        EventBus->>InventorySvc: 5b. 재고 차감 콜백 호출
        InventorySvc->>InventorySvc: 재고 확인 및 차감
        InventorySvc->>EventBus: "InventoryUpdated" 이벤트
    and
        EventBus->>EmailSvc: 5c. 주문 확인 이메일 콜백 호출
        EmailSvc->>EmailSvc: 이메일 템플릿 생성 및 발송
        EmailSvc->>EventBus: "EmailSent" 이벤트
    end
    
    Note over EventBus: 모든 이벤트 완료 확인
    EventBus->>ShippingSvc: 6. 배송 준비 콜백 호출
    ShippingSvc->>ShippingSvc: 배송 라벨 생성
    ShippingSvc->>EventBus: "ShippingPrepared" 이벤트
    
    EventBus->>Controller: 7. 주문 처리 완료 알림
    Controller->>User: 8. 주문 완료 응답 (200 OK)
    
    Note over User,ShippingSvc: 전체 프로세스에서 Hollywood Principle:<br/>각 서비스는 직접 호출하지 않고<br/>이벤트 버스가 필요할 때 호출

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

최적화하기 위한 고려사항

주제와 관련하여 주목할 내용

하위 주제별 추가 학습 필요 내용

관련 분야별 추가 학습 내용

용어 정리

핵심 원칙 및 설계 철학

디자인 패턴 및 구조 전략

비동기/이벤트 기반 프로그래밍

실패 내성 및 안정성 설계

IoC 인프라 및 실무 관련 개념

참고 및 출처

핵심 개념 (Hollywood Principle / IoC / DI)

• Inversion of Control – Wikipedia
• Martin Fowler’s Bliki: Inversion Of Control
• Hollywood Principle – DevIQ
• The Hollywood Principle – DZone
• Hollywood Principle in Software Design – Medium
• What is the Hollywood Principle? – Stack Overflow
• The Hollywood Principle – Matthew Mead Blog
• Design Patterns Explained – Dependency Injection – Stackify
• Three Design Patterns That Use Inversion of Control – SitePoint
• Inversion of Control (IoC) Design Principle – LinkedIn

프레임워크 / 이벤트 시스템 실무 예시

• Spring Events – Baeldung
• Spring – Event Handling – GeeksforGeeks
• Spring Cloud Stream Error Handling Guide

클라우드 / 메시징 / 아키텍처

• Event-Driven Architecture Best Practices – AWS Docs
• Handling Errors in Kafka Consumers – Confluent
• Dead Letter Queues – RabbitMQ
• Martin Fowler – Event-Driven Architecture

기타 참고 아티클 및 커뮤니티 자료

• DEV Community: Code Smell 271 – The Hollywood Principle
• Peter Miľovčík – Hollywood Principle and Patterns
• HackerNoon – The Hollywood Principle의 설계적 의미
• 기계인간 John Grib: 헐리우드 원칙과 의존성 부패
• Doublem.org – 헐리우드 원칙의 실무적 의미