Antigravity Agent
c24165b8bc
에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게 [공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류. 문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인). - Topic_Programming → Domain_Programming (내부 구조 보존) - Topic_Graphic → Domain_Design - Topic_Business → Domain_Product - Topic_General → Domain_General - _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning), Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing) - 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서) - 빈 폴더 정리 (memory/procedures) - 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.8 KiB
3.8 KiB
category, tags, title, description, last_updated
| category | tags | title | description | last_updated | |||
|---|---|---|---|---|---|---|---|
| Computer_Science_and_Theory |
|
Prefetching | 프리페칭(Prefetching)은 프론트엔드 및 백엔드 프레임워크에서 시스템 성능을 최적화하기 위해 데이터가 실제로 필요해지기 전에 미리 데이터를 불러오는 실전 패턴이다. | 2026-05-04 |
Prefetching
📌 Brief Summary
프리페칭(Prefetching)은 프론트엔드 및 백엔드 프레임워크에서 시스템 성능을 최적화하기 위해 데이터가 실제로 필요해지기 전에 미리 데이터를 불러오는 실전 패턴이다. React 생태계에서는 사용자 라우팅 지연 시간을 상쇄하기 위해 API 요청을 미리 실행하는 데 활용되며, Django와 같은 백엔드 환경에서는 ORM의 N+1 쿼리 문제를 방지하고 연관된 데이터베이스 객체를 효율적으로 가져오는 데 사용된다.
📖 Core Content
- React와 React Query를 활용한 프리페칭 패턴: Next.js와 같은 메타 프레임워크 환경에서 URL 변경 등의 라우팅에 의한 네비게이션 지연이 발생할 때,
react-query의queryClient.prefetchQueryAPI를 사용하여 데이터를 미리 요청할 수 있다. [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