AWS가 클라우드를 사람 개발자보다 AI agent(스스로 도구를 써서 여러 단계의 작업을 해내는 AI)가 쓰기 좋은 형태로 다시 짜고 있습니다. AWS CEO Matt Garman은 coding agent가 코드를 쓰고 데이터베이스를 고르고 인프라까지 배포하는 일이 늘면서, 계정을 만드는 방식부터 데이터베이스의 내구성 기준, 권한 체계까지 사람을 전제로 한 설계를 손보고 있다고 밝혔습니다. 동시에 GPU 부족 속에서 용량을 누구에게 어떻게 나누는지, 자체 칩 Graviton과 Trainium이 어떤 역할을 맡는지도 설명했습니다. 한국에서 AWS로 서비스를 만드는 개발자와 스타트업이 짚어 볼 만한 내용을 정리합니다.
규모: 연 매출 약 $1,700억, 성장률 37%
AWS의 연간 매출 규모는 약 $1,690억~1,700억이고 성장률은 약 37%입니다. Garman은 이 규모에서도 클라우드가 아직 초기 단계라고 봅니다. 전 세계 기업 업무의 대부분이 여전히 자체 서버(온프레미스)에 남아 있고, 기존 업무의 클라우드 이전과 생성형 AI 수요라는 두 흐름이 함께 수요를 끌어올리고 있다는 설명입니다.
스타트업에 대한 시각도 눈여겨볼 만합니다. Garman은 2005년 AWS 인턴 시절 어떤 고객이 클라우드를 가장 반길지 분석했고, 초기 비용 부담이 없는 종량제 덕분에 스타트업이 첫 시장이라는 결론을 냈습니다. 지금도 AWS 매출의 30~40%가 AWS에서 스타트업으로 출발한 기업에서 나온다고 추산합니다. 스타트업은 금융·의료·공공 기관보다 서비스를 훨씬 거세게 밀어붙이는 설계 파트너이고, 이들의 요구가 3~5년 뒤 대기업이 원할 기능을 미리 알려 준다는 것입니다.
다만 스타트업의 모습은 달라졌습니다. 예전에는 $1,000만을 모아 앱 하나를 천천히 다듬었다면, 지금의 AI 스타트업은 $2억 투자와 $10억 기업 가치로 시작하기도 합니다. 모델 학습과 GPU 확보에 드는 돈이 크기 때문입니다. 그래도 확장성, 성능, 보안, 권한 설정이라는 기본 과제는 그대로라고 Garman은 짚습니다.
agent가 클라우드에 요구하는 네 Ghazi
1. 30초 안에 시작하는 계정
지금까지 AWS 계정을 쓰려면 VPC(가상 사설망), 서브넷, 라우팅 테이블, IAM 역할(접근 권한 설정)부터 잡아야 했습니다. 사용자가 Cursor, Claude, Codex 같은 coding agent에 클라우드 자격 증명을 주고 배포까지 맡기는 상황에서는 이런 사전 설정이 큰 걸림돌입니다.
AWS는 Gmail 같은 일반 계정으로 가입하고 처음에는 신용카드도 입력하지 않은 채 30초 안에 바로 쓸 수 있는 계정을 내놓고 있습니다. 네트워크와 보안 기본값은 뒤에서 자동으로 잡힙니다. 중요한 점은 이것이 기능을 줄인 체험용 계정이 아니라는 것입니다. 서비스가 커져 조직 구조를 갖추거나 세부 설정을 바꿀 때도 같은 계정 안에서 하면 되므로 옮겨 갈 필요가 없습니다. 다만 이 방식은 차례로 적용되는 중이라 모든 계정에서 바로 쓸 수 있는 것은 아닐 수 있습니다.
2. 쓰고 버리는 자원
AWS는 Amazon Aurora처럼 ‘파이브 나인(99.999%)’ 수준의 내구성과 가용성을 기본으로 서비스를 설계해 왔습니다. 그런데 agent는 중간 계산을 위해 임시 데이터베이스를 띄웠다가 작업이 끝나면 곧바로 버리는 경우가 많습니다. 이런 일회용 작업에까지 여러 지역 복제와 최고 수준의 내구성을 붙이면 과한 설계가 됩니다.
그래서 AWS는 자원을 밀리초 단위로 만들고 지우되, 필요하면 오래 보관하는 선택지도 남기는 구조를 찾고 있습니다. agent가 데이터베이스를 띄우고 조회까지 3초 안에 끝내는 것이 목표입니다.
3. 작업 단위의 시한부 권한과 sandbox
사람이나 고정된 서비스 역할을 위해 만든 기존 IAM 권한은 agent에 맞지 않습니다. agent가 넓고 오래가는 자격 증명을 들고 있으면 안 되기 때문입니다. AWS는 agent가 특정 하위 작업에 필요한 최소한의 도구와 범위만, 정해진 시간 동안만 쓰게 하는 권한 체계를 만들고 있습니다.
실행 환경의 격리도 중요합니다. agent가 만든 코드는 즉시 뜨면서도 경계가 단단한 sandbox(격리된 실행 공간)에서 돌려야 합니다. AWS는 약 10년 전에 만든 microVM(아주 가벼운 가상 머신) 기술 Firecracker를 이 용도에 씁니다. 빠르게 부팅되고 격리가 강해서, AI 업계에 새로 생기는 sandbox 스타트업 다수도 Firecracker 위에서 서비스를 만든다고 합니다.
▲ 시한부 권한과 격리 실행
4. 꼬리 지연을 줄인 기반
agent 작업은 수백 개의 단계를 차례로 실행하기 때문에, 드물게 생기는 느린 응답(꼬리 지연, 예를 들어 Amazon S3의 p99.9 지연)이 쌓이면 전체 작업이 크게 늦어집니다. 사람은 가끔 느린 응답을 참지만 agent의 연쇄 작업에서는 지연이 누적됩니다. Garman은 AWS가 오랫동안 꼬리 지연을 줄이는 데 공들여 온 것이 agent를 돌리는 데 경쟁력이 된다고 주장합니다.
이 밖에도 AWS는 agent용 서비스인 Amazon Bedrock과 AgentCore로 메모리, 게이트웨이, 권한 경계를 관리하게 하고, Amazon S3 같은 기본 서비스도 사람이 아닌 접근 방식에 맞춰 조정하고 있습니다. 미리 보기로 공개한 AWS Context는 S3와 Aurora처럼 흩어진 데이터 저장소 위에 메타데이터 층을 얹어, agent가 여러 저장소의 데이터를 한 번에 조회하게 하는 서비스입니다.
GPU는 어떻게 나누나
GPU 부족은 AI 스타트업의 가장 큰 병목입니다. AWS는 고객의 GPU 용량 요청 가운데 약 60%를 지역, 시기, 클러스터 구성을 조정하는 방식으로 어떤 형태로든 충족한다고 밝혔습니다.
배분 원칙도 분명합니다. AWS는 Anthropic, OpenAI, Meta 같은 최전선 AI 연구소에 클러스터 전체를 몰아주지 않고, Salesforce와 JPMorgan Chase 같은 대기업, 그리고 초기 스타트업 몫을 따로 남겨 둡니다. 고객 한 곳의 매출 비중도 한 자릿수 퍼센트로 유지합니다. Garman은 고객 한두 곳이 매출의 30~60%를 차지하는 GPU 전문 클라우드(neo-cloud)와 비교하며 이 방식이 위험을 줄인다고 봅니다.
투자 규모도 큽니다. AWS는 앞으로 몇 년간 NVIDIA GPU 약 200만 개를 추가로 들이기로 했고, 2026년 설비 투자는 약 $2,200억 규모로 거론됐습니다. Garman은 이런 수요가 거품이 아니라고 말합니다. 고객이 실제 운영 업무에서 투자 대비 효과를 확인하고 있다는 이유입니다.
용량을 늘리는 데는 물리적 한계가 따릅니다. 전력, 데이터센터 건설 속도, 메모리와 칩 공급, 숙련 인력이 모두 병목입니다. Garman은 병목 하나를 풀면 곧바로 다음 병목이 나타난다는 ’제약 이론’을 들어, 전력을 해결하면 메모리, TSMC의 패키징, HBM(고대역폭 메모리), 네트워크 장비로 제약이 옮겨 간다고 설명합니다. 그래서 AWS는 서버 계획을 분기 단위에서 2026~2028년을 내다보는 여러 해 단위로 바꿨고, 전력과 송전은 최대 20년 앞을 보고 계획합니다.
자체 칩: Graviton과 Trainium
AWS 자체 칩의 출발점은 약 13~14년 전의 가상화 부담이었습니다. 가상화가 서버 연산을 잡아먹자 AWS는 네트워크와 스토리지 가상화를 전용 카드로 넘겼고, ARM 코어를 넣은 카드를 만들던 Annapurna Labs를 인수했습니다. 이것이 Nitro 시스템과 베어메탈 서버로 이어졌고, 카드의 ARM 코어를 키워 만든 서버용 CPU가 Graviton입니다.
| 칩 | 용도 | 핵심 수치와 현황 |
|---|---|---|
| Graviton | 서버용 ARM CPU | 비용 약 20% 절감, 성능 약 20% 향상. 상위 100개 고객의 90% 이상이 사용 |
| Inferentia | AI 추론 | 약 5~6년 전 시작한 AI 칩 개발에서 추론용으로 만든 칩 |
| Trainium 3 | AI 학습과 추론 | 3세대, 내년 말까지 용량이 거의 예약됨 |
| Trainium 4 | 차세대 AI 칩 | 미리 발표 |
Graviton은 AWS가 해마다 가장 많이 들이는 서버 프로세서이고, 일부 고객은 서버 전체를 옮겨 서버 수를 절반으로 줄였다고 합니다. Garman은 Graviton 전환을 AWS 비용을 줄이는 가장 쉬운 방법으로 꼽습니다.
Trainium은 이름과 달리 학습뿐 아니라 추론에서도 비용 대비 성능이 좋은 칩이 됐다는 설명입니다. Amazon Bedrock의 추론 작업 대부분이 Trainium에서 돌고, Anthropic과 OpenAI도 Trainium으로 작업합니다. Garman은 Inferentia와 Trainium이라는 이름이 혼란을 준다며 AWS가 이름 짓기에 서툴다고 스스로 인정하기도 했습니다.
▲ 자체 칩과 전력 병목
기업 agent가 막히는 곳: 신뢰와 평가
기업의 agent 도입은 빠르게 늘지만, 대부분은 사람이 단계마다 승인하는 비자율 방식입니다. 직원이 하던 다섯 단계 절차를 그대로 옮기는 식입니다. Garman은 사람의 순서를 베끼지 말고 목표 결과부터 정한 뒤, agent가 수십 Ghazi 경로를 동시에 시도하는 방식으로 업무를 처음부터 다시 설계하라고 권합니다.
자율 agent를 막는 가장 큰 벽은 모델 성능이 아니라 신뢰입니다. 권한이 잘못 잡힌 agent가 운영 데이터베이스를 통째로 지울 수 있다는 걱정은 타당하다는 것이 Garman의 시각입니다. 그래서 엄격한 guardrail(안전장치), 세밀한 권한 관리, eval(평가) 체계가 먼저 갖춰져야 합니다. AWS는 전문 엔지니어를 고객사에 보내 45일 동안 함께 평가 체계와 데이터 라벨링을 세우고, 이후에는 고객 팀이 스스로 운영하게 하는 방식을 씁니다. 5년씩 외부 컨설팅에 묶이는 구조를 피하려는 것입니다.
데이터 보호 측면에서는 Amazon Bedrock에서 고객의 입력과 prompt가 고객의 VPC를 벗어나지 않고 모델 제공사에도 전달되지 않는다고 강조합니다. Bedrock에서는 Anthropic의 Claude 모델과 오픈 웨이트 모델 사용이 빠르게 늘고 있고, OpenAI API에서 Bedrock으로 옮기는 사례도 많다고 합니다. 보안 쪽에서는 고급 모델로 취약점을 찾아 실제 환경의 맥락에서 우선순위를 매기는 Continuum을 내놓았습니다. 사람이 경보에 반응하는 속도로는 부족하고 방어도 기계의 속도로 돌아야 한다는 판단입니다.
Amazon 내부의 변화도 소개했습니다. 모든 직원이 Amazon Q를 쓰고, 인사 팀은 몇 주 걸리던 조직 계획을 몇 시간 만에 끝내며, 재무 팀은 agent로 세법과 지역 규정을 점검합니다. 소프트웨어 개발은 엔지니어가 agent 여러 개를 지휘하고 결과를 평가하는 방식으로 바뀌었고, 예전에 10명이 하던 일을 3~4명의 소규모 팀이 맡습니다.
정리: 한국 개발자와 스타트업이 할 일
AWS의 방향은 클라우드의 주 사용자가 사람에서 agent로 옮겨 간다는 판단 위에 서 있습니다. 지금 AWS로 서비스를 만든다면 다음을 점검해 볼 만합니다.
- coding agent에 배포를 맡긴다면 넓은 관리자 권한 대신 작업 단위의 최소 권한과 짧은 유효 기간을 주고, agent가 만든 코드는 sandbox에서 실행합니다.
- agent가 잠깐 쓰는 데이터 저장소에는 운영 데이터베이스 수준의 복제와 내구성을 붙이지 않습니다.
- 여러 단계를 이어 실행하는 agent라면 평균 응답 속도보다 p99, p99.9 같은 꼬리 지연을 기준으로 서비스를 고릅니다.
- GPU가 필요하면 지역과 하드웨어 구성을 넓게 열어 두는 편이 확보에 유리합니다.
- 비용을 줄이려면 Graviton으로 옮길 수 있는 업무부터 살펴봅니다.
- 기업에 agent를 도입한다면 기존 절차를 그대로 옮기기보다 목표부터 다시 정하고, 운영 전에 평가 체계와 guardrail을 먼저 세웁니다.