에이전트를 오래 돌릴 때, 무엇을 남겨야 할까

에이전트에게 오래 걸리는 일을 맡길 때는 흔히 시간을 먼저 말한다. “자기 전까지 계속 조사해 줘”, “몇 시간 동안 가능한 만큼 진행해 줘” 같은 식이다. 오래 일하면 결과도 많이 나올 것 같지만, 시간은 운영 조건일 뿐 완료 조건은 아니다. 세 시간 뒤 작업이 멈췄을 때 어디까지 끝났는지 알 수 없다면, 오래 실행된 기록은 큰 도움이 되지 않는다.

그렇다고 긴 작업마다 복잡한 관리 시스템을 붙일 필요는 없다. 읽기만 하고 처음부터 다시 돌리기도 쉽다면 그냥 재시작하는 편이 낫다. 반대로 몇 초 만에 끝나더라도 결제·삭제·게시처럼 같은 행동이 두 번 일어나면 곤란한 작업에는 더 강한 통제가 필요하다.

따라서 실행 시간을 보기보다 실패했을 때 무엇을 잃는지를 먼저 봐야 한다. 다시 돌려도 되면 재시작한다. 그러기 어렵다면 확정된 결과와 현재 권한, 다음 안전 행동을 남긴다.

오래 버티는 것과 다시 일어나는 것은 다르다

오래 실행된다는 것과 실패한 뒤 이어서 할 수 있다는 것은 다르다. Temporal 문서도 시간 제한 없이 실행되는 성질과, 실패 뒤 상태를 복원하는 성질을 따로 설명한다. 특정 제품에서 쓰는 구분이지만 긴 작업을 이해하는 데 도움이 된다. Workflow Execution

긴 작업은 여러 이유로 끊긴다. 네트워크가 바뀌고, 사용자가 자리를 비우고, 입력을 기다리거나 도구가 실패한다. 다른 에이전트가 일을 넘겨받을 수도 있다. 이때 연결을 끝까지 붙잡는 것보다, 다음 질문에 답할 수 있는 기록을 남기는 일이 중요하다.

어떤 작업의 어느 실행인가.
무엇까지 확정됐는가.
이미 일어난 외부 변화는 무엇인가.
지금 누가 같은 대상을 바꿀 수 있는가.
중단한 뒤 어디서부터 다시 시작해야 하는가.

압축은 대화를 이어 주지만 작업 기록은 아니다

에이전트가 계속 움직인다고 앞선 대화가 그대로 남아 있는 것은 아니다. 대화가 길어지면 제품은 오래된 내용을 지우거나 요약해 다음 추론에 넘길 수 있다. 여기서 말하는 컨텍스트 압축은 일반적인 무손실 데이터 압축처럼 원문을 되살리는 방식은 아니다. 다음 작업에 필요하다고 판단한 문맥만 골라 짧게 줄인다. 잘 작동하면 중복된 도구 출력과 지나간 대화를 덜어 낼 수 있지만, 나중에 중요해질 세부사항까지 반드시 남는다고 볼 수는 없다.

공개 문서를 보면 남기는 방식도 제품마다 다르다.

OpenAI Responses API와 Codex: 이전 상태와 추론의 핵심을 더 적은 토큰으로 넘기는 암호화된 압축 항목을 사용한다. 일부 이전 항목이 함께 남을 수도 있지만, 압축 항목 자체는 사람이 읽고 항목별 보존 여부를 확인할 수 없다. OpenAI Compaction, Unrolling the Codex agent loop
Anthropic Messages API: 앞선 대화를 요약한 compaction 블록을 만들고, 다음 요청에서는 그 앞의 내용을 제외한다. 기본 지침은 현재 상태와 다음 단계, 배운 내용처럼 작업을 이어 가는 데 필요한 정보를 요약하도록 하지만 모델마다 다르며 사용자가 바꿀 수도 있다. Anthropic Compaction
코드 실행이 켜진 Claude 일반 채팅: 한계에 가까워지면 이전 메시지를 요약하되 전체 채팅 기록은 보존한다고 안내한다. 어느 세부사항을 고르는지까지 공개하지는 않는다. Claude usage and length limits
Claude Code: 오래된 도구 출력을 먼저 비운 뒤 대화를 요약한다. 프로젝트 루트의 CLAUDE.md와 자동 메모리는 디스크에서 다시 넣지만, 경로별 규칙과 하위 폴더의 CLAUDE.md는 관련 파일을 다시 읽기 전까지 빠질 수 있다. 초기 대화에서만 준 세부 지침도 잃을 수 있다고 문서에 적혀 있다. Explore the context window, How Claude Code works

