성능·UX·AI, 세 전선이 동시에 열렸다
2026년 프론트엔드 개발자의 하루는 세 개의 전선을 동시에 관리하는 것처럼 느껴진다. 캐시가 낡으면 사용자는 오래된 가격을 본다. 모바일 키보드가 UI를 가리면 사용자는 그냥 앱을 닫는다. AI가 엉뚱한 JSON을 뱉으면 프로덕션 파이프라인이 터진다. 이 세 문제는 각각 독립적으로 보이지만, 사실 하나의 질문으로 수렴한다. '사용자가 기대하는 순간에, 기대하는 것을 정확히 보여줄 수 있는가?'
최근 dev.to에 올라온 세 편의 글이 이 질문에 각각 날카로운 답을 내놓았다. 함께 읽으면 2026년 프론트엔드 실전 스택의 윤곽이 보인다.
ISR은 '전부 빌드'가 아니라 '언제 빌드할지'를 설계하는 일
SmartReview 팀이 공개한 Next.js 스케일링 플레이북은 10,000개 이상의 상품 비교 페이지를 운영하면서 터득한 캐싱 전략의 정수다. 핵심은 단순하다. 모든 페이지를 미리 빌드하려 하지 말 것. 빌드 시간이 47분에서 4분으로 줄고, 서버 비용이 74% 감소한 건 그 원칙을 지킨 결과다.
이들이 설계한 3-티어 ISR 전략은 트래픽 온도에 따라 리밸리데이션 주기를 달리한다. 상위 500개 핫 페이지는 1시간, 다음 3,000개는 24시간, 나머지 롱테일 7,000개는 1주일. 그리고 진짜 무기는 시간 기반이 아닌 이벤트 기반 온디맨드 리밸리데이션이다. 가격이 바뀌거나 새 리뷰가 들어오는 순간, 해당 페이지만 정확히 재생성한다. revalidatePath를 웹훅으로 연결하면 배포 없이 데이터 신선도를 유지할 수 있다.
여기서 주목할 부분은 캐싱 레이어의 다층 설계다. ISR은 페이지 단위, Redis는 핫 데이터(4~24시간 TTL), unstable_cache는 쿼리 단위. 각 레이어가 서로 다른 신선도 요구사항을 담당한다. 단일 캐시 전략으로 모든 문제를 해결하려는 접근은 이 규모에서 작동하지 않는다.
dvh는 URL 바를 알지만, 키보드는 모른다
CSS dvh가 모바일 브라우저의 URL 바 문제를 해결했다는 건 이제 상식이다. 그런데 많은 개발자가 놓치는 사실이 있다. dvh는 온스크린 키보드를 완전히 무시한다. 스펙상 가상 키보드는 레이아웃 뷰포트를 변경하지 않는 오버레이로 처리되기 때문이다.
결과는 명확하다. 입력 폼 하단에 position: fixed로 붙여놓은 버튼이나 액션 바가 키보드에 가려진다. 사용자는 가려진 버튼을 찾아 헤매거나, 그냥 이탈한다. 모바일 전환율이 낮은 서비스의 원인을 데이터만 보고 찾으면 이런 UX 디테일을 놓친다.
해결책은 Visual Viewport API다. window.visualViewport.height는 키보드가 올라올 때 실제로 줄어드는 반면, window.innerHeight는 고정된 채로 남는다. 그 차이가 키보드 높이다. 단, iOS Safari와 Android Chrome의 동작 방식이 달라 두 케이스를 모두 처리해야 한다. iOS는 visualViewport.offsetTop이 증가하고, Android는 window.innerHeight 자체가 감소한다.
dev.to에 공개된 use-dynamic-viewport 훅은 이 두 케이스를 모두 핸들링하며 --dvh와 --keyboard-height CSS 변수를 루트에 자동 주입한다. 0.8KB, 제로 의존성, Next.js App Router SSR 안전. 모바일 입력 UX가 중요한 서비스라면 지금 당장 도입을 검토할 만하다.
AI 응답 검증: '모델을 믿을 것인가' vs '출력을 검증할 것인가'
LLM에게 JSON을 요청하면 가끔 마크다운 코드 블록이 오고, 가끔 필드명이 틀리고, 가끔 친절한 설명문이 온다. 이 불확실성을 어떻게 제어할 것인가가 AI 기능 개발의 핵심 설계 이슈다.
dev.to의 비교 분석에 따르면 선택지는 두 가지다. OpenAI Structured Outputs는 토큰 생성 단계에서 스키마를 강제해 구조적으로 잘못된 출력을 원천 차단한다. 100%의 구조 보장이지만 OpenAI 전용이다. Zod 검증은 출력 후 파싱·검증하는 방식으로 어떤 모델에도 적용 가능하며, TypeScript 타입 추론과 커스텀 로직을 자유롭게 결합할 수 있다.
실무에서 가장 현실적인 선택은 Vercel AI SDK의 generateObject다. Zod 스키마 하나로 정의하면, OpenAI에서는 Structured Outputs를 자동 활용하고, Claude나 Gemini에서는 프롬프트 기반 JSON 생성과 Zod 검증으로 폴백한다. 프로바이더를 갈아탈 때 검증 로직을 다시 짤 필요가 없고, 타입 안전성은 유지된다. Next.js 앱과의 궁합은 두말할 필요 없다.
세 기술이 하나의 철학으로 수렴하는 지점
세 가지 주제를 나란히 놓으면 공통 패턴이 보인다. ISR 티어링은 '모든 페이지를 동등하게 다루지 않는다'는 인사이트에서 출발하고, Visual Viewport API 활용은 '스펙이 다 해결해줄 거라는 믿음을 버린다'는 현실 감각에서 나오며, AI SDK의 generateObject는 '모델 하나에 종속되지 않는다'는 유연성 설계다.
세 가지 모두 기본값을 의심하고, 실제 동작을 측정하며, 계층을 나눠 설계하는 태도를 공유한다. 프론트엔드 개발이 점점 복잡해지는 2026년, 도구를 아는 것만큼 중요한 건 그 도구의 한계를 아는 것이다.
지금 당장 체크할 것
이 세 가지를 현재 프로젝트에 대입해보는 데 5분이면 충분하다. 페이지 종류별로 리밸리데이션 주기가 다르게 설계되어 있는가. 모바일 입력 폼 하단 UI가 키보드에 가려지는 시나리오를 실제 기기에서 테스트한 적 있는가. AI 응답 파싱 코드에 재시도 로직과 타입 검증이 붙어 있는가. 세 질문 중 하나라도 '아니오'라면, 거기서 사용자 경험의 구멍이 새고 있을 가능성이 높다.