Evolution of agentic surfaces — Gagan Bhat & Isabella Kai He, Anthropic

URL: https://www.youtube.com/watch?v=K0X9QDRkIdg
날짜: 2026-08-12
채널: aiDotEngineer
발표자: Gagan Bhat, Isabella Kai He (Anthropic Applied AI 팀)
원본 발행일: 2026-08-11
영상 길이: 31분 23초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==모델이 빠르게 진화할수록 제품의 에이전트 표면(agentic surface)과 하네스(harness)도 함께 진화해야 하며, 개발자가 제품·업무·도메인 지식에 집중하도록 에이전트 운영 인프라를 분리해 제공해야 한다.==

• 모델에 주는 작업은 단순 Q&A에서 위임된 작업, 전체 결과(outcome)의 소유로 복잡해졌다.
• Messages API는 토큰 입출력만 제공했고, Claude Agent SDK는 에이전트 루프와 도구 실행의 기본 뼈대를 제공했지만 운영 인프라는 여전히 고객의 몫이었다.
• Claude Managed Agents는 에이전트의 두뇌(brain)와 손(hands)을 분리하고, 세션·샌드박스·자격 증명·관찰 가능성·확장성을 관리형 인프라로 묶는다.

이 발표는 Anthropic Applied AI 팀이 내부와 엔터프라이즈 고객 환경에서 에이전트를 만들며 얻은 교훈을 시간순으로 설명한다. 먼저 에이전트 표면의 세 단계 진화를 살펴보고, Managed Agents의 내부 설계 원칙과 SRE 데모를 거친 뒤, 자격 증명·지연시간·세션 로그·실행 보안에 관한 현장 교훈과 dreaming·outcomes 같은 다음 단계 기능을 소개한다.

1. 에이전트 표면은 모델과 작업의 복잡성을 따라 진화한다

모델 능력과 작업 복잡성이 함께 상승하면서, 단순한 모델 호출만으로는 장시간 실행·도구 사용·상태 관리·운영 안정성을 감당할 수 없게 됐다.

1.1. AI 발전과 작업의 변화

1. 모델 발전은 가속되고 있다

   1. Transformer 아키텍처의 등장, Anthropic 창업자들이 발견한 scaling laws, 현재의 모델 릴리스까지 발전 속도는 계속 빨라졌다.
   2. 새로운 모델이 나올 때마다 이전 모델에는 없던 능력이 추가되며, 현장에서 그 차이를 체감한다.

2. 모델에 맡기는 일의 수준이 올라갔다

   1. 초기에는 단순 질문과 Q&A만 제공했다.
   2. 다음 단계에서는 모델에게 특정 작업을 위임했다.
   3. 현재는 에이전트가 단일 답변이 아니라 전체 결과(outcome)를 책임지도록 한다.
   4. 따라서 모델의 능력과 과업 복잡도가 개선될수록 이를 담는 agentic surface도 같은 속도로 바뀌어야 한다.

1.2. 1단계: Messages API와 수동 에이전트 루프

1. Messages API의 출발점

   1. Claude 3와 함께 등장한 첫 에이전트 표면이다.
   2. 기본 형태는 tokens in → tokens out이었다. 정보를 입력하면 텍스트 completion을 반환할 뿐, 장기 실행을 위한 실행 환경은 제공하지 않았다.

2. 고객이 직접 만든 agentic loop

   1. 작업이 길어지면서 모델이 정보를 가져오고 실행 중 context를 관리해야 했다.
   2. 각 고객은 Claude를 호출하고, 도구를 실행하고, 결과를 다시 모델에 넣고, context를 관리하는 루프를 처음부터 손으로 만들었다.
   3. 이 루프는 구현과 유지가 고통스러웠고, 제품의 AI 기능은 이 루프 위에서 실제 업무를 수행해야 했다.

