지난 10년 동안 "프론트엔드 스택이 무엇인가요?"라는 질문은 매우 무거운 질문이었습니다. jQuery 대 Backbone. Angular 대 React. Webpack 대 그 외 모든 것들. 이러한 변화의 소용돌이는 소모적이었으며, 우리 업무의 상당 부분은 그저 흐름을 따라가는 데 사용되었습니다.

그 시대는 조용히 끝나가고 있습니다. 우리가 프레임워크 전쟁에서 승리했기 때문이 아니라, 질문의 차원이 한 단계 위로 이동했기 때문입니다. 오늘날 프론트엔드의 흥미로운 문제들은 어떤 라이브러리가 리스트를 렌더링하느냐에 관한 것이 아닙니다. 그것은 렌더링(rendering), 데이터(data), 그리고 점점 더 중요해지는 생성(generation)이 어떻게 서로 맞물리는가에 관한 것입니다. 그리고 AI는 바로 그 변화의 중심에 자리 잡고 있습니다.

우리가 인정하는 것보다 더 많이 통합된 스택

2026년에 대부분의 새로운 프로덕션 앱들이 실제로 선택하는 것들을 살펴보십시오:

• React 또는 Svelte/Vue: 컴포넌트 모델을 위해 사용되며, 프레임워크 전쟁은 "하나를 고르세요, 모두 괜찮습니다"라는 수준으로 정리되었습니다.
• 메타 프레임워크 (Meta-framework) — Next, Remix/React Router, SvelteKit, Nuxt — 더 이상 아무도 라우팅(routing), 데이터 로딩(data loading), SSR을 직접 구현하지 않기 때문입니다.
• 기본값으로서의 TypeScript: 논쟁의 여지가 없습니다. 순수 JS(plain-JS) 기반의 신규 프로젝트는 이제 예외적인 사례입니다.
• 서버 우선 렌더링 (Server-first rendering) (RSC, islands, streaming)이 기본값이 되었으며, 클라이언트 번들(client bundle)은 우주의 중심이라기보다는 최소화해야 할 비용으로 취급됩니다.

중심축이 다시 서버 쪽으로 이동했습니다. 하지만 HTML을 스트리밍하고, 선택적으로 하이드레이션(hydrates)하며, 네트워크 경계를 일급 디자인 고려 사항으로 취급하는 '더 스마트한' 서버로 이동한 것입니다. 추는 2010년으로 되돌아간 것이 아니라, 앞으로 나선형을 그리며 전진했습니다.

AI가 실제로 바꾼 것 (그리고 바꾸지 못한 것)

과장된 말들은 "이제 AI가 프론트엔드를 작성한다"라고 합니다. 하지만 현장의 현실은 더 구체적이고 더 흥미롭습니다.

AI는 초기 80%의 비용을 무너뜨렸습니다. 컴포넌트의 스캐폴딩(Scaffolding)을 만들고, 폼(form)을 연결하고, Figma 프레임을 JSX로 변환하고, 레이아웃을 위한 Tailwind를 작성하는 작업들은 과거에는 몇 시간이 걸리던 일이었으나 이제는 몇 분 만에 끝납니다. 이것은 실재하는 변화이며, 이미 팀들이 업무량을 산정하는 방식을 바꾸어 놓았습니다.

마지막 20%는 무너지지 않았습니다. 접근성 (Accessibility) 예외 케이스, 포커스 관리 (focus management), 비동기 상태 (async state)에서의 레이스 컨디션 (race conditions), 기괴한 Safari 버그, 어디에도 기록되지 않은 디자인 시스템 (design-system)의 불변성(invariant) — 이 영역이야말로 여전히 시니어 엔지니어들이 자신의 가치를 증명하는 곳입니다. AI는 그럴싸한 초안을 가져다줄 뿐, 정확한 결과물을 가져다주지는 않습니다. 가치가 상승하고 있는 기술은 바로 **판단력 (judgment)**입니다. 즉, 무엇이 "완료"된 상태인지를 알고, 생성된 코드가 미묘하게 잘못되었을 때 이를 알아차릴 수 있는 능력입니다.

