로딩 스피너 30초, 그리고 '왜 우리는 AI 응답을 DB 쿼리처럼 다루는가'
AI 기능을 프론트엔드에 붙이는 일이 이제 '해볼 만한 실험'을 넘어 '제품의 기본값'이 되어가고 있다. 그런데 막상 구현 단계에 들어서면 낯선 병목이 기다리고 있다. LLM은 응답을 한 번에 뱉지 않는다. 스트리밍으로 토큰을 흘려보낸다. 그런데 많은 팀이 여전히 전체 응답이 완성될 때까지 기다렸다가 한꺼번에 렌더링한다. AI 프레젠테이션 생성 서비스 PitchShow를 만든 개발자가 dev.to에 공유한 사례가 딱 이 문제를 짚는다. 초기 버전은 슬라이드 한 장 생성에 30초가 걸렸고, 사용자는 스피너를 보다가 탭을 닫았다. 원인은 AI가 아니라 아키텍처였다.
스트리밍 UI가 바꾸는 것: '완성'이 아니라 '흐름'
해법의 핵심은 Progressive Disclosure—준비된 것부터 보여주는 것이다. PitchShow가 선택한 구조는 React Server Components + SSE(Server-Sent Events) + Suspense의 조합이다. 서버에서 LLM 스트림을 받아 슬라이드 경계(---SLIDE_BREAK---)를 감지하는 즉시 의미 단위 이벤트로 변환하고, 각 슬라이드를 독립된 Suspense 경계로 감싸 클라이언트에 순차 렌더링한다. 슬라이드 1이 화면에 뜨는 동안 슬라이드 4는 아직 생성 중이다. 사용자는 기다리는 게 아니라 이미 편집을 시작한다.
이 패턴이 흥미로운 이유는 기술적 선택이 곧 UX 결정이기 때문이다. Suspense 경계를 어디에 두느냐가 사용자가 '빠르다'고 느끼는 지점을 결정한다. 여기에 Framer Motion으로 스켈레톤→콘텐츠 전환에 페이드인을 얹으면, 스트리밍의 '덜컥거림'이 '의도된 흐름'으로 읽힌다. 기술 선택이 인터랙션 품질로 직결되는 지점이다.
5천만 사용자가 증명한 것: ISR과 엣지 캐싱은 성능 트릭이 아니라 확장 전략이다
AI 기능이 아무리 매끄러워도, 트래픽이 몰리는 순간 버티지 못하면 의미가 없다. Quran.com의 프론트엔드 엔지니어링 리드가 dev.to에 공유한 월 5천만 사용자 확장 사례는 이 지점에서 중요한 교훈을 준다.
출발점은 익숙한 문제였다. 클라이언트 사이드 렌더링 SPA, 느린 첫 화면, 서버 부하. 해법은 Next.js로의 전환과 ISR(Incremental Static Regeneration) 적용이었다. 자주 바뀌지 않는 콘텐츠(수라 페이지)는 1시간 주기로 백그라운드 재검증하고, Cloudflare를 Vercel 앞에 세워 ISR이 생성한 페이지를 엣지에서 캐싱했다. stale-while-revalidate 헤더가 핵심이다—CDN은 캐시된 버전을 즉시 서빙하면서 백그라운드로 갱신한다. 결과는 TTFB 70% 감소, CDN 캐시 히트율 40%→92%, JS 번들 크기 45% 감소.
이 사례가 AI 기능과 연결되는 이유가 있다. AI가 생성한 콘텐츠도 결국 어딘가에 캐싱되어야 한다. 사용자마다 완전히 다른 응답이 필요한 경우는 생각보다 적다. 공통 프롬프트 결과는 ISR로 미리 구워두고, 개인화 레이어만 클라이언트에서 처리하는 하이브리드 전략이 현실적이다. 확장은 AI를 붙인 다음에 생각하는 게 아니라, 처음 설계할 때 함께 고민해야 한다.
Predictor Interface: AI 모델이 바뀌어도 프론트엔드는 모른다
스트리밍과 캐싱을 갖췄어도, AI 시스템 자체가 바뀔 때마다 프론트엔드까지 수정해야 한다면 유지보수 비용이 빠르게 불어난다. 비엔나의 엔터프라이즈 AI 스튜디오 LOUWIETEC이 dev.to에서 소개한 Predictor Interface 패턴은 이 문제를 정면으로 다룬다.
아이디어는 단순하다. 규칙 기반 로직이든, XGBoost든, BERT든—모든 지능형 컴포넌트가 동일한 인터페이스를 구현한다. 같은 입력, 같은 출력, 같은 API 응답. 프론트엔드와 API 레이어는 내부에서 무엇이 돌아가는지 모른다. 모델 교체는 설정 변경 한 줄이다. 재배포도, 프론트엔드 수정도 없다.
이 패턴이 프로토타이핑→검증→고도화 흐름에서 갖는 의미는 크다. 데모는 규칙 기반으로 며칠 만에 만든다. 실제 데이터가 쌓이면 ML 모델로 교체한다. 모델이 기대 이하면 즉시 롤백한다. 프론트엔드 팀은 이 과정에서 아무것도 건드리지 않는다. AI 시스템의 실험 속도와 프론트엔드의 안정성이 분리된다.
세 가지 원칙이 완성하는 하나의 그림
세 사례를 나란히 놓으면 하나의 설계 철학이 보인다.
스트리밍 UI는 LLM의 비동기 특성을 UX 자산으로 전환한다. 기다림을 흐름으로 바꾸는 것은 기술이 아니라 아키텍처 결정이다. ISR + 엣지 캐싱은 AI 기능이 실사용자 규모에서도 성능을 유지하게 만드는 확장 전략이다. 성능은 AI를 붙인 후의 문제가 아니라 설계 초기의 제약 조건이다. Predictor Interface는 AI 모델의 진화 속도와 프론트엔드의 안정성 사이에 완충재를 둔다. 빠른 실험이 기술 부채로 쌓이지 않게 막는 구조적 선택이다.
전망: 프론트엔드 엔지니어가 설계해야 할 새로운 경계
AI 기능이 제품의 핵심이 되는 속도는 예상보다 빠르다. 그리고 그 기능을 사용자에게 실제로 전달하는 것은 결국 프론트엔드다. 스트리밍 아키텍처, 캐싱 전략, 모델 추상화—이 세 가지는 이제 'AI 팀의 일'이 아니라 프론트엔드 엔지니어가 설계 단계부터 함께 고민해야 할 영역이 됐다.
'AI를 붙이는 것'과 'AI가 제대로 작동하는 제품을 만드는 것' 사이의 거리는, 결국 이 설계 결정들이 채운다.