원문 캡처 · unreallabs.ai
원문 캡처 · unreallabs.ai

Unreal Labs는 지난 1년간 클라우드 에이전트를 구축하고 운영하며 얻은 인프라 설계 경험을 정리했다. 에이전트별 요구에 맞춰 샌드박스, 저장소, 인증 정보 관리, 메시징, 실행 환경을 조합하는 방식을 설명하고, 운영 과정에서 겪은 SDK 호환성 문제도 소개했다.

클라우드 에이전트는 실행 환경이 원격에 있고 사용자의 로컬 컴퓨터에서 돌아가는 프로세스와 독립적으로 작동하는 에이전트를 뜻한다. Meta Muse, Claude Tag, OpenAI Codex Cloud, Sierra, ElevenLabs Agents, Higgsfield Supercomputer 등이 사례로 제시됐다. Unreal Labs는 기업이 각자의 용도와 보안 요구에 맞는 에이전트를 직접 구축하고 배포할 수 있어야 한다고 본다.

에이전트 실행 환경과 데이터 관리

여러 사용자가 에이전트를 이용한다면 각 에이전트의 작업 공간을 분리해야 한다. Unreal Labs는 이를 위해 샌드박스를 사용한다고 설명한다. 에이전트 하네스를 샌드박스 안팎 어디에 둘지 고려해야 하며, 하네스가 밖에 있는 경우 샌드박스를 일시 중지할 수 있는지도 살펴볼 만하다. Firecracker 마이크로VM 기반 샌드박스는 일시 중지가 가능한 경우가 있으며, 작업 부하에 따라 추론 중 샌드박스를 멈춰 실행 비용을 줄일 수 있다.

샌드박스의 공간은 임시일 수 있으므로 조직의 맥락, 기술, 장기 기억은 에이전트가 다시 시작될 때도 이용할 수 있어야 한다. 파일 저장 방식으로는 영구 볼륨과 S3 스냅샷이 있으며, Unreal Labs는 내부 배포에서 NFS로 하위 디렉터리를 마운트하는 방식도 유용하다고 본다. 이들은 저장 공간을 읽기용 대형 캐시이자 쓰기용 스테이징 공간으로 활용한다. 샌드박스 준비를 빠르게 하고, 마운트와 권한으로 에이전트 작업 공간을 기본적으로 분리한다.

대화형 에이전트에는 이전 메시지 기록이 필요할 수 있다. Unreal Labs는 메시지 기록을 읽기 전용 디렉터리로 제공해 에이전트가 내용을 참고하되 원본 기록은 바꾸지 못하게 한다. 대화 기록의 기준 데이터는 데이터베이스에 둔다.

에이전트의 장기 기억을 누가 관리할지도 설계해야 한다. 관리자가 에이전트가 쓸 문서를 정하고 관리하는 방식이 있는가 하면, 에이전트가 과거 작업을 바탕으로 스스로 기억을 갱신하는 방식도 있다. 후자의 경우 별도의 백그라운드 에이전트가 로그와 기존 기억을 검토해 조직의 공유 기억을 갱신할 수 있다. 이런 과정을 흔히 ‘드리밍’이라고 부르지만, Unreal Labs는 과거 경험을 되돌아보고 학습한 내용을 정리한다는 의미를 담아 ‘명상’이라는 이름을 선호한다고 밝혔다.

인증 정보와 메시지 처리

에이전트는 Google Drive 같은 외부 서비스나 CMS 같은 내부 서비스에 접근해야 할 수 있지만, 계정 비밀번호나 토큰을 에이전트에 직접 넘기면 안 된다. Unreal Labs가 설명한 송신 프록시는 샌드박스에서 나가는 모든 트래픽을 거친다. 요청 목적지를 확인하고 필요한 인증 정보를 추가하거나, 허용되지 않은 목적지로 가는 요청을 차단하고 요청 본문을 살펴보거나 수정할 수 있다.

인증 정보의 관리와 저장은 프록시와 분리하는 편이 낫다고 Unreal Labs는 설명한다. 프록시는 각 요청에 필요한 인증 정보를 자격 증명 브로커(Credential Broker)에서 가져오며, 브로커는 요청자가 해당 유형의 호출을 할 권한이 있는지 확인한다. 인증 정보는 요청이 샌드박스를 벗어난 뒤 추가되므로 에이전트가 이를 직접 다루지 않는다.

자격 증명 브로커는 계정 연결, 연결 사용 권한, 해당하는 경우 인증 토큰 갱신을 관리한다. Slack 통신 등 다른 서비스도 같은 계정 연결을 쓸 수 있으므로, 전용 브로커를 두면 여러 구성 요소가 연결과 접근 규칙을 공유하면서 각자 인증 정보를 관리하는 일을 피할 수 있다. API 키와 토큰 저장소로는 Linux Foundation의 Vault 포크인 OpenBao를 사용해 왔으며, Unreal Labs는 이를 안정적이고 배포·관리가 쉽다고 평가했다. 계정을 연결한 사람, 연결 상태, 인증 정보의 저장 위치는 별도로 추적하며, 이 기록은 Postgres에 보관한다고 설명했다.

