프런티어 모델(Frontier Models)이 클라우드 조달(Cloud Procurement)이 되어가는 과정

AWS 상의 OpenAI와 Codex에서 흥미로운 점은 단순히 클라우드 메뉴에 모델 이름이 하나 더 추가되었다는 것이 아닙니다.

그 부분은 유용합니다. 기업은 강력한 모델을 원합니다. 개발자는 Codex가 자신들의 인프라, 데이터, 배포 메커니즘에 더 가까이 있기를 원합니다.

진정으로 흥미로운 점은 프런티어 AI(Frontier AI)가 기업이 운영하는 다른 모든 것들을 이미 규정하고 있는 똑같이 지루한 메커니즘, 즉 조달(Procurement), IAM(Identity and Access Management), 빌링 약정(Billing commitments), 리전 정책(Region policy), 감사 로그(Audit logs), 지원 계약(Support contracts), 데이터 경계(Data boundaries), 그리고 보안 검토(Security review) 속으로 끌려 들어가고 있다는 사실입니다.

이것은 마치 서류 작업처럼 들립니다.

하지만 이것이 바로 엔터프라이즈 소프트웨어가 실질적으로 변하는 방식이기도 합니다.

모델 액세스는 쉬운 문제였다

한동안 AI 도입은 액세스(Access) 문제로 프레임화되었습니다.

모델을 호출할 수 있는가? 충분한 속도 제한(Rate limit)을 확보할 수 있는가? SDK를 우리 제품에 연결할 수 있는가? 코딩 어시스턴트가 유용할 만큼 저장소(Repo)를 충분히 볼 수 있는가?

이것들은 실제적인 질문들입니다. 하지만 이것이 이야기의 끝은 아닙니다. 다음 질문 세트는 기업 내부에서 소프트웨어를 운영해 본 사람이라면 훨씬 더 익숙한 것들입니다. 어떤 계정이 이 사용량을 소유하는가, 어떤 데이터가 경계를 넘을 수 있는가, 누가 에이전트(Agents)를 생성할 수 있는가, 어떤 리전에서 추론(Inference)을 실행하는가, 비용은 어떻게 할당되는가, 그리고 모델 출력과 관련된 사고가 발생했을 때 어떤 증거가 존재하는가 하는 점들입니다.

그 지점이 바로 데모(Demo)가 플랫폼(Platform)이 되는 단계입니다.

AWS 상의 OpenAI가 중요한 이유는 많은 기업이 이미 AWS 내에 그러한 플랫폼 역량(Platform muscle)을 갖추고 있기 때문입니다. 그들은 IAM, 빌링(Billing), 프라이빗 네트워킹(Private networking), 감사 추적(Audit trails), 조달 경로(Procurement paths), 컴플라이언스 증거(Compliance evidence), 비용 할당 태그(Cost allocation tags), 그리고 이 모든 것을 생존 가능하게 만드는 것이 업무인 팀들을 보유하고 있습니다.

프런티어 모델을 그러한 메커니즘 뒤에 배치한다고 해서 어려운 부분들이 사라지는 것은 아닙니다.

그것을 읽을 수 있게(Legible) 만들 뿐입니다.

Bedrock은 조달 접점이다

Amazon Bedrock은 보통 관리형 모델 서비스(Managed model service)로 설명되는데, 이는 맞는 말이기도 하지만 핵심을 과소평가하는 것이기도 합니다.

기업들에게 Bedrock은 조달 및 제어 접점(Procurement and control surface)입니다.

만약 OpenAI 모델과 Codex를 Bedrock을 통해 사용할 수 있다면, 기업은 실험을 원하는 모든 팀을 위해 매번 새로운 벤더 경로를 생성하는 대신 기존의 클라우드 관계를 통해 도입을 진행할 수 있습니다. 사용량은 기존의 AWS 약정(commitments)에 포함될 수 있습니다. 보안 팀은 익숙한 계정 구조를 바탕으로 판단할 수 있습니다. 플랫폼 팀은 서비스 액세스 권한을 설정하는 것과 동일한 위치에 모델 액세스 권한을 배치할 수 있습니다.

