📚 지식 노트

건축가 알렉산더와 『A Pattern Language』

디자인 패턴이라는 말은 소프트웨어가 아니라 건축에서 왔다. 오스트리아 빈에서 태어난 건축가이자 디자인 이론가 크리스토퍼 알렉산더(1936~2022)는 1963년부터 40년 가까이 버클리에서 건축을 가르쳤고, 동료들과 함께 1977년 『A Pattern Language』를 냈다. 이 책은 도시와 동네, 건물, 방을 짓는 데서 되풀이되는 문제와 해법 253개를 하나씩 적은 것이다.

패턴 하나는 세 부분으로 읽을 수 있다. 맥락(어떤 자리에서), 문제(무엇이 거듭 어긋나는가), 해법(그 어긋남을 푸는 배치의 뼈대)이다. 해법은 치수가 정해진 도면이 아니라 뼈대여서, 같은 패턴으로 지은 카페도 동네마다 모양이 다르다. 책은 패턴을 확정된 진리가 아니라 가설로 다루고, 별표 수로 얼마나 확신하는지를 표시했다.

알렉산더는 이 생각을 실제 계획에도 썼다. 오리건 대학교는 그의 패턴 기반 계획 방법(『The Oregon Experiment』, 1975)을 받아들였고, 지금도 그것이 대학의 공식 계획 도구다. 그는 200채가 넘는 건물을 직접 설계하고 시공까지 맡았다.

패턴 언어: 패턴은 혼자 쓰이지 않는다

책의 제목이 "패턴 모음"이 아니라 "패턴 언어"인 까닭은 패턴끼리 이어져 있어서다. 각 패턴은 본문에서 다른 패턴을 괄호 속 번호로 가리킨다. 저자들은 253개 패턴이 모여 하나의 언어를 이룬다고 썼다. 낱말이 문법으로 이어져 문장이 되듯, 큰 패턴이 맥락을 주고 작은 패턴이 그 안을 채운다.

2년 뒤에 나온 『The Timeless Way of Building』(1979)은 이 언어의 철학 편이다. 나중에 나왔지만 사실상 『A Pattern Language』의 서론에 해당한다. 알렉산더는 살아 있는 건물과 동네가 지닌, 한 낱말로 정의할 수 없는 성질을 "이름 없는 특질"(quality without a name)이라 부르고, 여러 낱말로 그 둘레를 그리며 다가간다.

소프트웨어 쪽 패턴에서 이 생각의 두 가지가 그대로 살아남았다. 하나는 이름이 곧 어휘라는 것이다. "여기는 옵저버로 하자"는 한마디가 클래스 그림 한 장을 대신한다. 다른 하나는 패턴끼리의 관계다. GoF 책도 패턴마다 "관련 패턴" 항목을 두어 함께 쓰거나 헷갈리기 쉬운 패턴을 잇는다.

소프트웨어로 건너오다: 1987년 OOPSLA

패턴 언어를 프로그래밍에 처음 옮겨 본 것은 켄트 벡과 워드 커닝엄이다. 두 사람은 1987년 OOPSLA(객체 지향 프로그래밍 학회) 워크숍에 짧은 보고 「Using Pattern Languages for Object-Oriented Programs」를 냈다. Smalltalk로 창 기반 화면을 설계하는 패턴 다섯 개(Window Per Task, Few Panes Per Window, Standard Panes, Short Menus, Nouns and Verbs)를 영향이 큰 것부터 차례로 놓은 작은 언어였다.

보고에 따르면 Smalltalk 화면 구조를 모르는 업무 전문가들이 하루 연습 뒤에 쓸 만한 화면을 설계했다. 저자들은 사용자가 자기 프로그램을 직접 써야 한다는 주장과 함께, 객체 지향 프로그래밍 전체에 대한 더 큰 패턴 언어를 짓는 중이라고 적었다. 커닝엄은 뒤에 첫 위키(WikiWikiWeb)를 만들었는데, 이것도 알렉산더의 패턴 생각에서 직접 영감을 받은 것이다.

