Amazon Bedrock에 OpenAI 모델 도입: OpenAI와 AWS CEO 인터뷰

• OpenAI의 frontier 모델이 Amazon Bedrock의 AWS 네이티브 에이전트 런타임에 들어오며, 단순 모델 제공을 넘어 기업용 managed agent 형태로 결합됨
• Bedrock Managed Agents는 identity, permissions, logging, governance, deployment를 함께 묶어, 고객이 직접 조립하던 요소 없이 기업 환경에서 더 빠르게 에이전트를 운영하게 만듦
• 현재 에이전트 성능은 모델 자체만이 아니라 tools, state, memory, permissions, evals를 포함한 harness 결합도에 크게 좌우되며, AWS와 OpenAI는 이 결합을 공동 제품으로 다루고 있음
• 고객 데이터는 AWS VPC 내부에 남고, OpenAI 모델은 Bedrock을 통해 실행되며, 지원 창구도 AWS 중심으로 운영됨
• 스타트업을 열었던 초기 클라우드처럼 이번 결합도 AI 도입 장벽을 낮추는 흐름 위에 있으며, 빠르게 커지는 frontier 수요와 함께 새로운 플랫폼 계층으로 자리 잡으려는 구도도 드러남

AWS와 스타트업, AI 도입 속도

• AWS 초기 클라우드 모델은 대규모 기업만 가질 수 있던 인프라를 몇 달러와 신용카드만으로 쓸 수 있게 하며, 개발자가 무엇을 만들지 미리 정하지 않는 방식으로 인터넷의 창작 범위를 크게 넓힘
• AI 도입 파급력도 그와 비슷하거나 더 크게 평가됨
  • 코딩을 10년 배워야만 애플리케이션을 만들 수 있는 구조가 약해짐
  • 수백 명 규모 팀과 긴 개발 기간 없이도 소규모 팀이 빠르게 만들고 반복 개선할 수 있게 됨
  • 세계 여러 영역에서 새로운 혁신을 여는 수단으로 작동함
• 클라우드 초창기와 달리 AI 채택 속도는 매우 빠르게 전개됨
  • 2006년 클라우드는 "서점 회사가 왜 컴퓨팅을 제공하느냐"를 길게 설명해야 했지만, AI는 사람들이 훨씬 빨리 이해함
  • 단순한 지능형 챗봇에서 기업 내부 업무 수행으로 넘어가는 과정은 교육이 필요했지만, 기술 변화 속도 기준으로는 비교적 빠르게 진행됨
• 스타트업 플랫폼 전환은 Internet, cloud, mobile, AI의 네 번으로 정리됨
  • YC 초창기에는 AWS 같은 클라우드 덕분에 적은 자본으로도 회사를 시작할 수 있게 바뀜
  • colo 공간을 빌리고 서버를 조립하며 큰돈을 먼저 모아야 했던 장벽이 크게 낮아짐
  • 서버 비용만으로도 수만 달러가 든다는 전제가 깨지며 소자본 창업 구조가 가능해짐
• 스타트업은 대형 플랫폼 전환기에 더 짧은 사이클과 더 적은 자본으로 움직일 수 있을 때 대기업을 이기기 쉬움
  • 현재 AI 위에서도 그 방향이 유사하게 보임
  • YC 내부에서는 배치 시작과 끝 사이에도 좋은 회사의 매출 기대치가 달라질 정도로 매출 성장 속도가 과거보다 훨씬 빠르게 움직임
• AWS는 지금도 많은 확장 단계 스타트업이 사용하는 클라우드로 제시됨
  • scale, availability, security, reliability와 AWS 안의 ISV 파트너 생태계, AWS 안의 고객 기반이 함께 강점으로 묶임
  • 크레딧뿐 아니라 시스템 설계 조언, go-to-market 조언도 제공하며 스타트업을 AWS의 핵심 기반으로 계속 다룸
  • 분기마다 직접 스타트업을 만나 제품이 실제로 맞는지 확인함
• 오늘날 스타트업에서는 일반 컴퓨트는 AWS, AI는 OpenAI API를 함께 쓰는 패턴이 매우 흔하게 나타남

Bedrock Managed Agents와 공동 제품 방향

