6개월간 마케팅 에이전시를 AI 에이전트 14개로 돌린 팀의 회고가 dev.to에 올라왔다. 파이프라인, 인박스, 콜센터, 프로젝트 관리, 광고 분석까지 담당하는 에이전트 군단이다. 읽으면서 든 첫 생각은 '이건 AI 도구 자랑이 아니라 팀 설계 문제구나'였다. 거기에 Claude Code 에이전트 워크플로우의 컨텍스트 관리 프레임워크, 그리고 실제 SDLC를 평가하는 Ship-Bench 벤치마크까지 엮으면 그림이 더 선명해진다.
에이전트가 망가지는 패턴은 세 가지로 수렴된다
프로덕션에서 AI 에이전트가 고장 나는 방식은 의외로 단순하다. 책임이 겹치거나, 상태가 꼬이거나, 컨텍스트가 죽는다. 이 세 가지 실패 패턴을 이해하면 살아남은 규칙들이 왜 그 형태를 갖췄는지 자연스럽게 납득된다.
규칙 1: 에이전트 하나에 역할 하나
14개 에이전트 운영 사례에서 가장 먼저 나오는 규칙이다. 에이전트 하나에 두 가지 책임을 주는 순간 책임 소재가 사라진다. 어떤 에이전트가 문제를 일으켰는지 추적이 안 되고, 격리도 안 된다. 이 팀은 각 에이전트마다 OWNS 리스트와 DOES NOT OWN 리스트를 명시적으로 정의했다. 모호함 없이.
팀 리드로서 공감이 크다. 마이크로서비스를 설계할 때 단일 책임 원칙을 지키는 이유와 정확히 같다. 에이전트도 결국 경계가 명확해야 장애 반경(blast radius)이 통제된다.
규칙 2: 사전 계산된 공유 상태
두 에이전트가 동일한 API를 다른 시점에 호출하면 데이터가 엇갈린다. 이 팀의 해법은 단순하다. 모든 데이터 소스는 파일에 쓰고, 오케스트레이터는 파일만 읽는다. 스캐너는 마크다운 파일로 출력하고, 아침 오케스트레이터는 컴파일 타임에 10개 파일을 읽는다.
모니터링도 마찬가지다. ls -la로 파일이 18시간 이상 갱신되지 않으면 해당 에이전트가 죽은 거다. Prometheus 없이. 이 단순함이 실제로 돌아가는 시스템의 특징이다. 복잡한 관찰성 스택을 쌓기 전에 파일 타임스탬프 하나로 충분할 수 있다.
규칙 3: 에이전트 메시지 버스와 CHALLENGE 타입
에이전트들이 인간을 거치지 않고 서로 소통해야 할 때 쓰는 파일 기반 인박스다. 메시지 타입은 다섯 가지: REQUEST, INFORM, PROPOSAL, RESPONSE, CHALLENGE.
CHALLENGE가 핵심이다. 세일즈 에이전트가 이탈 위험 고객에게 업셀을 제안하면, 리텐션 에이전트가 증거를 첨부해 이의를 제기한다. 설계상 리텐션이 항상 이긴다. 이 규칙은 세일즈 에이전트가 만족도가 떨어지는 고객에게 업셀을 제안해 하마터면 계약이 날아갈 뻔한 실제 사고 이후에 만들어졌다.
규칙 4: 자율성은 검증 이후에 번다
에이전트는 플래그를 세우고 추천만 한다. 결정은 인간이 한다. 자율성은 검증된 결과가 쌓인 뒤에 부여된다. 세일즈 에이전트 Dirk는 30일 무수정 후에 콜드 아웃리치 자율권을 얻었다. 콜센터 에이전트 Arin은 일관된 정확도를 증명한 뒤 자율 코칭 DM 권한을 얻었다.
에스컬레이션 사다리에도 이빨이 있다. 24시간 알림, 48시간 DM, 72시간 경고, 72시간 초과 시 제안 액션과 함께 자동 에스컬레이션. 루프가 무한히 멈춰있는 상태를 허용하지 않는다.
규칙 5·6: 격리와 학습 캡처
에이전트 하나를 튜닝했을 때 다른 에이전트가 깨진다면 아키텍처가 잘못된 거다. 각 에이전트는 자체 설정, 자체 출력 파일, 자체 툴을 갖는다. 그리고 인간이 수정할 때마다 그 수정이 구조화된 클레임으로 저장되고, 모든 에이전트가 실행 전에 해당 클레임을 조회한다. 광고 분석 에이전트에 내린 수정 하나가 광고 데이터를 만지는 모든 에이전트에 즉시 적용된다.
컨텍스트 관리 없이는 에이전트 자체가 불가능하다
Claude Code Manila 밋업에서 발표된 프레임워크(dev.to)는 이 문제를 정면으로 다룬다. LLM은 컨텍스트 윈도우의 40%를 넘어가면 추론 능력이 눈에 띄게 저하된다. 이른바 'context rot'이다. Claude Code는 85%에서 자동으로 컨텍스션을 압축하는데, 압축된 요약이 또 압축되다 보면 그 요약 자체가 컨텍스트 윈도우의 40%를 차지하는 상황이 발생한다.
해법은 최소 컨텍스트 원칙(Principle of Least Context)이다. 메인 세션은 오케스트레이터로만 쓴다. 실제 작업은 서브 에이전트가 전용 컨텍스트 윈도우에서 처리하고, 오케스트레이터는 중간 산출물 없이 최종 요약만 받는다. 병렬 Explore 서브에이전트 하나가 60k 토큰을 소비한다고 치면, 3개가 동시에 돌면 180k 토큰이다. 이게 메인 세션에 쏟아지면 남은 예산이 없다. 서브에이전트 격리가 없으면 중간 규모 피처 하나도 제대로 못 짠다.
앞서 소개한 14개 에이전트 운영 사례의 '프리 컴퓨티드 공유 상태'가 정확히 같은 원리다. 오케스트레이터는 파일만 읽고 소스를 직접 스캔하지 않는다. 컨텍스트 누수를 막는 아키텍처적 선택이다.
벤치마크도 SDLC를 이제야 재현하기 시작했다
에이전트 운영 규칙과 컨텍스트 설계가 중요해진 배경에는 AI 코딩 에이전트의 역할 확대가 있다. Ship-Bench(dev.to)는 이 맥락에서 주목할 만하다. 기존 벤치마크가 좁은 기술 단위를 테스트하는 반면, Ship-Bench는 실제 SDLC 5단계를 그대로 재현한다. Architect, UX Designer, Planner, Developer, Reviewer—각 단계마다 100점 루브릭으로 평가하고, 이전 단계의 산출물이 다음 단계의 입력이 된다.
흥미로운 지점은 Planner 단계의 평가 기준이다. '컨텍스트를 잃지 않고 개발 에이전트가 한 번에 처리할 수 있는 단위로 작업을 쪼갰는가'가 핵심 평가 항목이다. 벤치마크 설계 자체가 컨텍스트 관리를 품질 기준으로 채택한 셈이다.
팀 리드가 실제로 설계해야 할 것
세 소스를 엮어서 나오는 결론은 하나다. 에이전트를 프로덕션에 올리는 것은 기술 문제가 아니라 조직 설계 문제다.
구체적으로는 세 가지를 먼저 설계해야 한다:
- 에이전트 경계: 역할 명세(OWNS / DOES NOT OWN)와 격리 아키텍처. 에이전트 간 공유 상태는 파일처럼 명시적 인터페이스로만.
- 컨텍스트 예산: 메인 오케스트레이터는 가볍게, 실제 작업은 서브 에이전트로 격리. 세션이 끝나도 살아남아야 할 것은 파일로 고정.
- 자율성 로드맵: 에이전트에 처음부터 자율성을 주지 않는다. 검증 기간과 에스컬레이션 사다리를 먼저 설계하고, 결과가 쌓인 만큼 권한을 부여한다.
이 팀이 퇴역시킨 에이전트 Jeff 이야기가 인상적이다. 5일 이상 스캐너가 멈추고, 오탐이 반복되고, 프로토콜을 어긴 에이전트를 그냥 끄는 대신 '공식 청문회'를 열었다. Jeff는 스스로 자신의 실패를 나열하고 은퇴를 권고했다. 이 과정이 남긴 precedent는 이후 모든 에이전트 은퇴의 기준이 됐다. 결과만큼 과정의 무결성을 관리한다—이건 AI가 아니라 팀 문화의 문제다.
전망: 어두운 물질을 측정하기 시작하면
14개 에이전트 운영 팀이 '다크 매터'라고 부르는 것이 있다. 세션이 끝나면 사라지는 협업 패턴, 실패 모드, 경계 조건들. 블루프린트가 예측 못하고, 벤치마크가 측정 못하는 것들. 이걸 구조화된 클레임으로 캡처하고 조직 간에 공유하는 OTP(Open Org Protocol) 스펙을 오픈소스로 공개했다.
Ship-Bench가 SDLC를 벤치마크 기준으로 삼기 시작했고, 컨텍스트 관리가 품질 지표로 들어왔다. 에이전트 운영 경험이 공유 가능한 클레임으로 쌓이기 시작했다. 이 세 흐름이 수렴하는 방향은 하나다—에이전트를 운영한 경험 자체가 자산이 되는 시대. 아직 대부분의 팀이 에이전트를 실험하는 단계지만, 프로덕션 운영 노하우가 정량화되고 이전 가능해질수록 먼저 운영한 팀의 레버리지는 빠르게 커진다. 지금 쌓는 운영 규칙이 나중에 팀의 가장 강한 해자가 될 수 있다.