3. 프로덕션 전환의 숨은 비용

   1. 세션 관리(session management): 실행 이력과 진행 상태를 보존해야 했다.
   2. 관찰 가능성(observability): 복잡한 오케스트레이션 안에서 실제로 무슨 일이 일어났는지 추적해야 했다.
   3. 자격 증명(credentials): 민감한 시스템에 접근하면서 보안 토큰을 모델에 노출하지 않아야 했다.
   4. 호스팅·확장(hosting and scaling): 에이전트가 어디서 얼마 동안 실행되고, 부하가 커질 때 무엇이 확장되는지 결정해야 했다.
   5. 샌드박싱(sandboxing)과 실행 격리: 에이전트가 작성한 코드를 어디서 실행할지, 어떻게 안전하게 제한할지 해결해야 했다.
   6. 이 인프라 작업은 팀이 제품 자체보다 운영 문제에 시간을 쓰게 만들었다.

1.3. 2단계: Claude Agent SDK

1. 기본 하네스의 패키징

   1. Claude Agent SDK는 Anthropic이 알고 있는 효과적인 하네스, 특히 Claude Code의 실행 방식을 패키징했다.
   2. 내장 agentic loop, 파일 시스템 접근, 도구, 샌드박싱 시스템을 제공해 고객이 처음부터 루프를 만들 필요를 줄였다.

2. 여전히 남은 고객의 책임

   1. SDK를 제품에 임베드해야 했다.
   2. 세션 관리와 관찰 가능성의 일부 primitive는 제공됐지만, 자격 증명과 호스팅 인프라는 여전히 직접 구현해야 했다.
   3. 고객은 에이전트를 어떤 박스에 넣고 어떻게 대규모 사용자에게 확장할지 결정해야 했다.

3. 생각을 자극하는 운영 질문

   1. 호스팅·확장: 에이전트와 프로세스는 어디서 실행되며, 프로세스는 얼마나 오래 살아 있는가? 부하 아래에서 무엇이 확장되고 무엇이 병목이 되는가?
   2. 세션 관리: 세션의 이력과 진행 상황은 어디에 저장되는가? 대규모 환경에서 여러 에이전트를 동시에 실행할 수 있는가?
   3. 파일 시스템: Claude가 파일을 만들고 수정할 수 있도록 어떻게 접근 권한을 부여하는가?
   4. 실행 격리: Claude가 작성한 코드는 실제로 어디서 실행되며, 그 실행을 어떻게 안전하게 유지하는가?
   5. 자격 증명: 모델이 보호해야 할 보안 토큰을 보지 않고 민감한 내부 시스템에 접근하게 하려면 어떻게 해야 하는가?
   6. 관찰 가능성: 복잡한 에이전트 오케스트레이션의 내부 동작을 어떻게 파악하는가?

1.4. 3단계: Claude Managed Agents

1. 책임의 경계 재설정

   1. 개발자는 제품(product), task, context, 도메인 지식을 소유한다.
   2. Claude Managed Agents는 에이전트에 필요한 production-grade 인프라를 제공한다.
   3. 즉 제품 팀은 무엇을 만들고 어떤 업무를 해결할지 정의하고, Anthropic이 반복적으로 관리해야 하는 실행 기반은 서비스가 담당한다.

2. 두뇌와 손의 비유

   1. **두뇌(brain)**는 Claude 자체, agentic loop, 내부에서 진화하는 custom harness다.
   2. **손(hands)**은 파일 시스템 접근과 코드 실행에 필요할 때 즉시 생성되는 sandbox다.
   3. 자격 증명, 세션 관리, 관찰 가능성, 호스팅 인프라 같은 운영 요소도 Anthropic이 맡는다.

3. 세 단계의 요약

   1. Messages API는 모델과 토큰을 주고받는 표면이다.
   2. Claude Agent SDK는 task를 수행하기 위한 내장 agent harness를 추가했다.
   3. Claude Managed Agents는 제품이 필요로 하는 영역과 그 아래의 실행·운영 스택을 함께 다룬다.

2. Managed Agents를 만든 설계 원칙

Managed Agents의 핵심은 현재 모델을 고정하는 것이 아니라, 내일의 모델 능력을 빠르게 받아들일 수 있는 교체 가능한 장기 실행 하네스를 만드는 데 있다.

2.1. 하네스는 모델의 한계에 대한 가설이다

