Anthropic이 밝힌 AI 에이전트가 개발 환경에서는 작동하고 운영 환경에서 실패하는 이유: 비용별 5가지 해결책

r/AnthropicAI 스레드가 하룻밤 사이에 _"Anthropic이 비코딩(non-coding) AI 에이전트의 90%가 운영 환경(production)에서 실패하는 이유를 방금 확인해주었습니다."_라는 헤드라인과 함께 138개의 추천을 받았습니다.

해당 스레드는 증상에 대해서는 맞지만, 치료법에 대해서는 틀렸습니다.

만약 여러분이 비코딩 에이전트(영업 담당자, 지원 분류, 운영 봇, 내부 검색 등 무엇이든)를 출시하고 있다면, 앞으로의 4분은 여러분이 이번 주에 읽게 될 내용 중 가장 저렴한 다섯 가지 해결책이 될 것입니다.

스레드가 실제로 말한 내용

2026년 5월 28일 기준 사실 관계:

Anthropic은 2주 전 에이전트 데모와 에이전트 운영 환경 사이의 격차를 다룬 배포 패턴(deployment-patterns) 보고서를 발표했습니다. 스레드의 스크린샷은 거기서 가져온 것입니다.
90%라는 수치는 Anthropic의 것이 아닙니다. 이는 Reddit 게시자가 Sierra의 2025년 4분기 진행된 411개의 엔터프라이즈 파일럿(enterprise pilots) 조사 결과를 인용하여 의역한 것입니다. 실제 Sierra의 수치는 에이전트 파일럿의 87%가 9개월 이내에 예산 항목(budgeted line item)으로 승격되지 못한다는 것입니다.
해당 스레드는 원인을 _"메모리 부족(missing memory)"_으로 축소하고 있습니다. 이는 Anthropic이 나열한 7가지 원인 중 하나일 뿐이며, 지배적인 원인은 아닙니다.
Anthropic이 자체적으로 집계한 상위 3가지 원인은 다음과 같습니다: 불충분하게 정의된 성공 기준(성공하지 못한 파일럿의 64%에서 언급), 출시 전 평가 세트(eval set) 미구축(61%), 그리고 운영 환경 형태의 입력값에서 충돌이 발생하는 취약한 도구 경계(brittle tool boundaries)(52%).
코딩 에이전트(Claude Code, Cursor, Cline)는 훨씬 낮은 실패율(Sierra는 40% 미만으로 집계)을 보입니다. 그 이유는 성공 기준이 프로그래밍 언어에 의해 고정되어 있기 때문입니다: 테스트가 통과했는가, 린터(linter)가 오류를 내지 않았는가, 디프(diff)가 적용되었는가 등입니다.
동일한 조사에서는 "예산 주기에 의해 중단된 파일럿(실패의 43%)"과 "조용히 계속 실행되었지만 SLA(서비스 수준 협약)로 승격되지 못한 파일럿(44%)"을 구분합니다. Reddit 스레드는 이 둘을 혼동하고 있습니다. 이들은 근본 원인이 다릅니다.
Anthropic은 또한 이번 주에 업데이트된 에이전트 설계 루브릭(agent-design rubric)을 발표했습니다. 마케팅 문구 없이 5개의 행으로 구성되어 있습니다. 사양(spec)을 작성하기 전에 읽어볼 가치가 있습니다. 이 루브릭은 네 번째 행이 나오기 전까지 모델 선택(model selection)에 대해 언급하지 않습니다.

이 스레드의 결론인 _"메모리를 추가하면 해결된다"_라는 말은, 에이전트 버전의 _"그냥 캐싱을 추가하세요"_와 같습니다. 도움이 될 수는 있겠지만, 실패율(failure rate)을 낮추지는 못할 것입니다.

이것이 단순한 기업용 파일럿 사례가 아닌 이유

오늘날 코딩을 하지 않는 에이전트(non-coding agent)를 출시한다면, 당신은 다음 세 가지 상황 중 하나에 처해 있을 것입니다.

시작한 지 3주 되었고, 데모는 잘 작동하며, 출시를 위해 인력을 충원 중입니다. 당신의 에이전트는 87%의 실패 그룹에 속하게 될 것입니다. 다음 섹션은 당신을 위한 것입니다.
3개월 전에 출시했습니다. 사용량은 괜찮지만, 동일한 5명의 사용자가 세션의 80%를 차지합니다. 당신은 실패하고 있는 것이 아니라, 정체(stalling)되고 있는 것입니다. 메커니즘(mechanism) 섹션에서 그 이유를 설명합니다.
1분기에 에이전트 프로젝트를 중단했습니다. 당신이 실시한 사후 분석(autopsy)은 아마도 모델(model)을 원인으로 지목했을 것입니다. 계속 읽어보십시오. 모델은 하중을 견디지 못해 발생하는 실패(load-bearing failure)의 원인인 경우가 거의 없습니다.

