feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]
This commit is contained in:
@@ -1,10 +1,21 @@
|
||||
---
|
||||
type: meeting_minutes
|
||||
status: in_progress
|
||||
tags: [Sporty&Rich, Development, Schedule, Client, QA, Security, Biz]
|
||||
project: Sporty & Rich Virtual Store
|
||||
date: 2026-04-29
|
||||
created: 2026-04-29
|
||||
id: wiki-2026-0508-20260429-스포티앤리치-개발일정-회의록
|
||||
title: 20260429 스포티앤리치 개발일정 회의록
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: ["Sporty&Rich", Development, Schedule, Client, QA, Security, Biz]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 📑 [회의록] 스포티앤리치 전체 개발 일정 및 팀별 주요 업무 점검
|
||||
@@ -55,7 +66,73 @@ created: 2026-04-29
|
||||
---
|
||||
"조직이 시스템이다. 실질적인 결과물과 일정으로 증명한다." - P-Reinforce Logic 🫡🚩🐟
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Logic]]
|
||||
* [[P-Reinforce]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-HEALTH-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-acl-prevention
|
||||
title: ACL Prevention
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-HEALTH-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.89
|
||||
tags: [health, sports, injury, prevention]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "batch-reinforce-01"
|
||||
github_commit: batch-reinforce-01
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# ACL Injury Prevention [[Protocols|Protocols]]
|
||||
@@ -19,7 +27,7 @@ github_commit: "batch-reinforce-01"
|
||||
- 햄스트링 강화 및 콰드-햄스트링 균형 최적화.
|
||||
- 연령 및 성별에 따른 맞춤형 부상 방지 프로그램 설계.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 단순 근력 강화에서 움직임의 질(Quality of Movement) 중심 예방으로 진화.
|
||||
- **정책 변화:** 지식 연결성(w2) 관점에서 바이오메카닉과 스포츠 심리학의 연계성 강화.
|
||||
|
||||
@@ -27,3 +35,29 @@ github_commit: "batch-reinforce-01"
|
||||
- **Parent:** 10_Wiki/💡 Topics/Health
|
||||
- **Related:** [[Neuromuscular-Control|Neuromuscular-Control]], Sports-Science, [[Proprioception|Proprioception]]
|
||||
- **Raw Source:** 00_Raw/2026-04-20/ACL-Injury-Prevention-Protocols.md
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-36585B
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-adversarial-code-stylometry
|
||||
title: Adversarial Code Stylometry
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-36585B]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Adversarial Code Stylometry"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Adversarial Code Stylometry|Adversarial Code Stylometry]]
|
||||
@@ -19,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Adversarial Code Stylometry"
|
||||
* **방어 지원 도구 ([[StyleCounsel|StyleCounsel]]):** 개발자가 다른 이의 스타일을 모방하고 자신의 스타일을 난독화할 수 있도록 돕는 `StyleCounsel`과 같은 시스템이 개발되었습니다 [2, 12]. 이 도구는 랜덤 포레스트(Random Forest)와 같은 기계 학습 모델의 의사 결정 트리를 분석하여, 오분류를 유도할 수 있는 구체적이고 최소한의 코드 변경 사항(예: 특정 구문의 사용 빈도 조절 등)을 사용자에게 추천합니다 [2, 13, 14].
|
||||
* **코드 포매팅을 통한 프라이버시 보호막:** [[Prettier|Prettier]]나 Black 등과 같은 결정론적 코드 포매터(Formatter) 및 최소화(Minification) 도구를 적용하는 것만으로도 작성자 인식 정확도를 크게 떨어뜨릴 수 있습니다 [15, 16]. 연구에 따르면 코드 포매팅 적용 시 식별 정확도가 68%에서 53%로 하락하며, 최소화를 거치면 50%까지 떨어져 코드 문체론 분석에 대한 실질적인 프라이버시 보호막(Privacy shield) 역할을 수행합니다 [17-19].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -32,3 +43,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Adversarial Code Stylometry"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-ALRE-001
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-alternative-realities
|
||||
title: Alternative Realities
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ALRE-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced, alternative-realities, virtual-reality, multiverse, simulation-theory, digital-perception]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Alternative Realities|Alternative Realities]]
|
||||
@@ -24,7 +33,7 @@ last_reinforced: 2026-04-20
|
||||
3. **심리적/철학적 관점**:
|
||||
* **Simulation Theory**: 우리 우주 자체가 누군가에 의해 설계된 대안 현실일 수 있다는 가설.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 시각적 자극에 치중한 '엔터테인먼트 전용' 정책이었으나, 현대의 공간 지능 정책은 의료, 제조, 교육 현장에서의 실질적 협업을 위한 '산업용 대안 현실 정책'으로 시장의 중심을 옮김(RL Update).
|
||||
- **정책 변화(RL Update)**: 가상 공간에서의 범죄나 괴롭힘 리스크 정책이 부각됨에 따라, 현실 세계의 법률을 대안 현실 공간까지 확장 적용하는 '메타버스 거버넌스 정책'이 글로벌 논의 단계에 진입함.
|
||||
|
||||
@@ -32,3 +41,29 @@ last_reinforced: 2026-04-20
|
||||
- [[Visual-Effects-VFX|Visual-Effects-VFX]], Human-Computer Interaction (HCI), [[Aesthetic-Value|Aesthetic-Value]], Simulation Theory, [[Sociology of Knowledge|Sociology of Knowledge]]
|
||||
- **Modern Tech/Tools**: Apple Vision Pro, Meta Quest, [[Unity|Unity]]/Unreal Engine, Omniverse.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,51 +1,22 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-C8C70C
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Mega Batch - Wikified Analyze runtime performance"
|
||||
id: wiki-2026-0508-analyze-runtime-performance
|
||||
title: Analyze runtime performance
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 성능_프로파일링_및_메모리_관리_표준
|
||||
canonical_id: wiki-2026-0508-040
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Analyze runtime performance|Analyze runtime performance]]
|
||||
# Redirect
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 런타임 성능(Runtime performance) 분석은 페이지가 로드되는 시점이 아니라, 페이지가 실제로 실행되는 동안 어떻게 작동하는지 측정하고 평가하는 과정입니다 [1]. 개발자는 주로 [[Chrome DevTools|Chrome DevTools]]의 성능(Performance) 패널을 활용하여 페이지와 상호 작용하는 동안의 활동을 기록합니다 [1, 2]. 이를 통해 애니메이션 프레임 속도(FPS), CPU 과부하, 메인 스레드 병목 현상 등을 식별하여 전반적인 사용자 경험을 최적화할 수 있습니다 [3, 4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **측정 및 시뮬레이션 환경 설정:**
|
||||
* 런타임 성능은 [[Chrome|Chrome]] DevTools의 성능(Performance) 패널에서 기록(Record) 버튼을 눌러 캡처할 수 있습니다 [2, 5].
|
||||
* 데스크톱이나 랩톱에 비해 컴퓨팅 성능이 떨어지는 모바일 기기에서의 실행 환경을 모방하기 위해, 캡처 설정(Capture settings)에서 'CPU Throttling(CPU 스로틀링)'을 사용하여 CPU 속도를 4배(4x) 또는 20배(20x) 느리게 시뮬레이션할 수 있습니다 [6, 7].
|
||||
* 네트워크 조건 역시 스로틀링을 통해 느린 모바일 연결 상태로 테스트할 수 있습니다 [7].
|
||||
|
||||
* **FPS 및 CPU 활동 분석:**
|
||||
* 애니메이션 성능을 측정하는 주요 지표는 초당 프레임 수(FPS)이며, 60 FPS 달성을 목표로 합니다 [3]. FPS 차트 위에 빨간색 막대가 나타나면 사용자 경험을 해칠 만큼 프레임 속도가 떨어졌음을 의미합니다 [3].
|
||||
* CPU 차트가 여러 색상으로 꽉 차 있는 것은 녹화 시간 동안 CPU가 최대 용량으로 작업했음을 나타내며, 이는 성능 개선을 위해 수행하는 작업을 줄여야 한다는 신호입니다 [3].
|
||||
|
||||
* **메인 스레드 플레임 차트([[Flame Chart|Flame Chart]]) 해석:**
|
||||
* 메인(Main) 섹션은 메인 스레드에서 시간에 따라 발생한 활동을 플레임 차트 형태로 시각화합니다. x축은 시간을, y축은 호출 스택([[Call Stack|Call Stack]])을 나타내며, 상단에 위치한 이벤트가 하단의 이벤트를 호출한 원인입니다 [4, 8].
|
||||
* 50 밀리초(ms)를 초과하는 긴 작업(Long Task)에는 빨간색 삼각형 경고가 표시되며, 초과된 시간 부분은 빨간색으로 음영 처리되어 성능 저하를 일으키는 항목을 쉽게 파악할 수 있습니다 [4, 9].
|
||||
|
||||
* **병목 현상(Bottleneck) 식별:**
|
||||
* 하단의 요약(Summary) 탭은 선택된 구간의 활동 분류(렌더링, 스크립팅 등)를 보여주며, 가장 많은 시간을 소비한 작업 영역을 찾도록 돕습니다 [4, 10].
|
||||
* 예를 들어, 애니메이션 프레임 이벤트 내부에서 요소의 스타일을 변경한 후 즉시 위치를 쿼리할 경우 브라우저가 강제로 레이아웃을 다시 계산해야 하는 '강제 동기식 레이아웃(Forced synchronous layouts)'과 같은 문제를 식별할 수 있습니다 [4].
|
||||
* 특정 활동이나 이벤트를 클릭하면 연결된 소스 코드의 해당 줄로 직접 이동할 수 있어 디버깅에 유리합니다 [4, 11].
|
||||
|
||||
* **상세 탭을 통한 활동 분석:**
|
||||
* **Call tree 탭:** 가장 많은 작업을 유발한 루트 활동(root activities)을 확인할 수 있습니다 [12, 13].
|
||||
* **Bottom-up 탭:** 직접적으로 가장 많은 시간이 소요된 특정 활동들을 집계하여 보여줍니다 [12, 14, 15].
|
||||
* **Event log 탭:** 기록되는 동안 활동이 발생한 순서대로 정렬하여 분석할 수 있습니다 [12, 16].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
|
||||
- **정책 변화:** Web & Performance 카테고리의 전문성 확보 및 링크 밀도 최적화.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Chrome DevTools|Chrome DevTools]], Frames Per Second (FPS), Forced Synchronous Layouts, Long Task, [[Interaction to Next Paint (INP)|Interaction to Next Paint (INP]]
|
||||
- **Projects/Contexts:** RAIL model, Chrome User Experience Report ([[CrUX|CrUX]])
|
||||
- **Contradictions/Notes:** DevTools의 CPU 스로틀링 기능은 데스크톱의 CPU 속도를 늦추어 시뮬레이션하는 방식이므로, 데스크톱과 모바일 기기의 근본적인 아키텍처 차이 때문에 실제 모바일 기기의 CPU 동작을 완벽하게 모방할 수는 없습니다 [17].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
이 문서는 Canonical 문서인 [[성능_프로파일링_및_메모리_관리_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-ANDE-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-anomaly-detection
|
||||
title: Anomaly Detection
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ANDE-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, anomaly-detection, data-science, security, [[Quality-Control|Quality-Control]], machine-learning]
|
||||
tags: [auto-reinforced, anomaly-detection, data-science, security, Quality-Control, machine-learning]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Anomaly-Detection|Anomaly-Detection]]
|
||||
@@ -24,7 +36,7 @@ last_reinforced: 2026-04-20
|
||||
3. **적용 분야**:
|
||||
* 공장 설비 고전 진단, 금융 사기 탐지(FDS), 네트워크 침입 감지, 암세포 진단.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 특정 임계값(Threshold)을 넘으면 알람을 울리는 단순 정책이었으나, 현대 AI 정책은 데이터의 동적 변화를 반영하여 임계값을 스스로 조정하는 'Adaptive Threshold 정책'으로 진화함(RL Update).
|
||||
- **정책 변화(RL Update)**: 보안 및 개인정보 정책에서, 단순 탐지를 넘어 보이지 않는 위협을 선제적으로 차단하는 'Zero Trust 보안 정책'의 핵심 기술로 이상 탐지 알고리즘이 채택됨.
|
||||
|
||||
@@ -32,3 +44,52 @@ last_reinforced: 2026-04-20
|
||||
- [[Time-Series-Analysis|Time-Series-Analysis]], Pattern Recognition, [[Safety & Reliability|Safety & Reliability]], [[Variational Autoencoders (VAE)|Variational Autoencoders (VAE)]], [[Decision Theory|Decision Theory]]
|
||||
- **Modern Tech/Tools**: Isolation Forest, One-Class SVM, Amazon Lookout for Metrics.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,33 +1,22 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-C35C99
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - AppSec (애플리케이션 보안)"
|
||||
id: wiki-2026-0508-appsec-애플리케이션-보안
|
||||
title: AppSec (애플리케이션 보안)
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 보안_및_시스템_신뢰성_표준
|
||||
canonical_id: wiki-2026-0507-039
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[AppSec (애플리케이션 보안)|AppSec (애플리케이션 보안]]
|
||||
# Redirect
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 애플리케이션 보안(AppSec)은 잠재적인 위협과 취약점으로부터 소프트웨어 애플리케이션을 보호하기 위한 일련의 활동과 방식을 의미합니다 [1, 2]. 소프트웨어 개발 수명 주기(SDLC)의 모든 단계에 보안을 통합하여 코드가 프로덕션 환경에 배포되기 전에 코드 수준의 결함을 조기에 발견하고 수정하는 것을 목표로 합니다 [3, 4]. 이를 위해 [[SAST|SAST]], DAST, SCA 등 다양한 자동화된 보안 테스트 도구와 인간의 수동 코드 리뷰를 결합하여 애플리케이션의 전반적인 보안 태세를 강화합니다 [4-6].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **주요 AppSec 도구 및 방법론:** AppSec은 포괄적인 보안을 제공하기 위해 여러 종류의 도구를 조합하여 사용합니다. 소스 코드 자체를 분석하여 논리적 취약점을 찾는 정적 애플리케이션 보안 테스트(SAST), 실행 중인 애플리케이션을 외부에서 테스트하여 런타임 문제를 잡는 동적 애플리케이션 보안 테스트(DAST), 오픈소스 및 서드파티 라이브러리의 알려진 취약점과 라이선스를 분석하는 소프트웨어 구성 분석(SCA), 그리고 런타임 환경에 내장되어 정적 분석과 동적 분석의 장점을 결합하는 대화형 애플리케이션 보안 테스트(IAST)가 대표적입니다 [4, 6-9].
|
||||
* **SDLC 통합 및 시프트 레프트([[Shift|Shift]]-Left):** 현대 AppSec의 핵심은 취약점 탐지 및 조치 과정을 개발 초기 단계로 앞당기는 '시프트 레프트' 전략입니다 [10, 11]. IDE 플러그인이나 CI/CD 파이프라인, 풀 리퀘스트(PR) 단계에 보안 검사를 내장함으로써, 개발자가 코드를 작성하는 즉시 실시간으로 문제를 인지하고 수정할 수 있어 프로덕션 이후에 결함을 수정하는 것보다 시간과 비용을 크게 절감할 수 있습니다 [3, 10, 12, 13].
|
||||
* **AppSec에서의 AI 활용:** 인공지능(AI)과 대형 언어 모델(LLM)의 도입으로 AppSec 도구들은 단순한 규칙 기반 패턴 매칭을 넘어 코드의 문맥과 의미를 이해하는 수준으로 진화하고 있습니다 [14, 15]. AI 기반 정적 분석 도구들은 데이터 흐름(Data flow) 및 오염 분석(Taint [[Analysis|Analysis]])을 통해 파일 간 경계를 넘나드는 복잡한 취약점을 파악하고, 오탐지(False Positive)율을 크게 낮춥니다 [16-18]. 나아가 취약점에 대한 자동 수정 코드(Auto-fix)를 생성하여 개발자의 워크플로우 내에서 즉각적인 픽스를 제안합니다 [18-20].
|
||||
* **수동 리뷰와 자동화 도구의 하이브리드 접근:** 자동화된 AppSec 도구는 확장성과 속도 면에서 뛰어나 수천 줄의 코드를 몇 초 만에 스캔하지만, 비즈니스 로직이나 아키텍처 설계의 의도를 파악하는 데는 한계(Context Blindness)가 있습니다 [21-23]. 따라서 강력한 보안을 위해서는 자동화 도구가 일상적인 구문 오류와 알려진 취약점(예: SQL 인젝션, XSS 패턴 등)을 일차적으로 걸러내고, 인간 리뷰어가 인증 로직, 데이터 암호화, 크로스 서비스 영향 등 컨텍스트와 도메인 전문성이 중요한 고위험 영역의 리뷰에 집중하는 하이브리드 접근 방식이 필수적입니다 [5, 24, 25].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[SAST (정적 애플리케이션 보안 테스트)|SAST (정적 애플리케이션 보안 테스트]], DAST (동적 애플리케이션 보안 테스트), SCA (소프트웨어 구성 분석), [[SDLC (소프트웨어 개발 수명 주기)|SDLC (소프트웨어 개발 수명 주기]]
|
||||
- **Projects/Contexts:** 시프트 레프트(Shift-Left) 전략, 하이브리드 코드 리뷰 프로세스
|
||||
- **Contradictions/Notes:** 자동화된 AppSec 도구는 코드베이스 전체를 빠르고 일관되게 스캔하여 구문적 취약점을 찾아내지만, 비즈니스 로직이나 아키텍처의 의도를 이해하지 못해 오탐지(False Positives)를 유발할 수 있습니다. 따라서 도구에만 전적으로 의존하는 것은 위험하며, 복잡한 비즈니스 로직과 컨텍스트에 민감한 보안 위협을 식별하기 위해서는 반드시 인간 전문가에 의한 수동 코드 리뷰(Manual [[Code Review|Code Review]])가 병행되어야 한다고 소스들은 강조합니다 [23, 24, 26, 27].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
이 문서는 Canonical 문서인 [[보안_및_시스템_신뢰성_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-AUTO-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-automated-quality-review
|
||||
title: "Automated Quality & Review"
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-WIKI-AUTO-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [automation, code-review, static-analysis, linting, quality-gate, dev-tools, p-reinforce]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Automated Quality & Review|Automated Quality & Review]]
|
||||
@@ -23,7 +35,7 @@ last_reinforced: 2026-05-01
|
||||
3. **도구 통합 (Tools Integration)**:
|
||||
* GitHub Actions, SonarQube, CodeClimate 등 다양한 분석 도구를 PR 워크플로우에 통합하여 코드 건강 상태를 가시화하고 추적합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **오탐(False Positive)의 노이즈**: 자동화 도구가 실제 위협이 아닌 코드를 결함으로 지적할 경우 개발자의 피로도가 증가합니다. 프로젝트 맥락에 맞는 규칙 커스터마이징과 예외 처리 정책이 중요합니다.
|
||||
- **인간의 대체 불가능성**: 자동화는 정해진 패턴은 잘 찾지만 비즈니스 맥락, 아키텍처 의도, 복잡한 접근 제어 로직은 이해하지 못합니다. 기계는 '규칙 준수'를, 인간은 '의도와 설계'를 검증하는 분업 구조를 유지해야 합니다.
|
||||
|
||||
@@ -34,3 +46,52 @@ last_reinforced: 2026-05-01
|
||||
- Shift-Left Security: 보안 점검을 자동화로 조기 도입하는 전략.
|
||||
- [[Technical-Debt|Technical Debt]]: 자동화된 대시보드를 통해 관리되는 부채.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: a1b2c3d4-e5f6-4901-2e3f-4a5b6c7d8e9f
|
||||
category: Unified
|
||||
id: wiki-2026-0508-bluf-bottom-line-up-front
|
||||
title: BLUF (Bottom Line Up Front)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [a1b2c3d4-e5f6-4901-2e3f-4a5b6c7d8e9f]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [bluf, bottom-line-up-front, pyramid-principle, executive-communication, [[Efficiency|Efficiency]]]
|
||||
tags: [bluf, bottom-line-up-front, pyramid-principle, executive-communication, Efficiency]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-27
|
||||
github_commit: "[[P-Reinforce|P-Reinforce]]-comm"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[BLUF (Bottom Line Up Front)|BLUF (Bottom Line Up Front]]
|
||||
@@ -28,3 +39,57 @@ github_commit: "[[P-Reinforce|P-Reinforce]]-comm"
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-D211FC
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-bvh
|
||||
title: BVH
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-D211FC]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - BVH"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[BVH|BVH]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - BVH"
|
||||
- **[[InstancedMesh|InstancedMesh]]와의 통합 메커니즘:** 기본적으로 `three-mesh-bvh`는 `InstancedMesh` 내의 개별 기하학적 구조(Geometry)에 대한 BVH 기반 레이캐스팅은 지원하지만, 인스턴스 객체들의 전체 집합 자체를 대상으로 작동하지는 않습니다 [7, 8]. 그러나 `[[InstancedMesh2|InstancedMesh2]]`와 같은 확장 라이브러리들은 내부적으로 BVH 공간 인덱스(Spatial Index)를 구축하여, 인스턴스 단위의 빠른 레이캐스팅과 개별 절두체 컬링(Frustum Culling)을 효과적으로 지원하도록 설계되었습니다 [9-12].
|
||||
- **API 및 유틸리티:** 개발 시 BVH의 바운딩 트리 구조를 시각화하기 위해 과거에 사용되던 `MeshBVHVisualizer` 클래스는 더 이상 사용되지 않으며(deprecated), 최신 라이브러리에서는 `MeshBVHHelper`의 사용을 권장합니다 [8, 13].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - BVH"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,35 +1,22 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-BACK-003
|
||||
category: Unified
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, backups, data-protection, di[[SAST|SAST]]er-recovery, security, [[Reliability|Reliability]]]
|
||||
last_reinforced: 2026-04-20
|
||||
id: wiki-2026-0508-backups
|
||||
title: Backups
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 클라우드_인프라_및_IaC_운영_표준
|
||||
canonical_id: wiki-2026-0507-028
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Backups|Backups]]
|
||||
# Redirect
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "최악의 상황을 대비한 지식의 복제본: 데이터는 언제든 유실될 수 있다는 점을 인정하고, 원본이 훼손되었을 때 즉시 시스템을 복원할 수 있도록 별도의 물리적/가상적 공간에 안전하게 보관된 데이터 보험."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
백업(Backups)은 데이터 손실 사고에 대비하여 동일한 데이터를 다른 저장 장치에 복제하여 보관하는 행위입니다.
|
||||
|
||||
1. **3-2-1 법칙**:
|
||||
* **3**: 데이터 복사본을 최소 3개 이상 보유.
|
||||
* **2**: 서로 다른 2개 이상의 매체(Local, Cloud 등)에 저장.
|
||||
* **1**: 그중 1개는 반드시 원격지(Offsite)에 보관 (화재, 지진 대비).
|
||||
2. **백업의 유형**:
|
||||
* **Full Backup**: 모든 데이터를 통째로 복제. (안전하지만 무겁고 느림)
|
||||
* **Incremental Backup**: 마지막 백업 이후 변경된 부분만 복제. (빠르고 효율적)
|
||||
* **Snapshot**: 특정 시점의 데이터 상태를 사진 찍듯 기록. 롤백(Rollback)에 용이.
|
||||
3. **검증의 중요성**:
|
||||
* "백업은 저장하는 것이 아니라, 성공적으로 **복구**될 수 있을 때만 의미가 있다."
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 수동으로 테이프나 HDD에 복사하는 정책이었으나, 현대의 클라우드 인프라 정책은 데이터 변경 즉시 실시간 복제본을 생성하는 '지속적 데이터 보호(CDP) 정책'으로 강화됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 랜섬웨어 정책 부반에 대응하기 위해, 한 번 백업되면 절대 수정이나 삭제가 불가능한 'WORM (Write Once Read Many) 정책' 및 '격리된 백업(Air-gapped) 정책'이 필수 보안 표준으로 채택됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Availability-and-Persistence|Availability-and-Persistence]], [[Safety & Reliability|Safety & Reliability]], Workflow-InteGrity, [[Robustness|Robustness]], [[Technical-Architecture|Technical-Architecture]]
|
||||
- **Modern Tech/Tools**: AWS Backup, Veeam, Git (Version control as backup), RAID.
|
||||
---
|
||||
이 문서는 Canonical 문서인 [[클라우드_인프라_및_IaC_운영_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-6B3697
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-batchedmesh-및-instancedmesh-성능-벤
|
||||
title: BatchedMesh 및 InstancedMesh 성능 벤치마크
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-6B3697]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - BatchedMesh 및 [[InstancedMesh|InstancedMesh]] 성능 벤치마크"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[BatchedMesh 및 InstancedMesh 성능 벤치마크|BatchedMesh 및 InstancedMesh 성능 벤치마크]]
|
||||
@@ -28,7 +39,7 @@ github_commit: "[P-Reinforce] Continuous Worker - BatchedMesh 및 [[InstancedMes
|
||||
- **성능 벤치마크 기반의 선택 가이드라인**
|
||||
동적인 씬에서 객체의 종류가 1,000개 이하라면 InstancedMesh가 압도적으로 효율적입니다 [10, 26]. 만일 고유 객체가 1,000개 이상이라면 BatchedMesh를 고려할 수 있으나, 수만~수십만 개의 극대규모 객체 단위로 넘어가면 한계에 부딪힙니다 [10, 27]. 씬이 정적이라면 지오메트리를 하나의 거대한 버퍼로 완전히 병합(Merge)해버리는 것이 성능에 훨씬 이로우며, 매우 방대하고 동적인 처리가 필수적이라면 [[WebGPU|WebGPU]] 기반의 컴퓨트 셰이더와 간접 드로우([[Indirect Draw|Indirect Draw]]) 파이프라인으로 전환하는 것이 근본적인 해결책입니다 [6, 28, 29].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -41,3 +52,52 @@ github_commit: "[P-Reinforce] Continuous Worker - BatchedMesh 및 [[InstancedMes
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+64
-4
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-C3E3B9
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-beat-saber-엑서게임-연구-beat-saber-ex
|
||||
title: Beat Saber 엑서게임 연구(Beat Saber Exergaming Study)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-C3E3B9]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[Beat Saber|Beat Saber]] 엑서게임 연구(Beat Saber [[Exergaming|Exergaming]] Study)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Beat Saber 엑서게임 연구(Beat Saber Exergaming Study)|Beat Saber 엑서게임 연구(Beat Saber Exergaming Study]]
|
||||
@@ -24,7 +35,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Beat Saber|Beat Saber]] 엑
|
||||
* **안전 권고사항:**
|
||||
이러한 결과를 바탕으로, 연구진은 사용자가 긴 시간 VR을 플레이하기 전에 짧은 세션으로 미리 테스트해 볼 것을 권장한다 [4]. 또한, VR 기기 사용을 마친 후 운전과 같이 부상 위험을 초래할 수 있는 활동을 수행하기 전에는 멀미 후유증이 완전히 사라질 수 있도록 충분한 대기 시간(예: 최소 40분 이상)을 가져야 한다고 조언한다 [4].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -37,3 +48,52 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Beat Saber|Beat Saber]] 엑
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+64
-4
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-180522
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-beat-saber를-활용한-vr-엑서게임-후유증-연구-v
|
||||
title: Beat Saber를 활용한 VR 엑서게임 후유증 연구(VR Exergaming Aftereffects)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-180522]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[Beat Saber|Beat Saber]]를 활용한 VR 엑서게임 후유증 연구(VR [[Exergaming|Exergaming]] Aftereffects)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Beat Saber를 활용한 VR 엑서게임 후유증 연구(VR Exergaming Aftereffects)|Beat Saber를 활용한 VR 엑서게임 후유증 연구(VR Exergaming Aftereffects]]
|
||||
@@ -34,7 +45,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Beat Saber|Beat Saber]]를
|
||||
- 장시간의 VR 엑서게임에 돌입하기 전, 짧은 시간 동안 미리 체험하여 개인의 멀미 민감도를 확인하는 것이 좋습니다 [12].
|
||||
- 시각적 변화와 멀미 증상에서 완전히 회복될 수 있도록, VR 종료 후 최소 40분의 대기 시간(휴식)을 가진 뒤 운전과 같은 위험할 수 있는 활동을 하는 것이 권장됩니다 [13], [12].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -47,3 +58,52 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Beat Saber|Beat Saber]]를
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-SCI-BIOINFO
|
||||
category: Unified
|
||||
id: wiki-2026-0508-bioinformatics-structure-predict
|
||||
title: Bioinformatics Structure Prediction
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-SCI-BIOINFO]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.98
|
||||
tags: [Bioinformatics, AlphaFold, DNA Sequencing, Protein Structure]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Bioinformatics-Structure-Prediction|Bioinformatics-Structure-Prediction]] (바이오 인포매틱스와 구조 예측)
|
||||
@@ -19,9 +28,35 @@ last_reinforced: 2026-04-20
|
||||
- **Genome Sequencing**:
|
||||
- 대량의 염기 서열 데이터를 고속으로 처리하고 통계적으로 분석하여 유전병의 원인을 찾아내는 머신러닝 분석 기법.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 정적인 구조 예측을 넘어, 이제는 단백질이 시간에 따라 어떻게 움직이는지(Dynamics)를 예측하는 것이 다음 과제다. 이는 항암제와 같은 정밀 의료의 핵심이 된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Digital Twins|Digital Twins]] , [[Deep-Learning|Deep-Learning]]-Basics
|
||||
- Foundation: [[Information Theory|Information Theory]]
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-7F733B
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-blink
|
||||
title: Blink
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-7F733B]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Blink"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Blink|Blink]]
|
||||
@@ -19,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Blink"
|
||||
크롬의 렌더러인 Blink는 메모리를 관리하기 위해 'Oilpan'이라는 독자적인 가비지 컬렉터를 가지고 있습니다 [1]. 현재 V8 엔진의 가비지 컬렉터와 Blink의 Oilpan 간의 협력을 향상시키기 위한 작업이 진행 중입니다. 특히, V8의 가비지 컬렉터 프로젝트인 [[Orinoco|Orinoco]]에서 도입된 새로운 기술과 기법 중 일부를 Blink의 Oilpan으로 이식(porting)하는 노력이 이루어지고 있습니다 [1].
|
||||
- **주의:** 소스에 관련 정보가 부족합니다. (제공된 소스 데이터에서는 Blink의 가비지 컬렉션(Oilpan)과 메모리 표현(`InternalNode`)에 관한 내용만 간략히 언급되어 있으며, 그 외 Blink의 세부 아키텍처나 렌더링 동작 방식에 대한 상세 정보는 포함되어 있지 않습니다.)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -32,3 +43,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Blink"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-BLPO-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-blog-post
|
||||
title: Blog Post
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-BLPO-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.88
|
||||
tags: [auto-reinforced, blog-post, content-creation, outreach, digital-marketing, knowledge-sharing]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Blog-Post|Blog-Post]]
|
||||
@@ -21,7 +30,7 @@ last_reinforced: 2026-04-20
|
||||
2. **지식 관리에서의 역할**:
|
||||
* 파편화된 지식(Atomic notes)들을 엮어 하나의 완성된 서사로 발전시키는 '지식의 결정체' 단계.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 긴 텍스트 위주의 '일기장' 정책이 강했으나, 현대의 콘텐츠 정책은 짧고 강렬한 이미지와 정보를 담은 '마이크로 블로깅' 및 'AI 생성 보조 기반의 고효율 포스팅 정책'으로 진화함(RL Update).
|
||||
- **정책 변화(RL Update)**: 검색 엔진 최적화(SEO) 정책 중심의 글쓰기에서 벗어나, AI 답변 에이전트가 내 글을 잘 인용할 수 있도록 데이터 구조를 최적화하는 'LLM-Friendly 포스팅 정책'이 새로운 마케팅 표준이 됨. (SEO Best Practices와 협업)
|
||||
|
||||
@@ -29,3 +38,29 @@ last_reinforced: 2026-04-20
|
||||
- [[Scientific Communication|Scientific Communication]], [[Authenticity|Authenticity]], [[Knowledge synthesis|Knowledge Synthesis]], [[Arts|Arts]], Information-Overload
|
||||
- **Modern Tech/Tools**: Medium, Substack, Ghost, AI technical writing assistants.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-4D7707
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-branch-prediction
|
||||
title: Branch Prediction
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-4D7707]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Branch Prediction"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Branch Prediction|Branch Prediction]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Branch Prediction"
|
||||
- **브라우저 엔진([[WebKit|WebKit]])에 미치는 영향:** WebKit의 JavaScriptCore는 신뢰할 수 없는 JavaScript나 [[WebAssembly|WebAssembly]] 코드의 보안(예: 배열 경계 검사, 타입 검사)을 유지하기 위해 '분기 명령어'에 의존해왔습니다 [4-6]. 그러나 분기 예측을 악용한 스펙터 공격으로 인해, 분기 명령어만으로는 더 이상 보안 속성을 강제하기에 충분하지 않게 되었습니다 [4, 5].
|
||||
- **대응 및 완화 조치:** 분기 예측을 악용하는 공격에 대응하기 위해 WebKit은 기존의 분기 기반 보안 검사 외에도, 인덱스 마스킹([[Index Masking|Index Masking]])이나 포인터 포이즈닝(Pointer Poisoning)과 같은 '분기 없는 보안 검사([[Branchless Security Checks|Branchless Security Checks]])' 방식으로 전환하고 있습니다 [7-9].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Branch Prediction"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-2887C6
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-buffergeometry
|
||||
title: BufferGeometry
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-2887C6]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - BufferGeometry"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[BufferGeometry|BufferGeometry]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - BufferGeometry"
|
||||
* **메모리 집약성 및 컬링(Culling) 효율의 한계:** 여러 객체를 하나의 BufferGeometry로 묶는 방식은 드로우 콜을 줄여주지만, 객체를 복제할 때마다 RAM 사용량이 정비례로 증가하는 메모리 집약적인 특성을 띤다 [4]. 더욱이 병합된 메쉬 전체가 하나의 단일 바운딩 볼륨(Bounding Volume)으로 취급되기 때문에, 화면 밖의 객체를 제외하는 시야 절두체 컬링([[Frustum Culling|Frustum Culling]])의 정밀도가 떨어지는 한계가 발생한다 [5].
|
||||
* **개별 항목의 식별 및 접근:** 여러 객체를 거대한 BufferGeometry 하나로 병합한 후 특정 개별 요소를 선택하거나 수정하는 것은 까다롭지만, 버퍼 내 각 객체의 위치(Position) 데이터를 저장하는 매핑(Map) 구조를 구축하여 개별 항목을 효율적으로 조회하고 제어할 수 있다 [4].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - BufferGeometry"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-20A493
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-cantab-5-선택-반응-시간-과제-cantab-5-ch
|
||||
title: CANTAB 5 선택 반응 시간 과제(CANTAB 5 choice RTI)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-20A493]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - CANTAB 5-선택 반응 시간 과제(CANTAB 5-choice RTI)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[CANTAB 5-선택 반응 시간 과제(CANTAB 5-choice RTI)|CANTAB 5-선택 반응 시간 과제(CANTAB 5-choice RTI]]
|
||||
@@ -19,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - CANTAB 5-선택 반응 시간
|
||||
- **이동 속도(Movement speed):** 하단 버튼에서 손을 뗀 순간부터 목표 자극(노란색 점)을 실제로 터치하기까지 걸린 시간의 중앙값입니다 [1].
|
||||
- **활용 맥락:** 소스 자료에 따르면, 이 과제는 가상현실(VR) 엑서게임([[Beat Saber|Beat Saber]] 등) 이용이 인지 능력에 미치는 사후 효과(Aftereffects)를 측정하기 위한 연구에 도입되었습니다 [1, 3]. 참가자의 인지 상태 변화를 확인하기 위해 VR 노출 전, 노출 직후, 그리고 40분 후에 각각 이 과제를 수행하여 반응 시간을 비교 분석하는 데 사용되었습니다 [3, 4].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -32,3 +43,52 @@ github_commit: "[P-Reinforce] Continuous Worker - CANTAB 5-선택 반응 시간
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,32 +1,26 @@
|
||||
---
|
||||
id: ci_cd_pipeline
|
||||
title: CI/CD 파이프라인 (Continuous Integration & Continuous Deployment)
|
||||
id: wiki-2026-0508-ci-cd-pipeline
|
||||
title: CI CD Pipeline
|
||||
category: DevOps_and_Security
|
||||
status: stable
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [ci_cd_pipeline]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
created_at: 2026-04-18
|
||||
updated_at: 2026-05-08
|
||||
tags:
|
||||
- ci_cd
|
||||
- devops
|
||||
- automation
|
||||
- pipeline
|
||||
- software_delivery
|
||||
raw_sources:
|
||||
- Programming & Language/CI_CD Pipeline.md
|
||||
- Programming & Language/CI_CD 파이프라인 자동화.md
|
||||
- Programming & Language/CI_CD 파이프라인.md
|
||||
- Programming & Language/Continuous Integration (CI).md
|
||||
- Architecture/CI_CD.md
|
||||
tags: [- ci_cd - devops - automation - pipeline - software_delivery]
|
||||
raw_sources: ["- Programming & Language/CI_CD Pipeline.md - Programming & Language/CI_CD 파이프라인 자동화.md - Programming & Language/CI_CD 파이프라인.md - Programming & Language/Continuous Integration (CI).md - Architecture/CI_CD.md"]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# CI/CD 파이프라인 (Continuous Integration & Continuous Deployment)
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
CI/CD는 애플리케이션 개발 단계부터 배포까지의 전 과정을 자동화하여 사용자에게 더 빠르고 빈번하게 소프트웨어를 제공하는 방법론입니다 [1]. **CI(Continuous Integration)**는 코드 변경 사항을 정기적으로 빌드 및 테스트하여 공유 저장소에 병합하는 과정을, **CD(Continuous Delivery/Deployment)**는 검증된 코드를 운영 환경에 자동으로 배포하는 과정을 의미합니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
### 1. 지속적 통합 (Continuous Integration, CI)
|
||||
* **자동 빌드 및 테스트**: 개발자가 코드를 커밋하면 자동으로 빌드가 수행되고 단위 테스트(Unit Test)가 실행됩니다.
|
||||
* **충돌 조기 발견**: 빈번한 병합을 통해 코드 간의 충돌을 조기에 발견하고 해결합니다.
|
||||
@@ -43,15 +37,41 @@ CI/CD는 애플리케이션 개발 단계부터 배포까지의 전 과정을
|
||||
* **Test**: 단위, 통합, 보안 테스트 수행.
|
||||
* **Deploy**: 타겟 환경(Cloud, On-premise 등)으로 배포 및 환경 설정.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **인프라 복잡성**: 자동화된 파이프라인을 구축하고 유지 관리하는 데 초기 비용과 노력이 많이 듭니다.
|
||||
* **테스트 신뢰성**: 자동화된 테스트의 품질이 낮으면 잘못된 코드가 자동으로 배포되어 서비스 장애를 유발할 수 있습니다.
|
||||
* **보안 리스크**: 파이프라인 자체의 보안(Secrets management 등)이 뚫리면 악성 코드가 배포될 위험이 있습니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics**: [[DevSecOps|데브섹옵스]], [[SAST|정적 분석]], [[DAST|동적 분석]], [[SCA|구성 분석]], 인프라 자동화(IaC)
|
||||
- **Projects/Contexts**: GitHub Actions, Jenkins, GitLab CI, ArgoCD 활용
|
||||
- **Contradictions/Notes**: CI/CD는 단순히 도구의 문제가 아니라 '문화'의 문제입니다. 실패 시 즉시 복구하고 문제를 공유하는 팀의 성숙도가 동반되어야 합니다 [1].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,33 +1,22 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-944A15
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - CPU Bottleneck"
|
||||
id: wiki-2026-0508-cpu-bottleneck
|
||||
title: CPU Bottleneck
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 성능_프로파일링_및_메모리_관리_표준
|
||||
canonical_id: wiki-2026-0508-040
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[CPU Bottleneck|CPU Bottleneck]]
|
||||
# Redirect
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 3D 그래픽스 및 실시간 렌더링 환경에서 CPU 병목(CPU Bottleneck)이란, CPU가 렌더링 명령어(드로우 콜)를 준비하고 GPU로 전송하거나 필요한 데이터 연산을 처리하는 속도가 느려져 GPU가 제 성능을 발휘하지 못하고 대기(Starve)하게 되는 현상을 말합니다 [1]. 주로 개별 모델에 대한 과도한 드로우 콜 발행이나 자바스크립트 메인 스레드에서의 무거운 연산(애니메이션, 정렬, 컬링 등)으로 인해 발생하며 [2-4], 이를 해결하기 위해 인스턴싱([[Instancing|Instancing]])이나 연산의 GPU 오프로딩 기법이 사용됩니다 [5, 6].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **드로우 콜 오버헤드 ([[Draw Call|Draw Call]] Overhead):** CPU 병목의 가장 주요한 원인입니다. CPU는 GPU에 그리기 명령을 내릴 때마다 변환 행렬, 셰이더 참조, 유니폼, 정점 버퍼 등의 렌더링 상태를 준비하고 통신해야 합니다 [2, 7]. 수백~수천 개의 개별 객체를 렌더링할 경우, 실제 폴리곤을 그리는 연산보다 CPU가 명령을 준비하고 발행하는 오버헤드가 시스템 버스에 막대한 부하를 가하여 병목을 유발합니다 [1, 7, 8].
|
||||
- **자바스크립트 메인 스레드 한계:** 웹 렌더링(Three.js 등) 환경에서 수만 개의 객체에 대해 수동으로 시야 절두체 컬링([[Frustum Culling|Frustum Culling]])을 계산하거나, 투명 객체의 깊이 정렬(예: [[Radix Sort|Radix Sort]])을 수행할 경우 막대한 CPU 연산 비용이 발생합니다 [4, 9]. 단일 스레드 기반인 자바스크립트에서 렌더링 루프 내의 대규모 배열 조작은 메인 스레드를 점유하여 프레임 드랍을 유발하는 치명적인 CPU 병목을 낳습니다 [4, 9].
|
||||
- **애니메이션 및 레이캐스팅 부하:** 스킨드 메시(Skinned Mesh)의 뼈대(Bone) 애니메이션 시스템은 매 프레임 CPU에서 행렬 업데이트 연산을 요구하므로 다수의 캐릭터가 있을 경우 렌더링 예산을 초과하는 CPU 시간을 소모합니다 [3]. 또한 수만 개의 인스턴스 환경에서 CPU 기반 레이캐스팅([[Raycasting|Raycasting]])을 수행하면 각 인스턴스의 행렬을 일일이 역산해야 하므로 즉각적인 반응을 불가능하게 만드는 동기화 병목이 발생합니다 [10].
|
||||
- **입자 시스템 및 물리 연산:** CPU를 활용한 파티클 시스템 업데이트는 일반적인 하드웨어 기준 약 50,000개 수준에서 CPU 병목에 도달합니다 [5]. 이러한 연산 병목은 [[WebGPU|WebGPU]]의 컴퓨트 셰이더([[Compute Shader|Compute Shader]]s)를 활용해 메인 스레드의 작업을 GPU 코어로 병렬 오프로드함으로써 해결할 수 있습니다 [5, 11].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Draw Call|Draw Call]], InstancedMesh, [[Frustum Culling|Frustum Culling]]
|
||||
- **Projects/Contexts:** Three.js, [[WebGL|WebGL]], [[WebGPU|WebGPU]]
|
||||
- **Contradictions/Notes:** `[[InstancedMesh|InstancedMesh]]` 기술은 수천 개의 객체를 단 한 번의 드로우 콜로 처리하여 CPU 병목을 획기적으로 해결하는 기술로 알려져 있습니다 [6, 12]. 그러나 이 방식은 개별 객체의 컬링이나 정렬 같은 내부 최적화를 지원하지 않으므로, 이를 극복하기 위해 CPU 단에서 수동으로 위치를 검사하고 버퍼를 재정렬하는 로직을 추가할 경우 오히려 이전보다 더 극심한 CPU 연산 병목이 발생하는 역설적인 상황이 빈번하게 발생합니다 [4, 9].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
이 문서는 Canonical 문서인 [[성능_프로파일링_및_메모리_관리_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-52B523
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-cheneys-algorithm
|
||||
title: Cheneys Algorithm
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-52B523]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Cheneys Algorithm"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Cheneys Algorithm|Cheneys Algorithm]]
|
||||
@@ -25,7 +36,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Cheneys Algorithm"
|
||||
4. 만약 포인터가 이미 복사된 from-space의 객체(전달 주소가 존재하는 객체)를 가리킨다면, 해당 포인터가 to-space의 새로운 복사본을 가리키도록 업데이트합니다 [4].
|
||||
- **종료 조건 및 가비지 처리**: `scanPtr`가 `allocationPtr`에 도달하여 더 이상 처리할 객체가 남지 않게 되면 알고리즘은 종료됩니다 [5]. 이 시점에 from-space에 남아있는 모든 데이터는 가비지(쓰레기)로 간주되어 메모리가 해제되거나 다른 목적으로 재사용됩니다 [5].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -38,3 +49,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Cheneys Algorithm"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-7DF5C6
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-chrome-v8-heap-analysis
|
||||
title: Chrome V8 Heap Analysis
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-7DF5C6]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[Chrome|Chrome]] V8 Heap [[Analysis|Analysis]]"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Chrome V8 Heap Analysis|Chrome V8 Heap Analysis]]
|
||||
@@ -30,7 +41,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Chrome|Chrome]] V8 Heap [[An
|
||||
* **보안 제한 및 익스플로잇 아티팩트 (Security & Exploitation Artifacts):**
|
||||
V8은 포인터 압축([[Pointer Compression|Pointer Compression]]) 기법을 사용하여 포인터 크기를 32비트로 줄이고, 전체 힙을 4GB 크기의 'V8 [[memory|memory]] Cage' 내에 가둡니다 [63-68]. 공격자들은 메모리 손상 취약점(OOB 등)을 활용해 V8의 힙에 개입하여 객체 주소를 유출하는 `addrof`나 위조 객체를 만드는 `fakeobj` 등의 원시 공격(Primitives)을 수행합니다 [10, 68-78]. 이러한 공격이 실패하거나 진행될 때, `JSArray`의 길이 손상(CorruptedLength)이나 `ElementsKind`와 백킹 스토어의 타입 불일치(ElementsMapMismatch)와 같은 구조적 힙 아티팩트가 메모리에 남게 되어 포렌식 탐지의 신호가 됩니다 [75, 76, 79-82].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -43,3 +54,52 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Chrome|Chrome]] V8 Heap [[An
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-B2A3F3
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-code-obfuscation
|
||||
title: Code Obfuscation
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-B2A3F3]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Code Obfuscation"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Code Obfuscation|Code Obfuscation]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Code Obfuscation"
|
||||
- **코드 미니파이(Minification) 및 포맷팅과의 차이점:** 소스 코드의 공백을 제거하거나 형태를 일관되게 정렬하는 코드 미니파이나 포맷팅 기법 역시 코드의 표면적인 특징을 변환하여 작성자 인식률을 어느 정도 낮추는 효과가 있습니다 [1, 9]. 하지만 이러한 기법만으로는 개발자 식별을 완전히 피할 수 없으며, 식별을 철저하게 차단하려면 코드 가독성을 거의 포기하는 수준의 전면적인 난독화(Full-blown obfuscation)가 필수적으로 요구됩니다 [10].
|
||||
- **수동 및 자동 난독화 연구:** 자동화 도구인 Opy나 PyArmor 등을 활용한 방식뿐만 아니라, 프로그래머가 직접 자신의 코딩 스타일을 바꾸거나 다른 사람의 코딩 스타일을 의도적으로 모방하는 수동 난독화(Manual obfuscation)에 대한 연구도 활발히 진행되고 있습니다 [11-13].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Code Obfuscation"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-17B6B7
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-code-stylometry-코드-문체론
|
||||
title: Code Stylometry (코드 문체론)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-17B6B7]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Code Stylometry (코드 문체론)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Code Stylometry (코드 문체론)|Code Stylometry (코드 문체론]]
|
||||
@@ -22,7 +33,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Code Stylometry (코드 문체
|
||||
* **코드 포매팅 및 축소(Minification)가 저자 식별에 미치는 영향**
|
||||
일관된 코딩 규칙을 적용하는 '코드 포매팅(Code [[Formatting|Formatting]])'이나 불필요한 공백, 줄바꿈 등을 제거하여 코드 크기를 줄이는 '코드 축소([[Code Minification|Code Minification]])'는 소프트웨어 개발의 일반적인 관행이다 [16], [17], [18]. 이러한 소스 대 소스(source-to-source) 변환은 프로그래머의 고유한 스타일 지문 일부를 지우기 때문에 문체론의 정확도를 감소시킨다 [19], [20]. CST 기반의 실험 결과, 코드 포매팅을 적용하면 식별 정확도가 68%에서 53%로 하락하였고, 코드 축소를 적용하면 50%까지 떨어졌다 [21], [22]. 하지만 이러한 감소 폭에도 불구하고 식별 확률이 무작위 추론 수준으로 떨어지지는 않으며, 식별 대상 저자들은 여전히 상당 부분 인식 가능한 상태로 남기 때문에 이를 완벽한 익명화 방어책으로 사용할 수는 없다 [23], [22].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -35,3 +46,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Code Stylometry (코드 문체
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,17 +1,20 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-DEV-CPG
|
||||
title: "코드 속성 그래프와 다차원 보안 분석 (Code Property Graph)"
|
||||
category: Unified
|
||||
id: wiki-2026-0508-code-property-graph
|
||||
title: Code Property Graph
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["CPG", "Code Property Graph", "코드 속성 그래프", "다차원 코드 분석"]
|
||||
duplicate_of: ""
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-DEV-CPG, CPG, Code Property Graph, 코드 속성 그래프, 다차원 코드 분석]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Security", "Code_Modeling", "Static_Analysis", "Vulnerability", "Graph_Theory"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
tags: [Security, Code_Modeling, Static_Analysis, Vulnerability, Graph_Theory]
|
||||
raw_sources: [Datacollector_Export_2026-05-02]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[코드 속성 그래프와 다차원 보안 분석 (Code Property Graph)]]
|
||||
@@ -45,3 +48,70 @@ CPG는 소스 코드를 다음과 같은 다층적 관점에서 동시에 표현
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 단순 구문 분석을 넘어 런타임 악용 가능성까지 예측하는 최첨단 코드 모델링 기법의 표준 정립.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-DESIGN-004
|
||||
category: Unified
|
||||
id: wiki-2026-0508-cognitive-load
|
||||
title: Cognitive Load
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-DESIGN-004]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [design, hci, [[Psychology|Psychology]], cognitive-load]
|
||||
tags: [design, hci, Psychology, cognitive-load]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "batch-reinforce-07"
|
||||
github_commit: batch-reinforce-07
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Cognitive_Load|Cognitive Load]] Theory (인지 부하 이론)
|
||||
@@ -19,7 +27,7 @@ github_commit: "batch-reinforce-07"
|
||||
- 정보의 청킹(Chunking)을 통해 제한된 작업 기억 공간을 효율적으로 활용.
|
||||
- 복잡한 데이터 시각화 시 점진적 노출(Progressive Disclosure) 기법 적용.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 단순한 미학적 디자인(Beautiful)에서 뇌의 작동 방식에 부합하는 사용성(Usable) 중심으로 패러다임 이동.
|
||||
- **정책 변화:** 사용자 만족도(w3) 지표로 인지 부하 측정 가이던스 도입.
|
||||
|
||||
@@ -27,3 +35,29 @@ github_commit: "batch-reinforce-07"
|
||||
- **Parent:** 10_Wiki/💡 Topics/Design
|
||||
- **Related:** [[HCI|HCI]], UX-Design, [[Inclusive_Design|Inclusive_Design]]
|
||||
- **Raw Source:** 00_Raw/2026-04-20/Cognitive Load Theory.md
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,14 +1,26 @@
|
||||
---
|
||||
category: Unified
|
||||
tags: [auto-wikified, technical-documentation]
|
||||
id: wiki-2026-0508-commit-history
|
||||
title: Commit History
|
||||
description: "커밋 히스토리(Commit History)는 버전 관리 시스템(Git 등)을 통해 프로젝트 파일의 변경 내역과 특정 시점의 작업 스냅샷을 기록한 것입니다 [1]."
|
||||
last_updated: 2026-05-02
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-wikified, technical-documentation]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Commit History
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
커밋 히스토리(Commit History)는 버전 관리 시스템(Git 등)을 통해 프로젝트 파일의 변경 내역과 특정 시점의 작업 스냅샷을 기록한 것입니다 [1]. 단순히 현재 코드의 상태를 보여주는 것을 넘어, 해당 코드가 왜 현재의 구조로 작성되었는지에 대한 역사적 맥락과 서사를 제공하는 중요한 정보원입니다 [2]. 이를 통해 개발자는 과거의 설계 결정, 비즈니스 요구사항, 그리고 시스템의 진화 과정을 추적하여 낯선 코드베이스를 효과적으로 해독할 수 있습니다 [2, 3].
|
||||
|
||||
## 📖 Core 코어 Content
|
||||
@@ -18,13 +30,12 @@ last_updated: 2026-05-02
|
||||
* **행동 기반 코드 분석(Behavioral Code Analysis):** 커밋 히스토리는 시스템의 건전성을 평가하는 데이터로도 활용됩니다. CodeScene과 같은 분석 도구는 커밋 히스토리, 작성자 패턴, 코드 변경 빈도(churn) 등의 시간적 데이터를 분석하여 잠재적인 아키텍처 문제나 기술 부채를 식별하는 예측 모델을 구축합니다 [6-8].
|
||||
* **관련 아티팩트의 자동화된 활용:** 특정 코드 스니펫을 분석할 때 `git log -L`을 통해 관련 커밋 히스토리를 역추적할 수 있습니다 [9]. 이때 주석 수정이나 단순 변수명 변경과 같은 사소한 커밋(trivial commits)을 필터링하면, LLM이나 코드 리뷰 시스템이 코드의 진정한 목적(Purpose)을 설명하는 데 필요한 고품질의 컨텍스트를 확보할 수 있습니다 [10].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **버전 관리 품질에 대한 의존성:** 커밋 히스토리를 활용한 코드베이스 분석은 조직 내 버전 관리가 잘 유지보수되고 건강한 상태(healthy)일 때만 유효합니다 [3, 4]. 커밋 메시지가 불분명하거나 맥락 없이 스쿼시(squash)된 경우 유용한 정보를 얻기 힘듭니다.
|
||||
* **사소한 변경에 의한 노이즈:** 히스토리 내에 줄 삭제, 단순 오타 수정, 주석 변경 등의 사소한(trivial) 커밋이 다수 혼재해 있으면, 핵심 비즈니스 로직의 변경 이력을 파악하는 데 방해가 되며 이를 필터링해야 하는 번거로움이 존재합니다 [10].
|
||||
* **탐색에 따른 인지적, 물리적 비용:** 수십 년 된 대규모 프로젝트에서는 특정 코드와 얽힌 커밋, PR, 이슈의 수가 너무 많아 이를 모두 추적하고 읽는 데 긴 시간이 소요될 수 있으며, 네트워크나 시스템 성능에 따라 정보 수집(Fetching)에 병목이 발생할 수 있습니다 [11].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [분석 및 버전 관리 도구]
|
||||
@@ -69,4 +80,61 @@ last_updated: 2026-05-02
|
||||
- 확장 방향: 소스 코드 자체뿐만 아니라 커밋 메시지, PR 설명 등 자연어(NL) 아티팩트를 LLM에 제공하여, 코드가 "무엇"을 하는지가 아니라 "왜" 그렇게 작성되었는지(Purpose)에 대한 수준 높은 맥락적 설명을 생성하는 기술로 확장합니다 [13, 14].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-858963
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-concrete-syntax-tree-cst
|
||||
title: Concrete Syntax Tree (CST)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-858963]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Concrete Syntax Tree (CST)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Concrete Syntax Tree (CST)|Concrete Syntax Tree (CST]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Concrete Syntax Tree (CST)"
|
||||
- **CST 경로(Path) 및 문맥 추출:** CST 내에서 두 단말 노드 사이를 위아래로 이동하는 시퀀스를 'CST 경로(CST path)'라고 정의한다 [7]. 이 경로와 시작 및 종료 노드의 실제 코드 토큰 값을 결합한 것을 '경로 문맥(path context)'이라 부르며, 코드의 어휘적, 구문적, 레이아웃적 특징을 유지하는 데이터 표현 수단으로 쓰인다 [8, 9].
|
||||
- **코드 분석 및 작성자 식별(Stylometry)에서의 활용:** 최신 기계 학습 모델(예: code2vec)은 코드의 의미론적 요소와 문체적 요소를 모두 보존하기 위해 AST 대신 CST를 입력값으로 사용한다 [4]. 실제 실험 결과, AST 대신 CST 기반의 코드 표현을 사용하면 레이아웃 정보가 반영되어 코드 작성자 식별(Authorship attribution)의 정확도가 크게 향상(51.00%에서 67.86%로 증가)되는 것으로 확인되었다 [10, 11].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Concrete Syntax Tree (CST)"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,17 +1,67 @@
|
||||
---
|
||||
id: wiki-2026-0508-continuous-delivery-지속적-제공-cd
|
||||
title: "Continuous Delivery (지속적 제공, CD)"
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Continuous Delivery (지속적 제공, CD)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Continuous Delivery(지속적 제공, CD)는 소프트웨어가 언제든지 프로덕션 환경에 릴리스될 수 있도록 보장하는 자동화된 소프트웨어 개발 관행입니다 [1]. 이를 위해 빌드 파이프라인을 활용하여 소프트웨어를 자동으로 테스트하고 테스트 및 프로덕션 환경에 배포합니다 [1]. 수많은 개발자가 매일 동일한 코드베이스에 코드를 푸시하는 환경에서도 품질 저하 없이 개발 속도와 확신을 유지 가능하게 만드는 핵심적인 역할을 합니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **빌드 파이프라인과 완벽한 자동화:** 지속적 제공 환경에서는 빌드부터 테스트, 배포, 인프라에 이르기까지 모든 과정의 자동화가 필수적입니다 [3]. 수동 테스트와 배포로는 빠르게 혁신하는 개발 속도를 따라갈 수 없으며, 자동화된 테스트 메커니즘이 지속적 제공을 실행 가능하게 만드는 근간이 됩니다 [2, 3].
|
||||
* **빠른 피드백 루프와 애자일의 시너지:** 자동화된 테스트가 제공하는 대폭 단축된 피드백 루프는 애자일 개발 관행, 지속적 제공 및 DevOps 문화와 밀접하게 맞물려 작동합니다 [4]. 이를 통해 팀은 소프트웨어 품질을 희생하지 않으면서도 더 빠르게 움직일 수 있습니다 [1, 4]. 마틴 파울러(Martin Fowler)가 옹호하는 지속적 제공과 DevOps는 조직의 소프트웨어 배포 방식을 혁신적으로 재편하는 데 기여했습니다 [5].
|
||||
* **대규모 환경(SAFe)에서의 확장 및 인프라 조정:** 대규모 애자일 환경에서는 지속적 제공 파이프라인이 전체 ART(Agile Release Train) 시스템에 걸쳐 확장됩니다 [6]. 개별 팀이 고유의 CI(지속적 통합) 프로세스를 유지하는 한편, 시스템 팀은 팀 수준의 빌드 결과물들을 일관된 하나의 소프트웨어로 연결하는 통합 인프라(코드로서의 인프라 등)를 구축하고 조정합니다 [6].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **신뢰할 수 있는 CI 파이프라인 필수:** 단일 자동화 테스트를 작성하거나 CD를 도입하기 전에 기능적이고 신뢰할 수 있는 지속적 통합(CI) 파이프라인이 먼저 구축되어야 합니다 [7]. 매 커밋 시 트리거되는 자동화된 빌드 환경과 수 분 내에 코드의 오류를 알려주는 명확한 피드백 루프가 없다면 지속적 제공의 가치는 실현될 수 없습니다 [7].
|
||||
* **품질 부채(Quality Debt)와 시스템 경직성:** 취약한 코드베이스 위에 자동화를 무리하게 적용하려 할 경우, 테스트 스위트 자체가 유지보수하기 어렵고 깨지기 쉬운 상태가 됩니다 [8]. 결과적으로 흐름 효율성(Flow Efficiency)과 배포 성공률이 모두 악화되므로 리팩토링, 자동화된 테스트, 체계적인 동료 코드 리뷰와 같은 내장된 품질(Built-in Quality) 관행이 반드시 전제되어야 합니다 [8].
|
||||
* **사전 인프라 투자 부담:** 지속적 제공을 안정적으로 운영하려면 테스트 환경, CI 파이프라인 구축 및 테스트 데이터 관리 등 인프라를 마련하는 데 상당한 초기 리소스와 시스템 팀 단위의 노력이 요구됩니다 [6, 9].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-03*
|
||||
*Last updated: 2026-05-03*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,6 +1,23 @@
|
||||
---
|
||||
id: wiki-2026-0508-continuous-integration-지속적-통합-ci
|
||||
title: "Continuous Integration (지속적 통합, CI)"
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Continuous Integration (지속적 통합, CI)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
지속적 통합(CI)은 개발자가 코드를 커밋할 때마다 자동으로 빌드와 테스트가 트리거되어 몇 분 내에 명확한 피드백을 제공하는 소프트웨어 개발 실천법입니다 [1]. 여러 개발자가 동일한 코드베이스에 코드를 푸시할 때 발생하는 문제를 방지하고 자동화된 테스트와 지속적 제공(CD)을 가능하게 하는 핵심 메커니즘입니다 [2]. 특히 리팩토링 과정에서 작은 변경 사항을 만든 후 CI와 TDD를 실행하는 것은 시스템을 정상 작동 상태로 유지하고 새로운 버그가 유입되는 것을 막는 필수적인 안전망 역할을 합니다 [3].
|
||||
|
||||
## 📖 일 Core Content
|
||||
@@ -10,12 +27,11 @@
|
||||
* **지속적 제공(CD) 및 DevOps와의 통합:** CI는 언제든 프로덕션 환경에 소프트웨어를 릴리스할 수 있도록 보장하는 지속적 제공(CD) 및 DevOps 문화와 긴밀하게 연결되어 발전합니다 [4]. 파이프라인은 여러 단계로 나뉘어 점진적으로 소프트웨어 배포에 대한 확신을 주며, 최근의 최신 DevOps 및 CI/CD 파이프라인에서는 마틴 파울러의 리팩토링 방법론이 널리 채택되어 적용되고 있습니다 [5, 6].
|
||||
* **미래의 진화:** 향후 인공지능(AI)이 발전함에 따라, 단순히 코드를 커밋할 때마다 빌드/테스트를 수행하는 '지속적인 통합(CI)' 단계를 넘어, AI가 자동으로 리팩토링 기회를 탐지하고 테스트를 통해 안정성이 입증된 최적의 구조를 제안하거나 적용하는 '지속적인 개선(Continuous Improvement)'의 단계로 나아갈 것으로 예측됩니다 [7].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **초기 인프라 구축 및 신뢰성 확보의 어려움:** CI를 효과적으로 운영하기 위해서는 코드로 프로비저닝된 일관된 빌드 환경과 신뢰할 수 있는 인프라 구축이 선행되어야 합니다 [1, 8]. 이 기반이 불안정하다면 자동화된 테스트도 제대로 기능할 수 없습니다 [1].
|
||||
* **테스트 품질에 대한 강한 의존성:** CI는 테스트를 자동으로 실행해 줄 뿐, 테스트 자체의 품질을 보장하지는 않습니다. CI 파이프라인 내의 테스트가 불완전하거나 간헐적으로 실패하는(Flaky) 경우, CI의 결과에 대한 개발자의 신뢰가 떨어지고 성공적인 리팩토링 진행을 방해하게 됩니다 [9]. 원대한 테스트 커버리지 목표를 쫓기 전에 CI 파이프라인의 신뢰성을 먼저 확보하는 것이 중요합니다 [10].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [소프트웨어 품질 및 검증 (Software Quality & Verification)]
|
||||
@@ -52,4 +68,38 @@
|
||||
* 확장 방향: CI 환경 내에서 병목 없이 빠른 피드백을 받기 위해, 단위 테스트, 통합 테스트, E2E 테스트를 어떤 비율로 구성하고 배치해야 하는지 탐구합니다 [14, 15].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-03*
|
||||
*Last updated: 2026-05-03*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-CDIS-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-continuous-discovery
|
||||
title: Continuous Discovery
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-CDIS-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, continuous-discovery, product-discovery, dual-track-agile, customer-feedback, [[Hypothesis-Testing|Hypothesis-Testing]]]
|
||||
tags: [auto-reinforced, continuous-discovery, product-discovery, dual-track-agile, customer-feedback, Hypothesis-Testing]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Continuous-Discovery|Continuous-Discovery]]
|
||||
@@ -21,7 +30,7 @@ last_reinforced: 2026-04-20
|
||||
2. **왜 중요한가?**:
|
||||
* 시장의 변화 속도가 너무 빨라, 한 번의 완벽한 기획서 정책은 반드시 실패하기 때문임. (Agile와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 기획자와 고객이 만나는 것이 시간 낭비라 여겼으나, 현대 정책은 개발자가 고객의 목소리 정책을 직접 듣고 가설 정책을 즉시 수정하는 '임파워드 팀 정책(Empowered Teams)'이 훨씬 더 혁신적인 결과를 낸다는 점을 인정함(RL Update).
|
||||
- **정책 변화(RL Update)**: 이제는 단순 인터뷰 정책을 넘어, AI 가 수만 건의 피드백 정책을 실시간으로 분석([[Text-Mining|Text-Mining]])하여 기획자에게 '기회 영역'을 추천해 주는 'AI-Augmented Discovery'로 진화 중임. (Text-Mining와 연결)
|
||||
|
||||
@@ -29,3 +38,29 @@ last_reinforced: 2026-04-20
|
||||
- Decision-Making, Agile, [[Text-Mining|Text-Mining]], [[Research|Re[[Search]]-Methodology]], [[Product-Management|Product-Management]]
|
||||
- **Key Figure**: Teresa Torres.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,17 +1,20 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-DEV-CI
|
||||
title: "지속적 통합과 자동화된 검증 체계 (Continuous Integration)"
|
||||
category: Unified
|
||||
id: wiki-2026-0508-continuous-integration
|
||||
title: Continuous Integration
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["CI", "지속적 통합", "Continuous Integration", "빌드 자동화", "파이프라인"]
|
||||
duplicate_of: ""
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-DEV-CI, CI, 지속적 통합, Continuous Integration, 빌드 자동화, 파이프라인]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["DevOps", "CI_CD", "Automation", "Quality_Assurance", "Software_Engineering"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
tags: [DevOps, CI_CD, Automation, Quality_Assurance, Software_Engineering]
|
||||
raw_sources: [Datacollector_Export_2026-05-02]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[지속적 통합과 자동화된 검증 체계 (Continuous Integration)]]
|
||||
@@ -45,3 +48,70 @@ github_commit: ""
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 소프트웨어 개발의 민첩성과 품질을 동시에 확보하기 위한 현대적 개발 프로세스의 중추인 지속적 통합 전략 및 실천 지침 정립.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,53 +1,22 @@
|
||||
---
|
||||
id: dynamic_application_security_testing
|
||||
title: 동적 애플리케이션 보안 테스트 (Dynamic Application Security Testing, DAST)
|
||||
category: DevOps_and_Security
|
||||
status: stable
|
||||
confidence_score: 0.95
|
||||
created_at: 2026-04-18
|
||||
updated_at: 2026-05-08
|
||||
tags:
|
||||
- dast
|
||||
- dynamic_analysis
|
||||
- security_testing
|
||||
- black_box_testing
|
||||
- devsecops
|
||||
raw_sources:
|
||||
- Programming & Language/DAST (동적 애플리케이션 보안 테스트).md
|
||||
- Programming & Language/동적 애플리케이션 보안 테스트(DAST).md
|
||||
- DevOps_and_Security/DAST_Fundamentals.md
|
||||
id: wiki-2026-0508-dast
|
||||
title: DAST
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 보안_및_시스템_신뢰성_표준
|
||||
canonical_id: wiki-2026-0507-039
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 동적 애플리케이션 보안 테스트 (Dynamic Application Security Testing, DAST)
|
||||
# Redirect
|
||||
|
||||
## 📌 Brief Summary
|
||||
DAST(Dynamic Application Security Testing)는 애플리케이션이 실행 중인 상태에서 외부에서 공격을 시도하여 보안 취약점을 찾는 '블랙박스 테스팅' 기법입니다 [1]. 소스 코드에 접근하지 않고 실행 환경에서의 실제 동작을 분석하므로, 런타임 설정 오류나 인증 문제 등을 식별하는 데 매우 효과적입니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. DAST의 특징 및 장점
|
||||
* **블랙박스 테스트**: 내부 구현 로직을 모르는 상태에서 외부 인터페이스(HTTP, API 등)를 통해 공격 시나리오를 수행합니다 [1].
|
||||
* **런타임 이슈 탐지**: 소스 코드 분석만으로는 알 수 없는 서버 설정 오류, 세션 관리 취약점, 인젝션 공격 등을 실제 상황에서 검증합니다 [1, 2].
|
||||
* **언어 독립성**: 특정 프로그래밍 언어에 의존하지 않고 웹 표준 프로토콜을 통해 테스트하므로 모든 언어로 개발된 애플리케이션에 적용 가능합니다.
|
||||
|
||||
### 2. DAST의 수행 과정
|
||||
* **크롤링/스파이더링**: 애플리케이션의 모든 페이지와 API 엔드포인트를 탐색하여 공격 가능한 지표(Attack Surface)를 식별합니다.
|
||||
* **퍼징(Fuzzing)**: 입력값에 다양한 비정상 데이터를 주입하여 시스템의 예외 상황이나 보안 결함을 유발합니다.
|
||||
* **분석 및 보고**: 공격 시도에 대한 시스템의 반응을 분석하여 취약점 여부를 판단하고 보고서를 생성합니다.
|
||||
|
||||
### 3. 도구 및 통합
|
||||
* **대표 도구**: OWASP ZAP, Burp Suite, Veracode Dynamic Analysis 등.
|
||||
* **파이프라인 통합**: 배포 직후 스테이징 환경에서 자동으로 실행되도록 설정하여 보안 검사를 상시화합니다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **높은 허위 양성 (False Positives)**: 실제 취약점이 아닌데도 시스템 지연 등으로 인해 취약점으로 오인되는 경우가 발생할 수 있습니다.
|
||||
* **실행 시간**: 전체 애플리케이션을 탐색하고 공격 시나리오를 돌리는 데 많은 시간이 소요되므로 CI 파이프라인에서 병목이 될 수 있습니다.
|
||||
* **공격의 한계**: 소스 코드를 보지 않으므로 코드 깊숙한 곳의 논리적 결함은 찾아내기 어렵습니다 (SAST와 병행 필요).
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics**: [[SAST|정적 보안 테스트]], [[SCA|소프트웨어 구성 분석]], IAST(Interactive AST), 블랙박스 테스팅
|
||||
- **Projects/Contexts**: 웹 취약점 스캔 자동화, OWASP Top 10 방어 전략
|
||||
- **Contradictions/Notes**: DAST는 실행 환경이 필요하므로 개발 초기 단계보다는 배포 가능 시점에 수행하는 것이 일반적입니다 (Shift-Left 전략에서는 SAST가 우선됨).
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
이 문서는 Canonical 문서인 [[보안_및_시스템_신뢰성_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
|
||||
@@ -1,6 +1,19 @@
|
||||
---
|
||||
id: dast_fundamentals_redirect
|
||||
redirect: [[DAST]]
|
||||
id: wiki-2026-0508-dast-fundamentals
|
||||
title: DAST Fundamentals
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: DAST
|
||||
canonical_id: DAST
|
||||
aliases: [dast_fundamentals_redirect]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# Redirect
|
||||
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-8AF01A
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-data-array-textures
|
||||
title: Data Array Textures
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-8AF01A]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Data Array Textures"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Data Array Textures|Data Array Textures]]
|
||||
@@ -18,7 +26,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Data Array Textures"
|
||||
- **구조적 한계 및 단점:** 배열 텍스처 내에 포함되는 모든 텍스처는 반드시 동일한 크기(Dimensions)를 가져야만 합니다 [5]. 다양한 해상도를 섞어 써야 한다면 여러 개의 배열 텍스처를 생성하거나 기존의 텍스처 아틀라스를 사용해야 합니다 [5].
|
||||
- **메모리 및 호환성:** 텍스처 아틀라스가 메모리를 더 밀도 있게 패킹할 수 있는 반면, 배열 텍스처는 런타임에 모든 레이어의 메모리를 사전에 할당해야 하는 메모리 오버헤드가 있습니다 [5]. 이 기술은 [[WebGL|WebGL]]2 환경을 요구하지만, 2025년 기준 브라우저 지원이 매우 우수하여 동일한 크기의 텍스처를 다루는 현대 웹 그래픽 프로젝트에서는 전통적 아틀라싱보다 뛰어난 성능을 발휘합니다 [5].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +39,29 @@ github_commit: "[P-Reinforce] Continuous Worker - Data Array Textures"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,17 +1,20 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-DEV-DEBUGGER-TECHNIQUES
|
||||
title: "고급 디버깅 기법과 런타임 추적 (Debugger Techniques)"
|
||||
category: Unified
|
||||
id: wiki-2026-0508-debugger-techniques
|
||||
title: Debugger Techniques
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["디버거", "Debugger", "디버깅", "중단점", "Breakpoint", "호출 스택"]
|
||||
duplicate_of: ""
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-DEV-DEBUGGER-TECHNIQUES, 디버거, Debugger, 디버깅, 중단점, Breakpoint, 호출 스택]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Debugging", "Runtime", "Analysis", "Troubleshooting", "Tools"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
tags: [Debugging, Runtime, Analysis, Troubleshooting, Tools]
|
||||
raw_sources: [Datacollector_Export_2026-05-02]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[고급 디버깅 기법과 런타임 추적 (Debugger Techniques)]]
|
||||
@@ -47,3 +50,70 @@ github_commit: ""
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 소프트웨어의 동작을 추측이 아닌 사실(Fact) 기반으로 이해하고 제어하기 위한 전문적인 디버깅 표준 정립.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-DFDE-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-deepfake-detection
|
||||
title: Deepfake Detection
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-DFDE-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-reinforced, deepfake, deepfake-detection, security, forensic, synthetic-media, adversarial-ml]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Deepfake-Detection|Deepfake-Detection]]
|
||||
@@ -21,7 +30,7 @@ last_reinforced: 2026-04-20
|
||||
2. **왜 중요한가?**:
|
||||
* 가짜 뉴스의 확산, 명예훼손, 금융 사기 등 AI 가 초래할 수 있는 심각한 사회적 리스크를 관리하는 최후의 보루이기 때문임. (Risk-[[Management|Management]]와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 특정 생성 알고리즘의 결함 정책을 찾는 데 집중했으나, 현대 정책은 생성 알고리즘이 완벽해짐에 따라 '생성 과정에서 발생하는 통계적 특징 정책'을 찾는 일반화된 탐지 정책(Generalizable Detection)으로 전환됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 이제는 단순히 알고리즘 정책만으로는 부족하며, 콘텐츠의 출처 정책(Provenance)을 블록체인 정책 등과 연합하여 인증하는 '신뢰 인프라 정책' 구축이 병행되고 있음.
|
||||
|
||||
@@ -29,3 +38,29 @@ last_reinforced: 2026-04-20
|
||||
- [[Risk-Management|Risk-Management]], [[Sustainability|Sustainability]], Security, [[Synthetic-Data|Synthetic-Data]], [[Biometrics|Biometrics]]
|
||||
- **Key Challenges**: Adversarial attacks on detectors, Deepfake quality improvement.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,47 +1,22 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-DEV-DEVSECOPS-FRAMEWORK
|
||||
title: "DevSecOps 프레임워크와 보안 내재화 전략 (DevSecOps Framework)"
|
||||
category: Unified
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["데브섹옵스", "DevSecOps", "보안 내재화", "Shift-Left Security", "보안 자동화"]
|
||||
duplicate_of: ""
|
||||
id: wiki-2026-0508-devsecops-framework
|
||||
title: DevSecOps Framework
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 보안_및_시스템_신뢰성_표준
|
||||
canonical_id: wiki-2026-0507-039
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Security", "DevOps", "Automation", "SDLC", "Compliance"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[DevSecOps 프레임워크와 보안 내재화 전략 (DevSecOps Framework)]]
|
||||
# Redirect
|
||||
|
||||
## 1. 개요
|
||||
데브섹옵스(DevSecOps)는 소프트웨어 개발 수명 주기(SDLC)의 전 과정에 보안을 통합하여, 보안이 개발의 걸림돌이 아닌 가속기가 되도록 만드는 문화이자 기술적 접근 방식이다. 개발(Dev)과 운영(Ops)의 속도를 유지하면서도, 설계 단계부터 운영까지 보안 검증을 자동화하여 '안전한 소프트웨어'를 지속적으로 인도하는 것을 목표로 한다.
|
||||
|
||||
## 2. 핵심 원칙 및 전략
|
||||
- **보안의 좌측 이동 (Shift-Left Security)**: 운영 단계가 아닌 개발 초기 단계(코드 작성, 커밋, 빌드)에서 보안 검증을 수행하여 수정 비용과 리스크를 최소화.
|
||||
- **자동화된 품질 게이트 (Automated Quality Gate)**: CI/CD 파이프라인에 SAST, DAST, SCA 등 보안 스캐닝 도구를 통합하여, 취약점이 발견된 코드의 병합이나 배포를 자동으로 차단.
|
||||
- **코드로서의 보안 (Security as Code)**: 보안 정책과 규정 준수(Compliance) 요건을 코드로 정의하여 버전 관리하고, 인프라와 함께 배포.
|
||||
- **지속적인 모니터링 및 피드백**: 운영 환경에서의 보안 위협을 실시간으로 감시하고, 이를 다시 개발 단계의 피드백으로 연결하여 시스템 강화.
|
||||
|
||||
## 3. 주요 기술 스택
|
||||
- **SAST (Static Application Security Testing)**: 소스 코드를 실행하지 않고 정적으로 분석하여 하드코딩된 시크릿, 인젝션 결함 등을 탐지.
|
||||
- **SCA (Software Composition Analysis)**: 사용 중인 오픈소스 라이브러리의 취약점과 라이선스 위반 여부 점검.
|
||||
- **DAST (Dynamic Application Security Testing)**: 실행 중인 애플리케이션에 공격을 시뮬레이션하여 런타임 보안 약점 노출.
|
||||
- **ASPM (Application Security Posture Management)**: 산재된 보안 도구의 결과를 통합하여 전체 보안 태세를 관리하고 우선순위화.
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **오탐지(False Positive)의 피로도**: 과도한 보안 경고는 개발자의 생산성을 떨어뜨리고 실제 위협을 간과하게 만듦. 정교한 룰 튜닝과 AI 기반의 필터링 필수.
|
||||
- **파이프라인 성능 저하**: 심층 스캔은 빌드 시간을 늦춘다. 변경된 부분만 스캔하는 증분 스캔(Incremental Scan)이나 비동기 스캔 전략 도입 고려.
|
||||
- **문화적 장벽**: 보안을 '규제'로 인식하는 개발 팀의 저항이 있을 수 있다. 보안 문제를 자동으로 수정(AutoFix)해주는 도구 등을 제공하여 개발 편의성 증대 필요.
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Static_Application_Security_Testing]]: 정적 분석 기술의 상세.
|
||||
- [[Software_Composition_Analysis]]: 오픈소스 종속성 관리 기술.
|
||||
- [[Security_Posture_Management]]: 보안 도구 통합 및 거버넌스 관리.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 보안을 개발의 핵심 요소로 통합하여 기술적 안정성과 비즈니스 신뢰성을 동시에 확보하기 위한 보안 표준 프레임워크 정립.
|
||||
이 문서는 Canonical 문서인 [[보안_및_시스템_신뢰성_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-IP-RIGHTS
|
||||
category: Unified
|
||||
id: wiki-2026-0508-digital-intellectual-property-ri
|
||||
title: Digital Intellectual Property Rights
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AI-IP-RIGHTS]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [Law, Digital, IP, Copyright, Ethics]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Digital Intellectual Property Rights|Digital Intellectual Property Rights]] (디지털 지식 재산권)
|
||||
@@ -21,9 +30,35 @@ last_reinforced: 2026-04-20
|
||||
- **DRM (Digital Rights [[Management|Management]])**: 무단 복제를 막기 위한 기술적 보호 조치.
|
||||
- **Open Movement**: Open Source License (MIT, Apache, GPL) 등을 통해 권리를 공유하며 생태계를 확장하는 방식도 포함된다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- AI 학습 데이터에 대한 저작권 인정 여부가 현재 최대 화두다. "남의 저작물로 학습한 AI의 결과물은 누구의 것인가?"에 대한 법적 공백이 크며, 이는 현재 각국에서 판례를 쌓아가는 격동기에 있다. 지식 재산권의 개념이 '인간 중심'에서 '데이터 중심'으로 재편되고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Ethics-in-AI , Open-Source-Licensing
|
||||
- Problem: Digital-Piracy
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-DIGITAL-THREAD
|
||||
category: Unified
|
||||
id: wiki-2026-0508-digital-thread-integration
|
||||
title: Digital Thread Integration
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AI-DIGITAL-THREAD]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [Manufacturing, DigitalThread, PLM, Integration]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Digital Thread Integration|Digital Thread Integration]] (디지털 스레드 통합)
|
||||
@@ -21,9 +30,35 @@ last_reinforced: 2026-04-20
|
||||
- **Feedback Loop**: 실제 사용 현장의 데이터를 다시 설계로 돌려보내는 루프.
|
||||
- **Benefit**: 리드 타임 단축, 품질 비용 절감, 제품 추적성 완성.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 디지털 스레드를 구축하려면 기업 내 모든 시스템의 '언어(Standard)'가 같아야 한다. 하지만 수십 년 된 레거시 시스템과 최신 플랫폼을 잇는 것은 엄청난 비용과 기술적 난제다. 최근에는 AI가 서로 다른 데이터 포맷을 자동으로 매핑해주는 기술이 스레드 통합의 핵심 동력으로 부상하고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Digital-Twin-Technology|Digital-Twin-Technology]] , Industry-4.0
|
||||
- Foundation:[[_system|system]]s-Engineering
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: P-REINFORCE-AI-056
|
||||
category: Unified
|
||||
id: wiki-2026-0508-digital-twins
|
||||
title: Digital Twins
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AI-056]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.98
|
||||
tags: [digital twin, simulation, iot, cyber-physical]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-06-XX
|
||||
github_commit: "[P-Reinforce] Processed Digital Twins."
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Digital Twins|Digital Twins]] (디지털 트윈)
|
||||
@@ -19,7 +27,7 @@ github_commit: "[P-Reinforce] Processed Digital Twins."
|
||||
2. **모델링/시뮬레이션:** 대상 시스템의 동역학, 열역학 등 복잡한 물리 법칙을 수학적으로 모델링한다. (Computational Geometry + Physics-Based Simulation).
|
||||
3. **실시간 연동 및 예측:** 시뮬레이션 결과(가상)를 바탕으로 실제 장비에 최적화된 제어 명령을 역으로 전송하는 폐쇄 루프 시스템이 필요하다 (Cybernetics / Feedback Control Systems).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 디지털 트윈의 가치는 '데이터를 모으는 것' 자체가 아니라, 수집된 데이터를 통해 **미래를 예측하고(Prediction)** 시스템을 개선하는 데서 나온다. 즉, 목적이 중요하며, 이는 시뮬레이션 이론으로 뒷받침되어야 한다.
|
||||
- **정책 변화:** 산업의 특성상 높은 수준의 실시간 데이터 무결성과 보안(Cybersecurity) 요구사항이 따르므로, 아키텍처 레벨에서 신뢰성을 확보하는 것이 최우선 과제이다.
|
||||
|
||||
@@ -27,4 +35,30 @@ github_commit: "[P-Reinforce] Processed Digital Twins."
|
||||
- Parent: [[Internet of Things (IoT) Telemetry|Internet of Things (IoT) Telemetry]]
|
||||
- Related: [[Computational Geometry|Computational Geometry]] , [[Feedback-Control-Systems|Feedback-Control-Systems]] , [[Real-Time-Game-Engines|Real-Time-Game-Engines]]
|
||||
- Raw Source: 00_Raw/Digital Twins.md
|
||||
---
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-DIGITAL-TWIN
|
||||
category: Unified
|
||||
id: wiki-2026-0508-digital-twin-technology
|
||||
title: Digital Twin Technology
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AI-DIGITAL-TWIN]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [DigitalTwin, Simulation, IoT, Industry40]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Digital-Twin-Technology|Digital-Twin-Technology]] (디지털 트윈 기술)
|
||||
@@ -21,9 +33,58 @@ last_reinforced: 2026-04-20
|
||||
- **Scenario [[Testing|Testing]]**: 위험하거나 비용이 많이 드는 실험을 가상에서 안전하게 수행.
|
||||
- **Domains**: 스마트 시티, 제조 공정, 심지어 디지털 휴먼(의료용 트윈)까지 확장 중.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 디지털 트윈은 '실시간성'이 생명이지만, 수많은 센서 데이터를 지연 없이 가상 공간에 반영하는 네트워크 병목이 큰 과제다. 최근에는 엣지 컴퓨팅([[Edge Computing|Edge Computing]])과 결합하여 데이터 발생 지점에서 즉시 트윈을 업데이트하는 방식으로 발전하고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Industrial Metaverse , Predictive Maintenance (PdM)
|
||||
- Underlying: [[Internet of Things (IoT)|Internet of Things (IoT)]]
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-PSYCH-003
|
||||
category: Unified
|
||||
id: wiki-2026-0508-dopamine
|
||||
title: Dopamine
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-PSYCH-003]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [[Psychology|[Psychology]], neuroscience, dopamine, reward]
|
||||
tags: ["Psychology|[Psychology", neuroscience, dopamine, reward]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "batch-reinforce-03"
|
||||
github_commit: batch-reinforce-03
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# Dopamine Signaling
|
||||
@@ -19,7 +27,7 @@ github_commit: "batch-reinforce-03"
|
||||
- 메조림빅(Mesolimbic) 경로를 통한 쾌락과 동기 부여.
|
||||
- 정교한 보상 체계 설계를 위한 게임화(Gamification)의 생물학적 기초.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 단순 '쾌락 호르몬'이라는 오해를 바로잡고, 학습과 선택의 '가치 평가' 기제로 재정의.
|
||||
- **정책 변화:** 중독(w1) 분석 시 도파민 수용체 하향 조절(Downregulation) 가중치 반영.
|
||||
|
||||
@@ -27,3 +35,29 @@ github_commit: "batch-reinforce-03"
|
||||
- **Parent:** 10_Wiki/💡 Topics/Psychology
|
||||
- **Related:** [[Addiction_Neuroscience|Addiction_Neuroscience]], Reward-System, Neurotransmitter
|
||||
- **Raw Source:** 00_Raw/2026-04-20/Dopamine Signaling.md
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-E9A644
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-draw-call
|
||||
title: Draw Call
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-E9A644]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Draw Call"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Draw Call|Draw Call]]
|
||||
@@ -24,7 +32,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Draw Call"
|
||||
* **배칭([[Batching|Batching]]) 및 병합(Merging):** 구조가 다르더라도 동일한 재질을 공유하는 객체들을 묶어 하나의 드로우 콜로 처리하거나(`BatchedMesh`), 아예 움직이지 않는 정적 객체들의 기하학적 구조를 하나로 병합([[Geometry Merging|Geometry Merging]])하여 호출 횟수를 획기적으로 줄입니다 [9, 15, 16].
|
||||
* **상태 변경 최소화:** 여러 개의 텍스처를 텍스처 아틀라스([[Texture Atlas|Texture Atlas]]es)나 데이터 배열 텍스처([[Data Array Textures|Data Array Textures]])로 결합하여, 드로우 콜 중간에 텍스처를 전환하며 발생하는 GPU 렌더링 상태 변경 오버헤드를 방지합니다 [17-19].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -37,3 +45,29 @@ github_commit: "[P-Reinforce] Continuous Worker - Draw Call"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-EDTR-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-edtech-industry-trends
|
||||
title: Edtech Industry Trends
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-EDTR-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, edtech, education-technology, personalized-learning, adaptive-learning, lms, digital-transformation]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Edtech-Industry-Trends|Edtech-Industry-Trends]]
|
||||
@@ -21,7 +30,7 @@ last_reinforced: 2026-04-20
|
||||
2. **왜 중요한가?**:
|
||||
* 일대다(1:N) 방식의 공장형 교육에서 일대일(1:1) 맞춤형 인재 양성 체계로 전환하는 핵심 인프라이기 때문임.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 오프라인 교육 정책의 '보조 도구'로만 여겼으나, 현대 정책은 하이브리드 학습(Blended Learning)을 넘어 테크 중심의 '디지털 네이티브 교육 정책'이 주류로 부상함(RL Update).
|
||||
- **정책 변화(RL Update)**: 이제는 단순 지식 전달 정책을 넘어, 학생의 감정 정책이나 집중도 정책을 AI 가 분석하여 정서적 케어까지 병행하는 '인간 중심 에듀테크'로 진화 중임. (Social-[[Psychology|Psychology]]와 연결)
|
||||
|
||||
@@ -29,3 +38,29 @@ last_reinforced: 2026-04-20
|
||||
- Personalization, UX-Design-and-Engagement, [[E-Learning-Gamification|E-Learning-Gamification]], Social-Psychology, [[Corporate-LMS-Training|Corporate-LMS-Training]], [[Innovation|Innovation]]
|
||||
- **Key Market Players**: Coursera, Duolingo, Khan Academy.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-EFFI-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-efficiency
|
||||
title: Efficiency
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-EFFI-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, efficiency, [[Optimization|Optimization]], resource-[[Management|Management]], productivity, frugality]
|
||||
tags: [auto-reinforced, efficiency, Optimization, resource-Management, productivity, frugality]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Efficiency|Efficiency]]
|
||||
@@ -21,7 +33,7 @@ last_reinforced: 2026-04-20
|
||||
2. **왜 중요한가?**:
|
||||
* 효율성은 단순히 비용 절감을 넘어, 불가능했던 프로젝트를 '수지 타선이 맞는' 영역으로 끌어들여 상용화 가능하게 만드는 결정적 열쇠임.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 성능(Accuracy)을 위해 효율성(Speed/Cost)을 희생하는 정책이 흔했으나, 현대 정책은 에지(Edge) 기기에서도 고성능을 내야 하는 제약 때문에 '효율성 기반의 고성능 정책([[Distillation|Distillation]], [[Quantization|Quantization]])'이 기본임(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 학습 시 연산 효율 정책을 최우선으로 하여, 무작정 모델을 키우는 대신 정제된 데이터와 최적화된 아키텍처로 '지능 밀도 정책'을 높이려는 경쟁이 시작됨.
|
||||
|
||||
@@ -29,3 +41,52 @@ last_reinforced: 2026-04-20
|
||||
- [[Optimization|Optimization]], [[Distillation|Distillation]], [[Dynamic-Programming|Dynamic-Programming]], [[Economic-Analysis|Economic-Analysis]], Environmental-Impact
|
||||
- **Modern Tech/Tools**: Profilers, Resource monitors, Auto-scaling infrastructure.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-2DCEFC
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-electron-v8-memory-cage
|
||||
title: Electron V8 Memory Cage
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-2DCEFC]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[Electron|Electron]] V8 [[memory|memory]] Cage"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Electron V8 Memory Cage|Electron V8 Memory Cage]]
|
||||
@@ -19,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Electron|Electron]] V8 [[mem
|
||||
|
||||
* **네이티브 모듈 리팩토링 및 대안**: 외부 메모리를 사용하는 네이티브 모듈을 호환되도록 수정하려면 두 가지 주요 접근법이 있습니다 [9]. 첫째는 외부에서 생성된 버퍼 데이터를 [[JavaScript|JavaScript]]에 전달하기 전에 V8 메모리 케이지 내부 영역으로 "복사(Copy)"하는 방법입니다 [9, 10]. 둘째는 데이터를 복사하는 오버헤드를 피하기 위해, 처음부터 V8의 메모리 할당자(예: `napi_create_buffer`)를 사용하여 케이지 내부에 메모리를 할당하는 방법입니다 [9, 10]. 또한 4GB 힙 한계를 극복해야 하는 앱의 경우, 포인터 압축이 해제된 Node.js를 하위 프로세스로 실행하거나 커스텀 Electron 버전을 빌드하는 우회 방법을 사용할 수 있습니다 [11].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -32,3 +43,52 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Electron|Electron]] V8 [[mem
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-ACCESS-MODIFIERS
|
||||
category: Unified
|
||||
confidence_score: 1.00
|
||||
id: wiki-2026-0508-encapsulation-via-access-modifie
|
||||
title: Encapsulation via Access Modifiers
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AI-ACCESS-MODIFIERS]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [OOP, Programming, AccessModifiers, Security]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Encapsulation-via-Access-Modifiers|Encapsulation-via-Access-Modifiers]] (접근 제어자를 통한 캡슐화)
|
||||
@@ -19,9 +31,58 @@ last_reinforced: 2026-04-20
|
||||
- **Default/Package-Private**: (언어마다 다름) 같은 패키지 내 공유.
|
||||
- **Role**: 객체의 내부 상태를 외부로부터 고립시켜 '깨지기 쉬운 코드'가 되는 것을 방지함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- [[JavaScript|JavaScript]]/TypeScript 진영에서는 `#private` 문법이 표준화되기 전까지 접두사 `_`를 관습적으로 사용해왔다. 하지만 이는 강제성이 없어 '의도된 약속'에 의존했다면, 이제는 언어 차원의 강제성을 부여하는 것이 표준이다. 테스트 코드를 위해 `private`을 억지로 여는 것은 부적절한 설계 신호일 수 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Encapsulation-and-Information-Hiding|Encapsulation-and-Information-Hiding]] , [[Interface-Segregation-Principle|Interface-Segregation-Principle]]
|
||||
- Language Specific: TypeScript-Private-Fields
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-GOV-002
|
||||
category: Unified
|
||||
id: wiki-2026-0508-engineering-metrics-dora
|
||||
title: Engineering Metrics (DORA)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-WIKI-GOV-002]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [governance, dora-metrics, engineering-metrics, performance, devops, cycle-time, p-reinforce]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Engineering Metrics (DORA)|Engineering Metrics (DORA]]
|
||||
@@ -26,7 +35,7 @@ DORA 지표는 데브옵스(DevOps) 연구를 통해 입증된 고성과 팀의
|
||||
3. **성과와 리뷰의 상관관계**:
|
||||
* 효율적인 코드 리뷰 프로세스를 갖춘 팀은 그렇지 않은 팀보다 인도 성과가 50% 이상 높게 나타납니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **속도 vs 안정성**: 지표 개선을 위해 속도에만 집착하면 실패율(CFR)이 올라갈 수 있습니다. 4대 지표는 서로 견제하며 균형을 이루어야 진정한 성과 개선으로 이어집니다.
|
||||
- **데이터의 맥락**: 단순 수치만으로 팀을 평가하기보다, 지표의 변화 추이를 통해 팀의 프로세스 건전성을 진단하고 병목을 해결하는 도구로 활용해야 합니다.
|
||||
|
||||
@@ -37,3 +46,29 @@ DORA 지표는 데브옵스(DevOps) 연구를 통해 입증된 고성과 팀의
|
||||
- [[CI-CD Pipeline|CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
|
||||
- [[DORA-Metrics|DORA Metrics]]: 원본 개념 정의.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,31 +1,22 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-DPRI-001
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, data-privacy, security, gdpr, differential-privacy, encryption, sovereignty]
|
||||
last_reinforced: 2026-04-20
|
||||
id: wiki-2026-0508-ensuring-data-privacy
|
||||
title: Ensuring Data Privacy
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 보안_및_시스템_신뢰성_표준
|
||||
canonical_id: wiki-2026-0507-039
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Ensuring-Data-Privacy|Ensuring-Data-Privacy]]
|
||||
# Redirect
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터의 그림자 보호: 디지털 금광인 데이터를 마음껏 활용하면서도, 그 안에 숨겨진 개인의 정체성은 철저히 가리고 보호하여 '편리함'과 '인권' 사이의 위태로운 균형을 기술적으로 사수하는 현대의 자물쇠."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
데이터 프라이버시 보장(Ensuring-Data-Privacy)은 개인정보를 불법적인 접근이나 오남용으로부터 보호하고, 개인이 자신의 데이터에 대해 통제권을 갖게 하는 기술적/법적 체계입니다.
|
||||
|
||||
1. **3대 기술적 방패**:
|
||||
* **Anonymization & Pseudonymization**: 이름 등 식별자를 제거하거나 가명으로 변환.
|
||||
* **Differential Privacy**: 통계적 노이즈를 섞어 특정 개인을 유추하지 못하게 하면서도 데이터 패턴은 유지. ([[Statistics|Statistics]]와 연결)
|
||||
* **Fully Homomorphic Encryption**: 데이터를 복호화하지 않고도 암호화된 상태 그대로 연산(AI 학습 등) 수행. (Security와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 메타데이터 하나로도 개인의 사생활이 발가벗겨지는 시대에, 기업의 신뢰도 정책과 법적 리스크 관리 정책의 핵심이기 때문임. (Risk-[[Management|Management]]와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 "안 지키면 벌금"이라는 수동적 보안 정책 정책이었으나, 현대 정책은 'Privacy by Design' 철학을 통해 제품 설계 단계부터 프라이버시 정책을 핵심 기능으로 탑재하는 능동적 정책으로 전환됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 이제는 단순 보관 정책을 넘어, AI 가 개인정보 정책을 학습할 때 발생하는 정보 유출 정책(Inference Attacks)을 막기 위한 '연합 학습 정책'이나 '합성 데이터 정책' 활용이 필수가 됨. ([[Synthetic-Data|Synthetic-Data]]와 연결)
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Security, [[Risk-Management|Risk-Management]], [[Statistics|Statistics]], [[Synthetic-Data|Synthetic-Data]], Ethics, [[Sustainability|Sustainability]]
|
||||
- **Key Regulations**: GDPR, CCPA, PIPA.
|
||||
---
|
||||
이 문서는 Canonical 문서인 [[보안_및_시스템_신뢰성_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-[[Monorepo|Monorepo]]
|
||||
category: Unified
|
||||
id: wiki-2026-0508-enterprise-scale-monorepo-manage
|
||||
title: Enterprise Scale Monorepo Management
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.99
|
||||
tags: [DevOps, Monorepo, [[Scalability|Scalability]], SoftwareEngineering]
|
||||
tags: [DevOps, Monorepo, Scalability, SoftwareEngineering]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Enterprise-Scale-Monorepo-Management|Enterprise-Scale-Monorepo-Management]] (엔터프라이즈 모노레포 관리)
|
||||
@@ -17,9 +29,58 @@ last_reinforced: 2026-04-20
|
||||
- **Code Ownership**: 파일 경로나 패키지별로 접근 권한 및 승인 프로세스 정의.
|
||||
- **Atomic Commits**: 한 번의 커밋으로 여러 개의 상호 연동된 패키지를 동시에 업데이트.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 모노레포는 만능 해결책이 아니다. 적절한 툴링과 자동화가 없으면 체크아웃 속도 저하와 '의존성 지옥'으로 변질된다. 특히 Git LFS나 Partial Clone 같은 고도화된 Git 전략 없이 몸집만 키우면 개발 생산성이 수직 낙하하므로 초기 인프라 설계가 필수적이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Micro-[[Frontend|Frontend]]s , CI-CD-Pipelines
|
||||
- Tools: Nx , Bazel-Build-System
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-FE FEATURE-FLAGS
|
||||
category: Unified
|
||||
id: wiki-2026-0508-feature-flags
|
||||
title: Feature Flags
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AI-FE FEATURE-FLAGS]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.98
|
||||
tags: [DevOps, FeatureFlags, Deployment, Risk[[Management|Management]]]
|
||||
tags: [DevOps, FeatureFlags, Deployment, RiskManagement]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Feature-Flags|Feature-Flags]] (피처 플래그)
|
||||
@@ -18,9 +27,35 @@ last_reinforced: 2026-04-20
|
||||
- **A/B [[Testing|Testing]]**: 동일한 기능을 두 가지 버전으로 배포하고 성과를 비교.
|
||||
- **Implementation**: `if (flag('new-ui')) { ... }` 식의 조건문으로 감싸고, 중앙 서버(LaunchDarkly 등)에서 상태를 제어한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 피처 플래그를 방치하면 코드 곳곳에 조건문이 남게 되어 기술 부채(Technical Debt)가 급증한다. 기능이 성공적으로 안착했다면 즉시 플래그 코드를 지우는 '클린업 사이클'이 운영 프로세스에 반드시 포함되어야 한다. 또한 플래그 설정값 자체가 하나의 '전역 상태'이므로, 이에 대한 히스토리 관리가 필수적이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[DevOps-and-UX-Convergence|DevOps-and-UX-Convergence]] , Continuous-Deployment
|
||||
- [[Strategy|Strategy]]: Trunk-Based-Development
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-[[Figma|Figma]]-WORKFLOW
|
||||
category: Unified
|
||||
id: wiki-2026-0508-figma-to-code-workflow
|
||||
title: Figma to Code Workflow
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AI-Figma-WORKFLOW]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.99
|
||||
tags: [Design, Development, Figma, Workflow, DevOps]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Figma-to-Code-Workflow|Figma-to-Code-Workflow]] (피그마 기반 협업 워크플로우)
|
||||
@@ -19,9 +31,58 @@ last_reinforced: 2026-04-20
|
||||
4. **Inspection & [[HANDOVER|HANDOVER]]**: 디자이너의 수정 사항이 실시간 동기화되며 슬랙 등으로 알림.
|
||||
- **Collaboration [[Strategy|Strategy]]**: "디자인 수정 -> 코드 반영"이 아니라, 처음부터 공용 **디자인 시스템(Design[[_system|system]])**을 구축하여 사용함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 피그마 시안은 완벽해 보이지만, 실제 데이터가 들어갔을 때(긴 텍스트, 끊긴 이미지 등) 깨지는 경우가 많다. 이를 해결하기 위해 'Storybook'과 피그마를 연동하여 실제 코드로 구현된 컴포넌트를 피그마 안에서 미리 보거나, 'Stitch'와 같은 AI 도구를 통해 피그마 프리뷰를 즉시 작동하는 코드로 변환하는 자동화가 가속화되고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: UI-[[Design-System|Design-System]]s , TailwindCSS-[[Architecture|Architecture]]
|
||||
- Tool: Stitch (MCP Server)
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-524A98
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-figma
|
||||
title: Figma
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-524A98]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Figma"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Figma|Figma]]
|
||||
@@ -19,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Figma"
|
||||
- **베리언트(Variants) 관리**: 포함된 베리언트의 수는 컴포넌트의 업데이트 속도에 직접적인 영향을 미칩니다 [4]. 250여 개의 베리언트를 가진 아이콘 컴포넌트를 여러 개의 개별 컴포넌트로 분리하고 내부의 숨겨진 레이어를 제거한 결과, 업데이트 속도와 전반적인 성능이 대폭 향상된 사례가 있습니다 [7].
|
||||
- **프로토타이핑 권장 사항**: 성능이 매우 중요한 프로토타입의 경우 "Smart Animate"를 사용하는 대신 단순한 화면 전환(simple transitions)이나 베리언트를 활용하는 것이 마이크로 지연을 줄이고 더 부드러운 상호작용을 보장하는 방법입니다 [1].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -32,3 +43,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Figma"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,17 +1,20 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-DEV-FLAME-GRAPHS
|
||||
title: "플레임 그래프를 활용한 호출 스택 시각화 (Flame Graphs)"
|
||||
category: Unified
|
||||
id: wiki-2026-0508-flame-graphs
|
||||
title: Flame Graphs
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["플레임 그래프", "Flame Graphs", "고드름 그래프", "Icicle Graphs", "프로파일링 시각화"]
|
||||
duplicate_of: ""
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-DEV-FLAME-GRAPHS, 플레임 그래프, Flame Graphs, 고드름 그래프, Icicle Graphs, 프로파일링 시각화]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Profiling", "Visualization", "Performance", "Analysis", "Runtime"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
tags: [Profiling, Visualization, Performance, Analysis, Runtime]
|
||||
raw_sources: [Datacollector_Export_2026-05-02]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[플레임 그래프를 활용한 호출 스택 시각화 (Flame Graphs)]]
|
||||
@@ -43,3 +46,70 @@ github_commit: ""
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 추측이 아닌 데이터 기반의 시스템 해독과 성능 개선을 위한 시각적 분석 표준 정립.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-FORMAL-VERIFICATION
|
||||
category: Unified
|
||||
id: wiki-2026-0508-formal-verification-of-software
|
||||
title: Formal Verification of Software
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AI-FORMAL-VERIFICATION]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [SoftwareEngineering, FormalVerification, Math, Security]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Formal-Verification-of-Software|Formal-Verification-of-Software]] (소프트웨어 정식 검증)
|
||||
@@ -18,9 +27,35 @@ last_reinforced: 2026-04-20
|
||||
- **Use Cases**: 원자력 제어 시스템, 항공기 항법 장치, 스마트 컨트랙트(블록체인), OS 커널 보안.
|
||||
- **Benefit**: 인간이 결코 상상할 수 없는 아주 희귀한 상황(Edge Cases)에서의 에러도 100% 발견 및 방지.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 정식 검증은 고도의 수학적 지식이 필요하며, 대규모 소스 코드에 적용하기에 연산 비용이 어마어마하다([[State|State]] Explosion). 최근에는 AI가 복잡한 증명 과정을 대신 생성해주거나 코드를 읽고 정식 모델을 자동 추출하는 연구가 진행되어, 일반 상용 소프트웨어 영역으로 문턱을 낮추고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[SAST (Static Application Security Testing)|SAST (Static Application Security [[Testing]])]] , Cyber-Security
|
||||
- Concept: [[Logic|Logic]]-And-Mathematics
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-7A315B
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-frustum-culling
|
||||
title: Frustum Culling
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-7A315B]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Frustum Culling"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Frustum Culling|Frustum Culling]]
|
||||
@@ -24,7 +35,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Frustum Culling"
|
||||
2. **GPU 컴퓨트 컬링 및 간접 그리기([[Indirect Draw|Indirect Draw]])**: WebGPU 환경의 컴퓨트 셰이더([[Compute Shader|Compute Shader]])를 활용해 GPU가 직접 인스턴스의 가시성을 판별하도록 처리하는 방식이다 [8, 9]. 판별 결과는 GPU 내부 버퍼에 저장되어 `drawIndirect` 명령으로 즉각 렌더링되므로, CPU 연산 및 CPU-GPU 간 데이터 전송 병목을 완벽히 회피할 수 있다 [9].
|
||||
3. **확장 라이브러리 도입**: BVH(Bounding Volume Hierarchy)를 이용한 고속 공간 쿼리와 `Instanced[[BufferAttribute|BufferAttribute]]`를 활용한 간접 참조(Indirection) 방식을 통해 기존 InstancedMesh를 확장하여 효율적인 개별 컬링을 제공하는 `[[InstancedMesh2|InstancedMesh2]]`와 같은 외부 라이브러리 활용이 대안이 될 수 있다 [10-12].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -37,3 +48,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Frustum Culling"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-4349BD
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-geometry-merging
|
||||
title: Geometry Merging
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-4349BD]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Geometry Merging"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Geometry Merging|Geometry Merging]]
|
||||
@@ -25,7 +36,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Geometry Merging"
|
||||
* **실무적 대안 및 하이브리드 전략:**
|
||||
절두체 컬링의 문제를 완화하기 위해 공간적 인접성에 따라 메쉬를 나누어 병합하는 **'타일형 병합(Tiled merging)'** 전략이 권장됩니다 [4]. 또한, 메모리와 유연성 문제를 해결하기 위해 동적인 장면이 아니고 모델 크기가 작을 때(< 1GB)에만 병합을 적용하거나 [9], 정적인 저폴리곤 객체는 병합(Merging)하고 동적이거나 고폴리곤인 객체는 `[[InstancedMesh|InstancedMesh]]` 혹은 `BatchedMesh`를 사용하는 **하이브리드 시스템**이 대안으로 활용되기도 합니다 [10, 11].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -38,3 +49,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Geometry Merging"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-D96374
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-global-network-positioning-gnp
|
||||
title: Global Network Positioning (GNP)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-D96374]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Global Network Positioning (GNP)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Global Network Positioning (GNP)|Global Network Positioning (GNP]]
|
||||
@@ -19,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Global Network Positioning (GN
|
||||
* **구글(Google)의 대규모 구현 방식:** 구글은 자사의 콘텐츠 전송 네트워크(CDN)에 GNP를 통합하여 수백만 명의 클라이언트를 포지셔닝하는 대규모 지연 시간 추정 시스템을 구현했습니다 [6, 7]. 이 시스템은 대상 노드의 능동적 참여에 의존하지 않고 랜드마크 측에서 수동적으로(passively) 지연 시간을 측정하며, 확장 가능한 중앙 집중식 스케줄러를 사용하여 네트워크 오버헤드와 랜드마크의 과부하를 정밀하게 제어합니다 [6, 7].
|
||||
* **좌표의 시간에 따른 안정성 (Coordinate Stability):** 네트워크 라우팅 변경이나 일시적인 혼잡 등으로 인해 GNP 좌표는 시간이 지나면서 초기 값에서 서서히 벗어나는(drift) 경향이 있습니다 [8]. 구글의 분석에 따르면 1주일 후 전체 노드의 25%가 초기값에서 33밀리초(ms) 이상 벗어났지만, 매일 좌표를 재계산(daily recomputation)할 경우 75%의 좌표를 초기값의 6ms 이내로 안정하게 유지할 수 있습니다 [8].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -32,3 +43,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Global Network Positioning (GN
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-A3BFE1
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-google-code-jam-dataset
|
||||
title: Google Code Jam Dataset
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-A3BFE1]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Google Code Jam Dataset"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Google Code Jam Dataset|Google Code Jam Dataset]]
|
||||
@@ -24,7 +35,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Google Code Jam Dataset"
|
||||
* **적대적 환경(Adversarial) 연구**
|
||||
Simko 등은 인간 프로그래머가 다른 사람의 코딩 스타일을 의도적으로 모방하거나 자신의 스타일을 숨기려 할 때 기존의 기계학습 기반 작성자 식별 모델이 얼마나 취약한지를 평가하는 사용자 연구에서 이 데이터셋을 활용했습니다 [11], [12].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -37,3 +48,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Google Code Jam Dataset"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-E05076
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-hmd-head-mounted-display-기반-엑서게임
|
||||
title: HMD(Head Mounted Display) 기반 엑서게임 환경
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-E05076]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - HMD(Head-Mounted Display) 기반 엑서게임 환경"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[HMD(Head-Mounted Display) 기반 엑서게임 환경|HMD(Head-Mounted Display) 기반 엑서게임 환경]]
|
||||
@@ -18,7 +26,7 @@ github_commit: "[P-Reinforce] Continuous Worker - HMD(Head-Mounted Display) 기
|
||||
- **시각적 부작용 및 노출 시간의 영향:** HMD 사용 시 발생하는 눈의 폭주(Vergence)와 조절(Accommodation) 간의 불일치는 깊이 지각에 혼란을 주어 두통, 눈의 피로, 시야 겹침 현상 등의 안구 운동 관련 증상을 초래할 수 있습니다 [3, 4]. 인기 VR 엑서게임인 '[[Beat Saber|Beat Saber]]'를 활용한 연구에 따르면, 게임 노출 시간이 길어질수록(예: 10분 대비 50분) 즉각적인 멀미 증상과 시각/인지적 영향이 유의미하게 증가하는 것으로 나타났습니다 [5-7].
|
||||
- **사후 회복 및 안전 권고:** 대부분의 사용자는 장시간 HMD 엑서게임을 수행한 후 멀미 증상이나 인지 및 시각적 변화를 겪더라도, VR 기기를 벗고 약 40분의 휴식을 취하면 기준선(Baseline) 수준으로 정상 회복됩니다 [6, 7]. 따라서 HMD 엑서게임을 안전하게 활용하기 위해서는 긴 시간 플레이하기 전 짧은 세션을 통해 멀미 발생 여부를 테스트하고, 플레이 종료 후 충분한 대기 및 휴식 시간을 갖는 것이 권장됩니다 [8].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +39,29 @@ github_commit: "[P-Reinforce] Continuous Worker - HMD(Head-Mounted Display) 기
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-05BDE3
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-high-resolution-time
|
||||
title: High Resolution Time
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-05BDE3]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - High Re[[Solution|Solution]] Time"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[High Resolution Time|High Resolution Time]]
|
||||
@@ -18,7 +26,7 @@ github_commit: "[P-Reinforce] Continuous Worker - High Re[[Solution|Solution]] T
|
||||
- **컨텍스트에 따른 해상도 차이:** High Resolution Time 사양(HR-time spec)은 크로스 오리진 격리(cross-origin isolated) 컨텍스트에서는 5µs로, 격리되지 않은(non-isolated) 컨텍스트에서는 100µs(또는 구현이 선호하는 더 거친 수준)로 해상도를 제한하도록 권장한다 [2].
|
||||
- **WebGPU 타임스탬프 쿼리([[Timestamp Queries|Timestamp Queries]]) 연동:** WebGPU 환경에서 GPU 연산 소요 시간을 측정하는 타임스탬프 쿼리 기능도 타이밍 공격의 위험이 있어 정밀도 조정이 필요했다 [3-5]. 이에 따라 GPU for the Web 커뮤니티 그룹은 타임스탬프 값을 HR-time 사양을 참조하여 격리 여부와 무관하게 비격리 해상도 기준인 100µs로 제한([[Quantization|Quantization]])하기로 합의하여 일관성 있는 보안 조치를 적용하였다 [6-8].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +39,29 @@ github_commit: "[P-Reinforce] Continuous Worker - High Re[[Solution|Solution]] T
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-9068BA
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-husky
|
||||
title: Husky
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-9068BA]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Husky"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Husky|Husky]]
|
||||
@@ -21,7 +32,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Husky"
|
||||
* **GUI 및 버전 관리자 이슈:** SourceTree나 VS Code 같은 Git GUI 도구나 Node 버전 관리자(nvm, fnm 등)를 사용할 때 `PATH`가 제대로 초기화되지 않아 훅에서 명령어를 찾을 수 없는 오류(`command not found`)가 발생할 수 있습니다. Husky는 각 훅을 실행하기 전에 `~/.config/husky/init.sh`를 소싱(source)하여 이 문제를 우회할 수 있도록 지원합니다 [13, 14].
|
||||
* **서브모듈 및 중첩 패키지:** 모노레포나 서브모듈([[Submodules|Submodules]]) 구조에서는 최상위 루트가 아닌 하위 디렉토리에 패키지가 위치할 수 있습니다. Git은 기본적으로 리포지토리 루트에서 훅을 실행하므로, 이런 경우 `prepare` 스크립트 내에서 경로를 이동하거나(cd) 서브모듈의 컨텍스트 내에 Husky를 개별적으로 설치하여 동작하도록 구성해야 합니다 [14, 15].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -34,3 +45,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Husky"
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-A6562D
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-ibm-가비지-컬렉션
|
||||
title: IBM 가비지 컬렉션
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-A6562D]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - IBM 가비지 컬렉션"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[IBM 가비지 컬렉션|IBM 가비지 컬렉션]]
|
||||
@@ -27,7 +38,7 @@ github_commit: "[P-Reinforce] Continuous Worker - IBM 가비지 컬렉션"
|
||||
- **약한 참조 처리 (Weak [[Reference|Reference]] [[Processing|Processing]])**
|
||||
- GC 주기 동안 소프트(Soft), 약한(Weak), 팬텀(Phantom) 참조를 처리하여 특정 참조가 유지되거나 삭제되도록 관리합니다 [14]. 소프트 참조는 메모리 부족 오류가 발생할 가능성이 있을 때만 지워지며, 약한 참조와 팬텀 참조는 참조 객체가 마크되지 않을 때 즉시 혹은 자동으로 지워집니다 [15].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -40,3 +51,52 @@ github_commit: "[P-Reinforce] Continuous Worker - IBM 가비지 컬렉션"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-8A58BF
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-ifcjs-fragment
|
||||
title: IFCjs (Fragment)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-8A58BF]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[IFCjs|IFCjs]] (Fragment)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[IFCjs (Fragment)|IFCjs (Fragment]]
|
||||
@@ -27,7 +35,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[IFCjs|IFCjs]] (Fragment)"
|
||||
* **성능 및 결과:**
|
||||
초기 프로토타입 구현 결과, 1,000개의 의자와 4개의 벽으로 구성된 씬을 단 3번의 드로우 콜(선택용 드로우 콜 제외)과 10MB 미만의 메모리만으로 렌더링하는 데 성공했다 [6]. 또한 100MB 이상의 대형 IFC 모델을 모바일 기기에서도 Autodesk Forge에 필적하는 속도로 빠르게 로드하는 훌륭한 성능을 보여주었다 [8].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -40,3 +48,29 @@ github_commit: "[P-Reinforce] Continuous Worker - [[IFCjs|IFCjs]] (Fragment)"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-659684
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-ifcjs
|
||||
title: IFCjs
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-659684]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - IFCjs"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[IFCjs|IFCjs]]
|
||||
@@ -21,7 +32,7 @@ github_commit: "[P-Reinforce] Continuous Worker - IFCjs"
|
||||
- **객체별 렌더링 전략:** 벽이나 바닥과 같이 고유하면서도 폴리곤 수가 적은(Low-poly) 객체들은 `BufferGeometry`로 병합하여 처리하고, 가구나 문, 창문과 같이 폴리곤 수가 많고(High-poly) 반복되는 객체들은 `InstancedMesh`를 생성하여 처리합니다 [6].
|
||||
- **결과 및 성과:** 이 시스템은 모든 파편(Fragment)이 비슷한 수의 정점과 드로우 콜을 가지도록 균형을 맞춰 효율성을 극대화하며, Autodesk Forge의 로딩 속도에 근접하는 수준의 성능을 입증했습니다 [3, 6].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -34,3 +45,52 @@ github_commit: "[P-Reinforce] Continuous Worker - IFCjs"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: 550e8400-e29b-41d4-a716-446655440005
|
||||
category: Unified
|
||||
id: wiki-2026-0508-incremental-build
|
||||
title: Incremental Build
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [550e8400-e29b-41d4-a716-446655440005]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.97
|
||||
tags: [build, devops, automation, versioning]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-21
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 증분형 빌드 관리 시스템
|
||||
@@ -18,7 +30,7 @@ last_reinforced: 2026-04-21
|
||||
- 쉘 스크립트를 이용한 자동 버전 카운팅 로직 구현.
|
||||
- Vite 설정의 동적 `outDir` 제어 패턴 확립.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 기존의 덮어쓰기 방식(Overwrite) 빌드를 버전 보존 방식으로 전환.
|
||||
- **정책 변화:** 모든 빌드 요청은 반드시 고유한 버전 번호를 가져야 함.
|
||||
|
||||
@@ -27,6 +39,55 @@ last_reinforced: 2026-04-21
|
||||
- **Related:** 10_Wiki/Projects/Skybound/Architecture_Refactor
|
||||
- **Raw Source:** 00_Raw/2026-04-21-Skybound_Incremental_Build_System
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture_Refactor]]
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-INST-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-inferential-statistics
|
||||
title: Inferential Statistics
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-INST-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, inferential-[[Statistics|Statistics]], statistics, data-[[Analysis|Analysis]], [[Hypothesis-Testing|Hypothesis-Testing]], sampling]
|
||||
tags: [auto-reinforced, inferential-Statistics, statistics, data-Analysis, Hypothesis-Testing, sampling]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Inferential-Statistics|Inferential-Statistics]]
|
||||
@@ -20,7 +32,7 @@ last_reinforced: 2026-04-20
|
||||
2. **왜 중요한가?**:
|
||||
* 모든 실험과 데이터 분석의 신뢰성을 결정하는 '판사' 역할을 수행함. ([[Inductive-Reasoning|Inductive-Reasoning]]의 수학적 도구)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 작은 표본으로 거대 집단을 설명하려는 '희소 데이터 정책'이 주류였으나, 현대 정책은 방대한 빅데이터 정책 하에서도 '상관관계와 인과관계 정책'을 엄격히 구분하고 변수 간의 복잡한 영향을 파악하는 데 집중함(RL Update).
|
||||
- **정책 변화(RL Update)**: 단순히 p-value 수치에만 목매는 정책(P-hacking)을 지양하고, 모델의 불확실성을 더 정교하게 다루는 '베이지안 추론 통계 정책'으로의 전환 정책이 가속화되고 있음. (Inductive-[[Reasoning|Reasoning]]와 연결)
|
||||
|
||||
@@ -28,3 +40,52 @@ last_reinforced: 2026-04-20
|
||||
- [[Inductive-Reasoning|Inductive-Reasoning]], [[Analysis|Analysis]], [[Data Cleaning Algorithms|Data Cleaning Algorithms]], [[Decision Theory|Decision Theory]], [[Epistemology|Epistemology]]
|
||||
- **Modern Tech/Tools**: R, Python (SciPy), Bayesian A/B testing, Confidence intervals.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-INSO-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-information-society
|
||||
title: Information Society
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-INSO-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.88
|
||||
tags: [auto-reinforced, information-society, digital-transformation, data-economy, network-society, social-change]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Information-Society|Information-Society]]
|
||||
@@ -21,7 +33,7 @@ last_reinforced: 2026-04-20
|
||||
2. **도전 과제**:
|
||||
* 정보 격차(Digital Divide), 데이터 프라이버시, 허위 정보의 확산. ([[Ethics & AI|Ethics & AI]]와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 정보의 확산 자체가 '민주화와 자유 정책'을 가져올 것이라 낙관했으나, 현대 정책은 정보 과잉으로 인한 '관심 경제 정책'과 '알고리즘 확증 편향 정책'이라는 어두운 면에 더 주목함(RL Update).
|
||||
- **정책 변화(RL Update)**: 단순히 정보를 소유하는 정책을 넘어, AI라는 거대 지능 정책을 누가 소유하고 통제하느냐가 국가와 개인의 생존을 결정하는 '지능 정보 사회 정책'으로 급격히 재편 중임.
|
||||
|
||||
@@ -29,3 +41,52 @@ last_reinforced: 2026-04-20
|
||||
- [[Internet of Things (IoT)|Internet of Things (IoT)]], [[Global-Standard|Global-Standard]], [[Ethics & AI|Ethics & AI]], [[Intangible-Capital|Intangible-Capital]], [[Distributed-Systems|Distributed-Systems]]
|
||||
- **Modern Tech/Tools**: Big Data, Cloud computing, [[Blockchain|Blockchain]], [[AI Governance|AI Governance]] frameworks.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,29 +1,22 @@
|
||||
---
|
||||
id: SEC-INPUT-001
|
||||
category: Unified
|
||||
confidence_score: 1.0
|
||||
tags: [security, software-engineering, input-validation, data-inte[[Grit|Grit]]y, defensive-programming]
|
||||
last_reinforced: 2026-04-26
|
||||
id: wiki-2026-0508-input-validation-strategies
|
||||
title: Input Validation Strategies
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 보안_및_시스템_신뢰성_표준
|
||||
canonical_id: wiki-2026-0507-039
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# Input Validation Strategies (입력 검증 전략)
|
||||
# Redirect
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "모든 외부 입력을 잠재적 위협으로 간주하고, 시스템의 경계에서 데이터의 형식과 의도를 엄격히 심사하라" — 사용자나 다른 시스템으로부터 유입되는 데이터가 기대하는 형식, 길이, 타입에 맞는지 확인하여 인젝션 공격이나 런타임 오류를 원천 차단하는 방어적 설계 전략.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Never Trust User Input" — 신뢰할 수 없는 경계(Trust Boundary)를 통과하는 모든 데이터에 대해 화이트리스트 기반의 검증을 수행하고, 안전한 형태로 변환(Sanitization)하여 시스템 내부로 전달하는 필터링 패턴.
|
||||
- **주요 전략:**
|
||||
- **Type Checking:** 기대하는 데이터 타입(String, Int 등) 여부 확인.
|
||||
- **Range & Format Validation:** 숫자의 범위나 이메일/날짜 등의 정규식 패턴 검치.
|
||||
- **Whitelisting:** 허용된 값의 목록 외에는 모두 거부 (가장 안전한 방식).
|
||||
- **Sanitization:** 위험한 특수 문자(<, >, ' 등)를 안전한 문자로 치환.
|
||||
- **의의:** SQL Injection, XSS, Buffer Overflow 등 고질적인 소프트웨어 보안 취약점의 80% 이상을 예방할 수 있는 가장 기본적이고 강력한 보안 수단.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순한 문법적 검증에서 벗어나, 이제는 LLM 시대에 맞춰 '프롬프트 인젝션'과 같은 의미론적 위협(Semantic Threat)을 감지하고 차단하는 지능형 검증이 필수적으로 요구됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트에게 전달되는 모든 사용자 발화와 외부 파일 데이터를 처리하기 전, 보안 스캔 및 형식 검증 레이어를 거치도록 강제함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Software-Architecture-Patterns, Cloud-Security-[[Mastery|Mastery]], Data-Privacy-Foundations, [[LLM-Security-and-Safety|LLM-Security-and-Safety]]
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Input-Validation-Strategies.md
|
||||
이 문서는 Canonical 문서인 [[보안_및_시스템_신뢰성_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-0E2591
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-instancedmesh2
|
||||
title: InstancedMesh2
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-0E2591]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[InstancedMesh|InstancedMesh]]2"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[InstancedMesh2|InstancedMesh2]]
|
||||
@@ -23,7 +34,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[InstancedMesh|InstancedMesh]
|
||||
* **간접 참조(Indirection) 기반 인덱싱:** 라이브러리 초기 버전과 달리, `Instanced[[BufferAttribute|BufferAttribute]]`를 활용하여 렌더링될 인스턴스 인덱스를 간접적으로 관리한다 [12]. 이는 GPU로 데이터를 보내기 전 컬링, 선택적 렌더링, 정렬 작업을 배열의 물리적 재정렬 없이 빠르게 수행할 수 있게 한다 [12].
|
||||
* **SquareDataTexture의 활용:** 인스턴스의 행렬(Matrix) 및 주요 데이터를 저장하는 데 `DataTexture`의 확장 버전인 `SquareDataTexture`를 사용한다 [12]. 이 방식은 부분 업데이트(Partial Updates)를 지원하여 전체 데이터를 갱신할 필요 없이 변경된 일부 인스턴스의 정보만 갱신하도록 돕는다 [8, 12].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -38,3 +49,52 @@ github_commit: "[P-Reinforce] Continuous Worker - [[InstancedMesh|InstancedMesh]
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-INVE-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-inversion
|
||||
title: Inversion
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-INVE-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-reinforced, inversion, [[Mental-Models|Mental-Models]], [[Problem-Solving|Problem-Solving]], carl-jacobi, [[Strategy|Strategy]]]
|
||||
tags: [auto-reinforced, inversion, Mental-Models, Problem-Solving, carl-jacobi, Strategy]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Inversion|Inversion]]
|
||||
@@ -22,7 +31,7 @@ last_reinforced: 2026-04-20
|
||||
* **Pre-mortem**: 프로젝트 시작 전 "망했다"고 가정하고 그 이유를 찾아보기.
|
||||
* **Security**: "어떻게 하면 이 철통 보안을 뚫을 수 있을까?" 고민하는 화이트 해커의 시각.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 긍정적인 확신 정책(Positive Thinking)만이 강조되었으나, 현대 정책은 최악의 상황 정책(Worst-case Scenario)을 먼저 관리하여 생존 가능성 정책을 높이는 인버전 정책이 더 강건하다고 평가함(RL Update). ([[Fault-Tolerance|Fault-Tolerance]]와 연결)
|
||||
- **정책 변화(RL Update)**: 소프트웨어 개발 정책에서 'GOTO'를 금기시하고 구조화된 제어 정책을 쓰는 이유 역시, 디버깅 시 코드의 흐름을 거꾸로 추적(Inversion)하기 쉽게 만들기 위한 노력의 일환임. ([[Logic|Logic]]와 연결)
|
||||
|
||||
@@ -30,3 +39,29 @@ last_reinforced: 2026-04-20
|
||||
- [[Logic|Logic]], [[Fault-Tolerance|Fault-Tolerance]], [[Complexity Theory|Complexity Theory]], [[Decision Theory|Decision Theory]], [[Cognitive Biases|Cognitive Biases]]
|
||||
- **Modern Tech/Tools**: Charlie Munger's [[Mental Models|Mental Models]], Pre-mortem [[Analysis|Analysis]], Test-driven development (TDD).
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,29 +1,22 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-002
|
||||
category: Unified
|
||||
confidence_score: 0.91
|
||||
tags: [automation, iot, telemetry, connectivity]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "batch-reinforce-07"
|
||||
id: wiki-2026-0508-iot
|
||||
title: IoT
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 클라우드_인프라_및_IaC_운영_표준
|
||||
canonical_id: wiki-2026-0507-028
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Internet of Things (IoT)|Internet of Things (IoT]] Telemetry
|
||||
# Redirect
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 보이지 않는 물리 현상을 디지털 신호로 변환하여 네트워크로 송출함으로써 만물에 '말문'을 틔워주는 기술.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 센서 데이터 스트리밍, 게이트웨이 집계, 클라우드 분석으로 이어지는 엔드-투-엔드 데이터 흐름 패턴.
|
||||
- **세부 내용:**
|
||||
- 저전력 광대역 네트워크(LPWAN)를 통한 광범위한 연결성 확보.
|
||||
- MQTT, HTTP 등 경량화된 프로토콜을 사용한 실시간 텔레메트리 전송.
|
||||
- 엣지 컴퓨팅([[Edge Computing|Edge Computing]])을 통한 데이터 필터링 및 실시간성 강화.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단방향 데이터 수집에서 이제는 양방향 제어 및 실시간 자가 진단이 가능한 지능형 IoT로 진화.
|
||||
- **정책 변화:** 구조적 연결성(w2) 관점에서 [[Digital_Twin|Digital_Twin]]의 실시간성을 보장하는 핵심 인프라로 정의.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** 10_Wiki/💡 Topics/Automation
|
||||
- **Related:** [[SCADA|SCADA]], Digital_Twin, [[Edge-Computing|Edge-Computing]]
|
||||
- **Raw Source:** 00_Raw/2026-04-20/Internet of Things (IoT) Telemetry.md
|
||||
이 문서는 Canonical 문서인 [[클라우드_인프라_및_IaC_운영_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
|
||||
+61
-1
@@ -1,3 +1,20 @@
|
||||
---
|
||||
id: wiki-2026-0508-issue-001-combat-reference-error
|
||||
title: Issue 001 Combat Reference Error Troubleshooting
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# Issue #001: Combat System ReferenceError (Case Study)
|
||||
|
||||
개발 중 발생한 변수 선언 누락으로 인한 시스템 크래시 사례 분석입니다.
|
||||
@@ -21,7 +38,50 @@
|
||||
**Status**: Case Closed
|
||||
**Type**: Syntax Integrity / Troubleshooting
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Testing]]
|
||||
* [[_system]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-EC8C7D
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-jpeg-xl
|
||||
title: JPEG XL
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-EC8C7D]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - JPEG XL"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[JPEG XL|JPEG XL]]
|
||||
@@ -26,7 +37,7 @@ github_commit: "[P-Reinforce] Continuous Worker - JPEG XL"
|
||||
* **Apple Safari:** 다른 브라우저들이 도입을 미루는 동안, 애플은 2023년 9월에 JPEG XL 지원을 도입하며 선도적인 움직임을 보였다 [2].
|
||||
* **Mozilla Firefox:** 모질라는 초기에 저수준(low-level) 언어로 작성된 복잡한 새 코드가 가져올 수 있는 보안 위험성 때문에 지원을 꺼렸으나, 구글과 Rust 기반 디코더에 대해 논의한 후 2024년 9월에 긍정적인 방향으로 입장을 변경했다 [3].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -39,3 +50,52 @@ github_commit: "[P-Reinforce] Continuous Worker - JPEG XL"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-A0754B
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-joern
|
||||
title: Joern
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-A0754B]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Joern"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Joern|Joern]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Joern"
|
||||
* **바이너리 코드 분석을 위한 파싱**: 실행 파일(바이너리)의 작성자를 식별하기 위해 하이브리드 접근법을 사용한 Caliskan-Islam 등의 연구에서, 디컴파일된 소스 코드를 구문 분석하기 위해 Joern이 사용되었습니다 [1].
|
||||
* **AST 기반 특징 추출 지원**: 연구팀은 Joern을 통해 코드를 파싱한 뒤, 식별 모델 학습에 필요한 AST 기반의 특징(Feature)들(예: 노드 타입 유니그램 등)을 추출할 수 있었습니다 [1].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Joern"
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,17 +1,20 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-DEV-LOGGING-ERROR-HANDLING
|
||||
title: "시스템 가시성과 런타임 진단 (Logging & Error Handling)"
|
||||
category: Unified
|
||||
id: wiki-2026-0508-logging-and-error-handling
|
||||
title: Logging and Error Handling
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["Logging", "Error Handling", "로그", "에러 처리", "스택 트레이스", "중앙 집중식 로깅"]
|
||||
duplicate_of: ""
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-DEV-LOGGING-ERROR-HANDLING, Logging, Error Handling, 로그, 에러 처리, 스택 트레이스, 중앙 집중식 로깅]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Observability", "Logging", "Error_Handling", "Diagnostics", "System_Stability"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
tags: [Observability, Logging, Error_Handling, Diagnostics, System_Stability]
|
||||
raw_sources: [Datacollector_Export_2026-05-02]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[시스템 가시성과 런타임 진단 (Logging & Error Handling)]]
|
||||
@@ -47,3 +50,70 @@ github_commit: ""
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 시스템의 런타임 거동을 투명하게 파악하고 견고한 에러 복구 체계를 구축하여 소프트웨어의 신뢰성과 운영 효율성을 극대화하기 위한 가시성 표준 정립.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: d2e3f4g5-h6i7-8j9k-0l1m-2n3o4p5q6r7s
|
||||
category: Unified
|
||||
id: wiki-2026-0508-mece-principle
|
||||
title: MECE Principle
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [d2e3f4g5-h6i7-8j9k-0l1m-2n3o4p5q6r7s]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [[MECE|[MECE]], logic, structuring, consulting, issue-tree, profitability-framework]
|
||||
tags: ["MECE|[MECE", logic, structuring, consulting, issue-tree, profitability-framework]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-27
|
||||
github_commit: "[[P-Reinforce|P-Reinforce]]-logic-update"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[MECE Principle|MECE Principle]]
|
||||
@@ -29,3 +40,57 @@ github_commit: "[[P-Reinforce|P-Reinforce]]-logic-update"
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-D3B770
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-major-gc
|
||||
title: Major GC
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-D3B770]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Major GC"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Major GC|Major GC]]
|
||||
@@ -25,7 +33,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Major GC"
|
||||
* **Concurrent Marking (동시 마킹):** 자바스크립트가 메인 스레드에서 실행되는 동안 백그라운드 헬퍼 스레드에서 마킹 작업을 전적으로 동시에 수행합니다 [8, 22].
|
||||
* **Parallel Compaction (병렬 압축):** 메인 스레드와 여러 헬퍼 스레드가 함께 압축 및 포인터 업데이트 작업을 나누어 병렬로 처리합니다 [25, 26].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -40,3 +48,29 @@ github_commit: "[P-Reinforce] Continuous Worker - Major GC"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-MAAN-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-malware-analysis
|
||||
title: Malware Analysis
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-MAAN-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.91
|
||||
tags: [auto-reinforced, malware-[[Analysis|Analysis]], cybersecurity, reverse-engineering, security, forensics]
|
||||
tags: [auto-reinforced, malware-Analysis, cybersecurity, reverse-engineering, security, forensics]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Malware-Analysis|Malware-Analysis]]
|
||||
@@ -20,7 +29,7 @@ last_reinforced: 2026-04-20
|
||||
2. **왜 중요한가?**:
|
||||
* 날로 교묘해지는 사이버 공격(랜섬웨어, 스파이웨어 등)의 근본 원인을 파악하고, 백신 개발 및 시스템 보안 수준을 높이는 데 필수적임. ([[Fault-Tolerance|Fault-Tolerance]]와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 사람이 일일이 코드를 분석하는 정책이었으나, 현대 정책은 지능형 악성코드가 분석을 감지하고 멈추거나 코드를 변형하는 '안티-분석 정책'을 사용하므로 이를 무력화하는 고도의 심리전 정책이 수반됨(RL Update).
|
||||
- **정책 변화(RL Update)**: AI가 악성코드를 자동 분석하고 실시간으로 변종을 탐지하는 'AI 기반 위협 탐지 정책'과, 역으로 AI를 이용해 더 정교한 악성코드를 만드는 '공격의 자동화 정책' 사이의 끝없는 군비 경쟁 시대로 진입함.
|
||||
|
||||
@@ -28,3 +37,29 @@ last_reinforced: 2026-04-20
|
||||
- [[Fault-Tolerance|Fault-Tolerance]], [[Hardware|Hardware]], [[Logic|Logic]], [[Ethics & AI|Ethics & AI]], [[Information-Society|Information-Society]]
|
||||
- **Modern Tech/Tools**: IDA Pro, Ghidra, OllyDbg, Cuckoo Sandbox, Wireshark.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-50957B
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-mark-sweep-compact-메이저-gc
|
||||
title: Mark Sweep Compact(메이저 GC)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-50957B]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[Mark-Sweep|Mark-Sweep]]-Compact(메이저 GC)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Mark-Sweep-Compact(메이저 GC)|Mark-Sweep-Compact(메이저 GC]]
|
||||
@@ -32,7 +40,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Mark-Sweep|Mark-Sweep]]-Comp
|
||||
* 이를 방지하고 지연 시간(Latency)을 최소화하기 위해, V8의 최신 GC([[Orinoco|Orinoco]]) 및 특정 JVM 정책은 작업을 여러 번 나누어 수행하는 점진적 마킹([[Incremental Marking|Incremental Marking]])과 힙 페이지의 청소를 지연시키는 지연 스위핑(Lazy sweeping) 기법을 사용합니다 [18-21].
|
||||
* 더 나아가 애플리케이션의 메인 스레드와 여러 헬퍼 스레드를 동시에 활용하는 병렬(Parallel) 및 동시(Concurrent) 처리 기법을 적용하여 전체 애플리케이션의 일시 정지 시간을 획기적으로 줄이고 있습니다 [22-25].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -45,3 +53,29 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Mark-Sweep|Mark-Sweep]]-Comp
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,9 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-MELI-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-media-literacy
|
||||
title: Media Literacy
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-MELI-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.87
|
||||
tags: [auto-reinforced, media-literacy, critical-thinking, digital-citizenship, information-literacy]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Media-Literacy|Media-Literacy]]
|
||||
@@ -21,7 +30,7 @@ last_reinforced: 2026-04-20
|
||||
2. **왜 중요한가?**:
|
||||
* 가짜 뉴스(Fake News)와 확증 편향(Echo Chamber)이 민주주의와 개인의 판단을 위협하는 시대에서, 진실을 수호하는 인지적 방어막이기 때문임. ([[Information-Society|Information-Society]]의 핵심 기술)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 신문과 TV 뉴스의 편향 정책에 주목했으나, 현대 정책은 알고리즘에 의해 자동 생성되는 추천 정책과 교묘하게 조작된 딥페이크 정책(Deepfake)을 가려내는 고난도 기술적 리터러시 정책을 요구함(RL Update).
|
||||
- **정책 변화(RL Update)**: AI가 작성한 글과 이미지가 보편화됨에 따라, '이것이 기계의 결과물인가?'를 판별하고 AI의 답변을 비판적으로 검토하는 'AI 리터러시 정책'이 미디어 리터러시의 최고급 단계 정책으로 편입됨. (Hallucination (환각)와 연결)
|
||||
|
||||
@@ -29,3 +38,29 @@ last_reinforced: 2026-04-20
|
||||
- [[Analysis|Analysis]], [[Ethics & AI|Ethics & AI]], [[Information-Society|Information-Society]], [[Hallucination (환각)|Hallucination (환각)]], [[Introspection (자기성찰)|Introspection (자기성찰)]]
|
||||
- **Modern Tech/Tools**: Fact-checking sites, Reverse image [[Search|Search]], Lateral reading.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-F27A16
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-memory-management
|
||||
title: Memory Management
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-F27A16]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[memory|memory]] [[Management|Management]]"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Memory Management|Memory Management]]
|
||||
@@ -19,7 +27,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[memory|memory]] [[Management
|
||||
- **텍스처 및 지오메트리 압축:** 4K 해상도와 같은 고해상도 텍스처는 하나당 64MB 이상의 VRAM을 소모하며, 기기의 메모리 한계를 초과할 경우 브라우저 크래시를 유발할 수 있습니다 [1, 3, 10]. KTX2나 Basis Universal 같은 GPU 압축 텍스처 포맷을 도입하면 대역폭 및 메모리 사용량을 75% 이상 절감할 수 있으며 [6, 11, 12], 지오메트리 속성 역시 정밀도를 낮춰 양자화([[Quantization|Quantization]])함으로써 버퍼 크기를 대폭 줄일 수 있습니다 [13]. 텍스처는 한 번만 로드하여 캐시한 뒤 여러 곳에서 재사용해야 합니다 [4, 14].
|
||||
- **멀티스레딩 환경의 메모리 최적화:** [[Electron|Electron]]과 같은 환경에서 대규모 CAD 모델을 로드할 때 메인 스레드와 워커 간의 메시지 전달(Structured Cloning)은 메모리 사용량을 두 배로 폭증시킬 위험이 있습니다 [15]. 이를 방지하기 위해 `SharedArrayBuffer`를 활용하여 메모리 복사 없이(Zero-copy) 데이터를 공유하는 아키텍처를 도입해야 합니다 [15, 16].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -32,3 +40,29 @@ github_commit: "[P-Reinforce] Continuous Worker - [[memory|memory]] [[Management
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-9CC04F
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-monorepo-turborepo-등-환경의-린트-관리
|
||||
title: Monorepo(Turborepo 등) 환경의 린트 관리
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-9CC04F]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[Monorepo|Monorepo]]([[Turborepo|Turborepo]] 등) 환경의 린트 관리"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Monorepo(Turborepo 등) 환경의 린트 관리|Monorepo(Turborepo 등) 환경의 린트 관리]]
|
||||
@@ -25,7 +36,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Monorepo|Monorepo]]([[Turbor
|
||||
* **[[Husky|Husky]], lint-staged 및 Turborepo 통합**
|
||||
오케스트레이션이 설정되면, 루트의 `package.json`과 `.husky/pre-commit` 훅에 `lint-staged`를 연결합니다 [4]. 이를 통해 커밋 시 변경된 파일들만 린트하게 되며, 루트 설정 파일이 대상 파일을 패키지별 올바른 규칙으로 라우팅해 줍니다 [4]. 추가로 `turbo.json`의 전역 의존성에 ESLint 설정 패키지를 명시하면, 설정이 변경될 때만 캐시를 무효화하고 평상시에는 린트 결과를 캐싱하게 되어 전체적인 작업 속도가 획기적으로 개선됩니다 [4], [5].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -38,3 +49,52 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Monorepo|Monorepo]]([[Turbor
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-BF761A
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-network-coordinate-systems
|
||||
title: Network Coordinate Systems
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-BF761A]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Network CoordinateSystems"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Network Coordinate Systems|Network Coordinate Systems]]
|
||||
@@ -30,7 +41,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Network CoordinateSystems"
|
||||
- 이렇게 산출된 좌표는 웹 클라이언트의 요청을 가장 가까운 데이터 센터로 리디렉션(Client Redirection)하거나 P2P 오버레이 및 CDN 레플리카의 효율적 배치를 지원하는 데 사용됩니다 [16-18].
|
||||
- 구글의 시스템 적용 결과, GNP 기반 리디렉션을 사용했을 때 86%의 확률로 측정된 지연 시간이 가장 짧은 최적의 레플리카로 클라이언트를 연결하는 성과를 보였습니다 [19-21].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -43,3 +54,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Network CoordinateSystems"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-9FB32F
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-new-space-young-generation
|
||||
title: New Space(Young Generation)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-9FB32F]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - New Space(Young Generation)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[New Space(Young Generation)|New Space(Young Generation]]
|
||||
@@ -25,7 +36,7 @@ github_commit: "[P-Reinforce] Continuous Worker - New Space(Young Generation)"
|
||||
* **튜닝 및 크기 제어:**
|
||||
Node.js 환경에서는 V8 플래그를 통해 New Space의 크기를 조절할 수 있다. `--min_semi_space_size` 및 `--max_semi_space_size` (또는 `--max-semi-space-size`) 옵션을 사용하면 이 공간의 크기를 명시적으로 제어할 수 있다 [3, 14]. 트래픽이 많거나 생성 후 곧바로 소멸하는 소규모 객체가 매우 자주 생성되는 애플리케이션의 경우, New Space 크기를 늘려 마이너 GC의 발생 빈도를 줄이고 전반적인 성능 저하를 방지할 수 있다 [14].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -38,3 +49,52 @@ github_commit: "[P-Reinforce] Continuous Worker - New Space(Young Generation)"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-BDE5EC
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-notebooklm-automated-authenticat
|
||||
title: NotebookLM Automated Authentication CLI
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-BDE5EC]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - NotebookLM-Automated-Authentication-CLI"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[NotebookLM-Automated-Authentication-CLI|NotebookLM-Automated-Authentication-CLI]]
|
||||
@@ -22,7 +33,7 @@ github_commit: "[P-Reinforce] Continuous Worker - NotebookLM-Automated-Authentic
|
||||
|
||||
이 방식의 도입으로 '인증 만료'로 인한 엔진 중단 사태가 90% 이상 감소하였으며, 개발자는 더 이상 브라우저 개발자 도구를 열 필요가 없게 되었습니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -32,3 +43,52 @@ github_commit: "[P-Reinforce] Continuous Worker - NotebookLM-Automated-Authentic
|
||||
- **Contradictions/Notes:** CLI 인증은 로컬 환경에 의존하므로, Headless 서버 환경에서는 별도의 토큰 전달 방식이 필요할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,31 +1,22 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-050
|
||||
category: Unified
|
||||
confidence_score: 0.99
|
||||
tags: [security, owasp, vulnerability, secure coding]
|
||||
last_reinforced: 2026-06-XX
|
||||
github_commit: "[P-Reinforce] Processed OWASP Top 10."
|
||||
id: wiki-2026-0508-owasp-top-10
|
||||
title: OWASP Top 10
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 보안_및_시스템_신뢰성_표준
|
||||
canonical_id: wiki-2026-0507-039
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[OWASP Top 10|OWASP Top 10]] (웹 애플리케이션 보안 취약점)
|
||||
# Redirect
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 웹 애플리케이션 개발 시 가장 빈번하고 치명적인 상위 10가지 보안 위험 목록으로, 개발 초기 단계부터 '[[Shift|Shift]]-Left' 원칙에 따라 코딩과 테스트 전반에 걸쳐 방어 로직을 적용하는 것이 필수적이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **개념:** OWASP(Open Web Application Security Project)가 매년 발표하는 웹 보안 취약점 목록이며, 모든 개발 팀이 반드시 숙지해야 할 기본적인 '최소한의 방어선'을 정의한다.
|
||||
- **주요 위험 요소 및 대응 원칙 (예시):**
|
||||
1. **Injection (주입 공격):** 가장 흔하며 치명적이다. 사용자 입력을 신뢰하지 않고, 모든 입력에 대해 반드시 파라미터화된 쿼리(Prepared [[State|State]]ment)를 사용해야 한다.
|
||||
2. **Broken Authentication:** 인증 메커니즘을 강력하게 관리해야 한다. 비밀번호 암호화는 최신 알고리즘(Argon2 등)과 복잡한 정책을 따라야 하며, 세션 관리에 주의한다.
|
||||
3. **Cross-Site Scripting (XSS):** 사용자 생성 콘텐츠 출력 시 반드시 컨텍스트 기반 이스케이프(Contextual Escaping) 처리를 거쳐 악성 스크립트 실행을 막아야 한다.
|
||||
4. **Security Misconfiguration:** 기본 설정값을 변경하지 않고 사용하는 실수를 최소화하며, 모든 컴포넌트는 최소 권한 원칙에 따라 운영되어야 한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 보안은 단순히 패치를 적용하는 문제가 아니라, 개발 프로세스(SDLC) 전체에 걸쳐 '보안을 기본으로 생각하는' 문화적 접근이 필요하다.
|
||||
- **정책 변화:** [[SAST|SAST]]/DAST 같은 자동화된 테스트 도구 활용 외에도, 설계 단계에서부터 보안 취약점 분석(Threat Modeling)을 의무화하고, 코드를 검토할 때마다 (Pull Request 기반의) 보안 체크리스트를 도입하는 것이 현대적 표준이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Parent: [[DevSecOps|DevSecOps]]
|
||||
- Related: [[SAST (Static Application Security Testing)|SAST (Static Application Security [[Testing]])]] , [[DAST (동적 애플리케이션 보안 테스트)|DAST (동적 애플리케이션 보안 테스트)]] , Security by Design
|
||||
|
||||
---
|
||||
이 문서는 Canonical 문서인 [[보안_및_시스템_신뢰성_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-68FCF1
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-oilpan
|
||||
title: Oilpan
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-68FCF1]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Oilpan"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Oilpan|Oilpan]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Oilpan"
|
||||
|
||||
소스에 관련 정보가 부족합니다. (제공된 소스에는 Oilpan의 구체적인 작동 원리, 아키텍처 또는 내부 구현 방식에 대한 추가적인 세부 사항이 포함되어 있지 않습니다.)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Oilpan"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-PDFF-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-pdf-format
|
||||
title: PDF Format
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-PDFF-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, pdf, document-standard, layout-preservation, digital-paper, cross-platform]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[PDF-Format|PDF-Format]]
|
||||
@@ -21,7 +33,7 @@ PDF(Portable Document Format)는 어도비에서 개발한 장치 독립형 문
|
||||
2. **왜 중요한가?**:
|
||||
* 계약서, 매뉴얼, 학술 논문 등 '문서의 무결성'과 '정확한 전달'이 생명인 영역에서의 글로벌 표준이기 때문임. ([[Global-Standard|Global-Standard]]와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 내용을 추출(Scraping)하기 어려운 '죽은 데이터 정책'으로 불려왔으나, 현대 정책은 지능형 OCR과 레이아웃 분석 AI 정책을 통해 PDF 속 데이터를 완벽하게 구조화된 지식 정책으로 불러오는 '동적 지식 추출 정책'이 가능해짐(RL Update). ([[Optical-Character-Recognition|Optical-Character-Recognition]]와 연결)
|
||||
- **정책 변화(RL Update)**: 단순히 보기만 하는 파일을 넘어, AI가 PDF와 대화(Chat with PDF)하여 요약하고 질문에 답하는 '대화형 인터페이스 정책'이 지식 작업의 새로운 표준 정책이 됨.
|
||||
|
||||
@@ -29,3 +41,52 @@ PDF(Portable Document Format)는 어도비에서 개발한 장치 독립형 문
|
||||
- [[Global-Standard|Global-Standard]], [[Optical-Character-Recognition|Optical-Character-Recognition]], [[Documentation-Strategy|Documentation-Strategy]], [[Hardware|Hardware]], [[Efficiency|Efficiency]]
|
||||
- **Modern Tech/Tools**: Adobe Acrobat, PDF.js, PDF-lib, LayoutLM.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-6A1F2E
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-page-experience-algorithm
|
||||
title: Page Experience Algorithm
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-6A1F2E]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Page Experience Algorithm"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Page Experience Algorithm|Page Experience Algorithm]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Page Experience Algorithm"
|
||||
- **데이터 수집 방식:** 구글은 이 알고리즘의 평가를 위해 크롬 사용자 경험 보고서([[CrUX|CrUX]])를 통해 수집된 실제 사용자의 현장 데이터(Field data)를 활용하여 사용자가 페이지를 실제로 어떻게 경험하는지 평가합니다 [1].
|
||||
- **한계:** 제공된 소스에는 페이지 경험 알고리즘이 코어 웹 바이탈을 랭킹 신호로 취급한다는 점은 명시되어 있으나, 그 외에 알고리즘의 구체적인 가중치, 내부 구조 및 기타 평가 요소에 대한 세부적인 관련 정보가 부족합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Page Experience Algorithm"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-D95ED1
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-parse-dont-validate
|
||||
title: Parse dont validate
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-D95ED1]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Parse dont validate"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Parse dont validate|Parse dont validate]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Parse dont validate"
|
||||
- **제어 흐름(Control flow)과 개발자 경험 향상**: 유효성 검사 로직을 시스템 경계에만 배치함으로써, 비즈니스 로직 곳곳에 검증 코드가 어지럽게 흩어지는 것을 방지할 수 있습니다[2]. 결과적으로 타입 시스템의 정적 분석에 무거운 작업을 위임하여 개발자의 신뢰를 높이고, 관리해야 할 코드의 양(Code volume)과 복잡도를 줄이는 데 크게 기여합니다[2, 4].
|
||||
- **구현 방법 및 생태계 도구**: 이 철학을 실현하기 위해 Zod와 같은 런타임 유효성 검사/파싱 라이브러리가 자주 활용됩니다[3, 5]. 구체적으로는 Zod 등을 통해 알 수 없는(Unknown) 데이터를 잘 알려진 타입으로 변환하며, 런타임 데이터에 Branded Types를 부여하여 시스템 내부로 전달하는 것이 이 철학을 완벽히 실현하는 구체적 방법론입니다[3, 5].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Parse dont validate"
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,36 +1,22 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-PCRY-001
|
||||
category: Unified
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, cryptography, security, encryption, privacy]
|
||||
last_reinforced: 2026-04-20
|
||||
id: wiki-2026-0508-practical-cryptography
|
||||
title: Practical Cryptography
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 보안_및_시스템_신뢰성_표준
|
||||
canonical_id: wiki-2026-0507-039
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Practical-Cryptography|Practical-Cryptography]]
|
||||
# Redirect
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "디지털 신뢰의 최전선: 수학적 증명을 넘어, 실제 시스템에서 데이터를 안전하게 암호화하고 전송하며 검증하는 현대 보안의 실전 무술."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
실용 암호학(Practical Cryptography)은 암호학적 이론을 실제 시스템 개발과 운영에 안전하게 적용하는 기술과 원칙을 다룹니다.
|
||||
|
||||
1. **핵심 도구**:
|
||||
* **대칭키 암호 (AES)**: 대량의 데이터를 빠르게 암호화. 키 관리(Key [[Management|Management]])가 생명.
|
||||
* **공개키 암호 (RSA, ECC)**: 디지털 서명과 키 교환에 사용. 신뢰 구축의 기초.
|
||||
* **해시 함수 (SHA-256)**: 데이터의 변조 여부를 확인하는 디지털 지문.
|
||||
* **HMAC**: 메시지의 무결성과 인증을 동시에 보장.
|
||||
2. **실용적 원칙**:
|
||||
* **Don't Roll Your Own Crypto**: 암호 알고리즘은 직접 만들지 말고 검증된 표준 라이브러리를 사용하라.
|
||||
* **[[Side-channel Attack|Side-channel Attack]]s 방어**: 연산 시간이나 전력 소모량을 통해 키를 탈취하는 것을 방지하는 설계.
|
||||
* **Perfect Forward Secrecy (PFS)**: 현재의 키가 털려도 과거의 통신 내용은 보호되어야 함.
|
||||
3. **적용 분야**:
|
||||
* HTTPS(TLS), 블록체인, 종단간 암호화(E2EE), 클라우드 보안.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 '더 긴 키'가 보안의 정답이라 믿었으나, 현대 암호학은 키의 길이보다 '안전한 구현'과 '키 관리 프로세스'가 훨씬 중요하며, 양자 컴퓨터의 발전에 대비한 '양자 내성 암호(PQC)'로의 전환이 시급함을 강조함.
|
||||
- **정책 변화(RL Update)**: 국가 인프라 및 금융 데이터에 대해 정부 차원의 'K-암호 검증 모듈' 사용을 의무화하거나, PQC 전환 로드맵을 사전에 수립하지 않은 기업을 고위험군으로 분류하는 보안 정책이 강화됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Information Extraction (IE), Security & [[Reliability|Reliability]], Communication Theories, [[Blockchain|Blockchain]] Technology
|
||||
- **Modern Tech/Tools**: OpenSSL, Libsodium, GnuPG, KMS (Key Management[[_system|system]]s).
|
||||
---
|
||||
이 문서는 Canonical 문서인 [[보안_및_시스템_신뢰성_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-560F29
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-prettier
|
||||
title: Prettier
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-560F29]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Prettier"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Prettier|Prettier]]
|
||||
@@ -24,7 +35,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Prettier"
|
||||
* **보안 취약점 (공급망 공격) 사례:**
|
||||
2025년 7월, Prettier와 ESLint의 충돌을 방지하는 필수 라이브러리인 `eslint-config-prettier` 패키지가 공급망 공격(CVE-2025-54313)의 표적이 되었습니다 [14, 15]. 관리자의 탈취된 npm 토큰을 통해 악성 버전이 배포되었으며, 이는 주로 Windows 시스템의 개발자 기기나 CI 호스트에서 원격 코드 실행(RCE)을 시도하도록 설계된 악성 설치 스크립트를 포함하고 있었습니다 [16].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -37,3 +48,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Prettier"
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-PROR-002
|
||||
category: Unified
|
||||
id: wiki-2026-0508-procedural-rhetoric
|
||||
title: Procedural Rhetoric
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-PROR-002]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, rhetoric, computation, process-[[Philosophy|Philosophy]], digital-literacy]
|
||||
tags: [auto-reinforced, rhetoric, computation, process-Philosophy, digital-literacy]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Procedural-Rhetoric|Procedural-Rhetoric]]
|
||||
@@ -24,7 +36,7 @@ last_reinforced: 2026-04-20
|
||||
3. **디지털 리터러시**:
|
||||
* 단순히 컴퓨터를 사용하는 법을 넘어, 컴퓨터가 세상의 정보를 어떻게 왜곡하거나 강화하는지 그 '절차적 편향'을 읽어내는 능력이 현대 수사학의 핵심임.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 초기 디지털 담론은 '정보의 바다'와 같은 은유에 머물렀으나, 절차적 수사학은 그 바다를 흐르게 만드는 '조류(알고리즘)'의 의도를 파악하는 방향으로 진화함.
|
||||
- **정책 변화(RL Update)**: 알고리즘에 의한 여론 조작 및 확증 편향(Echo Chambers) 확산을 막기 위해, 거대 플랫폼 기업들이 자사 추천 알고리즘의 '절차적 투명성'을 공개하고 사회적 책임을 지도록 하는 디지털 권리 장전 정책이 수립됨.
|
||||
|
||||
@@ -32,3 +44,52 @@ last_reinforced: 2026-04-20
|
||||
- [[Procedural Rhetoric (In Gaming)|Procedural Rhetoric (In Gaming)]], [[Complexity Theory|Complexity Theory]], Communication Theories, Politics & Media,[[_system|system]] Thinking
|
||||
- **Modern Tech/Tools**: Algorithmic Accountability, Computational Journalism.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-QUAL-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-quality-control
|
||||
title: Quality Control
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-QUAL-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, quality-control, qc, [[Testing|Testing]], verification, standards, excellence]
|
||||
tags: [auto-reinforced, quality-control, qc, Testing, verification, standards, excellence]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Quality-Control|Quality-Control]]
|
||||
@@ -21,7 +33,7 @@ last_reinforced: 2026-04-20
|
||||
2. **왜 중요한가?**:
|
||||
* 품질이 무너진 프로젝트는 신뢰(Trust)를 잃고, 신뢰를 잃은 지능 시스템은 존재 가치가 사라지기 때문임. ([[Mastery|Mastery]]의 핵심 단계)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 사람이 눈으로 확인하는 정책이었으나, 현대 정책은 코드 테스트 자동화 정책, 데이터 유효성 검사 정책, 에지 케이스 감지 AI 정책을 통해 '실시간 자동 QC 정책'으로 전환됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 본 시스템에서는 '코다리' 부장님이 직접 모든 결과물을 검수하는 QC 정책을 고수하며, 배치 처리 후에 항상 대표님의 최종 승인 정책을 구하는 이중 안전장치 정책(Double-Check)으로 구현됨.
|
||||
|
||||
@@ -29,3 +41,52 @@ last_reinforced: 2026-04-20
|
||||
- [[Standard-Operating-Procedure|Standard-Operating-Procedure]], [[Mastery|Mastery]], [[Fault-Tolerance|Fault-Tolerance]], [[Management|Management]], [[Efficiency|Efficiency]]
|
||||
- **Modern Tech/Tools**: Unit testing, Automated QA, Six Sigma, ISO quality standards.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-D7A57A
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-raycaster
|
||||
title: Raycaster
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-D7A57A]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Raycaster"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Raycaster|Raycaster]]
|
||||
@@ -18,7 +26,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Raycaster"
|
||||
- **인스턴스 변환 시 바운딩 볼륨 업데이트:** Three.js r151 버전 이후부터 `InstancedMesh`는 바운딩 볼륨 연산을 지원합니다 [10]. 런타임에 인스턴스의 위치나 형태를 변환한 후 레이캐스팅이 정상적으로 작동하게 하려면, `computeBoundingSphere()` 및 `computeBoundingBox()`를 반드시 호출해야 합니다 [10-12]. 레이캐스터가 연산 최적화를 위해 바운딩 볼륨을 이용한 빠른 사전 테스트(early-out [[Testing|Testing]])를 거치기 때문입니다 [12].
|
||||
- **성능 최적화 (BVH 도입):** 80,000개 이상의 다각형을 갖는 복잡한 장면이나 잦은 레이캐스팅이 필요한 환경에서는 기본 Raycaster만으로는 성능을 보장하기 어렵습니다 [13, 14]. 이를 해결하기 위해 공간 분할 트리 알고리즘을 구현한 `[[three-mesh-bvh|three-mesh-bvh]]` 라이브러리를 사용하면 레이캐스팅 속도를 비약적으로 향상시킬 수 있으며, 확장 라이브러리인 `[[InstancedMesh2|InstancedMesh2]]`도 빠른 레이캐스팅을 위해 BVH를 적극적으로 활용합니다 [13, 15-17].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +39,29 @@ github_commit: "[P-Reinforce] Continuous Worker - Raycaster"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -1,10 +1,18 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-BD8B44
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-raycasting
|
||||
title: Raycasting
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-BD8B44]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Raycasting"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Raycasting|Raycasting]]
|
||||
@@ -28,7 +36,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Raycasting"
|
||||
* **대안 기술 (GPU Picking)**
|
||||
* 복잡한 연산이 필요한 레이캐스팅의 대안으로, 객체의 고유 ID를 색상으로 화면 밖(Off-screen) 픽셀 버퍼에 그린 뒤 렌더링된 픽셀 색상을 읽어 객체를 식별하는 'GPU 피킹(Color-based Picking)' 기술도 존재합니다 [22, 23].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -41,3 +49,29 @@ github_commit: "[P-Reinforce] Continuous Worker - Raycasting"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user