에이전트 시스템은 모델의 능력이 일정하다는 가정 위에 오래 머물기 어렵다. 성능 개선 주기가 짧아질수록 어떤 구성 요소를 고정하고 무엇을 교체 가능하게 둘지가 운영 비용을 좌우한다.
모델이 똑똑해질수록 짐이 되는 코드
에이전트 하네스에는 모델의 약점을 메우는 코드가 들어간다. Anthropic도 Claude Sonnet 4.5가 컨텍스트 한계에 가까워지면 작업을 서둘러 끝내는 문제를 막으려고 리셋 로직을 넣었다. 하지만 Opus 4.5에서 문제가 사라지자 이 로직은 불필요해졌다. 모델의 약점을 보완한 코드는 그 약점이 사라지면 쓸모를 잃는다.
청킹, 리랭킹(문서를 조각내 관련도 순으로 재정렬하는 검색 전처리) 파이프라인, 복잡한 오케스트레이터, API를 재설명하는 툴 래퍼도 마찬가지다. 긴 명세를 읽고 작업 순서를 짜는 모델에는 오히려 방해가 된다. 모델이 맡는 범위가 넓어질수록 수작업 구조의 가치는 줄어든다. 실제로 한 코딩 에이전트 평가에서는 프롬프트를 줄인 뒤 점수가 10~15% 오르고, 토큰은 41~66%, API 비용은 33~67% 줄었다.
문제는 이 부채의 폐기 시점을 개발팀이 정할 수 없다는 데 있다. 새 모델이 나오면 코드의 전제부터 사라지기 때문이다. 모델을 바꿀 때는 규칙을 더하기 전에 오래된 프롬프트와 스킬부터 덜어내야 한다. 규칙과 절차를 묶음 단위로 제거하고 같은 평가를 반복해야 한다.
실행 환경은 언제든 죽을 수 있다
Managed Agents의 초기 구조는 세션과 하네스, 코드 실행 환경을 한 컨테이너에 넣었다. 단순했지만 컨테이너가 죽으면 세션도 사라졌다. 응답이 없을 때 하네스와 네트워크, 샌드박스 가운데 어디가 문제인지 어떻게 가릴 수 있었을까.
그래서 Anthropic은 세션을 컨테이너 밖의 이벤트 로그로 옮겼다. 입력과 응답, 툴 호출, 파일 변경, 오류와 재시도를 순서대로 남긴다. 실행 인스턴스가 종료돼도 마지막 이벤트부터 다시 시작할 수 있고, 기록은 그대로 감사 로그가 된다. Temporal도 이벤트를 재생해 중단 지점부터 작업을 이어간다.
이렇게 원본 로그가 밖에 있으면 요약은 삭제가 아니라 임시 압축이 된다. 필요할 때 getEvents()로 이전 내용을 되살릴 수 있어 안전 확보에도 쓰인다. 1,323개 실험에서 정책 위반율은 전체 정책을 줬을 때 0%였지만, 컴팩션 뒤에는 평균 30%, 일부 모델에서는 59%까지 올랐다.
필요한 실행 환경만 붙인다
분리된 하네스는 샌드박스를 execute(name, input) → string이라는 단순한 계약으로 호출한다. 그 뒤에 컨테이너가 있는지 외부 서비스가 있는지는 몰라도 된다. 실행 환경이 고장 나면 교체하고, 하네스는 wake(sessionId)를 호출해 외부 로그의 마지막 지점부터 이어간다.
코드 실행이 필요 없는 요청은 컨테이너를 기다리지 않고 처리한다. 이 구조를 적용하자 첫 토큰까지 걸리는 시간이 중앙값 기준 약 60%, 지연이 큰 상위 5% 구간에서는 90% 넘게 줄었다. 모델이 느려 보였던 원인 중 일부는 다름 아닌 실행 환경을 항상 함께 띄우는 구조에 있었다.
자격 증명은 실행 환경 밖에 둔다
실행 환경뿐 아니라 자격 증명도 샌드박스와 분리해 관리한다. 깃 토큰은 저장소를 연결할 때만 쓰고, MCP(모델과 외부 도구를 연결하는 프로토콜)의 OAuth 토큰은 외부 볼트에 둔 채 프록시가 대신 호출한다. 실제로 Unit 42는 Vertex AI 실행 환경에서 얻은 서비스 에이전트 자격 증명으로 고객 프로젝트의 모든 Cloud Storage 버킷을 읽을 수 있었던 사례 를 공개했다.
이런 위험을 감안하면 프롬프트 인젝션을 완벽히 탐지하는 데만 기댈 수는 없다. 공격이 성공해도 실행 환경에 장기 자격 증명이 없으면 피해가 줄어든다. 과거의 단일 컨테이너는 모델의 한계를 보완했지만, 이제는 장애 지점과 권한이 같은 경계 안에 함께 있는 구조가 됐다.
오래 남길 것은 경계와 계약이다
모델과 프롬프트는 몇 달 만에도 바뀐다. 반면 세션 기록과 실행 계약은 여러 세대의 모델이 함께 써야 한다. 수명이 짧은 전략을 장기 상태와 엮으면 모델을 바꿀 때마다 시스템 전체를 다시 검증해야 한다.
오래 유지할 대상은 특정 전략이 아니라 좁고 명확한 인터페이스다. execute, wake, emitEvent, getEvents는 구현이 바뀌어도 역할이 같다. 장애 복구와 네트워크 단절, 자격 증명 보호 역시 모델 성능과 무관한 조건이다. 컨텍스트 리셋이나 툴 스키마 재작성처럼 특정 행동을 보완하는 코드는 이 층에서 분리해야 한다.
멀티에이전트 구조도 같은 기준으로 판단한다. 역할 분담이 실제 권한이나 장애 경계를 반영한다면 유지할 가치가 있다. 짧은 컨텍스트나 서툰 툴 호출을 보완하기 위한 분담이라면, 모델 교체 뒤에는 통신 비용과 오류 지점만 늘어난다. 판단 기준은 에이전트 수일까. 그 분리가 어떤 현실의 제약을 반영하는지에 달려 있다.
결국 모델의 결함을 보완하는 코드에는 대상 행동과 삭제 조건을 함께 적어야 한다. 새 모델에서 같은 문제가 재현되지 않으면 제거하고 다시 평가한다. 에이전트 시스템의 수명은 기능을 얼마나 빨리 더하느냐보다, 업그레이드할 때 무엇을 걷어낼지 얼마나 쉽게 찾느냐에 달려 있다.
시스템의 복잡성은 도입 시점보다 교체 시점에 더 정확하게 나타난다. 새 모델을 넣는 데 드는 작업이 제한된 실험 수준으로 끝나는 구조는 기술 변화 속도를 그만큼 감당한다.