에이전트 시대를 여는 Claude Platform의 설계 원칙

URL: https://www.youtube.com/watch?v=TQqa0B_pNGE 날짜: 2026-09-01 채널: Tech Bridge 원문 제목: [한영자막] Anthropic의 Claude Platform 팀이 말하는 에이전트의 시대

---

메타데이터

• 주제: 장기 실행 에이전트(Long-running agent), Managed Agents, Harness, Claude Platform, 기업 도입
• 출연: Angela Jen, Caitlyn Les
• 대화 장소: Anthropic San Francisco office
• 원본 프로그램: Kleiner Perkins의 Builders 시즌 2

---

📌 핵심 질문 / 핵심 논점

==모델이 똑똑해지는 시대의 경쟁력은 모델 자체보다 모델이 안전하게 오래 일하도록 만드는 인프라, 업무 설계, 관찰성, 그리고 에이전트 중심 조직 운영에 있다.==

• 모델은 1년 사이 더 똑똑해졌고 더 오래 작업하며 백그라운드에서 더 많은 일을 처리하게 됐다.
• 장기 실행을 현실화하려면 에러 복구, 보안 경계, 영속 상태, 비용 최적화, 도구 실행 환경이 필요하다.
• 기업은 기존의 인간 업무 흐름에 에이전트를 끼워 넣기보다 가장 작은 단위부터 업무를 agent-first로 다시 설계해야 한다.
• 플랫폼은 반복적인 분산 시스템 문제를 맡고, 고객은 도메인 지식과 고객 경험을 차별화하는 상위 전략에 집중해야 한다.

Claude Platform은 모델·컴퓨트·추론·안전 팀 사이에 위치하면서 외부 고객과 Anthropic의 first-party 제품이 동일한 API를 사용하도록 만든다. 모델에게 단순히 명령을 내리는 단계를 넘어, 결과를 정의하고 에이전트가 스스로 실행·검증·수정하도록 하는 구조가 지식 노동의 기본 단위가 된다.

1. 모델 중심에서 장기 실행 에이전트 중심으로

모델 성능 향상은 사람과 모델이 짧은 대화를 주고받는 방식에서 모델이 백그라운드에서 장시간 업무를 수행하는 방식으로 무게중심을 옮겼다.

1.1. 지난 1년의 가장 큰 변화

1. 모델의 작업 지속 시간과 지능이 함께 늘어남

   1. 모델은 1년 전보다 더 오래 일하고 더 똑똑해졌으며 더 많은 종류의 일을 처리한다.
   2. 과거에는 사람이 loop 안에 들어가 chatbot과 대화하며 매 단계의 작업을 확인했다.
   3. 현재는 모델이 긴 시간 동안 작업을 이어가고 사람이 다른 일을 하는 동안 결과를 완성하는 방향으로 이동했다.

2. 모델 주변의 문제가 핵심 엔지니어링 문제가 됨

   1. 장기 실행은 적절한 infrastructure 없이는 불가능하다.
   2. 모델의 성능을 최대한 끌어내고 비용을 최적화하려면 분산 시스템, 실행 환경, 상태 관리가 필요하다.
   3. 모델이 더 오래 일할수록 안전·보안·규정 준수와 에러 복구가 모델 자체만큼 중요해진다.

3. 명령을 구체화하는 일에서 결과를 위임하는 일로 이동함

   1. 과거에는 모델이 특정 셀만 편집하도록 주변에 많은 scaffolding을 만들어야 했다.
   2. 현재는 “그 일을 해”라고 말하면 모델이 작업의 세부 절차를 구성하고 실행하는 수준에 가까워졌다.
   3. 설계 목표는 모델의 방향을 매 순간 조종하는 것이 아니라 오래 실행하고, 실패를 회복하고, 안전한 방식으로 계속 진행하게 하는 것이다.

1.2. 지식 노동에 적용되는 장기 실행 에이전트

1. 금융 분석을 결과 중심으로 위임함

   1. 과거의 자동화는 특정 Excel spreadsheet의 특정 셀을 계산하는 좁은 작업이었다.
   2. 더 높은 수준의 요청은 “이 회사의 DCF(Discounted Cash Flow)를 만들고 적절한 가격에 투자할지 판단하라”가 된다.
   3. 에이전트는 spreadsheet를 열고 계산한 뒤, 계산이 틀렸음을 스스로 발견하면 “제대로 계산하지 않았으니 다시 하겠다”고 판단하고 재실행한다.
   4. 사용자는 “작업을 다시 확인하라”고 매번 개입하거나 지시할 필요가 없다.