1. 하네스에는 ‘Claude가 혼자 할 수 없는 일’에 대한 가정이 들어간다

   1. Context reset, compaction 관리, 메모리, 실행 순서 같은 primitive는 모델의 부족한 부분을 보완하기 위해 하네스에 추가된다.
   2. 그러나 이 가정은 모델이 개선되면 빠르게 낡기 때문에 자주 검증해야 한다.

2. Context anxiety 사례

   1. Sonnet 4.5는 context window 한도에 가까워지면 실제 여유 공간이 남아 있어도 불안해하는 듯한 동작을 보였다.
   2. 에이전트는 작업을 일찍 마무리하거나, 아직 할 일이 남았는데도 실행을 종료했다.
   3. 팀은 이를 보완하기 위해 하네스에 context reset을 넣어 Sonnet 4.5가 context를 초기화하고 계속 작업하도록 했다.

3. 더 강한 모델이 기존 보정을 무효화한다

   1. Opus 4.5에서는 context anxiety가 완전히 사라졌다.
   2. Sonnet 4.5를 위해 넣었던 reset은 더 이상 필요하지 않은 dead weight가 됐다.
   3. 오히려 지연시간을 추가하고, 캐시가 잘못 폐기되는 문제를 만들 수 있었다.
   4. 결론은 모델은 이동했는데 하네스가 움직이지 않으면 하네스가 에이전트 성능을 떨어뜨린다는 것이다.

2.2. 미래 능력을 전제로 한 민첩한 하네스

1. 고객 하네스에서 관찰된 격차

   1. 일부 고객 하네스는 새 모델에 맞게 민첩하게 바뀐다.
   2. 다른 하네스는 오래된 Claude 모델을 기준으로 만들어져 더 경직돼 있다.
   3. 모델 릴리스 주기가 계속 짧아지는 상황에서 새 모델로 옮기는 데 수주나 수개월이 걸리는 stale harness는 문제가 된다.

2. Managed Agents의 구조적 대응

   1. 내일의 Claude 모델이 할 수 있을 일을 미리 예상해 하네스를 설계한다.
   2. 새 능력이 준비되는 즉시 반영할 수 있도록 반복(iteration)을 쉽게 만든다.
   3. 전체 아키텍처는 안정적으로 유지하되, 작은 primitive와 독립된 개별 컴포넌트로 구성한다.
   4. 각 컴포넌트를 다른 구현으로 교체하거나 개별적으로 개선할 수 있다.

2.3. 장기 실행 에이전트를 위한 요구사항

1. 업무 형태의 변화

   1. Claude Code와 Anthropic 내부의 다른 에이전트 제품(자막상 Claude Tag로 인식됨), 그리고 엔터프라이즈 고객의 제품에서 공통 패턴이 나타난다.
   2. 에이전트는 점점 비동기(asynchronous)가 되고, 더 복잡하고 어려운 작업을 맡는다.

2. 하네스가 제공해야 할 능력

   1. 긴 작업 동안 context가 축적되므로 context engineering을 잘해야 한다.
   2. 에이전트가 실제로 행동할 수 있도록 안전한 sandbox를 제공해야 한다.
   3. 수시간 또는 수일 동안 실행돼도 버틸 수 있는 신뢰성이 필요하다.
   4. 복잡한 문제의 여러 부분을 동시에 처리하도록 workflow를 병렬화해야 한다.

3. 핵심 아키텍처: 두뇌와 손의 분리

처음에는 agent loop와 tool execution을 하나의 컨테이너에 넣었지만, 실행 환경의 준비와 장애가 추론 자체를 막았다. 이를 분리함으로써 지연시간·신뢰성·복구성을 함께 개선했다.

3.1. 한 박스에 넣었을 때의 한계

1. 추론 시작이 컨테이너 준비에 종속된다

   1. 같은 환경에서 루프와 도구를 실행하면 도구를 호출하기는 쉽다.
   2. 그러나 컨테이너가 완전히 준비될 때까지 에이전트가 모델 추론을 시작하거나 첫 토큰을 출력할 수 없다.

2. 장애 반경이 전체로 번진다

   1. 한 컴포넌트가 내려가면 에이전트 전체 박스가 내려간다.
   2. 긴 작업과 프로덕션 규모에서는 이런 결합이 신뢰성의 큰 제약이 된다.

