프레임워크 없이 컴포넌트 기반 리뉴얼 프로젝트의 장단점

현재 우리 회사에서는 react나 vue와 같은 프레임워크 없이도

컴포넌트 기반으로 마크업을 작성하고 html과 css를 불러오는 구조로

리뉴얼 프로젝트를 진행할 예정이다.

 

프레임워크 없이 컴포넌트 기반으로 리뉴얼 프로젝트를 진행할 때의 장단점과

예상되는 문제점, 퍼블리싱 시 고려해야 할 포인트들을 정리해봤다.

 

 

---

장점

1. 컴포넌트 단위의 재사용
버튼, 헤더, 푸터, 카드 등 공통 UI를 모듈화해서 관리하면 중복 작업이 줄어들고 개발 속도가 빨라짐.
반복되는 구조를 재사용 가능하니 HTML 마크업이 깔끔해지고, 생산성이 향상됨.

2. 코드 분리로 가독성 향상
하나의 html 파일에 모든 내용을 작성하는 방식보다, 파일을 기능별로 나누면 각 컴포넌트 구조를 파악하기 쉬움.
신규 인원이 투입돼도 구조만 익히면 빠르게 적응 가능.

3. 스타일 충돌 최소화
컴포넌트 단위로 CSS를 작성하면 전역 스타일 오염이 줄어들고, 네임스페이스 충돌을 줄일 수 있음.
특히 CSS-in-JS 스타일을 차용한 방식이나 BEM 구조를 잘 적용하면 더욱 효과적임.

4. 페이지 부분 변경 시 효율적
전체 페이지가 아닌 일부 UI만 바뀔 경우, 해당 컴포넌트만 수정하면 되므로 유지보수 효율이 좋음.

---

 

단점

1. JS 의존도 증가
HTML을 JS에서 불러오는 방식은 브라우저가 자바스크립트를 비활성화했거나 로딩에 실패했을 경우 페이지가 정상적으로 표시되지 않을 수 있음.

2. 검색엔진 최적화(SEO)에 불리
JS 로드 후 렌더링되는 구조는 SSR이 아니면 일부 검색엔진에서 콘텐츠가 인식되지 않을 수 있음.
특히 초기 렌더링이 늦어지는 경우 사용자 경험에도 악영향을 줄 수 있음.

3. 초기 진입장벽
퍼블리셔가 JS로 마크업을 관리하는 구조에 익숙하지 않으면 적응하는 데 시간이 걸릴 수 있음.
디자이너나 다른 협업자가 HTML 구조를 보려고 할 때 접근이 어려울 수 있음.

4. 디버깅 어려움
마크업이 JS 파일 내부에 있다 보니, 디버깅 시 소스 구조를 파악하거나 추적하는 데 시간이 걸릴 수 있음.

 

---

 

유지보수 시 예상 문제점

1. 컴포넌트 간 의존성
컴포넌트끼리 서로 영향을 주게 되면 수정 시 예상치 못한 사이드 이펙트가 발생할 수 있음.
예: 버튼 컴포넌트를 수정했는데 다른 페이지의 버튼 스타일이 깨짐.

2. 버전 관리의 어려움
여러 프로젝트에서 같은 컴포넌트를 공유할 경우, 어느 시점에서 어느 컴포넌트를 사용하는지 관리가 어려워질 수 있음.

3. 디자인 변경 시 전체 적용 누락
공통 컴포넌트를 사용하는 줄 알고 변경했는데, 개별 페이지에서 override된 컴포넌트가 있어 변경이 누락될 수 있음.

4. 협업 도구 및 테스트 환경 부재
React나 Vue처럼 컴포넌트 테스트를 쉽게 도와주는 툴이 없어 직접 HTML과 JS로 로직을 확인해야 함.
Storybook 같은 도구 없이 개발자와 UI 테스트 시 불편할 수 있음.

 

---

 

퍼블리셔 입장에서의 고려 포인트

 

폴더 구조

컴포넌트 단위로 분리된 폴더 구조를 표준화하여 관리 편의성 확보

네이밍 룰

컴포넌트 명, CSS 클래스명에 일관된 규칙 적용 (ex. BEM)

문서화

각 컴포넌트의 사용법, 역할, 의존성 등을 문서화해서 팀원 간 공유

렌더링 방식

동적으로 로드된 HTML은 언제, 어떻게 삽입되는지 명확히 파악 필요

Fallback 제공

JS 로딩 실패 시 최소한의 HTML fallback 구조 고려