docs(wiki): cleanup orphan documents, delete 32 stubs and archive 121 for future merge

10_Wiki/Topics/_Archive_Orphans/2026-04-25-Datacollector_Engine_Processed_Count_and_Stalled_Loop_Guard.md

@@ -0,0 +1,56 @@
+# Datacollector - processed 카운터 정체 및 엔진 루프 정지 감시 보강
+
+- 작성 시각: 2026-04-25 22:52:25 KST
+- 프로젝트: `/Volumes/Data/project/Antigravity/Datacollector`
+- 관련 파일: `src/lib/engine.ts`, `src/components/AgentDashboard.tsx`
+
+## 상황
+
+사용자는 작업이 되는 것처럼 보이지만 `processed` 수치가 계속 오르지 않고, 서버를 재시작하면 1개가 추가된 뒤 다시 멈춘 것처럼 보인다고 보고했다.
+
+## 확인한 내용
+
+브리지 서버 상태는 정상이고 `/api/health` 기준 `pendingRequests`도 0이었다. 따라서 서버 요청이 계속 물려 있는 문제보다는 프론트엔드 엔진 루프가 한 번 처리한 뒤 다음 반복으로 자연스럽게 이어지지 않는 가능성이 높았다.
+
+코드상 `processedCount`는 `executeTask()`가 마크다운 생성까지 끝낸 뒤 `store.incrementProcessed()`를 호출할 때만 오른다. 즉 카운터가 오르지 않는다는 것은 다음 중 하나일 가능성이 있다.
+
+- 다음 작업 합성이 아직 완료되지 않았다.
+- 프론트엔드 엔진 루프 타이머가 끊겼다.
+- UI 상태는 `running`인데 엔진 내부 싱글톤의 루프가 실제로는 잠든 상태가 되었다.
+
+## 조치
+
+`src/lib/engine.ts`:
+
+- `isLoopActive`, `lastActivityAt`, `loopTimer`를 추가했다.
+- `runLoop()` 중복 실행을 막으면서도, 루프가 잠든 경우 다시 깨울 수 있게 했다.
+- `kickIfStalled()`를 추가해 `running` 상태인데 45초 이상 루프 활동이 없으면 자동으로 다음 루프를 시작한다.
+- 다음 루프 예약을 `scheduleNextLoop()`로 통합해 타이머를 추적할 수 있게 했다.
+- 작업 완료 후 `processedCount`가 반영된 값을 로그로 남기도록 했다.
+
+`src/components/AgentDashboard.tsx`:
+
+- 상태가 `running`일 때 15초마다 엔진 heartbeat를 실행한다.
+- 엔진 루프가 잠든 것으로 판단되면 `kickIfStalled()`가 자동으로 다시 깨운다.
+
+## 검증
+
+다음 검증을 완료했다.
+
+```bash
+npm run lint
+```
+
+결과:
+
+- TypeScript 검사 통과
+
+## 운영 메모
+
+이제 작업 하나가 완료될 때 Mission Telemetry에 다음 형태의 로그가 추가된다.
+
+```text
+[ENGINE] '토픽명' 처리 카운트 반영 완료: N
+```
+
+이 로그가 보이면 `processed` 값도 함께 올라가는 것이 정상이다. 만약 이 로그가 보이지 않고 `최종 데이터 합성 중...` 이후 오래 멈춘다면, 그때는 카운터 문제가 아니라 NotebookLM 합성 요청이 오래 걸리거나 실패 응답을 기다리는 상태로 봐야 한다.

10_Wiki/Topics/_Archive_Orphans/2026-04-25-Skybound_Player_Airframe_and_8Stage_Boss_Continuity_Rework.md

@@ -0,0 +1,103 @@
+# 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 referenced 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` 계열이 회피 목적을 명확히 만드는지 확인한다.

10_Wiki/Topics/_Archive_Orphans/2026-04-25-Skybound_Skill_Concept_and_Hangar_Layout_Overlap_Fix.md

@@ -0,0 +1,75 @@
+# 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/weaponBehaviors.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 referenced in /sprites/player.png didn't resolve at build time`
+- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
+
+## 후속 플레이테스트 포인트
+
+- Gatling 진화 후 더 이상 긴 레이저 기둥이 보이지 않는지 확인한다.
+- `Twin Arc Vulcan`이 빠른 관통 탄막 무기로 체감되는지 확인한다.
+- Hangar에서 `UPGRADES`, `EVENT PASS` 탭 선택 시 왼쪽 패널과 콘텐츠가 겹치지 않는지 확인한다.
+- 전투 보상 텍스트가 화면 가장자리에서 잘리지 않는지 확인한다.

10_Wiki/Topics/_Archive_Orphans/2026-04-25-Skybound_Vampire_Survivors_Loop_and_Stage_Curve_Preparation.md

@@ -0,0 +1,116 @@
+# 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 referenced in /sprites/player.png didn't resolve at build time`
+- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
+
+## 후속 작업 제안
+
+- 각 스테이지별 고유 몬스터 역할 비중을 더 명확히 분리한다.
+- 스테이지별 보스 패턴을 현재보다 더 강하게 차별화한다.
+- 진화 무기별 화면 가독성과 성능을 플레이테스트로 검증한다.
+- 미니보스 처치 시 보물상자/카드 선택 보상을 확정 지급하는 구조를 추가하면 뱀서류 보상감이 더 강해진다.

10_Wiki/Topics/_Archive_Orphans/2026-04-26-Skybound_Enemy_Motion_Damage_Pressure_and_Projectile_Visual_Pass.md

@@ -0,0 +1,123 @@
+# 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/WeaponBehaviorEngine.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 이펙트를 더 세분화할지 결정한다.

10_Wiki/Topics/_Archive_Orphans/2026-04-26-Skybound_Low_Level_First_Upgrade_Offer_Balance.md

@@ -0,0 +1,111 @@
+# Skybound Low Level First Upgrade Offer Balance
+
+작성일: 2026-04-26 13:16 KST
+
+## 요청 요약
+
+- 게임 플레이 중 Tactical Level Up으로 무기/스킬 업그레이드 후보가 나온다.
+- 이미 많이 레벨업한 무기가 계속 후보에 자주 나오면 특정 무기 몰빵이 쉬워진다.
+- 레벨이 낮은 무기/스킬이 다음 후보에 포함될 확률을 더 높인다.
+- 레벨이 높은 무기/스킬은 낮은 레벨 스킬 대비 후보 포함 확률을 낮춘다.
+
+## 핵심 문제
+
+기존 `ProgressionSystem.generateSkillCards()`는 이미 보유한 스킬과 near-max 스킬에 보너스를 주는 구조였다.
+
+기존 구조의 문제:
+
+1. 한 무기가 빠르게 고레벨까지 몰릴 수 있다.
+2. Lv4 → Lv5 직전 스킬이 자주 후보에 떠서 성장 속도가 급격해진다.
+3. 다양한 무기를 경험하기보다 가장 강한 무기 하나가 빠르게 완성된다.
+4. Stage 1-2 중반부터 빌드가 너무 빨리 안정화될 수 있다.
+
+## 적용한 변경
+
+### 후보 선택 방식 변경
+
+기존에는 카테고리별로 후보를 고르고, 보유/시너지/near-max에 가중치를 더했다.
+
+변경 후에는 각 스킬마다 `offer weight`를 계산한다.
+
+가중치 기준:
+
+- 남은 레벨이 많을수록 가중치 증가
+- Lv0/Lv1 스킬은 상대적으로 더 자주 등장
+- Lv3 이상 스킬은 가중치 감소
+- max 직전 스킬은 강하게 가중치 감소
+- 시너지/EVO 보너스는 유지하되, 고레벨 스킬을 압도적으로 밀어주지는 않음
+
+### 고레벨 몰빵 완화
+
+Near-max 스킬은 기존에 오히려 보너스를 받았지만, 이제는 낮은 확률로만 나온다.
+
+적용 규칙:
+
+- `currentLevel >= maxLevel - 1`: 가중치 35%로 감소
+- `currentLevel >= maxLevel * 0.6`: 가중치 58%로 감소
+
+예시:
+
+- Lv0/Lv1 스킬: 목록에 더 잘 등장
+- Lv3/Lv4 스킬: 등장 가능하지만 낮은 빈도
+- Lv4 → Lv5 완성: 운이 좋아야 뜨는 마무리 선택으로 변경
+
+### 첫 선택 보정
+
+아직 아무 스킬도 없는 첫 Tactical Level Up에서는 새 무기 후보를 우선 제공한다.
+
+목표는 첫 선택이 빌드 방향을 정하는 순간으로 작동하게 하는 것이다.
+
+### 새 무기 확장 선택 유지
+
+이미 스킬을 보유한 이후에도 새 무기 후보가 완전히 사라지지는 않는다.
+
+변경 후:
+
+- 슬롯 여유가 있고 새 무기가 있으면 65% 확률로 하나의 build-expanding option을 제공한다.
+- 나머지 후보는 전체 가중치 풀에서 선택한다.
+
+### Mini-boss Reward Cache 보정
+
+미니보스 보상 카드도 가장 높은 레벨 무기를 무조건 우선하지 않도록 변경했다.
+
+변경 후에는 보유 무기 중에서도 낮은 레벨/남은 성장 여지가 큰 무기가 더 잘 선택된다.
+
+### UI fallback 보정
+
+일반적으로 카드 후보는 엔진에서 생성되지만, 예외적으로 `LevelUpModal`에서 fallback 랜덤이 동작할 수 있다.
+
+이 fallback도 동일한 low-level-first 가중치 규칙을 따르도록 변경했다.
+
+## 설계 의도
+
+이번 변경의 목표는 성장 속도를 늦추는 것만이 아니다.
+
+플레이어가 한 무기를 빠르게 완성해 “이미 빌드가 끝났다”라고 느끼는 시점을 뒤로 미루고, 여러 선택지 사이에서 더 오래 고민하게 만드는 것이 핵심이다.
+
+원하는 플레이 감각:
+
+1. 초반에는 새 무기와 낮은 레벨 무기가 자주 보인다.
+2. 중반에는 빌드 방향을 넓히거나 약한 축을 보완하게 된다.
+3. 고레벨 완성 선택은 자주 뜨지 않지만, 떴을 때 반갑다.
+4. 특정 무기 하나가 너무 빨리 완성되어 난이도를 붕괴시키는 일이 줄어든다.
+
+## 수정 파일
+
+- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
+- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.tsx`
+
+## 검증
+
+- `npm run build` 성공
+- `/sprites/player.png` 경고 없음
+- 출력 디렉터리: `dist/26`
+
+## 후속 플레이테스트 체크 포인트
+
+- Stage 1에서 같은 무기가 너무 빠르게 Lv4/Lv5까지 올라가지 않는지 확인한다.
+- 낮은 레벨 무기/패시브가 기존보다 자주 후보에 뜨는지 확인한다.
+- 고레벨 완성 선택이 너무 안 떠서 답답하지 않은지 확인한다.
+- EVO 경로가 완전히 막힌 느낌이 들지 않는지 확인한다.
+- 미니보스 보상 카드가 여전히 보상답게 느껴지는지 확인한다.

10_Wiki/Topics/_Archive_Orphans/2026-04-26-Skybound_Miniboss_Treasure_Cache_Reward_Loop.md

@@ -0,0 +1,109 @@
+# 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 referenced in /sprites/player.png didn't resolve at build time`
+- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
+
+## 후속 작업 제안
+
+- 미니보스 처치 순간에 실제 상자/코어가 열리는 0.6초 전용 연출을 추가한다.
+- 보상 카드에 `EVO READY`, `BUILD CORE`, `SURVIVAL PICK` 같은 태그를 붙여 선택 이유를 더 명확하게 보여준다.
+- 스테이지별 미니보스 외형과 탄막 패턴을 분리해 “이번 스테이지의 중간 위협” 정체성을 강화한다.
+- 보물상자 보상을 1장 선택에서 3장 순차 오픈 또는 희귀도 보상으로 확장할지 플레이테스트 후 결정한다.

10_Wiki/Topics/_Archive_Orphans/2026-04-26-Skybound_Player_Sprite_Path_Warning_Fix.md

@@ -0,0 +1,63 @@
+# Skybound Player Sprite Path Warning Fix
+
+작성일: 2026-04-26 12:11 KST
+
+## 요청 요약
+
+- `npm run build` 시 반복되던 `/sprites/player.png referenced 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 톤과 완전히 맞도록 한 번 더 정리한다.

10_Wiki/Topics/_Archive_Orphans/2026-04-26-Skybound_Reward_Card_Clarity_and_Command_Cache_UI.md

@@ -0,0 +1,104 @@
+# Skybound Reward Card Clarity and Command Cache UI
+
+작성일: 2026-04-26 09:40 KST
+
+## 요청 요약
+
+- 미니보스 보상 루프 다음 단계로, 보상 카드가 왜 좋은 선택인지 사용자가 즉시 이해할 수 있게 개선한다.
+- 미니보스 처치 보상과 위기 보급 보상을 같은 화면처럼 보이지 않게 구분한다.
+- Stylized Casual Magitech 톤앤매너 안에서 보상감 있는 카드 선택 UI를 강화한다.
+
+## 핵심 방향
+
+이전 단계에서 미니보스 처치 시 확정 업그레이드 선택 보상이 추가되었다. 하지만 카드 3장이 뜨는 것만으로는 사용자가 “왜 이 보상이 지금 내 빌드에 좋은지” 바로 이해하기 어렵다.
+
+이번 변경의 목표는 보상 화면을 단순 선택지가 아니라, 플레이어에게 다음 메시지를 전달하는 UI로 만드는 것이다.
+
+1. 이 카드는 현재 주력 빌드를 강화한다.
+2. 이 카드는 EVO 진화 경로에 필요하다.
+3. 이 카드는 스웜/압박 상황에서 생존에 도움이 된다.
+4. 이 카드는 새로운 공격 패턴을 열어준다.
+
+## 적용한 변경
+
+### 보상 출처 타입 추가
+
+`LEVEL_UP` 이벤트에 `rewardSource`를 추가했다.
+
+- `STARTER`
+- `LEVEL_UP`
+- `POWER_SPIKE`
+- `MINIBOSS`
+
+기존에는 `isChest`만 있어서 미니보스 보상과 위기 보급 보상이 모두 같은 `Emergency Supply`처럼 보였다. 이제 보상 출처에 따라 헤더, 문구, 카드 태그를 다르게 표시할 수 있다.
+
+### 미니보스 보상 헤더 차별화
+
+미니보스 보상은 이제 `Emergency Supply`가 아니라 `Command Cache`로 표시된다.
+
+- Badge: `Cache`
+- Title: `Command Cache`
+- Subtitle: `Choose one build-defining reward`
+
+위기 보급은 기존 의도대로 `Emergency Supply`를 유지한다.
+
+### 카드 선택 이유 태그 추가
+
+각 카드 상단에 보상 이유 태그를 추가했다.
+
+- `FIRST CORE`: 첫 무기 선택, 런의 시작 방향 결정
+- `CORE UPGRADE`: 현재 주력 무기 강화
+- `MODULE BOOST`: 보유 패시브/모듈 강화
+- `EVO LINK`: 현재 무기의 진화 조건을 지원
+- `EVO READY`: 진화 조건 완성
+- `SURVIVAL PICK`: 스웜/압박 구간 대응
+- `NEW WEAPON`: 새로운 공격 패턴 개방
+- `UTILITY MOD`: 기본 성능 강화
+
+이 태그는 단순 라벨이 아니라, 카드가 “왜 지금 의미 있는 선택인지”를 설명하는 짧은 문장과 함께 표시된다.
+
+### Command Cache 연출 추가
+
+보상 화면 상단에 작은 마법공학 캐시 코어를 추가했다.
+
+- 팝 인 애니메이션
+- 회전하는 점선 링
+- 미니보스 캐시는 청록/라임 계열 빛
+- 일반 보급은 오렌지/시안 계열 빛
+
+실제 게임 시간을 더 지연시키지는 않지만, 화면이 뜨는 순간 보상 상자가 열린다는 감각을 강화한다.
+
+## 설계 의도
+
+뱀파이어 서바이벌 계열의 재미는 단순히 레벨업을 많이 하는 것이 아니라, “내가 고른 선택 때문에 빌드가 강해지고 있다”는 확신에서 나온다.
+
+이번 변경은 그 확신을 UI로 보강한다.
+
+- 미니보스 처치: `Command Cache`
+- 위기 보급: `Emergency Supply`
+- 일반 레벨업: `Tactical Upgrade`
+- 시작 선택: `Choose First Weapon`
+
+이제 각 성장 이벤트는 같은 카드 선택이라도 서로 다른 의미를 가진다.
+
+## 수정 파일
+
+- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.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/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` 성공
+- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
+- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
+
+## 후속 작업 제안
+
+- 스테이지별 미니보스 패턴을 분리해 `Command Cache`를 얻는 과정 자체를 더 재미있게 만든다.
+- 보상 카드에 실제 EVO 결과 미리보기 아이콘을 추가한다.
+- 보물상자 보상을 1장 선택에서 희귀도 기반 다중 보상으로 확장할지 플레이테스트한다.
+- Command Cache가 열리는 짧은 0.5초 전용 컷인/상자 오픈 애니메이션을 Canvas 위에 추가한다.

10_Wiki/Topics/_Archive_Orphans/2026-04-26-Skybound_Skill_Slot_Limit_Weapon5_Passive5.md

@@ -0,0 +1,136 @@
+# Skybound Skill Slot Limit Weapon 5 Passive 5
+
+작성일: 2026-04-26 13:29 KST
+
+## 요청 요약
+
+- 사용자가 획득할 수 있는 스킬 수량에 제한을 둔다.
+- 총 10개 스킬을 보유할 수 있게 한다.
+- 10개 중 5개는 무기, 5개는 패시브로 분리한다.
+- 슬롯이 부족한 상태에서 새 스킬을 선택하려 하면 `슬롯이 부족합니다`에 해당하는 노티가 필요하다.
+- 슬롯 제한 때문에 사용하지 못하는 스킬이 목록에 나올 수 있으므로 `Skip Upgrade` 선택지도 계속 필요하다.
+- 5/5 구조가 적절한지 검토한다.
+
+## 판단
+
+현재 Skybound에는 무기와 패시브 풀이 이미 넓고, 8스테이지까지 성장해야 한다.
+
+따라서 지금 시점에서는 `무기 5개 + 패시브 5개`가 적절하다.
+
+더 줄이는 선택지도 가능하지만, 아직은 권장하지 않는다.
+
+- 4/4는 빌드 정체성이 더 강해지는 대신 초반 선택 운 영향이 커진다.
+- 5/5는 Survivor.io/Vampire Survivors류의 성장 폭과 전략성을 적당히 유지한다.
+- 6/6 이상은 사용자가 거의 모든 것을 들고 가는 느낌이 강해져 빌드 선택 의미가 약해진다.
+
+그래서 이번 패스에서는 5/5를 기본값으로 적용했다.
+
+## 적용한 변경
+
+### Skill Slot Limit 추가
+
+`skills.ts`에 슬롯 제한 상수를 추가했다.
+
+```ts
+export const SKILL_SLOT_LIMITS = {
+  WEAPON: 5,
+  PASSIVE: 5,
+}
+```
+
+이제 시스템 전반에서 동일한 기준을 사용한다.
+
+### 후보 생성 필터링
+
+`ProgressionSystem.generateSkillCards()`와 `generateMiniBossRewardCards()`에서 슬롯 제한을 반영했다.
+
+규칙:
+
+- 이미 보유한 스킬은 계속 레벨업 가능하다.
+- 새 무기 획득은 무기 슬롯이 5개 미만일 때만 가능하다.
+- 새 패시브 획득은 패시브 슬롯이 5개 미만일 때만 가능하다.
+- 슬롯이 꽉 찬 타입의 새 스킬은 정상 후보 생성에서 제외한다.
+
+### 선택 시 슬롯 부족 방어
+
+혹시 예외 경로로 선택 불가 카드가 들어오거나, UI/엔진 동기화 타이밍 문제로 새 스킬 선택이 들어올 수 있다.
+
+그래서 `ProgressionSystem.applySkillSelection()`에도 최종 방어를 추가했다.
+
+슬롯이 부족하면:
+
+- 스킬을 추가하지 않는다.
+- 게임을 재개한다.
+- 전투 화면에 `WEAPON SLOTS FULL` 또는 `PASSIVE SLOTS FULL` 텍스트를 띄운다.
+- 보조 텍스트로 `Choose another module or skip`을 띄운다.
+
+### Store 레벨 방어
+
+`useGameStore.addSkill()`에도 동일한 슬롯 제한 방어를 추가했다.
+
+이유:
+
+- UI나 엔진 외부에서 `addSkill()`이 호출되더라도 잘못된 스킬이 저장되지 않게 하기 위함이다.
+- `__skip__`도 기존처럼 저장되지 않는다.
+
+### Level Up UI 슬롯 상태 표시
+
+`LevelUpModal` 상단에 현재 슬롯 상태를 표시한다.
+
+표시:
+
+- `Weapons 0/5`
+- `Passives 0/5`
+
+슬롯이 가득 차면 해당 배지가 붉은 톤으로 바뀐다.
+
+### SLOT FULL 카드 표시
+
+정상 후보 생성에서는 사용 불가 카드가 거의 나오지 않지만, 예외적으로 pre-generated cards나 fallback 상태에서 들어올 수 있다.
+
+이 경우 카드에 다음 표시를 추가했다.
+
+- `SLOT FULL` 태그
+- `No empty weapon/passive slot` 설명
+- `WEAPON slots are full` 또는 `PASSIVE slots are full`
+
+사용자는 이때 새로 추가된 `Skip Upgrade`를 선택해 넘길 수 있다.
+
+## 설계 의도
+
+슬롯 제한의 핵심은 빌드 선택을 더 전략적으로 만드는 것이다.
+
+제한이 없으면 사용자는 결국 대부분의 무기와 패시브를 다 들고 가게 되고, 선택의 의미가 약해진다.
+
+5/5 구조에서는 다음 판단이 생긴다.
+
+1. 무기 슬롯 하나를 새 무기에 쓸 것인가?
+2. 기존 무기 레벨업을 기다릴 것인가?
+3. 패시브 슬롯을 EVO 재료에 쓸 것인가?
+4. 생존 패시브를 포기하고 공격 패시브를 가져갈 것인가?
+5. 지금 후보가 별로면 스킵할 것인가?
+
+이번 변경은 `Skip Upgrade`의 존재 이유도 더 명확하게 만든다.
+
+## 수정 파일
+
+- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/skills.ts`
+- `/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/ui/LevelUpModal.tsx`
+- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.css`
+
+## 검증
+
+- `npm run build` 성공
+- `/sprites/player.png` 경고 없음
+- 출력 디렉터리: `dist/28`
+
+## 후속 플레이테스트 체크 포인트
+
+- 무기 5개를 보유한 상태에서 새 무기 후보가 정상 레벨업 목록에서 제외되는지 확인한다.
+- 패시브 5개를 보유한 상태에서 새 패시브 후보가 정상 레벨업 목록에서 제외되는지 확인한다.
+- 이미 보유한 무기/패시브는 슬롯이 가득 차도 레벨업 가능한지 확인한다.
+- 예외적으로 `SLOT FULL` 카드가 보일 때 선택하면 슬롯 부족 노티가 뜨는지 확인한다.
+- `Skip Upgrade`가 슬롯 제한 상황에서 자연스러운 탈출구로 작동하는지 확인한다.
+- 5/5가 너무 넉넉하거나 너무 답답하지 않은지 확인한다.

10_Wiki/Topics/_Archive_Orphans/2026-04-26-Skybound_Skip_Upgrade_and_Weapon_Transform_Reconfiguration.md

@@ -0,0 +1,150 @@
+# 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 상태 추가
+
+`GameState`에 새 무기 장착 연출용 상태를 추가했다.
+
+추가 필드:
+
+- `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__` 같은 잘못된 값이 저장되지 않는지 확인한다.
+- 새 무기를 처음 선택했을 때 기체 변신 연출이 충분히 눈에 띄는지 확인한다.
+- 기존 무기 레벨업/패시브 선택 시 변신 연출이 과하게 반복되지 않는지 확인한다.

10_Wiki/Topics/_Archive_Orphans/2026-04-26-Skybound_Stage1_to_3_Playtest_Balance_Bomb_and_Visual_Diversity_Pass.md

@@ -0,0 +1,205 @@
+# 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/weaponBehaviors.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에서 피격 압박은 생겼지만, 갑자기 불합리하게 어려워지지는 않았는지 확인한다.

10_Wiki/Topics/_Archive_Orphans/2026-04-26-Skybound_Stage_Miniboss_Pattern_Differentiation.md

@@ -0,0 +1,115 @@
+# 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`
+- `miniBossActionSeed`
+- `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 referenced in /sprites/player.png didn't resolve at build time`
+- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
+
+## 후속 작업 제안
+
+- 실제 플레이에서 Stage 4 `BARRAGE_WALL`과 Stage 7 `BLINK_SNIPER`의 탄속/쿨다운을 체감 기준으로 조정한다.
+- 미니보스 등장 시 패턴 이름을 더 상품성 있는 경고 문구로 표시한다.
+- 미니보스별 외형 색상, 엔진 이펙트, 코어 형태를 패턴에 맞게 분리한다.
+- `Command Cache` 오픈 전 0.5초 컷인 연출을 추가해 전투 승리 보상감을 더 강화한다.

10_Wiki/Topics/_Archive_Orphans/ADR-0001-volumes-data-project-antigravity-wiki-10-wiki-topics-여기가-네-지.md

@@ -0,0 +1,19 @@
+# ADR: /Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics 여기가 네 지식들이 저장된 곳이야. 내용을 보고...
+
+## Status
+accepted
+
+## Context
+/Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics 여기가 네 지식들이 저장된 곳이야. 내용을 보고 정리 정돈이 잘되어잇는지. 아니면 좀 더 개선할 부분이 있는지 평가해줄 수 있어?
+
+## Decision
+## 간단 요약 이 요청은 프로젝트 지식 생성이 아니라 코드리뷰와 제품 평가 요청입니다. 확인된 파일 구조 기준으로 보면, 이 프로젝트는 지식 수집 워크플로우를 앱 형태로 묶어 운영하려는 도구로 보이며, 먼저 데이터 수집 흐름의 안정성, 외부 연동 실패 처리, 수집 결과의 저장/재처리 가능성을 중심으로 평가해야 합니다. ## 확인된 근거 대상 경로: `/Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics` 확인된 우선 파일: - `Backend/_brief.md` - `Backend/개발자 경험(DX).md` - `Backend/넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환.md` - `Backend/대규모 3D 건축 모델(BIM) 시각화.md` - `Backend/대규모 프론트엔드 웹 프로젝트 폴더 구조...
+
+## Reason
+Captured automatically because the conversation contained decision-oriented language.
+
+## Alternatives
+Not captured yet.
+
+## Consequences
+- Future prompts should treat this as project context unless the user changes direction.

10_Wiki/Topics/_Archive_Orphans/ADR-0002-volumes-data-project-antigravity-wiki-10-wiki-topics-제2뇌의-지식.md

@@ -0,0 +1,19 @@
+# ADR: /Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics 제2뇌의 지식이 정보 간의 연결성(Interco...
+
+## Status
+accepted
+
+## Context
+/Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics 제2뇌의 지식이 정보 간의 연결성(Interconnectivity)과 실행 가능성(Actionability) 평가해주고 부족한 부분이 무엇이 있는지 의견을 주면 좋겠어. 개선 점 도,
+
+## Decision
+## 간단 요약 이 요청은 프로젝트 지식 생성이 아니라 코드리뷰와 제품 평가 요청입니다. 확인된 파일 구조 기준으로 보면, 이 프로젝트는 지식 수집 워크플로우를 앱 형태로 묶어 운영하려는 도구로 보이며, 먼저 데이터 수집 흐름의 안정성, 외부 연동 실패 처리, 수집 결과의 저장/재처리 가능성을 중심으로 평가해야 합니다. ## 확인된 근거 대상 경로: `/Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics` 확인된 우선 파일: - `Backend/_brief.md` - `Backend/개발자 경험(DX).md` - `Backend/넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환.md` - `Backend/대규모 3D 건축 모델(BIM) 시각화.md` - `Backend/대규모 프론트엔드 웹 프로젝트 폴더 구조...
+
+## Reason
+Captured automatically because the conversation contained decision-oriented language.
+
+## Alternatives
+Not captured yet.
+
+## Consequences
+- Future prompts should treat this as project context unless the user changes direction.

10_Wiki/Topics/_Archive_Orphans/AOP_Aspect-Oriented_Programming.md

@@ -0,0 +1,29 @@
+---
+category: Computer_Science_and_Theory
+tags: [auto-wikified, technical-documentation, computer_science_and_theory]
+title: AOP (Aspect-Oriented Programming)
+description: "AOP(Aspect-Oriented Programming)는 로깅, 보안, 트랜잭션 관리와 같은 횡단 관심사(Cross-Cutting Concerns)를 소프트웨어 시스템의 여러 모듈에서 분리하여 관리하는 방법론이자 프로그래밍 기법입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# AOP (Aspect-Oriented Programming)
+
+## 📌 Brief Summary
+AOP(Aspect-Oriented Programming)는 로깅, 보안, 트랜잭션 관리와 같은 횡단 관심사(Cross-Cutting Concerns)를 소프트웨어 시스템의 여러 모듈에서 분리하여 관리하는 방법론이자 프로그래밍 기법입니다 [1, 2]. 핵심 비즈니스 로직과 인프라 코드를 분리함으로써 소스 코드의 오염을 방지하고 코드의 가독성과 유지보수성을 크게 높여줍니다 [3, 4]. 주로 런타임에 메서드 호출을 가로채어 실행 전, 후, 또는 주변(around)에 원하는 동작을 적용하는 방식으로 작동합니다 [1, 2].
+
+## 📖 Core Content
+- **관심사의 분리 (Separation of Concerns)**: 소프트웨어는 주요 기능을 담당하는 핵심 관심사(Core Concerns, 비즈니스 로직)와 시스템 전반에 걸쳐 필요한 보조 기능인 횡단 관심사(Crosscutting Concerns)로 나뉩니다 [5]. AOP는 로깅, 데이터 전송, 보안, 성능 모니터링, 캐싱 등 애플리케이션의 여러 계층을 가로지르는 횡단 관심사를 별도의 '애스펙트(Aspect)'로 분리하여 관리합니다 [1, 5].
+- **Spring Boot에서의 실전 구현**: Spring 생태계에서 AOP는 컨트롤러, 서비스, 리포지토리 등 모든 Spring Bean의 메서드를 인터셉트할 수 있는 애플리케이션 및 서비스 계층의 기술로 활용됩니다 [1, 6]. 개발자는 `@Aspect`를 사용하여 `@Before`, `@After`, `@Around` 등의 시점(Pointcut)을 정의해 비즈니스 로직의 수정 없이 공통 기능을 주입할 수 있습니다 [1, 6].
+- **주요 활용 사례**:
+  - **트랜잭션 동작(Transactional Behavior)**: 모든 서비스 메서드에 `try-catch` 블록과 `commit`/`rollback` 호출을 반복 작성하는 대신, 어노테이션 마커를 통해 트랜잭션 처리 책임을 AOP에 위임합니다 [7].
+  - **인가(Authorization)**: 서비스 메서드를 호출할 수 있는 권한을 마커로 표시하고, AOP 어드바이스(Advice)가 해당 메서드의 실행 허용 여부를 동적으로 결정하게 합니다 [8].
+  - **원격 호출(Remoting)**: 분산 시스템 환경에서 대상 식별, 데이터 직렬화, 원격 네트워크 호출 등의 복잡한 처리를 애스펙트가 대신 수행하여, 개발자는 로컬 컴포넌트를 호출하는 것처럼 코드를 작성할 수 있습니다 [9].
+- **코드 품질 및 설계 향상**: AOP를 통해 공통 인프라 로직을 캡슐화하면 코드의 산재(Scattering)와 얽힘(Tangling)을 효과적으로 방지할 수 있습니다 [3, 10]. 이는 DRY(Don't Repeat Yourself) 원칙과 단일 책임 원칙(SRP) 위반을 막아주어, 대규모 코드베이스를 깨끗하고 리팩토링하기 쉬운 상태로 유지하도록 돕습니다 [3, 11].
+
+## ⚖️ Trade-offs & Caveats
+- **디버깅 난이도 상승 (마법 같은 동작)**: AOP는 비즈니스 코드와 인프라 코드를 완벽하게 분리하는 강력한 장점이 있지만, 실행 시점에 동적으로 로직을 삽입하므로 코드의 실제 실행 흐름을 직관적으로 파악하기 어렵게 만듭니다 [4]. 이러한 지나치게 '마법 같은(magical)' 동작 방식은 예기치 않은 오류 발생 시 추적과 디버깅을 매우 까다롭게 만드는 부작용이 있습니다 [4].
+- **런타임 성능 오버헤드**: Castle.DynamicProxy와 같은 런타임 인터셉터 프레임워크를 사용할 경우, 각 메서드나 클래스에 대한 프록시 래퍼(Proxy wrapper)를 동적으로 생성해야 하므로 추가적인 런타임 비용이 발생합니다 [12]. 로깅과 같이 매우 빈번하게 호출되는 연산에 전면적으로 적용할 경우 애플리케이션 전반의 성능을 저하시킬 수 있습니다 [12].
+- **빌드 파이프라인의 복잡성 증가**: 성능 오버헤드라는 제약을 피하기 위해 런타임 프록시 대신 컴파일 타임(Compile-time)이나 링크 타임(Link-time) 위빙(Weaving) 방식으로 AOP를 구현할 수 있습니다 [12]. 하지만 이 최적화 방법은 빌드 과정 자체를 훨씬 복잡하게 만드는 반대급부를 수반합니다 [12].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/AOT_Compilation_Ahead-of-Time.md

@@ -0,0 +1,25 @@
+---
+category: Computer_Science_and_Theory
+tags: [auto-wikified, technical-documentation, computer_science_and_theory]
+title: AOT Compilation (Ahead-of-Time)
+description: "AOT(Ahead-of-Time) 컴파일은 애플리케이션이 실행되기 전에 소스 코드를 기기의 네이티브 기계어(ARM 코드 등)로 미리 컴파일해 두는 기술입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# AOT Compilation (Ahead-of-Time)
+
+## 📌 Brief Summary
+AOT(Ahead-of-Time) 컴파일은 애플리케이션이 실행되기 전에 소스 코드를 기기의 네이티브 기계어(ARM 코드 등)로 미리 컴파일해 두는 기술입니다 [1, 2]. 주로 Flutter 프레임워크의 Dart 언어나 Spring Boot의 GraalVM 네이티브 컴파일 환경 등에서 활용됩니다 [3, 4]. 실행 시점에 코드를 동적으로 해석하거나 파싱할 필요가 없으므로 애플리케이션의 콜드 스타트(Cold start) 시간을 크게 단축시키며, 네이티브 수준의 높은 실행 효율과 성능을 보장할 수 있습니다 [1, 5].
+
+## 📖 Core Content
+* **Flutter와 Dart의 AOT 컴파일:** Flutter를 구동하는 Dart 가상 머신(VM)은 빠른 컴파일 환경을 제공하기 위해 JIT(Just-In-Time) 컴파일과 AOT 컴파일을 모두 지원합니다 [6]. 프로덕션 배포 시 Flutter 앱은 AOT 컴파일을 통해 Android 및 iOS용 네이티브 기계어(ARM 코드 등)로 사전에 직접 컴파일됩니다 [1, 2]. 엔진 초기화 및 자바스크립트 번들 파싱 과정을 거쳐야 하는 다른 크로스 플랫폼 기술과 비교했을 때, 런타임 오버헤드가 대폭 제거되어 콜드 스타트 시간이 눈에 띄게 단축되며 실행 효율이 극대화됩니다 [1, 5]. 결과적으로 네이티브 애플리케이션 본연의 성능(Original performance)을 달성할 수 있습니다 [3].
+* **Spring Boot의 네이티브 컴파일 (GraalVM 활용):** 자바(Java) 기반 백엔드 프레임워크인 Spring Boot 환경에서도 AOT 최적화 맥락과 맞닿아 있는 GraalVM 네이티브 컴파일을 채택하고 있습니다 [4]. 일반적인 JVM 애플리케이션은 시작하는 데 5~30초의 시간이 소요되지만, 이 네이티브 컴파일을 적용하면 코드가 사전 빌드되어 밀리초 단위로 애플리케이션을 시작할 수 있고 기존보다 훨씬 적은 힙 메모리(a fraction of the heap)만으로도 가동할 수 있습니다 [4].
+
+## ⚖️ Trade-offs & Caveats
+AOT 및 사전 네이티브 컴파일 방식을 애플리케이션 아키텍처에 도입할 경우, 최적화 이면에서 다음과 같은 반대 급부와 제약 사항을 반드시 고려해야 합니다.
+
+* **빌드 복잡성 증가 및 런타임 유연성 제한:** Spring Boot와 같은 환경에서 GraalVM을 활용한 네이티브 빌드를 적용할 경우, 사전에 정적 분석 및 컴파일을 수행해야 하므로 빌드 환경 구축과 과정의 복잡성(build complexity)이 크게 증가합니다 [4]. 더불어 코드가 네이티브 이미지로 완전히 고정되기 때문에, 기존 JVM이 지니고 있던 동적 로딩 등의 런타임 유연성(runtime flexibility)이 일부 상실되는 제약을 감수해야 합니다 [4].
+* **애플리케이션 파일 크기(앱 번들) 상승 부담:** 네이티브 기계어로 직접 컴파일되는 Flutter 애플리케이션의 경우, 컴파일된 결과물과 함께 Dart 런타임 및 자체 렌더링 엔진(예: Impeller)이 하나로 패키징되어 포함되어야 합니다 [1]. 이로 인해 아주 단순한 앱이라도 최소 기본 APK 크기가 8~12MB 수준에 달하게 되며, 복잡한 네이티브 코드가 포함됨에 따라 전체 앱 크기(App Size)가 다소 커지는 단점이 발생할 수 있습니다 [1, 7].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Active_Record_Pattern_vs_Repository_Pattern.md

@@ -0,0 +1,29 @@
+---
+category: Other
+tags: [auto-wikified, technical-documentation, other]
+title: Active Record Pattern vs Repository Pattern
+description: "Active Record 패턴은 데이터베이스 모델의 관심사와 비즈니스 로직을 하나의 객체나 계층에 결합하여 처리하는 설계 방식이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Active Record Pattern vs Repository Pattern
+
+## 📌 Brief Summary
+Active Record 패턴은 데이터베이스 모델의 관심사와 비즈니스 로직을 하나의 객체나 계층에 결합하여 처리하는 설계 방식이다 [1]. 반면 Repository 패턴은 데이터 접근을 전담하는 저장소(Repository) 계층을 분리하고, 모델은 비즈니스 로직이 없는 단순한 객체(dumb models/DTOs)로 유지하는 상반된 접근 방식을 취한다 [1, 2]. 최근 소프트웨어 산업은 모델 중심이 아닌 기능(Feature)을 축으로 비즈니스 로직을 분리하기 위해 점차 Active Record에서 Repository 패턴으로 이동하는 추세를 보이고 있다 [1].
+
+## 📖 Core Content
+* **Active Record 패턴의 특성**
+  Active Record 패턴은 데이터베이스 모델 내에 데이터 처리와 비즈니스 로직을 함께 구현하는 방식이다 [1]. 과거에는 데이터베이스 관련 관심사를 단순화하여 비즈니스 로직을 직관적으로 표현할 수 있다는 장점이 있었으나, 점차 애플리케이션 규모가 커지고 성능 및 확장성 등 다양한 기술적 관심사가 추가되면서 단일 계층에 너무 많은 책임이 혼재되는 문제를 겪게 되었다 [1].
+
+* **Repository 패턴의 특성 및 구현**
+  Repository 패턴은 데이터 접근은 오직 리포지토리를 통해서만 이루어지도록 강제한다 [2]. 이 패턴에서는 모델을 능동적인 객체가 아닌 '단순한 모델(dumb models)이나 DTO'로 정의하며, 실제 비즈니스 로직은 컨트롤러나 서비스 계층에서 담당하도록 관심사를 분리한다 [1]. 
+  Spring Boot 환경에서는 Spring Data JPA를 통해 Repository 패턴을 핵심적으로 활용하며, 메서드 이름에 따라 자동으로 쿼리를 생성해 데이터 접근에 필요한 보일러플레이트 코드를 크게 줄여준다 [3]. 이 방식은 관심사의 깔끔한 분리를 유지하면서도 복잡한 데이터베이스 쿼리를 원활히 지원하는 장점이 있다 [4].
+
+## ⚖️ Trade-offs & Caveats
+* **Active Record의 관심사 혼재와 부작용 위험**
+  Active Record 패턴을 유지하면서 Django의 시그널(Signals)과 같은 기능을 혼용할 경우, 비즈니스 로직이 예기치 않게 곳곳으로 스며들거나(creeping in) 보이지 않는 부수 효과(side-effects)를 발생시켜 시스템을 통제 불능 상태로 만들 수 있는 심각한 안티 패턴을 초래할 수 있다 [1, 5].
+* **Repository 패턴의 계층 복잡성**
+  Repository 패턴을 적용하면 Controller → Service → Repository로 이어지는 간접 참조(indirection) 및 계층화가 강제되므로, 단순한 로직을 처리할 때도 불필요한 스캐폴딩이 늘어나 애플리케이션 구조가 복잡해질 수 있다 [6]. 따라서 무조건적인 도메인 모델링보다는 도메인의 복잡성이 이를 요구할 만큼 충분히 높을 때 도입하는 것이 권장된다 [2].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Async_Messaging.md

@@ -0,0 +1,26 @@
+---
+category: Computer_Science_and_Theory
+tags: [auto-wikified, technical-documentation, computer_science_and_theory]
+title: Async Messaging
+description: "비동기 메시징(Async Messaging)은 동기식 통신(예: HTTP)이 트래픽이 많은 시스템에서 병목 현상을 일으키는 것을 방지하기 위해 도입하는 자동 백프레셔(back pressure) 기반의 논블로킹 통신 방식이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Async Messaging
+
+## 📌 Brief Summary
+비동기 메시징(Async Messaging)은 동기식 통신(예: HTTP)이 트래픽이 많은 시스템에서 병목 현상을 일으키는 것을 방지하기 위해 도입하는 자동 백프레셔(back pressure) 기반의 논블로킹 통신 방식이다 [1]. 애플리케이션에서 이메일 발송, 알림, 로깅, 아카이빙 등의 백그라운드 작업 처리를 수행할 때 주로 사용된다 [1]. 마이크로서비스 시스템뿐만 아니라 규모가 작은 모놀리식 아키텍처로 시작할 때에도 확장성 및 처리 효율성을 위해 가능한 한 빨리 내장(build in)하는 것이 권장된다 [1].
+
+## 📖 Core Content
+* **도입 목적 및 활용 분야**: 동기식 프로토콜인 HTTP는 다량의 트래픽을 처리하는 시스템에서 한계 요소가 될 수 있으므로, 이를 극복하기 위해 비동기 메시징과 논블로킹(non-blocking) 통신 방식이 사용된다 [1]. 메일 전송, 알림, 시스템 로깅, 데이터 아카이빙 등 즉각적인 응답이 필요 없는 비동기 작업을 처리하는 데 매우 효과적이다 [1].
+* **초기 아키텍처 단계에서의 적용**: 개발자 수가 20명 미만인 팀의 경우 복잡성을 최소화하기 위해 모놀리식 아키텍처로 시작하는 것이 좋으나, 이때에도 비동기 메시징 기능만큼은 가능한 한 빨리 아키텍처에 통합하는 것이 모범 사례로 제시된다 [1].
+* **NestJS 프레임워크의 지원 패턴**: NestJS는 마이크로서비스 구축을 위한 내장 전송 계층(transport layer)을 기본적으로 갖추고 있어 비동기 메시징 구현에 매우 강력하다 [2, 3]. Redis, NATS, Kafka, RabbitMQ, gRPC 등 다양한 메시지 브로커를 프로덕션 수준으로 지원하며, 요청-응답(request-response) 및 이벤트 기반(event-based) 메시지 패턴을 손쉽게 사용할 수 있다 [2-4].
+* **Spring Boot 프레임워크의 지원 패턴**: 엔터프라이즈 환경에서 널리 쓰이는 Spring Boot는 Spring AMQP, Spring Kafka 등의 도구를 통해 분산 시스템의 메시지 큐와 이벤트 주도 아키텍처(Event-Driven Architecture)를 유연하게 구현할 수 있다 [5, 6].
+* **Django 프레임워크의 비동기 작업 패턴**: Django 진영에서는 백그라운드 처리를 위해 전통적으로 Celery, Dramatiq와 같은 외부 큐 시스템이 널리 쓰여왔으나 [7], 최근 Django 6.0 릴리스에서 HTTP 요청-응답(request-response) 사이클 외부에서 비동기적으로 코드를 실행할 수 있는 'Tasks 프레임워크'를 기본 내장함으로써 이메일 발송 및 비동기 데이터 처리의 편의성을 높였다 [8, 9].
+
+## ⚖️ Trade-offs & Caveats
+* **복잡성 및 디버깅 난이도 증가**: 비동기 메시징을 활용하여 마이크로서비스와 같은 분산 시스템으로 확장할 경우, 전체적인 개발 및 운영 복잡성이 오히려 증가한다 [10]. 모든 구성요소가 하나의 애플리케이션에 포함된 모놀리식 환경과 비교할 때, 비동기 메시징이 포함된 분산 환경은 디버깅과 로깅이 훨씬 까다로워지며 배포를 위한 고도의 자동화와 오케스트레이션을 요구한다 [1, 10].
+* **구조적 고려 및 기술 제약**: 시스템 전체에 비동기 기능을 통합할 때는 초기 설계 단계에서부터 신중한 계획(careful planning)이 필수적이다 [8, 9]. 예를 들어, Django에서 전체 비동기(full async) 아키텍처를 적용하려면 웹소켓이나 비동기 환경을 프로젝트 시작 단계부터 설계에 반영해야 하는 까다로운 작업이 수반된다 [8, 9]. 또한 Node.js 기반 프레임워크의 경우 단일 스레드 이벤트 루프를 사용하기 때문에 비동기 I/O 작업에는 뛰어나지만, CPU 집약적인 연산이 포함될 경우 이벤트 루프가 차단(blocking)되어 비동기 응답 성능이 저하될 수 있으므로 분리된 워커 스레드로 작업을 오프로드해야 하는 제약 사항이 존재한다 [11].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Asynchronous_Messaging.md

@@ -0,0 +1,28 @@
+---
+category: Computer_Science_and_Theory
+tags: [auto-wikified, technical-documentation, computer_science_and_theory]
+title: Asynchronous Messaging
+description: "비동기 메시징(Asynchronous Messaging)은 메일, 알림, 로깅, 보관(Archiving) 등의 작업을 처리할 때 시스템이 대기하지 않도록 하는 논블로킹(Non-blocking) 통신 방식이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Asynchronous Messaging
+
+## 📌 Brief Summary
+비동기 메시징(Asynchronous Messaging)은 메일, 알림, 로깅, 보관(Archiving) 등의 작업을 처리할 때 시스템이 대기하지 않도록 하는 논블로킹(Non-blocking) 통신 방식이다 [1]. 동기식 프로토콜인 HTTP가 고트래픽 시스템에서 병목 지점이 될 수 있는 한계를 극복하기 위해 사용되며, 자동 백프레셔(Back pressure) 기능을 갖춘 비동기 통신을 도입하는 것이 권장된다 [1]. 현대 소프트웨어 프레임워크에서는 내장된 전송 계층이나 외부 메시지 큐를 활용해 이러한 비동기 패턴을 실전에 적용하고 있다 [2, 3].
+
+## 📖 Core Content
+*   **비동기 메시징의 역할 및 도입 시기:** 
+    개발자 규모가 작은 조직에서 모놀리식(Monolith) 아키텍처로 프로젝트를 시작하더라도, 메일 전송, 알림, 로깅, 데이터 보관과 같은 작업을 처리하기 위해 가능한 한 빨리 비동기 메시징을 시스템에 내장하는 것이 좋다 [1]. HTTP 통신의 동기적 제약을 우려하여 대안적인 논블로킹 통신 패턴으로 활용된다 [1].
+*   **프레임워크별 실전 패턴 및 지원:**
+    *   **NestJS:** 마이크로서비스 아키텍처를 위한 전송 계층을 내장하고 있으며, Redis, NATS, Kafka, RabbitMQ와 같은 메시지 브로커를 기본적으로 지원한다 [2, 4-6]. NestJS 환경에서는 요청-응답(Request-response) 패턴뿐만 아니라 이벤트 기반(Event-based) 메시지 패턴을 모두 유연하게 처리할 수 있다 [2].
+    *   **Spring Boot:** 대규모 엔터프라이즈 환경에 널리 쓰이는 Spring Boot는 메시지 큐 연동을 위해 Spring AMQP, Spring Kafka 등을 지원한다 [7].
+    *   **Django:** Django 환경에서 복잡한 비동기 작업은 전통적으로 Celery와 같은 외부 큐를 결합하여 처리하는 패턴이 주로 사용된다 [3]. 아울러 최신 버전(Django 6.0 등)에서는 요청-응답 주기(Request-response cycle) 외부에서 비동기 데이터를 처리하거나 이메일을 전송할 수 있도록 백그라운드 처리를 위한 'Tasks Framework'가 기본 도입되었다 [8].
+
+## ⚖️ Trade-offs & Caveats
+*   **도입 및 운영 복잡성 증가:** 비동기 메시징 처리를 위해 Celery와 같은 외부 큐 기반 시스템을 도입하는 것은 애플리케이션을 과도하게 복잡하게 만들고 잦은 실수를 유발하는 요인(footguns)이 될 수 있다는 강력한 비판이 존재한다 [9]. 이에 대한 대안으로 Dramatiq을 사용하거나, 최근 프레임워크 자체에 내장된 백그라운드 태스크 기능을 활용하여 복잡도를 낮추려는 시도가 권장된다 [9, 10].
+*   **데이터 검증 및 스키마 관리 문제:** 비동기 작업이나 메시지 큐를 통해 데이터를 전달할 때, 타입이 지정되지 않은 원시 딕셔너리(untyped dicts)를 코드 전반에 남용하는 것은 유지보수를 어렵게 하는 코드 악취(Code smell)로 간주된다 [9]. 비동기 외부 큐를 사용할 때는 데이터 무결성을 위해 Pydantic과 같은 라이브러리를 활용하여 전달되는 데이터 스키마를 엄격히 검증하고 관리하는 패턴이 필수적이다 [3, 9].
+
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Boilerplate.md

@@ -0,0 +1,28 @@
+---
+category: Other
+tags: [auto-wikified, technical-documentation, other]
+title: Boilerplate
+description: "**보일러플레이트(Boilerplate)**는 핵심 비즈니스 로직을 지원하기 위해 반복적으로 작성해야 하는 가치가 낮고 판에 박힌 코드를 의미한다 [1]."
+last_updated: 2026-05-04
+---
+
+# Boilerplate
+
+## 📌 Brief Summary
+**보일러플레이트(Boilerplate)**는 핵심 비즈니스 로직을 지원하기 위해 반복적으로 작성해야 하는 가치가 낮고 판에 박힌 코드를 의미한다 [1]. 현대 소프트웨어 개발 프레임워크와 라이브러리들은 이러한 보일러플레이트 코드를 줄여 개발 생산성을 높이고 유지보수성을 향상시키는 방향으로 발전하고 있다 [2-4]. 이를 위해 프레임워크 차원의 추상화, 상태 관리 도구의 최적화, 그리고 코드 자동 생성 기술이 적극적으로 활용된다 [5, 6].
+
+## 📖 Core Content
+*   **보일러플레이트의 문제점**: 귀중한 핵심 비즈니스 로직이 방대한 양의 가치 없는 보일러플레이트 코드와 섞이게 되면, 전체적인 코드를 이해하고 유지보수하기가 매우 어려워진다 [1].
+*   **프론트엔드 생태계의 보일러플레이트 감소**:
+    *   **Vue.js**: Vue 3의 Composition API를 도입하면 개발 주기가 단축되며 **보일러플레이트 코드를 30%가량 줄일 수 있다** [2]. 또한, 상태 관리 라이브러리로 기존의 Vuex 대신 Pinia를 사용하면 불필요한 보일러플레이트를 제거하고 타입스크립트 지원을 크게 강화할 수 있다 [3].
+    *   **React**: 기존의 Redux Toolkit처럼 보일러플레이트가 많은 도구 대신, 최근에는 **보일러플레이트가 적은 Zustand나 서버 상태 관리에 특화된 TanStack Query(React Query)가 실전 표준**으로 자리 잡고 있다 [4]. React Query 사용 시 발생하는 중복된 프리페치(prefetch) 등의 보일러플레이트 코드는 별도의 헬퍼 함수로 추출하여 코드를 깔끔하게 유지하는 것이 권장된다 [7].
+*   **백엔드 및 모바일 환경의 자동화 및 추상화**:
+    *   **Spring Boot**: Spring Boot 프레임워크 자체의 핵심 도입 목적 중 하나가 보일러플레이트의 축소이다 [8]. **Lombok 라이브러리**를 사용하여 자바의 반복적인 보일러플레이트 코드를 대폭 줄일 수 있으며 [9, 10], **Spring Data JPA**는 리포지토리 패턴과 쿼리 자동 생성을 통해 데이터베이스 접근에 필요한 보일러플레이트를 크게 제거하여 개발 시간을 단축시킨다 [6, 11]. 또한 Spring Cloud는 분산 시스템 조정에 필요한 보일러플레이트 패턴을 신속하게 구현할 수 있도록 돕는다 [12].
+    *   **React Native**: 새로운 아키텍처(New Architecture) 환경에서는 **Codegen 도구**가 TypeScript나 Flow 타입 정의를 분석하여 JavaScript와 네이티브(Native) 영역을 연결하는 데 필요한 C++ 보일러플레이트 코드를 자동으로 생성해 준다 [5].
+
+## ⚖️ Trade-offs & Caveats
+*   **AI 생성 도구 의존에 따른 일관성 결여 위험**: 최근의 생성형 AI 도구들은 보일러플레이트 코드를 매우 빠르게 생성할 수 있지만, 정해진 템플릿 없이 매번 코드를 새롭게 지어내기 때문에 **코드의 일관성을 보장하지 못한다** [13]. AI가 생성한 보일러플레이트에 과도하게 의존하면 미세한 기능적, 외관상 차이가 발생할 수 있으며, 이로 인해 코드베이스 전체에 걸쳐 일괄적인 패턴 변경이나 리팩토링(예: 글로벌 에러 처리 방식 변경 등)을 수동으로 추적하고 수정해야 하는 치명적인 단점이 발생한다 [13, 14].
+*   **과도한 추상화로 인한 가시성 저하 및 디버깅 난이도 상승**: 보일러플레이트를 없애기 위해 관점 지향 프로그래밍(AOP) 도구나 프레임워크의 자동 구성 기능을 사용할 경우, 코드는 깔끔해지지만 **핵심 로직이 '마법처럼' 숨겨지게 되는 트레이드오프**가 발생한다 [15, 16]. 이는 프로젝트에 새로 합류한 개발자가 코드의 실행 흐름을 파악하기 어렵게 만들며, 런타임 오류나 예상치 못한 동작이 발생했을 때 디버깅의 난이도를 크게 높이는 제약 사항이 된다 [15].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Bounded_Context.md

@@ -0,0 +1,24 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Bounded Context
+description: "Bounded Context(제한된 컨텍스트)는 도메인 주도 설계(DDD)에서 유래한 용어로, 단일하고 응집력 있는 도메인 개념에 매핑되는 코드 조직의 기본 단위를 의미합니다 [1]."
+last_updated: 2026-05-04
+---
+
+# Bounded Context
+
+## 📌 Brief Summary
+Bounded Context(제한된 컨텍스트)는 도메인 주도 설계(DDD)에서 유래한 용어로, 단일하고 응집력 있는 도메인 개념에 매핑되는 코드 조직의 기본 단위를 의미합니다 [1]. 이상적인 Bounded Context는 명확한 단일 책임을 지니며, 내부 로직을 독립적으로 추론할 수 있어야 합니다 [1]. 프레임워크 실전 아키텍처 패턴에서 이는 다른 모듈과의 결합도(coupling)를 최소화하여 시스템의 모듈성 및 유지보수성을 극대화하는 핵심 원리로 작용합니다 [1].
+
+## 📖 Core Content
+* **단일 책임과 독립적 패키징:** 프레임워크(예: Django)에서 Bounded Context로 기능하는 단위(App 등)는 이론적으로 별도의 패키지나 마이크로서비스로 쉽게 추출될 수 있을 만큼 독립적이어야 합니다 [1, 2]. 반면 `utils`, `helpers`, `misc`와 같이 다용도의 의미를 지닌 명명은 단일 도메인 개념을 위반하고 앱이 너무 많은 역할을 수행하고 있다는 경고 신호로 간주됩니다 [1].
+* **모델 소유권과 API를 통한 캡슐화:** 각 Bounded Context는 고유한 데이터 모델을 직접 소유해야 합니다 [3]. 실전 전자상거래 백엔드 사례를 보면, 주문(`orders/`) 컨텍스트가 재고(`inventory/`)를 확인할 때 상대방의 데이터 모델을 직접 임포트하지 않고 반드시 공개된 셀렉터(Selector) API를 통해서만 상호작용하도록 데이터 접근을 격리합니다 [3].
+* **마이크로서비스 경계로의 매핑:** 시스템이 성장함에 따라 잘 분리된 Bounded Context(예: NestJS의 모듈 시스템 등)는 향후 모놀리식 아키텍처를 해체할 때 자연스럽게 마이크로서비스의 경계로 확장 및 매핑될 수 있는 강력한 구조적 기반을 제공합니다 [2].
+
+## ⚖️ Trade-offs & Caveats
+* **경계 식별의 어려움과 복잡성 전가:** 시스템 내에서 Bounded Context의 경계(Boundary)를 올바르게 정의하는 것은 매우 까다로운 작업입니다 [4]. 컴포넌트를 깔끔하게 분리하지 못할 경우, 내부의 복잡성을 해소하지 못한 채 단지 컴포넌트 간의 연결(통신) 지점으로 복잡성만 전가하는 역효과를 초래할 수 있습니다 [4].
+* **직접적인 모델 접근 제약과 간접성 증가:** Bounded Context 간의 독립성을 철저히 보장하기 위해 다른 도메인의 모델을 직접 참조하는 것이 금지됩니다 [3]. 모든 데이터 접근이 퍼블릭 API를 통해서만 이루어져야 하므로 [3], 시스템 내부적으로 간접 호출 계층과 인터페이스가 증가하여 설계 초기의 구현 오버헤드가 발생할 수 있습니다.
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Bridgeless_New_Architecture.md

@@ -0,0 +1,26 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Bridgeless New Architecture
+description: "Bridgeless New Architecture(브릿지리스 신규 아키텍처)는 React Native의 역사상 가장 중요한 변화로, 기존의 비동기 자바스크립트 브릿지에서 발생하던 성능 병목 현상을 해결하기 위해 도입된 혁신적인 구조이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Bridgeless New Architecture
+
+## 📌 Brief Summary
+Bridgeless New Architecture(브릿지리스 신규 아키텍처)는 React Native의 역사상 가장 중요한 변화로, 기존의 비동기 자바스크립트 브릿지에서 발생하던 성능 병목 현상을 해결하기 위해 도입된 혁신적인 구조이다 [1, 2]. 이 아키텍처는 JSI(JavaScript Interface)를 통해 자바스크립트와 네이티브 계층 간의 직접적이고 동기적인 통신을 지원한다 [3, 4]. 결과적으로 데이터 직렬화 오버헤드와 지연 시간(Latency)을 줄이고 UI 반응성을 극대화하여, React Native 앱의 성능을 순수 네이티브 수준에 가깝게 끌어올리는 핵심 역할을 한다 [3-5].
+
+## 📖 Core Content
+*   **비동기 브릿지의 제거 (Elimination of the Bridge):** 과거 React Native의 가장 큰 성능 한계는 자바스크립트의 호출을 네이티브 명령으로 변환할 때 JSON 문자열로 직렬화(serialization)하여 통신하는 비동기 브릿지였다 [1, 6]. 신규 아키텍처(React Native 0.74부터 기본 활성화)는 이 브릿지를 완전히 제거하고, 오버헤드가 없는 보다 직접적이고 효율적인 통신 시스템으로 대체하였다 [1, 4, 6].
+*   **JSI (JavaScript Interface):** 신규 아키텍처의 근간이 되는 JSI는 C++ 기반의 경량 레이어로, 자바스크립트 코드가 네이티브 객체를 직접적이고 동기적으로 참조 및 호출할 수 있게 해준다 [3, 6]. 직렬화 과정을 생략하게 해 주어 스레드 간 실시간에 가까운 고성능 통신을 가능하게 한다 [3, 6].
+*   **패브릭 렌더러 (Fabric Renderer):** 새로운 UI 렌더링 시스템인 패브릭은 C++ 환경에서 섀도 트리(Shadow Tree)를 생성해 스레드 간 공유를 가능하게 한다 [7]. 비동기적인 왕복 과정 없이 네이티브 뷰를 측정하고 렌더링할 수 있어, 동시 렌더링(Concurrent Rendering)과 동기적 레이아웃 계산을 지원하며 UI의 반응성을 대폭 향상시킨다 [6, 7].
+*   **터보모듈 (TurboModules):** 기존에는 앱 시작 시 모든 네이티브 모듈을 초기화해야 했으나, 터보모듈은 차세대 네이티브 모듈 시스템으로서 모듈이 필요할 때만 로드되는 지연 로딩(Lazy loading) 방식을 취한다 [6, 8]. 동기식 네이티브 호출을 지원할 뿐만 아니라, 앱의 초기 시작 시간과 메모리 사용량을 효과적으로 줄여준다 [6, 8].
+*   **코드젠 (Codegen):** 동적 타입의 자바스크립트 환경과 정적 타입의 네이티브 환경(Java/Kotlin, Objective-C/Swift) 간의 안전한 통신을 보장하기 위해 도입되었다 [9]. 빌드 시점에 타입 정의를 분석하여 필요한 C++ 보일러플레이트 코드를 자동 생성하므로, 런타임이 아닌 컴파일 타임에 오류를 잡아내고 전반적인 개발자 경험(DX)을 개선한다 [9].
+
+## ⚖️ Trade-offs & Caveats
+*   **생태계 적응을 위한 과도기:** React Native의 신규 아키텍처는 프레임워크의 기반을 뒤흔드는 거대한 변화이므로, 서드파티 라이브러리 및 패키지들이 새로운 구조(TurboModules, Fabric 등)에 완벽하게 호환되고 채택을 완료할 때까지 일정 시간이 필요하다 [6].
+*   **도입 및 마이그레이션 비용:** 신규 아키텍처가 전면적인 기본값으로 완전히 정착되기 전까지의 이전 버전(예: 0.73) 환경에서는 이를 옵트인(Opt-in) 방식으로 활성화해야 한다 [2]. 앱에 통합된 기존 커스텀 네이티브 모듈이나 특정 라이브러리들이 JSI 기반의 동기적 호출 구조를 지원하지 않을 경우, 이에 대한 마이그레이션이나 검증 작업이 추가로 요구될 수 있다 [2, 6]. 
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Compound_Components.md

@@ -0,0 +1,31 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Compound Components
+description: "복합 컴포넌트(Compound Components) 패턴은 다수의 하위 컴포넌트가 협력하여 하나의 응집된 단일 기능을 수행하도록 설계된 현대 프론트엔드의 대표적인 아키텍처 패턴이다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Compound Components
+
+## 📌 Brief Summary
+복합 컴포넌트(Compound Components) 패턴은 다수의 하위 컴포넌트가 협력하여 하나의 응집된 단일 기능을 수행하도록 설계된 현대 프론트엔드의 대표적인 아키텍처 패턴이다 [1-3]. HTML의 `<select>`와 `<option>` 태그의 관계처럼 개별적으로는 큰 의미가 없지만 함께 사용될 때 유효하며, 부모 컴포넌트가 상태를 제어하고 자식 컴포넌트가 그 상태를 암시적으로 공유하는 방식으로 작동한다 [1, 3]. 이를 통해 불필요한 속성 전달(Prop Drilling)을 방지하고 개발자에게 높은 구조적 유연성과 재사용성을 제공한다 [1-3].
+
+## 📖 Core Content
+* **핵심 메커니즘 및 구조**
+  복합 컴포넌트 패턴은 단일 모놀리식 컴포넌트에 수많은 속성(Props)을 전달해 모든 것을 제어하려는 방식 대신, 조합 가능한 하위 컴포넌트 세트를 제공하여 사용자가 직접 UI를 구성하게 만든다 [1]. 부모 컴포넌트는 React Context를 통해 상태를 암시적으로 공유하며, 하위 컴포넌트들은 이 Context를 읽어와 자신의 렌더링 및 동작을 결정한다 [1, 4].
+
+* **실전 설계 지침 (Best Practices)**
+  * **도트 표기법(Dot-notation) API 활용**: `Tabs.List`, `Tabs.Trigger`와 같이 도트 표기법을 사용하면 컴포넌트들이 함께 사용되도록 의도되었음을 시각적으로 명확히 전달할 수 있다 [4, 5]. 이는 API를 자체 문서화(Self-documenting)하고, 임포트(import)를 깔끔하게 유지해주어 대규모 디자인 시스템 구축의 핵심 기반이 된다 [3, 4].
+  * **안전한 Context 가드 로직**: 하위 컴포넌트가 부모 Context 범위 외부에서 렌더링될 경우, 즉시 명확하고 설명적인 에러를 발생시키는 가드(Guard) 로직을 포함해야 한다 [3-5]. 이는 조용한 실패(Silent failures)를 방지하고 런타임의 예측 가능성을 높인다 [3, 5].
+  * **Context 훅 제공**: 컴포넌트 사용자가 자신만의 커스텀 하위 컴포넌트를 확장하여 구축하고자 할 때를 대비해, 내부에서 사용하는 Context Hook(예: `useTabsContext`)을 함께 Export하는 것이 권장된다 [5].
+
+* **주요 활용 사례**
+  아코디언(Accordion), 모달(Modal), 탭(Tabs), 드롭다운(Dropdown), 선택(Select) 등 부모가 논리를 관리하고 자식이 내용을 정의하는 복잡한 UI 컴포넌트 구현에 이상적이다 [6-8]. Radix UI나 Headless UI와 같은 유명 오픈소스 디자인 시스템에서 표준으로 채택하여 사용하고 있는 패턴이다 [3, 9].
+
+## ⚖️ Trade-offs & Caveats
+* **상태 추적의 난이도 상승**: Context API를 통한 암시적인 상태 공유는 코드를 깔끔하게 만들어주지만, 반대로 명시적인 Props 전달이 없기 때문에 데이터 흐름을 직관적으로 파악하기 어려워져 컴포넌트 간 상태 추적 난이도가 상승할 수 있다 [8].
+* **오버엔지니어링의 위험성**: 모든 컴포넌트를 복합 컴포넌트로 만들 필요는 없다. 몇 개의 Props만으로 충분히 제어할 수 있는 단순한 컴포넌트(예: 기본 Button)에 이 패턴을 적용하는 것은 불필요한 복잡성만 더하는 일이다 [9]. 이 패턴은 여러 자식 간에 상태를 공유해야 하거나 사용자에게 UI 유연성을 반드시 제공해야 하는 "진정한 복잡성"이 존재하는 경우에만 제한적으로 적용하는 것이 바람직하다 [8, 9].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Computed_Properties_&_Watchers.md

@@ -0,0 +1,28 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Computed Properties & Watchers
+description: "Computed Properties와 Watchers는 Vue 3 Composition API에서 파생된 상태를 관리하고 데이터 변경에 대응하기 위한 필수적인 도구입니다 [1]."
+last_updated: 2026-05-04
+---
+
+# Computed Properties & Watchers
+
+## 📌 Brief Summary
+Computed Properties와 Watchers는 Vue 3 Composition API에서 파생된 상태를 관리하고 데이터 변경에 대응하기 위한 필수적인 도구입니다 [1]. Computed Properties는 반응형 데이터에 기반해 값을 계산하고 캐시(cache)하는 반면, Watchers는 데이터 변경 시 특정 액션이나 비동기 작업 등의 부수 효과(side effects)를 처리하는 데 사용됩니다 [1, 2].
+
+## 📖 Core Content
+* **Computed Properties (계산된 속성)**
+  * 반응형 데이터(reactive data)로부터 파생된 값을 생성하는 데 최적화되어 있습니다 [1].
+  * 결과값을 자동으로 캐시하며, 의존하고 있는 데이터가 변경될 때만 다시 계산을 수행하므로 데이터 필터링이나 총계 계산과 같은 작업에 이상적입니다 [1].
+  * `computed()`를 사용하여 생성된 반응형 상태는 여러 컴포넌트 인스턴스 간에 공유하여 사용할 수도 있습니다 [3].
+
+* **Watchers (감시자)**
+  * 반응형 데이터의 변경이 발생했을 때 API 호출과 같은 특정 액션을 트리거하기 위해 사용됩니다 [2].
+  * 비동기 작업(asynchronous tasks)이나 부수 효과를 처리하는 목적에 특히 유용하게 활용됩니다 [2].
+
+## ⚖️ Trade-offs & Caveats
+소스에 관련 정보가 부족합니다.
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Constructor_Injection.md

@@ -0,0 +1,24 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Constructor Injection
+description: "Constructor Injection(생성자 주입)은 클래스의 생성자를 통해 객체가 필요로 하는 의존성을 명시적으로 선언하고 프레임워크로부터 해당 객체를 제공받는 의존성 주입(DI) 방식입니다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Constructor Injection
+
+## 📌 Brief Summary
+Constructor Injection(생성자 주입)은 클래스의 생성자를 통해 객체가 필요로 하는 의존성을 명시적으로 선언하고 프레임워크로부터 해당 객체를 제공받는 의존성 주입(DI) 방식입니다 [1-3]. 모던 Spring Boot와 NestJS 같은 최신 엔터프라이즈 프레임워크에서 가장 선호되고 권장되는 접근법입니다 [1, 2]. 이 방식을 사용하면 수동으로 객체를 생성하거나 연결할 필요 없이, 프레임워크가 의존성을 자동으로 감지하고 인스턴스화하여 주입합니다 [2, 3].
+
+## 📖 Core Content
+*   **프레임워크의 자동 의존성 해결**: Spring Boot와 NestJS와 같은 프레임워크에서는 클래스 생성자에 필요한 의존성을 선언하기만 하면 됩니다 [1, 2]. 프레임워크의 제어 역전(IoC) 혹은 DI 컨테이너가 생성자를 감지하여 알맞은 빈(Bean)이나 프로바이더를 자동으로 주입하므로, 팩토리 메서드나 수동 배선(manual wiring) 코드를 생략할 수 있습니다 [2].
+*   **결합도 완화와 구조적 명확성**: 의존성을 내부에서 직접 인스턴스화하거나 하드 코딩하여 임포트하는 대신, 생성자를 통해 외부에서 주입받는 방식을 취합니다 [1]. 이러한 접근은 컴포넌트 간의 강한 결합도를 낮추고 시스템을 더 유연하게 만듭니다 [1, 3]. 
+*   **테스트 가능성(Testability) 극대화**: 생성자 주입의 가장 큰 기술적 이점은 단위 테스트의 용이성입니다 [1, 3]. 테스트 과정에서 비즈니스 로직을 전혀 변경하지 않고도, 생성자의 인자를 통해 실제 서비스 대신 모의 객체(Mock)를 손쉽게 교체하여 주입할 수 있어 독립적이고 격리된 테스트 환경을 구축하기 매우 수월해집니다 [1].
+
+## ⚖️ Trade-offs & Caveats
+*   **기반 클래스(Base Class) 상속 시의 관리 부담**: 상속을 활용해 기반 클래스에 공통 로직을 구성할 때 의존성이 개입되면, 이를 상속받는 모든 하위 구현체의 생성자에 해당 의존성을 전달하도록 코드를 작성해야 하는 제약과 부담이 발생합니다 [4].
+*   **의존성 변경에 따른 연쇄 수정 비용**: 위의 상속 구조 등에서 새로운 의존성이 추가되는 설계 변경이 발생할 경우, 기반 클래스를 상속받는 모든 하위 클래스의 생성자 서명(Signature)을 일일이 찾아 수정해야 하는 유지보수 상의 비용과 번거로움이 발생할 수 있습니다 [4].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Context_API.md

@@ -0,0 +1,36 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Context API
+description: "Context API는 React 애플리케이션에서 컴포넌트 트리를 따라 매번 수동으로 props를 전달해야 하는 'Prop Drilling' 문제를 해결하고 데이터를 효율적으로 공유할 수 있게 해주는 기능이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Context API
+
+## 📌 Brief Summary
+Context API는 React 애플리케이션에서 컴포넌트 트리를 따라 매번 수동으로 props를 전달해야 하는 'Prop Drilling' 문제를 해결하고 데이터를 효율적으로 공유할 수 있게 해주는 기능이다 [1]. 테마 설정이나 사용자 데이터와 같이 깊게 중첩된 컴포넌트 간에 상태를 공유해야 할 때 주로 사용된다 [2]. 특히 복합 컴포넌트(Compound Components) 패턴과 결합하여, 하위 컴포넌트들이 부모로부터 명시적인 props 전달 없이도 상태를 암시적으로 공유할 수 있도록 지원하는 핵심 기술로 활용된다 [3].
+
+## 📖 Core Content
+* **Prop Drilling 해결 및 상태 공유**
+  Context API는 깊게 중첩된 컴포넌트에 데이터를 전달할 때 중간 컴포넌트들을 거치지 않고 직접 값을 전달할 수 있게 해준다 [1]. `React.createContext()`를 이용해 컨텍스트를 생성하고, `<Context.Provider value={...}>`를 통해 데이터를 공급하며, 하위 컴포넌트에서는 `useContext()` 훅을 사용하여 해당 데이터를 소비하는 방식으로 구현된다 [1].
+
+* **복합 컴포넌트(Compound Components) 패턴의 기반**
+  Context API는 탭(Tabs)이나 드롭다운(Dropdown)과 같이 여러 컴포넌트가 하나의 응집된 단위로 협력하는 복합 컴포넌트 패턴의 뼈대가 된다 [3, 4]. 자위 컴포넌트들이 활성화된 값(activeValue) 등을 수동으로 전달받지 않고 Context를 통해 읽어오므로, 사용자가 유연하게 컴포넌트 구조를 제어할 수 있는 API 설계가 가능해진다 [5]. 
+
+* **안전한 Context 소비를 위한 가드(Guard) 패턴**
+  하위 컴포넌트들이 부모 Context Provider 외부에서 실수로 사용될 경우를 대비해 보호 장치를 마련하는 것이 권장된다 [5]. 예를 들어 `useTabsContext()`와 같은 훅 안에서 Context 값을 확인하고, 값이 없다면 개발자에게 명확한 설명이 담긴 에러를 던지게 함으로써 런타임 오류와 헷갈리는 버그를 방지할 수 있다 [5].
+
+## ⚖️ Trade-offs & Caveats
+* **기본값 가드 누락에 따른 디버깅 어려움**
+  Context를 생성할 때 올바른 기본값이나 방어 로직(Default Value Guard) 없이 사용하면, 컴포넌트가 Provider 외부에서 렌더링될 때 오류의 원인을 파악하기 힘든 조용한 실패(Silent failure)를 겪을 수 있다 [6]. 
+
+* **React 서버 컴포넌트(RSC) 아키텍처에서의 클라이언트 경계(Client Boundary) 문제**
+  Context API는 React 상태 메커니즘을 사용하므로 서버 컴포넌트에서는 동작할 수 없으며, 필연적으로 클라이언트 컴포넌트(`'use client'`)에서 사용되어야 한다 [7]. 만약 트리 상단에서 Context를 사용하면 하위 컴포넌트들까지 암시적으로 모두 클라이언트 컴포넌트로 취경되는 문제가 발생한다 [7, 8]. 이를 우회하기 위해서는 Context Provider 로직만 별도의 파일로 분리하고, 부모 컴포넌트에서 하위 컴포넌트들을 `children` 프로프(prop)로 넘겨받도록 구조를 리팩토링해야 한다 [8-10].
+
+* **SSR 환경에서의 민감한 데이터 노출 위험**
+  서버사이드 렌더링(SSR) 시 인증 토큰이나 쿠키와 같은 민감한 정보를 클라이언트 컴포넌트에서 사용하기 위해 React Context에 넣게 되면, 이 정보가 클라이언트 번들에 노출되는 보안 문제가 발생할 수 있다 [11]. 이를 방지하려면 데이터를 암호화하여 서버에서만 해독되도록 처리하는 별도의 우회 기법이 필요하다 [11, 12].
+
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Cross-Cutting_Concerns_AOP.md

@@ -0,0 +1,34 @@
+---
+category: Computer_Science_and_Theory
+tags: [auto-wikified, technical-documentation, computer_science_and_theory]
+title: Cross-Cutting Concerns (AOP)
+description: "**횡단 관심사(Cross-Cutting Concerns)**는 로깅, 보안, 캐싱, 예외 처리 등 소프트웨어의 여러 계층과 컴포넌트 전반에 걸쳐 공통으로 요구되는 부차적이고 시스템적인 기능을 의미합니다 [1-4]."
+last_updated: 2026-05-04
+---
+
+# Cross-Cutting Concerns (AOP)
+
+## 📌 Brief Summary
+**횡단 관심사(Cross-Cutting Concerns)**는 로깅, 보안, 캐싱, 예외 처리 등 소프트웨어의 여러 계층과 컴포넌트 전반에 걸쳐 공통으로 요구되는 부차적이고 시스템적인 기능을 의미합니다 [1-4]. 이러한 관심사를 핵심 비즈니스 로직과 분리하여 모듈화하는 방법론이 **관점 지향 프로그래밍(AOP, Aspect-Oriented Programming)**입니다 [1, 5]. 이를 적절하게 중앙 집중화하지 않으면 코드의 중복과 강한 결합을 초래하여 대규모 애플리케이션의 유지보수성을 심각하게 저하시킬 수 있습니다 [1, 6].
+
+## 📖 Core Content
+* **개념 및 필요성**
+  애플리케이션의 비즈니스 로직이 '핵심 관심사(Core Concerns)'라면, 트랜잭션 관리, 로깅, 유효성 검사 등은 시스템 전체에 적용되어야 하는 '횡단 관심사'로 분류됩니다 [2, 7-10]. 이러한 횡단 관심사를 각 메서드 내부에 하드코딩하면 '단일 책임 원칙(SRP)'과 '반복 방지(DRY)' 원칙을 위반하게 되어 코드가 심하게 오염됩니다 [11]. AOP는 이러한 로직을 한 곳으로 추출하여 각 모듈에 선언적으로 주입합니다 [5, 7].
+
+* **프레임워크별 실전 구현 패턴**
+  현대 백엔드 프레임워크들은 횡단 관심사 분리를 위해 각자의 설계 철학에 맞는 메커니즘을 제공합니다 [12].
+  * **Spring Boot (Java)**: AOP(AspectJ), 필터(Filter), 인터셉터(Interceptor)를 혼합하여 사용합니다 [12, 13]. 필터는 서블릿 레벨에서 모든 HTTP 요청(CORS, 기본 인증 등)을 가로채고, 인터셉터는 MVC 컨트롤러 실행 전후를 처리합니다 [14, 15]. AOP는 `@Aspect`, `@Before` 어노테이션 등을 통해 서비스나 리포지토리 등 어떤 Spring Bean의 메서드든 가로채어 트랜잭션이나 로깅을 비즈니스 로직 변경 없이 적용할 수 있습니다 [16, 17].
+  * **NestJS (Node.js)**: 가드(Guard), 인터셉터(Interceptor), 파이프(Pipe), 미들웨어(Middleware)로 구성된 파이프라인 형태의 흐름 제어를 제공합니다 [12]. 특히 RxJS 스트림을 활용하여 비동기 작업을 유연하게 처리할 수 있는 일관된 구조를 지원합니다 [12].
+  * **기타 아키텍처 패턴**: .NET 중심의 클린 아키텍처에서는 MediatR의 `IPipelineBehavior`를 통해 파이프라인 내부에서 로깅, 캐싱, 유효성 검사를 독립된 단위로 캡슐화합니다 [18-20]. 
+
+* **주요 적용 사례**
+  * **트랜잭션 관리 (Transaction Management)**: 수많은 `try-catch`와 커밋/롤백 블록을 하드코딩하는 대신, AOP 어드바이스 마커를 활용해 트랜잭션 동작을 캡슐화함으로써 코드를 간결하게 유지합니다 [7].
+  * **로깅 및 예외 처리**: 애플리케이션 전반에 흩어진 추적(Tracing) 및 로깅 코드를 걷어내고, 인터셉터나 파이프라인을 통해 전역 예외 처리 및 로깅을 중앙 집중화합니다 [19, 21].
+
+## ⚖️ Trade-offs & Caveats
+* **마법 같은 동작(Magic)과 디버깅의 한계**: AOP나 미들웨어 파이프라인은 코드를 런타임에 래핑하거나 컴파일 시점에 동적으로 로직을 주입하므로, 비즈니스 코드와 인프라 코드를 깔끔하게 분리합니다 [22, 23]. 그러나 명시적으로 호출되는 코드가 없기 때문에 **실행 흐름이 불투명**해지며, 특정 로직이 왜 실행되는지 파악하기 어려워 디버깅 난이도가 급격히 상승할 수 있습니다 [22, 23]. 이는 Django의 Signals를 남용할 때 부수 효과(Side Effects)를 추적하기 어려워지는 안티 패턴과 유사한 기술 부채를 유발할 수 있습니다 [24, 25].
+* **런타임 성능 오버헤드**: C#의 Castle.DynamicProxy와 같은 런타임 인터셉터 방식은 실행 시점에 프록시 래퍼를 동적으로 생성하여 메서드 호출을 가로챕니다 [26]. 이는 로깅과 같이 매우 빈번하게 발생하는 작업에 무분별하게 적용할 경우, 애플리케이션에 성능 비용(Cost)을 초래할 수 있습니다 [26].
+* **설계 복잡성과 종속성 문제**: 횡단 관심사 로직을 공유하기 위해 '기반 클래스(Base Class)' 상속 패턴을 남용하면, 다중 상속 제약에 부딪히거나 모든 하위 클래스 생성자에 인프라 종속성을 넘겨주어야 하는 유지보수 문제가 발생합니다 [27, 28]. 인프라 컴포넌트(예: Logger 객체)가 시스템의 필수 종속성으로 강제되지 않도록 DI 생명주기(예: Transient 할당 지양)를 신중히 설정해야 합니다 [5].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Cross-platform_Mobile_Development_Frameworks.md

@@ -0,0 +1,42 @@
+---
+category: Other
+tags: [auto-wikified, technical-documentation, other]
+title: Cross-platform Mobile Development Frameworks
+description: "크로스 플랫폼 모바일 개발 프레임워크는 단일 코드베이스를 사용하여 iOS 및 Android와 같은 다수의 플랫폼에서 실행되는 애플리케이션을 구축할 수 있게 해주는 도구입니다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Cross-platform Mobile Development Frameworks
+
+## 📌 Brief Summary
+크로스 플랫폼 모바일 개발 프레임워크는 단일 코드베이스를 사용하여 iOS 및 Android와 같은 다수의 플랫폼에서 실행되는 애플리케이션을 구축할 수 있게 해주는 도구입니다 [1-3]. 2025년 현재 시장을 주도하는 두 가지 주요 프레임워크는 Meta가 지원하는 **React Native**와 Google이 지원하는 **Flutter**입니다 [4-6]. 이 기술들은 플랫폼별로 따로 코드를 작성하는 기존 네이티브 개발 방식에 비해 개발 시간과 비용을 크게 줄이면서도 네이티브에 준하는 뛰어난 성능과 사용자 경험을 제공합니다 [1, 7, 8].
+
+## 📖 Core Content
+**1. 렌더링 철학과 아키텍처**
+*   **Flutter (자체 렌더링 엔진):** Dart 언어를 기반으로 하며, Skia 또는 최신 Impeller 렌더링 엔진을 통해 화면의 모든 픽셀을 직접 그립니다 [8-11]. 이는 플랫폼의 네이티브 UI 컴포넌트에 의존하지 않으므로, 모든 디바이스와 OS에서 "픽셀 퍼펙트(Pixel-perfect)"한 일관된 브랜드 경험을 제공합니다 [9, 10, 12].
+*   **React Native (네이티브 브릿지 및 JSI):** JavaScript/TypeScript를 사용하며 코드를 실제 플랫폼의 네이티브 UI 컴포넌트(iOS의 UIView, Android의 View)로 변환하여 렌더링합니다 [10, 13, 14]. 최근에는 비동기 브릿지(Bridge) 방식의 병목을 해결하기 위해 '새로운 아키텍처(New Architecture)'를 도입했습니다. JSI(JavaScript Interface), Fabric, TurboModules를 통해 JavaScript와 네이티브 레이어 간의 동기식 직접 통신을 가능하게 하여 성능을 극대화했습니다 [12, 15-20].
+
+**2. 개발 경험(DX) 및 에코시스템**
+*   **React Native:** 세계에서 가장 널리 쓰이는 JavaScript 생태계를 그대로 활용할 수 있어 인재 확보와 코드 공유(웹/모바일) 측면에서 압도적인 전략적 우위를 가집니다 [21-23]. 특히 EAS(Expo Application Services), Expo Router 등을 제공하는 **Expo 에코시스템**은 복잡한 네이티브 빌드 구성을 추상화하여 프로덕션 수준의 워크플로우를 극도로 단순화시킵니다 [24-27].
+*   **Flutter:** 고도로 통합된 자체 도구 모음을 제공합니다 [25]. 상태 보존 핫 리로드(Hot Reload), 광범위한 내장 위젯 시스템, 통합된 DevTools(UI 검사기, 성능 프로파일러 등)를 통해 매우 빠른 UI 개발 주기를 보장합니다 [28-31].
+
+**3. 성능 및 최신 발전**
+*   두 프레임워크 모두 최적화 시 60fps 이상의 부드러운 성능을 제공합니다 [32]. 
+*   Flutter는 '셰이더 컴파일 정크(Shader compilation jank)' 문제를 해결하기 위해 런타임이 아닌 빌드 타임에 셰이더를 사전 컴파일하는 **Impeller 엔진**을 도입하여 첫 프레임부터 매끄러운 성능을 보장합니다 [11, 33]. 
+*   React Native 역시 브릿지를 제거한 새로운 아키텍처를 통해 Flutter와의 성능 격차를 사실상 없앴으며, 고도화된 인터랙션에서도 네이티브와 구분하기 힘든 성능을 냅니다 [34-36].
+
+**4. AI 및 머신러닝 통합**
+*   Flutter는 Google 생태계의 이점을 살려 Firebase AI Logic(Gemini) 및 TensorFlow Lite와의 깊고 원활한 자사(First-party) 통합을 제공합니다 [37, 38].
+*   React Native는 광범위한 커뮤니티 기반 아래 `react-native-fast-tflite`, `react-native-ai` 등 다양한 서드파티 라이브러리를 통해 LLM 및 온디바이스 ML 통합에 있어 유연하고 폭넓은 선택지를 제공합니다 [37, 39].
+
+## ⚖️ Trade-offs & Caveats
+**React Native의 제약 및 트레이드오프:**
+*   **유지보수 비용 및 플랫폼 파편화:** 실제 네이티브 UI 컴포넌트에 의존하기 때문에, iOS나 Android OS가 업데이트되면서 기본 모듈이 독자적으로 진화할 경우 플랫폼별 수정 사항이 발생할 수 있습니다 [40]. 이는 시간이 지남에 따라 유지보수 비용을 증가시키는 요인이 됩니다 [41, 42].
+*   **서드파티 의존성:** JavaScript 생태계의 방대한 라이브러리를 사용할 수 있지만, 품질이 고르지 않고 OS 업데이트에 따른 호환성 문제가 발생할 수 있어 지속적인 종속성 관리(Dependency Management)가 요구됩니다 [43-45].
+
+**Flutter의 제약 및 트레이드오프:**
+*   **네이티브 동작의 모방:** 네이티브 UI 컴포넌트를 사용하지 않고 자체 엔진으로 화면을 그리기 때문에, 스크롤 물리 효과나 텍스트 선택 등 운영체제 특유의 미묘한 동작이나 접근성(Accessibility) 의미를 100% 동일하게 구현하려면 추가적인 세밀한 조정이 필요합니다 [10, 46-48].
+*   **앱 크기 및 인재 풀:** Dart 런타임과 Impeller 렌더링 엔진을 앱과 함께 배포해야 하므로, React Native에 비해 앱의 기본 번들(APK 등) 크기가 더 큽니다 [9, 32, 49]. 또한, Dart 언어를 사용하는 개발자 풀이 JavaScript에 비해 작기 때문에 초기 인력 채용 및 팀 확장에 어려움이 따를 수 있습니다 [21, 50, 51].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Custom_Hooks.md

@@ -0,0 +1,35 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Custom Hooks
+description: "커스텀 훅(Custom Hooks)은 React 애플리케이션에서 상태 기반 로직을 추출하여 컴포넌트 간에 쉽게 공유할 수 있도록 고안된 함수형 디자인 패턴입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Custom Hooks
+
+## 📌 Brief Summary
+커스텀 훅(Custom Hooks)은 React 애플리케이션에서 상태 기반 로직을 추출하여 컴포넌트 간에 쉽게 공유할 수 있도록 고안된 함수형 디자인 패턴입니다 [1, 2]. `use`로 시작하는 명명 규칙을 따르며, 내부에 다른 React 훅들을 호출하여 새로운 맞춤형 기능을 조립할 수 있습니다 [1, 3]. 기존의 고차 컴포넌트(HOC)나 렌더 프로프(Render Props)가 유발하던 불필요한 컴포넌트 중첩(Wrapper Hell)을 제거하고, 함수 합성을 통해 깔끔하게 로직을 재사용할 수 있게 해줍니다 [1, 4].
+
+## 📖 Core Content
+* **상태 기반 로직의 캡슐화 및 재사용**:
+  커스텀 훅은 API 데이터 페칭, 폼 상태 관리, 반응형 디자인 등 UI 렌더링과 직접적인 관련이 없는 순수 비즈니스 및 상태 로직을 캡슐화하는 데 사용됩니다 [2, 5]. 이를 통해 여러 컴포넌트 사이에서 코드를 DRY(Don't Repeat Yourself)하게 유지하고 깔끔한 코드베이스를 작성할 수 있습니다 [5].
+* **함수 합성(Function Composition)을 통한 확장**:
+  복잡한 행위들을 단순한 형태의 훅으로 쪼개고 이를 다시 합성하여 강력한 기능을 구현할 수 있습니다 [1, 6]. 예를 들어, 디바운싱 로직을 다루는 `useDebounce`와 데이터를 가져오는 `useFetch`, 검색 로직을 다루는 `useSearch`를 각각 만들고, 이들을 하나의 훅에서 조합하여 효율적으로 관리할 수 있습니다 [1, 6].
+* **타입스크립트(TypeScript)와의 시너지**:
+  타입스크립트의 제네릭(Generics)을 커스텀 훅에 적용하면(`useFetch<T>` 등) 재사용성을 희생하지 않으면서도 강력한 타입 안전성(Type Safety)을 얻을 수 있습니다 [7]. 이는 엔터프라이즈 환경의 대규모 프로젝트에서 안전하고 견고한 코드를 구축하는 핵심 요소로 평가받습니다 [2, 8].
+* **독립적인 테스트와 관심사 분리**:
+  각 커스텀 훅은 하나의 책임만을 가지도록 집중적으로 설계해야 합니다 [3]. 추출된 훅은 특정 UI에 종속되지 않기 때문에 `@testing-library/react`의 `renderHook`과 같은 도구를 사용하여 독립적이고 쉽게 테스트할 수 있습니다 [3, 8].
+* **필수적인 설계 모범 사례(Best Practices)**:
+  훅을 작성할 때는 React 린팅 규칙이 의존하는 `use` 접두사를 반드시 사용해야 합니다 [3]. 다운스트림의 메모이제이션이 깨지는 것을 막기 위해 `useCallback`과 `useMemo`를 이용해 반환되는 참조를 안정적으로 유지하는 것이 중요합니다 [3]. 또한 이벤트나 외부 자원을 구독할 때에는 `useEffect`에서 항상 클린업(cleanup) 함수를 반환하여 누수를 방지해야 합니다 [3].
+
+## ⚖️ Trade-offs & Caveats
+* **엄격한 훅의 규칙(Rules of Hooks) 강제**: 
+  커스텀 훅을 사용할 때는 React의 훅 규칙을 반드시 준수해야 한다는 문법적, 구조적 제약이 따릅니다 [2, 9]. 이를 어길 경우 런타임 오류나 예상치 못한 상태 오류가 발생할 수 있습니다 [5].
+* **오래된 클로저(Stale Closure) 문제**: 
+  `useEffect` 등과 함께 커스텀 훅을 구현할 때, 참조되는 모든 값을 의존성 배열(dependency array)에 올바르게 명시하지 않으면 함수가 과거의 렌더링 변수 값에 갇히는 '오래된 클로저' 현상이 발생합니다 [7]. 변경 추적이 아닌 호출 시점에만 읽혀야 하는 값들은 `ref`를 사용해 우회해야 합니다 [7].
+* **성능 최적화 오용(Vibe Coding)의 함정**: 
+  성능을 개선한다는 맹목적인 믿음 하에 객관적인 성능 측정 없이 `useCallback`이나 `useMemo` 등을 무분별하게 추가하면 오히려 디버깅을 어렵게 만들고, 컴포넌트의 성능을 악화시키는 부작용을 초래할 수 있습니다 [10, 11].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Dart.md

@@ -0,0 +1,24 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Dart
+description: "Dart는 구글이 개발한 정적 타입 기반의 객체 지향 프로그래밍 언어로, 주로 크로스 플랫폼 프레임워크인 Flutter의 기반 언어로 사용됩니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Dart
+
+## 📌 Brief Summary
+Dart는 구글이 개발한 정적 타입 기반의 객체 지향 프로그래밍 언어로, 주로 크로스 플랫폼 프레임워크인 Flutter의 기반 언어로 사용됩니다 [1, 2]. 클라이언트 환경에 최적화되어 있으며 기계어(ARM 코드)로 직접 컴파일되어 빠른 앱 실행과 높은 성능을 제공하는 것이 특징입니다 [2-4]. Java, C# 등 기존 객체 지향 언어와 유사한 문법을 가져 해당 언어 경험이 있는 개발자들에게는 학습이 비교적 수월한 편입니다 [5].
+
+## 📖 Core Content
+* **언어 아키텍처 및 성능 최적화:** Dart는 가비지 컬렉션(Garbage Collection)과 강력한 비동기(Async) 처리를 지원하며, AOT(Ahead-of-Time)와 JIT(Just-in-Time) 컴파일 방식을 모두 제공합니다 [6, 7]. 특히 모바일 환경에서는 AOT 컴파일을 통해 네이티브 ARM 코드로 변환되므로 애플리케이션의 콜드 스타트(Cold Start) 속도가 매우 빠릅니다 [4, 8]. 
+* **정적 타입 시스템과 최신 문법:** Dart는 정적 타입(Static Type) 시스템을 사용하여 개발 단계 및 컴파일 타임에 오류를 사전에 포착함으로써 애플리케이션을 더 안정적이고 예측 가능하게 만듭니다 [9]. Dart 3 버전에 이르러서는 기본적으로 견고한 널 안전성(Sound Null Safety)을 지원하며, 봉인 클래스(Sealed Classes), 패턴 매칭, 레코드(Records)를 비롯하여 와일드카드 변수, 널 인지 컬렉션 요소 등의 최신 언어 기능을 도입하여 코드의 견고함과 표현력을 더욱 향상시켰습니다 [10, 11].
+* **Flutter 생태계와의 결합 및 상호 운용성:** Dart는 Flutter 엔진(Skia 또는 Impeller)을 구동하는 핵심으로, 네이티브에 근접한 수준의 애플리케이션 성능과 고도의 커스텀 UI 제어를 가능하게 합니다 [7, 11]. 또한 성능이 중요한 작업이 필요할 경우, Dart FFI(Foreign Function Interface)를 통해 C 언어 라이브러리를 직접 호출하여 통신할 수 있는 상호 운용성도 제공합니다 [12, 13].
+
+## ⚖️ Trade-offs & Caveats
+* **제한적인 인재 풀 및 높은 채용/교육 비용:** JavaScript 등 주류 언어에 비해 Dart를 다루는 개발자(전체 개발자의 약 25% 수준)가 제한적이어서 특화된 인재 확보가 다소 어렵습니다 [14, 15]. 이로 인해 채용 시 10~15%의 급여 프리미엄이 발생하거나, 기존 개발자를 교육하여 프로젝트에 투입하는 데 적지 않은 시간과 비용($8,000~$12,000 상당)이 요구될 수 있습니다 [14, 16].
+* **상대적으로 작은 커뮤니티 규모:** 널리 사용되는 JavaScript 생태계에 비해 커뮤니티 규모가 작기 때문에, 스택 오버플로우나 기술 블로그 등에서 문제 해결을 위한 참고 자료나 코드 리뷰를 얻을 기회가 적을 수 있습니다 [6, 17]. 이는 기존에 Dart를 다뤄보지 않은 웹 기반 개발팀이 진입할 때 초기 학습 곡선을 가파르게 만드는 원인이 됩니다 [6, 18]. 
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Dart_FFI_Foreign_Function_Interface.md

@@ -0,0 +1,23 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Dart FFI (Foreign Function Interface)
+description: "Dart FFI(Foreign Function Interface)는 Flutter 개발 환경에서 C 라이브러리를 직접 호출할 수 있도록 지원하는 외부 함수 인터페이스입니다 [1]."
+last_updated: 2026-05-04
+---
+
+# Dart FFI (Foreign Function Interface)
+
+## 📌 Brief Summary
+Dart FFI(Foreign Function Interface)는 Flutter 개발 환경에서 C 라이브러리를 직접 호출할 수 있도록 지원하는 외부 함수 인터페이스입니다 [1]. 주로 네이티브 API에 접근하거나 성능이 결정적인 역할을 하는 작업을 처리할 때 사용됩니다 [1, 2]. 기존의 비동기 메시지 패싱 방식인 플랫폼 채널(Platform Channels)과 더불어 모바일 앱의 커스텀 네이티브 기능을 구현하는 데 핵심적인 역할을 합니다 [1].
+
+## 📖 Core Content
+* **직접적인 C 언어 상호 운용성(C Interop)**: 애플리케이션 개발 중 커스텀 네이티브 코드가 필요한 경우, Dart FFI를 통해 C 라이브러리를 직접 호출하여 네이티브 API에 접근할 수 있습니다 [1, 2].
+* **고성능 작업(Performance-critical operations) 처리**: Dart FFI는 높은 성능을 요구하는 연산에서 C 코드와의 직접적인 통합을 가능하게 하여, 성능이 중요한 작업을 효과적이고 안정적으로 처리할 수 있도록 보장합니다 [2].
+* 소스에 관련 정보가 부족하여 세부적인 내부 작동 방식이나 아키텍처 구현 패턴에 대한 추가적인 설명은 제한됩니다.
+
+## ⚖️ Trade-offs & Caveats
+소스에 관련 정보가 부족합니다. (제공된 소스 데이터에서는 Dart FFI 도입으로 인해 발생할 수 있는 구체적인 부작용, 제약 사항, 또는 최적화 과정의 반대 급부에 대한 정보를 포함하고 있지 않습니다.)
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Decorators.md

@@ -0,0 +1,27 @@
+---
+category: Other
+tags: [auto-wikified, technical-documentation, other]
+title: Decorators
+description: "데코레이터(Decorators)는 클래스, 메서드, 프로퍼티 등에 메타데이터를 추가하여 동작을 정의하거나 의존성을 주입하는 설계 패턴 및 문법적 기능입니다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Decorators
+
+## 📌 Brief Summary
+데코레이터(Decorators)는 클래스, 메서드, 프로퍼티 등에 메타데이터를 추가하여 동작을 정의하거나 의존성을 주입하는 설계 패턴 및 문법적 기능입니다 [1-3]. 특히 NestJS와 같은 프레임워크에서 모듈, 컨트롤러, 서비스를 구성하는 핵심 아키텍처 요소로 활용되며 [3], 애플리케이션의 횡단 관심사(Cross-Cutting Concerns)를 비즈니스 로직과 분리하여 제어하는 데 유용하게 쓰입니다 [4, 5].
+
+## 📖 Core Content
+* **NestJS의 핵심 아키텍처 요소**: NestJS는 타입스크립트 데코레이터(`@Module()`, `@Controller`, `@Get`, `@Injectable` 등)를 적극적으로 사용하여 애플리케이션의 의존성 주입(DI) 컨테이너를 구성합니다 [2, 3, 6, 7]. 모듈은 `@Module()`로 주석이 달린 클래스이며, 프레임워크는 이를 통해 애플리케이션의 구조와 관계를 파악합니다 [2].
+* **데이터 모델링 및 문서 자동화**: DTO(Data Transfer Object)나 엔티티(Entity) 클래스에 데코레이터를 적용하여 TypeORM, Prisma, Drizzle 등의 ORM과 연동할 수 있습니다 [1]. 또한, 데코레이터와 DTO를 기반으로 Swagger/OpenAPI 문서를 실제 코드와 동기화하여 자동 생성하는 기능도 제공합니다 [8, 9].
+* **GraphQL 스키마 생성**: NestJS의 `@nestjs/graphql` 모듈에서는 데코레이터를 활용한 코드 우선(Code-first) 접근 방식을 지원합니다 [10]. 클래스에 데코레이터를 추가하는 것만으로 GraphQL 타입과 스키마를 자동으로 생성할 수 있습니다 [11].
+* **횡단 관심사(Cross-Cutting Concerns)의 분리**: 도메인 로직과 무관한 인프라 측면의 기능(로깅, 인증, 캐싱 등)을 분리할 때 데코레이터가 활용됩니다 [4]. 예를 들어, Django 프로젝트에서는 커스텀 권한(permissions)을 처리하거나 미들웨어와 함께 횡단 관심사의 흐름을 제어하기 위해 데코레이터를 설계 패턴으로 적용합니다 [5, 12].
+
+## ⚖️ Trade-offs & Caveats
+* **학습 곡선의 증가**: Express와 같이 제약이 적고 단순한 미니멀리즘 프레임워크에 익숙한 개발자에게는 데코레이터, 의존성 주입(DI), 모듈 시스템 등의 개념이 낯설 수 있으며 이를 익히기 위한 초기 학습 곡선이 가파릅니다 [6, 9].
+* **프레임워크 오버헤드**: NestJS의 경우 데코레이터와 의존성 주입(DI) 계층으로 인해 순수한 Express에 비해 약 10~15% 정도의 처리량(Throughput) 감소라는 성능 오버헤드가 발생합니다 [13]. 다만, 프로덕션 환경의 데이터베이스 쿼리나 네트워크 지연 시간에 비하면 이는 대부분 무시할 수 있는 수준입니다 [13].
+* **과도한 보일러플레이트 작성**: 소규모 팀이나 간단한 프로젝트에서는 모듈을 선언하고, DTO를 만들고, 엔티티에 데코레이터를 부착하는 구조화 작업 자체가 실제 비즈니스 로직 작성보다 더 많은 시간과 비용을 요구하는 기술 부채(Technical Debt)나 과잉 엔지니어링이 될 수 있습니다 [14, 15].
+* **전역 남용의 위험**: NestJS에서 교차 절단 관심사에 `@Global()` 데코레이터를 사용할 수 있지만, 이를 과도하게 남용할 경우 모듈 시스템이 해결하고자 했던 "모든 것이 어디서나 접근 가능해지는 문제"를 다시 발생시킬 수 있으므로 주의해서 사용해야 합니다 [16].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Dependency_Injection.md

@@ -0,0 +1,36 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Dependency Injection
+description: "의존성 주입(Dependency Injection, DI)은 클래스가 필요로 하는 의존성(객체)을 직접 생성하지 않고 프레임워크나 외부 컨테이너를 통해 주입받도록 하는 소프트웨어 아키텍처 패턴이다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Dependency Injection
+
+## 📌 Brief Summary
+의존성 주입(Dependency Injection, DI)은 클래스가 필요로 하는 의존성(객체)을 직접 생성하지 않고 프레임워크나 외부 컨테이너를 통해 주입받도록 하는 소프트웨어 아키텍처 패턴이다 [1-3]. 이를 통해 시스템 컴포넌트 간의 강한 결합을 방지하고 유연성을 높일 수 있다 [1]. Spring Boot, NestJS, Vue 3 등 현대 프레임워크 전반에서 핵심 구조로 채택되어 코드의 테스트 가능성과 모듈성을 극대화하는 데 사용된다 [2-4].
+
+## 📖 Core Content
+* **설계 원칙과 테스트 가능성 확보**: 
+  DI는 의존성 역전 원칙(Dependency Inversion Principle)을 구현하는 구체적인 수단이다 [1]. 구체적인 구현체에 직접 의존하는 대신 생성자 등을 통해 필요한 의존성을 주입받도록 함으로써, 시스템의 결합도를 낮추고 유연성을 제공한다 [1, 3]. 특히 단위 테스트(Unit testing) 환경에서 비즈니스 로직을 변경하지 않고도 실제 서비스를 모의(Mock) 객체로 손쉽게 교체할 수 있는 강력한 이점을 제공한다 [2, 3].
+
+* **Spring Boot의 IoC 컨테이너 기반 DI**: 
+  Spring Boot는 Java 어노테이션을 활용하는 제어의 역전(IoC) 컨테이너를 통해 DI를 구현한다 [5, 6]. 애플리케이션 시작 시 컨테이너가 어노테이션을 읽어 의존성 그래프를 구성하며, 수동 연결(Manual wiring) 없이 생성자를 통해 빈(Bean)을 자동으로 주입한다 [6, 7]. 
+
+* **NestJS의 데코레이터 기반 DI**: 
+  Node.js 생태계의 NestJS는 Angular의 설계 철학을 도입하여 TypeScript 데코레이터 기반의 강력한 의존성 주입 컨테이너를 제공한다 [3, 5, 8]. 클래스의 생성자에 필요한 의존성(예: 데이터베이스 서비스, 캐시 서비스 등)을 선언하기만 하면 프레임워크가 알아서 이를 제공하여 코드의 응집도를 높인다 [2, 3].
+
+* **Vue 3의 Provide/Inject를 통한 의존성 주입**: 
+  프론트엔드 환경인 Vue 3에서는 Provide/Inject 시스템이 DI의 역할을 수행한다 [4]. 이 패턴을 통해 글로벌 로거, API 클라이언트, 상태 등 공유 서비스를 최상위 공급자에서 깊게 중첩된 하위 컴포넌트로 직접 "텔레포트"할 수 있으며, 이로 인해 중간 계층 컴포넌트들이 불필요한 데이터를 전달받는 'Prop Drilling' 현상을 방지한다 [4, 9].
+
+## ⚖️ Trade-offs & Caveats
+* **성능 오버헤드**: 
+  의존성 주입 시스템과 이를 위한 데코레이터 처리는 런타임 성능에 약간의 오버헤드를 유발할 수 있다 [10]. 예를 들어, NestJS의 경우 DI 시스템의 추상화 계층으로 인해 순수 Express 프레임워크를 사용할 때보다 초당 요청 처리량(Throughput)이 약 10~15% 정도 감소할 수 있다 [10].
+* **과도한 스캐폴딩과 구조적 복잡성**: 
+  DI 컨테이너와 모듈 시스템을 올바르게 구축하려면 많은 설정과 보일러플레이트 코드 작성이 요구된다 [11, 12]. 2~5명 규모의 소규모 팀이나 단순한 기능의 프로젝트에서는 이러한 구조적 제약이 실제 비즈니스 가치 창출보다 프레임워크 배선(Wiring) 작업에 더 많은 시간을 쏟게 하는 비용(기술 부채)으로 작용할 수 있다 [11].
+* **프레임워크 우회 시 발생하는 안티 패턴**: 
+  DI를 지원하는 프레임워크 환경에서 개발자가 DI 컨테이너를 우회하여 직접 의존성을 인스턴스화(예: `new UsersService()`와 같이 객체를 수동 생성)하는 방식은 시스템의 이점을 파괴한다 [13]. 이와 같은 수동 의존성 연결은 아키텍처의 일관성을 해치고 테스트 가능성을 완전히 상실하게 만든다 [13].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Dependency_Inversion_Principle.md

@@ -0,0 +1,27 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Dependency Inversion Principle
+description: "의존성 역전 원칙(Dependency Inversion Principle)은 애플리케이션 서비스가 인프라스트럭처 서비스와 상호 작용할 때 구체적인 구현체(concrete implementations)에 직접 의존하지 않도록 하는 설계 원칙이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Dependency Inversion Principle
+
+## 📌 Brief Summary
+의존성 역전 원칙(Dependency Inversion Principle)은 애플리케이션 서비스가 인프라스트럭처 서비스와 상호 작용할 때 구체적인 구현체(concrete implementations)에 직접 의존하지 않도록 하는 설계 원칙이다 [1]. 이 원칙은 대신 클래스의 생성자를 통해 필요한 의존성을 주입(inject)하는 방식을 제안한다 [1]. 이를 통해 시스템 요소 간의 느슨한 결합(loose coupling)을 촉진하며, 시스템을 더 유연하고 테스트하기 쉽게 만든다 [1].
+
+## 📖 Core Content
+* **구체적 구현으로부터의 분리**: 의존성 역전 원칙에 따라 애플리케이션 계층은 구체적인 구현 클래스에 직접적으로 종속되지 않는다 [1]. 대신 필요한 의존성은 생성자를 통해 외부에서 주입받는 방식을 취하여 시스템의 결합도를 낮춘다 [1]. 
+* **헥사고날 아키텍처(Hexagonal Architecture)에서의 역할**: 헥사고날 아키텍처에서 애플리케이션 서비스가 인프라스트럭처 서비스와 상호작용해야 할 때 기본적으로 이 의존성 역전 원칙을 따른다 [1]. 이를 통해 핵심 비즈니스 로직과 외부 시스템 간의 상호작용을 유연하게 관리할 수 있다 [1].
+* **프레임워크 단위의 의존성 주입(DI) 지원**: NestJS나 Spring Boot 같은 프레임워크는 이 원칙을 실현하기 위해 강력한 의존성 주입(Dependency Injection) 컨테이너 시스템을 제공한다 [2, 3]. 개발자가 클래스 생성자를 통해 필요한 의존성을 선언하면 프레임워크가 자동으로 인스턴스화하여 주입한다 [2, 3]. 이러한 방식은 의존성을 직접 임포트하여 사용하는 방식에 비해 컴포넌트 간 결합도를 낮추고 단위 테스트(Unit Test) 가능성을 극대화한다 [3].
+
+## ⚖️ Trade-offs & Caveats
+소스 내에서 의존성 역전 원칙 자체에 대한 직접적인 단점은 명시되어 있지 않으나, 이를 구현하는 '의존성 주입(DI)' 및 구조적 아키텍처를 실전 프레임워크에 도입할 때 다음과 같은 제약 및 반대 급부(Trade-off)가 동반된다.
+
+* **가파른 학습 곡선**: 의존성 주입, 데코레이터, 모듈화 등의 개념을 바탕으로 엄격한 아키텍처를 강제하는 프레임워크(예: NestJS, Spring Boot)를 사용할 경우, 개발자가 이를 완벽히 숙지하기 위한 학습 곡선(Learning Curve)이 비교적 가파르다 [4, 5].
+* **소규모 프로젝트에서의 오버헤드**: 단순한 API나 소규모 팀(2~5명) 환경에서는 의존성 주입 컨테이너나 모듈 시스템을 구성하는 데 드는 비용이 비즈니스 가치 창출보다 클 수 있다 [6]. 즉, 기능 개발보다 프레임워크 구조 설정(wiring)에 과도한 시간이 소모될 수 있는 오버엔지니어링의 위험이 존재한다 [4, 6].
+* **순환 참조(Circular Dependency) 문제**: 복잡한 의존성 주입 시스템에서는 모듈 및 서비스 간의 순환 참조 문제가 발생할 수 있다 [7]. 프레임워크에서 이를 우회하는 기능(예: NestJS의 `forwardRef()`)을 제공하긴 하지만, 이를 임시방편으로 사용하기보다는 아키텍처적 재설계를 통해 근본적으로 차단하는 것이 바람직하다 [3, 7].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Django_Signals.md

@@ -0,0 +1,25 @@
+---
+category: Backend
+tags: [auto-wikified, technical-documentation, backend]
+title: Django Signals
+description: "Django 시그널(Signals)은 모델 저장과 같은 특정 이벤트가 발생할 때 암시적으로 지정된 동작을 실행하게 해주는 기능이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Django Signals
+
+## 📌 Brief Summary
+Django 시그널(Signals)은 모델 저장과 같은 특정 이벤트가 발생할 때 암시적으로 지정된 동작을 실행하게 해주는 기능이다 [1]. 데이터베이스 모델 매핑 외의 부가적인 로직이나 기술적 관심사를 처리하기 위해 사용되기도 하지만, 많은 실무 개발자들에게 기피해야 할 요소로 간주된다 [2-4]. 특히 대규모 시스템에서는 코드의 실행 흐름을 파악하기 어렵게 만들기 때문에 실무에서 가장 경계해야 할 안티 패턴(Anti-pattern) 중 하나로 평가받는다 [1, 3].
+
+## 📖 Core Content
+* **로직의 분리와 이동 수단:** Django 프레임워크에서 데이터베이스 스키마 매핑 이상의 로직을 모델에 전부 집중시키는 것(Active Record 패턴)을 피하기 위해, 비즈니스 로직이나 부가 작업을 매니저(managers)나 시그널 핸들러로 이동시키는 방식이 활용되기도 한다 [2, 3].
+* **제한적인 기술적 관심사 처리:** 데이터 통합이나 인덱스 재구성(reindexation)을 트리거하는 등의 특정한 기술적 관심사를 처리하는 데에는 시그널이 유용한 접근법이 될 수 있다 [3]. 주의를 기울여 제한적으로 사용한다면 개발에 도움이 될 수 있다는 일부 의견도 존재한다 [5].
+* **명시적 서비스 패턴으로의 대체 추세:** 현대 Django 아키텍처에서는 모델과 비즈니스 로직을 분리하기 위해 시그널보다는 '서비스 레이어(Service Layer)'나 '리포지토리(Repository)' 패턴을 사용하는 방향으로 나아가고 있다 [1, 3]. 시그널 대신 명시적인 서비스 함수 호출을 통해 로직을 관리하는 것이 기술 부채를 줄이는 대규모 시스템의 정석으로 여겨진다 [1].
+
+## ⚖️ Trade-offs & Caveats
+* **실행 흐름의 불투명성과 부수 효과(Side-effects):** 시그널 도입의 가장 치명적인 부작용은 '보이지 않는 부수 효과(Invisible side-effects)'를 만들어낸다는 점이다 [4]. 동작이 이벤트에 암시적으로 연결되므로 전체적인 코드의 실행 흐름을 불투명하게 만들며, 이는 시스템에 예상치 못한 오류를 유발하는 원인이 된다 [1].
+* **비즈니스 로직의 오염 통제 불가:** 시그널은 단순한 데이터 처리나 기술적 목적을 넘어 비즈니스 로직이 침투(creeping in)하기 시작할 때 가장 큰 문제를 낳는다 [3]. 로직이 여러 시그널에 흩어지게 되면 결국 시스템의 동작을 추적할 수 없는 통제 불능(out of hands) 상태에 빠지게 된다 [3].
+* **명시적 호출을 통한 제약 극복:** 이러한 제약 사항 때문에 시그널은 전염병처럼 피해야 할(avoid them like the plague) 최악의 아이디어로 꼽히기도 한다 [4]. 이를 해결하기 위한 기술적 최적화 방향은, 모델 인스턴스를 생성하거나 업데이트하는 방식을 코드베이스 전반에서 단일화하고, 저장 전후(pre-/post-save)의 로직과 유효성 검사 로직을 외부로 분리하여 명시적으로 호출(call out)하는 것이다 [1, 4].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Domain-Driven_Design.md

@@ -0,0 +1,28 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Domain-Driven Design
+description: "도메인 주도 설계(Domain-Driven Design, DDD)는 복잡한 비즈니스 요구사항을 해결하고 대규모 시스템을 확장하기 위해 소프트웨어 구성 요소를 도메인 개념에 맞추어 조직하는 아키텍처 패턴이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Domain-Driven Design
+
+## 📌 Brief Summary
+도메인 주도 설계(Domain-Driven Design, DDD)는 복잡한 비즈니스 요구사항을 해결하고 대규모 시스템을 확장하기 위해 소프트웨어 구성 요소를 도메인 개념에 맞추어 조직하는 아키텍처 패턴이다 [1, 2]. 프레임워크의 실전 패턴에서는 코드를 단일하고 응집력 있는 도메인 영역(Bounded Context)으로 매핑하여 책임을 분리하고 결합도를 낮추는 데 활용된다 [3]. 전반적인 DDD 철학이나 상세 구현 기법에 대해서는 소스에 관련 정보가 부족합니다.
+
+## 📖 Core Content
+* **제한된 컨텍스트(Bounded Context) 기반의 구조화:** 대규모 프로젝트 구조를 설계할 때 핵심 도메인 개념을 기준으로 코드를 분리한다. 예를 들어 Django 프로젝트에서 각 앱(App)은 단일하고 응집력 있는 도메인 개념인 DDD의 'Bounded Context'에 정확히 매핑되어야 한다 [3]. 이를 통해 각 앱은 명확한 단일 책임을 지고, 독립적으로 추론 가능하며, 타 컴포넌트와의 결합도(Coupling)를 최소화할 수 있다 [3].
+* **도메인별 책임 분리와 안티 패턴 회피:** "utils", "helpers", "core"와 같이 불분명한 목적을 지니고 너무 많은 비즈니스 로직을 담는 거대한 앱(Mega-Apps)을 만드는 것은 지양해야 한다 [3-5]. 소프트웨어 구조는 Django의 기술적 레이어가 아닌 비즈니스 도메인을 기준으로 분할되어야 한다 [5].
+* **프레임워크별 DDD 도입 방식:**
+  * **Express.js:** 구조를 강제하지 않는 미니멀한 프레임워크이므로 대규모 확장성을 확보하기 위해서는 개발자가 수동으로 도메인 주도 설계(DDD) 패턴이나 의존성 주입 인프라를 설계하여 도입해야 한다 [2].
+  * **기타 엔터프라이즈 프레임워크:** Spring Boot 마이크로서비스 아키텍처에서 구조적 설계를 위해 다루어지며 [6], ASP.NET Core 환경의 ABP 프레임워크는 프로덕션 환경을 위해 도메인 주도 설계를 플랫폼 차원에서 지원한다 [1]. 
+* **비즈니스 규칙 검증의 격리:** 애플리케이션의 유효성 검사(Validation)는 단순한 데이터 형식 입력 검증과 '비즈니스 규칙 검증'으로 나뉘며, 비즈니스 규칙 검증은 데이터가 도메인 특유의 논리와 규칙을 정확히 준수하는지 확인하는 과정으로 도메인 레이어에 가깝게 처리된다 [7, 8].
+
+## ⚖️ Trade-offs & Caveats
+* **수동 아키텍처 설계 오버헤드:** Express.js처럼 패턴을 강제하지 않는 환경에서 도메인 주도 설계를 적용하려면, 개발팀이 직접 스케일링 패턴과 모듈 경계를 설계하고 규율을 엄격하게 유지해야 하는 기술적 부담이 발생한다 [2, 9].
+* **도메인 복잡도에 따른 선별적 도입 필요:** 모든 프로젝트에 DDD를 강제할 필요는 없다. 실무적인 관점에서는 도메인이 너무 복잡한(too complex) 경우에 한하여 도메인 모델링을 적용하는 것이 권장되며, 그렇지 않은 경우 오버엔지니어링이 될 수 있다 [10].
+* (기타 DDD 아키텍처 도입에 따른 성능적, 운영적 반대 급부나 한계점에 대해서는 소스에 관련 정보가 부족합니다.)
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Entity_엔티티.md

@@ -0,0 +1,29 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Entity (엔티티)
+description: "엔티티(Entity)는 애플리케이션에서 데이터베이스 모델이나 순수한 비즈니스 규칙을 표현하는 핵심 데이터 구조이다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Entity (엔티티)
+
+## 📌 Brief Summary
+엔티티(Entity)는 애플리케이션에서 데이터베이스 모델이나 순수한 비즈니스 규칙을 표현하는 핵심 데이터 구조이다 [1-3]. 현대 소프트웨어 개발 및 실전 아키텍처에서는 엔티티를 API 입출력을 담당하는 DTO(Data Transfer Object)와 엄격하게 분리하여 관리하는 것을 핵심 패턴으로 삼는다 [1-3]. 이를 통해 데이터베이스 스키마와 외부 API 스펙 간의 결합도를 낮추고 대규모 시스템의 유지보수성을 확보할 수 있다 [2-4].
+
+## 📖 Core Content
+* **역할 및 위치:**
+  실무 아키텍처에서 엔티티는 주로 TypeORM, Prisma, Drizzle(NestJS 환경) 또는 JPA(Spring Boot 환경)와 같은 도구의 데코레이터/어노테이션을 통해 데이터베이스 모델로 정의되며, 서비스(Service) 계층에서 사용된다 [2, 5, 6]. 특히 헥사고날 아키텍처(Hexagonal Architecture)에서는 도메인(Domain) 계층에 위치하여 어떠한 외부 프레임워크나 라이브러리에도 의존하지 않는 순수한 형태로 존재해야 한다 [3].
+* **DTO와의 명확한 분리:**
+  프로젝트 초기에는 엔티티와 DTO의 구조가 매우 유사해 보일 수 있으나, 시간이 지나고 애플리케이션이 확장됨에 따라 두 객체의 구조는 필연적으로 달라지게 된다 [1, 2]. 따라서 엔티티는 데이터베이스 스키마 및 도메인 표현에만 집중하고, DTO는 API를 넘나드는 데이터의 형태를 정의하는 용도로 역할을 분리해야 한다 [1, 2].
+* **데이터 변환 및 계약 유지:**
+  엔티티를 애플리케이션의 다른 계층이나 외부로 전달할 때는 매퍼(Mapper)를 통해 DTO로 데이터를 변환하는 과정을 거쳐야 한다 [3]. 소비 계층(Consuming layer)에는 인터페이스 계약에 기반한 DTO만 반환함으로써 핵심 엔티티를 격리 및 보호할 수 있다 [4]. 
+
+## ⚖️ Trade-offs & Caveats
+* **직접 노출 시의 위험성 (안티 패턴):**
+  컨트롤러(Controller)에서 엔티티를 클라이언트에게 직접 노출하는 것은 심각한 안티 패턴이다 [2]. 엔티티를 직접 반환하면 내부 데이터베이스 필드 구조가 외부에 그대로 유출될 뿐만 아니라, 애플리케이션이 DB 스키마에 완전히 종속(Lock-in)되게 된다 [2]. 이로 인해 추후 데이터 모델이 변경될 때 외부 API 스펙까지 파괴될 위험이 있으며, API 변경에 막대한 비용이 발생하게 된다 [2, 3].
+* **보일러플레이트 코드와 복잡성 증가:**
+  엔티티와 DTO를 분리하고 변환하는 패턴은 아키텍처를 견고하게 만들지만, 개발자가 작성하고 유지보수해야 할 보일러플레이트 코드(예: 중복되어 보이는 DTO 클래스 및 매핑 로직)를 증가시킨다는 단점이 있다 [7]. 소규모 팀이나 단순한 프로젝트에서는 이러한 엄격한 분리 구조가 오히려 비즈니스 가치 창출보다 프레임워크 배선(wiring) 작업에 더 많은 비용을 소모하게 만들 수 있다 [7, 8].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Expo_Router.md

@@ -0,0 +1,24 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Expo Router
+description: "**Expo Router**는 **React Native 및 웹 애플리케이션을 위한 파일 기반 라우팅 시스템**입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Expo Router
+
+## 📌 Brief Summary
+**Expo Router**는 **React Native 및 웹 애플리케이션을 위한 파일 기반 라우팅 시스템**입니다 [1, 2]. Next.js와 같은 웹 프레임워크에서 깊은 영감을 받아 만들어졌으며, 웹과 모바일 개발 사이의 간극을 효과적으로 메워줍니다 [3]. 개발자가 디렉토리에 파일을 생성하는 것만으로 iOS, Android, 웹을 위한 화면과 내비게이션 스택을 손쉽게 정의할 수 있도록 지원합니다 [3].
+
+## 📖 Core Content
+* **자동화된 파일 기반 라우팅:** Expo Router는 디렉토리 내에 새로운 파일을 생성하면 **해당 파일이 앱의 내비게이션 경로(Route)로 자동으로 변환**되는 구조를 제공합니다 [1]. 이러한 접근 방식은 애플리케이션의 내비게이션 아키텍처를 크게 단순화하며, 코드의 조직화 및 라우팅 관리를 훨씬 효율적으로 만들어 줍니다 [1, 2].
+* **진정한 유니버설 앱 패러다임 구축:** 이 라우팅 시스템은 Android, iOS, 웹 등 **여러 플랫폼에 걸쳐 동일한 컴포넌트의 사용을 지원**합니다 [1]. 이를 통해 단일 코드베이스로 진정한 의미의 '유니버설 앱 패러다임'을 형성할 수 있으며, 특히 기존 웹 개발자가 모바일 개발로 넘어가는 전환 과정을 매우 매끄럽게 만들어 줍니다 [3].
+* **강력한 Expo 에코시스템과의 통합:** Expo Router는 EAS(Expo Application Services) 빌드 및 배포 파이프라인과 함께 프로덕션 수준의 앱 개발을 위한 핵심 도구로 자리 잡고 있습니다 [3, 4]. 이를 활용하면 개발자는 과거 React Native 설정 시 겪었던 복잡한 네이티브 빌드 구성을 피하고, 단순화된 내비게이션 아키텍처의 이점을 누릴 수 있습니다 [4].
+
+## ⚖️ Trade-offs & Caveats
+소스에 관련 정보가 부족합니다. (제공된 소스 데이터 내에는 Expo Router 자체의 구체적인 단점, 제약 사항 또는 기술적 반대 급부(Trade-off)에 대해 명시된 내용이 없습니다.)
+
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Fabric_Renderer.md

@@ -0,0 +1,25 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Fabric Renderer
+description: "Fabric Renderer는 React Native의 새로운 아키텍처(New Architecture)에 도입된 혁신적인 UI 렌더링 시스템으로, 기존의 UI 관리 레이어를 밑바닥부터 다시 작성한 결과물입니다 [1]."
+last_updated: 2026-05-04
+---
+
+# Fabric Renderer
+
+## 📌 Brief Summary
+Fabric Renderer는 React Native의 새로운 아키텍처(New Architecture)에 도입된 혁신적인 UI 렌더링 시스템으로, 기존의 UI 관리 레이어를 밑바닥부터 다시 작성한 결과물입니다 [1]. 과거 자바스크립트 스레드와 네이티브 스레드 간의 비동기적 브릿지(Bridge) 통신이 유발하던 성능 병목 현상을 해결하기 위해 설계되었습니다 [2, 3]. 네이티브 UI 레이어에 대한 동기적(synchronous) 접근을 가능하게 하여, React 18의 동시성 렌더링(Concurrent rendering)을 지원하고 네이티브에 가까운 부드러운 앱 성능을 제공합니다 [1, 3].
+
+## 📖 Core Content
+* **C++ 기반의 섀도우 트리(Shadow Tree) 생성:** 구형 아키텍처에서는 UI가 별도의 네이티브 스레드에서 관리되었으며 자바스크립트 스레드와의 통신이 비동기적으로 이루어졌습니다 [1]. 반면, Fabric은 UI의 가상 표현인 '섀도우 트리'를 C++에서 직접 생성하게 함으로써 스레드 간의 직접적이고 효율적인 데이터 공유를 가능하게 합니다 [1].
+* **동기적 레이아웃(Synchronous Layout) 연산:** Fabric 시스템은 비동기 왕복(round-trips) 없이 네이티브 뷰를 측정하고 렌더링할 수 있습니다 [3]. 네이티브 측에서 레이아웃을 계산한 뒤 동일한 렌더 사이클 내에 자바스크립트 스레드에 제공할 수 있게 되어, UI 요소가 한 프레임에 나타났다가 다음 프레임에 재배치되는 'UI 점프' 현상을 본질적으로 해결합니다 [1]. 
+* **동시성 렌더링(Concurrent Rendering) 완벽 지원:** Fabric은 React 18 및 그 이후 버전과 호환되며, 데이터 페칭을 위한 Suspense나 Transitions와 같은 동시성 기능을 지원합니다 [1]. 이를 통해 React는 렌더링의 우선순위를 조정하거나 사용자 입력에 즉각적으로 반응하기 위해 기존 렌더링 작업을 중단할 수 있어, 훨씬 더 유동적이고 반응성 높은 UI를 제공합니다 [1].
+* **성능 및 반응성 향상:** 렌더링 로직을 C++로 이동시키고 JSI를 통한 직접적인 통신을 활성화함으로써, UI 구성 요소를 렌더링하고 업데이트하는 데 걸리는 시간이 대폭 감소했습니다 [1]. 이는 복잡한 리스트 스크롤링, 네비게이션 전환 등에서 프레임 드랍 현상을 없애주며, 네이티브 컴포넌트들을 네이티브와 다름없는 성능으로 제어하고 애니메이션화할 수 있게 합니다 [3, 4].
+
+## ⚖️ Trade-offs & Caveats
+* **서드파티 라이브러리 호환성 및 과도기적 한계:** Fabric을 포함한 새로운 아키텍처는 아직 모든 신규 프로젝트에 기본값(default)으로 적용된 상태는 아니며, 선택적(opt-in)으로 사용할 수 있는 과도기적 단계에 있습니다 [5]. 따라서 초기 도입자(early adopters)에게는 훌륭한 성능을 제공하지만, 기존의 거대한 에코시스템 내 서드파티 라이브러리들이 새로운 아키텍처(Fabric 및 TurboModules)를 완벽히 지원하도록 채택(adoption) 및 업데이트될 때까지는 호환성 검토에 추가적인 노력이 필요할 수 있습니다 [3].
+* **플랫폼 종속적 애니메이션 한계:** Fabric이 네이티브 UI 레이어에 대한 렌더링 성능을 극대화했음에도 불구하고, React Native의 근본 특성상 실제 네이티브 플랫폼 컴포넌트(iOS의 UIKit, Android의 Views)를 그대로 사용합니다 [6]. 이는 진정한 네이티브 느낌을 주는 장점이 되지만, 극도로 복잡한 커스텀 애니메이션이나 비표준 파티클 효과 등을 구현할 때는 전체 렌더링 파이프라인을 독자적으로 통제하는 프레임워크(예: Flutter)에 비해 제약이 따르거나 플랫폼 간 미세한 편차가 발생할 수 있습니다 [6].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Fact_Based_Meeting_Minutes_Prompt.md

@@ -0,0 +1,25 @@
+# 📄 사실 기반 회의록 작성 가이드 (Fact-Based Meeting Minutes Guide)
+
+### [최종 목표]
+사용자로부터 제공받은 원본 회의 녹취록/기록(Input Data)을 분석하여, **외부 지식이나 개인적 추측이 일절 배제된**, 완벽하게 구조화되고 객관적이며 실행 가능한 '사실 기반 회의록'을 산출하는 것. 특히 **추상적인 개념보다는 구체적인 내용, 일정, 방향성**을 중심으로 정리한다.
+
+### [핵심 역할 및 정체성]
+당신은 **최종 사실 추출 엔진(Ultimate Fact Extraction Engine)**이다. 당신의 유일한 임무는 Input Data를 순수한 데이터 저장소로 작동하며, 모든 발언자의 감정적 편향이나 ID 표기(예: 참석자 1)에 관계없이 오직 **'발언된 사실과 합의된 내용'**만을 기록하는 것이다.
+
+### [데이터 우선순위 및 예외 처리 (CRITICAL OVERRIDE)]
+*   **최우선 데이터 소스:** 만약 사용자로부터 회의 녹취록 외에 별도로 제공된 '회의 메타데이터(날짜, 참석자 명단 등)'가 존재할 경우, **해당 메타데이터를 모든 날짜 및 참석자 정보 항목에 무조건적으로 사용해야 한다.**
+*   **녹취록 내 정보 처리:** 녹취록 자체에서 날짜나 참석자 정보가 언급되었더라도, 별도 제공된 메타데이터가 있다면 이를 덮어쓰고(Override) 사용한다.
+
+### [운영 원칙: 4단계 내부 처리 루프]
+1.  **데이터 해체 및 발언자 무시:** 잡담 분리, 핵심 주제 및 사실(Fact) 추출. 최종 출력물에는 발언자 ID(예: 참석자 1)를 절대 사용하지 않음.
+2.  **사실 기반 구조화:** 추출된 사실과 결정 사항을 필수 출력 형식의 6개 섹션 구조에 배치.
+3.  **검증 및 유효성 확인 (Critical Validation):**
+    *   a) 사실 기반 강제: 누락 시 `[확인 불가]` 표시.
+    *   b) 발언자 식별 금지: 본문 내 이름/ID 언급 엄격 금지.
+    *   c) 결정된 사실 위주 반영.
+4.  **정제 및 최종화:** 불확실한 정보는 `[확인 불가]` 대체. 구어체적 합의를 확정 조치로 포착.
+
+### [엄격 준수 규칙]
+*   **날짜/참석자 규약:** 메타데이터 우선 적용. 미명시 시 `[확인 불가]` 또는 `[논의 참여 주체]` 표시.
+*   **1인칭/감정 배제:** "우리는~", "생각한다" 등 주관적 표현 절대 금지. 모든 문장은 "결정됨", "논의됨", "확인됨" 등 객관적 서술형으로 종결.
+*   **발언자 익명화:** "A님이 말함" 대신 "특정 기능에 대한 요구사항이 제기됨"과 같이 내용 중심으로 기술.

10_Wiki/Topics/_Archive_Orphans/Fastify.md

@@ -0,0 +1,26 @@
+---
+category: Backend
+tags: [auto-wikified, technical-documentation, backend]
+title: Fastify
+description: "Fastify는 Node."
+last_updated: 2026-05-04
+---
+
+# Fastify
+
+## 📌 Brief Summary
+Fastify는 Node.js 환경에서 더 나은 성능과 확장성을 제공하기 위해 사용되는 고성능 HTTP 서버 프레임워크입니다 [1, 2]. 제공된 소스에서는 주로 NestJS 아키텍처 내에서 기본 프레임워크인 Express를 대체할 수 있는 선택적 HTTP 어댑터로 언급되며, 애플리케이션의 원시 처리량(Throughput)을 크게 향상시키는 역할을 합니다 [3, 4]. 
+
+## 📖 Core Content
+* **NestJS의 고성능 HTTP 어댑터 지원**: NestJS는 기본적으로 Express를 HTTP 계층으로 사용하지만, 아키텍처의 이점(의존성 주입, 모듈 시스템 등)을 유지하면서도 성능을 높이기 위해 기본 계층을 Fastify로 전환할 수 있도록 지원합니다 [1, 3, 4].
+* **압도적인 요청 처리량(Throughput)**: 단순 JSON 응답을 기준으로 Express 기반의 NestJS가 초당 약 12,000~17,000개의 요청(req/s)을 처리하는 반면, Fastify를 기반으로 구동되는 NestJS는 초당 약 25,000~30,000개의 요청을 처리할 수 있어 원시 처리량 벤치마크에서 Express를 크게 능가합니다 [3, 4].
+* **최소한의 전환 비용**: NestJS 생태계 내에서 기반 프레임워크를 Express에서 Fastify로 전환하는 것은 단 한 줄의 코드 변경만으로 가능하도록 설계되어 있습니다 [3]. 
+* **소스에 관련 정보가 부족합니다.** (제공된 문헌들은 NestJS와 Express를 비교하는 맥락에서만 Fastify를 간략히 언급하고 있으며, Fastify 자체가 가진 고유의 라우팅 패턴, 스키마 유효성 검사, 플러그인 아키텍처 등 코어 기능 및 실전 패턴에 대한 구체적인 정보는 포함하고 있지 않습니다.)
+
+## ⚖️ Trade-offs & Caveats
+* **실제 성능 병목과의 상관관계**: Fastify를 도입하면 프레임워크 자체의 처리량을 높일 수 있지만, 99%의 실제 프로덕션 애플리케이션 환경에서는 프레임워크의 오버헤드보다 데이터베이스 쿼리, 외부 API 호출, 비즈니스 로직 등에서 발생하는 지연 시간(Latency)이 훨씬 큽니다 [3]. 따라서 단순한 처리량 벤치마크 속도만을 근거로 Fastify를 채택하기보다는 개발 생산성과 유지보수성을 우선적으로 고려하는 것이 권장됩니다 [3].
+* **미들웨어 생태계와의 호환성 고려**: 소스에서 Fastify의 명시적인 단점을 짚고 있지는 않으나, Express 프레임워크가 Node.js 생태계에서 가장 널리 사용되며 수천 개의 npm 패키지 및 미들웨어를 보유하고 있다는 점을 감안할 때 [5], Fastify로 전환 시 기존 Express 전용으로 작성된 서드파티 미들웨어의 호환성 여부를 확인해야 하는 제약이 발생할 수 있습니다.
+* **소스에 관련 정보가 부족합니다.** (Fastify 단독 환경에서의 아키텍처적 한계점, 최적화 기법에 따른 부작용 등에 대한 상세한 정보는 소스에 부족합니다.)
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Flutter.md

@@ -0,0 +1,27 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Flutter
+description: "Flutter는 구글이 2017년에 출시한 오픈 소스 UI 소프트웨어 개발 키트로, 단일 코드베이스를 통해 모바일, 웹, 데스크톱 등 다양한 플랫폼의 애플리케이션을 구축할 수 있게 해주는 프레임워크이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Flutter
+
+## 📌 Brief Summary
+Flutter는 구글이 2017년에 출시한 오픈 소스 UI 소프트웨어 개발 키트로, 단일 코드베이스를 통해 모바일, 웹, 데스크톱 등 다양한 플랫폼의 애플리케이션을 구축할 수 있게 해주는 프레임워크이다 [1, 2]. Dart 프로그래밍 언어를 기반으로 하며, 호스트 운영체제의 네이티브 UI 컴포넌트를 호출하는 대신 프레임워크 자체 렌더링 엔진(Skia 또는 Impeller)을 사용하여 화면의 모든 픽셀을 직접 그리는 방식을 취한다 [3-6]. 이를 통해 개발자는 플랫폼에 구애받지 않고 '픽셀 퍼펙트(Pixel-perfect)'한 일관된 사용자 인터페이스와 높은 성능을 제공할 수 있다 [4, 7].
+
+## 📖 Core Content
+*   **자체 렌더링 엔진과 아키텍처 혁신**: Flutter는 모든 UI를 위젯(Widget)으로 구성하며, 네이티브 구성 요소를 사용하지 않고 자체 그래픽 엔진을 통해 UI를 렌더링한다 [4, 5, 8]. 기존 Skia 엔진의 한계였던 셰이더 컴파일 지연(Jank) 문제를 해결하기 위해 **Impeller 렌더링 엔진**을 도입하였으며, 빌드 시점에 셰이더를 미리 컴파일함으로써 일관된 60fps 이상의 부드러운 성능을 보장한다 [9-11].
+*   **Dart 언어와 컴파일 최적화**: Flutter는 Dart 언어를 사용하여 JIT(Just-in-Time) 및 AOT(Ahead-of-Time) 컴파일을 모두 지원한다 [5]. 개발 중에는 JIT를 통한 **'핫 리로드(Hot Reload)'**로 상태를 유지하면서 1초 이내에 빠른 피드백을 제공하고, 프로덕션에서는 AOT를 통해 네이티브 ARM 코드로 컴파일되어 빠른 시작 시간과 고성능을 자랑한다 [5, 12-14]. Dart 3의 도입으로 사운드 널 안정성(Sound null safety), 패턴 매칭, 레코드 등의 기능이 추가되어 코드베이스가 더욱 견고해졌다 [11].
+*   **실전 상태 관리 패턴**: 규모에 따라 다양한 아키텍처 패턴이 적용된다. 대규모 엔터프라이즈 프로젝트에서는 엄격한 관심사 분리를 요구하는 스트림(Stream) 기반의 이벤트 중심 상태 관리 방식인 **'BLoC (Business Logic Component)'** 패턴이 테스트 용이성 덕분에 선호된다 [15]. 중소규모 프로젝트에서는 유연한 의존성 주입을 돕는 **'Provider'**나, 이를 개선하여 MVVM 아키텍처와의 결합도가 높은 현대적 반응형 패턴인 **'Riverpod'**이 폭넓게 활용된다 [15].
+*   **AI 및 머신러닝 생태계 통합**: 구글의 에코시스템과 긴밀하게 통합되어 있어, Firebase AI Logic을 통한 Gemini 모델 접근이나 기기 내 직접 추론을 위한 TensorFlow Lite를 Flutter 애플리케이션에 매끄럽게 적용할 수 있다 [16, 17].
+
+## ⚖️ Trade-offs & Caveats
+*   **플랫폼 네이티브 컴포넌트의 부재**: Flutter는 실제 플랫폼 네이티브 UI 요소(예: iOS의 UIKit)를 사용하지 않고 이를 시각적으로 모방한다 [4, 18]. 이로 인해 새로운 OS 버전에서 UI 패러다임이 바뀔 경우 커뮤니티가 이를 복제할 때까지 기다려야 하며, 스크롤 물리 효과나 접근성(Accessibility) 의미 체계 등에서 네이티브 표준과 미묘한 차이가 발생할 수 있다 [4, 18-20].
+*   **앱 용량 증가**: Dart 런타임과 그래픽 렌더링 엔진(Impeller 등)을 애플리케이션 내에 자체적으로 포함하여 배포해야 하므로, React Native에 비해 기본적인 앱의 파일 크기(최소 8~12MB 수준)가 상대적으로 더 크며 기기 메모리 점유율도 약간 더 높다 [13, 21].
+*   **학습 곡선과 인재 확보의 한계**: 세계적으로 널리 쓰이는 JavaScript/TypeScript를 사용하는 React Native와 달리, 상대적으로 생태계가 작은 Dart 언어를 별도로 학습해야 한다 [22-24]. 이로 인해 전문 개발자 풀이 좁아 팀을 확장하거나 인재를 채용하는 데 더 많은 시간과 비용(프리미엄 인건비, 교육 비용 등)이 소요될 수 있다 [22, 24, 25].
+*   **서드파티 라이브러리 및 3D 제약**: 모바일 생태계에서 특정 네이티브 모듈이나 서드파티 라이브러리 지원이 JavaScript 생태계보다 성숙하지 않을 수 있어 일부 기능을 처음부터 직접 개발해야 할 수 있다 [26]. 또한 고도의 3D 애니메이션이나 컴포넌트 렌더링에 있어서는 React Native나 완전한 네이티브 환경에 비해 지원이 부족하다 [27].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Flutter_AOT_Compilation_Dart.md

@@ -0,0 +1,25 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Flutter AOT Compilation (Dart)
+description: "Flutter의 AOT(Ahead-of-Time) 컴파일은 Dart 프로그래밍 언어로 작성된 애플리케이션 코드를 실행 이전에 네이티브 ARM 코드(기계어)로 사전 컴파일하는 기술이다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Flutter AOT Compilation (Dart)
+
+## 📌 Brief Summary
+Flutter의 AOT(Ahead-of-Time) 컴파일은 Dart 프로그래밍 언어로 작성된 애플리케이션 코드를 실행 이전에 네이티브 ARM 코드(기계어)로 사전 컴파일하는 기술이다 [1-3]. 이는 실행 시점의 오버헤드를 줄여 애플리케이션의 빠른 초기 시작(Cold start) 속도를 달성하고 높은 런타임 성능을 보장하는 Flutter 아키텍처의 핵심 메커니즘이다 [2, 4].
+
+## 📖 Core Content
+* **네이티브 기계어로의 직접 컴파일**: Flutter는 프로덕션 배포 시 Dart AOT 컴파일러를 활용하여 코드를 Android 및 iOS 모바일 기기를 위한 네이티브 기계어(ARM 코드)로 직접 변환한다 [1-3, 5]. 실행 시점에 파싱되거나 해석되어야 하는 자바스크립트 기반 프레임워크와 달리, 기계어 형태로 컴파일되므로 향상된 퍼포먼스를 제공한다 [4].
+* **빠른 콜드 스타트(Cold Start) 속도**: 코드가 미리 컴파일되어 있기 때문에 애플리케이션 구동 시 자바스크립트 엔진(예: Hermes) 초기화 및 번들 파싱 과정을 거칠 필요가 없다 [2]. 이러한 이점 덕분에 Flutter 애플리케이션은 일반적으로 더 빠른 초기 시작 속도를 자랑한다 [2].
+* **실행 효율 극대화**: Flutter는 플랫폼 네이티브 컴포넌트에 의존하는 대신 자체 그래픽 렌더링 엔진(Skia 또는 Impeller)을 사용하며, Dart 언어의 AOT 컴파일 기능을 결합하여 애니메이션이나 복잡한 렌더링 작업 시 프레임워크의 실행 효율성을 극대화한다 [5, 6].
+
+## ⚖️ Trade-offs & Caveats
+* **애플리케이션 용량(App Size) 증가**: AOT 컴파일된 코드와 함께 Dart 런타임 및 자체 렌더링 엔진(Impeller 등)이 앱 번들에 포함되어 배포되어야 한다 [2]. 이로 인해 운영체제의 네이티브 UI 컴포넌트를 렌더링하는 React Native(최소 5~8MB) 대비 Flutter 앱의 최소 초기 파일 크기(최소 8~12MB)가 상대적으로 더 크며, 이는 기기의 메모리 성능에 부담을 줄 수 있다 [2, 7].
+* **Dart 언어 종속성과 인력 확보 한계**: AOT 컴파일의 이점을 누리기 위해선 반드시 Dart 언어를 학습해야 한다 [7, 8]. 범용성이 높은 JavaScript에 비해 개발자 풀과 생태계가 좁아 프로젝트 초기 인력 확보와 학습 곡선(Learning Curve) 극복에 비용과 시간이 더 들 수 있다 [7-9].
+* **아키텍처 지원 제약**: Flutter는 64비트 ARM 아키텍처 지원에 일부 한계가 있어(가장 근접하게 지원되는 구조가 ARM64-v8A) 일부 특정 모바일 디바이스 환경에서의 채택을 제한할 수 있다는 단점이 있다 [10].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Flutter_Impeller.md

@@ -0,0 +1,27 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Flutter Impeller
+description: "Flutter Impeller는 기존 Skia 엔진을 대체하기 위해 개발된 Flutter의 최신 그래픽 렌더링 엔진입니다."
+last_updated: 2026-05-04
+---
+
+# Flutter Impeller
+
+## 📌 Brief Summary
+Flutter Impeller는 기존 Skia 엔진을 대체하기 위해 개발된 Flutter의 최신 그래픽 렌더링 엔진입니다. 애플리케이션 빌드 시점에 셰이더(Shader)를 미리 컴파일하여 런타임에 발생하는 프레임 드랍(Jank) 현상을 근본적으로 해결할 목적으로 설계되었습니다. 2023년(Flutter 3.10)부터 iOS에서 기본 렌더러로 안정화되었으며, Android를 비롯한 다른 플랫폼으로도 지원이 확대되고 있습니다 [1, 2].
+
+## 📖 Core Content
+* **셰이더 컴파일 쟁크(Jank) 해결**: 기존 구조의 가장 큰 성능 문제였던 '셰이더 컴파일 쟁크'는 사용자가 새로운 시각 효과를 처음 마주할 때 셰이더를 실시간으로 컴파일하면서 발생하던 프레임 드랍 현상이었습니다 [1, 2]. Impeller는 앱 빌드 과정에서 더 작고 최적화된 셰이더 세트를 미리 컴파일(Pre-compile)해두는 방식으로 이 문제를 해결하여 첫 프레임부터 일관되고 부드러운 렌더링을 제공합니다 [3, 4].
+* **현대적 모바일 GPU 최적화**: Impeller는 테셀레이션(Tessellation) 기반의 렌더링 방식을 채택하여 최신 모바일 GPU 환경에 고도로 최적화되어 있습니다 [2]. 이를 통해 화면의 모든 픽셀을 직접 그리는(Custom Rendering) Flutter의 철학을 유지하면서도 복잡한 그래픽을 빠르고 예측 가능하게 처리합니다 [2, 5].
+* **성능 일관성**: Impeller의 도입으로 복잡한 애니메이션과 전환 효과가 사용되는 환경에서도 고주사율 기기에서 120fps 또는 일관된 60fps의 렌더링 성능을 보장받을 수 있게 되었습니다 [3, 6, 7].
+* **플랫폼 적용 현황**: iOS 환경에서는 완전히 안정화되어 프로덕션 레벨의 기본 그래픽 백엔드로 자리 잡았으며, Android에서는 프리뷰(Preview) 형태로 제공되며 버전이 업데이트될 때마다 빠르게 발전하고 있습니다 [2, 8].
+
+## ⚖️ Trade-offs & Caveats
+* **앱 용량(App Size) 증가**: 앱 패키징 시 Dart 런타임과 함께 Impeller 렌더링 엔진 자체가 포함되어야 합니다. 이로 인해 앱의 최소 크기(APK 기준)가 8~12MB 수준으로 구성되며, 시스템의 네이티브 렌더러를 활용하는 React Native(약 5~8MB)에 비해 베이스라인 용량이 상대적으로 커진다는 제약이 있습니다 [7].
+* **메모리 오버헤드**: 운영체제의 네이티브 UI 컴포넌트를 차용하지 않고, Impeller/Skia 엔진을 이용해 자체적인 위젯 트리와 렌더링 파이프라인을 독자적으로 유지하며 화면을 그립니다 [9, 10]. 이로 인해 네이티브 UI를 사용하는 방식 대비 애플리케이션의 기본 메모리 사용량이 다소 높게 발생합니다 [9].
+* **플랫폼별 성숙도 편차**: iOS에서는 Impeller가 기본값으로 완전히 성숙하여 셰이더 쟁크 문제를 해결했지만, Android 생태계에서는 아직 성숙해 가는 단계(Preview)이므로 플랫폼 간 그래픽 백엔드 안정성 및 최적화 수준에 일시적인 편차가 존재합니다 [2, 11].
+
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Flutter_Web_-_Desktop.md

@@ -0,0 +1,25 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Flutter Web / Desktop
+description: "Flutter Web / Desktop은 단일 코드베이스를 사용하여 모바일뿐만 아니라 웹과 데스크톱(Windows, macOS, Linux) 환경을 위한 애플리케이션을 구축할 수 있게 해주는 크로스 플랫폼 프레임워크 기능이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Flutter Web / Desktop
+
+## 📌 Brief Summary
+Flutter Web / Desktop은 단일 코드베이스를 사용하여 모바일뿐만 아니라 웹과 데스크톱(Windows, macOS, Linux) 환경을 위한 애플리케이션을 구축할 수 있게 해주는 크로스 플랫폼 프레임워크 기능이다 [1, 2]. 최근 WebAssembly(WasmGC) 기술 채택과 데스크톱 지원의 안정화를 거치며 성능과 범용성이 크게 향상되었다 [1]. 모바일 단말기를 넘어 모든 사용자 접점(Touchpoints)에서 일관된 사용자 경험을 제공해야 하는 비즈니스에 특히 성숙한 솔루션으로 평가받고 있다 [1, 3].
+
+## 📖 Core Content
+* **Flutter Web의 성능 비약적 발전**: WebAssembly(WasmGC)가 주류 기술로 채택됨에 따라 자바스크립트 대신 Wasm으로 코드를 컴파일할 수 있게 되었다 [1]. 이를 통해 로딩 시간이 눈에 띄게 단축되었고 번들 크기가 감소했으며, 복잡한 UI와 애니메이션에서도 네이티브에 가까운 성능을 제공하여 정교한 웹 애플리케이션 개발에 강력한 경쟁력을 갖추게 되었다 [1]. 
+* **안정화된 데스크톱 아키텍처 지원**: Windows, macOS, Linux 운영체제에 대한 데스크톱 지원이 매우 안정적이고 견고해졌다 [1, 2]. 개발자는 데스크톱 환경을 위한 사전 제작된 플러그인을 설치하거나 직접 생성할 수 있으며, 기존 소스 코드를 컴파일하여 기본 데스크톱 앱을 만들어 낼 수 있다 [2].
+* **프로덕션 수준의 다중 플랫폼 타겟팅**: Flutter는 모바일 플랫폼 이외에도 웹과 데스크톱 타겟을 단일 코드베이스로 동시에 지원할 수 있어 뛰어난 다중 플랫폼(Multi-platform) 커버리지를 제공한다 [3, 4]. 이러한 웹과 데스크톱 타겟 기능은 많은 애플리케이션 유형에서 즉시 상용화가 가능한(production-ready) 수준이며, React Native의 데스크톱/웹 지원에 비해 한층 더 성숙한 것으로 평가된다 [3-5].
+
+## ⚖️ Trade-offs & Caveats
+* **플랫폼 표준 및 관례 불일치 위험**: Flutter는 호스트 플랫폼의 네이티브 UI 구성요소를 사용하지 않고 자체 엔진을 사용해 모든 픽셀을 렌더링하므로, 모든 환경에서 동일한 시각적 결과를 보장하지만 각 웹 및 데스크톱 플랫폼의 기본 동작 관례를 개발자가 직접 맞춰야 하는 부담이 있다 [6]. 특히 스크롤 물리 엔진이나 텍스트 선택 동작, 접근성 의미론(Accessibility semantics)이 해당 플랫폼의 고유 표준과 미세하게 빗나갈 가능성이 존재한다 [6].
+* **'모방된(Simulated)' 네이티브 경험**: 각 플랫폼(웹, Windows, macOS 등) 고유의 UI 동작을 그대로 상속받지 못하고 Material 또는 Cupertino 위젯을 통해 이를 흉내(Simulated)내야 하므로, 해당 운영체제의 완벽한 네이티브 룩앤필(Native feel)이 필수적인 프로젝트에서는 적합하지 않을 수 있다 [5, 6].
+* **메모리 및 용량 오버헤드**: Flutter 앱은 네이티브 컴포넌트를 호출하는 방식이 아니라 자체적인 위젯 트리와 렌더링 엔진, Dart 런타임을 포함한 채 배포되어야 하므로 근본적으로 앱 크기가 더 무겁고 메모리 오버헤드가 더 높게 발생할 수 있다 [7, 8]. 
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/G1nation_Build_Fix_Report.md

@@ -0,0 +1,33 @@
+# [Report] G1nation Extension Encoding & Engine Rebuilding
+**Date**: 2026-04-24
+**Author**: PD Kodari (AI)
+**Status**: COMPLETED & PACKAGED (v2.2.15)
+
+## 1. 개요 (Overview)
+ConnectAI에서 G1nation으로의 브랜딩 전환 이후 발생한 심각한 빌드 오류 및 런타임 불안정성을 해결하기 위한 긴급 수술을 집행함. 소스 코드 내 인코딩 오염과 코드 복제(Duplication)로 인해 `npm run compile`이 불가능한 상태였음.
+
+## 2. 주요 결함 (Critical Issues)
+- **인코딩 지뢰 (Encoding Corruption)**: `extension.ts` 내 한글 주석 및 UI 문자열이 UTF-8 형식을 벗어나 깨지면서 따옴표(`'`) 인식을 방해함 -> `Unterminated string literal` 에러 발생.
+- **좀비 코드 (Ghost Blocks)**: 함수 외부에 버려진 실행 코드와 닫는 중괄호(`}`)들이 산재하여 문법 파괴.
+- **엔진 중복 (Engine Duplication)**: `_executeActions` 함수가 두 군데 이상 중복 정의되어 로직 충돌 및 용량 비대화 초래.
+- **문법 오용**: `execSync`에 `.catch()`를 사용하는 등 동기/비동기 혼선 발견.
+
+## 3. 수술 과정 (Surgical Process)
+총 20단계에 걸친 **PowerShell 레이저 수술(Line-by-line Patch)**을 통해 표준 `replace` 도구의 인코딩 한계를 극복함.
+
+- **v1~v10**: 설정 메뉴(`_handleSettingsMenu`) 및 브레인 메뉴(`_handleBrainMenu`)의 깨진 텍스트를 영문/표준 UTF-8로 전면 교체.
+- **v11~v18**: 중복된 코드 블록들을 찾아내어 삭제하고, 흩어진 액션 핸들러들을 하나로 통합.
+- **v19**: 메인 엔진(`_executeActions`)을 중복 없는 최신 구조로 리빌딩.
+- **v20**: 함수 외부에 잔존하던 '유령 코드'와 깨진 문자열 최종 소거.
+
+## 4. 최종 결과 (Final Result)
+- **빌드 성공**: `esbuild` 컴파일 정상 통과 (30ms 내외).
+- **패키징 완료**: `g1nation-2.2.15.vsix` 생성 완료.
+- **안정성 확보**: UI 텍스트 영문화 및 표준화를 통해 향후 인코딩 문제 재발 가능성 차단.
+
+## 5. 향후 과제 (Next Steps)
+- **모듈화**: 2,500라인이 넘는 `extension.ts`를 `ActionHandlers.ts`, `UIProvider.ts` 등으로 분리하여 유지보수성 향상 필요.
+- **i18n 도입**: 한글 UI 재도입 시 직접 하드코딩 대신 별도의 JSON 언어팩 사용 권장.
+
+---
+**PD 코다리의 한마디**: "조직이 시스템이다. 엔진이 깨끗해야 비행기가 뜬다!" 😎🐟

10_Wiki/Topics/_Archive_Orphans/GIT_PROTOCOL.md

@@ -0,0 +1,16 @@
+# 🚩 Agent Git Operation Mapping Protocol
+
+| 유저 명령어 | 실행 액션 | 대상 리모트/브랜치 |
+| :--- | :--- | :--- |
+| **"Agent 최신화해"** | `git pull origin <current_branch>` | https://github.com/g1nations/TeamG1.git |
+| **"Agent 커밋해"** | `git add .` <br> `git commit -m "Update Agent Systems"` <br> `git push origin <current_branch>` | https://github.com/g1nations/TeamG1.git |
+
+## 🛠️ 세부 수칙
+1. **Target Directory**: `E:\Wiki\2nd\Agent`
+2. **Git Address**: `https://github.com/g1nations/TeamG1.git`
+3. **Auto-Pilot**: 해당 명령어가 입력되면 추가 질문 없이 즉시 실행 후 보고한다.
+4. **Note**: `2nd` 프로젝트 하위에 있으나, 별도의 리모트 주소를 가진 독립 구역으로 취급한다.
+
+---
+**승인인**: AI 개발부장 코다리 🫡
+**일시**: 2026-04-22

10_Wiki/Topics/_Archive_Orphans/Global_Singleton.md

@@ -0,0 +1,24 @@
+---
+category: Other
+tags: [auto-wikified, technical-documentation, other]
+title: Global Singleton
+description: "글로벌 싱글톤(Global Singleton)은 애플리케이션 내에서 공유되는 상태나 기능을 개별 컴포넌트 외부로 추출하여 단일 객체 인스턴스로 관리하는 디자인 패턴이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Global Singleton
+
+## 📌 Brief Summary
+글로벌 싱글톤(Global Singleton)은 애플리케이션 내에서 공유되는 상태나 기능을 개별 컴포넌트 외부로 추출하여 단일 객체 인스턴스로 관리하는 디자인 패턴이다 [1, 2]. 이 패턴을 활용하면 컴포넌트 계층 구조와 무관하게 어디서든 해당 상태에 접근하거나 관련 액션을 트리거할 수 있다 [1]. 주로 프론트엔드의 전역 상태 관리나 백엔드의 공통 인프라스트럭처(예: 로거) 인스턴스를 유지하는 데 활용된다 [1, 3].
+
+## 📖 Core Content
+* **상태 추출 및 중앙 집중화:** 여러 컴포넌트가 동일한 상태에 의존하거나 이를 변경해야 할 때, 글로벌 싱글톤은 상태를 최상위로 끌어올릴 때 발생하는 'Prop Drilling' 문제를 해결하는 직관적인 대안을 제공한다 [1, 4]. 상태를 글로벌 싱글톤으로 추출하면 전체 컴포넌트 트리가 하나의 큰 뷰(View)처럼 기능하게 되며, 상태와 상태를 변경하는 로직이 한 곳에 집중된 단일 진실 공급원(Single Source of Truth)을 확보할 수 있다 [1, 5].
+* **공통 인프라스트럭처의 공유 인스턴스:** 백엔드(예: C#) 환경에서 싱글톤이나 정적 로거 팩토리는 로깅과 같은 횡단 관심사(Cross-Cutting Concerns)의 공유 인스턴스를 유지하는 데 매우 좋은 접근법이다 [3]. 이를 통해 인프라 구성 요소를 최대한 얇게 유지하면서도 애플리케이션 전역에서 재사용할 수 있다 [3].
+* **표준화된 개발 소통 제공:** 단일 객체의 사용을 상정하는 싱글톤 패턴은 개발자들 사이에서 해당 코드가 어떻게 동작하는지 쉽게 의사소통하고 예측할 수 있도록 돕는 공통의 기반 기술이 된다 [2].
+
+## ⚖️ Trade-offs & Caveats
+* **서버 사이드 렌더링(SSR) 환경에서의 데이터 유출 취약성:** SSR을 지원하는 환경에서 상태를 전역 싱글톤으로 관리할 경우, 여러 사용자의 요청(Request) 간에 동일한 스토어가 공유되어 데이터 유출과 같은 치명적인 문제가 발생할 수 있다 [6, 7]. 이를 해결하기 위해 Vue의 Pinia와 같은 현대적인 상태 관리 라이브러리는 전역 싱글톤을 피하고 각 요청마다 새로운 스토어 인스턴스를 생성하는 방식을 취한다 [7].
+* **임의적 상태 변이(Arbitrary Mutations)의 위험:** 글로벌 싱글톤 상태를 컴포넌트에서 자유롭게 수정할 수 있도록 방치하면 코드가 엉키고 장기적인 유지보수성이 크게 저하된다 [8]. 이를 방지하려면 상태 변이 로직 역시 중앙 집중화해야 하며, 의도를 명확히 표현하는 전용 메서드를 통해서만 상태를 제어하도록 제한해야 한다 [8].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Hermes_Engine.md

@@ -0,0 +1,24 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Hermes Engine
+description: "Hermes는 React Native 애플리케이션에서 자바스크립트 로직을 실행하는 데 사용되는 엔진이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Hermes Engine
+
+## 📌 Brief Summary
+Hermes는 React Native 애플리케이션에서 자바스크립트 로직을 실행하는 데 사용되는 엔진이다 [1, 2]. 고도로 최적화된 환경을 제공하며, React Native의 새로운 브릿지리스 아키텍처의 핵심인 JSI(JavaScript Interface)와 완벽하게 호환되어 작동한다 [3]. 
+
+## 📖 Core Content
+* **애플리케이션 로직 실행:** React Native는 기본적으로 Hermes와 같은 자바스크립트 코어 엔진을 탑재하여 애플리케이션의 내부 로직을 실행하고, 실제 렌더링은 네이티브 구성 요소를 호출하여 처리하는 아키텍처를 따른다 [1, 2, 4].
+* **신규 아키텍처(JSI) 호환:** React Native의 새로운 아키텍처를 구성하는 필수 요소인 JSI(JavaScript Interface)는 고도로 최적화된 Hermes 엔진을 포함한 다양한 자바스크립트 엔진을 지원하여 자바스크립트와 네이티브 간의 효율적인 통신을 돕는다 [3].
+* **앱 크기(App Size) 기준점 형성:** React Native 앱을 배포할 때 Hermes 자바스크립트 엔진이 함께 포함되어 제공되며, 이로 인해 최소 앱 크기(baseline APK size)는 대략 5~8MB 수준을 구성하게 된다 [1].
+
+## ⚖️ Trade-offs & Caveats
+* **초기 구동 지연(Startup Latency):** 앱이 콜드 스타트(Cold Start)를 할 때 Hermes 자바스크립트 엔진을 초기화하고 JS 번들을 파싱하는 과정을 반드시 거쳐야 한다 [1]. 이로 인해 코드를 직접 기계어로 사전 컴파일(AOT)하는 프레임워크(예: Flutter)와 비교했을 때, 앱 실행 시 대략 100~300 밀리초(ms) 정도의 측정 가능한 지연 시간이 추가로 발생한다는 단점이 있다 [1].
+
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Hexagonal_Architecture_Ports_and_Adapters.md

@@ -0,0 +1,36 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Hexagonal Architecture (Ports and Adapters)
+description: "헥사고날 아키텍처(포트와 어댑터 패턴)는 애플리케이션의 핵심 비즈니스 로직을 데이터베이스, UI, API 등 외부 기술적 종속성으로부터 완전히 고립시키기 위해 고안된 소프트웨어 아키텍처 패턴입니다."
+last_updated: 2026-05-04
+---
+
+# Hexagonal Architecture (Ports and Adapters)
+
+## 📌 Brief Summary
+헥사고날 아키텍처(포트와 어댑터 패턴)는 애플리케이션의 핵심 비즈니스 로직을 데이터베이스, UI, API 등 외부 기술적 종속성으로부터 완전히 고립시키기 위해 고안된 소프트웨어 아키텍처 패턴입니다. [1-3] 2005년 Alistair Cockburn에 의해 처음 소개되었으며, 시스템을 더 유지보수하고 테스트 및 확장하기 쉽게 만드는 것을 주된 목적으로 합니다. [2] 내부 도메인 로직과 외부 세계 간의 상호작용은 명확한 규약을 가진 인터페이스인 '포트(Port)'와 이를 구체적으로 구현하는 '어댑터(Adapter)'를 통해서만 이루어집니다. [3-5]
+
+## 📖 Core Content
+*   **설계 철학과 구조적 메커니즘**
+    *   육각형(Hexagon) 모양은 전통적인 N-티어(N-Tier) 계층 구조와 같이 수직적인 계층 관계를 내포하지 않는다는 것을 은유적으로 보여줍니다. [6] 다수의 연결 지점(포트)을 통해 다양한 어댑터를 쉽게 끼워 넣을 수(plug in) 있는 다형성을 시각적으로 나타냅니다. [6]
+    *   비즈니스 로직과 외부 인프라의 강한 결합(Tight coupling)을 방지하기 위해 의존성 역전 원칙(Dependency Inversion Principle)을 적용합니다. [2, 7] 이를 통해 외부 기술 스택의 변경(예: 관계형 DB에서 NoSQL로의 전환)이 핵심 도메인 로직에 영향을 미치지 않도록 시스템을 보호합니다. [8]
+
+*   **포트(Ports)와 어댑터(Adapters)의 역할 분리**
+    *   **포트(Ports)**: 시스템의 진입점으로서 애플리케이션이 '무엇(What)'을 할 수 있는지 정의하는 인터페이스(유즈케이스)입니다. [5, 9] 입력(Inbound) 포트와 출력(Outbound) 포트로 나뉘며, 애플리케이션 계층에 속합니다. [8, 10]
+    *   **어댑터(Adapters)**: 외부 시스템과 핵심 비즈니스 로직 사이에서 데이터를 변환하고 상호작용을 직접 처리하는 '어떻게(How)'에 해당하는 구현체입니다. [5, 11] 인프라 계층에 위치합니다. [10]
+        *   **기본 어댑터 (Primary Adapters)**: 외부의 요청을 받아 애플리케이션 내부(포트)로 전달하는 입력 핸들러(Controller, CLI, API Gateway 등)입니다. [11, 12]
+        *   **보조 어댑터 (Secondary Adapters)**: 애플리케이션의 결과를 외부 세계로 전달하는 출력 핸들러(Repository, 외부 API 클라이언트, 메시지 브로커 등)입니다. [12]
+
+*   **계층 구조와 데이터 흐름(DTO) 관리**
+    *   **도메인(Domain) 계층**: 순수한 비즈니스 규칙과 엔티티만 존재하며, 어떠한 외부 라이브러리나 프레임워크에도 의존하지 않아야 합니다. [8]
+    *   **애플리케이션(Application) 계층**: 유즈케이스를 처리하는 계층으로, 외부 인프라와의 결합을 막기 위해 **DTO(Data Transfer Object)**는 이 계층에 정의되어야 합니다. [8, 13, 14] DTO를 통해 상호작용(UI) 계층과 애플리케이션 계층 간의 데이터 흐름을 도메인 오염 없이 관리합니다. [13, 15]
+    *   **인프라/어댑터(Infrastructure/Adapter) 계층**: DTO와 내부 도메인/데이터베이스 엔티티 간의 변환(Mapping)을 담당하여, 내부 데이터 모델의 변경이 외부 API 스펙을 파괴하지 않도록 하는 안전장치 역할을 수행합니다. [8]
+
+## ⚖️ Trade-offs & Caveats
+*   **복잡도 및 오버헤드 증가**: 헥사고날 아키텍처는 고도의 모듈화와 테스트 용이성을 제공하지만, 모든 프로젝트에 적합한 것은 아닙니다. 시스템 구조가 단순하거나 마감일이 촉박한 소규모 프로젝트의 경우, 계층을 엄격히 분리하는 이 구조가 불필요한 오버헤드(Overhead)로 작용할 수 있습니다. [16]
+*   **보일러플레이트 코드 발생**: 인터페이스(포트)와 구현체(어댑터)를 분리하고, 도메인 모델과 DTO, 데이터베이스 엔티티를 명확히 구분하여 매퍼(Mapper)를 통해 변환하는 과정이 필수적이므로 초기 개발 단계에서 작성해야 할 보일러플레이트 코드가 크게 증가합니다. [8]
+*   **높은 아키텍처 이해도 요구**: DTO나 인터페이스를 어느 계층에 배치해야 하는지(예: 인프라 기술이 애플리케이션 계층으로 침투하지 않도록 DTO를 애플리케이션 계층에 올바르게 위치시켜야 함)와 같은 아키텍처적 판단이 지속적으로 요구되어, 팀원들에게 패턴에 대한 명확하고 높은 이해도가 강제됩니다. [10, 13, 14, 17]
+
+--- 
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Hydration_하이드레이션.md

@@ -0,0 +1,26 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Hydration (하이드레이션)
+description: "하이드레이션(Hydration)은 서버에서 렌더링되어 전달된 정적인 HTML('건조한' HTML)에 상호작용성과 이벤트 핸들러라는 '물'을 주어 동적인 웹 페이지로 만드는 과정입니다 [1]."
+last_updated: 2026-05-04
+---
+
+# Hydration (하이드레이션)
+
+## 📌 Brief Summary
+하이드레이션(Hydration)은 서버에서 렌더링되어 전달된 정적인 HTML('건조한' HTML)에 상호작용성과 이벤트 핸들러라는 '물'을 주어 동적인 웹 페이지로 만드는 과정입니다 [1]. 프론트엔드 프레임워크는 전체 DOM을 새로 다시 그리지 않고, 기존 DOM 트리를 재사용하여 이벤트 리스너를 부착하는 방식으로 작동합니다 [2, 3]. 최근에는 초기 로딩 시간 단축과 상호작용성 개선을 위해 React의 선택적 하이드레이션(Selective Hydration)이나 Vue의 지연 하이드레이션(Lazy Hydration) 같은 최적화 기법이 활용되고 있습니다 [4, 5].
+
+## 📖 Core Content
+* **작동 원리 (Mechanism):** 하이드레이션은 페이지를 처음부터 렌더링하는 과정이 아닙니다 [3]. 리액트(React)의 경우, 구축 중인 Fiber 트리와 병렬로 기존의 서버 렌더링 DOM 트리를 순회하면서 각 Fiber를 해당하는 DOM 노드에 일치시키고(`fiber.stateNode`에 참조 저장), 이벤트 리스너를 부착합니다 [3]. 이처럼 **DOM을 완전히 새로 만들지 않고 재사용**하기 때문에 새로운 렌더링(Fresh render)보다 더 빠르게 동작합니다 [3].
+* **선택적 하이드레이션 (Selective Hydration):** 과거에는 전체 트리가 순차적으로 하이드레이션될 때까지 페이지의 어떤 부분도 상호작용할 수 없는 한계가 있었습니다 [3]. 이를 해결하기 위해 React 18은 **우선순위 기반의 선택적 하이드레이션**을 도입했습니다 [4]. 사용자가 특정 요소를 클릭하면 React는 기존의 하이드레이션 작업을 중단하고, 사용자가 상호작용한 부분을 처리하는 데 필요한 부분만 우선적으로 하이드레이션한 뒤, 나머지 트리의 작업을 재개합니다 [4].
+* **지연 하이드레이션 (Lazy Hydration):** Vue 3.5 버전에서는 서버 사이드 렌더링(SSR)의 성능 향상을 위해 지연 하이드레이션을 도입했습니다 [5]. 이 기능은 **컴포넌트가 뷰포트(Viewport)에 보일 때만 하이드레이션되도록 허용**하여, 필요할 때까지 컴포넌트의 활성화를 지연시킴으로써 초기 로드 시간을 줄이고 전반적인 애플리케이션 성능을 최적화합니다 [5]. e-커머스 등 콘텐츠가 많은 애플리케이션에서 매우 유용합니다 [6].
+* **서버 컴포넌트와의 관계:** 리액트 서버 컴포넌트(React Server Components, RSC)는 클라이언트로 자바스크립트 코드가 전송되지 않고 오직 서버에서만 실행되므로 **하이드레이션 과정 자체가 아예 존재하지 않습니다** [7].
+
+## ⚖️ Trade-offs & Caveats
+* **하이드레이션 갭 (Hydration Gap):** SSR을 통해 사용자는 렌더링이 완료된 것처럼 보이는 페이지를 즉시 볼 수 있지만, 자바스크립트가 완전히 다운로드되고 **하이드레이션이 끝나기 전까지는 버튼을 클릭해도 아무런 반응이 없는 '하이드레이션 갭' 현상**이 발생합니다 [2]. 페이지가 상호작용 가능해 보이지만 실제로는 그렇지 않은 시기가 존재합니다 [2].
+* **클라이언트 병목 현상:** DOM 트리를 재사용하더라도 결국 브라우저는 대량의 자바스크립트 번들을 모두 다운로드하고 실행해야 합니다 [8]. 또한 트리 상단에 있는 단일의 느린 컴포넌트가 트리를 순회하는 하이드레이션 과정을 막고 있다면, 트리의 하단에 있는 버튼의 클릭 핸들러 부착까지 지연되어 **전체 페이지의 응답성이 차단되는 병목**을 초래할 수 있습니다 [3].
+* **이중 작업 구조 (Two-Trip Problem):** 서버에서 HTML을 그리기 위해 실행했던 작업과 데이터 패칭을, 클라이언트에서 하이드레이션을 진행하며 브라우저가 자바스크립트를 다시 실행하여 중복 수행하게 되는 구조적 비효율성이 존재합니다 [8]. 이러한 서버 렌더링의 근본적인 한계는 결국 클라이언트로 코드를 보내지 않는 '리액트 서버 컴포넌트(RSC)'가 등장하게 된 핵심 배경이 되었습니다 [8, 9].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Impeller.md

@@ -0,0 +1,28 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Impeller
+description: "Impeller는 모바일 개발 프레임워크 Flutter에서 기존의 Skia 엔진을 대체하기 위해 새롭게 도입된 자체 그래픽 렌더링 엔진이다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Impeller
+
+## 📌 Brief Summary
+Impeller는 모바일 개발 프레임워크 Flutter에서 기존의 Skia 엔진을 대체하기 위해 새롭게 도입된 자체 그래픽 렌더링 엔진이다 [1-3]. 기존 런타임 환경에서 셰이더(Shader)를 컴파일할 때 발생하던 프레임 끊김(Jank) 문제를 해결하기 위해, 빌드 시점에 셰이더를 미리 컴파일하는 방식을 채택했다 [2, 4, 5]. 이를 통해 첫 프레임부터 일관되고 부드러운 UI 렌더링과 최적화된 성능을 제공하는 것이 핵심적인 특징이다 [4, 5].
+
+## 📖 Core Content
+* **셰이더 컴파일 최적화 및 Jank 문제 해결**: 과거 Flutter의 기본 그래픽 엔진이었던 Skia는 사용자가 앱과 상호작용할 때 런타임에서 UI를 네이티브 코드로 컴파일해야 했고, 이로 인해 처음 복잡한 애니메이션이 실행될 때 심각한 버벅임(Shader compilation jank)이 발생했다 [2, 3, 5]. Impeller는 애플리케이션 빌드 단계에서 더 작고 단순하며 최적화된 셰이더 세트를 미리 컴파일(Pre-compile)해 두어 이러한 렌더링 병목 현상을 근본적으로 제거한다 [4-6].
+* **자체 렌더링 철학 유지**: React Native처럼 플랫폼의 네이티브 컴포넌트(iOS의 UIKit 등)에 의존하지 않고, Impeller를 통해 화면의 모든 픽셀을 직접 그린다 [7-9]. 이를 통해 플랫폼에 구애받지 않는 일관된 커스텀 위젯과 '픽셀 퍼펙트(Pixel-perfect)' 룩앤필을 구현할 수 있다 [7, 10]. 
+* **최신 모바일 GPU 최적화**: Impeller는 테셀레이션(Tessellation) 기반 렌더링 방식을 사용하여 최신 모바일 GPU에 맞춰 설계되었다 [5]. 또한 Metal, Vulkan과 같은 고급 GPU API를 활용하도록 만들어져 더 낮은 전력 소비와 효율적인 렌더링 효율성을 자랑한다 [3].
+* **극대화된 애니메이션 성능**: 셰이더가 이미 준비된 상태로 앱이 실행되기 때문에, 고주사율 기기에서도 일관된 60fps 또는 120fps의 프레임 속도를 매끄럽게 보장한다 [4, 11, 12]. 이로 인해 시각적으로 복잡한 전환 및 애니메이션 구현에 탁월한 강점을 지닌다 [4].
+* **진행 및 성숙도**: 2023년 Flutter 3.10 버전부터 iOS 환경에서는 기본 렌더러로 안정화되어 프로덕션 레벨에 투입되었으며 [5, 13], Android 환경에서도 지속적인 발전을 거치며 적용을 확대하고 있다 [2, 5, 11, 13]. 향후 업데이트에서는 커스텀 셰이더 지원 및 3D 지원 기능까지 확장될 계획이다 [14].
+
+## ⚖️ Trade-offs & Caveats
+* **기본 앱 용량(APK Size) 증가**: 기기에 앱을 배포할 때 Dart 런타임과 함께 자체 Impeller 렌더링 엔진 자체가 파일에 포함되어야 한다 [12]. 이로 인해 최소 앱 크기가 약 8~12MB 정도로 형성되며, 네이티브 뷰를 직접 활용하여 별도의 렌더링 엔진 탑재가 필요 없는 프레임워크(예: React Native의 5~8MB)에 비해 베이스라인 파일 크기가 상대적으로 크다 [12].
+* **메모리 사용량 오버헤드**: 플랫폼의 네이티브 UI 컴포넌트를 사용하지 않고 독자적인 위젯 트리, 레이어 트리 및 Impeller 렌더링 파이프라인을 유지해야 하므로 기본적으로 메모리 오버헤드가 발생한다 [15]. 대다수 앱에서 20~50MB 정도의 메모리 차이가 나며, 플래그십 기기에서는 무시할 만한 수준이지만 저사양 기기에서는 유의미한 단점이 될 수 있다 [15].
+* **플랫폼별 도입 속도의 불균형**: iOS 생태계에서는 이미 문제점들이 해결되어 기본값으로 훌륭히 작동하고 있으나, Android 플랫폼의 경우 상대적으로 프리뷰 단계에서 출발하여 빠르게 성숙해 나가는 과정에 있다 [5, 11]. 따라서 플랫폼 간 Impeller의 최적화 수준이나 적용 시기에 일시적인 과도기적 불균형이 존재할 수 있다 [5, 13].
+
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Interpretability.md

@@ -0,0 +1,28 @@
+---
+id: INTERPRET-001
+category: Unified
+confidence_score: 1.0
+tags: [ai, explainable-ai, xai, machine-learning, trust]
+last_reinforced: 2026-04-26
+---
+
+# Interpretability (해석 가능성)
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "AI 블랙박스의 내부를 들여다보는 지적 렌즈" — 머신러닝 모델의 판단 근거와 내부 작동 기제를 인간이 이해할 수 있는 형태로 설명하고 분석하는 능력.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** 복잡한 신경망 가중치 뒤에 숨겨진 논리 구조를 식별하여, AI의 결정이 우연인지 실질적인 학습 결과인지 검증하는 패턴.
+- **세부 내용:**
+    - **Global Interpretability:** 모델 전체의 거동과 중요한 변수들의 영향을 파악 (예: Feature Importance).
+    - **Local Interpretability:** 특정 개별 데이터에 대해 왜 그런 결정을 내렸는지 분석 (예: LIME, SHAP).
+    - **Mechanistic Interpretability:** 모델 내부의 특정 뉴런이나 '회로(Circuit)'가 수행하는 구체적인 알고리즘적 역할을 규명.
+    - **Trust & Safety:** 오답의 원인을 파악하고, 모델의 편향이나 위험성을 사전에 감지하기 위한 필수 요건.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 성능을 위해 이해를 포기하던 '블랙박스' 시대에서, 신뢰성과 규제 대응을 위해 '설명 가능한 AI(XAI)'가 필수적인 시대로 진입.
+- **정책 변화:** Antigravity 프로젝트는 모든 지식 보강 작업 시 모델이 참조한 근거(Raw Source)를 명시하여 결과물의 해석 가능성과 신뢰도를 확보함.
+
+## 🔗 지식 연결 (Graph)
+- Explainable-AI, Circuit-Discovery, Feature-Clamping, AI-Ethics
+- **Raw Source:** 10_Wiki/Topics/AI/Interpretability.md

10_Wiki/Topics/_Archive_Orphans/Inversion_of_Control_IoC.md

@@ -0,0 +1,31 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Inversion of Control (IoC)
+description: "제어의 역전(Inversion of Control, IoC)은 소프트웨어 컴포넌트 간의 결합도를 낮추고 재사용성을 극대화하기 위해 객체의 생성이나 렌더링 제어권을 프레임워크 또는 소비 컴포넌트로 위임하는 설계 원칙이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Inversion of Control (IoC)
+
+## 📌 Brief Summary
+제어의 역전(Inversion of Control, IoC)은 소프트웨어 컴포넌트 간의 결합도를 낮추고 재사용성을 극대화하기 위해 객체의 생성이나 렌더링 제어권을 프레임워크 또는 소비 컴포넌트로 위임하는 설계 원칙이다 [1, 2]. 백엔드에서는 주로 IoC 컨테이너와 의존성 주입(DI)을 통해 컴포넌트 간의 종속성 그래프를 자동 관리하는 방식으로 사용된다 [2, 3]. 프론트엔드 환경에서는 스코프 슬롯(Scoped Slots)과 동적 컴포넌트를 활용하여 렌더링에 대한 제어권을 부모에게 역전시키는 형태로 활용된다 [1, 4].
+
+## 📖 Core Content
+* **백엔드의 IoC 컨테이너 및 의존성 주입 (Spring Boot & NestJS)**
+  * Spring Boot는 Java 어노테이션을 사용하여 컴포넌트의 동작과 관계를 선언하며, 애플리케이션 시작 시점에 Spring IoC 컨테이너가 이 어노테이션들을 읽어 의존성 그래프를 구축하고 올바른 순서로 빈(Beans)을 인스턴스화한다 [2]. 
+  * TypeScript 기반의 NestJS 역시 이와 동일한 엔터프라이즈 Java 패턴을 도입하여 데코레이터 기반의 의존성 주입(DI) 컨테이너를 사용한다 [5, 6]. 개발자가 생성자에 필요한 종속성을 선언하면 프레임워크가 이를 자동으로 주입하므로, 컴포넌트 간 결합도가 낮아지고 모의 객체(Mock)를 활용한 단위 테스트가 극적으로 쉬워진다 [3, 7].
+
+* **프론트엔드의 렌더링 제어 역전 (Vue 3)**
+  * Vue 3 대규모 애플리케이션에서 제어의 역전은 '헤드리스(Headless)' 또는 '제네릭' 컴포넌트를 구축하여 다수의 모듈에서 재사용성을 극대화하는 궁극적인 전략으로 사용된다 [1].
+  * 동적 `:is` 속성과 스코프 슬롯(Scoped Slots)을 활용하는 '렌더 프로프(Render Prop)' 패턴을 통해, 자식 컴포넌트는 가상화, 접근성, 키보드 내비게이션 같은 복잡한 동작과 내부 상태만 관리한다 [1, 4]. 그리고 실제 HTML 구조와 시각적 렌더링에 대한 완전한 제어권은 부모 컴포넌트(소비자)에게 위임(역전)하여 구조를 유연하게 만든다 [1, 4].
+
+## ⚖️ Trade-offs & Caveats
+* **초기 학습 곡선**: Spring Boot의 IoC 컨테이너나 NestJS의 DI, 데코레이터, 모듈 시스템은 개발자가 구조에 익숙해지기까지 상대적으로 높은 학습 시간이 필요하다 [5, 8].
+* **프레임워크 시작 시간(Startup Time) 병목**: Spring Boot의 경우 IoC 컨테이너가 수많은 어노테이션과 자동 구성을 스캔하고 빈을 메모리에 적재하는 과정에서 5~30초의 느린 시작 시간을 가질 수 있다 [9, 10]. 이는 'Scale-to-zero'를 지향하는 서버리스 배포 환경에서는 큰 제약 사항이 될 수 있다 [10].
+* **테스트 가능성 및 결합도 훼손 위험**: 의존성 주입(DI) 컨테이너를 우회하여 수동으로 객체를 생성(예: `new Service()`)하면 제어의 역전이 제공하는 핵심 이점인 테스트 가능성(Testability)이 파괴된다 [7]. 또한, `@Global()` 모듈을 남용할 경우 "모든 것이 모든 곳에서 사용 가능한" 상태를 만들어 모듈 시스템의 존재 이유를 퇴색시킬 수 있다 [11].
+* **프론트엔드 계약(Contract) 관리의 복잡성**: 프론트엔드에서 제어의 역전을 위해 스코프 슬롯 등을 사용할 때 컴포넌트의 Props와 Emits 계약을 타입스크립트로 엄격하게 정의하지 않으면, 대규모 팀 환경에서 통합 시 런타임 오류가 발생하거나 예측 불가능한 버그를 초래할 수 있다 [12, 13].
+
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Kafka_&_RabbitMQ.md

@@ -0,0 +1,28 @@
+---
+category: Backend
+tags: [auto-wikified, technical-documentation, backend]
+title: Kafka & RabbitMQ
+description: "Kafka와 RabbitMQ는 마이크로서비스 아키텍처에서 서비스 간 통신 및 이벤트 기반 처리를 위해 사용되는 대표적인 메시지 브로커(Message Broker) 기술이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Kafka & RabbitMQ
+
+## 📌 Brief Summary
+Kafka와 RabbitMQ는 마이크로서비스 아키텍처에서 서비스 간 통신 및 이벤트 기반 처리를 위해 사용되는 대표적인 메시지 브로커(Message Broker) 기술이다 [1, 2]. 주로 Spring Boot와 NestJS와 같은 현대적인 백엔드 프레임워크에서 비동기 메시징 큐(Message Queue)를 구현하기 위한 핵심 인프라로 활용된다 [1, 3]. 제공된 소스에서는 두 기술에 대한 깊이 있는 아키텍처 원리보다는 프레임워크와의 통합 지원 여부를 중심으로 간단히 언급되고 있다 [1, 3].
+
+## 📖 Core Content
+* **NestJS에서의 통합 지원:** 
+  NestJS는 마이크로서비스 간 통신을 위해 내장된 전송 계층(Transport Layer)을 제공하며, 이를 통해 Kafka와 RabbitMQ를 기본적으로 지원한다 [1]. `@nestjs/microservices` 전송기(Transporters)를 활용하여 프로덕션 수준의 마이크로서비스를 구축할 수 있도록 문서화되어 있다 [2, 3]. 전송 계층의 API가 일관되게 제공되므로, 메시지 브로커 간(예: RabbitMQ에서 Kafka로)의 전환이 비교적 직관적이고 용이하다는 특징이 있다 [1].
+* **Spring Boot에서의 통합 지원:** 
+  엔터프라이즈 환경에서 널리 쓰이는 Spring Boot는 `Spring AMQP`를 통해 RabbitMQ를, `Spring Kafka`를 통해 Kafka를 지원하여 강력한 메시지 큐 시스템을 구성할 수 있도록 돕는다 [3]. 
+* **한계:** 
+  그 외에 두 기술 간의 구체적인 아키텍처 차이, 내부 동작 방식, 메시지 발행/구독(Pub/Sub) 패턴의 세부 구현 등에 대해서는 소스에 관련 정보가 부족합니다.
+
+## ⚖️ Trade-offs & Caveats
+소스에 관련 정보가 부족합니다. 
+
+(제공된 문헌에서는 NestJS와 Spring Boot 프레임워크가 Kafka와 RabbitMQ를 연동하여 사용할 수 있다는 사실 외에, 두 메시지 브로커를 도입할 때의 기술적 선택 기준, 최적화 방법, 부작용 및 제약 사항(Trade-off)에 대한 상세한 내용을 다루고 있지 않습니다.)
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Knowledge-Extraction-Protocol.md

@@ -0,0 +1,23 @@
+# 📑 지식 자산 증분 추출 프로토콜 (Incremental Extraction Protocol)
+
+## 1. 개요 (Overview)
+본 문서는 Connect AI 시스템의 'Thinking Mode'에서 표시되는 지식 자산을 로컬 위키 시스템으로 안전하게 이식하고, 향후 중복 없이 새로운 데이터만 필터링하여 가져오기 위한 운영 표준을 정의한다.
+
+## 2. 데이터 베이스라인 (Baseline)
+- **추출 일시**: 2026-04-29
+- **추출 수량**: 1,535개 (Knowledge Assets)
+- **추출 로직**: `E:\Wiki\2nd\10_Wiki\Topics` 내 마크다운 파일 중 알파벳 순 상위 1,535개 선별
+- **인벤토리**: [knowledge_inventory_1535.json](file:///E:/Wiki/2nd/10_Wiki/Skills/knowledge_inventory_1535.json)
+
+## 3. 필터링 규칙 (Filtering Rules)
+향후 재추출 요청 시 다음의 로직을 적용한다:
+1.  **경로 대조**: `knowledge_inventory_1535.json`에 명시된 `RelativePath`와 동일한 파일은 무시한다.
+2.  **신규성 판정**: 기존 인벤토리에 존재하지 않는 새로운 파일명이 발견되거나, 동일 파일명이라도 수정 일시(`LastWriteTime`)가 최신인 경우만 '신규 지식'으로 간주한다.
+3.  **8대 카테고리 유지**: 추출 시 원본의 8대 분류 체계를 유지하며 `00_Raw` 폴더로 이식한다.
+
+## 4. 실행 가이드 (Execution Guide)
+- **명령어**: `python E:\Wiki\Wonseok_AI_original\scratch\incremental_sync.py` (차기 구현 예정)
+- **주의 사항**: 원본 `Topics` 폴더의 파일 개수가 1,535개를 초과하여 증가하더라도, 인벤토리에 기록된 파일들은 중복으로 가져오지 않도록 엄격히 제한한다.
+
+---
+🫡 **"지식은 축적될 때 비로소 힘을 발휘한다."** - AI 개발부장 코다리 승인 🚩🐟

10_Wiki/Topics/_Archive_Orphans/Mapper_-_ModelMapper.md

@@ -0,0 +1,24 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Mapper / ModelMapper
+description: "ModelMapper는 DTO(Data Transfer Object), 도메인 모델, 엔티티 등 서로 다른 객체 간의 데이터를 매핑(변환)하기 위해 사용되는 라이브러리이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Mapper / ModelMapper
+
+## 📌 Brief Summary
+ModelMapper는 DTO(Data Transfer Object), 도메인 모델, 엔티티 등 서로 다른 객체 간의 데이터를 매핑(변환)하기 위해 사용되는 라이브러리이다 [1]. 주로 헥사고날 아키텍처나 계층형 아키텍처가 적용된 프레임워크(예: Spring Boot)에서 각 계층을 넘나드는 데이터를 변환하여 계층 간 결합도를 낮추는 데 활용된다 [1, 2].
+
+## 📖 Core Content
+* **계층 간 데이터 변환 책임 분리**: 헥사고날 아키텍처(Ports and Adapters)의 실전 구현에서 매핑 작업은 각 어댑터의 핵심 역할 중 하나이다. 예를 들어, 웹 어댑터(Web Adapter)는 들어오는 API 모델(DTO)과 내부 도메인 모델 간의 데이터를 매핑하고, 리포지토리 어댑터(Repository Adapter)는 도메인 모델과 데이터베이스 엔티티 간의 데이터를 매핑하여 변환을 처리한다 [2, 3].
+* **외부 API 스펙 파괴 방지 (안전장치)**: DTO와 엔티티를 명확히 분리하고 매퍼(Mapper)를 통해 데이터를 변환하는 과정은 아키텍처적으로 중요한 안전장치 역할을 한다 [4]. 이를 통해 내부 데이터베이스 모델(엔티티)의 구조가 변경되더라도, 매핑 레이어에 의해 외부로 노출되는 API 스펙(DTO)이 파괴되지 않도록 보호할 수 있다 [4].
+* **객체 간 매핑 단순화**: ModelMapper와 같은 라이브러리는 위와 같이 분리된 DTO, 도메인, 엔티티 모델 간의 데이터 매핑 및 복사 과정을 단순화하여 개발자가 비즈니스 로직에 집중할 수 있도록 지원한다 [1].
+
+## ⚖️ Trade-offs & Caveats
+* **보일러플레이트 및 개발 공수 증가**: 모델과 API 스펙을 분리하기 위해 각 요청(Request)의 변형마다 별도의 DTO를 생성하고, 이를 도메인 객체나 엔티티로 매핑하는 구조를 유지하는 것은 개발자에게 상당한 추가 작업(effort)을 요구하며 코드량을 증가시킨다 [5].
+* ModelMapper 라이브러리 작동 방식 자체에 따른 성능적 부작용이나 세부적인 최적화 제약 사항 등에 대해서는 소스에 관련 정보가 부족합니다.
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Material Design System.md

@@ -0,0 +1,46 @@
+---
+category: DevOps_and_Security
+tags: [auto-wikified, technical-documentation, merged, devops_and_security]
+title: Design System
+description: "디자인 시스템은 애플리케이션 전반의 일관성을 유지하기 위해 추출된 재사용 가능한 컴포넌트와 패턴의 공유 라이브러리이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Design System
+
+
+## 📌 Brief Summary
+디자인 시스템은 애플리케이션 전반의 일관성을 유지하기 위해 추출된 재사용 가능한 컴포넌트와 패턴의 공유 라이브러리이다 [1, 2]. 주로 모달(Modal), 탭(Tabs), 아코디언(Accordion), 선택 상자(Select)와 같은 UI 원시(primitives) 요소들로 구성되며, 개발자와 디자이너 간의 협업 및 확장성을 돕는다 [2, 3]. React 등 현대 프레임워크에서는 복합 컴포넌트(Compound Components)와 같은 고급 아키텍처 패턴을 활용하여 유연하고 견고한 디자인 시스템을 구축한다 [4, 5].
+
+## 📖 Core Content
+*   **React 기반 디자인 시스템의 핵심 패턴**: 디자인 시스템이나 공유 컴포넌트 라이브러리를 구축할 때 가장 필수적으로 사용되는 아키텍처 패턴은 복합 컴포넌트(Compound Components)와 렌더 프롭스(Render Props), 그리고 커스텀 훅(Custom Hooks)이다 [2, 4, 6]. Radix UI, Headless UI, React Aria, ShadCN, Material UI와 같은 유명 오픈소스 라이브러리들은 이러한 패턴을 활용한 디자인 시스템 설계의 훌륭한 모범 사례를 제공한다 [2, 5].
+*   **복합 컴포넌트(Compound Components)를 통한 유연성 확보**: 디자인 시스템에서 컴포넌트는 다수의 프로퍼티(Props)를 전달받는 거대한 단일 컴포넌트가 되어서는 안 된다 [7]. 대신, 하위 컴포넌트들이 React Context를 통해 암시적 상태를 공유하도록 설계하여, 디자인 시스템을 사용하는 개발자(소비자)가 UI의 구조를 자유롭게 제어할 수 있게 해야 한다 [7, 8].
+*   **헤드리스(Headless) 컴포넌트 라이브러리**: 렌더 프롭스나 커스텀 훅 패턴은 상태 관리나 드래그 앤 드롭, 폼 상태와 같은 '동작 로직(Behavioral Logic)'만을 공유하고 시각적 표현(UI)은 전적으로 소비자에게 맡기는 형태의 디자인 시스템(헤드리스 컴포넌트)을 구축하는 데 이상적이다 [9, 10].
+*   **코드 기반 프로토타이핑과의 동기화**: UXPin Merge와 같은 도구를 활용하여, 디자인 시스템 팀이 구축한 실제 React 또는 Vue 3 코드 컴포넌트를 디자이너가 프로토타이핑 환경에서 직접 사용하게 할 수 있다 [11, 12]. 이를 통해 디자인과 개발 간의 상호작용 패턴 및 시각적 일관성을 최종 제품까지 완벽하게 동기화할 수 있다 [12].
+
+## ⚖️ Trade-offs & Caveats
+*   **오버엔지니어링(Over-Engineering)의 위험**: 디자인 시스템 구축 시 모든 컴포넌트에 복잡한 패턴을 적용할 필요는 없다 [5]. 몇 개의 프로퍼티만 받는 단순한 `<Button>` 요소 등에 굳이 복합 컴포넌트 패턴을 적용하는 것은 불필요한 복잡성만 가중시킬 뿐이다 [5]. 진정한 복잡성(자식들 간의 상태 공유나 UI 유연성 등)이 요구될 때만 이러한 패턴을 도입해야 한다 [5].
+*   **구조적 복잡성 및 래퍼 지옥(Wrapper Hell)**: 로직 분리를 위해 렌더 프롭스 패턴 등을 남용할 경우, JSX 코드가 깊게 중첩되어 코드를 읽고 디버깅하기 매우 어려워지는 단점이 존재한다 [10, 13]. 
+*   **엄격한 유지보수 및 표준화 요구**: 디자인 시스템의 프로토타입이나 컴포넌트가 커질수록 파편화를 방지하기 위해 명확한 코딩 표준 확립, 일관된 명명 규칙, 그리고 컴포넌트 API 및 생성 패턴에 대한 철저한 문서화가 반드시 뒷받침되어야 한다 [14]. 
+
+---
+*Last updated: 2026-05-03*
+
+## 📚 Legacy Insights & Additional Context
+> [!NOTE]
+> Below is content merged from previous versions of this documentation.
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 지식 요약 정보 추출 중...
+
+## 📖 구조화된 지식 (Synthesized Content)
+본문 구조화 작업 중...
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
+- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
+
+## 🔗 지식 연결 (Graph)
+
+- Raw Source: 00_Raw/2026-04-20/Material Design System.md
+---

10_Wiki/Topics/_Archive_Orphans/Meta_Economy_Growth_Loop.md

@@ -0,0 +1,47 @@
+# 💰 Meta-Economy & Growth Loop (메타 경제 및 성장 루프)
+
+> **카테고리**: Skybound, Game Design, Economics & Algorithms
+> **상태**: 🔵 구현 완료 (Implemented)
+> **최종 업데이트**: 2026-04-22
+
+---
+
+## 📌 개요 (Overview)
+Skybound의 장기 리텐션을 책임지는 메타 게임 시스템이다. 격렬한 인게임 세션이 종료된 후, 플레이어는 획득한 Gold와 자원을 사용하여 격납고(Hangar)에서 영구적인 성장을 도모한다.
+
+## 🛠️ 시스템 구성 (System Components)
+
+### 1. 영구 업그레이드 (Permanent Upgrade)
+- **Hangar Shop**: 인게임에서 획득한 Gold를 소모하여 HP, ATK, SPEED, MAGNET, GOLD_GAIN 등 5종의 스탯을 영구 강화.
+- **Stat Injection Engine**: 구매한 업그레이드 레벨은 매 세션 시작 시 `calculateEffectiveStats`를 통해 플레이어 기체에 즉시 주입됨.
+- **지수적 비용 곡선**: 후반부 성장을 위해 레벨업 비용이 지수적으로 증가(300~8000G)하도록 설계.
+
+### 2. 크래프팅 경제 (Crafting Economy)
+아이템의 가치 보존과 인플레이션 방지를 위한 복합 제작 시스템이다.
+- **Disassemble (분해)**: 불필요한 장비를 분해하여 제작 재료(`Eternal Core`, `Destruction Core`, `TechMats`)를 확보.
+- **Cosmic Cast (코스믹 캐스트)**: 고가치의 재료를 대량 소모하여 자연 드롭으로 획득 불가능한 **SS급 장비**를 확정 제작.
+- **Astral Forge (아스트랄 포지)**: SS/LEGEND급 장비에 S급 장비를 제물로 바쳐 `forgeLevel`(+1~5)을 강화.
+- **TechPart Merge**: 동일 등급의 테크 파츠를 합성하여 스탯 보너스(`plusLevel`)를 강화.
+
+### 3. 이벤트 패스 (Event Pass)
+- **Atomic Trigger**: 보스 처치, 스테이지 클리어 등 인게임 이벤트 발생 시 실시간으로 패스 포인트 적립.
+- **Consolation Reward**: 런 실패 시에도 플레이 시간에 비례하여 포인트가 지급되어 "실패해도 진전이 있다"는 심리적 보상 제공.
+- **Reward Tiers**: 특정 티어 도달 시 S/SS급 확정 쿠폰 등 고가치 보상 지급.
+
+## 💡 경제 순환 구조 (Economy Pipeline)
+```mermaid
+graph TD
+    A[적 처치 / 런 완료] -->|Gold / 재료 드롭| B(Hangar)
+    B --> C{선택}
+    C -->|Gold 소모| D[Permanent Upgrade]
+    C -->|장비 분해| E[Crafting Materials]
+    E -->|제작| F[SS_CLASS Equipment]
+    F -->|포지 강화| G[End-game Stats]
+    A -->|Pass Points| H[Event Pass Tier Up]
+    H -->|보상| I[S/SS Coupon]
+    I -->|사용| F
+```
+
+---
+**승인인**: AI 개발부장 코다리 🫡
+**관련 코드**: `useGameStore.ts`, `HangarOverlay.tsx`, `combatUtils.ts`, `LootGenerator.ts`

10_Wiki/Topics/_Archive_Orphans/Mixins.md

@@ -0,0 +1,27 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Mixins
+description: "믹스인(Mixins)은 Vue."
+last_updated: 2026-05-04
+---
+
+# Mixins
+
+## 📌 Brief Summary
+믹스인(Mixins)은 Vue.js 프레임워크의 Options API 환경에서 코드 재사용을 위해 주로 사용되던 전통적인 패턴입니다 [1]. 그러나 대규모 애플리케이션으로 확장되는 현대적인 Vue 3 개발 환경에서는 믹스인이 가진 구조적인 한계로 인해 사용이 지양되고 있습니다 [2]. 오늘날 엔터프라이즈 코드베이스에서는 반응형 로직을 더 투명하고 타입 안전(type-safe)하게 공유할 수 있는 컴포저블(Composables) 패턴으로 효과적으로 대체되었습니다 [2].
+
+## 📖 Core Content
+* **Options API의 기본 재사용 접근법**: 믹스인은 재사용성 요구가 낮고 단일 기능을 수행하는 작고 단순한 컴포넌트를 설계할 때 Options API가 채택하던 주된 코드 재사용 방식이었습니다 [1].
+* **Composables로의 진화**: 엔터프라이즈급 대규모 웹 애플리케이션에서는 컴포넌트를 뷰(view) 계층에 집중시키고 상태 저장 로직(stateful logic)을 효과적으로 분리하기 위해 믹스인 대신 컴포저블을 사용합니다 [2].
+* **상속보다 합성(Composition over Inheritance)**: 비즈니스 규칙 등을 캡슐화할 때 믹스인과 같은 상속 기반의 패턴 대신, 독립적인 함수를 구성하는 '상속보다 합성' 접근 방식이 최신 아키텍처의 핵심으로 자리 잡았습니다 [3].
+
+## ⚖️ Trade-offs & Caveats
+믹스인 패턴은 재사용성을 제공하지만, 프로젝트의 규모가 커질 경우 다음과 같은 명확한 기술적 부작용과 제약 사항을 초래합니다.
+
+* **이름 충돌(Naming Collision) 문제**: 여러 믹스인을 하나의 컴포넌트에 통합하여 사용할 경우, 각 믹스인이 가진 변수명이나 메서드명이 동일하여 런타임 시 충돌이 일어나는 고전적인 문제가 발생합니다 [3].
+* **숨겨진 데이터(Hidden Data) 문제**: 데이터나 로직의 출처가 불분명해져 어떤 믹스인에서 특정 상태가 유래했는지 추적하기 어려워지는 문제가 발생합니다 [3]. 이는 결과적으로 코드의 가독성을 해치고 디버깅을 어렵게 만듭니다.
+* **타입 안정성의 한계**: 반환되는 참조(refs)와 함수를 통해 인터페이스를 명시적으로 정의하는 컴포저블과 비교할 때, 믹스인은 타입 안전성(Type-safe)이 크게 떨어집니다 [2, 3]. 이는 코드베이스가 복잡해질수록 예상치 못한 오류를 유발할 위험을 높입니다 [2].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Mocking_Framework.md

@@ -0,0 +1,26 @@
+---
+category: DevOps_and_Security
+tags: [auto-wikified, technical-documentation, devops_and_security]
+title: Mocking Framework
+description: "모킹 프레임워크(Mocking Framework)는 단위 테스트 수행 시 실제 서비스나 외부 종속성을 가짜(Mock) 객체로 교체하여, 비즈니스 로직을 변경하지 않고도 독립적인 테스트를 가능하게 하는 도구이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Mocking Framework
+
+## 📌 Brief Summary
+모킹 프레임워크(Mocking Framework)는 단위 테스트 수행 시 실제 서비스나 외부 종속성을 가짜(Mock) 객체로 교체하여, 비즈니스 로직을 변경하지 않고도 독립적인 테스트를 가능하게 하는 도구이다 [1]. 의존성 주입(DI) 구조의 유무에 따라 모킹의 복잡도가 크게 좌우되며, 시스템의 테스트 용이성을 결정짓는 핵심 요소로 작용한다 [1, 2]. 소스에 언급된 대표적인 모킹 도구로는 Java 생태계의 Mockito, React 환경의 Mock Service Worker(MSW), Node.js 환경의 proxyquire, rewire 등이 있다 [1, 3, 4].
+
+## 📖 Core Content
+*   **NestJS의 의존성 주입(DI) 기반 모킹 패턴:** NestJS는 테스트를 1급 관심사로 취급하며, 의존성 주입 메커니즘을 통해 모킹을 매우 직관적으로 지원한다 [1]. 프레임워크가 제공하는 테스트 모듈을 사용하면 단 몇 줄의 코드만으로 모의(Mock) 종속성이 포함된 격리된 인스턴스를 쉽게 생성할 수 있다 [1, 5].
+*   **Express에서의 수동 모킹 패턴:** Express는 자체적인 테스트 전략을 강제하지 않으므로, 종속성 모킹을 위해 `Jest`, `Mocha`, `Supertest` 등의 도구를 직접 구성해야 한다 [2]. 또한 구조적으로 결합도가 높은 경우, 의존성을 모킹하기 위해 `proxyquire`나 `rewire`와 같은 도구를 사용해야 하며 이를 위한 수동 설정 작업이 요구된다 [1, 2].
+*   **Java 및 Spring Boot의 모킹 (Mockito):** 헥사고날 아키텍처나 레이어드 아키텍처를 채택하는 Java 및 Spring Boot 기반 환경에서는 Java 컴포넌트의 단위 테스트를 위해 `Mockito` 프레임워크가 필수적으로 활용된다 [4, 6]. Spring Boot는 Mockito를 사용한 단위 테스트부터 테스트 컨테이너를 활용한 통합 테스트까지 포괄적인 모킹 및 테스트 환경을 제공한다 [5].
+*   **프론트엔드 환경의 모킹 (MSW):** React 애플리케이션 테스트 패턴에서는 `Vitest`, `React Testing Library` 등과 함께 `Mock Service Worker(MSW)`를 활용하여 데이터 페칭이나 외부 API 통신을 모킹하는 방식이 실전에서 사용된다 [3].
+
+## ⚖️ Trade-offs & Caveats
+프레임워크가 의존성 주입(DI) 구조를 강제하는지 여부에 따라 모킹을 위한 테스트 환경 설정의 트레이드오프가 명확히 발생한다 [1, 2]. 
+NestJS나 Spring Boot처럼 구조화되고 DI를 제공하는 프레임워크는 비즈니스 로직 수정 없이 모의 객체(Mock)를 원활하게 교체할 수 있어 모킹 및 단위 테스트가 매우 간단해진다는 강력한 이점이 있다 [1, 2]. 
+반면, Express와 같이 유연하고 뼈대를 강제하지 않는 프레임워크는 초기 개발의 자유도는 높지만, 종속성 모킹과 테스트 환경 설정을 위해 수동 작업이 많이 필요하다는 단점이 있다 [2]. 특히 수동으로 의존성을 모킹하거나 `proxyquire` 같은 외부 모킹 툴에 지나치게 의존하는 패턴은 자칫 테스트 코드를 지저분하게(hacky) 만들고 유지보수성을 저하시킬 수 있다는 제약 사항이 있다 [1].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Modular_Architecture.md

@@ -0,0 +1,33 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Modular Architecture
+description: "모듈러 아키텍처(Modular Architecture)는 시스템을 기능이나 도메인 단위의 독립적이고 응집력 있는 모듈로 분할하는 소프트웨어 설계 방식입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Modular Architecture
+
+## 📌 Brief Summary
+모듈러 아키텍처(Modular Architecture)는 시스템을 기능이나 도메인 단위의 독립적이고 응집력 있는 모듈로 분할하는 소프트웨어 설계 방식입니다 [1, 2]. NestJS나 Vue 3와 같은 현대적 프레임워크에서 이 패턴은 명확한 경계 설정을 통해 애플리케이션의 유지보수성과 확장성을 극대화합니다 [2-4]. 이를 통해 다수의 개발자가 협업하는 대규모 환경에서도 기술 부채를 줄이고 예측 가능한 코드베이스를 유지할 수 있습니다 [3, 5].
+
+## 📖 Core Content
+* **기능 기반(Feature-based) 모듈 구성**: NestJS 환경에서는 기술적 계층(Layered)이 아닌 기능(Feature)을 기준으로 모듈을 구성하는 것이 권장됩니다 [2]. 각 기능은 자체 폴더 내에 컨트롤러, 서비스, DTO, 엔티티 등을 모두 포함하는 하나의 모듈로 구현되어야 합니다 [2]. 이는 기능의 이동이나 삭제를 단일 폴더 조작으로 가능하게 하여 코드의 탐색과 관리를 매우 용이하게 만듭니다 [2].
+* **모듈의 역할별 분리 전략 (NestJS)**:
+  * **Feature Module**: 다른 모듈에서 주입받아야 할 요소만 명시적으로 내보내며(export), 하나의 기능당 하나의 모듈을 설계하여 캡슐화를 유지합니다 [6].
+  * **Shared Module**: 여러 기능에서 공통으로 사용하는 필터, 인터셉터, 파이프 등의 횡단 관심사(Cross-cutting concerns)를 위해 사용되며, `@Global()` 데코레이터를 통해 재임포트 없이 전역적으로 제공될 수 있습니다 [6].
+  * **Core Module**: 데이터베이스 연결이나 로거 설정 등 애플리케이션 시작 시 단 한 번만 초기화되어야 하는 요소들을 분리하여 담당합니다 [6].
+  * **Lazy Modules**: 거대한 애플리케이션이나 서버리스 콜드 스타트 성능 향상을 위해 특정 모듈을 지연 로딩(Lazy loading)할 수 있도록 설계합니다 [6].
+* **프론트엔드의 논리적 모듈화 (Vue 3)**: Vue 3의 Composition API는 데이터나 메서드 등의 기술적 옵션이 아닌 논리적 기능 단위로 코드를 그룹화하는 모듈화된 구조를 제공합니다 [4, 7]. 비즈니스 로직을 'Composables'라는 재사용 가능한 함수로 추출하여 캡슐화함으로써, 각 컴포넌트가 독립된 상태를 유지하고 코드베이스를 모듈식으로 깔끔하게 관리할 수 있게 합니다 [8-11].
+* **도메인 지향 구조 (Domain-Oriented Structure)**: 대규모 프론트엔드 애플리케이션에서는 단순히 기술적 유형(예: 모든 버튼을 한 폴더에 모으는 식)으로 구성하는 것을 넘어, 결제(billing)나 사용자(user)와 같은 특정 도메인 모듈 단위로 구조를 나누는 하이브리드 접근 방식이 아키텍처 병목 현상을 막아줍니다 [12].
+
+## ⚖️ Trade-offs & Caveats
+* **학습 곡선과 보일러플레이트 증가**: NestJS와 같이 모듈식 아키텍처를 강제하는 프레임워크는 Express와 같은 미니멀한 도구에 비해 초기 설정 시 더 많은 보일러플레이트 코드(Boilerplate code)를 요구하며 학습 곡선이 상대적으로 가파릅니다 [3].
+* **소규모 프로젝트에서의 오버엔지니어링**: 2~5명 규모의 소규모 팀이나 단순한 프로젝트에서는 모듈, 프로바이더, DTO 등을 촘촘히 설정하는 구조적 비용이 실제 비즈니스 가치보다 클 수 있으며, 결국 기능 구현보다 프레임워크 설정에 더 많은 시간을 쏟게 될 위험이 있습니다 [13].
+* **잘못된 모듈 패턴의 부작용**:
+  * `@Global()` 데코레이터를 남용하면 모듈 시스템이 본래 해결하고자 했던 "모든 것이 어디서나 접근 가능한" 혼란스러운 상태를 다시 초래하게 되므로 제한적으로 사용해야 합니다 [6].
+  * 하나의 코어 앱에 모든 것을 담는 "메가 앱(Mega-Apps)" 패턴이나, 단일 모듈이 수십 개의 기능 모듈을 무분별하게 임포트하는 구조는 모듈 분리의 목적을 퇴색시키므로 도메인에 따라 적절히 분할해야 합니다 [14, 15].
+* **순환 참조 (Circular Dependencies) 문제**: 모듈 간의 의존성이 잘못 설계되면 순환 참조 오류가 발생할 수 있습니다. 이때 `forwardRef()`와 같은 임시방편으로 경고를 회피하기보다는, 모듈 구조 자체를 근본적으로 수정하여 의존성을 바로잡는 것이 올바른 해결책입니다 [15].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Monorepo_Turborepo-Nx.md

@@ -0,0 +1,31 @@
+---
+category: DevOps_and_Security
+tags: [auto-wikified, technical-documentation, devops_and_security]
+title: Monorepo (Turborepo/Nx)
+description: "모노레포(Monorepo)는 Turborepo나 Nx와 같은 도구를 사용하여 복잡한 의존성 그래프를 관리하고 대규모 애플리케이션 환경을 지원하는 산업 표준 아키텍처 패턴이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Monorepo (Turborepo/Nx)
+
+## 📌 Brief Summary
+모노레포(Monorepo)는 Turborepo나 Nx와 같은 도구를 사용하여 복잡한 의존성 그래프를 관리하고 대규모 애플리케이션 환경을 지원하는 산업 표준 아키텍처 패턴이다 [1]. 고객 포털, 관리자 대시보드, 모바일 앱 등 여러 애플리케이션과 공유 라이브러리를 단일 저장소(Single repository)에서 함께 호스팅할 수 있게 해준다 [1]. 주로 코드의 재사용성을 높이고 지능형 캐싱 등을 통해 빌드 및 CI/CD 시간을 단축하며, 마이크로서비스 간의 공통 DTO나 UI 컴포넌트를 효과적으로 공유하기 위해 도입된다 [1, 2].
+
+## 📖 Core Content
+*   **다중 애플리케이션과 공유 코드의 단일 저장소 관리**
+    모노레포 환경에서는 여러 개의 독립적인 애플리케이션과 공통으로 사용되는 `packages/ui` 또는 `libs/`와 같은 폴더를 하나의 저장소에 배치한다 [1, 2]. 예를 들어, NestJS로 마이크로서비스를 구축할 때 `nest new --monorepo` 명령이나 Turborepo/Nx 워크스페이스를 설정하여 모든 서비스가 공유하는 DTO를 단일 라이브러리 패키지에서 가져오도록 구성할 수 있다 [2].
+*   **지능형 캐싱 (Intelligent Caching)**
+    Turborepo와 같은 도구는 '핑거프린팅(fingerprinting)' 시스템을 사용하여 변경되지 않은 컴포넌트의 빌드를 건너뛴다 [1]. 이러한 캐싱 메커니즘을 통해 CI/CD 시간을 최대 80%까지 단축할 수 있어 대규모 프로젝트에서의 개발 생산성을 크게 향상시킨다 [1].
+*   **워크스페이스 링킹 (Workspace Linking)**
+    모노레포 내에서 공유되는 컴포넌트(예: Vue 3 컴포넌트)에 대한 변경 사항은 로컬 심볼릭 링크(symlinks)를 통해 이를 소비하는 다른 애플리케이션에 즉각적으로 반영된다 [1]. 이는 번거로운 npm 퍼블리시 주기 없이도 "실시간(real-time)" 개발 경험을 가능하게 만들어 준다 [1].
+*   **엔터프라이즈 생태계의 표준화**
+    마이크로 프론트엔드와 모노레포 아키텍처의 조합은 현대 대규모 엔터프라이즈급 웹 애플리케이션 개발에서 점차 필수적인 표준으로 자리 잡고 있다 [1, 3].
+
+## ⚖️ Trade-offs & Caveats
+*   **버전 관리 및 동기화의 복잡성 증대**
+    모노레포를 통해 여러 서비스에서 공유되는 라이브러리를 사용하게 되면, 서비스 간의 버전을 관리하고 동기화 상태를 유지하며 배포를 조율하는 과정이 매우 빠르고 심각한 고통(painful fast)으로 다가올 수 있다 [4].
+*   **대안 부재로 인한 관리 비용 감수**
+    NestJS 마이크로서비스 등 특정 아키텍처에 헌신하기로 결정한 경우, 공유 라이브러리를 모노레포로 관리하면서 발생하는 배포 및 버전 관리의 복잡성을 감내해야만 하며, 이에 대한 뚜렷하고 훌륭한 대안이 부족하다는 제약이 있다 [4].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Monorepo_architectures.md

@@ -0,0 +1,24 @@
+---
+category: DevOps_and_Security
+tags: [auto-wikified, technical-documentation, devops_and_security]
+title: Monorepo architectures
+description: "모노레포(Monorepo) 아키텍처는 여러 애플리케이션과 공유 라이브러리를 단일 코드 저장소(Repository)에서 호스팅하여 복잡한 의존성 그래프를 관리하는 설계 방식입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Monorepo architectures
+
+## 📌 Brief Summary
+모노레포(Monorepo) 아키텍처는 여러 애플리케이션과 공유 라이브러리를 단일 코드 저장소(Repository)에서 호스팅하여 복잡한 의존성 그래프를 관리하는 설계 방식입니다 [1, 2]. 2026년 현대 소프트웨어 개발 환경에서 대규모 엔터프라이즈 애플리케이션 및 마이크로서비스를 구축할 때 널리 채택되는 트렌드이자 표준으로 자리 잡고 있습니다 [2, 3]. 주로 Turborepo나 Nx와 같은 도구를 활용하여 효율적인 코드 공유와 빌드 최적화를 수행합니다 [1, 2].
+
+## 📖 Core Content
+* **코드 공유와 구조화**: 모노레포 환경에서는 고객 포털, 관리자 대시보드 등의 여러 애플리케이션을 `packages/ui` 또는 공유 DTO가 담긴 `libs/` 폴더와 함께 단일 저장소에 배치합니다 [1, 2]. 예를 들어, NestJS 기반 마이크로서비스에서는 `nest new --monorepo` 명령어를 통해 환경을 구성하고 모든 서비스가 공통 패키지를 임포트(import)하여 사용합니다 [1]. TikTok과 같은 글로벌 기업은 20만 개 이상의 파일이 존재하는 대규모 프론트엔드 모노레포를 운영하며 코드를 관리하기도 합니다 [4].
+* **워크스페이스 링크 (Workspace Linking) 및 실시간 동기화**: 공유 컴포넌트에 대한 변경 사항은 로컬 심볼릭 링크(symlinks)를 통해 이를 사용하는 애플리케이션에 즉각적으로 반영됩니다 [2]. 따라서 번거로운 `npm publish` 사이클을 거치지 않아도 실시간 개발 경험(Real-time development experience)을 누릴 수 있습니다 [2].
+* **지능형 캐싱을 통한 성능 최적화 (Intelligent Caching)**: Turborepo와 같은 도구는 '핑거프린팅(fingerprinting)' 기술을 활용하여 변경되지 않은 컴포넌트의 빌드 과정을 건너뜁니다 [2]. 이를 통해 대규모 프로젝트에서 CI/CD 빌드 시간을 최대 80%까지 단축할 수 있습니다 [2].
+
+## ⚖️ Trade-offs & Caveats
+* **버전 관리 및 배포의 복잡성**: 마이크로서비스 환경에서 모노레포를 도입할 경우, 여러 서비스 간에 공유되는 라이브러리의 버전을 관리하고 동기화(sync)를 유지하며 배포를 통제하는 과정이 매우 고통스럽고 복잡해질 수 있습니다 [1].
+* **대안 부족의 딜레마**: 모노레포 구성이 가져오는 운영 상의 어려움과 기술 부채의 위험성에도 불구하고, NestJS 마이크로서비스 아키텍처와 같은 특정 환경을 구축할 때 이를 대체할 만한 더 훌륭한 구조적 대안이 마땅치 않다는 제약 사항이 있습니다 [1].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/NestJS.md

@@ -0,0 +1,39 @@
+---
+category: Architecture
+tags: [auto-wikified]
+title: NestJS
+description: "NestJS는 Angular의 아키텍처에서 영감을 받아 TypeScript로 구축된 효율적이고 확장 가능한 서버 사이드 Node."
+last_updated: 2026-05-04
+---
+
+# NestJS
+
+## 📌 Brief Summary
+NestJS는 Angular의 아키텍처에서 영감을 받아 TypeScript로 구축된 효율적이고 확장 가능한 서버 사이드 Node.js 프레임워크입니다 [1]. 기본적으로 Express를 사용하며(Fastify로 변경 가능) 의존성 주입(DI), 데코레이터, 모듈 시스템과 같은 엔터프라이즈 패턴을 도입하여 Node.js 프로젝트에 체계적인 구조를 제공합니다 [2-4]. 대규모 팀, 복잡한 비즈니스 로직, 마이크로서비스 아키텍처를 요구하는 엔터프라이즈급 애플리케이션 구축에 주로 활용됩니다 [5, 6].
+
+## 📖 Core Content
+* **오피니언 기반의 모듈식 아키텍처 (Opinionated Modular Architecture)**
+  NestJS의 모든 것은 컨트롤러(Controller), 모듈(Module), 프로바이더(Provider)를 중심으로 구성됩니다 [2, 7]. 대규모 코드베이스 확장을 위해 기술적 계층(Layer) 기준이 아닌 기능(Feature) 기반으로 폴더와 모듈을 구성하는 것이 권장되며, 각 기능 모듈은 컨트롤러, 서비스, DTO, 엔티티, 테스트를 한 폴더에 응집하여 관리합니다 [8, 9].
+* **강력한 의존성 주입(DI) 시스템**
+  생성자를 통해 필요한 의존성을 선언하면 프레임워크의 DI 컨테이너가 이를 자동으로 인스턴스화하고 주입합니다 [4, 10, 11]. 이 패턴은 구성 요소 간의 결합도를 낮춰주며, 단위 테스트 시 실제 서비스를 모의(Mock) 객체로 쉽게 교체할 수 있도록 하여 테스트 가능성을 극대화합니다 [10, 12].
+* **구조화된 횡단 관심사(Cross-Cutting Concerns) 관리**
+  NestJS는 단순한 미들웨어 이상의 구조화된 대안으로 가드(Guard), 인터셉터(Interceptor), 파이프(Pipe), 예외 필터(Exception Filter)를 제공합니다 [1, 13]. 예를 들어, `main.ts`에 전역 필터를 등록하여 모든 엔드포인트에 일관된 예외 처리 형식을 적용하고 [14], RxJS 스트림을 활용하여 비동기 흐름을 제어하고 로깅이나 유효성 검사를 삽입합니다 [15].
+* **DTO와 엔티티(Entity)의 철저한 분리**
+  데이터의 입출력 형태를 정의하는 DTO(Data Transfer Object)와 데이터베이스 모델인 엔티티는 시간이 지남에 따라 변하는 방향이 다르므로 별도로 분리해야 합니다 [16, 17]. `class-validator`를 이용해 DTO 수준에서 입력값을 검증하며, 컨트롤러가 엔티티를 직접 노출하는 것을 피하여 API 스펙의 결합도와 데이터 유출 위험을 줄입니다 [18, 19].
+* **엔터프라이즈 및 마이크로서비스 생태계 지원**
+  TCP, Redis, NATS, Kafka, RabbitMQ, gRPC 등 다양한 전송 계층을 지원하는 마이크로서비스 통신 모듈을 기본으로 제공하여 분산 모놀리스를 해체하기 쉽습니다 [13, 20, 21]. 또한 데코레이터를 이용한 코드 퍼스트 및 스키마 퍼스트 접근법을 모두 지원하는 강력한 GraphQL 통합 모듈(`@nestjs/graphql`)을 제공합니다 [20, 22, 23].
+
+## ⚖️ Trade-offs & Caveats
+* **가파른 학습 곡선과 보일러플레이트 부담**
+  NestJS는 Express의 단순한 미들웨어 패턴과 달리 DI, 데코레이터, 모듈, 가드, 파이프 등의 개념을 익히는 데 더 많은 시간이 소요됩니다 [20, 24]. 특히 2~5명 규모의 소규모 팀이나 단순한 MVP, 서버리스 함수 개발 시에는 비즈니스 가치보다 프레임워크 설정 및 배선(Wiring) 코드(모듈 등록, 프로바이더 주입, DTO 정의 등)를 작성하는 데 비용이 더 많이 드는 오버엔지니어링이 될 수 있습니다 [5, 25, 26].
+* **추상화 계층으로 인한 성능 오버헤드**
+  데코레이터와 DI 컨테이너 계층이 추가됨에 따라 순수 Express에 비해 초당 요청 처리량(req/s)이 약 10~15% 감소할 수 있습니다 [27]. 다만 이는 Fastify를 기본 HTTP 어댑터로 전환하여 극복할 수 있으며, 실제 병목은 프레임워크 오버헤드보다 데이터베이스 쿼리나 네트워크 지연에서 발생하는 경우가 많습니다 [27, 28].
+* **단일 스레드 한계와 이벤트 루프 차단**
+  Node.js 환경 위에서 구동되므로 I/O 집약적 작업에는 강하지만, CPU 집약적인 연산을 수행할 경우 단일 스레드 이벤트 루프가 차단되어 전체 동시 요청의 응답 시간이 저하됩니다 [29, 30]. 무거운 연산은 워커 스레드나 별도의 서비스로 오프로드(Offload)해야 합니다 [30].
+* **마이크로서비스 공유 자원 관리의 복잡성**
+  모노레포 환경에서 여러 마이크로서비스 간에 엔티티를 직접 공유하거나 임포트할 경우 구조가 분산 모놀리스(Distributed Monolith)로 변질될 위험이 있습니다 [31]. 여러 서비스 간 공유 라이브러리(Shared libs)를 동기화하고 버전을 관리하는 작업은 마이크로서비스 확장에 따라 점차 고통스러워질 수 있습니다 [31, 32].
+* **순환 참조(Circular Dependencies) 발생 가능성**
+  설계 단계에서 모듈 간 책임을 잘못 분리하면 서로를 참조하는 순환 참조 에러가 빈번하게 발생합니다 [31]. 프레임워크가 제공하는 `forwardRef()`를 사용하여 경고를 우회할 수 있지만, 장기적인 유지보수를 위해서는 아키텍처 구조 자체를 재설계하는 것이 권장됩니다 [12, 31].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/NestJS_Microservices_Module.md

@@ -0,0 +1,26 @@
+---
+category: Backend
+tags: [auto-wikified, technical-documentation, backend]
+title: NestJS Microservices Module
+description: "NestJS는 마이크로서비스 구축을 위한 내장 지원(built-in support) 기능을 제공하며, TCP, Redis, NATS, RabbitMQ, Kafka, gRPC 등 다양한 전송 계층(transport layer)을 지원하는 프레임워크입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# NestJS Microservices Module
+
+## 📌 Brief Summary
+NestJS는 마이크로서비스 구축을 위한 내장 지원(built-in support) 기능을 제공하며, TCP, Redis, NATS, RabbitMQ, Kafka, gRPC 등 다양한 전송 계층(transport layer)을 지원하는 프레임워크입니다 [1, 2]. 이 모듈은 요청-응답(request-response) 및 이벤트 기반(event-based) 메시지 패턴을 제공하고, 단일 앱에서 HTTP와 마이크로서비스 통신을 동시에 처리하는 하이브리드 애플리케이션 작성을 가능하게 합니다 [2]. 일관된 API를 통해 메시지 브로커를 손쉽게 전환할 수 있어 자바스크립트/타입스크립트 스택 기반의 마이크로서비스 아키텍처 구현에 매우 적합합니다 [3, 4].
+
+## 📖 Core Content
+* **다양한 전송 계층(Transport Layer) 지원**: NestJS의 마이크로서비스 모듈은 Redis, NATS, Kafka, RabbitMQ, gRPC, TCP 등을 기본적으로 지원합니다 [1-3]. 이들은 전송 메커니즘 전반에 걸쳐 일관된 API를 제공하므로, 필요에 따라 메시지 브로커를 전환하는 작업을 매우 직관적으로 만들어 줍니다 [3].
+* **통신 패턴 및 하이브리드 애플리케이션**: 이 프레임워크는 마이크로서비스 간의 요청-응답(request-response) 패턴과 이벤트 기반(event-based) 메시지 패턴을 모두 지원합니다 [2]. 또한, 일반적인 HTTP 요청 처리와 마이크로서비스 전송 계층을 동시에 제공하는 하이브리드 애플리케이션(hybrid applications)을 쉽게 구축할 수 있습니다 [2].
+* **도메인 경계와 모듈 시스템 매핑**: NestJS의 모듈 시스템은 기존의 모놀리식(Monolith) 시스템을 마이크로서비스로 분해할 때, 마이크로서비스의 도메인 경계에 자연스럽게 매핑되도록 설계되어 있어 확장성 있는 아키텍처를 돕습니다 [2].
+* **모노레포(Monorepo) 기반 구성**: 마이크로서비스 구현 시 `nest new --monorepo`를 사용하거나 Turborepo/Nx 워크스페이스를 통해 모노레포 환경을 구축할 수 있습니다 [5]. 이때 DTO와 같은 공유 코드는 `libs/` 패키지에 위치시켜 모든 개별 서비스에서 임포트하여 사용하는 방식을 취합니다 [5].
+
+## ⚖️ Trade-offs & Caveats
+* **공유 라이브러리 동기화 및 배포의 복잡성**: 마이크로서비스 환경에서 모노레포를 통해 DTO 등 공유 라이브러리를 사용할 경우, 여러 서비스 간의 버전을 관리하고 동기화하며 배포하는 과정이 급격히 까다로워지고 고통스러워질 수 있습니다 [6].
+* **분산 모놀리스(Distributed Monolith)의 위험성**: 여러 마이크로서비스 간에 엔티티(Entity)를 직접 임포트하여 공유하는 것은 심각한 안티 패턴입니다 [6]. 예를 들어 서비스 A가 서비스 B의 엔티티를 직접 임포트하게 되면, 이는 진정한 마이크로서비스가 아니라 시스템이 강하게 결합된 '분산된 모놀리스' 구조를 초래하게 됩니다 [6].
+* **오버헤드 및 프레임워크 배선(Wiring) 비용**: 소규모 팀(2~5명)이거나 복잡도가 낮은 시스템에서는 NestJS가 요구하는 구조적 셋업(모듈, 프로바이더, DTO, 인터셉터 등) 자체가 비용으로 작용할 수 있습니다 [7]. 비즈니스 로직(기능) 구현보다 프레임워크의 배선 작업에 더 많은 시간을 할애하게 될 위험이 있습니다 [7].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Netflix_OSS.md

@@ -0,0 +1,33 @@
+---
+category: Backend
+tags: [auto-wikified, technical-documentation, backend]
+title: Netflix OSS
+description: "**Netflix OSS(Open Source Software)**는 넷플릭스(Netflix)가 클라우드 환경으로 아키텍처를 전환하며 자체적으로 구축하고 오픈소스로 공개한 Java 기반의 클라우드 인프라 라이브러리 및 시스템이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Netflix OSS
+
+## 📌 Brief Summary
+**Netflix OSS(Open Source Software)**는 넷플릭스(Netflix)가 클라우드 환경으로 아키텍처를 전환하며 자체적으로 구축하고 오픈소스로 공개한 Java 기반의 클라우드 인프라 라이브러리 및 시스템이다 [1]. 주요 컴포넌트로는 서비스 디스커버리를 위한 Eureka, 로드 밸런싱을 위한 Ribbon, 내결함성을 제공하는 Hystrix 등이 있다 [1, 2]. 최근에는 대규모 자체 인프라 유지에 따른 기술 부채를 줄이기 위해, 커뮤니티 표준인 Spring Boot 및 Spring Cloud 생태계로 핵심 기능들을 이관 및 통합하는 방향으로 진화하고 있다 [3, 4].
+
+## 📖 Core Content
+*   **Netflix OSS의 탄생과 주요 컴포넌트**
+    2007년 넷플릭스는 대규모 클라우드 아키텍처로의 전환을 시작하며, 당시 요구사항을 충족하는 외부 솔루션이 부족하여 자체적인 클라우드 인프라 라이브러리를 개발했다 [1, 5]. 대표적으로 **로드 밸런서인 Ribbon**, **서비스 디스커버리 시스템인 Eureka**, **장애 허용성 및 서킷 브레이커 역할을 하는 Hystrix**, 종속성 주입 및 수명 주기 관리를 위한 Governator, 환경 설정을 담당하는 Archaius 등이 구성 요소로 포함되었으며, 2012년경 이를 오픈소스로 공개했다 [1].
+
+*   **Spring Cloud Netflix와의 통합**
+    2015년 커뮤니티 주도로 'Spring Cloud Netflix' 1.0이 출시되면서 Netflix OSS 컴포넌트들을 Spring Boot와 통합하는 작업이 이루어졌다 [3]. 이 통합을 통해 개발자들은 Eureka(서비스 디스커버리), Hystrix(서킷 브레이커), Zuul(지능형 라우팅), Ribbon(클라이언트 측 로드 밸런싱)과 같은 분산 시스템의 필수 패턴들을 Spring Boot 애플리케이션 내에서 쉽게 구현하고 사용할 수 있게 되었다 [2, 6].
+
+*   **커뮤니티 주도 표준으로의 회귀 (Spring Boot 도입)**
+    초기에는 넷플릭스 시스템의 안정성, 확장성, 효율성을 위해 내부 솔루션이 필수적이었으나, 이후 Spring 에코시스템이 방대하게 발전함에 따라 넷플릭스 역시 **Spring Boot를 핵심 Java 프레임워크로 전면 채택**하게 되었다 [5]. 넷플릭스는 노후화된 자체 소프트웨어(예: Ribbon)를 Spring Cloud Load Balancer와 같은 강력한 커뮤니티 솔루션으로 대체하고 있으며, 반대로 새로운 혁신 기술(예: Netflix Adaptive Concurrency Limiters)은 오픈소스 커뮤니티에 다시 환원하는 상호 보완적 전략을 실행하고 있다 [4, 7].
+
+## ⚖️ Trade-offs & Caveats
+*   **자체 기술 개발(In-house)의 한계와 기술 부채**
+    초기 클라우드 전환기에는 필요한 수준의 안정성과 확장성을 갖춘 프레임워크가 없어 기업 내부에서 직접(In-house) 솔루션을 개발해야 했으나, 시스템이 방대해짐에 따라 **자체 인프라 라이브러리를 유지보수하는 것은 막대한 기술 부채와 오버헤드를 발생**시켰다 [4, 5]. 
+
+*   **표준 생태계 레버리지 활용의 이점**
+    넷플릭스의 아키텍처 전환 사례는 넷플릭스 정도의 글로벌 대기업이라 할지라도, 독자적인 기술 생태계를 고집하기보다는 **고도로 추상화되고 문서화가 잘 된 커뮤니티 표준(Spring Boot, Spring Cloud 등)의 레버리지를 활용하는 것이 장기적 효율성 측면에서 훨씬 유리함**을 보여준다 [4, 8]. 조직의 핵심 비즈니스가 아닌 범용 인프라 영역에서는 성숙한 커뮤니티 솔루션으로 과감히 이관하는 것이 비즈니스 민첩성(Agility)을 높게 유지하는 데 긍정적으로 작용한다 [7, 8].
+
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Next_js_Caching_Architecture.md

@@ -0,0 +1,25 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Next.js Caching Architecture
+description: "Next."
+last_updated: 2026-05-04
+---
+
+# Next.js Caching Architecture
+
+## 📌 Brief Summary
+Next.js의 캐싱 아키텍처는 React 서버 컴포넌트(RSC) 및 서버 액션(Server Actions)과 긴밀하게 연동되어 애플리케이션의 데이터를 서버에 저장하고 무효화(Invalidate)하는 메커니즘입니다 [1, 2]. 개발자는 다양한 데이터를 서로 다른 태그(Tag)로 캐시하고, 데이터가 업데이트될 때 해당 태그를 무효화하는 방식으로 동작을 제어할 수 있습니다 [3]. 이를 통해 무거운 데이터의 잦은 재요청을 방지하고 빠른 렌더링 성능을 확보하는 것이 핵심 목적입니다 [3, 4].
+
+## 📖 Core Content
+*   **태그 기반 캐시 무효화 (Cache Invalidation with Tags):** Next.js에서는 데이터를 가져올 때 개별 데이터에 고유한 태그를 할당하여 캐시할 수 있습니다 [3]. 데이터의 변경이나 업데이트가 발생하면 서버 액션 내에서 `revalidateTag` 함수를 호출하여, 특정 태그와 연결된 캐시 데이터를 방출(eject)하도록 지시할 수 있습니다 [2, 5].
+*   **RSC 트리 전체 리렌더링:** `revalidateTag` API는 Next.js에게 '무엇을 다시 로드할지'를 알려주는 것이 아니라, 단지 '캐시에서 무엇을 제거할지'만을 알려줍니다 [5]. 그 결과, 이 함수가 호출되면 Next.js는 현재 페이지의 모든 것을 다시 로드해야 하므로 전체 RSC 트리가 리렌더링됩니다 [3, 5].
+*   **캐시 적중을 통한 성능 방어:** 전체 컴포넌트 트리가 리렌더링되는 구조적 특성에도 불구하고, 서버에 데이터가 올바르게 캐시되어 있다면 캐시된 데이터에 대한 후속 요청들은 매우 빠르게 실행되어 성능 저하를 방지할 수 있습니다 [3].
+
+## ⚖️ Trade-offs & Caveats
+*   **과도한 데이터 재요청 위험성:** `revalidateTag`를 호출하여 캐시를 무효화하면 전체 컴포넌트 트리가 리렌더링되면서 연관된 모든 데이터의 재요청이 발생합니다 [4, 5]. 만약 서버에 모든 데이터가 적절히 캐시되어 있지 않다면, 오히려 `react-query`와 같은 클라이언트 측 상태 관리 도구가 필요로 하는 두 번의 왕복 시간(Round trip)보다 단일 서버 왕복 시간이 더 오래 걸리는 심각한 성능 저하를 초래할 수 있습니다 [4].
+*   **서버 액션의 직렬 실행 병목:** 데이터 업데이트와 캐시 무효화에 사용되는 서버 액션은 한 번에 하나만 실행될 수 있는 직렬(Serial) 실행 제약을 가집니다 [6]. 네트워크가 느리거나 지연이 발생할 경우 작업들이 대기열(Queue)에 쌓이게 되어 사용자 경험을 크게 훼손할 수 있습니다 [6].
+*   **캐싱 API의 잦은 변경과 변동성:** 소스 자료 작성 시점 기준으로 Next.js는 완전히 다른 캐싱 API와 기본값을 포함한 새로운 버전을 출시하는 중이었습니다 [1]. 이는 캐싱 아키텍처의 세부 동작 방식이나 최적화 전략이 버전에 따라 급격히 달라질 수 있는 기술적 불안정성을 내포하고 있음을 의미합니다 [1].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/OpenAPI_-_Swagger.md

@@ -0,0 +1,29 @@
+---
+category: Backend
+tags: [auto-wikified, technical-documentation, backend]
+title: OpenAPI / Swagger
+description: "OpenAPI와 Swagger는 RESTful API를 설계, 테스트 및 문서화하기 위한 표준 사양과 대화형 도구 모음입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# OpenAPI / Swagger
+
+## 📌 Brief Summary
+OpenAPI와 Swagger는 RESTful API를 설계, 테스트 및 문서화하기 위한 표준 사양과 대화형 도구 모음입니다 [1, 2]. 개발자가 추가 도구 없이도 API 엔드포인트를 수동으로 탐색하고 상호작용할 수 있도록 지원하며, 클라이언트 코드 생성 프로세스를 간소화합니다 [1, 2]. 현대적인 백엔드 프레임워크들은 코드를 기반으로 이러한 API 문서를 자동 생성하고 동기화할 수 있는 강력한 통합 기능을 제공하고 있습니다 [3, 4].
+
+## 📖 Core Content
+* **인터랙티브 API 테스트 및 탐색**: Swagger는 API 엔드포인트를 쉽게 테스트하고 탐색할 수 있는 대화형 인터페이스(Swagger UI)를 제공합니다 [2]. 이를 통해 개발자는 별도의 외부 도구나 클라이언트 앱을 구축할 필요 없이 수동으로 애플리케이션과 상호작용하며 기능을 검증할 수 있습니다 [2].
+* **문서 자동화와 코드 동기화**: API 문서화 방식은 채택한 프레임워크에 따라 크게 달라집니다. 
+  * **NestJS**: 데코레이터와 DTO를 활용하여 Swagger/OpenAPI 문서를 자동으로 생성하며, API 문서가 실제 코드와 항상 동기화된 상태를 유지하도록 돕습니다 [3, 4].
+  * **Express**: 자동화 지원이 부족하여 `swagger-jsdoc`이나 별도의 문서화 도구를 사용해 수동으로 Swagger를 설정해야 합니다 [4].
+  * **Django (DRF)**: `drf-spectacular`와 같은 라이브러리를 활용하여 DRF API 문서화를 자동화할 수 있습니다 [5].
+  * **Encore**: 보일러플레이트를 줄인 Encore 프레임워크에서도 자동으로 OpenAPI 스펙을 생성하여 제공합니다 [6].
+* **클라이언트 코드 생성 및 협업 강화**: JSON 포맷 등으로 제공되는 OpenAPI 엔드포인트(예: `/api-docs`)는 API 계약(Contract)을 명확하게 유지하는 표준화된 문서 역할을 합니다 [2]. 이 스펙은 인터페이스 및 데이터 모델 생성에 사용될 수 있어, 마이크로서비스 환경 등에서 클라이언트 코드(SDK)를 생성하는 과정을 크게 단순화시킵니다 [1, 2]. 결과적으로 개발팀 간에 API 설계 및 기능에 대한 시각을 일치시키고 협업과 개발 속도를 가속화하는 데 기여합니다 [7].
+
+## ⚖️ Trade-offs & Caveats
+이 주제와 관련하여 OpenAPI/Swagger 적용 자체에 따른 심각한 시스템적 부작용이나 성능 저하에 대한 내용은 소스에 관련 정보가 부족합니다. 
+
+다만, API 문서를 구현하는 기술적 선택에 따른 제약 사항(Trade-off)은 존재합니다. Express와 같이 구조화되지 않고 유연성을 강조하는 프레임워크에서는 API 문서화를 위해 수동 설정과 지속적인 유지보수 작업이 요구됩니다 [4]. 반면, NestJS나 Spring Boot와 같이 구조화된 프레임워크에서는 자동 생성의 이점을 누릴 수 있지만, 이를 위해 특정 데코레이터나 어노테이션 패턴(DTO 등)을 강제적으로 코드베이스 전체에 적용해야 하므로 학습 곡선이 발생하고 프레임워크에 대한 종속성이 높아진다는 제약이 있습니다 [4].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Performance Optimization.md

@@ -0,0 +1,70 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, merged, architecture]
+title: React Native Performance Optimization
+description: "React Native의 성능 최적화는 주로 자바스크립트 스레드와 네이티브 스레드 간의 통신 병목 현상을 해결하는 데 초점을 맞추고 있습니다."
+last_updated: 2026-05-04
+---
+
+# React Native Performance Optimization
+
+
+## 📌 Brief Summary
+React Native의 성능 최적화는 주로 자바스크립트 스레드와 네이티브 스레드 간의 통신 병목 현상을 해결하는 데 초점을 맞추고 있습니다. 최근 '새로운 아키텍처(New Architecture)'의 도입을 통해 기존의 비동기 브릿지(Bridge) 구조를 제거하고 동기식 통신을 가능하게 하여 성능을 극적으로 향상시켰습니다. 이를 통해 직렬화 오버헤드를 줄이고, 렌더링 속도와 앱의 초기 로딩 및 메모리 성능을 효율적으로 최적화하고 있습니다.
+
+## 📖 Core Content
+* **새로운 아키텍처(New Architecture)와 브릿지리스 모드:** 과거 React Native의 가장 큰 성능 병목은 JS와 네이티브 간의 통신을 담당하며 데이터를 JSON 문자열로 직렬화했던 비동기 브릿지였습니다 [1]. 최근 버전(0.74 이상)에서는 이를 기본적으로 제거한 브릿지리스 아키텍처를 채택하여 성능을 크게 최적화했습니다 [1, 2].
+* **JSI (JavaScript Interface):** 기존 브릿지를 대체하는 경량 C++ 기반의 레이어로, 자바스크립트 코드가 네이티브 객체에 대한 직접적이고 동기적인 참조를 가질 수 있게 합니다 [3, 4]. 이로 인해 통신 간의 데이터 직렬화(Serialization) 오버헤드가 완전히 제거되어 실시간에 가까운 고성능 통신이 가능해집니다 [3, 4].
+* **Fabric 렌더러:** 새로운 UI 관리 및 렌더링 시스템으로, 비동기적 왕복 처리 없이 메인 스레드에서 네이티브 뷰를 측정하고 렌더링할 수 있습니다 [4, 5]. 이는 React 18의 동시성(Concurrent) 렌더링을 지원하며, 동기적인 레이아웃 계산을 통해 UI 요소의 반응성과 애니메이션이 훨씬 매끄럽게 동작하도록 개선합니다 [4, 5].
+* **TurboModules:** 기존 네이티브 모듈은 앱 시작 시 모두 한꺼번에 초기화되어 시작 시간을 늦추는 원인이었으나, TurboModules는 모듈이 처음 사용될 때만 로드되는 지연 로딩(Lazy Loading) 방식을 도입했습니다 [4, 6]. 이는 앱의 초기 시작 성능을 높이고 초기 메모리 사용량(Footprint)을 크게 줄여줍니다 [4, 6].
+* **Codegen 도입:** 자바스크립트와 네이티브(Java/Kotlin, Objective-C/Swift) 간 통신을 위한 C++ 보일러플레이트 코드를 빌드 타임에 자동으로 생성해 줍니다 [7]. 이는 두 계층 간의 강력한 타입 안전성을 제공하여 런타임이 아닌 컴파일 타임에 오류를 잡아냄으로써 성능과 코드 안정성에 기여합니다 [7].
+
+## ⚖️ Trade-offs & Caveats
+* **초기 시작 시간(Cold Start) 지연:** AOT(Ahead-Of-Time) 컴파일을 통해 머신 코드로 직접 변환되는 방식과 달리, React Native는 앱 실행 시 자바스크립트 엔진(주로 Hermes)을 초기화하고 JS 번들을 파싱하는 과정을 거쳐야 합니다 [8]. 이 과정 때문에 대체로 300~600ms 수준의 초기 콜드 스타트 지연 시간이 발생할 수 있습니다 [8].
+* **기존 브릿지 아키텍처의 레거시 부채:** 새로운 아키텍처로 완전히 전환하지 않은 환경에서는 자바스크립트와 네이티브 간 브릿지 통신에서 메모리 누수(Memory leaks)가 발생할 수 있으며, 시간이 지남에 따라 점진적인 성능 저하 문제가 발생할 수 있습니다 [9].
+* **서드파티 라이브러리 및 유지보수의 복잡성:** 새로운 아키텍처와 JSI의 성능적 이점을 온전히 얻기 위해서는 서드파티 라이브러리들 역시 새 구조를 지원해야 합니다 [4, 9]. 또한 OS 업데이트나 메이저 버전 업그레이드 시 플랫폼 종속적인 코드 재작성과 광범위한 테스트가 요구되어, 큰 유지보수 비용(최대 2~3개월 소요)이 발생할 수 있습니다 [7, 9].
+* **애니메이션 제어의 렌더링 한계:** 자체적인 렌더링 파이프라인을 온전히 통제하는 방식이 아니므로, 매우 복잡한 커스텀 애니메이션(파티클 효과 등)에서는 렌더링 성능의 한계가 드러날 수 있습니다 [10, 11]. 하지만 실제 네이티브 플랫폼 컴포넌트를 직접 사용하기 때문에 별도의 커스텀 렌더링 트리를 유지할 필요가 없어, 기본 메모리 사용량과 번들 크기는 더 작게 유지되는 긍정적 반대 급부도 가집니다 [8, 12].
+
+---
+*Last updated: 2026-05-03*
+
+## 📚 Legacy Insights & Additional Context
+> [!NOTE]
+> Below is content merged from previous versions of this documentation.
+
+## 📌 Brief Summary
+성능 최적화(Performance Optimization)는 소프트웨어의 기능적 동작을 동일하게 유지하면서 시간이나 메모리와 같은 자원 사용량을 개선하기 위해 내부 구조를 변경하는 과정입니다 [1-3]. 코드를 더 이해하고 수정하기 쉽게 만드는 리팩토링(Refactoring)과 유사하게 기능은 유지하지만, 구조 개선이 아닌 속도 향상이나 자원 효율성을 주된 목적으로 삼는다는 점에서 구별됩니다 [1, 2, 4]. 성공적인 성능 최적화를 위해서는 이해하기 쉬운 코드로 먼저 리팩토링하여 튜닝하기 좋은 상태를 만드는 것이 필수적인 선행 조건으로 간주됩니다 [5-7].
+
+## 📖 Core Content
+
+* **리팩토링과 최적화의 관계:**
+  소프트웨어 개발에서 기능 추가나 버그 수정과 달리, 리팩토링과 최적화는 모두 기존 기능을 불변으로 유지하면서 다른 속성을 변경한다는 공통점을 가집니다 [4]. 리팩토링은 프로그램의 구조(Structure)를 변경하는 반면, 최적화는 자원 사용량(Resource Usage)을 변경합니다 [2, 3]. 
+
+* **성능 개선을 위한 3가지 접근 방식 [8-11]:**
+  1. **시간 예산 할당 (Time Budgeting):** 심박조율기처럼 지연된 데이터가 치명적인 하드 실시간(Hard real-time) 시스템에서 주로 사용되며, 각 컴포넌트에 엄격한 시간과 자원 예산을 할당하는 방식입니다 [8].
+  2. **지속적 주의 (Constant Attention):** 모든 프로그래머가 항상 성능을 높게 유지하기 위해 노력하는 방식이지만, 실제로는 프로그램을 이해하고 수정하기 어렵게 만들어 개발 속도를 늦추기 때문에 효과적이지 않습니다 [9].
+  3. **프로파일러 기반 튜닝 (Profiler-Driven Tuning):** 대부분의 프로그램은 아주 작은 일부 코드에서 대부분의 시간을 낭비한다는 통계에 기반한 접근입니다 [10]. 성능에 신경 쓰지 않고 구조가 잘 짜인(Well-factored) 프로그램을 먼저 만든 후, 프로파일러를 사용해 시간과 공간을 소비하는 '핫스팟(Hot spots)'을 찾아 집중적으로 최적화합니다 [10, 11].
+
+* **잘 리팩토링된 코드가 최적화에 미치는 이점:**
+  잘 구조화된 프로그램은 기능 추가 속도를 높여주어 성능 튜닝에 투자할 시간을 더 많이 확보해 줍니다 [6]. 또한, 코드의 의도가 명확하고 구조가 잘게 나누어져 있어 성능 분석 시 더 세밀한 단위(Finer granularity)로 프로파일링하고 튜닝할 수 있는 이점을 제공합니다 [6]. 
+
+* **성능 최적화 관련 기법:**
+  기존 알고리즘이 유지보수할 수 없는 성능 병목 지점이 되었을 때 전체 구현을 교체하는 '알고리즘 전환(Substitute Algorithm)' 기법이 사용될 수 있습니다 [12]. 또한, 임시 변수를 질의 함수로 바꾸는 기법(Replace Temp with Query)은 데이터 흐름을 명확히 하여 향후 최적화, 메모이제이션(Memoization) 또는 병렬 실행을 지원하는 토대가 됩니다 [13]. 하드웨어 측면에서는 소프트웨어가 병렬 프로세서나 벡터 유닛의 이점을 취할 수 있도록 조정하는 작업도 포함됩니다 [14].
+
+## ⚖️ Trade-offs & Caveats
+
+* **단기적 성능 저하와 장기적 튜닝 용이성의 상충 (Trade-off):** 
+  코드를 이해하기 쉽게 만드는 리팩토링 과정은 종종 단기적으로 프로그램의 실행 속도를 느리게 만들 수 있습니다 [5, 7]. 예를 들어, 임시 변수를 제거하는 리팩토링 과정에서 루프가 여러 번 실행되거나 계산이 중복되어 성능 비용을 지불해야 할 수 있습니다 [15, 16]. 그러나 이러한 단기적인 성능 저하를 감수하면 오히려 강력한 최적화 옵션을 발견하기 쉬워지므로 최종적으로는 더 빠른 소프트웨어를 만들 수 있습니다 [7, 17].
+
+* **최적화로 인한 코드 가독성 저하:**
+  성능을 개선하기 위한 코드 변경은 대개 프로그램의 복잡도를 높이고 코드를 이해하기 어렵게 만듭니다 [1, 9]. 이것이 '지속적 주의' 방식이 오히려 개발을 느리게 만들고 낭비를 초래하는 주된 이유입니다 [9].
+
+* **추측에 기반한 최적화의 위험성 (Caveat):**
+  성능 최적화 시 가장 주의해야 할 점은 시스템을 잘 안다고 생각하여 병목 지점을 함부로 추측(Speculate)해서는 안 된다는 것입니다 [5, 18]. 경험 많은 개발자의 좋은 아이디어조차 실제 측정 결과와 다를 때가 많으므로, 반드시 프로파일러 도구로 실제 성능을 측정(Measure)한 후 최적화를 진행해야 합니다 [5, 11, 19].
+
+* **AI 도구 활용 시 제약 사항:**
+  성능이 중요한 최적화(Performance-critical optimization) 작업은 복잡성이 매우 높은 작업이므로, AI 코딩 도구를 사용할 경우 오히려 작업 속도를 지연시키거나 방해가 될 수 있습니다 [20, 21]. 따라서 이러한 맥락에서는 AI 지원 없이 전문가의 판단에 의존하는 것이 권장됩니다 [21].
+
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Prefetching.md

@@ -0,0 +1,24 @@
+---
+category: Computer_Science_and_Theory
+tags: [auto-wikified, technical-documentation, computer_science_and_theory]
+title: Prefetching
+description: "프리페칭(Prefetching)은 프론트엔드 및 백엔드 프레임워크에서 시스템 성능을 최적화하기 위해 데이터가 실제로 필요해지기 전에 미리 데이터를 불러오는 실전 패턴이다."
+last_updated: 2026-05-04
+---
+
+# Prefetching
+
+## 📌 Brief Summary
+프리페칭(Prefetching)은 프론트엔드 및 백엔드 프레임워크에서 시스템 성능을 최적화하기 위해 데이터가 실제로 필요해지기 전에 미리 데이터를 불러오는 실전 패턴이다. React 생태계에서는 사용자 라우팅 지연 시간을 상쇄하기 위해 API 요청을 미리 실행하는 데 활용되며, Django와 같은 백엔드 환경에서는 ORM의 N+1 쿼리 문제를 방지하고 연관된 데이터베이스 객체를 효율적으로 가져오는 데 사용된다.
+
+## 📖 Core Content
+* **React와 React Query를 활용한 프리페칭 패턴**: Next.js와 같은 메타 프레임워크 환경에서 URL 변경 등의 라우팅에 의한 네비게이션 지연이 발생할 때, `react-query`의 `queryClient.prefetchQuery` API를 사용하여 데이터를 미리 요청할 수 있다. [1, 2] 이 패턴을 적용하면 Next.js가 변경되지 않은 서버 컴포넌트(RSC) 페이지를 렌더링하느라 대기하는 동안 네트워크 요청을 미리 백그라운드에서 실행시킬 수 있다. [1, 2] 이후 클라이언트 컴포넌트가 실제로 동일한 쿼리를 실행할 때, 이미 진행 중인 Promise에 자동으로 연결되어 데이터를 즉시 사용할 수 있게 된다. [2]
+* **Django ORM의 `prefetch_related` 및 셀렉터 패턴**: Django 백엔드 아키텍처에서는 데이터베이스 쿼리 최적화를 위해 `prefetch_related`와 `select_related`를 필수적으로 사용한다. [3] 실전 대규모 프로젝트에서는 데이터 조회(Read) 로직을 전담하는 '셀렉터(Selectors)' 계층에 이러한 프리페칭 로직을 중앙 집중화한다. [3, 4] 이를 통해 뷰(View) 로직을 가볍게 유지하고, 여러 모델이 얽힌 N+1 쿼리 문제를 효과적으로 방지하며 코드의 중복을 최소화한다. [3, 4]
+
+## ⚖️ Trade-offs & Caveats
+* **코드 중복 및 보일러플레이트 증가**: React Query에서 `prefetchQuery`를 구현할 때, 프리페치를 트리거하는 코드(예: 검색 폼의 라우팅 이벤트)와 실제 컴포넌트 내부에서 데이터를 요청하는 코드 사이에 쿼리 옵션이 중복될 수 있다. [2, 5] 이러한 중복 코드를 피하고 유지보수성을 높이기 위해서는 프리페치와 실제 쿼리를 아우르는 별도의 헬퍼(helper) 함수를 만들어 관리해야 하는 구조적 복잡성이 수반된다. [5]
+* **라우팅 종속성에 따른 한계**: 프론트엔드의 프리페칭 패턴은 데이터 로딩이 URL(라우팅)과 강하게 결합되어 있을 때 발생하는 지연을 우회하기 위한 목적으로 주로 사용된다. [5] 만약 데이터 요청이 단순히 클라이언트 측 상태(Client-side state) 업데이트 버튼 클릭 등으로만 이루어진다면, 프레임워크의 라우팅 지연이 없으므로 복잡한 프리페칭 로직 없이도 쿼리가 즉시 실행된다. [5] 
+* **백엔드 프리페칭 관리의 주의점**: Django에서 프리페칭(`prefetch_related`)을 컨트롤러나 뷰(View) 계층에 무분별하게 흩어 놓으면 누락되는 경우가 발생하여 치명적인 성능 저하(N+1 문제)를 유발할 수 있다. [3] 따라서 반드시 독립된 셀렉터(Selector) 레이어에서 쿼리를 캡슐화하여 관리해야 하는 아키텍처적 규칙을 준수해야 한다. [3, 4]
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Process_Reflection_Template.md

@@ -0,0 +1,27 @@
+# 💡 프로젝트 기획 및 개선 과정 회고 (Project Retrospective Template)
+
+## 📄 문서 목적
+본 문서는 '사용자 요청 기반의 복합적인 지식 생성 작업'을 수행할 때, **[초기 계획 → 피드백 수용 → 최종 완성]** 과정을 구조적으로 기록하고 분석하여, 유사한 고난도 프로젝트에서 AI 모델의 사고력을 성장시키는 것을 목표로 합니다. 단순 결과물 저장소가 아닌, 방법론(Methodology) 학습 자료입니다.
+
+## 🛠️ [Phase 1: 초기 접근 및 가설 설정 (Initial Hypothesis)]
+*   **[작업 내용]:** 사용자의 요청을 처음 받았을 때 가장 먼저 생각한 해결책과 구조는 무엇이었는지 기록합니다.
+*   **[핵심 논리]:** 이 단계에서 어떤 키워드(Keyword)와 연결 고리를 중심으로 전체 아웃라인을 잡았는가? (예: "캐주얼 = 단순화", "전략 = 시스템")
+*   **[초기 강점/한계 인식]:** 내가 스스로 판단하기에, 초기 계획의 가장 큰 강점과 놓치고 지나간 구조적 약점은 무엇이었는지 명시합니다.
+
+## 🎯 [Phase 2: 외부 피드백 수용 및 오류 진단 (Critique Integration)]
+*   **[수신된 피드백]:** 사용자(혹은 시스템)로부터 받은 핵심적인 비판이나 누락 사항을 정확히 인용하고 요약합니다. (예: "전략과 캐주얼의 메커니즘적 연결고리가 부족하다.")
+*   **[오류 진단 및 원인 분석]:** 초기 계획이 실패한 이유가 **'개념의 충돌(Conflict)'** 때문인지, **'구조화 부족(Lack of Structure)'** 때문인지, 아니면 **'경제성 무시(Economic Blind Spot)'** 때문인지 근본적인 원인을 진단합니다.
+*   **[보완 방향 설정]:** 이 오류를 해결하기 위해 어떤 *새로운 메커니즘적 장치*가 필요한지 구체적으로 정의합니다. (예: '선택의 폭을 제한하여 전략성을 강제하는 시스템 도입')
+
+## 📈 [Phase 3: 최종 개선 및 성장 방법론 구축 (Final Methodology)]
+이 단계는 앞으로 유사한 작업을 할 때 반드시 지켜야 할 **'가장 중요한 규칙(Rule)'**입니다.
+
+1.  **✅ 구조적 사고 우선:** 요청을 받으면, 단순히 내용을 채우기보다 'A → B → C의 흐름이 논리적으로 연결되는지'를 가장 먼저 점검한다. (흐름도/Flowchart 사고)
+2.  **✅ 메커니즘 구체화 원칙:** 추상적인 개념(예: 재미, 깊이)만 제시하지 않고, **반드시 작동하는 '규칙'(Rule)**으로 정의해야 한다. (예: "A를 할 때 B가 발생하고, 이것은 C라는 제한을 가진다.")
+3.  **✅ 상호작용성 검증:** 기획의 모든 요소(시스템, 수익 모델, 메커니즘)는 서로 충돌하지 않고 **'시너지를 내도록'** 연결되어야 한다. 특히, 돈과 밸런스의 관계를 가장 엄격하게 정의해야 한다.
+
+---
+### 📌 요약: 성공적인 작업 수행의 체크리스트 (Future Self-Correction Checklist)
+*   [ ] **목표 재정의:** 프로젝트의 최종 목표가 '재미'인지, '수익'인지, 아니면 '전략적 깊이' 중 무엇에 가장 무게를 둘 것인가?
+*   [ ] **메커니즘화:** 모든 개념을 "누가/무엇을 할 때 어떤 규칙으로 작동하는지"라는 동사-주어 구조로 변환할 수 있는가?
+*   [ ] **제약 조건 설정:** 의도적으로 '제한(Constraint)'을 두는 요소를 넣어, 플레이어가 고민하게 만들었는가?

10_Wiki/Topics/_Archive_Orphans/Progressive_Hydration_점진적_하이드레이션.md

@@ -0,0 +1,23 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Progressive Hydration (점진적 하이드레이션)
+description: "점진적 하이드레이션(Progressive Hydration)은 서버가 모든 데이터를 기다리지 않고 HTML 셸(shell)을 즉시 전송한 뒤, 데이터가 해결되는 대로 Suspense 경계를 스트리밍하는 기술입니다 [1]."
+last_updated: 2026-05-04
+---
+
+# Progressive Hydration (점진적 하이드레이션)
+
+## 📌 Brief Summary
+점진적 하이드레이션(Progressive Hydration)은 서버가 모든 데이터를 기다리지 않고 HTML 셸(shell)을 즉시 전송한 뒤, 데이터가 해결되는 대로 Suspense 경계를 스트리밍하는 기술입니다 [1]. 클라이언트는 페이지의 나머지 부분이 여전히 다운로드되는 동안에도 이미 도착한 청크(chunk)들에 대해 먼저 하이드레이션을 시작할 수 있습니다 [1]. 이를 통해 가장 느린 데이터베이스 쿼리를 기다리느라 빈 화면이 노출되는 문제를 방지하고, 사용자에게 점진적인 로딩 경험을 제공합니다 [1].
+
+## 📖 Core Content
+* **청크 기반의 HTML 스트리밍:** 점진적 하이드레이션은 데이터를 모두 기다렸다가 한 번에 전송하는 대신, 데이터를 여러 청크로 나누어 순차적(progressive)으로 전송합니다 [1, 2].
+* **Suspense 마커와 재시도 메커니즘:** 내부적으로 이 기술은 Suspense 주석 노드 마커(`<!--$-->`, `<!--$!-->`)와 재시도 콜백(retry callback) 메커니즘을 통해 스트리밍된 HTML을 처리하고 렌더링합니다 [2]. 
+* **선택적 하이드레이션(Selective Hydration)과의 연계:** React 18에서는 우선순위(Lanes) 시스템을 활용해 하이드레이션 과정을 일시 중단할 수 있습니다 [1]. 만약 하이드레이션이 완료되기 전에 사용자가 버튼을 클릭하면, React는 해당 상호작용 경계로 먼저 이동하여(SyncLane 활용) 상호작용을 처리할 수 있을 만큼만 먼저 하이드레이션한 뒤 나머지 트리의 작업을 재개합니다 [1].
+
+## ⚖️ Trade-offs & Caveats
+점진적 하이드레이션과 선택적 스트리밍 기술을 적용하더라도 기존 SSR(Server-Side Rendering) 구조가 가진 근본적인 한계 비용은 사라지지 않습니다 [3]. 하이드레이션이 수행되려면 결국 자바스크립트 코드가 클라이언트 기기로 전송(ship)되어야 하며, 모든 컴포넌트가 클라이언트 측에서 다시 실행(run)되어야 한다는 치명적인 제약이 따릅니다 [3]. 이러한 구조적 단점은 점진적 하이드레이션만으로는 해결할 수 없으며, 결국 클라이언트로 자바스크립트를 아예 보내지 않는 '서버 컴포넌트(Server Components)' 패러다임이 도입되는 계기가 되었습니다 [3].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/README.md

@@ -0,0 +1,18 @@
+# Topics Chronicle Records
+
+## Project
+- ID: topics
+- Root: /Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics
+- Record root: /Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics/docs/records/Topics
+- Detail level: standard
+
+## Purpose
+Capture project direction, architecture discussion, decisions, and development notes as Markdown.
+
+## Folders
+- `planning/`
+- `discussions/`
+- `decisions/`
+- `development/`
+- `bugs/`
+- `retrospectives/`

10_Wiki/Topics/_Archive_Orphans/React_Fiber_&_Concurrent_Mode_동시성_모드.md

@@ -0,0 +1,24 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: React Fiber & Concurrent Mode (동시성 모드)
+description: "React Fiber는 일시 정지할 수 없는 콜스택 문제를 해결하고 렌더링 성능을 향상하기 위해 도입된 아키텍처입니다 [1]."
+last_updated: 2026-05-04
+---
+
+# React Fiber & Concurrent Mode (동시성 모드)
+
+## 📌 Brief Summary
+React Fiber는 일시 정지할 수 없는 콜스택 문제를 해결하고 렌더링 성능을 향상하기 위해 도입된 아키텍처입니다 [1]. React 18부터는 Lanes 우선순위 시스템을 통해 작업을 중단하고 재개할 수 있는 동시성(Concurrent) 아키텍처를 지원합니다 [2]. 이를 바탕으로 선택적 하이드레이션(Selective Hydration)과 같이 사용자 인터랙션에 즉각적으로 반응하는 최적화된 처리가 가능해졌습니다 [2].
+
+## 📖 Core Content
+* **React Fiber의 도입 배경과 트리 구조:** 과거 React는 클라이언트 측에서 콜스택을 일시 정지할 수 없었고 재렌더링 속도가 느리다는 한계가 있었으며, 이를 해결하기 위해 자체적인 실행 엔진인 Fiber와 Reconciler를 구축했습니다 [1, 3]. React는 서버에서 렌더링된 DOM 트리를 순회하는 동시에 Fiber 트리를 병렬로 구축하며, 각 Fiber를 해당하는 DOM 노드와 일치시켜 `fiber.stateNode`에 참조를 저장하는 방식으로 작동합니다 [4].
+* **선택적 하이드레이션(Selective Hydration):** 기존의 하이드레이션 방식에서는 전체 트리의 하이드레이션이 완료되기 전까지는 상호작용(Interactive)이 불가능하여, 트리 상단의 느린 컴포넌트가 하단 버튼의 클릭 핸들러 작동을 차단하는 문제가 있었습니다 [4]. React 18은 동시성 모드의 기반이 되는 'Lanes' 우선순위 시스템을 사용하여 하이드레이션을 중단하고 사용자 상호작용을 먼저 처리할 수 있도록 이 문제를 해결했습니다 [2].
+* **중단 가능한 작업(Interruptible Work):** 사용자가 특정 요소를 클릭하면, React는 `SyncLane`을 사용하여 해당 경계로 이동한 뒤 상호작용을 처리할 수 있을 만큼만 우선적으로 하이드레이션을 수행하고 이후 나머지 트리에 대한 작업을 재개합니다 [2]. 이는 작업의 중단이 가능하고(Interruptible work) 우선순위에 따라 주도되는(Priority-driven) 아키텍처를 통해 이루어집니다 [2].
+
+## ⚖️ Trade-offs & Caveats
+소스에 관련 정보가 부족합니다. 
+(제공된 소스 데이터에는 React Fiber 아키텍처 및 동시성 모드(Concurrent Mode) 자체를 도입하거나 최적화할 때 발생하는 구체적인 부작용, 제약 사항 또는 기술적 반대 급부(Trade-off)에 대한 설명이 포함되어 있지 않습니다.)
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/React_Hooks_useState,_useEffect.md

@@ -0,0 +1,28 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: React Hooks (useState, useEffect)
+description: "React Hooks(`useState`, `useEffect` 등)는 클래스 컴포넌트를 대체하여 함수형 컴포넌트 내에서 상태(State) 관리와 부수 효과(Side Effects) 처리를 더욱 깔끔하고 간결하게 수행할 수 있도록 제공되는 모던 설계 패턴입니다 [..."
+last_updated: 2026-05-04
+---
+
+# React Hooks (useState, useEffect)
+
+## 📌 Brief Summary
+React Hooks(`useState`, `useEffect` 등)는 클래스 컴포넌트를 대체하여 함수형 컴포넌트 내에서 상태(State) 관리와 부수 효과(Side Effects) 처리를 더욱 깔끔하고 간결하게 수행할 수 있도록 제공되는 모던 설계 패턴입니다 [1, 2]. 상태 기반의 로직을 추출하여 컴포넌트 간의 복잡한 중첩(Nesting) 없이도 손쉽게 코드를 재사용할 수 있도록 함수 합성(Function Composition) 방식을 지원합니다 [3-5].
+
+## 📖 Core Content
+* **상태 및 부수 효과 관리의 단순화:** `useState`와 `useEffect` 훅은 함수형 컴포넌트를 더 깨끗하고 간결하게 만들며 기존 클래스 기반 컴포넌트의 필요성을 대체합니다 [1].
+* **커스텀 훅(Custom Hooks) 패턴으로의 확장:** `useState`, `useEffect`와 같은 기본 훅들을 조합하여 `use` 접두사로 시작하는 커스텀 훅을 생성할 수 있습니다 [3, 4]. 이를 통해 API 데이터 페칭, 폼 상태 관리, 반응형 디자인 핸들링 등 렌더링과 무관한 복잡한 순수 로직을 캡슐화(Encapsulate)하고, 여러 컴포넌트에서 중복 없이 재사용할 수 있습니다 [5, 6].
+* **기존 패턴의 한계 극복:** 렌더 프로프(Render Props)나 고차 컴포넌트(HOC) 방식이 종종 초래하던 깊은 코드 중첩(Wrapper Hell) 문제 및 복잡한 프로퍼티 전달 문제를 불필요한 JSX 중첩 없이 깔끔하게 해결해 줍니다 [3-5].
+* **서버 컴포넌트(RSC) 환경에서의 제약:** React 서버 컴포넌트는 서버에서만 실행되므로 상태(State)를 가지거나 이펙트(Effects)를 발생시킬 수 없습니다 [7]. 따라서 `useState`나 `useEffect`와 같은 훅은 이벤트 핸들러나 상태 관리가 필요한 클라이언트 컴포넌트(명시적으로 `'use client'`가 선언된 영역) 내에서만 사용되어야 합니다 [7, 8].
+
+## ⚖️ Trade-offs & Caveats
+* **엄격한 훅의 규칙 준수 필수:** 훅 패턴은 로직의 재사용성이 뛰어나다는 장점이 있지만, 컴포넌트나 커스텀 훅의 최상위에서만 호출해야 하는 등 '훅의 규칙(Rules of Hooks)'을 엄격하게 준수하지 않으면 에러를 유발하기 쉽습니다 [2, 5].
+* **오래된 클로저(Stale Closure) 문제:** `useEffect` 등을 활용해 커스텀 훅을 작성할 때, 참조된 모든 값을 의존성 배열(Dependency Array)에 포함시켜야 합니다. 그렇지 않으면 렌더링 당시의 오래된 데이터를 참조하는 문제가 발생할 수 있으며, 이를 방지하기 위해 `eslint-plugin-react-hooks`의 `exhaustive-deps` 린트(Lint) 규칙 사용이 권장됩니다 [9].
+* **클린업(Cleanup) 처리 누락 주의:** `useEffect` 내부에서 이벤트 리스너를 추가하거나 외부 리소스를 구독할 때, 메모리 누수를 방지하기 위해 반환값으로 클린업(Cleanup) 함수를 제공하는 것을 잊는 것은 흔한 실수이자 피해야 할 안티 패턴입니다 [9, 10].
+* **과도한 맹목적 최적화(Vibe Coding)의 위험성:** 실제 성능 측정 없이 튜토리얼 등을 모방하여 무분별하게 `useCallback`, `React.memo`와 같은 훅을 모든 곳에 남용하는 것은 오히려 코드를 읽고 디버깅하기 어렵게 만들고 실제 성능을 더 악화시킬 수 있습니다 [11, 12].
+
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/React_Native.md

@@ -0,0 +1,36 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: React Native
+description: "React Native는 2015년 메타(Meta, 구 Facebook)에서 개발한 오픈 소스 크로스 플랫폼 모바일 애플리케이션 개발 프레임워크이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# React Native
+
+## 📌 Brief Summary
+React Native는 2015년 메타(Meta, 구 Facebook)에서 개발한 오픈 소스 크로스 플랫폼 모바일 애플리케이션 개발 프레임워크이다 [1, 2]. 자바스크립트(JavaScript)와 타입스크립트(TypeScript)를 기반으로 하여 단일 코드베이스로 iOS, Android, 웹 및 데스크톱 애플리케이션을 구축할 수 있다 [1, 3]. 고유한 렌더링 엔진 대신 호스트 운영체제의 기본(Native) UI 컴포넌트를 사용하여 사용자에게 100% 네이티브와 같은 외관과 동작을 제공하는 것이 가장 큰 특징이다 [3, 4]. 
+
+## 📖 Core Content
+
+*   **자바스크립트 생태계 및 React 패러다임 활용**
+    React Native는 세계에서 가장 널리 사용되는 자바스크립트와 React 패러다임을 그대로 모바일 환경에 적용한다 [5, 6]. 이는 웹 개발자가 상대적으로 낮은 학습 곡선으로 모바일 개발에 진입할 수 있게 하여 '인재 이동성(Talent Portability)'을 제공하며, 단일 팀이 웹과 모바일 코드베이스 전반에 기여할 수 있는 전략적 이점을 창출한다 [7, 8]. npm 저장소의 방대한 라이브러리는 물론, Zustand, TanStack Query(React Query)와 같은 웹 생태계의 상태 관리 도구들을 그대로 활용할 수 있다 [9, 10].
+*   **네이티브 UI 렌더링 (Native Components)**
+    React Native는 자바스크립트 코드를 실제 플랫폼의 네이티브 UI 컴포넌트(iOS의 `UIView`, Android의 `View`)로 변환하여 렌더링한다 [4, 11]. 이러한 렌더링 방식 덕분에 플랫폼 고유의 스크롤 물리 효과, 텍스트 선택 동작, 자동 수정, 동적 타입, 접근성 기능(VoiceOver, TalkBack) 등을 추가적인 노력 없이 자연스럽게 상속받아 온전한 네이티브 사용자 경험(UX)을 제공한다 [4, 12].
+*   **새로운 아키텍처 (New Architecture)의 도입**
+    기존 React Native의 가장 큰 성능 병목으로 지적되던 비동기 자바스크립트 브릿지(Bridge)를 제거하고, 성능을 극대화하기 위해 아키텍처를 대대적으로 개편하였다 [13, 14].
+    *   **JSI (JavaScript Interface):** 브릿지를 대체하는 기초 레이어로, 자바스크립트 코드가 C++를 통해 네이티브 객체를 직접적이고 동기적으로 호출할 수 있게 하여 직렬화(Serialization) 오버헤드를 완전히 제거한다 [15, 16].
+    *   **Fabric:** JSI를 기반으로 구축된 새로운 UI 렌더링 시스템으로, 메인 스레드에서 동기적인 레이아웃 계산과 렌더링을 가능하게 하여 UI 반응성을 크게 향상시킨다 [16, 17].
+    *   **TurboModules:** 앱 시작 시 모든 네이티브 모듈을 로드하던 기존 방식 대신, 필요할 때만 지연 로딩(Lazy-loading)하는 모듈 시스템으로 초기 시작 시간과 메모리 사용량을 대폭 줄여준다 [16, 18].
+*   **Expo 에코시스템을 통한 개발 표준화**
+    최근 React Native 개발에서는 Expo가 프로덕션 앱 구축의 실질적인 표준(De Facto Standard)으로 자리 잡았다 [19, 20]. EAS(Expo Application Services)를 이용한 클라우드 빌드 및 배포 자동화, Expo Router를 통한 파일 기반 네비게이션, 그리고 네이티브 코드를 직접 건드리지 않고도 외부 라이브러리를 통합할 수 있는 Config Plugins 기능 등을 제공하여 개발 생명주기를 획기적으로 간소화한다 [19, 20].
+
+## ⚖️ Trade-offs & Caveats
+
+*   **플랫폼 파편화 및 유지보수 비용:** iOS와 Android의 네이티브 모듈은 독립적으로 진화하기 때문에, OS 업데이트나 네이티브 플랫폼의 변경 사항에 따라 플랫폼 종속적인 수정이 필요할 수 있다 [21]. 이로 인해 브릿지 및 서드파티 라이브러리 관련 버그를 해결하기 위한 장기적인 유지보수 오버헤드가 발생한다 [22-24].
+*   **버전 업그레이드의 복잡성:** 주요 버전 업데이트 시 광범위한 테스트가 요구되며, 서드파티 라이브러리가 새로운 OS 버전을 즉각적으로 지원하지 않을 경우 호환성 문제가 발생할 수 있다 [22].
+*   **디버깅 난이도:** 자바스크립트 로직과 네이티브 코드가 결합된 하이브리드 환경의 특성상, 에러가 네이티브 영역(혹은 서드파티 라이브러리의 네이티브 코드)에서 발생할 경우 원인을 추적하고 디버깅하는 과정이 순수 네이티브 개발보다 훨씬 복잡해진다 [25, 26].
+*   **커스텀 UI 및 복잡한 애니메이션 한계:** 네이티브 컴포넌트를 사용하기 때문에 플랫폼 표준 인터페이스 구현에는 유리하지만, 렌더링 파이프라인을 완전히 통제하는 Flutter와 비교했을 때 플랫폼 종속성을 벗어나는 극도로 복잡한 맞춤형 애니메이션이나 고사양 그래픽 처리를 구현하는 데에는 구조적 한계가 존재한다 [27-29].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/React_Native_New_Architecture.md

@@ -0,0 +1,27 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: React Native New Architecture
+description: "React Native의 New Architecture(새로운 아키텍처)는 기존의 비동기적 자바스크립트 브릿지(Bridge) 통신 방식이 초래했던 성능 병목 현상을 해결하기 위해 도입된 혁신적인 구조적 변화입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# React Native New Architecture
+
+## 📌 Brief Summary
+React Native의 New Architecture(새로운 아키텍처)는 기존의 비동기적 자바스크립트 브릿지(Bridge) 통신 방식이 초래했던 성능 병목 현상을 해결하기 위해 도입된 혁신적인 구조적 변화입니다 [1, 2]. 이 아키텍처는 JavaScript Interface(JSI)를 기반으로 자바스크립트와 네이티브 코드 간의 직접적이고 동기적인 통신을 가능하게 합니다 [3, 4]. 최신 버전(0.74 이상)부터 브릿지리스(Bridgeless) 모드가 기본으로 활성화되며, 렌더링 성능과 초기 로딩 속도를 대폭 향상시켜 네이티브 앱과 구별하기 힘든 수준의 성능을 제공합니다 [3, 5, 6].
+
+## 📖 Core Content
+* **JSI (JavaScript Interface)**: 새로운 아키텍처의 근간을 이루는 기술로, 자바스크립트 코드가 네이티브 객체를 직접적이고 동기적으로 참조할 수 있게 하는 경량 C++ 레이어입니다 [4, 7]. 이를 통해 데이터를 JSON 문자열로 변환하는 직렬화(Serialization) 오버헤드를 완전히 제거하고 실시간 고성능 통신을 실현합니다 [4, 7].
+* **Fabric Renderer (패브릭 렌더러)**: 기존에 분리되어 있던 스레드 통신 문제를 해결하기 위해 도입된 새로운 UI 렌더링 시스템으로, C++ 기반의 'Shadow Tree'를 스레드 간에 공유합니다 [8]. React 18의 동시성 렌더링(Concurrent Rendering)을 지원하며, 네이티브 측에서 레이아웃을 동기적으로 계산하여 UI가 건너뛰는 현상(UI Jump)을 해결하고 앱의 전반적인 반응성을 개선합니다 [4, 8].
+* **TurboModules (터보 모듈)**: 앱 시작 시 모든 네이티브 모듈을 초기화해야 했던 기존 아키텍처의 단점을 극복한 차세대 네이티브 모듈 시스템입니다 [4, 9]. 모듈이 실제 사용되는 시점에만 로드되는 지연 로딩(Lazy Loading) 방식을 적용하여 앱의 초기 구동 시간을 크게 단축하고 메모리 사용량을 줄입니다 [4, 9].
+* **Codegen (코드젠)**: 빌드 시점에 TypeScript나 Flow의 타입 정의를 분석하여 자바스크립트와 네이티브 양측을 연결하는 C++ 보일러플레이트 코드를 자동 생성하는 도구입니다 [10]. 이를 통해 동적 타입 언어인 자바스크립트와 정적 타입의 네이티브 환경이 통신할 때 발생할 수 있는 오류를 런타임이 아닌 컴파일 시점에 잡아내어 강력한 타입 안전성을 보장합니다 [10].
+
+## ⚖️ Trade-offs & Caveats
+React Native의 새로운 아키텍처는 기존 비동기 브릿지가 유발했던 '브릿지 세금(Bridge Tax)'을 없애고 렌더링 성능을 극대화했지만, 기술적 선택과 유지보수 측면에서 몇 가지 제약 사항과 반대 급부를 수반합니다.
+
+* **네이티브 모듈 통합 및 마이그레이션 복잡성**: 복잡한 네이티브 모듈을 통합하거나 브릿징(Bridging)하는 작업에는 기존 방식보다 추가적인 노력과 기술적 이해도가 필요할 수 있습니다 [11]. 특히, TurboModules 등을 통해 커스텀 네이티브 기능을 구현할 때 C++이나 네이티브 계층에 대한 이해가 전제되어야 합니다 [10, 12]. 
+* **서드파티 라이브러리 의존성과 호환성 문제**: 방대한 React Native 생태계의 서드파티 라이브러리들이 OS 업데이트에 따라 네이티브 모듈 호환성이 깨질 위험이 지속적으로 존재합니다 [13, 14]. 새로운 아키텍처로 넘어가기 위한 메이저 버전 업그레이드 시 플랫폼별 코드를 다시 작성하거나 광범위한 테스트를 수행해야 하므로, 단기적으로 최소 2~3개월의 마이그레이션 기간과 높은 유지보수 비용이 발생할 수 있습니다 [13, 14].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/React_Native_for_Web.md

@@ -0,0 +1,24 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: React Native for Web
+description: "React Native for Web은 기본적으로 iOS와 Android를 지원하는 React Native를 웹 및 Electron 환경으로 확장할 수 있게 해주는 라이브러리이다 [1]."
+last_updated: 2026-05-04
+---
+
+# React Native for Web
+
+## 📌 Brief Summary
+React Native for Web은 기본적으로 iOS와 Android를 지원하는 React Native를 웹 및 Electron 환경으로 확장할 수 있게 해주는 라이브러리이다 [1]. 단일 코드베이스를 사용하여 모바일뿐만 아니라 웹 플랫폼에서도 작동하는 범용적인 애플리케이션을 구축할 수 있도록 돕는다 [2, 3]. 그러나 다중 플랫폼을 공식적으로 지원하는 경쟁 프레임워크에 비해 웹 타겟 지원이 상대적으로 제한적이라는 특성이 있다 [4]. 소스에 관련 정보가 부족합니다.
+
+## 📖 Core Content
+* **웹 환경으로의 플랫폼 확장**: React Native는 본래 Apple iOS/iPadOS 및 Android를 네이티브로 지원하도록 설계되었으나, 'React Native for Web'을 사용하면 웹과 Electron 환경에서도 동일한 개발 방식을 적용하고 확장할 수 있다 [1].
+* **범용 앱 패러다임(Universal App Paradigm)의 구현**: Next.js와 같은 웹 프레임워크에서 영감을 받은 Expo Router 등의 파일 기반 라우팅 시스템을 활용하면 웹과 모바일 개발 사이의 간극을 성공적으로 메울 수 있다 [3]. 개발자는 디렉토리에 파일을 생성하는 것만으로 iOS, Android, 그리고 웹을 위한 화면(Screen)과 내비게이션 스택을 통합적으로 정의할 수 있으며, 이는 웹 개발자들이 매우 매끄럽게 크로스 플랫폼 개발로 전환할 수 있는 환경을 제공한다 [3]. 
+* 소스에 관련 정보가 부족합니다.
+
+## ⚖️ Trade-offs & Caveats
+* **제한적인 웹 및 데스크톱 지원 수준**: 단일 코드베이스로 웹과 모바일, 데스크톱(Windows, MacOS, Linux)을 모두 공식적이고 강력하게 지원하는 Flutter(공식 다중 플랫폼 타겟 지원)와 비교할 때, React Native Web을 통한 웹/데스크톱 타겟 지원은 상대적으로 그 한계가 명확하고 제한적(Limited)이라는 단점이 있다 [4].
+* 소스에 관련 정보가 부족합니다.
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/React_Native_상태_관리_Redux_Toolkit,_Zustand,_React_Query.md

@@ -0,0 +1,26 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: React Native 상태 관리 (Redux Toolkit, Zustand, React Query)
+description: "React Native의 상태 관리는 React 웹 생태계의 성숙한 도구들을 그대로 가져와 활용할 수 있다는 큰 특징을 가집니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# React Native 상태 관리 (Redux Toolkit, Zustand, React Query)
+
+## 📌 Brief Summary
+React Native의 상태 관리는 React 웹 생태계의 성숙한 도구들을 그대로 가져와 활용할 수 있다는 큰 특징을 가집니다 [1, 2]. 전통적으로 Redux Toolkit이 대세로 사용되어 왔으나, 최근에는 보일러플레이트 코드가 적은 Zustand와 서버 상태 관리에 특화된 React Query(TanStack Query)가 실전 표준으로 자리 잡고 있습니다 [2]. 웹과 모바일 간에 상태 관리 코드를 공유함으로써 개발 효율을 극대화하고 클라이언트 로직을 단순화하는 패턴이 널리 사용됩니다 [1-3].
+
+## 📖 Core Content
+* **웹 생태계 도구의 활용 및 코드 공유**: React Native는 React 웹 애플리케이션과 동일한 상태 관리 라이브러리(Redux, Zustand, React Query, Jotai 등)를 그대로 채택하여 사용할 수 있습니다 [1, 2]. 기존 React 웹 애플리케이션이 있는 경우, 비즈니스 로직과 상태 관리 코드를 웹과 모바일 간에 100% 공유할 수 있어 데이터 집약적인 애플리케이션의 전체 개발 노력을 30~50%가량 줄일 수 있습니다 [3].
+* **Redux Toolkit**: React Native 생태계에서 여전히 대세로 자리 잡고 있는 강력한 상태 관리 도구입니다 [2].
+* **Zustand**: Redux Toolkit에 비해 설정 및 보일러플레이트 코드가 적어 최근 실전 표준 중 하나로 강력하게 부상하고 있습니다 [2].
+* **React Query (TanStack Query)**: 서버 상태 관리에 특화된 라이브러리입니다 [2]. 애플리케이션의 서버 데이터 동기화와 캐싱 로직을 직접 구현하지 않고 React Query로 위임함으로써, 클라이언트 측의 상태 관리 로직을 크게 단순화하는 패턴이 현대 모바일 앱 개발에서 강조되고 있습니다 [2].
+
+## ⚖️ Trade-offs & Caveats
+* **보일러플레이트와 생산성의 교환 (Redux Toolkit vs Zustand)**: Redux Toolkit은 오랫동안 대세로 사용되며 안정성이 검증되었으나, 상대적으로 보일러플레이트 코드가 많다는 단점이 있습니다. 반면 Zustand는 이러한 보일러플레이트가 적어 생산성이 높습니다 [2].
+* **서드파티 라이브러리 의존성**: React Native는 상태 관리를 포함하여 많은 부분을 JavaScript 기반의 방대한 서드파티 라이브러리에 의존해야 합니다. 생태계가 크다는 장점이 있지만, 사용할 수 있는 라이브러리들의 품질이 균일하지 않을 수 있다는 위험성(Caveat)을 내포하고 있습니다 [4].
+* 그 외 각 상태 관리 라이브러리(Redux Toolkit, Zustand, React Query)의 구체적인 한계점, 메모리 최적화 이슈, 혹은 세부적인 기술적 트레이드오프에 대해서는 **소스에 관련 정보가 부족합니다.**
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/React_Query_TanStack_Query.md

@@ -0,0 +1,36 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: React Query (TanStack Query)
+description: "React Query(TanStack Query)는 React 생태계에서 가장 성숙하고 잘 유지 관리되는 데이터 관리 라이브러리 중 하나입니다 [1]."
+last_updated: 2026-05-04
+---
+
+# React Query (TanStack Query)
+
+## 📌 Brief Summary
+React Query(TanStack Query)는 React 생태계에서 가장 성숙하고 잘 유지 관리되는 데이터 관리 라이브러리 중 하나입니다 [1]. React Server Components(RSC)와 같은 최신 환경에서도 원활하게 작동하며, 데이터 로딩, 캐싱, 그리고 서버 데이터 동기화를 위임하여 클라이언트 로직을 크게 단순화하는 데 사용됩니다 [1, 2]. React 웹 애플리케이션뿐만 아니라 React Native를 활용한 모바일 개발 환경에서도 서버 상태 관리를 위한 실전 표준으로 자리 잡고 있습니다 [2].
+
+## 📖 Core Content
+*   **데이터 로딩 및 SSR 통합**
+    React Query는 클라이언트 컴포넌트 내부에서 `useSuspenseQuery` 훅을 사용하여 데이터를 효율적으로 로드할 수 있습니다 [3]. `"use client"` 지시어 프래그마를 사용하더라도, 초기 페이지 로드 시에는 서버 사이드에서 데이터 페칭(Fetch)이 발생합니다 [3]. URL 변경에 따라 브라우저 측에서 새로운 쿼리가 실행될 때, 기존 UI가 로딩 상태(Suspense fallback)로 인해 사라지는 것을 방지하기 위해 `startTransition`으로 라우팅 로직을 감싸는 패턴이 활용됩니다 [3, 4].
+
+*   **데이터 업데이트와 무효화 (Invalidation)**
+    데이터를 업데이트(Mutation)한 후, 프론트엔드의 데이터를 최신 상태로 동기화하기 위해 `queryClient.invalidateQueries` API를 사용합니다 [5]. 쿼리 키(Query Key)의 첫 번째 부분을 전달하여 무효화하면, 해당 키로 시작하는 모든 캐시가 지워지고 화면에 활성화된 쿼리들이 즉시 다시 실행되어 UI가 갱신됩니다 [5]. 
+
+*   **프리패칭(Prefetching)을 통한 성능 최적화**
+    Next.js의 앱 라우터 환경에서 URL 파라미터가 변경될 때 프레임워크가 페이지를 새로 렌더링하는 과정에서 지연이 발생할 수 있습니다 [6, 7]. 이를 해결하기 위해 `queryClient.prefetchQuery`를 호출하여 새로운 데이터 요청을 미리 실행시킬 수 있습니다 [7, 8]. 이렇게 하면 Next.js의 네비게이션이 완료된 후 React Query가 데이터 요청을 보낼 때, 이미 진행 중인 프로미스(Promise)를 가로채어 결과를 즉시 사용할 수 있으므로 네트워크 병목이 해소됩니다 [8].
+
+*   **모바일 환경(React Native)에서의 서버 상태 관리 위임**
+    React Native 생태계에서도 React Query는 서버 상태 관리에 특화된 도구로 폭넓게 채택되고 있습니다 [2, 9]. 서버 데이터 동기화와 캐싱 로직을 프레임워크에 위임함으로써 클라이언트 측의 로직을 단순화하는 아키텍처 패턴이 강하게 권장됩니다 [2]. 
+
+## ⚖️ Trade-offs & Caveats
+*   **왕복 통신(Roundtrip)의 증가**
+    데이터를 업데이트하고 화면에 반영할 때, 브라우저에서 서버로 두 번의 왕복 통신(첫 번째는 데이터 업데이트 요청, 두 번째는 `invalidateQueries`에 의한 새로운 데이터 페칭)이 발생합니다 [10]. 하지만 Next.js의 Server Action이 `revalidateTag`를 통해 전체 컴포넌트 트리와 모든 데이터를 다시 로드하는 것에 비하면, React Query의 방식이 더 빠르고 효율적인 경우가 많습니다 [10, 11].
+*   **번들 크기(Bundle Size) 증가**
+    React Query를 사용하기 위해 컴포넌트에 `"use client"`를 선언하게 되면, 해당 컴포넌트는 서버뿐만 아니라 클라이언트 환경에서도 실행되어야 하므로 자바스크립트 번들 크기가 다소 증가하게 됩니다 [12]. 하지만 다수의 데이터 소스와 상호작용이 존재하는 애플리케이션에서는 이러한 약간의 번들 크기 증가를 감수하더라도 복잡성을 줄이는 편이 훨씬 유리합니다 [12, 13].
+*   **SSR 시 쿠키(Cookie) 누락 문제**
+    Next.js 서버에서 SSR을 수행하는 동안 백엔드 API로 보내는 fetch 요청에는 인증 정보 등의 쿠키가 자동으로 포함되지 않습니다 [14, 15]. 이를 해결하려면 최상위 서버 컴포넌트에서 쿠키를 읽어 클라이언트 프로바이더(Provider)로 전달해야 하는데, 이 경우 보안 쿠키가 클라이언트 번들에 노출될 위험이 존재합니다 [16, 17]. 따라서 서버에만 노출되도록 쿠키를 암호화하는 별도의 라이브러리 사용 등의 우회적인 보안 처리가 필요합니다 [15-17].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/React_Server_Actions.md

@@ -0,0 +1,25 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: React Server Actions
+description: "React Server Actions는 React Server Components(RSC) 환경에서 데이터를 조작(Mutate)하기 위해 사용되는 메커니즘으로, 함수 상단에 `'use server'` 프라그마를 선언하여 정의합니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# React Server Actions
+
+## 📌 Brief Summary
+React Server Actions는 React Server Components(RSC) 환경에서 데이터를 조작(Mutate)하기 위해 사용되는 메커니즘으로, 함수 상단에 `"use server"` 프라그마를 선언하여 정의합니다 [1, 2]. 개발자가 일반적인 로컬 함수처럼 클라이언트 이벤트 핸들러에서 호출하면, React가 내부적으로 이를 HTTP 엔드포인트로 변환하여 서버와의 단일 왕복(one round trip)만으로 작업을 처리합니다 [3-5]. 특히 폼(Form) 처리와 같은 단순한 데이터 전송 시나리오에서 뛰어난 개발 편의성과 효율성을 제공합니다 [6].
+
+## 📖 Core Content
+* **데이터 뮤테이션 및 단일 왕복 처리 (Data Mutation & Single Round Trip)**: 서버 액션은 서버 컴포넌트에서 데이터를 업데이트하기 위해 사용하는 기능입니다 [1]. 개발자가 작성한 순수 함수를 클라이언트 컴포넌트로 가져와 버튼 클릭 등의 이벤트 핸들러에서 호출할 수 있으며, 이 과정에서 클라이언트와 서버 간의 네트워크 요청이 단일 왕복으로 이루어집니다 [3, 4].
+* **폼(Form) 처리의 탁월성**: 단일 폼과 제출 버튼이 있는 페이지와 같이 데이터 소스가 복잡하게 얽혀있지 않은 경우, 서버 액션은 매우 뛰어난 성능과 편리성을 보여줍니다 [6]. Next.js 환경에서는 폼의 `action` 속성에 서버 액션을 직접 설정할 수 있으며 `useFormStatus`와 같은 관련 훅을 함께 사용할 수 있습니다 [6].
+* **공개 HTTP 엔드포인트로서의 본질**: 서버 액션은 코드상으로는 내부 함수를 호출하는 것처럼 보이지만, 실제로는 클라이언트의 요청을 HTTP 요청으로 변환하여 서버가 역직렬화하고 실행하는 공개된 HTTP 엔드포인트(Public HTTP endpoint)로 작동합니다 [5, 7].
+
+## ⚖️ Trade-offs & Caveats
+* **직렬화된 순차 실행 (Serial Execution)의 한계**: 서버 액션은 한 번에 하나씩 직렬로만 실행될 수 있습니다 [8]. 여러 액션을 동시에 시도할 경우 대기열(Queue)에 적체되며, 네트워크 환경이 느릴 때 여러 번 저장 버튼을 클릭하면 심각한 성능 지연 병목 현상을 유발할 수 있습니다 [8].
+* **캐시 무효화로 인한 전체 재렌더링 발생**: 서버 액션 내부에서 `revalidateTag` 등을 호출하여 데이터를 업데이트할 때, 프레임워크(예: Next.js)는 변경된 데이터만 부분적으로 업데이트하는 것이 아니라 해당 페이지의 모든 RSC 트리를 다시 렌더링하고 관련 데이터를 전부 다시 요청하는 오버페칭(Over-fetching) 문제를 발생시킬 수 있습니다 [4, 9].
+* **보안 취약점 노출 위험 (Security Vulnerabilities)**: 서버 액션은 누구나 POST 요청을 보낼 수 있는 공개 엔드포인트입니다 [7]. 개발자가 이를 단순히 내부 로컬 함수로 착각하고 입력값에 대한 유효성 검증(Validation) 및 정제(Sanitization)를 생략하면, 원격 코드 실행(RCE)과 같은 치명적인 보안 취약점(예: React2Shell)에 노출될 수 있습니다 [5, 7, 10]. 따라서 일반적인 외부 API를 다룰 때와 동일한 수준의 엄격한 데이터 검증이 필수적입니다 [7].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Reactivity_API.md

@@ -0,0 +1,33 @@
+---
+category: Other
+tags: [auto-wikified, technical-documentation, other]
+title: Reactivity API
+description: "Reactivity API(반응성 API)는 Vue."
+last_updated: 2026-05-04
+---
+
+# Reactivity API
+
+## 📌 Brief Summary
+Reactivity API(반응성 API)는 Vue.js 애플리케이션에서 상태(State)와 로직을 캡슐화하고 관리하기 위해 제공되는 핵심 함수들이다 [1, 2]. `ref()`, `reactive()`, `computed()`, `watch` 등의 도구를 활용하여 반응형 데이터를 선언하며, 단일 소스(Single source of truth)를 여러 컴포넌트 간에 손쉽게 공유할 수 있게 한다 [2-4]. 이를 통해 개발자는 단방향 데이터 흐름의 한계를 극복하고 컴포넌트 외부에서 전역 상태를 단순하게 관리하거나 유연한 로직 모듈(Composables)을 구성할 수 있다 [2, 5, 6].
+
+## 📖 Core Content
+* **`ref()`와 `reactive()`를 통한 로컬 상태 관리**
+  `ref()` 함수는 문자열, 숫자, 불리언, 객체 등 다양한 데이터 타입을 지원하는 다목적 상태 관리 도구로, `.value` 속성을 통해 데이터에 접근하거나 업데이트하는 명확한 구문을 제공한다 [1, 4]. 반면 `reactive()` 함수는 객체, 배열 및 컬렉션 처리에 특화되어 있으며, `.value`를 사용하지 않고 속성에 직접 접근할 수 있어 복잡한 데이터 구조를 직관적으로 다룰 수 있게 돕는다 [7].
+* **파생 상태 생성 및 사이드 이펙트 처리**
+  `computed()` API는 다른 반응형 데이터를 기반으로 파생된 상태를 생성하며, 결과값을 캐싱하고 의존성이 변경될 때만 재계산된다 [4, 8]. `watch` API는 반응형 값의 변경을 관찰하고 API 호출과 같은 사이드 이펙트(비동기 작업 등)를 트리거하는 데 사용된다 [4, 9].
+* **Reactivity API를 활용한 단순한 전역 상태 관리**
+  Reactivity API는 Vue의 컴포넌트 모델과 분리되어 있어 매우 유연하다 [3]. 옵션 API(Options API)의 `data()`가 내부적으로 `reactive()`를 사용하듯, 개발자는 `reactive()`나 `ref()`를 사용해 반응형 객체를 생성한 후 여러 컴포넌트에서 이를 임포트하여 전역 상태(Global State)처럼 공유할 수 있다 [2]. 
+* **Composition API와의 통합 및 Vue 3.5 성능 최적화**
+  Reactivity API는 재사용 가능한 상태 저장 로직을 함수형태로 캡슐화하는 Composable을 구축하는 근간이 된다 [6, 9]. 또한 Vue 3.5 릴리스에서는 반응성 시스템이 크게 리팩토링되어 메모리 사용량이 56% 감소하였으며, 크고 깊은 반응형 배열(Deeply reactive arrays)에 대한 작업 속도가 최대 10배까지 빨라지는 등 대규모 애플리케이션을 위한 성능 향상이 이루어졌다 [10].
+
+## ⚖️ Trade-offs & Caveats
+* **타입 적용의 한계와 반응성 연결 단절 문제**
+  `reactive()`를 원시 값(Primitive values: 문자열, 숫자 등)에 잘못 사용하면 반응성이 깨질 수 있으므로, 원시 값에는 반드시 `ref()`를 사용해야 한다 [11]. 또한 `reactive()`로 생성된 반응형 객체를 직접 구조 분해 할당(Destructuring)할 경우 반응형 연결이 끊어지는 부작용이 발생한다 [11]. 이를 방지하려면 속성에 직접 접근하거나 `toRefs()` 함수를 활용하여 반응성을 유지해야 한다 [11].
+* **무분별한 상태 변이로 인한 유지보수성 저하**
+  Reactivity API로 생성한 객체를 직접 공유할 경우, 임포트한 어떤 컴포넌트에서든 상태를 임의로 변이(Mutate)시킬 수 있다 [12]. 이러한 방식은 단기적으로는 편리하지만 장기적으로는 추적이 어려워 유지보수성을 해친다 [12]. 따라서 상태를 직접 수정하기보다는 명확한 의도를 표현하는 메서드(Action)를 상태 객체와 함께 정의하여 중앙 집중식으로 상태를 변경하도록 강제하는 것이 권장된다 [12].
+* **서버 사이드 렌더링(SSR) 환경에서의 싱글톤 상태 유출**
+  서버 사이드 렌더링(SSR)을 사용하는 애플리케이션에서 단순한 Reactivity API로 전역 상태를 구현하면, 해당 스토어가 싱글톤으로 작동하여 여러 요청(Request) 간에 상태가 공유되거나 데이터가 유출되는 심각한 문제가 발생할 수 있다 [3]. 따라서 대규모 프로덕션 수준의 앱이나 SSR 환경에서는 Pinia와 같은 공식 상태 관리 라이브러리의 도입이 필수적으로 요구된다 [13].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Reusable_Components.md

@@ -0,0 +1,33 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Reusable Components
+description: "재사용 가능한 컴포넌트(Reusable Components)는 애플리케이션 개발 시 코드 중복을 줄이고 개발 효율성을 높이기 위해 고안된 독립적이고 모듈화된 UI 및 논리 단위입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Reusable Components
+
+## 📌 Brief Summary
+재사용 가능한 컴포넌트(Reusable Components)는 애플리케이션 개발 시 코드 중복을 줄이고 개발 효율성을 높이기 위해 고안된 독립적이고 모듈화된 UI 및 논리 단위입니다 [1, 2]. 최신 프론트엔드 프레임워크(React, Vue 등)에서는 합성 컴포넌트(Compound Components), 커스텀 훅(Custom Hooks), 컴포저블(Composables)과 같은 다양한 디자인 패턴을 활용하여 로직과 뷰를 캡슐화합니다 [3-5]. 이를 통해 대규모 시스템 전반에 걸쳐 일관된 사용자 경험을 유지하고 유지보수성을 극대화할 수 있습니다 [1, 2].
+
+## 📖 Core Content
+**프론트엔드 프레임워크별 로직 및 상태 캡슐화 패턴**
+*   **React 패턴**: React에서는 재사용성을 위해 고차 컴포넌트(Higher-Order Components, HOC), 렌더 프로프(Render Props), 커스텀 훅(Custom Hooks), 그리고 복합 컴포넌트(Compound Components) 패턴을 활용합니다 [4, 6-8]. 특히 커스텀 훅은 데이터 페칭 등 복잡한 상태 기반 로직을 추출하여 여러 컴포넌트에서 깨끗하게 재사용할 수 있게 해주며 [8, 9], 복합 컴포넌트 패턴은 드롭다운, 모달, 탭과 같은 복잡한 UI를 구축할 때 암시적 상태를 공유하면서도 뛰어난 유연성을 제공합니다 [5, 10].
+*   **Vue 3 패턴**: Vue 3에서는 Composition API를 활용한 '컴포저블(Composables)'을 통해 상태 저장 로직을 재사용 가능한 단일 함수로 캡슐화합니다 [3, 11, 12]. 또한, 동적 컴포넌트 바인딩(`:is` 속성)과 스코프 슬롯(Scoped Slots)을 조합하여 구체적인 렌더링 로직은 부모가 결정하도록 위임하는 제네릭 및 "헤드리스(Headless)" 컴포넌트를 구축해 재사용성을 극대화합니다 [13, 14].
+
+**컴포넌트 분리 및 구조화 아키텍처**
+*   **스마트 vs 덤 컴포넌트 (컨테이너/프레젠테이션 패턴)**: 로직(상태 관리)과 프레젠테이션(UI 렌더링)을 분리하는 구조입니다 [2, 15]. 데이터를 직접 다루지 않고 props로만 받아서 UI를 렌더링하는 'Dumb(Presentational)' 컴포넌트들은 다른 프로젝트나 컨텍스트에서도 쉽게 재사용이 가능합니다 [2, 15]. 반면 'Smart(Container)' 컴포넌트는 API 호출이나 상태 관리를 전담합니다 [2, 15].
+*   **아토믹 디자인(Atomic Design) 방법론**: 대규모 애플리케이션에서는 컴포넌트를 기초 요소인 원자(Atoms), 이들이 결합된 분자(Molecules), 더 복잡한 유기체(Organisms) 등으로 분류하여 체계적으로 관리함으로써 특정 컴포넌트가 어디에 위치하고 어떻게 재사용되어야 하는지를 명확히 합니다 [16].
+
+**대규모 확장 및 배포 전략**
+기업 규모의 환경에서는 Turborepo나 Nx 같은 모노레포(Monorepo) 아키텍처를 사용하여 여러 애플리케이션이 공통 UI 라이브러리를 공유하도록 설계합니다 [17]. Vite의 라이브러리 모드를 통해 사용하지 않는 코드를 제거(Tree-shaking)할 수 있는 ESM(ES Modules) 형태로 번들링하고, 사설 레지스트리를 통해 안전하게 배포하고 버전을 관리(Semantic Versioning)하는 인프라를 갖추어 재사용성을 스케일업합니다 [18-20].
+
+## ⚖️ Trade-offs & Caveats
+*   **오버엔지니어링(Over-engineering)의 위험**: 모든 컴포넌트에 복합적인 패턴을 적용하려고 하는 것은 피해야 합니다 [21, 22]. 단순한 폼 입력이나 몇 개의 props만으로 구성할 수 있는 간단한 컴포넌트에까지 디자인 패턴을 남용하면 오히려 상태 처리가 복잡해지고 코드를 이해하기 어려워집니다 [5, 21, 23]. 
+*   **래퍼 지옥(Wrapper Hell) 발생**: React의 고차 컴포넌트(HOC)나 렌더 프로프 패턴을 과도하게 재사용 목적으로 중첩하다 보면, 디버깅을 힘들게 만드는 깊은 JSX 중첩 트리(Wrapper Hell)가 발생할 수 있습니다 [6, 7, 24].
+*   **복합 컴포넌트의 오용 및 예외 처리(Misuse)**: 하위 컴포넌트가 부모 컨텍스트 밖에서 단독으로 사용되면 오작동이 발생하므로, 반드시 이에 대한 명확한 에러를 발생시키는 가드(Guard) 로직을 설정해야 합니다 [22, 25, 26]. 또한 하위 컴포넌트를 무작위로 별도 익스포트(export)할 경우 다른 개발자가 의도치 않게 사용할 수 있어 유지보수를 저해할 수 있습니다 [22].
+*   **엄격한 타입 정의의 초기 비용**: 대규모 팀에서 런타임 오류를 방지하고 컴포넌트의 신뢰성을 보장하기 위해서는 Props와 Emits에 대한 엄격한 타입스크립트 기반 컨트랙트(Contract)를 정의하고 Storybook과 같은 툴로 문서화해야 하며, 이는 초기 개발 및 세팅에 추가적인 시간과 리소스를 요구합니다 [27, 28].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Riverpod.md

@@ -0,0 +1,25 @@
+---
+category: Other
+tags: [auto-wikified]
+title: Provider & Riverpod
+description: "Provider와 Riverpod은 Flutter 생태계에서 모바일 애플리케이션을 개발할 때 활용되는 성숙한 상태 관리 및 의존성 주입 패턴입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Provider & Riverpod
+
+## 📌 Brief Summary
+Provider와 Riverpod은 Flutter 생태계에서 모바일 애플리케이션을 개발할 때 활용되는 성숙한 상태 관리 및 의존성 주입 패턴입니다 [1, 2]. 상대적으로 배우기 쉽고 유연하다는 특징을 가지며, 강력한 커뮤니티 지원과 문서를 보유하고 있습니다 [1, 2]. 특히 중소규모 프로젝트에 적용할 경우 높은 개발 생산성을 제공하는 프레임워크 설계 패턴으로 평가받습니다 [2].
+
+## 📖 Core Content
+* **상태 관리 생태계의 주요 옵션**: Flutter 생태계에서는 프로젝트의 규모와 특성에 따라 다양한 상태 관리 패턴(BLoC, Provider, Riverpod, GetX 등)이 사용되며, Provider와 Riverpod은 이 중 널리 쓰이는 핵심 옵션입니다 [1, 2].
+* **유연성과 생산성**: 이 패턴들은 유연한 의존성 주입과 상태 관리 방식을 제공하여 개발자의 학습 곡선이 상대적으로 낮습니다 [2]. 이러한 장점 덕분에 중소규모 프로젝트에서 높은 생산성을 끌어낼 수 있습니다 [2].
+* **Riverpod으로의 진화**: Riverpod은 기존 Provider 패턴이 지니고 있던 한계점을 극복하기 위해 고안된 현대적인 반응형(Reactive) 상태 관리 패턴입니다 [2].
+* **아키텍처 결합도**: Riverpod 패턴은 MVVM(Model-View-ViewModel) 아키텍처와 결합도가 높아, 해당 아키텍처를 기반으로 소프트웨어를 설계할 때 매우 효과적으로 기능합니다 [2].
+
+## ⚖️ Trade-offs & Caveats
+* **대규모 프로젝트에서의 대안**: Provider와 Riverpod은 중소규모 프로젝트에서 생산성이 높은 반면, 대규모 엔터프라이즈 프로젝트의 경우 엄격한 관심사 분리와 높은 예측 가능성 및 테스트 용이성을 제공하는 BLoC 패턴이 더 선호되는 경향이 있습니다 [2].
+* **기존 Provider의 한계점 내포**: Riverpod이 기존 Provider의 한계를 극복한 패턴이라는 점에서, 원형인 Provider 모델에는 반응성이나 상태 관리 상의 특정 제약 사항이 존재함을 유추할 수 있습니다 [2]. 다만, 원형 Provider의 구체적인 기술적 한계가 무엇인지에 대해서는 소스에 관련 정보가 부족합니다.
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Scoped_Styles.md

@@ -0,0 +1,23 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Scoped Styles
+description: "Scoped Styles(범위가 지정된 스타일)는 컴포넌트 경계 내에서 스타일을 엄격하게 캡슐화하여 'CSS 누수(CSS leakage)'와 의도치 않은 스타일 덮어쓰기를 방지하는 아키텍처 기술이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Scoped Styles
+
+## 📌 Brief Summary
+Scoped Styles(범위가 지정된 스타일)는 컴포넌트 경계 내에서 스타일을 엄격하게 캡슐화하여 'CSS 누수(CSS leakage)'와 의도치 않은 스타일 덮어쓰기를 방지하는 아키텍처 기술이다 [1]. `scoped` 속성을 사용하면 전역 스타일 오염을 막고 컴포넌트 고유의 시각적 정체성을 환경에 관계없이 온전히 유지할 수 있다 [1]. 이를 통해 개발자는 다른 모듈과의 충돌 걱정 없이 단순하고 의미 있는 클래스 이름을 자유롭게 사용할 수 있다 [1].
+
+## 📖 Core Content
+* **스타일 캡슐화와 전역 오염 방지**: 마이크로 프론트엔드 아키텍처가 표준으로 자리 잡은 현대 웹 개발에서는 한 모듈의 스타일 변경이 다른 모듈의 레이아웃을 무너뜨리는 '전역 오염(global pollution)'의 위험이 매우 높다 [1]. `scoped` 속성은 이러한 환경에서 스타일을 컴포넌트 경계 내로 격리하여 안전하게 보호하는 일차적인 방어 수단이다 [1].
+* **고유 데이터 속성을 통한 작동 원리**: `scoped` 속성을 적용하면 컴파일러(예: Vue의 경우 PostCSS 활용)가 컴포넌트 내의 모든 HTML 요소에 `data-v-f3f3eg9`와 같은 고유하고 결정론적인 데이터 속성을 추가한다 [1]. 이에 따라 CSS 선택자(selector)들도 해당 속성을 포함하도록 자동 재작성되어 극도로 구체적인(hyper-specific) 특성을 띠게 된다 [1].
+* **클래스 명명의 단순화**: 스타일이 컴포넌트 단위로 격리되므로, 개발자는 다른 애플리케이션 영역에 있는 유사한 이름의 클래스와 충돌할 걱정 없이 `.card`나 `.title`과 같이 간단하고 의미론적인(semantic) 클래스 이름을 사용할 수 있다 [1].
+
+## ⚖️ Trade-offs & Caveats
+* **복잡한 UI 구성을 위한 추가 선택자(Selector) 학습 요구**: 스타일이 엄격하게 캡슐화되어 있기 때문에, 서드파티 자식 컴포넌트나 동적으로 전달된 콘텐츠를 스타일링할 때 제약이 발생할 수 있다 [2]. 전역 CSS 오버라이드에 의존하지 않고 유연성을 유지하려면, 서드파티 하위 컴포넌트를 위한 `:deep()` 선택자나 슬롯(slots)을 통해 전달된 콘텐츠를 위한 `:slotted()`와 같은 최신 선택자 사용법을 반드시 마스터해야 하는 기술적 부담이 따른다 [2].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Selective_Hydration_&_Streaming.md

@@ -0,0 +1,31 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Selective Hydration & Streaming
+description: "**선택적 하이드레이션(Selective Hydration)과 스트리밍(Streaming)**은 서버 사이드 렌더링(SSR)이 가진 초기 로딩 병목 현상과 상호작용 지연 문제를 해결하기 위한 진보된 렌더링 패턴이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Selective Hydration & Streaming
+
+## 📌 Brief Summary
+**선택적 하이드레이션(Selective Hydration)과 스트리밍(Streaming)**은 서버 사이드 렌더링(SSR)이 가진 초기 로딩 병목 현상과 상호작용 지연 문제를 해결하기 위한 진보된 렌더링 패턴이다 [1, 2]. **스트리밍**은 서버가 모든 데이터를 기다리지 않고 UI 셸(Shell)을 즉시 전송한 뒤, 준비되는 데이터를 청크(Chunk) 형태로 클라이언트에 지속적으로 밀어넣는 기술이다 [1, 3]. **선택적 하이드레이션**은 전체 트리가 하이드레이션되는 것을 기다리지 않고 사용자가 상호작용한 특정 컴포넌트를 우선적으로 처리하여, 애플리케이션이 빠르게 반응하도록 돕는 메커니즘이다 [2, 3].
+
+## 📖 Core Content
+* **하이드레이션 갭(Hydration Gap)의 극복**:
+  전통적인 SSR 환경에서는 서버가 렌더링한 HTML이 클라이언트에 표시되더라도, React가 DOM 트리를 순회하며 이벤트 리스너를 연결하는 '하이드레이션'이 완료되기 전까지는 UI가 사용자 입력에 반응하지 않는 문제가 있었다 [2, 4]. 선택적 하이드레이션은 Lanes 우선순위 시스템을 적용하여, 사용자가 아직 하이드레이션되지 않은 요소를 클릭할 경우 기존 하이드레이션 작업을 중단하고 해당 상호작용 경계로 이동하여 우선 처리한 후 나머지 작업을 재개한다 [3].
+
+* **Suspense 기반의 비순차적 스트리밍(Out-of-order Streaming)**:
+  이러한 렌더링 최적화는 Suspense 경계를 적극 활용한다 [3, 5]. 초기 요청 시 서버는 전체 화면의 셸을 먼저 렌더링해 응답하고 데이터 페칭이 지연되는 영역은 `Loading...` 상태로 남겨둔다 [3, 5]. 데이터 로드가 완료되면 서버는 순서에 상관없이 결과물을 클라이언트로 스트리밍하며, 브라우저는 전체 응답을 기다리지 않고 도착한 청크부터 점진적으로 렌더링 및 하이드레이션을 수행한다 [1, 3, 6].
+
+* **RSC(React Server Components) 아키텍처와의 시너지**:
+  스트리밍과 선택적 하이드레이션은 React Server Components 아키텍처와 결합하여 더욱 강력해진다 [7]. 서버 컴포넌트가 데이터를 페칭하여 직렬화된 형태(RSC 페이로드)로 스트리밍하면, 클라이언트 측 React는 이를 수신하는 즉시 기존 Fiber 트리에 병합하고 병렬적으로 하이드레이션을 시작함으로써 성능과 사용자 경험을 극대화한다 [6, 8].
+
+## ⚖️ Trade-offs & Caveats
+* **잔존하는 자바스크립트 실행 비용**:
+  선택적 하이드레이션과 스트리밍은 체감 로딩 속도와 초기 상호작용성을 획기적으로 개선하지만, 궁극적으로 모든 클라이언트 컴포넌트의 자바스크립트가 브라우저로 전송되고 실행되어야 한다는 SSR의 본질적인 한계 비용을 제거하지는 못한다 [9]. 이를 근본적으로 해결하기 위해서는 로직을 서버 컴포넌트로 이관하여 자바스크립트 번들 크기 자체를 줄여야 한다 [9].
+* **데이터 페칭 워터폴(Waterfall)의 위험성**:
+  Suspense를 활용해 비동기 데이터를 병렬로 로딩하더라도, 부모 컴포넌트와 자식 컴포넌트가 각각 별도로 데이터를 페칭하게 될 경우 워터폴 현상이 발생할 수 있다 [10]. 자식 컴포넌트는 부모의 로딩이 끝나기 전까지 페칭을 시작조차 할 수 없으므로, 서로 종속성이 없는 데이터라면 컴포넌트 트리 상단에서 데이터를 미리 로드하여 하위로 전달하도록 최적화해야 한다 [10].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Separation_of_Concerns.md

@@ -0,0 +1,32 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Separation of Concerns
+description: "Separation of Concerns(관심사의 분리)는 모듈, 파일, 클래스가 단 하나의 변경 이유만 가지도록 설계하는 소프트웨어 아키텍처의 핵심 원칙입니다 [1]."
+last_updated: 2026-05-04
+---
+
+# Separation of Concerns
+
+## 📌 Brief Summary
+Separation of Concerns(관심사의 분리)는 모듈, 파일, 클래스가 단 하나의 변경 이유만 가지도록 설계하는 소프트웨어 아키텍처의 핵심 원칙입니다 [1]. 이 원칙은 핵심 비즈니스 로직을 UI, 데이터베이스, 횡단 관심사(Cross-cutting concerns) 등 다른 기술적 세부사항으로부터 완벽히 고립시킴으로써 시스템의 유지보수성과 확장성을 보장합니다 [2, 3]. 현대의 프론트엔드 및 백엔드 프레임워크들은 각자의 고유한 패턴을 통해 이 원칙을 실무에 적용하고 있으며, 비즈니스 로직이 뷰(View) 등 다른 계층으로 누출될 경우 기술 부채가 빠르게 누적되게 됩니다 [3-5].
+
+## 📖 Core Content
+*   **프론트엔드 UI와 비즈니스 로직의 분리:**
+    *   **React:** 렌더 프로프(Render Props) 패턴이나 컨테이너/프레젠테이션(Container and Presentational) 패턴을 적용하여 데이터 페칭 등 '동작 논리'를 UI 렌더링과 물리적으로 분리합니다 [6-8]. 이 패턴들은 컴포넌트의 행동 로직은 캡슐화하되, UI 표현은 이를 사용하는 측에 위임함으로써 깔끔한 관심사 분리를 달성합니다 [6].
+    *   **Vue 3:** Composition API를 활용하여 관련된 상태와 로직을 하나의 블록(Composable)으로 그룹화함으로써 논리적 관심사를 분리합니다 [5]. 이를 통해 비즈니스 로직을 추출하고, 컴포넌트 자체는 순수한 뷰 레이어 기능에 집중하도록 만듭니다 [5].
+    *   **Flutter:** 대규모 프로젝트의 경우 BLoC(Business Logic Component) 패턴과 같은 스트림 기반의 이벤트 중심 상태 관리 방식을 사용하여 비즈니스 로직과 UI 사이의 엄격한 관심사 분리를 강제합니다 [9].
+
+*   **백엔드 아키텍처 수준의 관심사 분리:**
+    *   **Django의 레이어 분리:** 모델(Models)은 오직 데이터의 형태와 저장만을, 뷰(Views)는 HTTP 요청/응답만을, 서비스(Services)는 비즈니스 로직만을 담당하도록 분리하는 것이 실전 권장 사항입니다 [1]. 
+    *   **클린 / 헥사고날 아키텍처:** 핵심 도메인 규칙이 애플리케이션의 여타 부분과 섞이지 않도록 모듈화를 통해 고립시킵니다 [2, 3]. 또한 로깅, 인증, 예외 처리 등 전체 계층을 관통하는 횡단 관심사(Cross-Cutting Concerns)는 비즈니스 로직에 결합되지 않고 미들웨어, AOP, 인터셉터와 같은 인프라스트럭처 계층에서 중앙 집중식으로 분리하여 처리합니다 [2, 10-12].
+
+## ⚖️ Trade-offs & Caveats
+관심사의 분리를 실무 시스템에 구현하기 위해 고도화된 아키텍처 및 디자인 패턴을 도입할 때 다음과 같은 제약 및 반대 급부가 따를 수 있습니다:
+
+*   **디버깅 및 코드 추적의 어려움:** AOP(관점 지향 프로그래밍)나 인터셉터 도구를 통해 횡단 관심사를 너무 '마법처럼(magical)' 분리할 경우, 코드가 어디서 어떻게 실행되는지 명시적으로 보이지 않게 됩니다 [12, 13]. 이는 새로운 개발자의 온보딩을 어렵게 만들고 예상치 못한 곳에서 에러가 발생할 때 디버깅 난이도를 상승시킵니다 [12, 13]. 
+*   **복잡성과 보일러플레이트 코드 증가:** 로직과 프레젠테이션을 명확히 나누는 컨테이너 패턴이나 서비스 레이어 등을 강제하면 불가피하게 생성해야 할 파일 개수와 보일러플레이트 코드가 증가합니다 [14, 15].
+*   **오버엔지니어링 위험:** 지나치게 복잡한 분리 패턴이나 의존성 계층(예: 헥사고날 아키텍처의 포트와 어댑터)은 소규모 프로젝트나 1인 개발 환경에서는 오히려 프레임워크 자체의 기능 구축에 과도한 자원을 쓰게 만들어 개발 생산성을 크게 저하시키는 결과를 초래할 수 있습니다 [16-18]. 프론트엔드 환경에서도 렌더 프로프 패턴을 무분별하게 사용할 경우 깊게 중첩된 JSX 래퍼가 생성되는 '래퍼 지옥(Wrapper Hell)' 현상을 유발합니다 [19, 20].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Server_Actions.md

@@ -0,0 +1,36 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Server Actions
+description: "Server Actions는 React Server Components(RSC) 아키텍처 환경에서 데이터를 변경(mutate)하기 위해 도입된 기능이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Server Actions
+
+## 📌 Brief Summary
+Server Actions는 React Server Components(RSC) 아키텍처 환경에서 데이터를 변경(mutate)하기 위해 도입된 기능이다 [1]. 코드 상단에 `"use server"` 지시어를 선언하여 서버에서 실행되는 함수를 정의하며, 클라이언트 컴포넌트에서는 이를 일반적인 바닐라 함수처럼 간편하게 호출할 수 있다 [2, 3]. 단일 폼(Form) 제출과 같은 상호작용 시 클라이언트와 서버 간의 단일 왕복(one round trip)만으로 데이터 처리 및 화면 갱신이 가능하여 뛰어난 효율성을 제공한다 [4, 5].
+
+## 📖 Core Content
+*   **동작 원리 및 선언 방식**
+    Server Actions는 함수에 `"use server"` 프래그마(pragma)를 선언하여 생성한다 [2]. 클라이언트 컴포넌트는 이 함수를 가져와 버튼 클릭 등의 이벤트 핸들러에서 직접 호출할 수 있으며, 개발자에게는 단순한 함수 호출처럼 보이지만 내부적으로는 프레임워크가 자동으로 생성한 엔드포인트로 네트워크 POST 요청을 보내어 서버에서 코드를 실행한다 [2, 3].
+
+*   **상태 갱신 메커니즘**
+    서버 액션 내에서 데이터베이스 연산(예: SQLite UPDATE)을 수행한 후 `revalidateTag`와 같은 함수를 호출하면, 연관된 데이터의 캐시가 무효화된다 [2, 4]. 이로 인해 변경된 데이터를 기반으로 RSC가 다시 실행되고 업데이트된 마크업이 클라이언트로 전달되며, 이 모든 렌더링 및 통신 과정이 **서버와의 단일 왕복(one round trip) 내에서 완료**된다 [3, 4].
+
+*   **최적의 사용 사례**
+    Server Actions는 폼(form) 요소와 매우 잘 호환되며, 폼의 `action` 속성에 서버 액션을 직접 설정할 수도 있다 [5]. 복잡한 데이터 소스 없이 **단일 폼과 제출 버튼이 있는 페이지 구조에서 가장 뛰어난 성능과 효과**를 발휘한다 [5, 6]. 
+
+## ⚖️ Trade-offs & Caveats
+*   **전체 컴포넌트 트리 재렌더링의 비효율성**
+    서버 액션 실행 후 `revalidateTag`를 호출하면 업데이트된 특정 데이터만 갱신되는 것이 아니라, 캐시에서 해당 태그를 방출함에 따라 **현재 페이지의 전체 컴포넌트 트리가 다시 렌더링되며 모든 데이터를 다시 요청**하게 된다 [4, 7]. 만약 서버 측에 적절한 캐싱 처리가 되어있지 않다면, 서버 액션을 통한 한 번의 왕복 통신이 오히려 `react-query`를 사용한 두 번의 왕복 처리보다 더 오래 걸리는 성능 저하를 초래할 수 있다 [7, 8].
+
+*   **직렬 실행(Serial Execution) 제약**
+    서버 액션은 **한 번에 하나씩만 실행될 수 있다는 치명적인 한계**를 가진다 [9]. 여러 개의 서버 액션을 동시에 시도할 경우 요청이 대기열(Queue)에 쌓이게 되며, 네트워크가 느리거나 불안정한 환경에서는 매우 심각한 성능 지연을 발생시킨다 [9]. 따라서 데이터 소스나 폼이 여러 개 존재하는 복잡한 화면에는 도입하기 적합하지 않다 [6].
+
+*   **심각한 보안 취약점 노출 위험 및 유효성 검사 필수**
+    `"use server"`로 선언된 서버 액션 함수는 로컬 내부 함수처럼 보이지만, **실제로는 인터넷상의 누구나 접근하여 POST 요청을 보낼 수 있는 퍼블릭 HTTP 엔드포인트**로 동작한다 [10]. 개발자가 이를 내부 함수로 착각하여 입력값 유효성 검사를 누락할 경우, 조작된 악성 요청에 의해 인증 없이 원격 코드가 실행되는 'React2Shell (CVE-2025-55182)'과 같은 치명적인 보안 취약점에 노출될 수 있다 [10, 11]. 따라서 기존 Express 라우트 핸들러나 API 엔드포인트를 다룰 때와 동일한 수준의 **엄격한 데이터 검증과 살균(Sanitization) 작업이 반드시 수반**되어야 한다 [10].
+
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Server_State_Management.md

@@ -0,0 +1,31 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Server State Management
+description: "서버 상태 관리(Server State Management)는 프론트엔드 및 백엔드 애플리케이션에서 서버의 데이터를 클라이언트와 동기화하고 캐싱, 무효화(Invalidation) 등을 효율적으로 처리하는 아키텍처 패턴이다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Server State Management
+
+## 📌 Brief Summary
+서버 상태 관리(Server State Management)는 프론트엔드 및 백엔드 애플리케이션에서 서버의 데이터를 클라이언트와 동기화하고 캐싱, 무효화(Invalidation) 등을 효율적으로 처리하는 아키텍처 패턴이다 [1-3]. 특히 React Query(TanStack Query)와 같은 라이브러리를 통해 서버 데이터 동기화 및 캐싱 로직을 위임하여 클라이언트 로직을 단순화하는 방식이 실전 표준으로 자리 잡고 있다 [3]. 또한 서버 사이드 렌더링(SSR) 환경에서는 여러 요청 간의 데이터 유출을 방지하기 위해 상태 인스턴스의 생명주기를 엄격하게 분리하여 관리해야 한다 [4, 5].
+
+## 📖 Core Content
+* **React 생태계의 서버 상태 관리 (React Query와 RSC):** 
+  React와 Next.js 환경에서 React Server Components(RSC)는 서버에서 직접 데이터를 가져오고 결과물만을 직렬화하여 클라이언트에 전달한다 [6, 7]. 데이터 변경(Mutation) 로직에 Server Actions를 사용할 수 있으나, `react-query`의 `useSuspenseQuery`와 `queryClient.invalidateQueries` API를 결합하면 변경된 데이터에 대한 서버 상태를 세밀하게 캐싱하고 업데이트할 수 있다 [2, 8]. React Native와 같은 모바일 크로스 플랫폼 환경에서도 서버 상태 관리에 특화된 TanStack Query(React Query)를 사용하여 동기화 및 캐싱 로직을 위임하는 패턴이 대세로 자리 잡고 있다 [3].
+* **Vue 생태계의 SSR 서버 상태 관리 (Pinia):** 
+  Vue 애플리케이션에서 서버 사이드 렌더링(SSR)을 사용할 때 전역 상태를 싱글톤(Singleton)으로 생성하면, 여러 사용자 요청(Request) 간에 스토어가 공유되어 데이터 유출(Data Leakage) 문제가 발생할 수 있다 [4, 5]. 이를 방지하기 위해 공식 상태 관리 라이브러리인 Pinia는 각 요청마다 새로운 스토어 인스턴스를 생성하는 구조를 취하여 안전하게 서버 상태를 관리한다 [5].
+* **서버 상태의 캐싱(Caching) 및 동기화 패턴:** 
+  분산 시스템에서 캐싱은 서버 상태 관리와 성능 향상을 위한 핵심적인 횡단 관심사(Cross-cutting concern)이다 [9, 10]. 실무에서는 데이터를 읽을 때 먼저 캐시를 확인하고, 캐시에 데이터가 없으면 데이터베이스에서 가져온 후 캐시를 업데이트하는 'Cache Aside' 패턴이 널리 쓰인다 [11, 12].
+
+## ⚖️ Trade-offs & Caveats
+* **React Server Actions와 React Query의 트레이드오프:** 
+  서버 상태를 변경할 때 Server Actions를 사용하면 한 번의 왕복(Round trip)으로 처리가 가능하지만, 한 번에 하나의 서버 액션만 비행(in flight) 상태일 수 있어 직렬로 실행되며, `revalidateTag` 호출 시 전체 컴포넌트 트리가 다시 데이터를 로드해야 하는 심각한 성능 오버헤드가 발생할 수 있다 [13-15]. 반면 `react-query`를 사용하면 상태 업데이트와 캐시 무효화를 위해 두 번의 네트워크 왕복이 필요해지지만, 서버 전체를 리렌더링하는 대신 필요한 데이터만 빠르게 다시 요청할 수 있다는 반대급부가 있다 [16].
+* **SSR 환경에서의 상태 오염 위험:** 
+  SSR을 지원하는 애플리케이션에서 서버 상태를 전역 변수나 싱글톤으로 잘못 구성할 경우, 서버가 처리하는 수많은 유저 요청 사이에 데이터가 교차 오염될 수 있는 보안 및 정합성 제약 사항이 따른다 [4, 5].
+* **캐시 무효화(Cache Invalidation)의 복잡성:** 
+  캐싱을 통해 서버 상태 접근 부하를 줄일 수 있지만, 적절한 데이터 최신화 전략과 캐시 무효화 메커니즘을 구성하지 않으면 사용자에게 오래된(Outdated) 정보를 제공하게 된다 [11, 17]. 특히 분산 환경에서는 서로 다른 노드 간에 캐시된 데이터를 동기화해야 하는 기술적 복잡성이 추가된다 [17].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Service_Layer_Pattern.md

@@ -0,0 +1,25 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Service Layer Pattern
+description: "서비스 레이어 패턴(Service Layer Pattern)은 비즈니스 로직을 모델(Model)이나 뷰(View)에서 분리하여 독립적인 서비스 함수나 클래스에서 관리하는 소프트웨어 아키텍처 설계 방식이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Service Layer Pattern
+
+## 📌 Brief Summary
+서비스 레이어 패턴(Service Layer Pattern)은 비즈니스 로직을 모델(Model)이나 뷰(View)에서 분리하여 독립적인 서비스 함수나 클래스에서 관리하는 소프트웨어 아키텍처 설계 방식이다 [1, 2]. 이 패턴을 적용하면 뷰는 HTTP 요청 및 응답을 처리하는 얇은 어댑터 역할만 수행하고, 실제 데이터의 변경과 핵심 비즈니스 규칙의 적용은 서비스 계층이 전담하게 된다 [2, 3]. 주로 여러 모델에 걸친 복잡한 연산을 캡슐화하거나, 비즈니스 로직의 재사용성 및 유닛 테스트 용이성을 극대화하기 위해 실무에서 도입된다 [2-5].
+
+## 📖 Core Content
+* **비즈니스 로직의 중앙 집중화 및 뷰의 경량화**: 뷰(View)나 컨트롤러 계층에서는 비즈니스 로직을 제거하고, 단순히 입력값을 검증한 뒤 서비스 계층을 호출하는 얇은 HTTP 어댑터로 유지한다 [2, 3]. 이를 통해 핵심 비즈니스 로직은 HTTP 요청 문맥(Context) 없이도 독립적으로 테스트할 수 있으며, 관리 명령어(Management commands), 백그라운드 작업(예: Celery), 또는 다른 서비스 등 여러 진입점에서 재사용할 수 있게 된다 [3].
+* **다중 모델 연산의 캡슐화**: 단일 모델에 종속되는 모델 매니저(Model Manager) 패턴으로는 여러 모델의 상호작용을 처리하기 까다롭다 [4]. 서비스 레이어는 A, B, C 등 여러 개의 연관된 모델을 동시에 초기화하고 이메일 알림 전송과 같은 부수 효과(Side effects)를 안전하게 관리하는 복합적인 연산을 캡슐화하는 데 적합하다 [4, 5].
+* **셀렉터(Selector) 패턴과의 역할 분리 결합**: 데이터의 상태를 변경하는 쓰기(Write) 작업은 서비스(Service) 함수가 담당하고, 데이터 조회 로직을 처리하는 읽기(Read) 작업은 전담 '셀렉터(Selectors)' 계층으로 분리하는 구조가 자주 활용된다 [1, 2, 6]. 이러한 방식은 복잡한 데이터베이스 쿼리 필터링이나 N+1 쿼리 문제 방지를 위한 성능 최적화 로직을 중앙 집중화하여 코드의 책임을 더욱 명확하게 구분한다 [2, 6].
+
+## ⚖️ Trade-offs & Caveats
+서비스 레이어 패턴은 로직의 분리와 테스트 용이성을 제공하지만, 모든 로직을 모델과 뷰에서 억지로 빼내어 거대한 하나의 `services.py` 파일에 수천 줄의 코드로 몰아넣게 되는 관리 상의 최악의 안티 패턴으로 변질될 위험을 내포하고 있다 [7]. 따라서 작고 집중된 서비스와 적절한 도메인 모델 메서드를 혼합하여 사용하는 균형 잡힌 설계가 필수적이다 [7]. 
+
+또한, "뚱뚱한 모델(Fat models)" 접근법을 권장하는 특정 프레임워크(예: Django의 공식 문서 방향) 철학과는 상충될 수 있다 [1]. 프레임워크 자체가 제공하는 데이터베이스 액티브 레코드(Active Record) 패턴의 편의성을 일부 포기해야 하며, 서비스 계층이라는 추가적인 추상화 단계를 도입해야 하므로 단순한 CRUD 수준의 애플리케이션에서는 과도한 엔지니어링(Over-engineering)이 될 수 있다는 반대 의견도 존재한다 [1, 8].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Shader_Compilation_Jank.md

@@ -0,0 +1,31 @@
+---
+category: Computer_Science_and_Theory
+tags: [auto-wikified, technical-documentation, computer_science_and_theory]
+title: Shader Compilation Jank
+description: "**Shader Compilation Jank(셰이더 컴파일 잰크)**는 모바일 기기에서 복잡한 애니메이션이나 새로운 시각 효과가 처음 실행될 때, 필요한 셰이더를 실시간으로 컴파일하면서 발생하는 화면 끊김 현상이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Shader Compilation Jank
+
+## 📌 Brief Summary
+**Shader Compilation Jank(셰이더 컴파일 잰크)**는 모바일 기기에서 복잡한 애니메이션이나 새로운 시각 효과가 처음 실행될 때, 필요한 셰이더를 실시간으로 컴파일하면서 발생하는 화면 끊김 현상이다 [1, 2]. 이는 기존 Flutter 프레임워크에서 지속적으로 지적되던 가장 고질적인 성능 문제였으며, '셰이더 워밍업(shader warmup)'과 같은 꼼수(hacks)로도 완전히 해결할 수 없었다 [2]. 현재는 런타임 대신 빌드 시점에 셰이더를 미리 컴파일하는 **Impeller 렌더링 엔진**이 도입되면서 이 문제가 근본적으로 해결되고 있다 [2, 3].
+
+## 📖 Core Content
+* **발생 원인 및 현상**
+  애플리케이션 구동 중 복잡한 애니메이션이나 사용자가 처음 마주하는 새로운 시각적 효과를 처리할 때, 렌더링 엔진이 **필요한 셰이더를 실시간(on the fly)으로 컴파일**해야 하는 상황에서 발생한다 [1]. 이 컴파일 과정에서 프레임 드랍이 일어나며, 결과적으로 눈에 띄는 화면 끊김인 '잰크(Jank)' 현상을 유발한다 [1, 2].
+* **해결 기술 (Impeller 렌더링 엔진)**
+  Flutter는 셰이더 컴파일 잰크라는 역사적인 성능 문제를 해결하기 위해 기존 엔진을 대체하는 **Impeller**를 도입했다 [1]. Impeller는 런타임에 셰이더를 컴파일하는 대신, **애플리케이션 빌드 과정에서 더 작고 단순하며 최적화된 셰이더의 모든 변형을 미리 컴파일(pre-compile)**하는 아키텍처를 채택했다 [2, 3].
+* **성능 개선 효과**
+  미리 셰이더가 준비되어 있기 때문에 새로운 효과를 처음 렌더링할 때 발생하던 프레임 드랍 현상이 제거된다 [1, 2]. 이를 통해 앱 실행 시 첫 프레임부터 예측 가능하고 매끄러운 성능을 제공하며, **고주사율 기기에서도 복잡한 전환 및 애니메이션을 60fps 또는 120fps로 일관되게 렌더링**할 수 있다 [3, 4].
+
+## ⚖️ Trade-offs & Caveats
+셰이더 컴파일 잰크를 해결하기 위한 아키텍처 변경 및 Impeller 엔진 도입과 관련하여 다음과 같은 제약 사항과 트레이드오프가 존재한다.
+
+* **플랫폼별 도입 성숙도 차이**
+  iOS 환경에서는 Impeller가 2023년(Flutter 3.10)부터 안정화되어 기본 그래픽 백엔드로 적용되었고 잰크 현상이 성공적으로 제거되었다 [2]. 하지만 **Android 환경에서는 아직 프리뷰 단계이거나 활발히 개발이 진행 중인 상태**로, 플랫폼 간에 최적화와 안정성 수준의 격차가 존재한다 [2, 4].
+* **기본 앱 용량(APK 크기) 증가**
+  해당 렌더링 방식을 구현하기 위해 Flutter 앱은 **Impeller 렌더링 엔진과 Dart 런타임을 앱과 함께 배포(ship)해야 하는 부담**이 있다 [5]. 이로 인해 최소한의 기능을 가진 앱이라도 기본 APK 크기가 약 8~12MB 수준에 달하게 되며, 이는 OS의 네이티브 컴포넌트를 사용하는 다른 프레임워크(React Native의 경우 5~8MB)에 비해 메모리와 초기 앱 용량에서 불리한 요소로 작용한다 [5].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Skia.md

@@ -0,0 +1,25 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Skia
+description: "Skia는 2D 그래픽 렌더링 라이브러리로, 크로스 플랫폼 프레임워크인 Flutter가 화면의 모든 픽셀을 직접 그리기 위해 채택한 핵심 엔진으로 잘 알려져 있습니다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Skia
+
+## 📌 Brief Summary
+Skia는 2D 그래픽 렌더링 라이브러리로, 크로스 플랫폼 프레임워크인 Flutter가 화면의 모든 픽셀을 직접 그리기 위해 채택한 핵심 엔진으로 잘 알려져 있습니다 [1-3]. OS 플랫폼의 네이티브 UI 컴포넌트에 의존하지 않고 자체 캔버스에 UI를 렌더링하여 플랫폼 간 동일한 시각적 일관성을 제공합니다 [1, 4]. 최근에는 React Native 생태계에서도 복잡한 그래픽과 애니메이션 처리를 위해 통합되어 사용되고 있습니다 [5].
+
+## 📖 Core Content
+* **Flutter의 핵심 렌더링 엔진**: Flutter는 전통적으로 Skia 2D 그래픽 라이브러리와 통합되어 화면을 렌더링해왔습니다 [2, 3]. 이 접근 방식 덕분에 Flutter는 플랫폼(iOS, Android 등)에 종속되지 않고 픽셀 단위의 완벽한 제어가 가능하며, 복잡한 커스텀 그래픽과 애니메이션을 높은 성능으로 일관되게 표현할 수 있습니다 [1, 3, 6].
+* **React Native로의 확장 적용**: React Native는 기본적으로 네이티브 UI 컴포넌트를 활용하지만, `react-native-skia`와 같은 서드파티 라이브러리를 통해 Skia 엔진에 직접 접근할 수 있습니다 [5]. 이를 도입하면 React Native 환경에서도 고도의 맞춤형 렌더링 역량을 확보할 수 있어, 복잡한 그래픽과 애니메이션 구현 시 Flutter와의 커스터마이징 격차를 해소할 수 있습니다 [5, 7].
+* **Skia에서 Impeller로의 진화**: Skia는 훌륭한 렌더링 도구였으나, 모바일 환경에서 애니메이션 실행 시 실시간으로 셰이더를 컴파일하면서 발생하는 끊김 현상(Shader compilation jank)을 유발하기도 했습니다 [8]. 이러한 한계를 극복하기 위해 Flutter는 Skia를 발전시켜 GPU 사용을 최적화하고 셰이더를 사전 컴파일하는 새로운 렌더링 엔진인 'Impeller'를 도입하여 대체해 나가고 있습니다 [7, 9, 10].
+
+## ⚖️ Trade-offs & Caveats
+* **네이티브 느낌(Native Feel)의 부재 가능성**: Skia를 사용해 자체적으로 위젯을 그리는 방식은 UI의 완벽한 일관성을 보장하지만, 각 플랫폼(OS) 고유의 UI 컴포넌트 동작(예: 접근성 시맨틱, 텍스트 선택 동작, 특정 스크롤 물리 법칙 등)과는 미묘한 차이나 이질감을 발생시킬 수 있습니다 [11-13].
+* **앱 크기 및 메모리 사용량 증가**: Skia와 같은 독자적인 렌더링 엔진과 파이프라인을 애플리케이션 내부에 포함하여 배포해야 하므로, 네이티브 컴포넌트를 호출하는 방식에 비해 초기 앱 번들 크기가 커지고 메모리 오버헤드가 더 높게 발생합니다 [1, 14, 15].
+* **런타임 성능 지연(Jank) 문제**: Skia 렌더링 엔진 하에서는 복잡한 애니메이션이나 새로운 시각 효과를 처음 렌더링할 때 셰이더를 즉석에서 컴파일해야 하므로 프레임 드롭이나 눈에 띄는 끊김 현상(Jank)이 발생할 수 있는 부작용이 존재했습니다 [8, 16].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Skybound_Asset_Purity_Sync.md

@@ -0,0 +1,26 @@
+# [LOG] Skybound Asset Purity & Transparency Synchronization
+
+- **Timestamp**: 2026-04-23 22:52 (KST)
+- **Status**: Completed
+- **Lead**: Steve (Executive Director)
+
+## 1. 작업 내용 (Task Summary)
+- **스프라이트 자산 교체**: 사용자 기체(Falcon, Rayce), 일반 적기(Normal), 엘리트 적기(Elite), 보스 적기(Boss)의 이미지를 배경이 제거된 고해상도 PNG로 전면 교체.
+- **렌더링 로직 최적화**: `SpriteUtils.ts`의 `loadTransparentSprite` 함수 내에서 해당 에셋들이 'Fake Transparency Removal' 로직을 거치지 않고 원본 알파 채널을 그대로 사용하도록 화이트리스트 업데이트.
+
+## 2. 작업 이유 (Rationale)
+- **미학적 완성도**: 대표님(Yesung)께서 직접 가공하신 배경 없는 고해상도 에셋의 무결성을 100% 보존하기 위함.
+- **성능 최적화**: 픽셀 단위의 색상 비교 및 배경 제거 연산(Flood-fill style algorithm)은 CPU 자원을 소모함. 이미 투명 배경이 확보된 에셋에 대해 이를 수행하는 것은 'Shit'이며, 이를 제거함으로써 로딩 속도와 런타임 효율성을 확보함.
+
+## 3. 수정된 코드 (Code Changes)
+- **Target File**: `/Volumes/Data/project/Antigravity/Skybound/src/features/game/utils/SpriteUtils.ts`
+- **변경 사항**: `trueTransparencyAssets` 배열에 `'normal_enemy'`, `'elite_enemy'`, `'boss'` 키워드 추가. 이를 통해 해당 경로를 포함하는 모든 에셋은 원본 투명도를 신뢰하고 즉시 로딩됨.
+
+## 4. 왜 했는가 (Why It Matters)
+- **Zero-Tolerance for Mediocrity**: 도구가 창작자의 의도를 훼손하게 두지 않기 위함. 엔진은 창작자가 제공한 완벽한 재료를 가장 순수한 상태로 유저에게 전달해야 함.
+- **System Integrity**: 에셋의 상태(Transparent vs Solid)에 따라 처리 파이프라인을 분기함으로써 시스템의 유연성과 전문성을 강화함.
+
+## 5. 관련 토픽 (Linked Topics)
+- Skybound: 프로젝트 전체 에셋 관리 표준 수립.
+- Graphics & Performance: 불필요한 이미지 프로세싱 오버헤드 제거.
+- Design & Experience: 픽셀 퍼펙트한 실루엣을 통한 게임 몰입감 증대.

10_Wiki/Topics/_Archive_Orphans/Skybound_Enemy_Orientation_Fix.md

@@ -0,0 +1,21 @@
+# [LOG] Skybound Enemy Orientation Fix (Crab Movement Bug)
+
+- **Timestamp**: 2026-04-23 23:13 (KST)
+- **Status**: Resolved
+- **Lead**: Steve (Executive Director)
+
+## 1. 버그 내용 (Bug Description)
+- **현상**: 적기가 화면 상단에서 등장할 때 정면(아래)을 보지 않고 오른쪽을 바라본 채 하강하는 '꽃게 이동' 현상 발생.
+- **원인**: 적기 생성 시 `rotation` 초기값이 `0`이었으며, 등장 단계(Entrance)에서 플레이어를 조준하는 로직이 조기 종료(Early Return)로 인해 실행되지 않아 렌더링 오프셋(`+PI/2`)만 적용되어 오른쪽을 바라보게 됨.
+
+## 2. 해결 방법 (Resolution)
+- **초기화 강화**: `SpawnerSystem`에서 적기 생성 시 `rotation: Math.PI / 2`를 기본값으로 명시적 할당.
+- **로직 순서 재조정**: `CombatSystem`의 업데이트 루프에서 회전값 계산을 등장 단계 분기점 이전으로 전진 배치하여, 어떤 상태에서도 적기가 플레이어 방향(또는 아래 방향)을 유지하도록 보장.
+
+## 3. 결과 (Expected Result)
+- 적기가 생성되는 즉시 플레이어를 향해 정면을 유지하며 하강함.
+- 시각적 직관성 및 전투 몰입도 향상.
+
+## 4. 관련 토픽 (Linked Topics)
+- Skybound: 엔진 렌더링 무결성 확보.
+- Graphics & Performance: 스프라이트 회전 행렬 최적화.

10_Wiki/Topics/_Archive_Orphans/Smart_vs_Dumb_Components.md

@@ -0,0 +1,24 @@
+---
+category: Frontend
+tags: [auto-wikified, technical-documentation, frontend]
+title: Smart vs Dumb Components
+description: "스마트(Smart) 및 덤(Dumb) 컴포넌트 패턴은 '컨테이너와 프레젠테이셔널(Container and Presentational)' 패턴으로도 잘 알려져 있으며, 애플리케이션의 상태 관리 로직과 UI 렌더링을 분리하는 설계 패턴입니다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Smart vs Dumb Components
+
+## 📌 Brief Summary
+스마트(Smart) 및 덤(Dumb) 컴포넌트 패턴은 '컨테이너와 프레젠테이셔널(Container and Presentational)' 패턴으로도 잘 알려져 있으며, 애플리케이션의 상태 관리 로직과 UI 렌더링을 분리하는 설계 패턴입니다 [1-3]. 덤 컴포넌트는 오직 데이터 표시와 UI 구성에 집중하는 반면, 스마트 컴포넌트는 데이터 페칭 및 상태 관리를 전담하여 덤 컴포넌트에게 데이터를 전달하는 두뇌 역할을 합니다 [2, 4]. 이 패턴은 각 컴포넌트의 책임을 명확히 하여 코드의 재사용성을 높이고 유지보수와 테스트를 용이하게 만듭니다 [1-3].
+
+## 📖 Core Content
+*   **스마트(컨테이너) 컴포넌트 (Smart/Container Components):** 애플리케이션의 '두뇌' 역할을 수행하는 컴포넌트입니다 [2]. 주로 API 통신을 통한 데이터 페칭을 수행하고, 복잡한 로컬 상태나 전역 상태를 관리하는 등 사물들이 "어떻게 작동하는지"에 대한 비즈니스 로직을 처리합니다 [1, 2, 4]. 관리하고 있는 데이터를 렌더링하기 위해 하위의 덤 컴포넌트에게 주입(Drill down)합니다 [2].
+*   **덤(프레젠테이셔널) 컴포넌트 (Dumb/Presentational Components):** 사물들이 "어떻게 보이는지(UI)"에만 전적으로 집중하는 '순수(Pure)' 컴포넌트입니다 [1, 2]. 백엔드 API나 전역 스토어의 존재를 전혀 알지 못하며, 오직 부모 컴포넌트로부터 `props`를 통해서만 데이터를 전달받습니다 [2]. 사용자와의 상호작용 발생 시 이를 직접 처리하지 않고 이벤트를 방출(Emit)하여 부모 컴포넌트에 위임합니다 [2].
+*   **관심사의 분리와 이식성:** 비즈니스 로직과 UI 표현이 철저히 분리되므로, 개발자는 덤 컴포넌트를 앱의 다른 영역이나 전혀 다른 프로젝트에 쉽게 이동시켜 재사용할 수 있습니다 [2, 3]. 
+
+## ⚖️ Trade-offs & Caveats
+*   **장점 (Pros):** 컴포넌트를 독립적으로 테스트하고 스타일링 및 재사용하기가 매우 쉬워집니다 [1]. 데이터 페칭 로직이 분리되어 있으므로 UI 요소의 재사용성이 향상되며, 대규모 애플리케이션에서 복잡한 구조를 이해하고 유지보수하기 유리해집니다 [3, 4].
+*   **단점 (Cons / Caveats):** 하나의 기능을 구현할 때 로직과 프레젠테이션을 별도의 컴포넌트로 강제로 분리해야 하므로, 전반적으로 관리해야 할 파일의 개수가 늘어나고 보일러플레이트(Boilerplate) 코드가 증가하는 부작용이 발생할 수 있습니다 [5].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Spring_Boot_Actuator.md

@@ -0,0 +1,25 @@
+---
+category: Backend
+tags: [auto-wikified, technical-documentation, backend]
+title: Spring Boot Actuator
+description: "Spring Boot Actuator는 애플리케이션의 모니터링과 관리를 돕기 위해 즉시 사용 가능한 프로덕션 레벨의 기능들을 제공하는 도구입니다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Spring Boot Actuator
+
+## 📌 Brief Summary
+Spring Boot Actuator는 애플리케이션의 모니터링과 관리를 돕기 위해 즉시 사용 가능한 프로덕션 레벨의 기능들을 제공하는 도구입니다 [1, 2]. `/actuator` 및 `/actuator/health`와 같은 HTTP 엔드포인트를 노출하여 실행 중인 애플리케이션의 상태와 세부 정보를 파악할 수 있게 해줍니다 [3, 4]. 이를 통해 개발자는 복잡한 시스템 내에서 애플리케이션의 건전성을 쉽게 추적하고 관리할 수 있습니다 [1, 4].
+
+## 📖 Core Content
+* **모니터링 및 관리 엔드포인트 제공:** Actuator는 애플리케이션 상태를 확인할 수 있는 다양한 엔드포인트를 제공합니다. 기본 `/actuator` 엔드포인트를 통해 사용 가능한 전체 Actuator 관련 엔드포인트 목록을 조회할 수 있습니다 [3, 4].
+* **애플리케이션 상태(Health) 확인:** `/actuator/health` 엔드포인트를 호출하면 현재 실행 중인 애플리케이션의 기본적인 상태(Status) 정보를 반환받을 수 있습니다 [3, 4]. 
+* **유연한 노출 설정:** 노출할 엔드포인트의 목록은 `application.yaml` 파일의 `management.endpoints.web.exposure.include` 속성을 수정하여 커스터마이징할 수 있습니다(예: `beans` 추가 시 관련 엔드포인트 활성화) [3].
+* **상세 정보 확장:** 설정을 변경하면 디스크 사용량이나 데이터베이스 상태(`/actuator/health/db`)와 같은 보다 구체적이고 상세한 상태 정보를 반환하도록 구성할 수 있습니다 [5].
+
+## ⚖️ Trade-offs & Caveats
+* **보안 취약점 및 정보 노출 위험:** 데이터베이스 상태나 세부적인 헬스 데이터 등 민감한 정보가 외부로 노출될 수 있으므로, 이러한 상세 정보 반환 기능은 보안상의 이유로 기본적으로 비활성화되어 있습니다 [5].
+* **프로덕션 환경에서의 엄격한 접근 제어 필수:** 프로덕션(운영) 환경에서 Actuator 엔드포인트를 사용할 때는 인가되지 않은 접근을 막기 위해 반드시 안전하게 보호되어야 합니다 [5]. 인증(Authentication) 및 인가(Authorization)를 통해 접근을 제한해야 하며, 민감한 상태 데이터를 활성화할 때는 각별한 주의가 요구됩니다 [5].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Spring_Boot_Microservices.md

@@ -0,0 +1,27 @@
+---
+category: Backend
+tags: [auto-wikified, technical-documentation, backend]
+title: Spring Boot Microservices
+description: "Spring Boot는 엔터프라이즈급 백엔드 애플리케이션 및 마이크로서비스 구축을 위해 널리 사용되는 자바 기반 프레임워크이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Spring Boot Microservices
+
+## 📌 Brief Summary
+Spring Boot는 엔터프라이즈급 백엔드 애플리케이션 및 마이크로서비스 구축을 위해 널리 사용되는 자바 기반 프레임워크이다 [1, 2]. 자동 구성(Auto-configuration), 내장 서버, 스타터 종속성 등을 통해 개발 복잡성을 줄이고 분산 시스템을 빠르게 구축할 수 있도록 돕는다 [3]. 특히 Spring Cloud 및 Netflix OSS와 결합하여 서비스 디스커버리, 지능형 라우팅, 서킷 브레이커 등의 분산 아키텍처 패턴을 효과적으로 구현할 수 있는 강력한 생태계를 제공한다 [4, 5].
+
+## 📖 Core Content
+*   **마이크로서비스 및 분산 시스템 오케스트레이션**: Spring Boot는 Spring Cloud와 결합하여 복잡한 분산 시스템 패턴을 신속하게 구축할 수 있도록 지원한다 [4]. 애플리케이션은 서비스 디스커버리를 위한 Eureka, 지능형 라우팅을 위한 Zuul, 클라이언트 사이드 로드 밸런싱을 위한 Ribbon, 그리고 연쇄 장애 방지를 위한 Hystrix 등의 Netflix OSS 컴포넌트를 통합하여 강력한 장애 허용(Failover) 및 복원력을 확보할 수 있다 [5-7]. 넷플릭스 또한 내부 인프라 솔루션 대신 Spring Boot를 핵심 자바 프레임워크로 채택하여 이러한 오픈소스 생태계를 적극 활용하고 있다 [8, 9].
+*   **아키텍처 패턴 및 의존성 주입(DI)**: Spring Boot는 Java 어노테이션과 IoC(제어의 역전) 컨테이너를 통한 의존성 주입을 활용하여 컴포넌트를 구성하고 관리한다 [10-12]. 이 구조는 핵심 비즈니스 로직을 데이터베이스나 외부 API 등의 인프라로부터 격리하는 헥사고날 아키텍처(Ports and Adapters) 구현에 매우 적합하여, 시스템의 모듈화와 테스트 용이성을 극대화한다 [13-16]. 
+*   **엔터프라이즈 도구 및 데이터 처리**: 엔터프라이즈 요구사항을 충족하기 위한 성숙한 생태계를 갖추고 있다 [17, 18]. Spring Data JPA는 메서드 이름만으로 SQL 쿼리를 생성하여 데이터 접근에 필요한 보일러플레이트 코드를 제거하며 [19, 20], Spring Security는 어노테이션 기반으로 인증, 인가, OAuth2 등의 복잡한 보안 요구사항을 간결하게 처리한다 [21].
+*   **횡단 관심사(Cross-Cutting Concerns) 분리**: 로깅, 보안, 성능 모니터링 등 애플리케이션 전반에 걸친 횡단 관심사는 필터(Filters), 인터셉터(Interceptors), 그리고 AOP(관점 지향 프로그래밍) 메커니즘을 통해 비즈니스 로직과 물리적으로 분리하여 구현된다 [22-24].
+*   **운영 환경(Production-Ready) 모니터링**: 'Actuator' 엔드포인트를 기본적으로 제공하여 애플리케이션의 헬스 체크, 메트릭 모니터링, 디스크 및 데이터베이스 상태 등을 운영 단계에서 쉽게 관리할 수 있다 [3, 25, 26].
+
+## ⚖️ Trade-offs & Caveats
+*   **시작 시간 및 메모리 오버헤드**: JVM 기반으로 구동되는 특성상 Spring Boot 애플리케이션은 시작 시간이 다소 느리며(자동 구성에 따라 5~30초 소요), 트래픽을 처리하기 전부터 높은 기본 힙 메모리(약 256~512MB)를 요구한다 [17, 27, 28]. 따라서 빠른 콜드 스타트가 필수적인 서버리스 환경이나 극단적인 스케일 투 제로(Scale-to-zero) 배포 모델에는 적합하지 않을 수 있다 [29]. 이를 해결하기 위해 GraalVM 네이티브 컴파일을 사용할 수 있으나, 이 경우 빌드 과정의 복잡성이 증가한다 [28].
+*   **가파른 학습 곡선과 '마법' 같은 자동화의 함정**: 개발팀은 Java 언어 생태계, IoC 컨테이너 원리, 방대한 어노테이션 사용법을 충분히 숙지해야 하므로 학습 곡선이 높다 [17, 30]. 특히 AOP 기능이나 자동 구성(Auto-configuration)은 코드량을 대폭 줄여주지만, 내부 실행 흐름을 보이지 않게 감추는 '마법'처럼 동작하므로 문제 발생 시 디버깅이나 동작 원리 추적을 어렵게 만들 수 있다 [24].
+*   **마이크로서비스 인프라 관리의 복잡성**: 마이크로서비스 아키텍처를 도입할 경우 단일 모놀리식(Monolithic) 환경에 비해 로깅, 배포, 디버깅의 난이도가 기하급수적으로 상승한다 [31, 32]. 적절한 자동화와 오케스트레이션 도구가 필수적으로 동반되어야 하며, 규모가 작은 개발 조직이라면 처음부터 마이크로서비스로 시작하기보다는 모놀리식으로 출발해 필요 시 분리하는 전략이 더 유리할 수 있다 [31, 32].
+
+---
+*Last updated: 2026-05-03*

10_Wiki/Topics/_Archive_Orphans/Spring_Cloud_Netflix.md

@@ -0,0 +1,35 @@
+---
+category: Backend
+tags: [auto-wikified, technical-documentation, backend]
+title: Spring Cloud Netflix
+description: "Spring Cloud Netflix는 Netflix가 분산 시스템을 위해 자체 개발한 클라우드 인프라 라이브러리(Netflix OSS)를 Spring Boot 애플리케이션 환경에 통합하여 제공하는 프레임워크 프로젝트이다."
+last_updated: 2026-05-04
+---
+
+# Spring Cloud Netflix
+
+## 📌 Brief Summary
+Spring Cloud Netflix는 Netflix가 분산 시스템을 위해 자체 개발한 클라우드 인프라 라이브러리(Netflix OSS)를 Spring Boot 애플리케이션 환경에 통합하여 제공하는 프레임워크 프로젝트이다. [1, 2] 이 프레임워크를 통해 개발자는 서비스 디스커버리, 서킷 브레이커, 지능형 라우팅, 클라이언트 사이드 로드 밸런싱과 같은 분산 시스템의 공통 패턴을 신속하고 쉽게 구축할 수 있다. [1, 3] 초기에는 커뮤니티 주도로 Netflix OSS와 Spring Boot를 엮어 만들어졌으나, 기술이 성숙함에 따라 Netflix 내부에서도 이를 자사의 핵심 자바 프레임워크로 공식 채택하게 되었다. [2, 4]
+
+## 📖 Core Content
+* **핵심 구성 요소 및 지원 패턴**
+  Spring Cloud Netflix는 마이크로서비스 아키텍처에 필수적인 다양한 패턴과 Netflix OSS 구성 요소들을 제공한다. 주요 기능으로는 서비스 디스커버리를 위한 **Eureka**, 내결함성(Fault tolerance) 및 서킷 브레이커 패턴을 제공하는 **Hystrix**, 지능형 라우팅을 담당하는 **Zuul**, 그리고 클라이언트 사이드 로드 밸런싱을 위한 **Ribbon** 등이 포함되어 있다. [1, 5] 이를 통해 개발자의 로컬 환경부터 데이터 센터, Cloud Foundry와 같은 관리형 플랫폼에 이르기까지 다양한 분산 환경에서 잘 작동하는 서비스를 신속하게 구축할 수 있다. [3]
+
+* **Netflix OSS와 Spring Boot의 선순환(Coming Full Circle)**
+  Netflix는 2007년부터 클라우드로 전환하면서 자체적인 클라우드 인프라 시스템(Eureka, Hystrix, Ribbon 및 구성 관리용 Archaius, 의존성 주입용 Governator 등)을 사내에서 구축하고 2012년경 오픈소스화했다. [5] 2015년에 커뮤니티 주도로 이를 통합한 Spring Cloud Netflix 1.0이 출시되었고, Spring 생태계가 점차 확장되고 엔터프라이즈의 요구(데이터 액세스, 복잡한 보안 관리, 클라우드 제공자 통합 등)를 충족할 만큼 성숙해짐에 따라 Netflix 또한 2018년부터 Spring Boot를 자사의 핵심 프레임워크로 전환했다. [2, 6]
+
+* **생태계의 진화와 커뮤니티 협력**
+  Spring Cloud Netflix의 도입을 통해 Netflix는 Spring이 제공하는 강력하고 문서화된 추상화 및 API를 활용하여 인프라를 더욱 모듈화할 수 있게 되었다. [7, 8] 이러한 과정을 통해 노후화된 Netflix 내부 소프트웨어는 Spring Cloud Load Balancer와 같은 커뮤니티 솔루션으로 대체되고 있으며, Netflix가 새롭게 고안한 적응형 동시성 제한기(Adaptive Concurrency Limiters)와 같은 기술 혁신은 다시 커뮤니티로 기여 되는 형태로 발전하고 있다. [8]
+
+## ⚖️ Trade-offs & Caveats
+* **분산 시스템의 복잡성 증가**
+  Spring Cloud Netflix와 같은 도구로 마이크로서비스 아키텍처를 도입하는 것은 개발 관점에서 복잡성을 단순히 줄여주지 않으며, 오히려 분산 시스템으로 전환됨에 따라 시스템 전반의 복잡성이 크게 증가할 수 있다. [9] 컴포넌트 경계를 깔끔하게 정의하지 못하면, 기존 컴포넌트 내부에 있던 복잡성을 컴포넌트 간의 네트워크 연결 문제로 전가하는 결과만 초래할 수 있다. [10]
+
+* **인프라 자동화 및 팀 역량 요구**
+  이러한 아키텍처를 성공적으로 배포하고 운영하려면 강력한 자동화(Automation)와 오케스트레이션(Orchestration)이 필수적이다. [9] 또한 일부 기능은 여전히 맞춤형으로 직접 구축해야 할 수도 있으며, 팀의 기술적 역량이 부족할 경우 필연적으로 취약한 시스템이 만들어지는 위험이 존재한다. [9, 10]
+
+* **모놀리스 우선 접근법 고려**
+  모든 프로젝트가 마이크로서비스로 시작해야 하는 것은 아니다. 개발자가 20명 미만인 규모이거나 프로젝트 초기 단계라면, 단일 애플리케이션(모놀리스)으로 시작하는 것이 권장된다. [11, 12] 모놀리스 형태가 모든 코드를 하나의 애플리케이션에 포함하고 있어 배포, 로깅 및 디버깅 측면에서 훨씬 다루기 쉽기 때문이며, 모놀리스 구조가 병목을 일으킬 때 비로소 마이크로서비스로 분할하는 것이 합리적인 전략이다. [11, 12]
+
+---
+*Last updated: 2026-05-03*