웹 개발에 대한 이상한 믿음들

핵심: 내 웹이 웹 전체는 아니다

웹 개발에 대한 단정적인 주장 대부분은 자기가 겪는 웹을 웹 개발 전체로 일반화한 데서 나온다. 같은 사람이 만든 블로그와 웹 앱도 도구, 아키텍처, 쓰는 플랫폼 기능이 거의 겹치지 않는다.

	개인 블로그	오프라인 우선 웹 앱
클라이언트 JS	거의 없다	TypeScript 코드가 대부분
데이터	읽기 전용	서버와 양방향 동기화
도구	정적 생성기 정도	번들러, E2E 테스트(Playwright), 컴포넌트 프레임워크, 상태 관리

한쪽만 오래 하면 그것이 "웹 개발"이라고 믿기 쉽다. 웹 개발은 생각보다 훨씬 다양하다.

누가 웹 개발을 잘 아나

믿음	실제
브라우저 엔지니어는 웹 개발을 잘 안다	브라우저 엔지니어는 대부분 C++·Rust로 엔진의 한 분야를 깊게 판다. 도구는 거대 단일 저장소에서 남이 관리해 준다. 번들러 설정, iOS Safari 호환, 거대한 CSS, 청크 분할, ESM·CJS 혼란, 상태 관리 선택 같은 웹 개발자의 일상을 겪지 않는다. DevTools·브라우저 UI 담당자도 한 엔진의 최신 버전만 대상으로 하니 호환성·번들 크기·오프라인을 걱정하지 않는다. 대신 어디를 보고, 누구에게 묻고, 버그를 어디에 올릴지는 잘 안다
표준을 만드는 사람은 웹 개발을 잘 안다	표준 제정은 소시지 만들기와 같다. 선의와 실력에도 불구하고 회의실에 누가 있었는지, 누가 목소리가 컸는지, 얼마나 피곤했는지, 누군가의 승진 실적 같은 요인이 결정에 섞인다. 웹 개발자 피드백을 모으려 해도 설문은 최전선의 개발자만 응답해 쉽게 치우친다. 대면 회의 결정을 구속력 없게 두고 비동기로 결정하는 WHATWG 방식은 상대적으로 낫다
웹 개발자는 웹 플랫폼을 잘 안다	새 기능이 출시돼 기술 매체와 SNS가 떠들썩해도 현장의 많은 개발자는 몇 년 된 CSS 기능도 모른다. 작은 회사에서 빨리 납품하고 다음 프로젝트로 넘어가야 하는 사람에게는 새 기술보다 이미 검증된 익숙한 도구(jQuery, WordPress 등)가 합리적이다. 그들이 원하는 것은 새 API가 아니라 "고객에게 보여 줄 반응형 미리보기에 아이폰 목업" 같은 실용 기능이었다

교훈은 서로 다른 세계라는 점이다. 표준과 브라우저를 만드는 사람은 현장 개발자의 제약을, 현장 개발자는 플랫폼의 새 가능성을 놓치기 쉽다. 자기 제약 조건을 가장 잘 아는 사람은 그 일을 하는 사람이다.

SPA와 MPA에 대한 믿음

"브라우저는 SPA를 위해 만들어지지 않았다"

"브라우저는 네트워크에서 받은 문서를 점진적으로 그리는 데 최적화됐고, 동적 콘텐츠는 나중에 생겨서 덜 최적화됐다"는 주장이다. 지금의 브라우저에는 맞지 않는다.

브라우저 자체가 반례다. Firefox의 UI와 개발자 도구는 SPA이고, 개발자 도구는 React·Redux로 만들어져 있다. 브라우저는 JS로 계속 바뀌는 크고 오래 사는 DOM 트리를 잘 다룬다.
정당한 비판은 "초기 렌더링을 막는 큰 JS 번들"이다. 그러나 이것은 시작 번들을 작게 하라는 요구이고, 무거운 WordPress 사이트에도 똑같이 적용된다. SPA라는 구조의 문제가 아니다(자바스크립트 코드 분할).
비슷한 오해로 "어떤 애니메이션은 GPU에서 실행된다"가 있다. 브라우저는 일부 애니메이션을 합성(compositing) 단계나 별도 스레드·프로세스로 넘겨 GPU로 합성할 수 있을 뿐, 애니메이션 전체를 GPU에 맡기지 않는다(브라우저 렌더링 과정).

"MPA가 SPA를 대체한다"

