[번역] 자바스크립트가 웹을 망가뜨리고 있습니다 (우리는 이것을 진보라고 부르고 있죠)

원문

들어가기전에

저자는 현대 프론트엔드 개발 방식에 대해 날카롭게 비판하고 있습니다.

사람에 따라 저자의 의견에 동의하는 부분도 동의하지 않는 부분도 있겠지만,

중요한 것은 간과한 채 기술을 위한 기술, 개발을 위한 개발에만 치중되는 건 경계해야겠다는 생각이 들었습니다.🥹

---

대부분의 웹사이트는 형편없습니다

단순히 느린 게 아닙니다. 끔찍합니다. 부풀려지고, 불안정하며, 과잉 설계된 재앙입니다.

느리게 로드되고, 불규칙하게 렌더링되며, 수 메가바이트의 자바스크립트 뒤에 콘텐츠를 숨깁니다.

모바일에서는 버벅거립니다. 사용자를 좌절시키고, 검색엔진을 혼란스럽게 만듭니다. 유지보수도 불가능합니다. 그런데도 우리는 이것을 “진보”라고 부릅니다.

비극은, 그럴 필요가 전혀 없다는 점입니다. 예전에는 빠르고, 안정적이며, 탄탄한 웹이 있었습니다. 하지만 우리는 그것을 자바스크립트 카고 컬트(cargo cult)로 바꿔버렸습니다.

자바스크립트 카고 컬트란?
카고 컬트는 '겉모습은 흉내 내지만, 실제 원리나 목적은 이해하지 못한 채 의식만 반복하는 행위' 를 뜻함. 따라서 자바스크립트 카고 컬트란 실제로 필요한 이유나 맥락을 이해하지 못한 채 최신 자바스크립트 프레임워크·도구·패턴을 무조건 따라 쓰는 관행을 의미.

지금은 단순히 제목 하나 바꾸는 데도 엔지니어 4명, 프레임워크 세 개, CI/CD 파이프라인이 필요합니다. 웹페이지 하나 올리는 일이 불필요하게 복잡해졌습니다.

이것은 진화가 아닙니다. 스스로 만들어낸 복잡성일 뿐입니다. 그런데도 우리는 이것을 당연하게 여깁니다. 왜냐하면 언젠가부터 우리는 사용자, 아니라 개발자를 위한 웹사이트를 만들기 시작했기 때문입니다.

어떻게 여기까지 왔는가

2010년 즈음, 무언가가 변했습니다. 아이폰이 세상을 휩쓸고 있었습니다. 네이티브 앱은 세련되고, 빠르고, 부드러웠습니다. 동시에 최초의 주류 자바스크립트 프레임워크인 Angular가 등장했습니다.

그리고 모든 CMO(마케팅 임원)들이 웹사이트 기획서에서 똑같은 요구를 하기 시작했습니다.

“앱처럼 보이게 만들 수 있을까요?”

개발자들은 새로운 프레임워크와 선의로 무장하고 이렇게 대답했습니다.

“네.”

이론적으로, 자바스크립트는 매끄러운 전환과 세련된 UI를 구현할 수 있었습니다. 그래서 우리는 그 약속을 향해 달려갔습니다. 아니, 달려가려 했습니다.

하지만 결과는 달랐습니다. 앱 같은 성능은 나오지 않았습니다. 더 나은 사용자 경험도 없었습니다. 대신 복잡성의 무한 경쟁만 남았습니다.

단순한 문제(내비게이션, 레이아웃 등)를 마치 거대한 애플리케이션처럼 풀어야 했습니다.

동시에, 자바스크립트는 단순한 프론트엔드 언어를 넘어서기 시작했습니다. 애플리케이션과 폐쇄된 플랫폼을 만들어온 엔지니어들이 웹 생태계에 합류했습니다. 그들은 문서를 게시하는 것이 아니라 시스템을 설계하듯 웹을 대했습니다. 패턴, 상태 관리, 의존성 주입, 추상화된 로직.

결과는 무엇이었을까요? 한 명의 사용자가 단순히 “글 읽기”를 원해도, 시스템을 먼저 설계해야 하는 웹이었습니다.

그리하여, 우리는 밤을 새워가며 완전히 다른 니즈에 의해 웹 개발 규칙을 다시 써내려갔습니다. 콘텐츠를 위해서도, 속도를 위해서도, 상호운용성을 위해서도, 발견가능성을 위해서도 아니었습니다. 그저 코드를 위해서였습니다.

