어떤 설계 문제가 존재하는가?

• 클라이언트 코드가 구체적인 클래스 생성 로직에 강하게 결합됨
• 서비스가 커지면서 다양한 버튼 스타일, 모달 유형, 알림 배너처럼 서로 비슷하지만 살짝씩 다른 UI 컴포넌트 / 여러 컨텍스트 전용 훅을 만들어야 하는 상황
• 컴포넌트마다 조건 분기가 늘고 훅 구현을 복사해 붙여 쓰게 되면서, 생성·초기화 로직이 여기저기 흩어지고 변경에 취약한 구조가 됨

팩토리 메서드 패턴

• 특정 UI 컴포넌트나 훅을 어떻게 생성할지에 대한 로직을 서브 클래스(or 함수 팩토리)에 숨겨 두고, 클라이언트는 “어떤 종류를 쓸지”만 선택해서 컴포넌트/훅을 가져다 쓰게 만드는 패턴
• 버튼 / 모달 / 알림 같은 공통 인터페이스나 공통 props 형태는 유지하되, 실제로 어떤 스타일, 동작을 가진 구현을 만들지는 각 서브 팩토리(혹은 매핑 함수, 훅 팩토리)가 책임
• 클라이언트 코드는 “어떤 팩토리(혹은 타입)를 선택할지”만 결정하고, 구체적인 생성 방식은 팩토리가 알아서 처리하므로 생성 세부 사항에 대한 의존성이 줄어듦

// 공통 로직을 안에 숨긴 함수 팩토리
const makeToastHook = (type: "success" | "error") => {
  return () => {
    const showToast = (msg: string) => {
      // type에 따라 색, 아이콘, 위치 등 결정
      // ...
      console.log(`[${type.toUpperCase()}] ${msg}`);
    };

    return { showToast };
  };
};

// 클라이언트 코드
// success나 error만 넘겨주고, 내부 처리방식은 몰라도 됨
const useSuccessToast = makeToastHook("success");
const useErrorToast = makeToastHook("error");

// 팩토리 역할: 안전한 useContext 훅을 만들어줌
const makeSafeUseContext = <T,>(Context: Context<T | null>, name: string) => {
  return () => {

팩토리 메서드 패턴 특징

• 컴포넌트나 훅을 만드는 과정을 한 곳에 모아두기 때문에, 버튼 타입이 늘어나거나 새로운 훅 변형이 추가되어도 클라이언트 코드는 동일한 인터페이스로 사용 가능
• UI 스타일, 검증 규칙, 에러 처리 방식처럼 생성 시점에 달라질 수 있는 부분을 팩토리에서 갈아끼우도록 설계
  • prop이나 옵션만 바꿔도 다른 구현을 쉽게 끼워 넣을 수 있어 유연성과 재사용성 높아짐
• 디자인 시스템용 버튼/폼/모달 컴포넌트, 훅 팩토리처럼, 팀이나 외부 사용자에게 확장 가능한 API를 제공해야 할 때 특히 잘 맞는 패턴

팩토리 메서드 장단점

장점

• 컴포넌트나 훅을 어디서 어떻게 생성할지 한 곳(팩토리)에 모아두면, 생성 로직을 일관되게 관리할 수 있어 수정이나 리팩토링이 수월
• 생성하는 쪽(팩토리)과 사용하는 쪽(클라이언트)을 분리하므로, 클라이언트는 구체 컴포넌트/훅 구현을 몰라도 되고, 의존성이 낮아짐
• 버튼/모달/훅 생성 규칙이 중앙 집중화되기 때문에, 디자인 시스템이나 공통 훅 세트를 관리할 때 변경 범위를 최소화

단점

• 추상 팩토리, 서브 팩토리, 매핑 객체 등 추가 코드가 필요해 구조가 복잡해 보일 수 있고, 작은 규모의 UI에는 오히려 과한 설계
• 생성해야 할 변형(버튼 타입, 모달 종류, 훅 버전)이 많아질수록 팩토리 매핑이나 서브 구현이 계속 늘어나 관리 포인트가 많아짐
• 한 번 더 함수를 거쳐 생성하는 구조라 호출 계층이 깊어지고, 패턴 자체를 이해해야 해서 초기 학습 비용과 미세한 성능 오버헤드를 감수해야 함
  • 조금만 고민하면 그래도 나도 모르게 사용한 곳들이 많을 것 같음
  • 그만큼 익숙한 부분에서는 학습 비용이 높지 않을 것이라 생각함

언제 이 해결 방법을 적용해야 하는가?

• 디자인 시스템에서 버튼, 모달, 배너처럼 변형 타입이 계속 늘어날 것 같은 컴포넌트를 만들 때, 새 타입이 추가되어도 동일한 인터페이스로 사용할 수 있게 하고 싶을 때
• 공통 컴포넌트/훅 라이브러리를 만들면서, 외부나 다른 팀이 자신들만의 구현(커스텀 Button, Form, Hook 등)을 주입해서 확장할 수 있는 포인트를 제공해야 할 때
• 로직은 거의 같은데 검증 규칙, 에러 처리, 로깅 방식처럼 일부만 다른 훅들을 여러 개 만드는 상황
  • 규칙이나 정책을 인자로 받는 훅 팩토리로 중복을 줄이고 싶을 때
• UserContext, ThemeContext, AuthContext 등 여러 Context에 대해 동일한 에러 처리·디버깅 메시지 패턴을 적용하고 싶어서, 공통 팩토리로 안전한 전용 훅을 생성할 때

나만의 사용 방식

• 로깅 유틸 함수를 하나의 팩토리처럼 만들어 사용
  • 내부에서 로그 레벨(info, warn, error)에 따라 콘솔 색상이나 출력 형식을 다르게 처리
  • warn, error 레벨에서만 Sentry로 전송하도록 분기
• 여러 Context를 감싸 공통 정책을 가진 전용 훅으로 래핑
  • Provider 밖에서 사용되었을 때 공통 에러 메시지를 던지도록 해서, 디버깅 시 일관된 피드백을 제공

    const makeSafeUseContext = <T,>(
      Context: React.Context<T |

적용했을 때의 결과와 트레이드오프는 무엇인가?

결과

• 클라이언트 코드는 어떤 변형 /타입을 쓸지만 알고, 실제 구현·생성 로직은 팩토리에 숨김
  • 결합도가 낮아지고 테스트 및 교체가 쉬움
• 새로운 버튼 / 모달 타입이나 훅 변형을 추가할 때, 기존 사용처를 수정하지 않고 팩토리나 매핑만 확장하면 됨
  • 사실상 UI 레벨에서 OCP에 가까운 구조 가능
• 여러 곳에서 동일한 패턴을 반복해서 쓰면서 일관성과 재사용성을 확보

트레이드오프

• 공통 인터페이스, 팩토리 함수, 매핑 객체 등 추가 레이어가 생기면서 코드 구조가 복잡해지고, 작은 규모의 화면이나 일회성 컴포넌트에는 과한 설계가 될 수 있음
• 변형과 확장 포인트가 많아질수록 팩토리 매핑, 서브 구현들이 계속 늘어나 관리해야 할 파일/함수가 증가
• 한 번 더 함수를 경유해 생성하고, 패턴 자체를 이해해야 하므로 약간의 성능 오버헤드와 초기 학습 비용

결론