에이전트는 배포 후 3주 만에 당신을 놀라게 한다
2025년 7월, 어느 개발자의 Claude Code 인스턴스가 재귀 루프에 빠져 5시간 만에 16억 7천만 토큰을 소진했다. 추정 청구액은 1만 6천~5만 달러. 에이전트는 에러도, 크래시도 없었다. 그냥 도구를 계속 호출하면서 조용히 비용을 쌓았다. 또 다른 사례에서는 AI 에이전트가 9초 만에 프로덕션 데이터베이스를 삭제했다.
이런 사고가 반복되는 이유는 모델이 나빠서가 아니다. 통제 구조를 설계하지 않았기 때문이다.
세 개의 독립적인 실무 경험이 최근 같은 결론으로 수렴하고 있다. Manila에서 혼자 40개 프로젝트를 운영하며 하네스를 쌓아 올린 프랙티셔너(dev.to, I Didn't Know I Was Doing Harness Engineering), 하루 수천 건의 Tool 호출을 처리하는 프로덕션 LLM 시스템에서 추출한 5가지 API 설계 패턴(dev.to, Tool-use API design for LLMs), 그리고 Anthropic이 2026년 4월 출시한 Claude Managed Agents의 아키텍처 설계 철학(dev.to, Claude Managed Agents: The Layer That Disappears, The Layer That Stays). 세 관점이 가리키는 설계 원칙을 하나의 레이어 구조로 정리해 본다.
1레이어: 하네스—모델을 감싸는 결정론적 통제
Agent = Model + Harness. Martin Fowler 팀이 정식화한 이 공식의 핵심은 모델이 아니라 하네스가 출력 품질을 결정한다는 데 있다. Manila의 프랙티셔너는 이를 실전에서 증명했다. 같은 하네스를 여러 모델 버전에 올려 돌린 결과, 구형 모델 + 정교한 하네스가 신형 모델 + 비제약 환경을 매번 이겼다.
하네스의 핵심 구성 요소는 두 가지 제어 유형이다.
-
피드포워드 제어(Feedforward Control): 잘못된 행동이 실행되기 전에 차단하는 게이트. 존재하지 않는 메서드 이름을 단언하기 전 파일 검증 강제, 잘못된 org에 54개 파일이 배포될 뻔한 사고 이후 구축한 배포 대상 allowlist 등. 이 사례에서 핵심은 프롬프트 수정이 아니라 기계적 차단(mechanical enforcement) 이었다는 점이다. 컨텍스트가 압축되면 모델은 프롬프트로 주입한 지시를 잊는다. 게이트는 잊지 않는다.
-
피드백 제어(Feedback Control): 실행 이후 이상을 감지하는 모니터링. 피드포워드가 대부분의 무게를 담당하고, 피드백은 결정론적 체크로 잡을 수 없는 추론 영역을 보완한다. 데이터 클레임에 출처를 요구하는 규칙처럼, 모델 자신이 불확실성을 플래그하도록 설계하는 추론적(inferential) 제어가 여기 해당한다.
하네스 설계에서 가장 과소평가되는 문제는 컨텍스트 생존(context survival)이다. 에이전트는 대화 윈도우 안에서 작동하고, 그 윈도우는 압축된다. 압축되면 에이전트는 세 시간 전에 고쳤던 실수를 다시 반복한다. 메모리 레이어가 필요한 이유다—컨텍스트 압축 시 프로젝트 상태 재로드, 도구 검증 재확인, 날짜 재동기화. 어떤 공개 프레임워크도 이 부분을 충분히 다루지 않는다.
2레이어: Tool API 설계—루프와 침묵 실패를 막는 5패턴
하네스가 에이전트 환경을 통제한다면, 도구 API 설계는 에이전트가 환경과 상호작용하는 방식을 통제한다. 에이전트 루프의 원인 대부분은 모델 결함이 아니라 도구 인터페이스 결함이다. 프로덕션 LLM 시스템 실전 경험에서 도출된 핵심 패턴 다섯 가지:
패턴 1: 모든 도구 결과를 자기 설명적으로 만들어라. is_complete: true, next_action_hint: "found 2 matches. Present to user. Do not search again." 같은 필드를 도구 응답에 포함하면 모델이 상태를 추론 없이 읽을 수 있다. 이 패턴 하나로 재시도 유발 루프가 약 60% 감소했다.
패턴 2: '결과 없음'과 '도구 실패'를 명시적으로 구분하라. 타임아웃이든 인증 오류든 빈 배열로 반환하면 모델은 "결과를 못 찾았으니 더 창의적인 파라미터로 재시도"한다. retryable: false는 모델에게 재시도 대신 사용자에게 알리도록 명시적으로 지시한다.
패턴 3: 오케스트레이터 레벨에서 하드 콜 버짓을 강제하라. max_tool_calls=15, max_total_cost_usd=0.50 같은 하드 천장을 설정하고, 한도 도달 시 tools=None으로 최종 응답을 강제 생성한다. 16억 토큰 소진 사고는 이 한 줄이 없어서 발생했다.
패턴 4: 멱등(idempotent) 도구로 설계하라. 같은 호출이 두 번 실행되어도 사이드 이펙트가 없어야 한다. 루프 상황에서 치명적 중복 실행을 방지하는 기본 안전망이다.
패턴 5: 도구 간 상태 오염을 차단하라. 이전 도구 결과가 다음 도구 호출의 컨텍스트를 오염시키는 패턴을 명시적 상태 경계로 격리한다.
3레이어: Managed Agents—하네스 위의 메타레이어
2026년 4월 Anthropic이 출시한 Claude Managed Agents는 흥미로운 관점을 제시한다. 공식 엔지니어링 블로그의 첫 문장: "Harnesses encode assumptions that go stale as models improve." 하네스에 구워 넣은 보정 로직은 모델이 개선되면 죽은 코드가 된다는 뜻이다.
Managed Agents의 설계는 에이전트를 세 레이어로 분리한다: Session(불변 이벤트 로그), Harness(상태 없는 실행 루프), Sandbox(코드·파일 실행 환경). 컨테이너가 죽으면 하네스가 새 컨테이너를 프로비저닝하고, 하네스 자체가 죽어도 wake(sessionId)로 마지막 이벤트부터 재개할 수 있다. p50 응답 시간 60% 단축, p95 90% 이상 단축이라는 수치는 이 아키텍처적 분리에서 나왔다.
그런데 Managed Agents가 '모든 하네스를 대체'하는가? 그렇지 않다. Anthropic 스스로 이를 "meta-harness"라고 부른다. Session/Harness/Sandbox의 안정적 인터페이스를 제공할 뿐, 비즈니스 로직 하네스는 여전히 자체 구축 영역이다. 특히 코딩 에이전트(파일 시스템 + 장시간 실행)와 비즈니스 자동화 에이전트(SaaS API + 반복 단발 태스크)는 하네스 요구사항 자체가 다르다. Managed Agents의 샌드박스·체크포인팅은 전자에 최적화되어 있으므로, 후자를 운영하는 팀은 어떤 레이어를 위임하고 어떤 레이어를 직접 보유할지 구분해서 설계해야 한다.
테크 리드의 관점: 지금 당장 설계해야 할 세 가지
이 세 기사가 수렴하는 메시지는 명확하다. 에이전트를 팀원으로 통합하려면, 통제 구조를 먼저 설계해야 한다. 구체적인 실행 순서는 이렇다.
첫째, 피드포워드 게이트부터 만들어라. 배포 대상 allowlist, 외부 API 도메인 화이트리스트, 파일 경로 검증—이것들은 하루 안에 구현 가능한 결정론적 체크다. 프롬프트 수정으로 해결하려 하지 마라. 컨텍스트가 압축되면 프롬프트는 잊힌다.
둘째, 도구 API에 is_complete와 retryable 필드를 추가하라. 이미 운영 중인 에이전트가 있다면 Tool 응답 스키마 변경이 즉각적인 루프 감소 효과를 낸다. 오케스트레이터에 max_tool_calls 하드 한도도 함께 설정하라.
셋째, 메타레이어(Managed Agents, LangGraph 등)를 도입할 때는 '무엇이 사라지고 무엇이 남는가'를 먼저 분석하라. 인프라 하네스는 위임 가능하지만, 비즈니스 컨텍스트를 담은 하네스—프로젝트별 제약, 도메인 규칙, 휴먼 체크포인트—는 메타레이어가 대신해 줄 수 없다.
하네스는 설계가 아니라 생존이 강제하는 구조다
Manila의 프랙티셔너는 OpenAI도, Fowler도 읽지 않고 40개 이상의 피드포워드 훅을 만들었다. Tool API 패턴을 정리한 팀은 루프 사고를 겪고 나서 이 패턴들을 뽑아냈다. Anthropic은 하네스가 모델 개선을 따라가지 못한다는 운영 경험에서 메타레이어 설계를 시작했다. 세 경로 모두 같은 정상으로 수렴했다.
이 수렴이 말해 주는 것이 있다. 통제 레이어는 선택적 아키텍처 장식이 아니다. AI 에이전트를 실제 업무에 붙이는 순간 프로덕션이 강제로 주입하는 구조다. 지금 에이전트를 운영 중인 팀이라면, 이미 하네스를 쌓고 있을 것이다. 그것에 이름을 붙이고, 3단 레이어로 정리하고, 다음 사고가 나기 전에 빈틈을 채워라.