에이전트 시대의 클라우드 인프라를 설계하는 법

URL: https://www.youtube.com/watch?v=rn_afJaPldg 날짜: 2026-10-09 채널: a16z 원본 발행일: 2026-10-08 재생 시간: 56분 17초

---

📌 핵심 질문 / 이 대화가 관통하는 핵심 논점

==에이전트가 소프트웨어와 인프라를 직접 선택·생성·운영하는 시대에는 클라우드가 사람을 위한 서비스 집합을 넘어, 빠른 생성·세밀한 권한·격리된 실행·낮은 꼬리 지연을 갖춘 에이전트 실행 기반으로 바뀌어야 한다.==

• AWS는 에이전트가 API를 통해 데이터와 도구를 넘나들도록 컨텍스트 계층, 빠른 리소스 생성, 낮은 tail latency를 강화한다.
• GPU·전력·메모리·네트워크·건설 역량까지 포함한 공급망 투자가 AI 인프라 병목을 결정하며, AWS는 2026년 2,200억 달러를 투자하고 수년 내 NVIDIA GPU 200만 개를 확보하려 한다.
• 기업의 자율형 에이전트 도입은 기존 업무를 복제하는 일이 아니라 병렬 탐색, 평가, 권한, 샌드박스, 가드레일을 포함해 문제 해결 방식을 다시 설계하는 일이다.

Matt Garman은 AWS의 성장 여력이 여전히 크다고 보면서, 특정 고객과 모델에 대한 투자 집중을 피하고 기업 데이터의 신뢰 경계를 지키며 AWS 내부에서 검증한 에이전트 운영법을 고객에게 전파하는 방향을 제시한다.

1. AWS의 성장과 스타트업 중심 전략

AWS는 AI 수요와 온프레미스 워크로드의 클라우드 이전이라는 두 개의 순풍을 동시에 얻고 있으며, 스타트업은 미래 엔터프라이즈의 씨앗이자 기술 변화의 선행 지표다.

1.1. EC2 초기부터 이어진 성장 여력

1. 사업의 출발과 현재 규모
   1. 초기 경험: Garman은 2005년 비즈니스 스쿨 인턴으로 AWS 내부 프로젝트에 참여했고, AWS가 누구에게 가장 매력적일지 분석한 결과로 스타트업을 꼽았다.
   2. 현재 수치: AWS는 약 1,690억~1,700억 달러 매출과 37% 성장률을 기록했지만, 많은 워크로드가 아직 온프레미스에 남아 있어 기회가 초기 단계라고 본다.
2. 컴퓨트의 지속 증가
   1. AI와 마이그레이션: 고객이 매일 수행하는 컴퓨트는 전날보다 많아지고 있으며, AI 수요와 클라우드 이전이 성장을 함께 밀어 올린다.
   2. 장기 가능성: AWS가 처음 매출을 만들던 시기부터 함께한 Garman은 현재 사업이 역사책에 기록될 규모가 됐어도 고객 기회는 아직 남았다고 말한다.

1.2. 스타트업이 AWS에 중요한 이유

1. 미래 엔터프라이즈라는 경제적 가치
   1. 누적 매출: AWS는 역사상 한때 스타트업이었던 기업들이 현재 AWS 매출의 약 30~40%를 만든다고 추정한다.
   2. 초기 지원의 복리: AWS는 인프라뿐 아니라 회사 설립, 확장 가능한 아키텍처, 운영 방식도 조언하며 두 명이 차고에서 시작한 팀까지 지원한다.
2. 기술 레이더라는 전략적 가치
   1. 경계의 혁신: 스타트업은 은행·의료기관·정부보다 빠르게 기술의 한계를 밀어붙이며, 더 빠르게 성과를 내는 데 필요한 기능을 알려준다.
   2. 미래 수요 예측: 스타트업이 오늘 원하는 기능은 대기업이 5년 뒤 원할 기능일 수 있으므로, AWS는 스타트업을 통해 변화보다 앞선다.