GoF와 23가지 패턴

패턴을 프로그래머의 상식으로 만든 것은 1994년 책 『Design Patterns: Elements of Reusable Object-Oriented Software』다. 저자는 에리히 감마, 리처드 헬름, 랄프 존슨, 존 블리시디스 넷이고, 넷을 묶어 GoF(Gang of Four)라 부른다. 1990년 OOPSLA의 자유 모임에서 출발해 1994년 OOPSLA에서 처음 선보였고, 2005년 ACM SIGPLAN 프로그래밍 언어 업적상을 받았다.

책은 패턴 23가지를 목적에 따라 셋으로 나눈다. 생성(5개)은 객체를 만드는 일, 구조(7개)는 클래스와 객체를 엮는 일, 행위(11개)는 객체 사이의 책임과 대화를 다룬다.

아래 표의 "바뀌게 두는 것"은 각 패턴이 변경을 받아 내려고 열어 두는 자리를 이 노트의 말로 적은 것이다. 패턴을 고를 때 가장 쓸모 있는 열이다. 이름을 누르면 그 패턴을 자세히 다룬 글로 간다.

• 생성 패턴: 객체를 누가, 언제, 어떻게 만들지 감춘다.
• 구조 패턴: 클래스와 객체를 엮어 더 큰 구조를 만든다.
• 행위 패턴: 객체 사이의 책임과 대화를 나눈다.

하위 글은 생성 패턴, 구조 패턴 1(어댑터, 브리지, 컴포지트, 데코레이터), 구조 패턴 2(퍼사드, 플라이웨이트, 프록시), 행위 패턴 1(전략, 옵저버, 커맨드, 상태, 템플릿 메서드), 행위 패턴 2(나머지 여섯)로 나뉜다. GoF 이후에 자리 잡은 의존성 주입, 엔터프라이즈 패턴, 동시성 패턴은 GoF 너머에 있다.

패턴 문서는 무엇으로 이뤄지나

알렉산더의 카드가 맥락, 문제, 해법이었다면 GoF는 이것을 프로그래머에게 맞게 더 잘게 나눴다. 패턴마다 같은 항목을 같은 순서로 써서, 처음 보는 패턴도 어디를 읽으면 무엇이 나오는지 안다.

• 의도는 패턴을 한두 문장으로 줄인 것이다. 처음 훑을 때는 의도만 읽어도 후보를 고를 수 있다.
• 동기는 문제가 실제로 터지는 장면 하나를 보여 준다. 패턴이 왜 필요한지 납득이 가는 곳이다.
• 구조와 참여자는 클래스 그림과 역할 이름(예: Subject, Observer)이다. 실제 코드의 클래스 이름은 달라도 역할은 같다.
• 결과는 얻는 것과 치르는 것이다. 간접 층이 하나 늘고, 클래스가 늘고, 흐름을 따라가기 어려워지는 대가가 여기 적힌다.

이 형식이 유일한 표준은 아니다. 패턴을 적는 형식은 여럿이고, 이 사이트의 하위 글도 의도, 구조 그림, 예시 코드, 쓰는 자리, 함정 순으로 줄여 쓴다.

원칙 1: 구현이 아니라 인터페이스에 맞춰 프로그래밍한다

GoF는 1장에서 23가지 패턴 밑에 깔린 원칙 둘을 먼저 꺼낸다. 첫째가 "구현이 아니라 인터페이스에 맞춰 프로그래밍하라"(Program to an interface, not an implementation)다. 변수와 매개변수의 타입을 구체 클래스가 아니라 추상 타입(인터페이스, 추상 클래스)으로 두라는 뜻이다. 그러면 호출하는 쪽은 "무엇을 할 수 있는가"만 알고 "어떻게 하는가"는 모른다.

import java.util.ArrayList;
import java.util.List;

