왜? 디자인 패턴을 공부해야할까?

서론

개발 공부를 진행하다 보면 디자인 패턴이라는 단어를 많이 볼 수 있다.

나는 항상 왜? 디자인 패턴이라는 것을 알아야 하고, 이것을 공부하면 나의 프로젝트에 어떻게 적용할 수 있는지가 의문이 들었다.

 

싱글톤 패턴, 팩토리 패턴, 프록시 패턴 등 개발 서적에는 항상 등장하고, 시니어 개발자들은 당연하다는 듯이 사용하는 이 용어들. 면접에서도 단골 질문으로 나오지만, 정작 "왜 배워야 하는가?"에 대한 명확한 답을 찾기는 쉽지 않다.

---

디자인 패턴이란?

사진 출처 : https://woovictory.github.io/2019/06/10/DesignPattern-Overview/

 

본격적으로 들어가기 전에, 디자인 패턴이 정확히 무엇인지 짚고 넘어가자.

 

디자인 패턴(Design Pattern)은 소프트웨어 설계 과정에서 반복적으로 발생하는 문제들에 대한 재사용 가능한 해결책이다.

1994년 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides(일명 Gang of Four, GoF)가 출간한 Design Patterns: Elements of Reusable Object-Oriented Software에서 23가지 패턴을 정리하면서 본격적으로 알려지기 시작했다.

 

쉽게 말하면, "이런 상황에서는 이렇게 설계하면 좋더라"는 검증된 설계 템플릿이다.

 

1. 같은 문제를 다시 고민하지 않기 위해

온라인 쇼핑몰을 만든다고 상상해보자.

결제 시스템을 구현하는데, 외부 결제 API(토스 페이먼츠, 카카오페이 등)는 성공했지만 데이터베이스 저장에 실패한다면? 결제된 돈은 어떻게 할 것인가?

 

혹은 대용량 트래픽이 몰리는 이벤트 페이지를 만드는데, 매번 데이터베이스를 조회하면 서버가 터질 것 같다. 캐시를 써야 할까? 그렇다면 캐시 전략은 어떻게 구성해야 할까?

 

이런 문제들은 당신만 겪는 게 아니다. 전 세계 수많은 개발자들이 이미 경험했고, 해결책을 찾아냈다. 그리고 그 해결책을 정리한 것이 바로 디자인 패턴이다.

 

디자인 패턴은 이러한 반복되는 문제 상황에 대한 이미 검증된 베스트 프랙티스를 제공한다. 바퀴를 다시 발명할 필요는 없다. 선배 개발자들이 수십 년간 시행착오를 거쳐 정리한 해결책을 배우고 적용하는 것이 현명하다.

2. 코드가 스파게티가 되는 것을 막기 위해

프로젝트 초기에는 코드가 깔끔하다. "이 정도는 나중에 수정하기 쉬워"라고 생각한다. 하지만 요구사항이 추가되고, 버그를 수정하고, 기능을 변경하면서 코드는 점점 복잡해진다.

 

어느 순간 이런 생각이 든다.

• "이 코드 건드렸다가 다른 곳이 터지면 어쩌지?"
• "새로운 기능 추가하려면 전체를 다시 짜야 하나?"
• "도대체 이 클래스는 뭐 하는 애지?"

이것이 바로 유지보수 불가능한 코드의 특징이다. 일명 스파게티 코드.

 

디자인 패턴은 이런 상황을 예방한다. 각 패턴은 변경에 유연하고, 확장 가능하며, 이해하기 쉬운 구조를 만드는 방법을 제시한다.

단순히 "동작하는 코드"가 아니라 "좋은 구조의 코드"를 만드는 가이드라인인 것이다.

 

6개월 후의 당신이, 혹은 당신의 동료가 코드를 봤을 때 "아, 이렇게 설계했구나"라고 바로 이해할 수 있는 코드. 그것이 디자인 패턴이 추구하는 목표다.

3. 개발자들과 같은 언어로 대화하기 위해

코드 리뷰 시간, 동료가 당신의 코드를 보며 묻는다.

"이 부분 구조가 복잡한데, 어떤 의도로 설계한 건가요?"

 

