『Design Patterns』를 다시 읽을 때 중요한 것은 23개 암기가 아니라 공통 언어다
소프트웨어 설계 책 가운데 오래 살아남는 책은 많지 않다. 그중에서도 1994년에 나온 Design Patterns: Elements of Reusable Object-Oriented Software는 지금도 자주 거론된다. 저자인 에리히 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시디스(John Vlissides)는 이 책 이후 흔히 Gang of Four, 줄여서 GoF라고 불리게 됐다.
이 책의 가장 큰 가치는 “23개 패턴을 외우게 했다”는 데 있지 않다. 더 중요한 변화는, 반복되는 설계 문제에 표준적인 이름을 붙이고 장단점을 함께 토론할 수 있게 만들었다는 점이다.
디자인 패턴은 원래 소프트웨어에서 시작된 말이 아니다
패턴이라는 발상은 건축가 크리스토퍼 알렉산더(Christopher Alexander)의 A Pattern Language에서 널리 알려졌다. 알렉산더는 반복되는 환경 문제와 그에 대한 해법을 패턴이라는 단위로 정리하려 했다. 소프트웨어 쪽의 GoF 책은 이 발상을 객체지향 설계 문제로 옮겨온 셈이다.
이 연결이 중요한 이유는 분명하다. 패턴은 “멋진 구조를 전시하는 장식”이 아니라, 자주 반복되는 문제를 더 짧고 정확하게 대화하기 위한 도구라는 뜻이기 때문이다.
GoF 책이 남긴 진짜 유산은 “이름”이다
Pearson의 책 소개도 이 책을 “자주 발생하는 설계 문제에 대한 간결한 해법의 카탈로그”로 설명한다. 실제로 이 책이 크게 퍼진 이유는 패턴 자체보다 이름 붙이기에 있었다.
예를 들어 팀원이 “여기는 생성 책임을 분리해야 하니 팩토리 메서드 쪽이 낫겠다”거나 “이건 옵서버 성격이 강하다”고 말할 수 있으면, 긴 설명 없이도 설계 의도를 압축해서 전달할 수 있다. 이름이 붙으면 비교와 반박도 쉬워진다. “싱글턴으로 하자”가 아니라 “정말 전역 단일 인스턴스가 필요한가”를 묻기 시작할 수 있기 때문이다.
즉 패턴의 핵심은 암기보다 의사소통이다.
하지만 패턴은 만능 해법이 아니다
GoF 책을 처음 읽는 사람들이 흔히 빠지는 오해도 있다. 패턴을 많이 쓰면 설계가 자동으로 좋아진다고 생각하는 것이다. 실제로는 반대인 경우도 많다.
- 문제보다 패턴 이름이 먼저 떠오르면 불필요한 추상화가 늘어난다.
- 싱글턴, 팩토리, 옵서버를 습관적으로 붙이면 코드가 더 복잡해질 수 있다.
- 작은 프로그램에서는 단순한 함수와 데이터 구조가 더 나은 선택일 때가 많다.
그래서 이 책은 정답집보다는 어휘집에 가깝게 읽는 편이 좋다. 패턴을 적용하기 전에 “지금 이 문제에 정말 반복되는 구조가 있는가”, “장점만큼 비용도 감수할 가치가 있는가”를 먼저 봐야 한다.
지금 읽는다면 이렇게 읽는 편이 낫다
지금 시점에서 GoF 책을 가장 실용적으로 읽는 방법은 세 단계 정도로 정리할 수 있다.
- 먼저 서문과 패턴 소개 방식을 읽고, 패턴이 어떤 형식으로 설명되는지 익힌다.
- 그다음 모든 패턴을 외우려 하기보다 생성, 구조, 행위 패턴에서 자주 부딪히는 몇 개만 골라 읽는다.
- 마지막으로 자기 코드나 오픈소스 프로젝트를 보며 “이 구조가 왜 생겼는가”를 역으로 찾아본다.
이렇게 읽으면 패턴을 장식처럼 붙이는 습관보다, 설계 선택의 이유를 설명하는 습관이 먼저 자리 잡는다.
핵심 정리
Design Patterns가 오래 살아남은 이유는 23개의 기법을 소개했기 때문만이 아니다. 반복되는 설계 문제를 표준적인 이름과 형식으로 정리해, 개발자들이 같은 문제를 더 짧고 정확하게 토론할 수 있게 했기 때문이다.
그래서 이 책을 오늘 다시 읽을 때 중요한 것은 “패턴을 얼마나 많이 외웠는가”가 아니라, 어떤 문제를 어떤 언어로 설명할 수 있게 되었는가다. 패턴은 정답이 아니라 대화의 압축 형식이다. 그 점을 기억하면 이 고전은 지금도 충분히 쓸모가 있다.