컨텍스트 관리

대부분의 모델은 표준 200K 컨텍스트 창을 사용합니다.

• Claude 4.5 Sonnet - 복잡한 작업에 균형 잡힌 모델
• Claude 4.5 Haiku - 빠르고 효율적
• GPT-5 - 추론에 뛰어남(Beta)
• GPT-5-Codex - 코딩에 최적화됨(Beta)

용량:

• 총 메모리 용량 약 200,000 토큰
• 대부분의 개발 작업과 중간 규모 프로젝트에 충분함

포함되는 항목:

• 대화의 모든 메시지
• 컨텍스트에 로드된 파일 내용
• 도구 출력과 응답
• 시스템 프롬프트와 지침
• MCP 서버 정의

성능:

• 한계에 가까워질수록 성능이 크게 저하됨
• 컨텍스트 과부하 징후를 확인하세요(느린 응답, 정확도가 낮은 출력)
• 최적의 성능을 위해 컨텍스트를 더 자주 재설정하세요

Claude Sonnet 4.5는 명시적으로 선택했거나 입력이 200K 토큰을 초과할 때 확장 컨텍스트(1M 토큰)를 제공합니다.

용량:

• 총 메모리 1,000,000 토큰
• 표준 모델보다 5배 큼

장점:

• 큰 코드베이스 전체를 청크로 나누지 않고 로드하기에 적합함
• 대규모 프로젝트에서 컨텍스트 관리 부담을 대부분 줄임
• 컨텍스트 한계에 도달하기 전까지 더 오래 작업 가능
• 세션 재설정 필요 횟수가 줄어듦

사용 시점:

• 1000+개의 파일이 있는 큰 코드베이스
• 전체 프로젝트에 걸친 복잡한 다중 파일 리팩터링
• 여러 관련 작업으로 이어지는 긴 개발 세션
• 컨텍스트 관리 부담을 최소화하고 싶을 때

징후:

• 응답의 정확도가 낮아지거나 불완전함
• 대화 앞부분의 중요한 세부 정보를 놓침
• 긴 세션에서 일관성을 유지하기 어려움
• 최근 변경 사항이나 컨텍스트를 혼동함

구체적인 예:

• 세션 초반에 이미 거절한 해결책을 다시 제안함
• 20 메시지 전에 정한 코딩 규칙을 무시함
• 대화 앞부분에서 만든 변경 사항과 충돌하는 코드를 생성함
• 이전에 논의한 프로젝트 아키텍처와 맞지 않는 구현을 제안함

주요 신호: Verdent의 응답이 덜 정확해지거나 일관성이 없어짐

징후:

• 응답 시간이 눈에 띄게 느려짐
• 응답이 시작되기 전 처리 지연이 길어짐
• 메시지 사이의 지연 시간이 늘어남

구체적인 예:

• 평소 5-10초 걸리던 응답이 이제 30+초 걸림
• 메시지를 보낸 뒤 입력 표시기가 나타나기까지 눈에 띄는 지연이 있음
• 스트리밍 응답이 평소보다 훨씬 늦게 시작됨
• 도구 실행(파일 읽기, 검색)이 눈에 띄게 오래 걸림

주요 신호: 응답이 평소보다 훨씬 오래 걸림

징후:

• 이미 제공한 정보를 다시 확인해 달라고 요청함
• 앞서 정한 패턴이나 규칙을 잊어버림
• 이전에 논의한 파일이나 코드를 참조하지 못함
• 프로젝트 구조에 대해 중복 질문을 함

구체적인 예:

• 30 메시지 전에 React를 사용한다고 명시했는데도 "어떤 프레임워크를 사용하나요?"라고 물음
• 이미 여러 번 @-mentioned한 파일 경로를 다시 요청함
• 세션 시작 시 정한 네이밍 규칙을 기억하지 못함
• 이유를 들어 이미 거절한 개념이나 접근 방식을 다시 설명함

주요 신호: Verdent가 이미 논의한 내용을 다시 물어봄

징후:

• 200K 토큰 한계의 마지막 5분의 1에 가까워짐(약 160K+ 토큰 사용)
• 파일 읽기와 도구 출력이 많은 긴 대화
• 무거운 도구 정의가 있는 여러 MCP 서버가 활성화됨
• 큰 파일이 컨텍스트에 반복적으로 로드됨

