[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,57 +2,27 @@
|
||||
id: wiki-2026-0508-2026-04-15
|
||||
title: 2026 04 15
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-D3F316]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 2026-04-15"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
status: duplicate
|
||||
canonical_id: daily-note-placeholder
|
||||
duplicate_of: "[[README]]"
|
||||
aliases: []
|
||||
source_trust_level: B
|
||||
confidence_score: 0.5
|
||||
verification_status: redirected
|
||||
tags: [duplicate, daily-note, placeholder]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# [[2026-04-15]]
|
||||
# 2026-04-15
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
> **이 문서는 daily-note placeholder 입니다.** [[README]] 로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 🔗 Graph
|
||||
- 부모: [[README]] (canonical)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/2026-04-15.md]]
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | placeholder 정리 — daily-note 의 redirect |
|
||||
|
||||
@@ -2,57 +2,185 @@
|
||||
id: wiki-2026-0508-brand-identity-management
|
||||
title: Brand Identity Management
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-F8EDF9]
|
||||
aliases: [P-REINFORCE-AUTO-F8EDF9, Brand Identity, BI Management]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
verification_status: applied
|
||||
tags: [branding, marketing, design-systems, identity]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Brand-Identity-Management"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: typescript
|
||||
framework: figma-tokens
|
||||
---
|
||||
|
||||
# [[Brand-Identity-Management]]
|
||||
# Brand Identity Management
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
## 매 한 줄
|
||||
> **"매 brand 의 systematic codification"**. 매 Brand Identity Management 는 logo, typography, palette, voice, motion 을 design-token + governance pipeline 으로 묶어 cross-channel consistency 의 보장. 매 2026 의 modern brand stack 은 Figma Variables + Style Dictionary + AI-assisted asset generation (FLUX, Adobe Firefly).
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
### 매 brand asset 분류
|
||||
- **Visual**: logo, color palette, typography, iconography, photography style.
|
||||
- **Verbal**: tone of voice, lexicon, naming convention.
|
||||
- **Motion**: easing curves, timing, transition vocabulary.
|
||||
- **Sonic**: audio logo, UI sounds.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/Brand-Identity-Management.md]]
|
||||
---
|
||||
### 매 governance layer
|
||||
- **Design tokens**: 매 single source of truth (Figma Variables → Style Dictionary → CSS/iOS/Android).
|
||||
- **Brand portal**: 매 self-service asset library (Frontify, Brandfolder).
|
||||
- **Approval workflow**: 매 marketing automation 의 brand-safe template.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Multi-product company 의 sub-brand 관리 (Atlassian Jira/Confluence/Trello).
|
||||
2. Localization 의 culturally-adapted asset variant.
|
||||
3. AI-generated marketing asset 의 brand-fidelity check (CLIP embedding similarity).
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### 패턴 1: Design Token 정의 (Style Dictionary)
|
||||
```json
|
||||
{
|
||||
"color": {
|
||||
"brand": {
|
||||
"primary": { "value": "#FF6B35", "comment": "Antigravity Orange" },
|
||||
"accent": { "value": "#1B1B1F" },
|
||||
"surface": { "value": "#FAFAFA" }
|
||||
}
|
||||
},
|
||||
"typography": {
|
||||
"display": {
|
||||
"value": {
|
||||
"fontFamily": "Inter",
|
||||
"fontWeight": 700,
|
||||
"fontSize": "48px",
|
||||
"lineHeight": 1.1
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### 패턴 2: Token → Multi-platform output
|
||||
```js
|
||||
// style-dictionary.config.js
|
||||
module.exports = {
|
||||
source: ['tokens/**/*.json'],
|
||||
platforms: {
|
||||
css: { transformGroup: 'css', buildPath: 'dist/css/', files: [{ destination: 'tokens.css', format: 'css/variables' }] },
|
||||
ios: { transformGroup: 'ios', buildPath: 'dist/ios/', files: [{ destination: 'Tokens.swift', format: 'ios-swift/class.swift' }] },
|
||||
android:{ transformGroup: 'android',buildPath: 'dist/android/',files: [{ destination: 'tokens.xml', format: 'android/resources' }] }
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### 패턴 3: Brand-fidelity check (CLIP)
|
||||
```python
|
||||
import torch
|
||||
import clip
|
||||
from PIL import Image
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
device = "cuda" if torch.cuda.is_available() else "cpu"
|
||||
model, preprocess = clip.load("ViT-B/32", device=device)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
BRAND_PROMPT = "Antigravity orange, minimal modern tech brand, geometric"
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
def brand_fidelity(image_path: str) -> float:
|
||||
image = preprocess(Image.open(image_path)).unsqueeze(0).to(device)
|
||||
text = clip.tokenize([BRAND_PROMPT]).to(device)
|
||||
with torch.no_grad():
|
||||
image_features = model.encode_image(image)
|
||||
text_features = model.encode_text(text)
|
||||
sim = torch.cosine_similarity(image_features, text_features).item()
|
||||
return sim # > 0.28 → on-brand
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### 패턴 4: AI-generated asset 의 brand guardrail
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
|
||||
client = Anthropic()
|
||||
|
||||
def critique_asset(asset_url: str, guidelines: str) -> dict:
|
||||
response = client.messages.create(
|
||||
model="claude-opus-4-7-20260301",
|
||||
max_tokens=1024,
|
||||
messages=[{
|
||||
"role": "user",
|
||||
"content": [
|
||||
{"type": "image", "source": {"type": "url", "url": asset_url}},
|
||||
{"type": "text", "text": f"Brand guidelines:\n{guidelines}\n\nReturn JSON: {{on_brand: bool, issues: [...], score: 0-1}}"}
|
||||
]
|
||||
}]
|
||||
)
|
||||
return response.content[0].text
|
||||
```
|
||||
|
||||
### 패턴 5: Tone-of-voice classifier
|
||||
```python
|
||||
TONE_REFERENCE = {
|
||||
"playful": ["hey", "let's", "boom", "yay"],
|
||||
"formal": ["please", "kindly", "we regret"],
|
||||
"antigravity": ["lift", "soar", "weightless", "boundless"]
|
||||
}
|
||||
|
||||
def classify_tone(text: str) -> str:
|
||||
scores = {tone: sum(text.lower().count(w) for w in words)
|
||||
for tone, words in TONE_REFERENCE.items()}
|
||||
return max(scores, key=scores.get)
|
||||
```
|
||||
|
||||
### 패턴 6: Logo placement validator (CV)
|
||||
```python
|
||||
import cv2
|
||||
import numpy as np
|
||||
|
||||
def safe_zone_violation(image, logo_bbox, min_padding_ratio=0.1):
|
||||
h, w = image.shape[:2]
|
||||
x, y, lw, lh = logo_bbox
|
||||
pad_x = min_padding_ratio * w
|
||||
pad_y = min_padding_ratio * h
|
||||
return (x < pad_x or y < pad_y or
|
||||
x + lw > w - pad_x or y + lh > h - pad_y)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Multi-platform consistency | Style Dictionary + Figma Variables |
|
||||
| AI-asset workflow | CLIP fidelity gate + human review |
|
||||
| Sub-brand 관리 | shared core tokens + brand-specific overrides |
|
||||
| Rapid iteration startup | Figma Library only, defer token build |
|
||||
| Enterprise compliance | Frontify/Brandfolder + approval workflow |
|
||||
|
||||
**기본값**: Figma Variables → Style Dictionary → CLIP gate. 매 token-first.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Design Systems]] · [[Marketing]]
|
||||
- 변형: [[Visual Identity]] · [[Tone of Voice]]
|
||||
- 응용: [[Atlassian Design]] · [[IBM Carbon]]
|
||||
- Adjacent: [[Style Dictionary]] · [[Figma Variables]] · [[CLIP]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: brand audit, tone consistency check, asset critique, copy generation 의 voice guardrail.
|
||||
**언제 X**: 매 high-stakes legal trademark review — 매 lawyer 의 영역.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Token sprawl**: 매 ad-hoc 50+ color token. 매 semantic naming (primary/secondary) 으로 collapse.
|
||||
- **Pixel pushing without governance**: 매 Figma file 의 untracked 변경 — token-pipeline bypass.
|
||||
- **AI-asset 의 unsupervised dump**: 매 brand fidelity gate 없이 production publish.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Style Dictionary docs, Figma Variables docs, Frontify case studies).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — substantive content + 2026 stack (CLIP gate, AI-asset workflow) |
|
||||
|
||||
@@ -1,84 +1,192 @@
|
||||
---
|
||||
id: wiki-2026-0508-code-splitting-lazy-loading
|
||||
title: Code Splitting Lazy Loading
|
||||
title: Code Splitting & Lazy Loading
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-B933B1]
|
||||
aliases: [P-REINFORCE-AUTO-B933B1, Code Splitting, Lazy Loading]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
confidence_score: 0.95
|
||||
verification_status: applied
|
||||
tags: [web, performance, bundling, react, vite]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Code Splitting Lazy Loading"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: typescript
|
||||
framework: react+vite
|
||||
---
|
||||
|
||||
# [[Code Splitting Lazy Loading]]
|
||||
# Code Splitting & Lazy Loading
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
## 매 한 줄
|
||||
> **"매 ship-only-what-you-execute"**. 매 Code Splitting 은 single bundle 을 route/component-bound chunk 로 분할하여 initial JS payload 의 minimization. Lazy Loading 은 매 chunk 를 user-interaction 시점에 fetch. 매 2026 의 standard 는 Vite + React.lazy + dynamic import + RSC (React Server Components) hybrid.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
### 매 split 차원
|
||||
- **Route-based**: 매 page 의 lazy import — `/dashboard`, `/settings`.
|
||||
- **Component-based**: 매 heavy widget (chart, code-editor) 의 deferred load.
|
||||
- **Vendor split**: 매 third-party (React, lodash) 의 separate chunk → long-term cache.
|
||||
- **Dynamic feature flag**: 매 A/B variant 의 gated import.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/Code Splitting & Lazy Loading.md]]
|
||||
---
|
||||
### 매 핵심 메커니즘
|
||||
- **Dynamic `import()`**: 매 ES module spec — Promise 반환.
|
||||
- **Bundler chunk splitting**: Webpack/Vite 의 `splitChunks` heuristic.
|
||||
- **HTTP/2 push 의 deprecation**: 매 modern preload + modulepreload 로 대체.
|
||||
- **Streaming SSR + RSC**: 매 chunk 의 server-streamed delivery.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. SaaS dashboard — `/admin` route 의 lazy chunk.
|
||||
2. E-commerce — checkout flow 만 separate bundle.
|
||||
3. Editor app (Notion-like) — markdown/code-editor lazy.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### 패턴 1: React.lazy + Suspense
|
||||
```tsx
|
||||
import { lazy, Suspense } from "react";
|
||||
import { Routes, Route } from "react-router-dom";
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
const Dashboard = lazy(() => import("./pages/Dashboard"));
|
||||
const Settings = lazy(() => import("./pages/Settings"));
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
export function App() {
|
||||
return (
|
||||
<Suspense fallback={<Skeleton />}>
|
||||
<Routes>
|
||||
<Route path="/" element={<Home />} />
|
||||
<Route path="/dashboard" element={<Dashboard />} />
|
||||
<Route path="/settings" element={<Settings />} />
|
||||
</Routes>
|
||||
</Suspense>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### 패턴 2: Vite manual chunks
|
||||
```ts
|
||||
// vite.config.ts
|
||||
import { defineConfig } from "vite";
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
export default defineConfig({
|
||||
build: {
|
||||
rollupOptions: {
|
||||
output: {
|
||||
manualChunks(id) {
|
||||
if (id.includes("node_modules/react")) return "react-vendor";
|
||||
if (id.includes("node_modules/@radix-ui")) return "radix";
|
||||
if (id.includes("/src/charts/")) return "charts";
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### 패턴 3: Preload on hover (intent-based prefetch)
|
||||
```tsx
|
||||
function NavLink({ to, children }: { to: string; children: React.ReactNode }) {
|
||||
const prefetch = () => {
|
||||
if (to === "/dashboard") import("./pages/Dashboard");
|
||||
};
|
||||
return <Link to={to} onMouseEnter={prefetch} onFocus={prefetch}>{children}</Link>;
|
||||
}
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### 패턴 4: Conditional dynamic import
|
||||
```tsx
|
||||
async function loadChart(type: "line" | "bar" | "heatmap") {
|
||||
switch (type) {
|
||||
case "line": return (await import("./charts/Line")).default;
|
||||
case "bar": return (await import("./charts/Bar")).default;
|
||||
case "heatmap": return (await import("./charts/Heatmap")).default;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### 패턴 5: React Server Component (RSC) split
|
||||
```tsx
|
||||
// app/dashboard/page.tsx (Next.js 15+)
|
||||
import { Suspense } from "react";
|
||||
import { HeavyChart } from "./HeavyChart"; // server component
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
export default function Page() {
|
||||
return (
|
||||
<>
|
||||
<Header />
|
||||
<Suspense fallback={<ChartSkeleton />}>
|
||||
<HeavyChart /> {/* streamed independently */}
|
||||
</Suspense>
|
||||
</>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
### 패턴 6: Bundle analyzer pipeline
|
||||
```bash
|
||||
# Vite + rollup-plugin-visualizer
|
||||
npm i -D rollup-plugin-visualizer
|
||||
```
|
||||
```ts
|
||||
import { visualizer } from "rollup-plugin-visualizer";
|
||||
|
||||
export default defineConfig({
|
||||
plugins: [visualizer({ open: true, gzipSize: true })]
|
||||
});
|
||||
```
|
||||
|
||||
### 패턴 7: Module federation (micro-frontend)
|
||||
```ts
|
||||
// host vite.config.ts
|
||||
import federation from "@originjs/vite-plugin-federation";
|
||||
|
||||
export default {
|
||||
plugins: [
|
||||
federation({
|
||||
name: "host",
|
||||
remotes: { checkout: "http://cdn/checkout/remoteEntry.js" },
|
||||
shared: ["react", "react-dom"]
|
||||
})
|
||||
]
|
||||
};
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Multi-page SPA | route-based React.lazy |
|
||||
| Heavy single widget | component-level dynamic import |
|
||||
| Multi-team monorepo | module federation |
|
||||
| Server-rendered Next.js | RSC + Suspense streaming |
|
||||
| Legacy Webpack 4 | upgrade to Vite/Webpack 5 first |
|
||||
| Initial paint > 3s | bundle analyzer + manualChunks |
|
||||
|
||||
**기본값**: Vite + React.lazy(route) + intent-prefetch on hover.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Web Performance]] · [[Bundlers]]
|
||||
- 변형: [[Tree Shaking]] · [[Module Federation]]
|
||||
- 응용: [[React Server Components]] · [[Next.js App Router]]
|
||||
- Adjacent: [[Vite]] · [[Webpack]] · [[Rollup]] · [[esbuild]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: bundle analysis 의 chunk strategy 추천, lazy boundary 후보 식별, manualChunks rule 작성.
|
||||
**언제 X**: 매 production runtime 의 dynamic decision — 매 bundler-time static analysis 의 영역.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Over-splitting**: 매 component 마다 lazy — 매 too many waterfalls. 매 100KB+ threshold.
|
||||
- **Suspense boundary 의 미사용**: 매 React.lazy 의 fallback 없음 → throw.
|
||||
- **Preload everything**: 매 idle prefetch 의 abuse — bandwidth waste.
|
||||
- **Dynamic import in render**: 매 매 render 마다 import() 호출 → re-fetch.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (web.dev code-splitting docs, Vite docs, React.lazy spec, RFC#118).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — substantive content + 2026 stack (Vite, RSC, module federation) |
|
||||
|
||||
@@ -2,57 +2,174 @@
|
||||
id: wiki-2026-0508-description-logics
|
||||
title: Description Logics
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-088907]
|
||||
aliases: [P-REINFORCE-AUTO-088907, DL, ALC, SROIQ]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
confidence_score: 0.92
|
||||
verification_status: applied
|
||||
tags: [logic, knowledge-representation, ontology, owl, semantic-web]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Description-Logics"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: owlready2+hermit
|
||||
---
|
||||
|
||||
# [[Description-Logics]]
|
||||
# Description Logics
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
## 매 한 줄
|
||||
> **"매 decidable fragment of first-order logic"**. 매 Description Logics (DL) 은 concept (class), role (property), individual 을 formal language 로 표현하여 ontology reasoning 의 mathematical foundation. 매 OWL 2 (Web Ontology Language) 는 SROIQ(D) DL 의 syntactic dialect — 매 2026 의 Knowledge Graph + LLM grounding 의 backbone.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
### 매 DL family (expressivity)
|
||||
- **AL** (Attributive Language): atomic concept, conjunction, universal restriction.
|
||||
- **ALC**: AL + full negation. 매 baseline.
|
||||
- **ALCN**: ALC + cardinality.
|
||||
- **SHIQ**: + role hierarchy, inverse role, qualified cardinality.
|
||||
- **SROIQ**: SHIQ + role chain, self-restriction, nominal — OWL 2 DL 의 base.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/Description-Logics.md]]
|
||||
---
|
||||
### 매 reasoning task
|
||||
- **Subsumption**: C ⊑ D (concept inclusion).
|
||||
- **Consistency**: ontology 의 모순 검증.
|
||||
- **Instance check**: a ∈ C.
|
||||
- **Classification**: 전체 concept hierarchy 의 compute.
|
||||
- **Realization**: 매 individual 의 most-specific class.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Biomedical ontology (SNOMED CT, GO) — drug-disease reasoning.
|
||||
2. Knowledge graph 의 schema validation (Wikidata, Schema.org).
|
||||
3. LLM grounding — RAG 의 ontology-constrained retrieval.
|
||||
4. Configuration management — feature compatibility reasoning.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### 패턴 1: ALC concept 정의 (Owlready2)
|
||||
```python
|
||||
from owlready2 import *
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
onto = get_ontology("http://example.org/family.owl")
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
with onto:
|
||||
class Person(Thing): pass
|
||||
class Parent(Person): pass
|
||||
class hasChild(Person >> Person): pass
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
class Mother(Parent):
|
||||
equivalent_to = [Parent & ~onto.search(is_a=onto.Male)[0]]
|
||||
# ALC: Mother ≡ Parent ⊓ ¬Male
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### 패턴 2: SROIQ role chain (grandparent)
|
||||
```python
|
||||
with onto:
|
||||
class hasGrandchild(Person >> Person):
|
||||
# role chain: hasChild ∘ hasChild ⊑ hasGrandchild
|
||||
property_chain = [[hasChild, hasChild]]
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### 패턴 3: Reasoner 실행 (HermiT)
|
||||
```python
|
||||
from owlready2 import sync_reasoner_hermit
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
with onto:
|
||||
sync_reasoner_hermit(infer_property_values=True)
|
||||
|
||||
# inferred axioms inspect
|
||||
for cls in onto.classes():
|
||||
print(cls, "⊑", cls.is_a)
|
||||
```
|
||||
|
||||
### 패턴 4: Tableau algorithm (mini ALC)
|
||||
```python
|
||||
def alc_satisfiable(concept, world=None):
|
||||
"""Naive tableau for ALC C ⊓ ¬C unsatisfiability check."""
|
||||
world = world or {"individuals": {}, "constraints": []}
|
||||
if concept[0] == "AND":
|
||||
for sub in concept[1:]:
|
||||
if not alc_satisfiable(sub, world):
|
||||
return False
|
||||
return True
|
||||
if concept[0] == "NOT":
|
||||
atom = concept[1]
|
||||
if ("ATOM", atom) in world["constraints"]:
|
||||
return False # clash
|
||||
world["constraints"].append(("NOT_ATOM", atom))
|
||||
return True
|
||||
if concept[0] == "ATOM":
|
||||
if ("NOT_ATOM", concept[1]) in world["constraints"]:
|
||||
return False
|
||||
world["constraints"].append(("ATOM", concept[1]))
|
||||
return True
|
||||
# ∃R.C, ∀R.C handled by spawning fresh individual ...
|
||||
```
|
||||
|
||||
### 패턴 5: SPARQL over OWL inference
|
||||
```sparql
|
||||
PREFIX owl: <http://www.w3.org/2002/07/owl#>
|
||||
PREFIX : <http://example.org/family#>
|
||||
|
||||
SELECT ?gp ?gc WHERE {
|
||||
?gp :hasGrandchild ?gc . # inferred via property_chain
|
||||
}
|
||||
```
|
||||
|
||||
### 패턴 6: LLM-grounded ontology query
|
||||
```python
|
||||
import anthropic
|
||||
from owlready2 import get_ontology
|
||||
|
||||
client = anthropic.Anthropic()
|
||||
onto = get_ontology("./family.owl").load()
|
||||
|
||||
def grounded_answer(question: str) -> str:
|
||||
classes = [c.name for c in onto.classes()]
|
||||
response = client.messages.create(
|
||||
model="claude-opus-4-7-20260301",
|
||||
max_tokens=512,
|
||||
system=f"Use only these ontology classes: {classes}. Answer with class names.",
|
||||
messages=[{"role": "user", "content": question}]
|
||||
)
|
||||
return response.content[0].text
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Web ontology / Linked Data | OWL 2 DL (SROIQ) + Protégé |
|
||||
| Lightweight inference | OWL 2 EL (medical) or RL (rule-based) |
|
||||
| Real-time reasoning | RDFS + custom rules (avoid full DL) |
|
||||
| Research / proof-of-concept | ALC + custom tableau |
|
||||
| Fact-heavy KG (Wikidata) | SHACL validation > full DL reasoning |
|
||||
| LLM grounding | EL/RL profile + SPARQL |
|
||||
|
||||
**기본값**: OWL 2 EL (tractable PTIME) + HermiT/ELK reasoner.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Logic]] · [[Knowledge Representation]]
|
||||
- 변형: [[OWL 2]] · [[RDF Schema]]
|
||||
- 응용: [[SNOMED CT]] · [[Wikidata]] · [[Schema.org]]
|
||||
- Adjacent: [[First-Order Logic]] · [[Modal Logic]] · [[Knowledge Graphs]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: ontology design review, axiom suggestion, SPARQL 생성, RAG 의 ontology-grounded prompt.
|
||||
**언제 X**: 매 reasoning soundness 의 결정 — DL reasoner (HermiT, ELK) 의 영역. LLM 은 hint only.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Open-world misunderstanding**: 매 absent fact 가 false 라 가정 — DL 은 OWA (open world).
|
||||
- **Unique Name Assumption 가정**: 매 individual a ≠ b 자동 아님 — `differentFrom` 명시 필요.
|
||||
- **Undecidable extension**: 매 SROIQ 의 추가 expressivity (full datatype reasoning) → 결정불가.
|
||||
- **Reasoner 없이 inference**: 매 axiom 만 작성 + 매 reasoner 미실행 → no inferred triples.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Baader et al. "DL Handbook", W3C OWL 2 spec, Owlready2 docs).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — substantive content + 2026 stack (Owlready2, HermiT, LLM grounding) |
|
||||
|
||||
@@ -2,57 +2,159 @@
|
||||
id: wiki-2026-0508-dopamine-signaling
|
||||
title: Dopamine Signaling
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-C204E9]
|
||||
aliases: [P-REINFORCE-AUTO-C204E9, DA Signaling, RPE, Reward Prediction Error]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
confidence_score: 0.92
|
||||
verification_status: applied
|
||||
tags: [neuroscience, reinforcement-learning, reward, addiction, RPE]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Dopamine Signaling"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: numpy+gymnasium
|
||||
---
|
||||
|
||||
# [[Dopamine Signaling]]
|
||||
# Dopamine Signaling
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
## 매 한 줄
|
||||
> **"매 reward prediction error 의 neural currency"**. 매 Dopamine (DA) signaling 은 mesolimbic + nigrostriatal pathway 에서 phasic burst 로 actual − expected reward (RPE) 를 broadcast — 매 Schultz 1997 의 landmark finding 이 modern reinforcement learning + addiction model 의 bridge. 매 2026 의 frontier 는 multi-dimensional DA (D1/D2 receptor, axonal vs somatic, microcircuit) 의 dissection.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
### 매 pathway
|
||||
- **Mesolimbic** (VTA → NAc): 매 reward, motivation, addiction.
|
||||
- **Mesocortical** (VTA → PFC): 매 cognition, working memory.
|
||||
- **Nigrostriatal** (SNc → dorsal striatum): 매 motor learning, habit.
|
||||
- **Tuberoinfundibular** (hypothalamus → pituitary): 매 prolactin inhibition.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/Dopamine Signaling.md]]
|
||||
---
|
||||
### 매 RPE encoding
|
||||
- **Phasic burst**: 매 unexpected reward → DA 의 firing rate ↑.
|
||||
- **Phasic dip**: 매 omitted expected reward → firing 의 below-baseline.
|
||||
- **CS-shift**: 매 conditioning 의 결과 — burst 의 reward 시점에서 cue 시점으로 shift.
|
||||
- **Tonic level**: 매 background motivation, vigor.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 receptor 타입
|
||||
- **D1-like** (D1, D5): Gs-coupled, cAMP↑, direct pathway, "Go".
|
||||
- **D2-like** (D2, D3, D4): Gi-coupled, cAMP↓, indirect pathway, "NoGo".
|
||||
- **Asymmetric learning**: D1 의 positive RPE, D2 의 negative RPE.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### 매 응용
|
||||
1. Reinforcement learning algorithm (TD-learning) 의 biological basis.
|
||||
2. Parkinson's disease — SNc 의 dopaminergic neuron 손실.
|
||||
3. Addiction — mesolimbic 의 hijacking.
|
||||
4. Schizophrenia — mesocortical hypofunction + mesolimbic hyperfunction.
|
||||
5. ADHD — DA reuptake 의 dysregulation.
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### 패턴 1: TD(0) RPE simulation
|
||||
```python
|
||||
import numpy as np
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
def td_zero(states, rewards, alpha=0.1, gamma=0.95, episodes=1000):
|
||||
V = np.zeros(len(states))
|
||||
rpe_log = []
|
||||
for _ in range(episodes):
|
||||
for t in range(len(states) - 1):
|
||||
rpe = rewards[t] + gamma * V[t+1] - V[t]
|
||||
V[t] += alpha * rpe
|
||||
rpe_log.append((t, rpe))
|
||||
return V, rpe_log
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### 패턴 2: CS-US shift (Pavlovian)
|
||||
```python
|
||||
def conditioning(trials=200, cs_step=10, us_step=20, alpha=0.2, gamma=0.9):
|
||||
"""RPE 가 US 에서 CS 시점으로 shift 하는지 확인."""
|
||||
V = np.zeros(30)
|
||||
history = []
|
||||
for trial in range(trials):
|
||||
r = np.zeros(30); r[us_step] = 1.0
|
||||
for t in range(29):
|
||||
rpe = r[t] + gamma * V[t+1] - V[t]
|
||||
V[t] += alpha * rpe
|
||||
if t in (cs_step, us_step):
|
||||
history.append((trial, t, rpe))
|
||||
return history # late trials: cs_step burst, us_step ≈ 0
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### 패턴 3: D1/D2 asymmetric update
|
||||
```python
|
||||
def d1d2_update(weights, rpe, lr_d1=0.1, lr_d2=0.1):
|
||||
"""positive RPE → D1 facilitation, negative → D2 facilitation."""
|
||||
if rpe > 0:
|
||||
weights["go"] += lr_d1 * rpe
|
||||
else:
|
||||
weights["nogo"] += lr_d2 * (-rpe)
|
||||
return weights
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### 패턴 4: Tonic-phasic interaction
|
||||
```python
|
||||
def vigor_modulated_action(action_values, tonic_da, beta=2.0):
|
||||
"""Niv 2007: tonic DA → response rate."""
|
||||
p = np.exp(beta * tonic_da * action_values)
|
||||
return p / p.sum()
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### 패턴 5: Distributional RPE (Dabney 2020 finding)
|
||||
```python
|
||||
import torch
|
||||
import torch.nn.functional as F
|
||||
|
||||
class DistributionalDA(torch.nn.Module):
|
||||
"""다양한 optimism 의 DA neuron population."""
|
||||
def __init__(self, n_neurons=20):
|
||||
super().__init__()
|
||||
self.taus = torch.linspace(0.1, 0.9, n_neurons)
|
||||
self.values = torch.nn.Parameter(torch.zeros(n_neurons))
|
||||
|
||||
def update(self, reward, lr=0.1):
|
||||
delta = reward - self.values
|
||||
# asymmetric update per neuron
|
||||
with torch.no_grad():
|
||||
self.values += lr * torch.where(
|
||||
delta > 0, self.taus * delta, (1 - self.taus) * delta
|
||||
)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Behavioral RL model | TD(λ) / Q-learning, scalar RPE |
|
||||
| Asymmetric learning bias 모델 | D1/D2 dual-pathway |
|
||||
| Vigor / response rate 모델 | tonic DA + beta scaling |
|
||||
| Risk-sensitive / distributional | distributional RL (Dabney 2020) |
|
||||
| Clinical Parkinson | SNc loss + L-DOPA pharmacology |
|
||||
| Addiction model | mesolimbic phasic 의 hijack + tolerance |
|
||||
|
||||
**기본값**: TD(0) scalar RPE 의 baseline. 매 D1/D2 의 추가 시점은 asymmetric bias 가 핵심인 task.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Neuroscience]] · [[Reinforcement Learning]]
|
||||
- 변형: [[Serotonin]] · [[Norepinephrine]]
|
||||
- 응용: [[Parkinson's Disease]] · [[Addiction]] · [[Reward Prediction Error]]
|
||||
- Adjacent: [[TD-Learning]] · [[Actor-Critic]] · [[Distributional RL]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: literature review (RPE, distributional DA), modeling hypothesis generation, neurobiology + RL bridge 의 explanation.
|
||||
**언제 X**: 매 clinical diagnosis / prescription — 매 neurologist 의 영역.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Scalar oversimplification**: 매 single RPE channel 가정 — distributional + multi-receptor reality 의 무시.
|
||||
- **DA = pleasure 오해**: 매 DA 는 prediction error / motivation, hedonic experience 는 opioid system.
|
||||
- **Human ↔ rodent extrapolation**: 매 microcircuit + receptor expression 의 species difference 의 무시.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Schultz 1997 Science, Niv 2007, Dabney 2020 Nature, modern review Berke 2018).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — substantive content + distributional DA finding |
|
||||
|
||||
@@ -1,70 +1,33 @@
|
||||
---
|
||||
id: wiki-2026-0508-iriszoom-엔진의-물리적-가시화
|
||||
title: Iriszoom 엔진의 물리적 가시화
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: iriszoom-engine
|
||||
duplicate_of: "[[Iriszoom Engine]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, iriszoom, rendering]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# Iriszoom 엔진의 물리적 가시화
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Iriszoom 엔진은 [[WARNO]]에 도입된 Eugen[[ system]]s의 독자적인 3D 그래픽 및 물리 시뮬레이션 엔진으로, 광활한 전략적 전장과 세밀한 전술적 교전을 매끄럽게 연결합니다 [1]. 물리 기반 렌더링(PBR) 기술과 유닛의 상태 데이터를 동기화하여 사실적인 재질과 정교한 파괴 효과를 가시화합니다 [1, 2]. 이를 통해 게임 내의 데이터 중심 설계가 플레이어에게 시각적, 물리적으로 직관적이고 영속적인 전장 환경으로 전달됩니다 [2].
|
||||
> **이 문서는 [[Iriszoom Engine]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **물리 기반 렌더링(PBR) 파이프라인 적용:**
|
||||
Iriszoom 엔진은 과거의 Specular/Glossiness 방식에서 벗어나 최신 [[Metal]]lic/Roughness/Ambient Occlusion 워크플로우를 전면 도입하여 금속 및 비금속의 질감을 현실적으로 구현합니다 [1, 3, 4]. 지연 렌더링(Deferred Rendering) 구조를 바탕으로 장거리 시야에서 흔히 발생하는 스펙큘러 노이즈(specular explosion) 현상을 효과적으로 억제하며, 4K 해상도 텍스처를 통해 시뮬레이션의 현실감을 극대화했습니다 [1, 3, 4].
|
||||
* **동적 가시성과 가변적 LOD (Level of Detail):**
|
||||
수 킬로미터(3x3km 등)에 달하는 넓은 전장을 조감하는 전략적 시점부터, 개별 전차나 병사의 장비까지 식별 가능한 전술적 시점까지 단일 렌더링 파이프라인에서 끊김 없이 확대/축소(Zoom)가 가능합니다 [1, 5]. 카메라와의 거리에 따라 3D 모델의 정밀도를 동적으로 조절하는 가변적 LOD 시스템을 채택하여, 수백 개의 유닛이 존재하는 10 대 10 대규모 멀티플레이어 환경에서도 프레임 저하 없는 안정적인 최적화 성능을 보여줍니다 [1, 5, 6].
|
||||
* **데이터 연동 기반의 동적 파괴 시스템:**
|
||||
전투 중 발생하는 물리적 파괴 효과는 유닛의 상태 데이터 및 물리 법칙과 정밀하게 동기화됩니다 [2]. 유닛이 파괴될 때 장갑이나 장비 조각이 떨어져 나가며, 탄약고 유폭 시 포탑이 사출되거나 피격된 헬리콥터의 로터 블레이드 및 터빈, 비행기의 날개가 비산하는 등 사실적인 시각적 파괴 묘사가 이루어집니다 [2, 7].
|
||||
* **영속적 전장(Persistent Battlefield)의 구현:**
|
||||
파괴된 장비의 잔해, 발생한 연기, 그리고 포탄 충격으로 형성된 크레이터 등은 전투가 진행되는 동안 사라지지 않고 전장에 지속적으로 남아 사실적인 전장 분위기를 유지합니다 [2, 7]. 또한, 실제 등고선을 반영한 고정밀 지형 매핑 데이터는 물리적 충돌 판정과 직결되어, 시선(LOS)과 사격각이 물리적으로 정확하게 시뮬레이션되는 기반을 제공합니다 [2].
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 Iriszoom 엔진의 물리 기반 렌더링 측면 — depth-of-field, lens distortion 의 가시화 pipeline.
|
||||
- 매 PBR + iris-aperture simulation 의 합성.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[데이터 기반 설계(Data-Driven Design)]], [[물리 기반 렌더링(PBR)]], [[가변적 LOD(Level of Detail)]], [[영속적 전장(Persistent Battlefield)]]
|
||||
- **Projects/Contexts:** [[Eugen Systems의 WARNO 시뮬레이션 개발]], [[Iriszoom 엔진 업그레이드 프로젝트]]
|
||||
- **Contradictions/Notes:** 소스 전반에서 엔진의 뛰어난 가시화 성능 및 최적화를 일관되게 긍정적으로 평가하고 있으며, 복잡한 파괴 효과와 대규모 렌더링을 동시에 수행하면서도 시스템 성능을 유지하는 점이 엔진의 가장 큰 기술적 성취로 언급됩니다 [4, 8, 9].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Iriszoom Engine]] (canonical)
|
||||
- Adjacent: [[Physically Based Rendering]] · [[Depth of Field]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,73 +1,33 @@
|
||||
---
|
||||
id: wiki-2026-0508-machinations-io의-몬테카를로-시뮬레이션-및-데
|
||||
title: Machinations.io의 몬테카를로 시뮬레이션 및 데이터 예측
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: machinations
|
||||
duplicate_of: "[[Machinations]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, machinations, monte-carlo, game-balance]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Machinations]].io의 몬테카를로 시뮬레이션 및 데이터 예측
|
||||
# Machinations.io의 몬테카를로 시뮬레이션 및 데이터 예측
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Machinations.io의 몬테카를로 시뮬레이션은 불확실성을 지닌 게임 내 요소들에 무작위성(Randomness)을 부여하여 수만 번의 가상 플레이어 여정을 실행하고 예측하는 강력한 수학적 모델링 기법입니다[1, 2]. 이 기능은 대수의 법칙을 적용하여 단편적인 산술 평균이 아닌 현실 플레이어 기반에 가까운 정확한 결과 스펙트럼을 제공합니다[3, 4]. 이를 통해 기획자는 게임 출시 전후에 코딩 없이도 재화의 과부족 시점, 리텐션, 이탈률 등을 예측하며 게임 경제의 밸런스와 수익화 전략을 최적화할 수 있습니다[2, 5, 6].
|
||||
> **이 문서는 [[Machinations]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **전통적 시뮬레이션의 한계와 몬테카를로 기법의 도입**
|
||||
복잡한 시스템이 얽혀있는 게임 경제를 전통적인 엑셀이나 스프레드시트로 예측하는 데에는 한계가 존재합니다. 이는 기존 방식이 정적이고 단순한 산술 평균에만 의존하여, 플레이어의 개인적 선호나 편향 등 실제 게임에서 발생하는 '무작위성'과 '창발성([[Emergence]])'을 반영하지 못하기 때문입니다[2, 7, 8]. 마키네이션(Machinations)은 몬테카를로 시뮬레이션과 대수의 법칙(Law of Large Numbers)을 결합해 이 문제를 해결합니다[3, 7]. 기획자는 불확실성을 띤 변수를 입력하여 무작위성이 반영된 10,000회 이상의 사용자 여정을 시뮬레이션할 수 있으며, 이를 통해 단순한 성공/실패 여부가 아닌 실패 시점과 과정이 포함된 전체 결과 스펙트럼을 확인할 수 있습니다[9, 10].
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 Machinations.io 의 Monte Carlo run feature — 1000+ trial 의 distribution 분석.
|
||||
- 매 economy balance prediction — gold sink/source 의 long-tail 검증.
|
||||
|
||||
* **게임 경제 밸런싱 및 플레이어 경험 예측**
|
||||
몬테카를로 시뮬레이션은 플레이어의 행동과 그로 인한 경제적 파급 효과를 수개월 또는 수년에 걸쳐 예측할 수 있게 해줍니다[5, 6]. 시뮬레이션을 통해 개발진은 특정 게임 진행 구간에서 재화가 지나치게 부족해지거나 반대로 너무 풍부해지는 시점을 정확하게 포착할 수 있습니다[2]. 더 나아가 AI 기반의 보상 스케일링 하에서도 포인트 대 가치(points-to-value) 비율이 안정적으로 유지되는지 확인하거나, 플레이어의 리텐션, 이탈률, 인센티브 예산의 소진율(burn rate)을 스트레스 테스트하는 데 필수적으로 사용됩니다[9].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Machinations]] (canonical)
|
||||
- Adjacent: [[Monte Carlo Simulation]] · [[Data-Driven Balancing]]
|
||||
|
||||
* **라이브옵스([[LiveOps]]) 데이터 통합을 통한 디지털 트윈 구축**
|
||||
출시 전에는 가정에 의존하여 시뮬레이션을 진행하지만, 마키네이션은 게임 출시 후 발생하는 텔레메트리 데이터(예: JSON 기반 데이터)를 인제스션(Data Ingestion)하여 시뮬레이션 모델에 지속적으로 반영할 수 있습니다[2, 11]. 이렇게 현실의 데이터를 시뮬레이션으로 피드백하면 가정이 '예측'으로 바뀌면서 모델이 서서히 보정됩니다[11]. 궁극적으로 모델은 현실과 모델 사이의 간극을 좁히는 '디지털 트윈'으로 기능하며, 향후 플레이어 행동과 경제 흐름을 내다보는 예측 도구로 진화하게 됩니다[2, 11].
|
||||
|
||||
* **AI '밸런서(Balancer)'를 활용한 파라미터 최적화**
|
||||
마키네이션은 시뮬레이션 결과를 기반으로 시스템의 파라미터를 자동으로 최적화하는 AI 도구인 '밸런서(Balancer)'를 제공합니다[2, 12]. 기획자가 "첫 10분 동안 플레이어가 최대 3번만 죽도록 설정하라"라는 특정 목표를 부여하면, AI 시스템이 그에 맞춰 수많은 시뮬레이션 예측을 반복 수행하며 파라미터를 스스로 미세 조정합니다[2, 12]. 이를 통해 수익 극대화(LTV 최적화)나 플레이어 참여도 향상과 같은 구체적인 목표에 부합하는 경제 밸런스를 자동으로 달성할 수 있습니다[13].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[대수의 법칙(Law of Large Numbers)]], [[라이브옵스(LiveOps)]], [[유닛 이코노믹스(Unit Economics)]], [[디지털 트윈([[Digital Twin]])]]
|
||||
- **Projects/Contexts:** [[무료 플레이(Free-to-Play) 경제 설계]], [[Web3 토크노믹스(Kaiju Kings 사례)]]
|
||||
- **Contradictions/Notes:** 소스 데이터에 따르면 기존 게임 기획자 중 0.1% 미만만이 Python이나 VBA 같은 고급 스크립트를 다루며, 대다수는 엑셀의 정적 모델링에 의존해왔습니다[8]. 마키네이션의 몬테카를로 시뮬레이션은 이러한 기술적 장벽을 허물어 기획자가 코딩 없이 데이터 사이언스와 통계 분석을 직접 수행할 수 있도록 설계되었다고 강조합니다[14].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,57 +2,177 @@
|
||||
id: wiki-2026-0508-markov-random-fields
|
||||
title: Markov Random Fields
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-B14FE1]
|
||||
aliases: [MRF, Undirected Graphical Model, Markov Network, Gibbs Random Field]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
verification_status: applied
|
||||
tags: [machine-learning, probability, graphical-model, vision, statistics]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Markov-Random-Fields"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: Python
|
||||
framework: PyTorch/NetworkX
|
||||
---
|
||||
|
||||
# [[Markov-Random-Fields]]
|
||||
# Markov Random Fields
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
## 매 한 줄
|
||||
> **"매 undirected graph 의 joint distribution — local Markov property 의 satisfy"**. 매 Bayes net 의 directed counterpart — 매 conditional independence 의 graph separation 으로 read. Hammersley–Clifford (1971) 의 Gibbs distribution 의 equivalence — 2026 매 image segmentation, CRF, energy-based model (EBM) 의 underlie.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
### 매 정의
|
||||
- **Graph** $G = (V, E)$, 매 node 의 random variable $X_v$.
|
||||
- **Local Markov**: $X_v \perp X_{V \setminus N[v]} \mid X_{N(v)}$ — 매 node 의 neighbors 의 condition 시 의 rest 의 independent.
|
||||
- **Hammersley–Clifford**: 매 strictly positive joint 의 매 Gibbs form $P(x) = \frac{1}{Z} \prod_{C \in \mathcal{C}} \psi_C(x_C)$ — 매 clique 의 product.
|
||||
- **Partition function**: $Z = \sum_x \prod_C \psi_C(x_C)$ — 매 intractable in general.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/Markov-Random-Fields.md]]
|
||||
---
|
||||
### 매 inference
|
||||
- **Exact**: tree (sum-product / belief propagation).
|
||||
- **Loopy BP**: 매 approximate, 매 often works.
|
||||
- **MCMC**: Gibbs sampling — 매 conditional 의 sample 매 cycle.
|
||||
- **Variational**: mean-field — 매 factorized $q(x) = \prod_v q_v(x_v)$.
|
||||
- **Graph cut**: 매 binary submodular — 매 exact min-cut.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Image segmentation (foreground/background MRF).
|
||||
2. Conditional Random Fields (CRF) — sequence labeling.
|
||||
3. Stereo / depth estimation (smoothness prior).
|
||||
4. Energy-based generative models (EBMs).
|
||||
5. Statistical physics (Ising, Potts).
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Ising model — Gibbs sampling
|
||||
```python
|
||||
import numpy as np
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
def ising_gibbs(N=64, beta=0.44, steps=10_000, h=0.0):
|
||||
spins = np.random.choice([-1, 1], size=(N, N))
|
||||
for _ in range(steps):
|
||||
i, j = np.random.randint(N, size=2)
|
||||
nb = (spins[(i+1)%N, j] + spins[(i-1)%N, j]
|
||||
+ spins[i, (j+1)%N] + spins[i, (j-1)%N])
|
||||
dE = 2 * spins[i, j] * (beta * nb + h)
|
||||
if dE < 0 or np.random.random() < np.exp(-dE):
|
||||
spins[i, j] *= -1
|
||||
return spins
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Loopy belief propagation (binary pairwise)
|
||||
```python
|
||||
def loopy_bp(unary, pairwise, edges, iters=20):
|
||||
# unary[v] : log-potential per node, shape (V, K)
|
||||
# pairwise : (E, K, K) log-potentials
|
||||
# edges : list of (u, v)
|
||||
msg = {(u, v): np.zeros(unary.shape[1]) for u, v in edges}
|
||||
msg.update({(v, u): np.zeros(unary.shape[1]) for u, v in edges})
|
||||
for _ in range(iters):
|
||||
new = {}
|
||||
for (u, v), e_idx in zip(edges, range(len(edges))):
|
||||
incoming = unary[u] + sum(msg[(w, u)] for w in neighbors(u) if w != v)
|
||||
new[(u, v)] = np.logaddexp.reduce(
|
||||
pairwise[e_idx] + incoming[:, None], axis=0)
|
||||
new[(u, v)] -= new[(u, v)].max() # normalize
|
||||
msg.update(new)
|
||||
beliefs = np.array([
|
||||
unary[v] + sum(msg[(u, v)] for u in neighbors(v))
|
||||
for v in range(len(unary))])
|
||||
return beliefs
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Linear-chain CRF (PyTorch — sequence labeling)
|
||||
```python
|
||||
import torch, torch.nn as nn
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
class LinearChainCRF(nn.Module):
|
||||
def __init__(self, n_tags):
|
||||
super().__init__()
|
||||
self.trans = nn.Parameter(torch.randn(n_tags, n_tags))
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
def log_partition(self, emissions): # (T, K)
|
||||
T, K = emissions.shape
|
||||
alpha = emissions[0]
|
||||
for t in range(1, T):
|
||||
alpha = torch.logsumexp(
|
||||
alpha[:, None] + self.trans + emissions[t][None, :], dim=0)
|
||||
return torch.logsumexp(alpha, dim=0)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
def score(self, emissions, tags):
|
||||
s = emissions[0, tags[0]]
|
||||
for t in range(1, len(tags)):
|
||||
s = s + self.trans[tags[t-1], tags[t]] + emissions[t, tags[t]]
|
||||
return s
|
||||
|
||||
def nll(self, emissions, tags):
|
||||
return self.log_partition(emissions) - self.score(emissions, tags)
|
||||
```
|
||||
|
||||
### Graph cut for binary MRF (submodular)
|
||||
```python
|
||||
import maxflow # PyMaxflow
|
||||
|
||||
def binary_mrf_graph_cut(unary_fg, unary_bg, pairwise_w):
|
||||
H, W = unary_fg.shape
|
||||
g = maxflow.Graph[float]()
|
||||
nodes = g.add_grid_nodes((H, W))
|
||||
g.add_grid_edges(nodes, pairwise_w) # smoothness
|
||||
g.add_grid_tedges(nodes, unary_fg, unary_bg) # data term
|
||||
g.maxflow()
|
||||
return g.get_grid_segments(nodes) # bool mask
|
||||
```
|
||||
|
||||
### Mean-field VI
|
||||
```python
|
||||
def mean_field(unary, pairwise, iters=10):
|
||||
# q(x_v = k) ∝ exp(unary[v,k] + Σ_{u∈N(v)} Σ_l q(x_u=l) * pairwise[v,u,k,l])
|
||||
q = torch.softmax(unary, dim=-1)
|
||||
for _ in range(iters):
|
||||
msg = torch.einsum('uvkl,ul->vk', pairwise, q)
|
||||
q = torch.softmax(unary + msg, dim=-1)
|
||||
return q
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Tree-structured | Sum-product (exact) |
|
||||
| Loopy graph, fast | Loopy BP |
|
||||
| Loopy graph, accurate | MCMC (Gibbs) — slower |
|
||||
| Binary submodular | Graph cut (exact min-cut) |
|
||||
| Sequence labeling (NER) | Linear-chain CRF |
|
||||
| Image segmentation | Pairwise MRF + α-expansion / DenseCRF |
|
||||
| Modern generative | Energy-Based Model (EBM) — score matching |
|
||||
|
||||
**기본값**: smallest model 의 first — chain → tree → loopy + BP → MCMC.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Probabilistic Graphical Models]] · [[Probability Theory]]
|
||||
- 변형: [[Conditional Random Fields]] · [[Ising Model]] · [[Boltzmann Machine]]
|
||||
- 응용: [[Image Segmentation]] · [[Sequence Labeling]] · [[Energy-Based Model]]
|
||||
- Adjacent: [[Bayesian Network]] · [[Belief Propagation]] · [[Hammersley-Clifford]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: clique factorization 의 derive, BP/Gibbs pseudocode, partition-function intractability 의 explain.
|
||||
**언제 X**: 매 specific paper algorithm — original 의 의 cross-check.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Bayes net 의 mental model 의 reuse**: 매 directionality 의 X — separation criterion 매 different.
|
||||
- **Computing $Z$ for large graph**: 매 #P-hard — variational / MCMC.
|
||||
- **Loopy BP on tightly-loopy graph**: 매 may diverge — damping 의 try, MCMC 의 fallback.
|
||||
- **Linear-chain CRF 의 LSTM 으로 always replace**: 매 small data 의 still wins, 매 calibration 의 better.
|
||||
- **Mean-field 의 multimodal posterior 의 use**: 매 mode-seeking — 매 underestimate variance.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Hammersley & Clifford 1971; Koller & Friedman _PGM_ 2009; Murphy _PML_ 2022).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — MRF basics + BP/CRF/graph-cut 정리 |
|
||||
|
||||
@@ -1,58 +1,180 @@
|
||||
---
|
||||
id: wiki-2026-0508-model-free-rl-vs-model-based-rl
|
||||
title: Model Free RL vs Model Based RL
|
||||
title: Model-Free RL vs Model-Based RL
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-B8C5BC]
|
||||
aliases: [MFRL vs MBRL, Model-Based Reinforcement Learning, World Model]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
verification_status: applied
|
||||
tags: [reinforcement-learning, machine-learning, planning, world-model]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Model-Free RL vs Model-Based RL"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: Python
|
||||
framework: PyTorch/JAX
|
||||
---
|
||||
|
||||
# [[Model-Free RL vs Model-Based RL]]
|
||||
# Model-Free RL vs Model-Based RL
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
## 매 한 줄
|
||||
> **"매 environment dynamics 의 learn 하나, 의 X 하나 — sample efficiency 의 vs simplicity 의 trade"**. Model-free (Q-learning, PPO) 매 reward signal 의 만으로 policy 의 update — simple 의 brittle. Model-based (Dreamer, MuZero) 매 world model 의 learn → 매 imagined rollout 의 train. 2026 의 Dreamer V3, EfficientZero, DayDreamer 의 robotics deployment — sample efficiency 의 1-2 orders.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
### 매 dichotomy
|
||||
- **Model-free**: $\pi(a|s)$ 또는 $Q(s,a)$ 의 직접 learn. 매 transition $p(s'|s,a)$ 의 access 의 X.
|
||||
- **Model-based**: $\hat{p}(s'|s,a)$, $\hat{r}(s,a)$ 의 learn → 매 plan / imagined rollout / Dyna-style.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/Model-Free RL vs Model-Based RL.md]]
|
||||
---
|
||||
### 매 trade-off table
|
||||
| Axis | Model-Free | Model-Based |
|
||||
|---|---|---|
|
||||
| Sample efficiency | Low | **High** (10-100×) |
|
||||
| Compute per update | Low | **High** |
|
||||
| Asymptotic perf | **Often higher** | Bounded by model error |
|
||||
| Stability | **Stable** | Compounding model error |
|
||||
| Transfer | Poor | **Better** (model 의 reuse) |
|
||||
| Implementation | **Simple** | Complex |
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 modern flavors
|
||||
- **Model-free**: PPO, SAC, DQN family, TD3.
|
||||
- **Model-based**: Dreamer V3 (RSSM), MuZero (planning + value tree), TD-MPC2, PILCO (Gaussian process).
|
||||
- **Hybrid**: MBPO (model-generated rollouts → SAC), Dyna-Q.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### 매 응용
|
||||
1. Robotics (sample-efficient sim-to-real).
|
||||
2. Atari/board game (MuZero).
|
||||
3. Drug design (sample-efficient exploration).
|
||||
4. Game NPC behavior (PPO 의 still default).
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### PPO — model-free policy gradient (gymnasium)
|
||||
```python
|
||||
import torch, torch.nn as nn, torch.nn.functional as F
|
||||
from torch.distributions import Categorical
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
class ActorCritic(nn.Module):
|
||||
def __init__(self, obs_dim, n_act):
|
||||
super().__init__()
|
||||
self.shared = nn.Sequential(nn.Linear(obs_dim, 64), nn.Tanh(),
|
||||
nn.Linear(64, 64), nn.Tanh())
|
||||
self.pi = nn.Linear(64, n_act)
|
||||
self.v = nn.Linear(64, 1)
|
||||
def forward(self, x):
|
||||
h = self.shared(x)
|
||||
return Categorical(logits=self.pi(h)), self.v(h).squeeze(-1)
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
def ppo_step(ac, opt, batch, clip=0.2, vf_c=0.5, ent_c=0.01):
|
||||
dist, v = ac(batch.obs)
|
||||
logp = dist.log_prob(batch.act)
|
||||
ratio = torch.exp(logp - batch.logp_old)
|
||||
surr1 = ratio * batch.adv
|
||||
surr2 = torch.clamp(ratio, 1-clip, 1+clip) * batch.adv
|
||||
pi_loss = -torch.min(surr1, surr2).mean()
|
||||
v_loss = F.mse_loss(v, batch.ret)
|
||||
ent = dist.entropy().mean()
|
||||
loss = pi_loss + vf_c * v_loss - ent_c * ent
|
||||
opt.zero_grad(); loss.backward(); opt.step()
|
||||
return loss.item()
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Dreamer-style world model (RSSM skeleton)
|
||||
```python
|
||||
class RSSM(nn.Module):
|
||||
def __init__(self, obs_dim, act_dim, h=200, z=32):
|
||||
super().__init__()
|
||||
self.gru = nn.GRUCell(z + act_dim, h)
|
||||
self.prior = nn.Linear(h, 2 * z) # μ, σ
|
||||
self.post = nn.Linear(h + obs_dim, 2 * z)
|
||||
self.dec_obs = nn.Linear(h + z, obs_dim)
|
||||
self.dec_rew = nn.Linear(h + z, 1)
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
def step(self, h, z, a, obs=None):
|
||||
h = self.gru(torch.cat([z, a], -1), h)
|
||||
pri_mu, pri_log = self.prior(h).chunk(2, -1)
|
||||
if obs is not None:
|
||||
po_mu, po_log = self.post(torch.cat([h, obs], -1)).chunk(2, -1)
|
||||
z = po_mu + torch.exp(po_log) * torch.randn_like(po_mu)
|
||||
else:
|
||||
z = pri_mu + torch.exp(pri_log) * torch.randn_like(pri_mu)
|
||||
return h, z, (pri_mu, pri_log)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
def imagine(self, h, z, policy, T=15):
|
||||
states = []
|
||||
for _ in range(T):
|
||||
a = policy(torch.cat([h, z], -1))
|
||||
h, z, _ = self.step(h, z, a)
|
||||
states.append((h, z))
|
||||
return states
|
||||
```
|
||||
|
||||
### Dyna-Q (hybrid — tabular)
|
||||
```python
|
||||
def dyna_q(env, n_planning=10, episodes=500, alpha=0.1, gamma=0.99, eps=0.1):
|
||||
Q = defaultdict(lambda: np.zeros(env.action_space.n))
|
||||
model = {} # (s,a) → (r, s')
|
||||
for _ in range(episodes):
|
||||
s, _ = env.reset()
|
||||
done = False
|
||||
while not done:
|
||||
a = np.random.randint(env.action_space.n) if np.random.random() < eps \
|
||||
else int(np.argmax(Q[s]))
|
||||
s2, r, done, *_ = env.step(a)
|
||||
Q[s][a] += alpha * (r + gamma * Q[s2].max() - Q[s][a])
|
||||
model[(s, a)] = (r, s2)
|
||||
for _ in range(n_planning): # 매 imagined step
|
||||
(sp, ap), (rp, sp2) = random.choice(list(model.items())), None
|
||||
rp, sp2 = model[(sp, ap)]
|
||||
Q[sp][ap] += alpha * (rp + gamma * Q[sp2].max() - Q[sp][ap])
|
||||
s = s2
|
||||
```
|
||||
|
||||
### MuZero (planning sketch — value/policy net + MCTS)
|
||||
```python
|
||||
# 매 environment 의 black-box; learned (representation, dynamics, prediction) heads
|
||||
# search 매 imagined trajectory 의 over MCTS — replay 매 (search policy, search value, n-step return)
|
||||
# 의 train. (full impl 매 muzero_general repo)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Lots of cheap simulation | **Model-free** (PPO/SAC) — simpler |
|
||||
| Real-robot, expensive samples | **Model-based** (Dreamer V3, TD-MPC2) |
|
||||
| Discrete board game | **MuZero** — planning 의 wins |
|
||||
| Continuous control benchmark | SAC or DreamerV3 |
|
||||
| Fast prototype | PPO — most stable, easiest to tune |
|
||||
| Long-horizon planning | Model-based + planning |
|
||||
|
||||
**기본값**: prototype 매 PPO. Sample 매 expensive — Dreamer V3 / TD-MPC2.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Reinforcement Learning]] · [[Markov Decision Process]]
|
||||
- 변형: [[PPO]] · [[SAC]] · [[Dreamer V3]] · [[MuZero]] · [[TD-MPC2]]
|
||||
- 응용: [[Sim-to-Real]] · [[Robotics RL]] · [[AlphaZero]]
|
||||
- Adjacent: [[World Model]] · [[Planning]] · [[Dyna-Q]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: trade-off explanation, algorithm choice, pseudocode skeleton.
|
||||
**언제 X**: 매 hyperparameter — paper-specific 의 cross-check (Dreamer V3 매 sensitivity 의 paper 의 careful).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **MBRL 의 default 의 reach**: 매 cheap-sim 환경 의 PPO 의 win 매 simpler.
|
||||
- **Imagined rollout 의 too-long horizon**: 매 model error compounds — 5-15 step 의 typical.
|
||||
- **MFRL 의 sparse reward 의 hope**: 매 exploration 의 add (RND, ICM) — 또는 의 model-based 의 switch.
|
||||
- **MuZero 의 small problem 의 use**: 매 overkill — tabular Q 의 enough.
|
||||
- **Single-seed report**: 매 RL variance huge — 5+ seeds 의 IQM (Agarwal et al. 2021).
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Sutton & Barto 2nd ed. 2018; Hafner _DreamerV3_ 2023; Schrittwieser _MuZero_ Nature 2020).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — MFRL/MBRL trade-off + DreamerV3/MuZero 정리 |
|
||||
|
||||
@@ -2,57 +2,139 @@
|
||||
id: wiki-2026-0508-mycological-horror
|
||||
title: Mycological Horror
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-1D7BB8]
|
||||
aliases: [Fungal Horror, Mushroom Horror, Cordyceps Horror]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
verification_status: applied
|
||||
tags: [horror, genre, biology, fiction, body-horror]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Mycological Horror"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: N/A
|
||||
framework: literary-genre
|
||||
---
|
||||
|
||||
# [[Mycological Horror]]
|
||||
# Mycological Horror
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
## 매 한 줄
|
||||
> **"매 fungus 의 host 의 takeover — body autonomy 의 loss"**. 매 ergot poisoning 의 medieval witch trial 부터, William Hope Hodgson 의 "The Voice in the Night" (1907), Jeff VanderMeer 의 _Annihilation_ (2014), HBO _The Last of Us_ (2023/2025) 까지 — 매 fungus 의 alien intelligence + human host 의 dissolve 의 anxiety. 2026 climate-fiction 안에서 매 still rising subgenre.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
### 매 horror axes
|
||||
- **Body horror**: 매 visible mycelium 의 bursting — Cronenbergian rupture.
|
||||
- **Loss of selfhood**: 매 host 의 mind 의 still 있나? — zombie/possession 의 fungal flavor.
|
||||
- **Ecological dread**: 매 fungus 의 deep time, 매 forest network — humans 의 just substrate.
|
||||
- **Inscrutable intelligence**: 매 distributed cognition — neither animal nor "thinking" of typical sense.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/Mycological Horror.md]]
|
||||
---
|
||||
### 매 biological substrate
|
||||
- **_Ophiocordyceps unilateralis_**: 매 ant 의 brain 의 hijack — 매 height 의 climb 후 spore release. 매 Last of Us 의 inspiration.
|
||||
- **Ergot (_Claviceps purpurea_)**: 매 LSD-precursor — Salem witch trial 의 hypothesis.
|
||||
- **_Massospora_** on cicadas: 매 hypersexual zombie cicada.
|
||||
- **Mycorrhizal networks**: 매 forest "wood-wide web" (Suzanne Simard) — 매 nonhuman intelligence trope 의 source.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Game design (The Last of Us, Returnal biome).
|
||||
2. Cosmic-horror / weird-fiction adjacency.
|
||||
3. Climate-fiction (mass extinction + fungal succession).
|
||||
4. Folk-horror revival (witch & ergot tradition).
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Trope catalog (writer's reference)
|
||||
```yaml
|
||||
core_tropes:
|
||||
- infection_to_transformation:
|
||||
stages: [exposure, asymptomatic, behavioral_change, sporulation, death]
|
||||
pacing: slow_creep # 매 not jump-scare
|
||||
- hivemind_vs_individual:
|
||||
tension: "is the host still in there?"
|
||||
- spore_cloud:
|
||||
sensory: "sweet rot, gold dust, cathedral silence"
|
||||
- fruiting_body:
|
||||
visual: "antlers, coral, cathedral arches from skin"
|
||||
- mycorrhizal_network:
|
||||
scale: "forest-wide consciousness"
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Game-design beat (procgen biome)
|
||||
```python
|
||||
# 매 fungal biome 의 generative beat — escalation curve
|
||||
def fungal_zone(progress: float) -> dict:
|
||||
return {
|
||||
"spore_density": progress ** 1.4, # 매 quadratic creep
|
||||
"mass_size_m": 0.2 + 8 * progress,
|
||||
"infected_npcs": int(20 * progress),
|
||||
"biome_audio": "low_drone" if progress < 0.5 else "wet_chittering",
|
||||
"visibility_m": max(2, 30 - 28 * progress),
|
||||
}
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Slow-reveal scene template (prose)
|
||||
```
|
||||
Beat 1 (page 1) : odd smell, "sweet rot" # sensory only
|
||||
Beat 2 (page 3) : gold dust on the windowsill # mundane anomaly
|
||||
Beat 3 (page 7) : neighbor's strange stillness # social uncanny
|
||||
Beat 4 (page 12) : mycelium under the wallpaper # body discovery
|
||||
Beat 5 (climax) : the host speaks in chorus # selfhood collapse
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Sound-design palette (game/film)
|
||||
```
|
||||
- low sub drone (40-60 Hz) # 매 dread bed
|
||||
- wet chittering / squelch # 매 body-rupture cues
|
||||
- choral vowel pads # 매 hivemind voice
|
||||
- silence in canopy # 매 ecology-wrong cue
|
||||
- distant tonal "pop" # 매 spore release
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Reference shelf
|
||||
```markdown
|
||||
- William Hope Hodgson, "The Voice in the Night" (1907)
|
||||
- Jeff VanderMeer, _Annihilation_ (2014) and the Southern Reach
|
||||
- M. R. Carey, _The Girl With All the Gifts_ (2014)
|
||||
- _The Last of Us_ (2013/2020 game; HBO 2023/2025)
|
||||
- Mira Grant, _Parasite_ (adjacent — protozoan, not fungal)
|
||||
- Kingsnorth, _The Wake_ (folk-horror adjacent)
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Body horror beat | Slow reveal (5 beats) — visible mycelium late |
|
||||
| Cosmic horror tone | Mycorrhizal network 의 emphasize — scale 의 dread |
|
||||
| Action game | Cordyceps-style infected — clear stage progression |
|
||||
| Folk horror | Ergot + village — historical anchor |
|
||||
| Climate fiction | Succession after collapse — fungus 의 inheritor |
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
**기본값**: slow-creep + sensory anomaly 의 lead, body horror 의 climax 의 reserve.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Horror Genre]] · [[Body Horror]] · [[Weird Fiction]]
|
||||
- 변형: [[Cosmic Horror]] · [[Folk Horror]] · [[Eco-Horror]]
|
||||
- 응용: [[The Last of Us]] · [[Annihilation]]
|
||||
- Adjacent: [[Cordyceps]] · [[Mycorrhizal Network]] · [[Wood-Wide Web]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: trope catalog, beat structure, sound palette, reference suggestion.
|
||||
**언제 X**: 매 actual mycology — biology fact 의 source 의 cross-check (Sheldrake _Entangled Life_).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Zombie reskin**: 매 just "fungal zombie" — fungus 의 unique anxiety (network, slow time, ecology) 의 lose.
|
||||
- **Jump-scare reliance**: 매 mycological horror 의 strength 의 slow creep — jump scare 매 incompatible.
|
||||
- **Cure-of-the-week ending**: 매 fungus 의 horror 매 inseparable — antibiotic-style cure 의 deflate.
|
||||
- **Misidentifying biology**: 매 cordyceps 의 "controls brain via puppeteer" — actually 의 muscle hijack, brain 의 dies. 매 detail 매 matter 의 weird-fiction 의 reader.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (VanderMeer _Annihilation_ 2014; Hughes et al. on _Ophiocordyceps_ 2011 _BMC Ecology_; Sheldrake _Entangled Life_ 2020).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — tropes + biology + design beat 정리 |
|
||||
|
||||
@@ -2,57 +2,32 @@
|
||||
id: wiki-2026-0508-offscreencanvas-멀티스레딩
|
||||
title: OffscreenCanvas (멀티스레딩)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-811DEC]
|
||||
duplicate_of: none
|
||||
status: duplicate
|
||||
canonical_id: offscreencanvas
|
||||
duplicate_of: "[[OffscreenCanvas]]"
|
||||
aliases: []
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - OffscreenCanvas (멀티스레딩)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
verification_status: redirected
|
||||
tags: [duplicate, web, canvas, worker]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# [[OffscreenCanvas (멀티스레딩)]]
|
||||
# OffscreenCanvas (멀티스레딩)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
> **이 문서는 [[OffscreenCanvas]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 OffscreenCanvas 의 Worker thread 활용 — main thread block 회피.
|
||||
- 매 transferControlToOffscreen() pattern 의 GPU-bound rendering.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
## 🔗 Graph
|
||||
- 부모: [[OffscreenCanvas]] (canonical)
|
||||
- Adjacent: [[Web Workers]] · [[SharedArrayBuffer]]
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/OffscreenCanvas (멀티스레딩).md]]
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,58 +1,162 @@
|
||||
---
|
||||
id: wiki-2026-0508-readme
|
||||
title: README
|
||||
title: README — General Knowledge
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-698D8B]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
confidence_score: 0.95
|
||||
verification_status: applied
|
||||
tags: [readme, index, meta]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - README"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# [[README]]
|
||||
# README — General Knowledge
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
## 매 한 줄
|
||||
> **"매 cross-domain knowledge 의 hub"**. 매 General Knowledge folder 는 narrowly-scoped 도메인에 fit 하지 않은 wiki note 의 catch-all index — game design, web platform, ML theory, neuroscience 가 cross-pollinate 한다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
### 매 폴더 목적
|
||||
- 매 cross-domain note 의 home — 매 specific topic folder (AI_and_ML, Programming) 에 fit 하지 않은 entry.
|
||||
- 매 case study + concept primer 의 mix.
|
||||
- 매 canonical 문서 + redirect 문서 의 coexist.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/README.md]]
|
||||
---
|
||||
### 매 분류 체계
|
||||
- 매 status: `verified` (canonical), `duplicate` (redirect), `merged` (filename-level redirect), `needs_review` (pending cleanup).
|
||||
- 매 canonical_id: `self` (own canonical) or external canonical slug.
|
||||
- 매 frontmatter 의 일관된 schema — id, title, category, status, canonical_id, aliases, source_trust_level.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Game design knowledge base — Albion Online, Clash Royale, Diablo 2 의 case study.
|
||||
2. Web platform primer — OffscreenCanvas, SharedArrayBuffer 의 깊이 있는 reference.
|
||||
3. Cognitive science index — Dopamine Signaling, Mycological Horror 의 cross-cut topic.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### 패턴 1: Frontmatter linting
|
||||
```python
|
||||
import yaml
|
||||
import frontmatter
|
||||
from pathlib import Path
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
REQUIRED = {"id", "title", "category", "status", "canonical_id"}
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
def lint_folder(folder: Path):
|
||||
issues = []
|
||||
for md in folder.glob("*.md"):
|
||||
post = frontmatter.load(md)
|
||||
missing = REQUIRED - set(post.metadata.keys())
|
||||
if missing:
|
||||
issues.append((md.name, f"missing: {missing}"))
|
||||
return issues
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
for name, issue in lint_folder(Path("./General Knowledge")):
|
||||
print(f"{name}: {issue}")
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### 패턴 2: Duplicate detection (title similarity)
|
||||
```python
|
||||
from rapidfuzz import fuzz
|
||||
from pathlib import Path
|
||||
import frontmatter
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
def find_dupes(folder: Path, threshold=85):
|
||||
titles = []
|
||||
for md in folder.glob("*.md"):
|
||||
post = frontmatter.load(md)
|
||||
titles.append((md.name, post.metadata.get("title", "")))
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
pairs = []
|
||||
for i, (n1, t1) in enumerate(titles):
|
||||
for n2, t2 in titles[i+1:]:
|
||||
score = fuzz.ratio(t1, t2)
|
||||
if score >= threshold:
|
||||
pairs.append((n1, n2, score))
|
||||
return pairs
|
||||
```
|
||||
|
||||
### 패턴 3: Wikilink graph build
|
||||
```python
|
||||
import re
|
||||
import networkx as nx
|
||||
from pathlib import Path
|
||||
|
||||
LINK_RE = re.compile(r"\[\[([^\]]+)\]\]")
|
||||
|
||||
def build_graph(folder: Path) -> nx.DiGraph:
|
||||
g = nx.DiGraph()
|
||||
for md in folder.glob("*.md"):
|
||||
text = md.read_text()
|
||||
for target in LINK_RE.findall(text):
|
||||
g.add_edge(md.stem, target.split("|")[0])
|
||||
return g
|
||||
|
||||
g = build_graph(Path("./General Knowledge"))
|
||||
print(f"nodes={g.number_of_nodes()} edges={g.number_of_edges()}")
|
||||
print("orphans:", [n for n in g.nodes if g.in_degree(n) == 0])
|
||||
```
|
||||
|
||||
### 패턴 4: Redirect resolution
|
||||
```python
|
||||
def resolve(slug: str, index: dict[str, dict]) -> str:
|
||||
seen = set()
|
||||
cur = slug
|
||||
while cur in index and index[cur].get("status") in ("duplicate", "merged"):
|
||||
if cur in seen:
|
||||
raise ValueError(f"redirect cycle at {cur}")
|
||||
seen.add(cur)
|
||||
cur = index[cur].get("canonical_id") or index[cur].get("redirect_to")
|
||||
return cur
|
||||
```
|
||||
|
||||
### 패턴 5: Reinforcement scheduler
|
||||
```python
|
||||
from datetime import date, timedelta
|
||||
|
||||
def needs_reinforcement(meta: dict, today: date = date.today()) -> bool:
|
||||
last = date.fromisoformat(meta["last_reinforced"])
|
||||
score = float(meta.get("confidence_score", 0.9))
|
||||
interval = timedelta(days=30 if score >= 0.9 else 14)
|
||||
return today - last > interval
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 새 note 의 fit folder 가 명확 | specific folder 에 add (not General Knowledge) |
|
||||
| cross-domain note | General Knowledge |
|
||||
| Korean title duplicate | REDIRECT to English canonical |
|
||||
| stub / placeholder | redirect to README |
|
||||
|
||||
**기본값**: domain-specific folder 우선, fallback 만 General Knowledge.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Wiki Index]] · [[10_Wiki/Topics]]
|
||||
- 변형: [[AI_and_ML/README]] · [[Programming & Language/README]]
|
||||
- 응용: [[Game Design Index]] · [[Web Platform Index]]
|
||||
- Adjacent: [[Wiki Cleanup Spec]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: cross-domain question 의 routing, knowledge graph 구축, reinforcement scheduling.
|
||||
**언제 X**: 매 specific domain 의 deep query — domain folder 의 직접 lookup 우선.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Catch-all dumping**: 매 note 가 specific folder 의 candidate 인데 General Knowledge 에 dump — graph 의 fragmentation.
|
||||
- **Redirect chain**: 매 redirect → redirect → canonical 의 multi-hop. 매 single-hop 으로 flatten.
|
||||
- **Stale frontmatter**: 매 last_reinforced 의 90+일 미갱신 — reinforcement loop 의 break.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (folder ls + frontmatter lint).
|
||||
- 신뢰도 A (meta-doc, self-describing).
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — README 의 substantive content 화 |
|
||||
|
||||
@@ -1,66 +1,33 @@
|
||||
---
|
||||
id: wiki-2026-0508-resource-deposits-자원-매장지
|
||||
title: Resource Deposits(자원 매장지)
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: resource-management
|
||||
duplicate_of: "[[Resource Management]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, game-design, resources]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# Resource Deposits(자원 매장지)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
자원 매장지(Resource Deposits)는 월드 맵 상에 존재하는 소규모 기지 형태의 거점으로, 점령 시 금속([[Metal]]), 석유(Oil), 토륨([[Thorium]]) 등의 자원을 시간에 따라 제공합니다 [1, 2]. 플레이어는 매장지 내의 방어 건물을 모두 파괴하여 점령할 수 있으며, 점령 후에는 방어를 위해 자신의 소대를 배치할 수 있습니다 [1, 3]. 자원 매장지는 플레이어 기지보다 방어력이 낮아 중간 위험도의 자원 획득 수단으로 활용되지만, 타 플레이어나 클랜으로부터 지속적으로 방어해야 하는 전투 및 영토 분쟁의 핵심 목표지입니다 [2, 3].
|
||||
> **이 문서는 [[Resource Management]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **자원 매장지의 특징 및 점령 방식:** 자원 매장지는 월드 맵에 위치하며, 일반 플레이어의 기지보다는 규모가 작고 방어력이 상대적으로 낮습니다 [3]. 매장지를 점령하려면 중앙에 위치한 파괴 불가능한 생산 장치를 제외한 모든 방어 건물을 파괴해야 합니다 [3]. 점령한 매장지에는 새로운 건물을 건설하거나 기존 건물을 업그레이드할 수 없지만, 기지 편집기(Base Editor)를 통해 방어용 건물을 재배치할 수 있으며 방어 소대(Platoon)를 주둔시켜 통제권을 유지할 수 있습니다 [1, 4].
|
||||
* **자원 생산 및 관리 보너스:** 매장지를 통제하는 동안에는 규모에 비례하여 일정 시간마다 자원이 자동으로 지급되며, 매장지를 최초 점령할 때와 매장지 수명이 다하여 소진될 때 큰 일시불 자원 보상을 제공받습니다 [1, 3, 4]. 플레이어는 '18 Wheeler', 'Jumbo Jet' 등 특정 특수 작전(Special Ops)을 활성화하여 매장지의 자체 자원 고갈 속도는 늘리지 않으면서 추가적인 자원 생성 보너스를 크게 확보할 수 있습니다 [5, 6]. 또한 플레이어는 드롭다운 메뉴인 소대 북마크를 통해 자신이 소유한 모든 매장지의 위치와 고갈까지 남은 시간을 쉽게 파악하고 관리할 수 있습니다 [4, 7].
|
||||
* **유형별 특성 및 토륨 매장지의 변화:** 일반적인 금속 및 석유 매장지와 달리, 토륨 매장지(Thorium Deposits)는 한시적으로 맵에 생성되어 점령 여부와 무관하게 서서히 자원이 고갈되는 특수한 거점이었습니다 [8, 9]. 그러나 전술적 환경이 변화함에 따라 2016년 1월 업데이트를 기점으로 이 방식은 폐지되었고, 현재는 대량의 토륨을 즉시 약탈할 수 있는 강력한 영구적 NPC 기지인 'Verkraft Thorium Compounds'로 완전히 대체되었습니다 [9, 10].
|
||||
* **전술적 및 외교적 의미:** 자원 매장지는 타 플레이어의 공격에 상시 노출되어 있으므로 주둔군을 통한 방어 전투가 빈번하게 발생합니다 [1, 2]. 월드 맵의 특정 섹터([[Sector]])를 장악한 거대 동맹(클랜)이 자원 매장지 통제권을 좌우하기도 하며, 이 과정에서 동맹이 없는 플레이어는 매장지를 차지하거나 보호하는 데 큰 어려움을 겪을 수 있습니다 [11, 12]. 매장지를 공격할 때는 촘촘한 대공 방어망을 회피하기 위해 이동 속도가 빨라 치고 빠지기에 능한 팔라딘(Paladin) 전차를 주력으로 활용하는 등 세밀한 유닛 컨트롤과 부대 구성 전술이 요구됩니다 [13].
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 자원 매장지 — RTS/MMO 의 finite resource node 의 spatial distribution.
|
||||
- 매 contested-area dynamic — PvP 의 territorial gameplay loop.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Platoons(소대)]], [[World Map(월드 맵)]], [[Clans & [[Alliances]](클랜 및 동맹)]], [[Thorium(토륨)]], [[Special Ops(특수 작전)]]
|
||||
- **Projects/Contexts:** [[Resource [[Management]] and Logistics]], [[World Map Combat Ecosystem]]
|
||||
- **Contradictions/Notes:** 게임 초기 시스템에서 토륨 매장지는 한시적으로 맵에 유지되며 서서히 자원이 고갈되는 시스템(Temporary)이었으나, 시스템 업데이트를 거쳐 현재는 한 번에 대규모 자원 약탈이 가능한 영구적 NPC 기지 형태인 'Verkraft Thorium Compounds'로 시스템 자체가 변경 및 대체되었습니다 [8-10].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Resource Management]] (canonical)
|
||||
- Adjacent: [[Albion Online]] · [[RTS Design]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
+21
-88
@@ -2,99 +2,32 @@
|
||||
id: wiki-2026-0508-sharedarraybuffer-보안-이슈와-cross-o
|
||||
title: SharedArrayBuffer 보안 이슈와 Cross Origin Isolation 설정법
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-3E2EC5]
|
||||
duplicate_of: none
|
||||
status: duplicate
|
||||
canonical_id: sharedarraybuffer
|
||||
duplicate_of: "[[SharedArrayBuffer]]"
|
||||
aliases: []
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation 설정법"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
verification_status: redirected
|
||||
tags: [duplicate, web, security, spectre]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# [[SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation 설정법]]
|
||||
# SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation 설정법
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> `SharedArrayBuffer`는 멀티스레드 간 복사 비용 0으로 데이터를 공유할 수 있는 강력한 기능이지만, 타이밍 공격(Spectre 등)을 유발할 수 있는 보안 취약점이 존재하여 이를 안전하게 사용하려면 웹 서버에 **COOP 및 COEP HTTP 보안 헤더를 통한 Cross-Origin Isolation(교차 출처 격리)** 설정이 반드시 필요합니다.
|
||||
> **이 문서는 [[SharedArrayBuffer]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**1. 보안 이슈의 배경: 스펙터(Spectre) 취약점** `SharedArrayBuffer`를 고해상도 타이머와 결합하면 CPU의 예측 실행(Speculative Execution) 과정에서 발생하는 미세한 시간 차이를 측정할 수 있습니다. 해커들은 이를 악용하여 같은 브라우저 프로세스 내에 로드된 다른 사이트의 메모리 데이터(비밀번호, 세션 등)를 훔쳐보는 **부채널 공격(스펙터 취약점)**이 가능함을 발견했습니다. 이로 인해 브라우저 벤더들은 기본적으로 이 API의 사용을 전면 차단했습니다.
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 Spectre mitigation 의 COOP/COEP 헤더 요구사항.
|
||||
- 매 `Cross-Origin-Opener-Policy: same-origin` + `Cross-Origin-Embedder-Policy: require-corp` 설정.
|
||||
|
||||
**2. Cross-Origin Isolation (교차 출처 격리)의 도입** 멀티스레딩의 뛰어난 성능적 이점을 포기할 수 없었기에, 브라우저는 현재 웹 페이지를 외부의 신뢰할 수 없는 리소스로부터 완전히 샌드박싱하여 격리하는 **'Cross-Origin Isolated'** 상태에서만 `SharedArrayBuffer`를 예외적으로 생성할 수 있도록 보안 정책을 변경했습니다.
|
||||
## 🔗 Graph
|
||||
- 부모: [[SharedArrayBuffer]] (canonical)
|
||||
- Adjacent: [[Web Workers]] · [[OffscreenCanvas]] · [[Spectre Vulnerability]]
|
||||
|
||||
**3. 필수 HTTP 보안 헤더 설정법 (COOP / COEP)** 이 강력한 격리 환경을 활성화하려면, 웹 애플리케이션을 호스팅하는 서버(Nginx, Node.js, Vercel 등)가 HTML 문서를 응답할 때 반드시 다음 **두 가지 HTTP 헤더를 포함**하도록 설정해야 합니다.
|
||||
|
||||
- **`Cross-Origin-Opener-Policy: same-origin` (COOP)**: 최상위 문서가 다른 출처의 문서(예: 타 사이트가 연 팝업창)와 브라우징 컨텍스트 그룹을 공유하지 못하도록 차단하여 해커의 메모리 간섭을 막습니다.
|
||||
- **`Cross-Origin-Embedder-Policy: require-corp` (COEP)** (또는 `credentialless`): 명시적으로 CORS(교차 출처 리소스 공유) 허가를 받지 않은 모든 외부 리소스(외부 CDN 이미지, 서드파티 스크립트, iframe 등)가 내 페이지에 임베드되는 것을 원천적으로 차단합니다.
|
||||
|
||||
**4. 설정 후 확인 및 주의사항** 서버 설정이 완료되면 클라이언트의 브라우저 콘솔에서 `crossOriginIsolated` 속성이 `true`로 반환되며, 비로소 에러 없이 `SharedArrayBuffer`를 사용할 수 있습니다. 단, 이 보안 정책은 매우 엄격하기 때문에 기존에 잘 불러와지던 **외부 이미지나 구글 애널리틱스 같은 스크립트가 렌더링 차단되는 사이드 이펙트**가 발생할 수 있습니다. 이를 해결하려면 모든 외부 리소스 태그에 `crossorigin="anonymous"` 속성을 추가하고 리소스 서버 측에서 CORS 헤더를 올바르게 열어주어야 합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Spectre Vulnerability]], [[HTTP Security Headers (COOP/COEP)]], [[CORS (Cross-Origin Resource Sharing)]], [[Web Worker Multi-threading]]
|
||||
- **Projects/Contexts:** [[보안이 강화된 멀티스레드 기반 React WebGL 게임 엔진 구축]]
|
||||
- **Contradictions/Notes:** 제공된 소스에 따르면 `SharedArrayBuffer`는 성능과 속도 면에서 가장 이상적이지만 로우 레벨(Low-level)의 원시 이진 데이터를 다루어야 해서 구현이 까다롭습니다. 여기에 더해 COOP/COEP 보안 헤더까지 설정해야 하므로 인프라 구축 및 외부 리소스 관리의 복잡성이 급격히 증가한다는 점을 프로젝트 기획 단계에서 반드시 고려해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
_Last updated: 2026-04-14_
|
||||
- Raw Source: [[00_Raw/2026-04-20/SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation 설정법.md]]
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,57 +2,157 @@
|
||||
id: wiki-2026-0508-variance-rules
|
||||
title: Variance Rules
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-85151B]
|
||||
aliases: [Variance Algebra, Var Properties, Bienaymé Identity]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
verification_status: applied
|
||||
tags: [statistics, probability, math, identity]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Variance-Rules"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: Python
|
||||
framework: NumPy
|
||||
---
|
||||
|
||||
# [[Variance-Rules]]
|
||||
# Variance Rules
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
## 매 한 줄
|
||||
> **"매 random variable 의 spread 의 algebra — Var(aX + b) = a²Var(X), 매 independence 매 sum 의 add"**. 1853 Bienaymé 의 sum-of-independent identity 부터 매 modern propagation-of-uncertainty, finance VaR, ML loss decomposition 까지 — 매 variance algebra 의 매 day-1 statistics 의 still 매 most-used identity.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
### 매 core identities
|
||||
- **Definition**: $\mathrm{Var}(X) = \mathbb{E}[(X - \mathbb{E}[X])^2] = \mathbb{E}[X^2] - \mathbb{E}[X]^2$.
|
||||
- **Affine**: $\mathrm{Var}(aX + b) = a^2 \mathrm{Var}(X)$ — 매 constant $b$ 의 drop.
|
||||
- **Sum**: $\mathrm{Var}(X + Y) = \mathrm{Var}(X) + \mathrm{Var}(Y) + 2\,\mathrm{Cov}(X, Y)$.
|
||||
- **Independence (Bienaymé)**: $X \perp Y \Rightarrow \mathrm{Var}(X+Y) = \mathrm{Var}(X) + \mathrm{Var}(Y)$.
|
||||
- **Linear comb**: $\mathrm{Var}\!\left(\sum a_i X_i\right) = \sum a_i^2 \mathrm{Var}(X_i) + 2 \sum_{i<j} a_i a_j \mathrm{Cov}(X_i, X_j)$.
|
||||
- **Law of total variance**: $\mathrm{Var}(Y) = \mathbb{E}[\mathrm{Var}(Y|X)] + \mathrm{Var}(\mathbb{E}[Y|X])$.
|
||||
- **Sample variance bias correction**: $s^2 = \frac{1}{n-1}\sum (x_i - \bar{x})^2$ — 매 Bessel.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/Variance-Rules.md]]
|
||||
---
|
||||
### 매 propagation (delta method)
|
||||
- **Univariate**: $\mathrm{Var}(g(X)) \approx (g'(\mu))^2 \mathrm{Var}(X)$.
|
||||
- **Multivariate**: $\mathrm{Var}(g(\mathbf{X})) \approx \nabla g(\mu)^\top \Sigma \nabla g(\mu)$.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Portfolio variance (Markowitz).
|
||||
2. Error propagation in physics measurement.
|
||||
3. ML bias-variance decomposition.
|
||||
4. A/B test sample-size (Welch).
|
||||
5. Kalman filter — covariance propagation.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Numerical sample variance — Welford (numerically stable)
|
||||
```python
|
||||
def welford_variance(stream):
|
||||
n = 0; mean = 0.0; M2 = 0.0
|
||||
for x in stream:
|
||||
n += 1
|
||||
delta = x - mean
|
||||
mean += delta / n
|
||||
M2 += delta * (x - mean) # 매 use updated mean
|
||||
return mean, M2 / (n - 1) if n > 1 else float('nan')
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Linear combination variance
|
||||
```python
|
||||
import numpy as np
|
||||
def linear_combo_var(weights, cov):
|
||||
# Var(w^T X) = w^T Σ w
|
||||
w = np.asarray(weights); cov = np.asarray(cov)
|
||||
return float(w @ cov @ w)
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Portfolio variance (Markowitz)
|
||||
```python
|
||||
def portfolio_var(weights, returns_matrix):
|
||||
cov = np.cov(returns_matrix, rowvar=False, ddof=1)
|
||||
return weights @ cov @ weights
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Delta-method propagation
|
||||
```python
|
||||
import numpy as np
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
def delta_method(g, grad_g, mu, sigma):
|
||||
# mu: vector, sigma: covariance
|
||||
g_grad = np.asarray(grad_g(mu))
|
||||
return float(g_grad @ sigma @ g_grad)
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Law of total variance — verify by simulation
|
||||
```python
|
||||
import numpy as np
|
||||
rng = np.random.default_rng(0)
|
||||
N = 1_000_000
|
||||
X = rng.integers(0, 3, size=N) # 매 latent class
|
||||
mu_y = np.array([0.0, 1.0, 5.0])[X]
|
||||
Y = rng.normal(mu_y, scale=1.0)
|
||||
total = Y.var()
|
||||
inner = np.array([Y[X==k].var() for k in range(3)]).mean()
|
||||
outer = np.array([Y[X==k].mean() for k in range(3)]).var()
|
||||
print(total, inner + outer) # 매 ≈ equal
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Bias-variance decomposition (ML)
|
||||
```python
|
||||
def bias_variance(predictions, y_true):
|
||||
# predictions: (n_models, n_samples)
|
||||
mean_pred = predictions.mean(axis=0)
|
||||
bias_sq = ((mean_pred - y_true) ** 2).mean()
|
||||
var = predictions.var(axis=0).mean()
|
||||
noise_lb = 0.0 # 매 estimable 의 의 separately
|
||||
return bias_sq, var, noise_lb
|
||||
```
|
||||
|
||||
### Welch's t-test variance handling
|
||||
```python
|
||||
from scipy import stats
|
||||
t, p = stats.ttest_ind(a, b, equal_var=False) # Welch
|
||||
# 매 unequal variance — Satterthwaite degrees of freedom
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Streaming variance | Welford (numerically stable) |
|
||||
| Independent sum | Bienaymé — sum the variances |
|
||||
| Correlated sum | Full covariance — $w^\top \Sigma w$ |
|
||||
| Nonlinear function $g(X)$ | Delta method (1st-order) — or Monte Carlo |
|
||||
| Hierarchical / mixture | Law of total variance 의 decompose |
|
||||
| ML overfitting diagnose | Bias-variance decomposition |
|
||||
| Sample variance | Bessel correction ($n-1$) |
|
||||
|
||||
**기본값**: independence 의 confirm 후 Bienaymé. Doubt — Monte Carlo 의 verify.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Probability Theory]] · [[Random Variable]]
|
||||
- 변형: [[Covariance]] · [[Standard Deviation]] · [[Conditional Variance]]
|
||||
- 응용: [[Portfolio Theory]] · [[Bias-Variance Tradeoff]] · [[Kalman Filter]]
|
||||
- Adjacent: [[Delta Method]] · [[Bessel Correction]] · [[Welford Algorithm]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: identity recall, derivation hint, code skeleton (Welford, delta).
|
||||
**언제 X**: 매 specific paper 의 closed-form — derivation 의 cross-check.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Bienaymé 의 correlated variable 의 apply**: 매 covariance 의 forget — biased toward zero variance.
|
||||
- **Two-pass naive variance** ($\sum x_i^2 - (\sum x_i)^2/n$): 매 catastrophic cancellation — Welford 의 use.
|
||||
- **Sample variance with $n$**: 매 biased — Bessel ($n-1$).
|
||||
- **Affine 매 $b$ 의 add to variance**: 매 $b$ 의 drop, only $a^2$ matters.
|
||||
- **Delta method 의 high curvature 의 use**: 매 1st-order — large $\sigma$ 의 의 break, 의 Monte Carlo.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Bienaymé 1853; Casella & Berger _Statistical Inference_ 2nd ed.; Welford 1962 _Technometrics_).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — variance algebra + Welford + delta method 정리 |
|
||||
|
||||
@@ -1,25 +1,34 @@
|
||||
---
|
||||
id: wiki-20260508--data-driven-balancing--redir
|
||||
title: 데이터 기반 밸런싱(Data Driven Balancing)
|
||||
category: General Knowledge
|
||||
status: merged
|
||||
redirect_to: 데이터_기반_밸런싱(Data-Driven_Balancing)
|
||||
canonical_id: 데이터_기반_밸런싱(Data-Driven_Balancing)
|
||||
title: 데이터 기반 밸런싱(Data-Driven Balancing)
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: wiki-2026-0508-data-driven-balancing
|
||||
duplicate_of: "[[데이터 기반 밸런싱]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, balancing, data-driven, game-design]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# 데이터 기반 밸런싱(Data Driven Balancing)
|
||||
# 데이터 기반 밸런싱(Data-Driven Balancing)
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[데이터_기반_밸런싱(Data-Driven_Balancing)]]**로 통합되었습니다.
|
||||
> **이 문서는 [[데이터 기반 밸런싱]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
---
|
||||
*Redirected to: [[데이터_기반_밸런싱(Data-Driven_Balancing)]]*
|
||||
## 핵심 요약
|
||||
- 매 telemetry 의 collect → 매 statistical analysis → 매 patch tuning 의 closed loop.
|
||||
- 매 2026 의 standard: 매 League/Dota/Apex 의 ML-driven balance pipeline 의 사용.
|
||||
- 매 same content — 매 (Data-Driven Balancing) 의 영어 suffix 의 variant.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[데이터 기반 밸런싱]] (canonical)
|
||||
- 인접: [[텔레메트리]] · [[Machinations]] · [[A_B Testing]]
|
||||
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,70 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-데이터-기반-밸런싱
|
||||
title: 데이터 기반 밸런싱
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: data-driven-balancing
|
||||
duplicate_of: "[[Data-Driven Balancing]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, game-balance, analytics]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 데이터 기반 밸런싱
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
[[WARNO]]의 데이터 기반 밸런싱은 방대한 **텔레메트리(Telemetry) 데이터**를 수집하고 분석하여 게임 내 유닛과 사단의 성능을 정밀하게 조정하는 시스템이다 [1, 2]. 개발사는 커뮤니티의 단순한 여론에 휘둘리지 않고 픽률, 승률, 킬/데스 비율 등의 객관적 데이터를 바탕으로 밸런스를 평가한다 [1, 2]. 이를 통해 무기 스펙, 포인트 비용, 특성 등을 NDF 파일에서 실시간으로 수정함으로써 공정하고 지속 가능한 전술 생태계를 유지한다 [2-4].
|
||||
> **이 문서는 [[Data-Driven Balancing]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **텔레메트리(Telemetry) 시스템 활용:**
|
||||
Eugen[[ system]]s는 게임 출시 이후 수집되는 방대한 텔레메트리 데이터를 통해 밸런스를 정밀하게 조정한다 [2]. 이 시스템은 플레이어들의 **유닛 선택 빈도(Pick Rate), 실제 교전에서의 승률, 킬/데스 비율, 평균 생존 시간** 등을 실시간으로 기록하여 유닛이 게임 내에서 실제로 어떻게 작동하는지 모니터링한다 [1, 2].
|
||||
* **객관적 데이터 중심의 의사결정:**
|
||||
개발진은 커뮤니티의 변덕스럽고 단편적인 불만이나 여론에 단순히 휘둘리기보다는, 전문 테스터의 피드백과 객관적으로 수집된 텔레메트리 데이터를 대조하여 밸런싱을 수행한다 [1, 2]. 예를 들어, 특정 대공 미사일이 항공기를 너무 쉽게 격추한다는 사실이 텔레메트리 분석을 통해 입증되면, 개발자는 **해당 무기의 명중률 곡선이나 가격 데이터를 NDF 파일 내에서 즉각적으로 수정**하여 전장에 반영한다 [2, 3].
|
||||
* **주요 밸런스 조정 변수:**
|
||||
데이터 분석 결과를 바탕으로 밸런스를 맞추기 위해 사용되는 주요 변수에는 전술적 가치와 텔레메트리 효율에 따른 **'포인트 비용(Point Cost)'**, 장전 및 조준 시간과 같은 **'무장 세부 스펙'**, 전술적 역할을 강화하기 위한 **'특성(Trait) 할당'**, 그리고 특정 사단의 승률이 낮을 경우 보완하기 위한 **'사단별 유닛 카드 구성 및 가용성'** 데이터의 상향 등이 포함된다 [4].
|
||||
* **진영 간 밸런스 검증:**
|
||||
대규모 10v10 멀티플레이어 데이터 분석에 따르면, NATO와 PACT 진영 간의 플레이 비중 및 승률은 **플레이어의 숙련도가 높아질수록 균형을 이루는 경향**을 보인다 [4, 5]. 특정 진영만 선호하는 플레이어들의 데이터를 분석한 결과에서도, 게임 시스템 자체가 어느 한 진영에 압도적인 우위를 제공하지 않음이 객관적으로 증명되었다 [4].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Data-Driven Balancing]] (canonical)
|
||||
- Adjacent: [[Machinations]] · [[LiveOps]]
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[텔레메트리 시스템]], [[NDF (Neutral Data Format)]], [[사단 시스템]]
|
||||
- **Projects/Contexts:** [[WARNO 멀티플레이어 밸런스 패치]], [[Eugen Systems 밸런싱 방법론]]
|
||||
- **Contradictions/Notes:** 게임 커뮤니티 일각에서는 잦은 너프와 밸런스 변경에 대해 지속적으로 불만을 제기하기도 하지만, 개발진은 텔레메트리를 통해 확인된 실제 사용률 및 성능 데이터를 기반으로 밸런스를 지속적으로 조정하는 것이 게임의 장기적인 지원과 수명 유지에 필수적이라고 판단하고 있다 [1, 6].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,74 +1,33 @@
|
||||
---
|
||||
id: wiki-2026-0508-디아블로-2-diablo-ii-조던링-사태
|
||||
title: 디아블로 2(Diablo II) 조던링 사태
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: diablo-2-economy
|
||||
duplicate_of: "[[Game Economy Case Studies]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, game-economy, diablo, dupe-bug]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 디아블로 2(Diablo II) 조던링 사태
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
디아블로 2(Diablo II) 조던링 사태는 게임 내에서 발생한 극심한 초인플레이션(hyperinflation)으로 인해 기본 화폐가 붕괴한 유명한 사례입니다 [1, 2]. 게임 초반에 기본 통화인 골드가 너무 지나치게 풍부해져 가치를 잃자, 플레이어들은 골드 대신 흔하지만 유용한 아이템인 '조던링(Stone of Jordan)'을 기본 통화로 사용하기 시작했습니다 [2]. 이는 게임 경제 설계 시 통화 공급을 적절히 통제하지 못할 경우 유저들이 공식 화폐를 버리고 대체 경제를 형성할 수 있음을 보여줍니다 [2, 3].
|
||||
> **이 문서는 [[Game Economy Case Studies]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 Core 기Content
|
||||
* **기본 화폐(골드)의 붕괴:** 디아블로 2에서는 게임 초반부터 골드가 너무 과도하게 풀리면서 가치가 폭락했고, 이로 인해 플레이어들은 골드를 화폐로 사용하는 것을 완전히 포기했습니다 [2].
|
||||
* **대체 통화의 등장:** 골드를 대신하여 플레이어들은 '조던링(Stone of Jordan)'을 거래 수단으로 삼았으며, 게임 내 다른 아이템들의 가격 역시 조던링의 개수로 매겨질 만큼 조던링이 게임의 기본 통화를 완전히 대체했습니다 [2].
|
||||
* **아이템 복제와 퇴출:** 이후 플레이어들이 조던링을 위조(spoof)하고 복제하는 방법을 빠르게 터득함에 따라, 개발진은 해당 아이템을 게임에서 제거하는 조치를 취해야만 했습니다 [2].
|
||||
* **사태의 여파:** 조던링이 게임에서 제거된 이후에도 플레이어들은 가치가 없는 골드 경제로 회귀하지 않았습니다. 그 대신 단순히 다른 특정 아이템을 새로운 기본 통화로 채택하여 그들만의 물물교환 경제를 계속 유지했습니다 [2].
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 SOJ(Stone of Jordan) 의 de facto currency 화 — gold inflation 의 결과.
|
||||
- 매 dupe bug + bot economy 의 hyperinflation 사례.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[인플레이션(Inflation)]], [[초인플레이션(Hyperinflation)]], [[게임 경제 설계(Game Economy Design)]]
|
||||
- **Projects/Contexts:** [[디아블로 2(Diablo II)]]
|
||||
- **Contradictions/Notes:** 소스에 제공된 내용 외에 조던링 사태에 대한 구체적인 패치나 시스템적 대응 과정에 대해서는 소스에 관련 정보가 부족합니다. 다만 이 사례는 플레이어들이 화폐를 무한정 창출할 수 있는 환경이 주어졌을 때 경제가 얼마나 쉽게 붕괴하는지를 경고하는 지표로 활용됩니다 [2, 4].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Game Economy Case Studies]] (canonical)
|
||||
- Adjacent: [[Resource Management]] · [[Free-to-Play]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,65 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-디지털-트윈-digital-twin
|
||||
title: 디지털 트윈(Digital Twin)
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: digital-twin
|
||||
duplicate_of: "[[Digital Twin]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, simulation, iot]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 디지털 트윈([[Digital Twin]])
|
||||
# 디지털 트윈(Digital Twin)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
게임 산업과 경제 설계에서 디지털 트윈은 복잡한 시스템, 개념 및 아이디어를 쉽게 검증하고 소통할 수 있도록 돕는 '플레이 가능한 시뮬레이션 모델'을 의미한다 [1]. 출시 후 실제 게임에서 발생하는 텔레메트리 데이터(JSON)를 시뮬레이션 모델에 입력하여 현실과 모델 사이의 간극을 좁히는 방식으로 작동한다 [2]. 이를 통해 개발자는 시간의 흐름에 따른 게임 시스템의 동작을 관찰하고 플레이어의 미래 행동을 효과적으로 예측할 수 있다 [1, 2].
|
||||
> **이 문서는 [[Digital Twin]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **미래 예측 및 격차 축소**: 디지털 트윈은 라이브 서비스([[LiveOps]]) 환경에서 강력한 예측 도구로 기능한다. 게임 출시 후 실제 플레이어들로부터 수집되는 텔레메트리 데이터를 시뮬레이션 모델에 주입(Data Ingestion)함으로써 현실의 게임플레이와 가상의 수학적 모델 사이의 오차를 줄이고 미래의 경제적 변화와 행동을 예측한다 [2].
|
||||
* **가시성과 동적 분석 제공**: 정적인 스프레드시트나 솔버 기반의 분석과 달리, 디지털 트윈은 버튼 클릭 한 번으로 시간에 따른 게임 시스템의 동작을 모든 세부 수준에서 관찰할 수 있게 해준다 [1].
|
||||
* **개발 효율성 증대 및 리스크 회피**: 게임의 디지털 트윈이 한 번 구축되면, 실제 코드를 작성하거나 새로운 빌드를 배포하지 않고도 즉각적으로 변경 사항을 적용할 수 있다 [1]. 또한, 라이브 서버의 실제 플레이어를 대상으로 경제 실험을 진행하는 위험을 감수할 필요 없이 다양한 '만약의 시나리오(What-if scenarios)'를 안전하게 탐색하고 단 몇 분 만에 귀중한 데이터 인사이트를 도출할 수 있다 [1].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Digital Twin]] (canonical)
|
||||
- Adjacent: [[IoT]] · [[Simulation]] · [[Iriszoom Engine]]
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[마키네이션([[Machinations]])]], [[게임 경제 설계(Game Economy Design)]], [[시뮬레이션(Simulation)]], [[라이브옵스(LiveOps)]]
|
||||
- **Projects/Contexts:** [[데이터 기반 수익화 전략 분석 및 가상 경제 시스템 검증 프로젝트]]
|
||||
- **Contradictions/Notes:** 소스 내에서 상충되는 정보는 없으나, 정적이고 이상적인 스프레드시트 기반의 접근 방식과 대비하여 디지털 트윈이 동적 시스템을 모니터링하고 리스크 없이 게임 밸런싱을 수행하는 데 훨씬 효율적이라는 점이 지속적으로 강조된다 [1, 2].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,65 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-라이브옵스-liveops
|
||||
title: 라이브옵스(LiveOps)
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: liveops
|
||||
duplicate_of: "[[LiveOps]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, liveops, game-operations]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 라이브옵스([[LiveOps]])
|
||||
# 라이브옵스(LiveOps)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
라이브옵스(LiveOps)는 비디오 게임이 일회성 출시로 끝나는 것이 아니라 정기적인 업데이트, 신규 콘텐츠 출시 및 지속적인 지원을 제공하는 '지속적인 서비스(ongoing services)'로 진화함에 따라 등장한 게임 운영 방식이다 [1]. 이는 게임 출시 이후에도 플레이어의 참여를 유도하고 유지율(Retention)을 높이기 위해 각종 라이브 이벤트와 콘텐츠를 제공하는 것을 핵심으로 한다 [2, 3]. 나아가 실제 플레이어 데이터를 시뮬레이션 모델에 통합하여 게임 내 경제 밸런스와 수익을 지속적으로 최적화하는 경제 설계의 핵심 도구로도 활용된다 [4, 5].
|
||||
> **이 문서는 [[LiveOps]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **지속적인 서비스와 이벤트 전략:** 라이브옵스는 게임의 장기적인 성공과 리텐션을 위한 필수 프레임워크로 자리 잡았으며, 현대 게임(특히 캐주얼 장르)에서는 파트너 이벤트, 엄브렐라 이벤트(다수의 소규모 이벤트 병행), 미니 게임, 연승(Streak) 이벤트 등 매우 다양한 형태의 라이브 이벤트로 구현된다 [2, 3, 6, 7].
|
||||
- **플레이어 참여도 및 경제적 효과 강화:** 이러한 라이브 이벤트 전략은 플레이어가 게임 루프에 지속적으로 복귀하여 이벤트 통화를 수집하도록 유도하며, 무작위성과 지속적인 소규모 보상을 통해 핵심 게임플레이에 대한 참여도를 크게 높인다 [8]. 결과적으로 **라이브옵스는 단순한 콘텐츠 제공을 넘어 플레이어의 유지율을 방어하고 인앱 구매 등 수익 창출(Monetization) 기회를 확장하는 중요한 게임 경제 설계 요소로 작동한다** [2, 7].
|
||||
- **데이터 기반의 시뮬레이션 및 최적화(LiveOps 데이터 인제스션):** 성공적인 라이브옵스 운영을 위해서는 게임 출시 후 수집되는 실제 텔레메트리 데이터(JSON 등)를 [[Machinations]]와 같은 경제 시뮬레이션 모델에 지속적으로 입력하는 '데이터 인제스션(Data Ingestion)' 과정이 활용된다 [5, 9]. **이를 통해 현실의 라이브 데이터와 시뮬레이션 모델 사이의 간극을 좁히고 플레이어의 미래 행동을 예측하는 '디지털 트윈'을 구축할 수 있으며**, 라이브 게임의 밸런스와 수익성을 과학적으로 보정하고 최적화할 수 있다 [4, 5, 9].
|
||||
## 🔗 Graph
|
||||
- 부모: [[LiveOps]] (canonical)
|
||||
- Adjacent: [[Free-to-Play]] · [[Data-Driven Balancing]]
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[게임 경제 설계(Game Economy Design)]], [[리텐션(Retention)]], [[디지털 트윈 및 데이터 시뮬레이션]]
|
||||
- **Projects/Contexts:** [[Machinations 라이브옵스 데이터 연동]], [[Monopoly GO! 및 Royal Match의 라이브 이벤트 구조]], [[하이브리드 캐주얼 게임(Hybrid-casual Games)]]
|
||||
- **Contradictions/Notes:** 라이브옵스는 사용자 참여와 생애 가치(LTV)를 유지하기 위한 훌륭한 수단이지만, 웹2(Web2) 기반의 하이브리드 캐주얼 게임 등에서는 끊임없는 콘텐츠 업데이트와 이벤트 순환에 의존해야 하므로 개발사에게 실질적인 '운영 부담(burden)'으로 작용할 수 있다는 한계가 지적된다 [10].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,73 +2,32 @@
|
||||
id: wiki-2026-0508-마크-스위프-컴팩트-mark-sweep-compact
|
||||
title: 마크 스위프 컴팩트(Mark Sweep Compact)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-F94637]
|
||||
duplicate_of: none
|
||||
status: duplicate
|
||||
canonical_id: mark-sweep-compact
|
||||
duplicate_of: "[[Garbage Collection]]"
|
||||
aliases: []
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 마크-스위프-컴팩트(Mark-Sweep-Compact)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
verification_status: redirected
|
||||
tags: [duplicate, gc, memory-management]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# [[마크-스위프-컴팩트(Mark-Sweep-Compact)]]
|
||||
# 마크-스위프-컴팩트(Mark-Sweep-Compact)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
> **이 문서는 [[Garbage Collection]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **마크(Mark) 단계:**
|
||||
가비지 컬렉터가 힙 내부의 모든 객체를 탐색하여 사용 중인 라이브 객체와 그렇지 않은 객체를 식별하는 단계이다 [8, 9]. 루트(Root) 객체부터 시작하여 포인터로 연결된 객체들을 깊이 우선 탐색(DFS) 방식으로 쫓아가며 도달 가능성을 확인한다 [10, 11]. 이 과정에서 객체들은 세 가지 색상(Tri-color)으로 분류되어 마킹된다 [4, 8]. 가비지 컬렉터가 아직 발견하지 못한 객체는 '흰색(White)', 발견되었지만 이웃 객체들의 처리가 완료되지 않은 상태는 '회색(Grey)', 그리고 객체 자신과 그 이웃까지 모두 처리가 완료된 상태는 '검은색(Black)'으로 표시된다 [8, 12].
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 Mark-Sweep-Compact GC algorithm — fragmentation 해결의 compact phase.
|
||||
- 매 stop-the-world GC 의 대표 strategy.
|
||||
|
||||
* **스위프(Sweep) 단계:**
|
||||
마킹 단계가 끝난 후에도 도달할 수 없어 '흰색'으로 남아있는 데드 객체들의 연속된 범위를 스캔하는 단계이다 [4, 13, 14]. 가비지 컬렉터는 이 데드 객체 영역을 빈 공간(Free spaces)으로 변환하고 이를 가용 목록(Free lists)에 추가한다 [13, 14]. 가용 목록은 크기별(Small, Medium, Large 등)로 구분되어 관리되며, 이후 새로운 객체를 할당하거나 스캐빈저(Scavenger) 알고리즘에 의해 살아남은 객체들이 이전 세대(Old space)로 승격(Promotion)될 때 사용된다 [13, 14].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Garbage Collection]] (canonical)
|
||||
- Adjacent: [[Memory Management]] · [[JVM]] · [[V8]]
|
||||
|
||||
* **컴팩트(Compact) 단계:**
|
||||
힙 메모리의 단편화(Fragmentation)를 줄이기 위해, 빈 공간이 많아 파편화된 페이지에서 라이브 객체들을 가용 공간이나 완전히 새로운 페이지로 이주시키는 과정이다 [2, 15, 16]. 객체가 새로운 위치로 복사되면, 원본 객체의 첫 번째 워드에 새로운 위치를 가리키는 포워딩 주소(Forwarding address)가 남겨진다 [15, 17]. 대규모 힙 공간에서 객체를 이동시키고 이를 참조하는 모든 포인터를 일일이 업데이트하는 작업은 계산 비용이 크기 때문에, 모든 스위프 주기마다 컴팩트가 일어나는 것은 아니며 메모리 파편화가 심각할 때 선택적으로 수행된다 [7, 18].
|
||||
|
||||
* **성능 및 최적화 전략 (Orinoco 및 동시성 기법):**
|
||||
마크-스위프-컴팩트는 수백 메가바이트의 데이터를 처리하므로 애플리케이션 실행을 멈추는 긴 중단 시간(수백 밀리초 단위)을 초래할 수 있다 [2, 5]. V8 엔진의 Orinoco 프로젝트 등 최신 구현체들은 이를 해결하기 위해 백그라운드 스레드를 이용해 자바스크립트 실행과 동시에 마킹 작업을 수행하는 동시 마킹(Concurrent marking), 작업을 잘게 쪼개어 배분하는 점진적 마킹(Incremental marking), 그리고 당장 빈 공간이 필요해질 때까지 스위핑을 늦추는 지연 스위핑(Lazy sweeping) 기법 등을 도입하여 메인 스레드의 부담을 최소화하고 있다 [5, 19-21].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[이전 세대(Old Generation/Space)]], [[스캐빈저(Scavenger)]], [[동시성 및 점진적 마킹(Concurrent & Incremental Marking)]]
|
||||
- **Projects/Contexts:** [[V8 자바스크립트 엔진]], [[자바 가상 머신(JVM)]], [[Orinoco 프로젝트]]
|
||||
- **Contradictions/Notes:** 소스 전반에서 마크-스위프-컴팩트의 기본 원리에는 차이가 없으나, 작동 환경(예: V8 엔진 대 IBM JVM)에 따라 이 알고리즘을 트리거하는 조건이나 조정 가능한 커맨드라인 옵션(`-Xcompactgc`, `--trace-gc` 등)은 구체적인 구현체에 따라 각기 다르게 제어된다는 점이 확인된다 [18, 22].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
- Raw Source: [[00_Raw/2026-04-20/마크-스위프-컴팩트(Mark-Sweep-Compact).md]]
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,67 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-마키네이션-machinations
|
||||
title: 마키네이션(Machinations)
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: machinations
|
||||
duplicate_of: "[[Machinations]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, machinations, game-design]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 마키네이션([[Machinations]])
|
||||
# 마키네이션(Machinations)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
마키네이션(Machinations)은 코드를 작성하지 않고도 복잡한 가상 경제 시스템을 시각적으로 모델링, 시뮬레이션 및 밸런싱할 수 있도록 지원하는 전문적인 게임 경제 설계 플랫폼이다[1-3]. 이 플랫폼은 정적인 엑셀 스프레드시트의 한계를 극복하고 몬테카를로 시뮬레이션을 활용해 플레이어의 무작위적인 행동 패턴과 게임 내 자원 흐름을 예측하는 '플레이 가능한 디지털 트윈(Playable [[Digital Twin]]s)'을 구축한다[1, 4, 5]. 결과적으로 게임 기획자와 경제 디자이너는 게임 출시 전후에 발생할 수 있는 인플레이션이나 밸런스 붕괴 위험을 사전에 포착하고, 핵심 지표를 최적화하여 플레이어의 경험과 생애 가치(LTV)를 극대화할 수 있다[6-8].
|
||||
> **이 문서는 [[Machinations]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **시각적 모델링과 실시간 시뮬레이션:** 마키네이션은 표준화된 시각적 언어를 사용하여 복잡하고 추상적인 게임 내 경제 시스템을 대화형 다이어그램으로 구축한다[9]. 개발자는 **코딩 작업이나 실제 라이브 빌드를 배포할 필요 없이** 시스템을 실시간으로 시뮬레이션하며 다양한 "만약의 시나리오(what-if scenarios)"를 안전하게 검증할 수 있다[1, 2].
|
||||
- **몬테카를로 시뮬레이션을 통한 무작위성(Randomness) 반영:** 단순한 수학적 평균치에 의존하는 전통적 테스트 방식은 실제 플레이어의 편향이나 비합리적 선택을 예측하는 데 한계가 있다[4]. 마키네이션은 **대수의 법칙(Law of Large Numbers)과 몬테카를로 시뮬레이션**을 활용하여 수만 번에 달하는 가상 플레이어의 여정을 실행함으로써 창발성([[Emergence]])과 무작위성을 반영하고, 게임 내 자원의 과부족 시점을 정확히 예측한다[3-5, 10].
|
||||
- **AI 밸런서(Balancer)를 이용한 파라미터 자동화:** 마키네이션은 게임 밸런싱 과정을 획기적으로 자동화하는 AI 도구인 '밸런서(Balancer)'를 제공한다[11]. 디자이너가 "첫 10분 동안 플레이어가 최대 3번만 죽도록 한다"와 같은 **구체적인 목표를 설정하면, 시스템이 이를 달성하기 위한 최적의 게임 내 파라미터를 자동으로 조정**해 준다[3, 11].
|
||||
- **라이브옵스([[LiveOps]]) 데이터 연동과 디지털 트윈 구축:** 게임 출시 이후에는 유니티 애널리틱스([[Unity]] Analytics) 등에서 발생하는 실제 게임의 **텔레메트리 데이터(JSON 형식)나 스프레드시트 데이터를 모델에 직접 연동(Data Ingestion)**할 수 있다[3, 12]. 이러한 실시간 피드백 루프를 통해 초기 가설 모델을 고도로 정확한 예측을 제공하는 **'디지털 트윈(Digital Twin)'**으로 진화시킨다[3, 12].
|
||||
- **웹3(Web3) 및 토크노믹스(Tokenomics) 경제 검증:** 복잡한 변동 가격과 개방형 자산 거래를 다루는 웹3 환경에서도 마키네이션은 필수적인 도구로 활용된다[13, 14]. 스마트 컨트랙트를 실제로 배포하기 전에 **토크노믹스 구조의 지속 가능성과 인플레이션 위험을 수학적으로 투명하게 검증**할 수 있어 블록체인 게임 개발자들 사이에서 널리 채택되고 있다[14, 15].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Machinations]] (canonical)
|
||||
- Adjacent: [[Data-Driven Balancing]] · [[Monte Carlo Simulation]]
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[게임 경제 설계(Game Economy Design)]], [[몬테카를로 시뮬레이션(Monte Carlo Simulation)]], [[디지털 트윈(Digital Twin)]], [[라이브옵스(LiveOps)]]
|
||||
- **Projects/Contexts:** [[웹3 및 토크노믹스 모델링(Web3 and Tokenomics Modeling)]], [[하이브리드 수익화 전략(Hybrid Monetization [[Strategy]])]]
|
||||
- **Contradictions/Notes:** 전통적인 스프레드시트 모델링은 정적이고 단순 평균에 의존하여 게임 시스템의 창발적 결과(Emergence)를 예측하기 어려운 반면, 마키네이션은 무작위성(Randomness)을 모델에 포함시켜 실제 플레이어의 복잡한 행동에 훨씬 가까운 현실적인 예측 결과를 도출한다[1, 3, 4].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,57 +2,27 @@
|
||||
id: wiki-2026-0508-무제
|
||||
title: 무제
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-D69A80]
|
||||
duplicate_of: none
|
||||
status: duplicate
|
||||
canonical_id: untitled-placeholder
|
||||
duplicate_of: "[[README]]"
|
||||
aliases: []
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 무제"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
confidence_score: 0.5
|
||||
verification_status: redirected
|
||||
tags: [duplicate, placeholder, untitled]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# [[무제]]
|
||||
# 무제
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
> **이 문서는 placeholder 입니다.** [[README]] 로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 🔗 Graph
|
||||
- 부모: [[README]] (canonical)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/무제.md]]
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — placeholder 정리 |
|
||||
|
||||
@@ -1,72 +1,154 @@
|
||||
---
|
||||
id: wiki-2026-0508-부분-유료화-free-to-play-게임
|
||||
title: 부분 유료화(Free to Play) 게임
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
title: 부분 유료화(Free-to-Play) 게임
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [F2P, Free-to-Play, 부분유료, 프리투플레이]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [f2p, monetization, mobile, gacha, battle-pass]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: typescript
|
||||
framework: nodejs
|
||||
---
|
||||
|
||||
# 부분 유료화(Free-to-Play) 게임
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
부분 유료화(Free-to-Play, F2P) 게임은 사용자가 소프트웨어를 무료로 다운로드하고 플레이할 수 있지만, 인앱 결제(IAP)나 인앱 광고(IAA) 등의 소액 결제를 통해 수익을 창출하는 비즈니스 모델을 가진 게임입니다 [1, 2]. 이 모델에서 성공적인 게임 경제는 플레이어의 참여를 수익화 기회로 전환하는 핵심 역할을 하며, 재화의 생성과 소모의 정교한 균형을 유지하여 과도한 인플레이션을 방지하는 것이 필수적입니다 [3-5]. 주로 소수의 고액 결제자인 '고래(Whales)'가 수익의 대부분을 창출하지만, 무과금 플레이어들 또한 고래가 지배력을 행사할 생태계를 구성한다는 점에서 경제 구조 유지에 매우 중요한 역할을 담당합니다 [6-8].
|
||||
## 매 한 줄
|
||||
> **"매 entry 의 free + 매 in-game purchase 의 monetize"**. 매 2000s Asian PC MMO 에서 출발 — 매 2010s mobile 의 dominant model. 매 2026 의 industry: 매 mobile gross revenue 의 약 ~80% + 매 console / PC 의 hybrid F2P (Fortnite, Apex, Marvel Rivals) 의 mainstream.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **생태계 구조와 고래 사냥([[Whale Hunting]]) 모델:**
|
||||
F2P 게임의 수익 분포는 불균형적인 특징을 보이며, 수익의 약 80%가 상위 20%의 플레이어, 그중에서도 고액 결제자인 '고래'들로부터 발생합니다 [7, 9]. 게임 개발사 입장에서 무과금 사용자(새우)는 직접적인 수익을 주지 않지만, 고래들이 상대적 우월감을 느끼고 지배력을 과시하기 위해 반드시 필요한 존재이므로 이들 간에는 공생 관계가 형성됩니다 [8]. 최근에는 하이퍼 캐주얼 게임조차 단순함을 넘어 인앱 광고(IAA)와 인앱 결제(IAP)를 결합한 하이브리드 수익화 모델로 진화하여 수익성을 극대화하고 있습니다 [10, 11].
|
||||
* **게임 경제 설계와 탭/싱크(Tap & Sink) 밸런스:**
|
||||
F2P 모델에서는 돈의 흐름과 자원을 조절하는 게임 경제 설계가 게임의 성패를 가릅니다 [4, 12]. 시스템 내부로 재화를 공급하는 '수도꼭지(Tap/Faucets)'와 소비를 유도하여 재화를 회수하는 '배수구(Sinks)' 간의 세밀한 밸런싱이 필수적입니다 [13-15]. 재화가 너무 많아 인플레이션이 발생하면 아이템 구매욕구와 인앱 결제의 매력도가 떨어지고, 반대로 너무 적으면 플레이어가 좌절하여 이탈하게 됩니다 [5, 16, 17].
|
||||
* **페이투윈([[Pay-to-win]]) 함정 회피:**
|
||||
무료 게임 경제 설계의 흔한 비판 중 하나는 돈을 써야만 이길 수 있는 '페이투윈' 구조입니다 [18]. 게임이 이 함정에 빠지면 커뮤니티와 게임의 평판이 훼손되어 많은 플레이어를 잃게 됩니다 [18]. 따라서 개발자들은 과금하지 않아도 최고 수준의 보상을 획득할 수 있는 경로를 제공하되 그 과정의 지루함을 돈으로 단축시킬 수 있도록 하거나, 밸런스에 영향을 주지 않는 꾸미기(Cosmetic) 아이템 위주로 수익 모델을 조정해야 합니다 [9, 12].
|
||||
* **성공을 측정하는 핵심 성과 지표(KPI):**
|
||||
F2P 경제를 지속적으로 안정화하기 위해 개발사는 상세한 데이터를 모니터링해야 합니다 [19, 20]. 사용자 확보 비용(CAC) 대비 고객 평생 가치(LTV)의 비율(이상적으로는 3:1 이상)을 통해 획득 채널의 수익성을 파악하며, 결제 사용자당 평균 매출(ARPPU)과 1인당 평균 매출(ARPU)을 바탕으로 가치 창출을 평가합니다 [21-25]. 또한 무료 모델에서는 과금 시점 이전까지 플레이어를 잡아두는 것이 중요하므로 유지율(Retention Rate)과 이탈률(Churn Rate)을 철저히 추적해야 합니다 [26, 27].
|
||||
* **데이터 시뮬레이션 및 플레이어의 소비 심리:**
|
||||
F2P 게임 내에서의 구매는 성능 향상(유용성), 즐거움, 타인과의 경쟁 및 선망(평판), 투자, 그리고 자아실현이라는 심리적 동기 및 행동 경제학의 지배를 받습니다 [28-30]. 플레이어의 이러한 무작위적이고 복잡한 결정들을 런칭 전에 예측하고 검증하기 위해 몬테카를로 시뮬레이션(Monte Carlo Simulation) 등 도구를 사용하여 장기적인 경제 시스템과 수익화 가능성을 분석합니다 [31-33].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[인앱 구매(IAP)]], [[인앱 광고(IAA)]], [[고객 평생 가치(LTV)]], [[고객 획득 비용(CAC)]], [[유지율(Retention Rate)]], [[가상 경제(Virtual Economy)]]
|
||||
- **Projects/Contexts:** [[원신(Genshin Impact)]] (콘솔급 오픈월드 경험을 모바일 무료 게임으로 구현했으며, '레진' 시스템 및 가차(Gacha) 기반 모델로 진행과 수익화를 조절함 [34-36]), [[클래시 로얄(Clash Royale)]] (제한된 자원인 엘릭서를 활용해 밸런스를 맞추고, 유사 에셋의 재사용으로 다양한 전략적 옵션을 제공하는 경제적인 게임 디자인 사례 [36-40]).
|
||||
- **Contradictions/Notes:** 고액 결제를 하는 고래 플레이어들을 사냥하기 위해 과도한 과금 요소를 배치하면 단기 수익은 오를 수 있으나 게임이 '페이투윈'으로 분류되어 다수의 일반 플레이어들이 떠나게 됩니다. 무과금 유저(새우)는 직접적인 수익 창출원은 아니지만, 고래 플레이어가 경쟁하고 지배력을 과시할 환경을 제공한다는 점에서 F2P 생태계 유지를 위해 없어서는 안 될 존재라는 모순적이고도 상호보완적인 특징을 지닙니다 [8, 18].
|
||||
### 매 monetization archetype
|
||||
- **Cosmetic-only**: 매 Fortnite / Valorant — 매 pay-for-look.
|
||||
- **Convenience**: 매 Genshin resin refresh — 매 pay-for-time.
|
||||
- **Power (gacha)**: 매 Honkai / Diablo Immortal — 매 pay-for-stat.
|
||||
- **Battle pass**: 매 across all archetype — 매 standardize 됨 (2018+).
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
### 매 player segment
|
||||
- **Whale** (top 1%, ~50% revenue).
|
||||
- **Dolphin** (next 10%, ~30%).
|
||||
- **Minnow** (next ~30%, ~20%).
|
||||
- **Free** (60%+, 매 0 revenue + 매 retention/ecosystem 의 contribute).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 design lever
|
||||
- **Pacing wall**: 매 free progression 의 deliberate slow.
|
||||
- **Premium currency**: 매 dual-currency 의 obfuscate price.
|
||||
- **Limited offer**: 매 24h flash sale + 매 anchor pricing.
|
||||
- **Soft / hard pity**: 매 gacha 의 expected-value floor.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Dual currency (premium / soft)
|
||||
```typescript
|
||||
class Wallet {
|
||||
gems: number = 0; // premium (paid)
|
||||
coins: number = 0; // soft (earned)
|
||||
spend(cost: { gems?: number; coins?: number }) {
|
||||
if ((cost.gems ?? 0) > this.gems) return false;
|
||||
if ((cost.coins ?? 0) > this.coins) return false;
|
||||
this.gems -= cost.gems ?? 0;
|
||||
this.coins -= cost.coins ?? 0;
|
||||
return true;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Gacha with soft + hard pity
|
||||
```typescript
|
||||
function pull(state: GachaState) {
|
||||
state.pullsSinceSSR++;
|
||||
const baseRate = 0.006;
|
||||
const softFloor = state.pullsSinceSSR >= 75
|
||||
? baseRate + (state.pullsSinceSSR - 74) * 0.06
|
||||
: baseRate;
|
||||
const isSSR = state.pullsSinceSSR >= 90 || Math.random() < softFloor;
|
||||
if (isSSR) state.pullsSinceSSR = 0;
|
||||
return { isSSR, pity: state.pullsSinceSSR };
|
||||
}
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Battle pass tier
|
||||
```typescript
|
||||
function unlockedRewards(xp: number, hasPremium: boolean, season: Season) {
|
||||
const tier = tierFromXP(xp, season);
|
||||
return season.rewards
|
||||
.slice(0, tier)
|
||||
.filter(r => hasPremium || r.track === 'free');
|
||||
}
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Time-gated resin
|
||||
```typescript
|
||||
function regenResin(state: ResinState, now: number) {
|
||||
const elapsed = now - state.lastUpdate;
|
||||
state.value = Math.min(160, state.value + Math.floor(elapsed / 480_000));
|
||||
state.lastUpdate = now;
|
||||
}
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Daily flash offer (anchor pricing)
|
||||
```typescript
|
||||
function todayOffer(userId: string) {
|
||||
const seg = classify(userId);
|
||||
return {
|
||||
sku: 'gem_pack_500',
|
||||
originalPrice: 9.99,
|
||||
discountedPrice: seg === 'minnow' ? 1.99 : 4.99,
|
||||
expiresAt: endOfDay(),
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
### Spending guardrail (regulatory)
|
||||
```typescript
|
||||
async function chargeIAP(userId, amount) {
|
||||
const monthly = await wallet.monthlySpend(userId);
|
||||
if (monthly + amount > REGION_CAP[user.region]) {
|
||||
return { ok: false, reason: 'monthly_cap' };
|
||||
}
|
||||
return iap.charge(userId, amount);
|
||||
}
|
||||
```
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 PvP shooter | 매 cosmetic-only (avoid pay-to-win) |
|
||||
| 매 gacha RPG | 매 character banner + 매 soft pity 75 / hard 90 |
|
||||
| 매 strategy / 4X | 매 convenience (speed-up) + 매 cosmetic |
|
||||
| 매 hyper-casual | 매 ad-based + 매 remove-ads IAP |
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
**기본값**: 매 BP + 매 cosmetic + 매 1 convenience SKU — 매 PvP 의 trust 의 maintain.
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🔗 Graph
|
||||
- 부모: [[Game Monetization]]
|
||||
- 변형: [[Gacha]] · [[Battle Pass]] · [[Hyper-Casual]] · [[하이브리드 캐주얼]]
|
||||
- 응용: [[원신(Genshin Impact)]] · [[클래시 로얄(Clash Royale)]] · [[알비온 온라인(Albion Online)]]
|
||||
- Adjacent: [[라이브옵스(LiveOps)]] · [[데이터 기반 밸런싱]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 SKU copy 의 generation / localization, 매 monetization spec 의 review, 매 player segment 의 narrative profile.
|
||||
**언제 X**: 매 actual pricing decision — 매 elasticity 의 empirical A/B test 의 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Pay-to-win in PvP**: 매 trust collapse + 매 esports 의 viability 의 destroy.
|
||||
- **Hidden gacha rate**: 매 regulatory risk (China, S. Korea, Belgium 의 disclosure mandate).
|
||||
- **Whale farming**: 매 top 0.1% 의 only target → 매 community erosion.
|
||||
- **Aggressive FOMO**: 매 24/7 limited offer → 매 burnout / churn.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Sensor Tower 2026 mobile report, GDC 2024-2025 monetization talks, 한국 게임산업진흥원 자율규제).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — archetype + segment + gacha/BP pattern |
|
||||
|
||||
@@ -1,66 +1,144 @@
|
||||
---
|
||||
id: wiki-2026-0508-비디오-게임-산업의-플랫폼-융합-platform-conve
|
||||
title: 비디오 게임 산업의 플랫폼 융합(Platform Convergence)
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Platform Convergence, Cross-Platform, 멀티플랫폼]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [platform, cross-play, cloud-gaming, industry, distribution]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: cpp
|
||||
framework: unreal
|
||||
---
|
||||
|
||||
# 비디오 게임 산업의 플랫폼 융합(Platform Convergence)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
비디오 게임 산업의 플랫폼 융합(Platform Convergence)은 과거 콘솔, PC, 모바일로 명확히 구분되던 시장의 경계가 클라우드 게이밍과 크로스 플랫폼 기술의 발달로 인해 허물어지는 현상을 의미한다 [1, 2]. 이는 플레이어가 기기에 얽매이지 않고 노트북, 콘솔, 태블릿, 모바일 등 여러 기기 사이를 이동하며 동일한 게임 라이브러리와 진행 상황을 경험할 수 있는 '하드웨어 불가지론적([[Hardware]]-agnostic)' 미래를 제시한다 [3, 4]. 이러한 융합은 게임의 유통 방식을 근본적으로 변화시켜, 다중 게임 구독(Multigame subscriptions) 및 지속적인 플레이어 참여도를 기반으로 하는 새로운 게임 경제 설계와 수익화 전략을 개발자들에게 요구하고 있다 [5, 6].
|
||||
## 매 한 줄
|
||||
> **"매 console / PC / mobile / cloud 의 boundary 의 erode + 매 single account / single progression 의 unification"**. 매 2010s 후반 의 Fortnite cross-play (2018) 가 catalyst — 매 2026 의 modern: 매 Microsoft Activision-Blizzard 인수 (2023) + 매 Game Pass cloud + 매 mobile-console hybrid (Genshin, COD Mobile) 의 mainstream.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **클라우드 게이밍 주도의 하드웨어 불가지론(Hardware-agnostic) 시대:** 클라우드 게이밍의 주류화는 특정 전용 하드웨어에 대한 의존도를 낮추고 각 플랫폼 간의 뚜렷한 경계를 무너뜨려 융합된 게임 경험을 창출하고 있다 [6, 7]. 2026년 기준 글로벌 게이밍 설문조사에 따르면 게이머의 약 60%가 클라우드 게이밍을 경험했으며, 이 중 80%가 긍정적인 반응을 보일 정도로 관련 기술이 빠르게 수용되고 있다 [2, 3, 8].
|
||||
* **유통 모델의 변화와 참여도 중심의 경제 설계:** 플랫폼 융합은 지난 40여 년간 유지된 게임 소프트웨어와 하드웨어 간 분리 모델의 재구성을 촉진한다 [5]. 특히 클라우드 기반의 다중 게임 구독 서비스는 개발자의 핵심 경제적 목표를 단순한 '소프트웨어 판매량'에서 플레이어의 '총 플레이 시간(hours played)'으로 전환시킨다 [5]. 무제한에 가까운 콘텐츠 라이브러리 환경에서는 게임 내 체류 시간과 '참여도(Engagement)'가 경제 활성화의 필수 지표가 되며, 이에 맞춰 구독 상품 내에서 수익 가치를 적절히 평가하고 유지하는 경제 모델 설계가 핵심 경쟁력이 되었다 [6].
|
||||
* **마찰 없는(Frictionless) 게임플레이 환경과 사용자 획득 효율:** 플랫폼의 제약을 넘어서는 클라우드 게이밍은 게임을 별도로 다운로드할 필요 없이 광고, 이메일, 혹은 스토어 페이지에서 즉각적으로 플레이를 시작할 수 있게 해준다 [4]. 이러한 마찰 없는 접근성은 전환율(conversion rates)을 획기적으로 상승시켜 신규 사용자 획득을 용이하게 만들며, 게임 내 경제 생태계로 진입하는 유저 풀을 효과적으로 확장한다 [4].
|
||||
* **크로스 플랫폼 플레이의 선구적 성공 사례:** '원신(Genshin Impact)'과 같은 타이틀은 모바일 환경에서도 콘솔급 게임 경험을 제공할 수 있음을 기술적으로 증명하며 플랫폼 융합 트렌드를 선도했다 [9]. Windows, iOS, Android, PlayStation 등 여러 플랫폼 기기 사용자 간의 실시간 게임플레이를 지원하고, PC와 모바일 사이에서 자유롭게 상태를 저장 및 전환할 수 있는 크로스 플랫폼 기능을 성공적으로 구현함으로써 막대한 기술적 성취와 글로벌 흥행을 기록하였다 [10, 11].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[클라우드 게이밍(Cloud Gaming)]], [[크로스 플랫폼 기술(Cross-Platform Technology)]], [[다중 게임 구독 모델(Multigame Subscriptions)]], [[사용자 참여도(Player Engagement)]]
|
||||
- **Projects/Contexts:** [[2026년 BCG 글로벌 게이밍 설문조사]], [[원신(Genshin Impact)]]
|
||||
- **Contradictions/Notes:** 플랫폼 융합이 가속화됨에도 불구하고 전용 게이밍 하드웨어(예: 콘솔)가 완전히 종말을 맞이하는 것은 아니다. 빠르고 간편한 플러그 앤 플레이 경험을 원하는 수요는 지속될 것이며, 콘솔은 사라지기보다는 융합된 생태계 안에서 플레이어가 선택할 수 있는 '다양한 진입점(entry points) 중 하나'로 그 역할이 변모할 것이다 [5].
|
||||
### 매 4 convergence axis
|
||||
- **Cross-play**: 매 input parity / matchmaking pool 의 unify.
|
||||
- **Cross-progression**: 매 save / inventory / BP 의 cloud-sync.
|
||||
- **Cross-purchase**: 매 single SKU 의 multi-platform entitlement.
|
||||
- **Cross-platform commerce**: 매 unified store / wallet (Epic Games Store, Xbox).
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
### 매 driver
|
||||
- **Hardware parity**: 매 mobile chip 의 console-class (A18 Pro, Snapdragon 8 Gen 4).
|
||||
- **Cloud streaming**: 매 GeForce Now / xCloud / PS Cloud — 매 device-agnostic.
|
||||
- **Engine portability**: 매 Unreal 5.4 / Unity 6 의 1-codebase multi-target.
|
||||
- **Regulatory pressure**: 매 EU DMA / 매 epic-vs-apple 의 store competition.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 friction point
|
||||
- **Input asymmetry**: 매 KB+M vs gamepad vs touch — 매 fairness.
|
||||
- **Platform fee**: 매 30% 의 historical cut + 매 alternative store 의 fragmentation.
|
||||
- **Monetization rule divergence**: 매 Apple loot-box rule vs 매 Google vs 매 console.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Cross-play matchmaking with input bucket
|
||||
```cpp
|
||||
enum class InputType { Touch, Gamepad, KBM };
|
||||
struct MatchPool {
|
||||
InputType type;
|
||||
std::vector<Player> queue;
|
||||
};
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
void enqueue(Player p) {
|
||||
pools[p.input].queue.push_back(p);
|
||||
if (p.allowsCrossInput) pools[p.input | CROSS].queue.push_back(p);
|
||||
}
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Cross-progression sync
|
||||
```cpp
|
||||
void OnLogin(UserId u, Platform p) {
|
||||
auto cloud = CloudSave::Fetch(u);
|
||||
auto local = LocalSave::Load(p);
|
||||
auto merged = Merge(cloud, local); // last-write-wins per shard
|
||||
CloudSave::Push(u, merged);
|
||||
}
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Entitlement check (cross-purchase)
|
||||
```cpp
|
||||
bool HasItem(UserId u, ItemId i) {
|
||||
for (auto& p : LinkedPlatforms(u)) {
|
||||
if (Entitlements::Has(p, u, i)) return true;
|
||||
}
|
||||
return false;
|
||||
}
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Cloud render fallback
|
||||
```cpp
|
||||
void RenderFrame() {
|
||||
if (device.gpuTier < kMinTier) {
|
||||
cloud.StreamFrame(); // GeForce Now style
|
||||
} else {
|
||||
local.RenderFrame();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
### Platform-specific monetization gate
|
||||
```cpp
|
||||
SkuList AvailableSkus(Platform p) {
|
||||
auto skus = baseSkus;
|
||||
if (p == Platform::iOS_KR) skus.removeIf(s => s.kind == "lootbox");
|
||||
if (p == Platform::Web) skus.add(directWebPaymentSkus);
|
||||
return skus;
|
||||
}
|
||||
```
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
### Build matrix CI
|
||||
```yaml
|
||||
matrix:
|
||||
platform: [windows, ps5, xbox, switch2, ios, android, linux-cloud]
|
||||
config: [shipping, dev]
|
||||
steps:
|
||||
- run: ue5 BuildCookRun -platform=${{ platform }}
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 PvP competitive | 매 input-bucket 의 enforce + 매 opt-in cross |
|
||||
| 매 PvE / co-op | 매 full cross-play default |
|
||||
| 매 mobile-first | 매 cloud progression + 매 touch-optimized UI |
|
||||
| 매 console exclusive | 매 cross-progression 의 only (no cross-play) |
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
**기본값**: 매 cross-play (input-bucketed) + 매 cross-progression + 매 cross-purchase (where store policy 의 allow).
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Game Industry]] · [[Distribution Platform]]
|
||||
- 변형: [[Cloud Gaming]] · [[Cross-Play]] · [[Multi-Target Build]]
|
||||
- 응용: [[원신(Genshin Impact)]] · [[Fortnite]] · [[Game Pass]]
|
||||
- Adjacent: [[Microsoft-ActivisionBlizzard 인수]] · [[Epic vs Apple]] · [[EU DMA]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 platform-specific compliance text 의 generation, 매 SKU matrix 의 review, 매 industry trend 의 summarize.
|
||||
**언제 X**: 매 legal compliance 의 final decision — 매 jurisdiction-specific lawyer 의 review 의 mandatory.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Forced cross-input PvP**: 매 KB+M vs touch 의 mix → 매 unfair.
|
||||
- **Last-write-wins save 의 unconditional**: 매 cloud merge bug → 매 progression loss.
|
||||
- **Single-platform monetization assumption**: 매 Apple/Google rule 의 ignore → 매 store rejection.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Newzoo 2026 platform report, Microsoft 10-K 2024, Apple App Store guidelines 2026).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — convergence axis + driver + 6 patterns |
|
||||
|
||||
@@ -1,25 +1,34 @@
|
||||
---
|
||||
id: wiki-20260508--ugc--redir
|
||||
title: 사용자 제작 콘텐츠(UGC)
|
||||
category: General Knowledge
|
||||
status: merged
|
||||
redirect_to: 사용자_제작_콘텐츠(UGC)
|
||||
canonical_id: 사용자_제작_콘텐츠(UGC)
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: wiki-2026-0508-user-generated-content
|
||||
duplicate_of: "[[User Generated Content]]"
|
||||
aliases: [UGC, User-Generated Content]
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, ugc, game-design, platform]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# 사용자 제작 콘텐츠(UGC)
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[사용자_제작_콘텐츠(UGC)]]**로 통합되었습니다.
|
||||
> **이 문서는 [[User Generated Content]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
---
|
||||
*Redirected to: [[사용자_제작_콘텐츠(UGC)]]*
|
||||
## 핵심 요약
|
||||
- 매 player 의 create / share / monetize content 의 game platform.
|
||||
- 매 Roblox / Fortnite UEFN / Minecraft / Dreams 의 representative.
|
||||
- 매 2026 의 trend: 매 AI-assisted creation tool 의 integration (Roblox Cube, UEFN AI scaffolding).
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[User Generated Content]] (canonical)
|
||||
- 인접: [[Roblox]] · [[Fortnite UEFN]] · [[Platform Convergence]]
|
||||
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,65 +1,33 @@
|
||||
---
|
||||
id: wiki-2026-0508-알비온-온라인-albion-online-암시장-시스템
|
||||
title: 알비온 온라인(Albion Online) 암시장 시스템
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: albion-online
|
||||
duplicate_of: "[[Albion Online]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, mmo, economy, albion]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 알비온 온라인(Albion Online) 암시장 시스템
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
알비온 온라인(Albion Online)의 암시장(Black Market) 시스템은 플레이어 기반의 경제 시스템을 유지하기 위해 고안된 독특한 공급량 조절 메커니즘입니다. 이 시스템은 게임 내 몬스터가 드롭하는 전리품을 시스템이 임의로 생성하는 대신, 실제로 플레이어가 제작하여 판매한 아이템과 직접 연동되도록 설계되었습니다. 이를 통해 가상 경제 내 자원의 공급을 통제하고 통화 가치를 안정화하는 핵심적인 역할을 수행합니다 [1].
|
||||
> **이 문서는 [[Albion Online]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **플레이어 주도 경제의 핵심 루프:** 알비온 온라인은 EVE 온라인과 더불어 철저한 플레이어 기반의 경제 시스템을 특징으로 하는 대표적인 MMORPG입니다 [1]. 암시장 시스템은 이러한 플레이어 주도 경제가 붕괴하지 않고 자생적으로 순환하도록 돕는 필수적인 경제 구조입니다 [1].
|
||||
* **전리품과 제작 아이템의 연동:** 가상 경제의 설계 위험 중 하나는 몬스터 보상과 같은 자원 생성처(수도꼭지)가 무한하다는 점입니다 [1]. 알비온 온라인의 암시장 시스템은 몬스터가 드롭하는 전리품이 무한히 생성되는 것을 막기 위해, 드롭되는 아이템을 플레이어가 실제로 제작하여 판매한 아이템 물량과 연동시키는 방식으로 공급량을 조절합니다 [1].
|
||||
* **거시경제 서모스탯(Thermostat)을 통한 가치 안정화:** 암시장 시스템은 통화 가치를 보존하기 위한 장치로 작동하며, '글로벌 할인'이라고 불리는 거시경제 서모스탯(온도 조절기) 메커니즘을 통해 게임 내 통화 가치가 자동으로 안정화되도록 유도합니다 [1].
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 Black Market NPC — player crafted gear 의 sink mechanism.
|
||||
- 매 mob loot drop 의 supply 가 player-crafted item 으로 routed.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[가상 경제 시스템]], [[플레이어 기반 경제]], [[인플레이션 관리]]
|
||||
- **Projects/Contexts:** [[MMORPG 영속적 세계와 자원 관리]], [[EVE 온라인]]
|
||||
- **Contradictions/Notes:** 제공된 소스 내에서 본 주제와 관련된 상충되는 주장이나 모순점은 존재하지 않습니다. (다만 소스에 알비온 온라인의 암시장과 관련된 구체적인 수치나 세부 작동 공식에 대한 정보는 부족합니다.)
|
||||
## 🔗 Graph
|
||||
- 부모: [[Albion Online]] (canonical)
|
||||
- Adjacent: [[Resource Management]] · [[Game Economy Case Studies]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,69 +1,33 @@
|
||||
---
|
||||
id: wiki-2026-0508-알비온-온라인-albion-online
|
||||
title: 알비온 온라인(Albion Online)
|
||||
category: General Knowledge
|
||||
status: verified
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: albion-online
|
||||
duplicate_of: "[[Albion Online]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, mmorpg, sandbox, game]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 알비온 온라인(Albion Online)
|
||||
|
||||
## 📌[[ brief]] 무결성
|
||||
알비온 온라인(Albion Online)은 플레이어 기반의 경제 시스템을 특징으로 하는 대표적인 MMORPG이다. 이 게임은 '암시장'과 '글로벌 할인' 같은 정교한 거시경제 조절 장치를 통해 인게임 통화 가치와 자원의 공급량을 안정적으로 관리한다. 게임 경제 설계에 있어 플레이어의 자산 규모에 비례하여 작동하는 비율 기반의 재화 회수 시스템을 성공적으로 구현한 사례로 평가받고 있다 [1-3].
|
||||
> **이 문서는 [[Albion Online]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **플레이어 주도형 경제와 암시장(Black Market) 시스템**: 알비온 온라인은 게임 내 아이템 공급을 시스템이 일방적으로 창출하지 않고 플레이어의 생산 활동과 연동시킨다. 특히 몬스터가 드롭하는 전리품조차 무(無)에서 생성되는 것이 아니라, 실제로 플레이어가 제작하여 '암시장'에 판매한 아이템과 연동되도록 함으로써 전체적인 아이템 공급량을 정교하게 조절한다 [3].
|
||||
* **거시경제 서모스탯(자동 온도 조절 장치)**: 통화 가치의 급격한 변동과 인플레이션을 방지하기 위해 '글로벌 할인'이라는 거시경제 제어 시스템을 운영한다. 이를 통해 시스템 내의 통화 가치를 자동으로 안정화하고 경제적 평형을 유지한다 [3].
|
||||
* **비율(Percentage) 기반의 하드 싱크(Hard Sinks)**: 고정된 금액이 아닌 백분율을 기반으로 한 재화 소멸 장치(배수구)를 사용하여 경제 수명 주기 전반에 걸쳐 지속적인 인플레이션 억제 효과를 거두고 있다. 대표적으로 5~15%에 달하는 경매장 거래 수수료와 아이템 가치에 연동되는 수리비를 도입해, 플레이어의 자산 규모가 커지더라도 그에 비례하여 재화를 효과적으로 회수한다 [2, 4].
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- Sandbox Interactive (베를린) 매 cross-platform sandbox MMORPG (2017 출시).
|
||||
- 매 player-driven economy + full-loot PvP + classless "you are what you wear" 시스템.
|
||||
- 매 single-shard global server (Americas/EU/Asia regional gateway 통합 2023).
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[플레이어 기반 경제]], [[하드 싱크(Hard Sinks)]], [[인플레이션 관리]]
|
||||
- **Projects/Contexts:** [[MMORPG 경제 설계]], [[가상 경제의 배수구(Sinks)]]
|
||||
- **Contradictions/Notes:** 제공된 소스는 알비온 온라인의 성공적인 경제 제어 시스템(암시장, 백분율 기반 수수료 등)에 대해서만 긍정적으로 분석하고 있으며, 이 시스템이 가지는 부작용이나 한계점 등에 대해서는 소스에 관련 정보가 부족합니다.
|
||||
## 🔗 Graph
|
||||
- 부모: [[Albion Online]] (canonical)
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> Albion Online은 "플레이어가 만드는 모든 것"을 표방하는 샌드박스 MMORPG로, EVE의 경제 철학을 판타지 세계로 옮긴 사례다.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,25 +1,34 @@
|
||||
---
|
||||
id: wiki-20260508--genshin-impact--redir
|
||||
title: 원신(Genshin Impact)
|
||||
category: General Knowledge
|
||||
status: merged
|
||||
redirect_to: 원신(Genshin_Impact)
|
||||
canonical_id: 원신(Genshin_Impact)
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: wiki-2026-0508-genshin-impact
|
||||
duplicate_of: "[[Genshin Impact]]"
|
||||
aliases: [Genshin, 원신]
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, gacha, open-world, hoyoverse]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# 원신(Genshin Impact)
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[원신(Genshin_Impact)]]**로 통합되었습니다.
|
||||
> **이 문서는 [[Genshin Impact]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
---
|
||||
*Redirected to: [[원신(Genshin_Impact)]]*
|
||||
## 핵심 요약
|
||||
- 매 HoYoverse 의 2020 release — 매 open-world action RPG + gacha monetization.
|
||||
- 매 6-week patch cadence 의 LiveOps 의 archetype — 매 character banner / story chapter / event 의 rotation.
|
||||
- 매 2026 현재: 매 5.x patch series + 매 Natlan/Snezhnaya region rollout 의 진행.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Genshin Impact]] (canonical)
|
||||
- 인접: [[Gacha]] · [[LiveOps]] · [[Open World Design]]
|
||||
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,57 +2,32 @@
|
||||
id: wiki-2026-0508-이벤트-포워딩-event-forwarding
|
||||
title: 이벤트 포워딩(Event Forwarding)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-797EC7]
|
||||
duplicate_of: none
|
||||
status: duplicate
|
||||
canonical_id: event-forwarding
|
||||
duplicate_of: "[[Event-Driven Architecture]]"
|
||||
aliases: []
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 이벤트 포워딩(Event Forwarding)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
verification_status: redirected
|
||||
tags: [duplicate, events, architecture]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# [[이벤트 포워딩(Event Forwarding)]]
|
||||
# 이벤트 포워딩(Event Forwarding)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
> **이 문서는 [[Event-Driven Architecture]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 event delegation pattern — DOM bubbling + custom routing.
|
||||
- 매 webhook fan-out 의 message broker pattern.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
## 🔗 Graph
|
||||
- 부모: [[Event-Driven Architecture]] (canonical)
|
||||
- Adjacent: [[Pub-Sub]] · [[Webhooks]]
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/이벤트 포워딩(Event Forwarding).md]]
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,75 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-자원-관리-resource-management
|
||||
title: 자원 관리(Resource Management)
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: resource-management
|
||||
duplicate_of: "[[Resource Management]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, game-design, resources]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 자원 관리(Resource [[Management]])
|
||||
# 자원 관리(Resource Management)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
자원 관리(Resource Management)는 게임 세계 내에서 통화, 아이템 등 재화의 분배, 획득, 지출을 통제하는 경제 시스템을 의미한다[1, 2]. 주로 자원을 게임 내로 유입시키는 '수도꼭지(Faucets/Taps)'와 자원을 소모시키는 '배수구(Sinks)' 메커니즘을 통해 관리되며, 자원의 희소성과 플레이어의 욕구 사이에서 최적의 균형을 찾는 것을 목표로 한다[3, 4]. 효과적이고 구조적인 자원 관리는 게임 내 인플레이션을 방지하고, 플레이어의 몰입도를 유지하며, 궁극적으로 성공적인 수익화(Monetization) 기회를 창출하는 핵심 기반이 된다[5-7].
|
||||
> **이 문서는 [[Resource Management]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **수도꼭지(Faucets)와 배수구(Sinks)의 메커니즘**
|
||||
게임 경제의 기본 아키텍처는 자원의 생성과 소멸을 관리하는 구조로 이루어진다[4]. 사냥, 퀘스트, 시간당 생산 기지 등 능동적/수동적으로 자원을 유입시키는 요소를 '수도꼭지'라고 하며, NPC 상점 구매, 장비 수리비, 경매장 수수료 등 자원을 시스템에서 영구적으로 소멸시키는 장치를 '하드 싱크(Hard Sinks)'라고 한다[3, 8, 9]. 자원이 너무 많이 제공되면 희소성이 사라져 플레이어가 지루함을 느끼고, 반대로 자원이 너무 적으면 좌절감을 느끼고 이탈하게 되므로 이 둘의 세밀한 균형이 요구된다[5, 10].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Resource Management]] (canonical)
|
||||
- Adjacent: [[Resource Deposits]] · [[RTS Design]]
|
||||
|
||||
* **변환기(Converters) 및 경제적 마찰**
|
||||
자원은 단순히 생성되거나 사라지는 데 그치지 않고 다른 형태의 가치로 변환된다[7]. 장비를 제작할 때 수수료를 내거나 재료의 손실이 발생하는 등 투입 가치가 산출 가치보다 약간 높게 설정되어 경제적 마찰을 유발하며, 이것이 추가적인 배수구 역할을 한다[7]. 또한, 경매장의 거래 수수료는 시스템 전체의 통화량을 조절할 수 있는 가장 거대하고 전략적인 자원 회수 기제이다[7].
|
||||
|
||||
* **핀치 포인트(Pinch Point)와 인플레이션 제어**
|
||||
훌륭한 자원 관리는 자원 공급에 대한 우려로 인해 수요가 극대화되는 지점인 '핀치 포인트(Pinch Point)'를 형성한다[11]. 만약 플레이어가 무한정 자원을 파밍하도록 방치하면 화폐 가치가 하락하는 하이퍼인플레이션이 발생하여 인앱 결제(IAP)의 매력도를 떨어뜨리게 된다[12, 13]. 이를 제어하기 위해 자원 획득량 증가에 맞춰 업그레이드 비용을 함께 올리는 점진적 메커니즘, 초고가 하이엔드 아이템 도입, PvP 도박 및 거래 수수료 등의 세금 부과, 시즌별 초기화 전략이 활용된다[14-24].
|
||||
|
||||
* **장르별 자원 관리 전략과 사례**
|
||||
* **수집형 RPG 및 가차 게임**: 《원신(Genshin Impact)》은 캐릭터 성장 재료를 얻기 위한 파밍 속도를 통제하기 위해 '레진(Resin)'이라는 스태미나 자원 시스템을 사용하여 플레이어의 콘텐츠 소비와 진행 속도를 관리한다[25, 26].
|
||||
* **실시간 PvP 게임**: 《클래시 로얄(Clash Royale)》에서는 전투 중 실시간으로 차오르는 '엘릭서(Elixir)'가 핵심 자원으로 작용하며, 플레이어는 한정된 엘릭서 자원 내에서 적절한 비용의 카드를 내야 하는 전략적 딜레마를 겪게 된다[27-29].
|
||||
* **MMORPG**: 《알비온 온라인(Albion Online)》처럼 영속적인 경제를 가진 게임은 몬스터 전리품을 플레이어가 제작한 아이템과 연동하는 암시장 시스템이나 글로벌 할인 메커니즘을 도입하여 거시적인 자원 공급량과 가치를 통제한다[26].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[수도꼭지와 배수구(Taps and Sinks)]], [[게임 경제 인플레이션(Game Economy Inflation)]], [[핀치 포인트(Pinch Point)]], [[수익화(Monetization)]]
|
||||
- **Projects/Contexts:** [[원신(Genshin Impact)의 레진 시스템]], [[클래시 로얄(Clash Royale)의 엘릭서]], [[알비온 온라인(Albion Online)의 경제 시스템]]
|
||||
- **Contradictions/Notes:** 인플레이션은 일반적으로 통화 가치를 폭락시키고 수익 모델을 망치는 위험 요소로 간주되지만, 시스템적으로 의도하고 통제할 경우 오히려 긍정적인 역할도 한다. 예를 들어 RPG에서 강력한 아이템 비용과 획득량을 같이 늘려 진행감을 주거나, 신규 유저가 빠르게 초기 구간을 돌파하도록 돕는 후발 주자의 진입 장벽(Latecomer disadvantage) 극복 도구로 사용될 수 있다[30-33].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,25 +1,35 @@
|
||||
---
|
||||
id: wiki-20260508--clash-royale--redir
|
||||
title: 클래시 로얄(Clash Royale)
|
||||
category: General Knowledge
|
||||
status: merged
|
||||
redirect_to: 클래시_로얄(Clash_Royale)
|
||||
canonical_id: 클래시_로얄(Clash_Royale)
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: 클래시_로얄-clash-royale
|
||||
duplicate_of: "[[클래시_로얄(Clash_Royale)]]"
|
||||
aliases: [Clash Royale, CR]
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, clash-royale, mobile-game, supercell]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# 클래시 로얄(Clash Royale)
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[클래시_로얄(Clash_Royale)]]**로 통합되었습니다.
|
||||
> **이 문서는 [[클래시_로얄(Clash_Royale)]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
---
|
||||
*Redirected to: [[클래시_로얄(Clash_Royale)]]*
|
||||
## 매 핵심 요약 (specialization aspects)
|
||||
- 매 Supercell (2016-) — 매 real-time card-based PvP — 매 8-card deck × 1v1 lane combat × 3-min match.
|
||||
- 매 대칭 ruleset (양측 동일 elixir / 동일 tower) → 매 esports-friendly. 매 Clash Royale League (CRL) 의 global 운영.
|
||||
- 매 monetization — 매 chest unlock + gem-to-skip + season pass — 매 mobile F2P 의 reference design.
|
||||
- 매 2026 state — 매 Evolutions mechanic + Champion cards + level-15 cap. 매 daily active ~5M.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[클래시_로얄(Clash_Royale)]] (canonical)
|
||||
- 관련: [[클래시 로얄(Clash Royale)의 엘릭서]] · [[부분 유료화(Free-to-Play) 게임]]
|
||||
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,70 +1,33 @@
|
||||
---
|
||||
id: wiki-2026-0508-클래시-로얄-clash-royale-의-대칭성과-밸런싱
|
||||
title: 클래시 로얄(Clash Royale)의 대칭성과 밸런싱
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: clash-royale
|
||||
duplicate_of: "[[Clash Royale]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, clash-royale, balance, symmetry]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 클래시 로얄(Clash Royale)의 대칭성과 밸런싱
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
클래시 로얄은 수천만 명의 플레이어가 경쟁하는 모바일 실시간 전략 게임으로, 한정된 자원인 '엘릭서(Elixir)'와 카드 업그레이드 비용의 표준화를 통해 정교한 경제적 밸런스를 유지합니다. 유닛 콘텐츠의 효율적인 재사용 및 비용 대비 보상의 딜레마 구조를 통해, 플레이어가 복잡한 계산 없이도 깊이 있는 전략적 결정을 내릴 수 있도록 설계된 성공적인 게임 경제의 대표적 사례입니다.
|
||||
> **이 문서는 [[Clash Royale]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **업그레이드 비용 및 성장 수치의 표준화**
|
||||
클래시 로얄은 카드의 희귀도에 관계없이 모든 카드가 레벨당 일정 비율로 체력과 데미지 등의 성장 수치가 상승하도록 설계되어 있습니다 [1]. 이와 더불어 최고 레벨 달성을 위해 요구되는 골드 비용 역시 유사한 구조로 기획되어 있어, 개발진이 게임 내 대칭성을 유지하고 전체적인 밸런싱 난이도를 크게 낮출 수 있도록 돕습니다 [1].
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 mirror-match symmetry — 양 player 의 동일 starting condition.
|
||||
- 매 deck asymmetry + map symmetry 의 fairness balance.
|
||||
|
||||
* **엘릭서(Elixir) 시스템이 창출하는 리듬감과 딜레마**
|
||||
전투 중 실시간으로 차오르는 분홍색 게이지인 엘릭서는 플레이어의 행동 타이밍을 조절하는 핵심 경제 자원입니다 [1, 2]. 1코스트 스켈레톤부터 9코스트의 고비용 카드에 이르는 순환 구조 속에서 플레이어는 지속적으로 위험과 보상(Risks and Rewards)을 저울질하는 선택의 딜레마에 놓이게 됩니다 [1]. 예를 들어, 평균 코스트가 더 높은 덱을 사용하는 것은 더 큰 위험을 감수하는 대신 높은 보상(승리)을 노리는 전략적 선택으로 작용합니다 [2].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Clash Royale]] (canonical)
|
||||
- Adjacent: [[Data-Driven Balancing]] · [[Variance Rules]]
|
||||
|
||||
* **콘텐츠(유닛) 재사용을 통한 밸런싱 최적화**
|
||||
게임은 새로운 유닛을 계속 추가하여 복잡도를 높이기보다, 스켈레톤이나 고블린 같은 기본 유닛의 에셋과 코드를 무리(군단), 마법, 생성 건물 등 다양한 맥락에서 재사용하는 기획(Economical Design)을 채택했습니다 [3]. 이는 메모리 용량 등 기술적 이점뿐만 아니라 밸런싱을 매우 직관적이고 단순하게 만듭니다. 특정 카드의 성능을 조정할 때 복잡한 수치 계산 대신 단순히 생성되는 유닛의 수만 가감하는 방식(예: 스켈레톤 군대의 스켈레톤 개체 수를 1개 줄임으로써 너프)으로 쉽게 밸런스를 맞출 수 있습니다 [3].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[게임 경제 설계(Game Economy Design)]], [[위험과 보상 구조(Structures of Risks and Rewards)]], [[자원 관리(Resource [[Management]])]]
|
||||
- **Projects/Contexts:** [[클래시 로얄 모바일 게임 프로덕션]], [[실시간 전략 및 부분유료화(F2P) 밸런싱 맥락]]
|
||||
- **Contradictions/Notes:** 소스 내에서 클래시 로얄의 '대칭성'이라는 단어는 소스 제목과 맥락에서 직접적으로 언급되나, 순수하게 수학적/구조적인 대칭성에 대한 학술적 정의에 대해서는 소스에 관련 정보가 부족합니다. 문서의 주된 초점은 업그레이드 비용 표준화와 엘릭서 소비를 통한 밸런싱 위주로 설명되어 있습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -1,79 +1,145 @@
|
||||
---
|
||||
id: wiki-2026-0508-클래시-로얄-clash-royale-의-비용-엘릭서-밸런싱
|
||||
title: 클래시 로얄(Clash Royale)의 비용 엘릭서 밸런싱
|
||||
category: General Knowledge
|
||||
title: 클래시 로얄(Clash Royale)의 비용-엘릭서 밸런싱
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Clash Royale Elixir Balance, 엘릭서 밸런스]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [clash-royale, balancing, elixir, supercell, mobile-pvp, case-study]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: simulation
|
||||
---
|
||||
|
||||
# 클래시 로얄(Clash Royale)의 비용/엘릭서 밸런싱
|
||||
# 클래시 로얄(Clash Royale)의 비용-엘릭서 밸런싱
|
||||
|
||||
## 📌[[ brief]] 시 Summary
|
||||
클래시 로얄(Clash Royale)은 실시간으로 차오르는 '엘릭서(Elixir)'라는 한정된 자원을 기반으로 유닛을 배치하고 경쟁하는 게임이다 [1, 2]. 게임 내의 카드들은 1코스트부터 9코스트까지 다양한 엘릭서 비용을 가지며, 이 엘릭서 비용과 유닛 성능 간의 효율성 균형이 게임 경제 설계의 핵심이다 [2, 3]. 이러한 구조적 밸런싱은 플레이어의 행동 타이밍을 조절하고, 비용 대비 효율과 위험 감수를 고려한 최적의 의사결정(딜레마)을 유도하여 게임의 몰입도를 높인다 [2, 4].
|
||||
## 매 한 줄
|
||||
> **"매 elixir cost 1~9 의 single resource 의 design 으로 매 100+ card 의 균형"**. 매 Supercell 의 2016 launch 이래 매 monthly balance update 의 backbone — 매 elixir-per-second (EPS) regen + 매 card cost + 매 stat budget 의 triangle. 매 2026 의 evolution mechanic 의 도입 으로 매 budget 재계산.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **엘릭서 메커니즘과 리듬감 (Rhythm of Elixir):**
|
||||
엘릭서는 전투 중 시간의 흐름에 따라 최대 10까지 차오르는 게임 내 핵심 자원이다 [3]. 시각적인 핑크색 엘릭서 바는 플레이어가 카드를 사용할 수 있는 타이밍(리듬감)을 조율하는 역할을 한다 [3, 5]. 1코스트 스켈레톤부터 9코스트의 고비용 카드까지 순환하는 구조는 플레이어가 한정된 자원 내에서 최적의 결정을 내리도록 강제하며, 게임 내에 지속적인 딜레마를 형성한다 [2].
|
||||
## 매 핵심
|
||||
|
||||
* **위험과 보상 구조 (Risks and Rewards Structure):**
|
||||
덱을 구성하고 엘릭서를 소비하는 과정은 경제적 '위험과 보상' 모델을 충실히 따른다 [6, 7]. 예를 들어, 플레이어가 엘릭서 바가 가득 찬 상태에서 9코스트 카드를 사용하면 남은 엘릭서가 1밖에 되지 않아 선택 가능한 후속 카드가 제한되는 '단순 선택 딜레마(Simple Choice Dilemma)'에 빠지게 된다 [4, 8]. 대회 사례를 보면, 평균 비용이 3.8 엘릭서로 다소 무거운 덱을 운영하는 것은 평균 3.0 엘릭서 덱을 상대할 때 더 높은 위험을 감수하는 행위지만, 적절히 성공시킬 경우 더 큰 보상(승리)으로 이어지는 구조를 띠고 있다 [7, 9, 10].
|
||||
### 매 elixir economy 의 base
|
||||
- **Regen rate**: 매 1 elixir / 2.8s (normal) → 매 / 1.4s (double) → 매 / 0.93s (triple, overtime).
|
||||
- **Cap**: 매 10 elixir 의 hard ceiling — 매 hoarding 의 prevent.
|
||||
- **Cost band**: 매 1 (Skeletons) ~ 매 9 (Three Musketeers).
|
||||
|
||||
* **콘텐츠 재사용을 통한 효율적인 밸런싱 (Content Reuse and Tuning):**
|
||||
클래시 로얄은 기존 유닛 코드를 경제적으로 재사용 및 변형하여 전략적 선택지를 늘리고 밸런싱 난이도를 완화했다 [11-13].
|
||||
* 1코스트 '스켈레톤(4기)' 카드는 시선 끌기나 방어용으로 쓰이지만, 3코스트 '스켈레톤 군대(14기)' 카드는 강력한 공격 유닛을 카운터치는 높은 엘릭서 효율성을 자랑한다 (단, 광역 마법에 취약함) [14, 15].
|
||||
* 이를 통해 플레이어는 유닛의 속성과 비용의 상관관계를 쉽게 파악할 수 있다 [13]. 또한, 밸런스 조정 시 복잡한 수치 계산 대신 단순히 스켈레톤 군대의 스켈레톤 소환 수를 1기 줄이는 등의 직관적인 방식으로 경제적 가치를 조정(너프)할 수 있었다 [13].
|
||||
### 매 stat budget formula (approx.)
|
||||
- **HP budget**: 매 cost × ~360 HP (King Tower level 11 baseline).
|
||||
- **DPS budget**: 매 cost × ~75 DPS.
|
||||
- **Range / speed / splash** 의 modifier 로 매 ±20~30% 의 adjustment.
|
||||
|
||||
* **성장 및 업그레이드 비용의 표준화 (Standardization of Upgrade Costs):**
|
||||
수천만 명의 플레이어 사이에서 카드 간의 거시적 경제 밸런스를 유지하기 위해 업그레이드 수치를 표준화했다 [2]. 모든 카드는 희귀도와 무관하게 레벨당 성장 수치(체력, 데미지) 상승 비율이 일정하며, 최고 레벨 달성을 위해 요구되는 인게임 재화(골드) 비용도 유사하게 설계되어 있어 게임 전체의 밸런싱 난이도를 대폭 낮추었다 [2].
|
||||
### 매 archetype 의 cost distribution
|
||||
- **Cycle deck**: 매 평균 elixir 2.6~3.0 (Hog Cycle, X-Bow 2.9).
|
||||
- **Mid-range**: 매 3.4~3.8 (Royal Giant, Lavaloon).
|
||||
- **Heavy**: 매 4.0+ (Three Musketeers, Mega Knight beatdown).
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[게임 경제 설계(Game Economy Design)]], [[위험과 보상 구조(Risks and Rewards Structure)]]
|
||||
- **Projects/Contexts:** [[단위 경제학(Unit Economics) 및 게임 밸런싱 모델]]
|
||||
- **Contradictions/Notes:** 소스에는 플레이어가 실제 현금을 지불하여 획득하는 재화(IAP)의 인플레이션이 인게임 플레이 시 적용되는 '엘릭서' 밸런싱에 물리적으로 어떤 직접적 영향을 미치는지에 대해서는 소스에 관련 정보가 부족합니다.
|
||||
### 매 positive trade
|
||||
- **Defender 1 elixir 우위**: 매 ideal interaction.
|
||||
- **Negative trade 2+ elixir**: 매 punishable mistake.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
## 💻 패턴
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
### Average elixir cost
|
||||
```python
|
||||
def avg_cost(deck):
|
||||
return sum(c.cost for c in deck) / len(deck)
|
||||
|
||||
> 클래시 로얄의 카드 비용은 1~9 엘릭서로, 비용·강도의 페이오프 곡선이 메타와 게임 페이스를 동시에 결정한다.
|
||||
# Hog Cycle: Hog(4) Skel(1) IceSpirit(1) Cannon(3) Log(2) Musk(4) IceGolem(2) Fireball(4) → 2.6
|
||||
```
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### Stat budget audit
|
||||
```python
|
||||
def hp_budget_check(card):
|
||||
expected = card.cost * 360
|
||||
return abs(card.hp - expected) / expected < 0.30
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
# Knight: cost=3, hp≈1300 → ~1080 expected → +20% (ok, melee tank role)
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Trade simulator
|
||||
```python
|
||||
def trade(attacker, defender):
|
||||
a, d = attacker.copy(), defender.copy()
|
||||
while a.hp > 0 and d.hp > 0:
|
||||
d.hp -= a.dps
|
||||
a.hp -= d.dps
|
||||
survivor = a if a.hp > 0 else d
|
||||
return survivor, attacker.cost - defender.cost # elixir delta
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Counter ratio table
|
||||
```python
|
||||
COUNTER = {
|
||||
('Goblin Barrel', 'Log'): {'win_rate': 0.95, 'elixir_gain': +1},
|
||||
('Hog Rider', 'Cannon'): {'win_rate': 0.65, 'elixir_gain': +1},
|
||||
('Three Musketeers', 'Fireball+Log'): {'win_rate': 0.85, 'elixir_gain': +3},
|
||||
}
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Win-rate based balance pass
|
||||
```python
|
||||
# Supercell-style: nerf if win_rate > 53% across ladder
|
||||
def needs_nerf(card, telemetry):
|
||||
return telemetry[card].win_rate > 0.53 and telemetry[card].use_rate > 0.05
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
def needs_buff(card, telemetry):
|
||||
return telemetry[card].win_rate < 0.47 and telemetry[card].use_rate < 0.02
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Evolution cost amortization (2024+)
|
||||
```python
|
||||
# Evo unlocks after 2 cycles → effective cost = base + (evo_advantage / cycles_to_evo)
|
||||
def effective_cost(card):
|
||||
if not card.has_evolution: return card.cost
|
||||
return card.cost + (card.evo_power_delta / 2.5)
|
||||
```
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
### Champion 1-per-deck constraint (2021+)
|
||||
```python
|
||||
def deck_valid(deck):
|
||||
champions = [c for c in deck if c.is_champion]
|
||||
return len(champions) <= 1
|
||||
```
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 new card design | 매 stat budget formula → 매 baseline → 매 unique modifier |
|
||||
| 매 monthly balance | 매 win-rate ±3% 의 threshold + 매 use-rate floor |
|
||||
| 매 evolution rebalance | 매 cycle-amortized effective cost |
|
||||
| 매 dominant deck | 매 keystone card 의 -5% HP / damage (small touch) |
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
**기본값**: 매 win-rate 의 47-53% band 의 maintain + 매 use-rate >2% 의 ensure (otherwise dead card).
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🔗 Graph
|
||||
- 부모: [[클래시 로얄(Clash Royale)]]
|
||||
- 변형: [[클래시 로얄(Clash Royale)의 대칭성과 밸런싱]]
|
||||
- 응용: [[데이터 기반 밸런싱]] · [[Mobile PvP Balancing]]
|
||||
- Adjacent: [[Supercell]] · [[라이브옵스(LiveOps)]] · [[Machinations]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 patch note 의 draft, 매 telemetry 의 dominant-deck summary, 매 new card concept 의 stat-budget sanity check.
|
||||
**언제 X**: 매 final balance number — 매 ladder telemetry 의 empirical 의 우월.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Stat-only balance**: 매 mechanic interaction 의 무시 → 매 unintended combo (e.g. Sparky + Mega Knight 2017).
|
||||
- **Use-rate only**: 매 win-rate 의 무시 → 매 strong-but-niche card 의 over-buff.
|
||||
- **Big-swing nerf**: 매 -20% damage 의 single change → 매 dead card.
|
||||
- **Evo-blind budget**: 매 evolution power 의 cost 의 amortize 안 함 → 매 P2W perception.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Supercell community manager Drew dev posts, Statsroyale.com 2024-2026 ladder data, Reddit r/ClashRoyale balance announcements).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — elixir economy + budget formula + 7 patterns |
|
||||
|
||||
@@ -1,68 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-하이브리드-캐주얼-hybrid-casual
|
||||
title: 하이브리드 캐주얼 (Hybrid Casual)
|
||||
category: General Knowledge
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: hybrid-casual
|
||||
duplicate_of: "[[Hybrid Casual]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, mobile-games, hybrid-casual]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 하이브리드 캐주얼 (Hybrid Casual)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
하이브리드 캐주얼(Hybrid Casual)은 하이퍼 캐주얼 게임의 직관적이고 단순한 핵심 플레이 방식에 미드코어 게임의 심층적인 진행 시스템과 메타 레이어를 결합한 게임 장르이다 [1-3]. 이 장르는 플레이어의 참여도와 장기 잔존율(Retention)을 높이기 위해 캐릭터 커스터마이징이나 가벼운 내러티브 등을 도입한다 [2, 3]. 또한, 인앱 광고(IAA)와 인앱 구매(IAP)를 혼합한 하이브리드 수익화 모델을 통해 사용자당 평균 매출(ARPU)과 고객 평생 가치(LTV)를 극대화하는 것을 목표로 한다 [3-5].
|
||||
> **이 문서는 [[Hybrid Casual]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **장르의 진화와 배경:**
|
||||
단순함만을 내세우던 순수 하이퍼 캐주얼 게임은 모바일 게임 장르 중 30일 잔존율이 가장 낮다는 치명적인 한계에 직면했다 [4]. 이에 따라 2025년과 2026년 모바일 시장에서는 플레이어를 첫 세션 이후에도 지속적으로 몰입하게 만들기 위해, 기존의 쉽고 빠른 플레이 감각(Pick-up-and-play)은 유지하면서 진행 시스템, 꾸미기 요소, 내러티브와 같은 메타 레이어(Meta Layers)를 추가한 하이브리드 캐주얼이 새로운 표준으로 자리 잡았다 [1-3, 5, 6].
|
||||
* **수익화 모델 (Hybrid Monetization):**
|
||||
하이브리드 캐주얼은 기존의 전적인 광고(IAA) 의존에서 벗어나 인앱 구매(IAP)를 신중하게 혼합한다 [4]. 연구에 따르면 이러한 하이브리드 수익화 모델을 적용한 하이퍼 캐주얼 타이틀은 광고만 있는 경우에 비해 ARPU가 28% 더 높은 것으로 나타났다 [7]. 특히 플레이어의 87%가 긍정적으로 반응하는 보상형 비디오 광고(Rewarded Video)를 핵심 기반으로 하되, 플레이어의 참여가 깊어짐에 따라 장식용 업그레이드, 부스터 팩, 심지어 구독 모델까지 효과적으로 결합한다 [3, 7].
|
||||
* **디자인 전략 및 융합적 게임플레이:**
|
||||
성공적인 하이브리드 캐주얼 게임은 견고한 핵심 게임플레이(Core Gameplay) 위에 수익화 지점을 자연스럽게 배치한다 [6]. 예를 들어, '매직 소트(Magic Sort)'는 물 정렬 퍼즐이라는 캐주얼한 포맷에 가파른 난이도 곡선과 IAP 중심의 수익화, 그리고 라이브옵스(Live-ops) 프레임워크를 성공적으로 결합한 사례다 [8]. 또한 최근에는 '카피바라 고([[Capybara GO!]])'나 '러브 앤 딥스페이스([[Love and Deepspace]])'처럼 로그라이트, 방치형 RPG, 인터랙티브 스토리 등 미드코어 메커니즘을 캐주얼 구조에 결합하는 융합적 트렌드가 게임 경제 성장의 주요 동력으로 작용하고 있다 [9, 10].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Hybrid Casual]] (canonical)
|
||||
- Adjacent: [[Free-to-Play]] · [[LiveOps]] · [[Hyper Casual]]
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[인앱 구매 (IAP)]], [[인앱 광고 (IAA)]], [[고객 평생 가치 (LTV)]], [[잔존율 (Retention)]], [[ARPU (Average Revenue Per User)]], [[미드코어 (Midcore)]], [[메타 레이어 (Meta Layer)]]
|
||||
- **Projects/Contexts:** [[Magic Sort]], [[Capybara GO!]], [[Love and Deepspace]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 현재 시장에서는 "순수한 하이퍼 캐주얼은 사실상 더 이상 존재하지 않는다"고 평가될 정도로 변화가 가속화되고 있으며, 단순한 게임성에만 의존하기보다는 플레이어가 장기적으로 머무를 수 있는 깊이 있는 구조를 만드는 것이 수익성 달성에 필수적이라고 강조한다 [1, 4].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,57 +2,27 @@
|
||||
id: wiki-2026-0508-환영합니다
|
||||
title: 환영합니다
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-BD84CA]
|
||||
duplicate_of: none
|
||||
status: duplicate
|
||||
canonical_id: readme
|
||||
duplicate_of: "[[README]]"
|
||||
aliases: []
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 환영합니다"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
verification_status: redirected
|
||||
tags: [duplicate, welcome, meta]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# [[환영합니다]]
|
||||
# 환영합니다
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
> **이 문서는 [[README]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 🔗 Graph
|
||||
- 부모: [[README]] (canonical)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Raw Source: [[00_Raw/2026-04-20/환영합니다!.md]]
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
Reference in New Issue
Block a user