3.2. brain/hands 분리의 효과

1. 독립적 수명과 지연시간

   1. brain은 agent loop와 추론을 담당하고 hands는 tool execution 환경을 담당한다.
   2. brain은 실제로 필요할 때만 세션을 만들 수 있다.
   3. sandbox가 준비되는 동안에도 모델은 즉시 추론을 시작할 수 있으며, 해당 작업에 컨테이너가 필요 없다면 준비 자체를 생략할 수 있다.

2. 교체와 복구

   1. hands가 죽으면 brain이 새 sandbox를 띄우고 재시도한 뒤 중단 지점부터 계속한다.
   2. brain이 죽어도 모든 동작이 durable session resource의 session log에 기록돼 있으므로, 새 brain이 로그를 읽고 context를 복원해 정확히 이어갈 수 있다.

3.3. 세 가지 핵심 primitive: agent, environment, session

1. Agent

   1. 사용 사례에서 에이전트가 무엇을 하는지 정의한다.
   2. 모델, system prompt, tools, skills 등 에이전트를 작동시키는 모든 요소가 포함된다.

2. Environment

   1. 에이전트가 실제로 실행되는 container 정의다.
   2. 하나의 environment 정의에 여러 session을 연결할 수 있다.
   3. 동시에 실행되는 각 session은 자기만의 격리된 container instance를 사용한다.

3. Session

   1. agent와 environment를 결합한 durable cloud resource다.
   2. 에이전트와 주고받은 모든 interaction이 저장된다.
   3. 이 구조가 관찰 가능성, 장기 실행, 신뢰성을 가능하게 한다.

3.4. 프로덕션 세션 상태와 장애 복구

1. 네 가지 상태

   1. idle: 에이전트가 사용자 입력을 기다린다.
   2. running: 에이전트가 실제 작업을 실행한다.
   3. rescheduling: 오류를 만나 재시도할 준비를 한다.
   4. terminated: 복구할 수 없는 오류로 종료된다.

2. 확장 환경에서의 의미

   1. 노트북에서 한 명의 사용자를 위해 동작하는 에이전트와, 수백·수천·수백만 사용자에게 서비스하는 프로덕션 에이전트는 전혀 다른 문제다.
   2. 수시간 실행되는 에이전트는 tool failure에서 회복해야 하며, 기존 session으로 돌아가 중단 지점부터 재개할 수 있어야 한다.

3.5. Durable session log와 context engineering

1. 기존 하네스의 context 한계

   1. 전통적인 하네스에서는 현재 session run의 context window와 session 자체가 사실상 하나로 묶인다.
   2. Claude가 현재 window에서 일부 context를 버리면, 나중에 그 내용을 다시 읽어올 방법이 없을 수 있다.

2. 로그를 외부의 회복 가능한 기억으로 사용

   1. Managed Agents는 모든 것을 durable session log에 기록한다.
   2. 하네스는 필요한 context의 일부만 현재 window로 slice해 읽을 수 있다.
   3. Claude가 실행 내용을 편집하거나 버려도 session log에서 다시 읽어 복구할 수 있다.

3. 개발자의 집중 영역

   1. Anthropic이 agent loop, memory, observability 같은 공통 하네스 부분을 관리한다.
   2. 개발자는 context management와 domain expertise를 사용자에 맞게 설계한다.
   3. 코딩 에이전트는 노트북에서 개발자가 쓰는 Bash·Grep 같은 도구를 사용하지만, 법률 에이전트나 go-to-market 에이전트는 전혀 다른 도구가 필요하다.
   4. 따라서 개발자는 system prompt, skills, tools를 설계하는 데 집중해야 한다.

4. 데모: SRE Investigator를 프로덕션 에이전트로 만들기

데모의 목표는 Atlas라는 서비스 대시보드에서 P99 지연시간이 baseline의 10배로 치솟은 장애를, SRE 에이전트가 로그·메트릭·배포 이력·코드 변경을 조사해 근본 원인으로 좁히는 흐름이다.

4.1. 문제 설정과 에이전트 정의