• Bedrock Managed Agents는 OpenAI 모델이 AWS에 들어오는 수준이 아니라, OpenAI의 frontier 모델을 AWS 네이티브 에이전트 런타임 안에 넣는 형태로 제시됨
  • identity, permission state, logging, governance, deployment 같은 운영 요소가 함께 묶임
• 다음 단계의 AI는 텍스트를 넣고 텍스트를 받는 단계를 넘어, 회사 내부에서 실제 일을 하는 stateful agent로 이동 중임
  • "virtual co-workers"라는 표현은 완벽하지 않지만 가장 덜 어색한 표현으로 다뤄짐
  • 업계 전체가 이 대상을 어떻게 부를지, 어떻게 쓸지 완전히 정하지는 못한 상태임
• Codex는 이 흐름의 선명한 예시로 제시됨
  • 실제로 원하는 일이 일어나면 되는 것이 핵심이며, 사용자는 모델과 하네스 중 무엇이 더 기여했는지 구분하지 않게 됨
• 모델과 하네스의 결합도가 에이전트 성능의 핵심으로 다뤄짐
  • tools, state, memory, permissions, evals가 실제 작동을 좌우함
  • pre-training과 직접 같지는 않지만 post-training과 prompt 수준 모두에서 결합이 일어남
  • 초기에는 분리돼 보였던 tool-calling도 시간이 지나며 학습 과정에 더 깊게 통합됨
  • 앞으로는 model과 harness, 그리고 pre-training과 post-training도 더 강하게 결합될 가능성이 제시됨
• 산업 성숙도는 아직 Homebrew Computer Club 시절에 비유될 정도로 초기 단계로 묘사됨
• AWS와 OpenAI의 공동 작업은 고객이 직접 조립해야 했던 요소를 묶어, 기업 환경에서 더 빨리 가치에 도달하게 만드는 데 초점을 둠
  • 고객은 모델과 에이전트가 기억을 유지하며 함께 잘 작동하길 원함
  • 서드파티 툴뿐 아니라 자사 툴, 자사 데이터, 자사 애플리케이션, 자사 운영 환경까지 연결하길 원함
  • 이런 통합 작업은 지금까지 각 고객이 직접 맡아야 했던 영역이었음
  • 공동 제품에서는 identity가 내장되고, 데이터베이스 인증도 AWS VPC 안에서 이뤄지도록 설계됨
• 목표는 단순한 편의성 향상만이 아니라, 기존 방식으로는 고통스럽게 조립해도 신뢰성 있게 구현되지 않던 것까지 가능하게 만드는 데 있음
• 현재 개발자는 모델을 활용해 무언가를 만들 때 너무 많은 고통과 수작업을 겪는 상태로 묘사됨
  • ChatGPT 사용에서도 복사-붙여넣기와 복잡한 프롬프트 조합이 많음
  • 이런 마찰은 사라질 것이며, 지금은 여전히 매우 이르고 불편한 단계로 다뤄짐
• 이번 협력은 AWS에 이미 머무는 고객이 OpenAI technology를 원한다는 수요와, OpenAI가 AWS 고객 접근성을 넓히려는 방향이 맞물린 결과이기도 함
• 단순한 모델 유통을 넘어 새로운 제품을 함께 만드는 성격이 더 강하게 강조됨
  • 1년 뒤 돌아보면 "AWS로 OpenAI 모델에 접근 가능해졌다"보다 이 신제품의 중요성이 더 크게 남기를 바라는 구도임
  • 모델, harness, capability 차원에서 기존의 모델 API 호출과는 다른 새로운 컴퓨팅 방식에 가까워짐

AgentCore, Managed Agents, 운영 모델

• AgentCore는 메모리, 안전한 실행 환경, 권한 부여 같은 에이전트 프리미티브 집합으로 소개됨
• Bedrock Managed Agents는 AgentCore 구성 요소 위에 OpenAI 모델과 여러 운영 요소를 결합해 AWS와 OpenAI가 공동 구축한 상위 제품으로 놓임
• AgentCore만으로도 직접 agentic workflow를 만들 수 있음
  • 이미 production에서 이를 돌리며 실제 활용하는 고객도 있음
• 현재도 AgentCore를 쓰면서 OpenAI 모델을 외부 호출하는 방식은 가능함
  • Bedrock 안에 네이티브하게 붙는 형태는 아니지만, 다른 클라우드에 있는 OpenAI 모델을 직접 호출하는 고객이 있음
