구글은 서울에서 모델이 아니라 에이전트를 판다

며칠 전에 브라우저 탭 세 개를 나란히 열어두고 있었습니다.

하나는 구글이 서울에서 연다는 AI Agents Live + Labs 등록 페이지였고, 하나는 앤트로픽이 6월에 최신 모델 접근을 정부 지침 때문에 막았다가 다시 연 공지였고, 나머지 하나는 오픈AI가 새 모델 라인업 일부를 미국 정부 요청으로 제한했다는 6월 말 기사였습니다. 원래는 서울 행사만 보려던 거였는데, 탭을 닫으려다가 세 화면이 한눈에 들어왔습니다. 뭔가 좀 어긋나 있다는 느낌이 들었습니다.

따로 보면 셋은 상관없는 뉴스입니다. 하나는 아시아 개발자 행사 초대장이고, 둘은 프런티어 랩의 접근 제어 사건입니다. 그런데 시기가 겹칩니다. 프런티어 모델 두 개가 6월 한 달 사이에 나란히 정부발 제한을 맞는 동안, 구글은 모델 자랑 대신 그 위에 얹는 것들, 그러니까 에이전트와 오케스트레이션과 프로덕션을 들고 서울로 오고 있었습니다.

저는 그 행사에 가본 것도 아니고 이 모델들을 직접 써본 것도 아닙니다. 세 조각을 나란히 놓고 본 게 전부입니다. 그런데 그렇게 놓고 보니 구글이 계속 말해온 멀티모델 유연성이라는 말이 갑자기 다르게 들렸습니다.

6월에 있었던 일

구글 얘기를 하려면 6월 얘기를 먼저 해야 할 것 같습니다.

6월 12일에 앤트로픽이 막 공개한 Fable 5와 Mythos 5의 접근을 그날로 끊었습니다. 회사가 알아서 조심한 게 아니었습니다. 앤트로픽 공지를 보면 미국 정부가 국가안보 권한을 근거로 모든 접근을 중단하라는 수출통제 지침을 내렸고, 지침이 도착한 그 오후에 모델이 바로 내려갔습니다.

막힌 대상이 좀 특이했습니다. 미국 안이든 밖이든 상관없이 외국 국적자 전부였습니다. 앤트로픽에서 일하는 외국 국적 직원도 포함해서요. 국경이 아니라 여권으로 선을 그은 겁니다. 한국에서 이 모델을 업무에 붙여 쓰던 팀이라면, 자기가 뭘 잘못한 것도 없는데 어느 날 오후에 갑자기 못 쓰게 된 겁니다.

제가 그 팀에 있었다면 처음엔 장애인 줄 알았을 것 같습니다. API 키가 만료됐나, 네트워크가 끊겼나, 우리 쪽 설정이 꼬였나부터 봤을 거고, 한참 뒤에야 공지를 보고 이건 우리가 고칠 수 있는 문제가 아니라는 걸 알았을 겁니다. 장애는 기다리면 복구되기라도 하는데, 이건 언제 풀릴지 누구도 말해줄 수 없는 종류의 멈춤입니다. 그게 제일 답답했을 것 같습니다.

그다음엔 설명하는 게 일이었을 것 같습니다. 서비스를 쓰는 고객이나 위에 있는 사람한테 왜 멈췄는지를 말해야 하는데, 우리 잘못도 아니고 모델 회사 잘못도 아니고 미국 정부 지침 때문이라는 설명은 듣는 쪽에서 쉽게 받아들여지지 않았을 겁니다. 언제 다시 되느냐는 질문에도 답할 수가 없고요. 우리가 할 수 있는 게 없다는 말을 하는 쪽도 듣는 쪽도 편하지 않았을 겁니다. 장애라면 복구 예상 시간이라도 말할 수 있는데 이건 그것도 없습니다. 기술 문제는 기술로 풀면 되지만, 이런 건 풀 방법이 손 밖에 있다는 걸 남한테 설명하는 게 더 힘들었을 것 같습니다.