1. Atlas 장애 시나리오

   1. 엔지니어가 소유한 서비스 대시보드에서 핵심 지표를 확인하던 중 P99 latency가 갑자기 baseline의 10배로 치솟는다.
   2. 로그에는 텍스트가 많이 쌓여 있어, 사람이 대시보드를 열고 무엇이 잘못됐는지 직접 찾아야 한다.
   3. SRE Investigator가 이 지루한 데이터 조사를 대신해 대시보드를 열기도 전에 root cause를 알려주는 것이 목표다.

2. Agent definition

   1. 이름을 SRE Investigator로 정한다.
   2. 데모에서 모델은 Claude Opus 4.8로 설정됐다(자막에는 “Opus 48”로 인식됨).
   3. system prompt에 에이전트의 행동 방식과 조사 지침을 넣는다.
   4. 기본 도구 세트로 Bash, Grep, blob 등을 제공한다.
   5. MCP tool set을 연결해 대시보드에서 deploy와 metrics를 가져오게 한다.

4.2. 환경·증거·세션 설정

1. Environment 정의

   1. SRE sandbox를 만들고 Anthropic Cloud에서 실행하도록 설정한다.
   2. 네트워크를 제한하고, 허용 호스트를 연결하려는 MCP 서버로만 지정한다.
   3. 이 경계 설정은 Claude가 의도하지 않은 일을 하지 못하게 한다.

2. 작업 증거 제공

   1. 앞서 본 application log 파일을 업로드한다.
   2. 파일과 skills를 함께 올려 에이전트가 필요한 자료를 읽도록 구성한다.

3. Session 시작

   1. agent definition은 에이전트가 무엇인지, environment는 어디서 실행되는지, 업로드된 증거는 무엇을 읽을지 정의한다.
   2. session은 이 durable resource들을 하나로 결합하고 session log를 resource로 지정해 실행을 시작한다.
   3. 정의한 자원이 Anthropic Cloud에 존재하므로 애플리케이션 필요에 따라 동적으로 session을 만들 수 있다.

4.3. 장애 조사 실행과 관찰

1. 조사 요청

   1. “장애가 발생했다. checkout 지연이 매우 높다. 조사해 달라”고 SRE Investigator에 요청한다.
   2. Managed Agents가 cloud에서 brain을 즉시 시작하고, hands인 sandbox를 사용해 application log를 grep한다.

2. 근본 원인 도출

   1. MCP 도구로 관련 metrics를 확인한다.
   2. 최근 deploy를 찾아 장애가 시작된 지점을 격리한다.
   3. 추가 조사를 통해 code diff를 찾고, 로그·메트릭·배포·코드 변경을 종합해 최종 root cause를 만든다.

3. 프로덕션 확장과 추적

   1. 몇 줄의 코드로 cloud에서 end-to-end 실행되는 production-grade agent를 만들 수 있다.
   2. 데모는 한 session이지만, 실제 애플리케이션에서는 모든 사용자에 대해 여러 session을 즉시 시작할 수 있다.
   3. Cloud Console의 observability dashboard에서 session을 보고, 정확한 event trace와 session log를 확인할 수 있다.
   4. 로그에는 사용한 도구, 도구 결과, 에이전트 메시지 등 해당 사건의 모든 이벤트가 포함된다.

5. 고객 현장에서 얻은 네 가지 교훈

5.1. 교훈 1 — 자격 증명을 에이전트에서 떼어놓아라

1. 문제

   1. 고객은 보안 토큰이 들어 있는 environment file을 에이전트가 읽거나 볼 수 없게 하는 방법을 가장 중요하게 묻는다.
   2. brain과 hands를 분리하면 agentic loop와 tool execution이 다른 곳에서 실행돼 노출면을 줄일 수 있다.

2. Vaults

   1. 보안 자격 증명을 vault에 안전하게 저장한다.
   2. 도구 실행 runtime에 필요한 순간에만 복호화한다.
   3. 모델은 실제 security token을 보지 않고도 민감한 시스템을 사용할 수 있다.

5.2. 교훈 2 — brain/hands 분리는 지연시간을 낮춘다

