🔥 리액트 리팩토링[디자인 패턴 적용]

React나 Next.js로 프로젝트를 진행하다 보면 처음엔 단순했던 컴포넌트가 어느새 1,000줄이 넘고 손대면 다른 부분에서 오류가 발생하는 스파게티 코드로 변해버리곤 해요.

다들 이런 경험 있으신가요?

• props를 5단계 이상 전달해야 하는 컴포넌트 트리
• 어디부터 수정해야 할지 막막한 레거시 코드
• 같은 로직이 여러 곳에 복붙되어 있는 코드베이스

이런 문제는 우리만의 고민이 아니라 수많은 선배 개발자들이 겪어온 공통적인 문제예요. 그리고 오랜 고민 끝에 만들어진 해결책 중 하나가 바로 디자인 패턴(Design Pattern) 이에요.

패턴마다 어떤 문제를 풀기 위해 나왔는지를 중심으로 봐주세요. 무조건 쓰는 게 아니라 "이 상황이면 이 패턴"이라는 판단 기준을 가져가는 게 목표예요.

1. Container-Presentation 패턴

컴포넌트가 커질수록 "이 컴포넌트가 뭘 보여주는 건지" "뭘 처리하는 건지"가 뒤섞이기 시작해요. UI를 바꾸려는데 로직도 건드려야 하고 반대로 로직만 수정하면 되는 상황에서 UI 코드를 같이 읽어야 하는 식이에요. Container-Presentation 패턴은 이 두 역할을 파일 단위로 분리해요.

문제상황

UI와 로직이 한 파일에 뒤섞여 단일 책임 원칙이 무너져요.

해결방법

• Container: 상태 관리 및 비즈니스 로직 담당, 각종 훅 adapter 역할
• Presentation: UI 표현만 담당

// ✅ Container
export default function TodoContainer() {
  const { text, setText, todos, addTodo } = useTodo();
  return (
    <TodoPresentation
      text={text}
      onTextChange={setText}
      todos={todos}
      onAdd={addTodo}
    />
  );
}

// ✅ Presentation
interface TodoPresentationProps {
  text: string;
  onTextChange: (text: string) => void;
  todos: Array<{ id: string; text: string }>;
  onAdd: () => void;
}

function TodoPresentation({ text, onTextChange, todos, onAdd }: TodoPresentationProps) {
  return (
    <>
      <input value={text} onChange={(e) => onTextChange(e.target.value)} />
      <button onClick={onAdd}>추가</button>
      <ul>
        {todos.map((t) => (
          <li key={t.id}>{t.text}</li>
        ))}
      </ul>
    </>
  );
}

요즘은 Custom Hook이 Container 역할을 대신하는 경우가 많아요. useTodo 같은 훅이 데이터 로직을 담당하고 Presentation 컴포넌트는 순수하게 UI만 표현하는 식이에요. Dan Abramov도 2019년에 "Custom Hook이 같은 문제를 더 잘 해결한다"고 언급했을 만큼 패턴 자체의 필요성은 줄었지만 UI와 로직을 나눈다는 개념은 여전히 유효해요.

언제 사용할까?

• 같은 UI를 다른 데이터 소스로 재사용해야 할 때
• 스토리북 등으로 UI만 독립적으로 테스트하고 싶을 때
• 디자이너와 협업 시 UI를 명확히 분리하고 싶을 때

UI와 로직을 나눠놓으면 가독성과 재사용성이 올라가는 건 사실이에요. 다만 작은 프로젝트에서는 오히려 파일이 불필요하게 늘어나는 느낌이 들 수 있어요. 팀원끼리 "이 정도 규모면 굳이?"라는 대화를 한 번쯤 나눠보는 게 좋아요.

그런데 여기서 한 가지 의문이 생겨요. UI와 로직을 분리하는 건 좋은데 그 로직 자체를 여러 컴포넌트에서 재사용하고 싶다면 어떻게 해야 할까요? 예를 들어 인증 체크 같은 공통 기능을 열 군데 컴포넌트에 붙여야 하는 상황이라면요.

2. HOC (Higher-Order Component) 패턴

문제상황

특정 기능을 여러 컴포넌트에 재사용하고 싶을 때 불필요한 반복 코드가 생겨요.

해결방법

컴포넌트를 감싸는 고차 함수(HOC)로 기능을 주입해요.

const checkAuthorization = () => {
  // 권한을 확인하거나 로컬스토리지를 확인해 원격 서버로 요청을 보내요.
};

const withAuthorization = <P extends object>(
  Component: React.ComponentType<P>
) => {
  return function WithAuthorization(props: P) {
    const isAuthorized = checkAuthorization();
    return isAuthorized ? <Component {...props} /> : <Login />;
  };
};

실제로 적용할 때는 컴포넌트를 HOC로 감싼 결과를 새 변수에 담아서 써요.

