(번역)자바스크립트가 웹을 망가뜨렸습니다. (그리고 이를 진보라고 불렀습니다)

원문: https://www.jonoalderson.com/conjecture/javascript-broke-the-web-and-called-it-progress/

대부분의 웹사이트는 끔찍합니다.

그저 느리기만 한 게 아닙니다. 끔찍합니다. 비대하고, 불안정하며, 오버 엔지니어링 된 재앙입니다. 느리게 로딩되고, 불규칙하게 렌더링 되며, 메가바이트 크기의 자바스크립트 뒤에 콘텐츠를 숨깁니다. 모바일에서는 깨집니다. 사용자를 힘들게 하고 검색 엔진을 혼란스럽게 합니다. 유지보수가 불가능합니다. 그리고 어떻게든 우리는 이것을 진보라 말하고 있습니다.

비극적인 것은, 이 모든 것이 불필요하다는 점입니다. 한때 우리에게는 빠르고, 안정적이며, 회복력 있는 웹이 있었습니다. 하지만 우리는 그것을 자바스크립트 화물 숭배(cargo cult)로 대체했습니다.

역자주: 화물 숭배는 원래 태평양 섬 지역에서 나타난 종교 현상으로, 제2차 대전 당시 미군이 가져온 물자(카고)를 다시 불러오기 위해 활주로나 관제탑을 모방해서 만드는 의식을 가리킨다. 현재는 성공의 본질적 원인을 이해하지 못한 채 겉모습이나 형식만 따라 하는 행위를 비유적으로 표현할 때 사용된다.

지금은 단순히 제목 하나를 바꾸는 데도 4명의 엔지니어, 3개의 프레임워크, 그리고 CI/CD 파이프라인이 필요합니다. 웹페이지를 게시하는 것이 이상할 정도로 복잡해졌습니다.

이것은 진화가 아닙니다. 스스로 만들어낸 복잡성입니다. 그리고 우리는 이를 당연하게 여기게 되었습니다. 언제부턴가 사용자가 아닌 개발자를 위한 웹사이트를 만들기 시작했기 때문입니다.

어떻게 여기까지 오게 되었는가

2010년경, 변화가 시작되었습니다. 아이폰이 상승세를 타고 있었고 네이티브 앱은 세련되고, 빠르며, 유려했습니다. 웹을 위한 최초의 주류 자바스크립트 프레임워크인 Angular가 막 등장했습니다. 그리고 이 시점에 갑자기 모든 CMO가 웹사이트 기획서에서 같은 요구를 하기 시작했습니다. “앱처럼 느껴지게 만들 수 있나요?”

새로운 프레임워크와 선의로 무장한 개발자들은 그렇다고 답했습니다. 자바스크립트는 이론적으로 원활한 전환과 매끄러운 UI를 만들 수 있었습니다. 그래서 우리는 그 약속을 향해 구축했고 시도했습니다.

스포일러: 우리는 앱 같은 성능을 얻지 못했습니다. 더 나은 사용자 경험도 얻지 못했습니다. 우리가 얻은 것은 누가 더 복잡한 기술을 쓰는지 경쟁하는 상황이었습니다.

우리는 내비게이션이나 레이아웃 같은 단순한 문제를 본격적인 애플리케이션을 위해 만들어진 도구로 해결하기 시작했습니다.

동시에, 자바스크립트는 더 이상 단순한 프런트엔드 언어가 아니게 되었습니다. Node.js의 부상과 함께 JS는 서버 사이드로 이동했고, 이와 함께 많은 앱 개발자가 웹 생태계로 몰려들었습니다. 이들은 웹 디자이너나 콘텐츠 퍼블리셔가 아니었습니다. 문서가 아닌 애플리케이션을 만들도록 훈련받은 엔지니어들이었습니다. 이 엔지니어들은 아키텍처를 우선시하는 사고방식과 함께 패턴, 상태 관리, 의존성 주입, 추상화된 로직 같은 개념들을 가져왔습니다. 그 결과 사용자가 글을 읽기만 하면 되는 단순한 상황에서도 페이지를 만들고 끝내는 것이 아닌 시스템을 설계하는 것으로 문화가 서서히 바뀌었습니다.

