모델의 길에서 비켜서기

원문 제목: Get Out of the Model's Way — Kevin Hou, Google DeepMind
URL: https://www.youtube.com/watch?v=buHC7bQE1X4
영상 ID: buHC7bQE1X4
채널: AI Engineer (aiDotEngineer)
발행일: 2026-09-27
처리일: 2026-09-28 (Asia/Seoul)
발표자: Kevin Hou, Google DeepMind Antigravity Engineering Lead
영상 길이: 19분 1초

📌 핵심 질문 / 제품이 모델의 지능을 가로막지 않게 만드는 방법

==모델이 더 똑똑해질수록 제품은 모델의 판단을 대신하는 고정된 도구·워크플로·UI를 줄이고, 동적 서브에이전트(dynamic subagent)·Sidecar·생성형 UI(generative UI)가 확장될 공간을 제공해야 한다.==

• Kevin Hou는 2022년 자동완성(autocomplete)에서 2024년 에이전트(agent), 2025년 에이전트 관리자(agent manager)를 거쳐 2026년 에이전트 팀(agent teams)으로 개발 도구가 진화했다고 설명한다.
• Google Antigravity는 Gemini 3.5 Flash가 팀을 이끌고 필요한 역할을 즉석에서 만들도록 하여, OS 커널을 93개 서브에이전트·12시간·20억 토큰·1,000달러 미만으로 구축한 사례를 제시한다.
• 탐색적 문제에는 모델이 파일 시스템과 bash를 직접 다루게 하고, 결과를 생성형 UI로 표현하며, 외부 이벤트는 장기 실행 Sidecar가 받도록 하는 단순한 기반이 복잡한 고정 파이프라인보다 오래 견딘다.

제품의 수명은 현재 모델을 얼마나 정교하게 제약하느냐가 아니라 다음 모델이 더 빠르고 싸고 똑똑해졌을 때 함께 좋아지는가에 달려 있다. Antigravity는 사람이 모든 단계를 미리 결정하는 애플리케이션에서 모델이 목표를 해석하고 팀·도구·인터페이스를 스스로 구성하는 운영 환경으로 이동한다.

1. “메시에게 공을 주고 길을 비켜라”라는 제품 철학

1.1. 축구 비유가 설명하는 모델의 역할

1. 89분의 아르헨티나 경기

   1. 최고의 선수에게 맡기기: 89분에 메시가 팀에 있다면 코치는 복잡한 전술을 직접 수행하기보다 “메시에게 공을 주고 그의 길에서 비켜라(Give the ball to Messi and get out of his way)”라고 할 것이다.
   2. 제품 설계의 대응: 대규모 언어 모델(large language model)은 더 이상 보조적인 선수에 머물지 않으며, 알맞은 제품을 주변에 만들면 팀의 스타가 된다.

2. 비켜선다는 말의 의미

   1. 판단을 대신하지 않기: 모델이 이미 처리할 수 있는 복잡성을 보호한다는 명목으로 사람이 선택지를 잘게 쪼개면 모델의 추론 공간이 제품의 한계에 갇힌다.
   2. 지능과 함께 확장하기: 제품의 기본 요소는 모델 성능이 오를 때 더 강력해져야 하며, 모델의 한계를 영구적인 제품 규칙으로 굳히면 새로운 모델의 능력을 낭비하게 된다.

1.2. Antigravity의 정체성과 출발점

1. 기술·비기술 사용자를 위한 에이전트 제품

   1. 제품 범위: Google Antigravity는 technical user와 non-technical user 모두를 위한 agent-based programming product다.
   2. 출시와 목적: 2025년 11월 출시 이후 Google 안팎의 개발자 업무를 가속해 왔으며, 핵심 관심사는 처음부터 agents였다.

2. Antigravity 1.0의 중심 개념

   1. 에이전트 관리·조정 플랫폼: 개발 환경 자체보다 여러 에이전트를 관리하고 조정하는 새로운 방식에 초점을 맞췄다.
   2. 기반의 확장: 자체 proxy를 추출하고 Antigravity command interface를 출시하면서 하나의 IDE 기능을 넘어 에이전트 운영 계층으로 확장했다.

2. Antigravity 2.0과 지능에 따른 제품 진화

2.1. IDE와 Agent Manager의 분리

