코딩 에이전트 실패 복구는 샌드박스 전체 스냅샷 탐색으로 개선된다

무엇인가

코딩 에이전트는 실패하기 전까지 상당한 진전을 만든다. 문제는 그 진전이 실패와 함께 사라진다는 점이다. 재시도는 처음부터 다시 시작하므로, 그 과정에서 만들어진 머신 상태는 통째로 버려진다. 이 논문은 이 낭비를 실패 복구의 비효율로 규정하고, 복구를 하나의 탐색 문제로 다시 정의한다.

어떻게 동작하나

출발점은 단순한 가정이다. 중간 환경 상태가 의미 있는 진전을 보존하고 있다면, 그 상태로 되돌아가 거기서부터 분기해 나가는 편이 초기 상태에서 반복 재시작하는 것보다 나을 수 있다. 즉 실패는 끝이 아니라, 다시 뻗어나갈 수 있는 탐색 노드가 된다.

무엇과 다른가

제안하는 방법은 Go-Explore 스타일 탐색을 Daytona의 전체 스냅샷 위에 구현한 것이다. Go-Explore는 유망했던 상태로 되돌아간 뒤 그 지점에서 다시 탐색을 전개하는 접근으로, 여기서는 전체 스냅샷이 그 복원 지점 역할을 한다. 중요한 차이는 스냅샷의 범위다. 저장소의 코드 변경분만이 아니라 데이터베이스, 실행 중인 서비스, 그 밖의 런타임 상태까지 함께 담긴다. 에이전트가 만들어 놓은 환경 전체가 되돌릴 수 있는 단위가 되는 셈이다.

어떻게 쓰나

실험에서 더 높고 더 효율적인 해결률을 좌우한 것은 주로 저장소 밖에 존재하는 진전이었다. 데이터베이스, 서비스, 기타 런타임 상태처럼 코드 diff만으로는 복원되지 않는 자산이다. 저장소 안의 변경만이 문제의 전부라면 전체 스냅샷을 되돌리는 이점은 상대적으로 작아진다.

전제와 한계

이 관찰이 논문의 결론으로 이어진다. 전체 스냅샷 탐색은 장기(long-horizon) 코딩 작업이 여러 서비스에 걸쳐 있고, 그 상태가 단일 diff로 재구성되지 않을 때 가장 효과적이다. 에이전트가 오래 붙잡고 있어야 하는 작업일수록, 그리고 손대는 대상이 코드 바깥으로 퍼져 있을수록 스냅샷 기반 분기 탐색의 값어치가 커진다는 뜻이다.

실무에서는 에이전트 실행 인프라를 설계할 때 이 지점을 먼저 따져야 한다. 재시도를 처음부터 다시 도는 정책으로 둘지, 스냅샷을 찍고 유망한 지점으로 되돌아가는 정책으로 둘지가 여기서 갈린다. 스냅샷에 무엇을 포함할지, 즉 저장소만 담을지 서비스와 데이터베이스 상태까지 담을지가 핵심 결정이 되며, 그 선택은 작업이 몇 개의 서비스에 걸쳐 있는지에 따라 달라진다.

한계도 분명하다. 이 논문의 결론은 조건부다. 전체 스냅샷 탐색의 이점은 저장소 밖 상태가 문제 해결에 중요할 때 나타나며, 그렇지 않은 작업에서는 효과가 제한적일 수 있다는 전제 위에 서 있다. 따라서 자신의 작업이 단일 저장소, 단일 프로세스 안에서 끝나는지부터 확인해야 한다.