무엇 때문에 이렇게 됐는지를 보면 좀 허무합니다. 문제가 된 건 좁은 범위의 탈옥 가능성이었는데, 내용은 모델한테 어떤 코드베이스를 읽게 하고 소프트웨어 결함을 찾아서 고치게 하는 거였습니다. 개발자라면 매일 하는 일입니다. 그런데 같은 능력이 방향만 바꾸면 취약점을 찾아내는 도구가 됩니다. 보도로는 이 우회 방법을 시연한 게 아마존 연구진이었고, 그게 국가안보 우려로 번졌다고 합니다.

통제는 2주 조금 넘어서 풀렸습니다. 6월 30일에 상무부가 제한을 풀었고 7월 1일부터 다시 전 세계에서 쓸 수 있게 됐습니다. 다시 열린 모델에는 그 방법을 거의 다 걸러내는 안전 분류기가 붙었고, 걸린 요청은 이전 세대인 Opus 4.8로 돌려 보낸다고 합니다. 랩이 알아서 몸을 사린 게 아니라 정부가 명령한 거였다는 게 저한테는 제일 크게 남았습니다.

비슷한 때에 오픈AI도 비슷한 일을 겪었습니다. 6월 26일에 내놓은 GPT-5.6 라인업, 제일 센 Sol과 균형형 Terra와 싸고 빠른 Luna도 일부 접근이 미국 정부 요청으로 제한됐습니다. 프런티어 랩 두 곳이 한 달 안에 나란히 자기 최신 모델을 정부 손에 맡긴 셈입니다.

앤트로픽과 오픈AI는 안전에 대한 평판이 거의 반대인 회사들입니다. 한쪽은 신중하기로, 다른 쪽은 공격적으로 내놓기로 알려져 있습니다. 그런 두 회사가 같은 달에 같은 벽에 부딪혔습니다. 그래서 저는 이게 어느 랩이 조심했느냐의 문제가 아니라고 생각하게 됐습니다. 회사가 아니라 프런티어 모델이라는 층 자체가 이제 정부가 스위치를 쥐는 층이 된 것 같습니다. 하룻밤 사이에 못 쓰게 될 수 있는 층이요.

같은 달에 구글은 플랫폼을 깔고 있었습니다

구글이 모델 경쟁에서 빠진 건 아닙니다. Gemini 3는 에이전트와 바이브코딩 쪽에서 최고 수준이라고 내세우고, 여러 코딩 벤치에서 높은 점수를 냈습니다. I/O 2026에서는 Gemini 3.5와 Omni, 에이전트 개발 플랫폼 Antigravity, 시스템 수준 에이전트까지 한꺼번에 내놨습니다. 벤치 슬라이드만 보면 다른 프런티어 랩과 다를 게 없어 보입니다.

그런데 구글이 정말 힘을 준 데는 다른 쪽 같습니다.

4월 Cloud Next에서 구글은 Vertex AI를 Gemini Enterprise Agent Platform으로 이름을 바꾸고 하나로 합쳤습니다. 앞으로 Vertex AI의 모든 서비스와 로드맵은 따로 나오지 않고 이 Agent Platform을 통해서만 나온다고 했고, 따로 있던 Agentspace도 이 안으로 들어왔습니다. 하는 말이 꽤 노골적입니다. 이제 파는 건 모델을 부르는 API가 아니라 에이전트를 돌리는 공장이라는 거니까요.

규모도 꽤 됩니다. 에이전트끼리 통신하는 A2A 프로토콜은 처음엔 파트너 몇십 곳으로 시작했는데 지금은 백 곳 넘는 조직이 파일럿이 아니라 실제 업무에서 쓰고 있고, 관리도 리눅스 재단 쪽으로 넘어갔습니다. Merck는 Gemini Enterprise 에이전트를 회사 전체에 까는 큰 다년 계약을 맺었습니다. 이 플랫폼에서 처리되는 토큰 양도 구글이 따로 자랑할 만큼 많습니다.

저는 이걸 보고 구글이 판돈을 한 칸 위로 올렸다고 느꼈습니다. 프런티어 랩들이 우리 모델이 벤치에서 몇 점이라고 다투는 동안, 구글은 여러 모델을 엮고 조직 전체에 배포하고 거버넌스를 거는 프로덕션 층에 걸었습니다. 모델은 부품이고 부품을 조립해서 돌리는 라인이 상품이라는 생각 같습니다.