구분	콘텐츠를 바꾸는 방식
SPA	오래 사는 DOM 트리를 스크립트로 갱신한다
MPA	네트워크에서 다른 HTML 문서로 이동해 바꾼다(최상위 이동만이 아니라 `<iframe>` 이동도 포함)

이 기준으로 보면 문서마다 URL이 있는 Google Docs도 한 문서를 JS로 계속 갱신하므로 SPA이고, YouTube도 탐색을 가로채 스크립트로 내용을 바꾸는 SPA다. 문서 간 View Transitions가 생기며 MPA도 SPA처럼 매끄러운 전환을 낼 수 있게 됐다. 하지만 모든 SPA가 MPA로 바뀌지는 않는다.

Figma, 웹 Photoshop, Slack, Discord, Google Maps를 문서 이동 방식으로 만들기는 어렵다.
독립적으로 탐색하는 패널과 오프라인 우선 요구가 있는 앱을 MPA로 바꾸려면 <iframe>으로 HTML을 쪼개야 한다. 그러면 양방향 동기화가 3방향 동기화가 되어 복잡도는 크게 늘고, 사용자가 얻는 이득은 없이 버그와 지연만 는다.

아키텍처는 유행이 아니라 앱의 요구로 고른다. 렌더링 방식별 차이는 SPA와 CSR·SSR에 있다.

JS와 빌드에 대한 믿음

"모든 사이트는 JS 없이 동작해야 한다"

JS 없이도 동작하는 사이트는 훌륭한 목표다. 점진적으로 품질이 떨어질 뿐 깨지지 않고, 초기 렌더링을 막는 스크립트가 없고, 더 많은 브라우저에서 돈다(책임감 있는 자바스크립트). 문제는 이것이 모든 사이트에 대한 교조가 될 때다.

디자인 도구, 개발자 도구, 그림 그리기 앱은 JS 없이 상상하기 어렵다.
접근성에 JS가 필요한 경우가 많다. 툴바·탭처럼 컨트롤이 많은 위젯은 그룹 사이는 Tab으로, 그룹 안은 방향키로 움직여야 빠르게 탐색할 수 있다. 이 로빙 tabindex와 2차원 방향키 탐색은 JS로 구현한다(키보드 접근성과 포커스 관리). 플랫폼 차원의 해법(focusgroup)은 아직 제안 단계다. 접근성을 위해 JS를 쓰는 것은 부끄러운 일이 아니다.
오히려 JS가 조금 더 있으면 좋아지는 사이트도 많다. 예: 문서의 코드 예제 언어 탭을 고르면 그 선택을 기억해 모든 예제에 적용하는 정도의 클라이언트 스크립트.

"웹 개발에 빌드 단계는 필요 없다"

"툴체인이 너무 복잡해졌으니 빌드 없이 배포해야 한다"는 주장도 있다. 컴파일 언어의 관점에서는 반대다. 컴파일러는 평범한 코드를 훨씬 빠른 형태로 바꾸는 최적화를 겹겹이 쌓는다.

이미지 최적화와 정적 HTML 미리 생성은 당연하게 받아들이면서, 코드 에셋 최적화만 거부할 이유는 없다.
빌드 때 끝낼 수 있는 계산과 I/O를 런타임으로 미룰 이유도 없다. 개발용 주석 수 MB를 모든 사용자에게 매 요청 보낼 필요는 없다.
JS는 부수 효과를 정적으로 판단하기 어려워 컴파일 최적화에 한계가 있지만, 그만큼 탐구할 여지도 크다. WASM으로 컴파일하는 프론트엔드 프레임워크처럼 빌드가 전제인 방식도 늘고 있다(번들러의 역사와 Vite).

정리

브라우저 엔지니어, 표준 제정자, 현장 개발자는 각자 다른 세계에서 일한다. 누구도 웹 개발 전체를 대표하지 않는다.
브라우저는 SPA를 잘 다룬다. 문제는 SPA가 아니라 초기 렌더링을 막는 큰 번들이다.
MPA와 View Transitions는 좋은 선택지지만 모든 앱의 답은 아니다. 앱의 요구로 아키텍처를 고른다.
JS 없는 사이트는 좋은 목표지 교리가 아니다. 접근성과 사용성을 위해 JS가 필요한 곳이 많다.
빌드 단계는 짐이 아니라 사용자에게 보낼 것을 줄이는 최적화 기회다.

남이 특정 방식을 단정할 때는 그 사람이 겪는 웹이 어떤 웹인지부터 본다.

버그 제보