데코레이터 패턴은 무엇이고, 언제 사용하면 좋을까요?

[softmoca]

객체에 기능을 추가해야 할 때 보통 상속을 먼저 떠올릴 수 있습니다.
하지만 기능 조합이 많아질수록 상속만으로 해결하기 어려운 상황이 생깁니다.

예를 들어 커피 주문 기능이 있다고 가정해보겠습니다.
기본 커피에 우유, 샷 추가, 휘핑, 시럽 같은 옵션을 붙일 수 있다면,
각 조합마다 클래스를 만들 경우 클래스 수가 빠르게 늘어날 수 있습니다.

• Americano
• AmericanoWithMilk
• AmericanoWithShot
• AmericanoWithMilkAndShot
• AmericanoWithMilkAndShotAndSyrup

이런 식으로 기능 조합이 늘어날수록 상속 구조는 복잡해지고, 새로운 옵션이 추가될 때마다 기존 구조를 계속 수정해야 할 수 있습니다.

데코레이터 패턴은 이런 문제를 해결하기 위해, 기존 객체를 감싸는 객체를 만들어 기능을 동적으로 추가하는 방식입니다.

즉, 객체 자체를 수정하거나 상속 계층을 계속 늘리지 않고도,
필요한 기능을 하나씩 감싸면서 확장할 수 있습니다.

그렇다면 데코레이터 패턴은 정확히 어떤 구조를 가지고 있을까요?
또 상속을 통한 확장과 비교했을 때 어떤 장점과 단점이 있을까요?
그리고 실제 프로젝트에서는 어떤 상황에서 데코레이터 패턴을 적용해볼 수 있을까요?

[softmoca]

저는 데코레이터 패턴의 본질을
상속(컴파일 타임에 고정되는 확장)을 합성(런타임에 조합되는 확장)으로 대체하는 것
이라고 생각합니다.

핵심은 데코레이터가 자신이 감싸는 대상과 같은 타입이라는 점인데,
이 덕분에 데코레이터로 감싼 객체를 원본과 똑같이 취급할 수 있고,
데코레이터 위에 또 데코레이터를 겹겹이 쌓을 수 있습니다.

이전 상속 토론(LSP)에서 정리했던 "행동 호환성"이 여기서 그대로 전제 조건이 됩니다.
그래서 저는 데코레이터를 "기능을 덧붙이는 기법"이라기보다,
같은 타입을 유지하면서 책임을 동적으로 합성하는 구조로 이해하는 편이 정확하다고 봅니다.

1. 왜 상속만으로는 부족한가 — 조합 폭발

발제에서 짚은 것처럼, 상속으로 기능 조합을 표현하면 조합의 수만큼 클래스가 필요합니다.

옵션이 우유, 샷, 휘핑, 시럽 4개라면 가능한 조합은 2⁴ = 16개입니다. 옵션이 하나 더 늘면 32개가 됩니다. 이걸 클래스로 표현하면 **조합 폭발(combinatorial explosion)**이 일어납니다.

저는 이 문제의 근본 원인이 상속은 컴파일 타임에 확장이 고정된다는 점에 있다고 생각합니다. AmericanoWithMilk는 "아메리카노 + 우유"라는 조합을 클래스 작성 시점에 박아넣은 것입니다. 런타임에 사용자가 "우유랑 샷 빼고 시럽만"이라고 하면, 그 조합에 맞는 클래스가 또 필요합니다.

게다가 새 옵션(예: 카라멜)이 추가되면 기존의 모든 조합 클래스에 카라멜 버전이 추가로 필요해집니다. 이건 OCP(개방-폐쇄 원칙) 위반입니다. 확장할 때마다 기존 구조를 건드려야 하니까요.

데코레이터는 이 문제를 조합을 클래스가 아니라 객체 합성으로 표현해서 해결합니다. 옵션 하나당 데코레이터 하나만 만들면, 그것들을 런타임에 자유롭게 조합할 수 있습니다.