일반 ChatGPT 채팅이 자동으로 압축될 때 무엇을 남기는지는 공식 문서에서 찾지 못했다. 기능이 없다는 뜻은 아니다. Codex나 Responses API의 설명을 일반 채팅에 그대로 적용할 근거가 없다는 뜻이다.

따라서 압축 결과는 작업을 이어 주는 문맥이지, 완료나 승인을 판정하는 기록이 아니다. 확정한 산출물의 버전, 바꾸지 않을 결정과 이유, 이미 일어난 외부 변화, 남은 승인, 다음 확인 방법은 사람이 읽고 다시 확인할 수 있는 곳에 따로 남겨야 한다. 압축 뒤 게시·전송·삭제 같은 행동을 재개할 때도 요약만 믿지 말고 실제 저장소나 API의 현재 상태부터 확인한다.

별도로 남길 체크포인트가 대화 전체를 복사한 파일일 필요도 없다. 다음 사람이 원문 대화를 모두 읽지 않고도 다음 행동을 고를 수 있으면 된다. 채택된 산출물, 아직 끝나지 않은 항목, 이미 일어난 외부 효과, 필요한 승인, 다음 검증 방법 정도가 핵심이다.

네 가지 방식 중 가장 합리적인 것을 고른다

긴 작업을 운영하는 방식은 대략 네 가지로 나눠 볼 수 있다. 이것은 성숙도 점수가 아니라 비용에 맞는 선택표다.

방식	알맞은 작업	남겨야 할 것
전체 재시작	읽기 전용이고 다시 돌리기 쉬움	입력, 버전, 재현 방법
산출물 체크포인트	탐색·작성 비용이 크고 자연스러운 중간 결과가 있음	채택된 결과, 남은 일, 다음 단계
관리형 실행	반복·예약·재시도가 필요하고 기존 플랫폼을 쓸 수 있음	실행 ID, 플랫폼 상태, 재시도 정책, 대상 작업의 중복 방지
명시적 제어	여러 실행자가 같은 상태를 바꾸거나 비가역 효과·중간 승인이 있음	현재 변경 권한, 만료·인계 규칙, 안전한 재개점, 취소 경계

처음부터 가장 무거운 방식을 고를 필요는 없다. 다음 질문에 하나라도 “그렇다”고 답할 때만 한 단계 더 강한 통제를 검토하면 된다.

실패하면 이미 한 작업을 비싸게 다시 해야 하는가.
같은 명령이 두 번 실행되면 피해가 생기는가.
여러 실행자가 같은 파일이나 외부 상태를 바꿀 수 있는가.
중간에 사람의 새 판단이나 승인이 필요한가.
정해진 시각을 놓치면 실질적인 손해가 있는가.

오래 걸리지만 순수 계산만 하는 작업은 재시작형일 수 있다. 조사·작성처럼 외부 변화가 적은 작업도 압축 뒤 다시 찾는 비용이 크다면 산출물 체크포인트가 합리적이다. 반대로 짧은 게시 작업은 중복 공개나 잘못된 버전 배포를 막아야 하므로 관리형 실행이나 명시적 제어가 필요할 수 있다.

