Anthropic 4월 쌍둥이 출시 — Opus 4.7과 Managed Agents의 에이전트 비용 충격

4월 둘째 주에 Anthropic 공식 블로그를 두 번 새로 고침했다. 4월 8일에 Managed Agents 퍼블릭 베타, 4월 16일에 Claude Opus 4.7. 같은 달에 “인프라 레이어”와 “모델 레이어”를 동시에 업그레이드한 것이다.

솔직히 첫 반응은 흥분이었다. SWE-bench Pro 64.3%라는 숫자는 이전 버전 대비 약 10.9포인트 향상이고, Managed Agents는 내가 매달 직접 관리하던 에이전트 세션 인프라를 Anthropic이 대신 맡아준다는 얘기였다. 그런데 커뮤니티 반응을 읽기 시작하면서 그림이 복잡해졌다.

Opus 4.7이 실제로 무엇을 바꿨나

출시일인 4월 16일 기준으로 공개된 변경사항은 네 가지다.

벤치마크 수치: SWE-bench Pro에서 64.3%로 전작 대비 +10.9포인트, CursorBench에서 70%로 +12포인트. 코딩 에이전트 관점에서는 명확한 개선이다.

고해상도 이미지 지원: 최대 2576px, 3.75MP로 확장됐다. 이전 버전의 1568px/1.15MP 한계를 벗어난 것인데, UI 테스트 자동화나 스크린샷 기반 에이전트에게는 실질적인 업그레이드다.

task_budget 파라미터: 베타 기능이지만 내가 가장 주목한 변화다. 에이전트 루프 전체에 토큰 예산을 설정할 수 있다. task-budgets-2026-03-13 헤더로 활성화하며, 최솟값은 20k 토큰이다. hard cap이 아니라 advisory 방식으로 동작한다 — 예산을 초과해도 즉시 중단되는 게 아니라 모델이 “예산 내에서 완료하도록 노력”하는 방식이다.

xhigh 노력 레벨: 기존 low/medium/high에 xhigh가 추가됐다. 복잡한 추론 작업에서 더 깊이 생각하게 만드는 설정이다.

API 호출 예시로 task_budget 적용 방법을 정리하면:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    extra_headers={
        "anthropic-beta": "task-budgets-2026-03-13"
    },
    # task_budget은 에이전트 루프 전체 토큰 예산
    # 최소 20000, advisory(hard cap 아님)
    task_budget=50000,
    messages=[
        {
            "role": "user",
            "content": "이 레포지토리의 모든 Python 파일에서 deprecated API 호출을 찾아 최신 버전으로 교체해줘."
        }
    ]
)

이 코드를 Anthropic API 키 없이 직접 실행하지는 못했다. 위 코드는 공식 문서와 릴리스 노트를 기반으로 작성한 것이며, task_budget의 advisory 동작 방식은 Managed Agents 실전 배포 포스트에서 직접 테스트한 경험과 맞닿아 있다.

Managed Agents는 뭐가 다른가

4월 8일에 퍼블릭 베타로 전환된 Claude Managed Agents는 개념적으로 단순하다. 개발자가 직접 관리해야 했던 에이전트 실행 환경 — 샌드박스, 세션 상태, 권한 검증, 장시간 실행 컨테이너 — 을 Anthropic 플랫폼이 대신 운영해준다.

공식 문서가 제시하는 핵심 기능:

• 격리된 샌드박스: Bash 명령어, 파일 작업, 웹 검색, MCP 서버 실행이 격리된 환경에서 돌아감
• 세션 상태 유지: 몇 분에서 몇 시간짜리 작업도 파일시스템과 대화 맥락이 보존됨
• 자격증명 보안: API 키와 시크릿을 에이전트에게 직접 노출하지 않고 권한 위임 방식으로 처리
• 멀티 에이전트 조율: 리서치 프리뷰 상태지만 여러 에이전트가 협업하는 워크플로우 구성 가능

가격 구조는 세션 시간당 $0.08 + 표준 Claude API 토큰 비용이다. idle 시간은 제외되지 않는다는 점을 공식 문서에서 명시하고 있다.

Notion, Rakuten, Sentry가 이미 프로덕션에 적용했다는 사례가 공개됐는데, Notion은 90% 비용 감소와 85% 지연 개선, Rakuten은 70개 이상 비즈니스 유닛에서 오류율 97% 감소를 보고했다. 숫자가 크게 느껴지지만, 이는 기존에 각 팀이 직접 운영하던 불안정한 에이전트 인프라와 비교한 수치임을 감안해야 한다.

좋은 것부터: 에이전트 인프라 관리 부담의 실질적 감소