// AI는 기꺼이 이것을 생성할 것입니다.
function Price({ cents }: { cents: number }) {
  return <span>${(cents / 100).toFixed(2)}</span>;
...

중요한 변화: 단순히 작성하는 것이 아니라 생성하는 UI

여기에 진정으로 새로운 아이디어가 있습니다. 수년간 "서버 주도 UI (server-driven UI)"는 백엔드가 레이아웃 설명을 보내면 클라이언트가 이를 렌더링하는 것을 의미했습니다. AI는 이를 한 단계 더 밀어붙입니다. 즉, 미리 작성된 것이 아니라 의도(intent)로부터 요청 시점에 조립되는 (assembled on demand) 인터페이스를 향해 나아갑니다.

우리가 완전히 그 단계에 도달한 것은 아니며, 많은 "생성형 UI (generative UI)" 데모들은 장난감 수준에 불과합니다. 하지만 방향은 명확합니다:

1. 정적 UI (Static UI) — 모든 화면을 수작업으로 작성합니다. (우리가 지나온 방식)
2. 서버 주도 UI (Server-driven UI) — 백엔드가 화면을 설명하고, 클라이언트가 스키마 (schema)를 바탕으로 렌더링합니다.
3. 생성형 UI (Generative UI) — 모델이 디자인 시스템 (design system)의 제약 조건 내에서, 특정 사용자와 컨텍스트에 맞는 컴포넌트 트리 (component tree)를 생성합니다.

오늘날 3번 방식에서 가치를 얻고 있는 팀들은 모델이 픽셀을 마음대로 그리도록(freestyle) 내버려 두지 않습니다. 대신 모델에게 엄격하게 제한된 어휘 (tightly constrained vocabulary) — 즉, 검증된 컴포넌트와 토큰 (tokens)의 고정된 집합 — 를 제공하고, 그 가이드라인 안에서 조합하도록 합니다. 이제 디자인 시스템은 단순한 문서가 아니라, _AI가 계획을 세울 때 준수해야 하는 가드레일 (guardrail)_이 됩니다. 이는 프론트엔드 아키텍처 작업의 많은 부분을 재정의합니다. 여러분의 컴포넌트 API (component API)는 이제 프롬프트 표면 (prompt surface)이기도 합니다.

향후 몇 년간 이것이 의미하는 바

제가 실제로 확신할 수 있는 몇 가지 예측은 다음과 같습니다:

• 컴포넌트 라이브러리가 팀 내에서 가장 가치 있는 자산이 됩니다 — 왜냐하면 인간과 모델 모두가 이를 기반으로 구축하기 때문입니다. 깔끔하고, 타입이 잘 지정되어 있으며(well-typed), 접근성(accessibility)이 뛰어난 디자인 시스템에 대한 투자는 두 배의 보상으로 돌아옵니다.
• 타입(Types)과 계약(contracts)이 승리합니다. 경계(boundaries)가 기계가 읽을 수 있는 형태(TS 타입, 스키마, OpenAPI)일수록, AI는 그 안에서 더 안정적으로 작동할 수 있습니다. 모호함은 생성(generation)의 적입니다.
• 직함의 경계가 모호해집니다. "프론트엔드 엔지니어"는 점점 더 _데이터 페칭(data fetching), 렌더링 전략, AI 보조 저작 루프(AI-assisted authoring loop), 그리고 무엇이 잘못되었는지 판단할 수 있는 심미안(taste)까지 포함하여 경험 전체를 책임지는 제품 엔지니어(product engineer)_를 의미하게 됩니다.
• 리뷰(Reviewing)가 타이핑(typing)을 대체합니다. 병목 현상은 코드를 생성하는 것에서 코드를 _평가(evaluating)_하는 것으로 이동합니다. 코드를 비판적이고 빠르게 읽을 수 없다면, AI 세상에서 당신은 더 빨라지는 것이 아니라 더 느려질 것입니다.

핵심 요약 (The takeaway)

프론트엔드는 자동화되어 사라지는 것이 아니라, _재레버리지(re-leveraged)_되고 있습니다. 기계적인 부분은 저렴해지고 있으며, 언제나 실제 어려운 작업이었던 부분들 — 아키텍처(architecture), 정확성(correctness), 접근성(accessibility), 심미안(taste) — 은 가치가 낮아지는 것이 아니라 오히려 더 높아지고 있습니다.

번창하는 엔지니어는 가장 빠르게 타이핑하거나 가장 많은 API를 암기하는 사람이 아닐 것입니다. 그들은 _좋은 것_이 무엇인지에 대한 명확한 그림을 유지하고, 이를 제약이 있고 기계가 읽을 수 있는 빌딩 블록(building blocks)으로 표현하며, 눈앞의 초안이 잘못되었을 때 즉각적으로 말할 수 있는 사람들일 것입니다.

프론트엔드는 대화가 되어가고 있습니다. 여전히 당신의 몫으로 남아있는 그 절반의 영역에서 숙련도를 높일 가치가 있습니다.