Context·State·Memory·Checkpoint 구분

모델에게 보여줄 정보, 실행을 진행할 상태, 다음 작업에도 남길 기억, 복구할 스냅샷은 서로 다른 기준으로 관리해야 합니다.

정보의 수명과 책임

보고서를 만드는 에이전트가 중단됐다가 다시 시작한다고 가정합니다. 대화 요약에 "보고서 완성"이 남아 있어도 저장 위치와 전달 여부를 모르면 다음 행동을 정하기 어렵습니다. 반대로 실행 기록을 모두 다음 모델 입력에 넣으면 이미 끝난 작업까지 다시 읽게 됩니다.

이 문제를 나누기 위해 정보의 쓰임을 Context, State, Memory, Checkpoint로 구분합니다. 각각 모델 입력, 실행 상태, 재사용할 기억, 복구용 스냅샷을 뜻합니다. 저장 파일의 형식보다 누가 읽고 언제 갱신하는지가 구분 기준입니다.

이 분류는 설계 책임을 설명하기 위한 기준이며, 모든 프레임워크가 같은 이름을 쓰지는 않습니다. LangGraph 영속화 문서는 대화 단위 상태 저장을 단기 기억이라고 부릅니다. 대화를 넘어 공유하는 장기 기억은 별도 저장소로 구분합니다(2026-09 문서 기준).

Context의 구성과 압축

대규모 언어 모델(Large Language Model, LLM)이 이번 호출에서 직접 받는 입력이 Context입니다. 시스템 지시, 메시지, 도구 설명, 검색 결과 중 실제 요청에 포함한 내용이 여기에 해당합니다. 데이터베이스에 저장해 둔 사실도 입력으로 가져오지 않으면 그 호출에서 모델이 직접 읽을 수 없습니다.

Anthropic의 컨텍스트 엔지니어링 글은 필요한 입력을 선별하고, 긴 대화를 압축하는 방법을 설명합니다. 압축은 중복을 줄이지만 나중에 필요한 조건까지 지울 수 있습니다. 요약의 길이뿐 아니라 남겨야 할 정보가 보존됐는지 확인해야 합니다.

보고서 작업에서는 채택한 근거와 출처 식별자, 아직 해결하지 못한 반론, 최종 제출 조건을 남기는 식으로 적용할 수 있습니다. 이미 반영한 검색 결과의 전문은 필요할 때 다시 읽을 수 있도록 원문 위치를 유지합니다. 요약문만 남겨 원문과의 연결을 끊으면 잘못 요약된 사실을 확인하기 어렵습니다.

Context를 압축했다고 저장된 State까지 자동으로 줄어드는 것은 아닙니다. 모델 입력을 만드는 코드가 State에서 필요한 필드를 선택할 수도 있고, 별도 요약을 사용할 수도 있습니다. 어떤 정보를 입력에서 제외할지는 애플리케이션이 정해야 합니다.

State의 갱신과 실행 사실

State는 작업을 어디까지 진행했는지 판단할 구조화 데이터입니다. 현재 단계, 완료된 작업, 산출물 식별자, 남은 예산처럼 실행을 제어할 값을 보관합니다. 대화 전체를 저장하더라도 이 값들을 별도로 두면 다음 단계의 조건을 명시하기 쉽습니다.

예를 들어 보고서가 "검토 대기"에서 "전달 완료"로 바뀌려면 실제 전달 결과가 필요합니다. 모델이 완료를 선언한 문장만으로 상태를 전환하면 도구 실행 실패를 놓칠 수 있습니다. 이 글에서는 모델이 변경을 제안하고 실행 코드가 결과와 조건을 확인한 뒤 State에 반영하는 방식을 권합니다.

State는 외부 시스템의 현재 상태와도 구분해야 합니다. 실행 기록에 파일이 저장됐다고 남아 있어도 다른 사용자가 이후 그 파일을 삭제했을 수 있습니다. 재사용할 때 필요한 외부 사실은 다시 조회해야 하며, 저장된 기록만으로 현재의 존재나 권한을 보장할 수 없습니다.

