[G1-Sync] Manual knowledge update

2026-04-30 22:42:02 +09:00
parent 0bd4f19e38
commit c36c0644a1
4888 changed files with 18470 additions and 18602 deletions
@@ -1,6 +1,6 @@
 ---
 title: 리액트 클린 코드 및 개발 에티켓
-category: Software Architecture
+category: Software [[Architecture]]
 tags: [Clean Code, Etiquette, Best Practice, Readable Code]
 created: 2026-04-20
 ---
@@ -16,7 +16,7 @@ created: 2026-04-20
 - **Props Destructuring (구조 분해 할당)**:
    - `props.user.name` 처럼 경로를 길게 쓰는 대신, 함수의 인자 단계에서 `{ user: { name } }` 처럼 분해하라. 코드가 숨을 쉬기 시작한다.
 - **Explicit Naming (명시적 네이밍)**:
-    - 핸들러 함수는 `handle[Action]` (예: `handleSearch`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다.
+    - 핸들러 함수는 `handle[Action]` (예: `handle[[Search]]`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다.
 - **조건부 렌더링 에티켓**:
    - `&&` 연산자 대신 삼항 연산자(`? :`)를 권장한다. 특히 `0 && <Component />` 시 화면에 숫자 0이 출력되는 대참사를 방지하기 위함이다.

@@ -1,6 +1,6 @@
 ---
 title: 리액트 훅(Hooks) 심층 분석 및 활용
-category: Software Architecture
+category: Software [[Architecture]]
 tags: [React, Hooks, useEffect, Custom Hooks]
 created: 2026-04-20
 ---
@@ -14,7 +14,7 @@ created: 2026-04-20
 - **useEffect의 올바른 관점**:
    - "마운트될 때 실행"이라는 라이프사이클 사고방식에서 벗어나라. `useEffect`는 **의존성 배열의 값과 컴포넌트 외부 시스템(API, DOM 등)을 동기화**하는 작업이다.
 - **Custom Hooks (추상화의 꽃)**:
-    - 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMyLogic` 처럼 따로 빼내어 컴포넌트는 오직 UI 선언에만 집중하게 만든다. 이것이 컴포넌트의 가독성을 폭발시키는 비결이다.
+    - 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMy[[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]]
+- Related: [[React_Performance_Optimization]] , [[React_[[State]]_[[Management]]_Strategy]]
 - Context: [[WebWorker_Performance]]
@@ -1,6 +1,6 @@
 ---
-title: 리액트 핵심 멘탈 모델 (UI as a Function of State)
-category: Software Architecture
+title: 리액트 핵심 멘탈 모델 (UI as a Function of [[State]])
+category: Software [[Architecture]]
 tags: [React, State, Mental Model, Immutability]
 created: 2026-04-20
 ---
@@ -14,12 +14,12 @@ 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 Diffing**:
    - 리액트는 실제 DOM을 직접 건드리기 전에 메모리상의 가상 DOM에서 이전 상태와 비교(Diffing)하여, 꼭 필요한 부분만 실제 화면에 반영(Commit)한다. 이것이 고성능 웹의 비결이다.

 ## ⚠️ 모순 및 업데이트 (RL Update)
- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어(Normalization) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다.
+- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어([[Normalization]]) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다.

 ## 🔗 지식 연결 (Graph)
 - Related: [[React_Hooks_Deep_Dive]] , [[Component_Design_Patterns]]
@@ -1,7 +1,7 @@
 ---
 title: 리액트 렌더링 최적화 전략
-category: Software Architecture
-tags: [Performance, Memoization, React.memo, Optimization]
+category: Software [[Architecture]]
+tags: [Performance, Memoization, React.memo, [[Optimization]]]
 created: 2026-04-20
 ---

@@ -17,7 +17,7 @@ created: 2026-04-20
    - **useCallback**: 함수 객체의 변동을 막아 자식 컴포넌트의 불필요한 리렌더링을 방지한다.
 - **Windowing (가상 리스트)**:
    - 수천 개의 리스트 아이템이 있어도 사용자의 눈에 보이는 수십 개만 실제 DOM에 렌더링한다. (예: `react-window`, `react-virtualized`).
- **상태의 위치 선정 (State Colocation)**:
+- **상태의 위치 선정 ([[State]] Colocation)**:
    - 전역 상태가 바뀔 때마다 앱 전체가 들썩이지 않게 하라. 상태는 그것을 사용하는 가장 하위 컴포넌트 근처로 내려라.

 ## ⚠️ 모순 및 업데이트 (RL Update)
@@ -1,7 +1,7 @@
 ---
-title: 전략적 상태 관리 가이드 (Global & Server State)
-category: Software Architecture
-tags: [State Management, React Query, SSOT, Architecture]
+title: 전략적 상태 관리 가이드 (Global & Server [[State]])
+category: Software [[Architecture]]
+tags: [State [[Management]], React Query, SSOT, Architecture]
 created: 2026-04-20
 ---

@@ -21,7 +21,7 @@ created: 2026-04-20
    - 다른 상태로부터 계산될 수 있는 값(예: `firstName`+`lastName` = `fullName`)은 절대 '상태'로 만들지 마라. 렌더링 시점에 계산하는 것이 정합성 유지의 핵심이다.

 ## ⚠️ 모순 및 업데이트 (RL Update)
- 무조건적인 전역 상태 지상주의는 'Prop Drilling'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.
+- 무조건적인 전역 상태 지상주의는 '[[Prop Drilling]]'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.

 ## 🔗 지식 연결 (Graph)
 - Related: [[Single_Source_of_Truth]] , [[API_Communication_Patterns]]
@@ -1,7 +1,7 @@
 ---
 title: 리액트 애플리케이션 테스트 전략
-category: Software Architecture
-tags: [Testing, Vitest, RTL, Unit Test, QA]
+category: Software [[Architecture]]
+tags: [[[Testing]], Vitest, RTL, Unit Test, QA]
 created: 2026-04-20
 ---

@@ -1,6 +1,6 @@
 ---
 title: 타입스크립트 기반의 안정적 개발 (Type Safety)
-category: Software Architecture
+category: Software [[Architecture]]
 tags: [TypeScript, Interface, Type Safety, Generic]
 created: 2026-04-20
 ---
@@ -10,9 +10,9 @@ created: 2026-04-20
 ## 🎯 개요 (Overview)
 실시간 상태 변화가 매우 빈번한 애플리케이션(예: 게임, 시뮬레이션)에서 UI 스레드와 복잡한 연산 로직을 분리하여 **프레임 드롭(Jank)**을 방지하는 아키텍처 설계 기법입니다.

-## 🚀 주요 원칙 (Key Principles)
+## 🚀 주요 원칙 (Key [[Principles]])
 - **스레드 분리 (Thread Isolation)**: 무거운 계산은 백그라운드 스레드(Web Worker)에서 수행하고, 메인 스레드는 렌더링에만 집중합니다.
- **메시징 기반 통신 (Messaging Architecture)**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다.
+- **메시징 기반 통신 (Messaging [[Architecture]])**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다.

 ## 💡 레슨 런 (Lesson Learned)
 > [!IMPORTANT]