구글이 이렇게 가는 게 저는 좀 구글다운 선택이라고 느꼈습니다. 검색도 그랬고 클라우드도 그랬듯이, 남이 만든 것까지 자기 위에 올려놓고 그 판을 쥐는 쪽이 구글이 늘 잘하던 방식이니까요. 제일 좋은 모델을 만드는 회사가 되는 것보다 어떤 모델이 제일 좋든 그게 자기 위에서 돌게 만드는 회사가 되는 게 더 오래간다고 보는 것 같습니다.

그런데 진열대에 올라가는 모델 회사 쪽에서 보면 이게 마냥 좋은 일인지는 잘 모르겠습니다. 구글 위에서 Claude를 쓰는 고객은 Claude를 쓰는 걸까요, 구글을 쓰는 걸까요. 고객이 매달 보는 청구서와 콘솔은 구글 것이고, 모델은 그 안에서 고르는 메뉴 하나입니다. 모델 회사로서는 고객을 더 많이 만나는 길이기도 하지만, 고객 바로 앞에 서는 건 구글이 하게 됩니다. 언젠가 고객이 오늘은 이 모델이 낫네, 하고 설정 하나로 바꿔버릴 수 있는 구조라면 모델 회사는 늘 다음 모델로 교체될 수 있는 부품으로 남는 셈입니다. 진열대에 같이 놓인다는 건 옆 상품과 늘 비교된다는 뜻이기도 하니까요. 구글이 바라는 게 바로 그런 구조일 거라는 생각이 들었습니다.

모델 발표와 플랫폼 발표는 듣는 사람도 다릅니다. 모델 발표는 벤치 슬라이드를 들고 연구자와 얼리어답터한테 말합니다. 플랫폼 발표는 도입 사례와 계약 규모를 들고 조직에서 결정하는 사람한테 말합니다. 이미 다들 쓰고 있다는 말투입니다. 같은 회사가 벤치도 자랑하고 계약도 자랑하지만, 어떤 숫자를 더 앞에 내세우느냐를 보면 지금 어디에 무게를 싣고 있는지가 보이는 것 같습니다.

Model Garden을 보면 이게 더 잘 보입니다. 모델이 수백 개 모여 있는데, Gemini나 Gemma 같은 자기 모델만 있는 게 아니라 앤트로픽의 Claude Opus, Sonnet, Haiku 같은 다른 회사 모델도 똑같이 내놓고 팝니다. 경쟁사 모델을 자기 진열대에 올려놓고 파는 겁니다. 처음엔 그냥 넉넉한 벤더 정책처럼 보였습니다. 고르고 싶은 거 고르세요 하는 식으로요. 이 얘기는 뒤에서 다시 꺼낼 텐데, 6월을 옆에 놓고 보면 좀 다르게 보입니다.

서울에 오는 것

구글이 낸 AI 에이전트 트렌드 2026 리포트를 보면 이 이야기를 회사가 얼마나 밀고 있는지 감이 옵니다. 그리고 그 이야기를 이 지역 개발자와 기업들 앞에 실제로 내려놓는 행사가 곧 서울에서 열립니다.

등록 페이지의 아젠다를 열어보면, 프로덕션 층으로 무게를 옮겼다는 게 세션 제목마다 그대로 적혀 있습니다. 키노트 밑으로 Scaling AI Agents, Agentic Enterprise, Agentic Data Cloud, Cloud with Google DeepMind, Agentic Work, Gemini User Talk까지 트랙이 여섯 개인데, 어디에도 우리 모델이 몇 점이라는 제목은 없습니다. Data Cloud에도 Work에도 Enterprise에도 Agentic이 앞에 붙어 있습니다. 전부 에이전트를 어디에 어떻게 얹을지에 대한 말입니다.

키노트를 따라가 보면 Google Cloud Korea 지사장 오프닝과 Google Research의 Neuro Context 데모로 시작하고, 그다음에 힘이 실린 세션 두 개가 이어집니다.