• AWS는 이를 열린 생태계로 다룸
  • 원하는 역량을 조합해 직접 구축하는 방식은 앞으로도 계속될 수 있음
  • 집에서 직접 컴퓨터를 만드는 사람처럼, 오래도록 직접 에이전트를 만들고 싶어 하는 빌더도 남을 것으로 봄
• 다수의 고객은 모든 조각을 직접 설정하지 않아도 되는 더 쉬운 방식을 원하며, 이번 협업 출시는 그 수요를 겨냥함
• Azure에서의 OpenAI 사용은 API 직접 접근 경험이고, Amazon에서의 이번 발표는 그와 구별되는 managed service로 정리됨
• 이 managed agent 서비스는 현재 Amazon과 독점적으로 진행됨
  • 단순히 Amazon API를 쓰는 수준이 아니라 두 회사가 함께 추진하는 joint effort로 다뤄짐
• 고객 데이터는 AWS 내부에 남음
  • 전체가 VPC 안에 머물며 Bedrock 환경 내부에서 보호됨
• OpenAI 모델은 Bedrock을 통해 실행되며, 인프라는 Trainium과 GPU를 혼합해 사용함
  • 일부는 시점 문제, 일부는 capabilities 문제로 정리됨
  • 시간이 갈수록 더 많은 비중이 Trainium으로 이동할 것이라는 방향이 제시됨
  • OpenAI도 자사 모델이 Trainium에서 실행되는 점에 큰 기대를 보임
• OpenAI 모델을 AWS 환경에서 운영할 때 1차 지원 창구는 AWS가 맡음
  • 고객은 AWS support와 AWS 계정 담당자를 통해 도움을 받게 됨
  • 구축 과정에서는 OpenAI 측 인력도 참여해 활용 방식을 함께 조율함
  • OpenAI 도움이 필요한 버그는 AWS가 OpenAI로 에스컬레이션함

로컬, 클라우드, 권한과 보안 경계

• Codex는 처음에는 클라우드에서 시작했지만, 실제로는 로컬 실행으로 돌아간 흐름이 제시됨
• 로컬이 쉬운 이유는 환경이 이미 거기 있기 때문임
  • 컴퓨터 설정, 데이터, 파일 접근이 이미 갖춰져 있어 추가 구성이 적음
  • 최종 상태는 아니어도 단기적으로는 사용 편의성이 더 중요하게 작용함
• 장기적으로는 에이전트가 클라우드에서 실행되고, 매우 무거운 작업이나 컴퓨터를 닫아야 하는 상황에서는 클라우드로 넘기는 형태가 유용한 방향으로 다뤄짐
• 로컬 클라이언트는 여전히 장점이 있음
  • iPhone 앱도 로컬 컴포넌트를 가지듯 connectivity, latency, local compute, 파일 및 애플리케이션 접근 측면의 이점이 있음
  • 다만 노트북 자체를 scale-out할 수는 없어 확장성 한계가 분명함
• 기업 환경에서는 로컬 방식이 더 어려워짐
  • 두 사람 사이의 공유만 돼도 난도가 올라감
  • permissions와 security boundary를 다루기 더 복잡해짐
  • 결국 로컬과 클라우드를 잇는 bridge가 필요해짐
• 에이전트는 배포할 환경과 같은 환경에서 개발하는 쪽이 자연스럽고, identity와 permission 설계는 아직 많이 미완성된 영역으로 남아 있음
  • 사람 계정을 에이전트가 그대로 써야 하는지
  • 에이전트가 별도 계정을 가져야 하는지
  • 여러 에이전트를 둘 때 어떻게 구분할지 같은 문제가 남아 있음