2. 금융·의료·전문 지식 업무의 실행 단위를 바꿈

   1. 금융과 healthcare를 포함한 지식 노동에서 결과를 동료 associate에게 맡기듯 에이전트에게 전달할 수 있다.
   2. 장기 실행 에이전트는 단순 답변이 아니라 조사·도구 사용·검증을 포함한 전체 작업을 맡는다.
   3. 결과적으로 사람은 반복 실행에서 벗어나 더 높은 가치의 판단과 방향 설정에 집중한다.

2. Angela Jen과 Caitlyn Les가 Anthropic으로 이동한 이유

두 사람은 Stripe에서 개발자 플랫폼을 만들던 경험을 Anthropic의 Claude Platform과 연결하고, 강력한 AI를 안전한 결과로 이어가는 일을 선택했다.

2.1. Caitlyn Les의 Stripe 경험과 Anthropic 합류

1. Stripe Connect에서 개발자 플랫폼을 구축함

   1. Caitlyn은 Anthropic에 합류한 지 약 1년이 됐으며, 평범한 tech job이라면 신입에 가까운 기간이라고 농담했다.
   2. Stripe에서 Angela와 함께 Stripe Connect를 담당했다.
   3. 고객은 primitive building block을 원할 수도 있고, 사업 규모와 결제·금융 서비스의 비중에 따라 out-of-the-box solution을 원할 수도 있었다.
   4. 개발자 플랫폼은 고객이 자기 제품과 시스템 안에 기반 기술의 가치를 직접 심도록 돕는 역할을 했다.

2. 플랫폼 사고방식을 AI로 확장함

   1. Anthropic에서도 낮은 수준의 building block과 완성된 agent를 모두 제공한다.
   2. 고객이 직접 차별화된 제품을 만들 수 있게 하는 개발자 플랫폼이라는 관점은 Stripe에서 Claude Platform으로 이어졌다.
   3. 주변 산업이 급격히 바뀌는 상황에서 그 변화의 중심에 참여하고, 과거에 함께 일한 사람들이 모인 환경에서 일하고 싶다는 판단이 합류를 이끌었다.

3. 안전 AGI를 만드는 인재 밀도에 매력을 느낌

   1. Anthropic은 기술이 매우 강력해질수록 세계에 좋은 결과를 만들어야 한다는 생각에 전념한다.
   2. 안전, 상업적 사업, intelligence가 교차하는 어려운 문제를 빠르게 사고하면서도 깊이 있게 다루는 사람들이 모여 있다.
   3. 지적으로 열린 태도와 가치에 충실한 태도를 동시에 가진 사람들이 함께 일하는 점이 쉽게 포기하기 어려운 매력이 됐다.

2.2. Angela Jen의 OpenAI 전환과 70%의 계기

1. Stripe를 떠난 뒤 OpenAI에서 API 제품을 경험함

   1. Angela와 Caitlyn은 같은 시기에 Stripe를 떠났고, 서로 다른 lab으로 이동해 이전 팀을 당황하게 만들었다.
   2. Caitlyn은 Anthropic으로, Angela는 ChatGPT가 이미 존재하던 시기에 OpenAI로 갔다.
   3. Angela는 처음부터 AI 제품에 적극적으로 참여하려던 것은 아니었지만, Stripe의 V2 Accounts API 프로젝트가 생각을 바꾸는 계기가 됐다.

2. Cursor가 API 통합의 70%를 자동화함

   1. Stripe는 처음부터 API를 versioning했고, 한 번 만든 abstraction이 수십 년 지속돼야 한다는 장기 관점을 가졌다.
   2. V2 Accounts API는 다음 수십 년의 가치가 있어야 version bump를 정당화할 수 있을 만큼 공들여 만든 프로젝트였다.
   3. 고객 user-experience research(UXR)에서 고객은 제공된 문서를 그대로 Cursor에 넣고 “통합해”라고 요청했다.
   4. 당시 모델은 통합 작업을 약 70% 정확하게 수행했고, Angela는 지식 노동을 해방하는 미래가 이미 도착했다고 느꼈다.
   5. Angela는 API 제품을 담당하는 비슷한 역할로 OpenAI에 합류했고, 그 경험을 바탕으로 Anthropic의 Platform 업무와 연결했다.

3. 서로를 설득하다가 Anthropic에서 다시 만남

   1. 두 사람은 각자 상대에게 자기 lab으로 오라고 계속 권했다.
   2. Caitlyn은 edge partner가 필요했고 Angela는 product partner가 필요하다고 주장했다.
   3. Angela는 결국 Caitlyn이 이겼다고 말했고, Caitlyn은 Angela가 자신의 버전으로 이야기를 전한다고 놀렸다.
   4. Anthropic이 안전한 AGI를 만들고 기술을 모두에게 안전하게 배포하려는 사명을 가진 점이 두 사람의 선택을 확정했다.

