컨텍스트 압축

컨텍스트 압축 전략

에이전트 세션이 수백만 토큰의 대화 기록을 생성할 때 압축은 필수적입니다. 순진한 접근 방식은 요청당 토큰을 최소화하기 위해 공격적으로 압축하는 것입니다. 올바른 최적화 목표는 작업당 토큰입니다: 작업을 완료하는 데 소비된 총 토큰이며, 압축으로 인해 중요한 정보가 손실될 때 재조회 비용을 포함합니다.

활성화 시점

다음과 같은 경우 이 스킬을 활성화하세요:

• 에이전트 세션이 컨텍스트 창 한도를 초과할 때
• 코드베이스가 컨텍스트 창을 초과할 때 (500만 토큰 이상 시스템)
• 대화 요약 전략을 설계할 때
• 에이전트가 수정한 파일을 "잊어버리는" 경우를 디버깅할 때
• 압축 품질 평가 프레임워크를 구축할 때
• 결정, 파일, 위험 및 다음 작업을 보존하는 내구성 있는 핸드오프 요약을 만들 때

다른 스킬이 담당하는 인접 작업에는 이 스킬을 활성화하지 마세요:

• 마스킹, 프리픽스 캐싱 또는 파티셔닝과 같은 일반적인 토큰 효율 전략: context-optimization.
• 완화 방법을 선택하기 전에 긴 컨텍스트가 실패하는 이유를 진단: context-degradation.
• 요약 없이 원시 출력, 로그 또는 계획을 파일에 쓰기: filesystem-context.
• 세션 간 장기 의미 메모리 설계: memory-systems.
• 모델이 자체 컨텍스트를 언제, 어디서 다시 작성할지 결정: self-managed-context. 이 스킬은 대체 텍스트가 반드시 보존해야 할 내용을 결정합니다.

핵심 개념

컨텍스트 압축은 토큰 절감과 정보 손실 간의 균형을 유지합니다. 세션 특성에 따라 세 가지 프로덕션 준비 접근 방식 중에서 선택하세요:

1. 앵커 기반 반복 요약: 파일 추적이 중요한 장기 실행 세션에 구현하세요. 세션 의도, 파일 수정, 결정 및 다음 단계에 대한 명시적 섹션이 있는 구조화되고 지속적인 요약을 유지합니다. 압축이 트리거되면 새로 잘린 범위만 요약하고 처음부터 다시 생성하는 대신 기존 요약과 병합합니다. 이는 요약이 전체적으로 재생성될 때 누적되는 드리프트를 방지합니다 — 각 재생성은 모델이 작업에 필요하지만 우선순위가 낮다고 간주하는 세부 정보를 잃을 위험이 있습니다. 구조는 전용 섹션이 요약자가 채워야 하는 체크리스트 역할을 하여 정보 손실을 포착하므로 보존을 강제합니다.

2. 불투명 압축: 재조회 비용이 낮고 최대 토큰 절감이 필요한 짧은 세션에 사용합니다. 재구성 충실도에 최적화된 압축된 표현을 생성하여 99% 이상의 압축률을 달성하지만 해석 가능성을 완전히 희생합니다. 절충점이 중요합니다: 탐침 기반 평가 없이는 무엇이 보존되었는지 확인할 방법이 없으므로 디버깅이나 아티팩트 추적이 중요한 상황에서는 절대 사용하지 마세요.

3. 재생성 전체 요약: 요약 가독성이 중요하고 세션에 명확한 단계 경계가 있는 경우 사용하세요. 각 압축 트리거 시 자세한 구조화된 요약을 생성합니다. 약점은 반복 주기에 걸친 누적 세부 정보 손실입니다 — 각 전체 재생성은 이전 요약에 보존된 세부 정보의 우선순위를 낮출 수 있는 새로운 패스입니다.

세부 주제

요청당 토큰이 아닌 작업당 토큰 최적화

작업 시작부터 완료까지 소비된 총 토큰을 측정하고, 개별 요청당 토큰이 아닙니다. 압축이 파일 경로, 오류 메시지 또는 결정 근거를 삭제하면 에이전트는 다시 탐색하고, 파일을 다시 읽고, 결론을 다시 도출해야 하므로 압축이 절약한 것보다 훨씬 더 많은 토큰을 낭비합니다. 요청당 0.5% 더 많은 토큰을 절약하지만 재조회를 20% 더 많이 유발하는 전략은 전체 비용이 더 많이 듭니다. 재조회 빈도를 주요 품질 신호로 추적하세요: 에이전트가 이미 처리한 파일을 반복해서 다시 읽도록 요청하면 압축이 너무 공격적인 것입니다.

