모델의 길에서 비켜서기

URL: https://www.youtube.com/watch?v=buHC7bQE1X4
날짜: 2026-09-28
채널: aiDotEngineer
발표자: Kevin Hou, Google DeepMind

---

📌 핵심 질문 / 모델의 능력을 제품에 드러내는 설계 논점

==모델이 더 빠르고 똑똑하고 저렴해질수록 제품은 모델의 능력을 가두는 고정 인터페이스가 아니라, 모델이 직접 확장할 수 있는 실행·협업·표현의 기반을 제공해야 한다.==

• 에이전트가 터미널, 병렬 하위 에이전트, 외부 이벤트, 생성형 사용자 인터페이스를 직접 다루도록 제품의 기본 단위를 바꿔야 한다.
• 최신 모델의 지능을 제품 경험에서 즉시 드러내야 제품이 모델의 발전과 함께 확장된다.
• 사람은 모든 작업을 직접 운전하는 대신 목표와 제약을 정하고, 모델이 조정하는 팀과 동적으로 생성되는 도구를 감독해야 한다.

대규모 언어 모델(Large Language Model, LLM)은 더 이상 보조 선수에 머물지 않는다. 적절한 제품을 둘러주면 팀의 핵심 선수, 즉 스스로 계획하고 다른 에이전트를 조정하며 결과를 표현하는 주체가 된다. 제품이 해야 할 일은 모델의 길을 대신 선택하는 것이 아니라 모델이 가진 능력을 안전하게 펼칠 수 있는 권한, 샌드박스, 비동기 실행, 이벤트 연결, 동적 UI를 제공하는 것이다.

1. 메시지의 출발점: 메시에게 공을 주고 길을 비켜라

1.1. 89분의 아르헨티나와 에이전트 제품의 비유

1. 월드컵 상황으로 핵심 원칙을 제시한다

   1. 아르헨티나를 감독하는 상황에서 89분이 남았고 팀에 Lionel Messi가 있다면 복잡한 전술을 새로 지시하기보다 “메시에게 공을 주고 길을 비켜라(Give the ball to Messi and get out of his way)”라고 할 수 있다.
   2. 이 비유는 최고 수준의 능력을 가진 선수에게 불필요한 간섭을 줄이고, 선수가 가진 판단과 실행을 펼칠 공간을 주는 원칙을 나타낸다.
   3. 발표 초반 관객에게 월드컵 팬이 있는지 묻자 호응이 나왔고, 화면의 슬라이드와 칩이 보이는지 확인하는 짧은 진행 상호작용도 있었다.

2. LLM을 팀의 스타 선수로 재배치한다

   1. LLM은 더 이상 작은 역할만 맡는 보조 선수가 아니며 제품이 올바른 기반을 제공하면 팀의 스타가 될 수 있다.
   2. 스타가 빛나게 하려면 제품이 모델의 판단을 고정된 흐름에 억지로 끼워 넣지 않고 모델의 길을 막지 않아야 한다.
   3. 핵심 문장은 “모델의 길을 비켜라(Stay out of the way of the model)”이며 이후의 제품 구조, 로드맵, 기본 단위가 모두 이 문장에서 파생된다.

1.2. Antigravity의 정체와 발표 목적

1. 기술·비기술 사용자를 위한 에이전트 기반 프로그래밍 제품

   1. Google의 Antigravity는 기술 사용자와 비기술 사용자 모두를 위한 에이전트 기반 프로그래밍 제품이다.
   2. Antigravity는 2025년 11월 출시된 뒤 Google 안팎의 개발자 작업을 가속해 왔다.
   3. Kevin Hou는 Antigravity 엔지니어링 팀의 일부를 이끌며 에이전트를 제품의 최우선 관심사로 삼는다.

2. 제품 소개를 넘어 제품을 만든 원리를 살핀다

   1. Antigravity는 처음부터 에이전트에 관심을 두고, 여러 에이전트를 관리하고 조정하는 새로운 개발 환경이라는 개념으로 출발했다.
   2. 팀은 이후 자체 프록시(proxy)를 분리해 만들고 자체 명령줄 인터페이스(Command-Line Interface, CLI)를 출시했다.
   3. Kevin Hou는 제품의 기능 목록만 나열하는 대신 제품 뒤에서 작동하는 원칙과 로드맵을 이끈 모델 변화, 앞으로 필요한 기본 단위를 함께 제시한다.

2. Antigravity의 진화와 모델 지능에 맞춘 확장

2.1. Antigravity 2.0이 개발 환경과 에이전트 관리자를 분리하다

1. 개발 환경과 조정 계층을 두 애플리케이션으로 나눈다

   1. Antigravity는 Google I/O에서 Antigravity 2.0을 공개했다.
   2. “모델의 길을 막지 않는다”는 원칙에 맞춰 통합 개발 환경(Integrated Development Environment, IDE)과 Agent Manager를 분리했다.
   3. Agent Manager는 이제 독립 실행 애플리케이션으로 사용할 수 있고, IDE에 항상 붙어 있어야 하는 보조 패널이 아니다.

