[한영자막] Anthropic의 Claude Platform 팀이 말하는 에이전트의 시대

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Anthropic의 Claude Platform 팀이 말하는 에이전트의 시대는 더 똑똑한 모델만의 시대가 아니라, 장기 실행 인프라와 기업의 전략적 통제권을 결합해 결과 중심으로 일을 위임하는 시대다.

📌 핵심 요점

1. AI 활용의 중심이 매 단계에서 사람의 지시를 기다리는 챗봇에서, 목표를 받아 백그라운드에서 장시간 일하는 에이전트로 이동하고 있다. 금융 업무도 엑셀 셀 수정 같은 세부 지시에서 DCF 계산과 적정 투자 가격 판단 같은 결과 중심 요청으로 확장된다.
2. 장기 실행은 모델 지능만으로 달성되지 않는다. 오류 복구, 대화 상태 보존, 자격 증명 주입, 보안 격리, 규정 준수, 관찰 가능성을 담당하는 하니스와 실행 인프라가 함께 필요하다.
3. Anthropic이 제시하는 구조는 지속 가능한 서버에 에이전트의 두뇌와 상태를 유지하고, 위험한 실행만 일시적인 샌드박스에서 처리하는 방식이다. 기업은 Claude Managed Agents로 빠르게 시작한 뒤 필요에 따라 프롬프트 캐싱, MCP 연결, 자체 샌드박스 같은 하위 계층을 조정할 수 있다.
4. 비용 최적화의 기준은 토큰 단가가 아니라 사업 성과를 달성하는 총비용이다. 작은 모델의 실행, 큰 모델의 조언, 별도 에이전트의 평가와 재시도, 메모리·스킬 갱신을 분리하면 불필요한 반복을 줄이면서 달러당 지능을 높일 수 있다.
5. 에이전트 도입은 기존 업무에 채팅창을 붙이는 작업이 아니다. 업무를 신입 직원이 맡을 수 있는 기본 단위로 분해하고, 자율 실행과 예외 상황의 선택적 에스컬레이션을 중심으로 프로세스를 다시 설계해야 한다. 구현 속도가 빨라질수록 문제 선택, 조직 조율, 포트폴리오 구성의 중요성은 오히려 커진다.

🧩 배경과 문제 정의

• AI 모델이 짧은 질의응답 도구에서 장시간 자율적으로 일하는 에이전트로 발전하면서, 사람의 지속적인 개입 없이 결과 단위로 업무를 맡길 수 있게 됐다.
• 모델의 지능만으로는 장기 작업을 안정적으로 수행하기 어렵고, 오류 복구·상태 보존·보안 격리·관찰 가능성을 지원하는 인프라가 필요하다.
• 에이전트 플랫폼은 공통 인프라를 대신 처리하되, 기업이 고객 이해와 도메인 지식을 바탕으로 차별화된 전략을 설계할 수 있는 통제권을 남겨야 한다.

🕒 시간순 섹션별 상세정리

1. 장기 실행 능력이 바꾼 AI 활용 방식

• 모델이 더 똑똑해지고 오랫동안 작업할 수 있게 되면서, 사람이 매 단계에 개입하던 챗봇형 활용에서 백그라운드 자율 실행으로 중심이 이동했다. [01:26]
• 장기 실행에는 비용 최적화와 실행 인프라가 필요하며, 에이전트가 오류에서 복구하고 보안·규정 준수 범위 안에서 계속 일할 수 있어야 한다. [02:35]

2. 세부 작업에서 결과 중심 위임으로의 전환

• 금융 업무는 특정 엑셀 셀을 수정하라는 지시에서 기업의 DCF를 계산하고 적정 투자 가격을 판단하라는 결과 중심 요청으로 확장됐다. [03:21]
• 장기 실행 에이전트는 스프레드시트를 열어 계산한 뒤 오류를 스스로 발견하고 재시도하므로, 사용자가 검산 절차까지 일일이 지시할 필요가 줄어든다. [03:54]

3. 개발자 플랫폼 경험과 Anthropic 합류 배경

• Stripe Connect에서 원시적인 구성 요소부터 즉시 사용할 수 있는 솔루션까지 제공하며, 기업의 단계와 제품 구조에 맞춘 개발자 플랫폼을 다뤘다. [04:53]
• Anthropic에서도 기본 구성 요소와 완성형 에이전트를 함께 제공해, 고객이 기반 기술을 자신의 제품과 시스템에 통합할 수 있는 플랫폼을 지향한다. [05:45]

4. API 통합 경험이 보여준 지식 노동의 변화

• 수십 년간 유지할 추상화를 목표로 Stripe V2 Accounts API를 어렵게 설계했지만, 고객은 문서를 Cursor에 넣는 방식으로 통합을 시도했다. [08:41]
• 당시 모델이 API 통합을 약 70% 정확도로 완성하면서, 오랜 전문 작업의 상당 부분을 모델이 수행할 수 있다는 가능성이 현실적인 변화로 다가왔다. [08:57]