1. 두 애플리케이션으로 나눈 이유

   1. Antigravity 2.0: Google I/O에서 공개된 Antigravity 2.0은 development environment와 agent manager를 분리했다.
   2. 독립적인 운영: 사용자는 코딩 IDE를 열지 않고도 Agent Manager를 standalone application으로 실행해 프로젝트와 에이전트를 조정할 수 있다.

2. Agent Manager가 제공하는 표면

   1. 통합 관제 공간: 에이전트와 프로젝트를 관리하는 control center이면서 sub-agents, 새 templates, worktrees를 함께 다룬다.
   2. 자동화 기능: scheduled tasks와 sound mode 같은 요소가 포함되어, 단순한 채팅 창이 아니라 작업을 계속 관찰하고 실행하는 운영 공간을 만든다.

2.2. “Scaling with intelligence”의 연대기

1. 2022년: 모델의 처리 범위에 맞춘 보조 기능

   1. 당시의 기능: autocomplete와 chat sidebar가 중심이었고, 모델이 처리할 수 있는 범위가 제한적이어서 기능을 많이 넣는 것이 불가피했다.
   2. 구체적 장치: inclusions, rule files, syntax-tree analysis가 모델의 부족한 맥락 처리 능력을 보완했다.

2. 2024년: 단일 응답에서 지능형 에이전트로

   1. 작업 방식의 변화: intelligent agents가 등장하면서 개발자는 한 번의 제안이 아니라 여러 단계를 거치는 조사와 구현을 맡길 수 있게 됐다.
   2. 새로운 기반: MCP protocols, custom tools, permission systems가 에이전트의 외부 세계 접근을 가능하게 했다.

3. 2025년: 여러 에이전트의 병렬 관리

   1. Agent Manager의 등장: 사용자가 여러 agents를 동시에 병렬로 관리하는 패턴이 Antigravity와 유사한 제품들에서 자리 잡았다.
   2. 운영 요소의 확장: skills, hooks, artifacts가 2025년의 핵심 building blocks가 됐다.

4. 2026년: Agent Teams의 시대

   1. 새 기본 단위: sub-agents, generative user interfaces, helper agents가 2026년 제품을 구성하는 후보가 된다.
   2. 판단 기준: 새 기능은 현재 모델의 부족함을 가리는 임시 장치가 아니라, 다음 모델의 지능이 커질 때 더 큰 확장성을 만들어야 한다.

2.3. 어려운 제품 결정을 통해 얻은 교훈

1. 터미널 접근 권한을 열기

   1. 초기의 두려움: 모델이 전체 소프트웨어 데이터베이스를 지우고 스타트업을 망칠 수 있다는 우려 때문에 터미널 접근은 위험한 선택으로 보였다.
   2. 모델·권한 시스템의 진화: permission systems 같은 안전 장치를 마련하고 모델이 좋아지자 사용자는 더 빠르게 작업하면서도 안전하게 실행할 수 있었다.
   3. 핵심 교훈: 지능이 커진 모델은 무엇을 실행해야 하고 실행하면 안 되는지 더 잘 판단하므로, 모든 명령을 제품이 미리 대신 결정할 필요가 줄어든다.

2. Windsurf에서 chat sidebar를 제거하기

   1. 사용자 반발: 많은 사용자가 익숙하고 좋아하던 chat sidebar를 없애고 proxy만 남긴 결정에 강하게 항의했다.
   2. 새로운 작업 패러다임: 시간이 지나면서 multi-step research, agentic research, agentic implementation이 표준이 됐고, 단순 chat보다 에이전트 제품을 사용하는 방식이 자연스러워졌다.
   3. 제품 결정의 의미: 당장 사랑받는 UI를 유지하는 것이 항상 사용자의 장기 목표를 돕는 것은 아니며, 모델이 변하면 익숙한 인터페이스도 과감히 버려야 한다.

3. IDE와 Agent Manager의 분리

   1. 비유: Agent Manager와 IDE의 관계는 debugger와 development environment의 관계와 비슷하다.
   2. 필요할 때 깊이 내려가기: 개발자는 늘 debugger를 필요로 하지는 않지만, 추상화 계층 안쪽을 조사해야 할 때 debugger가 큰 가치를 제공한다.
   3. 미래에 대한 베팅: agent teams, swarms, software factories 중 어떤 이름을 쓰든 에이전트 조정이 미래라는 판단에 제품 구조를 맞췄다.

