DeltaBox: 파일과 프로세스를 함께 되돌리는 에이전트 롤백의 조건

코딩 에이전트가 실패한 분기에서 돌아올 때 대화 기록만 잘라 내면 될까. 이미 파일을 수정했고, Python 프로세스가 수정 전 설정을 메모리에 들고 있다면 그렇지 않다. 파일을 되돌렸다고 실행 중인 변수와 파일 핸들까지 과거로 돌아가는 것도 아니다. 더 까다로운 경우는 그 분기에서 원격 API 쓰기까지 성공했을 때다. 로컬 상태를 복구해도 외부 서버가 받은 요청은 남는다.

DeltaBox는 첫 번째와 두 번째 문제, 즉 파일시스템과 프로세스 상태를 함께 복구하는 비용을 줄이려는 연구다. 모든 행동을 취소하는 만능 실행 취소 버튼은 아니다. 이 글은 arXiv의 버전 고정 본문 v2를 바탕으로 메커니즘과 측정 경계를 해설하고, 어떤 복구 계층이 필요한지 판단하는 표를 제안한다. 제품을 설치해 실행한 후기나 벤치마크 독립 재현 결과는 아니다.

1. 무엇을 한 묶음으로 저장해야 하나

논문은 에이전트의 물리 상태를 파일시스템과 프로세스 메모리라는 두 축으로 나눈다. Git으로 추적 파일을 복구하는 일과, 실행 중인 프로세스가 어느 명령 다음에서 계속할지를 복구하는 일은 서로 다르다. 대화나 워크플로 상태 저장은 또 다른 논리 계층이다. 어느 하나만 저장하면서 나머지도 복구됐다고 가정하면 이전 상태의 코드와 이후 상태의 메모리를 섞을 수 있다.

DeltaBox가 제안하는 추상화 DeltaState는 파일과 메모리의 일관된 쌍을 체크포인트로 취급한다. StateManager는 두 복구 장치를 조정한다. DeltaFS가 파일 계층을 다루고, DeltaCR이 CRIU 덤프와 동결 프로세스 템플릿을 다룬다. 복구에서는 파일 계층을 먼저 목표 시점으로 전환한 뒤 그 시점의 프로세스를 재개해, 서로 다른 시점의 상태로 실행되는 것을 막는다는 설계다. 논문 §§3.2–3.3과 §4.3의 설명이지, 여기에서 수행한 정확성 증명은 아니다.

파일과 메모리를 같은 시점으로 되돌리는 결합 구조. 외부 서버의 상태는 이 복구 쌍에 포함되지 않는다. 논문 설계의 편집자 재구성이며 실행 검증 화면이 아니다. 출처: arxiv.org/html/2605.22781v2.

예를 들어 에이전트가 설정 파일을 바꾼 다음 그 값을 메모리 캐시에 읽었다고 하자. 파일만 과거로 되돌리면 디스크와 캐시가 서로 다른 설정을 나타낼 수 있다. 이 예시는 문제를 설명하기 위한 편집자의 가상 사례다. DeltaBox 실험에서 실제로 관측한 버그나 테스트 로그로 제시하는 것이 아니다.

2. DeltaFS는 전체 디렉터리를 다시 복사하지 않는다

일반 Linux overlayfs의 계층 구성은 마운트 시점에 정해진다. DeltaFS는 커널 모듈을 확장한 사용자 정의 ioctl로 마운트 해제 없이 계층 구성을 전환한다. 체크포인트를 만들 때 현재 쓰기 가능한 upper 계층을 읽기 전용 lower로 바꾸고 새로운 upper를 올린다. 이후 수정은 새 계층에 남으므로 과거 계층을 보존하면서 탐색을 계속할 수 있다.

