# OpenAI 프런티어 모델과 Codex가 이제 AWS에서 제공됨 > Clean Markdown view of GeekNews topic #30119. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30119](https://news.hada.io/topic?id=30119) - GeekNews Markdown: [https://news.hada.io/topic/30119.md](https://news.hada.io/topic/30119.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-03T00:40:14+09:00 - Updated: 2026-06-03T00:40:14+09:00 - Original source: [openai.com](https://openai.com/index/openai-frontier-models-and-codex-are-now-available-on-aws/) - Points: 2 - Comments: 1 ## Topic Body - **OpenAI 프런티어 모델**과 Codex가 AWS에서 정식 제공되며, 수백만 AWS 고객이 이미 비즈니스를 운영하는 플랫폼에서 OpenAI로 구축할 수 있음 - 기업은 기존 **보안·컴플라이언스·조달·청구·거버넌스** 워크플로를 통해 프런티어 AI를 프로덕션에 도입할 수 있어 평가에서 실제 배포까지의 마찰이 줄어듦 - **OpenAI models on Amazon Bedrock**은 AWS 네이티브 보안 및 거버넌스 제어를 사용해 AI 애플리케이션을 구축하게 해줌 - **Codex on Amazon Bedrock**은 매주 500만 명 이상이 사용하는 OpenAI의 소프트웨어 엔지니어링 에이전트를 AWS 환경으로 가져와 코드 작성, 리뷰, 디버깅, 현대화를 지원함 - 향후 **Daybreak**를 AWS 고객에게 제공해 보안 코드 리뷰, 위협 모델링, 패치 검증, 의존성 위험 분석, 탐지, 개선 안내를 일상 개발 루프에 넣는 방향으로 확장함 --- ### AWS에서 OpenAI를 프로덕션에 도입 - OpenAI 프런티어 모델과 Codex가 AWS에서 일반 제공됨 - AWS 고객은 기존에 비즈니스를 운영하는 AWS 플랫폼을 통해 OpenAI 기능을 사용할 수 있음 - 기업의 주요 장벽인 보안, 컴플라이언스, 조달, 청구, 거버넌스 절차를 기존 워크플로 안에서 처리할 수 있음 - 조직은 운영 장벽을 줄이고 평가 단계에서 실제 배포로 더 빠르게 이동할 수 있음 ### 제공 방식과 확장 계획 - [OpenAI models on Amazon Bedrock](https://aws.amazon.com/bedrock/openai/)은 AWS 네이티브 보안 및 거버넌스 제어를 사용해 AI 애플리케이션을 만들 수 있게 함 - [Codex on Amazon Bedrock](https://developers.openai.com/codex/amazon-bedrock)은 팀이 이미 빌드하고 배포하는 AWS 환경에서 코드 작성, 리뷰, 디버깅, 현대화를 돕는 소프트웨어 엔지니어링 에이전트로 제공됨 - 두 제공 방식은 AWS Commercial 및 GovCloud 리전에서 사용할 수 있음 - OpenAI와 AWS는 AWS를 통해 제공되는 OpenAI 기능을 계속 확장해 팀이 더 적은 마찰과 더 높은 확신으로 평가에서 프로덕션으로 이동하도록 할 계획임 - 향후 제공될 Daybreak는 사이버 모델과 Codex Security를 포함하며, 사이버 방어자가 위험을 더 일찍 보고 더 빨리 대응하며 소프트웨어를 더 탄력적으로 만들도록 설계됨 ## Comments ### Comment 58841 - Author: neo - Created: 2026-06-03T00:40:15+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48363132) - AWS나 Azure, GCP 같은 곳을 왜 **신뢰**하느냐, 왜 프리미엄을 내느냐고 묻는 걸 볼 때마다, 엔터프라이즈 환경에서 일해본 적이 없구나 싶음 내가 일하는 대기업은 고객 계약에 엄격한 데이터 거버넌스가 들어가 있고, 자체 거버넌스 요구도 있음. 정보보안 승인을 받은 벤더일 뿐 아니라 고객 계약상 **데이터 처리자**로 명시된 벤더를 쓰는 게 해고와 소송을 피하는 길임 집에서 내 코드와 데이터로 놀 때는 뭐든 해도 되지만, 회사와 고객 데이터로는 절대 안 됨. 유행하는 최신 프런티어 모델을 아무거나 쓰지 않는 이유도 같음. 사이드 프로젝트와 스타트업은 제약과 고려사항이 완전히 다름 - 실제 **AWS 계약**과, 계약 및 마케팅 자료에 링크된 문서에서 명시한 제한적 책임을 확인해봤는지 궁금함 작은 글씨를 읽어보면 꽤 재미있음. 데이터 손실 책임은 대체로 고객에게 있고, SLA 청구에는 구체적 증거를 제시해야 하며, 받아들인 구제책은 보통 데이터를 잃은 바로 그 제품의 향후 사용 크레딧임 AWS의 약관은 GCP 같은 곳과 비교하면 오히려 꽤 합리적인 편임. GCP의 SLA는 엔터프라이즈 구매팀이 “SLA가 있으니 실사도 했고, 이걸 골라도 해고되진 않겠다”고 말하는 데 주로 유용해 보임. 반면 GCP는 “계약서에 서명할 때 이미 제안된 구제책을 수락했으니 소송해도 그 조항을 보여주겠다. 신뢰해줘서 고맙다”고 할 수 있음. [0] [0] [https://docs.cloud.google.com/storage/docs/storage-classes]() 표준 멀티 리전 또는 듀얼 리전 스토리지는 99.95% 가용성 SLA, 리전 표준은 99.9%, 리전 Nearline, Coldline, Archive는 99.0%까지 낮아질 수 있음. 크레딧은 영향을 받은 서비스 계층의 월 청구액 기준 10%, 25%, 50%이고, 월 합산 상한은 50%이며 향후 사용에 적용됨. Google은 고객이 30일 안에 크레딧을 요청하지 않으면 포기한 것으로 본다고도 함 - 여기에 더해, “저 팀이 비용 보고서에 AI로 **1,000달러**를 썼다니, 뭘 얻은 거지?”와 “회사 전체 AWS 청구액이 몇 퍼센트 올랐네, 시간 될 때 살펴보자” 사이에는 엄청난 차이가 있음. 후자가 프로젝트를 훨씬 더 현실적으로 만들어줌 - **AWS의 보안 태세**는 다름. AI 스타트업이나 스타트업 웹앱 빌더 도구, VSCode 플러그인 업체들은 해킹당하고 데이터가 유출될 가능성이 큼 AWS도 해킹될 수는 있지만, 그 가능성을 조금 낮추고 어떤 고객이 영향을 받았는지 추적하기 쉽게 만들기 위해 신경을 써왔음. 예를 들어 AWS 로깅을 파고들면, 켜두기만 했을 때 정말 많은 기록이 남아서 누가 권한이나 환경에 무엇을 했는지 되짚어볼 수 있음. AWS 직원의 접근도 꽤 잘 기록할 것 같음. 예전에 내 계정에 AWS 직원을 붙이려면 여러 절차를 거쳐야 했음 - 간단히 말하면, **IBM을 샀다고 해고된 사람은 없다**는 얘기임 - 아무 AI 하네스나 모델을 쓸 수 있던 자유로운 환경에서 엄격한 엔터프라이즈 환경으로 막 옮겼음 Azure에서 **GitHub Copilot 라이선스** 하나 쓰는 게 얼마나 어려운지 알고 충격받았음. 둘 다 Microsoft 제품인데도, IT가 GitHub Enterprise를 설정하고 Azure 구독과 연결하는 등 온갖 작업을 알아내야 했음 - 대기업 환경에서 AI 코딩 모델을 써봤다면, 많은 대기업 배포가 사실상 **AWS Bedrock** 사용을 요구한다는 걸 알 것임. 이유는 단순함 1. 대기업은 이미 AWS와 관계가 있는 경우가 많아, 새 벤더 관계를 만드는 것보다 절차가 훨씬 쉬움 2. 대기업은 내부 데이터가 회사 통제 아래 남아야 한다는 강한 내부 요구사항이 많음. AWS Bedrock을 쓰면 모델에 넣는 내용이 어딘가의 학습 데이터셋으로 흘러들어가지 않는다고 훨씬 더 확신할 수 있음. 내가 일하는 곳에서는 이 요구사항 때문에 OpenAI API를 직접 쓰지 않고 AWS Bedrock을 거치는 게 필수 조건임 - 한 단계 더 들어가면, 새 벤더를 추가하기가 자주 불가능한 이유는 고객과 맺은 여러 계약에서 고객 데이터를 **다른 벤더로 보내지 않겠다**고 다양한 형태로 약속했기 때문임 - 많은 LLM에서 Bedrock은 데이터가 어느 나라에 머무를지 제어할 수 있게 해줌. 예를 들어 **Claude API**에서는 그런 제어가 없음 우리는 미국에서 일하지 않고, 데이터가 우리나라 안에 머물러야 한다는 강한 요구사항이 있는데 Bedrock은 그 제어를 제공함 - 흥미로운 얘기임 이런 흐름이라면 AI가 앞으로 어떻게 계속 성장할지 궁금함. 가치 있는 데이터 대부분이 이런 방화벽 뒤에 있다고 가정하면, 공개 데이터는 이미 수확됐고 불법적으로 확보한 데이터 위에서 학습됐을 가능성도 있음. 이 부분은 회색지대임 결국 외부 입력 없는 **폐쇄형 생태계**가 되는 걸까? - Bedrock 데이터가 외부 제공업체로 옮겨지지 않는다고 어떻게 확신할 수 있는지 궁금함 - 왜 굳이 직접 쓰지 않고 AWS를 통해 이 API들에 더 많은 돈을 내느냐가 궁금하다면, 어떤 회사에서는 **새 벤더 승인**을 받는 게 거의 불가능하기 때문임. 회사에 AWS 계약이 있으면 AWS가 제공하는 걸 써야 함 - 잠깐, AWS가 어떤 AI 회사 서버 접근권을 재판매하는 건가, 아니면 AWS가 자체 하드웨어에서 모델을 돌리는 건가? - 승인을 받을 수 있더라도 연례 **보안 감사**의 범위가 넓어지고, 보안 평가에 공개해야 할 벤더가 하나 더 생기며, 데이터가 또 다른 처리자에게 퍼지고, 송장과 예산 논의도 하나 더 늘어남 고객 계약에 따라 새 벤더를 고객에게 알려야 할 수도 있고, 이게 새 보안 검토를 촉발할 수도 있음. 그런데 Bedrock에 모델 하나 더 추가하는 것뿐이라면? 훨씬 편함 - 전 세계 CEO, 이사회, 중간관리자들이 이제 AI 유행어에 사로잡혀 있음. 프런티어 연구소와 직접 계약하자고 요청해도 정말 막히지 않을 것 같은데? - OpenAI에는 엄청난 소식임. **AWS에서 쓸 수 있다는 이유만으로 Claude를 채택한 엔터프라이즈**가 상상 이상으로 많았고, 이제는 진지한 경쟁이 생김 - OpenAI에는 좋은 움직임이고 Anthropic은 걱정해야 할 일임. AWS 종속과 보안 요구사항 때문에 한동안 **Bedrock**이 내가 기반 모델을 쓸 수 있는 유일한 방법이었음 - Claude는 이미 AWS에서 Anthropic 서버로 통과시키는 방식과 Bedrock 양쪽으로 제공됨. [https://aws.amazon.com/claude-platform/]() 선점 효과가 사라진 걸 반기진 않겠지만, 오래전부터 예상했을 것 같음 - 경쟁에는 좋은 소식임 Claude Code는 Amazon Bedrock을 통해 쓰는 사람들에게 새 기능을 계속 빼고 있음. 예를 들면 **자동 모드**, Ultra 플랜, Claude for Chrome 같은 것들임. 경쟁이 좀 더 생기면 전략을 다시 생각하게 될지도 모름 - 이상한 게, Amazon Bedrock의 **Claude 모델**은 그 기능들을 모두 지원함 한동안 api.anthropic.com 에뮬레이터를 만들어서 요청을 “몰래” Amazon Bedrock으로 전달해왔음. 잘 동작하고, 이제 1차 제공 전용 기능도 바로 쓸 수 있음 - 이제 Bedrock에서도 자동 모드가 동작함 - Anthropic은 **IPO**를 빨리 해야 할 듯함. 엄청난 매출 급증은 사실상 Gemini 출시 실패와 OpenAI가 Azure에 묶여 손발이 묶인 결과였음 Anthropic 모델은 말 그대로 AWS에서 사용할 수 있는 유일하게 실용적인 서버리스 API, 즉 Bedrock 모델이었음. 최근 Qwen 3.5/3.6 계열은 출시조차 하지 않았음. 토큰 효율과 투자수익률 중심 흐름까지 겹치니, Anthropic이 3분기를 어떻게 마감할지 정말 보고 싶음 - 프런티어 연구소들은 하이퍼스케일러가 데이터 수집 없이 서빙만 하는 **동결된 모델 빌드**를 제공함. 민감한 데이터를 저장하면서도 프런티어 LLM을 쓰고 싶어 하는 대부분의 회사에는 이것이 전제조건임 - Azure에는 안 좋은 일임. 선택받은 존재였지만 수요를 따라가지 못했음 OpenAI가 Azure가 안정적이지 않다며 독점 계약에서 빠져나왔을 때, 다음 목적지가 **AWS**라는 걸 알았음