AI 채팅을 위한 대화 문맥 관리 (Conversation Context Management)

요약 (TL;DR)
AI 코딩 세션은 본질적으로 세션 기반이지만, Copilot Chat은 문맥 창 (Context Window)을 '압축(Compact)' 또는 '삭제(Clear)'라는 두 가지 극단적인 선택지만 있는 수동적인 스크롤 버퍼로 취급합니다. 이 제안서는 대화 문맥을 구조화된 작업 결과물로서 가지치기(Pruning), 고정(Pinning), 스냅샷 생성(Snapshotting) 및 유지(Persisting)할 수 있는 일급 시스템인 '문맥 관리 (Context Management)'를 소개합니다. 핵심 기본 단위는 '세션 프레임 (Session Frame)'입니다. 이는 git에서 버전 관리가 가능하고, 메모리 그래프 (Memory Graphs)로 추출될 수 있으며, 에이전트 (Agents) 간에 전달될 수 있고, 분석 (Analytics)을 통해 측정할 수 있는 경계가 지정된 이름 있는 내보내기 가능한 문맥 단위입니다. 1단계 (선택적 가지치기 + 고정된 턴)는 독립적으로 출시될 수 있습니다. 전체 시스템은 현재 모든 세션 경계에서 지식이 유실되는 루프를 차단합니다.

문제점 (The Problem)
모든 AI 코딩 세션은 시간이 지남에 따라 성능이 저하됩니다. 이는 모델이 나빠져서가 아니라, 문맥 창 (Context Window)이 모델이 무시할 수 없는 노이즈 (Noise)로 가득 차기 때문입니다.

세 가지 실패 모드는 근본 원인은 같으나 규모가 다릅니다:

1. 핵폭탄급 초기화 (The Nuclear Reset - 파괴적)
   작업 중간에 문맥이 가득 찹니다. 선택할 수 있는 옵션은 '압축 (Compact)' (제어할 수 없는 손실이 발생하는 요약) 또는 '삭제 (Clear)' (모든 것을 지움)뿐입니다. 실시간 추론 과정 — 정확한 변수 이름, 절반만 완성된 계획, 방금 전까지 관련이 있었던 마지막 에러 메시지 등을 모두 잃게 됩니다. 40번의 턴 (Turns)에 걸쳐 구축해 온 멘탈 모델 (Mental Model)이 사라집니다. 처음부터 다시 시작해야 합니다.

2. 노이즈 문제 (The Noise Problem - 만성적)
   오래되고 무관한 턴 (Turns)들이 문맥에 무기한 남아 있습니다. 방향을 틀어버린 기능에 대한 초기 브레인스토밍, 아무런 성과 없이 끝난 디버깅 우회로, 두 턴 뒤에 뒤집힌 UI 결정 등이 이에 해당합니다. 모델은 '이것은 무효화되었다'와 '이것은 여전히 유효하다'를 구분하지 못합니다. 사용자가 머릿속에서 이미 버린 오래된 문맥 (Stale Context)을 바탕으로 자신 있게 추론합니다.

3. 막다른 길 문제 (The Dead-End Problem - 잠재적)
   어떤 방향을 탐색하지만, 그것이 작동하지 않습니다. 다시 되돌아가려 하지만, 실패한 시도가 이제 문맥 속에 영구적으로 엮여 버립니다.

“22번째 턴부터는 모두 무시하고 다른 방식으로 시도해줘”라고 말할 방법이 없습니다. 오염된 상태를 그대로 감수하거나, 아니면 모든 것을 초기화해야 합니다.

4. 조회 낭비 문제 (Lookup Waste Problem, 보이지 않는 문제)
   에이전트가 전체 코드베이스에 대해 의미론적 검색 (semantic_search)을 실행하거나, 데이터베이스에서 200개의 레코드를 가져오는 MCP 도구를 호출합니다. 그 결과는 컨텍스트 윈도우 (context window)에 단 한 번 주입되고 사라집니다. 다음 세션, 다음 작업, 동일한 주제가 주어져도 에이전트는 이를 다시 실행합니다. 또 실행하고, 또 실행합니다. “이 조회는 이미 수행했으니 결과를 재사용해”라고 말할 방법이 없습니다. 모든 세션은 제로(zero) 상태에서 시작되며, 이미 완료된 작업에 토큰과 시간을 낭비하게 됩니다.

이것들은 네 개의 버그가 아닙니다. 하나의 누락된 기본 요소(primitive), 즉 문맥 관리 (context management)의 문제입니다.

제안하는 해결책
대화 문맥 윈도우 (conversation context window)를 주기적으로 삭제해야 하는 수동적인 스크롤 버퍼가 아니라, 사용자가 관리할 수 있는 일급 객체 (first-class object)로 취급하십시오.