• "Ben의 에이전트가 Ben으로 로그인하되 실제 Ben이 아니라 에이전트라는 표시를 남기는" 식의 primitive조차 아직 없음
• 에이전트가 노동력에 편입되고 자율성과 작업 복잡도가 높아질수록, 회사 내부와 인터넷 전반의 접근제어와 권한 모델도 함께 진화해야 함
• 클라우드로 옮길수록 중앙 조직이 보안 통제를 더 강하게 가질 수 있음
  • 고객은 강력한 모델과 에이전트의 가능성을 좋아하면서도, 실수로 회사가 끝장나는 사건을 가장 걱정함
  • VPC 안에서 동작하게 하거나 특정 gateway를 거치게 하거나 환경 내 role처럼 권한을 부여하는 식으로 경계를 통제할 수 있음
  • AWS가 20년 동안 쌓아온 보안 구조 덕분에 스타트업뿐 아니라 글로벌 은행, 헬스케어 기관, 정부 기관도 사용할 수 있었다는 점이 이어짐
  • 위험 회피적인 조직일수록 sandbox 안의 가드레일이 오히려 도입을 넓혀줌

AI 스택과 기업용 아키텍처

• 기업 고객은 데이터와 에이전트를 연결하고, 토큰 지출 추적과 감독을 제공하는 관리 계층을 원함
• 대기업 고객은 agent runtime environment, 관리 계층, 직원용 workspace를 함께 묶은 형태를 일관되게 요구함
  • 직원용 workspace로는 Codex 같은 형태가 예시로 제시됨
  • 이런 패키지 수요는 꽤 일관되지만 실제 제공물은 아직 더 구축해야 함
• 조직 안에는 여러 데이터베이스와 SaaS 앱, 분산된 데이터를 가로지르는 middleware / middle layer가 필요하다는 데 동의함
  • 관련 맥락으로 OpenAI Frontier가 함께 연결됨
• 현재 구조에서는 사용자 상호작용을 담당하는 user agent layer와 회사 관리 계층이 모두 필요해 보임
  • 사용자 측에서는 여러 에이전트와 상호작용하고, 각각의 에이전트가 서로 대화하도록 빌드하는 형태가 쓰임
  • 회사 관리 계층에서는 AI가 파일 시스템 등을 탐색할 때 필요한 각종 control이 중요함
• 다만 모델이 충분히 똑똑해지면 이런 구조 전체를 재설계하게 될 가능성도 열려 있음
  • 지금의 이중 계층 구조는 현재 세계에 맞춘 형태임
  • 미래 아키텍처가 정확히 어떻게 될지는 아직 모름
  • 어느 시점에는 "이건 그냥 모델 안에 있어야 한다"는 판단으로 이어질 수 있음
  • 고객이 실제로 사용하고 구축하는 과정을 통해 무엇을 더 쉽게, 더 빠르게, 더 좋게 만들어야 하는지 배워가게 됨

수요, 용량, 모델 계층화

• OpenAI는 이 사업에 많은 컴퓨트 구매와 상당한 노력을 투입하고 있으며, 그에 맞는 매출도 기대함
• 지능 수요는 가격이 충분히 낮아지면 사실상 상한이 없는 수요에 가까운 성격으로 다뤄짐
• 현재는 가격보다 용량 부족이 더 큰 제약으로 보임
  • 가격과 무관하게 더 많은 capacity를 원하고 추가 비용도 내겠다는 고객이, 가격을 두고 다투는 고객보다 많음
  • 현재 수준의 지능 비용은 앞으로도 극적으로 낮아질 것이라는 확신이 제시됨
• 전체 시장 수요 중 상당 부분이 absolute frontier에 몰려 있다는 점이 예상보다 놀라운 신호로 다뤄짐
  • 이전 세대 모델로 충분할 것이라는 가정보다 최신 전면 모델을 계속 원한다는 흐름이 더 강하게 나타남
• 컴퓨트 비용이 수십 년간 크게 낮아졌는데도 판매량은 계속 늘어난 것처럼, AI도 비슷한 수요 확대 경로를 따를 가능성이 제시됨
• 지금은 유용한 작업을 하려면 많은 경우 frontier 모델이 필요해 모두가 그쪽을 원함
• 시간이 지나면 작고 저렴하고 빠른 모델과 초대형 모델이 함께 존재하는 혼합 구조가 형성될 것으로 예상됨
  • 일부 소형 모델은 시간이 지나며 현재 최신 OpenAI 모델도 아직 못 하는 작업까지 처리할 수 있게 될 수 있음
  • 초대형 모델은 암 치료 같은 더 큰 문제를 겨냥하게 될 수 있음
• 지금은 아직 초기 단계이며, 이런 수준의 수요와 성장이 함께 나타나는 점이 향후 가능성을 크게 키움