그래서 우리는 거의 하룻밤 사이에 완전히 다른 필요에 따라 웹 개발의 규칙을 다시 작성했습니다. 콘텐츠, 속도, 상호 운용성, 발견 가능성이 아니라 단지 코드만을 위해서 말입니다.

우리가 이 길을 더 멀리 갈수록, 스택은 기본 원칙에서 더 멀어졌습니다. 시맨틱 HTML은 선택사항이 되었고, 서버 사이드 렌더링은 처음부터 다시 구축해야 했습니다. 접근성은 시간이 있을 때나 고려하는 것이 되었고, 성능은 서버 대신 사용자의 디바이스에 로딩 부담을 떠넘겨 비용을 절약할 수 있다면 누가 신경 쓰겠느냐는 식이었습니다.

그렇게 점진적으로, 웹은 게시하기 전에 컴파일해야 하는 것이 되었습니다. 사용자가 필요해서가 아니라. 개발자가 현대적으로 느끼기를 원했기 때문입니다.

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

개발자 경험(Developer Experience)의 숭배(cult)

오늘날 우리는 “DX”, 개발자 경험을 최적화합니다. 사용자 경험이 아닙니다. 성능도 아닙니다. 결과도 아닙니다.

오늘날의 인기 있는 프레임워크는 DX로 판매됩니다. 문서가 매끄럽게 작성되어 있고, 온보딩이 쉽습니다. 도구는 영리하고, 통합되어 있으며, 영리합니다. CLI 명령으로 새 앱을 시작할 수 있고 콘텐츠 한 줄을 작성하기도 전에 이미 생산적이라고 느낄 수 있습니다.

하지만 좋은 DX가 좋은 UX를 보장하지는 않습니다. 사실 종종 그 반대입니다. 개발자에게 편한 것을 만들수록 더 많은 추상화를 추가하기 때문입니다. 그리고 모든 추상화는 만들어지는 것과 그것을 위한 사람들 사이에 거리를 만듭니다.

이제 우리에게는 버튼 마크업을 생성하는 컴포넌트 라이브러리가 있습니다. 자바스크립트 함수에서 관리되는 페이지 메타데이터가 있습니다. 설정 파일에 묻힌 이미지 로딩 전략이 있습니다.

모든 것이 개발자를 위해 최적화되었고, 다른 모든 사람에게는 적대적입니다.

이것은 우연이 아닙니다. 문화적인 것입니다. 우리는 복잡성이 찬양받는 산업을 만들었습니다. 영리함이 보상받는 곳이자 엔지니어링 정교함이 명확성, 사용성, 상업적 효과성보다 더 가치 있게 여겨지는 곳이었죠.

*”블로그에 왜 리액트를 사용하는가?”*라고 묻는 것보다 SSR 호환성 문제를 인용해 논증에서 이기는 것이 더 쉽습니다.

그래서 우리는 계속해서 잘못된 것들을 최적화합니다. 기분이 좋기 때문입니다. 재미있기 때문입니다. 현대적으로 보이기 때문입니다. 그리고 아무도 우리를 막지 않기 때문입니다.

복잡성이 기본값이 됩니다

이렇게 악순환이 반복됩니다.

우리는 더 이상 복잡성을 단순히 감내하는 하는 것이 아니라 당연한 것으로 여깁니다. 모든 사이트에 빌드 단계, 번들러, 하이드레이션 전략, 라우팅 레이어, API 레이어, 디자인 시스템, 그리고 영리한 캐시 무효화 로직이 필요하다고 가정합니다. 마이크로서비스로 구축하고, 엣지 네트워크에 호스팅하며, 단순한 콘텐츠를 전달하기 위해 파이프라인을 배포합니다.

블로그 포스트를 게시하든 이커머스 사이트를 만들든 상관없습니다. 스택은 동일합니다. 무겁고, 추상적이며, 유용성의 끝까지 엔지니어링 되었습니다. 그리고 아무도 그것을 이해하지 못합니다. 완전히는 말입니다.

마케터도, SEO 담당자도, 심지어 6개월 전에 그것을 만든 개발자도 아닙니다. 모든 새로운 도구는 새로운 추상화, 새로운 문법, 새로운 멘탈 모델을 가져옵니다. 제목, 메타 태그, 또는 레이아웃에 대해 간단한 수정을 하는 것이 3단계 배포 프로세스가 됩니다.

