핵심 이슈: 서버를 걷어낼수록 프론트엔드 설계가 더 정교해진다
최근 dev.to에 잇따라 등장한 세 편의 글이 흥미로운 공통 신호를 보낸다. React Dialog Flow를 async/await로 오케스트레이션하는 패턴, Next.js 정적 내보내기로 260개 이상의 툴을 운영하는 아키텍처, 그리고 DeepSeek API와 Cloudflare Worker만으로 AI 문법 교정기를 브라우저에서 돌리는 구현. 세 프로젝트 모두 '서버를 최소화하거나 아예 없애는' 방향을 선택했고, 그 결과 오히려 프론트엔드 설계의 복잡도와 책임이 올라갔다. 서버리스는 단순함이 아니라 다른 종류의 엔지니어링 도전이다.
맥락 1: UI 흐름을 데이터처럼 다루는 Dialog 오케스트레이션
react-dialog-flow 라이브러리의 핵심 아이디어는 간단하지만 파급력이 크다. 기존에는 다단계 다이얼로그 흐름을 isOpen, selectedUser, isConfirmOpen 같은 상태 조각들로 흩뿌려 관리했다. 이 패턴은 화면이 늘어날수록 컴포넌트 간 상태 동기화 비용이 기하급수적으로 커진다. 반면 openAsync(UserSearchDialog) → openAsync(ConfirmDialog, { title }) 형태로 Promise 체인을 타면, UI 흐름이 실제 사용자 여정과 1:1로 대응하는 코드가 된다.
이것은 단순한 DX 개선이 아니다. AI 도구처럼 '입력 → 처리 중 → 확인 → 결과' 단계가 명확한 플로우를 구현할 때, async/await 기반 Dialog 오케스트레이션은 상태 관리 레이어를 줄이면서 가독성과 타입 안전성을 동시에 확보한다. Radix나 shadcn/ui가 UI 렌더링 문제를 푼다면, react-dialog-flow는 그 위에서 흐름 제어 문제를 푼다. 두 레이어를 분리해서 생각해야 한다는 점이 이 라이브러리의 진짜 시사점이다.
맥락 2: 260개 툴을 정적 사이트로 운영하는 아키텍처 전략
ToolReign의 개발자 Anirudha Sonwane이 선택한 핵심 베팅은 output: 'export'로 Next.js를 완전 정적 사이트로 내보내는 것이었다. 260개 이상의 도구가 src/app/{category}/{tool-slug}/ 구조에 각자 라우트를 갖고, tool-registry.json 하나가 사이트맵·카테고리 허브·검색 인덱스를 동기화한다. 빌드 아티팩트가 out/ 폴더 하나이기 때문에 Node 서버 없이 정적 호스팅에 올릴 수 있다.
이 구조가 유지 가능했던 이유는 두 가지다. 첫째, buildMetadata() 헬퍼 하나가 모든 페이지의 OpenGraph, 트위터 카드, canonical URL, JSON-LD를 일관되게 생성한다. 메타데이터 드리프트를 원천 차단한다. 둘째, PDF 처리는 pdf-lib, 이미지는 Canvas API, 오디오는 Web Audio API—모든 실제 연산이 클라이언트에서 일어난다. 사용자 데이터가 서버로 나가지 않는다는 사실이 단순한 프라이버시 마케팅이 아니라 실제 엔지니어링 제약이었다. 중간 규모 스마트폰에서 5개 PDF를 병합할 때 메인 스레드를 블로킹하지 않는 것은 서버 API 호출보다 훨씬 섬세한 문제다.
한 가지 주목할 후회가 있다. 그는 공통 컴포넌트 스캐폴드—입력 툴바, 유효성 검증 헬퍼, 결과 플레이스홀더—를 초반에 잡지 않았던 것을 아쉬워한다. 비슷한 도구 20개가 넘어가는 순간 복붙 리팩터링 비용이 공통 추상화 비용을 앞지른다. 빠르게 늘리기 전에 컴포넌트 전략부터 잠가야 한다는 교훈이다.
맥락 3: AI 기능을 브라우저에 이식하는 최소 아키텍처
AI Grammar Checker의 스택은 의도적으로 단순하다. HTML + 바닐라 JS + CSS → Cloudflare Worker(프록시) → DeepSeek API. React도, Next.js도, 빌드 스텝도 없다. API 키를 서버 사이드에 두기 위한 Cloudflare Worker 한 겹이 전부다.
이 구조에서 눈여겨볼 선택은 두 가지다. 첫째, DeepSeek을 GPT-4o 대신 고른 이유가 단순히 비용(1/10 수준) 때문만이 아니다. 동일 테스트셋에서 93% 대 91%의 오류 검출률 차이는 10배 비용 차이를 정당화하지 못한다. 여기서 의사결정의 틀이 드러난다—기능 대비 비용의 한계효용을 명시적으로 측정하고 선택했다는 것. 둘째, 강도 슬라이더가 시스템 프롬프트를 직접 조절한다. 이것은 AI 파라미터를 UX 레이어에 노출하는 방식이다. '어떤 AI 기능을 쓸까'보다 '사용자가 AI의 적극성을 어떻게 제어하게 할까'가 더 중요한 설계 문제였다.
아직 미완인 오프라인 모드—WebLLM으로 온디바이스 모델을 번들하는 방향—는 앞서 언급한 브라우저 기반 실행 트렌드와 정확히 맞닿아 있다. 프록시 서버마저 없애는 방향으로 아키텍처가 계속 수렴하고 있다.
시사점: 세 패턴이 함께 가리키는 설계 원칙
세 프로젝트를 겹쳐보면 공통된 설계 방향이 선명해진다.
흐름은 코드 구조로 표현하라. 다단계 UI 흐름을 상태 조각 대신 async/await 체인으로 표현하면, AI 도구처럼 단계가 많은 UX를 설계할 때 로직과 UI가 함께 읽힌다.
레지스트리 하나가 전체를 동기화한다. 수십~수백 개의 기능 단위가 생기는 순간, 라우트·메타데이터·사이트맵을 각자 관리하는 구조는 무너진다. 단일 진실 공급원을 초반에 잡아두는 것이 규모의 전제 조건이다.
AI 기능의 복잡도는 프록시 레이어로 격리하라. API 키 노출, 비용 제어, 모델 교체 가능성—이 세 가지를 Cloudflare Worker 같은 얇은 서버 레이어로 분리하면, 프론트엔드는 UX에만 집중할 수 있다. 그리고 그 레이어를 점진적으로 온디바이스로 옮기는 경로도 열린다.
전망: 프로토타입 속도와 설계 품질의 교차점
세 프로젝트 모두 빠른 프로토타이핑에서 시작해 실제 사용자 가치를 검증한 뒤 구조를 고도화하는 흐름을 밟았다. 그리고 세 개 모두 같은 후회를 남겼다—공통 추상화를 더 일찍 잡았어야 한다는 것.
AI 도구가 개발 속도를 올려주는 지금, 역설적으로 초반 설계 결정의 무게가 더 커진다. 빠르게 만들수록 컴포넌트 전략, 레지스트리 구조, 흐름 제어 레이어를 미리 잠가두는 것이 중요해진다. 브라우저가 AI 실행 환경이 되는 속도는 점점 빨라지고, 그 위에서 사용자 신뢰를 설계하는 것은 여전히 프론트엔드 개발자의 몫이다.