sunny34.com

1. 에이전트 호출과 실제 업무 완료를 같은 요청으로 묶지 말아야 한다

에이전트가 문서를 읽고, 도구를 호출하고, 외부 시스템까지 갱신하는 작업은 생각보다 오래 걸립니다. 이 과정을 브라우저 요청 한 번에 모두 끝내려 하면 타임아웃과 중복 실행이 동시에 발생하기 쉽습니다. 그래서 운영 관점에서는 사용자 요청과 실제 작업 완료를 분리하는 구조가 먼저 필요합니다.

가장 단순한 기준은 "접수", "백그라운드 실행", "검토 또는 확정"을 분리하는 것입니다. 접수 단계에서는 작업 ID와 입력을 고정하고, 실행 단계에서는 모델 호출과 도구 결과를 누적하며, 확정 단계에서는 외부 시스템에 쓰기 전 최종 승인 여부를 판단합니다. 이 분리가 있어야 실패가 나도 어느 단계부터 다시 시작할지 명확해집니다.

2. 큐 단위는 작업 목적이 아니라 복구 경계로 나누는 편이 안전하다

많은 팀이 작업 이름 중심으로 큐를 나누지만, 실제 운영에서는 복구 경계를 기준으로 나누는 편이 더 유용합니다. 예를 들어 첫 번째 큐는 입력 정규화와 정책 점검, 두 번째 큐는 모델 추론과 도구 호출, 세 번째 큐는 승인 후 외부 반영으로 분리할 수 있습니다. 이렇게 하면 실패가 발생해도 전체를 다시 돌리지 않고 중간 상태부터 재실행할 수 있습니다.

• 접수 큐: 요청 본문, 사용자 ID, 권한 범위, 멱등 키를 저장합니다.
• 실행 큐: 모델 응답, 도구 호출 결과, 중간 요약, 재시도 횟수를 추적합니다.
• 확정 큐: 사람이 승인한 이후에만 CRM, CMS, 티켓 시스템 같은 외부 시스템에 쓰기를 수행합니다.

이 구조는 에이전트 품질이 완벽하지 않아도 서비스 안정성을 지키는 기본 장치가 됩니다.

3. 승인 게이트는 마지막 단계에만 두지 말고 위험도별로 여러 층을 둬야 한다

사람 승인이 필요하다는 사실만으로는 운영 리스크가 해결되지 않습니다. 어떤 작업은 초안 작성까지만 자동화해도 충분하고, 어떤 작업은 외부 전송 직전에만 승인하면 됩니다. 따라서 승인 게이트는 작업 결과물이 미치는 영향 범위에 맞춰 여러 층으로 설계하는 편이 낫습니다.

예를 들어 내부 초안 작성은 자동으로 허용하되, 고객에게 직접 발송되는 메시지나 결제 관련 수정은 별도 승인 상태로 멈추게 할 수 있습니다. 이때 승인 화면에는 전체 프롬프트를 노출하기보다 요약, 근거 링크, 예상 영향, 되돌리기 방법이 함께 보여야 담당자가 더 빠르게 판단할 수 있습니다.

4. 재시도 정책은 모델 실패와 시스템 실패를 구분해야 한다

에이전트 작업에서는 같은 오류처럼 보여도 실제 원인이 다릅니다. 네트워크 오류나 도구 응답 지연은 시스템 재시도로 해결될 수 있지만, 정책 위반이나 근거 부족은 재시도보다 사람 검토가 맞습니다. 따라서 재시도 정책은 단순 횟수 제한이 아니라 실패 유형 분류와 함께 설계돼야 합니다.

운영 로그에는 최소한 작업 ID, 이전 상태, 현재 상태, 모델 버전, 사용한 도구, 재시도 횟수, 최종 판정 이유가 남아야 합니다. 이 로그가 있어야 장애가 났을 때 "왜 멈췄는지"와 "어디서 다시 시작해야 하는지"를 빠르게 설명할 수 있습니다.

5. 처음부터 복잡한 오케스트레이션을 만들기보다 한 가지 고위험 흐름부터 큐로 옮기는 편이 낫다

비동기 에이전트 작업 큐 설계의 목적은 모든 AI 기능을 대규모 워크플로 엔진으로 옮기는 것이 아닙니다. 오히려 고객 영향이 크고 실행 시간이 긴 흐름 하나를 골라, 그 흐름에서 타임아웃 감소와 승인 정확도 향상을 먼저 확인하는 편이 현실적입니다. 예를 들어 긴 리포트 생성, 다단계 검토, 다수 도구 호출이 필요한 지원 자동화부터 시작하면 운영 효과를 비교적 빨리 볼 수 있습니다.

정리하면 비동기 에이전트 운영의 핵심은 모델을 더 똑똑하게 만드는 것이 아니라, 실패와 승인과 재실행을 사람이 이해할 수 있는 상태 전이로 바꾸는 데 있습니다. 이 기준이 있어야 에이전트가 오래 걸리는 일도 안정적으로 맡을 수 있습니다.