프론트엔드 생태계를 오래 지켜본 사람이라면 느끼는 게 있어요. "또 라이브러리가 나왔네" 가 아니라, "이번엔 뭘 덜어냈지?" 가 먼저 떠오르는 시점이 왔다는 겁니다. 최근 Hacker News에서 화제가 된 시맨틱 HTML 기반 초경량 UI 라이브러리 Oat, Vue 3 + Tailwind CSS v4로 이메일 에디터를 아토믹 디자인으로 재설계한 MySigMail Card 사례, 그리고 Chrome 146에 실험적으로 탑재된 WebMCP API까지 — 세 가지 흐름을 관통하는 키워드는 명확합니다. "덜어내는 아키텍처(Subtractive Architecture)".
1. 8KB가 증명하는 것: Oat과 '제로 의존성'의 귀환
솔직히 고백하면, Oat의 데모 사이트를 처음 열었을 때 "어, 벌써 로드됐어?" 하고 스크롤을 멈췄습니다. 6KB CSS + 2.2KB JS, gzip 기준 총 8KB. 사용자 입장에서는 탭을 누르는 순간 페이지가 완성되어 있는 느낌이에요. Hacker News 댓글에서도 "채찍처럼 빠르다(snappy as a whip)"는 반응이 나올 정도였죠.
기술적으로 더 인상적인 건 클래스 없이 <button>, <dialog>, <input> 같은 시맨틱 HTML 요소에 직접 스타일을 입히는 방식입니다. role="button"이나 ARIA 속성까지 CSS 셀렉터로 자동 인식하니까, 접근성(a11y)이 "추가 작업"이 아니라 기본값(default)이 됩니다. 키보드 내비게이션, 스크린리더 지원이 빌트인이라는 건 — 솔직히 Tailwind 클래스 수십 개 붙이면서 aria-label 빼먹는 저 같은 사람한테는 뼈 아픈 지적이에요.
물론 현실적인 한계는 있습니다. 댓글에서도 지적됐듯이 시맨틱 요소와 data- 속성, CSS 클래스가 혼재하는 일관성 문제가 보이고, Safari에서 <dialog>의 showModal()이 Chromium 대비 59배 느린 레이아웃 재계산을 유발하는 브라우저 호환성 이슈도 남아있어요. 하지만 Oat이 던지는 메시지는 분명합니다: "프레임워크를 추가하기 전에, 브라우저가 이미 제공하는 걸 먼저 쓰고 있는가?"
2. 프리셋의 함정에서 아톰으로: 아키텍처는 '분해'할수록 유연해진다
MySigMail Card를 만든 Anton Reshetov의 회고는 프론트엔드 아키텍트라면 한 번쯤 겪어봤을 "프리셋 트랩(Preset Trap)"에 대한 이야기입니다. 헤더 블록, 테스티모니얼 블록… 처음엔 빠르게 만들 수 있지만, 이미지를 오른쪽에 놓고 싶으면? 새 블록. 3컬럼이 필요하면? 또 새 블록. 변형이 폭발(Variation Explosion)하면서 개발자 자신이 병목이 되는 구조죠.
해결책은 Block → Row → Cell → Atom으로 이어지는 재귀적 계층 구조였습니다. 이건 Brad Frost의 아토믹 디자인을 이메일 에디터라는 극단적 제약(Outlook의 테이블 기반 렌더링!) 환경에 적용한 실전 사례예요. Vue 3 Composition API + TypeScript로 스키마를 정의하고, Tailwind CSS v4와 Shadcn Vue로 UI를 구성했는데 — 사실 이건 기술 스택 자체보다 "레이아웃과 콘텐츠를 분리한다"는 설계 원칙이 핵심입니다.
Dev.to의 React/TypeScript 스프린트 워크플로우 글도 같은 맥락이에요. 저자는 1~2주 스프린트에서 가장 먼저 하는 일로 "데이터 계약(Data Contract) 잠그기"를 꼽습니다. API 응답 타입을 type Project = { id: string; status: "draft" | "active" | "archived" } 식으로 먼저 고정한 뒤, 컴포넌트는 데이터와 콜백만 받는 순수한 경계를 유지하라는 거죠. 상태관리도 React Query + useState로 시작해서, 필요할 때만 글로벌 상태를 추가하라고 합니다. "추상화를 추가하는 게 아니라 제거할 때 유지보수성이 올라간다" — 이 문장이 계속 머릿속에 남아요.
3. WebMCP: 프론트엔드에서 AI SDK를 '덜어내는' 패러다임
Chrome 146에 실험적으로 들어간 WebMCP API는 이 "덜어내기"의 가장 극단적인 형태입니다. 기존에 프론트엔드에서 AI 기능을 넣으려면? OpenAI SDK 설치하고, API 키 관리하고, 프롬프트 엔지니어링하고, 로딩 상태 처리하고… 번들 사이즈가 눈에 보이게 불어나죠. WebMCP는 이 전체를 뒤집습니다.
개발자는 navigator.modelContext.registerTool()로 "우리 사이트는 이런 기능을 할 수 있어요"만 선언하면 됩니다. AI 모델 선택은 사용자 몫이에요. 로컬 Llama를 쓰든, 클라우드 Claude를 쓰든 — 개발자의 API 비용은 $0. POC 테스트에서 로컬 모델은 10~50ms, 클라우드 모델은 500~1500ms 응답 속도를 보였다고 하는데, 여기서 중요한 건 개발자가 이 레이턴시 차이를 UI로 흡수해야 한다는 점입니다. 로딩 스켈레톤, 옵티미스틱 업데이트, 에러 바운더리… 결국 프론트엔드의 일이 "AI를 통합하는 것"에서 "AI가 호출할 수 있는 깔끔한 도구(tool)를 노출하는 것"으로 바뀌는 거예요.
물론 현실 체크는 필요합니다. 아직 Chrome Canary에서만 동작하고, 'modelContext' in navigator 분기를 태우는 폴백 전략이 필수이며, BYOM(Bring Your Own Model) 환경에서는 사용자 모델의 품질 편차가 엄청나기 때문에 tool description의 정밀도가 곧 API 문서의 품질이 됩니다. 이건 Figma에서 디자인 토큰 네이밍이 곧 개발 커뮤니케이션의 품질이 되는 것과 비슷한 구조예요.
4. 시사점: 2026년, '덜어낸 만큼' 빨라지는 프론트엔드
세 가지 사례를 겹쳐 놓으면 방향이 보입니다.
- 인프라 레이어에서 덜어내기: Oat처럼 프레임워크·빌드 도구·node_modules 의존성을 제거하고, 브라우저 네이티브 기능(시맨틱 HTML, CSS 변수, WebComponents)으로 회귀.
- 아키텍처 레이어에서 덜어내기: 프리셋 블록 대신 아톰 단위로 분해하고, 데이터 계약을 먼저 잠금으로써 컴포넌트 경계를 명확하게.
- AI 통합에서 덜어내기: SDK와 API 키 대신 WebMCP tool 선언만으로 AI 기능을 노출하고, 모델 선택·비용·프라이버시를 사용자에게 위임.
사용자 입장에서는 이 세 겹의 "덜어내기"가 모두 체감 성능으로 수렴합니다. Lighthouse 점수가 올라가고, Core Web Vitals의 LCP·INP가 개선되고, 번들 사이즈가 줄어드는 건 전부 같은 결과거든요. 그리고 이건 단순히 기술적 트렌드가 아니라, "사용자에게 필요하지 않은 복잡성은 아키텍처 부채"라는 인식의 전환이에요.
다만, 모든 프로젝트에 Oat을 쓰라는 이야기는 아닙니다. 복잡한 상태 관리가 필요한 대시보드에 8KB 라이브러리만으로 버틸 순 없죠. 핵심은 "기본값을 가볍게 시작하고, 복잡성은 증명된 필요에 의해서만 추가한다"는 원칙입니다. React Query가 Redux를 대체한 것도, Tailwind가 BEM을 밀어낸 것도 결국 같은 흐름이었잖아요.
2026년 프론트엔드의 경쟁력은 "무엇을 추가했느냐"가 아니라 "무엇을 덜어냈느냐"로 결정될 겁니다. 번들에서 1KB를 빼는 게, 기능을 하나 추가하는 것보다 어렵고 — 솔직히 더 중요한 시대가 오고 있습니다.