feat: Wiki-fication of 00_Raw data (Batch #4 - Next.js, Atomic Style, CI/CD, CLS, Rendering)
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,22 @@
|
||||
# [[Component Lifecycle]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
컴포넌트 라이프사이클(Component Lifecycle)은 컴포넌트가 렌더링되고, 업데이트되며, 마운트 해제(unmount)되는 일련의 과정을 의미합니다. 최신 함수형 React에서는 `useEffect`와 같은 훅(Hook)을 사용하여 라이프사이클에 따른 부수 효과(side effects)를 관리하며, 클래스형 컴포넌트에서는 `componentDidCatch`와 같은 특정 라이프사이클 메서드를 활용합니다 [1, 2]. 특히 컴포넌트가 마운트 해제될 때 적절한 정리(cleanup) 작업을 수행하는 것은 메모리 누수를 방지하고 애플리케이션의 안정성을 유지하는 데 필수적입니다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **함수형 컴포넌트와 `useEffect` 훅 활용**
|
||||
최신 React의 함수형 컴포넌트에서는 주로 `useEffect`를 통해 라이프사이클과 관련된 부수 효과(side effects)를 처리합니다. 흔히 발생하는 문제 중 하나는 이벤트 리스너나 구독(subscription)과 같은 효과를 컴포넌트 마운트 해제 시 정리(cleanup)하지 않는 것입니다 [1]. 이러한 정리 누락은 시간이 지남에 따라 성능 저하와 메모리 누수(Memory Leak)를 유발할 수 있으므로, `useEffect`에서 항상 정리 함수를 반환하여 컴포넌트가 언마운트될 때 리소스가 해제되도록 해야 합니다 [1, 4].
|
||||
|
||||
* **클래스형 컴포넌트의 라이프사이클 메서드와 에러 경계(Error Boundaries)**
|
||||
클래스형 컴포넌트는 고유한 라이프사이클 메서드를 가집니다. `static getDerivedStateFromError()` 또는 `componentDidCatch()` 중 하나 이상을 정의하면 해당 클래스 컴포넌트는 하위 트리의 에러를 포착하는 '에러 경계(Error Boundary)' 역할을 수행하게 됩니다 [2]. 에러 경계는 하위 컴포넌트 트리의 렌더링 중, 생성자 내부, 그리고 라이프사이클 메서드 내부에서 발생하는 에러를 포착합니다 [5]. 하위 컴포넌트의 `componentDidUpdate`와 같은 라이프사이클 메서드 안에서 에러가 발생하더라도, 이는 가장 가까운 에러 경계로 정상적으로 전파되어 애플리케이션 전체가 멈추는 것을 방지합니다 [6].
|
||||
|
||||
* **컴포넌트 언마운트 시 메모리 누수 예방**
|
||||
SPA(Single Page Application) 환경에서 컴포넌트 라이프사이클 주기를 이해하는 것은 메모리 누수 탐지 및 예방에 매우 중요합니다 [7]. 컴포넌트가 언마운트될 때 등록된 이벤트 리스너를 제거하지 않으면 참조가 계속 유지되어 가비지 컬렉션(Garbage Collection)이 이루어지지 않습니다 [3, 7]. 이를 방지하기 위해 React에서는 `useEffect`의 반환 함수에서 정리를 수행하고, Vue에서는 `beforeUnmount` 라이프사이클 단계에서 감시자(watchers)와 이벤트 리스너를 파괴하는 등 각 프레임워크의 라이프사이클에 맞춘 적절한 정리 패턴을 구현해야 합니다 [3].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[React Hooks]], [[useEffect]], [[Error Boundaries]], [[Memory Leaks]]
|
||||
- **Projects/Contexts:** [[Single Page Applications (SPAs)]], [[Frontend Performance Optimization]]
|
||||
- **Contradictions/Notes:** 제공된 소스에서는 라이프사이클의 모든 단계를 포괄적으로 설명하기보다는, 주로 함수형 컴포넌트의 마운트 해제 시 메모리 누수 방지(useEffect의 cleanup)와 클래스형 컴포넌트의 에러 핸들링(Error Boundaries) 맥락에서 라이프사이클의 특정 측면을 집중적으로 다루고 있습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,23 @@
|
||||
# [[Scalable React Architecture]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
확장 가능한 리액트 아키텍처(Scalable React Architecture)는 애플리케이션의 복잡성 증가, 팀의 확장, 장기적인 유지보수 요구를 원활하게 수용할 수 있도록 프론트엔드 시스템을 설계하는 방법론입니다 [1-4]. 단순한 파일 유형별 폴더 구성을 넘어 기능(Feature) 또는 도메인 기반의 구조인 기능 분할 설계(Feature-Sliced Design)를 채택하는 방향으로 진화해 왔습니다 [5, 6]. 이 아키텍처는 명시적인 경계 설정, 결합도 감소, 일관된 명명 규칙 적용 및 적절한 상태 관리를 통해 높은 성능과 개발 속도를 유지하는 것을 목표로 합니다 [3, 6-12].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **아키텍처의 필요성과 실패 요인:** 리액트 앱이 커질수록 비즈니스 로직이 UI 컴포넌트로 새어나가거나, 상태 소유권이 불분명해지고, 기능 간 암묵적인 의존성이 생기는 문제가 흔히 발생합니다 [2, 13]. 확장 가능한 아키텍처는 결합도(Coupling)를 낮추고 응집도(Cohesion)를 높이며, 모듈과 퍼블릭 API의 명확한 경계를 설정하여 인지 부하를 줄이고 안전한 성장을 가능하게 합니다 [3].
|
||||
* **폴더 구조의 진화 (유형 기반에서 기능 기반으로):** 컴포넌트, 훅, 서비스를 각각의 폴더로 모아두는 전통적인 파일 유형 기반 구조는 단일 기능을 수정할 때 여러 폴더를 오가야 하므로 대규모 확장에 불리합니다 [7, 14-16]. 2025년 기준의 모던 리액트 프로젝트는 연관된 컴포넌트, 훅, 로직, 타입을 하나의 도메인/기능 폴더 내에 배치하는 기능 기반(Feature-Based) 구조를 권장합니다 [6, 16, 17].
|
||||
* **기능 분할 설계 (Feature-Sliced Design, FSD):** FSD는 프론트엔드 애플리케이션을 위해 설계된 아키텍처 방법론으로, 코드를 기술적 유형이 아닌 범위(Scope)와 책임(Responsibility)에 따라 구성합니다 [5, 18, 19]. 앱(app) -> 페이지(pages) -> 위젯(widgets) -> 기능(features) -> 엔티티(entities) -> 공유(shared)로 이어지는 계층 모델을 가지며, 상위 계층이 하위 계층에만 의존할 수 있는 단방향 의존성 규칙을 엄격히 적용합니다 [8, 9, 18]. 또한 각 슬라이스는 단일 진입점(`index.ts`)만을 노출하는 '퍼블릭 API 규칙'을 통해 내부 구현을 캡슐화합니다 [20-22].
|
||||
* **클린 코드 및 SOLID 원칙 적용:** 리액트 컴포넌트의 유지보수성을 높이려면 SOLID, DRY, KISS, YAGNI와 같은 소프트웨어 공학 원칙이 필요합니다 [21, 23-26]. 예를 들어 단일 책임 원칙(SRP)에 따라 컴포넌트가 300줄을 넘어가면 여러 개의 작은 컴포넌트로 분리해야 하며, 반복되는 로직은 커스텀 훅으로 추출(DRY)하여 단순하게 유지(KISS)해야 합니다 [23, 25, 27, 28].
|
||||
* **상태 관리와 성능 최적화:** 확장 가능한 아키텍처에서는 상태를 지역 상태, 전역 애플리케이션 상태, 서버 캐시 상태 등으로 엄격히 구분합니다 [29, 30]. 자주 변경되는 상태를 기본 Context API로 관리하면 불필요한 리렌더링 폭풍(Re-render storm)이 발생할 수 있으므로, 상태 슬라이스를 선택(Selector)할 수 있는 Zustand나 대규모 팀에 적합한 Redux 같은 전문 도구를 사용하는 것이 성능에 유리합니다 [31-34]. 더불어 Vite의 `manualChunks`나 `React.lazy`를 이용한 코드 스플리팅을 통해 초기 번들 크기를 줄이는 것도 핵심 전략입니다 [35-38].
|
||||
* **명명 규칙 및 거버넌스(Governance):** 확장되는 팀 내 혼란을 막기 위해 엄격한 폴더 및 파일 명명 규칙이 적용됩니다. 리액트 컴포넌트는 PascalCase, 일반 파일/폴더는 OS 호환성을 위해 kebab-case, 훅과 유틸리티 함수는 camelCase를 사용합니다 [39-44]. 또한 ESLint, Prettier, Husky 같은 도구를 통해 아키텍처 규칙과 포맷팅을 CI/CD 파이프라인에서 자동 강제(Governance)합니다 [45, 46].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Feature-Sliced Design]], [[Clean Code and SOLID Principles]], [[Frontend Folder Structure]], [[React State Management]], [[Frontend Performance Optimization]]
|
||||
- **Projects/Contexts:** [[Bulletproof React]] (생산 환경에 적합한 단순하고 확장 가능한 리액트 아키텍처 베스트 프랙티스를 모아둔 오픈소스 레퍼런스 [10])
|
||||
- **Contradictions/Notes:**
|
||||
- 기능 기반 구조(Feature-Based Structure)가 확장성 측면에서 매우 권장되지만, 매우 작은 소규모 프로젝트나 초보자에게는 오버엔지니어링(Overkill)일 수 있으며 초기에는 플랫(Flat) 구조가 적합할 수 있습니다 [15, 47].
|
||||
- Context API는 추가 의존성 없이 상태를 공유할 수 있어 유용하지만, 자주 변경되는 데이터에 사용할 경우 성능이 심각하게 저하되므로 Zustand나 Redux로 대체해야 한다는 명확한 제약 사항이 여러 소스에서 강조됩니다 [31, 33, 34, 48].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,25 @@
|
||||
# [[Sentry/LogRocket Monitoring]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Sentry와 LogRocket은 프론트엔드 애플리케이션에서 발생하는 에러를 추적하고 사용자 세션을 모니터링하여 프로덕션 환경의 디버깅을 돕는 대표적인 클라우드 기반 모니터링 도구입니다 [1-3]. Sentry는 지능형 에러 그룹화와 에러 발생까지의 경로(Breadcrumb)를 추적하는 등 개발자 중심의 에러 관리에 탁월한 반면, LogRocket은 Redux 상태 변화와 전체 DOM을 포함하는 고해상도 세션 리플레이 기능에 특화되어 있습니다 [2, 4, 5]. 두 도구 모두 복잡한 분산 프론트엔드 시스템의 가시성(Observability)을 확보하고 신속하게 근본 원인을 파악하는 데 필수적인 역할을 합니다 [5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
**Sentry: 개발자 중심의 에러 트래커 (Developer-First Error Tracker)**
|
||||
* **핵심 기능:** Sentry의 가장 큰 강점은 '지능형 에러 그룹화(Intelligent error grouping)'입니다 [2]. 중복되는 에러의 홍수 속에서 유사한 에러를 자동으로 묶어 고유한 문제에 집중할 수 있게 해줍니다 [2, 5]. 또한 '이동 경로(Breadcrumb trail)' 기능을 통해 콘솔 로그, 네트워크 요청, 사용자 상호작용 등 에러 발생 전까지의 정확한 이벤트 시퀀스를 캡처합니다 [2].
|
||||
* **장단점:** 넉넉한 무료 티어를 제공하며 100개 이상의 SDK 통합을 지원하여 개발자 경험이 매우 뛰어납니다 [7]. NextJS 환경 기준 회원가입부터 첫 에러 캡처까지 약 8분밖에 걸리지 않을 정도로 설정이 직관적입니다 [8]. 반면 대규모 사용자 기반으로 확장 시 에러, 리플레이, 성능 모니터링 등에 대한 다중 미터링 요금제가 복잡해질 수 있으며, 세션 리플레이 기능은 전문 도구에 비해 성숙도가 낮습니다 [7]. 최근에는 Sentry MCP 기능을 도입하여 단순 에러 복사를 넘어 실제 프로덕션 컨텍스트를 기반으로 한 스마트 디버깅과 수정 제안 기능을 추가하고 있습니다 [9].
|
||||
|
||||
**LogRocket: 세션 리플레이 선구자 (The Session Replay Pioneer)**
|
||||
* **핵심 기능:** 단순한 에러 로깅을 넘어 모든 사용자 세션을 화면 녹화기처럼 기록합니다 [3]. 전체 DOM, Redux/Vuex 상태 변경, 헤더 및 응답이 포함된 네트워크 요청, 성능 지표까지 상세하게 캡처하여 복잡한 버그를 디버깅할 때 최고의 컨텍스트를 제공합니다 [4, 5].
|
||||
* **장단점:** 고해상도 세션 리플레이와 상태(State) 검사 기능은 독보적이지만, 기본적으로 "모든 것을 캡처"하는 방식을 취하고 있어 민감한 데이터를 가리는(Redact) 프라이버시 설정 작업에 많은 시간이 소요됩니다 [4, 10]. 또한 Sentry에 비해 애플리케이션 번들 크기에 미치는 성능 영향이 더 크고, 대규모 사용 시 월 69달러에서 수천 달러까지 비용이 비싸지는 단점이 있습니다 [10, 11].
|
||||
|
||||
**도입 시 성능 및 개인정보 보호 고려사항**
|
||||
* 로깅 도구를 선택할 때는 단순히 스티커 가격뿐만 아니라 번들 크기로 인한 성능 저하(추가 로드 시간 발생)와 프라이버시 설정에 들어가는 팀의 시간을 총 비용으로 고려해야 합니다 [12, 13].
|
||||
* 민감한 데이터를 자동으로 마스킹하는 개인정보 보호 기능이 기본적으로 적용되는 도구를 선택하는 것이 프라이버시 규제가 강화되는 현재 환경에서 필수적입니다 [12].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Error Handling]], [[Performance Optimization]], [[Observability]], [[Debugging Frontend Applications]]
|
||||
- **Projects/Contexts:** [[Scalable Frontend Systems]], [[Production Monitoring]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 Sentry는 설정이 빠르고 초기 비용(무료 티어) 면에서 단순 로깅 요구사항에 가장 적합한 옵션으로 꼽히는 반면, LogRocket은 세션과 상태에 대한 압도적인 컨텍스트를 제공하지만 번들 크기에 미치는 성능 악영향과 기본 설정에서의 프라이버시 침해 우려(모든 것 캡처)라는 상반된 트레이드오프를 가지고 있습니다 [7, 10, 12, 14].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
Reference in New Issue
Block a user