2. Agent Manager가 관리하는 대상과 기능을 넓힌다

   1. 화면은 에이전트와 프로젝트를 한곳에서 관리하는 제어 센터(control center) 역할을 한다.
   2. 하위 에이전트(sub-agent), 새 템플릿, 워크트리(work tree), 예약 작업(scheduled task), 사운드 모드(sound mode)가 함께 제공된다.
   3. 사용자는 단순히 코드를 편집하는 화면을 여는 대신 여러 작업 단위와 에이전트의 상태를 관리하고, 필요할 때 더 깊은 실행 계층으로 내려갈 수 있다.

2.2. ‘지능과 함께 확장하기(Scaling with Intelligence)’

1. 제품의 발전 속도를 모델의 발전 속도와 연결한다

   1. Kevin Hou는 2022년부터 개발자 도구를 만들며 얻은 가장 큰 교훈으로 “지능과 함께 확장하기(scaling with intelligence)”를 꼽는다.
   2. 모델이 좋아질 때 제품도 좋아져야 하며, 사용자가 최신 모델의 능력을 제품 경험에서 명확히 볼 수 있어야 한다.
   3. 새 모델을 붙였는데 제품의 고정된 흐름이 능력을 가린다면 모델 발전은 사용자 가치로 전환되지 않는다.

2. 2022년에는 모델이 할 수 있는 일에 맞춰 제품을 좁혔다

   1. 당시 개발자 도구는 자동완성(autocomplete)과 채팅 사이드바(chat sidebar)를 중심으로 작동했다.
   2. 포함 관계(inclusion), 규칙 파일(rule file), 구문 트리 분석(syntax-tree analysis) 같은 장치가 애플리케이션 안에 들어갔다.
   3. 그 구조가 필연적이었던 이유는 당시 모델이 안정적으로 처리할 수 있는 범위가 그 정도였기 때문이다.

3. 2024년에는 에이전트가 개발 방식 자체를 바꿨다

   1. 지능형 에이전트가 등장하면서 개발자는 한 번의 완성 문장을 받는 방식에서 여러 단계를 계획하고 수행하는 방식으로 이동했다.
   2. 모델 컨텍스트 프로토콜(Model Context Protocol, MCP), 사용자 정의 도구(custom tools), 권한 시스템(permission systems)이 핵심 제품 요소로 부상했다.
   3. 제품은 답변을 표시하는 창보다 모델이 현실의 도구를 안전하게 호출하도록 연결하는 실행 환경에 가까워졌다.

4. 2025년에는 여러 에이전트를 동시에 관리했다

   1. Antigravity의 Agent Manager와 이를 뒤따른 여러 제품은 사용자가 여러 에이전트를 병렬로 관리하는 흐름을 만들었다.
   2. 스킬(skills), 훅(hooks), 아티팩트(artifacts)가 2025년의 대표적인 기본 요소가 됐다.
   3. 2026년에는 이 요소 위에 에이전트 팀, 외부 이벤트를 듣는 장기 프로세스, 필요에 따라 생성되는 UI가 더해진다.

2.3. 사용자가 사랑하는 기능을 없애는 어려움과 두 가지 전환 사례

1. 더 나은 경로를 위해 익숙한 기능을 제거한다

   1. 사용자가 익숙하고 좋아하는 기능을 제거해 더 나은 경로로 이끄는 일은 매우 어렵다.
   2. 제품 팀이 항상 100% 옳은 것은 아니지만, 모델이 발전하면 이전의 안전장치나 인터페이스가 오히려 능력을 가리는 경우가 생긴다.
   3. 이 전환은 당장의 불만을 감수하면서 장기적으로 더 강한 모델-제품 관계를 만드는 선택이 된다.

2. 터미널 접근 권한에 대한 공포를 권한 시스템으로 극복한다

   1. AI에게 터미널을 주면 전체 소프트웨어 데이터베이스를 지우고 스타트업을 망가뜨릴 것이라는 두려움이 널리 퍼졌다.
   2. 모델이 향상되고 권한 시스템 같은 핵심 안전 요소에 투자하면서 사용자는 더 빠르게 만들고 더 많은 일을 하면서도 안전하게 작업할 수 있게 됐다.
   3. 더 지능적인 모델은 터미널에서 무엇을 실행해야 하고 무엇을 실행하면 안 되는지 더 나은 결정을 내릴 수 있다.

3. 채팅 사이드바를 프록시로 바꾼다는 반발을 통과한다

   1. 채팅을 제거하고 프록시만 남겼을 때 사용자는 팀을 향해 강한 반발을 보냈다.
   2. 당시 채팅 사이드바는 익숙하고 소중한 기능이었기 때문에 제거는 받아들이기 어려웠다.
   3. 이후 모델이 다단계 연구와 에이전트 기반 연구·구현을 수행하면서 채팅창에 모든 기능을 담는 방식은 새 패러다임으로 대체됐고, 사용자도 에이전트 제품을 사용하고 사랑하게 됐다.