5. 공통 인프라와 제품 차별화의 분리

• Managed Agents의 기본 원칙은 플랫폼이 공통 문제를 처리하고, 개발자는 고객과 사업을 차별화하는 영역에 집중하도록 만드는 것이다. [10:27]
• 장기 실행 에이전트에는 대규모 분산 시스템이 필요하지만, 이 인프라를 개별 기업이 반복해서 구축해도 원하는 사업 성과로 직접 이어지기 어렵다. [10:44]

6. 지속 가능한 두뇌와 일시적인 샌드박스

• 장기 작업이 가능해지자 실행 환경이 병목이 됐으며, 에이전트의 자율성을 허용하면서도 시스템을 훼손하지 못하도록 샌드박스가 필요해졌다. [11:53]
• 기존 샌드박스는 일시적 실행을 전제로 하므로, 에이전트 전체를 그 안에 두면 연결이나 컨테이너가 종료될 때 장기 작업도 함께 사라질 수 있다. [12:28]

7. Managed Agents로 시작해 필요한 만큼 내려가는 방식

• 초기 도입 기업은 복잡한 하니스·프롬프트 캐싱·컨텍스트 엔지니어링부터 구축하기보다, 상위 추상화인 Claude Managed Agents로 장기 프로세스를 실험할 수 있다. [14:07]
• 요구사항이 구체화되면 하위 프리미티브로 내려가 프롬프트 캐싱 같은 세부 동작을 조정할 수 있어, 빠른 시작과 정밀한 통제를 함께 확보한다. [14:30]

8. 신뢰를 구성하는 보안과 관찰 가능성

• 첫 번째 신뢰 계층은 에이전트가 기업의 보안 경계 안에서만 일하도록 만드는 것이며, 자체 샌드박스를 연결해 운영 시스템과 민감 데이터의 접근 방식을 직접 통제할 수 있다. [16:27]
• 두 번째 신뢰 계층은 실행 결과와 과정을 추적하는 관찰 가능성이며, 에이전트가 올바르게 일했는지 검사하고 감사할 수 있어야 사용자에게 더 큰 자율성을 부여할 수 있다. [16:53]

9. 아키텍처 원칙과 개방형 인프라

• 모델 제공과 안전 분류기처럼 Messages API 아래의 핵심 계층은 Anthropic이 직접 운영하지만, 그 위에서는 특정 인프라보다 에이전트 아키텍처에 더 강한 원칙을 둔다. [17:42]
• 기본 API와 상위 Managed Agents 사이를 더 세분화해, 사용자가 필요한 추상화 수준과 운영 방식을 선택할 수 있는 구조를 목표로 한다. [18:06]

10. 기업 데이터에 대한 학습 정책

• 폐쇄형 모델을 사용하면 기업의 데이터와 맥락이 모델 제공사에 넘어가 경쟁 우위를 잃는다는 우려가 있지만, Anthropic은 고객 데이터로 모델을 학습하지 않는다는 정책을 둔다. [19:05]
• 기업 데이터의 보호 여부는 모델의 개방·폐쇄 구분만으로 추정하기보다, 실제 학습 정책과 배포·접근 통제 조건을 기준으로 판단해야 한다. [19:10]

11. 토큰 단가보다 사업 성과를 보는 비용 구조

• 비용 최적화의 실제 목표는 가장 싼 모델을 고르는 것이 아니라 제품 출시를 앞당기거나 팀 효율을 높이는 등 원하는 사업 성과를 합리적인 총비용으로 달성하는 것이다. [19:35]
• 더 크고 비싼 모델이라도 정확한 토큰으로 재시도와 낭비를 줄이면, 저렴한 모델을 반복 실행하는 방식보다 전체 비용이 낮아질 수 있다. [20:24]

12. 실행·조언·평가·학습으로 나뉘는 토큰의 역할

• 모든 토큰을 동일한 실행 자원으로 취급하지 않고, 작은 모델이 실행하다가 어려운 구간에서 큰 모델의 조언을 받는 방식으로 역할을 분리할 수 있다. [21:37]
• Sonnet이 실행하고 Opus가 조언한 실험에서는 Opus에 가까운 성능을 내면서도, 불필요한 토큰을 줄여 Sonnet 단독 실행보다 비용이 낮아졌다. [22:05]

13. 하니스의 기본 루프와 전략 계층

• 하니스의 최소 형태는 사용자 입력을 받고 모델을 호출한 뒤 도구를 실행하는 반복 루프이며, 모델과 대화 상태를 붙잡고 전체 실행 흐름을 관리한다. [23:51]
• 장기 작업에는 안전한 도구 실행 환경, 중단 후 재개할 대화 상태 저장소, 외부 시스템 접근용 자격 증명을 모델에 노출하지 않는 주입 계층이 추가로 필요하다. [24:17]