1.3. 오늘날 스타트업 고객의 변화

1. 출발 규모의 확대
   1. 과거: 약 1,000만 달러의 자금으로 앱 아이디어를 천천히 반복 개선하는 팀이 전형적이었다.
   2. 현재: 시작부터 10억 달러 가치와 2억 달러 자금을 확보하는 팀이 생겼고, 모델 학습 등으로 초기 컴퓨트 비용도 훨씬 커졌다.
2. 변하지 않은 요구
   1. 확장성: 아키텍처·보안·성능·기능·IAM 설정을 확장할 수 있어야 한다.
   2. 플랫폼 깊이: 직원이 세 명을 넘은 뒤에도 쓸 수 있는 보안·운영·확장 기능 때문에 단순히 쉬운 네오클라우드보다 AWS를 택한다.

2. 에이전트를 위한 클라우드 재설계

에이전트는 메뉴를 클릭하지 않고 API를 조합하므로, 데이터·도구·권한·실행 환경을 빠르고 안전하게 연결하는 클라우드가 필요하다.

2.1. 사람용 서비스에서 에이전트용 기반으로

1. 기본 특성
   1. API와 생성 속도: 에이전트가 쉽게 순회할 수 있는 명확한 API와 약 3초 안에 데이터베이스를 시작하는 수준의 생성 속도가 필요하다.
   2. 기존 서비스 최적화: AgentCore와 Bedrock 같은 에이전트 서비스뿐 아니라 S3·Aurora 같은 기반 서비스도 사람과 에이전트가 함께 쓰도록 개선한다.
2. 데이터 컨텍스트와 성능
   1. AWS Context: Aurora, S3 등 여러 데이터 저장소의 정보를 에이전트가 찾도록 컨텍스트 계층을 만드는 베타·프리뷰 기능이다.
   2. 꼬리 지연: 사람은 P99.9 S3 지연을 늘 신경 쓰지 않지만 에이전트는 tail latency에 막혀 전체 워크플로가 멈출 수 있다. 처리량·확장성·예측 가능한 지연이 중요하다.

2.2. 에이전트가 바꾸는 배포 온램프

1. 자연어 배포
   1. 코딩 에이전트: 고객은 Kiro, Claude, Codex 등에 AWS에서 만들 것, 자격 증명, 배포 방식을 알려주고 에이전트가 인프라를 구성하게 한다.
   2. 파트너 계층: 아직 클라우드를 선택하지 않은 사용자가 “배포”라고만 말할 때는 더 쉬운 계층을 제공하는 파트너로 가기도 하며, AWS는 파트너 생태계를 긍정적으로 본다.
2. 30초 계정
   1. 기존 장벽: 새 계정을 만들려면 VPC와 IAM 역할을 정의해야 했고, 이는 대규모 운영에는 중요하지만 첫 실험에는 부담이었다.
   2. 새 온램프: 단계적으로 출시 중인 방식은 Gmail 가입과 기본 설정 자동화로 신용카드 없이 30초 이내 실제 AWS 계정을 시작하게 하며, 나중에 조직과 세부 설정을 추가해도 계정을 옮길 필요가 없다.

3. 에이전트 시대의 새로운 인프라 블록

에이전트는 영구적인 운영 시스템과 다른 수명·권한·격리 요구를 갖기 때문에, 일시적 실행과 장기 운영을 동시에 수용해야 한다.

3.1. 일시적 데이터베이스와 내구성

1. 수명 차이
   1. 에이전트 작업: 데이터베이스를 만들고 잠깐 작업한 뒤 없애는 경우가 많다.
   2. 운영 데이터베이스: Aurora는 높은 내구성, 가용성, 데이터 보호를 위해 설계돼 짧은 실험에는 과할 수 있다.
