Antigravity Agent
34 lines
5.0 KiB
Markdown
34 lines
5.0 KiB
Markdown
---
|
|
id: [[P-Reinforce|P-Reinforce]]-AUTO-353103
|
|
category: Dev
|
|
confidence_score: 0.90
|
|
tags: [auto-reinforced]
|
|
last_reinforced: 2026-04-20
|
|
github_commit: "[P-Reinforce] Continuous Worker - 프론트엔드 컴포넌트 구조화"
|
|
---
|
|
|
|
# [[프론트엔드 컴포넌트 구조화|프론트엔드 컴포넌트 구조화]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> 프론트엔드 컴포넌트 구조화는 웹 개발에서 복잡성을 줄이고 유지보수성을 높이기 위해 기능과 역할 단위로 코드를 분리하고 조직하는 방법론입니다 [1, 2]. 초기에는 HTML, CSS, [[JavaScript|JavaScript]]라는 언어적 역할에 따라 분리되었으나, 특정 기능과 UI 요소를 하나의 단위로 묶는 컴포넌트 기반 아키텍처로 진화했습니다 [3]. 프로젝트의 규모가 커짐에 따라 발생하는 컴포넌트 간의 높은 결합도를 해결하기 위해, 관심사의 분리(SoC) 원칙을 다시 적용하여 [[Feature-Sliced Design|Feature-Sliced Design]](FSD)과 같이 기능 중심으로 구조를 세분화하는 방향으로 발전하고 있습니다 [2, 4].
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
- **컴포넌트 패러다임의 등장과 한계:** 프론트엔드의 개발은 본래 문서의 구조, 표현, 동작을 위해 각각 HTML, CSS, JS라는 수평적 계층으로 나뉘어 있었으나, 웹 프레임워크의 도입과 함께 기능 중심의 모듈화를 의미하는 수직적 '컴포넌트' 방식으로 변화했습니다 [1, 3, 5]. 하지만 프로젝트가 비대해짐에 따라 하나의 컴포넌트 안에 데이터 관리, 표현 로직, 비즈니스 로직이 집중되어 단일 책임 원칙을 위반하고, 'props drilling'으로 인한 컴포넌트 간의 결합도가 지나치게 높아지는 문제가 발생했습니다 [4, 6].
|
|
- **계층적 관심사로의 회귀:** 컴포넌트의 한계를 극복하기 위해 다시 계층적 분리가 도입되었습니다 [7]. UI 컴포넌트의 명확한 역할과 계층을 나누기 위한 [[Atomic Design Pattern|Atomic Design Pattern]]의 도입, CSS가 HTML의 구조를 단방향으로 따라가게 만드는 의존성 해결, 그리고 화면(View)과 데이터 로직을 분리하여 단방향 데이터 흐름을 만드는 상태 관리(State [[Management|Management]]) 기법이 적용되었습니다 [8-10].
|
|
- **폴더 구조의 진화와 FSD 아키텍처:** 전통적인 폴더 구조는 역할(api, components, pages 등)을 중심으로 분리되었으나, 대규모 프로젝트에서는 기능 단위로 코드가 흩어지게 되어 파악이 어렵습니다 [11, 12]. 이에 따라 기능을 기준으로 필요한 모든 파일을 한 폴더에 모아 관리하는 Feature-Sliced Design(FSD) 아키텍처가 대안으로 등장했습니다 [2]. 이를 통해 기능 간의 결합도를 줄이고 독립적인 관리가 가능해집니다 [13].
|
|
- **올바른 컴포넌트 분리 원칙:** 프론트엔드 구조화에서 가장 흔한 실수는 겉모양이 비슷하다는 이유로 완전히 다른 도메인 데이터를 다루는 컴포넌트들을 하나로 묶어 재사용하려는 것입니다 [14]. 화면을 다루는 뷰 컴포넌트와 비즈니스 로직을 다루는 도메인 컴포넌트는 명확히 분리해야 하며, 만약 같은 화면 컴포넌트를 여러 도메인에서 공유해야 한다면 데이터를 변환하는 어댑터를 활용해 도메인별 데이터 규격을 화면 컴포넌트가 받아들일 수 있는 형태로 맞추어 전달하는 구조를 취해야 합니다 [15, 16].
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- **Related Topics:** 관심사의 분리, [[Feature-Sliced Design|Feature-Sliced Design]], 단일 책임 원칙 (SRP), [[Atomic Design Pattern|Atomic Design Pattern]]
|
|
- **Projects/Contexts:** [[대규모 프론트엔드 웹 프로젝트 폴더 구조화|대규모 프론트엔드 웹 프로젝트 폴더 구조화]], [[컴포넌트 기반 웹 프레임워크 아키텍처 설계|컴포넌트 기반 웹 프레임워크 아키텍처 설계]]
|
|
- **Contradictions/Notes:** 초기 웹 개발은 HTML, CSS, JS라는 역할 중심의 계층 구조로 이루어졌으나, 컴포넌트 패러다임의 등장으로 기능 중심의 융합 구조로 변하였습니다 [1, 3]. 하지만 컴포넌트 비대화와 결합도 증가라는 복잡성 문제가 다시 발생함에 따라, 현대에는 컴포넌트 내외부를 다시 세분화된 역할과 기능(Feature) 단위로 분리하는 FSD 아키텍처 구조로 나아가는 진화 흐름을 보입니다 [2, 4, 7].
|
|
|
|
---
|
|
*Last updated: 2026-04-18*
|
|
|
|
---
|