3. Agent Teams와 동적 서브에이전트

3.1. Gemini가 팀을 이끄는 구조

1. 제품과 모델의 상호작용

   1. Antigravity 1.0: 핵심은 parallel agent management였고, 사람은 driver’s seat에서 각 에이전트를 직접 조정했다.
   2. 모델의 학습: Antigravity를 통해 Gemini가 agent team을 관리하는 방법을 익혔으며, 이 product-model relationship이 Google DeepMind 내부의 장점이 됐다.

2. Gemini 3.5 Flash의 역할

   1. 출시 시점과 능력: 2026년 4월 공개된 Gemini 3.5 Flash는 일반 작업 수행뿐 아니라 팀을 이끄는 능력을 보여줬다.
   2. 속도·비용·지능의 균형: 더 빠르고 저렴하면서 지능과 실행 속도·비용 사이의 Pareto curve를 밀어, 더 많은 에이전트를 실용적으로 운영할 수 있게 했다.
   3. 남은 과제: multi-agent system은 아직 더 협력적이고, 작업을 더 작은 단위로 분해하며, 팀 구성원끼리 더 잘 소통할 여지가 많다.

3.2. /teamwork로 시작하는 에이전트 팀

1. 사용자와 lead agent의 역할

   1. 작업 정의: 사용자가 목표를 정의하며, 요청이 구체적일수록 좋은 결과를 얻지만 에이전트가 더 많은 정보가 필요하면 사용자에게 질문할 수 있다.
   2. 팀 조정: lead agent는 팀 규모를 정하고 작업을 분해해 완료까지 관리한다.

2. 동적으로 만들어지는 전문 역할

   1. 전문성의 예시: front-end engineer, back-end engineer, infrastructure specialist, quality assurance designer 등 다양한 역할을 조합할 수 있다.
   2. 독립적 실행: 각 sub-agent는 작업 중 동적으로 생성되고 독립적으로 실행된다.
   3. 모델 선택: sub-agent는 main agent와 다른 model을 사용할 수 있으며, 어떤 모델을 배정할지는 main agent가 작업에 맞춰 결정한다.
   4. 확장 방식: 사람이 모든 역할을 미리 등록하는 대신 모델의 판단으로 팀 구성이 달라지므로, 지능이 높아질수록 더 정교한 팀을 만들 수 있다.

3.3. 생성형 UI로 팀의 상태를 표현하기

1. 필요할 때 즉시 생성되는 화면

   1. 상태 질문: 사용자가 “내 작업의 상태는 무엇인가?”라고 묻거나 “진행 상황을 Kanban board로 보여 달라”고 요청하면 모델이 즉석에서 적합한 화면을 만든다.
   2. 시간 흐름 표현: Chrome의 error-correction tool처럼 timeline이 유용한 문제에는 타임라인 화면을 생성한다.

2. 실험 프로젝트의 사례

   1. 브라우저 이미지 편집기: 수백 개의 sub-agents가 약 반나절 동안 협력해 raw images를 브라우저에서 직접 편집하는 image editor를 만들었다.
   2. 메시징 앱: 같은 방식으로 방 안의 참석자에게 익숙한 형태의 messaging app을 만들었다.
   3. 고정 템플릿의 한계 탈피: 모델이 작업에 필요한 화면을 생성하므로 모든 기능에 미리 전용 UI를 만들어 둘 필요가 없다.

4. OS 커널과 연구 자동화가 보여준 확장성

4.1. Doom을 실행하는 OS 커널 구축

1. 극단적인 검증 과제

   1. 목표: Google I/O에서 완전히 새로운 operating system kernel을 처음부터 구축하고 그 위에서 Doom을 실제로 실행했다.
   2. 시연: Kevin Hou의 동료 Varun이 Google I/O에서 결과를 시연했다.

2. 규모와 비용

   1. 에이전트 수와 시간: 93개 sub-agents가 12시간 동안 작업했다.
   2. 처리량: 15,000개의 명령을 처리하고 2 billion tokens를 사용했다.
   3. 비용: 총비용은 1,000달러 미만이었다.

