프레임워크는 더 이상 인간만을 위해 설계되지 않는다

이 글은 Google I/O Writing Challenge를 위한 제출물입니다.

요약 (TL;DR)
Google I/O 2026 세션들을 시청한 후, 저는 Flutter, Search, Chrome DevTools, 그리고 Google의 에이전트 워크플로우(agent workflows) 전반에서 동일한 패턴을 발견하기 시작했습니다. AI는 단순히 애플리케이션의 일부가 되는 것에 그치지 않습니다. 프레임워크(Frameworks), 툴링(tooling), 그리고 웹 자체조차도 능동적인 빌더(builders)로서 AI 시스템을 중심으로 서서히 진화하기 시작하고 있습니다.

예상 읽기 시간: 약 8분

목차

• 올해는 모델에 관한 것이라고 생각했다
• 나머지 I/O를 바라보는 관점을 바꿔놓은 Flutter 업데이트
• 우리는 사람을 위한 인터페이스를 구축해 왔다
• Search는 소프트웨어 생성(software generation)과 더 유사하게 동작하기 시작하고 있다
• 인간 클립보드 문제 (The Human Clipboard Problem)
• 웹사이트들도 변하고 있다
• 이 모든 것의 밑바닥에 깔린 긴장감
• 개발자들이 실제로 적응해야 할 것
• 마지막 생각
• 참고 문헌

🤝 계속 소통하기

올해는 모델에 관한 것이라고 생각했다
모든 Google I/O는 결국 동일한 주제로 돌아옵니다. 더 나은 모델. 더 빠른 응답. 더 유능한 AI 시스템. 그래서 제가 Google I/O 2026 세션을 시청하기 시작했을 때, 저는 그 이야기의 또 다른 버전을 기대했습니다. 그리고 그런 내용도 충분히 있었습니다. 하지만 다음을 시청한 후에는:

