새벽 2시, 우리 프로젝트 React 컴포넌트 200개가 한꺼번에 뒤집어졌을 때 — 그때
개발의 길 2026. 9. 20. 10:04 |
새벽 2시, 우리 프로젝트 React 컴포넌트 200개가 한꺼번에 뒤집어졌을 때 — 그때
프로젝트 마감이 코앞인데 갑자기 화면이 안 뜹니다. 새벽 2시, 노트북 앞에서 30분째 멍하니 앉아 있던 순간이 떠올라요. 그날 제가 React 컴포넌트 설계 패턴 정리를 진심으로 시작했습니다.
제 React 컴포넌트 설계 패턴 정리 이야기: 시작부터 현재까지
처음엔 그냥 "되면 된다"라는 마인드로 코드를 짰습니다. 진짜 그랬어요. 한 컴포넌트 파일에 비즈니스 로직, 뷰, API 호출을 다 몰아넣고, props를 10개씩 넘기면서도 별 문제 없다고 생각했죠.
돌이켜보면, 그때는 "작동하는 코드"와 "유지보수하는 코드"의 차이를 몰랐던 것 같습니다. 컴포넌트가 50개를 넘어가면서부터 재사용이 불가능해졌고, 비슷한 UI를 만들 때마다 Ctrl+C, Ctrl+V로 복붙을 시작했고, 그러다 props 이름이 조금씩 달라지면서 버그가 슬슬 생기기 시작했어요.
React 프로젝트에서는 신규 개발자가 첫 주에 마주치는 컴포넌트의 평균 개수가 적지 않은 편으로 알려져 있습니다. 제 프로젝트도 예외는 아니었어요. 새로 합류한 사람이 코드를 읽을 때 어디서부터 시작해야 할지 몰라 헤매는 일이 잦아졌죠.
이런 일이 일어난 진짜 원인
핵심 원인은 단 하나였습니다. 컴포넌트가 너무 많은 책임을 지고 있었다는 점이에요.
공식 문서를 확인하면 React는 "단일 책임 원칙"을 강조합니다. 한 컴포넌트는 한 가지 일만 해야 한다는 거죠. 재사용 가능한 컴포넌트는 독립적으로 테스트 가능하고, 명확한 인터페이스를 가져야 한다는 권고도 같은 맥락에서 나옵니다. 제 코드는 이 두 가지 다 충족하지 못하고 있었습니다.
구체적으로는 이런 문제가 있었습니다.
- 한 파일에 300줄짜리 컴포넌트가 너무 많음
- props drilling이 5단계 이상 깊어짐
- 같은 로직이 여러 컴포넌트에 중복해서 들어감
- 상태 관리가 각 컴포넌트 안에 흩어져 있어서 디버깅이 지옥이었음
제가 결국 찾은 해결 방법
결국 패턴을 정리하면서 두 가지 접근법을 비교해 봤어요. 옵션 A: HOC(고차 컴포넌트), 옵션 B: 커스텀 훅(Custom Hooks). 두 패턴의 비교는 아래 표로 정리했습니다.
| 비교 항목 | HOC (고차 컴포넌트) | 커스텀 훅 (Custom Hooks) |
|---|---|---|
| 도입 시기 | React 0.13 이후 | React 16.8 이후 |
| 코드 형태 | 컴포넌트를 반환하는 함수 | 일반 함수 (use 접두사) |
| 가독성 | Wrapper 컴포넌트 중첩으로 복잡해질 수 있음 | 평범한 함수 호출이라 직관적 |
| 상태 공유 | props로 전달 (구조가 깊어질 수 있음) | 훅 안에서 직접 공유 |
| 디버깅 | React DevTools에서 Wrapper가 끼어들어 추적 어려움 | 함수 호출 스택 그대로 추적 가능 |
| 권장 시점 | 레거시 코드 유지보수 | 신규 코드, React 16.8 이후 환경 |
| 타입 추론 | 제네릭 작성 난이도 있음 | 비교적 단순 |
표에서 보듯 정답은 상황에 따라 다르다입니다. 다만 React 18.2 기준 공식 릴리스 노트에서도 "함수형 컴포넌트와 훅을 우선 권장한다"는 흐름이 분명해요. React 19가 나온 지금도 그 기조는 유지되고 있습니다. 제 프로젝트도 결국 HOC를 걷어내고 커스텀 훅으로 대부분 옮겼습니다.
GitHub 이슈 트래커에 따르면 facebook/react 저장소에서도 HOC의 Wrapper Hell 문제와 관련된 여러 이슈가 오랫동안 논의되어 왔다고 합니다. 실제 React 진영도 훅 도입 이후 HOC 사용을 줄이는 쪽으로 움직이고 있다는 뜻이에요.
핵심 요점: 신규 프로젝트라면 처음부터 HOC 대신 커스텀 훅 + 함수형 컴포넌트로 시작하세요. 레거시 코드를 다룰 때만 HOC 패턴을 유지하는 게 정신건강에 이롭습니다.
이번 경험에서 얻은 3가지 교훈
첫째, 한 컴포넌트는 한 가지 일만 하게 하세요. 처음부터 분리하기 귀찮아도, 분리해 두면 나중에 디버깅할 때 시간을 아낍니다.
둘째, props drilling이 3단계 이상 깊어지면 Context API나 상태 관리 라이브러리를 검토하세요. props만으로 해결하려 들면 결국 컴포넌트 간 결합도가 높아져서 테스트가 힘들어집니다.
셋째, 같은 로직이 두 군데 이상 보이면 무조건 훅으로 빼세요. "나중에 정리하면 되지"라는 말이 가장 위험합니다. 그 "나중"은 보통 오지 않거든요.
참고로, 이 세 가지 원칙은 단순히 제 경험뿐 아니라 React 커뮤니티 전반에서 자주 언급되는 권장 사항입니다.
마무리
정리하면, 컴포넌트 설계 패턴은 결국 "책임을 어떻게 나눌 것인가"의 문제입니다. 작은 프로젝트일수록 미리 패턴을 정해두는 게 후회 없이 가는 길이에요.
오늘은 여기까지. 도움이 되셨으면 좋겠네요. 패턴 적용 중에 막히는 부분이 있으면 댓글로 알려주세요. 같이 고민해 보겠습니다.
자주 묻는 질문 (FAQ)
Q. HOC 패턴을 아직도 써야 하나요? A. 신규 프로젝트라면 권장하지 않습니다. React 16.8 이상 환경이면 커스텀 훅이 더 깔끔해요. 단, 외부 라이브러리가 HOC로 감싸 제공된다면 그건 그대로 쓰는 게 편합니다.
Q. 커스텀 훅과 Context API, 언제 나눠 쓰나요? A. 로직 재사용 목적이면 커스텀 훅, 전역 상태 공유 목적이면 Context API를 떠올리시면 됩니다. 둘을 함께 쓰는 것도 흔한 조합이에요.
Q. 클래스 컴포넌트는 이제 안 배워도 되나요? A. 신규 프로젝트에선 거의 쓰지 않습니다. 다만 레거시 코드를 유지보수할 일이 있다면 lifecycle 메서드 정도는 알아두셔야 해요.
Q. React 19에서도 같은 패턴이 유효한가요? A. 큰 틀은 그대로 유효합니다. 다만 서버 컴포넌트, use() 훅 등 새로운 개념이 추가됐으니 추후 별도로 정리할 계획이에요.
Q. 컴포넌트 분리 기준이 명확하지 않을 때는요? A. "이 컴포넌트가 어떤 props를 받는지 1분 안에 설명할 수 있느냐"를 자문해 보세요. 설명이 길어지면 분리 신호입니다.
#리액트 #컴포넌트설계 #React훅 #HOC #프론트엔드
'개발의 길' 카테고리의 다른 글
| VS Code 생산성 확장 추천 3가지, 제가 직접 써보고 남긴 정리 (0) | 2026.10.07 |
|---|---|
| Git 자주 쓰는 명령어 정리, 헷갈릴 때 먼저 보는 다섯 가지 (0) | 2026.09.12 |
| VS Code 생산성 확장 추천으로 작업 속도 올리는 법 (0) | 2026.09.11 |
| 파이썬 입문, 어디서부터 시작해야 진짜 다룰 수 있을까? (0) | 2026.08.17 |
| React 컴포넌트 설계 패턴, 반년 동안 삽질하고 정리한 이야기 (0) | 2026.08.03 |