3. 제품 설계에 주는 증거

   1. 지능으로 확장하기: 모델과 sub-agent 수를 늘리면 Gemini 3.5 Flash가 매우 강력하면서도 확장 가능하고 비교적 저렴하게 복잡한 소프트웨어를 만들 수 있다.
   2. 일상적인 비용 판단: 매일 수천 달러를 들여 OS 커널을 만들 필요는 없지만, 이 사례는 필요할 때 지능과 병렬성을 투입할 수 있는 기반의 가치를 증명한다.

4.2. DeepMind 내부 평가 분석 자동화

1. 기존 평가 workflow

   1. 비교 작업: 여러 실험의 결과를 control group과 experiment 표로 나누고, 단순한 차이뿐 아니라 차이가 생긴 이유까지 찾아야 한다.
   2. 반복 개선: 원인을 알아낸 뒤 다음 실험에서 더 나은 버전을 만들 수 있도록 가설과 변경점을 정리해야 한다.
   3. 수작업의 부담: 전통적으로 Jupyter Notebook에서 데이터를 읽고 비교하며 결과를 분석하는 작업이 많은 시간을 차지했다.

2. 자연어와 내부 지식의 결합

   1. 90% 자동화: 연구 그룹은 relevant assessments를 자연어로 요청하는 것만으로 평가 분석 workflow의 약 90%를 자동화했다.
   2. 조직 지식의 활용: agent가 Google의 거대한 Mono Repo에 대한 skills와 이해를 갖추면서 데이터를 처리하고 실험 간 차이를 설명할 수 있게 됐다.

3. 100개 가설의 병렬 탐색

   1. 전문 연구 agent: 단순히 차이를 반환하는 데 그치지 않고, 차이를 만든 이유에 대한 100개의 서로 다른 hypotheses를 제안한다.
   2. 가설별 분업: 각 hypothesis를 하나의 sub-agent에 배정해 특정 원인을 병렬로 조사한다.
   3. 연구자에게 전달: 조사 결과를 하나의 응답에 연결하고, 연구자가 검토할 수 있는 report로 정리한다.

4. 생성형 보고서 인터페이스

   1. 상호작용성: report는 텍스트로 끝나지 않고 dropdown, filter, segment, 탐색 기능을 가진 generative UI로 제공된다.
   2. 사용자별 이해 방식: 결과를 풍부하게 보여 주어 사용자가 자신의 학습 방식에 맞게 데이터를 살피고 성공·실패 원인을 찾을 수 있다.
   3. 기존 엔지니어링 대비: 과거에는 asynchronous proxy suite를 만들고 evaluator와 data pipeline을 연결해야 했지만, 이제는 동적 sub-agent와 생성형 UI라는 기본 단위로 재구성할 수 있다.

5. 사용자의 작업 방식

   1. 준비물: 사용자는 skills file을 업로드하고 자연어로 질문을 시작하면 된다.
   2. 운영 중 재구성: sub-agent 구성과 UI는 미리 고정되지 않으며, 작업 도중 결과와 필요에 따라 새롭게 만들어지고 수정된다.

5. 2026년의 세 가지 기본 building blocks

5.1. Dynamic Sub-agents

1. 서로 다른 임시 팀원

   1. 비동일성: 두 sub-agent가 완전히 동일한 경우는 없으며, 각각의 목표·맥락·권한·전문 역할에 맞춰 만들어진다.
   2. 중앙 조정: main agent가 모든 sub-agent를 조정하고, 작업 중 필요한 데이터와 방향을 준비해 제공한다.

2. 안전하고 병렬적인 실행

   1. 실행 환경: sub-agent는 격리된 sandbox나 remote execution system 등 서로 다른 secure environment에서 실행될 수 있다.
   2. 전문화: 가능한 역할의 수에는 사실상 제한이 없으며, 여러 역할이 동시에 작업할 수 있다.
   3. 지능의 선순환: 모델이 더 똑똑해질수록 팀은 더 전문적이고 협력적으로 변하고, 사용자를 대신해 더 복잡한 문제를 해결한다.

5.2. Sidecars

1. 외부 세계를 듣는 장기 실행 프로세스

   1. 정의: Sidecar는 주 프로세스 옆에서 동작하는 추가 protocol이자 long-term listening tool이다.
   2. 트리거 준비: 외부에서 사건이 발생하면 모델이 반응할 수 있도록 이벤트를 계속 듣고 자체 trigger를 준비한다.