1. 기존 결합 구조의 병목

   1. agent harness와 컨테이너가 한 박스에 있을 때는 컨테이너 준비가 끝나야 모델이 추론하고 첫 토큰을 출력할 수 있었다.
   2. 이 구조는 특히 time to first token(TTFT)을 늦췄다.

2. 병렬 실행

   1. 분리 구조에서는 모델 reasoning을 즉시 시작하는 동시에 container setup을 병렬로 진행한다.
   2. 모델이 필요로 하는 시점에 hands가 준비되며, 특정 작업에 컨테이너가 필요 없으면 준비를 완전히 건너뛸 수 있다.

3. 측정 결과

   1. P50 또는 median use case에서 time to first token이 60% 빨라졌다.
   2. P95 use case에서는 time to first token latency가 90% 이상 개선됐다.

5.3. 교훈 3 — session log는 관찰 가능성과 개선의 기반이다

1. 실행의 전 과정 기록

   1. session log 또는 trace에는 user message, model response, tool execution, tool result 등 실행 중 발생한 모든 이벤트가 play-by-play로 기록된다.
   2. 이 로그를 사용자에게 보이는 UI로 노출하면 에이전트가 무엇을 했는지 관찰할 수 있다.

2. 메모리와 self-improvement

   1. 로그는 과거 실행의 history가 되며, 에이전트가 사용자에 관한 사실을 기억하는 memory와 결합된다.
   2. 여기에 dreaming을 더하면 메모리를 시간에 따라 업데이트하고 개선할 수 있다.
   3. 결과적으로 다음 실행의 에이전트가 이전 실행보다 나아진다.

5.4. 교훈 4 — 도구 실행 환경의 보안을 고객 정책에 맞춰라

1. 고객의 실행 경계 요구

   1. 보안에 민감한 엔터프라이즈 팀은 tool execution이 자기들 통제 아래 있어야 한다.
   2. 특히 자체 virtual private cloud(VPC) 안에서 실행 환경을 관리하기를 원한다.

2. Self-hosted sandboxes

   1. brain/hands 분리 덕분에 hands를 Anthropic Cloud가 아닌 고객 VPC 등 원하는 위치에서 실행할 수 있다.
   2. self-hosted sandboxes를 통해 고객은 sandbox control plane과 실행 환경을 자기 정책에 맞춰 직접 통제할 수 있다.

3. MCP tunnels

   1. 고객은 MCP 서버를 public internet에 노출하지 않고 에이전트에 연결할 수 있다.
   2. MCP server는 private network 안에서만 실행하고, Claude agent loop로 outbound call만 허용한다.

6. 모델 진화에 맞춰 확장되는 프론티어 기능

Managed Agents의 현재 기능은 기본 토대이며, 하네스는 모델이 할 수 있는 일의 확장에 맞춰 scheduled deployments, self-hosted sandboxes, multi-agent orchestration, dreaming, outcomes, memory 등으로 계속 진화한다.

6.1. Dreaming: 실행 기록을 이용한 자기 개선

1. 입력과 배치 처리

   1. 에이전트의 매일 실행에서 나온 transcript/session log를 축적한다.
   2. 에이전트의 현재 memory state도 함께 준비한다.
   3. 이를 dreaming이라는 주기적 batch process에 넣는다.

2. 메모리 재구성

   1. 더 강해진 모델은 transcript와 memory에서 새로운 통찰과 정리된 구조를 추출한다.
   2. 필요한 대로 memory를 편집하고 업데이트해 다음 날 session이 더 지능적으로 시작하게 한다.
   3. 실행이 누적될수록 스스로 개선되는 agent를 만들 수 있다.

3. 확장되는 메모리의 범위

   1. 사용자별 memory는 특정 사용 사례에 관한 사실을 기억한다.
   2. dreaming은 에이전트가 스스로 개선하도록 한다.
   3. 이 둘을 넘어 조직 규모의 memory가 등장할 수 있다.
   4. 조직 memory는 팀의 runbook과 업무 세부사항을 저장해 개인을 넘어 팀 전체의 운영 지식을 활용한다.

6.2. Outcomes: 성공 기준을 이해하고 반복하는 에이전트

