[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -4,24 +4,24 @@ _모든 명령·분배·산출물·대화가 시간순으로 누적됩니다.
|
||||
|
||||
## [16:07:45] 👤 **사용자**
|
||||
|
||||
[모닝 브리핑] 오늘 날짜는 2026-04-30입니다. 회사 목표(goals.md)와 지금까지의 의사결정 로그를 바탕으로 오늘 우리 회사가 우선순위로 처리해야 할 작업 3가지를 결정하고, 각 작업을 적절한 에이전트에게 분배하세요.
|
||||
[모닝 브리핑] 오늘 날짜는 2026-04-30입니다. 회사 목표([[goals]].md)와 지금까지의 의사결정 로그를 바탕으로 오늘 우리 회사가 우선순위로 처리해야 할 작업 3가지를 결정하고, 각 작업을 적절한 에이전트에게 분배하세요.
|
||||
|
||||
## [16:28:10] 🧭 **CEO** · _작업 분배_
|
||||
|
||||
회사 목표와 로그가 초기화 상태이므로, 시장 분석을 통한 닉슈 선정 → 수익화 전략 및 KPI 도출 → 일일/주간 실행 계획 수립 순으로 3가지 우선 작업을 정의합니다.
|
||||
|
||||
**할당:**
|
||||
- 🔍 **Researcher**: AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개월 내 진입 가능한 최적의 1개 닉슈와 핵심 타깃 키워드 5개를 정리해 보고하세요.
|
||||
- 💰 **Business**: researcher의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안하고, 월별 조회수·구독자·변환율 목표를 포함한 KPI 프레임워크와 가격/수익 구조를 1페이지 분량으로 작성하세요.
|
||||
- 📱 **Secretary**: 리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전트·진행 상태를 명시한 데일리 브리핑과 1주일 액션 플랜을 텔레그램 보고 형식으로 출력하세요.
|
||||
- 🔍 **[[Research]]er**: AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개월 내 진입 가능한 최적의 1개 닉슈와 핵심 타깃 키워드 5개를 정리해 보고하세요.
|
||||
- 💰 **[[business]]**: re[[Search]]er의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안하고, 월별 조회수·구독자·변환율 목표를 포함한 KPI 프레임워크와 가격/수익 구조를 1페이지 분량으로 작성하세요.
|
||||
- 📱 **[[secretary]]**: 리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전트·진행 상태를 명시한 데일리 브리핑과 1주일 액션 플랜을 텔레그램 보고 형식으로 출력하세요.
|
||||
|
||||
## [16:33:10] 🔍 **Researcher** · _AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개_
|
||||
## [16:33:10] 🔍 **[[researcher]]** · _AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개_
|
||||
|
||||
⚠️ Researcher 에이전트 호출 실패: aborted
|
||||
|
||||
## [16:37:31] 👤 **사용자**
|
||||
|
||||
[자율 사이클 — 2026-04-30] 사용자가 자리를 비웠습니다. 회사 목표·각 에이전트의 개인 목표(_agents/{id}/goal.md)·최근 의사결정·메모리를 검토해서 지금 가장 가치 있는 단일 작업 1개를 결정하고, 적절한 1~2명 에이전트에게 분배해서 실행하세요. 같은 산출물을 반복하지 마세요 — 메모리에 비슷한 항목이 24시간 내에 있으면 다른 각도로 진전시키세요.
|
||||
[자율 사이클 — 2026-04-30] 사용자가 자리를 비웠습니다. 회사 목표·각 에이전트의 개인 목표(_agents/{id}/[[goal]].md)·최근 의사결정·메모리를 검토해서 지금 가장 가치 있는 단일 작업 1개를 결정하고, 적절한 1~2명 에이전트에게 분배해서 실행하세요. 같은 산출물을 반복하지 마세요 — 메모리에 비슷한 항목이 24시간 내에 있으면 다른 각도로 진전시키세요.
|
||||
|
||||
## [16:38:10] 💰 **Business** · _researcher의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안_
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 리액트 클린 코드 및 개발 에티켓
|
||||
category: Software Architecture
|
||||
category: Software [[Architecture]]
|
||||
tags: [Clean Code, Etiquette, Best Practice, Readable Code]
|
||||
created: 2026-04-20
|
||||
---
|
||||
@@ -16,7 +16,7 @@ created: 2026-04-20
|
||||
- **Props Destructuring (구조 분해 할당)**:
|
||||
- `props.user.name` 처럼 경로를 길게 쓰는 대신, 함수의 인자 단계에서 `{ user: { name } }` 처럼 분해하라. 코드가 숨을 쉬기 시작한다.
|
||||
- **Explicit Naming (명시적 네이밍)**:
|
||||
- 핸들러 함수는 `handle[Action]` (예: `handleSearch`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다.
|
||||
- 핸들러 함수는 `handle[Action]` (예: `handle[[Search]]`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다.
|
||||
- **조건부 렌더링 에티켓**:
|
||||
- `&&` 연산자 대신 삼항 연산자(`? :`)를 권장한다. 특히 `0 && <Component />` 시 화면에 숫자 0이 출력되는 대참사를 방지하기 위함이다.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 리액트 훅(Hooks) 심층 분석 및 활용
|
||||
category: Software Architecture
|
||||
category: Software [[Architecture]]
|
||||
tags: [React, Hooks, useEffect, Custom Hooks]
|
||||
created: 2026-04-20
|
||||
---
|
||||
@@ -14,7 +14,7 @@ created: 2026-04-20
|
||||
- **useEffect의 올바른 관점**:
|
||||
- "마운트될 때 실행"이라는 라이프사이클 사고방식에서 벗어나라. `useEffect`는 **의존성 배열의 값과 컴포넌트 외부 시스템(API, DOM 등)을 동기화**하는 작업이다.
|
||||
- **Custom Hooks (추상화의 꽃)**:
|
||||
- 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMyLogic` 처럼 따로 빼내어 컴포넌트는 오직 UI 선언에만 집중하게 만든다. 이것이 컴포넌트의 가독성을 폭발시키는 비결이다.
|
||||
- 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMy[[Logic]]` 처럼 따로 빼내어 컴포넌트는 오직 UI 선언에만 집중하게 만든다. 이것이 컴포넌트의 가독성을 폭발시키는 비결이다.
|
||||
- **Rules of Hooks**:
|
||||
- 반드시 함수의 최상위에서만 호출되어야 한다. 그래야 리액트가 훅의 상태를 유한 상태 머신처럼 정확한 순서로 관리할 수 있다.
|
||||
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- `useEffect` 내에서 무분별하게 상태를 업데이트하면 무한 루프나 성능 저하가 발생한다. 가능하면 `useMemo`나 `useCallback`으로 계산 결과를 캐싱하거나, 상태 업데이트 로직을 `useReducer`로 위임하라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Performance_Optimization]] , [[React_State_Management_Strategy]]
|
||||
- Related: [[React_Performance_Optimization]] , [[React_[[State]]_[[Management]]_Strategy]]
|
||||
- Context: [[WebWorker_Performance]]
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 리액트 핵심 멘탈 모델 (UI as a Function of State)
|
||||
category: Software Architecture
|
||||
title: 리액트 핵심 멘탈 모델 (UI as a Function of [[State]])
|
||||
category: Software [[Architecture]]
|
||||
tags: [React, State, Mental Model, Immutability]
|
||||
created: 2026-04-20
|
||||
---
|
||||
@@ -14,12 +14,12 @@ created: 2026-04-20
|
||||
- **UI = f(State)**:
|
||||
- 화면은 상태의 결과값이어야 한다. 명령형(Imperative)으로 "이 버튼의 글자를 바꿔라"라고 하는 순간 리액트의 질서는 무너진다. 오직 상태를 바꾸고 리액트가 알아서 그리게 하라.
|
||||
- **Immutability (불변성)**:
|
||||
- 리액트는 객체의 주소값이 변할 때만 렌더링을 시도한다. `arr.push(1)`이 아니라 `setArr([...arr, 1])`처럼 **새로운 원본**을 복제하여 가상 DOM(Virtual DOM)이 효율적으로 동작하게 돕는다.
|
||||
- 리액트는 객체의 주소값이 변할 때만 렌더링을 시도한다. `arr.push(1)`이 아니라 `setArr([...arr, 1])`처럼 **새로운 원본**을 복제하여 가상 DOM([[Virtual DOM]])이 효율적으로 동작하게 돕는다.
|
||||
- **Virtual DOM Diffing**:
|
||||
- 리액트는 실제 DOM을 직접 건드리기 전에 메모리상의 가상 DOM에서 이전 상태와 비교(Diffing)하여, 꼭 필요한 부분만 실제 화면에 반영(Commit)한다. 이것이 고성능 웹의 비결이다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어(Normalization) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다.
|
||||
- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어([[Normalization]]) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Hooks_Deep_Dive]] , [[Component_Design_Patterns]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 리액트 렌더링 최적화 전략
|
||||
category: Software Architecture
|
||||
tags: [Performance, Memoization, React.memo, Optimization]
|
||||
category: Software [[Architecture]]
|
||||
tags: [Performance, Memoization, React.memo, [[Optimization]]]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -17,7 +17,7 @@ created: 2026-04-20
|
||||
- **useCallback**: 함수 객체의 변동을 막아 자식 컴포넌트의 불필요한 리렌더링을 방지한다.
|
||||
- **Windowing (가상 리스트)**:
|
||||
- 수천 개의 리스트 아이템이 있어도 사용자의 눈에 보이는 수십 개만 실제 DOM에 렌더링한다. (예: `react-window`, `react-virtualized`).
|
||||
- **상태의 위치 선정 (State Colocation)**:
|
||||
- **상태의 위치 선정 ([[State]] Colocation)**:
|
||||
- 전역 상태가 바뀔 때마다 앱 전체가 들썩이지 않게 하라. 상태는 그것을 사용하는 가장 하위 컴포넌트 근처로 내려라.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 전략적 상태 관리 가이드 (Global & Server State)
|
||||
category: Software Architecture
|
||||
tags: [State Management, React Query, SSOT, Architecture]
|
||||
title: 전략적 상태 관리 가이드 (Global & Server [[State]])
|
||||
category: Software [[Architecture]]
|
||||
tags: [State [[Management]], React Query, SSOT, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -21,7 +21,7 @@ created: 2026-04-20
|
||||
- 다른 상태로부터 계산될 수 있는 값(예: `firstName`+`lastName` = `fullName`)은 절대 '상태'로 만들지 마라. 렌더링 시점에 계산하는 것이 정합성 유지의 핵심이다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 무조건적인 전역 상태 지상주의는 'Prop Drilling'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.
|
||||
- 무조건적인 전역 상태 지상주의는 '[[Prop Drilling]]'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Single_Source_of_Truth]] , [[API_Communication_Patterns]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 리액트 애플리케이션 테스트 전략
|
||||
category: Software Architecture
|
||||
tags: [Testing, Vitest, RTL, Unit Test, QA]
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[Testing]], Vitest, RTL, Unit Test, QA]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 타입스크립트 기반의 안정적 개발 (Type Safety)
|
||||
category: Software Architecture
|
||||
category: Software [[Architecture]]
|
||||
tags: [TypeScript, Interface, Type Safety, Generic]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -10,9 +10,9 @@ created: 2026-04-20
|
||||
## 🎯 개요 (Overview)
|
||||
실시간 상태 변화가 매우 빈번한 애플리케이션(예: 게임, 시뮬레이션)에서 UI 스레드와 복잡한 연산 로직을 분리하여 **프레임 드롭(Jank)**을 방지하는 아키텍처 설계 기법입니다.
|
||||
|
||||
## 🚀 주요 원칙 (Key Principles)
|
||||
## 🚀 주요 원칙 (Key [[Principles]])
|
||||
- **스레드 분리 (Thread Isolation)**: 무거운 계산은 백그라운드 스레드(Web Worker)에서 수행하고, 메인 스레드는 렌더링에만 집중합니다.
|
||||
- **메시징 기반 통신 (Messaging Architecture)**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다.
|
||||
- **메시징 기반 통신 (Messaging [[Architecture]])**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다.
|
||||
|
||||
## 💡 레슨 런 (Lesson Learned)
|
||||
> [!IMPORTANT]
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 효율적인 API 통신 패턴 (Axios & Interceptors)
|
||||
category: Software Architecture
|
||||
category: Software [[Architecture]]
|
||||
tags: [API, Axios, Interceptor, Error Handling, Network]
|
||||
created: 2026-04-20
|
||||
---
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 모든 통신에 Axios가 정답은 아니다. 브라우저 네이티브인 `fetch`로도 충분한 경우가 많으며, 라이브러리 의존성을 낮추는 것이 가벼운 앱을 만드는 첫걸음일 수 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[System_Protocol_Standard]] , [[React_State_Management_Strategy]]
|
||||
- Related: [[System_Protocol_Standard]] , [[React_[[State]]_[[Management]]_Strategy]]
|
||||
- Foundation: [[Reliability_Safety_First]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 컴포넌트 설계 패턴 (Atomic & Composition)
|
||||
category: Software Architecture
|
||||
tags: [Design Pattern, Atomic Design, Composition, Architecture]
|
||||
category: Software [[Architecture]]
|
||||
tags: [Design Pattern, [[Atomic Design]], Composition, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -12,9 +12,9 @@ created: 2026-04-20
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Container-Presenter 패턴**:
|
||||
- **Container**: 데이터(State, API)를 가져오고 관리하는 '머리'.
|
||||
- **Container**: 데이터([[State]], API)를 가져오고 관리하는 '머리'.
|
||||
- **Presenter**: 오직 Props만 받아 화면을 그리는 '몸통'. 스타일과 UI 구조에만 집중하여 테스트 가능성을 높인다.
|
||||
- **Compound Components (복합 컴포넌트)**:
|
||||
- **[[Compound Components]] (복합 컴포넌트)**:
|
||||
- `<Select><Option /></Select>` 처럼 부모와 자식이 상태를 공유하며 하나의 긴밀한 기능을 수행하는 패턴. 사용자가 UI 구조를 자유롭게 배치할 수 있게 유연성을 제공한다.
|
||||
- **Atomic Design (원자 중심 설계)**:
|
||||
- Atom(버튼, 입력창) $\rightarrow$ Molecule(검색바) $\rightarrow$ Organism(헤더) $\rightarrow$ Template $\rightarrow$ Page.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 시스템 아키텍처와 관심사 분리 (Separation of Concerns)
|
||||
category: Software Architecture
|
||||
title: 시스템 아키텍처와 관심사 분리 ([[Separation of Concerns]])
|
||||
category: Software [[Architecture]]
|
||||
tags: [Architecture, SoC, Modular Design, Design Pattern]
|
||||
created: 2026-04-20
|
||||
---
|
||||
@@ -11,8 +11,8 @@ created: 2026-04-20
|
||||
복잡한 소프트웨어 시스템을 역할별로 구분된 독립적인 모듈로 나누어, 유지보수성과 확장성을 극대화하는 설계 철학입니다.
|
||||
|
||||
## 🚀 계층구조 예시 (Layering Example)
|
||||
1. **Logic Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`)
|
||||
2. **State Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`)
|
||||
1. **[[Logic]] Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`)
|
||||
2. **[[State]] Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`)
|
||||
3. **View Layer**: 사용자 인터페이스 표현 및 렌더링 (예: React Components)
|
||||
|
||||
## 💡 레슨 런 (Lesson Learned)
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 상태 관리의 단일 진실 공급원 (Single Source of Truth)
|
||||
category: Software Architecture
|
||||
tags: [State Management, Data Consistency, Redux, Architecture]
|
||||
title: 상태 관리의 단일 진실 공급원 ([[Single Source of Truth]])
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[State]] [[Management]], Data Consistency, Redux, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -10,7 +10,7 @@ created: 2026-04-20
|
||||
## 🎯 개요 (Overview)
|
||||
시스템의 핵심 데이터를 중앙 집중식으로 관리하여, 데이터 불일치(Inconsistency) 현상을 원천 차단하고 예측 가능한 데이터 흐름을 확보하는 설계 원칙입니다.
|
||||
|
||||
## 🚀 주요 원칙 (Key Principles)
|
||||
## 🚀 주요 원칙 (Key [[Principles]])
|
||||
- **단일 지점 정의 (Defined at Single Point)**: 상태는 오직 한 곳에서만 정의되고 관리되어야 합니다.
|
||||
- **예측 가능성 (Predictability)**: 상태 변경은 정해진 규칙(Action/Setter)을 통해서만 발생하여 디버깅을 용이하게 합니다.
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 시스템 시뮬레이션 설계 원리
|
||||
category: Systemic Modeling & Fun
|
||||
tags: [Simulation, Physics Engine, Systemic Modeling, Ruleset]
|
||||
category:[[ system]]ic Modeling & Fun
|
||||
tags: [Simulation, [[Physics]] Engine, Systemic Modeling, Ruleset]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 배포 프로토콜 및 CI/CD 자동화
|
||||
category: Software Architecture
|
||||
tags: [Deployment, CI/CD, GitHub Actions, Vercel, DevOps]
|
||||
category: Software [[Architecture]]
|
||||
tags: [Deployment, CI/CD, [[GitHub Actions]], Vercel, DevOps]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -23,4 +23,4 @@ created: 2026-04-20
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Modern_Environment_Ecosystem]] , [[Collaboration_Governance]]
|
||||
- Pre-requisite: [[React_Testing_Strategy]]
|
||||
- Pre-requisite: [[React_[[Testing]]_Strategy]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 개발 환경 및 실행 프로세스 관리 (DevOps & Setup)
|
||||
category: DevOps
|
||||
tags: [DevOps, Environment, CI/CD, Process Management]
|
||||
tags: [DevOps, Environment, CI/CD, Process [[Management]]]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 🛠️ Git Operation & Work Log Protocol (Git 작업 및 기록 지침)
|
||||
# 🛠️ Git [[Opera]]tion & Work Log Protocol (Git 작업 및 기록 지침)
|
||||
|
||||
> **카테고리**: 03_DevOps_Environment, Automation
|
||||
> **상태**: 🟢 활성화 (Active)
|
||||
@@ -9,7 +9,7 @@
|
||||
## 📌 개요 (Overview)
|
||||
본 문서는 Skybound 프로젝트를 포함한 4개 주요 개발 거점의 원격 저장소 동기화 정합성을 유지하고, 모든 AI 작업 과정을 체계적으로 문서화하기 위한 Git 운영 규정 및 작업 로그(Work Log) 시스템을 정의한다.
|
||||
|
||||
## 🔗 프로젝트별 Git 맵핑 (Repository Mapping)
|
||||
## 🔗 프로젝트별 Git 맵핑 ([[Repository]] Mapping)
|
||||
대표님의 명령 한마디로 정확한 경로에서 작업을 수행하기 위해 각 폴더별로 독립적인 Git 설정을 유지한다.
|
||||
|
||||
| 프로젝트 | 로컬 경로 | 원격 저장소 (Remote URL) | 리모트 명칭 |
|
||||
@@ -17,7 +17,7 @@
|
||||
| **Wiki (2nd)** | `E:\Wiki\2nd` | `https://github.com/wonseokjung/solopreneur-ai-agents.git` | `lm_sync` |
|
||||
| **Skybound** | `E:\Wiki\skybound` | `https://github.com/wonseokjung/skybound-protocol.git` | `origin` |
|
||||
| **Legal** | `E:\Wiki\legal-bridge` | `https://github.com/wonseokjung/legal-bridge.git` | `origin` |
|
||||
| **Agent** | `E:\Wiki\auto-research-agent`| `https://github.com/wonseokjung/auto-research-agent.git` | `origin` |
|
||||
| **Agent** | `E:\Wiki\auto-[[Research]]-agent`| `https://github.com/wonseokjung/auto-re[[Search]]-agent.git` | `origin` |
|
||||
|
||||
## 🛠️ 운영 지침 (Operational Guidelines)
|
||||
|
||||
@@ -37,7 +37,7 @@
|
||||
- **Result**: 최종 결과 및 관련 연결 지식.
|
||||
|
||||
### 3. 위키화 (Wikification)
|
||||
- `00_Raw`에 축적된 로그는 주기적으로 `10_Wiki\Topics` 하위 카테고리로 고도화(Refinement)되어 이동된다.
|
||||
- `00_Raw`에 축적된 로그는 주기적으로 `10_Wiki\Topics` 하위 카테고리로 고도화([[Refinement]])되어 이동된다.
|
||||
- 위키화가 완료된 원본 로그는 삭제하여 지식 베이스의 정결성을 유지한다.
|
||||
|
||||
## 🚀 기대 효과
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 모던 개발 환경 및 프레임워크 생태계
|
||||
category: Software Architecture
|
||||
tags: [Vite, Next.js, Ecosystem, Modern Stack]
|
||||
category: Software [[Architecture]]
|
||||
tags: [Vite, [[Next.js]], Ecosystem, Modern Stack]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -16,7 +16,7 @@ created: 2026-04-20
|
||||
- **Framework: Next.js (The Fullstack Edge)**:
|
||||
- 단순히 SEO를 위한 SSR 도구가 아니다. API Routes를 통한 서버리스 함수 구현, 데이터 캐싱 전략(ISR/SSG) 등 현대 웹이 요구하는 거의 모든 기능을 탑재한 '거버넌스' 그 자체다.
|
||||
- **패키지 매니저의 선택**:
|
||||
- `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포(Monorepo) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다.
|
||||
- `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포([[Monorepo]]) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 최신 기술이 항상 정답은 아니다. 안정성이 최우선인 기업 환경에서는 검증된 `CRA` 혹은 `Webpack` 기반의 설정을 유지하는 것이 보수적인 면에서 유리할 수 있다. 기술 부채(Tech Debt)와 도입 비용을 항상 저울질하라.
|
||||
|
||||
@@ -1,21 +1,21 @@
|
||||
---
|
||||
title: 프로젝트 회고: 고성능 테트리스 아키텍처
|
||||
category: Projects
|
||||
tags: [Retrospective, Tetris, Architecture, Performance]
|
||||
tags: [Retrospective, Tetris, [[Architecture]], Performance]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 프로젝트 회고: 고성능 테트리스 아키텍처 (P-Reinforce)
|
||||
# 프로젝트 회고: 고성능 테트리스 아키텍처 ([[P-Reinforce]])
|
||||
|
||||
## 🌊 프로젝트 아키텍처 요약
|
||||
본 프로젝트는 **Web Worker**를 활용한 완전한 연산-렌더링 분리를 실현하여, 실시간 게임 환경에서 극강의 부드러움을 확보하는 데 성공했습니다.
|
||||
|
||||
### 🧩 컴포넌트별 기술적 역할
|
||||
- **Game Engine**: 물리 계산 및 상태 전이 (`public/gameWorker.js`).
|
||||
- **State Manager**: UI의 유일한 진실 공급원 (`src/App.js`).
|
||||
- **[[State]] Manager**: UI의 유일한 진실 공급원 (`src/App.js`).
|
||||
- **Renderer**: Props 기반의 순수 매핑 렌더러 (`src/components/GameBoard.jsx`).
|
||||
|
||||
## ⚠️ 핵심 교훈 (Lessons Learned)
|
||||
## ⚠️ 핵심 교훈 ([[Lessons Learned]])
|
||||
> [!IMPORTANT]
|
||||
> **"논리가 완벽해도 실행 환경이 무너지면 아무 의미가 없다."**
|
||||
> 아키텍처 설계만큼이나 '파일 무결성 검증'과 '환경 재설정 루틴'이 개발 생산성에 지대한 영향을 미친다는 것을 확인했습니다.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 웹 접근성 및 포용적 설계 (a11y)
|
||||
category: Software Architecture
|
||||
tags: [Accessibility, a11y, Semantic HTML, Inclusivity]
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[Accessibility]], a11y, Semantic HTML, Inclusivity]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -13,7 +13,7 @@ created: 2026-04-20
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Semantic HTML (의미론적 태그)**:
|
||||
- `<div>`로만 도배하지 마라. `<main>`, `<article>`, `<section>`, `<nav>` 등 의미가 담긴 태그를 써야 기계(스크린 리더)와 검색 엔진이 내 콘텐츠의 중요도를 파악한다.
|
||||
- **ARIA & States**:
|
||||
- **ARIA & [[State]]s**:
|
||||
- 표준 HTML로 설명이 불가능한 인터랙션(예: 커스텀 탭 메뉴)은 `aria-label`, `aria-hidden` 등을 통해 기계에게 보조 설명을 전한다.
|
||||
- **Keyboard Navigation**:
|
||||
- 마우스 없이 `Tab` 키와 `Enter` 키만으로 내 앱의 모든 핵심 기능을 수행할 수 있는지 검증하라. 포커스링을 숨기지 마라. 누군가에게는 유일한 가이드라인이다.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 협업 가이드라인 및 코드 거버넌스
|
||||
category: Software Architecture
|
||||
tags: [Collaboration, PR, Code Review, Documentation, Governance]
|
||||
category: Software [[Architecture]]
|
||||
tags: [Collaboration, PR, [[Code Review]], Documentation, Governance]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -11,7 +11,7 @@ created: 2026-04-20
|
||||
> 코드는 혼자 쓰는 일기장이 아니라 함께 짓는 건축물이다. 동료의 시간을 아껴주는 문서화와 소통 방식이 당신의 가치를 증명한다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Pull Request (PR) 에티켓**:
|
||||
- **[[Pull Request (PR)]] 에티켓**:
|
||||
- "이거 고쳤습니다"는 최악의 PR이다. 무엇을(What), 왜(Why), 어떻게(How) 했는지 명시하고 가능한 시각적 결과물(스크린샷, GIF)을 첨부하여 리뷰어의 인지 부하를 줄여라.
|
||||
- **Code Review Protocol**:
|
||||
- P1(필수 반영), P2(권장), P3(질문/의견) 식으로 중요도를 표시하라. 비판은 날카롭게 하되 표현은 따뜻하게 하여 팀의 심리적 안정성을 유지하라.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 애플리케이션 안정성 및 로깅 (Error Boundary)
|
||||
category: Software Architecture
|
||||
tags: [Reliability, Error Boundary, Sentry, Logging, Stability]
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[Reliability]], Error Boundary, Sentry, Logging, [[Stability]]]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -24,5 +24,5 @@ created: 2026-04-20
|
||||
- 모든 곳에 에러 바운더리를 칠 필요는 없다. 데이터와 UI가 1:1로 매칭되는 구조라면 차라리 상위에서 에러를 처리하는 것이 논리적으로 명확할 수 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[System_Debugging_Protocol]] , [[React_Testing_Strategy]]
|
||||
- Related: [[System_Debugging_Protocol]] , [[React_[[Testing]]_Strategy]]
|
||||
- Foundation: [[System_Protocol_Standard]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 스타일 거버넌스 및 디자인 시스템
|
||||
category: Software Architecture
|
||||
tags: [Styling, Tailwind, CSS-in-JS, Design System, Responsive]
|
||||
category: Software [[Architecture]]
|
||||
tags: [Styling, Tailwind, [[CSS-in-JS]], Design[[ system]], Responsive]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -11,11 +11,11 @@ created: 2026-04-20
|
||||
> 디자인은 '예쁜 픽셀'이 아니라 '일관된 약속'이다. 단 하나의 변수가 바뀌었을 때 전체 앱의 조화가 유지되는 구조가 진짜 디자인 시스템이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Design Tokens (디자인 토큰)**:
|
||||
- **[[Design Tokens]] (디자인 토큰)**:
|
||||
- 색상(#FF0000 -> `brand-primary`), 여백(16px -> `spacing-md`)을 추상화된 이름으로 정의하라. 그래야 브랜드 리뉴얼 시 코드 한 줄로 대응 가능하다.
|
||||
- **Utility-First vs Runtime Style**:
|
||||
- **Tailwind CSS**: 클래스명으로 스타일을 정의하여 런타임 오버헤드가 없고 개발 속도가 압도적이다.
|
||||
- **Styled-components**: 컴포넌트 중심의 의미론적 스타일링과 동적 Props 처리에 강점이 있다.
|
||||
- **[[Tailwind CSS]]**: 클래스명으로 스타일을 정의하여 런타임 오버헤드가 없고 개발 속도가 압도적이다.
|
||||
- **[[styled-components]]**: 컴포넌트 중심의 의미론적 스타일링과 동적 Props 처리에 강점이 있다.
|
||||
- **Mobile First Responsive**:
|
||||
- 작은 화면부터 디자인을 시작하여 넓은 화면으로 확장하라. 이것이 CSS 코드를 30% 이상 줄이는 지름길이다.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 단계별 시스템 디버깅 체크리스트 (L1~L3)
|
||||
category: Software Architecture
|
||||
category: Software [[Architecture]]
|
||||
tags: [Debugging, Troubleshooting, Checklist, Process]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 표준 시스템 통신 프로토콜 및 상태 제어
|
||||
category: Software Architecture
|
||||
tags: [Protocol, State Machine, Data Exchange, Lifecycle]
|
||||
category: Software [[Architecture]]
|
||||
tags: [Protocol, [[State]] Machine, Data Exchange, Lifecycle]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -16,7 +16,7 @@ created: 2026-04-20
|
||||
- `UPDATE`: 엔진 계산 결과의 브로드캐스트.
|
||||
|
||||
## 🔄 시스템 생명 주기 (Life Cycle)
|
||||
시스템은 [초기화 $\rightarrow$ 활성 루프 $\rightarrow$ 종료/정리]의 명확한 단계를 거쳐야 리소스 누수(Memory Leak)를 방지할 수 있습니다.
|
||||
시스템은 [초기화 $\rightarrow$ 활성 루프 $\rightarrow$ 종료/정리]의 명확한 단계를 거쳐야 리소스 누수([[memory]] Leak)를 방지할 수 있습니다.
|
||||
|
||||
## 🚨 상태 머신 (State Machine) 도입
|
||||
시스템 복잡도가 임계치를 넘을 경우, `READY`, `RUNNING`, `PAUSED` 등 상태를 명시적으로 제어하는 **State Machine** 적용을 원칙으로 삼습니다.
|
||||
|
||||
@@ -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]]에서 최대 20명의 플레이어가 동시에 참여하여 거대한 스펙터클과 혼란을 만들어내는 대규모 전술 게임 모드입니다 [1]. 이 모드에서는 유닛과 플레이어의 밀도가 매우 높아 강력한 포격과 촘촘한 방공망이 형성되며, 플레이어는 전장 전체가 아닌 특정 구역에 집중하여 전투를 수행할 수 있습니다 [1]. WARNO의 기반인 Iriszoom 엔진은 수백 개의 유닛이 기동하고 파괴되는 이러한 극단적인 환경 속에서도 4K 해상도와 풀 옵션을 안정적으로 유지할 수 있는 고도의 데이터 최적화 성능을 자랑합니다 [2, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **엔진 최적화 및 시각 데이터 처리:** 10v10 멀티플레이어 매치는 시스템에 엄청난 부하를 주지만, Iriszoom 엔진은 이를 원활하게 처리하도록 설계되었습니다 [2]. 수백 개의 개별 유닛이 동시에 전장에서 충돌하고 파괴되는 10 대 10 환경에서도 게임은 4K 해상도와 풀 옵션 설정에서 안정적인 성능을 보여줍니다 [3]. 또한 네이팜, 연막, 폭발 등의 시각적 효과 데이터가 10v10 모드에서도 효과가 종료되기 전에 사라지지 않고 명확하게 렌더링되도록 최적화되었습니다 [4].
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# [[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]])와 같은 기술의 도입으로 아이디어의 고속 대량 생산, 시각적 정체성의 일관성 유지, 정교한 사후 편집이 맞물린 체계적 작업이 가능해졌다 [3-5]. 이에 따라 이미지 프롬프트 작성법 역시 단순한 단어의 나열을 넘어, 카메라 물리 법칙이나 조명 과학 등의 시각적 전문 지식을 반영하고 각 AI 모델의 고유한 통제 언어를 다루는 고도화된 프롬프트 엔지니어링으로 격상되었다 [2, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
* **프롬프트 엔지니어링의 구조화 및 전문화**
|
||||
성공적인 시각 언어 생성 프롬프트는 인공지능의 신경망 구조에 부합하도록 주체(Subject), 매체(Medium), 환경(Environment), 조명(Lighting), 기술적 매개변수(Parameters) 등 5가지 핵심 층위로 구성된다 [7, 8]. 특히 2026년에는 '85mm 렌즈', '얕은 피사계 심도' 같은 렌즈 물리학이나, '볼륨메트릭 라이팅(Volumetric Lighting)', '치아로스쿠로(Chiaroscuro)' 같은 조명 과학 기반의 정밀 키워드가 이미지의 깊이와 서사를 결정짓는 핵심 수단으로 활용된다 [6, 9].
|
||||
성공적인 시각 언어 생성 프롬프트는 인공지능의 신경망 구조에 부합하도록 주체(Subject), 매체(Medium), 환경(Environment), 조명(Lighting), 기술적 매개변수([[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)]]`, `[[에이전틱 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]]*
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-EB3F3C
|
||||
id: [[P-Reinforce]]-AUTO-EB3F3C
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
@@ -10,17 +10,17 @@ 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].
|
||||
> '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)가 개발한 `instancedMesh2` 라이브러리를 기반으로 하며, 대규모 스킨드 메쉬를 렌더링하기 위해 다음과 같은 세부 최적화 기술들을 사용했습니다 [2].
|
||||
이 데모는 제작자(agargaro)가 개발한 `[[InstancedMesh]]2` 라이브러리를 기반으로 하며, 대규모 스킨드 메쉬를 렌더링하기 위해 다음과 같은 세부 최적화 기술들을 사용했습니다 [2].
|
||||
|
||||
* **프러스텀 컬링 및 시야 기반 업데이트 (Frustum Culling & View-based Updates):**
|
||||
* **프러스텀 컬링 및 시야 기반 업데이트 ([[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].
|
||||
`meshoptimizer`를 활용해 5단계의 기하학적 LOD를 생성했습니다 [2]. 거리가 먼 인스턴스에 대해서는 일부 뼈대 계산을 생략하며, 각 LOD마다 1개의 드로우 콜([[Draw Call]])만 발생시켜 총 5개의 드로우 콜만으로 렌더링을 완료합니다 [2, 3]. 또한, 그림자(Shadows) 렌더링 시에도 LOD를 관리할 수 있도록 구성되어 있습니다 [4].
|
||||
* **개별 애니메이션 지원:**
|
||||
단일 인스턴스들의 복제본들이 모두 동일한 애니메이션과 포즈를 공유하는 것이 아니라, 각 인스턴스마다 서로 다른 애니메이션을 가집니다 [5, 6]. 이 데모에서는 하나의 애니메이션 믹서(Mixer)를 사용했지만, 필요에 따라 인스턴스별로 믹서를 생성할 수도 있습니다 [6].
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
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]
|
||||
tags: [ux, ab-[[Testing]], data-driven-design, cro, micro-conversions, product-growth]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
@@ -12,11 +12,11 @@ last_reinforced: 2026-04-26
|
||||
> "디자인의 주관적 미학을 통계적 객관성으로 치환하고, 사용자의 실제 행동 데이터를 나침반 삼아 비즈니스 전환율의 임계점을 돌파하라" — 가설을 검증하고 사용자 경험의 마찰을 수치로 정밀 타격하는 현대 프로덕트 성장의 핵심 엔진.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Empirical Validation and Iterative Optimization" — 직관이나 가정에 의존하는 대신, 트래픽을 대조군(Control)과 실험군(Test)으로 분리하여 특정 UI 변경이 미치는 인과관계를 데이터로 증명하는 패턴.
|
||||
- **추출된 패턴:** "Empirical Validation and Iterative [[Optimization]]" — 직관이나 가정에 의존하는 대신, 트래픽을 대조군(Control)과 실험군(Test)으로 분리하여 특정 UI 변경이 미치는 인과관계를 데이터로 증명하는 패턴.
|
||||
- **핵심 방법론 및 도구:**
|
||||
- **A/B & Multivariate Testing:** 단일 또는 다중 변수의 변경이 최종 전환율에 미치는 영향을 분리 및 검증.
|
||||
- **Micro-conversions:** 최종 목표(구매 등) 이전의 행동(스크롤, 클릭, 시청)을 추적하여 사용자 의도 파악.
|
||||
- **Behavioral Analysis:** 히트맵(Heatmaps)과 세션 녹화(Session Recording)를 통해 정량적 지표 뒤에 숨겨진 정성적 마찰 지점 식별.
|
||||
- **[[Behavior]]al [[Analysis]]:** 히트맵(Heatmaps)과 세션 녹화(Session Recording)를 통해 정량적 지표 뒤에 숨겨진 정성적 마찰 지점 식별.
|
||||
- **Progressive Rollouts:** 리스크 최소화를 위해 신규 디자인을 특정 세그먼트에게만 점진적으로 노출.
|
||||
- **의의:** 디자인 결정의 불확실성을 제거하고, 지속적인 실험 루프를 통해 제품의 비즈니스 가치를 과학적으로 극대화함.
|
||||
|
||||
@@ -25,5 +25,5 @@ last_reinforced: 2026-04-26
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 주요 UI 변경 시 최소 10%의 트래픽에 대해 A/B 테스트를 선행하며, 데이터 기반의 근거 없이는 레이아웃 변경을 승인하지 않는 'Evidence-based Design' 정책을 고수함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- User-Centered-Design, Conversion-Rate-Optimization-CRO, [[Hypothesis-Testing]], Product-Management-Best-Practices
|
||||
- User-Centered-Design, Conversion-Rate-Optimization-CRO, [[Hypothesis-Testing]], Product-[[Management]]-Best-Practices
|
||||
- **Raw Source:** 00_Raw/A-B 테스트 및 데이터 기반 UX 검증 환경.md
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
id: ABA-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [psychology, behavioral-science, reinforcement-learning, aba, pedagogy]
|
||||
tags: [[[Psychology]], [[Behavior]]al-science, [[Reinforcement-Learning]], aba, pedagogy]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# ABA (Applied Behavior Analysis, 응용 행동 분석)
|
||||
# ABA (Applied Behavior [[Analysis]], 응용 행동 분석)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "행동의 원인을 분석하고, 보상 설계를 통해 바람직한 변화를 이끌어내라" — 행동주의 심리학에 근거하여 인간의 행동을 객관적으로 측정하고, 환경 조절과 강화를 통해 사회적으로 유의미한 행동 변화를 유도하는 과학적 방법론.
|
||||
@@ -16,7 +16,7 @@ last_reinforced: 2026-04-26
|
||||
- **핵심 요소:**
|
||||
- **ABC Analysis:** 선행 사건(A), 행동(B), 결과(C)의 연쇄 고리 파악.
|
||||
- **Positive Reinforcement:** 바람직한 행동 뒤에 보상을 주어 행동의 재발 확률을 높임.
|
||||
- **Prompting & Fading:** 초기에는 보조(Prompt)를 통해 행동을 유도하고, 점차 보조를 줄여 독립적 수행을 도움.
|
||||
- **[[prompt]]ing & Fading:** 초기에는 보조(Prompt)를 통해 행동을 유도하고, 점차 보조를 줄여 독립적 수행을 도움.
|
||||
- **Generalization:** 학습된 행동이 치료실 밖의 실제 환경에서도 유지되도록 유도.
|
||||
- **의의:** 자폐 스펙트럼 장애 치료뿐만 아니라 조직 관리, 교육, 그리고 인공지능 에이전트의 보상 함수 설계에 광범위하게 응용됨.
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
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]
|
||||
tags: [[[Accessibility]], compliance, ada, eaa, wcag-2-2, pour-[[Principles]], digital-inclusive, legal-risk]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
|
||||
@@ -12,12 +12,12 @@ last_reinforced: 2026-04-26
|
||||
> "인간이 할 수 있는 모든 지적 태스크를 인간 수준 혹은 그 이상으로 수행하는 범용 지능" — 특정 분야에 국한되지 않고 새로운 환경에서 스스로 학습하고, 추론하며, 창의적인 문제를 해결할 수 있는 인공지능의 궁극적 도달점.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 지식의 파편화된 활용을 넘어, 자의식과 메타인지를 바탕으로 도메인을 넘나드는 범용적 문제 해결(General Problem Solving)을 수행하는 완전한 지능 패턴.
|
||||
- **추출된 패턴:** 지식의 파편화된 활용을 넘어, 자의식과 메타인지를 바탕으로 도메인을 넘나드는 범용적 문제 해결(General [[Problem Solving]])을 수행하는 완전한 지능 패턴.
|
||||
- **핵심 특징:**
|
||||
- **Cross-domain Learning:** 수학 문제를 풀던 지능이 소설을 쓰거나 코딩을 하는 등 다양한 분야로 즉각 전이됨.
|
||||
- **Common Sense:** 방대한 경험을 바탕으로 세상의 당연한 이치(상식)를 이해하고 활용.
|
||||
- **Self-Correction:** 자신의 오류를 인지하고 외부의 도움 없이도 지식 체계를 수정 및 업데이트.
|
||||
- **Abstract Reasoning:** 구체적인 사례 없이도 원리와 개념만으로 복잡한 논리를 전개.
|
||||
- **[[Self-Correction]]:** 자신의 오류를 인지하고 외부의 도움 없이도 지식 체계를 수정 및 업데이트.
|
||||
- **Abstract [[Reasoning]]:** 구체적인 사례 없이도 원리와 개념만으로 복잡한 논리를 전개.
|
||||
- **예상 시점:** 연구자마다 견해가 다르나, LLM의 등장으로 AGI로 가는 길이 가속화되었다는 평이 지배적.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-AIDS-001
|
||||
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]
|
||||
|
||||
@@ -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]]에서 최대 20명의 플레이어가 동시에 참여하여 거대한 스펙터클과 혼란을 만들어내는 대규모 전술 게임 모드입니다 [1]. 이 모드에서는 유닛과 플레이어의 밀도가 매우 높아 강력한 포격과 촘촘한 방공망이 형성되며, 플레이어는 전장 전체가 아닌 특정 구역에 집중하여 전투를 수행할 수 있습니다 [1]. WARNO의 기반인 Iriszoom 엔진은 수백 개의 유닛이 기동하고 파괴되는 이러한 극단적인 환경 속에서도 4K 해상도와 풀 옵션을 안정적으로 유지할 수 있는 고도의 데이터 최적화 성능을 자랑합니다 [2, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **엔진 최적화 및 시각 데이터 처리:** 10v10 멀티플레이어 매치는 시스템에 엄청난 부하를 주지만, Iriszoom 엔진은 이를 원활하게 처리하도록 설계되었습니다 [2]. 수백 개의 개별 유닛이 동시에 전장에서 충돌하고 파괴되는 10 대 10 환경에서도 게임은 4K 해상도와 풀 옵션 설정에서 안정적인 성능을 보여줍니다 [3]. 또한 네이팜, 연막, 폭발 등의 시각적 효과 데이터가 10v10 모드에서도 효과가 종료되기 전에 사라지지 않고 명확하게 렌더링되도록 최적화되었습니다 [4].
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
id: P-REINFORCE-5267ED
|
||||
id: [[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]]"
|
||||
---
|
||||
|
||||
# [[AlphaZero Strategy]]
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# Combined Arms (제병협동) 전술
|
||||
|
||||
## 📌 Brief Summary
|
||||
Combined Arms (제병협동) 전술은 보병, 기갑, 포병, 항공 지원 및 정찰 등 다양한 병과를 조화롭게 통합하여 승리를 쟁취하는 WARNO의 핵심 전술입니다 [1]. 이는 가위바위보와 같은 상성 원리를 기반으로 작동하며, 다양한 유닛이 서로를 지원하고 약점을 보완하도록 전술적 진형을 갖추어 교전을 통제하는 것을 의미합니다 [2-4].
|
||||
## 📌[[ brief]] Summary
|
||||
Combined Arms (제병협동) 전술은 보병, 기갑, 포병, 항공 지원 및 정찰 등 다양한 병과를 조화롭게 통합하여 승리를 쟁취하는 [[WARNO]]의 핵심 전술입니다 [1]. 이는 가위바위보와 같은 상성 원리를 기반으로 작동하며, 다양한 유닛이 서로를 지원하고 약점을 보완하도록 전술적 진형을 갖추어 교전을 통제하는 것을 의미합니다 [2-4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **가위바위보 기반의 상성 원리:** WARNO의 전투는 기본적으로 공격 헬기가 전차를 이기고, 대공포가 공격 헬기를 이기며, 전차가 대공포를 이기는 식의 상성(rock-paper-scissors) 원리로 작동합니다 [3, 5]. 따라서 적이 어떤 유닛을 투입하든 즉각적으로 카운터 유닛으로 대응할 수 있도록, 사전에 전장에 다양한 병과를 미리 전개해 두는 것이 제병협동의 기초입니다 [4, 5].
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# Eugen Systems 모딩 매뉴얼
|
||||
# Eugen[[ system]]s 모딩 매뉴얼
|
||||
|
||||
## 📌 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]]의 [[WARNO]] 모딩 매뉴얼은 플레이어가 게임 소스 코드를 직접 수정하지 않고도 게임 내 데이터 포맷인 NDF(Neutral Data Format) 파일을 편집하여 새로운 유닛, 무기, 사단 등을 추가하거나 밸런스를 변경할 수 있도록 돕는 지침이다 [1, 2]. 게임 설치 폴더에 포함된 공식 매뉴얼(Modding Manual, NDF [[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].
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# Eugen Systems의 Iriszoom 엔진 및 전략 게임 개발
|
||||
# Eugen[[ system]]s의 Iriszoom 엔진 및 전략 게임 개발
|
||||
|
||||
## 📌 Brief Summary
|
||||
Eugen Systems가 개발한 WARNO는 독자적인 Iriszoom 엔진을 기반으로 구축된 현대 실시간 전술 및 턴제 전략 게임이다 [1, 2]. 이 엔진은 수 킬로미터에 달하는 광활한 전략적 시야와 개별 병사의 무장까지 확인 가능한 세밀한 전술적 시점을 매끄럽게 연결하며, 물리 기반 렌더링(PBR)을 통해 전장의 시각적 사실성을 극대화한다 [3, 4]. 전작인 Wargame과 Steel Division 시리즈의 성공적인 요소를 계승하면서도, 고도화된 데이터 중심 설계(Data-Driven Design)를 결합하여 복잡한 현대 전술 시뮬레이션을 구현해냈다 [2, 5].
|
||||
## 📌[[ brief]] Summary
|
||||
[[Eugen Systems]]가 개발한 [[WARNO]]는 독자적인 Iriszoom 엔진을 기반으로 구축된 현대 실시간 전술 및 턴제 전략 게임이다 [1, 2]. 이 엔진은 수 킬로미터에 달하는 광활한 전략적 시야와 개별 병사의 무장까지 확인 가능한 세밀한 전술적 시점을 매끄럽게 연결하며, 물리 기반 렌더링(PBR)을 통해 전장의 시각적 사실성을 극대화한다 [3, 4]. 전작인 Wargame과 Steel Division 시리즈의 성공적인 요소를 계승하면서도, 고도화된 데이터 중심 설계(Data-Driven Design)를 결합하여 복잡한 현대 전술 시뮬레이션을 구현해냈다 [2, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
@@ -15,7 +15,7 @@ Eugen Systems가 개발한 WARNO는 독자적인 Iriszoom 엔진을 기반으로
|
||||
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]. 또한, Metallic/Roughness/Ambient Occlusion 워크플로우를 적용해 이전의 Specular/Glossiness 방식보다 금속 및 비금속 등 재질을 물리 법칙에 맞게 사실적으로 묘사한다 [4, 7, 8].
|
||||
WARNO에 도입된 최신 엔진은 물리 기반 렌더링(PBR) 시스템과 지연 렌더링(Deferred Rendering) 구조를 전면 도입하였다 [3, 4]. 이를 통해 원거리 시야에서 발생할 수 있는 스펙큘러 폭발(Specular explosion) 노이즈를 효과적으로 억제하고, 4K 해상도의 텍스처를 지원한다 [3, 8]. 또한, [[Metal]]lic/Roughness/Ambient Occlusion 워크플로우를 적용해 이전의 Specular/Glossiness 방식보다 금속 및 비금속 등 재질을 물리 법칙에 맞게 사실적으로 묘사한다 [4, 7, 8].
|
||||
|
||||
* **동적 파괴 시스템과 데이터의 물리적 연동**
|
||||
게임 내 유닛의 파괴는 단순한 폭발 이펙트가 아니라 상태 데이터와 동기화된 물리적 현상으로 처리된다 [7]. 탄약고 유폭 시 전차의 포탑이 사출되거나 헬리콥터의 로터 블레이드 및 터빈이 비산하는 등 정교한 파괴 모션이 구현된다 [7, 9]. 파괴된 잔해나 폭발 분화구는 사라지지 않고 전장에 영구적으로 남아 '영속적 전장(Persistent Battlefield)'을 시각적으로 가시화한다 [7, 9].
|
||||
|
||||
@@ -4,14 +4,14 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# Eugen Systems의 WARNO 시뮬레이션 개발
|
||||
# Eugen[[ system]]s의 [[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]]가 개발한 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) 시스템과 Metallic/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]]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].
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# Eugen Systems의 냉전기 가상 시나리오 및 모딩 생태계 구축
|
||||
# Eugen[[ system]]s의 냉전기 가상 시나리오 및 모딩 생태계 구축
|
||||
|
||||
## 📌 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]]의 [[WARNO]]는 1987년 소련 강경파의 쿠데타를 기점으로 1989년에 제3차 세계대전이 발발했다는 가상의 '냉전기 열전(Cold War Gone Hot)' 시나리오를 배경으로 합니다 [1, 2]. 이 가상 시나리오는 실제 역사적 사단 편제표(TO&E)를 철저한 데이터 구조로 치환하여 게임 내 규칙으로 적용한 데이터 기반 설계를 특징으로 합니다 [2]. 더 나아가, 독자적인 NDF(Neutral Data Format) 시스템을 통해 소스코드 수정 없이도 게임 데이터를 제어할 수 있게 하여, 커뮤니티 주도의 분석 도구 및 모드(Mod) 개발이 활발히 이루어지는 개방적인 생태계를 구축했습니다 [2, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **가상 냉전 시나리오의 데이터적 구현**
|
||||
@@ -21,7 +21,7 @@ Eugen Systems의 WARNO는 1987년 소련 강경파의 쿠데타를 기점으로
|
||||
* Eugen Systems는 사용자를 위해 `CreateNewMod.bat` 등의 배치 파일과 모딩 매뉴얼, NDF 참조 가이드를 제공하여 손쉽게 모드 환경을 구축할 수 있게 돕고 있습니다 [3, 5].
|
||||
|
||||
* **데이터 민주화와 커뮤니티 생태계 확장**
|
||||
* NDF 파일의 구조적 접근성 덕분에 커뮤니티는 숨겨진 게임 내부 수치를 파싱하여 War-Yes, Warno-Armory와 같은 정밀한 데이터 분석 웹사이트와 툴을 자체적으로 개발할 수 있었습니다 [2, 6, 7].
|
||||
* NDF 파일의 구조적 접근성 덕분에 커뮤니티는 숨겨진 게임 내부 수치를 파싱하여 [[War-Yes]], [[Warno-Armory]]와 같은 정밀한 데이터 분석 웹사이트와 툴을 자체적으로 개발할 수 있었습니다 [2, 6, 7].
|
||||
* 또한, 흩어진 NDF 속성들의 의미와 핵심 게임 메커니즘을 문서화하기 위해 WARNO-DATA와 같은 광범위한 오픈소스 위키 프로젝트가 진행되기도 했습니다 [2, 8].
|
||||
* 이러한 생태계의 개방성은 모든 무기 데이터를 실제 현실의 제원값으로 치환하고 시뮬레이션 경제를 재설계한 'RebsFRAGO'와 같은 고도의 현실주의 모드(Realism Mod)가 탄생하는 기술적 근간이 되었습니다 [2, 9].
|
||||
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# Steel Division 시리즈
|
||||
|
||||
## 📌 Brief Summary
|
||||
'Steel Division 시리즈'는 Eugen Systems가 개발한 실시간 전술 및 전략 비디오 게임 시리즈로, 《Steel Division: Normandy 44》와 《Steel Division 2》를 포함합니다 [1]. 이 시리즈는 역사적 군 편제표에 기반한 사단(Division) 덱 시스템, 스마트 오더, Army General 캠페인과 같은 핵심 시스템을 도입했습니다 [2, 3]. 이러한 메커니즘은 이후 《WARNO》의 정교한 데이터 기반 설계와 전술적 게임플레이를 구축하는 데 직접적이고 결정적인 토대가 되었습니다 [4, 5].
|
||||
## 📌[[ brief]] Summary
|
||||
'Steel Division 시리즈'는 Eugen[[ system]]s가 개발한 실시간 전술 및 전략 비디오 게임 시리즈로, 《Steel Division: Normandy 44》와 《Steel Division 2》를 포함합니다 [1]. 이 시리즈는 역사적 군 편제표에 기반한 사단(Division) 덱 시스템, 스마트 오더, Army General 캠페인과 같은 핵심 시스템을 도입했습니다 [2, 3]. 이러한 메커니즘은 이후 《[[WARNO]]》의 정교한 데이터 기반 설계와 전술적 게임플레이를 구축하는 데 직접적이고 결정적인 토대가 되었습니다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
* **WARNO 설계의 기술적·전술적 토대:**
|
||||
@@ -20,7 +20,7 @@ converted_at: 2026-04-28
|
||||
《Steel Division 2》에서 처음 도입된 혁신적인 AI 편의성 도구들이 《WARNO》에 그대로 이식되었습니다 [2, 3, 10]. '스마트 오더'는 부대의 마이크로 컨트롤을 컴퓨터에 위임하여 그룹 구성, 지형, 도로, 적의 상대적 강도 등 다양한 전술적 데이터를 AI가 통합적으로 계산해 명령을 수행하게 합니다 [2, 11]. '교전 수칙'은 유닛이 전장의 변화하는 조건에 맞춰 더 독립적이고 지능적으로 행동하도록 규칙을 설정할 수 있게 해줍니다 [10].
|
||||
|
||||
* **전략적 깊이를 더하는 싱글플레이어 콘텐츠:**
|
||||
《WARNO》는 《Steel Division 2》로부터 턴제 기반의 전략 캠페인인 'Army General'과 실시간 'Operations(작전)' 모드 등 전용 싱글플레이어 콘텐츠를 성공적으로 통합했습니다 [3]. 이를 통해 개별 전술 전투뿐만 아니라 대규모 작전 단위의 시뮬레이션을 구현할 수 있었습니다.
|
||||
《WARNO》는 《Steel Division 2》로부터 턴제 기반의 전략 캠페인인 'Army General'과 실시간 '[[Opera]]tions(작전)' 모드 등 전용 싱글플레이어 콘텐츠를 성공적으로 통합했습니다 [3]. 이를 통해 개별 전술 전투뿐만 아니라 대규모 작전 단위의 시뮬레이션을 구현할 수 있었습니다.
|
||||
|
||||
* **장갑 관통 및 피해 연산의 진화:**
|
||||
《Steel Division》 시리즈는 장갑 관통 확률과 거리에 따른 스케일링 계산법에 있어 지속적인 변화와 발전을 거쳤습니다 [12]. 1편에서 2편으로 넘어가며 계산 방식이 변경되었으며 [13], 이는 《WARNO》에 이르러 운동에너지(KE) 탄자와 성형작약탄(HEAT)의 데이터적 차별화로 이어지는 물리적 시뮬레이션 발전의 궤적을 보여줍니다 [14].
|
||||
|
||||
@@ -4,13 +4,13 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO 그래픽 엔진 업그레이드 프로젝트
|
||||
# [[WARNO]] 그래픽 엔진 업그레이드 프로젝트
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO 그래픽 엔진 업그레이드 프로젝트는 Eugen Systems의 독자적인 기술인 Iriszoom 엔진을 최신 산업 표준에 맞게 진화시킨 프로젝트입니다 [1, 2]. 이 업그레이드는 물리 기반 렌더링(PBR) 시스템을 전면 도입하여 유닛과 지형의 시각적 사실성을 극대화했습니다 [1, 2]. 4K 텍스처와 물리 데이터가 연동된 정교한 파괴 시스템을 적용하면서도 뛰어난 최적화를 달성하여 전작인 Steel Division 2 수준의 시스템 요구 사양을 유지한 것이 핵심입니다 [3, 4].
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO 그래픽 엔진 업그레이드 프로젝트는 Eugen[[ system]]s의 독자적인 기술인 Iriszoom 엔진을 최신 산업 표준에 맞게 진화시킨 프로젝트입니다 [1, 2]. 이 업그레이드는 물리 기반 렌더링(PBR) 시스템을 전면 도입하여 유닛과 지형의 시각적 사실성을 극대화했습니다 [1, 2]. 4K 텍스처와 물리 데이터가 연동된 정교한 파괴 시스템을 적용하면서도 뛰어난 최적화를 달성하여 전작인 Steel Division 2 수준의 시스템 요구 사양을 유지한 것이 핵심입니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **Iriszoom 엔진의 진화와 PBR 파이프라인 도입:** R.U.S.E.부터 이어져 온 독자적인 엔진 기술을 발전시켜 수 킬로미터의 광활한 전략적 조감 시점과 개별 병사를 식별할 수 있는 전술적 시점을 매끄럽게 연결합니다 [2]. 기존의 Specular/Glossiness 방식 대신 최첨단 Metallic/Roughness/Ambient Occlusion 워크플로우를 자산 생산 파이프라인에 전면 도입했습니다 [2, 3]. 이를 통해 모든 유닛에 4K PBR 텍스처와 세밀한 모델링을 적용하였으며, 사진학적 설정을 활용한 새로운 톤 매핑 알고리즘으로 사실성을 높였습니다 [2, 3]. 지연 렌더링(Deferred Rendering) 구조를 활용해 원거리에서 폭발적으로 발생하는 PBR 스펙큘러 노이즈 문제도 효과적으로 해결했습니다 [1, 2].
|
||||
* **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].
|
||||
|
||||
* **데이터가 연동된 동적 파괴 시스템:** 유닛이 피해를 입고 파괴되는 시각적 효과가 실제 전투 상태 데이터와 동기화되어 작동합니다 [4]. 단순히 폭발 효과만 출력하는 것이 아니라 유닛의 장갑이나 장비 조각이 떨어져 나가며, 파괴 시 탄약고 유폭으로 포탑이 사출되거나 헬리콥터 로터 블레이드 및 비행기 날개가 날아가는 사실적인 물리적 폭발 효과가 구현되었습니다 [4, 5]. 또한, 유닛 텍스처가 파손 상태를 직접적으로 반영하여 손상도를 시각화합니다 [5].
|
||||
|
||||
|
||||
@@ -4,13 +4,13 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO 데이터 기반 밸런싱
|
||||
# [[WARNO]] 데이터 기반 밸런싱
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 밸런싱은 커뮤니티의 단순한 여론이나 개발진의 임의적 결정이 아닌, 수집된 방대한 텔레메트리(Telemetry) 데이터를 기반으로 객관적으로 이루어지는 시스템적 과정이다 [1], [2]. Eugen Systems는 유닛의 선택 빈도, 승률, 킬/데스 비율, 평균 생존 시간 등을 종합적으로 분석하여 포인트 비용, 무장 스펙, 사단별 가용성을 NDF 파일을 통해 세밀하게 조정한다 [2], [3]. 이러한 데이터 중심 설계는 특정 진영에 압도적인 우위가 고착되는 것을 방지하고, 게임이 지속적으로 균형 잡힌 전술 생태계로 기능하게 만든다 [3].
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 밸런싱은 커뮤니티의 단순한 여론이나 개발진의 임의적 결정이 아닌, 수집된 방대한 텔레메트리(Telemetry) 데이터를 기반으로 객관적으로 이루어지는 시스템적 과정이다 [1], [2]. Eugen[[ system]]s는 유닛의 선택 빈도, 승률, 킬/데스 비율, 평균 생존 시간 등을 종합적으로 분석하여 포인트 비용, 무장 스펙, 사단별 가용성을 NDF 파일을 통해 세밀하게 조정한다 [2], [3]. 이러한 데이터 중심 설계는 특정 진영에 압도적인 우위가 고착되는 것을 방지하고, 게임이 지속적으로 균형 잡힌 전술 생태계로 기능하게 만든다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **텔레메트리(Telemetry) 기반의 객관적 분석:** Eugen Systems는 게임 출시 후 유저들의 플레이에서 발생하는 텔레메트리 데이터를 실시간으로 기록한다. 여기에는 어떤 유닛이 자주 선택되는지(Pick Rate), 실제 교전에서의 승률과 킬/데스 비율, 그리고 유닛의 평균 생존 시간 등이 포함된다 [2]. 개발진은 미숙련 플레이어들의 변덕스러운 여론에 직접적으로 휘둘리기보다는, 전문 테스터의 피드백과 수집된 텔레메트리 데이터를 교차 검증하여 게임 내 실제 작동 방식을 기준으로 밸런스를 조정한다 [4], [1].
|
||||
* **텔레메트리(Telemetry) 기반의 객관적 분석:** [[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].
|
||||
|
||||
@@ -4,13 +4,13 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO 데이터 기반 설계
|
||||
# [[WARNO]] 데이터 기반 설계
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO는 1980년대 후반 냉전의 군사 교리와 장비 제원을 고도의 데이터 아키텍처로 치환하여 설계된 실시간 전술 시뮬레이션 게임입니다 [1]. 이 시스템은 Eugen Systems의 독자적인 Iriszoom 엔진과 NDF(Neutral Data Format) 스크립트 언어를 활용하여, 게임 코드와 데이터 값을 엄격히 분리한 '데이터 기반 설계(Data-Driven Design)' 철학을 바탕으로 구축되었습니다 [2]. 정밀한 명중률 알고리즘, 물리적 장갑 관통 모델, 심리적 제압 수치화, 그리고 텔레메트리에 기반한 밸런싱을 통해 플레이어에게 고도로 현실적이고 동적인 전술 환경을 제공합니다 [3-5].
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO는 1980년대 후반 냉전의 군사 교리와 장비 제원을 고도의 데이터 아키텍처로 치환하여 설계된 실시간 전술 시뮬레이션 게임입니다 [1]. 이 시스템은 Eugen[[ system]]s의 독자적인 Iriszoom 엔진과 NDF(Neutral Data Format) 스크립트 언어를 활용하여, 게임 코드와 데이터 값을 엄격히 분리한 '데이터 기반 설계(Data-Driven Design)' 철학을 바탕으로 구축되었습니다 [2]. 정밀한 명중률 알고리즘, 물리적 장갑 관통 모델, 심리적 제압 수치화, 그리고 텔레메트리에 기반한 밸런싱을 통해 플레이어에게 고도로 현실적이고 동적인 전술 환경을 제공합니다 [3-5].
|
||||
|
||||
## 📖 Core 무Content
|
||||
* **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,7 +19,7 @@ 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]]) 데이터는 은신 수치를 일시적으로 삭감시켜 위치를 노출시킵니다 [17, 18].
|
||||
* **텔레메트리 기반 밸런스 조정:**
|
||||
개발진은 단순히 커뮤니티의 여론에 의존하지 않고, 유닛의 선택 빈도, 킬/데스 비율, 평균 생존 시간 등 방대한 텔레메트리(Telemetry) 데이터를 실시간으로 분석하여 포인트 비용이나 무장 스펙 데이터를 지속적으로 재조정합니다 [5, 19, 20].
|
||||
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO 멀티플레이어 및 경쟁 플레이 밸런스 패치
|
||||
# [[WARNO]] 멀티플레이어 및 경쟁 플레이 밸런스 패치
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 멀티플레이어 및 경쟁 플레이 밸런스 패치는 개발사인 Eugen Systems가 수집하는 방대한 텔레메트리(Telemetry) 데이터를 기반으로 이루어집니다 [1], [2]. 개발진은 커뮤니티의 단순한 여론에 휘둘리지 않고, 유닛 선택률, 승률, 평균 생존 시간 등 객관적인 데이터를 분석하여 게임 내 수치를 정밀하게 조정합니다 [1], [2]. 이러한 데이터 중심의 설계와 지속적인 패치는 WARNO를 편향 없는 공정한 경쟁이 가능한 살아있는 전술 생태계로 유지하는 핵심 원동력입니다 [3].
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 멀티플레이어 및 경쟁 플레이 밸런스 패치는 개발사인 Eugen[[ system]]s가 수집하는 방대한 텔레메트리(Telemetry) 데이터를 기반으로 이루어집니다 [1], [2]. 개발진은 커뮤니티의 단순한 여론에 휘둘리지 않고, 유닛 선택률, 승률, 평균 생존 시간 등 객관적인 데이터를 분석하여 게임 내 수치를 정밀하게 조정합니다 [1], [2]. 이러한 데이터 중심의 설계와 지속적인 패치는 WARNO를 편향 없는 공정한 경쟁이 가능한 살아있는 전술 생태계로 유지하는 핵심 원동력입니다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **텔레메트리 기반의 객관적 밸런싱**
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO 모딩(Modding)
|
||||
# [[WARNO]] 모딩(Modding)
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 모딩은 게임 소스 코드를 직접 수정하지 않고, Eugen Systems의 독자적인 스크립트 언어인 NDF(Neutral Data Format) 파일을 편집하여 게임 내 유닛 데이터, 무기 성능, 시각적 묘사 및 사단 편제 등을 변경하는 과정을 의미합니다. 플레이어와 모더들은 공식 도구와 커뮤니티가 개발한 WME(Warno Mod Editor), ndf-parse 등의 파싱 프로그램을 활용하여 게임의 데이터를 수정할 수 있습니다. 이러한 개방적인 데이터 구조는 현실주의 모드(Reb's FRAGO) 개발이나 새로운 전술적 환경을 구축하는 등 커뮤니티 주도의 확장성을 크게 높여줍니다.
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 모딩은 게임 소스 코드를 직접 수정하지 않고, Eugen[[ system]]s의 독자적인 스크립트 언어인 NDF(Neutral Data Format) 파일을 편집하여 게임 내 유닛 데이터, 무기 성능, 시각적 묘사 및 사단 편제 등을 변경하는 과정을 의미합니다. 플레이어와 모더들은 공식 도구와 커뮤니티가 개발한 WME(Warno Mod Editor), [[ndf-parse]] 등의 파싱 프로그램을 활용하여 게임의 데이터를 수정할 수 있습니다. 이러한 개방적인 데이터 구조는 현실주의 모드(Reb's FRAGO) 개발이나 새로운 전술적 환경을 구축하는 등 커뮤니티 주도의 확장성을 크게 높여줍니다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **모딩 환경의 기반 및 NDF 시스템**
|
||||
@@ -28,7 +28,7 @@ WARNO의 모딩은 게임 소스 코드를 직접 수정하지 않고, Eugen Sys
|
||||
## 🔗 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].
|
||||
- **Contradictions/Notes:** [[Eugen Systems]]는 기본적인 모딩 매뉴얼과 NDF 참조 가이드를 제공하지만, 정작 수천 개의 NDF 파일 내에 담긴 개별 데이터 속성(Property)에 대한 구체적인 설명은 누락되어 있습니다. 이를 극복하기 위해 커뮤니티 주도로 게임 메커니즘과 단위 데이터를 상세히 분석하여 문서화한 WARNO-DATA GitHub 위키가 만들어졌습니다 [29, 30].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -4,15 +4,15 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO 모딩
|
||||
# [[WARNO]] 모딩
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO 모딩은 Eugen Systems의 독자적인 스크립트 언어인 NDF(Neutral Data Format) 파일을 수정하여 게임의 소스 코드 변경 없이 유닛의 성능, 무기 제원, 편제 등을 커스터마이징하는 과정입니다 [1]. 개발사가 공식 모딩 가이드와 생성 도구를 제공하며, 커뮤니티 주도의 다양한 모드 에디터와 데이터 분석 도구가 활성화되어 있습니다 [2-4]. 이를 통해 플레이어는 단순한 수치 조정을 넘어 현실주의 지향 모드 등 자신만의 고유한 전술 시뮬레이션 환경을 데이터 기반으로 직접 구축할 수 있습니다 [4].
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO 모딩은 Eugen[[ system]]s의 독자적인 스크립트 언어인 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]]', '[[War-Yes]]' 등의 데이터 파싱 도구를 통해 공식 문서에 누락된 숨겨진 데이터 구조를 파악하고 모딩에 활용할 수 있습니다 [4, 13, 14].
|
||||
* **대표적인 모딩 사례:** 커뮤니티 모드인 'Reb's FRAGO'는 현실주의(Realism)를 지향하여 게임 내 모든 무기 데이터를 실제 제원값으로 치환하고 시뮬레이션의 시간 축과 경제 시스템을 재설계하는 등 데이터 기반 설계를 극한으로 활용한 대표적인 모딩 사례입니다 [4].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
@@ -4,15 +4,15 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO 밸런싱 및 사단 시스템
|
||||
# [[WARNO]] 밸런싱 및 사단 시스템
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 밸런싱 및 사단 시스템은 역사적 군 편제(TO&E) 데이터와 텔레메트리(Telemetry) 분석을 결합하여 전술적 깊이를 부여하는 핵심 설계 요소입니다. 플레이어는 모든 분야에서 완벽한 유닛 조합을 갖추는 대신 강점과 약점이 명확히 설정된 사단 단위의 덱을 구성해야 하며, 이는 다양한 전술과 팀플레이를 유도합니다. 개발사인 Eugen Systems는 커뮤니티의 주관적 여론보다는 유닛 선택률과 실제 승률 등 객관적 통계 데이터를 기반으로 NDF 파일 수치를 조정하며 지속적인 밸런싱을 수행합니다.
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 밸런싱 및 사단 시스템은 역사적 군 편제(TO&E) 데이터와 텔레메트리(Telemetry) 분석을 결합하여 전술적 깊이를 부여하는 핵심 설계 요소입니다. 플레이어는 모든 분야에서 완벽한 유닛 조합을 갖추는 대신 강점과 약점이 명확히 설정된 사단 단위의 덱을 구성해야 하며, 이는 다양한 전술과 팀플레이를 유도합니다. 개발사인 Eugen[[ system]]s는 커뮤니티의 주관적 여론보다는 유닛 선택률과 실제 승률 등 객관적 통계 데이터를 기반으로 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]]는 커뮤니티의 불만이나 여론에만 의존하지 않고 텔레메트리를 통해 유저들의 실제 유닛 픽률(Pick Rate), 교전 승률, 킬/데스 비율, 평균 생존 시간 등의 데이터를 은밀히 수집합니다 [16], [6]. 이 분석 결과를 토대로 유닛의 포인트 비용, 장전 시간, 조준 시간, 장갑 관통력 등을 재책정하며, 이러한 변경 사항은 게임의 논리적 설계가 담긴 NDF(Neutral Data Format) 파일을 수정함으로써 전장에 즉각적으로 반영됩니다 [17], [18], [19].
|
||||
- **통계에 기반한 진영 간 균형(Faction Balance):** 플레이어 간에는 항상 진영 편향(NATO 또는 PACT가 더 유리하다는 주장)에 대한 논쟁이 있으나, 실제 10v10 대규모 멀티플레이어 데이터를 분석한 결과 게임 시스템 자체에 특정 진영에 대한 압도적인 우위는 발견되지 않았습니다 [20], [21], [19]. 승률의 차이는 주로 플레이어의 전술적 숙련도 차이 및 양 진영 플레이어들의 경험치 풀(Pact를 선호하는 유저들의 평균 플레이 횟수가 약간 더 높음)에서 비롯된 것으로 분석되며, 기본적으로 진영 간 밸런스는 견고하게 유지되고 있습니다 [22], [21].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
@@ -4,13 +4,13 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO 사후 관리 (Post-Launch Management)
|
||||
# [[WARNO]] 사후 관리 (Post-Launch [[Management]])
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 사후 관리는 단순히 유저 커뮤니티의 여론에 의존하는 것이 아니라, 수집된 객관적인 텔레메트리(Telemetry) 데이터를 기반으로 정밀하게 밸런싱을 수행하는 과정을 의미합니다 [1, 2]. 플레이어의 유닛 선택 빈도(Pick rate), 승률, 킬/데스 비율 등의 실시간 데이터를 분석하여 NDF 파일의 수치를 지속적으로 패치합니다 [2]. 이러한 데이터 중심의 사후 지원은 게임을 단순한 정적 시뮬레이션이 아닌 살아있는 전술 생태계로 유지하는 핵심 동력으로 작용합니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **텔레메트리(Telemetry) 기반 밸런싱**: Eugen Systems는 게임 출시 후 텔레메트리 시스템을 통해 플레이어들의 유닛 사용 방식, 선택 빈도(Pick rate), 실제 교전에서의 승률, 킬/데스 비율, 평균 생존 시간 등을 실시간으로 기록 및 모니터링합니다 [1, 2]. 이는 변덕스럽고 비전문적인 커뮤니티 불만에만 의존하지 않고, 객관적인 데이터를 바탕으로 유닛의 실제 성능을 파악하여 패치를 진행하기 위함입니다 [1, 2].
|
||||
* **텔레메트리(Telemetry) 기반 밸런싱**: Eugen[[ system]]s는 게임 출시 후 텔레메트리 시스템을 통해 플레이어들의 유닛 사용 방식, 선택 빈도(Pick rate), 실제 교전에서의 승률, 킬/데스 비율, 평균 생존 시간 등을 실시간으로 기록 및 모니터링합니다 [1, 2]. 이는 변덕스럽고 비전문적인 커뮤니티 불만에만 의존하지 않고, 객관적인 데이터를 바탕으로 유닛의 실제 성능을 파악하여 패치를 진행하기 위함입니다 [1, 2].
|
||||
* **밸런스 조정의 주요 데이터 변수**: 수집된 텔레메트리 데이터 분석 결과를 바탕으로 개발사는 NDF 파일 내의 수치를 직접 수정합니다 [2]. 유닛의 포인트 비용(Point Cost) 재책정, 장전 시간·조준 시간·관통력 수치 등 무장 세부 스펙의 미세 조정, 전술적 역할을 강화하기 위한 새로운 특성(Trait) 할당, 그리고 특정 사단의 승률을 보완하기 위한 보조 유닛 카드 추가 및 가용성 상향 등이 주요 밸런스 변수로 작용합니다 [4].
|
||||
* **전문 테스터 및 커뮤니티 피드백의 교차 검증**: 개발사는 객관적인 텔레메트리 데이터뿐만 아니라 전문 테스터들의 피드백과 커뮤니티 미디어에서 제기되는 의견들의 요약본을 수집합니다 [1]. 이후 해당 피드백이 실제로 유의미한지 텔레메트리 데이터와 비교·대조하여 조정을 진행합니다 [1].
|
||||
* **상호 연결된 데이터 생태계 관리**: WARNO의 데이터는 긴밀하게 연결되어 있어, 수송 트럭의 도로 이동 속도와 같은 단순한 수치 하나를 변경하더라도 해당 트럭을 사용하는 모든 유닛에 미치는 가치 변화와 이를 대체할 수 있는 다른 유닛들의 기회비용까지 모두 고려하여 밸런싱을 진행해야 합니다 [3]. 이렇듯 끊임없는 경쟁 플레이를 위한 엄격한 데이터 기반의 밸런싱 작업이 게임에 대한 지속적인 사후 지원을 의미합니다 [3, 4].
|
||||
|
||||
@@ -4,9 +4,9 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO 실시간 전술(Real-time Tactics) 및 Army General 캠페인
|
||||
# [[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 캠페인 (턴제 전략 요소):**
|
||||
* 캠페인은 보드 워게임이나 대전략 게임과 유사한 턴제 기반의 작전술(Operational warfare)을 다루며, 플레이어는 대대급 부대를 조작하여 기동한다 [7, 8].
|
||||
* 캠페인은 보드 워게임이나 대전략 게임과 유사한 턴제 기반의 작전술([[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 Systems의 Iriszoom 엔진 및 전략 게임 개발]]
|
||||
- **Projects/Contexts:** [[Eugen[[ system]]s의 Iriszoom 엔진 및 전략 게임 개발]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 WARNO의 실시간 전술 전투와 전략 캠페인은 각각 고유한 복잡성을 지니나, 이 두 시스템 모두 역사적 제원과 편제를 반영하는 강력한 '데이터 기반 설계'를 통해 상호 연결되어 전술적 일관성을 유지한다 [9]. 다만 AI의 성능과 관련하여, 전략 맵(Army General)에서는 상대의 약점을 찌르거나 포위를 훌륭하게 수행하지만 실시간 전술 전투에서는 지형을 무시하고 예측 가능하게 전차를 일렬로 밀어붙이는 경향이 있어 한계로 지적된다 [25-27].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,16 +4,16 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 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) 시스템과 Metallic/Roughness 워크플로우를 도입**하여 재질감을 사실적으로 구현했으며, 유닛 파괴 시 탄약고 유폭에 의한 포탑 사출과 같은 물리적 현상을 유닛의 상태 데이터와 동기화하여 '영속적 전장(Persistent Battlefield)'을 만들어 냅니다 [2, 4].
|
||||
WARNO는 Iriszoom 엔진을 활용하여 광활한 전략적 조감과 개별 유닛 단위의 전술적 줌을 단일 렌더링 파이프라인에서 지원합니다 [2]. **물리 기반 렌더링(PBR) 시스템과 [[Metal]]lic/Roughness 워크플로우를 도입**하여 재질감을 사실적으로 구현했으며, 유닛 파괴 시 탄약고 유폭에 의한 포탑 사출과 같은 물리적 현상을 유닛의 상태 데이터와 동기화하여 '영속적 전장(Persistent Battlefield)'을 만들어 냅니다 [2, 4].
|
||||
|
||||
* **NDF (Neutral Data Format) 스크립트 아키텍처**
|
||||
* **[[NDF (Neutral Data Format)]] 스크립트 아키텍처**
|
||||
게임의 모든 논리적 설계는 텍스트 기반 언어인 **NDF 내에 정의되어 있어 게임 코드와 데이터 값이 엄격히 분리**됩니다 [3]. `UniteDescriptor.ndf` (물리/기술 속성), `WeaponDescriptor.ndf` (무기 메커니즘), `Ammunition.ndf` (탄약 타격 로직) 등을 통해 모듈화된 디스크립터를 조립하여 유닛을 생성합니다 [3, 5]. 이 구조는 수천 개의 속성을 체계적으로 관리하며, 신속한 데이터 기반 밸런싱과 유저 모딩을 가능하게 합니다 [3, 5].
|
||||
|
||||
* **수학적 정밀도에 기반한 전투 및 장갑 역학**
|
||||
@@ -23,7 +23,7 @@ WARNO의 전술 시뮬레이션 시스템은 냉전 시대의 군사 교리와
|
||||
유닛들은 500점의 기본 제압 수치를 지니며, 폭발이나 아군 손실 시 수치가 누적되어 '응집력'이 하락합니다 [9]. **제압 상태가 깊어지면 명중률, 재장전 속도, 기동력이 저하**되는 페널티를 받습니다 [9]. 건물(50%) 및 숲(35%)과 같은 지형 데이터는 제압 피해에 대한 저항력을 제공하며, 헌병(Military Police) 특성과 높은 숙련도(Veterancy)는 응집력 회복을 가속하는 등 심리적 전장이 수치화되어 있습니다 [10].
|
||||
|
||||
* **텔레메트리 기반 밸런싱과 모딩 생태계**
|
||||
Eugen Systems는 커뮤니티의 단순 여론이 아닌 **방대한 텔레메트리(픽률, 승률, 킬/데스 비율 등) 데이터를 실시간으로 분석하여 가격, 무장 스펙, 가용성 등을 정밀하게 조정**합니다 [11, 12]. 또한 게임의 개방적인 데이터 구조를 통해 유저들은 NDF를 직접 수정하여 현실주의 모드(예: Reb's FRAGO)를 만들거나, Warno-Armory 및 War-Yes와 같은 데이터 파싱 도구를 제작하여 은닉된 엔진 내부 수치들을 커뮤니티와 공유하고 분석합니다 [13, 14].
|
||||
Eugen[[ system]]s는 커뮤니티의 단순 여론이 아닌 **방대한 텔레메트리(픽률, 승률, 킬/데스 비율 등) 데이터를 실시간으로 분석하여 가격, 무장 스펙, 가용성 등을 정밀하게 조정**합니다 [11, 12]. 또한 게임의 개방적인 데이터 구조를 통해 유저들은 NDF를 직접 수정하여 현실주의 모드(예: Reb's FRAGO)를 만들거나, [[Warno-Armory]] 및 [[War-Yes]]와 같은 데이터 파싱 도구를 제작하여 은닉된 엔진 내부 수치들을 커뮤니티와 공유하고 분석합니다 [13, 14].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Iriszoom 엔진]], [[NDF (Neutral Data Format)]], [[텔레메트리 기반 밸런싱]], [[사단(Division) 덱 시스템]]
|
||||
|
||||
@@ -4,9 +4,9 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO 전투 메커니즘 (Combat Mechanics)
|
||||
# [[WARNO]] 전투 메커니즘 (Combat Mechanics)
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 전투 메커니즘은 단순한 난수 생성을 넘어 타겟과의 거리, 지형, 무기 특성이 복합적으로 작용하는 비선형적 알고리즘으로 구성된 시스템이다 [1]. 게임 엔진과 데이터 구조는 관통력, 명중률 등의 물리적 타격 로직부터 전장의 공포를 반영한 심리적 상태까지 모든 것을 정밀한 수치로 치환하여 모사한다 [2, 3]. 이러한 데이터 중심 설계는 플레이어로 하여금 유닛의 기동, 은폐, 사거리 조절을 끊임없이 최적화하도록 요구하는 깊이 있는 전술적 환경을 제공한다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
@@ -17,7 +17,7 @@ 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]])' 수치만큼 은신 데이터가 일시적으로 삭감되어, 적의 정찰망에 강제로 노출되는 리스크가 발생한다 [15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Iriszoom 엔진]], [[NDF (Neutral Data Format)]], [[데이터 기반 밸런싱]]
|
||||
|
||||
@@ -4,21 +4,21 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 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 Systems의 수천 개의 NDF 파일(UniteDescriptor.ndf, WeaponDescriptor.ndf 등)에 분산된 데이터를 체계적으로 문서화한 위키입니다 [12-14]. 피해량 및 정확도 계산과 같은 핵심 게임 메커니즘에 대한 심층적인 통찰력과 데이터 딕셔너리를 커뮤니티에 제공합니다 [13, 15].
|
||||
* **데이터 추출 및 시각화 플랫폼 ([[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].
|
||||
|
||||
## 🔗 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].
|
||||
- **Contradictions/Notes:** 게임 개발사인 [[Eugen Systems]]는 인게임 무기고나 UI를 통해 모든 데이터를 공개하지 않지만(연사 준비 시간, 위험도 등 은닉 데이터 존재), 커뮤니티는 NDF 파싱 도구를 통해 이러한 데이터를 스스로 발굴하고 공유하여 전술 최적화에 적극적으로 활용하고 있습니다 [1, 7, 16].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -4,15 +4,15 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO 커뮤니티 모딩 생태계
|
||||
# [[WARNO]] 커뮤니티 모딩 생태계
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 커뮤니티 모딩 생태계는 게임의 개방적인 데이터 설계(NDF 시스템)를 바탕으로 유저들이 직접 게임 내 수치와 메커니즘을 분석, 수정, 공유하며 발전시키는 지식 및 창작 환경을 의미합니다 [1, 2]. 개발사인 Eugen Systems가 공식 모딩 가이드와 편집 도구를 제공하여 데이터 접근성을 높였으며, 이를 통해 유저들은 현실주의 모드 개발, 데이터 파싱 도구 제작, 통합 데이터베이스 구축 등 활발한 활동을 이어가고 있습니다 [2-4]. 이는 WARNO가 단순한 정적 게임을 넘어 유저 커뮤니티와 함께 호흡하며 진화하는 확장 가능한 전술 시뮬레이션 플랫폼으로 기능하게 합니다 [5, 6].
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO의 커뮤니티 모딩 생태계는 게임의 개방적인 데이터 설계(NDF 시스템)를 바탕으로 유저들이 직접 게임 내 수치와 메커니즘을 분석, 수정, 공유하며 발전시키는 지식 및 창작 환경을 의미합니다 [1, 2]. 개발사인 Eugen[[ system]]s가 공식 모딩 가이드와 편집 도구를 제공하여 데이터 접근성을 높였으며, 이를 통해 유저들은 현실주의 모드 개발, 데이터 파싱 도구 제작, 통합 데이터베이스 구축 등 활발한 활동을 이어가고 있습니다 [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]]는 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].
|
||||
* **커뮤니티 주도의 지식 문서화(Wiki) 프로젝트:** WARNO의 방대한 유닛 데이터와 수천 개의 NDF 파일에 분산된 게임 메커니즘을 체계적으로 문서화하기 위해 'WARNO-DATA'와 같은 GitHub 기반의 위키 프로젝트가 진행되었습니다 [2, 21, 22]. 이 프로젝트는 유저들이 자발적으로 참여하여 데미지 계산, 명중률 공식 등을 분석하고 기록하는 집단 지성의 장으로 기능합니다 [2, 23].
|
||||
* **현실주의 모드의 등장 (Reb's FRAGO):** 커뮤니티 생태계의 대표적 성과 중 하나는 'RebsFRAGO'와 같은 고도의 현실주의(Realism) 지향 모드입니다 [2, 24]. 이 모드는 임의적인 밸런스 패치를 지양하고 무기의 최대 사거리, 탄약 크기 기반의 데미지, 폭발 반경, 이동 속도 등 모든 데이터를 실제 제원값과 일관된 계산식에 기반하여 재설계함으로써 전술적 현실성을 극대화했습니다 [24-26].
|
||||
|
||||
|
||||
@@ -3,16 +3,16 @@ category: AI & Games
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
# WARNO-DATA Wiki
|
||||
# [[WARNO]]-DATA Wiki
|
||||
|
||||
## ?뱦 Brief Summary
|
||||
WARNO-DATA Wiki??Eugen Systems???꾩닠 ?쒕??덉씠??寃뚯엫??WARNO???좊떅 ?곗씠?곗? ?듭떖 寃뚯엫 硫붿빱?덉쬁???곸꽭??臾몄꽌?뷀븳 而ㅻ??덊떚 二쇰룄???꾨줈?앺듃?낅땲??[1-3]. 寃뚯엫???묐룞 ?쇰━媛 ?닿릿 ?낆옄?곸씤 NDF ?뚯씪?ㅼ쓽 ?뺤떇???대룆?섏뿬, 諛⑸????뚯씪 ?띿뿉 遺꾩궛???띿꽦 媛믩뱾???댄빐?섍린 ?쎄쾶 ?ㅻ챸?섎뒗 寃껋쓣 紐⑺몴濡??⑸땲??[1, 4]. ?대? ?듯빐 紐낆쨷瑜? ?곕?吏 怨꾩궛 ???④꺼吏?硫붿빱?덉쬁???щ챸?섍쾶 怨듦컻?섏뿬 ?뚮젅?댁뼱媛 ?곗씠??以묒떖??寃뚯엫 ?ㅺ퀎瑜?源딆씠 ?댄빐?????덈룄濡??뺤뒿?덈떎 [4, 5].
|
||||
## ?뱦[[ brief]] Summary
|
||||
WARNO-DATA Wiki??Eugen[[ system]]s???꾩닠 ?쒕??덉씠??寃뚯엫??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]]??怨좎쑀 ?щ㎎???섏쿇 媛쒖쓽 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]] 諛?[[War-Yes]]? 媛숈? ?곗씠???뚯떛 ?꾧뎄?ㅺ낵 ?붾텋?? 媛쒕컻???대????④꺼???덈뜕 ?붿쭊 ?섏튂瑜?諛쒓뎬?섏뿬 ?좎?媛 ?뺢탳???곗씠??湲곕컲???꾩닠???섎┰?????덈룄濡??뺣뒗 ?듭떖?곸씤 ??븷???섑뻾?⑸땲??[5, 10].
|
||||
|
||||
## ?뵕 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[?곗씠??湲곕컲 ?ㅺ퀎(Data-Driven Design)]], [[Iriszoom ?붿쭊]]
|
||||
|
||||
@@ -4,13 +4,13 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WARNO-DATA 프로젝트
|
||||
# [[WARNO]]-DATA 프로젝트
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO-DATA 프로젝트는 Eugen Systems의 전술 게임 WARNO를 위해 깃허브(GitHub)에 구축된 광범위한 위키 프로젝트입니다 [1, 2]. 이 프로젝트는 수천 개의 `.ndf` 파일에 분산된 유닛 데이터를 문서화하고 명중률이나 데미지 계산과 같은 게임의 핵심 메커니즘을 상세히 설명하는 데 목적을 두고 있습니다 [3-5]. 공식 모딩 매뉴얼이 제공하지 못하는 데이터 속성의 구체적인 의미를 해독하여 WARNO 커뮤니티와 모더들의 이해를 돕는 커뮤니티 주도형 프로젝트입니다 [3, 6].
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO-DATA 프로젝트는 Eugen[[ system]]s의 전술 게임 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]]의 독자적인 `.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].
|
||||
|
||||
@@ -5,8 +5,8 @@ converted_at: 2026-04-28
|
||||
---
|
||||
# WARNO
|
||||
|
||||
## ?뱦 Brief Summary
|
||||
WARNO??Eugen Systems媛 媛쒕컻???ㅼ떆媛??꾩닠 諛??댁젣 ?꾨왂 寃뚯엫?쇰줈, 1989???됱쟾???댁쟾?쇰줈 移섎떖? 媛?곸쓽 ??李??멸퀎??꾩쓣 諛곌꼍?쇰줈 ?섎뒗 援곗궗 ?쒕??덉씠?섏엯?덈떎 [1, 2]. ??寃뚯엫? ?⑥닚???쒕??덉씠?섏쓣 ?섏뼱 1980?꾨? ?꾨컲??援곗궗 援먮━? ?λ퉬 ?쒖썝??怨좊룄???곗씠???꾪궎?띿쿂濡?援ы쁽??'?곗씠??湲곕컲 ?ㅺ퀎(Data-Driven Design)' 泥좏븰??諛뷀깢?쇰줈 媛쒕컻?섏뿀?듬땲??[2]. ?낆옄?곸씤 NDF ?ㅽ겕由쏀듃 ?몄뼱? Iriszoom ?붿쭊??寃고빀?섏뿬, ?좊떅??臾쇰━??異⑸룎遺???щ━???쒖븬 ?쒖뒪?쒖뿉 ?대Ⅴ湲곌퉴吏 ?꾩옣??紐⑤뱺 ?붿냼瑜??뺢탳???곗씠???섏튂 紐⑤뜽濡?援ъ텞??寃껋씠 ?뱀쭠?낅땲??[3, 4].
|
||||
## ?뱦[[ brief]] Summary
|
||||
WARNO??Eugen[[ system]]s媛 媛쒕컻???ㅼ떆媛??꾩닠 諛??댁젣 ?꾨왂 寃뚯엫?쇰줈, 1989???됱쟾???댁쟾?쇰줈 移섎떖? 媛?곸쓽 ??李??멸퀎??꾩쓣 諛곌꼍?쇰줈 ?섎뒗 援곗궗 ?쒕??덉씠?섏엯?덈떎 [1, 2]. ??寃뚯엫? ?⑥닚???쒕??덉씠?섏쓣 ?섏뼱 1980?꾨? ?꾨컲??援곗궗 援먮━? ?λ퉬 ?쒖썝??怨좊룄???곗씠???꾪궎?띿쿂濡?援ы쁽??'?곗씠??湲곕컲 ?ㅺ퀎(Data-Driven Design)' 泥좏븰??諛뷀깢?쇰줈 媛쒕컻?섏뿀?듬땲??[2]. ?낆옄?곸씤 NDF ?ㅽ겕由쏀듃 ?몄뼱? Iriszoom ?붿쭊??寃고빀?섏뿬, ?좊떅??臾쇰━??異⑸룎遺???щ━???쒖븬 ?쒖뒪?쒖뿉 ?대Ⅴ湲곌퉴吏 ?꾩옣??紐⑤뱺 ?붿냼瑜??뺢탳???곗씠???섏튂 紐⑤뜽濡?援ъ텞??寃껋씠 ?뱀쭠?낅땲??[3, 4].
|
||||
|
||||
## ?뱰 Core Content
|
||||
* **?곗씠??以묒떖???붿쭊 諛?援ъ“ (Iriszoom怨?NDF):**
|
||||
@@ -16,7 +16,7 @@ WARNO??Eugen Systems媛 媛쒕컻???ㅼ떆媛??꾩닠 諛??댁젣 ?꾨왂 寃
|
||||
* **?щ━???꾩옣???섏튂??(?쒖븬 諛??묒쭛??:**
|
||||
?꾩옣?먯꽌???щ━???뺣컯? **'?쒖븬(Suppression)'** 諛?**'?묒쭛??Cohesion)'** ?쒖뒪?쒖쑝濡??곗씠?고솕?⑸땲??[14]. 紐⑤뱺 ?좊떅? 湲곕낯?곸쑝濡?500?먯쓽 ?쒖븬 ?섏튂瑜?吏?덈ʼn, ?쇨꺽?섍굅??二쇰??먯꽌 ??컻??諛쒖깮???뚮쭏???쒖븬 ?곗씠?곌? ?꾩쟻?섏뼱 ?좊떅??紐낆쨷瑜? ?ъ옣???띾룄, 湲곕룞?μ씠 ?섎씫?⑸땲??[14, 15]. 吏???곗씠??嫄대Ъ 50%, ??35% ?쒖븬 ?쇳빐 ????? 諛??좊떅 ?숇젴???곗씠?곌? ?쒖븬 ?꾩쟻 ?띾룄 諛??뚮났 ?띾룄??吏곸젒?곸쑝濡?媛쒖엯?섎룄濡??ㅺ퀎?섏뿀?듬땲??[15, 16].
|
||||
* **?붾젅硫뷀듃由?湲곕컲 諛몃윴?깃낵 紐⑤뵫 ?앺깭怨?**
|
||||
媛쒕컻?щ뒗 ?⑥닚??而ㅻ??덊떚 ?щ줎???꾨땶 **?붾젅硫뷀듃由?Telemetry)** ?쒖뒪?쒖쓣 ?듯빐 ?섏쭛??媛앷????곗씠???좏깮瑜? ?밸쪧, ???곗뒪 鍮꾩쑉 ??瑜?遺꾩꽍?섏뿬 ?좊떅???ъ씤??鍮꾩슜, 臾댁옣 ?ㅽ럺, ?щ떒 ??媛?⑹꽦 ?깆쓣 ?뺣??섍쾶 議곗젙?⑸땲??[17-19]. ?먰븳, 媛쒕갑?곸씤 NDF ?곗씠??援ъ“ ?뺣텇??而ㅻ??덊떚??'War-Yes', 'Warno-Armory', 'WARPLAN'怨?媛숈? ?뚯떛 諛?由ы뵆?덉씠 遺꾩꽍 ?꾧뎄瑜?吏곸젒 媛쒕컻?섏??쇰ʼn, ?대? ?듯빐 UI??蹂댁씠吏 ?딅뒗 ?④꺼吏??곗씠???? ????뱀닔, 諛쒖궗 媛꾧꺽 濡쒖쭅)瑜?諛쒓뎬?섍퀬 ?듦퀎???꾩닠???섎┰?섍퀬 ?덉뒿?덈떎 [20-23].
|
||||
媛쒕컻?щ뒗 ?⑥닚??而ㅻ??덊떚 ?щ줎???꾨땶 **?붾젅硫뷀듃由?Telemetry)** ?쒖뒪?쒖쓣 ?듯빐 ?섏쭛??媛앷????곗씠???좏깮瑜? ?밸쪧, ???곗뒪 鍮꾩쑉 ??瑜?遺꾩꽍?섏뿬 ?좊떅???ъ씤??鍮꾩슜, 臾댁옣 ?ㅽ럺, ?щ떒 ??媛?⑹꽦 ?깆쓣 ?뺣??섍쾶 議곗젙?⑸땲??[17-19]. ?먰븳, 媛쒕갑?곸씤 NDF ?곗씠??援ъ“ ?뺣텇??而ㅻ??덊떚??'[[War-Yes]]', '[[Warno-Armory]]', '[[WARPLAN]]'怨?媛숈? ?뚯떛 諛?由ы뵆?덉씠 遺꾩꽍 ?꾧뎄瑜?吏곸젒 媛쒕컻?섏??쇰ʼn, ?대? ?듯빐 UI??蹂댁씠吏 ?딅뒗 ?④꺼吏??곗씠???? ????뱀닔, 諛쒖궗 媛꾧꺽 濡쒖쭅)瑜?諛쒓뎬?섍퀬 ?듦퀎???꾩닠???섎┰?섍퀬 ?덉뒿?덈떎 [20-23].
|
||||
|
||||
## ?뵕 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[Iriszoom Engine]], [[Telemetry]], [[?쒖븬 諛??묒쭛???쒖뒪??], [[?κ컩 愿???뚭퀬由ъ쬁 (Armor Penetration Algorithm)]]
|
||||
|
||||
@@ -4,14 +4,14 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# WME (Warno Mod Editor)
|
||||
# WME ([[WARNO]] Mod Editor)
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌[[ brief]] Summary
|
||||
WME(Warno Mod Editor)는 WARNO의 모드 제작을 위해 개발된 커뮤니티 기반의 편집 도구이다 [1, 2]. 기본 Windows 텍스트 편집기를 사용하는 것보다 모딩 작업을 더 편리하게 만들 목적으로 만들어졌다 [1]. NDF 파일의 시각적 편집 기능과 모드 제작에 필수적인 고유 식별자인 GUID 생성기를 통합하여 접근성 높은 모드 제작 환경을 지원한다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **통합 모딩 환경 제공:** WARNO의 모딩은 기본적으로 Sublime Text나 NotePad++ 같은 텍스트 편집기 프로그램과 별도의 GUID 생성기를 각각 사용해야 하는 번거로움이 있다 [1, 3]. WME는 이러한 필수 편집 도구들을 하나로 통합하여 모더(Modder)들에게 보다 편리한 작업 환경을 제공한다 [1].
|
||||
* **NDF 파일의 시각적 편집:** WARNO의 모든 논리적 설계와 데이터는 Eugen Systems의 독자적인 스크립트 언어인 NDF 파일에 저장된다 [4]. WME는 이러한 NDF 파일들을 시각적으로 편집할 수 있는 기능을 지원하여, 유저 커뮤니티가 게임의 데이터 기반 설계 아키텍처에 쉽게 접근하고 관련 데이터를 조작할 수 있도록 돕는다 [2].
|
||||
* **NDF 파일의 시각적 편집:** WARNO의 모든 논리적 설계와 데이터는 Eugen[[ system]]s의 독자적인 스크립트 언어인 NDF 파일에 저장된다 [4]. WME는 이러한 NDF 파일들을 시각적으로 편집할 수 있는 기능을 지원하여, 유저 커뮤니티가 게임의 데이터 기반 설계 아키텍처에 쉽게 접근하고 관련 데이터를 조작할 수 있도록 돕는다 [2].
|
||||
* **GUID 생성기 내장:** 모드 제작 시 각 요소는 반드시 무작위로 부여된 고유 식별자인 GUID를 가져야 한다 [1, 3]. WME는 이 GUID 생성기를 시스템 내에 내장하고 있어, 사용자가 외부 사이트를 오갈 필요 없이 도구 내에서 고유 ID를 생성하고 데이터베이스를 손쉽게 편집할 수 있도록 지원한다 [1-3].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# War-Yes / Warno-Armory (커뮤니티 데이터 분석 도구)
|
||||
# [[War-Yes]] / [[Warno-Armory]] (커뮤니티 데이터 분석 도구)
|
||||
|
||||
## 📌 Brief Summary
|
||||
War-Yes와 Warno-Armory는 WARNO 유저 커뮤니티가 게임 내부의 데이터를 기반으로 직접 개발한 데이터 파싱 및 유닛 비교 도구 웹사이트이다 [1-3]. 이 도구들은 게임 엔진의 내부 파일(NDF)을 직접 읽어들이거나 텍스트 파서를 활용하여 인게임 UI에서는 확인할 수 없는 숨겨진 수치(Hidden stats)를 추출해 제공한다 [3-6]. 플레이어들은 이를 통해 유닛의 상세 제원을 검색, 분류, 비교할 수 있으며 데이터에 기반한 정교한 덱 빌딩과 전술을 수립할 수 있다 [1, 3].
|
||||
## 📌[[ brief]] Summary
|
||||
War-Yes와 [[WARNO]]-Armory는 WARNO 유저 커뮤니티가 게임 내부의 데이터를 기반으로 직접 개발한 데이터 파싱 및 유닛 비교 도구 웹사이트이다 [1-3]. 이 도구들은 게임 엔진의 내부 파일(NDF)을 직접 읽어들이거나 텍스트 파서를 활용하여 인게임 UI에서는 확인할 수 없는 숨겨진 수치(Hidden stats)를 추출해 제공한다 [3-6]. 플레이어들은 이를 통해 유닛의 상세 제원을 검색, 분류, 비교할 수 있으며 데이터에 기반한 정교한 덱 빌딩과 전술을 수립할 수 있다 [1, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **데이터 파싱 및 추출 방식:**
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# War-Yes 및 Warno-Armory 도구
|
||||
# [[War-Yes]] 및 [[Warno-Armory]] 도구
|
||||
|
||||
## 📌 Brief Summary
|
||||
War-Yes와 Warno-Armory는 Eugen Systems의 전술 시뮬레이션 게임 WARNO의 데이터를 분석하고 비교하기 위해 커뮤니티 유저들이 개발한 데이터 파싱 및 유닛 비교 웹사이트 도구입니다 [1-4]. 이 도구들은 게임 내 사용자 인터페이스(UI)에서는 확인할 수 없는 숨겨진 스탯(Hidden Stats)과 엔진 내부의 수치를 추출하여 플레이어에게 제공합니다 [1, 2, 4, 5]. 이를 통해 플레이어들은 게임의 물리적 메커니즘을 깊이 있게 이해하고, 데이터에 기반한 정교한 덱 빌딩과 전술을 수립할 수 있습니다 [4].
|
||||
## 📌[[ brief]] Summary
|
||||
War-Yes와 [[WARNO]]-Armory는 Eugen[[ system]]s의 전술 시뮬레이션 게임 WARNO의 데이터를 분석하고 비교하기 위해 커뮤니티 유저들이 개발한 데이터 파싱 및 유닛 비교 웹사이트 도구입니다 [1-4]. 이 도구들은 게임 내 사용자 인터페이스(UI)에서는 확인할 수 없는 숨겨진 스탯(Hidden Stats)과 엔진 내부의 수치를 추출하여 플레이어에게 제공합니다 [1, 2, 4, 5]. 이를 통해 플레이어들은 게임의 물리적 메커니즘을 깊이 있게 이해하고, 데이터에 기반한 정교한 덱 빌딩과 전술을 수립할 수 있습니다 [4].
|
||||
|
||||
## 📖 Core Content
|
||||
- **데이터 파싱 및 숨겨진 수치 발굴:** 이 도구들은 WARNO의 실제 게임 파일(NDF 파일 등)을 직접 읽어오거나 AI 텍스트 파서를 활용해 데이터를 추출하는 방식으로 구축되었습니다 [4-7]. 이를 통해 인게임 무기고(Armory)나 유닛 카드에는 표시되지 않는 엔진 내부 수치, 예를 들어 '연사 준비 시간(TempsEntreDeuxTirs)'과 같은 숨겨진 데이터를 유저들이 확인할 수 있도록 공유합니다 [4, 8].
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# Wargame 시리즈
|
||||
|
||||
## 📌 Brief Summary
|
||||
'Wargame 시리즈'(*European Escalation*, *AirLand Battle*, *Red Dragon* 등)는 Eugen Systems가 개발한 냉전 및 현대전 배경의 실시간 전술(RTS) 비디오 게임 프랜차이즈입니다 [1, 2]. 이 시리즈는 *WARNO*의 정신적 전작으로서, WARNO는 Wargame의 전술적 전투 메커니즘을 기반으로 삼으면서도 이를 더욱 고도화된 데이터 기반의 사단 시스템과 통합하여 설계되었습니다 [1, 3-5].
|
||||
## 📌[[ brief]] Summary
|
||||
'Wargame 시리즈'(*European Escalation*, *AirLand Battle*, *Red Dragon* 등)는 Eugen[[ system]]s가 개발한 냉전 및 현대전 배경의 실시간 전술(RTS) 비디오 게임 프랜차이즈입니다 [1, 2]. 이 시리즈는 *[[WARNO]]*의 정신적 전작으로서, WARNO는 Wargame의 전술적 전투 메커니즘을 기반으로 삼으면서도 이를 더욱 고도화된 데이터 기반의 사단 시스템과 통합하여 설계되었습니다 [1, 3-5].
|
||||
|
||||
## 📖 Core Content
|
||||
* **WARNO 시스템 설계의 기반:** WARNO는 Wargame 시리즈와 Steel Division 2의 성공적인 요소들을 계승하여 만들어진 게임입니다 [5, 6]. WARNO의 전술적 전투와 부대 커스터마이징 시스템은 Wargame 시리즈에서 얻은 교훈의 집약체이며, Wargame의 핵심 게임플레이 메커니즘에 Steel Division의 사단(Division) 단위 DNA를 결합하여 설계되었습니다 [3, 7]. 또한, WARNO의 'Army General' 턴제 전략 캠페인은 *Wargame: AirLand Battle*과 *Wargame: Red Dragon*의 다이내믹 캠페인 구조를 발전시킨 형태입니다 [8].
|
||||
|
||||
@@ -4,27 +4,27 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# Warno 데이터 기반 설계
|
||||
# [[WARNO]] 데이터 기반 설계
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌[[ brief]] Summary
|
||||
WARNO는 단순한 실시간 전술 게임을 넘어 냉전 시대의 군사 교리와 장비 제원을 고도의 데이터 아키텍처로 치환한 가상 전장 시뮬레이션입니다 [1]. 시각적 요소부터 물리적 충돌, 심리적 제압 시스템에 이르는 모든 게임 내 요소는 NDF(Neutral Data Format)라는 독자적인 스크립트 언어와 정교한 수학적 모델링을 통해 상호 연결된 데이터 구조 내에서 작동합니다 [1, 2]. 개발사는 텔레메트리(Telemetry)를 활용하여 객관적인 데이터 기반 밸런싱을 수행하며, 유저 커뮤니티에도 이 데이터 설계를 개방하여 확장 가능한 전술 시뮬레이션 프레임워크를 구축하고 있습니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **Iriszoom 엔진과 시각 데이터 연동:** 물리 기반 렌더링(PBR)을 전면 도입하여 유닛과 지형의 재질별 식별성을 강화했습니다 [5, 6]. 단순한 폭발 이펙트가 아닌 탄약고 유폭 시 포탑 사출, 헬기 로터 블레이드 비산 등 동적 파괴 시스템이 유닛의 상태 데이터와 물리적으로 동기화되어 작동합니다 [5, 6].
|
||||
|
||||
* **NDF (Neutral Data Format) 아키텍처:** WARNO의 논리적 설계는 NDF 파일 내에 텍스트 기반 객체 지향 구조로 모듈화되어 있습니다 [2]. `UniteDescriptor.ndf`, `WeaponDescriptor.ndf`, `Ammunition.ndf` 등을 통해 게임 코드의 직접적인 수정 없이 유닛의 스펙, 관통력, 명중률, 사거리 데이터를 미세 조정할 수 있어 밸런싱과 모딩에 유연성을 제공합니다 [2, 7].
|
||||
* **[[NDF (Neutral Data Format)]] 아키텍처:** WARNO의 논리적 설계는 NDF 파일 내에 텍스트 기반 객체 지향 구조로 모듈화되어 있습니다 [2]. `UniteDescriptor.ndf`, `WeaponDescriptor.ndf`, `Ammunition.ndf` 등을 통해 게임 코드의 직접적인 수정 없이 유닛의 스펙, 관통력, 명중률, 사거리 데이터를 미세 조정할 수 있어 밸런싱과 모딩에 유연성을 제공합니다 [2, 7].
|
||||
|
||||
* **전투 역학의 수학적 정밀도:** 명중률은 고정된 확률이 아니라 거리가 좁혀질수록 특정 구간에서 기하급수적으로 상승하는 비선형적 거리 비례 데이터 곡선을 따르며, 이동 중 사격 시에는 스테빌라이저 유무에 따라 패널티 데이터가 감쇄됩니다 [8, 9]. 항공기에 대한 대공 미사일 명중률은 타겟의 ECM 데이터를 승수적으로 반영하여 산출($P_{final} = BaseAccuracy \times (1 - ECM)$)됩니다 [10, 11].
|
||||
|
||||
* **장갑 관통 데이터 추상화:** 실제 RHA 수치를 게임에 맞게 스케일링 한 '장갑 점수(Armor Value)'를 사용하며, 철갑탄(AP) 등 운동에너지(KE) 탄자는 거리에 비례하여 관통력이 감소하는 데이터 곡선을 가지는 반면, 대전차 고폭탄(HEAT) 및 대전차 미사일(ATGM)은 성형작약 원리를 반영해 사거리에 상관없이 일정한 관통력을 유지합니다 [12-14]. 관통 후 피해량은 장갑과 관통력의 차이에 기반하여 `(AP Value - Armor) / 2 + 1`과 같은 수학적 로직으로 계산됩니다 [15].
|
||||
|
||||
* **심리적 제압(Suppression)과 시야(Optics) 시스템:** 모든 유닛은 500점의 기본 제압 데이터를 보유하며, 피격이나 주변 폭발 시 수치가 누적되어 명중률, 재장전 속도, 기동성 수치의 하락을 유발합니다 [16]. 정찰 시스템은 관측 유닛의 광학(Optics) 수치와 대상 유닛의 은신(Stealth) 수치 간의 거리 판정을 기반으로 하며, 무기 발사 시 적용되는 소음(Noise) 데이터가 은신 수치를 일시적으로 삭감시켜 노출 위험도를 높입니다 [17, 18].
|
||||
* **심리적 제압(Suppression)과 시야(Optics) 시스템:** 모든 유닛은 500점의 기본 제압 데이터를 보유하며, 피격이나 주변 폭발 시 수치가 누적되어 명중률, 재장전 속도, 기동성 수치의 하락을 유발합니다 [16]. 정찰 시스템은 관측 유닛의 광학(Optics) 수치와 대상 유닛의 은신(Stealth) 수치 간의 거리 판정을 기반으로 하며, 무기 발사 시 적용되는 소음([[Noise]]) 데이터가 은신 수치를 일시적으로 삭감시켜 노출 위험도를 높입니다 [17, 18].
|
||||
|
||||
* **사단 중심의 전략 제약과 텔레메트리 밸런싱:** 사단(Division) 편제표에 따라 유닛의 가용성(Availability) 및 슬롯 포인트 데이터를 달리 설정하여 플레이어가 전술적 장단점을 강제받도록 유도합니다 [19]. 개발사는 방대한 실시간 텔레메트리 데이터를 분석해 픽률과 교전 효율(승률, 생존 시간)을 토대로 유닛의 포인트, 무장 스펙, 특성 데이터를 객관적으로 튜닝하는 밸런싱 작업을 거칩니다 [3, 20].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[Iriszoom 엔진]], [[텔레메트리 (Telemetry) 밸런싱]], [[Combined Arms (제병협동) 전술]]
|
||||
- **Projects/Contexts:** [[Eugen Systems의 냉전기 가상 시나리오 및 모딩 생태계 구축]]
|
||||
- **Projects/Contexts:** [[Eugen[[ system]]s의 냉전기 가상 시나리오 및 모딩 생태계 구축]]
|
||||
- **Contradictions/Notes:** WARNO의 장갑 데이터는 게임 성능 최적화와 복잡한 입사각 계산의 단순화를 위해, 경사 장갑 등에 의한 방호 효과를 추상화하여 장갑 수치 데이터 자체에 반영함으로써 실제 물리적 두께보다 높게 설정된 경우가 존재합니다 [13].
|
||||
|
||||
---
|
||||
|
||||
@@ -4,16 +4,16 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# Warno-Armory
|
||||
# [[WARNO]]-Armory
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌[[ brief]] Summary
|
||||
Warno-Armory는 WARNO의 게임 내부 파일(NDF 파일)을 자동으로 파싱하여 데이터를 읽고, 이를 플레이어에게 편리한 형식으로 보여주는 커뮤니티 기반의 데이터 파싱 도구 웹사이트이다 [1, 2]. 이 사이트는 게임 내 UI에서는 확인할 수 없는 무기 체계의 상세 로직과 숨겨진 스탯을 전수 조사하여 제공한다 [3-5]. 플레이어들은 이 도구를 통해 게임 메커니즘을 더욱 깊이 있게 이해하고, 데이터에 기반한 정교한 덱 빌딩과 전술을 수립할 수 있다 [2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **데이터 파싱 및 숨겨진 스탯 제공:** Warno-Armory는 게임의 내부 파일을 직접 읽어들여 구축된 온라인 무기고(Armory)로, 거의 모든 스탯에 대한 유닛 카테고리별 순위와 숨겨진 유닛 스탯을 제공한다 [1, 4]. 대표적으로 인게임 유닛 카드에는 표시되지 않는 무기별 '다음 공격 준비 시간(TempsEntreDeuxTirs)'과 같은 숨겨진 기술적 속성들을 이 웹사이트에서 쉽게 조회할 수 있다 [3].
|
||||
* **상세 로직 분석 및 피해량 계산:** 이 웹사이트는 WARNO 무기 체계의 상세 로직을 분석하는 데 사용된다 [5]. 플레이어는 Warno-Armory의 '장갑 분석(Armor analytics)' 탭을 통해 거리에 따른 실제 피해량(Real damage)을 편리하게 계산하고 예측하여 복잡한 전투 역학을 이해할 수 있다 [6].
|
||||
* **데이터 기반 설계와의 연관성:** WARNO는 NDF 시스템을 통한 데이터 기반 설계(Data-Driven Design)를 핵심으로 삼고 있는데, Reaktor4가 제작한 Warno-Armory는 이러한 엔진 내부에 숨겨진 수치들을 발굴하고 커뮤니티에 공유하는 중추적인 역할을 수행했다 [2, 7]. 이는 유저들이 게임의 수학적, 물리적 메커니즘을 데이터 단위에서 분석하고 전술에 직접 적용할 수 있도록 한 '데이터 민주화'의 대표적인 사례이다 [2].
|
||||
* **현재 상태:** Warno-Armory는 훌륭한 데이터 분석 사이트로 활약했으나, 이후 사이트 접속이 불가능해지면서 유사한 데이터 파싱 기능을 제공하는 커뮤니티 도구인 War-Yes(war-yes.com)가 그 역할을 대체하게 되었다 [8].
|
||||
* **현재 상태:** Warno-Armory는 훌륭한 데이터 분석 사이트로 활약했으나, 이후 사이트 접속이 불가능해지면서 유사한 데이터 파싱 기능을 제공하는 커뮤니티 도구인 [[War-Yes]](war-yes.com)가 그 역할을 대체하게 되었다 [8].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[War-Yes]], [[데이터 파싱 (Data Parsing)]], [[데이터 기반 설계 (Data-Driven Design)]]
|
||||
|
||||
@@ -6,13 +6,13 @@ converted_at: 2026-04-28
|
||||
|
||||
# 가용성 (Availability)
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 '가용성(Availability)'은 플레이어가 전투단(Battlegroup) 덱에서 증원군으로 전장에 호출할 수 있는 특정 유닛의 최대 개수를 의미하는 핵심 데이터입니다 [1]. 이 수치는 사단 중심의 덱 빌딩 시스템 내에서 개별 유닛의 전략적 가치를 결정짓고 게임의 전반적인 밸런스를 통제하는 역할을 수행합니다 [2, 3]. 고성능 유닛은 가용성이 극히 제한되는 반면, 구식 장비나 예비군은 높은 가용성을 지니게 되어 플레이어에게 품질과 물량 사이의 전술적 선택을 강제하는 데이터적 압박으로 작용합니다 [3, 4].
|
||||
## 📌[[ brief]] Summary
|
||||
[[WARNO]]의 '가용성(Availability)'은 플레이어가 전투단(Battlegroup) 덱에서 증원군으로 전장에 호출할 수 있는 특정 유닛의 최대 개수를 의미하는 핵심 데이터입니다 [1]. 이 수치는 사단 중심의 덱 빌딩 시스템 내에서 개별 유닛의 전략적 가치를 결정짓고 게임의 전반적인 밸런스를 통제하는 역할을 수행합니다 [2, 3]. 고성능 유닛은 가용성이 극히 제한되는 반면, 구식 장비나 예비군은 높은 가용성을 지니게 되어 플레이어에게 품질과 물량 사이의 전술적 선택을 강제하는 데이터적 압박으로 작용합니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **데이터를 통한 전술적 역할 강제:** 사단 시스템 하에서 개별 유닛은 '가용성' 데이터를 통해 그 가치와 역할이 규정됩니다 [3]. 초중전차와 같은 고성능 유닛은 카드당 제공되는 유닛 수가 1~2대 수준으로 극히 제한되어 있으며, 이는 플레이어가 해당 유닛의 손실을 무조건 최소화해야 한다는 데이터 기반의 압박으로 작용합니다 [3, 4]. 반면 예비군 부대나 구식 장비는 매우 높은 가용성 데이터를 할당받아, 물량을 앞세운 소모전이나 전선 유지용 소모품으로 활용되도록 시스템적으로 유도됩니다 [4].
|
||||
* **숙련도(Veterancy)와 가용성의 반비례 관계:** 유닛을 배치할 때 높은 숙련도(예: Veteran, Elite)를 선택할수록 전장에 투입할 수 있는 최대 유닛 수(가용성)는 감소합니다 [5]. 플레이어는 소수의 고도로 훈련된 병력을 사용할 것인지, 아니면 숙련도가 낮더라도 다수의 병력을 운용할 것인지(Quantity vs Quality)를 가용성 데이터를 기반으로 결정해야 합니다 [5, 6].
|
||||
* **NDF (Neutral Data Format) 아키텍처 구현:** 가용성 규칙은 Eugen Systems의 독자적인 스크립트 파일인 NDF 시스템 내에 엄격히 정의되어 있습니다 [7, 8]. `Divisions.ndf` 파일은 사단 덱 내의 유닛 카드 목록과 가용성을 나열하며, `DivisionRules.ndf` 파일은 개별 유닛의 기본 제공 수치(`NumberOfUnitInPack`)와 숙련도 레벨에 따른 가용성 승수(`NumberOfUnitInPackXPMultiplier`) 데이터를 직접 제어하여 밸런스를 수학적으로 구조화합니다 [9, 10].
|
||||
* **[[NDF (Neutral Data Format)]] 아키텍처 구현:** 가용성 규칙은 Eugen[[ system]]s의 독자적인 스크립트 파일인 NDF 시스템 내에 엄격히 정의되어 있습니다 [7, 8]. `Divisions.ndf` 파일은 사단 덱 내의 유닛 카드 목록과 가용성을 나열하며, `DivisionRules.ndf` 파일은 개별 유닛의 기본 제공 수치(`NumberOfUnitInPack`)와 숙련도 레벨에 따른 가용성 승수(`NumberOfUnitInPackXPMultiplier`) 데이터를 직접 제어하여 밸런스를 수학적으로 구조화합니다 [9, 10].
|
||||
* **모딩(Modding)을 통한 시스템 조정:** 데이터 파일이 개방된 구조 덕분에, 모더들은 가용성 관련 변수를 수정하여 게임의 밸런스를 독자적으로 재설계할 수 있습니다 [7, 11]. 예를 들어, 현실주의 전술을 추구하는 'RebsFRAGO' 모드에서는 숙련도가 오를 때마다 가용성이 25%씩만 감소하도록 관련 데이터를 수정하여, 고숙련 베테랑 유닛의 실질적인 전장 활용도를 높였습니다 [12].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
@@ -6,12 +6,12 @@ converted_at: 2026-04-28
|
||||
|
||||
# 가위바위보 상성 (Rock-paper-scissors principle)
|
||||
|
||||
## 📌 Brief Summary
|
||||
가위바위보 상성(Rock-paper-scissors principle)은 WARNO의 전투 및 밸런싱을 구성하는 핵심 전술적 원리로, 서로 다른 유닛들이 물고 물리는 절대적인 상성 관계를 갖는 것을 의미합니다. 예를 들어 대전차 특화 헬리콥터는 전차에 강하고, 대공포는 헬리콥터에 강하며, 전차는 대공포에 강한 식의 순환 구조를 가집니다. 플레이어는 이 원리를 바탕으로 적의 유닛을 파괴하는 데 특화된 카운터 유닛을 적절히 배치하고 제병협동 전술을 구사해야 합니다.
|
||||
## 📌[[ brief]] Summary
|
||||
가위바위보 상성(Rock-paper-scissors principle)은 [[WARNO]]의 전투 및 밸런싱을 구성하는 핵심 전술적 원리로, 서로 다른 유닛들이 물고 물리는 절대적인 상성 관계를 갖는 것을 의미합니다. 예를 들어 대전차 특화 헬리콥터는 전차에 강하고, 대공포는 헬리콥터에 강하며, 전차는 대공포에 강한 식의 순환 구조를 가집니다. 플레이어는 이 원리를 바탕으로 적의 유닛을 파괴하는 데 특화된 카운터 유닛을 적절히 배치하고 제병협동 전술을 구사해야 합니다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **기본 상성 구조:** WARNO의 게임 메커니즘이 처음에는 매우 복잡해 보일 수 있지만, 근본적인 전투 원리는 가위바위보 상성과 동일합니다[1]. 전차가 아무리 강력하더라도 전차 사냥에 특화된 공격 헬리콥터에게 위에서 공격을 받으면 일방적으로 패배하게 됩니다[1]. 반대로, 공격 헬리콥터는 대공 전투에 특화된 대공포(AA guns)의 공격을 받으면 일방적으로 격추당하며, 대공포는 다시 전차의 공격에 일방적으로 무너지는 구조를 갖습니다[1].
|
||||
* **카운터 유닛 대응 및 제병협동:** 가위바위보 원리에 따라 WARNO 전투의 기본은 적 유닛을 파괴하는 데 특화된 '카운터 유닛'으로 맞대응하는 것입니다[2]. 이러한 깊이 있는 전술적 가위바위보 상호작용(rock-paper-scissors interplay)은 보병, 기갑, 포병, 대공, 정찰 병과가 조화롭게 작동해야 승리할 수 있는 제병협동(combined-arms) 메커니즘과 긴밀하게 결합되어 있습니다[3, 4].
|
||||
* **카운터 유닛 대응 및 제병협동:** 가위바위보 원리에 따라 WARNO 전투의 기본은 적 유닛을 파괴하는 데 특화된 '카운터 유닛'으로 맞대응하는 것입니다[2]. 이러한 깊이 있는 전술적 가위바위보 상호작용(rock-paper-scissors interplay)은 보병, 기갑, 포병, 대공, 정찰 병과가 조화롭게 작동해야 승리할 수 있는 제병협동([[Combined-Arms]]) 메커니즘과 긴밀하게 결합되어 있습니다[3, 4].
|
||||
* **국가 및 사단별 RPS 유연성 차이:** 덱 구축(Deck building) 측면에서 볼 때, 진영이나 사단에 따라 가위바위보(RPS) 대응 능력이 다릅니다[5]. 예를 들어, 미국(US)이나 소련(SOV)과 같은 국가 단위의 덱 구성이 가능하다면, 사용 가능한 유닛의 풀이 가장 넓기 때문에 상황에 대처할 수 있는 유연성과 가위바위보(RPS) 옵션을 가장 많이 확보할 수 있게 되어 S/S+ 티어의 강력함을 갖게 됩니다[5].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
@@ -4,16 +4,16 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 모딩 커뮤니티 도구 (War-Yes, Warno-Armory)
|
||||
# 모딩 커뮤니티 도구 ([[War-Yes]], [[Warno-Armory]])
|
||||
|
||||
## 📌 Brief Summary
|
||||
War-Yes와 Warno-Armory는 WARNO 유저 커뮤니티가 자체적으로 개발한 웹 기반의 데이터 파싱 및 유닛 비교 도구입니다 [1, 2]. 이 도구들은 게임 내 UI에서는 직접 확인할 수 없는 엔진 내부의 숨겨진 수치와 메커니즘을 추출하여 시각화합니다 [2, 3]. 이를 통해 플레이어들은 게임의 복잡한 데이터 기반 설계를 깊이 이해하고, 보다 정교한 덱 빌딩과 전술을 수립할 수 있습니다 [2].
|
||||
## 📌[[ brief]] Summary
|
||||
War-Yes와 [[WARNO]]-Armory는 WARNO 유저 커뮤니티가 자체적으로 개발한 웹 기반의 데이터 파싱 및 유닛 비교 도구입니다 [1, 2]. 이 도구들은 게임 내 UI에서는 직접 확인할 수 없는 엔진 내부의 숨겨진 수치와 메커니즘을 추출하여 시각화합니다 [2, 3]. 이를 통해 플레이어들은 게임의 복잡한 데이터 기반 설계를 깊이 이해하고, 보다 정교한 덱 빌딩과 전술을 수립할 수 있습니다 [2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **데이터 파싱을 통한 숨겨진 통계 추출:** WARNO의 커뮤니티 도구들은 게임 엔진 내부에 숨겨진 수치들을 발굴하여 공유하는 역할을 수행합니다 [2]. 예를 들어, 인게임 유닛 카드에는 표시되지 않는 무기의 '연사 준비 시간(TempsEntreDeuxTirs)'이나 자동 타겟팅과 관련된 '위험도(dangerousness)' 같은 숨겨진 내부 데이터를 이 도구들을 통해 정확하게 확인할 수 있습니다 [2, 4, 5].
|
||||
* **Warno-Armory의 역할 및 특징:** 실제 WARNO의 내부 파일(NDF)을 직접 읽어들여 구축된 온라인 무기고(Armory)입니다 [6]. 무기 체계의 상세 로직과 전수 조사 데이터를 제공하며, 플레이어들이 게임 내부 파일에 담긴 방대한 데이터를 이해하기 쉬운 형태로 열람할 수 있도록 돕습니다 [3, 7].
|
||||
* **War-Yes의 역할 및 특징:** 유닛 간의 상대적 성능을 정밀하게 비교할 수 있도록 검색, 정렬, 필터링 기능과 유닛 비교 차트를 제공합니다 [1, 7]. 초기 구축 당시에는 AI 텍스트 파서를 활용해 유닛 카드의 데이터를 추출하는 방식으로 개발되었으며 [8], 숨겨진 명중률 곡선 등을 시각화하여 제공합니다 [7].
|
||||
* **전술적 이해 및 생태계 확장:** 이러한 도구들은 플레이어가 전자전(ECM) 계산식이나 체력 피해 변환 표와 같은 복잡한 수치적 기반을 이해하도록 지원합니다 [9, 10]. 또한, 리플레이 분석기인 WARPLAN이나 시각적 모드 제작을 돕는 WME(Warno Mod Editor)와 함께 작용하여, WARNO의 '데이터 기반 설계'가 제작사만의 전유물이 아닌 유저와 함께 호흡하며 진화하는 개방형 생태계로 발전하는 데 기여하고 있습니다 [7].
|
||||
* **전술적 이해 및 생태계 확장:** 이러한 도구들은 플레이어가 전자전(ECM) 계산식이나 체력 피해 변환 표와 같은 복잡한 수치적 기반을 이해하도록 지원합니다 [9, 10]. 또한, 리플레이 분석기인 [[WARPLAN]]이나 시각적 모드 제작을 돕는 WME(Warno Mod Editor)와 함께 작용하여, WARNO의 '데이터 기반 설계'가 제작사만의 전유물이 아닌 유저와 함께 호흡하며 진화하는 개방형 생태계로 발전하는 데 기여하고 있습니다 [7].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)]], [[숨겨진 통계 (Hidden Stats)]]
|
||||
|
||||
@@ -4,10 +4,10 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 사단 시스템 (Division System)
|
||||
# 사단 시스템 (Division[[ system]])
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 사단 시스템은 플레이어가 50점의 활성화 포인트(Activation Points)를 사용하여 역사적 군 편제에 기반한 덱을 구성하도록 하는 핵심 게임 메커니즘이다 [1, 2]. 이는 모든 병과에서 완벽한 유닛으로만 구성된 '무적의 군대'를 만드는 것을 방지하고, 각 사단마다 뚜렷한 강점과 약점을 데이터적으로 강제하여 전술적 다양성과 기회비용을 창출한다 [2-4]. 궁극적으로 플레이어에게 단순한 유닛 조합을 넘어, 실제 지휘관과 같은 한정된 자원 내에서의 전략적 제약을 경험하게 하는 시스템이다 [3, 5].
|
||||
## 📌[[ brief]] Summary
|
||||
[[WARNO]]의 사단 시스템은 플레이어가 50점의 활성화 포인트(Activation Points)를 사용하여 역사적 군 편제에 기반한 덱을 구성하도록 하는 핵심 게임 메커니즘이다 [1, 2]. 이는 모든 병과에서 완벽한 유닛으로만 구성된 '무적의 군대'를 만드는 것을 방지하고, 각 사단마다 뚜렷한 강점과 약점을 데이터적으로 강제하여 전술적 다양성과 기회비용을 창출한다 [2-4]. 궁극적으로 플레이어에게 단순한 유닛 조합을 넘어, 실제 지휘관과 같은 한정된 자원 내에서의 전략적 제약을 경험하게 하는 시스템이다 [3, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
* **전략적 제약의 데이터화**: 모든 사단은 덱 구성을 위해 50점의 활성화 포인트를 동일하게 부여받지만, 각 병과 슬롯을 개방하는 데 소모되는 포인트 비용은 사단의 특성에 따라 상이하게 설정되어 있다 [1, 2]. 예를 들어, 기갑사단은 전차 슬롯 비용이 저렴해 물량 확보가 쉽지만 보병 슬롯은 비싸고 가용 카드가 적게 데이터화되어 있다 [1, 2].
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# 사단 편제표 (TO&E)
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 사단 편제표(TO&E)는 가상의 1989년 냉전 시나리오를 바탕으로 실제 역사적 군 편제를 게임의 핵심 규칙으로 내재화한 데이터 중심의 덱 빌딩 시스템이다 [1]. 이는 플레이어가 모든 분야에서 완벽한 유닛으로만 구성된 '무적의 군대'를 만드는 것을 방지하고, 각 사단의 고유한 강점과 약점에 따른 데이터적 정체성을 강제한다 [2, 3]. 결과적으로 병력 구성에 기회비용을 발생시키고 전략적 제약을 부여하여 게임의 밸런싱과 전술적 깊이를 창출하는 핵심적인 역할을 수행한다 [1-3].
|
||||
## 📌[[ brief]] Summary
|
||||
[[WARNO]]의 사단 편제표(TO&E)는 가상의 1989년 냉전 시나리오를 바탕으로 실제 역사적 군 편제를 게임의 핵심 규칙으로 내재화한 데이터 중심의 덱 빌딩 시스템이다 [1]. 이는 플레이어가 모든 분야에서 완벽한 유닛으로만 구성된 '무적의 군대'를 만드는 것을 방지하고, 각 사단의 고유한 강점과 약점에 따른 데이터적 정체성을 강제한다 [2, 3]. 결과적으로 병력 구성에 기회비용을 발생시키고 전략적 제약을 부여하여 게임의 밸런싱과 전술적 깊이를 창출하는 핵심적인 역할을 수행한다 [1-3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **데이터 기반의 사단 설계 철학**: 방대한 무기고에서 원하는 유닛을 샌드박스 형태로 자유롭게 조합할 수 있었던 전작(Wargame 시리즈)과 달리, WARNO는 실제 지휘관처럼 **제한된 사단 편제(TO&E) 내에서만 부대를 구성하도록 강제**한다 [4]. 이를 통해 모든 역할을 다 해내는 만능 덱의 출현을 막고, 강력한 전차를 가진 사단은 보병진이나 대공망이 취약하게 만드는 등 뚜렷한 기회비용과 설계적 제약을 부여한다 [2, 5].
|
||||
@@ -16,7 +16,7 @@ WARNO의 사단 편제표(TO&E)는 가상의 1989년 냉전 시나리오를 바
|
||||
* **사단 유형별 전략적 다변화**: 게임 내 사단은 장갑(Armored), 보병(Infantry), 기계화 보병(Mechanized Infantry), 공수(Airborne), 공중강습(Air Assault), 예비군(Reserve) 등 다양한 편제로 세분화된다 [10-15]. 편제 유형에 따라 개활지, 시가지, 숲 등 유리하게 작용하는 지형 조건이 다르며, 경기 초반의 기동성 우위나 후반부의 전차 물량전 등 각기 다른 전술적 강점이 데이터로 뚜렷하게 구분된다 [11, 13].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[덱 빌딩 시스템 (Deck Building System)]], [[NDF (Neutral Data Format)]], [[가용성 (Availability)]]
|
||||
- **Related Topics:** [[덱 빌딩 시스템 (Deck Building[[ system]])]], [[NDF (Neutral Data Format)]], [[가용성 (Availability)]]
|
||||
- **Projects/Contexts:** [[WARNO 데이터 기반 밸런싱]]
|
||||
- **Contradictions/Notes:** 사단 편제표 시스템이 제공하는 '역사적 고증'과 밸런싱에 대해 커뮤니티 내 의견 대립이 존재한다. 일부 플레이어는 실제 사단 편제에 맞지 않는 부대나 무기가 작전상 필요하다는 구실로 임의 배속되는 점이 고증과 몰입을 깬다고 강하게 비판하며 샌드박스 시스템으로의 회귀를 요구한다 [16-19]. 반면, 다른 플레이어들과 개발진은 이러한 제한적 편제 시스템이 획일화된 '메타 덱'을 방지하고 더 나은 게임 밸런스 및 팀 플레이를 유도하는 필수적인 장치라고 주장한다 [9, 20-22].
|
||||
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# 사단(Division) 시스템
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 사단(Division) 시스템은 역사적 군 편제에 기반하여 플레이어의 덱 구성을 제한하고 전략적 정체성을 데이터로 강제하는 핵심 설계입니다 [1]. 이 시스템은 플레이어가 모든 병과에서 완벽한 유닛만 선택하여 '무적의 군대'를 만드는 것을 방지하고, 각 사단에 내재된 고유의 강점과 약점을 수용하도록 유도합니다 [1, 2]. 모든 사단은 덱 구성을 위해 50점의 활성화 포인트(Activation Points)를 공유하지만, 사단별로 슬롯 비용과 유닛 가용성(Availability) 데이터를 차등 적용하여 고도의 전략적 의사결정과 데이터 기반의 밸런싱을 구현합니다 [1, 3, 4].
|
||||
## 📌[[ brief]] Summary
|
||||
[[WARNO]]의 사단(Division) 시스템은 역사적 군 편제에 기반하여 플레이어의 덱 구성을 제한하고 전략적 정체성을 데이터로 강제하는 핵심 설계입니다 [1]. 이 시스템은 플레이어가 모든 병과에서 완벽한 유닛만 선택하여 '무적의 군대'를 만드는 것을 방지하고, 각 사단에 내재된 고유의 강점과 약점을 수용하도록 유도합니다 [1, 2]. 모든 사단은 덱 구성을 위해 50점의 활성화 포인트(Activation Points)를 공유하지만, 사단별로 슬롯 비용과 유닛 가용성(Availability) 데이터를 차등 적용하여 고도의 전략적 의사결정과 데이터 기반의 밸런싱을 구현합니다 [1, 3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **전략적 제약과 밸런싱 디자인 공간**: 사단 시스템은 개별 유닛 단위가 아닌 사단이라는 큰 틀 안에서 밸런스를 조정할 수 있는 디자인 공간(Design space)을 제공합니다 [5]. 이를 통해 매우 강력한 유닛을 약한 사단에 배치하거나, 반대로 약한 유닛을 전반적으로 강력한 사단에서 필수적으로 사용하게끔 강제할 수 있습니다 [5]. 즉, 최고의 보병 탭을 가진 사단은 최고의 전차를 가질 수 없도록 설계되어 있어 플레이어가 특정 무적 메타 덱(Meta deck)에만 의존하는 것을 방지합니다 [2, 6].
|
||||
|
||||
@@ -4,16 +4,16 @@ status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 소음 역학 (Noise Dynamics)
|
||||
# 소음 역학 ([[Noise]] Dynamics)
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 소음 역학(Noise Dynamics)은 유닛이 무기를 발사할 때 발생하는 소음으로 인해 은신(Stealth) 수치가 감소하는 메커니즘입니다 [1]. 각 무기 체계는 고유한 '소음 페널티(noise malus)'와 '최대 소음에 도달하기까지의 사격 횟수'에 대한 데이터를 보유하고 있습니다 [2], [1]. 무기를 발사할 때마다 유효 은신 수치가 단계적으로 삭감되어 적 정찰 유닛의 탐지 거리 내로 강제 노출되는 결과를 낳게 됩니다 [3].
|
||||
## 📌[[ brief]] Summary
|
||||
[[WARNO]]의 소음 역학(Noise Dynamics)은 유닛이 무기를 발사할 때 발생하는 소음으로 인해 은신(Stealth) 수치가 감소하는 메커니즘입니다 [1]. 각 무기 체계는 고유한 '소음 페널티(noise malus)'와 '최대 소음에 도달하기까지의 사격 횟수'에 대한 데이터를 보유하고 있습니다 [2], [1]. 무기를 발사할 때마다 유효 은신 수치가 단계적으로 삭감되어 적 정찰 유닛의 탐지 거리 내로 강제 노출되는 결과를 낳게 됩니다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **은신 수치 감소 로직:** 무기 발사 시 생성되는 소음과 예광탄은 유닛의 유효 은신 수치(Effective Stealth) 상실로 직결됩니다 [1]. 실제 은신 손실량은 무기의 소음 페널티를 최대 소음 도달 사격 횟수로 나누어 계산됩니다 [4]. 일반적으로 대부분의 WARNO 유닛은 사격할 때마다 1단계의 유효 은신 수치를 잃게 되며, 사격 후에도 꽤 오랜 시간 동안 소음 상태(은신 감소 상태)가 유지됩니다 [1], [5].
|
||||
* **무기별 고유 소음 데이터:** 유닛이 장비한 무기에 따라 발생하는 소음 데이터 값은 다르게 설정되어 있습니다 [6]. 예를 들어, TOW-2 대전차 미사일 팀의 소음 페널티는 2이며 최대 소음에 도달할 때까지 2회의 사격을 할 수 있습니다 [1]. 반면 더 큰 소음을 내는 M1A1 전차의 주포는 2.2의 소음 페널티를 가지며, 동일하게 2회 사격 시 최대 소음에 도달합니다 [1].
|
||||
* **거리 판정 및 전술적 영향:** 관측 유닛과 타겟 유닛 간의 탐지 거리를 결정할 때 소음 역학이 개입하게 됩니다 [3]. 예를 들어, 숲에 배치되어 은신 수치가 5인 TOW-2 팀은 초기에는 적 정찰조가 1351m 이내로 접근해야 발견되지만, 한 발을 사격하여 은신 수치가 감소하면 1700m 거리에서도 발각될 수 있습니다 [7].
|
||||
* **전술적 응용:** 이러한 소음 역학 때문에 정찰 유닛은 위치가 발각되는 것을 피하기 위해 '사격 중지(Hold fire)' 또는 '반격(Return fire)' 명령을 내려야 합니다 [8], [9]. 반대로 이 시스템을 역이용하여, 적의 ATGM(대전차 유도 미사일) 팀의 사격을 의도적으로 유도(Baiting)함으로써 적이 소음 페널티를 받아 스스로 위치를 노출하도록 만드는 카운터 전술도 가능합니다 [8], [9].
|
||||
* **전술적 응용:** 이러한 소음 역학 때문에 정찰 유닛은 위치가 발각되는 것을 피하기 위해 '사격 중지(Hold fire)' 또는 '반격(Return fire)' 명령을 내려야 합니다 [8], [9]. 반대로 이 시스템을 역이용하여, 적의 ATGM(대전차 유도 미사일) 팀의 사격을 의도적으로 유도([[Baiting]])함으로써 적이 소음 페널티를 받아 스스로 위치를 노출하도록 만드는 카운터 전술도 가능합니다 [8], [9].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[은신 역학 (Stealth Mechanics)]], [[탐지 및 광학 알고리즘 (Detection and Optics Algorithm)]]
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# 은신과 시야 매커니즘 (Stealth and Optics)
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 은신과 시야 매커니즘은 유닛의 정보 우위를 결정하는 핵심 데이터 기반 시스템이다 [1]. 이 시스템은 관측 유닛의 광학(Optics) 수치와 타겟 유닛의 은신(Stealth) 수치 간의 거리 판정 알고리즘을 통해 적의 탐지 여부를 결정한다 [2]. 플레이어는 가시선(LOS) 도구, 지형이 제공하는 은신 배수, 그리고 무기 발사 시 발생하는 소음(Noise) 데이터를 종합적으로 고려하여 전술을 수립해야 한다 [3], [4], [5].
|
||||
## 📌[[ brief]] Summary
|
||||
[[WARNO]]의 은신과 시야 매커니즘은 유닛의 정보 우위를 결정하는 핵심 데이터 기반 시스템이다 [1]. 이 시스템은 관측 유닛의 광학(Optics) 수치와 타겟 유닛의 은신(Stealth) 수치 간의 거리 판정 알고리즘을 통해 적의 탐지 여부를 결정한다 [2]. 플레이어는 가시선(LOS) 도구, 지형이 제공하는 은신 배수, 그리고 무기 발사 시 발생하는 소음([[Noise]]) 데이터를 종합적으로 고려하여 전술을 수립해야 한다 [3], [4], [5].
|
||||
|
||||
## 📖 Core Content
|
||||
* **은신(Stealth) 및 광학(Optics) 데이터:**
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# 장갑 관통 모델링(Armor Penetration Modeling)
|
||||
|
||||
## 📌 Brief Summary
|
||||
장갑 관통 모델링은 WARNO에서 차량의 방호력과 무기의 관통력을 비교하여 피해를 산출하는 데이터 기반 시뮬레이션 시스템입니다 [1]. 이 모델은 엔진 연산 부하를 줄이기 위해 실제 역사적 RHA(균질압연강권) 수치를 그대로 쓰지 않고 스케일링된 '장갑 점수(Armor Value)'로 추상화하여 사용합니다 [1]. 무기의 관통력과 방어자의 부위별 장갑 수치 차이에 따라 관통 확률 및 데미지가 결정되며, 탄종(KE, HEAT 등)에 따라 사거리 비례 관통력 변화 로직이 다르게 적용됩니다 [1, 2].
|
||||
## 📌[[ brief]] Summary
|
||||
장갑 관통 모델링은 [[WARNO]]에서 차량의 방호력과 무기의 관통력을 비교하여 피해를 산출하는 데이터 기반 시뮬레이션 시스템입니다 [1]. 이 모델은 엔진 연산 부하를 줄이기 위해 실제 역사적 RHA(균질압연강권) 수치를 그대로 쓰지 않고 스케일링된 '장갑 점수(Armor Value)'로 추상화하여 사용합니다 [1]. 무기의 관통력과 방어자의 부위별 장갑 수치 차이에 따라 관통 확률 및 데미지가 결정되며, 탄종(KE, HEAT 등)에 따라 사거리 비례 관통력 변화 로직이 다르게 적용됩니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **장갑 점수와 연산 효율화**
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# 장갑 및 사거리 데이터 (Armor and Range Stats)
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 장갑 및 사거리 데이터는 실제 물리적 제원(RHA 등)을 게임 내 역학에 맞춰 스케일링한 수치 체계이다 [1]. 장갑 시스템은 부위별 방호력 점수와 탄종별 관통력 산식을 기반으로 피해량과 도탄 여부를 엄격하게 결정한다 [2], [3], [4]. 사거리는 단순한 사격 가능 거리를 넘어, 거리 비례 명중률 곡선 및 관통력 증감 시스템과 결합하여 전술적 기동의 핵심 변수로 작용한다 [5], [6], [4].
|
||||
## 📌[[ brief]] Summary
|
||||
[[WARNO]]의 장갑 및 사거리 데이터는 실제 물리적 제원(RHA 등)을 게임 내 역학에 맞춰 스케일링한 수치 체계이다 [1]. 장갑 시스템은 부위별 방호력 점수와 탄종별 관통력 산식을 기반으로 피해량과 도탄 여부를 엄격하게 결정한다 [2], [3], [4]. 사거리는 단순한 사격 가능 거리를 넘어, 거리 비례 명중률 곡선 및 관통력 증감 시스템과 결합하여 전술적 기동의 핵심 변수로 작용한다 [5], [6], [4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **장갑 점수(Armor Value)와 방호 모델링:** 게임은 실제 전차의 RHA(균질압연강판) 수치를 그대로 쓰지 않고, 엔진의 연산 부하를 줄이며 물리적으로 정확한 결과를 내기 위해 스케일링된 '장갑 점수'를 사용한다 [1], [4]. 복잡한 입사각 계산을 단순화하기 위해 경사 장갑에 의한 방호 효과가 장갑 수치 데이터 자체에 사전에 반영되어 있다 [4]. 차량의 장갑은 전면, 측면, 후면, 상면(약함/강함)으로 엄격히 구분되며, 일반적으로 전면 장갑이 가장 두껍게 설정된다 [2], [1].
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# 제병협동 (Combined Arms)
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO에서의 제병협동은 보병, 전차, 대공, 포병, 정찰 등 서로 다른 강점과 약점을 가진 유닛들을 결합하여 상호 지원하는 전술적 진형을 구성하는 핵심 플레이 원리입니다. 각 유닛의 사거리, 장갑, 은신도 등의 데이터 특성을 기반으로 알맞은 위치에 유닛을 배치하여 적의 어떠한 유닛 조합에도 대응할 수 있게 만듭니다. 성공적인 제병협동은 전략적 우위를 제공하며, Army General 캠페인 모드에서는 부대 병종의 조합에 따라 적에게 부정적인 보정치를 부여하는 시스템적 보너스로도 작용합니다.
|
||||
## 📌[[ brief]] Summary
|
||||
[[WARNO]]에서의 제병협동은 보병, 전차, 대공, 포병, 정찰 등 서로 다른 강점과 약점을 가진 유닛들을 결합하여 상호 지원하는 전술적 진형을 구성하는 핵심 플레이 원리입니다. 각 유닛의 사거리, 장갑, 은신도 등의 데이터 특성을 기반으로 알맞은 위치에 유닛을 배치하여 적의 어떠한 유닛 조합에도 대응할 수 있게 만듭니다. 성공적인 제병협동은 전략적 우위를 제공하며, Army General 캠페인 모드에서는 부대 병종의 조합에 따라 적에게 부정적인 보정치를 부여하는 시스템적 보너스로도 작용합니다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **가위바위보 상성 극복과 전술적 유연성 확보**
|
||||
|
||||
@@ -6,11 +6,11 @@ converted_at: 2026-04-28
|
||||
|
||||
# 제병협동 전술 (Combined Arms)
|
||||
|
||||
## 📌 Brief 소스
|
||||
WARNO에서 제병협동 전술(Combined Arms)은 보병, 기갑, 포병, 항공 지원 및 정찰 등 다양한 병과가 조화롭게 협력하여 승리를 쟁취하는 핵심 전술 개념입니다 [1]. 서로 다른 특성과 능력치를 가진 유닛들을 통합하고 상호 지원하도록 배치함으로써 개별 유닛의 약점을 보완하고 적의 어떠한 유닛에도 효과적으로 대응할 수 있습니다 [2, 3]. 이는 단순한 실시간 전술 전투를 넘어 전략 모드인 아미 제너럴(Army General)에서도 시스템적으로 깊게 반영되어, 다양한 병과를 결합하면 적에게 디버프를 주고 아군에게 보너스를 부여하는 등 데이터 기반 설계의 핵심을 이룹니다 [4, 5].
|
||||
## 📌[[ brief]] 소스
|
||||
[[WARNO]]에서 제병협동 전술(Combined Arms)은 보병, 기갑, 포병, 항공 지원 및 정찰 등 다양한 병과가 조화롭게 협력하여 승리를 쟁취하는 핵심 전술 개념입니다 [1]. 서로 다른 특성과 능력치를 가진 유닛들을 통합하고 상호 지원하도록 배치함으로써 개별 유닛의 약점을 보완하고 적의 어떠한 유닛에도 효과적으로 대응할 수 있습니다 [2, 3]. 이는 단순한 실시간 전술 전투를 넘어 전략 모드인 아미 제너럴(Army General)에서도 시스템적으로 깊게 반영되어, 다양한 병과를 결합하면 적에게 디버프를 주고 아군에게 보너스를 부여하는 등 데이터 기반 설계의 핵심을 이룹니다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
- **병과 간 상호 지원과 전술적 배치 (Mutual Support & Positioning)**: 제병협동의 핵심은 개별 유닛의 데이터 특성(사거리, 장갑, 은신 등)을 기반으로 한 상호 지원 진형을 구축하는 것입니다 [6]. 장갑이 얇은 유닛은 중장갑 유닛 뒤에, 사거리가 긴 유닛(ATGM, 공격 헬리콥터 등)은 보병이나 전차 뒤에, 비전투 및 은신 능력(Stealth)이 낮은 유닛은 후방에 배치하여 각 유닛의 특성을 극대화하고 약점을 철저히 보호해야 합니다 [7-9].
|
||||
- **병과 간 상호 지원과 전술적 배치 (Mutual [[Support]] & Positioning)**: 제병협동의 핵심은 개별 유닛의 데이터 특성(사거리, 장갑, 은신 등)을 기반으로 한 상호 지원 진형을 구축하는 것입니다 [6]. 장갑이 얇은 유닛은 중장갑 유닛 뒤에, 사거리가 긴 유닛(ATGM, 공격 헬리콥터 등)은 보병이나 전차 뒤에, 비전투 및 은신 능력(Stealth)이 낮은 유닛은 후방에 배치하여 각 유닛의 특성을 극대화하고 약점을 철저히 보호해야 합니다 [7-9].
|
||||
- **란체스터의 제곱 법칙 (Lanchester's Square Law) 적용**: 게임 내 화력전에서 부대의 전투력은 보유한 유닛 화력 총합의 제곱에 비례하게 설계되어 있습니다 [10]. 서로 다른 병과(예: 전차, ATGM 차량, 보병 등)를 결합하여 십자포화(Crossfire)를 구성하면 단일 유닛으로 전투할 때보다 기하급수적으로 높은 데미지와 제압력(Suppression)을 적에게 입힐 수 있습니다 [11, 12].
|
||||
- **핵심 병과의 융합 (Integration of Key Units)**: 정찰 유닛으로 적을 식별하고, 전차와 보병으로 전선을 형성하며, 대공(AA) 유닛으로 이들을 보호하고, 연막(Smoke)을 효과적으로 사용하여 교전을 통제하는 것이 제병협동의 기본입니다 [13-16]. 일례로 저격수가 보병, 전차, IFV를 동시에 지원하도록 배치하는 것은 시스템상 매우 스마트한 제병협동 플레이로 권장됩니다 [17].
|
||||
- **아미 제너럴(Army General) 시스템과의 연동**: 턴제 전략 캠페인인 아미 제너럴 모드에서도 제병협동의 원칙은 룰로 강제됩니다. 전투에 다양한 유형의 부대를 참여시킬 경우, 적 부대에게 부정적인 수정치(negative modifier)가 적용되며, 아군에게는 추가적인 전투 보너스가 시스템적으로 계산되어 승률에 직접적인 영향을 미칩니다 [4, 5].
|
||||
|
||||
@@ -6,8 +6,8 @@ converted_at: 2026-04-28
|
||||
|
||||
# 탄도학 및 명중률 알고리즘 (Ballistics and Accuracy Algorithms)
|
||||
|
||||
## 📌 Brief Summary
|
||||
WARNO의 탄도학 및 명중률 알고리즘은 거리에 따른 비선형적 명중률 보정, 이동 사격 페널티, 전자전(ECM), 그리고 숙련도를 복합적으로 고려하여 수학적 정밀도를 제공하는 전투 연산 시스템입니다. 무기의 종류와 타겟과의 거리, 유닛의 심리적/물리적 상태에 따라 역동적으로 명중 확률이 계산되어 깊이 있는 데이터 기반 전술 환경을 형성합니다.
|
||||
## 📌[[ brief]] Summary
|
||||
[[WARNO]]의 탄도학 및 명중률 알고리즘은 거리에 따른 비선형적 명중률 보정, 이동 사격 페널티, 전자전(ECM), 그리고 숙련도를 복합적으로 고려하여 수학적 정밀도를 제공하는 전투 연산 시스템입니다. 무기의 종류와 타겟과의 거리, 유닛의 심리적/물리적 상태에 따라 역동적으로 명중 확률이 계산되어 깊이 있는 데이터 기반 전술 환경을 형성합니다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **거리 비례 명중률 연산 (Range-based Accuracy Scaling)**
|
||||
@@ -25,7 +25,7 @@ WARNO의 탄도학 및 명중률 알고리즘은 거리에 따른 비선형적
|
||||
* 이에 더해 항공기는 숙련도 레벨에 따라 명중률을 고정적으로 차감(레벨당 -5%)시키는 '회피 기동(Evasive Maneuvers)' 메커니즘을 추가로 가져, 고숙련 파일럿의 생존성을 데이터적으로 보장합니다 [4, 9].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[장갑 관통 모델링 (Armor Penetration Modeling)]], [[제압 및 응집력 시스템 (Suppression and Cohesion System)]], [[NDF (Neutral Data Format)]]
|
||||
- **Related Topics:** [[장갑 관통 모델링 (Armor Penetration Modeling)]], [[제압 및 응집력 시스템 (Suppression and Cohesion[[ system]])]], [[NDF (Neutral Data Format)]]
|
||||
- **Projects/Contexts:** [[WARNO 데이터 기반 밸런싱 (WARNO Data-Driven Balancing)]], [[Iriszoom 엔진 물리 렌더링 (Iriszoom Engine Physical Rendering)]]
|
||||
- **Contradictions/Notes:** 소스 문서들은 대공 무기 명중률 공식에서 ECM이 승수로 작용한다는 점에 동의하나 [4, 8], 소스 28에서는 여기에 공격자의 숙련도 배율이 추가된 구체적인 인게임 수학적 산출식(`명중률 × (1+경험치 보정) × (1-ECM)`)을 제시하여 더 복합적인 연산이 이루어짐을 보여줍니다 [7].
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
id: P-REINFORCE-AI-047
|
||||
category: "10_Wiki/💡 Topics/AI & ML MLOps"
|
||||
id: [[P-Reinforce]]-AI-047
|
||||
category: "10_Wiki/💡 Topics/AI & ML [[MLOps]]"
|
||||
confidence_score: 0.96
|
||||
tags: [ai, machine learning, mlops, data science]
|
||||
last_reinforced: 2026-06-XX
|
||||
@@ -15,7 +15,7 @@ github_commit: "[P-Reinforce] Processed Concept Drift (개념 드리프트)."
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **정의:** 머신러닝 시스템이 배포되고 운영되는 환경에서 발생하는 데이터 분포의 변화를 의미한다. 이는 단순한 '데이터 부족' 이상의 근본적인 모델 성능 저하 문제다.
|
||||
- **유형 및 원인:**
|
||||
1. **Covariate Shift (공변량 드리프트):** 입력 데이터 $P(X)$가 변하는 경우. (예: 특정 계절에만 발생하는 트래픽 패턴 변화).
|
||||
1. **Covariate [[Shift]] (공변량 드리프트):** 입력 데이터 $P(X)$가 변하는 경우. (예: 특정 계절에만 발생하는 트래픽 패턴 변화).
|
||||
2. **Concept Drift (개념 드리프트):** 실제 데이터 생성 과정 자체가 변하여, 같은 입력 $X$에 대한 레이블 $Y$의 조건부 확률 $P(Y|X)$가 변하는 경우. (예: 사용자의 구매 행동 패턴이 시대에 따라 근본적으로 변화).
|
||||
- **탐지 및 대응:**
|
||||
1. **모니터링:** 모델 예측 결과와 실제 데이터 분포 간의 KL Divergence, JS Divergence 등을 주기적으로 측정하여 이상 징후를 포착한다.
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
id: P-REINFORCE-8DB819
|
||||
id: [[P-Reinforce]]-8DB819
|
||||
category: "10_Wiki/💡 Topics/AI & Narrative"
|
||||
confidence_score: 0.95
|
||||
tags: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Batch 10 - Wikified AI-Driven Narrative Systems"
|
||||
github_commit: "[P-Reinforce] Batch 10 - Wikified AI-Driven Narrative[[ system]]s"
|
||||
---
|
||||
|
||||
# [[AI-Driven Narrative Systems]]
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
id: P-REINFORCE-E4FCEF
|
||||
category: "10_Wiki/💡 Topics/AI & Psychology"
|
||||
id: [[P-Reinforce]]-E4FCEF
|
||||
category: "10_Wiki/💡 Topics/AI & [[Psychology]]"
|
||||
confidence_score: 0.95
|
||||
tags: []
|
||||
last_reinforced: 2026-04-20
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
id: P-REINFORCE-92F236
|
||||
id: [[P-Reinforce]]-92F236
|
||||
category: "10_Wiki/💡 Topics/AI & Tools"
|
||||
confidence_score: 0.95
|
||||
tags: []
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-AIAC-001
|
||||
id: [[P-Reinforce]]-AUTO-AIAC-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, ai-accountability, responsibility, algorithmic-transparency, ethics-governance]
|
||||
@@ -27,6 +27,6 @@ AI 책임론(AI Accountability)은 AI 시스템의 설계, 개발, 배포 및
|
||||
- **정책 변화(RL Update)**: 자율주행차나 의료 AI처럼 생명과 직결된 분야에서는 사고 시 AI 모델의 최종 파라미터 상태를 디지털 블랙박스로 기록하고 보존하는 것이 법적 정책 의무 사항이 됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Ethics & AI]], [[AI & Data Sovereignty]], [[Safety & Reliability]], Generative-AI-Safety, [[Decision Theory]]
|
||||
- **Modern Tech/Tools**: Algorithmic Impact Assessment (AIA), Explainable AI (XAI) toolkits.
|
||||
- [[Ethics & AI]], [[AI & Data Sovereignty]], [[Safety & Reliability]], [[Generative-AI]]-Safety, [[Decision Theory]]
|
||||
- **Modern Tech/Tools**: Algorithmic Impact [[Assessment]] (AIA), Explainable AI (XAI) toolkits.
|
||||
---
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
id: AGENTS-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, ai-agents, autonomous-agents, reasoning, planning]
|
||||
tags: [ai, ai-agents, [[Autonomous-Agents]], [[Reasoning]], planning]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
@@ -12,12 +12,12 @@ last_reinforced: 2026-04-26
|
||||
> "단순한 답변기가 아닌, 목표를 위해 도구를 쓰고 스스로 계획하는 '행동 주체'로 진화하라" — 거대 모델의 추론 능력을 바탕으로 목표를 설정하고, 실행 계획을 수립하며, 외부 도구(브라우저, 코드 에디터 등)를 사용해 태스크를 완수하는 인공지능 시스템.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 사용자의 추상적인 요청을 구체적인 작업 단위로 분해(Planning)하고, 각 단계를 실행(Action)하며, 결과를 관찰(Observation)하여 다음 행동을 결정하는 루프 기반의 자율성 패턴.
|
||||
- **추출된 패턴:** 사용자의 추상적인 요청을 구체적인 작업 단위로 분해(Planning)하고, 각 단계를 실행(Action)하며, 결과를 관찰([[Observation]])하여 다음 행동을 결정하는 루프 기반의 자율성 패턴.
|
||||
- **핵심 루프 (ReAct 패턴 등):**
|
||||
- **Reasoning:** 현재 상황을 분석하고 무엇을 해야 할지 판단.
|
||||
- **Planning:** 목표 달성을 위한 단계별 워크플로우 생성.
|
||||
- **Tool Use:** API, 웹 검색, 파일 시스템 접근 등 외부 도구 활용.
|
||||
- **Memory:** 대화의 맥락(단기)과 지식 베이스(장기)를 활용하여 일관성 유지.
|
||||
- **[[memory]]:** 대화의 맥락(단기)과 지식 베이스(장기)를 활용하여 일관성 유지.
|
||||
- **주요 사례:** AutoGPT, BabyAGI, 그리고 현재 작동 중인 Antigravity 에이전트.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
id: P-REINFORCE-92F236
|
||||
id: [[P-Reinforce]]-92F236
|
||||
category: "10_Wiki/💡 Topics/AI & Tools"
|
||||
confidence_score: 0.95
|
||||
tags: []
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-AIGO-001
|
||||
id: [[P-Reinforce]]-AUTO-AIGO-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, ai-governance, policy, regulation, global-standards, tech-ethics]
|
||||
tags: [auto-reinforced, ai-governance, policy, regulation, [[Global-Standard]]s, tech-ethics]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -20,13 +20,13 @@ AI 거버넌스(AI Governance)는 인공지능 기술의 개발 및 활용이
|
||||
* **Technical Standards**: 보안, 성능, 상호운용성을 위한 기술 표준.
|
||||
2. **주요 쟁점**:
|
||||
* **Risk-based Approach**: AI의 위험도에 따라 다른 수위의 규제 적용. (허용 불가 - 고위험 - 저위험)
|
||||
* **International Cooperation**: 국경 없는 기술 특성상 국가 간 공조 필수.
|
||||
* **International Co[[Opera]]tion**: 국경 없는 기술 특성상 국가 간 공조 필수.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 기술 발전을 저해한다는 이유로 규제에 소극적이었으나, 현대 정책은 '안전한 기술이 더 큰 시장을 만든다'는 인식 하에 선제적인 '안심 거버넌스 정책'으로 패러다임을 전환함(RL Update).
|
||||
- **정책 변화(RL Update)**: 단순히 사후 규제가 아닌, 설계 단계부터 거버넌스를 코드에 녹여내는 'Governance by Design' 정책이 테크 기업의 필수 준수 사항이 됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[AI Accountability]], [[AI Safety]], [[AI & Data Sovereignty]], [[Ethics & AI]], Generative-AI-Safety
|
||||
- **Modern Tech/Tools**: ISO/IEC 42001 (AI Management System), NIST AI Risk Management Framework.
|
||||
- [[AI Accountability]], [[AI Safety]], [[AI & Data Sovereignty]], [[Ethics & AI]], [[Generative-AI]]-Safety
|
||||
- **Modern Tech/Tools**: ISO/IEC 42001 (AI [[Management]][[ system]]), NIST AI [[Risk Management]] Framework.
|
||||
---
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-AIHU-001
|
||||
id: [[P-Reinforce]]-AUTO-AIHU-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced, ai-humanism, philosophy, human-centric, coexistence, existential-risks]
|
||||
tags: [auto-reinforced, ai-humanism, [[Philosophy]], human-centric, coexistence, existential-risks]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-AILI-001
|
||||
id: [[P-Reinforce]]-AUTO-AILI-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, ai-literacy, education, digital-competence, critical-thinking, future-skills]
|
||||
@@ -18,15 +18,15 @@ AI 리터러시(AI Literacy)는 단순히 AI를 사용하는 기술을 넘어, A
|
||||
* **Understanding**: 데이터, 알고리즘, 모델링의 기본 원리 파악.
|
||||
* **Utilization**: 프롬프트 엔지니어링이나 에이전트 활용을 통한 문제 해결 능력.
|
||||
* **Evaluation**: AI의 답변이 편향되거나 허위 정보(Hallucination)가 아닌지 검증.
|
||||
* **Ethical Reflection**: AI 사용 시 발생할 수 있는 보안, 저작권, 윤리 문제 인지.
|
||||
* **Ethical [[Reflection]]**: AI 사용 시 발생할 수 있는 보안, 저작권, 윤리 문제 인지.
|
||||
2. **왜 중요한가?**:
|
||||
* 지식 정보의 비대칭성을 해소하고, AI가 가져올 일자리의 변화에 적응하기 위한 기초 체력임. (Adaptability와 연결)
|
||||
* 지식 정보의 비대칭성을 해소하고, AI가 가져올 일자리의 변화에 적응하기 위한 기초 체력임. ([[Adaptability]]와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 소수의 개발자만 알면 되는 '코딩' 정책이 주류였으나, 현대의 보편 교육 정책은 전 국민이 AI의 논리를 이해해야 하는 'AI 시민 역량 정책'으로 확대됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 기업 채용 및 승진 정책에서, 특정 툴 사용 능력을 넘어 AI와의 협업 능력(Co-intelligence)을 핵심 평가지표로 삼는 정책이 확산 중임.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Adaptability]], Prompt-Engineering-Strategies, [[Ethics & AI]], [[AI for Social Good]], Vocational-Training
|
||||
- [[Adaptability]], [[Prompt-Engineering]]-Strategies, [[Ethics & AI]], [[AI for Social Good]], Vocational-Training
|
||||
- **Modern Tech/Tools**: AI Literacy education tools (Elements of AI), Generative AI sandbox.
|
||||
---
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
id: P-REINFORCE-AI-SAFETY
|
||||
id: [[P-Reinforce]]-AI-SAFETY
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [AI Safety, Alignment, Risk Management, AI Ethics]
|
||||
tags: [[[AI Safety]], [[Alignment]], Risk [[Management]], AI Ethics]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -12,9 +12,9 @@ last_reinforced: 2026-04-20
|
||||
> "브레이크 없는 기차는 재앙이다." 인간보다 강력한 지능이 탄생했을 때, 그 지능이 인간의 목표와 문명을 파괴하지 않도록 기술적/방어적 보호막을 구축하는 가장 시급한 연구 분야다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Robustness**:
|
||||
- **[[Robustness]]**:
|
||||
- 적대적 공격(Adversarial Attack)이나 처음 보는 돌발 상황에서도 AI가 오작동하지 않고 안전하게 관리되는 성질.
|
||||
- **Interpretability**:
|
||||
- **[[Interpretability]]**:
|
||||
- 신경망이라는 블랙박스 내부에서 어떤 논리 구조로 판단을 내리는지 인간이 읽을 수 있게 시각화하고 분석하는 기술(Mechanistic Interpretability).
|
||||
- **Scalable Oversight**:
|
||||
- 인간이 이해하기 힘든 복잡한 지능을 가진 AI를 다른 AI가 감시하게 하여, 인간의 통제력을 잃지 않게 하는 감시 체계.
|
||||
@@ -24,4 +24,4 @@ last_reinforced: 2026-04-20
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[AI-Alignment]] , AI-Governance
|
||||
- Strategy: [[Reliability_Safety_First]]
|
||||
- [[Strategy]]: [[Reliability_Safety_First]]
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-AISA-001
|
||||
id: [[P-Reinforce]]-AUTO-AISA-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.99
|
||||
tags: [auto-reinforced, ai-safety, alignment, existential-risk, robustness, evaluation]
|
||||
tags: [auto-reinforced, ai-safety, [[Alignment]], existential-risk, [[Robustness]], evaluation]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -26,6 +26,6 @@ AI 안전(AI Safety)은 AI 시스템이 설계된 목표 내에서만 안전하
|
||||
- **정책 변화(RL Update)**: 단순히 기술적 안전을 넘어, 사회적 가치와 공존하는지 검증하는 '거버넌스 연계형 AI 안전 정책'이 글로벌 안전 서밋(UK AI Safety Summit 등)의 핵심 의제가 됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Alignment]], [[AI Governance]], [[Safety & Reliability]], Generative-AI-Safety, [[Ethics & AI]]
|
||||
- **Modern Tech/Tools**: RLHF (Reinforcement Learning from Human Feedback), Jailbreak testing, Model evaluation suites.
|
||||
- [[Alignment]], [[AI Governance]], [[Safety & Reliability]], [[Generative-AI]]-Safety, [[Ethics & AI]]
|
||||
- **Modern Tech/Tools**: RLHF (Reinforcement Learning from Human Feedback), Jailbreak [[Testing]], Model evaluation suites.
|
||||
---
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-AINR-001
|
||||
id: [[P-Reinforce]]-AUTO-AINR-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, ai-narrative, storytelling, generative-ai, interactive-media, literature]
|
||||
tags: [auto-reinforced, ai-narrative, storytelling, [[Generative-AI]], interactive-media, literature]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -16,7 +16,7 @@ AI와 서사(AI and Narrative)는 인공지능 기술이 문학, 영화, 게임
|
||||
|
||||
1. **AI의 서사적 역할**:
|
||||
* **Generative Author**: 프롬프트를 바탕으로 소설, 시나리오, 시 등 텍스트 서사 생성.
|
||||
* **Structure Analyzer**: 수만 권의 책을 분석하여 '영웅의 여정'과 같은 성공적인 서사 패턴 추출 및 적용. (Structuralism과 연결)
|
||||
* **Structure Analyzer**: 수만 권의 책을 분석하여 '영웅의 여정'과 같은 성공적인 서사 패턴 추출 및 적용. ([[Structuralism]]과 연결)
|
||||
* **Dynamic Storyteller**: 사용자의 선택에 따라 세계관과 인물의 반응이 실시간으로 변하는 인터랙티브 서사 구현.
|
||||
2. **기술적 구현**:
|
||||
* LLM의 문맥 유지 능력(Context Window)을 통해 일관성 있는 복합 서사 유지.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-AIFG-001
|
||||
id: [[P-Reinforce]]-AUTO-AIFG-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, ai4good, social-impact, sustainability, humanitarian-ai, global-goals]
|
||||
tags: [auto-reinforced, ai4good, social-impact, [[Sustainability]], humanitarian-ai, global-[[goals]]]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
id: P-REINFORCE-AI-GOV-POLICY
|
||||
id: [[P-Reinforce]]-AI-GOV-POLICY
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.99
|
||||
tags: [AI Governance, Policy, Compliance, Risk Management]
|
||||
tags: [[[AI Governance]], Policy, Compliance, Risk [[Management]]]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-254BE9
|
||||
id: [[P-Reinforce]]-AUTO-254BE9
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
@@ -10,7 +10,7 @@ github_commit: "[P-Reinforce] Continuous Worker - AI 생성 코드 검증(AI Cod
|
||||
# [[AI 생성 코드 검증(AI Code Assurance)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> AI Code Assurance(AI 생성 코드 검증)는 AI가 생성하거나 지원한 코드로 인해 발생할 수 있는 고유한 품질 및 보안 위험을 해결하기 위해 설계된 워크플로우이자 검증 프로세스입니다 [1]. 이를 통해 조직은 AI가 작성한 코드가 프로덕션 환경에 배포되기 전에 엄격한 보안, 신뢰성 및 품질 표준을 충족하는지 확인할 수 있습니다 [1, 2]. 주로 정적 애플리케이션 보안 테스트(SAST)와 자동화된 코드 리뷰를 활용하여 결함과 취약점을 조기에 식별하고 일관된 표준을 강제합니다 [2, 3].
|
||||
> AI Code Assurance(AI 생성 코드 검증)는 AI가 생성하거나 지원한 코드로 인해 발생할 수 있는 고유한 품질 및 보안 위험을 해결하기 위해 설계된 워크플로우이자 검증 프로세스입니다 [1]. 이를 통해 조직은 AI가 작성한 코드가 프로덕션 환경에 배포되기 전에 엄격한 보안, 신뢰성 및 품질 표준을 충족하는지 확인할 수 있습니다 [1, 2]. 주로 정적 애플리케이션 보안 테스트([[SAST]])와 자동화된 코드 리뷰를 활용하여 결함과 취약점을 조기에 식별하고 일관된 표준을 강제합니다 [2, 3].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **목적 및 필요성**
|
||||
@@ -18,7 +18,7 @@ github_commit: "[P-Reinforce] Continuous Worker - AI 생성 코드 검증(AI Cod
|
||||
|
||||
- **주요 기능 및 작동 방식**
|
||||
- **AI 코드 감지 및 추적:** 시스템은 프로젝트 내에 AI 생성 코드가 존재함을 자동으로 감지하거나 개발자가 직접 태그를 지정할 수 있게 합니다 [3]. 이를 통해 명확한 라벨링과 배지를 부여하여 AI 코드의 관리, 유지보수 및 규정 준수 모니터링을 간소화합니다 [3].
|
||||
- **정적 코드 분석(SAST) 적용:** 결정론적(deterministic)이고 독립적인 코드 검증 방식인 정적 코드 분석과 오염 분석(Taint Analysis)을 사용하여 코드를 스캔합니다 [4, 6]. 이를 통해 보안 취약점, 유출된 비밀 정보, 코드 냄새(Code smells), 논리적 결함 및 성능 위험을 풀 리퀘스트(Pull Request) 단계에서 조기에 표면화합니다 [4, 6, 7].
|
||||
- **정적 코드 분석(SAST) 적용:** 결정론적(deterministic)이고 독립적인 코드 검증 방식인 정적 코드 분석과 오염 분석(Taint [[Analysis]])을 사용하여 코드를 스캔합니다 [4, 6]. 이를 통해 보안 취약점, 유출된 비밀 정보, 코드 냄새(Code smells), 논리적 결함 및 성능 위험을 풀 리퀘스트(Pull Request) 단계에서 조기에 표면화합니다 [4, 6, 7].
|
||||
- **워크플로우 및 에이전트 통합:** IDE부터 CI/CD 파이프라인에 이르기까지 기존 개발 워크플로우에 원활하게 통합됩니다 [6, 8]. 특히, MCP(Model Context Protocol)를 통해 Cursor, Claude Code, Windsurf와 같은 AI 코딩 에이전트와 직접 연결되어, 코드가 생성되는 실시간 대화 흐름 속에서 보안 핫스팟 분석 및 피드백을 제공합니다 [4, 8, 9].
|
||||
|
||||
- **기대 효과**
|
||||
@@ -29,8 +29,8 @@ github_commit: "[P-Reinforce] Continuous Worker - AI 생성 코드 검증(AI Cod
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Static Application Security Testing (SAST)]], [[Model Context Protocol (MCP)]], Automated Code Review
|
||||
- **Projects/Contexts:** SonarQube Server, SonarQube Cloud
|
||||
- **Related Topics:** [[Static Application Security [[Testing]] (SAST)]], [[Model Context Protocol (MCP)]], Automated [[Code Review]]
|
||||
- **Projects/Contexts:** [[SonarQube]] Server, SonarQube Cloud
|
||||
- **Contradictions/Notes:** 소스에 따르면 AI 어시스턴트가 생성하는 코드는 본질적으로 일관성이 없고 예측하기 어려울 수 있지만, 이에 적용되는 정적 코드 분석 기술은 '결정론적(deterministic)'이므로 AI 코드의 불확실성을 극복하고 신뢰할 수 있는 독립적인 검증을 제공할 수 있다고 강조합니다 [4].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,27 +1,27 @@
|
||||
---
|
||||
id: P-REINFORCE-AI-AGENT
|
||||
id: [[P-Reinforce]]-AI-AGENT
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [AI Agent, Autonomy, Planning, Reasoning, Action]
|
||||
tags: [AI Agent, Autonomy, Planning, [[Reasoning]], Action]
|
||||
last_reinforced: 2026-04-20
|
||||
---
|
||||
|
||||
# AI-에이전트-(AI-Agent)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "단순한 계산기에서 자율적인 일꾼으로." 스스로 목표를 설정하고, 계획을 세우며, 도구(Browser, Terminal 등)를 사용하여 주어진 과업을 끝까지 완수하는 자율적 지능체다.
|
||||
> "단순한 계산기에서 자율적인 일꾼으로." 스스로 목표를 설정하고, 계획을 세우며, 도구([[Browser]], Terminal 등)를 사용하여 주어진 과업을 끝까지 완수하는 자율적 지능체다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Planning & Reasoning**:
|
||||
- 거대 언어 모델(LLM)을 두뇌로 삼아 복잡한 문제를 작은 단계로 분해(Chain-of-Thought)하고 전략을 수립한다.
|
||||
- **Action & Tool Use**:
|
||||
- API 호출, 웹 검색, 코드 실행 등 외부 환경과 상호작용할 수 있는 인터페이스를 통해 실제 세계에 변화를 일으킨다.
|
||||
- **Memory Management**:
|
||||
- **[[memory]] [[Management]]**:
|
||||
- 대화의 맥락(Short-term)과 과거 지식(Long-term)을 RAG나 체크포인트 형태로 유지하여 일관된 수행 능력을 보유한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 현재의 에이전트는 '무한 루프'나 '환각'에 빠질 위험이 크다. 이를 극복하기 위해 에이전트가 자신의 결과물을 스스로 검토하는 'Self-Correction' 루프와, 인간이 중간에 개입하는 'Human-in-the-loop' 설계가 필수적이다.
|
||||
- 현재의 에이전트는 '무한 루프'나 '환각'에 빠질 위험이 크다. 이를 극복하기 위해 에이전트가 자신의 결과물을 스스로 검토하는 '[[Self-Correction]]' 루프와, 인간이 중간에 개입하는 'Human-in-the-loop' 설계가 필수적이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Multi-Agent-System-(다중-에이전트-시스템) , Agent-Communication-Protocol-(에이전트-통신-규약)
|
||||
- Related: [[Multi-agent-System]]-(다중-에이전트-시스템) , Agent-Communication-Protocol-(에이전트-통신-규약)
|
||||
- Deployment: [[Deployment_Final_Gate]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# [[AI 이미지 생성 워크플로우 (AI Image Generation Workflow)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
AI 이미지 생성 워크플로우는 창작자가 텍스트 프롬프트를 입력하여 초기 이미지를 생성한 후, 반복적인 수정과 세부 조정을 통해 최종 결과물을 완성하는 일련의 과정이다 [1-3]. 이 과정은 명확한 피사체(Subject), 스타일, 조명 등의 뼈대를 잡는 단순한 프롬프트로 시작하여, 결과물을 평가한 뒤 점진적으로 부정 프롬프트(Negative Prompt)와 세부 매개변수를 추가하며 발전시킨다 [4-6]. 최근에는 단일 이미지 생성을 넘어 시안(Draft)을 빠르게 대량 생산하고 최적의 구도를 선택하거나, 일관된 스타일 참조 기능을 활용하는 등 전문가 수준의 파이프라인으로 진화하고 있다 [7, 8].
|
||||
## 📌[[ brief]] Summary
|
||||
AI 이미지 생성 워크플로우는 창작자가 텍스트 프롬프트를 입력하여 초기 이미지를 생성한 후, 반복적인 수정과 세부 조정을 통해 최종 결과물을 완성하는 일련의 과정이다 [1-3]. 이 과정은 명확한 피사체(Subject), 스타일, 조명 등의 뼈대를 잡는 단순한 프롬프트로 시작하여, 결과물을 평가한 뒤 점진적으로 부정 프롬프트(Negative [[prompt]])와 세부 매개변수를 추가하며 발전시킨다 [4-6]. 최근에는 단일 이미지 생성을 넘어 시안(Draft)을 빠르게 대량 생산하고 최적의 구도를 선택하거나, 일관된 스타일 참조 기능을 활용하는 등 전문가 수준의 파이프라인으로 진화하고 있다 [7, 8].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **반복적 프롬프트 정교화 (Iterative Prompting):**
|
||||
* **반복적 프롬프트 정교화 ([[Iterative Prompting]]):**
|
||||
AI 이미지 생성은 단 한 번의 완벽한 프롬프트로 끝나는 것이 아니라, 넓고 모호한 지시에서 시작해 구체적이고 좁은 지시로 나아가는 고도의 반복적 과정이다 [1-3]. 단순하고 명확한 아이디어로 시작해 생성된 이미지를 바탕으로 예술적 요소, 조명, 환경 등의 세부 사항을 덧붙이는 방식이 권장된다 [4, 9]. 일반적으로 첫 프롬프트로 80%의 틀을 완성하고, 3~5번의 변형과 후속 프롬프트를 통해 세부 사항을 다듬어 나간다 [10].
|
||||
* **모델별 맞춤형 워크플로우 전략:**
|
||||
* **Midjourney:** V7 모델의 '드래프트 모드(Draft Mode)'를 활용해 저렴하고 빠른 속도로 여러 시안을 생성한 뒤, 가장 나은 구도를 고화질(HD)로 승격시키는 파이프라인이 비용과 시간 측면에서 효과적이다 [7, 11]. 이후 `--sref`(스타일 참조)나 `--oref`(옴니 참조) 파라미터를 사용하여 일관된 시각적 방향성을 재사용하며 편집을 진행한다 [8, 12, 13].
|
||||
@@ -18,8 +18,8 @@ AI 이미지 생성 워크플로우는 창작자가 텍스트 프롬프트를
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[프롬프트 엔지니어링 (Prompt Engineering)]], [[부정 프롬프트 (Negative Prompt)]], [[인페인팅 및 아웃페인팅 (Inpainting and Outpainting)]], [[프롬프트 가중치 (Prompt Weights)]]
|
||||
- **Projects/Contexts:** [[미드저니 V7 드래프트 모드 (Midjourney V7 Draft Mode)]], [[DALL-E 3와 ChatGPT 통합 워크플로우]]
|
||||
- **Projects/Contexts:** [[미드저니 V7 드래프트 모드 ([[Midjourney V7 Draft Mode]])]], [[DALL-E 3와 ChatGPT 통합 워크플로우]]
|
||||
- **Contradictions/Notes:** 부정 프롬프트 사용과 관련하여, Stable Diffusion에서는 원치 않는 요소를 배제하고 이미지 품질을 높이기 위한 필수적이고 강력한 도구로 활용되지만 [21, 24, 35], DALL-E 3 모델은 "No", "Without"과 같은 부정 지시어를 잘 처리하지 못하고 오히려 해당 요소를 생성해버리는 경향이 있어 긍정형 문장 위주로 프롬프트를 구성해야 한다는 기술적 차이점이 있다 [16, 36, 37].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-30*
|
||||
*Last updated: [[2026-04-30]]*
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
# [[AI 이미지 품질 최적화 및 디버깅 (Image Quality Optimization & Debugging)]]
|
||||
# [[AI 이미지 품질 최적화 및 디버깅 (Image Quality [[Optimization]] & Debugging)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌[[ brief]] Summary
|
||||
AI 이미지 생성에서 품질 최적화 및 디버깅은 프롬프트 매개변수, 가중치 조절, 그리고 후보정 편집 기능을 활용하여 시각적 결과물의 완성도를 높이고 예기치 않은 오류를 수정하는 과정입니다. 고해상도 관련 키워드나 네거티브 프롬프트를 전략적으로 사용하여 원치 않는 시각적 결함을 사전에 차단합니다. 또한, 단 번에 완벽한 결과를 기대하기보다는 인페인팅(Inpainting)이나 드래프트 모드(Draft Mode) 등을 통해 문제 영역을 식별하고 점진적으로 개선해 나가는 반복적인 작업이 필수적입니다.
|
||||
|
||||
## 📖 Core Content
|
||||
- **고품질 키워드 및 파라미터 활용 (Quality Keywords & Parameters)**
|
||||
이미지의 완성도를 높이려면 프롬프트에 "8k", "4k", "high resolution", "ultra detailed", "sharp focus"와 같은 해상도 및 디테일 관련 품질 수식어를 추가하는 것이 좋습니다 [1]. Midjourney의 경우 `--q` (quality) 파라미터를 사용하여 디테일과 렌더링 시간을 조정할 수 있으며, 이 값이 클수록 더 많은 디테일이 부여됩니다 [1-3]. 초기 생성 후에는 업스케일(Upscale) 기능을 통해 이미지의 크기를 키우면서 미세한 디테일을 추가로 개선할 수 있습니다 [4].
|
||||
- **고품질 키워드 및 파라미터 활용 (Quality Keywords & [[Parameter]]s)**
|
||||
이미지의 완성도를 높이려면 프롬프트에 "8k", "4k", "high re[[Solution]]", "ultra detailed", "sharp focus"와 같은 해상도 및 디테일 관련 품질 수식어를 추가하는 것이 좋습니다 [1]. Midjourney의 경우 `--q` (quality) 파라미터를 사용하여 디테일과 렌더링 시간을 조정할 수 있으며, 이 값이 클수록 더 많은 디테일이 부여됩니다 [1-3]. 초기 생성 후에는 업스케일(Upscale) 기능을 통해 이미지의 크기를 키우면서 미세한 디테일을 추가로 개선할 수 있습니다 [4].
|
||||
|
||||
- **네거티브 프롬프트를 통한 결함 디버깅 (Debugging via Negative Prompts)**
|
||||
- **네거티브 프롬프트를 통한 결함 디버깅 (Debugging via Negative [[prompt]]s)**
|
||||
기형적인 손, 흐릿한 초점, 불필요한 텍스트나 워터마크 등 이미지의 구조적 결함이 나타날 때 네거티브 프롬프트는 핵심적인 디버깅 도구가 됩니다 [5, 6]. 단순히 "bad"와 같은 모호한 단어를 쓰기보다는 "extra fingers", "misaligned eyes"와 같이 화면에 나타난 구체적인 결함 요소를 파악하여 차단하는 것이 훨씬 효과적입니다 [7-9]. 지속적인 결함이 나타나면 `(blurry:1.3)`과 같이 적절한 가중치를 부여해 해당 요소가 생성되는 것을 적극적으로 억제할 수 있습니다 [8].
|
||||
|
||||
- **반복적 정교화와 영역별 수정 (Iterative Refinement & Inpainting)**
|
||||
- **반복적 정교화와 영역별 수정 (Iterative [[Refinement]] & Inpainting)**
|
||||
첫 시도에 오류가 발생하면 전체 프롬프트를 폐기하기보다 특정 부분을 점진적으로 수정하는 접근이 필요합니다 [10, 11]. Midjourney의 'Vary (Region)' 기능이나 Stable Diffusion의 인페인팅을 활용하면, 전체 이미지의 맥락과 분위기를 유지한 상태에서 잘못 생성된 모자나 원치 않는 요소 등 특정 영역만 자유롭게 지우고 다시 생성할 수 있습니다 [12-15].
|
||||
|
||||
- **구문 및 가중치 오류 점검 (Syntax & Weight Troubleshooting)**
|
||||
@@ -25,4 +25,4 @@ AI 이미지 생성에서 품질 최적화 및 디버깅은 프롬프트 매개
|
||||
- **Contradictions/Notes:** 네거티브 프롬프트를 사용할 때 포괄적이고 긴 실패 목록을 복사해 붙여넣는 것보다, 출력물을 확인한 뒤 눈에 띄는 구체적인 결함(예: "text, signature, watermark")만 적은 수로 타겟팅하는 것이 이미지의 구조적 붕괴나 스타일 손실을 막는 데 훨씬 효과적입니다 [5, 27, 28].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-30*
|
||||
*Last updated: [[2026-04-30]]*
|
||||
|
||||
@@ -1,26 +1,26 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-4DB2F8
|
||||
id: [[P-Reinforce]]-AUTO-4DB2F8
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - AI 코드 리뷰 및 보안 취약점 점검(DevSecOps)"
|
||||
github_commit: "[P-Reinforce] Continuous Worker - AI 코드 리뷰 및 보안 취약점 점검([[DevSecOps]])"
|
||||
---
|
||||
|
||||
# [[AI 코드 리뷰 및 보안 취약점 점검(DevSecOps)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> AI 코드 리뷰 및 보안 취약점 점검(DevSecOps)은 소프트웨어 개발 수명 주기(SDLC)의 초기 단계에 AI 기반의 자동화된 정적 분석(SAST)과 인간의 수동 리뷰를 결합하여 코드의 품질과 보안을 선제적으로 확보하는 프로세스입니다 [1, 2]. 개발자는 IDE 내부나 CI/CD 파이프라인의 Pull Request(PR) 단계에서 실시간으로 버그, 로직 결함, 보안 취약점(예: 인젝션, 민감 정보 노출)을 식별하고 수정할 수 있습니다 [3-6]. 결과적으로 기계적이고 반복적인 코드 스타일 검사 및 패턴 기반 취약점 탐지는 AI에 위임하고, 인간은 아키텍처 결정이나 도메인 종속적인 비즈니스 로직을 검토하는 '하이브리드' 방식을 통해 개발 속도와 보안성의 균형을 맞춥니다 [2, 7, 8].
|
||||
> AI 코드 리뷰 및 보안 취약점 점검(DevSecOps)은 소프트웨어 개발 수명 주기(SDLC)의 초기 단계에 AI 기반의 자동화된 정적 분석([[SAST]])과 인간의 수동 리뷰를 결합하여 코드의 품질과 보안을 선제적으로 확보하는 프로세스입니다 [1, 2]. 개발자는 IDE 내부나 CI/CD 파이프라인의 Pull Request(PR) 단계에서 실시간으로 버그, 로직 결함, 보안 취약점(예: 인젝션, 민감 정보 노출)을 식별하고 수정할 수 있습니다 [3-6]. 결과적으로 기계적이고 반복적인 코드 스타일 검사 및 패턴 기반 취약점 탐지는 AI에 위임하고, 인간은 아키텍처 결정이나 도메인 종속적인 비즈니스 로직을 검토하는 '하이브리드' 방식을 통해 개발 속도와 보안성의 균형을 맞춥니다 [2, 7, 8].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **하이브리드 코드 리뷰 모델의 부상**
|
||||
2025년 기준 가장 이상적이고 안전한 코드 리뷰 방식은 자동화 도구와 인간의 통찰력을 결합한 하이브리드 모델입니다 [2]. 자동화된 리뷰 도구는 수천 줄의 코드를 단 몇 분 만에 스캔하여 문법 오류, 알려진 보안 취약점 패턴, 코드 스타일 위반 등을 일관성 있게 찾아냅니다 [6, 9]. 하지만 이러한 도구들은 시스템의 의도나 비즈니스 로직을 이해하는 데 한계가 있습니다 [10]. 따라서 자동화 스캔을 1차 방어선으로 사용하여 일상적인 문제를 해결하고, 고위험 아키텍처, 인증 로직, 교차 서비스 통신 및 비즈니스 규칙 검증과 같은 복잡한 판단은 숙련된 개발자의 수동 리뷰를 통해 진행해야 합니다 [11-14].
|
||||
|
||||
* **AI 기반 정적 애플리케이션 보안 테스트(SAST)**
|
||||
전통적인 SAST 도구는 규칙과 패턴 매칭에 의존하여 높은 오탐률(False Positive)과 알림 피로도를 유발했습니다 [10, 15, 16]. 그러나 Snyk Code, Corgea, GitHub Advanced Security와 같은 최신 AI 네이티브 SAST 도구들은 머신러닝과 대규모 언어 모델(LLM)을 결합하여 코드의 문맥(Semantic)을 파악합니다 [17-20]. 이 도구들은 오염 분석(Taint analysis)과 도달 가능성(Reachability)을 분석해 파일 간 데이터를 추적하며 실제 악용 가능한 위협만을 효과적으로 필터링합니다 [19, 21, 22]. 또한 Copilot Autofix나 DeepCode AI Fix처럼 발견된 취약점에 대해 검증된 수정안(Remediation)을 PR 단계에서 자동으로 제안하여 리뷰 시간을 대폭 단축시킵니다 [23-25].
|
||||
전통적인 SAST 도구는 규칙과 패턴 매칭에 의존하여 높은 오탐률(False Positive)과 알림 피로도를 유발했습니다 [10, 15, 16]. 그러나 Snyk Code, [[Corgea]], GitHub Advanced Security와 같은 최신 AI 네이티브 SAST 도구들은 머신러닝과 대규모 언어 모델(LLM)을 결합하여 코드의 문맥(Semantic)을 파악합니다 [17-20]. 이 도구들은 오염 분석(Taint [[Analysis]])과 도달 가능성(Reachability)을 분석해 파일 간 데이터를 추적하며 실제 악용 가능한 위협만을 효과적으로 필터링합니다 [19, 21, 22]. 또한 Copilot Autofix나 [[DeepCode AI]] Fix처럼 발견된 취약점에 대해 검증된 수정안(Remediation)을 PR 단계에서 자동으로 제안하여 리뷰 시간을 대폭 단축시킵니다 [23-25].
|
||||
|
||||
* **시프트 레프트(Shift-Left)와 파이프라인 자동화**
|
||||
DevSecOps의 핵심은 소프트웨어 병합 및 배포 전에 보안 및 품질 문제를 원천 차단하는 시프트 레프트 전략입니다 [1, 26]. Husky와 lint-staged 등의 도구를 활용해 Git 사전 커밋(Pre-commit) 훅을 설정하면, 변경된 파일에 대해서만 ESLint(로직/품질)와 Prettier(포맷팅)를 강제 적용할 수 있습니다 [27-29]. 이후 CI/CD 파이프라인 내에 SAST 및 소프트웨어 구성 분석(SCA) 도구를 통합하여 임계치 이상의 치명적 취약점이 포함된 코드는 메인 브랜치로 병합되지 못하도록 '품질 게이트' 역할을 수행하게 합니다 [30, 31].
|
||||
* **시프트 레프트([[Shift]]-Left)와 파이프라인 자동화**
|
||||
DevSecOps의 핵심은 소프트웨어 병합 및 배포 전에 보안 및 품질 문제를 원천 차단하는 시프트 레프트 전략입니다 [1, 26]. [[Husky]]와 [[lint-staged]] 등의 도구를 활용해 Git 사전 커밋(Pre-commit) 훅을 설정하면, 변경된 파일에 대해서만 [[ESLint]](로직/품질)와 [[Prettier]](포맷팅)를 강제 적용할 수 있습니다 [27-29]. 이후 CI/CD 파이프라인 내에 SAST 및 소프트웨어 구성 분석(SCA) 도구를 통합하여 임계치 이상의 치명적 취약점이 포함된 코드는 메인 브랜치로 병합되지 못하도록 '품질 게이트' 역할을 수행하게 합니다 [30, 31].
|
||||
|
||||
* **자동화의 한계 및 AI 거버넌스 정책**
|
||||
강력한 자동화 도구라 할지라도 맹신은 위험합니다. 연구에 따르면 SAST 및 자동화 도구는 실제 취약점의 약 22%를 감지하지 못하며 [32, 33], 개발자들이 자동화 시스템의 '녹색 체크마크'만 보고 코드를 제대로 이해하지 않은 채 통과시키는 '녹색 체크마크 증후군(Green Check Mark Syndrome)'과 같은 인지적 나태함을 유발할 수 있습니다 [34, 35]. 기업은 승인되지 않은 퍼블릭 AI 모델에 독점 소스 코드나 고객 데이터가 유출되지 않도록 명확한 AI 사용 정책(AUP)을 수립해야 합니다 [36-38]. 또한 AI가 생성하거나 수정한 코드라도 최종적으로는 반드시 인간 엔지니어의 엄격한 수동 리뷰를 거쳐 이해와 책임을 보장하는 'Human-in-the-Loop' 원칙을 준수해야 합니다 [38, 39].
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-76F9E4
|
||||
id: [[P-Reinforce]]-AUTO-76F9E4
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
@@ -10,10 +10,10 @@ github_commit: "[P-Reinforce] Continuous Worker - AI 코드 리뷰"
|
||||
# [[AI 코드 리뷰]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> AI 코드 리뷰는 인공지능 에이전트나 머신러닝(ML) 기반의 정적 분석 도구(SAST)를 활용하여 소스 코드의 결함, 보안 취약점, 스타일 위반 및 로직 오류를 식별하는 자동화 프로세스입니다 [1-3]. IDE, CI/CD 파이프라인, 풀 리퀘스트(PR) 등 개발 워크플로우에 통합되어 개발자에게 실시간에 가까운 피드백과 자동 수정(Auto-fix) 제안을 제공합니다 [2, 4-8]. 이를 통해 코드 리뷰의 대기 시간을 줄이고 일관된 품질 표준을 강제할 수 있지만, 아키텍처 의도나 비즈니스 로직의 문맥을 깊이 이해하는 데는 한계가 있어 인간 검토자와의 하이브리드 접근 방식이 필수적으로 요구됩니다 [5, 9-12].
|
||||
> AI 코드 리뷰는 인공지능 에이전트나 머신러닝(ML) 기반의 정적 분석 도구([[SAST]])를 활용하여 소스 코드의 결함, 보안 취약점, 스타일 위반 및 로직 오류를 식별하는 자동화 프로세스입니다 [1-3]. IDE, CI/CD 파이프라인, 풀 리퀘스트(PR) 등 개발 워크플로우에 통합되어 개발자에게 실시간에 가까운 피드백과 자동 수정(Auto-fix) 제안을 제공합니다 [2, 4-8]. 이를 통해 코드 리뷰의 대기 시간을 줄이고 일관된 품질 표준을 강제할 수 있지만, 아키텍처 의도나 비즈니스 로직의 문맥을 깊이 이해하는 데는 한계가 있어 인간 검토자와의 하이브리드 접근 방식이 필수적으로 요구됩니다 [5, 9-12].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **작동 방식 및 주요 기술**: 기존의 규칙 기반 정적 분석에 머신러닝(ML), 대규모 언어 모델(LLM) 등을 결합하여 코드의 문맥, 데이터 흐름(Data flow), 오염 추적(Taint analysis) 등을 시맨틱하게 분석합니다 [4, 13-18].
|
||||
- **작동 방식 및 주요 기술**: 기존의 규칙 기반 정적 분석에 머신러닝(ML), 대규모 언어 모델(LLM) 등을 결합하여 코드의 문맥, 데이터 흐름(Data flow), 오염 추적(Taint [[Analysis]]) 등을 시맨틱하게 분석합니다 [4, 13-18].
|
||||
- **주요 이점**: 대규모 코드베이스를 단 몇 초에서 몇 분 안에 스캔하여 보안 취약점과 버그를 조기에 발견합니다 [19, 20]. 시니어 검토자의 큐(Queue)에서 저위험군 코멘트를 제거하여 PR 검토 주기를 최대 40%까지 단축시키며, 결과적으로 인간 검토자가 아키텍처 설계와 비즈니스 로직에 집중할 수 있도록 돕습니다 [5, 11, 19].
|
||||
- **한계점 및 위험성**: AI는 코드의 전반적인 아키텍처 의도나 비즈니스 로직을 완벽히 이해하지 못하는 '문맥 맹점(Context Blindness)'을 지닙니다 [12, 21, 22]. 또한, 오탐지(False Positives)를 발생시키거나 환각(Hallucination)에 의한 잘못된 수정안을 제안할 위험이 존재하며, 검토자가 AI를 맹신하여 비판적 사고가 저하되는 '녹색 체크 표시 증후군(Green Check Mark Syndrome)'을 초래할 수 있습니다 [12, 23-25].
|
||||
- **하이브리드 리뷰 모델 및 거버넌스**: 2025년 이후의 현대 소프트웨어 개발에서는 AI 자동화 리뷰와 인간의 수동 리뷰를 결합한 '하이브리드(Hybrid) 리뷰'가 모범 사례로 꼽힙니다 [9-11, 26-28]. 일반적인 취약점 패턴이나 문법 등 기계적인 검증은 AI 도구에 맡기고, 도메인 특화 비즈니스 로직이나 교차 서비스 영향도 평가는 인간이 담당해야 합니다 [28, 29]. 아울러 지적 재산(IP) 유출 방지와 보안을 위해 "인간 개입(Human-in-the-Loop)"을 의무화하는 명확한 AI 사용 정책(Governance) 수립이 필수적입니다 [30-34].
|
||||
@@ -25,7 +25,7 @@ github_commit: "[P-Reinforce] Continuous Worker - AI 코드 리뷰"
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[SAST]], 풀 리퀘스트(Pull Request), [[DevSecOps]]
|
||||
- **Projects/Contexts:** [[SonarQube]], Snyk Code, GitHub Advanced Security, [[Corgea]]
|
||||
- **Contradictions/Notes:** AI 코드 리뷰 도구의 도입만으로는 배포 성능이나 품질이 보장되지 않는다는 점에 유의해야 합니다. 맹목적인 도구 도입과 높은 AI 사용률에도 불구하고 실제 PR 처리 시간이나 재작업 비율은 개선되지 않을 수 있으므로, 결과(DORA 지표 등)에 기반한 관리가 중요합니다 [35-37]. 또한 일부 AI 네이티브 도구들은 오탐률을 혁신적으로 줄였다고 주장하지만(예: Corgea 5% 미만, Veracode 1.1% 미만), 근본적으로 어떠한 도구도 오탐을 완벽히 제거할 수는 없으므로 인간의 검토와 검증 과정이 반드시 수반되어야 합니다 [38-40].
|
||||
- **Contradictions/Notes:** AI 코드 리뷰 도구의 도입만으로는 배포 성능이나 품질이 보장되지 않는다는 점에 유의해야 합니다. 맹목적인 도구 도입과 높은 AI 사용률에도 불구하고 실제 PR 처리 시간이나 재작업 비율은 개선되지 않을 수 있으므로, 결과(DORA 지표 등)에 기반한 관리가 중요합니다 [35-37]. 또한 일부 AI 네이티브 도구들은 오탐률을 혁신적으로 줄였다고 주장하지만(예: [[Corgea]] 5% 미만, Veracode 1.1% 미만), 근본적으로 어떠한 도구도 오탐을 완벽히 제거할 수는 없으므로 인간의 검토와 검증 과정이 반드시 수반되어야 합니다 [38-40].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
id: ALIGN-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [ai-safety, alignment, rlhf, ai-ethics, trustworthy-ai]
|
||||
tags: [ai-safety, [[Alignment]], rlhf, ai-ethics, [[Trustworthy-AI]]]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
|
||||
@@ -2,22 +2,22 @@
|
||||
id: MKT-AEO-001
|
||||
category: "10_Wiki/💡 Topics/AI"
|
||||
confidence_score: 1.0
|
||||
tags: [aeo, geo, seo, generative-ai, chatgpt, search-generative-experience, structured-data, ssr]
|
||||
tags: [aeo, geo, seo, [[Generative-AI]], chatgpt, [[Search]]-generative-experience, structured-data, ssr]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# AI Answer Engine Optimization (AEO, AI 답변 엔진 최적화)
|
||||
# AI Answer Engine [[Optimization]] (AEO, AI 답변 엔진 최적화)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "전통적인 검색창의 '목록'에 머물지 말고, 생성형 AI의 '입(답변)'이 되어 브랜드의 가시성을 인용구(Citation)라는 새로운 권력으로 재편하라" — AI 답변 엔진과 챗봇이 웹 콘텐츠를 신뢰할 수 있는 출처로 채택하도록 최적화하는 차세대 검색 전략.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Crawlable Authority and Direct Answer Mapping" — 대규모 AI 크롤러가 JavaScript 실행 비용 없이도 콘텐츠를 즉시 합성할 수 있도록 '사전 렌더링된 HTML'과 '구조화된 데이터'를 제공하는 패턴.
|
||||
- **추출된 패턴:** "Crawlable Authority and Direct Answer Mapping" — 대규모 AI 크롤러가 [[JavaScript]] 실행 비용 없이도 콘텐츠를 즉시 합성할 수 있도록 '사전 렌더링된 HTML'과 '구조화된 데이터'를 제공하는 패턴.
|
||||
- **AEO 달성 핵심 전략:**
|
||||
- **JS Execution Wall 제거:** AI 봇(GPTBot 등)은 비용 문제로 JS를 실행하지 않는 경우가 많으므로, SSR/SSG를 통해 원본 HTML에 핵심 콘텐츠를 노출.
|
||||
- **Semantic Clarity:** `<main>`, `<article>` 태그를 활용해 AI가 핵심 내용과 주변 요소를 즉시 구분하도록 설계.
|
||||
- **JSON-LD Schema Markup:** 페이지의 실체(Entity)와 답변의 맥락을 머신러닝 모델이 오해 없이 이해하도록 명시적 신호 제공.
|
||||
- **Q&A Formatting:** 질문(H2)과 간결한 답변 구조를 통해 AI 오버뷰(SGE)에 직접 인용될 확률 극대화.
|
||||
- **JSON-LD [[Schema]] Markup:** 페이지의 실체(Entity)와 답변의 맥락을 머신러닝 모델이 오해 없이 이해하도록 명시적 신호 제공.
|
||||
- **Q&A [[Formatting]]:** 질문(H2)과 간결한 답변 구조를 통해 AI 오버뷰(SGE)에 직접 인용될 확률 극대화.
|
||||
- **의의:** '검색 결과 클릭' 중심의 시대에서 '답변 내 인용 및 신뢰도 확보' 중심으로 이동하는 AI 시대의 디지털 마케팅 생존법.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
id: P-REINFORCE-8DB819
|
||||
id: [[P-Reinforce]]-8DB819
|
||||
category: "10_Wiki/💡 Topics/AI & Narrative"
|
||||
confidence_score: 0.95
|
||||
tags: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Batch 10 - Wikified AI-Driven Narrative Systems"
|
||||
github_commit: "[P-Reinforce] Batch 10 - Wikified AI-Driven Narrative[[ system]]s"
|
||||
---
|
||||
|
||||
# [[AI-Driven Narrative Systems]]
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user