하나는 Agentic Era: from vision to value입니다. 제목이 다 말해주는 것 같습니다. 세션 설명을 보면 Gemini 3.5, Live, Omni 같은 모델 소개는 앞부분에 잠깐 있고, 진짜 데모는 그다음입니다. 노코드 workflow 에이전트에서 시작해서 하이코드 Agent Platform 아키텍처까지 이어서 보여주면서, 비개발자가 직관적으로 만드는 것부터 기업용 멀티 에이전트의 기획, 배포, 거버넌스, 운영까지를 한 줄로 엮습니다. 모델은 부품이고 조립 라인이 상품이라는 생각을 무대 위에서 데모로 보여주는 셈입니다.

다른 하나가 저는 더 눈에 걸렸습니다. Securing the AI Era with AI Threat Defence라는 세션인데, 발표는 구글 클라우드에 들어간 보안 회사 Wiz가 합니다. 소개하는 Google AI Threat Defense는 Gemini의 추론에 Wiz의 위험 분석, CodeMender의 자동 코드 수정, Mandiant의 위협 인텔리전스를 하나로 묶은 겁니다. 세션 설명에는 공격자가 악용하기 전에 위험 경로를 미리 예측하고 막는다고 적혀 있습니다.

여기서 6월 생각이 났습니다. 코드를 읽고 취약점을 찾아내는 능력, Fable 5를 정부 손에 내려가게 만든 바로 그 능력을 구글은 서울 무대에서 방어 제품으로 세워서 보여줍니다. 한쪽에서는 그 능력이 수출통제 대상이 돼서 못 쓰게 되고, 다른 쪽에서는 세일즈 덱의 하이라이트가 됩니다. 능력은 하나인데 위협으로 보느냐 제품으로 보느냐에 따라 대접이 정반대입니다. 6월을 겪고 나서 보니 이게 그냥 우연처럼 보이지 않았습니다. 같은 코드 읽기 능력을 두고 한 나라 정부는 위험하다고 막고, 같은 시기에 한 회사는 그걸로 위험을 막아주겠다고 파는 겁니다. 어느 쪽이 맞다기보다는, 이 능력이 이제 그만큼 무거워졌다는 얘기로 들렸습니다. 가볍게 쓰던 기능이 어느새 양쪽에서 동시에 무게를 다는 물건이 된 것 같습니다. 개발자 입장에서는 매일 시키던 일이 갑자기 그렇게 무거운 일이었다는 걸 뒤늦게 알게 된 셈입니다.

멀티모델 유연성이라는 말

제가 제일 하고 싶었던 얘기는 이쪽입니다.

구글이 여러 모델 중에 골라 쓰라고 할 때, 저는 그동안 그걸 벤더 마케팅으로만 들었습니다. 락인 싫어하는 기업 고객을 달래는 문구, 어차피 다들 하는 말. AWS도 Bedrock에서 여러 모델을 내놓고 다른 클라우드도 마찬가지니까요.

그런데 6월 일을 옆에 두니 같은 말이 다르게 들렸습니다. 내 프로덕션 에이전트 밑에 깔린 모델이 하룻밤 사이에 정부 때문에 내려가면 어떻게 되는가. 6월 12일에 실제로 있었던 일입니다. Fable 5에 기대던 워크플로가 있었다면 그날 오후에 그냥 멈췄을 겁니다. 외국 국적 직원이 쓰던 라인이라면 통제가 풀릴 때까지 2주 넘게 멈춰 있었을 거고요. 대안이 없는 조직은 손 놓고 기다렸을 거고, 밑에 다른 모델을 끼울 수 있게 만들어 둔 조직은 라우팅만 바꿔서 계속 돌렸을 겁니다.

밑에 다른 모델을 끼울 수 있는 구조, 그게 구글이 파는 거라고 생각합니다. A2A로 에이전트를 느슨하게 잇고, Model Garden에서 모델을 부품처럼 바꾸고, 오케스트레이션 쪽에서 라우팅을 다시 겁니다. 벤더 유연성이라는 상품이 6월을 겪고 나니 지정학적인 가용성 위험에 대한 헤지로 보이기 시작했습니다.

