feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]
This commit is contained in:
+196
@@ -0,0 +1,196 @@
|
||||
---
|
||||
id: wiki-2026-0508-2026-04-25-skybound-player-airfr
|
||||
title: 2026 04 25 Skybound Player Airframe and 8Stage Boss Continuity Rework
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Skybound Player Airframe and 8 Stage Boss Continuity Rework
|
||||
|
||||
작성일: 2026-04-25 09:51 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- 사용자 기체가 엔진에서 그린 도형 조립처럼 보여 시각적 완성도가 낮아 보이는 문제를 개선한다.
|
||||
- Stage 1 클리어 후 Stage 2로 넘어가는 흐름이 결과 화면으로 끊겨 게임이 단절되는 문제를 개선한다.
|
||||
- Aero Fighters처럼 보스를 처치하고 같은 런 안에서 다음 스테이지로 자연스럽게 이어지는 구조를 만든다.
|
||||
- 총 8개 스테이지를 유지하고, 스테이지가 올라갈수록 난이도가 올라가도록 보스 HP, 파츠, 패턴을 재조정한다.
|
||||
- 각 스테이지 보스가 서로 다른 공격 패턴을 체감할 수 있도록 실행부를 보강한다.
|
||||
|
||||
## 확인한 문제
|
||||
|
||||
### 플레이어 기체 렌더링
|
||||
|
||||
- `GameRenderer.renderPlayer()`에서 플레이어 스프라이트 위에 랜덤 원형 엔진 글로우를 직접 그려서, 기체 뒤쪽이 매 프레임 흔들리는 임시 도형처럼 보였다.
|
||||
- `renderWeaponAttachments()`에서 일부 장착 무기를 `fillRect`, `strokeRect`, 랜덤 원형 플래시로 그려서 톤앤매너에 맞는 완성형 파츠가 아니라 디버그 박스처럼 보일 수 있었다.
|
||||
- 특히 Hyper Sonic Vulcan, Gatling fallback, Missile Pod fallback이 사용자 기체 실루엣과 잘 섞이지 않았다.
|
||||
|
||||
### 스테이지 전환
|
||||
|
||||
- 보스 처치 후 `STAGE_CLEAR`가 되고, 300프레임 뒤 `BOSS_ACTION NEXT_STAGE` 이벤트가 발생한다.
|
||||
- 기존 `useGameEngine`은 이 이벤트를 곧바로 `finishMission('CLEAR')`로 연결했다.
|
||||
- 그 결과 Standard 캠페인에서도 Stage 1 보스 처치 후 결과 화면으로 끊기고, 다음 스테이지는 별도 런처럼 느껴졌다.
|
||||
|
||||
### 보스 패턴
|
||||
|
||||
- `bossActions.ts`에는 Stage 1부터 Stage 8까지 액션 테이블이 있다.
|
||||
- 하지만 `BossSystem.executePattern()`은 일부 액션만 처리하고 있었기 때문에, 실제 전투에서는 많은 액션이 기본 단발 탄으로 떨어질 수 있었다.
|
||||
- `StageDirectorSystem.instantiateBoss()`의 보스 파츠 turretId가 `T-CORE`, `T-WING`, `T-HEAVY`처럼 실제 `TURRET_CATALOG`에 없는 값이라 파츠 포탑이 의도대로 발사되지 않을 수 있었다.
|
||||
- 기존 보스 HP는 Stage 2부터 `5000 * currentStage`로 급격히 올라가 캠페인 커브가 자연스럽지 않았다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 플레이어 기체 완성도 개선
|
||||
|
||||
- 플레이어 엔진 글로우를 랜덤 원형에서 고정된 마기테크 추진 플룸으로 변경했다.
|
||||
- 스프라이트 크기를 72px에서 78px로 약간 키워 중심 기체의 존재감을 높였다.
|
||||
- `drawMagitechPod()` 헬퍼를 추가해 장착 무기를 작은 마기테크 포드 형태로 통일했다.
|
||||
- Vulcan, Gatling fallback, Missile Pod fallback을 박스 도형 대신 다크 블루 메탈 바디, 시안/옐로/핑크 액센트, 라운드 포드 실루엣으로 렌더링한다.
|
||||
- 장착 파츠의 랜덤 플래시를 줄이고 프레임 기반 pulse로 바꿔 덜 튀고 더 의도적으로 보이게 했다.
|
||||
|
||||
### 연속 캠페인 전환
|
||||
|
||||
- Standard 캠페인에서 Stage 1-7 보스 처치 후 `finishMission`을 호출하지 않고, 같은 엔진 런 안에서 다음 스테이지로 전환하도록 변경했다.
|
||||
- 전환 시 다음 작업을 수행한다.
|
||||
- `currentStage` 증가
|
||||
- `campaignStageIndex` 저장
|
||||
- `StageDirectorSystem.advanceToStage()`로 새 타임라인 로드
|
||||
- 활성 총알, 적, 파티클 풀 정리
|
||||
- 스포너 큐 초기화
|
||||
- 보스, 탄막, hazard, airdrop, exp gem, vortex 정리
|
||||
- `INTRO` 페이즈로 재시작
|
||||
- 체력 25% 회복과 120프레임 무적 부여
|
||||
- Stage 안내 텍스트와 HQ comms 출력
|
||||
- Stage 8 보스 처치 시에는 `GAME_COMPLETE`로 결과 화면에 진입한다.
|
||||
- Blitz 모드는 기존처럼 단일 전투 클리어로 유지한다.
|
||||
|
||||
### 8스테이지 보스 커브
|
||||
|
||||
- 보스 HP를 선형 폭증에서 완만한 곡선형 성장으로 변경했다.
|
||||
- Stage 1은 낮게 시작하고, Stage 8은 누적 성장과 보스 패턴 난이도를 고려해 높은 난이도를 갖도록 설계했다.
|
||||
- 보스 파츠 HP도 같은 stage curve를 사용해 코어, 날개, 포탑이 함께 성장한다.
|
||||
- 각 스테이지에 실제 `TURRET_CATALOG`에 존재하는 turretId loadout을 지정했다.
|
||||
|
||||
### 보스 패턴 실행 보강
|
||||
|
||||
- 다음 액션들이 실제 탄막/기믹으로 실행되도록 매핑했다.
|
||||
- `FAN_PART`, `DASH_PART`: 부채꼴 조준 사격
|
||||
- `SIDE_WAVE`: 좌우 측면 웨이브
|
||||
- `ZONE_BOMB`: 안전 구역 압박과 링 탄막
|
||||
- `WALL_WAVE`: 틈이 있는 벽 형태 탄막
|
||||
- `MISSILE_BARRAGE`, `HOMING_CHASE`: 유도성 탄막
|
||||
- `CROSS_CHASE`: 네 방향 교차 추격 탄
|
||||
- `SPIRAL_WEB`, `REVOLVING_FLAME`: 나선 탄막
|
||||
- `BURST_SPLITTER`: 분열형 부채 탄
|
||||
- `GEAR_STORM`: 고밀도 나선과 링 조합
|
||||
- `PRECISION_LOCK`, `SNIPE_GRID`, `LASER_AIM`, `LASER_SWEEP`: 크로스헤어 기반 고속 압박
|
||||
- `TELEPORT_STRIKE`: 보스 위치 변경 후 기습 사격
|
||||
- `GIMMICK_PULSE`, `CC_REVERSE`, `ZONE_COLLAPSE`: 중력장/페이즈존 기믹과 링 탄막
|
||||
- `ULTIMATE_SYMPHONY`: 기존 고난도 복합 패턴 유지
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/StageDirectorSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/BossSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/EntityManager.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png [[Reference]]d in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 관련 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
|
||||
## 후속 플레이테스트 포인트
|
||||
|
||||
- Stage 1 보스 처치 후 결과 화면 없이 Stage 2 INTRO로 자연스럽게 이어지는지 확인한다.
|
||||
- Stage 8 보스 처치 후 `GAME_COMPLETE` 결과로 진입하는지 확인한다.
|
||||
- 장착 무기 파츠가 기체와 과하게 분리되어 보이지 않는지 확인한다.
|
||||
- Stage 3 이후 `ZONE_BOMB`, `WALL_WAVE`, `HOMING_CHASE`, `PRECISION_LOCK` 계열이 회피 목적을 명확히 만드는지 확인한다.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+168
@@ -0,0 +1,168 @@
|
||||
---
|
||||
id: wiki-2026-0508-2026-04-25-skybound-skill-concep
|
||||
title: 2026 04 25 Skybound Skill Concept and Hangar Layout Overlap Fix
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Skybound Skill Concept and Hangar Layout Overlap Fix
|
||||
|
||||
작성일: 2026-04-25 10:09 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- 스킬 업그레이드 후 화면에 긴 라이트 기둥만 보이는 문제가 있어 스킬 개념과 연출을 수정한다.
|
||||
- HUD/UI 관점에서 왼쪽에 여러 UI가 겹쳐 나오는 문제가 있어 필요하면 전체적으로 재설계한다.
|
||||
|
||||
## 확인한 문제
|
||||
|
||||
### Hyper-Sonic Vulcan 컨셉 불일치
|
||||
|
||||
- `Hyper-Sonic Vulcan`은 이름상 고속 벌컨/캐논 계열인데 실제 구현은 영구 지속되는 긴 레이저 빔이었다.
|
||||
- `GameRenderer`가 플레이어 기준으로 화면 끝까지 이어지는 두꺼운 시안 빔을 그려서, 스킬이 무기라기보다 긴 조명처럼 보였다.
|
||||
- `ModularWeaponSystem.updateHyperLaser()`도 라인 판정으로 지속 데미지를 넣고 있어 플레이어가 발사/탄막을 체감하기 어려웠다.
|
||||
|
||||
### Hangar UI 겹침
|
||||
|
||||
- `HangarOverlay.tsx`에서 `UPGRADE`와 `PASS` 탭 콘텐츠가 오른쪽 `craft-area` 패널 밖에 렌더링되고 있었다.
|
||||
- 그 결과 [[CSS Grid]]의 세 번째 아이템처럼 배치되어 왼쪽 패널/재료 영역과 겹쳐 보였다.
|
||||
- 특히 `UPGRADE` 탭 선택 시 `PERMANENT UPGRADES` 콘텐츠가 왼쪽 재료 패널 위로 올라오는 문제가 발생했다.
|
||||
|
||||
### 전투 보상 텍스트 겹침
|
||||
|
||||
- 적 처치 보상 텍스트가 화면 가장자리에서 생성될 경우 `TechMats`, `+TAC` 같은 텍스트가 잘리거나 서로 겹쳐 보일 수 있었다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Twin Arc Vulcan으로 스킬 컨셉 변경
|
||||
|
||||
- `HYPER_SONIC_VULCAN` 메타데이터 이름을 `Twin Arc Vulcan`으로 변경했다.
|
||||
- 설명도 `Twin magitech cannons fire rapid piercing arc rounds.`로 바꿔 실제 플레이 감각과 맞췄다.
|
||||
- 기존의 영구 레이저 빔 컨셉을 제거하고, 전방 관통 아크 탄환을 빠르게 발사하는 무기로 재설계했다.
|
||||
- 플레이어 좌우 포드에서 3갈래 관통탄을 빠르게 발사해 “벌컨 업그레이드” 느낌을 강화했다.
|
||||
- 스킬이 화면을 덮는 긴 빛이 아니라, 방향성과 탄막 밀도가 있는 공격으로 보이게 했다.
|
||||
|
||||
### 긴 라이트 렌더링 제거
|
||||
|
||||
- `GameRenderer`의 full-screen beam `fillRect()` 렌더링을 제거했다.
|
||||
- 대신 기체 앞쪽 포드에 짧은 muzzle bloom과 짧은 시안 streak만 표시하도록 변경했다.
|
||||
- 화면 전체를 가리는 시각 노이즈를 줄이고, 실제 공격은 projectile 렌더링이 담당하게 했다.
|
||||
|
||||
### Hangar 탭 레이아웃 수정
|
||||
|
||||
- `UPGRADE`와 `PASS` 탭 콘텐츠를 오른쪽 `craft-area` 내부로 이동했다.
|
||||
- 이제 탭 콘텐츠가 왼쪽 `Airframe Telemetry`/`Materials` 패널과 겹치지 않는다.
|
||||
- 기존 스타일을 유지하면서 구조적 렌더링 오류를 먼저 제거했다.
|
||||
|
||||
### Floating Text 안전 영역 처리
|
||||
|
||||
- `ctx.spawnText()`에서 텍스트 생성 위치를 화면 안전 영역 안으로 clamp한다.
|
||||
- 왼쪽 끝/오른쪽 끝에서 적이 죽어도 보상 텍스트가 화면 밖으로 잘리거나 HUD 영역에 과하게 겹치는 현상을 줄였다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/evolutions.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/weapon[[Behavior]]s.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HangarOverlay.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png [[Reference]]d in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
|
||||
## 후속 플레이테스트 포인트
|
||||
|
||||
- Gatling 진화 후 더 이상 긴 레이저 기둥이 보이지 않는지 확인한다.
|
||||
- `Twin Arc Vulcan`이 빠른 관통 탄막 무기로 체감되는지 확인한다.
|
||||
- Hangar에서 `UPGRADES`, `EVENT PASS` 탭 선택 시 왼쪽 패널과 콘텐츠가 겹치지 않는지 확인한다.
|
||||
- 전투 보상 텍스트가 화면 가장자리에서 잘리지 않는지 확인한다.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+209
@@ -0,0 +1,209 @@
|
||||
---
|
||||
id: wiki-2026-0508-2026-04-25-skybound-vampire-surv
|
||||
title: 2026 04 25 Skybound Vampire Survivors Loop and Stage Curve Preparation
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Skybound Vampire Survivors Loop and Stage Curve Preparation
|
||||
|
||||
작성일: 2026-04-25 23:52 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Skybound가 뱀파이어 서바이벌 계열 게임처럼 느껴지도록 재미 요소와 스테이지별 레벨 구조를 준비한다.
|
||||
- 단순히 적을 많이 내보내는 것이 아니라, 성장 선택, 밀도 상승, 진화 완성, 보스 체크포인트가 자연스럽게 이어지도록 만든다.
|
||||
|
||||
## 핵심 방향
|
||||
|
||||
Skybound는 탑다운 생존 슈터이지만, 기존 구조는 스테이지 시간이 짧고 보스 진입이 빨라 빌드가 완성되기 전에 전투가 끊기는 문제가 있었다. 뱀서류 재미를 만들려면 다음 루프가 안정적으로 반복되어야 한다.
|
||||
|
||||
1. 초반: 첫 무기 선택 후 약한 적을 많이 처치하며 빠르게 1-2회 성장한다.
|
||||
2. 중반: 적 밀도와 엘리트 압박이 올라가며 광역/관통/방어 선택의 의미가 생긴다.
|
||||
3. 후반: 스웜과 미니보스가 들어오며 빌드 조합과 진화 무기가 필요해진다.
|
||||
4. 보스: 완성된 빌드가 제대로 작동하는지 검증한다.
|
||||
5. 다음 스테이지: 같은 빌드를 이어가되 적 밀도, 패턴, 보스 기믹이 상승한다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 8스테이지 Survivor 프로필 추가
|
||||
|
||||
`CombatTimeline.ts`에 `SURVIVOR_STAGE_PROFILES`를 추가했다. 각 스테이지는 아래 정보를 가진다.
|
||||
|
||||
- 스테이지 이름
|
||||
- 스테이지 길이
|
||||
- 기본 난이도 배율
|
||||
- 동시 적 수 기준
|
||||
- 스폰 템포
|
||||
- 오프닝 웨이브
|
||||
- 압박 엘리트 웨이브
|
||||
- 스웜 웨이브
|
||||
- 클라이맥스 엘리트 웨이브
|
||||
- 미니보스 체크포인트
|
||||
|
||||
### 스테이지별 구조
|
||||
|
||||
- Stage 1 `First Contact`: 첫 무기와 기본 생존 학습
|
||||
- Stage 2 `Fast Lanes`: 빠른 적과 이동 압박
|
||||
- Stage 3 `Ruined Circuit`: 혼합 편대와 엘리트 압박
|
||||
- Stage 4 `Crossfire Grid`: 길막/라인 클리어 압박
|
||||
- Stage 5 `Magma Forge`: 고밀도 스웜 시작
|
||||
- Stage 6 `Storm Foundry`: 빌드 완성 요구
|
||||
- Stage 7 `Arcane Collapse`: 진화 무기 권장
|
||||
- Stage 8 `Final Singularity`: 완성 빌드 검증
|
||||
|
||||
### 스테이지 시간 조정
|
||||
|
||||
기존 Standard 스테이지는 약 165초부터 시작해 빌드업 시간이 부족했다. 새 구조에서는 Stage 1이 240초, Stage 8이 420초까지 증가한다.
|
||||
|
||||
이렇게 하면 플레이어는 한 스테이지 안에서 다음 리듬을 경험할 수 있다.
|
||||
|
||||
- 0-25%: 세팅과 첫 성장
|
||||
- 25-48%: 엘리트 압박
|
||||
- 48-72%: 스웜 압박
|
||||
- 72%-보스 전: 클라이맥스와 미니보스
|
||||
- 마지막 35초 전후: 보스전 진입
|
||||
|
||||
### 스폰 밀도 조정
|
||||
|
||||
- 적 하드캡을 56에서 76으로 올렸다.
|
||||
- 스웜 배치 단위를 6에서 8로 올렸다.
|
||||
- 기본 절차 스폰 간격을 96프레임에서 84프레임으로 줄였다.
|
||||
|
||||
목표는 “가만히 있어도 클리어”가 아니라, 점점 밀려오는 압박을 움직임과 빌드 선택으로 해결하게 만드는 것이다.
|
||||
|
||||
### Tac EXP 커브 조정
|
||||
|
||||
바닥 EXP 젬을 다시 뿌리지는 않고, 처치 즉시 Tac EXP를 지급하는 현재 방향을 유지했다. 다만 뱀서류 성장 리듬을 만들기 위해 처치 경험치를 조정했다.
|
||||
|
||||
- 일반 적: `+2 TAC`
|
||||
- 엘리트 적: `+10 TAC`
|
||||
- 미드보스: `+30 TAC`
|
||||
|
||||
초기 요구 EXP는 `90`에서 `80`으로 낮췄다. 대신 레벨업 후 초과 EXP carryover는 25%만 유지해 연속 레벨업 폭주는 막는다.
|
||||
|
||||
레벨 요구량 배율은 아래처럼 조정했다.
|
||||
|
||||
- Level 1-4: `x1.34`
|
||||
- Level 5-8: `x1.42`
|
||||
- Level 9-14: `x1.52`
|
||||
- Level 15+: `x1.62`
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 변경은 “Vampire Survivors의 재미”를 다음 요소로 해석했다.
|
||||
|
||||
- 적은 점점 많아진다.
|
||||
- 플레이어는 더 자주 선택하고 강해진다.
|
||||
- 선택에는 빌드 방향성이 있다.
|
||||
- 중반 이후에는 광역, 관통, 방어, 기동 중 최소 하나가 부족하면 압박을 느낀다.
|
||||
- 보스는 단절된 엔딩이 아니라 빌드 검증 구간이다.
|
||||
- 다음 스테이지는 새 게임이 아니라 이전 빌드의 확장 시험이다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png [[Reference]]d in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
|
||||
## 후속 작업 제안
|
||||
|
||||
- 각 스테이지별 고유 몬스터 역할 비중을 더 명확히 분리한다.
|
||||
- 스테이지별 보스 패턴을 현재보다 더 강하게 차별화한다.
|
||||
- 진화 무기별 화면 가독성과 성능을 플레이테스트로 검증한다.
|
||||
- 미니보스 처치 시 보물상자/카드 선택 보상을 확정 지급하는 구조를 추가하면 뱀서류 보상감이 더 강해진다.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+216
@@ -0,0 +1,216 @@
|
||||
---
|
||||
id: wiki-2026-0508-2026-04-26-skybound-enemy-motion
|
||||
title: 2026 04 26 Skybound Enemy Motion Damage Pressure and Projectile Visual Pass
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Skybound Enemy Motion Damage Pressure and Projectile Visual Pass
|
||||
|
||||
작성일: 2026-04-26 12:46 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Stage 1 적기의 이동이 어디에 낀 것처럼 바들바들 떨리는 문제를 개선한다.
|
||||
- 적 공격 데미지가 사용자 Tac Level에 정비례해서 오르는 느낌이 아니라, 소폭만 상승하도록 조정한다.
|
||||
- 사용자 기체의 일반 공격 탄환과 Gatling 탄환이 단순 렌더링 도형처럼 보여 아쉬운 문제를 개선한다.
|
||||
- 스킬과 탄환의 비주얼을 Skybound의 Stylized Casual Magitech 톤앤매너에 맞춰 더 상품성 있게 다듬는다.
|
||||
|
||||
## 핵심 문제
|
||||
|
||||
### 적 이동 떨림
|
||||
|
||||
Stage 1에서 보이는 적기의 떨림은 주로 추적형 AI가 플레이어 근처에서 목표점을 매 프레임 다시 계산하면서 발생했다. 목표를 향해 직선 이동하다가 너무 가까워지면 다음 프레임에 방향이 반대로 튀고, 여기에 회전값도 즉시 플레이어를 향해 바뀌면서 시각적으로 “끼어서 떠는” 것처럼 보였다.
|
||||
|
||||
### 적 데미지 상승
|
||||
|
||||
적 데미지는 스테이지와 페이즈 압박에 따라 올라가야 하지만, 사용자 Tac Level과 동일한 폭으로 오르면 성장 보상이 무효화된다. 따라서 Tac Level은 적 데미지에 아주 작은 압박 보정만 주는 것이 맞다.
|
||||
|
||||
### 플레이어 탄환 비주얼
|
||||
|
||||
기본 공격과 Gatling 탄환은 기존 Canvas 사각형/막대 형태가 남아 있어, 현재 게임의 마법공학 기체와 스킬 아이콘 퀄리티에 비해 완성도가 낮게 보였다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 적 회전 안정화
|
||||
|
||||
적기의 회전을 즉시 목표 각도로 바꾸지 않고 `smoothEnemyRotation`을 통해 보간한다.
|
||||
|
||||
이제 적은 플레이어를 향해 부드럽게 회전하며, 근거리에서 회전값이 프레임마다 튀는 현상이 줄어든다.
|
||||
|
||||
### 추적형 적 이동 안정화
|
||||
|
||||
`chase` 패턴에 속도 보간과 근거리 감속을 추가했다.
|
||||
|
||||
- 목표점으로 바로 이동하지 않고 `vx`, `vy`를 보간한다.
|
||||
- 플레이어와 너무 가까워지면 속도를 줄인다.
|
||||
- 일정 거리 안으로 들어오면 살짝 밀려나며 겹침을 완화한다.
|
||||
|
||||
### 적끼리 겹침 완화
|
||||
|
||||
`applyEnemySeparation`을 추가했다. 적이 서로 너무 가까이 붙으면 약하게 밀어내어, 여러 적이 한 점에 몰려 떨리는 문제를 줄인다.
|
||||
|
||||
적 종류별 최소 거리도 다르게 적용한다.
|
||||
|
||||
- 일반 적: 작은 거리
|
||||
- 엘리트: 중간 거리
|
||||
- 미니보스: 더 큰 거리
|
||||
|
||||
### 적 데미지 보정 완만화
|
||||
|
||||
기존에는 페이즈 난이도 배율이 탄속/데미지에 직접적으로 강하게 반영될 수 있었다. 이제 아래처럼 완만하게 조정했다.
|
||||
|
||||
- 탄속은 페이즈 배율을 직접 곱하지 않고 작은 `phaseSpeedPressure`만 반영한다.
|
||||
- 데미지는 스테이지 커브를 기본으로 하되 `phaseDamagePressure`를 제한적으로 적용한다.
|
||||
- 사용자 Tac Level은 최대 `+18%`까지만 적 데미지에 반영한다.
|
||||
|
||||
의도는 다음과 같다.
|
||||
|
||||
- 플레이어가 성장해도 적이 완전히 무력해지지는 않는다.
|
||||
- 하지만 플레이어 레벨이 올랐다고 적 데미지가 같은 폭으로 따라오지는 않는다.
|
||||
- 성장 보상은 유지하고, 긴장감만 조금 보강한다.
|
||||
|
||||
### 플레이어 탄환 비주얼 개선
|
||||
|
||||
기본 탄환, Gatling 탄환, Rayce 탄환, 드론 탄환에 `visualKind`를 부여했다.
|
||||
|
||||
추가된 visualKind:
|
||||
|
||||
- `arc_bolt`
|
||||
- `gatling_round`
|
||||
- `rayce_lance`
|
||||
- `micro_missile`
|
||||
- `arc_vulcan`
|
||||
- `drone_shot`
|
||||
|
||||
### Magitech Projectile Renderer 추가
|
||||
|
||||
`GameRenderer`에 `renderMagitechProjectile`을 추가했다. 기존 사각형 탄환 대신 아래 요소를 가진 발사체로 렌더링된다.
|
||||
|
||||
- 밝은 코어
|
||||
- 마법공학 외곽 라인
|
||||
- 발사 방향 꼬리광
|
||||
- 글로우
|
||||
- 작은 룬/핀 라인
|
||||
- 기체/무기별 색상 차이
|
||||
|
||||
Gatling은 골드빛 짧은 고속탄, 기본 Falcon 탄은 시안 아크 볼트, Rayce는 마젠타 랜스형 탄환으로 보이게 했다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 변경은 조작감과 시각 품질을 동시에 개선하는 작업이다.
|
||||
|
||||
적 이동은 “불안정한 버그처럼 보이는 흔들림”이 아니라, 의도된 추적/회피 압박처럼 보여야 한다. 또한 적 데미지는 플레이어 성장과 같은 폭으로 따라오면 안 된다. 플레이어는 강해져야 하고, 적은 그 강함을 무효화하지 않는 선에서 압박을 유지해야 한다.
|
||||
|
||||
탄환 비주얼은 Skybound의 가장 자주 보는 이펙트이므로, 단순 도형이 남아 있으면 전체 완성도를 낮춘다. 이번 변경으로 기본 공격도 스킬과 같은 톤의 Magitech 무장처럼 보이게 했다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/PlayerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/Weapon[[Behavior]]Engine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/23`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- Stage 1 일반 적이 플레이어 근처에서 바들바들 떨지 않는지 확인한다.
|
||||
- 적이 겹칠 때 자연스럽게 분산되는지 확인한다.
|
||||
- Tac Level이 올라가도 적 데미지가 과하게 따라오지 않는지 확인한다.
|
||||
- Falcon 기본탄과 Gatling 탄환이 사각형 도형이 아니라 마법공학 발사체처럼 보이는지 확인한다.
|
||||
- Rayce 탄환이 Falcon과 충분히 구분되는지 확인한다.
|
||||
- 이후 스킬별 전용 Canvas/PNG 이펙트를 더 세분화할지 결정한다.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,202 @@
|
||||
---
|
||||
id: wiki-2026-0508-2026-04-26-skybound-miniboss-tre
|
||||
title: 2026 04 26 Skybound Miniboss Treasure Cache Reward Loop
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Skybound Miniboss Treasure Cache Reward Loop
|
||||
|
||||
작성일: 2026-04-26 09:32 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- 뱀파이어 서바이벌 계열의 재미를 더 강하게 만들기 위한 다음 단계로, 미니보스 처치 보상 루프를 추가한다.
|
||||
- 단순 EXP 성장만 반복되는 구조가 아니라, 중간 강적을 잡았을 때 빌드 방향을 강화하는 확정 보상을 제공한다.
|
||||
- 보상은 기존 Tac Level Up 화면을 재사용하되, 보물상자 성격의 `Emergency Supply` 카드 선택으로 연결한다.
|
||||
|
||||
## 핵심 방향
|
||||
|
||||
Skybound의 현재 전투 루프는 적을 처치하면 Tac EXP를 바로 얻고, 일정 EXP에 도달하면 업그레이드를 선택하는 구조다. 이 방식은 화면 가독성에는 좋지만, 플레이 중간에 “강적을 잡아서 특별한 보상을 얻었다”는 뱀서류 특유의 보상감이 부족했다.
|
||||
|
||||
이번 변경의 목표는 미니보스를 다음 역할로 재정의하는 것이다.
|
||||
|
||||
1. 전투 흐름 중간의 압박 체크포인트
|
||||
2. 플레이어 빌드가 충분히 강한지 확인하는 작은 검증 구간
|
||||
3. 처치하면 현재 빌드를 더 선명하게 만드는 확정 업그레이드 보상
|
||||
4. 보스 전 진화/EVO 경로를 완성할 기회를 주는 중간 보물상자
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 미니보스 식별 플래그 추가
|
||||
|
||||
기존 `MINI_BOSS` 스폰은 내부적으로 `ELITE` 적을 생성했기 때문에, 처치 시 일반 엘리트와 구분되는 보상 처리가 어려웠다. `SystemEnemy`에 아래 플래그를 추가했다.
|
||||
|
||||
- `isMiniBoss`
|
||||
- `rewardClaimed`
|
||||
|
||||
`SpawnerSystem`의 `MINI_BOSS` 스폰에서는 이제 `isMiniBoss: true`를 부여한다.
|
||||
|
||||
### 미니보스 HP 스케일링
|
||||
|
||||
미니보스가 후반 스테이지에서도 너무 빨리 녹지 않도록 스테이지와 난이도 배율을 반영했다.
|
||||
|
||||
- 기본 HP: `620`
|
||||
- 스테이지당 증가: `+22%`
|
||||
- 현재 `difficultyMult` 반영
|
||||
|
||||
의도는 미니보스가 보스만큼 길지는 않지만, 플레이어가 위치와 공격 방향을 신경 써야 하는 짧은 전투 목표가 되게 하는 것이다.
|
||||
|
||||
### 처치 보상 인텐트 추가
|
||||
|
||||
`EngineProtocol`에 `MINIBOSS_REWARD` 인텐트를 추가했다. `CombatSystem`은 미니보스 처치 시 직접 UI를 열지 않고, 엔진 인텐트를 통해 보상 처리를 요청한다.
|
||||
|
||||
이렇게 한 이유는 다음과 같다.
|
||||
|
||||
- 전투 시스템이 UI 상태를 직접 제어하지 않게 한다.
|
||||
- 기존 `LEVEL_UP` 이벤트와 `LevelUpModal` 흐름을 재사용한다.
|
||||
- 추후 보물상자 연출, 룰렛, 보상 티어를 추가하기 쉽다.
|
||||
|
||||
### 빌드 우선 보상 카드 생성
|
||||
|
||||
`ProgressionSystem`에 `generateMiniBossRewardCards`를 추가했다. 이 보상은 일반 레벨업 카드보다 더 전략적으로 구성된다.
|
||||
|
||||
우선순위는 다음과 같다.
|
||||
|
||||
1. 이미 보유한 무기/스킬의 레벨업
|
||||
2. Lv.3 이상 무기의 EVO에 필요한 서포트 패시브
|
||||
3. 스웜/압박 구간 대응용 `isSpikeCounter` 스킬
|
||||
4. 부족한 자리는 기존 3카드 생성 규칙으로 보충
|
||||
|
||||
이 구조는 플레이어가 아무 카드나 고르는 것이 아니라, “내 빌드를 완성해가는 선택”을 하도록 유도한다.
|
||||
|
||||
### 보상 UI 연결
|
||||
|
||||
미니보스 처치 시 아래 흐름으로 동작한다.
|
||||
|
||||
1. 미니보스 사망
|
||||
2. `CombatSystem`이 `MINIBOSS_REWARD` 인텐트 발행
|
||||
3. `useGameEngine`이 현재 스킬 상태를 기반으로 보상 카드 생성
|
||||
4. 게임 일시정지
|
||||
5. `LEVEL_UP` 이벤트를 `isChest: true`로 발행
|
||||
6. 기존 `Emergency Supply` 카드 선택 UI 표시
|
||||
7. `COMMAND CACHE UNLOCKED` 피드백 텍스트 출력
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이 변경은 Skybound의 목적성을 더 명확하게 만들기 위한 작업이다.
|
||||
|
||||
- 일반 적 처치: Tac EXP를 쌓는 기본 성장
|
||||
- 엘리트 처치: 더 많은 EXP와 재료/장비 가능성
|
||||
- 미니보스 처치: 확정 빌드 강화 선택
|
||||
- 스테이지 보스 처치: 다음 스테이지 진행과 영구 보상
|
||||
|
||||
즉, 전투 중 목표가 “그냥 버티기”에서 “위험한 타이밍을 넘기고 빌드를 완성하기”로 바뀐다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/EngineProtocol.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png [[Reference]]d in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
|
||||
## 후속 작업 제안
|
||||
|
||||
- 미니보스 처치 순간에 실제 상자/코어가 열리는 0.6초 전용 연출을 추가한다.
|
||||
- 보상 카드에 `EVO READY`, `BUILD CORE`, `SURVIVAL PICK` 같은 태그를 붙여 선택 이유를 더 명확하게 보여준다.
|
||||
- 스테이지별 미니보스 외형과 탄막 패턴을 분리해 “이번 스테이지의 중간 위협” 정체성을 강화한다.
|
||||
- 보물상자 보상을 1장 선택에서 3장 순차 오픈 또는 희귀도 보상으로 확장할지 플레이테스트 후 결정한다.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,156 @@
|
||||
---
|
||||
id: wiki-2026-0508-2026-04-26-skybound-player-sprit
|
||||
title: 2026 04 26 Skybound Player Sprite Path Warning Fix
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Skybound Player Sprite Path Warning Fix
|
||||
|
||||
작성일: 2026-04-26 12:11 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- `npm run build` 시 반복되던 `/sprites/player.png [[Reference]]d in /sprites/player.png didn't resolve at build time` 경고를 해결한다.
|
||||
- 필요하다면 Skybound의 Stylized Casual Magitech 톤앤매너에 맞는 플레이어 기체 이미지를 새로 준비한다.
|
||||
|
||||
## 원인
|
||||
|
||||
경고의 원인은 실제 플레이 중 사용되는 Canvas 렌더링이 아니라, 선택 화면 CSS에서 존재하지 않는 `/sprites/player.png`를 참조하고 있었기 때문이다.
|
||||
|
||||
문제 위치는 `src/App.css`의 아래 클래스였다.
|
||||
|
||||
- `.plane-preview.falcon`
|
||||
- `.plane-preview.rayce`
|
||||
|
||||
현재 프로젝트에는 `/sprites/player.png`가 없고, 실제 준비된 기체 에셋은 아래 파일이다.
|
||||
|
||||
- `/sprites/Falcon.png`
|
||||
- `/sprites/rayce.png`
|
||||
|
||||
따라서 새 이미지를 생성하기보다, 이미 톤앤매너에 맞춰 준비된 실제 기체 에셋으로 경로를 정리하는 것이 적절했다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Falcon 미리보기 경로 수정
|
||||
|
||||
`/sprites/player.png`를 `/sprites/Falcon.png`로 교체했다.
|
||||
|
||||
### Rayce 미리보기 경로 수정
|
||||
|
||||
Rayce도 같은 `player.png`에 `hue-rotate`를 걸어 임시로 표현하고 있었기 때문에, 실제 `/sprites/rayce.png`를 직접 사용하도록 바꿨다.
|
||||
|
||||
또한 임시 색상 변환 필터를 제거했다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
선택 화면은 사용자가 처음 기체의 정체성을 보는 곳이기 때문에, 존재하지 않는 공용 `player.png`나 임시 색상 변환보다 실제 기체별 에셋을 보여주는 편이 상품성 측면에서 낫다.
|
||||
|
||||
이번 수정으로 다음 효과가 있다.
|
||||
|
||||
- Vite 빌드 경고 제거
|
||||
- Falcon/Rayce 선택 화면 미리보기 정확도 개선
|
||||
- 임시 에셋 참조 제거
|
||||
- 기존 Stylized Casual Magitech 기체 에셋 재사용
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/App.css`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- 기존 `/sprites/player.png` Vite 경고 사라짐
|
||||
- 출력 디렉터리: `dist/21`
|
||||
|
||||
## 후속 작업 제안
|
||||
|
||||
- 선택 화면의 기체 미리보기를 정적 배경 이미지가 아니라, Canvas 렌더러와 동일한 축소 프리뷰 컴포넌트로 통일한다.
|
||||
- Falcon/Rayce의 실제 플레이 성능 차이가 UI 문구와 정확히 대응되는지 점검한다.
|
||||
- 선택 화면도 현재 게임 HUD/UI 톤과 완전히 맞도록 한 번 더 정리한다.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+243
@@ -0,0 +1,243 @@
|
||||
---
|
||||
id: wiki-2026-0508-2026-04-26-skybound-skip-upgrade
|
||||
title: 2026 04 26 Skybound Skip Upgrade and Weapon Transform Reconfiguration
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Skybound Skip Upgrade and Weapon Transform Reconfiguration
|
||||
|
||||
작성일: 2026-04-26 13:25 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Tactical Level Up 화면에서 마음에 들지 않는 업그레이드만 나올 수 있다.
|
||||
- 이 경우 사용자가 강제로 원하지 않는 업그레이드를 고르지 않도록 `업글 안하기` 선택지를 추가한다.
|
||||
- 새로운 무기가 장착되었을 때 사용자의 기체 외형도 그에 맞춰 변화해야 한다.
|
||||
- 연출적으로는 트랜스포머처럼 기체가 재구성되고 무장이 전개되는 느낌을 표현한다.
|
||||
|
||||
## 핵심 문제
|
||||
|
||||
기존 레벨업 화면은 반드시 하나의 스킬을 선택해야 했다.
|
||||
|
||||
이 구조의 문제:
|
||||
|
||||
1. 현재 빌드와 맞지 않는 선택지만 나와도 강제로 선택해야 한다.
|
||||
2. 낮은 레벨 우선 후보 확률을 적용한 뒤에는 사용자가 원치 않는 저레벨/새 무기가 뜰 가능성도 생긴다.
|
||||
3. 새 무기를 획득해도 기체가 실제로 바뀌는 느낌이 약하다.
|
||||
4. 무기가 생긴 순간의 시각적 보상이 부족하다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Skip Upgrade 선택지 추가
|
||||
|
||||
`LevelUpModal`에 `Skip Upgrade` 카드를 추가했다.
|
||||
|
||||
동작:
|
||||
|
||||
- STARTER 첫 무기 선택에서는 스킵이 나오지 않는다.
|
||||
- 일반 Tactical Upgrade, Supply, Command Cache에서는 스킵 가능하다.
|
||||
- 스킵을 선택하면 스킬/무기 레벨이 증가하지 않고 전투로 복귀한다.
|
||||
|
||||
표시 문구:
|
||||
|
||||
- `HOLD UPGRADE`
|
||||
- `Skip Upgrade`
|
||||
- `No change this time`
|
||||
|
||||
### Skip 안전 처리
|
||||
|
||||
`__skip__`이 실제 스킬처럼 저장되지 않도록 여러 지점에 방어를 추가했다.
|
||||
|
||||
적용 지점:
|
||||
|
||||
- `GameSceneRenderer`
|
||||
- `ProgressionSystem`
|
||||
- `useGameStore.addSkill`
|
||||
|
||||
`__skip__`이 선택되면:
|
||||
|
||||
- Zustand `skills`에 추가하지 않는다.
|
||||
- 엔진 스킬 상태에도 추가하지 않는다.
|
||||
- `TACTICAL UPGRADE HELD` 텍스트를 띄운다.
|
||||
- 게임 pause를 해제하고 전투를 재개한다.
|
||||
|
||||
### 새 무기 장착 감지
|
||||
|
||||
`ProgressionSystem.applySkillSelection()`에서 선택 직전 스킬 레벨을 확인한다.
|
||||
|
||||
조건:
|
||||
|
||||
- 선택한 스킬이 `WEAPON` 타입
|
||||
- 선택 직전 레벨이 0
|
||||
|
||||
이 조건을 만족할 때만 새 무기 장착 연출을 발동한다.
|
||||
|
||||
기존 무기 레벨업이나 패시브 선택은 변신 연출을 발동하지 않는다.
|
||||
|
||||
### Airframe Reconfiguration 상태 추가
|
||||
|
||||
`Game[[State]]`에 새 무기 장착 연출용 상태를 추가했다.
|
||||
|
||||
추가 필드:
|
||||
|
||||
- `weaponTransformStartFrame`
|
||||
- `weaponTransformDuration`
|
||||
- `weaponTransformSkillId`
|
||||
|
||||
이 값은 렌더러가 현재 프레임 기준으로 변신 진행도를 계산하는 데 사용한다.
|
||||
|
||||
### 기체 변신/무장 전개 연출 추가
|
||||
|
||||
`GameRenderer.renderPlayer()`에 새 무기 장착 연출을 추가했다.
|
||||
|
||||
연출 요소:
|
||||
|
||||
- 기체 중심에서 확장되는 아케인 스캔 링
|
||||
- 무기 색상별 발광
|
||||
- 좌우 장갑 패널이 바깥으로 접히듯 전개
|
||||
- 전방 무장 레일이 앞으로 돌출
|
||||
- 작은 locking spark
|
||||
- `WEAPON LINK: 무기명`
|
||||
- `AIRFRAME RECONFIGURING`
|
||||
- 화면 흔들림과 파티클
|
||||
|
||||
무기별 액센트 컬러:
|
||||
|
||||
- Gatling Gun: 골드
|
||||
- Missile Pod: 핑크/레드
|
||||
- Nova Burst: 시안
|
||||
- Energy Shield: 라임
|
||||
- Sweep Laser: 화이트/시안
|
||||
- Plasma Torpedo: 오렌지
|
||||
- Ion Storm: 전기 시안
|
||||
- Attack Drone: 라임
|
||||
- Gravity Mine: 퍼플
|
||||
- Plasma Fire: 오렌지/레드
|
||||
- Plasma Blade: 시안
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 변경은 업그레이드 UX에 “선택하지 않을 권리”를 추가하는 작업이다.
|
||||
|
||||
업그레이드는 항상 이득처럼 보여야 하지만, 빌드 방향과 맞지 않는 선택을 강제하면 사용자는 선택권을 잃었다고 느낄 수 있다.
|
||||
|
||||
스킵 선택지는 다음 의미를 가진다.
|
||||
|
||||
1. 원하지 않는 업그레이드를 강제로 먹지 않는다.
|
||||
2. 빌드 순도를 유지할 수 있다.
|
||||
3. 낮은 레벨 우선 후보 시스템의 부작용을 완화한다.
|
||||
4. 선택 화면에서 사용자 판단 여지를 높인다.
|
||||
|
||||
새 무기 변신 연출은 “새 기능이 생겼다”를 UI 문구가 아니라 기체 자체 변화로 전달하기 위한 장치다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/GameSceneRenderer.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.css`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/27`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- 일반 레벨업 화면에서 `Skip Upgrade`가 명확하게 보이는지 확인한다.
|
||||
- STARTER 첫 무기 선택에서는 스킵이 나오지 않는지 확인한다.
|
||||
- 스킵 선택 시 게임이 정상 재개되는지 확인한다.
|
||||
- 스킵 선택 후 `skills.__skip__` 같은 잘못된 값이 저장되지 않는지 확인한다.
|
||||
- 새 무기를 처음 선택했을 때 기체 변신 연출이 충분히 눈에 띄는지 확인한다.
|
||||
- 기존 무기 레벨업/패시브 선택 시 변신 연출이 과하게 반복되지 않는지 확인한다.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+298
@@ -0,0 +1,298 @@
|
||||
---
|
||||
id: wiki-2026-0508-2026-04-26-skybound-stage1-to-3-
|
||||
title: 2026 04 26 Skybound Stage1 to 3 Playtest Balance Bomb and Visual Diversity Pass
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Skybound Stage 1 to 3 Playtest Balance Bomb and Visual Diversity Pass
|
||||
|
||||
작성일: 2026-04-26 12:35 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Stage 1부터 Stage 3까지 실제 플레이 후 느낀 문제를 개선한다.
|
||||
- Stage 1 초반 적 탄속이 부담스럽고, 중반 이후 성장하면 너무 쉬워지는 문제를 조정한다.
|
||||
- Stage 2 시작 시 이미 Tac Level 6 정도로 강해져 적이 화면에 들어오기 전에 사망하는 문제를 완화한다.
|
||||
- Space/X 폭탄의 비주얼 이펙트가 약하므로 톤앤매너에 맞는 폭탄 연출을 강화한다.
|
||||
- 일반 적, 엘리트, 미니보스, 보스 외형 다양성을 확보한다.
|
||||
|
||||
## 핵심 문제
|
||||
|
||||
플레이 피드백 기준으로 Skybound의 현재 문제는 초반과 중반의 난이도 감각이 반대로 작동한다는 점이었다.
|
||||
|
||||
1. Stage 1 초반은 적 탄속이 빠르게 느껴져 부담스럽다.
|
||||
2. Stage 1 중반부터 스킬이 붙으면 플레이어 화력이 너무 급격히 상승한다.
|
||||
3. Stage 2에서는 적이 화면에 들어오기 전에 사망해 긴장감이 사라진다.
|
||||
4. Tac Level 성장 속도와 무기 효율이 합쳐져 “이미 완성된 빌드”처럼 느껴진다.
|
||||
5. 보스/적기 외형 반복으로 스테이지 진행감이 약하다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Stage 1 적 탄속 완화
|
||||
|
||||
`balance.ts`의 적 탄환 기본 속도와 스테이지별 탄속 커브를 낮췄다.
|
||||
|
||||
변경 전:
|
||||
|
||||
- `BULLET_BASE_SPEED: 3.75`
|
||||
- `BULLET_SPEED_CURVE: [1.1, 1.28, 1.48, ...]`
|
||||
|
||||
변경 후:
|
||||
|
||||
- `BULLET_BASE_SPEED: 3.25`
|
||||
- `BULLET_SPEED_CURVE: [0.82, 0.96, 1.12, ...]`
|
||||
|
||||
Stage 1은 회피를 학습할 수 있는 속도로 낮추고, Stage 4 이후부터 탄속이 본격적으로 올라가도록 재배치했다.
|
||||
|
||||
### 적 사격 템포 완화
|
||||
|
||||
초반 탄막 부담을 줄이기 위해 `FIRE_RATE_CURVE`도 조정했다.
|
||||
|
||||
변경 후:
|
||||
|
||||
- `[280, 248, 222, 198, 176, 154, 134, 116]`
|
||||
|
||||
Stage 1-2는 더 읽을 수 있게 만들고, 후반 스테이지는 기존처럼 빠르게 압박하도록 유지했다.
|
||||
|
||||
### Tac Level 성장 속도 완화
|
||||
|
||||
Tac Level이 Stage 1 중반에 너무 빨리 누적되지 않도록 조정했다.
|
||||
|
||||
- 시작 요구 EXP: `80` → `100`
|
||||
- 레벨업 후 초과 EXP carryover: `25%` → `15%`
|
||||
- 레벨업 lockout: `360프레임` → `480프레임`
|
||||
- 일반 적 Tac EXP: `2` → `1`
|
||||
- 엘리트 Tac EXP: `10` → `8`
|
||||
- 미니보스 Tac EXP: `30` → `24`
|
||||
|
||||
목표는 Stage 2 시작 시 플레이어가 강해졌다는 느낌은 가지되, 이미 완성된 상태는 아니게 만드는 것이다.
|
||||
|
||||
### 플레이어 무기 초중반 효율 완화
|
||||
|
||||
무기 업그레이드가 의미는 있지만, Lv1-3에서 화면 전체를 지우지 않도록 주요 피해량을 조정했다.
|
||||
|
||||
- Gatling Gun 피해와 발사 효율 하향
|
||||
- Hyper Laser 피해 하향
|
||||
- Nova Burst 피해 하향
|
||||
- Missile Pod, Rocket Launcher, Ion Storm, Gravity Mine, Blade Orbit 등 데이터 기반 무기 피해 하향
|
||||
- EVO 무기도 일부 피해를 낮춰 Stage 2-3을 통째로 삭제하지 않게 조정
|
||||
|
||||
### 화면 밖 적 선삭제 방지
|
||||
|
||||
Stage 2에서 적이 화면에 나오기도 전에 사망하는 가장 큰 원인은 자동 조준/유도/빔/드론/오비트 무기가 `y < 0`에 있는 적까지 타겟팅하거나 피해를 주는 것이었다.
|
||||
|
||||
그래서 플레이어 무기 타겟팅과 충돌 판정에 `TARGETABLE_Y = -35` 기준을 추가했다.
|
||||
|
||||
적이 화면에 거의 진입하기 전까지는 다음 무기가 타겟팅하지 않는다.
|
||||
|
||||
- 유도탄
|
||||
- 자동 조준 무기
|
||||
- 빔
|
||||
- 오비트 무기
|
||||
- 드론
|
||||
- 설치/장판 무기
|
||||
- 일반 플레이어 탄환 충돌
|
||||
|
||||
이제 적이 화면에 들어와 위협을 보여준 뒤 처치되는 흐름이 만들어진다.
|
||||
|
||||
### Stage 2-3 압박 보강
|
||||
|
||||
Stage 2와 Stage 3은 이미 성장한 플레이어를 전제로 난이도를 다시 올렸다.
|
||||
|
||||
Stage 2:
|
||||
|
||||
- `diffBase: 1.02` → `1.12`
|
||||
- `capBase: 23` → `28`
|
||||
- `spawnTempo: 0.94` → `0.86`
|
||||
- opening density: `10` → `14`
|
||||
|
||||
Stage 3:
|
||||
|
||||
- `diffBase: 1.14` → `1.28`
|
||||
- `capBase: 28` → `34`
|
||||
- `spawnTempo: 0.88` → `0.78`
|
||||
- opening density: `12` → `16`
|
||||
|
||||
### 적 HP 스케일링 보강
|
||||
|
||||
일반/엘리트 적이 스킬 몇 개에 바로 삭제되지 않도록 기본 HP 공식을 조정했다.
|
||||
|
||||
추가 요소:
|
||||
|
||||
- 스테이지별 HP 증가
|
||||
- 플레이어가 예상보다 높은 Tac Level일 때 적 HP 보정
|
||||
- 엘리트 HP 배율 상향
|
||||
|
||||
이 보정은 플레이어가 잘 성장했을 때도 적이 최소한 화면에 들어와 압박을 만들도록 하기 위한 안전장치다.
|
||||
|
||||
### 폭탄 비주얼 개선
|
||||
|
||||
기존 폭탄은 얇은 원형 렌더링에 가까워 비주얼 피드백이 약했다. 이제 폭탄 사용 시 발동 위치를 저장하고, 그 지점에서 Magitech shockwave가 확장된다.
|
||||
|
||||
추가된 연출:
|
||||
|
||||
- 고정된 폭발 원점
|
||||
- 시안/라임/골드 3중 마법공학 링
|
||||
- 점선 링 회전
|
||||
- 중심 코어 플래시
|
||||
- 방사형 에너지 라인
|
||||
- 밝은 라디얼 플래시
|
||||
|
||||
Space/X를 눌렀을 때 “화면을 정리하는 기술”이라는 감각이 더 강해지도록 했다.
|
||||
|
||||
### 적기 외형 다양성 개선
|
||||
|
||||
기존 적기 스프라이트 선택은 역할별 고정값이 많아 반복감이 컸다. 이제 역할과 스테이지, 약간의 랜덤 salt를 반영해 더 다양한 스프라이트를 선택한다.
|
||||
|
||||
적용 대상:
|
||||
|
||||
- 일반 적
|
||||
- 엘리트 적
|
||||
- 미니보스
|
||||
|
||||
미니보스는 패턴별로 크기와 발광색도 달라져 작은 보스전처럼 보이게 했다.
|
||||
|
||||
### 보스 외형 다양성 개선
|
||||
|
||||
보스는 `spriteIdx`가 명시되지 않아 사실상 같은 보스 타일만 반복 사용되는 문제가 있었다. 이제 스테이지별 보스 비주얼 프로필을 갖는다.
|
||||
|
||||
프로필 요소:
|
||||
|
||||
- 보스 스프라이트 인덱스
|
||||
- 보스 크기
|
||||
- 보스 가로/세로 비율
|
||||
- 날개 포탑 위치
|
||||
- 하단 포탑 위치
|
||||
- 발광 액센트 색상
|
||||
|
||||
이제 Stage 1-8 보스는 같은 시스템을 쓰더라도 외형, 크기, 포탑 배치가 다르게 보인다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 패스의 핵심은 “초반은 읽기 쉽게, 중반은 무적감이 너무 빨리 오지 않게” 만드는 것이다.
|
||||
|
||||
원하는 플레이 감각은 다음과 같다.
|
||||
|
||||
1. Stage 1 초반: 탄을 보고 피하는 법을 배운다.
|
||||
2. Stage 1 중반: 첫 빌드가 강해지는 재미를 느낀다.
|
||||
3. Stage 1 후반: 미니보스와 보스로 빌드 검증을 한다.
|
||||
4. Stage 2: 성장한 상태지만 적도 더 빨리/많이 들어와 다시 긴장감이 생긴다.
|
||||
5. Stage 3: 단일 무기 강화만으로는 부족하고 광역/방어/관통 선택의 의미가 생긴다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/balance.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/weapon[[Behavior]]s.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/PlayerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/StageDirectorSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/WeaponBehaviorEngine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/22`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- Stage 1 첫 60초 탄속이 “부담스럽지만 불공정하지 않은지” 확인한다.
|
||||
- Stage 1 후반 Tac Level이 대략 3-5 사이인지 확인한다.
|
||||
- Stage 2 시작 시 적이 화면 안에 들어오기 전에 삭제되는 현상이 줄었는지 확인한다.
|
||||
- Space/X 폭탄 사용 시 충분히 강한 시각 피드백이 있는지 확인한다.
|
||||
- Stage 1-3 보스가 서로 다른 외형과 크기로 인식되는지 확인한다.
|
||||
- Stage 2-3에서 피격 압박은 생겼지만, 갑자기 불합리하게 어려워지지는 않았는지 확인한다.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+208
@@ -0,0 +1,208 @@
|
||||
---
|
||||
id: wiki-2026-0508-2026-04-26-skybound-stage-minibo
|
||||
title: 2026 04 26 Skybound Stage Miniboss Pattern Differentiation
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Skybound Stage Miniboss Pattern Differentiation
|
||||
|
||||
작성일: 2026-04-26 09:44 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- 미니보스 보상 루프 다음 단계로, 8개 스테이지마다 미니보스 전투 패턴을 다르게 만든다.
|
||||
- `Command Cache`를 얻는 과정 자체가 작은 보스전처럼 느껴지게 한다.
|
||||
- 스테이지가 올라갈수록 압박 방식이 달라져 반복감을 줄이고, 플레이어가 이동/회피/빌드 선택을 더 의식하게 만든다.
|
||||
|
||||
## 핵심 방향
|
||||
|
||||
기존 미니보스는 내부적으로 `ELITE + COMMANDER`에 가까웠고, 일반 적 사격 규칙을 타고 있었다. 그래서 미니보스를 처치하면 보상은 의미 있어졌지만, 전투 자체는 “체력이 많은 엘리트”처럼 느껴질 위험이 있었다.
|
||||
|
||||
이번 변경은 미니보스를 아래 역할로 재정의한다.
|
||||
|
||||
1. 각 스테이지 중반의 작은 실력 체크
|
||||
2. 스테이지 기믹을 미리 보여주는 압박 패턴
|
||||
3. `Command Cache` 보상을 얻기 위한 전투 목표
|
||||
4. 보스전 전 빌드가 충분한지 검증하는 중간 관문
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 미니보스 패턴 타입 추가
|
||||
|
||||
`SystemEnemy`에 미니보스 전용 패턴 상태를 추가했다.
|
||||
|
||||
- `miniBossPattern`
|
||||
- `miniBossTimer`
|
||||
- `miniBossCooldown`
|
||||
- `miniBossDashFrames`
|
||||
- `miniBossAction[[Seed]]`
|
||||
- `dashTargetX`
|
||||
- `dashTargetY`
|
||||
|
||||
일반 적 AI에는 영향을 주지 않고, `isMiniBoss`가 true인 적만 전용 이동/사격 로직을 사용한다.
|
||||
|
||||
### 스테이지별 패턴 매핑
|
||||
|
||||
`SpawnerSystem`에서 현재 스테이지에 따라 미니보스 패턴을 자동 부여한다.
|
||||
|
||||
- Stage 1: `DUELIST`
|
||||
- Stage 2: `DASH_RAIDER`
|
||||
- Stage 3: `DRONE_CALLER`
|
||||
- Stage 4: `BARRAGE_WALL`
|
||||
- Stage 5: `MINE_LAYER`
|
||||
- Stage 6: `DRONE_RING`
|
||||
- Stage 7: `[[Blink]]_SNIPER`
|
||||
- Stage 8: `OMEGA_COMMANDER`
|
||||
|
||||
### 전용 이동 AI 추가
|
||||
|
||||
`CombatSystem`에서 미니보스는 기존 `role` 기반 AI 대신 `updateMiniBossAI`를 탄다.
|
||||
|
||||
패턴별 이동/행동은 다음과 같다.
|
||||
|
||||
- `DUELIST`: 플레이어 x축을 따라가며 기본 팬샷 압박
|
||||
- `DASH_RAIDER`: 짧은 예고 후 플레이어 방향으로 돌진
|
||||
- `DRONE_CALLER`: 좌우에 스팅어 호위기를 주기적으로 소환
|
||||
- `BARRAGE_WALL`: 화면 가로 라인을 오가며 안전 구멍이 있는 탄막벽 생성
|
||||
- `MINE_LAYER`: 플레이어 근처에 위험 구름/지뢰형 압박 구역 생성
|
||||
- `DRONE_RING`: 헌터 호위기와 링 탄막으로 공간 압박
|
||||
- `BLINK_SNIPER`: 위치를 순간이동하며 빠른 저격 탄을 발사
|
||||
- `OMEGA_COMMANDER`: 팬샷, 링 탄막, 지뢰, 블링크를 순환하는 최종형 미니보스
|
||||
|
||||
### 전용 사격 패턴 추가
|
||||
|
||||
`spawnMiniBossBulletPattern`을 추가해 미니보스 사격을 일반 적과 분리했다.
|
||||
|
||||
- 팬샷
|
||||
- 빠른 저격탄
|
||||
- 링 탄막
|
||||
- 안전 구멍이 있는 라인 탄막
|
||||
- 느린 중력/지뢰형 탄
|
||||
- 최종 스테이지 혼합 패턴
|
||||
|
||||
스테이지가 올라가면 탄 수와 쿨다운이 자연스럽게 강해진다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 변경은 “보상을 얻는 과정”을 재미있게 만들기 위한 작업이다.
|
||||
|
||||
이전 구조:
|
||||
|
||||
- 미니보스 등장
|
||||
- 체력이 많은 적을 처치
|
||||
- 보상 선택
|
||||
|
||||
변경 후 구조:
|
||||
|
||||
- 스테이지별 다른 압박을 가진 미니보스 등장
|
||||
- 사용자는 이동/회피/빌드 강점을 이용해 작은 보스전을 해결
|
||||
- 처치하면 `Command Cache`를 열고 빌드를 강화
|
||||
- 다음 구간을 버틸 준비가 된다
|
||||
|
||||
이렇게 하면 미니보스가 단순 보상 트리거가 아니라, 스테이지 리듬의 핵심 이벤트가 된다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png [[Reference]]d in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
|
||||
## 후속 작업 제안
|
||||
|
||||
- 실제 플레이에서 Stage 4 `BARRAGE_WALL`과 Stage 7 `BLINK_SNIPER`의 탄속/쿨다운을 체감 기준으로 조정한다.
|
||||
- 미니보스 등장 시 패턴 이름을 더 상품성 있는 경고 문구로 표시한다.
|
||||
- 미니보스별 외형 색상, 엔진 이펙트, 코어 형태를 패턴에 맞게 분리한다.
|
||||
- `Command Cache` 오픈 전 0.5초 컷인 연출을 추가해 전투 승리 보상감을 더 강화한다.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-accessibility-a11y
|
||||
title: Accessibility (A11y)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Accessibility (A11y)|Accessibility (A11y]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
접근성([[Accessibility|Accessibility]], A11y)은 스크린 리더, 키보드 네비게이션 등을 지원하여 모든 사용자가 차별 없이 UI를 이용할 수 있도록 하는 설계 원칙 및 기능입니다 [1, 2]. React 컴포넌트 아키텍처와 디자인 시스템에서 재사용성은 접근성과 뗄 수 없는 관계를 가지며, ARIA 속성 및 시맨틱 HTML 적용을 기본으로 합니다 [3, 4]. 잘 설계된 컴포넌트 라이브러리와 아키텍처 패턴은 개발자가 처음부터 접근성을 구현할 필요 없이, 접근성 테마 모드나 포커스 관리 등과 같은 내장된 접근성 지원을 제공합니다 [1, 5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **재사용 가능한 컴포넌트와 접근성 우선(Accessibility First) 원칙**
|
||||
재사용 가능한 컴포넌트를 설계할 때 접근성은 선택 사항이 아니라 필수 사항입니다 [2]. 키보드 탭 순서 관리, 화살표 키 탐색, 올바른 시맨틱 HTML 역할(Roles)과 레이블, 포커스 제어 및 오류 메시지 제공 등은 컴포넌트의 핵심 기능에 내장(Bake into the DNA)되어야 합니다 [2, 6]. 컴포넌트가 진화하더라도 접근성 역할, 레이블, 포커스 상태가 깨지지 않는지 확인하기 위해 지속적인 접근성 검사(Accessibility checks)가 필요합니다 [7].
|
||||
|
||||
@@ -22,10 +41,64 @@
|
||||
* **대규모 접근성 문서화 및 관리 자동화**
|
||||
Uber와 같은 대규모 환경에서는 VoiceOver, TalkBack, ARIA와 같은 3가지 접근성 API를 커버해야 하며, 각각 수백 개의 속성이 존재하기 때문에 수동으로 스펙을 관리하기 어렵습니다 [14]. 이를 해결하기 위해 AI 에이전트([[Figma|Figma]] Console MCP 활용)를 도입하여 컴포넌트 트리를 스크랩하고 다중 플랫폼의 스크린 리더 및 접근성 속성을 단 몇 분 만에 포괄적인 스펙 문서로 자동 렌더링하는 자동화 파이프라인을 구축하여 접근성 기준을 유지합니다 [15-18].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Compound Components|Compound Components]], Headless Components, Design Tokens, [[Tailwind CSS|Tailwind CSS]]
|
||||
- **Projects/Contexts:** [[Uber Base Web|Uber Base Web]], Shopify Polaris, [[React Component Library Architecture|React Component Library Architecture]]
|
||||
- **Contradictions/Notes:** 컴포넌트 레벨에서의 접근성 내장 여부에서 프레임워크 간 차이가 발생합니다. [[Shopify Polaris|Shopify Polaris]]나 [[Uber Base Web|Uber Base Web]] 등의 완전한 UI 컴포넌트 라이브러리는 ARIA 및 키보드 조작과 같은 접근성을 기본으로 제공하지만 [1, 3, 12], Tailwind CSS를 단독으로 사용할 경우 자동으로 접근성 태그를 부여하지 않으므로 개발자가 직접 시맨틱 마크업과 ARIA 속성을 챙겨야 한다는 명확한 한계(책임의 전가)를 지적하고 있습니다 [4].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-automatic-batching
|
||||
title: Automatic Batching
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Automatic Batching|Automatic Batching]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Automatic [[Batching|Batching]](자동 배칭)은 React 18에 도입된 기능으로, 여러 상태(State) 업데이트를 하나의 리렌더링으로 그룹화하여 처리하는 성능 최적화 기법입니다 [1-3]. 이전 버전에서는 React의 네이티브 이벤트 핸들러 내의 업데이트만 배칭되었으나, React 18부터는 프로미스(Promise), setTimeout, 비동기 작업 등 출처와 무관하게 모든 상태 업데이트를 자동으로 배칭합니다 [2, 4-6]. 이를 통해 불필요한 리렌더링과 [[Virtual DOM|Virtual DOM]]의 비교 연산(diffing)을 최소화하여 애플리케이션의 성능과 UI 응답성을 크게 향상시킵니다 [4, 7].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **작동 원리 및 도입 배경:**
|
||||
React 18 이전에는 `onClick`과 같은 React 내부 이벤트 핸들러에서 발생하는 상태 업데이트만 배칭 처리가 되었습니다 [2, 6]. 따라서 `setTimeout`이나 비동기 API 호출 내에서 상태를 여러 번 업데이트할 경우, 각 업데이트마다 개별적인 리렌더링이 발생하여 성능 저하의 원인이 되었습니다 [2, 8]. React 18의 자동 배칭 기능은 이벤트 출처와 상관없이 모든 상태 업데이트를 하나로 묶어(Batch) 단 한 번의 렌더링과 DOM 업데이트만 트리거합니다 [3, 7, 9, 10].
|
||||
|
||||
@@ -16,10 +36,64 @@ Automatic [[Batching|Batching]](자동 배칭)은 React 18에 도입된 기능
|
||||
* **주의사항 및 디버깅:**
|
||||
자동 배칭은 기본적으로 제공되는 최적화지만, 일부 서드파티 상태 관리 도구나 UI 라이브러리가 React의 이벤트 시스템을 우회하는 방식으로 동작할 경우 배칭이 제대로 적용되지 않을 수 있습니다 [16, 17]. 이러한 예외 상황을 식별하기 위해서는 React DevTools Profiler를 사용하여 컴포넌트의 렌더링 횟수와 업데이트 트리거를 모니터링하는 것이 권장됩니다 [16].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Virtual DOM|Virtual DOM]], [[React가 빠른 이유|React가 빠른 이유]], Reflow / Repaint 최소화 방법
|
||||
- **Projects/Contexts:** [[React 18|React 18]], [[Performance Optimization|Performance Optimization]]
|
||||
- **Contradictions/Notes:** 자동 배칭은 성능을 크게 향상시키지만 무조건적으로 유용한 것은 아닙니다. 폼의 입력 값 업데이트나 요소 포커싱처럼 사용자에게 지연 없는 즉각적 피드백을 제공해야 하는 필수적인 상황에서는 `flushSync`를 사용해 배칭을 해제해야 하며, 이를 남용할 경우 배칭으로 얻는 성능 이점을 상쇄할 수 있으므로 주의해야 합니다 [13, 18]. 또한 서드파티 라이브러리 통합 시 React 이벤트 시스템을 우회하면 자동 배칭이 무력화될 수 있다는 함정이 존재합니다 [17].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-bem-block-element-modifier
|
||||
title: BEM (Block Element Modifier)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[BEM (Block Element Modifier)|BEM (Block Element Modifier]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
BEM(Block Element Modifier)은 모듈식이고 재사용 가능하며 충돌 없는 UI 컴포넌트를 구축하기 위해 고안된 검증된 CSS 아키텍처 방법론이다 [1]. 깊게 중첩된 선택자 대신 평면적이고 명시적이며 스스로를 설명할 수 있는 클래스 명명 규칙을 도입하여 CSS를 구조화한다 [2, 3]. 이를 통해 대규모 프론트엔드 프로젝트에서 전역 네임스페이스 충돌을 방지하고 CSS의 예측 가능성과 유지보수성을 높이는 것을 핵심 목적으로 한다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **BEM의 구조 및 명명 규칙:**
|
||||
* BEM은 독립적으로 의미를 가지는 재사용 가능한 UI 컴포넌트인 '블록(Block)', 블록에 종속되어 독립적으로 존재할 수 없는 하위 요소인 '엘리먼트(Element)', 그리고 모양이나 상태의 변화를 나타내는 '모디파이어(Modifier)'로 구성된다 [3, 6, 7].
|
||||
* 엘리먼트는 이중 밑줄(`__`)로 구분하고(예: `card__title`), 모디파이어는 이중 하이픈(`--`)으로 구분한다(예: `button--primary`) [6-8].
|
||||
@@ -23,10 +43,64 @@ BEM(Block Element Modifier)은 모듈식이고 재사용 가능하며 충돌 없
|
||||
* 최근의 React 등 컴포넌트 기반 환경에서는 BEM이 해결하려 했던 전역 CSS 충돌 문제를 자동으로 해결해주는 [[CSS Modules|CSS Modules]]가 선호되는 경향이 있다 [18, 19].
|
||||
* 그러나 공유 유틸리티, 전역 디자인 시스템, 혹은 컴포넌트 라이브러리에서 테마를 덮어써야 하는 화이트라벨(whitelabel) 앱 환경 등에서는 BEM의 명시적 구조가 여전히 매우 유용하게 사용된다 [19-21].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[CSS Modules|CSS Modules]], Tailwind CSS, CSS-in-JS, [[CSS Architecture|CSS Architecture]]
|
||||
- **Projects/Contexts:** 대규모 프론트엔드 프로젝트 유지보수, 컴포넌트 기반 UI 설계, [[디자인 시스템 구축|디자인 시스템 구축]]
|
||||
- **Contradictions/Notes:** BEM은 명시적이고 예측 가능한 스타일링을 제공하여 유지보수성을 극대화하지만 [1, 9], 인간의 수동 관리에 의존해야 한다는 명확한 한계가 존재한다 [5, 14]. 이로 인해 오늘날의 실무에서는 빌드 단계에서 자동으로 고유 클래스명을 보장하는 CSS Modules나, 유틸리티 클래스 기반으로 재사용성을 높인 [[Tailwind CSS|Tailwind CSS]]와 종종 비교되거나 상호 보완적으로 사용된다 [8, 21-23].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-bem
|
||||
title: BEM
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[BEM|BEM]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
BEM(Block Element Modifier)은 모듈화되고 재사용 가능하며 충돌이 없는 UI 컴포넌트를 구축하기 위해 고안된 CSS 아키텍처 및 네이밍 규칙론입니다 [1]. 클래스 이름을 블록(Block), 요소(Element), 상태/변형(Modifier)이라는 세 가지 구성 요소로 명확히 나누어 작성함으로써 CSS의 전역 스코프(Global Scope)로 인해 발생하는 복잡성과 이름 충돌 문제를 방지합니다 [2-4]. 이를 통해 대규모 프론트엔드 프로젝트에서도 CSS를 예측 가능하고 유지보수하기 쉽게 관리할 수 있도록 돕습니다 [5].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **BEM의 핵심 구성 요소:**
|
||||
- **Block (블록):** `card`, `button`, `navigation` 등과 같이 스스로 의미를 가지며 독립적으로 재사용 가능한 UI 컴포넌트 단위입니다 [3]. 주변 DOM 구조에 의존하지 않고 기능해야 합니다 [3].
|
||||
- **Element (요소):** 블록에 종속된 하위 구성 요소로, 독립적으로 존재할 수 없습니다 [6]. 이중 밑줄(`__`)을 사용하여 표기합니다(예: `card__title`, `card__image`) [6].
|
||||
@@ -19,10 +39,64 @@ BEM(Block Element Modifier)은 모듈화되고 재사용 가능하며 충돌이
|
||||
- **장황함(Verbosity) 극복:** BEM의 주된 비판 중 하나는 클래스 이름이 길고 장황해진다는 점입니다 [12]. 하지만 [[SCSS|SCSS]]나 Less 같은 CSS 전처리기를 사용하면 부모 참조(`&`)와 중첩(Nesting) 기능을 통해 BEM을 훨씬 효율적이고 깔끔하게 작성할 수 있습니다 [16, 17].
|
||||
- **휴먼 에러의 한계:** BEM은 개발자의 자발적인 규칙 준수에 의존하는 '수동적인' 보장 방식입니다 [18, 19]. 따라서 프로젝트가 커지고 시간이 지날수록 규칙이 깨지거나 이름이 충돌할 위험성을 완전히 배제할 수는 없습니다 [18, 20].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[CSS Modules|CSS Modules]], Tailwind CSS, SCSS, [[CSS Architecture|CSS Architecture]]
|
||||
- **Projects/Contexts:** [[디자인 시스템 개념|디자인 시스템 개념]], 컴포넌트 기반 아키텍처 (React, Vue 등), [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD]]
|
||||
- **Contradictions/Notes:** 소스 문헌들에서는 BEM과 [[CSS Modules|CSS Modules]]의 근본적인 접근 방식을 비교하고 있습니다. BEM은 고유한 네이밍 패턴을 '수동으로' 작성하여 충돌을 막으려는 시도인 반면, CSS Modules는 빌드 시점에 해시된 고유 식별자를 생성해 스코프 제한을 '자동으로' 해결합니다 [19, 21]. 이러한 이유로 현대의 React/TypeScript 기반 생태계에서는 BEM의 원래 목적이 CSS Modules로 대체될 수 있어 CSS Modules가 더 자연스럽다는 주장이 있습니다 [22, 23]. 그러나 여전히 글로벌 디자인 시스템의 토큰 및 유틸리티 구성이나 리팩토링 관점에서는 BEM이 유용하다는 시각도 공존합니다 [13, 24].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-723577
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-batching
|
||||
title: Batching
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-723577]
|
||||
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 - Batching"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Batching|Batching]]
|
||||
@@ -23,7 +34,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Batching"
|
||||
* **UI 레이아웃 및 DOM 성능 최적화**
|
||||
웹 성능 지표([[Core Web Vitals|Core Web Vitals]]) 중 하나인 INP(Interaction to Next Paint)를 최적화하기 위해서도 배칭 개념이 쓰입니다. 읽기 작업 직후 쓰기 작업을 수행하여 발생하는 과도한 동기식 레이아웃 재계산(레이아웃 스래싱)을 방지하기 위해, DOM 읽기 및 쓰기 작업을 현명하게 배칭(Batch)하여 처리하는 것이 권장됩니다 [5].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -36,3 +47,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Batching"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-[[Branded-Types|Branded-Types]]
|
||||
category: Unified
|
||||
id: wiki-2026-0508-branded-types-for-nominal-typing
|
||||
title: Branded Types for Nominal Typing
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [TypeScript, TypeSystem, NominalTyping, Safety]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Branded-Types-for-Nominal-Typing|Branded-Types-for-Nominal-Typing]] (브랜디드 타입을 활용한 공칭 타입화)
|
||||
@@ -21,9 +33,58 @@ last_reinforced: 2026-04-20
|
||||
- **[[Type Casting|Type Casting]]**:
|
||||
- 데이터를 생성할 때 `as Email`과 같은 단언(Assertion)을 사용하여 브랜드를 부여한다. 이후 시스템은 이 '낙인'이 찍힌 데이터만 특정 함수로 전달될 수 있도록 보장한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 브랜디드 타입은 런타임에는 실체가 없는 '컴파일 타임 전용 장치'다. 따라서 실제 런타임 데이터 유효성 검사(Zod 등)와 병행해야 하며, 지나친 사용은 코드 가독성을 해칠 수 있음에 주의해야 한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Structural-Type-System , Type-Safety
|
||||
- Tools: Zod-Runtime-Validation
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-B20BA9
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-buffer-allocation
|
||||
title: Buffer Allocation
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-B20BA9]
|
||||
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 - Buffer Allocation"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Buffer Allocation|Buffer Allocation]]
|
||||
@@ -19,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Buffer Allocation"
|
||||
* **오브젝트 풀링(Object [[Pooling|Pooling]]) 활용:** 객체를 빈번하게 생성하고 파괴하는 작업은 버퍼 할당 오버헤드와 가비지 컬렉션(GC)에 의한 일시 정지를 유발합니다. 런타임 할당 스파이크를 피하려면 로딩 단계에서 풀을 미리 데워두는(Pre-warm) 방식의 오브젝트 풀링을 사용해야 합니다 [6].
|
||||
* **버퍼 재할당 시 메모리 누수 주의:** WebGL 컨텍스트는 디바이스에 따라 유한한 메모리 한도(일반적으로 256MB~1GB)를 가지며, 한도를 초과하면 뷰어가 다운될 수 있습니다 [7]. 또한, 기존의 인스턴스 메쉬 자원을 깔끔하게 폐기(Dispose)하지 못한 상태에서 동적으로 버퍼 용량을 늘리려 할 경우 메모리 누수가 발생할 수 있습니다 [8].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -32,3 +43,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Buffer Allocation"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,7 +1,27 @@
|
||||
## 📌 Brief Summary
|
||||
---
|
||||
id: wiki-2026-0508-bundle-size-optimization
|
||||
title: Bundle Size Optimization
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Bundle Size Optimization(번들 크기 최적화)은 클라이언트로 전송되는 자바스크립트 자산의 물리적 용량을 최소화하여 초기 로딩 성능(LCP)과 런타임 반응성(TBT/INP)을 개선하는 기술적 공정이다. 코드 분할(Code Splitting), 지연 로딩(Lazy Loading), 트리 쉐이킹 등을 통해 브라우저의 파싱 및 실행 오버헤드를 근본적으로 줄이는 것을 목표로 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
1. **번들 팽창의 원인 진단**
|
||||
- 단일 엔트리 포인트(`index.js`)에 모든 종속성(React, heavy libraries)이 결합된 구조.
|
||||
- 무분별한 Eager Import와 거대한 전이적 종속성(Transitive Dependencies)으로 인한 메인 스레드 점유율 상승.
|
||||
@@ -16,12 +36,12 @@ Bundle Size Optimization(번들 크기 최적화)은 클라이언트로 전송
|
||||
5. **분석 및 정제 도구 활용**
|
||||
- `rollup-plugin-visualizer` 또는 Webpack Bundle Analyzer를 통해 번들 내부의 'Bloat'을 시각적으로 식별하고 제거.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **워터폴(Waterfall) 현상**: 지연 로딩을 남발할 경우 청크 간의 의존성으로 인해 순차적 로딩 지연이 발생하여 체감 성능이 오히려 저하될 수 있다.
|
||||
- **네트워크 요청 수 증가**: 번들을 너무 작게 쪼개면 HTTP 요청 수가 급증하여 네트워크 오버헤드가 발생할 수 있으므로 적절한 청크 사이즈(예: 30KB~100KB) 유지가 필요하다.
|
||||
- **캐시 무효화 관리**: 청크 분할 전략이 잘못될 경우 작은 코드 수정에도 모든 벤더 청크의 해시가 변경되어 캐시 효율이 떨어질 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Code Splitting]]
|
||||
* [[Core_Web_Vitals]]
|
||||
@@ -53,3 +73,52 @@ Bundle Size Optimization(번들 크기 최적화)은 클라이언트로 전송
|
||||
- **Brotli / Gzip Compression**
|
||||
- **Tree Shaking & ES Modules**
|
||||
- **HTTP/2 & HTTP/3 Multi-plexing**
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-38FA31
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-cpu-overhead
|
||||
title: CPU Overhead
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-38FA31]
|
||||
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 - CPU Overhead"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[CPU Overhead|CPU Overhead]]
|
||||
@@ -22,7 +33,7 @@ github_commit: "[P-Reinforce] Continuous Worker - CPU Overhead"
|
||||
* **WebGPU와 구조적 최적화를 통한 해결:**
|
||||
WebGPU는 멀티 스레드를 통한 렌더링 명령 준비와 명시적이고 정적인 리소스 관리(GPU 리소스 읽기 전용화 등)를 지원하여 CPU 측의 재검증 오버헤드를 획기적으로 줄입니다 [4, 5, 16-18]. 컴퓨트 셰이더를 사용하여 물리 시뮬레이션이나 입자 시스템 같은 연산 논리를 GPU로 오프로딩하면 CPU-GPU 간의 왕복 통신과 JavaScript 실행 지연을 최소화하는 'GPU 주도(GPU-driven)' 렌더링이 가능해집니다 [13, 19]. 또한, 엔진 차원에서는 인스턴싱이나 배칭([[Batching|Batching]])을 통해 절대적인 드로우 콜 횟수를 최소화하는 것이 오버헤드 감소의 핵심입니다 [8, 20].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -35,3 +46,52 @@ github_commit: "[P-Reinforce] Continuous Worker - CPU Overhead"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-css-grid-및-flexbox
|
||||
title: CSS Grid 및 Flexbox
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[CSS Grid 및 Flexbox|CSS Grid 및 Flexbox]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
CSS [[Flexbox|Flexbox]]와 [[CSS Grid|CSS Grid]]는 웹 페이지의 요소들을 배치하고 정렬하기 위해 도입된 최신 CSS 레이아웃 모듈입니다 [1-3]. Flexbox는 행(Row)이나 열(Column) 중 하나의 방향으로 요소를 배치하는 1차원 레이아웃에 특화되어 있으며, CSS Grid는 행과 열을 동시에 제어하는 2차원 레이아웃 시스템입니다 [4-6]. 이 두 기술은 과거의 float이나 복잡한 위치 지정(positioning) 방식을 대체하여, 예측 가능하고 유지보수가 용이한 반응형 디자인을 구축하는 핵심 도구로 사용됩니다 [7-9].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**1. Flexbox (1차원 레이아웃 및 컴포넌트 정렬)**
|
||||
* **목적 및 특징:** Flexbox는 단일 차원(행 또는 열)에서 항목을 정렬하고 간격을 분배하는 데 최적화되어 있습니다 [4, 9, 10]. 주로 내비게이션 바, 폼 필드, 카드 컴포넌트 내의 텍스트와 이미지 정렬 등 소규모 레이아웃에 적합합니다 [3, 11, 12].
|
||||
* **동작 원리 (Content-out):** Flexbox는 '콘텐츠 중심(Content-out)'으로 동작합니다. 요소들의 내부 콘텐츠 크기에 따라 항목이 커지거나(`flex-grow`) 줄어들며(`flex-shrink`), 가용 공간을 유연하게 채웁니다 [1, 13-16]. 화면 크기가 줄어들면 `flex-wrap` 속성을 통해 자연스럽게 다음 줄로 넘어가게 할 수 있습니다 [17, 18].
|
||||
@@ -22,10 +42,64 @@ CSS [[Flexbox|Flexbox]]와 [[CSS Grid|CSS Grid]]는 웹 페이지의 요소들
|
||||
* 그런 다음 개별 그리드 셀 내부에 들어가는 버튼 그룹, 아이콘, 텍스트 등의 요소들을 정렬할 때는 Flexbox를 활용합니다 [35, 36].
|
||||
* 이러한 하이브리드 접근 방식은 불필요한 래퍼(Wrapper) 요소의 중첩을 줄여 DOM 구조를 가볍게 만들고, 브라우저 렌더링 성능과 코드의 유지보수성을 크게 향상시킵니다 [35, 37-39].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[반응형 디자인|반응형 디자인]], CSS 아키텍처, [[BEM|BEM]]
|
||||
- **Projects/Contexts:** 대규모 프론트엔드 아키텍처 최적화, 컴포넌트 기반 UI/UX 설계
|
||||
- **Contradictions/Notes:** Flexbox와 CSS Grid는 서로를 대체하는 기술이 아닙니다 [40, 41]. 오히려 Flexbox는 1차원 정렬(예: 한 줄 또는 한 열의 아이템 배치)에 직관적이고 적합하며, CSS Grid는 2차원의 복잡한 구조 배치에 강점을 지니므로 두 기술을 상호 보완적으로 함께 사용해야 완벽한 레이아웃 시스템을 설계할 수 있다고 여러 소스에서 강조합니다 [8, 36, 39, 40].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-css-grid
|
||||
title: CSS Grid
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[CSS Grid|CSS Grid]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
CSS Grid는 행(Row)과 열(Column)을 동시에 다루어 복잡하고 체계적인 웹 페이지 구조를 설계할 수 있도록 돕는 2차원 레이아웃 시스템입니다 [1, 2]. [[Flexbox|Flexbox]]와 달리 레이아웃 구조를 먼저 정의하고 요소를 배치하는 '레이아웃 우선(layout in)' 방식을 취하며, 대규모 페이지 레이아웃이나 대시보드, 갤러리 등 정밀한 배치가 필요한 곳에 가장 적합합니다 [3-5].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **2차원 레이아웃 제어:**
|
||||
* 1차원(행 또는 열)으로만 작동하는 Flexbox와 다르게, CSS Grid는 가로와 세로 두 방향의 레이아웃을 동시에 제어할 수 있습니다 [2, 6].
|
||||
* 복잡한 중첩 컨테이너를 생성할 필요 없이 깔끔한 마크업으로 복잡한 디자인(예: 헤더, 푸터, 사이드바, 메인 콘텐츠 배치)을 쉽게 구현할 수 있습니다 [7, 8].
|
||||
@@ -20,10 +40,64 @@ CSS Grid는 행(Row)과 열(Column)을 동시에 다루어 복잡하고 체계
|
||||
* 모던 프론트엔드 아키텍처에서는 CSS Grid와 Flexbox 중 하나만 선택하는 것이 아니라, 목적에 맞게 두 가지를 혼용하는 것이 핵심입니다 [24, 25].
|
||||
* 전체 페이지의 구조(Major layout)나 대규모 뼈대는 2차원인 **CSS Grid**로 잡고, 해당 셀 내부에 들어가는 UI 컴포넌트들의 세부적인 정렬은 1차원인 **Flexbox**로 처리하는 것이 유지보수성 높은 코드를 작성하는 모범 사례입니다 [26-29].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Flexbox|Flexbox]], [[반응형 디자인|반응형 디자인]]
|
||||
- **Projects/Contexts:** 유지보수 가능한 CSS 레이아웃 설계, 웹 페이지 및 대시보드 구조화
|
||||
- **Contradictions/Notes:** Flexbox는 콘텐츠의 크기를 기반으로 공간을 분배하는 '콘텐츠 우선(content out)' 방식으로 동작하지만, CSS Grid는 정의된 레이아웃의 형태에 요소를 끼워 맞추는 '레이아웃 우선(layout in)' 방식을 취합니다 [5, 30]. CSS Grid가 더 복잡한 기능을 제공하지만 단순한 1차원 정렬(행, 열 내에서의 아이템 정렬)에 사용하기에는 과도한 설정(overkill)이 될 수 있으므로 상황에 맞게 Flexbox와 구별해 사용해야 합니다 [6, 27, 31].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,19 +1,93 @@
|
||||
---
|
||||
id: wiki-2026-0508-css-media-queries
|
||||
title: CSS Media Queries
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[CSS Media Queries|CSS Media Queries]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
CSS Media Queries(미디어 쿼리)는 뷰포트 너비, 화면 해상도, 방향 등의 특정 조건에 따라 각기 다른 CSS 스타일을 적용할 수 있게 해주는 규칙이다 [1, 2]. 이는 반응형 웹 디자인의 논리적 토대를 형성하며, 다양한 디바이스에 맞춰 단일 코드베이스로 레이아웃을 유연하게 조정할 수 있도록 돕는다 [1-3]. 또한, 특정 조건에서만 필요한 스타일을 분리하여 브라우저의 초기 렌더링 차단 현상을 방지하는 등 웹 성능 최적화에도 필수적인 역할을 한다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **반응형 디자인의 논리적 기반:** 미디어 쿼리는 뷰포트 너비뿐만 아니라 고해상도 디스플레이, 다크/라이트 모드, 가로/세로 화면 방향 등의 조건에 반응하여 각기 다른 CSS 규칙을 적용할 수 있게 해준다 [2, 6]. 이를 통해 모바일용과 데스크톱용 페이지를 따로 만들 필요 없이 유기적으로 적응하는 레이아웃을 구성할 수 있다 [1, 2].
|
||||
- **모바일 우선 설계 ([[Mobile-First Approach|Mobile-First Approach]]):** 미디어 쿼리 작성 시 가장 작은 화면(모바일)을 위한 기본 스타일을 먼저 정의한 후, `min-width` 쿼리를 사용해 화면이 커짐에 따라 점진적으로 복잡한 레이아웃이나 요소를 추가하는 것이 권장된다 [7-9]. 이 방식은 불필요한 스타일 덮어쓰기를 방지하여 코드를 논리적이고 유지보수하기 쉽게 만들어준다 [9].
|
||||
- **중단점(Breakpoints) 설정 원칙:** 특정 디바이스의 해상도 규격에 맞춰 중단점을 정하기보다는, 화면을 줄이거나 늘릴 때 콘텐츠의 레이아웃이 깨지기 시작하는 지점을 기준으로 설정해야 한다 [10]. 실무에서는 통상적으로 모바일(480px 이하), 태블릿(481~1024px), 데스크톱(1200px 이상) 등과 같은 구간을 활용한다 [2, 6, 10].
|
||||
- **렌더링 성능 최적화 (Optimizing Render [[Blocking|Blocking]]):** 브라우저는 CSS 파싱을 완료하기 전까지 화면 렌더링을 차단하지만, 미디어 쿼리를 활용하면 이 문제를 완화할 수 있다 [4]. HTML `<link>` 태그에 `media` 속성을 명시하여 인쇄용(print)과 같이 당장 필요하지 않은 스타일 시트를 분리하면, 브라우저가 해당 파일을 다운로드하더라도 렌더링 과정을 차단하지 않아 페이지 로딩 속도를 향상시킬 수 있다 [4, 5, 11].
|
||||
- **뷰포트 한계와 컴포넌트 중심 설계로의 진화:** 뷰포트 기반 미디어 쿼리는 화면 전체 크기에 반응할 뿐, 컴포넌트가 실제로 속해 있는 부모 컨테이너의 가용 공간을 인식하지 못하는 근본적인 한계를 지닌다 [12]. 따라서 디자인 시스템이나 모듈화된 설계를 위해, 2026년 현재는 부모 컨테이너의 크기에 맞춰 컴포넌트가 스스로 형태를 변경하는 컨테이너 쿼리([[Container Queries|Container Queries]])와 미디어 쿼리를 병행해서 사용하는 것이 표준으로 자리 잡았다 [12-14].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[반응형 디자인|반응형 디자인]], Container Queries, Mobile-First Design, [[CSS Performance Optimization|CSS Performance Optimization]]
|
||||
- **Projects/Contexts:** [[실무에서 CSS 관리하는 방법|실무에서 CSS 관리하는 방법]], [[디자인 시스템 개념|디자인 시스템 개념]]
|
||||
- **Contradictions/Notes:** 소스에서는 뷰포트 기반의 미디어 쿼리만으로는 완벽한 재사용 컴포넌트를 만드는 데 제약이 있다고 지적한다. 사이드바나 모달 등 다양한 컨텍스트(공간)에 독립적으로 반응해야 하는 컴포넌트를 설계할 때는 미디어 쿼리보다 컨테이너 쿼리를 사용하는 것이 더 적합하며, 이는 최근 반응형 디자인의 패러다임이 페이지 수준에서 컴포넌트 수준으로 이동했음을 보여준다 [12, 14-16].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-css-modules
|
||||
title: CSS Modules
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[CSS Modules|CSS Modules]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
CSS Modules는 표준 CSS 문법을 사용하면서도 빌드 단계에서 클래스명을 고유하게 변환하여 컴포넌트 단위로 스타일을 자동으로 스코핑(scoping)하는 CSS 아키텍처 접근법입니다 [1-3]. 전역 네임스페이스 충돌을 방지하기 위해 BEM과 같은 수동 규칙에 의존하는 대신, 도구를 통해 고유한 해시 클래스명을 생성함으로써 유지보수성을 극대화합니다 [4, 5]. 런타임 오버헤드가 없는 정적 CSS를 생성하므로 성능이 뛰어나며, React 및 [[Next.js|Next.js]]와 같은 최신 프레임워크 환경에서 전역 오염 없이 안전하게 UI를 구축할 수 있게 해줍니다 [6-8].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **동작 방식 및 특징:**
|
||||
CSS Modules를 사용하면 개발자는 익숙한 표준 CSS 문법을 그대로 작성할 수 있습니다 [6, 9]. 작성된 CSS 파일(`.module.css`)을 [[JavaScript|JavaScript]] 컴포넌트에 임포트하면, 빌드 도구가 `.button`과 같은 클래스명을 `Button_button__x9KdL`과 같은 고유한 식별자로 자동 변환합니다 [3, 9]. 또한, `composes` 기능을 통해 기존 스타일을 쉽게 확장할 수 있으며 [1], Sass([[SCSS|SCSS]])나 PostCSS와 같은 기존 CSS 도구와도 완벽하게 통합됩니다 [1, 10].
|
||||
|
||||
@@ -21,10 +41,64 @@ CSS Modules는 표준 CSS 문법을 사용하면서도 빌드 단계에서 클
|
||||
* **실무 활용 전략:**
|
||||
CSS Modules는 탄탄한 CSS 역량을 갖춘 팀이나, 복잡한 애니메이션 및 세밀한 CSS 제어가 필요한 프로젝트에 가장 적합합니다 [14]. 특히 2025년 기준 [[Next.js App Router|Next.js App Router]]와 같은 [[React Server Components|React Server Components]](RSC) 환경에서는 런타임 CSS-in-JS 라이브러리의 호환성 문제로 인해 Tailwind CSS나 CSS Modules를 사용하는 것이 강력히 권장됩니다 [8, 15]. 대규모 프로젝트의 실무에서는 레이아웃과 간격에는 빠르고 일관된 Tailwind CSS를 사용하고, 복잡한 커스텀 로직이나 애니메이션이 필요한 컴포넌트 스타일에는 CSS Modules를 사용하는 방식으로 두 기술의 장점을 결합한 하이브리드 아키텍처를 채택하기도 합니다 [16-18].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[BEM|BEM]], Tailwind CSS, CSS-in-JS, [[SCSS|SCSS]]
|
||||
- **Projects/Contexts:** [[컴포넌트 기반 아키텍처|컴포넌트 기반 아키텍처]], React Server Components, [[Next.js App Router|Next.js App Router]]
|
||||
- **Contradictions/Notes:** 소스 문헌들은 BEM이 개발자의 수동적인 명명 규칙 준수에 의존해 휴먼 에러가 발생하기 쉬운 반면, CSS Modules는 빌드 도구를 통해 "자동화된 캡슐화"를 제공하여 BEM이 풀고자 했던 문제를 더 깔끔하게 해결한다고 비교합니다 [4, 5, 11, 13]. 또한, Tailwind CSS는 클래스명을 짓는 수고와 파일 전환의 피로를 없애주지만 마크업 코드가 길어지고 자의적인 값이 쌓일 수 있는 반면, CSS Modules는 깔끔한 HTML을 유지하지만 파일 전환과 네이밍 피로가 존재한다는 트레이드오프 관계를 가집니다 [7, 14, 19, 20].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 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,98 @@
|
||||
---
|
||||
id: wiki-2026-0508-css-구조-설계-방식
|
||||
title: CSS 구조 설계 방식
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[CSS 구조 설계 방식]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
CSS 구조 설계 방식은 웹 프론트엔드 프로젝트가 대규모로 확장됨에 따라 발생하는 전역 네임스페이스 충돌, 특수성(specificity) 전쟁, 그리고 CSS 비대화(bloat) 문제를 해결하고 코드의 유지보수성을 확보하기 위한 방법론입니다 [1]. 전통적인 BEM과 같은 수동적인 네이밍 규칙부터, 빌드 시점에 자동으로 로컬 스코프(scope)를 분리하는 [[CSS Modules]], 유틸리티 퍼스트(Utility-first) 접근을 취하는 [[Tailwind CSS]] 등 다양한 패러다임으로 진화해 왔습니다 [2], [3], [4]. 현대의 CSS 아키텍처는 단순한 시각적 장식을 넘어, 팀 협업 환경에서 예측 가능하고 확장 가능한 컴포넌트 기반 시스템을 구축하는 것을 핵심 목적으로 합니다 [5], [6], [7].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **전통적 모듈화 방법론 (BEM 구조):**
|
||||
BEM(Block Element Modifier)은 클래스 이름을 통해 캡슐화를 모방하는 엄격한 네이밍 규칙입니다 [8]. UI를 독립적인 '블록(Block)', 그 내부의 '엘리먼트(Element)', 상태나 외형 변화를 나타내는 '모디파이어(Modifier)'로 분류하여 구조화합니다 [9], [10], [11], [12]. 이를 통해 선택자의 깊이를 얕게(flat) 유지하고 낮은 결합도와 높은 응집도를 촉진합니다 [12]. 하지만 대규모 프로젝트에서는 개발자의 실수로 인한 전역 충돌의 위험이 여전히 존재하며, 사용하지 않는 데드 코드(dead code)를 자동으로 제거하기 어렵다는 한계가 있습니다 [13].
|
||||
* **자동화된 스코핑과 캡슐화 (CSS Modules):**
|
||||
CSS Modules는 빌드 도구를 통해 고유한 해시(hashed) 클래스명을 생성함으로써 자동으로 로컬 스코프를 보장합니다 [3], [14]. [[SCSS]]와 같은 기존 프리프로세서와 잘 호환되며 전통적인 CSS 작성 방식을 그대로 유지할 수 있습니다 [15], [16]. 스타일 유출이나 충돌을 원천적으로 방지하여 유지보수성을 크게 향상시키며, 제로 런타임(Zero-runtime)으로 동작하여 런타임 성능 저하가 없습니다 [15], [17].
|
||||
* **유틸리티 퍼스트 접근법 (Tailwind CSS):**
|
||||
Tailwind CSS는 사전에 정의된 단일 목적의 작은 유틸리티 클래스들을 조합하여 HTML이나 JSX 내에서 직접 스타일을 작성하는 방식입니다 [18], [4]. 디자인 시스템의 일관성을 강제하기 쉽고, JIT(Just-In-Time) 컴파일러를 통해 사용된 클래스만 빌드 결과물에 포함시켜 프로덕션 CSS 번들 크기를 획기적으로 줄여줍니다 [19], [4], [20]. 다만, 마크업이 매우 장황해지고(verbose) 임의의 값(arbitrary values)이 남용될 우려가 있으며, 컴포넌트 전반의 스타일을 변경할 때 유지보수가 까다로울 수 있습니다 [19], [21], [20].
|
||||
* **런타임 기반 스타일링의 한계 ([[CSS-in-JS]]):**
|
||||
[[styled-components]]나 Emotion과 같은 CSS-in-JS는 [[JavaScript]] 코드 내에 스타일을 작성하여 컴포넌트 로직과 스타일을 함께 배치하는 방식입니다 [22], [23]. 동적 테마 적용이나 props를 활용한 스타일링에 매우 유리하지만, 런타임에 CSS를 파싱하고 주입해야 하므로 성능 오버헤드와 자바스크립트 번들 크기 증가가 발생합니다 [24], [25], [26], [23]. 특히 최근의 [[React Server Components]](RSC) 환경에서는 컨텍스트(Context) 기반의 CSS-in-JS가 호환되지 않는 치명적인 문제가 있어, 빌드 시점에 정적 CSS를 생성하는 Vanilla Extract 같은 제로 런타임 도구나 CSS Modules, Tailwind로 전환되는 추세입니다 [27], [28], [29].
|
||||
* **실무에서의 혼합 전략 (Hybrid Approach):**
|
||||
규모가 큰 엔지니어링 팀들은 단일 도구에 얽매이지 않고 각 방식의 장점을 결합하여 사용하기도 합니다 [30]. 예를 들어, 전반적인 레이아웃과 간격에는 개발 속도가 빠른 Tailwind CSS를 적용하고, 복잡한 애니메이션이나 정밀한 제어가 필요한 컴포넌트에는 CSS Modules나 SCSS를 결합하여 사용하는 하이브리드 전략을 채택함으로써 개발 생산성과 애플리케이션 성능을 동시에 최적화할 수 있습니다 [31], [32], [30], [33].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[BEM]], [[CSS Modules]], [[Tailwind CSS]], [[CSS-in-JS]], [[유틸리티 퍼스트(Utility-first)]]
|
||||
- **Projects/Contexts:** [[대규모 프론트엔드 프로젝트 아키텍처]], [[디자인 시스템 기반 컴포넌트 개발]], [[React [[Server Components]](RSC) 환경의 스타일링 최적화]]
|
||||
- **Contradictions/Notes:** Tailwind CSS는 클래스 네이밍에 대한 고민을 줄이고 빠른 프로토타이핑을 가능하게 하여 일관성과 CSS 번들 사이즈 최적화에 기여하지만 [19], [4], 개발자에 따라서는 인라인 스타일을 작성하는 것과 다름없어 HTML 마크업을 심각하게 어지럽히고 추상화 레이어를 불필요하게 추가한다는 강한 비판도 존재합니다 [34], [35], [19], [20]. 반면, CSS-in-JS는 컴포넌트 캡슐화에 매우 효과적이나 [22], 런타임 비용 및 서버 컴포넌트 호환성 이슈로 인해 2025년 기준 신규 아키텍처에서는 지양되고 CSS Modules가 더 안정적인 대안으로 추천되기도 합니다 [24], [36], [27], [37].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,18 +1,92 @@
|
||||
---
|
||||
id: wiki-2026-0508-cssom-css-object-model
|
||||
title: CSSOM(CSS Object Model)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[CSSOM(CSS Object Model)|CSSOM(CSS Object Model]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
[[CSSOM|CSSOM]](CSS Object Model)은 웹 페이지의 DOM(Document Object Model) 요소들이 어떻게 스타일링되는지에 대한 모든 정보를 담고 있는 객체 모델입니다 [1, 2]. 브라우저가 제공받은 CSS 규칙을 파싱하여 부모, 자식, 형제 관계를 가진 노드 트리 형태로 구성합니다 [3, 4]. 완성된 CSSOM은 DOM과 결합하여 화면에 픽셀을 그리기 위한 렌더 트리([[Render Tree|Render Tree]])를 생성하는 데 필수적인 역할을 합니다 [5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **렌더링 차단 특성 (Render-[[Blocking|Blocking]]):** DOM 트리의 생성은 점진적으로 이루어지지만, CSSOM 생성은 점진적이지 않은 렌더링 차단(render-blocking) 작업입니다 [1, 2]. 브라우저는 스타일이 적용되지 않은 날 것의 HTML 콘텐츠가 화면에 번쩍이며 나타나는 현상(FOUC, Flash of Unstyled Content)을 방지하기 위해, 연결된 모든 스타일시트를 다운로드하고 처리하여 CSSOM이 완성될 때까지 페이지 렌더링을 차단합니다 [1, 2].
|
||||
- **트리 구조와 캐스케이딩 (Cascading):** CSSOM은 CSS 규칙에 따라 노드 트리를 형성하며, 하위 노드는 상위 노드의 스타일 일부를 상속받습니다(하향식 종속) [3, 7]. 이후에 파싱된 규칙이 이전 규칙을 덮어쓸 수 있는 속성이 있으므로, 브라우저는 전체 CSS가 완전히 파싱될 때까지 CSSOM을 렌더 트리 구성에 사용할 수 없습니다 [7]. CSSOM 트리에는 브라우저의 기본 사용자 에이전트(User Agent) 스타일시트 정보도 포함되어 있으며, 브라우저는 가장 일반적인 규칙부터 구체적인 규칙을 거듭 적용하여 최종 스타일을 계산합니다 [8].
|
||||
- **선택자 파싱 원리와 성능:** 브라우저는 CSS 선택자를 오른쪽에서 왼쪽으로 파싱합니다 [9]. 따라서 클래스 여러 개가 결합된 구체적인 선택자(예: `.container.navigation.item`)는 조상 관계를 확인하기 위해 DOM 트리를 거슬러 올라가야 하므로, 단순한 선택자(예: `.item`)에 비해 브라우저에 약간의 작업 부하를 더 줍니다 [9, 10].
|
||||
- **렌더 트리(Render Tree)와의 결합:** 브라우저는 화면에 표시될 요소의 레이아웃을 계산하기 위해 DOM 트리와 CSSOM 트리를 병합하여 렌더 트리를 만듭니다 [6, 11]. DOM 트리의 루트에서 시작해 눈에 보이는 각 노드를 순회하며 적절한 CSSOM 규칙을 찾아 적용합니다 [6]. 이때 화면에 시각적 영향을 주지 않는 노드나 `display: none` 스타일이 적용된 노드는 렌더 트리에서 제외됩니다 [6, 11].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[DOM (Document Object Model)|DOM(Document Object Model]], Render Tree, Critical Rendering Path, [[Reflow & Repaint|Reflow & Repaint]]
|
||||
- **Projects/Contexts:** 브라우저 렌더링 최적화([[Browser|Browser]] Rendering [[Optimization|Optimization]])
|
||||
- **Contradictions/Notes:** 소스에 따르면 CSSOM 구축은 중요한 렌더링 차단 과정이지만, 최신 브라우저 엔진에서 CSSOM 생성 및 스타일 계산 속도는 마이크로초 단위로 이루어질 만큼 매우 빠릅니다 [8-10]. 따라서 CSS 선택자의 구체성을 낮추는 등의 마이크로 최적화보다는, 필요 없는 CSS 규칙을 최소화하거나 논블로킹(non-blocking) 요청을 적절히 사용하는 것이 더 의미 있는 성능 개선 방법이라고 지적합니다 [8, 10, 12].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-cssom
|
||||
title: CSSOM
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[CSSOM|CSSOM]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
[[CSSOM(CSS Object Model)|CSSOM(CSS Object Model]]은 웹 페이지의 시각적 외관을 정의하는 스타일 정보의 트리 구조입니다 [1-3]. DOM 생성과 달리 점진적으로 구성되지 않으며, 화면 렌더링을 차단(render-Blocking)하는 특징이 있습니다 [1, 2]. 구축된 CSSOM은 DOM과 결합하여 브라우저가 화면에 요소를 계산하고 그리는 데 사용하는 렌더 트리([[Render Tree|Render Tree]])를 합성하는 핵심 역할을 합니다 [3-5].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **생성 과정 및 특징**
|
||||
브라우저는 CSS 코드를 파싱하여 CSSOM 트리를 생성하며, 여기에는 브라우저의 기본 사용자 에이전트(user agent) 스타일시트도 포함됩니다 [6, 7]. 브라우저는 CSS 규칙을 자신이 이해할 수 있는 스타일 맵으로 변환하고, CSS 선택자를 기반으로 부모, 자식, 형제 관계를 가지는 노드 트리를 구성합니다 [6]. 이 과정에서 가장 일반적인 규칙부터 시작하여 더 구체적인 규칙을 재귀적으로 적용하며 속성값을 캐스케이딩(Cascading)합니다 [7, 8].
|
||||
|
||||
@@ -16,10 +36,64 @@
|
||||
* **렌더 트리(Render Tree)의 합성**
|
||||
CSSOM과 DOM의 구축이 모두 준비되면, 브라우저는 이 두 트리를 결합하여 렌더 트리를 생성합니다 [4, 5, 11]. 렌더 트리는 화면에 표시되는 콘텐츠와 그에 해당하는 계산된 스타일(computed styles)만을 포함하며, `display: none`으로 스타일링된 숨김 요소나 `<head>`, `<script>` 같은 비시각적 노드는 렌더 트리에서 제외됩니다 [4, 5, 11].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[DOM (Document Object Model)|DOM (Document Object Model]], Render Tree, [[Critical Rendering Path (CRP)|Critical Rendering Path (CRP]]
|
||||
- **Projects/Contexts:** [[Browser|Browser]] Rendering Process, [[Web Performance Optimization|Web Performance Optimization]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 더 구체적인 CSS 선택자가 파싱 비용을 증가시키긴 하지만, 브라우저가 이를 마이크로초 단위로 처리할 만큼 속도가 매우 빠르기 때문에 선택자 성능 최적화 자체에만 집중하기보다는 CSS 파일을 최소화(minification)하거나 미디어 쿼리로 비차단(non-blocking) 요청을 분리하는 등 다른 최적화 방식이 더 큰 효과를 줄 수 있다고 조언합니다 [7, 10].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-E946BD
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-cache-miss-rates
|
||||
title: Cache miss rates
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-E946BD]
|
||||
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 - Cache miss rates"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Cache miss rates|Cache miss rates]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Cache miss rates"
|
||||
- **타이밍 기반 정보 유출 (Timing-based information leak):** 스펙터(Spectre) 공격의 성공은 고정밀 타이밍 측정에 의존합니다 [4]. 데이터가 CPU의 L1 캐시에 존재할 때의 접근 지연 시간과 캐시 미스로 인해 메인 메모리에 접근해야 할 때의 지연 시간 차이를 측정함으로써, 공격자는 메모리 내부의 기밀 데이터를 유추해낼 수 있습니다 [4, 5].
|
||||
- **브라우저의 방어 메커니즘 (타이머 정밀도 제한):** 캐시 미스에 따른 미세한 타이밍 차이(서브 마이크로초 단위)를 공격자가 관찰하지 못하도록, 브라우저 엔진들은 `performance.now()`의 정밀도를 1ms 단위로 낮추거나(reduce timer precision) 격리된 환경(Isolated Context)에서 [[WebGPU|WebGPU]] 타임스탬프 쿼리의 해상도를 100 마이크로초 등으로 제한([[Quantization|Quantization]])하는 보안 조치를 취하고 있습니다 [1, 3, 6, 7].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Cache miss rates"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: CS-FE-MIGRATION-KIWI-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-case-study-kiwi-com-frontend-mig
|
||||
title: Case Study Kiwi com Frontend Migration
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [CS-FE-MIGRATION-KIWI-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [case-study, kiwi-com, [[Frontend|Frontend]]-migration, nextjs, mono-repo, orbit-[[Design-System|Design-System]], [[Scalability|Scalability]], web-performance]
|
||||
tags: [case-study, kiwi-com, Frontend-migration, nextjs, mono-repo, orbit-Design-System, Scalability, web-performance]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Case Study: Kiwi.com Frontend Migration (사례 연구: Kiwi.com 프런트엔드 마이그레이션)
|
||||
@@ -21,10 +33,59 @@ last_reinforced: 2026-04-26
|
||||
- **정량적 성과:** 페이지 로딩 속도의 획기적 단축, 개발 주기의 단축, 그리고 전 세계 검색 결과에서의 가시성 대폭 향상.
|
||||
- **의의:** 기술 부채가 누적된 대규모 시스템이 어떻게 점진적으로 현대화될 수 있는지에 대한 실질적 이정표 제공.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 과거에는 유연성을 위해 서비스별로 자유로운 기술 스택 사용을 허용했으나, Kiwi.com 사례는 '전사적 표준화 정책'과 '통합 디자인 언어 정책'이 대규모 조직에서 훨씬 강력한 효율을 낸다는 것을 증명함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 대규모 플랫폼 설계 시 Kiwi.com의 모노레포 및 디자인 시스템 기반 협업 모델을 벤치마킹하며, 모든 공유 패키지의 버전 관리를 자동화하는 정책을 도입함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Modern-Frontend-Engineering-Architecture|Modern-Frontend-Engineering-Architecture]], [[Design-System|Design-System]], [[Nextjs-App-Router-Architecture|Nextjs-App-Router-Architecture]], Scalable-[[Frontend-Architecture|Frontend-Architecture]], [[Uber-Base-Web-Design-System|Uber-Base-Web-Design-System]]
|
||||
- **Raw Source:** 00_Raw/Kiwi.com Migration.md, 00_Raw/kiwi.com 마이그레이션 프로젝트.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-CESI-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-cesiumjs
|
||||
title: CesiumJS
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-CESI-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, [[Cesium|Cesium]]js, [[WebGL|WebGL]], 3d-mapping, geospatial, visualization]
|
||||
tags: [auto-reinforced, Cesiumjs, WebGL, 3d-mapping, geospatial, visualization]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[CesiumJS|CesiumJS]]
|
||||
@@ -21,7 +33,7 @@ CesiumJS는 3D 지리 공간 데이터를 웹 브라우저에서 시각화하기
|
||||
2. **주요 활용**:
|
||||
* 스마트 시티 디지털 트윈, 항공 경로 실시간 모니터링, 재난 피해 가상 시뮬레이션 등.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거의 웹 지도 정책은 2D 평면 지도 중심이었으나, CesiumJS와 같은 3D 위주의 정책이 등격하며 '공간적 맥락 정책'을 디지털 트윈의 표준으로 만듦(RL Update).
|
||||
- **정책 변화(RL Update)**: 엔비디아 옴니버스나 구글 맵스 3D 타일과의 통합 정책이 강화됨에 따라, 닫힌 시스템이 아닌 '상호운용성 정책(InterOperability)'을 최우선으로 하는 지리 정보 생태계로 진화함.
|
||||
|
||||
@@ -29,3 +41,52 @@ CesiumJS는 3D 지리 공간 데이터를 웹 브라우저에서 시각화하기
|
||||
- [[Browser|Browser]], [[Geographic-Information-Systems|Geographic-Information-Systems]] (GIS), Simulation, [[Scalability|Scalability]], [[Technical-Architecture|Technical-Architecture]]
|
||||
- **Modern Tech/Tools**: Cesium Ion, Unmanned Traffic [[Management|Management]] (UTM), [[Digital_Twin|Digital Twin]] platforms.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-5D281C
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-chrome
|
||||
title: Chrome
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-5D281C]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Chrome"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Chrome|Chrome]]
|
||||
@@ -19,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Chrome"
|
||||
- **보안 및 타이밍 제어**: [[Spectre|Spectre]] 및 Meltdown과 같은 보안 취약점에 대응하기 위해, Chrome은 `performance.now()` 및 WebGPU 타임스탬프 쿼리의 정밀도를 제한([[Quantization|Quantization]])한다 [19, 23, 24]. 교차 출처 격리(Cross-origin isolated) 상태에 따라 100 마이크로초 단위로 해상도를 낮추며, 개발자 플래그(`chrome://flags/`)를 통해서만 제한을 해제할 수 있도록 보안과 디버깅의 균형을 맞추고 있다 [19, 24, 25].
|
||||
- **실험적 기능 (Origin Trials) 및 AI 도입**: 웹 페이지가 전환될 때의 소프트 내비게이션([[Soft Navigation|Soft Navigation]]s) 성능을 측정하기 위한 API 실험을 진행 중이며 [26], Speculation rules를 통해 미래의 내비게이션에 필요한 리소스를 미리 렌더링하는 기능도 지원한다 [10, 27]. 더 나아가 DevTools 내에 AI 디버깅 기능과 [[Model Context Protocol (MCP)|Model Context Protocol (MCP]] 서버를 도입하여 성능 데이터를 기반으로 코드 변경을 자동화하는 실험도 제공하고 있다 [28, 29].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -32,3 +43,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Chrome"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,15 +1,26 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-F09548
|
||||
category: "10_Wiki/💡 Topics/Web Development"
|
||||
id: wiki-2026-0508-client-components
|
||||
title: Client Components
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-F09548]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-03
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Client Components"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Client Components|Client Components]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
클라이언트 컴포넌트(Client Components)는 React Server Components (RSC) 패러다임에서 상태(State), 생명주기(Lifecycle), 이벤트 핸들러 및 브라우저 전용 API를 사용할 수 있는 전통적인 React 컴포넌트를 의미합니다 [1-3]. 파일 상단에 `'use client'` 지시어(directive)를 선언하여 명시적으로 정의하며, 서버 컴포넌트와 달리 자바스크립트 번들에 코드가 포함되어 브라우저에서 하이드레이션(Hydration) 과정을 거쳐 상호작용성을 제공합니다 [3-5].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
@@ -22,13 +33,12 @@ github_commit: "[P-Reinforce] Continuous Worker - Client Components"
|
||||
* **컴포넌트 중첩 및 구조화 (Interleaving)**
|
||||
클라이언트 컴포넌트는 내부에서 서버 컴포넌트를 직접 임포트(Import)하여 렌더링할 수 없습니다. 클라이언트 컴포넌트가 임포트하는 모든 하위 컴포넌트는 암시적으로 클라이언트 컴포넌트로 변환되기 때문입니다 [11, 12]. 서버 컴포넌트를 클라이언트 컴포넌트 내부에서 사용하려면, 서버 컴포넌트를 부모 영역에서 생성한 뒤 클라이언트 컴포넌트의 `children`과 같은 Prop 형태로 전달하는 중첩(Interleaving) 방식을 사용해야 합니다 [13-15]. Prop은 직렬화 가능하므로 번들러가 이 구조를 문제없이 처리할 수 있습니다 [15].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **자바스크립트 번들 크기 증가:** 서버 컴포넌트는 번들에 포함되지 않아 크기를 줄여주지만, 클라이언트 컴포넌트의 코드는 여전히 사용자 브라우저로 전송되어야 하므로 너무 많은 클라이언트 컴포넌트를 사용하면 애플리케이션의 번들 사이즈가 증가합니다 [3, 16].
|
||||
* **하이드레이션 간극(Hydration Gap):** 클라이언트 컴포넌트는 서버에서 HTML 형태로 먼저 사용자에게 보일 수 있으나, 브라우저가 자바스크립트를 다운로드하고 이벤트 리스너를 연결(하이드레이션)하기 전까지는 버튼 등 UI가 사용자의 조작에 반응하지 않는 간극이 존재합니다 [17, 18].
|
||||
* **관습적 적용의 함정 (Vibe Coding Trap):** 튜토리얼을 따라 하거나 단순히 에러를 피할 목적으로 불필요한 곳까지 무분별하게 `'use client'`를 선언하는 것은 안티 패턴입니다 [19, 20]. 이는 서버 컴포넌트의 장점(번들 사이즈 감소)을 무효화하고 불필요한 아키텍처적 복잡성만 가중시키므로, 브라우저 환경이나 상태 관리 등 클라이언트 기능이 명확히 필요한 경우에만 클라이언트 컴포넌트로 지정해야 합니다 [20].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술]
|
||||
@@ -70,3 +80,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Client Components"
|
||||
*Last updated: 2026-05-03*
|
||||
- Raw Source: 00_Raw/2026-05-03/Client Components.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,19 +1,30 @@
|
||||
---
|
||||
id: wiki-2026-0508-client-side-rendering-csr
|
||||
title: Client Side Rendering (CSR)
|
||||
category: Frontend
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-wikified, technical-documentation, merged, frontend]
|
||||
title: Client-Side Rendering (CSR)
|
||||
description: "클라이언트 사이드 렌더링(CSR)은 사용자가 초기에 비어 있는 HTML 파일과 자바스크립트 번들을 수신한 뒤, 브라우저에서 스크립트를 실행하여 동적으로 UI를 구성하는 렌더링 전략이다 [1, 2]."
|
||||
last_updated: 2026-05-04
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Client-Side Rendering (CSR)
|
||||
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
클라이언트 사이드 렌더링(CSR)은 사용자가 초기에 비어 있는 HTML 파일과 자바스크립트 번들을 수신한 뒤, 브라우저에서 스크립트를 실행하여 동적으로 UI를 구성하는 렌더링 전략이다 [1, 2]. 각 컴포넌트가 독립적으로 데이터를 가져오게 할 수 있어 개발 편의성이 높고 고도의 상호작용이 필요한 애플리케이션에 적합하다 [3, 4]. 하지만 자바스크립트 다운로드와 실행이 완료될 때까지 빈 화면이 노출되며, 사용자 기기의 성능에 앱의 구동 속도가 크게 의존한다는 단점이 있다 [5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **동작 메커니즘**
|
||||
초기 요청 시 클라이언트는 내용이 없고 `<script>` 태그만 포함된 HTML 파일을 전달받는다 [2]. 스크립트 형태의 자바스크립트 번들에는 React와 같은 프레임워크와 모든 작성된 코드가 포함되어 있다 [1]. 자바스크립트가 다운로드되고 파싱을 마치면 프레임워크가 브라우저에서 부팅되어 처음부터 모든 DOM 노드를 생성하고 화면을 렌더링한다 [1, 2].
|
||||
* **데이터 페칭(Data Fetching) 방식**
|
||||
@@ -21,8 +32,7 @@ last_updated: 2026-05-04
|
||||
* **개발 편의성 및 상호작용 최적화**
|
||||
클라이언트 렌더링 SPA(Single Page Application)는 렌더링이 필요한 컴포넌트 스스로가 필요한 데이터를 알아서 페칭하도록 설계할 수 있어 개발 편의성(convenience) 측면에서 매우 뛰어나다 [3]. 특히 그리기 도구, 실시간 에디터, 복잡한 폼 처리 등 상호작용이 주가 되는 애플리케이션의 경우, 거의 모든 요소가 클라이언트 컴포넌트로 구성되므로 이 방식이 자연스럽게 적용된다 [4].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **초기 로딩 지연 (Blank White Screen)**
|
||||
자바스크립트 코드를 다운로드하고 파싱하여 DOM을 구축하는 데 긴 시간이 소요되며, 이 과정 동안 사용자는 아무것도 없는 빈 하얀 화면을 보며 대기해야 한다 [6].
|
||||
* **번들 크기 비대화**
|
||||
@@ -39,10 +49,10 @@ last_updated: 2026-05-04
|
||||
> [!NOTE]
|
||||
> Below is content merged from previous versions of this documentation.
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Client-Side Rendering (CSR)은 브라우저(클라이언트)가 서버로부터 최소한의 HTML 뼈대와 [[JavaScript|JavaScript]] 번들을 전달받은 후, JavaScript를 실행하여 동적으로 웹 페이지의 콘텐츠를 렌더링하고 UI를 구축하는 방식입니다 [1-3]. 이 방식은 주로 React나 Vue와 같은 라이브러리를 통해 단일 페이지 애플리케이션(SPA) 형태로 구현됩니다 [2, 4, 5]. 초기 로딩 이후에는 전체 페이지 새로고침 없이 즉각적인 화면 전환이 가능하여 매끄럽고 앱과 같은 사용자 경험을 제공하는 것이 특징입니다 [1, 6-8].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **작동 메커니즘**: CSR 환경에서 서버는 콘텐츠가 거의 없는 빈 HTML 파일과 JavaScript 코드를 클라이언트로 전송합니다 [1-3]. 브라우저는 이 JavaScript를 다운로드하고 파싱 및 실행한 뒤에야 필요한 데이터를 가져오고 [[DOM (Document Object Model)|DOM(Document Object Model]]을 생성하여 실제 화면에 시각적 콘텐츠를 렌더링합니다 [1, 2, 9].
|
||||
* **주요 장점**:
|
||||
* **풍부한 상호작용 및 UX**: 첫 페이지 로드 이후 후속 조작 시 서버에 전체 페이지를 다시 요청할 필요 없이 동적으로 필요한 데이터만 업데이트하므로, 전환이 매끄럽고 네이티브 앱과 같은 사용자 경험을 제공합니다 [1, 6-8].
|
||||
@@ -53,10 +63,59 @@ Client-Side Rendering (CSR)은 브라우저(클라이언트)가 서버로부터
|
||||
* **검색 엔진 최적화(SEO) 제약**: 검색 엔진 크롤러나 소셜 미디어 봇이 웹사이트에 접근할 때 초기에는 빈 페이지만 보게 되므로, JavaScript를 제대로 파싱하지 못하면 콘텐츠 색인화 및 미리보기 생성이 누락될 수 있습니다 [1, 8, 9, 12, 13].
|
||||
* **최적의 사용 사례(Use Cases)**: CSR은 SEO가 상대적으로 중요하지 않고, 사용자 상호작용과 실시간 데이터 업데이트가 필수적인 환경에 이상적입니다 [6, 14]. 로그인 장벽 뒤에 있는 대시보드, [[SaaS|SaaS]] 플랫폼, 내부 비즈니스 도구 및 소셜 미디어 플랫폼 등이 대표적인 적용 사례입니다 [2, 5, 14, 15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** `[[Server-Side Rendering (SSR)|Server-Side Rendering (SSR]]`, `Single-Page Applications (SPA)`, `[[Static Site Generation (SSG)|Static Site Generation (SSG]]`, `Document Object Model (DOM)`
|
||||
- **Projects/Contexts:** `SaaS 플랫폼 및 대시보드 개발`, `React 기반 고도의 동적 웹 애플리케이션 구축`
|
||||
- **Contradictions/Notes:** 소스 전반에서 CSR의 '뛰어난 상호작용성'과 'SEO 및 초기 로딩의 취약점'에 대한 평가는 일치하며 상충하는 내용은 없습니다 [1, 6, 8, 9, 12, 13]. 다만 최근에는 CSR의 한계를 극복하기 위해 [[Next.js|Next.js]]와 같은 프레임워크를 사용하여 페이지의 목적에 맞게 SSR이나 SSG를 혼합(하이브리드 렌더링)하여 사용하는 방식이 권장되고 있습니다 [15-17].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,21 +1,40 @@
|
||||
---
|
||||
id: wiki-2026-0508-code-splitting
|
||||
title: Code Splitting
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Code Splitting|Code Splitting]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
큰 자바스크립트 번들을 더 작은 청크(chunk) 단위로 나누어 사용자가 필요로 할 때(on demand) 로드하는 프로세스입니다 [1, 2]. 모든 애플리케이션 코드를 초기에 한 번에 다운로드하는 대신, 필요한 파일만 먼저 불러오게 하여 초기 번들 크기를 극적으로 줄일 수 있습니다 [2, 3]. 결과적으로 초기 페이지 로드 속도를 향상시키고, 애플리케이션의 체감 성능을 개선하는 핵심적인 프론트엔드 최적화 기법입니다 [1, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **라우트 기반 분할 (Route-level Code Splitting):** 가장 일반적이고 효과적인 접근 방식입니다. 사용자가 특정 라우트로 이동할 때만 해당 페이지의 코드를 다운로드하도록 하여 초기 로딩 시 불필요한 코드 다운로드를 방지합니다 [1, 2, 5].
|
||||
* **컴포넌트 수준 지연 로딩 (Component-level Lazy Loading):** 차트, 지도, 리치 텍스트 에디터처럼 크고 무거운 컴포넌트나 드물게 사용되는 모달, 설정 패널 등을 렌더링이 필요한 시점에만 로드하도록 분리합니다 [6, 7]. React에서는 `React.lazy()`와 동적 임포트(dynamic imports), 그리고 `<Suspense>`를 활용해 이를 쉽게 구현할 수 있습니다 [4, 6, 8].
|
||||
* **벤더 라이브러리 분할 (Vendor Splitting):** Vite(내부적으로 Rollup 사용) 등의 번들러를 사용할 때 `manualChunks` 옵션을 통해 React 코어 라이브러리나 차트 등 무거운 벤더 코드를 별도의 파일로 분할합니다 [5, 9, 10]. 벤더 라이브러리는 자주 변경되지 않기 때문에 브라우저 캐싱 효율을 극대화할 수 있습니다 [5, 11].
|
||||
* **번들러의 자동화 지원:** 최신 번들러(Webpack, Vite)는 코드 내에 작성된 동적 임포트(`import()`)를 감지하면 자동으로 해당 코드를 별도의 청크로 분리합니다 [4, 6].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **필수 컴포넌트에 대한 오남용 금지:** 페이지에 즉시 필요한 스크롤 없이 볼 수 있는(above-the-fold) 핵심 컴포넌트나, 렌더링 속도가 빨라야 하는 요소에는 지연 로딩과 코드 분할을 피해야 합니다 [7]. 오히려 첫 화면을 그리는 시간을 지연시킬 수 있습니다.
|
||||
* **사용자 경험 저하 방지 (Fallback UI 필요):** 코드를 동적으로 불러오는 동안 네트워크 지연이 발생할 수 있습니다. 따라서 `<Suspense>`를 사용해 모듈이 로드되는 동안 스피너나 스켈레톤과 같은 Fallback UI를 제공해야 합니다 [5, 8].
|
||||
* **네트워크 요청 증가의 위험:** 너무 잘게 코드를 분할하면 오히려 수많은 네트워크 요청이 발생해 오버헤드가 발생할 수 있습니다. 따라서 번들 크기를 시각적으로 분석할 수 있는 `rollup-plugin-visualizer` 등의 도구를 사용해 500kB 이상의 큰 청크를 타겟으로 식별하고 적절하게 분할해야 합니다 [12, 13].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처/기반 기술]
|
||||
@@ -55,4 +74,53 @@
|
||||
- 확장 방향: 클라이언트 사이드의 코드 분할에서 더 나아가, 아예 정적인 UI 렌더링을 서버에서 처리하여 클라이언트로 보내는 자바스크립트 번들의 양 자체를 획기적으로 줄이거나 제거하는 최신 아키텍처 접근법입니다 [19-21].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-30*
|
||||
*Last updated: 2026-04-30*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,18 +1,29 @@
|
||||
---
|
||||
category: Frontend
|
||||
tags: [auto-wikified, technical-documentation, frontend]
|
||||
id: wiki-2026-0508-codegen
|
||||
title: Codegen
|
||||
description: "Codegen(코드 생성)은 소프트웨어 아키텍처에서 빌드 시점이나 개발 단계에 반복적인 보일러플레이트 코드나 연결 코드를 자동으로 생성하여 생산성과 안전성을 높이는 실전 패턴이다 [1, 2]."
|
||||
last_updated: 2026-05-04
|
||||
category: Frontend
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-wikified, technical-documentation, frontend]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Codegen
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Codegen(코드 생성)은 소프트웨어 아키텍처에서 빌드 시점이나 개발 단계에 반복적인 보일러플레이트 코드나 연결 코드를 자동으로 생성하여 생산성과 안전성을 높이는 실전 패턴이다 [1, 2]. 프레임워크 수준에서는 동적 타입 환경과 정적 타입 환경 간의 통신 시 발생하는 런타임 오버헤드와 타입 오류를 컴파일 타임에 방지하기 위해 사용된다 [2]. 또한, 횡단 관심사(Cross-Cutting Concerns) 처리를 위해 고급 IDE 도구 및 AI를 통해 코드를 생성하는 개발론적 접근법도 포함된다 [1, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**프레임워크 수준의 아키텍처 도구: React Native New Architecture**
|
||||
* React Native의 새로운 아키텍처(New Architecture)에서 Codegen은 동적 타입의 자바스크립트 세계와 정적 타입의 네이티브 플랫폼(Java/Kotlin, Objective-C/Swift) 간의 매끄럽고 안전한 통신을 보장하기 위해 도입되었다 [2].
|
||||
* 빌드 시점에 TypeScript 또는 Flow의 타입 정의를 분석하여 자바스크립트와 네이티브 측을 연결하는 데 필요한 C++ 보일러플레이트 코드를 자동으로 생성한다 [2].
|
||||
@@ -23,14 +34,12 @@ Codegen(코드 생성)은 소프트웨어 아키텍처에서 빌드 시점이나
|
||||
* 최근에는 AI 기반 도구를 활용하여 보일러플레이트 코드를 신속하게 생성하는 방식이 등장하여 교차 관심사 등을 다루는 대안으로 고려되고 있다 [3].
|
||||
* 부가적으로 Flutter 생태계의 `Auto Route`는 코드 생성을 통해 타입 안전성이 보장되는 라우팅을 제공하며 [4], NestJS는 데코레이터와 DTO를 기반으로 Swagger/OpenAPI 문서를 자동 생성하여 실제 코드베이스와 API 문서 간의 동기화를 보장한다 [5, 6].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **유지보수의 어려움 및 코드 중복:** IDE 도구를 통한 코드 생성 패턴은 본질적으로 코드베이스 내에 코드 중복(Duplication)을 발생시킨다 [1]. 향후 에러 처리 방식 등 특정 패턴을 전체적으로 변경해야 할 경우, 중복된 코드를 일일이 찾아 수동으로 변경해야 하는 어려움이 따를 수 있다 [1, 7].
|
||||
* **AI 생성 코드의 일관성 및 기능적 결함 문제:** AI를 활용하여 보일러플레이트를 생성할 경우, AI가 매번 새로운 코드를 지어내기 때문에 일관성을 완벽히 보장하기 어렵다 [3]. 미세한 외관상 또는 기능적 차이가 발생할 수 있다는 위협이 상존하며 [3], 실제로 개발자의 96%가 AI 생성 코드가 기능적으로 올바른지 완전히 신뢰하지 못하는 것으로 나타났다 [8].
|
||||
* **초기 설정 및 빌드 복잡도 증가:** React Native의 Codegen과 같이 C++ 기반으로 인터페이스를 자동 생성하는 아키텍처는 타입 안전성을 보장하는 대신, 빌드 타임에 코드를 분석하고 생성하는 추가적인 파이프라인이 요구되어 프로젝트 초기 설정의 복잡도를 증가시킬 수 있다 (컴파일 타임 로직 도입에 따른 일반적 제약 사항) [2].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/기반 기술)]
|
||||
@@ -76,4 +85,53 @@ Codegen(코드 생성)은 소프트웨어 아키텍처에서 빌드 시점이나
|
||||
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-03*
|
||||
*Last updated: 2026-05-03*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (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,25 @@
|
||||
---
|
||||
id: wiki-20260508-component-based-architecture-redir
|
||||
title: Component Based Architecture
|
||||
category: Frontend
|
||||
status: merged
|
||||
redirect_to: Component-Based_Architecture
|
||||
canonical_id: Component-Based_Architecture
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# Component Based Architecture
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[Component-Based_Architecture]]**로 통합되었습니다.
|
||||
|
||||
---
|
||||
*Redirected to: [[Component-Based_Architecture]]*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: FE-REACT-COMP-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-component-composition
|
||||
title: Component Composition
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [FE-REACT-COMP-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [react, [[Frontend|Frontend]], component-composition, reusability, [[Modularity|Modularity]], design-patterns, clean-code]
|
||||
tags: [react, Frontend, component-composition, reusability, Modularity, design-patterns, clean-code]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Component Composition (컴포넌트 합성)
|
||||
@@ -19,10 +31,59 @@ last_reinforced: 2026-04-26
|
||||
- **HOC (High-Order Components):** 컴포넌트를 인자로 받아 기능을 강화된 새 컴포넌트를 반환 (최근에는 Custom Hooks로 많이 대체됨).
|
||||
- **의의:** 컴포넌트 간의 결합도를 낮추고(Decoupling), 비즈니스 로직과 UI 로직을 명확히 분리하여 코드의 재사용성과 테스트 용이성을 극대화함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 과거 객체지향 기반 프레임워크는 클래스 상속을 권장했으나, React 정책은 '상속보다 합성(Composition over Inheritance)' 정책을 절대적 원칙으로 고수함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 공용 UI 라이브러리 설계 시 '슬롯 기반 합성(Slot-based Composition)' 아키텍처를 강제하며, 3단계 이상의 깊은 [[Prop Drilling|Prop Drilling]]이 발생하는 경우 반드시 합성을 통해 구조를 재설계하도록 함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- React-[[Architecture|Architecture]], [[Custom-Hooks-Patterns|Custom-Hooks-Patterns]], Reusable-UI-Components, Scalable-React-Architecture
|
||||
- **Raw Source:** 00_Raw/Component Composition.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-889EC5
|
||||
category: "10_Wiki/💡 Topics/Software Engineering"
|
||||
id: wiki-2026-0508-composables
|
||||
title: Composables
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-889EC5]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-03
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Composables"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Composables|Composables]]
|
||||
@@ -18,13 +29,12 @@ Composables는 Vue 3의 Composition API 환경에서 상태 저장 로직(statef
|
||||
* **컴포넌트 설계와 결합**: 더 복잡한 기능을 만들기 위해 작은 Composable 여러 개를 중첩(nesting)하여 사용할 수 있습니다. [7] 이렇게 추출된 Composables를 사용하면, 복잡한 인증 흐름이나 폼 유효성 검사, 드래그 앤 드롭 등의 인터랙션 로직을 컴포넌트 밖으로 빼내어 UI 컴포넌트를 가볍게 유지할 수 있습니다. [4, 8]
|
||||
* **팀 협업 및 테스트 용이성 극대화**: 각 Composable은 `useAuth`, `useCounter`와 같이 의도를 명확히 드러내는 명명 규칙을 따르는 것이 권장됩니다. [5, 9] 또한 UI DOM 요소 전체를 마운트할 필요 없이, 반응형 상태와 비즈니스 로직이 담긴 Composable 함수만 개별적으로 유닛 테스트할 수 있어 대규모 프로젝트에서 코드 오염을 방지하고 견고함을 유지할 수 있습니다. [4, 5, 10]
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **유연성으로 인한 코드 파편화 위험**: Composition API와 Composables가 제공하는 높은 유연성은 오히려 양날의 검이 될 수 있습니다. 로직을 어떻게 추출하고 명명할지에 대해 팀 내의 명확한 코딩 표준(naming conventions, 파일 구조 등)이 확립되지 않으면, 일관성 없는 코드가 양산되어 장기적인 유지보수가 어려워질 수 있습니다. [5, 9, 11]
|
||||
* **가파른 학습 곡선**: 소규모 프로젝트나 Vue에 처음 입문하는 개발자에게는 직관적이고 선언적인 Options API에 비해, 상태와 반응성 객체를 직접 조립해야 하는 Composables 패턴이 상대적으로 가파른 학습 곡선을 요구합니다. [12-14]
|
||||
* **반응성(Reactivity) 손실 주의**: 원시 값과 객체의 반응성을 다루는 방식(`ref` vs `reactive`)을 정확히 이해하지 못하고 구조 분해 할당(destructuring)을 오용할 경우, 컴포넌트와의 반응성 연결이 끊어지는 흔한 함정(pitfall)에 빠질 수 있습니다. [15]
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처/기반 기술]
|
||||
@@ -69,3 +79,52 @@ Composables는 Vue 3의 Composition API 환경에서 상태 저장 로직(statef
|
||||
*Last updated: 2026-05-03*
|
||||
- Raw Source: 00_Raw/2026-05-03/Composables.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-69B9E0
|
||||
category: "10_Wiki/💡 Topics/Software Engineering"
|
||||
id: wiki-2026-0508-composition-api
|
||||
title: Composition API
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-69B9E0]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-03
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Composition API"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Composition API|Composition API]]
|
||||
@@ -20,14 +31,13 @@ Vue 3 Composition API는 컴포넌트의 옵션(`data`, `methods`, `computed`
|
||||
* **Provide / Inject를 통한 컨텍스트 공유**: 엔터프라이즈 환경에서 데이터가 불필요한 중간 컴포넌트 계층을 거치는 'Prop Drilling' 문제를 방지한다 [14]. 전역 로거, API 클라이언트 주입이나 테마 및 다국어 지원 등 '컨텍스트 인식(Context-aware)' 컴포넌트 트리를 구성하는 데 활용된다 [14, 15].
|
||||
* **강력한 TypeScript 호환성**: Composition API는 TypeScript와 매끄럽게 통합되어 뛰어난 타입 추론을 제공한다 [2, 11]. 이는 런타임 에러를 사전에 방지하고 버그를 최소화하며 개발 속도를 높이는 결정적 요인으로 작용한다 [3, 4].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **가파른 학습 곡선 (Steeper Learning Curve)**: 단순하고 선언적인 구조를 가진 Options API에 비해 Composition API는 상대적으로 학습 곡선이 가파르다 [16, 17].
|
||||
* **반응성(Reactivity) 상실의 위험**: `reactive`를 원시 값에 잘못 사용하거나, 반응형 객체를 직접 구조 분해 할당(Destructuring)할 경우 반응성 연결이 끊어지는 흔한 실수가 발생할 수 있다. 이를 유지하려면 속성에 직접 접근하거나 `toRefs()` 유틸리티를 사용해야 한다 [18]. 또한 JavaScript 내부에서 `ref` 변수에 접근할 때 `.value`를 누락하는 실수에 유의해야 한다 [18].
|
||||
* **라이프사이클 및 비동기 로직의 위치 제약**: 데이터 페칭 및 이벤트 리스너 설정 로직은 `setup` 함수 내부의 적절한 라이프사이클 훅 안에서 호출되어야 한다. 이 규칙을 벗어날 경우 메모리 누수(Memory leaks)나 예기치 않은 동작이 발생할 수 있다 [19].
|
||||
* **단순 컴포넌트에서의 오버엔지니어링**: 재사용성이 낮고 기능이 단순한 단일 기능 컴포넌트에서는 Composition API를 도입하는 것이 불필요하게 복잡할 수 있으며, 이 경우 Options API를 사용하는 것이 더 직관적일 수 있다 [16, 20].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술]
|
||||
@@ -72,3 +82,52 @@ Vue 3 Composition API는 컴포넌트의 옵션(`data`, `methods`, `computed`
|
||||
*Last updated: 2026-05-03*
|
||||
- Raw Source: 00_Raw/2026-05-03/Composition API.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
id: wiki-20260508-compound-components-redir
|
||||
title: Compound Components
|
||||
category: Frontend
|
||||
status: merged
|
||||
redirect_to: Compound_Components
|
||||
canonical_id: Compound_Components
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# Compound Components
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[Compound_Components]]**로 통합되었습니다.
|
||||
|
||||
---
|
||||
*Redirected to: [[Compound_Components]]*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-053
|
||||
category: Unified
|
||||
id: wiki-2026-0508-computational-geometry
|
||||
title: Computational Geometry
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AI-053]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.97
|
||||
tags: [geometry, computational geometry, 3d, rendering]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-06-XX
|
||||
github_commit: "[P-Reinforce] Processed Computational Geometry."
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Computational Geometry|Computational Geometry]] (계산 기하학)
|
||||
@@ -19,7 +30,7 @@ github_commit: "[P-Reinforce] Processed Computational Geometry."
|
||||
2. **공간 분할 기법:** 대규모 데이터를 효율적으로 검색하기 위해 공간을 나누는 방법들 (예: Octree, BVH - Bounding Volume Hierarchy). 이는 렌더링의 성능(Culling)에 필수적이다.
|
||||
3. **좌표 변환 및 근사화:** 카메라 위치나 오브젝트 이동에 따른 좌표계 변환(Transformation Matrix), 그리고 복잡한 곡선을 단순화하는 과정이 포함된다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 기하학적 모델링은 단순히 형태를 만드는 것을 넘어, 물리 엔진과의 결합을 통해 '물리 법칙'을 시뮬레이션하고 그 결과를 예측하는 데 사용된다.
|
||||
- **정책 변화:** 최신 트렌드는 하드웨어 가속(GPU)과 연동하여 복잡한 기하학적 계산(예: Ray Tracing)을 실시간으로 처리하는 방향으로 진화하고 있다.
|
||||
|
||||
@@ -27,4 +38,53 @@ github_commit: "[P-Reinforce] Processed Computational Geometry."
|
||||
- Parent: [[Computational Geometry|Computational Geometry]]
|
||||
- Related: Bounding Volume Hierarchy (BVH) , [[Three.js 렌더링 최적화|Three.js 렌더링 최적화]] , [[Physics|Physics]]-Based-Simulation
|
||||
|
||||
---
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,21 +1,40 @@
|
||||
---
|
||||
id: wiki-2026-0508-concurrent-features
|
||||
title: Concurrent Features
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Concurrent Features|Concurrent Features]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Concurrent Features는 React 18부터 도입된 기능으로, 렌더링 작업을 일시 중지(pause), 중단(interrupt), 재개(resume)할 수 있게 해주는 기능입니다 [1]. 이를 통해 중요한 사용자 상호작용(클릭, 타이핑 등)의 우선순위를 높이고, 상대적으로 느린 업데이트(대용량 필터링 등)를 지연시킬 수 있습니다 [1]. 결과적으로 앱의 실제 연산 속도 자체를 마법처럼 빠르게 만드는 것은 아니지만, 인지되는 속도(perceived speed)를 최적화하여 사용자 인터페이스를 반응성 있게 유지합니다 [2].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **동시성 렌더링(Concurrent Rendering)의 원리:** 최신 버전의 React에서 기본적으로 동작하는 방식으로, 렌더링 작업의 우선순위를 지정하여 중요도가 높은 상호작용이 렌더링에 의해 차단(block)되지 않고 즉시 반응하도록 돕습니다 [1].
|
||||
* **`useTransition`을 통한 우선순위 제어:** 특정 상태 업데이트를 '긴급하지 않은(non-urgent)' 것으로 표시하여 지연시키는 훅(Hook)입니다 [3]. 실시간 검색 결과나 대용량 데이터 필터링 시, 사용자의 타이핑 같은 입력은 즉각적으로 반응하게 하면서 무거운 렌더링 처리는 뒤로 미룰 수 있습니다 [3]. 또한 `isPending` 상태를 활용해 입력 즉각성을 막지 않고 로딩 스피너나 스켈레톤 UI를 표시할 수도 있습니다 [3].
|
||||
* **`useDeferredValue`를 통한 값 참조 지연:** `useTransition`이 업데이트를 언제 발생시킬지를 관리한다면, `useDeferredValue`는 무거운 값을 언제 '읽을지'를 제어합니다 [4]. 입력과 같은 UI 변경은 즉시 반영하면서, 파생되는 무거운 로직 적용은 살짝 지연시켜 실시간 폼(form) 등에서 발생하는 끊김 현상(jank)을 줄여줍니다 [4].
|
||||
* **프레임워크 지원 환경:** 2025년 기준 Next.js(App Router), Remix, Vite + React 18+ 환경 등 대부분의 풀스택 및 번들러 프레임워크에서 기본적으로 동시성 렌더링 기능이 통합되어 지원됩니다 [2].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **성능 향상의 본질적 한계:** 이 기능들은 앱의 실제 연산 속도를 물리적으로 높여주는 것이 아니라 "인지되는 속도(perceived speed)"를 우선시하는 기능입니다 [2]. 백그라운드 작업이 계속 진행되는 동안 UI의 반응성을 유지할 뿐, 실행해야 할 연산량 자체가 줄어드는 것은 아닙니다 [2].
|
||||
* **선별적 사용 요구:** 모든 컴포넌트에 전역적으로 사용해서는 안 되며, 주로 '상호작용이 많은 뷰(interactive views)'에 선별적으로 적용해야 합니다 [4].
|
||||
* **호환성 문제:** 렌더링을 차단하는(render-blocking) 구식 패턴(가드가 없는 클래스 컴포넌트 등)이나 오래된 상태 관리 라이브러리와 섞어서 사용하면 정상적으로 동작하지 않거나 성능 문제를 야기할 수 있습니다 [4].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술]
|
||||
@@ -53,4 +72,53 @@ Concurrent Features는 React 18부터 도입된 기능으로, 렌더링 작업
|
||||
- 확장 방향: 화면의 렌더링 과정을 매끄럽게 하는 것을 넘어, 초기 애플리케이션 로딩 시 네트워크를 통해 다운로드하는 코드의 양 자체를 분할하여 초기 응답성(Time to Interactive)을 향상시키는 전략 탐구 [8, 9].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-30*
|
||||
*Last updated: 2026-04-30*
|
||||
|
||||
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
id: wiki-20260508-concurrent-rendering-redir
|
||||
title: Concurrent Rendering
|
||||
category: Frontend
|
||||
status: merged
|
||||
redirect_to: Concurrent_Rendering
|
||||
canonical_id: Concurrent_Rendering
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# Concurrent Rendering
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[Concurrent_Rendering]]**로 통합되었습니다.
|
||||
|
||||
---
|
||||
*Redirected to: [[Concurrent_Rendering]]*
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
id: wiki-20260508-container-queries-redir
|
||||
title: Container Queries
|
||||
category: Frontend
|
||||
status: merged
|
||||
redirect_to: Container_Queries
|
||||
canonical_id: Container_Queries
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# Container Queries
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[Container_Queries]]**로 통합되었습니다.
|
||||
|
||||
---
|
||||
*Redirected to: [[Container_Queries]]*
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
id: wiki-2026-0508-core-web-vitals
|
||||
title: Core Web Vitals
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Core Web Vitals]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Core Web Vitals(코어 웹 바이탈)은 웹사이트의 실제 성능과 사용자 경험을 평가하는 필수 지표로, 로딩 속도, 레이아웃의 안정성, 사용자 입력에 대한 반응 속도를 측정합니다 [1]. 핵심 지표로는 LCP(Largest Contentful Paint), CLS(Cumulative Layout [[Shift]]), INP(Interaction to Next Paint)가 있으며, 이는 구글의 검색 순위(Ranking signal)와 모바일 우선 인덱싱에 직접적인 영향을 미칩니다 [2, 3].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **핵심 지표와 목표치**: Core Web Vitals는 크게 세 가지 주요 지표로 구성됩니다. LCP(Largest Contentful Paint)는 주요 콘텐츠의 로딩 속도를 의미하며 2.5초 미만을 유지해야 하고, CLS(Cumulative Layout Shift)는 레이아웃의 시각적 안정성을 나타내며 0.1 미만이어야 하며, INP(Interaction to Next Paint)는 사용자의 입력에 대한 반응성을 측정하여 200밀리초 미만을 목표로 최적화해야 합니다 [4].
|
||||
* **CSS 및 반응형 디자인과의 연관성**: 잘못된 이미지 크기 지정, 너비(width) 및 높이(height) 속성 누락, 최적화되지 않은 폰트 등은 모바일 환경에서 Core Web Vitals 점수 하락의 가장 흔한 원인이 됩니다 [2, 3]. 잘 구축된 반응형 레이아웃은 불필요한 레이아웃 이동(Layout shift)을 줄이고 로딩 시간을 개선하며 사용자 상호작용을 민첩하게 만듭니다 [1].
|
||||
* **성능 최적화 기법**: CLS를 방지하기 위해 컨테이너에 `aspect-ratio` 속성을 적용하거나 명시적인 너비와 높이를 지정해야 합니다 [5, 6]. LCP 향상을 위해서는 LCP 요소(주로 히어로 이미지)에 `fetchpriority="high"`를 설정하고 폴드(fold) 아래의 이미지는 지연 로딩(lazy-load) 처리하며, WebP나 AVIF 같은 압축률이 높은 차세대 포맷을 사용하는 방법이 있습니다 [5-7].
|
||||
* **SEO 및 비즈니스 영향**: 구글은 페이지 경험 신호의 일부로 Core Web Vitals를 활용하므로, 로딩이 느리고 레이아웃 이동이 잦은 비반응형 웹사이트는 검색 결과에서 성능이 저하될 수 있습니다 [3, 4]. 따라서 이 지표들을 지속적으로 모니터링하고 최적화하는 것은 2026년 현재 반응형 웹 디자인의 핵심 요구 사항입니다 [4, 8].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Responsive Web Design]], [[CSS Performance Optimization]]
|
||||
- **Projects/Contexts:** [[Search Engine [[Optimization]] (SEO)]]
|
||||
- **Contradictions/Notes:** 소스 전반에 걸쳐 CSS 및 반응형 디자인의 최적화가 Core Web Vitals 지표 개선으로 직결된다고 강조하고 있으며, 소스 간 상충되는 의견은 존재하지 않습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-critical-rendering-path-crp
|
||||
title: Critical Rendering Path (CRP)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Critical Rendering Path (CRP)|Critical Rendering Path (CRP]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
[[Critical Rendering Path|Critical Rendering Path]] (CRP)는 웹 브라우저가 HTML, CSS, JavaScript 코드를 수신하여 화면의 픽셀로 변환하기 위해 실행하는 일련의 단계입니다 [1, 2]. 이 경로는 DOM(문서 객체 모델) 및 [[CSSOM|CSSOM]](CSS 객체 모델) 구축, 렌더 트리 생성, 레이아웃 계산, 화면 페인팅 등의 핵심 과정으로 구성됩니다 [2]. CRP를 최적화하면 최초 렌더링(Time to First Render) 시간을 단축하고, 초당 60프레임의 원활한 상호작용을 보장하며, 성능 저하나 끊김(Jank)을 방지할 수 있습니다 [2, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **[[DOM (Document Object Model)|DOM(Document Object Model]] 구축:** 브라우저는 HTML 데이터를 수신하면 점진적 파싱(incremental parsing)을 시작합니다 [3, 4]. 수신된 바이트를 문자, 토큰, 노드로 변환한 뒤 계층적인 DOM 트리를 구축합니다 [3, 4].
|
||||
- **[[CSSOM(CSS Object Model)|CSSOM(CSS Object Model]] 구축:** CSS는 HTML과 달리 점진적으로 처리되지 않으며 렌더링 차단(render-[[Blocking|Blocking]]) 리소스로 작동합니다 [5, 6]. 브라우저는 화면에 스타일이 지정되지 않은 콘텐츠가 깜빡이는 현상(FOUC)을 막기 위해 렌더 트리를 만들기 전 모든 연결된 스타일시트를 다운로드하고 구문 분석하여 CSSOM을 완성해야 합니다 [5, 6].
|
||||
- **렌더 트리([[Render Tree|Render Tree]]) 생성:** DOM과 CSSOM 트리가 준비되면 이를 결합하여 렌더 트리를 합성합니다 [7, 8]. 이 트리에는 화면 렌더링에 필요한 가시적 노드만 포함되며, `<script>`, `<meta>` 요소나 `display: none` 처리된 요소 등 시각적 레이아웃에 영향을 주지 않는 노드는 제외됩니다 [7-9].
|
||||
@@ -11,10 +31,64 @@
|
||||
- **페인트(Paint / Repaint) 및 합성(Compositing):** 페인트 단계에서는 계산된 기하학적 구조와 스타일(색상, 그림자, 텍스트 등)을 바탕으로 요소를 실제 픽셀로 화면에 그립니다 [13-15]. 마지막으로 합성 단계에서는 여러 레이어를 하나의 최종 이미지로 결합하며, 최신 브라우저에서는 성능을 위해 이 과정을 GPU에 오프로드하여 처리합니다 [13, 16].
|
||||
- **성능 최적화 전략:** CRP 최적화를 위해서는 다운로드해야 하는 렌더링 차단 리소스(`<head>` 내부의 CSS 및 동기식 JavaScript)의 크기와 개수를 최소화해야 합니다 [17-19]. 중요하지 않은 리소스의 로드를 지연시키거나 비동기로 처리하여 브라우저의 렌더링 파이프라인이 멈추지 않도록 구성하는 것이 핵심입니다 [17, 20].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[DOM (Document Object Model)|DOM (Document Object Model]], CSSOM (CSS Object Model), [[Render Tree|Render Tree]], Reflow, Repaint
|
||||
- **Projects/Contexts:** 최신 프론트엔드 개발의 기초 구조 설계, 코어 웹 바이탈([[Core Web Vitals|Core Web Vitals]]) 성능 개선, React의 [[Virtual DOM|Virtual DOM]] 도입을 통한 렌더링 병목 현상 해결 컨텍스트 [1, 2, 21].
|
||||
- **Contradictions/Notes:** CSS 선택자의 구체성(specificity)을 높게 작성할 경우 파싱 비용이 증가하지만, 현대 브라우저 엔진은 구문 분석 속도가 매우 빠르기 때문에 이러한 선택자 최적화가 CRP 전체 성능에 미치는 영향은 마이크로초(microseconds) 수준에 불과하여 최적화의 주된 우선순위로 삼기에는 실효성이 부족할 수 있습니다 [22].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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,25 @@
|
||||
---
|
||||
id: wiki-20260508-critical-rendering-path-redir
|
||||
title: Critical Rendering Path
|
||||
category: Frontend
|
||||
status: merged
|
||||
redirect_to: Critical_Rendering_Path
|
||||
canonical_id: Critical_Rendering_Path
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# Critical Rendering Path
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[Critical_Rendering_Path]]**로 통합되었습니다.
|
||||
|
||||
---
|
||||
*Redirected to: [[Critical_Rendering_Path]]*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: FE-REACT-CUSTOM-HOOK-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-custom-hooks-patterns
|
||||
title: Custom Hooks Patterns
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [FE-REACT-CUSTOM-HOOK-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [react, [[Frontend|Frontend]], custom-hooks, dry, refactoring, separation-of-concerns, [[business|business]]-[[Logic|Logic]]]
|
||||
tags: [react, Frontend, custom-hooks, dry, refactoring, separation-of-concerns, business-Logic]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Custom Hooks Patterns (커스텀 훅 패턴)
|
||||
@@ -22,10 +34,59 @@ last_reinforced: 2026-04-26
|
||||
- **Co-location:** 특정 도메인에 국한된 훅은 해당 도메인 폴더에, 범용 훅은 `src/hooks`에 배치.
|
||||
- **의의:** 중복 코드를 제거(DRY)하고, 복잡한 컴포넌트의 인지적 부하를 줄여 유지보수 비용을 획기적으로 낮춤.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 과거에는 로직 재사용을 위해 고차 컴포넌트(HOC)나 [[Render Props|Render Props]]를 사용했으나, 훅 도입 이후 이러한 방식은 'Wrapper Hell'을 유발하는 지양해야 할 정책으로 간주됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 30라인 이상의 비즈니스 로직을 포함하는 컴포넌트 개발 시 반드시 커스텀 훅으로의 분리를 검토하도록 강제하며, 훅 내부에서 사이드 이펙트(Effect) 발생 시 명확한 클린업 로직을 포함하는 것을 정책화함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[React-Hooks|React-Hooks]], [[Dry-Principle|DRY-Principle]], [[Clean-Code-Principles|Clean-Code-Principles]], [[Component-Composition|Component-Composition]]
|
||||
- **Raw Source:** 00_Raw/Custom Hooks.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
id: wiki-20260508-dom-document-object-model--redir
|
||||
title: DOM (Document Object Model)
|
||||
category: Frontend
|
||||
status: merged
|
||||
redirect_to: DOM(Document_Object_Model)
|
||||
canonical_id: DOM(Document_Object_Model)
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# DOM (Document Object Model)
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[DOM(Document_Object_Model)]]**로 통합되었습니다.
|
||||
|
||||
---
|
||||
*Redirected to: [[DOM(Document_Object_Model)]]*
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-dom-및-cssom
|
||||
title: DOM 및 CSSOM
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[DOM 및 CSSOM|DOM 및 CSSOM]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
DOM(문서 객체 모델)과 [[CSSOM|CSSOM]](CSS 객체 모델)은 브라우저의 핵심 렌더링 경로(Critical Rendering Path)에서 웹 페이지를 화면에 그리기 위해 생성되는 두 가지 독립적인 트리 구조 데이터입니다 [1, 2]. DOM은 HTML 마크업을 점진적으로 파싱하여 문서의 구조와 내용을 나타냅니다 [3, 4]. 반면, CSSOM은 문서에 적용될 스타일 규칙을 정의하며, 렌더링 시 스타일이 적용되지 않은 콘텐츠가 깜빡이는 현상(FOUC)을 방지하기 위해 렌더링 차단(render-Blocking) 방식으로 생성됩니다 [5, 6]. 이 두 트리가 결합하여 화면에 표시될 시각적 요소들만 포함하는 렌더 트리([[Render Tree|Render Tree]])를 최종적으로 형성합니다 [7, 8].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**[[DOM (Document Object Model)|DOM(Document Object Model]] 구축**
|
||||
- 브라우저는 HTML 응답을 받으면 데이터를 문자, 토큰(token)으로 변환하고, 이를 다시 노드(node)로 변환하여 계층적인 DOM 트리를 구축합니다 [3, 4, 9].
|
||||
- DOM 트리는 문서의 콘텐츠와 각 요소 간의 관계 및 계층 구조를 나타냅니다 [4, 8, 9].
|
||||
@@ -22,10 +42,64 @@ DOM(문서 객체 모델)과 [[CSSOM|CSSOM]](CSS 객체 모델)은 브라우저
|
||||
- 렌더 트리는 시각적으로 렌더링되는 요소들만 캡처합니다 [7]. 따라서 시각적 레이아웃에 영향을 주지 않는 `<script>`, `<meta>` 요소나, CSS에 의해 `display: none`으로 처리된 요소는 렌더 트리에서 제외됩니다 [7, 8, 14, 15].
|
||||
- 하지만 `visibility: hidden`이 적용된 요소는 보이지 않더라도 레이아웃 상에서 공간을 차지하므로 렌더 트리에 포함됩니다 [15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** `[[Critical Rendering Path|Critical Rendering Path]]`, `Render Tree`, `[[Reflow and Repaint|Reflow and Repaint]]`
|
||||
- **Projects/Contexts:** `[[프론트엔드 성능 최적화|프론트엔드 성능 최적화]]`, `브라우저 렌더링 파이프라인 이해`
|
||||
- **Contradictions/Notes:** CSS 선택자의 구체성이 CSSOM 생성 연산 속도에 영향을 미치지만, 최신 브라우저는 파싱 속도가 매우 빨라 이로 인한 지연은 마이크로초 단위에 불과합니다 [11, 13]. 따라서 과도하게 선택자 구체성 최적화에 집착하기보다는 미니파이(minification)나 렌더링 차단을 방지하는 다른 CSS 최적화 기법에 집중하는 것이 좋습니다 [13].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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,25 @@
|
||||
---
|
||||
id: wiki-20260508-dom-document-object-model--redir
|
||||
title: DOM(Document Object Model)
|
||||
category: Frontend
|
||||
status: merged
|
||||
redirect_to: DOM(Document_Object_Model)
|
||||
canonical_id: DOM(Document_Object_Model)
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# DOM(Document Object Model)
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[DOM(Document_Object_Model)]]**로 통합되었습니다.
|
||||
|
||||
---
|
||||
*Redirected to: [[DOM(Document_Object_Model)]]*
|
||||
@@ -1,3 +1,23 @@
|
||||
---
|
||||
id: wiki-2026-0508-datacollector-knowledge-hub
|
||||
title: Datacollector Knowledge Hub
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 📡 Datacollector Project: Engineering Hub (MOC)
|
||||
|
||||
데이터 수집 및 자동화 프로세스를 관리하는 핵심 허브입니다.
|
||||
@@ -31,7 +51,7 @@
|
||||
---
|
||||
**Status**: Managed by Antigravity AI
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[2026-04-25-Datacollector_Auto_Resume_After_Reauth_Fix]]
|
||||
* [[2026-04-25-Datacollector_Bridge_Connection_Refused_Run_Script_Fix]]
|
||||
@@ -44,3 +64,69 @@
|
||||
* [[2026-04-25-Datacollector_NotebookLM_Automatic_Reauth_Verification_and_Lock]]
|
||||
* [[2026-04-25-Datacollector_NotebookLM_Connection_Guard_and_MCP_Restart_Fix]]
|
||||
* [[2026-04-25-Datacollector_NotebookLM_Progress_Visibility_and_Auth_Diagnosis]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-debugging-frontend-applications
|
||||
title: Debugging Frontend Applications
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Debugging Frontend Applications|Debugging Frontend Applications]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
프론트엔드 디버깅은 웹 애플리케이션에서 발생하는 자바스크립트 런타임 에러, 메모리 누수, 그리고 불필요한 리렌더링과 같은 성능 저하 요인을 식별하고 해결하는 과정입니다 [1-3]. Chrome DevTools와 같은 브라우저 내장 도구부터 React DevTools, 그리고 Sentry나 LogRocket과 같은 프로덕션 클라우드 로깅 도구를 활용하여 문제의 근본 원인을 추적합니다 [4-7]. 효과적인 디버깅 전략과 에러 핸들링 아키텍처는 애플리케이션의 안정성을 보장하고 사용자 경험을 최적화하는 데 필수적입니다 [8-10].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **메모리 누수(Memory Leaks) 탐지 및 해결:**
|
||||
* 메모리 누수는 할당된 메모리가 더 이상 필요하지 않음에도 해제되지 않을 때 발생하며, 앱 속도 저하와 브라우저 탭 충돌을 유발합니다 [2, 11].
|
||||
* Chrome DevTools의 Task Manager를 통해 실시간 JavaScript 메모리 사용량을 확인하고, Performance 탭의 기록을 통해 시간 경과에 따른 메모리 증가 패턴을 시각화할 수 있습니다 [12, 13].
|
||||
@@ -18,15 +37,13 @@
|
||||
* 배포된 프로덕션 앱에서는 Sentry, LogRocket, Datadog RUM 등의 클라우드 로깅 툴을 통해 사용자가 경험하는 에러를 모니터링합니다 [23-25].
|
||||
* Sentry는 지능형 에러 그룹화(Error grouping)와 에러 발생 전의 콘솔 로그, 네트워크 요청 등을 보여주는 빵부스러기(Breadcrumb) 트레일을 제공합니다 [4, 25]. LogRocket은 사용자의 전체 화면을 녹화하듯 DOM 및 Redux/Vuex 상태 변화까지 캡처하는 세션 리플레이(Session replay) 기능으로 상세한 디버깅 컨텍스트를 제공합니다 [5]. Datadog RUM은 프론트엔드 에러를 백엔드 분산 트레이싱(Distributed tracing)과 상관관계 지어(Correlation) 복잡한 시스템의 에러를 파악하게 해줍니다 [24].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **클라우드 로깅 도구의 성능 및 비용 문제:** 모니터링 도구들은 렌더링 성능 및 번들 크기에 직접적인 영향을 미칩니다. 일부 도구 구현 시 최대 120ms의 추가 로드 시간이 발생할 수 있습니다 [26]. 또한, Datadog과 같은 툴은 로그 수집(Ingest)과 검색을 위한 인덱싱(Index)에 대해 이중 과금 구조를 가지고 있어 규모가 커질수록 비용이 매우 가파르게 증가하는 단점이 있습니다 [27, 28].
|
||||
* **세션 리플레이와 개인정보 침해 (Privacy Concerns):** LogRocket처럼 '모든 것을 캡처'하는 세션 리플레이 방식은 기본적으로 강력한 디버깅 정보를 제공하지만, 민감한 사용자 데이터까지 녹화될 수 있는 심각한 개인정보 침해 우려가 동반됩니다. 따라서 별도의 마스킹 및 설정 작업이 강제됩니다 [5, 29, 30].
|
||||
* **Error Boundaries의 한계:** 선언적인 UI 에러 처리에 강력하지만, 이벤트 핸들러 내부의 에러, `setTimeout` 같은 비동기 코드, 서버 사이드 렌더링(SSR), 그리고 Error Boundary 자체에서 발생한 에러는 포착하지 못합니다. 이러한 부분은 전통적인 자바스크립트의 `try/catch` 블록으로 디버깅 및 예외 처리를 해야 하는 제약이 있습니다 [31, 32].
|
||||
* **React Compiler 도입에 따른 디버깅 난이도 증가:** 코드를 자동으로 최적화해주는 React Compiler는 내부 로직이 블랙박스(Black box) 형태로 동작합니다. 개발자는 최적화된 부분과 그 이유에 대한 가시성을 잃게 되며, 예기치 않은 리렌더링 발생 시 코드상의 `React.memo`나 `useCallback` 호출을 확인하는 대신 React DevTools Profiler에 전적으로 의존해 조사해야 하므로 디버깅 난이도가 상승합니다 [33].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (브라우저 및 성능 분석 기반 도구)]
|
||||
@@ -71,4 +88,53 @@
|
||||
- 확장 방향: 디버깅을 통해 발견한 메모리 누수와 불필요한 컴포넌트 렌더링(Re-renders) 문제를 실질적인 성능 최적화 기법(가상화, 코드 스플리팅)으로 해결하여 Core Web Vitals를 개선하는 방향 [20, 50].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-30*
|
||||
*Last updated: 2026-04-30*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-DECLARATION-FILES
|
||||
category: Unified
|
||||
id: wiki-2026-0508-declaration-files
|
||||
title: Declaration Files
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AI-DECLARATION-FILES]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.99
|
||||
tags: [TypeScript, [[JavaScript|JavaScript]], DeclarationFiles, Tooling]
|
||||
tags: [TypeScript, JavaScript, DeclarationFiles, Tooling]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Declaration-Files|Declaration-Files]] (선언 파일, .d.ts)
|
||||
@@ -19,9 +31,58 @@ last_reinforced: 2026-04-20
|
||||
- **[[Ambient Declarations|Ambient Declarations]]**: `window`나 `process` 같은 전역 객체에 타입을 추가하는 용도.
|
||||
- **Compiler [[Behavior|Behavior]]**: 런타임에는 아무런 영향을 주지 않으며, 오직 '에디터'와 '컴파일 타임'의 안정성만을 위해 존재한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 선언 파일과 실제 JS 코드가 불일치(Out-of-sync)할 때 발생하는 '거짓 안전(False sense of security)'이 가장 위험하다. 이를 방지하기 위해 라이브러리 제작자는 `tsc`를 통해 구현부에서 타입을 자동 추출(emitDeclarationOnly)하는 방식을 지향해야 한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[DefinitelyTyped|DefinitelyTyped]] , TypeScript-Type-System
|
||||
- Practice: Publishing-Dual-CJS-ESM-Packages
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-DEFINITELY-TYPED
|
||||
category: Unified
|
||||
id: wiki-2026-0508-definitelytyped
|
||||
title: DefinitelyTyped
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AI-DEFINITELY-TYPED]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.98
|
||||
tags: [TypeScript, [[JavaScript|JavaScript]], OpenSource, TypeSystem]
|
||||
tags: [TypeScript, JavaScript, OpenSource, TypeSystem]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[DefinitelyTyped|DefinitelyTyped]]
|
||||
@@ -20,9 +32,58 @@ last_reinforced: 2026-04-20
|
||||
- 수천 명의 기여자와 자동화된 테스트 봇(dtslint)이 타입의 정확성을 검증한다.
|
||||
- **Impact**: 자바스크립트 생태계를 타입스크립트로 전환한 일등 공신이며, IDE의 자동 완성 기능을 가능하게 하는 핵심 인프라다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 최근에는 많은 라이브러리가 자체적으로 TS를 사용해 빌드하거나, 패키지 내부에 타입 파일을 포함(Bundled types)하는 추세다. 따라서 DefinitelyTyped는 '자체 타입이 없는 레거시 라이브러리'를 지원하는 역할로 조금씩 이동하고 있으나, 그 방대함 때문에 여전히 필수적이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Declaration-Files|Declaration-Files]] , TypeScript-Type-System
|
||||
- [[Storage|Storage]]: GitHub
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-diffing-algorithm
|
||||
title: Diffing Algorithm
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Diffing Algorithm|Diffing Algorithm]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Diffing Algorithm(디핑 알고리즘)은 React에서 이전 가상 DOM([[Virtual DOM|Virtual DOM]]) 트리와 새롭게 계산된 트리를 비교하여 실제 DOM을 가장 효율적으로 업데이트할 방법을 결정하는 과정입니다 [1, 2]. 이론적인 트리 비교 알고리즘은 $O(n^3)$의 시간 복잡도를 가져 실시간 애플리케이션에 부적합하지만, React는 두 가지 휴리스틱 가정을 통해 이를 $O(n)$ 복잡도로 최적화했습니다 [3-5]. 이 알고리즘은 '[[Reconciliation|Reconciliation]](재조정)' 과정의 핵심으로, 불필요한 DOM 조작을 최소화하여 렌더링 성능을 극대화하는 역할을 합니다 [1, 2, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **알고리즘의 기본 원리 및 가정:**
|
||||
React의 디핑 알고리즘은 두 가지 주요 가정에 기반하여 $O(n)$의 성능을 달성합니다. 첫째, 서로 다른 타입의 요소는 근본적으로 다른 트리를 생성한다고 가정합니다 [3, 5]. 둘째, 개발자가 제공하는 `key` prop을 통해 여러 렌더링 사이클 동안 안정적으로 유지되는 자식 요소를 식별할 수 있다고 가정합니다 [3, 5].
|
||||
|
||||
@@ -18,10 +38,64 @@ Diffing Algorithm(디핑 알고리즘)은 React에서 이전 가상 DOM([[Virtua
|
||||
* **트레이드오프 및 주의사항:**
|
||||
이 알고리즘은 휴리스틱에 의존하기 때문에 가정이 충족되지 않으면 성능이 저하될 수 있습니다 [14]. 예를 들어 하위 트리가 형제 요소 사이가 아닌 아예 다른 계층으로 이동하는 경우, 알고리즘은 해당 하위 트리를 완전히 다시 렌더링합니다 [15]. 또한 배열의 인덱스를 키로 사용하거나 `Math.random()` 같은 불안정한 키를 사용하면 리스트가 재정렬될 때 컴포넌트 상태가 꼬이거나 성능 저하가 발생할 수 있습니다 [14, 16].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Virtual DOM|Virtual DOM]], Reconciliation, [[React Fiber|React Fiber]]
|
||||
- **Projects/Contexts:** [[React Frontend Development|React Frontend Development]], [[Component-Based Architecture|Component-Based Architecture]]
|
||||
- **Contradictions/Notes:** 일반적인 트리 비교 알고리즘은 $O(n^3)$의 복잡도를 가지지만, React의 디핑 알고리즘은 휴리스틱([[Heuristics|Heuristics]])을 적용하여 실용적인 $O(n)$ 복잡도로 구현되었다는 점이 핵심적인 기술적 차이입니다 [4, 5]. 배열의 인덱스를 `key`로 사용하는 것은 요소의 순서가 변경되지 않을 때만 유효하며, 재정렬(Reorder) 시에는 비효율적이고 상태 오류를 일으킬 수 있으므로 권장되지 않습니다 [13, 16].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: TS-UNION-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-discriminated-unions-for-error-h
|
||||
title: Discriminated Unions for Error Handling
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [TS-UNION-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [typescript, type-system, [[Functional-Programming|Functional-Programming]], error-handling]
|
||||
tags: [typescript, type-system, Functional-Programming, error-handling]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Discriminated Unions|Discriminated Unions]] (판별 가능한 유니온)
|
||||
@@ -19,7 +31,7 @@ last_reinforced: 2026-04-26
|
||||
- **Error Handling:** `Success`와 `Failure` 타입을 유니온으로 묶어 런타임 에러 대신 컴파일 타임에 예외 처리를 강제.
|
||||
- **Pattern Matching:** 함수형 언어의 패턴 매칭과 유사한 안정성을 객체 지향 환경에서 구현.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** `instanceof`나 임의의 속성 체크 기반의 불안정한 타입 가드에서, 명시적인 '태그' 기반의 선언적 타입 가드로 표준화됨.
|
||||
- **정책 변화:** Antigravity 에이전트의 통신 프로토콜 정의 시, 메시지 타입을 Discriminated Unions로 정의하여 파싱 오류를 원천 차단함.
|
||||
|
||||
@@ -27,3 +39,52 @@ last_reinforced: 2026-04-26
|
||||
- **Parent:** 10_Wiki/💡 Topics/AI
|
||||
- **Related:** Type-Guards, Algebraic-Data-Types, [[Exhaustiveness-Checking|Exhaustiveness-Checking]]
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/[[Discriminated-Unions|Discriminated-Unions]]-for-Error-Handling.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-DU-[[State|State]]S
|
||||
category: Unified
|
||||
id: wiki-2026-0508-discriminated-unions-for-state-m
|
||||
title: Discriminated Unions for State Modeling
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AI-DU-StateS]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.99
|
||||
tags: [TypeScript, State[[Management|Management]], Patterns, [[Architecture|Architecture]]]
|
||||
tags: [TypeScript, StateManagement, Patterns, Architecture]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Discriminated-Unions-for-State-Modeling|Discriminated-Unions-for-State-Modeling]] (상태 모델링을 위한 구별된 유니온)
|
||||
@@ -20,9 +32,58 @@ last_reinforced: 2026-04-20
|
||||
- `type` 속성을 통해 현재 어떤 상태인지 명확히 구별하며, 각 상태에 꼭 필요한 데이터만 가질 수 있게 강제한다.
|
||||
- **Benefit**: 컴포넌트나 로직에서 조건문 분기가 매우 명확해지며, 런타임 에러 발생 가능성이 획기적으로 줄어든다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 상태가 복잡해지면(예: 부분적 성공, 멀티 스텝 폼 등) 유니온의 조합이 기하급수적으로 늘어날 수 있다. 이때는 상태 머신(State Machine, 예: XState) 라이브러리를 도입하여 타입 안전성과 비즈니스 흐름 제어를 동시에 잡는 것이 권장된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Discriminated-Unions|Discriminated-Unions]] , [[Finite-State-Machines|Finite-State-Machines]]
|
||||
- Context: React-Query-Pattern
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-0B8FFC
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-draw-call-optimization
|
||||
title: Draw Call Optimization
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-0B8FFC]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - [[Draw Call|Draw Call]] [[Optimization|Optimization]]"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Draw Call Optimization|Draw Call Optimization]]
|
||||
@@ -21,7 +32,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Draw Call|Draw Call]] [[Opti
|
||||
* **가시성 제어 (Visibility & LOD):** 카메라 시야 밖의 객체에 대한 렌더링 명령을 제외하는 절두체 컬링([[Frustum Culling|Frustum Culling]])을 수행하고 [18, 25], 카메라와의 거리에 따라 기하학적 복잡도를 낮추는 LOD(Level of Detail) 기법을 적용하여 멀리 있는 객체에서 발생하는 불필요한 드로우 콜과 연산을 최소화합니다 [9, 26-28].
|
||||
* **구조적 한계 및 고려사항 (Limitations & Trade-offs):** `InstancedMesh`를 통한 드로우 콜 단일화가 항상 최선은 아닙니다. 단일 객체로 취급되어 가시성 판정이 '전부 아니면 전무(All-or-Nothing)'로 이루어져 절두체 컬링이 비효율적으로 작동할 수 있습니다 [29, 30]. 또한, 인스턴스 간 자동 정렬 부재로 인한 심각한 오버드로우([[Overdraw|Overdraw]]) 현상과 매 프레임 수많은 변환 행렬 데이터를 갱신할 때 발생하는 메모리 대역폭 한계로 인해 또 다른 성능 병목이 유발될 수 있습니다 [29, 31, 32]. [[Unity|Unity]] 같은 게임 엔진에서는 이와 같은 드로우 콜 최적화 방식들이 겹칠 때 SRP Batcher, 정적 배칭(Static batching), GPU 인스턴싱 순으로 우선순위를 두어 충돌을 제어합니다 [33, 34].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -34,3 +45,52 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Draw Call|Draw Call]] [[Opti
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,18 +1,92 @@
|
||||
---
|
||||
id: wiki-2026-0508-dynamic-theming
|
||||
title: Dynamic Theming
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Dynamic Theming|Dynamic Theming]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Dynamic Theming(동적 테마 적용)은 라이트 모드/다크 모드 또는 다중 브랜드 테마와 같이 사용자 설정이나 컨텍스트에 따라 UI의 시각적 속성을 런타임에 유연하게 전환할 수 있는 기법입니다. 이는 주로 디자인 토큰([[Design Tokens|Design Tokens]]), CSS 변수(Custom Properties), 또는 styled-components와 같은 [[CSS-in-JS|CSS-in-JS]] 라이브러리를 활용하여 구현됩니다. 컴포넌트 코드의 직접적인 수정 없이 애플리케이션 전체의 디자인 시스템을 일관성 있고 확장 가능하게 관리하는 데 필수적인 역할을 합니다.
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **디자인 토큰 기반의 테마 전환 (Token Swapping):** 동적 테마 구현의 핵심은 단일 소스인 디자인 토큰을 활용하는 것입니다. 특정 시맨틱 토큰(Semantic Token)이 테마에 따라 다른 참조 값([[Reference|Reference]] Value)을 가리키도록 설정합니다(예: 라이트 모드에서는 `color.background = ref.gray.100`, 다크 모드에서는 `ref.gray.900`) [1]. Style Dictionary와 같은 도구를 활용하면 [[Figma|Figma]] 등에서 정의된 JSON 형식의 토큰을 CSS 변수나 React 테마 객체로 자동 변환하여 손쉽게 테마 전용 출력물을 생성할 수 있습니다 [2-4].
|
||||
* **CSS 변수([[CSS Variables|CSS Variables]])를 활용한 동적 테마:** 최적의 성능을 위해 디자인 토큰을 CSS 변수에 매핑하여 사용하는 방식이 널리 쓰입니다 [5]. 테마별로 별도의 토큰 세트를 정의하고(예: `light-theme.css`, `dark-theme.css`), 런타임 시에 `<html>` 또는 `<body>` 같은 최상위 컨테이너에 테마 클래스를 토글하여 스타일을 업데이트할 수 있습니다 [5, 6]. 이 접근법은 값비싼 전체 리렌더링(full re-render)을 유발하지 않아 부드럽고 빠른 사용자 경험을 제공합니다 [5, 7]. 최근 [[Tailwind CSS v4|Tailwind CSS v4]]에서도 `@theme` 디렉티브와 CSS 변수를 활용해 네이티브 수준의 런타임 테마 전환을 직관적으로 지원합니다 [8, 9].
|
||||
* **React 프레임워크 및 CSS-in-JS의 테마 적용:** `styled-components`나 `Emotion` 같은 CSS-in-JS 라이브러리는 기본적으로 제공하는 `ThemeProvider`를 사용해 React 컴포넌트 트리에 동적으로 테마를 주입할 수 있어 다중 테마 구현에 매우 용이합니다 [10, 11]. 또한, `Chakra UI`는 CSS-in-JS를 기반으로 제작되어 런타임 시 라이트/다크 모드 동적 전환을 쉽게 구현할 수 있도록 돕습니다 [12].
|
||||
* **[[React Server Components (RSC)|React Server Components (RSC]] 환경에서의 제약과 해법:** Context 기반의 `ThemeProvider`는 React Context가 없는 서버 컴포넌트(RSC) 환경에서는 작동하지 않는 근본적인 한계가 있습니다 [13-15]. 이를 해결하기 위해 `styled-components` (v6.4 이상)는 `createTheme` 함수를 도입하여 일반 테마 객체를 CSS 사용자 정의 속성 참조(예: `var(--prefix-path)`)로 변환합니다 [13]. 이 방식은 React Context에 의존하지 않으므로 클라이언트와 서버 컴포넌트 모두에서 동작하며, 라이트/다크 모드 전환 시 하이드레이션([[Hydration|Hydration]]) 불일치나 화면 깜빡임(Flash)을 방지합니다 [13, 16].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Design Tokens|Design Tokens]], CSS Variables, Styled Components, [[Tailwind CSS|Tailwind CSS]], [[React Server Components (RSC)|React Server Components (RSC]]
|
||||
- **Projects/Contexts:** [[Scalable Frontend Systems|Scalable FrontendSystems]], [[Component Library Architecture|Component Library Architecture]], Design-to-Code Workflow
|
||||
- **Contradictions/Notes:** CSS-in-JS 라이브러리의 `ThemeProvider`는 동적인 테마 적용에 매우 유용하지만, [[Next.js|Next.js]]의 App Router와 같은 React Server Components(RSC) 아키텍처와는 본질적으로 호환되지 않습니다 [14, 15]. 최신 확장성 높은 프론트엔드 환경에서는 이러한 런타임 CSS-in-JS 대신 정적 생성된 CSS 변수나 Tailwind CSS, 혹은 제로 런타임 라이브러리([[vanilla-extract|vanilla-extract]]) 기반의 테마 시스템을 구축하는 것이 권장됩니다 [13, 15, 17, 18].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 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,25 @@
|
||||
---
|
||||
id: wiki-20260508-e-commerce-platforms-redir
|
||||
title: E commerce Platforms
|
||||
category: Frontend
|
||||
status: merged
|
||||
redirect_to: E-commerce_Platforms
|
||||
canonical_id: E-commerce_Platforms
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# E commerce Platforms
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[E-commerce_Platforms]]**로 통합되었습니다.
|
||||
|
||||
---
|
||||
*Redirected to: [[E-commerce_Platforms]]*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-ESPL-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-eslint-plugin-development
|
||||
title: ESLint Plugin Development
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ESPL-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, [[ESLint|ESLint]], plugin-development, static-[[Analysis|Analysis]], ast, [[JavaScript|JavaScript]], dev-tooling, automation]
|
||||
tags: [auto-reinforced, ESLint, plugin-development, static-Analysis, ast, JavaScript, dev-tooling, automation]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[ESLint-Plugin-Development|ESLint-Plugin-Development]]
|
||||
@@ -21,7 +33,7 @@ ESLint 플러그인 개발(ESLint-Plugin-Development)은 여러 ESLint 규칙(Ru
|
||||
2. **왜 중요한가?**:
|
||||
* 대규모 조직에서 매번 각 프로젝트의 린트 설정을 복사-붙여넣기 할 필요 없이, 중앙 관리형 플러그인 정책을 통해 코드 표준 정책을 일회성으로 전파할 수 있기 때문임. ([[Efficiency|Efficiency]]와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 단순한 정규표현식 정책 검사에 가까웠으나, 현대 정책은 강력한 '타입 정보 정책(Type-aware linting)'을 활용하여 타입스크립트의 타입 관계 정책까지 검증하는 고수준 플러그인 정책으로 발전함(RL Update).
|
||||
- **정책 변화(RL Update)**: 이제는 단순 에러 감지 정책을 넘어, 복잡한 리팩토링 정책을 코드가 써진 순간 자동으로 수행(Fixer)해 주는 보좌진 역할을 수행함. ([[Quality-Control|Quality-Control]]와 연결)
|
||||
|
||||
@@ -29,3 +41,52 @@ ESLint 플러그인 개발(ESLint-Plugin-Development)은 여러 ESLint 규칙(Ru
|
||||
- [[Custom-ESLint-Rules|Custom-ESLint-Rules]], [[Efficiency|Efficiency]], [[Quality-Control|Quality-Control]], [[Technical-Architecture|Technical-Architecture]], Standard-Operating-Procedure, Automation
|
||||
- **Key Tools**: Yeoman generator-eslint, AST Explorer.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-C0B018
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-effect-ts-및-ts-brand-라이브러리-활용
|
||||
title: Effect TS 및 ts brand 라이브러리 활용
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-C0B018]
|
||||
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 - [[Effect TS|Effect TS]] 및 [[ts-brand|ts-brand]] 라이브러리 활용"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Effect TS 및 ts-brand 라이브러리 활용|Effect TS 및 ts-brand 라이브러리 활용]]
|
||||
@@ -23,7 +34,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Effect TS|Effect TS]] 및 [[
|
||||
- **단언(Assertion) 함수의 차별화**: `ts-brand`의 `make`와 달리, Effect는 타입 브랜드 단언 함수를 만들기 위해 `Brand.refined`라는 별도의 함수를 제공합니다 [5]. 이 함수는 값이 제약 조건을 충족하는지 판별하는 함수와, 충족하지 않을 경우 에러를 던지는 함수 등 두 가지 매개변수를 받아 작동합니다 [5, 6].
|
||||
- **메타데이터 활용**: Effect TS는 에러 처리나 내부 제어 흐름을 명확히 구분하기 위해 `_tag`와 같은 메타데이터 속성을 활용하는 패턴을 제공하며, 이는 복잡한 로직에서 일관된 에러 처리와 내부 로직 판별을 돕습니다 [7, 8].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -36,3 +47,52 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Effect TS|Effect TS]] 및 [[
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,3 +1,23 @@
|
||||
---
|
||||
id: wiki-2026-0508-equipment-crafting-and-synthesis
|
||||
title: Equipment Crafting and Synthesis Engine
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Equipment Crafting and Synthesis Engine
|
||||
|
||||
Skybound의 장비 시스템은 전장에서의 획득을 넘어, 기지(Hangar)에서의 합성 및 연성을 통해 종결급 스펙에 도달하는 **Meta-game Loop**를 구성합니다.
|
||||
@@ -29,6 +49,72 @@ Skybound의 장비 시스템은 전장에서의 획득을 넘어, 기지(Hangar)
|
||||
**Context**: Meta-Game Economy / Progression Engineering
|
||||
**Tags**: #Growth_Loop #Mechanics #Progression
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Logic]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,7 +1,27 @@
|
||||
## 📌 Brief Summary
|
||||
---
|
||||
id: wiki-2026-0508-error-boundaries
|
||||
title: Error Boundaries
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Error Boundaries는 React 컴포넌트 트리 하위에서 발생하는 JavaScript 런타임 에러를 포착하여 전체 애플리케이션의 크래시(White Screen)를 방지하는 선언적 에러 처리 메커니즘이다. 에러가 발생한 지점을 격리하고 대체 UI(Fallback UI)를 렌더링함으로써 시스템의 가용성과 사용자 경험을 보호한다.
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
1. **작동 메커니즘 및 클래스 컴포넌트 의존성**
|
||||
- React 16부터 도입되었으며, 자식 컴포넌트의 렌더링, 수명 주기 메서드, 생성자 내부의 에러를 감지한다.
|
||||
- 반드시 클래스 컴포넌트로 구현해야 하며, `static getDerivedStateFromError()`로 상태를 업데이트하고 `componentDidCatch()`로 에러를 로깅한다.
|
||||
@@ -14,12 +34,12 @@ Error Boundaries는 React 컴포넌트 트리 하위에서 발생하는 JavaScri
|
||||
4. **미처리 에러의 결과**
|
||||
- 포착되지 않은 에러는 전체 컴포넌트 트리의 마운트 해제(Unmounting)를 유발하며, 이는 손상된 데이터가 사용자에게 노출되는 것보다 안전한 선택으로 간주된다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **클래스 컴포넌트 유지 필요성**: 최신 React가 Hooks 중심임에도 불구하고 Error Boundary 구현을 위해 클래스 컴포넌트를 유지해야 하는 아키텍처적 일관성 저하가 발생할 수 있다.
|
||||
- **성능 및 렌더링 오버헤드**: 너무 많은 Error Boundary를 중첩할 경우 트리 깊이가 깊어지고 에러 전파 체크 로직에 따른 미세한 성능 영향이 있을 수 있다.
|
||||
- **비동기 에러 처리의 공백**: 렌더링 에러만 포착하므로, 비동기 데이터 통신이 빈번한 현대 앱에서는 `react-error-boundary`와 같은 라이브러리를 통한 추가 처리가 필수적이다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Frontend]]
|
||||
* [[JavaScript]]
|
||||
@@ -47,3 +67,52 @@ Error Boundaries는 React 컴포넌트 트리 하위에서 발생하는 JavaScri
|
||||
- **Try/Catch Statement in JS**
|
||||
- **Observability in Frontend**
|
||||
- **Graceful Degradation Design**
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: e1r2r3o4-h5a6-4n7d-l8i9-n0g1s2t3a4b5
|
||||
category: Unified
|
||||
id: wiki-2026-0508-error-handling-and-stability
|
||||
title: Error Handling and Stability
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [e1r2r3o4-h5a6-4n7d-l8i9-n0g1s2t3a4b5]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.99
|
||||
tags: [react, error-handling, stability, error-boundary, monitoring, resilience]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-error-handling"
|
||||
github_commit: wikification-error-handling
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Frontend Error Handling & Application Stability
|
||||
@@ -13,7 +24,6 @@ github_commit: "wikification-error-handling"
|
||||
> 프론트엔드 안정성은 모든 에러를 막는 것이 아니라, 발생한 에러가 전체 앱의 화이트 스크린으로 번지지 않도록 구획을 나누고(Error Boundary), 실시간 모니터링을 통해 빠르게 인지하고 복구하는 회복 탄력성(Resilience)에 있다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 계층적 에러 처리 전략
|
||||
- **Error Boundaries**: React 컴포넌트 트리 상위에서 하위 컴포넌트의 런타임 에러를 캡처하여 사용자에게 대체 UI를 보여준다. 핵심 비즈니스 영역별로 안전장치를 배치한다.
|
||||
- **Global Error Handling**: `window.onerror`, `unhandledrejection` 이벤트를 구독하여 예기치 못한 비동기 에러를 전역에서 캡처하고 서버로 전송한다.
|
||||
@@ -26,7 +36,7 @@ github_commit: "wikification-error-handling"
|
||||
### 3. 모니터링 및 분석
|
||||
- **Sentry 통합**: 에러 발생 시점의 사용자 세션, 기기 정보, 스택 트레이스를 수집하여 재현 및 수정을 용이하게 한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과도한 에러 무시**: 모든 에러를 묵묵히 처리하면 실제 심각한 논리 오류를 놓칠 수 있다. 로그 수집과 경고 알림(Alerting) 체계가 병행되어야 한다.
|
||||
- **에러 바운더리의 한계**: 이벤트 핸들러나 비동기 코드 내부의 에러는 Error Boundary가 직접 캡처하지 못하므로 별도의 처리가 필요하다.
|
||||
|
||||
@@ -40,7 +50,7 @@ github_commit: "wikification-error-handling"
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Frontend Error Handling and Application Stability Standard"`
|
||||
3. Push: `git push origin main`
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[2026-05-01]]
|
||||
* [[Boundaries]]
|
||||
@@ -51,3 +61,52 @@ github_commit: "wikification-error-handling"
|
||||
* [[P-Reinforce]]
|
||||
* [[React]]
|
||||
* [[Resilience]]
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-[[ESLint|ESLint]]
|
||||
category: Unified
|
||||
confidence_score: 1.00
|
||||
tags: [[JavaScript|[JavaScript]], Tooling, ESLint, Static[[Analysis|Analysis]]]
|
||||
id: wiki-2026-0508-es-lint-configuration
|
||||
title: Es Lint Configuration
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["JavaScript|[JavaScript", Tooling, ESLint, StaticAnalysis]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Es-Lint-Configuration|Es-Lint-Configuration]] (ESLint 설정 가이드)
|
||||
@@ -19,9 +31,58 @@ last_reinforced: 2026-04-20
|
||||
- **Rules**: 'off', 'warn', 'error' 3단계로 개별 규칙의 엄격도 조절.
|
||||
- **Auto-fix**: 저장 시점에 세미콜론 누락, 안 쓰는 변수 제거 등을 자동으로 교정하여 생산성 향상.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- 최신 ESLint(v9+)는 설정 파일 형식이 완전히 바뀐 'Flat Config' 시대로 진입했다. 기존 `eslintrc.*` 방식은 레거시가 되었으므로, 새로운 프로젝트에서는 `eslint.config.js`를 사용해야 한다. 또한 포맷팅 전용 도구인 [[Prettier|Prettier]]와 충돌하지 않도록 역할 분담(Linter: 논리검사, Formatter: 모양검사)을 명확히 하는 것이 핵심이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Prettier-Configuration , [[Custom-ESLint-Rules-Development|Custom-ESLint-Rules-Development]]
|
||||
- Part of: [[SAST (Static Application Security Testing)|SAST (Static Application Security [[Testing]])]]
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,15 +1,29 @@
|
||||
---
|
||||
category: Unified
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
id: wiki-2026-0508-eugen-systems의-warno-시뮬레이션-개발
|
||||
title: Eugen Systems의 WARNO 시뮬레이션 개발
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Eugen Systems의 WARNO 시뮬레이션 개발
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Eugen Systems가 개발한 WARNO는 1989년 냉전이 열전으로 번진 가상의 시나리오를 배경으로 하는 실시간 전술(RTT) 및 턴제 전략 시뮬레이션 게임입니다 [1, 2]. 이 게임은 자체 개발한 Iriszoom 엔진을 통해 세밀한 3D 그래픽과 대규모 전장을 매끄럽게 구현하며, NDF(Neutral Data Format)라는 독자적인 스크립트 언어를 활용한 데이터 아키텍처를 기반으로 설계되었습니다 [3-5]. 개발진은 커뮤니티의 피드백뿐만 아니라 객관적인 텔레메트리(Telemetry) 데이터를 실시간으로 분석하여 무기 스펙과 사단 편제 등 시뮬레이션의 전술적 밸런스를 정교하게 조정합니다 [6, 7].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **Iriszoom 엔진과 시각적 가시화:**
|
||||
WARNO는 과거 R.U.S.E.부터 진화해 온 Eugen Systems의 독자 엔진인 Iriszoom의 최신 버전을 사용합니다 [3, 4]. 이 엔진은 물리 기반 렌더링(PBR) 시스템과 Metallic/Roughness/Ambient Occlusion 워크플로우를 도입하여 4K 해상도로 유닛과 지형의 질감을 매우 사실적으로 구현합니다 [3, 4, 8]. 기술적으로 지연 렌더링(Deferred Rendering) 구조를 활용해 수백 대의 유닛이 맞붙는 10 대 10 멀티플레이어 환경에서도 뛰어난 최적화를 유지하며, 탄약고 유폭 시 포탑이 날아가거나 헬기 로터 블레이드가 떨어져 나가는 동적 파괴 시스템이 물리 데이터와 연동되어 표현됩니다 [4, 9-11].
|
||||
|
||||
@@ -22,10 +36,64 @@ Eugen Systems가 개발한 WARNO는 1989년 냉전이 열전으로 번진 가상
|
||||
* **텔레메트리(Telemetry) 기반 밸런싱과 수학적 정밀도:**
|
||||
게임 내 전투 역학은 거리 비례 명중률(가까울수록 기하급수적으로 상승), 승수적으로 작용하는 항공기 ECM(전자전) 데이터, 무기 사거리 등 복잡한 수학적 모델을 따릅니다 [25-28]. Eugen Systems는 이렇게 복잡하게 얽힌 시스템을 밸런싱하기 위해 플레이어들의 유닛 선택률(Pick rate), 교전 승률, 평균 생존 시간 등을 추적하는 '텔레메트리 데이터'를 활용합니다 [6, 7]. 개발진은 커뮤니티의 단순한 여론에 휩쓸리지 않고 수집된 객관적 데이터를 분석하여, 특정 유닛이나 사단이 과도한 효율을 낼 경우 NDF 파일의 포인트 비용이나 세부 스펙을 정밀하게 조정하는 방식을 취합니다 [6, 7, 29].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** `[[Iriszoom 엔진|Iriszoom 엔진]]`, `[[NDF (Neutral Data Format)|NDF (Neutral Data Format)]]`, `[[사단 시스템 (Division System)|사단 시스템 (Division System)]]`, `[[텔레메트리 (Telemetry) 밸런싱|텔레메트리 (Telemetry) 밸런싱]]`
|
||||
- **Projects/Contexts:** `[[WARNO|WARNO]]`, `[[Wargame 시리즈|Wargame 시리즈]]`, `[[Steel Division 시리즈|Steel Division 시리즈]]`, `[[RebsFRAGO 모드|RebsFRAGO 모드]]`
|
||||
- **Contradictions/Notes:** 덱 구성 아키텍처와 관련하여, 일부 유저들은 과거 Wargame 시리즈처럼 제약이 없는 국가별 덱 시스템이 유저의 창의성을 높인다고 주장하지만, 개발진과 다른 다수의 유저들은 사단 시스템(Division System)이 메타 고착화를 방지하고 훨씬 다양하고 역사적으로 몰입감 있는 밸런스를 제공한다고 반박합니다 [19, 30-34].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
*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 |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-events
|
||||
title: Events
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Events|Events]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
게임 오브 워(Game of War) 및 4X 전략 게임에서 '이벤트(Events)'는 플레이어의 장기적 참여와 사회적 협력, 그리고 지속적인 수익 창출(Monetization)을 유도하기 위해 설계된 핵심적인 기간 한정 활동입니다. 이러한 이벤트는 매일 진행되는 소규모 일과부터 다수의 왕국(서버)이 맞붙는 대규모 전쟁에 이르기까지 다양하게 구성되며, 라이브옵스(LiveOps) 스케줄과 촘촘하게 결합되어 유저들의 결제를 강력하게 촉진합니다. 최상위 이벤트의 결과는 서버의 존폐나 최고 권력의 향방을 결정지을 만큼 막대한 영향력을 지닙니다.
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **라이브옵스(LiveOps)와 결제(Monetization)의 핵심 동력**
|
||||
* 이벤트는 4X 전략 게임에서 유저의 유지(Retention)를 수익으로 전환하는 가장 중요한 수단입니다 [1].
|
||||
* '즉각적 수익화 전략(Immediate Monetization Strategy)'을 사용하는 게임들은 한 번에 최대 15개에 달하는 정규 및 시즌 이벤트를 동시에 진행하며 플레이어를 압도합니다. 각 이벤트의 보상과 진행도가 서로 맞물려 있어, 유저가 끊임없이 이벤트에 참여하고 그 과정에서 자연스럽게 패키지 상품을 구매하도록 설계되어 있습니다 [1, 2].
|
||||
@@ -22,10 +42,64 @@
|
||||
* 대규모 전투 외에도 건설(Build), 병력 훈련, 몬스터 사냥(Kill Monster) 등 일상적인 행동과 연계된 이벤트들이 끊임없이 순환합니다 [13].
|
||||
* 자신의 왕국 내에서 요새를 점령하거나 특정 토큰을 모으는 도미네이션(Domination) 이벤트, 포트리스 킬(Fortress Kill) 이벤트 등을 통해 유저들 간의 상호작용과 경쟁을 일상적으로 유도합니다 [14].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Kingdom vs. Kingdom (KvK)|Kingdom vs. Kingdom (KvK)]], Super Wonder, [[LiveOps|LiveOps]], [[수익화(Monetization)|Monetization]]
|
||||
- **Projects/Contexts:** Game of War: Fire Age BM 및 구조, 4X 전략 게임 이벤트 구조
|
||||
- **Contradictions/Notes:** 소스에 따르면 4X 게임의 수익화 전략에 따라 이벤트 운영 철학이 극명하게 갈립니다. 일부 게임(예: Puzzles & Survival)은 이벤트를 고밀도로 중첩시켜 강한 과금 압박과 행동을 유도하는 반면, 다른 게임(예: State of Survival, King of Avalon)은 이벤트의 수를 제한하고 UI에서 숨길 수 있는 선택권까지 제공하여 유저의 피로도를 낮추고 장기적인 신뢰를 구축하는 방식을 택합니다 [1-3, 15].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
*Last updated: 2026-04-27*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-EYTR-001
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced, eye-tracking, hci, [[Biometrics|Biometrics]], attention, usability]
|
||||
id: wiki-2026-0508-eye-tracking
|
||||
title: Eye Tracking
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-EYTR-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced, eye-tracking, hci, Biometrics, attention, usability]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Eye-Tracking|Eye-Tracking]]
|
||||
@@ -23,7 +35,7 @@ last_reinforced: 2026-04-20
|
||||
* **Medical**: 자폐증이나 치매 초기 진단.
|
||||
* **Gaming/VR**: 시선이 머무는 곳만 고해상도로 렌더링(Foveated Rendering)하여 [[Efficiency|Efficiency]] 극대화.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 전용 안경이나 수천만 원대 장비 정책이 필수였으나, 현대 정책은 딥러닝과 웹캠만으로 시선을 추적하는 '범용 카메라 기반 소프트웨어 정책'으로 대중화됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 광고나 마케팅 정책에서 시선을 강제로 빼앗는 '다크 패턴 정책'에 대한 규제와, 시선 데이터가 개인의 무의식을 드러낸다는 점에서 발생하는 '생체 정보 시선 프라이버시 정책'이 강화되고 있음.
|
||||
|
||||
@@ -31,3 +43,52 @@ last_reinforced: 2026-04-20
|
||||
- User Experience (UX), [[Design-System|Design-System]], [[Affective Computing|Affective Computing]], [[Analysis|Analysis]], [[Cognitive Biases|Cognitive Biases]]
|
||||
- **Modern Tech/Tools**: Tobii, Gazepoint, Webcam-based eye trackers (Webgazer.js).
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,17 +1,29 @@
|
||||
---
|
||||
category: Frontend
|
||||
tags: [auto-wikified, technical-documentation, frontend]
|
||||
id: wiki-2026-0508-fabric
|
||||
title: Fabric
|
||||
description: "Fabric은 React Native의 새로운 아키텍처(New Architecture)를 구성하는 핵심 요소 중 하나로, 밑바닥부터 완전히 새롭게 재작성된 새로운 UI 렌더링 시스템(UI 관리 레이어)이다 [1, 2]."
|
||||
last_updated: 2026-05-04
|
||||
category: Frontend
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-wikified, technical-documentation, frontend]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Fabric
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Fabric은 React Native의 새로운 아키텍처(New Architecture)를 구성하는 핵심 요소 중 하나로, 밑바닥부터 완전히 새롭게 재작성된 새로운 UI 렌더링 시스템(UI 관리 레이어)이다 [1, 2]. 기존의 비동기 브릿지(Bridge) 방식의 병목 현상을 해결하기 위해 설계되었으며, 네이티브 UI 레이어에 대한 동기적 접근을 가능하게 한다 [1, 2]. 이를 통해 동시성 렌더링(Concurrent Rendering)과 동기적인 레이아웃 계산을 지원하며, 결과적으로 React Native 애플리케이션의 네이티브 렌더링 성능과 응답성을 비약적으로 향상시킨다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **동기적 네이티브 UI 접근 메커니즘**
|
||||
기존 아키텍처에서는 UI가 별도의 네이티브 스레드에서 관리되고 자바스크립트 스레드와의 통신이 비동기식으로 이루어져 성능 지연이 발생했다 [1, 2]. Fabric은 이 구조를 혁신하여, C++에서 UI의 가상 표현인 '섀도 트리(Shadow Tree)'를 직접 생성하고 스레드 간에 공유할 수 있도록 한다 [1]. 이를 통해 비동기적인 왕복 통신(round-trips) 없이도 네이티브 뷰를 측정하고 렌더링할 수 있게 된다 [2].
|
||||
|
||||
@@ -24,12 +36,11 @@ Fabric은 React Native의 새로운 아키텍처(New Architecture)를 구성하
|
||||
* **네이티브 컴포넌트 수준의 고성능 애니메이션**
|
||||
렌더링 로직을 C++로 이동시키고 직접 통신을 활성화함으로써, Fabric은 UI 컴포넌트의 렌더링 및 업데이트 소요 시간을 대폭 감소시킨다 [1]. 이러한 네이티브 컴포넌트 렌더링 제어를 통해 부드러운 애니메이션과 거의 네이티브 수준에 근접한 성능(near-native performance)을 달성하게 된다 [3, 4].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
소스에 관련 정보가 부족합니다.
|
||||
단, 소스에 명시된 아키텍처 구조를 통해 유추할 수 있는 제약 사항으로는 Fabric이 단독으로 기능하기보다는 JSI(JavaScript Interface) 기반의 바인딩과 TurboModules 등 New Architecture의 다른 요소들과 완벽하게 결합되어야만 비동기 브릿지의 한계를 극복하고 완전한 성능 향상을 이룰 수 있다는 구조적 종속성이 존재한다 [2, 4-6]. 또한 기존 브릿지 기반으로 작성된 서드파티 네이티브 라이브러리들은 이 새로운 동기식 렌더링 파이프라인에 맞춰 호환성 업데이트를 거쳐야 할 수 있다 [7, 8].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/기반 기술)]
|
||||
@@ -65,4 +76,53 @@ Fabric은 React Native의 새로운 아키텍처(New Architecture)를 구성하
|
||||
- 확장 방향: React Native가 Fabric을 통해 UI 비동기 병목을 해결했듯, Flutter 진영이 기존 Skia 엔진의 셰이더 컴파일 지연(Jank) 현상을 해결하기 위해 내놓은 커스텀 렌더링 엔진인 'Impeller'의 구조와 렌더링 방식을 비교 분석함으로써 모바일 크로스 플랫폼 렌더링 최적화 기술 전반의 흐름을 이해할 수 있다 [7, 9, 15].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-03*
|
||||
*Last updated: 2026-05-03*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (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,25 @@
|
||||
---
|
||||
id: wiki-20260508-feature-driven-architecture-redir
|
||||
title: Feature Driven Architecture
|
||||
category: Frontend
|
||||
status: merged
|
||||
redirect_to: Feature-Driven_Architecture
|
||||
canonical_id: Feature-Driven_Architecture
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# Feature Driven Architecture
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[Feature-Driven_Architecture]]**로 통합되었습니다.
|
||||
|
||||
---
|
||||
*Redirected to: [[Feature-Driven_Architecture]]*
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
id: wiki-20260508-fiber-architecture-redir
|
||||
title: Fiber Architecture
|
||||
category: Frontend
|
||||
status: merged
|
||||
redirect_to: Fiber_Architecture
|
||||
canonical_id: Fiber_Architecture
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# Fiber Architecture
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[Fiber_Architecture]]**로 통합되었습니다.
|
||||
|
||||
---
|
||||
*Redirected to: [[Fiber_Architecture]]*
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
id: wiki-2026-0508-fiber-아키텍처-fiber-architecture
|
||||
title: Fiber 아키텍처 (Fiber Architecture)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Fiber 아키텍처 ([[Fiber Architecture]])]]
|
||||
|
||||
## 📌[[ brief]] 신Summary
|
||||
Fiber 아키텍처는 동시성 렌더링([[Concurrent Rendering]])을 지원하고 렌더링 프로세스를 세밀하게 제어하기 위해 React 16에서 도입된 재조정([[Reconciliation]]) 엔진의 완전한 재작성 버전이다 [1-3]. 이 아키텍처는 렌더링 작업을 '파이버 노드(Fiber node)'라고 불리는 작은 작업 단위(unit of work)로 분할하여 점진적으로 처리하는 작업 루프(work loop)를 기반으로 작동한다 [4, 5]. 렌더링 도중 우선순위가 높은 상호작용이 발생하면 작업을 일시 중지하고 브라우저에 제어권을 넘겼다가 다시 시작할 수 있는 '타임 슬라이싱([[Time-Slicing]])'을 가능하게 하여 UI의 반응성을 크게 향상시킨다 [4, 5].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **작업 루프와 파이버 트리 (Work Loop and Fiber Tree):**
|
||||
이전의 React는 스택 재조정자(stack reconciler)를 사용하여 전체 컴포넌트 트리를 단일 재귀 호출로 한 번에 처리했기 때문에 메인 스레드를 차단하는 문제가 있었다 [4]. Fiber는 컴포넌트 트리의 각 노드를 자식(child), 형제(sibling), 부모(return)에 대한 포인터를 가진 '파이버 노드'로 구성하며, 이를 단위로 작업 루프를 돈다 [6, 7]. 스케줄러는 트리를 깊이 우선 탐색(depth-first) 방식으로 순회하며 렌더링 작업을 수행하고, 현재 프레임에 남은 시간이 없으면 작업을 일시 중단(yield)하여 브라우저의 끊김을 방지한다 [7, 8].
|
||||
* **재조정 단계 (Reconciliation Phases):**
|
||||
React의 재조정 프로세스는 작업 중단 및 우선순위 지정을 가능하게 하기 위해 두 가지 명확한 단계로 나뉜다 [9].
|
||||
* **렌더 단계 (Render phase):** 트리를 순회하며 이전 상태와 새로운 상태 간의 차이를 계산하는 단계로, DOM을 직접 수정하지 않는다 [9, 10]. 이 단계는 언제든 중단, 취소, 재시작이 가능하며 부작용(side effects)을 실행해서는 안 된다 [9, 10]. 렌더 단계가 끝나면 변경이 필요한 파이버들만 모아 이펙트 목록(effect list)을 구성한다 [11].
|
||||
* **커밋 단계 (Commit phase):** 중단될 수 없는 동기적인 단계로, 렌더 단계에서 생성된 이펙트 목록을 바탕으로 DOM 노드의 삽입, 삭제, 업데이트를 한 번에 적용한다 [10, 12]. 이 단계에서 `useLayoutEffect` 및 `useEffect`와 같은 생명주기 메서드와 훅이 실행된다 [10, 12, 13].
|
||||
* **우선순위 스케줄링과 레인 모델 (Priority and [[Lane Model]]):**
|
||||
Fiber는 여러 업데이트의 혼합된 우선순위를 효율적으로 관리하기 위해 '레인(Lanes)'이라는 비트마스크 시스템을 사용한다 [14, 15]. 작업은 사용자 타이핑이나 클릭처럼 즉각적인 처리가 필요한 동기(Sync) 레인부터 스크롤과 같은 사용자 차단(User-[[Blocking]]) 레인, 데이터 페칭 결과를 나타내는 기본(Default) 레인, 백그라운드 작업인 유휴(Idle) 레인 등으로 분류된다 [14, 16]. 이를 통해 긴급한 UI 상호작용이 무거운 비동기 업데이트보다 먼저 처리될 수 있다 [14, 17].
|
||||
* **동시성 기능의 기반 (Foundation for Concurrent Features):**
|
||||
이러한 중단 가능한 렌더링 및 우선순위 관리 구조 덕분에 React는 `[[useTransition]]` 및 `[[useDeferredValue]]`와 같은 동시성 훅(concurrent hooks)을 도입할 수 있게 되었다 [18]. 이 훅들은 무거운 연산이 진행되는 동안에도 긴급한 사용자 입력을 위해 메인 스레드를 확보하여 부드러운 앱 경험을 유지하게 돕는다 [18, 19].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[가상 DOM ([[Virtual DOM]])]], [[재조정 (Reconciliation)]], [[동시성 렌더링 (Concurrent Rendering)]], 타임 슬라이싱 (Time-Slicing)
|
||||
- **Projects/Contexts:** React 16, [[React 19]] 동시성 훅 (useTransition, useDeferredValue)
|
||||
- **Contradictions/Notes:** 소스 간의 의견 충돌은 없으며, Fiber 아키텍처의 목표는 복잡한 렌더링 작업으로 인해 프레임이 떨어지는 기존의 스택 재조정자(Stack Reconciler) 문제를 해결하기 위해 필수적으로 도입된 구조적 변화라고 일관되게 설명된다 [2, 4].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-fiber-아키텍처와-동시성-concurrent-rende
|
||||
title: Fiber 아키텍처와 동시성 (Concurrent Rendering)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Fiber 아키텍처와 동시성 (Concurrent Rendering)|Fiber 아키텍처와 동시성 (Concurrent Rendering]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
React의 **Fiber 아키텍처**는 단일 호출로 전체 트리를 동기적으로 렌더링하여 메인 스레드를 차단하던 기존의 한계를 극복하기 위해 재작성된 재조정([[Reconciliation|Reconciliation]]) 엔진입니다 [1, 2]. 이 엔진은 렌더링 과정을 작은 '작은 작업 단위(Unit of work)'로 분할하여 **동시성 렌더링(Concurrent Rendering)**을 구현합니다 [2, 3]. 결과적으로 긴급한 사용자 상호작용(예: 클릭, 타이핑)이 무거운 렌더링 작업에 의해 지연되지 않도록 작업을 일시 중지, 재개, 우선순위 재조정하여 사용자 인터페이스(UI)의 반응성을 극대화합니다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **기존 렌더링의 문제점과 Fiber의 도입:**
|
||||
React 16 이전에는 전체 컴포넌트 트리를 단일 재귀 호출로 처리하는 '스택 재조정자(Stack Reconciler)'를 사용했습니다 [2]. 이 방식은 렌더링이 완료될 때까지 메인 스레드를 차단(synchronous [[Blocking|Blocking]])하여, 큰 규모의 애플리케이션에서는 UI가 사용자의 입력이나 애니메이션에 반응하지 못하는 문제를 발생시켰습니다 [2]. 이를 해결하기 위해 렌더링을 중단 및 재개할 수 있는 Fiber 아키텍처가 도입되었습니다 [1, 2].
|
||||
|
||||
@@ -26,10 +45,64 @@ React의 **Fiber 아키텍처**는 단일 호출로 전체 트리를 동기적
|
||||
- **동시성 기능(Concurrent Features)의 활용:**
|
||||
Fiber의 동시성 렌더링 구조는 [[React 18|React 18]], 19의 `useTransition` 및 `[[useDeferredValue|useDeferredValue]]`와 같은 훅(Hook)을 가능하게 합니다 [12, 13]. 긴급하지 않은 업데이트의 우선순위를 낮춰 처리함으로써 무거운 리스트 필터링이나 데이터 계산 중에도 앱의 반응성을 부드럽게 유지할 수 있습니다 [12, 14].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[가상 DOM과 재조정 (Virtual DOM and Reconciliation)|가상 DOM과 재조정 (Virtual DOM and Reconciliation]], 차선 모델과 작업 우선순위 (Lane Model & Priorities), Time-Slicing, [[React 동시성 훅 (useTransition, useDeferredValue)|React 동시성 훅 (useTransition, useDeferredValue]]
|
||||
- **Projects/Contexts:** [[메인 스레드 차단 문제 해결을 위한 React 16의 Fiber 엔진 교체 및 React 18, 19의 동시성 렌더링 적용 사례|메인 스레드 차단 문제 해결을 위한 React 16의 Fiber 엔진 교체 및 React 18, 19의 동시성 렌더링 적용 사례]]
|
||||
- **Contradictions/Notes:** 소스 전반에 걸쳐 내용이 일치하며 상충되는 의견은 없습니다. 모든 소스는 Fiber 아키텍처가 렌더링을 작은 단계로 분할하고 우선순위를 부여함으로써 메인 스레드의 부하를 줄여 동시성과 반응성을 달성한다는 점을 일관되게 강조합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,18 +1,92 @@
|
||||
---
|
||||
id: wiki-2026-0508-figma-tokens-studio
|
||||
title: Figma Tokens Studio
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Figma Tokens Studio|Figma Tokens Studio]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
[[Figma|Figma]] Tokens Studio(과거 명칭: Figma Tokens)는 디자이너가 색상, 서체, 간격과 같은 디자인 결정(디자인 토큰)을 JSON 형식으로 구조화할 수 있게 해주는 Figma 플러그인입니다 [1]. 이 도구를 활용하면 Figma에서 작업한 토큰을 외부 파일로 내보내어 코드 기반의 디자인 시스템과 동기화할 수 있습니다 [1, 2]. 확장성 있는 UI 시스템에서 디자인과 개발 워크플로우를 연결하여 일관된 테마를 구축하는 데 필수적인 역할을 합니다 [1, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **디자인 토큰의 JSON 구조화 및 추출**: Tokens Studio for Figma는 디자이너가 내린 디자인 결정들을 플랫폼에 구애받지 않는 JSON 데이터로 정의하고 내보낼 수 있도록 지원합니다 [1].
|
||||
* **테마 생성 엔진과의 파이프라인 연동**: 이 플러그인을 통해 내보낸 테마별 JSON 토큰 파일(예: `colors-light.json`, `colors-dark.json`)은 [[Style Dictionary|Style Dictionary]]와 같은 오픈소스 테마 엔진과 결합하여 사용할 수 있습니다 [4, 5]. 이 과정을 통해 React 애플리케이션 등에서 직접 사용할 수 있는 [[JavaScript|JavaScript]]/TypeScript 테마 객체나 CSS 변수로 자동 변환됩니다 [4].
|
||||
* **단일 진실 공급원([[Single_Source_of_Truth|Single Source of Truth]]) 유지**: Tokens Studio와 같은 플러그인을 통해 토큰을 추출하여 공유 리포지토리나 코드베이스로 동기화함으로써, 디자이너와 개발자 간에 동일한 디자인 언어(디자인 토큰)를 공유할 수 있습니다 [2, 3]. 이는 다중 테마, 다크 모드, 여러 브랜드 스타일을 수동 코드 작성 없이 안전하게 확장할 수 있게 해줍니다 [1, 3].
|
||||
* *참고: 소스에 관련 정보가 부족합니다.* (Figma Tokens Studio 플러그인 자체의 구체적인 내부 사용법이나 세부 기능에 대한 구체적인 설명은 소스에 포함되어 있지 않으며, 주로 Style Dictionary를 활용한 JSON 토큰 추출 파이프라인의 일부로만 언급됩니다 [1, 2].)
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Design Tokens|Design Tokens]], Style Dictionary, CSS Variables, [[Dynamic Theming|Dynamic Theming]]
|
||||
- **Projects/Contexts:** Scalable UISystems, Design-to-Code Workflow
|
||||
- **Contradictions/Notes:** 소스 데이터는 Figma Tokens Studio의 작동 원리나 전체 기능에 대해 깊이 다루지 않습니다. 단지 디자이너가 만든 토큰을 코드로 가져오기 위해 JSON 형태로 내보내는 도구(플러그인)로써의 역할에만 초점을 맞추고 있으므로, 소스에 관련 정보가 부족합니다 [1, 2].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 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,25 @@
|
||||
---
|
||||
id: wiki-20260508-fluid-typography-redir
|
||||
title: Fluid Typography
|
||||
category: Frontend
|
||||
status: merged
|
||||
redirect_to: Fluid_Typography
|
||||
canonical_id: Fluid_Typography
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# Fluid Typography
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[Fluid_Typography]]**로 통합되었습니다.
|
||||
|
||||
---
|
||||
*Redirected to: [[Fluid_Typography]]*
|
||||
@@ -1,6 +1,26 @@
|
||||
---
|
||||
id: wiki-2026-0508-folder-structure-best-practices
|
||||
title: Folder Structure Best Practices
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Folder Structure Best Practices|Folder Structure Best Practices]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
React 등 프론트엔드 프로젝트에서 코드의 유지보수성, 확장성, 그리고 협업 효율성을 높이기 위해 파일과 디렉터리를 체계적으로 구성하는 방법론입니다 [1]. 현대적인 애플리케이션에서는 과거의 파일 유형 기반(유형별 분류) 구조에서 벗어나, 기능(Feature)이나 도메인 중심으로 관련된 로직을 묶는 하이브리드 또는 기능 기반 방식이 모범 사례로 권장됩니다 [2, 3]. 이를 통해 UI, 비즈니스 로직, 상태 관리 등의 관심사를 명확히 분리하고 프로젝트가 커짐에 따라 발생하는 기술 부채를 최소화할 수 있습니다 [4].
|
||||
|
||||
## 📖 Core 소스 Content
|
||||
@@ -30,8 +50,7 @@ React 등 프론트엔드 프로젝트에서 코드의 유지보수성, 확장
|
||||
* **Next.js 환경에서의 라우트 그룹 (Route Groups):**
|
||||
* Next.js 프로젝트에서는 괄호를 사용한 폴더명 `(folderName)` 방식을 통해, 실제 URL 경로에는 영향을 주지 않으면서도 관련 기능이나 논리에 따라 라우트를 깔끔하게 그룹화할 수 있습니다 [25-27].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
- [[Feature-Sliced Design|Feature-Sliced Design]]
|
||||
- 연결 이유: 대규모 React 애플리케이션의 폴더 구조를 구축하기 위해 고안된 전문적인 프론트엔드 아키텍처 방법론이기 때문입니다 [21].
|
||||
@@ -66,4 +85,66 @@ React 등 프론트엔드 프로젝트에서 코드의 유지보수성, 확장
|
||||
- 확장 방향: 라우트 혹은 폴더(Feature) 단위로 코드 스플리팅과 지연 로딩(Lazy Loading)을 적용하여 초기 번들 크기를 줄이고 성능을 최적화하는 전략과 연결됩니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-30*
|
||||
*Last updated: 2026-04-30*
|
||||
|
||||
## 📖 구조화된 지식 (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,110 @@
|
||||
---
|
||||
id: wiki-2026-0508-frontend-architecture
|
||||
title: Frontend Architecture
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
프론트엔드 아키텍처는 현대 웹 애플리케이션의 복잡성을 관리하고 지속 가능한 유지보수성과 확장성을 확보하기 위한 구조적 설계 기반이다. 단순한 UI 렌더링을 넘어 비즈니스 로직과 UI의 분리, 엄격한 의존성 관리, 그리고 기능(Feature) 기반의 모듈화를 통해 견고한 소프트웨어 시스템을 구축하는 것을 목표로 한다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
1. **기능 기반 설계 및 FSD (Feature-Sliced Design)**
|
||||
- 기술적 타입(컴포넌트, 훅 등)이 아닌 비즈니스 기능(도메인) 중심으로 코드를 구성하여 응집도를 높인다.
|
||||
- FSD 아키텍처를 통해 계층(Layer) 간 단방향 의존성을 강제하고, 모듈 간의 순환 참조와 아키텍처 붕괴를 원천적으로 방지한다.
|
||||
2. **소프트웨어 공학 원칙의 적용**
|
||||
- **SOLID**: 단일 책임 원칙(SRP)으로 컴포넌트를 세분화하고, 컴포넌트 합성(Composition)으로 개방-폐쇄 원칙(OCP)을 준수한다.
|
||||
- **KISS, DRY, YAGNI**: 코드를 단순하게 유지하고 불필요한 추상화와 오버엔지니어링을 경계하여 실용적인 코드베이스를 유지한다.
|
||||
3. **계층화된 상태 관리**
|
||||
- 상태의 성격에 따라 로컬(React State), 글로벌 앱 상태(Zustand), 서버 캐시 상태(TanStack Query)로 레이어를 분리하여 리렌더링 성능과 데이터 동기화 효율을 최적화한다.
|
||||
4. **성능 및 회복성 설계**
|
||||
- Vite 기반의 코드 스플리팅과 지연 로딩을 통해 번들 크기를 최적화하고, Error Boundary를 배치하여 특정 모듈의 오류가 시스템 전체로 전파되는 것을 차단한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **설계 오버헤드**: 엄격한 아키텍처(FSD 등) 도입 시 초기 폴더 구성과 계층 분리에 따른 인지적 부하 및 파일 수 증가가 발생할 수 있다.
|
||||
- **추상화의 양날의 검**: DRY 원칙을 무리하게 적용하여 지나치게 추상화된 공통 로직은 오히려 코드 독해를 방해하고 변경에 취약하게 만들 수 있다(KISS 원칙과의 충돌).
|
||||
- **기술 부채의 점진적 해결**: 기존의 모놀리식 구조에서 기능 기반 아키텍처로 전환할 때, 과도한 빅뱅 방식의 리팩토링보다는 점진적 마이그레이션 전략이 권장된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
- **Feature-Sliced Design**: 프론트엔드 모듈화의 최신 표준 방법론 (관계: 핵심 아키텍처 모델)
|
||||
- **State Management**: 데이터 흐름의 중앙 통제 및 최적화 (관계: 데이터 레이어 설계)
|
||||
- **SOLID Principles**: 객체 지향 및 컴포넌트 설계의 근간 (관계: 코드 품질 기준)
|
||||
|
||||
### Deeper Research Questions
|
||||
1. FSD의 'Widgets' 계층과 'Features' 계층 사이의 책임 분배를 결정하는 가장 명확한 기준은 무엇인가?
|
||||
2. 마이크로 프론트엔드 전환 시, 중앙 집중식 상태 관리 라이브러리와 서비스별 격리된 상태 관리 중 어떤 것이 유리한가?
|
||||
3. 컴포넌트 합성(Composition) 패턴이 개방-폐쇄 원칙(OCP)을 프론트엔드 환경에서 어떻게 물리적으로 구현하는가?
|
||||
4. 서버 사이드 데이터(RSC) 비중이 늘어날 때, 클라이언트 아키텍처의 상태 관리 레이어는 어떻게 간소화되어야 하는가?
|
||||
5. 아키텍처의 단방향 의존성 규칙을 정적 분석 도구(ESLint plugin-import 등)를 통해 자동화하여 강제하는 방안은?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **대규모 앱 리팩토링**: 흩어져 있는 비즈니스 로직을 기능별 폴더로 캡슐화하여 유지보수성 확보.
|
||||
- **신규 프로젝트 설계**: 초기 아키텍처 수립 단계에서 상태 레이어와 오류 처리 전략 정의.
|
||||
|
||||
### Adjacent Topics
|
||||
- **Micro-Frontends**
|
||||
- **Server Components (RSC)**
|
||||
- **Test-Driven Development (TDD) in Frontend**
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: FE-ARCH-STRUCT-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-frontend-architecture-and-folder
|
||||
title: Frontend Architecture and Folder Structure
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [FE-ARCH-STRUCT-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [[Frontend|[Frontend]], [[Architecture|Architecture]], folder-structure, [[Scalability|Scalability]], [[Modularity|Modularity]], atomic-design, clean-architecture]
|
||||
tags: ["Frontend|[Frontend", Architecture, folder-structure, Scalability, Modularity, atomic-design, clean-architecture]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Frontend Architecture and Folder Structure (프런트엔드 아키텍처 및 폴더 구조)
|
||||
@@ -21,10 +33,59 @@ last_reinforced: 2026-04-26
|
||||
- **`/src/assets` & `/src/styles`:** 이미지, 폰트 및 전역 CSS 설정.
|
||||
- **의의:** 의존성 방향을 명확히 하여 코드 변경의 파급 효과를 제한하고, 새로운 팀원이 프로젝트에 빠르게 적응할 수 있는 높은 관측성을 제공함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 과거에는 `components`, `containers`, `actions`, `reducers` 등 기술적 계층으로 폴더를 나누었으나(Layered Architecture), 현대 정책은 관련 있는 기능을 한곳에 모으는 '도메인/피처 중심 정책'으로 전환됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 저장소에 대해 'Feature-first' 폴더 구조를 강제하며, 각 피처 폴더 밖으로 유출되는 의존성은 엄격히 검토되는 'Strict Encapsulation' 정책을 고수함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Scalable-[[Frontend-Architecture|Frontend-Architecture]], Atomic-Styling-and-[[Design Systems|Design-Systems]], [[Clean-Code-Principles|Clean-Code-Principles]], Modular-Monolith
|
||||
- **Raw Source:** 00_Raw/Frontend Folder Structure.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,8 +1,21 @@
|
||||
---
|
||||
category: Unified
|
||||
id: wiki-2026-0508-frontend
|
||||
title: Frontend
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [category-index, frontend]
|
||||
title: Frontend Directory
|
||||
last_updated: 2026-05-02
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Frontend Directory
|
||||
@@ -355,4 +368,80 @@ last_updated: 2026-05-02
|
||||
- [[프론트엔드 애플리케이션 렌더링 병목 개선]] : [[프론트엔드 애플리케이션 렌더링 병목 개선|프론트엔드 애플리케이션 렌더링 병목 개선]]
|
||||
- [[프론트엔드 컴포넌트 구조화]] : [[프론트엔드 컴포넌트 구조화|프론트엔드 컴포넌트 구조화]]
|
||||
- [[프론트엔드 컴포넌트 설계]] : [[프론트엔드 컴포넌트 설계|프론트엔드 컴포넌트 설계]]
|
||||
- [[힙 스냅샷 (Heap Snapshots)]] : [[힙 스냅샷 (Heap Snapshots)|힙 스냅샷 (Heap Snapshots]]
|
||||
- [[힙 스냅샷 (Heap Snapshots)]] : [[힙 스냅샷 (Heap Snapshots)|힙 스냅샷 (Heap Snapshots]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> 프런트엔드는 사용자 인터페이스 계층으로, HTML/CSS/JS의 토대 위에 컴포넌트 모델·상태 관리·메타 프레임워크가 쌓인 구조다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:** UI 라이브러리(React/Vue/Svelte) + 메타 프레임워크(Next/Nuxt/SvelteKit) + 도구체인 + 디자인 시스템의 4계층.
|
||||
|
||||
**세부 내용:**
|
||||
- 라이브러리: React/Vue/Svelte/Solid.
|
||||
- 메타: Next.js/Nuxt/SvelteKit.
|
||||
- 빌드: Vite, Turbopack, Webpack.
|
||||
- 상태: Redux, Zustand, Tanstack Query.
|
||||
- 스타일: Tailwind, CSS-in-JS, vanilla CSS.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: FP-TS-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-functional-programming-in-typesc
|
||||
title: Functional Programming in TypeScript
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [FP-TS-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [typescript, [[Functional-Programming|Functional-Programming]], immutability, pure-functions]
|
||||
tags: [typescript, Functional-Programming, immutability, pure-functions]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Functional Programming|Functional Programming]] in TypeScript (함수형 프로그래밍)
|
||||
@@ -20,7 +32,7 @@ last_reinforced: 2026-04-26
|
||||
- **Type Safety:** TypeScript의 강력한 제네릭과 [[readonly|readonly]] 타입을 활용하여 컴파일 타임에 불변성을 강제.
|
||||
- **Declarative Code:** '어떻게(How)'가 아닌 '무엇(What)'을 할 것인지 기술하여 코드의 의도를 명확히 함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 성능상의 이유로 가변 객체를 선호하던 과거와 달리, 현대의 JS 엔진 최적화와 메모리 관리 능력 향상으로 불변 객체 사용이 성능과 안정성 사이의 최적의 타협점이 됨.
|
||||
- **정책 변화:** Antigravity 프로젝트의 핵심 비즈니스 로직은 함수형 패러다임을 따라 작성하며, 상태 관리는 Redux나 Zustand와 같은 불변성 지향 라이브러리를 사용함.
|
||||
|
||||
@@ -28,3 +40,52 @@ last_reinforced: 2026-04-26
|
||||
- **Parent:** 10_Wiki/💡 Topics/AI
|
||||
- **Related:** Immutability, Pure-Functions, Monad, [[Reactive-Programming|Reactive-Programming]]
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Functional-Programming-in-TypeScript.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-4AA291
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-gpu-resources
|
||||
title: GPU Resources
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-4AA291]
|
||||
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 - GPU Resources"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[GPU Resources|GPU Resources]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - GPU Resources"
|
||||
- **특수 텍스처 및 빈번한 생성 객체 관리:** GLTF 모델 파일에서 `ImageBitmap` 형태로 로드된 텍스처 리소스의 경우, 기본 폐기 메서드 외에도 명시적으로 `texture.source.data.close?()`를 호출해 닫아주어야만 메모리가 새는 것을 막을 수 있습니다 [4, 7]. 또한 게임 내 탄환이나 파티클처럼 자주 생성되고 파괴되는 리소스의 경우 매번 새로 할당하지 않고 오브젝트 풀링(Object [[Pooling|Pooling]]) 방식을 사용하여 메모리 할당 오버헤드를 막는 것이 좋습니다 [4, 7].
|
||||
- **리소스 한계 모니터링:** WebGL 컨텍스트의 가용 메모리 한도는 디바이스 환경에 따라 약 256MB에서 1GB 수준으로 제한적입니다 [3]. 이 용량을 초과해 GPU 리소스가 할당되면 컨텍스트 손실이 발생하여 애플리케이션이 충돌하게 됩니다 [3]. 이를 방지하기 위해서는 런타임 중에 `renderer.info.[[memory|memory]]` 상태를 꾸준히 모니터링하여 텍스처나 지오메트리 수가 지속적으로 증가하는 메모리 누수 현상이 없는지 확인해야 합니다 [1, 4].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - GPU Resources"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
id: wiki-2026-0508-gpu-가속-및-컴포지팅
|
||||
title: GPU 가속 및 컴포지팅
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[GPU 가속 및 컴포지팅]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
GPU 가속 및 컴포지팅은 브라우저의 메인 스레드에서 처리하던 애니메이션 작업을 기기의 GPU(그래픽 처리 장치)로 위임하여 웹 성능을 크게 향상시키는 기술입니다 [1]. 이 기법을 사용하면 비용이 많이 드는 브라우저의 레이아웃(Reflow) 및 페인트(Repaint) 단계를 건너뛰고, 오직 컴포지트(Composite) 단계만을 실행하여 렌더링 부담을 줄일 수 있습니다 [2]. 특히 모바일 기기나 저사양 환경에서도 초당 60프레임(60 FPS)의 매끄러운 애니메이션을 달성하는 데 핵심적인 역할을 합니다 [2-4].
|
||||
|
||||
## 📖 Core 단락
|
||||
* **픽셀 파이프라인과 컴포지트 단계:** DOM 요소가 변경될 때 브라우저는 '스타일 재계산 -> 레이아웃(Reflow) -> 페인트(Repaint) -> 컴포지트(Composite)'로 이어지는 픽셀 파이프라인을 실행합니다 [5]. 애니메이션 성능을 극한으로 끌어올리기 위해서는 전체 파이프라인을 다시 거치지 않고, 마지막 컴포지트 단계만을 유발하는 속성을 사용하는 것이 중요합니다 [2].
|
||||
* **GPU 가속을 유발하는 속성:** 브라우저가 특정 애니메이션을 자동으로 GPU로 보내도록 만들 수 있습니다 [1]. 대표적으로 `transform`과 `opacity` 속성이 이를 지원하며, 리플로우나 리페인트 없이 GPU 가속을 통해 애니메이션을 처리합니다 [2, 6, 7]. 추가로 `transform: translateZ()`나 `rotate3d()` 같은 3D 변환, `position: fixed`, 그리고 `will-change` 속성이 적용된 요소나 `<video>`, `<canvas>`, `<iframe>` 요소 등도 자체적인 레이어에서 렌더링되어 컴포지팅의 이점을 얻습니다 [3].
|
||||
* **사용 시 주의사항:** 모든 속성이 가속을 통해 이점을 얻는 것은 아닙니다. `box-shadow`, `filter`, `border-radius`와 같은 속성들은 애니메이션 시 컴포지팅 레이어나 블렌딩 과정에서 추가적인 리소스를 요구하여 오히려 애니메이션을 느리게 만들 수 있습니다 [6]. 또한 `will-change` 속성은 브라우저가 변경 사항을 미리 최적화하도록 돕지만, 너무 많은 요소에 남용할 경우 도리어 성능을 저하시킬 수 있습니다 [8].
|
||||
* **성능 프로파일링 및 디버깅:** CSS 애니메이션이 올바르게 최적화되었는지 확인하려면 [[Chrome DevTools]]를 활용할 수 있습니다. 특히 Layer Profiler를 사용하면 어떤 요소가 복합 레이어(Composite layer)에서 렌더링되고 있는지 식별하여 성능 병목 현상을 파악할 수 있습니다 [9].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** CSS 애니메이션 성능 최적화, Reflow와 Repaint (리플로우와 리페인트), transform 및 opacity 속성, will-change 속성
|
||||
- **Projects/Contexts:** 모바일 우선 및 저사양 기기를 고려한 웹 성능 최적화, 60 FPS의 부드러운 상호작용 및 애니메이션 구현
|
||||
- **Contradictions/Notes:** 컴포지팅은 애니메이션 성능 최적화의 핵심이지만, `box-shadow`나 `filter` 등의 속성을 포함한 애니메이션은 무거운 렌더링 과정을 유발해 오히려 성능 저하를 초래할 수 있으므로 주의해야 합니다 [6].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-035B08
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-gpu-webgl-파이프라인의-미세-지연-micro-lat
|
||||
title: GPU WebGL 파이프라인의 미세 지연(Micro latency) 측정 사례
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-035B08]
|
||||
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 - GPU_[[WebGL|WebGL]] 파이프라인의 미세 지연(Micro-latency) 측정 사례"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례|GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례]]
|
||||
@@ -33,7 +44,7 @@ github_commit: "[P-Reinforce] Continuous Worker - GPU_[[WebGL|WebGL]] 파이프
|
||||
* **[[JavaScript|JavaScript]] 우회 측정 방법**
|
||||
* 일부 브라우저(예: Chrome)에서는 성능 및 구조상의 이유로 `gl.finish()`가 비정상적으로 `gl.flush()`로 작동하기 때문에 렌더링 지연을 직접 측정할 수 없습니다 [11]. 이를 우회하기 위해 `gl.readPixels()`를 사용하여 단일 픽셀을 강제로 읽어 모든 그래픽 프로세스를 지연시키고 동기화한 뒤, 그 오버헤드를 `performance.now()`로 측정 및 차감하여 실제 작업의 렌더링 시간을 추정하는 기법이 활용되기도 합니다 [25, 26].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -46,3 +57,52 @@ github_commit: "[P-Reinforce] Continuous Worker - GPU_[[WebGL|WebGL]] 파이프
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-A2356F
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-google-chrome
|
||||
title: Google Chrome
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-A2356F]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Google [[Chrome|Chrome]]"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Google Chrome|Google Chrome]]
|
||||
@@ -25,7 +36,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Google [[Chrome|Chrome]]"
|
||||
- **렌더러 충돌(Crash)과 포렌식 활용**
|
||||
Chrome 브라우저에서 복잡한 익스플로잇 시도가 실패할 경우 렌더러 프로세스 충돌(Crash)이 발생하게 됩니다 [22]. 이러한 충돌 덤프 데이터에는 공격자가 V8 힙에 남긴 가짜 객체(fakeobj), 손상된 배열 길이, 원시 데이터 메모리 흔적 등이 포함되며, 이를 통해 아직 알려지지 않은 제로데이 공격 시도 등을 포렌식 관점에서 사전에 감지하고 식별할 수 있습니다 [23, 24].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -38,3 +49,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Google [[Chrome|Chrome]]"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-GQCG-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-graphql-code-generator
|
||||
title: GraphQL Code Generator
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-GQCG-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, graphql, code-generator, typescript, type-safety, [[Schema|Schema]], automation, api-development]
|
||||
tags: [auto-reinforced, graphql, code-generator, typescript, type-safety, Schema, automation, api-development]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[GraphQL-Code-Generator|GraphQL-Code-Generator]]
|
||||
@@ -21,7 +33,7 @@ GraphQL 코드 제너레이터(GraphQL-Code-Generator)는 GraphQL 스키마와
|
||||
2. **왜 중요한가?**:
|
||||
* API 변경 시 클라이언트 코드가 즉시 컴파일 에러를 띄우므로, 런타임 장애 정책을 사전에 완벽히 차단하기 때문임. ([[Reliability|Reliability]]와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 `any` 타입을 쓰거나 수동으로 인터페이스 정책을 맞췄으나, 현대 정책은 'Schema-first' 또는 'Code-first' 방식 정책을 통해 타입 정책을 100% 자동 생성 정책하는 것이 표준임(RL Update). ([[Distributed-System-Type-Safety|Distributed-System-Type-Safety]]와 연결)
|
||||
- **정책 변화(RL Update)**: 이제는 단순 타입 생성 정책을 넘어, 스키마 정보를 활용하여 목업 데이터(Mocking) 정책이나 유효성 검사 로직(Zod) 정책까지 자동으로 생성해 주는 풀스택 개발 가속기로 진화함.
|
||||
|
||||
@@ -29,3 +41,52 @@ GraphQL 코드 제너레이터(GraphQL-Code-Generator)는 GraphQL 스키마와
|
||||
- [[Efficiency|Efficiency]], [[Reliability|Reliability]], [[Distributed-System-Type-Safety|Distributed-System-Type-Safety]], [[Technical-Architecture|Technical-Architecture]], Standard-Operating-Procedure, Automation
|
||||
- **Key Ecosystem**: The Guild (Creators).
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-GGXR-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-guilty-gear-xrd-rendering-pipeli
|
||||
title: Guilty Gear Xrd Rendering Pipeline
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-GGXR-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, guilty-gear, rendering, anime-style, cel-shading, real-time-graphics, unreal-engine]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Guilty-Gear-Xrd-Rendering-Pipeline|Guilty-Gear-Xrd-Rendering-Pipeline]]
|
||||
@@ -21,7 +33,7 @@ last_reinforced: 2026-04-20
|
||||
2. **왜 중요한가?**:
|
||||
* 3D의 자유로운 카메라 연출력과 2D의 예술적 미학 정책을 결합하여 '대체 불가능한 시각적 경험 정책'을 완성했기 때문임. (UX-Design-and-Engagement와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거 셀 쉐이딩(Cel-shading) 정책은 외곽선만 그리면 된다는 단순한 수준이었으나, 길티기어 정책은 조명 모델 정책 자체를 2D 표현 정책에 맞게 재정의한 '차세대 스타일라이즈드 렌더링 정책'의 기준을 세움(RL Update).
|
||||
- **정책 변화(RL Update)**: 이제는 길티기어 스트라이브(Strive)를 거치며 더 발전된 후처리 효과 정책(Bloom, DoF)과 결합되었으며, AI 가 이 화풍 정책을 학습하여 실시간으로 3D 영상을 애니메이션화하는 연구의 벤치마크가 됨.
|
||||
|
||||
@@ -29,3 +41,52 @@ last_reinforced: 2026-04-20
|
||||
- [[Refinement|Refinement]], UX-Design-and-Engagement, [[Deep-Convolutional-GANs|Deep-Convolutional-GANs]], Animation, Simulation, Creative-Process
|
||||
- **Key Developer**: Junya Motomura.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,28 +1,39 @@
|
||||
---
|
||||
category: Frontend
|
||||
tags: [auto-wikified, technical-documentation, frontend]
|
||||
id: wiki-2026-0508-hermes
|
||||
title: Hermes
|
||||
description: "Hermes는 React Native에서 로직을 실행하기 위해 사용하는 고도로 최적화된 자바스크립트 엔진이다 [1-3]."
|
||||
last_updated: 2026-05-04
|
||||
category: Frontend
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-wikified, technical-documentation, frontend]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Hermes
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Hermes는 React Native에서 로직을 실행하기 위해 사용하는 고도로 최적화된 자바스크립트 엔진이다 [1-3]. React Native 애플리케이션이 실행될 때 자바스크립트 번들을 파싱하고 구동하는 핵심 역할을 담당한다 [2, 3]. JSI(JavaScript Interface)와 같은 React Native의 새로운 아키텍처와 결합하여 모바일 애플리케이션의 전반적인 실행 성능과 런타임 효율성에 직접적인 영향을 미친다 [1].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **자바스크립트 실행 및 로직 처리**: Hermes는 React Native 프레임워크 내에서 자바스크립트 코드를 실행하는 기반 엔진이다 [3]. 모든 React Native 앱은 애플리케이션 로직 구동을 위해 이 엔진과 함께 배포된다 [2, 4].
|
||||
* **새로운 아키텍처와의 통합**: React Native의 렌더링 및 통신 방식을 혁신한 JSI(JavaScript Interface)는 고도로 최적화된 Hermes를 비롯한 다양한 자바스크립트 엔진을 지원한다 [1]. 이를 기반으로 자바스크립트와 네이티브 코드 간의 직접적이고 동기적인 바인딩이 가능해진다 [1].
|
||||
* **앱 용량(App Size)에 미치는 영향**: Hermes 자바스크립트 엔진을 포함하여 빌드 및 배포되는 React Native 앱은 대략 5~8 MB 수준의 기본(baseline) APK 크기를 가진다 [2, 4].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
**초기 시작 지연(Startup Latency) 및 콜드 스타트 문제**
|
||||
React Native 앱은 시작할 때 반드시 Hermes 자바스크립트 엔진을 초기화하고 JS 번들을 파싱하는 과정을 거쳐야 하며, 이는 측정 가능한 수준의 시작 지연(Startup latency)을 추가로 발생시킨다 [2].
|
||||
결과적으로 네이티브 ARM 코드로 미리 컴파일(AOT)하는 Flutter 앱의 콜드 스타트 시간(일반적으로 200~400ms)과 비교했을 때, Hermes를 사용하는 React Native 앱의 콜드 스타트 시간은 보통 300~600ms로 상대적으로 더 느리다 [2, 4]. 이러한 지연은 성능 벤치마크 상에서는 눈에 띄는 차이지만, 실제 대부분의 앱 사용자에게는 결정적인 방해 요소가 되지는 않는다 [2].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/기반 기술)]
|
||||
@@ -59,4 +70,53 @@ React Native 앱은 시작할 때 반드시 Hermes 자바스크립트 엔진을
|
||||
- 확장 방향: 렌더링 엔진(Skia, Impeller)을 사용하는 Flutter와 자바스크립트 엔진(Hermes)을 사용하는 React Native의 철학적, 아키텍처적 접근 방식을 폭넓게 비교 연구할 수 있다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-03*
|
||||
*Last updated: 2026-05-03*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-1F4D68
|
||||
category: "10_Wiki/💡 Topics/Web Development"
|
||||
id: wiki-2026-0508-hydration-progressive-rendering
|
||||
title: "Hydration & Progressive Rendering"
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-1F4D68]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-03
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Hydration & Progressive Rendering"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Hydration & Progressive Rendering|Hydration & Progressive Rendering]]
|
||||
@@ -13,7 +24,6 @@ github_commit: "[P-Reinforce] Continuous Worker - Hydration & Progressive Render
|
||||
하이드레이션(Hydration)은 서버 사이드 렌더링(SSR)을 통해 생성된 정적 HTML을 클라이언트가 넘겨받아 이벤트 리스너를 연결하고 동적 상호작용이 가능하도록 '수분'을 공급하는 과정입니다 [1, 2]. 기존 SSR은 초기 화면은 빠르게 보여주지만 전체 자바스크립트를 다운로드하고 하이드레이션을 마칠 때까지 상호작용이 지연되는 '하이드레이션 갭(Hydration Gap)' 문제를 안고 있었습니다 [1, 3]. 이를 해결하기 위해 React 18의 선택적 하이드레이션(Selective Hydration) 및 스트리밍(Streaming) 렌더링, Vue 3.5의 지연 하이드레이션(Lazy Hydration)과 같은 점진적 렌더링 기법이 도입되어, 대규모 애플리케이션의 초기 로딩 성능과 사용자 경험을 최적화하는 핵심 실전 패턴으로 자리 잡았습니다 [4, 5].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
* **하이드레이션의 작동 원리 및 한계**
|
||||
* 서버 렌더링 환경에서 React는 기존 서버에서 렌더링된 DOM 트리를 병렬로 순회하며 Fiber 트리와 일치시키고, DOM 노드를 다시 생성하는 대신 재사용하며 이벤트 리스너를 부착합니다 [1, 6].
|
||||
* 그러나 전통적인 하이드레이션은 트리를 순차적으로 걷기 때문에, 전체 트리가 하이드레이션되기 전까지는 버튼 클릭과 같은 사용자 상호작용이 동작하지 않는 '먹통' 현상(Hydration Gap)을 유발합니다 [1, 6].
|
||||
@@ -29,14 +39,12 @@ github_commit: "[P-Reinforce] Continuous Worker - Hydration & Progressive Render
|
||||
* **하이드레이션의 완전한 생략: 서버 컴포넌트(RSC)**
|
||||
* React 서버 컴포넌트(RSC)는 서버에서만 실행되며 코드가 클라이언트 번들에 포함되지 않으므로 하이드레이션 자체가 발생하지 않습니다 [9, 10]. 이는 자바스크립트 번들 크기를 줄이고 하이드레이션 비용을 원천적으로 없애는 아키텍처적 진화입니다 [11].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **두 번의 왕복 문제(The Two-Trip Lie):** 전통적 하이드레이션은 SSR을 통해 빠른 HTML을 제공하지만, 브라우저는 여전히 모든 JavaScript를 다운로드하고 클라이언트에서 코드를 다시 실행해야 합니다. 즉, 서버에서의 작업이 클라이언트의 연산 비용을 줄여주지 못하는 근본적 한계가 있습니다 [3, 12].
|
||||
* **하이드레이션 불일치(Hydration Mismatches):** 서버에서 렌더링된 콘텐츠와 클라이언트에서 렌더링된 콘텐츠가 다를 경우 오류가 발생합니다. 이를 위해 Vue 3.5는 서버-클라이언트 간 일관된 고유 ID를 보장하는 `useId()` API를 도입하였고, 의도적인 불일치에 대한 경고를 억제하기 위해 `data-allow-mismatch` 속성을 사용해야 하는 관리 포인트가 생깁니다 [5, 13].
|
||||
* **아키텍처 복잡성과 보안 위험:** 하이드레이션을 생략하기 위해 서버 컴포넌트(RSC) 패턴을 사용할 경우, 서버와 클라이언트 경계가 모호해져 아키텍처가 매우 복잡해집니다 [14, 15]. 특히 서버 액션을 내부 함수처럼 취급하여 입력 유효성 검사를 생략하면, 인증 없이 원격 코드 실행(RCE)이 가능한 'React2Shell'과 같은 치명적인 보안 취약점이 발생할 수 있습니다 [16-18].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/기반 기술)]
|
||||
@@ -84,3 +92,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Hydration & Progressive Render
|
||||
*Last updated: 2026-05-03*
|
||||
- Raw Source: 00_Raw/2026-05-03/Hydration & Progressive Rendering.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,108 @@
|
||||
---
|
||||
id: wiki-2026-0508-hydration-성능-최적화
|
||||
title: Hydration 성능 최적화
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Hydration 성능 최적화]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
[[Hydration]]은 서버에서 렌더링된 정적 HTML 뼈대에 [[JavaScript]]를 실행하고 이벤트 리스너를 연결하여 완전한 상호작용이 가능한 애플리케이션으로 변환하는 과정입니다 [1, 2]. 기본적으로 React는 페이지 전체를 한 번에 Hydration하면서 메인 스레드를 차단하여 TBT(Total [[Blocking]] Time)와 TTI(Time to Interactive) 지표를 악화시킬 수 있습니다 [3]. 이를 해결하기 위해 선택적 Hydration, 지연 로딩, [[React Server Components]](RSC) 등의 최적화 기법을 도입하여 초기 로드 성능과 상호작용성을 극대화할 수 있습니다 [4-6].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **Hydration의 개념 및 주요 성능 병목 현상:**
|
||||
* Hydration은 SSR(Server-Side Rendering) 환경에서 서버가 생성한 HTML을 클라이언트가 넘겨받아 상호작용을 부여하는 필수적인 과정입니다 [2, 3].
|
||||
* 문제는 React가 기본적으로 시야에 보이지 않는 컴포넌트까지 포함하여 페이지 전체를 한 번에 Hydration 하려 한다는 점입니다 [3]. 이로 인해 JavaScript 실행이 메인 스레드를 장시간 점유하게 되고, 결과적으로 TBT(Total Blocking Time), FID(First Input Delay), TTI(Time to Interactive) 등의 핵심 웹 성능 지표가 크게 저하되며 사용자의 입력 지연을 초래합니다 [3, 7].
|
||||
* 또한 서버에서 렌더링된 HTML과 클라이언트의 렌더링 결과가 다를 때 발생하는 'Hydration Mismatch' 오류와, 모든 컴포넌트를 위한 전체 JavaScript를 다운로드해야 해서 발생하는 번들 크기 비대화(Bundle Size Bloat) 문제도 겪을 수 있습니다 [4, 8].
|
||||
|
||||
* **점진적 및 선택적 Hydration (Selective & Progressive Hydration):**
|
||||
* 페이지 전체를 일괄 처리하는 대신 스크롤 위쪽(Above-the-fold)의 중요한 콘텐츠를 우선 처리하고, 덜 중요한 컴포넌트는 Hydration을 지연시킵니다 [4].
|
||||
* [[Next.js]] 환경에서는 `next/dynamic`을 활용한 동적 임포트(Dynamic Imports)를 통해 구현하거나, IntersectionObserver API를 사용하여 요소가 뷰포트에 들어올 때만 Hydration을 수행하는 지연(Lazy) 방식을 적용할 수 있습니다 [5, 9]. 이를 통해 메인 스레드 차단을 분산시켜 TBT를 최대 40%까지 줄일 수 있습니다 [5].
|
||||
|
||||
* **[[React [[Server Components]] (RSC)]]의 활용:**
|
||||
* [[Next.js App Router]] 등에서 지원하는 React Server Components는 오직 서버에서만 실행되며 클라이언트로 JavaScript 페이로드를 전혀 보내지 않습니다 [5, 10, 11].
|
||||
* 정적이거나 상호작용이 필요 없는 UI(예: 텍스트, 사이드바 등)를 RSC로 구성하면 해당 영역은 Hydration 프로세스 자체가 필요 없어지므로 클라이언트의 부담과 번들 크기가 비약적으로 감소합니다 [6, 12, 13].
|
||||
|
||||
* **Streaming 및 Suspense 적용:**
|
||||
* React의 Suspense API를 활용하면 서버에서 HTML을 점진적으로 스트리밍(Streaming)할 수 있습니다 [6].
|
||||
* 이를 통해 렌더링이 완료된 일부 화면을 사용자에게 더 빠르게 보여주면서(FCP 개선), 복잡한 부분에 대한 Hydration 작업은 나중으로 미루어 체감 성능을 향상시킬 수 있습니다 [6, 14]. [[React 18]]의 동시성 렌더링([[Concurrent Rendering]])은 Hydration 작업을 작은 청크로 쪼개어 브라우저가 사용자 입력을 처리할 수 있도록 양보(yield)하는 기능을 제공합니다 [15].
|
||||
|
||||
* **부분 Hydration (Partial Hydration) 및 기타 팁:**
|
||||
* 정적인 콘텐츠 영역을 고립시키고 상호작용이 필요한 특정 부분만 Hydration하는 섬 아키텍처([[Island Architecture]])를 도입하거나, 절대적으로 정적인 콘텐츠의 경우 `dangerouslySetInnerHTML`을 사용하여 통째로 Hydration 과정에서 배제하는 것도 유용한 전략입니다 [16-18].
|
||||
* 불가피하게 클라이언트와 서버 간의 렌더링 불일치가 예상되는 곳에는 `suppressHydrationWarning`을 제한적으로 사용하거나, Hydration 완료 이후에 동작해야 하는 로직을 의존성 배열이 빈 `useEffect` 내에 배치하여 불일치 에러를 방지할 수 있습니다 [17, 19].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Server-Side Rendering (SSR)]], [[React Server Components (RSC)]], [[Total Blocking Time (TBT)]], [[Concurrent Rendering]]
|
||||
- **Projects/Contexts:** [[Next.js App Router]], [[Island Architecture]]
|
||||
- **Contradictions/Notes:** SSR은 클라이언트에게 완성된 HTML을 즉시 제공하여 FCP(First Contentful Paint)와 SEO를 크게 향상시키지만, JavaScript 번들이 다운로드되고 Hydration이 완료될 때까지 사용자가 페이지와 상호작용할 수 없으므로 TTI(Time to Interactive)가 오히려 지연되는 성능적 트레이드오프(Trade-off)가 존재합니다 [20, 21].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: FE-SSR-HYDRA-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-hydration-mismatch-and-ssr-debug
|
||||
title: Hydration Mismatch and SSR Debugging
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [FE-SSR-HYDRA-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [react, ssr, [[Hydration|Hydration]], hydration-mismatch, debugging, [[Frontend|Frontend]]-performance, nextjs]
|
||||
tags: [react, ssr, Hydration, hydration-mismatch, debugging, Frontend-performance, nextjs]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Hydration Mismatch and SSR Debugging (수화 불일치 및 SSR 디버깅)
|
||||
@@ -23,10 +35,59 @@ last_reinforced: 2026-04-26
|
||||
- **Suppression Tag:** 극히 제한적인 상황에서만 `suppressHydrationWarning` 속성 사용.
|
||||
- **의의:** 불필요한 UI 흔들림(Flicker)을 방지하고, 브라우저의 렌더링 성능 최적화(Hydration 효율성)를 보장함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 과거에는 수화 불일치 경고를 사소한 경고 정책으로 보았으나, 현대 React 정책은 이를 성능 저하와 버그의 전조로 간주하여 엄격히 관리할 것을 요구함. 특히 [[Next.js 15|Next.js 15]]+ 환경에서는 빌드 타임에 이를 더 공격적으로 검출 정책화함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 SSR 컴포넌트에 대해 'Zero Hydration Warning' 정책을 시행하며, 브라우저 전용 로직은 반드시 전용 커스텀 훅(`useIsMounted`)을 통해서만 처리하도록 강제함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Web-Rendering-Strategies-CSR-vs-SSR|Web-Rendering-Strategies-CSR-vs-SSR]], Server-Side-Rendering-SSR, [[Nextjs-App-Router-Architecture|Nextjs-App-Router-Architecture]], [[Frontend-Debugging-and-Testing|Frontend-Debugging-and-Testing]]
|
||||
- **Raw Source:** 00_Raw/Hydration Mismatch.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: 550e8400-e29b-41d4-a716-446655440004
|
||||
category: Unified
|
||||
id: wiki-2026-0508-ide-stability-fix
|
||||
title: IDE Stability Fix
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [550e8400-e29b-41d4-a716-446655440004]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.99
|
||||
tags: [skybound, typescript, stability, code-quality]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-21
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Skybound IDE 안정성 및 타입 보정
|
||||
@@ -18,7 +30,7 @@ last_reinforced: 2026-04-21
|
||||
- `SystemEnemy`, `SystemBoss` 인터페이스의 역할(Role) 및 페이즈(Phase) 타입 일합.
|
||||
- 미사용 구조 분해 할당(`emitEvent`) 제거로 린트 경고 해결.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 부정확한 타입 확장으로 발생하던 IDE 경고를 정밀한 리터럴 타입 적용으로 해결.
|
||||
- **정책 변화:** 모든 유틸리티 함수 반환값은 Partial을 지양하고 Full-spec을 따를 것.
|
||||
|
||||
@@ -27,7 +39,56 @@ last_reinforced: 2026-04-21
|
||||
- **Related:** 10_Wiki/Projects/Skybound/Architecture_Refactor
|
||||
- **Raw Source:** 00_Raw/2026-04-21-Skybound_IDE_Problems_Fix
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture_Refactor]]
|
||||
* [[decisions]]
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,29 +1,40 @@
|
||||
---
|
||||
category: Frontend
|
||||
tags: [auto-wikified, technical-documentation, frontend]
|
||||
id: wiki-2026-0508-impeller-engine
|
||||
title: Impeller Engine
|
||||
description: "Impeller Engine은 Flutter 프레임워크에서 기존 Skia를 대체하기 위해 도입된 **차세대 자체 렌더링 엔진**입니다."
|
||||
last_updated: 2026-05-04
|
||||
category: Frontend
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-wikified, technical-documentation, frontend]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Impeller Engine
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Impeller Engine은 Flutter 프레임워크에서 기존 Skia를 대체하기 위해 도입된 **차세대 자체 렌더링 엔진**입니다. 애플리케이션 빌드 단계에서 셰이더(Shader)를 사전 컴파일하여 런타임에 발생하는 셰이더 컴파일 버벅거림(Jank) 문제를 근본적으로 해결하도록 설계되었습니다. iOS에서는 기본 렌더러로 이미 안정화되었으며 Android에서도 점진적으로 도입되고 있어, 고도화된 애니메이션 환경에서도 일관된 60fps~120fps 성능을 제공하는 모바일 크로스 플랫폼 아키텍처의 핵심 요소입니다.
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **도입 배경 및 Skia 대체:** 기존 Flutter의 주요 성능 문제였던 **'셰이더 컴파일 버벅거림(Shader compilation jank)'을 해결하기 위해 개발**되었습니다 [1, 2]. iOS(Flutter 3.10부터) 및 최신 Android 버전에서 기존의 Skia 엔진을 대체하여 기본 그래픽 백엔드로 적용되고 있습니다 [1, 2].
|
||||
* **사전 컴파일 메커니즘:** 새로운 시각적 효과가 화면에 나타날 때 런타임에 셰이더를 컴파일하여 프레임 드롭이 발생하던 기존 방식과 달리, **빌드 과정에서 더 작고 단순하며 최적화된 셰이더 세트를 미리 컴파일(Pre-compiles)**합니다 [2, 3]. 이를 통해 앱 실행 시 첫 프레임부터 부드럽고 예측 가능한 성능을 보장합니다 [3].
|
||||
* **모바일 GPU 최적화:** 현대 모바일 GPU에 최적화된 **테셀레이션(Tessellation) 기반 렌더링 방식을 사용**하여, 복잡한 커스텀 애니메이션과 화면 전환에서도 높은 프레임 레이트(예: 120fps)의 유동적이고 일관된 성능을 유지할 수 있습니다 [2, 3].
|
||||
* **자체 렌더링 아키텍처:** 플랫폼의 네이티브 UI 컴포넌트(예: iOS의 UIKit, Android의 Views)에 의존하거나 호출하지 않고, **자체 렌더링 엔진(Impeller)을 사용하여 화면의 모든 픽셀을 직접 그립니다(Draws every pixel)** [4-6]. 이는 모든 모바일 기기 및 플랫폼에서 픽셀 단위로 일치하는 완벽한 UI 일관성을 제공합니다 [4, 5].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **앱 크기(App Size) 증가:** Impeller 렌더링 엔진과 Dart 런타임이 앱 패키지에 자체적으로 포함되어야 하므로, 최소한의 기능을 가진 앱이라 하더라도 **기본 APK 크기가 대략 8~12MB 수준으로 증가**합니다. 이는 네이티브 컴포넌트를 사용하여 상대적으로 앱 크기가 작은 React Native(5~8MB)에 비해 큰 편입니다 [7].
|
||||
* **네이티브 플랫폼 표준과의 미묘한 괴리:** 화면의 픽셀을 직접 렌더링하여 높은 커스터마이징과 일관성을 보장하지만, **플랫폼의 기본 네이티브 UI 컴포넌트를 사용하지 않으므로 발생하는 반대 급부**가 있습니다. 스크롤 물리 효과(Scroll physics), 텍스트 선택 동작, 접근성 의미(Accessibility semantics) 등에서 플랫폼 표준과 미묘한 차이가 발생할 수 있으며, OS 업데이트로 인한 새로운 UI 패러다임이 등장할 경우 이를 일일이 커뮤니티가 복제(Replicate)하여 구현해야 합니다 [4, 8].
|
||||
* **플랫폼 간 성숙도 불균형:** iOS에서는 이미 프로덕션 레벨로 안정화되어 기본 렌더러로 강력한 성능을 내고 있지만, **Android 버전에서는 여전히 프리뷰 단계이거나 지속 개선 중인 상태**입니다. 이로 인해 두 플랫폼 간 완전한 렌더링 안정성을 동일하게 보장받기까지는 약간의 시차가 존재합니다 [2, 9].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/기반 기술)]
|
||||
@@ -63,4 +74,53 @@ Impeller Engine은 Flutter 프레임워크에서 기존 Skia를 대체하기 위
|
||||
- 확장 방향: Dart 언어의 AOT 컴파일이 어떻게 JIT 컴파일에 비해 앱의 콜드 스타트(Cold start) 시간을 단축시키는지 조사하고, 이것이 셰이더 사전 컴파일과 만나 만들어내는 초기 로딩 속도 최적화 원리를 이해할 수 있습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-03*
|
||||
*Last updated: 2026-05-03*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-8EEC8D
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-indirect-draw
|
||||
title: Indirect Draw
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-8EEC8D]
|
||||
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 - Indirect Draw"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Indirect Draw|Indirect Draw]]
|
||||
@@ -22,7 +33,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Indirect Draw"
|
||||
* **지원 환경 및 한계 극복:**
|
||||
[[WebGPU|WebGPU]], Vulkan 등 최신 그래픽스 API 환경에서 주로 활용되며, Three.js에서도 WebGPU 도입과 함께 적극 활용되고 있다 [2, 6, 7]. 매우 복잡하고 방대한 객체를 다룰 때, 기존의 [[InstancedMesh|InstancedMesh]]나 BatchedMesh가 CPU 기반 데이터 업데이트 및 버퍼 패킹으로 인해 겪게 되는 성능 저하 한계를 근본적으로 극복할 수 있는 기술로 평가받는다 [2, 8, 9].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -35,3 +46,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Indirect Draw"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-2752BF
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-instancing
|
||||
title: Instancing
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-2752BF]
|
||||
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 - Instancing"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Instancing|Instancing]]
|
||||
@@ -22,7 +33,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Instancing"
|
||||
- **성능 저하의 원인:** 대규모 디자인 파일에서 복잡한 중첩 구조를 가진 컴포넌트를 사용할 때, 인스턴스 내부에 불필요하게 포함된 숨겨진 레이어(hidden layers)는 파일의 렌더링과 업데이트 속도를 크게 늦출 수 있습니다 [3, 8, 9].
|
||||
- **인스턴스 최적화 방안:** 구조 컴포넌트의 사용을 줄이고, 대신 별도의 변형(variants) 개수를 늘려 인스턴스 내의 숨겨진 레이어들을 제거하면 프로토타입 동작이 눈에 띄게 부드러워지며 성능이 크게 향상됩니다 [4, 10].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -35,3 +46,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Instancing"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,15 +1,26 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-F612C1
|
||||
category: "10_Wiki/💡 Topics/Software Engineering"
|
||||
id: wiki-2026-0508-jsi-javascript-interface
|
||||
title: JSI (JavaScript Interface)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-AUTO-F612C1]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-03
|
||||
github_commit: "[P-Reinforce] Continuous Worker - JSI (JavaScript Interface)"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[JSI (JavaScript Interface)|JSI (JavaScript Interface)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
JSI(JavaScript Interface)는 React Native의 '새로운 아키텍처(New Architecture)'의 중심이 되는 경량 범용 C++ 계층입니다 [1]. 기존의 비동기적 브릿지(Bridge) 방식이 지녔던 직렬화(Serialization) 오버헤드를 완전히 제거하고, 자바스크립트 코드와 네이티브 객체 간에 직접적이고 동기적인 참조를 가능하게 합니다 [1, 2]. 이를 통해 자바스크립트와 네이티브 스레드 간의 실시간 고성능 통신을 지원하며, React Native의 성능 격차를 네이티브 개발 수준으로 좁히는 핵심 기반 기술입니다 [1, 2].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
@@ -22,13 +33,12 @@ JSI(JavaScript Interface)는 React Native의 '새로운 아키텍처(New Archite
|
||||
* **자바스크립트 엔진 호환성**
|
||||
JSI는 범용적으로 설계되어, 고도로 최적화된 자바스크립트 엔진인 Hermes를 비롯한 다양한 자바스크립트 엔진을 안정적으로 지원할 수 있습니다 [1].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
JSI 및 이를 도입한 '새로운 아키텍처(New Architecture)'와 관련된 제약 사항에 대해서는 소스 내에 다음과 같은 점이 간접적으로 확인됩니다.
|
||||
React Native 버전 0.74부터 브릿지리스 모드(Bridgeless mode)가 기본적으로 활성화되면서 아키텍처의 패러다임이 브릿지에서 JSI 기반의 동기적 통신으로 전환되었습니다 [7, 8]. 이러한 변화는 성능과 반응성 면에서 압도적인 장점을 주지만, 생태계 내 기존 브릿지 기반의 수많은 서드파티 라이브러리(Native Modules)들이 새로운 아키텍처와 JSI에 온전히 대응하고 마이그레이션 하는 데 시간이 걸릴 수 있습니다 [7, 8]. 또한, JSI의 기반이 C++ 계층이므로 고도화된 네이티브 모듈을 개발할 경우 Java/Kotlin, Objective-C/Swift와 더불어 C++에 대한 이해가 요구될 수 있습니다 [1].
|
||||
그 외에 JSI 자체의 아키텍처적 결함이나 구체적이고 치명적인 부작용(Trade-off)에 대해서는 **소스에 관련 정보가 부족합니다.**
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/기반 기술)]
|
||||
@@ -76,3 +86,52 @@ React Native 버전 0.74부터 브릿지리스 모드(Bridgeless mode)가 기본
|
||||
*Last updated: 2026-05-03*
|
||||
- Raw Source: 00_Raw/2026-05-03/JSI (JavaScript Interface).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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,7 +1,27 @@
|
||||
## 📌 Brief Summary
|
||||
---
|
||||
id: wiki-2026-0508-jsx
|
||||
title: JSX
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
JSX는 UI를 상태(state)와 속성(props)의 순수 함수로 표현하는 선언형(declarative) 컴포넌트 트리 작성 문법이다. HTML과 유사한 구문을 통해 UI 구조를 직관적으로 설계할 수 있게 하며, React Compiler와 같은 현대적인 도구들을 통해 고성능 렌더링 최적화를 자동으로 수행한다.
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
1. **선언적 컴포넌트 합성 (Composition)**
|
||||
- UI를 독립적인 엘리먼트들의 트리 구조로 사고하고 조립하도록 유도하여 코드의 예측 가능성을 높인다.
|
||||
- JSX 자체는 비즈니스 로직의 위치를 강제하지 않으므로, 아키텍처적 제약(FSD 등)을 통해 로직 누수를 방지해야 한다.
|
||||
@@ -13,12 +33,12 @@ JSX는 UI를 상태(state)와 속성(props)의 순수 함수로 표현하는 선
|
||||
4. **인라인 함수 사용 시 주의점**
|
||||
- JSX 내부에서 익명 함수를 직접 정의하는 행위는 매 렌더링마다 새로운 참조를 생성하여 자식 컴포넌트의 불필요한 리렌더링을 유발하므로 지양해야 한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **로직 혼재의 위험**: JSX의 자유로운 특성으로 인해 UI 마크업 사이에 복잡한 비즈니스 규칙이 섞여 컴포넌트가 비대해지고 유지보수가 어려워질 수 있다.
|
||||
- **도구 의존성**: React Compiler와 같은 자동 최적화 도구는 'Rules of React'(순수성 등)를 엄격히 준수하는 코드에서만 안전하게 작동하므로, 기존 레거시 코드와의 호환성 검토가 필요하다.
|
||||
- **추상화 비용**: JSX 성능을 위해 모든 함수를 useCallback으로 감싸는 수동 최적화는 코드의 가독성을 해치고 관리 비용을 증가시키는 트레이드오프가 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Feature-Sliced_Design]]
|
||||
* [[React]]
|
||||
@@ -47,3 +67,52 @@ JSX는 UI를 상태(state)와 속성(props)의 순수 함수로 표현하는 선
|
||||
* **Memoization (useMemo, useCallback)**
|
||||
* **Feature-Sliced Design (FSD)**
|
||||
* **Virtual DOM vs Incremental DOM**
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: JS-ASYNC-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-javascript-async-and-event-loop
|
||||
title: JavaScript Async and Event Loop
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [JS-ASYNC-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [[JavaScript|[JavaScript]], [[Frontend|Frontend]], web-development, event-loop, async-await, concurrency]
|
||||
tags: ["JavaScript|[JavaScript", Frontend, web-development, event-loop, async-await, concurrency]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# JavaScript Async and Event Loop (JS 비동기와 이벤트 루프)
|
||||
@@ -21,10 +33,59 @@ last_reinforced: 2026-04-26
|
||||
- **Event Loop:** 콜 스택과 큐를 상시 감시하며 작업을 옮겨주는 중재자.
|
||||
- **의의:** 현대 웹 프론트엔드의 부드러운 애니메이션과 실시간 반응성을 지탱하는 기술적 뿌리.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 콜백 지옥(Callback Hell)에서 벗어나, Promise와 `async/await`라는 문법적 설탕(Syntactic Sugar)을 통해 비동기 코드를 동기 코드처럼 직관적으로 작성하는 시대로 완전히 전이됨.
|
||||
- **정책 변화:** ConnectAI 확장 프로그램은 VS Code의 메인 스레드를 방해하지 않기 위해, 모든 대규모 지식 검색 및 모델 호출 로직을 비동기 이벤트 루프 최적화 패턴에 따라 처리함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Frontend-Architecture|Frontend-Architecture]], [[Message-Queues-and-Event-Streams|Message-Queues-and-Event-Streams]],[[_system|system]]-Design-for-AI-Scale, [[Reactive-Programming|Reactive-Programming]]
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/JavaScript-Async-and-Event-Loop.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: PERF-JS-OPT-001
|
||||
category: Unified
|
||||
id: wiki-2026-0508-javascript-optimization-patterns
|
||||
title: JavaScript Optimization Patterns
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [PERF-JS-OPT-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [[JavaScript|[JavaScript]], performance, [[Optimization|Optimization]], inp, code-splitting, tree-shaking, web-workers, main-thread]
|
||||
tags: ["JavaScript|[JavaScript", performance, Optimization, inp, code-splitting, tree-shaking, web-workers, main-thread]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# JavaScript Optimization Patterns (자바스크립트 최적화 패턴)
|
||||
@@ -21,10 +33,59 @@ last_reinforced: 2026-04-26
|
||||
- **requestIdleCallback:** 중요도가 낮은 작업을 브라우저의 유휴 시간에 배치.
|
||||
- **의의:** 자바스크립트 실행으로 인한 UI 프리징을 제거하여 [[Core Web Vitals|Core Web Vitals]]의 INP 지표를 획기적으로 개선하고 실질적인 사용자 만족도를 높임.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 과거에는 모든 기능을 하나의 거대한 라이브러리에 의존하는 경향이 있었으나, 현대 정책은 '경량 모듈 정책'과 '필요 시 로드 정책'을 최우선으로 함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 동기적 루프에 대해 50ms 초과 시 경고 정책을 시행하며, CPU 집약적인 데이터 처리 로직은 반드시 웹 워커(Web Worker) 사용 정책을 준수하도록 함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Core-Web-Vitals-Metrics|Core-Web-Vitals-Metrics]], [[Interaction-to-Next-Paint-INP|Interaction-to-Next-Paint-INP]], [[Frontend-Performance-Optimization-Guide|Frontend-Performance-Optimization-Guide]], [[Clean-Code-Principles|Clean-Code-Principles]]
|
||||
- **Raw Source:** 00_Raw/JavaScript Optimization.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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,10 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-1AF373
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-javascriptcore
|
||||
title: JavaScriptCore
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-1AF373]
|
||||
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 - [[JavaScript|JavaScript]]Core"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[JavaScriptCore|JavaScriptCore]]
|
||||
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[JavaScript|JavaScript]]Core"
|
||||
- **실행 및 취약점 노출 원리:** JavaScriptCore가 JavaScript의 속성 접근(property access) 등 보안에 민감한 언어 작업을 처리할 때, 코드는 최신 CPU의 분기 예측([[Branch Prediction|Branch Prediction]])과 추측 실행([[Speculative Execution|Speculative Execution]])을 통해 병렬로 실행됩니다 [5, 6]. 공격자는 이 추측 실행 과정에서 L1 캐시와 메인 메모리 간의 지연 시간(latency) 차이를 악용하여 데이터를 유출할 수 있습니다 [4, 7].
|
||||
- **보안 완화(Mitigation) 전략:** Spectre 위협에 대응하기 위해 JavaScriptCore는 기존의 분기 기반 보안 검사에서 벗어나 '분기 없는 보안 검사([[Branchless Security Checks|Branchless Security Checks]])'를 도입하여 전환하고 있습니다 [3]. 대표적으로 객체 필드 접근 시 무작위 독성 값을 활용하는 '포인터 중독([[Pointer Poisoning|Pointer Poisoning]])' 기법을 JavaScriptCore의 수많은 데이터 구조에 적용함으로써, 임의의 포인터 생성을 막고 원격 코드 실행에 악용되는 유형 혼동(type confusion)을 방어하고 있습니다 [8, 9].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - [[JavaScript|JavaScript]]Core"
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -1,9 +1,21 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-JUDG-001
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
id: wiki-2026-0508-judgment
|
||||
title: Judgment
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-JUDG-001]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced, judgment, decision-making, wisdom, discretion, ethical-judgment]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Judgment|Judgment]]
|
||||
@@ -20,7 +32,7 @@ last_reinforced: 2026-04-20
|
||||
2. **왜 중요한가?**:
|
||||
* 연산력이 풍부한 시대일수록, 역설적으로 그 연산을 '어디에 쓸 것인가'를 결정하는 고도의 판단력이 가장 희소하고 값진 능력이 됨. ([[Intangible-Capital|Intangible-Capital]]의 핵심)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 권위자나 시스템이 내린 단일 정답 기반의 '수동적 판단 정책'이 주류였으나, 현대 정책은 데이터의 불확실성을 인정하고 다양한 시나리오를 검토하는 '확률적·비판적 판단 정책'으로의 전환을 요구함(RL Update). (Critical Thinking와 연결)
|
||||
- **정책 변화(RL Update)**: 윤리적 판단 정책을 아예 AI 모델 내부에 원칙(Constitution)으로 심으려는 노력과, 여전히 인간의 직접적 개입이 필요한 'Red-line 정책' 사이의 치열한 논의가 진행 중임. (Constitutional AI와 연결)
|
||||
|
||||
@@ -28,3 +40,52 @@ last_reinforced: 2026-04-20
|
||||
- [[Decision Theory|Decision Theory]], [[Ethics & AI|Ethics & AI]], [[Constitutional AI (헌법 AI)|Constitutional AI (헌법 AI)]], Critical Thinking, [[Intangible-Capital|Intangible-Capital]]
|
||||
- **Modern Tech/Tools**: Decision [[Support|Support]][[_system|system]]s, Ethical AI frameworks, Strategic planning tools.
|
||||
---
|
||||
|
||||
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user