# 긴 코딩 세션에서 컨텍스트 손실을 방지하려면 어떻게 해야 하나요? > 채팅의 지속적 사실을 간결한 작업 원장, 결정 로그, 테스트 기록, repository checkpoint로 옮겨 컨텍스트 손실을 막으세요. 압축이나 모델 교체 전에 이러한 산출물에서 상태를 다시 불러옵니다. 긴 세션은 갑작스러운 망각보다 점진적인 드리프트로 실패하는 경우가 많습니다. 에이전트는 큰 목표는 기억하지만 작은 제약을 놓치고, 오래된 테스트 결과를 믿고, 조사를 반복하거나 현재 repository와 맞지 않는 계획으로 수정합니다. 해결책은 transcript보다 짧고 신뢰할 수 있는 지속적인 외부 상태입니다. 대화는 작업 기억으로, repository는 진실의 원천으로 취급하세요. 의미 있는 checkpoint마다 무엇이 바뀌었고 무엇이 검증됐으며 무엇이 불확실하고 다음 행동이 무엇인지 기록합니다. ## 네 가지 컨텍스트를 추적하세요 요약이 구분 없는 이야기로 변하지 않도록 사실을 기능별로 나눕니다. | 컨텍스트 유형 | 예시 | 지속 위치 | |---|---|---| | 목표 | 사용자 결과와 수락 기준 | 작업 원장 | | 제약 | 호환성, 안전, 스타일, 범위 | 작업 원장 | | Repository 상태 | 변경 파일과 현재 branch | Version control | | 증거 | 테스트, 로그, screenshot, benchmark | 검증 기록 | 가정은 명확히 표시할 때만 다섯 번째 유형으로 추가하세요. 각 가정에는 확인하거나 반박할 수 있는 가장 저렴한 행동을 적습니다. ## 간결한 작업 원장을 유지하세요 좋은 원장은 한 화면에 들어갑니다. 모든 메시지가 아니라 milestone 뒤에 갱신하세요. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` 정확한 경로, 명령, 실패 이름을 보존하세요. 논의 과정을 일기처럼 적지 마세요. ## 검증된 상태를 중심으로 checkpoint를 만드세요 다음 세션이 재현할 수 있는 결과 뒤에 checkpoint를 만드세요. 통과한 테스트 그룹, 저장된 작은 변경, 확인된 API 응답, fixture로 뒷받침된 설계 결정이 좋은 경계입니다. 모델 교체나 컨텍스트 압축 전에 변경 파일을 기록하세요. 코드를 작성했다는 이유로 기능이 동작한다고 주장하지 말고 테스트, build, 관찰 가능한 artefact와 연결합니다. | 주장 | 필요한 증거 | |---|---| | Parser가 두 호출을 지원 | 두 call ID가 연결된 fixture | | Retry가 안전 | 연결 끊김 상황의 idempotency 테스트 | | Refactor가 동작을 유지 | 기존 및 신규 테스트 모두 통과 | | UI가 올바름 | 목표 크기에서 render 검사 | ## 채팅을 재생하지 말고 현재 source를 가져오세요 세부 사항이 중요하면 현재 파일, 스키마 또는 공식 문서를 다시 여세요. 오래된 transcript는 이미 바뀐 코드를 설명할 수 있습니다. 경로와 검색어를 제공해 에이전트가 최신 상태를 검사하게 하세요. Retrieval은 좁아야 합니다. 전체 repository보다 interface, 구현, 실패 테스트, 관련 로그를 먼저 불러와 추론 공간을 남깁니다. ## 결정과 증거를 보존하며 압축하세요 좋은 압축은 대화 반복을 제거하지만 제약, 되돌리기 어려운 결정, 거절된 대안, 검증은 남깁니다. `verified`, `observed`, `assumed`, `pending`을 구분하세요. 실패한 실험을 최종 설계처럼 요약하지 마세요. 같은 매력적인 접근이 다시 나타날 수 있다면 거절 이유도 보존합니다. ## 도구 출력이 컨텍스트에 들어오기 전에 제한하세요 긴 로그와 생성 파일은 주의를 빠르게 소모합니다. 관련 범위, 개수 또는 일치 행만 요청하세요. 전체 출력은 artefact로 저장하고 짧은 digest와 경로만 돌려줍니다. 테스트 실패에서는 첫 유용한 stack trace, 실패 assertion, 환경 정보만 유지하세요. 반복 frame 수백 개를 모델에 보내지 마세요. ## 결정론적 절차로 재개하세요 일시 중지, 컨텍스트 압축 또는 모델 교체 뒤에는 다음을 수행합니다. * 목표와 제약을 읽습니다. * Version control 상태와 최근 변경을 확인합니다. * 현재 상태 섹션의 파일을 엽니다. * 마지막 관련 검사를 다시 실행합니다. * 기록된 다음 행동이 여전히 유효한지 확인합니다. 이 절차는 오래된 요약이 새 편집을 일으키기 전에 문제를 잡습니다. ## Transcript 기억에 의존하지 않고 모델을 고르세요 Gateway는 모델 교체를 쉽게 하지만 상태는 여전히 사용자의 책임입니다. Atlas Cloud는 하나의 Base URL에서 여러 LLM 프로토콜을 제공합니다. 실행 중인 에이전트를 옮기기 전에 [프로토콜 행렬](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context)과 최신 [모델 카탈로그](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context)를 확인하세요. 교체 모델에 작업 원장, 관련 source file, 새 검증 결과를 제공하세요. 동일한 프로토콜과 동작이 확인되지 않았다면 공급자별 state handle에 의존하지 마세요. ## 결론 지속 상태가 간결하고 증거 기반이며 쉽게 다시 불러올 수 있을 때 긴 코딩 세션이 컨텍스트를 유지합니다. 한 화면 원장을 관리하고 검증된 변경에 checkpoint를 만들며 채팅 대신 현재 source를 읽고 도구 출력을 제한하며 결정론적 재개 절차를 사용하세요. 큰 context window는 도움이 되지만 작업을 복구 가능하게 만드는 것은 규율 있는 외부 상태입니다. ## FAQ ### 더 큰 context window면 긴 코딩 세션에 충분한가요? 아닙니다. 더 큰 공간은 압박을 늦출 뿐, 오래된 제약이 계속 두드러지거나 낡은 관찰이 교정된다고 보장하지 않습니다. ### 코딩 세션 원장에는 무엇을 기록해야 하나요? 목표, 제약, 현재 계획, 변경 파일, 주요 결정, 검증 결과, 미해결 위험, 정확한 다음 행동을 기록하세요. ### 에이전트는 얼마나 자주 checkpoint를 만들어야 하나요? 테스트 통과, 마이그레이션 단계 완료, 설계 결정 또는 계획을 바꾸는 발견처럼 의미 있는 상태 변화 뒤에 만드세요. ### 전체 transcript를 새 모델에 붙여 넣어야 하나요? 대개 그렇지 않습니다. 정리된 checkpoint와 관련 source file, 로그를 제공하고 새 모델이 현재 repository 상태를 검사하게 하세요. ### 요약이 과거의 오류를 보존하지 않게 하려면 어떻게 하나요? 검증된 사실과 가정을 분리하고 명령이나 파일 위치 같은 증거를 연결하며 새 테스트가 반박한 주장은 폐기하세요. ### 중단 후 가장 안전하게 재개하는 방법은 무엇인가요? 작업 원장을 다시 읽고 version control 상태를 확인하며 마지막 관련 검증을 재실행한 뒤 기록된 다음 행동에서 시작하세요.