만약 당신이 코딩 에이전트(coding agents) — Claude Code 래퍼(wrapper), MCP 서버, 서브 에이전트 오케스트레이터(sub-agent orchestrators) — 를 구축하고 있다면, 이 내용의 대부분은 여전히 적용됩니다. 당신의 실패율은 컴파일러(compiler)가 당신이 틀렸을 때 알려준다는 사실 때문에 단지 숨겨져 있을 뿐입니다. 컴파일러를 제거하면 ("이 코드베이스를 요약해줘", "리팩토링을 제안해줘", "마이그레이션 계획을 초안해줘") 당신의 수치는 코딩을 하지 않는 에이전트의 평균치로 회귀합니다. Cursor와 Cline 팀은 내부적으로 "테스트가 커버되지 않은 작업(non-test-covered task)"의 실패율을 비공개적으로 참조하고 있는데, 이는 Sierra의 비코딩 에이전트 수치와 거의 정확히 일치합니다. 다만 테스트가 커버된 작업들이 주요 지표(headline metric)가 되기 때문에 보고되지 않을 뿐입니다.

만약 당신이 에이전트 제품을 판매하는 창업자라면, 실패율은 당신의 고객 이탈률(churn)의 상한선입니다. 만약 당신이 에이전트를 구매하는 CTO라면, 실패율은 파일럿에서 운영 환경(production)으로 전환하기 위한 관문입니다. 두 사람 모두 계약의 서로 다른 측면에서 동일한 수치를 바라보고 있는 것입니다.

메커니즘: 실패가 실제로 발생하는 지점

Anthropic이 밝힌 7가지 원인은 세 가지 아키텍처 계층(architectural layers)으로 압축됩니다. 대부분의 팀은 잘못된 계층을 수정하고 있습니다.

계층 1: 스펙 계층 (Spec layer, 실패의 64%가 발생하는 곳)

대부분의 에이전트 스펙(spec)은 다음과 같이 작성됩니다:

목표(Goal): 인바운드 지원 티켓을 처리하고 해결하거나 에스컬레이션(escalate)함.
성공 기준(Success): 높은 CSAT(고객 만족도), 낮은 처리 시간.
도구(Tools): zendesk, slack, kb_search.

이것은 바람(wish)일 뿐, 명세(spec)가 아닙니다. 에이전트가 업무를 제대로 수행했는지 알 수 있는 테스트는 존재하지 않습니다. 평가 세트(eval set)에는 "이 대화는 에스컬레이션(escalate)되어야 하고, 저 대화는 그렇지 않아야 한다"라고 명시된 행(row)이 없습니다. 모델이 잘못된 선택을 했을 때, 그것이 나쁜 모델 때문인지, 나쁜 프롬프트(prompt) 때문인지, 아니면 나쁜 도구(tool) 때문인지 알 방법이 없습니다. 그리고 누군가 이 명세가 결코 반증 가능하지(falsifiable) 않다는 사실을 알아차리기 전까지, 당신은 이 세 가지를 교체하며 6주를 허비하게 됩니다.

명세에 필요한 것:

목표: "결제(billing)" 및 "계정 액세스(account access)" 큐의 L1 티켓을 해결할 것.
해결 정의: 요청자가 24시간 이내에 티켓을 "해결됨(resolved)"으로 표시하고,
  7일 이내에 재오픈(reopen)되지 않음.
...

이것은 업무의 지루한 절반입니다. 데모(demo)로 보여줄 수도 없습니다. 하지만 이는 당신이 기다리고 있는 모델 업그레이드보다 실패율에 더 큰 영향을 미치는 단 하나의 변수이기도 합니다. 파일럿 프로젝트에서 제가 보는 가장 비용이 많이 드는 실수는, 팀원 두 명조차 동일하게 라벨링(labeling)할 수 없는 명세를 두고 프롬프트 문구의 A/B 테스트를 수행하며 3주를 보내는 것입니다. 이러한 명세에 대한 인간 라벨러(human labeler) 간의 편차는 종종 Sonnet 4.5와 Opus 4.7 사이의 편차보다 높으며, 이는 _모델이 개선되었는지 여부를 판단할 수 없음_을 의미합니다.

레이어 2: 도구 레이어 (실패의 52%)