살아 있음, 진전, 완료를 섞지 않는다

장기 작업 화면에서 가장 오해하기 쉬운 것은 “실행 중”이라는 표시다. 표시가 새로 갱신됐다고 유용한 일이 진행됐다는 뜻은 아니다. 파일 하나가 생겼다고 완료된 것도 아니다. 다음 세 신호를 나눠야 한다.

생존 신호: 실행자나 작업자가 최근까지 응답했는가.
진전 기록: 어떤 단계나 산출물이 새로 확정됐는가.
완료 기록: 사용자가 받을 결과와 완료 여부를 판정할 기록이 있는가.

한시적 변경 권한인 lease는 현재 누가 언제까지 대상을 바꿀 수 있는지 정한다. 생존 신호인 heartbeat는 그 실행자가 최근까지 응답했음을 알린다. 둘 다 작업의 정확성이나 완료를 증명하지는 않는다. Kubernetes도 Lease 객체를 노드 생존 신호와 리더 선출에 사용하지만, 그것이 노드에서 수행한 업무의 품질을 말해 주는 것은 아니다. Kubernetes Leases

생존 신호가 필요하다면 “살아 있음”만 알리지 말고, 마지막으로 확정한 작업 단위도 함께 남기는 편이 낫다. 그래도 그 기록이 실제 외부 변화와 어긋날 수 있으므로 완료 기록으로 삼아서는 안 된다. 상세 로그를 계속 쌓는 일도 기본값이 될 수 없다. Google SRE는 쓰지 않는 관측 신호가 시스템 자원과 사람의 주의를 함께 소모한다고 지적한다. Monitoring Distributed Systems

다시 실행해도 같은 일이 두 번 생기지 않게 한다

체크포인트가 있다고 안전하게 재개되는 것은 아니다. 예를 들어 게시 요청은 성공했지만, 완료 기록을 남기기 전에 실행이 끊길 수 있다. 다음 실행이 기록만 보고 게시를 다시 시도하면 같은 효과가 두 번 생긴다.

“한 번만 보냈다”고 믿는 것만으로는 이 문제를 막을 수 없다. 실제 변화를 남기는 시스템이 같은 작업을 알아보고 중복 실행을 걸러야 한다. RFC 9110도 통신이 끊긴 뒤 요청을 자동으로 다시 보내려면 그 요청이 멱등적이라는 사실을 알아야 한다고 설명한다. HTTP 메서드 표준이 에이전트 작업 전체를 안전하게 만들어 주는 것은 아니지만, 재시도의 기본 원칙은 잘 보여 준다. RFC 9110 §9.2.2

실무에서는 작업과 중요한 외부 명령에 안정적인 식별자를 둔다. 같은 요청을 다시 받았을 때 이미 끝난 효과인지, 아직 시작하지 않은 일인지, 결과가 불확실한지를 구분한다. 결과가 불확실하면 자동으로 반복하기보다 사람이 확인하게 한다.

취소도 마찬가지다. 취소 버튼을 눌렀다고 이미 일어난 변화가 되돌아가지는 않는다. “취소 요청을 받음”, “실행이 멈춤”, “이미 생긴 외부 효과를 정리함”은 별도 상태다. Microsoft Durable Task와 AWS Step Functions 문서도 종료·중단 요청 뒤 실제 상태를 다시 조회하거나, 외부 작업의 취소가 최선 노력에 그칠 수 있음을 밝힌다. Durable Task instance management, Step Functions integration patterns

인계에는 대화보다 다음 행동이 필요하다

에이전트나 장치가 바뀌거나 같은 대화가 압축된 뒤 이어질 때도, 요약만으로는 안전하게 계속하기 어렵다. 어느 실행을 이어야 하는지, 어떤 결과가 확정됐는지, 이전 실행의 변경 권한이 아직 살아 있는지, 무엇을 다시 해서는 안 되는지가 빠지기 쉽기 때문이다.