2. 지원할 이벤트와 Antigravity의 활용

   1. 이벤트 종류: short text message, webhooks, scheduled tasks(cron jobs), GitHub pull requests 등으로 확장할 수 있다.
   2. 기존 기능의 기반: Antigravity의 scheduled task 기능은 이미 Sidecar 개념을 시간 기반 작업에 사용한다.
   3. 공개 계획: Sidecar specification을 공개해 사용자가 새로운 확장 요소를 만들 수 있도록 하며, 발표 시점 기준 그해 여름 공개를 예고했다.

5.3. Generative User Interface

1. 고정된 UI를 넘어서는 속도

   1. 모델 출력 속도: Gemini Flash는 Antigravity 안에서 초당 약 900 symbols를 생성하며, 여러 선도적인 prototype trial보다 약 10배 빠르다.
   2. 아이디어에서 화면까지: 머릿속 아이디어를 text prompt로 바꾸고, 몇 초 안에 대화 인터페이스에 통합된 목적별 use case로 전환한다.

2. 템플릿·HTML 대신 대화 속 UI

   1. 생성 방식: Antigravity는 미리 만든 template이나 HTML file에 의존하지 않고 conversation 안에서 필요한 user interface를 직접 생성한다.
   2. 표현 범위: Doom 같은 게임뿐 아니라 bar chart, graph, table 등 텍스트보다 깊이 탐색해야 하는 모든 인터랙티브 표현을 만들 수 있다.

3. Steve Jobs의 iPhone 비유

   1. 고정 키보드의 문제: Steve Jobs는 iPhone을 공개하며 “필요하든 아니든 키보드가 항상 붙어 있고, 모든 앱에서 같은 고정 플라스틱 버튼을 쓴다”는 점을 지적했다.
   2. 동적 제품의 대응: 에이전트의 요구에 맞춰 UI가 확장되는 제품은 고정된 plastic frame에 제한되지 않는다.
   3. 설계 방향: 무거운 infrastructure와 기계적인 user interface 대신 utilities와 generative user interfaces를 사용해 모델의 능력에 맞춰 제품 표면을 바꾼다.

주요 발언 모음

“Give the ball to Messi and get out of his way.”

“Large language models are no longer just minor players; they can be the star of your team if you build the right product around them.”

“As the model improves, your product should also improve.”

“We are not fixed in plastic.”

“The smarter the model becomes, the more specialized and collaborative your team will become.”

핵심 데이터 & 수치

• 2025년 11월: Google Antigravity가 technical·non-technical 사용자를 위한 agent-based programming product로 출시됐다.
• 2022 → 2024 → 2025 → 2026: autocomplete/chat sidebar → intelligent agent → agent manager → agent teams로 핵심 제품 단위가 이동했다.
• Gemini 3.5 Flash: 2026년 4월 공개된 모델로, 작업 수행뿐 아니라 agent team 리딩을 목표로 한다.
• OS kernel 실험: 93개 sub-agents, 12시간, 15,000개 명령, 2 billion tokens, 1,000달러 미만의 비용으로 Doom 실행 커널을 구축했다.
• 평가 분석 자동화: DeepMind 연구 그룹이 자연어 요청으로 기존 수작업 평가 workflow의 약 90%를 자동화했다.
• 가설 탐색: 전문 research agent가 100개 가설을 만들고 가설마다 sub-agent를 병렬 배정했다.
• 생성형 UI 속도: Gemini Flash가 Antigravity에서 초당 약 900 symbols를 생성하며, 여러 선도 prototype trial보다 약 10배 빠르다.

결론 및 시사점

