# Amazon Bedrock에 OpenAI 모델 도입: OpenAI와 AWS CEO 인터뷰 > Clean Markdown view of GeekNews topic #29003. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29003](https://news.hada.io/topic?id=29003) - GeekNews Markdown: [https://news.hada.io/topic/29003.md](https://news.hada.io/topic/29003.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-04-29T10:44:47+09:00 - Updated: 2026-04-29T10:44:47+09:00 - Original source: [stratechery.com](https://stratechery.com/2026/an-interview-with-openai-ceo-sam-altman-and-aws-ceo-matt-garman-about-bedrock-managed-agents/) - Points: 1 - Comments: 1 ## Topic Body - **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](https://aws.amazon.com/bedrock/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](https://stratechery.com/2026/openais-memos-frontier-amazon-and-anthropic/)가 함께 연결됨 - 현재 구조에서는 사용자 상호작용을 담당하는 **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](https://openai.com/index/introducing-gpt-5-5/)는 **토큰당 비용은 5.4보다 높지만**, 같은 답을 얻는 데 필요한 토큰 수는 훨씬 적은 예시로 제시됨 - 사용자는 답변에 몇 토큰이 들었는지보다 원하는 작업이 끝났는지를 더 신경 씀 - 더 큰 모델이 적은 토큰으로 돌든, 더 작은 모델이 많은 토큰으로 돌든, GPU든 Trainium이든 고객은 내부 구현보다 **적은 비용으로 큰 효용**을 원함 - **Codex**나 Amazon Bedrock용 [Stateful Runtime Environment](https://openai.com/index/introducing-the-stateful-runtime-environment-for-agents-in-amazon-bedrock/) 안에서 새 에이전트를 만들 때도, 사용자는 내부 컴퓨트 선택을 의식할 필요가 없어야 함 - **토큰 사용량 감소**는 주로 모델 개선의 결과이며, 하네스 영향은 일부만 반영됨 - 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년 동안 모델 능력이 가파르게 발전할 것으로 예상하는 만큼, 지금 함께 플랫폼을 구축하는 시점이 **좋은 타이밍**이라고 생각 ## Comments ### Comment 56529 - Author: neo - Created: 2026-04-29T10:44:49+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47939320) - 내가 일하는 **프라이버시 민감 조직**들에서는 Claude가 훨씬 잘 받아들여졌음 "신뢰되는" 중간자 역할의 **Amazon**을 통해 접근할 수 있었기 때문임. OpenAI는 금지돼 있고 신뢰받지 못함 이 조직들의 법무팀 판단에 내가 꼭 동의하는 건 아니지만, 서비스 약관은 나보다 훨씬 꼼꼼히 읽었을 것 같음 이 발표가 판을 바꿀지는 두고 봐야겠지만, 지금 체감상 OpenAI는 여러 면에서 꽤 뒤처져 보임 다만 AI 업계에서 **2~8주 차이**는 엄청 큰 격차도 아니라서 실제 영향보다 인식의 문제일 수도 있음 적어도 내 정보 버블에서는 Sam Altman 때문에 OpenAI 평판이 바닥이고, 비윤리적으로 보이는 데다 fabs 관련 요구 같은 걸 보면 꽤 불안정해 보여서 별로 좋아하지 않음 - 주요 **LLM 제공사**들은 어디든 ZDR 계약을 맺을 수 있음 AWS만 쓴다고 충분한 것도 아니고, AWS가 모델을 돌리더라도 제대로 된 **ZDR**을 원하면 따로 그쪽과 협의해야 함 [0] [0]: [https://platform.claude.com/docs/en/build-with-claude/claude...]() - **Anthropic**이 최고의 모델과 흔들림 적은 리더십을 가진 건 맞지만, 엔터프라이즈 접근성을 크게 키운 건 역시 **AWS** 덕분이라고 봄 둘 다 확실히 이득을 봤고, AWS 고객들의 피드백 루프 문화가 Anthropic이 엔터프라이즈 대응을 더 빨리 갖추는 데 도움이 됐을 것 같음 - 법적 조건, **SLA**, 데이터 우려 측면에서 이게 **OpenAI on Azure**보다 정말 더 나은지 궁금함 Azure 쪽은 이미 한동안 있었음 - OpenAI는 **LLM 하나만** 파는 데 집중하지 않고 비디오와 이미지 생성도 같이 함 반면 Anthropic은 한 가지에 집중하고, 그래서 **SWE 벤치마크**에서 늘 최상위권에 드는 이유 같음 - 이건 AWS가 그냥 "신뢰되는 중간자"라서가 아니라, 모델이 고객 **자기 AWS 계정 안**에서 다른 계약 아래 실행된다는 점이 핵심임 AWS는 입력과 출력이 모델 제공자와 공유되지 않고, 기본 모델 학습에도 쓰이지 않는다고 명시함 [1] 게다가 OpenAI는 **NYT v. OpenAI**에서 2025년 5월 보존 명령을 받았고, 법원이 ChatGPT 출력 로그를 사실상 무기한 보관하라고 강제하고 있음 여기에는 원래 30일 내 삭제됐을 사용자 삭제 대화도 포함됨 [2] 그래서 **HIPAA/GDPR**에 묶인 조직에는 아예 출발선에도 못 서는 조건이 됨 [1] [https://aws.amazon.com/bedrock/faqs/]() [2] [https://openai.com/index/response-to-nyt-data-demands/]() - 대형 테크에서 일하면서 두 팀 사이에 작은 기능 하나 배포 조율하려고도 **끝없는 회의**를 하는 입장이라, 이런 모델을 Bedrock 하드웨어에 올리는 데 들어갔을 회의와 **6-pager** 양은 상상도 안 감 - 이 정도 레벨에선 그냥 결정하고 **SWAT 팀** 꾸려서 몇 주 안에 밀어붙이는 경우가 많음 정치질이나 관료적 리뷰는 대체로 아래 레벨 사람들을 기능 찌꺼기와 운영 일로 바쁘게 묶어두는 쪽에 더 가깝다고 봄 - 구현 방식에 따라 다르겠지만, Amazon은 이미 **gpt-oss-20b**를 넣었음 모델이 GPT의 OSS 변형과 충분히 비슷하다면 생각보다 그렇게 복잡하진 않았을 수도 있음 - 서로 다른 **추론 플랫폼**에서 돌리는 같은 모델이 꼭 똑같은 결과를 내는 건 아님 **양자화**, 커스텀 서빙 실리콘, 배칭, 기타 추론 최적화 때문에 원 제공자 버전과 호스팅 버전의 동작이 달라질 수 있음 이 논문은 정확히 같은 상황은 아니고 감사 가능한 오픈 웨이트 Llama를 다루지만, 비슷한 증상을 잘 보여줌 [https://arxiv.org/pdf/2410.20247]() - **OpenAI**와 **Microsoft**를 통해 gpt-x를 둘 다 써본 사람은 이 차이를 아주 선명하게 느꼈을 것임 - 우리 조직에서도 **Bedrock 제공**이 Anthropic 사용을 밀어준 핵심 요인이었음 거기서 실제 마진도 꽤 남길 수 있을 것 같음 이게 Microsoft와의 결별 흐름과 직접 연결돼 있는지도 궁금함 내 주변 사례만 봐도 진지한 엔터프라이즈 배포에서는 OpenAI가 거의 무시되고 있는데, Azure에서 제공하는 게 별로고 그 외에 기업 친화적인 경로도 없기 때문임 Anthropic과 AWS 조합에 엔터프라이즈 시장을 계속 내주면 치명적이라는 걸 깨닫고, OpenAI가 따라붙기 위해 움직인 것처럼 보임 - OpenAI가 이걸 준비하면서 **계약 재협상**을 했다는 건 꽤 분명해 보임 [https://news.ycombinator.com/item?id=47921248]() - 순수하게 궁금한데, **Azure** 쪽은 뭐가 문제임 - 여기서 흥미로운 건 **엔터프라이즈 세일즈** 동선임 금융·헬스케어 같은 규제 산업은 이미 AWS와 **데이터 거주성** 약정이 들어간 계약을 맺어둔 경우가 많음 Bedrock 위의 OpenAI는 이런 조직이 OpenAI와 별도로 DPA 협상을 하지 않아도 되게 해주므로, 서류상으로 보이는 것보다 훨씬 큰 돌파구일 수 있음 - 이건 **컴플라이언스** 측면에서 꽤 반가운 변화임 서브프로세서가 하나 줄고, 데이터도 이미 AWS 안에 있으니 다른 곳으로 보낸다는 걱정을 덜 수 있음 - OpenAI가 보기에 **Anthropic 뒤를 바짝 쫓는** 모양새임 - 이제 AWS를 통해 OpenAI를 살 수 있게 됐는데, 내 도구들과 **완전히 호환 안 되는 인터페이스**를 또 써야 한다는 뜻이기도 함 AWS가 드디어 포기하고 Bedrock을 좀 쓸 만하게 만들려고 **OpenAI API 호환성**을 넣은 게 아니라면 말임 - 나는 **Bedrock Mantle** PM인데, 이제 bedrock-mantle 엔드포인트가 **OpenAI API 호환**을 지원함 Responses와 Chat Completions를 지원하니 여기 참고하면 됨 [https://docs.aws.amazon.com/bedrock/latest/userguide/endpoin...]() - 생각보다 빨리 나왔음 - 실제 준비는 오래 걸렸겠지만, 대중이 보는 **PR 흐름**은 정교하게 잘 굴러가는 기계 같음 이번 HN 글만 해도 발표 링크가 동시에 4개나 뜬 건 우연이 아님 잘못된 말이 잘못된 타이밍에 나오면 수십억 달러의 투자금이 흔들리니, 메시지는 매우 신중하게 다듬고 단계적으로 내보낼 수밖에 없음 - OpenAI는 결국 **dumb pipe** 방향으로 가는 듯함