C-3: 행위 패턴 — 객체가 어떻게 협력하나, 전략·옵저버·템플릿 메서드·상태·커맨드

안녕하세요, 홍순구 튜터입니다. 지난 두 시간 동안 우리는 카테고리 C를 절반 넘게 걸어왔어요. 생성 패턴으로 "객체를 어떻게 만드나"를 보고, 구조 패턴으로 "이미 만들어진 객체를 어떻게 조립하나"를 봤죠. 팩토리·빌더·싱글톤으로 객체를 태어나게 했고, 어댑터·데코레이터·퍼사드·프록시로 그 객체들을 감싸고 묶었습니다.

오늘은 디자인 패턴의 마지막 갈래, 행위 패턴(behavioral pattern)으로 갑니다. 객체를 만들었고(C-1) 조립도 했으니(C-2), 이제 그 엮인 객체들이 어떻게 일을 주고받는지를 볼 차례예요. 지난 시간이 "객체를 어떻게 엮나"였다면, 오늘은 "엮은 객체들이 어떻게 협력하나"입니다.

 카테고리 C — 디자인 패턴, 검증된 해법의 카탈로그

 C-1  생성 패턴   "객체를 어떻게 만드나"     (지난 시간)
        팩토리 · 빌더 · 싱글톤(+안티패턴)
 C-2  구조 패턴   "객체를 어떻게 조립하나"    (지난 시간)
        어댑터 · 데코레이터 · 퍼사드 · 프록시
 C-3  행위 패턴   "객체가 어떻게 협력하나"    ← 오늘 여기
        전략 · 옵저버 · 템플릿 메서드 · 상태 · 커맨드

행위 패턴은 코드 리뷰에서 자주 듣는 말들과 짝이 맞아요. "if-else 분기가 스무 개예요", "상태마다 같은 조건문이 중복돼요" 같은 지적이 바로 행위 패턴이 풀어 주는 문제입니다. 그리고 오늘 우리가 B-1에서 본 OCP("확장에는 열고 수정에는 닫는다")가 전략이라는 이름을 달고 돌아오고, C-2에서 예고했던 "거대한 조건문을 다형성으로"가 상태 패턴으로 실현됩니다.

다만 오늘은 마지막에 한 가지를 정면으로 짚어요. 패턴 다섯 개를 손에 쥐면 어디에나 쓰고 싶어지는데, "이거 그냥 함수 하나면 될 걸 클래스 다섯 개로 만들었네요"라는 말이 가장 무서운 코드 리뷰 지적입니다. 패턴은 무기지, 모든 못을 박는 망치가 아니에요. C 카테고리를 닫으며 그 경계를 분명히 긋겠습니다.

💡 오늘 수업의 핵심 — "알고리즘은 전략으로 갈아 끼우고, 변화는 옵저버로 알리고, 절차의 뼈대는 템플릿으로 고정하고, 상태는 객체로 나누고, 요청은 커맨드로 포장한다 — 그리고 다섯 패턴 모두 '단순함이 먼저'라는 경계 위에 선다"

🎯 학습 목표

1. 행위 패턴이 "객체가 어떻게 협력하나"를 푸는 갈래임을 이해하고, 전략·옵저버·템플릿 메서드·상태·커맨드 다섯을 지도로 잡는다.
2. 전략으로 거대한 if/switch를 갈아 끼울 수 있는 알고리즘으로 바꾸고(B-1 OCP 회수), 그 전략이 Java 람다·Python 함수 하나로도 표현됨을 본다. 상태로 흩어진 조건문을 상태별 객체로 모은다(C-2 회수).
3. 옵저버로 느슨하게 알리고, 템플릿 메서드로 절차의 뼈대를 고정하며, 커맨드로 요청을 객체로 포장한다. 그리고 패턴마다 "언제 안 쓰나"의 경계를 쥐고, 마지막에 "패턴을 위한 패턴"의 함정을 정면으로 본다.

Step 1: "객체가 어떻게 협력하나" — 행위 패턴의 지도

생성 패턴이 "객체를 어떻게 태어나게 하나", 구조 패턴이 "객체를 어떻게 조립하나"였다면, 행위 패턴은 그렇게 만들어 조립한 객체들이 실행 중에 어떻게 일을 나눠 맡고 주고받나를 다룹니다. 한 객체가 모든 일을 떠안지 않고, 책임을 잘게 나눠 협력하게 만드는 거예요.

오늘 걸을 다섯 패턴을 먼저 지도에 펼쳐 봅시다.

 행위 패턴 — "객체가 어떻게 협력하나"

 전략         알고리즘을 통째로 갈아 끼운다              (거대한 if/switch 제거)
 옵저버       상태 변화를 구독자들에게 알린다             (느슨한 결합)
 템플릿 메서드  절차의 뼈대는 고정, 한 칸만 자식이 채운다     (상속 기반)
 상태         상태에 따라 행동이 바뀐다                 (if 지옥을 다형성으로)
 커맨드       요청 자체를 객체로 포장한다                (실행 취소·작업 큐)

다섯 패턴을 관통하는 통찰이 하나 있어요. 행위 패턴 상당수는 "바뀌는 부분"을 인터페이스 뒤로 빼낸다는 점에서 닮았습니다. 배송비 계산 방식이 바뀌면 전략으로, 알려야 할 대상이 바뀌면 옵저버로, 절차 중 한 칸이 바뀌면 템플릿으로, 상태마다 행동이 바뀌면 상태 패턴으로 빼냅니다. 변하는 것과 변하지 않는 것을 가르고, 변하는 쪽을 갈아 끼울 수 있게 만드는 게 행위 패턴의 공통된 정신이에요.