2. 데코레이터 패턴의 구조

데코레이터는 네 가지 역할로 구성됩니다.

// 1. Component: 공통 타입 (감싸는 것과 감싸이는 것이 공유)
public interface Coffee {
    int price();
    String description();
}

// 2. ConcreteComponent: 기본 구현
public class Americano implements Coffee {
    public int price() { return 4000; }
    public String description() { return "아메리카노"; }
}

// 3. Decorator: Component를 구현하면서, Component를 필드로 가짐 (핵심)
public abstract class CoffeeDecorator implements Coffee {
    protected final Coffee coffee;  // 감싸는 대상
    
    protected CoffeeDecorator(Coffee coffee) {
        this.coffee = coffee;
    }
}

// 4. ConcreteDecorator: 실제 기능 추가
public class MilkDecorator extends CoffeeDecorator {
    public MilkDecorator(Coffee coffee) {
        super(coffee);
    }
    
    public int price() {
        return coffee.price() + 500;  // 위임 + 추가
    }
    public String description() {
        return coffee.description() + " + 우유";
    }
}

구조의 핵심 두 가지

저는 이 구조에서 두 가지가 결정적이라고 생각합니다.

(a) 데코레이터는 자신이 감싸는 것과 같은 타입이다 (CoffeeDecorator implements Coffee)

이게 가장 중요합니다. MilkDecorator도 Coffee이기 때문에, 클라이언트는 데코레이터로 감싼 것인지 원본인지 구분할 필요가 없습니다. 그냥 Coffee로 다룹니다.

(b) 데코레이터는 같은 타입의 객체를 필드로 가진다 (protected final Coffee coffee)

데코레이터가 Coffee이면서 동시에 Coffee를 품고 있기 때문에, 데코레이터를 또 다른 데코레이터로 감쌀 수 있습니다. 이 재귀적 구조가 무한한 조합을 가능하게 합니다.

3. 실제로 어떻게 조합되는가

구조의 진가는 사용할 때 드러납니다.

// 아메리카노 + 우유 + 샷 + 시럽
Coffee coffee = new SyrupDecorator(
                    new ShotDecorator(
                        new MilkDecorator(
                            new Americano())));

coffee.price();        // 4000 + 500 + 500 + 300 = 5300
coffee.description();  // "아메리카노 + 우유 + 샷 + 시럽"

호출 흐름

coffee.price()를 호출하면 가장 바깥 데코레이터부터 안쪽으로 위임이 일어납니다.

SyrupDecorator.price()
  → ShotDecorator.price() + 300
      → MilkDecorator.price() + 500
          → Americano.price() + 500
              → 4000

마치 양파 껍질을 벗기듯, 각 데코레이터가 안쪽에 위임하고 자기 몫을 더합니다. 이전 토론에서 다룬 프록시(CGLIB)나 Filter 체인과 구조적으로 닮았다고 느꼈습니다. 셋 다 "같은 타입으로 감싸면서 전후에 무언가를 더한다"는 점이 공통입니다.

런타임 조합의 위력

Coffee 주문 = new Americano();
if (우유추가) 주문 = new MilkDecorator(주문);
if (샷추가) 주문 = new ShotDecorator(주문);

조합이 코드 작성 시점이 아니라 런타임 사용자 선택에 따라 결정됩니다. 상속으로는 불가능한 부분입니다.

4. 상속 확장과의 비교 — 장점과 단점

데코레이터의 장점

• 조합 폭발을 피한다: 옵션 N개에 클래스 2ⁿ개가 아니라 N개만 필요하다
• 런타임 조합이 가능하다: 사용자 선택에 따라 동적으로 기능을 쌓을 수 있다
• OCP를 지킨다: 새 옵션은 새 데코레이터 추가로 끝난다. 기존 코드를 건드리지 않는다
• SRP를 지킨다: 각 데코레이터가 하나의 책임(우유 추가)만 가진다
• 순서를 표현할 수 있다: 감싸는 순서로 적용 순서를 제어할 수 있다