Trainium, 추상화, 내부 컴퓨트

• Trainium은 이름과 달리 앞으로 inference 측면의 존재감이 더 커질 수 있다는 질문에 대해, AWS는 training과 inference 모두에 유용하다고 답함
• 고객은 Trainium을 직접 다루기보다 managed service의 추상화를 통해 접하게 될 방향이 강조됨
  • GPU도 대부분의 고객이 직접 상대하지 않듯, OpenAI나 Claude를 사용할 때 실제로는 GPU, Trainium, TPU가 아니라 interface와 상호작용하게 됨
• 앞으로도 accelerator chip은 소수의 대형 모델과 서비스 뒤에서 작동할 가능성이 큼
  • 5개, 10개, 20개, 100개 수준일 수는 있어도 이를 직접 프로그래밍하는 사람이 수백만 명으로 늘어나진 않을 것으로 봄
  • 모델 학습은 돈도 많이 들고 운영 전문성도 높게 요구됨
  • OpenAI 팀은 대형 컴퓨트 클러스터에서 가치를 짜내는 역량이 뛰어나지만, 그런 팀을 갖춘 곳은 많지 않음
• OpenAI는 자신들을 처음엔 token factory처럼 생각한다고 말했다가, 곧 intelligence factory에 더 가깝다고 고쳐 말함
  • 고객이 원하는 것은 토큰 수가 아니라 최저 비용으로 최고의 지능 단위를 충분한 용량으로 받는 일임
• GPT-5.5는 토큰당 비용은 5.4보다 높지만, 같은 답을 얻는 데 필요한 토큰 수는 훨씬 적은 예시로 제시됨
  • 사용자는 답변에 몇 토큰이 들었는지보다 원하는 작업이 끝났는지를 더 신경 씀
• 더 큰 모델이 적은 토큰으로 돌든, 더 작은 모델이 많은 토큰으로 돌든, GPU든 Trainium이든 고객은 내부 구현보다 적은 비용으로 큰 효용을 원함
• Codex나 Amazon Bedrock용 Stateful Runtime Environment 안에서 새 에이전트를 만들 때도, 사용자는 내부 컴퓨트 선택을 의식할 필요가 없어야 함
• 토큰 사용량 감소는 주로 모델 개선의 결과이며, 하네스 영향은 일부만 반영됨
• AWS는 유사한 managed service를 다른 모델에도 확장할지에 대해, 현재는 OpenAI와의 협업에 집중하고 있다고만 답함

시장 전개와 플랫폼 전략

• ChatGPT는 Facebook 이후 등장한 첫 대규모 신규 소비자 제품으로 평가됨
• OpenAI는 ChatGPT뿐 아니라 API와 특히 Codex에서도 꽤 좋은 성과를 냈다고 밝힘
  • 과거에는 새로운 언어 인터페이스가 인터넷에서 정보를 찾는 방식을 바꿀 가능성에 더 초점을 두고 있었다는 회고도 나옴
  • Google은 여전히 breadth와 depth 면에서 phenomenal company로 평가됨
• AWS는 처음부터 partner 중심 전략을 택해 왔고, 파트너가 성공하면 AWS도 성공하는 구조를 지향해 왔음
  • 모든 것을 직접 소유해야 한다는 방식과 다르며 파이 키우기에 가까움
  • 고객이 자신에게 가장 적합한 것을 선택할 수 있어야 하며, 그것이 자사 제품이든 파트너 제품이든 상관없다는 입장임
• Bedrock도 이런 전략 위에서 광범위한 모델과 다양한 기능을 지원하도록 설계됨
  • 데이터베이스, 컴퓨트 플랫폼 등 다른 영역에서도 비슷한 접근을 유지해 왔음
• AWS는 인프라 계층에서는 S3처럼 자사 핵심 구성요소를 강하게 밀지만, 스택 상위로 갈수록 더 넓은 파트너 생태계를 받아들이는 쪽이 고객에게도 유리하다고 봄
• 양사의 역할은 OpenAI가 Software, AWS가 Infrastructure, 그리고 함께 Platform을 만드는 구도
• 향후 1년 동안 모델 능력이 가파르게 발전할 것으로 예상하는 만큼, 지금 함께 플랫폼을 구축하는 시점이 좋은 타이밍이라고 생각