Google I/O '26 키노트 (Keynote)
개발자 키노트 (Developer Keynote (Google I/O '26))
Flutter의 새로운 기능 및 Google AI 세션

다른 모든 것의 밑바닥에서 또 다른 패턴이 서서히 나타나기 시작했습니다. 하나의 주요 발표를 통해서도, 하나의 헤드라인 기능(headline feature)을 통해서도 아니었습니다. 그것은 서로 다른 세션에 걸쳐 퍼져 있는 더 작은 아키텍처적 결정(architectural decisions)들을 통해 나타났습니다. 처음에는 그 중 어느 것도 서로 연결된 것처럼 보이지 않았습니다. 그러다 Flutter 세션에서 Material과 Cupertino를 핵심 프레임워크(core framework)로부터 분리하는 것에 대해 이야기하기 시작했습니다. 그 후, 저는 다른 모든 곳에서도 동일한 아이디어를 발견하기 시작했습니다.

나머지 I/O를 바라보는 관점을 바꿔놓은 Flutter 업데이트
표면적으로 Flutter 발표는 프레임워크 유지보수처럼 들렸습니다. Material과 Cupertino가 별도의 패키지(packages)가 되는 것. 더 스타일 중립적인(style-neutral) Flutter 코어. GenUI SDK. A2UI 프로토콜. 하지만 들으면 들을수록, 그것은 평범한 프레임워크 작업처럼 들리지 않았습니다.

왜냐하면 UI 프레임워크는 설계 단계부터 항상 특정한 방식(opinionated)을 따르도록 만들어졌기 때문입니다. 그것이 프레임워크의 역할입니다. 프레임워크는 개발자가 구조와 일관성을 갖출 수 있도록 안내합니다. 수년 동안 프론트엔드 개발은 대부분 동일한 모델을 따라왔습니다. 개발자가 인터페이스를 먼저 설계하고, 사용자는 나중에 그것과 상호작용합니다. 화면은 이미 결정되어 있습니다. 흐름도 이미 결정되어 있습니다. 심지어 동적인 애플리케이션조차도 대개 인간이 조립한 사전 정의된 레이아웃(predefined layouts)을 기반으로 구축됩니다. 하지만 Google I/O 2026의 많은 발표는 다른 방향으로 움직이는 것처럼 보였습니다. 맥락(context)에, 대화(conversation)에, 의도(intent)에, 환경(environment)에, 그리고 그 순간 일어나고 있는 작업(task)에 적응하는 인터페이스 말입니다. 고정된 화면이 아니라, 생성된(generated) 화면입니다. 그리고 이것은 프레임워크 자체의 밑바닥을 변화시킵니다. 소프트웨어가 인터페이스를 동적으로 생성할 것으로 기대된다면, 프레임워크는 사전 정의된 인간의 레이아웃을 중심으로 엄격하게 구조화된 상태로 남아있을 수 없기 때문입니다. 프레임워크는 소프트웨어가 소프트웨어를 조립할 수 있을 만큼 충분히 유연해져야 합니다. 그것이 I/O의 나머지 세션들이 저에게 다르게 보이기 시작한 순간이었습니다. 이러한 깨달음의 대부분은 'What's New in Flutter' 세션을 시청하면서 얻었습니다. 해당 세션은 GenUI, A2UI, 그리고 Flutter가 사전 정의된 디자인 시스템(design systems)에 밀접하게 결합되는 대신, 스타일 중립적(style-neutral)으로 변모하는 것에 대해 상당한 시간을 할애합니다. 영상을 보면 볼수록, 이것은 일반적인 프레임워크 업데이트라기보다 Flutter가 동적으로 생성되는 인터페이스를 위해 준비하는 과정처럼 들렸습니다. 우리는 과거에 사람을 위해 인터페이스를 구축했습니다. 여러 세션을 통해 더욱 분명해진 것은, 대부분의 소프트웨어 도구들이 얼마나 깊게 인간 중심적(human-centered)이었는가 하는 점입니다. 컴포넌트 시스템(Component systems). 디자인 시스템(Design systems). 네비게이션 패턴(Navigation patterns). 접근성 흐름(Accessibility flows). 모든 것이 인간이 인터페이스를 어떻게 읽고, 탐색하고, 해석하고, 훑어보고, 시각적으로 이동하는지를 중심으로 구축되었습니다. 하지만 이제 시스템 내부에는 또 다른 참여자가 있습니다. 바로 에이전트(Agents)입니다. 그리고 그들은 소프트웨어와 다르게 상호작용합니다. AI 에이전트는 버튼이 화면상에서 시각적으로 균형 잡혀 보이는지 따위에는 관심이 없습니다.

그것(AI 에이전트)이 관심을 갖는 것은 다음과 같습니다: 구조 (structure), 상호작용 지점 (interaction points), 기능 (capabilities), 의미론적 의미 (semantic meaning), 기계가 읽을 수 있는 워크플로 (machine-readable workflows), 접근 가능한 경로 (accessible pathways). 이는 프레임워크가 무엇을 최적화해야 하는지를 변화시킵니다. 인간을 대체하는 것이 아니라, 인간과 에이전트를 동시에 지원하는 것입니다. 그리고 저는 이것이 올해 I/O 발표 내용 중 가장 큰 변화 중 하나일 수도 있다고 생각합니다. 처음으로 프레임워크가 더 이상 전적으로 인간 우선 (human-first)으로 느껴지지 않았습니다. Google은 AI가 소프트웨어를 구축하는 방법만을 보여준 것이 아니었습니다. 세션을 더 많이 시청할수록, AI 시스템이 소프트웨어 생태계 내부의 능동적인 참여자가 됨에 따라 소프트웨어 생태계 자체가 서서히 재편될 수도 있겠다는 느낌이 들기 시작했습니다. 검색 (Search)은 점점 더 소프트웨어 생성 (software generation)과 유사하게 동작하기 시작했습니다. Google I/O '26 기조연설에서 제가 계속해서 다시 보게 된 순간 중 하나는, 검색이 결과 내에서 직접 상호작용 가능한 소프트웨어 경험을 생성하는 것을 지켜보는 것이었습니다. 단순한 요약이나 응답이 아니었습니다. 실제로 사용 가능한 인터페이스였습니다. 플래너 (planner), 시뮬레이터 (simulator), 생성된 워크플로 (generated workflow)와 같은 것들 말입니다. 중요한 부분은 인터페이스 그 자체가 아니라, 그것을 만들어낸 것이었습니다. 전통적으로 개발자는 애플리케이션을 구축했고, 검색 엔진은 사용자가 이를 발견하도록 도왔습니다. 이제는 플랫폼 자체가 특정 상황을 위해 소프트웨어 경험을 동적으로 생성하기 시작했습니다. 영구적인 애플리케이션이 아니라, 일시적인 것들입니다. 정확히 필요한 순간을 위해 생성된 소프트웨어 말입니다. Google I/O '26 기조연설 중에 보여준 예시들은 아마도 이러한 방향을 이해할 수 있는 가장 명확한 방법일 것입니다. 검색이 실시간으로 상호작용 가능한 플래너와 시각적 시뮬레이터를 생성하는 것을 보는 것은 전통적인 검색 데모와는 매우 다르게 느껴졌습니다. 그것은 상호작용 과정 중에 소프트웨어가 조립되는 것에 더 가깝게 느껴졌습니다. 그리고 소프트웨어가 이와 같이 동작하기 시작하면, 그 밑단의 프레임워크 또한 변해야 합니다.

인간 클립보드 문제 (The Human Clipboard Problem)
제가 계속해서 생각하게 된 또 다른 순간은 에이전트를 위한 Chrome DevTools (Chrome DevTools for Agents)에서 나왔습니다. 주로 AI 도구를 사용하는 거의 모든 개발자가 이미 알고 있는 워크플로를 다루었기 때문입니다. AI에게 코드를 생성해 달라고 요청합니다. 무언가 망가집니다.

에러를 복사합니다. 어시스턴트(Assistant)에 다시 붙여넣습니다. 또 다른 응답을 기다립니다. 그리고 이 사이클을 다시 반복합니다. 개발자는 런타임(Runtime), 브라우저, 툴링(Tooling), 그리고 AI 시스템 사이의 연결 고리가 됩니다. 하지만 이제 에이전트(Agent)는 다음과 같은 일을 할 수 있습니다: DOM 검사, Lighthouse 감사 실행, 에러 로그 읽기, 수정 시도, 변경 사항 자체 검증. 이는 개발자의 역할 또한 변화시킵니다. AI 시스템이 툴링과 직접 상호작용할 수 있게 되면, 더 이상 수동적인 어시스턴트처럼 행동하지 않기 때문입니다. 그들은 워크플로(Workflow) 자체에 참여하기 시작합니다. 이 부분은 Developer Keynote (Google I/O '26), 특히 Chrome DevTools for Agents 시연에서 가져온 내용입니다. 해당 세션은 저에게 이번 행사 전체에서 가장 실질적인 변화 중 하나를 소개했는데, 이는 주로 AI가 디버깅 및 런타임 툴링 자체와 상호작용하는 방식을 바꾸기 때문입니다. 웹사이트 또한 변화하고 있습니다. WebMCP에서도 동일한 패턴이 다시 나타났습니다. 웹의 역사 대부분 동안 웹사이트는 거의 전적으로 인간의 상호작용을 위해 설계되었습니다. 인간은 메뉴를 탐색하고, 버튼을 누르고, 레이아웃을 읽고, 인터페이스를 시각적으로 이동합니다. 하지만 WebMCP는 웹사이트가 에이전트에게도 기능을 직접 노출해야 한다는 개념을 도입합니다. 시각적인 방식이 아닌, 구조적인(Structurally) 방식입니다. Developer Keynote에서는 이를 "에이전트 경험 (Agent Experience)"을 개선하는 것이라고 언급했습니다. 이에 대해 생각하면 할수록, 그 문구가 점점 더 중요하게 느껴지기 시작했습니다. 소프트웨어 생태계가 에이전트를 위해서도 최적화를 시작하면, 인터넷 자체가 다른 무언가로 변하기 시작하기 때문입니다. 단순히 인간이 읽을 수 있는(Human-readable) 것을 넘어, 훨씬 더 깊은 방식으로 기계가 읽을 수 있는(Machine-readable) 것이 됩니다. WebMCP와 "에이전트 경험 (Agent Experience)"에 관한 논의 역시 Developer Keynote (Google I/O '26)에서 나왔습니다. 저는 세션의 그 부분으로 계속 되돌아가게 되는데, 에이전트가 일반적인 소프트웨어 워크플로의 일부가 될 때 웹 자체가 어떻게 동작할 것으로 기대되는지를 바꾸기 때문입니다.

이 모든 것의 이면에 깔린 긴장감이 디자이너가 사라진다거나, 프론트엔드 개발자 (frontend developers)가 사라진다거나, 혹은 인터페이스가 예측 불가능한 AI 생성 혼돈 (AI-generated chaos)이 된다는 것을 의미한다고 생각하지 않습니다. 실제로 이번 발표들 전반에서 가장 흥미로운 부분 중 하나는 유연성 (flexibility)과 일관성 (consistency) 사이의 긴장이었습니다. 생성된 인터페이스 (Generated interfaces)는 동적으로 적응할 수 있기 때문에 강력합니다. 하지만 사람들은 여전히 다음과 같은 요소들에 의존합니다: 친숙함 (familiarity), 안정적인 내비게이션 (stable navigation), 예측 가능한 상호작용 패턴 (predictable interaction patterns), 일관된 시각적 시스템 (consistent visual systems). 이 긴장은 중요합니다. 왜냐하면 완전히 제한이 없는 생성된 인터페이스는 매우 빠르게 피로감을 줄 것이기 때문입니다. 그리고 Google은 세션 내내 그 점을 인지하고 있는 것처럼 보였습니다. 그 방향성은 "구조를 완전히 제거한다"는 느낌이 아니었습니다. 오히려 "신중하게 정의된 경계 (carefully defined boundaries) 내에서 소프트웨어가 적응할 수 있도록 허용한다"는 느낌에 가까웠습니다. 이는 매우 다른 아이디어이며, 아마도 훨씬 더 실용적인 아이디어일 것입니다.

개발자들이 실제로 적응해야 할 것

여기서 가장 큰 변화가 AI가 더 많은 코드를 생성할 것이라는 점이라고 생각하지 않습니다. 그 논의는 이미 어디에나 존재합니다. 더 흥미로운 변화는 소프트웨어 생태계 (software ecosystems) 자체가 AI 참여 (AI participation)를 중심으로 진화하기 시작했다는 점입니다. 프레임워크 (Frameworks)는 더 유연해지고 있습니다. 개발자 도구 (Developer tools)는 에이전트 인식형 (agent-aware)이 되고 있습니다. 웹 표준 (Web standards)은 기계 판독 가능 (machine-readable)해지고 있습니다. 인터페이스는 동적 (dynamic)으로 변하고 있습니다. 그리고 개발자들은 아마도 다음과 같이 시간을 점진적으로 다르게 쓰게 될 것입니다:

정적인 화면을 수동으로 조립하고, 반복적인 워크플로 (workflows)를 연결하며, 도구와 AI 시스템 사이의 가교 역할을 하는 데 쓰는 시간은 줄어들고,

경계를 정의하고, 프리미티브 (primitives)를 설계하며, 동작을 형성하고, 생성된 시스템을 검토하며, 적응형 워크플로 (adaptive workflows)를 가이드하는 데 더 많은 시간을 쓰게 될 것입니다.

이것은 매우 다른 소프트웨어 개발 모델처럼 느껴집니다. 완전히 자동화된 것은 아니지만, 우리 대부분이 배웠던 모델과는 확실히 다릅니다. 왜냐하면 가장 큰 변화는 AI가 소프트웨어 개발을 대체하는 것이 아니라, 소프트웨어 생태계가 AI 참여를 중심으로 천천히 재편되는 것일 수 있기 때문입니다.

마치며

Google I/O 2026으로 넘어가며, 저는 더 나은 AI 시스템을 기대했습니다.

제가 예상하지 못했던 것은, 얼마나 많은 세션이 그 이면에 있는 동일하고 더 깊은 변화를 가리키고 있었는가 하는 점이었습니다. Flutter가 더욱 스타일 중립적 (style-neutral)으로 변모하는 것, 검색이 인터페이스를 동적으로 생성하는 것, 웹 표준 (Web standards)이 에이전트 (agents)에게 직접적으로 기능을 노출하는 것, 그리고 개발자 도구 (Developer tooling)가 자율적 워크플로우 (autonomous workflows)를 중심으로 진화하는 것 말입니다. 개별적으로 보면 이러한 발표들은 서로 관련이 없어 보였습니다. 하지만 이들이 모였을 때, 마치 동일한 전환의 조각들처럼 느껴지기 시작했습니다. 수년 동안 프레임워크는 거의 전적으로 인간 개발자가 인간 사용자를 위한 인터페이스를 구축하는 것을 중심으로 설계되었습니다. 이제 소프트웨어 생태계는 AI 시스템을 중심으로도 진화하기 시작했습니다. 그리고 저는 미래의 개발자들이 이 순간을 "AI가 더 똑똑해진 해"라기보다는, "소프트웨어 생태계가 AI 참여를 중심으로 스스로를 재편하기 시작한 해"로 기억할 것이라고 생각합니다.

참고 문헌 (References)
이 세션들은 이 글의 대부분의 아이디어와 관찰을 형성하는 데 도움이 되었습니다:
Google I/O '26 Keynote
Developer Keynote (Google I/O '26)
What's New in Flutter

AI 워크플로우, 도구, 그리고 인터페이스 생성에 관한 더 넓은 방향을 고민하는 동안 다음 세션들도 유용하다고 느꼈습니다:
What's New in Google AI
What's New in Firebase

I/O 메인 스테이지에서 터미널까지
🤝 연락처 (Stay in Touch)
찾아오실 곳
GitHub에서 무언가를 만드는 중 → hemapriya-kanagala
LinkedIn 리소스 및 업데이트 → hemapriya-kanagala
X의 무작위 개발 생각 → @KanagalaHema

그리고 진심으로, 이 내용 중 이해가 가는 부분(혹은 그렇지 않은 부분)이 있다면 댓글을 남겨주세요.