당신의 도구 정의(tool definitions)는 아마도 해피 패스(happy-path, 이상적인 경로) 데모를 위해 작성되었을 것입니다. 운영 환경(production)의 입력값은 해피 패스가 아닙니다. 네 가지 패턴이 지배적입니다:

서류상의 스키마 도구 (The schema-on-paper tool). 당신의 lookup_order(order_id: str)는 독스트링(docstring)상으로는 Order 객체를 반환합니다. 하지만 운영 환경(production)에서는 호출의 4%에서 {"error": "order is in dispute, see legal_hold table"}를 반환합니다. 에이전트는 이를 어떻게 처리해야 할지 전혀 모릅니다. 이는 스키마(schema)의 일부가 아니었기 때문입니다. 모델은 계획을 지어내고, 그 계획은 틀리며, 당신의 고객 만족도(CSAT)는 8점 하락합니다.
무한 도구 (The infinite-tool). search_kb(query: str)가 상위 50개의 문서를 반환합니다. 에이전트는 성실하게 50개 모두를 컨텍스트(context)에 집어넣고, 이제 당신은 환불 질문 하나에 답변하기 위해 2달러어치의 토큰을 태웠습니다. 유닛 이코노믹스(unit economics)는 결코 회복될 수 없습니다.
드라이 런(dry run)이 없는 파괴적인 도구 (The destructive tool with no dry run). cancel_subscription(user_id)는 운영 환경에서 미리보기 단계 없이 첫 시도에 이름 그대로의 동작을 수행합니다. 당신의 에이전트는 결국 잘못된 사용자에게 이 도구를 호출하게 될 것입니다. 사후 분석(post-mortem)에서는 "환각 (hallucination)"이라고 말하겠지만, 실제 원인은 당신의 API가 확인 절차 없이 에이전트의 실행을 허용했기 때문입니다.
도구 간 일관성 격차 (The cross-tool consistency gap). lookup_order는 주문 정보를 USD(달러)로 반환합니다. issue_refund는 센트(cents) 단위를 받습니다. 아무도 이 단위 불일치를 문서화하지 않았고, 그 결과 에이전트는 사용자가 요청한 금액의 100배를 조용히 환불해 버립니다. 이 버그는 이번 분기에 실제 고객에게 적용되어 누군가 발견하기 전까지 4만 2천 달러의 손실을 입혔습니다.

레이어 3: 메모리 및 상태 레이어 (The Reddit fix)

이것이 바로 스레드가 가리키고 있는 지점입니다. 메모리(Memory)는 중요합니다. 장기 실행 에이전트(long-running agents)와 멀티 턴 워크플로우(multi-turn workflows)에는 메모리가 필요하며, 맞습니다, Anthropic Memory와 새로운 메모리 도구 패턴은 실질적인 승리입니다. 하지만 여기서 발생하는 실패 모드(failure mode)는 앞서 언급한 스펙(spec) 및 도구 실패에 비하면 작습니다. 망가진 스펙 위에 메모리를 수정하는 것은 더 확신에 찬 오답을 내놓게 만들 뿐이며, 이는 종종 혼란스러워하는 것보다 더 나쁩니다. 적어도 혼란스러워하는 에이전트는 에스컬레이션(escalate)이라도 할 테니까요.

실질적인 규칙: 메모리는 그 아래 레이어들에 대한 승수(multiplier)입니다. 만약 당신의 스펙이 6점이고 도구가 6점이라면, 메모리는 당신을 7점으로 올려줍니다. 하지만 스펙이 2점이고 도구가 4점이라면, 메모리는 당신을 1점으로 떨어뜨립니다. 왜냐하면 이제 잘못된 결정이 턴(turn)을 거쳐 지속되며 미래의 결정까지 오염시키기 때문입니다.

반대 의견: "모델이 따라잡을 것이다"

일관성 있는 반론이 존재하며, 당신의 팀원 중 적어도 한 명의 엔지니어로부터 이런 말을 듣게 될 것입니다:

"6개월 뒤의 Claude 5는 불충분하게 정의된 사양(spec)을 스스로 파악할 만큼 똑똑해질 겁니다. 다음 분기 모델이 모호함(ambiguity)을 더 잘 처리할 텐데, 왜 우리가 지금 200개의 라벨링된 행을 작성해야 하죠?"

