AI 코드 생성 도구가 일상이 된 지금, 아이러니한 현상이 하나 생겼다. 코드를 더 빠르게 만들 수 있게 됐는데, 오히려 코드베이스가 더 빠르게 뒤엉킨다. Cursor나 Claude로 컴포넌트를 뚝딱 만들어내다 보면 어느새 데이터 페칭 로직과 렌더링 코드가 한 파일 안에 뒤섞인 덩어리들이 늘어나 있다. 속도는 빠른데 유지보수는 점점 힘들어지는 구조적 역설이다.
이 맥락에서 React의 Presentational & Container 패턴이 다시 주목받을 이유가 생긴다. velog의 한 기술 포스팅이 잘 정리하고 있듯, 이 패턴의 핵심은 단순하다. '무엇을 보여주는가(UI)'와 '어떻게 데이터를 가져오는가(로직)'를 명확히 나누는 것이다. UserCard는 name, email, avatar를 받아서 렌더링만 하고, UserCardContainer가 fetchUser를 호출해 데이터를 준비한 뒤 넘겨준다. 역할이 분리되니 각자의 책임이 명확해진다.
물론 React Hooks가 등장한 이후, Container 컴포넌트 대신 Custom Hook으로 로직을 분리하는 방식이 주류가 됐다. useProductList 같은 훅이 데이터 페칭과 상태 관리를 담당하고, ProductList 컴포넌트는 그 훅을 호출해 렌더링에만 집중한다. 문법은 달라졌지만 철학은 같다. '관심사의 분리(Separation of Concerns)'라는 원칙이 형태를 바꿔 살아남은 것이다.
AI 코드 생성 맥락에서 이 패턴이 진짜 빛을 발하는 지점은 여기서부터다. AI에게 컴포넌트 생성을 요청할 때, 경계가 명확한 설계를 프롬프트에 심어두면 결과물의 품질이 달라진다. "데이터 페칭 없이 props만 받아 렌더링하는 Presentational 컴포넌트를 만들어줘"라고 지정하면, AI는 useEffect나 fetch 없이 순수한 UI 코드를 생성한다. 반대로 로직 레이어는 Custom Hook으로 분리해 요청하면, 나중에 API 엔드포인트가 바뀌거나 상태 관리 라이브러리를 교체할 때 건드릴 파일이 명확해진다. AI가 만든 코드도 경계가 있으면 교체와 수정이 쉬워진다.
디자인 시스템 관점에서도 이 경계는 결정적이다. Presentational 컴포넌트는 외부 상태에 의존하지 않기 때문에 Storybook에서 독립적으로 렌더링할 수 있고, 디자이너와 개발자가 동일한 컴포넌트를 함께 검증할 수 있다. AI로 프로토타입을 빠르게 뽑아낸 뒤, 그 UI 껍데기를 디자인 시스템의 컴포넌트로 격상시키는 흐름이 자연스럽게 이어진다. 경계가 없으면 이 흐름이 막힌다—데이터 로직이 UI에 뒤엉켜 있으면 디자이너가 검토할 수 있는 순수한 UI 레이어가 존재하지 않기 때문이다.
시사점은 명확하다. AI 도구가 코드 생성 속도를 높여줄수록, 개발자가 지켜야 할 것은 '어떤 경계를 어디에 그을 것인가'에 대한 판단력이다. AI는 요청한 대로 코드를 만들어주지만, 그 코드가 전체 아키텍처 안에서 어느 레이어에 속해야 하는지는 알지 못한다. Presentational과 Container(혹은 Custom Hook)의 분리는 그 판단을 구조화하는 가장 검증된 방법 중 하나다. 패턴 자체보다 패턴이 강제하는 '생각의 순서'가 더 중요하다.
앞으로의 방향은 이렇게 그려진다. AI가 더 자율적으로 코드를 생성하는 에이전트 시대로 갈수록, 개발자의 역할은 코드를 타이핑하는 것에서 올바른 경계를 설계하고 그 기준을 AI에게 명확히 전달하는 것으로 이동할 것이다. Presentational & Container 패턴은 낡은 개념이 아니다. AI와 협업하는 방식이 성숙해질수록, 이 패턴이 지향하는 관심사의 분리 원칙은 오히려 더 근본적인 질문으로 돌아온다. 코드를 누가 짜느냐보다, 그 코드가 어디에 속하는지를 아는 사람이 결국 시스템을 오래 살아남게 만든다.