[P-Reinforce] Global knowledge consolidation, massive deduplication (5,249 files), and high-density wikification (45 nodes)
This commit is contained in:
Antigravity Agent
@@ -1,47 +0,0 @@
|
||||
# Cognitive Load & Mental Models (인지 부하 및 멘탈 모델)
|
||||
|
||||
## 📌 Brief Summary
|
||||
인지 부하 이론(Cognitive Load Theory, CLT)과 멘탈 모델(Mental Models)은 소프트웨어 엔지니어가 복잡한 시스템을 파악하고 유지보수할 때 발생하는 내부적 지식 표상과 인지적 제약을 설명하는 핵심 이론입니다 [1, 5]. 인간의 제한된 '작업 기억(Working Memory)' 용량 내에서 소스 코드를 읽고 시스템의 의도를 재구성하는 과정은 본질적 복잡성과 구현상의 불필요한 복잡성 사이의 투쟁입니다 [1]. 성공적인 개발자는 파편화된 코드를 고수준의 기능적 단위로 '청킹(Chunking)'하여 견고한 멘탈 모델을 구축함으로써 대규모 시스템의 복잡도를 관리합니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. 인지 부하의 3대 유형 (Types of Cognitive Load)
|
||||
소프트웨어 개발 시 발생하는 인지적 노력은 다음 세 가지로 분류됩니다 [1]:
|
||||
* **본질적 부하 (Intrinsic Load):** 도메인 로직이나 알고리즘 자체가 가진 고유의 복잡성입니다. (예: 분산 합의 알고리즘 구현)
|
||||
* **외부적 부하 (Extraneous Load):** 조잡한 코드 명명, 파편화된 아키텍처, 문서 부재 등 구현 방식 때문에 발생하는 불필요한 인지적 소모입니다.
|
||||
* **관련적 부하 (Germane Load):** 시스템의 동작 원리를 내재화하고 지식 스키마(Schema)를 구축하는 데 투입되는 유익한 노력입니다.
|
||||
|
||||
### 2. 멘탈 모델의 계층 구조 (Hierarchy of Mental Models)
|
||||
개발자는 코드를 읽으며 두 가지 핵심 표상을 형성합니다 [1, 2, 5]:
|
||||
* **프로그램 모델 (Program Model):** 코드의 구문, 제어 흐름, 데이터 흐름 등 기술적 구현에 집중한 저수준 모델입니다. (상향식 접근법의 결과물)
|
||||
* **상황 모델 (Situation Model / Task Model):** 비즈니스 목적, 사용자 요구사항, 도메인 기능을 표현하는 고수준 모델입니다. (하향식 접근법의 결과물)
|
||||
* **매핑 계층 (Annotation Layer):** 프로그램 모델(How)과 상황 모델(Why) 사이의 연결 고리로, 이 연결이 명확할수록 코드의 '추적 가능성(Traceability)'이 높아집니다.
|
||||
|
||||
### 3. 복잡성 관리 도구 (Chunking & Beacons)
|
||||
* **청킹 (Chunking):** 여러 코드 요소를 '정렬 알고리즘', '인증 미들웨어'와 같이 하나의 추상화된 레이블로 묶어 작업 기억의 부하를 줄이는 기술입니다 [1].
|
||||
* **비컨 (Beacons):** 특정 기능을 암시하는 강력한 단서(예: `swap` 변수는 정렬을 암시)로, 개발자가 하향식 가설을 세울 때 지름길 역할을 합니다 [16, 17].
|
||||
|
||||
## ⚠️ Trade-offs & Caveats
|
||||
* **Clean vs. Traceable 코드의 긴장:** 고도로 모듈화된 '클린(Clean)' 코드는 개별 모듈의 본질적 부하를 줄여주지만, 실행 흐름을 파악하기 위해 수많은 파일을 넘나들어야 하므로 **외부적 인지 부하(Extraneous load)**를 급격히 높일 수 있습니다 [3, 4].
|
||||
* **비전형적 코드(Unplan-like)의 충격:** 관례를 무시한 코드는 개발자의 기존 스키마와 충돌하여 '인지적 불일치(Cognitive Dissonance)'를 유발하고 멘탈 모델 구축을 방해합니다 [18].
|
||||
* **리뷰 파편화:** 인지 부하 관리를 위해 PR을 작게 쪼개는 것은 개별 검토에는 유리하지만, 전체 시스템의 일관성(Big Picture)을 놓치게 만들 위험이 있습니다 [2].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[Program Comprehension Strategies]]: 멘탈 모델을 구축하기 위한 구체적인 하향식/상향식 탐색 전략을 다룹니다.
|
||||
- Information Foraging Theory (정보 탐색 이론): 최소한의 인지 노력으로 코드 내 비컨(단서)을 찾아 이동하는 인간의 행동 양식을 설명합니다.
|
||||
- Clean Architecture vs Traceable Code: 인지 부하 최적화와 아키텍처적 결합도 제거 사이의 트레이드오프를 심층 분석합니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
- AI 기반 자동 완성 도구가 제공하는 코드가 개발자의 '관련적 부하(Germane load)' 형성을 방해하여 장기적인 시스템 이해도를 떨어뜨리는가?
|
||||
- 가상현실(VR)이나 3D 시각화 도구가 텍스트 기반 코드보다 고수준 상황 모델 구축에 더 효과적인 인지 보조 수단이 될 수 있는가?
|
||||
- 마이크로서비스 환경에서 파편화된 상황 모델을 하나로 통합하기 위한 가장 효율적인 '비컨' 설계 전략은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **System Design:** 아키텍처 설계 시 'Clean'함뿐만 아니라 'Traceable'함(추적 용이성)을 동시에 고려하여 외부적 부하를 통제해야 합니다 [20, 32].
|
||||
- **Code Review:** 리뷰어의 인지 부하를 줄이기 위해 PR 본문에 'Specification(목적)'을 명확히 작성하여 구현부와의 매핑(Annotation)을 도와야 합니다 [5, 10].
|
||||
- **Documentation:** 문서는 단순히 코드를 설명하는 것이 아니라, 코드에서 읽기 어려운 '상황 모델(Why)'을 집중적으로 보완하는 역할을 해야 합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: FEA-001
|
||||
category: Unified
|
||||
confidence_score: 1.0
|
||||
tags: [engineering, simulation, [[Physics|Physics]], mathematics, cae]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Finite Element [[Analysis|Analysis]] (FEA, 유한 요소 해석)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "복잡한 전체를 단순한 조각으로 나누어 계산하라" — 복잡한 구조물의 물리적 거동을 무수히 작은 요소(Finite Elements)들의 연립 방정식으로 치환하여 수치적으로 해결하는 시뮬레이션 기법.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 연속적인 물리계를 이산적인 격자(Mesh)로 분할하고, 각 격자점(Node)에서의 물리량 변화를 계산하여 전체 시스템의 반응을 예측하는 수치 해석 패턴.
|
||||
- **세부 내용:**
|
||||
- **Meshing:** 기하학적 형상을 삼각형이나 사각형 등 단순한 요소로 나누는 과정. 격자가 세밀할수록 정확도가 높으나 연산 비용 증가.
|
||||
- **Boundary Conditions:** 하중, 구속 조건 등 실제 환경의 물리적 제약 사항을 수치 모델에 반영.
|
||||
- **Structural Analysis:** 응력, 변형률, 진동 등을 계산하여 구조물의 안전성과 내구성 검증.
|
||||
- **Multi-physics:** 열전달, 유체 흐름, 전자기장 등 다양한 물리 현상을 복합적으로 해석.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거에는 거대한 슈퍼컴퓨터에서만 가능했으나, GPU 가속 및 클라우드 컴퓨팅의 발전으로 데스크톱 환경에서도 고정밀 해석이 가능해짐.
|
||||
- **정책 변화:** Antigravity 프로젝트의 자산 설계 시, 가상 구조물의 물리적 타당성을 검토하기 위한 수치 해석 모델링의 기초 이론으로 활용.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** 10_Wiki/💡 Topics/AI
|
||||
- **Related:** Computational-Fluid-Dynamics, Numerical-Analysis, Simulation
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Finite-Element-Analysis.md
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-SORT-001
|
||||
category: Unified
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, sorting, algorithm, [[Efficiency|Efficiency]], data-organization, ordering]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Sorting|Sorting]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "혼돈을 질서로: 흩어진 데이터들을 가나다순이나 크기순으로 정렬하여, '이진 탐색(Binary [[Search|Search]])' 같은 초고속 알고리즘이 작동할 수 있는 최적의 무대를 마련해 주는 컴퓨터 과학의 가장 기초적이자 파괴적인 도구."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
정렬(Sorting)은 데이터를 특정한 기준(오름차순, 내림차순 등)에 따라 일정한 순서로 나열하는 과정입니다.
|
||||
|
||||
1. **대표 알고리즘과 효율성 ($O$)**:
|
||||
* **Quick/Merge Sort**: $O(n \log n)$ - 대규모 데이터 처리에 적합 (표준). (Efficiency와 연결)
|
||||
* **Bubble/Insertion Sort**: $O(n^2)$ - 작은 데이터나 이미 거의 정렬된 경우 사용.
|
||||
2. **왜 중요한가?**:
|
||||
* 정렬되지 않은 데이터에서 무언가를 찾는 것은 모래사장에서 바늘 찾기 정책이지만, 정렬된 데이터에서는 '절반씩 날려버리는(Divide and Conquer)' 마법 정책 같은 탐색이 가능해지기 때문임. ([[Scalability|Scalability]]의 기반)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 수동으로 알고리즘 정책을 골라 썼으나, 현대 정책은 데이터의 특성 정책을 AI가 파악해 가장 빠른 정렬 기법 정책을 동적으로 선택하는 '자율 정렬 정책'이나 메모리 계층 구조 정책을 극대화한 'Cache-aware 정렬 정책'으로 진화함(RL Update).
|
||||
- **정책 변화(RL Update)**: 이제는 단순 숫자 정렬 정책을 넘어, 벡터 공간 정책 내에서 의미적 유사성 정책에 따라 결과를 정렬해 상위권에 노출하는 '시맨틱 랭킹 정책'이 검색 지능의 핵심임. ([[Semantic-Search|Semantic-Search]]와 연결)
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Efficiency|Efficiency]], [[Scalability|Scalability]], [[Search|Search]], [[Semantic-Search|Semantic-Search]], [[Logic|Logic]], [[Optimization|Optimization]]
|
||||
- **Modern Tech/Tools**: Timsort (Python standard), Quicksort, [[Radix Sort|Radix Sort]] for GPUs.
|
||||
---
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-054
|
||||
category: Unified
|
||||
confidence_score: 0.96
|
||||
tags: [type theory, formal verification, typeSystem, compiler]
|
||||
last_reinforced: 2026-06-XX
|
||||
github_commit: "[P-Reinforce] Processed Type Theory."
|
||||
---
|
||||
|
||||
# [[Type Theory|Type Theory]] (타입 이론)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 프로그래밍 언어의 타입 시스템을 수학적 공리(Axiom)와 논리학에 기반하여 분석하고, 프로그램의 안전성과 정확성을 컴파일 타임에 증명하는 학문이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **정의:** 타입을 단순히 데이터의 분류를 넘어, 시스템이 가질 수 있는 '속성'과 '규칙'으로 바라보는 접근법이다. 프로그램의 정적 분석을 수학적 증명 과정으로 확장한다.
|
||||
- **주요 개념:**
|
||||
1. **타입 추론 (Type Inference):** 코드를 작성할 때 타입을 명시하지 않아도 컴파일러가 타입 규칙에 따라 자동으로 타입을 유추하는 능력.
|
||||
2. **계산 가능성(Computability) 및 안전성:** 타입 이론의 궁극적 목표는 프로그램이 어떤 조건에서도 예측 불가능한 오류 없이 동작함을 수학적으로 증명하는 것이다 (Formal Verification).
|
||||
3. **Advanced Features:** 고급 언어 기능인 추상 데이터 타입, 범주론적 접근 등은 컴파일러 설계 자체를 학문적으로 다룬다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 완벽한 타입 안전성(Type Safety)을 달성하는 것은 매우 어려우며, 실제 개발에서는 '실용적인 타협점' (예: Runtime Validation, Zod 사용)이 필요하다.
|
||||
- **정책 변화:** 타입 시스템은 언어 차원의 기능뿐만 아니라, 도메인 모델링(DDD)의 규칙을 코드로 강제하는 도구로 활용되어 그 가치가 극대화되고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Parent: Type Safety
|
||||
- Related: Formal Methods in Software Engineering , Algebraic-Data-Types , TypeScript Type System
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user