React 컴포넌트 설계 패턴, 반년 동안 삽질하고 정리한 이야기
개발의 길 2026. 8. 3. 19:03 |
React 컴포넌트 설계 패턴, 반년 동안 삽질하고 정리한 이야기
리액트 프로젝트 처음 맡았을 때, 컴포넌트를 그냥 마구 만들어서 3개월 만에 코드베이스가 스파게티가 됐어요. 그때부터 진짜 설계 패턴 공부를 시작했습니다. 오늘은 제가 직접 부딪힌 경험을 솔직하게 풀어볼게요.


제 React 컴포넌트 설계 패턴 정리 이야기: 시작부터 현재까지
사실 처음엔 컴포넌트 = 그냥 함수라고 생각했습니다. 버튼 하나 만들었는데, 거기에 비즈니스 로직이랑 스타일, API 호출까지 다 들어가 있더라고요. 간단합니다. 그게 시작이었습니다.
그러다 프로젝트가 커지면서 이런 일이 벌어졌어요.
- props가 20개 넘어가는 컴포넌트 등장
- 같은 UI를 3군데서 다르게 렌더링
- 상태가 어디서 오는지 추적 불가능
- 재사용하겠다고 만든 컴포넌트가 한 군데서만 쓰임
스택오버플로우 답변에 따르면 이런 현상은 "Prop Drilling"과 "God Component"라는 이름으로 자주 언급됩니다. stackoverflow.com/questions/38357241 같은 글에서 실제로 같은 상황을 호소한 사람이 많았어요.
그때는 몰랐는데, 돌이켜보면 패턴을 모른 게 아니라 적용 타이밍을 몰랐던 거였어요.
이런 일이 일어난 진짜 원인
원인은 단순했습니다. 처음에 설계를 안 했거든요.
공식 문서를 확인하면 React 팀은 "Thinking in React" 가이드에서 먼저 컴포넌트 계층을 쪼개라고 강조합니다. (출처: https://react.dev/learn/thinking-in-react) 근데 저는 VSCode 켜고 바로 App.jsx부터 작성했어요. 솔직히 후회됩니다.
또 하나. React 18로 업그레이드하면서 Suspense와 Concurrent Features가 추가됐는데, 이걸 모른 채 코드를 짰습니다. 공식 릴리스 노트에 따르면 React 18은 2022년 3월 29일 출시됐고, 자동 배칭(Automatic Batching)이 기본값으로 들어왔어요. 출처: https://react.dev/blog/2022/03/29/react-v18
설계 없이 코드를 먼저 짜면, 나중에 리팩토링 비용이 10배 이상 증가합니다. 체감상 진짜 그랬어요.
제가 결국 찾은 해결 방법
저는 결국 5가지 패턴을 비교해 보고, 우리 프로젝트에 맞는 조합을 골랐습니다. 표로 정리합니다.
| 패턴 | 장점 | 단점 | 적합한 상황 |
|---|---|---|---|
| 컨테이너/프레젠테이셔널 | 관심사 분리 명확 | 보일러플레이트 증가 | 데이터 fetch와 UI 분리 |
| 컴파운드 컴포넌트 | 유연한 API 제공 | 학습 곡선 있음 | 셀렉트, 아코디언 같은 복합 UI |
| 고차 컴포넌트 (HOC) | 횡단 관심사 재사용 | props 충돌 가능 | 권한 체크, 로깅 |
| 렌더 프롭스 | 명시적 데이터 흐름 | JSX 중첩 깊음 | 동적 렌더링이 필요한 경우 |
| 커스텀 훅 | 상태 로직 재사용 | 남발 시 복잡도 증가 | React 16.8 이후 거의 모든 케이스 |
참고로 MDN 웹 문서를 확인하면 React 자체는 라이브러리라서 정해진 패턴이 따로 없습니다. 그래서 팀 컨벤션이 핵심이에요. 한 번 정해두면 오래 갑니다.
저는 결국 컴파운드 컴포넌트 + 커스텀 훅 조합으로 정착했습니다. 이유는 단순해요. React 19에서도 잘 동작하고, 훅 기반이라 트리 쉐이킹이 잘 됩니다. React 19는 2024년 12월 5일 정식 출시됐어요. 출처: https://react.dev/blog/2024/12/05/react-19
한 번 해보세요. props 개수가 눈에 띄게 줄 겁니다.
이번 경험에서 얻은 3가지 교훈
교훈 1. 처음 30분은 설계에 쓰자.
타이핑 시작 전에 컴포넌트 계층도를 그립니다. 종이에요. 도구 없어도 됩니다. 사실 이게 진짜 효과 있었어요.
교훈 2. 작은 컴포넌트부터 쪼개자.
100줄짜리 컴포넌트 보면 일단 의심하세요. 대부분 더 쪼갤 수 있어요. 살짝만 분리해도 테스트하기 쉬워집니다.
교훈 3. 패턴은 도구일 뿐, 답이 아닙니다.
커스텀 훅이 좋다 해서 모든 곳에 적용하면, 오히려 추적이 더 어려워집니다. 그러면 안 되죠. 팀 규모와 프로젝트 성격을 고려해야 합니다.
핵심 요점: 패턴은 "이 상황에서 이렇게 쓰면 편하다"는 도구 모음일 뿐, 맹신하면 독이 됩니다.
마무리
오늘은 React 컴포넌트 설계 패턴을 반년 동안 부딪히며 정리한 이야기를 풀어봤습니다. 한 줄로 요약하면 이래요. "설계 30분, 구현 2시간" — 이 비율이 진짜 효과 있었어요.
여러분의 프로젝트는 어떤 비율인가요? 댓글로 알려주시면 저도 많이 배울 수 있습니다. 끝까지 읽어주셔서 고맙습니다. 도움이 되셨으면 좋겠네요.
자주 묻는 질문 (FAQ)
Q. React 18과 19 중 어떤 버전에서 시작하는 게 좋을까요? A. 2025년 기준 신규 프로젝트는 React 19로 시작하는 걸 추천합니다. 자동 메모이제이션과 Actions가 추가되어 보일러플레이트가 크게 줄었어요.
Q. 커스텀 훅과 유틸 함수의 차이는 무엇인가요? A. 커스텀 훅은 React 상태나 생명주기를 사용할 수 있는 반면, 순수 유틸 함수는 일반 자바스크립트 함수입니다. 상태가 필요 없다면 유틸 함수로 충분해요.
Q. 컴파운드 컴포넌트 패턴은 언제 쓰나요? A. 셀렉트 박스, 탭, 아코디언처럼 부모-자식 관계가 명확한 UI에 적합합니다. 페이스북, 유튜브 셀렉트 박스가 대표적 사례죠.
Q. 고차 컴포넌트는 이제 안 쓰나요? A. React 공식 문서도 훅 사용을 권장하지만, 횡단 관심사(로깅, 권한 체크)에는 여전히 유효합니다. 무조건 배제하진 마세요.
Q. 클래스 컴포넌트는 배워야 하나요? A. 레거시 코드 유지보수라면 알아야 하지만, 신규 프로젝트는 함수형 컴포넌트로 충분합니다.
#리액트 #React #컴포넌트설계 #프론트엔드 #웹개발
'개발의 길' 카테고리의 다른 글
| VS Code 생산성 확장 5개, 진짜 잘 쓰는 것만 추천합니다 (0) | 2026.07.18 |
|---|---|
| PostgreSQL 인덱스 기초 가이드: B씨 프로젝트가 8초 (0) | 2026.07.08 |
| 2026년 개발 현장의 필수 기술 (1) | 2026.07.05 |
| 2026년 신입 개발자라면 (0) | 2026.07.04 |
| VS Code 생산성 확장 추천 - 2년 동안 써보고 진짜 살아남은 (1) | 2026.06.29 |







