사전 실행 환경을 넘어: AI 에이전트를 위한 영속적인 런타임 구축

[http://www.youtube.com/watch?v=WFyFCFC15dE]

이 발표의 제목은 《Beyond Sandboxes: Architecting Durable Runtimes for AI Agents》 (사전 실행 환경을 넘어: AI 에이전트를 위한 영속적인 런타임 구축)이며, 연사는 Orkes의 공동 창립자이자 CTO인 Virein Baraiya입니다.

발표의 핵심 관점은 다음과 같습니다: 프로덕션 환경에서 AI Agent를 운영할 때, 단순히 '사전 실행 환경(Sandbox)'에 의존하는 것만으로는 충분하지 않으며, 에이전트의 상태가 영속화되고, 충돌 후 복구 가능하며, 과정이 감사 가능한 '영속적인 런타임(Durable Runtime)'이 필요하다.

다음은 발표의 핵심 내용 요약입니다:

1. 핵심 문제점: 왜 전통적인 '사전 실행 환경'과 '메모리 루프'는 부족한가?

전통적인 Agent 개발은 보통 Agent를 메모리 루프(LLM in the loop) 내에서 작동하는 개체로 간주합니다: LLM이 상태를 관찰 $
ightarrow$ 도구 호출을 결정 $
ightarrow$ 상태 업데이트 $
ightarrow$ 순환 계속 08:45. 하지만 이러한 방식은 프로덕션 환경에서 거대한 결함을 안고 있습니다:

장기 주기 작업 대응 불가: Agent가 며칠, 몇 주 동안 실행되어야 하거나 '인간 개입(Human-in-the-loop)' 단계(예: 승인 대기 또는 사용자 문서 제출)를 포함하는 경우, 전체 프로세스를 마이크로 가상 머신이나 사전 실행 환경에 걸어두는 것은 CPU와 메모리 자원을 크게 낭비합니다 05:54.
충돌 복구 능력 부족 (Crash Recovery): 전통적인 메모리 루프는 프로세스가 충돌(예: 네트워크 시간 초과, 시스템 정전)한 후, 메모리에 있던 상태와 컨텍스트가 모두 손실되어 중단점에서 정확하게 복구할 수 없습니다 07:38, 09:10.
다중 Agent 협업 복잡성: 사전 실행 환경에서 작동하는 Agent들이 서로 통신할 때는 복잡한 IP 주소 지정, 재시도 로직 등의 접착 코드(glue code)를 처리해야 합니다 06:26.

2. 핵심 아키텍처 사상: '추론'과 '실행' 분리하기

발표자는 Agent의 초점을 분리해야 한다고 제안합니다 04:32:

사전 실행 환경은 '실행(Actions)' 보호용: Agent가 생성한, 안전 위험이나 버그를 포함할 수 있는 도구 코드를 실행하는 데만 사용되어야 합니다.
영속화 프레임워크는 '추론(Reasoning)' 오케스트레이션용: LLM은 계획을 제시하는 역할에만 집중해야 합니다 (예:

Netflix Conductor (마이크로서비스 워크플로 엔진): 이는 발표자 팀이 Netflix 재직 시절 개발한 것(현재는 Orkes에서 유지 관리)입니다. 이는 지속 가능한 기반(Persistence Base)으로서, 데이터베이스(예: Postgres, Redis)를 통해 에이전트(Agent) 실행의 모든 단계(LLM 호출, 도구 호출, 상태 전이, 사용자 입력)를 원장(Ledger)에 기록합니다 12:28, 15:03.
온디맨드 일시 중단 (On-demand Suspension): 사람의 개입이나 장기적인 대기가 필요한 경우, 워크플로(Workflow)는 일시 중단되어 모든 CPU와 메모리를 해제합니다. 이후 다음 이벤트가 발생하여 깨어날 때까지 실행을 멈추며, 심지어 6개월이 지난 후에도 계속해서 이어갈 수 있습니다 18:03, 19:11.
Agent Span (Agent 런타임): Conductor 위에 구축된 에이전트 전용 런타임입니다. 이는 컴파일러와 같은 역할을 하여, 현재 시장의 주류인 11가지 에이전트 SDK(예: LangGraph, OpenAI Agents, Vercel AI SDK 등)로 정의된 에이전트를 비즈니스 코드를 수정하지 않고도 Conductor의 지속 가능한 워크플로 실행으로 직접 변환할 수 있습니다 14:09, 23:34.

IV. 핵심 가치

결정론적 가드레일 (Deterministic Guardrails): 가드레일은 LLM이 호출 여부를 결정하게 두는 것이 아니라 프레임워크 계층에서 강제적으로 제어합니다. 이를 통해 LLM이 환각(Hallucination)으로 인해 보안 검사를 우회하는 것(예: 데이터베이스 오삭제)을 방지합니다 10:05.
전수 감사 및 재생 (Full Audit & Replay): 몇 달이 지난 후라도 컴플라이언스 부서에서 특정 에이전트가 왜 그런 결정을 내렸는지 감사하고자 할 때, 개발자는 전체 실행 기록을 확인할 수 있습니다. 심지어 LLM을 모킹(Mock)하는 방식으로 전체 실행 과정을 "재생(Replay)"할 수도 있습니다 19:34, 24:17.
더 효율적인 테스트 및 평가 (Eval): 특정 단계의 LLM 출력을 변경하여 후속 도구 체인(Toolchain)과 비즈니스 로직의 흐름을 관찰할 수 있으므로, 에이전트 테스트의 결정론적 성격을 높일 수 있습니다 20:13.

V. 도입 권장 사항 및 기술적 해자 (Moat)

발표자는 마지막으로 몇 가지 실무적인 조언을 제공했습니다 21:56:

도구의 멱등성 (Idempotency): 시스템이 최소 한 번 전달(At-least-once delivery) 방식의 큐를 사용하므로, 비멱등적 도구(예: 송금)의 재시도 로직을 처리할 때 주의해야 합니다.
컨텍스트 부패 (Context Rot): 에이전트의 루프 횟수가 증가함에 따라 원장과 컨텍스트가 급격히 팽창합니다. 복잡한 에이전트를 여러 개의 **하위 에이전트 (Sub-agents)**로 분리하여, 각 하위 에이전트가 자신과 관련된 국소적 컨텍스트(Local Context)만을 유지하도록 하는 것을 권장합니다 22:58.
기업의 진정한 해자 (The Moat): 파운데이션 모델(예: OpenAI, Anthropic)은 끊임없이 반복 발전하며 일부 외부 프로세스를 내재화할 수도 있지만, 기업 고유의 **비즈니스 컨텍스트 (Business Context)**는 결코 가져갈 수 없습니다. 지속 가능한 런타임을 통해 포착된 기업 고유의 비즈니스 실행 프로세스와 의사결정 컨텍스트야말로 AI 시대에 기업이 가질 수 있는 진정한 장벽입니다 24:45.

Conductor와 Agent Span에 대한 쉬운 설명

Conductor와 Agent Span의 관계를 이해하기 위해 쉬운 비유를 들어보겠습니다.

대규모 언어 모델(Agent)을 "매우 똑똑하지만 기억력이 매우 나빠서 언제든 건망증이 생길 수 있는 탐정"이라고 상상해 보세요. 탐정은 사건을 해결할 때 전문가에게 자주 전화를 걸어야 하고(LLM 호출), 파일을 뒤져봐야 하며(도구 호출), 심지어 상사의 승인을 기다려야 할 때도 있습니다(인간의 개입).

이때 강연에서 언급된 두 오픈소스 프로젝트는 서로 다른 역할을 수행합니다.

1. Netflix Conductor: 지치지 않는 "서기"이자 "시간 정지 장치"

전통적인 방식은 탐정이 사건을 조사하면서 동시에 머릿속으로 진행 상황을 기억하는 것이었습니다. 만약 중간에 탐정이 갑자기 "쓰러진다면" (프로그램 충돌, 네트워크 단절), 사건은 처음부터 다시 조사해야 합니다.

핵심 기능 (장부 메커니즘): Conductor는 탐정에게 그림자처럼 따라다니는 "서기"를 붙여주는 것과 같습니다. 탐정이 말을 한마디 할 때마다, 전화를 한 번 걸 때마다, 파일 한 페이지를 넘길 때마다 서기는 이를 작은 수첩(데이터베이스)에 꼼꼼히 기록합니다. 설령 탐정이 갑자기 쓰러지더라도, 새로운 탐정이 와서 수첩을 펼쳐보면 즉시 이전 단계부터 조사를 이어갈 수 있어 시간을 전혀 낭비하지 않습니다.
필요 시 일시 중단 (시간 정지): 사건 처리 과정에서 탐정이 서류 승인을 기다려야 하는데 상사가 휴가를 떠났다고 가정해 봅시다. 탐정을 사무실에서 계속 기다리게 한다면, 회사는 매일 그에게 높은 급여를 지급해야 합니다 (서버의 CPU와 메모리를 낭비함). Conductor가 있다면, 서기는 탐정을 즉시 "현장에서 사라지게" 하여 (모든 계산 자원을 해제) 사건을 봉인해 둡니다. 6개월 후 상사가 휴가에서 돌아와 서명하는 순간 (깨우기 이벤트 트리거), 서기는 사건 파일을 탁 하고 다시 열고, 탐정은 즉시 "부활"하여 서명을 기다리던 그 찰나의 순간부터 정확히 업무를 재개합니다. 이 기간 동안 회사의 자원은 단 한 푼도 소모되지 않습니다.

2. Agent Span: 고급 "동시통역사" (번역가)

탐정(Agent)에는 많은 유파가 있습니다. 어떤 탐정은 영어를 쓰고(LangGraph 프레임워크로 작성됨), 어떤 탐정은 프랑스어를 씁니다(OpenAI SDK로 작성됨). 그들이 사건을 해결하는 방식은 제각각입니다. 반면 서기인 Conductor는 보수적인 성격이라, 매우 엄격하고 공장 생산 라인 같은 "표준 공문" (Deterministic Workflow)만을 이해할 수 있습니다.

핵심 기능 (컴파일러/런타임): Agent Span은 "슈퍼 동시통역사"입니다. 당신은 탐정에게 보수적인 서기와 소통하는 법을 억지로 배울 필요가 없습니다 (기존의 Agent 비즈니스 코드를 수정할 필요가 없음). 시중에 나와 있는 어떤 주류 프레임워크(예: LangGraph 또는 OpenAI 공식 SDK)를 사용하여 Agent를 작성하더라도, Agent Span이 밑단에서 탐정이 내뱉는 기상천외한 추론과 아이디어들을 보수적인 서기가 이해할 수 있는 "표준 공문"으로 자동 번역하여, 서기가 이를 기록하고 실행할 수 있도록 전달합니다.

요약하자

Conductor는 Agent의 프로덕션 환경에서의 "생존 문제"를 해결합니다. 메모 기록과 고차원 절전 모드를 통해 Agent 작업이 중단되지 않고, 비용은 낮게 유지하며, 언제든 추적 가능하도록 보장합니다.
Agent Span은 Agent의 "적응 문제"를 해결합니다. 가장 유행하는 방식으로 Agent를 작성하면서도, 코드를 재구조화하는 고통 없이 Conductor가 제공하는 강력한 안정성을 매끄럽게 누릴 수 있게 해줍니다.