복잡성 속에서 진화하는 상태 (evolving state)를 관리하기 위해 이미 작동하고 있는 사고 모델인 버전 관리 (version control)를 빌려오십시오.

하지만 여기서 더 나아가야 합니다. 개발자는 단순히 코드 상태만을 관리하는 것이 아니라, 세션 상태 (session state)를 관리합니다. 모든 유의미한 코딩 세션은 시작, 집중 영역, 일련의 발견, 그리고 종료라는 자연스러운 형태를 가집니다. 그 형태는 이미 채팅 기록에 암묵적으로 담겨 있습니다. 제안하는 바는 이를 명시적으로 만드는 것입니다. 즉, 그 형태에 이름과 인터페이스, 그리고 영속성 계층 (persistence layer)을 부여하는 것입니다.

세션 프레임 모델 (The Session Frame Model)
개발자는 자연스럽게 세션 단위로 코딩합니다. “세션 시작” 시점과 “세션 종료” 시점이 존재하며, 그 사이의 모든 것은 하나의 프레임 (frame)을 형성합니다. 프레임이란 목적, 주제, 그리고 일련의 결과물을 가진 경계가 지정된 문맥 단위입니다.

프레임은 이미 개발자들이 소통하는 방식이기도 합니다. 인수인계 문서 (handoff documents)는 수동으로 작성된 프레임입니다. 세션 로그 (session logs)는 비공식적인 프레임입니다. 스프린트 회고 (sprint retrospectives)는 큐레이션된 프레임입니다. 이 모든 것을 수동으로 유지하는 인지적 부하 (cognitive overhead)는 엄청나며, 만약 도구가 세션에 구조가 있다는 점을 이해한다면 이는 완전히 피할 수 있는 문제입니다.

프레임(Frame)이란 무엇인가?
프레임은 다음과 같은 요소를 포함하는, 이름이 지정되고 경계가 설정된 대화의 세그먼트(segment)입니다:

• 시작 경계 (명시적이거나 주제 전환으로부터 추론됨)
• 종료 경계 (세션 종료, 체크포인트, 또는 사용자 정의)
• 주제 레이블 (worklog-search, auth-bug, db-schema-refactor)
• 상태 (active, closed, archived, exported)
• 결과물 세트 — 주요 결정 사항, 코드 변경 사항, 수정된 파일 경로, 생성된 도구 결과물

현재 세션은 이 모든 데이터를 암시적(implicitly)으로 생성합니다. 기능 요청 사항은 이를 명시적(explicitly)으로 드러내는 것입니다.

프레임 작업 (Frame Operations)

작업	내용
Export/Serialize	프레임을 휴대 가능한 형식(JSON, Markdown, 구조화된 YAML)으로 내보냅니다. 이를 다른 에이전트, 다른 도구, 또는 파일로 전송합니다.
Compact	사용자가 지시하는 프레임 요약: 결과물은 유지하고 추론 과정(reasoning trail)은 버립니다. 압축(Compaction)은 항상 범위가 지정되며 적용 전에 미리보기가 제공됩니다.
Prune	압축하지 않고 프레임에서 특정 턴(turn)을 제거합니다. 정밀하고 비파괴적입니다.
Archive	프레임을 삭제하지 않고 닫습니다. 활성 컨텍스트 창(active context window)에서는 벗어나지만, 검색 및 재로드(reloadable)가 가능한 상태로 유지됩니다.
Import	이전에 내보낸 프레임(또는 그 일부)을 새로운 세션의 컨텍스트에 주입합니다.
Merge	두 프레임의 결과물을 하나의 컨텍스트 객체로 결합합니다. 예: "auth-redesign" 프레임의 결과물을 "dashboard-rebuild" 프레임으로 병합합니다.
Extract to Memory	프레임의 주요 엔티티(entities), 결정 사항, 파일 경로를 세션 리셋 후에도 유지되는 영구 메모리 그래프(persistent memory graph)로 추출합니다.

프레임 기반 핸드오프 (Frame-Based Handoffs)
오늘날 AI 보조 개발자들은 다음 세션을 위한 컨텍스트를 보존하기 위해 세션 종료 시 수동으로 핸드오프 문서(handoff documents)를 작성합니다. 이 문서들은 본질적으로 수동으로 작성된 프레임입니다.

프레임에 대한 일급 지원(first-class support)이 이루어지면, 핸드오프는 자동화됩니다:

