디자인 패턴은 언제부터 배우는 게 좋을까?

디자인 패턴이라는 말을 처음 들으면 '뭔가 어려운 것'이라는 인상을 받는다. GoF, 싱글턴, 팩토리, 옵저버 같은 영어 용어들이 쏟아지다 보니 그럴 만도 하다. 근데 생각해보면, 디자인 패턴의 본질은 의외로 단순하다.

디자인 패턴은 반복적으로 등장하는 코드 설계 문제를 해결하기 위해 이름을 붙인 검증된 방법들이다. 새로운 기술이 아니라 오래된 경험을 정리한 것이다.

디자인 패턴이 생긴 배경

1994년 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides — 이 네 명을 통칭해 GoF(Gang of Four, 4인방)라고 부른다. 이들이 쓴 책 '디자인 패턴: 재사용성을 지닌 객체지향 소프트웨어의 핵심 요소'가 소프트웨어 개발 역사에서 중요한 위치를 차지한다.

이 책에서 23가지 패턴을 세 가지 범주로 분류했다.

생성(Creational) 패턴은 객체를 어떻게 만들 것인지에 관한 패턴이다. 싱글턴(Singleton), 팩토리 메서드(Factory Method), 추상 팩토리(Abstract Factory) 등이 여기 속한다.

구조(Structural) 패턴은 클래스나 객체를 어떻게 조합할 것인지에 관한 패턴이다. 어댑터(Adapter), 데코레이터(Decorator), 컴포지트(Composite) 등이 대표적이다.

행동(Behavioral) 패턴은 객체 간 책임과 통신 방식에 관한 패턴이다. 옵저버(Observer), 전략(Strategy), 커맨드(Command) 등이 여기 속한다.

언제 배워야 할까?

처음엔 저도 헷갈렸는데요, 전문가들의 공통된 의견은 "코드를 어느 정도 짜봐야 패턴이 왜 필요한지 이해된다"는 것이다.

너무 일찍 — 문법을 막 익힌 입문자 — 배우면 추상적인 개념이 실제 코드와 연결이 안 돼서 결국 암기에 그친다. 패턴의 이름은 알지만 언제 어디서 쓰는지 모르는 상태가 된다.

반면 너무 늦게 배우면 문제가 다르다. 이미 나쁜 코드 습관이 굳어진 상태에서 패턴을 접하면, "맞아, 이걸 이렇게 짜면 됐었구나"라는 깨달음보다 "이게 다 뭔가"라는 피로감이 먼저 온다.

가장 적합한 시점은 간단한 프로젝트를 두세 개 완성한 후, 코드가 복잡해지면서 "이 코드를 더 잘 짤 방법이 없을까?"라는 고민이 생기기 시작할 때다. 이 시점에 패턴을 배우면 "아, 이래서 이 패턴이 있는 거구나"가 와닿는다.

입문자에게 추천하는 패턴 3가지

23개 패턴을 한꺼번에 다 외우려 하면 지친다. 먼저 자주 마주치는 것들부터 시작하는 게 낫다.

싱글턴(Singleton) 패턴은 클래스의 인스턴스를 딱 하나만 만드는 패턴이다. 데이터베이스 연결이나 로그 관리처럼 전체에서 하나만 있어야 하는 객체에 사용한다. 개념이 단순해서 패턴 입문으로 좋다. 다만 남용하면 테스트가 어려워지는 단점이 있다.

옵저버(Observer) 패턴은 특정 객체의 상태가 변할 때 이를 구독한 다른 객체들에게 자동으로 알림을 보내는 패턴이다. SNS 알림, 이벤트 리스너, 실시간 업데이트가 모두 이 패턴이다. JavaScript의 addEventListener가 대표적인 옵저버 구현이다.

전략(Strategy) 패턴은 알고리즘을 교체 가능하게 캡슐화하는 패턴이다. 결제 수단(카드, 현금, 카카오페이 등)을 선택하는 것처럼, 동작 방식을 런타임에 바꿀 수 있다. if-else 지옥을 탈출하는 데 유용하다.

패턴보다 먼저 알아야 할 것들

아, 그리고 한 가지 더 — 디자인 패턴을 배우기 전에 객체지향 프로그래밍(OOP)의 네 가지 핵심 개념을 이해해야 한다.

캡슐화(Encapsulation)는 데이터와 기능을 하나의 단위로 묶고 내부를 숨기는 것이다. 상속(Inheritance)은 부모 클래스의 특성을 자식 클래스가 물려받는 것이다. 다형성(Polymorphism)은 같은 인터페이스를 다양하게 구현할 수 있다는 것이다. 추상화(Abstraction)는 필요한 부분만 드러내고 나머지는 숨기는 것이다.

이 개념들이 체화되어야 디자인 패턴이 왜 그렇게 설계됐는지 이해된다. 패턴은 OOP 위에 세워진 건물이다.

정리하면, 디자인 패턴은 입문 단계가 아니라 "코드가 복잡해졌을 때"의 해결책이다. 간단한 프로젝트 경험 이후, SOLID 원칙과 OOP 개념을 어느 정도 이해한 상태에서 시작하는 것이 가장 효과적이다.

자주 묻는 질문

Q. GoF 디자인 패턴을 전부 외워야 하나요?

A. 외울 필요는 없습니다. 패턴의 이름과 어떤 문제를 해결하기 위한 것인지를 이해하는 것이 중요합니다. 자주 쓰이는 5~7개 패턴을 깊이 이해하는 것이 23개를 얕게 아는 것보다 실용적입니다.

Q. 디자인 패턴 공부에 좋은 교재나 자료는?

A. 'Head First Design Patterns'가 그림과 예시로 쉽게 설명되어 입문서로 많이 추천됩니다. 인프런의 '코딩으로 학습하는 GoF의 디자인 패턴' 강의도 실습 중심으로 좋은 평가를 받습니다.

Q. 프론트엔드 개발자에게도 디자인 패턴이 필요한가요?

A. 필요합니다. 옵저버 패턴(이벤트 처리), 싱글턴 패턴(전역 상태 관리), 전략 패턴(다양한 렌더링 방식) 등이 프론트엔드 코드에서도 자주 사용됩니다. React의 Context API나 Redux도 패턴 기반 설계입니다.

Q. SOLID 원칙과 디자인 패턴의 관계는?

A. SOLID는 객체지향 설계의 5가지 원칙(단일 책임, 개방-폐쇄, 리스코프 치환, 인터페이스 분리, 의존성 역전)이고, 디자인 패턴은 이 원칙들을 실제 코드 구조에 적용한 구체적인 방법입니다. SOLID를 먼저 이해하면 패턴이 왜 그렇게 설계됐는지 자연스럽게 이해됩니다.

Q. 디자인 패턴을 적용하면 코드가 항상 더 좋아지나요?

A. 항상 그런 것은 아닙니다. 간단한 문제에 복잡한 패턴을 억지로 적용하면 오히려 코드가 복잡해집니다. "과도한 엔지니어링"이라고 불리는 이 함정에 주의해야 합니다. 패턴은 필요한 곳에 쓸 때 가치가 있습니다.