3. Managed Agents의 제품 철학과 시스템 구조

Claude Managed Agents는 기업이 낮은 수준의 harness engineering을 반복하지 않고 장기 실행 에이전트를 시작하도록 돕는 higher-order abstraction이다.

3.1. 차별화된 문제와 차별화되지 않은 문제를 분리함

1. 고객은 차별화되는 일에 집중해야 함

   1. 플랫폼 위의 builder는 고객을 깊이 이해하고 도메인 문제를 해결하는 일에 시간을 써야 한다.
   2. 분산 시스템과 장기 실행 infrastructure처럼 반복되는 문제는 고객이 매번 직접 풀지 않아도 된다.
   3. DCF를 수행하는 장기 실행 에이전트를 안정적으로 운영하는 일은 순수한 prompt·harness 최적화가 아니라 대규모 infrastructure 문제다.

2. 하나의 정답 harness를 가정하지 않음

   1. 모든 문제에 통하는 “one true harness”가 있다는 관점은 실제 현상과 맞지 않는다.
   2. 문제 공간과 고객에 따라 여러 최적화 계층과 조합 방식이 필요하다.
   3. Claude Platform은 고객이 system prompt, skills, MCP 연결과 상위 전략을 조정할 수 있도록 더 많은 control을 제공한다.
   4. 인프라의 어려운 부분을 대신 풀어주는 것과 고객의 최종 agent experience를 설계할 자유를 함께 제공한다.

3.2. Ephemeral sandbox와 durable agent를 분리함

1. Sandbox만으로 장기 실행을 구현하면 한계가 생김

   1. 에이전트가 rogue하게 시스템을 건드리지 않도록 container를 sandbox로 사용한다.
   2. Sandbox 기술은 보통 ephemeral하도록 설계돼 있어 장기 실행 infrastructure로는 적합하지 않다.
   3. Sandbox가 종료되거나 연결을 잃을 때 전체 agent가 함께 사라지면 장기 작업의 신뢰성이 떨어진다.

2. Harness와 실행 환경을 modular architecture로 분리함

   1. 에이전트의 brain 또는 harness는 durable server에서 계속 실행한다.
   2. 실제로 위험한 tool execution이 필요할 때만 sandbox를 spawn한다.
   3. 작업이 끝나면 sandbox를 teardown하며, sandbox 하나가 죽어도 전체 agent의 conversation과 상태는 살아남는다.
   4. Anthropic 내부 제품에서 여러 agent를 만들며 얻은 설계 판단을 외부 Platform primitive로 옮겼다.

3.3. 신뢰를 만드는 두 계층

1. 보안 경계를 사용자가 결정함

   1. 에이전트가 production system과 민감한 내부 data를 만질 때 기업의 security bounds 안에서만 작동해야 한다.
   2. Bring-your-own-sandbox 같은 방식을 통해 기업이 실행 환경과 권한을 직접 통제할 수 있다.
   3. 보안과 compliance는 에이전트에게 자율성을 주기 전에 먼저 해결해야 할 조건이다.

2. 관찰성과 감사 가능성을 확보함

   1. 에이전트가 일을 할 수 있게 된 뒤에는 “정확히 했는가”를 확인하는 문제가 새롭게 생긴다.
   2. 기업은 에이전트의 실행 과정을 inspect하고, 의도한 방식으로 실제 작업이 일어났는지 audit할 수 있어야 한다.
   3. Platform은 observability와 tooling을 제공하지만, 기업 시스템과의 세부 integration은 고객이 추가로 구축해야 한다.
   4. 보안 경계와 observability가 함께 갖춰져야 직원이나 최종 사용자에게 실질적인 autonomy를 부여할 수 있다.

3.4. 어디까지 직접 제공하고 어디까지 개방할지

1. 모델 제공과 safety classifier는 핵심으로 유지함

   1. Anthropic은 모델을 실행하고 serve하는 역할을 계속 맡는다.
   2. 실행되는 safety classifier와 모델 접근 계층은 회사가 중요하게 생각하는 핵심 영역이다.
   3. Messages API는 모델에서 token에 접근하는 가장 primitive한 API이며, 그 아래의 모델·안전 계층은 Anthropic의 중심 영역이다.

2. 상위 인프라는 점점 self-hostable하게 만듦

   1. Messages API 위 계층에서는 architecture에 대한 의견과 infrastructure에 대한 고정된 의견을 구분한다.
   2. Sandbox를 자체 호스팅하는 선택지를 제공하고, 방화벽 뒤에 MCP server를 두면서도 agent가 연결할 수 있는 MCP tunnel infrastructure를 제공한다.
   3. 강력한 architecture 규칙을 지키는 한 실제 infrastructure를 어디에서 어떻게 운영할지는 고객이 선택할 수 있게 하는 방향으로 나아간다.