14. 기존 업무에 에이전트를 끼워 넣는 접근의 한계

• 대형 은행의 KYC 전체 자동화처럼 첫 과제를 지나치게 크게 잡으면, 여러 정책으로 이어 붙인 인간 업무를 충분히 분해하지 못해 구현 단계에서 막힌다. [26:17]
• 성공 가능성을 높이려면 야심 찬 프로젝트도 신입 직원이 맡을 법한 기본 단위로 쪼개고, 인간의 기존 행동을 모방시키는 대신 에이전트 중심의 업무 흐름으로 다시 설계해야 한다. [27:07]

15. 채팅창을 넘어 상시 협업자로 진화하는 인터페이스

• 모든 제품에 채팅창을 붙이던 방식에서 벗어나, 사용자가 일일이 대화하지 않아도 전체 맥락을 이해하고 실제 작업을 끝내는 유능한 동료 형태로 인터페이스가 이동한다. [28:13]
• Slack처럼 사람들이 이미 사용하는 공간에 에이전트를 배치하면 복잡한 처리는 내부에서 수행하면서도 사용자 경험은 익숙하게 유지돼 조직 전체로 확산하기 쉬워진다. [29:05]

16. 범용 제품과 맞춤형 문제 해결의 역할 분담

• 궁극적으로는 모델과 대화하는 것만으로 요구사항 정리, 스캐폴딩 구축, 임시 제품 생성과 폐기까지 처리하는 형태가 이상적이지만, 현재는 제품이나 현장 지원이 그 간극을 메운다. [30:47]
• 범용 제품은 직원이 별도 승인이나 개발팀 배정을 기다리지 않고 작은 대시보드 같은 도구를 직접 만들게 하며, 개인의 실행력과 조직의 변화 가능성을 빠르게 체감시킨다. [31:40]

17. 개발 속도가 빨라지며 조율이 새로운 병목으로 부상

• 약 200명 규모의 팀은 전통적인 제품 소유 구조를 유지하면서도 필요한 도구를 즉석에서 만들고 업무를 에이전트에 위임해 수백만 고객과 대규모 매출을 지원한다. [33:58]
• 멀티클라우드 배포와 안전·인프라 문제에는 여러 팀의 합의가 필요하지만, 개발이 이틀 만에 끝날 정도로 빨라지면서 제품 관리자와 테크 리드가 관계자를 정렬할 시간이 부족해진다. [34:36]

18. 제품 관리자는 역할의 본질에 더 집중해야 한다

• 일정 조율, 프로젝트 관리, 2주 스프린트 배정 같은 전통적인 제품 관리 업무는 Claude와의 대화만으로 실행이 빨라지면서 중요성이 줄어든다. [36:21]
• 제품 관리자의 핵심은 무엇을 누구를 위해 해결할지 결정하는 문제 선택으로 압축되며, 가설과 베팅의 품질이 이전보다 직접적으로 제품 성과를 좌우한다. [37:02]

19. 단일 베팅보다 포트폴리오가 필요한 제품 전략

• 기술과 시장의 불확실성이 크고 결과 편차도 넓기 때문에 하나의 계획에 집중하기보다 여러 베팅을 빠르게 구축해 하나라도 성공할 가능성을 확보해야 한다. [37:43]
• 구현 비용이 급격히 낮아지면 세부 기능의 우선순위보다 상위 전략이 중요해지고, 가능한 여러 결과가 모두 긍정적 효과로 이어지도록 포트폴리오의 구조를 설계해야 한다. [38:30]

20. 실패 허용과 급격한 규모 변화에 대응하는 조직

• 제품 실험에는 높은 실패 허용도가 필요하지만 엔지니어링 안정성의 기준은 더 엄격하며, 팀은 예상 밖의 안전·인프라·확장성 문제에 계획이 무너져도 즉시 대응할 준비를 갖춰야 한다. [39:00]
• 크리스마스에는 가족도 Claude를 잘 몰랐지만 몇 달 뒤에는 친척이 Mac Mini 기반 에이전트 환경을 사용할 정도로 채택이 빨라졌고, 그 변화가 플랫폼 트래픽과 운영 부담을 급증시켰다. [39:34]

21. 에이전트를 활용한 제품 검증과 개인화

• API 통합 코드를 직접 작성해야 했던 과거와 달리, 에이전트를 이용하면 고객 제품에 접속해 사용 흐름을 시험하고 스크린샷을 수집하는 과정까지 자동화할 수 있어 자체 제품 검증이 쉬워진다. [40:37]
• 원격 에이전트에게 만족·불만족 결과를 말로 전달하고 그 내용을 메모리에 저장하게 하면 선호와 실수를 다음 작업에 반영할 수 있어 별도 설정 조작 없이 생산성이 높아진다. [41:52]