class ReportPrinter {
    // 구현에 맞춤: ArrayList만 받는다. LinkedList나 List.of(...)는 넘길 수 없다
    void printConcrete(ArrayList<String> lines) {
        lines.forEach(System.out::println);
    }

    // 인터페이스에 맞춤: List라는 약속만 지키면 무엇이든 받는다
    void print(List<String> lines) {
        lines.forEach(System.out::println);
    }
}

// 만드는 곳 한 군데만 구체 클래스를 안다
List<String> lines = new ArrayList<>();

구체 클래스 이름은 객체를 만드는 곳 한 군데에만 남는다. 그 한 군데마저 감추려는 것이 생성 패턴(팩터리 메서드, 추상 팩터리)이고, 바깥에서 꽂아 주는 것이 의존성 주입이다. 같은 생각을 모듈 사이로 넓힌 것이 SOLID의 의존성 역전 원칙(DIP)이며, 소프트웨어 공학 노트의 설계 원칙 절에 있다.

다른 언어에서는: Python과 JavaScript는 덕 타이핑이라 타입 이름을 적지 않아도 이미 "그 메서드가 있으면 된다"는 인터페이스에 맞춰 짜는 셈이다. 대신 약속이 코드에 드러나지 않으므로 Python은 typing.Protocol, TypeScript는 interface로 적어 두면 읽는 사람과 검사기가 함께 안다. Go는 인터페이스를 구현한다고 선언하지 않아도 메서드가 맞으면 저절로 만족하므로, 쓰는 쪽 패키지에 작은 인터페이스를 두는 관용구가 흔하다.

원칙 2: 상속보다 객체 합성

둘째 원칙은 "클래스 상속보다 객체 합성을 선호하라"(Favor object composition over class inheritance)다. 상속은 부모의 구현을 그대로 물려받아 빠르지만, 부모와 자식이 컴파일 때 단단히 묶인다. 합성은 다른 객체를 필드로 들고 일을 넘기는 것이라, 무엇을 들지 실행 중에 바꿀 수 있다.

상속의 약점이 가장 크게 드러나는 곳은 기능이 여러 축으로 갈릴 때다. 알림을 메일, 문자, 푸시로 보내는데 암호화, 재시도, 기록을 저마다 켜고 끌 수 있다고 하자. 조합마다 하위 클래스를 만들면 24개가 필요하다. 축을 나눠 부품으로 두면 6개다.

// 상속: 조합마다 하위 클래스가 하나씩 생긴다
class MailNotifier extends Notifier { ... }
class EncryptedMailNotifier extends MailNotifier { ... }
class RetryingEncryptedMailNotifier extends EncryptedMailNotifier { ... }
// ... 채널 3개 × 부가 기능 3개를 켜고 끄는 조합이면 24개

interface Channel {
    void send(String to, String text);
}

final class MailChannel implements Channel {
    public void send(String to, String text) { /* SMTP로 보낸다 */ }
}

// 부가 기능은 Channel을 감싸는 Channel이다(데코레이터)
final class Encrypting implements Channel {
    private final Channel inner;

    Encrypting(Channel inner) {
        this.inner = inner;
    }

    public void send(String to, String text) {
        inner.send(to, encrypt(text));
    }

    private String encrypt(String text) { /* 생략 */ return text; }
}

final class Notifier {
    private final Channel channel;

    Notifier(Channel channel) {
        this.channel = channel;
    }

    void alert(String to, String text) {
        channel.send(to, text);
    }
}

// 조합은 클래스가 아니라 조립으로 만든다
Notifier notifier = new Notifier(new Retrying(new Encrypting(new MailChannel())));

부가 기능을 같은 인터페이스로 감싸는 이 모양이 데코레이터이고, 채널을 갈아 끼우는 부분은 전략과 같은 생각이다. 합성에도 값이 있다. 감싸는 쪽이 안쪽 메서드마다 넘기는 코드를 손으로 써야 하고, 객체가 여러 겹이면 디버거로 따라가기가 번거롭다. GoF도 상속과 합성은 보통 함께 쓰인다고 말한다. "상속 금지"가 아니라 "먼저 합성을 떠올려 보라"는 뜻이다.