3. 2026년 에이전트 팀 시대

3.1. IDE와 Agent Manager의 관계를 디버거와 IDE의 관계로 재정의한다

1. 항상 필요한 화면과 필요할 때 여는 화면을 분리한다

   1. Antigravity 2.0에서 Agent Manager와 IDE를 분리한 관계는 개발 환경과 디버거(debugger)의 관계와 비슷하다.
   2. 개발자는 항상 디버거를 열어 둘 필요는 없지만 추상화 계층 아래로 내려가 원인을 파고들어야 할 때 디버거가 결정적으로 유용하다.
   3. 마찬가지로 사용자는 항상 여러 에이전트의 내부 조정을 볼 필요는 없지만 복잡한 작업을 맡기거나 실패 원인을 조사할 때 Agent Manager를 사용할 수 있다.

2. 에이전트 조정의 미래에 베팅한다

   1. 에이전트 팀(agent teams), 에이전트 스웜(agent swarms), 소프트웨어 팩토리(software factories)는 이름은 달라도 여러 에이전트가 함께 일하는 동일한 미래를 가리킨다.
   2. Antigravity 팀은 이 조정 계층이 미래라고 판단하고 제품 구조를 그 방향에 맞춰 준비한다.
   3. 2026년의 대표 기본 요소는 하위 에이전트, 생성형 사용자 인터페이스(generative UI), 보조 에이전트(helper agent)다.

3.2. 제품 변화와 모델 변화가 서로를 이끄는 방식

1. 새로운 기본 요소는 실험과 모델 능력의 결합에서 나온다

   1. 제품 팀이 독자적으로 새 시대의 원리를 정할 수도 있지만 실제 변화는 제품을 만들고 모델을 실험하는 과정에서 함께 발견된다.
   2. Google DeepMind 안에서는 모델과 제품이 가까이 연결돼 있어 모델 능력의 변화가 제품 설계로 빠르게 반영된다.
   3. Agent Manager의 필요성도 단순한 화면 설계가 아니라 Gemini가 에이전트 팀을 관리할 수 있게 된 데서 출발했다.

2. Antigravity와 Gemini가 서로의 능력을 밀어 올린다

   1. Antigravity 1.0의 중심은 병렬 에이전트 관리였고, 사람은 운전석에 앉아 각 에이전트를 직접 관리했다.
   2. 이전 발표에서 소개한 Flywheel 검색 제품처럼, 실제 제품 사용은 모델에게 에이전트 팀을 관리하는 방법을 학습할 기회를 제공했다.
   3. Gemini는 Antigravity를 통해 팀 조정의 기본을 익혔고, 더 나은 협업과 작업 분해에는 아직 개선 여지가 있지만 강한 출발점을 만들었다.

3. Gemini 3.5 Flash가 팀 리더 역할을 현실화한다

   1. Gemini 3.5 Flash는 2026년 4월 출시됐고 Antigravity가 그동안 뒤에서 실험하던 능력을 대중에게 가져왔다.
   2. Flash는 개별 작업을 수행하는 능력뿐 아니라 팀을 이끄는 능력이 강하며 빠르고 저렴하다.
   3. 지능과 속도·비용의 관계에서 Pareto 곡선을 밀어 올려 같은 비용으로 더 많은 지능을 사용하거나 같은 지능을 더 빠르고 저렴하게 사용할 수 있게 한다.

4. Agent Teams의 실제 구조와 사례

4.1. /teamwork로 에이전트 스웜을 시작한다

1. 사용자는 목표를 구체적으로 입력한다

   1. Antigravity의 공개 프리뷰에서 /teamwork 슬래시 명령을 입력하면 Agent Teams 모드로 들어가 작업에 필요한 에이전트 스웜을 풀어놓을 수 있다.
   2. 사용자가 정의하는 작업이 구체적일수록 결과가 좋아진다.
   3. 정보가 부족하면 에이전트가 사용자에게 추가 정보를 물어보고, 작업의 조건이 명확해질 때까지 상호작용한다.

2. 리드 에이전트가 동적으로 팀을 구성한다

   1. 리드 에이전트(lead agent)는 필요한 팀 규모를 정하고 전체 작업을 관리한다.
   2. 리드 에이전트는 Avengers처럼 프런트엔드 엔지니어, 백엔드 엔지니어, 인프라 전문가, 품질 보증(Quality Assurance, QA) 담당자, 디자이너 등 전문 역할을 조합한다.
   3. 각 하위 에이전트는 작업 중 동적으로 생성되고 독립적으로 실행된다.
   4. 하위 에이전트마다 다른 모델을 선택할 수 있으며 어떤 모델을 쓸지는 리드 에이전트가 결정한다.

