오픈에이아이 프런티어 모델과 코덱스가 이제 아마존웹서비스에서 제공됨

오픈에이아이 프런티어 모델과 코덱스가 아마존웹서비스에서 정식 제공되며, 수백만 아마존웹서비스 고객이 이미 비즈니스를 운영하는 플랫폼에서 오픈에이아이로 구축할 수 있음 기업은 기존 보안·컴플라이언스·조달·청구·거버넌스 워크플로를 통해 프런티어 인공지능를 프로덕션에 도입할 수 있어 평가에서 실제 배포까… 오픈에이아이.

발표의 핵심

오픈에이아이 프런티어 모델과 코덱스가 아마존웹서비스에서 정식 제공되며, 수백만 아마존웹서비스 고객이 이미 비즈니스를 운영하는 플랫폼에서 오픈에이아이로 구축할 수 있음 기업은 기존 보안·컴플라이언스·조달·청구·거버넌스 워크플로를 통해 프런티어 인공지능를 프로덕션에 도입할 수 있어 평가에서 실제 배포까… 오픈에이아이 프런티어 모델과 코덱스가 이제 아마존웹서비스에서 제공됨 (openai.com)1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개 오픈에이아이 프런티어 모델과 코덱스가 아마존웹서비스에서 정식 제공되며, 수백만 아마존웹서비스 고객이 이미 비즈니스를 운영하는 플랫폼에서 오픈에이아이로 구축할 수 있음 기업은 기존 보안·컴플라이언스·조달·청구·거버넌스 워크플로를 통해 프런티어 인공지능를 프로덕션에 도입할 수 있어 평가에서 실제 배포까지의 마찰이 줄어듦 오픈에이아이 models on 아마존 베드록은 아마존웹서비스 네이티브 보안 및 거버넌스 제어를 사용해 인공지능 애플리케이션을 구축하게 해줌 코덱스 on 아마존 베드록은 매주 500만 명 이상이 사용하는 오픈에이아이의 소프트웨어 엔지니어링 에이전트를 아마존웹서비스 환경으로 가져와 코드 작성, 리뷰, 디버깅, 현대화를 지원함 향후 데이브레이크를 아마존웹서비스 고객에게 제공해 보안 코드 리뷰, 위협 모델링, 패치 검증, 의존성 위험 분석, 탐지, 개선 안내를 일상 개발 루프에 넣는 방향으로 확장함 아마존웹서비스에서 오픈에이아이를 프로덕션에 도입 오픈에이아이 프런티어 모델과 코덱스가 아마존웹서비스에서 일반 제공됨 아마존웹서비스 고객은 기존에 비즈니스를 운영하는 아마존웹서비스 플랫폼을 통해 오픈에이아이 기능을 사용할 수 있음 기업의 주요 장벽인 보안, 컴플라이언스, 조달, 청구, 거버넌스 절차를 기존 워크플로 안에서 처리할 수 있음 조직은 운영 장벽을 줄이고 평가 단계에서 실제 배포로 더 빠르게 이동할 수 있음 제공 방식과 확장 계획 오픈에이아이 models on 아마존 베드록은 아마존웹서비스 네이티브 보안 및 거버넌스 제어를 사용해 인공지능 애플리케이션을 만들 수 있게 함 코덱스 on 아마존 베드록은 팀이 이미 빌드하고 배포하는 아마존웹서비스 환경에서 코드 작성, 리뷰, 디버깅, 현대화를 돕는 소프트웨어 엔지니어링 에이전트로 제공됨 두 제공 방식은 아마존웹서비스 커머셜 및 거브클라우드 리전에서 사용할 수 있음 오픈에이아이와 아마존웹서비스는 아마존웹서비스를 통해 제공되는 오픈에이아이 기능을 계속 확장해 팀이 더 적은 마찰과 더 높은 확신으로 평가에서 프로덕션으로 이동하도록 할 계획임 향후 제공될 데이브레이크는 사이버 모델과 코덱스 Security를 포함하며, 사이버 방어자가 위험을 더 일찍 보고 더 빨리 대응하며 소프트웨어를 더 탄력적으로 만들도록 설계됨 아마존 베드록에 오픈에이아이 모델 도입: 오픈에이아이와 아마존웹서비스 CEO 인터뷰 오픈에이아이, 클라우드 기반 코드 에이전트 코덱스 리서치 프리뷰 출시 오픈에이아이, 코덱스를 ChatGPT 모바일 앱에 통합 공개 RedHat, 쿠버네티스 보안 플랫폼 StackRox를 오픈소스로 공개 아마존웹서비스나 Azure, GCP 같은 곳을 왜 신뢰하느냐, 왜 프리미엄을 내느냐고 묻는 걸 볼 때마다, 엔터프라이즈 환경에서 일해본 적이 없구나 싶음 내가 일하는 대기업은 고객 계약에 엄격한 데이터 거버넌스가 들어가 있고, 자체 거버넌스 요구도 있음.

정보보안 승인을 받은 벤더일 뿐 아니라 고객 계약상 데이터 처리자로 명시된 벤더를 쓰는 게 해고와 소송을 피하는 길임 집에서 내 코드와 데이터로 놀 때는 뭐든 해도 되지만, 회사와 고객 데이터로는 절대 안 됨.

유행하는 최신 프런티어 모델을 아무거나 쓰지 않는 이유도 같음.

기업 도입 방식

사이드 프로젝트와 스타트업은 제약과 고려사항이 완전히 다름 실제 아마존웹서비스 계약과, 계약 및 마케팅 자료에 링크된 문서에서 명시한 제한적 책임을 확인해봤는지 궁금함 작은 글씨를 읽어보면 꽤 재미있음.

데이터 손실 책임은 대체로 고객에게 있고, SLA 청구에는 구체적 증거를 제시해야 하며, 받아들인 구제책은 보통 데이터를 잃은 바로 그 제품의 향후 사용 크레딧임 아마존웹서비스의 약관은 GCP 같은 곳과 비교하면 오히려 꽤 합리적인 편임.

GCP의 SLA는 엔터프라이즈 구매팀이 “SLA가 있으니 실사도 했고, 이걸 골라도 해고되진 않겠다”고 말하는 데 주로 유용해 보임.

개발 지원 범위

반면 GCP는 “계약서에 서명할 때 이미 제안된 구제책을 수락했으니 소송해도 그 조항을 보여주겠다.

신뢰해줘서 고맙다”고 할 수 있음.

[0] 표준 멀티 리전 또는 듀얼 리전 스토리지는 99.95% 가용성 SLA, 리전 표준은 99.9%, 리전 Nearline, Coldline, Archive는 99.0%까지 낮아질 수 있음.

향후 확장 계획

크레딧은 영향을 받은 서비스 계층의 월 청구액 기준 10%, 25%, 50%이고, 월 합산 상한은 50%이며 향후 사용에 적용됨.

Google은 고객이 30일 안에 크레딧을 요청하지 않으면 포기한 것으로 본다고도 함 여기에 더해, “저 팀이 비용 보고서에 인공지능로 1,000달러를 썼다니, 뭘 얻은 거지?”와 “회사 전체 아마존웹서비스 청구액이 몇 퍼센트 올랐네, 시간 될 때 살펴보자” 사이에는 엄청난 차이가 있음.

후자가 프로젝트를 훨씬 더 현실적으로 만들어줌 아마존웹서비스의 보안 태세는 다름.

원문: GeekNews 기사 보기