// ✅ 적용 예시
function Dashboard({ title }: { title: string }) {
  return <h1>{title}</h1>;
}

// withAuthorization으로 감싸면 권한 체크가 자동으로 붙어요.
const ProtectedDashboard = withAuthorization(Dashboard);

// 사용할 때는 원본 컴포넌트와 동일한 props를 그대로 넘겨요.
<ProtectedDashboard title="관리자 페이지" />

언제 사용할까?

• 여러 컴포넌트에 동일한 인증/권한 로직을 적용할 때
• 로딩/에러 처리 같은 공통 UI 래퍼가 필요할 때

중복 코드를 제거하고 인증 로직을 한 곳에서 관리할 수 있어요. 반면 HOC를 여러 개 중첩하면 컴포넌트 트리가 불필요하게 깊어지고 props 이름이 충돌할 가능성도 있어요. 요즘은 Custom Hook이 상당 부분을 대체할 수 있어서 새 프로젝트라면 HOC부터 꺼내드는 경우는 많지 않은 편이에요.

HOC가 컴포넌트 단위의 재사용을 해결해준다면 상태 관리 자체가 복잡해지는 문제는 별개예요. useState가 다섯 개쯤 쌓이기 시작하면 어디서 무엇이 바뀌는지 추적하기가 점점 어려워져요.

3. Reducer 패턴

상태가 복잡해지면 useState만으로는 한계가 느껴져요. 특히 여러 상태가 서로 얽혀 있을 때 어떤 이벤트가 어떤 상태를 바꾸는지 파악하기 어렵고, 예상치 못한 타이밍에 상태가 틀어지기도 해요.

useReducer를 쓰면 "어떤 일이 일어났는가(action)"와 "그 결과 상태가 어떻게 달라지는가(reducer)"를 명확히 분리할 수 있어요.

interface Todo {
  id: string;
  text: string;
  completed: boolean;
}

type Action =
  | { type: "ADD"; text: string }
  | { type: "TOGGLE"; id: string }
  | { type: "DELETE"; id: string };

function todoReducer(state: Todo[], action: Action): Todo[] {
  switch (action.type) {
    case "ADD":
      return [
        ...state,
        {
          id: crypto.randomUUID(),
          text: action.text,
          completed: false,
        },
      ];
    case "TOGGLE":
      return state.map((t) =>
        t.id === action.id ? { ...t, completed: !t.completed } : t
      );
    case "DELETE":
      return state.filter((t) => t.id !== action.id);
    default:
      const _exhaustiveCheck: never = action;
      throw new Error(`Unknown action type`);
  }
}

// ✅ 사용 예시
const [todos, dispatch] = useReducer(todoReducer, []);
dispatch({ type: "ADD", text: "새 할 일" });

예를 들어 Action 타입에 { type: "CLEAR" }를 추가했는데 case "CLEAR": 분기를 빠뜨리면 default에서 action이 never가 아닌 타입으로 남아 TypeScript 오류가 바로 발생해요. 놓친 액션이 런타임에서야 터지는 게 아니라 에디터에서 바로 잡히는 거예요.

상태 관리 로직을 reducer 한 곳에 모아두면 "이 상태가 왜 바뀌었지?"라는 질문에 빠르게 답할 수 있어요. 다만 상태가 단순한 경우에는 오히려 코드가 장황해지니까 useState 두세 개로 충분한 상황에서 굳이 꺼낼 필요는 없어요.

상태 관리가 정리됐다면 이제 컴포넌트 간 상태 공유 문제로 넘어가볼게요. props를 깊이 전달하지 않으면서 여러 하위 컴포넌트가 같은 상태를 쓰게 하려면 어떻게 해야 할까요?

4. Compound Components 패턴

문제상황

Props drilling이 심해지고 옵션이 많아질수록 컴포넌트 인터페이스가 복잡해져요.

해결방법

부모 컴포넌트 안에서 자식 컴포넌트들이 Context를 통해 상태를 공유하게 해요.

interface ToggleContextType {
  on: boolean;
  toggle: () => void;
}

const ToggleContext = createContext<ToggleContextType | null>(null);

function useToggleContext() {
  const context = useContext(ToggleContext);
  if (!context) throw new Error('Toggle 내부에서만 사용 가능합니다.');
  return context;
}

function Toggle({ children }: { children: React.ReactNode }) {
  const [on, setOn] = useState(false);

  // toggle을 useCallback으로 안정화하고 value를 useMemo로 메모이제이션해요.
  // Context value가 매 렌더마다 새 객체로 만들어지면
  // 하위 컴포넌트 전체가 불필요하게 리렌더될 수 있거든요.
  const toggle = useCallback(() => setOn((o) => !o), []);
  const value = useMemo(() => ({ on, toggle }), [on, toggle]);

  return (
    <ToggleContext.Provider value={value}>
      {children}
    </ToggleContext.Provider>
  );
}