미친 짓입니다.

우리는 단지 몇 킬로바이트의 텍스트를 제공하기 위해 항공 교통관제 시스템처럼 웹을 재구축했습니다.

가장 최악인 점은 대부분의 복잡성이 우리가 원래 가지고 있던 것들을 다시 만들기 위해 존재한다는 것입니다. 라우팅, 메타데이터, 캐싱, 템플릿, 레이아웃 같은 것들 말이죠.

우리는 혁신하고 있지 않습니다. 웹이 이미 제공했던 도구들의 망가진 버전을 재구축하고 있고, 이 또한 제대로 하지 못하고 있습니다.

스택이 스스로를 되돌아보며 재구축하고 있습니다

이제 현재 상황을 보겠습니다. 아이러니하게도, 수년간 추상화와 복잡성을 추구한 뒤, 자바스크립트 생태계는 우리가 잃어버린 것들을 되찾기 위해 애쓰고 있습니다.

서버 사이드 렌더링은 다시 유행하고 있으며, 라우팅은 신중하게 관리되고 있습니다. URL 구조, 메타데이터, 심지어 HTML 출력까지 모든 것을 플러그인으로 하나씩 재구축하고 있습니다.

결국 우리가 처음 시작했던 것과 점점 더 비슷해지고 있습니다. 서버에서 렌더링 하고, 사용자에게 가까운 곳에 캐시 된 HTML을 제공하는 전통적인 CMS 말입니다.

하지만 이제 더 느리고, 유지 보수하기 어려우며, 패키지, 컴파일러, 엣지 핸들러의 취약한 생태계에 의존합니다.

우리는 워드프레스와 같은 플랫폼의 기능들을 다시 만들고 있지만, 10배 더 무거우면서도 사용성은 훨씬 떨어지는 결과를 만들어내고 있습니다.

더 나쁜 것은, 모든 새로운 레이어가 새로운 버그, 새로운 호환성 문제, 새로운 인지적 부담을 도입한다는 것입니다. 이제 우리는 단순히 홈페이지를 온라인에 올리기 위해 하이드레이션 로직과 캐시 전략 그리고 빌드 파이프라인을 유지보수하고 있습니다.

이렇게나 피로하지 않았더라면 웃겼을지도 모르겠습니다.

이것이 참신함에 사로잡힌 개발 문화의 엔드게임입니다. 우리는 더 나은 사이트를 만들고 있지 않습니다. 점점 더 복잡한 방식으로 기본 인프라를 재발명하며 거의 작동한다는 사실에 축하하고 있습니다.

반복과 불안정성의 순환

스택은 절대 안정되지 않습니다.

아무것도 안정적이지 않습니다. 아무것도 완성되지 않습니다. 모든 스프린트, 모든 로드맵, 모든 분기마다 새로운 이니셔티브가 있습니다. 최신 프레임워크로 마이그레이션 하고, 새로운 번들러를 채택하며, 라우팅 레이어를 리팩토링하고, CMS 통합을 교체하며, 캐시를 재구축합니다.

끝나지 않습니다. 그리고 거의 도움이 되지 않습니다.

이런 변동의 대부분은 실제 사용자의 문제를 해결하지 않습니다. 이전 아키텍처 결정으로 생긴 문제들을 해결하고 있을 뿐입니다. 우리는 임팩트를 위해 반복하는 것이 아니라 그냥 현상 유지를 위해 반복하고 있습니다.

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

컴포넌트 라이브러리가 충분히 유연하지 않아서 마케팅 캠페인이 지연됩니다. 분석 레이어가 하이드레이션 전략과 호환되지 않아서 A/B 테스트가 취소됩니다. 콘텐츠 업데이트는 빌드를 며칠씩 기다려야 합니다. 기본적인 SEO 조정은 백로그에 묻혀버립니다.

한편, 사용자들은 여전히 페이지를 로드할 수 없습니다.

이것이 복잡성 그 자체가 제품이 되었을 때 일어나는 일입니다. 우리는 더 이상 결과를 최적화하지 않습니다. 최적화하는 과정을 최적화할 뿐입니다.