4.2. 생성형 UI로 팀의 진행 상황을 즉시 표현한다

1. 모델이 질문에 맞춰 인터페이스를 만든다

   1. Gemini Flash처럼 빠른 모델을 쓰면 “내 작업 상태가 어때?”라고 묻는 순간 상태 화면이 만들어질 수 있다.
   2. 사용자가 “무슨 일이 진행 중인지 칸반 보드(Kanban board)로 보여줘”라고 요청하면 모델은 칸반 보드를 즉시 생성한다.
   3. Chrome의 오류 수정 도구처럼 시간순 타임라인을 보고 싶다면 작업의 진행을 타임라인 형태로 표시한다.

2. 정해진 화면 대신 작업에 맞는 도구를 생성한다

   1. 생성형 사용자 인터페이스는 개발자가 모든 상황을 미리 템플릿으로 만들어 두지 않아도 된다.
   2. 빠른 모델은 요청의 의미를 해석하고 그 순간 필요한 조작 화면을 만든다.
   3. 이 구조는 에이전트의 협업 상태를 텍스트 로그만으로 읽어야 하는 부담을 줄이고 사용자가 원하는 학습 방식과 탐색 방식에 맞춘다.

4.3. 수백 개의 하위 에이전트로 만든 프로젝트

1. 브라우저 안에서 작동하는 이미지 편집기와 메시징 앱

   1. Antigravity 팀은 브라우저 안에서 원본(raw) 이미지를 직접 편집할 수 있는 이미지 편집기를 만들었다.
   2. 행사장 사람들에게 익숙해 보이는 메시징 앱도 만들었다.
   3. 두 프로젝트에는 각각 수백 개의 하위 에이전트가 투입됐고 실행에 대략 반나절이 걸렸다.

2. 운영체제 커널과 Doom으로 한계를 시험한다

   1. 가장 주목할 만한 시험은 운영체제(OS) 커널 전체를 처음부터 만드는 일이었다.
   2. Google I/O에서 완전한 운영체제 커널을 구축하고 그 위에서 Doom을 실제로 실행하는 데모가 공개됐다.
   3. 동료 Varun이 Google I/O 무대에서 이 시연을 맡았다.
   4. 이 실험은 더 많은 지능과 더 많은 하위 에이전트를 투입하면 Gemini 3.5 Flash가 매우 강력하면서도 확장 가능하고 비교적 저렴한 방식으로 복잡한 문제를 처리할 수 있다는 점을 보여줬다.

3. 커널 구축의 규모와 비용

   1. 93개의 하위 에이전트가 12시간 이상 작업했다.
   2. 전체 과정에서 15,000개의 명령이 처리됐다.
   3. 약 20억 개의 토큰을 사용했다.
   4. 총비용은 1,000달러 미만이었다.
   5. 매일 수천 달러를 들여 운영체제 커널을 만들 필요는 없지만, 필요하다면 이 규모의 작업도 가능하다는 점이 핵심이다.

5. 평가 분석 자동화: 내부 연구 업무를 에이전트 워크플로로 바꾸다

5.1. 전통적인 평가 비교의 병목

1. 컨트롤과 실험을 비교한다

   1. Gemini의 프로그래밍·에이전트 능력을 개선하는 내부 연구에는 평가 결과를 분석하는 작업이 반복해서 등장한다.
   2. 연구자는 여러 실행(run)을 1, 2, 3, 4처럼 나누고 동일한 작업 집합을 각각 수행해 결과를 얻는다.
   3. 컨트롤 그룹과 실험 그룹을 두 표에 놓고 단순한 결과 차이뿐 아니라 차이가 생긴 이유까지 파악해야 한다.

2. 차이의 원인에서 다음 실험으로 이어간다

   1. 연구자는 어느 평가가 좋아지고 나빠졌는지 확인한다.
   2. 차이의 원인을 추정하고 그 추정을 검증하면서 다음 버전을 위한 수정안을 만든다.
   3. 과거에는 이 과정 대부분을 Jupyter Notebook에서 수동으로 처리해야 했다.

5.2. 자연어 질문과 90% 자동화

1. 스킬과 Monorepo 지식으로 데이터를 읽는다

   1. 2026년의 기본 단위를 사용하면 연구 그룹은 관련 평가에 대해 자연어로 질문하는 것만으로 이 워크플로의 90%를 자동화할 수 있다.
   2. 에이전트는 Google의 거대한 모노레포(Monorepo) 데이터베이스에 대한 스킬과 이해를 갖고 결과를 처리한다.
   3. 연구자는 직접 노트북 코드를 작성하는 대신 어떤 실험의 어떤 결과를 비교하고 싶은지 묻고 차이와 맥락을 받는다.

