프론트엔드 개발에서 과도한 추상화를 멈추자

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

웹 개발

대상자

프론트엔드 개발자, 디자이너, UI/UX 전문가

핵심 요약

• 프론트엔드 추상화는 백엔드와 동일한 방식으로 적용하는 것이 잘못됨 - UI의 변화 빈도와 특성은 백엔드와 근본적으로 다름
• 과도한 추상화는 디자인 변화 시 유지보수 비용을 증가시킴 - 예: type: "BANNER_SMALL"과 같은 메타데이터 기반 렌더링
• UI 설계는 "유연성"보다 "변화 대응력"에 중점을 두어야 함 - Tailwind, Fluent UI v9처럼 기초 레이아웃 추상화만 수행해야 함

섹션별 세부 요약

1. 프론트엔드 추상화의 오해

• 백엔드 설계 패턴(팩토리, 전략 등)을 UI에 무분별하게 적용
• UI의 변화 빈도는 백엔드보다 10배 이상 빈번 - Figma 파일은 2주에 한 번씩 변경되지만, DB 스키마는 수개월 유지됨
• 과도한 추상화는 "아키텍처 뼈대"로 보이는 것이지만, 오히려 디자인 변경 시 유지보수를 복잡하게 만듦

2. 추상화의 실질적 문제점

• 메타데이터 기반 렌더링은 코드 복잡도를 증가

- 예: { type: "BULLET", content: "..." } 형식의 데이터 구조

• 새로운 개발자가 추상화 구조를 이해하는 데 시간 소요

- "왜 푸터가 섹션 팩토리 안에 감싸져 있는가?"와 같은 질문 발생

• 디자인 변경 시 기존 추상화가 무용지물이 되는 경우 많음 - 예: "배너 위치 변경" 시 전체 구조 재작성 필요

3. 올바른 접근 방향

• 기초 레이아웃 추상화만 수행 - Tailwind의 유틸리티 기반 레이아웃, Fluent UI v9의 구조화된 컴포넌트 재사용
• "DRY"보다 "가독성"을 우선시 - 코드 가독성을 높이는 것이 유지보수에 더 유리
• "변화 대응력"을 위한 설계 원칙 도입 - Tailwind의 유틸리티 클래스와 Fluent UI의 구조화된 컴포넌트 패턴 활용

결론

• 프론트엔드 추상화는 "유연성"보다 "변화 대응력"에 중점을 두어야 함 - Tailwind, Fluent UI v9처럼 기초 레이아웃 추상화만 수행하고, 메타데이터 기반 렌더링은 피해야 함
• 디자인 변경 시 추상화 구조가 복잡해지는 경우, 즉시 추상화를 중단하고 단순한 컴포지션 방식으로 전환
• "UI는 백엔드와 달리 변화가 빈번하므로, 유지보수를 위한 유연한 구조가 우선"이라는 원칙을 전문가 팀에 공유