이것은 화려한 작업이 아닙니다. 하지만 어떤 도구가 열광적인 소수의 엔지니어를 넘어 확산될 수 있을지를 결정하는 바로 그런 종류의 일입니다.

저는 데이터베이스, 큐(queues), 관측성(observability) 도구, 그리고 보안 제품에서도 이러한 패턴을 본 적이 있습니다. 기술적으로 가장 뛰어난 옵션이 기업 내부에서 항상 승리하는 것은 아닙니다. 운영 모델(operating model)에 적합한 옵션이 종종 더 빠르게 채택됩니다.

AI도 이 법칙에서 예외는 아닙니다.

모델이 아무리 훌륭하더라도 벤더 온보딩(vendor onboarding), 법률 검토, 예산 승인, 리전 제한, 감사 증거(audit evidence) 부족, 그리고 소유권 문제로 인해 수개월을 허비할 수 있습니다.

클라우드 마켓플레이스(Cloud marketplaces)와 관리형 AI 플랫폼(managed AI platforms)은 단순한 유통 채널이 아닙니다. 이들은 모델 기업들의 속도와, 기업 거버넌스(enterprise governance)라는 더 느리고 생소한 현실 사이를 연결하는 어댑터(adapters)입니다.

거버넌스(governance)가 기능(feature)이 되고 있다

Microsoft는 Foundry를 통해 유사한 이야기를 하고 있습니다.

그들의 제안은 단순히 "에이전트를 구축하라"는 것이 아닙니다. 기업이 다른 운영 시스템(production systems)에 적용하는 것과 동일한 진지함으로 에이전트를 구축(build), 근거 설정(ground), 거버넌스(govern), 관측(observe), 그리고 운영(operate)하라는 것입니다. Microsoft Learn 가이드에는 AI 하이프(hype) 스레드에서는 거의 등장하지 않지만 아키텍처 리뷰(architecture reviews)에서는 자주 등장하는 단어들이 가득합니다: 소유권(ownership), ID(identity), 라이프사이클 관리(lifecycle management), 관측성(observability), 데이터 레지던시(data residency), 컴플라이언스(compliance), 레지스트리(registries), 프로토콜(protocols).

좋습니다.

상황은 항상 이 방향으로 흘러가고 있었습니다. 엔터프라이즈 에이전트(enterprise agent) 문제는 "LLM이 도구를 호출할 수 있는가?"가 아닙니다. 우리는 그것을 이미 증명했습니다.

엔터프라이즈 에이전트 문제는 "조직이 어떤 에이전트가 존재하는지, 그들이 무엇에 접근할 수 있는지, 누가 그들을 소유하는지, 비용은 얼마인지, 그리고 그들이 예상치 못한 행동을 했을 때 어떤 증거가 존재하는지를 알 수 있는가?"입니다.

그것은 컨트롤 플레인 (control-plane) 문제입니다.

컨트롤 플레인이 없다면, 에이전트(agents)는 그림자 인프라 (shadow infrastructure)가 됩니다. 누군가 유용한 자동화 도구를 만듭니다. 그것은 토큰 (token)을 얻습니다. 위키 (wiki)를 읽습니다. 티켓팅 시스템 (ticketing system)을 호출합니다. 그러면 다른 팀이 그것을 복제합니다. 그다음 누군가가 그것을 고객 데이터에 연결합니다. 그러다 매니저가 이것이 승인된 것인지 묻고, 모두가 서로를 쳐다봅니다.

이것이 내부 플랫폼 (internal platforms)이 탄생하는 방식입니다. 그 대안은 보이지 않는 프로덕션 동작 (production behavior)뿐입니다.

codex가 이를 더욱 날카롭게 만듭니다

AWS 상의 Codex는 특히 흥미로운데, 코딩 에이전트 (coding agents)가 위험한 요소들과 밀접하게 맞닿아 있기 때문입니다.