4. 기업 도입, Harness, 토큰 경제

4.1. 기업이 시작하는 가장 현실적인 경로

1. 처음에는 Managed Agents를 사용함

   1. Fortune 500 기업의 CTO·CEO·VP Engineering처럼 장기 실행 에이전트를 production에 도입하려는 리더도 처음부터 prompt caching과 context engineering의 모든 세부사항을 직접 해결할 필요는 없다.
   2. Cloud Managed Agents는 장기 실행과 모델 유지에 필요한 작업을 일반적으로 잘 처리하는 harness다.
   3. Anthropic 내부의 깊은 prompt caching·context management 전문가도 새 agent가 필요할 때마다 낮은 수준을 다시 구현하기보다 Managed Agents를 사용한다.

2. 필요할 때만 낮은 계층으로 내려감

   1. Managed Agents는 system prompt를 조정하고 skills를 설정하며 외부 시스템과 MCP connection을 붙일 수 있다.
   2. 조직이 특정 prompt caching 방식과 extreme control에 대해 확실한 의견을 갖게 되면 lower-level primitive로 내려갈 수 있다.
   3. 초기 목표는 기술 복잡성을 감당하는 것이 아니라 어떤 결과가 조직에 유용한지 빠르게 실험하고 확인하는 것이다.

4.2. Harness의 최소 정의와 확장 계층

1. Harness는 모델을 붙잡는 실행 loop임

   1. 가장 기본적인 harness는 user input을 받고, model의 판단을 묻고, tool을 호출하고, 결과를 다시 model에 전달하는 while loop다.
   2. Harness는 conversation의 각 부분을 관리하면서 모델이 계속 실행되도록 유지한다.
   3. 장기 실행으로 확장하려면 안전한 tool execution environment, 중단 후 재개할 수 있는 conversation state 저장소가 필요하다.
   4. MCP 등 외부 시스템에 접근할 때는 secure credential을 주입하되 agent가 실제 credential 값을 볼 수 없게 해야 한다.

2. Core harness 위에 Strategy 계층을 쌓음

   1. 여러 agent를 조정하고 서로의 loop에 결과를 feed back하며 각자 다른 job을 주는 상위 계층을 meta-harness 또는 strategy라고 부를 수 있다.
   2. 에러 처리, 반복 loop, 장기 실행 같은 기본기는 어느 정도 표준화되고 있다.
   3. 실제 성능 차이는 도메인에 맞게 여러 agent의 역할과 실행 전략을 compose하는 상위 계층에서 커진다.

4.3. 모든 토큰이 같은 가치를 갖지 않음

1. 비용은 token 단가보다 사업 결과로 평가함

   1. 기업이 토큰 비용을 줄이고 싶다고 말할 때 실제 목표는 제품을 더 빨리 출시하거나 팀을 더 효율적으로 만드는 경우가 많다.
   2. 가장 싼 모델을 고르는 것보다 목표 결과에 도달하는 가장 효율적인 경로를 찾는 것이 중요하다.
   3. 더 큰 모델이 모든 token을 정확하게 생성해 재시도와 낭비를 없앤다면 token 단가는 비싸도 전체 비용은 더 낮아질 수 있다.
   4. 작은 지능으로 충분한 작업을 감지하고 필요한 순간에만 더 높은 지능을 쓰는 자동화가 장기 목표다.

2. 토큰에 서로 다른 job을 부여함

   1. Advising: 작은 모델이 실행하다가 어려운 문제를 만나면 큰 모델에 조언을 구한다.
   2. Sonnet이 실행하고 Opus가 조언하는 조합은 평가에서 거의 Opus 수준의 성능을 내면서, Opus 단독 실행보다 적은 token으로 끝날 수 있다.
   3. Opus의 조언이 Sonnet의 실행 방식을 개선해 전체 작업 token을 줄이기 때문이다.
   4. Outcomes: 첫 번째 agent가 실행하고 두 번째 grader agent가 “좋은 결과의 rubric”으로 평가한다.
   5. Grader가 충분하지 않다고 판단하면 첫 agent가 다시 시도해 executor와 evaluator가 함께 더 나은 결과를 만든다.
   6. Dreaming: 과거 session을 되돌아보고 memory와 skills를 써서 이후 실행을 개선한다.
   7. 장기적으로는 고객이 이런 token 배분 전략을 직접 고안하지 않아도 platform이 자동으로 선택하는 방향을 지향한다.

5. 에이전트 도입 실패를 줄이는 업무 재설계

5.1. 너무 큰 자동화부터 시작하지 않음