구체적인 예:

• 세션이 2+시간 동안 100+개의 메시지로 진행됨
• 대화 중 @-mentions가 포함된 20+개 파일을 로드함
• 큰 파일 여러 개(각 >1000줄)가 컨텍스트에 있음
• 방대한 도구 정의가 있는 MCP 서버 5+개가 활성화되어 있음
• 대화에 grep/search 결과와 파일 읽기가 많이 포함됨

주요 신호: 파일과 도구를 광범위하게 사용한 매우 긴 세션

• 응답 시간이 눈에 띄게 느려짐
• 응답의 정확도가 낮아지거나 일관성이 없어짐
• Verdent가 이전 컨텍스트나 패턴을 잊어버림
• 컨텍스트 창 한계에 가까워짐(성능 저하 징후를 확인하세요)

조치: 품질이 저하되면 새 세션을 시작합니다

• 서로 관련 없는 기능이나 모듈 사이를 전환함
• 하나의 todo를 완료하고 다음으로 이동함
• 메모리를 많이 쓰는 작업 이후(대규모 리팩터링, 아키텍처 작업)
• 조사 단계에서 구현 단계로 이동함

조치: 새로운 주요 작업에는 새 세션을 사용합니다

• 완료한 기능을 버전 관리에 커밋한 후
• 개발 워크플로의 논리적 체크포인트 사이
• 테스트-검증-커밋 사이클 이후

조치: 커밋 → 테스트 → 새 세션

• 주요 새 기능을 시작하기 전
• 대화 기록이 매우 길어졌을 때
• 다중 파일 변경을 완료한 후
• 서로 다른 작업 유형 사이(디버깅 → 기능 개발)

조치: 컨텍스트가 저하되기 전에 선제적으로 새로 시작합니다

작고 집중된 파일:

• 큰 파일 몇 개보다 작은 파일 여러 개가 컨텍스트를 더 효율적으로 사용함
• 관련 모듈만 로드하기 쉬움
• 컨텍스트에 포함되는 내용을 더 세밀하게 제어할 수 있음
• 큰 파일 전체를 로드할 필요가 줄어듦

명확한 디렉터리 구조:

• 논리적인 구성이 Verdent가 관련 파일을 찾는 데 도움이 됨
• 기능 기반 또는 모듈 기반 구성이 컨텍스트 대상을 더 잘 좁혀줌
• 관련 없는 코드를 로드할 필요가 줄어듦

Documentation in AGENTS.md:

• 프로젝트 문서가 많은 예제 파일을 로드할 필요를 대체함
• 아키텍처 패턴을 한 번 설명하고 반복해서 참조함
• 코딩 표준을 중앙에서 문서화함
• 탐색적 파일 읽기로 인한 컨텍스트 부담을 줄임

장점:

• 코드베이스 전체를 로드하지 않고 격리된 모듈에서 작업 가능
• 명확한 경계가 집중된 세션을 가능하게 함
• 모듈 경계를 따라 작업을 청크로 나누는 것이 자연스러워짐

문제:

• 모놀리식 파일은 큰 컨텍스트 전체를 로드하게 만듦
• 구조가 불명확하면 아키텍처를 이해하기 위해 많은 파일을 로드해야 함
• 같은 파일에 여러 관심사가 섞이면 관련 없는 코드에 컨텍스트가 낭비됨

영향:

• 컨텍스트 한계 문제가 자주 발생함
• 관련 없는 코드에 토큰이 낭비됨
• 작업을 특정 모듈로 격리하기 어려움
• 세션 재설정이 더 자주 필요함

흔한 안티 패턴:

• 여러 관심사가 섞인 단일 5000+줄 파일
• 루트에 100+개 파일이 있는 평면 디렉터리 구조
• 기능/모듈 간 명확한 분리가 없음
• 중앙화된 문서가 부족함

리팩터링 접근 방식:

• 큰 파일을 작고 집중된 모듈로 나눔
• 파일 유형이 아니라 기능이나 도메인별로 구성함
• 명확한 디렉터리 계층을 만듦
• 공유 코드를 별도 모듈로 추출함

문서화:

• 아키텍처 패턴을 담은 AGENTS.md를 만듦
• 코딩 표준을 중앙에서 문서화함
• 모듈별 README 파일을 유지함
• 설계 결정을 문서로 남김

컨텍스트 영향: 표준 200K 토큰 컨텍스트에서는 정리된 워크스페이스가 한계에 자주 도달하는지 드물게 도달하는지를 가릅니다. 1M 토큰 컨텍스트에서는 구성이 덜 중요하지만 여전히 효율성을 높입니다.

성능 징후 확인:

• 세션 전반에서 응답 품질과 속도를 모니터링합니다
• 응답이 느려지거나 정확도가 낮아지는 시점을 알아차립니다
• 대화 길이와 파일 수를 수동으로 추적합니다
• 새 세션 시작을 선제적으로 고려합니다

모니터링할 항목:

• 응답 정확도와 일관성
• 첫 응답까지 걸리는 시간(입력 표시기 지연)
• 전체 응답 완료 시간
• 이전 대화 세부 정보에 대한 기억

서브에이전트 관리:

• 필요하지 않을 때 사용하지 않는 커스텀 서브에이전트를 비활성화합니다
• 활성화된 각 서브에이전트는 시스템 오버헤드에 정의를 추가합니다
• 실제로 사용하는 서브에이전트만 활성화 상태로 둡니다
• 특정 작업에 필요할 때 다시 활성화합니다

조치 기준: 2-3개의 성능 저하 신호가 보이면 새 세션을 시작할 때입니다.

청크 나누기 접근 방식:

• 큰 작업을 더 작은 단위로 나눕니다
• 관련 작업을 집중된 세션에서 완료합니다
• 긴 대화에서 서로 다른 작업 유형을 섞지 않습니다
• 메모리를 많이 쓰는 작업에는 컨텍스트 창의 마지막 5분의 1을 피합니다

세션 관리:

• 주요 작업 사이에는 새 세션을 시작합니다
• 커밋 후 컨텍스트를 지웁니다: 테스트 → 검증 → 커밋 → 새 세션
• 여러 단계 계획에는 todo를 사용합니다
• todo 항목을 별도의 집중된 세션에서 처리합니다

모범 사례 패턴:

1. Plan Mode에서 작업을 계획합니다
2. 새 세션에서 집중적으로 구현합니다
3. 변경 사항을 테스트하고 검증합니다
4. 버전 관리에 커밋합니다
5. 다음 작업을 위해 새 세션을 시작합니다

작업 격리: 디버깅은 기능 개발과 분리하고, 조사는 구현과 분리하세요.

전략적 포함:

• 명시적 파일 포함이 필요할 때만 @-mentions를 사용합니다
• 많은 파일을 로드하는 대신 AGENTS.md 문서를 활용합니다
• 큰 프로젝트에서는 한 번에 하나의 모듈만 작업합니다
• 큰 파일을 더 작고 집중된 컴포넌트로 나눕니다

파일 선택 원칙:

• 수정하거나 직접 참조해야 하는 파일만 포함합니다
• 예제 파일 로드보다 문서를 선호합니다
• 더 이상 필요하지 않은 파일은 컨텍스트에서 제거합니다
• 파일은 미리 로드하지 말고 필요할 때 로드합니다

큰 파일 처리:

• 500줄을 넘는 파일은 분할을 고려합니다
• 유틸리티와 헬퍼를 별도 파일로 추출합니다
• 명확한 모듈 경계를 사용합니다
• 파일 간 관계를 AGENTS.md에 문서화합니다

최적화 워크플로:

성능 모니터링 → 세션 비대화 식별 → 사용하지 않는 서브에이전트 비활성화 → 새 세션을 선제적으로 시작 → 작업 품질에 집중

일상적인 실천:

• 주요 기능마다 새 컨텍스트로 시작합니다
• 자주 커밋하고 커밋 사이에 재설정합니다
• 세션을 하나의 목표에 집중시킵니다
• 자연스러운 중단 지점에서 컨텍스트 사용량을 검토합니다

For Extended Context (1M tokens): Claude Sonnet 4.5의 더 큰 컨텍스트 창에서는 최적화의 중요도가 낮아집니다. 공격적인 컨텍스트 관리보다 작업 품질에 집중하세요. 그래도 좋은 관행은 여전히 효율성과 구성을 개선합니다.