서울 트랙에 있는 ADK 워크숍에서 에이전트를 하나 만든다고 생각해 봤습니다. 데이터 소스를 붙이고, 도구 몇 개를 잇고, Model Garden에서 밑에 깔 모델을 하나 고릅니다. 여기까지는 어느 클라우드에서 해도 비슷할 것 같습니다. 차이는 그다음에 납니다. 고른 모델이 6월의 Fable 5처럼 내려갔을 때, 에이전트 정의는 그대로 두고 라우팅만 다른 모델로 바꿀 수 있느냐는 겁니다. A2A로 느슨하게 이어진 구조라면 설정 값 하나 바꾸는 정도일 거고, 특정 모델 SDK에 하드코딩된 구조라면 코드를 다시 써야 할 겁니다. 6월 전에는 이게 편하냐 불편하냐의 문제였는데, 6월 이후에는 멈추느냐 안 멈추느냐의 문제가 된 것 같습니다.

그 에이전트 정의가 실제로 뭘로 되어 있는지는 나중에 제 레포를 열어놓고 따로 뜯어봤습니다. 트리거, 토폴로지, verifier, stop rule 네 가지로 나눠 보니 모델을 바꿔 끼워도 남는 건 전부 그 네 가지에 적힌 배선 쪽이었습니다. 밑을 바꿀 수 있느냐는 결국 이 배선이 특정 모델 SDK에 얼마나 붙어 있느냐에 달린 것 같습니다.

그리고 아까 미뤄둔 얘기입니다. Model Garden은 Claude도 팝니다. 그러니까 6월에 앤트로픽 모델이 내려갔을 때, 그 충격은 앤트로픽 채널만이 아니라 구글 플랫폼 위에서 Claude를 부르던 워크플로에도 그대로 갔을 겁니다. 헤지를 파는 플랫폼이 헤지가 필요한 위험을 자기 진열대에 같이 올려놓고 있었던 겁니다. 저는 이게 묘하게 맞물려 있어서 재밌었습니다.

구글한테는 이게 나쁜 소식만은 아닐 것 같습니다. 오히려 팔 말이 분명해집니다. 한 모델에 다 걸지 말고, 우리 위에서는 밑을 바꿔 끼울 수 있다는 거죠. 서울 키노트가 from vision to value라는 제목 아래 모델 소개는 앞에 잠깐 두고 거버넌스와 운영까지 한 줄로 엮은 것도 이렇게 보면 자연스럽습니다. 밑을 바꿀 수 있는 층을 파는 회사가 그 층이 얼마나 값어치 있는지를 이 지역 결정권자들 앞에 풀어놓는 행사인 거죠.

밑을 바꿔 끼운다고 성능까지 그대로 가는 건 아닐 겁니다. Fable 5에 맞춰 다듬은 프롬프트가 다른 모델에서 똑같이 나온다는 보장은 없고, 앤트로픽이 걸린 요청을 이전 모델로 돌려보낸 것처럼 한 단계 낮은 걸로 버텨야 할 수도 있습니다. 그래도 아예 멈추는 것과 조금 낮은 걸로 돌아가는 것 사이에는 꽤 큰 차이가 있다고 봅니다. 사용자는 답이 조금 덜 좋아진 건 잘 모르고 지나가도, 서비스가 아예 응답을 안 하는 건 바로 알아챕니다. 프로덕션에서 무서운 건 대개 뒤쪽입니다.

브레이크를 쥔 손

한 발 물러서서 보면 6월에 바뀐 건 모델 몇 개의 접근 권한이 아니라 브레이크를 쥔 손인 것 같습니다.

지난 몇 년 동안 안전이냐 속도냐 하는 긴장은 대체로 랩 안의 얘기였습니다. 어떤 능력을 언제 풀지, 어떤 안전장치를 걸지, 레드팀이 뭘 걸러낼지를 회사 안에서 정했고, 밖에서 보면 자율 규제였습니다. 앤트로픽이 신중하든 오픈AI가 공격적이든 브레이크는 결국 랩 발밑에 있었습니다. 6월은 그 브레이크가 밖으로, 정부 쪽으로 넘어간 걸 보여준 달이었습니다.

Fable 5를 내린 건 앤트로픽 안전팀이 아니라 상무부의 수출통제 지침이었습니다. 어떤 능력이 국가안보 문제가 되는 순간 그 스위치는 더 이상 회사 혼자 쥐지 못합니다. 코드베이스를 읽고 결함을 고치는 능력, 개발자 생산성의 한가운데 있는 그 능력이 방향만 바꾸면 취약점 찾는 도구가 되고, 그게 능력 자체를 규제 대상으로 만들었습니다.