특히 전략과 상태는 코드 구조가 거의 똑같습니다. 둘 다 인터페이스 하나에 여러 구현, 그리고 그걸 들고 쓰는 컨텍스트로 이뤄져요. 그런데 의도가 다릅니다. 전략은 외부에서 알고리즘을 골라 끼우고, 상태는 객체가 스스로 다음 상태로 넘어갑니다. 이 차이는 Step 5에서 나란히 두고 보겠습니다. 지금은 "구조가 비슷해도 의도로 갈린다"만 담고 첫 패턴으로 들어가요.

💡 한 줄 정리

행위 패턴은 객체들이 실행 중에 어떻게 협력하나를 푼다. 공통 정신은 "바뀌는 부분을 인터페이스 뒤로 빼내 갈아 끼울 수 있게" 만드는 것이다.

Step 2: "if-else 분기가 스무 개예요" — 전략

첫 패턴은 전략(strategy)입니다. 한마디로 알고리즘을 통째로 갈아 끼울 수 있게 만드는 패턴이에요. 같은 일을 하는 방법이 여러 가지일 때, 그 방법들을 각각 객체로 빼서 필요한 걸 골라 끼웁니다.

배송비를 계산하는 코드를 봅시다. 배송 방법마다 계산식이 달라요. 처음엔 if로 갈래를 나누게 됩니다.

// 배송 방법마다 분기가 늘어나는 거대한 if/switch (behavioral.strategy.ShippingFeeCalculatorBefore)
public class ShippingFeeCalculatorBefore {

    public int fee(String method, int weightGram) {
        if (method.equals("STANDARD")) {
            return 3000;
        } else if (method.equals("EXPRESS")) {
            return 5000;
        } else if (method.equals("OVERNIGHT")) {
            return 9000 + (weightGram / 1000) * 1000;
        } else {
            throw new IllegalArgumentException("알 수 없는 배송 방법: " + method);
        }
    }
}

배송 방법이 하나 늘 때마다 이 메서드를 열어 else if를 한 가지 더 끼워야 합니다. "드론 배송"이 생기면? 또 엽니다. 계산식 하나만 고치려 해도 이 큰 메서드 전체를 다시 읽어야 하고요. 코드 리뷰에서 "분기가 스무 개예요"라고 듣는 모습이 이거예요.

B-1에서 배운 OCP를 떠올려 보세요. "확장에는 열려 있고, 수정에는 닫혀 있어야 한다"고 했죠. 지금 이 코드는 정반대입니다. 확장(새 배송 방법)을 하려면 기존 코드를 수정해야 해요. 이걸 패턴으로 뒤집어 봅시다.

먼저, 갈아 끼울 알고리즘 하나의 약속을 인터페이스로 정합니다.

// 갈아 끼울 수 있는 알고리즘 한 가지의 약속 (behavioral.strategy.ShippingFeePolicy)
public interface ShippingFeePolicy {

    int fee(int weightGram);
}

그리고 배송 방법마다 이 약속을 구현한 전략 객체를 따로 둡니다.

// behavioral.strategy — 방법마다 전략 하나씩
public class StandardShipping implements ShippingFeePolicy {
    @Override
    public int fee(int weightGram) {
        return 3000;
    }
}

public class OvernightShipping implements ShippingFeePolicy {
    @Override
    public int fee(int weightGram) {
        return 9000 + (weightGram / 1000) * 1000;
    }
}

이제 전략을 받아 쓰는 자리입니다. 여기엔 if가 한 줄도 없어요.

// 전략을 주입받아 계산을 위임한다 (behavioral.strategy.ShippingService)
public class ShippingService {

    private final ShippingFeePolicy policy;

    public ShippingService(ShippingFeePolicy policy) {
        this.policy = policy;
    }

    public int checkout(int weightGram) {
        return policy.fee(weightGram);
    }
}

ShippingService는 어떤 배송 방법인지 따지지 않습니다. 생성될 때 전략 하나를 받아 두고, 계산은 그 전략에게 맡길 뿐이에요. 새 배송 방법이 생기면 ShippingFeePolicy를 구현한 클래스 하나만 추가하면 됩니다. ShippingService도, 기존 전략들도 한 줄도 바뀌지 않아요. 확장에는 열려 있고 수정에는 닫혀 있는 — B-1의 OCP가 패턴으로 돌아온 모습입니다.

전략은 사실 함수 하나일 때가 많다 — Java 람다와 Python 함수

여기서 오늘의 가장 중요한 현대적 시각을 하나 심어 둘게요. 방금 ShippingFeePolicy를 보면 메서드가 fee 하나뿐이죠? 메서드가 하나뿐인 인터페이스를 Java에서는 함수형 인터페이스라 부르고, 이런 건 클래스를 따로 만들지 않고 람다 한 줄로 표현할 수 있습니다.

// 전략을 클래스 대신 람다로 — 메서드가 하나뿐이라 가능하다 (behavioral.strategy.ShippingFeeRegistry)
private static final Map<String, ShippingFeePolicy> POLICIES = Map.of(
    "STANDARD", weightGram -> 3000,
    "EXPRESS", weightGram -> 5000,
    "OVERNIGHT", weightGram -> 9000 + (weightGram / 1000) * 1000);

StandardShipping·ExpressShipping·OvernightShipping 세 클래스가 람다 세 줄로 녹았습니다. 새 배송 방법은 맵에 한 줄을 더하면 끝이에요. 클래스도, if 분기도 늘지 않습니다. 이것도 똑같이 OCP고요.

Python에서는 이게 더 자연스럽습니다. 함수가 일급(first-class)이라, "방법 → 함수"를 담은 딕셔너리 하나면 끝나요.