그리고 이 과정을 반복합니다.

마케터와 사용자에 대한 부수적 피해

이 모든 복잡성은 개발자들을 좌절시킬 뿐만 아니라 다른 모든 사람을 배제합니다.

마케터들은 티켓을 올리지 않고는 카피를 업데이트하거나 실험을 실행할 수 없습니다. 콘텐츠를 미리 보거나, 레이아웃을 테스트하거나, 페이지를 내보낼 수 없습니다. 모든 변경 사항은 개발자, 파이프라인, 승인, 재구축을 거쳐야 합니다.

SEO 담당자들은 제어할 수 없는 렌더링 문제를 진단하려고 애쓰고 있습니다. 페이지가 비어 있거나, 늦게, 또는 전혀 로드되지 않거나 크롤러 트랩이 나타납니다. 메타데이터가 사라지기도 하고 구조화된 데이터가 자바스크립트 객체로 번들되어 제대로 인식되지 않습니다.

콘텐츠 전략가와 편집자들은 사용자가 실제로 보게 되는 것과 무관한 JSON 블롭, 마크다운 파일, 또는 헤드리스 CMS 폼을 편집해야 합니다.

기본적인 QA조차 엉망일 겁니다. 페이지가 올바른 제목을 보여주나요? 캐노니컬 태그가 올바르게 해결되나요? 배포하기 전까지는 알 수 없습니다. 아마도 말입니다.

그리고 사용자들은 어떨까요? 로딩 스피너를 응시하기도 하고 망가진 버튼을 탭하고 있습니다. 그리고 뒤로 가기 버튼이 스스로 고쳐지기를 기다리고 있으며, 레이아웃이 제자리로 섞이면서 텍스트가 리플로우되는 것을 보고 있습니다.

이것은 웹의 미래가 아닙니다. 슬로우 모션 재앙입니다.

우리는 현대적인 개발이라는 이름하에 웹사이트를 게시하기 더 어렵게, 찾기 더 어렵게, 사용하기 더 어렵게, 유지 보수하기 더 어렵게 만들었습니다.

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

명확히 하자면, 자바스크립트가 악역은 아닙니다. 자바스크립트는 강력하고 필수적입니다. 풍부한 상호작용, 동적 콘텐츠, 실시간 업데이트를 가능하게 합니다. 단순한 페이지가 아닌 도구를 만들 수 있게 해 줍니다.

현명하게 사용하면 웹을 향상시킵니다.

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

그리고 그런 사용 사례에서는 현대 자바스크립트 스택은 완전히 과도한 수단입니다.

제품 옵션, 옵션 선택 기능, 장바구니 추가 기능, 모달 오버레이가 있는 이커머스 사이트조차도 완전한 프레임워크가 필요하지 않습니다. 이 모든 것은 최소한의, 가벼운, 잘 타겟팅 된 자바스크립트로 구축할 수 있습니다. 클라이언트 사이드 라우팅, 하이드레이션, 그리고 컴포넌트 트리 없이 말이죠.

잘 작성된 바닐라 자바스크립트(또는 심지어 jQuery) 몇 줄로도 대부분의 웹사이트가 실제로 필요한 것의 95%를 처리할 수 있습니다. 그것도 더 빠르고, 더 간단하며, 더 접근하기 쉽게 말입니다.

또한, 모던 CSS만으로도 토글, 모달, 심지어 캐러셀 같이 우리가 자바스크립트를 사용해야 했던 많은 작업을 처리할 수 있어서 스크립팅의 필요성을 전반적으로 줄입니다.

물론 일부 사이트는 진짜로 클라이언트 사이드 상태 관리가 필요합니다. 로그인 상태, 통화 선택기, 지역별 서비스 제공 여부 같은 것들 말입니다. 하지만 이런 기능들조차 서버 사이드 로직이나 간단한 비동기 자바스크립트와 AJAX로 더 깔끔하고 빠르게 처리할 수 있는 경우가 많습니다. ‘로그인’ 버튼을 보여주거나 USD에서 EUR로 환율을 바꾸는 데 완전한 반응형 런타임까지 필요하지는 않습니다.