22. 모델과 애플리케이션을 연결하는 공통 플랫폼

• 외부 고객과 Anthropic의 자체 제품이 동일한 API와 플랫폼을 사용하므로, 자체 제품팀도 플랫폼팀의 직접적인 고객이 되고 외부 요구와 내부 요구가 같은 기반에서 만난다. [42:48]
• 플랫폼은 가속기·추론·연구·모델 계층과 애플리케이션 사이에 위치하며, 조직 규모가 비교적 작아 각 팀과 긴밀한 관계를 유지하면서 변화에 빠르게 대응할 수 있다. [43:10]

🧾 결론

• 에이전트 플랫폼의 핵심 가치는 모든 기업이 반복해서 만들 필요가 없는 장기 실행·복구·상태 관리·보안·감사 인프라를 공통 계층으로 제공하는 데 있다.
• 경쟁력은 범용 하니스 자체보다 고객과 도메인을 이해하고 상위 최적화 계층, 시스템 프롬프트, 스킬, 도구, 평가 방식을 설계하는 능력에서 나온다.
• 기업은 최고 수준의 전면 자동화부터 시도하기보다 작은 업무 단위에서 신뢰와 경제성을 검증하고, 요구사항이 선명해질 때 통제 범위를 넓히는 편이 현실적이다.
• 개발 비용이 급격히 낮아져도 무엇을 누구를 위해 해결할지 결정하는 제품 판단과 여러 팀을 정렬하는 조직 역량은 자동으로 해결되지 않는다.

📈 투자·시사 포인트

• 장기 실행 에이전트가 확산되면 모델뿐 아니라 상태 저장, 샌드박스, 관찰 가능성, 자격 증명 관리, 평가, 모델 라우팅을 제공하는 플랫폼 계층의 중요성이 커질 수 있다.
• 비용 경쟁은 가장 싼 토큰을 공급하는 방향보다 재시도와 낭비를 줄이고 제품 출시 또는 팀 효율이라는 사업 성과를 낮은 총비용으로 달성하는 방향으로 이동할 가능성이 있다.
• 범용 에이전트 제품과 기업별 맞춤 프로세스는 대체 관계라기보다 역할 분담 관계에 가깝다. 공통 인프라는 플랫폼이 맡고, 핵심 업무 재설계는 현장 엔지니어나 내부 개발자가 담당하는 구조가 제시된다.
• 구현 속도가 빨라질수록 단일 기능의 개발력보다 고객 이해, 문제 선택, 보안 신뢰, 조직 조율, 여러 실험을 관리하는 포트폴리오 전략이 기업 간 성과 차이를 만들 수 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 모델이 Stripe API 통합을 약 70% 정확도로 완성했다는 사례는 구체적인 평가 기준, 과제 범위, 재현 조건이 제시되지 않아 일반적인 성능 수치로 해석하기 어렵다.
• Sonnet이 실행하고 Opus가 조언한 실험의 비용·성능 개선에는 구체적인 벤치마크, 토큰 사용량, 실패율이 제시되지 않았다.
• Anthropic이 고객 데이터로 모델을 학습하지 않는다는 정책만으로 전체 데이터 위험을 판단할 수는 없다. 실제 배포 방식, 보존 정책, 접근 통제, 자체 샌드박스와 MCP 서버의 운영 조건을 함께 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 전체 업무가 아니라 신입 직원에게 맡길 수 있는 수준의 단일 업무를 골라 입력, 기대 결과, 허용 도구, 실패 조건, 인간 에스컬레이션 기준을 정의한다.
• 파일 수정이나 외부 시스템 접근 같은 위험한 실행은 샌드박스로 격리하고, 에이전트 상태와 대화 기록은 실행 환경 장애에도 복구할 수 있는 지속 계층에 저장한다.
• 성공률과 토큰 가격만 비교하지 말고 완료 시간, 재시도 횟수, 인간 검수 시간, 오류 복구 비용을 포함한 목표 달성 총비용을 측정한다.
• 작은 모델의 실행, 큰 모델의 조언, 별도 평가자의 채점과 재시도를 분리하는 구성을 동일 과제에서 비교한다.

❓ 열린 질문

• 기업이 공통 플랫폼에 맡길 영역과 자체적으로 통제할 하니스·샌드박스·MCP·평가 계층의 경계는 어떤 기준으로 정해야 하는가?
• 장시간 백그라운드 작업에서 사용자가 과도하게 개입하지 않으면서도 목표 이탈을 조기에 수정할 수 있는 인터페이스는 무엇인가?
• 구현 비용이 급락한 조직에서 제품 관리자와 테크 리드는 실험 포트폴리오, 관계자 조율, 안전성 검토에 시간을 어떻게 재배분해야 하는가?