가면 갈수록 근본에서 더 멀어졌습니다. 시맨틱 HTML? 선택 사항입니다. 서버 측 렌더링(SSR)? 처음부터 재구성합니다.(웹이 원래 기본적으로 제공하던 SSR 기능을 프레임워크들이 버려놓고, 다시 복잡하게 새로 구현하고 있다는 비판) 접근성? 시간이 있다면 할수도요. 성능? 서버 대신 사용자의 장치에 부담을 주어 비용을 절약할 수 있다면 누가 신경이나 쓰겠어요?

그래서 점차 웹은 게시하기 전에 컴파일해야 하는 것이 되었습니다. 사용자가 필요해서가 아니라 개발자들이 현대스러움을 느끼길 원했기 때문입니다.

그리고 우리는 여전히 그 결정에 대한 대가를 치르고 있습니다.

개발자 경험(DX) 숭배

오늘날 우리는 DX(Developer Experience, 개발자 경험)를 최적화합니다. UX도 아니고, 성능도 아니고, 결과도 아닙니다.

프레임워크는 DX를 내세웁니다. 문서는 세련되고, 온보딩은 매끄럽습니다. CLI 명령 한 줄로 앱을 띄우고, 아직 콘텐츠 한 줄도 작성하지 않았는데 뭔가 생산적인 기분이 듭니다.

하지만 좋은 DX가 곧 좋은 UX를 보장하지는 않습니다. 오히려 반대일 때가 많습니다. DX가 편리해질수록 추상화가 늘어나고, 추상화가 늘어날수록 사용자와는 멀어집니다.

오늘날 우리는 버튼 하나를 만들기 위해 컴포넌트 라이브러리를 씁니다. 메타데이터를 자바스크립트 함수에서 관리합니다. 이미지 로딩 전략을 설정 파일 깊숙이 숨겨둡니다.

모든 것이 개발자를 위한 최적화입니다. 사용자에게는 적대적일 뿐입니다.

이건 우연이 아닙니다. 문화적인 문제입니다. 우리는 복잡성이 칭찬받는 업계를 만들어 왔습니다. 영리함이 보상받고, 공학적 세련됨이 명확성, 사용성, 혹은 상업적 효과보다 더 가치 있게 여겨지는 업계 말이죠.

SSR 호환성 문제를 언급하는 게, “왜 블로그에 React를 쓰고 있지?”라고 묻는 것보다 더 쉽게 이길 수 있는 논거가 됩니다.

그래서 우리는 계속 잘못된 것들을 최적화합니다. 왜냐하면 기분이 좋으니까. 재미있으니까. 현대적으로 보이니까. 그리고 아무도 그만두라고 하지 않으니까.

복잡성이 당연한 것이 되다

악순환이 이어지고 있습니다.

우리는 이제 복잡성을 단순히 용인하는 게 아니라, 당연하게 여깁니다.

모든 사이트가 빌드 단계, 번들러, 하이드레이션 전략, 라우팅 계층, API 계층, 디자인 시스템, 그리고 교묘한 캐시 무효화 로직을 필요로 한다고 가정합니다.

기본적인 콘텐츠를 제공하기 위해 마이크로서비스로 나누고, 엣지 네트워크에 호스팅하며, 배포 파이프라인까지 구축합니다.

블로그 글을 올리든 전자상거래 사이트를 만들든 상관없습니다. 사용하는 스택은 똑같습니다. 무겁고, 추상적이며, 유용성의 끝자락까지 밀어붙인 엔지니어링입니다.

그리고 아무도 완전히 이해하지 못합니다. 마케터도, SEO 담당자도, 심지어 6개월 전에 이걸 만든 개발자조차도요.

새로운 도구가 나올 때마다 새로운 추상화, 새로운 문법, 새로운 사고 모델이 쏟아집니다. 단순히 제목, 메타 태그, 레이아웃을 조금 수정하는 것도 세 단계를 거쳐 배포해야 가능한 일이 됩니다.

이건 광기입니다.

우리는 웹을 단지 몇 킬로바이트의 텍스트를 제공하기 위해 항공 교통 관제 시스템처럼 다시 만들어버렸습니다.

그리고 최악인 건? 이 복잡성의 대부분은 원래 기본으로 제공되던 것들을 억지로 덧대어 흉내 내려는 데서 비롯된다는 겁니다. 라우팅, 메타데이터, 캐싱, 템플릿, 레이아웃 말이죠.

