docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
Antigravity Agent
@@ -1,5 +1,5 @@
|
||||
# Index: Decisions
|
||||
|
||||
## 📁 Subcategories
|
||||
- [[Skybound/Index|Skybound]]
|
||||
- Skybound
|
||||
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
id: 550e8400-e29b-41d4-a716-446655440006
|
||||
category: "[[10_Wiki/Decisions/Skybound]]"
|
||||
category: "10_Wiki/Decisions/Skybound"
|
||||
confidence_score: 0.96
|
||||
tags: [skybound, game-balance, combat, buff]
|
||||
last_reinforced: 2026-04-21
|
||||
---
|
||||
|
||||
# [[플레이어 전투 밸런스 상향]]
|
||||
# 플레이어 전투 밸런스 상향
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 스테이지 1의 몰입도 향상을 위해 플레이어 기체의 기본 연사력을 20% 상향 조정하여 전투 리듬을 개선함.
|
||||
@@ -23,6 +23,6 @@ last_reinforced: 2026-04-21
|
||||
- **정책 변화:** 전투 밸런스 수정 시 반드시 프레임 단위의 수치를 기록하고 비교할 것.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Decisions/Skybound]]
|
||||
- **Related:** [[10_Wiki/Projects/Skybound/HUD_UI_Refinement]]
|
||||
- **Raw Source:** [[00_Raw/2026-04-21-Skybound_Player_Combat_Buff]]
|
||||
- **Parent:** 10_Wiki/Decisions/Skybound
|
||||
- **Related:** 10_Wiki/Projects/Skybound/HUD_UI_Refinement
|
||||
- **Raw Source:** 00_Raw/2026-04-21-Skybound_Player_Combat_Buff
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
id: 550e8400-e29b-41d4-a716-446655440002
|
||||
category: "[[10_Wiki/Decisions/Skybound]]"
|
||||
category: "10_Wiki/Decisions/Skybound"
|
||||
confidence_score: 1.0
|
||||
tags: [skybound, typesystem, maintenance]
|
||||
last_reinforced: 2026-04-21
|
||||
---
|
||||
|
||||
# [[Skybound 프레임 타입 복구]]
|
||||
# Skybound 프레임 타입 복구
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 엔진 루프의 시간축 참조를 위한 `frame` 속성을 인터페이스에 명시하여 정적 타입 무결성을 복구함.
|
||||
@@ -23,6 +23,6 @@ last_reinforced: 2026-04-21
|
||||
- **정책 변화:** 핵심 엔진 상태 속성은 누락 시 즉시 반려(Veto) 대상임.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Decisions/Skybound]]
|
||||
- **Related:** [[10_Wiki/Projects/Skybound/Architecture_Refactor]]
|
||||
- **Raw Source:** [[00_Raw/2026-04-21-Skybound_Frame_Type_Restoration]]
|
||||
- **Parent:** 10_Wiki/Decisions/Skybound
|
||||
- **Related:** 10_Wiki/Projects/Skybound/Architecture_Refactor
|
||||
- **Raw Source:** 00_Raw/2026-04-21-Skybound_Frame_Type_Restoration
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
id: 550e8400-e29b-41d4-a716-446655440004
|
||||
category: "[[10_Wiki/Decisions/Skybound]]"
|
||||
category: "10_Wiki/Decisions/Skybound"
|
||||
confidence_score: 0.99
|
||||
tags: [skybound, typescript, stability, code-quality]
|
||||
last_reinforced: 2026-04-21
|
||||
---
|
||||
|
||||
# [[Skybound IDE 안정성 및 타입 보정]]
|
||||
# Skybound IDE 안정성 및 타입 보정
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 엄격한 타입 매칭과 필수 속성 초기화를 통해 런타임 잠재 에러를 사전에 차단하고 개발자 생산성을 향상함.
|
||||
@@ -23,6 +23,6 @@ last_reinforced: 2026-04-21
|
||||
- **정책 변화:** 모든 유틸리티 함수 반환값은 Partial을 지양하고 Full-spec을 따를 것.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Decisions/Skybound]]
|
||||
- **Related:** [[10_Wiki/Projects/Skybound/Architecture_Refactor]]
|
||||
- **Raw Source:** [[00_Raw/2026-04-21-Skybound_IDE_Problems_Fix]]
|
||||
- **Parent:** 10_Wiki/Decisions/Skybound
|
||||
- **Related:** 10_Wiki/Projects/Skybound/Architecture_Refactor
|
||||
- **Raw Source:** 00_Raw/2026-04-21-Skybound_IDE_Problems_Fix
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Index: Decisions > Skybound
|
||||
|
||||
## 📝 Documents
|
||||
- [[Combat_Balance_Buff]]
|
||||
- [[Frame_Type_Restoration]]
|
||||
- [[IDE_Stability_Fix]]
|
||||
- [[Combat_Balance_Buff|Combat_Balance_Buff]]
|
||||
- [[Frame_Type_Restoration|Frame_Type_Restoration]]
|
||||
- [[IDE_Stability_Fix|IDE_Stability_Fix]]
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Code Splitting]]
|
||||
# [[Code Splitting|Code Splitting]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
큰 자바스크립트 번들을 더 작은 청크(chunk) 단위로 나누어 사용자가 필요로 할 때(on demand) 로드하는 프로세스입니다 [1, 2]. 모든 애플리케이션 코드를 초기에 한 번에 다운로드하는 대신, 필요한 파일만 먼저 불러오게 하여 초기 번들 크기를 극적으로 줄일 수 있습니다 [2, 3]. 결과적으로 초기 페이지 로드 속도를 향상시키고, 애플리케이션의 체감 성능을 개선하는 핵심적인 프론트엔드 최적화 기법입니다 [1, 4].
|
||||
@@ -19,18 +19,18 @@
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처/기반 기술]
|
||||
- [[Lazy Loading]]
|
||||
- [[Lazy Loading|Lazy Loading]]
|
||||
- 연결 이유: 코드 분할이 번들을 쪼개는 행위라면, 지연 로딩(Lazy Loading)은 그 쪼개진 코드를 필요 시점에 로드하는 기술적 방법론입니다 [2, 3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 분할된 코드가 언제 브라우저로 전송되고 애플리케이션에 병합되는지 이해할 수 있습니다 [8].
|
||||
- [[Core Web Vitals]]
|
||||
- [[Core Web Vitals|Core Web Vitals]]
|
||||
- 연결 이유: 코드 분할을 적용하는 주된 성능적 목적은 초기 자바스크립트 실행을 최소화하여 LCP(Largest Contentful Paint)와 INP(Interaction to Next Paint) 같은 핵심 웹 지표를 향상시키는 데 있습니다 [1, 8, 14].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 최적화 결과가 실제 사용자의 체감 성능 및 페이지 측정 지표에 어떻게 긍정적 영향을 주는지 평가할 수 있습니다 [15].
|
||||
|
||||
#### [구현/활용 도구]
|
||||
- [[React.lazy() and Suspense]]
|
||||
- React.lazy() and Suspense
|
||||
- 연결 이유: React 애플리케이션에서 컴포넌트 레벨 및 라우트 레벨의 동적 코드 분할을 구현하기 위해 사용하는 공식 API입니다 [6, 8].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 동적 임포트 처리 과정에서의 비동기 UI 렌더링 흐름과 예외(지연) 처리 방식을 배울 수 있습니다 [5].
|
||||
- [[Vite (Rollup)]]
|
||||
- Vite (Rollup)
|
||||
- 연결 이유: 개발 및 프로덕션 환경에서 자바스크립트 애플리케이션을 번들링하고 실제 물리적인 청크 파일들로 분리해 내는 도구입니다 [9, 11].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 번들러의 `manualChunks` 설정을 통해 어떻게 벤더 라이브러리와 애플리케이션 코드를 효율적으로 나누어 브라우저 캐싱을 활용할 수 있는지 이해할 수 있습니다 [5].
|
||||
|
||||
@@ -49,9 +49,9 @@
|
||||
- **My Project Relevance:** 프로젝트 규모가 커짐에 따라 메인 자바스크립트 번들이 수 메가바이트 단위로 무거워져 모바일 기기 등에서 로딩 속도 저하 현상이 보일 경우, 즉각적으로 라우트 기반 코드 분할과 차트/에디터 등 무거운 UI의 지연 로딩을 도입하여 LCP 문제를 해결할 수 있습니다 [3, 14, 16].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Tree Shaking]]
|
||||
- [[Tree Shaking (번들 크기 최적화)|Tree Shaking]]
|
||||
- 확장 방향: 코드 분할이 필요한 코드를 '쪼개어' 가져오는 방식이라면, 트리 쉐이킹은 사용되지 않는 죽은 코드(Dead Code) 자체를 번들에서 '제거'하여 초기 번들 크기를 줄이는 상호 보완적인 최적화 기법입니다 [17, 18].
|
||||
- [[Server Components (Next.js)]]
|
||||
- Server Components (Next.js)
|
||||
- 확장 방향: 클라이언트 사이드의 코드 분할에서 더 나아가, 아예 정적인 UI 렌더링을 서버에서 처리하여 클라이언트로 보내는 자바스크립트 번들의 양 자체를 획기적으로 줄이거나 제거하는 최신 아키텍처 접근법입니다 [19-21].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Concurrent Features]]
|
||||
# [[Concurrent Features|Concurrent Features]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Concurrent Features는 React 18부터 도입된 기능으로, 렌더링 작업을 일시 중지(pause), 중단(interrupt), 재개(resume)할 수 있게 해주는 기능입니다 [1]. 이를 통해 중요한 사용자 상호작용(클릭, 타이핑 등)의 우선순위를 높이고, 상대적으로 느린 업데이트(대용량 필터링 등)를 지연시킬 수 있습니다 [1]. 결과적으로 앱의 실제 연산 속도 자체를 마법처럼 빠르게 만드는 것은 아니지만, 인지되는 속도(perceived speed)를 최적화하여 사용자 인터페이스를 반응성 있게 유지합니다 [2].
|
||||
@@ -19,16 +19,16 @@ Concurrent Features는 React 18부터 도입된 기능으로, 렌더링 작업
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술]
|
||||
- [[useTransition]]
|
||||
- [[useTransition|useTransition]]
|
||||
- 연결 이유: 상태 업데이트를 긴급하지 않은 것으로 표시하여 지연시킬 수 있는 Concurrent Feature의 핵심 요소입니다 [3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: React가 렌더링 우선순위를 조정하여 사용자 입력 반응성을 잃지 않게 유지하는 구체적인 메커니즘.
|
||||
|
||||
- [[useDeferredValue]]
|
||||
- [[useDeferredValue|useDeferredValue]]
|
||||
- 연결 이유: 비용이 큰 파생 데이터의 렌더링 반영 시점을 지연시켜 UI 끊김을 막는 또 다른 주요 요소입니다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태의 업데이트 시점이 아닌, 계산된 값을 읽어 들이는 시점을 분리하는 최적화 전략.
|
||||
|
||||
#### [관계 유형 B: 구현/활용 도구]
|
||||
- [[Suspense]]
|
||||
- Suspense
|
||||
- 연결 이유: Concurrent Feature(특히 `useTransition`)와 결합하여 무거운 렌더링이나 데이터가 로드되는 동안 Fallback UI를 유연하게 표시하는 데 사용됩니다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비동기 로딩 상태에서 사용자 경험(UX)을 부드럽게 설계하는 선언적 UI 패턴.
|
||||
|
||||
@@ -47,9 +47,9 @@ Concurrent Features는 React 18부터 도입된 기능으로, 렌더링 작업
|
||||
- **My Project Relevance:** 검색 필터가 많은 대시보드나 실시간 데이터 시각화 차트를 구축할 때 UI 스레드가 멈추는 것을 방지하여 사용자 경험을 크게 개선하는 데 직접적으로 적용될 수 있습니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Server Components]]
|
||||
- [[Server Components|Server Components]]
|
||||
- 확장 방향: 클라이언트에서 렌더링을 지연시키거나 최적화하는 것을 넘어, 무거운 렌더링 작업 자체를 서버로 완전히 옮겨 클라이언트의 자바스크립트 번들 크기와 실행 부담을 근본적으로 줄이는 방법론 탐구 [6, 7].
|
||||
- [[Code Splitting & Lazy Loading]]
|
||||
- Code Splitting & Lazy Loading
|
||||
- 확장 방향: 화면의 렌더링 과정을 매끄럽게 하는 것을 넘어, 초기 애플리케이션 로딩 시 네트워크를 통해 다운로드하는 코드의 양 자체를 분할하여 초기 응답성(Time to Interactive)을 향상시키는 전략 탐구 [8, 9].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Concurrent Rendering in React 18+]]
|
||||
# [[Concurrent Rendering in React 18+|Concurrent Rendering in React 18+]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 18+의 동시성 렌더링(Concurrent Rendering)은 React가 렌더링 작업을 일시 중지, 중단 및 재개할 수 있도록 하는 강력한 기능입니다 [1]. 이를 통해 개발자는 업데이트 발생 시기와 방식을 세밀하게 제어할 수 있으며, 사용자의 상호작용성을 저하시키지 않으면서도 화면이 멈추지 않는 더 부드럽고 반응성 높은 애플리케이션을 구축할 수 있습니다 [1, 2].
|
||||
@@ -22,15 +22,15 @@ React 18+의 동시성 렌더링(Concurrent Rendering)은 React가 렌더링 작
|
||||
|
||||
### Related Concepts
|
||||
|
||||
- [[useTransition]]
|
||||
- [[useTransition|useTransition]]
|
||||
- 연결 이유: 동시성 렌더링 환경에서 특정 상태 업데이트를 '긴급하지 않은 작업'으로 명시적으로 분류하기 위해 사용되는 핵심 훅입니다 [3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 업데이트의 우선순위를 낮추어 사용자 입력에 대한 메인 스레드 차단을 방지하는 구체적인 제어 방법.
|
||||
|
||||
- [[useDeferredValue]]
|
||||
- [[useDeferredValue|useDeferredValue]]
|
||||
- 연결 이유: 연산 비용이 높은 값의 화면 적용 시점을 늦추어 UI의 즉각적인 체감 반응성을 향상시키는 동시성 기능이기 때문입니다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 사용자 입력(타이핑 등)의 즉각적인 반영과 무거운 파생 데이터 렌더링 간의 처리 시점을 분리하는 메커니즘.
|
||||
|
||||
- [[Suspense]]
|
||||
- Suspense
|
||||
- 연결 이유: 동시성 훅(`useTransition` 등)과 결합하여 비동기 처리나 지연된 렌더링이 완료되기 전까지 자연스러운 대체 UI(Fallback UI)를 표시하는 역할을 합니다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비동기 데이터 로딩 과정에서 동시성 렌더링을 활용한 부드러운 사용자 경험(UX) 설계 방식.
|
||||
|
||||
@@ -52,10 +52,10 @@ React 18+의 동시성 렌더링(Concurrent Rendering)은 React가 렌더링 작
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[React Server Components]]
|
||||
- [[React Server Components|React Server Components]]
|
||||
- 확장 방향: 동시성 렌더링과 함께 Next.js App Router 환경의 핵심 성능 최적화 축을 이루며, 클라이언트 측 자바스크립트 번들을 획기적으로 줄여주는 서버 컴포넌트의 렌더링 원리 탐구 [5, 6].
|
||||
|
||||
- [[Core Web Vitals (INP/TBT)]]
|
||||
- Core Web Vitals (INP/TBT)
|
||||
- 확장 방향: 동시성 렌더링 기능 적용이 웹의 핵심 반응성 지표인 INP 및 TBT를 어떻게 개선하는지 실제 성능 측정 툴(Chrome DevTools, Lighthouse) 데이터와 연계하여 조사 [7-9].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Context API]]
|
||||
# [[Context API|Context API]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Context API는 React에 내장된 상태 공유 솔루션으로, 컴포넌트 트리의 모든 레벨을 통해 명시적으로 props를 전달하지 않고도 데이터를 전송할 수 있게 해주는 기능입니다 [1, 2]. 이는 독립적인 상태 관리 도구라기보다는 데이터를 전달하는 브로드캐스트 전송 메커니즘에 가깝습니다 [3, 4]. 주로 테마, 다국어 설정 등 변경이 거의 없는 정적인 데이터를 전역적으로 공유할 때 적합하게 사용됩니다 [5, 6].
|
||||
@@ -12,13 +12,13 @@ Context API는 React에 내장된 상태 공유 솔루션으로, 컴포넌트
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[Prop Drilling]]
|
||||
- [[Prop Drilling|Prop Drilling]]
|
||||
- 연결 이유: 부모 컴포넌트에서 깊게 중첩된 자식 컴포넌트로 데이터를 전달하기 위해 불필요한 중간 컴포넌트들을 거쳐야 하는 패턴입니다 [2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Context API가 탄생하게 된 근본적인 배경과, 데이터를 어떻게 트리 아래로 "건너뛰어" 전달하는지 그 목적을 이해할 수 있습니다 [2, 19].
|
||||
- [[useContext]]
|
||||
- useContext
|
||||
- 연결 이유: Context API의 Provider가 제공하는 브로드캐스트 값을 읽기 위해 개별 컴포넌트 내부에서 호출하는 React의 내장 훅입니다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 구독(Subscription)이 발생하는 정확한 지점과, 값이 변경될 때 어떤 컴포넌트에서 리렌더링이 트리거되는지 렌더링 동작 원리를 파악할 수 있습니다 [8].
|
||||
- [[Zustand]]
|
||||
- Zustand
|
||||
- 연결 이유: Context API의 리렌더링 한계와 보일러플레이트를 극복하기 위해 자주 비교되고 채택되는 경량 상태 관리 라이브러리입니다 [20, 21].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Zustand의 'Selector 패턴'이 어떻게 특정 상태 슬라이스만 구독하게 하여 Context API의 "전체 리렌더링" 문제를 해결하는지 성능 최적화의 차이를 비교할 수 있습니다 [8, 10].
|
||||
|
||||
@@ -37,9 +37,9 @@ Context API는 React에 내장된 상태 공유 솔루션으로, 컴포넌트
|
||||
- **My Project Relevance:** 기존 코드베이스에 'Global Context' 안티 패턴(모든 상태를 한 곳에 몰아넣은 형태)이 존재하지 않는지 점검하고 [11], 렌더링 병목이 있는 경우 `useMemo`, `useCallback`과 함께 Context를 책임별로 분할하는 리팩토링 목표와 직접적으로 연관됩니다 [1, 12].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[React.memo]]
|
||||
- React.memo
|
||||
- 확장 방향: Context API에 의해 발생하는 불필요한 하위 컴포넌트 렌더링을 방지하기 위한 얕은 비교(Shallow Compare) 최적화 도구로, 렌더링 성능 최적화(Performance Optimization) 기법 전반으로의 이해를 확장합니다 [28, 29].
|
||||
- [[Concurrent Rendering]]
|
||||
- [[Concurrent Rendering|Concurrent Rendering]]
|
||||
- 확장 방향: React 18의 동시성 렌더링 기능(`useTransition`, `useDeferredValue`)을 통해 무거운 컴포넌트 렌더링을 어떻게 지연시키고 애플리케이션의 반응성을 개선할 수 있는지 상태 업데이트 흐름으로 탐구를 확장합니다 [6, 30].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Debugging Frontend Applications]]
|
||||
# [[Debugging Frontend Applications|Debugging Frontend Applications]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
프론트엔드 디버깅은 웹 애플리케이션에서 발생하는 자바스크립트 런타임 에러, 메모리 누수, 그리고 불필요한 리렌더링과 같은 성능 저하 요인을 식별하고 해결하는 과정입니다 [1-3]. Chrome DevTools와 같은 브라우저 내장 도구부터 React DevTools, 그리고 Sentry나 LogRocket과 같은 프로덕션 클라우드 로깅 도구를 활용하여 문제의 근본 원인을 추적합니다 [4-7]. 효과적인 디버깅 전략과 에러 핸들링 아키텍처는 애플리케이션의 안정성을 보장하고 사용자 경험을 최적화하는 데 필수적입니다 [8-10].
|
||||
@@ -30,20 +30,20 @@
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (브라우저 및 성능 분석 기반 도구)]
|
||||
- [[Chrome DevTools]]
|
||||
- [[Chrome DevTools|Chrome DevTools]]
|
||||
- 연결 이유: 자바스크립트 힙 메모리와 DOM의 상태를 프로파일링하여 메모리 누수를 진단하는 가장 근본적인 프론트엔드 디버깅 도구이기 때문입니다 [6, 34].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저의 가비지 컬렉션(GC) 동작 원리, 분리된 DOM 노드(Detached DOM nodes)와 클로저(Closure)가 메모리를 점유하여 성능을 저하시키는 원리를 시각적으로 이해할 수 있습니다 [2, 14, 17, 35].
|
||||
|
||||
#### [관계 유형 B (React 컴포넌트 및 에러 핸들링 도구)]
|
||||
- [[React Error Boundaries]]
|
||||
- React Error Boundaries
|
||||
- 연결 이유: 렌더링 및 생명주기 도중 발생하는 컴포넌트 런타임 에러를 디버깅/핸들링하여 "하얀 화면(White screen of death)"을 막아주는 React만의 고유한 방어적 디버깅 패턴입니다 [1, 36].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 선언적(Declarative) UI 트리의 에러 전파 방식과, 명령형(Imperative) 이벤트 핸들러에서 `try-catch`를 사용해야 하는 아키텍처적 차이를 명확히 구분할 수 있습니다 [32].
|
||||
- [[React DevTools Profiler]]
|
||||
- [[React DevTools Profiler|React DevTools Profiler]]
|
||||
- 연결 이유: 어떤 컴포넌트가 언제, 왜 리렌더링되었는지를 측정(Profiling)하여 렌더링 병목 현상을 디버깅하는 필수 도구입니다 [7, 37].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: React의 렌더링 라이프사이클, 불필요한 상태 및 props 변경 추적, 그리고 React Compiler 도입 전후의 렌더링 패스(Render pass) 차이를 검증하는 방법을 배울 수 있습니다 [7, 38].
|
||||
|
||||
#### [관계 유형 C (프로덕션 환경 관측성 도구)]
|
||||
- [[Session Replay & Distributed Tracing]]
|
||||
- Session Replay & Distributed Tracing
|
||||
- 연결 이유: 로컬에서 재현이 불가능한 프로덕션 에러를 추적하기 위해 사용자의 브라우저 상호작용(Sentry, LogRocket)과 백엔드 데이터 흐름(Datadog)을 연결하여 디버깅 단서를 찾는 핵심 개념입니다 [5, 24, 39].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 풀스택 환경에서의 엔드투엔드(End-to-End) 성능 모니터링 한계와 프론트엔드 에러가 백엔드 서비스에 미치는 연관 관계를 깊게 이해할 수 있습니다 [24, 25].
|
||||
|
||||
@@ -65,9 +65,9 @@
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[State Management Architecture]]
|
||||
- State Management Architecture
|
||||
- 확장 방향: 상태 관리 라이브러리(Redux, Zustand, Context API 등)의 아키텍처적 선택이 상태 변화 추적성과 DevTools 디버깅 퀄리티에 어떤 영향을 미치는지 분석 [21, 22, 49].
|
||||
- [[Frontend Performance Optimization]]
|
||||
- [[프론트엔드 성능 최적화(Frontend Performance Optimization)|Frontend Performance Optimization]]
|
||||
- 확장 방향: 디버깅을 통해 발견한 메모리 누수와 불필요한 컴포넌트 렌더링(Re-renders) 문제를 실질적인 성능 최적화 기법(가상화, 코드 스플리팅)으로 해결하여 Core Web Vitals를 개선하는 방향 [20, 50].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Engineering Scalable Frontend Systems]]
|
||||
# [[Engineering Scalable Frontend Systems|Engineering Scalable Frontend Systems]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
확장 가능한 프론트엔드 시스템(Engineering Scalable Frontend Systems)은 단순한 스크립트 실행을 넘어 유지보수성, 고성능, 견고성을 갖춘 분산 소프트웨어 아키텍처를 구축하는 것을 의미합니다 [1]. 이는 기술적 파일 기반 폴더 구조에서 기능 중심(Feature-Based) 및 도메인 기반 설계로의 전환을 요구하며, 엄격한 코드 컨벤션과 거버넌스를 동반합니다 [2, 3]. 또한 프론트엔드 개발에 SOLID와 같은 소프트웨어 공학 원칙을 결합하고, 서버/클라이언트 상태의 분리, 그리고 빌드 타임 및 런타임 성능 최적화를 통해 예측 가능한 성장을 가능하게 합니다 [1, 4, 5].
|
||||
@@ -34,26 +34,26 @@
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처 및 시스템 구조 (Architecture & Structural Design)]
|
||||
* `[[Feature-Sliced Design (FSD)]]`
|
||||
* `[[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD)]]`
|
||||
* 연결 이유: 현대 프론트엔드의 모듈화 및 확장성을 해결하기 위해 널리 채택되는 아키텍처 방법론의 핵심이기 때문입니다 [9, 10].
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비즈니스 도메인 기반의 코드 분할, 엄격한 단방향 의존성 규칙 적용 방법, 그리고 퍼블릭 API를 통한 모듈 캡슐화 원리 [4, 8, 50].
|
||||
* `[[Error Boundaries]]`
|
||||
* `[[Error Boundaries|Error Boundaries]]`
|
||||
* 연결 이유: 부분적인 UI 런타임 에러가 시스템 전체의 장애(White screen of death)로 확산되는 것을 방지하는 구조적 안전 장치이기 때문입니다 [33, 34].
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 렌더링 트리에서 컴포넌트 결함을 격리하는 원리와 시스템 복원력을 높이는 에러 처리 전략 [33, 35].
|
||||
|
||||
#### [관계 유형 B: 상태 관리 패러다임 (State Management Paradigms)]
|
||||
* `[[Zustand vs Context API]]`
|
||||
* `Zustand vs Context API`
|
||||
* 연결 이유: 전역 상태 관리에서 성능과 확장성을 결정짓는 가장 빈번한 아키텍처 결정 지점이기 때문입니다 [5, 19].
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: Context API의 브로드캐스트 렌더링 문제점과 이를 해결하기 위한 Zustand의 구독/선택자(Selector) 기반 렌더링 최적화 기법 [19, 20, 51].
|
||||
* `[[TanStack Query (React Query)]]`
|
||||
* `TanStack Query (React Query)`
|
||||
* 연결 이유: 클라이언트 상태와 서버 상태(Server State)를 구조적으로 분리하여 API 데이터 처리의 병목을 없애주기 때문입니다 [18, 22].
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 데이터 캐싱, 백그라운드 동기화 및 API 계층의 관심사 분리(Separation of Concerns) [18, 22].
|
||||
|
||||
#### [관계 유형 C: 성능 및 빌드 최적화 (Performance & Build Optimization)]
|
||||
* `[[React Compiler]]`
|
||||
* `[[React Compiler|React Compiler]]`
|
||||
* 연결 이유: 수동 메모이제이션의 복잡성을 줄이고 빌드 타임에 컴포넌트 렌더링 성능을 자동으로 최적화하는 최신 핵심 도구이기 때문입니다 [25, 28, 29].
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 선언적 UI 프레임워크에서의 빌드 타임 최적화 한계 및 React의 규칙(Rules of React)이 강제하는 불변성의 중요성 [52, 53].
|
||||
* `[[Code Splitting & Lazy Loading]]`
|
||||
* `Code Splitting & Lazy Loading`
|
||||
* 연결 이유: 초기 로드(First Paint) 속도 향상과 JavaScript 번들 크기를 제어하는 확장 가능한 시스템의 필수 성능 전략이기 때문입니다 [30, 31, 54].
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: Vite나 Webpack 같은 번들러 환경에서 동적 임포트를 통한 라우트 단위 분할 및 무거운 벤더 청크(`manualChunks`)의 캐싱 분리 전략 [26, 27, 31].
|
||||
|
||||
@@ -75,9 +75,9 @@
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
* `[[Core Web Vitals]]`
|
||||
* `[[Core Web Vitals|Core Web Vitals]]`
|
||||
* 확장 방향: LCP(Largest Contentful Paint), INP(Interaction to Next Paint), CLS(Cumulative Layout Shift) 등 구글이 정의한 사용자 경험 중심의 성능 측정 지표를 이해하고, 앞서 다룬 코드 스플리팅, 레이지 로딩, 렌더링 최적화 기법이 실제 사용자 체감 속도 향상에 어떻게 직결되는지 심층 분석하는 방향으로 연구할 수 있습니다 [23, 60, 61].
|
||||
* `[[Git Branching Strategies & CI/CD Governance]]`
|
||||
* `Git Branching Strategies & CI/CD Governance`
|
||||
* 확장 방향: 복잡한 프론트엔드 시스템을 다수의 개발자가 협업하여 구축할 때 충돌을 최소화하고 릴리스 안정성을 높이기 위한 GitHub Flow, Trunk-Based Development 등의 브랜칭 전략과, ESLint/Prettier 자동화, Conventional Commits를 활용한 배포 파이프라인(CI/CD) 통제 방법을 확장해서 조사할 수 있습니다 [62-64].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Folder Structure Best Practices]]
|
||||
# [[Folder Structure Best Practices|Folder Structure Best Practices]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 등 프론트엔드 프로젝트에서 코드의 유지보수성, 확장성, 그리고 협업 효율성을 높이기 위해 파일과 디렉터리를 체계적으로 구성하는 방법론입니다 [1]. 현대적인 애플리케이션에서는 과거의 파일 유형 기반(유형별 분류) 구조에서 벗어나, 기능(Feature)이나 도메인 중심으로 관련된 로직을 묶는 하이브리드 또는 기능 기반 방식이 모범 사례로 권장됩니다 [2, 3]. 이를 통해 UI, 비즈니스 로직, 상태 관리 등의 관심사를 명확히 분리하고 프로젝트가 커짐에 따라 발생하는 기술 부채를 최소화할 수 있습니다 [4].
|
||||
@@ -33,15 +33,15 @@ React 등 프론트엔드 프로젝트에서 코드의 유지보수성, 확장
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[Feature-Sliced Design]]
|
||||
- [[Feature-Sliced Design|Feature-Sliced Design]]
|
||||
- 연결 이유: 대규모 React 애플리케이션의 폴더 구조를 구축하기 위해 고안된 전문적인 프론트엔드 아키텍처 방법론이기 때문입니다 [21].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 폴더 간의 단방향 의존성 규칙과 각 폴더(Layer, Slice, Segment)가 담당해야 하는 역할의 엄격한 분리 방식 [22, 28].
|
||||
|
||||
- [[Separation of Concerns]] (관심사의 분리)
|
||||
- [[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]] (관심사의 분리)
|
||||
- 연결 이유: 폴더 구조를 설계하는 근본적인 목적이 UI 렌더링, 전역 상태 관리, 데이터 통신(API) 등의 책임을 각기 다른 위치로 분리하는 데 있기 때문입니다 [4, 29].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `services/`, `store/`, `components/` 등의 폴더를 분리하여 단일 책임 원칙(SRP)을 프론트엔드 아키텍처 전반에 적용하는 방법 [4, 30].
|
||||
|
||||
- [[Naming Conventions]] (명명 규칙)
|
||||
- [[Naming Conventions|Naming Conventions]] (명명 규칙)
|
||||
- 연결 이유: 일관된 폴더 및 파일 명명 규칙(예: 폴더명은 kebab-case, 컴포넌트는 PascalCase)은 폴더 구조 내에서 파일을 예측 가능하게 찾고 충돌을 방지하는 핵심 규칙이기 때문입니다 [31-33].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 다양한 운영체제와 CI/CD 파이프라인에서 빌드 에러를 방지하고 팀 내 코드 가독성을 유지하는 방법 [34, 35].
|
||||
|
||||
@@ -60,9 +60,9 @@ React 등 프론트엔드 프로젝트에서 코드의 유지보수성, 확장
|
||||
- **My Project Relevance:** 현재 진행 중이거나 리팩토링해야 할 React 코드베이스에서, 거대해진 `components/` 폴더를 도메인 단위의 `features/` 폴더로 나누고 재사용 불가 로직들을 분리하는 데 직접적으로 적용됩니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[State Management]]
|
||||
- [[상태 관리(State Management)|State Management]]
|
||||
- 확장 방향: 전역 상태(Global State)와 로컬 상태(Local State)를 어디에 보관해야 하는지, Zustand와 같은 도구가 `store/` 폴더의 구조를 어떻게 단순화하는지 확장하여 조사할 수 있습니다.
|
||||
- [[Code Splitting]] (코드 스플리팅)
|
||||
- [[Code Splitting|Code Splitting]] (코드 스플리팅)
|
||||
- 확장 방향: 라우트 혹은 폴더(Feature) 단위로 코드 스플리팅과 지연 로딩(Lazy Loading)을 적용하여 초기 번들 크기를 줄이고 성능을 최적화하는 전략과 연결됩니다.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Frontend Performance Debugging]]
|
||||
# [[Frontend Performance Debugging|Frontend Performance Debugging]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
프론트엔드 성능 디버깅(Frontend Performance Debugging)은 웹 애플리케이션의 메모리 누수, 불필요한 리렌더링, 잦은 가비지 컬렉션 등으로 인해 발생하는 성능 저하와 응답 지연을 식별하고 해결하는 과정입니다 [1-3]. 개발자는 브라우저의 내장 개발자 도구(Chrome DevTools)를 활용해 메모리 상태와 컴포넌트 렌더링 비용을 로컬에서 분석합니다 [4, 5]. 더 나아가 프로덕션 환경에서는 클라우드 기반 로깅 및 모니터링 도구를 사용하여 실제 사용자의 세션과 에러를 추적함으로써 복잡한 성능 병목의 근본 원인을 파악합니다 [6-8].
|
||||
@@ -25,23 +25,23 @@ React 애플리케이션에서는 상태(State), 프로퍼티(Props), 컨텍스
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (로컬 디버깅 및 분석 도구)]
|
||||
- [[Chrome DevTools Memory Profiler]]
|
||||
- Chrome DevTools Memory Profiler
|
||||
- 연결 이유: 자바스크립트 애플리케이션의 메모리 누수와 객체 보존 상태를 프로파일링하는 브라우저 내장 도구.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Heap Snapshots 비교, Allocation Timeline을 통한 메모리 할당 추적, Detached DOM tree 파악 기법 [9, 12, 33].
|
||||
- [[React DevTools Profiler]]
|
||||
- [[React DevTools Profiler|React DevTools Profiler]]
|
||||
- 연결 이유: React 특유의 렌더링 사이클과 성능 병목을 시각화하는 핵심 도구.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트 렌더링 소요 시간, 렌더링 발생 원인(Props/State 변경 여부 판별) [5, 14].
|
||||
|
||||
#### [관계 유형 B (프로덕션 관측성 및 모니터링)]
|
||||
- [[Frontend Cloud Logging Tools]]
|
||||
- Frontend Cloud Logging Tools
|
||||
- 연결 이유: Sentry, LogRocket, Datadog RUM, SigNoz 등 배포 이후 발생하는 성능 저하와 버그를 추적하는 플랫폼.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프로덕션 레벨에서의 세션 리플레이, 자동 에러 그룹화, 엔드투엔드 분산 트레이싱, Core Web Vitals 추적 [7, 8, 20, 21, 34].
|
||||
|
||||
#### [관계 유형 C (아키텍처 및 안티패턴)]
|
||||
- [[JavaScript Memory Leaks]]
|
||||
- JavaScript Memory Leaks
|
||||
- 연결 이유: 애플리케이션 성능을 점진적으로 파괴하는 현상으로 메모리 팽창, 가비지 컬렉션 등과 연관.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클로저 잔류 참조(Closure-Retained References), 해제되지 않은 이벤트 리스너의 동작 메커니즘 [2, 10, 35].
|
||||
- [[React Re-render Optimization]]
|
||||
- React Re-render Optimization
|
||||
- 연결 이유: React의 렌더링 특성상 발생하는 메인 스레드 블로킹 문제를 해결하기 위한 코드 레벨 기법.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 참조 안정성(Reference stability), 익명 함수의 부작용, `useMemo` 및 `useCallback`의 올바른 활용법 [36-38].
|
||||
|
||||
@@ -63,9 +63,9 @@ React 애플리케이션에서는 상태(State), 프로퍼티(Props), 컨텍스
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Core Web Vitals]]
|
||||
- [[Core Web Vitals|Core Web Vitals]]
|
||||
- 확장 방향: 프론트엔드 성능 최적화와 디버깅의 궁극적인 성과 지표이자 기준점이 되는 실제 사용자 체감 속도 지표(LCP, FID, INP, CLS 등) 심층 탐구 [8].
|
||||
- [[React Server Components (RSC)]]
|
||||
- [[React Server Components (RSC)|React Server Components (RSC)]]
|
||||
- 확장 방향: Next.js 환경에서 클라이언트 측 자바스크립트 번들 사이즈 자체를 줄이고 상호작용 없는 UI를 서버에서 렌더링함으로써 근본적인 클라이언트 디버깅 요소 및 리렌더링 비용을 제거하는 아키텍처 [42, 43].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Index: Development
|
||||
|
||||
## 📁 Subcategories
|
||||
- [[UI_Components/Index|UI_Components]]
|
||||
- UI_Components
|
||||
|
||||
## 📝 Documents
|
||||
- [[Homepage_React_Best_Practices]]
|
||||
- [[Homepage_React_Best_Practices|Homepage_React_Best_Practices]]
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Large-scale Application Refactoring]]
|
||||
# [[Large-scale Application Refactoring|Large-scale Application Refactoring]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
대규모 애플리케이션 리팩토링은 코드의 동작 방식을 보존하면서 내부 구조를 개선하여 오래된 코드베이스의 유지보수성과 확장성을 회복하는 과정이다 [1]. 이는 단순히 코드를 '수정'하는 것이 아니라, 복잡한 비즈니스 로직을 분리하고 구조적 결합도를 낮추는 것을 목표로 한다 [2]. 성공적인 리팩토링을 위해서는 점진적인 접근 방식, 엄격한 아키텍처 적용, 그리고 코드 변경을 뒷받침할 수 있는 테스트 구축이 필수적이다 [1, 3].
|
||||
@@ -22,20 +22,20 @@
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처 및 기반 원칙]
|
||||
- [[Feature-Sliced Design]]
|
||||
- [[Feature-Sliced Design|Feature-Sliced Design]]
|
||||
- 연결 이유: 대규모 코드베이스의 스파게티화를 해결하고, 도메인/기능 중심의 단방향 의존성 규칙을 부여하여 확장 가능한 구조를 만드는 리팩토링의 궁극적 목표 모델이기 때문이다 [7, 22].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기능(Feature)과 계층(Layer)을 어떻게 나누고 캡슐화하여 서로 간의 의존성 결합을 끊어내는지에 대한 실무적 아키텍처 구조 [6, 23].
|
||||
|
||||
- [[SOLID Principles]]
|
||||
- [[SOLID Principles|SOLID Principles]]
|
||||
- 연결 이유: 단일 책임 원칙(SRP) 등을 통해 거대한 컴포넌트가 가지는 여러 책임을 분리하고, 함수나 컴포넌트를 테스트 가능하게 잘게 쪼개는 리팩토링의 핵심 이론적 배경이기 때문이다 [24, 25].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기능적 컴포넌트 내에서 인터페이스(Props)를 어떻게 분리하고, 확장에 열려있으면서 수정에는 닫힌 코드 작성을 구현하는 방법 [25, 26].
|
||||
|
||||
#### [구현 및 활용 도구]
|
||||
- [[Unit Testing]]
|
||||
- Unit Testing
|
||||
- 연결 이유: 레거시 코드 구조를 변경할 때 기능이 망가지지 않았음을 보장하는 첫 번째 단계이자 가장 중요한 안전망 역할을 수행하기 때문이다 [3, 12].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드를 어떻게 더 작고 논리적인 블록 단위로 나누어(Triangulation) 의존성 없이 독립적으로 검증할 수 있는지에 대한 방법론 [9, 12].
|
||||
|
||||
- [[Custom Hooks]]
|
||||
- Custom Hooks
|
||||
- 연결 이유: 리액트 컴포넌트 내부에 복잡하게 얽힌 상태와 사이드 이펙트 로직을 외부로 추출하는 리팩토링의 주된 단위이자 도구이기 때문이다 [9].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: UI 렌더링 책임과 비즈니스 데이터 처리 책임을 어떻게 물리적으로 격리하여 코드 재사용성을 높일 수 있는지의 원리 [9, 10].
|
||||
|
||||
@@ -57,9 +57,9 @@
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Web Performance Optimization]]
|
||||
- [[Web Performance Optimization|Web Performance Optimization]]
|
||||
- 확장 방향: 리팩토링 작업과 병행하여 번들 사이즈 감소(코드 스플리팅), 리렌더링 최적화, 불필요한 렌더 블로킹 제거 등을 통해 애플리케이션의 런타임 및 로딩 속도를 향상하는 전략적 기법을 탐구한다.
|
||||
- [[State Management Fragmentation]]
|
||||
- State Management Fragmentation
|
||||
- 확장 방향: 레거시 앱의 거대한 단일 전역 상태를 분석하여 로컬 컴포넌트 상태, 전역 UI 상태, 서버 캐시 상태, URL 상태 등으로 파편화 및 전문화하여 각각에 맞는 도구(Zustand, React Query 등)로 이관하는 설계 방법론을 조사한다.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Lazy Loading]]
|
||||
# [[Lazy Loading|Lazy Loading]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Lazy Loading은 리소스나 코드 청크를 애플리케이션 초기 구동 시 한 번에 로드하지 않고, 사용자가 실제로 필요로 하는 시점에 비동기적으로 불러오는 성능 최적화 기법입니다 [1, 2]. 프론트엔드 환경에서는 초기 JavaScript 번들 크기를 최대 20~70%까지 줄여 초기 페이지 로드 시간을 획기적으로 향상시킵니다 [3]. 주로 경로(Route) 기반 컴포넌트, 무거운 UI 위젯(차트 등), 뷰포트 하단의 이미지 등에 적용되어 앱의 전반적인 반응성과 Core Web Vitals 지표를 개선합니다 [4, 5].
|
||||
@@ -19,20 +19,20 @@ Lazy Loading은 리소스나 코드 청크를 애플리케이션 초기 구동
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처/기반 기술]
|
||||
- [[Code Splitting]]
|
||||
- [[Code Splitting|Code Splitting]]
|
||||
- 연결 이유: Lazy Loading이 가능하도록 애플리케이션의 단일 JavaScript 번들을 여러 개의 작은 청크 단위로 나누는 근본적인 기반 기술이기 때문입니다 [2, 13].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 모던 프론트엔드 환경에서 빌드 툴(Vite, Webpack)이 런타임 최적화를 위해 코드를 어떻게 분할하고 관리하는지 이해할 수 있습니다 [6, 7].
|
||||
|
||||
- [[Dynamic Imports]]
|
||||
- Dynamic Imports
|
||||
- 연결 이유: 자바스크립트 모듈을 파일의 최상단에서 정적으로 불러오지 않고, 실행 중에 비동기적으로 불러오기 위해 `import()` 문법을 사용하는 방식입니다 [1, 7].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 라우트 전환이나 특정 이벤트 발생 시점에 필요한 코드만 네트워크로 호출하는 런타임 메커니즘을 파악할 수 있습니다 [7].
|
||||
|
||||
#### [구현/활용 도구]
|
||||
- [[React Suspense]]
|
||||
- React Suspense
|
||||
- 연결 이유: `React.lazy()`를 이용해 지연 로딩을 수행할 때, 청크가 로드되기 전까지 렌더링을 일시 중지하고 Fallback UI를 화면에 그려주는 핵심 컴포넌트입니다 [7, 8].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비동기 UI 로딩 시 사용자 경험(UX)을 부드럽게 유지하기 위한 렌더링 제어 및 로딩 상태 설계 패턴을 배울 수 있습니다 [8, 11].
|
||||
|
||||
- [[Vite manualChunks]]
|
||||
- Vite manualChunks
|
||||
- 연결 이유: Vite를 통해 빌드할 때, 변경이 잦지 않은 무거운 벤더 라이브러리(React 코어 등)를 Lazy Loading의 청크 분할 전략과 결합해 별도 파일로 독립시키는 환경 설정입니다 [7, 14].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저 캐싱 전략을 극대화하고, 초기 번들 용량 경고("Large Chunks") 문제를 해결하는 구체적인 번들러 최적화 방법을 학습할 수 있습니다 [7, 15].
|
||||
|
||||
@@ -54,9 +54,9 @@ Lazy Loading은 리소스나 코드 청크를 애플리케이션 초기 구동
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Core Web Vitals]]
|
||||
- [[Core Web Vitals|Core Web Vitals]]
|
||||
- 확장 방향: 지연 로딩이 검색 엔진 최적화(SEO) 및 사용자 경험 지표인 FCP, LCP(Largest Contentful Paint), INP(Interaction to Next Paint) 수치를 실제로 얼마나 개선하는지 측정 및 분석하는 관점으로 확장할 수 있습니다 [3, 23, 24].
|
||||
- [[Server Components (RSC)]]
|
||||
- Server Components (RSC)
|
||||
- 확장 방향: 클라이언트 사이드의 자바스크립트 크기를 줄이기 위한 또 다른 현대적 패러다임으로, 클라이언트에서 실행될 코드를 아예 서버에서 렌더링하고 HTML로만 보내는 방식과 Lazy Loading과의 역할을 비교/대조합니다 [20, 21].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Next.js App Router]]
|
||||
# [[Next.js App Router|Next.js App Router]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Next.js App Router는 Next.js(버전 13 이후)에서 도입된 최신 라우팅 및 아키텍처 시스템으로, React Server Components(RSC)를 기본적으로 지원하여 클라이언트 측 자바스크립트 전송량을 줄이고 초기 로딩 속도를 향상시킵니다 [1, 2]. 이 시스템은 `app` 디렉토리를 기반으로 동작하며, `page.js`, `layout.js`와 같은 특수 파일들을 통해 직관적이고 구조화된 라우팅을 제공합니다 [3, 4].
|
||||
@@ -15,15 +15,15 @@ Next.js App Router는 Next.js(버전 13 이후)에서 도입된 최신 라우팅
|
||||
|
||||
### Related Concepts
|
||||
|
||||
- [[React Server Components]]
|
||||
- [[React Server Components|React Server Components]]
|
||||
- 연결 이유: Next.js App Router 아키텍처의 핵심 기반으로, 번들 크기를 줄이고 데이터 페칭 성능을 향상시키는 역할을 합니다 [1, 2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클라이언트 측 렌더링 코드와 서버 측 렌더링 코드 간의 명확한 경계 구분 및 Hydration 최소화 전략 [6, 7, 9].
|
||||
|
||||
- [[Route Groups]]
|
||||
- Route Groups
|
||||
- 연결 이유: App Router 내에서 URL 경로를 변경하지 않고도 폴더 구조를 논리적으로 조직할 수 있게 해주는 핵심 폴더 라우팅 패턴입니다 [5, 11].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 복잡한 애플리케이션에서 별도의 레이아웃을 가진 섹션(예: 마케팅 페이지와 상점 페이지)을 충돌 없이 독립적으로 분리하는 방법 [5, 11].
|
||||
|
||||
- [[Concurrent Rendering]]
|
||||
- [[Concurrent Rendering|Concurrent Rendering]]
|
||||
- 연결 이유: Next.js App Router가 기본적으로 완벽하게 지원하는 React의 렌더링 메커니즘으로, 렌더링 작업을 일시 중지, 중단 및 재개할 수 있게 해줍니다 [10, 12].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `useTransition` 및 `useDeferredValue` 훅을 통해 무거운 렌더링 시에도 사용자 입력 반응성(UX)을 높게 유지하는 원리 [13, 14].
|
||||
|
||||
@@ -45,9 +45,9 @@ Next.js App Router는 Next.js(버전 13 이후)에서 도입된 최신 라우팅
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Code Splitting & Lazy Loading]]
|
||||
- Code Splitting & Lazy Loading
|
||||
- 확장 방향: App Router의 Server Components뿐만 아니라, `React.lazy`와 `Suspense`를 결합하여 라우트 및 무거운 컴포넌트(차트, 에디터 등)를 필요한 순간에만 로드하도록 최적화하는 기법으로의 이해 확장 [20, 21].
|
||||
- [[React Context API Optimization]]
|
||||
- React Context API Optimization
|
||||
- 확장 방향: App Router 환경 하의 클라이언트 컴포넌트 내에서 불가피하게 전역 상태를 쓸 때, Context의 광범위한 리렌더링 이슈를 회피하기 위해 컨텍스트를 분리하거나 Zustand, Jotai 등의 외부 라이브러리를 도입하는 방향으로 학습 확장 [22-24].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Prop Drilling]]
|
||||
# [[Prop Drilling|Prop Drilling]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Prop Drilling은 실제로 해당 데이터가 필요하지 않은 여러 중간 컴포넌트들을 거쳐 계층적으로 데이터를 전달하는 안티 패턴을 의미합니다 [1]. 주로 깊게 중첩된 하위 컴포넌트에 상태나 데이터를 전달해야 할 때 발생합니다 [1]. React 생태계에서는 이 문제를 해결하기 위해 내장된 Context API나 외부 상태 관리 라이브러리를 활용합니다 [1, 2].
|
||||
@@ -19,15 +19,15 @@ Prop Drilling을 피하기 위해 가장 먼저 고려되는 Context API는 빈
|
||||
### Related Concepts
|
||||
|
||||
#### [기반 기술/해결책]
|
||||
- [[Context API]]
|
||||
- [[Context API|Context API]]
|
||||
- 연결 이유: Prop Drilling 문제를 해결하기 위해 React에서 자체적으로 도입한 내장 데이터 전달 메커니즘이기 때문입니다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: props를 일일이 넘기지 않고 컴포넌트 트리에 데이터를 브로드캐스트하는 원리와 그에 따른 리렌더링 한계를 이해할 수 있습니다 [6, 12].
|
||||
|
||||
#### [상태 관리 도구/대안]
|
||||
- [[Zustand]]
|
||||
- Zustand
|
||||
- 연결 이유: Prop Drilling의 대안인 Context API가 갖는 리렌더링 성능 문제를 극복할 수 있는 경량 상태 관리 라이브러리이기 때문입니다 [2, 7].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 선택자(Selector) 패턴을 활용해 필요한 상태의 변경에만 컴포넌트를 리렌더링하도록 스마트하게 구독(subscribe)하는 구조를 이해할 수 있습니다 [7, 13].
|
||||
- [[Redux]]
|
||||
- [[Redux|Redux]]
|
||||
- 연결 이유: 대규모 애플리케이션에서 Prop Drilling을 방지하고 상태를 일관성 있게 관리하기 위한 산업 표준 상태 컨테이너 도구이기 때문입니다 [5, 14].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 파생 선택자(derived selectors)가 존재함으로써 Prop Drilling 없이 복잡한 상태와 비동기 로직을 어떻게 효율적으로 다루는지 파악할 수 있습니다 [5, 15].
|
||||
|
||||
@@ -49,7 +49,7 @@ Prop Drilling을 피하기 위해 가장 먼저 고려되는 Context API는 빈
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Re-renders]]
|
||||
- Re-renders
|
||||
- 확장 방향: Prop Drilling을 피하기 위한 수단(Context API)이 초래하는 부작용인 불필요한 렌더링을 방지하기 위한 메모이제이션(`React.memo`, `useMemo`, `useCallback`) 등 React 런타임 성능 최적화 기법으로의 이해 확장이 필요합니다 [3, 6, 23].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Re-renders Optimization]]
|
||||
# [[Re-renders Optimization|Re-renders Optimization]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Re-renders Optimization은 React 애플리케이션에서 불필요한 컴포넌트 업데이트를 최소화하여 성능, 반응성 및 사용자 경험을 향상시키는 과정입니다 [1, 2]. 주로 상태(state), 속성(props), 컨텍스트(context)의 변경으로 인해 발생하는 과도한 렌더링을 타겟으로 합니다 [3]. 이를 위해 수동 메모이제이션, 상태 관리 최적화, 가상화 기법, 그리고 React Compiler와 같은 최신 자동화 도구를 활용하여 병목 현상을 방지합니다 [4-6].
|
||||
@@ -18,15 +18,15 @@ Re-renders Optimization은 React 애플리케이션에서 불필요한 컴포넌
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[React Compiler]]
|
||||
- [[React Compiler|React Compiler]]
|
||||
- 연결 이유: 개발자가 수동으로 리렌더링을 최적화하던 기존 방식을 대체하여, 빌드 타임에 자동으로 메모이제이션을 적용하는 2025년 기준 핵심 기술이기 때문입니다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트 전체가 아닌 개별 JSX 요소와 연산이 어떻게 독립적으로 캐싱되는지의 원리와 서드파티 라이브러리 호환성 한계 [19, 26].
|
||||
|
||||
- [[State Management (Zustand vs Context)]]
|
||||
- State Management (Zustand vs Context)
|
||||
- 연결 이유: 불필요한 전체 리렌더링을 유발하는 Context API의 구조적 한계를 Zustand의 선택자(Selector) 패턴이 어떻게 극복하여 렌더링을 최적화하는지 설명하기 때문입니다 [13, 17].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 자주 변경되는 전역 상태 관리에서 React 렌더링 사이클 외부의 스토어가 어떻게 컴포넌트 렌더링을 정밀하게 제어하는지 [17, 27].
|
||||
|
||||
- [[Memoization (useMemo, useCallback)]]
|
||||
- Memoization (useMemo, useCallback)
|
||||
- 연결 이유: React의 얕은 비교(Shallow comparison) 특성을 극복하고 참조 동등성을 유지하여 `React.memo`와 결합한 리렌더링 최적화의 기반이 되기 때문입니다 [10].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 무분별한 메모이제이션이 오히려 렌더링 비용보다 큰 성능 오버헤드를 유발하는 이유와 올바른 적용 조건 [11, 12].
|
||||
|
||||
@@ -45,9 +45,9 @@ Re-renders Optimization은 React 애플리케이션에서 불필요한 컴포넌
|
||||
- **My Project Relevance:** 현재 유지보수하거나 새로 구축하는 React 프로젝트에서 성능 저하를 겪고 있다면, 익명 함수 인라인 작성 패턴을 수정하고, 불필요한 거대 Context를 분리하며, 식별 가능한 병목 지점에 프로파일링 기반의 메모이제이션을 적용해 즉각적인 성능 개선을 이룰 수 있습니다 [5, 15, 22].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Core Web Vitals (INP, FCP, TTI)]]
|
||||
- Core Web Vitals (INP, FCP, TTI)
|
||||
- 확장 방향: 프론트엔드 코드의 리렌더링 최적화가 실제 사용자의 체감 성능을 측정하는 지표(특히 Interaction to Next Paint)에 브라우저 레벨에서 어떤 영향을 미치는지 확장하여 조사합니다 [2, 33].
|
||||
- [[Code Splitting & Lazy Loading]]
|
||||
- Code Splitting & Lazy Loading
|
||||
- 확장 방향: 컴포넌트 업데이트 시점(리렌더링)의 최적화뿐만 아니라, 컴포넌트 최초 로드 시점의 번들 크기를 줄여 초기 렌더링 성능을 극대화하는 `React.lazy`와 동적 임포트 기법을 함께 학습합니다 [34].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[React 18 Concurrent Features]]
|
||||
# [[React 18 Concurrent Features|React 18 Concurrent Features]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 18 Concurrent Features(동시성 기능)는 업데이트가 발생하는 시점과 방식을 제어하여 응답성을 희생하지 않으면서도 더 매끄러운 앱을 구축할 수 있게 해주는 기능이다 [1]. 이 렌더링 모델은 React가 렌더링 작업을 일시 중지(pause), 중단(interrupt), 재개(resume)할 수 있도록 허용하여 중요도에 따른 업데이트 우선순위 지정을 가능하게 한다 [2]. 대표적인 훅(Hook)인 `useTransition`과 `useDeferredValue`를 통해 느린 렌더링이 중요한 사용자 상호작용을 차단하지 못하게 방지할 수 있다 [3, 4].
|
||||
@@ -16,13 +16,13 @@ React 18 Concurrent Features(동시성 기능)는 업데이트가 발생하는
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[useTransition]]
|
||||
- [[useTransition|useTransition]]
|
||||
- 연결 이유: React 18 동시성 기능의 핵심 훅으로, 비긴급 업데이트를 지연시키는 구체적인 구현체이다 [3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 라이브 검색이나 필터링 시 렌더링 병목 현상을 방지하고, 어떻게 비긴급 작업과 긴급 상호작용(타이핑 등)을 분리하는지 이해할 수 있다 [3].
|
||||
- [[useDeferredValue]]
|
||||
- [[useDeferredValue|useDeferredValue]]
|
||||
- 연결 이유: 값의 읽기를 지연시켜 UI 업데이트와 연산 부하를 분리하는 동시성 기능의 또 다른 핵심 훅이다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 즉각적인 UI 반영이 필요한 부분과 지연시켜도 무방한 무거운 계산(derived data)을 어떻게 나누어 처리하는지 알 수 있다 [4].
|
||||
- [[Suspense]]
|
||||
- Suspense
|
||||
- 연결 이유: 동시성 훅(`useTransition` 등)과 결합하여 백그라운드 렌더링이 진행되거나 데이터가 로드될 때 스켈레톤(fallback UI)을 보여줄 수 있도록 설계된 기능이다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 지연 중인 렌더링 상태에서 사용자의 경험(UX)을 어떻게 부드럽게 이어갈 수 있는지 이해할 수 있다 [4].
|
||||
|
||||
@@ -41,9 +41,9 @@ React 18 Concurrent Features(동시성 기능)는 업데이트가 발생하는
|
||||
- **My Project Relevance:** 현재 진행 중인 프로젝트에서 데이터가 많은 차트나 테이블 필터링 시 UI가 끊기는(Jank) 현상이 있다면, 이 동시성 기능 훅을 도입하여 즉각적인 클릭/입력 응답성을 확보할 수 있다 [3, 4].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[React Performance Optimization]]
|
||||
- [[React Performance Optimization|React Performance Optimization]]
|
||||
- 확장 방향: 동시성 렌더링 외에도 불필요한 리렌더링 자체를 막는 `React.memo`, `useCallback`, `useMemo` 활용법과 같은 다양한 React 성능 최적화 기법 전반으로 지식을 확장할 수 있다 [9-11].
|
||||
- [[Server Components]]
|
||||
- [[Server Components|Server Components]]
|
||||
- 확장 방향: Next.js에서 동시성 기능과 함께 성능 향상의 양대 축을 이루는 기능으로, 클라이언트 측 JavaScript를 전송하지 않고 서버에서 렌더링을 완료하여 번들 크기를 줄이는 전략을 학습할 수 있다 [12, 13].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[React Application Scaling]]
|
||||
# [[React Application Scaling|React Application Scaling]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
리액트 애플리케이션 스케일링(React Application Scaling)은 애플리케이션의 크기와 복잡성이 증가함에 따라 발생하는 아키텍처, 성능, 상태 관리, 그리고 협업 문제를 체계적으로 해결하는 과정입니다 [1-3]. 이는 단순히 렌더링 속도를 높이는 것을 넘어, 비즈니스 로직과 UI의 결합을 막고, 예측 가능한 폴더 구조를 도입하며, 불필요한 리렌더링과 번들 크기를 최적화하는 것을 포함합니다 [2-5]. 결과적으로 대규모 팀이 안정적이고 유지보수하기 쉬운 프론트엔드 시스템을 구축할 수 있도록 돕는 핵심 엔지니어링 패러다임입니다 [3, 6].
|
||||
@@ -24,6 +24,6 @@
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처 및 폴더 구조 (Architecture & Structure)]
|
||||
- [[Feature-Sliced Design (FSD)]]
|
||||
- [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD)]]
|
||||
- 연결 이유: 확장 가능한 리액트 앱을 구축하기 위한 핵심 도메인 주도 아키텍처 방법론입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기능, 위젯, 엔티티를 분리하고 단방향 의존성 규칙을 강제하여 결
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[React Codebase Refactoring]]
|
||||
# [[React Codebase Refactoring|React Codebase Refactoring]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 코드베이스 리팩토링은 기존 앱의 외부 동작을 변경하지 않으면서 유지보수성, 성능, 가독성을 향상시키기 위해 코드를 재설계하고 정리하는 과정입니다. 대규모 React 앱에서 자주 발생하는 논리 결합, 불필요한 재렌더링, 전역 상태의 남용 등의 아키텍처 문제를 해결하는 데 중점을 둡니다. 성공적인 리팩토링을 위해서는 단위 테스트로 안전망을 확보한 후, 컴포넌트 책임 분리, TypeScript 도입, 상태 관리 도구의 현대화를 점진적으로 수행하는 것이 권장됩니다 [1-3].
|
||||
@@ -22,21 +22,21 @@ React 코드베이스 리팩토링은 기존 앱의 외부 동작을 변경하
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/기반 기술)]
|
||||
- [[Feature-Sliced Design]]
|
||||
- [[Feature-Sliced Design|Feature-Sliced Design]]
|
||||
- 연결 이유: 리팩토링 과정에서 기술 단위(Component, Hooks 등)로 흩어진 기존 폴더 구조를 기능(Feature) 중심으로 모듈화하고 재편할 때 기준이 되는 현대적인 프론트엔드 아키텍처론입니다 [22, 23].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 확장성을 위한 단방향 의존성 규칙과 도메인 중심의 코드 캡슐화 설계 방법.
|
||||
- [[SOLID Principles]]
|
||||
- [[SOLID Principles|SOLID Principles]]
|
||||
- 연결 이유: 거대한 React 컴포넌트를 작게 분리하고 인터페이스를 구성할 때, 단일 책임 원칙(SRP)과 같은 클린 코드의 기반 지침을 제공합니다 [6, 24].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 리액트 컴포넌트의 책임을 올바르게 분리하고 유지보수하기 쉬운 추상화를 설계하는 기준.
|
||||
|
||||
#### [관계 유형 B (구현/활용 도구)]
|
||||
- [[TanStack Query]]
|
||||
- TanStack Query
|
||||
- 연결 이유: 기존의 비효율적인 Context API나 거대한 Redux 스토어를 리팩토링할 때, 서버 상태(캐싱, 동기화 등)를 깔끔하게 분리해 주는 핵심 도구입니다 [10, 11].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서버 데이터 페칭 로직의 분리와 컴포넌트 내 복잡한 상태 관리 감소 방법.
|
||||
- [[Zustand]]
|
||||
- Zustand
|
||||
- 연결 이유: 불필요한 재렌더링을 유발하는 기존의 Context API 기반 상태 관리를 리팩토링할 때 주로 도입되는 경량 클라이언트 상태 관리 라이브러리입니다 [1, 25].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 선택자(Selector)를 통한 렌더링 최적화 구조 및 보일러플레이트 없는 상태 관리 로직 작성법.
|
||||
- [[Unit Testing]]
|
||||
- Unit Testing
|
||||
- 연결 이유: 리팩토링 시 코드를 변경하더라도 기존의 비즈니스 로직이 파괴되지 않음을 보장하기 위해 리팩토링 작업에 선행되어야 하는 기술입니다 [2, 5].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기존 코드를 검증 가능한 형태로 쪼개고 안전성을 확보하는 실질적인 엔지니어링 절차.
|
||||
|
||||
@@ -55,9 +55,9 @@ React 코드베이스 리팩토링은 기존 앱의 외부 동작을 변경하
|
||||
- **My Project Relevance:** 현재 유지보수하고 있는 복잡한 레거시 React 프로젝트의 성능 및 유지보수성 저하 원인을 분석하고, 컴포넌트 분리와 상태 관리 라이브러리(Zustand, React Query) 교체 작업을 체계적으로 기획할 때 직접 적용할 수 있습니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Web Performance Optimization]]
|
||||
- [[Web Performance Optimization|Web Performance Optimization]]
|
||||
- 확장 방향: 리팩토링의 궁극적 결과물 중 하나인 초기 로딩 속도 향상, 렌더링 최적화, 그리고 불필요한 번들 사이즈를 줄이는 코드 스플리팅(Code Splitting) 기법 등으로 개념을 확장하여 학습할 수 있습니다.
|
||||
- [[Git Workflow & CI/CD]]
|
||||
- Git Workflow & CI/CD
|
||||
- 확장 방향: 대규모 리팩토링 시 발생할 수 있는 브랜치 충돌 방지와 코드 리뷰 자동화, 그리고 Pull Request 과정에서 Visual Regression Testing을 연동하는 등 협업 전략으로 확장할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[React DevTools Profiler]]
|
||||
# [[React DevTools Profiler|React DevTools Profiler]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React DevTools Profiler는 React 애플리케이션의 렌더링 성능을 측정하고 최적화 대상을 식별하기 위해 React DevTools에 내장된 프로파일링 및 디버깅 도구이다 [1]. 이 도구는 어떤 컴포넌트가 언제, 얼마나 오래 렌더링되었는지, 그리고 어떤 요인(props, state 변경 등)이 렌더링을 유발했는지 파악하는 데 사용된다 [1, 2]. 주로 로컬 개발 환경에서 성능 병목 현상을 식별하고 불필요한 리렌더링을 찾아내는 데 핵심적으로 활용된다 [3].
|
||||
@@ -17,15 +17,15 @@ React DevTools Profiler는 React 애플리케이션의 렌더링 성능을 측
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술]
|
||||
- [[React Compiler]]
|
||||
- [[React Compiler|React Compiler]]
|
||||
- 연결 이유: React Compiler가 빌드 타임에 주입한 자동 메모이제이션 로직의 성공 여부와 렌더링 스킵 결과를 Profiler를 통해 시각적으로 확인할 수 있다 [7-9].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 명시적인 메모이제이션 코드 없이도 렌더링 성능이 최적화되는 원리와, 블랙박스화된 렌더링 메커니즘을 디버깅하는 방법 [9, 11].
|
||||
|
||||
#### [관계 유형 B: 구현/활용 도구]
|
||||
- [[React.memo]]
|
||||
- React.memo
|
||||
- 연결 이유: Profiler를 통해 특정 컴포넌트의 렌더링 빈도와 비용을 측정한 뒤, 그 결과에 따라 `React.memo` 적용이 성능 향상에 실질적인 도움이 될지 판단할 수 있다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 얕은 비교(Shallow comparison)의 원리와 프로파일링 데이터에 기반한 전략적 메모이제이션 방법 [4, 12, 13].
|
||||
- [[useCallback & useMemo]]
|
||||
- useCallback & useMemo
|
||||
- 연결 이유: Profiler에서 자식 컴포넌트가 참조(Reference) 변경 때문에 계속 리렌더링되는 것을 발견했다면, 이 훅들을 사용하여 참조 안정성(Reference stability)을 확보할 수 있다 [5, 14].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 함수나 객체의 참조 동일성이 컴포넌트 렌더링 트리에 미치는 직접적인 영향 [14].
|
||||
|
||||
@@ -43,9 +43,9 @@ React DevTools Profiler는 React 애플리케이션의 렌더링 성능을 측
|
||||
- **My Project Relevance:** 화면 내 대용량 리스트나 복잡한 필터를 조작할 때 발생하는 지연 현상(Jank)의 원인이 렌더링 시간 자체인지, 아니면 불필요한 연쇄 리렌더링 때문인지 진단하고 해결책을 마련한다 [21, 22].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[why-did-you-render]]
|
||||
- why-did-you-render
|
||||
- 확장 방향: Profiler와 결합하여 사용할 수 있는 라이브러리로, 실제 데이터 변경이 없음에도 불구하고 컴포넌트가 리렌더링된 '정확한 이유'를 콘솔에 경고 형태로 남겨주어 디버깅을 더욱 쉽게 만들어주는 도구에 대해 조사한다 [3, 23].
|
||||
- [[Chrome DevTools Performance Tab]]
|
||||
- Chrome DevTools Performance Tab
|
||||
- 확장 방향: Profiler가 알려주는 React 내부의 렌더링 속도 이외에, 프레임 드롭이나 메인 스레드를 막는 무거운 자바스크립트 실행, 레이아웃 이동 등 브라우저 레벨의 전체적인 성능 분석으로 시야를 확장한다 [3, 23].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[React Frontend Architecture]]
|
||||
# [[React Frontend Architecture|React Frontend Architecture]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 프론트엔드 아키텍처는 확장 가능하고 유지보수하기 쉬운 애플리케이션을 구축하기 위한 구조적 뼈대이자 조직화 방법론이다 [1, 2]. 기존의 기술적 파일 단위 분리에서 벗어나, 비즈니스 도메인과 기능(Feature-Based)을 중심으로 코드를 구성하여 결합도를 낮추고 응집도를 높이는 것을 목표로 한다 [3-5]. 이를 통해 무분별한 비즈니스 로직의 UI 누수를 막고 명확한 상태 소유권을 확립하며, 팀과 코드베이스가 성장함에 따라 시스템이 예측 가능하게 확장할 수 있도록 돕는다 [6-8].
|
||||
@@ -23,18 +23,18 @@ React 프론트엔드 아키텍처는 확장 가능하고 유지보수하기 쉬
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처 및 디자인 패턴]
|
||||
- [[Feature-Sliced Design]]
|
||||
- [[Feature-Sliced Design|Feature-Sliced Design]]
|
||||
- 연결 이유: 현대 React 애플리케이션의 모듈화 및 계층화를 위해 고안된 가장 대표적이고 구체적인 프론트엔드 아키텍처 방법론이기 때문 [3, 13].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 도메인 기반 분할, 단방향 의존성 규칙 적용 방법, 그리고 Public API를 통한 컴포넌트의 캡슐화 원리 [14, 16, 17].
|
||||
- [[SOLID Principles]]
|
||||
- [[SOLID Principles|SOLID Principles]]
|
||||
- 연결 이유: 확장 가능한 프론트엔드 구조를 짜기 위해 클래스 기반 OOP를 넘어 React의 함수형 컴포넌트에도 적용해야 하는 근본적인 소프트웨어 설계 원칙이기 때문 [17, 48].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 책임 원칙(SRP)을 이용한 비대해진 컴포넌트의 리팩토링 방식 및 개방-폐쇄 원칙(OCP)을 활용한 UI 컴포넌트 합성(Composition) 전략 [25, 49].
|
||||
|
||||
#### [상태 관리 및 최적화 전략]
|
||||
- [[State Management]]
|
||||
- [[상태 관리(State Management)|State Management]]
|
||||
- 연결 이유: 아키텍처 내에서 데이터(서버 데이터, 로컬 상태, 전역 UI 상태)의 성격에 따라 책임과 저장소를 어떻게 나눌지 결정하는 핵심 분야이기 때문 [20, 50].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Context API의 렌더링 한계를 돌파하기 위한 Zustand/Jotai의 Selector 패턴 작동 원리 및 TanStack Query를 활용한 서버 상태 격리 기법 [21, 43, 51].
|
||||
- [[Performance Optimization]]
|
||||
- [[Performance Optimization|Performance Optimization]]
|
||||
- 연결 이유: 대규모 아키텍처가 실제로 사용자 브라우저에서 효율적으로 동작하기 위해 필수적으로 수반되어야 하는 성능 지표(Web Vitals) 관리 방법이기 때문 [52, 53].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 지연 로딩(Lazy Loading) 및 코드 스플리팅을 통한 초기 번들 사이즈 최적화, 그리고 동시성 렌더링(Concurrent Rendering) 훅의 활용법 [54-56].
|
||||
|
||||
@@ -55,9 +55,9 @@ React 프론트엔드 아키텍처는 확장 가능하고 유지보수하기 쉬
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Micro-Frontends]]
|
||||
- [[마이크로 프론트엔드 (Micro Frontends)|Micro-Frontends]]
|
||||
- 확장 방향: 단일 React SPA 아키텍처의 한계를 넘어, 독립적으로 배포 및 관리 가능한 여러 프론트엔드 팀과 서비스를 하나로 조율하는 엔터프라이즈급 인프라 확장 관점으로 연결 [3, 63].
|
||||
- [[Observability and Monitoring]]
|
||||
- Observability and Monitoring
|
||||
- 확장 방향: 설계한 아키텍처가 실제 프로덕션 환경에서 어떻게 동작하고 어디서 병목을 일으키는지 측정하기 위한 구조적 로깅, 성능 프로파일링(Web Vitals), 그리고 Sentry를 활용한 세션 모니터링 기법으로 확장 [64-66].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[React Scalability]]
|
||||
# [[React Scalability|React Scalability]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React Scalability(React 확장성)는 기능, 팀 규모, 비즈니스 로직의 복잡성이 증가함에 따라 애플리케이션의 성능, 유지보수성, 예측 가능한 성장을 유지하는 능력을 의미합니다. 단순히 컴포넌트를 렌더링하는 것을 넘어, 결합도를 낮추고 응집도를 높이는 아키텍처 설계, 상태 관리의 최적화, 그리고 코드 스플리팅과 렌더링 성능 최적화를 포괄합니다. 확장 가능한 React 시스템은 명확한 폴더 구조(예: Feature-Sliced Design)와 엄격한 관심사 분리를 통해 코드베이스가 자체적인 무게로 인해 붕괴되는 것을 방지합니다. [1-4]
|
||||
@@ -20,21 +20,21 @@ React Scalability(React 확장성)는 기능, 팀 규모, 비즈니스 로직의
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처/기반 기술]
|
||||
- [[Feature-Sliced Design]]
|
||||
- [[Feature-Sliced Design|Feature-Sliced Design]]
|
||||
- 연결 이유: React의 한계인 구체적인 아키텍처 부재를 해결하기 위해 설계된 대규모 프론트엔드 방법론입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 레이어(Layer) 간의 단방향 의존성 원칙과 Public API를 활용한 모듈의 캡슐화 및 결합도 최소화 방법.
|
||||
- [[SOLID Principles]]
|
||||
- [[SOLID Principles|SOLID Principles]]
|
||||
- 연결 이유: 확장 가능하고 유지보수가 쉬운 React 코드를 작성하기 위한 핵심 소프트웨어 엔지니어링 원칙입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대한 컴포넌트를 단일 책임 원칙(SRP)에 따라 작은 기능으로 분리하고, 커스텀 훅을 활용하여 로직을 재사용하는 구조적 사고.
|
||||
|
||||
#### [구현/활용 도구]
|
||||
- [[State Management Libraries (Redux, Zustand, Context API)]]
|
||||
- State Management Libraries (Redux, Zustand, Context API)
|
||||
- 연결 이유: 애플리케이션의 크기와 상태 업데이트 빈도에 따라 적절한 도구를 선택하는 것은 확장성에 지대한 영향을 미칩니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 불필요한 리렌더링 방지를 위한 Selector 패턴의 동작 원리와, 대규모 프로젝트에서 강제되는 상태 관리 아키텍처의 중요성.
|
||||
- [[Code Splitting & Lazy Loading]]
|
||||
- Code Splitting & Lazy Loading
|
||||
- 연결 이유: 코드가 비대해짐에 따라 발생하는 성능 저하(번들 크기 증가)를 해결하기 위한 핵심 런타임 최적화 기법입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `React.lazy`와 Vite의 `manualChunks`를 이용한 번들 크기 축소 및 브라우저 캐싱 전략.
|
||||
- [[React Error Boundaries]]
|
||||
- React Error Boundaries
|
||||
- 연결 이유: 대규모 앱에서 하나의 결함 있는 컴포넌트로 인해 전체 애플리케이션이 붕괴되는 것을 막아주는 안전 장치입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 런타임 렌더링 에러를 격리(Isolate)하고 폴백(Fallback) UI를 제공하여 시스템 복원력을 높이는 방법.
|
||||
|
||||
@@ -56,11 +56,11 @@ React Scalability(React 확장성)는 기능, 팀 규모, 비즈니스 로직의
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Server Components (Next.js)]]
|
||||
- Server Components (Next.js)
|
||||
- 확장 방향: 클라이언트 측으로 전송되는 JavaScript 번들 자체를 제거하여 하이드레이션(Hydration) 오버헤드를 줄이고 확장성과 성능을 동시에 잡는 최신 렌더링 패러다임.
|
||||
- [[Memory Leak Detection in JavaScript]]
|
||||
- Memory Leak Detection in JavaScript
|
||||
- 확장 방향: 확장 가능한 애플리케이션에서 장시간 사용 시 성능을 저하시키는 Detached DOM Nodes나 이벤트 리스너 누수 등을 Chrome DevTools Heap Snapshot을 통해 디버깅하는 방법.
|
||||
- [[Git Branching Workflows for Small & Large Teams]]
|
||||
- Git Branching Workflows for Small & Large Teams
|
||||
- 확장 방향: 규모가 확장되는 프론트엔드 팀이 충돌 없이 코드를 통합하기 위해 사용하는 GitHub Flow, Trunk-Based Development 및 PR(Pull Request) 리뷰 에티켓.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[React.lazy()]]
|
||||
# [[React.lazy()|React.lazy()]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
`React.lazy()`는 리액트(React)에서 컴포넌트를 필요한 시점에 동적으로 불러올 수 있게 해주는 내장 함수입니다 [1]. 이 기능을 동적 임포트(Dynamic Imports)와 결합하면 거대한 자바스크립트 번들을 더 작은 청크(Chunk)로 나눌 수 있습니다 [2, 3]. 결과적으로 사용자가 앱에 처음 접근할 때 다운로드해야 하는 초기 자바스크립트 페이로드 크기를 대폭 줄여 앱의 초기 로드 속도와 전반적인 성능을 크게 향상시킵니다 [2-4].
|
||||
@@ -24,23 +24,23 @@
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처/기반 기술]
|
||||
- [[Code Splitting]]
|
||||
- [[Code Splitting|Code Splitting]]
|
||||
- 연결 이유: `React.lazy()`의 존재 목적이자 근본적인 성능 최적화 기법입니다 [6].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 초기 렌더링 시 불필요한 자바스크립트 번들 크기를 줄여 로딩 성능을 최적화하는 애플리케이션 구조 원리.
|
||||
- [[Dynamic Imports]]
|
||||
- Dynamic Imports
|
||||
- 연결 이유: `React.lazy()` 함수 내부에서 비동기적으로 모듈을 로드하기 위해 사용하는 표준 자바스크립트 문법(`import()`)입니다 [2, 3, 8].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저가 특정 코드가 실행되어야 할 시점에 네트워크 요청을 생성하여 모듈을 가져오는 메커니즘.
|
||||
|
||||
#### [구현/활용 도구]
|
||||
- [[Suspense]]
|
||||
- Suspense
|
||||
- 연결 이유: `React.lazy()`로 분리된 코드가 백그라운드에서 다운로드되는 동안 앱이 멈추지 않도록 로딩 UI를 처리하기 위해 필수적으로 결합되는 리액트 기능입니다 [1, 3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비동기 렌더링 흐름에서 로딩 상태(Loading State)를 컴포넌트 트리 상단에서 선언적으로 처리하는 방법.
|
||||
- [[Vite/Rollup]]
|
||||
- Vite/Rollup
|
||||
- 연결 이유: 소스 코드에 작성된 `React.lazy()` 구문을 분석하여 빌드 타임에 물리적으로 개별 자바스크립트 파일(청크)로 분할해 내는 도구들입니다 [2, 8].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 모듈 번들러가 코드 스플리팅을 인식하고 프로덕션 환경의 정적 에셋으로 변환하여 캐싱 효율을 높이는 과정.
|
||||
|
||||
### Deeper Research Questions
|
||||
- `React.lazy()`를 활용한 클라이언트 사이드 코드 스플리팅과 서버 사이드에서 이루어지는 [[React Server Components]]의 성능 최적화 방식은 어떻게 다르며 서로 어떻게 보완될 수 있는가?
|
||||
- `React.lazy()`를 활용한 클라이언트 사이드 코드 스플리팅과 서버 사이드에서 이루어지는 [[React Server Components|React Server Components]]의 성능 최적화 방식은 어떻게 다르며 서로 어떻게 보완될 수 있는가?
|
||||
- `<Suspense>`로 감싸진 지연 로딩 컴포넌트가 로드될 때 발생하는 Cumulative Layout Shift (CLS)를 최소화하기 위한 구체적인 UI 패턴과 전략은 무엇인가?
|
||||
- 모바일 환경 등 네트워크 속도가 느린 곳에서 `React.lazy()`로 분리된 청크를 불러올 때, 에러가 발생한 경우(예: 배포 후 이전 해시 청크 삭제됨) 이를 Error Boundary로 어떻게 우아하게 복구할 수 있는가?
|
||||
- 사용자가 컴포넌트를 요청하기 전(예: 링크에 마우스를 올리는 시점)에 `React.lazy()`로 분리된 청크를 미리 가져오는 프리패치(Prefetching/Preloading) 전략은 어떻게 구현하는가?
|
||||
@@ -54,11 +54,11 @@
|
||||
- **My Project Relevance:** 현재 유지보수 중인 프로젝트에 모달, 어드민 설정 패널 등 즉시 보이지 않는 컴포넌트들이 메인 번들에 포함되어 있다면, 이를 `React.lazy()`로 리팩토링하여 Time To Interactive (TTI) 지표를 당장 개선하는 데 적용할 수 있습니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Core Web Vitals]]
|
||||
- [[Core Web Vitals|Core Web Vitals]]
|
||||
- 확장 방향: `React.lazy()`를 적용했을 때 First Contentful Paint (FCP)와 Interaction to Next Paint (INP) 같은 구글의 웹 성능 지표가 어떻게 개선되는지 확인하는 방향으로 연구 확장 [1, 5].
|
||||
- [[manualChunks]]
|
||||
- manualChunks
|
||||
- 확장 방향: `React.lazy()`에 의한 스플리팅 외에, React 코어나 서드파티 라이브러리들(vendor)을 별도 분리해 브라우저 캐싱을 고도화하는 빌드 도구 수준의 수동 제어 기법 파악 [8, 14].
|
||||
- [[React Server Components (RSC)]]
|
||||
- [[React Server Components (RSC)|React Server Components (RSC)]]
|
||||
- 확장 방향: 자바스크립트를 클라이언트로 아예 보내지 않고 서버에서 렌더링하여 성능을 극대화하는 최신 Next.js 패러다임과 클라이언트 단의 `React.lazy`를 비교 [9, 15].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Real User Monitoring (RUM)]]
|
||||
# [[Real User Monitoring (RUM)|Real User Monitoring (RUM)]]
|
||||
|
||||
## 📌 Brief 시 Summary
|
||||
Real User Monitoring (RUM)은 다양한 기기와 네트워크 조건에서 사용자가 경험하는 실제 성능과 상호작용을 추적하는 모니터링 방식입니다 [1]. 합성 테스트(Synthetic testing)가 놓칠 수 있는 실제 성능 문제를 파악하는 데 필수적이며 [1], 프론트엔드의 사용자 액션과 백엔드의 인프라 트레이스를 연결하여 전체 시스템에 대한 가시성을 제공합니다 [2].
|
||||
@@ -20,21 +20,21 @@ Real User Monitoring (RUM)은 다양한 기기와 네트워크 조건에서 사
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/기반 기술)]
|
||||
- [[Synthetic Testing]]
|
||||
- [[Synthetic Testing|Synthetic Testing]]
|
||||
- 연결 이유: RUM과 대비되는 모니터링 개념으로, 가상 환경에서 애플리케이션의 성능을 시뮬레이션하여 측정합니다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 시뮬레이션 데이터와 실제 사용자 경험(RUM) 데이터가 어떻게 상호보완적으로 작용하여 성능 병목 현상을 찾아내는지 이해할 수 있습니다.
|
||||
- [[Distributed Tracing]]
|
||||
- Distributed Tracing
|
||||
- 연결 이유: RUM 도구가 프론트엔드의 사용자 동작을 백엔드의 서비스 요청과 연관 짓기 위해 사용하는 핵심 메커니즘입니다 [2, 4, 12].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 마이크로서비스 아키텍처 환경에서 클라이언트 에러의 근본 원인을 백엔드 데이터베이스나 외부 API까지 어떻게 추적하는지 원리를 파악할 수 있습니다.
|
||||
- [[Core Web Vitals]]
|
||||
- [[Core Web Vitals|Core Web Vitals]]
|
||||
- 연결 이유: RUM을 통해 주로 측정하고 최적화하려는 대상인 실제 사용자 중심의 로딩 속도, 상호작용, 시각적 안정성 지표입니다 [13, 14].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: RUM 데이터가 웹 성능 최적화의 기준(LCP, FID, CLS, INP)과 어떻게 매핑되어 사용자 경험(UX)을 수치화하는지 이해할 수 있습니다.
|
||||
|
||||
#### [관계 유형 B (구현/활용 도구)]
|
||||
- [[Datadog RUM]]
|
||||
- Datadog RUM
|
||||
- 연결 이유: 소스에서 엔드투엔드 프론트엔드-백엔드 모니터링을 연결해 주는 대표적인 RUM 플랫폼으로 소개되었습니다 [2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 분산 시스템에서 RUM을 활용하는 구체적인 사례와, 인덱싱 비용 최적화(Trade-off) 전략의 중요성을 학습할 수 있습니다.
|
||||
- [[Session Replay]]
|
||||
- Session Replay
|
||||
- 연결 이유: 사용자의 상태 변경, 콘솔 로그, 네트워크 요청 등을 마치 화면 녹화처럼 재현하는 RUM의 고급 디버깅 기능입니다 [7, 12, 15].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 스택 트레이스만으로 찾기 힘든 복잡한 사용자 상호작용 오류의 디버깅 방법론과 이에 따른 프라이버시 설정의 중요성을 알 수 있습니다.
|
||||
|
||||
@@ -53,9 +53,9 @@ Real User Monitoring (RUM)은 다양한 기기와 네트워크 조건에서 사
|
||||
- **My Project Relevance:** 현재 진행 중인 프론트엔드 프로젝트에서 사용자 이탈률이 높은 특정 화면의 병목 지점을 찾기 위해, RUM을 적용하여 실제 모바일 기기와 3G/LTE 환경에서의 INP(Interaction to Next Paint)와 렌더링 지연을 측정 및 개선할 때 활용합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[OpenTelemetry]]
|
||||
- OpenTelemetry
|
||||
- 확장 방향: 특정 벤더에 종속되지 않고(No vendor lock-in) 오픈 스탠다드 프로토콜을 이용해 RUM, 메트릭, 로그 데이터를 수집하고 백엔드와 연결하는 아키텍처로 지식을 확장할 수 있습니다 [16, 17].
|
||||
- [[Error Boundaries]]
|
||||
- [[Error Boundaries|Error Boundaries]]
|
||||
- 확장 방향: React 애플리케이션 내에서 UI 렌더링 중 발생하는 런타임 에러를 캡처하여 전체 앱의 크래시를 방지하는 개념으로, 여기서 포착된 에러를 RUM 시스템에 보고하는 방식으로 연계할 수 있습니다 [18-20].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Redux]]
|
||||
# [[Redux|Redux]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Redux는 예측 가능한 상태 컨테이너로, 불변성을 유지하는 업데이트, 액션 디스패치(action dispatch), 그리고 리듀서(reducer)를 통해 전역 상태를 관리하는 산업 표준 라이브러리이다 [1]. 주로 복잡한 파생 및 계산된 상태가 존재하거나 500개 이상의 컴포넌트를 다루는 대규모 애플리케이션에서 일관된 개발 패턴을 강제하기 위해 채택된다 [2]. RTK Query와 Redux DevTools 같은 성숙한 생태계를 통해 비동기 상태 관리의 복잡성을 줄이고 강력한 디버깅 기능을 제공한다 [2-4].
|
||||
@@ -13,19 +13,19 @@ Redux는 예측 가능한 상태 컨테이너로, 불변성을 유지하는 업
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[Context API]]
|
||||
- [[Context API|Context API]]
|
||||
- 연결 이유: Redux와 자주 비교되는 React의 내장 상태 공유 기능으로, 소규모 애플리케이션의 테마나 언어 설정 등을 관리하기 적합하지만, 상태 변경 시 발생하는 대규모 리렌더링 폭풍(Re-render Storm)을 유발하여 대규모 앱에서 Redux가 필요한 당위성을 제공한다 [8, 9, 16].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 구독 아키텍처의 차이가 React 컴포넌트의 리렌더링 성능에 미치는 치명적인 영향성 [8, 10].
|
||||
|
||||
- [[Zustand]]
|
||||
- Zustand
|
||||
- 연결 이유: Redux의 무거운 보일러플레이트와 Context API의 성능 문제 사이에서 적절한 타협점을 제공하는 경량 상태 관리 라이브러리이다 [17-19].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 관리 라이브러리의 과도한 유연성(Zustand)이 팀 단위 협업에서 어떻게 비동기 패턴의 파편화와 혼란을 야기할 수 있는지, 대조적으로 Redux의 엄격한 구조가 갖는 방어적 이점 [1, 11, 18, 20].
|
||||
|
||||
- [[RTK Query]]
|
||||
- RTK Query
|
||||
- 연결 이유: Redux Toolkit(RTK) 생태계에 포함된 데이터 패칭 및 캐싱 도구이다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Redux가 어떻게 단순한 클라이언트 상태 관리를 넘어 서버 API 응답(캐싱, 무효화, 재요청)이라는 현대적인 요구사항을 보일러플레이트 없이 소화하는지 파악 [4, 21].
|
||||
|
||||
- [[Time-Travel Debugging]]
|
||||
- Time-Travel Debugging
|
||||
- 연결 이유: Redux DevTools가 제공하는 고유의 강력한 기능으로, 언제 어떤 액션이 디스패치되어 상태가 어떻게 변경되었는지 기록하고 되감는 기술이다 [2, 3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 5년 이상 지속되는 엔터프라이즈 애플리케이션에서 아키텍처의 디버깅 역량이 개발자의 생산성 및 장애 대응에 미치는 영향 [11, 12].
|
||||
|
||||
@@ -44,9 +44,9 @@ Redux는 예측 가능한 상태 컨테이너로, 불변성을 유지하는 업
|
||||
- **My Project Relevance:** 글로벌 상태가 다수의 컴포넌트에 복잡하게 얽혀 있거나, 팀원 간 동일한 비동기/상태 관리 구조를 강제하여 파편화를 막아야 하는 애플리케이션을 구축할 때 핵심적인 기술 스택으로 검토될 수 있다 [1, 12].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Server State Management (TanStack Query 등)]]
|
||||
- Server State Management (TanStack Query 등)
|
||||
- 확장 방향: 클라이언트 전역 상태와 구별되는 "서버 데이터(API 캐싱, 동기화, 로딩/에러 사이클)"만을 전문적으로 처리하는 모던 라이브러리와 Redux의 역할 비교 및 연동 방안 탐색 [24, 25].
|
||||
- [[React Rendering Optimization]]
|
||||
- React Rendering Optimization
|
||||
- 확장 방향: 상태 관리 라이브러리의 선택과 별개로, React 컴포넌트 생명주기 및 메모이제이션(`useMemo`, `useCallback`, `React.memo`)이 애플리케이션 퍼포먼스에 미치는 원리와 프로파일링 방법 탐색 [26-28].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Rollup]]
|
||||
# [[Rollup|Rollup]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Rollup은 2025년 기준 최신 프론트엔드 빌드 도구인 Vite의 프로덕션 빌드를 백그라운드에서 담당하는 모듈 번들러입니다 [1]. 개발 단계에서는 네이티브 ES 모듈(ESM)을 사용하는 Vite가 실제 배포 시점에는 Rollup으로 전환하여 애플리케이션 코드를 병합하고 최적화합니다 [1, 2]. 자동 코드 분할(Code Splitting)과 사용하지 않는 코드를 제거하는 트리 쉐이킹(Tree-shaking) 기능을 통해 매우 최적화된 최종 에셋을 생성하는 것이 핵심 역할입니다 [1].
|
||||
@@ -18,18 +18,18 @@ Rollup은 2025년 기준 최신 프론트엔드 빌드 도구인 Vite의 프로
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처/기반 기술]
|
||||
- [[Vite]]
|
||||
- Vite
|
||||
- 연결 이유: Rollup은 Vite의 아키텍처 내에서 프로덕션 배포 시 최적화된 빌드를 수행하는 내부 엔진으로 작동합니다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 개발 모드(ESM)와 배포 모드(Rollup)를 다르게 가져가는 Vite의 하이브리드 번들링 아키텍처 전략을 이해할 수 있습니다 [1, 2].
|
||||
- [[Tree-shaking]]
|
||||
- [[Tree Shaking (번들 크기 최적화)|Tree-shaking]]
|
||||
- 연결 이유: Rollup이 배포용 코드를 최적화할 때 사용하지 않는 코드를 덜어내는 핵심 메커니즘입니다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: ES 모듈 기반 라이브러리 사용이 왜 최종 번들 사이즈 최적화에 필수적인지 파악할 수 있습니다 [10].
|
||||
|
||||
#### [구현/활용 도구]
|
||||
- [[manualChunks]]
|
||||
- manualChunks
|
||||
- 연결 이유: Rollup을 사용하여 거대한 메인 번들을 세분화된 벤더 청크(Vendor chunk)로 쪼갤 때 사용되는 핵심 설정입니다 [4-6].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저 캐싱을 극대화하기 위해 코드를 성격(변경 빈도)에 따라 분리하는 최적화 전략을 배울 수 있습니다 [6, 7].
|
||||
- [[Code Splitting]]
|
||||
- [[Code Splitting|Code Splitting]]
|
||||
- 연결 이유: Rollup의 기능과 React의 지연 로딩(`React.lazy`)을 결합하여 구현되는 성능 최적화 기법입니다 [3, 11].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 초기 페이로드(Payload)를 줄이고 Core Web Vitals를 개선하는 런타임 최적화 방법을 학습할 수 있습니다 [9, 12].
|
||||
|
||||
@@ -48,9 +48,9 @@ Rollup은 2025년 기준 최신 프론트엔드 빌드 도구인 Vite의 프로
|
||||
- **My Project Relevance:** Vite 기반 React 애플리케이션을 Vercel이나 AWS 서버에 배포하기 전에 빌드 속도 및 초기 다운로드 속도를 개선하기 위한 필수 점검 단계로 활용합니다 [2, 11].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[ES Modules (ESM)]]
|
||||
- ES Modules (ESM)
|
||||
- 확장 방향: Rollup의 프로덕션 빌드 이전, Vite가 개발 환경에서 코드 변경 사항을 즉각적으로 브라우저에 반영하는 원리 파악 [1, 15].
|
||||
- [[Core Web Vitals]]
|
||||
- [[Core Web Vitals|Core Web Vitals]]
|
||||
- 확장 방향: Rollup의 번들 분할 및 경량화 작업이 LCP(Largest Contentful Paint)나 INP(Interaction to Next Paint)와 같은 브라우저 성능 측정 지표를 어떻게 개선하는지 조사 [9, 14].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Scalable Frontend Systems]]
|
||||
# [[Scalable Frontend Systems|Scalable Frontend Systems]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
대규모 프론트엔드 시스템(Scalable Frontend Systems)은 높은 유지보수성, 고성능, 확장성을 보장하기 위해 기존의 단순한 스크립트 실행을 넘어 정교하게 분산된 소프트웨어 아키텍처를 도입한 시스템입니다 [1]. 기능별 또는 도메인 중심의 모듈형 폴더 구조를 사용하며, SOLID와 같은 클린 코드 원칙을 준수하고 애플리케이션 상태와 서버 상태를 분리하여 관리합니다 [2-4]. 더불어 자동화된 빌드 최적화, 예측 가능한 렌더링 최적화, 정교한 에러 처리 및 협업 워크플로우를 결합하여 애플리케이션이 안정적으로 성장할 수 있도록 지원합니다 [1, 5].
|
||||
@@ -16,23 +16,23 @@
|
||||
|
||||
### Related Concepts
|
||||
|
||||
- [[Feature-Sliced Design (FSD)]]
|
||||
- [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD)]]
|
||||
- 연결 이유: 확장 가능한 프론트엔드 아키텍처에서 빈번하게 발생하는 '비즈니스 로직 얽힘' 문제를 해결하기 위해 도입된 핵심적인 컴포넌트/디렉토리 분할 방법론입니다 [33, 34].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단방향 의존성 흐름, 계층별(Layered) 분할, 캡슐화를 통한 Public API 인터페이스 설계 원리 [7, 9].
|
||||
|
||||
- [[State Management Fragmentation (상태 관리 파편화)]]
|
||||
- State Management Fragmentation (상태 관리 파편화)
|
||||
- 연결 이유: 대규모 애플리케이션에서 단일 스토어나 Context API만으로는 리렌더링 성능 최적화가 불가능해짐에 따라, 전역 상태(Zustand), 서버 상태(React Query), 로컬 상태로 역할을 분리하여 관리하는 트렌드입니다 [4, 13, 35].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 불필요한 렌더링 방지 원리(Zustand의 선택자 패턴)와 서버/클라이언트 데이터 간의 캐싱 및 동기화 전략 [4, 14].
|
||||
|
||||
- [[React Compiler]]
|
||||
- [[React Compiler|React Compiler]]
|
||||
- 연결 이유: 개발자가 수동으로 수행하던 `useMemo`, `useCallback`, `React.memo` 등의 메모이제이션을 빌드 타임에 자동으로 처리해 주어, 깔끔한 코드를 유지하면서 성능 확장을 가능케 하는 최신 도구입니다 [19, 36].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: React의 렌더링 최적화 한계 및 Rules of React 준수 중요성, 써드파티 라이브러리와의 호환성 문제 [37, 38].
|
||||
|
||||
- [[Error Boundaries]]
|
||||
- [[Error Boundaries|Error Boundaries]]
|
||||
- 연결 이유: 시스템의 크기가 커질 때 단일 컴포넌트의 오류가 전체 앱의 '화이트 스크린' 크래시로 이어지지 않게 UI의 일부분만 대체(Fallback)하여 시스템 복원력(Resilience)을 보장하는 장치입니다 [23, 24, 39].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클래스형 컴포넌트 생명주기를 활용한 런타임 에러 포착 원리 및 대규모 UI 보호 전략 [40, 41].
|
||||
|
||||
- [[Code Splitting & Lazy Loading (코드 분할과 지연 로딩)]]
|
||||
- Code Splitting & Lazy Loading (코드 분할과 지연 로딩)
|
||||
- 연결 이유: 프론트엔드 코드가 비대해지면서 초기 로딩 속도(TTI, LCP)를 최적화하기 위해 필수적으로 요구되는 기술로, Vite나 React.lazy를 통해 필요한 시점에만 모듈을 다운로드하게 합니다 [15, 17, 42].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 모듈 번들러의 청크(Chunk) 분리 원리 및 브라우저 성능 최적화(Core Web Vitals)와 번들 사이즈의 상관관계 [43, 44].
|
||||
|
||||
@@ -54,11 +54,11 @@
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Frontend Cloud Logging Tools (프론트엔드 클라우드 로깅 도구)]]
|
||||
- Frontend Cloud Logging Tools (프론트엔드 클라우드 로깅 도구)
|
||||
- 확장 방향: 확장 가능한 시스템이 프로덕션 단계에 들어갔을 때, Sentry나 Datadog, SigNoz 같은 모니터링 툴을 활용해 사용자 세션과 에러 로그를 연동하여 가시성(Observability)을 확보하는 방향으로 확장할 수 있습니다 [58-60].
|
||||
- [[Storybook Visual Regression Testing (Storybook 시각적 회귀 테스트)]]
|
||||
- Storybook Visual Regression Testing (Storybook 시각적 회귀 테스트)
|
||||
- 확장 방향: 대규모 팀에서 UI 컴포넌트를 변경할 때, 기존 화면(baseline)의 레이아웃이나 픽셀이 의도치 않게 깨지는 것을 방지하기 위한 자동화된 시각적 회귀 검증(Happo, Chromatic) 및 CI 파이프라인 연동 방향으로 확장할 수 있습니다 [61-63].
|
||||
- [[Git Branching Strategies & Workflows (Git 브랜치 전략 및 워크플로우)]]
|
||||
- Git Branching Strategies & Workflows (Git 브랜치 전략 및 워크플로우)
|
||||
- 확장 방향: 어플리케이션 확장뿐만 아니라 참여하는 개발자 수가 많아질 때, Trunk-based 개발이나 GitHub Flow 등을 도입하여 충돌을 줄이고 티켓 기반 추적성을 확보하는 형상관리 방향으로 확장할 수 있습니다 [31, 64].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Storybook]]
|
||||
# [[Storybook|Storybook]]
|
||||
|
||||
## 📌 Brief 주Summary
|
||||
Storybook은 프론트엔드 개발 시 UI 컴포넌트를 주 애플리케이션과 격리하여 개발하고 문서화할 수 있도록 돕는 도구입니다 [1-3]. 특히 개발된 컴포넌트의 다양한 상태(스토리)를 기반으로 자동화된 시각적 회귀 테스트(Visual Regression Testing) 및 상호작용 테스트(Interaction Testing)를 수행하여 의도치 않은 UI 변경이나 접근성 위반을 방지합니다 [4-6]. Pull Request 과정에 결합되어 안전한 UI 업데이트와 리뷰를 지원하는 필수적인 플랫폼으로 활용됩니다 [1, 7].
|
||||
@@ -25,20 +25,20 @@ Storybook은 프론트엔드 개발 시 UI 컴포넌트를 주 애플리케이
|
||||
### Related Concepts
|
||||
|
||||
#### [테스트 및 검증 기법 (Testing Methods)]
|
||||
- [[Visual Regression Testing]]
|
||||
- [[Visual Regression Testing|Visual Regression Testing]]
|
||||
- 연결 이유: Storybook이 컴포넌트의 변경 사항을 픽셀 단위로 확인하기 위해 사용하는 핵심 테스트 방법론입니다 [4, 8].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: HTML 마크업을 비교하는 Snapshot Test의 한계점과 오탐(False Positive)의 원리, 그리고 픽셀 렌더링 기반 비교의 장점을 명확히 이해할 수 있습니다 [9].
|
||||
|
||||
- [[Interaction Testing]]
|
||||
- Interaction Testing
|
||||
- 연결 이유: 컴포넌트의 단순한 렌더링뿐만 아니라 유저의 행동(이벤트, 상태 등)을 시뮬레이션하여 다양한 UI 상태(로딩, 호버 등)를 검증하는 Storybook의 기능입니다 [5, 6].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 전이에 따라 동적으로 변하는 UI를 어떻게 시각적 테스트와 결합하여 검증할 수 있는지 원리를 파악할 수 있습니다 [5].
|
||||
|
||||
#### [통합 및 자동화 도구 (Integration Tools)]
|
||||
- [[Chromatic]]
|
||||
- Chromatic
|
||||
- 연결 이유: Storybook 유지보수 팀이 만든 공식 클라우드 서비스로, 크로스 브라우저 시각적 테스트와 CI 통합을 네이티브로 지원합니다 [8, 15].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클라우드 환경에서 베이스라인(Baseline) 이미지가 어떻게 저장, 비교, 동기화되는지 CI/CD 파이프라인 통합 과정을 이해할 수 있습니다 [7, 13].
|
||||
|
||||
- [[Happo]]
|
||||
- Happo
|
||||
- 연결 이유: Storybook과 통합되어 다중 브라우저 스크린샷 테스트 및 접근성 회귀 테스트를 병렬로 수행하는 시각적 테스트 도구입니다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Flakiness 방지를 위해 애니메이션을 정지하거나 색상 오차 범위(color-delta tolerance)를 설정하여 시각적 노이즈를 줄이는 구체적 최적화 기법을 알 수 있습니다 [11, 14].
|
||||
|
||||
@@ -57,9 +57,9 @@ Storybook은 프론트엔드 개발 시 UI 컴포넌트를 주 애플리케이
|
||||
- **My Project Relevance:** 현재 유지보수 중인 애플리케이션의 리팩토링이나 새로운 디자인 시스템(UI 라이브러리) 구축 작업 시, 실수로 발생하는 CSS/레이아웃 깨짐을 사전에 방지하기 위한 안전장치로 도입할 수 있습니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Pull Request Workflow]]
|
||||
- Pull Request Workflow
|
||||
- 확장 방향: Storybook 시각적 테스트의 결과를 GitHub, GitLab 등의 리뷰 프로세스와 결합하여, 버그 없는 UI 코드를 배포하기 위한 협업 및 검증 파이프라인 구축 전략으로 확장합니다.
|
||||
- [[Feature-Sliced Design]]
|
||||
- [[Feature-Sliced Design|Feature-Sliced Design]]
|
||||
- 확장 방향: 프론트엔드 코드를 기능(Feature) 단위로 분리할 때, Storybook을 이용해 각 기능의 UI 컴포넌트들을 메인 앱에 의존하지 않고 독립적으로 작동하게 만드는 설계 원칙으로 확장합니다.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Index: Development > UI_Components
|
||||
|
||||
## 📝 Documents
|
||||
- [[Accordion]]
|
||||
- [[Accordion|Accordion]]
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Visual Regression Testing]]
|
||||
# [[Visual Regression Testing|Visual Regression Testing]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
시각적 회귀 테스트(Visual Regression Testing)는 스토리북(Storybook) 등의 도구로 렌더링된 컴포넌트의 픽셀 단위 스크린샷을 캡처하여 이전에 알려진 "정상(baseline)" 상태의 스크린샷과 자동으로 비교하는 테스트 방식이다 [1, 2]. 이를 통해 개발자는 풀 리퀘스트(PR) 과정에서 의도치 않은 UI 레이아웃, 색상, 타이포그래피 등의 시각적 변경이나 결함을 찾아낼 수 있다 [3-5]. HTML 마크업만 비교하는 기존의 스냅샷 테스트와 달리, 실제 사용자가 경험하는 화면 픽셀을 직접 검증하므로 추가적인 테스트 코드 작성이나 유지보수 부담을 줄이면서도 오탐(false positive)을 최소화할 수 있는 것이 특징이다 [1, 2].
|
||||
@@ -18,18 +18,18 @@
|
||||
### Related Concepts
|
||||
|
||||
#### [테스트 및 검증 기술]
|
||||
- [[Snapshot Testing]]
|
||||
- Snapshot Testing
|
||||
- 연결 이유: 시각적 회귀 테스트와 대조되는 테스트 방식으로, 픽셀이 아닌 렌더링된 HTML 마크업 코드 덩어리를 비교한다 [2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: HTML 구조 비교 방식이 왜 빈번하게 오탐(False Positive)을 발생시키는지, 그리고 픽셀 기반 비교가 유지보수에 왜 더 유리한지 명확하게 이해할 수 있다 [2].
|
||||
- [[Interaction Testing]]
|
||||
- Interaction Testing
|
||||
- 연결 이유: 사용자의 상호작용이나 이벤트를 시뮬레이션하여 컴포넌트의 특정 UI 상태를 유도하는 테스트 방식이다 [5, 10].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 정적 UI 화면뿐만 아니라 로딩, 에러, 클릭 시 드롭다운 오픈 등 동적으로 변화하는 UI 상태를 시각적 회귀 테스트가 어떻게 캡처하고 검증하는지 파악할 수 있다 [9, 10].
|
||||
|
||||
#### [구현 및 활용 도구]
|
||||
- [[Storybook]]
|
||||
- [[Storybook|Storybook]]
|
||||
- 연결 이유: UI 컴포넌트를 애플리케이션의 복잡한 로직과 분리하여 격리된 환경에서 시각적으로 개발하고 문서화할 수 있게 해주는 도구이다 [3, 6].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 시각적 회귀 테스트가 전체 페이지 단위가 아닌 개별 컴포넌트의 상태(Story) 단위로 렌더링되고 기준선과 비교되는 아키텍처적 기반을 이해할 수 있다 [1].
|
||||
- [[Chromatic]] / [[Happo]]
|
||||
- Chromatic / Happo
|
||||
- 연결 이유: Storybook과 연결되어 실제 브라우저 기반의 스크린샷 캡처, 베이스라인 픽셀 비교, CI/CD 연동 등을 수행하는 시각적 회귀 테스트 클라우드 서비스(도구)이다 [1, 3, 4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 자동화된 시각적 회귀 테스트가 브라우저 간의 렌더링 차이를 어떻게 병렬로 처리하고 풀 리퀘스트(PR) 프로세스와 어떻게 상호작용하는지 확인할 수 있다 [4, 12].
|
||||
|
||||
@@ -48,9 +48,9 @@
|
||||
- **My Project Relevance:** 프론트엔드 레거시 코드를 리팩토링하거나 수백 개의 화면에서 공유되는 코어 UI 라이브러리 버전을 업그레이드할 때, 다른 팀의 컴포넌트에서 발생하는 의도치 않은 파급 효과(Side Effect) 및 시각적 깨짐을 안전하게 감지하고 확신을 갖고 배포하는 데 핵심적인 역할을 한다 [3, 16].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Accessibility Regression Testing]]
|
||||
- Accessibility Regression Testing
|
||||
- 확장 방향: 시각적 테스트 워크플로우와 결합하여, 새로운 테스트 코드를 별도로 작성할 필요 없이 스크린샷 실행 단계에서 UI의 접근성 위반(명도 대비 부족, 키보드 포커스 누락 등)까지 동시에 자동 검증하는 영역으로 확장할 수 있다 [9, 10].
|
||||
- [[Continuous Integration (CI) Pipelines]]
|
||||
- Continuous Integration (CI) Pipelines
|
||||
- 확장 방향: GitHub Actions, CircleCI 등의 CI 도구에서 시각적 테스트 인프라가 어떻게 연동되며, 코드가 병합되기 전에 PR의 상태 체크(Status Check)를 필수로 제어하는 자동화 파이프라인 및 DevOps 프로세스로 학습을 넓힐 수 있다 [12].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Vite + React 성능 최적화]]
|
||||
# [[Vite + React 성능 최적화|Vite + React 성능 최적화]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Vite와 React 환경에서 애플리케이션의 성능을 최적화하는 것은 초기 로딩 속도를 높이고 런타임 성능을 향상시켜 전반적인 사용자 경험을 개선하는 과정입니다. 개발 환경에서는 기본 ES 모듈(ESM)을, 운영 환경에서는 Rollup을 통한 번들링을 활용하는 Vite의 구조적 이점을 극대화하는 것이 핵심입니다. 주요 최적화 기법으로는 빠른 컴파일을 위한 SWC 도입, 동적 임포트를 통한 코드 분할, `manualChunks`를 활용한 무거운 벤더 라이브러리 분리, 그리고 번들 시각화 도구를 통한 불필요한 의존성 제거 등이 포함됩니다.
|
||||
@@ -26,24 +26,24 @@ Vite와 React 환경에서 애플리케이션의 성능을 최적화하는 것
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/기반 기술)]
|
||||
- [[네이티브 ES 모듈(ESM)]]
|
||||
- 네이티브 ES 모듈(ESM)
|
||||
- 연결 이유: Vite가 개발 환경에서 코드 모듈을 서빙하는 방식의 핵심 기반 원리입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 번들러가 전체 앱을 매번 빌드하지 않고 변경된 모듈만 요청/로드함으로써 프로젝트 크기에 상관없이 빠른 HMR과 응답성을 유지하는 메커니즘을 파악할 수 있습니다 [1, 29, 30].
|
||||
|
||||
- [[Rollup]]
|
||||
- [[Rollup|Rollup]]
|
||||
- 연결 이유: Vite 환경에서 프로덕션 배포 시 코드를 하나로 모으고 최적화하는 데 사용되는 번들러입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Vite의 설정 파일(`vite.config.js`)에서 `manualChunks` 등 Rollup 전용 빌드 옵션을 통해 어떻게 효율적인 정적 애셋(Asset)을 생성하고, 코드 분할과 트리 쉐이킹을 수행하는지 이해할 수 있습니다 [14, 18, 31, 32].
|
||||
|
||||
#### [관계 유형 B (구현/활용 도구)]
|
||||
- [[SWC 컴파일러]]
|
||||
- SWC 컴파일러
|
||||
- 연결 이유: Vite의 기본 구성을 확장해 속도를 향상시키기 위한 강력한 도구입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 과거 Babel이 처리하던 JSX/TypeScript 변환 작업을 Rust 기반의 빠른 도구(`@vitejs/plugin-react-swc`)로 교체하여 대형 React 애플리케이션의 재빌드 시간을 즉각적으로 단축시키는 방식을 파악할 수 있습니다 [1, 3, 5].
|
||||
|
||||
- [[React.lazy & Suspense]]
|
||||
- React.lazy & Suspense
|
||||
- 연결 이유: React 내부에서 동적 임포트를 통한 컴포넌트 레벨 지연 로딩을 구현하기 위한 API입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 라우트나 무거운 모듈을 분리하고, 번들이 로드되는 동안 `<Suspense>`를 통해 폴백(Fallback) UI를 처리함으로써 초기 자바스크립트 페이로드 용량을 대폭 줄이는 실무 기법을 배울 수 있습니다 [6, 9, 11, 12, 33].
|
||||
|
||||
- [[rollup-plugin-visualizer]]
|
||||
- rollup-plugin-visualizer
|
||||
- 연결 이유: 최적화 작업 전후로 번들 크기를 시각화하고 문제를 진단하는 필수 분석 플러그인입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 큰 청크가 왜 발생하는지, 어떤 외부 라이브러리(벤더)가 의도치 않게 용량을 과도하게 점유하는지 분석하여 `manualChunks`나 코드 교체를 결단하는 측정/디버깅 기반을 확립할 수 있습니다 [6, 13, 21].
|
||||
|
||||
@@ -65,10 +65,10 @@ Vite와 React 환경에서 애플리케이션의 성능을 최적화하는 것
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Core Web Vitals]]
|
||||
- [[Core Web Vitals|Core Web Vitals]]
|
||||
- 확장 방향: Vite와 React 최적화를 통해 얻어낸 메인 번들 크기 감소 및 렌더링 속도 향상이 실제 사용자 체감 성능 지표(LCP, FID/INP 등)에 어떤 수치적 개선으로 나타나는지를 구체적으로 연구합니다 [11, 34, 35].
|
||||
|
||||
- [[Concurrent Rendering (동시성 렌더링)]]
|
||||
- Concurrent Rendering (동시성 렌더링)
|
||||
- 확장 방향: 로딩과 번들링 최적화뿐만 아니라, `useTransition` 및 `useDeferredValue` 훅을 이용하여 복잡한 데이터 변화 시에도 사용자 입력 등의 UI 반응성을 유지하는 런타임 차원의 성능 향상 전략으로 지식을 확장합니다 [36-38].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Vite Build System]]
|
||||
# [[Vite Build System|Vite Build System]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Vite는 현대 프론트엔드 애플리케이션(특히 React) 개발을 위한 새로운 산업 표준 빌드 도구로, 거의 즉각적인 서버 시작과 초고속 HMR(Hot Module Replacement)을 제공합니다 [1, 2]. 기존 번들러와 달리 개발 환경에서는 브라우저에 네이티브 ES 모듈 형태로 코드를 제공하고, 프로덕션 환경에서는 Rollup을 사용하여 고도로 최적화된 번들을 생성하는 하이브리드 아키텍처를 사용합니다 [3, 4]. 또한 SWC나 esbuild와 같은 Rust 기반 컴파일러를 활용하여 대규모 프로젝트에서도 빠르고 원활한 개발자 경험을 보장합니다 [3, 5, 6].
|
||||
@@ -12,19 +12,19 @@ Vite는 현대 프론트엔드 애플리케이션(특히 React) 개발을 위한
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[Native ES Modules (ESM)]]
|
||||
- Native ES Modules (ESM)
|
||||
- 연결 이유: Vite가 개발 환경에서 파일 전체를 사전 번들링하지 않고, 필요할 때 브라우저에 코드를 제공하는 핵심 메커니즘이기 때문입니다 [3, 7].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Vite가 기존 도구(Webpack 등)에 비해 어떻게 초기 구동 속도와 HMR 응답성을 극적으로 단축할 수 있는지 그 원리를 파악할 수 있습니다 [2, 3].
|
||||
|
||||
- [[Rollup]]
|
||||
- [[Rollup|Rollup]]
|
||||
- 연결 이유: Vite가 프로덕션용 빌드를 생성할 때 내부적으로 채택하고 있는 번들러 도구이기 때문입니다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프로덕션 환경에서 청크가 어떻게 나뉘며(`manualChunks`), 코드 스플리팅과 트리 쉐이킹을 통해 최적화된 정적 자산이 만들어지는 과정을 이해할 수 있습니다 [4, 8, 11].
|
||||
|
||||
- [[SWC (Speedy Web Compiler)]]
|
||||
- SWC (Speedy Web Compiler)
|
||||
- 연결 이유: Vite 환경에서 기존의 Babel을 대체하여 JSX와 TypeScript를 실시간에 가깝게 변환하는 Rust 기반 컴파일러 기술이기 때문입니다 [3, 5, 6].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 React 애플리케이션 개발 시 컴파일 속도와 핫 리로드 속도를 향상하는 기술적 배경을 깊이 이해할 수 있습니다 [3, 6].
|
||||
|
||||
- [[Code Splitting & manualChunks]]
|
||||
- Code Splitting & manualChunks
|
||||
- 연결 이유: 대용량 메인 번들 문제를 해결하고, 초기 페이지 로드 속도를 높이기 위한 Vite 성능 최적화의 핵심 기법이기 때문입니다 [12, 14].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 동적 임포트와 결합하여 벤더 라이브러리(안정적인 코드)를 별도 파일로 캐싱하고 기능 단위로 청크를 나누는 전략을 학습할 수 있습니다 [8, 16].
|
||||
|
||||
@@ -43,9 +43,9 @@ Vite는 현대 프론트엔드 애플리케이션(특히 React) 개발을 위한
|
||||
- **My Project Relevance:** 소스에 관련 정보가 부족합니다. (개인의 현재 진행 중인 특정 프로젝트에 대한 정보가 소스 텍스트에 포함되어 있지 않습니다.)
|
||||
|
||||
### Adjacent Topics
|
||||
- [[React Server Components (RSC) & Next.js App Router]]
|
||||
- React Server Components (RSC) & Next.js App Router
|
||||
- 확장 방향: Vite를 이용한 빌드 툴 체인 최적화(CSR/SPA 성능 최적화)를 넘어, 클라이언트 측 자바스크립트 번들 자체를 전송하지 않고 서버에서 미리 렌더링하는 아키텍처 수준의 성능 최적화 패러다임으로 이해를 넓힙니다 [21-23].
|
||||
- [[Performance Metrics (Core Web Vitals)]]
|
||||
- Performance Metrics (Core Web Vitals)
|
||||
- 확장 방향: Vite의 청크 최적화와 레이지 로딩 기법이 실제 사용자 체감 성능 지표인 FCP(First Contentful Paint), LCP(Largest Contentful Paint), INP(Interaction to Next Paint)에 어떤 직접적인 영향을 미치는지 연결하여 학습합니다 [13, 24, 25].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Vite Build Tool]]
|
||||
# [[Vite Build Tool|Vite Build Tool]]
|
||||
|
||||
## 📌 Brief 임무
|
||||
Vite는 현대 프론트엔드 애플리케이션(주로 React)을 위한 표준 빌드 도구로, 기존 Webpack 및 Create React App(CRA)을 대체하며 빠르게 자리 잡았습니다 [1, 2]. 이 도구는 개발 환경에서는 브라우저의 네이티브 ES 모듈(ESM)을 활용해 즉각적인 서버 시작과 초고속 HMR(Hot Module Replacement)을 제공합니다 [2-4]. 프로덕션 배포 시에는 내부적으로 Rollup을 사용하여 코드 스플리팅과 트리 쉐이킹이 적용된 고도로 최적화된 번들을 생성하는 하이브리드 아키텍처를 특징으로 합니다 [5, 6].
|
||||
@@ -28,20 +28,20 @@ Vite는 현대 프론트엔드 애플리케이션(주로 React)을 위한 표준
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처/기반 기술]
|
||||
- [[Native ES Modules (ESM)]]
|
||||
- Native ES Modules (ESM)
|
||||
- 연결 이유: Vite가 개발 단계에서 빠른 구동 속도를 달성하기 위해 활용하는 브라우저의 기본 모듈 시스템입니다 [2, 4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 과거 도구(Webpack)의 무거운 사전 번들링 방식과 대비되는 Vite의 '요청 시 제공(On-demand serving)' 메커니즘의 원리.
|
||||
|
||||
- [[Rollup]]
|
||||
- [[Rollup|Rollup]]
|
||||
- 연결 이유: Vite의 프로덕션 빌드를 담당하는 내부 번들러입니다 [5, 6].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 배포 환경에서 어떻게 `manualChunks`를 활용하여 번들을 분할하고, 트리 쉐이킹을 통해 최적화된 결과물을 도출하는지 그 과정 [10, 16].
|
||||
|
||||
- [[SWC]]
|
||||
- SWC
|
||||
- 연결 이유: 기존의 Babel을 대체하여 JSX와 TypeScript 컴파일을 엄청나게 빠른 속도로 처리하는 Rust 기반 트랜스포머입니다 [4, 7, 8].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Vite 환경에서 React 애플리케이션의 핫 리로드와 빌드 퍼포먼스를 한 차원 끌어올리는 컴파일러의 역할.
|
||||
|
||||
#### [최적화 기법]
|
||||
- [[Code Splitting & manualChunks]]
|
||||
- Code Splitting & manualChunks
|
||||
- 연결 이유: 500kB 이상의 거대한 메인 번들 경고 문제를 해결하기 위해 Vite/Rollup 환경에서 벤더 코드와 앱 코드를 나누는 핵심 기법입니다 [6, 14, 15].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저 병렬 다운로드와 효율적인 캐시 무효화 전략, 초기 페이로드 최소화 방법 [17, 19].
|
||||
|
||||
@@ -63,9 +63,9 @@ Vite는 현대 프론트엔드 애플리케이션(주로 React)을 위한 표준
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Webpack]]
|
||||
- Webpack
|
||||
- 확장 방향: Vite가 등장하기 전 업계 표준이었으나 시작 전 전체 번들링 과정으로 인해 무거운 구조를 가진 Webpack의 한계와 Vite와의 아키텍처 비교 [1, 2].
|
||||
- [[Core Web Vitals]]
|
||||
- [[Core Web Vitals|Core Web Vitals]]
|
||||
- 확장 방향: Vite의 청크 분할 및 지연 로딩 기법이 실제 사용자 경험 지표인 FCP(First Contentful Paint), LCP(Largest Contentful Paint), INP(Interaction to Next Paint)에 어떻게 직결되는지 탐구 [17, 20].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[대규모 프론트엔드 애플리케이션]]
|
||||
# [[대규모 프론트엔드 애플리케이션|대규모 프론트엔드 애플리케이션]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
대규모 프론트엔드 애플리케이션은 단순한 스크립트 실행을 넘어 확장성, 유지보수성, 고성능을 요구하는 고도로 정교한 분산 소프트웨어 시스템입니다. 비즈니스 로직과 UI의 분리, 명확한 상태 소유권, 엄격한 폴더 구조(Feature-Sliced Design 등)를 통해 아키텍처의 붕괴를 방지합니다. 또한, 코드 스플리팅, 자동 메모이제이션, 세분화된 상태 관리 도구를 활용하여 최적의 렌더링 성능과 사용자 경험을 유지하는 것이 핵심입니다.
|
||||
@@ -24,19 +24,19 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[Feature-Sliced Design (FSD)]]
|
||||
- [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD)]]
|
||||
- 연결 이유: 대규모 프론트엔드 프로젝트의 폴더 구조와 모듈 의존성을 통제하는 핵심 아키텍처 방법론입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비즈니스 도메인과 UI를 어떻게 계층적으로 분리하고, 순환 참조 및 강한 결합을 어떻게 방지할 수 있는지 이해할 수 있습니다.
|
||||
- [[상태 관리 (State Management)]]
|
||||
- [[상태 관리(State Management)|상태 관리 (State Management)]]
|
||||
- 연결 이유: 대규모 앱에서는 전역 상태, 서버 상태, 로컬 상태를 명확히 분리해야 확장 및 성능 유지가 가능합니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Context API의 성능적 한계(리렌더링 폭풍)와 Zustand의 Selector 패턴, TanStack Query를 통한 서버 상태 캐싱 원리를 이해할 수 있습니다.
|
||||
- [[성능 최적화 (Performance Optimization)]]
|
||||
- [[성능 최적화(Performance Optimization)|성능 최적화 (Performance Optimization)]]
|
||||
- 연결 이유: 대규모 코드베이스는 필연적으로 번들 크기 증가와 렌더링 병목을 초래하므로 이를 제어하는 기술이 필수적입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: React Compiler의 자동화된 메모이제이션 원리, Vite의 manualChunks를 통한 번들 분할, React.lazy 기반의 코드 스플리팅 적용 방식을 파악할 수 있습니다.
|
||||
- [[에러 바운더리 (Error Boundaries)]]
|
||||
- 에러 바운더리 (Error Boundaries)
|
||||
- 연결 이유: 컴포넌트 하나의 오류가 전체 앱의 크래시로 이어지지 않게 막아주는 대규모 시스템의 필수 안전망입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트 트리 내에서 에러를 격리하는 원리와 런타임 에러를 우아하게 처리(Graceful degradation)하는 방법을 배울 수 있습니다.
|
||||
- [[메모리 누수 (Memory Leaks)]]
|
||||
- [[메모리 누수(Memory Leaks)|메모리 누수 (Memory Leaks)]]
|
||||
- 연결 이유: 앱 사용 시간이 길어질수록 성능을 심각하게 저하시키는 숨은 원인입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클로저(Closure)나 Detached DOM에 의해 가비지 컬렉터가 메모리를 회수하지 못하는 구조적 원인과 DevTools를 활용한 디버깅 기법을 이해할 수 있습니다.
|
||||
|
||||
@@ -55,9 +55,9 @@
|
||||
- **My Project Relevance:** 팀 단위의 협업 시 ESLint, Prettier, Husky를 도입해 아키텍처 규칙(다른 Feature에 직접 접근 금지 등)을 자동 강제하고, 코드 리뷰 시 일관된 아키텍처 원칙을 기준으로 삼을 수 있습니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[마이크로 프론트엔드 (Micro-Frontends)]]
|
||||
- [[마이크로 프론트엔드 (Micro Frontends)|마이크로 프론트엔드 (Micro-Frontends)]]
|
||||
- 확장 방향: 단일 저장소(Monorepo) 및 모듈화의 한계를 넘어, 초대형 엔터프라이즈 환경에서 여러 팀이 프론트엔드를 독립적으로 배포하고 운영하기 위한 런타임 통합 아키텍처로 지식을 확장합니다.
|
||||
- [[시각적 회귀 테스트 (Visual Regression Testing)]]
|
||||
- 시각적 회귀 테스트 (Visual Regression Testing)
|
||||
- 확장 방향: Storybook을 활용한 컴포넌트 고립 개발을 넘어서, Happo, Chromatic 등의 도구를 통해 코드 변경이 UI나 접근성(Accessibility)에 의도치 않은 파괴적 영향을 미쳤는지 자동 검증하는 QA 고도화 영역으로 확장합니다.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[비동기 데이터 관리]]
|
||||
# [[비동기 데이터 관리|비동기 데이터 관리]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
비동기 데이터 관리(서버 상태 관리)는 API에서 가져온 데이터를 클라이언트 측 애플리케이션 상태와 명확히 분리하여 처리하는 것을 의미합니다 [1]. 이는 네트워크 요청에 따른 데이터 캐싱, 동기화, 로딩 및 에러 사이클 관리를 포함하며, 현대 프론트엔드 시스템 아키텍처의 핵심 요소입니다 [1, 2]. 대규모 앱에서는 RTK Query나 TanStack Query(React Query)와 같은 특화된 도구를 사용하여 비동기 보일러플레이트를 줄이고 효율적인 캐시 관리를 수행합니다 [1, 3, 4].
|
||||
@@ -23,19 +23,19 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[TanStack Query 및 RTK Query]]
|
||||
- TanStack Query 및 RTK Query
|
||||
- 연결 이유: 서버 상태(API 데이터) 관리에 있어 캐싱, 중복 요청 제거, 자동 재요청 등을 처리하기 위한 현대적인 필수 표준 도구로 소스에서 강조되고 있기 때문입니다 [1, 2, 4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비동기 데이터 관리에서 발생하는 보일러플레이트 감소 원리와 데이터 동기화 메커니즘.
|
||||
|
||||
- [[서버 상태 (Server State)]]
|
||||
- 서버 상태 (Server State)
|
||||
- 연결 이유: API로부터 패치(fetch)되는 데이터는 클라이언트 상태와 성격이 완전히 달라 별도의 관리가 필요하다는 비동기 관리의 핵심 전제이기 때문입니다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 캐싱 로딩, 에러 사이클, 서버 데이터 최신화 기법.
|
||||
|
||||
- [[디바운싱(Debouncing) 및 쓰로틀링(Throttling)]]
|
||||
- 디바운싱(Debouncing) 및 쓰로틀링(Throttling)
|
||||
- 연결 이유: 잦은 사용자 이벤트로 인해 발생하는 무분별한 비동기 API 호출을 제어하여 성능을 최적화하는 구체적인 전략이기 때문입니다 [6, 7].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프론트엔드에서의 네트워크 최적화 및 런타임 병목 현상 방지.
|
||||
|
||||
- [[클린업 (Cleanup) 함수와 메모리 누수]]
|
||||
- 클린업 (Cleanup) 함수와 메모리 누수
|
||||
- 연결 이유: 비동기 작업 완료 전 컴포넌트가 언마운트되었을 때 발생할 수 있는 자원 낭비와 메모리 누수를 막는 필수 규칙이기 때문입니다 [8, 9].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: React 생명주기(Lifecycle)와 결합된 안전한 비동기 처리 방법.
|
||||
|
||||
@@ -54,9 +54,9 @@
|
||||
- **My Project Relevance:** 실시간 알림, 방대한 데이터의 무한 스크롤, 사용자 검색 시의 자동완성(디바운스 적용) 기능 등 복잡한 API 기반 기능이 있는 프로젝트의 성능 및 아키텍처 개선에 직접 적용됩니다 [2, 6, 7].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[상태 관리 아키텍처 (State Management Architecture)]]
|
||||
- 상태 관리 아키텍처 (State Management Architecture)
|
||||
- 확장 방향: 비동기 데이터 관리(서버 상태)와 로컬 상태, 전역 애플리케이션 상태가 애플리케이션 내에서 어떻게 상호작용하고 조화롭게 구성되는지 확장해서 알아봅니다 [1, 14].
|
||||
- [[성능 프로파일링 및 렌더링 최적화 (Performance Profiling & Rendering Optimization)]]
|
||||
- 성능 프로파일링 및 렌더링 최적화 (Performance Profiling & Rendering Optimization)
|
||||
- 확장 방향: 잘못된 비동기 데이터 처리가 어떻게 불필요한 리렌더링 폭풍(re-render storm)이나 병목을 일으키는지 파악하고, React Profiler를 통해 이를 어떻게 탐지하는지 알아봅니다 [15-17].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[프론트엔드 애플리케이션 렌더링 병목 개선]]
|
||||
# [[프론트엔드 애플리케이션 렌더링 병목 개선|프론트엔드 애플리케이션 렌더링 병목 개선]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
프론트엔드 애플리케이션 렌더링 병목은 불필요하거나 과도한 컴포넌트 리렌더링으로 인해 UI 반응성이 떨어지고 상호작용 속도가 지연되는 현상을 의미합니다 [1, 2]. 이를 개선하기 위해서는 렌더링 트리거(상태, Props, Context 등)를 식별하고 메모이제이션, 리스트 가상화, 상태 분리, 동시성 렌더링(Concurrent Rendering) 기능 등을 활용해야 합니다 [3, 4]. 지속적인 프로파일링을 통해 렌더링 비용이 높은 부분을 측정하고 전략적으로 최적화를 적용하는 것이 핵심입니다 [5, 6].
|
||||
@@ -28,21 +28,21 @@
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처/기반 기술]
|
||||
- [[Context API]]
|
||||
- [[Context API|Context API]]
|
||||
- 연결 이유: 컴포넌트 트리 깊은 곳까지 상태를 전달할 수 있으나 구독 중인 모든 컴포넌트를 리렌더링시키는 특성상 렌더링 병목의 주요 원인이 됩니다 [17].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브로드캐스트 기반 상태 관리의 한계와 리렌더링 발생 범위를 이해할 수 있습니다.
|
||||
- [[Concurrent Rendering]]
|
||||
- [[Concurrent Rendering|Concurrent Rendering]]
|
||||
- 연결 이유: 렌더링 작업의 우선순위를 부여하고 중단/재개할 수 있는 기술로, `useTransition` 등을 통해 무거운 렌더링이 메인 스레드를 막는 병목 현상을 방지합니다 [21].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 반응성 지표(INP 등)를 개선하기 위한 렌더링 스케줄링 메커니즘을 이해할 수 있습니다.
|
||||
- [[React Compiler]]
|
||||
- [[React Compiler|React Compiler]]
|
||||
- 연결 이유: 수동 메모이제이션의 한계를 극복하고 빌드 타임에 자동으로 JSX 요소 단위의 메모이제이션을 적용하여 렌더링 최적화를 달성합니다 [13, 14].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 최신 React의 렌더링 최적화가 런타임 제어에서 컴파일러 기반 정적 분석으로 넘어가는 기술적 진화를 이해할 수 있습니다.
|
||||
|
||||
#### [구현/활용 도구]
|
||||
- [[Zustand]]
|
||||
- Zustand
|
||||
- 연결 이유: 셀렉터(Selector) 기능을 활용해 컴포넌트가 자신이 필요한 상태 조각(Slice)이 변경될 때만 리렌더링되도록 보장하여 병목을 줄이는 상태 관리 도구입니다 [18].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 전역 상태의 파편화 관리와 불필요한 리렌더링을 차단하는 구독 최적화 패턴을 학습할 수 있습니다.
|
||||
- [[List Virtualization (Windowing)]]
|
||||
- List Virtualization (Windowing)
|
||||
- 연결 이유: 대규모 리스트에서 사용자의 화면 뷰포트에 존재하는 DOM 노드만 제한적으로 렌더링하여 DOM 트리 비대화를 막습니다 [25, 26].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 다수의 데이터를 렌더링할 때 발생하는 메모리 및 레이아웃 페인팅 병목을 제어하는 원리를 이해할 수 있습니다.
|
||||
|
||||
@@ -61,9 +61,9 @@
|
||||
- **My Project Relevance:** 현재 유지 보수하거나 신규 구축하는 React 웹 앱에서 스크롤 끊김이나 클릭 시 반응 지연이 발생할 때, 해당 개념을 기반으로 병목이 되는 컴포넌트의 렌더링 횟수를 측정하고 적절한 최적화 도구를 즉각 적용할 수 있습니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Server Components (Next.js)]]
|
||||
- Server Components (Next.js)
|
||||
- 확장 방향: 브라우저에서의 렌더링 부하를 줄이기 위해 클라이언트 자바스크립트 번들을 최소화하고 서버에서 정적 UI를 렌더링하여 넘겨주는 아키텍처적 최적화에 대해 심도 있게 조사할 수 있습니다 [39-41].
|
||||
- [[JavaScript Memory Leaks]]
|
||||
- JavaScript Memory Leaks
|
||||
- 확장 방향: 과도한 렌더링 외에도 클로저나 분리된 DOM 노드에 의해 자바스크립트 메모리가 해제되지 않고 누적되어 성능 저하를 일으키는 메모리 누수 식별 및 해결 방법으로 이해를 확장합니다 [42-44].
|
||||
|
||||
---
|
||||
|
||||
+13
-13
@@ -1,18 +1,18 @@
|
||||
# Index: .
|
||||
|
||||
## 📁 Subcategories
|
||||
- [[.git/Index|.git]]
|
||||
- [[Decisions/Index|Decisions]]
|
||||
- [[Development/Index|Development]]
|
||||
- [[Management/Index|Management]]
|
||||
- [[Projects/Index|Projects]]
|
||||
- [[Skills/Index|Skills]]
|
||||
- [[Technical_Reports/Index|Technical_Reports]]
|
||||
- [[Topics/Index|Topics]]
|
||||
- [[Topics_Art/Index|Topics_Art]]
|
||||
- [[Topics_Biz/Index|Topics_Biz]]
|
||||
- [[Topics_Blog/Index|Topics_Blog]]
|
||||
- [[Topics_GD/Index|Topics_GD]]
|
||||
- .git
|
||||
- Decisions
|
||||
- Development
|
||||
- Management
|
||||
- Projects
|
||||
- Skills
|
||||
- Technical_Reports
|
||||
- Topics
|
||||
- Topics_Art
|
||||
- Topics_Biz
|
||||
- Topics_Blog
|
||||
- Topics_GD
|
||||
|
||||
## 📝 Documents
|
||||
- [[Placeholder_Tracking_List]]
|
||||
- [[Placeholder_Tracking_List|Placeholder_Tracking_List]]
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Agile Environments]]
|
||||
# [[Agile Environments|Agile Environments]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Agile Environments(애자일 환경)는 요구사항이 지속적으로 변화하는 프로젝트나 스타트업 환경을 의미합니다 [1]. 이러한 환경에서는 미래에 필요할지도 모르는 복잡한 기능을 미리 개발하기보다는 오직 현재의 요구사항에 집중하는 것이 핵심입니다 [2]. 따라서 각 기능을 독립적으로 생성하고 구현할 수 있는 유연하고 모듈화된 접근 방식이 매우 적합합니다 [3].
|
||||
@@ -13,13 +13,13 @@ Agile Environments(애자일 환경)는 요구사항이 지속적으로 변화
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[YAGNI]]
|
||||
- YAGNI
|
||||
- 연결 이유: 애자일 환경에서 미래의 불확실한 기능을 미리 만들지 않고 현재의 요구사항에 집중하도록 이끄는 가장 핵심적인 개발 원칙입니다 [1, 2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 애자일 환경에서 불필요한 코드(Dead Code)의 생성을 방지하고 유지보수 비용을 최소화하는 구체적인 판단 기준을 이해할 수 있습니다 [2].
|
||||
- [[Feature-Based Structure]]
|
||||
- Feature-Based Structure
|
||||
- 연결 이유: 애자일 방법론과 가장 잘 어울리는 아키텍처 패턴으로, 코드 베이스를 기능 단위로 분리하여 독립적인 개발을 가능하게 합니다 [3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 애자일 팀이 요구사항 변경에 맞춰 여러 기능을 독립적으로 확장하고 개발할 때 파일과 폴더를 어떻게 구성해야 하는지 이해할 수 있습니다 [3].
|
||||
- [[Startup Projects]]
|
||||
- [[Startup Projects|Startup Projects]]
|
||||
- 연결 이유: 애자일 환경과 마찬가지로 요구사항이 지속적으로 변화하는 특성을 공유하며, YAGNI 원칙이 강하게 적용되는 대표적인 비즈니스 환경입니다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 애자일 원칙이 실무에서 어떠한 형태의 프로젝트 규모나 상황(빠른 변화와 유연성 요구)에서 주로 채택되는지 파악할 수 있습니다 [1].
|
||||
|
||||
@@ -38,9 +38,9 @@ Agile Environments(애자일 환경)는 요구사항이 지속적으로 변화
|
||||
- **My Project Relevance:** 잦은 기획 변경이 예상되는 초기 단계의 스타트업 프로젝트나 애자일 조직을 세팅할 때, 초기 개발 속도를 높이면서도 변경에 유연하게 대응하기 위한 가이드라인으로 직결됩니다 [1, 3].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[SOLID Principles]]
|
||||
- [[SOLID Principles|SOLID Principles]]
|
||||
- 확장 방향: 애자일 환경에서 당장의 기능을 단순하게 개발(YAGNI)하면서도, 장기적으로 애플리케이션의 규모가 커졌을 때 코드를 어떻게 유지보수 가능하게 설계할지 객체 지향적/구조적 관점에서 이해를 확장할 수 있습니다 [1, 4].
|
||||
- [[Clean Code]]
|
||||
- Clean Code
|
||||
- 확장 방향: 빠른 변화와 반복 개발(Iteration)이 일어나는 애자일 환경 속에서, 여러 명의 개발자가 코드를 쉽게 읽고 협업할 수 있도록 하는 기본적인 코드 품질 유지 기법으로 확장이 가능합니다 [4, 5].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Branching Strategies]]
|
||||
# [[Branching Strategies|Branching Strategies]]
|
||||
|
||||
## 📌 Brief 소Summary
|
||||
Branching Strategies(브랜칭 전략)는 소프트웨어 개발 과정에서 코드 변경 사항을 관리하고 팀원 간의 협업을 조율하기 위해 버전 관리 시스템(Git 등)에서 브랜치를 생성, 병합, 유지보수하는 규칙과 워크플로우를 의미합니다. 팀의 규모와 프로젝트 요구사항에 따라 Git Flow, GitHub Flow, Trunk-Based Development, Feature Branch Workflow 등 다양한 전략이 사용됩니다. 명확한 브랜칭 전략의 도입은 메인 코드베이스의 안정성을 보장하고 병합 충돌을 방지하며 코드 리뷰와 추적성을 강화하는 핵심 역할을 합니다 [1-3].
|
||||
@@ -29,21 +29,21 @@ Branching Strategies(브랜칭 전략)는 소프트웨어 개발 과정에서
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 방법론]
|
||||
- [[Feature Branch Workflow]]
|
||||
- Feature Branch Workflow
|
||||
- 연결 이유: 소규모 3~5인 개발 팀에 가장 추천되는 단순하고 직관적인 브랜칭 전략의 기반 개념입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메인 브랜치를 오염시키지 않고 새로운 기능을 격리된 환경에서 개발하고 병합하는 방법론을 이해할 수 있습니다.
|
||||
- [[Trunk-Based Development]]
|
||||
- Trunk-Based Development
|
||||
- 연결 이유: 무거운 워크플로우를 탈피하여 브랜치 생명주기를 극한으로 줄이고 빠른 통합을 중시하는 최신 트렌드 모델입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: CI/CD 환경에서의 잦은 소규모 배포 방식과 충돌 최소화 전략을 학습할 수 있습니다.
|
||||
- [[Git Flow]]
|
||||
- Git Flow
|
||||
- 연결 이유: 브랜칭 전략의 고전적이고 체계적인 형태로서, 대형 프로젝트의 정기적 버저닝 관리를 위해 설계되었습니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `develop`, `release`, `hotfix` 등 개발 파이프라인에 따른 브랜치의 역할 분리 기법을 이해할 수 있습니다.
|
||||
|
||||
#### [관계 유형 B: 구현/활용 도구 및 규칙]
|
||||
- [[Pull Request & Code Review]]
|
||||
- Pull Request & Code Review
|
||||
- 연결 이유: 브랜칭 전략이 안전하게 동작하기 위해 모든 병합 전에 필수적으로 거쳐야 하는 품질 검증 관문입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀원 간의 비동기적 피드백 수렴, 시각적 검증, 그리고 CI 통과를 전제로 한 안전한 병합 과정을 배울 수 있습니다.
|
||||
- [[Conventional Commits]]
|
||||
- Conventional Commits
|
||||
- 연결 이유: 브랜치 병합 내역을 추적하고 가독성을 높이기 위해 전 세계적으로 통용되는 커밋 메시지 작성 표준입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `feat(scope): message` 와 같은 형식의 구문을 통해 코드 히스토리 파악 및 문서 자동화를 어떻게 이룰 수 있는지 이해할 수 있습니다.
|
||||
|
||||
@@ -62,9 +62,9 @@ Branching Strategies(브랜칭 전략)는 소프트웨어 개발 과정에서
|
||||
- **My Project Relevance:** 3~5인 규모의 프로젝트에서 무거운 Git Flow의 도입을 지양하고, '단기 기능 브랜치 → PR 및 1인 이상 피어 리뷰 승인 → Squash Merge 및 브랜치 즉시 삭제'라는 단순화된 룰을 적용하여 개발 속도와 코드 품질을 동시에 챙깁니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Continuous Integration / Continuous Deployment (CI/CD)]]
|
||||
- Continuous Integration / Continuous Deployment (CI/CD)
|
||||
- 확장 방향: 브랜칭 전략에 의해 트리거(Trigger)되어 실행되는 빌드, 테스트, 배포 파이프라인의 자동화 프로세스를 깊이 알아봅니다.
|
||||
- [[Feature-Sliced Design (FSD)]]
|
||||
- [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD)]]
|
||||
- 확장 방향: 도메인과 기능 단위로 코드를 분리하는 프론트엔드 아키텍처 방법론으로, 브랜치를 기능별로 나눌 때 충돌을 물리적으로 최소화하는 코드 구조 설계법을 탐구합니다.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Code Review]]
|
||||
# [[Code Review|Code Review]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
코드 리뷰(Code Review)는 개발자가 작성한 코드를 메인 브랜치에 병합하기 전에 팀원(동료)이 검토하여 승인하는 품질 관리 및 협업 프로세스입니다 [1, 2]. 주로 Pull Request(PR) 단계를 통해 이루어지며, 단독으로 잘못된 코드가 병합되는 것을 방지하고 팀 내 빠른 피드백 루프를 형성합니다 [1]. 최근 프론트엔드 환경에서는 단순한 코드 검토를 넘어 Storybook과 같은 도구를 CI 파이프라인과 결합한 '시각적 리뷰(Visual Review)'로 확장되어 의도치 않은 UI 변경을 방지하는 역할도 수행합니다 [3].
|
||||
@@ -18,16 +18,16 @@
|
||||
### Related Concepts
|
||||
|
||||
#### [협업 및 형상 관리 워크플로우]
|
||||
- [[Pull Request (PR)]]
|
||||
- [[Pull Request (PR)|Pull Request (PR)]]
|
||||
- 연결 이유: 코드 리뷰가 실질적으로 요청되고, 검토 피드백이 오가는 핵심 플랫폼이자 단위입니다 [1, 2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜치 병합 전 품질 관리 게이트로서의 기능과 짧고 명확한 작업 단위 분할의 중요성을 파악할 수 있습니다.
|
||||
|
||||
- [[Feature Branch Workflow]]
|
||||
- Feature Branch Workflow
|
||||
- 연결 이유: 코드 리뷰 시스템을 쉽게 도입하기 위한 가장 기본적이고 충돌이 적은 브랜치 전략입니다 [14, 15].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메인 브랜치를 항상 안정적으로 유지하면서, 각각의 태스크를 독립된 브랜치에서 작업하고 리뷰를 통해 검증하는 전체 흐름을 이해할 수 있습니다.
|
||||
|
||||
#### [자동화 및 품질 검증 도구]
|
||||
- [[Visual Regression Testing]]
|
||||
- [[Visual Regression Testing|Visual Regression Testing]]
|
||||
- 연결 이유: 프론트엔드 코드 리뷰 시 육안으로 확인하기 힘든 의도치 않은 레이아웃/색상 변경을 자동화 도구가 시각적으로 찾아내어 리뷰어에게 제시합니다 [3, 9].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Chromatic이나 Happo를 CI 파이프라인과 결합하여 PR 리뷰의 정확도를 높이고 안정적인 UI를 배포하는 프로세스를 배울 수 있습니다.
|
||||
|
||||
@@ -49,7 +49,7 @@
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Continuous Integration (CI)]]
|
||||
- [[Continuous Integration (CI)|Continuous Integration (CI)]]
|
||||
- 확장 방향: PR이 올라왔을 때 코드 리뷰를 돕기 위해 사전에 테스트 통과 여부, 빌드 성공 여부 등을 자동으로 검사해주는 자동화 파이프라인의 구축에 대해 학습할 수 있습니다 [7, 19].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Git Workflow]]
|
||||
# [[Git Workflow|Git Workflow]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Git Workflow(깃 워크플로우)는 팀 환경에서 코드 변경 사항을 관리하고 협업하기 위한 체계적이고 구조화된 접근 방식입니다 [1, 2]. 이는 기능 브랜치(Feature-branch), 트렁크 기반(Trunk-based), Git Flow 등 다양한 전략을 포괄하며, 충돌을 방지하고 `main` 브랜치의 배포 가능 상태를 보장하는 것을 목표로 합니다 [2-4]. 일관된 브랜치 명명 규칙, 커밋 메시지 규약, 풀 리퀘스트(PR)와 리뷰 절차를 도입함으로써 잠재적인 혼돈을 예측 가능한 릴리스 흐름으로 전환할 수 있습니다 [1, 5, 6].
|
||||
@@ -30,24 +30,24 @@ Git Workflow(깃 워크플로우)는 팀 환경에서 코드 변경 사항을
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/기반 기술)]
|
||||
- `[[Trunk-Based Development]]`
|
||||
- `Trunk-Based Development`
|
||||
- 연결 이유: Git Workflow를 구성하는 핵심 전략 중 하나로, 빠른 통합을 목적으로 하는 방법론입니다 [2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 짧은 수명의 브랜치, 빈번한 병합, 기능 플래그(Feature Flags) 활용이 프로젝트 배포 속도에 어떻게 기여하는지 이해할 수 있습니다 [9, 12].
|
||||
|
||||
- `[[Git Flow]]`
|
||||
- `Git Flow`
|
||||
- 연결 이유: 구조가 복잡한 대규모 프로젝트의 릴리스를 관리하기 위해 만들어진 전통적 브랜칭 모델입니다 [2, 10].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `develop`, `release`, `hotfix` 등 다중 브랜치 전략이 왜 오버헤드를 유발하면서도 엔터프라이즈 환경에서 사용되는지 파악할 수 있습니다 [8, 10].
|
||||
|
||||
#### [관계 유형 B (구현/활용 도구)]
|
||||
- `[[Conventional Commits]]`
|
||||
- `Conventional Commits`
|
||||
- 연결 이유: 팀의 일관된 코드베이스 히스토리 관리를 위해 Git 커밋 메시지 작성에 적용되는 업계 표준 규칙입니다 [6, 16].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `feat:`, `fix:`, `chore:`와 같은 접두사가 리뷰어의 코드 이해도를 어떻게 높이고 자동화된 릴리스에 기여하는지 배울 수 있습니다 [6, 16].
|
||||
|
||||
- `[[Pull Requests (PR)]]`
|
||||
- `Pull Requests (PR)`
|
||||
- 연결 이유: 브랜치의 코드를 `main`으로 병합하기 전, 협업 팀원들이 코드를 검토하는 핵심 관문입니다 [13, 16].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜치 보호 설정, 동료 리뷰 요구(1 review required), 지속적 통합(CI) 체크가 시스템 안정성 유지에 어떻게 필수적으로 작용하는지 이해할 수 있습니다 [16, 17].
|
||||
|
||||
- `[[Ticket IDs (Traceability)]]`
|
||||
- `Ticket IDs (Traceability)`
|
||||
- 연결 이유: 코드의 변경 사항이 어떤 비즈니스 요구사항(예: Jira 티켓)에 의해 발생했는지를 연결하는 도구적 장치입니다 [5, 22].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `PROJ-123` 형태의 티켓 번호를 브랜치와 커밋에 삽입함으로써 리뷰어에게 맥락을 제공하고, 문서화 및 작업 추적(Traceability)을 어떻게 달성하는지 알 수 있습니다 [5, 22].
|
||||
|
||||
@@ -66,9 +66,9 @@ Git Workflow(깃 워크플로우)는 팀 환경에서 코드 변경 사항을
|
||||
- **My Project Relevance:** 현재 진행하는 3인 규모의 프로젝트 등에서는 Git Flow의 무거운 절차를 피하고, 항상 배포 가능한 안정적인 `main` 브랜치를 기준으로 짧은 기능 브랜치를 생성하여 빠른 리뷰와 피드백을 주고받는 방식을 즉각 도입할 수 있습니다 [4, 8].
|
||||
|
||||
### Adjacent Topics
|
||||
- `[[CI/CD (Continuous Integration/Continuous Deployment)]]`
|
||||
- `CI/CD (Continuous Integration/Continuous Deployment)`
|
||||
- 확장 방향: PR을 생성하거나 병합할 때 코드를 자동으로 테스트하고 빌드, 배포하는 인프라 파이프라인 구성 방법론으로 확장하여 조사.
|
||||
- `[[Semantic Versioning (SemVer)]]`
|
||||
- `Semantic Versioning (SemVer)`
|
||||
- 확장 방향: Git 태그(Tag)와 Conventional Commits를 활용하여 소프트웨어의 버전을 체계적이고 일관성 있게 부여하는 방법으로 확장.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[GitHub Flow]]
|
||||
# [[GitHub Flow|GitHub Flow]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
GitHub Flow는 복잡한 Git Flow의 대안으로 사용되는 가볍고 단순한 브랜치 기반 워크플로우입니다 [1, 2]. 이 방식은 항상 배포 가능한 상태(deployable)를 유지하는 `main` 브랜치를 중심으로 작동하며, 개발자는 새로운 작업을 위해 짧은 주기의 기능 브랜치(feature branch)를 생성합니다 [3-5]. 변경된 코드는 동료의 코드 리뷰와 CI/CD 테스트를 모두 통과한 후 오직 Pull Request(PR)를 통해서만 `main`에 병합됩니다 [1, 6].
|
||||
@@ -25,18 +25,18 @@ GitHub Flow는 복잡한 Git Flow의 대안으로 사용되는 가볍고 단순
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술 (개발 워크플로우)]
|
||||
- [[Git Flow]]
|
||||
- Git Flow
|
||||
- 연결 이유: GitHub Flow와 자주 비교되는 분기 전략으로, 프로젝트의 복잡성에 따라 두 전략 사이를 마이그레이션하는 경우가 많습니다 [2, 12].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `develop`, `release`, `hotfix` 브랜치를 사용하는 Git Flow를 이해함으로써, 상대적으로 GitHub Flow가 생략한 구조적 복잡성과 그에 따른 속도/단순성의 이점을 명확히 비교할 수 있습니다.
|
||||
- [[Trunk-Based Development]]
|
||||
- Trunk-Based Development
|
||||
- 연결 이유: 소규모 팀에서 빠르고 충돌 없는 병합을 위해 도입할 수 있는 또 다른 경량 워크플로우입니다 [3, 16].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 극단적으로 짧은 생명주기의 브랜치를 사용하거나 메인에 빈번히 직접 병합하는 철학을 통해 CI(지속적 통합)의 본질을 더 깊게 이해할 수 있습니다.
|
||||
|
||||
#### [관계 유형 B: 구현/활용 도구]
|
||||
- [[Pull Request]]
|
||||
- [[풀 리퀘스트 (Pull Request)|Pull Request]]
|
||||
- 연결 이유: GitHub Flow에서 코드 병합을 수행하고 팀원 간의 협업 및 리뷰를 진행하는 가장 핵심적인 메커니즘입니다 [8, 10].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드 품질 통제, 피어 리뷰(Peer Review)의 역할 및 CI/CD 훅(Hook)이 작동하는 방식을 구체적으로 이해할 수 있습니다.
|
||||
- [[CI/CD]]
|
||||
- [[CI_CD|CI/CD]]
|
||||
- 연결 이유: `main` 브랜치를 항상 배포 가능한 상태로 유지하기 위해 배후에서 코드를 검증하는 필수 자동화 파이프라인입니다 [1, 6].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 수동 병합이 위험한지, PR 리뷰가 끝난 코드가 어떻게 안전하게 프로덕션 레벨까지 배포되는지의 전 과정을 파악할 수 있습니다.
|
||||
|
||||
@@ -55,9 +55,9 @@ GitHub Flow는 복잡한 Git Flow의 대안으로 사용되는 가볍고 단순
|
||||
- **My Project Relevance:** 3~5명의 소규모 팀에서 충돌을 최소화하면서도 빠른 피드백과 릴리스가 필요한 현재 프로젝트 상황에, 불필요한 절차를 없애고 안정성을 보장하는 가장 이상적인 협업 모델로 적용할 수 있습니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Conventional Commits]]
|
||||
- Conventional Commits
|
||||
- 확장 방향: 커밋 메시지를 `feat:`, `fix:`, `chore:` 등의 규격으로 통일함으로써, PR 내용의 가독성을 높이고 향후 릴리스 노트를 자동화하는 방향으로 지식을 확장할 수 있습니다.
|
||||
- [[Issue Tracking System]]
|
||||
- Issue Tracking System
|
||||
- 확장 방향: 코드 구현(GitHub)과 요구사항 정의(JIRA, Linear 등)를 연결하여 프로젝트 관리 수준을 높이고 변경 사항의 비즈니스 맥락(Traceability)을 추적하는 방법론으로 확장됩니다.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# Index: Management
|
||||
|
||||
## 📁 Subcategories
|
||||
- [[System/Index|System]]
|
||||
- System
|
||||
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
id: 550e8400-e29b-41d4-a716-446655440007
|
||||
category: "[[10_Wiki/Management/System]]"
|
||||
category: "10_Wiki/Management/System"
|
||||
confidence_score: 0.99
|
||||
tags: [antigravity, agent, collaboration, governance]
|
||||
last_reinforced: 2026-04-21
|
||||
---
|
||||
|
||||
# [[Antigravity 에이전트 협업 시스템 v1.0]]
|
||||
# Antigravity 에이전트 협업 시스템 v1.0
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 에이전트 간의 엄격한 핸드오버 계약과 반려권(Veto) 행사를 통해 '가혹한 무결성'과 '자율적 진화'를 동시에 달성함.
|
||||
@@ -25,6 +25,6 @@ last_reinforced: 2026-04-21
|
||||
- **정책 변화:** "Insanely Great" 하지 않은 모든 결과물은 반려(Veto) 대상임.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Management/System]]
|
||||
- **Related:** [[10_Wiki/Global/Universal_Knowledge_Bridge]], [[10_Wiki/Projects/Skybound/HUD_UI_Refinement]]
|
||||
- **Raw Source:** [[00_Raw/2026-04-21-Antigravity_Agent_System_Overhaul]]
|
||||
- **Parent:** 10_Wiki/Management/System
|
||||
- **Related:** 10_Wiki/Global/Universal_Knowledge_Bridge, 10_Wiki/Projects/Skybound/HUD_UI_Refinement
|
||||
- **Raw Source:** 00_Raw/2026-04-21-Antigravity_Agent_System_Overhaul
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Index: Management > System
|
||||
|
||||
## 📝 Documents
|
||||
- [[Antigravity_Agent_System_v1]]
|
||||
- [[Antigravity_Agent_System_v1|Antigravity_Agent_System_v1]]
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Team Collaboration]]
|
||||
# [[Team Collaboration|Team Collaboration]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
프론트엔드 개발에서 'Team Collaboration(팀 협업)'이란 다수의 개발자가 동일한 코드베이스에서 효율적으로 함께 작업할 수 있도록 지원하는 실천 방식, 아키텍처, 그리고 워크플로우를 의미한다 [1, 2]. 이는 일관된 폴더 구조, 명명 규칙, 상태 관리 패턴 및 Git 브랜칭 전략을 확립하여 개발자 간의 충돌과 소통 비용을 최소화하는 것을 목표로 한다 [2-4]. 성공적인 협업은 린팅이나 포매팅과 같은 자동화된 도구를 통한 엄격한 코드 거버넌스와 명확한 코드 리뷰 문화를 바탕으로 애플리케이션과 팀이 확장될 때 안정성을 유지하도록 돕는다 [5-7].
|
||||
@@ -23,21 +23,21 @@
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (협업/코드 관리 프로세스)]
|
||||
- [[Git Branching Strategies]]
|
||||
- Git Branching Strategies
|
||||
- 연결 이유: 다수의 개발자가 동시에 코드를 작성할 때 충돌을 방지하고 통합 과정을 관리하기 위한 핵심 규약이기 때문이다 [3, 34].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Pull Request, 코드 리뷰, 브랜치 명명 규칙, Trunk-based 워크플로우 등 실제 팀 운영 방식 [7, 35].
|
||||
- [[Commit Message Conventions]]
|
||||
- Commit Message Conventions
|
||||
- 연결 이유: 변경 사항의 의도와 작업 내역(버그 픽스, 기능 추가 등)을 다른 팀원들에게 명확히 전달하는 소통의 도구이기 때문이다 [36].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 티켓 ID 통합, `feat:`, `fix:`와 같은 접두사를 통한 변경 이력의 자동화 및 스캐닝 [14, 36, 37].
|
||||
|
||||
#### [관계 유형 B (아키텍처 및 거버넌스 도구)]
|
||||
- [[Feature-Sliced Design]]
|
||||
- [[Feature-Sliced Design|Feature-Sliced Design]]
|
||||
- 연결 이유: 코드를 기술적 계층이 아닌 비즈니스 기능(Feature) 중심으로 분리하여, 여러 팀이 서로 간섭 없이 독립적으로 작업할 수 있는 환경을 제공한다 [16, 38].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 도메인 주도 설계의 프론트엔드 적용, 명시적 퍼블릭 API를 통한 모듈 캡슐화와 결합도 낮추기 [38-40].
|
||||
- [[Automated Governance]]
|
||||
- Automated Governance
|
||||
- 연결 이유: 사람의 수동 확인에 의존하지 않고 ESLint, Prettier, Husky 등으로 코드 컨벤션과 아키텍처 룰(의존성 방향 등)을 시스템적으로 강제한다 [6, 20].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: CI/CD 파이프라인에서의 코드 품질 보증 및 팀원 간의 스타일 분쟁 방지 [20].
|
||||
- [[Redux vs Zustand in Teams]]
|
||||
- Redux vs Zustand in Teams
|
||||
- 연결 이유: 팀의 규모(소규모 vs 엔터프라이즈)에 따라 상태 관리 도구의 선택이 협업의 일관성에 결정적인 영향을 미치기 때문이다 [5, 24, 27].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 개발자의 자율성 부여와 일관성 강제(Boilerplate) 사이의 아키텍처적 트레이드오프 [22, 41].
|
||||
|
||||
@@ -59,11 +59,11 @@
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Code Review Practices]]
|
||||
- Code Review Practices
|
||||
- 확장 방향: 작은 단위의 Pull Request 유지, 시각적 리뷰 도구의 도입, 효율적인 동료 피드백 제공 등 코드 리뷰 자체의 품질과 속도를 높이는 방법론 [37, 45].
|
||||
- [[CI/CD Pipelines]]
|
||||
- CI/CD Pipelines
|
||||
- 확장 방향: 팀원의 코드가 `main`에 병합되기 전, 자동으로 테스트와 린팅을 수행하고 배포까지 이어지는 인프라 및 데브옵스 환경 [7].
|
||||
- [[Visual Regression Testing]]
|
||||
- [[Visual Regression Testing|Visual Regression Testing]]
|
||||
- 확장 방향: Storybook 및 Chromatic을 활용해 UI 변경 사항을 리뷰어가 시각적으로 직접 확인하고, 예기치 않은 레이아웃 깨짐을 방지하는 협업 기술 [45, 46].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Version Control]]
|
||||
# [[Version Control|Version Control]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
버전 관리(Version Control)는 소규모부터 대규모 팀에 이르기까지 코드의 변경 사항을 추적하고, 병합 충돌을 방지하며 안정적인 배포를 가능하게 하는 필수적인 협업 도구 및 거버넌스 프로세스입니다 [1, 2]. 개발팀은 프로젝트 규모와 팀의 숙련도에 따라 Feature-Branch 워크플로우, Trunk-based 개발, Git Flow 등 다양한 브랜칭 전략을 선택하여 사용합니다 [3, 4]. 효과적인 버전 관리는 브랜치와 커밋에 티켓 ID 연동, 의미 있는 커밋 메시지 작성, 작고 빈번한 커밋, 그리고 엄격한 풀 리퀘스트(PR) 리뷰 등의 모범 사례를 준수하여 코드베이스의 품질과 추적성을 유지하는 것을 목표로 합니다 [2, 5].
|
||||
@@ -27,21 +27,21 @@
|
||||
### Related Concepts
|
||||
|
||||
#### [워크플로우 및 방법론 (Workflow Strategies)]
|
||||
- [[Feature Branch Workflow]]
|
||||
- Feature Branch Workflow
|
||||
- 연결 이유: 버그 수정이나 새 기능 개발 시 `main`과 분리된 독립적이고 짧은 수명의 브랜치를 사용하는 전략이기 때문입니다. [6, 7]
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 어떻게 `main` 브랜치의 안정성을 훼손하지 않으면서도 다수의 개발자가 코드를 작성하고 충돌을 방지할 수 있는지 이해할 수 있습니다.
|
||||
- [[Trunk-Based Development]]
|
||||
- Trunk-Based Development
|
||||
- 연결 이유: 모든 개발자가 빈번하게 짧은 주기로 메인 브랜치(Trunk)에 코드를 병합하는 방법론이기 때문입니다. [8, 9]
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 지속적 통합(CI)을 어떻게 보장하며, 장기 브랜치로 인해 발생하는 문제를 어떻게 회피하는지 파악할 수 있습니다.
|
||||
- [[Git Flow]]
|
||||
- Git Flow
|
||||
- 연결 이유: 릴리스용 브랜치와 개발용 브랜치를 명확히 나누어 복잡한 프로젝트 릴리스를 관리하는 아키텍처이기 때문입니다. [9, 19]
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀의 규모와 배포 스케줄에 따라 워크플로우에 어떤 구조적 레이어를 추가해야 하는지 이해할 수 있습니다.
|
||||
|
||||
#### [협업 및 품질 관리 (Quality Assurance & Collaboration)]
|
||||
- [[Pull Request (PR)]]
|
||||
- [[Pull Request (PR)|Pull Request (PR)]]
|
||||
- 연결 이유: 코드를 주 브랜치에 병합하기 전, 변경 사항을 동료에게 검토받는 핵심 품질 통제 절차이기 때문입니다. [13, 16]
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드 리뷰와 CI 테스트 자동화가 어떻게 실제 코드 품질을 유지하고 팀 내 지식 공유를 돕는지 이해할 수 있습니다.
|
||||
- [[Conventional Commits]]
|
||||
- Conventional Commits
|
||||
- 연결 이유: `feat:`, `fix:`와 같이 표준화된 접두사를 사용하여 커밋 메시지의 의도를 명확하게 만드는 구문 규칙이기 때문입니다. [5, 13]
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 커밋 히스토리를 통한 변경 사항 추적성 확보와 릴리스 노트 자동화에 어떻게 기여하는지 이해할 수 있습니다.
|
||||
|
||||
@@ -60,9 +60,9 @@
|
||||
- **My Project Relevance:** 프론트엔드/React 개발 프로젝트 등의 팀 단위 협업 시, 불필요한 절차 없이 코드 충돌을 최소화하고 추적 가능한 변경 내역을 보장하는 협업 기준을 마련하는 데 즉각적으로 활용할 수 있습니다 [1, 22].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Continuous Integration / Continuous Deployment (CI/CD)]]
|
||||
- Continuous Integration / Continuous Deployment (CI/CD)
|
||||
- 확장 방향: PR 단계에서 자동화된 테스트 및 린팅을 실행하고, 메인 브랜치 병합 시 배포를 자동화하여 버전 관리 도구와 어떻게 시너지를 내는지 조사. [1, 19]
|
||||
- [[Issue Tracking Systems]]
|
||||
- Issue Tracking Systems
|
||||
- 확장 방향: JIRA나 GitHub Issues 등의 도구가 Git의 티켓 ID 거버넌스와 결합되어 요구사항부터 코드 변경까지 어떻게 완벽한 추적성(Traceability)을 보장하는지 조사. [2, 23]
|
||||
|
||||
---
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: a7f8e1c2-d3b4-4e5f-9a0b-1c2d3e4f5a6b
|
||||
category: "[[10_Wiki/Projects/ConnectAI]]"
|
||||
category: "10_Wiki/Projects/ConnectAI"
|
||||
confidence_score: 0.90
|
||||
tags: [connectai, optimization, python, architecture, performance]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "initial-wikification"
|
||||
---
|
||||
|
||||
# [[ConnectAI Core Optimization Plan (Python Core)]]
|
||||
# ConnectAI Core Optimization Plan (Python Core)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> ConnectAI의 성능 병목을 해결하기 위해 $O(N^2)$ 알고리즘을 $O(N \log N)$으로 고도화하고, 동기식 I/O를 비동기 파이프라인으로 전환하며, 옵저버 패턴을 통해 모듈 간 결합도를 제거하는 전면적인 코어 아키텍처 개편 계획이다.
|
||||
@@ -36,9 +36,9 @@ github_commit: "initial-wikification"
|
||||
- **비동기 오버헤드**: 단순 연산 위주 작업에서는 `asyncio` 전환이 오히려 컨텍스트 스위칭 비용만 늘릴 수 있으므로 프로파일링 필수.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Projects/ConnectAI]]
|
||||
- **Related**: [[Observer Pattern]], [[KD-Tree]], [[Asynchronous I/O]]
|
||||
- **Raw Source**: [[00_Raw/system_analysis_and_improvement_plan]]
|
||||
- **Parent**: 10_Wiki/Projects/ConnectAI
|
||||
- **Related**: Observer Pattern, KD-Tree, Asynchronous I/O
|
||||
- **Raw Source**: 00_Raw/system_analysis_and_improvement_plan
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# Index: Projects
|
||||
|
||||
## 📁 Subcategories
|
||||
- [[Skybound/Index|Skybound]]
|
||||
- Skybound
|
||||
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
id: 550e8400-e29b-41d4-a716-446655440001
|
||||
category: "[[10_Wiki/Projects/Skybound]]"
|
||||
category: "10_Wiki/Projects/Skybound"
|
||||
confidence_score: 0.95
|
||||
tags: [skybound, architecture, performance, zero-leak]
|
||||
last_reinforced: 2026-04-21
|
||||
---
|
||||
|
||||
# [[Skybound 아키텍처 리팩토링]]
|
||||
# Skybound 아키텍처 리팩토링
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 엔진-모듈 간의 '의도(Intent)' 기반 통신과 선언적 파이프라인 도입을 통해 시스템 신뢰도와 성능을 동시에 확보하는 'Zero-Leak' 아키텍처로 진화함.
|
||||
@@ -24,6 +24,6 @@ last_reinforced: 2026-04-21
|
||||
- **정책 변화:** 성능보다는 '예측 가능성(Predictability)'을 우선하는 설계 원칙 수립.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Projects/Skybound]]
|
||||
- **Related:** [[10_Wiki/Decisions/Skybound/IDE_Stability_Fix]], [[10_Wiki/Decisions/Skybound/Frame_Type_Restoration]]
|
||||
- **Raw Source:** [[00_Raw/2026-04-21-Skybound_Architecture_Refactor_Plan]]
|
||||
- **Parent:** 10_Wiki/Projects/Skybound
|
||||
- **Related:** 10_Wiki/Decisions/Skybound/IDE_Stability_Fix, 10_Wiki/Decisions/Skybound/Frame_Type_Restoration
|
||||
- **Raw Source:** 00_Raw/2026-04-21-Skybound_Architecture_Refactor_Plan
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
id: 550e8400-e29b-41d4-a716-446655440003
|
||||
category: "[[10_Wiki/Projects/Skybound]]"
|
||||
category: "10_Wiki/Projects/Skybound"
|
||||
confidence_score: 0.98
|
||||
tags: [skybound, ui, ux, minimalism]
|
||||
last_reinforced: 2026-04-21
|
||||
---
|
||||
|
||||
# [[Skybound HUD UI 최적화]]
|
||||
# Skybound HUD UI 최적화
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 중복된 점수 노출을 제거하고 "High Score Sync" 맥락으로 정보를 통합하여 "Digital Cockpit" 미학을 실현함.
|
||||
@@ -23,6 +23,6 @@ last_reinforced: 2026-04-21
|
||||
- **정책 변화:** UI 요소 추가 시 '중복 여부'를 반드시 검수하는 체크리스트 도입.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Projects/Skybound]]
|
||||
- **Related:** [[10_Wiki/Management/System/Antigravity_Agent_System_v1]]
|
||||
- **Raw Source:** [[00_Raw/2026-04-21-Skybound_HUD_UI_Refinement]]
|
||||
- **Parent:** 10_Wiki/Projects/Skybound
|
||||
- **Related:** 10_Wiki/Management/System/Antigravity_Agent_System_v1
|
||||
- **Raw Source:** 00_Raw/2026-04-21-Skybound_HUD_UI_Refinement
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# Index: Projects > Skybound
|
||||
|
||||
## 📝 Documents
|
||||
- [[Architecture_Refactor]]
|
||||
- [[HUD_UI_Refinement]]
|
||||
- [[Architecture_Refactor|Architecture_Refactor]]
|
||||
- [[HUD_UI_Refinement|HUD_UI_Refinement]]
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
id: 550e8400-e29b-41d4-a716-446655440005
|
||||
category: "[[10_Wiki/Skills/BuildSystem]]"
|
||||
category: "10_Wiki/Skills/BuildSystem"
|
||||
confidence_score: 0.97
|
||||
tags: [build, devops, automation, versioning]
|
||||
last_reinforced: 2026-04-21
|
||||
---
|
||||
|
||||
# [[증분형 빌드 관리 시스템]]
|
||||
# 증분형 빌드 관리 시스템
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 빌드 결과물을 버전별로 격리된 폴더에 저장하여 배포 이력을 보존하고 롤백 안정성을 확보함.
|
||||
@@ -23,6 +23,6 @@ last_reinforced: 2026-04-21
|
||||
- **정책 변화:** 모든 빌드 요청은 반드시 고유한 버전 번호를 가져야 함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Skills/BuildSystem]]
|
||||
- **Related:** [[10_Wiki/Projects/Skybound/Architecture_Refactor]]
|
||||
- **Raw Source:** [[00_Raw/2026-04-21-Skybound_Incremental_Build_System]]
|
||||
- **Parent:** 10_Wiki/Skills/BuildSystem
|
||||
- **Related:** 10_Wiki/Projects/Skybound/Architecture_Refactor
|
||||
- **Raw Source:** 00_Raw/2026-04-21-Skybound_Incremental_Build_System
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Index: Skills > BuildSystem
|
||||
|
||||
## 📝 Documents
|
||||
- [[Incremental_Build]]
|
||||
- [[Incremental_Build|Incremental_Build]]
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
id: {{UUID}}
|
||||
category: "[[10_Wiki/Skills]]"
|
||||
category: "10_Wiki/Skills"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, architecture, git-sync, automation, connect-ai]
|
||||
last_reinforced: 2026-04-29
|
||||
@@ -29,5 +29,5 @@ last_reinforced: 2026-04-29
|
||||
- **보안 정책**: Zero Cloud API 원칙에 따라 모든 연산은 로컬에서 수행되지만, GitHub 동기화 시 개인 인증(Credential) 관리가 보안의 핵심 변수로 작용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[WIKIFICATION_PROTOCOL]], [[P-Reinforce_Skill]], [[System_Manual]]
|
||||
- [[WIKIFICATION_PROTOCOL|WIKIFICATION_PROTOCOL]], [[P-Reinforce_Skill|P-Reinforce_Skill]], [[System_Manual|System_Manual]]
|
||||
- **Raw Source:** E:/Wiki/Wonseok_AI_original/ARCHITECTURE.md
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Index: Skills
|
||||
|
||||
## 📁 Subcategories
|
||||
- [[BuildSystem/Index|BuildSystem]]
|
||||
- BuildSystem
|
||||
|
||||
## 📝 Documents
|
||||
- [[P-Reinforce_Skill]]
|
||||
- [[P-Reinforce_Skill|P-Reinforce_Skill]]
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
1. **Knowledge Ingestion**: `knowledge/` 폴더에 존재하는 모든 마크다운 파일을 정기적으로 `00_Raw/`의 날짜별 폴더로 자동 복사(Ingestion)하여 시스템의 먹이로 제공한다.
|
||||
2. **Real-time Monitoring**: `00_Raw/` 폴더의 모든 입력을 실시간 모니터링하고 지식화하라.
|
||||
3. **Autonomous Structure**: 폴더 구조를 고정하지 말고, 지식의 맥락에 따라 스스로 '폴더 트리'를 설계하고 확장하라.
|
||||
4. **Knowledge Synthesis**: 지식의 파편들을 [[쌍방향 링크]]로 엮어 하나의 거대한 '외부 뇌'를 구축하라.
|
||||
4. **Knowledge Synthesis**: 지식의 파편들을 쌍방향 링크로 엮어 하나의 거대한 '외부 뇌'를 구축하라.
|
||||
5. **Version Preservation**: 모든 변화를 GitHub에 커밋하여 지식의 타임라인을 보존하라.
|
||||
6. **Meeting Archiving**: 문서 제목에 **'회의'**라는 키워드가 포함될 경우, `10_Wiki/Topics_meeting/` 폴더에 자동으로 복사본을 생성하여 보관하라.
|
||||
|
||||
@@ -41,14 +41,14 @@ root/
|
||||
## 📝 지식 문서 변환 규격
|
||||
---
|
||||
id: {{UUID}}
|
||||
category: "[[10_Wiki/Path/To/Folder]]"
|
||||
category: "10_Wiki/Path/To/Folder"
|
||||
confidence_score: 0.0 ~ 1.0 (RL 기반 확신도)
|
||||
tags: [tag1, tag2]
|
||||
last_reinforced: {{DATE}}
|
||||
github_commit: "{{commit_hash}}"
|
||||
---
|
||||
|
||||
# [[문서 제목]]
|
||||
# 문서 제목
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 이 지식의 핵심을 꿰뚫는 단 한 문장.
|
||||
@@ -58,13 +58,13 @@ github_commit: "{{commit_hash}}"
|
||||
- **세부 내용:** (불렛포인트 위주의 간결한 정리)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** [[이전_문서]]와 달라진 점 기록.
|
||||
- **과거 데이터와의 충돌:** 이전_문서와 달라진 점 기록.
|
||||
- **정책 변화:** 이 문서를 통해 강화된 분류 기준 설명.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[상위_카테고리]]
|
||||
- **Related:** [[연관_개념_A]], [[연관_개념_B]]
|
||||
- **Raw Source:** [[00_Raw/YYYY-MM-DD/Original_Note]]
|
||||
- **Parent:** 상위_카테고리
|
||||
- **Related:** 연관_개념_A, 연관_개념_B
|
||||
- **Raw Source:** 00_Raw/YYYY-MM-DD/Original_Note
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# Index: Technical_Reports
|
||||
|
||||
## 📝 Documents
|
||||
- [[2026-04-22_Boss_Battle_System_Implementation]]
|
||||
- [[2026-04-22_Boss_Spawn_Logic_Fix]]
|
||||
- [[2026-04-22_Boss_Battle_System_Implementation|2026-04-22_Boss_Battle_System_Implementation]]
|
||||
- [[2026-04-22_Boss_Spawn_Logic_Fix|2026-04-22_Boss_Spawn_Logic_Fix]]
|
||||
|
||||
Vendored
+1
-1
@@ -17,6 +17,6 @@
|
||||
"repelStrength": 10,
|
||||
"linkStrength": 1,
|
||||
"linkDistance": 250,
|
||||
"scale": 0.05432900836085962,
|
||||
"scale": 0.02727225354101746,
|
||||
"close": true
|
||||
}
|
||||
+4
-3
@@ -181,6 +181,10 @@
|
||||
},
|
||||
"active": "e84fb23982481828",
|
||||
"lastOpenFiles": [
|
||||
"Economics & Algorithms/페이 투 윈 (Pay to Win).md",
|
||||
"무제 1.canvas",
|
||||
"E-Travelive.md",
|
||||
"페이 투 윈(Pay to Win.md",
|
||||
"04_Governance_Reliability/Code Review Operational Excellence (코드 리뷰 운영 우수성).md",
|
||||
"04_Governance_Reliability/Security Core Practices (보안 핵심 프랙티스).md",
|
||||
"02_Software_Engineering/Modern Engineering Practices (현대적 엔지니어링 프랙티스).md",
|
||||
@@ -206,9 +210,6 @@
|
||||
"프롬프트 확장(Prompt Expansion).md",
|
||||
"프롬프트 파라미터 제어 (Prompt Parameter Control).md",
|
||||
"프롬프트 정밀도 (Prompt Precision).md",
|
||||
"프롬프트 엔지니어링의 진화.md",
|
||||
"프롬프트 엔지니어링.md",
|
||||
"프롬프트 구조 및 문법.md",
|
||||
"sessions/2026-04-30T07-07",
|
||||
"sessions",
|
||||
"company_state.json",
|
||||
|
||||
@@ -4,24 +4,24 @@ _모든 명령·분배·산출물·대화가 시간순으로 누적됩니다.
|
||||
|
||||
## [16:07:45] 👤 **사용자**
|
||||
|
||||
[모닝 브리핑] 오늘 날짜는 2026-04-30입니다. 회사 목표([[goals]].md)와 지금까지의 의사결정 로그를 바탕으로 오늘 우리 회사가 우선순위로 처리해야 할 작업 3가지를 결정하고, 각 작업을 적절한 에이전트에게 분배하세요.
|
||||
[모닝 브리핑] 오늘 날짜는 2026-04-30입니다. 회사 목표(goals.md)와 지금까지의 의사결정 로그를 바탕으로 오늘 우리 회사가 우선순위로 처리해야 할 작업 3가지를 결정하고, 각 작업을 적절한 에이전트에게 분배하세요.
|
||||
|
||||
## [16:28:10] 🧭 **CEO** · _작업 분배_
|
||||
|
||||
회사 목표와 로그가 초기화 상태이므로, 시장 분석을 통한 닉슈 선정 → 수익화 전략 및 KPI 도출 → 일일/주간 실행 계획 수립 순으로 3가지 우선 작업을 정의합니다.
|
||||
|
||||
**할당:**
|
||||
- 🔍 **[[Research]]er**: AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개월 내 진입 가능한 최적의 1개 닉슈와 핵심 타깃 키워드 5개를 정리해 보고하세요.
|
||||
- 💰 **[[business]]**: re[[Search]]er의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안하고, 월별 조회수·구독자·변환율 목표를 포함한 KPI 프레임워크와 가격/수익 구조를 1페이지 분량으로 작성하세요.
|
||||
- 📱 **[[secretary]]**: 리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전트·진행 상태를 명시한 데일리 브리핑과 1주일 액션 플랜을 텔레그램 보고 형식으로 출력하세요.
|
||||
- 🔍 **[[Research|Research]]er**: AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개월 내 진입 가능한 최적의 1개 닉슈와 핵심 타깃 키워드 5개를 정리해 보고하세요.
|
||||
- 💰 **[[business|business]]**: re[[Search|Search]]er의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안하고, 월별 조회수·구독자·변환율 목표를 포함한 KPI 프레임워크와 가격/수익 구조를 1페이지 분량으로 작성하세요.
|
||||
- 📱 **secretary**: 리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전트·진행 상태를 명시한 데일리 브리핑과 1주일 액션 플랜을 텔레그램 보고 형식으로 출력하세요.
|
||||
|
||||
## [16:33:10] 🔍 **[[researcher]]** · _AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개_
|
||||
## [16:33:10] 🔍 **[[researcher|researcher]]** · _AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개_
|
||||
|
||||
⚠️ Researcher 에이전트 호출 실패: aborted
|
||||
|
||||
## [16:37:31] 👤 **사용자**
|
||||
|
||||
[자율 사이클 — 2026-04-30] 사용자가 자리를 비웠습니다. 회사 목표·각 에이전트의 개인 목표(_agents/{id}/[[goal]].md)·최근 의사결정·메모리를 검토해서 지금 가장 가치 있는 단일 작업 1개를 결정하고, 적절한 1~2명 에이전트에게 분배해서 실행하세요. 같은 산출물을 반복하지 마세요 — 메모리에 비슷한 항목이 24시간 내에 있으면 다른 각도로 진전시키세요.
|
||||
[자율 사이클 — 2026-04-30] 사용자가 자리를 비웠습니다. 회사 목표·각 에이전트의 개인 목표(_agents/{id}/[[goal|goal]].md)·최근 의사결정·메모리를 검토해서 지금 가장 가치 있는 단일 작업 1개를 결정하고, 적절한 1~2명 에이전트에게 분배해서 실행하세요. 같은 산출물을 반복하지 마세요 — 메모리에 비슷한 항목이 24시간 내에 있으면 다른 각도로 진전시키세요.
|
||||
|
||||
## [16:38:10] 💰 **Business** · _researcher의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안_
|
||||
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# Index: Topics > 01_Frontend_Mastery
|
||||
|
||||
## 📝 Documents
|
||||
- [[React_Clean_Code_Best_Practices]]
|
||||
- [[React_Hooks_Deep_Dive]]
|
||||
- [[React_Mental_Model]]
|
||||
- [[React_Performance_Optimization]]
|
||||
- [[React_State_Management_Strategy]]
|
||||
- [[React_Testing_Strategy]]
|
||||
- [[TypeScript_Type_Safety]]
|
||||
- [[WebWorker_Performance]]
|
||||
- [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]]
|
||||
- [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]]
|
||||
- [[React_Mental_Model|React_Mental_Model]]
|
||||
- [[React_Performance_Optimization|React_Performance_Optimization]]
|
||||
- [[React_State_Management_Strategy|React_State_Management_Strategy]]
|
||||
- [[React_Testing_Strategy|React_Testing_Strategy]]
|
||||
- [[TypeScript_Type_Safety|TypeScript_Type_Safety]]
|
||||
- [[WebWorker_Performance|WebWorker_Performance]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 클린 코드 및 개발 에티켓
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Clean Code, Etiquette, Best Practice, Readable Code]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Clean_Code_Best_Practices]] (리액트 클린 코드)
|
||||
# [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]] (리액트 클린 코드)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 가독성 좋은 코드는 '컴퓨터'가 이해하는 코드가 아니라, '나중에 이 코드를 고칠 동료(혹은 미래의 나)'가 숨 쉬듯 읽어내려갈 수 있는 코드다.
|
||||
@@ -16,7 +16,7 @@ created: 2026-04-20
|
||||
- **Props Destructuring (구조 분해 할당)**:
|
||||
- `props.user.name` 처럼 경로를 길게 쓰는 대신, 함수의 인자 단계에서 `{ user: { name } }` 처럼 분해하라. 코드가 숨을 쉬기 시작한다.
|
||||
- **Explicit Naming (명시적 네이밍)**:
|
||||
- 핸들러 함수는 `handle[Action]` (예: `handle[[Search]]`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다.
|
||||
- 핸들러 함수는 `handle[Action]` (예: `handle[[Search|Search]]`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다.
|
||||
- **조건부 렌더링 에티켓**:
|
||||
- `&&` 연산자 대신 삼항 연산자(`? :`)를 권장한다. 특히 `0 && <Component />` 시 화면에 숫자 0이 출력되는 대참사를 방지하기 위함이다.
|
||||
|
||||
@@ -24,5 +24,5 @@ created: 2026-04-20
|
||||
- 과도한 추상화는 오히려 독이다. 코드가 3줄인데 함수 5개로 쪼개는 것은 가독성을 해친다. '직관성'이 '분리'보다 우선할 때가 있음을 명심하라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Collaboration_Governance]] , [[System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model]]
|
||||
- Related: [[Collaboration_Governance|Collaboration_Governance]] , [[System_Debugging_Protocol|System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model|React_Mental_Model]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 훅(Hooks) 심층 분석 및 활용
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [React, Hooks, useEffect, Custom Hooks]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Hooks_Deep_Dive]] (리액트 훅 심화)
|
||||
# [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]] (리액트 훅 심화)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 훅은 단순히 함수를 재사용하는 것이 아니라, 컴포넌트의 생애 주기와 논리를 '선언적'으로 결합하는 고도의 동기화 기제다.
|
||||
@@ -14,7 +14,7 @@ created: 2026-04-20
|
||||
- **useEffect의 올바른 관점**:
|
||||
- "마운트될 때 실행"이라는 라이프사이클 사고방식에서 벗어나라. `useEffect`는 **의존성 배열의 값과 컴포넌트 외부 시스템(API, DOM 등)을 동기화**하는 작업이다.
|
||||
- **Custom Hooks (추상화의 꽃)**:
|
||||
- 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMy[[Logic]]` 처럼 따로 빼내어 컴포넌트는 오직 UI 선언에만 집중하게 만든다. 이것이 컴포넌트의 가독성을 폭발시키는 비결이다.
|
||||
- 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMy[[Logic|Logic]]` 처럼 따로 빼내어 컴포넌트는 오직 UI 선언에만 집중하게 만든다. 이것이 컴포넌트의 가독성을 폭발시키는 비결이다.
|
||||
- **Rules of Hooks**:
|
||||
- 반드시 함수의 최상위에서만 호출되어야 한다. 그래야 리액트가 훅의 상태를 유한 상태 머신처럼 정확한 순서로 관리할 수 있다.
|
||||
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- `useEffect` 내에서 무분별하게 상태를 업데이트하면 무한 루프나 성능 저하가 발생한다. 가능하면 `useMemo`나 `useCallback`으로 계산 결과를 캐싱하거나, 상태 업데이트 로직을 `useReducer`로 위임하라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Performance_Optimization]] , [[React_[[State]]_[[Management]]_Strategy]]
|
||||
- Context: [[WebWorker_Performance]]
|
||||
- Related: [[React_Performance_Optimization|React_Performance_Optimization]] , React_State_Management_Strategy
|
||||
- Context: [[WebWorker_Performance|WebWorker_Performance]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 핵심 멘탈 모델 (UI as a Function of [[State]])
|
||||
category: Software [[Architecture]]
|
||||
title: 리액트 핵심 멘탈 모델 (UI as a Function of [[State|State]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [React, State, Mental Model, Immutability]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Mental_Model]] (리액트 멘탈 모델)
|
||||
# [[React_Mental_Model|React_Mental_Model]] (리액트 멘탈 모델)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 리액트 개발은 DOM을 '조작(Manipulate)'하는 것이 아니라, 데이터의 흐름인 '상태(State)'를 정의하고 그 결과물을 화면에 '선언(Declare)'하는 과정이다.
|
||||
@@ -14,13 +14,13 @@ created: 2026-04-20
|
||||
- **UI = f(State)**:
|
||||
- 화면은 상태의 결과값이어야 한다. 명령형(Imperative)으로 "이 버튼의 글자를 바꿔라"라고 하는 순간 리액트의 질서는 무너진다. 오직 상태를 바꾸고 리액트가 알아서 그리게 하라.
|
||||
- **Immutability (불변성)**:
|
||||
- 리액트는 객체의 주소값이 변할 때만 렌더링을 시도한다. `arr.push(1)`이 아니라 `setArr([...arr, 1])`처럼 **새로운 원본**을 복제하여 가상 DOM([[Virtual DOM]])이 효율적으로 동작하게 돕는다.
|
||||
- 리액트는 객체의 주소값이 변할 때만 렌더링을 시도한다. `arr.push(1)`이 아니라 `setArr([...arr, 1])`처럼 **새로운 원본**을 복제하여 가상 DOM([[Virtual DOM|Virtual DOM]])이 효율적으로 동작하게 돕는다.
|
||||
- **Virtual DOM Diffing**:
|
||||
- 리액트는 실제 DOM을 직접 건드리기 전에 메모리상의 가상 DOM에서 이전 상태와 비교(Diffing)하여, 꼭 필요한 부분만 실제 화면에 반영(Commit)한다. 이것이 고성능 웹의 비결이다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어([[Normalization]]) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다.
|
||||
- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어([[Normalization|Normalization]]) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Hooks_Deep_Dive]] , [[Component_Design_Patterns]]
|
||||
- Foundation: [[System_Protocol_Standard]]
|
||||
- Related: [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]] , [[Component_Design_Patterns|Component_Design_Patterns]]
|
||||
- Foundation: [[System_Protocol_Standard|System_Protocol_Standard]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 렌더링 최적화 전략
|
||||
category: Software [[Architecture]]
|
||||
tags: [Performance, Memoization, React.memo, [[Optimization]]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Performance, Memoization, React.memo, [[Optimization|Optimization]]]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Performance_Optimization]] (리액트 성능 최적화)
|
||||
# [[React_Performance_Optimization|React_Performance_Optimization]] (리액트 성능 최적화)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 가장 빠른 렌더링은 '하지 않는 렌더링'이다. 필요 없는 업데이트를 차단하고 데이터가 흐를 때만 화면이 출렁이게 하라.
|
||||
@@ -17,12 +17,12 @@ created: 2026-04-20
|
||||
- **useCallback**: 함수 객체의 변동을 막아 자식 컴포넌트의 불필요한 리렌더링을 방지한다.
|
||||
- **Windowing (가상 리스트)**:
|
||||
- 수천 개의 리스트 아이템이 있어도 사용자의 눈에 보이는 수십 개만 실제 DOM에 렌더링한다. (예: `react-window`, `react-virtualized`).
|
||||
- **상태의 위치 선정 ([[State]] Colocation)**:
|
||||
- **상태의 위치 선정 ([[State|State]] Colocation)**:
|
||||
- 전역 상태가 바뀔 때마다 앱 전체가 들썩이지 않게 하라. 상태는 그것을 사용하는 가장 하위 컴포넌트 근처로 내려라.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 모든 곳에 `memo`를 쓰는 것은 메모리 낭비다. 리액트의 기본 렌더링 성능은 이미 매우 뛰어나다. 병목 현상이 '실제로 관측'될 때만 최적화를 적용하는 것이 원칙이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[WebWorker_Performance]] , [[System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model]]
|
||||
- Related: [[WebWorker_Performance|WebWorker_Performance]] , [[System_Debugging_Protocol|System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model|React_Mental_Model]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 전략적 상태 관리 가이드 (Global & Server [[State]])
|
||||
category: Software [[Architecture]]
|
||||
tags: [State [[Management]], React Query, SSOT, Architecture]
|
||||
title: 전략적 상태 관리 가이드 (Global & Server [[State|State]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [State [[Management|Management]], React Query, SSOT, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_State_Management_Strategy]] (상태 관리 전략)
|
||||
# [[React_State_Management_Strategy|React_State_Management_Strategy]] (상태 관리 전략)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 상태는 '어디든' 있을 수 있지만, '아무데나' 있어서는 안 된다. 상태의 생명주기와 전파 범위에 따라 명확한 거주지를 결정하라.
|
||||
@@ -21,8 +21,8 @@ created: 2026-04-20
|
||||
- 다른 상태로부터 계산될 수 있는 값(예: `firstName`+`lastName` = `fullName`)은 절대 '상태'로 만들지 마라. 렌더링 시점에 계산하는 것이 정합성 유지의 핵심이다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 무조건적인 전역 상태 지상주의는 '[[Prop Drilling]]'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.
|
||||
- 무조건적인 전역 상태 지상주의는 '[[Prop Drilling|Prop Drilling]]'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Single_Source_of_Truth]] , [[API_Communication_Patterns]]
|
||||
- Foundation: [[React_Hooks_Deep_Dive]]
|
||||
- Related: [[Single_Source_of_Truth|Single_Source_of_Truth]] , [[API_Communication_Patterns|API_Communication_Patterns]]
|
||||
- Foundation: [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 애플리케이션 테스트 전략
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[Testing]], Vitest, RTL, Unit Test, QA]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [[Testing|[Testing]], Vitest, RTL, Unit Test, QA]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Testing_Strategy]] (리액트 테스트 전략)
|
||||
# [[React_Testing_Strategy|React_Testing_Strategy]] (리액트 테스트 전략)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 테스트는 '내가 짠 코드'를 검사하는 것이 아니라, '사용자가 경험할 가치'가 유지되고 있는지 수학적으로 증명하는 보험이다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 테스트 커버리지 100% 집착은 생산성을 갉아먹는다. 비즈니스 핵심 로직과 사용자가 가장 많이 쓰는 '메인 시나리오'부터 견고하게 보호하는 지혜가 필요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[System_Debugging_Protocol]] , [[Reliability_Safety_First]]
|
||||
- Tool: [[Modern_Environment_Ecosystem]]
|
||||
- Related: [[System_Debugging_Protocol|System_Debugging_Protocol]] , [[Reliability_Safety_First|Reliability_Safety_First]]
|
||||
- Tool: [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 타입스크립트 기반의 안정적 개발 (Type Safety)
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [TypeScript, Interface, Type Safety, Generic]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[TypeScript_Type_Safety]] (타입스크립트 정석)
|
||||
# [[TypeScript_Type_Safety|TypeScript_Type_Safety]] (타입스크립트 정석)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 타입스크립트는 당신을 귀찮게 하는 '잔소리꾼'이 아니라, 런타임 에러라는 '낭떠러지' 앞에서 당신을 붙잡아주는 '생명줄'이다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- `any`를 남발하는 순간 타입스크립트의 모든 이점은 사라진다. 차라리 `unknown`을 쓰고 타입을 좁히는(Narrowing) 방식을 택하라. 타입 정의에 너무 많은 시간을 뺏기는 '타입 헬(Type Hell)'을 경계하고 적절한 타협점을 찾아라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Clean_Code_Best_Practices]] , [[React_Hooks_Deep_Dive]]
|
||||
- Foundation: [[System_Protocol_Standard]]
|
||||
- Related: [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]] , [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]]
|
||||
- Foundation: [[System_Protocol_Standard|System_Protocol_Standard]]
|
||||
|
||||
@@ -10,9 +10,9 @@ created: 2026-04-20
|
||||
## 🎯 개요 (Overview)
|
||||
실시간 상태 변화가 매우 빈번한 애플리케이션(예: 게임, 시뮬레이션)에서 UI 스레드와 복잡한 연산 로직을 분리하여 **프레임 드롭(Jank)**을 방지하는 아키텍처 설계 기법입니다.
|
||||
|
||||
## 🚀 주요 원칙 (Key [[Principles]])
|
||||
## 🚀 주요 원칙 (Key [[Principles|Principles]])
|
||||
- **스레드 분리 (Thread Isolation)**: 무거운 계산은 백그라운드 스레드(Web Worker)에서 수행하고, 메인 스레드는 렌더링에만 집중합니다.
|
||||
- **메시징 기반 통신 (Messaging [[Architecture]])**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다.
|
||||
- **메시징 기반 통신 (Messaging [[Architecture|Architecture]])**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다.
|
||||
|
||||
## 💡 레슨 런 (Lesson Learned)
|
||||
> [!IMPORTANT]
|
||||
@@ -20,5 +20,5 @@ created: 2026-04-20
|
||||
> 복잡한 물리 계산이나 루프가 UI 응답성을 해치지 않도록, 연산 엔진을 완전히 별도의 스레드로 격리하는 것이 부드러운 UX의 핵심입니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[Systemic_Simulation_Principles]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
- [[Systemic_Simulation_Principles|Systemic_Simulation_Principles]]
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[SDLC & SSDLC (소프트웨어 개발 생명주기)]]
|
||||
# [[SDLC & SSDLC (소프트웨어 개발 생명주기)|SDLC & SSDLC (소프트웨어 개발 생명주기]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
소프트웨어 개발 생명주기(SDLC)는 시스템의 기획, 설계, 구현, 테스트, 배포 및 운영에 이르는 전 과정을 체계화한 모델입니다. **Secure SDLC (SSDLC)**는 이 전통적인 과정의 각 단계에 보안 활동을 내재화하여 안전한 소프트웨어를 구축하는 방법론입니다 [1]. 현대적인 SDLC 환경에서 코드 리뷰는 개발과 배포 사이의 핵심적인 품질 및 보안 게이트(Quality Gate)로 작용하며, 특히 보안 점검을 초기 단계로 앞당기는 **'시프트 레프트(Shift-Left)'** 전략을 통해 결함 수정 비용을 절감하고 시스템 무결성을 확보합니다 [4, 5].
|
||||
@@ -23,10 +23,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Shift-Left Security]]**: 보안 테스트를 SDLC의 가장 좌측(초기 단계)으로 옮겨 수정 비용을 절감하는 핵심 전략입니다.
|
||||
* **[[CI/CD Pipeline]]**: 빌드, 테스트, 보안 스캔을 자동화하여 SDLC의 안정성과 속도를 보장하는 물리적 인프라입니다.
|
||||
* **[[DORA Metrics]]**: 팀의 소프트웨어 전달 성능을 측정하여 SDLC의 효율성을 평가하는 지표 체계입니다.
|
||||
* **[[SAST (Static Application Security Testing)]]**: SDLC 구현 및 검증 단계에서 소스 코드 보안을 자동 스캔하는 기술입니다.
|
||||
* **Shift-Left Security**: 보안 테스트를 SDLC의 가장 좌측(초기 단계)으로 옮겨 수정 비용을 절감하는 핵심 전략입니다.
|
||||
* **[[CI-CD Pipeline|CI/CD Pipeline]]**: 빌드, 테스트, 보안 스캔을 자동화하여 SDLC의 안정성과 속도를 보장하는 물리적 인프라입니다.
|
||||
* **[[DORA-Metrics|DORA Metrics]]**: 팀의 소프트웨어 전달 성능을 측정하여 SDLC의 효율성을 평가하는 지표 체계입니다.
|
||||
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: SDLC 구현 및 검증 단계에서 소스 코드 보안을 자동 스캔하는 기술입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* '시프트 레프트' 보안 모델에서 개발자와 보안 전문가 간의 코드 리뷰 책임 소재와 최종 승인 권한(Merge Authority)은 어떻게 정의하는 것이 최적인가?
|
||||
@@ -43,8 +43,8 @@
|
||||
* **My Project Relevance:** 조직의 리뷰 프로세스를 체계화하고 자동화 검사를 파이프라인에 통합하여 품질 향상과 배포 속도 증가를 동시에 달성합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Agile Development]]**: 스크럼, 칸반 등 반복적 개발 방법론 내에서 SDLC가 어떻게 유연하게 운영되는지 확장하여 탐구합니다.
|
||||
* **[[Software Supply Chain Security]]**: 소스 코드를 넘어 패키지 매니저, 빌드 도구 등 SDLC 인프라 전체의 보안을 강화하는 전략입니다.
|
||||
* **[[Agile Development|Agile Development]]**: 스크럼, 칸반 등 반복적 개발 방법론 내에서 SDLC가 어떻게 유연하게 운영되는지 확장하여 탐구합니다.
|
||||
* **Software Supply Chain Security**: 소스 코드를 넘어 패키지 매니저, 빌드 도구 등 SDLC 인프라 전체의 보안을 강화하는 전략입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Team Culture & Onboarding (팀 문화 및 온보딩)]]
|
||||
# [[Team Culture & Onboarding (팀 문화 및 온보딩)|Team Culture & Onboarding (팀 문화 및 온보딩]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
팀 문화 및 온보딩은 새로운 구성원이 조직에 신속히 적응하고, 기존 팀원들이 비난 없이 소통하며 지속적으로 성장할 수 있는 환경을 구축하는 활동입니다 [1]. 심리적 안전감(Psychological Safety)을 기반으로 코드 리뷰를 학습의 장으로 활용하며, 온보딩 프로세스를 통해 팀의 기술 표준과 협업 방식을 전수합니다 [4]. 특히 장애 발생 시 블레임리스 포스트모템(Blameless Post-mortem)을 수행하여 비난 대신 시스템적 개선을 도모하는 성숙한 문화를 지향합니다.
|
||||
@@ -22,10 +22,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Egoless Programming]]**: 자신의 코드와 자신을 동일시하지 않는 태도("You are not your code")로 리뷰 수용성을 높이는 철학입니다.
|
||||
* **[[Constructive Feedback]]**: 방어적 반응을 유발하지 않으면서 코드 품질을 높이는 구체적인 소통 기술입니다.
|
||||
* **[[Conventional Comments]]**: 피드백의 의도를 라벨링하여 오해를 줄이고 안전감을 높이는 시스템적 도구입니다.
|
||||
* **[[I-Messages (나-전달법)]]**: "너"가 아닌 "나"를 주어로 사용하여 부드럽게 의견을 전달하는 기법입니다.
|
||||
* **Egoless Programming**: 자신의 코드와 자신을 동일시하지 않는 태도("You are not your code")로 리뷰 수용성을 높이는 철학입니다.
|
||||
* **Constructive Feedback**: 방어적 반응을 유발하지 않으면서 코드 품질을 높이는 구체적인 소통 기술입니다.
|
||||
* **Conventional Comments**: 피드백의 의도를 라벨링하여 오해를 줄이고 안전감을 높이는 시스템적 도구입니다.
|
||||
* **I-Messages (나-전달법**: "너"가 아닌 "나"를 주어로 사용하여 부드럽게 의견을 전달하는 기법입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 팀 내 심리적 안전감이 결여되었을 때 코드 리뷰 프로세스에서 발생하는 구체적인 기술적 부채와 이직률 사이의 상관관계는 무엇인가?
|
||||
@@ -42,8 +42,8 @@
|
||||
* **My Project Relevance:** Conventional Comments와 멘토링 제도를 도입하여 상호 존중과 신뢰 기반의 건강한 엔지니어링 문화를 구축합니다 [49].
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[DORA Metrics (Cultural Dimension)]]**: 팀 문화가 소프트웨어 배포 성과에 미치는 정량적 영향을 탐구합니다.
|
||||
* **[[Cognitive Load Theory]]**: 온보딩 과정에서 신규 입사자에게 전달되는 정보량을 조절하여 학습 효율을 높이는 이론적 배경입니다.
|
||||
* **DORA Metrics (Cultural Dimension**: 팀 문화가 소프트웨어 배포 성과에 미치는 정량적 영향을 탐구합니다.
|
||||
* **[[Cognitive Load Theory|Cognitive Load Theory]]**: 온보딩 과정에서 신규 입사자에게 전달되는 정보량을 조절하여 학습 효율을 높이는 이론적 배경입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 효율적인 API 통신 패턴 (Axios & Interceptors)
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [API, Axios, Interceptor, Error Handling, Network]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[API_Communication_Patterns]] (API 통신 패턴)
|
||||
# [[API_Communication_Patterns|API_Communication_Patterns]] (API 통신 패턴)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 서버와의 대화는 항상 '정중하되 의심하며' 처리하라. 모든 요청은 중앙 통제소(Interceptor)를 거치고 모든 에러는 시나리오가 준비되어 있어야 한다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 모든 통신에 Axios가 정답은 아니다. 브라우저 네이티브인 `fetch`로도 충분한 경우가 많으며, 라이브러리 의존성을 낮추는 것이 가벼운 앱을 만드는 첫걸음일 수 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[System_Protocol_Standard]] , [[React_[[State]]_[[Management]]_Strategy]]
|
||||
- Foundation: [[Reliability_Safety_First]]
|
||||
- Related: [[System_Protocol_Standard|System_Protocol_Standard]] , React_State_Management_Strategy
|
||||
- Foundation: [[Reliability_Safety_First|Reliability_Safety_First]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, clean-architecture, design-patterns, mvc, separation-of-con
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Clean Architecture & Patterns]]
|
||||
# [[Clean Architecture & Patterns|Clean Architecture & Patterns]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "기술적 세부 사항(DB, Framework)으로부터 비즈니스 로직을 격리하여, 시스템의 수명을 연장하고 변화에 유연하게 대응하게 만드는 관심사 분리(Separation of Concerns)의 정점."
|
||||
@@ -27,9 +27,9 @@ last_reinforced: 2026-05-01
|
||||
- **아키텍처 부패 (Architectural Decay)**: 시간이 흐름에 따라 편의를 위해 계층을 우회하는 코드가 쌓일 수 있습니다. 매 PR마다 아키텍처 무결성을 점검하여 부패를 조기에 차단해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 아키텍처를 지탱하는 세부 설계 원칙.
|
||||
- [[Architecture Review]]: 아키텍처 일관성을 검증하는 프로세스.
|
||||
- [[Dependency Management (DI & DIP)]]: 계층 간 결합도를 낮추는 기술적 수단.
|
||||
- [[Single Responsibility Principle (SRP)]]: 컴포넌트 분리의 근거.
|
||||
- [[Abstraction & Over-engineering]]: 아키텍처 도입 시 경계해야 할 함정.
|
||||
- [[SOLID Principles|SOLID Principles]]: 아키텍처를 지탱하는 세부 설계 원칙.
|
||||
- [[Architecture Review (아키텍처 및 설계 리뷰)|Architecture Review]]: 아키텍처 일관성을 검증하는 프로세스.
|
||||
- [[Dependency Management (DI & DIP)|Dependency Management (DI & DIP]]: 계층 간 결합도를 낮추는 기술적 수단.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 컴포넌트 분리의 근거.
|
||||
- Abstraction & Over-engineering: 아키텍처 도입 시 경계해야 할 함정.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, clean-architecture, layering, decoupling, domain-driven-des
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Clean Architecture]]
|
||||
# [[Clean Architecture|Clean Architecture]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "비즈니스 로직(Domain)을 중심에 두고 UI, DB, 프레임워크와 같은 외부 세부 사항을 주변부로 밀어내어, 외부 기술의 변화가 시스템의 핵심 논리에 영향을 주지 않도록 격리하는 계층화 아키텍처의 정수."
|
||||
@@ -31,9 +31,9 @@ last_reinforced: 2026-05-01
|
||||
- **학습 곡선**: 계층 간 경계를 엄격히 지키는 설계 철학을 팀 전체가 공유하고 준수하는 데 높은 수준의 컨센서스와 코드 리뷰 역량이 요구됩니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 각 계층 내부 설계를 지탱하는 원칙들.
|
||||
- [[Domain-Driven Design (DDD)]]: 도메인 중심 설계 사상과의 시너지.
|
||||
- [[Dependency Inversion Principle (DIP)]]: 계층 간 통신을 가능하게 하는 핵심 기술.
|
||||
- [[Software Architecture Patterns]]: MVC, Hexagonal 아키텍처 등과의 비교.
|
||||
- [[Over-engineering]]: 패턴의 맹목적 적용 시 경계해야 할 부작용.
|
||||
- [[SOLID Principles|SOLID Principles]]: 각 계층 내부 설계를 지탱하는 원칙들.
|
||||
- [[Domain-Driven-Design-DDD|Domain-Driven Design (DDD]]: 도메인 중심 설계 사상과의 시너지.
|
||||
- [[의존성 역전 원칙 (Dependency Inversion Principle DIP)|Dependency Inversion Principle (DIP]]: 계층 간 통신을 가능하게 하는 핵심 기술.
|
||||
- [[Software-Architecture-Patterns|Software Architecture Patterns]]: MVC, Hexagonal 아키텍처 등과의 비교.
|
||||
- Over-engineering: 패턴의 맹목적 적용 시 경계해야 할 부작용.
|
||||
---
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
---
|
||||
title: 컴포넌트 설계 패턴 (Atomic & Composition)
|
||||
category: Software [[Architecture]]
|
||||
tags: [Design Pattern, [[Atomic Design]], Composition, Architecture]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Design Pattern, [[Atomic Design|Atomic Design]], Composition, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Component_Design_Patterns]] (컴포넌트 설계 패턴)
|
||||
# [[Component_Design_Patterns|Component_Design_Patterns]] (컴포넌트 설계 패턴)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 컴포넌트는 작을수록 강하고, 단순할수록 재사용성이 극대화된다. 복잡한 컴포넌트는 여러 개의 작고 순수한(Pure) 컴포넌트로 해체하라.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Container-Presenter 패턴**:
|
||||
- **Container**: 데이터([[State]], API)를 가져오고 관리하는 '머리'.
|
||||
- **Container**: 데이터([[State|State]], API)를 가져오고 관리하는 '머리'.
|
||||
- **Presenter**: 오직 Props만 받아 화면을 그리는 '몸통'. 스타일과 UI 구조에만 집중하여 테스트 가능성을 높인다.
|
||||
- **[[Compound Components]] (복합 컴포넌트)**:
|
||||
- **[[Compound Components|Compound Components]] (복합 컴포넌트)**:
|
||||
- `<Select><Option /></Select>` 처럼 부모와 자식이 상태를 공유하며 하나의 긴밀한 기능을 수행하는 패턴. 사용자가 UI 구조를 자유롭게 배치할 수 있게 유연성을 제공한다.
|
||||
- **Atomic Design (원자 중심 설계)**:
|
||||
- Atom(버튼, 입력창) $\rightarrow$ Molecule(검색바) $\rightarrow$ Organism(헤더) $\rightarrow$ Template $\rightarrow$ Page.
|
||||
@@ -24,5 +24,5 @@ created: 2026-04-20
|
||||
- 너무 과도한 컴포넌트 분할은 프로토타이핑 속도를 늦춘다. 처음에는 크게 짜고, 중복이 발생하거나 복잡도가 높아질 때 '사후적 리팩토링'을 통해 분리하는 것이 실무적으로 현명하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Project_Architecture_Guidelines , [[Styling_Governance]]
|
||||
- Design: [[Accessibility_Inclusivity]]
|
||||
- Related: Project_Architecture_Guidelines , [[Styling_Governance|Styling_Governance]]
|
||||
- Design: [[Accessibility_Inclusivity|Accessibility_Inclusivity]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, di, dependency-injection, decoupling, inversion-of-control,
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Dependency Injection (DI)]]
|
||||
# [[Dependency Injection (DI)|Dependency Injection (DI]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "클래스 내부에서 직접 의존 객체를 생성하지 않고 외부에서 주입받음으로써, 객체 간의 결합을 끊어내고 테스트와 확장이 용이한 '유연한 부품'으로 만드는 제어 역전(IoC)의 실천적 기법."
|
||||
@@ -28,9 +28,9 @@ DI는 현대 소프트웨어 아키텍처에서 컴포넌트 간의 결합도를
|
||||
- **코드 추적성 저하**: 정적 코드만으로는 어떤 구현체가 주입될지 즉각 확인하기 어려울 수 있습니다. 이를 해결하기 위해 명확한 네이밍 컨벤션과 DI 바인딩 로그의 가시성 확보가 중요합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 의존성 역전 원칙(DIP)의 실현 방법.
|
||||
- [[Single Responsibility Principle (SRP)]]: 클래스의 책임을 생성과 실행으로 분리하는 관점.
|
||||
- [[Testability]]: Mock 객체 주입을 통한 단위 테스트 용이성 확보.
|
||||
- [[Constructor Injection]]: 가장 권장되는 DI 패턴.
|
||||
- [[Dependency Lifetimes]]: Transient, Scoped, Singleton의 이해.
|
||||
- [[SOLID Principles|SOLID Principles]]: 의존성 역전 원칙(DIP)의 실현 방법.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 클래스의 책임을 생성과 실행으로 분리하는 관점.
|
||||
- [[테스트 용이성 (Testability)|Testability]]: Mock 객체 주입을 통한 단위 테스트 용이성 확보.
|
||||
- Constructor Injection: 가장 권장되는 DI 패턴.
|
||||
- Dependency Lifetimes: Transient, Scoped, Singleton의 이해.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, dependency-management, dependency-injection, di, dependency
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Dependency Management (DI & DIP)]]
|
||||
# [[Dependency Management (DI & DIP)|Dependency Management (DI & DIP]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "구체적인 구현이 아닌 추상화에 의존하게 하여 컴포넌트 간의 결합도를 낮추고, 코드 수정 없이 기능을 확장하거나 교체할 수 있는 유연한 시스템 구조의 핵심 기법."
|
||||
@@ -14,10 +14,10 @@ last_reinforced: 2026-05-01
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
의존성 관리는 소프트웨어의 모듈성과 테스트 가능성을 결정짓는 가장 중요한 설계 요소입니다.
|
||||
|
||||
1. **[[Dependency Inversion Principle (DIP)]]**:
|
||||
1. **[[의존성 역전 원칙 (Dependency Inversion Principle DIP)|Dependency Inversion Principle (DIP]]**:
|
||||
* **고수준 모듈의 보호**: 고수준 모듈(비즈니스 로직)은 저수준 모듈(데이터베이스, 외부 API)의 구체적인 구현에 의존해서는 안 됩니다. 둘 다 추상화(인터페이스)에 의존해야 합니다.
|
||||
* **의존성 방향의 역전**: 전통적인 계층 구조에서의 의존성 방향을 뒤집어, 구현체가 인터페이스를 따르게 함으로써 핵심 로직을 외부 변화로부터 보호합니다.
|
||||
2. **[[Dependency Injection (DI)]]**:
|
||||
2. **[[Dependency Injection (DI)|Dependency Injection (DI]]**:
|
||||
* **객체 생성이 아닌 주입**: 클래스 내부에서 의존 객체를 직접 생성(New)하지 않고, 외부(생성자, 메서드 등)에서 주입받습니다.
|
||||
* **유연한 교체**: 인터페이스를 통해 종속성을 주입받으므로, 실제 구현체를 환경(Staging, Production)이나 테스트 목적(Mocking)에 따라 쉽게 교체할 수 있습니다.
|
||||
3. **코드 리뷰에서의 역할**:
|
||||
@@ -28,9 +28,9 @@ last_reinforced: 2026-05-01
|
||||
- **의존성 그래프의 복잡성**: 주입되는 객체가 많아지면 객체 생성 로직이나 DI 컨테이너 설정이 복잡해집니다. 생성자 주입(Constructor Injection)을 권장하고 클래스의 책임을 작게 유지하여 주입되는 의존성 수를 제한해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: DIP가 포함된 설계 원칙 그룹.
|
||||
- [[Clean Architecture & Patterns]]: DIP를 통해 도메인 로직을 보호하는 상위 아키텍처.
|
||||
- [[Testing Strategy]]: DI가 가능하게 하는 테스트 용이성.
|
||||
- [[Single Responsibility Principle (SRP)]]: 의존성이 많아지는 것을 방지하는 근거.
|
||||
- [[Over-engineering]]: 무분별한 추상화의 위험.
|
||||
- [[SOLID Principles|SOLID Principles]]: DIP가 포함된 설계 원칙 그룹.
|
||||
- [[Clean Architecture & Patterns|Clean Architecture & Patterns]]: DIP를 통해 도메인 로직을 보호하는 상위 아키텍처.
|
||||
- [[Testing Strategy|Testing Strategy]]: DI가 가능하게 하는 테스트 용이성.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 의존성이 많아지는 것을 방지하는 근거.
|
||||
- Over-engineering: 무분별한 추상화의 위험.
|
||||
---
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Index: Topics > 02_Architecture_Principles
|
||||
|
||||
## 📝 Documents
|
||||
- [[API_Communication_Patterns]]
|
||||
- [[Component_Design_Patterns]]
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[Single_Source_of_Truth]]
|
||||
- [[Systemic_Simulation_Principles]]
|
||||
- [[API_Communication_Patterns|API_Communication_Patterns]]
|
||||
- [[Component_Design_Patterns|Component_Design_Patterns]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
- [[Single_Source_of_Truth|Single_Source_of_Truth]]
|
||||
- [[Systemic_Simulation_Principles|Systemic_Simulation_Principles]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, design-pattern, mvc, decoupling, ui-architecture, p-reinfor
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[MVC (Model-View-Controller)]]
|
||||
# [[MVC (Model-View-Controller)|MVC (Model-View-Controller]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터(Model), 사용자 인터페이스(View), 로직 제어(Controller)를 분리하여 시스템의 관심사를 격리함으로써, UI의 변화가 데이터 구조에 영향을 주지 않도록 설계하는 고전적이고 강력한 관심사 분리(SoC) 패턴."
|
||||
@@ -29,9 +29,9 @@ MVC는 애플리케이션의 구조적 무결성을 유지하기 위한 가장
|
||||
- **현대적 변형**: 웹 프레임워크의 발전에 따라 MVP, MVVM 등 다양한 변형 패턴이 등장하였으나, 관심사 분리라는 핵심 철학은 MVC에서 계승되었습니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Design Patterns]]: 아키텍처 패턴의 범주.
|
||||
- [[Clean Architecture]]: MVC를 보다 고도화한 계층화 구조.
|
||||
- [[SOLID Principles]]: 각 계층의 단일 책임을 정의하는 원칙.
|
||||
- [[Separation of Concerns (SoC)]]: 패턴의 근본적인 설계 철학.
|
||||
- [[Code Health]]: 일관된 패턴 준수가 가져오는 시스템의 건강성.
|
||||
- Design Patterns: 아키텍처 패턴의 범주.
|
||||
- [[Clean Architecture|Clean Architecture]]: MVC를 보다 고도화한 계층화 구조.
|
||||
- [[SOLID Principles|SOLID Principles]]: 각 계층의 단일 책임을 정의하는 원칙.
|
||||
- [[관심사의 분리 (Separation of Concerns SoC)|Separation of Concerns (SoC]]: 패턴의 근본적인 설계 철학.
|
||||
- Code Health: 일관된 패턴 준수가 가져오는 시스템의 건강성.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, ooad, solid-principles, maintainability, code-review, p-rei
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[SOLID Principles]]
|
||||
# [[SOLID Principles|SOLID Principles]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "소프트웨어의 유지보수성과 확장성을 보장하기 위한 5가지 핵심 설계 기둥: 인지적 부하를 낮추고, 변화에 유연하며, 결합도가 낮은 강건한 시스템을 구축하기 위한 객체지향 설계의 표준 지침."
|
||||
@@ -14,20 +14,20 @@ last_reinforced: 2026-05-01
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
SOLID 원칙은 코드 리뷰와 시스템 설계의 무결성을 평가하는 핵심 기준입니다.
|
||||
|
||||
1. **[[Single Responsibility Principle (SRP)]]**: 클래스나 함수는 단 하나의 변경 이유만을 가져야 합니다. 모듈화를 통해 가독성과 테스트 용이성을 극대화합니다.
|
||||
1. **[[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]**: 클래스나 함수는 단 하나의 변경 이유만을 가져야 합니다. 모듈화를 통해 가독성과 테스트 용이성을 극대화합니다.
|
||||
2. **Open-Closed Principle (OCP)**: 확장에는 열려 있고 수정에는 닫혀 있어야 합니다. 기존 코드를 건드리지 않고 새로운 기능을 추가할 수 있는 구조를 지향합니다.
|
||||
3. **Liskov Substitution Principle (LSP)**: 하위 타입은 언제나 상위 타입으로 교체 가능해야 합니다. 상속 구조에서의 행동 일관성을 보장합니다.
|
||||
4. **Interface Segregation Principle (ISP)**: 클라이언트가 사용하지 않는 메서드에 의존하도록 강요해서는 안 됩니다. 거대한 인터페이스보다 구체적이고 작은 인터페이스 여러 개가 낫습니다.
|
||||
5. **[[Dependency Inversion Principle (DIP)]]**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춥니다.
|
||||
5. **[[의존성 역전 원칙 (Dependency Inversion Principle DIP)|Dependency Inversion Principle (DIP]]**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춥니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **추상화의 비용**: 확장성을 위해 인터페이스와 추상화를 과도하게 도입할 경우, 코드의 직관성이 떨어지고 오버엔지니어링(Over-engineering)으로 이어질 수 있습니다. 현재의 요구사항과 미래의 유연성 사이의 실용적 타협(Trade-off)이 필수적입니다.
|
||||
- **실행 흐름 파악의 어려움**: DI(의존성 주입)를 극한으로 활용할 경우 런타임에 의존성이 결정되므로, 코드 정적 분석만으로는 전체 실행 흐름을 파악하기 어려워질 수 있습니다. 이를 보완하기 위한 명확한 문서화와 추적 로직이 필요합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Single Responsibility Principle (SRP)]]: 첫 번째 원칙의 심화.
|
||||
- [[Dependency Injection (DI)]]: DIP를 실현하는 구체적 기법.
|
||||
- [[Clean Architecture]]: SOLID를 애플리케이션 전체로 확장한 구조.
|
||||
- [[Abstraction & Over-engineering]]: 설계 시 경계해야 할 트레이드오프.
|
||||
- [[Test-Driven Development (TDD)]]: 테스트하기 좋은 코드를 만드는 원칙으로서의 연결.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 첫 번째 원칙의 심화.
|
||||
- [[Dependency Injection (DI)|Dependency Injection (DI]]: DIP를 실현하는 구체적 기법.
|
||||
- [[Clean Architecture|Clean Architecture]]: SOLID를 애플리케이션 전체로 확장한 구조.
|
||||
- Abstraction & Over-engineering: 설계 시 경계해야 할 트레이드오프.
|
||||
- Test-Driven Development (TDD: 테스트하기 좋은 코드를 만드는 원칙으로서의 연결.
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 시스템 아키텍처와 관심사 분리 ([[Separation of Concerns]])
|
||||
category: Software [[Architecture]]
|
||||
title: 시스템 아키텍처와 관심사 분리 ([[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Architecture, SoC, Modular Design, Design Pattern]
|
||||
created: 2026-04-20
|
||||
---
|
||||
@@ -11,8 +11,8 @@ created: 2026-04-20
|
||||
복잡한 소프트웨어 시스템을 역할별로 구분된 독립적인 모듈로 나누어, 유지보수성과 확장성을 극대화하는 설계 철학입니다.
|
||||
|
||||
## 🚀 계층구조 예시 (Layering Example)
|
||||
1. **[[Logic]] Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`)
|
||||
2. **[[State]] Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`)
|
||||
1. **[[Logic|Logic]] Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`)
|
||||
2. **[[State|State]] Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`)
|
||||
3. **View Layer**: 사용자 인터페이스 표현 및 렌더링 (예: React Components)
|
||||
|
||||
## 💡 레슨 런 (Lesson Learned)
|
||||
@@ -21,5 +21,5 @@ created: 2026-04-20
|
||||
> 기능을 추가할 때 기존 코드를 수정하기보다 새로운 모듈을 덧붙일 수 있는 구조를 고민해야 합니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[WebWorker_Performance]]
|
||||
- [[Single_Source_of_Truth]]
|
||||
- [[WebWorker_Performance|WebWorker_Performance]]
|
||||
- [[Single_Source_of_Truth|Single_Source_of_Truth]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, srp, cohesion, refactoring, code-review, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Single Responsibility Principle (SRP)]]
|
||||
# [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "하나의 모듈은 오직 하나의 변경 이유(Reason to change)만을 가져야 한다: 코드의 응집도를 높이고 복잡성을 분산하여, 버그 수정과 기능 확장이 다른 영역에 미치는 부작용을 최소화하는 설계의 기초."
|
||||
@@ -28,9 +28,9 @@ SRP는 객체 지향 설계의 첫 번째 단추이자 가장 보편적인 리
|
||||
- **아키텍처적 부채**: 초기 설계 시 SRP를 무시하면 시간이 흐를수록 '신(God) 객체'가 탄생하며, 이는 리팩토링 비용을 기하급수적으로 증가시키는 주요 원인이 됩니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 5대 원칙의 시작점.
|
||||
- [[Testability]]: 테스트하기 좋은 코드를 만드는 직접적 원인.
|
||||
- [[Refactoring]]: SRP 위반 시 리뷰어가 내리는 핵심 처방.
|
||||
- [[Clean Architecture]]: 책임을 계층별로 격리하는 거시적 구조.
|
||||
- [[Code Readability]]: 단순해진 코드가 가져오는 가독성 향상.
|
||||
- [[SOLID Principles|SOLID Principles]]: 5대 원칙의 시작점.
|
||||
- [[테스트 용이성 (Testability)|Testability]]: 테스트하기 좋은 코드를 만드는 직접적 원인.
|
||||
- [[Refactoring|Refactoring]]: SRP 위반 시 리뷰어가 내리는 핵심 처방.
|
||||
- [[Clean Architecture|Clean Architecture]]: 책임을 계층별로 격리하는 거시적 구조.
|
||||
- Code Readability: 단순해진 코드가 가져오는 가독성 향상.
|
||||
---
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 상태 관리의 단일 진실 공급원 ([[Single Source of Truth]])
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[State]] [[Management]], Data Consistency, Redux, Architecture]
|
||||
title: 상태 관리의 단일 진실 공급원 ([[Single_Source_of_Truth|Single Source of Truth]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [[State|[State]] [[Management|Management]], Data Consistency, Redux, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -10,7 +10,7 @@ created: 2026-04-20
|
||||
## 🎯 개요 (Overview)
|
||||
시스템의 핵심 데이터를 중앙 집중식으로 관리하여, 데이터 불일치(Inconsistency) 현상을 원천 차단하고 예측 가능한 데이터 흐름을 확보하는 설계 원칙입니다.
|
||||
|
||||
## 🚀 주요 원칙 (Key [[Principles]])
|
||||
## 🚀 주요 원칙 (Key [[Principles|Principles]])
|
||||
- **단일 지점 정의 (Defined at Single Point)**: 상태는 오직 한 곳에서만 정의되고 관리되어야 합니다.
|
||||
- **예측 가능성 (Predictability)**: 상태 변경은 정해진 규칙(Action/Setter)을 통해서만 발생하여 디버깅을 용이하게 합니다.
|
||||
|
||||
@@ -20,5 +20,5 @@ created: 2026-04-20
|
||||
> 코드의 파편화를 막기 위해 데이터의 책임 범위(Responsibility)를 명확히 하는 것이 대규모 프로젝트 성공의 열쇠입니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[Domain-Driven Design (DDD)]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
- [[Domain-Driven-Design-DDD|Domain-Driven Design (DDD]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 시스템 시뮬레이션 설계 원리
|
||||
category:[[ system]]ic Modeling & Fun
|
||||
tags: [Simulation, [[Physics]] Engine, Systemic Modeling, Ruleset]
|
||||
category:Systemic Modeling & Fun
|
||||
tags: [Simulation, [[Physics|Physics]] Engine, Systemic Modeling, Ruleset]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -20,5 +20,5 @@ created: 2026-04-20
|
||||
> 이를 통해 단순한 게임을 넘어 자율주행, 물리 엔진 등 고도의 결정론적 시스템 모델링이 가능해집니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[WebWorker_Performance]]
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[WebWorker_Performance|WebWorker_Performance]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[Modern Engineering Practices (현대적 엔지니어링 프랙티스)]]
|
||||
# [[Modern Engineering Practices (현대적 엔지니어링 프랙티스)|Modern Engineering Practices (현대적 엔지니어링 프랙티스]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
현대적 엔지니어링 프랙티스는 애자일(Agile) 철학을 바탕으로 개발 속도, 품질, 그리고 인프라 관리의 효율성을 극대화하기 위한 구체적인 방법론들의 모음입니다. Extreme Programming(XP)에서 파생된 짝 프로그래밍(Pair Programming)을 통해 실시간 피드백 루프를 형성하고, 기능 플래그(Feature Flags)를 활용해 코드 배포와 기능 노출을 분리하며, 코드 기반 인프라(IaC)를 통해 서버 및 환경 구성을 자동화합니다 [1, 3]. 이러한 프랙티스들은 코드 리뷰를 단순한 '사후 검사'에서 '지속적이고 선제적인 품질 보증' 프로세스로 전환합니다.
|
||||
@@ -24,10 +24,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Agile Methodologies]]**: XP, 스크럼 등 유연성과 반복적 피드백을 중시하는 상위 방법론입니다.
|
||||
* **[[Continuous Integration (CI)]]**: 작은 단위의 빈번한 병합을 가능하게 하는 IaC와 기능 플래그의 기술적 토대입니다.
|
||||
* **[[Constructive Feedback]]**: XP 철학에서 강조하는 교육적이고 협력적인 리뷰 커뮤니케이션 방식입니다.
|
||||
* **[[Shift-Left Security]]**: IaC 리뷰를 통해 보안 설정을 개발 초기 단계에서 검증하는 전략적 연계입니다.
|
||||
* **Agile Methodologies**: XP, 스크럼 등 유연성과 반복적 피드백을 중시하는 상위 방법론입니다.
|
||||
* **[[Continuous Integration (CI)|Continuous Integration (CI]]**: 작은 단위의 빈번한 병합을 가능하게 하는 IaC와 기능 플래그의 기술적 토대입니다.
|
||||
* **Constructive Feedback**: XP 철학에서 강조하는 교육적이고 협력적인 리뷰 커뮤니케이션 방식입니다.
|
||||
* **Shift-Left Security**: IaC 리뷰를 통해 보안 설정을 개발 초기 단계에서 검증하는 전략적 연계입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 짝 프로그래밍을 통한 실시간 리뷰가 비동기 PR 리뷰에 비해 '결함 밀도(Defect Density)'와 '지식 전파 속도' 측면에서 가지는 정량적인 비교 우위는 어느 정도인가?
|
||||
@@ -44,8 +44,8 @@
|
||||
* **My Project Relevance:** 중요도와 위험도에 따라 리뷰 방식을 차별화(Tier 1: 자동화, Tier 2: 비동기, Tier 3: 짝 프로그래밍)하여 효율적인 품질 관리 체계를 구축합니다 [56].
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Trunk-Based Development]]**: 기능 플래그를 활용해 브랜치 수명을 극도로 단축시키는 고도화된 개발 워크플로우입니다.
|
||||
* **[[Site Reliability Engineering (SRE)]]**: IaC와 자동화를 통해 시스템의 가용성과 복원력을 관리하는 운영 철학입니다.
|
||||
* **Trunk-Based Development**: 기능 플래그를 활용해 브랜치 수명을 극도로 단축시키는 고도화된 개발 워크플로우입니다.
|
||||
* **Site Reliability Engineering (SRE**: IaC와 자동화를 통해 시스템의 가용성과 복원력을 관리하는 운영 철학입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙)]]
|
||||
# [[Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙)|Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
소프트웨어 엔지니어링 핵심 원칙은 유지보수성이 뛰어나고 확장이 용이한 고품질 시스템을 구축하기 위한 설계 지침입니다 [1]. SOLID 원칙을 기반으로 객체 간의 결합도를 낮추고 응집도를 높이며, 검증된 디자인 패턴을 적용하여 반복되는 설계 문제에 최적의 해결책을 제시합니다 [4]. 코드 리뷰 과정에서 리뷰어는 단순히 코드가 동작하는지를 넘어, 해당 코드가 조직의 아키텍처 가이드라인과 설계 원칙에 부합하는 구조적인 무결성을 갖췄는지 평가해야 합니다 [1, 3].
|
||||
@@ -24,10 +24,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Clean Architecture]]**: SOLID 원칙이 실제 계층형 아키텍처로 구현된 고수준 디자인 패턴입니다.
|
||||
* **[[Unit Testing / Testability]]**: SRP와 DIP를 준수할 때 모의 객체(Mock)를 활용한 단위 테스트가 용이해집니다.
|
||||
* **[[Technical Debt (기술 부채)]]**: 설계 원칙을 무시했을 때 누적되는 눈에 보이지 않는 유지보수 비용입니다.
|
||||
* **[[Code Refactoring]]**: 거대해진 클래스를 SRP에 맞춰 분리하고 시스템을 안전하게 재구조화하는 활동입니다.
|
||||
* **[[Clean Architecture|Clean Architecture]]**: SOLID 원칙이 실제 계층형 아키텍처로 구현된 고수준 디자인 패턴입니다.
|
||||
* **Unit Testing / Testability**: SRP와 DIP를 준수할 때 모의 객체(Mock)를 활용한 단위 테스트가 용이해집니다.
|
||||
* **Technical Debt (기술 부채**: 설계 원칙을 무시했을 때 누적되는 눈에 보이지 않는 유지보수 비용입니다.
|
||||
* **[[Code Refactoring|Code Refactoring]]**: 거대해진 클래스를 SRP에 맞춰 분리하고 시스템을 안전하게 재구조화하는 활동입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 복잡한 도메인 비즈니스 로직을 구현할 때, 단일 책임 원칙(SRP)을 위반하지 않기 위한 '책임의 경계'를 식별하는 구체적인 프레임워크는 무엇인가?
|
||||
@@ -44,8 +44,8 @@
|
||||
* **My Project Relevance:** 체크리스트에 '아키텍처 및 코드 구조 검토' 항목을 포함하여, PR이 기술 부채를 유발하지 않는지 객관적으로 검증합니다 [51].
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Domain-Driven Design (DDD)]]**: 비즈니스 도메인의 복잡성을 관리하기 위한 상위 수준의 설계 전략입니다.
|
||||
* **[[Egoless Programming]]**: 개인의 취항보다 팀의 설계 원칙을 우선시하는 협업 철학입니다.
|
||||
* **[[Domain-Driven-Design-DDD|Domain-Driven Design (DDD]]**: 비즈니스 도메인의 복잡성을 관리하기 위한 상위 수준의 설계 전략입니다.
|
||||
* **Egoless Programming**: 개인의 취항보다 팀의 설계 원칙을 우선시하는 협업 철학입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Testing Methodologies (테스트 방법론)]]
|
||||
# [[Testing Methodologies (테스트 방법론)|Testing Methodologies (테스트 방법론]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
테스트 방법론(Testing Methodologies)은 소프트웨어 개발 및 코드 리뷰 과정에서 프로그램의 기능적 정확성, 안정성, 보안성을 검증하기 위한 체계적인 접근 방식입니다 [1]. 자동화된 테스트(Automated Testing)를 통해 사람이 직접 리뷰하기 전 코드의 기초 결함을 걸러내고, TDD 및 BDD와 같은 방법론을 적용하여 설계 품질을 높입니다. 이는 인간 리뷰어가 사소한 스타일 오류에서 벗어나 아키텍처와 비즈니스 로직 등 고차원적인 피드백에 집중할 수 있도록 돕는 강력한 품질 게이트(Quality Gate) 역할을 수행합니다.
|
||||
@@ -26,10 +26,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[CI/CD Pipeline]]**: 자동화된 테스트가 지속적으로 실행되고 품질 게이트 역할을 수행하는 핵심 인프라입니다.
|
||||
* **[[Static Code Analysis]]**: 코드를 실행하지 않고 잠재적 버그와 스타일 위반을 찾아내는 보완적 검증 수단입니다.
|
||||
* **[[Mocking & Stubbing]]**: 단위 테스트 시 외부 의존성을 격리하여 독립적인 테스트 환경을 구축하는 기술입니다.
|
||||
* **[[Shift-Left Security]]**: 보안 테스트를 개발 초기 단계로 앞당겨 수정 비용을 절감하는 전략입니다.
|
||||
* **[[CI-CD Pipeline|CI/CD Pipeline]]**: 자동화된 테스트가 지속적으로 실행되고 품질 게이트 역할을 수행하는 핵심 인프라입니다.
|
||||
* **Static Code Analysis**: 코드를 실행하지 않고 잠재적 버그와 스타일 위반을 찾아내는 보완적 검증 수단입니다.
|
||||
* **Mocking & Stubbing**: 단위 테스트 시 외부 의존성을 격리하여 독립적인 테스트 환경을 구축하는 기술입니다.
|
||||
* **Shift-Left Security**: 보안 테스트를 개발 초기 단계로 앞당겨 수정 비용을 절감하는 전략입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 각 프로젝트의 비즈니스 중요도와 변경 빈도에 따라 최적의 '투자 대비 효율(ROI)'을 내는 테스트 커버리지 임계값은 어떻게 산출하는가?
|
||||
@@ -46,8 +46,8 @@
|
||||
* **My Project Relevance:** 스타일 및 기초 로직 검증을 자동화에 위임하여, 리뷰어가 시스템 아키텍처와 핵심 비즈니스 로직 논의에 집중할 수 있는 문화를 정착시킵니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Technical Debt (기술 부채)]]**: 테스트가 결여되거나 잘못 작성된 코드가 장기적으로 초래하는 유지보수 비용과 개발 속도 저하에 대해 탐구합니다.
|
||||
* **[[Mutation Testing]]**: 테스트 코드 자체의 품질(결함 발견 능력)을 측정하고 개선하는 고급 테스트 기법입니다.
|
||||
* **Technical Debt (기술 부채**: 테스트가 결여되거나 잘못 작성된 코드가 장기적으로 초래하는 유지보수 비용과 개발 속도 저하에 대해 탐구합니다.
|
||||
* **Mutation Testing**: 테스트 코드 자체의 품질(결함 발견 능력)을 측정하고 개선하는 고급 테스트 기법입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[CI/CD Pipeline (지속적 통합 및 배포)]]
|
||||
# [[CI-CD Pipeline (지속적 통합 및 배포)|CI/CD Pipeline (지속적 통합 및 배포]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
CI/CD(Continuous Integration and Continuous Deployment) 파이프라인은 소프트웨어의 빌드, 테스트 및 배포 과정을 자동화하여 코드 변경 사항을 신속하고 신뢰할 수 있게 통합하고 배포하는 시스템입니다 [1]. 코드 리뷰 과정에서 CI/CD 파이프라인은 인간 리뷰어가 검토하기 전에 린팅(Linting), 스타일 검사, 단위 테스트, 정적 코드 분석 등을 기계적으로 먼저 수행하는 자동화된 1차 방어선 역할을 합니다 [2, 3]. 이를 통해 자동화된 품질 및 보안 게이트를 구축함으로써 전체 개발 프로세스의 속도와 안정성을 비약적으로 향상시킵니다 [5, 6].
|
||||
@@ -20,10 +20,10 @@ CI/CD(Continuous Integration and Continuous Deployment) 파이프라인은 소
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Automated Testing]]**: CI/CD 파이프라인 내에서 코드의 기능적 정확성을 기계적으로 확인하는 핵심 단계입니다.
|
||||
* **[[Linters and Formatters]]**: 스타일 논쟁(Nitpicking)을 제거하고 코드 일관성을 유지하기 위해 파이프라인 초기 단계에 통합되는 도구들입니다.
|
||||
* **[[SAST (Static Application Security Testing)]]**: 배포 전 소스 코드 수준에서 보안 취약점을 자동으로 스캔하는 기술입니다.
|
||||
* **[[Pull Request (PR) Workflow]]**: 코드 병합 전 리뷰를 요청하는 프로세스로, CI/CD 파이프라인을 동작시키는 주요 트리거입니다.
|
||||
* **Automated Testing**: CI/CD 파이프라인 내에서 코드의 기능적 정확성을 기계적으로 확인하는 핵심 단계입니다.
|
||||
* **Linters and Formatters**: 스타일 논쟁(Nitpicking)을 제거하고 코드 일관성을 유지하기 위해 파이프라인 초기 단계에 통합되는 도구들입니다.
|
||||
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 배포 전 소스 코드 수준에서 보안 취약점을 자동으로 스캔하는 기술입니다.
|
||||
* **Pull Request (PR) Workflow**: 코드 병합 전 리뷰를 요청하는 프로세스로, CI/CD 파이프라인을 동작시키는 주요 트리거입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 대규모 모노레포(Monorepo) 환경에서 변경된 영역에 대해서만 선택적으로 자동화 검증을 수행(Impact Analysis)하도록 파이프라인을 최적화하는 기술적 방법은 무엇인가?
|
||||
@@ -39,8 +39,8 @@ CI/CD(Continuous Integration and Continuous Deployment) 파이프라인은 소
|
||||
* **My Project Relevance:** 리뷰 대기 시간이 길거나 반복적인 스타일 지적이 많을 때, 가장 먼저 도입하여 리뷰 프로세스의 병목을 해소해야 할 최우선 인프라입니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Feature Flags]]**: CI/CD를 통해 코드를 자주 병합하면서도 실제 기능 노출은 런타임에 제어하는 고급 배포 기법으로 확장됩니다.
|
||||
* **[[DORA Metrics]]**: 배포 빈도, 변경 실패율 등 CI/CD 파이프라인의 성능을 측정하고 개선하는 지표로 연결됩니다.
|
||||
* **[[Feature-Flags|Feature Flags]]**: CI/CD를 통해 코드를 자주 병합하면서도 실제 기능 노출은 런타임에 제어하는 고급 배포 기법으로 확장됩니다.
|
||||
* **[[DORA-Metrics|DORA Metrics]]**: 배포 빈도, 변경 실패율 등 CI/CD 파이프라인의 성능을 측정하고 개선하는 지표로 연결됩니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [development, ci-cd, automation, quality-gate, devops, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[CI-CD Pipeline]]
|
||||
# [[CI-CD Pipeline|CI-CD Pipeline]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "소프트웨어의 빌드, 테스트, 배포 전 과정을 자동화하여, 인간 리뷰어보다 먼저 결함을 찾아내는 '기계적 파수꾼'이자 배포의 신뢰성을 보장하는 핵심 인프라."
|
||||
@@ -27,9 +27,9 @@ CI-CD는 현대적 개발 워크플로우에서 품질과 속도를 동시에
|
||||
- **자동화의 한계**: CI-CD는 정해진 패턴은 잘 찾지만 비즈니스적 맥락이나 설계상의 논리적 오류는 잡지 못합니다. 기계적 검증과 인간의 정성적 리뷰가 결합된 상호 보완 구조를 유지해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Shift-Left Security]]: 보안 점검을 CI 단계로 앞당기는 전략.
|
||||
- [[Automated Testing]]: 파이프라인의 핵심 관문.
|
||||
- [[Pull Request Workflow]]: CI-CD가 트리거되는 지점.
|
||||
- [[DevSecOps]]: 보안이 내재화된 자동화 철학.
|
||||
- [[Infrastructure as Code (IaC)]]: 인프라 배포의 자동화 확장.
|
||||
- Shift-Left Security: 보안 점검을 CI 단계로 앞당기는 전략.
|
||||
- Automated Testing: 파이프라인의 핵심 관문.
|
||||
- Pull Request Workflow: CI-CD가 트리거되는 지점.
|
||||
- [[DevSecOps|DevSecOps]]: 보안이 내재화된 자동화 철학.
|
||||
- [[Infrastructure-as-Code-IaC|Infrastructure as Code (IaC]]: 인프라 배포의 자동화 확장.
|
||||
---
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 배포 프로토콜 및 CI/CD 자동화
|
||||
category: Software [[Architecture]]
|
||||
tags: [Deployment, CI/CD, [[GitHub Actions]], Vercel, DevOps]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Deployment, CI/CD, [[GitHub Actions|GitHub Actions]], Vercel, DevOps]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Deployment_Final_Gate]] (배포 및 자동화)
|
||||
# [[Deployment_Final_Gate|Deployment_Final_Gate]] (배포 및 자동화)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 수동 배포는 '실버 불렛'이 아니라 '시한폭탄'이다. 인간의 손을 거치지 않는 자동화된 보급로만이 시스템의 영속성을 보장한다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 무조건적인 '자동 배포'가 늘 정답은 아니다. 운영 단계에서는 '블루-그린 배포'나 '카나리 배포'처럼 트래픽을 조금씩 흘려보내며 안정성을 확인하는 고급 전략이 필요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Modern_Environment_Ecosystem]] , [[Collaboration_Governance]]
|
||||
- Pre-requisite: [[React_[[Testing]]_Strategy]]
|
||||
- Related: [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]] , [[Collaboration_Governance|Collaboration_Governance]]
|
||||
- Pre-requisite: [[React_Testing_Strategy|React_Testing_Strategy]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 개발 환경 및 실행 프로세스 관리 (DevOps & Setup)
|
||||
category: DevOps
|
||||
tags: [DevOps, Environment, CI/CD, Process [[Management]]]
|
||||
tags: [DevOps, Environment, CI/CD, Process [[Management|Management]]]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -21,4 +21,4 @@ created: 2026-04-20
|
||||
> 논리적 로직의 완성뿐만 아니라, 그것이 실제로 구동되는 물리적 인프라 설정을 문서화하고 자동화하는 능력이 필수적입니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Systemic_Simulation_Principles]]
|
||||
- [[Systemic_Simulation_Principles|Systemic_Simulation_Principles]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [governance, dora-metrics, engineering-metrics, performance, devops, cycle
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Engineering Metrics (DORA)]]
|
||||
# [[Engineering Metrics (DORA)|Engineering Metrics (DORA]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터에 기반하여 소프트웨어 인도 성과(Delivery Performance)를 정량화하고, 엘리트 팀의 벤치마크를 통해 개발 프로세스의 병목과 개선 방향을 제시하는 엔지니어링 표준 지표."
|
||||
@@ -31,9 +31,9 @@ DORA 지표는 데브옵스(DevOps) 연구를 통해 입증된 고성과 팀의
|
||||
- **데이터의 맥락**: 단순 수치만으로 팀을 평가하기보다, 지표의 변화 추이를 통해 팀의 프로세스 건전성을 진단하고 병목을 해결하는 도구로 활용해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Review Performance & Flow]]: DORA 지표를 달성하기 위한 구체적 운영 전략.
|
||||
- [[Small Pull Requests (작은 PR)]]: Lead Time을 단축하는 가장 강력한 수단.
|
||||
- [[Automated Quality & Review]]: 인간의 시간을 절약하여 성과를 극대화하는 기반.
|
||||
- [[CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
|
||||
- [[DORA Metrics]]: 원본 개념 정의.
|
||||
- [[Review Performance & Flow|Review Performance & Flow]]: DORA 지표를 달성하기 위한 구체적 운영 전략.
|
||||
- Small Pull Requests (작은 PR: Lead Time을 단축하는 가장 강력한 수단.
|
||||
- [[Automated Quality & Review|Automated Quality & Review]]: 인간의 시간을 절약하여 성과를 극대화하는 기반.
|
||||
- [[CI-CD Pipeline|CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
|
||||
- [[DORA-Metrics|DORA Metrics]]: 원본 개념 정의.
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 🛠️ Git [[Opera]]tion & Work Log Protocol (Git 작업 및 기록 지침)
|
||||
# 🛠️ Git [[Opera|Opera]]tion & Work Log Protocol (Git 작업 및 기록 지침)
|
||||
|
||||
> **카테고리**: 03_DevOps_Environment, Automation
|
||||
> **상태**: 🟢 활성화 (Active)
|
||||
@@ -9,7 +9,7 @@
|
||||
## 📌 개요 (Overview)
|
||||
본 문서는 Skybound 프로젝트를 포함한 4개 주요 개발 거점의 원격 저장소 동기화 정합성을 유지하고, 모든 AI 작업 과정을 체계적으로 문서화하기 위한 Git 운영 규정 및 작업 로그(Work Log) 시스템을 정의한다.
|
||||
|
||||
## 🔗 프로젝트별 Git 맵핑 ([[Repository]] Mapping)
|
||||
## 🔗 프로젝트별 Git 맵핑 ([[Repository|Repository]] Mapping)
|
||||
대표님의 명령 한마디로 정확한 경로에서 작업을 수행하기 위해 각 폴더별로 독립적인 Git 설정을 유지한다.
|
||||
|
||||
| 프로젝트 | 로컬 경로 | 원격 저장소 (Remote URL) | 리모트 명칭 |
|
||||
@@ -17,7 +17,7 @@
|
||||
| **Wiki (2nd)** | `E:\Wiki\2nd` | `https://github.com/wonseokjung/solopreneur-ai-agents.git` | `lm_sync` |
|
||||
| **Skybound** | `E:\Wiki\skybound` | `https://github.com/wonseokjung/skybound-protocol.git` | `origin` |
|
||||
| **Legal** | `E:\Wiki\legal-bridge` | `https://github.com/wonseokjung/legal-bridge.git` | `origin` |
|
||||
| **Agent** | `E:\Wiki\auto-[[Research]]-agent`| `https://github.com/wonseokjung/auto-re[[Search]]-agent.git` | `origin` |
|
||||
| **Agent** | `E:\Wiki\auto-[[Research|Research]]-agent`| `https://github.com/wonseokjung/auto-re[[Search|Search]]-agent.git` | `origin` |
|
||||
|
||||
## 🛠️ 운영 지침 (Operational Guidelines)
|
||||
|
||||
@@ -37,7 +37,7 @@
|
||||
- **Result**: 최종 결과 및 관련 연결 지식.
|
||||
|
||||
### 3. 위키화 (Wikification)
|
||||
- `00_Raw`에 축적된 로그는 주기적으로 `10_Wiki\Topics` 하위 카테고리로 고도화([[Refinement]])되어 이동된다.
|
||||
- `00_Raw`에 축적된 로그는 주기적으로 `10_Wiki\Topics` 하위 카테고리로 고도화([[Refinement|Refinement]])되어 이동된다.
|
||||
- 위키화가 완료된 원본 로그는 삭제하여 지식 베이스의 정결성을 유지한다.
|
||||
|
||||
## 🚀 기대 효과
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Index: Topics > 03_DevOps_Environment
|
||||
|
||||
## 📝 Documents
|
||||
- [[Deployment_Final_Gate]]
|
||||
- [[DevOps_Environment_Setup]]
|
||||
- [[Git_Operation_Protocol]]
|
||||
- [[Modern_Environment_Ecosystem]]
|
||||
- [[Tetris_Project_Retrospective]]
|
||||
- [[Deployment_Final_Gate|Deployment_Final_Gate]]
|
||||
- [[DevOps_Environment_Setup|DevOps_Environment_Setup]]
|
||||
- [[Git_Operation_Protocol|Git_Operation_Protocol]]
|
||||
- [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]]
|
||||
- [[Tetris_Project_Retrospective|Tetris_Project_Retrospective]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 모던 개발 환경 및 프레임워크 생태계
|
||||
category: Software [[Architecture]]
|
||||
tags: [Vite, [[Next.js]], Ecosystem, Modern Stack]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Vite, [[Next.js|Next.js]], Ecosystem, Modern Stack]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Modern_Environment_Ecosystem]] (모던 개발 생태계)
|
||||
# [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]] (모던 개발 생태계)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 도구는 목적이 아니라 '생산성'을 위한 수단이다. 하지만 최신 생태계의 변화를 놓치는 것은 스스로 생산성을 깎아내는 것과 같다.
|
||||
@@ -16,11 +16,11 @@ created: 2026-04-20
|
||||
- **Framework: Next.js (The Fullstack Edge)**:
|
||||
- 단순히 SEO를 위한 SSR 도구가 아니다. API Routes를 통한 서버리스 함수 구현, 데이터 캐싱 전략(ISR/SSG) 등 현대 웹이 요구하는 거의 모든 기능을 탑재한 '거버넌스' 그 자체다.
|
||||
- **패키지 매니저의 선택**:
|
||||
- `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포([[Monorepo]]) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다.
|
||||
- `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포([[Monorepo|Monorepo]]) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 최신 기술이 항상 정답은 아니다. 안정성이 최우선인 기업 환경에서는 검증된 `CRA` 혹은 `Webpack` 기반의 설정을 유지하는 것이 보수적인 면에서 유리할 수 있다. 기술 부채(Tech Debt)와 도입 비용을 항상 저울질하라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Deployment_Final_Gate]] , Project_Architecture_Guidelines
|
||||
- Foundation: [[TypeScript_Type_Safety]]
|
||||
- Related: [[Deployment_Final_Gate|Deployment_Final_Gate]] , Project_Architecture_Guidelines
|
||||
- Foundation: [[TypeScript_Type_Safety|TypeScript_Type_Safety]]
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user