논문 §4.1에서 중요한 보조 조건은 reflink를 지원하는 XFS다. 수정하지 않은 파일 구간은 물리 블록을 공유하고 덮어쓴 구간에 복사 비용을 내는 방식이다. 단순히 “파일을 복사하지 않는다”로 줄이면 틀린다. 새 수정, 메타데이터, 열린 파일의 포인터를 새 계층에 맞추는 작업은 남는다. 열린 파일에는 세대 번호를 이용한 lazy switch를 적용한다. 따라서 기존 macOS 파일시스템이나 기본 Linux overlayfs에서 설정 하나로 켤 수 있는 기능으로 읽어서는 안 된다.

이 연구의 변경분 중심 접근은 저장과 복구의 반복 비용에 관한 것이다. 샌드박스가 악성 코드를 완벽히 막는다는 보안 보증도, 파일 변경량이 항상 작다는 운영 보증도 아니다. 변경의 크기와 빈도, 계층을 유지하는 비용은 자신의 작업에서 따로 살펴야 한다.

3. 빠른 복구는 살아 있는 템플릿에 달려 있다

DeltaCR은 체크포인트에서 CRIU 덤프와 동결 템플릿을 만든다. 템플릿은 프로세스를 fork한 뒤 멈춰 둔 것이며, 나중에 그 템플릿을 다시 fork하면 메모리 내용을 전부 즉시 복사하지 않고 copy-on-write로 공유한 채 시작할 수 있다. 이것이 빠른 복구 경로다. 템플릿 풀이 제한된 크기여서 목표 템플릿이 이미 제거됐다면 CRIU lazy-pages 복구라는 느린 경로로 돌아간다. 템플릿 제거가 복구 이미지까지 삭제한다는 뜻은 아니다.

빠른 경로는 살아 있는 동결 템플릿에 의존한다. 템플릿이 제거돼도 CRIU 덤프를 이용하는 느린 경로가 남는다. 복구 후 페이지 작업은 없어지는 것이 아니라 일부가 백그라운드로 이동한다. 출처: arxiv.org/html/2605.22781v2.

속도가 빠르다고 일이 사라진 것은 아니다. fork 이후 프로세스가 공유 페이지에 처음 쓰면 복사 비용이 발생한다. 논문 §4.2.2의 async-warm은 별도 데몬 스레드가 그 비용을 백그라운드에서 미리 부담하게 한다. 체크포인트 덤프 역시 LLM 추론을 기다리는 시간과 겹쳐 실행한다. 대기 시간 안으로 일을 옮기는 최적화와 총 자원 사용량이 없어지는 일은 구분해야 한다.

fork가 안전하려면 프로세스가 시스템 호출이나 반쯤 완료된 쓰기 중이 아닌 정지 가능한 시점에 있어야 한다. 장기 네트워크 연결과 SDK 스레드는 별도 Network Proxy Daemon으로 옮긴다. §4.2.3에서 이 데몬은 에이전트의 CRIU 덤프와 템플릿 fork 대상 밖에 있다. 이런 실행 모델 조건 때문에 일반적인 다중 스레드 프로그램을 아무 수정 없이 복구하는 도구로 단정할 수 없다.

4. 5ms라는 제목 대신 v2의 측정 경계를 읽자

수집 큐의 원래 제목에는 “롤백 5ms”가 있었다. 이 제목은 원래 글감의 정체성을 보존하기 위한 기록이며, 이번 글의 결과값으로 재사용하지 않았다. 수집된 버전 비고정 abstract 화면에는 이전의 14ms/5ms 문구가 남아 있는 반면, 실제 검토한 v2 본문은 다른 수치와 측정 조건을 제시한다. 이번 해설의 기준은 2026년 6월 8일 수정된 버전 고정 본문이다. 이전 버전 수치와 새 실험 조건을 섞지 않는다.

v2에서 확인한 항목	보고값	반드시 함께 읽을 범위
Table 2 체크포인트 호출→반환의 로컬 작업	10.83ms	비동기 CRIU 덤프 완료 시간은 제외
Table 2 복구 이벤트 평균	1.86ms	warm-template 기반 표준 경로의 실험 결과
Table 4 느린 경로 복구	9.29ms	템플릿 제거 시 CRIU lazy-pages 대체 경로

