원래 글의 의도는 단순히 복잡해진 JS 프레임워크만을 비판하는 것이 아닙니다.
편의를 위하여 위에 있는 한국어 번역본 링크에서 인용하도록 하겠습니다.
지금은 단순히 제목 하나를 바꾸는 데도 4명의 엔지니어, 3개의 프레임워크, 그리고 CI/CD 파이프라인이 필요합니다. 웹페이지를 게시하는 것이 이상할 정도로 복잡해졌습니다.
그렇게 점진적으로, 웹은 게시하기 전에 컴파일해야 하는 것이 되었습니다. 사용자가 필요해서가 아니라. 개발자가 현대적으로 느끼기를 원했기 때문입니다.
모든 것이 개발자를 위해 최적화되었고, 다른 모든 사람에게는 적대적입니다.
우리는 더 이상 복잡성을 단순히 감내하는 하는 것이 아니라 당연한 것으로 여깁니다. 모든 사이트에 빌드 단계, 번들러, 하이드레이션 전략, 라우팅 레이어, API 레이어, 디자인 시스템, 그리고 영리한 캐시 무효화 로직이 필요하다고 가정합니다. 마이크로서비스로 구축하고, 엣지 네트워크에 호스팅하며, 단순한 콘텐츠를 전달하기 위해 파이프라인을 배포합니다.
우리는 워드프레스와 같은 플랫폼의 기능들을 다시 만들고 있지만, 10배 더 무거우면서도 사용성은 훨씬 떨어지는 결과를 만들어내고 있습니다. 더 나쁜 것은, 모든 새로운 레이어가 새로운 버그, 새로운 호환성 문제, 새로운 인지적 부담을 도입한다는 것입니다. 이제 우리는 단순히 홈페이지를 온라인에 올리기 위해 하이드레이션 로직과 캐시 전략 그리고 빌드 파이프라인을 유지보수하고 있습니다.
컴포넌트 라이브러리가 충분히 유연하지 않아서 마케팅 캠페인이 지연됩니다. 분석 레이어가 하이드레이션 전략과 호환되지 않아서 A/B 테스트가 취소됩니다. 콘텐츠 업데이트는 빌드를 며칠씩 기다려야 합니다. 기본적인 SEO 조정은 백로그에 묻혀버립니다.
마케터들은 티켓을 올리지 않고는 카피를 업데이트하거나 실험을 실행할 수 없습니다. 콘텐츠를 미리 보거나, 레이아웃을 테스트하거나, 페이지를 내보낼 수 없습니다. 모든 변경 사항은 개발자, 파이프라인, 승인, 재구축을 거쳐야 합니다.
마케터, 콘텐츠 편집자, SEO 담당자, 디자이너 이들은 모두 프로세스에서 배제됩니다. 이제 간단한 작업조차 기술적 유창함이 필요하기 때문입니다. 타이틀 태그를 바꾸고 싶다고 하면 엔지니어와 상의하시라고 할 것이며, 캠페인을 내보내고 싶다면, 티켓을 올리고 두 스프린트를 기다리라고 할 것입니다.
모든 것이 개발팀을 통해 흘러갑니다. 즉, 개발팀이 무엇이 중요한지, 무엇이 배포되는지, 무엇이 무기한 우선순위에서 밀리는지 결정한다는 의미입니다. 그리고 그들이 더 많은 복잡성을 추가할수록, 그들은 더 불가결해집니다.
원 글의 의도를 잘못 이해 하신거 같아요.
"...여기에는 Git 버전 관리와 CI/CD 파이프라인이 붙어 있고, 스테이징 서버와 실제 운영 서버를 분리시켜 놨습니다. Main 브랜치에 Pull Request가 병합되면 파이프라인에서 번들러를 돌린 산출물을 스테이징 서버에 자동으로 배포하고, 담당자가 스테이징 서버를 확인한 뒤 배포를 최종 승인하면 그게 다시 운영 서버에 배포되는 형태로 되어 있습니다. 과거에는 그냥 FTP를 통해 원본 파일을 운영 서버에 바로 덮어씌우는 방식이었는데, 관련 업무가 저희 팀으로 넘어온 뒤에 이렇게 변경하였습니다.
이게 정말 비합리적인 복잡성일까요?"
라고 하셨는데 별로 관련이 없는 글 같습니다. 배포와 관리를 그렇게 하는 정도의 일과 이 글이 주장하는 바는 많이 다른거 같아서요.