프론트엔드 개발자가 매일 마주치는 세 가지 장면이 있다. 첫 번째는 DevTools를 열었을 때 HTML 문서 한 줄이 1.4초 동안 멈춰 있는 장면이다. 두 번째는 버튼 하나가 열두 개의 isLoading, isError, isOpen 플래그로 뒤덮인 코드를 마주치는 순간이다. 세 번째는 레이아웃을 고민하느라 일주일을 보낸 뒤에야 팀 미팅에 들어가는 기획자의 얼굴이다. 세 장면은 서로 달라 보이지만 하나의 질문으로 수렴한다. '이 결정이 사용자에게 진짜 도움이 되는가.'
1. 느린 API는 아키텍처 문제다
dev.to에 올라온 Streaming SSR 분석 글은 이 첫 번째 장면을 수학으로 풀어낸다. 전통적인 Promise.all 기반 SSR에서 페이지 TTFB는 가장 빠른 API가 아니라 가장 느린 API에 맞춰진다. 다섯 개의 API 중 하나가 1,400ms를 잡아먹으면, 나머지 네 개가 30ms 안에 끝나도 사용자는 1.4초를 기다린다. 이른바 '단판 효과(short-board effect)'다.
더 냉정한 진실은 이 문제가 시간이 갈수록 악화된다는 점이다. API가 다섯 개일 때 p99 지연 발생 확률은 약 4.9%지만, 열 개가 되면 9.6%로 올라간다. 서비스가 성장할수록 의존성은 늘어나고, 느린 의존성은 거의 제거되지 않는다. 캐싱은 부분적인 해답이다. 개인화 데이터와 실시간 데이터는 캐시할 수 없고, 콜드 캐시는 배포할 때마다 첫 번째 사용자를 희생시킨다.
Streaming SSR은 이 문제를 구조적으로 해결한다. 핵심은 단순하다. 빠른 데이터로 셸(shell)을 즉시 내보내고, 느린 데이터는 Suspense 폴백과 함께 스트림으로 흘려보낸다. 같은 백엔드, 같은 API 지연이어도 TTFB는 1,440ms에서 240ms로 줄어든다. 사용자는 추천 콘텐츠를 기다리는 동안 이미 상품 페이지를 읽고 있다. 마법이 아니다. 설계 판단이다. 중요한 것은 어떤 데이터를 await하고 어떤 데이터를 defer할지 의식적으로 선택하는 것—그 판단이 곧 사용자 경험의 우선순위를 선언하는 행위다.
2. 복잡한 상태는 설계로 다스린다
두 번째 장면으로 넘어가자. GeekNews에서 조명한 Statecharts 논의는 프론트엔드 개발자라면 한 번쯤 경험해본 감각을 건드린다. isLoading && !isError && !isSubmitted && step === 2—이런 조건문이 쌓일수록 코드는 읽히지 않고, 버그는 예측 불가능한 곳에서 터진다. 암묵적으로 상태 기계처럼 작동하는 코드를 명시적인 Statechart로 끌어올리면 무슨 일이 생기는가.
XState를 만든 David Khourshid는 10년 넘게 이 문제를 파고든 끝에 핵심을 이렇게 정리한다. '다음에 무슨 일이 일어나는가가 현재 상태와 이벤트 둘 다에 의존할 때, Statechart는 가장 강력하다.' Statechart를 만드는 과정 자체가 가능한 모든 상태를 탐색하게 만들고, 그 과정에서 미처 생각하지 못했던 엣지 케이스가 드러난다. 연구 결과로도 Statechart 기반 코드의 버그 수가 전통적인 코드보다 낮다는 사례가 있다.
물론 비용이 없는 건 아니다. 새로운 학습 곡선, 작은 컴포넌트에서 늘어나는 코드량, 팀 전체의 패러다임 전환에 대한 저항—이 모든 것이 현실이다. 하지만 흥미로운 변수가 하나 생겼다. Hacker News 댓글에서 한 개발자가 지적했듯, 'AI가 있으면 XState의 장황한 문법 장벽이 거의 사라진다.' 최신 LLM은 이미 XState 코드를 꽤 잘 생성한다. AI가 복잡한 보일러플레이트를 처리해줄 수 있다면, 개발자는 상태 설계 자체에 집중할 수 있다. 도구의 변화가 패러다임 채택의 비용 구조를 바꾸고 있다.
3. AI 프로토타이핑은 '검증의 속도'를 바꾼다
B2B SaaS 플랫폼 UX 기획자의 Claude Design 활용 기록(브런치)은 세 번째 장면에 답한다. 이 기획자는 레이아웃 하나를 확정하는 데 일주일 이상을 썼다. 다양한 서비스를 비교 분석하고, 장단점을 따지고, 최선의 안을 고르는 과정이다. Claude Design과 함께 같은 작업을 했을 때 걸린 시간은 2일이었다.
단순한 속도 차이가 아니다. 더 중요한 변화는 '사고의 범위'가 달라졌다는 점이다. 기획자는 인라인 레이아웃 안에서 정보 위계를 고민하고 있었다. AI는 사이드패널형과 카드형을 추가로 제안하며 비교 분석을 함께 내놨다. 기획자가 미처 생각하지 못했던 레이아웃 패턴이 선택지로 등장한 것이다. 이때 인간의 역할이 중요해진다. AI가 제시한 세 가지 안 중에서 '왜 2안인가'를 판단한 것은 사용자 경험에 대한 기획자의 맥락 이해였다. 지도와 텍스트 추천 이유를 동시에 보여주는 사이드패널이 이 서비스의 핵심 문제를 푼다는 판단—그것은 AI가 대신할 수 없다.
이 기록에서 눈길을 끄는 또 다른 지점은 design.md와 Claude Design의 조합이다. 피그마 파일을 업로드하거나 GitHub의 디자인 시스템 마크다운을 붙여넣으면, AI가 기존 디자인 시스템에 맞는 결과물을 생성한다. 디자인 시스템이 없는 팀도 Awesome-design 같은 오픈소스 리소스로 진입장벽을 낮출 수 있다. 프로토타이핑이 개발자와 디자이너의 전유물이 아니라 기획자의 도구가 되는 순간이다.
세 가지 판단이 가리키는 하나의 방향
Streaming SSR, Statechart, AI 프로토타이핑—이 세 가지는 서로 다른 레이어의 이야기처럼 보인다. 하지만 공통된 논리가 있다. 세 가지 모두 '기다림의 구조'를 다시 설계하는 일이다. Streaming SSR은 느린 API가 빠른 콘텐츠를 인질로 잡지 못하게 한다. Statechart는 예측 불가능한 상태 전이가 사용자를 막다른 곳에 몰아넣지 못하게 한다. AI 프로토타이핑은 검증을 위한 시각물이 만들어지기까지의 대기 시간을 줄인다.
전망은 이렇다. Streaming SSR은 2026년 기준으로 이미 테이블 스테이크(table stakes)에 가까워지고 있다. Next.js App Router가 이를 기본 동작으로 채택했고, React Suspense는 이 패턴의 언어가 됐다. Statechart는 XState 차기 버전의 ergonomics 개선과 AI 보조 코드 생성이 맞물리며 채택 장벽이 낮아질 것이다. AI 프로토타이핑은 디자인-개발 경계를 허무는 것을 넘어, '만들기 전에 검증한다'는 문화 자체를 바꾸고 있다.
결국 이 세 가지 설계 판단이 묻는 것은 같다. 사용자가 기다리는 시간, 예측하지 못하는 상태, 검증되지 않은 가정—이것들을 얼마나 일찍, 얼마나 명시적으로 다루는가. 프론트엔드 설계의 품질은 기술 선택이 아니라 이 질문을 얼마나 자주 먼저 던지느냐에 달려 있다.