Table 2는 이벤트 가중 평균이며 비동기 덤프 완료를 제외한다. Table 4의 9.29ms는 느린 복구 경로다. 표의 행 높이는 지연 크기를 나타내지 않으며 보편적인 SLA가 아니다. 출처: arxiv.org/html/2605.22781v2.

Table 2의 평균은 네 워크로드 행을 같은 비중으로 평균낸 값이 아니다. Django·SymPy·Scientific·Tools/Small 궤적을 각각 4·4·10·6개 사용하고 각 궤적을 두 번 재생했으며, 표의 가중 평균은 체크포인트·복구 이벤트를 모은 이벤트 가중 평균이다. 검토한 표에는 각 행의 정확한 이벤트 수가 공개되지 않아 독자가 행 평균만으로 같은 값을 다시 계산할 수 없다. 궤적 수를 곧바로 이벤트 가중치로 사용하는 것도 맞지 않는다.

실험 환경도 일반 노트북이 아니다. §6.1은 물리 코어 96개·하드웨어 스레드 192개, RAM 760GiB, NVMe 400GB 서버를 명시한다. 샌드박스는 4vCPU·RAM 8GB와 XFS를 사용하며 구현은 사용자 정의 Linux 6.8과 Firecracker에 기반한다. 이 값들은 해당 실험의 지연을 설명하는 조건이지, 모든 인프라의 복구 SLA가 아니다. 과제 해결 정확도가 올랐다는 수치로 바꾸어 읽을 근거도 없다.

Table 4의 체크포인트 “체감 차단 0”도 같은 주의가 필요하다. 10.83ms의 로컬 작업을 추론 대기와 겹쳐 숨겼다는 뜻이다. 전체 덤프 작업이 무료라거나 모든 요청에서 차단 시간이 항상 없다는 보장이 아니다. 템플릿 적중률과 복구 후 쓰기 패턴을 보지 않고 평균 복구값만 선택 기준으로 쓰면 느린 경로나 지연된 작업을 놓친다.

5. 도입 판단표: 상태 복구와 외부 효과를 분리한다

파일만 복구하면 충분한 작업인지, 살아 있는 프로세스까지 이어야 하는 작업인지 먼저 구분한다. 아래 판단표는 논문 설계에서 도출한 편집자의 제안이며, DeltaBox를 실행해 검증한 도입 지침이나 성능 보증이 아니다.

작업에서 되돌려야 하는 것	먼저 검토할 복구 계층	도입 전에 확인할 증거
추적된 소스 파일만 바뀌고 매번 새 프로세스로 시작	파일 복구와 깨끗한 재실행	추적 밖 파일·설치 환경·캐시가 다음 실행에 남는가
실행 중 메모리와 파일이 함께 이전 분기로 돌아가야 함	일관된 파일·프로세스 체크포인트	동일 시점의 쌍 저장, 실패 시 반쪽 상태 중단, 정지 가능한 실행 시점
탐색 트리가 넓어 과거 템플릿이 자주 제거됨	템플릿 풀과 느린 복구 경로	적중·미적중 별 지연, 복구 후 페이지 쓰기, 덤프 저장량
원격 API 쓰기·게시·결제까지 이미 발생	외부 효과 관리 계층을 별도로 설계	요청의 실제 accepted ID, 중복 방지 수단, 취소 또는 보상 가능성

특히 마지막 행은 DeltaBox의 기능 소개가 아니다. 저자들은 §4.2.3에서 네트워크 I/O 롤백을 현재 지원하지 않으며 외부 부작용이 발생할 수 있다고 명시한다. 로컬 프로세스가 과거로 돌아가면 “아직 보내지 않았다”는 상태를 다시 실행할 가능성도 있다. 그러므로 원격 쓰기에는 멱등성이나 보상 처리를 별도로 검토하자는 것이 이 글의 운영 제안이다. 그것을 DeltaBox가 제공하는 검증된 기능으로 소개하지 않는다.