하지만, 우리는 프레임워크를 기본으로 선택합니다. 연락처 페이지를 만들기 위해 리액트에 손을 내밉니다. 정적 콘텐츠를 위해 하이드레이션 전략을 배포합니다. 존재할 필요가 없는 코드를 컴파일하고, 번들링하고, 트랜스파일하고, 최적화합니다.

단순히 낭비적인 것이 아닙니다. 해로운 것입니다.

우리는 아무도 요청하지 않은 상호작용을 시뮬레이션하기 위해 사용자의 관심, 개발자의 시간, 비즈니스 자원을 태우고 있습니다.

자바스크립트는 케이크 위의 장식 정도여야 합니다. 케이크 자체가 되어서는 안 되고, 하물며 오븐과 레시피, 심지어 부엌 전체가 되어서는 더더욱 안 됩니다.

권력 문제

스택이 복잡해질수록, 더 많은 권력이 집중됩니다.

마케터, 콘텐츠 편집자, SEO 담당자, 디자이너 이들은 모두 프로세스에서 배제됩니다. 이제 간단한 작업조차 기술적 유창함이 필요하기 때문입니다. 타이틀 태그를 바꾸고 싶다고 하면 엔지니어와 상의하시라고 할 것이며, 캠페인을 내보내고 싶다면, 티켓을 올리고 두 스프린트를 기다리라고 할 것입니다.

모든 것이 개발팀을 통해 흘러갑니다. 즉, 개발팀이 무엇이 중요한지, 무엇이 배포되는지, 무엇이 무기한 우선순위에서 밀리는지 결정한다는 의미입니다.

그리고 그들이 더 많은 복잡성을 추가할수록, 그들은 더 불가결해집니다.

이것은 (보통) 악의적이지 않습니다. 구조적입니다. 스택은 개발자에 의해, 개발자를 위해 만들어집니다. 그래서 무언가가 망가지거나, 바뀌어야 하거나, 설명이 필요할 때 그것을 만든 사람들에게 돌아갑니다. 이것이 모델을 강화하고 의존성을 깊게 만듭니다. 더 많은 추상화를 정당화하고, 더 많은 통제권을 갖게 됩니다.

이것은 단순한 기술적 문제가 아닙니다. 조직적 문제입니다. 우리는 기계를 이해하는 유일한 사람들에게 웹의 통제권을 넘겨주었습니다. 그리고 그들은 기계를 고치느라 너무 바빠서 애초에 그것이 필요했는지 멈춰서 묻지 못합니다.

작동하는 웹사이트

더 나은 방법이 있습니다. 그리고 인터넷을 완전히 다시 작성하거나 2005년으로 돌아갈 필요가 없습니다.

CMS를 포기할 필요가 없습니다. 자바스크립트를 금지할 필요가 없습니다. 단순히 모든 웹사이트를 소프트웨어 제품처럼 다루는 것을 멈추면 됩니다.

대부분의 사이트는 빠르게 로드되고, 탐색하기 쉽고, 검색에 나타나며, 사용자가 간단한 일을 할 수 있어야 합니다. 읽기, 클릭, 스크롤, 구매 그게 전부입니다. 그리고 우리는 이미 그것을 구축할 도구를 가지고 있습니다.

• 서버 렌더링 된 HTML
• 시맨틱 마크업
• 깔끔한 URL
• 가벼운 템플릿
• 엣지 캐싱
• 실제 효용을 더하는 합리적인 자바스크립트 사용

그것은 워드프레스일 수 있고 Eleventy, 커스텀 설정일 수 있습니다. 요점은 도구가 아니라 마인드 셋입니다.

사용자를 위해 구축하고 성능을 위해 구축하세요. 유지보수성을 위해 구축하세요.

영리함보다 단순함을 선택하세요. 추상화보다 투명성을 선택하세요. 결과를 아키텍처보다 우선시하세요.

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

이것은 뒤로 가자는 것이 아닙니다. 자유낙하를 멈추자는 것입니다. 웹은 다시 작동할 수 있습니다. 우리가 그렇게 하도록 놔두기만 하면 됩니다.

웹을 되찾기

