컴포넌트

UI를 독립적이고 재사용 가능한 조각으로 분할하고, 각 조각을 개별적으로 고찰할 수 있도록 만든 선언적 구조체.

— React 공식 도큐먼트 가이드 및 MDN 웹 기술 문서

"재사용 하려고 컴포넌트로 쪼갰는데, 정작 프로젝트 내내 단 한 번만 쓰이고 버려지는 독거 컴포넌트가 90%다." ~~그냥 한 파일에 길게 적는 게 훨씬 가독성 좋았을 텐데 대체 왜 쪼갰을까.(...)~~

1. 개요

모던 웹 프론트엔드 개발(React, Vue, Svelte 등)에서 UI(User Interface)를 구성하는 독립적이고, 재사용이 가능하며, 스스로 상태를 관리할 수 있는 최소 단위의 레고 블록이다. 영문 명칭은 Component. HTML과 자바스크립트를 결합하여 선언형 단위로 화면을 코딩하는 패러다임이다.(...)

2. 아토믹 디자인의 이상향과 거대 쓰레기 더미의 현실

모던 프론트엔드 생태계는 컴포넌트 중심으로 돌아간다. 디자인 시스템을 구축하겠답시고 가장 원자 단위의 버튼부터 쪼개서 조립해 나가는 아토믹 디자인(Atomic Design) 패턴을 도입하는 유행이 불기도 했다. 그러나 이론과 현실은 다른 법. 실무에서는 아주 사소한 스타일 변화나 비즈니스 로직 차이 때문에 컴포넌트 내부에 온갖 분기 조건문 속성(Props)이 덕덕지덕지 붙어 기괴한 누더기 괴물이 탄생하곤 한다. 결국 Button 컴포넌트 하나가 인자값만 40개를 받아 처먹는 대형 오브젝트로 진화하여 재사용성은 커녕 수정조차 불가능한 폭탄이 되기 일쑤다. 이 짓거리를 피하려고 다시 컴포넌트를 쪼개다 보면, 파일 이름이 RealFinalNavbarAbsoluteSecondVersion.tsx 같은 파멸적인 꼬락서니로 치닫는다.(...)

3. 관련 밈 및 드립

3.1. 컴포넌트 폴더 구조 짜기 대전쟁

새로운 프론트엔드 프로젝트를 시작할 때 개발자들이 코딩은 안 하고 3일 밤낮을 키보드로 싸우는 밈이다. components/ 폴더 밑에 기능별로 묶을 것인가, 도메인별로 묶을 것인가, 아니면 공통 요소만 둘 것인가를 두고 치열한 정치 싸움을 벌이다가, 결국 프로젝트 후반부에는 기한에 쫓겨 아무 폴더에나 무지성으로 파일을 던져놓아 개판 오분 전 개집으로 완성되는 결말을 의미한다.

3.2. Props Drilling 지옥

최상위 부모 컴포넌트가 들고 있는 데이터를 10단계 밑에 있는 막내 증손주 컴포넌트에게 전달하기 위해, 중간에 있는 아무 죄 없는 부모·형제 컴포넌트들이 오직 배달부 역할만을 수행하며 인자값을 대물림하는 노가다 현상이다. 중간 컴포넌트의 파라미터를 한 줄 고치면 하위 모든 자식 컴포넌트의 타입 정의(TypeScript)가 연쇄적으로 터지는 뇌절 쇼를 유발한다.

4. 여담

클래스형에서 함수형으로: 과거 리액트 컴포넌트는 extends React.Component를 상속받아 장황하게 작성하는 클래스 형태였으나, 훅(Hooks)의 도입으로 현재는 깔끔한 함수형 컴포넌트가 시장을 99% 씹어 먹었다. 과거 유산을 보면 장엄함마저 느껴진다.
웹 컴포넌트(Web Components) 표준의 공기화: 원래 특정 프레임워크에 종속되지 않는 브라우저 표준 자체 기술로 웹 컴포넌트 명세가 존재하지만, 리액트와 뷰의 생태계가 너무나 견고하고 비대하여 표준 기술은 현업에서 공기 취급을 당하고 있다.
서버 컴포넌트(RSC)의 유행: 2026년 현재는 브라우저가 아니라 서버에서 미리 렌더링을 끝내고 완성본 뼈대만 클라이언트에 내려보내는 리액트 서버 컴포넌트 기술이 상식으로 자리 잡았으나, 프론트엔드 개발자가 서버 인프라 비용과 하이드레이션 에러까지 신경 써야 하는 새로운 고통을 낳았다.