이것은 어리석은 생각이 아닙니다. Claude 4.7은 이미 4.5보다 모호한 작업들을 실질적으로 더 잘 처리하고 있습니다. 확장된 사고(extended thinking) 기능을 갖춘 Sonnet 4.6은 1분기에 팀 전체가 놓쳤던 사양의 공백을 해결할 수도 있습니다. Anthropic이 발표한 자체 벤치마크(benchmarks)에 따르면, 에이전트 작업(agentic tasks)에서의 4.5와 4.7 사이의 격차(TAU-Bench, MLE-Bench, SWE-bench Verified)는 이 회사가 출시한 단일 버전 업데이트 중 가장 큰 도약입니다. 복리 효과의 곡선은 실재합니다.

하지만 이것은 운영 환경(production)의 문제를 해결하지 못합니다. 세 가지 이유가 있습니다.

첫째, 실패의 원인은 "모델이 잘못 선택했다"가 아닙니다. "모델이 잘못 선택했는지 알 방법이 없어서, 반복(iterate)할 수 없다"가 문제입니다. 더 똑똑한 모델은 이 문제를 해결하지 못하며, 오히려 틀린 답을 더 확신 있게 내놓게 만듭니다. 4.7 출시 노트의 안전(safety) 섹션에서도 실제로 이 점을 경고하고 있습니다: "작업 완료 행동(task completion behavior)이 더 강력한 모델은 잘못된 작업을 더 단호하게 완료할 수 있습니다." 이 문장은 모든 PM의 책상 위 포스터에 붙어 있어야 합니다.

둘째, "모델이 알아서 하게 두자"는 방식의 비용 궤적(cost trajectory)은 잘못된 방향으로 흐릅니다. Opus 4.7의 확장된 사고(extended thinking)는 훌륭하지만 공짜가 아닙니다. 턴(turn)당 8초 동안 생각하는 사양이 미비한 에이전트는, 모델 업그레이드가 이루어지기도 전에 당신의 단위 경제성(unit economics)을 갉아먹을 것입니다. 제가 본 모델 업그레이드 과정에서 살아남은 팀들은 사양(spec)을 충분히 엄격하게 정의하여, 트래픽의 70%는 Sonnet으로 낮추어 처리(downgrade)하고 어려운 케이스만 Opus로 라우팅(route)할 수 있었던 팀들이었습니다. 사양이 없다면, 라우팅을 할 수 없습니다.

셋째, Anthropic의 자체 4분기 내부 고객 성공 데이터(지난주 Krieger 인터뷰에서 인용됨)에 따르면

해결책 2: 도구 오류 응답을 일급 출력(First-class outputs)으로 격상시키기 (2일 소요, $0)

에이전트가 호출하는 모든 도구(Tool)를 검토하십시오. 각 도구에 대해, 정상적인 경로(Happy-path)가 아닌 상황에서 반환될 수 있는 상위 5가지 응답을 작성하십시오. 그리고 이를 도구 설명(Tool description)에 추가하십시오. 만약 도구가 {"error": "in dispute"}를 반환할 수 있다면, 설명에는 에이전트가 해당 응답을 받았을 때 무엇을 해야 하는지가 명시되어야 합니다.

이번 달 한 고객으로부터 받은 실제 사례를 의역하면 다음과 같습니다:

# 이전 — 데모 버전
@tool
def lookup_order(order_id: str) -> Order:
...

이것은 모델의 문제가 아닙니다. 모델이 읽을 수 있는 문서화(Documentation)의 문제입니다. 비용은 누군가가 코드베이스를 하나씩 훑으며 도구별로 작업하는 2일의 시간입니다. 그 대가는 에이전트가 예외 상황(Edge cases)에서 독단적으로 행동하는 것을 멈추는 것입니다. 도구가 무엇을 해야 할지 알려주면, 에이전트는 그대로 수행합니다. 4.7급 모델들은 4.5급 모델들보다 이러한 구조화된 도구 설명을 눈에 띄게 더 높은 충실도(Fidelity)로 따르며, 이는 이 해결책이 1년 전보다 오늘날 더 저렴하게 적용될 수 있음을 의미합니다.

해결책 3: 모든 파괴적인 도구에 드라이 런(Dry-run) 모드 추가 (도구당 반나절 소요, $0)

쓰기, 취소, 환불, 전송, 삭제 또는 결제를 수행하는 모든 도구 — 단 하나도 빠짐없이 — 에 실제로 실행하지 않고 어떤 일이 일어날지를 반환하는 preview=True 파라미터를 추가하십시오. 에이전트는 기본적으로 미리보기(Preview)를 사용하며, 에이전트가 명시적으로 정당성을 입증해야 하는 확인 단계를 거친 후에만 작업을 확정(Commit)합니다.

@tool
def issue_refund(
    user_id: str,
...