기다리는 AI에도 서버비는 듭니다: 에이전트에게 일시정지가 필요한 이유

핵심 요약

• AI 에이전트가 기다리는 동안에도 할당해 둔 서버 자원에는 비용이 들 수 있습니다.
• 실행 환경의 일시정지와 재개는 대기 중 자원 낭비를 줄이기 위한 설계입니다.
• 일시정지라는 기능 이름만으로 자원 반환이나 과금 중단을 보장하지는 않습니다.
• 작업을 안정적으로 이어가려면 작업 상태와 외부 연결을 관리하고 중복 실행도 막아야 합니다.

AI에게 코드 작성부터 실행까지 맡기면, 답변이 정확한지 외에도 따져볼 문제가 생깁니다. 사람의 승인이나 외부 서비스의 응답을 기다리는 동안 실행 환경을 어떻게 유지할지도 생각해야 합니다. 구글 AX와 Agent Substrate를 볼 때도 이 질문을 해볼 필요가 있습니다. “일하지 않는 에이전트의 자원은 누가 관리할까요?”

1. 에이전트의 작업 시간에는 기다림이 섞여 있습니다

에이전트는 모델을 호출하는 것만으로 일을 끝내지 않습니다. 파일을 만들고 프로그램을 실행한 뒤, 결과까지 확인합니다. 결제를 하거나 변경 사항을 배포하기 전에는 사람의 승인을 기다릴 수도 있습니다.

이때 모델의 추론이 멈췄다고 해서 주변 인프라 비용까지 사라지지는 않습니다. 실행 환경에 메모리와 서버 자원을 계속 할당해 두면, 과금 방식에 따라 유지 비용이 듭니다.

가령 작업 하나가 끝나는 데 30분이 걸린다고 해보겠습니다. 실제 실행은 3분이고 승인 대기가 27분이라면, 전체 시간의 90%를 기다리는 데 씁니다.

그렇다고 비용을 90% 줄일 수 있다는 뜻은 아닙니다. 다만 모델 호출 비용만 따져서는 이런 지출을 놓치기 쉽습니다. 에이전트가 여러 개로 늘어나면 대기 상태로 남아 있는 실행 환경도 함께 늘어납니다.

2. 샌드박스를 멈춘다는 것은 무엇일까요?

샌드박스는 에이전트가 코드를 실행하고 파일을 다루는 격리된 작업 공간입니다. 실행한 코드가 주변 시스템에 미치는 영향을 제한하기 위해 마련한 환경입니다.

작업이 잠시 멈출 때마다 이 공간을 지워버리면 문제가 생깁니다. 설치한 도구와 중간 결과를 다시 준비해야 할 수 있기 때문입니다. 반대로 모든 환경을 계속 켜두면 기다리는 동안에도 자원을 차지합니다.

이럴 때 쓰는 기능이 suspend와 resume, 즉 일시정지와 재개입니다. 필요한 상태를 보존해 두었다가 다음 작업을 할 수 있을 때 이어서 실행하는 방식입니다.

다만 무엇을 보존하는지에 따라 작업을 재개하는 방식도 달라집니다. 파일과 작업 기록을 저장한 뒤 프로그램을 다시 실행할 수도 있고, 실행 중인 메모리 상태까지 보존할 수도 있습니다. 두 방식은 복구 속도가 다르고 구현하는 데 드는 수고도 다릅니다.

프로세스만 멈추고 메모리와 서버는 그대로 점유하는 경우도 있습니다. 따라서 ‘일시정지 지원’이라는 설명만 보고 대기 비용이 사라진다고 판단해서는 안 됩니다. 실제로 어떤 자원을 반환하는지, 멈춰 있는 동안에는 무엇에 과금하는지 확인해야 합니다.

3. 다시 켜기보다 안전하게 이어가기가 더 까다롭습니다

실행 환경을 복원해도 외부 시스템까지 이전 상태로 돌아가지는 않습니다.

기다리는 사이 로그인 정보가 만료되거나 데이터베이스 연결이 끊어질 수 있습니다. 그동안 다른 사람이 같은 파일을 수정했을 가능성도 있습니다.

특히 조심해야 할 문제는 중복 실행입니다. 예를 들어 에이전트가 결제 요청을 보낸 직후 멈췄다고 해보겠습니다. 결제는 성공했는데 그 결과를 기록하지 못했다면, 작업을 재개한 에이전트가 같은 요청을 다시 보낼 수 있습니다.

이를 막으려면 해당 작업을 이미 처리했는지 확인할 수 있어야 합니다. 같은 요청을 여러 번 보내도 결제는 한 번만 처리하도록 설계할 필요도 있습니다. 이런 성질을 ‘멱등성’이라고 부릅니다.

작업을 제대로 이어가려면 두 종류의 기록을 함께 챙겨야 합니다. 실행 환경에 남아 있는 상태와 외부에서 실제로 완료된 작업의 기록입니다. 샌드박스를 복원하는 기능만으로는 복구 과정에서 생기는 문제를 모두 해결할 수 없습니다.

4. 오케스트레이터는 기다림도 관리해야 합니다

오케스트레이터는 여러 작업의 순서와 실행을 조율하는 시스템입니다. 에이전트에게 일을 나눠주고 각 에이전트가 낸 결과를 모읍니다.

대기 상태까지 관리하려면 판단할 일이 늘어납니다. 우선 지금 멈춰도 되는지 살펴야 합니다. 멈추기로 했다면 어떤 상태를 저장하고, 무엇을 계기로 다시 실행할지도 정해야 합니다.

기다린다고 해서 매번 일시정지하는 편이 유리하지는 않습니다. 몇 초 뒤 응답이 돌아오는데 상태를 저장하고 복원하는 데 더 오래 걸린다면 그대로 두는 편이 나을 수 있습니다. 반면 사람이 다음 날 승인할 작업이라면 실행 환경을 계속 켜둘 이유가 줄어듭니다.

비용도 함께 따져야 합니다. 대기 중 자원을 반환해 아끼는 금액에서 상태를 저장하고 복원하는 데 드는 비용을 빼야 합니다. 사용자가 작업 재개를 얼마나 기다려야 하는지도 고려해야 합니다.

제가 구글 AX와 Agent Substrate 같은 주제를 볼 때도 이 부분을 눈여겨봅니다. 에이전트 전용 인프라를 평가하려면 기다림을 얼마나 효율적으로 처리하는가도 살펴야 합니다.

에이전트 운영 비용을 따질 때는 일하는 시간과 기다리는 시간을 함께 봐야 합니다. 일시정지와 재개는 이 두 상태 사이에서 실행 환경을 관리하는 기능입니다. 에이전트가 승인을 기다리는 동안 실행 환경도 멈추는지, 계속 켜져 있다면 그 시간에 비용이 얼마나 드는지 확인할 필요가 있습니다.