에이전트가 깔끔하게 죽지 않고 조용히 상태를 망가뜨리는 문제 겪는 사람 또 있음?
Anyone else dealing with agents that silently corrupt state instead of crashing cleanly?
핵심 요약
에이전트가 오류 없이 잘못된 작업을 수행해 데이터를 손상시키는 문제와 그에 대한 해결책(체크포인트, 섀도우 마이그레이션)을 논의함.
- 조용한 실패 — 에이전트가 오류 없이 잘못된 데이터를 생성해 원본을 덮어쓰는 위험성
- 상태 복구 — 데이터 손상 시 복구를 위해 파일시스템과 메모리 스냅샷을 결합한 체크포인트 활용
- 검증 전략 — 섀도우 마이그레이션과 불변성 검증을 통해 작업 전후 상태를 비교하는 방식
- 권한 제한 — 에이전트의 폭발 반경을 줄이기 위해 도구 사용 범위를 엄격히 제한하는 보안 접근
머신러닝이랑 수치 해석 쪽은 꽤 오래 굴러먹었는데, 최근에는 LLM이랑 에이전트 쪽을 좀 건드려보고 있어. 특히 데이터베이스나 설정 파일 같은 실제 데이터를 직접 건드리고 코드를 짜서 실행하는 에이전트 셋업 말이야. 근데 나를 진짜 미치게 만드는 건 에이전트가 뻗어버리는 게 아니야. 에러 나면 그냥 예외 처리하고 넘어가면 그만이니까. 진짜 문제는 에이전트가 '작동은 하는데 결과는 틀린' 상황이 발생할 때야.
예를 들어볼게. LangGraph를 써서 샌드박스 컨테이너 안에서 GPT-OSS-120b 에이전트를 돌리고 있었거든. sqlite 데이터베이스에 있는 "credits" 컬럼을 티어별 "balance" 컬럼으로 마이그레이션하는 작업이었어 (예를 들면 "100 크레딧 미만은 5센트, 500까지는 10센트, 500 이상은 15센트" 이런 식). 에이전트가 마이그레이션 스크립트를 짜서 실행했는데, 에러 하나 없이 깔끔하게 돌아가고는 기존 "credits" 컬럼을 날려버리더라고. 근데 딱 한 명, 정확히 500 크레딧인 유저의 티어를 잘못 계산한 거야. 내가 알아챘을 땐 이미 원래 데이터가 들어있던 컬럼이 삭제된 뒤라, 그 숫자가 원래 뭐였는지 확인할 방법이 없었지. 컨테이너 덕분에 외부 데이터는 무사했지만, 컨테이너 안쪽 데이터는 샌드박스가 있든 없든 똑같이 영구적으로 박살 난 상태였어. 격리만으로는 해결이 안 되니까 결국 처음부터 다시 시작해야 했고, 시간도 토큰도 다 날렸지.
그래서 실제로 에이전트를 실무 데이터에 돌리고 있는 형들한테 몇 가지 물어볼 게 있어.
- 이런 문제 겪어본 적 있어? 아니면 그냥 에이전트를 읽기 전용으로 쓰거나 샌드박스에 가둬놔서 아직 별문제가 없는 거야?
- 만약 이런 일을 겪었다면, 어떻게 잡아냈고 어떻게 복구했어? (아니면 그냥 포기했어?)
결국 내가 직접 테스트용으로 하나 만들었어. Docker랑 OverlayFS 체크포인트를 대화 스냅샷이랑 메타데이터에 맞춰서 묶어버렸거든. 롤백 호출 한 번이면 대화랑 데이터 상태를 동시에 되돌릴 수 있게 말이야. 궁금한 사람 있으면 공유해 줄 수 있는데, 일단 이게 다들 겪는 공통적인 고충인지, 아니면 나만 유난 떠는 건지, 아니면 내가 놓치고 있는 뻔한 해결책이 있는 건지 궁금해서 물어봐.