1. 거대한 인간 프로세스를 한 번에 자동화하려는 실수를 피함

   1. 대형 은행의 전체 KYC(Know Your Customer) 프로세스를 처음부터 agent 하나로 자동화하려는 접근은 과도한 범위를 잡는다.
   2. 기존 프로세스는 사람의 판단, 정책, 예외 처리가 duct tape처럼 이어져도 일단 작동한다.
   3. 인간의 비효율이 보이는 지점마다 agent를 그대로 삽입하면 agent가 원래 인간이 하던 절차를 억지로 재현해야 한다.

2. 작은 단위부터 agent-first로 다시 설계함

   1. 야심찬 프로젝트를 가장 작은 핵심 단위로 공격적으로 쪼갠다.
   2. 새로 채용한 사람이 맡을 법한 기본 업무 수준까지 분해한 뒤, 그 프로세스를 처음부터 agent-first로 다시 만든다.
   3. 에이전트가 일한 뒤 사람에게 결과를 돌려주는 기존 흐름보다, 에이전트가 자율적으로 탐색·재검토하고 꼭 필요한 순간에만 사람에게 escalate하는 흐름이 더 나을 수 있다.
   4. 기존 인간 workflow를 보존하기보다 불필요한 단계를 지우고 scratch부터 재설계할수록 성공 가능성이 높아진다.

6. 인간과 AI의 UX, 미래 form factor

6.1. Chat box에서 동료 같은 에이전트로

1. 상호작용 form factor는 빠르게 바뀜

   1. 2년 전에는 모든 제품에 chat box를 붙이는 흐름이 강했다.
   2. 사용자는 점점 chat box에 질문을 반복하기보다 agent에게 직접 목적을 전달하고 agent가 전체 작업을 수행하기를 원한다.
   3. 가장 자연스러운 방향은 훌륭한 동료처럼 맥락 전체를 이해하고, 필요한 곳에서는 push back하며, 불평 없이 일을 끝내는 agent다.

2. 익숙한 UI와 보이지 않는 장기 실행을 결합함

   1. Claude를 Slack에서 호출하는 방식은 사람이 서로 협업하는 익숙한 form factor를 활용한다.
   2. Slack이라는 UI는 익숙하게 유지하면서, 그 아래에서는 Claude가 정보를 수집하고 판단하고 실행하는 “horsework”를 수행한다.
   3. 사람은 잠든 동안 agent를 보내고 아침에 결과를 받는 경험을 점점 더 많이 하게 된다.
   4. 사용자가 원하는 결과를 정확하게 표현하고, 백그라운드 agent의 방향을 수정할 수 있는 제어 방식은 아직 계속 찾아가는 중이다.

6.2. Product와 현장 엔지니어의 경계

1. 궁극적으로는 모델 자체가 문제를 풀어야 함

   1. 가장 순수한 형태에서는 사용자가 Claude와 대화하는 것만으로 문제를 해결한다.
   2. Claude가 사용자의 의도를 더 잘 표현하도록 돕고, 필요한 scaffolding을 만들며, 때로는 product를 직접 만든 뒤 목적에 맞는 process를 다시 구성할 수 있다.
   3. 현재는 그 수준에 도달하지 않았으므로 조직의 도입 lifecycle에 따라 제품, Managed Agents, 현장 지원을 조합해야 한다.

2. Product는 가능성을 열고, FTE·엔지니어는 특수 문제를 품음

   1. 처음 도입하는 조직은 product로 직원에게 “허가를 기다리지 않고 직접 만들 수 있다”는 감각을 보여주는 것이 효과적이다.
   2. Anthropic의 신입 직원은 Claude 제품으로 작은 dashboard를 직접 배포하며, 과거라면 여러 팀에 요청했을 일을 스스로 처리할 수 있음을 경험한다.
   3. 수십 년 누적된 대규모 code migration처럼 맞춤형 제품이 없는 foundational business problem은 deployed engineer나 내부 엔지니어가 agent와 함께 custom process를 설계하는 편이 적합하다.
   4. 12년이 걸릴 것으로 예상한 migration을 약 3개월로 단축하면 단순한 효율 개선을 넘어 조직이 불가능하다고 생각한 일을 다시 상상하게 된다.

7. 약 200명 팀이 거대한 규모를 운영하는 방식

7.1. 사람의 ownership은 유지하고 leverage를 키움

1. 작은 팀과 큰 사업 사이의 레버리지

   1. Claude Platform 팀은 약 200명 규모인데 수백만 명의 고객과 수십억 달러의 매출을 감당하는 방향으로 나아가고 있다.
   2. 각 구성원은 시스템의 특정 부분을 이해하고 product ownership을 갖는 전통적인 팀 구조를 유지한다.
   3. 차이는 구성원이 직접 만들거나 즉석에서 만든 도구와 agent로 훨씬 많은 일을 위임하고 처리한다는 점이다.