2. 설계 절충
   1. 위험한 비내구성 옵션: 사용자가 장기 운영할 리소스를 잘못 고를 수 있으므로 단순히 비내구성 옵션을 제공할 수 없다.
   2. 성장 경로: 빠르게 만들고 필요 없을 때 버리되 계속 쓰기로 하면 생산 데이터베이스로 성장하게 하는 설계가 필요하다.

3.2. 권한과 샌드박스

1. 사람 권한을 복제하지 않기
   1. 단기 권한: 에이전트에는 root나 전체 도구 권한 대신 특정 작업에만 유효한 짧은 만료 권한을 줘야 한다.
   2. 세밀한 통제: 도구 전체가 아니라 개별 동작 단위까지 허용 범위를 줄여야 한다.
2. Firecracker
   1. 실행 격리: 에이전트 코드와 리소스를 가벼운 샌드박스 안에서 실행해 다른 시스템을 보호한다.
   2. 마이크로VM: AWS가 약 10년 전 개발한 Firecracker는 빠른 기동, 강한 보안 경계, 전통적 대형 VM보다 작은 가상화 오버헤드 때문에 샌드박스 스타트업들이 널리 사용한다.
3. 새 구성요소
   1. 게이트웨이와 에이전트 권한: 기존 구성요소의 사용법만 바꾸는 것이 아니라 게이트웨이·단기 권한·실행 샌드박스라는 새 기본 블록이 필요하다.
   2. 지속적 갱신: 에이전트가 매일 새로운 작업 방식을 보여 주므로 AWS는 이 설계를 계속 조정한다.

4. GPU 부족과 AI 인프라 투자

AI 컴퓨트 확장은 GPU만의 문제가 아니라 전력·데이터센터·메모리·네트워크·건설 역량을 함께 확보하는 공급망 문제다.

4.1. 자본 지출과 복합 병목

1. 수요와 건설
   1. 2026년 투자: AWS의 자본 지출은 약 2,200억 달러이며 수요가 막대해 가까운 시일에 줄일 계획이 없다.
   2. 물리적 한계: 데이터센터를 짓는 속도, 자본 집행, 메모리·칩 확보, 전력, 건설 인력 모두 시점별 병목이 된다.
2. 수년 단위 조달
   1. GPU 확보: AWS는 수년 내 NVIDIA GPU 200만 개를 구매하겠다고 발표했지만 그것만으로 충분할지는 다른 구성요소에 달려 있다.
   2. 공급망 전체: 전력·부지·자본·메모리·칩뿐 아니라 전송과 네트워크까지 동시에 계획해야 한다.

4.2. GPU 할당

1. 고객군 균형
   1. 대형 고객: Anthropic·OpenAI·Meta 같은 프론티어 연구소와 Salesforce·JPMorgan Chase 같은 기업은 대규모 또는 특정 구성의 가속기를 원한다.
   2. 스타트업 용량: AWS는 모든 GPU를 대형 연구소에 팔 수 있지만 미래 엔터프라이즈가 될 스타트업을 위해 용량을 의도적으로 남긴다.
2. 현실적 배분
   1. 응답률: 요청의 약 60%에 결국 어떤 방식으로든 “예”라고 답하지만, 늦은 시점·다른 리전·다른 구성일 수 있다.
   2. 계속되는 부족: 모든 스타트업은 더 많은 GPU를 원하므로 “좋은 문제”인 동시에 실제 문제로 남는다.

4.3. AI 투자 거품 논쟁

1. 집중 위험
   1. AWS의 분산: 일부 네오클라우드의 한두 고객 매출 비중이 30~60%인 반면 AWS의 단일 고객 비중은 최고도 한 자릿수 퍼센트다.
   2. 수요의 질: AWS 용량은 모델 학습뿐 아니라 핵심 컴퓨트·스토리지·추론과 프로덕션 애플리케이션에 쓰인다.
