docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
Antigravity Agent
Vendored
+1
-1
@@ -17,6 +17,6 @@
|
||||
"repelStrength": 10,
|
||||
"linkStrength": 1,
|
||||
"linkDistance": 250,
|
||||
"scale": 0.05432900836085962,
|
||||
"scale": 0.02727225354101746,
|
||||
"close": true
|
||||
}
|
||||
+4
-3
@@ -181,6 +181,10 @@
|
||||
},
|
||||
"active": "e84fb23982481828",
|
||||
"lastOpenFiles": [
|
||||
"Economics & Algorithms/페이 투 윈 (Pay to Win).md",
|
||||
"무제 1.canvas",
|
||||
"E-Travelive.md",
|
||||
"페이 투 윈(Pay to Win.md",
|
||||
"04_Governance_Reliability/Code Review Operational Excellence (코드 리뷰 운영 우수성).md",
|
||||
"04_Governance_Reliability/Security Core Practices (보안 핵심 프랙티스).md",
|
||||
"02_Software_Engineering/Modern Engineering Practices (현대적 엔지니어링 프랙티스).md",
|
||||
@@ -206,9 +210,6 @@
|
||||
"프롬프트 확장(Prompt Expansion).md",
|
||||
"프롬프트 파라미터 제어 (Prompt Parameter Control).md",
|
||||
"프롬프트 정밀도 (Prompt Precision).md",
|
||||
"프롬프트 엔지니어링의 진화.md",
|
||||
"프롬프트 엔지니어링.md",
|
||||
"프롬프트 구조 및 문법.md",
|
||||
"sessions/2026-04-30T07-07",
|
||||
"sessions",
|
||||
"company_state.json",
|
||||
|
||||
@@ -4,24 +4,24 @@ _모든 명령·분배·산출물·대화가 시간순으로 누적됩니다.
|
||||
|
||||
## [16:07:45] 👤 **사용자**
|
||||
|
||||
[모닝 브리핑] 오늘 날짜는 2026-04-30입니다. 회사 목표([[goals]].md)와 지금까지의 의사결정 로그를 바탕으로 오늘 우리 회사가 우선순위로 처리해야 할 작업 3가지를 결정하고, 각 작업을 적절한 에이전트에게 분배하세요.
|
||||
[모닝 브리핑] 오늘 날짜는 2026-04-30입니다. 회사 목표(goals.md)와 지금까지의 의사결정 로그를 바탕으로 오늘 우리 회사가 우선순위로 처리해야 할 작업 3가지를 결정하고, 각 작업을 적절한 에이전트에게 분배하세요.
|
||||
|
||||
## [16:28:10] 🧭 **CEO** · _작업 분배_
|
||||
|
||||
회사 목표와 로그가 초기화 상태이므로, 시장 분석을 통한 닉슈 선정 → 수익화 전략 및 KPI 도출 → 일일/주간 실행 계획 수립 순으로 3가지 우선 작업을 정의합니다.
|
||||
|
||||
**할당:**
|
||||
- 🔍 **[[Research]]er**: AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개월 내 진입 가능한 최적의 1개 닉슈와 핵심 타깃 키워드 5개를 정리해 보고하세요.
|
||||
- 💰 **[[business]]**: re[[Search]]er의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안하고, 월별 조회수·구독자·변환율 목표를 포함한 KPI 프레임워크와 가격/수익 구조를 1페이지 분량으로 작성하세요.
|
||||
- 📱 **[[secretary]]**: 리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전트·진행 상태를 명시한 데일리 브리핑과 1주일 액션 플랜을 텔레그램 보고 형식으로 출력하세요.
|
||||
- 🔍 **[[Research|Research]]er**: AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개월 내 진입 가능한 최적의 1개 닉슈와 핵심 타깃 키워드 5개를 정리해 보고하세요.
|
||||
- 💰 **[[business|business]]**: re[[Search|Search]]er의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안하고, 월별 조회수·구독자·변환율 목표를 포함한 KPI 프레임워크와 가격/수익 구조를 1페이지 분량으로 작성하세요.
|
||||
- 📱 **secretary**: 리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전트·진행 상태를 명시한 데일리 브리핑과 1주일 액션 플랜을 텔레그램 보고 형식으로 출력하세요.
|
||||
|
||||
## [16:33:10] 🔍 **[[researcher]]** · _AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개_
|
||||
## [16:33:10] 🔍 **[[researcher|researcher]]** · _AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개_
|
||||
|
||||
⚠️ Researcher 에이전트 호출 실패: aborted
|
||||
|
||||
## [16:37:31] 👤 **사용자**
|
||||
|
||||
[자율 사이클 — 2026-04-30] 사용자가 자리를 비웠습니다. 회사 목표·각 에이전트의 개인 목표(_agents/{id}/[[goal]].md)·최근 의사결정·메모리를 검토해서 지금 가장 가치 있는 단일 작업 1개를 결정하고, 적절한 1~2명 에이전트에게 분배해서 실행하세요. 같은 산출물을 반복하지 마세요 — 메모리에 비슷한 항목이 24시간 내에 있으면 다른 각도로 진전시키세요.
|
||||
[자율 사이클 — 2026-04-30] 사용자가 자리를 비웠습니다. 회사 목표·각 에이전트의 개인 목표(_agents/{id}/[[goal|goal]].md)·최근 의사결정·메모리를 검토해서 지금 가장 가치 있는 단일 작업 1개를 결정하고, 적절한 1~2명 에이전트에게 분배해서 실행하세요. 같은 산출물을 반복하지 마세요 — 메모리에 비슷한 항목이 24시간 내에 있으면 다른 각도로 진전시키세요.
|
||||
|
||||
## [16:38:10] 💰 **Business** · _researcher의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안_
|
||||
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# Index: Topics > 01_Frontend_Mastery
|
||||
|
||||
## 📝 Documents
|
||||
- [[React_Clean_Code_Best_Practices]]
|
||||
- [[React_Hooks_Deep_Dive]]
|
||||
- [[React_Mental_Model]]
|
||||
- [[React_Performance_Optimization]]
|
||||
- [[React_State_Management_Strategy]]
|
||||
- [[React_Testing_Strategy]]
|
||||
- [[TypeScript_Type_Safety]]
|
||||
- [[WebWorker_Performance]]
|
||||
- [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]]
|
||||
- [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]]
|
||||
- [[React_Mental_Model|React_Mental_Model]]
|
||||
- [[React_Performance_Optimization|React_Performance_Optimization]]
|
||||
- [[React_State_Management_Strategy|React_State_Management_Strategy]]
|
||||
- [[React_Testing_Strategy|React_Testing_Strategy]]
|
||||
- [[TypeScript_Type_Safety|TypeScript_Type_Safety]]
|
||||
- [[WebWorker_Performance|WebWorker_Performance]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 클린 코드 및 개발 에티켓
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Clean Code, Etiquette, Best Practice, Readable Code]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Clean_Code_Best_Practices]] (리액트 클린 코드)
|
||||
# [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]] (리액트 클린 코드)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 가독성 좋은 코드는 '컴퓨터'가 이해하는 코드가 아니라, '나중에 이 코드를 고칠 동료(혹은 미래의 나)'가 숨 쉬듯 읽어내려갈 수 있는 코드다.
|
||||
@@ -16,7 +16,7 @@ created: 2026-04-20
|
||||
- **Props Destructuring (구조 분해 할당)**:
|
||||
- `props.user.name` 처럼 경로를 길게 쓰는 대신, 함수의 인자 단계에서 `{ user: { name } }` 처럼 분해하라. 코드가 숨을 쉬기 시작한다.
|
||||
- **Explicit Naming (명시적 네이밍)**:
|
||||
- 핸들러 함수는 `handle[Action]` (예: `handle[[Search]]`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다.
|
||||
- 핸들러 함수는 `handle[Action]` (예: `handle[[Search|Search]]`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다.
|
||||
- **조건부 렌더링 에티켓**:
|
||||
- `&&` 연산자 대신 삼항 연산자(`? :`)를 권장한다. 특히 `0 && <Component />` 시 화면에 숫자 0이 출력되는 대참사를 방지하기 위함이다.
|
||||
|
||||
@@ -24,5 +24,5 @@ created: 2026-04-20
|
||||
- 과도한 추상화는 오히려 독이다. 코드가 3줄인데 함수 5개로 쪼개는 것은 가독성을 해친다. '직관성'이 '분리'보다 우선할 때가 있음을 명심하라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Collaboration_Governance]] , [[System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model]]
|
||||
- Related: [[Collaboration_Governance|Collaboration_Governance]] , [[System_Debugging_Protocol|System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model|React_Mental_Model]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 훅(Hooks) 심층 분석 및 활용
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [React, Hooks, useEffect, Custom Hooks]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Hooks_Deep_Dive]] (리액트 훅 심화)
|
||||
# [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]] (리액트 훅 심화)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 훅은 단순히 함수를 재사용하는 것이 아니라, 컴포넌트의 생애 주기와 논리를 '선언적'으로 결합하는 고도의 동기화 기제다.
|
||||
@@ -14,7 +14,7 @@ created: 2026-04-20
|
||||
- **useEffect의 올바른 관점**:
|
||||
- "마운트될 때 실행"이라는 라이프사이클 사고방식에서 벗어나라. `useEffect`는 **의존성 배열의 값과 컴포넌트 외부 시스템(API, DOM 등)을 동기화**하는 작업이다.
|
||||
- **Custom Hooks (추상화의 꽃)**:
|
||||
- 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMy[[Logic]]` 처럼 따로 빼내어 컴포넌트는 오직 UI 선언에만 집중하게 만든다. 이것이 컴포넌트의 가독성을 폭발시키는 비결이다.
|
||||
- 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMy[[Logic|Logic]]` 처럼 따로 빼내어 컴포넌트는 오직 UI 선언에만 집중하게 만든다. 이것이 컴포넌트의 가독성을 폭발시키는 비결이다.
|
||||
- **Rules of Hooks**:
|
||||
- 반드시 함수의 최상위에서만 호출되어야 한다. 그래야 리액트가 훅의 상태를 유한 상태 머신처럼 정확한 순서로 관리할 수 있다.
|
||||
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- `useEffect` 내에서 무분별하게 상태를 업데이트하면 무한 루프나 성능 저하가 발생한다. 가능하면 `useMemo`나 `useCallback`으로 계산 결과를 캐싱하거나, 상태 업데이트 로직을 `useReducer`로 위임하라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Performance_Optimization]] , [[React_[[State]]_[[Management]]_Strategy]]
|
||||
- Context: [[WebWorker_Performance]]
|
||||
- Related: [[React_Performance_Optimization|React_Performance_Optimization]] , React_State_Management_Strategy
|
||||
- Context: [[WebWorker_Performance|WebWorker_Performance]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 핵심 멘탈 모델 (UI as a Function of [[State]])
|
||||
category: Software [[Architecture]]
|
||||
title: 리액트 핵심 멘탈 모델 (UI as a Function of [[State|State]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [React, State, Mental Model, Immutability]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Mental_Model]] (리액트 멘탈 모델)
|
||||
# [[React_Mental_Model|React_Mental_Model]] (리액트 멘탈 모델)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 리액트 개발은 DOM을 '조작(Manipulate)'하는 것이 아니라, 데이터의 흐름인 '상태(State)'를 정의하고 그 결과물을 화면에 '선언(Declare)'하는 과정이다.
|
||||
@@ -14,13 +14,13 @@ created: 2026-04-20
|
||||
- **UI = f(State)**:
|
||||
- 화면은 상태의 결과값이어야 한다. 명령형(Imperative)으로 "이 버튼의 글자를 바꿔라"라고 하는 순간 리액트의 질서는 무너진다. 오직 상태를 바꾸고 리액트가 알아서 그리게 하라.
|
||||
- **Immutability (불변성)**:
|
||||
- 리액트는 객체의 주소값이 변할 때만 렌더링을 시도한다. `arr.push(1)`이 아니라 `setArr([...arr, 1])`처럼 **새로운 원본**을 복제하여 가상 DOM([[Virtual DOM]])이 효율적으로 동작하게 돕는다.
|
||||
- 리액트는 객체의 주소값이 변할 때만 렌더링을 시도한다. `arr.push(1)`이 아니라 `setArr([...arr, 1])`처럼 **새로운 원본**을 복제하여 가상 DOM([[Virtual DOM|Virtual DOM]])이 효율적으로 동작하게 돕는다.
|
||||
- **Virtual DOM Diffing**:
|
||||
- 리액트는 실제 DOM을 직접 건드리기 전에 메모리상의 가상 DOM에서 이전 상태와 비교(Diffing)하여, 꼭 필요한 부분만 실제 화면에 반영(Commit)한다. 이것이 고성능 웹의 비결이다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어([[Normalization]]) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다.
|
||||
- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어([[Normalization|Normalization]]) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Hooks_Deep_Dive]] , [[Component_Design_Patterns]]
|
||||
- Foundation: [[System_Protocol_Standard]]
|
||||
- Related: [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]] , [[Component_Design_Patterns|Component_Design_Patterns]]
|
||||
- Foundation: [[System_Protocol_Standard|System_Protocol_Standard]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 렌더링 최적화 전략
|
||||
category: Software [[Architecture]]
|
||||
tags: [Performance, Memoization, React.memo, [[Optimization]]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Performance, Memoization, React.memo, [[Optimization|Optimization]]]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Performance_Optimization]] (리액트 성능 최적화)
|
||||
# [[React_Performance_Optimization|React_Performance_Optimization]] (리액트 성능 최적화)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 가장 빠른 렌더링은 '하지 않는 렌더링'이다. 필요 없는 업데이트를 차단하고 데이터가 흐를 때만 화면이 출렁이게 하라.
|
||||
@@ -17,12 +17,12 @@ created: 2026-04-20
|
||||
- **useCallback**: 함수 객체의 변동을 막아 자식 컴포넌트의 불필요한 리렌더링을 방지한다.
|
||||
- **Windowing (가상 리스트)**:
|
||||
- 수천 개의 리스트 아이템이 있어도 사용자의 눈에 보이는 수십 개만 실제 DOM에 렌더링한다. (예: `react-window`, `react-virtualized`).
|
||||
- **상태의 위치 선정 ([[State]] Colocation)**:
|
||||
- **상태의 위치 선정 ([[State|State]] Colocation)**:
|
||||
- 전역 상태가 바뀔 때마다 앱 전체가 들썩이지 않게 하라. 상태는 그것을 사용하는 가장 하위 컴포넌트 근처로 내려라.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 모든 곳에 `memo`를 쓰는 것은 메모리 낭비다. 리액트의 기본 렌더링 성능은 이미 매우 뛰어나다. 병목 현상이 '실제로 관측'될 때만 최적화를 적용하는 것이 원칙이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[WebWorker_Performance]] , [[System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model]]
|
||||
- Related: [[WebWorker_Performance|WebWorker_Performance]] , [[System_Debugging_Protocol|System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model|React_Mental_Model]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 전략적 상태 관리 가이드 (Global & Server [[State]])
|
||||
category: Software [[Architecture]]
|
||||
tags: [State [[Management]], React Query, SSOT, Architecture]
|
||||
title: 전략적 상태 관리 가이드 (Global & Server [[State|State]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [State [[Management|Management]], React Query, SSOT, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_State_Management_Strategy]] (상태 관리 전략)
|
||||
# [[React_State_Management_Strategy|React_State_Management_Strategy]] (상태 관리 전략)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 상태는 '어디든' 있을 수 있지만, '아무데나' 있어서는 안 된다. 상태의 생명주기와 전파 범위에 따라 명확한 거주지를 결정하라.
|
||||
@@ -21,8 +21,8 @@ created: 2026-04-20
|
||||
- 다른 상태로부터 계산될 수 있는 값(예: `firstName`+`lastName` = `fullName`)은 절대 '상태'로 만들지 마라. 렌더링 시점에 계산하는 것이 정합성 유지의 핵심이다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 무조건적인 전역 상태 지상주의는 '[[Prop Drilling]]'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.
|
||||
- 무조건적인 전역 상태 지상주의는 '[[Prop Drilling|Prop Drilling]]'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Single_Source_of_Truth]] , [[API_Communication_Patterns]]
|
||||
- Foundation: [[React_Hooks_Deep_Dive]]
|
||||
- Related: [[Single_Source_of_Truth|Single_Source_of_Truth]] , [[API_Communication_Patterns|API_Communication_Patterns]]
|
||||
- Foundation: [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 애플리케이션 테스트 전략
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[Testing]], Vitest, RTL, Unit Test, QA]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [[Testing|[Testing]], Vitest, RTL, Unit Test, QA]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Testing_Strategy]] (리액트 테스트 전략)
|
||||
# [[React_Testing_Strategy|React_Testing_Strategy]] (리액트 테스트 전략)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 테스트는 '내가 짠 코드'를 검사하는 것이 아니라, '사용자가 경험할 가치'가 유지되고 있는지 수학적으로 증명하는 보험이다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 테스트 커버리지 100% 집착은 생산성을 갉아먹는다. 비즈니스 핵심 로직과 사용자가 가장 많이 쓰는 '메인 시나리오'부터 견고하게 보호하는 지혜가 필요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[System_Debugging_Protocol]] , [[Reliability_Safety_First]]
|
||||
- Tool: [[Modern_Environment_Ecosystem]]
|
||||
- Related: [[System_Debugging_Protocol|System_Debugging_Protocol]] , [[Reliability_Safety_First|Reliability_Safety_First]]
|
||||
- Tool: [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 타입스크립트 기반의 안정적 개발 (Type Safety)
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [TypeScript, Interface, Type Safety, Generic]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[TypeScript_Type_Safety]] (타입스크립트 정석)
|
||||
# [[TypeScript_Type_Safety|TypeScript_Type_Safety]] (타입스크립트 정석)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 타입스크립트는 당신을 귀찮게 하는 '잔소리꾼'이 아니라, 런타임 에러라는 '낭떠러지' 앞에서 당신을 붙잡아주는 '생명줄'이다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- `any`를 남발하는 순간 타입스크립트의 모든 이점은 사라진다. 차라리 `unknown`을 쓰고 타입을 좁히는(Narrowing) 방식을 택하라. 타입 정의에 너무 많은 시간을 뺏기는 '타입 헬(Type Hell)'을 경계하고 적절한 타협점을 찾아라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Clean_Code_Best_Practices]] , [[React_Hooks_Deep_Dive]]
|
||||
- Foundation: [[System_Protocol_Standard]]
|
||||
- Related: [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]] , [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]]
|
||||
- Foundation: [[System_Protocol_Standard|System_Protocol_Standard]]
|
||||
|
||||
@@ -10,9 +10,9 @@ created: 2026-04-20
|
||||
## 🎯 개요 (Overview)
|
||||
실시간 상태 변화가 매우 빈번한 애플리케이션(예: 게임, 시뮬레이션)에서 UI 스레드와 복잡한 연산 로직을 분리하여 **프레임 드롭(Jank)**을 방지하는 아키텍처 설계 기법입니다.
|
||||
|
||||
## 🚀 주요 원칙 (Key [[Principles]])
|
||||
## 🚀 주요 원칙 (Key [[Principles|Principles]])
|
||||
- **스레드 분리 (Thread Isolation)**: 무거운 계산은 백그라운드 스레드(Web Worker)에서 수행하고, 메인 스레드는 렌더링에만 집중합니다.
|
||||
- **메시징 기반 통신 (Messaging [[Architecture]])**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다.
|
||||
- **메시징 기반 통신 (Messaging [[Architecture|Architecture]])**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다.
|
||||
|
||||
## 💡 레슨 런 (Lesson Learned)
|
||||
> [!IMPORTANT]
|
||||
@@ -20,5 +20,5 @@ created: 2026-04-20
|
||||
> 복잡한 물리 계산이나 루프가 UI 응답성을 해치지 않도록, 연산 엔진을 완전히 별도의 스레드로 격리하는 것이 부드러운 UX의 핵심입니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[Systemic_Simulation_Principles]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
- [[Systemic_Simulation_Principles|Systemic_Simulation_Principles]]
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[SDLC & SSDLC (소프트웨어 개발 생명주기)]]
|
||||
# [[SDLC & SSDLC (소프트웨어 개발 생명주기)|SDLC & SSDLC (소프트웨어 개발 생명주기]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
소프트웨어 개발 생명주기(SDLC)는 시스템의 기획, 설계, 구현, 테스트, 배포 및 운영에 이르는 전 과정을 체계화한 모델입니다. **Secure SDLC (SSDLC)**는 이 전통적인 과정의 각 단계에 보안 활동을 내재화하여 안전한 소프트웨어를 구축하는 방법론입니다 [1]. 현대적인 SDLC 환경에서 코드 리뷰는 개발과 배포 사이의 핵심적인 품질 및 보안 게이트(Quality Gate)로 작용하며, 특히 보안 점검을 초기 단계로 앞당기는 **'시프트 레프트(Shift-Left)'** 전략을 통해 결함 수정 비용을 절감하고 시스템 무결성을 확보합니다 [4, 5].
|
||||
@@ -23,10 +23,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Shift-Left Security]]**: 보안 테스트를 SDLC의 가장 좌측(초기 단계)으로 옮겨 수정 비용을 절감하는 핵심 전략입니다.
|
||||
* **[[CI/CD Pipeline]]**: 빌드, 테스트, 보안 스캔을 자동화하여 SDLC의 안정성과 속도를 보장하는 물리적 인프라입니다.
|
||||
* **[[DORA Metrics]]**: 팀의 소프트웨어 전달 성능을 측정하여 SDLC의 효율성을 평가하는 지표 체계입니다.
|
||||
* **[[SAST (Static Application Security Testing)]]**: SDLC 구현 및 검증 단계에서 소스 코드 보안을 자동 스캔하는 기술입니다.
|
||||
* **Shift-Left Security**: 보안 테스트를 SDLC의 가장 좌측(초기 단계)으로 옮겨 수정 비용을 절감하는 핵심 전략입니다.
|
||||
* **[[CI-CD Pipeline|CI/CD Pipeline]]**: 빌드, 테스트, 보안 스캔을 자동화하여 SDLC의 안정성과 속도를 보장하는 물리적 인프라입니다.
|
||||
* **[[DORA-Metrics|DORA Metrics]]**: 팀의 소프트웨어 전달 성능을 측정하여 SDLC의 효율성을 평가하는 지표 체계입니다.
|
||||
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: SDLC 구현 및 검증 단계에서 소스 코드 보안을 자동 스캔하는 기술입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* '시프트 레프트' 보안 모델에서 개발자와 보안 전문가 간의 코드 리뷰 책임 소재와 최종 승인 권한(Merge Authority)은 어떻게 정의하는 것이 최적인가?
|
||||
@@ -43,8 +43,8 @@
|
||||
* **My Project Relevance:** 조직의 리뷰 프로세스를 체계화하고 자동화 검사를 파이프라인에 통합하여 품질 향상과 배포 속도 증가를 동시에 달성합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Agile Development]]**: 스크럼, 칸반 등 반복적 개발 방법론 내에서 SDLC가 어떻게 유연하게 운영되는지 확장하여 탐구합니다.
|
||||
* **[[Software Supply Chain Security]]**: 소스 코드를 넘어 패키지 매니저, 빌드 도구 등 SDLC 인프라 전체의 보안을 강화하는 전략입니다.
|
||||
* **[[Agile Development|Agile Development]]**: 스크럼, 칸반 등 반복적 개발 방법론 내에서 SDLC가 어떻게 유연하게 운영되는지 확장하여 탐구합니다.
|
||||
* **Software Supply Chain Security**: 소스 코드를 넘어 패키지 매니저, 빌드 도구 등 SDLC 인프라 전체의 보안을 강화하는 전략입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Team Culture & Onboarding (팀 문화 및 온보딩)]]
|
||||
# [[Team Culture & Onboarding (팀 문화 및 온보딩)|Team Culture & Onboarding (팀 문화 및 온보딩]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
팀 문화 및 온보딩은 새로운 구성원이 조직에 신속히 적응하고, 기존 팀원들이 비난 없이 소통하며 지속적으로 성장할 수 있는 환경을 구축하는 활동입니다 [1]. 심리적 안전감(Psychological Safety)을 기반으로 코드 리뷰를 학습의 장으로 활용하며, 온보딩 프로세스를 통해 팀의 기술 표준과 협업 방식을 전수합니다 [4]. 특히 장애 발생 시 블레임리스 포스트모템(Blameless Post-mortem)을 수행하여 비난 대신 시스템적 개선을 도모하는 성숙한 문화를 지향합니다.
|
||||
@@ -22,10 +22,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Egoless Programming]]**: 자신의 코드와 자신을 동일시하지 않는 태도("You are not your code")로 리뷰 수용성을 높이는 철학입니다.
|
||||
* **[[Constructive Feedback]]**: 방어적 반응을 유발하지 않으면서 코드 품질을 높이는 구체적인 소통 기술입니다.
|
||||
* **[[Conventional Comments]]**: 피드백의 의도를 라벨링하여 오해를 줄이고 안전감을 높이는 시스템적 도구입니다.
|
||||
* **[[I-Messages (나-전달법)]]**: "너"가 아닌 "나"를 주어로 사용하여 부드럽게 의견을 전달하는 기법입니다.
|
||||
* **Egoless Programming**: 자신의 코드와 자신을 동일시하지 않는 태도("You are not your code")로 리뷰 수용성을 높이는 철학입니다.
|
||||
* **Constructive Feedback**: 방어적 반응을 유발하지 않으면서 코드 품질을 높이는 구체적인 소통 기술입니다.
|
||||
* **Conventional Comments**: 피드백의 의도를 라벨링하여 오해를 줄이고 안전감을 높이는 시스템적 도구입니다.
|
||||
* **I-Messages (나-전달법**: "너"가 아닌 "나"를 주어로 사용하여 부드럽게 의견을 전달하는 기법입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 팀 내 심리적 안전감이 결여되었을 때 코드 리뷰 프로세스에서 발생하는 구체적인 기술적 부채와 이직률 사이의 상관관계는 무엇인가?
|
||||
@@ -42,8 +42,8 @@
|
||||
* **My Project Relevance:** Conventional Comments와 멘토링 제도를 도입하여 상호 존중과 신뢰 기반의 건강한 엔지니어링 문화를 구축합니다 [49].
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[DORA Metrics (Cultural Dimension)]]**: 팀 문화가 소프트웨어 배포 성과에 미치는 정량적 영향을 탐구합니다.
|
||||
* **[[Cognitive Load Theory]]**: 온보딩 과정에서 신규 입사자에게 전달되는 정보량을 조절하여 학습 효율을 높이는 이론적 배경입니다.
|
||||
* **DORA Metrics (Cultural Dimension**: 팀 문화가 소프트웨어 배포 성과에 미치는 정량적 영향을 탐구합니다.
|
||||
* **[[Cognitive Load Theory|Cognitive Load Theory]]**: 온보딩 과정에서 신규 입사자에게 전달되는 정보량을 조절하여 학습 효율을 높이는 이론적 배경입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 효율적인 API 통신 패턴 (Axios & Interceptors)
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [API, Axios, Interceptor, Error Handling, Network]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[API_Communication_Patterns]] (API 통신 패턴)
|
||||
# [[API_Communication_Patterns|API_Communication_Patterns]] (API 통신 패턴)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 서버와의 대화는 항상 '정중하되 의심하며' 처리하라. 모든 요청은 중앙 통제소(Interceptor)를 거치고 모든 에러는 시나리오가 준비되어 있어야 한다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 모든 통신에 Axios가 정답은 아니다. 브라우저 네이티브인 `fetch`로도 충분한 경우가 많으며, 라이브러리 의존성을 낮추는 것이 가벼운 앱을 만드는 첫걸음일 수 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[System_Protocol_Standard]] , [[React_[[State]]_[[Management]]_Strategy]]
|
||||
- Foundation: [[Reliability_Safety_First]]
|
||||
- Related: [[System_Protocol_Standard|System_Protocol_Standard]] , React_State_Management_Strategy
|
||||
- Foundation: [[Reliability_Safety_First|Reliability_Safety_First]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, clean-architecture, design-patterns, mvc, separation-of-con
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Clean Architecture & Patterns]]
|
||||
# [[Clean Architecture & Patterns|Clean Architecture & Patterns]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "기술적 세부 사항(DB, Framework)으로부터 비즈니스 로직을 격리하여, 시스템의 수명을 연장하고 변화에 유연하게 대응하게 만드는 관심사 분리(Separation of Concerns)의 정점."
|
||||
@@ -27,9 +27,9 @@ last_reinforced: 2026-05-01
|
||||
- **아키텍처 부패 (Architectural Decay)**: 시간이 흐름에 따라 편의를 위해 계층을 우회하는 코드가 쌓일 수 있습니다. 매 PR마다 아키텍처 무결성을 점검하여 부패를 조기에 차단해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 아키텍처를 지탱하는 세부 설계 원칙.
|
||||
- [[Architecture Review]]: 아키텍처 일관성을 검증하는 프로세스.
|
||||
- [[Dependency Management (DI & DIP)]]: 계층 간 결합도를 낮추는 기술적 수단.
|
||||
- [[Single Responsibility Principle (SRP)]]: 컴포넌트 분리의 근거.
|
||||
- [[Abstraction & Over-engineering]]: 아키텍처 도입 시 경계해야 할 함정.
|
||||
- [[SOLID Principles|SOLID Principles]]: 아키텍처를 지탱하는 세부 설계 원칙.
|
||||
- [[Architecture Review (아키텍처 및 설계 리뷰)|Architecture Review]]: 아키텍처 일관성을 검증하는 프로세스.
|
||||
- [[Dependency Management (DI & DIP)|Dependency Management (DI & DIP]]: 계층 간 결합도를 낮추는 기술적 수단.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 컴포넌트 분리의 근거.
|
||||
- Abstraction & Over-engineering: 아키텍처 도입 시 경계해야 할 함정.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, clean-architecture, layering, decoupling, domain-driven-des
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Clean Architecture]]
|
||||
# [[Clean Architecture|Clean Architecture]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "비즈니스 로직(Domain)을 중심에 두고 UI, DB, 프레임워크와 같은 외부 세부 사항을 주변부로 밀어내어, 외부 기술의 변화가 시스템의 핵심 논리에 영향을 주지 않도록 격리하는 계층화 아키텍처의 정수."
|
||||
@@ -31,9 +31,9 @@ last_reinforced: 2026-05-01
|
||||
- **학습 곡선**: 계층 간 경계를 엄격히 지키는 설계 철학을 팀 전체가 공유하고 준수하는 데 높은 수준의 컨센서스와 코드 리뷰 역량이 요구됩니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 각 계층 내부 설계를 지탱하는 원칙들.
|
||||
- [[Domain-Driven Design (DDD)]]: 도메인 중심 설계 사상과의 시너지.
|
||||
- [[Dependency Inversion Principle (DIP)]]: 계층 간 통신을 가능하게 하는 핵심 기술.
|
||||
- [[Software Architecture Patterns]]: MVC, Hexagonal 아키텍처 등과의 비교.
|
||||
- [[Over-engineering]]: 패턴의 맹목적 적용 시 경계해야 할 부작용.
|
||||
- [[SOLID Principles|SOLID Principles]]: 각 계층 내부 설계를 지탱하는 원칙들.
|
||||
- [[Domain-Driven-Design-DDD|Domain-Driven Design (DDD]]: 도메인 중심 설계 사상과의 시너지.
|
||||
- [[의존성 역전 원칙 (Dependency Inversion Principle DIP)|Dependency Inversion Principle (DIP]]: 계층 간 통신을 가능하게 하는 핵심 기술.
|
||||
- [[Software-Architecture-Patterns|Software Architecture Patterns]]: MVC, Hexagonal 아키텍처 등과의 비교.
|
||||
- Over-engineering: 패턴의 맹목적 적용 시 경계해야 할 부작용.
|
||||
---
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
---
|
||||
title: 컴포넌트 설계 패턴 (Atomic & Composition)
|
||||
category: Software [[Architecture]]
|
||||
tags: [Design Pattern, [[Atomic Design]], Composition, Architecture]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Design Pattern, [[Atomic Design|Atomic Design]], Composition, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Component_Design_Patterns]] (컴포넌트 설계 패턴)
|
||||
# [[Component_Design_Patterns|Component_Design_Patterns]] (컴포넌트 설계 패턴)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 컴포넌트는 작을수록 강하고, 단순할수록 재사용성이 극대화된다. 복잡한 컴포넌트는 여러 개의 작고 순수한(Pure) 컴포넌트로 해체하라.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Container-Presenter 패턴**:
|
||||
- **Container**: 데이터([[State]], API)를 가져오고 관리하는 '머리'.
|
||||
- **Container**: 데이터([[State|State]], API)를 가져오고 관리하는 '머리'.
|
||||
- **Presenter**: 오직 Props만 받아 화면을 그리는 '몸통'. 스타일과 UI 구조에만 집중하여 테스트 가능성을 높인다.
|
||||
- **[[Compound Components]] (복합 컴포넌트)**:
|
||||
- **[[Compound Components|Compound Components]] (복합 컴포넌트)**:
|
||||
- `<Select><Option /></Select>` 처럼 부모와 자식이 상태를 공유하며 하나의 긴밀한 기능을 수행하는 패턴. 사용자가 UI 구조를 자유롭게 배치할 수 있게 유연성을 제공한다.
|
||||
- **Atomic Design (원자 중심 설계)**:
|
||||
- Atom(버튼, 입력창) $\rightarrow$ Molecule(검색바) $\rightarrow$ Organism(헤더) $\rightarrow$ Template $\rightarrow$ Page.
|
||||
@@ -24,5 +24,5 @@ created: 2026-04-20
|
||||
- 너무 과도한 컴포넌트 분할은 프로토타이핑 속도를 늦춘다. 처음에는 크게 짜고, 중복이 발생하거나 복잡도가 높아질 때 '사후적 리팩토링'을 통해 분리하는 것이 실무적으로 현명하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Project_Architecture_Guidelines , [[Styling_Governance]]
|
||||
- Design: [[Accessibility_Inclusivity]]
|
||||
- Related: Project_Architecture_Guidelines , [[Styling_Governance|Styling_Governance]]
|
||||
- Design: [[Accessibility_Inclusivity|Accessibility_Inclusivity]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, di, dependency-injection, decoupling, inversion-of-control,
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Dependency Injection (DI)]]
|
||||
# [[Dependency Injection (DI)|Dependency Injection (DI]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "클래스 내부에서 직접 의존 객체를 생성하지 않고 외부에서 주입받음으로써, 객체 간의 결합을 끊어내고 테스트와 확장이 용이한 '유연한 부품'으로 만드는 제어 역전(IoC)의 실천적 기법."
|
||||
@@ -28,9 +28,9 @@ DI는 현대 소프트웨어 아키텍처에서 컴포넌트 간의 결합도를
|
||||
- **코드 추적성 저하**: 정적 코드만으로는 어떤 구현체가 주입될지 즉각 확인하기 어려울 수 있습니다. 이를 해결하기 위해 명확한 네이밍 컨벤션과 DI 바인딩 로그의 가시성 확보가 중요합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 의존성 역전 원칙(DIP)의 실현 방법.
|
||||
- [[Single Responsibility Principle (SRP)]]: 클래스의 책임을 생성과 실행으로 분리하는 관점.
|
||||
- [[Testability]]: Mock 객체 주입을 통한 단위 테스트 용이성 확보.
|
||||
- [[Constructor Injection]]: 가장 권장되는 DI 패턴.
|
||||
- [[Dependency Lifetimes]]: Transient, Scoped, Singleton의 이해.
|
||||
- [[SOLID Principles|SOLID Principles]]: 의존성 역전 원칙(DIP)의 실현 방법.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 클래스의 책임을 생성과 실행으로 분리하는 관점.
|
||||
- [[테스트 용이성 (Testability)|Testability]]: Mock 객체 주입을 통한 단위 테스트 용이성 확보.
|
||||
- Constructor Injection: 가장 권장되는 DI 패턴.
|
||||
- Dependency Lifetimes: Transient, Scoped, Singleton의 이해.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, dependency-management, dependency-injection, di, dependency
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Dependency Management (DI & DIP)]]
|
||||
# [[Dependency Management (DI & DIP)|Dependency Management (DI & DIP]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "구체적인 구현이 아닌 추상화에 의존하게 하여 컴포넌트 간의 결합도를 낮추고, 코드 수정 없이 기능을 확장하거나 교체할 수 있는 유연한 시스템 구조의 핵심 기법."
|
||||
@@ -14,10 +14,10 @@ last_reinforced: 2026-05-01
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
의존성 관리는 소프트웨어의 모듈성과 테스트 가능성을 결정짓는 가장 중요한 설계 요소입니다.
|
||||
|
||||
1. **[[Dependency Inversion Principle (DIP)]]**:
|
||||
1. **[[의존성 역전 원칙 (Dependency Inversion Principle DIP)|Dependency Inversion Principle (DIP]]**:
|
||||
* **고수준 모듈의 보호**: 고수준 모듈(비즈니스 로직)은 저수준 모듈(데이터베이스, 외부 API)의 구체적인 구현에 의존해서는 안 됩니다. 둘 다 추상화(인터페이스)에 의존해야 합니다.
|
||||
* **의존성 방향의 역전**: 전통적인 계층 구조에서의 의존성 방향을 뒤집어, 구현체가 인터페이스를 따르게 함으로써 핵심 로직을 외부 변화로부터 보호합니다.
|
||||
2. **[[Dependency Injection (DI)]]**:
|
||||
2. **[[Dependency Injection (DI)|Dependency Injection (DI]]**:
|
||||
* **객체 생성이 아닌 주입**: 클래스 내부에서 의존 객체를 직접 생성(New)하지 않고, 외부(생성자, 메서드 등)에서 주입받습니다.
|
||||
* **유연한 교체**: 인터페이스를 통해 종속성을 주입받으므로, 실제 구현체를 환경(Staging, Production)이나 테스트 목적(Mocking)에 따라 쉽게 교체할 수 있습니다.
|
||||
3. **코드 리뷰에서의 역할**:
|
||||
@@ -28,9 +28,9 @@ last_reinforced: 2026-05-01
|
||||
- **의존성 그래프의 복잡성**: 주입되는 객체가 많아지면 객체 생성 로직이나 DI 컨테이너 설정이 복잡해집니다. 생성자 주입(Constructor Injection)을 권장하고 클래스의 책임을 작게 유지하여 주입되는 의존성 수를 제한해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: DIP가 포함된 설계 원칙 그룹.
|
||||
- [[Clean Architecture & Patterns]]: DIP를 통해 도메인 로직을 보호하는 상위 아키텍처.
|
||||
- [[Testing Strategy]]: DI가 가능하게 하는 테스트 용이성.
|
||||
- [[Single Responsibility Principle (SRP)]]: 의존성이 많아지는 것을 방지하는 근거.
|
||||
- [[Over-engineering]]: 무분별한 추상화의 위험.
|
||||
- [[SOLID Principles|SOLID Principles]]: DIP가 포함된 설계 원칙 그룹.
|
||||
- [[Clean Architecture & Patterns|Clean Architecture & Patterns]]: DIP를 통해 도메인 로직을 보호하는 상위 아키텍처.
|
||||
- [[Testing Strategy|Testing Strategy]]: DI가 가능하게 하는 테스트 용이성.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 의존성이 많아지는 것을 방지하는 근거.
|
||||
- Over-engineering: 무분별한 추상화의 위험.
|
||||
---
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Index: Topics > 02_Architecture_Principles
|
||||
|
||||
## 📝 Documents
|
||||
- [[API_Communication_Patterns]]
|
||||
- [[Component_Design_Patterns]]
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[Single_Source_of_Truth]]
|
||||
- [[Systemic_Simulation_Principles]]
|
||||
- [[API_Communication_Patterns|API_Communication_Patterns]]
|
||||
- [[Component_Design_Patterns|Component_Design_Patterns]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
- [[Single_Source_of_Truth|Single_Source_of_Truth]]
|
||||
- [[Systemic_Simulation_Principles|Systemic_Simulation_Principles]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, design-pattern, mvc, decoupling, ui-architecture, p-reinfor
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[MVC (Model-View-Controller)]]
|
||||
# [[MVC (Model-View-Controller)|MVC (Model-View-Controller]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터(Model), 사용자 인터페이스(View), 로직 제어(Controller)를 분리하여 시스템의 관심사를 격리함으로써, UI의 변화가 데이터 구조에 영향을 주지 않도록 설계하는 고전적이고 강력한 관심사 분리(SoC) 패턴."
|
||||
@@ -29,9 +29,9 @@ MVC는 애플리케이션의 구조적 무결성을 유지하기 위한 가장
|
||||
- **현대적 변형**: 웹 프레임워크의 발전에 따라 MVP, MVVM 등 다양한 변형 패턴이 등장하였으나, 관심사 분리라는 핵심 철학은 MVC에서 계승되었습니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Design Patterns]]: 아키텍처 패턴의 범주.
|
||||
- [[Clean Architecture]]: MVC를 보다 고도화한 계층화 구조.
|
||||
- [[SOLID Principles]]: 각 계층의 단일 책임을 정의하는 원칙.
|
||||
- [[Separation of Concerns (SoC)]]: 패턴의 근본적인 설계 철학.
|
||||
- [[Code Health]]: 일관된 패턴 준수가 가져오는 시스템의 건강성.
|
||||
- Design Patterns: 아키텍처 패턴의 범주.
|
||||
- [[Clean Architecture|Clean Architecture]]: MVC를 보다 고도화한 계층화 구조.
|
||||
- [[SOLID Principles|SOLID Principles]]: 각 계층의 단일 책임을 정의하는 원칙.
|
||||
- [[관심사의 분리 (Separation of Concerns SoC)|Separation of Concerns (SoC]]: 패턴의 근본적인 설계 철학.
|
||||
- Code Health: 일관된 패턴 준수가 가져오는 시스템의 건강성.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, ooad, solid-principles, maintainability, code-review, p-rei
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[SOLID Principles]]
|
||||
# [[SOLID Principles|SOLID Principles]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "소프트웨어의 유지보수성과 확장성을 보장하기 위한 5가지 핵심 설계 기둥: 인지적 부하를 낮추고, 변화에 유연하며, 결합도가 낮은 강건한 시스템을 구축하기 위한 객체지향 설계의 표준 지침."
|
||||
@@ -14,20 +14,20 @@ last_reinforced: 2026-05-01
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
SOLID 원칙은 코드 리뷰와 시스템 설계의 무결성을 평가하는 핵심 기준입니다.
|
||||
|
||||
1. **[[Single Responsibility Principle (SRP)]]**: 클래스나 함수는 단 하나의 변경 이유만을 가져야 합니다. 모듈화를 통해 가독성과 테스트 용이성을 극대화합니다.
|
||||
1. **[[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]**: 클래스나 함수는 단 하나의 변경 이유만을 가져야 합니다. 모듈화를 통해 가독성과 테스트 용이성을 극대화합니다.
|
||||
2. **Open-Closed Principle (OCP)**: 확장에는 열려 있고 수정에는 닫혀 있어야 합니다. 기존 코드를 건드리지 않고 새로운 기능을 추가할 수 있는 구조를 지향합니다.
|
||||
3. **Liskov Substitution Principle (LSP)**: 하위 타입은 언제나 상위 타입으로 교체 가능해야 합니다. 상속 구조에서의 행동 일관성을 보장합니다.
|
||||
4. **Interface Segregation Principle (ISP)**: 클라이언트가 사용하지 않는 메서드에 의존하도록 강요해서는 안 됩니다. 거대한 인터페이스보다 구체적이고 작은 인터페이스 여러 개가 낫습니다.
|
||||
5. **[[Dependency Inversion Principle (DIP)]]**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춥니다.
|
||||
5. **[[의존성 역전 원칙 (Dependency Inversion Principle DIP)|Dependency Inversion Principle (DIP]]**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춥니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **추상화의 비용**: 확장성을 위해 인터페이스와 추상화를 과도하게 도입할 경우, 코드의 직관성이 떨어지고 오버엔지니어링(Over-engineering)으로 이어질 수 있습니다. 현재의 요구사항과 미래의 유연성 사이의 실용적 타협(Trade-off)이 필수적입니다.
|
||||
- **실행 흐름 파악의 어려움**: DI(의존성 주입)를 극한으로 활용할 경우 런타임에 의존성이 결정되므로, 코드 정적 분석만으로는 전체 실행 흐름을 파악하기 어려워질 수 있습니다. 이를 보완하기 위한 명확한 문서화와 추적 로직이 필요합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Single Responsibility Principle (SRP)]]: 첫 번째 원칙의 심화.
|
||||
- [[Dependency Injection (DI)]]: DIP를 실현하는 구체적 기법.
|
||||
- [[Clean Architecture]]: SOLID를 애플리케이션 전체로 확장한 구조.
|
||||
- [[Abstraction & Over-engineering]]: 설계 시 경계해야 할 트레이드오프.
|
||||
- [[Test-Driven Development (TDD)]]: 테스트하기 좋은 코드를 만드는 원칙으로서의 연결.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 첫 번째 원칙의 심화.
|
||||
- [[Dependency Injection (DI)|Dependency Injection (DI]]: DIP를 실현하는 구체적 기법.
|
||||
- [[Clean Architecture|Clean Architecture]]: SOLID를 애플리케이션 전체로 확장한 구조.
|
||||
- Abstraction & Over-engineering: 설계 시 경계해야 할 트레이드오프.
|
||||
- Test-Driven Development (TDD: 테스트하기 좋은 코드를 만드는 원칙으로서의 연결.
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 시스템 아키텍처와 관심사 분리 ([[Separation of Concerns]])
|
||||
category: Software [[Architecture]]
|
||||
title: 시스템 아키텍처와 관심사 분리 ([[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Architecture, SoC, Modular Design, Design Pattern]
|
||||
created: 2026-04-20
|
||||
---
|
||||
@@ -11,8 +11,8 @@ created: 2026-04-20
|
||||
복잡한 소프트웨어 시스템을 역할별로 구분된 독립적인 모듈로 나누어, 유지보수성과 확장성을 극대화하는 설계 철학입니다.
|
||||
|
||||
## 🚀 계층구조 예시 (Layering Example)
|
||||
1. **[[Logic]] Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`)
|
||||
2. **[[State]] Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`)
|
||||
1. **[[Logic|Logic]] Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`)
|
||||
2. **[[State|State]] Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`)
|
||||
3. **View Layer**: 사용자 인터페이스 표현 및 렌더링 (예: React Components)
|
||||
|
||||
## 💡 레슨 런 (Lesson Learned)
|
||||
@@ -21,5 +21,5 @@ created: 2026-04-20
|
||||
> 기능을 추가할 때 기존 코드를 수정하기보다 새로운 모듈을 덧붙일 수 있는 구조를 고민해야 합니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[WebWorker_Performance]]
|
||||
- [[Single_Source_of_Truth]]
|
||||
- [[WebWorker_Performance|WebWorker_Performance]]
|
||||
- [[Single_Source_of_Truth|Single_Source_of_Truth]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, srp, cohesion, refactoring, code-review, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Single Responsibility Principle (SRP)]]
|
||||
# [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "하나의 모듈은 오직 하나의 변경 이유(Reason to change)만을 가져야 한다: 코드의 응집도를 높이고 복잡성을 분산하여, 버그 수정과 기능 확장이 다른 영역에 미치는 부작용을 최소화하는 설계의 기초."
|
||||
@@ -28,9 +28,9 @@ SRP는 객체 지향 설계의 첫 번째 단추이자 가장 보편적인 리
|
||||
- **아키텍처적 부채**: 초기 설계 시 SRP를 무시하면 시간이 흐를수록 '신(God) 객체'가 탄생하며, 이는 리팩토링 비용을 기하급수적으로 증가시키는 주요 원인이 됩니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 5대 원칙의 시작점.
|
||||
- [[Testability]]: 테스트하기 좋은 코드를 만드는 직접적 원인.
|
||||
- [[Refactoring]]: SRP 위반 시 리뷰어가 내리는 핵심 처방.
|
||||
- [[Clean Architecture]]: 책임을 계층별로 격리하는 거시적 구조.
|
||||
- [[Code Readability]]: 단순해진 코드가 가져오는 가독성 향상.
|
||||
- [[SOLID Principles|SOLID Principles]]: 5대 원칙의 시작점.
|
||||
- [[테스트 용이성 (Testability)|Testability]]: 테스트하기 좋은 코드를 만드는 직접적 원인.
|
||||
- [[Refactoring|Refactoring]]: SRP 위반 시 리뷰어가 내리는 핵심 처방.
|
||||
- [[Clean Architecture|Clean Architecture]]: 책임을 계층별로 격리하는 거시적 구조.
|
||||
- Code Readability: 단순해진 코드가 가져오는 가독성 향상.
|
||||
---
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 상태 관리의 단일 진실 공급원 ([[Single Source of Truth]])
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[State]] [[Management]], Data Consistency, Redux, Architecture]
|
||||
title: 상태 관리의 단일 진실 공급원 ([[Single_Source_of_Truth|Single Source of Truth]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [[State|[State]] [[Management|Management]], Data Consistency, Redux, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -10,7 +10,7 @@ created: 2026-04-20
|
||||
## 🎯 개요 (Overview)
|
||||
시스템의 핵심 데이터를 중앙 집중식으로 관리하여, 데이터 불일치(Inconsistency) 현상을 원천 차단하고 예측 가능한 데이터 흐름을 확보하는 설계 원칙입니다.
|
||||
|
||||
## 🚀 주요 원칙 (Key [[Principles]])
|
||||
## 🚀 주요 원칙 (Key [[Principles|Principles]])
|
||||
- **단일 지점 정의 (Defined at Single Point)**: 상태는 오직 한 곳에서만 정의되고 관리되어야 합니다.
|
||||
- **예측 가능성 (Predictability)**: 상태 변경은 정해진 규칙(Action/Setter)을 통해서만 발생하여 디버깅을 용이하게 합니다.
|
||||
|
||||
@@ -20,5 +20,5 @@ created: 2026-04-20
|
||||
> 코드의 파편화를 막기 위해 데이터의 책임 범위(Responsibility)를 명확히 하는 것이 대규모 프로젝트 성공의 열쇠입니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[Domain-Driven Design (DDD)]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
- [[Domain-Driven-Design-DDD|Domain-Driven Design (DDD]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 시스템 시뮬레이션 설계 원리
|
||||
category:[[ system]]ic Modeling & Fun
|
||||
tags: [Simulation, [[Physics]] Engine, Systemic Modeling, Ruleset]
|
||||
category:Systemic Modeling & Fun
|
||||
tags: [Simulation, [[Physics|Physics]] Engine, Systemic Modeling, Ruleset]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -20,5 +20,5 @@ created: 2026-04-20
|
||||
> 이를 통해 단순한 게임을 넘어 자율주행, 물리 엔진 등 고도의 결정론적 시스템 모델링이 가능해집니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[WebWorker_Performance]]
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[WebWorker_Performance|WebWorker_Performance]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[Modern Engineering Practices (현대적 엔지니어링 프랙티스)]]
|
||||
# [[Modern Engineering Practices (현대적 엔지니어링 프랙티스)|Modern Engineering Practices (현대적 엔지니어링 프랙티스]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
현대적 엔지니어링 프랙티스는 애자일(Agile) 철학을 바탕으로 개발 속도, 품질, 그리고 인프라 관리의 효율성을 극대화하기 위한 구체적인 방법론들의 모음입니다. Extreme Programming(XP)에서 파생된 짝 프로그래밍(Pair Programming)을 통해 실시간 피드백 루프를 형성하고, 기능 플래그(Feature Flags)를 활용해 코드 배포와 기능 노출을 분리하며, 코드 기반 인프라(IaC)를 통해 서버 및 환경 구성을 자동화합니다 [1, 3]. 이러한 프랙티스들은 코드 리뷰를 단순한 '사후 검사'에서 '지속적이고 선제적인 품질 보증' 프로세스로 전환합니다.
|
||||
@@ -24,10 +24,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Agile Methodologies]]**: XP, 스크럼 등 유연성과 반복적 피드백을 중시하는 상위 방법론입니다.
|
||||
* **[[Continuous Integration (CI)]]**: 작은 단위의 빈번한 병합을 가능하게 하는 IaC와 기능 플래그의 기술적 토대입니다.
|
||||
* **[[Constructive Feedback]]**: XP 철학에서 강조하는 교육적이고 협력적인 리뷰 커뮤니케이션 방식입니다.
|
||||
* **[[Shift-Left Security]]**: IaC 리뷰를 통해 보안 설정을 개발 초기 단계에서 검증하는 전략적 연계입니다.
|
||||
* **Agile Methodologies**: XP, 스크럼 등 유연성과 반복적 피드백을 중시하는 상위 방법론입니다.
|
||||
* **[[Continuous Integration (CI)|Continuous Integration (CI]]**: 작은 단위의 빈번한 병합을 가능하게 하는 IaC와 기능 플래그의 기술적 토대입니다.
|
||||
* **Constructive Feedback**: XP 철학에서 강조하는 교육적이고 협력적인 리뷰 커뮤니케이션 방식입니다.
|
||||
* **Shift-Left Security**: IaC 리뷰를 통해 보안 설정을 개발 초기 단계에서 검증하는 전략적 연계입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 짝 프로그래밍을 통한 실시간 리뷰가 비동기 PR 리뷰에 비해 '결함 밀도(Defect Density)'와 '지식 전파 속도' 측면에서 가지는 정량적인 비교 우위는 어느 정도인가?
|
||||
@@ -44,8 +44,8 @@
|
||||
* **My Project Relevance:** 중요도와 위험도에 따라 리뷰 방식을 차별화(Tier 1: 자동화, Tier 2: 비동기, Tier 3: 짝 프로그래밍)하여 효율적인 품질 관리 체계를 구축합니다 [56].
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Trunk-Based Development]]**: 기능 플래그를 활용해 브랜치 수명을 극도로 단축시키는 고도화된 개발 워크플로우입니다.
|
||||
* **[[Site Reliability Engineering (SRE)]]**: IaC와 자동화를 통해 시스템의 가용성과 복원력을 관리하는 운영 철학입니다.
|
||||
* **Trunk-Based Development**: 기능 플래그를 활용해 브랜치 수명을 극도로 단축시키는 고도화된 개발 워크플로우입니다.
|
||||
* **Site Reliability Engineering (SRE**: IaC와 자동화를 통해 시스템의 가용성과 복원력을 관리하는 운영 철학입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙)]]
|
||||
# [[Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙)|Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
소프트웨어 엔지니어링 핵심 원칙은 유지보수성이 뛰어나고 확장이 용이한 고품질 시스템을 구축하기 위한 설계 지침입니다 [1]. SOLID 원칙을 기반으로 객체 간의 결합도를 낮추고 응집도를 높이며, 검증된 디자인 패턴을 적용하여 반복되는 설계 문제에 최적의 해결책을 제시합니다 [4]. 코드 리뷰 과정에서 리뷰어는 단순히 코드가 동작하는지를 넘어, 해당 코드가 조직의 아키텍처 가이드라인과 설계 원칙에 부합하는 구조적인 무결성을 갖췄는지 평가해야 합니다 [1, 3].
|
||||
@@ -24,10 +24,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Clean Architecture]]**: SOLID 원칙이 실제 계층형 아키텍처로 구현된 고수준 디자인 패턴입니다.
|
||||
* **[[Unit Testing / Testability]]**: SRP와 DIP를 준수할 때 모의 객체(Mock)를 활용한 단위 테스트가 용이해집니다.
|
||||
* **[[Technical Debt (기술 부채)]]**: 설계 원칙을 무시했을 때 누적되는 눈에 보이지 않는 유지보수 비용입니다.
|
||||
* **[[Code Refactoring]]**: 거대해진 클래스를 SRP에 맞춰 분리하고 시스템을 안전하게 재구조화하는 활동입니다.
|
||||
* **[[Clean Architecture|Clean Architecture]]**: SOLID 원칙이 실제 계층형 아키텍처로 구현된 고수준 디자인 패턴입니다.
|
||||
* **Unit Testing / Testability**: SRP와 DIP를 준수할 때 모의 객체(Mock)를 활용한 단위 테스트가 용이해집니다.
|
||||
* **Technical Debt (기술 부채**: 설계 원칙을 무시했을 때 누적되는 눈에 보이지 않는 유지보수 비용입니다.
|
||||
* **[[Code Refactoring|Code Refactoring]]**: 거대해진 클래스를 SRP에 맞춰 분리하고 시스템을 안전하게 재구조화하는 활동입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 복잡한 도메인 비즈니스 로직을 구현할 때, 단일 책임 원칙(SRP)을 위반하지 않기 위한 '책임의 경계'를 식별하는 구체적인 프레임워크는 무엇인가?
|
||||
@@ -44,8 +44,8 @@
|
||||
* **My Project Relevance:** 체크리스트에 '아키텍처 및 코드 구조 검토' 항목을 포함하여, PR이 기술 부채를 유발하지 않는지 객관적으로 검증합니다 [51].
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Domain-Driven Design (DDD)]]**: 비즈니스 도메인의 복잡성을 관리하기 위한 상위 수준의 설계 전략입니다.
|
||||
* **[[Egoless Programming]]**: 개인의 취항보다 팀의 설계 원칙을 우선시하는 협업 철학입니다.
|
||||
* **[[Domain-Driven-Design-DDD|Domain-Driven Design (DDD]]**: 비즈니스 도메인의 복잡성을 관리하기 위한 상위 수준의 설계 전략입니다.
|
||||
* **Egoless Programming**: 개인의 취항보다 팀의 설계 원칙을 우선시하는 협업 철학입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Testing Methodologies (테스트 방법론)]]
|
||||
# [[Testing Methodologies (테스트 방법론)|Testing Methodologies (테스트 방법론]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
테스트 방법론(Testing Methodologies)은 소프트웨어 개발 및 코드 리뷰 과정에서 프로그램의 기능적 정확성, 안정성, 보안성을 검증하기 위한 체계적인 접근 방식입니다 [1]. 자동화된 테스트(Automated Testing)를 통해 사람이 직접 리뷰하기 전 코드의 기초 결함을 걸러내고, TDD 및 BDD와 같은 방법론을 적용하여 설계 품질을 높입니다. 이는 인간 리뷰어가 사소한 스타일 오류에서 벗어나 아키텍처와 비즈니스 로직 등 고차원적인 피드백에 집중할 수 있도록 돕는 강력한 품질 게이트(Quality Gate) 역할을 수행합니다.
|
||||
@@ -26,10 +26,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[CI/CD Pipeline]]**: 자동화된 테스트가 지속적으로 실행되고 품질 게이트 역할을 수행하는 핵심 인프라입니다.
|
||||
* **[[Static Code Analysis]]**: 코드를 실행하지 않고 잠재적 버그와 스타일 위반을 찾아내는 보완적 검증 수단입니다.
|
||||
* **[[Mocking & Stubbing]]**: 단위 테스트 시 외부 의존성을 격리하여 독립적인 테스트 환경을 구축하는 기술입니다.
|
||||
* **[[Shift-Left Security]]**: 보안 테스트를 개발 초기 단계로 앞당겨 수정 비용을 절감하는 전략입니다.
|
||||
* **[[CI-CD Pipeline|CI/CD Pipeline]]**: 자동화된 테스트가 지속적으로 실행되고 품질 게이트 역할을 수행하는 핵심 인프라입니다.
|
||||
* **Static Code Analysis**: 코드를 실행하지 않고 잠재적 버그와 스타일 위반을 찾아내는 보완적 검증 수단입니다.
|
||||
* **Mocking & Stubbing**: 단위 테스트 시 외부 의존성을 격리하여 독립적인 테스트 환경을 구축하는 기술입니다.
|
||||
* **Shift-Left Security**: 보안 테스트를 개발 초기 단계로 앞당겨 수정 비용을 절감하는 전략입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 각 프로젝트의 비즈니스 중요도와 변경 빈도에 따라 최적의 '투자 대비 효율(ROI)'을 내는 테스트 커버리지 임계값은 어떻게 산출하는가?
|
||||
@@ -46,8 +46,8 @@
|
||||
* **My Project Relevance:** 스타일 및 기초 로직 검증을 자동화에 위임하여, 리뷰어가 시스템 아키텍처와 핵심 비즈니스 로직 논의에 집중할 수 있는 문화를 정착시킵니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Technical Debt (기술 부채)]]**: 테스트가 결여되거나 잘못 작성된 코드가 장기적으로 초래하는 유지보수 비용과 개발 속도 저하에 대해 탐구합니다.
|
||||
* **[[Mutation Testing]]**: 테스트 코드 자체의 품질(결함 발견 능력)을 측정하고 개선하는 고급 테스트 기법입니다.
|
||||
* **Technical Debt (기술 부채**: 테스트가 결여되거나 잘못 작성된 코드가 장기적으로 초래하는 유지보수 비용과 개발 속도 저하에 대해 탐구합니다.
|
||||
* **Mutation Testing**: 테스트 코드 자체의 품질(결함 발견 능력)을 측정하고 개선하는 고급 테스트 기법입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[CI/CD Pipeline (지속적 통합 및 배포)]]
|
||||
# [[CI-CD Pipeline (지속적 통합 및 배포)|CI/CD Pipeline (지속적 통합 및 배포]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
CI/CD(Continuous Integration and Continuous Deployment) 파이프라인은 소프트웨어의 빌드, 테스트 및 배포 과정을 자동화하여 코드 변경 사항을 신속하고 신뢰할 수 있게 통합하고 배포하는 시스템입니다 [1]. 코드 리뷰 과정에서 CI/CD 파이프라인은 인간 리뷰어가 검토하기 전에 린팅(Linting), 스타일 검사, 단위 테스트, 정적 코드 분석 등을 기계적으로 먼저 수행하는 자동화된 1차 방어선 역할을 합니다 [2, 3]. 이를 통해 자동화된 품질 및 보안 게이트를 구축함으로써 전체 개발 프로세스의 속도와 안정성을 비약적으로 향상시킵니다 [5, 6].
|
||||
@@ -20,10 +20,10 @@ CI/CD(Continuous Integration and Continuous Deployment) 파이프라인은 소
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Automated Testing]]**: CI/CD 파이프라인 내에서 코드의 기능적 정확성을 기계적으로 확인하는 핵심 단계입니다.
|
||||
* **[[Linters and Formatters]]**: 스타일 논쟁(Nitpicking)을 제거하고 코드 일관성을 유지하기 위해 파이프라인 초기 단계에 통합되는 도구들입니다.
|
||||
* **[[SAST (Static Application Security Testing)]]**: 배포 전 소스 코드 수준에서 보안 취약점을 자동으로 스캔하는 기술입니다.
|
||||
* **[[Pull Request (PR) Workflow]]**: 코드 병합 전 리뷰를 요청하는 프로세스로, CI/CD 파이프라인을 동작시키는 주요 트리거입니다.
|
||||
* **Automated Testing**: CI/CD 파이프라인 내에서 코드의 기능적 정확성을 기계적으로 확인하는 핵심 단계입니다.
|
||||
* **Linters and Formatters**: 스타일 논쟁(Nitpicking)을 제거하고 코드 일관성을 유지하기 위해 파이프라인 초기 단계에 통합되는 도구들입니다.
|
||||
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 배포 전 소스 코드 수준에서 보안 취약점을 자동으로 스캔하는 기술입니다.
|
||||
* **Pull Request (PR) Workflow**: 코드 병합 전 리뷰를 요청하는 프로세스로, CI/CD 파이프라인을 동작시키는 주요 트리거입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 대규모 모노레포(Monorepo) 환경에서 변경된 영역에 대해서만 선택적으로 자동화 검증을 수행(Impact Analysis)하도록 파이프라인을 최적화하는 기술적 방법은 무엇인가?
|
||||
@@ -39,8 +39,8 @@ CI/CD(Continuous Integration and Continuous Deployment) 파이프라인은 소
|
||||
* **My Project Relevance:** 리뷰 대기 시간이 길거나 반복적인 스타일 지적이 많을 때, 가장 먼저 도입하여 리뷰 프로세스의 병목을 해소해야 할 최우선 인프라입니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Feature Flags]]**: CI/CD를 통해 코드를 자주 병합하면서도 실제 기능 노출은 런타임에 제어하는 고급 배포 기법으로 확장됩니다.
|
||||
* **[[DORA Metrics]]**: 배포 빈도, 변경 실패율 등 CI/CD 파이프라인의 성능을 측정하고 개선하는 지표로 연결됩니다.
|
||||
* **[[Feature-Flags|Feature Flags]]**: CI/CD를 통해 코드를 자주 병합하면서도 실제 기능 노출은 런타임에 제어하는 고급 배포 기법으로 확장됩니다.
|
||||
* **[[DORA-Metrics|DORA Metrics]]**: 배포 빈도, 변경 실패율 등 CI/CD 파이프라인의 성능을 측정하고 개선하는 지표로 연결됩니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [development, ci-cd, automation, quality-gate, devops, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[CI-CD Pipeline]]
|
||||
# [[CI-CD Pipeline|CI-CD Pipeline]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "소프트웨어의 빌드, 테스트, 배포 전 과정을 자동화하여, 인간 리뷰어보다 먼저 결함을 찾아내는 '기계적 파수꾼'이자 배포의 신뢰성을 보장하는 핵심 인프라."
|
||||
@@ -27,9 +27,9 @@ CI-CD는 현대적 개발 워크플로우에서 품질과 속도를 동시에
|
||||
- **자동화의 한계**: CI-CD는 정해진 패턴은 잘 찾지만 비즈니스적 맥락이나 설계상의 논리적 오류는 잡지 못합니다. 기계적 검증과 인간의 정성적 리뷰가 결합된 상호 보완 구조를 유지해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Shift-Left Security]]: 보안 점검을 CI 단계로 앞당기는 전략.
|
||||
- [[Automated Testing]]: 파이프라인의 핵심 관문.
|
||||
- [[Pull Request Workflow]]: CI-CD가 트리거되는 지점.
|
||||
- [[DevSecOps]]: 보안이 내재화된 자동화 철학.
|
||||
- [[Infrastructure as Code (IaC)]]: 인프라 배포의 자동화 확장.
|
||||
- Shift-Left Security: 보안 점검을 CI 단계로 앞당기는 전략.
|
||||
- Automated Testing: 파이프라인의 핵심 관문.
|
||||
- Pull Request Workflow: CI-CD가 트리거되는 지점.
|
||||
- [[DevSecOps|DevSecOps]]: 보안이 내재화된 자동화 철학.
|
||||
- [[Infrastructure-as-Code-IaC|Infrastructure as Code (IaC]]: 인프라 배포의 자동화 확장.
|
||||
---
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 배포 프로토콜 및 CI/CD 자동화
|
||||
category: Software [[Architecture]]
|
||||
tags: [Deployment, CI/CD, [[GitHub Actions]], Vercel, DevOps]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Deployment, CI/CD, [[GitHub Actions|GitHub Actions]], Vercel, DevOps]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Deployment_Final_Gate]] (배포 및 자동화)
|
||||
# [[Deployment_Final_Gate|Deployment_Final_Gate]] (배포 및 자동화)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 수동 배포는 '실버 불렛'이 아니라 '시한폭탄'이다. 인간의 손을 거치지 않는 자동화된 보급로만이 시스템의 영속성을 보장한다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 무조건적인 '자동 배포'가 늘 정답은 아니다. 운영 단계에서는 '블루-그린 배포'나 '카나리 배포'처럼 트래픽을 조금씩 흘려보내며 안정성을 확인하는 고급 전략이 필요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Modern_Environment_Ecosystem]] , [[Collaboration_Governance]]
|
||||
- Pre-requisite: [[React_[[Testing]]_Strategy]]
|
||||
- Related: [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]] , [[Collaboration_Governance|Collaboration_Governance]]
|
||||
- Pre-requisite: [[React_Testing_Strategy|React_Testing_Strategy]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 개발 환경 및 실행 프로세스 관리 (DevOps & Setup)
|
||||
category: DevOps
|
||||
tags: [DevOps, Environment, CI/CD, Process [[Management]]]
|
||||
tags: [DevOps, Environment, CI/CD, Process [[Management|Management]]]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -21,4 +21,4 @@ created: 2026-04-20
|
||||
> 논리적 로직의 완성뿐만 아니라, 그것이 실제로 구동되는 물리적 인프라 설정을 문서화하고 자동화하는 능력이 필수적입니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Systemic_Simulation_Principles]]
|
||||
- [[Systemic_Simulation_Principles|Systemic_Simulation_Principles]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [governance, dora-metrics, engineering-metrics, performance, devops, cycle
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Engineering Metrics (DORA)]]
|
||||
# [[Engineering Metrics (DORA)|Engineering Metrics (DORA]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터에 기반하여 소프트웨어 인도 성과(Delivery Performance)를 정량화하고, 엘리트 팀의 벤치마크를 통해 개발 프로세스의 병목과 개선 방향을 제시하는 엔지니어링 표준 지표."
|
||||
@@ -31,9 +31,9 @@ DORA 지표는 데브옵스(DevOps) 연구를 통해 입증된 고성과 팀의
|
||||
- **데이터의 맥락**: 단순 수치만으로 팀을 평가하기보다, 지표의 변화 추이를 통해 팀의 프로세스 건전성을 진단하고 병목을 해결하는 도구로 활용해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Review Performance & Flow]]: DORA 지표를 달성하기 위한 구체적 운영 전략.
|
||||
- [[Small Pull Requests (작은 PR)]]: Lead Time을 단축하는 가장 강력한 수단.
|
||||
- [[Automated Quality & Review]]: 인간의 시간을 절약하여 성과를 극대화하는 기반.
|
||||
- [[CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
|
||||
- [[DORA Metrics]]: 원본 개념 정의.
|
||||
- [[Review Performance & Flow|Review Performance & Flow]]: DORA 지표를 달성하기 위한 구체적 운영 전략.
|
||||
- Small Pull Requests (작은 PR: Lead Time을 단축하는 가장 강력한 수단.
|
||||
- [[Automated Quality & Review|Automated Quality & Review]]: 인간의 시간을 절약하여 성과를 극대화하는 기반.
|
||||
- [[CI-CD Pipeline|CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
|
||||
- [[DORA-Metrics|DORA Metrics]]: 원본 개념 정의.
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 🛠️ Git [[Opera]]tion & Work Log Protocol (Git 작업 및 기록 지침)
|
||||
# 🛠️ Git [[Opera|Opera]]tion & Work Log Protocol (Git 작업 및 기록 지침)
|
||||
|
||||
> **카테고리**: 03_DevOps_Environment, Automation
|
||||
> **상태**: 🟢 활성화 (Active)
|
||||
@@ -9,7 +9,7 @@
|
||||
## 📌 개요 (Overview)
|
||||
본 문서는 Skybound 프로젝트를 포함한 4개 주요 개발 거점의 원격 저장소 동기화 정합성을 유지하고, 모든 AI 작업 과정을 체계적으로 문서화하기 위한 Git 운영 규정 및 작업 로그(Work Log) 시스템을 정의한다.
|
||||
|
||||
## 🔗 프로젝트별 Git 맵핑 ([[Repository]] Mapping)
|
||||
## 🔗 프로젝트별 Git 맵핑 ([[Repository|Repository]] Mapping)
|
||||
대표님의 명령 한마디로 정확한 경로에서 작업을 수행하기 위해 각 폴더별로 독립적인 Git 설정을 유지한다.
|
||||
|
||||
| 프로젝트 | 로컬 경로 | 원격 저장소 (Remote URL) | 리모트 명칭 |
|
||||
@@ -17,7 +17,7 @@
|
||||
| **Wiki (2nd)** | `E:\Wiki\2nd` | `https://github.com/wonseokjung/solopreneur-ai-agents.git` | `lm_sync` |
|
||||
| **Skybound** | `E:\Wiki\skybound` | `https://github.com/wonseokjung/skybound-protocol.git` | `origin` |
|
||||
| **Legal** | `E:\Wiki\legal-bridge` | `https://github.com/wonseokjung/legal-bridge.git` | `origin` |
|
||||
| **Agent** | `E:\Wiki\auto-[[Research]]-agent`| `https://github.com/wonseokjung/auto-re[[Search]]-agent.git` | `origin` |
|
||||
| **Agent** | `E:\Wiki\auto-[[Research|Research]]-agent`| `https://github.com/wonseokjung/auto-re[[Search|Search]]-agent.git` | `origin` |
|
||||
|
||||
## 🛠️ 운영 지침 (Operational Guidelines)
|
||||
|
||||
@@ -37,7 +37,7 @@
|
||||
- **Result**: 최종 결과 및 관련 연결 지식.
|
||||
|
||||
### 3. 위키화 (Wikification)
|
||||
- `00_Raw`에 축적된 로그는 주기적으로 `10_Wiki\Topics` 하위 카테고리로 고도화([[Refinement]])되어 이동된다.
|
||||
- `00_Raw`에 축적된 로그는 주기적으로 `10_Wiki\Topics` 하위 카테고리로 고도화([[Refinement|Refinement]])되어 이동된다.
|
||||
- 위키화가 완료된 원본 로그는 삭제하여 지식 베이스의 정결성을 유지한다.
|
||||
|
||||
## 🚀 기대 효과
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Index: Topics > 03_DevOps_Environment
|
||||
|
||||
## 📝 Documents
|
||||
- [[Deployment_Final_Gate]]
|
||||
- [[DevOps_Environment_Setup]]
|
||||
- [[Git_Operation_Protocol]]
|
||||
- [[Modern_Environment_Ecosystem]]
|
||||
- [[Tetris_Project_Retrospective]]
|
||||
- [[Deployment_Final_Gate|Deployment_Final_Gate]]
|
||||
- [[DevOps_Environment_Setup|DevOps_Environment_Setup]]
|
||||
- [[Git_Operation_Protocol|Git_Operation_Protocol]]
|
||||
- [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]]
|
||||
- [[Tetris_Project_Retrospective|Tetris_Project_Retrospective]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 모던 개발 환경 및 프레임워크 생태계
|
||||
category: Software [[Architecture]]
|
||||
tags: [Vite, [[Next.js]], Ecosystem, Modern Stack]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Vite, [[Next.js|Next.js]], Ecosystem, Modern Stack]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Modern_Environment_Ecosystem]] (모던 개발 생태계)
|
||||
# [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]] (모던 개발 생태계)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 도구는 목적이 아니라 '생산성'을 위한 수단이다. 하지만 최신 생태계의 변화를 놓치는 것은 스스로 생산성을 깎아내는 것과 같다.
|
||||
@@ -16,11 +16,11 @@ created: 2026-04-20
|
||||
- **Framework: Next.js (The Fullstack Edge)**:
|
||||
- 단순히 SEO를 위한 SSR 도구가 아니다. API Routes를 통한 서버리스 함수 구현, 데이터 캐싱 전략(ISR/SSG) 등 현대 웹이 요구하는 거의 모든 기능을 탑재한 '거버넌스' 그 자체다.
|
||||
- **패키지 매니저의 선택**:
|
||||
- `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포([[Monorepo]]) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다.
|
||||
- `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포([[Monorepo|Monorepo]]) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 최신 기술이 항상 정답은 아니다. 안정성이 최우선인 기업 환경에서는 검증된 `CRA` 혹은 `Webpack` 기반의 설정을 유지하는 것이 보수적인 면에서 유리할 수 있다. 기술 부채(Tech Debt)와 도입 비용을 항상 저울질하라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Deployment_Final_Gate]] , Project_Architecture_Guidelines
|
||||
- Foundation: [[TypeScript_Type_Safety]]
|
||||
- Related: [[Deployment_Final_Gate|Deployment_Final_Gate]] , Project_Architecture_Guidelines
|
||||
- Foundation: [[TypeScript_Type_Safety|TypeScript_Type_Safety]]
|
||||
|
||||
@@ -1,21 +1,21 @@
|
||||
---
|
||||
title: 프로젝트 회고: 고성능 테트리스 아키텍처
|
||||
category: Projects
|
||||
tags: [Retrospective, Tetris, [[Architecture]], Performance]
|
||||
tags: [Retrospective, Tetris, [[Architecture|Architecture]], Performance]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 프로젝트 회고: 고성능 테트리스 아키텍처 ([[P-Reinforce]])
|
||||
# 프로젝트 회고: 고성능 테트리스 아키텍처 ([[P-Reinforce|P-Reinforce]])
|
||||
|
||||
## 🌊 프로젝트 아키텍처 요약
|
||||
본 프로젝트는 **Web Worker**를 활용한 완전한 연산-렌더링 분리를 실현하여, 실시간 게임 환경에서 극강의 부드러움을 확보하는 데 성공했습니다.
|
||||
|
||||
### 🧩 컴포넌트별 기술적 역할
|
||||
- **Game Engine**: 물리 계산 및 상태 전이 (`public/gameWorker.js`).
|
||||
- **[[State]] Manager**: UI의 유일한 진실 공급원 (`src/App.js`).
|
||||
- **[[State|State]] Manager**: UI의 유일한 진실 공급원 (`src/App.js`).
|
||||
- **Renderer**: Props 기반의 순수 매핑 렌더러 (`src/components/GameBoard.jsx`).
|
||||
|
||||
## ⚠️ 핵심 교훈 ([[Lessons Learned]])
|
||||
## ⚠️ 핵심 교훈 ([[Lessons Learned|Lessons Learned]])
|
||||
> [!IMPORTANT]
|
||||
> **"논리가 완벽해도 실행 환경이 무너지면 아무 의미가 없다."**
|
||||
> 아키텍처 설계만큼이나 '파일 무결성 검증'과 '환경 재설정 루틴'이 개발 생산성에 지대한 영향을 미친다는 것을 확인했습니다.
|
||||
@@ -26,5 +26,5 @@ created: 2026-04-20
|
||||
- [x] 체계적인 디버깅 프로토콜 수립.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[System_Debugging_Protocol]]
|
||||
- [[System_Debugging_Protocol|System_Debugging_Protocol]]
|
||||
- Project_Architecture_Guidelines
|
||||
|
||||
+22
-26
@@ -1,45 +1,41 @@
|
||||
# [[AI-Generated Code Assurance (AI 생성 코드 검토 및 보안)]]
|
||||
# AI-Generated Code Assurance (AI 생성 코드 검토 및 보안
|
||||
|
||||
## 📌 Brief Summary
|
||||
AI 생성 코드는 개발 생산성을 극적으로 향상시키지만, 인간 작성 코드보다 보안 취약점(XSS, 인젝션 등) 발생률이 높고 '환각(Hallucination)'으로 인한 가짜 API 호출 위험을 내포합니다. 연구에 따르면 AI가 작성한 풀 리퀘스트(PR)는 인간보다 1.7배 더 많은 문제와 높은 보안 취약점을 포함하는 경향이 있습니다. 따라서 AI 생성 코드는 완성본이 아닌 '초안'으로 취급되어야 하며, 정적 분석(SAST), 소프트웨어 구성 분석(SCA) 등 자동화 도구와 인간 리뷰어의 비판적 검토가 결합된 엄격한 품질 게이트(Quality Gate) 적용이 필수적입니다.
|
||||
AI 생성 코드는 개발 생산성을 극적으로 향상시키지만, 인간 작성 코드보다 보안 취약점(XSS, 인젝션 등) 발생률이 높고 '환각(Hallucination)'으로 인한 가짜 API 호출 위험을 내포합니다 [1]. 연구에 따르면 AI가 작성한 풀 리퀘스트(PR)는 인간보다 1.7배 더 많은 보안 취약점을 포함하는 경향이 있습니다 [7, 8]. 따라서 AI 생성 코드는 완성본이 아닌 '초안'으로 취급되어야 하며, 정적 분석(SAST), 소프트웨어 구성 분석(SCA) 등 자동화 도구와 인간 리뷰어의 비판적 검토가 결합된 엄격한 품질 게이트(Quality Gate) 적용이 필수적입니다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **증가하는 보안 위협과 취약점 발생률:** AI 생성 코드는 XSS(교차 사이트 스크립팅) 취약점 도입 확률이 2.74배, 불안전한 객체 참조 포함 확률이 1.91배 높습니다 [1, 7]. 입력값 검증 누락, 데이터베이스 자격 증명 및 API 키 하드코딩이 빈번하게 발생하며, 이는 실제 데이터 유출 및 커맨드 인젝션 사고로 이어지기도 합니다 [8, 10].
|
||||
* **AI 특화 위험 (환각 및 슬롭스쿼팅):** AI 모델은 존재하지 않는 API, 라이브러리, 패키지를 실제인 것처럼 지어내는 '환각(Hallucination)' 현상을 보입니다 [2, 11]. 공격자들은 AI가 자주 지어내는 패키지 이름을 노려 악성 코드를 배포하는 '슬롭스쿼팅(Slopsquatting)' 또는 '타이포스쿼팅' 공격을 시도할 수 있습니다 [1, 9].
|
||||
* **비즈니스 맥락 및 엣지 케이스 무시:** AI는 주로 정상 작동 시나리오인 '해피 패스(Happy path)'에 집중하여, Null 값, 빈 배열, 유효하지 않은 입력 등 중요한 엣지 케이스 처리를 누락하는 경향이 있습니다 [3, 12]. 또한, 비즈니스 맥락이나 시스템 아키텍처 의도를 파악하지 못해 루프 내 순차적 I/O 수행 등 성능 병목을 유발하기도 합니다 [13, 14].
|
||||
* **품질 저하 및 라이선스 위반:** AI 코드는 불필요하게 장황하거나 DRY(Don't Repeat Yourself) 원칙을 위반하는 경우가 많습니다 [15, 16]. 특히 오픈소스 코드를 그대로 복제하여 AGPL-3.0 코드를 MIT 프로젝트에 삽입하는 등의 지적 재산권 및 라이선스 호환성 문제를 일으킬 위험이 큽니다 [17].
|
||||
* **검증 프로세스 및 도구 통합:** AI 생성 코드를 감지하고 태깅하여 관리해야 하며, SonarQube, Semgrep, CodeQL, Dependabot 등 SAST/SCA 도구를 CI/CD 파이프라인에 통합하여 최소 80% 이상의 테스트 커버리지 조건을 강제해야 합니다 [4, 15, 18].
|
||||
* **증가하는 보안 위협과 취약점 발생률:** AI 생성 코드는 XSS(교차 사이트 스크립팅) 취약점 도입 확률이 2.74배 높으며, 하드코딩된 자격 증명이나 입력값 검증 누락이 빈번합니다 [1, 7].
|
||||
* **AI 특화 위험 (환각 및 슬롭스쿼팅):** AI 모델은 존재하지 않는 패키지를 제안하는 '환각(Hallucination)' 현상을 보이며, 공격자들은 이를 악용해 악성 코드를 배포하는 '슬롭스쿼팅(Slopsquatting)' 공격을 시도합니다 [2, 9].
|
||||
* **비즈니스 맥락 및 엣지 케이스 무시:** AI는 주로 '해피 패스(Happy path)' 시나리오에 집중하여, Null 값 처리나 예외 상황 등 중요한 엣지 케이스를 누락하는 경향이 있습니다 [3, 12].
|
||||
* **품질 저하 및 라이선스 위반:** 불필요하게 장황한 코드(Slop)를 양산하거나, AGPL-3.0 등 라이선스가 엄격한 오픈소스 코드를 무단 복제하여 지적 재산권 문제를 일으킬 수 있습니다 [17].
|
||||
* **검증 프로세스 통합:** SonarQube, Semgrep, CodeQL 등 SAST/SCA 도구를 CI/CD 파이프라인에 통합하여 최소 80% 이상의 테스트 커버리지를 강제하고, 모든 AI 생성 코드에 태깅을 수행합니다 [15, 18].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **개발 속도(생산성) vs. 기술 부채 및 보안 위험:** AI 코딩 어시스턴트를 통해 마이그레이션 기간을 수개월에서 수주로 단축하는 압도적인 생산성 향상을 얻을 수 있으나, 동시에 예측 가능한 보안 약점을 시스템에 도입합니다 [19, 20]. 이를 상쇄하기 위해 자동화된 리뷰 파이프라인 및 보안 검증 리소스 투자가 트레이드오프로 요구됩니다.
|
||||
* **AI 자동화 리뷰 vs. 인간의 비즈니스 맥락 이해:** AI 리뷰 도구는 빠른 피드백을 제공하지만 아키텍처적 트레이드오프를 완벽히 이해하지 못합니다 [13, 22]. AI 피드백을 무비판적으로 수용할 경우 오히려 잘못된 수정이 적용될 수 있으므로, 최종 검증은 항상 비즈니스 의도를 파악하고 있는 인간(시니어 리뷰어)이 수행해야 합니다.
|
||||
* **속도 vs 안전성:** AI 코딩 어시스턴트는 마이그레이션 기간을 획기적으로 단축하지만, 예측 가능한 보안 약점을 시스템에 도입합니다. 이를 위해 자동화된 보안 검증 리소스 투자가 트레이드오프로 요구됩니다 [19].
|
||||
* **자동화의 사각지대:** AI 기반 리뷰 도구는 30~60%의 오탐률을 보이며 실제 취약점의 약 22%를 놓치는 근본적인 한계가 있습니다 [Augment Code 벤치마크]. 아키텍처 설계와 비즈니스 로직의 무결성 판단에는 여전히 인간의 수동 검토가 필수 불가결합니다.
|
||||
* **리뷰 피로도(Review Fatigue):** AI가 양산하는 대량의 코드(Slop)는 리뷰어의 인지 부하를 높여 형식적인 승인(Rubber-stamping)을 유도할 위험이 있습니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[SAST (정적 애플리케이션 보안 테스트)]]**: AI 코드에서 하드코딩된 시크릿, 인젝션 결함 등을 코드가 실행되기 전 소스 수준에서 자동 식별하는 핵심 기술입니다.
|
||||
* **[[SCA (소프트웨어 구성 분석)]]**: AI가 제안하는 의존성 패키지의 실존 여부, 취약점, 라이선스 호환성을 검증하여 환각 및 슬롭스쿼팅 공격을 방어합니다.
|
||||
* **[[Slopsquatting (Typosquatting)]]**: AI 환각을 이용한 구체적인 공급망 공격 기법으로, AI 코드를 수동으로 검증해야 하는 강력한 이유를 제공합니다.
|
||||
* **[[Shift-Left Security]]**: AI가 양산하는 대량의 결함을 배포 전(PR 단계 이전) 조기에 차단하여 수정 비용을 낮추는 전략적 접근입니다.
|
||||
* **[[Static Analysis & Linting (정적 분석 및 린팅)|Static Analysis & Linting]]**: AI 코드의 구문적 오류와 보안 결함을 자동 식별하는 1차 방어선입니다.
|
||||
* **[[Software Security Standards & Vulnerabilities (소프트웨어 보안 표준 및 취약점)|Software Security Standards & Vulnerabilities]]**: AI가 자주 위반하는 OWASP Top 10 등 보안 표준에 대한 이해가 필요합니다.
|
||||
* **Shift-Left Security**: AI 대량 생산 코드를 배포 전 PR 단계에서 조기에 차단하는 전략입니다.
|
||||
* **Software Supply Chain Security**: AI 환각으로 인한 악성 패키지 도입을 방어하는 전체적인 공급망 보안 전략입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* AI의 '의존성 환각'을 CI/CD 단계에서 100% 차단하기 위한 실시간 패키지 레지스트리 교차 검증 아키텍처는 어떻게 설계해야 하는가?
|
||||
* 외부 AI 코드 리뷰 도구 도입 시 소스 코드 노출에 따른 데이터 주권(Data Sovereignty) 문제를 해결하기 위한 Self-hosted LLM 활용 방안은 무엇인가?
|
||||
* '바이브 코딩' 환경에서 인간 리뷰어의 인지적 과부하(Review Fatigue)를 방지하면서도 시스템의 아키텍처 무결성을 유지하는 '계층화된 리뷰(Tiered Review)' 모델은 무엇인가?
|
||||
* AI가 생성한 단위 테스트 자체가 내포할 수 있는 논리적 결함(False Positive)을 교차 검증하기 위한 자동화된 Mutation Testing 도입의 실익은 무엇인가?
|
||||
* AI 생성 코드의 라이선스 위반 여부를 소스 코드 지문 분석(Code Fingerprinting)을 통해 실시간 감지하는 효율적인 프로세스는 무엇인가?
|
||||
* AI의 '의존성 환각'을 CI/CD 단계에서 실시간으로 차단하기 위한 패키지 레지스트리 교차 검증 아키텍처는 무엇인가?
|
||||
* Self-hosted LLM을 활용하여 소스 코드 노출 없이 AI 리뷰를 수행할 때의 성능과 비용 효율성은 어떠한가?
|
||||
* AI 생성 코드의 라이선스 위반 여부를 실시간으로 감지하는 소스 코드 지문 분석(Fingerprinting) 기술의 정확도는?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** AI가 생성한 코드를 복사-붙여넣기 전, OWASP Top 10 기준에 맞춰 입력값을 검증하고 파라미터화된 쿼리 사용 여부를 직접 수정해야 합니다.
|
||||
* **System Design:** AI 제안 로직이 기존 아키텍처 결정 사항(ADR)과 충돌하지 않는지 확인하고, 루프 내 I/O 발생 등 성능 안티 패턴을 집중 리뷰합니다.
|
||||
* **Operation / Maintenance:** CI/CD에 보안 스캐너를 통합하여 정책 위반 코드를 자동 차단하고, 커밋 메시지에 AI 사용 여부를 태깅하여 향후 감사를 대비합니다.
|
||||
* **Learning Path:** 주니어 개발자가 AI 코드를 그대로 수용하지 않도록 "이 코드가 놓친 엣지 케이스는 무엇인가?"를 묻는 비판적 사고 훈련 멘토링에 활용합니다.
|
||||
* **My Project Relevance:** PR 템플릿에 "AI-Generated Code Verification" 체크리스트(의존성 확인, 시크릿 검사, 라이선스 체크 등)를 추가하고 품질 게이트를 설정합니다.
|
||||
* **Implementation:** AI 코드를 복사하기 전 파라미터화된 쿼리 사용 여부를 직접 검증합니다.
|
||||
* **System Design:** AI 제안 로직이 기존 아키텍처 결정(ADR)과 충돌하지 않는지 확인합니다.
|
||||
* **My Project Relevance:** PR 템플릿에 "AI 생성 코드 체크리스트"를 추가하고 보안 스캔 통과를 강제합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Vibe Coding]]**: 인간이 논리 작성보다 의도와 맥락에 집중하는 코딩 방식으로, 리뷰어가 결과물의 '의도 일치성'을 판단하는 역량이 중요해집니다.
|
||||
* **[[Technical Debt Management]]**: AI가 양산하는 '작동은 하지만 유지보수성이 낮은 코드'가 쌓이는 현상을 측정하고 관리하는 전략으로 확장됩니다.
|
||||
* **[[Software Supply Chain Security]]**: AI가 도입하는 외부 컴포넌트의 무결성을 점검하고 SBOM을 통해 관리하는 전체적인 방어 전략입니다.
|
||||
* **Technical Debt Management**: AI가 양산하는 '작동하지만 유지보수성 낮은 코드' 관리 전략입니다.
|
||||
* **Vibe Coding**: 인간이 논리보다 의도에 집중하는 환경에서의 리뷰어 역량 변화를 탐구합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 웹 접근성 및 포용적 설계 (a11y)
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[Accessibility]], a11y, Semantic HTML, Inclusivity]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [[Accessibility|[Accessibility]], a11y, Semantic HTML, Inclusivity]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Accessibility_Inclusivity]] (포용적 설계와 접근성)
|
||||
# [[Accessibility_Inclusivity|Accessibility_Inclusivity]] (포용적 설계와 접근성)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 웹은 '모두'를 위한 공간이어야 한다. 신체적 제약이 시스템 이용의 제약이 되지 않게 하는 것은 '매너'가 아니라 전문 개발자의 '책임'이다.
|
||||
@@ -13,7 +13,7 @@ created: 2026-04-20
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Semantic HTML (의미론적 태그)**:
|
||||
- `<div>`로만 도배하지 마라. `<main>`, `<article>`, `<section>`, `<nav>` 등 의미가 담긴 태그를 써야 기계(스크린 리더)와 검색 엔진이 내 콘텐츠의 중요도를 파악한다.
|
||||
- **ARIA & [[State]]s**:
|
||||
- **ARIA & [[State|State]]s**:
|
||||
- 표준 HTML로 설명이 불가능한 인터랙션(예: 커스텀 탭 메뉴)은 `aria-label`, `aria-hidden` 등을 통해 기계에게 보조 설명을 전한다.
|
||||
- **Keyboard Navigation**:
|
||||
- 마우스 없이 `Tab` 키와 `Enter` 키만으로 내 앱의 모든 핵심 기능을 수행할 수 있는지 검증하라. 포커스링을 숨기지 마라. 누군가에게는 유일한 가이드라인이다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 접근성을 챙기는 것은 단순히 윤리적인 문제를 넘어, **SEO(검색 노출)** 성적과 직결된다. 구글 검색 로봇은 눈이 없기에, 스크린 리더와 유사한 방식으로 우리 사이트를 평가하기 때문이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Styling_Governance]] , [[React_Clean_Code_Best_Practices]]
|
||||
- Ethic: [[Collaboration_Governance]]
|
||||
- Related: [[Styling_Governance|Styling_Governance]] , [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]]
|
||||
- Ethic: [[Collaboration_Governance|Collaboration_Governance]]
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[Application Security Posture Management (ASPM, 애플리케이션 보안 태세 관리)]]
|
||||
# Application Security Posture Management (ASPM, 애플리케이션 보안 태세 관리
|
||||
|
||||
## 📌 Brief Summary
|
||||
Application Security Posture Management (ASPM)은 개발 과정 전반에 걸쳐 애플리케이션 구성 요소의 설정 오류, 보안 위협 및 규정 준수 위반 사항을 지속적으로 평가하고 관리하는 도구 및 방법론입니다 [1]. 클라우드 및 프로덕션 환경의 실시간 인사이트를 활용하여 개발자에게 실제 보안 위험의 우선순위를 명확히 지정해 줌으로써, '시프트 레프트(Shift-Left)' 보안을 실현합니다 [1, 2]. ASPM은 파편화된 보안 도구(SAST, DAST, SCA 등)의 데이터를 통합하여 소프트웨어 공급망 전체에 대한 가시성을 제공하고 효율적인 코드 리뷰를 지원합니다 [1, 3].
|
||||
@@ -16,10 +16,10 @@ Application Security Posture Management (ASPM)은 개발 과정 전반에 걸쳐
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Shift-Left Security]]**: 보안 검토를 SDLC 초기 단계로 당기는 전략으로, ASPM이 기술적으로 이를 구현하는 핵심 수단이 됩니다.
|
||||
* **[[SAST, DAST, IAST]]**: ASPM이 통합하여 관리하는 소스 코드, 런타임, 대화형 보안 테스트 기술들입니다.
|
||||
* **[[Software Bill of Materials (SBOM)]]**: 애플리케이션의 모든 구성 요소를 명시한 자재 명세서로, ASPM이 공급망 위험을 평가하는 기초 데이터로 활용됩니다.
|
||||
* **[[DevSecOps]]**: 개발, 보안, 운영을 하나로 통합하는 철학이며, ASPM은 이 환경에서 보안 거버넌스를 자동화하는 플랫폼 역할을 수행합니다.
|
||||
* **Shift-Left Security**: 보안 검토를 SDLC 초기 단계로 당기는 전략으로, ASPM이 기술적으로 이를 구현하는 핵심 수단이 됩니다.
|
||||
* **SAST, DAST, IAST**: ASPM이 통합하여 관리하는 소스 코드, 런타임, 대화형 보안 테스트 기술들입니다.
|
||||
* **Software Bill of Materials (SBOM**: 애플리케이션의 모든 구성 요소를 명시한 자재 명세서로, ASPM이 공급망 위험을 평가하는 기초 데이터로 활용됩니다.
|
||||
* **[[DevSecOps|DevSecOps]]**: 개발, 보안, 운영을 하나로 통합하는 철학이며, ASPM은 이 환경에서 보안 거버넌스를 자동화하는 플랫폼 역할을 수행합니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* ASPM 도구는 클라우드 구성 정보(Config)와 소스 코드 취약점을 결합하여 '공격 경로(Attack Path)'를 구체적으로 어떻게 시각화하고 우선순위를 정하는가?
|
||||
@@ -36,8 +36,8 @@ Application Security Posture Management (ASPM)은 개발 과정 전반에 걸쳐
|
||||
* **My Project Relevance:** 코드 리뷰 체크리스트 중 보안 검토 항목을 ASPM에 위임하여, 리뷰어가 비즈니스 로직 검증에 집중할 수 있도록 프로세스를 최적화합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[AI-Generated Code Security]]**: 개발 효율을 위해 도입된 AI 코드가 유발하는 보안 리스크를 ASPM 거버넌스 체계 내에서 통제하는 방안으로 확장됩니다.
|
||||
* **[[Cloud Native Application Protection Platform (CNAPP)]]**: 클라우드 인프라와 애플리케이션 보안을 통합 관리하는 더 넓은 범위의 플랫폼 개념과 ASPM의 연결성을 탐구할 수 있습니다.
|
||||
* **AI-Generated Code Security**: 개발 효율을 위해 도입된 AI 코드가 유발하는 보안 리스크를 ASPM 거버넌스 체계 내에서 통제하는 방안으로 확장됩니다.
|
||||
* **Cloud Native Application Protection Platform (CNAPP**: 클라우드 인프라와 애플리케이션 보안을 통합 관리하는 더 넓은 범위의 플랫폼 개념과 ASPM의 연결성을 탐구할 수 있습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Architecture Review (아키텍처 및 설계 리뷰)]]
|
||||
# [[Architecture Review (아키텍처 및 설계 리뷰)|Architecture Review (아키텍처 및 설계 리뷰]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
아키텍처 리뷰(Architecture Review)는 라인 단위의 구현 세부 사항을 넘어, 코드 변경 사항의 구조적 무결성과 장기적인 생존성을 평가하는 고수준의 특화된 검토 프로세스입니다 [1, 2]. 이 과정은 아키텍처의 표류(Architectural drift)와 기술 부채의 축적을 방지하는 전략적 체크포인트 역할을 수행합니다 [1, 3]. 궁극적으로 새로운 기능이 시스템의 거시적인 디자인 패턴(예: MVC, 클린 아키텍처) 및 설계 원칙(예: SOLID)에 부합하여, 확장성과 유지보수성을 보장하도록 만드는 것을 목표로 합니다 [1, 4].
|
||||
@@ -18,10 +18,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[SOLID Principles]]**: 아키텍처 리뷰 시 견고한 객체 지향 설계를 판단하는 절대적인 척도입니다.
|
||||
* **[[Architecture Decision Records (ADR)]]**: 리뷰를 통해 합의된 설계 선택과 트레이드오프를 기록하는 공식적인 도구입니다.
|
||||
* **[[Over-engineering]]**: 리뷰어가 가장 경계해야 할, 시스템 유지보수성을 해치는 불필요한 추상화와 일반화입니다.
|
||||
* **[[Shift-Left Strategy]]**: 설계 결함을 구현 전 초기 단계에서 잡아내어 리팩토링 비용을 예방하는 전략입니다.
|
||||
* **[[SOLID Principles|SOLID Principles]]**: 아키텍처 리뷰 시 견고한 객체 지향 설계를 판단하는 절대적인 척도입니다.
|
||||
* **Architecture Decision Records (ADR**: 리뷰를 통해 합의된 설계 선택과 트레이드오프를 기록하는 공식적인 도구입니다.
|
||||
* **Over-engineering**: 리뷰어가 가장 경계해야 할, 시스템 유지보수성을 해치는 불필요한 추상화와 일반화입니다.
|
||||
* **Shift-Left Strategy**: 설계 결함을 구현 전 초기 단계에서 잡아내어 리팩토링 비용을 예방하는 전략입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* ADR 작성 프로세스를 애자일 스프린트나 PR 워크플로우 내에 마찰 없이 매끄럽게 통합하기 위한 자동화 방안은 무엇인가?
|
||||
@@ -38,8 +38,8 @@
|
||||
* **My Project Relevance:** 중대한 구조 변경 시 요구되는 별도의 '설계 승인(Design Approval)' 단계를 도입하여 아키텍처 표류를 방지합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Technical Debt (기술 부채)]]**: 아키텍처 리뷰 소홀로 인해 누적되는 장기적인 비용과 운영 리스크에 대해 탐구합니다.
|
||||
* **[[Code Smells]]**: 고수준의 설계 결함이 소스 코드 레벨에서 어떤 구현 안티 패턴으로 발현되는지 분석합니다.
|
||||
* **Technical Debt (기술 부채**: 아키텍처 리뷰 소홀로 인해 누적되는 장기적인 비용과 운영 리스크에 대해 탐구합니다.
|
||||
* **Code Smells**: 고수준의 설계 결함이 소스 코드 레벨에서 어떤 구현 안티 패턴으로 발현되는지 분석합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Automated Code Analysis (자동화된 코드 분석)]]
|
||||
# [[Automated Code Analysis (자동화된 코드 분석)|Automated Code Analysis (자동화된 코드 분석]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
자동화된 코드 분석(Automated Code Analysis)은 코드가 인간 리뷰어에게 전달되기 전에 도구를 사용하여 구문, 스타일, 버그, 보안 취약점 등을 알고리즘적으로 검사하는 프로세스입니다 [1]. 이는 정적 분석(SAST), 동적 분석(DAST), 린팅(Linting), 소프트웨어 구성 분석(SCA) 등을 포함하며, 코드 리뷰의 일차적 방어선 역할을 합니다 [1-3]. 이를 통해 인간 리뷰어는 단순한 스타일 교정에서 벗어나 아키텍처, 비즈니스 로직 등 비판적 사고가 필요한 고차원적인 문제에 집중할 수 있게 됩니다 [4, 5].
|
||||
@@ -22,10 +22,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[SAST (Static Application Security Testing)]]**: 코드 실행 전 소스 자체를 분석하여 결함 위치를 정확히 찾아내는 자동화의 핵심입니다.
|
||||
* **[[DAST (Dynamic Application Security Testing)]]**: 실행 중인 애플리케이션 관점에서 보안 위협을 탐지하여 SAST의 사각지대를 보완합니다.
|
||||
* **[[Linters & Formatters]]**: 코드 스타일과 기본 구문을 자동 교정하여 리뷰어의 시각적 피로를 줄여줍니다.
|
||||
* **[[SCA (Software Composition Analysis)]]**: 공급망 보안(Supply Chain Security) 관리를 위한 필수적인 오픈소스 의존성 스캔 기술입니다.
|
||||
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 코드 실행 전 소스 자체를 분석하여 결함 위치를 정확히 찾아내는 자동화의 핵심입니다.
|
||||
* **[[DAST (Dynamic Application Security Testing)|DAST (Dynamic Application Security Testing]]**: 실행 중인 애플리케이션 관점에서 보안 위협을 탐지하여 SAST의 사각지대를 보완합니다.
|
||||
* **Linters & Formatters**: 코드 스타일과 기본 구문을 자동 교정하여 리뷰어의 시각적 피로를 줄여줍니다.
|
||||
* **SCA (Software Composition Analysis**: 공급망 보안(Supply Chain Security) 관리를 위한 필수적인 오픈소스 의존성 스캔 기술입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 정적 분석 도구의 오탐(False Positives)을 줄이고 개발자의 수용도를 높이기 위한 '상황 인식(Context-aware) 튜닝' 전략은 무엇인가?
|
||||
@@ -42,8 +42,8 @@
|
||||
* **My Project Relevance:** 스타일 지적 등 소모적인 논쟁을 자동화에 위임하고, 아키텍처 및 비즈니스 로직 중심의 고도화된 코드 리뷰 문화를 정착시킵니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Shift-Left Security]]**: 보안 검토를 SDLC 가장 앞단으로 앞당겨 수정 비용을 대폭 절감하는 전략적 접근입니다.
|
||||
* **[[Technical Debt (기술 부채)]]**: 자동 분석으로 식별된 코드 스멜(Code Smells)을 정량화하고 관리하여 시스템의 건강성을 유지하는 방안으로 확장됩니다.
|
||||
* **Shift-Left Security**: 보안 검토를 SDLC 가장 앞단으로 앞당겨 수정 비용을 대폭 절감하는 전략적 접근입니다.
|
||||
* **Technical Debt (기술 부채**: 자동 분석으로 식별된 코드 스멜(Code Smells)을 정량화하고 관리하여 시스템의 건강성을 유지하는 방안으로 확장됩니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[CI/CD Pipeline Security (CI/CD 파이프라인 보안)]]
|
||||
# [[CI-CD Pipeline Security (CI-CD 파이프라인 보안)|CI/CD Pipeline Security (CI/CD 파이프라인 보안]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
CI/CD 파이프라인 보안은 소프트웨어 개발의 지속적 통합 및 배포(CI/CD) 과정에서 소스 코드, 설정, 서드파티 의존성에 존재하는 보안 취약점과 결함을 자동으로 식별하고 차단하는 방어 체계를 의미합니다 [1]. 코드 리뷰 프로세스와 결합하여 정적 분석(SAST), 시크릿(Secret) 스캐닝, 의존성 검사(SCA) 등의 자동화 도구를 실행하며, 심각한 위험 감지 시 병합(Merge)을 차단하는 게이트키퍼 역할을 수행합니다 [4]. 이를 통해 개발 속도를 유지하면서도 공급망을 보호하고 전체 시스템의 안정성을 보장합니다 [5, 7].
|
||||
@@ -16,10 +16,10 @@ CI/CD 파이프라인 보안은 소프트웨어 개발의 지속적 통합 및
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[SAST (Static Application Security Testing)]]**: 코드 실행 전 소스 분석을 통해 취약점 위치를 라인 수준에서 짚어주는 핵심 스캐닝 도구입니다.
|
||||
* **[[SCA (Software Composition Analysis)]]**: 서드파티 의존성 패키지의 취약점과 라이선스 위반을 검사하여 공급망 보안을 강화합니다.
|
||||
* **[[Automated Quality Gates]]**: 보안 및 품질 기준을 통과해야만 병합이 가능하도록 시스템적으로 강제하는 관문입니다.
|
||||
* **[[Shift-Left Security]]**: 보안 검토를 SDLC 가장 초기 단계로 앞당겨 수정 비용을 절감하려는 근본적인 전략입니다.
|
||||
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 코드 실행 전 소스 분석을 통해 취약점 위치를 라인 수준에서 짚어주는 핵심 스캐닝 도구입니다.
|
||||
* **SCA (Software Composition Analysis**: 서드파티 의존성 패키지의 취약점과 라이선스 위반을 검사하여 공급망 보안을 강화합니다.
|
||||
* **Automated Quality Gates**: 보안 및 품질 기준을 통과해야만 병합이 가능하도록 시스템적으로 강제하는 관문입니다.
|
||||
* **Shift-Left Security**: 보안 검토를 SDLC 가장 초기 단계로 앞당겨 수정 비용을 절감하려는 근본적인 전략입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* SAST/SCA 스캔 결과의 오탐을 줄이고 리뷰어의 피로도를 낮추기 위한 '상황 인식(Context-aware) 정책 최적화' 방안은 무엇인가?
|
||||
@@ -36,8 +36,8 @@ CI/CD 파이프라인 보안은 소프트웨어 개발의 지속적 통합 및
|
||||
* **My Project Relevance:** 스타일 및 단순 취약점 지적을 자동화에 맡겨 리뷰어의 소모적 업무를 줄이고, 핵심 로직 및 구조적 피드백의 밀도를 높입니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Dependency Management (의존성 관리)]]**: Dependabot 등을 활용하여 외부 라이브러리의 취약점을 지속적으로 추적하고 업데이트하는 전략입니다.
|
||||
* **[[Policy-as-Code (코드로서의 정책)]]**: 보안 및 거버넌스 규칙을 코드로 정의하여 자동 검증하고 버전 관리하는 최신 관리 방법론입니다.
|
||||
* **Dependency Management (의존성 관리**: Dependabot 등을 활용하여 외부 라이브러리의 취약점을 지속적으로 추적하고 업데이트하는 전략입니다.
|
||||
* **Policy-as-Code (코드로서의 정책**: 보안 및 거버넌스 규칙을 코드로 정의하여 자동 검증하고 버전 관리하는 최신 관리 방법론입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [governance, code-quality, code-health, simplicity, maintainability, reada
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Code Quality & Health]]
|
||||
# [[Code Quality & Health|Code Quality & Health]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드베이스의 장기적 생존성과 팀의 개발 속도를 결정하는 핵심 자산: 인지적 부하를 최소화하는 단순성(Simplicity)과 미래의 변화를 수용하는 유지보수성(Maintainability)의 조화로운 상태."
|
||||
@@ -28,9 +28,9 @@ last_reinforced: 2026-05-01
|
||||
- **가독성 vs 성능**: 간결하고 읽기 쉬운 코드가 때로는 마이크로 최적화 관점에서 성능을 희생할 수 있습니다. 성능이 크리티컬한 영역이 아니라면 유지보수성을 우선하는 것이 장기적으로 유리합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Single Responsibility Principle (SRP)]]: 코드를 단순하게 만드는 구조적 원칙.
|
||||
- [[Refactoring]]: 코드 건강을 회복시키는 실천적 행위.
|
||||
- [[Technical Debt]]: 코드 품질 저하 시 발생하는 잠재적 비용.
|
||||
- [[Over-engineering]]: 단순성을 해치는 가장 큰 위협.
|
||||
- [[Testability]]: 단순한 코드가 가져오는 부가적 이득.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 코드를 단순하게 만드는 구조적 원칙.
|
||||
- [[Refactoring|Refactoring]]: 코드 건강을 회복시키는 실천적 행위.
|
||||
- [[Technical-Debt|Technical Debt]]: 코드 품질 저하 시 발생하는 잠재적 비용.
|
||||
- Over-engineering: 단순성을 해치는 가장 큰 위협.
|
||||
- [[테스트 용이성 (Testability)|Testability]]: 단순한 코드가 가져오는 부가적 이득.
|
||||
---
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[Code Review Automation & Metrics (코드 리뷰 자동화 및 지표)]]
|
||||
# [[Code Review Automation & Metrics (코드 리뷰 자동화 및 지표)|Code Review Automation & Metrics (코드 리뷰 자동화 및 지표]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
코드 리뷰 자동화 및 지표는 소프트웨어 개발의 품질 검증 과정을 기계적으로 가속화하고, 그 효율성을 객관적인 데이터로 측정하는 체계입니다 [1]. 정적 분석(SAST), 린팅(Linting), 단위 테스트 등을 자동화하여 인간 리뷰어의 인지 부하를 줄이고, 결함 밀도, 리뷰 주기 시간(Cycle Time), 변경 실패율 등의 지표를 통해 개발 프로세스의 병목을 식별합니다 [2, 3]. 이는 개별 개발자 평가가 아닌, 팀 전체의 생산성 향상과 고품질 소프트웨어의 신속한 배포를 위한 전략적 기반으로 기능합니다.
|
||||
@@ -22,10 +22,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[DORA Metrics]]**: 배포 빈도, 변경 리드 타임 등 팀의 전반적인 데브옵스 성과를 측정하는 업계 표준 지표입니다.
|
||||
* **[[Automated Code Analysis]]**: SAST, SCA 등 리뷰 자동화를 실질적으로 구현하는 기술적 도구 체계입니다.
|
||||
* **[[Pull Request Size]]**: 리뷰 속도(Cycle Time)와 결함 발견율에 결정적 영향을 미치는 핵심 선행 지표입니다.
|
||||
* **[[CI/CD Pipeline]]**: 자동화된 분석과 품질 게이트가 실제로 동작하는 물리적 인프라 환경입니다.
|
||||
* **[[DORA-Metrics|DORA Metrics]]**: 배포 빈도, 변경 리드 타임 등 팀의 전반적인 데브옵스 성과를 측정하는 업계 표준 지표입니다.
|
||||
* **[[Automated Code Analysis (자동화된 코드 분석)|Automated Code Analysis]]**: SAST, SCA 등 리뷰 자동화를 실질적으로 구현하는 기술적 도구 체계입니다.
|
||||
* **Pull Request Size**: 리뷰 속도(Cycle Time)와 결함 발견율에 결정적 영향을 미치는 핵심 선행 지표입니다.
|
||||
* **[[CI-CD Pipeline|CI/CD Pipeline]]**: 자동화된 분석과 품질 게이트가 실제로 동작하는 물리적 인프라 환경입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 결함 이탈률이 높을 때, 이것이 리뷰어의 도메인 지식 부족 때문인지 테스트 자동화의 사각지대 때문인지 객관적으로 구분하여 진단하는 프레임워크는 무엇인가?
|
||||
@@ -42,8 +42,8 @@
|
||||
* **My Project Relevance:** 소모적인 스타일 논쟁을 자동화에 위임하고, 수집된 지표를 기반으로 팀의 리뷰 문화를 지속적으로 고도화합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Code Review Culture]]**: 정성적인 팀 문화와 정량적인 품질 지표 사이의 상관관계 및 심리적 안전감의 영향을 탐구합니다.
|
||||
* **[[Shift-Left Security]]**: 보안 검토를 조기에 자동화하여 수정 비용 지표를 낮추는 전략적 연계입니다.
|
||||
* **Code Review Culture**: 정성적인 팀 문화와 정량적인 품질 지표 사이의 상관관계 및 심리적 안전감의 영향을 탐구합니다.
|
||||
* **Shift-Left Security**: 보안 검토를 조기에 자동화하여 수정 비용 지표를 낮추는 전략적 연계입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[Code Review Etiquette & Communication (코드 리뷰 에티켓 및 커뮤니케이션)]]
|
||||
# [[Code Review Etiquette & Communication (코드 리뷰 에티켓 및 커뮤니케이션)|Code Review Etiquette & Communication (코드 리뷰 에티켓 및 커뮤니케이션]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
코드 리뷰 에티켓 및 커뮤니케이션은 리뷰어와 작성자 간의 상호 존중과 협력을 바탕으로 건설적인 피드백을 주고받기 위한 행동 규범입니다 [1]. 이는 단순한 결함 발견을 넘어 팀 내 심리적 안전감을 형성하고 지식 공유를 촉진하며, 시스템의 장기적인 건전성을 유지하는 데 기여합니다 [4]. 명확한 의도 전달, 객관적인 언어 사용, 긍정적인 피드백의 균형을 통해 불필요한 감정 소모 없이 효율적으로 코드 품질을 높이는 것을 핵심 목표로 합니다.
|
||||
@@ -23,10 +23,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[심리적 안전감(Psychological Safety)]]**: 비판이 아닌 개선을 위한 협업임을 신뢰하는 효과적인 리뷰의 심리적 토대입니다.
|
||||
* **[[IKEA 효과(IKEA Effect)]]**: 작성자가 자신의 코드에 과도한 가치를 부여하여 피드백을 방어적으로 받아들이게 되는 인지 편향입니다.
|
||||
* **[[Conventional Comments]]**: 피드백 라벨링을 통해 소통 마찰을 줄이는 구체적인 시스템 프레임워크입니다.
|
||||
* **[[Egoless Programming]]**: 개인의 자존심보다 팀의 코드 품질을 최우선으로 생각하는 개발 철학입니다.
|
||||
* **[[심리적 안전감 (Psychological Safety)|심리적 안전감(Psychological Safety]]**: 비판이 아닌 개선을 위한 협업임을 신뢰하는 효과적인 리뷰의 심리적 토대입니다.
|
||||
* **IKEA 효과(IKEA Effect**: 작성자가 자신의 코드에 과도한 가치를 부여하여 피드백을 방어적으로 받아들이게 되는 인지 편향입니다.
|
||||
* **Conventional Comments**: 피드백 라벨링을 통해 소통 마찰을 줄이는 구체적인 시스템 프레임워크입니다.
|
||||
* **Egoless Programming**: 개인의 자존심보다 팀의 코드 품질을 최우선으로 생각하는 개발 철학입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 비동기 텍스트 리뷰에서 발생할 수 있는 '톤(Tone)의 오해'를 AI가 감지하여 더 부드러운 표현으로 수정을 제안해주는 도구의 효용성은 어느 정도인가?
|
||||
@@ -43,8 +43,8 @@
|
||||
* **My Project Relevance:** 댓글 스레드가 길어지면 "10분만 대화하시죠"라고 제안하여 감정적 핑퐁을 끊고 문제를 신속히 해결합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Automated Static Analysis & Linters]]**: 인간 간의 스타일 논쟁을 근본적으로 제거하기 위한 자동화 도구 체계입니다.
|
||||
* **[[Pair Programming]]**: 소통 지연과 오해를 실시간 대화로 즉시 해소하는 동기식 협업 방식입니다.
|
||||
* **Automated Static Analysis & Linters**: 인간 간의 스타일 논쟁을 근본적으로 제거하기 위한 자동화 도구 체계입니다.
|
||||
* **Pair Programming**: 소통 지연과 오해를 실시간 대화로 즉시 해소하는 동기식 협업 방식입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Code Review Foundations (코드 리뷰 기초)]]
|
||||
# [[Code Review Foundations (코드 리뷰 기초)|Code Review Foundations (코드 리뷰 기초]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
코드 리뷰(Code Review)는 한 명 이상의 개발자가 다른 개발자가 작성한 소스 코드를 검토하여 버그를 찾고, 품질을 높이며, 지식을 공유하는 협업 프로세스입니다 [1]. 이는 소프트웨어 개발 생명주기(SDLC)에서 결함을 조기에 발견하여 수정 비용을 절감하고 시스템의 아키텍처적 일관성을 유지하는 핵심 방어선 역할을 합니다 [2, 3]. 리뷰 방식은 실시간으로 진행되는 '동기식(Synchronous)'과 PR/MR 도구를 활용하는 '비동기식(Asynchronous)'으로 나뉘며, 조직의 규모와 목적에 따라 상호 보완적으로 활용됩니다 [4, 5].
|
||||
@@ -28,10 +28,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Pair Programming]]**: 코드를 작성하면서 실시간으로 리뷰가 완료되는 가장 강력한 동기식 협업 기법입니다.
|
||||
* **[[Pull Request (PR) Workflow]]**: 비동기식 리뷰가 이루어지는 현대적인 표준 개발 워크플로우입니다.
|
||||
* **[[DORA Metrics]]**: 리뷰 속도와 효율성이 팀의 소프트웨어 전달 성과에 미치는 영향을 측정하는 지표 체계입니다.
|
||||
* **[[Shift-Left Security]]**: 보안 검토를 코드 리뷰 단계로 앞당겨 수정 비용을 절감하려는 전략적 접근입니다.
|
||||
* **Pair Programming**: 코드를 작성하면서 실시간으로 리뷰가 완료되는 가장 강력한 동기식 협업 기법입니다.
|
||||
* **Pull Request (PR) Workflow**: 비동기식 리뷰가 이루어지는 현대적인 표준 개발 워크플로우입니다.
|
||||
* **[[DORA-Metrics|DORA Metrics]]**: 리뷰 속도와 효율성이 팀의 소프트웨어 전달 성과에 미치는 영향을 측정하는 지표 체계입니다.
|
||||
* **Shift-Left Security**: 보안 검토를 코드 리뷰 단계로 앞당겨 수정 비용을 절감하려는 전략적 접근입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 비동기 리뷰 중 댓글 대화가 몇 회 이상 지속될 때 동기식 회의로 전환하는 것이 팀의 생산성 ROI 측면에서 가장 유리한가?
|
||||
@@ -48,8 +48,8 @@
|
||||
* **My Project Relevance:** 스타일 지적 등 기계적인 검증은 자동화 도구(CI/CD)에 맡기고, 리뷰어는 비즈니스 로직과 설계의 적합성 검증이라는 본연의 가치에 집중합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Code Review Communication Etiquette]]**: 효율적인 피드백 전달을 위한 어조, 기술, 감정 관리 등 소프트 스킬 영역으로 확장됩니다.
|
||||
* **[[Egoless Programming]]**: 개인의 자존심을 버리고 팀의 코드를 최우선으로 생각하는 개발 철학입니다.
|
||||
* **Code Review Communication Etiquette**: 효율적인 피드백 전달을 위한 어조, 기술, 감정 관리 등 소프트 스킬 영역으로 확장됩니다.
|
||||
* **Egoless Programming**: 개인의 자존심을 버리고 팀의 코드를 최우선으로 생각하는 개발 철학입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[Code Review Operational Excellence (코드 리뷰 운영 우수성)]]
|
||||
# [[Code Review Operational Excellence (코드 리뷰 운영 우수성)|Code Review Operational Excellence (코드 리뷰 운영 우수성]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
코드 리뷰 운영 우수성은 리뷰 프로세스의 속도, 품질, 그리고 개발자 경험(DX)을 최적화하기 위한 운영 전략과 실행 지침입니다. 명확한 Git 커밋 메시지 작성, 체크리스트를 활용한 체계적 검토, 서비스 수준 협약(SLA) 기반의 응답 시간 관리, 그리고 컨텍스트 스위칭(Context Switching) 비용 최소화를 통해 팀의 생산성을 극대화합니다 [1, 4]. 이는 기술 부채를 통제하고 코드 건강(Code Health)을 유지하는 동시에 개발 파이프라인의 병목을 제거하는 것을 목표로 합니다.
|
||||
@@ -26,10 +26,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Pull Request Best Practices]]**: 작은 PR 유지와 템플릿 활용 등 PR 단계의 운영 실무입니다.
|
||||
* **[[DORA Metrics]]**: 리뷰 속도가 배포 빈도와 변경 리드 타임에 미치는 영향을 측정하는 상위 지표입니다.
|
||||
* **[[Code Review Automation & Metrics]]**: 운영 데이터를 수집하고 분석하는 기술적 수단입니다.
|
||||
* **[[Architecture Decision Records (ADR)]]**: 중대한 설계 결정 배경을 기록하여 장기적인 운영 맥락을 제공합니다.
|
||||
* **Pull Request Best Practices**: 작은 PR 유지와 템플릿 활용 등 PR 단계의 운영 실무입니다.
|
||||
* **[[DORA-Metrics|DORA Metrics]]**: 리뷰 속도가 배포 빈도와 변경 리드 타임에 미치는 영향을 측정하는 상위 지표입니다.
|
||||
* **[[Code Review Automation & Metrics (코드 리뷰 자동화 및 지표)|Code Review Automation & Metrics]]**: 운영 데이터를 수집하고 분석하는 기술적 수단입니다.
|
||||
* **Architecture Decision Records (ADR**: 중대한 설계 결정 배경을 기록하여 장기적인 운영 맥락을 제공합니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 리뷰어의 컨텍스트 스위칭 비용을 최소화하기 위해, 캘린더의 '집중 시간'과 연동하여 리뷰 요청을 지연(Batching) 전달하는 시스템의 효용성은 어느 정도인가?
|
||||
@@ -46,8 +46,8 @@
|
||||
* **My Project Relevance:** 'SLA 기반 리뷰 문화'를 도입하여 PR이 며칠씩 방치되는 현상을 제거하고 개발 흐름을 가속화합니다 [45].
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Cognitive Load Theory]]**: 리뷰어의 인지 부하를 줄이기 위한 정보 전달 방식의 심리학적 배경입니다.
|
||||
* **[[Continuous Deployment (CD)]]**: 고도화된 리뷰 운영이 어떻게 사람의 개입 없는 자동 배포로 이어지는지에 대한 연계성입니다.
|
||||
* **[[Cognitive Load Theory|Cognitive Load Theory]]**: 리뷰어의 인지 부하를 줄이기 위한 정보 전달 방식의 심리학적 배경입니다.
|
||||
* **Continuous Deployment (CD**: 고도화된 리뷰 운영이 어떻게 사람의 개입 없는 자동 배포로 이어지는지에 대한 연계성입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
---
|
||||
title: 협업 가이드라인 및 코드 거버넌스
|
||||
category: Software [[Architecture]]
|
||||
tags: [Collaboration, PR, [[Code Review]], Documentation, Governance]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Collaboration, PR, [[Code Review|Code Review]], Documentation, Governance]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Collaboration_Governance]] (협업과 코드 품격)
|
||||
# [[Collaboration_Governance|Collaboration_Governance]] (협업과 코드 품격)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 코드는 혼자 쓰는 일기장이 아니라 함께 짓는 건축물이다. 동료의 시간을 아껴주는 문서화와 소통 방식이 당신의 가치를 증명한다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **[[Pull Request (PR)]] 에티켓**:
|
||||
- **[[Pull Request (PR)|Pull Request (PR]] 에티켓**:
|
||||
- "이거 고쳤습니다"는 최악의 PR이다. 무엇을(What), 왜(Why), 어떻게(How) 했는지 명시하고 가능한 시각적 결과물(스크린샷, GIF)을 첨부하여 리뷰어의 인지 부하를 줄여라.
|
||||
- **Code Review Protocol**:
|
||||
- P1(필수 반영), P2(권장), P3(질문/의견) 식으로 중요도를 표시하라. 비판은 날카롭게 하되 표현은 따뜻하게 하여 팀의 심리적 안정성을 유지하라.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 완벽한 거버넌스를 추구하느라 소통이 무거워지면 안 된다. 빠른 배포가 필요한 시점에는 '기술 부채'를 명문화하고 나중에 갚는 기민함(Agile)도 필요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Clean_Code_Best_Practices]] , [[Deployment_Final_Gate]]
|
||||
- Foundation: [[System_Debugging_Protocol]]
|
||||
- Related: [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]] , [[Deployment_Final_Gate|Deployment_Final_Gate]]
|
||||
- Foundation: [[System_Debugging_Protocol|System_Debugging_Protocol]]
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[DORA Metrics (소프트웨어 전달 성과 지표)]]
|
||||
# [[DORA Metrics (소프트웨어 전달 성과 지표)|DORA Metrics (소프트웨어 전달 성과 지표]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
DORA(DevOps Research and Assessment) 지표는 소프트웨어 개발 조직의 전달(Delivery) 성능과 운영 효율성을 측정하는 글로벌 표준 기준입니다 [1]. 코드 리뷰의 속도와 효율성은 DORA 지표에 직결되며, 빠른 리뷰 주기를 유지하는 엘리트(Elite) 팀은 그렇지 않은 팀보다 50% 더 높은 딜리버리 성과를 보입니다 [2]. DORA 지표는 배포 빈도, 변경 리드 타임, 서비스 복구 시간, 변경 실패율의 4가지 핵심 지표를 통해 조직의 역량을 객관적으로 진단합니다 [3].
|
||||
@@ -24,10 +24,10 @@ DORA(DevOps Research and Assessment) 지표는 소프트웨어 개발 조직의
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Review-Speed Benchmarks]]**: DORA 데이터를 기반으로 리뷰 속도를 엘리트, 우수, 수용 가능 수준으로 구분하여 정량 평가하는 기준입니다.
|
||||
* **[[Pull Request Size Limits (PR 크기 제한)]]**: 엘리트 등급의 리뷰 속도 달성을 위한 선제 조건으로, 리뷰어의 인지 부하를 최소화합니다.
|
||||
* **[[Automation in Code Review (코드 리뷰 자동화)]]**: 기계적 검증을 자동화하여 인간 리뷰어가 고차원적 가치 창출(지식 공유 등)에 집중하게 돕습니다.
|
||||
* **[[Software Delivery Performance]]**: DORA 지표가 궁극적으로 측정하고자 하는 소프트웨어 전달 역량의 종합적 성과입니다.
|
||||
* **Review-Speed Benchmarks**: DORA 데이터를 기반으로 리뷰 속도를 엘리트, 우수, 수용 가능 수준으로 구분하여 정량 평가하는 기준입니다.
|
||||
* **Pull Request Size Limits (PR 크기 제한**: 엘리트 등급의 리뷰 속도 달성을 위한 선제 조건으로, 리뷰어의 인지 부하를 최소화합니다.
|
||||
* **Automation in Code Review (코드 리뷰 자동화**: 기계적 검증을 자동화하여 인간 리뷰어가 고차원적 가치 창출(지식 공유 등)에 집중하게 돕습니다.
|
||||
* **Software Delivery Performance**: DORA 지표가 궁극적으로 측정하고자 하는 소프트웨어 전달 역량의 종합적 성과입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 지리적으로 분산된 글로벌 팀이 DORA의 '첫 리뷰 1시간 이내' 기준을 달성하기 위해 비동기 협업 및 알림(Notification) 시스템을 어떻게 최적화해야 하는가?
|
||||
@@ -44,8 +44,8 @@ DORA(DevOps Research and Assessment) 지표는 소프트웨어 개발 조직의
|
||||
* **My Project Relevance:** 현재 팀의 평균 리드 타임과 배포 빈도 데이터를 추출하여 DORA 벤치마크와 비교 진단하고 병목 구간을 개선합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[DevOps Culture]]**: DORA 지표가 효과를 발휘하기 위해 전제되어야 할 팀의 심리적 안전감과 실험 정신 등 문화적 측면으로 확장됩니다.
|
||||
* **[[Cycle Time (TTR)]]**: PR 생성부터 병합까지의 전체 주기를 측정하고 관리하는 실무적 지표 체계입니다.
|
||||
* **DevOps Culture**: DORA 지표가 효과를 발휘하기 위해 전제되어야 할 팀의 심리적 안전감과 실험 정신 등 문화적 측면으로 확장됩니다.
|
||||
* **Cycle Time (TTR**: PR 생성부터 병합까지의 전체 주기를 측정하고 관리하는 실무적 지표 체계입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[Dependency & Supply Chain Security (의존성 및 공급망 보안)]]
|
||||
# [[Dependency & Supply Chain Security (의존성 및 공급망 보안)|Dependency & Supply Chain Security (의존성 및 공급망 보안]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
의존성 및 공급망 보안은 애플리케이션 개발에 사용되는 외부 오픈소스 라이브러리와 서드파티 컴포넌트의 무결성을 보장하고 보안 취약점을 관리하는 프로세스입니다 [1]. 현대 소프트웨어의 80% 이상이 외부 의존성으로 구성되므로, 직접 작성한 코드만큼이나 외부 유입 코드의 안전성을 검증하는 것이 필수적입니다 [2]. SCA(Software Composition Analysis) 도구와 Dependabot과 같은 자동화 시스템을 활용하여 알려진 취약점(CVE)과 라이선스 위반을 실시간으로 감지하고 대응합니다 [1, 2].
|
||||
@@ -22,10 +22,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[SAST (Static Application Security Testing)]]**: 내부 작성 소스 코드의 결함을 찾는 도구로, SCA와 상호 보완적인 관계입니다.
|
||||
* **[[CVE (Common Vulnerabilities and Exposures)]]**: SCA 도구가 참조하는 '알려진 취약점'의 표준 데이터베이스입니다.
|
||||
* **[[SBOM (Software Bill of Materials)]]**: 애플리케이션의 모든 구성 요소를 명시한 자재 명세서로, 공급망 투명성의 핵심 자산입니다.
|
||||
* **[[Shift-Left Security]]**: 보안 스캔을 개발 초기 단계로 앞당겨 리스크를 줄이는 DevSecOps의 핵심 철학입니다.
|
||||
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 내부 작성 소스 코드의 결함을 찾는 도구로, SCA와 상호 보완적인 관계입니다.
|
||||
* **CVE (Common Vulnerabilities and Exposures**: SCA 도구가 참조하는 '알려진 취약점'의 표준 데이터베이스입니다.
|
||||
* **SBOM (Software Bill of Materials**: 애플리케이션의 모든 구성 요소를 명시한 자재 명세서로, 공급망 투명성의 핵심 자산입니다.
|
||||
* **Shift-Left Security**: 보안 스캔을 개발 초기 단계로 앞당겨 리스크를 줄이는 DevSecOps의 핵심 철학입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* SCA 도구가 수많은 전이 의존성 중 실제 애플리케이션의 실행 경로(Code Path)에 포함되어 실질적 위협이 되는 요소를 어떻게 선별적으로 식별하는가?
|
||||
@@ -42,8 +42,8 @@
|
||||
* **My Project Relevance:** 코드 리뷰 체크리스트에 '의존성 보안 점검' 항목을 추가하고, 자동화 도구를 통해 리뷰어의 육안 검사 부담을 해소합니다 [54].
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Policy-as-Code]]**: 보안 차단 기준을 코드로 정의하여 파이프라인에서 자동 강제하는 전략입니다.
|
||||
* **[[Vulnerability Management]]**: 발견된 취약점의 생명주기를 관리하고 조치 우선순위를 정하는 전체 프로세스로 확장됩니다.
|
||||
* **Policy-as-Code**: 보안 차단 기준을 코드로 정의하여 파이프라인에서 자동 강제하는 전략입니다.
|
||||
* **Vulnerability Management**: 발견된 취약점의 생명주기를 관리하고 조치 우선순위를 정하는 전체 프로세스로 확장됩니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [governance, dora-metrics, engineering-metrics, performance, devops, cycle
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Engineering Metrics (DORA)]]
|
||||
# [[Engineering Metrics (DORA)|Engineering Metrics (DORA]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터에 기반하여 소프트웨어 인도 성과(Delivery Performance)를 정량화하고, 엘리트 팀의 벤치마크를 통해 개발 프로세스의 병목과 개선 방향을 제시하는 엔지니어링 표준 지표."
|
||||
@@ -31,9 +31,9 @@ DORA 지표는 데브옵스(DevOps) 연구를 통해 입증된 고성과 팀의
|
||||
- **데이터의 맥락**: 단순 수치만으로 팀을 평가하기보다, 지표의 변화 추이를 통해 팀의 프로세스 건전성을 진단하고 병목을 해결하는 도구로 활용해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Review Performance & Flow]]: DORA 지표를 달성하기 위한 구체적 운영 전략.
|
||||
- [[Small Pull Requests (작은 PR)]]: Lead Time을 단축하는 가장 강력한 수단.
|
||||
- [[Automated Quality & Review]]: 인간의 시간을 절약하여 성과를 극대화하는 기반.
|
||||
- [[CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
|
||||
- [[DORA Metrics]]: 원본 개념 정의.
|
||||
- [[Review Performance & Flow|Review Performance & Flow]]: DORA 지표를 달성하기 위한 구체적 운영 전략.
|
||||
- Small Pull Requests (작은 PR: Lead Time을 단축하는 가장 강력한 수단.
|
||||
- [[Automated Quality & Review|Automated Quality & Review]]: 인간의 시간을 절약하여 성과를 극대화하는 기반.
|
||||
- [[CI-CD Pipeline|CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
|
||||
- [[DORA-Metrics|DORA Metrics]]: 원본 개념 정의.
|
||||
---
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Index: Topics > 04_Governance_Reliability
|
||||
|
||||
## 📝 Documents
|
||||
- [[Accessibility_Inclusivity]]
|
||||
- [[Collaboration_Governance]]
|
||||
- [[Reliability_Safety_First]]
|
||||
- [[Styling_Governance]]
|
||||
- [[System_Debugging_Protocol]]
|
||||
- [[System_Protocol_Standard]]
|
||||
- [[Accessibility_Inclusivity|Accessibility_Inclusivity]]
|
||||
- [[Collaboration_Governance|Collaboration_Governance]]
|
||||
- [[Reliability_Safety_First|Reliability_Safety_First]]
|
||||
- [[Styling_Governance|Styling_Governance]]
|
||||
- [[System_Debugging_Protocol|System_Debugging_Protocol]]
|
||||
- [[System_Protocol_Standard|System_Protocol_Standard]]
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[Pull Request Best Practices (PR 베스트 프랙티스)]]
|
||||
# [[Pull Request Best Practices (PR 베스트 프랙티스)|Pull Request Best Practices (PR 베스트 프랙티스]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Pull Request(PR) 베스트 프랙티스는 코드 변경 사항을 메인 브랜치에 통합하기 전, 리뷰와 검증 과정을 효율화하고 품질을 높이기 위한 핵심 활동 지침입니다 [1]. PR을 작고 응집력 있는 단위(200~400 LOC 이하)로 유지하고, 템플릿을 활용해 변경 맥락을 명확히 전달하며, 자동화된 도구와 결합하여 리뷰어의 인지 부하를 최소화하는 것을 목표로 합니다 [2, 5]. 이는 결함 발견율을 높이고 배포 주기를 단축하며 팀의 협업 생산성을 극대화하는 기반이 됩니다.
|
||||
@@ -24,10 +24,10 @@ Pull Request(PR) 베스트 프랙티스는 코드 변경 사항을 메인 브랜
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Feature Flags]]**: 미완성 기능을 사용자에게 노출하지 않고 지속적으로 작은 PR을 병합할 수 있게 돕는 핵심 도구입니다.
|
||||
* **[[Stacked Pull Requests]]**: 상호 의존적인 여러 변경 사항을 논리적 단계로 나누어 리뷰 흐름을 관리하는 워크플로우입니다.
|
||||
* **[[Defect Density]]**: PR 크기와 결함 발견율 사이의 상관관계를 보여주는 정량적 품질 지표입니다.
|
||||
* **[[Time to Review (TTR)]]**: 작은 PR을 통해 최소화하고자 하는 코드 리뷰 병목 시간 지표입니다.
|
||||
* **[[Feature-Flags|Feature Flags]]**: 미완성 기능을 사용자에게 노출하지 않고 지속적으로 작은 PR을 병합할 수 있게 돕는 핵심 도구입니다.
|
||||
* **Stacked Pull Requests**: 상호 의존적인 여러 변경 사항을 논리적 단계로 나누어 리뷰 흐름을 관리하는 워크플로우입니다.
|
||||
* **Defect Density**: PR 크기와 결함 발견율 사이의 상관관계를 보여주는 정량적 품질 지표입니다.
|
||||
* **Time to Review (TTR**: 작은 PR을 통해 최소화하고자 하는 코드 리뷰 병목 시간 지표입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 언어별 표현력 차이(장황한 Java vs 간결한 Python)에 따라 '작은 PR'의 기준(LOC)을 어떻게 차등 적용하는 것이 합리적인가?
|
||||
@@ -44,8 +44,8 @@ Pull Request(PR) 베스트 프랙티스는 코드 변경 사항을 메인 브랜
|
||||
* **My Project Relevance:** GitHub Actions를 활용해 PR 크기가 기준을 초과할 경우 자동으로 경고를 남기거나 병합을 제한하는 품질 게이트를 적용합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Continuous Integration (CI)]]**: 빈번하고 작은 단위의 병합이 어떻게 지속적 통합의 신뢰성을 높이는지 탐구합니다.
|
||||
* **[[Conventional Commits]]**: 커밋 메시지를 표준화하여 변경 이력의 가독성을 높이는 전략으로 확장됩니다.
|
||||
* **[[Continuous Integration (CI)|Continuous Integration (CI]]**: 빈번하고 작은 단위의 병합이 어떻게 지속적 통합의 신뢰성을 높이는지 탐구합니다.
|
||||
* **Conventional Commits**: 커밋 메시지를 표준화하여 변경 이력의 가독성을 높이는 전략으로 확장됩니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 애플리케이션 안정성 및 로깅 (Error Boundary)
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[Reliability]], Error Boundary, Sentry, Logging, [[Stability]]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [[Reliability|[Reliability]], Error Boundary, Sentry, Logging, Stability]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Reliability_Safety_First]] (애플리케이션 안정성)
|
||||
# [[Reliability_Safety_First|Reliability_Safety_First]] (애플리케이션 안정성)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 에러는 막는 것이 아니라 '우아하게 격리'하는 것이다. 컴포넌트 하나가 무너져도 전체 시스템은 안전하게 순항해야 한다.
|
||||
@@ -24,5 +24,5 @@ created: 2026-04-20
|
||||
- 모든 곳에 에러 바운더리를 칠 필요는 없다. 데이터와 UI가 1:1로 매칭되는 구조라면 차라리 상위에서 에러를 처리하는 것이 논리적으로 명확할 수 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[System_Debugging_Protocol]] , [[React_[[Testing]]_Strategy]]
|
||||
- Foundation: [[System_Protocol_Standard]]
|
||||
- Related: [[System_Debugging_Protocol|System_Debugging_Protocol]] , React_[[Testing Strategy|Testing_Strategy]]
|
||||
- Foundation: [[System_Protocol_Standard|System_Protocol_Standard]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [management, review-performance, cycle-time, context-switching, asynchrono
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Review Performance & Flow]]
|
||||
# [[Review Performance & Flow|Review Performance & Flow]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "팀 전체의 배포 속도(Velocity)와 개별 엔지니어의 몰입(Flow) 사이의 균형을 최적화하여, 기술적 병목을 제거하고 작업의 연속성을 보장하는 운영 전략."
|
||||
@@ -20,7 +20,7 @@ last_reinforced: 2026-05-01
|
||||
2. **인지적 부하 및 세션 관리**:
|
||||
* **200~400 LOC**: 한 번의 리뷰 세션(60~90분)에서 가장 효율적으로 결함을 발견할 수 있는 코드 크기입니다.
|
||||
* **컨텍스트 스위칭 방지**: 실시간 알림에 즉각 반응하기보다, 자연스러운 업무 중단점(Break point)에 리뷰를 모아서 처리(Batching)하여 개인의 몰입도를 보호합니다.
|
||||
3. **[[Asynchronous Code Review]]**:
|
||||
3. **Asynchronous Code Review**:
|
||||
* 문서화와 비동기 피드백을 통해 시간대(Time zone)가 다른 팀원들과도 효율적으로 협업하며, 각자의 일정에 맞춰 고품질의 검토를 수행합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
@@ -28,9 +28,9 @@ last_reinforced: 2026-05-01
|
||||
- **SLA의 유연성**: 모든 작업에 동일한 잣대를 대기보다, 긴급 핫픽스와 일반 기능 배포의 리뷰 우선순위와 SLA를 차등화하여 운영 효율성을 높여야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Small Pull Requests (작은 PR)]]: 리뷰 속도를 높이는 가장 근본적인 해결책.
|
||||
- [[Context Switching (컨텍스트 스위칭)]]: 리뷰 활동이 개인 생산성에 미치는 비용.
|
||||
- [[Time-to-Merge (Cycle Time)]]: 배포 성과를 측정하는 상위 지표.
|
||||
- [[Automated Code Analysis]]: 인간의 리뷰 시간을 아껴주는 자동화 엔진.
|
||||
- [[DORA Metrics]]: 엘리트 팀의 성과 기준.
|
||||
- Small Pull Requests (작은 PR: 리뷰 속도를 높이는 가장 근본적인 해결책.
|
||||
- Context Switching (컨텍스트 스위칭: 리뷰 활동이 개인 생산성에 미치는 비용.
|
||||
- Time-to-Merge (Cycle Time: 배포 성과를 측정하는 상위 지표.
|
||||
- [[Automated Code Analysis (자동화된 코드 분석)|Automated Code Analysis]]: 인간의 리뷰 시간을 아껴주는 자동화 엔진.
|
||||
- [[DORA-Metrics|DORA Metrics]]: 엘리트 팀의 성과 기준.
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Secure Code Review (보안 중심 코드 리뷰)]]
|
||||
# [[Secure Code Review (보안 중심 코드 리뷰)|Secure Code Review (보안 중심 코드 리뷰]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Secure Code Review(보안 코드 리뷰)는 소프트웨어가 배포되기 전에 소스 코드의 보안 취약점, 논리적 오류, 약점을 체계적으로 감사하여 애플리케이션의 안전성을 보장하는 프로세스입니다 [1]. 기능과 유지보수성에 초점을 맞추는 일반적인 코드 리뷰와 달리, 공격자의 관점(Adversarial mindset)에서 입력값 조작 가능성이나 민감 데이터 노출 여부를 중점적으로 파악합니다 [3, 4]. 자동화된 스캐닝 도구와 인간의 수동 분석을 결합하는 '시프트 레프트(Shift-Left)' 보안 전략의 핵심 단계로서 결함 수정 비용을 절감하고 규제 준수를 증명하는 필수적인 역할을 합니다 [5, 6].
|
||||
@@ -23,10 +23,10 @@ Secure Code Review(보안 코드 리뷰)는 소프트웨어가 배포되기 전
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Shift-Left Security]]**: 보안 검토를 SDLC 가장 초기 단계로 앞당겨 지속적으로 수행하는 전략입니다.
|
||||
* **[[SAST (Static Application Security Testing)]]**: 코드를 실행하지 않고 소스 수준에서 보안 결함을 찾아내는 1차 방어선입니다.
|
||||
* **[[SCA (Software Composition Analysis)]]**: 외부 의존성 라이브러리의 취약점(CVE) 및 공급망 보안 위험을 관리합니다.
|
||||
* **[[OWASP Top 10]]**: 보안 코드 리뷰 시 최우선으로 검증해야 할 치명적인 웹 위협 목록입니다.
|
||||
* **Shift-Left Security**: 보안 검토를 SDLC 가장 초기 단계로 앞당겨 지속적으로 수행하는 전략입니다.
|
||||
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 코드를 실행하지 않고 소스 수준에서 보안 결함을 찾아내는 1차 방어선입니다.
|
||||
* **SCA (Software Composition Analysis**: 외부 의존성 라이브러리의 취약점(CVE) 및 공급망 보안 위험을 관리합니다.
|
||||
* **[[OWASP Top 10|OWASP Top 10]]**: 보안 코드 리뷰 시 최우선으로 검증해야 할 치명적인 웹 위협 목록입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 일반 품질 리뷰와 보안 리뷰를 단일 워크플로우 내에서 통합할 때, 역할 분리와 최종 승인 권한(Approval Authority)을 어떻게 설계하는 것이 최적인가?
|
||||
@@ -43,8 +43,8 @@ Secure Code Review(보안 코드 리뷰)는 소프트웨어가 배포되기 전
|
||||
* **My Project Relevance:** 기능 중심 리뷰에서 탈피하여 보안 전용 체크리스트를 도입하고, 기계적 검토는 자동화에 위임하여 리뷰 품질을 고도화합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Threat Modeling]]**: 코드 작성 전 설계 단계에서 잠재적 위험을 미리 식별하는 선제적 보안 기법입니다.
|
||||
* **[[ASPM (Application Security Posture Management)]]**: SDLC 전반의 보안 위협을 가시화하고 우선순위를 정하는 통합 관리 플랫폼으로 확장됩니다.
|
||||
* **Threat Modeling**: 코드 작성 전 설계 단계에서 잠재적 위험을 미리 식별하는 선제적 보안 기법입니다.
|
||||
* **ASPM (Application Security Posture Management**: SDLC 전반의 보안 위협을 가시화하고 우선순위를 정하는 통합 관리 플랫폼으로 확장됩니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Security Core Practices (보안 핵심 프랙티스)]]
|
||||
# [[Security Core Practices (보안 핵심 프랙티스)|Security Core Practices (보안 핵심 프랙티스]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
보안 핵심 프랙티스는 소프트웨어 개발 수명 주기(SDLC) 전반에 걸쳐 자산의 무결성을 보호하고 위협을 선제적으로 차단하기 위한 필수 활동들의 모음입니다. 보안 점검을 초기 단계로 앞당기는 **시프트 레프트(Shift-Left)** 전략을 중심으로, 잠재적 공격 경로를 분석하는 **위협 모델링(Threat Modeling)**, 최소 권한 원칙(Least Privilege) 준수, 그리고 시크릿 및 취약점 탐지 자동화를 통해 제품 자체에 보안을 내재화(Built-in)하는 것을 목표로 합니다 [1, 4].
|
||||
@@ -25,10 +25,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[SDLC & SSDLC]]**: 보안 프랙티스가 실제로 통합되어 동작하는 전체 개발 프로세스 프레임워크입니다.
|
||||
* **[[Secure Code Review]]**: 시프트 레프트 전략이 인간의 통찰과 결합되어 실현되는 구체적인 검토 활동입니다.
|
||||
* **[[SAST & IAST]]**: 소스 코드와 런타임 환경에서 취약점을 자동으로 찾아내는 기술적 수단입니다.
|
||||
* **[[OWASP Top 10]]**: 보안 프랙티스를 통해 우선적으로 방어해야 할 웹 애플리케이션의 치명적 위협 목록입니다.
|
||||
* **[[SDLC & SSDLC (소프트웨어 개발 생명주기)|SDLC & SSDLC]]**: 보안 프랙티스가 실제로 통합되어 동작하는 전체 개발 프로세스 프레임워크입니다.
|
||||
* **[[Secure Code Review (보안 중심 코드 리뷰)|Secure Code Review]]**: 시프트 레프트 전략이 인간의 통찰과 결합되어 실현되는 구체적인 검토 활동입니다.
|
||||
* **SAST & IAST**: 소스 코드와 런타임 환경에서 취약점을 자동으로 찾아내는 기술적 수단입니다.
|
||||
* **[[OWASP Top 10|OWASP Top 10]]**: 보안 프랙티스를 통해 우선적으로 방어해야 할 웹 애플리케이션의 치명적 위협 목록입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 시프트 레프트 보안 도입 시 '배포 리드 타임(Lead Time)' 증가를 최소화하면서도 자동화 도구의 탐지 정확도를 높이기 위한 머신러닝 기반 필터링 기법은 무엇인가?
|
||||
@@ -45,8 +45,8 @@
|
||||
* **My Project Relevance:** 'OWASP Top 10' 및 '시크릿 유출 방지'를 코드 리뷰 필수 체크리스트로 편입하여 보안 기술 부채를 원천 차단합니다 [49].
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[DevSecOps]]**: 보안 프랙티스를 문화와 기술 전 영역에 끊김 없이 통합하는 거시적 방법론입니다.
|
||||
* **[[Software Supply Chain Security]]**: 소스 코드를 넘어 외부 의존성 및 빌드 파이프라인 전체의 무결성을 확보하는 전략입니다.
|
||||
* **[[DevSecOps|DevSecOps]]**: 보안 프랙티스를 문화와 기술 전 영역에 끊김 없이 통합하는 거시적 방법론입니다.
|
||||
* **Software Supply Chain Security**: 소스 코드를 넘어 외부 의존성 및 빌드 파이프라인 전체의 무결성을 확보하는 전략입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
+7
-7
@@ -1,4 +1,4 @@
|
||||
# [[Software Security Standards & Vulnerabilities (소프트웨어 보안 표준 및 취약점)]]
|
||||
# [[Software Security Standards & Vulnerabilities (소프트웨어 보안 표준 및 취약점)|Software Security Standards & Vulnerabilities (소프트웨어 보안 표준 및 취약점]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
소프트웨어 보안 표준 및 취약점은 안전한 애플리케이션 개발을 위해 반드시 준수해야 할 지침과 방어해야 할 알려진 위협들의 모음입니다. CVE(Common Vulnerabilities and Exposures), CWE(Common Weakness Enumeration), CIS Benchmarks 등 글로벌 표준을 활용하여 보안 코드 리뷰의 기준을 수립하고, 인젝션 결함(Injection Flaws)과 같은 치명적인 약점을 사전에 식별하여 조치합니다 [1]. 이는 시프트 레프트(Shift-Left) 보안 전략의 핵심 데이터로 활용되어 공급망 보안과 시스템 무결성을 보장합니다.
|
||||
@@ -22,10 +22,10 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[SCA (Software Composition Analysis)]]**: 외부 라이브러리의 CVE 및 라이선스 위반을 탐지하는 핵심 기술입니다.
|
||||
* **[[SAST (Static Application Security Testing)]]**: 소스 코드 내의 CWE 패턴(인젝션 등)을 정적으로 식별하는 도구입니다.
|
||||
* **[[Policy-as-code]]**: 보안 표준(CVE 차단 등)을 CI/CD 파이프라인에서 자동 강제하는 구현 방식입니다.
|
||||
* **[[OWASP Top 10]]**: 웹 보안 분야에서 가장 널리 통용되는 취약점 우선순위 가이드입니다.
|
||||
* **SCA (Software Composition Analysis**: 외부 라이브러리의 CVE 및 라이선스 위반을 탐지하는 핵심 기술입니다.
|
||||
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 소스 코드 내의 CWE 패턴(인젝션 등)을 정적으로 식별하는 도구입니다.
|
||||
* **Policy-as-code**: 보안 표준(CVE 차단 등)을 CI/CD 파이프라인에서 자동 강제하는 구현 방식입니다.
|
||||
* **[[OWASP Top 10|OWASP Top 10]]**: 웹 보안 분야에서 가장 널리 통용되는 취약점 우선순위 가이드입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* SCA 도구에서 발견된 수많은 CVE 중 '실행 경로(Exploitable Path)' 상에 존재하여 즉각적인 조치가 필요한 위험을 선별하는 효율적인 분석 기법은 무엇인가?
|
||||
@@ -42,8 +42,8 @@
|
||||
* **My Project Relevance:** PR 병합 전 단계에 CVE 스캔을 필수화하고, 심각한 결함 발견 시 자동으로 배포를 차단하는 보안 게이트를 설정합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Software Supply Chain Security]]**: 소스 코드를 넘어 패키지 매니저, 빌드 도구 등 소프트웨어 공급망 전체의 무결성을 확보하는 전략으로 확장됩니다.
|
||||
* **[[Zero Day Vulnerability]]**: 아직 패치가 존재하지 않는 알려지지 않은 취약점에 대한 실시간 탐지 및 대응 전략입니다.
|
||||
* **Software Supply Chain Security**: 소스 코드를 넘어 패키지 매니저, 빌드 도구 등 소프트웨어 공급망 전체의 무결성을 확보하는 전략으로 확장됩니다.
|
||||
* **Zero Day Vulnerability**: 아직 패치가 존재하지 않는 알려지지 않은 취약점에 대한 실시간 탐지 및 대응 전략입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Static Analysis & Linting (정적 분석 및 린팅)]]
|
||||
# [[Static Analysis & Linting (정적 분석 및 린팅)|Static Analysis & Linting (정적 분석 및 린팅]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
정적 분석 및 린팅은 소프트웨어를 실행하지 않고 소스 코드 자체를 알고리즘 기반으로 검사하여 스타일 위반, 문법 오류, 잠재적 버그, 보안 취약점을 자동으로 식별하는 기술입니다 [1]. 린팅(Linting)은 주로 코드 컨벤션과 포맷팅 등 스타일 이슈를 처리하여 리뷰어의 사소한 지적(Nitpicking)을 제거하며, SAST(Static Application Security Testing)는 보안 결함을 조기에 발견하는 시프트 레프트(Shift-Left)의 핵심 도구로 작동합니다 [3, 4]. 이를 통해 인간 리뷰어는 기계적인 검사에서 벗어나 아키텍처 설계와 비즈니스 로직 등 고차원적인 피드백에 집중할 수 있습니다.
|
||||
@@ -13,7 +13,7 @@
|
||||
* **자동화 통합 전략:**
|
||||
* **Pre-commit Hooks:** 개발자가 코드를 커밋하기 직전 로컬에서 선제적으로 린팅과 기본 검사를 실행하여 부적절한 코드가 원격 저장소에 올라가는 것을 방지합니다 [32, 33].
|
||||
* **CI/CD 파이프라인:** 모든 PR 단계에서 자동화된 정적 분석을 수행하여 병합 전 최종 품질을 강제합니다 [7, 8].
|
||||
* **도구 생태계:** JavaScript(ESLint), Python(Pylint, Ruff), Java(Checkstyle, SonarQube) 등 언어별 표준 도구를 활용하고 Google/Airbnb 스타일 가이드를 벤치마킹합니다 [14, 17].
|
||||
* **도구 생태계:** JavaScript(ESLint), Python(Pylint, Ruff), Java(Checkstyle, SonarQube) 등 언어별 표준 도구를 활용하고, 최근에는 AI가 오탐(False Positive)을 걸러주는 'AI-Driven SAST'가 도입되어 분석 정확도를 높이고 있습니다 [14, 17, 23].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **맥락 이해의 한계:** 자동화 도구는 사전에 정의된 패턴은 잘 찾지만, 코드의 비즈니스 목적이나 아키텍처적 의도, 운영 환경의 실제 영향도는 이해하지 못합니다 [19].
|
||||
@@ -23,14 +23,14 @@
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[CI/CD Pipeline]]**: 정적 분석과 린팅이 실시간으로 실행되어 품질 게이트 역할을 수행하는 물리적 환경입니다.
|
||||
* **[[Nitpicking]]**: 린팅 도구가 자동화하여 인간 리뷰어의 피로를 해결해 주는 사소한 스타일 지적 행위입니다.
|
||||
* **[[Shift-Left Security]]**: 보안 스캔을 개발 초기 단계로 앞당겨 리스크를 조기 차단하는 전략적 접근입니다.
|
||||
* **[[Code Formatter]]**: 린트 경고를 넘어 코드를 설정된 스타일에 맞춰 기계적으로 변환(Auto-fix)해 주는 도구입니다.
|
||||
* **[[CI-CD Pipeline|CI/CD Pipeline]]**: 정적 분석과 린팅이 실시간으로 실행되어 품질 게이트 역할을 수행하는 물리적 환경입니다.
|
||||
* **Nitpicking**: 린팅 도구가 자동화하여 인간 리뷰어의 피로를 해결해 주는 사소한 스타일 지적 행위입니다.
|
||||
* **Shift-Left Security**: 보안 스캔을 개발 초기 단계로 앞당겨 리스크를 조기 차단하는 전략적 접근입니다.
|
||||
* **Code Formatter**: 린트 경고를 넘어 코드를 설정된 스타일에 맞춰 기계적으로 변환(Auto-fix)해 주는 도구입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 기존 규칙이 없던 대규모 레거시 프로젝트에 엄격한 린팅과 SAST 규칙을 도입할 때, 팀의 반발을 최소화하며 점진적으로 적용하는 전략은 무엇인가?
|
||||
* 규칙 기반(Rule-based) 린터와 AI 기반(LLM) 코드 분석 도구가 파이프라인 내에서 어떻게 상호 보완적으로 작동할 때 가장 높은 탐지 효율을 내는가?
|
||||
* 규칙 기반(Rule-based) 린터와 AI 기반(LLM) 코드 분석 도구가 파이프라인 내에서 어떻게 상호 보완적으로 작동할 때 가장 높은 탐지 효율을 내는가? 특히 AI-Driven SAST가 오탐률을 획기적으로 줄일 수 있는가?
|
||||
* 정적 분석 도구로 탐지가 불가능한 '도메인 특화 비즈니스 결함'을 잡기 위해 인간 리뷰어가 갖춰야 할 체크리스트는 어떻게 구성해야 하는가?
|
||||
* 커스텀 린트 규칙(Custom Lint Rules)을 활용하여 아키텍처 계층 간의 잘못된 참조(예: Controller에서 Repository 직접 참조)를 자동 차단하는 방법은 무엇인가?
|
||||
* 자동화된 스타일 교정이 PR의 변경 이력(Git Blame 등) 가독성에 미치는 영향을 최소화하기 위한 운영 팁은 무엇인가?
|
||||
@@ -43,8 +43,8 @@
|
||||
* **My Project Relevance:** "린팅 통과 여부"를 PR 머지의 필수 체크포인트로 설정하여 로직 무결성 검증에 집중할 수 있는 문화를 정착시킵니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Code Smells]]**: 정적 분석 도구가 감지하고자 하는 '장기적 유지보수를 저해하는 나쁜 코드 징후' 패턴들을 탐구합니다.
|
||||
* **[[Dynamic Application Security Testing (DAST)]]**: 실행 중인 환경에서 취약점을 찾는 기법으로, 정적 분석과 상호 보완적입니다.
|
||||
* **Code Smells**: 정적 분석 도구가 감지하고자 하는 '장기적 유지보수를 저해하는 나쁜 코드 징후' 패턴들을 탐구합니다.
|
||||
* **Dynamic Application Security Testing (DAST**: 실행 중인 환경에서 취약점을 찾는 기법으로, 정적 분석과 상호 보완적입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,21 +1,21 @@
|
||||
---
|
||||
title: 스타일 거버넌스 및 디자인 시스템
|
||||
category: Software [[Architecture]]
|
||||
tags: [Styling, Tailwind, [[CSS-in-JS]], Design[[ system]], Responsive]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Styling, Tailwind, [[CSS-in-JS|CSS-in-JS]], DesignSystem, Responsive]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Styling_Governance]] (스타일 매니지먼트)
|
||||
# [[Styling_Governance|Styling_Governance]] (스타일 매니지먼트)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 디자인은 '예쁜 픽셀'이 아니라 '일관된 약속'이다. 단 하나의 변수가 바뀌었을 때 전체 앱의 조화가 유지되는 구조가 진짜 디자인 시스템이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **[[Design Tokens]] (디자인 토큰)**:
|
||||
- **[[Design Tokens|Design Tokens]] (디자인 토큰)**:
|
||||
- 색상(#FF0000 -> `brand-primary`), 여백(16px -> `spacing-md`)을 추상화된 이름으로 정의하라. 그래야 브랜드 리뉴얼 시 코드 한 줄로 대응 가능하다.
|
||||
- **Utility-First vs Runtime Style**:
|
||||
- **[[Tailwind CSS]]**: 클래스명으로 스타일을 정의하여 런타임 오버헤드가 없고 개발 속도가 압도적이다.
|
||||
- **[[styled-components]]**: 컴포넌트 중심의 의미론적 스타일링과 동적 Props 처리에 강점이 있다.
|
||||
- **[[Tailwind CSS|Tailwind CSS]]**: 클래스명으로 스타일을 정의하여 런타임 오버헤드가 없고 개발 속도가 압도적이다.
|
||||
- **[[styled-components|styled-components]]**: 컴포넌트 중심의 의미론적 스타일링과 동적 Props 처리에 강점이 있다.
|
||||
- **Mobile First Responsive**:
|
||||
- 작은 화면부터 디자인을 시작하여 넓은 화면으로 확장하라. 이것이 CSS 코드를 30% 이상 줄이는 지름길이다.
|
||||
|
||||
@@ -23,5 +23,5 @@ created: 2026-04-20
|
||||
- 과도한 '공통 컴포넌트'화는 오히려 독이 될 수 있다. 버튼 하나에 옵션이 20개가 달리는 순간, 그 버튼은 유지보수의 재앙이 된다. 적절한 '복제'와 '분리'의 균형을 유지하라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Component_Design_Patterns]] , [[Accessibility_Inclusivity]]
|
||||
- Best Practice: [[React_Clean_Code_Best_Practices]]
|
||||
- Related: [[Component_Design_Patterns|Component_Design_Patterns]] , [[Accessibility_Inclusivity|Accessibility_Inclusivity]]
|
||||
- Best Practice: [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]]
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 단계별 시스템 디버깅 체크리스트 (L1~L3)
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Debugging, Troubleshooting, Checklist, Process]
|
||||
created: 2026-04-20
|
||||
---
|
||||
@@ -23,5 +23,5 @@ created: 2026-04-20
|
||||
- **필수 조치**: 최소 실행 예제(MRE)를 통한 격리 테스트.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Tetris_Project_Retrospective]]
|
||||
- [[DevOps_Environment_Setup]]
|
||||
- [[Tetris_Project_Retrospective|Tetris_Project_Retrospective]]
|
||||
- [[DevOps_Environment_Setup|DevOps_Environment_Setup]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 표준 시스템 통신 프로토콜 및 상태 제어
|
||||
category: Software [[Architecture]]
|
||||
tags: [Protocol, [[State]] Machine, Data Exchange, Lifecycle]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Protocol, [[State|State]] Machine, Data Exchange, Lifecycle]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -16,11 +16,11 @@ created: 2026-04-20
|
||||
- `UPDATE`: 엔진 계산 결과의 브로드캐스트.
|
||||
|
||||
## 🔄 시스템 생명 주기 (Life Cycle)
|
||||
시스템은 [초기화 $\rightarrow$ 활성 루프 $\rightarrow$ 종료/정리]의 명확한 단계를 거쳐야 리소스 누수([[memory]] Leak)를 방지할 수 있습니다.
|
||||
시스템은 [초기화 $\rightarrow$ 활성 루프 $\rightarrow$ 종료/정리]의 명확한 단계를 거쳐야 리소스 누수([[memory|memory]] Leak)를 방지할 수 있습니다.
|
||||
|
||||
## 🚨 상태 머신 (State Machine) 도입
|
||||
시스템 복잡도가 임계치를 넘을 경우, `READY`, `RUNNING`, `PAUSED` 등 상태를 명시적으로 제어하는 **State Machine** 적용을 원칙으로 삼습니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- Project_Architecture_Guidelines
|
||||
- [[Single_Source_of_Truth]]
|
||||
- [[Single_Source_of_Truth|Single_Source_of_Truth]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [development, testing-strategy, testability, tdd, automated-testing, quali
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Testing Strategy]]
|
||||
# [[Testing Strategy|Testing Strategy]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드의 의도를 명세화(Documentation)하고, 변경에 대한 즉각적인 회귀(Regression) 방지망을 구축하여 지속적인 배포와 리팩토링을 가능하게 하는 품질의 초석."
|
||||
@@ -17,7 +17,7 @@ last_reinforced: 2026-05-01
|
||||
1. **테스트 가능성 (Testability)**:
|
||||
* **설계적 접근**: 코드가 쉽게 테스트될 수 있도록 의존성을 주입(DI)받고, 인터페이스를 통해 외부 모듈을 격리(Mocking)합니다. 정적 메서드나 싱글톤의 남용은 테스트 가능성을 저해합니다.
|
||||
* **결정론적 테스트**: 테스트는 환경이나 실행 순서에 영향을 받지 않고 항상 동일한 결과를 내야 합니다.
|
||||
2. **[[Test-Driven Development (TDD)]]**:
|
||||
2. **Test-Driven Development (TDD**:
|
||||
* 실패하는 테스트를 먼저 작성(Red) -> 기능을 구현(Green) -> 코드를 개선(Refactor)하는 사이클을 통해 테스트가 코드의 설계를 주도하게 만듭니다.
|
||||
3. **리뷰 단계에서의 테스트**:
|
||||
* **테스트 코드 우선 리뷰**: 테스트를 먼저 읽으면 해당 기능의 유즈케이스와 의도를 더 명확히 파악할 수 있습니다.
|
||||
@@ -30,9 +30,9 @@ last_reinforced: 2026-05-01
|
||||
- **유지보수 비용**: 테스트 코드 역시 관리 대상인 부채입니다. 과도하게 복잡한 테스트 로직이나 불필요한 구현 세부 사항에 결합된 테스트는 리팩토링을 방해할 수 있으므로, 테스트 자체의 품질과 단순성도 유지해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Automated Quality & Review]]: 테스트가 자동으로 실행되는 환경.
|
||||
- [[Dependency Injection (DI)]]: 테스트 가능성을 높이는 핵심 기술.
|
||||
- [[CI-CD Pipeline]]: 테스트 결과에 따라 병합 여부를 결정하는 시스템.
|
||||
- [[Refactoring]]: 테스트라는 안전망이 있을 때 비로소 가능해지는 활동.
|
||||
- [[Mocking and Test Doubles]]: 외부 의존성 격리 기법.
|
||||
- [[Automated Quality & Review|Automated Quality & Review]]: 테스트가 자동으로 실행되는 환경.
|
||||
- [[Dependency Injection (DI)|Dependency Injection (DI]]: 테스트 가능성을 높이는 핵심 기술.
|
||||
- [[CI-CD Pipeline|CI-CD Pipeline]]: 테스트 결과에 따라 병합 여부를 결정하는 시스템.
|
||||
- [[Refactoring|Refactoring]]: 테스트라는 안전망이 있을 때 비로소 가능해지는 활동.
|
||||
- Mocking and Test Doubles: 외부 의존성 격리 기법.
|
||||
---
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# Index: Topics > 10_Wiki
|
||||
|
||||
## 📁 Subcategories
|
||||
- [[💡 Topics/Index|💡 Topics]]
|
||||
- 💡 Topics
|
||||
|
||||
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
category: AI & Games
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 10v10 대규모 멀티플레이어
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
10v10 대규모 멀티플레이어는 [[WARNO]]에서 최대 20명의 플레이어가 동시에 참여하여 거대한 스펙터클과 혼란을 만들어내는 대규모 전술 게임 모드입니다 [1]. 이 모드에서는 유닛과 플레이어의 밀도가 매우 높아 강력한 포격과 촘촘한 방공망이 형성되며, 플레이어는 전장 전체가 아닌 특정 구역에 집중하여 전투를 수행할 수 있습니다 [1]. WARNO의 기반인 Iriszoom 엔진은 수백 개의 유닛이 기동하고 파괴되는 이러한 극단적인 환경 속에서도 4K 해상도와 풀 옵션을 안정적으로 유지할 수 있는 고도의 데이터 최적화 성능을 자랑합니다 [2, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **엔진 최적화 및 시각 데이터 처리:** 10v10 멀티플레이어 매치는 시스템에 엄청난 부하를 주지만, Iriszoom 엔진은 이를 원활하게 처리하도록 설계되었습니다 [2]. 수백 개의 개별 유닛이 동시에 전장에서 충돌하고 파괴되는 10 대 10 환경에서도 게임은 4K 해상도와 풀 옵션 설정에서 안정적인 성능을 보여줍니다 [3]. 또한 네이팜, 연막, 폭발 등의 시각적 효과 데이터가 10v10 모드에서도 효과가 종료되기 전에 사라지지 않고 명확하게 렌더링되도록 최적화되었습니다 [4].
|
||||
* **전술적 환경의 변화:** 플레이어 밀도가 높은 10v10 게임에서는 맵의 좁은 부분에 역량을 집중할 수 있어, 치열한 협력과 혼전이 발생합니다 [1]. 대공 방어망이 빽촘하게 배치되어 항공기 운용이 매우 까다로워지며, 집중된 대규모 포격 데이터로 인해 노출된 고정 위치에서 보병을 생존시키는 것이 훨씬 더 어렵습니다 [1]. 일부 플레이어들은 10v10 모드에서 가장 유효한 전략을 '전면 돌격(full frontal assault)'으로 체감하기도 하며, NATO 진영은 무거운 기갑 사단을 스팸(spam)할 때 특히 강한 모습을 보입니다 [5, 6].
|
||||
* **사단(Division) 단위 데이터 밸런싱:** 소규모 전투에서는 방어나 기동의 약점 때문에 다루기 까다로운 예비군 사단(예: K.d.A. Bezirk Erfurt)이나 특정 보병 사단들도 10v10과 같은 대규모 팀 게임에서는 훨씬 플레이하기 쉬워집니다 [7]. 팀원들이 부족한 보병이나 전차 전력을 채워주고, 본인은 포병과 대공망을 극대화하여 팀을 지원하는 방식의 상호 보완적 덱 빌딩이 가능해지기 때문입니다 [7, 8].
|
||||
* **통계적 밸런스와 숙련도 데이터:** 많은 플레이어가 특정 진영(NATO 또는 PACT)이 10v10에서 불균형적으로 강하다고 인식하지만, 실제 10v10 퍼블릭 로비의 플레이어 승률과 텔레메트리 데이터를 분석해 보면 진영 간 눈에 띄는 편향은 발견되지 않습니다 [9]. 10v10 대규모 멀티플레이어 데이터 분석 결과, NATO와 PACT 간의 플레이 비중 및 승률은 플레이어의 숙련도가 높아질수록 균형을 이루는 경향을 보입니다 [10].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Iriszoom 엔진]], [[사단(Division) 시스템]], [[텔레메트리(Telemetry) 데이터 분석]]
|
||||
- **Projects/Contexts:** [[WARNO 데이터 기반 밸런싱]]
|
||||
- **Contradictions/Notes:** 소스 [5]을 비롯해 10v10 커뮤니티 내에서는 게임 경험상 특정 진영(예: NATO)이 더 강하거나 유리하게 느껴진다는 체감상 주장들이 종종 제기되지만, 소스 [11], [9], [10]에서 진행된 실제 10v10 플레이어 데이터 및 승률 통계 분석에 따르면 두 진영 간의 통계적으로 유의미한 불균형이나 편향은 존재하지 않으며, 승패는 주로 플레이어 본인과 팀원들의 숙련도 차이에 기인하는 것으로 나타납니다 [12].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,11 +1,11 @@
|
||||
# [[2026년 인공지능 시각 언어 생성 패러다임 전환 및 연속적 창작 워크플로우]]
|
||||
# [[2026년 인공지능 시각 언어 생성 패러다임 전환 및 연속적 창작 워크플로우|2026년 인공지능 시각 언어 생성 패러다임 전환 및 연속적 창작 워크플로우]]
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
2026년의 인공지능 시각 언어 생성 기술은 단발성 이미지 추출에서 벗어나, 인간과 AI 에이전트가 긴밀하게 협업하는 '연속적 창작 워크플로우'의 패러다임으로 진화하였다 [1, 2]. 미드저니 V7의 드래프트 모드(Draft Mode)나 옴니 참조([[Omni Reference]])와 같은 기술의 도입으로 아이디어의 고속 대량 생산, 시각적 정체성의 일관성 유지, 정교한 사후 편집이 맞물린 체계적 작업이 가능해졌다 [3-5]. 이에 따라 이미지 프롬프트 작성법 역시 단순한 단어의 나열을 넘어, 카메라 물리 법칙이나 조명 과학 등의 시각적 전문 지식을 반영하고 각 AI 모델의 고유한 통제 언어를 다루는 고도화된 프롬프트 엔지니어링으로 격상되었다 [2, 6].
|
||||
## 📌 Brief Summary
|
||||
2026년의 인공지능 시각 언어 생성 기술은 단발성 이미지 추출에서 벗어나, 인간과 AI 에이전트가 긴밀하게 협업하는 '연속적 창작 워크플로우'의 패러다임으로 진화하였다 [1, 2]. 미드저니 V7의 드래프트 모드(Draft Mode)나 옴니 참조([[Omni Reference|Omni Reference]])와 같은 기술의 도입으로 아이디어의 고속 대량 생산, 시각적 정체성의 일관성 유지, 정교한 사후 편집이 맞물린 체계적 작업이 가능해졌다 [3-5]. 이에 따라 이미지 프롬프트 작성법 역시 단순한 단어의 나열을 넘어, 카메라 물리 법칙이나 조명 과학 등의 시각적 전문 지식을 반영하고 각 AI 모델의 고유한 통제 언어를 다루는 고도화된 프롬프트 엔지니어링으로 격상되었다 [2, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
* **프롬프트 엔지니어링의 구조화 및 전문화**
|
||||
성공적인 시각 언어 생성 프롬프트는 인공지능의 신경망 구조에 부합하도록 주체(Subject), 매체(Medium), 환경(Environment), 조명(Lighting), 기술적 매개변수([[Parameter]]s) 등 5가지 핵심 층위로 구성된다 [7, 8]. 특히 2026년에는 '85mm 렌즈', '얕은 피사계 심도' 같은 렌즈 물리학이나, '볼륨메트릭 라이팅(Volumetric Lighting)', '치아로스쿠로(Chiaroscuro)' 같은 조명 과학 기반의 정밀 키워드가 이미지의 깊이와 서사를 결정짓는 핵심 수단으로 활용된다 [6, 9].
|
||||
성공적인 시각 언어 생성 프롬프트는 인공지능의 신경망 구조에 부합하도록 주체(Subject), 매체(Medium), 환경(Environment), 조명(Lighting), 기술적 매개변수([[Parameter|Parameter]]s) 등 5가지 핵심 층위로 구성된다 [7, 8]. 특히 2026년에는 '85mm 렌즈', '얕은 피사계 심도' 같은 렌즈 물리학이나, '볼륨메트릭 라이팅(Volumetric Lighting)', '치아로스쿠로(Chiaroscuro)' 같은 조명 과학 기반의 정밀 키워드가 이미지의 깊이와 서사를 결정짓는 핵심 수단으로 활용된다 [6, 9].
|
||||
|
||||
* **연속적 창작 워크플로우와 드래프트 모드(Draft Mode)의 정착**
|
||||
이미지 생성의 개념은 한 번에 완벽한 결과물을 얻는 것에서, 여러 시안을 탐색하고 정교화하는 반복적인 디자인 리뷰 루프(Design Review Loop)로 변화했다 [3, 10]. 미드저니 V7에 도입된 드래프트 모드는 기존 대비 약 10배 빠른 속도와 절반의 GPU 비용으로 아이디어를 시각화하며, 사용자가 유망한 구도를 선택해 고품질로 승격시키는 프로세스를 가능하게 했다 [1, 3, 4]. 또한, 생성 이후에도 인페인팅(Vary Region)이나 줌 아웃(Zoom Out)을 활용해 기존 맥락을 유지하면서 이미지를 부분 수정하거나 공간을 논리적으로 확장하는 사후 편집이 필수적인 단계로 자리 잡았다 [11-13].
|
||||
@@ -13,16 +13,16 @@
|
||||
* **모델별 맞춤형 프롬프트 제어와 참조 기능**
|
||||
각 AI 플랫폼의 특성 및 구조적 '방언'에 맞춘 프롬프트 접근이 요구된다 [14].
|
||||
* **미드저니(Midjourney):** 미학적 결과물 도출에 특화되어 있으며, 2026년 V7 모델의 핵심인 `--sref`(스타일 참조)와 `--oref`(옴니 참조) 매개변수를 통해 특정 캐릭터나 사물의 형태, 브랜드의 미학적 정체성을 여러 프롬프트에 걸쳐 일관되게 재현할 수 있다 [4, 5, 15, 16].
|
||||
* **스테이블 디퓨전(Stable Diffusion):** `(keyword:factor)` 형식의 가중치 부여 문법과 통제된 부정 프롬프트(Negative [[prompt]])를 통해, 해부학적 왜곡이나 불필요한 시각적 노이즈를 픽셀 단위로 차단하는 정밀한 제어가 가능하다 [17-19].
|
||||
* **스테이블 디퓨전(Stable Diffusion):** `(keyword:factor)` 형식의 가중치 부여 문법과 통제된 부정 프롬프트(Negative prompt)를 통해, 해부학적 왜곡이나 불필요한 시각적 노이즈를 픽셀 단위로 차단하는 정밀한 제어가 가능하다 [17-19].
|
||||
* **DALL-E 3:** 대화형 GPT-4의 상호작용을 통해 복잡한 다중 객체의 배치나 오타 없는 정확한 텍스트 렌더링에서 우수한 성능을 보여주며, 자연어에 강하게 의존한다 [20, 21].
|
||||
|
||||
* **에이전틱 크리에이티브(Agentic Creative) 패러다임의 도래**
|
||||
AI가 인간의 능력을 보조하는 것을 넘어 주도적으로 협력하는 2026년 '에이전틱 AI(Agentic AI)' 트렌드와 결합하여, 창작 환경에도 거대한 변화가 일어났다 [2, 22, 23]. 인간 창작자가 추상적인 비전을 제시하면, AI 에이전트가 이를 모델별 최적의 기술적 언어로 번역하고 대량의 시안을 자율적으로 생성하는 '에이전틱 크리에이티브' 시대가 열리며 소프트웨어적 상호작용 방식이 근본적으로 재정의되고 있다 [2, 24].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** `[[프롬프트 계층 구조(Prompt Hierarchical Structure)]]`, `[[매개변수 제어([[Parameter Control]])]]`, `[[부정 프롬프트(Negative Prompt)]]`, `[[에이전틱 AI(Agentic AI)]]`
|
||||
- **Projects/Contexts:** `[[미드저니 V7 드래프트 모드([[Midjourney V7 Draft Mode]])]]`, `[[옴니 참조(Omni [[Reference]], --oref)]]`, `[[에이전틱 크리에이티브(Agentic Creative)]]`
|
||||
- **Related Topics:** `프롬프트 계층 구조(Prompt Hierarchical Structure`, `매개변수 제어(Parameter Control)`, `[[부정 프롬프트 (Negative Prompt)|부정 프롬프트(Negative Prompt]]`, `[[에이전틱 AI (Agentic AI)|에이전틱 AI(Agentic AI]]`
|
||||
- **Projects/Contexts:** `미드저니 V7 드래프트 모드(Midjourney V7 Draft Mode`, `옴니 참조(Omni Reference, --oref)`, `에이전틱 크리에이티브(Agentic Creative`
|
||||
- **Contradictions/Notes:** 모델 아키텍처에 따라 '부정 지시어'를 처리하는 메커니즘에 뚜렷한 모순과 차이가 존재한다. 스테이블 디퓨전은 이미지의 해부학적 오류(예: extra fingers)나 저화질 요소를 제거하기 위해 명시적인 부정 프롬프트 작성이 필수적이지만 [17, 19, 25], DALL-E 3 모델은 "사용하지 말 것(no, without)"과 같은 부정 지시어를 오히려 해당 피사체를 그려내라는 의미로 오인하는 한계가 있어 모든 프롬프트를 긍정형으로 작성해야 한다 [21, 26]. 또한 미드저니 V7 모델은 시각적이고 미학적인 아이디어 탐색 워크플로우에는 최적화되어 있으나, 정확한 타이포그래피나 엄격한 레이아웃을 그대로 복제해야 하는 작업에는 적합하지 않다는 제한점이 관찰된다 [27, 28].
|
||||
|
||||
---
|
||||
*Last updated: [[2026-04-30]]*
|
||||
*Last updated: [[2026-04-30|2026-04-30]]*
|
||||
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-EB3F3C
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 20k skinned instances demo"
|
||||
---
|
||||
|
||||
# [[20k skinned instances demo]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> '20k skinned instances demo'는 Three.js 기반의 오픈 소스 라이브러리인 [[InstancedMesh2]]를 활용하여 20,000개의 개별적인 스킨드 인스턴스(Skinned instances)를 동시에 렌더링하는 성능 최적화 데모입니다 [1, 2]. 이 데모는 모바일 기기에서도 3,000개의 인스턴스를 원활하게 구동할 수 있도록 설계되었습니다 [2]. 프러스텀 컬링, 거리 기반 애니메이션 프레임 조절, 다중 LOD(Level of Detail) 생성 등 다양한 최적화 기법을 적용하여 단 5번의 드로우 콜만으로 렌더링을 처리하는 것이 특징입니다 [2, 3].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
이 데모는 제작자(agargaro)가 개발한 `[[InstancedMesh]]2` 라이브러리를 기반으로 하며, 대규모 스킨드 메쉬를 렌더링하기 위해 다음과 같은 세부 최적화 기술들을 사용했습니다 [2].
|
||||
|
||||
* **프러스텀 컬링 및 시야 기반 업데이트 ([[Frustum Culling]] & View-based Updates):**
|
||||
기본적인 프러스텀 컬링을 적용하여 카메라 시야(Frustum) 내에 존재하는 인스턴스들에 대해서만 뼈대(Bones) 연산을 업데이트합니다 [2].
|
||||
* **동적 애니메이션 프레임 제어:**
|
||||
카메라와 각 인스턴스 간의 거리를 계산하여 애니메이션 FPS를 0에서 60 사이로 개별 설정함으로써 불필요한 연산을 줄입니다 [2].
|
||||
* **LOD(Level of Detail)의 적극적 활용:**
|
||||
`meshoptimizer`를 활용해 5단계의 기하학적 LOD를 생성했습니다 [2]. 거리가 먼 인스턴스에 대해서는 일부 뼈대 계산을 생략하며, 각 LOD마다 1개의 드로우 콜([[Draw Call]])만 발생시켜 총 5개의 드로우 콜만으로 렌더링을 완료합니다 [2, 3]. 또한, 그림자(Shadows) 렌더링 시에도 LOD를 관리할 수 있도록 구성되어 있습니다 [4].
|
||||
* **개별 애니메이션 지원:**
|
||||
단일 인스턴스들의 복제본들이 모두 동일한 애니메이션과 포즈를 공유하는 것이 아니라, 각 인스턴스마다 서로 다른 애니메이션을 가집니다 [5, 6]. 이 데모에서는 하나의 애니메이션 믹서(Mixer)를 사용했지만, 필요에 따라 인스턴스별로 믹서를 생성할 수도 있습니다 [6].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[InstancedMesh2]], [[Frustum Culling]], [[Level of Detail (LOD)]], Skinned Mesh, [[Draw Call]]
|
||||
- **Projects/Contexts:** three.js
|
||||
- **Contradictions/Notes:** 본 텍스처(Bone texture)의 부분 업데이트(Partial texture updates) 기능은 PC 환경에서 60FPS를 달성하는 데 도움이 될 수 있는 최적화 기법이지만, 모바일 기기와 파이어폭스(Mozilla Firefox) 브라우저에서는 이중 버퍼링(Double buffering) 부재로 인해 오히려 속도가 느려지는 문제가 있어 본 데모에서는 비활성화된 상태로 제공되었습니다 [2, 7].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: UX-DATA-TEST-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [ux, ab-[[Testing]], data-driven-design, cro, micro-conversions, product-growth]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# A/B Testing and Data-Driven UX (A/B 테스트 및 데이터 기반 UX)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "디자인의 주관적 미학을 통계적 객관성으로 치환하고, 사용자의 실제 행동 데이터를 나침반 삼아 비즈니스 전환율의 임계점을 돌파하라" — 가설을 검증하고 사용자 경험의 마찰을 수치로 정밀 타격하는 현대 프로덕트 성장의 핵심 엔진.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Empirical Validation and Iterative [[Optimization]]" — 직관이나 가정에 의존하는 대신, 트래픽을 대조군(Control)과 실험군(Test)으로 분리하여 특정 UI 변경이 미치는 인과관계를 데이터로 증명하는 패턴.
|
||||
- **핵심 방법론 및 도구:**
|
||||
- **A/B & Multivariate Testing:** 단일 또는 다중 변수의 변경이 최종 전환율에 미치는 영향을 분리 및 검증.
|
||||
- **Micro-conversions:** 최종 목표(구매 등) 이전의 행동(스크롤, 클릭, 시청)을 추적하여 사용자 의도 파악.
|
||||
- **[[Behavior]]al [[Analysis]]:** 히트맵(Heatmaps)과 세션 녹화(Session Recording)를 통해 정량적 지표 뒤에 숨겨진 정성적 마찰 지점 식별.
|
||||
- **Progressive Rollouts:** 리스크 최소화를 위해 신규 디자인을 특정 세그먼트에게만 점진적으로 노출.
|
||||
- **의의:** 디자인 결정의 불확실성을 제거하고, 지속적인 실험 루프를 통해 제품의 비즈니스 가치를 과학적으로 극대화함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거에는 디자인을 '완성된 작품'으로 보았으나, 현재 정책은 제품을 '지속적 실험의 대상'으로 간주함. 특히 상관관계(Correlation)와 인과관계(Causation)를 혼동하지 않기 위한 엄격한 통계적 유의성 검증 정책이 강화됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 주요 UI 변경 시 최소 10%의 트래픽에 대해 A/B 테스트를 선행하며, 데이터 기반의 근거 없이는 레이아웃 변경을 승인하지 않는 'Evidence-based Design' 정책을 고수함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- User-Centered-Design, Conversion-Rate-Optimization-CRO, [[Hypothesis-Testing]], Product-[[Management]]-Best-Practices
|
||||
- **Raw Source:** 00_Raw/A-B 테스트 및 데이터 기반 UX 검증 환경.md
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: ABA-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [[[Psychology]], [[Behavior]]al-science, [[Reinforcement-Learning]], aba, pedagogy]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# ABA (Applied Behavior [[Analysis]], 응용 행동 분석)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "행동의 원인을 분석하고, 보상 설계를 통해 바람직한 변화를 이끌어내라" — 행동주의 심리학에 근거하여 인간의 행동을 객관적으로 측정하고, 환경 조절과 강화를 통해 사회적으로 유의미한 행동 변화를 유도하는 과학적 방법론.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** ABC(Antecedent-Behavior-Consequence) 패러다임을 통해 행동 전후의 맥락을 분석하고, 보상(Reinforcement) 체계를 설계하여 특정 행동의 발생 빈도를 조절하는 기능적 분석 패턴.
|
||||
- **핵심 요소:**
|
||||
- **ABC Analysis:** 선행 사건(A), 행동(B), 결과(C)의 연쇄 고리 파악.
|
||||
- **Positive Reinforcement:** 바람직한 행동 뒤에 보상을 주어 행동의 재발 확률을 높임.
|
||||
- **[[prompt]]ing & Fading:** 초기에는 보조(Prompt)를 통해 행동을 유도하고, 점차 보조를 줄여 독립적 수행을 도움.
|
||||
- **Generalization:** 학습된 행동이 치료실 밖의 실제 환경에서도 유지되도록 유도.
|
||||
- **의의:** 자폐 스펙트럼 장애 치료뿐만 아니라 조직 관리, 교육, 그리고 인공지능 에이전트의 보상 함수 설계에 광범위하게 응용됨.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순히 행동을 교정하는 '훈련'으로 치부되기도 했으나, 현대에는 개인의 삶의 질 향상을 목표로 하는 인본주의적 가치가 결합된 과학적 분석법으로 정착.
|
||||
- **정책 변화:** Antigravity 에이전트의 강화학습 보상 모델 설계 시, ABA의 '기능적 행동 평가' 원칙을 도입하여 에이전트가 왜 특정 오류 행동을 반복하는지 분석하고 교정함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Psychology-of-Learning]], [[Reinforcement-Learning]], [[Alignment]], [[Habit-Formation]]
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/ABA.md
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: SYS-COMP-ACC-GLOBAL-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [[[Accessibility]], compliance, ada, eaa, wcag-2-2, pour-[[Principles]], digital-inclusive, legal-risk]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# ADA and EAA Accessibility Compliance (글로벌 디지털 접근성 규정 준수)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "디지털 장벽을 허물어 모든 인간의 평등한 정보 접근권을 보장하고, ADA(미국)와 EAA(유럽)라는 강력한 법적 표준을 통해 글로벌 비즈니스의 윤리적/법적 정당성을 확보하라" — WCAG 2.2를 기반으로 한 웹 및 모바일 접근성의 글로벌 통합 가이드라인.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Harmonized Global Standards and Proactive Inclusivity" — 미국(ADA)의 WCAG 2.1 AA 권고와 유럽(EAA 2025)의 EN 301 549 표준을 통합하여, 코드 레벨에서부터 보편적 설계(Universal Design)를 관철시키는 패턴.
|
||||
- **글로벌 규제 현황:**
|
||||
- **ADA (Americans with Disabilities Act):** 미국 내 모든 디지털 콘텐츠의 접근성 의무화. 최근 소송 건수 급증 추세.
|
||||
- **EAA (European Accessibility Act):** 2025년 6월 발효. 유럽 내 전자상거래, 뱅킹 등 주요 서비스의 접근성 준수 강제.
|
||||
- **WCAG 2.2 핵심 업데이트 (2023):**
|
||||
- **Focus Not Obscured:** 레이어 등에 의해 포커스 표시가 가려지지 않아야 함.
|
||||
- **Dragging Movements:** 복잡한 드래그 동작에 대한 단일 클릭 대안 제공 필수.
|
||||
- **Accessible Authentication:** 기억력에 의존하지 않는 로그인 방식(생체 인식 등) 권장.
|
||||
- **의의:** 장애인뿐만 아니라 고령자, 일시적 부상자, 저속 인터넷 사용자 등 모든 잠재 고객의 이탈을 방지하고 브랜드 가치를 고양함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거에는 '접근성 위젯(Overlay)'이 법적 방패가 될 것으로 보았으나, 2025년 기준 소송의 22% 이상이 위젯 설치 사이트를 대상으로 함. 따라서 '코드 레벨의 직접 수정'만이 유일한 안전 정책임.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 UI 컴포넌트에 대해 WCAG 2.2 AA 수동 테스트와 스크린 리더 검증을 의무화하며, 유럽 시장 진출을 위해 EAA 표준을 기본 아키텍처에 반영함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Web-Accessibility, POUR-Principles, Inclusive-Design, User-Centered-Design-Approach
|
||||
- **Raw Source:** 00_Raw/ADA Website Compliance.md, 00_Raw/Accessibility Compliance (ADA-EAA).md, 00_Raw/Accessibility Compliance (WCAG).md
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: AGI-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, agi, future-of-ai, singularity, cognitive-science]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# AGI (Artificial General Intelligence, 일반 인공지능)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "인간이 할 수 있는 모든 지적 태스크를 인간 수준 혹은 그 이상으로 수행하는 범용 지능" — 특정 분야에 국한되지 않고 새로운 환경에서 스스로 학습하고, 추론하며, 창의적인 문제를 해결할 수 있는 인공지능의 궁극적 도달점.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 지식의 파편화된 활용을 넘어, 자의식과 메타인지를 바탕으로 도메인을 넘나드는 범용적 문제 해결(General [[Problem Solving]])을 수행하는 완전한 지능 패턴.
|
||||
- **핵심 특징:**
|
||||
- **Cross-domain Learning:** 수학 문제를 풀던 지능이 소설을 쓰거나 코딩을 하는 등 다양한 분야로 즉각 전이됨.
|
||||
- **Common Sense:** 방대한 경험을 바탕으로 세상의 당연한 이치(상식)를 이해하고 활용.
|
||||
- **[[Self-Correction]]:** 자신의 오류를 인지하고 외부의 도움 없이도 지식 체계를 수정 및 업데이트.
|
||||
- **Abstract [[Reasoning]]:** 구체적인 사례 없이도 원리와 개념만으로 복잡한 논리를 전개.
|
||||
- **예상 시점:** 연구자마다 견해가 다르나, LLM의 등장으로 AGI로 가는 길이 가속화되었다는 평이 지배적.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순히 계산 속도가 빠른 컴퓨터에서, 인간의 인지 구조를 완벽히 모사하거나 능가하는 '디지털 생명체'에 가까운 개념으로 확장.
|
||||
- **정책 변화:** Antigravity 프로젝트의 최종 비전은 개별 도구로서의 AI를 넘어, 사용자의 모든 업무와 지식 관리를 통합적으로 보조하는 'Personal AGI'급 에이전트 환경 구축에 있음.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[LLM]], Theory-of-Mind-ToM-in-AI, [[AI-Alignment]], Symbolic-AI-vs-Connectionism
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/AGI.md
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-AIDS-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.93
|
||||
tags: [auto-reinforced, data-sovereignty, ai-ethics, privacy, digital-colonialism, data-governance]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# [[AI & Data Sovereignty]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터의 주인은 누구인가: 우리의 모든 행동이 AI 학습의 공짜 재료가 되는 시대, 개인과 국가가 자신의 데이터를 통제하고 그로부터 창출된 부를 정당하게 나눠 가질 권리를 지키기 위한 투쟁."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
AI 및 데이터 주권(AI & Data Sovereignty)은 디지털 정보와 그로부터 파생된 AI 모델에 대해 개개인, 조직, 혹은 국가가 가지는 배타적인 통제권과 자기 결정권을 의미합니다.
|
||||
|
||||
1. **핵심 층위**:
|
||||
* **Individual Sovereignty**: 내 데이터가 어디에 쓰이는지 알고 거부하거나 보상받을 권리 (Privacy rights).
|
||||
* **National Sovereignty**: 자국민의 데이터가 해외 거대 테크 기업(Big Tech)의 AI 학습에 종속되지 않도록 인프라와 규제를 갖추는 것.
|
||||
* **Model Sovereignty**: 특정 국가나 기업의 AI 모델에 의존하지 않고 독자적인 연산력과 모델 아키텍처를 보유하는 능력.
|
||||
2. **부각되는 배경**:
|
||||
* 거대 모델 학습을 위한 무분별한 데이터 수집이 '디지털 식민주의'를 초래할 수 있다는 우려 확산.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 인터넷의 '개방성과 공유' 정책이 최우선이었으나, 현대의 AI 패권 경쟁 정책은 데이터가 곧 전략 자산임을 인식하고 '데이터의 폐쇄적 권리 확보 정책'으로 이동함(RL Update).
|
||||
- **정책 변화(RL Update)**: EU의 GDPR 및 AI Act와 같이, 개인 데이터를 학습에 쓰려면 명시적인 '옵트-인(Opt-in)'을 거치게 하고 위반 시 막대한 과징금을 부과하는 정책이 데이터 주권 보호의 표준이 됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Ethics & AI]], [[AI Accountability]], [[Sociology of Knowledge]], [[Universal Basic Income (UBI)]], Foundational Models
|
||||
- **Modern Tech/Tools**: Federated Learning (Privacy-preserving AI), Differential Privacy, Sovereign Clouds.
|
||||
---
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# 10v10 대규모 멀티플레이어
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
10v10 대규모 멀티플레이어는 [[WARNO]]에서 최대 20명의 플레이어가 동시에 참여하여 거대한 스펙터클과 혼란을 만들어내는 대규모 전술 게임 모드입니다 [1]. 이 모드에서는 유닛과 플레이어의 밀도가 매우 높아 강력한 포격과 촘촘한 방공망이 형성되며, 플레이어는 전장 전체가 아닌 특정 구역에 집중하여 전투를 수행할 수 있습니다 [1]. WARNO의 기반인 Iriszoom 엔진은 수백 개의 유닛이 기동하고 파괴되는 이러한 극단적인 환경 속에서도 4K 해상도와 풀 옵션을 안정적으로 유지할 수 있는 고도의 데이터 최적화 성능을 자랑합니다 [2, 3].
|
||||
## 📌 Brief Summary
|
||||
10v10 대규모 멀티플레이어는 [[WARNO|WARNO]]에서 최대 20명의 플레이어가 동시에 참여하여 거대한 스펙터클과 혼란을 만들어내는 대규모 전술 게임 모드입니다 [1]. 이 모드에서는 유닛과 플레이어의 밀도가 매우 높아 강력한 포격과 촘촘한 방공망이 형성되며, 플레이어는 전장 전체가 아닌 특정 구역에 집중하여 전투를 수행할 수 있습니다 [1]. WARNO의 기반인 Iriszoom 엔진은 수백 개의 유닛이 기동하고 파괴되는 이러한 극단적인 환경 속에서도 4K 해상도와 풀 옵션을 안정적으로 유지할 수 있는 고도의 데이터 최적화 성능을 자랑합니다 [2, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **엔진 최적화 및 시각 데이터 처리:** 10v10 멀티플레이어 매치는 시스템에 엄청난 부하를 주지만, Iriszoom 엔진은 이를 원활하게 처리하도록 설계되었습니다 [2]. 수백 개의 개별 유닛이 동시에 전장에서 충돌하고 파괴되는 10 대 10 환경에서도 게임은 4K 해상도와 풀 옵션 설정에서 안정적인 성능을 보여줍니다 [3]. 또한 네이팜, 연막, 폭발 등의 시각적 효과 데이터가 10v10 모드에서도 효과가 종료되기 전에 사라지지 않고 명확하게 렌더링되도록 최적화되었습니다 [4].
|
||||
@@ -16,8 +16,8 @@ converted_at: 2026-04-28
|
||||
* **통계적 밸런스와 숙련도 데이터:** 많은 플레이어가 특정 진영(NATO 또는 PACT)이 10v10에서 불균형적으로 강하다고 인식하지만, 실제 10v10 퍼블릭 로비의 플레이어 승률과 텔레메트리 데이터를 분석해 보면 진영 간 눈에 띄는 편향은 발견되지 않습니다 [9]. 10v10 대규모 멀티플레이어 데이터 분석 결과, NATO와 PACT 간의 플레이 비중 및 승률은 플레이어의 숙련도가 높아질수록 균형을 이루는 경향을 보입니다 [10].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Iriszoom 엔진]], [[사단(Division) 시스템]], [[텔레메트리(Telemetry) 데이터 분석]]
|
||||
- **Projects/Contexts:** [[WARNO 데이터 기반 밸런싱]]
|
||||
- **Related Topics:** [[Iriszoom 엔진|Iriszoom 엔진]], 사단(Division) 시스템, [[텔레메트리(Telemetry) 데이터 분석|텔레메트리(Telemetry) 데이터 분석]]
|
||||
- **Projects/Contexts:** [[WARNO 데이터 기반 밸런싱|WARNO 데이터 기반 밸런싱]]
|
||||
- **Contradictions/Notes:** 소스 [5]을 비롯해 10v10 커뮤니티 내에서는 게임 경험상 특정 진영(예: NATO)이 더 강하거나 유리하게 느껴진다는 체감상 주장들이 종종 제기되지만, 소스 [11], [9], [10]에서 진행된 실제 10v10 플레이어 데이터 및 승률 통계 분석에 따르면 두 진영 간의 통계적으로 유의미한 불균형이나 편향은 존재하지 않으며, 승패는 주로 플레이어 본인과 팀원들의 숙련도 차이에 기인하는 것으로 나타납니다 [12].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-5267ED
|
||||
id: [[P-Reinforce|P-Reinforce]]-5267ED
|
||||
category: "10_Wiki/💡 Topics/AI & Games"
|
||||
confidence_score: 0.95
|
||||
tags: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Mega Batch - Wikified AlphaZero [[Strategy]]"
|
||||
github_commit: "[P-Reinforce] Mega Batch - Wikified AlphaZero [[Strategy|Strategy]]"
|
||||
---
|
||||
|
||||
# [[AlphaZero Strategy]]
|
||||
# [[AlphaZero Strategy|AlphaZero Strategy]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 핵심 요약 작업 진행 중
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# Combined Arms (제병협동) 전술
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
Combined Arms (제병협동) 전술은 보병, 기갑, 포병, 항공 지원 및 정찰 등 다양한 병과를 조화롭게 통합하여 승리를 쟁취하는 [[WARNO]]의 핵심 전술입니다 [1]. 이는 가위바위보와 같은 상성 원리를 기반으로 작동하며, 다양한 유닛이 서로를 지원하고 약점을 보완하도록 전술적 진형을 갖추어 교전을 통제하는 것을 의미합니다 [2-4].
|
||||
## 📌 Brief Summary
|
||||
Combined Arms (제병협동) 전술은 보병, 기갑, 포병, 항공 지원 및 정찰 등 다양한 병과를 조화롭게 통합하여 승리를 쟁취하는 [[WARNO|WARNO]]의 핵심 전술입니다 [1]. 이는 가위바위보와 같은 상성 원리를 기반으로 작동하며, 다양한 유닛이 서로를 지원하고 약점을 보완하도록 전술적 진형을 갖추어 교전을 통제하는 것을 의미합니다 [2-4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **가위바위보 기반의 상성 원리:** WARNO의 전투는 기본적으로 공격 헬기가 전차를 이기고, 대공포가 공격 헬기를 이기며, 전차가 대공포를 이기는 식의 상성(rock-paper-scissors) 원리로 작동합니다 [3, 5]. 따라서 적이 어떤 유닛을 투입하든 즉각적으로 카운터 유닛으로 대응할 수 있도록, 사전에 전장에 다양한 병과를 미리 전개해 두는 것이 제병협동의 기초입니다 [4, 5].
|
||||
@@ -19,8 +19,8 @@ Combined Arms (제병협동) 전술은 보병, 기갑, 포병, 항공 지원 및
|
||||
* **Army General 캠페인에서의 시스템적 보상:** Army General 모드에서 전술 전투(Tactical Battle)를 벌일 때, 서로 다른 유닛 타입들을 조합하여 제병협동을 달성하면 시스템적으로 적에게는 부정적인 모디파이어(페널티)를 가하고 아군에게는 추가적인 전투 보너스를 제공받게 됩니다 [11].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[가위바위보 상성 (Rock-paper-scissors principle)]], [[장갑 및 사거리 데이터 (Armor and Range Stats)]], [[은신과 시야 매커니즘 (Stealth and Optics)]]
|
||||
- **Projects/Contexts:** [[WARNO 실시간 전술(Real-time Tactics) 및 Army General 캠페인]]
|
||||
- **Related Topics:** [[가위바위보 상성 (Rock-paper-scissors principle)|가위바위보 상성 (Rock-paper-scissors principle]], 장갑 및 사거리 데이터 (Armor and Range Stats), [[은신과 시야 매커니즘 (Stealth and Optics)|은신과 시야 매커니즘 (Stealth and Optics]]
|
||||
- **Projects/Contexts:** [[WARNO 실시간 전술(Real-time Tactics) 및 Army General 캠페인|WARNO 실시간 전술(Real-time Tactics) 및 Army General 캠페인]]
|
||||
- **Contradictions/Notes:** 모든 소스들은 공통적으로 제병협동의 절대적인 중요성을 강조하며, 단순히 병력을 한곳에 뭉치는 것(blobbing)이 아니라 각 유닛의 스펙과 데이터(장갑, 사거리, 은신)를 고려한 정교한 진형 배치가 승리의 핵심임을 지적합니다 [1, 7, 12].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# Eugen[[ system]]s 모딩 매뉴얼
|
||||
# EugenSystems 모딩 매뉴얼
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
[[Eugen Systems]]의 [[WARNO]] 모딩 매뉴얼은 플레이어가 게임 소스 코드를 직접 수정하지 않고도 게임 내 데이터 포맷인 NDF(Neutral Data Format) 파일을 편집하여 새로운 유닛, 무기, 사단 등을 추가하거나 밸런스를 변경할 수 있도록 돕는 지침이다 [1, 2]. 게임 설치 폴더에 포함된 공식 매뉴얼(Modding Manual, NDF [[Reference]] Manual) 및 커뮤니티가 제공하는 가이드와 툴(Warno Mod Editor 등)을 기반으로 모딩이 이루어진다 [3, 4]. 이를 통해 사용자들은 유닛의 기초적인 통계부터 3D 모델(Depiction) 및 덱 편제에 이르기까지 폭넓은 데이터 수정 작업을 수행할 수 있다 [1, 5, 6].
|
||||
## 📌 Brief Summary
|
||||
[[Eugen Systems|Eugen Systems]]의 WARNO 모딩 매뉴얼은 플레이어가 게임 소스 코드를 직접 수정하지 않고도 게임 내 데이터 포맷인 NDF(Neutral Data Format) 파일을 편집하여 새로운 유닛, 무기, 사단 등을 추가하거나 밸런스를 변경할 수 있도록 돕는 지침이다 [1, 2]. 게임 설치 폴더에 포함된 공식 매뉴얼(Modding Manual, NDF [[Reference|Reference]] Manual) 및 커뮤니티가 제공하는 가이드와 툴(Warno Mod Editor 등)을 기반으로 모딩이 이루어진다 [3, 4]. 이를 통해 사용자들은 유닛의 기초적인 통계부터 3D 모델(Depiction) 및 덱 편제에 이르기까지 폭넓은 데이터 수정 작업을 수행할 수 있다 [1, 5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
* **모딩 초기 설정 (Initial Setup):** WARNO의 모딩은 게임의 `Mods` 폴더 내에 있는 `CreateNewMod.bat` 파일을 실행하여 모드 이름을 인수로 입력함으로써 시작된다 [7, 8]. 성공적으로 실행되면 `CommonData`, `GameData` 폴더와 모드 생성 및 관리를 위한 다양한 배치 파일(`GenerateMod.bat`, `UpdateMod.bat` 등)이 생성된다 [6, 9]. Eugen Systems는 모딩의 기초를 다룬 'Modding Manual'과 NDF 언어의 구조를 설명하는 'NDF Reference Manual' PDF 파일을 게임 폴더 내에 함께 제공하여 모더들을 지원하고 있다 [4].
|
||||
@@ -20,8 +20,8 @@ converted_at: 2026-04-28
|
||||
* **시각적 묘사 (Depictions):** 게임 내 3D 모델(`.fbx` 파일), 사운드, 시각 효과 등을 렌더링하기 위해서는 `DepictionVehicles.ndf`, `DepictionAlternatives.ndf`(LOD 품질 설정용), `GeneratedDepictionGhosts.ndf`(배치 단계의 투명 모델), `UnitCadavreDescriptor.ndf`(파괴된 유닛 잔해) 등의 다양한 NDF 파일들을 편집하고 상호 연결하는 복잡한 과정이 필요하다 [5, 17, 18].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** `[[NDF (Neutral Data Format)]]`, `[[Warno Mod Editor (WME)]]`, `[[Iriszoom 엔진]]`
|
||||
- **Projects/Contexts:** `[[WARNO-DATA Wiki]]`, `[[RebsFRAGO 모드 프로젝트]]`
|
||||
- **Related Topics:** `[[NDF (Neutral Data Format)|NDF (Neutral Data Format]]`, `Warno Mod Editor (WME)`, `[[Iriszoom 엔진|Iriszoom 엔진]]`
|
||||
- **Projects/Contexts:** `[[WARNO-DATA Wiki|WARNO-DATA Wiki]]`, `RebsFRAGO 모드 프로젝트`
|
||||
- **Contradictions/Notes:** 모딩 중 동일한 유닛을 같은 사단 덱 내에 중복해서 추가할 경우, 충돌이 발생하여 정상적으로 모드가 생성되지 않는다는 점에 주의해야 한다 [14]. 또한, 모드 생성 시 나타나는 코드 오류 메시지가 주로 프랑스어로 출력되므로, 번역기를 사용하여 편집 실수를 파악하고 대처해야 할 수 있다 [15].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# Eugen[[ system]]s의 Iriszoom 엔진 및 전략 게임 개발
|
||||
# EugenSystems의 Iriszoom 엔진 및 전략 게임 개발
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
[[Eugen Systems]]가 개발한 [[WARNO]]는 독자적인 Iriszoom 엔진을 기반으로 구축된 현대 실시간 전술 및 턴제 전략 게임이다 [1, 2]. 이 엔진은 수 킬로미터에 달하는 광활한 전략적 시야와 개별 병사의 무장까지 확인 가능한 세밀한 전술적 시점을 매끄럽게 연결하며, 물리 기반 렌더링(PBR)을 통해 전장의 시각적 사실성을 극대화한다 [3, 4]. 전작인 Wargame과 Steel Division 시리즈의 성공적인 요소를 계승하면서도, 고도화된 데이터 중심 설계(Data-Driven Design)를 결합하여 복잡한 현대 전술 시뮬레이션을 구현해냈다 [2, 5].
|
||||
## 📌 Brief Summary
|
||||
[[Eugen Systems|Eugen Systems]]가 개발한 [[WARNO|WARNO]]는 독자적인 Iriszoom 엔진을 기반으로 구축된 현대 실시간 전술 및 턴제 전략 게임이다 [1, 2]. 이 엔진은 수 킬로미터에 달하는 광활한 전략적 시야와 개별 병사의 무장까지 확인 가능한 세밀한 전술적 시점을 매끄럽게 연결하며, 물리 기반 렌더링(PBR)을 통해 전장의 시각적 사실성을 극대화한다 [3, 4]. 전작인 Wargame과 Steel Division 시리즈의 성공적인 요소를 계승하면서도, 고도화된 데이터 중심 설계(Data-Driven Design)를 결합하여 복잡한 현대 전술 시뮬레이션을 구현해냈다 [2, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
@@ -15,7 +15,7 @@ converted_at: 2026-04-28
|
||||
Iriszoom 엔진은 R.U.S.E. 게임부터 이어져 온 Eugen Systems의 독자 엔진으로, 광활한 전장을 조감하는 시점과 유닛 단위의 정밀한 시점을 단일 렌더링 파이프라인 내에서 끊김 없이 연결하는 '줌(Zoom)' 기능을 핵심으로 한다 [3, 4]. 이 엔진은 카메라와의 거리에 따라 3D 모델의 정밀도를 동적으로 조절하는 가변적 LOD(Level of Detail) 시스템을 채택하여 대규모 전장에서의 가시성과 성능을 동시에 확보한다 [6, 7].
|
||||
|
||||
* **그래픽 및 렌더링 파이프라인의 진화**
|
||||
WARNO에 도입된 최신 엔진은 물리 기반 렌더링(PBR) 시스템과 지연 렌더링(Deferred Rendering) 구조를 전면 도입하였다 [3, 4]. 이를 통해 원거리 시야에서 발생할 수 있는 스펙큘러 폭발(Specular explosion) 노이즈를 효과적으로 억제하고, 4K 해상도의 텍스처를 지원한다 [3, 8]. 또한, [[Metal]]lic/Roughness/Ambient Occlusion 워크플로우를 적용해 이전의 Specular/Glossiness 방식보다 금속 및 비금속 등 재질을 물리 법칙에 맞게 사실적으로 묘사한다 [4, 7, 8].
|
||||
WARNO에 도입된 최신 엔진은 물리 기반 렌더링(PBR) 시스템과 지연 렌더링(Deferred Rendering) 구조를 전면 도입하였다 [3, 4]. 이를 통해 원거리 시야에서 발생할 수 있는 스펙큘러 폭발(Specular explosion) 노이즈를 효과적으로 억제하고, 4K 해상도의 텍스처를 지원한다 [3, 8]. 또한, [[Metal|Metal]]lic/Roughness/Ambient Occlusion 워크플로우를 적용해 이전의 Specular/Glossiness 방식보다 금속 및 비금속 등 재질을 물리 법칙에 맞게 사실적으로 묘사한다 [4, 7, 8].
|
||||
|
||||
* **동적 파괴 시스템과 데이터의 물리적 연동**
|
||||
게임 내 유닛의 파괴는 단순한 폭발 이펙트가 아니라 상태 데이터와 동기화된 물리적 현상으로 처리된다 [7]. 탄약고 유폭 시 전차의 포탑이 사출되거나 헬리콥터의 로터 블레이드 및 터빈이 비산하는 등 정교한 파괴 모션이 구현된다 [7, 9]. 파괴된 잔해나 폭발 분화구는 사라지지 않고 전장에 영구적으로 남아 '영속적 전장(Persistent Battlefield)'을 시각적으로 가시화한다 [7, 9].
|
||||
@@ -24,8 +24,8 @@ WARNO에 도입된 최신 엔진은 물리 기반 렌더링(PBR) 시스템과
|
||||
시각적 및 물리적 복잡성에도 불구하고 Iriszoom 엔진의 최적화 수준은 매우 뛰어나다 [4]. 수백 개의 유닛이 교전하는 10 대 10 멀티플레이어 환경이나 3x3km 크기의 전장에서도 프레임 드랍 없이 부드러운 플레이를 제공하며, 게임 로딩 속도 또한 매우 빠르다 [4, 10-12]. 개발진은 이러한 엔진 향상에도 불구하고 WARNO의 시스템 요구 사항이 전작인 Steel Division 2보다 높아지지 않도록 효율성을 유지하였다 [8]. 이를 바탕으로 WARNO는 Wargame 시리즈의 실시간 전술(RTT) 교전과 Steel Division 2의 턴제 Army General 캠페인 메커니즘을 성공적으로 하나의 게임 내에 결합시켰다 [13-15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Iriszoom 엔진]], [[물리 기반 렌더링(PBR)]], [[데이터 기반 설계(Data-Driven Design)]], [[NDF (Neutral Data Format)]]
|
||||
- **Projects/Contexts:** [[WARNO]], [[Wargame 시리즈]], [[Steel Division 2]]
|
||||
- **Related Topics:** [[Iriszoom 엔진|Iriszoom 엔진]], 물리 기반 렌더링(PBR), 데이터 기반 설계(Data-Driven Design), [[NDF (Neutral Data Format)|NDF (Neutral Data Format]]
|
||||
- **Projects/Contexts:** [[WARNO|WARNO]], Wargame 시리즈, Steel Division 2
|
||||
- **Contradictions/Notes:** 소스에 따르면 엔진 기술의 시각적 그래픽 수준이 대폭 향상되었으나, 최적화를 통해 Steel Division 2 이상의 고사양 PC를 요구하지 않도록 설계된 점이 특징적이다 [8]. 유저들 또한 고도로 디테일한 모델과 애니메이션을 특징으로 하는 경쟁작들과 비교할 때, 수많은 객체를 끊김 없이 렌더링하는 WARNO의 탁월한 최적화를 엔진의 가장 큰 강점으로 평가하고 있다 [10-12].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,14 +4,14 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# Eugen[[ system]]s의 [[WARNO]] 시뮬레이션 개발
|
||||
# EugenSystems의 [[WARNO|WARNO]] 시뮬레이션 개발
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
[[Eugen Systems]]가 개발한 WARNO는 1989년 냉전이 열전으로 번진 가상의 시나리오를 배경으로 하는 실시간 전술(RTT) 및 턴제 전략 시뮬레이션 게임입니다 [1, 2]. 이 게임은 자체 개발한 Iriszoom 엔진을 통해 세밀한 3D 그래픽과 대규모 전장을 매끄럽게 구현하며, NDF(Neutral Data Format)라는 독자적인 스크립트 언어를 활용한 데이터 아키텍처를 기반으로 설계되었습니다 [3-5]. 개발진은 커뮤니티의 피드백뿐만 아니라 객관적인 텔레메트리(Telemetry) 데이터를 실시간으로 분석하여 무기 스펙과 사단 편제 등 시뮬레이션의 전술적 밸런스를 정교하게 조정합니다 [6, 7].
|
||||
## 📌 Brief Summary
|
||||
[[Eugen Systems|Eugen Systems]]가 개발한 WARNO는 1989년 냉전이 열전으로 번진 가상의 시나리오를 배경으로 하는 실시간 전술(RTT) 및 턴제 전략 시뮬레이션 게임입니다 [1, 2]. 이 게임은 자체 개발한 Iriszoom 엔진을 통해 세밀한 3D 그래픽과 대규모 전장을 매끄럽게 구현하며, NDF(Neutral Data Format)라는 독자적인 스크립트 언어를 활용한 데이터 아키텍처를 기반으로 설계되었습니다 [3-5]. 개발진은 커뮤니티의 피드백뿐만 아니라 객관적인 텔레메트리(Telemetry) 데이터를 실시간으로 분석하여 무기 스펙과 사단 편제 등 시뮬레이션의 전술적 밸런스를 정교하게 조정합니다 [6, 7].
|
||||
|
||||
## 📖 Core Content
|
||||
* **Iriszoom 엔진과 시각적 가시화:**
|
||||
WARNO는 과거 R.U.S.E.부터 진화해 온 Eugen Systems의 독자 엔진인 Iriszoom의 최신 버전을 사용합니다 [3, 4]. 이 엔진은 물리 기반 렌더링(PBR) 시스템과 [[Metal]]lic/Roughness/Ambient Occlusion 워크플로우를 도입하여 4K 해상도로 유닛과 지형의 질감을 매우 사실적으로 구현합니다 [3, 4, 8]. 기술적으로 지연 렌더링(Deferred Rendering) 구조를 활용해 수백 대의 유닛이 맞붙는 10 대 10 멀티플레이어 환경에서도 뛰어난 최적화를 유지하며, 탄약고 유폭 시 포탑이 날아가거나 헬기 로터 블레이드가 떨어져 나가는 동적 파괴 시스템이 물리 데이터와 연동되어 표현됩니다 [4, 9-11].
|
||||
WARNO는 과거 R.U.S.E.부터 진화해 온 Eugen Systems의 독자 엔진인 Iriszoom의 최신 버전을 사용합니다 [3, 4]. 이 엔진은 물리 기반 렌더링(PBR) 시스템과 [[Metal|Metal]]lic/Roughness/Ambient Occlusion 워크플로우를 도입하여 4K 해상도로 유닛과 지형의 질감을 매우 사실적으로 구현합니다 [3, 4, 8]. 기술적으로 지연 렌더링(Deferred Rendering) 구조를 활용해 수백 대의 유닛이 맞붙는 10 대 10 멀티플레이어 환경에서도 뛰어난 최적화를 유지하며, 탄약고 유폭 시 포탑이 날아가거나 헬기 로터 블레이드가 떨어져 나가는 동적 파괴 시스템이 물리 데이터와 연동되어 표현됩니다 [4, 9-11].
|
||||
|
||||
* **NDF(Neutral Data Format) 기반의 데이터 아키텍처:**
|
||||
시뮬레이션의 모든 논리적 설계와 유닛 메커니즘은 NDF(Neutral Data Format)라는 텍스트 기반의 자체 스크립트 언어로 정의되어 있습니다 [5, 12]. 게임의 소스 코드와 데이터가 엄격히 분리된 이 객체 지향적 구조 덕분에, 개발자나 유저(모더)들은 `UniteDescriptor.ndf`, `WeaponDescriptor.ndf`, `Ammunition.ndf` 등의 데이터 파일만 수정하여 유닛의 명중률, 관통력, 이동 속도, 장갑 수치 등을 쉽게 제어할 수 있습니다 [5, 13-15]. 이러한 개방적이고 모듈화된 데이터 설계는 RebsFRAGO와 같이 무기 데이터를 실제 현실의 제원값으로 치환하는 정교한 현실주의 모드의 탄생을 가능하게 했습니다 [5, 16-18].
|
||||
@@ -23,8 +23,8 @@ converted_at: 2026-04-28
|
||||
게임 내 전투 역학은 거리 비례 명중률(가까울수록 기하급수적으로 상승), 승수적으로 작용하는 항공기 ECM(전자전) 데이터, 무기 사거리 등 복잡한 수학적 모델을 따릅니다 [25-28]. Eugen Systems는 이렇게 복잡하게 얽힌 시스템을 밸런싱하기 위해 플레이어들의 유닛 선택률(Pick rate), 교전 승률, 평균 생존 시간 등을 추적하는 '텔레메트리 데이터'를 활용합니다 [6, 7]. 개발진은 커뮤니티의 단순한 여론에 휩쓸리지 않고 수집된 객관적 데이터를 분석하여, 특정 유닛이나 사단이 과도한 효율을 낼 경우 NDF 파일의 포인트 비용이나 세부 스펙을 정밀하게 조정하는 방식을 취합니다 [6, 7, 29].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** `[[Iriszoom 엔진]]`, `[[NDF (Neutral Data Format)]]`, `[[사단 시스템 (Division System)]]`, `[[텔레메트리 (Telemetry) 밸런싱]]`
|
||||
- **Projects/Contexts:** `[[WARNO]]`, `[[Wargame 시리즈]]`, `[[Steel Division 시리즈]]`, `[[RebsFRAGO 모드]]`
|
||||
- **Related Topics:** `[[Iriszoom 엔진|Iriszoom 엔진]]`, `NDF (Neutral Data Format)`, `사단 시스템 (Division System)`, `[[텔레메트리 (Telemetry) 밸런싱|텔레메트리 (Telemetry) 밸런싱]]`
|
||||
- **Projects/Contexts:** `[[WARNO|WARNO]]`, `Wargame 시리즈`, `Steel Division 시리즈`, `[[RebsFRAGO 모드|RebsFRAGO 모드]]`
|
||||
- **Contradictions/Notes:** 덱 구성 아키텍처와 관련하여, 일부 유저들은 과거 Wargame 시리즈처럼 제약이 없는 국가별 덱 시스템이 유저의 창의성을 높인다고 주장하지만, 개발진과 다른 다수의 유저들은 사단 시스템(Division System)이 메타 고착화를 방지하고 훨씬 다양하고 역사적으로 몰입감 있는 밸런스를 제공한다고 반박합니다 [19, 30-34].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# Eugen[[ system]]s의 냉전기 가상 시나리오 및 모딩 생태계 구축
|
||||
# EugenSystems의 냉전기 가상 시나리오 및 모딩 생태계 구축
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
[[Eugen Systems]]의 [[WARNO]]는 1987년 소련 강경파의 쿠데타를 기점으로 1989년에 제3차 세계대전이 발발했다는 가상의 '냉전기 열전(Cold War Gone Hot)' 시나리오를 배경으로 합니다 [1, 2]. 이 가상 시나리오는 실제 역사적 사단 편제표(TO&E)를 철저한 데이터 구조로 치환하여 게임 내 규칙으로 적용한 데이터 기반 설계를 특징으로 합니다 [2]. 더 나아가, 독자적인 NDF(Neutral Data Format) 시스템을 통해 소스코드 수정 없이도 게임 데이터를 제어할 수 있게 하여, 커뮤니티 주도의 분석 도구 및 모드(Mod) 개발이 활발히 이루어지는 개방적인 생태계를 구축했습니다 [2, 3].
|
||||
## 📌 Brief Summary
|
||||
[[Eugen Systems|Eugen Systems]]의 [[WARNO|WARNO]]는 1987년 소련 강경파의 쿠데타를 기점으로 1989년에 제3차 세계대전이 발발했다는 가상의 '냉전기 열전(Cold War Gone Hot)' 시나리오를 배경으로 합니다 [1, 2]. 이 가상 시나리오는 실제 역사적 사단 편제표(TO&E)를 철저한 데이터 구조로 치환하여 게임 내 규칙으로 적용한 데이터 기반 설계를 특징으로 합니다 [2]. 더 나아가, 독자적인 NDF(Neutral Data Format) 시스템을 통해 소스코드 수정 없이도 게임 데이터를 제어할 수 있게 하여, 커뮤니티 주도의 분석 도구 및 모드(Mod) 개발이 활발히 이루어지는 개방적인 생태계를 구축했습니다 [2, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **가상 냉전 시나리오의 데이터적 구현**
|
||||
@@ -21,13 +21,13 @@ converted_at: 2026-04-28
|
||||
* Eugen Systems는 사용자를 위해 `CreateNewMod.bat` 등의 배치 파일과 모딩 매뉴얼, NDF 참조 가이드를 제공하여 손쉽게 모드 환경을 구축할 수 있게 돕고 있습니다 [3, 5].
|
||||
|
||||
* **데이터 민주화와 커뮤니티 생태계 확장**
|
||||
* NDF 파일의 구조적 접근성 덕분에 커뮤니티는 숨겨진 게임 내부 수치를 파싱하여 [[War-Yes]], [[Warno-Armory]]와 같은 정밀한 데이터 분석 웹사이트와 툴을 자체적으로 개발할 수 있었습니다 [2, 6, 7].
|
||||
* NDF 파일의 구조적 접근성 덕분에 커뮤니티는 숨겨진 게임 내부 수치를 파싱하여 [[War-Yes|War-Yes]], [[Warno-Armory|Warno-Armory]]와 같은 정밀한 데이터 분석 웹사이트와 툴을 자체적으로 개발할 수 있었습니다 [2, 6, 7].
|
||||
* 또한, 흩어진 NDF 속성들의 의미와 핵심 게임 메커니즘을 문서화하기 위해 WARNO-DATA와 같은 광범위한 오픈소스 위키 프로젝트가 진행되기도 했습니다 [2, 8].
|
||||
* 이러한 생태계의 개방성은 모든 무기 데이터를 실제 현실의 제원값으로 치환하고 시뮬레이션 경제를 재설계한 'RebsFRAGO'와 같은 고도의 현실주의 모드(Realism Mod)가 탄생하는 기술적 근간이 되었습니다 [2, 9].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[사단 편제표 (TO&E)]], [[데이터 기반 설계]]
|
||||
- **Projects/Contexts:** [[WARNO-DATA 프로젝트]], [[RebsFRAGO 모드]], [[War-Yes 및 Warno-Armory 도구]]
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], 사단 편제표 (TO&E), [[데이터 기반 설계|데이터 기반 설계]]
|
||||
- **Projects/Contexts:** [[WARNO-DATA 프로젝트|WARNO-DATA 프로젝트]], RebsFRAGO 모드, [[War-Yes 및 Warno-Armory 도구|War-Yes 및 Warno-Armory 도구]]
|
||||
- **Contradictions/Notes:** 게임의 전체적인 배경은 1989년 3차 세계대전이라는 완전한 허구의 시나리오를 따르고 있지만, 그 전장을 채우는 부대 편제와 유닛의 성능은 철저하게 실제 역사적 데이터(TO&E 등)를 바탕으로 한 데이터 아키텍처에 의해 엄격하게 통제되고 있어 허구와 현실성이 공존하고 있습니다 [1, 2, 4].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Index: Topics > AI & Games
|
||||
|
||||
## 📝 Documents
|
||||
- [[AlphaZero Strategy]]
|
||||
- [[AlphaZero Strategy|AlphaZero Strategy]]
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# Steel Division 시리즈
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
'Steel Division 시리즈'는 Eugen[[ system]]s가 개발한 실시간 전술 및 전략 비디오 게임 시리즈로, 《Steel Division: Normandy 44》와 《Steel Division 2》를 포함합니다 [1]. 이 시리즈는 역사적 군 편제표에 기반한 사단(Division) 덱 시스템, 스마트 오더, Army General 캠페인과 같은 핵심 시스템을 도입했습니다 [2, 3]. 이러한 메커니즘은 이후 《[[WARNO]]》의 정교한 데이터 기반 설계와 전술적 게임플레이를 구축하는 데 직접적이고 결정적인 토대가 되었습니다 [4, 5].
|
||||
## 📌 Brief Summary
|
||||
'Steel Division 시리즈'는 EugenSystems가 개발한 실시간 전술 및 전략 비디오 게임 시리즈로, 《Steel Division: Normandy 44》와 《Steel Division 2》를 포함합니다 [1]. 이 시리즈는 역사적 군 편제표에 기반한 사단(Division) 덱 시스템, 스마트 오더, Army General 캠페인과 같은 핵심 시스템을 도입했습니다 [2, 3]. 이러한 메커니즘은 이후 《[[WARNO|WARNO]]》의 정교한 데이터 기반 설계와 전술적 게임플레이를 구축하는 데 직접적이고 결정적인 토대가 되었습니다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
* **WARNO 설계의 기술적·전술적 토대:**
|
||||
@@ -20,14 +20,14 @@ converted_at: 2026-04-28
|
||||
《Steel Division 2》에서 처음 도입된 혁신적인 AI 편의성 도구들이 《WARNO》에 그대로 이식되었습니다 [2, 3, 10]. '스마트 오더'는 부대의 마이크로 컨트롤을 컴퓨터에 위임하여 그룹 구성, 지형, 도로, 적의 상대적 강도 등 다양한 전술적 데이터를 AI가 통합적으로 계산해 명령을 수행하게 합니다 [2, 11]. '교전 수칙'은 유닛이 전장의 변화하는 조건에 맞춰 더 독립적이고 지능적으로 행동하도록 규칙을 설정할 수 있게 해줍니다 [10].
|
||||
|
||||
* **전략적 깊이를 더하는 싱글플레이어 콘텐츠:**
|
||||
《WARNO》는 《Steel Division 2》로부터 턴제 기반의 전략 캠페인인 'Army General'과 실시간 '[[Opera]]tions(작전)' 모드 등 전용 싱글플레이어 콘텐츠를 성공적으로 통합했습니다 [3]. 이를 통해 개별 전술 전투뿐만 아니라 대규모 작전 단위의 시뮬레이션을 구현할 수 있었습니다.
|
||||
《WARNO》는 《Steel Division 2》로부터 턴제 기반의 전략 캠페인인 'Army General'과 실시간 '[[Opera|Opera]]tions(작전)' 모드 등 전용 싱글플레이어 콘텐츠를 성공적으로 통합했습니다 [3]. 이를 통해 개별 전술 전투뿐만 아니라 대규모 작전 단위의 시뮬레이션을 구현할 수 있었습니다.
|
||||
|
||||
* **장갑 관통 및 피해 연산의 진화:**
|
||||
《Steel Division》 시리즈는 장갑 관통 확률과 거리에 따른 스케일링 계산법에 있어 지속적인 변화와 발전을 거쳤습니다 [12]. 1편에서 2편으로 넘어가며 계산 방식이 변경되었으며 [13], 이는 《WARNO》에 이르러 운동에너지(KE) 탄자와 성형작약탄(HEAT)의 데이터적 차별화로 이어지는 물리적 시뮬레이션 발전의 궤적을 보여줍니다 [14].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[사단 편제표(TO&E)]], [[스마트 오더(Smart Orders)]], [[Army General 캠페인]]
|
||||
- **Projects/Contexts:** [[Eugen Systems의 게임 개발 계보]], [[WARNO의 시스템 설계]]
|
||||
- **Related Topics:** [[사단 편제표 (TO&E)|사단 편제표(TO&E]], 스마트 오더(Smart Orders), Army General 캠페인
|
||||
- **Projects/Contexts:** Eugen Systems의 게임 개발 계보, WARNO의 시스템 설계
|
||||
- **Contradictions/Notes:** 커뮤니티 내에서는 과거 Wargame 시리즈의 국가 기반 자유 덱 시스템을 선호하는 유저들이 있으나, 통계 및 밸런스 측면에서는 《Steel Division》에서 도입된 사단 시스템이 우월하다는 커뮤니티 및 개발진의 평가가 대립/공존하고 있습니다 [9, 15, 16].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,21 +4,21 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 그래픽 엔진 업그레이드 프로젝트
|
||||
# [[WARNO|WARNO]] 그래픽 엔진 업그레이드 프로젝트
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO 그래픽 엔진 업그레이드 프로젝트는 Eugen[[ system]]s의 독자적인 기술인 Iriszoom 엔진을 최신 산업 표준에 맞게 진화시킨 프로젝트입니다 [1, 2]. 이 업그레이드는 물리 기반 렌더링(PBR) 시스템을 전면 도입하여 유닛과 지형의 시각적 사실성을 극대화했습니다 [1, 2]. 4K 텍스처와 물리 데이터가 연동된 정교한 파괴 시스템을 적용하면서도 뛰어난 최적화를 달성하여 전작인 Steel Division 2 수준의 시스템 요구 사양을 유지한 것이 핵심입니다 [3, 4].
|
||||
## 📌 Brief Summary
|
||||
WARNO 그래픽 엔진 업그레이드 프로젝트는 EugenSystems의 독자적인 기술인 Iriszoom 엔진을 최신 산업 표준에 맞게 진화시킨 프로젝트입니다 [1, 2]. 이 업그레이드는 물리 기반 렌더링(PBR) 시스템을 전면 도입하여 유닛과 지형의 시각적 사실성을 극대화했습니다 [1, 2]. 4K 텍스처와 물리 데이터가 연동된 정교한 파괴 시스템을 적용하면서도 뛰어난 최적화를 달성하여 전작인 Steel Division 2 수준의 시스템 요구 사양을 유지한 것이 핵심입니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **Iriszoom 엔진의 진화와 PBR 파이프라인 도입:** R.U.S.E.부터 이어져 온 독자적인 엔진 기술을 발전시켜 수 킬로미터의 광활한 전략적 조감 시점과 개별 병사를 식별할 수 있는 전술적 시점을 매끄럽게 연결합니다 [2]. 기존의 Specular/Glossiness 방식 대신 최첨단 [[Metal]]lic/Roughness/Ambient Occlusion 워크플로우를 자산 생산 파이프라인에 전면 도입했습니다 [2, 3]. 이를 통해 모든 유닛에 4K PBR 텍스처와 세밀한 모델링을 적용하였으며, 사진학적 설정을 활용한 새로운 톤 매핑 알고리즘으로 사실성을 높였습니다 [2, 3]. 지연 렌더링(Deferred Rendering) 구조를 활용해 원거리에서 폭발적으로 발생하는 PBR 스펙큘러 노이즈 문제도 효과적으로 해결했습니다 [1, 2].
|
||||
* **Iriszoom 엔진의 진화와 PBR 파이프라인 도입:** R.U.S.E.부터 이어져 온 독자적인 엔진 기술을 발전시켜 수 킬로미터의 광활한 전략적 조감 시점과 개별 병사를 식별할 수 있는 전술적 시점을 매끄럽게 연결합니다 [2]. 기존의 Specular/Glossiness 방식 대신 최첨단 [[Metal|Metal]]lic/Roughness/Ambient Occlusion 워크플로우를 자산 생산 파이프라인에 전면 도입했습니다 [2, 3]. 이를 통해 모든 유닛에 4K PBR 텍스처와 세밀한 모델링을 적용하였으며, 사진학적 설정을 활용한 새로운 톤 매핑 알고리즘으로 사실성을 높였습니다 [2, 3]. 지연 렌더링(Deferred Rendering) 구조를 활용해 원거리에서 폭발적으로 발생하는 PBR 스펙큘러 노이즈 문제도 효과적으로 해결했습니다 [1, 2].
|
||||
|
||||
* **데이터가 연동된 동적 파괴 시스템:** 유닛이 피해를 입고 파괴되는 시각적 효과가 실제 전투 상태 데이터와 동기화되어 작동합니다 [4]. 단순히 폭발 효과만 출력하는 것이 아니라 유닛의 장갑이나 장비 조각이 떨어져 나가며, 파괴 시 탄약고 유폭으로 포탑이 사출되거나 헬리콥터 로터 블레이드 및 비행기 날개가 날아가는 사실적인 물리적 폭발 효과가 구현되었습니다 [4, 5]. 또한, 유닛 텍스처가 파손 상태를 직접적으로 반영하여 손상도를 시각화합니다 [5].
|
||||
|
||||
* **영속적 전장(Persistent Battlefield)과 최적화:** 전장에 생성된 차량의 잔해, 연기, 크레이터 등은 단순히 장식으로 소모되지 않고 지속적으로 유지되어 사실적이고 영속적인 전장 환경을 구성합니다 [4, 5]. 그래픽 엔진이 대폭 업그레이드되었음에도 불구하고 최적화 수준이 매우 높아, 이전 타이틀인 Steel Division 2보다 높은 사양을 요구하지 않습니다 [3]. 결과적으로 수백 개의 유닛이 동시에 파괴되고 기동하는 대규모 10 대 10 멀티플레이어 환경에서도 엔진은 안정적인 시각적 성능을 발휘합니다 [2].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Iriszoom 엔진]], [[물리 기반 렌더링(PBR)]], [[지연 렌더링(Deferred Rendering)]]
|
||||
- **Projects/Contexts:** [[데이터 기반 설계(Data-Driven Design)]], [[영속적 전장(Persistent Battlefield)]]
|
||||
- **Related Topics:** [[Iriszoom 엔진|Iriszoom 엔진]], 물리 기반 렌더링(PBR), [[지연 렌더링(Deferred Rendering)|지연 렌더링(Deferred Rendering]]
|
||||
- **Projects/Contexts:** [[데이터 기반 설계 (Data-Driven Design)|데이터 기반 설계(Data-Driven Design]], 영속적 전장(Persistent Battlefield
|
||||
- **Contradictions/Notes:** 소스에 상충되는 정보는 없습니다. 시각적 디테일과 파괴 효과가 획기적으로 증가했음에도 불구하고 시스템 요구 사양이 상승하지 않고 효율적인 최적화가 유지되었다는 점이 엔진 업그레이드의 핵심 성과로 강조됩니다.
|
||||
|
||||
---
|
||||
|
||||
@@ -4,20 +4,20 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 데이터 기반 밸런싱
|
||||
# [[WARNO|WARNO]] 데이터 기반 밸런싱
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 밸런싱은 커뮤니티의 단순한 여론이나 개발진의 임의적 결정이 아닌, 수집된 방대한 텔레메트리(Telemetry) 데이터를 기반으로 객관적으로 이루어지는 시스템적 과정이다 [1], [2]. Eugen[[ system]]s는 유닛의 선택 빈도, 승률, 킬/데스 비율, 평균 생존 시간 등을 종합적으로 분석하여 포인트 비용, 무장 스펙, 사단별 가용성을 NDF 파일을 통해 세밀하게 조정한다 [2], [3]. 이러한 데이터 중심 설계는 특정 진영에 압도적인 우위가 고착되는 것을 방지하고, 게임이 지속적으로 균형 잡힌 전술 생태계로 기능하게 만든다 [3].
|
||||
## 📌 Brief Summary
|
||||
WARNO의 밸런싱은 커뮤니티의 단순한 여론이나 개발진의 임의적 결정이 아닌, 수집된 방대한 텔레메트리(Telemetry) 데이터를 기반으로 객관적으로 이루어지는 시스템적 과정이다 [1], [2]. EugenSystems는 유닛의 선택 빈도, 승률, 킬/데스 비율, 평균 생존 시간 등을 종합적으로 분석하여 포인트 비용, 무장 스펙, 사단별 가용성을 NDF 파일을 통해 세밀하게 조정한다 [2], [3]. 이러한 데이터 중심 설계는 특정 진영에 압도적인 우위가 고착되는 것을 방지하고, 게임이 지속적으로 균형 잡힌 전술 생태계로 기능하게 만든다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **텔레메트리(Telemetry) 기반의 객관적 분석:** [[Eugen Systems]]는 게임 출시 후 유저들의 플레이에서 발생하는 텔레메트리 데이터를 실시간으로 기록한다. 여기에는 어떤 유닛이 자주 선택되는지(Pick Rate), 실제 교전에서의 승률과 킬/데스 비율, 그리고 유닛의 평균 생존 시간 등이 포함된다 [2]. 개발진은 미숙련 플레이어들의 변덕스러운 여론에 직접적으로 휘둘리기보다는, 전문 테스터의 피드백과 수집된 텔레메트리 데이터를 교차 검증하여 게임 내 실제 작동 방식을 기준으로 밸런스를 조정한다 [4], [1].
|
||||
* **텔레메트리(Telemetry) 기반의 객관적 분석:** [[Eugen Systems|Eugen Systems]]는 게임 출시 후 유저들의 플레이에서 발생하는 텔레메트리 데이터를 실시간으로 기록한다. 여기에는 어떤 유닛이 자주 선택되는지(Pick Rate), 실제 교전에서의 승률과 킬/데스 비율, 그리고 유닛의 평균 생존 시간 등이 포함된다 [2]. 개발진은 미숙련 플레이어들의 변덕스러운 여론에 직접적으로 휘둘리기보다는, 전문 테스터의 피드백과 수집된 텔레메트리 데이터를 교차 검증하여 게임 내 실제 작동 방식을 기준으로 밸런스를 조정한다 [4], [1].
|
||||
* **주요 밸런스 조정 변수와 NDF 연동:** 데이터 분석을 통해 특정 무기나 유닛의 성능이 지나치게 강력하거나 비효율적이라고 확인되면, 개발자는 독자적 언어인 NDF 파일 내 수치를 수정해 전장에 즉각적인 변화를 투영한다 [5], [2]. 주요 조정 변수로는 전술적 가치와 텔레메트리 효율에 맞춘 '포인트 비용(Point Cost)' 재책정, 장전 및 조준 시간·관통력 등의 '무장 세부 스펙' 변경, 전술적 역할을 강화하기 위한 '특성(Trait)' 할당, 특정 사단의 승률을 보완하기 위한 '사단별 유닛 카드 구성 및 가용성' 상향 등이 활용된다 [3].
|
||||
* **사단(Division) 시스템을 통한 거시적 밸런스 통제:** 전작의 국가 덱(National Deck) 시스템을 대체하여 도입된 사단(Division) 중심의 덱 빌딩은 밸런싱을 위한 훌륭한 설계 장치이다 [6]. 플레이어가 뛰어난 유닛들만 모아 덱을 구성하는 것을 원천적으로 차단하며, 사단마다 내재된 강점과 약점을 데이터적으로 강제하여 훨씬 다채롭고 흥미로운 전술적 메타를 유지하게 한다 [6], [7], [8].
|
||||
* **플레이어 통계와 진영 균형 검증:** 대규모 멀티플레이어 환경(10v10 등)의 데이터 분석에 의하면, NATO와 PACT 진영 간의 승률은 플레이어의 숙련도가 높아질수록 균형을 이루는 경향을 보인다 [9], [3]. 커뮤니티 유저가 직접 수백 명의 플레이어 통계를 분석한 결과에서도 진영 간 뚜렷한 편향성은 확인되지 않았으며, 게임 시스템 자체가 특정 진영에 압도적인 우위를 제공하지 않음이 객관적 지표로 증명되고 있다 [10], [9], [3].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[텔레메트리(Telemetry)]], [[NDF (Neutral Data Format)]], [[사단 시스템(Division System)]]
|
||||
- **Projects/Contexts:** [[WARNO 멀티플레이어 밸런싱 패치]]
|
||||
- **Related Topics:** [[텔레메트리 (Telemetry)|텔레메트리(Telemetry]], NDF (Neutral Data Format), [[사단 시스템 (Division System)|사단 시스템(Division System]]
|
||||
- **Projects/Contexts:** WARNO 멀티플레이어 밸런싱 패치
|
||||
- **Contradictions/Notes:** 개발진의 텔레메트리나 유저들의 수치 통계는 양 진영(NATO vs PACT)이 대체로 균형을 이룬다는 데이터를 보여주고 있으나 [9], [3], 일부 플레이어들은 게임 체감상 특정 진영 편향(예: PACT 편향)이 존재한다고 주장하며 커뮤니티 여론과 실제 통계 데이터 간의 인식 차이가 빈번하게 나타난다 [11], [12], [4], [1].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,13 +4,13 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 데이터 기반 설계
|
||||
# [[WARNO|WARNO]] 데이터 기반 설계
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO는 1980년대 후반 냉전의 군사 교리와 장비 제원을 고도의 데이터 아키텍처로 치환하여 설계된 실시간 전술 시뮬레이션 게임입니다 [1]. 이 시스템은 Eugen[[ system]]s의 독자적인 Iriszoom 엔진과 NDF(Neutral Data Format) 스크립트 언어를 활용하여, 게임 코드와 데이터 값을 엄격히 분리한 '데이터 기반 설계(Data-Driven Design)' 철학을 바탕으로 구축되었습니다 [2]. 정밀한 명중률 알고리즘, 물리적 장갑 관통 모델, 심리적 제압 수치화, 그리고 텔레메트리에 기반한 밸런싱을 통해 플레이어에게 고도로 현실적이고 동적인 전술 환경을 제공합니다 [3-5].
|
||||
## 📌 Brief Summary
|
||||
WARNO는 1980년대 후반 냉전의 군사 교리와 장비 제원을 고도의 데이터 아키텍처로 치환하여 설계된 실시간 전술 시뮬레이션 게임입니다 [1]. 이 시스템은 EugenSystems의 독자적인 Iriszoom 엔진과 NDF(Neutral Data Format) 스크립트 언어를 활용하여, 게임 코드와 데이터 값을 엄격히 분리한 '데이터 기반 설계(Data-Driven Design)' 철학을 바탕으로 구축되었습니다 [2]. 정밀한 명중률 알고리즘, 물리적 장갑 관통 모델, 심리적 제압 수치화, 그리고 텔레메트리에 기반한 밸런싱을 통해 플레이어에게 고도로 현실적이고 동적인 전술 환경을 제공합니다 [3-5].
|
||||
|
||||
## 📖 Core 무Content
|
||||
* **[[NDF (Neutral Data Format)]] 아키텍처:**
|
||||
* **[[NDF (Neutral Data Format)|NDF (Neutral Data Format]] 아키텍처:**
|
||||
WARNO의 모든 물리적 및 기술적 속성(유닛 성능, 명중률, 관통력, 이동 속도 등)은 텍스트 기반의 객체 지향 스크립트 언어인 NDF 내에 정의되어 있습니다 [2]. `UniteDescriptor.ndf`, `WeaponDescriptor.ndf`, `Ammunition.ndf` 등의 파일을 통해 게임 소스코드를 수정하지 않고도 수천 개의 속성을 모듈화하여 체계적으로 관리하고 밸런스를 조정할 수 있습니다 [2, 6-8].
|
||||
* **Iriszoom 엔진과 시각적 데이터의 물리적 연동:**
|
||||
지연 렌더링(Deferred Rendering) 구조와 PBR(물리 기반 렌더링)을 전면 도입하여 거리에 따른 가변적 LOD 시스템을 구현했습니다 [9, 10]. 동적 파괴 시스템은 탄약고 유폭 시 포탑이 사출되거나 헬리콥터 로터가 비산하는 등 유닛의 상태 데이터와 물리적 현상을 정교하게 동기화시킵니다 [10, 11].
|
||||
@@ -19,13 +19,13 @@ WARNO는 1980년대 후반 냉전의 군사 교리와 장비 제원을 고도의
|
||||
* **장갑 및 관통(Armor & Penetration):** 실제 역사적 RHA(균질압연강권) 수치를 추상화한 '장갑 점수(Armor Value)'를 사용하며, 경사 장갑에 의한 방호 효과는 엔진 연산 부하를 줄이기 위해 미리 수치에 반영되어 있습니다 [14, 15]. 철갑탄(KE)과 같은 운동에너지 탄자는 거리에 비례해 관통력 데이터가 감소하나, 대전차 고폭탄이나 미사일(HEAT/ATGM)은 사거리에 관계없이 관통력을 유지합니다 [15].
|
||||
* **제압(Suppression)과 은신(Stealth) 시스템:**
|
||||
* 유닛은 기본적으로 500점의 제압 수치를 지니며 피격이나 폭발 시 누적되어 응집력(Cohesion)을 떨어뜨리고 명중률, 재장전, 기동력에 페널티를 부여합니다 [4, 16]. 건물(50%)과 숲(35%) 지형은 제압 효과에 대한 저항 데이터를 제공합니다 [16, 17].
|
||||
* 광학(Optics) 수치와 은신(Stealth) 수치 간의 상호작용으로 탐지가 결정되며, 무기 발사 시 생성되는 소음([[Noise]]) 데이터는 은신 수치를 일시적으로 삭감시켜 위치를 노출시킵니다 [17, 18].
|
||||
* 광학(Optics) 수치와 은신(Stealth) 수치 간의 상호작용으로 탐지가 결정되며, 무기 발사 시 생성되는 소음([[Noise|Noise]]) 데이터는 은신 수치를 일시적으로 삭감시켜 위치를 노출시킵니다 [17, 18].
|
||||
* **텔레메트리 기반 밸런스 조정:**
|
||||
개발진은 단순히 커뮤니티의 여론에 의존하지 않고, 유닛의 선택 빈도, 킬/데스 비율, 평균 생존 시간 등 방대한 텔레메트리(Telemetry) 데이터를 실시간으로 분석하여 포인트 비용이나 무장 스펙 데이터를 지속적으로 재조정합니다 [5, 19, 20].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Iriszoom Engine]], [[NDF (Neutral Data Format)]], [[Telemetry-based Balancing]], [[Data-Driven Design]]
|
||||
- **Projects/Contexts:** [[WARNO]], [[Eugen Systems]], [[WARNO Modding Ecosystem]]
|
||||
- **Related Topics:** Iriszoom Engine, NDF (Neutral Data Format), Telemetry-based Balancing, [[데이터 기반 설계 (Data-Driven Design)|Data-Driven Design]]
|
||||
- **Projects/Contexts:** [[WARNO|WARNO]], Eugen Systems, WARNO Modding Ecosystem
|
||||
- **Contradictions/Notes:** 커뮤니티의 일부 유저들은 특정 진영이나 유닛(예: PACT의 전차 장갑 등)이 편향되어 있다고 비판하며 불만을 제기하기도 하지만, 개발사가 수집한 텔레메트리 데이터 분석 결과에 따르면 플레이어의 숙련도가 높아질수록 NATO와 PACT 진영 간의 승률은 균형을 이루는 것으로 나타나 데이터 기반 밸런싱의 실효성을 입증하고 있습니다 [5, 19, 21, 22].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 멀티플레이어 및 경쟁 플레이 밸런스 패치
|
||||
# [[WARNO|WARNO]] 멀티플레이어 및 경쟁 플레이 밸런스 패치
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 멀티플레이어 및 경쟁 플레이 밸런스 패치는 개발사인 Eugen[[ system]]s가 수집하는 방대한 텔레메트리(Telemetry) 데이터를 기반으로 이루어집니다 [1], [2]. 개발진은 커뮤니티의 단순한 여론에 휘둘리지 않고, 유닛 선택률, 승률, 평균 생존 시간 등 객관적인 데이터를 분석하여 게임 내 수치를 정밀하게 조정합니다 [1], [2]. 이러한 데이터 중심의 설계와 지속적인 패치는 WARNO를 편향 없는 공정한 경쟁이 가능한 살아있는 전술 생태계로 유지하는 핵심 원동력입니다 [3].
|
||||
## 📌 Brief Summary
|
||||
WARNO의 멀티플레이어 및 경쟁 플레이 밸런스 패치는 개발사인 EugenSystems가 수집하는 방대한 텔레메트리(Telemetry) 데이터를 기반으로 이루어집니다 [1], [2]. 개발진은 커뮤니티의 단순한 여론에 휘둘리지 않고, 유닛 선택률, 승률, 평균 생존 시간 등 객관적인 데이터를 분석하여 게임 내 수치를 정밀하게 조정합니다 [1], [2]. 이러한 데이터 중심의 설계와 지속적인 패치는 WARNO를 편향 없는 공정한 경쟁이 가능한 살아있는 전술 생태계로 유지하는 핵심 원동력입니다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **텔레메트리 기반의 객관적 밸런싱**
|
||||
@@ -23,8 +23,8 @@ WARNO의 멀티플레이어 및 경쟁 플레이 밸런스 패치는 개발사
|
||||
10v10 대규모 멀티플레이어 매치 데이터를 분석한 결과, NATO와 PACT 진영 간의 플레이 비중과 승률은 플레이어의 숙련도가 높아질수록 균형을 이루는 경향을 보입니다 [4], [3]. 특정 진영만을 선호하는 플레이어(소위 'Pactoid' 또는 'Natoid')들의 데이터를 비교해보아도, 게임 시스템 자체가 특정 진영에 압도적인 우위를 제공하지 않음이 확인되었습니다 [5], [3]. 즉, 진영의 승률 차이는 팩션 자체의 불균형보다는 플레이어들의 전반적인 경험치와 실력 차이에서 기인하는 것으로 분석됩니다 [4].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[텔레메트리 (Telemetry)]], [[NDF (Neutral Data Format)]], [[가용성 (Availability)]]
|
||||
- **Projects/Contexts:** [[WARNO 10v10 멀티플레이어 통계 분석]]
|
||||
- **Related Topics:** [[텔레메트리 (Telemetry)|텔레메트리 (Telemetry]], NDF (Neutral Data Format), [[가용성 (Availability)|가용성 (Availability]]
|
||||
- **Projects/Contexts:** WARNO 10v10 멀티플레이어 통계 분석
|
||||
- **Contradictions/Notes:** 일부 플레이어들은 잦은 밸런스 변경 및 단위 너프에 피로감을 느끼며 일정 시간 후에는 수치를 고정할 것을 원하기도 하지만 [6], 개발사와 커뮤니티의 분석에 따르면 지속적인 텔레메트리 모니터링을 통한 밸런스 패치야말로 경쟁적인 RTS 게임을 유지하고 지원하기 위한 필수 불가결한 과정입니다 [1], [7].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 모딩(Modding)
|
||||
# [[WARNO|WARNO]] 모딩(Modding)
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 모딩은 게임 소스 코드를 직접 수정하지 않고, Eugen[[ system]]s의 독자적인 스크립트 언어인 NDF(Neutral Data Format) 파일을 편집하여 게임 내 유닛 데이터, 무기 성능, 시각적 묘사 및 사단 편제 등을 변경하는 과정을 의미합니다. 플레이어와 모더들은 공식 도구와 커뮤니티가 개발한 WME(Warno Mod Editor), [[ndf-parse]] 등의 파싱 프로그램을 활용하여 게임의 데이터를 수정할 수 있습니다. 이러한 개방적인 데이터 구조는 현실주의 모드(Reb's FRAGO) 개발이나 새로운 전술적 환경을 구축하는 등 커뮤니티 주도의 확장성을 크게 높여줍니다.
|
||||
## 📌 Brief Summary
|
||||
WARNO의 모딩은 게임 소스 코드를 직접 수정하지 않고, EugenSystems의 독자적인 스크립트 언어인 NDF(Neutral Data Format) 파일을 편집하여 게임 내 유닛 데이터, 무기 성능, 시각적 묘사 및 사단 편제 등을 변경하는 과정을 의미합니다. 플레이어와 모더들은 공식 도구와 커뮤니티가 개발한 WME(Warno Mod Editor), [[ndf-parse|ndf-parse]] 등의 파싱 프로그램을 활용하여 게임의 데이터를 수정할 수 있습니다. 이러한 개방적인 데이터 구조는 현실주의 모드(Reb's FRAGO) 개발이나 새로운 전술적 환경을 구축하는 등 커뮤니티 주도의 확장성을 크게 높여줍니다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **모딩 환경의 기반 및 NDF 시스템**
|
||||
@@ -26,9 +26,9 @@ WARNO의 모딩은 게임 소스 코드를 직접 수정하지 않고, Eugen[[ s
|
||||
이처럼 고도로 모듈화된 데이터 설계 덕분에 커뮤니티는 모든 무기 데이터를 실제 현실의 제원값으로 치환한 'Reb's FRAGO'와 같은 현실주의 지향 모드를 독자적으로 개발할 수 있었습니다 [25]. 이 모드는 무기의 최대 유효 사거리, 발사 속도, 장갑 모델링, 지형에 따른 속도 변경 등 게임의 핵심 메커니즘 데이터를 재설계하여 전술 시뮬레이션의 현실성을 극대화했습니다 [26-28].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[데이터 기반 밸런싱(Data-Driven Balancing)]], [[Iriszoom 엔진]]
|
||||
- **Projects/Contexts:** [[Reb's FRAGO 모드]], [[WME (Warno Mod Editor)]], [[WARNO-DATA Wiki]], [[ndf-parse]]
|
||||
- **Contradictions/Notes:** [[Eugen Systems]]는 기본적인 모딩 매뉴얼과 NDF 참조 가이드를 제공하지만, 정작 수천 개의 NDF 파일 내에 담긴 개별 데이터 속성(Property)에 대한 구체적인 설명은 누락되어 있습니다. 이를 극복하기 위해 커뮤니티 주도로 게임 메커니즘과 단위 데이터를 상세히 분석하여 문서화한 WARNO-DATA GitHub 위키가 만들어졌습니다 [29, 30].
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], 데이터 기반 밸런싱(Data-Driven Balancing), [[Iriszoom 엔진|Iriszoom 엔진]]
|
||||
- **Projects/Contexts:** [[Reb's FRAGO 모드|Reb's FRAGO 모드]], WME (Warno Mod Editor), WARNO-DATA Wiki, [[ndf-parse|ndf-parse]]
|
||||
- **Contradictions/Notes:** [[Eugen Systems|Eugen Systems]]는 기본적인 모딩 매뉴얼과 NDF 참조 가이드를 제공하지만, 정작 수천 개의 NDF 파일 내에 담긴 개별 데이터 속성(Property)에 대한 구체적인 설명은 누락되어 있습니다. 이를 극복하기 위해 커뮤니티 주도로 게임 메커니즘과 단위 데이터를 상세히 분석하여 문서화한 WARNO-DATA GitHub 위키가 만들어졌습니다 [29, 30].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -4,20 +4,20 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 모딩
|
||||
# [[WARNO|WARNO]] 모딩
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO 모딩은 Eugen[[ system]]s의 독자적인 스크립트 언어인 NDF(Neutral Data Format) 파일을 수정하여 게임의 소스 코드 변경 없이 유닛의 성능, 무기 제원, 편제 등을 커스터마이징하는 과정입니다 [1]. 개발사가 공식 모딩 가이드와 생성 도구를 제공하며, 커뮤니티 주도의 다양한 모드 에디터와 데이터 분석 도구가 활성화되어 있습니다 [2-4]. 이를 통해 플레이어는 단순한 수치 조정을 넘어 현실주의 지향 모드 등 자신만의 고유한 전술 시뮬레이션 환경을 데이터 기반으로 직접 구축할 수 있습니다 [4].
|
||||
## 📌 Brief Summary
|
||||
WARNO 모딩은 EugenSystems의 독자적인 스크립트 언어인 NDF(Neutral Data Format) 파일을 수정하여 게임의 소스 코드 변경 없이 유닛의 성능, 무기 제원, 편제 등을 커스터마이징하는 과정입니다 [1]. 개발사가 공식 모딩 가이드와 생성 도구를 제공하며, 커뮤니티 주도의 다양한 모드 에디터와 데이터 분석 도구가 활성화되어 있습니다 [2-4]. 이를 통해 플레이어는 단순한 수치 조정을 넘어 현실주의 지향 모드 등 자신만의 고유한 전술 시뮬레이션 환경을 데이터 기반으로 직접 구축할 수 있습니다 [4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **NDF(Neutral Data Format) 기반의 데이터 구조:** WARNO의 모든 논리적 설계는 NDF 파일 내에 텍스트 기반으로 정의되어 있습니다 [1]. 유닛의 물리적/기술적 속성을 정의하는 `UniteDescriptor.ndf`, 무기의 메커니즘을 설정하는 `WeaponDescriptor.ndf`, 탄약의 타격 로직과 관통력을 결정하는 `Ammunition.ndf`, 그리고 사단 구성 및 가용성을 다루는 `Divisions.ndf` 등을 통해 유닛 데이터와 게임 코드가 분리되어 체계적으로 관리됩니다 [1, 5-7].
|
||||
* **모드 생성 및 작업 프로세스:** 모드 생성은 게임 내의 `Mods` 폴더에서 `CreateNewMod.bat` 배치 파일에 모드 이름을 인수로 입력 및 실행하여 시작할 수 있습니다 [3]. 이 과정을 거치면 `CommonData`, `GameData` 디렉터리와 함께 `GenerateMod.bat`, `UpdateMod.bat` 등의 필수 스크립트가 포함된 모드 폴더가 생성됩니다 [8]. 생성된 모드 내에서 유닛 구성, 활성화 포인트, 가용성을 수정하거나 `DivisionRules.ndf`, `DivisionCostMatrix.ndf` 파일 등을 편집하여 새로운 유닛 및 사단을 추가할 수 있으며, 새로운 3D 모델(.fbx) 묘사를 연결하는 것도 가능합니다 [5, 9-11].
|
||||
* **모딩 도구 및 커뮤니티 지원:** .ndf 파일을 편집하기 위해서는 텍스트 편집기(Notepad++, Sublime Text 등)와 함께 각 요소에 고유 식별자를 부여하기 위한 GUID 생성기가 필요합니다 [12]. 커뮤니티에서는 이러한 기능들을 통합하여 시각적 편집을 돕는 WME(Warno Mod Editor)를 제작하여 지원하고 있습니다 [2, 13]. 또한, GitHub의 'WARNO-DATA' 위키나 '[[Warno-Armory]]', '[[War-Yes]]' 등의 데이터 파싱 도구를 통해 공식 문서에 누락된 숨겨진 데이터 구조를 파악하고 모딩에 활용할 수 있습니다 [4, 13, 14].
|
||||
* **모딩 도구 및 커뮤니티 지원:** .ndf 파일을 편집하기 위해서는 텍스트 편집기(Notepad++, Sublime Text 등)와 함께 각 요소에 고유 식별자를 부여하기 위한 GUID 생성기가 필요합니다 [12]. 커뮤니티에서는 이러한 기능들을 통합하여 시각적 편집을 돕는 WME(Warno Mod Editor)를 제작하여 지원하고 있습니다 [2, 13]. 또한, GitHub의 'WARNO-DATA' 위키나 '[[Warno-Armory|Warno-Armory]]', '[[War-Yes|War-Yes]]' 등의 데이터 파싱 도구를 통해 공식 문서에 누락된 숨겨진 데이터 구조를 파악하고 모딩에 활용할 수 있습니다 [4, 13, 14].
|
||||
* **대표적인 모딩 사례:** 커뮤니티 모드인 'Reb's FRAGO'는 현실주의(Realism)를 지향하여 게임 내 모든 무기 데이터를 실제 제원값으로 치환하고 시뮬레이션의 시간 축과 경제 시스템을 재설계하는 등 데이터 기반 설계를 극한으로 활용한 대표적인 모딩 사례입니다 [4].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[데이터 기반 설계 (Data-Driven Design)]], [[Iriszoom 엔진]]
|
||||
- **Projects/Contexts:** [[Reb's FRAGO 모드]], [[WME (Warno Mod Editor)]], [[WARNO-DATA 위키]]
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], 데이터 기반 설계 (Data-Driven Design), [[Iriszoom 엔진|Iriszoom 엔진]]
|
||||
- **Projects/Contexts:** [[Reb's FRAGO 모드|Reb's FRAGO 모드]], WME (Warno Mod Editor), WARNO-DATA 위키
|
||||
- **Contradictions/Notes:** WARNO의 NDF 파일 시스템은 세부적인 데이터 접근성을 제공하지만, 무기의 관통력과 같은 특정 데이터 값이 단일 무기 파일에만 명시된 것이 아니라 손상 계통(Family)을 지정하는 복잡한 참조 구조(`DamageResistanceFamilyListImpl.ndf` 등)로 얽혀 있어 모더들이 원하는 값을 찾고 수정하는 데 혼란을 겪기도 합니다 [15, 16].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,20 +4,20 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 밸런싱 및 사단 시스템
|
||||
# [[WARNO|WARNO]] 밸런싱 및 사단 시스템
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 밸런싱 및 사단 시스템은 역사적 군 편제(TO&E) 데이터와 텔레메트리(Telemetry) 분석을 결합하여 전술적 깊이를 부여하는 핵심 설계 요소입니다. 플레이어는 모든 분야에서 완벽한 유닛 조합을 갖추는 대신 강점과 약점이 명확히 설정된 사단 단위의 덱을 구성해야 하며, 이는 다양한 전술과 팀플레이를 유도합니다. 개발사인 Eugen[[ system]]s는 커뮤니티의 주관적 여론보다는 유닛 선택률과 실제 승률 등 객관적 통계 데이터를 기반으로 NDF 파일 수치를 조정하며 지속적인 밸런싱을 수행합니다.
|
||||
## 📌 Brief Summary
|
||||
WARNO의 밸런싱 및 사단 시스템은 역사적 군 편제(TO&E) 데이터와 텔레메트리(Telemetry) 분석을 결합하여 전술적 깊이를 부여하는 핵심 설계 요소입니다. 플레이어는 모든 분야에서 완벽한 유닛 조합을 갖추는 대신 강점과 약점이 명확히 설정된 사단 단위의 덱을 구성해야 하며, 이는 다양한 전술과 팀플레이를 유도합니다. 개발사인 EugenSystems는 커뮤니티의 주관적 여론보다는 유닛 선택률과 실제 승률 등 객관적 통계 데이터를 기반으로 NDF 파일 수치를 조정하며 지속적인 밸런싱을 수행합니다.
|
||||
|
||||
## 📖 Core Content
|
||||
- **사단(Division) 기반 덱 구성의 구조적 제약:** 과거작인 Wargame: Red Dragon의 무제한적인 국가별 덱(National Deck) 시스템과 달리, WARNO는 역사적 사단 편제를 기반으로 유닛을 제한합니다 [1], [2], [3]. 특정 사단은 우수한 보병을 갖춘 대신 최상급 전차가 없거나, 강력한 기갑 전력을 보유한 대신 대공이나 보병이 취약한 식의 구조적 강점과 약점을 가집니다 [2], [3], [4]. 이를 통해 플레이어는 특정 분야에 특화된 전술을 고민해야 하며, 모든 역할을 완벽히 수행하는 '무적의 메타 덱' 생성이 방지됩니다 [2], [5], [4].
|
||||
- **유닛 가용성(Availability)과 베테랑(Veterancy) 시스템을 통한 밸런싱:** 각 유닛의 가치는 사단 내에서의 '가용성' 데이터를 통해 조율됩니다 [6]. 고성능 초중전차(예: M1A1 HA Abrams, T-80UD)나 정예 특수부대는 카드당 제공되는 유닛 수가 극히 제한적이며 활성화 포인트와 배치 비용이 비싸게 책정되어 손실을 철저히 관리해야 합니다 [7], [8], [9], [6]. 반면, 예비군(Reservist)이나 구식 장비는 능력치가 떨어지지만 높은 가용성과 저렴한 비용으로 소모전과 전선 유지에 유리하도록 설계되었습니다 [10], [11], [12], [6]. 또한, 플레이어가 유닛의 숙련도(Veterancy)를 높게 설정할수록 명중률, 연사력, 제압 저항력 등 성능이 향상되는 대신 맵에 배치할 수 있는 최대 유닛 수가 감소하여 밸런스가 유지됩니다 [13], [14], [15].
|
||||
- **텔레메트리(Telemetry) 기반 객관적 데이터 패치:** [[Eugen Systems]]는 커뮤니티의 불만이나 여론에만 의존하지 않고 텔레메트리를 통해 유저들의 실제 유닛 픽률(Pick Rate), 교전 승률, 킬/데스 비율, 평균 생존 시간 등의 데이터를 은밀히 수집합니다 [16], [6]. 이 분석 결과를 토대로 유닛의 포인트 비용, 장전 시간, 조준 시간, 장갑 관통력 등을 재책정하며, 이러한 변경 사항은 게임의 논리적 설계가 담긴 NDF(Neutral Data Format) 파일을 수정함으로써 전장에 즉각적으로 반영됩니다 [17], [18], [19].
|
||||
- **텔레메트리(Telemetry) 기반 객관적 데이터 패치:** [[Eugen Systems|Eugen Systems]]는 커뮤니티의 불만이나 여론에만 의존하지 않고 텔레메트리를 통해 유저들의 실제 유닛 픽률(Pick Rate), 교전 승률, 킬/데스 비율, 평균 생존 시간 등의 데이터를 은밀히 수집합니다 [16], [6]. 이 분석 결과를 토대로 유닛의 포인트 비용, 장전 시간, 조준 시간, 장갑 관통력 등을 재책정하며, 이러한 변경 사항은 게임의 논리적 설계가 담긴 NDF(Neutral Data Format) 파일을 수정함으로써 전장에 즉각적으로 반영됩니다 [17], [18], [19].
|
||||
- **통계에 기반한 진영 간 균형(Faction Balance):** 플레이어 간에는 항상 진영 편향(NATO 또는 PACT가 더 유리하다는 주장)에 대한 논쟁이 있으나, 실제 10v10 대규모 멀티플레이어 데이터를 분석한 결과 게임 시스템 자체에 특정 진영에 대한 압도적인 우위는 발견되지 않았습니다 [20], [21], [19]. 승률의 차이는 주로 플레이어의 전술적 숙련도 차이 및 양 진영 플레이어들의 경험치 풀(Pact를 선호하는 유저들의 평균 플레이 횟수가 약간 더 높음)에서 비롯된 것으로 분석되며, 기본적으로 진영 간 밸런스는 견고하게 유지되고 있습니다 [22], [21].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[텔레메트리 (Telemetry)]], [[NDF (Neutral Data Format)]], [[Iriszoom 엔진]]
|
||||
- **Projects/Contexts:** [[Eugen Systems의 데이터 기반 설계]]
|
||||
- **Related Topics:** [[텔레메트리 (Telemetry)|텔레메트리 (Telemetry]], NDF (Neutral Data Format), [[Iriszoom 엔진|Iriszoom 엔진]]
|
||||
- **Projects/Contexts:** Eugen Systems의 데이터 기반 설계
|
||||
- **Contradictions/Notes:** 국가 기반 덱 시스템(WGRD)을 선호하는 일부 유저들은 현재의 사단 시스템이 유닛 구성의 자유도와 창의성을 크게 제한한다고 불만을 표출합니다 [23], [24]. 반면, 이를 옹호하는 유저들은 사단 시스템이 소수의 유닛에만 의존하는 메타 고착화를 방지하고 훨씬 더 다채롭고 밸런스 잡힌 게임플레이를 가능하게 한다고 반박합니다 [25], [2], [5].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,20 +4,20 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 사후 관리 (Post-Launch [[Management]])
|
||||
# [[WARNO|WARNO]] 사후 관리 (Post-Launch [[Management|Management]])
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
## 📌 Brief Summary
|
||||
WARNO의 사후 관리는 단순히 유저 커뮤니티의 여론에 의존하는 것이 아니라, 수집된 객관적인 텔레메트리(Telemetry) 데이터를 기반으로 정밀하게 밸런싱을 수행하는 과정을 의미합니다 [1, 2]. 플레이어의 유닛 선택 빈도(Pick rate), 승률, 킬/데스 비율 등의 실시간 데이터를 분석하여 NDF 파일의 수치를 지속적으로 패치합니다 [2]. 이러한 데이터 중심의 사후 지원은 게임을 단순한 정적 시뮬레이션이 아닌 살아있는 전술 생태계로 유지하는 핵심 동력으로 작용합니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **텔레메트리(Telemetry) 기반 밸런싱**: Eugen[[ system]]s는 게임 출시 후 텔레메트리 시스템을 통해 플레이어들의 유닛 사용 방식, 선택 빈도(Pick rate), 실제 교전에서의 승률, 킬/데스 비율, 평균 생존 시간 등을 실시간으로 기록 및 모니터링합니다 [1, 2]. 이는 변덕스럽고 비전문적인 커뮤니티 불만에만 의존하지 않고, 객관적인 데이터를 바탕으로 유닛의 실제 성능을 파악하여 패치를 진행하기 위함입니다 [1, 2].
|
||||
* **텔레메트리(Telemetry) 기반 밸런싱**: EugenSystems는 게임 출시 후 텔레메트리 시스템을 통해 플레이어들의 유닛 사용 방식, 선택 빈도(Pick rate), 실제 교전에서의 승률, 킬/데스 비율, 평균 생존 시간 등을 실시간으로 기록 및 모니터링합니다 [1, 2]. 이는 변덕스럽고 비전문적인 커뮤니티 불만에만 의존하지 않고, 객관적인 데이터를 바탕으로 유닛의 실제 성능을 파악하여 패치를 진행하기 위함입니다 [1, 2].
|
||||
* **밸런스 조정의 주요 데이터 변수**: 수집된 텔레메트리 데이터 분석 결과를 바탕으로 개발사는 NDF 파일 내의 수치를 직접 수정합니다 [2]. 유닛의 포인트 비용(Point Cost) 재책정, 장전 시간·조준 시간·관통력 수치 등 무장 세부 스펙의 미세 조정, 전술적 역할을 강화하기 위한 새로운 특성(Trait) 할당, 그리고 특정 사단의 승률을 보완하기 위한 보조 유닛 카드 추가 및 가용성 상향 등이 주요 밸런스 변수로 작용합니다 [4].
|
||||
* **전문 테스터 및 커뮤니티 피드백의 교차 검증**: 개발사는 객관적인 텔레메트리 데이터뿐만 아니라 전문 테스터들의 피드백과 커뮤니티 미디어에서 제기되는 의견들의 요약본을 수집합니다 [1]. 이후 해당 피드백이 실제로 유의미한지 텔레메트리 데이터와 비교·대조하여 조정을 진행합니다 [1].
|
||||
* **상호 연결된 데이터 생태계 관리**: WARNO의 데이터는 긴밀하게 연결되어 있어, 수송 트럭의 도로 이동 속도와 같은 단순한 수치 하나를 변경하더라도 해당 트럭을 사용하는 모든 유닛에 미치는 가치 변화와 이를 대체할 수 있는 다른 유닛들의 기회비용까지 모두 고려하여 밸런싱을 진행해야 합니다 [3]. 이렇듯 끊임없는 경쟁 플레이를 위한 엄격한 데이터 기반의 밸런싱 작업이 게임에 대한 지속적인 사후 지원을 의미합니다 [3, 4].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[텔레메트리 데이터 (Telemetry Data)]], [[NDF (Neutral Data Format)]], [[데이터 기반 밸런싱 (Data-Driven Balancing)]]
|
||||
- **Projects/Contexts:** [[WARNO 멀티플레이어 및 경쟁 플레이 밸런스 패치]]
|
||||
- **Related Topics:** [[텔레메트리 데이터 (Telemetry Data)|텔레메트리 데이터 (Telemetry Data]], NDF (Neutral Data Format), [[데이터 기반 밸런싱 (Data-Driven Balancing)|데이터 기반 밸런싱 (Data-Driven Balancing]]
|
||||
- **Projects/Contexts:** [[WARNO 멀티플레이어 및 경쟁 플레이 밸런스 패치|WARNO 멀티플레이어 및 경쟁 플레이 밸런스 패치]]
|
||||
- **Contradictions/Notes:** 사후 밸런싱은 주로 커뮤니티의 단순한 불만에 휘둘리기보다 객관적인 텔레메트리 데이터를 우선시한다고 명시되어 있으나, 전문 테스터 및 유저 커뮤니티의 피드백을 완전히 배제하는 것은 아니며 이를 수집해 실제 데이터와 교차 검증하는 과정을 반드시 거칩니다 [1].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,9 +4,9 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 실시간 전술(Real-time Tactics) 및 Army General 캠페인
|
||||
# [[WARNO|WARNO]] 실시간 전술(Real-time Tactics) 및 Army General 캠페인
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
## 📌 Brief Summary
|
||||
WARNO는 1989년의 가상 제3차 세계대전을 배경으로 하는 실시간 전술(Real-time Tactics) 및 턴제 전략 하이브리드 게임이다 [1, 2]. 실시간 전술 전투에서는 다양한 병과를 조율하는 제병협동 전술이 요구되며, 시야, 사거리, 제압, 장갑 관통 등 정교한 데이터 기반 시스템이 작용한다 [3-6]. 'Army General'로 불리는 턴제 캠페인 모드는 대대급 부대를 전략 맵에서 운용하며 피로도와 보급을 관리하고, 전투 발생 시 자동 전술 계산이나 실시간 직접 전투를 선택하게 함으로써 군사 시뮬레이션의 깊이를 더한다 [7-9].
|
||||
|
||||
## 📖 Core Content
|
||||
@@ -17,14 +17,14 @@ WARNO는 1989년의 가상 제3차 세계대전을 배경으로 하는 실시간
|
||||
* 유닛들은 제압(Suppression)과 응집력(Cohesion) 데이터를 통해 심리적 타격을 시뮬레이션하며, 사격이나 폭발의 영향을 받을 시 명중률과 이동 속도가 저하되는 등 데이터가 유닛의 전술적 행동에 직접적인 영향을 미친다 [6, 17, 18].
|
||||
|
||||
* **Army General 캠페인 (턴제 전략 요소):**
|
||||
* 캠페인은 보드 워게임이나 대전략 게임과 유사한 턴제 기반의 작전술([[Opera]]tional warfare)을 다루며, 플레이어는 대대급 부대를 조작하여 기동한다 [7, 8].
|
||||
* 캠페인은 보드 워게임이나 대전략 게임과 유사한 턴제 기반의 작전술([[Opera|Opera]]tional warfare)을 다루며, 플레이어는 대대급 부대를 조작하여 기동한다 [7, 8].
|
||||
* 각 부대는 행동력(Action Points, AP)을 소모하여 이동하고 전투를 수행하며, 피로도(Fatigue)와 영구적인 병력 및 장비 손실을 관리해야 한다 [7, 19-21]. 보급선 차단 및 포위를 통해 적의 피로도 회복을 막는 전략적 기동도 중요하다 [22, 23].
|
||||
* 전략 맵에서 교전이 발생하면, 플레이어는 각 전투의 승률(비율)을 바탕으로 이를 자동 전투(Autoresolve)로 넘기거나 전술 맵에서 직접 실시간 전투를 지휘할 수 있다 [7, 8, 24].
|
||||
* 이 모든 캠페인 시스템과 교전 규칙 역시 실제 냉전 교리와 사단 편제표(TO&E)를 고도의 데이터 아키텍처로 체계화한 결과물이다 [9].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[제병협동 전술 (Combined Arms)]], [[텔레메트리 밸런싱 (Telemetry Balancing)]]
|
||||
- **Projects/Contexts:** [[Eugen[[ system]]s의 Iriszoom 엔진 및 전략 게임 개발]]
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], 제병협동 전술 (Combined Arms), [[텔레메트리 밸런싱 (Telemetry Balancing)|텔레메트리 밸런싱 (Telemetry Balancing]]
|
||||
- **Projects/Contexts:** [[Eugen Systems의 Iriszoom 엔진 및 전략 게임 개발|EugenSystems의 Iriszoom 엔진 및 전략 게임 개발]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 WARNO의 실시간 전술 전투와 전략 캠페인은 각각 고유한 복잡성을 지니나, 이 두 시스템 모두 역사적 제원과 편제를 반영하는 강력한 '데이터 기반 설계'를 통해 상호 연결되어 전술적 일관성을 유지한다 [9]. 다만 AI의 성능과 관련하여, 전략 맵(Army General)에서는 상대의 약점을 찌르거나 포위를 훌륭하게 수행하지만 실시간 전술 전투에서는 지형을 무시하고 예측 가능하게 전차를 일렬로 밀어붙이는 경향이 있어 한계로 지적된다 [25-27].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,16 +4,16 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 전술 시뮬레이션 시스템
|
||||
# [[WARNO|WARNO]] 전술 시뮬레이션 시스템
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
## 📌 Brief Summary
|
||||
WARNO의 전술 시뮬레이션 시스템은 냉전 시대의 군사 교리와 장비 제원을 '데이터 기반 설계(Data-Driven Design)' 철학 아래 통합한 정교한 가상 전장 환경입니다 [1]. 게임 내의 시각적 파괴 효과부터 물리적 충돌, 심리적 제압 및 부대 편제에 이르는 모든 요소가 상호 연결된 데이터 구조 내에서 작동합니다 [1]. 이 시스템은 독자적인 NDF(Neutral Data Format)와 Iriszoom 엔진을 통해 소스 코드 수정 없이도 방대한 전술 데이터와 텔레메트리를 제어하여 고도의 현실감과 전략적 깊이를 구현합니다 [2, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **Iriszoom 엔진과 시각 데이터의 통합**
|
||||
WARNO는 Iriszoom 엔진을 활용하여 광활한 전략적 조감과 개별 유닛 단위의 전술적 줌을 단일 렌더링 파이프라인에서 지원합니다 [2]. **물리 기반 렌더링(PBR) 시스템과 [[Metal]]lic/Roughness 워크플로우를 도입**하여 재질감을 사실적으로 구현했으며, 유닛 파괴 시 탄약고 유폭에 의한 포탑 사출과 같은 물리적 현상을 유닛의 상태 데이터와 동기화하여 '영속적 전장(Persistent Battlefield)'을 만들어 냅니다 [2, 4].
|
||||
WARNO는 Iriszoom 엔진을 활용하여 광활한 전략적 조감과 개별 유닛 단위의 전술적 줌을 단일 렌더링 파이프라인에서 지원합니다 [2]. **물리 기반 렌더링(PBR) 시스템과 [[Metal|Metal]]lic/Roughness 워크플로우를 도입**하여 재질감을 사실적으로 구현했으며, 유닛 파괴 시 탄약고 유폭에 의한 포탑 사출과 같은 물리적 현상을 유닛의 상태 데이터와 동기화하여 '영속적 전장(Persistent Battlefield)'을 만들어 냅니다 [2, 4].
|
||||
|
||||
* **[[NDF (Neutral Data Format)]] 스크립트 아키텍처**
|
||||
* **[[NDF (Neutral Data Format)|NDF (Neutral Data Format]] 스크립트 아키텍처**
|
||||
게임의 모든 논리적 설계는 텍스트 기반 언어인 **NDF 내에 정의되어 있어 게임 코드와 데이터 값이 엄격히 분리**됩니다 [3]. `UniteDescriptor.ndf` (물리/기술 속성), `WeaponDescriptor.ndf` (무기 메커니즘), `Ammunition.ndf` (탄약 타격 로직) 등을 통해 모듈화된 디스크립터를 조립하여 유닛을 생성합니다 [3, 5]. 이 구조는 수천 개의 속성을 체계적으로 관리하며, 신속한 데이터 기반 밸런싱과 유저 모딩을 가능하게 합니다 [3, 5].
|
||||
|
||||
* **수학적 정밀도에 기반한 전투 및 장갑 역학**
|
||||
@@ -23,11 +23,11 @@ WARNO의 전술 시뮬레이션 시스템은 냉전 시대의 군사 교리와
|
||||
유닛들은 500점의 기본 제압 수치를 지니며, 폭발이나 아군 손실 시 수치가 누적되어 '응집력'이 하락합니다 [9]. **제압 상태가 깊어지면 명중률, 재장전 속도, 기동력이 저하**되는 페널티를 받습니다 [9]. 건물(50%) 및 숲(35%)과 같은 지형 데이터는 제압 피해에 대한 저항력을 제공하며, 헌병(Military Police) 특성과 높은 숙련도(Veterancy)는 응집력 회복을 가속하는 등 심리적 전장이 수치화되어 있습니다 [10].
|
||||
|
||||
* **텔레메트리 기반 밸런싱과 모딩 생태계**
|
||||
Eugen[[ system]]s는 커뮤니티의 단순 여론이 아닌 **방대한 텔레메트리(픽률, 승률, 킬/데스 비율 등) 데이터를 실시간으로 분석하여 가격, 무장 스펙, 가용성 등을 정밀하게 조정**합니다 [11, 12]. 또한 게임의 개방적인 데이터 구조를 통해 유저들은 NDF를 직접 수정하여 현실주의 모드(예: Reb's FRAGO)를 만들거나, [[Warno-Armory]] 및 [[War-Yes]]와 같은 데이터 파싱 도구를 제작하여 은닉된 엔진 내부 수치들을 커뮤니티와 공유하고 분석합니다 [13, 14].
|
||||
EugenSystems는 커뮤니티의 단순 여론이 아닌 **방대한 텔레메트리(픽률, 승률, 킬/데스 비율 등) 데이터를 실시간으로 분석하여 가격, 무장 스펙, 가용성 등을 정밀하게 조정**합니다 [11, 12]. 또한 게임의 개방적인 데이터 구조를 통해 유저들은 NDF를 직접 수정하여 현실주의 모드(예: Reb's FRAGO)를 만들거나, [[Warno-Armory|Warno-Armory]] 및 [[War-Yes|War-Yes]]와 같은 데이터 파싱 도구를 제작하여 은닉된 엔진 내부 수치들을 커뮤니티와 공유하고 분석합니다 [13, 14].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Iriszoom 엔진]], [[NDF (Neutral Data Format)]], [[텔레메트리 기반 밸런싱]], [[사단(Division) 덱 시스템]]
|
||||
- **Projects/Contexts:** [[WARNO]], [[Reb's FRAGO 모드]], [[Warno-Armory 및 War-Yes 커뮤니티 도구]]
|
||||
- **Related Topics:** [[Iriszoom 엔진|Iriszoom 엔진]], NDF (Neutral Data Format), 텔레메트리 기반 밸런싱, 사단(Division) 덱 시스템
|
||||
- **Projects/Contexts:** [[WARNO|WARNO]], Reb's FRAGO 모드, Warno-Armory 및 War-Yes 커뮤니티 도구
|
||||
- **Contradictions/Notes:** 커뮤니티 일각에서는 특정 진영(예: Pact)이 편향적으로 유리하다거나, 무기 위력이 비현실적이라는 주관적 불만을 제기하기도 하지만, 개발사와 유저들의 실제 대규모 텔레메트리 데이터 분석 결과에 따르면 시스템 자체의 압도적인 진영 편향은 없으며 숙련도에 따라 승률이 균형을 이루는 것으로 나타납니다 [11, 12, 15, 16].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,9 +4,9 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 전투 메커니즘 (Combat Mechanics)
|
||||
# [[WARNO|WARNO]] 전투 메커니즘 (Combat Mechanics)
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
## 📌 Brief Summary
|
||||
WARNO의 전투 메커니즘은 단순한 난수 생성을 넘어 타겟과의 거리, 지형, 무기 특성이 복합적으로 작용하는 비선형적 알고리즘으로 구성된 시스템이다 [1]. 게임 엔진과 데이터 구조는 관통력, 명중률 등의 물리적 타격 로직부터 전장의 공포를 반영한 심리적 상태까지 모든 것을 정밀한 수치로 치환하여 모사한다 [2, 3]. 이러한 데이터 중심 설계는 플레이어로 하여금 유닛의 기동, 은폐, 사거리 조절을 끊임없이 최적화하도록 요구하는 깊이 있는 전술적 환경을 제공한다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
@@ -17,11 +17,11 @@ WARNO의 전투 메커니즘은 단순한 난수 생성을 넘어 타겟과의
|
||||
* **제압 및 응집력 시스템 (Suppression & Cohesion):**
|
||||
모든 유닛은 500점의 제압 한계 수치를 가지며, 피격되거나 인접 유닛이 손실될 때 제압 수치가 누적된다 [3, 11]. 누적된 제압 수치로 인해 유닛의 응집력(Cohesion) 상태가 하락하면 명중률이 감소할 뿐만 아니라 이동 속도와 연사 속도에 최대 50%의 심각한 페널티가 부과된다 [3, 12]. 장갑 수치 1당 제압 피해를 5% 흡수할 수 있으며, 헌병(Military Police) 특성 오라나 건물(50% 저항력), 숲(35% 저항력) 등의 지형 데이터는 심리적 타격에 대한 강력한 방어 및 회복력을 제공한다 [11-13].
|
||||
* **정찰과 은신 (Recon & Stealth):**
|
||||
은신 탐지 알고리즘은 관측 유닛의 '광학(Optics)' 수치와 타겟 유닛의 '은신(Stealth)' 수치의 상호작용으로 결정된다 [13]. 보병 유닛이 건물에 들어가면 3.75배, 숲에 들어가면 2.75배의 은신 승수를 얻어 탐지가 극히 어려워진다 [14, 15]. 그러나 무기를 발사할 경우 해당 무기에 설정된 '소음([[Noise]])' 수치만큼 은신 데이터가 일시적으로 삭감되어, 적의 정찰망에 강제로 노출되는 리스크가 발생한다 [15].
|
||||
은신 탐지 알고리즘은 관측 유닛의 '광학(Optics)' 수치와 타겟 유닛의 '은신(Stealth)' 수치의 상호작용으로 결정된다 [13]. 보병 유닛이 건물에 들어가면 3.75배, 숲에 들어가면 2.75배의 은신 승수를 얻어 탐지가 극히 어려워진다 [14, 15]. 그러나 무기를 발사할 경우 해당 무기에 설정된 '소음([[Noise|Noise]])' 수치만큼 은신 데이터가 일시적으로 삭감되어, 적의 정찰망에 강제로 노출되는 리스크가 발생한다 [15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Iriszoom 엔진]], [[NDF (Neutral Data Format)]], [[데이터 기반 밸런싱]]
|
||||
- **Projects/Contexts:** [[Warno 데이터 기반 설계]]
|
||||
- **Related Topics:** [[Iriszoom 엔진|Iriszoom 엔진]], NDF (Neutral Data Format), [[데이터 기반 밸런싱|데이터 기반 밸런싱]]
|
||||
- **Projects/Contexts:** [[WARNO 데이터 기반 설계|Warno 데이터 기반 설계]]
|
||||
- **Contradictions/Notes:** 항공기에 대한 대공 미사일 공격 시, 일부 유저 커뮤니티는 ECM 계산이 방어력을 차감하는 방식일 것으로 예측했으나, NDF 데이터 상 ECM은 명중률에 곱해지는 승수적 삭감($BaseAccuracy \times (1 - ECM)$) 로직으로 작동한다는 것이 확인된다 [5, 16]. 또한 구형 매뉴얼에는 장갑 1당 제압 피해가 5%씩 감소한다고 명시되어 있으나, ATGM에 피격된 전차의 실제 제압 피해를 분석해 본 결과 유닛 시트에 기록된 데이터와 일치하지 않는 비정상적인 수치가 적용되는 등 일부 게임 내 구현과 데이터 기술 간의 괴리가 보고되기도 한다 [11].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,21 +4,21 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 커뮤니티 데이터 도구 생태계
|
||||
# [[WARNO|WARNO]] 커뮤니티 데이터 도구 생태계
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
## 📌 Brief Summary
|
||||
WARNO 커뮤니티 데이터 도구 생태계는 유저들이 게임 내 숨겨진 데이터를 추출, 분석, 시각화하여 전술적 이해도를 높이기 위해 자발적으로 구축한 다양한 서드파티 플랫폼과 파싱 도구들의 집합을 의미합니다 [1]. 이 생태계는 NDF 파일 기반의 게임 구조를 역설계하여 인게임 UI에서 제공되지 않는 은닉 데이터를 제공하며, 데이터의 민주화를 통해 유저들이 게임 역학을 깊이 이해하고 정교한 덱 빌딩과 전술을 수립할 수 있도록 지원합니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **데이터 추출 및 시각화 플랫폼 ([[Warno-Armory]] & [[War-Yes]]):** 유저들은 NDF 파일을 직접 읽어 분석하거나 AI 텍스트 파서를 활용하는 웹사이트를 개발했습니다 [3, 4]. 'War-Yes'는 유닛을 검색, 정렬, 필터링하고 차트를 통해 상호 비교할 수 있게 해주며, 숨겨진 명중률 곡선 등을 시각화하여 제공합니다 [1, 5]. 'Warno-Armory'는 실제 NDF 파일 파싱을 기반으로 무기 체계의 상세 로직과 AI 표적 우선순위에 영향을 미치는 '위험도(Dangerousness)' 같은 숨겨진 통계를 추출하여 제공하며, 게임 패치 직후 신속하게 최신 데이터가 반영되는 강점이 있습니다 [1, 6, 7].
|
||||
* **리플레이 및 전투력 분석 도구 ([[WARPLAN]] & WARCAL):** 'WARPLAN'은 1v1 멀티플레이어 게임의 리플레이 파일(.rpl)과 게임 종료 화면의 스크린샷(OCR 활용)을 분석하여 시간 경과에 따른 유닛 구매 내역 및 AP(활성화 포인트) 손실 타임라인을 구축하는 도구입니다 [1, 8]. 'WARCAL' 알고리즘은 유닛의 전투력을 생존성, 대장갑 살상력, 대보병 살상력, 대공 살상력, 주도권 등 5가지 지표로 정량화하여 유닛 및 진영 간의 고차원적인 객관적 비교를 지원합니다 [9].
|
||||
* **모딩 및 NDF 파싱 도구 (WME & [[ndf-parse]]):** WARNO의 스크립트 언어인 NDF 파일을 해독하고 수정하기 위한 도구들도 커뮤니티 주도로 활발히 개발되었습니다. 'Warno Mod Editor (WME)'는 통합 GUID 생성기를 포함하여 NDF 파일의 시각적 편집을 돕는 도구로, 높은 접근성을 통해 모드 제작을 지원합니다 [1, 10]. 또한, Python 기반의 'ndf-parse' 패키지는 NDF 파일을 구문 분석하고 수정된 코드를 다시 유효한 NDF 코드로 작성할 수 있게 해주는 유틸리티입니다 [11].
|
||||
* **종합 위키 및 문서화 프로젝트 (WARNO-DATA):** GitHub에서 운영되는 'WARNO-DATA' 프로젝트는 Eugen[[ system]]s의 수천 개의 NDF 파일(UniteDescriptor.ndf, WeaponDescriptor.ndf 등)에 분산된 데이터를 체계적으로 문서화한 위키입니다 [12-14]. 피해량 및 정확도 계산과 같은 핵심 게임 메커니즘에 대한 심층적인 통찰력과 데이터 딕셔너리를 커뮤니티에 제공합니다 [13, 15].
|
||||
* **데이터 추출 및 시각화 플랫폼 ([[Warno-Armory|Warno-Armory]] & [[War-Yes|War-Yes]]):** 유저들은 NDF 파일을 직접 읽어 분석하거나 AI 텍스트 파서를 활용하는 웹사이트를 개발했습니다 [3, 4]. 'War-Yes'는 유닛을 검색, 정렬, 필터링하고 차트를 통해 상호 비교할 수 있게 해주며, 숨겨진 명중률 곡선 등을 시각화하여 제공합니다 [1, 5]. 'Warno-Armory'는 실제 NDF 파일 파싱을 기반으로 무기 체계의 상세 로직과 AI 표적 우선순위에 영향을 미치는 '위험도(Dangerousness)' 같은 숨겨진 통계를 추출하여 제공하며, 게임 패치 직후 신속하게 최신 데이터가 반영되는 강점이 있습니다 [1, 6, 7].
|
||||
* **리플레이 및 전투력 분석 도구 ([[WARPLAN|WARPLAN]] & WARCAL):** 'WARPLAN'은 1v1 멀티플레이어 게임의 리플레이 파일(.rpl)과 게임 종료 화면의 스크린샷(OCR 활용)을 분석하여 시간 경과에 따른 유닛 구매 내역 및 AP(활성화 포인트) 손실 타임라인을 구축하는 도구입니다 [1, 8]. 'WARCAL' 알고리즘은 유닛의 전투력을 생존성, 대장갑 살상력, 대보병 살상력, 대공 살상력, 주도권 등 5가지 지표로 정량화하여 유닛 및 진영 간의 고차원적인 객관적 비교를 지원합니다 [9].
|
||||
* **모딩 및 NDF 파싱 도구 (WME & [[ndf-parse|ndf-parse]]):** WARNO의 스크립트 언어인 NDF 파일을 해독하고 수정하기 위한 도구들도 커뮤니티 주도로 활발히 개발되었습니다. 'Warno Mod Editor (WME)'는 통합 GUID 생성기를 포함하여 NDF 파일의 시각적 편집을 돕는 도구로, 높은 접근성을 통해 모드 제작을 지원합니다 [1, 10]. 또한, Python 기반의 'ndf-parse' 패키지는 NDF 파일을 구문 분석하고 수정된 코드를 다시 유효한 NDF 코드로 작성할 수 있게 해주는 유틸리티입니다 [11].
|
||||
* **종합 위키 및 문서화 프로젝트 (WARNO-DATA):** GitHub에서 운영되는 'WARNO-DATA' 프로젝트는 EugenSystems의 수천 개의 NDF 파일(UniteDescriptor.ndf, WeaponDescriptor.ndf 등)에 분산된 데이터를 체계적으로 문서화한 위키입니다 [12-14]. 피해량 및 정확도 계산과 같은 핵심 게임 메커니즘에 대한 심층적인 통찰력과 데이터 딕셔너리를 커뮤니티에 제공합니다 [13, 15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[데이터 기반 설계(Data-Driven Design)]], [[은신과 광학 메커니즘(Stealth and Optics Mechanics)]]
|
||||
- **Projects/Contexts:** [[War-Yes 및 Warno-Armory 플랫폼]], [[WARPLAN 리플레이 분석기]], [[Warno Mod Editor (WME)]], [[WARNO-DATA GitHub 프로젝트]]
|
||||
- **Contradictions/Notes:** 게임 개발사인 [[Eugen Systems]]는 인게임 무기고나 UI를 통해 모든 데이터를 공개하지 않지만(연사 준비 시간, 위험도 등 은닉 데이터 존재), 커뮤니티는 NDF 파싱 도구를 통해 이러한 데이터를 스스로 발굴하고 공유하여 전술 최적화에 적극적으로 활용하고 있습니다 [1, 7, 16].
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], 데이터 기반 설계(Data-Driven Design), 은신과 광학 메커니즘(Stealth and Optics Mechanics
|
||||
- **Projects/Contexts:** War-Yes 및 Warno-Armory 플랫폼, WARPLAN 리플레이 분석기, Warno Mod Editor (WME), WARNO-DATA GitHub 프로젝트
|
||||
- **Contradictions/Notes:** 게임 개발사인 [[Eugen Systems|Eugen Systems]]는 인게임 무기고나 UI를 통해 모든 데이터를 공개하지 않지만(연사 준비 시간, 위험도 등 은닉 데이터 존재), 커뮤니티는 NDF 파싱 도구를 통해 이러한 데이터를 스스로 발굴하고 공유하여 전술 최적화에 적극적으로 활용하고 있습니다 [1, 7, 16].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -4,21 +4,21 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]] 커뮤니티 모딩 생태계
|
||||
# [[WARNO|WARNO]] 커뮤니티 모딩 생태계
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 커뮤니티 모딩 생태계는 게임의 개방적인 데이터 설계(NDF 시스템)를 바탕으로 유저들이 직접 게임 내 수치와 메커니즘을 분석, 수정, 공유하며 발전시키는 지식 및 창작 환경을 의미합니다 [1, 2]. 개발사인 Eugen[[ system]]s가 공식 모딩 가이드와 편집 도구를 제공하여 데이터 접근성을 높였으며, 이를 통해 유저들은 현실주의 모드 개발, 데이터 파싱 도구 제작, 통합 데이터베이스 구축 등 활발한 활동을 이어가고 있습니다 [2-4]. 이는 WARNO가 단순한 정적 게임을 넘어 유저 커뮤니티와 함께 호흡하며 진화하는 확장 가능한 전술 시뮬레이션 플랫폼으로 기능하게 합니다 [5, 6].
|
||||
## 📌 Brief Summary
|
||||
WARNO의 커뮤니티 모딩 생태계는 게임의 개방적인 데이터 설계(NDF 시스템)를 바탕으로 유저들이 직접 게임 내 수치와 메커니즘을 분석, 수정, 공유하며 발전시키는 지식 및 창작 환경을 의미합니다 [1, 2]. 개발사인 EugenSystems가 공식 모딩 가이드와 편집 도구를 제공하여 데이터 접근성을 높였으며, 이를 통해 유저들은 현실주의 모드 개발, 데이터 파싱 도구 제작, 통합 데이터베이스 구축 등 활발한 활동을 이어가고 있습니다 [2-4]. 이는 WARNO가 단순한 정적 게임을 넘어 유저 커뮤니티와 함께 호흡하며 진화하는 확장 가능한 전술 시뮬레이션 플랫폼으로 기능하게 합니다 [5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
* **개방적인 데이터 접근성 및 공식 지원:** [[Eugen Systems]]는 NDF(Neutral Data Format) 파일 구조를 통해 유저들이 게임의 핵심 소스 코드를 건드리지 않고도 유닛의 성능, 명중률, 관통력 등을 미세 조정할 수 있도록 개방적인 환경을 제공합니다 [1, 7]. 공식적인 모딩 매뉴얼과 `CreateNewMod.bat` 등의 스크립트를 기본 제공하여, 유저가 쉽게 자신만의 모드 디렉토리를 생성하고 `Divisions.ndf`, `DivisionRules.ndf`, `UniteDescriptor.ndf` 등의 파일을 수정할 수 있도록 지원하고 있습니다 [3, 4, 8-10].
|
||||
* **데이터 파싱 및 커뮤니티 도구의 발달:** 복잡한 NDF 파일을 효율적으로 다루기 위해 유저 커뮤니티는 독자적인 파싱 및 편집 도구를 자체 개발했습니다. Python 기반의 `[[ndf-parse]]` 패키지를 비롯하여 [11, 12], 고유 ID(GUID) 생성기가 통합된 전용 에디터인 '[[WME (Warno Mod Editor)]]' 등이 제작되어 모딩에 대한 진입 장벽을 낮추었습니다 [2, 13].
|
||||
* **메타 데이터베이스 및 분석 도구 구축:** 숨겨진 게임 엔진 내부의 수치들을 파싱하여 시각화하는 '[[Warno-Armory]]', '[[War-Yes]]'와 같은 웹 기반 데이터베이스 사이트가 유저들에 의해 구축되었습니다 [2, 14-17]. 또한 리플레이 데이터 파일(.rpl)과 스크린샷을 분석하여 유닛의 생존성, 살상력 등을 시계열로 추적하는 '[[WARPLAN]]'과 같은 전술 분석 도구도 커뮤니티 주도로 활발히 운영되고 있습니다 [2, 18-20].
|
||||
* **개방적인 데이터 접근성 및 공식 지원:** [[Eugen Systems|Eugen Systems]]는 NDF(Neutral Data Format) 파일 구조를 통해 유저들이 게임의 핵심 소스 코드를 건드리지 않고도 유닛의 성능, 명중률, 관통력 등을 미세 조정할 수 있도록 개방적인 환경을 제공합니다 [1, 7]. 공식적인 모딩 매뉴얼과 `CreateNewMod.bat` 등의 스크립트를 기본 제공하여, 유저가 쉽게 자신만의 모드 디렉토리를 생성하고 `Divisions.ndf`, `DivisionRules.ndf`, `UniteDescriptor.ndf` 등의 파일을 수정할 수 있도록 지원하고 있습니다 [3, 4, 8-10].
|
||||
* **데이터 파싱 및 커뮤니티 도구의 발달:** 복잡한 NDF 파일을 효율적으로 다루기 위해 유저 커뮤니티는 독자적인 파싱 및 편집 도구를 자체 개발했습니다. Python 기반의 `[[ndf-parse|ndf-parse]]` 패키지를 비롯하여 [11, 12], 고유 ID(GUID) 생성기가 통합된 전용 에디터인 '[[WME (Warno Mod Editor)|WME (Warno Mod Editor]]' 등이 제작되어 모딩에 대한 진입 장벽을 낮추었습니다 [2, 13].
|
||||
* **메타 데이터베이스 및 분석 도구 구축:** 숨겨진 게임 엔진 내부의 수치들을 파싱하여 시각화하는 '[[Warno-Armory|Warno-Armory]]', 'War-Yes'와 같은 웹 기반 데이터베이스 사이트가 유저들에 의해 구축되었습니다 [2, 14-17]. 또한 리플레이 데이터 파일(.rpl)과 스크린샷을 분석하여 유닛의 생존성, 살상력 등을 시계열로 추적하는 '[[WARPLAN|WARPLAN]]'과 같은 전술 분석 도구도 커뮤니티 주도로 활발히 운영되고 있습니다 [2, 18-20].
|
||||
* **커뮤니티 주도의 지식 문서화(Wiki) 프로젝트:** WARNO의 방대한 유닛 데이터와 수천 개의 NDF 파일에 분산된 게임 메커니즘을 체계적으로 문서화하기 위해 'WARNO-DATA'와 같은 GitHub 기반의 위키 프로젝트가 진행되었습니다 [2, 21, 22]. 이 프로젝트는 유저들이 자발적으로 참여하여 데미지 계산, 명중률 공식 등을 분석하고 기록하는 집단 지성의 장으로 기능합니다 [2, 23].
|
||||
* **현실주의 모드의 등장 (Reb's FRAGO):** 커뮤니티 생태계의 대표적 성과 중 하나는 'RebsFRAGO'와 같은 고도의 현실주의(Realism) 지향 모드입니다 [2, 24]. 이 모드는 임의적인 밸런스 패치를 지양하고 무기의 최대 사거리, 탄약 크기 기반의 데미지, 폭발 반경, 이동 속도 등 모든 데이터를 실제 제원값과 일관된 계산식에 기반하여 재설계함으로써 전술적 현실성을 극대화했습니다 [24-26].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[데이터 기반 밸런싱(Data-Driven Balancing)]], [[Iriszoom 엔진]]
|
||||
- **Projects/Contexts:** [[War-Yes 및 Warno-Armory 데이터베이스]], [[WARPLAN 리플레이 분석기]], [[RebsFRAGO 모드]], [[WARNO-DATA GitHub 위키 프로젝트]], [[WME (Warno Mod Editor)]]
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], 데이터 기반 밸런싱(Data-Driven Balancing), [[Iriszoom 엔진|Iriszoom 엔진]]
|
||||
- **Projects/Contexts:** War-Yes 및 Warno-Armory 데이터베이스, WARPLAN 리플레이 분석기, RebsFRAGO 모드, WARNO-DATA GitHub 위키 프로젝트, [[WME (Warno Mod Editor)|WME (Warno Mod Editor]]
|
||||
- **Contradictions/Notes:** Eugen Systems는 기본적인 모딩 매뉴얼과 NDF 참조 가이드를 공식적으로 제공하고 있으나, 수천 개의 파일에 분산된 구체적인 속성 데이터에 대한 상세한 설명은 부족한 편입니다. 이에 대한 간극은 유저 커뮤니티가 직접 WARNO-DATA 위키 문서화나 커뮤니티 디스코드 등을 통해 메우고 있습니다 [3, 21, 27].
|
||||
|
||||
---
|
||||
|
||||
@@ -3,20 +3,20 @@ category: AI & Games
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
# [[WARNO]]-DATA Wiki
|
||||
# [[WARNO|WARNO]]-DATA Wiki
|
||||
|
||||
## ?뱦[[ brief]] Summary
|
||||
WARNO-DATA Wiki??Eugen[[ system]]s???꾩닠 ?쒕??덉씠??寃뚯엫??WARNO???좊떅 ?곗씠?곗? ?듭떖 寃뚯엫 硫붿빱?덉쬁???곸꽭??臾몄꽌?뷀븳 而ㅻ??덊떚 二쇰룄???꾨줈?앺듃?낅땲??[1-3]. 寃뚯엫???묐룞 ?쇰━媛 ?닿릿 ?낆옄?곸씤 NDF ?뚯씪?ㅼ쓽 ?뺤떇???대룆?섏뿬, 諛⑸????뚯씪 ?띿뿉 遺꾩궛???띿꽦 媛믩뱾???댄빐?섍린 ?쎄쾶 ?ㅻ챸?섎뒗 寃껋쓣 紐⑺몴濡??⑸땲??[1, 4]. ?대? ?듯빐 紐낆쨷瑜? ?곕?吏 怨꾩궛 ???④꺼吏?硫붿빱?덉쬁???щ챸?섍쾶 怨듦컻?섏뿬 ?뚮젅?댁뼱媛 ?곗씠??以묒떖??寃뚯엫 ?ㅺ퀎瑜?源딆씠 ?댄빐?????덈룄濡??뺤뒿?덈떎 [4, 5].
|
||||
## ?뱦Brief Summary
|
||||
WARNO-DATA Wiki??EugenSystems???꾩닠 ?쒕??덉씠??寃뚯엫??WARNO???좊떅 ?곗씠?곗? ?듭떖 寃뚯엫 硫붿빱?덉쬁???곸꽭??臾몄꽌?뷀븳 而ㅻ??덊떚 二쇰룄???꾨줈?앺듃?낅땲??[1-3]. 寃뚯엫???묐룞 ?쇰━媛 ?닿릿 ?낆옄?곸씤 NDF ?뚯씪?ㅼ쓽 ?뺤떇???대룆?섏뿬, 諛⑸????뚯씪 ?띿뿉 遺꾩궛???띿꽦 媛믩뱾???댄빐?섍린 ?쎄쾶 ?ㅻ챸?섎뒗 寃껋쓣 紐⑺몴濡??⑸땲??[1, 4]. ?대? ?듯빐 紐낆쨷瑜? ?곕?吏 怨꾩궛 ???④꺼吏?硫붿빱?덉쬁???щ챸?섍쾶 怨듦컻?섏뿬 ?뚮젅?댁뼱媛 ?곗씠??以묒떖??寃뚯엫 ?ㅺ퀎瑜?源딆씠 ?댄빐?????덈룄濡??뺤뒿?덈떎 [4, 5].
|
||||
|
||||
## ?뱰 Core Content
|
||||
* **?ㅻ┰ 諛곌꼍 諛?紐⑹쟻:** WARNO??寃뚯엫 ?숈옉怨??좊떅 ?곗씠?곕뒗 [[Eugen Systems]]??怨좎쑀 ?щ㎎???섏쿇 媛쒖쓽 NDF(Neutral Data Format) ?뚯씪??遺꾩궛?섏뼱 ??λ릺???덉뒿?덈떎 [1]. 怨듭떇?곸쑝濡??쒓났?섎뒗 紐⑤뵫 留ㅻ돱?쇱? ?뚯씪 ?뺤떇留?媛쒕왂?곸쑝濡??ㅻ챸??肉??대? ?곗씠?곗뿉 ????곸꽭???ㅻ챸??遺議깊빀?덈떎 [1]. WARNO-DATA ?꾨줈?앺듃???대윭??媛꾧레??硫붿슦湲??꾪빐 ?좊떅??二쇱슂 ?띿꽦怨??듭떖 硫붿빱?덉쬁???ш큵?곸쑝濡?臾몄꽌?뷀븯???꾪궎瑜?援ъ텞?섏??듬땲??[1, 3, 4].
|
||||
* **?ㅻ┰ 諛곌꼍 諛?紐⑹쟻:** WARNO??寃뚯엫 ?숈옉怨??좊떅 ?곗씠?곕뒗 [[Eugen Systems|Eugen Systems]]??怨좎쑀 ?щ㎎???섏쿇 媛쒖쓽 NDF(Neutral Data Format) ?뚯씪??遺꾩궛?섏뼱 ??λ릺???덉뒿?덈떎 [1]. 怨듭떇?곸쑝濡??쒓났?섎뒗 紐⑤뵫 留ㅻ돱?쇱? ?뚯씪 ?뺤떇留?媛쒕왂?곸쑝濡??ㅻ챸??肉??대? ?곗씠?곗뿉 ????곸꽭???ㅻ챸??遺議깊빀?덈떎 [1]. WARNO-DATA ?꾨줈?앺듃???대윭??媛꾧레??硫붿슦湲??꾪빐 ?좊떅??二쇱슂 ?띿꽦怨??듭떖 硫붿빱?덉쬁???ш큵?곸쑝濡?臾몄꽌?뷀븯???꾪궎瑜?援ъ텞?섏??듬땲??[1, 3, 4].
|
||||
* **?곗씠???ъ쟾(Data Dictionary) ?쒓났:** ???꾪궎??`UniteDescriptor.ndf`, `WeaponDescriptor.ndf`, `Ammunition.ndf` ???쒕??덉씠?섏쓣 援щ룞?섎뒗 ?듭떖 NDF ?뚯씪?ㅼ쓽 二쇱슂 ?띿꽦???뺣━???ъ쟾(Dictionary)???ы븿?섍퀬 ?덉뒿?덈떎 [4, 6]. ?대? ?듯빐 ?좊떅??媛寃? ?쒖빞, ?κ컩, 愿?듬젰, 議곗? ?쒓컙 ??臾쇰━??諛?湲곗닠???띿꽦???곗씠???덈꺼?먯꽌 ?대뼸寃??뺤쓽?섎뒗吏 ?뺤씤?????덉뒿?덈떎 [6, 7].
|
||||
* **寃뚯엫 硫붿빱?덉쬁???ъ링 遺꾩꽍:** WARNO-DATA???섏튂?곸씤 ?곗씠?곕퓧留??꾨땲?? 紐낆쨷瑜좉낵 ?곕?吏媛 怨꾩궛?섎뒗 怨쇱젙 ??洹쇰낯?곸씤 寃뚯엫 ??븰??????ъ링?곸씤 ?듭같?μ쓣 ?쒓났?⑸땲??[2, 4]. ???꾪궎???먮즺瑜?諛뷀깢?쇰줈 ?뚮젅?댁뼱?ㅼ? ?꾩쥌(KE, HEAT, HE ?????곕Ⅸ ?ш굅由?鍮꾨? 愿?듬젰??李⑥씠??蹂듭옟??臾쇰━ 怨꾩궛???댄빐?????덉뒿?덈떎 [8, 9].
|
||||
* **而ㅻ??덊떚 二쇰룄???곗씠??誘쇱＜??** WARNO-DATA??GPL-3.0 ?쇱씠?좎뒪 ?섏뿉 ?댁쁺?섎뒗 ?꾨줈?앺듃濡? 而ㅻ??덊떚 援ъ꽦?먮뱾???꾩쭅 臾몄꽌?붾릺吏 ?딆? ?띿꽦?ㅼ쓣 ?④퍡 ?대룆???섍???湲곗뿬??援ъ“瑜?媛吏怨??덉뒿?덈떎 [2]. [[Warno-Armory]] 諛?[[War-Yes]]? 媛숈? ?곗씠???뚯떛 ?꾧뎄?ㅺ낵 ?붾텋?? 媛쒕컻???대????④꺼???덈뜕 ?붿쭊 ?섏튂瑜?諛쒓뎬?섏뿬 ?좎?媛 ?뺢탳???곗씠??湲곕컲???꾩닠???섎┰?????덈룄濡??뺣뒗 ?듭떖?곸씤 ??븷???섑뻾?⑸땲??[5, 10].
|
||||
* **而ㅻ??덊떚 二쇰룄???곗씠??誘쇱＜??** WARNO-DATA??GPL-3.0 ?쇱씠?좎뒪 ?섏뿉 ?댁쁺?섎뒗 ?꾨줈?앺듃濡? 而ㅻ??덊떚 援ъ꽦?먮뱾???꾩쭅 臾몄꽌?붾릺吏 ?딆? ?띿꽦?ㅼ쓣 ?④퍡 ?대룆???섍???湲곗뿬??援ъ“瑜?媛吏怨??덉뒿?덈떎 [2]. [[Warno-Armory|Warno-Armory]] 諛?[[War-Yes|War-Yes]]? 媛숈? ?곗씠???뚯떛 ?꾧뎄?ㅺ낵 ?붾텋?? 媛쒕컻???대????④꺼???덈뜕 ?붿쭊 ?섏튂瑜?諛쒓뎬?섏뿬 ?좎?媛 ?뺢탳???곗씠??湲곕컲???꾩닠???섎┰?????덈룄濡??뺣뒗 ?듭떖?곸씤 ??븷???섑뻾?⑸땲??[5, 10].
|
||||
|
||||
## ?뵕 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[?곗씠??湲곕컲 ?ㅺ퀎(Data-Driven Design)]], [[Iriszoom ?붿쭊]]
|
||||
- **Projects/Contexts:** [[Warno-Armory]], [[War-Yes]], [[WARNO 紐⑤뵫 而ㅻ??덊떚]]
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], ?곗씠??湲곕컲 ?ㅺ퀎(Data-Driven Design), Iriszoom ?붿쭊
|
||||
- **Projects/Contexts:** [[Warno-Armory|Warno-Armory]], War-Yes, WARNO 紐⑤뵫 而ㅻ??덊떚
|
||||
- **Contradictions/Notes:** 媛쒕컻?ъ씤 Eugen Systems??NDF ?뚯씪 ?щ㎎?????媛꾨왂??媛?대뱶瑜??쒓났?섏?留??대? ?곗씠???띿꽦?????援ъ껜???ㅻ챸? ?꾨씫?섍퀬 ?덉쑝硫? ?대? 而ㅻ??덊떚 二쇰룄??WARNO-DATA ?꾪궎媛 ?대룆?섍퀬 臾몄꽌瑜?梨꾩썙 ?ｌ뼱 蹂댁셿?섍퀬 ?덉뒿?덈떎 [1].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,20 +4,20 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[WARNO]]-DATA 프로젝트
|
||||
# [[WARNO|WARNO]]-DATA 프로젝트
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO-DATA 프로젝트는 Eugen[[ system]]s의 전술 게임 WARNO를 위해 깃허브(GitHub)에 구축된 광범위한 위키 프로젝트입니다 [1, 2]. 이 프로젝트는 수천 개의 `.ndf` 파일에 분산된 유닛 데이터를 문서화하고 명중률이나 데미지 계산과 같은 게임의 핵심 메커니즘을 상세히 설명하는 데 목적을 두고 있습니다 [3-5]. 공식 모딩 매뉴얼이 제공하지 못하는 데이터 속성의 구체적인 의미를 해독하여 WARNO 커뮤니티와 모더들의 이해를 돕는 커뮤니티 주도형 프로젝트입니다 [3, 6].
|
||||
## 📌 Brief Summary
|
||||
WARNO-DATA 프로젝트는 EugenSystems의 전술 게임 WARNO를 위해 깃허브(GitHub)에 구축된 광범위한 위키 프로젝트입니다 [1, 2]. 이 프로젝트는 수천 개의 `.ndf` 파일에 분산된 유닛 데이터를 문서화하고 명중률이나 데미지 계산과 같은 게임의 핵심 메커니즘을 상세히 설명하는 데 목적을 두고 있습니다 [3-5]. 공식 모딩 매뉴얼이 제공하지 못하는 데이터 속성의 구체적인 의미를 해독하여 WARNO 커뮤니티와 모더들의 이해를 돕는 커뮤니티 주도형 프로젝트입니다 [3, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
* **프로젝트의 배경 및 목표:** WARNO의 게임 동작 및 유닛 데이터는 [[Eugen Systems]]의 독자적인 `.ndf` 파일 시스템 내에 저장됩니다 [3]. 개발사가 파일 포맷을 설명하는 간략한 모딩 매뉴얼과 `.ndf` 참조 가이드를 제공하기는 하나, 수천 개의 파일에 분포된 실제 데이터의 의미에 대한 설명은 부족합니다 [3]. WARNO-DATA는 이러한 정보의 공백을 메우기 위해 고안되었으며, WARNO 커뮤니티의 발전을 위해 GPL-3.0 라이선스로 운영되는 커뮤니티 중심의 프로젝트입니다 [4, 6].
|
||||
* **프로젝트의 배경 및 목표:** WARNO의 게임 동작 및 유닛 데이터는 [[Eugen Systems|Eugen Systems]]의 독자적인 `.ndf` 파일 시스템 내에 저장됩니다 [3]. 개발사가 파일 포맷을 설명하는 간략한 모딩 매뉴얼과 `.ndf` 참조 가이드를 제공하기는 하나, 수천 개의 파일에 분포된 실제 데이터의 의미에 대한 설명은 부족합니다 [3]. WARNO-DATA는 이러한 정보의 공백을 메우기 위해 고안되었으며, WARNO 커뮤니티의 발전을 위해 GPL-3.0 라이선스로 운영되는 커뮤니티 중심의 프로젝트입니다 [4, 6].
|
||||
* **데이터 사전(Data Dictionary):** 이 위키는 `UniteDescriptor.ndf` 및 `WeaponDescriptor.ndf` 등과 같은 게임 내 가장 중요한 `.ndf` 파일들의 핵심 속성들을 세심하게 기록한 포괄적인 데이터 사전을 포함하고 있습니다 [4].
|
||||
* **게임 메커니즘 심층 가이드:** 단순히 데이터를 나열하는 것에 그치지 않고, 명중률(accuracy) 및 데미지 계산(damage calculation) 방식 등을 비롯한 WARNO의 근본적인 게임 메커니즘에 대한 상세한 통찰과 가이드를 제공합니다 [4, 6].
|
||||
* **커뮤니티의 참여와 기여:** 아직 완전히 문서화되지 않은 데이터 속성들을 해독하기 위해 유저 커뮤니티의 적극적인 참여를 장려하고 있습니다 [6]. 사용자는 깃허브의 이슈(issue) 기능을 통해 질문을 남기거나 문제 해결을 지원받을 수 있습니다 [6].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[모딩 생태계]], [[데이터 기반 밸런싱]]
|
||||
- **Projects/Contexts:** [[Eugen Systems 모딩 매뉴얼]], [[Warno-Armory]], [[War-Yes]]
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], 모딩 생태계, [[데이터 기반 밸런싱|데이터 기반 밸런싱]]
|
||||
- **Projects/Contexts:** [[Eugen Systems 모딩 매뉴얼|Eugen Systems 모딩 매뉴얼]], Warno-Armory, [[War-Yes|War-Yes]]
|
||||
- **Contradictions/Notes:** 개발사인 Eugen Systems에서 자체적인 모딩 매뉴얼과 `.ndf` 가이드를 공식 제공하고 있음에도 불구하고, 실제 데이터 세부 내용에 대한 설명은 결여되어 있어 유저 주도의 WARNO-DATA 프로젝트가 필수적인 보완재 역할을 수행하고 있습니다 [3, 4].
|
||||
|
||||
---
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user