2. 단순 비교를 넘어 100개 가설을 병렬 조사한다

   1. 에이전트는 차이만 반환하는 데서 멈추지 않는다.
   2. 전문 연구 에이전트가 차이가 발생한 이유에 대한 가설을 100개 제안한다.
   3. 각 가설을 별도의 하위 에이전트에 배정해 특정 사례를 병렬로 조사한다.
   4. 하위 에이전트의 조사를 하나의 응답으로 합치고 연구자에게 발견 사항과 검토 가능한 보고서를 건넨다.
   5. 에이전트가 연구자에게 건네는 흐름은 “여기서 발견한 측면들이 있고, 이제 검토할 보고서가 있다”는 형태로 결과와 판단 재료를 함께 제공한다.

5.3. 보고서에서 생성형 분석 화면으로 확장한다

1. 연구자가 결과를 직접 탐색한다

   1. 시스템은 보고서 텍스트만 반환하지 않고 생성형 UI를 함께 만든다.
   2. 연구자는 데이터를 브라우즈하고, 항목을 상호작용으로 선택하고, 드롭다운 메뉴를 열고, 필터와 세그먼트를 적용할 수 있다.
   3. 긴 표나 텍스트를 순서대로 읽지 않아도 자신의 질문과 학습 방식에 맞춰 결과를 깊게 탐색할 수 있다.

2. Google 내부 제품 개선 루프에 연결한다

   1. 내부 팀은 모델을 개선하고 제품을 개선하며 Google 안에서 사용자가 성공하거나 실패하는 방식을 이해하는 데 이 워크플로를 활용한다.
   2. 예전에는 수동으로 처리하던 일이 이제 몇 분 안에 끝난다.
   3. 초기 구축에는 비동기 프록시 제품군, 평가기(evaluator), 데이터 파이프라인을 직접 만들고 서로 연결하는 수작업이 필요했다.
   4. 동적 하위 에이전트, 외부 이벤트를 듣는 프로세스, 생성형 UI라는 기본 단위가 이 반복적인 연결 작업을 제품 구조에 흡수한다.

3. 사용자는 스킬 파일을 올리고 바로 질문한다

   1. 하위 에이전트 체계가 동적으로 구성되고 생성형 UI가 결과를 마지막에 풍부한 화면으로 표현한다.
   2. 이 작업은 실행 중에도 재현하거나 수정할 수 있다.
   3. 사용자가 스킬 파일을 업로드하고 자연어로 질문하면 필요한 연구·분석·표현 흐름이 조합된다.

6. 2026년을 여는 세 가지 기본 단위

6.1. 동적 하위 에이전트(Dynamic Sub-agent)

1. 하위 에이전트는 작업마다 새로 구성된다

   1. 어떤 두 하위 에이전트도 완전히 동일하지 않으며 작업의 목표와 필요한 역할에 따라 구성이 달라진다.
   2. 메인 에이전트는 모든 하위 에이전트를 조정하는 책임을 진다.
   3. 메인 에이전트는 작업 중 하위 에이전트를 준비하고 방향을 제시하며 필요한 데이터를 전달한다.

2. 병렬성과 격리성을 함께 확보한다

   1. 하위 에이전트는 여러 작업을 병렬로 수행할 수 있다.
   2. 각각 격리된 환경인 샌드박스(sandbox) 또는 원격 실행 시스템(remote execution system)에서 일할 수 있다.
   3. 프런트엔드, 백엔드, 인프라, 연구, QA 등 전문 역할의 수에는 사실상 제한이 없다.

3. 모델 지능이 팀의 복잡도를 끌어올린다

   1. 모델이 똑똑해질수록 팀은 더 전문화되고 더 협력적으로 구성된다.
   2. 더 전문화된 협업은 한 에이전트가 처리하기 어려운 복잡한 작업을 대신 수행하는 능력으로 이어진다.
   3. 확장의 핵심은 사람을 계속 추가하는 것이 아니라 모델이 작업을 분해하고 적절한 에이전트를 동적으로 배치하는 데 있다.

6.2. 사이드카(Sidecar): 외부 세계를 오래 듣는 프로세스

1. 장기 실행 보조 프로세스를 에이전트 옆에 둔다

   1. Sidecar는 Antigravity에 도입되는 새로운 추가 프로토콜이다.
   2. 이름처럼 메인 프로세스 옆에서 함께 실행되는 별도 프로세스이며, 장기간 실행되고 외부 세계를 계속 듣는다.
   3. Sidecar가 사건을 감지하면 모델이 반응할 수 있는 트리거(trigger)를 준비한다.

2. 여러 이벤트를 에이전트의 시작 조건으로 연결한다

   1. 짧은 텍스트 메시지가 들어올 수 있다.
   2. 웹훅(webhook)이 외부 서비스의 사건을 전달할 수 있다.
   3. 예약 작업과 크론 작업(cron job)이 정해진 시간에 실행을 시작할 수 있다.
   4. GitHub의 풀 리퀘스트(pull request)에 연결해 코드 변화가 발생할 때 에이전트를 깨울 수도 있다.
   5. 이 목록은 고정된 몇 가지 통합이 아니라 계속 확장 가능한 추가 계층이다.