// Toggle.Button처럼 컴포넌트에 하위 컴포넌트를 프로퍼티로 붙여요.
// 이렇게 하면 Toggle과 관련된 하위 컴포넌트를 Toggle 네임스페이스 안에서 관리할 수 있고
// 사용자 입장에서도 "이 컴포넌트는 Toggle 안에서 써야 하는 것"임을 이름만 보고 알 수 있어요.
Toggle.Button = function ToggleButton() {
  const { on, toggle } = useToggleContext();
  return <button onClick={toggle}>{on ? "ON" : "OFF"}</button>;
};

Toggle.Message = function ToggleMessage({ children }: { children: React.ReactNode }) {
  const { on } = useToggleContext();
  return on ? <span>{children}</span> : null;
};

// ✅ 사용 예시
<Toggle>
  <Toggle.Button />
  <Toggle.Message>토글이 켜졌습니다!</Toggle.Message>
</Toggle>

언제 사용할까?

• 여러 하위 컴포넌트가 상태를 공유해야 할 때
• 조립형 UI를 제공하고 싶을 때
• UI 라이브러리나 디자인 시스템을 설계할 때

확장성과 가독성 면에서 확실히 유용한 패턴이에요. props drilling 지옥을 피하면서 컴포넌트를 조립하듯 쓸 수 있으니까요. 전역 상태가 필요한 수준이 아니라 특정 UI 블록 안에서만 공유되는 상태라면 이 패턴이 딱 맞아요.

이쯤 되면 한 가지 공통점이 보여요. 앞서 소개한 패턴들, HOC든 Compound Components든 결국 "로직을 어디에 두고 어떻게 재사용할 것인가"라는 질문에서 출발했어요. 그리고 현대 React에서 이 질문에 가장 직접적으로 답하는 수단이 바로 Custom Hook이에요.

5. Custom Hook 패턴

여러 컴포넌트에서 똑같은 폼 관리 코드를 복붙하다가 지친 적 있어요? before/after를 보면 이게 왜 필요한지 바로 느껴져요.

// ❌ Before: 컴포넌트마다 같은 코드가 반복돼요.
function LoginForm() {
  const [username, setUsername] = useState("");
  const [password, setPassword] = useState("");

  return (
    <form>
      <input value={username} onChange={(e) => setUsername(e.target.value)} />
      <input value={password} onChange={(e) => setPassword(e.target.value)} />
    </form>
  );
}

// ✅ After: 반복 로직을 훅으로 뽑아내면 컴포넌트가 깔끔해져요.
function useFormInput(initial = "") {
  const [value, setValue] = useState(initial);
  const onChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setValue(e.target.value);
  };
  const reset = () => setValue(initial);

  // inputProps만 따로 묶어서 반환해요.
  // { value, onChange, reset }을 통째로 스프레드하면
  // reset이 DOM에 알 수 없는 속성으로 전달되어 콘솔 경고가 발생하거든요.
  return { inputProps: { value, onChange }, reset };
}

function LoginForm() {
  const username = useFormInput("");
  const password = useFormInput("");

  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();

    await login(username.inputProps.value, password.inputProps.value);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input {...username.inputProps} placeholder="아이디" />
      <input {...password.inputProps} type="password" placeholder="비밀번호" />
      <button type="submit">로그인</button>
    </form>
  );
}

이전의 HOC나 Render Props가 담당하던 역할 대부분을 Custom Hook이 대체하면서 현대 React에서 가장 자주 쓰이는 패턴이 됐어요. 로직 재사용이라는 목적만 보면 거의 만능에 가깝죠. 다만 한계도 있어요. 로직은 분리할 수 있지만 여러 컴포넌트 사이의 UI 상태 공유는 여전히 별도 수단(Context, 상태 관리 라이브러리)이 필요해요. 훅을 테스트하려면 renderHook 같은 테스트 환경 설정도 따로 챙겨야 하고요.

언제 사용할까?

• 여러 컴포넌트에서 동일한 로직을 사용할 때
• API 호출, 폼 관리, 애니메이션 등 재사용 가능한 로직이 있을 때
• 컴포넌트에서 로직을 분리해 테스트하고 싶을 때

마무리

디자인 패턴은 만능 해결책은 아니라고 생각해요.
하지만 반복되는 문제에 대한 검증된 해법이라고 볼 수 있어요.
React에서 자주 쓰이는 패턴들을 이해하고 적절하게 활용하면 코드 품질이 눈에 띄게 좋아질 수 있어요.

참고 자료

• 패턴으로 익히고 설계로 완성하는 리액트
• 자바스크립트 + 리액트 디자인 패턴
• Compound Components in React (Design Patterns)