# 전략 = 함수 하나. Python 은 함수가 일급이라 dict 에 담으면 끝이다 (strategy_as_function.py)
SHIPPING_POLICIES = {
    "STANDARD": lambda weight_gram: 3000,
    "EXPRESS": lambda weight_gram: 5000,
    "OVERNIGHT": lambda weight_gram: 9000 + (weight_gram // 1000) * 1000,
}

"GoF 전략 패턴이 사실은 함수가 일급이 아닌 언어에서, 함수를 흉내 내려고 만든 우회로"라는 시각이 여기서 나옵니다. 함수를 변수처럼 다룰 수 있으면, 전략은 그냥 함수 하나면 돼요. 그래서 패턴을 신성한 정답으로 외우는 게 아니라, "왜 이런 모양이 됐나"를 알아야 합니다.

⚠️ 언제 안 쓰나. 갈아 끼울 알고리즘이 지금 단 하나뿐이라면, 전략 인터페이스를 미리 만드는 건 과합니다. "나중에 종류가 늘 것 같아서"만으로 인터페이스를 깔면, 구현이 하나뿐인 빈 추상화만 남아요(YAGNI). 그리고 전략이 짧은 계산 하나라면, 클래스 다섯 개로 늘리지 말고 람다나 함수 하나로 두는 게 더 깔끔합니다. 전략 패턴의 정신은 "알고리즘을 갈아 끼운다"이지 "무조건 인터페이스와 클래스를 만든다"가 아니에요.

💡 한 줄 정리

전략은 갈아 끼울 알고리즘을 인터페이스 뒤로 빼, 거대한 if/switch를 없애고 OCP를 지킨다. 다만 알고리즘이 짧거나 하나뿐이면 클래스 대신 람다·함수 하나로 두는 게 낫다.

Step 3: "상태가 바뀔 때마다 여기저기 알려 줘야 해요" — 옵저버

두 번째는 옵저버(observer)입니다. 상태가 변하면 그걸 구독한 쪽들에게 알려 주는 패턴이에요. 신문 구독을 떠올리면 됩니다. 신문사는 누가 구독하는지만 알고, 구독자들에게 신문을 돌릴 뿐이에요. 구독자가 그 신문으로 뭘 하는지는 신문사가 몰라도 됩니다.

상품 재입고 상황을 봅시다. 품절됐던 상품이 다시 들어오면, 여러 곳에 알려야 해요. 알림 메일도 보내고, "NEW" 배지도 갱신하고요. 처음엔 재입고 처리 안에서 이걸 직접 다 부르게 됩니다.

// 발행자가 통지 대상을 직접 다 안다 — 강결합 (behavioral.observer.ProductBefore)
public class ProductBefore {

    private final StringBuilder emailLog = new StringBuilder();
    private int stock;
    private int badgeCount;

    public void restock(String name, int quantity) {
        this.stock += quantity;
        // 알려야 할 곳을 발행자가 직접 다 호출한다
        emailLog.append(name).append(" 재입고 알림: ").append(quantity).append("개");
        this.badgeCount++;
    }
    // ... getter 생략 ...
}

문제가 보이시나요? "재고를 채운다"는 일과 "여기저기 알린다"는 일이 한 덩어리로 엉켰어요. 알릴 곳이 하나 늘 때마다 이 restock을 열어 코드를 더해야 하고, 통지 대상이 늘수록 이 클래스가 점점 무거워집니다. 재입고 로직을 고치러 들어왔다가 알림 코드까지 마주하게 되죠.

옵저버로 풀어 봅시다. 먼저 "통지를 받는다"는 약속(구독자의 인터페이스)을 정합니다.

// 통지를 받고 싶은 쪽이 구현하는 약속 (behavioral.observer.StockObserver)
public interface StockObserver {

    void onRestock(String product, int quantity);
}

발행자는 구독자 목록을 들고, 재입고가 일어나면 그 목록에 대고 알리기만 합니다.

// 발행자(Subject). 구독자에게 "알린다"는 사실만 안다 (behavioral.observer.Product)
public class Product {

    private final String name;
    private final List<StockObserver> observers = new ArrayList<>();
    private int stock;

    public Product(String name) {
        this.name = name;
    }

    public void subscribe(StockObserver observer) {
        observers.add(observer);
    }

    public void restock(int quantity) {
        this.stock += quantity;
        for (StockObserver observer : observers) {
            observer.onRestock(name, quantity);
        }
    }
    // ... getStock 생략 ...
}

Product는 누가 구독하는지, 그들이 통지를 받아 무엇을 하는지 전혀 모릅니다. 그냥 onRestock을 부를 뿐이에요. 구독자는 각자 자기 일을 합니다.

// 구독자 둘 — 같은 통지를 전혀 다르게 처리한다 (behavioral.observer)
public class EmailObserver implements StockObserver {
    private String lastMessage = "";
    @Override
    public void onRestock(String product, int quantity) {
        this.lastMessage = product + " 재입고 알림: " + quantity + "개";
    }
    // ... getLastMessage 생략 ...
}

public class BadgeObserver implements StockObserver {
    private int restockCount;
    @Override
    public void onRestock(String product, int quantity) {
        this.restockCount++;
    }
    // ... getRestockCount 생략 ...
}

이제 새 구독자가 생겨도 Product는 한 줄도 바뀌지 않아요. subscribe로 끼워 넣으면 그만입니다. 발행자와 구독자가 서로의 속을 모른 채 약속(인터페이스)으로만 연결된 이 상태를 느슨한 결합(loose coupling)이라고 해요. B-1에서 "결합도를 낮추자"고 했던 그 결합도가, 여기선 통지 구조로 낮아진 겁니다.

💡 이 발행-구독의 원리는 현대 백엔드 곳곳에 녹아 있어요. "이벤트가 발생하면 그걸 구독한 여러 핸들러가 반응한다"는 스프링의 이벤트 메커니즘, 데이터의 흐름을 구독해 반응하는 리액티브 스트림이 모두 옵저버의 후예입니다. 다만 그 본격적인 적용은 후속 spring-boot 과정의 몫이에요. 여기서는 "이런 원리 위에 서 있구나"까지만 잡아 둡시다.

⚠️ 언제 안 쓰나. 알릴 대상이 지금 하나뿐이고 앞으로도 늘 일이 없다면, 옵저버 구조는 과합니다. 그냥 직접 호출하는 게 읽기 더 쉬워요. 그리고 옵저버는 "누가 언제 반응하는지"가 코드에 직접 드러나지 않는다는 비용이 있습니다. restock 한 줄을 보고는 무슨 일이 연쇄로 일어나는지 알기 어려워, 문제가 생겼을 때 추적이 까다로울 수 있어요. 통지 순서나 통지 중 예외 처리도 직접 챙겨야 하고요. 느슨한 결합은 공짜가 아닙니다.

💡 한 줄 정리

옵저버는 발행자가 구독자 목록에 대고 알리기만 하고, 구독자는 각자 반응한다. 발행자와 구독자가 인터페이스로만 연결돼 느슨하게 결합되지만, "흐름이 코드에 안 보이는" 비용이 따른다.

Step 4: "공통 절차는 같은데 한 부분만 달라요" — 템플릿 메서드

세 번째는 템플릿 메서드(template method)입니다. 절차의 뼈대는 부모가 고정하고, 그중 달라지는 한 칸만 자식이 채우게 하는 패턴이에요.

리포트를 만든다고 합시다. 어떤 형식이든 "머리말을 쓰고 → 본문을 채우고 → 꼬리말을 쓴다"는 절차는 똑같아요. 오직 본문 형식만 CSV냐 HTML이냐로 갈립니다. 이 "공통 절차 + 한 칸만 다름"을 템플릿 메서드로 표현합니다.

// 절차의 뼈대는 부모가 고정, 본문 한 칸만 자식이 채운다 (behavioral.templatemethod.ReportGenerator)
public abstract class ReportGenerator {

    // 템플릿 메서드 — 절차의 뼈대를 고정한다(자식이 순서를 못 바꾸게 final)
    public final String generate() {
        return header() + body() + footer();
    }

    private String header() {
        return "[리포트 시작]\n";
    }

    // 자식이 채우는 한 칸 — 본문 형식만 다르다
    protected abstract String body();

    private String footer() {
        return "\n[리포트 끝]";
    }
}

generate()가 헤더 → 본문 → 푸터 순서를 못 박습니다. 이게 "템플릿"이에요. 순서를 자식이 함부로 못 바꾸게 final로 잠갔고, 가운데 body()만 추상 메서드로 비워 뒀습니다. 자식은 그 한 칸만 채워요.

// 본문 한 칸만 형식이 다르다 (behavioral.templatemethod)
public class CsvReport extends ReportGenerator {
    @Override
    protected String body() {
        return "이름,점수\n홍길동,90";
    }
}

public class HtmlReport extends ReportGenerator {
    @Override
    protected String body() {
        return "<table><tr><td>홍길동</td><td>90</td></tr></table>";
    }
}

헤더·푸터를 쓰는 절차는 두 자식이 똑같이 물려받고, 본문 한 칸만 다르게 채웁니다. 나중에 "모든 리포트 머리말에 날짜를 넣어 주세요"라는 요구가 오면, 부모의 header() 한 곳만 고치면 모든 자식에 한꺼번에 반영돼요. 절차가 한 곳에 모여 있기 때문입니다.

템플릿 메서드(상속) vs 전략(위임)

여기서 Step 2의 전략과 비교해 봐야 합니다. 둘은 묘하게 닮았어요. "달라지는 한 부분을 빼낸다"는 목표가 같거든요. 그런데 빼내는 방법이 다릅니다.

 같은 목표 — "달라지는 한 부분만 갈아 끼운다", 다른 방법

 템플릿 메서드 (상속)         전략 (위임/컴포지션)
   부모가 뼈대를 들고            컨텍스트가 뼈대를 들고
   자식이 빈 칸을 채운다          전략 객체를 주입받아 맡긴다
   → 컴파일 시점에 고정          → 런타임에 갈아 끼울 수 있다

B-2에서 "상속보다 컴포지션"을 배웠죠? 템플릿 메서드는 상속으로 빈 칸을 채우고, 전략은 위임(컴포지션)으로 채웁니다. 그래서 변하는 게 본문 하나뿐이고 컴파일 시점에 정해져도 된다면 템플릿 메서드가 간결하고, 변하는 방법이 여럿이라 실행 중에 갈아 끼우고 싶다면 전략이 어울려요. 같은 문제를 상속으로 풀 수도, 위임으로 풀 수도 있다는 걸 두 패턴이 나란히 보여 줍니다.

⚠️ 언제 안 쓰나. 템플릿 메서드는 상속에 기댑니다. 상속은 자식을 부모의 뼈대에 단단히 묶어요. 부모의 절차가 바뀌면 모든 자식이 영향을 받고, 자식은 부모 없이 존재할 수 없습니다. 그래서 빼낼 부분이 하나가 아니라 여럿이고, 런타임에 조합을 바꾸고 싶다면 상속의 경직성보다 전략의 유연함이 낫습니다. "공통 절차 + 딱 한 칸"이 또렷할 때만 템플릿 메서드를 쓰세요.

💡 한 줄 정리

템플릿 메서드는 절차의 뼈대를 부모가 final로 고정하고, 달라지는 한 칸만 자식이 상속으로 채운다. 같은 목표를 위임으로 풀면 전략이 되고, 런타임 교체가 필요하면 전략이 더 유연하다.

Step 5: "상태마다 같은 조건문이 중복돼요" — 상태

네 번째는 상태(state) 패턴입니다. C-2 마무리에서 "거대한 조건문을 다형성으로 푸는 상태 패턴"을 예고했었죠. 그걸 오늘 실현합니다. 객체의 상태에 따라 행동이 달라질 때, 그 상태들을 각각 객체로 빼내 조건문을 없애는 패턴이에요.

주문 상태를 봅시다. 결제 완료(PAID) → 배송 중(SHIPPED) → 배송 완료(DELIVERED)로 흐르고, 중간에 취소(CANCELLED)될 수도 있어요. 그런데 "지금 어떤 상태냐"에 따라 할 수 있는 일이 다릅니다. 결제 완료 상태에선 취소가 되지만, 배송 중엔 취소가 안 되죠. 처음엔 이걸 상태 문자열과 if로 풉니다.

// 메서드마다 같은 상태 분기를 되풀이한다 (behavioral.state.OrderBefore)
public class OrderBefore {

    private String status = "PAID";

    public void ship() {
        if (status.equals("PAID")) {
            status = "SHIPPED";
        } else if (status.equals("SHIPPED")) {
            throw new IllegalStateException("이미 배송 중입니다");
        } else if (status.equals("DELIVERED")) {
            throw new IllegalStateException("이미 배송 완료된 주문입니다");
        } else {
            throw new IllegalStateException("취소된 주문은 배송할 수 없습니다");
        }
    }

    public void cancel() {
        if (status.equals("PAID")) {
            status = "CANCELLED";
        } else if (status.equals("SHIPPED")) {
            throw new IllegalStateException("배송 중인 주문은 취소할 수 없습니다");
        } else if (status.equals("DELIVERED")) {
            throw new IllegalStateException("배송 완료된 주문은 취소할 수 없습니다");
        } else {
            throw new IllegalStateException("이미 취소된 주문입니다");
        }
    }
    // deliver() 도 똑같은 상태 분기를 또 한 번 반복한다 ...
}

문제가 보이시죠? ship·cancel·deliver 세 메서드가 저마다 똑같은 상태 분기를 되풀이합니다. 상태가 하나 늘면 세 메서드를 전부 열어 분기를 더해야 하고, "이 상태에서 뭘 할 수 있나"가 코드 곳곳에 흩어져요. 코드 리뷰에서 "상태마다 같은 조건문이 중복돼요"라고 듣는 바로 그 모습입니다.

상태 패턴으로 풀어 봅시다. "이 상태에서 무엇을 할 수 있는가"를 약속으로 정합니다. 각 동작은 다음 상태를 돌려주고, 할 수 없는 동작이면 예외를 던져요.

// "이 상태에서 무엇을 할 수 있는가"의 약속 (behavioral.state.OrderState)
public interface OrderState {

    OrderState ship();

    OrderState deliver();

    OrderState cancel();

    String name();
}

그리고 상태마다 객체를 하나씩 둡니다. 각 상태는 자기 상태에서 가능한 일과 넘어갈 다음 상태만 알아요.

// 결제 완료 상태 — 배송 시작과 취소만 가능하다 (behavioral.state.PaidState)
public class PaidState implements OrderState {

    @Override
    public OrderState ship() {
        return new ShippedState();
    }

    @Override
    public OrderState deliver() {
        throw new IllegalStateException("아직 배송이 시작되지 않았습니다");
    }

    @Override
    public OrderState cancel() {
        return new CancelledState();
    }

    @Override
    public String name() {
        return "PAID";
    }
}

// 배송 중 상태 — 배송 완료로만 넘어간다 (behavioral.state.ShippedState)
public class ShippedState implements OrderState {

    @Override
    public OrderState ship() {
        throw new IllegalStateException("이미 배송 중입니다");
    }

    @Override
    public OrderState deliver() {
        return new DeliveredState();
    }

    @Override
    public OrderState cancel() {
        throw new IllegalStateException("배송 중인 주문은 취소할 수 없습니다");
    }

    @Override
    public String name() {
        return "SHIPPED";
    }
}

이제 주문은 현재 상태 객체 하나만 들고, 동작을 그 객체에게 넘깁니다.

// 현재 상태 객체에게 동작을 위임한다 — if 가 없다 (behavioral.state.Order)
public class Order {

    private OrderState state = new PaidState();

    public void ship() {
        state = state.ship();
    }

    public void deliver() {
        state = state.deliver();
    }

    public void cancel() {
        state = state.cancel();
    }

    public String status() {
        return state.name();
    }
}

Order의 어느 메서드에도 if 분기가 없어요. "지금 어떤 상태 객체인가"가 행동을 정하고, 각 동작은 다음 상태 객체를 돌려받아 갈아 끼웁니다. 흩어졌던 조건문이 상태별 객체로 모인 거예요. 상태가 하나 늘어도 새 상태 클래스 하나만 추가하면 됩니다.

전략과 상태 — 구조는 쌍둥이, 의도는 다르다

Step 1에서 예고했듯, 전략과 상태는 코드 구조가 거의 똑같습니다. 둘 다 인터페이스 + 여러 구현 + 그걸 들고 쓰는 컨텍스트예요. 그런데 의도가 갈립니다.

 전략                          상태
   외부가 알고리즘을 골라 끼운다      객체가 스스로 다음 상태로 넘어간다
   ShippingService(전략을 받음)     Order(state = state.ship())
   "어떻게 계산할까"를 갈아 끼움      "지금 무엇을 할 수 있나"가 바뀜
   전략끼리는 서로를 모른다          상태가 다음 상태를 안다(전이)

전략은 바깥에서 어떤 알고리즘을 쓸지 정해 주입합니다. 상태는 객체 안에서 스스로 다음 상태로 전이해요. 그래서 상태 패턴의 각 상태는 "다음에 어떤 상태가 오는지"를 알지만, 전략들은 서로의 존재를 모릅니다. 구조가 닮았다고 같은 패턴이 아니에요. 의도가 패턴의 정체를 정합니다.

⚠️ 언제 안 쓰나. 상태와 전이가 두세 개로 적고 앞으로도 단순하다면, 상태 클래스를 여러 개 만드는 건 과합니다. 작은 상태 머신은 enum과 switch 하나로도 충분히 읽혀요. 상태 패턴은 상태가 많고, 상태마다 행동이 복잡하며, 전이 규칙이 자주 바뀔 때 값을 합니다. 상태 셋에 동작 하나뿐인데 클래스 셋을 만들면, 오히려 코드가 흩어져 읽기 어려워져요.

💡 한 줄 정리

상태 패턴은 상태마다 객체를 두어, 메서드마다 중복되던 조건문을 없앤다. 전략과 구조는 같지만, 전략은 외부가 알고리즘을 고르고 상태는 객체가 스스로 다음 상태로 전이한다.

Step 6: "방금 한 작업을 되돌리고 싶어요" — 커맨드

마지막 패턴은 커맨드(command)입니다. "요청 하나"를 객체로 포장하는 패턴이에요. 무엇을 할지를 객체에 담아 두면, 그 요청을 나중에 실행하거나, 쌓아 뒀다가 되돌리거나, 큐에 넣어 두는 일이 가능해집니다.

텍스트 편집기를 봅시다. 글자를 입력하는 기능을 가장 단순하게 만들면 이렇게 됩니다.

// 동작을 그 자리에서 바로 수행한다 — 되돌릴 수 없다 (behavioral.command.EditorBefore)
public class EditorBefore {

    private final StringBuilder text = new StringBuilder();

    public void append(String s) {
        text.append(s);
    }

    public String content() {
        return text.toString();
    }
}

동작은 합니다. 그런데 "방금 한 일"을 어디에도 남기지 않아요. 그래서 되돌릴(undo) 방법이 없습니다. 작업을 모아 뒀다 나중에 실행하거나, 로그로 남기는 것도 불가능하고요. 무엇을 했는지가 흔적도 없이 사라지기 때문이에요.

커맨드로 풀어 봅시다. "요청 하나"를 객체로 만듭니다. 무엇을 할지(execute)와 그걸 어떻게 되돌릴지(undo)를 한 객체가 함께 알아요.

// "요청 하나"를 객체로 포장한 약속 (behavioral.command.Command)
public interface Command {

    void execute();

    void undo();
}

"글자를 붙여라"라는 요청을 이 약속으로 구현합니다. 무엇을 붙였는지 기억해 두기에, 되돌릴 때 붙인 만큼 정확히 지울 수 있어요.

// "이 문서에 이 글자를 붙여라"를 객체로 (behavioral.command.AppendCommand)
public class AppendCommand implements Command {

    private final Document document;
    private final String text;

    public AppendCommand(Document document, String text) {
        this.document = document;
        this.text = text;
    }

    @Override
    public void execute() {
        document.append(text);
    }

    @Override
    public void undo() {
        document.deleteLast(text.length());
    }
}

이제 편집기는 커맨드를 실행하고 히스토리에 쌓아 둡니다. 무슨 동작인지 직접 알 필요 없이, 들어온 커맨드를 실행하고 스택에 push할 뿐이에요.

// 커맨드를 실행하고 히스토리에 쌓는다 (behavioral.command.Editor)
public class Editor {

    private final Deque<Command> history = new ArrayDeque<>();

    public void run(Command command) {
        command.execute();
        history.push(command);
    }

    public void undo() {
        if (!history.isEmpty()) {
            history.pop().undo();
        }
    }
}

undo()는 가장 최근 커맨드를 꺼내, 그 커맨드 자신에게 "되돌리라"고 시킵니다. 요청이 객체가 됐기에 실행 취소가 자연스럽게 따라와요. Before에선 불가능했던 일이죠. 같은 구조로 커맨드를 큐에 쌓으면 작업 예약이 되고, 커맨드 목록을 저장하면 매크로가 됩니다. 요청을 객체로 만든다는 한 수가 이 모든 걸 열어 줘요.

💡 커맨드도 현대 언어에선 모습이 가벼워집니다. Java의 Runnable이 사실 "인자도 결과도 없는 커맨드"예요. 메서드 하나짜리라 람다로도 표현되고요. 전략과 마찬가지로, 일급 함수가 있는 곳에선 "요청을 객체로 포장한다"가 "함수를 변수에 담는다"로 녹습니다.

⚠️ 언제 안 쓰나. 실행 취소도, 작업 큐도, 로그도, 매크로도 필요 없다면 커맨드는 과합니다. 그냥 메서드를 직접 부르면 될 일을, 굳이 객체로 포장하면 클래스만 늘어나요. 커맨드는 "요청을 나중에 다루고 싶다"는 분명한 필요가 있을 때 — 되돌리기, 예약 실행, 작업 기록 — 그때 값을 합니다.

💡 한 줄 정리

커맨드는 요청을 execute/undo를 가진 객체로 포장해, 실행 취소·작업 큐·기록을 가능하게 한다. 다만 그런 필요가 없으면 메서드 직접 호출이 낫고, 일급 함수가 있는 언어에선 람다로 가벼워진다.

Step 7: "이거 그냥 함수 하나면 될 걸 클래스 다섯 개로 만들었네요" — 패턴을 위한 패턴을 경계하라

다섯 패턴을 다 봤습니다. 먼저 한 표로 의도를 정리하고, C 카테고리 전체를 닫는 가장 중요한 이야기를 하겠습니다.

다섯 패턴 모두 "바뀌는 부분을 인터페이스 뒤로 빼낸다"는 한 정신을 공유합니다. 빼내는 게 알고리즘이냐(전략), 통지냐(옵저버), 절차의 한 칸이냐(템플릿), 상태냐(상태), 요청이냐(커맨드)로 갈릴 뿐이에요.

패턴은 무기지, 목적이 아니다

이제 C 카테고리 전체를 닫는 경계입니다. 패턴 열 몇 개를 손에 쥐면, 모든 코드에서 패턴을 쓰고 싶어집니다. 그런데 패턴을 많이 쓴 코드가 좋은 코드가 아니에요. 오히려 정반대인 경우가 더 흔합니다.

 ❌ 패턴 과용 — 단순한 일을 복잡하게

   "두 수를 더한다"
     → AdderStrategy 인터페이스
     → PlusStrategy 구현 클래스
     → CalculatorContext 컨텍스트
     → StrategyFactory 팩토리
   다섯 파일을 열어야 a + b 가 보인다


 ✅ 단순함이 먼저

   "두 수를 더한다"
     → return a + b;

"이거 그냥 함수 하나면 될 걸 클래스 다섯 개로 만들었네요" — 이게 패턴을 갓 배운 사람이 가장 자주 듣는 코드 리뷰 지적입니다. 패턴은 문제가 있을 때 꺼내는 해법이지, 미리 깔아 두는 장식이 아니에요. 지금 갈아 끼울 알고리즘이 하나뿐인데 전략을, 알릴 대상이 하나뿐인데 옵저버를, 되돌릴 일이 없는데 커맨드를 두는 건 전부 과잉입니다.

이걸 YAGNI(You Aren't Gonna Need It, "그거 필요 없을걸")라고 불러요. "나중에 필요할 것 같아서" 미리 만든 추상화의 대부분은 끝내 쓰이지 않고, 코드만 복잡하게 만듭니다. 우리가 이번 모듈 내내 패턴마다 ⚠️ "언제 안 쓰나"를 단 이유가 이거예요. 패턴을 아는 것보다 언제 안 쓸지 아는 게 더 어렵고 중요합니다.

그리고 오늘 거듭 본 것처럼, 전략·커맨드는 람다 하나로, 옵저버는 리액티브로 모습을 바꿉니다. 패턴은 "언어를 초월한 영원한 정답"이라기보다, 그 시대 언어가 부족한 부분을 메우려고 사람들이 찾아낸 검증된 우회로에 가까워요. 그러니 패턴을 신성시하지 말고, 도구로 보세요. 손에 든 게 망치라고 모든 게 못으로 보이면 안 됩니다.

 디자인 패턴 카탈로그 (GoF 23) — C 카테고리 완주

 C-1  생성   객체를 어떻게 만드나     팩토리 · 빌더 · 싱글톤 …
 C-2  구조   객체를 어떻게 조립하나    어댑터 · 데코레이터 · 퍼사드 · 프록시 …
 C-3  행위   객체가 어떻게 협력하나    전략 · 옵저버 · 템플릿 · 상태 · 커맨드 …

 → 이제 패턴은 "검증된 해법"이자 "남용하면 독"이라는 양면을 함께 안다

💡 한 줄 정리

다섯 행위 패턴은 "바뀌는 부분을 빼낸다"는 정신을 공유한다. 그러나 패턴을 많이 쓴 코드가 좋은 코드는 아니다. 패턴은 문제가 있을 때 꺼내는 도구지, 미리 까는 장식이 아니다 — 단순함이 먼저다.

마무리

오늘은 행위 패턴 다섯으로 "객체가 어떻게 협력하나"를 익혔습니다. 그리고 C 카테고리 전체를 닫으며, 패턴이 검증된 해법인 동시에 남용하면 독이라는 양면을 함께 봤어요.

오늘 배운 핵심 세 가지

💡 하나 — 행위 패턴은 "바뀌는 부분을 인터페이스 뒤로 빼낸다". 전략은 알고리즘을, 옵저버는 통지 대상을, 템플릿 메서드는 절차의 한 칸을, 상태는 상태별 행동을, 커맨드는 요청 자체를 빼낸다. 거대한 if/switch와 흩어진 조건문이 이 빼내기로 정리된다.

💡 둘 — 구조가 닮아도 의도로 갈린다. 전략과 상태는 코드 구조가 쌍둥이지만, 전략은 외부가 알고리즘을 고르고 상태는 객체가 스스로 전이한다. 템플릿 메서드(상속)와 전략(위임)도 같은 목표를 다른 방법으로 푼다. 패턴의 정체는 코드 모양이 아니라 의도가 정한다.

💡 셋 — 패턴은 무기지 목적이 아니다. 다섯 패턴 모두 람다·함수로 가벼워지고, 필요 없는 자리에 깔면 독이 된다. "함수 하나면 될 걸 클래스 다섯 개로" 만드는 게 가장 흔한 함정이다. 변화가 세 번째로 반복될 때 꺼내라 — 단순함이 먼저다.

다음 시간 예고

다음 시간(D-1)부터는 카테고리 D, 리팩토링으로 갑니다. 지금까지 A·B·C에서 "좋은 코드란 무엇인가"의 목표 지점을 봤다면, 이제는 이미 나빠진 코드를 그 지점으로 안전하게 옮기는 실전이에요.

여기서 오늘 배운 패턴들이 다시 돌아옵니다. 리팩토링의 핵심 기법 중에 "조건문을 다형성으로 바꾸기"가 있는데, 그게 바로 오늘 우리가 거대한 if를 전략으로, 흩어진 조건문을 상태로 바꾼 그 작업이에요. 패턴을 알았기에 리팩토링의 "이 if 지옥을 어디로 끌고 갈지"가 막히지 않습니다. 그리고 그렇게 코드를 바꾸면서도 행동이 바뀌지 않았음을 테스트로 증명하는 안전망을 다음 시간에 처음 정면으로 다룹니다. 돌아가는 코드를 멈추지 않고 고치는 법, D-1에서 만나요.

과제

오늘 배운 패턴을 직접 손으로 적용해 봅니다. 각 Before 코드를 더 나은 구조로 고쳐 보세요. 정답은 예시답안에서 확인할 수 있어요.

[기초] 거대한 환율 변환 if를 전략으로

아래는 외화를 원화로 바꾸는 코드입니다. 통화마다 환율이 달라서 if로 갈래를 나눴어요.

// Before — 통화가 늘 때마다 else if 를 더해야 한다
public class CurrencyConverterBefore {

    public long toKrw(String currency, long amount) {
        if (currency.equals("USD")) {
            return amount * 1300;
        } else if (currency.equals("EUR")) {
            return amount * 1400;
        } else if (currency.equals("JPY")) {
            return amount * 9;
        } else {
            throw new IllegalArgumentException("지원하지 않는 통화: " + currency);
        }
    }
}

ExchangePolicy라는 약속(메서드 long toKrw(long amount))을 두고, 통화마다 전략을 구현해 보세요. 그래서 새 통화(예: GBP)가 생겨도 기존 코드는 수정하지 않고 클래스(또는 람다) 하나만 추가하면 되게 고쳐 보세요. 여유가 있다면, 세 전략 클래스를 만드는 대신 "통화 → 람다"를 담은 맵 하나로도 같은 일을 해 보고, 둘 중 어느 쪽이 이 상황에 더 어울리는지 판단해 보세요.

[응용] 주문 완료의 여러 후처리를 옵저버로

아래는 주문이 완료되면 여러 후처리를 직접 다 부르는 코드입니다.

// Before — 주문 완료 처리가 후처리 대상을 직접 다 안다 (강결합)
public class OrderServiceBefore {

    public void complete(String orderId) {
        // 주문을 완료 처리하고...
        // 알려야 할 곳을 직접 다 호출한다
        System.out.println(orderId + " 재고 차감");
        System.out.println(orderId + " 포인트 적립");
        System.out.println(orderId + " 완료 메일 발송");
    }
}

OrderObserver라는 약속(메서드 void onCompleted(String orderId))을 두고, 재고 차감·포인트 적립·메일 발송을 각각 구독자로 빼내 보세요. 주문 완료 처리(발행자)는 구독자 목록에 대고 알리기만 하고, 누가 무엇을 하는지 모르게 만드는 게 목표입니다. 그런 다음 "쿠폰 발급"이라는 후처리를 하나 더 추가할 때, 발행자 코드를 한 줄도 고치지 않고 끼워 넣을 수 있는지 확인해 보세요.

[심화] 글 발행 상태 머신을 상태 패턴으로

아래는 블로그 글의 상태를 문자열과 if로 관리하는 코드입니다. 초안(DRAFT) → 검토(REVIEW) → 발행(PUBLISHED)으로 흐르고, 검토 중엔 반려(DRAFT로 복귀)할 수 있어요.

// Before — 메서드마다 같은 상태 분기가 중복된다
public class ArticleBefore {

    private String status = "DRAFT";

    public void submit() {   // 검토 요청
        if (status.equals("DRAFT")) {
            status = "REVIEW";
        } else {
            throw new IllegalStateException("초안만 검토 요청할 수 있습니다");
        }
    }

    public void approve() {  // 승인 → 발행
        if (status.equals("REVIEW")) {
            status = "PUBLISHED";
        } else {
            throw new IllegalStateException("검토 중인 글만 발행할 수 있습니다");
        }
    }

    public void reject() {   // 반려 → 초안
        if (status.equals("REVIEW")) {
            status = "DRAFT";
        } else {
            throw new IllegalStateException("검토 중인 글만 반려할 수 있습니다");
        }
    }

    public String status() {
        return status;
    }
}

ArticleState 인터페이스와 상태별 객체(DraftState·ReviewState·PublishedState)로 바꿔, 각 상태가 자기 전이만 알게 만들어 보세요. Article은 현재 상태 객체에게 동작을 위임하고 if 분기가 사라지게 고치면 됩니다. 추가로, 만약 "발행을 예약했다가 취소하는" 기능(되돌리기)을 붙인다면 어떤 행위 패턴이 어울릴지, 코드까지 짜지 않아도 좋으니 한 문단으로 설명해 보세요.

생각해볼 주제

1. 전략 패턴 vs 함수 하나 — 언제 클래스로 만들고 언제 람다로 둘까?

오늘 우리는 전략 패턴을 세 개의 클래스로도, 람다 세 줄로도, Python 함수 딕셔너리로도 표현했다. 기능은 똑같았다. 그렇다면 "전략 = 클래스"라는 공식은 더 이상 맞지 않는 걸까? 어떤 자리에서 굳이 전략을 인터페이스와 클래스로 만들고, 어떤 자리에서 람다 한 줄로 두는 게 옳을까? "패턴의 이름값(공통 어휘)"과 "코드의 간결함"이 부딪힐 때, 무엇을 기준으로 고를지 생각해 보자.

2. 옵저버의 느슨한 결합은 공짜인가?

옵저버는 발행자와 구독자를 느슨하게 떼어 놓는다. 새 구독자를 자유롭게 끼울 수 있어 유연하다. 그런데 그 대가로, 코드만 봐서는 "이 동작이 일어나면 무엇이 연쇄로 반응하는지"가 보이지 않는다. restock 한 줄 뒤에 어떤 일들이 벌어지는지 추적하려면 구독자 목록을 일일이 따라가야 한다. 느슨한 결합이 주는 유연함과, 그것이 앗아 가는 "흐름의 가시성" 사이에서 우리는 무엇을 얻고 무엇을 잃는 걸까? 결합을 느슨하게 할수록 항상 좋은 걸까?

3. 행위 패턴 다수가 함수 하나로 녹는다면, 패턴을 공부하는 의미는?

전략은 람다로, 커맨드는 Runnable로, 옵저버는 리액티브 스트림으로 — 오늘 본 행위 패턴 상당수가 현대 언어에서는 일급 함수나 라이브러리로 모습을 바꾼다. 그렇다면 "GoF 패턴은 함수가 일급이 아니던 시절의 우회로"라는 시각이 맞는 걸까? 만약 그렇다면, 우리가 이 패턴들을 굳이 공부한 의미는 무엇일까? 패턴의 코드 모양이 사라져도 남는 것이 있다면, 그건 무엇일까? C 카테고리 전체를 닫으며, "패턴을 배운다는 것"이 결국 무엇을 손에 남기는 일이었는지 정리해 보자.