프로덕션 AI 에이전트에는 런타임 레이어 (Runtime Layer)가 필요합니다

대부분의 AI 에이전트 데모가 프로덕션 환경에서 실패하는 이유는 지루할 정도로 단순합니다. 프레임워크 (Framework)는 있지만, 런타임 (Runtime)이 없기 때문입니다.

프레임워크는 에이전트가 다음에 무엇을 할지 결정하도록 돕습니다. 메시지, 도구 호출 (Tool calls), 그리고 추론 루프 (Reasoning loop)를 관리합니다.

런타임은 해당 에이전트가 충돌(Crash) 상황에서 생존할 수 있는지, 도구를 안전하게 실행하는지, 예산을 준수하는지, 그리고 작업이 끝났을 때 스스로를 정리할 수 있는지를 결정합니다.

에이전트가 짧은 로컬 데모를 넘어설 때, 이 차이는 즉각적으로 중요해집니다.

프레임워크는 런타임이 아닙니다

에이전트 프레임워크와 에이전트 런타임은 종종 동일한 것으로 취급되지만, 이들은 서로 다른 문제를 해결합니다.

프레임워크는 보통 다음과 같은 질문에 답합니다:

다음 모델 호출 (Model call)은 무엇인가?
에이전트가 어떤 도구를 사용해야 하는가?
메시지와 상태 (State)가 그래프를 통해 어떻게 흐르는가?
루프는 언제 멈춰야 하는가?

런타임은 다른 질문 세트에 답합니다:

에이전트가 실제로 어디에서 실행되는가?
어떤 파일, 네트워크, 비밀 정보 (Secrets), 또는 도구에 접근할 수 있는가?
작업 중간에 프로세스가 종료되면 어떻게 되는가?
에이전트가 무한 루프에 빠지는 것을 무엇이 막아주는가?
상태 누출 (State leakage) 없이 수백 개의 에이전트를 동시에 어떻게 실행하는가?

모델 API는 이 문제를 해결해주지 않습니다. API는 호출 사이에 상태가 없는 스테이트리스 (Stateless) 방식입니다. 프레임워크는 보통 사용자가 시작한 프로세스 내부에서 실행됩니다. 프로덕션 관련 우려 사항들은 바로 그 프로세스 주변에 존재합니다.

그 주변을 둘러싼 레이어가 바로 런타임입니다.

네 가지 런타임의 책임

프로덕션 에이전트를 위해, 런타임 레이어는 보통 네 가지 핵심 역할을 수행합니다.

책임	범위	이것이 없을 때 발생하는 문제
지속 가능한 상태 (Durable state)	체크포인트 (Checkpoints), 재개 (Resume), 복구 (Recovery)	긴 작업이 충돌 후 처음부터 다시 시작됨
...

이 중 어느 것도 지능 (Intelligence)의 문제는 아닙니다.

더 나은 모델은 더 나은 결정을 내릴 수 있지만, 프로세스 복구를 보장하거나, 신뢰할 수 없는 코드를 격리하거나, 인프라 경계에서 실제 시간 기준의 타임아웃 (Wall-clock timeout)을 강제할 수는 없습니다.

지속 가능한 상태는 보통 첫 번째 실패 요인입니다

에이전트는 일반적인 요청-응답 (Request-response) 애플리케이션보다 더 오래 실행되는 경향이 있습니다.

코딩 에이전트 (Coding agent)는 10분 동안 실행될 수 있습니다. 리서치 에이전트 (Research agent)는 한 시간 동안 실행될 수도 있습니다. 예약된 워크플로 (Scheduled workflow)는 수많은 단계, 도구 (Tools), 그리고 재시도 (Retries) 과정을 거치며 실행될 수 있습니다.

작업이 길어질수록, 다음과 같은 요소들이 작업을 방해할 가능성이 높아집니다:

배포 (Deploy)
워커 재시작 (Worker restart)
네트워크 장애 (Network failure)
메모리 부족으로 인한 프로세스 종료 (Out-of-memory kill)
제공자 타임아웃 (Provider timeout)

내구성이 있는 상태 (Durable state)가 없다면, 모든 중단은 전체 재시작으로 이어집니다.

체크포인팅 (Checkpointing)이 도움이 되긴 하지만, 체크포인팅은 내구성이 있는 실행 (Durable execution)의 일부일 뿐입니다. 상태를 저장하는 것은 쉬운 부분입니다. 더 어려운 부분은, 모든 애플리케이션 개발자가 커스텀 복구 로직 (Custom recovery logic)을 직접 작성하지 않아도, 실패를 감지하고 작업을 재개할 수 있는 런타임 (Runtime)을 갖추는 것입니다.

최소한, 프로덕션 에이전트는 다음과 같은 질문에 답할 수 있어야 합니다:

만약 이 프로세스가 37단계에서 중단된다면, 38단계는 어디서부터 다시 시작되는가?

만약 그 대답이 "처음부터 다시 시작한다"라면, 그 시스템은 아직 데모 수준에 불과합니다.

에이전트가 도구를 사용하는 순간, 샌드박스 실행 (Sandboxed execution)은 선택이 아닌 필수입니다

에이전트가 생성된 코드를 실행하거나, 셸 (Shell)을 호출하거나, 웹을 탐색하거나, 파일을 수정할 수 있게 되는 순간, 문제는 오케스트레이션 (Orchestration)에서 보안 (Security)의 문제로 전환됩니다.

도구 접근 (Tool access)은 에이전트가 실제 업무를 수행할 수 있게 해주기 때문에 유용합니다. 하지만 바로 그 이유 때문에 위험하기도 합니다.

런타임 격리 (Runtime isolation)는 다음 사항들을 정의해야 합니다:

에이전트가 무엇을 읽을 수 있는지
에이전트가 무엇을 쓸 수 있는지
어떤 네트워크 접근이 허용되는지
어떤 비밀 정보 (Secrets)가 마운트되는지
환경이 얼마나 오래 유지되는지
환경을 재사용할지 아니면 폐기할지

단순한 내부 도구의 경우, 가벼운 경계 (Boundary)만으로도 충분할 수 있습니다. 하지만 신뢰할 수 없거나 부분적으로만 신뢰할 수 있는 코드 실행의 경우, 더 강력한 격리가 중요합니다. 많은 팀이 결국 일회성 샌드박스 (Disposable sandboxes), 컨테이너 (Containers), 또는 마이크로 VM (MicroVM) 스타일의 경계로 이동하게 되는데, 이는 에이전트 런타임이 도구 입력값이 적대적일 수 있다고 가정해야 하기 때문입니다.

프레임워크 (Framework)는 도구를 호출할지 여부를 결정할 수 있습니다.

런타임 (Runtime)은 해당 도구가 실행될 때 어떤 일이 일어날지를 결정합니다.

리소스 제한 (Resource limits)은 제품의 기능입니다

리소스 제어 (Resource control)는 인프라의 배관 작업처럼 들릴 수 있지만, 이는 사용자 경험 (User experience)에 직접적인 영향을 미칩니다.

무한 루프를 도는 에이전트는 단순히 비효율적인 것에 그치지 않습니다. 다음과 같은 문제를 야기합니다:

예측 불가능한 비용 (unpredictable cost)
노이즈가 많은 로그 (noisy logs)
중단된 작업 (stuck jobs)
낮은 사용자 신뢰 (poor user trust)
팀을 위한 운영 부담 (operational pains for the team)

프로덕션 에이전트에는 다음과 같은 엄격한 상한선 (hard ceilings)이 필요합니다:

실행당 최대 단계 수 (max steps per run)
최대 실제 소요 시간 (max wall-clock time)
작업당 토큰 예산 (token budget per task)
CPU 및 메모리 제한 (CPU and memory limits)
동시성 제한 (concurrency limits)
중단된 작업에 대한 정리 규칙 (cleanup rules for abandoned work)

이러한 제한 사항은 프롬프트 내부의 정중한 제안이어서는 안 됩니다. 반드시 런타임 (runtime)에 의해 강제되어야 합니다.

라이프사이클 (Lifecycle): 시스템을 유지시키는 화려하지 않은 부분

모든 에이전트 실행에는 라이프사이클 (lifecycle)이 있습니다.

시작되고, 환경을 할당받고, 권한을 부여받고, 도구 (tools)를 호출하고, 상태 (state)를 기록하고, 로그를 출력하며, 완료되거나 실패한 후에는 정리되어야 합니다.

만약 런타임이 해당 라이프사이클을 소유하지 않는다면, 결국 다음과 같은 상황을 맞이하게 됩니다:

고아 프로세스 (orphaned processes)
오래된 샌드박스 (stale sandboxes)
유출된 파일 (leaked files)
혼란스러운 재시도 (confused retries)
관련 없는 작업 간에 공유되는 상태 (state shared across unrelated tasks)

좋은 기본 설정은 휘발성 실행 (ephemeral execution)입니다. 각 의미 있는 작업에 대해 깨끗한 환경을 생성하고, 이를 감독하며, 트레이스 (traces)를 수집하고, 완료되면 파괴하는 방식입니다.

이렇게 하면 실패 원인을 파악하기 쉬워지며, 보안이 침해되었거나 혼란에 빠진 하나의 실행이 다음 실행에 영향을 미칠 가능성을 줄여줍니다.

실무적인 프로덕션 체크리스트

에이전트를 프로덕션에 배포하기 전에, 저는 다음과 같은 질문을 던질 것입니다:

워커 (worker) 재시작 후에도 에이전트가 재개될 수 있는가?
호스트 비밀 정보 (host secrets)에 접근하지 않고 도구를 실행할 수 있는가?
예산, 시간, 또는 단계 수에 의해 중단될 수 있는가?
각 실행에 대해 사후에 트레이싱 (tracing)이 가능한가?
부수 효과 (side effects)를 중복시키지 않고 실패한 작업을 재시도할 수 있는가?
많은 에이전트가 상태를 실수로 공유하지 않고 동시에 실행될 수 있는가?
사용자나 운영자가 실행 중에 무슨 일이 일어났는지 이해할 수 있는가?

만약 답변이 대부분 '아니오'라면, 부족한 조각은 아마도 또 다른 프롬프트가 아닐 것입니다. 그것은 바로 런타임 레이어 (runtime layer)입니다.

SandBase의 역할

우리는 바로 이 레이어를 중심으로 SandBase를 구축하고 있습니다. 즉, 프로덕션 AI 에이전트를 구축하는 개발자들을 위한 에이전트 인프라입니다.

우리의 초점은 에이전트 워크로드 (agent workloads)를 둘러싼 런타임 인프라에 있습니다:

샌드박스화된 도구 실행 (sandboxed tool execution)
모델 라우팅 (model routing)
에이전트 애플리케이션을 위한 API (APIs for agent applications)
에이전트 워크로드를 위한 분산 컴퓨팅 (distributed compute for agent workloads)
추론 (reasoning), 도구 (tools), 실행 (execution) 간의 더 명확한 경계

논지는 간단합니다:

프로덕션 에이전트에는 프롬프트뿐만 아니라 인프라가 필요합니다.

만약 도구를 실행하고, 컴퓨팅 자원을 사용하며, 데모 환경 밖에서 안전하게 작동해야 하는 에이전트를 구축하고 있다면, 런타임 레이어 (runtime layer)를 조기에 설계할 가치가 있습니다.

원문 버전: https://www.sandbase.ai/blog/production-ai-agents-need-a-runtime-layer/