2. 조율 역할이 새 병목이 됨

   1. Platform은 여러 cloud에 배포되고, safety·infrastructure 등 여러 내부 팀과 협력한다.
   2. 과거에는 엔지니어가 오랫동안 구현하는 동안 PM, tech lead, TPM이 정렬과 coordination을 수행할 시간이 있었다.
   3. 현재는 프로젝트를 시작한 지 이틀 만에 엔지니어가 구현을 끝낼 수 있어, 조율 담당자가 모든 사람을 같은 페이지에 올려놓기 전에 구현이 완료된다.
   4. 빠른 실행으로 생긴 병목이 덜 병목처럼 작동하도록 역할과 프로세스를 다시 설계해야 한다.

7.2. Product Manager의 순수한 역할

1. 조율·프로젝트 관리보다 문제 정의가 중요해짐

   1. 전통적인 PM 업무인 일정 조율, 프로젝트 관리, 엔지니어링 sprint 배정, 조직 정렬의 비중이 줄어든다.
   2. “2주 sprint에서 무엇을 만들지”는 Claude와 대화하는 즉시 실행될 수 있다.
   3. PM은 “무엇을 풀어야 하는가”와 “누구를 위해 풀어야 하는가”라는 가장 어려운 product 문제에 집중해야 한다.

2. 가설·thesis·bet의 품질이 승패를 좌우함

   1. 모델과 agent가 구현을 빠르게 해주므로 prioritization에 과도한 시간을 쓰는 방식은 덜 중요해진다.
   2. 불확실성이 높고 결과 분산이 큰 환경에서는 하나의 bet에 몰아넣기보다 빠르게 portfolio를 구성해야 한다.
   3. 여러 가설 가운데 하나라도 맞으면 전체가 이기는 구조는 product를 투자(investing)처럼 운영하는 방식에 가깝다.
   4. PM은 가장 순수한 형태의 문제 해결자이자, 어떤 hypothesis와 thesis에 자원을 걸지 결정하는 사람으로 변한다.

7.3. “Punch in the face”에 대비하는 문화

1. 실패 허용도는 역할마다 다름

   1. 빠르게 바뀌는 product bets는 한 달 뒤 방향을 바꿔도 괜찮을 정도로 높은 failure tolerance를 요구한다.
   2. engineering 측면에서는 안전성, infrastructure, scale 문제를 실제 서비스 수준으로 해결해야 하므로 실패 허용도가 상대적으로 낮다.
   3. Caitlyn의 팀은 “모두가 계획을 갖고 있지만 얼굴을 한 대 맞기 전까지일 뿐”이라는 표현을 사용한다.

2. 계획은 극단적 현실 변화에 맞춰 계속 수정함

   1. 6개월 전만 해도 지금처럼 극단적인 scale 상황에 도달할 것이라고 생각한 사람은 거의 없었다.
   2. 1월에 세운 계획과 bet은 실제 수요와 scale이 급증하면서 pivot이 필요해졌다.
   3. 안전·인프라·scale 문제를 해결할 준비를 하고, 예상 밖의 충격이 와도 팀을 다시 묶어 실행하는 능력이 필수다.

3. 대중화 속도가 조직 계획을 앞지름

   1. Caitlyn은 Christmas에 New York 가족에게 Claude가 무엇인지 설명했지만 가족은 이해하지 못했다.
   2. 다음 봄 Easter에 만난 사촌은 Mac Mini에서 자신의 OpenClaw setup을 직접 보여줬고, 가족은 “Claude에서 일한다니 멋지다”고 반응했다.
   3. 그 짧은 기간에 전 세계 Claude로 들어오고 나가는 모든 token이 Platform 팀이 만든 시스템을 통과하는 규모가 됐다.
   4. 제품의 대중화 속도가 계획을 바꾸는 현실적인 압력으로 작용한다.

8. 실제 사용, Dogfooding, Platform의 중앙 위치

8.1. 에이전트로 에이전트를 시험함

1. Angela의 고객 경험 검증 workflow

   1. 개발자 제품 팀은 자기 API를 직접 통합할 코드를 작성해야 했기 때문에 제품을 dogfood할 시간이 부족했다.
   2. Angela는 고객이 여러 서비스를 연결해 만든 결과를 확인하고 싶을 때, 예전에는 각 서비스에 계정을 만들고 browser로 직접 탐색했다.
   3. 이제 Claude Managed Agents에 여러 product를 사용해보고 screenshot을 가져와 고객이 실제로 어떻게 쓰는지 알려달라고 요청할 수 있다.
   4. agent를 사용해 agent를 테스트하는 구조는 meta한 방식이지만 제품 진화를 훨씬 빠르게 만든다.