다른 언어에서는: 넘기는 코드를 줄여 주는 문법이 있다. Kotlin은 class Logged(inner: Channel) : Channel by inner처럼 by로 위임을 한 줄에 쓰고, Go는 구조체에 다른 타입을 이름 없이 넣는 임베딩으로 메서드를 올려 쓴다. Python은 데코레이터 문법(@)이 함수 감싸기를 언어로 지원한다.

클래스 패턴과 객체 패턴

GoF는 분류 말고도 패턴을 범위로 한 번 더 나눈다. 클래스 패턴은 관계를 상속으로 맺어 컴파일 때 정해지고, 객체 패턴은 합성으로 맺어 실행 중에 바뀔 수 있다. 23가지 가운데 클래스 범위는 팩터리 메서드, 어댑터, 인터프리터, 템플릿 메서드뿐이고 나머지는 모두 객체 범위다. 둘째 원칙이 패턴 목록에도 그대로 드러난 셈이다.

import java.nio.charset.StandardCharsets;

interface Printer {
    void print(String text);
}

class LegacyPrinter {
    void printBytes(byte[] data) { /* 오래된 드라이버 */ }
}

// 클래스 어댑터: LegacyPrinter를 상속해 붙는다
class ClassAdapter extends LegacyPrinter implements Printer {
    public void print(String text) {
        printBytes(text.getBytes(StandardCharsets.UTF_8));
    }
}

// 객체 어댑터: LegacyPrinter 객체를 감싸고 호출을 넘긴다
class ObjectAdapter implements Printer {
    private final LegacyPrinter legacy;

    ObjectAdapter(LegacyPrinter legacy) {
        this.legacy = legacy;
    }

    public void print(String text) {
        legacy.printBytes(text.getBytes(StandardCharsets.UTF_8));
    }
}

• 클래스 어댑터는 넘기는 코드가 짧고 부모의 protected 멤버도 쓸 수 있다. 대신 LegacyPrinter의 하위 클래스가 있어도 그것까지 맞춰 주지는 못하고, 다중 상속이 없는 Java에서는 맞출 쪽(Printer)이 인터페이스여야 한다.
• 객체 어댑터는 생성자로 받은 어떤 LegacyPrinter든, 그 하위 클래스 객체든 감쌀 수 있다. 실무에서 보는 어댑터는 대개 이쪽이다.
• 템플릿 메서드와 팩터리 메서드가 클래스 패턴인 것도 같은 이유다. 둘 다 "하위 클래스가 빈칸을 채운다"는 상속의 구조 자체가 패턴이다.

패턴은 언제 쓰나: 문제에서 출발한다

패턴은 목록에서 고르는 것이 아니라 증상에서 거꾸로 찾아가는 것이다. 같은 분기가 여러 곳에 퍼졌다, 새 종류를 더할 때마다 기존 코드를 고친다, 테스트에서 가짜를 꽂을 수 없다 같은 아픔이 먼저 있고, 패턴은 그 아픔에 붙은 이름이다. 아래는 증상 하나에서 출발해 질문 넷으로 패턴에 닿는 과정이다.

• 무엇이 바뀌나가 가장 중요한 질문이다. 위 표의 "바뀌게 두는 것" 열이 이 질문의 답을 패턴별로 모아 둔 것이다.
• 지금 아픈가, 아플 것 같은가를 구분한다. 이미 두 번 겪은 변경이면 패턴으로 받아 둘 값이 있고, 상상 속의 변경이면 대개 오지 않는다(YAGNI).
• 처음부터 패턴으로 설계하기보다 단순하게 짠 뒤 리팩터링으로 패턴 쪽으로 옮겨 가는 편이 보통 결과가 좋다. 패턴 모양이 코드에서 자라나도록 둔다.

남용: 패턴병과 쓸데없는 추상

