디자인 패턴을 배우면 코드가 어떻게 달라질까?

"디자인 패턴을 배우면 코드가 더 짧아지나요?" 이 질문을 받으면 솔직히 말씀드리면, 아니다. 오히려 패턴을 적용하면 코드 줄 수가 늘어나는 경우가 많다. 그러면 뭐가 좋은 걸까?

디자인 패턴은 코드를 짧게 만드는 기술이 아니라, 읽기 쉽고 바꾸기 쉽고 함께 일하기 좋게 만드는 설계 원칙이다. 이 차이가 단기 개발 속도보다 장기 유지보수에서 드러난다.

패턴 없는 코드 vs 전략 패턴 적용 코드

결제 시스템을 예로 들어보자. 신용카드, 카카오페이, 무통장입금 세 가지 결제 수단이 있다. 패턴 없이 짜면 이렇게 된다.

if payment_method == "credit_card":
    # 신용카드 처리
elif payment_method == "kakao_pay":
    # 카카오페이 처리
elif payment_method == "bank_transfer":
    # 무통장 처리

나중에 네이버페이를 추가해야 한다면? elif를 하나 더 추가한다. 애플페이도 추가한다면? 또 추가한다. 이 파일이 커지고 조건이 늘어날수록 수정하기가 두려워진다. 어디를 건드리면 다른 부분이 망가질지 모르기 때문이다.

전략(Strategy) 패턴을 적용하면 각 결제 수단을 독립적인 클래스로 분리한다. 새로운 결제 수단을 추가해도 기존 코드는 건드리지 않는다. 새 클래스를 만들어 붙이면 된다. 이것을 "개방-폐쇄 원칙(Open-Closed Principle)"이라고 한다 — 확장에는 열려 있고, 수정에는 닫혀 있다.

옵저버 패턴이 바꾸는 것: 결합도

유튜브에서 채널을 구독하면 새 영상이 올라올 때 알림이 온다. 이걸 코드로 짤 때 두 가지 방법이 있다.

방법 1: 영상이 올라오면 유튜브가 직접 각 구독자에게 메시지를 보낸다. 구독자가 1억 명이면 1억 번 반복문을 돌린다. 구독자 목록이 변할 때마다 영상 업로드 코드를 수정해야 한다.

방법 2: 옵저버(Observer) 패턴. 영상 업로드 이벤트가 발생하면 "알림 신호"를 발송하고, 이 신호를 구독한 객체들이 알아서 처리한다. 구독자가 늘거나 줄어도 영상 업로드 코드는 변경할 필요가 없다.

패턴 적용 후 변화는 코드 길이가 아니라 결합도(Coupling) 다. 서로 의존하는 코드가 줄어들수록 한 부분을 바꿔도 다른 부분이 무너지지 않는다.

싱글턴 패턴이 주는 명확성

데이터베이스 연결 객체를 코드 여러 곳에서 각자 만들어 쓴다면 어떻게 될까? 연결이 여러 개 생겨 리소스 낭비가 발생하고, 데이터 일관성 문제가 생길 수 있다.

싱글턴(Singleton) 패턴은 "이 클래스의 인스턴스는 딱 하나"를 보장한다. 코드 어디서든 DB 연결 객체를 요청하면 동일한 하나의 인스턴스를 반환한다.

이 패턴이 코드에 주는 것은 명확성이다. "이건 전체에서 하나만 존재한다"는 의도가 코드에 드러난다. 나중에 코드를 읽는 사람이 "왜 이 객체가 여기서 또 생성되지?"라는 혼란 없이 설계 의도를 파악할 수 있다.

패턴이 협업에 주는 가치

혼자 짜는 코드라면 패턴의 효과를 덜 느낄 수도 있다. 하지만 팀으로 일할 때 패턴의 가치는 확실하다.

"이 부분은 옵저버 패턴으로 구현했어"라는 한 마디가 수십 줄의 설명을 대체한다. 패턴 이름이 공통 언어가 된다. 코드 리뷰에서 "여기서 전략 패턴이 더 적합하지 않을까요?"라는 피드백이 명확한 개선 방향을 제시한다.

이 공통 언어를 모르는 팀원과 일하면 소통 비용이 훨씬 올라간다. 같은 설계를 설명하는 데 몇 배의 시간이 필요하다.

패턴 남용의 함정

단, 패턴이 항상 좋은 것은 아니다. 간단한 문제에 복잡한 패턴을 억지로 적용하면 오히려 코드가 복잡해지고 이해하기 어려워진다. 이를 "과도한 엔지니어링(Over-engineering)"이라고 한다.

3개짜리 조건문에 전략 패턴을 적용하거나, 딱 한 번 쓰이는 클래스에 팩토리 패턴을 만드는 것이 그 예다. 패턴은 "이 문제가 반복적으로 커질 것 같다"는 판단이 있을 때 적용하는 것이 적절하다.

정리하면, 디자인 패턴을 배운 후 코드에서 달라지는 것은 줄 수가 아니라 구조다. 변경에 강하고, 읽기 좋고, 팀과 공유하기 쉬운 코드가 패턴 적용의 결과물이다.

자주 묻는 질문

Q. 디자인 패턴을 적용하면 코드 성능도 좋아지나요?

A. 성능보다는 유지보수성과 확장성에 초점이 맞춰져 있습니다. 일부 패턴(예: 플라이웨이트 패턴)은 메모리 사용을 최적화하지만, 일반적으로 패턴 적용이 성능을 직접 개선하지는 않습니다.

Q. 어떤 패턴이 실무에서 가장 자주 사용되나요?

A. 싱글턴(상태 공유 객체), 옵저버(이벤트/알림 시스템), 팩토리(객체 생성 캡슐화), 전략(교체 가능한 알고리즘), 데코레이터(기능 추가)가 웹 개발 실무에서 자주 사용됩니다.

Q. 프레임워크에도 디자인 패턴이 쓰이나요?

A. 네, 광범위하게 사용됩니다. Spring의 DI(의존성 주입)는 팩토리/싱글턴 패턴, React의 이벤트 시스템은 옵저버 패턴, Django의 ORM은 데이터 매퍼 패턴에 기반합니다.

Q. 싱글턴 패턴의 단점은 무엇인가요?

A. 전역 상태를 가지므로 단위 테스트에서 목(Mock) 객체로 교체하기 어렵습니다. 또 멀티스레드 환경에서 동시 접근 시 동기화 처리가 필요합니다. 이 때문에 싱글턴은 신중하게 사용해야 하는 패턴으로 알려져 있습니다.

Q. 디자인 패턴을 알아야 코드 리뷰가 더 잘 되나요?

A. 그렇습니다. 패턴에 대한 공통 이해가 있으면 "여기서 전략 패턴을 고려해보는 게 어떨까요?" 같은 구체적인 피드백이 가능합니다. 패턴이 공통 언어 역할을 해 코드 리뷰의 질이 높아집니다.