meepin 컴포넌트 분리를 어떻게 해야될까에 대한 고찰
목차
개요
문제 정의 및 논의 목적
실무에서 마주친 주요 과제들
해결을 위한 전략 정리
4.1 스타일 vs 컴포넌트 분리 체크리스트
추천 방안
- 개요
이 문서는 단기 구축형 프로젝트에서 컴포넌트 설계 전략을 정리한 것입니다..
UI 재사용을 위한 컴포넌트와 CSS의 이상적 분리 기준
현실적인 프로젝트 속도와 유지보수 가능성을 고려한 폴더 구조 및 설계 방안
- 문제 정의 및 논의 목적
목적
재사용성과 확장성을 고려한이상적인 컴포넌트 구조를 구축 프로젝트에서 어디까지 추구해야 하는가?
스타일을 재사용하기 위해 컴포넌트로 분리하는 것이과연 합리적인가?
스타일이 컴포넌트와 결합될 경우 유지보수성은 어떻게 확보할 수 있는가?
- 실무에서 마주치는 이슈
실무 케이스별 이슈와 그것이 왜 문제였는가에 대한 테이블..
이슈
설명
발생 원인
컴포넌트에 스타일을 재사용
여러 화면에서 같은 레이아웃을 복붙,
클래스 순서 누락 시 UI 깨짐
CSS 기억 의존, 문서 부재
개발자마다 DOM 구조 구성 다름
같은 카드라도 누락/과잉 구조가 생김
구조 캡슐화 부재
리팩토링 시 구조 변경 파급
UI가 CSS 기반일 경우 DOM 바뀌면 전면 수정 필요
구조-스타일 분리 실패
스타일만 필요하지만 컴포넌트화됨
단순 타이틀/섹션인데도 컴포넌트화
기준 없는 분리
기억 의존
3개월 뒤 class 조합, 순서, 구조 등 잊음
문서화 미흡, 캡슐화 부족
- 해결을 위한 전략 정리
4.1 스타일 vs 컴포넌트 분리 체크리스트
컴포넌트로 분리할지, CSS로만 조립할지를 결정하기 위한 실용적인 체크리스트..
항목
CSS 조립(스타일 분리)
컴포넌트 분리
DOM 구조 복잡도
단순
중첩됨
상태 제어 여부
없음
있음 (hover, loading, skeleton 등)
반복 재사용 빈도
낮음
높음
조립 시 실수 가능성
높음 (순서, 클래스 누락)
낮음
문서화 필요성
높음 (class 기억 필요)
낮음 (컴포넌트 추상화)
디자이너 → 개발자 전달 효율성
낮음
높음
디자인 변경 시 영향 범위
전역적 (클래스 재정의)
국지적 (컴포넌트 내부만 수정)
단기 구축에 적합
부분적으로
구조 고정 시 유리
- 추천 방안
스타일만 존재하는 구조는 장기적으로는 유지보수가 불가능→ 구조를 모르면 class를 잘못 조합할 가능성 높음