우리는 혁신하고 있는 게 아닙니다. 웹이 이미 제공하던 도구들을 부서진 버전으로 다시 만들고 있을 뿐이고, 그것도 형편없이 말입니다.

스택이 스스로를 재구성하는 방식

오늘날을 생각해보면, 아이러니하게도 수년간 추상화와 복잡성을 좇아온 끝에 자바스크립트 생태계는 우리가 잃어버린 것들을 다시 들여오려고 안간힘을 쓰고 있습니다.

서버 사이드 렌더링? 다시 유행입니다. 라우팅? 신중하게 관리됩니다. URL 구조, 메타데이터, 심지어 HTML 출력까지 — 모두 플러그인 하나하나를 통해 다시 재구성되고 있습니다.

라우팅이 신중하게 관리된다는 것의 의미:
CSR/SPA 환경에서는 라우팅이 단순히 “파일 ↔ URL” 매핑이 아니라, 개발자가 프레임워크 레벨에서 세심하게 설계하고 관리해야함. 이러한 상황을 비꼰 것

그리고 그 모습은 점점 우리가 처음 시작했던 것과 닮아갑니다. 서버에서 HTML을 렌더링하고, 사용자와 가까운 곳에 캐싱해 제공하는 전통적인 CMS 말이죠.

단지 이제는 더 느리고, 유지보수가 더 어렵고, 수많은 패키지·컴파일러·엣지 핸들러라는 불안정한 생태계에 의존할 뿐입니다.

우리는 지금 워드프레스와 그 기능들을 (재)구축하고 있지만, 10배의 오버헤드와 0의 사용성을 안고 있습니다.

더 나쁜 건, 새로운 계층이 추가될 때마다 새로운 버그, 호환성 문제, 그리고 인지적 부담이 따라온다는 사실입니다. 이제 단순히 홈페이지 하나 띄우기 위해 하이드레이션 로직, 캐시 전략, 빌드 파이프라인까지 유지해야 하는 상황입니다.

웃어넘길 수 있다면 좋겠지만, 실제로는 지쳐버릴 뿐입니다.

이건 새로움에 집착하는 개발 문화의 종착지입니다. 우리는 더 나은 웹사이트를 내놓고 있는 게 아닙니다. 단지 기본적인 인프라를 점점 더 꼬인 방식으로 다시 발명하고 있을 뿐이고, 그게 그럭저럭 돌아간다는 사실에 스스로 박수를 치고 있는 겁니다.

끝없는 불안정의 순환

스택은 결코 안정되지 않습니다.

아무것도 안정적이지 않고, 아무것도 완성되지 않습니다. 매 스프린트, 매 로드맵, 매 분기마다 새로운 이니셔티브가 등장합니다. 최신 프레임워크로 마이그레이션하라, 새로운 번들러를 도입하라, 라우팅 계층을 리팩터링하라, CMS 통합을 교체하라, 캐시를 다시 구축하라… 끝이 없습니다. 그리고 대부분은 도움이 되지 않습니다.

이 변화의 대부분은 실제 사용자 문제를 해결하지 않습니다. 단지 지난번 아키텍처 결정이 만들어낸 문제를 해결하고 있을 뿐입니다. 우리는 사용자 가치로 이어지는 방향으로 반복하는 게 아니라, 그저 가라앉지 않으려고 반복하고 있습니다.

그리고 스택이 자기 자신을 고치느라 바쁜 동안, 다른 모든 것들은 느려집니다.

컴포넌트 라이브러리가 유연하지 않아서 마케팅 캠페인이 지연됩니다. 분석 계층이 하이드레이션 전략과 호환되지 않아 A/B 테스트가 무산됩니다. 콘텐츠 업데이트는 빌드를 기다리느라 며칠씩 늦춰집니다. 기본적인 SEO 수정조차 백로그에 파묻혀버립니다.

한편, 사용자는 여전히 페이지를 불러오지 못합니다.

이것이 복잡성이 곧 제품이 되어버렸을 때 벌어지는 일입니다. 우리는 더 이상 결과를 위해 최적화하지 않습니다. 최적화 계층 자체를 최적화합니다.

그리고 그걸 또 반복합니다.

부수적 피해: 마케터와 사용자

이 모든 복잡성은 개발자만 괴롭히는 게 아닙니다. 다른 모두를 배제해 버립니다.

