diff --git a/00_Raw/1535_Knowledge/00_Raw/2026-04-24/G1nation_Build_Fix_Report.md b/00_Raw/1535_Knowledge/00_Raw/2026-04-24/G1nation_Build_Fix_Report.md deleted file mode 100644 index 78fab8d1..00000000 --- a/00_Raw/1535_Knowledge/00_Raw/2026-04-24/G1nation_Build_Fix_Report.md +++ /dev/null @@ -1,33 +0,0 @@ -# [Report] G1nation Extension Encoding & Engine Rebuilding -**Date**: 2026-04-24 -**Author**: PD Kodari (AI) -**Status**: COMPLETED & PACKAGED (v2.2.15) - -## 1. 개요 (Overview) -ConnectAI에서 G1nation으로의 브랜딩 전환 이후 발생한 심각한 빌드 오류 및 런타임 불안정성을 해결하기 위한 긴급 수술을 집행함. 소스 코드 내 인코딩 오염과 코드 복제(Duplication)로 인해 `npm run compile`이 불가능한 상태였음. - -## 2. 주요 결함 (Critical Issues) -- **인코딩 지뢰 (Encoding Corruption)**: `extension.ts` 내 한글 주석 및 UI 문자열이 UTF-8 형식을 벗어나 깨지면서 따옴표(`'`) 인식을 방해함 -> `Unterminated string literal` 에러 발생. -- **좀비 코드 (Ghost Blocks)**: 함수 외부에 버려진 실행 코드와 닫는 중괄호(`}`)들이 산재하여 문법 파괴. -- **엔진 중복 (Engine Duplication)**: `_executeActions` 함수가 두 군데 이상 중복 정의되어 로직 충돌 및 용량 비대화 초래. -- **문법 오용**: `execSync`에 `.catch()`를 사용하는 등 동기/비동기 혼선 발견. - -## 3. 수술 과정 (Surgical Process) -총 20단계에 걸친 **PowerShell 레이저 수술(Line-by-line Patch)**을 통해 표준 `replace` 도구의 인코딩 한계를 극복함. - -- **v1~v10**: 설정 메뉴(`_handleSettingsMenu`) 및 브레인 메뉴(`_handleBrainMenu`)의 깨진 텍스트를 영문/표준 UTF-8로 전면 교체. -- **v11~v18**: 중복된 코드 블록들을 찾아내어 삭제하고, 흩어진 액션 핸들러들을 하나로 통합. -- **v19**: 메인 엔진(`_executeActions`)을 중복 없는 최신 구조로 리빌딩. -- **v20**: 함수 외부에 잔존하던 '유령 코드'와 깨진 문자열 최종 소거. - -## 4. 최종 결과 (Final Result) -- **빌드 성공**: `esbuild` 컴파일 정상 통과 (30ms 내외). -- **패키징 완료**: `g1nation-2.2.15.vsix` 생성 완료. -- **안정성 확보**: UI 텍스트 영문화 및 표준화를 통해 향후 인코딩 문제 재발 가능성 차단. - -## 5. 향후 과제 (Next Steps) -- **모듈화**: 2,500라인이 넘는 `extension.ts`를 `ActionHandlers.ts`, `UIProvider.ts` 등으로 분리하여 유지보수성 향상 필요. -- **i18n 도입**: 한글 UI 재도입 시 직접 하드코딩 대신 별도의 JSON 언어팩 사용 권장. - ---- -**PD 코다리의 한마디**: "조직이 시스템이다. 엔진이 깨끗해야 비행기가 뜬다!" 😎🐟 diff --git a/00_Raw/1535_Knowledge/00_Raw/Index.md b/00_Raw/1535_Knowledge/00_Raw/Index.md deleted file mode 100644 index 98b1545e..00000000 --- a/00_Raw/1535_Knowledge/00_Raw/Index.md +++ /dev/null @@ -1,5 +0,0 @@ -# Index: Topics > 00_Raw - -## 📁 Subcategories -- [[2026-04-20/Index|2026-04-20]] - diff --git a/00_Raw/1535_Knowledge/01_Frontend_Mastery/Index.md b/00_Raw/1535_Knowledge/01_Frontend_Mastery/Index.md deleted file mode 100644 index 48899ef1..00000000 --- a/00_Raw/1535_Knowledge/01_Frontend_Mastery/Index.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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]] diff --git a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Clean_Code_Best_Practices.md b/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Clean_Code_Best_Practices.md deleted file mode 100644 index 713b506e..00000000 --- a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Clean_Code_Best_Practices.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: 리액트 클린 코드 및 개발 에티켓 -category: Software Architecture -tags: [Clean Code, Etiquette, Best Practice, Readable Code] -created: 2026-04-20 ---- - -# [[React_Clean_Code_Best_Practices]] (리액트 클린 코드) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 가독성 좋은 코드는 '컴퓨터'가 이해하는 코드가 아니라, '나중에 이 코드를 고칠 동료(혹은 미래의 나)'가 숨 쉬듯 읽어내려갈 수 있는 코드다. - -## 📖 구조화된 지식 (Synthesized Content) -- **Early Return 패턴**: - - 중첩된 `if-else`는 지옥이다. 예외 상황(Loading, Error)을 먼저 `return`으로 쳐내면, 함수의 본체는 항상 가장 중요한 로직만 남게 된다. -- **Props Destructuring (구조 분해 할당)**: - - `props.user.name` 처럼 경로를 길게 쓰는 대신, 함수의 인자 단계에서 `{ user: { name } }` 처럼 분해하라. 코드가 숨을 쉬기 시작한다. -- **Explicit Naming (명시적 네이밍)**: - - 핸들러 함수는 `handle[Action]` (예: `handleSearch`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다. -- **조건부 렌더링 에티켓**: - - `&&` 연산자 대신 삼항 연산자(`? :`)를 권장한다. 특히 `0 && ` 시 화면에 숫자 0이 출력되는 대참사를 방지하기 위함이다. - -## ⚠️ 모순 및 업데이트 (RL Update) -- 과도한 추상화는 오히려 독이다. 코드가 3줄인데 함수 5개로 쪼개는 것은 가독성을 해친다. '직관성'이 '분리'보다 우선할 때가 있음을 명심하라. - -## 🔗 지식 연결 (Graph) -- Related: [[Collaboration_Governance]] , [[System_Debugging_Protocol]] -- Foundation: [[React_Mental_Model]] diff --git a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Hooks_Deep_Dive.md b/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Hooks_Deep_Dive.md deleted file mode 100644 index cce5236e..00000000 --- a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Hooks_Deep_Dive.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: 리액트 훅(Hooks) 심층 분석 및 활용 -category: Software Architecture -tags: [React, Hooks, useEffect, Custom Hooks] -created: 2026-04-20 ---- - -# [[React_Hooks_Deep_Dive]] (리액트 훅 심화) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 훅은 단순히 함수를 재사용하는 것이 아니라, 컴포넌트의 생애 주기와 논리를 '선언적'으로 결합하는 고도의 동기화 기제다. - -## 📖 구조화된 지식 (Synthesized Content) -- **useEffect의 올바른 관점**: - - "마운트될 때 실행"이라는 라이프사이클 사고방식에서 벗어나라. `useEffect`는 **의존성 배열의 값과 컴포넌트 외부 시스템(API, DOM 등)을 동기화**하는 작업이다. -- **Custom Hooks (추상화의 꽃)**: - - 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMyLogic` 처럼 따로 빼내어 컴포넌트는 오직 UI 선언에만 집중하게 만든다. 이것이 컴포넌트의 가독성을 폭발시키는 비결이다. -- **Rules of Hooks**: - - 반드시 함수의 최상위에서만 호출되어야 한다. 그래야 리액트가 훅의 상태를 유한 상태 머신처럼 정확한 순서로 관리할 수 있다. - -## ⚠️ 모순 및 업데이트 (RL Update) -- `useEffect` 내에서 무분별하게 상태를 업데이트하면 무한 루프나 성능 저하가 발생한다. 가능하면 `useMemo`나 `useCallback`으로 계산 결과를 캐싱하거나, 상태 업데이트 로직을 `useReducer`로 위임하라. - -## 🔗 지식 연결 (Graph) -- Related: [[React_Performance_Optimization]] , [[React_State_Management_Strategy]] -- Context: [[WebWorker_Performance]] diff --git a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Mental_Model.md b/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Mental_Model.md deleted file mode 100644 index 02838468..00000000 --- a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Mental_Model.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: 리액트 핵심 멘탈 모델 (UI as a Function of State) -category: Software Architecture -tags: [React, State, Mental Model, Immutability] -created: 2026-04-20 ---- - -# [[React_Mental_Model]] (리액트 멘탈 모델) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 리액트 개발은 DOM을 '조작(Manipulate)'하는 것이 아니라, 데이터의 흐름인 '상태(State)'를 정의하고 그 결과물을 화면에 '선언(Declare)'하는 과정이다. - -## 📖 구조화된 지식 (Synthesized Content) -- **UI = f(State)**: - - 화면은 상태의 결과값이어야 한다. 명령형(Imperative)으로 "이 버튼의 글자를 바꿔라"라고 하는 순간 리액트의 질서는 무너진다. 오직 상태를 바꾸고 리액트가 알아서 그리게 하라. -- **Immutability (불변성)**: - - 리액트는 객체의 주소값이 변할 때만 렌더링을 시도한다. `arr.push(1)`이 아니라 `setArr([...arr, 1])`처럼 **새로운 원본**을 복제하여 가상 DOM(Virtual DOM)이 효율적으로 동작하게 돕는다. -- **Virtual DOM Diffing**: - - 리액트는 실제 DOM을 직접 건드리기 전에 메모리상의 가상 DOM에서 이전 상태와 비교(Diffing)하여, 꼭 필요한 부분만 실제 화면에 반영(Commit)한다. 이것이 고성능 웹의 비결이다. - -## ⚠️ 모순 및 업데이트 (RL Update) -- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어(Normalization) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다. - -## 🔗 지식 연결 (Graph) -- Related: [[React_Hooks_Deep_Dive]] , [[Component_Design_Patterns]] -- Foundation: [[System_Protocol_Standard]] diff --git a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Performance_Optimization.md b/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Performance_Optimization.md deleted file mode 100644 index 6cc4a0b4..00000000 --- a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Performance_Optimization.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: 리액트 렌더링 최적화 전략 -category: Software Architecture -tags: [Performance, Memoization, React.memo, Optimization] -created: 2026-04-20 ---- - -# [[React_Performance_Optimization]] (리액트 성능 최적화) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 가장 빠른 렌더링은 '하지 않는 렌더링'이다. 필요 없는 업데이트를 차단하고 데이터가 흐를 때만 화면이 출렁이게 하라. - -## 📖 구조화된 지식 (Synthesized Content) -- **Memoization (메모이제이션)**: - - **React.memo**: 상위 컴포넌트가 변해도 내 Props가 같다면 그리기를 거부한다. - - **useMemo**: 비용이 큰 연산 결과(예: 복잡한 필터링)를 저장해두고 재사용한다. - - **useCallback**: 함수 객체의 변동을 막아 자식 컴포넌트의 불필요한 리렌더링을 방지한다. -- **Windowing (가상 리스트)**: - - 수천 개의 리스트 아이템이 있어도 사용자의 눈에 보이는 수십 개만 실제 DOM에 렌더링한다. (예: `react-window`, `react-virtualized`). -- **상태의 위치 선정 (State Colocation)**: - - 전역 상태가 바뀔 때마다 앱 전체가 들썩이지 않게 하라. 상태는 그것을 사용하는 가장 하위 컴포넌트 근처로 내려라. - -## ⚠️ 모순 및 업데이트 (RL Update) -- 모든 곳에 `memo`를 쓰는 것은 메모리 낭비다. 리액트의 기본 렌더링 성능은 이미 매우 뛰어나다. 병목 현상이 '실제로 관측'될 때만 최적화를 적용하는 것이 원칙이다. - -## 🔗 지식 연결 (Graph) -- Related: [[WebWorker_Performance]] , [[System_Debugging_Protocol]] -- Foundation: [[React_Mental_Model]] diff --git a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_State_Management_Strategy.md b/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_State_Management_Strategy.md deleted file mode 100644 index ce445ce1..00000000 --- a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_State_Management_Strategy.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: 전략적 상태 관리 가이드 (Global & Server State) -category: Software Architecture -tags: [State Management, React Query, SSOT, Architecture] -created: 2026-04-20 ---- - -# [[React_State_Management_Strategy]] (상태 관리 전략) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 상태는 '어디든' 있을 수 있지만, '아무데나' 있어서는 안 된다. 상태의 생명주기와 전파 범위에 따라 명확한 거주지를 결정하라. - -## 📖 구조화된 지식 (Synthesized Content) -- **상태의 3대 거주지**: - 1. **Local State (거주형)**: `useState`. 특정 컴포넌트 내부에서만 알고 있는 '사생활' (예: 드롭다운 열림 여부). - 2. **Global State (공용)**: `Zustand`, `Redux`. 온 동네가 알아야 하는 '공공 정보' (예: 로그인 유저, 다크모드). - 3. **Server State (빌려온 것)**: `React Query`. 서버에서 잠시 빌려와서 화면에 보여주는 '외부 데이터'. -- **Server State의 독립**: - - 과거엔 Redux에 서버 데이터를 담으려 했으나, 이제는 캐싱, 재시도, 로딩 관리를 전담하는 **React Query/SWR**로 분리하는 것이 세계적인 추세다. -- **상태의 최소화 원칙**: - - 다른 상태로부터 계산될 수 있는 값(예: `firstName`+`lastName` = `fullName`)은 절대 '상태'로 만들지 마라. 렌더링 시점에 계산하는 것이 정합성 유지의 핵심이다. - -## ⚠️ 모순 및 업데이트 (RL Update) -- 무조건적인 전역 상태 지상주의는 'Prop Drilling'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라. - -## 🔗 지식 연결 (Graph) -- Related: [[Single_Source_of_Truth]] , [[API_Communication_Patterns]] -- Foundation: [[React_Hooks_Deep_Dive]] diff --git a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Testing_Strategy.md b/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Testing_Strategy.md deleted file mode 100644 index ca840dd3..00000000 --- a/00_Raw/1535_Knowledge/01_Frontend_Mastery/React_Testing_Strategy.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: 리액트 애플리케이션 테스트 전략 -category: Software Architecture -tags: [Testing, Vitest, RTL, Unit Test, QA] -created: 2026-04-20 ---- - -# [[React_Testing_Strategy]] (리액트 테스트 전략) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 테스트는 '내가 짠 코드'를 검사하는 것이 아니라, '사용자가 경험할 가치'가 유지되고 있는지 수학적으로 증명하는 보험이다. - -## 📖 구조화된 지식 (Synthesized Content) -- **Unit Testing (단위 테스트)**: - - `Vitest` 사용. 순수 함수, 비즈니스 로직, 유틸리티 함수가 주어진 입력에 정확한 출력을 내는지 검증한다. -- **Integration Testing (통합 테스트)**: - - `React Testing Library (RTL)`의 철학: "사용자가 보듯 테스트하라." 버튼을 클릭했을 때 화면이 변하는지, 유저의 인터랙션을 시뮬레이션한다. -- **Mocking (모킹)**: - - 서버 API 호출(`msw`)이나 무거운 라이브러리를 가짜(Mock)로 대체하여 환경에 구애받지 않는 안정적인 테스트 환경을 구축한다. - -## ⚠️ 모순 및 업데이트 (RL Update) -- 테스트 커버리지 100% 집착은 생산성을 갉아먹는다. 비즈니스 핵심 로직과 사용자가 가장 많이 쓰는 '메인 시나리오'부터 견고하게 보호하는 지혜가 필요하다. - -## 🔗 지식 연결 (Graph) -- Related: [[System_Debugging_Protocol]] , [[Reliability_Safety_First]] -- Tool: [[Modern_Environment_Ecosystem]] diff --git a/00_Raw/1535_Knowledge/01_Frontend_Mastery/TypeScript_Type_Safety.md b/00_Raw/1535_Knowledge/01_Frontend_Mastery/TypeScript_Type_Safety.md deleted file mode 100644 index 6fc052aa..00000000 --- a/00_Raw/1535_Knowledge/01_Frontend_Mastery/TypeScript_Type_Safety.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: 타입스크립트 기반의 안정적 개발 (Type Safety) -category: Software Architecture -tags: [TypeScript, Interface, Type Safety, Generic] -created: 2026-04-20 ---- - -# [[TypeScript_Type_Safety]] (타입스크립트 정석) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 타입스크립트는 당신을 귀찮게 하는 '잔소리꾼'이 아니라, 런타임 에러라는 '낭떠러지' 앞에서 당신을 붙잡아주는 '생명줄'이다. - -## 📖 구조화된 지식 (Synthesized Content) -- **Non-Nullable & Narrowing**: - - 데이터가 `null`이거나 `undefined`일 수 있음을 코드 수준에서 강제로 인지시켜, 런타임에서 발생하는 'TypeError'를 90% 이상 사전 차단한다. -- **Generics (추상화의 끝판왕)**: - - 데이터의 구체적인 타입은 나중에 정하지만, 그 구조의 일관성은 유지하고 싶을 때 사용한다. 재사용 가능한 고기능 컴포넌트 제작의 필수 요건이다. -- **Interface & Alias**: - - 시스템 전체에 흐르는 데이터의 '형태(Shape)'를 정의하라. 타입 정의만 잘 되어 있어도 코드는 스스로를 설명하는 훌륭한 문서가 된다. - -## ⚠️ 모순 및 업데이트 (RL Update) -- `any`를 남발하는 순간 타입스크립트의 모든 이점은 사라진다. 차라리 `unknown`을 쓰고 타입을 좁히는(Narrowing) 방식을 택하라. 타입 정의에 너무 많은 시간을 뺏기는 '타입 헬(Type Hell)'을 경계하고 적절한 타협점을 찾아라. - -## 🔗 지식 연결 (Graph) -- Related: [[React_Clean_Code_Best_Practices]] , [[React_Hooks_Deep_Dive]] -- Foundation: [[System_Protocol_Standard]] diff --git a/00_Raw/1535_Knowledge/01_Frontend_Mastery/WebWorker_Performance.md b/00_Raw/1535_Knowledge/01_Frontend_Mastery/WebWorker_Performance.md deleted file mode 100644 index 0dae6511..00000000 --- a/00_Raw/1535_Knowledge/01_Frontend_Mastery/WebWorker_Performance.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: WebWorker를 이용한 고성능 아키텍처 설계 -category: Web & Performance -tags: [Web Worker, Concurrency, Performance, UI responsiveness] -created: 2026-04-20 ---- - -# WebWorker를 이용한 고성능 아키텍처 설계 - -## 🎯 개요 (Overview) -실시간 상태 변화가 매우 빈번한 애플리케이션(예: 게임, 시뮬레이션)에서 UI 스레드와 복잡한 연산 로직을 분리하여 **프레임 드롭(Jank)**을 방지하는 아키텍처 설계 기법입니다. - -## 🚀 주요 원칙 (Key Principles) -- **스레드 분리 (Thread Isolation)**: 무거운 계산은 백그라운드 스레드(Web Worker)에서 수행하고, 메인 스레드는 렌더링에만 집중합니다. -- **메시징 기반 통신 (Messaging Architecture)**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다. - -## 💡 레슨 런 (Lesson Learned) -> [!IMPORTANT] -> **"성능 병목 현상은 종종 '스레딩(Threading)'의 문제이다."** -> 복잡한 물리 계산이나 루프가 UI 응답성을 해치지 않도록, 연산 엔진을 완전히 별도의 스레드로 격리하는 것이 부드러운 UX의 핵심입니다. - -## 🔗 연결된 지식 -- [[Separation_of_Concerns]] -- [[Systemic_Simulation_Principles]] diff --git a/00_Raw/1535_Knowledge/02_Architecture_Principles/API_Communication_Patterns.md b/00_Raw/1535_Knowledge/02_Architecture_Principles/API_Communication_Patterns.md deleted file mode 100644 index 07b8125c..00000000 --- a/00_Raw/1535_Knowledge/02_Architecture_Principles/API_Communication_Patterns.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: 효율적인 API 통신 패턴 (Axios & Interceptors) -category: Software Architecture -tags: [API, Axios, Interceptor, Error Handling, Network] -created: 2026-04-20 ---- - -# [[API_Communication_Patterns]] (API 통신 패턴) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 서버와의 대화는 항상 '정중하되 의심하며' 처리하라. 모든 요청은 중앙 통제소(Interceptor)를 거치고 모든 에러는 시나리오가 준비되어 있어야 한다. - -## 📖 구조화된 지식 (Synthesized Content) -- **Service Layer (서비스 레이어) 추상화**: - - 컴포넌트 내에 `axios` 코드를 기생시키지 마라. `userService.js`, `productApi.js` 처럼 API별로 모듈화하여 컴포넌트는 오직 '함수 호출'만 알게 하라. -- **Axios Interceptors (심사 통로)**: - - 모든 요청에 인증 토큰을 자동으로 붙이거나, 백엔드에서 내려오는 401 에러를 가로채서 자동으로 토큰을 갱신(Silent Refresh)하는 로직을 중앙 집권화한다. -- **Error Scenario Planning**: - - 400(잘못된 요청), 403(권한 없음), 500(서버 죽음) 등 각 에러 코드별로 사용자가 경험할 UI 처리 방침을 미리 약속하라. - -## ⚠️ 모순 및 업데이트 (RL Update) -- 모든 통신에 Axios가 정답은 아니다. 브라우저 네이티브인 `fetch`로도 충분한 경우가 많으며, 라이브러리 의존성을 낮추는 것이 가벼운 앱을 만드는 첫걸음일 수 있다. - -## 🔗 지식 연결 (Graph) -- Related: [[System_Protocol_Standard]] , [[React_State_Management_Strategy]] -- Foundation: [[Reliability_Safety_First]] diff --git a/00_Raw/1535_Knowledge/02_Architecture_Principles/Component_Design_Patterns.md b/00_Raw/1535_Knowledge/02_Architecture_Principles/Component_Design_Patterns.md deleted file mode 100644 index 800cc8bd..00000000 --- a/00_Raw/1535_Knowledge/02_Architecture_Principles/Component_Design_Patterns.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: 컴포넌트 설계 패턴 (Atomic & Composition) -category: Software Architecture -tags: [Design Pattern, Atomic Design, Composition, Architecture] -created: 2026-04-20 ---- - -# [[Component_Design_Patterns]] (컴포넌트 설계 패턴) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 컴포넌트는 작을수록 강하고, 단순할수록 재사용성이 극대화된다. 복잡한 컴포넌트는 여러 개의 작고 순수한(Pure) 컴포넌트로 해체하라. - -## 📖 구조화된 지식 (Synthesized Content) -- **Container-Presenter 패턴**: - - **Container**: 데이터(State, API)를 가져오고 관리하는 '머리'. - - **Presenter**: 오직 Props만 받아 화면을 그리는 '몸통'. 스타일과 UI 구조에만 집중하여 테스트 가능성을 높인다. -- **Compound Components (복합 컴포넌트)**: - - `` 처럼 부모와 자식이 상태를 공유하며 하나의 긴밀한 기능을 수행하는 패턴. 사용자가 UI 구조를 자유롭게 배치할 수 있게 유연성을 제공한다. -- **Atomic Design (원자 중심 설계)**: - - Atom(버튼, 입력창) $\rightarrow$ Molecule(검색바) $\rightarrow$ Organism(헤더) $\rightarrow$ Template $\rightarrow$ Page. - - 가장 하위의 Atom이 프로젝트 전반에서 동일한 디자인 언어인 '디자인 토큰'을 반영하게 한다. - -## ⚠️ 모순 및 업데이트 (RL Update) -- 너무 과도한 컴포넌트 분할은 프로토타이핑 속도를 늦춘다. 처음에는 크게 짜고, 중복이 발생하거나 복잡도가 높아질 때 '사후적 리팩토링'을 통해 분리하는 것이 실무적으로 현명하다. - -## 🔗 지식 연결 (Graph) -- Related: Project_Architecture_Guidelines , [[Styling_Governance]] -- Design: [[Accessibility_Inclusivity]] diff --git a/00_Raw/1535_Knowledge/02_Architecture_Principles/Index.md b/00_Raw/1535_Knowledge/02_Architecture_Principles/Index.md deleted file mode 100644 index c70a47f2..00000000 --- a/00_Raw/1535_Knowledge/02_Architecture_Principles/Index.md +++ /dev/null @@ -1,8 +0,0 @@ -# Index: Topics > 02_Architecture_Principles - -## 📝 Documents -- [[API_Communication_Patterns]] -- [[Component_Design_Patterns]] -- [[Separation_of_Concerns]] -- [[Single_Source_of_Truth]] -- [[Systemic_Simulation_Principles]] diff --git a/00_Raw/1535_Knowledge/02_Architecture_Principles/Separation_of_Concerns.md b/00_Raw/1535_Knowledge/02_Architecture_Principles/Separation_of_Concerns.md deleted file mode 100644 index e57cf8eb..00000000 --- a/00_Raw/1535_Knowledge/02_Architecture_Principles/Separation_of_Concerns.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: 시스템 아키텍처와 관심사 분리 (Separation of Concerns) -category: Software Architecture -tags: [Architecture, SoC, Modular Design, Design Pattern] -created: 2026-04-20 ---- - -# 시스템 아키텍처와 관심사 분리 (SoC) - -## 🎯 개요 (Overview) -복잡한 소프트웨어 시스템을 역할별로 구분된 독립적인 모듈로 나누어, 유지보수성과 확장성을 극대화하는 설계 철학입니다. - -## 🚀 계층구조 예시 (Layering Example) -1. **Logic Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`) -2. **State Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`) -3. **View Layer**: 사용자 인터페이스 표현 및 렌더링 (예: React Components) - -## 💡 레슨 런 (Lesson Learned) -> [!IMPORTANT] -> **"코드의 경계가 명확할 때 시스템은 비로소 건강해진다."** -> 기능을 추가할 때 기존 코드를 수정하기보다 새로운 모듈을 덧붙일 수 있는 구조를 고민해야 합니다. - -## 🔗 연결된 지식 -- [[WebWorker_Performance]] -- [[Single_Source_of_Truth]] diff --git a/00_Raw/1535_Knowledge/02_Architecture_Principles/Single_Source_of_Truth.md b/00_Raw/1535_Knowledge/02_Architecture_Principles/Single_Source_of_Truth.md deleted file mode 100644 index d62c92be..00000000 --- a/00_Raw/1535_Knowledge/02_Architecture_Principles/Single_Source_of_Truth.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: 상태 관리의 단일 진실 공급원 (Single Source of Truth) -category: Software Architecture -tags: [State Management, Data Consistency, Redux, Architecture] -created: 2026-04-20 ---- - -# 상태 관리의 단일 진실 공급원 (Single Source of Truth) - -## 🎯 개요 (Overview) -시스템의 핵심 데이터를 중앙 집중식으로 관리하여, 데이터 불일치(Inconsistency) 현상을 원천 차단하고 예측 가능한 데이터 흐름을 확보하는 설계 원칙입니다. - -## 🚀 주요 원칙 (Key Principles) -- **단일 지점 정의 (Defined at Single Point)**: 상태는 오직 한 곳에서만 정의되고 관리되어야 합니다. -- **예측 가능성 (Predictability)**: 상태 변경은 정해진 규칙(Action/Setter)을 통해서만 발생하여 디버깅을 용이하게 합니다. - -## 💡 레슨 런 (Lesson Learned) -> [!TIP] -> **"상태는 오직 한 곳에서만 정의하고, 모든 로직은 그 상태를 읽고 쓰는 방식으로 동작해야 한다."** -> 코드의 파편화를 막기 위해 데이터의 책임 범위(Responsibility)를 명확히 하는 것이 대규모 프로젝트 성공의 열쇠입니다. - -## 🔗 연결된 지식 -- [[Separation_of_Concerns]] -- [[Domain-Driven Design (DDD)]] diff --git a/00_Raw/1535_Knowledge/02_Architecture_Principles/Systemic_Simulation_Principles.md b/00_Raw/1535_Knowledge/02_Architecture_Principles/Systemic_Simulation_Principles.md deleted file mode 100644 index 3cf8eceb..00000000 --- a/00_Raw/1535_Knowledge/02_Architecture_Principles/Systemic_Simulation_Principles.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: 시스템 시뮬레이션 설계 원리 -category: Systemic Modeling & Fun -tags: [Simulation, Physics Engine, Systemic Modeling, Ruleset] -created: 2026-04-20 ---- - -# 시스템 시뮬레이션 설계 원리 - -## 🎯 개요 (Overview) -현실 세계의 물리 법칙이나 비즈니스 규칙을 수학적으로 정의하고, 이를 절대적으로 우회할 수 없는 시스템 내의 법(Law)으로 구축하는 설계 기법입니다. - -## 🚀 핵심 메커니즘 (Mechanisms) -- **규칙 강제 (Ruleset Enforcement)**: 모든 상태 변화는 사전에 정의된 물리 엔진 함수(`checkCollision` 등)를 거쳐야만 합니다. -- **수학적 모델링**: 변화를 시각적 묘사가 아닌 데이터와 수식으로 먼저 증명합니다. - -## 💡 레슨 런 (Lesson Learned) -> [!TIP] -> **"모든 시뮬레이션은 수학적 규칙을 절대 우회할 수 없도록 강제해야 한다."** -> 이를 통해 단순한 게임을 넘어 자율주행, 물리 엔진 등 고도의 결정론적 시스템 모델링이 가능해집니다. - -## 🔗 연결된 지식 -- [[WebWorker_Performance]] -- [[Separation_of_Concerns]] diff --git a/00_Raw/1535_Knowledge/03_DevOps_Environment/Deployment_Final_Gate.md b/00_Raw/1535_Knowledge/03_DevOps_Environment/Deployment_Final_Gate.md deleted file mode 100644 index 7196cc46..00000000 --- a/00_Raw/1535_Knowledge/03_DevOps_Environment/Deployment_Final_Gate.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: 배포 프로토콜 및 CI/CD 자동화 -category: Software Architecture -tags: [Deployment, CI/CD, GitHub Actions, Vercel, DevOps] -created: 2026-04-20 ---- - -# [[Deployment_Final_Gate]] (배포 및 자동화) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 수동 배포는 '실버 불렛'이 아니라 '시한폭탄'이다. 인간의 손을 거치지 않는 자동화된 보급로만이 시스템의 영속성을 보장한다. - -## 📖 구조화된 지식 (Synthesized Content) -- **CI (Continuous Integration)**: - - 코드가 저장소에 합쳐지기 전, 린트(Lint) 검사, 빌드 테스트, 유닛 테스트를 자동으로 수행하여 '오염된 코드'의 유입을 원천 차단한다. -- **CD (Continuous Deployment)**: - - 검증된 코드를 실서버에 자동으로 릴리즈한다. `Vercel`, `Netlify` 같은 플랫폼은 브랜치별 '미리보기' 주소를 제공하여 배포 전 최종 검수를 돕는다. -- **Environment Variables (보안 환경)**: - - `.env` 파일을 통한 민감 정보 격리는 기본 중의 기본이다. 깃허브에 API Key가 하나라도 노출되는 순간, 그 프로젝트는 보안적으로 사망한 것과 다름없다. - -## ⚠️ 모순 및 업데이트 (RL Update) -- 무조건적인 '자동 배포'가 늘 정답은 아니다. 운영 단계에서는 '블루-그린 배포'나 '카나리 배포'처럼 트래픽을 조금씩 흘려보내며 안정성을 확인하는 고급 전략이 필요하다. - -## 🔗 지식 연결 (Graph) -- Related: [[Modern_Environment_Ecosystem]] , [[Collaboration_Governance]] -- Pre-requisite: [[React_Testing_Strategy]] diff --git a/00_Raw/1535_Knowledge/03_DevOps_Environment/DevOps_Environment_Setup.md b/00_Raw/1535_Knowledge/03_DevOps_Environment/DevOps_Environment_Setup.md deleted file mode 100644 index c24517d5..00000000 --- a/00_Raw/1535_Knowledge/03_DevOps_Environment/DevOps_Environment_Setup.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: 개발 환경 및 실행 프로세스 관리 (DevOps & Setup) -category: DevOps -tags: [DevOps, Environment, CI/CD, Process Management] -created: 2026-04-20 ---- - -# 개발 환경 및 실행 프로세스 관리 - -## 🎯 개요 (Overview) -코딩 완성도만큼이나 중요한 **실행 환경(Runtime Environment)**과 **설정 파일(Configuration)**의 무결성을 확보하여, '내 컴퓨터에선 되는데 왜 저기선 안 되지?'라는 문제를 해결하는 프로세스입니다. - -## 🚀 필수 체크리스트 (Checklist) -- **의존성 관리**: `npm install` 등 패키지 무결성 확인. -- **물리적 파일 구조**: `index.html` 등 필수 진입점 파일 존재 확인. -- **보안 및 권한**: OS 레벨의 실행 정책(`Execution Policy`) 및 권한 설정. - -## 💡 레슨 런 (Lesson Learned) -> [!NOTE] -> **"운영 환경에 대한 이해는 코딩 능력의 절반이다."** -> 논리적 로직의 완성뿐만 아니라, 그것이 실제로 구동되는 물리적 인프라 설정을 문서화하고 자동화하는 능력이 필수적입니다. - -## 🔗 연결된 지식 -- [[Systemic_Simulation_Principles]] diff --git a/00_Raw/1535_Knowledge/03_DevOps_Environment/Git_Operation_Protocol.md b/00_Raw/1535_Knowledge/03_DevOps_Environment/Git_Operation_Protocol.md deleted file mode 100644 index 1389de3f..00000000 --- a/00_Raw/1535_Knowledge/03_DevOps_Environment/Git_Operation_Protocol.md +++ /dev/null @@ -1,50 +0,0 @@ -# 🛠️ Git Operation & Work Log Protocol (Git 작업 및 기록 지침) - -> **카테고리**: 03_DevOps_Environment, Automation -> **상태**: 🟢 활성화 (Active) -> **최종 업데이트**: 2026-04-22 - ---- - -## 📌 개요 (Overview) -본 문서는 Skybound 프로젝트를 포함한 4개 주요 개발 거점의 원격 저장소 동기화 정합성을 유지하고, 모든 AI 작업 과정을 체계적으로 문서화하기 위한 Git 운영 규정 및 작업 로그(Work Log) 시스템을 정의한다. - -## 🔗 프로젝트별 Git 맵핑 (Repository Mapping) -대표님의 명령 한마디로 정확한 경로에서 작업을 수행하기 위해 각 폴더별로 독립적인 Git 설정을 유지한다. - -| 프로젝트 | 로컬 경로 | 원격 저장소 (Remote URL) | 리모트 명칭 | -| :--- | :--- | :--- | :--- | -| **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-research-agent.git` | `origin` | - -## 🛠️ 운영 지침 (Operational Guidelines) - -### 1. 동기화 프로토콜 (Full Sync) -- **주기**: 모든 작업 세션 시작 전 및 종료 후. -- **명령**: `git pull ` (일반적으로 main). -- **목적**: 로컬 작업 환경과 원격 저장소의 정합성 확보 및 충돌 방지. - -### 2. 작업 로그 시스템 (Work Log) -- **생성 경로**: `E:\Wiki\2nd\00_Raw` -- **파일명 규칙**: `YYYY-MM-DD_Task_Description.md` -- **필수 포함 항목**: - - **What**: 작업 내용 요약. - - **Why**: 작업의 의도 및 목적. - - **How**: 주요 코드 수정 내역 및 기술적 처리 과정. - - **Knowledge**: 사용된 지식 및 새롭게 습득한 패턴. - - **Result**: 최종 결과 및 관련 연결 지식. - -### 3. 위키화 (Wikification) -- `00_Raw`에 축적된 로그는 주기적으로 `10_Wiki\Topics` 하위 카테고리로 고도화(Refinement)되어 이동된다. -- 위키화가 완료된 원본 로그는 삭제하여 지식 베이스의 정결성을 유지한다. - -## 🚀 기대 효과 -1. **정확성**: 경로 혼선으로 인한 Git 작업 오류 0건 유지. -2. **지속성**: AI의 모든 작업 과정이 지식 자산(OPA)으로 축적되어 지식 베이스 강화. -3. **신뢰성**: 대표님의 명령에 따른 즉각적이고 투명한 히스토리 관리. - ---- -**승인인**: AI 개발부장 코다리 🫡 -**관련 문서**: GIT_PROTOCOL.md, WIKIFICATION_PROTOCOL.md diff --git a/00_Raw/1535_Knowledge/03_DevOps_Environment/Index.md b/00_Raw/1535_Knowledge/03_DevOps_Environment/Index.md deleted file mode 100644 index b88603c0..00000000 --- a/00_Raw/1535_Knowledge/03_DevOps_Environment/Index.md +++ /dev/null @@ -1,8 +0,0 @@ -# Index: Topics > 03_DevOps_Environment - -## 📝 Documents -- [[Deployment_Final_Gate]] -- [[DevOps_Environment_Setup]] -- [[Git_Operation_Protocol]] -- [[Modern_Environment_Ecosystem]] -- [[Tetris_Project_Retrospective]] diff --git a/00_Raw/1535_Knowledge/03_DevOps_Environment/Modern_Environment_Ecosystem.md b/00_Raw/1535_Knowledge/03_DevOps_Environment/Modern_Environment_Ecosystem.md deleted file mode 100644 index ed392e47..00000000 --- a/00_Raw/1535_Knowledge/03_DevOps_Environment/Modern_Environment_Ecosystem.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: 모던 개발 환경 및 프레임워크 생태계 -category: Software Architecture -tags: [Vite, Next.js, Ecosystem, Modern Stack] -created: 2026-04-20 ---- - -# [[Modern_Environment_Ecosystem]] (모던 개발 생태계) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 도구는 목적이 아니라 '생산성'을 위한 수단이다. 하지만 최신 생태계의 변화를 놓치는 것은 스스로 생산성을 깎아내는 것과 같다. - -## 📖 구조화된 지식 (Synthesized Content) -- **Build Tools: Vite vs Webpack**: - - `Vite`는 네이티브 ESM을 활용하여 개발 서버 구동 속도를 혁신적으로 줄였다. 프로젝트 규모가 커질수록 Vite의 HMR(Hot Module Replacement) 속도는 빛을 발한다. -- **Framework: Next.js (The Fullstack Edge)**: - - 단순히 SEO를 위한 SSR 도구가 아니다. API Routes를 통한 서버리스 함수 구현, 데이터 캐싱 전략(ISR/SSG) 등 현대 웹이 요구하는 거의 모든 기능을 탑재한 '거버넌스' 그 자체다. -- **패키지 매니저의 선택**: - - `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포(Monorepo) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다. - -## ⚠️ 모순 및 업데이트 (RL Update) -- 최신 기술이 항상 정답은 아니다. 안정성이 최우선인 기업 환경에서는 검증된 `CRA` 혹은 `Webpack` 기반의 설정을 유지하는 것이 보수적인 면에서 유리할 수 있다. 기술 부채(Tech Debt)와 도입 비용을 항상 저울질하라. - -## 🔗 지식 연결 (Graph) -- Related: [[Deployment_Final_Gate]] , Project_Architecture_Guidelines -- Foundation: [[TypeScript_Type_Safety]] diff --git a/00_Raw/1535_Knowledge/03_DevOps_Environment/Tetris_Project_Retrospective.md b/00_Raw/1535_Knowledge/03_DevOps_Environment/Tetris_Project_Retrospective.md deleted file mode 100644 index 7fe8fa68..00000000 --- a/00_Raw/1535_Knowledge/03_DevOps_Environment/Tetris_Project_Retrospective.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: 프로젝트 회고: 고성능 테트리스 아키텍처 -category: Projects -tags: [Retrospective, Tetris, Architecture, Performance] -created: 2026-04-20 ---- - -# 프로젝트 회고: 고성능 테트리스 아키텍처 (P-Reinforce) - -## 🌊 프로젝트 아키텍처 요약 -본 프로젝트는 **Web Worker**를 활용한 완전한 연산-렌더링 분리를 실현하여, 실시간 게임 환경에서 극강의 부드러움을 확보하는 데 성공했습니다. - -### 🧩 컴포넌트별 기술적 역할 -- **Game Engine**: 물리 계산 및 상태 전이 (`public/gameWorker.js`). -- **State Manager**: UI의 유일한 진실 공급원 (`src/App.js`). -- **Renderer**: Props 기반의 순수 매핑 렌더러 (`src/components/GameBoard.jsx`). - -## ⚠️ 핵심 교훈 (Lessons Learned) -> [!IMPORTANT] -> **"논리가 완벽해도 실행 환경이 무너지면 아무 의미가 없다."** -> 아키텍처 설계만큼이나 '파일 무결성 검증'과 '환경 재설정 루틴'이 개발 생산성에 지대한 영향을 미친다는 것을 확인했습니다. - -## 🏆 성과 -- [x] Web Worker 기반 비동기 엔진 구축 완료. -- [x] 표준 통신 프로토콜 기반의 Decoupling 성공. -- [x] 체계적인 디버깅 프로토콜 수립. - -## 🔗 연결된 지식 -- [[System_Debugging_Protocol]] -- Project_Architecture_Guidelines diff --git a/00_Raw/1535_Knowledge/04_Governance_Reliability/Accessibility_Inclusivity.md b/00_Raw/1535_Knowledge/04_Governance_Reliability/Accessibility_Inclusivity.md deleted file mode 100644 index c6af0e18..00000000 --- a/00_Raw/1535_Knowledge/04_Governance_Reliability/Accessibility_Inclusivity.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: 웹 접근성 및 포용적 설계 (a11y) -category: Software Architecture -tags: [Accessibility, a11y, Semantic HTML, Inclusivity] -created: 2026-04-20 ---- - -# [[Accessibility_Inclusivity]] (포용적 설계와 접근성) - -## 📌 한 줄 통찰 (The Karpathy Summary) -> 웹은 '모두'를 위한 공간이어야 한다. 신체적 제약이 시스템 이용의 제약이 되지 않게 하는 것은 '매너'가 아니라 전문 개발자의 '책임'이다. - -## 📖 구조화된 지식 (Synthesized Content) -- **Semantic HTML (의미론적 태그)**: - - `
`로만 도배하지 마라. `
`, `
`, `
`, `