111. 할리우드 원칙 (Hollywood Principle)

핵심 인사이트 (3줄 요약)

본질: 할리우드 원칙 (Hollywood Principle)은 "먼저 연락하지 마라, 우리가 연락할 것이다 (Don't call us, we'll call you)"라는 표현으로, 상위 모듈이 하위 모듈의 호출 시점과 방법을 결정하는 제어 역전(IoC, Inversion of Control)의 철학적 근간이다.

가치: 하위 모듈이 상위 프레임워크에 의존하지 않고 인터페이스만 구현하면, 프레임워크가 적절한 시점에 하위 모듈을 호출함으로써 하위 모듈과 상위 모듈 간의 순환 의존성(circular dependency)이 사라진다.

판단 포인트: 콜백(callback), 이벤트 리스너(event listener), 템플릿 메서드(Template Method), 의존성 주입(DI) 모두 할리우드 원칙의 구체적 표현이므로, 프레임워크 설계 시 "하위가 상위를 직접 호출하는 구조"가 보이면 원칙 위반 후보다.

Ⅰ. 개요 및 필요성

할리우드 원칙은 영화 오디션 문화에서 유래한 비유다. 오디션을 본 배우(하위 모듈)는 합격 여부를 알기 위해 제작사(상위 프레임워크)에 매일 전화하지 않는다. 제작사가 결정이 나면 배우에게 연락한다. 이 역전된 제어 흐름이 원칙의 핵심이다.

전통적 라이브러리 방식에서는 개발자가 직접 라이브러리를 호출했다. Math.sqrt(4)처럼 개발자 코드가 라이브러리를 호출하고 결과를 받는다. 반면 프레임워크는 개발자의 코드를 호출한다. Spring Framework가 @Controller의 핸들러 메서드를 HTTP 요청이 들어올 때 호출하는 것이 대표적이다. 이 차이가 라이브러리와 프레임워크를 구분하는 본질이다.

┌─────────────────────────────────────────────────────────────┐
│      라이브러리 vs 프레임워크: 제어 방향의 차이              │
├─────────────────────────────────────────────────────────────┤
│ [라이브러리 방식] - 개발자 코드가 제어권 보유                │
│                                                             │
│  개발자 코드 ─────────────────▶ 라이브러리 함수()           │
│  (제어권)                        (호출됨)                   │
│                                                             │
│ [프레임워크 방식 / 할리우드 원칙] - 프레임워크가 제어권 보유 │
│                                                             │
│  프레임워크 ──────────────────▶ 개발자 코드(핸들러)          │
│  (제어권)                        (호출됨)                   │
│       ▲                                                     │
│       │ 개발자는 인터페이스만 구현                           │
└─────────────────────────────────────────────────────────────┘

할리우드 원칙이 없으면 하위 모듈이 상위 모듈에 직접 의존하여 순환 의존성이 생기거나, 하위 모듈이 실행 시점을 스스로 결정하는 폴링(polling) 방식이 되어 자원 낭비와 타이밍 불일치가 발생한다.

📢 섹션 요약 비유: 오디션에 합격한 배우는 촬영 일정을 스스로 정하지 않는다. 감독이 "내일 오전 9시에 스튜디오 3번 방으로 오세요"라고 연락한다. 배우(하위 모듈)는 준비만 하면 된다.

Ⅱ. 아키텍처 및 핵심 원리

할리우드 원칙이 구체화되는 주요 패턴은 네 가지다. ① 콜백(Callback): 함수를 인자로 전달하고 특정 이벤트 시 프레임워크가 호출, ② 이벤트 리스너: 이벤트 발생 시 등록된 핸들러를 시스템이 호출, ③ 템플릿 메서드 패턴: 부모 클래스가 알고리즘 뼈대를 제어하고 자식 클래스의 추상 메서드를 호출, ④ DI 컨테이너: 객체 생성과 생명주기를 프레임워크가 관리하고 필요 시 주입.

항목	설명	포인트
콜백	이벤트 루프, 비동기 엔진 / 콜백 함수	Node.js, JavaScript 이벤트
이벤트 리스너	이벤트 버스, GUI 프레임워크 / 리스너 클래스	Java Swing, Android
템플릿 메서드	추상 클래스의 훅(hook) 메서드 / 구체 클래스 오버라이딩	JUnit, 웹 프레임워크 필터
DI 컨테이너	Spring IoC 컨테이너 / @Component, @Service	Spring, Guice

┌─────────────────────────────────────────────────────────────┐
│      Spring IoC에서 할리우드 원칙 작동 흐름                  │
├─────────────────────────────────────────────────────────────┤
│  [Spring Container]                                         │
│       │                                                     │
│       ├─▶ 1. Bean 정의 스캔 (클래스 탐색)                   │
│       ├─▶ 2. 의존성 분석 및 주입 (@Autowired)               │
│       └─▶ 3. 생명주기 훅 호출 (@PostConstruct)              │
│                                                             │
│  개발자는 @Service만 붙이고 대기 → 컨테이너가 "호출"        │
└─────────────────────────────────────────────────────────────┘

할리우드 원칙을 과도하게 적용하면 코드 실행 흐름을 추적하기 어려워지는 "프레임워크 블랙박스" 문제가 생긴다. 어디서 어떤 코드가 호출되는지 IDE에서 추적하기 어렵고, 디버깅이 복잡해진다.

📢 섹션 요약 비유: 콘서트 무대는 조명감독이 지휘한다. 각 조명 담당자(하위 모듈)는 "큐" 신호가 오면 맡은 조명을 켠다. 각자가 임의로 켜고 끄면 무대는 혼돈이 된다.

