diff --git a/10_Wiki/Topics/00_Raw/conversations/2026-04-30.md b/10_Wiki/Topics/00_Raw/conversations/2026-04-30.md index df4609b5..b9e09cfb 100644 --- a/10_Wiki/Topics/00_Raw/conversations/2026-04-30.md +++ b/10_Wiki/Topics/00_Raw/conversations/2026-04-30.md @@ -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가지 우선 작업을 정의합니다. **할당:** -- 🔍 **Researcher**: AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개월 내 진입 가능한 최적의 1개 닉슈와 핵심 타깃 키워드 5개를 정리해 보고하세요. -- 💰 **Business**: researcher의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안하고, 월별 조회수·구독자·변환율 목표를 포함한 KPI 프레임워크와 가격/수익 구조를 1페이지 분량으로 작성하세요. -- 📱 **Secretary**: 리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전트·진행 상태를 명시한 데일리 브리핑과 1주일 액션 플랜을 텔레그램 보고 형식으로 출력하세요. +- 🔍 **[[Research]]er**: AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개월 내 진입 가능한 최적의 1개 닉슈와 핵심 타깃 키워드 5개를 정리해 보고하세요. +- 💰 **[[business]]**: re[[Search]]er의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안하고, 월별 조회수·구독자·변환율 목표를 포함한 KPI 프레임워크와 가격/수익 구조를 1페이지 분량으로 작성하세요. +- 📱 **[[secretary]]**: 리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전트·진행 상태를 명시한 데일리 브리핑과 1주일 액션 플랜을 텔레그램 보고 형식으로 출력하세요. -## [16:33:10] 🔍 **Researcher** · _AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개_ +## [16:33:10] 🔍 **[[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]].md)·최근 의사결정·메모리를 검토해서 지금 가장 가치 있는 단일 작업 1개를 결정하고, 적절한 1~2명 에이전트에게 분배해서 실행하세요. 같은 산출물을 반복하지 마세요 — 메모리에 비슷한 항목이 24시간 내에 있으면 다른 각도로 진전시키세요. ## [16:38:10] 💰 **Business** · _researcher의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안_ diff --git a/10_Wiki/Topics/01_Frontend_Mastery/React_Clean_Code_Best_Practices.md b/10_Wiki/Topics/01_Frontend_Mastery/React_Clean_Code_Best_Practices.md index 713b506e..2cd8886b 100644 --- a/10_Wiki/Topics/01_Frontend_Mastery/React_Clean_Code_Best_Practices.md +++ b/10_Wiki/Topics/01_Frontend_Mastery/React_Clean_Code_Best_Practices.md @@ -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 && ` 시 화면에 숫자 0이 출력되는 대참사를 방지하기 위함이다. diff --git a/10_Wiki/Topics/01_Frontend_Mastery/React_Hooks_Deep_Dive.md b/10_Wiki/Topics/01_Frontend_Mastery/React_Hooks_Deep_Dive.md index cce5236e..866092d5 100644 --- a/10_Wiki/Topics/01_Frontend_Mastery/React_Hooks_Deep_Dive.md +++ b/10_Wiki/Topics/01_Frontend_Mastery/React_Hooks_Deep_Dive.md @@ -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]] diff --git a/10_Wiki/Topics/01_Frontend_Mastery/React_Mental_Model.md b/10_Wiki/Topics/01_Frontend_Mastery/React_Mental_Model.md index 02838468..255c6679 100644 --- a/10_Wiki/Topics/01_Frontend_Mastery/React_Mental_Model.md +++ b/10_Wiki/Topics/01_Frontend_Mastery/React_Mental_Model.md @@ -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]] diff --git a/10_Wiki/Topics/01_Frontend_Mastery/React_Performance_Optimization.md b/10_Wiki/Topics/01_Frontend_Mastery/React_Performance_Optimization.md index 6cc4a0b4..7205735f 100644 --- a/10_Wiki/Topics/01_Frontend_Mastery/React_Performance_Optimization.md +++ b/10_Wiki/Topics/01_Frontend_Mastery/React_Performance_Optimization.md @@ -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) diff --git a/10_Wiki/Topics/01_Frontend_Mastery/React_State_Management_Strategy.md b/10_Wiki/Topics/01_Frontend_Mastery/React_State_Management_Strategy.md index ce445ce1..5e2eb949 100644 --- a/10_Wiki/Topics/01_Frontend_Mastery/React_State_Management_Strategy.md +++ b/10_Wiki/Topics/01_Frontend_Mastery/React_State_Management_Strategy.md @@ -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]] diff --git a/10_Wiki/Topics/01_Frontend_Mastery/React_Testing_Strategy.md b/10_Wiki/Topics/01_Frontend_Mastery/React_Testing_Strategy.md index ca840dd3..82183622 100644 --- a/10_Wiki/Topics/01_Frontend_Mastery/React_Testing_Strategy.md +++ b/10_Wiki/Topics/01_Frontend_Mastery/React_Testing_Strategy.md @@ -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 --- diff --git a/10_Wiki/Topics/01_Frontend_Mastery/TypeScript_Type_Safety.md b/10_Wiki/Topics/01_Frontend_Mastery/TypeScript_Type_Safety.md index 6fc052aa..fd67b450 100644 --- a/10_Wiki/Topics/01_Frontend_Mastery/TypeScript_Type_Safety.md +++ b/10_Wiki/Topics/01_Frontend_Mastery/TypeScript_Type_Safety.md @@ -1,6 +1,6 @@ --- title: 타입스크립트 기반의 안정적 개발 (Type Safety) -category: Software Architecture +category: Software [[Architecture]] tags: [TypeScript, Interface, Type Safety, Generic] created: 2026-04-20 --- diff --git a/10_Wiki/Topics/01_Frontend_Mastery/WebWorker_Performance.md b/10_Wiki/Topics/01_Frontend_Mastery/WebWorker_Performance.md index 0dae6511..a697efc9 100644 --- a/10_Wiki/Topics/01_Frontend_Mastery/WebWorker_Performance.md +++ b/10_Wiki/Topics/01_Frontend_Mastery/WebWorker_Performance.md @@ -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] diff --git a/10_Wiki/Topics/02_Architecture_Principles/API_Communication_Patterns.md b/10_Wiki/Topics/02_Architecture_Principles/API_Communication_Patterns.md index 07b8125c..96b98154 100644 --- a/10_Wiki/Topics/02_Architecture_Principles/API_Communication_Patterns.md +++ b/10_Wiki/Topics/02_Architecture_Principles/API_Communication_Patterns.md @@ -1,6 +1,6 @@ --- title: 효율적인 API 통신 패턴 (Axios & Interceptors) -category: Software Architecture +category: Software [[Architecture]] tags: [API, Axios, Interceptor, Error Handling, Network] created: 2026-04-20 --- @@ -22,5 +22,5 @@ created: 2026-04-20 - 모든 통신에 Axios가 정답은 아니다. 브라우저 네이티브인 `fetch`로도 충분한 경우가 많으며, 라이브러리 의존성을 낮추는 것이 가벼운 앱을 만드는 첫걸음일 수 있다. ## 🔗 지식 연결 (Graph) -- Related: [[System_Protocol_Standard]] , [[React_State_Management_Strategy]] +- Related: [[System_Protocol_Standard]] , [[React_[[State]]_[[Management]]_Strategy]] - Foundation: [[Reliability_Safety_First]] diff --git a/10_Wiki/Topics/02_Architecture_Principles/Component_Design_Patterns.md b/10_Wiki/Topics/02_Architecture_Principles/Component_Design_Patterns.md index 800cc8bd..ad02b46e 100644 --- a/10_Wiki/Topics/02_Architecture_Principles/Component_Design_Patterns.md +++ b/10_Wiki/Topics/02_Architecture_Principles/Component_Design_Patterns.md @@ -1,7 +1,7 @@ --- title: 컴포넌트 설계 패턴 (Atomic & Composition) -category: Software Architecture -tags: [Design Pattern, Atomic Design, Composition, Architecture] +category: Software [[Architecture]] +tags: [Design Pattern, [[Atomic Design]], Composition, Architecture] created: 2026-04-20 --- @@ -12,9 +12,9 @@ created: 2026-04-20 ## 📖 구조화된 지식 (Synthesized Content) - **Container-Presenter 패턴**: - - **Container**: 데이터(State, API)를 가져오고 관리하는 '머리'. + - **Container**: 데이터([[State]], API)를 가져오고 관리하는 '머리'. - **Presenter**: 오직 Props만 받아 화면을 그리는 '몸통'. 스타일과 UI 구조에만 집중하여 테스트 가능성을 높인다. -- **Compound Components (복합 컴포넌트)**: +- **[[Compound Components]] (복합 컴포넌트)**: - `` 처럼 부모와 자식이 상태를 공유하며 하나의 긴밀한 기능을 수행하는 패턴. 사용자가 UI 구조를 자유롭게 배치할 수 있게 유연성을 제공한다. - **Atomic Design (원자 중심 설계)**: - Atom(버튼, 입력창) $\rightarrow$ Molecule(검색바) $\rightarrow$ Organism(헤더) $\rightarrow$ Template $\rightarrow$ Page. diff --git a/10_Wiki/Topics/02_Architecture_Principles/Separation_of_Concerns.md b/10_Wiki/Topics/02_Architecture_Principles/Separation_of_Concerns.md index e57cf8eb..de2734ef 100644 --- a/10_Wiki/Topics/02_Architecture_Principles/Separation_of_Concerns.md +++ b/10_Wiki/Topics/02_Architecture_Principles/Separation_of_Concerns.md @@ -1,6 +1,6 @@ --- -title: 시스템 아키텍처와 관심사 분리 (Separation of Concerns) -category: Software Architecture +title: 시스템 아키텍처와 관심사 분리 ([[Separation of Concerns]]) +category: Software [[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]] Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`) +2. **[[State]] Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`) 3. **View Layer**: 사용자 인터페이스 표현 및 렌더링 (예: React Components) ## 💡 레슨 런 (Lesson Learned) diff --git a/10_Wiki/Topics/02_Architecture_Principles/Single_Source_of_Truth.md b/10_Wiki/Topics/02_Architecture_Principles/Single_Source_of_Truth.md index d62c92be..1cfcef47 100644 --- a/10_Wiki/Topics/02_Architecture_Principles/Single_Source_of_Truth.md +++ b/10_Wiki/Topics/02_Architecture_Principles/Single_Source_of_Truth.md @@ -1,7 +1,7 @@ --- -title: 상태 관리의 단일 진실 공급원 (Single Source of Truth) -category: Software Architecture -tags: [State Management, Data Consistency, Redux, Architecture] +title: 상태 관리의 단일 진실 공급원 ([[Single Source of Truth]]) +category: Software [[Architecture]] +tags: [[[State]] [[Management]], Data Consistency, Redux, Architecture] created: 2026-04-20 --- @@ -10,7 +10,7 @@ created: 2026-04-20 ## 🎯 개요 (Overview) 시스템의 핵심 데이터를 중앙 집중식으로 관리하여, 데이터 불일치(Inconsistency) 현상을 원천 차단하고 예측 가능한 데이터 흐름을 확보하는 설계 원칙입니다. -## 🚀 주요 원칙 (Key Principles) +## 🚀 주요 원칙 (Key [[Principles]]) - **단일 지점 정의 (Defined at Single Point)**: 상태는 오직 한 곳에서만 정의되고 관리되어야 합니다. - **예측 가능성 (Predictability)**: 상태 변경은 정해진 규칙(Action/Setter)을 통해서만 발생하여 디버깅을 용이하게 합니다. diff --git a/10_Wiki/Topics/02_Architecture_Principles/Systemic_Simulation_Principles.md b/10_Wiki/Topics/02_Architecture_Principles/Systemic_Simulation_Principles.md index 3cf8eceb..894916cb 100644 --- a/10_Wiki/Topics/02_Architecture_Principles/Systemic_Simulation_Principles.md +++ b/10_Wiki/Topics/02_Architecture_Principles/Systemic_Simulation_Principles.md @@ -1,7 +1,7 @@ --- title: 시스템 시뮬레이션 설계 원리 -category: Systemic Modeling & Fun -tags: [Simulation, Physics Engine, Systemic Modeling, Ruleset] +category:[[ system]]ic Modeling & Fun +tags: [Simulation, [[Physics]] Engine, Systemic Modeling, Ruleset] created: 2026-04-20 --- diff --git a/10_Wiki/Topics/03_DevOps_Environment/Deployment_Final_Gate.md b/10_Wiki/Topics/03_DevOps_Environment/Deployment_Final_Gate.md index 7196cc46..f00857f0 100644 --- a/10_Wiki/Topics/03_DevOps_Environment/Deployment_Final_Gate.md +++ b/10_Wiki/Topics/03_DevOps_Environment/Deployment_Final_Gate.md @@ -1,7 +1,7 @@ --- title: 배포 프로토콜 및 CI/CD 자동화 -category: Software Architecture -tags: [Deployment, CI/CD, GitHub Actions, Vercel, DevOps] +category: Software [[Architecture]] +tags: [Deployment, CI/CD, [[GitHub Actions]], Vercel, DevOps] created: 2026-04-20 --- @@ -23,4 +23,4 @@ created: 2026-04-20 ## 🔗 지식 연결 (Graph) - Related: [[Modern_Environment_Ecosystem]] , [[Collaboration_Governance]] -- Pre-requisite: [[React_Testing_Strategy]] +- Pre-requisite: [[React_[[Testing]]_Strategy]] diff --git a/10_Wiki/Topics/03_DevOps_Environment/DevOps_Environment_Setup.md b/10_Wiki/Topics/03_DevOps_Environment/DevOps_Environment_Setup.md index c24517d5..425f2fcf 100644 --- a/10_Wiki/Topics/03_DevOps_Environment/DevOps_Environment_Setup.md +++ b/10_Wiki/Topics/03_DevOps_Environment/DevOps_Environment_Setup.md @@ -1,7 +1,7 @@ --- title: 개발 환경 및 실행 프로세스 관리 (DevOps & Setup) category: DevOps -tags: [DevOps, Environment, CI/CD, Process Management] +tags: [DevOps, Environment, CI/CD, Process [[Management]]] created: 2026-04-20 --- diff --git a/10_Wiki/Topics/03_DevOps_Environment/Git_Operation_Protocol.md b/10_Wiki/Topics/03_DevOps_Environment/Git_Operation_Protocol.md index 1389de3f..cc502623 100644 --- a/10_Wiki/Topics/03_DevOps_Environment/Git_Operation_Protocol.md +++ b/10_Wiki/Topics/03_DevOps_Environment/Git_Operation_Protocol.md @@ -1,4 +1,4 @@ -# 🛠️ Git Operation & Work Log Protocol (Git 작업 및 기록 지침) +# 🛠️ Git [[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]] 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-research-agent.git` | `origin` | +| **Agent** | `E:\Wiki\auto-[[Research]]-agent`| `https://github.com/wonseokjung/auto-re[[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]])되어 이동된다. - 위키화가 완료된 원본 로그는 삭제하여 지식 베이스의 정결성을 유지한다. ## 🚀 기대 효과 diff --git a/10_Wiki/Topics/03_DevOps_Environment/Modern_Environment_Ecosystem.md b/10_Wiki/Topics/03_DevOps_Environment/Modern_Environment_Ecosystem.md index ed392e47..9097a48b 100644 --- a/10_Wiki/Topics/03_DevOps_Environment/Modern_Environment_Ecosystem.md +++ b/10_Wiki/Topics/03_DevOps_Environment/Modern_Environment_Ecosystem.md @@ -1,7 +1,7 @@ --- title: 모던 개발 환경 및 프레임워크 생태계 -category: Software Architecture -tags: [Vite, Next.js, Ecosystem, Modern Stack] +category: Software [[Architecture]] +tags: [Vite, [[Next.js]], Ecosystem, Modern Stack] created: 2026-04-20 --- @@ -16,7 +16,7 @@ created: 2026-04-20 - **Framework: Next.js (The Fullstack Edge)**: - 단순히 SEO를 위한 SSR 도구가 아니다. API Routes를 통한 서버리스 함수 구현, 데이터 캐싱 전략(ISR/SSG) 등 현대 웹이 요구하는 거의 모든 기능을 탑재한 '거버넌스' 그 자체다. - **패키지 매니저의 선택**: - - `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포(Monorepo) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다. + - `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포([[Monorepo]]) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다. ## ⚠️ 모순 및 업데이트 (RL Update) - 최신 기술이 항상 정답은 아니다. 안정성이 최우선인 기업 환경에서는 검증된 `CRA` 혹은 `Webpack` 기반의 설정을 유지하는 것이 보수적인 면에서 유리할 수 있다. 기술 부채(Tech Debt)와 도입 비용을 항상 저울질하라. diff --git a/10_Wiki/Topics/03_DevOps_Environment/Tetris_Project_Retrospective.md b/10_Wiki/Topics/03_DevOps_Environment/Tetris_Project_Retrospective.md index 7fe8fa68..9c5b3312 100644 --- a/10_Wiki/Topics/03_DevOps_Environment/Tetris_Project_Retrospective.md +++ b/10_Wiki/Topics/03_DevOps_Environment/Tetris_Project_Retrospective.md @@ -1,21 +1,21 @@ --- title: 프로젝트 회고: 고성능 테트리스 아키텍처 category: Projects -tags: [Retrospective, Tetris, Architecture, Performance] +tags: [Retrospective, Tetris, [[Architecture]], Performance] created: 2026-04-20 --- -# 프로젝트 회고: 고성능 테트리스 아키텍처 (P-Reinforce) +# 프로젝트 회고: 고성능 테트리스 아키텍처 ([[P-Reinforce]]) ## 🌊 프로젝트 아키텍처 요약 본 프로젝트는 **Web Worker**를 활용한 완전한 연산-렌더링 분리를 실현하여, 실시간 게임 환경에서 극강의 부드러움을 확보하는 데 성공했습니다. ### 🧩 컴포넌트별 기술적 역할 - **Game Engine**: 물리 계산 및 상태 전이 (`public/gameWorker.js`). -- **State Manager**: UI의 유일한 진실 공급원 (`src/App.js`). +- **[[State]] Manager**: UI의 유일한 진실 공급원 (`src/App.js`). - **Renderer**: Props 기반의 순수 매핑 렌더러 (`src/components/GameBoard.jsx`). -## ⚠️ 핵심 교훈 (Lessons Learned) +## ⚠️ 핵심 교훈 ([[Lessons Learned]]) > [!IMPORTANT] > **"논리가 완벽해도 실행 환경이 무너지면 아무 의미가 없다."** > 아키텍처 설계만큼이나 '파일 무결성 검증'과 '환경 재설정 루틴'이 개발 생산성에 지대한 영향을 미친다는 것을 확인했습니다. diff --git a/10_Wiki/Topics/04_Governance_Reliability/Accessibility_Inclusivity.md b/10_Wiki/Topics/04_Governance_Reliability/Accessibility_Inclusivity.md index c6af0e18..f251ec77 100644 --- a/10_Wiki/Topics/04_Governance_Reliability/Accessibility_Inclusivity.md +++ b/10_Wiki/Topics/04_Governance_Reliability/Accessibility_Inclusivity.md @@ -1,7 +1,7 @@ --- title: 웹 접근성 및 포용적 설계 (a11y) -category: Software Architecture -tags: [Accessibility, a11y, Semantic HTML, Inclusivity] +category: Software [[Architecture]] +tags: [[[Accessibility]], a11y, Semantic HTML, Inclusivity] created: 2026-04-20 --- @@ -13,7 +13,7 @@ created: 2026-04-20 ## 📖 구조화된 지식 (Synthesized Content) - **Semantic HTML (의미론적 태그)**: - `
`로만 도배하지 마라. `
`, `
`, `
`, `