[체크리스트] 공통 컴포넌트 vs 화면 전용 컴포넌트, 5분 만에 구분하는 기준(리액트 협업)
[체크리스트] 공통 컴포넌트 vs 화면 전용 컴포넌트, 5분 만에 구분하는 기준(리액트 협업)
“이거 공통 컴포넌트로 빼야 하나요?”라는 질문, 회의에서 하루에 몇 번씩 나오죠. 리액트(React) 협업에서는 이 판단 하나가 개발 속도와 유지보수 난이도를 동시에 좌우합니다.
공통으로 빼면 재사용은 좋아지는데, 조금만 달라도 Variant(변형)가 늘어나서 관리가 복잡해지고… 반대로 화면 전용 컴포넌트로 두면 개발은 빨리 끝나지만, 비슷한 UI가 여기저기 복제돼서 유지보수 지옥이 열립니다.
게다가 잘못 나누면 “버튼 하나 수정했는데 전 화면이 깨졌다” 같은 사고가 실제로 터집니다. 결국 문제는 ‘감’이 아니라 구분 기준이 문서로 고정돼 있지 않다는 데 있습니다.
이번 글에서는 리액트(React) 환경에서 바로 써먹을 수 있는 공통 컴포넌트 vs 화면 전용 컴포넌트 판단 체크리스트를 제공합니다. 재사용성, Variant/State, 데이터 결합도 같은 핵심 기준을 5분 안에 점검해 개발자 질문과 리스크를 확 줄여보세요. ✅
핵심 요약 (5분 체크로 결론 내리기)
- 재사용성: 여러 화면에서 반복되면 공통 후보
- Variant/State: 변형/상태가 폭증하면 전용 후보
- 데이터 결합도: 특정 API/도메인에 묶이면 전용 후보
- 변경 영향 범위: 수정 시 파급이 크면 공통화 기준을 더 엄격히
.png "공통 컴포넌트 vs 화면 전용 컴포넌트")
1. 공통 컴포넌트 vs 화면 전용 컴포넌트, 무엇이 다른가?
공통 컴포넌트는 여러 화면에서 재사용되는 UI 부품(예: 버튼, 입력창, 토스트)이고, 화면 전용 컴포넌트는 특정 화면/도메인에 강하게 결합된 UI(예: 결제 요약 카드, 특정 화면 전용 리스트)입니다. 이 글의 목표는 “둘 중 하나가 정답”이 아니라, 기준을 문서로 고정해 판단을 빠르게 만드는 것입니다.
2. 구분 기준이 없을 때 생기는 문제(협업 비용)
- 유사 UI가 복제되어 수정 시 누락 발생(QA 비용 증가)
- 공통화를 과하게 해 Variant/State가 폭증(개발/테스트 난이도 증가)
- “이건 공통인가요?” 같은 반복 질문이 늘어 회의 시간이 증가
- 작은 수정이 전 화면에 영향을 주는 사이드 이펙트 발생
3. 5분 체크리스트: 공통/전용 판단 기준
아래 체크리스트는 “예/아니오”로 빠르게 판단하기 위한 구조입니다.
| 번호 | 질문(판단 기준) | 예(공통 쪽) | 아니오(전용 쪽) | 메모 |
|---|---|---|---|---|
| 1 | 3개 이상 화면에서 동일 패턴으로 반복되나요? | 공통 후보 | 전용 후보 | |
| 2 | Variant(변형)가 3개 이내로 관리 가능한가요? | 공통 후보 | 전용 후보(변형 폭증 위험) | |
| 3 | State(로딩/에러/빈 화면) 규칙이 표준화 가능한가요? | 공통 후보 | 전용 후보(상태가 화면마다 다름) | |
| 4 | 특정 도메인/특정 API에 강하게 묶여 있나요? | 전용 후보 | 공통 후보 | |
| 5 | 수정 시 영향 범위를 예측하기 쉬운가요? | 공통 후보 | 전용 후보(파급 통제 어려움) |
4. 실무 룰: 공통으로 승격/전용으로 격리하는 기준
공통화는 “처음부터 크게”보다, 전용 → 검증 → 공통 승격 흐름이 안전합니다. 팀 규칙으로 아래처럼 정해두면 논쟁이 줄어듭니다.
- 전용으로 먼저 만들고 2~3개 화면에서 재사용이 확정되면 공통으로 승격
- Variant가 4개 이상 늘어나면 공통 후보에서 재검토(분리/전용화)
- 도메인 결합이 강한 UI는 공통 라이브러리 대신 도메인 영역에 둔다
5. 예시로 보는 판단(버튼/리스트/모달)
같은 “버튼”이라도 결제/탈퇴처럼 도메인 규칙이 강하면 전용화가 더 안전할 수 있습니다. 반대로 토스트, 기본 버튼, 입력창처럼 규칙이 표준화되면 공통 컴포넌트로 가져가면 이득이 큽니다.
6. 자주 묻는 질문(FAQ)
Q 공통 컴포넌트는 무조건 좋은 선택인가요?
A 아닙니다. Variant/State가 과도하게 늘면 오히려 유지보수 비용이 커질 수 있어 체크리스트로 선별하는 것이 핵심입니다.
Q 화면 전용으로 두면 무엇이 문제인가요?
A 단기 구현은 빠르지만, 유사 UI 복제로 수정 누락과 QA 비용이 증가할 수 있습니다.
Q 기획자가 어디까지 결정해야 하나요?
A 이름보다 “공통 재사용 의도”, “Variant 기준”, “State 조건”, “예외(로딩/에러/빈 화면)”를 문서로 고정하는 것이 가장 효과적입니다.