1. 성공의 명시적 정의

   1. 사용자가 에이전트의 성공 criteria를 정의한다.
   2. 어떤 상태가 task completion인지 rubric으로 정하고, 실패 case도 명시한다.

2. 별도 grader agent

   1. Outcomes는 agent loop와 함께 동작하는 별도의 grader agent를 실행한다.
   2. grader는 정의된 rubric에 따라 실제 에이전트가 과업을 성공했는지 평가한다.
   3. 에이전트는 task를 실행한 뒤 grader의 판정을 확인한다.

3. 실패 시 반복

   1. grader가 성공 기준을 충족하지 못했다고 판단하면 에이전트는 멈추지 않고 다시 시도한다.
   2. 정의된 success criteria에 도달할 때까지 반복하므로, 단순히 한 번의 completion을 반환하는 것보다 결과 신뢰도가 높아진다.
   3. 모델이 더 복잡한 task와 outcome을 달성할수록, 과거에는 불가능했던 업무도 이 방식으로 열릴 수 있다.

7. 결론: 정적인 하네스와 모델 능력 사이의 간극 줄이기

1. 현재의 병목은 하네스다

   1. Claude를 비롯한 모델은 지수적인 궤도로 발전하고 있다.
   2. 반면 제품이 제공하는 표면과 정적 하네스가 그 능력을 따라가지 못하면, 모델이 실제로 할 수 있는 일과 제품이 제공하는 일 사이에 간극이 생긴다.
   3. 발표자들은 모델이 발전할수록 harness가 모델 능력의 limiting factor가 된다고 진단한다.

2. Managed Agents의 역할

   1. brain/hands 분리, durable session, context 재읽기, 안전한 sandbox, credential vault, 관찰 가능성은 장기 실행 에이전트의 공통 기반을 제공한다.
   2. dreaming과 memory는 실행을 통해 지식을 누적하고, outcomes는 rubric과 grader를 통해 결과 품질을 반복적으로 끌어올린다.
   3. 개발자는 모델 런타임 인프라를 직접 붙잡기보다 task·context·도메인 지식·prompt·skills·tools에 집중한다.

3. 실용적 시사점

   1. 모델을 교체할 때 기존 보정 로직이 여전히 필요한지부터 재검증해야 한다.
   2. 장기 실행·비동기·다중 사용자 에이전트라면 실행 환경, 세션 로그, 복구 상태를 애플리케이션 코드와 분리해야 한다.
   3. 보안 설계에서는 모델이 token을 직접 보지 않도록 vault와 tool runtime을 분리하고, 실행 위치와 MCP 연결을 정책으로 제한해야 한다.
   4. 에이전트 품질을 단순 응답 평가가 아니라 명시적 outcome rubric과 grader로 측정하면 복잡한 업무의 신뢰성을 높일 수 있다.
   5. 궁극적으로 좋은 agentic surface는 현재 모델을 감싸는 고정 래퍼가 아니라, 다음 모델의 능력을 빠르게 흡수하는 교체 가능한 운영 시스템이어야 한다.

주요 발언 모음

“As task complexity and model capability has improved, the agentic surfaces has to evolve with them.”
“작업 복잡도와 모델 능력이 개선될수록 agentic surface도 함께 진화해야 한다.”

“When the model moves and the harness doesn't, it degrades the agent.”
“모델은 움직이는데 하네스가 움직이지 않으면 에이전트 성능이 저하된다.”

“You own the product, you own the task, you own your context.”
“제품과 task, context는 개발자가 소유한다.”

“The brain could just spin up a new sandbox and retry and then continue as it left off.”
“두뇌는 새 sandbox를 띄우고 재시도한 뒤 중단한 지점부터 계속할 수 있다.”

“The model never sees your security tokens.”
“모델은 보안 토큰을 절대 보지 않는다.”

“What we see as Claude models and other models essentially evolve alongside this exponential trajectory is that harnesses have become the limiting factor to what models can achieve.”
“모델이 지수적 궤도로 진화할수록 하네스가 모델이 달성할 수 있는 것의 제한 요인이 된다.”

핵심 데이터 & 수치