그들은 리포지토리 (repositories)를 읽고, 테스트를 실행하며, 풀 리퀘스트 (pull requests)를 생성합니다. 또한 인프라 코드 (infrastructure code), 마이그레이션 (migrations), CI 설정 (CI configuration), 의존성 (dependencies), 그리고 배포 스크립트 (deployment scripts)를 건드릴 수도 있습니다. 그들은 자연어 요청을 머지 (merge)하기에 충분히 공식적으로 보이는 브랜치 (branch)로 전환할 수 있습니다.

그렇기에 주변 플랫폼 (platform)이 중요해집니다.

만약 기업이 코딩 에이전트가 실제 엔지니어링 워크플로우 (engineering workflows) 내에서 작동하도록 허용하려 한다면, 단순히 "모델이 좋다"는 것 이상의 것이 필요합니다. 리포지토리, 자격 증명 (credentials), 네트워크, 도구 액세스 (tool access), 생성된 디프 (generated diffs), 리뷰 증거 (review evidence), 감사 추적 (audit trails), 그리고 비용에 관한 정책이 필요합니다.

에이전트가 어디에서 실행되었는가? 어떤 모델을 사용했는가? 어떤 파일을 읽었는가? 어떤 명령어를 실행했는가? 외부 서비스를 호출했는가? 세션이 이슈 (issue)와 연결되었는가? 풀 리퀘스트가 트랜스크립트 (transcript)를 보존했는가? 해당 리포지토리가 더 엄격한 샌드박스 (sandbox)를 요구할 만큼 민감했는가?

이것들은 AI에 반대하는 질문들이 아닙니다.

이것들은 프로덕션 (production)을 지지하는 질문들입니다.

Codex가 유용해질수록 이러한 질문들은 더욱 중요해집니다. 프로덕션에 인접한 리포지토리를 건드리는 코딩 에이전트는 소프트웨어 인도 시스템 (software delivery system)의 일부가 됩니다.

그리고 소프트웨어 인도 시스템에는 통제 장치 (controls)가 필요합니다.

클라우드 제공업체들은 친숙함을 판매하고 있습니다

이 이야기에는 클라우드 제공업체들이 단지 AI 지출을 점유하려 한다는 냉소적인 버전도 있습니다.

그것은 사실이지만, 그것만으로는 충분하지 않습니다.

그들은 익숙함(familiarity) 또한 판매하고 있습니다. AWS는 다음과 같이 말합니다: 이미 비즈니스를 운영하는 데 사용 중인 클라우드 플랫폼 내부에서 모델을 사용하십시오. Microsoft는 다음과 같이 말합니다: 거버넌스(governance), 보안(security), 컴플라이언스(compliance) 제어 기능과 함께 귀사의 비즈니스 데이터를 기반으로 에이전트(agent)를 구축하십시오. 두 메시지 모두 "이 벤치마크를 보십시오"라는 말보다는 덜 흥미롭지만, 대규모 고객들이 실제로 필요로 하는 것과는 더 일치합니다.

이것이 제가 AI 플랫폼 전쟁이 단지 모델 품질(model quality)에 관한 것만은 아니라고 생각하는 이유입니다.

모델 품질은 엄청나게 중요합니다. 하지만 기업들은 순수한 성능(raw capability)만을 단독으로 구매하는 경우는 드뭅니다. 그들은 계약, 권한, 인보이스(invoices), 대시보드(dashboards), 리전(regions), 지원(support), 그리고 장애 대응 절차(failure procedures)로 감싸진 성능을 구매합니다.

그 래퍼(wrapper)는 부수적인 것이 아닙니다.

그것은 제품의 일부입니다.

동일한 모델이라도 개인 API 키를 통해 접근하느냐, 공유된 회사 계정을 통해 접근하느냐, IAM(Identity and Access Management)과 비용 할당(cost allocation) 기능이 있는 클라우드 플랫폼을 통해 접근하느냐, 혹은 지역적 제어가 있는 규제 환경(regulated environment)을 통해 접근하느냐에 따라 매우 다르게 느껴집니다.