2. 인터넷 버블의 교훈
   1. 선별 투자: 모든 10억 달러 스타트업이 성공하지는 않지만 여러 기업 중 일부의 성공이 실패를 보상하는 구조는 오래됐다.
   2. 지속되는 인프라: 인터넷 버블 뒤에도 인터넷과 Google·Amazon 같은 내구성 있는 기업은 남았다. 고객 대부분이 현재 비용으로 긍정적 ROI를 얻는다고 답하므로 실제 업무 수요는 사라지지 않는다.

5. 전력·공급망·데이터센터

AI 인프라는 단기 서버 주문에서 20년 단위 전력·송전·공급망·지역 계획으로 바뀌었고, AWS는 고객이 감당하기 어려운 조달을 대신한다.

5.1. 전력 계획

1. 전력 프로젝트
   1. 과거와 현재: 15년 전에는 전력회사에 수십 메가와트를 요청하면 됐지만 이제는 자체 전력 프로젝트가 필요하다.
   2. 재생에너지: AWS는 최근 10년 동안 대형 재생에너지 구매자 중 하나였고 태양광·원자력 프로젝트에 비용을 낸다.
2. 두 가지 공급 방식
   1. 그리드 연계: 프로젝트 자본을 부담하고 전력망에 연결한 뒤 사용 크레딧을 받는다.
   2. Behind-the-meter: 데이터센터 뒤에서 직접 공급하는 방식도 지역과 규모에 따라 병행한다.

5.2. 항상 다음 병목이 온다

1. 병목 이동
   1. 구성요소: 전력이 해결되면 메모리, TSMC, HBM, 네트워크 부품, 커넥터가 다음 병목이 된다.
   2. 지역성: 인도네시아 전력이 충분해도 독일에는 부족할 수 있어 자원이 완전히 대체 가능하지 않다.
2. 다단계 추적
   1. 부품 관리: AWS는 수만~수십만 개 부품을 추적하고 일부는 공급업체에, 일부는 직접 관리한다.
   2. 선행 대응: 10년 전부터 공급망 4~5단계 아래까지 추적했으며 태국 홍수의 디스크 드라이브 부족과 메모리 위기를 교훈으로 삼았다.

5.3. 데이터센터의 지역사회 가치

1. 환경·경제 편익
   1. 환경 관리: AWS는 재생에너지를 확보하고 물 사용량을 줄이며, 대부분 자유 공기 냉각을 사용해 데이터센터의 물 사용량이 매우 적다고 설명한다.
   2. 지역 경제: 고임금 일자리를 만들고 지역 세금을 내지만 주민이 편익을 체감하지 못하는 경우가 많다.
2. 투명성
   1. 세금 사례: 한 카운티에서는 AWS의 세금 덕분에 주민의 연간 세금 부담이 5,000달러 낮다는 보고가 있었지만 주민들은 잘 몰랐다.
   2. 업계 평판: 규정을 무시하거나 지역 영향을 고려하지 않는 일부 사업자가 업계 전체의 평판을 해치므로 좋은 시민과 그렇지 않은 사업자를 구분해 알려야 한다.

6. Graviton과 Trainium

AWS의 자체 칩은 가상화 오버헤드를 줄이는 Nitro에서 ARM 서버 Graviton, AI 가속기 Trainium으로 단계적으로 확장됐다.

6.1. Nitro와 Graviton

1. 가상화 세금 제거
   1. 오프로딩: AWS는 네트워크 가상화를 카드로 옮긴 뒤 ARM 코어가 있는 회사를 찾아 스토리지 가상화도 처리하도록 실험했다.
   2. Nitro 효과: 인수한 팀과 더 큰 카드를 만들었고, 네트워크·스토리지 가상화를 카드 API로 처리해 자원 활용·성능·보안 격리를 높였다.
2. ARM 생태계
   1. 초기 Graviton: Nitro 카드의 ARM 코어를 작은 서버로 확장한 뒤 ARM 성능과 전력 효율의 교차점을 보고 생태계를 키웠다.
   2. 성과: Graviton은 최근 5~6년 동안 약 20% 저렴하면서 20% 더 나은 성능을 제공했고, 상위 100개 고객의 90% 이상이 사용한다. 전체 플릿을 옮겨 서버 수를 절반으로 줄인 사례도 있다.