데코레이터의 단점

• 작은 객체가 많아진다: 데코레이터 클래스들이 늘어나 구조 파악이 어려울 수 있다
• 조합 코드가 복잡해진다: new A(new B(new C(...))) 중첩이 깊어지면 읽기 어렵다 (그래서 빌더와 함께 쓰기도 한다)
• 순서 의존성이 생길 수 있다: 감싸는 순서가 결과에 영향을 주면 디버깅이 까다롭다
• 특정 데코레이터를 식별하기 어렵다: 여러 겹으로 감싼 객체에서 "중간에 우유 데코레이터가 있는가?"를 알기 어렵다 (instanceof가 잘 안 통한다)

제 관점

저는 이 비교가 결국 이전 상속 토론과 이어진다고 생각합니다. 그 토론에서 "상속은 강한 결합을 만들고, 행동 호환이 안 되면 위험하다"고 정리했는데, 데코레이터는 상속 대신 합성을 써서 그 결합을 느슨하게 만든 것입니다. "상속보다 합성을 선호하라(Favor composition over inheritance)"는 원칙의 구체적 실현이라고 봅니다.

5. 데코레이터가 성립하기 위한 전제 — LSP

저는 데코레이터를 쓸 때 반드시 의식해야 할 것이 데코레이터가 원본의 행동 계약을 깨면 안 된다는 점이라고 생각합니다. 이전 LSP 토론과 직결됩니다.

MilkDecorator로 감싼 Coffee는 여전히 Coffee로서 클라이언트의 기대를 모두 만족해야 합니다. 만약 어떤 데코레이터가 price()에서 예외를 던지거나, 원본과 전혀 다른 의미로 동작한다면, 클라이언트는 더 이상 Coffee 타입을 믿을 수 없게 됩니다.

// ❌ 행동 호환을 깨는 데코레이터
public class BrokenDecorator extends CoffeeDecorator {
    public int price() {
        throw new UnsupportedOperationException();  // 클라이언트 기대 파괴
    }
}

이건 Penguin이 Bird의 fly()를 못 하는 것과 똑같은 문제입니다. 데코레이터는 "같은 타입으로 감싼다"는 것이 전제이므로, 감싼 후에도 그 타입의 약속을 그대로 지켜야 패턴이 성립합니다. 그래서 저는 데코레이터를 "기능을 마음대로 바꾸는 도구"가 아니라 같은 계약 안에서 책임을 더하는 도구로 이해해야 한다고 봅니다.

6. 실제로 어디에 쓰이는가

데코레이터는 추상적인 패턴 같지만, 사실 우리가 매일 쓰는 곳에 이미 있습니다.

(a) 자바 IO 스트림 — 가장 유명한 예

BufferedReader br = new BufferedReader(
                        new InputStreamReader(
                            new FileInputStream("file.txt")));

FileInputStream(기본)을 InputStreamReader(변환)로 감싸고, 다시 BufferedReader(버퍼링)로 감쌉니다. 정확히 데코레이터 구조입니다. 버퍼링이 필요하면 감싸고, 필요 없으면 안 감싸면 됩니다.

(b) Spring의 HttpServletRequestWrapper

요청을 가공해야 할 때(예: 본문을 여러 번 읽기 위해 캐싱) 원본 요청을 래퍼로 감쌉니다. 이것도 데코레이터입니다.

(c) 컬렉션 래퍼

Collections.unmodifiableList(list)는 원본 리스트를 감싸 "수정 불가"라는 행동을 덧입힙니다. 이전 일급 컬렉션 토론에서 다룬 방어적 복사·불변 래핑과도 연결됩니다.

(d) 횡단 관심사 (프록시와의 경계)

로깅, 캐싱 같은 부가 기능을 덧입힐 때 데코레이터를 쓸 수 있습니다. 다만 이건 프록시 패턴과 헷갈리기 쉬운데, 아래에서 구분하겠습니다.

7. 프록시 패턴과의 차이