3. 예약 작업의 숨은 기반을 공개한다

   1. Antigravity는 이미 시간 기반 작업에 Sidecar를 사용하고 있다.
   2. 사용자가 보는 scheduled task 기능과 cron 동작의 뒤에는 Sidecar가 있다.
   3. Sidecar 사양은 2026년 여름 후반에 공개될 예정이며 외부 개발자도 이 기본 요소 위에 새로운 기능을 만들 수 있다.
   4. Google 내부 직원들은 이미 이 개념을 업무 자동화에 활용할 수 있는 좋은 방식을 실험하고 있다.

6.3. 생성형 사용자 인터페이스(Generative UI)

1. 사람이 미리 작성한 특수 UI의 전제를 바꾼다

   1. 생성형 UI는 사람이 목적별로 작성한 특수 인터페이스가 거의 쓸모없어질 수 있다는 강한 가정을 전제로 한다.
   2. Gemini Flash는 Antigravity에서 초당 약 900개의 기호(symbol)를 생성한다.
   3. 이 속도는 여러 선도적인 프로토타입 실험보다 약 10배 빠르다.

2. 아이디어를 대화형 도구로 즉시 전환한다

   1. 사용자는 머릿속 아이디어를 텍스트 프롬프트로 옮긴 뒤 몇 초 안에 대화형 인터페이스에 통합된 사용 사례를 얻을 수 있다.
   2. 템플릿이나 HTML 파일을 미리 준비할 필요가 없다.
   3. Antigravity는 대화 안에서 모델이 만든 UI를 직접 표시한다.
   4. Doom 같은 게임뿐 아니라 막대 차트, 그래프, 표, 세부 데이터를 더 깊게 살펴볼 수 있는 모든 조작 화면을 만들 수 있다.

3. 고정된 플라스틱 버튼을 없앤다는 iPhone의 비유

   1. 이 구조는 Steve Jobs가 iPhone을 공개하면서 키보드를 없앤 이유를 설명한 말과 닮았다.
   2. Steve Jobs의 요지는 “모든 기기에 키보드가 있고, 필요할 때나 필요하지 않을 때나 존재한다. 모든 기기는 고정된 플라스틱 제어 버튼을 갖고 모든 애플리케이션에서 똑같이 보인다”는 것이었다.
   3. 생성형 UI는 모든 작업에 같은 버튼과 화면을 강요하지 않고 에이전트가 필요한 도구를 그 자리에서 확장한다.

4. 기계적인 UI에서 모델을 위한 유틸리티로 이동한다

   1. Antigravity는 무거운 인프라와 기계적인 사용자 인터페이스를 넘어 유틸리티와 생성형 UI를 선택한다.
   2. 제품 경험은 고정된 플라스틱 프레임에 갇히지 않고 에이전트의 요구에 따라 늘어난다.
   3. 동적 하위 에이전트, 유틸리티 드라이버(utility driver), 생성형 UI가 Antigravity를 구동하는 세 가지 주된 요소가 된다.

7. 제품을 만드는 사람에게 주는 설계 원칙

7.1. 모델의 지능이 커질 자리를 처음부터 남겨 둔다

1. 제품의 초기 요소를 확장 가능한 형태로 선택한다

   1. AI 에이전트를 중심으로 제품을 만든다면 초기 요소가 모델의 지능과 함께 확장될 수 있는지 살펴야 한다.
   2. 에이전트가 사용할 도구, 병렬 작업을 격리하는 환경, 외부 사건을 듣는 프로세스, 결과를 표시하는 UI가 처음부터 확장 가능한 기본 단위가 되어야 한다.
   3. 사람이 미리 정한 단계 수와 화면 수가 모델의 능력을 제한하지 않아야 한다.

2. 많은 기능보다 다음 모델에서도 살아남을 기능을 고른다

   1. 새로운 도구가 많아져 기능을 출시하는 일 자체는 쉬워졌다.
   2. 더 중요한 결정은 어떤 기능이 다음 모델 출시 때에도 가치가 커질지 고르는 일이다.
   3. 다음 모델은 필연적으로 더 빠르고, 더 좋고, 더 저렴해지므로 제품은 그 개선을 흡수해야 한다.

7.2. 지능의 초기 기반이 프로토타입의 상한선을 바꾼다

1. 올바른 요소가 모델의 잠재력을 드러낸다

   1. 동적 하위 에이전트, Sidecar, 생성형 UI를 올바르게 조합하면 제작자는 초기 기대를 뛰어넘는 프로토타입을 보게 된다.
   2. 이미지 편집기, 메시징 앱, OS 커널처럼 서로 다른 문제도 같은 기본 단위로 조합할 수 있다.
   3. 모델이 발전할수록 같은 제품 구조가 더 복잡한 작업을 받아들이며, 제품 팀은 매번 전체 인터페이스를 다시 만들 필요가 없다.

