피자가게로 이해하는 디자인 패턴

작성일:2026.05.21|조회수:87

피자가게로 이해하는 디자인 패턴

에이든 피자는 처음부터 복잡한 시스템을 만들 생각이 없었다. 처음에는 메뉴 몇 개만 만들면 됐다. 그런데 손님은 커스텀 주문을 넣기 시작했고, 주방은 상태를 나눠야 했고, 결제와 배달앱과 알림이 하나씩 붙었다. 코드도 가게를 닮는다. 장사가 잘될수록 이상하게 더 쉽게 망가진다.

디자인 패턴은 그때 등장한다. 멋진 클래스 다이어그램을 자랑하기 위해서가 아니라, 이미 불편해진 코드를 더 오래 버티게 만들기 위해서다. 이 시리즈는 GoF 패턴을 외우는 목록으로 다루지 않는다. 피자가게 하나가 점점 복잡해지는 과정을 따라가며, 각 패턴이 어떤 불편함 앞에서 필요한 선택이 되는지 살펴본다.

패턴은 정답지가 아니라, 복잡해진 책임을 어디에 둘지 논의하게 해주는 언어다.

이 시리즈가 다루는 것

1편부터 5편까지는 객체를 어떻게 만들 것인가에서 출발한다. 메뉴가 늘어나면 조건문이 길어지고, 옵션이 많아지면 생성자가 지저분해지고, 세트 메뉴가 생기면 서로 맞지 않는 재료 조합을 막아야 한다. Factory Method, Builder, Abstract Factory, Prototype, Singleton은 모두 “생성”이라는 평범한 문제를 조금 다른 각도에서 다룬다.

6편부터 12편까지는 주문이 흐르기 시작한다. 주문서는 취소되고 다시 실행되어야 하고, 토핑은 겹겹이 붙고, 단품과 세트는 같은 방식으로 계산되어야 한다. 조리 순서는 비슷하지만 세부 단계는 다르고, 주문 완료 사실은 여러 곳에 전파되어야 하며, 주문 상태에 따라 가능한 행동도 달라진다. 여기서 Command, Decorator, Composite, Template Method, Observer, Chain of Responsibility, State가 등장한다.

13편부터 23편까지는 가게 바깥의 세계와 부딪힌다. 배달 방식은 런타임에 바뀌고, 직원과 주방과 POS는 직접 얽히면 곤란하며, 외부 배달앱은 저마다 다른 API를 들고 온다. 결제 전에는 검증이 필요하고, 버튼 하나 뒤에는 여러 절차가 숨어 있다. Bridge, Flyweight, Memento, Visitor, Interpreter까지 가면 “패턴을 쓴다”는 말보다 “변경이 들어올 자리를 미리 구분한다”는 감각이 더 중요해진다.

마지막 24편은 앞의 예시들을 실제 애플리케이션 흐름으로 다시 묶는다. 패턴별 샘플 코드는 이해를 위해 일부러 고립되어 있지만, 실제 서비스에서는 주문 생성, 결제, 조리, 알림, 배달이 한 도메인 안에서 함께 움직여야 한다. 그래서 마지막 편은 “각 패턴을 배웠다”에서 끝나지 않고, 그것들을 어디까지 연결하고 어디서 끊어야 하는지 다시 묻는다.

추천 읽기 순서

처음 읽는다면 순서대로 읽는 편이 가장 좋다. 이 시리즈는 단순히 24개의 패턴을 나열한 글이 아니라, 작은 피자가게가 운영 시스템으로 커지는 흐름을 따라가도록 설계되어 있다. 앞에서 생긴 불편함이 뒤에서 다른 형태로 다시 나타나기 때문에, 순서대로 읽으면 패턴 사이의 거리감이 줄어든다.

이미 특정 문제가 있다면 필요한 구간부터 읽어도 된다. 객체 생성이 지저분하다면 1–5편, 주문 처리와 조합이 복잡하다면 6–12편, 외부 시스템과 변경 가능성이 고민이라면 13–23편이 더 직접적이다. 다만 마지막 24편은 가능하면 나중에라도 읽는 편이 좋다. 개별 패턴이 실제 흐름 안으로 들어오면 예제에서 보이지 않던 타협점이 드러나기 때문이다.

이 시리즈를 읽을 때 조심할 점

패턴 이름을 먼저 떠올리면 설계가 쉽게 과해진다. 피자 한 판을 만들 뿐인데 클래스가 줄을 서고, 간단한 옵션 하나를 추가하려다 구조가 먼저 위엄을 갖추는 일이 생긴다. 그런 코드는 겉으로는 객체지향적이지만, 실제로는 읽는 사람에게 일을 떠넘긴다. 이 시리즈가 계속 피자가게라는 작은 도메인에 머무르는 이유도 그 때문이다. 작은 문제에서 과한 구조가 얼마나 빨리 티 나는지 보기 좋다.

좋은 패턴 사용은 이름을 맞히는 일이 아니다. 변경이 어디에서 자주 일어나는지 보고, 그 변경이 다른 책임까지 끌고 가지 않도록 선을 긋는 일에 가깝다. 어떤 편에서는 클래스를 나누는 것이 답이고, 어떤 편에서는 굳이 나누지 않는 것이 더 나은 답이다. 패턴은 그 판단을 대신해주지 않는다. 다만 팀이 같은 문제를 같은 단어로 이야기하게 도와준다.

에이든 피자가 마지막에 얻는 것은 23개의 정답 목록이 아니다. 메뉴, 주문, 주방, 결제, 알림, 배달이 서로를 덜 괴롭히며 움직이게 만드는 감각이다. 그 감각이 남는다면, 디자인 패턴은 외워야 할 면접 질문이 아니라 코드를 고칠 때 꺼내 쓸 수 있는 현실적인 대화 도구가 된다.

댓글

댓글을 불러오는 중...