Executor와 상태 관리

실행기는 계획을 작업으로 바꾼다

Planner가 "무엇을 어떤 순서로 할지" 정한다면, Executor는 그 계획을 실제 작업으로 바꿉니다. 에이전트가 문서를 요약하고, 검색 도구를 호출하고, 초안을 만들고, 사용자의 승인을 기다리는 과정은 모두 Executor의 책임입니다.

Executor의 기본 흐름은 단순합니다.

1. 실행할 단계를 가져옵니다.

2. 단계에 필요한 입력을 준비합니다.

3. 필요한 도구를 호출합니다.

4. 결과가 기대한 형태인지 확인합니다.

5. 성공하면 다음 단계로 이동합니다.

6. 실패하면 재시도하거나 중단합니다.

중요한 점은 Executor가 단순히 "도구를 실행하는 함수"가 아니라는 사실입니다. 실행 결과를 해석하고, 상태를 저장하고, 실패했을 때 다음 행동을 결정하는 작은 운영 시스템에 가깝습니다.

단계마다 기록해야 할 것

에이전트 작업은 한 번에 끝나지 않는 경우가 많습니다. 검색 결과를 모으고, 초안을 만들고, 검토하고, 발행 준비까지 이어질 수 있습니다. 이때 각 단계의 실행 기록을 남기지 않으면 문제가 생겼을 때 어디서부터 다시 시작해야 하는지 알 수 없습니다.

최소한 다음 정보는 저장하는 것이 좋습니다.

• 단계 ID

• 단계 이름

• 입력값

• 사용한 도구

• 도구 호출 결과

• 시작 시간과 종료 시간

• 성공 여부

• 오류 메시지

• 재시도 횟수

• 다음에 실행할 단계

예를 들어 "블로그 초안 작성" 단계가 실패했다면, Executor는 이전 검색 결과까지 다시 만들 필요가 없습니다. 이미 성공한 검색 단계의 결과를 불러오고, 초안 작성 단계만 다시 실행하면 됩니다. 이것이 상태 관리의 핵심입니다.

중간 상태는 어디에 저장할까

간단한 실험에서는 메모리에 상태를 저장해도 됩니다. 하지만 실제 서비스에서는 서버가 재시작되거나 네트워크 오류가 생길 수 있습니다. 그래서 중요한 작업 상태는 데이터베이스나 작업 큐, 파일 저장소처럼 오래 남는 공간에 저장해야 합니다.

상태는 크게 두 종류로 나눌 수 있습니다.

첫째, 작업 상태입니다. 현재 작업이 어디까지 진행되었는지 나타냅니다. 예를 들어 pending, running, waiting_approval, failed, completed 같은 값입니다.

둘째, 작업 컨텍스트입니다. 다음 단계를 실행하는 데 필요한 중간 결과입니다. 검색 결과, 사용자가 수정한 문장, 생성된 초안, 선택한 옵션 등이 여기에 포함됩니다.

작업 상태는 진행을 제어하고, 작업 컨텍스트는 다음 실행의 재료가 됩니다. 둘을 구분하면 설계가 훨씬 단순해집니다.

실패했을 때의 기준

모든 실패를 같은 방식으로 처리하면 안 됩니다. 네트워크 오류처럼 일시적인 문제는 재시도할 수 있습니다. 하지만 권한 오류나 잘못된 입력값은 재시도해도 같은 문제가 반복될 가능성이 큽니다.

재시도에 적합한 경우는 다음과 같습니다.

• 외부 API의 일시적 장애

• 네트워크 타임아웃

• 응답 지연

• 모델 출력 형식 오류 중 자동 수정이 가능한 경우

반대로 즉시 중단하거나 사용자 확인을 받아야 하는 경우도 있습니다.

• 권한이 없는 도구 호출

• 삭제, 결제, 발행처럼 되돌리기 어려운 작업

• 입력 데이터가 부족한 경우

• 모델이 계획과 다른 도구를 반복해서 호출하는 경우

좋은 Executor는 실패를 숨기지 않습니다. 실패한 이유를 기록하고, 다시 실행할 수 있는 지점을 남깁니다. 그래야 사용자는 "처음부터 다시 하기"가 아니라 "문제가 생긴 단계부터 이어 하기"를 선택할 수 있습니다.

사용자가 중간에 개입하는 흐름

실제 제품에서는 에이전트가 모든 단계를 자동으로 끝내기보다, 중요한 지점에서 사용자의 확인을 받는 편이 안전합니다. 예를 들어 콘텐츠 에이전트는 자료 조사와 초안 작성까지는 자동으로 수행할 수 있습니다. 하지만 게시 전에는 사용자 승인을 받아야 합니다.

이때 Executor는 작업을 완료 상태로 만들지 않습니다. 대신 waiting_approval 상태로 저장합니다. 사용자가 초안을 수정하거나 승인하면, 수정된 내용을 작업 컨텍스트에 반영하고 다음 단계부터 재개합니다.

이 구조를 사용하면 사용자는 에이전트의 결과를 통제할 수 있고, 에이전트는 중간 결과를 잃지 않습니다.

실습: 여러 단계 작업을 이어서 실행하기

간단한 콘텐츠 작성 에이전트를 생각해 봅시다.

• 1단계: 주제 입력 받기

• 2단계: 핵심 아이디어 정리

• 3단계: 초안 작성

• 4단계: 사용자 승인 대기

• 5단계: 승인된 초안을 게시용 형식으로 변환

이 실습의 핵심은 각 단계가 끝날 때마다 상태를 저장하는 것입니다. 3단계에서 초안 작성이 끝나면 결과를 컨텍스트에 넣고 상태를 waiting_approval로 바꿉니다. 사용자가 문장을 수정하면 수정본을 다시 저장합니다. 이후 Executor는 1단계부터 다시 시작하지 않고 5단계만 실행합니다.

에이전트가 일을 끝까지 수행하려면 좋은 답변만으로는 부족합니다. 어디까지 했는지 기억하고, 실패한 지점에서 다시 시작하고, 사용자의 개입을 자연스럽게 받아들여야 합니다. Executor와 상태 관리는 이 능력을 만드는 기반입니다.