2. 사람의 역할을 운전자에서 설계자·감독자로 넓힌다

   1. 사람은 목표와 안전 제약, 필요한 정보, 검토 기준을 설정한다.
   2. 리드 에이전트는 전문 하위 에이전트를 구성하고, Sidecar는 사건을 기다리며, 생성형 UI는 현재 필요한 도구를 만든다.
   3. 사람은 모든 명령을 직접 입력하기보다 모델이 확장될 수 있는 무대와 피드백 루프를 설계한다.

8. 마무리 발언과 현장 안내

8.1. TPU 농담과 피드백 요청

1. 컴퓨팅 자원의 현실을 농담으로 마무리한다

   1. Kevin Hou는 TPU 프로세서 위기가 실제로 해결될 때까지 자신이 들고 온 칩을 계속 사용하겠다고 농담했다.
   2. 이 말은 더 많은 에이전트와 토큰을 쓰는 확장 전략이 모델 지능뿐 아니라 실제 컴퓨팅 자원에도 의존한다는 현실을 환기한다.

2. 다음 제품 실험을 위한 피드백을 요청한다

   1. Kevin Hou는 Twitter에서 찾을 수 있고 개인 메시지로 피드백을 보낼 수 있다고 안내했다.
   2. 팀은 새롭고 가장 좋은 제품을 만드는 방법에 대한 아이디어를 계속 찾고 있다.

8.2. Antigravity 부스에서 이어지는 대화

1. 행사 주최자와 관객에게 감사를 전한다

   1. Kevin Hou는 자신을 초대하고 행사를 진행한 Swix와 Ben에게 감사했다.
   2. 이 자리에 서는 일이 늘 즐겁다고 말하며 발표를 마쳤다.

2. 제품을 더 보고 싶은 사람을 현장 팀으로 연결한다

   1. Kevin Hou는 Antigravity 부스에 머물 예정이라고 안내했다.
   2. 제품에 대해 더 알고 싶은 사람은 부스의 팀원들과 대화할 수 있다.
   3. 별도의 긴 질의응답 세션보다 부스에서 후속 대화를 이어가는 방식으로 관객과 만남을 열어 두고 감사 인사를 전했다.

주요 발언 모음

“메시에게 공을 주고 길을 비켜라(Give the ball to Messi and get out of his way).”

“LLM은 더 이상 작은 역할을 맡는 선수가 아니다. 올바른 제품을 둘러주면 팀의 스타가 될 수 있다.”

“스타가 빛나게 하려면 모델의 길을 비켜야 한다(Stay out of the way of the model).”

“모델이 좋아질 때 제품도 좋아져야 하며, 사용자는 제품 경험 안에서 최신 모델의 수준을 분명히 볼 수 있어야 한다.”

“사용자가 필요한 만큼 구체적으로 작업을 정의하면 된다. 더 필요한 정보가 있으면 에이전트가 물어본다.”

“이 팀은 Avengers와 비슷하다. 프런트엔드, 백엔드, 인프라, QA, 디자이너 같은 전문 역할을 불러올 수 있다.”

“여기서 발견한 측면들이 있다. 이제 검토할 수 있는 보고서를 보여주겠다.”

“모든 하위 에이전트가 똑같지는 않다. 메인 에이전트가 준비하고 안내하고 데이터를 제공한다.”

“모든 기기에는 필요할 때나 필요하지 않을 때나 존재하는 키보드와 고정된 플라스틱 버튼이 있다.”

“제품을 만드는 사람이라면 초기 요소가 모델의 지능과 함께 어떻게 확장될지 생각해야 한다.”

핵심 데이터 & 수치

• 출시 시점: Antigravity는 2025년 11월 출시됐고 Antigravity 2.0은 2026년 Google I/O에서 공개됐다.
• 개발 도구의 단계: 2022년 자동완성·채팅 사이드바, 2024년 MCP·사용자 정의 도구·권한 시스템, 2025년 병렬 에이전트 관리·스킬·훅·아티팩트, 2026년 에이전트 팀·Sidecar·생성형 UI로 이어졌다.
• Gemini 3.5 Flash: 2026년 4월 출시됐고 작업 수행뿐 아니라 팀 리딩에 강한 빠르고 저렴한 모델로 제시됐다.
• OS 커널 실험: 93개 하위 에이전트가 12시간 이상 작업하고 15,000개 명령과 약 20억 토큰을 처리했으며 1,000달러 미만이 들었다.
• 평가 분석 자동화: 연구 그룹이 자연어 질문만으로 기존 수동 워크플로의 90%를 자동화했다.
• 가설 병렬 조사: 전문 연구 에이전트가 차이의 원인에 대한 100개 가설을 만들고 하위 에이전트가 각각 병렬 조사했다.
• 생성형 UI 속도: Gemini Flash가 Antigravity에서 초당 약 900개 기호를 생성하며 여러 선도 프로토타입 시험보다 약 10배 빠르다고 제시됐다.
• 프로젝트 규모: 브라우저 이미지 편집기와 메시징 앱에는 각각 수백 개의 하위 에이전트가 투입됐고 대략 반나절이 걸렸다.