세션 종료 → 프레임이 닫히고 직렬화(serialized)됨
프레임 포함 내용: 주제(topic), 결정된 사항, 수정된 파일, 미결 질문, 캐싱된 도구 결과(tool results)
다음 세션 시작 → 에이전트가 프레임을 빈 상태(blank slate)가 아닌 초기 문맥(opening context)으로 로드함
프레임을 완전히 다른 에이전트에게 전달할 수 있음 — 이를 통해 문맥 손실 없이 전문화된 에이전트 간의 깔끔한 작업 핸드오프(handoffs)가 가능해짐
이는 단순한 편의 기능이 아닙니다. 여러 AI 에이전트(백엔드용, 프론트엔드용, 리뷰용 등)를 사용하는 팀에게 프레임은 에이전트 간의 네이티브 통신 프로토콜(inter-agent communication protocol)입니다.

기능 상세 분석

1. 체크포인트 (Checkpoints, Snapshots): 대화의 현재 상태를 "커밋(Commit)\

핀 고정 (Pin any turn) — 핵심적인 아키텍처 결정, 확인된 제약 조건, 반드시 참조해야 하는 코드 스니펫 등을 고정할 수 있습니다.
핀 고정된 턴(Pinned turns)은 압축(Compaction), 가지치기(Pruning), 스크롤 아웃(Scroll-off)의 영향을 받지 않습니다.
전용 "활성 문맥 (Active Context)" 패널에 표시되어 모델이 항상 무엇을 알고 있는지 정확히 확인할 수 있습니다.
최대 핀 고정 개수는 토큰 예산(Token budget)에 의해 제한됩니다 (실시간 인디케이터로 표시됨).

1. 브랜치 (Branches) "메인 스레드를 오염시키지 않고 막다른 길을 탐색하십시오."

"여기서 브랜치 생성 (Branch from here)" — 해당 시점까지의 모든 턴을 공유하지만, 그 시점부터는 갈라져 나오는 병렬 대화를 생성합니다.
브랜치는 라벨이 지정되며 탭이나 드롭다운을 통해 전환할 수 있습니다.
브랜치는 폐기(아카이브)하거나 다시 병합(Merge)할 수 있습니다 — 브랜치에서 특정 턴을 선택하여(Cherry-pick) 메인 스레드로 가져올 수 있습니다.
이를 통해 "방식 A를 잃지 않고 방식 B를 시도해 볼 수 있습니다"가 가능해집니다.

1. 턴 주석 (Turn Annotations) "이 턴이 무엇을 의미하는지 모델에게 가르치십시오."

모든 턴에 상태 태그를 사용하여 주석을 달 수 있습니다: ✅ 해결됨 (Resolved), ⚠️ 무효화됨 (Overruled), 📌 핵심 제약 조건 (Key constraint), 🚧 진행 중 (In progress), ❌ 막다른 길 (Dead end).
주석은 선택적으로 모든 요청의 서문(Preamble)으로 주입될 수 있습니다: "참고: 다음의 이전 결정들은 무효화되었습니다: [턴 12, 18, 31]."
이는 가벼운 의미론적 문맥 (Semantic context)입니다 — 내용을 다시 서술함으로써 새로운 토큰을 소비하는 것이 아니라, 상태를 명시하는 데에만 토큰을 사용합니다.

1. 도구 결과 캐싱 (Tool Result Caching, 주제 범위 조회) "이미 수행한 조회를 재사용하십시오."

이는 에이전트 워크플로우 (Agentic workflows)에서 가장 간과되는 토큰 낭비 원인 중 하나입니다.

에이전트가 비용이 많이 드는 도구 — 전체 코드베이스의 의미론적 검색 (Semantic search), MCP 데이터베이스 쿼리, 웹 페치 (Web fetch), 의존성 그래프 순회 (Dependency graph traversal) 등 — 를 실행할 때, 그 결과는 문맥에 한 번 주입되어 사용된 후 사라집니다. 동일한 주제를 다루는 다음 세션은 도구를 처음부터 다시 실행합니다.

제안된 동작:

모든 도구 호출 결과(tool call result)는 "주제별 캐싱(cached for topic)"으로 표시될 수 있습니다 — 예: topic: auth-module.
해당 주제와 일치하는 새로운 작업이 도착하면, 에이전트(agent)는 도구를 다시 실행하기 전에 캐싱된 결과를 제공받습니다.
캐시 항목에는 TTL(Time To Live, 만료 시간)이 있으며, 이는 세션별, 커밋 SHA(commit SHA)별, 날짜별 또는 수동 무효화(manual invalidation)를 통해 설정할 수 있습니다.
캐싱된 결과는 활성 문맥(Active Context) 패널에 다음과 같은 라벨과 함께 표시됩니다: 📦 Cached: codebase-scan (auth) — 2026-06-01.
에이전트는 기반 도구를 재실행하지 않고도 캐싱된 조회 결과(cached lookups)를 바탕으로 추론할 수 있어, 지연 시간(latency)과 토큰 비용(token cost)을 모두 절감할 수 있습니다.

