대화를 기억하는 것만으로 충분할까요?
에이전트가 여러 파일을 수정하는 중에 대화가 길어졌다고 해 볼게요. 앞부분에는 “결제 코드는 건드리지 않는다”는 제약이 있었고, 중간에는 특정 오류의 원인을 이미 확인했어요. 작업을 다시 이어가는 시점에 두 내용이 빠지면 수정 범위가 넓어지거나 같은 조사를 반복할 수 있어요.
긴 대화를 줄이는 압축(compaction)은 이후 판단에 사용할 내용을 요약하는 과정이에요. 중요한 것은 원래 문장을 얼마나 많이 남겼는가보다, 다음 행동을 결정하는 데 필요한 상태가 남았는가예요. 재개할 때마다 원래 대화를 전부 읽는 방법은 비용이 커지고, 요약만 믿는 방법은 빠진 제약을 알아채기 어려워요.
AGS의 context-continuity 스킬은 이 문제를 체크포인트로 다뤄요. 전체 대화를 보관하기보다 잃었을 때 실제 행동이 달라지는 정보를 골라 저장해요.
무엇을 남겨야 다시 시작할 수 있을까요?
저장 기준은 구체적이에요. 작업 범위와 권한, 완료 기준, 이미 끝낸 작업, 실패한 시도, 다음 구현을 바꿀 결정, 근거의 위치와 아직 해결하지 못한 문제가 대상이에요. 원시 로그나 긴 코드, 대화 전문을 그대로 넣는 용도는 아니에요.
예를 들어 다음 두 메모를 비교해 볼 수 있어요.
| 메모 | 재개할 때 알 수 있는 내용 |
|---|---|
| 로그인 오류를 조사했고 수정 중이에요 | 작업의 주제는 알 수 있지만 어디서 이어야 할지 모호해요 |
| 요청 검증을 수정했어요. 결제 파일은 제외해요. 특정 입력 테스트가 실패했고 실패 로그는 별도 파일에 있어요. 다음에는 해당 분기를 확인해요 | 완료한 부분, 수정 범위, 남은 실패와 근거의 위치를 구분할 수 있어요 |
두 번째 메모도 그대로 실행할 지시문으로 보관하면 안 돼요. 저장 이후 사용자가 범위를 바꿨을 수 있기 때문이에요. AGS 문서는 nextActions를 권한 있는 명령이 아니라 과거 시점에 고려한 다음 행동으로 쓰도록 정해요.
이 구분은 재개할 때 특히 중요해요. “다음은 배포”라는 메모를 읽었다고 현재 사용자에게 배포 승인을 받은 것이 되지는 않아요. 현재 요청과 적용 지침을 확인한 뒤 그 행동을 다시 선택해야 해요.
부분 추가 대신 전체 스냅샷을 교체하기
AGS의 직접 작업용 체크포인트는 checkpoint_context에 전체 스냅샷을 보내는 방식이에요. 이전 기록에 일부 필드가 자동으로 덧붙는다고 가정하지 않아요. 현재 작업을 재개하는 데 필요한 내용으로 다시 정리해 보내요.
아래는 공개 문서의 규칙을 설명하는 의사코드예요. 실제 API의 전체 요청 형식이나 실행 가능한 예제는 아니에요.
첫 저장: expectedRevision = 0
다음 저장: expectedRevision = 직전 저장에서 확인한 revision
응답을 못 받아 같은 저장을 재시도:
같은 requestId + 같은 입력
내용을 바꿔 새로 저장:
새로운 requestId + 전체 replacement snapshotrevision은 과거 상태를 기준으로 새 내용을 덮어쓰는 충돌을 알아내는 데 쓰여요. 응답이 유실됐다고 다른 식별자를 붙여 무조건 다시 저장하면 첫 요청이 반영됐는지와 별개로 새 변경을 만들 수 있어요. 그래서 같은 요청의 재시도와 내용이 달라진 새 요청을 구분해요.
이 방식에는 작성 비용도 있어요. 전체 교체이므로 계속 필요한 제약을 새 스냅샷에서 빠뜨리지 않아야 해요. 서버가 revision을 검사해도 사람이 읽어야 할 중요한 조건의 누락까지 자동으로 판단해 주지는 않아요. 무엇을 남길지는 스킬의 판단 영역이고 서버는 저장·복원 조건을 관리해요.
복원 후보를 받았다고 본문을 바로 믿지 않기
AGS의 직접 작업에서는 재개나 압축 뒤에 훅이 복원 후보의 메타데이터를 제공해요. 훅은 특정 실행 시점에 동작하는 연결 코드예요. 이 카드에는 저장된 본문이 없고 DEFER 메타데이터만 있어요.
에이전트는 현재 요청과 작업 식별 정보, epoch, revision, digest가 맞는지 확인한 뒤 load_context를 호출해요. epoch는 작업 상태를 구분하는 세대 정보이고, digest는 내용이 같은지 확인할 때 사용하는 요약값이에요. 이전에 본 후보가 지금도 유효하다고 가정하지 않고 복원 시점에 다시 확인하는 절차예요.
본문을 불러온 뒤에도 최신 사용자 요청이 우선해요. 이 단계가 빠지면 오래된 메모가 현재 요청보다 강한 지시처럼 작동할 수 있어요. 저장에 성공했는지와 현재 사용할 수 있는 정보인지는 별개의 판단이에요.
이미 있는 실행 기록과 중복시키지 않기
AGS는 직접 작업과 오케스트레이션으로 관리하는 작업을 구분해요. 직접 작업에는 별도 체크포인트를 쓰지만, 오케스트레이션 작업에서는 TaskEnvelope, WorkflowReceipt, convergence root를 기준으로 삼아요. 후자는 재시도와 수렴을 추적하는 기록이에요.
이미 실행 단계와 결과를 관리하는 기록이 있는데 또 다른 요약을 기준 원본으로 만들면 두 자료가 어긋날 수 있어요. 한쪽은 테스트 성공, 다른 쪽은 테스트 대기라고 적혀 있다면 재개하는 에이전트가 무엇을 따라야 할지 불분명해져요. AGS가 두 경로를 나누는 설계는 이런 중복을 줄이려는 선택으로 읽을 수 있어요.
저장한다고 모든 문제가 해결되지는 않아요
직접 작업 스냅샷은 로컬 SQLite에 평문 JSON으로 저장되고 자동 만료되지 않아요. 따라서 비밀이나 개인정보, 원시 로그를 넣지 않는 기준이 중요해요. 자동 복원 후보 표시를 중단하는 것과 저장된 본문을 삭제하는 것도 별도 기능이에요.
연속성 기능을 사용할 수 없다고 작업이나 압축 자체를 막지는 않아요. 그 경우 저장하지 못한 상태를 나중에 복원할 수 있다고 가정해서는 안 돼요. 이 글에서는 공개 스킬의 저장·복원 규칙을 확인했으며, 모든 호스트의 압축 시점을 실험해 동일한 복원 결과를 확인한 것은 아니에요.
적용할 때는 정상 저장만 확인하는 것으로 부족해요. 같은 요청의 재전송, 오래된 revision으로 저장, 후보 제공 후 상태 변경, 사용자의 범위 변경을 나눠 확인해야 해요. 특히 마지막 경우는 형식 검증만으로 해결되지 않아요. 복원한 다음 행동이 지금도 허용되는지 에이전트가 다시 판단해야 해요.
다음 글과 소스
다음 글은 같은 실패를 반복하는 AI의 재시도 제어예요. 실패 사실을 저장하는 것에서 한 걸음 더 나아가, 어떤 변화가 있어야 다시 시도할 가치가 있는지 살펴봐요.