메시징 게이트웨이는 Slack, iMessage, Telegram, WhatsApp, 내부 채팅, Instant Bloomberg 등 여러 서비스에 공통 인터페이스를 제공한다. 에이전트의 주의가 필요한 수신 메시지를 오케스트레이터로 전달하고, 응답을 지정된 채널이나 스레드에 보내기 전에 목적지가 존재하는지 확인한다. 조직이나 사용자별 대화를 저장하고 불러오며, 에이전트가 메시지를 보낼 수 있는 채널도 제한한다.

오케스트레이션과 인터페이스

메시지가 도착했을 때 에이전트가 쉬고 있거나 이미 작업 중일 수 있고, 실행 중인 샌드박스가 없을 수도 있다. 에이전트 오케스트레이터는 환경을 준비하고 실행을 관리하며, 에이전트가 준비되면 대기 중인 메시지를 전달한다. 필요한 파일과 서비스에 접근할 수 있도록 샌드박스를 만들고, 에이전트의 실행을 시작해 수명 주기를 관리한다. 실행 추적 정보를 저장하고 대화 출력을 실시간으로 전달하며, 예약 실행과 실행 상태를 관리하고 유휴 샌드박스를 정리한다.

수신 메시지는 대기열을 거친다. 에이전트가 작업 중에도 새 요청을 받을 수 있고, 후속 지시나 공유 채널의 여러 사용자 메시지를 에이전트가 준비된 뒤 차례로 전달할 수 있다. 어떤 메시지를 대기열에 넣을지는 메시징 게이트웨이가 결정한다.

별도의 채팅 인터페이스는 선택 사항이다. Slack 같은 메시징 서비스만으로 이용하는 에이전트도 있고, 웹이나 모바일 앱에 자체 인터페이스가 필요한 에이전트도 있다. 후자의 경우 오케스트레이터가 대화 출력을 저장하고 실시간 갱신을 전달해, 사용자가 대화를 다시 열고 결과를 확인하며 메시지와 도구 호출, 추론 과정을 따라갈 수 있게 한다.

웹 채팅 배포에서는 PostgreSQL이 대화 기록을 지속적으로 저장하고, Redis Streams가 진행 중인 대화와 실시간 갱신을 처리한다. Unreal Labs는 웹 인터페이스를 만드는 데 assistant-ui가 적합했다고 설명했다. 외부 저장소 런타임을 이용하면 애플리케이션 자체 백엔드에 연결할 수 있으며, 메시지 형식도 서로 다른 클라이언트 요구에 맞게 조정할 수 있다고 덧붙였다.

하네스와 SDK의 운영상 과제

하네스는 모델을 호출하고 도구를 실행하며 대화 상태를 유지하는 에이전트 실행 루프다. 인프라는 하네스를 통해 도구를 실행하고 진행 상황을 보고받는다. Anthropic은 Claude Agent SDK를, 오픈AI는 OpenAI Agents SDK와 Codex SDK를 제공한다.

Unreal Labs는 이 SDK들이 계속 바뀌고 있어 버전과 모델 변경, 새 기능에 맞춰 통합을 유지하는 작업이 필요하다고 밝혔다. 경험한 문제로는 모델 호환성, 모델과 실행 환경 간 버전 불일치, 도구 제한 설정이 꼽혔다. 예를 들어 Fireworks의 Anthropic 호환 엔드포인트에서 Kimi K3를 실행했을 때 도구 호출 ID가 충돌했다. Unreal Labs의 직접 테스트에서는 도구 실행이 성공했는데도 ID 재사용으로 Claude Code가 이후 모델 요청의 결과를 버리는 일이 나타났다. API가 호환된다고 하네스까지 호환되는 것은 아니라는 설명이다.

새 모델이 오래된 하네스나 SDK와 잘 작동하지 않아 업그레이드가 필요할 수 있고, 업그레이드 과정에서 통합 방식도 바뀔 수 있다. Unreal Labs는 백그라운드 작업에서 조기 종료와 멈춤을 막기 위해 새로운 완료 처리 로직이 필요했던 사례를 들었다. 또 Claude Agent SDK에서 AskUserQuestion 도구를 막았지만 계획 도구의 지침은 여전히 해당 도구를 호출하라고 안내해, 모델이 거부되는 도구 호출을 시도할 수 있었다고 밝혔다. 이 경우 토큰과 비용이 낭비될 수 있다.

Unreal Labs는 SDK가 오픈소스이며 Claude Agent SDK에 여러 수정 사항을 기여했다고 밝혔다. 자체 하네스 설계 구상과 이런 운영 경험을 바탕으로 Unreal Agent를 개발했으며, 자세한 내용은 Unreal Agent 소개 글에서 확인할 수 있다. 회사는 모든 에이전트에 동일한 인프라가 필요한 것은 아니며, 유연하고 재사용 가능한 구성 요소가 용도별 구축을 돕는다고 주장한다.

원문의 사례는 설명을 위한 것이며 제품 추천이나 광고가 아니다. 샌드박스 논의에서는 컴퓨터 형태의 에이전트 환경을 전제로 한다.