• 31분 23초: 발표 전체 길이.
• 3년: 발표가 돌아보는 agentic surface의 진화 기간.
• P99 지연시간 10배: 데모에서 Atlas 서비스 장애가 baseline 대비 치솟은 수준.
• 4가지 세션 상태: idle, running, rescheduling, terminated.
• 60% 빠른 TTFT: P50/median use case에서 brain/hands 분리 후 time to first token 개선.
• 90% 이상 개선: P95 use case에서 time to first token latency 개선.
• 수시간~수일: Managed Agents가 신뢰성 있게 지원해야 하는 장기 실행 범위.
• 4가지 현장 교훈: credentials 격리, latency 개선, session logs, tool execution security.

핵심 요약 (20줄)

1. Anthropic Applied AI 팀은 지난 3년간 agentic surface가 모델 능력과 작업 복잡성을 따라 진화했다고 설명한다.
2. 초기 Messages API는 tokens in과 tokens out만 제공하는 단순한 호출 표면이었다.
3. 고객은 장기 작업을 위해 Claude 호출·도구 실행·context 관리를 직접 묶은 agentic loop를 만들었다.
4. 프로덕션에서는 세션 관리, 관찰 가능성, 자격 증명, 호스팅, 샌드박싱이 추가 부담이 됐다.
5. Claude Agent SDK는 내장 agentic loop와 파일 시스템·도구·샌드박싱을 패키징했다.
6. SDK를 사용해도 자격 증명과 호스팅·확장은 고객이 직접 해결해야 했다.
7. Claude Managed Agents는 제품·task·context를 고객이 소유하고 실행 인프라는 Anthropic이 맡는 모델을 제시한다.
8. Managed Agents는 Claude와 agent loop라는 brain과 필요할 때 생성되는 sandbox라는 hands를 분리한다.
9. 분리 구조는 한 컴포넌트의 장애가 전체 에이전트를 중단시키는 문제를 줄인다.
10. Agent, environment, session이라는 세 primitive가 장기 실행과 관찰 가능성의 기반이 된다.
11. durable session log 덕분에 brain이나 sandbox가 죽어도 에이전트가 중단 지점에서 복구할 수 있다.
12. 로그에서 context를 필요한 부분만 다시 읽을 수 있어 context engineering의 유연성이 높아진다.
13. SRE Investigator 데모는 로그·메트릭·배포·코드 diff를 조합해 Atlas 장애의 root cause를 찾는다.
14. 환경의 네트워크와 허용 호스트를 제한하면 에이전트의 행동 경계를 통제할 수 있다.
15. 자격 증명은 vault에 저장하고 도구 실행 시에만 복호화해 모델에 토큰을 노출하지 않는다.
16. brain/hands 병렬화는 P50에서 TTFT를 60%, P95에서 90% 이상 개선했다.
17. session log는 관찰 가능성뿐 아니라 memory와 dreaming을 통한 self-improvement의 재료다.
18. self-hosted sandboxes와 MCP tunnels는 VPC와 private network 안에서 실행·연결을 통제하게 한다.
19. dreaming은 과거 transcript와 memory를 재구성하고 outcomes는 grader와 rubric으로 성공을 검증한다.
20. 발표의 결론은 모델 진화의 병목이 되지 않는 민첩한 하네스가 제품이 모델 능력에 가까워지는 길이라는 것이다.

결론 및 시사점

1. 모델 교체가 잦은 환경에서는 하네스의 모든 보정 로직을 주기적으로 재검증하고, 더 이상 필요 없는 reset·compaction 로직을 제거해야 한다.
2. 장기 실행 에이전트는 brain, execution environment, durable session을 분리해 장애 복구와 수평 확장을 기본 설계로 삼아야 한다.
3. 에이전트 제품의 차별화는 공통 런타임을 재구현하는 데 있지 않고, 적절한 context 관리·도메인 도구·skills·system prompt를 설계하는 데 있다.
4. 보안·성능·품질을 동시에 다루려면 credential vault, 병렬 컨테이너 준비, session trace, outcome grader를 제품 수명주기에 포함해야 한다.
5. 최종적으로 agentic surface는 모델을 호출하는 API가 아니라, 모델의 능력을 실제 사용자 결과로 연결하는 진화 가능한 운영 시스템이다.