수출통제라는 말이 낯익은 건 몇 년째 그게 AI 하드웨어, 고성능 GPU 얘기였기 때문일 겁니다. 어떤 칩을 어느 나라에 팔 수 있느냐가 늘 규제의 중심이었습니다. 6월에 달라진 건 그 대상이 하드웨어에서 모델 접근으로 한 칸 올라왔다는 거라고 생각합니다. 칩은 물건이라 국경에서 막지만 모델 접근은 API 호출이라 여권으로 막습니다. 규제가 물리 쪽에서 소프트웨어 쪽으로 올라온 만큼 스위치가 눌리는 속도도 빨라졌습니다. 칩 선적을 막으려면 몇 달이 걸리는데, 모델 접근을 끊는 데는 오후에 도착한 지침 한 장이면 됐습니다.

개발자한테는 좀 아픈 얘기도 있습니다. 6월에 막힌 건 이미지 생성 모델도, 잡담용 챗봇도 아니었습니다. 코딩과 에이전트 능력이 제일 센 프런티어 모델이었습니다. 우리가 프로덕션 에이전트에 제일 넣고 싶어 하는 그 능력이 안보 스위치에 제일 가까이 붙어 있는 능력이기도 한 겁니다. 그러니 이건 언젠가 모델이 더 세지면 생길 일이 아니라, 지금 제일 유능한 개발 도구를 고르는 순간 같이 따라오는 일인 것 같습니다. 유능한 걸 고를수록 스위치에 가까워집니다.

그렇게 생각하면 좀 이상한 선택도 떠오릅니다. 제일 센 모델을 기본으로 두지 않고, 한 단계 낮지만 오래 열려 있을 것 같은 모델을 기본으로 두고 센 모델은 꼭 필요한 일에만 부르는 식입니다. 성능만 보면 손해 같은데, 멈추지 않는 쪽을 더 쳐주는 팀이라면 그게 맞는 계산일 수도 있습니다. 저라면 어느 쪽을 고를지 솔직히 잘 모르겠습니다. 다만 6월 전에는 이런 고민을 할 이유 자체가 없었다는 게 좀 묘하게 느껴집니다. 좋은 모델을 고르는 게 곧 좋은 선택이던 때가 있었습니다. 그게 그렇게 오래전 일도 아닌데 벌써 좀 멀게 느껴집니다. 한 번 그런 일을 보고 나니 그렇습니다.

모델이 강해질수록 이건 더 심해질 것 같습니다. 유능해질수록 그 능력이 안보 문제와 겹치는 부분이 넓어지고, 넓어질수록 바깥 스위치가 눌릴 가능성도 올라갑니다. 6월은 그게 처음으로 두 번 연달아 실제로 일어난 달이었습니다.

이걸 미리 대비할 수 있느냐 하면 저는 잘 모르겠습니다. 어떤 능력이 언제 안보 문제로 분류될지는 쓰는 쪽에서 알 방법이 없습니다. 이번에도 문제가 된 건 매일 하는 코드 수정이었고, 그게 문제가 될 거라고 미리 짐작한 사람은 거의 없었을 것 같습니다. 그러니 무엇이 막힐지를 맞히려고 하기보다는, 뭐가 막히든 버틸 수 있게 만들어 두는 쪽이 현실적인 것 같습니다.

버틴다는 게 거창한 일일 필요는 없을 것 같습니다. 평소에 쓰는 프롬프트 몇 개를 다른 모델에서도 가끔 돌려보고, 어디까지는 비슷하게 나오고 어디서부터 확실히 떨어지는지를 대강이라도 알아두는 정도만 해도 멈췄을 때 덜 당황할 것 같습니다. 문제는 그런 일이 급할 때 말고는 아무도 안 한다는 겁니다. 잘 돌아가는 모델을 두고 굳이 다른 모델을 시험해 볼 이유가 평소엔 없으니까요. 6월 같은 일이 한 번 있고 나야 그게 왜 필요했는지 알게 되는데, 그때는 이미 늦은 경우가 많을 것 같습니다. 결국 평소에 조금 귀찮은 걸 해두느냐 마느냐의 차이인데, 그 귀찮음을 감수할 이유를 6월이 하나 만들어 준 것 같습니다. 그걸 누가 먼저 챙길지는 팀마다 다르겠지만요.

