처음으로 AI 에이전트를 구축하는 거의 모든 팀에게 일어나는 순간이 있다. 데모는 아름답게 작동한다. 에이전트는 질문에 답하고, 도구를 사용하고, 컨텍스트를 기억한다. 이해관계자들에게 보여주면 감명받는다. 그리고 누군가가 묻는다: "이것을 프로덕션에 넣을 수 있나요?"
그 질문은 대부분의 팀이 과소평가하는 격차를 드러낸다. 데모 에이전트는 개발자가 지켜보는 상태에서 통제된 환경에서 한 번 작동하도록 구축된다. 프로덕션 에이전트는 아무도 지켜보지 않는 상태에서 예측 불가능한 조건에서 수천 번 작동해야 한다. 그 두 요구 사항 사이의 격차가 대부분의 AI 에이전트 프로젝트가 정체되는 곳이며——런타임 선택이 엄청나게 중요해지기 시작하는 곳이다.
데모 함정
데모 함정은 유혹적이다. 데모는 진정으로 구축하기 쉽기 때문이다. 현대 AI 프레임워크는 언어 모델을 연결하고, 몇 가지 도구를 주고, 질문에 답하게 하는 것을 간단하게 만든다. 어려운 부분은 작동하게 만드는 것이 아니다——계속 작동하게 만드는 것이다.
데모 에이전트는 보통 상태가 없다. 재시작해도 아무것도 잃지 않는다. 인증이 없다. 속도 제한이 없다. 모니터링이 없다. 오류 처리가 없다.
프로덕션은 그 가정들을 모두 벗겨낸다. 에이전트가 재시작하면 사용자는 컨텍스트를 잃는다. 인증되지 않은 사용자가 엔드포인트를 찾는다. 누군가가 1분에 1,000개의 메시지를 보낸다. 에이전트가 잘못된 답을 내놓고 아무도 이유를 모른다. AI 제공업체가 다운되고 에이전트가 우아하게 저하되는 대신 충돌한다. 이 실패 모드들 각각은 예측 가능하다——그리고 각각은 올바르게 처리하기 위해 의도적인 아키텍처 결정을 요구한다.
이 전환을 성공적으로 헤쳐나가는 팀들은 처음부터 AI 에이전트를 스크립트가 아닌 인프라로 취급하는 팀들이다.
프로덕션이 실제로 요구하는 것
첫 번째 요구 사항은 영구적이고 신뢰할 수 있는 상태다. 프로덕션 에이전트는 진행 중인 대화, 누적된 사용자 선호도, 작업 큐, 학습된 컨텍스트를 관리한다. 그 상태는 재시작에서 살아남고, 충돌에서 살아남고, 무언가가 잘못됐을 때 복구 가능해야 한다. 원자적 쓰기가 필요하다——에이전트의 컨텍스트를 손상시키는 반쯤 쓰인 메모리 항목 없음. 검사 가능해야 한다——에이전트가 예상치 못한 동작을 할 때 무엇을 알고 있었고 왜 그 결정을 내렸는지 볼 수 있도록.
ZeroClaw는 WAL 모드의 SQLite로 이것을 처리한다: ACID 컴플라이언트, 단일 파일, 전원 장애에서 살아남는다. 전체 에이전트 상태가 하나의 파일에 저장된다. 백업은 `cp memory.db memory.db.bak`다. 복원은 `cp memory.db.bak memory.db`다. 관리할 데이터베이스 서버 없음, 구성할 연결 풀 없음, 설정할 복제 없음. 에이전트가 실제로 사용하는 접근 패턴——수백만이 아닌 수천 개의 메모리——에 대해 SQLite는 분산 데이터베이스를 능가한다. 네트워크 라운드 트립이 없기 때문이다.
두 번째 요구 사항은 신뢰에 의존하지 않는 보안 모델이다. 프로덕션 에이전트는 실제 자격 증명을 처리하고, 실제 파일 시스템에 접근하고, 약점을 찾는 실제 사용자와 상호작용한다. 보안 모델은 "플러그인 개발자를 신뢰한다"거나 "사용자가 잘 행동한다고 가정한다"가 될 수 없다. 기본 거부여야 한다: 모든 도구, 모든 파일 경로, 모든 네트워크 엔드포인트는 에이전트가 접근하기 전에 명시적으로 허용되어야 한다. 감사 로그는 모든 도구 실행을 입력과 출력과 함께 기록해야 한다——무언가가 잘못됐을 때 따라갈 수 있는 추적이 있도록.
이것이 정확히 OpenClaw의 아키텍처가 2026년에 실패한 곳이다. WebSocket 신뢰 모델, OS 수준의 스킬 권한, 41.7%의 취약한 항목을 가진 플러그인 마켓플레이스는 버그가 아니었다——개발자 도구에는 의미 있었고 실제 자격 증명과 실제 데이터를 처리하는 프로덕션 인프라로 배포됐을 때 부채가 된 아키텍처 결정들이었다.
세 번째 요구 사항은 관찰 가능성이다. 에이전트가 프로덕션에서 잘못된 답을 내놓을 때 "잘못된 컨텍스트를 사용했다"는 유용한 진단이 아니다. 메시지 수신부터 응답 전달까지의 요청 추적, 대화별 및 사용자별 토큰 사용량 추적, 입력과 출력을 가진 도구 실행 로그, 각 요청에 주입된 컨텍스트를 정확히 보여주는 메모리 검색 로그가 필요하다. 이것 없이는 프로덕션 문제 디버깅이 추측이 된다——그리고 새벽 2시에 무언가가 고장났을 때의 추측은 비싸다.
신뢰성은 네 번째 요구 사항이며, "충돌하지 않는다"보다 더 미묘하다. 프로덕션은 24/7 가동 시간 기대를 의미한다——충돌 시 자동 재시작, AI 제공업체가 사용 불가능할 때 우아한 저하, 채널에 대한 지수 백오프를 가진 연결 재시도, 모니터링 시스템을 위한 헬스 체크 엔드포인트. 사용자에게 보이는 중단을 만들지 않는 콜드 스타트 시간도 의미한다. 8초에 재시작하는 에이전트는 1년 동안 합산하면 수 시간의 다운타임이 되는 사용 불가 창을 만든다. 10밀리초에 재시작하는 에이전트는 사실상 항상 사용 가능하다——사용자는 간격을 알아채지 못한다.
다섯 번째 요구 사항은 비용 제어다. 통제되지 않은 AI 에이전트는 예측하기 어려운 방식으로 토큰을 소모한다. 긴 대화를 할 수 있다는 것을 발견한 단일 사용자가 하루에 수백 달러의 API 비용을 생성할 수 있다. 프로덕션은 사용자별 및 채널별 토큰 예산, 남용을 방지하는 속도 제한, 모델 라우팅——간단한 쿼리에는 저렴한 모델, 복잡한 것에는 비싼 모델——을 요구한다. 이 제어 없이는 토큰 비용이 놀라움이 된다.
대부분의 프레임워크가 잘못하는 것
프로덕션을 위해 설계되지 않은 프레임워크 전반에서 패턴은 일관적이다: 해피 패스에 모든 주의를 기울이고 그 외 모든 것에 투자 부족이다.
오류 처리는 콘솔에 로그를 기록하는 try-catch가 된다. 재시도 로직은 독자를 위한 연습으로 남겨진다. 우아한 저하는 TODO 주석이다. AI 제공업체가 429를 반환할 때 에이전트는 백오프와 함께 요청을 큐에 넣고 재시도하는 대신 충돌한다. 이것들은 엣지 케이스가 아니다——충분히 오래 실행되는 서비스의 정상적인 운영 조건이다.
리소스 효율성은 비용 승수가 아닌 있으면 좋은 것으로 취급된다. 단일 에이전트 인스턴스에 1GB RAM을 사용하는 프레임워크는 비싼 인프라 없이 멀티 테넌트 배포로 확장할 수 없다. 각 엔터프라이즈 고객에게 전용 에이전트 인스턴스를 주고 싶다면——데이터 격리를 위해 종종 올바른 아키텍처다——인스턴스당 1GB로 수백 개의 인스턴스를 동시에 실행할 수 있는 서버가 필요하다. 인스턴스당 4MB라면 $5/월 VPS로 충분하다.
보안은 가장 일반적인 후속 조치다. 본능은 먼저 기능을 구축하고 나중에 보안을 추가하는 것이다. 하지만 보안은 허용적인 아키텍처에 나중에 추가할 수 없다——OpenClaw 위기는 이것을 대규모로 실증했다. 기본 거부, 메모리 안전성, 샌드박싱은 처음부터 설계에 내장되어야 한다. 나중에 추가하는 것은 허용적인 접근을 가정하고 구축된 것들을 깨는 것을 의미하기 때문이다.
ZeroClaw의 프로덕션 스토리
ZeroClaw는 처음부터 프로덕션을 위해 설계됐으며, 설계 결정이 그것을 반영한다. 단일 바이너리는 배포가 하나의 12MB 파일을 복사하는 것을 의미한다——의존성 해결 없음, 버전 충돌 없음, "내 머신에서는 작동한다" 없음. 4MB RAM 풋프린트는 단일 1GB VPS에서 50개의 에이전트 인스턴스를 실행할 수 있음을 의미하며, 다른 어떤 런타임으로도 전용 서버가 필요한 규모에서 멀티 테넌트 배포를 경제적으로 실행 가능하게 만든다. 10ms 미만의 콜드 스타트는 재시작이 사용자에게 보이지 않고 롤링 업데이트가 제로 다운타임을 일으킴을 의미한다.
Rust의 메모리 안전성은 컴파일 타임에 전체 취약점 클래스를 제거한다——버퍼 오버플로우, use-after-free, 데이터 경쟁은 컴파일 오류이지 런타임 놀라움이 아니다. 기본 거부 허용 목록 모델은 모든 도구, 파일 경로, 네트워크 엔드포인트가 에이전트가 접근하기 전에 config.toml에서 명시적으로 허용되어야 함을 의미한다. WAL 모드의 SQLite는 관리할 데이터베이스 서버 없이 단일 파일에 ACID 컴플라이언트 상태를 제공한다. distroless Docker 이미지는 ZeroClaw 바이너리와 필요한 인증서만 포함한다——셸 없음, 패키지 매니저 없음, 최소한의 공격 표면.
프로덕션 체크리스트
AI 에이전트를 프로덕션으로 가져가는 팀에게 체크리스트는 기능보다 운영 성숙도에 관한 것이다. 출시 전에 도구 권한을 명시적으로 정의한다——에이전트는 무엇에 접근할 수 있고, 무엇이 명시적으로 거부되는가? 청구서 놀라움을 받기 전에 사용자별 및 채널별 토큰 예산을 설정한다. 오류율과 지연 백분위수에 대한 모니터링과 알림을 설정한다. 메모리 데이터베이스의 자동 백업을 설정한다. 의도적으로 실패 시나리오를 테스트한다: AI 제공업체가 다운되면 어떻게 되는가? 채널이 연결 해제되면? 디스크가 가득 차면? 최종 사용자를 위해 에이전트의 기능과 한계를 문서화한다. 필요하기 전에 에이전트 오작동에 대한 인시던트 대응 프로세스를 수립한다.
데모와 프로덕션 사이의 격차는 운영 성숙도다. 선택하는 프레임워크는 그 성숙도가 얼마나 내장되어 있는지 대 나중에 추가되는지를 결정한다. 처음부터 프로덕션을 위해 설계된 런타임은 구축할 기반을 제공한다. 데모를 위해 설계되고 프로덕션 기능으로 나중에 추가된 런타임은 시간이 지남에 따라 복리로 증가하는 유지 관리 부담을 제공한다. 처음에 내리는 선택이 그 후의 모든 것을 형성한다.