여러분의 웹사이트가 관리하기 어렵다고 느낀 적이 있다면 착각이 아닙니다. 제목 태그 하나를 수정하는 데 며칠이 걸리고, 상품 페이지에 오류가 생기고, 블로그가 자바스크립트 없이는 로드되지 않는다면… 그것은 “원래 그런 것”이 아닙니다. 그것은 선택입니다. 여러분이 자리에 없을 때 내려진 선택 말입니다. 그러니 질문하고 반박하세요.

• “대부분 정적인 사이트에 왜 완전한 JS 프레임워크를 사용하고 있나요?”
• “왜 엔지니어링 도움 없이는 이 콘텐츠를 업데이트할 수 없나요?”
• “헤드라인 하나를 바꾸는 데 왜 빌드 파이프라인이 필요한가요?”
• “이것이 왜 그냥 HTML이 아닌가요?”

아키텍처에 이의를 제기하기 위해 코드를 작성할 필요는 없습니다. 결과물을 우선순위로 만들기만 하면 됩니다.

그리고 기억하세요. 복잡성은 단순히 기술적 부담이 아닙니다. 재정적 부담이기도 합니다. 더 많은 엔지니어. 더 느린 출시. 더 높은 유지보수 비용. 더 적은 민첩성. 스택이 비대해지면 비용도 함께 비대해집니다.

더 빠른 사이트. 더 쉬운 퍼블리싱. 더 나은 순위. 더 행복한 사용자.

여러분은 이런 것들을 요구할 수 있습니다.

왜냐하면 그것들은 비합리적이지 않기 때문입니다. 그것들은 웹이 만들어진 목적이기 때문입니다.

그리고 이제 더 나은 것을 요구할 때입니다.

더 많이 질문하세요. 더 많이 기대하세요. 아키텍처가 아닌 결과물을 위해 노력하세요.

웹은 우연히 망가진 것이 아닙니다. 의도적으로 망가진 것입니다. 그리고 우리는 그것을 받아들일 필요가 없습니다.

그렇다고 해서 프레임워크가 설 자리가 없다는 뜻은 아닙니다. 대규모 또는 분산된 팀은 종종 아키텍처 스캐폴딩, 공유 컨벤션, 모듈형 접근 방식의 이점을 얻습니다. 하지만 그 스캐폴딩은 거의 적절한 크기로 만들어지지 않습니다. 더 자주, 그것은 성장함으로써 자신을 정당화하고 자신이 도입한 복잡성을 유지하기 위해 더 많은 엔지니어의 필요성을 만들어냅니다.

그리고 네, 프레임워크는 빠르고, 접근성이 좋고, SEO 친화적일 수도 있습니다. 하지만 솔직히 말하면: 실제로 그런 경우는 거의 없습니다. 현실에서는 말입니다. 상당한 전문성, 시간, 그리고 주의 없이는 말입니다. 대부분의 개발자는 자신이 모르는 것을 모릅니다. 그들은 기본 설정, 그리고 기본을 조용히 망가뜨리는 마법 같은 미들웨어에 의존합니다.

결과는 어땠을까요? 망가진 뒤로 가기 버튼. 이미지 비대화. 접근할 수 없는 마크업. URL처럼 작동하지 않는 URL들. 사라지는 메타데이터. 복사할 수 없는 콘텐츠. 키보드로 접근할 수 없는 버튼. 사용자를 가두는 모달. 이유 없이 리셋되는 스크롤 위치. 읽는 중에 이동하는 헤드라인. 현실과 맞지 않는 애널리틱스. 거짓말하는 미리 보기 환경. 그리고 마침내… 로드되는 페이지들.

모두 고칠 수 있습니다. 모두 피할 수 있습니다. 모두 적합하지 않은 도구를 선택한 탓입니다.

이것은 테이블 레이아웃으로 돌아가거나 자바스크립트를 금지하자는 것이 아닙니다. 의도를 가지고 구축하자는 것입니다. 웹이 기본적으로 우리에게 제공하는 것을 이해하고 그것을 처음부터 다시 구축하려는 충동에 저항하자는 것입니다.

이것은 순수성에 관한 것이 아닙니다. 결과에 관한 것입니다. 작동하는 것을 사용하세요.

하지만 그것이 여러분의 사용자를 위해 작동하는지, 아니면 단지 여러분의 개발자들을 위해 작동하는지 의문을 가져보세요.