에이전트 데모는 쉽다. 유튜브 영상 5분, 트위터 스레드 몇 줄이면 된다. 그런데 그 에이전트를 30일 동안 실제 워크로드에 붙여두면 어떤 일이 벌어지는가. dev.to에 올라온 한 실전 사례가 이 질문에 꽤 냉정한 답을 내놓았다. 6시간마다 고객 지원 이메일 200건을 분류하고 답장 초안을 뽑아내는 에이전트—120회 스케줄 실행 중 117회 정상 완료, 사람이 개입한 횟수는 단 3번, 총 10분. 이 숫자가 가능했던 이유는 모델이 좋아서가 아니었다.
핵심 이슈: 모델이 아니라 '지루한 엔지니어링'이 에이전트를 살린다
사례에서 에이전트가 처음 죽은 건 4일 차였다. 이메일 300건을 한꺼번에 메모리에 올리다 컨테이너가 OOM으로 날아갔다. 원인은 단순했다—에이전트를 스크립트처럼 짰다. "전부 읽고, 전부 처리하고, 전부 쓴다." 장기 실행 프로세스에는 이 패턴이 치명적이다. 수정은 간단했다: N건씩 배치로 나누고 항목마다 커밋 포인트를 찍는다. 47번째 항목에서 죽어도 다음 실행은 48번부터 시작된다. 9일 차엔 모델 타임아웃 하나가 무한 재시도 루프에 빠져 하룻밤에 $40 청구서를 냈다. 수정: 지수 백오프 + 3회 상한 + 데드레터 큐. "에이전트가 조용히 실패"에서 "에이전트가 시끄럽게 실패"로 바꾸는 것이 핵심이었다.
14일 차엔 더 미묘한 문제가 나왔다. 에이전트가 오래된 주문 정보를 참조하며 엉뚱한 답장을 쓰기 시작했다. 컨테이너 재시작 때 인메모리 캐시가 날아가면서 상태가 어긋났다. 결론은 한 문장으로 요약된다: 인메모리 상태는 거짓말이다. 다음 추론 호출 전에 Postgres에 써놓지 않은 정보는 없는 것과 같다. kill -9 사이 어느 줄에서 죽어도 살아남을 수 있어야 장기 실행 에이전트다. 그렇지 않으면 그건 장기 실행 프로토타입이다.
맥락 해석: 상태 관리는 끝이 아니라 시작이었다
상태를 Postgres로 빼는 것까지는 팀에서 구현 가능한 범위다. 그런데 에이전트가 학습한 것, 기억한 것, 판단 근거로 삼은 것—이른바 '에이전트 메모리'는 어떻게 관리해야 하는가. 여기서 두 번째 설계 숙제가 시작된다.
같은 dev.to 커뮤니티에서 나온 다른 글이 이 문제를 정확하게 짚었다. 에이전트 메모리를 단순히 "더 많이 기억하는" 문제로 보는 한, 거버넌스는 없다. 메모리가 영속 상태가 되는 순간 그것은 더 이상 편의 기능이 아니다. 그것은 엔지니어링 프로세스의 일부가 된다. 잘못된 메모리 하나가 다음 작업, 다음 브랜치, 다음 리뷰를 조용히 오염시킨다. 더 나쁜 건 아무도 모른다는 점이다.
이 글이 제안하는 체크리스트는 화려하지 않다. 메모리는 검사 가능해야 하고, 수정 가능해야 하고, 출처가 있어야 하고, 이식 가능해야 하고, 권한이 있어야 하고, 정리 가능해야 한다. 벡터 서치 품질 문제가 아니다. 검색이 과거 메모리를 찾아낼 수는 있어도, 그게 지금도 맞는 정보인지는 판단하지 못한다. 임시 워크어라운드가 영구 아키텍처 원칙으로 굳어지는 것, 새벽 2시 디버깅 세션에서 나온 반쪽짜리 코멘트가 요구사항으로 기억되는 것—이걸 막으려면 메모리 쓰기를 코드 변경처럼 다뤄야 한다. 에이전트가 세션을 끝낼 때 제안한 메모리 항목을 사람이 검토하고, 승인하거나 거부하거나 범위를 조정하는 흐름. 거창한 PR 의식이 필요한 게 아니라, 영속 메모리가 조용히 미래 동작을 바꾸면 안 된다는 원칙이다.
운영 범위 설계: Codex의 확장이 던지는 질문
세 번째 숙제는 조금 다른 방향에서 온다. OpenAI가 Codex 활용 사례를 기존 12개에서 52개로 대폭 확장했다. 코딩 보조에서 시작해 이제는 Gmail 받은편지함, 재무 모델링, QA, 신규 입사자 온보딩, Computer Use(Mac 앱 직접 조작)까지 뻗어나갔다. 엔지니어링 팀만의 도구가 아니라 전사 팀이 일감을 위임하는 플랫폼으로 포지셔닝이 이동했다.
이게 팀 리드에게 의미하는 바는 명확하다. 에이전트의 운영 범위를 팀이 먼저 정의하지 않으면, 도구가 알아서 범위를 넓힌다. Computer Use로 Mac 앱을 조작하고, Slack 스레드에서 코드 작업을 시작하고, 이메일 답장 초안을 쓰는 에이전트—각각은 유용하지만 거버넌스 없이 조합되면 누가 무엇을 승인했는지 알 수 없는 자동화가 된다. 30일 사례에서 19일 차에 드러난 교훈—"비기술 운영자가 혼자 돌릴 수 없었다"—은 단순한 UX 문제가 아니었다. 운영 환경 자체가 제품이어야 한다는 신호였다.
시사점: AI-First 팀이 지금 당장 잠가야 할 세 개의 설계 포인트
세 사례를 하나로 묶으면 다음 세 가지로 압축된다.
첫째, 상태 관리는 인프라 설계다. 배치 + 커밋 포인트 + 데드레터 큐는 지루하지만 생략할 수 없다. 이게 없으면 에이전트는 프로덕션이 아니라 운이 좋은 데모다.
둘째, 메모리 거버넌스는 코드 리뷰와 같은 무게다. 영속 메모리는 편의 기능이 아니라 엔지니어링 상태다. 출처 추적, 수정 가능성, 만료 정책 없이 메모리를 쌓으면 아무도 리뷰하지 않는 숨은 팀원이 생긴다.
셋째, 운영 범위는 팀이 먼저 선언해야 한다. 도구가 할 수 있는 것과 팀이 허용하는 것은 다르다. 에이전트가 건드릴 수 있는 시스템, 사람이 반드시 검토해야 하는 결정, 자동화가 멈춰야 하는 지점—이걸 AGENTS.md나 운영 가이드에 명시하지 않으면 범위는 기능 업데이트마다 조용히 늘어난다.
전망: 에이전트 경쟁은 프롬프트가 아니라 운영 레이어에서 갈린다
30일 실전 사례가 마지막에 남긴 문장이 있다. "에이전트는 모델이 나빠서 실패하지 않는다. 지루한 것들을 아무도 연결하지 않아서 실패한다." 이건 팀 리드가 들을 말이기도 하다. 다음 18개월 동안 에이전트 시장을 가르는 건 더 영리한 프롬프트가 아니다. 체크포인팅, 데드레터, 메모리 거버넌스, 운영 범위 선언—이 지루한 레이어를 제품으로 묶어서 배포할 수 있는 팀이다. 그리고 그 레이어를 직접 운영하고 싶지 않다면, 관리형 런타임이 관리형 Postgres처럼 당연해지는 세상도 멀지 않았다. 선택은 각 팀이 해야 하지만, 선택을 미루면 에이전트가 대신 결정한다.