AI 에이전트에게 필요한 건 자율성이 아니라 롤백 기능이다

대부분의 에이전트 프레임워크에서 트랜잭션이 어떻게 처리되는지 고민해 보았다.

에이전트가 5개의 도구 호출을 순차적으로 실행한다고 가정해 보자. 세 번째 도구에서 오류가 발생하면, 결과 상태는 사용자가 의도한 결과도 아니고 실행 전 시스템 상태도 아닌 어중간한 상태가 된다. 결과적으로 에이전트에게는 복구할 체계적인 방법이 없으며, 인간 운영자조차 불완전한 증거를 바탕으로 무슨 일이 일어났는지 재구성해야만 한다.

이 문제는 도구 자체의 결함이 아니라, 스택에서 빠져 있는 근본적인 기본 요소가 없기 때문이다.

데이터베이스는 50년 동안 이 문제를 해결해 왔고, 분산 시스템은 수십 년 동안 이 문제와 씨름해 왔다. 이 개념을 설명하기 위한 풍부한 용어들이 존재한다: ACID, 사가(sagas), 보상 동작(compensating actions), 멱등성 키(idempotency keys), 2단계 커밋(two-phase commit), 선행 기록 로그(write-ahead logs) 등이 그것이다. 어쩌면 이런 개념 중 일부가 에이전트 프레임워크에 통합되었을지도 모르지만, 지금까지 프로덕션 환경에서 이를 본 적은 없다.

현재 지배적인 패턴은 다음과 같다:

• 도구 호출 시퀀스를 실행한다.
• 오류가 발생하면 LLM에게 "알아서 해결해"라고 요청한다.
• 좋은 결과가 나오길 바란다.
• 루프가 끝나면 "작업 완료"라고 기록한다.

이 접근 방식은 에이전트가 격리된 환경에서 되돌릴 수 있는 작업을 수행할 때는 효과적이다. 하지만 에이전트가 파일 시스템, 배포, 사이드 이펙트가 있는 외부 API, 결제 흐름, 데이터베이스 등과 상호작용할 때는 실패한다. 이런 작업들은 인간이라면 부분적인 상태를 남기기보다 트랜잭션 방식으로 처리되기를 기대할 것이다.

질문은 "에이전트를 얼마나 자율적으로 만들 수 있는가?"가 아니라 "에이전트가 재시도, 보상, 롤백이 필요한 작업에 대해 자신의 의도를 어떻게 표현할 수 있는가?"이다.

LLM이 이런 상황을 처리할 만큼 똑똑해지는 것만으로 충분할까? 이는 분산 시스템이 이미 저질렀던 실수와 같다. 애플리케이션 계층이 독립적으로 이런 문제를 해결할 것이라고 가정했던 것이다. 그 가정은 틀린 것으로 판명되었고, 인프라가 주도권을 잡아야 했다.

유망한 차세대 솔루션은 더 똑똑한 루프라는 개념에서 벗어나 다음 사항에 집중할 가능성이 높다:

• 명시적인 트랜잭션 경계 설정.
• 각 도구에 대한 보상 동작 등록.
• 도구 호출에 멱등성 키 포함.
• 단순한 채팅 기록을 넘어선 재실행 로그 활용.
• 승인 게이트를 일급 기본 요소로 인식.
• LLM이 추론할 필요가 없는 부분 실패 복구 메커니즘 구현.

아니면 내가 너무 빗나간 생각을 하는 걸까? 여러분의 생각을 알려달라.