2. Caitlyn의 remote agent와 memory workflow

   1. Caitlyn은 거의 모든 일을 remote agent에게 맡기는 방식에 집중한다.
   2. 어떤 agent가 일을 할 때든 “기억하고 memory에 저장해”라고 말해 이후에도 선호와 규칙을 유지하게 한다.
   3. 결과가 마음에 들지 않으면 “그건 틀렸고 다시 하지 말라고 기억해”라고 피드백을 준 뒤 memory에 저장되는 것을 확인한다.
   4. 클릭하거나 별도 UI를 조작하지 않고 대화로 규칙을 누적하기 때문에 작업 방식이 단순해지고 생산성이 크게 올라간다.

8.2. Platform은 조직의 가운데에 위치함

1. 외부 고객과 first-party 제품이 같은 기반을 사용함

   1. 외부 고객이 build하는 동일한 API와 Platform 위에서 Anthropic의 first-party 제품도 동작한다.
   2. First-party 제품은 Platform 팀의 내부 고객이므로, 외부 고객이 겪는 문제를 제품 팀이 직접 경험한다.
   3. Platform은 accelerator, inference, research, model 등 아래 계층과 애플리케이션 팀 위에 놓인다.

2. 관계와 Tiger Team으로 부서 경계를 넘음

   1. Anthropic은 아직 여러 팀과 긴밀히 협력할 수 있을 만큼 작고, 필요한 일을 즉시 모을 수 있을 만큼 scrappy하다.
   2. 새 model class가 출시될 때처럼 end-to-end 품질이 필요한 문제에는 여러 기능 조직의 사람을 Tiger Team으로 묶는다.
   3. 비법은 거대한 조직 구조가 아니라 강한 관계, 올바른 협업 방식, 특정 문제에 모두를 투입하는 실행력이다.

주요 발언 모음

“모델은 더 오래 일하고 더 똑똑해졌으며 더 많은 일을 할 수 있게 됐다.”

“그 일을 하라고 말하면 그냥 해낸다. 이제 필요한 것은 모델을 한 방향으로 몰아붙이는 일이 아니라 더 오래 실행하고 에러에서 회복하게 하는 일이다.”

“고객이 차별화되는 일을 하게 하고, 차별화되지 않는 일은 대신 해결해야 한다.”

“Sandbox가 죽어도 전체 agent가 죽지 않도록 brain은 durable server에서 실행하고, 실행이 필요할 때만 sandbox를 만든다.”

“우리는 고객의 data로 학습하지 않는다.”

“모든 token이 같은 것은 아니다. 목표 결과에 가장 효율적인 경로를 선택해야 한다.”

“Harness의 가장 기본적인 버전은 user에게 입력을 받고 model에 묻고 tool을 호출하는 while loop다.”

“처음부터 거대한 KYC 프로세스를 자동화하려 하지 말고, 새로 들어온 사람이 맡을 수준까지 쪼갠 뒤 agent-first로 다시 설계해야 한다.”

“가장 좋은 동료처럼 필요한 곳에서 push back하고, 불평 없이 맥락 전체를 이해하며 일을 끝내는 agent가 필요하다.”

“모두가 계획을 갖고 있지만 얼굴을 한 대 맞기 전까지일 뿐이다.”

“Agent로 agent를 테스트하는 것은 조금 meta하지만, 지금은 정말 멋진 시대다.”

핵심 데이터 & 수치

• 약 1년: 모델이 짧은 human-in-the-loop chatbot에서 장기 실행·백그라운드 작업으로 이동했다고 체감한 기간이다.
• 약 70%: Angela가 Stripe V2 Accounts API 문서를 Cursor에 넣었을 때 고객 통합이 당시 수행한 정확도다.
• 약 200명: Claude Platform과 관련 infrastructure를 운영하는 팀 규모다.
• 수백만 명·수십억 달러: 약 200명 팀이 곧 지원하게 될 고객 수와 매출 규모로 언급됐다.
• 12년 → 약 3개월: agent와 custom process를 활용해 장기 code migration을 단축할 수 있는 예시다.
• 약 6개월: 현재의 극단적인 scale이 예상보다 빠르게 찾아와 기존 계획을 수정하게 만든 시간 감각이다.
• 거의 Opus 수준: Sonnet executor와 Opus adviser 조합이 평가에서 도달한 성능 수준이다.
• 이틀: agent 도구가 프로젝트 구현을 끝낼 수 있어 조율 담당자가 정렬할 시간보다 실행이 앞서는 예시다.
• 두 계층의 trust: security boundary와 observability·audit가 장기 실행 에이전트의 핵심 신뢰 조건이다.
• 세 가지 token 역할: 실행(execution), 조언(advising), 결과 평가(grading), 과거 회고와 개선(dreaming)으로 확장되는 사용 방식이 제시됐다.