6.2. Trainium

1. 선제 투자와 수요
   1. 세대: AWS는 5~6년 전 AI 컴퓨트를 예상해 칩을 만들었고 현재 Trainium 3까지 출시했으며 용량은 다음 해 말 무렵까지 매진에 가깝다.
   2. 고객: Bedrock 트래픽 대부분이 Trainium에서 실행되고 Anthropic·OpenAI 및 6~12개 스타트업이 Trainium을 사용한다.
2. 학습과 추론
   1. 이름과 현실: 학습용으로 이름 붙였지만 대형 모델 추론에서 절대 성능과 비용 대비 성능이 뛰어나며, 아키텍처가 다르고 가격이 낮다.
   2. 미래: Trainium 4는 아직 출시되지 않았지만 발표된 아키텍처가 대규모 학습 클러스터의 미래로 고객의 관심을 받고 있다.

7. 기업 에이전트 도입과 자율화

기업은 사람 개입형 에이전트로 이미 가치를 얻고 있지만, 완전 자율화에는 업무 재설계와 신뢰·평가 체계가 필요하다.

7.1. 복제가 아닌 그린필드 재설계

1. 현재 상태
   1. 초기 에이전트: 대부분 단순하고 비자율적이며 사람이 중간에 개입한다.
   2. 다음 단계: 기업은 안전한 방식으로 자율성을 높이려 한다.
2. 업무를 다시 정의하기
   1. 복제의 한계: 사람이 1·2·3·4·5단계를 한 뒤 확인하는 흐름을 에이전트에 복사하면 큰 가치가 나오지 않는다.
   2. 병렬화: 목표만 정하고 에이전트가 50가지 방법을 시도하게 하며, 보험 승인 같은 업무도 컴퓨터가 문제를 푸는 방식에 맞춰 새로 설계해야 한다.

7.2. 신뢰와 평가

1. 안전한 실행
   1. 보호 장치: 권한·가드레일·샌드박스·사람 개입 여부를 설계해 운영 데이터베이스 삭제 같은 치명적 실수를 막아야 한다.
   2. 자율성의 한계: 현재 기업의 불안은 적절하며, “마음껏 하라”고 말하기 전에 안전한 아키텍처와 기술이 필요하다.
2. 평가 체계
   1. 지속적 테스트: 평가를 계속 돌리고 목표 달성을 합리적으로 측정하며 실제 운영을 대표하는 라벨을 만들어야 한다.
   2. 드리프트: 프로덕션을 측정하고 백테스트해 모델·데이터·워크플로 변화로 인한 드리프트를 찾아야 한다.

7.3. FDE와 45일 역량 이전

1. 지원 수요
   1. 전문팀: 기업이 평가·라벨링·운영 측정을 잘하지 못해 AWS와 파트너가 FDE(Field Development Engineer) 팀을 확대한다.
   2. 종속 방지: 반복적인 외부 컨설팅이 아니라 고객이 스스로 운영하는 능력을 갖추는 것이 목표다.
2. 공동 구축
   1. 과정: 고객과 약 45일 동안 평가를 만들고 데이터를 라벨링하며 실제 업무를 수행한다.
   2. 결과: 45일 뒤 FDE가 떠나도 고객이 직접 운영할 수 있어야 하며, 고객 역시 5년 동안 외부 인력에 종속되는 것을 원하지 않는다.

8. 기업 데이터, 오픈 웨이트, AI 보안

기업 데이터는 핵심 자산이므로 모델 선택의 개방성과 신뢰 경계 안의 데이터 통제를 함께 확보해야 한다.

8.1. Bedrock