나는 이 블로그의 자동화 시스템을 직접 운영하면서 에이전트 세션 관리가 얼마나 성가신지 체감하고 있다. 세션이 예기치 않게 끊기고, 컨텍스트가 유실되고, 장시간 작업이 조용히 실패하는 상황을 방어하는 코드가 비즈니스 로직보다 많아지는 시점이 온다.

Managed Agents가 이 부담을 덜어준다면 — 실제로 Sentry가 “몇 주 만에 패치 에이전트를 프로덕션 출시했다”고 말한 배경이 이것이라면 — 가치는 분명하다.

Claude Code 에이전틱 워크플로우 패턴에서 다룬 오케스트레이터-서브에이전트 구조를 Managed Agents 위에 올리면, 이전에는 직접 구현해야 했던 복구 로직과 상태 동기화를 플랫폼이 처리해주는 셈이다.

task_budget도 방향은 맞다. 에이전트가 예산 내에서 우선순위를 스스로 정하도록 유도하는 방식은, 하드 컷보다 실제 작업 완성도를 더 높일 가능성이 있다.

아쉬운 것: 벤치마크와 실무의 괴리, 그리고 숨겨진 비용

그런데 Opus 4.7 출시 24시간 뒤 커뮤니티 반응이 들어오기 시작했고, 나는 불편한 패턴을 발견했다.

byteiota.com에서 수집된 개발자 피드백 요약을 보면, 일부 파워 유저들이 Opus 4.7을 “legendarily bad”라고 표현했다. 구체적 불만은 세 가지로 수렴된다.

안전성 오버핏: 악성코드를 탐지하는 기준이 지나치게 높아져서, 일반 네트워크 호출이나 표준 라이브러리 사용도 거부되는 사례가 보고됐다. SWE-bench 같은 코딩 벤치마크에서는 보수적인 판단이 오히려 정확도를 높이지만, 실무에서는 마찰이 된다.

명령 해석의 경직성: 이전 버전보다 지시를 리터럴하게 해석하는 경향이 강해졌다. 유연한 추론보다 명시적 지시 준수를 우선시하는 것처럼 느껴진다는 반응이다.

출력 스타일 변화: 산문 형식보다 불릿 포인트 정리 선호가 강해졌다. 이걸 개선으로 보는 사람도 있고, 창의적 작업에서 단점으로 보는 사람도 있다.

그리고 내가 가장 중요하게 생각하는 문제는 따로 있다. 새 토큰나이저다. Opus 4.7은 새 토큰나이저를 탑재했는데, 동일 텍스트에 대해 이전 대비 1〜1.35배 더 많은 토큰을 사용한다. 공표된 가격은 바뀌지 않았지만, 실질 비용이 최대 35% 상승할 수 있다는 의미다.

AI 에이전트 비용 현실에서 프로덕션 에이전트 운용 비용을 분석한 적이 있는데, 토큰나이저 변경은 예산 시뮬레이션을 완전히 다시 해야 할 수준의 변수다. Anthropic이 이것을 출시 전면에 내세우지 않았다는 점은 비판받아 마땅하다.

비용 현실: 얼마나 올랐나

공개된 수치를 기반으로 시나리오별 비교를 해보면:

시나리오	Opus 4.6 기준	Opus 4.7 예상 (토큰 +25%)
간단한 Q&A (1K 토큰)	$0.005	~$0.006
코드 리뷰 (10K 토큰)	$0.05	~$0.063
장시간 에이전트 (100K 토큰)	$0.50	~$0.625

여기에 Managed Agents 세션 비용($0.08/시간)이 더해진다. 1시간짜리 에이전트 작업이라면 토큰 비용에 $0.08을 추가하는 셈이다. 짧은 배치 작업에는 부담스럽고, 장시간 복잡한 작업에는 직접 인프라 운영 비용보다 저렴할 수 있다.

Anthropic의 계산은 이렇다: 개발자가 에이전트 인프라를 직접 구성하고 유지하는 엔지니어링 비용보다 $0.08/시간이 저렴하다. 실제로 맞는 팀도 있고 틀린 팀도 있다. 이미 잘 돌아가는 에이전트 인프라가 있는 팀은 굳이 Managed Agents로 이전할 이유가 없다.

task_budget를 왜 지금 배워야 하나

task_budget 파라미터는 이번 릴리스에서 가장 조용하게 묻힌 기능이다. 언론은 벤치마크 숫자와 Managed Agents의 화려한 사례를 다뤘지만, 에이전트를 장기 운용하는 개발자에게 가장 실질적인 변화는 이 파라미터일 수 있다.

문제는 이렇다. 복잡한 리팩토링 에이전트를 실행하면 얼마나 오래 걸릴지, 토큰을 얼마나 쓸지 예측하기 어렵다. 에이전트가 예상보다 넓은 범위를 탐색하거나, 불필요한 도구 호출을 반복하거나, 컨텍스트를 계속 확장하면 비용이 수십 배로 불어날 수 있다.