논문의 네트워크 I/O 롤백 비지원 경계를 보여 주는 가상 사례다. 외부 요청 ID·멱등성·보상 처리는 편집자의 별도 설계 제안이며 DeltaBox의 검증된 기능이 아니다. 출처: arxiv.org/html/2605.22781v2.

여기서 유용한 진단 순서는 작다. 먼저 복구 목표 시점에 해당하는 파일과 프로세스를 같이 식별한다. 다음으로 템플릿 적중과 미적중을 따로 기록한다. 마지막으로 외부 요청은 로컬 상태와 다른 원장에 실제 수신 결과를 남기고, 복구 후 재실행이 중복 효과를 만들지 확인한다. 이것은 구현팀이 설계해야 할 검사 항목이지, 이미 이 연구에서 실험한 운영 절차가 아니다. 외부 효과의 상태가 모호하다면 빠른 로컬 롤백보다 모호성을 먼저 해결하는 편이 안전하다.

6. 이 논문에서 가져갈 것과 남겨 둘 것

가져갈 핵심은 “항상 몇 밀리초”가 아니라 파일과 프로세스를 같은 복구 단위로 묶고, 변하지 않은 상태를 공유하며, 비용을 어디에서 치르는지 드러내는 설계다. 반복 탐색이 많은 에이전트라면 검토할 가치가 있지만, 커널 확장·정지 시점·템플릿 풀·외부 I/O 분리를 받아들일 수 있는지부터 판단해야 한다.

남겨 둘 주장은 명확하다. 논문을 읽었다고 독립 성능 재현을 했다고 말할 수 없다. 검토한 v2 HTML에는 DeltaBox 자체의 재현 코드 저장소 링크가 확인되지 않았고, 주변 시스템의 GitHub 링크를 DeltaBox 코드로 취급하지 않았다. 이것은 모든 곳에 코드가 없다는 단정은 아니다. GPU 관련 파생 계산을 실제 운영 학습 속도나 정확도 개선으로 바꾸는 주장도 이 글에서는 하지 않는다.

복구 기능의 가치는 복구 범위를 얼마나 정확히 약속하느냐에 달려 있다. 로컬 파일과 메모리가 일치해도 원격 서버는 다른 시간축을 살고 있다. 이 경계를 먼저 그리면 빠른 롤백을 필요한 곳에 쓰면서, 되돌릴 수 없는 일을 되돌렸다고 착각하는 위험을 줄일 수 있다.

함께 읽으면 구분이 쉬운 글

• Copilot 로컬 샌드박스의 권한 결정표는 실행 권한을 제한하는 문제를 다룬다. 이번 글의 과거 상태 복구와 달리, 무엇을 실행해도 되는지의 경계다. 샌드박스라는 같은 이름 아래 권한 제한과 롤백을 혼동하지 않을 때 도움이 된다.
• Copilot Dynamic Workflows의 재개 경계는 저장된 결과를 이어 쓰는 논리적 재개를 다룬다. DeltaBox의 파일·프로세스 복구와 비교해, 작업 재개가 물리 상태를 되돌린다는 뜻은 아니라는 차이를 읽을 수 있다.

출처와 검토 범위

• 버전 고정 1차 본문: DeltaBox v2. 메커니즘은 §§3.2–3.3, 4.1–4.4, 실험 조건은 §6.1, 지연은 §6.2.1 Table 2와 §6.3.1 Table 4, 네트워크 제한은 §4.2.3을 기준으로 했다.
• 서지 정보: arXiv 2605.22781v2. 최초 제출은 2026년 5월 21일, 검토한 수정본은 2026년 6월 8일이다.
• 본문의 판단표와 가상 사례, 네 장의 설명 그림은 위 근거를 바탕으로 새로 구성한 편집자 해설이다. 실제 제품 화면이나 독립 실험 그래프가 아니며 저자·소속 기관의 보증을 의미하지 않는다.