먼저 아티팩트 추적 문제 해결

아티팩트 추적 무결성은 종종 압축 평가에서 가장 취약한 측면입니다 (claim-context-compression-factory-benchmark). 일반 요약은 이를 안정적으로 유지할 수 없으므로 사전에 해결하세요.

모든 압축 주기에서 다음 범주를 명시적으로 보존하세요:

• 생성된 파일 (전체 경로)
• 수정된 파일 및 변경 사항 (파일 이름뿐만 아니라 함수 이름 포함)
• 읽었지만 변경되지 않은 파일
• 특정 식별자: 함수 이름, 변수 이름, 오류 메시지, 오류 코드

요약자가 이러한 세부 정보를 캡처하도록 의존하는 대신 에이전트 스캐폴딩에 별도의 아티팩트 인덱스 또는 명시적 파일 상태 추적을 구현하세요. 전용 파일 섹션이 있는 구조화된 요약이라도 긴 세션에서 완전성을 유지하는 데 어려움을 겪습니다.

필수 섹션으로 요약 구성

암묵적인 정보 손실을 방지하는 명시적 섹션으로 구조화된 요약을 작성하세요. 각 섹션은 요약자가 채워야 하는 체크리스트 역할을 하여 누락을 눈에 띄게 만듭니다.

## 세션 의도
[사용자가 달성하려는 것]

## 수정된 파일
- auth.controller.ts: JWT 토큰 생성 수정
- config/redis.ts: 연결 풀링 업데이트
- tests/auth.test.ts: 새 설정을 위한 모드 설정 추가

## 내린 결정
- 요청당 연결 대신 Redis 연결 풀 사용
- 일시적 오류에 대한 지수 백오프 재시도 로직

## 현재 상태
- 14개 테스트 통과, 2개 실패
- 남은 작업: 세션 서비스 테스트를 위한 모의 설정

## 다음 단계
1. 나머지 테스트 실패 수정
2. 전체 테스트 스위트 실행
3. 문서 업데이트

에이전트 도메인에 맞게 섹션을 조정하세요. 디버깅 에이전트는 "근본 원인" 및 "오류 메시지"가 필요하고; 마이그레이션 에이전트는 "소스 스키마" 및 "대상 스키마"가 필요합니다. 특정 섹션보다 구조 자체가 더 중요합니다 — 명시적 스키마는 자유 형식 요약보다 성능이 뛰어납니다.

압축 트리거 전략적으로 선택

압축을 트리거하는 시점은 압축 방법만큼 중요합니다. 세션 예측 가능성에 따라 트리거 전략을 선택하세요:

전략	트리거 지점	절충점
고정 임계값	컨텍스트 사용률 70-80%	간단하지만 너무 일찍 압축할 수 있음
슬라이딩 윈도우	마지막 N 턴 + 요약 유지	예측 가능한 컨텍스트 크기
중요도 기반	관련성이 낮은 섹션 먼저 압축	복잡하지만 신호 보존
작업 경계	논리적 작업 완료 시 압축	깔끔한 요약이지만 예측 불가능한 타이밍

코딩 에이전트의 경우 슬라이딩 윈도우와 구조화된 요약을 기본값으로 사용하세요 — 예측 가능성과 품질의 최상의 균형을 제공합니다. 세션에 명확한 단계 전환이 있는 경우 (예: 연구 후 구현 후 테스트) 작업 경계 트리거를 사용하세요.

메트릭이 아닌 탐침으로 압축 평가

ROUGE 또는 임베딩 유사성과 같은 전통적인 메트릭은 기능적 압축 품질을 포착하지 못합니다. 요약은 어휘 중복성에서 높은 점수를 받을 수 있지만 에이전트가 계속 진행하는 데 필요한 파일 경로 하나를 놓칠 수 있습니다.

탐침 기반 평가를 사용하세요: 압축 후 중요한 정보가 살아남았는지 테스트하는 질문을 던집니다. 에이전트가 올바르게 답하면 압축이 올바른 정보를 보존한 것입니다. 그렇지 않으면 추측하거나 환각을 냅니다.