1. 데이터 경계
   1. VPC 보호: Bedrock의 데이터는 고객 VPC를 떠나지 않고 모델 제공자에게 프롬프트가 전달되지 않는다.
   2. 프로덕션 정착: AWS는 출시가 느리다는 비판을 받았지만 데이터 보호와 내구성 있는 기반을 먼저 만들었고, 개념증명에서 프로덕션으로 넘어가는 고객이 Bedrock을 택하는 이유가 됐다.
2. 모델 개방성
   1. 선택권: 오픈 모델·독점 모델을 모두 제공하고 AgentCore로 Bedrock 안팎 및 Gemini 같은 외부 모델도 연결한다.
   2. 위험 관리: 기업 데이터가 모델 제공자에게 돌아가는 구조는 위험하므로 모델을 바꿔도 신뢰 환경을 지키는 것이 차별점이다.

8.2. 오픈 웨이트와 SageMaker

1. 작고 맞춤화된 모델
   1. 가능성: 독점 데이터를 오픈 웨이트 모델에 추가 학습·파인튜닝·증류하면 낮은 가격으로 더 높은 업무 성능을 얻을 수 있다.
   2. 전제: 개선 여부를 증명할 평가가 먼저 필요하다.
2. 플랫폼의 재부상
   1. 현재 사용: 고객은 SageMaker에서 오픈 웨이트 모델을 조정하고 SageMaker로 추론을 호스팅한다.
   2. 개선 방향: 여러 모델을 테스트하고 학습·평가·배포를 연결하는 기능을 더 만들어야 하며, 기업의 자체 맞춤 모델 구축이 SageMaker의 역할을 키운다.

8.3. Continuum과 머신 속도 보안

1. CEO의 질문
   1. 통제: Hugging Face 공격과 보안 취약점 논의 속에서 에이전트가 의도한 행동만 하도록 신뢰하는 방법이 핵심 질문이다.
   2. 통제 수단: 권한·샌드박스·가드레일·사람 개입 여부를 포함한 안전한 배포가 필요하다.
2. AI로 AI 방어
   1. 양면성: 강력한 모델이 공격 표면이 될 위험과 동시에 취약점을 발견할 기회를 만든다.
   2. Continuum: 환경 전체의 취약점을 찾고 권한·구성·보완 통제라는 맥락으로 우선순위를 정한다. 사람 속도가 아닌 머신 속도의 보안이 목표다.

9. AWS 내부 도입과 조직 변화

AWS는 에이전트를 개발뿐 아니라 보안·인사·재무에 적용하고, 작은 팀이 에이전트 무리와 함께 더 빠르게 제품을 만드는 조직 실험을 진행한다.

9.1. Amazon Quick

1. 업무 부서의 자립
   1. 전사 배포: Amazon Quick을 모든 직원에게 배포하자 인사·재무팀이 개발자에게 막히지 않고 직접 에이전트를 만들었다.
   2. 사례: HR의 팀 계획·자원 관리는 수주 걸리던 일이 한 사람이 몇 시간에 처리하는 일로 바뀌었고, 재무팀은 여러 곳의 세법을 모아 규정 준수를 점검한다.
2. 고객 확산
   1. 범위: 작은 스타트업부터 대기업까지 Quick을 도입해 기업 데이터에 에이전트를 적용한다.
   2. 효과: 소프트웨어 개발과 보안, HR 정책 전반에서 개발자 병목이 줄고 업무 부서의 혁신 속도가 올라간다.

9.2. 개발 속도와 조직

1. 프론티어 팀
   1. 개발 방식: 가장 큰 개선은 코드 자동완성이 아니라 제품 개발과 출시 전체의 속도이며, 에이전트가 코드를 쓰고 사람은 에이전트 팀을 관리한다.
   2. 수요 대응: AWS는 원래 기능 출시가 빠르지만 최근 1년 동안 에이전트 우선 개발로 고객 혁신 속도가 더 빨라졌다.