이전에 CGLIB·프록시를 다뤘기 때문에, 데코레이터와 프록시의 차이를 짚는 게 의미 있다고 생각합니다. 둘은 구조가 거의 똑같습니다(같은 타입으로 감싼다). 차이는 의도에 있습니다.

• 데코레이터의 의도: 객체에 새로운 기능/책임을 추가한다. 클라이언트가 능동적으로 "우유를 추가해줘"라고 조합한다.
• 프록시의 의도: 객체에 대한 접근을 제어한다(지연 로딩, 권한 검사, 트랜잭션). 클라이언트는 프록시의 존재를 모르고, 원본을 쓴다고 생각한다.

즉 데코레이터는 "기능을 더하려고 일부러 감싸는 것"이고, 프록시는 "접근을 통제하려고 몰래 감싸는 것"입니다. 구조가 같아도 왜 감싸는가가 다릅니다.

8. 미션·실무에서 언제 적용을 고민할까

저는 데코레이터를 다음 신호가 보일 때 고민합니다.

• 기능 조합이 많고, 그 조합이 런타임에 결정된다 (커피 옵션, 알림 채널 조합 등)
• 상속 클래스가 조합 때문에 폭발적으로 늘어나고 있다
• 기존 객체를 수정하지 않고 기능을 덧붙여야 한다 (원본은 건드리면 안 되는 라이브러리 객체 등)
• 기능을 켜고 끄거나 순서를 바꿀 수 있어야 한다

반대로 적용을 자제하는 경우도 분명합니다.

• 조합이 거의 없고 고정적이다 → 그냥 필드나 단순 분기로 충분하다
• 옵션이 1~2개뿐이다 → 데코레이터의 구조적 비용이 이득보다 크다
• 기능 추가가 아니라 접근 제어다 → 프록시가 맞다

이번 예약 대기 미션을 예로 들면, 솔직히 데코레이터가 꼭 필요한 강한 동기는 적다고 생각합니다. 다만 "예약에 부가 정보를 단계적으로 덧붙이는 응답 가공"이나 "알림 채널(메일+푸시+SMS)을 조합하는" 기능이 생긴다면, 각 채널을 데코레이터로 만들어 조합하는 방식을 고려해볼 수 있다고 봅니다. 저는 패턴을 "쓸 수 있으니 쓰자"가 아니라, 조합 폭발이나 OCP 위반이라는 구체적 고통이 보일 때 꺼내는 도구로 여기는 편이 건강하다고 생각합니다.

9. 정리

발제한 입장에서 제 생각을 정리하면 이렇습니다.

데코레이터는 상속(컴파일 타임 고정 확장)을 합성(런타임 조합 확장)으로 바꾸는 패턴이다. 핵심은 데코레이터가 감싸는 대상과 같은 타입을 유지하는 것이고, 그 덕분에 무한히 겹쳐 쌓으면서도 클라이언트는 원본과 똑같이 다룰 수 있다.

• 상속의 조합 폭발과 OCP 위반을 합성으로 해결한다
• 데코레이터가 Component와 같은 타입이라는 점이 재귀적 조합을 가능하게 한다
• 단, 감싼 후에도 원본의 행동 계약을 지켜야 한다 (LSP가 전제)
• 자바 IO, 컬렉션 래퍼, 요청 래퍼 등 실무 곳곳에 이미 쓰인다
• 구조가 같은 프록시와는 "기능 추가 vs 접근 제어"라는 의도로 구분된다

결론적으로 저는 데코레이터를 "상속보다 합성을 선호하라"는 원칙이 조합 확장이라는 구체적 문제에서 구현된 형태라고 봅니다. 그래서 단순히 "기능을 덧붙이는 기법"으로 외우기보다, 같은 타입을 유지하며 책임을 동적으로 쌓는 구조라는 본질로 이해하고, 조합 폭발이나 OCP 위반이라는 실제 고통이 보일 때 꺼내 드는 것이 적절하다고 생각합니다.