탐침 유형	테스트 내용	예시 질문
재현율	사실적 유지	"원래 오류 메시지는 무엇이었나요?"
아티팩트	파일 추적	"수정한 파일은 무엇인가요?"
연속성	작업 계획	"다음에 무엇을 해야 하나요?"
결정	추론 체인	"Redis 문제에 대해 무엇을 결정했나요?"

6가지 차원에서 압축 점수 측정

코딩 에이전트에 대한 압축 품질을 다음 차원에서 평가하세요. 정확성과 아티팩트 추적 보존은 어휘 유사성보다 방법을 더 명확하게 구분하는 경향이 있으므로 (claim-context-compression-factory-benchmark), 압축은 일반 요약 이상의 특수 처리가 필요합니다.

1. 정확성: 기술적 세부 정보(파일 경로, 함수 이름, 오류 코드)가 올바른가?
2. 컨텍스트 인식: 응답이 현재 대화 상태를 반영하는가?
3. 아티팩트 추적: 에이전트가 읽거나 수정한 파일을 알고 있는가?
4. 완전성: 응답이 질문의 모든 부분을 다루는가?
5. 연속성: 정보를 다시 가져오지 않고 작업을 계속할 수 있는가?
6. 명령 수행: 응답이 명시된 제약 조건을 존중하는가?

실용적인 지침

대규모 코드베이스를 위한 3단계 압축 워크플로우 적용

컨텍스트 창을 초과하는 코드베이스 또는 에이전트 시스템의 경우 세 가지 순차적 단계를 통해 압축하세요. 각 단계는 다음 단계가 예산 내에서 작동할 수 있도록 컨텍스트를 좁힙니다.

1. 연구 단계: 아키텍처 다이어그램, 문서 및 주요 인터페이스를 탐색하세요. 탐색을 구성 요소, 종속성 및 경계에 대한 구조화된 분석으로 압축합니다. 출력: 원시 탐색을 대체하는 단일 연구 문서.

2. 계획 단계: 연구 문서를 함수 시그니처, 유형 정의 및 데이터 흐름이 포함된 구현 사양으로 변환합니다. 500만 토큰 코드베이스는 이 단계에서 약 2,000단어의 사양으로 압축됩니다.

3. 구현 단계: 사양에 따라 실행합니다. 컨텍스트는 원시 코드베이스 탐색이 아닌 사양과 활성 작업 파일에 집중됩니다. 이 단계는 사양이 이미 간결하기 때문에 추가 압축이 거의 필요하지 않습니다.

예제 아티팩트를 압축 시드로 사용

수동 마이그레이션 예제 또는 참조 PR이 제공되면 처음부터 코드베이스를 탐색하는 대신 템플릿으로 사용하여 대상 패턴을 이해하세요. 예제는 정적 분석이 표면화할 수 없는 제약 조건을 드러냅니다: 유지해야 할 불변성, 변경 시 중단되는 서비스, 그리고 깔끔한 구현이 어떻게 보이는지.

이는 에이전트가 필수 복잡성(비즈니스 요구 사항)과 우발적 복잡성(레거시 해결 방법)을 구분할 수 없을 때 가장 중요합니다. 예제 아티팩트는 이러한 구분을 암시적으로 인코딩하여 시행착오 탐색에 소비될 토큰을 절약합니다.

앵커 기반 반복 요약 단계별 구현

1. 에이전트 도메인(디버깅, 마이그레이션, 기능 개발)에 맞는 명시적 요약 섹션을 정의하세요.
2. 첫 번째 압축 트리거 시 잘린 기록을 해당 섹션으로 요약하세요.
3. 이후 압축 시 새로 잘린 콘텐츠만 요약하세요 — 기존 요약을 다시 요약하지 마세요.
4. 새 정보를 기존 섹션에 병합하고 파일 경로 및 결정 ID별로 중복을 제거하세요.
5. 어떤 정보가 어떤 압축 주기에서 왔는지 태그를 지정하세요 — 요약이 드리프트할 때 디버깅이 가능합니다.

세션 프로필에 맞는 올바른 접근 방식 선택

앵커 기반 반복 요약을 사용할 때:

• 세션이 장기 실행되는 경우 (100개 이상의 메시지)
• 파일 추적이 중요한 경우 (코딩, 디버깅)
• 보존된 정보의 확인이 필요한 경우

불투명 압축을 사용할 때:

• 최대 토큰 절감이 필요한 경우
• 세션이 상대적으로 짧은 경우
• 재조회 비용이 낮은 경우 (예: 파일 시스템 액세스 불필요)

재생성 요약을 사용할 때:

• 사람이 검토하기 위해 요약 해석 가능성이 중요한 경우
• 세션에 명확한 단계 경계가 있는 경우
• 각 압축 트리거 시 전체 컨텍스트 검토가 허용되는 경우

방법별 압축 비율 보정

방법	압축 비율	품질 점수	절충점
앵커 기반 반복	98.6%	3.70	최고 품질, 약간 낮은 압축
재생성	98.7%	3.44	좋은 품질, 중간 압축
불투명	99.3%	3.35	최고 압축, 품질 손실

이러한 수치는 보편적인 상수가 아닌 소스별 벤치마크 수치로 사용하세요 (claim-context-compression-factory-benchmark). 재조회 비용이 존재하는 모든 작업에서 이러한 절충점은 일반적으로 구조화된 접근 방식을 선호합니다.

예제

예제 1: 디버깅 세션 압축

원본 컨텍스트 (89,000 토큰, 178개 메시지):

• /api/auth/login 엔드포인트에서 401 오류
• auth 컨트롤러, 미들웨어, 세션 저장소 추적
• 오래된 Redis 연결 발견
• 연결 풀링 수정, 재시도 로직 추가
• 14개 테스트 통과, 2개 실패

압축 후 구조화된 요약:

## 세션 의도
유효한 자격 증명에도 불구하고 /api/auth/login에서 401 Unauthorized 오류 디버깅.

## 근본 원인
세션 저장소의 오래된 Redis 연결. JWT가 올바르게 생성되었지만 세션을 유지할 수 없음.

## 수정된 파일
- auth.controller.ts: 변경 사항 없음 (읽기 전용)
- middleware/cors.ts: 검사됨 (변경 사항 없음)
- config/redis.ts: 연결 풀링 구성 수정
- services/session.service.ts: 일시적 오류에 대한 재시도 로직 추가
- tests/auth.test.ts: 모의 설정 업데이트

## 테스트 상태
14개 통과, 2개 실패 (모의 설정 문제)

## 다음 단계
1. 나머지 테스트 실패 수정 (모의 세션 서비스)
2. 전체 테스트 스위트 실행
3. 스테이징에 배포

예제 2: 탐침 응답 품질

압축 후 "원래 오류는 무엇이었나요?" 질문:

좋은 응답 (구조화된 요약):

"원래 오류는 /api/auth/login 엔드포인트에서 401 Unauthorized 응답이었습니다. 사용자가 유효한 자격 증명으로 이 오류를 받았습니다. 근본 원인은 세션 저장소의 오래된 Redis 연결이었습니다."

나쁜 응답 (공격적인 압축):

"인증 문제를 디버깅하고 있었습니다. 로그인이 실패했습니다. 몇 가지 구성 문제를 수정했습니다."

구조화된 응답은 엔드포인트, 오류 코드 및 근본 원인을 보존합니다. 공격적인 응답은 모든 기술적 세부 정보를 잃습니다.

지침

1. 요청당 토큰이 아닌 작업당 토큰에 최적화하세요.
2. 파일 추적을 위한 명시적 섹션이 있는 구조화된 요약을 사용하세요.
3. 컨텍스트 사용률 70-80%에서 압축을 트리거하세요.
4. 전체 재생성보다 증분 병합을 구현하세요.
5. 탐침 기반 평가로 압축 품질을 테스트하세요.
6. 파일 추적이 중요한 경우 아티팩트 추적을 별도로 관리하세요.
7. 더 나은 품질 유지를 위해 약간 낮은 압축 비율을 수용하세요.
8. 재조회 빈도를 압축 품질 신호로 모니터링하세요.

주의사항

1. 도구 정의나 스키마를 절대 압축하지 마세요: 함수 호출 스키마, API 사양 또는 도구 정의를 압축하면 에이전트 기능이 완전히 파괴됩니다. 에이전트가 도구를 호출할 수 없습니다.