docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
This commit is contained in:
@@ -0,0 +1,102 @@
|
||||
---
|
||||
id: wiki-2026-0507-009
|
||||
title: AI 이미지 생성 워크플로우
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-009, AI Image Generation Workflow, 이미지 생성 워크플로우, AI 이미지 파이프라인, DALL-E 3, Midjourney, Stable Diffusion]
|
||||
duplicate_of: none
|
||||
source_trust_level: B
|
||||
confidence_score: 1.0
|
||||
tags: [AI, Image Generation, Workflow, Midjourney, Stable Diffusion, DALL-E 3]
|
||||
raw_sources: [직접 입력]
|
||||
last_reinforced: 2026-05-07
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# AI_이미지_생성_워크플로우
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> AI 이미지 생성은 단판 승부가 아닌, '초기 시안 탐색 -> 반복적 정교화 -> 부분 수정 및 확장'으로 이어지는 점진적이고 계층적인 워크플로우의 결과물이다. 모델마다 다른 언어적 이해도와 기술적 매개변수를 정확히 활용하는 것이 프로페셔널 생성의 핵심이다.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 생성의 80%는 핵심 피사체와 구도를 잡는 초기 프롬프트에서 결정되며, 나머지 20%의 완성도는 부정 프롬프트 제어와 인페인팅/아웃페인팅 기술을 통한 미세 조정에서 완성된다. DALL-E 3는 자연어 설명 중심, Midjourney/SD는 기술적 매개변수 중심의 전략을 취한다.
|
||||
|
||||
**세부 내용:**
|
||||
- **모델별 특화 전략:**
|
||||
- **DALL-E 3:**
|
||||
- GPT-4 기반의 고도화된 자연어 이해력을 활용.
|
||||
- 프롬프트를 문장 형태로 상세히 기술할수록 의도가 정확히 반영됨.
|
||||
- 의도가 왜곡될 경우 "Prompt exactly: [본래 프롬프트]"를 사용하여 모델의 자동 확장을 억제.
|
||||
- **Midjourney:**
|
||||
- `--ar` (가로세로비), `--stylize` (스타일 강도), `--chaos` (다양성) 등 매개변수 중심의 제어.
|
||||
- `--sref` (Style Reference) 및 `--cref` (Character Reference)를 통한 이미지 일관성 유지.
|
||||
- **Stable Diffusion (SD):**
|
||||
- LoRA, ControlNet 등 외부 모듈을 통한 결정론적(Deterministic) 제어.
|
||||
- 긍정/부정 프롬프트의 가중치 조절을 통한 픽셀 단위의 미세 조정.
|
||||
- **반복적 정교화 (Iterative Prompting):**
|
||||
- 넓고 모호한 지시에서 시작해 구체적인 지시로 좁혀나가는 방식.
|
||||
- 3~5번의 변형(Variation)을 통해 세부 사항을 다듬음.
|
||||
- **사후 편집 기술:**
|
||||
- **Inpainting (Vary Region):** 원본 맥락을 유지하며 특정 부분만 수정/추가.
|
||||
- **Outpainting (Zoom/Pan):** 캔버스 바깥 공간 확장 및 구도 재구성.
|
||||
- **계층적 프롬프트 구조:** 주체(Subject) -> 맥락(Context) -> 스타일(Style) -> 기술적 세부사항(Technical) 순의 논리적 배치.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 상업적 수준의 고품질 이미지를 생성해야 할 때.
|
||||
- 여러 장의 이미지를 하나의 프로젝트나 시리즈로 일관되게 제작해야 할 때.
|
||||
- 생성 결과가 마음에 들지 않아 처음부터 다시 시작하는 대신 효율적으로 수정하고 싶을 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 단순 재미 위주의 일회성 생성이며, 결과의 정밀도가 중요하지 않을 때.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **모델 선택:** 의도가 복잡하면 DALL-E 3, 미적 퀄리티와 일관성이 중요하면 Midjourney, 정밀 제어가 필요하면 SD 선택.
|
||||
2. **시안 탐색:** 간결한 프롬프트로 4~8개의 초기 시안 생성.
|
||||
3. **선택 및 변형:** 가장 나은 시안을 골라 세부 키워드 추가 및 매개변수 조절.
|
||||
4. **결함 제거:** 부정 프롬프트를 사용하여 시각적 결함 차단 (SD/Midjourney 필수).
|
||||
5. **최종 리터칭:** 인페인팅/아웃페인팅으로 특정 부위 보정 및 구도 확장.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- 모델마다 부정어 처리 능력이 다르므로(SD는 강력, DALL-E 3는 취약), 플랫폼 특성에 맞는 전략 선택이 필수적임.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** B
|
||||
- **검토 이유:** 해당 없음
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[AI Image Generation Workflow (canonical)]], [[DALL-E 3]], [[DALL-E 3 대화형 프롬프트 생성]], [[AI 이미지 생성 도구 및 매개변수]], [[AI 이미지 생성 파이프라인]] 등
|
||||
- **처리 방식:** UPDATE
|
||||
- **처리 이유:** 이미지 생성 프로세스와 관련된 중복 문서들을 통합하여 DALL-E 3까지 아우르는 하나의 완성된 파이프라인 가이드로 강화함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 단순 생성을 넘어 '드래프트-업스케일-편집'으로 이어지는 전문가용 워크플로우를 표준으로 설정.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** , [[미드저니_매개변수_제어]]
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | DALL-E 3 및 도구별 상세 파라미터 활용법 통합 업데이트 | UPDATE | B |
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: wiki-2026-0508-cfg-스케일-제어
|
||||
title: CFG 스케일 제어
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: wiki-2026-0508-cfg-scale-control
|
||||
duplicate_of: "[[CFG Scale Control]]"
|
||||
aliases: []
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, diffusion, cfg, image-generation]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# CFG 스케일 제어
|
||||
|
||||
> **이 문서는 [[CFG Scale Control]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 핵심 요약
|
||||
- 매 Classifier-Free Guidance scale (w) 의 prompt adherence vs diversity 의 trade-off.
|
||||
- 매 SD 1.5 ~7, SDXL ~5, FLUX 의 distilled (CFG=1).
|
||||
- 매 dynamic CFG, CFG rescale, perturbed-attention guidance 의 modern variants.
|
||||
|
||||
## 🔗 Graph
|
||||
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
id: wiki-moc-comfyui
|
||||
title: ComfyUI
|
||||
category: 10_Wiki/Topics
|
||||
status: moc
|
||||
aliases: [Comfyui]
|
||||
tags: [moc, index]
|
||||
last_reinforced: 2026-05-20
|
||||
---
|
||||
|
||||
# ComfyUI
|
||||
|
||||
> **ComfyUI** 카테고리 목차(MOC). `Comfyui/` 의 토픽 문서 48개. 자동 생성 인덱스 — redirect/중복 문서는 제외.
|
||||
|
||||
## 📚 토픽 (48)
|
||||
|
||||
- [[API Format]]
|
||||
- [[API Format (workflow_api.json)]]
|
||||
- [[API JSON]]
|
||||
- [[Comfy CLI]]
|
||||
- [[Comfy GPT]]
|
||||
- [[ComfyUI API]]
|
||||
- [[ComfyUI Backend Engine]]
|
||||
- [[ComfyUI Manager]]
|
||||
- [[ComfyUI Workflow Extractor]]
|
||||
- [[ComfyUI Workflow JSON]]
|
||||
- [[ComfyUI Workflow JSON Generation and Serialization]]
|
||||
- [[Comfyui workflow json 생성 방법]]
|
||||
- [[ComfyUI Workspace Manager]]
|
||||
- [[ComfyUI-Manager]]
|
||||
- [[ComfyUI-to-Python-Extension]]
|
||||
- [[ComfyUI-WorkflowGenerator]]
|
||||
- [[Custom Node Dependency Management]]
|
||||
- [[Custom Node Registry]]
|
||||
- [[Custom Nodes]]
|
||||
- [[Directed Acyclic Graph (DAG)]]
|
||||
- [[Execution Model Inversion]]
|
||||
- [[ExecutionCache]]
|
||||
- [[exiftool]]
|
||||
- [[Frontend Format (workflow.json)]]
|
||||
- [[Generative AI Pipeline]]
|
||||
- [[JSON Schema v1.0]]
|
||||
- [[Lazy Evaluation in Graph Theory]]
|
||||
- [[Litegraph]]
|
||||
- [[Litegraph Standard]]
|
||||
- [[Metadata Forensics]]
|
||||
- [[Metadata Stripping]]
|
||||
- [[Model Hashing]]
|
||||
- [[Model Hashing (SHA-256)]]
|
||||
- [[Natural Language to Workflow Generation]]
|
||||
- [[PNG Metadata Chunks]]
|
||||
- [[Serialization Formats (Frontend vs API)]]
|
||||
- [[Serverless Deployment]]
|
||||
- [[Steganography in Generative AI]]
|
||||
- [[Subgraph]]
|
||||
- [[Visual Programming Environment]]
|
||||
- [[Workflow API JSON]]
|
||||
- [[Workflow API JSON (Backend Format)]]
|
||||
- [[Workflow JSON]]
|
||||
- [[Workflow JSON v1.0 Schema]]
|
||||
- [[Workflow.json (Frontend Format)]]
|
||||
- [[workflow_api.json]]
|
||||
- [[WorkflowExecutor]]
|
||||
- [[Workspace Packaging]]
|
||||
|
||||
## 🕓 변경 이력
|
||||
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-20 | MOC 페이지 신규 생성 (링크명 정규화) |
|
||||
@@ -0,0 +1,119 @@
|
||||
---
|
||||
id: wiki-2026-0508-modern-web-rendering-and-optimiz
|
||||
title: Modern Web Rendering and Optimization
|
||||
category: Frontend
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [modern_web_rendering_and_optimization]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [- rendering-strategies - web-performance - hydration - react - core-web-vitals]
|
||||
raw_sources: [- 10_Wiki/Topics/AI_and_ML/CSR vs SSR vs SSG.md - 10_Wiki/Topics/AI_and_ML/서버 사이드 렌더링(SSR)과 하이드레이션(Hydration).md - 10_Wiki/Topics/AI_and_ML/Static_Site_Generation_SSG.md - 10_Wiki/Topics/AI_and_ML/Virtual_DOM과_Reconciliation.md - 10_Wiki/Topics/AI_and_ML/Server Components.md - 10_Wiki/Topics/AI_and_ML/Interaction-to-Next-Paint-INP.md - 10_Wiki/Topics/AI_and_ML/Largest-Contentful-Paint-LCP.md]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 현대적 웹 렌더링 및 최적화 (Modern Web Rendering and Optimization)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "언제, 어디서 HTML을 생성할 것인가?" 웹 렌더링 전략은 초기 로드 성능(FCP/LCP), 상호작용성(TTI/INP), 그리고 검색 엔진 최적화(SEO) 사이의 트레이드오프를 관리하는 엔지니어링 의사결정의 집합입니다.
|
||||
|
||||
## 📖 핵심 내용 (Core Content)
|
||||
|
||||
### 1. 렌더링 전략 (Rendering Strategies)
|
||||
* **CSR (Client-Side Rendering)**: 브라우저에서 자바스크립트로 UI를 동적 구축. 상호작용은 풍부하나 초기 로드가 느리고 SEO에 불리함.
|
||||
* **SSR (Server-Side Rendering)**: 요청마다 서버에서 HTML 생성. 빠른 콘텐츠 노출(FCP)과 우수한 SEO를 제공하지만, 서버 부하와 하이드레이션 지연이 발생함.
|
||||
* **SSG (Static Site Generation)**: 빌드 시점에 HTML 미리 생성. CDN 배포를 통해 압도적인 로딩 속도를 제공하나 실시간 데이터 업데이트가 어려움.
|
||||
* **ISR (Incremental Static Regeneration)**: SSG의 장점을 유지하면서 런타임에 정적 페이지를 부분적으로 업데이트하는 하이브리드 전략.
|
||||
|
||||
### 2. 하이드레이션 및 상호작용 (Hydration & Interaction)
|
||||
* **하이드레이션(Hydration)**: 서버에서 받은 정적 HTML에 자바스크립트 이벤트 리스너와 상태를 결합하여 생명을 불어넣는 과정.
|
||||
* **Uncanny Valley**: 화면은 보이지만 상호작용이 되지 않는 상태. TTI(Time to Interactive) 지표와 직결됨.
|
||||
* **최적화 기법**: 선택적 하이드레이션, 스트리밍 SSR, 아일랜드 아키텍처(Island Architecture), React 서버 컴포넌트(RSC)를 통한 JS 번들 최소화.
|
||||
|
||||
### 3. 가상 DOM과 재조정 (Virtual DOM & Reconciliation)
|
||||
* **Virtual DOM**: 실제 DOM의 가벼운 복사본을 메모리에 유지하여 최소한의 변경 사항만 실제 DOM에 반영하는 기술.
|
||||
* **Diffing Algorithm**: 이전 트리와 새 트리를 비교하여 O(n) 복잡도로 변경점을 찾아냄. 'Key' 속성을 통한 효율적인 리스트 렌더링이 핵심.
|
||||
|
||||
### 4. 핵심 성능 지표 (Core Web Vitals)
|
||||
* **LCP (Largest Contentful Paint)**: 가장 큰 콘텐츠가 보이는 시점 (로딩 성능).
|
||||
* **INP (Interaction to Next Paint)**: 사용자의 입력에 대한 응답 지연 시간 (상호작용성, FID를 대체하는 2024년 이후 표준).
|
||||
* **CLS (Cumulative Layout Shift)**: 레이아웃이 예기치 않게 흔들리는 정도 (시각적 안정성).
|
||||
|
||||
## ⚠️ 트레이드오프 및 주의사항 (Trade-offs)
|
||||
* **SSR vs 하이드레이션**: SSR은 시각적 로딩은 빠르지만(FCP), 대규모 자바스크립트 실행으로 인해 상호작용(TTI)이 지연될 수 있습니다.
|
||||
* **RSC의 제약**: 서버 컴포넌트에서는 `useState`, `useEffect`와 같은 클라이언트 훅을 사용할 수 없으므로, 데이터 페칭(서버)과 상호작용(클라이언트)의 경계를 명확히 설계해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics**: [[CSS_Architecture_and_Styling]], [[Web_Performance_Optimization]], [[Next.js]]
|
||||
- **Next Step**: Partial Hydration(부분 하이드레이션) 및 Resumability(재개 가능성, Qwik 등) 패러다임 검토.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
id: wiki-2026-0508-prompt-engineering
|
||||
title: Prompt Engineering
|
||||
category: AI_and_ML
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [prompt_engineering]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [- prompt_engineering - llm - image_generation - ai_optimization - chain-of-thought - few-shot - midjourney - stable_diffusion]
|
||||
raw_sources: [- AI_and_ML/Prompt_Engineering.md - AI_and_ML/Prompt-Engineering-Foundations.md - AI_and_ML/Prompt_Structure.md - AI_이미지_생성_및_프롬프트_엔지니어링_워크플로우.md - AI/Prompt-Engineering.md]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 프롬프트 엔지니어링 (Prompt Engineering)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
프롬프트 엔지니어링은 인공지능 모델(LLM 및 이미지 생성 모델)로부터 최적의 결과물을 도출하기 위해 입력값(Prompt)을 전략적으로 설계, 최적화 및 프로그래밍하는 기술 체계입니다 [1]. 단순히 '말을 잘하는 법'을 넘어, 모델의 추론 성능을 극대화하기 위한 구조적 지시어 설계와 반복적인 실험(Iterative Refinement)을 통해 잠재된 확률의 바다에서 최적의 해답을 인양하는 현대 지능 제어의 핵심 인터페이스 역할을 합니다 [4, 12].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
### 1. 프롬프트 엔지니어링의 기초 (Foundations)
|
||||
모델에게 사고의 방향을 제시하는 가장 기본적인 기법들입니다.
|
||||
* **Zero-shot**: 예시 없이 직접적인 지시만 내리는 방식.
|
||||
* **Few-shot**: 몇 개의 입출력 예시를 제공하여 모델이 패턴을 학습하게 하는 방식 [18].
|
||||
* **Chain of Thought (CoT)**: "단계별로 생각해보자"와 같은 문구로 모델의 논리적 추론 과정을 명시적으로 유도하는 기법 [19].
|
||||
* **Persona Prompting**: 모델에게 특정 전문가 역할을 부여하여 출력의 전문성을 높입니다 (예: "너는 20년 경력의 시니어 개발자야") [20].
|
||||
* **System Prompt**: 모델의 전반적인 페르소나, 행동 규칙, 제약 사항을 정의하는 최상위 지시어 [20].
|
||||
|
||||
### 2. 핵심 계층 구조 (Hierarchical Structure)
|
||||
인간의 의도를 AI가 해석 가능한 시각적/언어적 기호로 번역하기 위한 5단계 레이어 패턴입니다 [1, 2, 15].
|
||||
1. **주체 (Subject)**: 중심 초점. 막연한 명사보다 구체적인 특징이나 행동을 포함 (예: "늙은 남자" -> "풍파를 겪은 손을 가진 어부") [6, 20].
|
||||
2. **환경 및 맥락 (Environment/Context)**: 주체가 존재하는 배경, 시간적/공간적 설정 및 서사적 맥락 [9, 21].
|
||||
3. **매체 및 스타일 (Medium & Style)**: 사진, 유화, 3D 렌더링 등 예술적 형식이나 특정 화풍 정의 [7, 22].
|
||||
4. **조명 및 카메라 구도 (Lighting & Composition)**: 림 라이팅, 골든 아워, 85mm 렌즈 등 기술적 연출 [11, 23].
|
||||
5. **기술 매개변수 (Parameters)**: 모델 고유의 명령어를 통한 시스템적 제어 (예: Midjourney의 `--ar`, `--s`) [16, 24].
|
||||
|
||||
### 3. 고도화된 이미지 생성 기술 (Advanced Image Generation)
|
||||
단순 생성을 넘어 일관성과 정밀도를 확보하기 위한 기술입니다.
|
||||
* **참조 제어 (References)**:
|
||||
* **Character Reference (--cref)**: 특정 캐릭터의 외형을 유지하며 다른 구도/상황 생성 [39].
|
||||
* **Style Reference (--sref)**: 특정 이미지의 화풍, 색감, 질감을 복제 [40].
|
||||
* **구도 제어 (ControlNet)**: 스케치, 포즈, 깊이 정보를 입력하여 이미지의 구조를 픽셀 단위로 제어 [45].
|
||||
* **LoRA (Low-Rank Adaptation)**: 특정 인물, 스타일, 사물을 학습한 저용량 가중치 파일을 사용하여 일관성 확보 [46].
|
||||
|
||||
### 4. 반복적 정교화 워크플로우 (Iterative Refinement)
|
||||
한 번에 완벽한 결과를 얻기보다 점진적으로 다듬어가는 협업 과정입니다 [4].
|
||||
* **Start Simple**: 핵심 요소만 담은 간결한 지시어(15~50단어)로 뼈대를 구축합니다 [7, 31].
|
||||
* **Generate-Inspect-Adjust**: 결과를 평가하고 한 번에 하나의 요소만 변경하여 모델의 반응을 파악합니다 [11, 12].
|
||||
* **Vary Region / Inpainting**: 이미지의 전체 분위기는 유지하면서 특정 부분만 수정합니다 [16].
|
||||
|
||||
### 5. 플랫폼별 최적화 전략 (Platform Optimization)
|
||||
* **미드저니 (Midjourney)**: `[주체] [배경] [스타일] [매개변수]` 공식 중심. 자연어보다는 시각적 키워드 블록에 강점이 있습니다 [43].
|
||||
* **DALL-E 3**: 완전한 자연어 문장 형태의 서술에 최적화되어 있습니다 [44, 69].
|
||||
* **스테이블 디퓨전 (Stable Diffusion)**: 쉼표로 구분된 태그 중심 문법과 가중치 조절, 전용 부정 프롬프트 활용이 핵심입니다 [45, 69].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **자연어 vs 태그**: 모델의 텍스트 인코더 특성에 따라 문장형(DALL-E) 혹은 키워드형(SD)을 선택해야 합니다.
|
||||
* **주의력 분산 (Attention Dilution)**: 과도한 디테일은 모델의 주의력을 분산시켜 핵심 주제의 품질을 저하시킬 수 있습니다 [54].
|
||||
* **부정형의 역설**: 일부 모델에서 "No dots" 입력 시 오히려 "dots" 토큰에 주목하여 점을 더 많이 그리는 현상이 발생할 수 있습니다 [55].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics**: [[P-Reinforce|P-Reinforce 시스템]], [[Backend/Indirect Prompt Injection|프롬프트 인젝션 보안]]
|
||||
- **Projects/Contexts**: ConnectAI 프롬프트 라이브러리, 에이전트 워크플로우 자동화
|
||||
- **Contradictions/Notes**: "Photorealistic" 같은 단어보다 실제 카메라 사양(렌즈, 셔터스피드)을 명시하는 것이 질감 제어에 더 효과적입니다 [60].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
@@ -0,0 +1,115 @@
|
||||
---
|
||||
id: wiki-2026-0508-web-performance-optimization
|
||||
title: Web Performance Optimization
|
||||
category: Web
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [web_performance_optimization]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [- web-performance - web-vitals - lcp - inp - cls - browser-rendering]
|
||||
raw_sources: [- AI/Core-Web-Vitals.md - AI/Interaction to Next Paint (INP).md - AI/Largest Contentful Paint (LCP).md - AI/Long Animation Frames API.md - AI/PageSpeed Insights.md - AI/Soft Navigation.md]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 웹 성능 최적화 및 Web Vitals (Web Performance & Web Vitals)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "사용자 경험의 계량화: 단순히 페이지가 빨리 뜨는 것을 넘어, 로딩(LCP), 반응성(INP), 시각적 안정성(CLS)을 측정하여 사용자가 체감하는 '쾌적함'을 숫자로 관리하는 전략."
|
||||
|
||||
## 📖 핵심 내용 (Core Content)
|
||||
|
||||
### 1. Core Web Vitals (핵심 웹 지표)
|
||||
구글이 사용자 경험을 평가하기 위해 제시한 3대 지표입니다.
|
||||
* **LCP (Largest Contentful Paint)**: 가장 큰 콘텐츠(이미지, 텍스트 블록 등)가 렌더링되는 시점. **로딩 성능**을 측정합니다. (2.5초 이내 권장)
|
||||
* **CLS (Cumulative Layout Shift)**: 페이지 로드 중 예기치 않은 레이아웃 이동이 발생하는 정도. **시각적 안정성**을 측정합니다. (0.1 이하 권장)
|
||||
* **INP (Interaction to Next Paint)**: 사용자의 클릭, 탭, 키보드 입력에 대해 브라우저가 다음 프레임을 그릴 때까지의 시간. **반응성**을 측정합니다. (FID를 대체하는 최신 지표)
|
||||
|
||||
### 2. 브라우저 렌더링 최적화
|
||||
* **Main Thread 관리**: JavaScript 실행 시간이 길어지면 메인 스레드가 차단되어 반응성이 저하됩니다. **Long Tasks**를 분할하거나 Web Workers를 활용해야 합니다.
|
||||
* **Layout & Paint**: 불필요한 DOM 변경과 리플로우(Reflow)를 방지하고, GPU 가속(transform, opacity)을 활용하여 부드러운 애니메이션을 구현합니다.
|
||||
* **Long Animation Frames (LoAF) API**: 기존의 Long Tasks API보다 더 정밀하게 프레임 지연의 원인을 추적할 수 있는 최신 API입니다.
|
||||
|
||||
### 3. 도구 및 방법론
|
||||
* **PageSpeed Insights & Lighthouse**: 웹 페이지의 성능 점수와 구체적인 개선 가이드를 제공합니다.
|
||||
* **Chrome DevTools Performance Tab**: 프레임 드랍, 메인 스레드 점유율, 네트워크 워크플로우를 타임라인으로 분석합니다.
|
||||
* **Soft Navigation**: SPA(Single Page Application)에서 URL이 바뀌지만 전체 페이지 로드가 없는 경우의 성능을 측정하는 새로운 지표입니다.
|
||||
|
||||
## ⚠️ 트레이드오프 및 주의사항 (Trade-offs)
|
||||
* **점수 vs 실제 경험**: Lighthouse 점수가 높더라도 실제 사용자가 느끼는 환경(네트워크, 디바이스 성능)에 따라 체감 성능은 다를 수 있으므로 **Field Data(CrUX)**를 확인해야 합니다.
|
||||
* **최적화 과잉**: 과도한 이미지 압축이나 기능 제한은 사용자 경험(UX)의 질을 오히려 떨어뜨릴 수 있습니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics**: [[Performance_Profiling_and_Memory]], [[프론트엔드 및 UIUX 표준|Frontend-Architecture]], [[Core Web Vitals Optimization (INP, LCP, CLS)|Core-Web-Vitals]], [[SEO]]
|
||||
- **Next Step**: HTTP/3 도입 및 에지 컴퓨팅(Edge Computing)을 통한 응답 속도 극대화 전략 수립.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,125 @@
|
||||
---
|
||||
id: wiki-2026-0507-107
|
||||
title: 그래픽스 및 시뮬레이션 엔지니어링
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-107, Graphics Engineering, Computer Graphics, Simulation, WebGPU, VFX, Rendering, Physics Engine, 그래픽스, 시뮬레이션]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [Graphics, Simulation, WebGPU, VFX, Rendering, Physics]
|
||||
raw_sources: [Chrome WebGPU 구현.md, Rendering Pipeline.md, Physics Simulation.md, Visual Effects.md]
|
||||
last_reinforced: 2026-05-07
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 그래픽스_및_시뮬레이션_엔지니어링
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "수학으로 현실을 그리다." 물리적 법칙을 코드로 시뮬레이션하고, 하드웨어 가속(GPU)을 통해 실시간으로 고품질 시각 정보를 렌더링하며, 디지털 세계의 상호작용을 사실적으로 구현하는 시각화 공학.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 현대 그래픽스 엔지니어링은 **'WebGPU와 같은 차세대 API'**를 통한 저수준 제어와 **'절차적 생성(Procedural Generation)'**을 통한 대규모 세계 구축을 지향한다. 렌더링 파이프라인의 최적화는 단순히 속도를 높이는 것을 넘어, 복잡한 물리 현상(빛, 유체 등)을 실시간으로 근사하는 고도의 수학적 모델링을 포함한다.
|
||||
|
||||
**세부 내용:**
|
||||
|
||||
### 1. 렌더링 API 및 하드웨어 가속
|
||||
- **WebGPU:** 최신 GPU 아키텍처를 웹에서 직접 제어할 수 있는 표준 API. WebGL 대비 오버헤드가 낮고 연산 성능(Compute Shader)이 뛰어남.
|
||||
- **렌더링 파이프라인:** 정점 처리(Vertex Processing), 래스터화(Rasterization), 프래그먼트 처리(Fragment Processing)의 고속 병렬 처리 과정.
|
||||
- **GPU 메모리 계층:** 레지스터, 공유 메모리, 글로벌 메모리 간의 데이터 전송 최적화가 성능의 핵심.
|
||||
|
||||
### 2. 시뮬레이션 및 물리 엔진
|
||||
- **물리 법칙 모델링:** 강체(Rigid Body), 연성체(Soft Body), 유체(Fluid) 시뮬레이션.
|
||||
- **충돌 감지 (Collision Detection):** 정교한 공간 분할 알고리즘(Octree, BVH)을 통한 실시간 상호작용 보장.
|
||||
- **절차적 생성:** 알고리즘(Noise functions 등)을 사용하여 지형, 식생, 도시 구조 등을 자동으로 생성하는 기법.
|
||||
|
||||
### 3. 시각 효과 (VFX) 및 애니메이션
|
||||
- **셰이더 프로그래밍 (HLSL/GLSL/WGSL):** 픽셀 단위의 광원 처리, 텍스처 매핑, 특수 효과 구현.
|
||||
- **모션 캡처 및 리타겟팅:** 실제 움직임을 디지털 캐릭터에 매핑하고 관절 구조에 맞게 보정하는 기술.
|
||||
- **파티클 시스템:** 불, 연기, 폭발 등 복잡한 시각 현상을 수만 개의 점 입자로 시뮬레이션.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 웹 기반의 고성능 3D 대시보드나 인터랙티브 시각화 도구를 개발할 때.
|
||||
- 게임 엔진의 렌더링 성능을 튜닝하거나 커스텀 셰이더 효과를 구현해야 할 때.
|
||||
- 물리 법칙이 적용된 시뮬레이션 환경(Digital Twin 등)을 구축할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 정적인 이미지나 텍스트 위주의 웹사이트 개발.
|
||||
- 고사양 그래픽 처리가 필요 없는 단순한 비즈니스 애플리케이션.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **기술 스택 선정:** 타겟 플랫폼과 성능 요구사항에 따라 WebGL, WebGPU 등 API 선정.
|
||||
2. **파이프라인 설계:** 렌더링 패스(Forward vs Deferred)와 셰이더 구조 설계.
|
||||
3. **최적화:** 드로우 콜(Draw Calls) 최소화 및 텍스처 압축, LOD(Level of Detail) 적용.
|
||||
4. **물리 결합:** 필요한 물리 연산의 정밀도를 설정하고 안정적인 시간 간격(Timestep) 확보.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **장치 호환성:** WebGPU 등 최신 기술은 모든 브라우저나 하드웨어에서 지원되지 않을 수 있으므로 폴백(Fallback) 전략 필요.
|
||||
- **수학적 복잡도:** 선형 대수학, 미적분학 등 고도의 수학적 지식이 요구됨.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** W3C WebGPU 표준, GPU Gems 등 그래픽스 공학의 권위 있는 자료를 기반으로 함.
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Chrome WebGPU Implementation]], [[GPU-Memory-Hierarchy]], [[Visual_Effects]], [[Physics & Simulation]], [[Motion-Capture-Retargeting]] 등 70여 개
|
||||
- **처리 방식:** MERGE & ARCHIVE
|
||||
- **처리 이유:** 시각화 기술과 시뮬레이션 물리 기술은 서로 밀접하게 연동되나 문서가 분산되어 있음. 이를 하나의 시각화 공학 표준으로 통합함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **레이 트레이싱 (Ray Tracing):** 전통적인 래스터화 방식에서 실시간 레이 트레이싱 기술로 패러다임이 전환되고 있음.
|
||||
- **AI 기반 렌더링:** DLSS 등 AI를 활용한 업스케일링 및 프레임 생성이 그래픽 성능 향상의 핵심 요소로 부상.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[데이터 사이언스 및 ML 엔지니어링]], [[현대적 웹 성능 및 사용자 경험 최적화]], [[게임 디자인 및 가상 경제 시스템]]
|
||||
- **Raw Source:** Graphics 및 Modeling 폴더 내 다수 파일
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 70개 이상의 그래픽스/시뮬레이션 관련 문서 통합 및 v3.0 규격 적용 | MERGE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
id: wiki-2026-0507-012
|
||||
title: 디퓨전 모델 작동 원리
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-012, Diffusion Models, 디퓨전 모델, 확산 모델]
|
||||
duplicate_of: none
|
||||
source_trust_level: B
|
||||
confidence_score: 1.0
|
||||
tags: [AI, Machine Learning, Diffusion Models, Generative AI, Image Generation]
|
||||
raw_sources: [직접 입력]
|
||||
last_reinforced: 2026-05-07
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# 디퓨전_모델_작동_원리
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 디퓨전 모델은 데이터에 노이즈를 섞는 과정을 학습한 뒤, 무작위 노이즈로부터 텍스트 조건에 맞춰 형태를 복원해가는 '역방향 확산'을 통해 고품질 이미지를 생성하는 아키텍처다.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 생성은 파괴(노이즈 추가)의 역과정이며, 이 반복적인 디노이징(Denoising) 단계 덕분에 GAN보다 학습이 안정적이고 프롬프트를 통한 세밀한 제어가 가능하다.
|
||||
|
||||
**세부 내용:**
|
||||
- **핵심 프로세스:**
|
||||
- **정방향 확산 (Forward Diffusion):** 원본 데이터에 가우시안 노이즈를 점진적으로 추가하여 완전한 노이즈로 변환하는 과정을 학습.
|
||||
- **역방향 확산 (Reverse Diffusion):** 무작위 노이즈에서 시작하여 학습된 데이터를 바탕으로 노이즈를 제거하며 의도한 형태를 복원.
|
||||
- **주요 특징:**
|
||||
- **안정성:** GAN(생성적 적대 신경망)에 비해 훈련 과정이 안정적이고 모드 붕괴(Mode Collapse) 위험이 적음.
|
||||
- **세밀한 제어:** 반복적인 생성 단계 덕분에 사용자가 중간 단계에서 개입하거나 매개변수(CFG, Seed 등)로 결과물을 조율하기 용이함.
|
||||
- **제약 사항:** 반복 연산으로 인해 컴퓨팅 리소스 소모가 크며, 생성 속도가 단판 승부 방식인 GAN보다 상대적으로 느림.
|
||||
- **플랫폼별 적용:**
|
||||
- **Midjourney/DALL-E:** 클라우드 기반, 뛰어난 예술적 해석력과 접근성.
|
||||
- **Stable Diffusion:** 오픈소스, 로컬 제어 및 무한한 커스텀 가능성 제공.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 이미지 생성 AI의 기술적 배경이나 작동 원리를 설명해야 할 때.
|
||||
- 생성 속도, 품질, 제어 가능성 사이의 트레이드오프를 분석할 때.
|
||||
- 미드저니의 `--stop`이나 스테이블 디퓨전의 `Sampling Steps`가 결과에 미치는 영향을 이해하고 싶을 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- GAN이나 VAE 등 확산 방식이 아닌 다른 생성 모델의 구체적 기술 사양이 필요한 경우.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **개념 이해:** 생성이 '노이즈에서 조각을 깎는 과정'임을 인식.
|
||||
2. **파라미터 조절:** 디노이징 단계(Steps)를 높여 디테일을 확보하거나, CFG를 통해 프롬프트 준수 강도를 조절.
|
||||
3. **플랫폼 선택:** 보안과 제어가 중요하면 로컬 SD, 심미적 결과가 중요하면 클라우드 모델 선택.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- 디퓨전 모델은 텍스트 이해도가 뛰어나지만, 수치적 계산이나 정교한 텍스트 렌더링(DALL-E 3 제외) 등에서는 여전히 한계가 있을 수 있음.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** B
|
||||
- **검토 이유:** 해당 없음
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Diffusion Models]], [[디퓨전 모델 (Diffusion Models)]], [[확산 모델 (Diffusion Models)]]
|
||||
- **처리 방식:** MERGE
|
||||
- **처리 이유:** 확산 모델과 관련된 이론적 정의와 플랫폼별 특성을 담은 3개 문서를 통합하여 기술적 깊이를 더함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 단순 이미지 생성을 넘어 '연산 자원 효율성'과 '로컬 제어의 복잡성' 문제를 함께 다룸.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[CFG_스케일_제어]], [[미드저니_매개변수_제어]]
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 3개 중복 문서를 통합 및 v3.0 규격 적용 | MERGE | B |
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
id: wiki-2026-0507-002
|
||||
title: 미드저니 매개변수 제어
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-002, Midjourney Parameters, 미드저니 매개변수, 미드저니 파라미터]
|
||||
duplicate_of: none
|
||||
source_trust_level: B
|
||||
confidence_score: 1.0
|
||||
tags: [Midjourney, Parameters, Prompt Engineering, V7]
|
||||
raw_sources: [직접 입력]
|
||||
last_reinforced: 2026-05-07
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# 미드저니_매개변수_제어
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 미드저니 매개변수는 텍스트로 표현하기 어려운 시각적 비율, 모델 버전, 예술적 개입 및 일관성을 정밀하게 제어하는 기술적 레버다.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 모델 버전이 올라갈수록(V6 -> V7) 단순 묘사보다 참조(Reference) 파라미터(`--cref`, `--oref`)의 비중이 커지며, 생성 속도와 비용을 최적화하는 옵션(`--draft`)이 강화된다.
|
||||
|
||||
**세부 내용:**
|
||||
- **기본 규칙:** 프롬프트 가장 뒤에 위치하며, `--`로 시작하고 앞에는 공백이 필요함.
|
||||
- **비율 및 모델:**
|
||||
- `--ar`: 종횡비 제어 (최신 모델 파노라마 지원 확대)
|
||||
- `--v`: 모델 버전 지정 (현재 V7 권장)
|
||||
- `--draft`: V7 전용, 10배 빠른 초기 시안 생성
|
||||
- **미학적 제어:**
|
||||
- `--s` (Stylize): 모델의 예술적 개입 강도 (0~1000)
|
||||
- `--style raw`: 사실적/가공되지 않은 스타일
|
||||
- `--c` (Chaos): 4장 이미지 간의 다양성/무작위성
|
||||
- `--w` (Weird): 기이하고 독특한 표현력
|
||||
- **일관성 유지 (Reference):**
|
||||
- `--sref`: 스타일 참조 (색감, 무드 복제)
|
||||
- `--cref`: 캐릭터 참조 (인물 일관성)
|
||||
- `--oref`: 옴니 참조 (V7, 사물/피사체의 형태적 정체성 유지)
|
||||
- `--seed`: 동일한 노이즈 패턴 재현
|
||||
- **기타:**
|
||||
- `--no`: 특정 요소 제외 (부정 프롬프트)
|
||||
- `--stop`: 렌더링 중도 중단 (추상적 효과)
|
||||
- `--iw`: 이미지 프롬프트 가중치 조절
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 미드저니 프롬프트를 작성하거나 최적화할 때.
|
||||
- 특정 캐릭터나 사물의 디자인을 여러 장면에 걸쳐 유지해야 할 때.
|
||||
- 생성 비용(GPU 시간)을 절약하면서 아이디어를 빠르게 테스트할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 미드저니가 아닌 다른 이미지 생성 도구(Stable Diffusion, DALL-E 등)를 사용할 때.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **목표 설정:** 비율, 스타일, 일관성 중 우선순위 결정.
|
||||
2. **파라미터 조합:** `--ar`로 구도를 잡고, `--s`나 `--style raw`로 톤을 결정한 뒤, 일관성이 필요하면 `--cref`나 `--oref` 추가.
|
||||
3. **최적화:** 초기 시안은 `--draft`를 활용해 빠르게 검토.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- V7 모델의 `--oref` 기능은 캐릭터 참조보다 연산량이 많을 수 있으며, 너무 복잡한 피사체는 재현율이 떨어질 수 있음.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** B
|
||||
- **검토 이유:** 해당 없음
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Midjourney Parameters]], [[미드저니 매개변수 (Midjourney Parameters)]]
|
||||
- **처리 방식:** MERGE
|
||||
- **처리 이유:** 유사한 내용을 담은 두 문서를 통합하여 정보 밀도를 높이고 P-Reinforce v3.0 규격을 적용함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** V6의 `--cref` 한계를 극복하기 위해 V7의 `--oref` 활용을 권장하는 내용을 포함함.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[미드저니 V7 (Midjourney V7)]]
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 기존 두 문서를 통합 및 v3.0 규격으로 마이그레이션 | MERGE | B |
|
||||
Reference in New Issue
Block a user