이렇게 보면 구글의 베팅은 꽤 영리해 보입니다. 모델 층은 앞으로도 지정학 싸움에 끌려다닐 것 같습니다. 국적으로 선이 그어지고, 정부 지침 하나로 쓸 수 있다 없다가 정해지고, 능력이 셀수록 그 폭이 커집니다. 구글은 그 층에 다 거는 대신 그 위에서 부품을 바꾸고 라우팅을 다시 거는 층을 팝니다. 모델을 축구공이라고 하면, 공이 어디로 튀든 공을 담는 상자를 파는 쪽이 되겠다는 것에 가깝습니다. Gemini도 유능한 프런티어 모델이니 언젠가 같은 스위치 앞에 설 수 있겠지만, 구글은 자기 모델과 남의 모델을 한 진열대에 같이 올려놨기 때문에 하나가 내려가도 상자는 계속 돌릴 여지가 있습니다.

다중화

그러면 개발자나 조직 입장에서 남는 생각이 하나 있습니다.

브레이크가 랩 안 윤리 위원회에서 바깥 정부로 넘어간 다음에는, 모델 하나가 안정적이냐를 그 랩이 얼마나 신중하냐만으로 장담할 수 없게 된 것 같습니다. 아무리 조심스러운 랩의 모델을 써도, 그 모델은 나와 아무 상관없는 이유로, 다른 나라 연구진의 시연이나 다른 부처의 판단으로 하룻밤 사이에 내려갈 수 있습니다. 6월에 그런 일이 실제로 있었으니까요.

그래서 손댈 수 있는 방어선은 모델을 고르는 데가 아니라 그 위층에 있다고 봅니다. 프로덕션 층을 여러 겹으로 만들어 두는 것. 에이전트를 특정 모델에 하드코딩하지 않고, 밑을 바꿀 수 있는 추상 위에 올려두는 것. 모델 하나가 멈춰도 라우팅을 다시 걸어서 조금 낮은 성능으로라도 계속 돌게 하는 것.

이게 대단한 아키텍처라는 얘기는 아닙니다. 여러 프로바이더를 추상화해 두는 건 원래부터 있던 엔지니어링 상식에 가깝습니다. 다만 그걸 하는 이유가 달라졌습니다. 예전엔 비용을 아끼거나, 품질을 비교하거나, 벤더 락인을 피하려고 했다면, 이제는 밑에 깔린 모델이 정부 손에 내려갈 수 있다는 가용성 위험이 그 위에 하나 더 올라왔습니다. 똑같은 설계인데 이유가 지정학까지 커진 겁니다.

그런데 이렇게 써 놓고 보니 하나가 좀 걸립니다. 밑을 바꿔 끼울 수 있게 해두는 게 원래 있던 상식이라면, 그걸 하려고 꼭 큰 플랫폼을 사야 하는 걸까요. 모델을 부르는 곳을 한 군데로 모아두고 어떤 모델을 부를지를 설정 값 하나로 빼두는 정도면, 작은 팀은 그걸로 6월 같은 일을 꽤 버틸 수 있을 것 같습니다. 코드로 치면 몇십 줄짜리 얇은 층 하나입니다. 구글이 파는 건 거기에 거버넌스와 배포와 운영까지 얹은 큰 덩어리인데, 그 덩어리가 필요한 건 에이전트가 수십 개씩 도는 조직 정도일 것 같습니다. 대부분의 팀한테 필요한 건 그중 얇은 층 하나뿐인데, 무대에서는 그게 늘 큰 덩어리 전체로만 소개됩니다. 6월 일을 헤지로 읽은 건 제 생각 그대로지만, 그 헤지를 얼마짜리로 사야 하는지는 팀마다 꽤 다를 것 같습니다. 이미 있는 코드에 한 줄 끼우면 되는 일을 플랫폼 이전 프로젝트로 만들 필요는 없으니까요.