모델의 관점에서는 추론(inference)은 그저 추론일 뿐입니다.

하지만 회사의 관점에서는 이들이 완전히 다른 리스크 프로필(risk profiles)을 가집니다.

플랫폼 팀은 기다려서는 안 됩니다

이 문제를 클라우드 제공업체들이 완전히 해결해 줄 것이라고 생각하는 것은 실수입니다.

그들은 프리미티브(primitives)를 제공할 것입니다: 정책 훅(policy hooks), 로그(logs), 빌링 뷰(billing views), 모델 카탈로그(model catalogs), ID 통합(identity integration), 그리고 더 나은 설정 경로(setup paths) 등입니다. 그것은 도움이 됩니다.

하지만 까다로운 로컬 결정(local decisions)은 여전히 회사의 몫입니다.

어떤 에이전트 워크플로(agent workflows)가 어떤 리포지토리(repositories)에서 허용되는가? 고객 데이터를 위해 어떤 모델이 수용 가능한가? 어떤 작업에 인간의 검토(human review)가 필요한가? 에이전트가 어떤 도구(tools)를 호출할 수 있는가? 어떤 세션이 트랜스크립트(transcript) 보존을 필요로 하는가? 어떤 실험이 샌드박스(sandbox)에서는 괜찮고 운영 환경(production) 근처에서는 금지되는가?

이것들은 기술적 설정(technical configuration)으로 위장된 조직적 질문들입니다.

플랫폼 팀은 작게 시작해야 하지만, 반드시 시작해야 합니다.

모델 사용 현황(inventory)을 작성하세요. 개인적인 실험과 프로덕션 워크플로(production workflows)를 분리하세요. AI 비용을 서비스나 워크플로에 할당하세요. 몇 가지 리포지토리 위험 계층(risk tiers)을 정의하세요. 에이전트 세션이 검토자가 실제로 사용할 수 있는 증거를 생성하도록 만드세요. 개발자들에게 사용 가치가 있을 만큼 충분히 빠른 승인된 경로를 제공하세요.

보안 경로(secure path)는 사용 가능해야 합니다.

만약 보안 경로가 개인 키(personal key)와 셸 스크립트(shell script)를 사용하는 것보다 느리다면, 사람들은 결국 개인 키와 셸 스크립트를 찾아낼 것입니다.

핵심 요약 (the punchline)

AWS를 통해 프런티어 모델(Frontier models)이 도착하는 것은 표면적으로는 모델 액세스(model-access)에 관한 이야기입니다.

하지만 그 이면에는 거버넌스(governance)에 관한 이야기가 있습니다.

중심축이 "어떤 모델을 호출할 수 있는가?"에서 "어떤 플랫폼을 통해 이를 운영할 것인가?"로 이동하고 있습니다. 이는 조달(procurement), IAM(Identity and Access Management), 빌링(billing), 감사(audit), 데이터 경계(data boundaries), 리전(regions), 지원(support), 그리고 강력한 소프트웨어를 생존 가능하게 만드는 기타 지루한 통제 수단들을 의미합니다.

이것은 모델 경쟁의 끝이 아닙니다.

모델 경쟁을 둘러싼 운영(operations) 경쟁의 시작입니다.

AI 에이전트(AI agents)로부터 가치를 얻는 기업은 단순히 가장 모험적인 프로토타입을 가진 기업만이 아닐 것입니다. 그들은 에이전트 작업이 엔지니어링을 통해 이미 신뢰가 입증된 시스템, 즉 계정(accounts), 권한(permissions), 로그(logs), 검토(reviews), 예산(budgets), 그리고 소유권(ownership)에 부합하도록 만드는 기업들이 될 것입니다.

엔터프라이즈 AI의 미래는 새로운 앱이라기보다는, 더 나은 모델을 배후에 둔 클라우드 제어 평면(cloud control plane)에 더 가까운 모습일 수 있습니다.

참고 문헌 (references)

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 사용할 수 있는 20달러(USD)를 원하신다면, 이 링크를 사용하세요.