AI 에이전트를 '써본 팀'과 '운영하는 팀' 사이의 격차는 생각보다 빠르게 벌어지고 있다. 데모에서 잘 돌아가던 에이전트가 프로덕션에서 한 주 만에 47번 크래시하고, 루프 하나가 $340짜리 API 청구서를 만들어내는 경험—이걸 겪어본 팀만이 '운영'과 '실행'이 다른 문제라는 걸 안다. 세 편의 현장 보고가 동시에 가리키는 건 바로 이 지점이다.
에이전트가 프로덕션에서 죽는 이유는 모델이 나빠서가 아니다
Nexus OS를 만든 개발자의 고백은 직설적이다. 에이전트는 네트워크 타임아웃, 레이트 리밋, 컨텍스트 윈도우 오버플로우로 계속 죽는다. 문제는 죽는 것 자체가 아니라, 죽었을 때 어떻게 되는가다. 10단계 작업의 7번째 단계에서 에이전트가 죽으면 이전 상태가 복구되는가? 비용이 어디서 얼마나 나갔는지 알 수 있는가? 대부분의 팀은 이 두 질문에 답하지 못한다.
그가 택한 해법은 40년 된 Erlang의 철학이다. "크래시를 막으려 하지 마라. 크래시가 나도 시스템이 살아남게 만들어라." Supervisor 트리로 죽은 에이전트를 자동 재시작하고, Saga 패턴으로 실패한 단계를 역순으로 보상 처리한다. 비용에는 하드 리밋을 걸고, WASM 샌드박스로 에이전트가 허가받지 않은 파일 시스템이나 네트워크에 접근하지 못하게 막는다. 이건 에이전트 로직이 아니라 인프라 설계의 문제다.
슈퍼모델 환상이 설계를 망친다
두 번째 현장은 더 근본적인 질문을 던진다. 우리는 왜 AI에게 "이해하고, 계획하고, 코딩하고, 자기 코드를 리뷰하라"를 동시에 요구하는가? 단일 에이전트가 모든 역할을 맡는 구조는 실패할 때 가장 나쁜 방식으로 실패한다. 틀렸다고 말하는 게 아니라, 그럴듯하게 말한다.
이 글이 제시하는 대안은 구조다. Intake → Triage → Specialist → Verification → Escalation이라는 레이어가 있을 때, 각 구성 요소는 더 좁은 책임을 더 일관되게 수행한다. 단순한 작업은 빠르고 저렴하게, 고위험 작업은 검증 레이어를 거쳐 처리된다. 에이전트가 자기 출력을 스스로 검증하는 패턴—가장 흔하고 가장 위험한 패턴—을 구조적으로 깨는 것이다. "가장 스마트한 시스템은 가장 큰 모델을 쓰는 시스템이 아니라, 언제 무엇을 쓸지 아는 시스템"이라는 명제가 여기서 나온다.
멀티 프로젝트 운영은 봇이 아니라 라우터가 필요하다
Claude Code를 주력 도구로 쓰는 개발자가 만든 Oh My Team은 더 실용적인 문제를 다룬다. Claude Code의 채널 시스템은 기본적으로 1봇 1터미널이다. 터미널을 닫으면 세션이 죽고, 프로젝트가 세 개면 봇도 세 개가 필요하다. 세션 관리도, 라우팅도, 퍼시스턴스도 없다.
해법은 Claude Code 채널 프로토콜 위에 라우터를 얹는 것이었다. Telegram 포럼 토픽이나 Slack 스레드를 각 프로젝트 세션의 독립된 채널로 매핑하고, tmux로 세션을 영속화한다. 노트북을 닫아도 세션은 살아있고, 폰에서 메시지를 보내면 해당 프로젝트의 Claude 세션에 라우팅된다. 각 프로젝트 세션은 컨텍스트를 공유하지 않으므로 토큰 비용이 배수로 늘지도 않는다.
이 구조에서 특히 주목할 부분은 멀티 에이전트 리뷰 패턴이다. /oh-my-team:review-work를 실행하면 목표 검증, QA, 코드 품질, 보안, 컨텍스트 마이닝을 담당하는 5개의 독립 에이전트가 동시에 코드를 리뷰한다. "에이전트는 자기 출력을 객관적으로 평가할 수 없다"는 명제에 대한 실용적 답변이다.
팀 리드에게 실질적으로 의미하는 것
세 현장을 묶으면 AI-First 팀이 에이전트를 인프라로 운영할 때 필요한 설계 결정 세 가지가 나온다.
첫째, 세션 라우팅과 퍼시스턴스. 멀티 프로젝트 환경에서 에이전트를 운영하려면 세션 생애주기 관리가 필수다. 봇을 늘리는 것이 아니라 라우터를 설계해야 한다.
둘째, 장애 복구를 설계에 포함할 것. 에이전트는 크래시한다. 이걸 전제로 Supervisor, Saga, 비용 리밋을 처음부터 넣어야 한다. 나중에 붙이는 건 이미 늦다.
셋째, 검증은 생성과 분리된 레이어여야 한다. 같은 에이전트가 쓰고 읽는 구조는 신뢰할 수 없다. 역할이 분리된 전문 에이전트가 독립적으로 검증할 때 품질 게이트가 의미를 가진다.
지금 시작해야 할 이유
에이전트를 실행하는 팀과 인프라로 운영하는 팀 사이의 격차는 지금 이 순간에도 벌어지고 있다. 데모 수준의 에이전트는 누구나 띄울 수 있다. 차이는 그 에이전트가 크래시했을 때 시스템이 살아남는가, 비용이 통제되는가, 다른 에이전트가 그 출력을 검증하는가에 있다.
흥미로운 건 이 세 가지 해법 모두 AI 기술 자체의 발전이 아니라, 소프트웨어 엔지니어링에서 수십 년간 검증된 패턴—Supervisor 트리, Saga 패턴, 역할 분리, 독립 검증—을 에이전트 레이어에 적용한 결과라는 점이다. 에이전트 인프라를 새로 발명할 필요는 없다. 우리가 이미 아는 것을 적용하면 된다. 모르는 척하고 있었을 뿐이다.