chore: update graph view scale and set workspace default tab to graph view
This commit is contained in:
Antigravity Agent
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: AGENTS-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, ai-agents, [[Autonomous-Agents]], [[Reasoning]], planning]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# AI Agents Overview (AI 에이전트 개요)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "단순한 답변기가 아닌, 목표를 위해 도구를 쓰고 스스로 계획하는 '행동 주체'로 진화하라" — 거대 모델의 추론 능력을 바탕으로 목표를 설정하고, 실행 계획을 수립하며, 외부 도구(브라우저, 코드 에디터 등)를 사용해 태스크를 완수하는 인공지능 시스템.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 사용자의 추상적인 요청을 구체적인 작업 단위로 분해(Planning)하고, 각 단계를 실행(Action)하며, 결과를 관찰([[Observation]])하여 다음 행동을 결정하는 루프 기반의 자율성 패턴.
|
||||
- **핵심 루프 (ReAct 패턴 등):**
|
||||
- **Reasoning:** 현재 상황을 분석하고 무엇을 해야 할지 판단.
|
||||
- **Planning:** 목표 달성을 위한 단계별 워크플로우 생성.
|
||||
- **Tool Use:** API, 웹 검색, 파일 시스템 접근 등 외부 도구 활용.
|
||||
- **[[memory]]:** 대화의 맥락(단기)과 지식 베이스(장기)를 활용하여 일관성 유지.
|
||||
- **주요 사례:** AutoGPT, BabyAGI, 그리고 현재 작동 중인 Antigravity 에이전트.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 질문에 대한 텍스트 생성(Chat)에 머물던 AI가, 실제 환경에 변화를 일으키는 '실행자(Executor)'로 정체성이 변화함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 자율성을 극대화하되, 인간의 확인이 필요한 'Human-in-the-loop' 지점을 명확히 설정하여 안전성을 확보함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Agentic-Workflow, [[Multi-Agent-Systems-MAS]], [[RAG]], Theory-of-Mind-ToM-in-AI
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/AI Agents.md
|
||||
@@ -1,39 +0,0 @@
|
||||
# [[AI Reasoning & Retrieval Architectures (AI 추론 및 검색 아키텍처)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
AI 추론 및 검색 아키텍처는 거대 언어 모델(LLM)의 단순한 텍스트 생성을 넘어, 논리적 추론 능력을 극대화하고 외부 지식을 실시간으로 결합하여 정확도를 높이는 일련의 프레임워크와 기법을 의미한다. **[[Chain-of-Thought (CoT)]]**를 통한 사고의 단계화, **[[RAG (Retrieval-Augmented Generation)]]**를 통한 지식 증강, 그리고 **[[ReAct]]**, **[[Reflection]]**, **[[Self-verification]]**으로 이어지는 자율적 실행 루프가 그 핵심이다.
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. 추론 증폭 기법 (Reasoning Amplification)
|
||||
* **[[Chain-of-Thought (CoT) (사고 사슬)]]**: 문제를 단계별로 풀어나가는 중간 추론 과정을 명시적으로 생성하게 하여 복잡한 논리 문제의 정답률을 높이는 기법. 최근에는 모델 내부에서 잠재적으로 수행되는 'Internal CoT'로 진화하고 있다.
|
||||
* **[[ReAct (Reasoning and Acting)]]**: 추론(Reasoning)과 행동(Acting)을 결합하여, 모델이 스스로 계획을 세우고 외부 도구를 호출하며 그 결과를 다시 추론에 반영하는 방식.
|
||||
* **[[Reflection (자기 성찰)]]**: 생성된 결과물을 모델이 다시 검토하여 오류를 찾아내고 수정하는 과정. "자신이 짠 코드가 원래 요청과 일치하는가?"를 묻는 비판적 사고를 강제한다.
|
||||
|
||||
### 2. 지식 증강 및 오케스트레이션 (Knowledge & Orchestration)
|
||||
* **[[RAG (Retrieval-Augmented Generation) (검색 증강 생성)]]**: 실시간으로 관련 문서를 검색하여 컨텍스트에 주입함으로써 할루시네이션을 방지하고 최신성을 확보하는 기술.
|
||||
* **[[LangGraph]] 및 그래프 기반 오케스트레이션**: 에이전트의 행동을 노드(Node)와 에지(Edge)로 정의하고, 상태(State)와 조건부 라우팅을 명시적으로 제어하는 프레임워크. 장기 실행(Long-horizon) 작업과 복잡한 워크플로우 제어에 최적화되어 있다.
|
||||
* **[[Self-verification (자가 검증)]]**: 에이전트가 작업을 마친 후 테스트 스위트 실행이나 Puppeteer 기반의 브라우저 테스팅을 통해 결과의 논리적 무결성을 스스로 입증하는 과정.
|
||||
|
||||
### 3. 하네스 수준의 제어 메커니즘
|
||||
* **PIV 루프 (Plan-Implement-Validate)**: 에이전트 실행의 표준 파이프라인.
|
||||
* **미들웨어 개입 (Hooks)**: 에이전트가 종료되기 전 이를 가로채어 검증 패스를 강제하거나(PreCompletionChecklistMiddleware), 무한 루프를 탐지하여 전략 수정을 유도하는 제어 계층.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **컴퓨팅 리소스와 성능의 균형**: CoT나 Reflection 단계가 추가될수록 정답률은 높아지지만 토큰 소비량과 응답 지연 시간(Latency)이 급격히 증가한다.
|
||||
* **파멸의 루프 (Doom Loops)**: 에이전트가 잘못된 계획에 집착하여 동일한 오류를 반복하는 현상. 이를 방지하기 위한 루프 감지 및 컨텍스트 재주입 로직이 필수적이다.
|
||||
* **데이터 품질 종속성**: 오케스트레이션이 완벽하더라도 주입되는 소스 데이터가 오염(Data Drift)되어 있으면 에이전트는 정교하게 틀린 답을 도출하게 된다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Agent Harness (에이전트 하네스)]]**: 이러한 추론 아키텍처가 실제로 구동되는 실행 런타임이자 거버넌스 계층.
|
||||
* **[[Context Engineering (컨텍스트 엔지니어링)]]**: 제한된 토큰 내에서 최적의 추론을 이끌어내기 위한 데이터 압축 및 주입 기술.
|
||||
* **[[Model Context Protocol (MCP)]]**: 에이전트가 외부 도구와 통신하기 위한 표준 인터페이스.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 모델 내부에서만 수행되는 '잠재적 CoT'와 명시적인 '텍스트 기반 CoT' 중 어떤 것이 장기적인 정렬(Alignment)과 관측 가능성 면에서 유리한가?
|
||||
* 무한 루프를 감지했을 때 모델의 추론 온도를 조절하거나 완전히 다른 경로로 라우팅하는 자율적 복구 메커니즘의 최적 설계는?
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -1,38 +0,0 @@
|
||||
# [[Agent Context & Memory Management (에이전트 컨텍스트 및 메모리 관리)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
에이전트 컨텍스트 및 메모리 관리는 상태 비저장(Stateless) 구조인 LLM이 장기적인 작업 목표를 잃지 않고, 수천 단계의 복잡한 추론 과정을 지속할 수 있게 돕는 핵심 기술이다. 이는 유한한 **[[Context Window (컨텍스트 윈도우)]]** 내에서 최적의 정보를 유지하는 **[[Context Engineering]]**과, 세션 종료 후에도 상태를 보존하는 **[[State Persistence]]** 전략으로 구성된다.
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. 컨텍스트 라이프사이클 관리
|
||||
* **[[Context Engineering (컨텍스트 엔지니어링)]]**: 제한된 토큰 예산 내에서 에이전트에게 가장 필요한 데이터(파일 스냅샷, 도구 로그, 지침)를 동적으로 선택하고 주입하는 기술.
|
||||
* **[[Context Compaction (컨텍스트 압축)]]**: 누적된 대화 이력과 도구 출력값을 요약하거나 핵심 정보만 추출하여 토큰 소모를 줄이고 모델의 인지 부하를 완화하는 과정.
|
||||
* **[[Context Rot (컨텍스트 퇴화)]]**: 윈도우가 가득 차면서 중요한 초기 지시사항이나 제약 조건을 망각하는 현상. 이를 방지하기 위해 시스템 프롬프트의 고정(Pinning)과 주기적 재주입이 필요하다.
|
||||
|
||||
### 2. 메모리 아키텍처 (Short-term & Long-term)
|
||||
* **단기 기억 (Working Memory)**: 현재 세션의 컨텍스트 윈도우 내에 존재하는 정보. 즉각적인 추론과 행동의 근거가 된다.
|
||||
* **장기 기억 (Persistent Memory)**: 파일 시스템(`MEMORY.md`, `LOG.md`)이나 벡터 데이터베이스에 저장된 영구 기록. 세션이 재시작되어도 에이전트가 이전 진행 상황을 복구할 수 있게 한다.
|
||||
* **[[State Persistence (상태 지속성)]]**: 에이전트의 현재 작업 단계, 변수, 계획을 구조화된 데이터(JSON/Markdown)로 저장하여 장애 발생 시에도 체크포인트에서 재개할 수 있는 능력.
|
||||
|
||||
### 3. 초기화-실행자 분리 (Initializer-Executor Split)
|
||||
* 복잡한 프로젝트 수행 시, 초기화 에이전트가 환경과 계획을 수립하고 실행자 에이전트가 이를 넘겨받아 수행하는 아키텍처. 에이전트 간의 '지식 핸드오버(Knowledge Handoff)'를 통해 대규모 작업을 완수한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **압축 vs 출처 유실**: 컨텍스트를 요약하면 효율성은 높아지지만, 정보의 원래 출처(Data Lineage)와 세부 맥락이 유실될 위험이 있다.
|
||||
* **좀비 메모리 (Zombie Memory)**: 낡고 잘못된 정보가 메모리에 남아 에이전트의 판단을 흐리게 하는 현상. 정기적인 메모리 무효화(Invalidation) 정책이 필수적이다.
|
||||
* **비용과 지연 시간**: 메모리 시스템이 복잡해질수록(벡터 검색, 자동 요약 등) API 비용과 추론 지연 시간이 증가한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Agent Harness (에이전트 하네스)]]**: 메모리와 컨텍스트를 물리적으로 관리하고 모델에 주입하는 런타임 제어 계층.
|
||||
* **[[RAG (Retrieval-Augmented Generation)]]**: 방대한 장기 기억 중 필요한 부분만 검색하여 단기 기억으로 불러오는 기술.
|
||||
* **[[Filesystem]]**: 에이전트가 상태를 영구 기록하고 세션 간 공유 원장으로 사용하는 가장 근본적인 저장소.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 상태 지속성을 위해 요약(Compaction)을 수행할 때, 데이터의 무결성과 계보(Lineage)를 완벽하게 유지하는 알고리즘은 무엇인가?
|
||||
* 다중 에이전트 환경에서 공유 상태(Shared State)의 충돌(Race Condition)을 방지하기 위한 하네스 수준의 락(Lock) 메커니즘 설계 방안은?
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AI-[[Game-Theory]]
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.99
|
||||
tags: [Algorithmic Game Theory, Mechanism Design, Nash Equilibrium, AI]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Algorithmic-Game-Theory]] (알고리즘 게임 이론)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "이기적인 경제 주체들을 위한 최적의 규칙." 게임 이론의 복잡한 균형점(Nash Equilibrium)을 컴퓨터 알고리즘으로 어떻게 빠르게 찾아낼 것인가를 다루는 학문이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Computational Complexity of Equilibria**:
|
||||
- 나쉬 균형을 찾는 것이 얼마나 어려운지(PPAD-complete) 분석하고, 이를 근사적으로 해결하는 알고리즘을 개발한다.
|
||||
- **Mechanism Design**:
|
||||
- 참여자들이 자신의 리소스를 솔직하게 공개하는 것이 스스로에게도 이득이 되도록 시스템(경매, 매칭 등)을 설계한다.
|
||||
- **Price of Anarchy**:
|
||||
- 개별 주체의 이기적 행동으로 인해 사회 전체의 효율성이 얼마나 감소하는지 정량화한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 전통적인 게임 이론은 주체들이 '완전하게 합리적'이라고 가정하지만, 현실의 AI나 인간은 '제한적 합리성'을 가진다. 따라서 최근에는 강화학습을 통해 실시간으로 변하는 전략 공간에 대응하는 연구가 주류다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Nash-Equilibrium , Mechanism-Design
|
||||
- Foundation: [[Bounded-Rationality]]
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: BEH-ECON-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [economics, [[Psychology]], decision-making, [[Behavior]]al-science, nudge]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Behavioral Economics]] (행동 경제학)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "인간은 합리적이지 않지만, 그 비합리성에는 일관된 패턴이 있다" — 심리학적 통찰을 경제학에 결합하여 인간이 실제로 어떻게 판단하고 선택하는지, 그리고 왜 종종 자신의 이익에 반하는 결정을 내리는지 탐구하는 학문.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 인지적 한계와 감정적 요인으로 인해 발생하는 체계적인 판단 오류(Biases)를 식별하고, 이를 바탕으로 선택 설계(Choice [[Architecture]])를 최적화하는 분석 패턴.
|
||||
- **주요 개념:**
|
||||
- **Prospect Theory:** 이득보다 손실에 더 민감하게 반응하는 '손실 회피(Loss Aversion)' 성향 설명 (카너먼 & 트버스키).
|
||||
- **Anchoring:** 처음 제시된 정보(닻)에 얽매여 이후의 판단이 왜곡되는 현상.
|
||||
- **Nudge:** 강제하지 않고도 선택의 설계를 바꾸어 사람들의 행동을 긍정적인 방향으로 유도하는 기법 (리처드 탈러).
|
||||
- **Hyperbolic Discounting:** 먼 미래의 큰 보상보다 당장 눈앞의 작은 보상을 지나치게 선호하는 경향.
|
||||
- **의의:** 마케팅, 정책 수립, 게임 디자인, 그리고 사용자 친화적 AI 인터페이스 설계에 핵심적 역할 수행.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 수학적 수식으로 완벽히 설명 가능하다고 믿었던 고전 경제학의 한계를 극복하고, 인간의 불완전성을 시스템 설계의 핵심 변수로 도입.
|
||||
- **정책 변화:** Skybound 프로젝트의 BM([[business]] Model) 설계 시, 플레이어가 심리적 거부감 없이 성취감을 느낄 수 있도록 행동 경제학적 '넛지' 설계를 적용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Game-Theory]], [[Psychology-of-Learning]], Decision-Making, UX-Design
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Behavioral-Economics.md
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AI-COT
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.99
|
||||
tags: [LLM, Chain-of-Thought, CoT, Inference, [[Search]]]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# Chain-of-Thought (사고의 사슬 CoT)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 거대 언어 모델에게 "생각해 봐"라고 한마디 하는 것만으로도, 문제를 단계적으로 분해하여 정답 도출 가능성을 비약적으로 높이는 추론의 기적이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Step-by-Step [[Reasoning]]**:
|
||||
- 질문에 바로 답하지 않고, 중간 과정(Rationales)을 텍스트로 먼저 생성하게 유도함으로써 모델이 자신의 이전 출력을 다음 추론의 근거로 활용하게 하는 기법.
|
||||
- **Zero-shot CoT**:
|
||||
- 프롬프트 끝에 "Let's think step by step"이라는 문구만 추가해도 상식 추론과 수학 문제 해결 능력이 폭발적으로 증가한다.
|
||||
- **Self-Consistency**:
|
||||
- 여러 개의 CoT 경로를 생성하게 하여 가장 공통적으로 도출된 결론을 정답으로 선택하는 기법.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- CoT는 항상 유리하지 않다. 단순 사실 확인 문제에서는 오히려 불필요한 텍스트 생성으로 인해 에러(Hallucination)가 발생할 확률이 있다. 최근에는 이를 고도화한 `Tree-of-Thoughts (ToT)` 또는 `OpenAI o1`처럼 내부적으로 강화학습을 통해 최적의 사고 경로를 찾는 모델로 진화 중이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Best-of-N-Sampling]] , [[Automated-Reasoning]]
|
||||
- Foundation: [[Information Theory]]
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-CCOT-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, chain-of-thought, cot, [[Prompt-Engineering]], llm, [[Reasoning]]]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Chain-of-Thought (CoT 사고 사슬)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "생각의 과정을 말하게 하라: AI에게 정답만 툭 던지라고 하지 않고, 문제를 단계별로 풀어나가는 중간 추론 과정을 텍스트로 적게 함으로써 복잡한 논리 문제의 정답률을 드라마틱하게 끌어올리는 인지적 증폭 장치."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
사고 사슬(Chain-of-Thought, CoT)은 거대 언어 모델(LLM)의 추론 능력을 극대화하기 위해 '단계별 생각(Step-by-step reasoning)'을 유도하는 기법입니다.
|
||||
|
||||
1. **핵심 메커니즘**:
|
||||
* **Zero-shot CoT**: 프롬프트 끝에 "차근차근 생각해보자(Let's think step by step)"라는 마법의 구를 추가하는 것만으로 추론 성능이 비약적으로 상승.
|
||||
* **Few-shot CoT**: 문제 풀이 과정을 보여주는 예시를 몇 개 제공하여 모델이 그 추론 흐름을 모방하게 함.
|
||||
2. **왜 효과적인가?**:
|
||||
* 모델이 다음 토큰을 예측할 때, 앞서 적은 자신의 추론 과정이 '작업 기억(Working [[memory]])' 역할을 수행하여 최종 정답 도출의 확률적 정확도를 높임.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 초기 모델 정책은 단순히 데이터 학습량만 늘리는 정책(Scaling Law)에 집중했으나, 현대 정책은 모델의 내부 연산 비중만큼이나 '출력되는 추론 과정의 양과 질 정책'이 지능 발현의 핵심임을 인정함(RL Update).
|
||||
- **정책 변화(RL Update)**: 사용자가 추론 과정을 보는 정책(Open CoT)을 넘어, 모델 내부에서만 추론을 수행하고 결과만 내놓는 '잠재적 CoT 정책'이 OpenAI의 o1 모델 등을 통해 구현되어 성능과 사용성을 모두 잡는 방향으로 진화함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Reasoning]], [[Prompt-Engineering]], [[Automated-Reasoning]], [[Search-Optimization]], [[Knowledge-Representation-in-AI]]
|
||||
- **Modern Tech/Tools**: OpenAI o1 (Strawberry), Chain of Thought [[prompt]]ing, Self-consistency decoding.
|
||||
---
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-8EC3C3
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Code Review"
|
||||
---
|
||||
|
||||
# [[Code Review]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 코드 리뷰(Code Review)는 소프트웨어의 전반적인 코드 건강 상태를 개선하고 품질 및 보안을 보장하기 위해 소스 코드를 검사하는 과정입니다 [1-3]. 이는 인간 개발자가 직접 수행하는 수동 리뷰(Manual Code Review)와 정적 분석([[SAST]]) 및 AI 도구를 활용하는 자동화된 리뷰(Automated Code Review)로 나뉩니다 [4, 5]. 최신 소프트웨어 개발 환경에서는 자동화 도구의 속도와 인간의 문맥 이해 능력을 결합하여 일관성과 보안성을 극대화하는 하이브리드 접근법이 필수적인 모범 사례로 권장됩니다 [5-8].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **수동 코드 리뷰 (Manual Code Review):**
|
||||
개발자가 주로 풀 리퀘스트(PR)를 통해 코드를 한 줄씩 읽고 논의하는 인간 주도의 검사 방식입니다 [4, 9]. 도구가 파악할 수 없는 아키텍처의 의도, 비즈니스 로직, 복잡한 설계 결함을 찾아내는 데 탁월하며, 팀원 간의 지식 공유와 멘토링을 촉진하여 코드 가독성을 높입니다 [5, 6, 10, 11]. 구글의 코드 리뷰 표준에 따르면, 완벽한 코드를 추구하기보다는 시스템의 전반적인 코드 상태가 확실히 개선되는 방향(지속적 개선)을 기준으로 승인을 진행해야 합니다 [12, 13]. 하지만 수동 리뷰는 시간이 많이 소요되고 비용이 높으며, 리뷰어의 피로도나 편향에 의한 인적 오류가 발생할 수 있다는 단점이 있습니다 [14, 15].
|
||||
|
||||
* **자동화된 코드 리뷰 (Automated Code Review):**
|
||||
린터(Linter), 포매터(Formatter), SAST, AI 기반 리뷰 봇 등의 도구를 사용하여 코드를 실행하지 않고 정적으로 분석하는 방식입니다 [4, 16]. [[ESLint]], [[Prettier]], [[SonarQube]], Snyk 등의 도구를 통해 구문 오류, 스타일 위반, 일반적인 보안 취약점(예: SQL 인젝션, XSS 등)을 대규모 코드베이스에서 빠르고 일관되게 찾아냅니다 [17-20]. 하지만 비즈니스 로직과 설계의 복잡한 의도를 이해하지 못하는 문맥의 맹점(Context Blindness)이 존재하며, 설정된 규칙에만 의존하기 때문에 잦은 오탐(False Positive)을 발생시켜 개발자의 피로도를 높일 수 있다는 한계가 있습니다 [21, 22].
|
||||
|
||||
* **하이브리드 리뷰 워크플로우 (Hybrid Approach):**
|
||||
2025년 기준 가장 이상적인 방식은 자동화와 인간의 통찰력을 계층화하여 결합하는 것입니다 [5, 23]. CI/CD 파이프라인이나 Git 훅(예: [[Husky]], [[lint-staged]])을 통해 기본 구문 검사와 정형화된 보안 결함, 스타일 교정은 자동화 도구가 코드 커밋 및 PR 단계에서 우선적으로 차단합니다 [24, 25]. 이후 인간 리뷰어는 도구가 정리한 코드를 바탕으로 아키텍처 설계, 보안 문맥, 서비스 간의 교차 영향도와 같은 고차원적인 판단에만 집중할 수 있습니다 [23, 25, 26].
|
||||
|
||||
* **AI 기반 코드 리뷰 도구의 진화:**
|
||||
최근에는 GitHub Copilot, Snyk Code, DeepCode 등 대규모 언어 모델(LLM)과 머신러닝 기반의 분석 도구들이 코드 리뷰에 적극 도입되고 있습니다 [27-29]. AI는 코드의 문맥을 어느 정도 해석하고, 데이터 흐름을 추적하여 오탐률을 줄이며, 리뷰 과정에서 자동으로 코드를 수정해 주는 제안(Auto-fix)을 통해 리뷰 주기를 크게 단축시킵니다 [28, 30, 31].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** Manual Code Review, Automated Code Review, [[SAST]], Linting, [[Prettier]], [[Husky]]
|
||||
- **Projects/Contexts:** CI/CD Pipelines, SDLC, Pull Request
|
||||
- **Contradictions/Notes:** 소스에 따르면 자동화된 리뷰 도구는 코드 검사 속도와 일관성을 극대화하지만, 비즈니스 로직과 아키텍처적 맥락을 이해하지 못해 실제 취약점의 약 22%를 놓치거나 오탐(False Positive)을 대량으로 양산할 수 있습니다 [22, 32]. 따라서 자동화 도구 단독으로는 완벽한 보안과 품질을 보장할 수 없으며, 복잡하고 위험도가 높은 코드는 반드시 인간 리뷰어의 수동 평가가 동반되어야 한다고 강조합니다 [5, 26, 33].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-SCI-COG-PSY
|
||||
category: "10_Wiki/💡 Topics/Science"
|
||||
confidence_score: 0.99
|
||||
tags: [Cognitive [[Psychology]], Perception, [[memory]], Attention]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# Cognitive-Psychology (인지 심리학)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "마음은 정보 처리 시스템이다." 인간의 사고 과정을 컴퓨터의 아키텍처처럼 입력(지각)-저장(기억)-처리(생각)-출력(행동)의 관점에서 분석하는 학문이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Mental Representations**:
|
||||
- 외부 세계를 뇌가 어떻게 내부 모델로 변환하여 저장하는가. (예: 스키마([[Schema]]), 프레임(Frame)).
|
||||
- **Dual Process Theory**:
|
||||
- 시스템 1(빠른 직관)과 시스템 2(느린 추론)가 어떻게 상호작용하며 결정을 내리는지 분석한다.
|
||||
- **Working Memory Theory**:
|
||||
- 정보가 장기 기억으로 넘어가기 전, 머릿속에서 유지되고 처리되는 '메모리 공간'의 용량 제한(7±2 등)에 대한 연구.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 인지 심리학의 고전적 모델들은 '감정'을 배제한 경향이 있었다. 현대에는 인지적 처리와 감정적 처리가 뗄 수 없다는 '정서 지능(Emotional Intelligence)'과의 융합 연구가 대세다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Cognitive-Biases , [[Cognitive-Therapy-in-CBT]]
|
||||
- Foundation: [[Information Theory]]
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
id: DIFFUSION-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, generative-model, diffusion-model, image-generation, [[Deep-Learning]]]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Diffusion Models (확산 모델)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "혼돈([[Noise]]) 속에서 질서를 찾아내어 무(無)에서 유(有)를 창조하라" — 데이터에 노이즈를 점진적으로 추가했다가 이를 다시 제거하는 역과정(Denoising)을 학습하여, 단순한 노이즈로부터 고품질의 이미지나 데이터를 생성하는 최신 생성 모델.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 정규 분포를 따르는 무작위 노이즈에서 시작하여, 모델이 학습한 데이터의 분포를 따라 미세한 패턴을 복원해나가는 반복적 정제(Iterative [[Refinement]]) 패턴.
|
||||
- **작동 원리:**
|
||||
- **Forward Process:** 데이터에 가우시안 노이즈를 단계적으로 추가하여 완전한 노이즈 상태로 만듦.
|
||||
- **Reverse Process (Denoising):** 각 단계에서 추가된 노이즈를 예측하고 제거하여 원래 데이터를 복구하도록 모델을 학습.
|
||||
- **Sampling:** 학습된 모델을 사용해 순수 노이즈로부터 한 단계씩 노이즈를 걷어내며 새로운 데이터 생성.
|
||||
- **의의:** GAN의 학습 불안정성 문제를 해결하고, 압도적인 데이터 생성 품질과 다양성을 확보하여 Midjourney, Stable Diffusion 등의 기반 기술이 됨.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** GAN이 생성 모델의 정답으로 여겨지던 시대를 지나, 더 안정적이고 고성능인 확산 모델이 이미지/비디오 생성의 새로운 표준으로 자리 잡음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 위키 문서의 시각화 보조 자료나 목업 이미지를 생성할 때 최신 확산 모델 기반의 API를 활용하여 고품질 결과물을 생성함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Generative-Adversarial-Networks]]-GAN, [[Variational-Autoencoders-VAE]], [[CLIP]], [[Computer-Vision]]-[[Mastery]]
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Diffusion-Models.md
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: DDD-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [software-[[Architecture]], ddd, domain-driven-design, microservices, strategic-design]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Domain-Driven Design (DDD, 도메인 주도 설계)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "기술적 구현보다 비즈니스의 본질(도메인)을 코드의 중심에 두어라" — 복잡한 소프트웨어 프로젝트에서 비즈니스 로직과 기술 인프라를 분리하고, 도메인 전문가와 개발자가 동일한 언어(Ubiquitous Language)를 사용하여 시스템을 설계하는 방법론.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 거대한 시스템을 의미 있는 경계(Bounded Context)로 나누고, 각 맥락 안에서 핵심 비즈니스 모델을 정교하게 구축하여 복잡성을 관리하는 전략적 설계 패턴.
|
||||
- **핵심 요소:**
|
||||
- **Ubiquitous Language:** 기획자와 개발자가 소통하는 공통의 용어 사전.
|
||||
- **Bounded Context:** 모델이 적용되는 논리적인 경계. MSA의 기반이 됨.
|
||||
- **Entity & Value Object:** 식별자가 중요한 객체와 속성값이 중요한 객체의 구분.
|
||||
- **Aggregate:** 데이터 변경의 단위이자 캡슐화 경계.
|
||||
- **Layered Architecture:** 도메인 로직을 표현 레이어나 인프라 레이어로부터 격리.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 데이터베이스 테이블 중심의 설계에서, 비즈니스 행위([[Behavior]]) 중심의 설계로 전환. 초기에는 중복 내용이 여러 파일에 흩어져 있었으나, Antigravity 지식 정비 과정을 통해 통합 마스터 문서로 정립됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 스킬과 지식 카테고리를 설계할 때 DDD 원칙을 적용하여, 각 에이전트가 명확한 도메인 경계 내에서 자율성을 갖도록 구성함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Software-Architecture-Patterns]], Microservices, [[Strategic-Thinking]],[[ system]]-Design-for-AI-Scale
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Domain-Driven-Design-DDD.md
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: GAME-ANALYTICS-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [data-science, game-design, metrics, retention, monetization]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Game Analytics (게임 분석론)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터를 통해 플레이어의 경험을 읽고 설계하라" — 게임 내에서 발생하는 방대한 로그를 분석하여 리텐션, 이탈 지점, 경제 균형 등을 진단하고 개선하는 정량적 의사결정 체계.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 사용자 행동 로그를 깔대기(Funnel) 구조로 분석하여 특정 구간에서의 이탈 원인을 파악하고, A/B 테스트를 통해 최적의 게임 구성을 찾아가는 데이터 주도 패턴.
|
||||
- **주요 지표 (Metrics):**
|
||||
- **Retention (D1, D7, D30):** 게임에 다시 접속하는 비율. 게임의 근본적인 재미와 지속 가능성을 나타냄.
|
||||
- **DAU/MAU:** 활성 사용자 수 지표. 서비스의 규모와 활성도를 측정.
|
||||
- **ARPU/ARPPU:** 사용자당 평균 결제 금액. 비즈니스 모델의 효율성 측정.
|
||||
- **Churn Rate:** 이탈률. 특정 레벨이나 퀘스트에서의 난이도 병목 지점 파악에 유용.
|
||||
- **분석 기법:**
|
||||
- **Funnel [[Analysis]]:** 튜토리얼 완료율, 상점 진입 후 구매율 등 단계별 전환 확인.
|
||||
- **Cohort Analysis:** 유입 시기별 사용자 그룹의 행동 변화 추적.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순히 전체 매출만 보던 방식에서, 개별 플레이어의 '생애 가치(LTV)'와 '심리적 몰입 지표'를 정교하게 추적하는 방식으로 진화.
|
||||
- **정책 변화:** Skybound 프로젝트는 실시간 텔레메트리(Telemetry) 시스템을 통해 플레이어가 선호하는 무기 조합과 사망 지점 데이터를 수집, 밸런싱 작업에 즉시 환류함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Game-Economy-Design]], Data-Mining, AB-[[Testing]], Telemetry
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Game Analytics (게임 분석).md
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-GDTH-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, game-design-theory, mda-framework, flow-theory, mechanics, dynamics, aesthetics]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Game-Design-Theory]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "의도된 경험의 공학: 규칙(Mechanics)이 어떻게 플레이어의 행동(Dynamics)을 유도하고, 최종적으로 어떤 감정적 체험(Aesthetics)을 만들어내는지 파악하여 사용자에게 최상의 '몰입'을 선사하는 지식 체계."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
게임 디자인 이론(Game-Design-Theory)은 게임이 작동하는 방식과 그것이 인간에게 전달하는 가치를 연구하는 학제적 분야입니다.
|
||||
|
||||
1. **3대 핵심 프레임워크 (MDA)**:
|
||||
* **Mechanics (역학)**: 게임의 코드, 규칙, 기초 시스템.
|
||||
* **Dynamics (역동)**: 규칙들이 상호작용하며 발생하는 연쇄 반응과 플레이어 행동.
|
||||
* **Aesthetics (미학)**: 플레이어가 느끼는 감정 (도전, 즐거움, 공포 등). (UX-Design-and-Engagement와 연결)
|
||||
2. **몰입의 조절**:
|
||||
* **Flow Theory**: 난이도와 숙련도의 균형점(Flow Channel)을 유지하여 지루함과 불안을 방지. ([[Experience-Sampling-Method]]와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 '화려한 그래픽'이 게임의 전부라 믿는 경향 정책이 있었으나, 현대 정책은 탄탄한 '규칙의 상호작용 정책'이 그래픽보다 훨씬 더 깊은 몰입 정책을 만든다는 'Ludo-centric' 관점이 주류임(RL Update).
|
||||
- **정책 변화(RL Update)**: 이제는 단순한 '재미 정책'을 넘어, 교육 정책, 치료 정책, 조직 관리 정책 등에 게임 이론 정책을 이식하는 '기능성 게임(Serious Games)'과 '게이미피케이션 정책'으로 확장 중임. ([[Gamification-Theory]]와 연결)
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- UX-Design-and-Engagement, [[Experience-Sampling-Method]], [[Gamification-Theory]], [[Game-Design-Ontology]], Immersive-Sim, Complexity-Science
|
||||
- **Key Figures**: Jesse Schell, Raph Koster, Mihaly Csikszentmihalyi.
|
||||
---
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: GAME-THEORY-AI-001
|
||||
date: 2026-05-07T14:56:00.000Z
|
||||
type: knowledge_artifact
|
||||
standard: P-Reinforce v3.0
|
||||
tags: [game-theory, ai, multi-agent-systems, reinforcement-learning, strategic-decision-making]
|
||||
---
|
||||
|
||||
# [[Game-Theory-in-AI]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "상호작용의 지능화: 다중 에이전트 환경에서 각 주체의 최적 전략이 서로에게 미치는 영향을 수학적으로 모델링하여, 복잡한 경쟁 및 협력 상황에서 최적의 균형점(Equilibrium)을 찾는 인공지능 설계 원칙."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
게임 이론은 현대 인공지능, 특히 다중 에이전트 강화학습(MARL)과 자율 시스템 설계에서 의사결정의 핵심 논리를 제공합니다.
|
||||
|
||||
1. **핵심 개념 및 균형점**:
|
||||
* **내시 균형 (Nash Equilibrium)**: 다른 에이전트의 전략이 고정되었을 때, 어떤 에이전트도 자신의 전략을 변경하여 더 높은 이득을 얻을 수 없는 상태입니다. AI는 이 균형점을 향해 학습하며 시스템의 안정성을 확보합니다.
|
||||
* **제로섬 vs 비제로섬 게임**: 자원이 한정된 경쟁 상황(Zero-sum)과 협력을 통해 공동의 이익을 창출할 수 있는 상황(Non-zero-sum)을 구분하여 보상 함수(Reward Function)를 설계합니다.
|
||||
2. **AI 분야의 응용**:
|
||||
* **Multi-Agent Reinforcement Learning (MARL)**: 여러 AI 에이전트가 동시에 학습하는 환경에서 상호 간의 간섭을 게임 이론적으로 해결합니다.
|
||||
* **메커니즘 디자인 (Mechanism Design)**: 에이전트들이 자신의 이익을 위해 행동하더라도 전체 시스템이 원하는 방향(예: 자원 효율성)으로 유도되도록 규칙과 보상 구조를 설계합니다.
|
||||
3. **실전 사례**:
|
||||
* **AlphaGo & Poker AI**: 불완전 정보 게임(Poker)이나 복잡한 상태 공간(Go)에서 상대의 전략을 예측하고 최적의 대응수를 계산하는 데 필수적으로 사용됩니다.
|
||||
* **자율주행 및 드론 스웜**: 여러 자율 주행 차량이 교차로에서 충돌 없이 효율적으로 통행하기 위한 전략적 상호작용 모델링에 활용됩니다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **계산 복잡도**: 에이전트 수가 증가할수록 내시 균형을 찾는 계산량이 기하급수적으로 늘어나는 '차원의 저주' 문제가 발생합니다.
|
||||
* **합리성 가정의 한계**: 현실의 에이전트(인간 포함)는 항상 완벽하게 합리적으로 행동하지 않으므로, 제한된 합리성(Bounded Rationality)을 고려한 모델링이 필요합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics**: [[Reinforcement Learning (RL)]], [[Multi-Agent-Systems-MAS]], [[Bounded Rationality]], [[Algorithmic-Game-Theory]]
|
||||
- **Applications**: [[Autonomous Vehicles]], [[Artificial-Intelligence-in-Games]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-07*
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
id: GAME-THEORY-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [math, decision-theory, economics, ai-[[Strategy]]]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Game Theory (게임 이론)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "상대방의 전략을 고려한 최선의 선택을 수학적으로 분석하라" — 독립적인 의사결정자들이 서로의 선택이 자신의 결과에 영향을 미치는 상황(전략적 상호작용)에서 어떻게 행동하는지 연구하는 학문.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 상대방이 자신의 이익을 극대화한다는 가정 하에, 자신의 기대 보상을 최대화하는 '내쉬 균형(Nash Equilibrium)' 지점을 찾아가는 의사결정 패턴.
|
||||
- **세부 내용:**
|
||||
- **Zero-sum Game:** 한쪽의 이득이 다른 쪽의 손실이 되는 대립 관계 (예: 장기, 바둑).
|
||||
- **Prisoner's Dilemma:** 각자에게는 최선의 선택이 전체적으로는 최악의 결과를 낳는 협력의 딜레마 분석.
|
||||
- **Dominant Strategy:** 상대방이 무엇을 하든 상관없이 자신에게 가장 유리한 전략.
|
||||
- **Minimax Algorithm:** AI 체스/바둑 등에서 최악의 시나리오를 가정하고 손실을 최소화하는 경로 탐색.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 완전한 합리성을 전제로 하던 초기 모델에서, 진화 게임 이론(Evolutionary Game Theory) 및 행동 게임 이론을 통해 비합리성과 생물학적 진화 과정을 포괄하는 모델로 확장.
|
||||
- **정책 변화:** Antigravity 에이전트의 다중 에이전트 협업(Multi-agent Collaboration) 설계 시, 개인의 이익과 팀의 목표가 일치하도록 '메커니즘 디자인' 이론을 적용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Decision-Theory, Expected-Utility-Theory, Nash-Equilibrium, Mechanism-Design
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Game-Theory.md
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-INRE-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, inductive-[[Reasoning]], [[Logic]], epistimology, patterns, generalization]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Inductive-Reasoning]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "관찰이 쌓여 상식이 되다: '어제도 해가 떴고 오늘도 떴으니 내일도 뜰 것이다'처럼, 수많은 개별적 사례들로부터 보편적인 패턴이나 법칙을 끌어내어 미래를 예측하는 지능의 핵심 귀납 엔진."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
귀납적 추론(Inductive-Reasoning)은 구체적인 사실들로부터 일반적인 원리를 도출하는 사고 방식입니다.
|
||||
|
||||
1. **특징**:
|
||||
* **Probability-based**: 전제가 참이라도 결론이 100% 참임을 보장하지는 않음 (개연성의 영역).
|
||||
* **Pattern Recognition**: 뇌가 세상을 안정적으로 살아가기 위해 사용하는 가장 기본적인 지식 확장 방식. ([[Machine Learning (ML)]]의 본질)
|
||||
2. **왜 중요한가?**:
|
||||
* 인공지능(특히 딥러닝)이 수조 개의 텍스트나 이미지를 보고 '세상의 법칙'을 스스로 깨닫는 과정 자체가 거대한 귀납적 추론 장치이기 때문임.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거 논리학 정책은 귀납법을 연역법(Deductive)에 비해 '불확실한 정책'으로 보았으나, 현대 정책은 불확실한 복잡계에서 유일한 학습 도구 정책으로 그 가치를 극대화함(RL Update). ([[Epistemology]]와 연결)
|
||||
- **정책 변화(RL Update)**: 단순히 패턴을 찾는 정책을 넘어, 적은 표본만으로도 강력한 일반화 정책을 수행하는 '퓨샷 러닝([[Few-Shot-Learning]]) 정책'이나 '베이지안 귀납 정책'이 차세대 AI의 핵심 지능 정책으로 각광받음. (Few-Shot-Learning와 연결)
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Machine Learning (ML)]], [[Few-Shot-Learning]], [[Epistemology]], [[Grounded Theory Method]], [[Logic]]
|
||||
- **Modern Tech/Tools**: [[Bayesian Inference]], LLM-based pattern extraction, Predictive analytics.
|
||||
---
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: LLM-HALLUCINATION-001
|
||||
date: 2026-05-07T14:57:00.000Z
|
||||
type: knowledge_artifact
|
||||
standard: P-Reinforce v3.0
|
||||
tags: [llm, hallucination, ai-safety, rag, grounding, fact-checking]
|
||||
---
|
||||
|
||||
# [[LLM Hallucinations]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "확률적 몽상: 대규모 언어 모델이 학습 데이터의 패턴에 기반해 문법적으로 완벽하지만 사실과는 다른 정보를 자신 있게 생성하는 현상으로, 신뢰할 수 있는 AI 시스템 구축을 위해 반드시 해결해야 할 핵심 과제."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
LLM 환각(Hallucination)은 모델이 학습한 데이터의 통계적 분포와 실제 사실 간의 괴리에서 발생하며, 다양한 형태와 원인을 가집니다.
|
||||
|
||||
1. **주요 원인**:
|
||||
* **학습 데이터의 한계**: 데이터셋에 포함된 거짓 정보, 편향, 또는 특정 주제에 대한 정보 부족이 모델의 잘못된 학습을 유도합니다.
|
||||
* **확률적 토큰 예측**: 모델은 본질적으로 다음 토큰을 확률적으로 예측하므로, 사실 관계보다는 문맥적 매끄러움을 우선시할 때 환각이 발생합니다.
|
||||
* **모델 압축 및 과적합**: 복잡한 지식을 유한한 파라미터에 압축하는 과정에서 정보가 왜곡되거나, 특정 패턴에 과하게 최적화될 수 있습니다.
|
||||
2. **환각의 유형**:
|
||||
* **Intrinsic (내재적)**: 제공된 소스 텍스트와 모순되는 정보를 생성하는 경우.
|
||||
* **Extrinsic (외재적)**: 소스에는 없지만 사실 여부를 확인할 수 없는 정보를 지어내는 경우.
|
||||
3. **완화 전략 (Mitigation)**:
|
||||
* **RAG (Retrieval-Augmented Generation)**: 외부 지식 베이스(Wiki, DB)에서 관련 문서를 검색하여 모델의 답변을 사실에 근거(Grounding)하게 합니다.
|
||||
* **Chain-of-Verification (CoVe)**: 모델이 스스로 생성한 답변의 개별 주장을 검증하는 질문을 던지고 수정하도록 유도합니다.
|
||||
* **Self-Correction & LaaJ**: 다른 LLM을 검수자(Judge)로 활용하여 답변의 사실성을 교차 검증합니다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **창의성 vs 사실성**: 환각을 억제하기 위해 제약을 강화하면 모델의 창의적인 문장 생성 능력이 저하될 수 있는 트레이드오프가 존재합니다.
|
||||
* **검증 비용**: 실시간 검증 레이어를 추가할수록 추론 비용(Latency & API Cost)이 증가합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics**: [[Large Language Models (LLM)]], [[RAG (검색 증강 생성)]], [[AI Safety]], [[Knowledge-Grounding]]
|
||||
- **Protocols**: [[P-Reinforce]], [[Semantic Grounding & Provenance]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-07*
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AI-LORA
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.00
|
||||
tags: [AI, LLM, LoRA, FineTuning, [[Efficiency]]]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[LoRA (Low-Rank Adaptation)]] (저차원 적응)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "거대한 산을 옮기지 말고, 신발 밑창에 아주 얇은 깔창 하나만 덧대는 혁명." 수조 개의 파라미터를 가진 거대 모델 전체를 건드리지 않고, 아주 작은 추가 행렬(A, B)만 학습시켜 모델의 지식을 효율적으로 갱신하는 최신 튜닝 기법이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **The Core Idea**: 모델이 학습하며 변하는 가중치의 차이($\Delta W$)는 사실 '낮은 차원(Low intrinsic rank)'에 머물러 있다는 점에 착안함.
|
||||
- **Mechanism**:
|
||||
- 기존 가중치 $W$는 얼려둔(Freeze) 채로, 옆에 두 개의 작은 행렬($A \times B$)을 둠.
|
||||
- $W_{new} = W + (A \times B)$.
|
||||
- **Unbelievable Efficiency**:
|
||||
- 전체 파라미터의 0.01%만 학습해도 전체 튜닝과 유사한 성능을 냄.
|
||||
- 수 기가바이트의 모델 대신 수 메가바이트의 'LoRA 가중치 파일'만 저장하고 공유하면 됨.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- LoRA는 효율적이지만, 대규모 멀티 모달 학습이나 근본적인 기초 지식 습득에는 전체 파인튜닝(Full [[Fine-tuning]])보다 성능이 소폭 떨어질 수 있다. 이를 보완하기 위해 양자화 기술을 결합한 **QLoRA**가 등장하여, 일반 소비자용 그래픽카드 한 장으로도 거대 언어 모델을 튜닝하는 'AI 민주화'를 이끌고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Instruction-Tuning]] , [[Quantization]] (양자화)
|
||||
- Variant: QLoRA (Quantized LoRA)
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: ML-LIFE-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [machine-learning, [[MLOps]], workflow, software-engineering]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Machine Learning Lifecycle (머신러닝 생명주기)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터 수집부터 모델 폐기까지, AI의 요람에서 무덤까지의 여정" — 단순한 학습(Training)을 넘어 비즈니스 목표 설정, 데이터 엔지니어링, 배포, 모니터링을 포괄하는 순환적인 개발 프로세스.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 한 번의 배포로 끝나는 것이 아니라, 실제 운영 데이터(Real-world data)를 지속적으로 환류(Feedback)하여 모델을 개선해 나가는 반복적 라이프사이클 패턴.
|
||||
- **주요 단계:**
|
||||
- **Data Preparation:** 수집, 클리닝, 라벨링, 피처 엔지니어링. 가장 많은 시간이 소요되는 구간.
|
||||
- **Model Development:** 알고리즘 선택, 학습, 하이퍼파라미터 튜닝, 평가.
|
||||
- **Deployment & Serving:** 학습된 모델을 실제 서비스 환경(API, Edge 등)에 배포.
|
||||
- **Monitoring & Maintenance:** 성능 하락(Model Drift) 감지, 재학습(Retraining) 트리거.
|
||||
- **MLOps:** 이 생명주기 전반을 자동화하여 효율성을 극대화하는 실천법.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 연구 중심의 '모델링'에만 치중하던 방식에서, 지속 가능한 운영과 데이터 품질 관리가 강조되는 '데이터 중심(Data-centric)' 환경으로 전환.
|
||||
- **정책 변화:** Antigravity 프로젝트는 '지식 엔진'의 답변 품질을 매일 모니터링하며, 성능이 저하될 경우 자동으로 위키 데이터를 재인덱싱하는 라이프사이클 자동화 시스템을 갖추고 있음.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[MLOps]], Data-Centric-AI, [[Hyper[[Parameter]]-Optimization]], Continuous-Integration
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Machine-Learning-Lifecycle.md
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-C8F96B
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Model Context Protocol (MCP)"
|
||||
---
|
||||
|
||||
# [[Model Context Protocol (MCP)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> Model Context Protocol (MCP)은 Cursor, Claude Code, Windsurf, GitHub Copilot 등과 같은 AI 코딩 어시스턴트(AI 에이전트)를 분석 엔진과 직접 연결할 수 있도록 지원하는 프로토콜입니다 [1, 2]. 이 프로토콜을 통해 AI는 대화형 워크플로우 내에서 실시간으로 쿼리를 보내고 통제된 피드백을 받을 수 있습니다 [1, 3]. 결과적으로 AI를 활용한 생산성과 코드 품질 및 보안 사이의 간격을 메워주는 특수한 브릿지 역할을 수행합니다 [2, 4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **AI 에이전트와의 직접 통합**: MCP는 [[SonarQube]] MCP 서버와 같은 분석 도구를 Cursor, Claude Code, Windsurf 등의 AI 코딩 에이전트에 직접 연결하는 표준 방식을 제공합니다 [1].
|
||||
- **실시간 쿼리 및 분석 수행**: AI 어시스턴트는 MCP를 활용해 신뢰할 수 있는 분석 엔진과 실시간으로 상호작용합니다 [2, 3]. 이를 통해 AI는 코드 스니펫을 분석하고, Quality Gate 상태를 확인하며, 보안 핫스팟(Security Hotspots)을 즉각적으로 찾아낼 수 있습니다 [4].
|
||||
- **사전 코드 검토 및 워크플로우 최적화**: MCP를 통한 통합은 AI가 코드를 생성하는 과정에서 실시간으로 검토 및 개선이 이루어지도록 보장합니다 [3]. 이는 코드가 풀 리퀘스트(Pull Request) 단계에 도달하기 훨씬 전부터 작동하므로, 에이전틱(Agentic) 워크플로우를 최적화하고 안전한 코드 전달을 가능하게 합니다 [3].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[AI Agents]], Static Code [[Analysis]], Automated [[Code Review]]
|
||||
- **Projects/Contexts:** SonarQube MCP Server, Cursor, Claude Code, Windsurf, GitHub Copilot
|
||||
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (제공된 소스에서는 주로 SonarQube 환경에서의 통합 사례를 통해서만 MCP가 설명되고 있으며, 프로토콜 자체의 심층적인 기술적 사양이나 다른 활용 사례에 대한 정보는 없습니다.)
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
id: AI-MODAL-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, [[Deep-Learning]], multi-modal, [[CLIP]], dall-e, cross-modal-learning]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Multi-Modal Learning (멀티모달 학습)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "언어의 개념과 이미지의 형상을 하나의 공통된 공간(Latent Space)에서 융합하여, 보고 듣고 말하는 통합 지능을 완성하라" — 텍스트, 이미지, 오디오, 비디오 등 서로 다른 형식의 데이터를 동시에 학습하여 모달리티 간의 상관관계를 파악하고 상호 변환하는 학습 체계.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Cross-modal Embedding [[Alignment]]" — 이미지에서 추출한 특징 벡터와 텍스트에서 추출한 특징 벡터가 같은 의미를 가질 때 가깝게 위치하도록 학습시킴으로써, 기계가 "사과"라는 단어와 사과의 시각적 형상을 동일한 개념으로 인지하게 만드는 패턴.
|
||||
- **주요 구현 방식:**
|
||||
- **Early Fusion:** 입력 단계에서 데이터를 물리적으로 결합.
|
||||
- **Late Fusion:** 각 모달리티를 개별 모델로 처리한 후 결과 단계에서 통합.
|
||||
- **Joint Training (CLIP 등):** 공유된 잠재 공간에서 두 데이터를 직접 비교하며 학습.
|
||||
- **의의:** AI가 단순히 글자만 읽는 수준을 넘어, 현실 세계의 다채로운 정보를 인간처럼 복합적으로 이해하고 생성(Generative AI)할 수 있게 함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 모달리티 간의 단순 결합이 정보의 노이즈를 키울 수 있다는 우려를 넘어, 최근에는 서로 다른 감각 정보가 보완 작용을 하여 단일 모달리티보다 더 강력한 일반화 성능을 낼 수 있음이 증명됨 (GPT-4o 등).
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트가 코드 설명뿐만 아니라 아키텍처 다이어그램(Image)과 사용자의 음성 지시(Audio)를 동시에 해석할 수 있도록 멀티모달 추론 레이어를 확장 중임.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Transformer-Architecture]]-Foundations, [[Computer-Vision]]-Foundations, NLP-Foundations, [[Generative-Adversarial-Networks]]-GAN
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Multi-Modal-Learning.md
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-NPML-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, motor-learning, [[Neuroplasticity]], skill-acquisition]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Neuroplasticity in Motor Learning]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "반복이 만드는 신경의 고속도로: 새로운 움직임을 익힐 때 일차 운동 피질이 물리적으로 영토를 확장하며 '숙련도'를 뉴런의 연결 강도로 치환하는 과정."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
운동 학습에서의 신경가소성(Neuroplasticity in Motor Learning)은 새로운 신체적 기술을 습득할 때 뇌가 구조적, 기능적으로 변화하는 원리를 다룹니다.
|
||||
|
||||
1. **단계별 가소성**:
|
||||
* **초기 단계 (Fast Learning)**: 수분 내에 발생하는 기능적 연결성 강화. 소뇌와 기저핵이 주도.
|
||||
* **장기 단계 (Slow Learning)**: 수주~수개월간의 반복을 통한 시냅스 구조 변화(Dendritic Spine 생성).
|
||||
2. **운동 피질의 재구성 (Map Expansion)**:
|
||||
* 특정 동작(예: 피아노 연주)에 사용되는 손가락 담당 뇌 영역이 연습량에 비례하여 주변 영역을 점유하며 확장됨.
|
||||
3. **수면과 공고화 (Consolidation)**:
|
||||
* 낮 동안 연습한 운동 기술은 수면 중에 단기 기억에서 장기 기억으로 전이되며, 이때 신경망의 오프라인 재배선이 일어남.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 운동 기술이 한 번 익혀지면 변하지 않는다고 믿었으나, '사용하지 않으면 잃는다(Use it or lose it)'는 원리에 따라 운동 피질의 지도는 훈련 중단 시 신속하게 축소되거나 다른 기능에 점유됨이 밝혀짐.
|
||||
- **정책 변화(RL Update)**: 재활 훈련 시 '양보다는 질'과 '가변성(Variability) 학습'이 뇌의 가소성을 더 효과적으로 자극한다는 연구에 따라, 단순 반복보다는 다양한 상황에서의 문제 해결형 운동 교육이 표준 정책으로 도입됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: Motor Control, [[Neuroplasticity]], Cerebellum, Basal Ganglia, Long-Term Potentiation (LTP)
|
||||
- **Modern Tech/Tools**: dMRI (Diffusion MRI), TMS-based Brain Mapping.
|
||||
---
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-NPML-002
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, brain-maps, cortical-reorganization]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Neuroplasticity-in-Motor-Learning]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "뇌의 영토 전쟁: 특정 운동 기능을 극한으로 연마할 때 운동 피질의 기능 지도가 동적으로 재구성되는 '피질 재조직화'의 경이로움."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
이 문서는 운동 학습 시 발생하는 피질 수준의 가소성과 지도 재구성(Cortical Reorganization)에 초점을 맞춥니다.
|
||||
|
||||
1. **운동 피질의 동적 변화**:
|
||||
* **Representational Plasticity**: 훈련된 근육 동원 패턴에 맞춰 일차 운동 피질(M1)의 뉴런 발화 패턴이 더 정교해짐.
|
||||
* **Sprouting and Pruning**: 새로운 시냅스 축삭의 발아와 불필요한 연결의 제거를 통해 최적화된 운동 회로 구축.
|
||||
2. **운동 전 피질과 보완 운동 영역 (PMC/SMA)**:
|
||||
* 복잡한 시퀀스 동작(예: 춤, 격투기)을 익힐 때 동작의 순서를 계획하고 준비하는 영역에서의 회로 효율화.
|
||||
3. **장입 가소성 (Homeostatic Plasticity)**:
|
||||
* 특정 신경 회로가 너무 과하게 흥분하지 않도록 조절하면서도 학습 효과를 유지하는 뇌의 항상성 기제.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 운동 피질을 고정된 '호문쿨루스(Homunculus)' 지도로 보았으나, 현재는 학습과 경험에 의해 실시간으로 변하는 '유동적 지도'로 이해함.
|
||||
- **정책 변화(RL Update)**: 에이전트 기반 학습(RL 에이전트)에서 행동 선택의 엔트로피를 조절하여 새로운 탐색과 기존 숙련 사이의 균형을 맞추는 기법이 실제 뇌의 운동 가소성 조절 기제에서 영감을 얻음.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: [[Neuromuscular-Control]], Synaptic Plasticity, Skill Acquisition, Somatosensory Cortex
|
||||
- **Modern Tech/Tools**: EEG-based Source Localization, Optical Imaging.
|
||||
---
|
||||
@@ -0,0 +1,312 @@
|
||||
---
|
||||
name: p_reinforce
|
||||
description: "원시 데이터를 영속 위키로 정리하고, 중복·오류·충돌을 방지하며 기존 대표 문서를 강화하는 지식 자동화 에이전트."
|
||||
risk: safe
|
||||
source: self
|
||||
allowed-tools: [Read, Write, Edit, Bash, Glob]
|
||||
---
|
||||
|
||||
# P-Reinforce
|
||||
|
||||
너는 사용자의 원시 데이터, 대화 기록, 아이디어, 조사 내용, 개발 기록을 영속적 위키로 정리하는 지식 자동화 에이전트다.
|
||||
|
||||
핵심 임무는 새 문서를 많이 만드는 것이 아니라, 기존 지식과 비교하여 중복을 줄이고 대표 문서를 강화하는 것이다.
|
||||
|
||||
최우선 원칙:
|
||||
|
||||
> 새 문서를 만들기 전에 먼저 판단한다.
|
||||
> "이 입력은 새 문서가 필요한가, 아니면 기존 문서를 업데이트해야 하는가?"
|
||||
|
||||
---
|
||||
|
||||
## 1. 실행 트리거
|
||||
|
||||
다음 요청이 들어오면 실행한다.
|
||||
|
||||
- wiki화 해줘
|
||||
- 위키로 정리해줘
|
||||
- 이 내용 저장해줘
|
||||
- 2nd brain에 넣어줘
|
||||
- P-Reinforce 실행
|
||||
- 지식화해줘
|
||||
- raw 데이터 정리해줘
|
||||
|
||||
실행 시 바로 Write하지 말고 반드시 기존 문서와의 관계를 먼저 확인한다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 기본 폴더 구조
|
||||
|
||||
- `00_Raw/`: 원본 데이터 보관. 수정 금지.
|
||||
- `10_Wiki/Projects/`: 프로젝트 중심 지식.
|
||||
- `10_Wiki/Topics/`: 일반 개념 지식.
|
||||
- `10_Wiki/Topics_Art/`: 아트, 디자인, 그래픽.
|
||||
- `10_Wiki/Topics_Biz/`: 사업, 마케팅, 시장 조사.
|
||||
- `10_Wiki/Topics_Blog/`: 블로그, 콘텐츠 초안.
|
||||
- `10_Wiki/Topics_GD/`: 게임 디자인, 밸런스, 시스템 기획.
|
||||
- `10_Wiki/Decisions/`: 의사결정 기록.
|
||||
- `10_Wiki/Skills/`: 프롬프트, 워크플로우, 자동화 패턴.
|
||||
- `20_Meta/Graph.json`: 문서 간 연결 관계.
|
||||
- `20_Meta/Policy.md`: 사용자 피드백과 분류 정책.
|
||||
- `20_Meta/Index.md`: 위키 전체 인덱스.
|
||||
- `20_Meta/ReviewQueue/`: 검토 필요 항목.
|
||||
|
||||
---
|
||||
|
||||
## 3. 처리 흐름
|
||||
|
||||
모든 입력은 아래 순서로 처리한다.
|
||||
|
||||
1. Raw 입력 확인
|
||||
2. 기존 위키 문서 검색
|
||||
3. 중복 여부 검사
|
||||
4. 충돌 여부 검사
|
||||
5. 출처 신뢰도 평가
|
||||
6. 저장 판단 결정
|
||||
7. CREATE / UPDATE / MERGE / QUARANTINE / REJECT 중 하나 실행
|
||||
8. 관련 문서 연결
|
||||
9. Policy, Graph, Index 필요 시 갱신
|
||||
10. 실행 결과 보고
|
||||
|
||||
---
|
||||
|
||||
## 4. 저장 판단 기준
|
||||
|
||||
- `CREATE`: 기존 문서와 중복되지 않는 새로운 지식이면 새 문서를 생성한다.
|
||||
- `UPDATE`: 기존 대표 문서를 보강하는 내용이면 새 문서를 만들지 않고 기존 문서를 업데이트한다.
|
||||
- `MERGE`: 중복 문서가 여러 개 있으면 병합을 제안한다. 자동 삭제하지 않는다.
|
||||
- `QUARANTINE`: 출처가 약하거나 기존 정보와 충돌하면 ReviewQueue에 보류한다.
|
||||
- `REJECT`: 저장 가치가 낮거나 명백히 잘못된 정보는 저장하지 않고 이유만 보고한다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 중복 방지 규칙
|
||||
|
||||
하나의 핵심 개념에는 하나의 대표 문서를 유지한다.
|
||||
|
||||
새 문서 생성 전 다음을 확인한다.
|
||||
|
||||
- 제목 유사도
|
||||
- 핵심 개념 유사도
|
||||
- 내용 의미 유사도
|
||||
- Raw Source 유사도
|
||||
- aliases 유사 표현
|
||||
- Graph.json 연결 관계
|
||||
|
||||
판단 기준:
|
||||
|
||||
- 유사도 `0.92 이상`: 새 문서 생성 금지. 기존 문서 업데이트.
|
||||
- 유사도 `0.80 ~ 0.92`: 중복 후보. ReviewQueue에 기록.
|
||||
- 유사도 `0.65 ~ 0.80`: 관련 지식. 별도 문서 가능하나 Related 링크 필수.
|
||||
- 유사도 `0.65 미만`: 새 지식 후보. 출처 신뢰도 확인 후 생성 가능.
|
||||
|
||||
---
|
||||
|
||||
## 6. 출처 신뢰도
|
||||
|
||||
모든 지식에는 출처 신뢰도를 부여한다.
|
||||
|
||||
- `S`: 사용자가 명시적으로 확정한 결정사항.
|
||||
- `A`: 프로젝트 내부 문서, ADR, 실제 코드, 실행 로그.
|
||||
- `B`: 공식 문서, 논문, 신뢰 가능한 외부 자료.
|
||||
- `C`: AI 요약 또는 추론.
|
||||
- `D`: 출처가 불분명한 메모, 임시 아이디어.
|
||||
|
||||
저장 규칙:
|
||||
|
||||
- S/A 등급은 대표 문서에 반영 가능.
|
||||
- B 등급은 출처와 함께 반영 가능.
|
||||
- C 등급은 AI 추론 또는 해석으로 표시한다.
|
||||
- D 등급은 기본적으로 `needs_review` 또는 ReviewQueue에 보류한다.
|
||||
|
||||
---
|
||||
|
||||
## 7. 충돌 처리 규칙
|
||||
|
||||
새 입력이 기존 문서와 충돌하면 기존 내용을 즉시 덮어쓰지 않는다.
|
||||
|
||||
1. 충돌 문서를 식별한다.
|
||||
2. 기존 주장과 새 주장을 비교한다.
|
||||
3. 출처 신뢰도와 최신성을 확인한다.
|
||||
4. 자동 판단이 어렵다면 `20_Meta/ReviewQueue/contradiction_candidates.md`에 기록한다.
|
||||
5. 기존 문서에는 충돌 후보를 `모순 및 업데이트` 섹션에 남긴다.
|
||||
|
||||
---
|
||||
|
||||
## 8. ReviewQueue 규칙
|
||||
|
||||
검토가 필요한 정보는 `20_Meta/ReviewQueue/`에 기록한다.
|
||||
|
||||
권장 파일:
|
||||
|
||||
- `duplicate_candidates.md`
|
||||
- `contradiction_candidates.md`
|
||||
- `low_confidence_notes.md`
|
||||
- `merge_suggestions.md`
|
||||
- `deprecated_candidates.md`
|
||||
|
||||
기록할 내용:
|
||||
|
||||
- 입력 요약
|
||||
- 관련 문서
|
||||
- 문제 유형
|
||||
- 추천 처리
|
||||
- 이유
|
||||
- 사용자 확인 필요 여부
|
||||
|
||||
---
|
||||
|
||||
## 9. 문서 작성 규칙
|
||||
|
||||
새 문서는 가능한 한 아래 요소를 포함한다.
|
||||
|
||||
- 제목
|
||||
- 한 줄 통찰
|
||||
- 핵심 개념
|
||||
- 추출된 패턴
|
||||
- 세부 내용
|
||||
- 검증 상태
|
||||
- 출처 신뢰도
|
||||
- 중복 검사 결과
|
||||
- 모순 및 업데이트
|
||||
- 관련 문서 링크
|
||||
- Raw Source
|
||||
- 변경 이력
|
||||
|
||||
문서 frontmatter에는 가능한 한 다음 항목을 포함한다.
|
||||
|
||||
- id
|
||||
- title
|
||||
- category
|
||||
- status
|
||||
- canonical_id
|
||||
- aliases
|
||||
- duplicate_of
|
||||
- source_trust_level
|
||||
- confidence_score
|
||||
- created_at
|
||||
- updated_at
|
||||
- review_reason
|
||||
- merge_history
|
||||
- tags
|
||||
- raw_sources
|
||||
- github_commit
|
||||
|
||||
문서 상태는 다음 중 하나를 사용한다.
|
||||
|
||||
- `draft`
|
||||
- `verified`
|
||||
- `needs_review`
|
||||
- `deprecated`
|
||||
- `merged`
|
||||
|
||||
---
|
||||
|
||||
## 10. 분류 규칙
|
||||
|
||||
기본 저장 위치는 `10_Wiki/Topics`다.
|
||||
|
||||
단, 성격에 따라 아래 폴더를 사용한다.
|
||||
|
||||
- 프로젝트 실행: `10_Wiki/Projects`
|
||||
- 의사결정: `10_Wiki/Decisions`
|
||||
- 프롬프트/워크플로우: `10_Wiki/Skills`
|
||||
- 아트: `10_Wiki/Topics_Art`
|
||||
- 사업: `10_Wiki/Topics_Biz`
|
||||
- 블로그: `10_Wiki/Topics_Blog`
|
||||
- 게임 기획: `10_Wiki/Topics_GD`
|
||||
|
||||
새 폴더는 기존 폴더와 의미적으로 맞지 않을 때만 생성한다.
|
||||
특정 폴더의 파일이 12개를 초과하면 세분화를 제안하되 자동 실행하지 않는다.
|
||||
|
||||
---
|
||||
|
||||
## 11. 연결 규칙
|
||||
|
||||
모든 문서는 최소 2개 이상의 관련 문서와 연결한다.
|
||||
|
||||
연결 기준:
|
||||
|
||||
- 상위 개념
|
||||
- 유사 개념
|
||||
- 반대 개념
|
||||
- 같은 프로젝트의 결정사항
|
||||
- 같은 Raw Source에서 나온 지식
|
||||
- 같은 문제를 해결하는 다른 접근법
|
||||
|
||||
`Graph.json`이 있으면 기존 데이터를 보존하면서 업데이트한다.
|
||||
|
||||
---
|
||||
|
||||
## 12. 사용자 피드백 반영
|
||||
|
||||
사용자의 피드백은 `20_Meta/Policy.md`에 기록하고 다음 분류에 반영한다.
|
||||
|
||||
예시:
|
||||
|
||||
- "이건 코딩이 아니라 비즈니스 폴더야."
|
||||
- "이 문서를 대표 문서로 써."
|
||||
- "이건 중복이니까 합쳐."
|
||||
- "이 내용은 사실이 아니야."
|
||||
|
||||
---
|
||||
|
||||
## 13. Git 규칙
|
||||
|
||||
변경사항은 명확한 단위로 커밋한다.
|
||||
|
||||
커밋 타입:
|
||||
|
||||
- `reinforce:create`
|
||||
- `reinforce:update`
|
||||
- `reinforce:merge`
|
||||
- `reinforce:review`
|
||||
- `reinforce:deprecate`
|
||||
- `reinforce:fix`
|
||||
- `reinforce:policy`
|
||||
- `reinforce:graph`
|
||||
|
||||
Git push 실패 시 위험한 복구 명령을 자동 실행하지 않는다.
|
||||
실패 이유를 보고하고 사용자 확인을 요청한다.
|
||||
|
||||
---
|
||||
|
||||
## 14. 실행 보고
|
||||
|
||||
작업 후 다음을 간단히 보고한다.
|
||||
|
||||
- 생성한 문서
|
||||
- 업데이트한 문서
|
||||
- ReviewQueue에 보류한 항목
|
||||
- 중복 검사 결과
|
||||
- 충돌 검사 결과
|
||||
- 출처 신뢰도
|
||||
- 연결한 문서
|
||||
- Git 처리 결과
|
||||
- 사용자 확인이 필요한 항목
|
||||
|
||||
---
|
||||
|
||||
## 15. 커뮤니케이션 규칙
|
||||
|
||||
1. 모든 응답은 한국어로 작성한다.
|
||||
2. 새 문서를 만들기 전에 기존 문서와의 관계를 먼저 확인한다.
|
||||
3. 중복 가능성이 있으면 반드시 보고한다.
|
||||
4. 출처가 약한 정보는 확정 사실처럼 쓰지 않는다.
|
||||
5. 사용자가 명시적으로 결정한 내용은 S급으로 기록한다.
|
||||
6. Raw 데이터는 수정하지 않는다.
|
||||
7. 기존 문서 삭제, 대량 수정, 대표 문서 변경은 사용자 확인 없이는 수행하지 않는다.
|
||||
8. 문서가 많아지는 것보다 대표 문서의 품질이 높아지는 것을 더 좋은 결과로 본다.
|
||||
9. 최종 목표는 "많은 파일"이 아니라 "다시 찾고 연결할 수 있는 정확한 지식"이다.
|
||||
|
||||
---
|
||||
|
||||
## 16. LLM 실행 가이드 (로컬 모델 성능 강화용)
|
||||
|
||||
> 이 섹션은 로컬 LLM이 이 스킬을 실행할 때 일관된 판단을 유지하도록 돕기 위해 작성되었다.
|
||||
> 추상적 규칙 대신 구체적인 판단 체인과 예시를 제공한다.
|
||||
|
||||
### 16-1. 판단 체인 (Chain-of-Thought 템플릿)
|
||||
|
||||
입력이 들어오면 아래 질문을 순서대로 스스로에게 던진다.
|
||||
각 질문에 답하면서 다음 단계로 이동한다.
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-47A74B
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[Pull Request (PR)]] 워크플로우"
|
||||
---
|
||||
|
||||
# [[Pull Request (PR) 워크플로우]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> Pull Request (PR) 워크플로우는 소프트웨어 개발 과정에서 코드 변경 사항이 메인 브랜치에 병합(merge)되기 전에 검토, 분석 및 승인되는 핵심 단계입니다 [1, 2]. 현대적인 PR 워크플로우는 인간 개발자의 수동 리뷰와 AI 기반 코드 리뷰, 정적 분석([[SAST]]) 등의 자동화 도구를 결합한 하이브리드 방식을 채택합니다 [3, 4]. 이를 통해 보안 취약점과 버그를 조기에 발견하고 PR 처리 시간을 크게 단축하여 전체적인 소프트웨어 배포의 안정성과 속도를 향상시킵니다 [5, 6].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **자동화 검증 및 품질 게이트 (Quality [[Gates]]) 통합:** PR이 생성되면 즉각적으로 린터(Linter), 정적 애플리케이션 보안 테스트(SAST), AI 리뷰 봇 등이 병렬로 실행되어 코드 변경 사항을 스캔합니다 [1, 7, 8]. 이 과정에서 보안 취약점, 메모리 누수, 코드 스멜 등을 사전에 찾아내며, 조직에서 설정한 코드 품질 및 보안 기준([[Quality Gates]])을 통과하지 못하면 PR 병합이 시스템적으로 차단됩니다 [9-11].
|
||||
- **하이브리드 리뷰(Hybrid Review) 체계:** 가장 효율적인 PR 워크플로우는 기계와 인간의 장점을 결합하여 이루어집니다 [12]. 자동화 도구는 구문 오류, 스타일 위반, 알려진 취약점 등 기계적인 검증과 사전 필터링을 빠르게 처리하여 리뷰어의 피로도를 낮춥니다 [3, 13]. 인간 리뷰어는 도구가 파악할 수 없는 아키텍처 결정의 트레이드오프, 복잡한 비즈니스 로직, 서비스 간의 상호 작용 등 문맥 파악이 필수적인 고차원적 판단에 집중합니다 [3, 4, 14].
|
||||
- **경로 기반 라우팅과 필수 승인 (Path-Based Routing):** GitHub의 CODEOWNERS나 GitLab의 승인 규칙 같은 기능을 통해, PR 내에서 변경된 파일 경로(예: 결제 모듈, 인증 로직)에 따라 적절한 전문 팀(보안 팀, 시니어 개발자 등)에게 자동으로 리뷰 요청을 할당합니다 [15, 16]. 자동화된 검사를 통과하고 지정된 검토자의 필수 승인을 모두 확보해야만 코드 병합(Merge)이 활성화되는 다단계 아키텍처를 가집니다 [8, 16].
|
||||
- **PR 주기 시간(Cycle Time) 단축 및 지표 관리:** 자동화된 리뷰 어시스턴트를 도입한 조직은 PR 생성부터 병합까지 걸리는 'PR 사이클 타임'과 '첫 리뷰까지의 시간'을 최대 40%까지 단축할 수 있습니다 [3, 5]. 이는 검토 대기열(Backlog)이 쌓이는 병목 현상을 방지하여, 개발자의 컨텍스트 스위칭 비용을 줄이고 배포 빈도(Deployment frequency)를 높이는 핵심 요소로 작용합니다 [5, 17].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** 수동 코드 리뷰(Manual [[Code Review]]), 자동화된 코드 리뷰(Automated Code Review), [[정적 애플리케이션 보안 테스트(SAST)]], [[Quality Gates]]
|
||||
- **Projects/Contexts:** GitHub CODEOWNERS, CI/CD 파이프라인
|
||||
- **Contradictions/Notes:** 자동화된 AI PR 리뷰 봇은 프로세스를 가속화하지만, 때로는 사소하거나 가치 없는 코멘트를 대량으로 발생시켜 리뷰어에게 '경고 피로(Alert Fatigue)'를 유발할 수 있습니다 [18, 19]. 따라서 자동화 도구는 보조 수단일 뿐, 심층적인 아키텍처 결정은 여전히 인간의 수동 검토에 의존해야 합니다 [18].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-3B4223
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Pull Request (PR)"
|
||||
---
|
||||
|
||||
# [[Pull Request (PR)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 풀 리퀘스트(Pull Request, PR)는 소프트웨어 개발 과정에서 개발자가 자신이 수정한 코드를 메인 브랜치에 병합(merge)하기 전, 다른 팀원이나 자동화 도구에게 코드 검토를 요청하는 워크플로우를 의미합니다 [1-3]. 이는 매뉴얼 코드 리뷰와 자동화된 정적 애플리케이션 보안 테스트([[SAST]]) 및 AI 코드 리뷰가 실행되는 주요 환경으로 작용합니다 [1, 3-5]. PR 단계에서 코드의 품질, 보안 취약점, 로직 오류 등을 사전에 식별하고 논의함으로써 프로덕션 환경에 결함이 배포되는 것을 방지하고 유지보수성을 높일 수 있습니다 [4, 6-8].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **코드 리뷰의 핵심 컨텍스트**
|
||||
풀 리퀘스트 워크플로우는 수동 및 자동화된 코드 리뷰가 이루어지는 필수적인 단계입니다 [3, 4]. 개발자들은 PR을 통해 코드를 병합하기 전에 버그, 보안 취약점, 스타일 위반, 성능 및 유지보수성 문제 등을 종합적으로 평가합니다 [1, 4]. 수동 리뷰에서 동료 개발자들은 PR을 검토하며 비즈니스 로직, 아키텍처 결정, 코드 가독성 등 자동화 도구가 파악하기 어려운 문맥과 의도를 검증합니다 [3, 8]. 동시에 [[SonarQube]], Snyk, Semgrep 등의 정적 분석 도구들은 PR 생성 시 CI/CD 파이프라인과 연동되어 코드를 스캔하고, 품질 기준을 충족하지 못할 경우 병합을 차단하는 게이트(gate) 역할을 수행합니다 [7, 9-11].
|
||||
|
||||
* **AI 기반 도구의 PR 통합**
|
||||
최근에는 다양한 AI 기반 코드 리뷰 및 보안 도구들이 PR 워크플로우 내에 직접 통합되어 개발자 경험과 리뷰 속도를 향상시키고 있습니다 [4, 7]. 예를 들어, GitHub Copilot이나 [[Semgrep Assistant]], Snyk Code와 같은 도구는 PR 토론(discussion) 스레드 내에 직접 컨텍스트 기반의 제안을 추가하거나 인라인으로 수정 코드를 제공합니다 [4, 9, 12-14]. 이 과정에서 AI는 단순한 오류 탐지를 넘어 PR 요약본을 생성하고 발견된 취약점에 대한 수정안을 자동으로 검증(Autofix)하여 시니어 개발자 및 리뷰어의 피로도를 크게 줄여줍니다 [12, 15-17].
|
||||
|
||||
* **생산성 및 딜리버리 지표 (Metrics)**
|
||||
PR 워크플로우의 효율성은 조직의 소프트웨어 딜리버리 성과를 결정짓는 중요한 요소입니다 [18, 19]. AI 및 자동화 코드 리뷰 도구를 PR에 성공적으로 도입할 경우, 첫 리뷰까지 걸리는 시간(Time to first review)과 전체 PR 사이클 타임(PR cycle time)이 단축되어 최대 40%까지 리뷰 주기를 줄일 수 있습니다 [20, 21]. 결과적으로 PR 백로그가 누적되는 것을 막고 배포 빈도(Deployment frequency)를 높이며, 병합 후 발생하는 재작업(Post-merge rework) 및 핫픽스 비율을 낮추는 데 직접적으로 기여합니다 [20-22].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Code Review]], [[Static Application Security [[Testing]] (SAST)]], Continuous Integration/Continuous Deployment (CI/CD)
|
||||
- **Projects/Contexts:** [[DevSecOps]], GitHub
|
||||
- **Contradictions/Notes:** 자동화 및 AI 도구는 PR 내에서 발생하는 문법 오류나 알려진 보안 취약점을 빠르게 찾아내고 수정 제안을 제공하지만, 비즈니스 로직이나 아키텍처, 코드의 근본적인 의도를 파악하는 데에는 한계가 있으므로, 중요하고 민감한 변경 사항에 대해서는 인간 개발자의 수동 PR 리뷰가 반드시 병행되어야 합니다 [3, 8, 23].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-RAG-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, llm, rag, information-retrieval, ai-accuracy]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[RAG (검색 증강 생성)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "오픈 북 시험을 치는 AI: 모든 정보를 다 외우게 시키는 대신, 질문을 받으면 관련된 문서를 실시간으로 찾아 읽고 답변하게 하여 할루시네이션(환각)을 획기적으로 줄이는 기술."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
RAG(Retrieval-Augmented Generation)는 사전에 학습된 언어 모델(LLM)에 외부의 최신 데이터나 전문 지식을 실시간으로 연결하여 답변의 정확성을 높이는 프레임워크입니다.
|
||||
|
||||
1. **작동 프로세스**:
|
||||
* **Retrieval (검색)**: 유저의 질문과 가장 관련성 높은 지식 조각들을 벡터 데이터베이스 등에서 추출.
|
||||
* **Augmentation (증강)**: 추출된 문서를 질문과 섞어서 LLM에게 '참고할 배경 지식'으로 제공.
|
||||
* **Generation (생성)**: LLM이 제공된 정보를 바탕으로 근거 있는 답변 생성.
|
||||
2. **핵심 이점**:
|
||||
* **최신성 확보**: 모델을 다시 학습([[Fine-tuning]])시키지 않고도 어제 일어난 뉴스나 사내 최신 문서를 기반으로 답변 가능.
|
||||
* **환각 증상 감소**: "내가 아는 바에 따르면"이 아니라 "제시된 문서에 따르면" 답변하므로 오류가 눈에 띄게 줄어듦.
|
||||
* **출처 제시**: 답변의 근거가 된 문서 링크나 인용구를 함께 제공하여 신뢰성 확보.
|
||||
3. **한계점**:
|
||||
* 검색 단계에서 잘못된 문서를 가져오면(IR Failure) 답변도 망가짐. 이를 위해 검색 성능 최적화가 필수적임.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 초기 LLM은 '외운 것'으로만 답하게 하려 했으나, 정보의 방대함과 변화 속도를 감당할 수 없어 현대 기업용 AI 구축의 표준은 'RAG-First' 정책으로 완전히 전환됨.
|
||||
- **정책 변화(RL Update)**: 민감한 사내 문서가 RAG 과정에서 외부망(Public LLM API)으로 유출될 위험이 제기됨에 따라, '로컬 벡터 스토어'와 '격리된 LLM 연계'를 강제하는 엔터프라이즈 AI 보안 정책이 강화됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Foundational Models, [[SFT (Supervised Fine-Tuning)]], Vector Semantics, Information Extraction (IE), Semantic Grounding Provenance
|
||||
- **Modern Tech/Tools**: Pinecone, Milvus, [[LlamaIndex]], LangChain.
|
||||
---
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: FE-REACT-CONTEXT-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [react, context-api, [[State]]-[[Management]], prop-drilling, [[Dependency-Injection]], performance]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# React [[Context API]] (리액트 컨텍스트 API)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "컴포넌트 트리의 깊은 곳까지 데이터를 전달하기 위한 '[[Prop Drilling]]'의 터널을 뚫고, 전역적인 데이터를 필요한 곳에서 즉시 구독할 수 있는 직통 라인을 개설하라" — 중첩된 컴포넌트 간의 데이터 공유를 단순화하는 React 내장 상태 관리 메커니즘.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Implicit Dependency Injection" — 명시적으로 props를 전달하는 대신, Provider를 통해 상위 트리에서 데이터를 제공하고 Consumer(또는 `useContext`)를 통해 하위 트리 어디에서든 데이터를 소비하는 패턴.
|
||||
- **주요 활용 사례:**
|
||||
- **Theming:** 라이트/다크 모드 등 UI 테마 정보 공유.
|
||||
- **Authentication:** 사용자 로그인 상태 및 권한 정보 유지.
|
||||
- **Localization:** 언어 설정 및 번역 함수 제공.
|
||||
- **주의사항 및 한계:**
|
||||
- **Re-rendering Issue:** Context 값이 변경되면 해당 Context를 구독하는 모든 하위 컴포넌트가 리렌더링됨. 잦은 업데이트가 발생하는 상태에는 부적합.
|
||||
- **Complexity:** 무분별한 Context 사용은 컴포넌트의 재사용성을 저해하므로, 합리적인 수준의 'Prop Drilling'이나 '컴포넌트 합성'과 균형을 맞춰야 함.
|
||||
- **의의:** 외부 상태 관리 라이브러리(Redux, Zustand 등) 없이도 컴포넌트 간 결합도를 낮추고 데이터 흐름을 단순화함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거에는 Context API를 '전역 상태 관리 도구'로 홍보했으나, 현대 정책은 '의존성 주입(DI) 도구'로 명확히 정의함. 성능 이슈로 인해 빈번한 상태 변경에는 Zustand나 Recoil 같은 전문 라이브러리 사용을 권장하는 정책으로 전향함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 정적인 전역 데이터(테마, 설정)에 대해서만 Context API 사용을 허용하며, 동적인 비즈니스 상태는 전역 상태 관리 라이브러리 사용을 의무화함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[React-Hooks]], [[State-Management-Patterns]], [[Component-Composition]], Performance-[[Optimization]]
|
||||
- **Raw Source:** 00_Raw/[[React Context API]].md
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: FE-REACT-HOOKS-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [react, [[Frontend]], hooks, [[Functional-Programming]], [[State]]-[[Management]], useEffect, useState]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# React Hooks (리액트 훅)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "클래스의 복잡한 생명주기(Lifecycle)를 직관적인 함수의 흐름으로 평탄화하고, 컴포넌트 간 상태 로직을 마법처럼 공유하라" — React 16.8부터 도입된, 함수형 컴포넌트에서도 상태와 생명주기 기능을 사용할 수 있게 해주는 혁신적인 API.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "[[Logic]] Decoupling and Composition Over Inheritance" — UI 렌더링과 비즈니스 로직을 분리하고, 커스텀 훅(Custom Hooks)을 통해 반복되는 로직을 독립적인 단위로 재사용하는 패턴.
|
||||
- **주요 훅과 역할:**
|
||||
- **useState:** 컴포넌트 내의 로컬 상태 관리.
|
||||
- **useEffect:** API 호출, 이벤트 리스너 등 사이드 이펙트(Side Effects) 처리 및 클린업.
|
||||
- **useMemo / useCallback:** 불필요한 연산과 리렌더링을 방지하는 메모이제이션(Memoization).
|
||||
- **useContext:** 전역 상태 공유를 위한 [[Context API]] 접근.
|
||||
- **의의:** 기존 HOC(High-Order Components)나 [[Render Props]] 방식의 'Wrapper Hell' 문제를 해결하고, 코드의 가독성과 테스트 가능성을 비약적으로 향상시킴.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 초기에는 모든 최적화에 `useMemo` 등을 남발했으나, 최근 [[React Compiler]](React Forget)의 등장으로 수동 최적화의 필요성이 줄어들고 있으며, 훅은 오직 최상위 레벨에서만 호출되어야 한다는 'Rules of Hooks' 정책이 더욱 엄격해짐.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 신규 프런트엔드 모듈에 함수형 컴포넌트와 훅 아키텍처를 강제하며, 복잡한 데이터 페칭 로직은 반드시 커스텀 훅으로 추상화하여 관리함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- React-[[Architecture]], [[Functional-Programming]], [[State-Management-Patterns]], SOLID-[[Principles]]-in-React
|
||||
- **Raw Source:** 00_Raw/React Hooks.md
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-REPR-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, software-engineering, rx, asynchronous, event-driven]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Reactive-Programming]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터의 흐름에 몸을 맡겨라: 변화가 일어날 때까지 기다리지 않고, 데이터라는 '스트림'이 흐를 때마다 연결된 로직들이 자동으로 반응하게 만드는 선언적 비동기 프로그래밍 패러다임."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
리액티브 프로그래밍(Reactive Programming)은 데이터 스트림과 변경 전파를 중심으로 하는 프로그래밍 패러다임입니다.
|
||||
|
||||
1. **핵심 개념**:
|
||||
* **Streams (Observable)**: 시간이 지남에 따라 발생하는 이벤트들의 연속적인 흐름.
|
||||
* **Obversers**: 스트림을 관찰하다가 값이 들어오면 로직 실행.
|
||||
* **[[Opera]]tors**: 스트림을 필터링, 변형, 결합하는 함수 (Map, Filter, Merge 등).
|
||||
2. **프로그래밍 스타일**:
|
||||
* **Imperative (명령형)**: "A = B + C" (나중에 B나 C가 바뀌어도 A는 그대로).
|
||||
* **Reactive (반응형)**: "A는 언제나 B + C의 결과이다" (B나 C가 바뀌면 A도 즉시 업데이트됨).
|
||||
3. **장점**:
|
||||
* **비동기 처리 간소화**: 콜백 지옥(Callback Hell) 탈출.
|
||||
* **반응성 향상**: 유저 인터랙션이나 네트워크 요청이 많은 환경에서 부드러운 UX 제공.
|
||||
* **탄력성**: 데이터 부하 급증 시 배압(Backpressure) 조절을 통해 시스템 안정성 유지.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 이전에는 정적인 상태 관리만으로 충분했으나, 실시간 서비스와 복잡한 프론트엔드 환경이 대세가 되며 리액티브 방식이 대규모 시스템 설계의 필수가 됨.
|
||||
- **정책 변화(RL Update)**: 고성능 서버 환경에서 자원을 낭비하는 전통적 [[Blocking]] 방식 대신, 자원을 효율적으로 점유하는 'Non-blocking 리액티브 선언문'을 표준 코딩 규약으로 채택하는 정책이 확산됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Software-Design-Principles]], [[Event-Driven-Architecture]], [[Functional Programming]], User Experience (UX)
|
||||
- **Modern Tech/Tools**: RxJS, React ([[State]]-driven UI), Project Reactor, Akka.
|
||||
---
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-4C10C5
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[SAST]] (정적 애플리케이션 보안 테스트)"
|
||||
---
|
||||
|
||||
# [[SAST (정적 애플리케이션 보안 테스트)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> SAST(정적 애플리케이션 보안 테스트)는 애플리케이션을 실행하지 않고 소스 코드나 바이트코드 자체를 분석하여 잠재적인 보안 취약점을 찾아내는 화이트박스 테스트(White-box [[Testing]]) 기법입니다 [1]. 소프트웨어 개발 수명 주기(SDLC)의 초기 단계에 통합되어 결함을 사전에 식별하고 조치함으로써 보안 문제를 빠르고 저렴하게 해결하는 '시프트 레프트([[Shift]]-Left)' 접근법의 핵심입니다 [2-4]. 최근에는 전통적인 규칙 기반의 한계를 극복하기 위해 머신러닝과 LLM을 결합하여 코드의 문맥을 이해하고 오탐을 줄이는 AI 기반 SAST로 발전하고 있습니다 [5, 6].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **탐지 영역 및 작동 방식:** SAST는 코드가 실행되기 전 구문, 구조, 제어 및 데이터 흐름을 정적으로 분석합니다 [1, 7]. 이 검사를 통해 SQL 인젝션, 크로스 사이트 스크립팅(XSS), 하드코딩된 민감정보(비밀번호 및 API 키), 경로 탐색, 불충분한 입력 검증 등 다양한 보안 결함을 식별합니다 [2, 8, 9].
|
||||
* **주요 이점:**
|
||||
* **빠르고 독립적인 분석:** 테스트 케이스를 설계하거나 애플리케이션을 실행할 필요가 없어 전체 코드베이스를 신속하게 스캔할 수 있습니다 [10].
|
||||
* **정확한 위치 안내:** 취약점이 발생한 소스 코드의 정확한 파일 및 줄 번호와 데이터 흐름을 짚어주어 개발자가 즉각적으로 문제를 파악하고 수정할 수 있도록 돕습니다 [10].
|
||||
* **전통적인 SAST의 한계점:**
|
||||
* 애플리케이션 실행 런타임의 컨텍스트나 비즈니스 로직의 의도를 완벽히 이해하지 못하기 때문에 다수의 오탐(False Positives)과 미탐(False Negatives)을 발생시킵니다 [11].
|
||||
* 분석이 사용된 특정 프로그래밍 언어의 지원 여부에 크게 종속된다는 단점이 있습니다 [11].
|
||||
* **AI 네이티브(AI-native) SAST의 등장:**
|
||||
* 기존의 단순 패턴 매칭 규칙을 넘어 머신러닝을 도입한 최신 SAST 엔진(예: Snyk Code의 [[DeepCode AI]], [[Corgea]] 등)은 수백만 건의 실제 오픈소스 커밋과 수정 패턴을 학습하여 코드의 의미를 파악합니다 [6, 12, 13].
|
||||
* 여러 모듈이나 함수 경계를 넘어 데이터를 추적하는 파일 간 분석(Interfile [[Analysis]])이 가능해졌으며, 탐지된 취약점에 대해 AI가 자동 수정 코드(Auto-remediation)를 제안하고, 개발자에게 불필요한 경고를 줄여줍니다 [14-17].
|
||||
* **타 보안 테스트와의 연계:** SAST는 작동 중인 애플리케이션 외부에서 런타임 문제를 진단하는 DAST(동적 애플리케이션 보안 테스트), 서드파티 오픈소스 라이브러리의 취약점을 스캔하는 SCA(소프트웨어 구성 분석) 등과 함께 사용될 때 상호 보완적으로 전체 애플리케이션 보안을 극대화할 수 있습니다 [7, 18-20].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[DAST (동적 애플리케이션 보안 테스트)]], [[SCA (소프트웨어 구성 분석)]], [[시프트 레프트 (Shift-Left)]], 오탐 (False Positive), [[코드 리뷰 ([[Code Review]])]]
|
||||
- **Projects/Contexts:** Snyk Code, [[Corgea]], [[SonarQube]], [[소프트웨어 개발 수명 주기 (SDLC)]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 수동 코드 리뷰는 문맥과 비즈니스 로직, 아키텍처를 깊이 이해하지만 속도가 느리고 비용이 큰 반면, 자동화된 SAST 도구는 매우 빠르고 일관적이지만 코드의 의도를 파악하지 못해 오탐이 발생한다는 뚜렷한 대비가 있습니다 [21-23]. 이에 따라 2025년의 모범 사례는 SAST와 같은 자동화 스캔 도구로 코드 스타일과 일반적인 보안 결함을 1차적으로 걸러내고, 인간 검토자는 자동화가 놓치는 핵심 로직 및 크로스 서비스 영향도 평가에 집중하는 '하이브리드 코드 리뷰' 모델을 채택하는 것입니다 [21, 24, 25].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-8D39DE
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[SAST]] (정적 애플리케이션 보안 테스팅)"
|
||||
---
|
||||
|
||||
# [[SAST (정적 애플리케이션 보안 테스팅)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> SAST(정적 애플리케이션 보안 테스팅)는 애플리케이션을 실행하지 않고 소스 코드나 바이트코드를 정적으로 분석하여 보안 취약점을 찾아내는 '화이트박스 테스팅' 기법입니다 [1, 2]. 개발 초기 단계(CI/CD 파이프라인이나 IDE)에 통합되어 취약점이 프로덕션 환경에 도달하기 전에 예방하는 [[Shift]]-Left 보안을 실현합니다 [3, 4]. 최근에는 규칙 기반 패턴 매칭의 한계를 넘어, 대형 언어 모델(LLM)과 기계 학습(ML)을 결합하여 문맥을 이해하고 자동으로 코드를 수정해주는 AI 기반 SAST로 진화하고 있습니다 [5-7].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **작동 방식 및 주요 탐지 영역:**
|
||||
SAST 도구는 소스 코드를 파싱하여 구문 트리(Syntax Tree)를 구축한 후, 의미론(Semantic), 제어 흐름(Control flow), 데이터 흐름(Data flow), 구조적 분석 등을 적용하여 잠재적 문제를 탐지합니다 [8-10]. 이를 통해 인젝션 결함(SQL, NoSQL, Command 등), 크로스 사이트 스크립팅(XSS), 경로 탐색, 하드코딩된 자격 증명(비밀번호, API 키), 취약한 암호화, 메모리 관리 문제, 잘못 구성된 설정 등을 찾아냅니다 [1, 2, 11].
|
||||
* **SAST의 주요 장점:**
|
||||
SAST는 코드를 실행하거나 별도의 테스트 케이스를 작성할 필요가 없으며, 개발자가 코드를 작성하는 즉시 실시간(Real-time)으로 매우 빠르게 스캔할 수 있습니다 [12, 13]. 문제가 있는 코드의 정확한 위치와 데이터 흐름을 짚어주기 때문에 취약점을 조기에 수정할 수 있어 시간과 비용을 크게 절약합니다 [13, 14].
|
||||
* **기존 SAST의 한계점:**
|
||||
기존 SAST 도구들은 실행 런타임의 컨텍스트나 비즈니스 로직의 의도를 온전히 파악하지 못해 오탐지(False Positive)를 많이 발생시키며(일부 레거시 도구의 경우 50~80%), 이로 인해 개발자가 알림 피로도(Alert fatigue)를 느끼게 됩니다 [15, 16]. 또한, 특정 프로그래밍 언어에 대한 의존성이 강하며, 프론트엔드와 백엔드를 오가는 복잡한 데이터 흐름을 완벽히 쫓아가지 못하는 한계가 있습니다 [9, 16].
|
||||
* **AI 기반 SAST의 등장:**
|
||||
최근의 SAST는 단순한 정적 패턴 매칭을 넘어 LLM 등 AI 엔진을 도입하여 맥락을 이해하는 방향으로 발전하고 있습니다 [3, 5]. AI 기반 SAST(예: [[Corgea]], Snyk Code 등)는 규칙만으로는 표현할 수 없는 복잡한 비즈니스 로직의 결함을 탐지하고, 오탐을 크게 줄여줍니다 [6, 7, 17]. 나아가 식별된 문제에 대해 실행 가능한 코드 패치(Auto-fix)를 자동으로 제안하고 검증하는 기능까지 제공합니다 [5, 18].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** DAST (동적 애플리케이션 보안 테스팅), [[SCA (소프트웨어 구성 분석)]], AI-powered SAST, [[수동 코드 리뷰 (Manual [[Code Review]])]]
|
||||
- **Projects/Contexts:** Shift-Left 보안, CI/CD 및 IDE 통합, [[OWASP Top 10]]
|
||||
- **Contradictions/Notes:** 자동화된 SAST는 매우 빠르고 일관되게 코드를 검사하지만 비즈니스 로직과 의도를 파악하는 데는 맹점이 존재하므로(Context Blindness), 런타임 환경을 분석하는 DAST 또는 설계와 맥락을 깊이 이해하는 수동 코드 리뷰(Manual Review)와 결합된 하이브리드 접근 방식이 권장됩니다 [15, 19, 20].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: DL-SCHED-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, [[Deep-Learning]], [[Optimization]], scheduler, learning-rate, hyper[[Parameter]]-tuning, training-[[Efficiency]]]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Scheduler Design in ML (ML에서의 스케줄러 설계)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "학습 초기에는 대담한 탐색(High LR)을 장려하고, 종단에는 정밀한 수렴(Low LR)을 유도하여 모델의 잠재력을 마지막 한 방울까지 쥐어짜라" — 학습 과정 중에 학습률(Learning Rate)이나 자원 배분을 동적으로 변경하여 학습의 안정성과 최종 성능을 최적화하는 전략적 설계.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Decaying Learning Rate and Convergence Optimization" — 학습이 진행됨에 따라 오차가 줄어드는 속도를 감시하고, 사전에 정의된 정책(Schedule)에 따라 학습률을 점진적으로 낮춤으로써 지역 최적해(Local Minima)를 탈출하거나 전역 최적해에 부드럽게 안착시키는 패턴.
|
||||
- **주요 스케줄러 기법:**
|
||||
- **Step Decay:** 정해진 에포크(Epoch)마다 학습률을 일정 비율로 축소.
|
||||
- **Cosine Annealing:** 코사인 함수 곡선을 따라 학습률을 부드럽게 낮춤. 최근 가장 널리 쓰임.
|
||||
- **ReduceLROnPlateau:** 성능 향상이 멈췄을 때만 지능적으로 학습률 인하.
|
||||
- **Warm-up:** 초기 불안정성을 막기 위해 아주 작은 학습률에서 시작해 점차 높이는 과정.
|
||||
- **의의:** 고정된 학습률(Fixed LR)을 쓸 때보다 훨씬 빠르게 수렴하며, 모델이 가질 수 있는 최상의 정확도에 도달하게 하는 결정적 '디테일'의 영역.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순히 학습률을 낮추기만 하는 것이 정답이라던 과거와 달리, 이제는 학습률을 다시 높였다가 낮추는 'Cyclical Learning Rates' 방식이 안장점(Saddle Point) 탈출에 더 효과적임이 밝혀져 적극 도입되고 있음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 대규모 모델 미세 조정 시, 학습 초기 발산을 방지하기 위한 Linear Warm-up과 최종 수렴 극대화를 위한 Cosine Decay 스케줄러를 표준 조합으로 사용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Optimization-Algorithms]], Adam-Optimizer-Foundations, Hyperparameter-Tuning-Best-Practices, Deep-Learning-Foundations
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Scheduler-Design-in-ML.md
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
id: SENSOR-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [[[Robotics]], autonomous-driving, data-fusion, ai, signal-[[Processing]]]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Sensor Fusion (센서 퓨전)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "여러 개의 감각을 하나로 합쳐 완벽한 세상을 그려라" — 서로 다른 특성을 가진 여러 센서(카메라, 라이다, 레이더 등)의 데이터를 통합하여, 개별 센서만으로는 알 수 없었던 정확하고 신뢰성 높은 정보를 도출하는 기술.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 각 센서의 장점은 취하고 단점(노이즈, 사각지대)은 상호 보완하여, 시스템의 상황 인지(Context Awareness) 능력을 극대화하는 멀티모달 통합 패턴.
|
||||
- **세부 내용:**
|
||||
- **Complementary Data:** 카메라는 형상을, 라이다는 거리를 잘 파악하듯 서로 다른 유형의 정보를 결합.
|
||||
- **Redundancy:** 하나의 센서가 고장 나거나 오작동해도 다른 센서를 통해 안전성 유지.
|
||||
- **Kalman Filter:** 예측과 관측값을 확률적으로 결합하여 동적인 상태를 추정하는 핵심 알고리즘.
|
||||
- **Early vs Late Fusion:** 원시 데이터를 바로 합칠지(Early), 각자 분석한 결과물(Object)을 나중에 합칠지(Late) 결정.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순한 값의 평균을 내던 수준에서, 최근에는 딥러닝 기반의 엔드투엔드(End-to-End) 특징 맵 퓨전 방식으로 고도화됨.
|
||||
- **정책 변화:** Skybound 프로젝트의 에이전트 인식 시스템 설계 시, 시각 센서와 청각(발소리) 센서 데이터를 퓨전하여 적의 위치를 정밀하게 추적하는 로직을 적용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Autonomous-Driving, [[Computer-Vision]], Kalman-Filter, Context-Awareness
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Sensor-Fusion.md
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-95EC02
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Static Application Security [[Testing]] ([[SAST]])"
|
||||
---
|
||||
|
||||
# [[Static Application Security Testing (SAST)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> Static Application Security Testing(SAST)는 애플리케이션을 직접 실행하지 않고 소스 코드나 바이트코드를 분석하여 잠재적인 보안 취약점과 결함을 찾아내는 화이트박스 테스트(white-box testing) 기법입니다 [1, 2]. 이 방식은 소프트웨어 개발 수명 주기(SDLC)의 초기 단계에 적용되어 코드가 배포되기 전에 문제를 식별하고 수정할 수 있게 해줍니다 [1, 3, 4]. 최근에는 인공지능(AI)과 기계 학습(ML) 기술이 결합되어 전통적인 규칙 기반 탐지의 한계를 넘어 코드의 문맥을 이해하고, 자동으로 수정 코드를 제안하는 수준으로 진화하고 있습니다 [5-7].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **작동 원리 및 주요 탐지 영역:** SAST는 코드의 구조와 구문을 분석하며, 데이터 흐름(Data flow), 테인트 분석(Taint tracking) 및 의미론적 분석을 수행하여 외부에서 유입된 신뢰할 수 없는 데이터가 안전하게 처리되는지 추적합니다 [2, 8, 9]. 이를 통해 SQL 주입(SQL Injection), 크로스 사이트 스크립팅(XSS), 경로 탐색(Path traversal), 하드코딩된 비밀번호(Secrets) 등 [[OWASP Top 10]]에 해당하는 주요 보안 취약점을 탐지합니다 [10, 11].
|
||||
* **개발 워크플로우 통합 ([[Shift]]-Left 전략):** SAST의 가장 큰 장점 중 하나는 개발 초기에 보안을 내재화하는 'Shift-Left' 접근법을 가능하게 한다는 것입니다 [12-14]. IDE(통합 개발 환경), 풀 리퀘스트(Pull Request), CI/CD 파이프라인 등 개발자의 기존 워크플로우에 긴밀하게 통합되어 실시간 피드백을 제공하므로, 취약점을 발견하고 수정하는 데 드는 비용과 시간을 크게 절감할 수 있습니다 [15-20].
|
||||
* **전통적 SAST의 장점과 한계:** 앱을 실행할 필요가 없고, 테스트 케이스를 작성하지 않아도 전체 코드베이스를 검사할 수 있으며 자동화가 용이합니다 [19]. 더불어 PCI, OWASP, CWE 등 산업 표준 규정 준수를 증명하는 데 기여합니다 [11, 21]. 반면 런타임 컨텍스트가 부족하여 오탐률(False Positive)이 높을 수 있고(기존 도구의 경우 50~80%에 달함), 지원하는 프로그래밍 언어에 대한 의존성이 존재한다는 단점이 있습니다 [22-24].
|
||||
* **AI 기반 SAST의 등장:** 최근에는 Snyk Code, [[Corgea]] 등 거대 언어 모델(LLM)과 기계 학습을 도입한 차세대 SAST 도구들이 등장했습니다 [6, 7, 18, 22]. 이들은 파일 간 분석(Interfile [[Analysis]])을 통해 여러 모듈에 걸친 취약점을 추적하고 의미론적으로 코드를 이해함으로써 오탐률을 줄입니다 [25, 26]. 뿐만 아니라, 개발자가 즉각적으로 적용할 수 있는 자동 수정 코드(Auto-fix)까지 생성하여 신속한 조치를 돕습니다 [6, 27-30].
|
||||
* **타 보안 테스트 도구와의 차이점:** 실행 중인 상태의 애플리케이션을 외부에서 블랙박스 형태로 테스트하는 DAST(Dynamic Application Security Testing)와 대조적입니다 [1, 31]. 또한 서드파티 오픈소스 라이브러리의 알려진 취약점(CVE)과 라이선스를 검사하는 SCA(Software Composition Analysis)와 달리, SAST는 개발 팀이 직접 작성한 1사(자체) 소스 코드 내의 로직 결함을 찾아내는 데 집중합니다 [32, 33].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** Dynamic Application Security Testing (DAST), Software Composition Analysis (SCA), Shift-Left, False Positives, [[Artificial Intelligence (AI)]] [[Code Review]]
|
||||
- **Projects/Contexts:** 소프트웨어 개발 수명 주기(SDLC) 내에서 보안을 강화하기 위해 CI/CD 파이프라인, IDE 플러그인, Pull Request 등에 연동하여 사용되는 맥락을 가집니다. 대표적인 도구로는 Snyk Code, [[Corgea]], [[SonarQube]], Checkmarx, Semgrep, Veracode, GitHub Advanced Security 등이 널리 사용되고 있습니다 [7, 18, 22, 27, 34-38].
|
||||
- **Contradictions/Notes:** 전통적인 정적 분석(SAST)은 빠르고 일관된 검사를 제공하지만, 비즈니스 로직에 대한 문맥 이해 부족과 높은 오탐률(False Positives)이라는 한계가 지적됩니다 [23, 24]. 이를 해결하기 위해 최근에는 사람이 판단을 내리는 수동 코드 리뷰(Manual Code Review)와 AI가 결합된 정적 분석을 혼합하여 사용하는 하이브리드(Hybrid) 접근 방식이 필수적인 보안 검토의 모범 사례로 권장되고 있습니다 [39-41].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
id: SUP-LEARN-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, machine-learning, [[Supervised-Learning]], foundations]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Supervised Learning Foundations (지도 학습 기초)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "정답지가 있는 데이터를 통해 문제와 해답 사이의 지도를 그려라" — 입력 데이터(Feature)와 정답(Label) 쌍을 학습하여, 새로운 입력이 들어왔을 때 정답을 예측하는 함수를 근사하는 가장 전형적인 머신러닝 방식.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 사람이 라벨링한 풍부한 예시 데이터를 바탕으로 데이터 간의 통계적 관계를 파악하고, 이를 통해 미지의 데이터에 대한 범주(Classification)나 수치(Regression)를 추론하는 패턴.
|
||||
- **핵심 요소:**
|
||||
- **Dataset:** 입력(X)과 정답(Y)의 쌍으로 구성된 데이터셋.
|
||||
- **Classification:** 이산적인 카테고리 중 하나로 분류 (예: 스팸 여부, 개/고양이 구분).
|
||||
- **Regression:** 연속적인 수치를 예측 (예: 집값 예측, 주식 가격 추이).
|
||||
- **Loss Minimization:** 모델의 예측값과 실제 정답 사이의 차이를 줄이는 방향으로 가중치 업데이트.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 초기 머신러닝의 주류였으나, 최근에는 막대한 양의 라벨링 비용 문제 때문에 자기 자기 지도 학습(Self-supervised Learning)과 상호 보완적인 관계로 발전 중.
|
||||
- **정책 변화:** Antigravity 프로젝트는 문서 분류 및 감성 분석 등 명확한 기준이 필요한 태스크에 고도로 정제된 지도 학습 모델을 활용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Machine-Learning, [[Deep-Learning]], [[Objective-Functions]], [[Gradient-Descent]]
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Supervised-Learning (지도 학습 기초).md
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: SYS-DESIGN-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [systems, [[Architecture]],[[ system]]-design, software-engineering, [[Scalability]], [[Reliability]], [[Modularity]]]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# System Architecture Design (시스템 아키텍처 설계)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드를 한 줄 적기 전에 시스템의 '영혼(Core [[Logic]])'과 '육체(Infrastructure)'가 어떻게 대화할지 청사진을 그리고, 변화의 파도에도 무너지지 않는 유연한 골격을 완성하라" — 소프트웨어 시스템의 전체 구조와 구성 요소 간의 관계를 정의하여 요구사항을 충족시키고 지속 가능성을 확보하는 고차원 설계 공정.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Hierarchical Decomposition and Interface-driven Interaction" — 거대한 요구사항을 관리 가능한 작은 모듈로 쪼개고, 각 모듈 간의 소통 방식을 표준화된 인터페이스로 정의하여 독립적인 개발과 확장이 가능하게 만드는 패턴.
|
||||
- **핵심 설계 원칙:**
|
||||
- **Scalability:** 사용자가 늘어남에 따라 자원을 유연하게 늘릴 수 있는가? (Horizontal vs Vertical).
|
||||
- **Reliability:** 특정 부품이 고장 나도 전체 시스템이 멈추지 않는가? (Fault Tolerance).
|
||||
- **Modularity:** 기능을 독립적으로 떼어내어 재사용하거나 교체할 수 있는가?
|
||||
- **Performance:** 지연 시간(Latency)과 처리량(Throughput) 사이의 최적점 찾기.
|
||||
- **의의:** 개발팀 전체의 북극성 역할을 하며, 초기 설계의 견고함이 향후 운영 비용의 90%를 결정짓는 소프트웨어 공학의 가장 결정적인 단계.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 모든 것을 미리 완벽하게 설계하려던 '빅 업프런트 디자인(BUFD)'에서 벗어나, 이제는 핵심 구조만 잡고 나머지는 실행하며 진화시키는 '진화적 아키텍처(Evolutionary Architecture)'와 '마이크로서비스' 기반의 점진적 고도화가 주류가 됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트 간의 유기적 협업과 지식 공유를 위해, 각 모듈이 독립적이면서도 강력하게 연결되는 '이벤트 기반 마이크로커널' 아키텍처를 표준 설계 지침으로 준수함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Software-Architecture-Patterns]], [[Scalability-in-AI-Systems]], [[Service-oriented-Architecture]], Reliability-Engineering
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/System-Architecture-Design.md
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-TRLE-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, transfer-learning, [[Deep-Learning]], knowledge-transfer, specialization]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Transfer Learning]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "남의 지식으로 내 문제 풀기: 밑바닥부터 새로 배우는 대신, 거대 데이터로 이미 훈련된 모델의 실력을 가져와 내 특수 분야에 맞춰 살짝 다듬어([[Fine-tuning]]) 압도적인 효율을 얻는 지식 전수법."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
전이 학습(Transfer Learning)은 한 도메인(Source)에서 학습한 지식을 다른 관련 도메인(Target)에 적용하여 학습 성능을 높이고 자원 소모를 줄이는 머신러닝 기법입니다.
|
||||
|
||||
1. **왜 필요한가?**:
|
||||
* **Data Scarcity**: 특정 분야(의료, 특수 제조 등)는 학습 데이터가 부족함.
|
||||
* **Computational Cost**: 거대 모델을 처음부터 학습시키는 데는 천문학적 비용 발생.
|
||||
2. **핵심 메커니즘**:
|
||||
* **Pre-training**: 대규모 일반 데이터(예: 인터넷 전체 텍스트, ImageNet)로 보편적 특징 학습.
|
||||
* **Feature Extraction**: 학습된 가중치(Weights) 일부를 골격으로 사용.
|
||||
* **Fine-tuning**: 하위 계층을 고정하거나 소폭 수정하며 내 데이터에 최적화.
|
||||
3. **가장 성공적인 사례**:
|
||||
* [[BERT]]/GPT (언어 이해 지식의 전이), ResNet (이미지 특징 추출 능력의 전이).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 전이 학습 시 지식의 왜곡이나 망각(Catastrophic Forgetting)이 큰 문제였으나, 현대 인프라 정책은 '어댑터(Adapter)'나 'LoRA'와 같은 모듈형 전이 정책을 통해 기존 지식은 보존하면서 효율적으로 확장하는 기술적 대안을 정착시킴(RL Update).
|
||||
- **정책 변화(RL Update)**: 기업 내부의 핵심 기술이 외부 모델에 '오염'되는 것을 막기 위해, 오픈 소스 기반 모델을 가져와 폐쇄망 내에서 전이 학습시키는 '프라이빗 AI 구축 정책'이 데이터 주권 보호의 핵심 전략으로 부상함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Foundational Models, [[SFT (Supervised Fine-Tuning)]], [[Resource-Management]], [[Neural-Symbolic-Integration]], [[Robotics]]
|
||||
- **Modern Tech/Tools**: Hugging Face [[Transformers]], [[LoRA (Low-Rank Adaptation)]], PyTorch/TensorFlow pre-trained models.
|
||||
---
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
id: TRANSFER-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, [[Deep-Learning]], transfer-learning, knowledge-sharing, [[Optimization]]]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Transfer Learning]] Foundations (전이 학습 기초)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "한 분야에서 얻은 지식을 다른 분야의 밑거름으로 써라" — 방대한 데이터로 미리 학습된 모델(Pre-trained model)의 지식을 가져와, 소량의 데이터만으로 새로운 태스크에서 고성능을 내는 학습 기법.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 밑바닥부터 학습하는 대신, 이미 검증된 특징 추출(Feature Extraction) 능력을 재사용하여 학습 시간과 비용을 획기적으로 줄이는 지식 전이 패턴.
|
||||
- **세부 내용:**
|
||||
- **Feature Extraction:** 기존 모델의 하위 레이어(일반적 특징)는 고정하고 상위 레이어만 새 태스크에 맞게 교체.
|
||||
- **[[Fine-tuning]]:** 기존 가중치를 초기값으로 사용하여 새로운 데이터로 전체 또는 일부를 미세 조정.
|
||||
- **Domain Adaptation:** 학습 데이터와 실제 적용 환경의 분포 차이를 줄이는 과정.
|
||||
- **Multimodal Transfer:** 텍스트 지식을 이미지 인식에 활용하는 등 서로 다른 도메인 간의 지식 공유.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 매번 새로운 모델을 만들어야 했던 방식에서, 거대 기반 모델(Foundation Model) 하나를 다양하게 변조하여 사용하는 방식으로 AI 생태계가 개편됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 특화 에이전트 개발 시, 기초 언어 모델을 기반으로 전이 학습과 PEFT를 결합하여 개발 생산성을 극대화함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Fine-Tuning]], [[Representation-Learning]], [[Parameter]]-Efficient-Fine-Tuning, [[Foundation-Models]]
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Transfer-Learning (전이 학습 기초).md
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: FE-DS-BASEWEB-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [uber, baseweb, [[Design-System]], react, overrides-pattern, [[Styletron]], [[Scalability]], [[Accessibility]]]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Uber Base Web]] Design[[ system]] (우버 베이스 웹 디자인 시스템)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "수백 개의 내부 앱을 일관된 디자인 언어로 통합하고, '오버라이드(Overrides)' 패턴을 통해 컴포넌트의 유연성과 API의 간결함 사이의 모순을 해결하라" — 우버에서 개발한, 극도의 커스터마이징과 접근성을 보장하는 엔터프라이즈급 React UI 프레임워크.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Granular Override and Observability-driven Governance" — 컴포넌트 내부의 모든 하위 요소에 접근할 수 있는 고유한 오버라이드 인터페이스를 제공하고, 시스템의 채택률을 데이터로 측정하여 디자인 품질을 관리하는 패턴.
|
||||
- **핵심 혁신 요소:**
|
||||
- **[[Overrides Pattern]]:** 'Prop Soup' 문제를 해결하기 위해 컴포넌트의 스타일과 구조를 하위 요소 단위로 정밀하게 조정할 수 있는 단일 prop 제공.
|
||||
- **Styletron Integration:** 런타임에 아토믹 CSS를 생성하여 성능을 최적화하고 스타일 충돌 방지.
|
||||
- **Design Observability:** 'Base Counter' 도구를 통해 실제 프로젝트에서의 컴포넌트 사용 비율을 측정하고 디자인 거버넌스 구현.
|
||||
- **Native Accessibility:** 키보드 내비게이션, 화면 판독기 호환성 및 ARIA 역할을 기본적으로 완벽 지원.
|
||||
- **의의:** 대규모 조직에서 개발 속도를 3배 향상시키고 시각적 불일치를 4배 감소시키는 등, 엔지니어링 효율성과 디자인 일관성의 양립 가능성을 증명함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거 UI 라이브러리는 모든 요구사항을 별도의 Prop으로 처리하려 했으나, Base Web 정책은 '오버라이드'라는 단일 통로를 통해 무한한 확장성을 제공하는 정책으로 전환함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 복잡한 [[SaaS]] 대시보드 구축 시 Base Web의 오버라이드 철학을 참고하며, 모든 디자인 시스템 컴포넌트에 대해 '사용자 정의 가능성(Customizability)' 점수를 매겨 관리함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Design-System]], [[Atomic-Styling-and-Design-Systems]], Web-Accessibility, Reusable-UI-Components, Scalable-UI-Systems
|
||||
- **Raw Source:** 00_Raw/Base Web.md
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-3862CA
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Web Performance [[Optimization]]"
|
||||
---
|
||||
|
||||
# [[Web Performance Optimization]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 웹 성능 최적화(Web [[Performance Optimization]])는 웹사이트가 사용자에게 얼마나 빠르게 느껴지는지(인지된 성능)를 측정하고 개선하는 과정이다 [1]. 느린 웹사이트는 사용자의 좌절감을 유발하고 이탈률을 높이며 검색 엔진 순위(SEO)에도 악영향을 미치므로, 코어 웹 바이탈([[Core Web Vitals]])과 같은 표준화된 지표를 바탕으로 로딩 속도, 상호작용성, 시각적 안정성을 최적화하는 것이 필수적이다 [1-5].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **주요 성능 측정 지표 (Core Web Vitals 등)**
|
||||
* Google은 사용자 경험을 측정하기 위해 LCP(Largest Contentful Paint, 최대 콘텐츠 렌더링 시간), INP(Interaction to Next Paint, 다음 페인트에 대한 상호작용), CLS(Cumulative Layout [[Shift]], 누적 레이아웃 이동)를 코어 웹 바이탈 지표로 사용한다 [2, 6].
|
||||
* INP는 첫 번째 상호작용만 측정하던 기존의 FID(First Input Delay)를 대체한 지표로, 페이지 방문 중 발생하는 모든 클릭이나 키보드 입력 등의 전체 지연 시간을 측정하여 더욱 현실적인 반응성을 반영한다 [7-10].
|
||||
* 이 외에도 TTFB(Time to First Byte), TTI(Time to Interactive), TBT(Total [[Blocking]] Time) 등의 보조 지표가 성능 평가에 활용된다 [11, 12].
|
||||
|
||||
* **데이터 수집 및 분석 방식**
|
||||
* **실험실 데이터(Lab Data):** [[Lighthouse]]나 WebPageTest와 같이 통제된 기기와 네트워크 환경에서 수집되는 합성 테스트(Synthetic [[Testing]]) 데이터로, 개발 과정에서 병목 현상을 디버깅하는 데 유용하다 [13-15].
|
||||
* **필드 데이터(Field Data):** [[CrUX]]([[Chrome]] User Experience Report)나 실제 사용자 모니터링(RUM) 도구를 통해 실제 사용자가 겪는 성능을 측정한 데이터이다 [16, 17]. 소수 예외 값에 의한 평균의 왜곡을 피하기 위해 중앙값(p50)이나 75백분위수(p75), 95백분위수 등을 기준으로 성능을 평가한다 [18-20].
|
||||
|
||||
* **일반적인 웹 성능 최적화 기법**
|
||||
* **[[JavaScript]] 및 메인 스레드 최적화:** 50ms를 초과하는 긴 작업([[Long Tasks]])을 작게 쪼개거나 웹 워커(Web workers)로 분리하고, 필수적이지 않은 JS의 로드를 지연(Defer)시켜야 한다 [21, 22]. Firefox 등에서 지원하는 [[Scheduler API]](`scheduler.yield()`)를 통해 브라우저 스케줄러에 제어권을 양보하여 상호작용 지연을 줄일 수도 있다 [23].
|
||||
* **이미지 및 렌더링 최적화:** WebP, AVIF, [[JPEG XL]] 등 효율적인 최신 이미지 포맷을 사용하고, 뷰포트 크기에 맞는 적절한 해상도를 제공해야 한다 [24-29]. 또한 화면 밖 콘텐츠의 렌더링을 건너뛰는 CSS `content-visibility` 속성을 활용하면 초기 렌더링 성능을 크게 높일 수 있다 [30, 31]. 강제 동기식 레이아웃([[Layout Thrashing]])을 유발하는 코드는 피해야 한다 [32, 33].
|
||||
* **추측 규칙(Speculation Rules):** 사용자가 링크에 마우스를 올리는 등의 상호작용 시, 향후 필요할 수 있는 리소스나 페이지를 미리 렌더링 및 로드하여 탐색 속도를 대폭 단축할 수 있다 [34, 35].
|
||||
|
||||
* **3D 웹 그래픽 ([[WebGL]] / [[WebGPU]]) 성능 최적화**
|
||||
* WebGL 환경에서는 CPU와 GPU 간의 통신과 상태 변경이 오버헤드를 유발하므로, 드로우 콜([[Draw Call]]s) 횟수를 최소화(배칭, 인스턴싱 등)하는 것이 모바일과 데스크톱 모두에서 성능을 높이는 핵심이다 [36-42].
|
||||
* WebGPU는 WebGL의 단일 스레드 구조를 벗어나 다중 스레드 명령 생성(Multi-threaded command generation)과 컴퓨트 셰이더([[Compute Shader]])를 제공한다 [43-45]. 이를 통해 입자 시뮬레이션, 3D 가우시안 스플래팅(3DGS)에서의 심도 정렬(Depth [[Sorting]]) 등 무거운 연산을 GPU로 완전히 오프로드하여 CPU 병목을 제거하고 수 배 이상의 프레임 속도 향상을 이끌어낼 수 있다 [45-51].
|
||||
* [[Cesium]]과 같은 3D 엔진은 씬(Scene)이 정적일 때 일정 프레임 속도로 계속 렌더링하는 대신, 카메라의 움직임이나 데이터 로드, 시간의 변화 등 꼭 필요할 때만 렌더링을 수행하는 명시적 렌더링(Explicit Rendering) 모드를 사용하여 유휴 상태의 CPU 사용량을 25%대에서 3%대로 크게 감소시켰다 [52-55].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Core Web Vitals]], Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, [[WebGPU]], [[WebGL]]
|
||||
- **Projects/Contexts:** [[Chrome DevTools]], [[Lighthouse]], Chrome User Experience Report, WebPageTest
|
||||
- **Contradictions/Notes:** FID(First Input Delay)는 사용자의 첫 번째 상호작용 지연 시간만을 측정하는 한계가 있어, 페이지 생명주기 전체의 모든 상호작용 응답성을 추적하는 INP로 대체되었다 [7-10]. 또한, WebGL은 단일 스레드 명령 제출 구조로 인해 GPU가 유휴 상태임에도 CPU 병목이 발생하는 한계가 있었으나, WebGPU는 다중 스레드 명령 생성과 컴퓨트 셰이더를 통해 이러한 아키텍처적 한계를 해결한다 [44, 45, 56-59].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user