마케터는 티켓을 올리지 않고는 카피를 수정하거나 실험을 진행할 수 없습니다. 콘텐츠를 미리 보기, 레이아웃을 테스트하기, 페이지를 런칭하는 일조차 불가능합니다. 모든 변경 사항은 개발자, 파이프라인, 승인, 리빌드를 거쳐야 합니다.

SEO 담당자는 제어할 수도 없는 렌더링 문제를 진단하느라 발이 묶입니다. 페이지가 비어 있거나, 늦게 뜨거나, 아예 안 뜨기도 합니다. 크롤 트랩이 생기고, 메타데이터는 사라집니다. 구조화된 데이터는 자바스크립트 객체 안에 묶여 방치됩니다.

콘텐츠 전략가와 에디터는 사용자가 실제로 보는 것과 전혀 연결되지 않은 JSON 블롭, 마크다운 파일, 혹은 헤드리스 CMS 폼을 편집하는 처지에 놓입니다.

기본적인 QA조차 엉망입니다. 페이지가 올바른 제목을 보여주나요? 캐노니컬 태그가 제대로 해석되나요? 배포를 끝내야 겨우 알 수 있습니다. 아마도요.

캐노니컬 태그란?
SEO에서 중요한 개념으로, 한 콘텐츠가 여러 URL로 접근 가능할 때, 검색엔진이 중복된 페이지를 다른 페이지로 오인하지 않도록 대표 URL을 지정하는 역할을 함.
사용법: <link rel="canonical" href="정식 URL" /> 형태로 HTML <head> 안에 삽입

그리고 사용자들은? 로딩 스피너를 멍하니 바라봅니다. 고장 난 버튼을 눌러봅니다. 뒤로 가기 버튼이 다시 작동하기를 기다립니다. 레이아웃이 제자리를 찾으며 텍스트가 흔들리는 모습을 지켜봅니다.

이건 웹의 미래가 아닙니다. 느리게 무너져가는 재앙입니다.

우리는 웹사이트를 더 어렵게 만들었습니다. 발행하기도, 찾기도, 사용하기도, 유지하기도 힘들게 만들었습니다. 그것도 모두 "모던 개발"이라는 이름으로 말이죠.

자바스크립트는 강력하지만 잘못 사용되고 있습니다

분명히 해두지만, 자바스크립트는 빌런이 아닙니다. 자바스크립트는 강력하고, 필수적이며, 풍부한 인터랙션, 동적 콘텐츠, 실시간 업데이트를 가능하게 합니다. 단순한 페이지가 아니라 도구를 만들 수 있게 해줍니다.

현명하게 사용된다면, 자바스크립트는 웹을 한 단계 끌어올립니다.

하지만 대부분의 웹사이트는 도구일 필요가 없습니다. 복잡한 상태 관리가 필요하지도, 실시간 데이터나 동적 라우팅이 필요하지도 않습니다. 그저 앱이 아니라 브로슈어, 카탈로그, 포트폴리오, 기사일 뿐입니다.

이런 용도에 현대적인 자바스크립트 스택은 완전히 과잉입니다.

심지어 전자상거래 사이트조차 — 제품 옵션, 변형 선택기, 장바구니 담기 기능, 모달 오버레이 같은 기능이 있더라도 — 완전한 프레임워크가 필요하지 않습니다. 최소한의, 가볍고 목적에 맞는 자바스크립트만으로도 충분히 구축할 수 있습니다. 클라이언트 사이드 라우팅도, 하이드레이션도, 거대한 컴포넌트 트리도 필요 없습니다.

잘 작성된 바닐라 자바스크립트 몇 줄(혹은 네, jQuery조차도)이 대부분 웹사이트에 필요한 기능의 95%를 처리할 수 있습니다. 더 빠르고, 더 단순하며, 더 접근 가능하게요.

현대적인 CSS만으로도 과거에 자바스크립트가 필요했던 많은 작업들을 처리할 수 있습니다. 토글, 모달, 캐러셀조차도요. 덕분에 스크립트 자체의 필요성이 줄어들었습니다.

물론 일부 사이트는 실제 클라이언트 사이드 상태가 필요합니다. 로그인 상태, 통화 선택기, 지역별 가용성 같은 것들이죠. 하지만 이런 것들조차 서버 사이드 로직이나 간단한 비동기 자바스크립트, AJAX로 더 깔끔하고 효율적으로 처리할 수 있습니다. "로그인됨" 버튼 하나 띄우거나 USD에서 EUR로 바꾸는 데 완전한 리액티브 런타임이 필요하지는 않습니다.