결론 및 시사점

1. 제품의 중심을 고정된 기능에서 모델의 확장성으로 옮겨야 한다: 모델이 더 똑똑해질 때마다 사람이 새 화면과 절차를 덧붙이는 대신 모델이 도구와 팀을 조합할 수 있는 기반을 마련해야 한다.
2. Agent Manager는 IDE의 대체물이 아니라 조정 계층이다: 개발자는 평소 IDE에서 일하고 복잡한 조정과 관찰이 필요할 때 별도 Agent Manager로 내려갈 수 있다.
3. 동적 하위 에이전트는 지능의 병렬 확장 장치다: 리드 에이전트가 전문 역할과 모델을 고르고 샌드박스·원격 환경에서 병렬 실행하면 복잡한 작업도 비용과 시간의 제약 안에서 분해할 수 있다.
4. Sidecar는 에이전트를 대화창 밖의 세계와 연결한다: 메시지, 웹훅, cron, GitHub PR을 장기적으로 듣는 프로세스가 에이전트를 적절한 순간에 깨운다.
5. 생성형 UI는 결과 표현 방식까지 모델에게 맡긴다: 칸반 보드, 타임라인, 차트, 그래프, 표, 게임처럼 작업에 필요한 화면을 대화에서 즉시 생성한다.
6. 안전은 권한과 격리로 제품 구조에 포함해야 한다: 터미널 접근 사례는 더 강한 모델과 permission system, sandbox가 함께 발전할 때 에이전트의 자율성이 생산성과 안전성으로 전환된다는 점을 보여준다.
7. 다음 모델을 위한 여백이 제품의 경쟁력이 된다: 기능 수가 아니라 더 빠르고 더 좋고 더 저렴한 다음 모델이 들어왔을 때 가치가 커지는 초기 요소를 선택해야 한다.

핵심 요약 (20줄)

LLM은 보조 선수가 아니라 올바른 제품을 만나면 팀의 스타가 되는 실행 주체다. 제품은 모델의 판단을 가두기보다 메시에게 공을 주고 길을 비키듯 모델의 능력을 펼칠 공간을 제공해야 한다. Antigravity는 기술 사용자와 비기술 사용자를 위한 Google의 에이전트 기반 프로그래밍 제품이다. Antigravity 2.0은 IDE와 Agent Manager를 분리해 개발과 에이전트 조정의 경계를 나눴다. Agent Manager는 하위 에이전트와 템플릿과 워크트리와 예약 작업과 사운드 모드를 관리한다. 제품은 모델이 좋아질 때 사용자 경험도 좋아져야 한다는 지능과 함께 확장하기 원칙을 따른다. 2022년의 자동완성과 채팅 사이드바는 당시 모델이 처리할 수 있는 범위에 맞춘 구조였다. 2024년에는 MCP와 사용자 정의 도구와 권한 시스템이 에이전트 개발의 핵심 요소가 됐다. 2025년에는 여러 에이전트를 병렬로 관리하는 Agent Manager와 스킬과 훅과 아티팩트가 등장했다. 2026년의 에이전트 팀은 하위 에이전트와 생성형 UI와 보조 에이전트를 기본 단위로 삼는다. Gemini 3.5 Flash는 빠르고 저렴하면서 팀을 이끄는 능력을 갖춰 Agent Teams를 현실화했다. 사용자는 /teamwork로 작업을 시작하고 리드 에이전트는 전문 역할을 가진 팀을 동적으로 구성한다. 하위 에이전트는 서로 다른 모델과 격리 환경을 사용하면서 독립적이고 병렬적으로 작업할 수 있다. OS 커널 구축 실험은 93개 에이전트와 12시간과 15,000개 명령과 20억 토큰과 1,000달러 미만의 비용으로 진행됐다. 평가 분석 워크플로는 자연어 질문만으로 90%가 자동화됐고 100개 가설이 병렬 조사됐다. Sidecar는 메시지와 웹훅과 cron과 GitHub PR을 장기적으로 듣고 에이전트를 깨우는 프로토콜이다. 생성형 UI는 템플릿이나 HTML 없이 대화 안에서 칸반 보드와 차트와 표와 게임을 만든다. Gemini Flash는 Antigravity에서 초당 약 900개 기호를 생성해 빠른 UI 생성을 가능하게 한다. 사람이 모든 고정 버튼을 미리 만드는 시대에서 에이전트가 필요한 도구를 그때 생성하는 시대로 이동한다. 제품 제작자는 다음 모델이 더 빠르고 좋고 저렴해질 때 함께 커질 초기 요소를 선택해야 한다.