패턴을 막 배운 사람이 가장 흔히 걸리는 병은 모든 것을 패턴으로 짜는 것이다. 구현이 하나뿐인 인터페이스, 한 곳에서만 쓰는 팩터리, 무엇도 바꾸지 않는 전략이 쌓이면 코드는 유연해지는 것이 아니라 읽을 곳만 늘어난다. 패턴은 간접 층을 하나 더하는 일이고, 간접 층은 공짜가 아니다. 잘못 쓴 패턴은 쓸데없는 복잡도를 더하고, 덧붙은 간접 호출 때문에 실행 속도가 떨어지기도 한다.

• 싱글턴 남용: 전역 변수에 이름을 붙인 것이 되기 쉽다. 숨은 의존이 생기고 테스트끼리 상태를 나눠 쓴다. 감마는 2009년 인터뷰에서 책을 다시 쓴다면 싱글턴을 빼고 싶다고 했다(다른 저자들은 동의하지 않았다).
• 이름만 패턴: 클래스 이름에 Factory, Manager, Strategy를 붙였다고 패턴이 되지 않는다. 역할과 바뀌는 자리가 맞아야 한다.
• 패턴을 위한 패턴: 면접이나 코드 리뷰에서 "패턴을 썼다"는 것이 목표가 되면, 문제가 없는 곳에 해법이 생긴다.

비판과 의의: 언어가 패턴을 지운다

가장 널리 인용되는 비판은 피터 노빅의 1996년 5월 Object World 발표 「Design Patterns in Dynamic Programming」이다. 노빅은 GoF 책을 살펴 Dylan이나 Lisp에서는 23개 가운데 16개가 보이지 않거나(언어의 일부가 되어 의식하지 못함) 더 단순해진다고 정리했다. 모든 쓰임이 아니라 적어도 일부 쓰임에서 질적으로 단순해진다는 주장이다.

예를 들어 함수를 값으로 넘길 수 있으면 전략과 커맨드는 클래스 계층 없이 함수 하나가 된다. 클래스 자체를 값으로 넘길 수 있으면 추상 팩터리와 팩터리 메서드가 단순해진다. 여기서 나오는 교훈은 패턴의 일부가 언어에 없는 기능을 메우는 우회로라는 것이다. 폴 그레이엄도 자기 프로그램에 패턴이 보이면 문제의 신호로 여긴다고 썼다. AspectJ로 23가지를 구현해 보니 17개에서 코드 수준의 의존이 사라졌다는 연구(Hannemann, Kiczales)도 같은 방향이다.

그래도 패턴은 낡지 않았다. 구현이 언어 기능 한 줄로 줄어도 문제와 이름은 남는다. Java 람다로 짠 정렬 기준도 여전히 전략이고, 팀이 "그건 전략으로 빼자"고 말할 수 있는 어휘가 GoF의 가장 큰 유산이다. 언어가 바뀌면 구현은 바뀌고, 문제를 보는 눈은 남는다.

안티패턴: 흔하지만 해로운 해법

안티패턴(anti-pattern)이라는 말은 앤드루 코닉이 1995년 『Journal of Object-Oriented Programming』에 쓴 글 「Patterns and Antipatterns」에서 처음 썼고, GoF 책에서 영감을 받은 것이다. 안티패턴은 그냥 나쁜 습관과 두 가지로 구분된다. 흔히 쓰이고 처음에는 알맞아 보이지만 손해가 이득보다 크고, 효과가 검증된 다른 해법이 문서로 있다는 것이다. 1998년 책 『AntiPatterns』(Brown, Malveau, McCormick, Mowbray)가 이 생각을 아키텍처와 프로젝트 관리까지 넓혀 퍼뜨렸다.

