Claude Managed Agents: Dreaming·Outcomes·멀티에이전트로 자기 개선하고 자기 평가하는 에이전트 운영 패턴

왜 에이전트 메모리는 쌓일수록 나빠지는가

에이전트가 작업을 반복하다 보면 메모리 스토어는 두꺼워진다. 첫 주에 쓴 사용자 선호가 다음 주에 모순되는 내용으로 덮어 씌워지고, 한 번만 있었던 예외 상황이 반복적인 패턴인 것처럼 기록되고, 여러 세션이 같은 사실을 각자 다른 방식으로 적는다. 표준 메모리 API는 세션 안에서 증분 기록을 담당할 뿐, 축적된 노이즈를 스스로 정리하지는 않는다.

사람이 수면 중에 기억을 통합하고 불필요한 정보를 걸러낸다는 신경과학 이론에서 이름을 빌려, Anthropic은 2026년 5월 6일 Code with Claude 개발자 컨퍼런스에서 세 가지 기능을 공개했다.

• Dreaming — 과거 세션과 메모리 스토어를 비동기 파이프라인으로 분석해 정제된 메모리 스토어를 새로 만드는 기능 (연구 프리뷰)
• Outcomes — 루브릭(채점 기준)을 정의하면 별도 grader 에이전트가 결과물을 평가하고 부족한 점을 피드백하는 반복 개선 루프 (공개 베타)
• 멀티에이전트 오케스트레이션 — 하나의 리드 에이전트가 전문 서브에이전트를 병렬로 생성하고 조율하는 기능 (공개 베타)

Dreaming: 메모리 정제의 비동기 파이프라인

Dreams API 아키텍처

Dreaming은 POST /v1/dreams 엔드포인트로 시작하는 비동기 잡이다. 요청에는 다음 두 가지 입력이 필요하다.

• memory_store (필수) — 정리 대상 메모리 스토어 ID
• sessions (선택, 최대 100개) — 패턴을 추출할 과거 세션 트랜스크립트 ID 배열

드리밍 파이프라인은 입력 메모리 스토어를 절대 수정하지 않는다. 대신 별도 출력 메모리 스토어를 생성한다. 이 출력 스토어의 ID는 꿈이 running 상태로 전환된 직후 outputs[] 배열에서 확인할 수 있다.

instructions 파라미터로 합성 방향을 조정할 수 있다. "코딩 스타일 선호에 집중하고, 일회성 디버깅 메모는 무시하라"처럼 고수준 지시가 유효하다. 특정 줄을 수정하라는 명령은 합성 패스 특성상 적용되지 않는다.

드리밍 수명 주기

드리밍은 session_id로 내부 파이프라인 세션을 참조한다. 이 세션에서 이벤트를 스트리밍하면 무엇을 읽고 쓰는지 실시간으로 관찰할 수 있다.

멀티에이전트 드리밍 패턴

20개의 서브에이전트가 같은 도메인에서 동시에 작업하는 환경을 생각해보자. 각 에이전트는 자신의 세션에서 독립적으로 메모리를 쌓는다. 드리밍은 이 에이전트들의 세션을 일괄 입력으로 받아, 개별 에이전트가 혼자서는 볼 수 없는 패턴을 팀 단위 메모리 스토어로 합성한다. 반복되는 실수, 에이전트들이 수렴하는 워크플로우, 팀 공통 선호를 추출해 공유 메모리 스토어에 발행하는 방식이다.

# 팀 공유 드리밍 예시
dream = client.beta.dreams.create(
    inputs=[
        {"type": "memory_store", "memory_store_id": team_store_id},
        {"type": "sessions", "session_ids": all_agent_session_ids},  # 최대 100개
    ],
    model="claude-opus-4-8",
    instructions="코딩 스타일 공통 패턴 추출; 개인 선호는 무시",
)

운영 제약

• 드리밍은 연구 프리뷰이며 접근 요청이 필요하다 (claude.com/form/claude-managed-agents)
• 지원 모델: claude-fable-5, claude-opus-4-8, claude-opus-4-7, claude-sonnet-5, claude-sonnet-4-6
• instructions 최대 4,096자, 세션 최대 100개
• 비용은 선택한 모델의 표준 토큰 요금 적용
• dreaming-2026-04-21 베타 헤더를 managed-agents-2026-04-01과 함께 전송해야 한다

Outcomes: 루브릭 기반 자기 평가 루프

왜 루브릭이 필요한가

"최선을 다해 분석 리포트를 작성해라"는 지시는 에이전트가 언제 완료인지 판단하기 어렵다. Outcomes는 "완료"의 기준을 명시적 채점 기준(rubric)으로 표현하고, 별도 grader 에이전트가 이 기준에 따라 결과물을 독립적으로 평가한다.

루프 아키텍처

user.define_outcome 이벤트

세션 생성 후 user.define_outcome 이벤트를 전송하면 에이전트가 즉시 작업을 시작한다. 별도 사용자 메시지 없이 에이전트 자율 실행이다.

