효율적인 AI 협업을 위한 컨텍스트 윈도우 이해와 Antigravity 활용 가이드

---

효율적인 AI 협업을 위한 컨텍스트 윈도우 이해와 Antigravity 활용 가이드

1. 컨텍스트 윈도우(Context Window)의 정의와 중요성

1-1. 컨텍스트 윈도우의 개념

• 인공지능 모델이 한 번에 처리하고 기억할 수 있는 정보의 총량을 의미한다.
• 사용자와의 대화 기록, 참조된 파일 내용, 시스템 지침 등이 모두 이 가상의 작업 기억 공간에 포함된다.
• 컨텍스트 윈도우의 크기는 AI가 복잡한 프로젝트의 전체 구조를 파악하는 능력과 직결된다.

  1-1-1. 토큰(Token)과 처리 한계

• 문장은 토큰이라 불리는 최소 단위로 분절되어 계산되며, 각 모델은 처리 가능한 최대 토큰 수를 가진다.

2. Antigravity와 Gemini의 컨텍스트 관리 기술

2-1. 거대 컨텍스트 윈도우의 이점

• Antigravity가 사용하는 Gemini 3.0 모델은 백만 단위 이상의 방대한 컨텍스트 윈도우를 제공한다.
• 이는 수만 줄의 소스 코드와 복잡한 기획 문서를 동시에 로드하여 분석할 수 있는 기반이 된다.

  2-2. SDD(Spec-Driven Development)를 통한 맥락 보존

• 대화가 길어지면 초기 논의 내용이 망각될 수 있으나, 명세서(Spec) 작성을 통해 이를 방지한다.
• implementation_plan.md와 같은 파일은 대화의 핵심 결론을 박제하는 '기억의 앵커' 역할을 수행한다.

  2-2-1. 소스 오브 트루스(Source of Truth) 기법

• 명세서 상단에 에이전트 지침을 명문화하여 새로운 세션에서도 일관된 동작을 유도한다.

  > **[Agent Directive: Source of Truth]**
  > 이 문서는 프로젝트의 핵심 설계도이며 모든 의사결정의 근거이다. 
  > 새로운 에이전트는 이 문서의 제약 사항을 최우선으로 준수해야 한다.

2-3. 온디맨드(On-demand) 분석과 RAG 기술

• Antigravity는 모든 코드를 한꺼번에 컨텍스트에 넣지 않고, 필요할 때 필요한 곳만 비추는 '스포트라이트' 방식을 사용한다.
• RAG(Retrieval-Augmented Generation): 사용자 질문과 가장 관련 깊은 코드 조각을 실시간으로 검색하여 컨텍스트에 주입한다.
• 로컬 벡터 인덱스: 사용자 PC의 .gemini/antigravity/implicit 경로에 SQLite 기반의 벡터 DB와 파일 해시 지도를 생성하여 프로젝트 전체 구조를 시맨틱(Semantic)하게 파악한다.

3. Antigravity 활용 최적화 팁

3-1. "Start a New Conversation"의 전략적 사용

• 대화창의 응답 속도가 저하되거나 에이전트가 이전 합의 사항을 헷갈리기 시작할 때 사용한다.
• 전환이 필요한 결정적 순간:
  1. 새로운 단계(Phase)나 아예 다른 비즈니스 로직을 시작할 때.
  2. 기획 문서(spec)나 디자인 시스템의 핵심 규칙이 변경되었을 때.
  3. 긴 버그 수정 사이클이 끝나고 '깨끗한 최종 코드' 상태로 다음 작업을 하고 싶을 때.
  4. 이전의 특정 결정을 번복하고 완전히 새로운 방식으로 접근하려 할 때.

3-2. 핸드오프 기법

• 새 대화창으로 넘어가기 전, 현재까지의 합의 사항을 요약한 후 새 대화창에 handoff.md 파일을 전달함으로써 '과거의 의사결정 맥락'을 계승한다.

  3-2-1. 이상적인 핸드오프 템플릿 예시

• 템플릿은 handoff_template.md 파일에 정의한다. 기존 대화창에 이 템플릿을 전달하고 인수인계를 요청한다.

    # AI Context Handoff Template
  
    > **[Agent Directive: Handoff Creation]**
    > 에이전트는 현재까지의 대화 맥락을 분석하여 이 템플릿 형식에 맞춰 요약된 내용을 생성하고, 이를 프로젝트 루트의 `handoff.md` 파일에 저장(이미 존재할 경우 덮어쓰기)하세요. 
    > 이 과정은 새로운 대화 세션에서 맥락을 완벽하게 복구하기 위한 필수 절차입니다.
  
    ---
  
    ### [시스템 지침]
    - [ ] implementation_plan.md를 읽고 작업을 이어가줘.
    - [ ] (추가적인 특별 지침이 있다면 여기에 작성)
  
    ### [현황 요약]
    - **완료된 기능:** 
    - **디자인 철학/결정:** 
    - **주의해야 할 예외/버그:** 
  
    ### [다음 목표]
    - 이번 세션에서 집중적으로 처리해야 할 핵심 Task 명시
  
    ---
    *Template version 1.0*

4. 프로젝트 명칭 관리와 도메인 컨텍스트

4-1. 명칭 일관성의 중요성

• 프로젝트 명칭은 단순한 이름이 아닌, AI가 도메인 지식을 인출하는 '식별 키'이다.
• 이름 불일치 시 발생 가능한 리스크:
  1. 설정 오류: package.json이나 배포 설정 파일에서의 경로/식별자 불일치로 인한 빌드 에러.
  2. 도메인 맥락 희석: 일반적인 이름(예: web-app)은 AI를 일반적인 답변에 치중하게 만들 수 있으나, 구체적인 이름(예: wi-connect)은 AI가 해당 도메인(Wi-Fi, 네트워크)의 특수성을 고려하게 만든다.
  3. 신뢰도 저하: 문서나 UI 상의 잘못된 명칭 노출은 최종 결과물의 전문성을 해친다.

4-2. 프로젝트 명칭 변경 시 대응 절차

• 즉각적인 통보: 사용자가 임의로 프로젝트 폴더명이나 서비스명을 변경했다면, 즉시 Antigravity에게 이 사실을 명시적으로 알려야 한다.
• 동기화 작업 요청: 에이전트에게 "프로젝트명이 변경되었으니 모든 설정 파일(package.json, HTML title, README 등)과 경로를 전수 조사하여 수정해줘"라고 요청함으로써 인덱스와 실제 코드 간의 괴리를 제거해야 한다.
• 새 세션의 예방 조치: 명칭 변경 후에는 새로운 대화창을 시작하여 깨끗한 상태에서 바뀐 이름을 'Source of Truth'로 인식시키는 것이 가장 안전하다.

5. 결론 및 요약

5-1. 지능형 에이전트와의 협업 원칙

• 컨텍스트 윈도우는 단순한 저장 공간이 아닌, AI와 사용자가 공유하는 '사고의 장'이다.
• 효율적인 요약, 명확한 문서화, 그리고 일관된 브랜딩(프로젝트 명칭)은 AI 에이전트의 생산성을 극대화하는 3대 핵심 요소이다.

---