Ⅲ. 비교 및 연결

할리우드 원칙은 DIP(의존성 역전 원칙)와 깊이 연결되지만, 적용 관점이 다르다.

비교 축	A	B
핵심 질문	누가 언제 호출하는가 (제어 흐름)	무엇에 의존하는가 (의존성 방향)
강조점	제어의 역전 (IoC)	추상화에 의존
구현 기법	콜백, 이벤트, 훅 메서드	인터페이스, DI
결과	프레임워크가 실행 시점 결정	고수준 모듈이 저수준을 모름

옵저버 패턴(Observer Pattern)도 할리우드 원칙의 표현이다. 구독자(Observer)는 발행자(Subject)에게 "나를 등록해 줘"라고 알리고 대기한다. 이벤트가 발생하면 Subject가 Observer를 호출한다. Observer는 Subject의 내부 상태 변화를 폴링하지 않는다.

📢 섹션 요약 비유: 알림 설정을 켜두면 앱이 새 소식이 생길 때 스마트폰에 푸시 알림을 보낸다. 사용자(Observer)가 5분마다 앱을 열어 확인(폴링)할 필요가 없다.

Ⅳ. 실무 적용 및 기술사 판단

Spring Boot, React의 useEffect, Node.js의 이벤트 루프 모두 할리우드 원칙을 기반으로 동작한다. 실무에서 이 원칙의 위반은 주로 비즈니스 코드가 프레임워크를 직접 참조하거나, 하위 서비스가 상위 서비스를 직접 호출하는 역방향 의존성으로 나타난다.

판단 체크리스트

하위 모듈이 상위 프레임워크 클래스를 직접 import·참조하고 있는가?
하위 서비스가 상위 서비스를 직접 호출하는 역방향 의존성이 존재하는가?
이벤트 기반으로 전환 가능한 폴링(polling) 로직이 있는가?
콜백·이벤트 리스너가 너무 중첩되어 "콜백 지옥(callback hell)"이 형성되고 있는가?
프레임워크의 생명주기 훅(@PostConstruct, @PreDestroy)을 올바르게 활용하고 있는가?

📢 섹션 요약 비유: 신입사원은 상사가 업무를 지시할 때까지 대기한다. 신입사원이 무작정 CEO에게 전화해 "오늘 뭐 하면 되나요?"라고 물으면 조직 체계가 무너진다.

Ⅴ. 기대효과 및 결론

할리우드 원칙을 체계적으로 적용하면 하위 모듈이 프레임워크로부터 독립성을 얻는다. 비즈니스 로직 클래스가 프레임워크 API를 직접 참조하지 않으므로, 프레임워크 교체나 버전 업그레이드의 충격이 최소화된다. 단위 테스트에서도 프레임워크 컨텍스트 없이 POJO (Plain Old Java Object)를 직접 테스트할 수 있다.

한계는 디버깅 복잡성이다. 실행 흐름이 프레임워크 내부를 거쳐 역방향으로 호출되므로, 스택 트레이스(stack trace)가 복잡해지고 "이 코드가 언제, 왜 호출되는가"를 파악하는 데 더 많은 노력이 필요하다. 적절한 로깅(logging)과 문서화가 이 한계를 보완한다.

미래 방향으로는 ① 리액티브 프로그래밍(Reactive Programming)에서 할리우드 원칙의 스트림(Stream) 수준 확장, ② 서버리스(Serverless) 아키텍처에서 함수가 클라우드 트리거에 의해 호출되는 극단적 IoC, ③ AI 에이전트 오케스트레이션에서 에이전트가 오케스트레이터의 호출을 기다리는 패턴이 주목받고 있다.

할리우드 원칙은 "제어권을 상위 프레임워크에 위임하고, 하위 모듈은 규약(인터페이스)만 충실히 구현하면 된다"는 현대 프레임워크 설계의 근본 철학으로 기억해야 한다.

📢 섹션 요약 비유: 자판기는 고객이 버튼을 누를 때만 음료를 내보낸다. 자판기가 스스로 음료를 꺼내거나, 창고 담당자에게 "지금 음료를 꺼내도 될까요?"라고 묻지 않는다. 트리거(버튼)가 오면 반응하는 것이 핵심이다.

📌 관련 개념 맵

[전통 라이브러리 호출] → [할리우드 원칙] → [IoC/DI] → [프레임워크 설계] → [리액티브 프로그래밍]

개념	연결 포인트
IoC (Inversion of Control)	할리우드 원칙을 아키텍처 패턴으로 구체화한 개념
템플릿 메서드 패턴	부모가 자식 메서드를 호출하는 할리우드 원칙 패턴 구현
옵저버 패턴	이벤트 기반 할리우드 원칙의 GoF 패턴 표현
Spring IoC 컨테이너	할리우드 원칙을 엔터프라이즈 수준에서 구현한 프레임워크

📈 관련 키워드 및 발전 흐름도

[라이브러리 직접 호출] → [콜백 패턴] → [할리우드 원칙 정립] → [IoC/DI 프레임워크] → [리액티브 스트림] → [서버리스 FaaS 트리거] → [AI 에이전트 오케스트레이션]

👶 어린이를 위한 3줄 비유 설명

오디션을 보고 집에서 기다리면 제작사에서 "합격했어요, 내일 촬영 오세요"라고 연락이 와요.
배우(하위 모듈)가 매일 제작사에 전화해 "저 뽑혔나요?"라고 묻는 것은 할리우드 원칙 위반이에요.
위에서 부를 때까지 자기 역할을 준비하고 기다리는 것, 그것이 할리우드 원칙이에요!