docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거

Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.

10_Wiki/Topic_Programming/Frontend/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*