• 갓 오브젝트(god object): 서로 관계없는 메서드를 잔뜩 가지고 수많은 타입에 기대는, 지나치게 크고 힘센 객체다. 무엇을 고쳐도 이 클래스를 건드리게 된다. 책임별로 쪼개는 것이 처방이다.
• 스파게티 코드: 제어 흐름이 구조 없이 이리저리 뛰는 코드다. goto를 마구 쓰던 시절의 이름이지만, 콜백과 이벤트가 얽힌 지금 코드에도 그대로 생긴다. 구조적 프로그래밍이 이것을 막으려고 나왔다.
• 골든 해머(golden hammer): 익숙한 기술 하나를 모든 문제에 들이대는 것이다. 1966년 매슬로가 쓴 "가진 도구가 망치뿐이면 모든 것을 못처럼 다루고 싶어진다"는 말에서 왔다. 패턴을 막 배운 뒤의 패턴병도 이것의 한 갈래다.
• 큰 진흙 공(big ball of mud): 알아볼 만한 구조가 없는 시스템이다. 마감, 사람의 교체, 오랜 땜질이 쌓여 생긴다.

공부하는 법

23가지를 차례로 외우면 금방 잊는다. 패턴은 겪어 본 문제에 붙을 때 남는다. 아래 고리를 패턴 하나씩 돈다.

• 자주 쓰는 것부터: 전략, 옵저버, 데코레이터, 어댑터, 팩터리 메서드, 템플릿 메서드는 거의 모든 코드베이스에 있다. 인터프리터나 플라이웨이트는 필요한 날 찾아봐도 된다.
• 이미 쓰는 라이브러리에서 찾는다: Java의 Comparator는 전략, Iterator는 이터레이터, 입출력 스트림을 겹겹이 감싸는 것은 데코레이터, 브라우저의 addEventListener는 옵저버다. 아는 코드에 이름을 붙이면 빨리 익는다.
• 그림을 손으로 그린다: 역할(인터페이스, 구현, 클라이언트)과 화살표 방향을 직접 그려 보면, 어느 쪽이 어느 쪽을 모르는지가 보인다. 패턴의 핵심은 대개 그 "모름"이다.
• 패턴 없이 먼저 짜 본다: 분기로 짠 코드에 기능을 하나 더해 보고, 같은 일을 패턴으로 다시 해 본다. 어느 쪽이 더 고치기 쉬운지 몸으로 느끼면 남용도 덜 한다.
• 다른 언어로 짜 본다: 같은 패턴을 Java와 Python, Go로 짜 보면 무엇이 문제 자체이고 무엇이 언어의 빈칸을 메운 것인지 갈린다.

흔한 오해

• "디자인 패턴은 GoF가 만들었다" — 패턴이라는 생각은 알렉산더의 건축에서 왔고, 소프트웨어로는 1987년 벡과 커닝엄이 먼저 옮겼다. GoF는 그것을 23가지로 정리해 널리 퍼뜨렸다.
• "패턴은 복사해 쓰는 코드다" — 패턴은 해법의 뼈대와 이름이다. 같은 패턴도 언어와 상황에 따라 코드가 전혀 다르게 나온다.
• "패턴을 많이 쓸수록 좋은 설계다" — 패턴마다 간접 층과 클래스가 는다. 바뀌지 않는 곳에 쓴 패턴은 비용만 남긴다.
• "상속은 나쁘고 합성은 좋다" — GoF의 말은 "먼저 합성을 떠올려 보라"이지 상속 금지가 아니다. 진짜 "is-a" 관계이고 축이 하나뿐이면 상속이 더 간단하다.
• "함수형 언어에는 패턴이 없다" — 일부 패턴이 언어 기능으로 줄어들 뿐, 문제는 남고 그 언어만의 패턴(고차 함수 조합, 모나드 등)이 새로 생긴다.
• "안티패턴은 그냥 나쁜 코드다" — 안티패턴은 흔히 쓰이고 그럴듯해 보인다는 점, 그리고 검증된 대안이 있다는 점이 핵심이다. 그래서 이름을 붙여 알아보게 하는 것이다.

핵심 자료

요지는 직접 정리한 한 줄이다.