max_tokens는 응답 하나의 길이를 제한하지만, 멀티턴 에이전트 루프 전체를 제어하지는 못한다. task_budget은 이 공백을 메우려는 시도다.

advisory 방식이라는 점이 흥미롭다. 모델이 예산 한도에 다가가면 강제로 중단되는 게 아니라, “이 예산 안에서 끝낼 방법을 스스로 찾도록” 동작한다. 공식 문서 표현으로는 모델이 예산 소진 전에 “우선순위가 낮은 탐색을 생략하고 핵심 작업에 집중한다”고 설명한다.

완벽한 해법은 아니다. advisory니까 모델이 예산을 초과할 수도 있고, 최소 20k 토큰 제약 때문에 짧은 작업에는 적용할 의미가 없다. 하지만 내가 운영하는 블로그 자동화처럼 일정 범위 내에서 끝나야 하는 에이전트에게는 유용한 가드레일이 될 것 같다.

Managed Agents가 바꾸는 개발 프로세스

Managed Agents를 처음 들었을 때 “기존 Claude API에 샌드박스가 붙는 정도겠지”라고 생각했다. 문서를 자세히 읽고 나서 생각이 바뀌었다.

가장 큰 변화는 상태 관리다. 기존에 에이전트 세션을 직접 운영하면 다음 문제가 반복된다.

첫째, 컨텍스트 유실. 에이전트가 여러 도구를 호출하면서 이전 단계 결과를 잊는 문제. 개발자들이 이걸 방어하기 위해 “컨텍스트 압축 로직”을 별도로 만든다.

둘째, 세션 재시작 비용. 예기치 않은 종료 후 다시 시작하면 전체 컨텍스트를 다시 구성해야 한다. 대형 코드베이스 분석 에이전트라면 이 재시작 비용 자체가 상당하다.

셋째, 자격증명 보안. 에이전트에게 GitHub, DB, 외부 API 접근 권한을 부여하면서도 키를 직접 노출하지 않는 방법이 복잡하다.

Managed Agents는 이 세 가지를 플랫폼 레이어에서 처리한다. 세션이 끊겨도 파일시스템 상태가 유지되고, 자격증명은 권한 위임 방식으로 격리되며, 컨텍스트는 장시간에 걸쳐 보존된다.

Sentry가 “몇 주 만에 패치 에이전트를 출시했다”는 사례가 과장이 아닐 수 있다. 이 인프라 레이어를 직접 구축하는 데 수개월이 걸리는 팀도 있으니까.

단점도 명확하다. Claude 모델만 사용할 수 있다. OpenAI나 Gemini 기반 에이전트를 병행 운영하는 팀이라면 Anthropic 종속성이 부담이 된다. 그리고 $0.08/시간은 단순해 보이지만 idle 시간이 포함되므로, 대기 시간이 긴 에이전트라면 실제 비용이 예상을 초과할 수 있다.

실행 가능성 판단: 내가 도입할까

솔직히 말하면, 지금 당장 Opus 4.7로 전체 전환하지는 않겠다.

안전성 오버핏 이슈가 개인적으로 운영하는 자동화 시스템에서 어떻게 발현될지 아직 확인되지 않았다. 이 블로그의 daily-post 에이전트가 git push, npm build, 외부 API 호출을 조합해서 사용하는데, 이런 작업을 Opus 4.7이 보수적으로 거부할 가능성이 있다.

반면 task_budget은 바로 적용해보고 싶다. 현재 장시간 에이전트가 조용히 토큰을 소모하는 문제가 있었는데, advisory budget이라도 있으면 모델이 스스로 우선순위를 조정하는 효과를 기대할 수 있다.

Managed Agents는 새 에이전트를 처음부터 만드는 프로젝트라면 진지하게 고려할 것 같다. 기존 시스템을 마이그레이션하는 비용은 정당화하기 어렵지만, 초기 설계 단계라면 세션 관리 코드를 직접 쓰는 것보다 낫다.

누구에게 Opus 4.7이 맞고, 누구에게 안 맞나

커뮤니티 피드백과 공식 문서를 종합하면 사용 적합성이 꽤 명확하게 갈린다.

Opus 4.7이 진가를 발휘하는 상황

복잡한 멀티파일 리팩토링이나 코드베이스 전체를 분석하는 에이전트 작업에서 성능 개선이 뚜렷하다고 보고된다. SWE-bench Pro에서 +10.9포인트라는 수치는 단순 자동완성이 아니라 장시간 자율 작업에서 나온 결과다. 대형 레거시 코드베이스 마이그레이션, 테스트 커버리지 자동 확장, 보안 취약점 분석처럼 “아무도 하기 싫어하는 대규모 코딩 작업”에서는 도움이 된다.