당신은 10분간 설명을 늘어놓는다. 이 클래스가 저 클래스를 호출하고, 의존성은 이렇게 연결되어 있고...

하지만 만약 이렇게 말할 수 있다면?

"팩토리 패턴을 적용했습니다. 객체 생성 로직을 분리해서 확장성을 높였어요."

 

30초 만에 의도가 명확하게 전달된다.

 

디자인 패턴은 개발자들 사이의 공통 언어다. 패턴 이름 하나로 복잡한 구조와 설계 의도를 표현할 수 있다.

 

마치 의사들이 의학 용어를 사용해 정확하고 빠르게 소통하는 것처럼, 개발자들도 패턴 이름을 통해 효율적으로 의사소통할 수 있다.

 

이는 협업에서, 코드 리뷰에서, 기술 문서 작성에서, 그리고 면접에서 큰 무기가 된다.

4. 사실 이미 사용하고 있다

Spring Boot로 개발한다면, 우리는 이미 디자인 패턴을 사용하고 있다.

• @Service, @Repository 어노테이션 → 싱글톤 패턴
• Spring AOP로 로깅이나 트랜잭션 처리 → 프록시 패턴
• RestTemplate, JdbcTemplate 사용 → 템플릿 메서드 패턴
• 이벤트 리스너로 비동기 처리 → 옵저버 패턴

문제는 이것을 모르고 사용한다는 것이다.

 

자동차를 운전할 수는 있지만, 엔진이 어떻게 작동하는지 모르는 것과 같다. 일상적인 주행은 가능하지만, 문제가 생겼을 때 해결할 수 없고, 더 나은 성능을 끌어낼 수도 없다.

 

디자인 패턴을 공부하면 프레임워크가 "왜 이렇게 동작하는지" 이해하게 된다. 그리고 그 원리를 자신의 코드에도 적용할 수 있게 된다. 더 나아가 프레임워크의 한계를 이해하고, 필요할 때 직접 확장하거나 커스터마이징할 수 있는 능력도 생긴다.

5. 좋은 개발자로 성장하기 위해

주니어 개발자와 시니어 개발자의 차이는 무엇일까?

단순히 코드를 "동작하게" 만드는 것과, "좋은 구조로" 만드는 것의 차이다.

• 주니어: "일단 돌아가게 만들었습니다."
• 시니어: "이렇게 설계하면 나중에 확장하기 쉽습니다."

디자인 패턴은 단순히 코드 작성 기법이 아니다. 소프트웨어 설계 사고방식을 배우는 것이다.

• 이 기능을 어떻게 구조화할까?
• 나중에 변경이 일어날 부분은 어디일까?
• 어떻게 설계해야 테스트하기 쉬울까?
• 이 설계가 SOLID 원칙을 지키고 있나?

이런 질문들에 답하는 능력, 그것이 바로 좋은 개발자의 조건이다. 디자인 패턴은 이러한 설계 사고를 훈련하는 최고의 교재다.

결론

디자인 패턴은 은탄환(Silver Bullet)이 아니다. 모든 문제를 해결해주는 마법의 도구도 아니고, 억지로 모든 코드에 적용해야 하는 것도 아니다.

 

하지만 알고 있으면 다르다.

• 문제 상황에서 더 나은 선택을 할 수 있다.
• 코드의 품질이 달라진다.
• 동료들과의 소통이 원활해진다.
• 프레임워크를 더 깊이 이해할 수 있다.
• 설계에 대한 사고력이 향상된다.

가장 중요한 것은, 이미 검증된 지혜를 배운다는 것이다. 수십 년간 축적된 소프트웨어 엔지니어링의 정수를, GoF를 비롯한 수많은 선배 개발자들의 경험을 흡수할 수 있다.

 

다음 글부터는 실무에서 가장 많이 사용되는 디자인 패턴들을 하나씩 파헤쳐볼 것이다. 이론만이 아닌, 실제로 어떻게 적용하는지, 어떤 상황에서 사용하는지를 중심으로 정리할 예정이다.

 

다음 글 예고: 가장 간단하면서도 가장 오해받는 패턴, 싱글톤 패턴부터 시작한다.