진짜 빌더가 더 좋다고 생각하시나요? 정말인가요?

이 글은 빌더 vs 생성자에 대한 저의 견해입니다. (다른 의견이 있다면 댓글로 주시면 감사드리겠습니다!)
사람들을 보면 빌더와 생성자의 본질의 차이점도 모른채 빌더를 사용하고는 합니다.
하지만 이 글을 통해 이에 대해 알고 사용할 수 있다면 좋겠습니다.

안녕하세요 오늘은 다들 익숙하게 쓰고 있는 빌더 패턴에 대해 이야기 해보고자합니다.

빌더는 객체를 생성할 때 사용하는데요. 생성자 방식을 사용하지 않고 왜 빌더 패턴을 사용할까요?
빌더 패턴을 블로그에 검색하다보면 빌더패턴에 대한 여러 장점이 나오는데요. 해당 주장은 다음과 같습니다.

1. 가독성이 좋아 휴먼에러의 가능성이 낮아진다.

2. 유연성이 높다.

위의 내용들에 대해서 반박할 여지는 반박해보며 글을 작성해보겠습니다.

가독성이 좋고, 휴먼 에러의 가능성이 높아진다.

이 말이 나온 배경에 대해 설명하겠습니다.
생성자 방식은 객체를 생성할 때 가독성이 좋지 않았습니다

LocalDateTime date = LocalDateTime.of(2025, 5, 13, 10, 0); // 2025년 5월 13일 10시 0분

주석이 없다면 여러분들은 위 내용을 이해하기 쉽지 않았을 것입니다.
이는 언뜻 보기에 매우 타당한 주장입니다. 하지만 저는 현대에는 이 주장의 타당성은 약해지지 않았나 생각합니다.
이유는 다음과 같습니다.

여러분들은 가독성이 나빠보이시나요?
현대의 개발은 대부분 IntelliJ를 대부분 사용합니다.
IntelliJ는 매개변수 힌트를 제공하므로 생성자 방식도 충분히 가독성이 좋습니다.

생성자 방식이 가독성이 떨어진다는 의견은 분명 과거에는 맞지만 적어도 Intellij의 환경을 대부분 사용하기 때문에 이제 이러한 의견은 조금 힘을 싣기엔 어렵지 않나라고 생각합니다.
intellij를 쓰지 않는다면 빌더패턴을 애초부터 잘 사용하지 않을 것이라고 생각합니다.
만약 힌트를 제공하지 않는 ide라면 이 주장이 타당성이 있을 것입니다!

---

그렇다면 빌더와 생성자의 본질의 차이는 뭘까

제가 보는 빌더와 생성자를 구분하는 본질은 2번입니다.

유연성이 높다.

빌더를 사용하지 않고 생성자만 사용한다고 가정을 해보겠습니다.

자바는 컴파일 타임 제약이 강한 언어입니다.
컴파일 타임 타입 검사가 매우 엄격합니다. 변수 선언할 때 반드시 타입을 명시해야 하고, 타입이 맞지 않으면 컴파일 자체가 안 됩니다.
메서드 시그니처 고정도 엄격합니다.
메서드 호출 시 매개변수 개수, 순서, 타입이 정확히 일치해야 합니다. 파이썬처럼 func(a=1, b=2) 식으로 키워드 인수를 쓸 수도 없고, 자바스크립트처럼 매개변수를 마음대로 생략할 수도 없습니다.

즉, 객체 생성 방식의 제약이 강합니다. 생성자를 통해서만 객체를 만들 수 있고, 생성자에 정의된 매개변수를 정확한 순서와 타입으로 모두 전달해야 합니다.
이런 엄격함 때문에 생성자도 매개변수 순서 바뀌면 안 되고, 타입 틀리면 안 되고, 개수 맞지 않으면 안 되는 특성을 가지는 거죠.
반면 빌더 패턴은 이런 자바의 엄격함 속에서도 유연성을 제공하는 우아한 해결책인 셈입니다. 메서드 체이닝으로 순서도 자유롭고, 선택적 매개변수도 처리할 수 있으니까요.

생성자의 단점

특정 필드를 생략하고 싶을 때의 복잡해지게 됩니다.

// 중간 매개변수를 건너뛸 수 없음
public User(String name, String email, String phone, String address) { }

// address만 설정하고 phone은 생략하고 싶다면?
// -> 새로운 생성자 필요

하지만 유연한 빌더도 분명 단점이 있습니다.

빌더의 단점

// 실수로 필수 필드를 빼먹을 수 있음
User user = User.builder()
    .email("test@test.com")
    // name을 깜빡함!
    .build();

필드를 빼먹어도 컴파일 시점에 이를 체크할 수 없게 됩니다.

---

결론으론 빌더와 생성자 무엇을 사용할 것인가?

결국 핵심은 요구사항에 맞게 제약을 강하게 걸지, 유연성을 챙길지 결정하는 것입니다.

제약이 필요한 경우 (생성자 선택)

• 객체의 필수 속성이 명확하고 변하지 않을 때
• 컴파일 시점에 오류를 잡고 싶을 때
• 팀의 실수를 방지하고 싶을 때

유연성이 필요한 경우 (빌더 선택)

• 요구사항이 자주 변경될 것으로 예상될 때
• 다양한 조합의 객체 생성이 필요할 때

---

글을 마무리하며

물론 결국에는 팀과의 논의를 거쳐 하나의 컨벤션을 맞추는 것도 중요합니다.
만약에 협의를 하게 된다면 위의 사항을 잘 고려해 선택하는게 중요할 것이라고 생각합니다.

추가로 만약 테스트를 잘 짠다면 빌더의 유연함을 챙기면서도 테스트 시점에 누락된 필드의 버그를 찾을 수 있기 때문에 테스트를 잘 짜는 조직이라면 빌더에 손을 들어줄 수 있을 것 같습니다
오늘 글은 여기서 마무리 하겠습니다
감사합니다 :)