2. 포드 조직
   1. 팀 규모: 과거 10명이 맡던 기능을 3~4명이 빠르게 만들고 다른 문제로 이동하는 방식을 실험한다.
   2. 미완의 과제: 사람은 상당 기간 남고, 운영·유지보수와 팀 재배치를 함께 설계해야 한다. 직원은 더 빠르게 만들고 더 많은 일을 하는 점을 긍정적으로 보지만 조직 모델에는 아직 정답이 없다.

주요 발언 모음

“스타트업은 AWS가 배우는 곳이다. 기술의 경계에서 무엇이 가능한지 이해하고, 우리가 더 빨리 움직이도록 서비스를 밀어붙인다.”

“에이전트에는 사람이나 root 권한을 그대로 주고 무엇이든 하게 해서는 안 된다. 짧고 시간 제한이 있는 권한과 세밀한 동작 단위 권한이 필요하다.”

“전력이 병목이 아니게 되면 메모리, TSMC, HBM, 네트워크 부품, 커넥터 중 다른 것이 병목이 된다.”

“사람이 하던 1·2·3·4·5단계를 에이전트에게 복사하는 데서 멈추지 말고, 에이전트가 문제를 완전히 다른 방식으로 풀 수 있도록 다시 생각해야 한다.”

“고객이 원하는 것은 다음 5년 동안 외부 인력에 종속되는 것이 아니다. 약 45일 동안 함께 일한 뒤 고객이 스스로 평가하고 운영할 수 있어야 한다.”

“고객은 인간의 속도가 아니라 머신의 속도로 보안을 해야 한다.”

핵심 데이터 & 수치

• AWS 매출 약 1,690억~1,700억 달러, 성장률 약 37%.
• AWS 역사상 한때 스타트업이었던 기업이 AWS 매출의 약 30~40%를 만든다고 추정한다.
• AWS는 2026년 약 2,200억 달러의 자본 지출을 계획한다.
• AWS는 수년 내 NVIDIA GPU 약 200만 개를 구매하겠다고 발표했다.
• GPU 요청의 약 60%에 결국 어떤 형태로든 답한다.
• AWS의 단일 고객 비중은 최고도 한 자릿수 퍼센트 수준이라고 설명한다.
• Graviton은 최근 5~6년 동안 약 20% 저렴하고 20% 높은 성능을 제공했다.
• AWS 상위 100개 고객의 90% 이상이 Graviton을 사용한다.
• 새 AWS 계정은 자동 기본 설정으로 30초 이내 시작하는 방향으로 단순화된다.
• 한 카운티에서 AWS의 세금 납부로 주민의 연간 세금 부담이 5,000달러 낮아졌다는 보고가 있다.
• FDE 지원은 약 45일 공동 구축 뒤 고객에게 평가·라벨링·운영 소유권을 넘기는 모델을 지향한다.

결론 및 시사점

1. 사람 중심 클라우드는 에이전트가 API와 데이터를 조합하는 실행 기반으로 진화해야 한다.
2. 에이전트 시대에는 평균 지연보다 꼬리 지연, 빠른 기동, 처리량, 예측 가능성이 중요하다.
3. 단기 권한·세밀한 동작 제어·샌드박스·게이트웨이·일시적 데이터베이스가 새로운 기본 블록이 된다.
4. AI 인프라는 GPU 주문이 아니라 전력·송전·HBM·TSMC·네트워크·건설을 포함한 공급망 사업이다.
5. 투자 위험은 특정 고객과 모델에 집중됐는지, 프로덕션 수요로 분산됐는지를 통해 판단해야 한다.
6. 기업은 기존 절차를 자동화하는 대신 에이전트의 병렬 탐색에 맞춰 업무 목표와 과정을 그린필드에서 재설계해야 한다.
7. 평가·라벨링·드리프트 모니터링·권한·샌드박스·가드레일이 완전 자율성의 전제다.
8. 모델 선택보다 기업 데이터가 신뢰 환경 밖으로 나가지 않는 구조를 먼저 마련해야 한다.
9. Continuum처럼 AI로 취약점을 찾고 우선순위를 정하면 보안도 머신 속도로 확장할 수 있다.
10. 3~4명의 팀과 에이전트 묶음이 제품 개발 속도를 높이지만 유지보수와 조직 재배치는 여전히 실험 중이다.