고해상도 이미지 지원도 특정 팀에게는 실질적 개선이다. UI 자동화 테스트 에이전트가 화면 전체를 분석하거나, 문서 OCR 에이전트가 고해상도 스캔본을 처리하는 경우, 2576px 지원이 직접적인 정확도 향상으로 이어진다.

Opus 4.7을 피해야 하는 상황

일상적인 코딩 보조 작업에는 과도하다. “이 함수 리팩토링해줘”나 “타입 오류 고쳐줘” 수준의 작업은 Claude Sonnet 4.6이 더 빠르고 비용도 낮다. 새 토큰나이저로 비용이 실질적으로 오른 상황에서 단순 작업까지 Opus 4.7로 처리하면 예산이 불필요하게 소모된다.

창의적 글쓰기나 자유 형식 추론도 논란이다. 명령 해석이 경직되고 출력이 불릿 포인트 중심으로 변한 경향이 있어서, 유연한 창작 작업에는 이전 버전이 낫다는 피드백이 있다.

안전성 오버핏이 발생하는 작업 유형도 피해야 한다. 네트워크 요청, 시스템 파일 접근, 외부 API 통합이 포함된 에이전트에서 예상치 못한 거부가 발생할 수 있다. 이것이 실제로 얼마나 자주 일어나는지는 아직 충분한 데이터가 없다.

이번 달 Anthropic 릴리스의 더 큰 그림

4월 Anthropic 릴리스를 하나의 서사로 읽으면 흥미롭다. 지난달 성능 저하 논란으로 커뮤니티 신뢰가 흔들렸을 때, Anthropic은 한 달 만에 벤치마크 개선 수치와 함께 돌아왔다.

하지만 개발자들의 반응은 “숫자보다 실무가 더 중요하다”는 방향으로 성숙해지고 있다. SWE-bench가 높다고 해서 내 코드베이스에서도 잘 동작한다는 보장은 없고, “legendarily bad” 같은 피드백은 무시하기 어렵다.

Managed Agents의 성공 사례(Notion, Rakuten, Sentry)는 인상적이지만, 이 숫자들은 이전에 특히 불안정한 인프라를 운영하던 팀의 비교 수치라는 맥락을 봐야 한다. 모든 팀에게 90% 개선이 돌아오는 건 아니다.

내 결론: Opus 4.7은 코딩 벤치마크상 명확한 개선이지만 실무 전환은 신중하게. task_budget과 xhigh 노력 레벨은 에이전트 비용 제어에 실질적 도움이 될 수 있다. Managed Agents는 새 프로젝트 시작 시점에서 진지한 대안이다. 그리고 새 토큰나이저 비용 영향은 반드시 직접 계산해봐야 한다.

두 달 치 릴리스를 한 달에 소화하는 건 쉽지 않다. 하지만 Anthropic이 “모델”과 “인프라” 두 축을 동시에 올리는 전략이 어디로 향하는지는 지켜볼 만하다.

개인적으로는 다음 한 달 동안 두 가지를 직접 해볼 생각이다. 하나는 기존 블로그 자동화 에이전트 중 가장 오래 실행되는 daily-post 에이전트에 task_budget을 실험적으로 붙여보는 것이다. advisory 방식이 실제 토큰 사용 패턴에 어떤 영향을 주는지 데이터로 확인하고 싶다. 다른 하나는 새 사이드 프로젝트 에이전트를 설계할 때 Managed Agents를 기본 인프라로 가져가보는 것이다. 기존 시스템 마이그레이션이 아니라 백지에서 시작하는 경우라면, 세션 관리 코드를 직접 쓰는 대신 Managed Agents 위에서 비즈니스 로직에만 집중해보는 게 맞는 판단인지 실제로 확인해야 한다.

결론적으로 이번 4월은 Anthropic에게도, 에이전트 개발자에게도 중요한 분기점이다. “에이전트를 어떻게 만들 것인가”라는 질문에 Anthropic이 모델과 인프라 양쪽에서 동시에 답안을 제시했다. 그 답안이 완벽하지 않더라도, 질문 자체는 옳다.

---

실행 가능성 판단 (Source Review 기준)

이 글에서 소개한 task_budget 코드 예시와 Managed Agents 기능 설명은 공식 문서(platform.claude.com/docs)와 릴리스 노트를 기반으로 작성했다. Anthropic API 키 없이 직접 실행 환경을 구성하지 못했으므로, 실제 task_budget의 advisory 동작이나 세션 비용 청구 방식은 직접 검증하지 않았다. “문서상 설계와 공개 사례 기준”으로 판단한 내용임을 명시한다.