하지만 우리는 습관적으로 프레임워크를 집어 듭니다. 단순한 연락처 페이지조차 React로 만듭니다. 정적 콘텐츠에도 하이드레이션 전략을 씁니다. 존재할 필요조차 없는 코드를 컴파일하고, 번들링하고, 트랜스파일하고, 최적화합니다.

이건 단순히 낭비가 아닙니다. 해롭습니다.

사용자의 주의력, 개발자의 시간, 비즈니스 자원을 아무도 원하지 않은 상호작용을 흉내 내는 데 태워버리고 있습니다.

자바스크립트는 케이크 위의 아이싱이어야 합니다. 케이크 자체도, 오븐도, 레시피도, 싱크대까지도 되어서는 안 됩니다.

권력의 문제

스택이 복잡해질수록 권력은 개발자에게 더 집중됩니다.

마케터, 콘텐츠 에디터, SEO 담당자, 디자이너 — 모두가 프로세스에서 배제됩니다. 이제 단순한 작업조차 기술적 숙련도를 요구하기 때문입니다. 타이틀 태그를 바꾸고 싶나요? 엔지니어링 팀에 문의해야 합니다. 캠페인을 시작하고 싶나요? 티켓을 올리고 두 번의 스프린트를 기다려야 합니다.

모든 흐름이 개발팀을 거칩니다. 이는 곧 개발팀이 무엇이 중요한지, 무엇이 출시되는지, 무엇이 무기한 후순위로 밀리는지를 결정한다는 뜻입니다.

그리고 복잡성이 더해질수록, 그들은 점점 더 없어서는 안 될 존재가 됩니다.

이건 (대부분) 악의적인 게 아닙니다. 구조적인 문제입니다. 스택은 개발자에 의해, 개발자를 위해 만들어졌습니다. 무언가 고장 나거나, 수정이 필요하거나, 설명이 필요할 때마다 결국 만든 사람에게로 돌아갑니다. 그 과정이 모델을 강화하고, 의존성을 심화시키며, 더 많은 추상화를 정당화합니다. 그리고 더 많은 통제권을 쥐게 합니다.

이건 단순한 기술적 문제가 아닙니다. 조직적 문제입니다. 우리는 웹을, 그 기계를 이해하는 유일한 사람들에게 통째로 넘겨버렸습니다. 하지만 그들은 기계를 고치느라 너무 바빠, 애초에 그 기계가 정말 필요했는지를 돌아볼 여유조차 없습니다.

제대로 동작하는 웹사이트란

더 나은 길이 있습니다. 그렇다고 인터넷을 완전히 갈아엎거나 2005년으로 돌아갈 필요는 없습니다.

CMS를 버릴 필요도 없고, 자바스크립트를 금지할 필요도 없습니다. 다만 모든 웹사이트를 소프트웨어 제품처럼 취급하는 걸 멈추면 됩니다.

대부분의 사이트가 필요한 건 단순합니다. 빠르게 로드되고, 쉽게 탐색할 수 있으며, 검색에 잘 노출되고, 사용자가 간단한 일을 할 수 있으면 됩니다 — 읽기, 클릭, 스크롤, 구매. 그게 전부입니다. 그리고 이를 위한 도구는 이미 우리 손에 있습니다:

• 서버 렌더링된 HTML
• 시맨틱 마크업
• 깔끔한 URL
• 가벼운 템플릿
• 엣지 캐싱
• 진짜 가치를 더할 때만 사용하는 자바스크립트

그게 워드프레스일 수도 있고, Eleventy일 수도 있고, 맞춤형 셋업일 수도 있습니다. 중요한 건 도구가 아니라 마인드셋입니다.

사용자를 위해 만들고, 성능을 위해 만들고, 유지보수를 위해 만들어야 합니다.

영리함보다 단순함을. 추상화보다 투명성을. 아키텍처보다 결과를 선택해야 합니다.

우리는 여전히 현대적인 워크플로우를 가질 수 있습니다. 콘텐츠를 버전 관리할 수 있고, 미리 보기, 협업, 배포, 반복을 할 수 있습니다. 하지만 그 토대는 웹이어야 합니다. 앱도, 껍데기도, 시뮬레이션도 아닙니다.

이건 과거로 돌아가자는 게 아닙니다. 끝없는 추락을 멈추자는 겁니다.