핵심 요약 (20줄)

AWS는 약 1,690억~1,700억 달러 매출과 37% 성장률을 기록하면서도 온프레미스와 AI 수요로 장기 성장 여력을 가진다.

스타트업은 AWS 매출의 약 30~40%를 만든 미래 엔터프라이즈이자 기술 변화의 빠른 신호다.

오늘날 AI 스타트업은 시작부터 10억 달러 가치와 2억 달러 자금을 확보할 만큼 규모가 커졌다.

에이전트용 클라우드는 명확한 API, 빠른 리소스 생성, 높은 처리량, 낮은 꼬리 지연을 갖춰야 한다.

AWS Context는 Aurora와 S3 등 여러 저장소의 데이터를 에이전트가 찾도록 돕는 컨텍스트 계층이다.

새 AWS 계정은 Gmail 가입과 기본 설정 자동화로 30초 안에 클라우드를 시작하는 방향으로 단순화되고 있다.

에이전트 인프라는 일시적 데이터베이스, 단기 권한, 세밀한 동작 제어, 게이트웨이, 샌드박스를 요구한다.

Firecracker 마이크로VM은 빠른 기동과 강한 격리 덕분에 에이전트 실행 환경에 적합하다.

AWS는 2026년 약 2,200억 달러를 투자하고 수년 내 NVIDIA GPU 200만 개를 확보하려 한다.

GPU 공급은 전력, 데이터센터, 자본, 메모리, 칩, 네트워크, 건설 인력의 복합 병목에 의해 제한된다.

AWS는 스타트업 용량을 남겨 GPU 요청의 약 60%에 어떤 방식으로든 답하면서 생태계를 분산한다.

AWS는 고객 집중도가 한 자릿수 퍼센트 수준이고 프로덕션 수요가 분산돼 투자 위험이 낮다고 본다.

전력이 해결되면 HBM, TSMC, 네트워크 부품, 커넥터처럼 다른 공급망 병목이 나타난다.

Graviton은 최근 5~6년 동안 약 20% 낮은 비용과 20% 높은 성능을 제공했고 상위 고객의 90% 이상이 사용한다.

Trainium은 Bedrock 추론의 대부분을 담당하며 대형 모델에서 학습과 추론 비용 대비 성능을 모두 노린다.

기업은 사람의 1·2·3·4·5단계를 복제하기보다 에이전트가 여러 방법을 병렬 시도하도록 업무를 재설계해야 한다.

완전 자율 에이전트는 권한, 샌드박스, 가드레일, 평가, 라벨링, 드리프트 모니터링 없이는 신뢰할 수 없다.

Bedrock은 기업 데이터와 프롬프트가 고객 VPC 밖으로 나가지 않도록 하며 여러 모델을 지원한다.

Continuum은 강력한 모델로 취약점을 찾고 환경 맥락에 따라 우선순위를 정해 머신 속도의 보안을 돕는다.

Amazon은 Quick을 전 직원에게 배포했고 소규모 팀과 에이전트가 제품 개발과 업무 혁신의 속도를 높이고 있다.

---

메타데이터

• video_id: rn_afJaPldg
• title_original: Building Infrastructure for the Agent Era | AWS CEO Matt Garman
• channel: a16z
• drop_date: 2026-10-08
• processed_date: 2026-10-09
• duration_seconds: 3377
• video_url: https://www.youtube.com/watch?v=rn_afJaPldg
• category: ai-llm
• speaker: Matt Garman, AWS CEO
• host: Raghu Raghuram
• transcript_source: YouTube English auto-generated captions
• tags: #AWS #a16z #MattGarman #AI #AgenticAI #CloudInfrastructure #GPU #Trainium #Graviton #Bedrock #SageMaker