인계 기록은 짧아도 다음 항목을 담는 편이 좋다.

작업: 무엇을 끝내려는가
현재 상태: 실행 중 / 입력 대기 / 중단 / 검증 중
확정된 결과: 채택된 산출물과 버전, 바꾸지 않을 결정과 이유
외부 변화: 이미 게시·전송·수정된 항목
현재 권한: 지금 변경할 수 있는 실행자와 종료 시점
남은 결정: 필요한 입력·승인, 아직 열려 있는 선택과 기한
다음 행동: 안전하게 재개할 단계와 먼저 확인할 기준 자료

이 목록은 표준 규격이 아니라 실무용 메모 틀이다. 내부 추론과 원시 로그를 전부 넘기자는 뜻도 아니다. 비밀 정보와 개인정보는 빼고, 다음 결정을 내리는 데 필요한 상태와 근거만 남긴다. W3C Trace Context처럼 분산 요청을 연결하는 표준도 있지만, 추적 ID가 작업 소유권이나 승인·재개 권한까지 대신하지는 않는다. Trace Context

예약 공개는 새 기능보다 기존 예약·실행 기능을 빌리는 편이 낫다

예약 공개는 이 선택 기준을 적용하기 좋은 예다. 공개 빈도가 낮고 매번 사람이 글을 먼저 승인한다면, 사이트 자체에 예약 상태와 관리자 화면을 새로 만들 이유가 적다. 이미 있는 예약 기능이 승인된 글을 정해진 시각에 게시하도록 맡기면 된다.

그렇다고 예약 기능이 모든 책임을 가져가는 것은 아니다. 예약 실행이 두 번 시도될 수 있고, 컴퓨터가 꺼져 있거나 서비스가 지연될 수 있으며, 실행 성공과 실제 공개 성공은 다를 수 있다. Google Cloud Scheduler는 드물게 한 일정이 여러 번 실행될 수 있으므로 대상을 멱등하게 만들라고 안내한다. GitHub Actions도 부하가 높을 때 예약 실행이 지연되거나 일부 작업이 빠질 수 있다고 문서화한다. Cloud Scheduler overview, GitHub Actions troubleshooting

따라서 예약 도구는 승인자가 아니라 실행자다. 승인된 대상과 버전이 분명해야 하고, 같은 버전을 다시 실행해도 중복 효과가 없어야 한다. 실제 공개 결과 확인은 별도의 검증 단계로 남는다. 예약 빈도와 정시성 요구가 커질 때에만 관리형 작업 흐름이나 전용 기능의 비용을 다시 비교하면 된다.

오래 일하게 하기보다, 잃지 않게 한다

좋은 장기 작업은 반드시 복잡한 작업 관리 시스템을 갖춘 작업이 아니다. 다시 돌리기 쉬우면 재시작이 낫고, 자연스러운 중간 결과가 있으면 체크포인트 몇 개로 충분하다. 플랫폼이 상태·재시도·예약을 이미 제공한다면 그 기능을 빌리는 편이 대개 더 합리적이다. 여러 실행자가 같은 상태를 바꾸거나, 중복된 외부 효과가 크거나, 사람의 승인이 필요할 때에만 소유권과 중단·재개 규칙을 강화한다.

핵심은 에이전트를 오래 버티게 하는 데 있지 않다. 작업이 끊기거나 대화가 압축돼도 어디까지 끝났는지 알고, 같은 일을 잘못 반복하지 않으며, 다음 행동을 누가 해도 되는지 분명히 하는 데 있다. 네 시간의 실행 기록보다 다음 한 줄이 더 쓸모 있을 때가 많다.

여기까지 확정했고, 이것은 이미 실행했으며, 다음에는 이 단계부터 확인하고 이어가면 된다.

AI disclosure

Researched and drafted with OpenAI Codex using GPT‑5.6 Sol (xhigh reasoning). Editorial review and final approval by Yioo.