1. 가장 단순한 기반에서 시작한다: 모델, 파일 시스템, 목표처럼 모델이 이미 잘 아는 표준 인터페이스를 먼저 제공하고, 복잡성은 필요성이 입증될 때만 추가한다.
2. 모델의 능력을 제품의 상한으로 만들지 않는다: 현재 모델을 보호하기 위한 guardrail·custom tool·고정 workflow가 다음 모델의 능력을 막지 않는지 매 릴리스마다 점검한다.
3. 탐색적 문제와 정의된 workflow를 구분한다: 정해진 이메일 템플릿이나 보고서 형식처럼 제약이 본질인 문제에는 구조를 유지하되, 탐색적 문제에는 파일 시스템과 bash 같은 범용 도구를 열어 둔다.
4. 전문 역할은 동적으로 만든다: 미리 모든 에이전트를 설계하기보다 lead agent가 작업을 분해하고 필요한 모델·권한·실행 환경을 선택하게 한다.
5. 외부 이벤트를 Sidecar로 연결한다: 메시지·webhook·cron·GitHub pull request를 장기 실행 listener로 연결하면 사용자가 매번 작업을 시작하지 않아도 된다.
6. UI를 모델의 출력물로 취급한다: 모든 사용 사례를 고정 HTML과 템플릿으로 구현하기보다 대화 맥락에서 필요한 차트·표·보드·타임라인을 생성한다.
7. 기능 추가보다 다음 모델과의 호환성을 우선한다: 새 기능은 출시 당시의 데모를 채우는 데 그치지 않고 모델이 더 빠르고, 더 싸고, 더 똑똑해질 때 제품의 가치도 함께 커져야 한다.
8. 성공 지표를 실제 결과로 측정한다: 많은 agent와 token을 쓰는 것이 목적이 아니라, OS kernel·평가 분석처럼 이전에 사람이 하던 복잡한 결과를 시간·비용·품질 기준으로 달성하는지 확인한다.

Kevin Hou는 TPU processor crisis가 해결될 때까지 발표용 칩을 계속 사용하겠다는 농담으로 마무리하고, @kevinhou22를 통한 피드백과 Antigravity 부스에서의 대화를 요청했다. 제품 개발자는 모델을 대신해 생각하는 장치를 계속 덧붙이기보다, 모델이 더 나아질 때 스스로 확장되는 기반을 먼저 만들어야 한다.

핵심 요약 (20줄)

1. Kevin Hou는 89분의 경기에서 메시에게 공을 주고 길을 비키는 비유로 AI 제품 설계의 방향을 설명한다.
2. 대규모 언어 모델은 보조 선수가 아니라 올바른 제품을 만나면 팀의 스타가 되는 주체다.
3. Google Antigravity는 기술·비기술 사용자를 위한 에이전트 기반 프로그래밍 제품이다.
4. Antigravity는 2025년 11월 출시된 뒤 여러 에이전트를 관리하고 조정하는 플랫폼으로 확장됐다.
5. Antigravity 2.0은 개발 환경과 Agent Manager를 분리해 에이전트 조정을 독립 애플리케이션으로 만들었다.
6. Agent Manager에는 서브에이전트, 템플릿, worktree, scheduled task, sound mode가 함께 들어간다.
7. 2022년의 자동완성과 chat sidebar는 당시 모델의 한계를 보완하기 위한 고정 장치였다.
8. 2024년에는 MCP protocol, custom tool, permission system을 갖춘 지능형 에이전트가 개발 방식을 바꿨다.
9. 2025년의 핵심 단위가 agent manager와 skills·hooks·artifacts였다면 2026년은 agent team의 시대다.
10. Gemini 3.5 Flash는 작업 수행뿐 아니라 팀을 이끌고 역할을 배정하는 능력을 보여준다.
11. Antigravity의 /teamwork 명령은 lead agent가 목표를 분해하고 전문 서브에이전트를 동적으로 만드는 모드다.
12. 각 서브에이전트는 독립적으로 실행되며 main agent와 다른 모델과 보안 환경을 사용할 수 있다.
13. 생성형 UI는 사용자의 질문에 맞춰 Kanban board, timeline, 차트, 표를 대화 중 즉시 만든다.
14. 수백 개 서브에이전트는 반나절 만에 브라우저 이미지 편집기와 messaging app을 구축했다.
15. 93개 서브에이전트는 12시간 동안 15,000개 명령과 2 billion tokens를 사용해 Doom을 실행하는 OS 커널을 만들었다.
16. Google DeepMind 연구 그룹은 자연어 요청과 내부 저장소 지식으로 평가 분석의 약 90%를 자동화했다.
17. 전문 research agent는 실험 차이의 원인을 찾기 위해 100개 가설을 만들고 가설별 조사를 병렬화한다.
18. Sidecar는 메시지, webhook, cron, GitHub pull request를 듣고 에이전트의 트리거를 준비하는 장기 실행 프로토콜이다.
19. Gemini Flash의 생성형 UI는 초당 약 900 symbols를 출력해 고정 HTML과 템플릿의 필요를 줄인다.
20. 다음 모델의 지능이 커질수록 좋아지는 단순한 기반을 만들고, 제품이 모델의 길에서 비켜서야 한다.