Anthropic은 2026년 5월 6일 Claude Managed Agents 업데이트에서 Dreaming, Outcomes, multiagent orchestration, webhooks를 공개했다. 이름만 보면 새 기능 4개지만, 실제 변화는 에이전트 운영에서 사람이 따로 만들던 기억 정리, 품질검수, 병렬 위임, 완료 알림이 플랫폼 기능으로 들어오기 시작했다는 점이다.
개발자 입장에서는 “모델이 더 똑똑해졌다”보다 “하네스가 제품 기능이 되고 있다”가 더 중요하다. 지금까지는 에이전트를 오래 굴리려면 메모리 정리 스크립트, grader 프롬프트, 서브에이전트 라우팅, Slack이나 webhook 알림을 직접 엮어야 했다. Managed Agents 업데이트는 이 주변 실행 계층을 Claude Platform 안으로 끌어들이는 흐름이다.
지금 바로 봐야 할 결론은 단순하다. Dreaming은 기억 정리, Outcomes는 기준표 기반 자기검수, multiagent orchestration은 리드 에이전트와 전문 서브에이전트 분업, webhooks는 완료 이벤트 알림이다. 네 기능 모두 멋있지만, 프로덕션 적용 전에는 접근 권한, 비용, 로그, 실패 복구 기준을 따로 확인해야 한다.
4종 기능을 운영 언어로 번역하기
| 기능 | 공식 발표의 핵심 | 운영자가 봐야 할 질문 |
|---|---|---|
| Dreaming | 과거 세션과 메모리를 검토해 패턴을 찾고 기억을 정리하는 research preview | 어떤 기억을 자동 반영하고, 어떤 변경은 사람이 승인할까 |
| Outcomes | 성공 기준 rubric을 쓰면 별도 grader가 결과를 평가하고 agent가 다시 고친다 | “좋음”을 어떤 체크리스트로 표현할 수 있나 |
| Multiagent orchestration | lead agent가 전문 subagent에게 일을 나눠 병렬 처리한다 | 공유 파일시스템, 권한, trace를 어떻게 통제할까 |
| Webhooks | outcome 완료 시 알림을 받을 수 있다 | 완료, 실패, 재시도, 사람 승인 이벤트를 어디로 보낼까 |
Dreaming은 제일 매력적이면서 제일 조심해야 할 기능이다. 공식 글은 Dreaming을 scheduled process로 설명한다. 에이전트 세션과 memory store를 검토하고, 반복 실수, 수렴한 워크플로, 팀 선호를 찾아 기억을 정리한다. 긴 작업을 계속 돌리는 팀에서는 이 기능이 “지난번 삽질을 또 하지 말자”에 가깝다.
다만 기억 자동 업데이트는 편한 만큼 위험하다. 에이전트가 잘못 배운 규칙, 임시 예외, 특정 프로젝트에만 맞는 선호를 전역 기억으로 올리면 다음 작업이 조용히 비뚤어진다. 그래서 Dreaming을 쓴다면 auto-update보다 review-before-landing 경로가 먼저다. 기억도 배포물이다. 배포물은 리뷰한다. 여기서 낭만 챙기면 나중에 로그가 복수한다.
Outcomes는 블로그 파이프라인이나 문서 생성 작업에 바로 떠오르는 기능이다. 공식 설명대로라면 사용자가 성공 기준 rubric을 쓰고, 별도 grader가 자기 context window에서 결과를 평가한다. agent가 만든 산출물을 agent의 추론에 휘둘리지 않는 평가자가 다시 보는 구조다. TECHTAEK 식으로 말하면 “작가와 리뷰어를 분리하라”가 제품 기능으로 들어간 셈이다.
Anthropic은 내부 테스트에서 Outcomes가 표준 prompting loop 대비 어려운 작업에서 task success를 최대 10점 높였고, docx는 +8.4%, pptx는 +10.1% 개선됐다고 밝혔다. 이 수치는 공급사 내부 벤치마크라 독립 검증처럼 쓰면 안 된다. 대신 방향은 분명하다. 산출물 품질은 모델명 하나보다 평가 기준과 재시도 루프에서 많이 갈린다.
Multiagent orchestration은 리드 에이전트가 일을 나눠 맡기는 구조다. 공식 예시는 deploy history, error logs, metrics, support tickets를 각 subagent가 병렬로 조사하고 lead agent가 패턴만 모으는 식이다. 이건 기존 “한 프롬프트에 다 넣고 기다리기”와 다르다. 잘게 쪼개야 빠르고, 다시 합치는 기준이 있어야 망하지 않는다.
Webhooks는 덜 화려하지만 운영에서는 꽤 중요하다. 에이전트가 완료됐는지 사람이 계속 들여다보는 구조는 장기 작업에 약하다. outcome을 정의하고 agent를 돌린 뒤 완료 이벤트를 webhook으로 받으면, Slack, Discord, 내부 대시보드, 노션 큐, CI 후속 작업과 연결할 수 있다. 결국 에이전트는 대화창을 벗어나 이벤트 시스템으로 들어가야 오래 산다.
내 하네스에 붙인다면 무엇부터 바꿀까
첫 번째 후보는 Outcomes다. 블로그 글, 리서치 요약, 문서 생성, 코드 리뷰처럼 기준표가 있는 작업은 성공 조건을 문장으로만 말하지 말고 rubric으로 내려야 한다. 예를 들어 TECHTAEK 글이라면 순수 뉴스요약 금지, 실사용·비용·실패·워크플로·설정 분리 중 2개 이상, FAQ와 공식 출처 필수, 금지 헤더 제거 같은 항목을 evaluator가 체크하게 만들 수 있다.
두 번째 후보는 multiagent orchestration이다. 하지만 모든 작업을 서브에이전트로 쪼개면 오히려 느려진다. 쪼갤 가치가 있는 작업은 정보원이 다르거나, 파일 범위가 다르거나, 평가 기준이 다른 경우다. 예를 들어 한 agent는 공식 문서만 확인하고, 다른 agent는 기존 vault 글과 내부 링크를 찾고, lead agent는 최종 구조를 잡는 식이면 역할이 산다.
세 번째 후보는 webhook이다. 완료 알림은 장난감 기능처럼 보이지만, 실제 운영에서는 병목을 줄인다. 장기 리서치, batch eval, 이미지 렌더링, 문서 변환, 테스트 수정처럼 몇 분 이상 걸리는 작업은 사람이 화면을 보고 기다리면 손해다. 완료, 실패, 사람 승인 필요, 재시도 초과를 이벤트로 분리하면 운영 루프가 훨씬 깔끔해진다.
Dreaming은 마지막에 둔다. 이유는 간단하다. 기억은 강력하지만, 잘못된 기억은 조용히 오래 간다. 먼저 memory schema, 승인 방식, 삭제 정책, 프로젝트별 범위, 개인정보 보관 기준을 세운 뒤에 켜야 한다. 특히 고객 데이터, 금융 데이터, 내부 의사결정 기록이 섞인 에이전트라면 “스스로 기억한다”는 말이 바로 “무엇을 어디까지 보관하나”로 바뀐다.
도입 전에 확인할 실패 지점
가장 먼저 접근 상태를 확인해야 한다. 공식 글 기준 Dreaming은 research preview이고 접근 요청이 필요하다. Outcomes, multiagent orchestration, memory는 Managed Agents의 public beta로 안내된다. 즉 문서에 있다고 모든 계정에서 바로 쓰는 전제가 아니다. 이걸 안 보고 글을 쓰면 독자는 버튼 찾다가 책상과 친해진다.
두 번째는 비용이다. multiagent orchestration은 일을 나눠 병렬로 처리한다. 병렬은 빠르지만 모델 호출도 늘어난다. Outcomes는 grader와 재시도 루프가 붙는다. Dreaming은 세션과 memory store를 주기적으로 검토한다. 각각은 합리적이어도 합치면 “왜 이번 달 청구서가 발표자료처럼 커졌지?”가 될 수 있다.
세 번째는 trace와 감사로그다. 여러 subagent가 공유 파일시스템에서 움직이면 누가 어떤 판단으로 어떤 파일을 건드렸는지 남아야 한다. 공식 글은 Claude Console에서 어떤 agent가 무엇을 어떤 순서로 왜 했는지 추적할 수 있다고 설명한다. 이 trace가 실제 운영 감사, 고객 설명, 장애 복구에 충분한지 봐야 한다.
네 번째는 실패 복구다. Outcomes가 실패를 찾아도 agent가 계속 같은 방향으로 고치면 루프가 길어진다. webhook이 완료만 보내고 실패 이벤트를 잘 안 나누면 사람이 놓친다. Dreaming이 잘못된 기억을 올리면 다음 세션에서 반복된다. 그래서 retry limit, human escalation, memory rollback, artifact versioning을 같이 설계해야 한다.
블로그와 개발 워크플로에 적용하는 작은 실험
작게 시작한다면 “리드 에이전트 1개 + 리서치 2개 + grader 1개” 구조가 좋다. 리드 에이전트는 글의 질문과 성공 기준을 정한다. 리서치 agent 1은 공식 문서만 확인한다. 리서치 agent 2는 기존 발행 글과 내부 허브 연결을 찾는다. grader는 draft가 채널 규칙과 fact table을 통과하는지 본다.
코드 작업에서는 “이슈 재현 agent + 수정 agent + 리뷰 agent”로 나눌 수 있다. 이슈 재현 agent는 테스트와 로그만 본다. 수정 agent는 작은 diff를 만든다. 리뷰 agent는 권한, 보안, 회귀 위험을 본다. lead agent는 세 결과를 합쳐 merge 후보인지 판단한다. 이 구조는 무조건 빠르진 않지만, 실패가 어디서 났는지 보기 쉬워진다.
문서 작업에서는 Outcomes가 특히 잘 맞는다. “본문 2,800자 이상”, “FAQ 있음”, “공식 출처 있음”, “금지 헤더 없음”, “가짜 1인칭 없음” 같은 조건은 rubric으로 바꾸기 쉽다. 사람 리뷰어가 매번 같은 체크를 반복하는 영역부터 grader에게 넘기면 효율이 나온다.
다만 모든 자동화를 Managed Agents로 옮길 필요는 없다. 개인 vault 안에서 파일 하나 고치는 일, 빠른 요약, 단발성 리서치는 기존 Claude Code나 Codex 세션으로도 충분하다. Managed Agents는 장기 세션, 반복 품질검수, 팀 표준, 이벤트 알림이 필요한 곳에서 빛난다.
언제 발행 가치가 있고, 언제 보류해야 하나
이 주제는 새 기능 정리만 하면 TECHTAEK 기준에 못 미친다. Dreaming, Outcomes, multiagent orchestration, webhooks의 기능명을 나열하는 글은 이미 공식 블로그가 더 잘한다. 발행 가치가 생기는 지점은 하네스 운영표다. 어떤 기능을 어디에 붙이고, 비용과 실패 복구를 어떻게 볼지까지 써야 한다.
발행해도 되는 각도는 “AI 에이전트 운영 체크리스트”다. 기억, 평가, 위임, 알림을 각각 운영 책임으로 번역하면 실사용, 워크플로, 실패, 설정 분리 기준이 살아난다. 반대로 “앤트로픽 새 기능 대박” 같은 제목은 드롭이다. 그건 TECHTAEK가 아니라 알림창이다. 알림창은 이미 우리 폰이 열심히 하고 있다.
FAQ
Dreaming은 Claude가 자는 동안 생각한다는 뜻인가?
비유로는 그렇게 말할 수 있지만, 공식 설명은 scheduled memory curation에 가깝다. 과거 세션과 memory store를 검토해 패턴을 찾고 기억을 정리하는 기능이다.
Outcomes는 기존 eval과 뭐가 다른가?
rubric을 성공 기준으로 두고, 별도 grader가 산출물을 평가한 뒤 agent가 다시 수정하는 루프가 핵심이다. 단순 사후 점수표보다 작업 완료 과정에 평가가 들어간다.
Multiagent orchestration은 그냥 subagent 여러 개 띄우는 것과 같나?
비슷해 보이지만 lead agent가 전문 subagent에게 일을 나누고, 병렬 결과를 전체 context로 모으는 구조가 중요하다. trace와 공유 파일시스템, 권한 기준도 같이 봐야 한다.
Webhooks는 왜 중요한가?
장기 작업은 사람이 화면을 지켜보면 운영이 깨진다. 완료, 실패, 승인 필요 같은 이벤트를 외부 시스템으로 보내야 큐, 알림, 후속 자동화가 이어진다.
지금 바로 프로덕션에 넣어도 되나?
아직은 작은 실험부터가 맞다. Dreaming은 research preview이고, Managed Agents 자체도 접근 권한과 베타 상태를 확인해야 한다. 비용, 로그, 실패 복구, memory 승인 정책 없이 바로 넣는 건 빠른 도입이 아니라 빠른 혼란이다.
공식 출처
- Anthropic – New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration
- Anthropic – Claude Managed Agents: get to production 10x faster
- Threads 원문 캡처 출처