Memory의 기록 정책

이 글에서 Memory는 다음 작업에도 재사용할 장기 기억을 뜻합니다. 사용자의 출력 형식 선호나 반복 업무의 확인된 규칙처럼 실행 하나를 넘어 유효한 정보가 대상입니다. 실패한 검색 결과나 임시 가설을 같은 수준의 사실로 저장하면 이후 판단도 그 오류를 물려받습니다.

기록 시점도 설계 대상입니다. LangChain의 기억 개요는 실행 중 바로 기록하는 방식과 별도 작업으로 기록하는 방식을 구분합니다. 전자는 다음 판단에 곧바로 쓸 수 있지만 응답 경로에 작업이 추가되고, 후자는 반영되기 전까지 최신 기억을 읽지 못할 수 있습니다.

보고서 선호를 저장한다면 값과 함께 출처, 적용 범위, 확인 시점을 관리하는 편이 좋습니다. "짧은 형식"이 이번 요청에만 적용되는지 이후 보고서에도 적용되는지부터 구분합니다. 보존 권한과 유효기간, 상충하는 요청을 처리할 기준은 저장 전에 정합니다.

Memory를 파일에 적거나 검색 인덱스에 넣는 것만으로 다음 Context에 자동 반영되지는 않습니다. 애플리케이션이 관련 기억을 읽고 현재 작업에 적용 가능한지 판단한 뒤 입력에 포함해야 합니다. 검색 점수가 높은 기억도 현재 요청과 충돌하면 그대로 적용해서는 안 됩니다.

Checkpoint의 복구 범위

Checkpoint는 특정 시점의 State와 실행 재개에 필요한 정보를 저장한 스냅샷입니다. 어떤 단계에서 이어갈지 복원하기 위한 기록이며, 과거의 대화 요약과는 목적이 다릅니다. 복구가 필요하다면 저장 시점과 저장 매체, 재개 가능한 경계를 함께 정해야 합니다.

LangGraph 영속화 문서에 따르면 메모리에만 둔 체크포인트는 프로세스가 종료되면 사라집니다. 프로세스 장애를 넘겨 복구하려면 영속 저장소가 필요합니다.

Checkpoint가 외부 작업까지 되돌려 주지는 않습니다. 보고서 전달은 성공했지만 완료 상태 저장 전에 프로세스가 중단되는 경우를 생각할 수 있습니다. 이전 Checkpoint에서 재개하면 전달 단계가 다시 실행될 가능성이 있습니다.

이 경우를 위한 운영 설계는 외부 작업 식별자를 보관하고, 재개 전에 처리 여부를 확인하는 것입니다. 같은 요청을 반복해도 결과가 중복되지 않게 하는 멱등성도 함께 검토합니다. 멱등성 키가 효과를 내려면 실제 전달을 처리하는 시스템이 그 키의 중복을 판별해야 합니다.

저장과 재개의 설계 기준

복구 테스트는 저장한 데이터를 읽는 데서 끝나지 않습니다. 중단 지점에서 다음 행동을 정할 수 있는지, 외부 작업을 중복 실행하지 않는지 확인해야 합니다. 보고서 예시라면 전달 직전과 전달 직후에 각각 중단된 상황을 구분해 점검할 수 있습니다.

이 기준이 각각 다른 데이터베이스를 요구하는 것은 아닙니다. 같은 저장소를 쓰더라도 갱신 주체와 보존 기간, 읽기 경로를 구분할 수 있습니다. 구현은 작게 시작하되, 대화 요약 하나에 모든 책임을 맡기지 않는 편이 좋습니다.

정리

Context는 현재 판단에 필요한 입력이고, State는 실행을 진행하기 위한 상태입니다. Memory에는 이후 작업에 재사용할 정보와 그 적용 조건을 남깁니다. Checkpoint는 실행을 복원할 기준점이지만 외부 시스템의 변경까지 되돌리지는 않습니다. 각 정보의 수명과 갱신 책임을 구분해야 입력을 줄이면서도 작업을 이어가고 중복 실행을 막을 수 있습니다.