개인과 조직은 이걸 다르게 받아들일 것 같습니다. 혼자 사이드 프로젝트를 하는 사람한테는 밑 모델이 2주 넘게 멈추는 게 불편할 뿐 치명적이진 않습니다. 기다리거나 잠깐 다른 걸 쓰면 됩니다. 프로덕션 에이전트에 매출이 걸려 있는 조직이라면 그 2주가 계약 위반이 되고 신뢰를 잃는 일이 됩니다. 6월 일을 진지하게 받아들여야 하는 건 뒤쪽이고, 서울 키노트가 비개발자의 직관적 개발부터 기업형 멀티 에이전트의 거버넌스와 운영까지를 굳이 한 줄로 묶어둔 걸 보면 구글이 보고 있는 청중도 뒤쪽인 것 같습니다.

개인과 조직을 이렇게 나눠 놓고 나서 한동안 마음이 좀 불편했습니다. 이 글을 쓰고 나서 전환의 단위는 회사인데 제가 실제로 본 변화는 전부 사람 한 명 단위였다는 걸 따로 적어본 적이 있습니다. 구글이 거버넌스와 운영을 묶어서 파는 상대는 조직인데, 에이전트를 실제로 돌리는 손은 책상 하나에 있습니다. 계약이 회사 단위로 맺어지는 것과 그 회사 안에서 에이전트가 실제로 돌아가는 것 사이에는 아직 거리가 꽤 있는 것 같습니다.

한국 기업들이 서울 무대에서 이 얘기를 들으면 어떻게 받아들일지도 궁금합니다. 외국 국적자를 막는다는 6월 지침은 한국 팀 입장에서는 남 일이 아니었을 텐데, 그런 위험을 직접 겪어 본 조직과 기사로만 본 조직은 같은 세션을 듣고도 다르게 들을 것 같습니다. 겪어 본 쪽에는 헤지라는 말이 바로 와닿을 거고, 안 겪어 본 쪽에는 여전히 벤더 문구로 들릴 수도 있습니다.

만약 이런 일이 몇 번 더 반복된다면, 한국 쪽 팀들은 모델을 고를 때 성능과 가격 말고 하나를 더 보게 될 것 같습니다. 이 모델이 우리 같은 외국 사용자한테 얼마나 오래 열려 있을지요. 지금까지는 그런 걸 묻는 사람이 거의 없었습니다. 좋은 모델은 당연히 누구나 쓸 수 있는 거라고 생각했으니까요. 6월은 그 당연함이 생각보다 얇았다는 걸 보여준 달 같습니다. 그게 앞으로 모델을 고르는 기준에 실제로 들어갈지는 아직 모르겠지만, 적어도 한 번은 그런 생각을 해보게 만든 건 맞는 것 같습니다.

구글이 서울에서 파는 건 결국 그 이유를 상품으로 만든 거라고 봅니다. 그게 구글의 선의라거나 유일한 답이라는 얘기는 아닙니다. Claude를 진열대에 올려둔 플랫폼조차 6월엔 그 위험을 그대로 맞았으니까요. 그래도 세 탭을 나란히 놓고 봤을 때 느낀 건, 모델 층이 흔들릴수록 손댈 수 있는 방어선은 그 위층으로 올라간다는 거였습니다.

저는 서울 행사에 아마 안 갈 것 같습니다. 가더라도 지금 하는 생각이 크게 바뀔 것 같지는 않습니다. 그래도 궁금한 건 하나 있습니다. Agentic Era든 Securing the AI Era든, 무대 위에서 누군가 6월 일을, 에이전트 밑의 모델이 하룻밤 사이에 정부 손에 내려간 그 일을 세일즈 시나리오로 꺼내는지요. 꺼낸다면 제가 세 탭을 보면서 한 생각이 크게 틀리지 않았던 거고, 안 꺼낸다면 구글은 자기가 파는 헤지가 진짜 얼마짜리인지를 아직 말로 하지 못한 걸 겁니다. 6월 일이 없었다면 저도 멀티모델 유연성이라는 말을 그냥 흘려들었을 겁니다. 세 탭이 우연히 한 화면에 겹치지 않았다면 벤더 문구로 읽고 지나갔을 말이었습니다.