Medium
자바스크립트가 웹을 망가뜨렸습니다. (그리고 이를 진보라고 불렀습니다)
"앱처럼 느껴지게 해달라" 가 시작이었다. 우리는 DX 를 UX 로 착각한 채 모든 페이지에 빌드·하이드레이션·SPA 라우팅을 욱여넣었다. 이 글은 그 결정의 청구서다.
핵심 요약
글의 골자는 다음 흐름이다.
- 2010년대 "앱처럼 느껴지게" 라는 비즈니스 요구가 SPA 보편화를 촉발
- Node + JS 풀스택 문화로 문서가 아니라 애플리케이션을 만든다 는 멘탈이 표준이 됨
- 그 결과 모든 페이지가 빌드·하이드레이션·라우팅 레이어를 갖게 됨
- 사용자에게 전가되는 비용: 메가바이트급 JS, CLS/LCP 악화, 접근성·SEO 후순위, 의존성 복잡도
- "DX 가 좋다" 가 무비판 정당화 도구가 됨 — 영리함 > 명확성
반론으로 가능한 처방:
| 영역 | 도구/패턴 | 효과 |
|---|---|---|
| 콘텐츠 사이트 | MPA, 정적 생성, 부분 하이드레이션(Astro) | JS 최소화 |
| 인터랙션 풍부 영역 | 아일랜드/RSC | 필요한 곳만 클라이언트 |
| 라우팅 | 서버 라우팅 + 점진적 향상 | 첫 페인트 빨라짐 |
| 번들 | Tree-shaking + lazy + esbuild/Rolldown | 다운로드 감소 |
이 글의 주장 한 줄: "개발자 경험을 사용자 경험으로 착각하지 마라". 근래 10년 프론트엔드 진화는 추상화 = 개발자 편의 증가, 사용자 부담 증가 의 거래였고, 그 거래에서 사용자 측 비용(JS 다운로드·실행 시간, 메인 스레드 점유, 시맨틱 손실, 접근성 후순위) 이 누적됐다는 진단이다. 그래서 "DX 좋다" 가 곧 "좋은 선택" 이 아니다 — 그 추상화의 비용을 누가 부담하는가 를 매번 묻는 사고가 핵심이다.
이 글은 단순 비판이 아니라 "기술 선택의 책임 분리" 라는 시니어 면접 단골 주제를 정확히 건드린다. 다음 세 가지를 자기 언어로 정리해두면 면접에서 큰 차이가 난다.
- 어떤 페이지에 SPA 가 정말 필요한가 (블로그/문서 vs 대시보드)
- 하이드레이션·스트리밍·아일랜드 같은 패턴이 풀려는 문제가 무엇인가
- DX 향상이 UX 비용으로 전가되는 구체적 사례 (번들·메인 스레드·시맨틱 손실)
결론적으로 "무조건 React 쓰자" 가 아니라 문제 → 도구 매핑 을 평가하는 자세를 묻는 글이다.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
DX 를 UX 로 착각하지 않기
좋은 DX 는 개발자가 빠르게 편하게 일한다 를 의미하지만, 그 편의가 사용자 비용으로 전가되는 경우가 많다.
| DX 향상 | 자주 따라오는 UX 비용 |
|---|---|
| 컴포넌트 라이브러리 | 사용 안 한 코드까지 번들에 포함 |
| 파일 기반 라우팅 | 라우트마다 별도 청크 → 첫 로드 폭증 |
| useEffect 데이터 패칭 | 폭포수 요청, 깜빡임 |
| 클라이언트 상태 관리 | 메인 스레드 + 메모리 |
시니어가 묻는 질문: "이 추상화의 비용을 누가 부담하는가?" 답이 항상 "사용자" 라면 도구 선택을 다시 본다.
"개발 속도가 빨라졌으니 좋은 도구" 라는 결론. 지표(LCP/INP, 번들/메인 스레드) 를 같이 측정하지 않으면 사용자 비용은 보이지 않는다.
콘텐츠 사이트와 앱은 같은 도구를 쓰면 안 된다
블로그·문서·랜딩 같은 콘텐츠 사이트 는 인터랙션이 거의 없다. 여기에 SPA 를 박으면 거의 모든 비용이 무의미하다.
블로그(콘텐츠) → MPA + 정적 생성 + 점진적 향상
대시보드(앱) → SPA 또는 RSC + 클라이언트 라우팅
혼합 → Astro/Next 의 island, RSC + Client Component 분리
React 19 의 RSC, Astro 의 island 모델은 모두 "기본은 정적, 인터랙션이 있는 부분만 JS" 라는 같은 원칙으로 수렴 중이다.
콘텐츠 사이트에 "라우팅 부드러움" 을 위해 SPA 를 도입하는 것. 첫 페인트가 느려져 전체 경험은 더 나빠진다.
복잡성은 기본값이 아니다
글의 마지막 주장은 "복잡성을 기본값으로 받아들이지 마라" 다. 매 프로젝트마다 다음 질문을 먼저 한다.
- 빌드 단계가 반드시 필요한가? (간단한 페이지면 vanilla 도 답)
- 하이드레이션이 반드시 필요한가? (콘텐츠 위주면 island 만으로 충분)
- 클라이언트 라우팅이 반드시 필요한가? (브라우저 기본 라우팅이 최선)
- 디자인 시스템 의존이 반드시 필요한가? (한 컴포넌트 쓰자고 통째로 임포트?)
"필요해서 추가" vs "기본이라 추가" 의 차이가 누적되어 번들 차이를 만든다.
"이 시대에 vanilla 는 비현실적" 이라는 무비판. 정적 사이트 생성기 + 약간의 JS 만으로 90% 의 콘텐츠 사이트를 충분히 처리할 수 있다.
읽는 순서
- 1이론
DX, UX, 하이드레이션, 아일랜드, RSC 의 정의를 한 줄씩 적고, 각각이 어떤 비용을 누가 부담 하는지 옆에 적는다.
- 2구현
동일한 콘텐츠 페이지를 (a) Next.js App Router (b) Astro 정적 생성 두 방식으로 만들고, Lighthouse 의 LCP/INP, 번들 크기, 메인 스레드 점유를 비교한다.
- 3실무
현재 프로젝트의 라우트별 번들 크기 와 Time To Interactive 를 측정해, 콘텐츠 위주 페이지에서 SPA 가 가져오는 비용을 정량화한다. 1개 페이지를 island/MPA 형태로 변환해보고 결과를 회고.
- 4설명
동료에게 "DX 와 UX 가 충돌하는 사례" 를 5분 안에 설명한다. 단순 비판이 아니라 조건/도구/지표 로 평가하는 시니어의 시선으로.
면접 연결 질문
[감점 답변] "Next.js 가 표준이라 Next.js". [좋은 답변] 콘텐츠 사이트라는 점이 결정적. 인터랙션이 적으니 정적 생성/MPA 가 (1) JS 거의 없음 → LCP/INP 우수, (2) SEO·SNS 미리보기 자연스러움, (3) 빌드·운영 비용 단순. 만약 기존 인프라가 Next 인 등 조직 표준 이슈가 있다면 Next 를 쓰되 "정적 export + island 만 클라이언트" 같은 형태로 DX 따로, UX 비용 최소화 를 노린다.
[감점 답변] "커뮤니티 크기 본다". [좋은 답변] DX 와 UX 비용을 분리해 묻는다. (1) 사용자 비용: 번들/메인 스레드/CLS·INP 변화, (2) 마이그레이션 비용: 기존 시스템 통합·테스트 부담, (3) 운영 비용: 빌드 시간·CI 비용, (4) 인력 비용: 학습·채용. DX 향상이 UX 회귀를 동반하면 채택하지 않는다 가 기본 입장.
[감점 답변] "JS 다시 실행하는 거예요". [좋은 답변] 하이드레이션은 서버에서 그린 HTML 위에 클라이언트가 다시 컴포넌트 트리를 만들어 이벤트를 붙이는 과정이라, (a) 동일 코드의 재실행, (b) 데이터의 재직렬화, (c) 메인 스레드 점유로 인한 INP 악화 를 만든다. 줄이는 최근 패턴은 (1) 아일랜드(Astro) — 인터랙티브 영역만 하이드레이션, (2) RSC(React) — 서버 컴포넌트는 클라이언트 코드 없이 렌더, (3) Resumability(Qwik) — 클라이언트가 다시 실행하지 않고 "이어 받는다".
자기 점검
"DX 와 UX 가 같은 방향" 이라는 가정. 종종 반대 방향이다.
"항상 부적합" 또는 "항상 적합" 이라는 이분법. 조건 에 따라 결정이 달라진다.