Presentational과 Container: 역할 분리 등장

hogu__giriboy·2026년 5월 18일

위클리

목록 보기

11/11

1. 패턴의 등장

React로 개발을 하다 보면
처음에는 자연스럽게 하나의 컴포넌트 안에 모든 걸 넣게 된다.

function UserPage() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser().then(setUser);
  }, []);

  return (
    <div>
      <h1>{user?.name}</h1>
    </div>
  );
}

처음엔 문제 없어 보이지만,
프로젝트 규모가 점점 커지기 시작하면서 컴포넌트 안에 점점 더 많은 것들이 섞이기 시작한다.

상태 관리
API 요청
데이터 가공
이벤트 처리
UI 렌더링

결국 하나의 컴포넌트가 너무 많은 역할을 맡게 되는 거다.

그래서 React에서는
“역할을 분리하자”라는 흐름이 등장하게 된다.

2. Presentational & Container 패턴

이 패턴의 핵심은 단순하다.

컴포넌트를

화면을 보여주는 역할
데이터를 관리하는 역할

로 나누는 거다.

Presentational Component

Presentational Component는
말 그대로 “보여주는 역할”에 집중한다.

UI 렌더링
스타일
마크업

같은 화면 표현만 담당한다.

function UserCard({ name }) {
  return <h1>{name}</h1>;
}

이 컴포넌트는 데이터를 직접 가져오지 않는다.
그냥 받은 데이터를 화면에 출력만 한다.

Container Component

반대로 Container Component는
데이터와 로직을 담당한다.

상태 관리
API 호출
이벤트 처리

같은 동작을 처리하고,
그 결과를 Presentational 컴포넌트에 전달한다.

function UserContainer() {
  const [name, setName] = useState("철수");

  return <UserCard name={name} />;
}

즉,

Container → 데이터 관리
Presentational → 화면 출력

이렇게 역할을 나눈 구조라고 보면 된다.

3. 이 구조의 존재이유

가장 큰 이유는 유지보수 때문이다.

UI와 로직이 섞여 있으면
컴포넌트가 점점 복잡해진다.

반대로 역할을 분리하면

UI 재사용이 쉬워지고
로직 수정 영향 범위가 줄고
테스트하기 편해지고
협업 구조도 명확해진다

특히 디자이너나 퍼블리셔와 협업할 때
화면 컴포넌트만 따로 관리하기도 좋아졌다.

하지만 점점 다른 문제가 생기기 시작했다

문제는 Container 컴포넌트가 너무 많아진다는 점이었다.

<UserContainer>

같은 구조가 계속 생기고,
컴포넌트를 감싸는 구조도 점점 깊어졌다.

또 데이터를 전달하기 위해 props를 계속 넘기다 보니
props drilling 문제도 자주 발생했다.

결국 역할 분리를 위해 만든 패턴이
오히려 구조를 복잡하게 만들기 시작한 거다.

4. Hooks가 등장하면서 흐름이 바뀌었다

React Hooks가 등장한 이후부터는
Container 역할을 컴포넌트가 아니라 Hook으로 분리하기 시작했다.

예전에는:

Container → Presentational

구조였다면,

지금은:

Hook → Component

형태로 많이 바뀌었다.

예를 들면:

function useUser() {
  const [user, setUser] = useState(null);

  return { user };
}
function UserCard() {
  const { user } = useUser();

  return <div>{user.name}</div>;
}