결론 및 시사점

1. 모델 성능만으로는 에이전트 제품이 완성되지 않는다. 장기 실행, 영속 상태, 안전한 sandbox, 오류 복구, 관찰성과 규정 준수를 함께 설계해야 한다.
2. 기업은 Managed Agents로 빠르게 결과를 검증해야 한다. 도메인 가치가 확인된 뒤에만 prompt caching과 낮은 수준의 harness를 세밀하게 최적화하는 편이 효율적이다.
3. 비용 최적화의 기준을 token 가격에서 업무 결과로 바꿔야 한다. 더 비싼 모델이 재시도와 실패를 줄이면 총소유비용은 오히려 낮아질 수 있다.
4. 토큰은 실행 외에도 조언·평가·기억 개선 같은 역할을 맡을 수 있다. 이 역할 분담이 적은 비용으로 높은 지능을 사용하는 핵심 패턴이 된다.
5. 기존 인간 workflow를 그대로 자동화하지 말아야 한다. 가장 작은 업무 단위부터 agent-first로 새로 설계하고 사람에게 escalate할 조건을 정의해야 한다.
6. 제품 조직은 구현 속도보다 문제 정의와 bet의 품질에 집중해야 한다. 불확실성이 높을수록 하나의 계획보다 여러 가설의 portfolio가 유리하다.
7. Platform 조직은 아래의 모델·컴퓨트 계층과 위의 제품·고객 계층을 연결해야 한다. 동일한 API를 내부 first-party 제품과 외부 고객에게 제공하면 학습 속도가 빨라진다.
8. 에이전트 시대의 조직은 빠른 실행과 빠른 회복을 동시에 가져야 한다. 안전·인프라·scale의 충격을 예상하고 Tiger Team과 강한 협업 관계로 대응해야 한다.

핵심 요약 (20줄)

모델의 장기 실행 능력 향상이 chatbot 중심의 AI를 백그라운드 에이전트 중심으로 바꾸고 있다. 에이전트의 실용성은 모델 지능뿐 아니라 오류 복구·보안·상태 저장·도구 실행 인프라에 달려 있다. 금융 분석가는 Excel 셀 계산 대신 DCF 작성과 투자 판단이라는 결과를 에이전트에게 위임할 수 있다. 장기 실행 에이전트는 계산 결과를 스스로 검증하고 틀리면 재시도해 사람의 개입을 줄인다. Caitlyn Les는 Stripe Connect의 개발자 플랫폼 경험을 Claude Platform의 building block 철학으로 확장했다. Angela Jen은 Cursor가 Stripe API 통합을 약 70% 정확도로 수행한 경험에서 AI 혁명의 현전성을 깨달았다. Anthropic은 강력한 AI를 안전한 결과로 연결하려는 사명과 높은 인재 밀도로 사람을 끌어들인다. Claude Managed Agents는 반복적인 분산 시스템 문제를 대신 풀어 기업의 차별화된 업무에 집중하게 한다. Durable한 agent brain과 필요할 때만 생성하는 ephemeral sandbox의 분리는 장기 실행 신뢰성을 높인다. 기업은 자체 sandbox와 observability 도구를 통해 에이전트의 보안 경계와 실행 과정을 통제해야 한다. Anthropic은 모델과 safety classifier를 핵심으로 유지하면서 상위 인프라의 self-hosting 선택지를 넓힌다. Harness의 기본 형태는 사용자 입력·모델 판단·도구 호출을 반복하는 while loop다. 효율적인 에이전트 시스템은 작은 모델의 실행과 큰 모델의 조언을 조합해 성능과 비용을 함께 개선한다. Grader agent와 memory·skills를 활용한 dreaming은 토큰에 실행 외의 역할을 부여한다. 기업은 거대한 KYC 프로세스를 그대로 자동화하지 말고 가장 작은 업무부터 agent-first로 재설계해야 한다. 미래의 agent는 최고의 동료처럼 전체 맥락을 이해하고 필요한 순간에 push back하며 일을 끝낸다. 제품은 직원에게 직접 만들 수 있다는 agency를 주고 특수한 장기 문제는 현장 엔지니어가 맞춤 설계한다. Claude Platform 팀은 약 200명으로 수백만 고객과 수십억 달러 규모를 운영하는 레버리지를 만든다. AI가 구현을 이틀 만에 끝내면서 PM의 핵심 가치는 조율보다 문제 정의·가설·bet의 품질로 이동한다. 빠르게 변하는 AI 시대에는 안전한 infrastructure와 강한 관계로 예상 밖의 scale 충격을 회복하는 조직이 승리한다.