client.beta.sessions.events.send(
    session_id=session.id,
    events=[{
        "type": "user.define_outcome",
        "description": "Costco에 대한 DCF 모델을 .xlsx 형식으로 작성",
        "rubric": {"type": "text", "content": rubric_markdown},
        # 또는 Files API로 업로드한 파일: {"type": "file", "file_id": rubric_file_id}
        "max_iterations": 5,  # 선택, 기본 3, 최대 20
    }]
)

Outcome 이벤트 스트림

span.outcome_evaluation_end의 result가 needs_revision이면 피드백이 에이전트에게 전달되고 다음 이터레이션이 자동 시작된다. satisfied이면 세션이 idle로 전환된다.

루브릭 작성 지침

루브릭은 채점 가능한 기준으로 구성해야 한다. "데이터가 좋아 보인다" 대신 "가격 컬럼에 숫자 값이 있다"처럼 구체적이고 독립적으로 채점할 수 있어야 한다. Anthropic 내부 벤치마크에서 Outcomes 적용 후 전반적 작업 성공률이 최대 +10 포인트 향상됐고, .pptx 생성에서 +10.1%, .docx에서 +8.4% 개선이 보고됐다.

멀티에이전트 오케스트레이션

멀티에이전트 오케스트레이션은 리드 에이전트가 전문 서브에이전트를 생성하고 병렬로 실행하며, 결과를 수집하고 합성하는 패턴이다. 이 기능은 공개 베타로, managed-agents-2026-04-01 헤더만으로 사용 가능하다.

Harvey 법률 서비스는 드리밍을 적용한 뒤 작업 완료율이 약 6배 증가했고, 의료 문서 검토 회사 Wisedocs는 Outcomes 적용 후 문서 검토 시간을 50% 단축했다고 보고했다.

세 기능을 연결하는 운영 패턴

패턴 1: 드리밍 → 정제 메모리 → 더 나은 에이전트

[일일 에이전트 세션 실행] → 세션 축적
↓ (주 1회 또는 필요 시)
[Dreams API 호출] → sessions[] 최근 50개 + 기존 메모리 스토어
↓
[출력 메모리 스토어 검토] → Console 또는 Memory Stores API로 확인
↓
[검토 통과] → 다음 세션에서 출력 스토어 연결

패턴 2: Outcomes → 루브릭 채점 → 고품질 산출물

[user.define_outcome 이벤트] → 루브릭 + 설명 + max_iterations
↓
[에이전트 작업] → /mnt/session/outputs/ 에 파일 저장
↓
[Grader 평가] → span.outcome_evaluation_end
↓ needs_revision
[에이전트 재작업] → 피드백 반영
↓ satisfied 또는 max_iterations_reached
[Files API로 산출물 수집] → GET /v1/files?scope_id={session_id}

패턴 3: 멀티에이전트 + 드리밍 → 집단 학습

서브에이전트가 각자 메모리를 쌓고, 드리밍이 팀 공유 스토어를 갱신하는 주기로 집단 지식이 누적된다.

보안 고려사항

드리밍은 100개 세션 트랜스크립트를 포함한 다량의 데이터를 파이프라인에 입력한다. 세션에 민감한 자격증명이나 PII가 포함되어 있다면 메모리 스토어로 합성될 위험이 있다. 운영자는 다음을 확인해야 한다.

• 세션 트랜스크립트에서 민감 데이터가 메모리 쓰기 전에 마스킹되는지
• instructions에 보안 필터 지침 포함 가능 여부
• 드림 출력 스토어를 연결하기 전 반드시 검토하는 절차 수립

Outcomes의 grader는 메인 에이전트와 별도 컨텍스트 창을 사용하므로 메인 에이전트의 구현 선택에 의해 채점이 편향되지 않는다. 다만 루브릭 자체가 완성도의 상한선이 되므로 루브릭 품질이 결과물 품질을 결정한다.

운영 체크리스트

• [ ] managed-agents-2026-04-01 베타 헤더 설정 (멀티에이전트, Outcomes)
• [ ] Dreaming 접근 신청 및 dreaming-2026-04-21 베타 헤더 추가
• [ ] 드림 입력 세션 수 설계 (소수로 시작해 품질 확인 후 확대)
• [ ] 드림 출력 스토어 검토 → 연결 또는 폐기 절차 수립
• [ ] Outcomes 루브릭 세분화: 채점 가능한 구체적 기준 작성
• [ ] max_iterations 비용/시간 예산과 맞춰 설정
• [ ] 세션 아웃풋 파일 수집: GET /v1/files?scope_id={session_id}
• [ ] 멀티에이전트 팀 공유 메모리 스토어 설계 (개인 vs. 팀 분리)

References

• New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration — Anthropic Blog
• Dreams API — Claude Platform Docs
• Define Outcomes — Claude Platform Docs
• Anthropic Launches Dreaming for Claude Agents — Let's Data Science
• Anthropic will let its managed agents dream — The New Stack
• Claude Agents Can Now Dream — Ken Huang / Substack
• Scaling Managed Agents: Decoupling the brain from the hands — Anthropic Engineering