108번의 커밋으로 인프라를 구축했지만, Google I/O 2026에서는 한 번의 API 호출로 제공했다.

Source: Dev.to

Google I/O 6일 전, 나는 오픈소스 프로젝트에 마지막 커밋을 푸시했다. 이틀 뒤, Google은 그 프로젝트의 가장 어려운 부분을 제품화했다는 발표를 했다.
그게 이야기다. 불평이 아니라, I/O 2026이 실제로 소프트웨어를 어떻게 구축하는지에 대해 내가 공유할 수 있는 가장 유용한 내용이다.

NeuroScale는 개발자가 인프라를 이해하지 못해도 AI 모델을 프로덕션에 배포할 수 있게 해 주는 셀프‑서비스 플랫폼이다. 개발자는 양식을 채우고, 풀 리퀘스트가 자동으로 생성되며, 자동 검증이 수행되고, 스스로 배포가 이루어져서 동작하는 AI 엔드포인트가 살아난다.
개발자는 양식과 엔드포인트만 본다. 그 사이에 일어나는 13가지 작업은 보이지 않는다.
그 보이지 않는 13가지를 만드는 데 108개의 커밋이 사용됐다.

‘안전한 AI 배포’가 실제로 요구하는 것 — 그리고 각 요소가 존재하는 이유는 다음과 같다:

• 격리 레이어
  AI 모델이 실행될 때는 자체 격리된 환경에서 돌아가야 한다. 모델이 크래시가 나도 다른 서비스가 다운되지 않아야 하고, 데이터가 유출돼도 다른 팀의 워크로드에 닿지 않아야 한다. 이런 컨테이너를 만들고 관리하는 일은 결코 간단하지 않다.

• 정책 집행 레이어
  개발자에게 맡겨두면 메모리 제한 없이, 소유자 라벨 없이, 비용 할당 없이 AI 모델을 배포하게 된다. 공유 환경에서는 하나의 잘못 설정된 모델이 클러스터 전체 메모리를 고갈시킬 수 있다. 문제 발생 전에 실제로 배포를 차단하는 메커니즘이 필요하다 — 경고가 아니라 차단이다.

• 비용 할당 레이어
  “AI는 비싸다”는 정보는 쓸모가 없다. “Alpha 팀의 추천 모델은 이번 달에 $47, Beta 팀의 분류기는 $112가 들었다”는 정보는 의미가 있다. 라벨링, 메트릭 수집, 비용 분석을 연결해 주는 작업이 필요하다.

• 드리프트 보정 및 검증 레이어
  프로덕션 시스템은 수동으로 수정되곤 한다 — 누군가가 “잠깐” 설정을 직접 바꾸는 경우가 있다. 지속적인 감시가 없으면 인프라가 실제와 달라진다. 그리고 어떤 설정이 프로덕션에 배포되기 전에는 조직 정책에 맞는지 풀 리퀘스트 단계에서 검증돼야 한다 — 이는 프로덕션에서 문제를 잡는 것보다 지수적으로 비용이 적게 든다.

각 레이어마다 자체 사후 분석이 있었다.

• 격리 레이어?
  AI 모델이 전혀 배포되지 않는 이유를 디버깅하는 데 3시간을 썼다. 원인은 disableIstioVirtualHost: true 라는 단 하나의 설정 플래그였으며, 문서 어디에도 언급되지 않았다. 배포 도구의 소스 코드를 읽어 찾아냈다. 불리언 하나, 3시간.

• 정책 레이어?
  2주 동안 자동 검증 도구가 모든 풀 리퀘스트에 “모든 정책 통과”라는 초록 체크마크를 표시했다. 사실은 거짓이었다. 우리가 사용한 CLI 도구는 정책 위반이 있어도 성공 코드(0)를 반환했다. 우리는 종료 코드를 믿을 수 없었기에 도구의 텍스트 출력을 파싱하도록 검증 로직을 다시 작성해야 했다. 2주간의 허위 자신감.

이것들은 예외 상황이 아니다. 바로 플랫폼 엔지니어링이 실제로 어떻게 보이는가이다. 개발자가 절대 보지 못하는 모든 레이어는, 아직 존재하지 않았다는 이유로 새벽 2시에 호출을 받는 사람에 의해 만들어졌다.

Google I/O 2026에서 발표된 Managed Agents (Gemini API)

Google은 Managed Agents를 다음과 같이 소개했다:

“단일 API 호출로 원격 Linux 환경을 프로비저닝한다. 에이전트는 여기서 추론하고, 계획을 세우며, 도구를 호출한다; 격리된 샌드박스에서 코드를 실행하고 파일을 관리한다; 웹을 탐색해 실시간 데이터를 가져와 처리한다.”

내가 만든 것과의 즉각적인 유사점은 다음과 같다:

• 격리 레이어?
  각 에이전트 상호작용마다 자체 샌드박스 환경이 제공된다 — 문제는 비슷하지만 해결책은 훨씬 단순하다.

• 정책 레이어?
  Antigravity는 “크로스‑플랫폼 터미널 샌드박싱, 자격 증명 마스킹, 강화된 Git 정책”을 제공한다. 조직 차원의 정책 집행과는 정확히 동일하지 않지만 인프라 수준에서 같은 영역을 커버한다.

• 상태 지속성?
  환경이 호출 사이에 상태를 유지한다. 이는 GitOps 스타일의 드리프트 재조정과는 다르다 — Google은 여러분의 프로덕션 클러스터를 감시해 무단 변경을 되돌리지 않는다 — 하지만 에이전트가 상호작용 사이에 컨텍스트를 잃는 문제는 해결한다.

코드 예시

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="Deploy this model and run inference on the test dataset.",
    environment="remote",
)

print(interaction.output_text)

그게 전부다. 설정 파일도 없고, 13단계 파이프라인도 없으며, 불리언 플래그를 찾는 3시간 디버깅 세션도 없다.

내가 6개월 동안 만든 인프라 추상화는 — Google이 제시한 훨씬 간단한 경로와 동일한 개발자 결과를 제공한다.

나는 이것을 비판하려는 것이 아니다. NeuroScale 플랫폼은 실제로 동작한다. 하지만 Google의 발표는 내가 문제를 해결한 위치에 대해 중요한 통찰을 제공한다.

• 나는 인프라 레이어(Kubernetes, 컨테이너 오케스트레이션, 정책 엔진, GitOps 컨트롤러)에서 문제를 해결했다. 강력하고 유연하지만, 개발자가 이 모든 용어를 이해해야만 온보딩할 수 있다.
• Google은 인터페이스 레이어에서 문제를 해결했다. “하고 싶은 일을 문장으로 적어라. 우리는 그 아래를 모두 처리한다.”

능력 차이가 아니라 진입 장벽 차이다.

내 플랫폼은 개발자에게 양식 → 매니페스트 → 정책 엔진 → 배포 컨트롤러라는 흐름을 신뢰하도록 요구한다. 개발자는 볼 수 없는 세 층의 추상화를 신뢰해야 하며, 이를 유지하는 사람(나)을 믿어야 한다.

Google의 Managed Agents는 개발자에게 문장 하나만 쓰면 된다.

또한 Google이 에이전트를 정의한 방식에는 더 깊은 의미가 있다. 그들은 AGENTS.md와 SKILL.md라는 순수 마크다운 파일을 도입했다 — 에이전트가 무엇을 할 수 있고 어떻게 행동해야 하는지를 정의한다. 특별한 문법도, 독점 포맷도 없다. 단순히 파일일 뿐이다.

내 플랫폼의 대응물은 Backstage 플러그인에 커스텀 템플릿 스키마를 두고, 이를 Kubernetes 커스텀 리소스 정의와 연결하고, YAML로 구성된 정책 엔진으로 검증한다. 목표는 동일하지만 복잡도는 천차만별이다.

Google의 통찰은 인프라 행동은 그것을 정의하는 사람들에 의해 읽히고 이해될 수 있어야 한다는 점이다. 플랫폼을 구축하는 엔지니어만이 아니라, 정책을 정의하는 사람도 인프라를 읽을 수 있어야 한다.

---

조직 레이어는 여전히 인간 문제다

Managed Agents는 환경을 프로비저닝한다. 하지만 그 환경을 둘러싼 조직적 현실을 모델링하지는 않는다.

NeuroScale가 배포를 차단하는 이유는 기술적 제약 때문이 아니다. 조직이 모든 AI 워크로드는 오너 라벨과 비용 센터 라벨을 반드시 포함해야 실행된다고 정했기 때문이다. 이 정책은 재무 회의에서 나온 것이며, 기술 사양이 아니라 비즈니스 규칙으로 플랫폼에 인코딩된 것이다.

Google의 Managed Agents는 여러분의 재무 팀