예시:
에이전트가 worklog 모듈 전체에 대해 codegraph_context를 실행하여 3,000토큰의 결과를 생성했습니다. 이 결과는 이제 worklog라는 주제(topic) 아래에 캐싱됩니다. 이번 세션 내의 모든 후속 worklog 작업 — 또는 커밋 SHA가 변경되지 않았다면 세션을 넘나드는 작업 — 은 그래프 탐색(graph traversal)을 다시 실행하는 대신 캐싱된 결과를 참조할 수 있습니다.

이것은 주제 범위의 주변 문맥(topic-scoped ambient context)입니다. 즉, 에이전트가 영역을 다시 발견할 필요 없이 해당 영역을 이미 알고 있는 상태를 의미합니다.

UX 스케치 (UX Sketch)
┌─────────────────────────────────────────┐
│ COPILOT CHAT ⚙️ │
├──────────────┬──────────────────────────┤
│ ACTIVE CTX │ │
│ │ [Turn 1] user: ... │
│ 📌 Turn 3 │ [Turn 2] assistant: ... │
│ 📌 Turn 14 │ ━━━━ checkpoint: "v1" │
│ │ [Turn 3] 📌 ... │
│ CHECKPOINTS │ ... │
│ │ [Turn 22] ░ (pruned) │
│ ✓ "v1" │ [Turn 23] ░ (pruned) │
│ ✓ "auth ok" │ ━━━━ checkpoint: "auth" │
│ │ [Turn 24] user: ... │
│ BRANCHES │ [Turn 25] assistant:... │
│ │ │
│ main ● │ > _ │
│ try-yjs │ │
└──────────────┴──────────────────────────┘

지속성 계층으로서의 Git (Git as the Persistence Layer)
프레임(Frames)은 데이터입니다. 데이터는 버전 관리(version control) 시스템에 속해야 합니다.

Git 아티팩트(Artifacts)로서의 프레임 (Frames as Git Artifacts)
세션 프레임(session frame)이 종료되고 내보내기(export)될 때, 이는 구조화된 아티팩트(artifact)로서 저장소(repository)에 커밋(commit)됩니다. 예: .copilot/sessions/2026-06-02_auth-redesign.frame.json.
프레임 파일에는 다음 내용이 포함됩니다: 주제(topic), 상태(status), 타임스탬프(timestamps), 전체 턴 로그(full turn log)(또는 압축된 요약), 캐시된 도구 결과(tool results), 수정된 파일 경로(file paths), 기록된 결정 사항(decisions), 미결 질문(open questions).
프레임은 해당 프레임이 생성한 코드 변경 사항과 동시에 커밋되어, 대화와 커밋 사이에 끊을 수 없는 연결 고리를 생성합니다.
git log는 코드의 차이(diff)와 그 코드를 생성하게 된 추론(reasoning)을 모두 보여줍니다. git blame은 새로운 차원을 얻게 됩니다. 단순히 누가 한 줄을 변경했는지가 아니라, 어떤 대화가 그 변경을 이끌어냈는지를 보여줍니다.

프레임 → 커밋 연결 (Frame → Commit Linkage)
git log --frames (가상 명령어)

2c4f2ba feat(auth): OAuth 흐름 구현
프레임: .copilot/sessions/2026-06-02_auth.frame.json
주제: auth-redesign | 턴(Turns): 38 | 도구 호출(Tool calls): 4개 캐시됨
주요 결정 사항: [세션 쿠키 대신 JWT 사용, RS256 서명]
종료 시 미결 사항: [리프레시 토큰 로테이션 — 보류]

1dae6b6 refactor(db): 사용자 스키마 정규화
프레임: .copilot/sessions/2026-05-31_db-refactor.frame.json
주제: db-schema | 턴(Turns): 22 | 도구 호출(Tool calls): 6

이것은 단순한 출처(provenance) 확인이 아닙니다. 이것은 조직의 기억(institutional memory)입니다. 모든 결정 뒤에 숨겨진 추론이 코드와 함께 자동으로 보존되는 것입니다.

Git을 통한 세션 재개 (Session Resume from Git)
이전 브랜치를 체크아웃(checking out)하시나요? 해당 브랜치의 세션에서 생성된 프레임 파일들을 사용할 수 있습니다.
에이전트(agent)에게 "이 브랜치에서 마지막으로 작업했을 때의 프레임을 로드해"라고 지시할 수 있으며, 전체 코드베이스를 처음부터 다시 읽지 않고도 원래 코드를 생성했던 것과 동일한 문맥(context)을 가지고 작업을 재개할 수 있습니다.
이것이 "여기 코드가 있습니다"와 "여기 코드가 있고, 이것이 왜 이렇게 작동하는지에 대한 이유도 있습니다"의 차이입니다.

메모리 그래프 추출 (Memory Graph Extraction)
프레임은 지속 가능한 메모리 그래프(persistent memory graphs)를 만들기 위한 원재료입니다.