[ Programming > Design Pattern ]
[디자인 패턴] 빌더 패턴
빌더 패턴(Builder Pattern)
빌더 패턴은 복잡하게 여러 단계로 나눠는 객체 생성 과정을 캡슐화하고 싶을때 쓰는 생성 패턴이에요. 객체 생성 로직이 복잡한 경우나 동일한 구조에서 서로 다른 설정으로 객체를 만들고 싶은 경우 유용해요. SQL을 코드로 작성하는 경우, 프론트엔드는 zod라는 타입 검증을 만드는 라이브러리에서 많이 사용되요.
빌더 패턴 구조 (Director 사용하는 빌더패턴)

Director 방식을 사용하는 빌더 패턴은 복잡한 생성 과정을 제어하는 Director, 제품 생성에 필요한 방법을 추상화한 인터페이스인 Builder, Builder 인터페이스를 구현한 ConcreteBuilder, 그리고 결과물인 Product로 구성되요.
Director
역할: Builder를 사용해서 객체 생성 순서와 과정을 제어하는 역할이에요. Client 대신 복잡한 생성 로직을 관리해요.
특징: 어떤 ConcreteBuilder가 사용될지 모르지만, Builder 인터페이스만 알고 있으면 일관된 방식으로 객체를 만들 수 있어요.
예시: 건축 감독 → 어떤 집을 짓든 "기초 → 골조 → 벽 → 지붕" 순서로 지시해요.
Builder
역할: 복잡한 객체를 생성하는데 필요한 단계들을 추상 메서드로 정의하는 인터페이스에요.
특징: Product를 만드는 최소 기준을 정의하고, ConcreteBuilder들이 따라야 할 공통 API를 제공해요.
예시: 집 짓기 설계도 → buildFoundation(), buildWalls(), buildRoof() 등의 단계를 정의해요.
ConcreteBuilder
역할: Builder 인터페이스를 실제로 구현하여 특정 타입의 Product를 만드는 클래스에요.
특징: Director를 몰라도 Builder 인터페이스만 알고 구현하면 되요. 각 단계에서 자신만의 방식으로 Product를 조립해요.
예시: 목조주택 빌더, 콘크리트 빌더 등 → 같은 단계지만 재료와 방식이 달라요.
Product
역할: 빌더를 통해 최종적으로 만들어지는 복잡한 객체에요.
특징: 여러 부품과 속성으로 구성되어 있으며, 한번에 만들기 어려운 복잡한 구조를 가져요. ConcreteBuilder마다 다른 타입의 Product가 만들어질 수 있어요.
예시: 완성된 집 → 기초, 벽, 지붕 등 여러 부분이 조립된 최종 결과물이에요.
다양한 빌더 패턴
상황 | 방법 | 이유 |
|---|---|---|
순서가 복잡하고 여러 변형이 있는 경우 | Director | 생성 로직을 재사용 가능 |
순서는 중요하지만 유연성도 필요한 경우 | Builder 내부 검증 | 자유롭게 사용하되 안전하게 |
순서를 절대적으로 강제해야 하는 경우 | Step Builder | 컴파일 타임에 순서 보장 |
순서가 중요하지 않은 경우 | 일반 Builder | 컴퓨터 조립처럼 순서 무관 |
순서는 정해져 있지만 호출은 자유롭게 하고 싶은 경우 | 명령 큐잉 (지연 실행) | 명령 저장 후 build()에서 최적화 |
예시 - 빌더 패턴
작성중...
마무리
작성중...

