에이전트의 실패와 복구

실패를 전제로 설계하기

에이전트 시스템은 한 번의 답변으로 끝나지 않습니다. 계획을 세우고, 도구를 호출하고, 외부 서비스의 결과를 기다리고, 상태를 저장합니다. 이 과정이 길어질수록 실패 가능성도 커집니다.

중요한 목표는 "절대 실패하지 않는 에이전트"가 아닙니다. 그런 시스템은 현실적으로 만들기 어렵습니다. 더 중요한 것은 실패해도 데이터가 망가지지 않고, 비용이 폭증하지 않으며, 사용자가 어디서 문제가 생겼는지 이해할 수 있게 만드는 것입니다.

무한 루프와 비용 폭증 막기

에이전트가 같은 작업을 반복하는 경우가 있습니다. 예를 들어 자료를 찾지 못했는데 계속 검색 도구를 호출하거나, 실패한 API 요청을 조건 없이 반복하는 식입니다.

이를 막으려면 먼저 최대 단계 수를 정해야 합니다. 하나의 작업은 10단계까지만 실행한다, 도구 호출은 5회까지만 허용한다처럼 상한을 둡니다. 이 제한은 단순하지만 매우 강력한 안전장치입니다.

반복 패턴도 확인해야 합니다. 같은 도구를 같은 입력으로 여러 번 호출한다면 실행을 멈추고 원인을 기록해야 합니다. 또한 작업별 비용 한도를 두어야 합니다. 모델 호출 비용, 검색 비용, 외부 API 비용이 일정 금액을 넘으면 자동으로 중단하고 사용자에게 확인을 요청합니다.

잘못된 도구 호출 줄이기

도구 호출 실패는 대부분 입력이 부정확하거나, 호출 조건이 맞지 않아서 발생합니다. 예를 들어 이메일 발송 도구에는 수신자, 제목, 본문이 필요합니다. 이 중 하나라도 없다면 실행하지 않아야 합니다.

각 도구에는 사전 조건을 둡니다. 읽기 도구인지 쓰기 도구인지, 사용자 승인이 필요한지, 어떤 형식의 입력만 허용하는지 명확히 정합니다. 모델이 도구를 선택하더라도 실제 실행 전에 시스템이 한 번 더 검증해야 합니다.

특히 되돌리기 어려운 작업은 실행 전 확인 절차가 필요합니다. 게시, 결제, 삭제, 대량 발송 같은 작업은 "모델이 요청했다"는 이유만으로 실행하면 안 됩니다. 초안을 보여주고 사용자가 승인한 뒤 실행해야 합니다.

맥락 손실에 대비하기

긴 작업에서는 처음 목표가 흐려질 수 있습니다. 대화가 길어지고 도구 결과가 쌓이면 모델이 이전 조건을 잊거나, 이미 끝난 단계를 다시 수행할 수 있습니다.

이를 막기 위해 작업 상태를 요약해서 저장합니다. 목표, 현재 단계, 완료된 단계, 남은 단계, 중요한 사용자 지시를 별도로 관리합니다. 전체 대화를 매번 넣는 대신, 실행에 필요한 핵심 상태를 구조화해 전달하는 방식입니다.

단계별 기록도 중요합니다. 어떤 입력으로 어떤 도구를 호출했고, 어떤 결과가 나왔으며, 그 결과를 바탕으로 다음에 무엇을 했는지 남겨야 합니다. 이 기록이 있어야 중간에 실패해도 같은 일을 처음부터 반복하지 않고 이어서 실행할 수 있습니다.

외부 서비스 실패 다루기

에이전트는 종종 이메일, 캘린더, 문서, 데이터베이스, 결제 API 같은 외부 서비스에 의존합니다. 이때 실패는 에이전트 내부 문제가 아닐 수 있습니다. 권한이 만료되었거나, API 호출 한도를 넘었거나, 외부 서비스가 일시적으로 장애를 겪을 수 있습니다.

이런 경우에는 조용히 재시도만 반복하면 안 됩니다. 사용자에게 무엇이 실패했는지 알려야 합니다. "문서 서비스 권한이 만료되어 파일을 읽을 수 없습니다"처럼 원인을 구체적으로 설명하는 것이 좋습니다.

가능하다면 대체 경로도 제안합니다. 권한 오류라면 다시 로그인하도록 안내하고, API 제한이라면 잠시 후 재시도하거나 작업을 큐에 넣습니다. 외부 서비스 장애라면 로컬 초안 저장, 수동 다운로드, 나중에 다시 실행 같은 선택지를 제공할 수 있습니다.

체크포인트와 재시도 정책

복구 가능한 에이전트를 만들려면 체크포인트가 필요합니다. 체크포인트는 "여기까지는 성공했다"는 저장 지점입니다. 단계가 끝날 때마다 입력, 출력, 상태, 다음 단계 정보를 저장하면 중단된 작업을 마지막 성공 단계부터 재개할 수 있습니다.

재시도 정책도 구체적이어야 합니다. 네트워크 오류처럼 일시적인 문제는 짧은 간격으로 몇 번 재시도할 수 있습니다. 반면 권한 오류, 입력 오류, 승인 누락은 재시도해도 해결되지 않습니다. 이런 오류는 즉시 멈추고 사용자 조치를 기다려야 합니다.

좋은 에이전트는 실패를 숨기지 않습니다. 어디서 멈췄는지, 무엇을 보존했는지, 사용자가 무엇을 선택할 수 있는지 알려줍니다. 결국 안정적인 에이전트는 더 똑똑한 모델만으로 만들어지지 않습니다. 제한, 기록, 검증, 승인, 복구 흐름이 함께 있을 때 실제 제품 안에서 믿고 사용할 수 있습니다.