웹은 다시 제대로 작동할 수 있습니다. 우리가 그렇게 하도록 놔주기만 하면 됩니다.

웹을 다시 되찾으십시오

당신의 웹사이트가 생각보다 훨씬 관리하기 어렵다고 느낀 적이 있다면, 그건 착각이 아닙니다.

제목 태그 하나 바꾸는 데 며칠이 걸리고, 상품 페이지가 자꾸 깨지고, 블로그가 자바스크립트 없이는 열리지 않는다면… 그건 “원래 그런 것”이 아닙니다. 그건 선택입니다. 당신이 없는 자리에서 내려진 선택 말이죠.

그러니 질문하세요. 문제를 제기하세요.

• “왜 거의 정적인 사이트에 풀 JS 프레임워크를 쓰고 있나요?”
• “왜 엔지니어 도움 없이는 콘텐츠를 수정할 수 없나요?”
• “왜 제목을 바꾸는 데 빌드 파이프라인이 필요한가요?”
• “이건 그냥 HTML이면 안 되나요?”

아키텍처에 이의를 제기하려고 코드를 쓸 필요는 없습니다. 결과를 우선시하기만 하면 됩니다.

그리고 기억하세요 — 복잡성은 단순히 기술적 부담이 아니라 재정적 부담이기도 합니다. 더 많은 엔지니어, 더 느린 출시, 더 높은 유지 비용, 줄어든 민첩성. 스택이 비대해질수록 비용도 커집니다.

빠른 사이트, 쉬운 발행, 더 나은 검색 순위, 만족스러운 사용자 경험.

이건 요구할 수 있는 것들입니다.

그리고 전혀 무리한 요구가 아닙니다. 오히려 웹이 태생적으로 지향했던 바입니다.

이제는 더 나은 것을 요구해야 할 때입니다.

더 묻고, 더 기대하고, 아키텍처가 아니라 결과를 요구하세요.

웹은 우연히 망가진 게 아닙니다. 설계 방식 때문에 망가졌습니다.

물론 그렇다고 프레임워크가 필요 없다는 뜻은 아닙니다. 규모가 크거나 분산된 팀이라면 아키텍처적 비계(scaffolding), 공유된 규약, 모듈식 접근법이 도움이 됩니다. 하지만 그 비계는 대체로 규모에 맞게 설계되지 않습니다. 스스로 존재 이유를 정당화하려고 점점 더 커지고, 결국 그 복잡성을 유지하기 위해 더 많은 엔지니어가 필요해지는 악순환을 만듭니다.

프레임워크가 빠르고, 접근 가능하며, SEO 친화적일 수는 있습니다. 하지만 솔직히 말해 현실에서는 거의 그렇지 않습니다. 전문성, 시간, 세심한 관리가 뒷받침되지 않는 한 말이죠. 대부분의 개발자는 자신이 모르는 걸 모릅니다. 그래서 기본 설정이나 마법 같은 미들웨어에 의존하다가 기본적인 기능을 깨뜨리곤 합니다.

그 결과는 뻔합니다.

• 망가진 뒤로 가기 버튼
• 비대해진 이미지
• 접근 불가능한 마크업
• URL답지 않은 URL
• 사라진 메타데이터
• 복사조차 안 되는 콘텐츠
• 키보드로 접근 불가능한 버튼
• 사용자를 가둬버리는 모달
• 이유 없이 초기화되는 스크롤 위치
• 읽는 중간에 바뀌는 헤드라인
• 현실과 맞지 않는 분석 데이터
• 믿을 수 없는 프리뷰 환경
• 그리고… 결국에는 뜨긴 하는 페이지

모두 고칠 수 있습니다. 모두 피할 수 있습니다. 모두 이 일에 맞지 않는 도구를 선택했기 때문에 생긴 문제들입니다.

이건 테이블 레이아웃 시절로 돌아가자는 것도, 자바스크립트를 금지하자는 것도 아닙니다.

의도를 가지고 개발하자는 겁니다.
웹이 기본적으로 제공하는 것들을 이해하고, 굳이 처음부터 다시 만들려는 충동을 거부하자는 겁니다.

순수함이 목적이 아닙니다. 결과가 목적입니다. 작동하는 것을 쓰세요.

다만 그것이 정말 사용자를 위한 것인지, 아니면 단지 개발자를 위한 것인지는 반드시 질문해야 합니다.