프론트엔드 트레드밀

• 오래 가는 제품일수록 프론트엔드 프레임워크 선택보다 재작성 논쟁에 쓰는 시간과 에너지가 더 큰 비용이 됨
• 제품이 5년 뒤에도 살아 있다면 성공이지만, 그 사이 선택한 프레임워크는 구식이 되거나 같은 이름의 새 버전으로 크게 바뀔 가능성이 큼
• 더 나은 제품팀은 새 도구로 갈아타기보다 현재 프레임워크를 깊이 이해해, 도구가 업무 진척을 막지 않을 만큼 숙련도를 높임
• 장기 비용을 줄이려면 복잡한 추상화보다 웹 플랫폼과 핵심 웹 기술에 가까이 붙는 선택이 현실적인 비즈니스 절충안이 될 수 있음
• 프론트엔드 생태계의 복잡성은 신입 개발자와 채용팀 모두를 어렵게 만들며, 웹 기본기가 약한 개발자는 다음 스택 변화에 더 취약해짐

---

재작성으로는 트레드밀에서 벗어나기 어려움

• 많은 프론트엔드 팀은 재작성이 더 나은 상태로 이어질 것이라고 믿지만, 오래 갈 제품에서는 프레임워크 선택 자체가 가장 중요한 기술 결정이 아님
• 제품이 5년 이상 지속되면 성공으로 볼 수 있으나, 그 기간 동안 선택한 프레임워크는 구식이 될 수 있음
  • 프론트엔드 커뮤니티는 계속 변화를 중심으로 움직여 왔고, 가까운 시점에 달라질 가능성도 낮음
  • 살아남은 인기 프레임워크도 내부는 완전히 달라질 수 있으며, 새 버전 번호 아래 사실상 재작성될 수 있음
• 팀이 집중해야 할 일은 새롭고 반짝이는 도구를 좇는 것이 아니라, 지금 쓰는 프레임워크를 충분히 익히는 것임
  • 도구가 업무 진척의 장애물이 되지 않을 정도의 이해와 숙련이 필요함
  • 대체 도구로 갈아타면 문제가 해결될 것이라는 기대는 함정에 가까움

웹 플랫폼에 가까울수록 장기 비용이 줄어듦

• 프론트엔드 기술이 자주 구식이 되는 비용을 줄이려는 회사라면 웹 플랫폼에 더 가까운 방향을 검토할 수 있음
  • 복잡한 추상화를 줄이고 웹이 실제로 무엇을 할 수 있는지 다시 배워야 함
  • 이것이 모든 문제의 정답이거나 무조건 더 낫다는 뜻은 아님
  • 장기적으로 더 많은 가치를 제공하고 비용을 낮출 수 있는 비즈니스 절충안이 될 수 있음
• 핵심 웹 기술에 가까이 있으면, 향후 유능한 엔지니어를 채용할 때 수백만 줄의 코드를 다시 써야만 일할 수 있다는 주장에 덜 휘둘림
• 엔지니어 개인에게도 특정 프레임워크를 계속 따라가는 것보다 핵심 웹 기술을 깊게 이해하는 편이 장기 시장 가치에 더 도움이 됨
  • 단기 채용 시장성 일부를 포기할 수는 있음
  • 인기 기술을 모두 배우려는 방식보다 커리어 지속성에 더 유리함
  • 특정 기술을 안다고 해서 시장 악화 같은 현실에서 보호받는 것은 아님

프레임워크 선호와 팀 비용

• 프레임워크 선호가 강한 엔지니어는 그 기준을 구직 조건에 반영해야 함
  • 이미 특정 프레임워크를 쓰는 팀에 들어간 뒤 자신이 선호하는 프레임워크로 전환시키려 하면 팀을 흔들고 비용을 크게 늘림
• 현재 프론트엔드 생태계의 복잡성은 신입 개발자와 기업 모두에게 부담을 줌
  • 신입 개발자는 취업에 충분한 기술을 익히기 어려워하고, 복잡한 도구에 압도됨
  • 기업은 일반 개발자 채용조차 더 어렵게 느끼며, 정규 개발자 직무의 진입 기준도 높아짐
  • 현재 기술 생태계를 배우는 사람이 웹 기본기를 배우지 못하면, 스택이 다시 바뀔 때 심각한 불리함을 겪을 수 있음
• 웹은 소프트웨어를 전달하는 유능하고 독특한 플랫폼이며, 시간이 지나며 더 좋아졌고 높은 수준의 하위 호환성을 유지해 왔음
  • 현재의 기본 도구들은 충분히 좋아졌지만, 프레임워크 계층은 플랫폼을 받아들이기보다 거슬러 작동하고 있음

[GN⁺]

Hacker News 의견들

• 최근 프론트엔드 코드의 빌드 시스템을 yarn에서 pnpm으로 바꾸는 작업을 했는데, 평소엔 백엔드 엔지니어지만 JS 쪽도 꽤 겪어봤음
  프론트엔드에 들어갈 때 가장 짜증 나는 건 정말 모든 게 deprecated처럼 보인다는 점임. 2022년에 apollo CLI를 썼다면 바로 deprecated가 되어 graphql-client 같은 전혀 다른 설정과 옵션을 가진 도구를 배워야 함. 결국 예전 것을 유지하고 pnpm의 Node 엔진 검사만 꺼서 불평하지 않게 만듦. 어떤 의존성을 패치 업그레이드하려 하면 타입 시그니처가 깨질 수 있어 그것도 고정하고, 언젠가 누군가 고치길 바라는 TODO를 코드베이스에 남김
  겨우 실행되게 만들면 설치 중 수백 개의 deprecated 경고가 흘러가고, 빌드가 끝나자마자 도망치게 됨
  프론트엔드 개발 전체가 깨지는 변경과 deprecated를 이렇게 받아들이는 정도가 정말 이상하게 느껴짐. 큰 Rust 프로젝트를 거의 4년 해왔는데 그동안 서드파티 라이브러리의 작은 깨지는 변경은 몇 번 있었지만, 애플리케이션을 크게 고쳐야 했던 주요 변경은 한 번뿐이었음. 반면 JS는 6개월도 못 가서 뭔가를 다시 써야 하는 것처럼 보임

  • 프론트엔드 쪽에서 이런 변화가 인플루언서들에 의해 많이 움직인다는 게 놀라움
    프론트엔드 세계는 다른 분야보다 소셜 미디어, YouTube, 심지어 Twitch까지 훨씬 적극적으로 받아들였음. 이런 인플루언서들은 relevance를 유지하려면 계속 새 소재가 필요하니, 콘텐츠로 만들 수 있는 새로운 것을 끊임없이 밀어붙임
    여기에 활발한 컨퍼런스 문화도 더해짐. 프론트엔드와 JS 컨퍼런스는 뜨는 새 주제를 발표하려는 큰 경쟁처럼 느껴짐
    프론트엔드 강좌를 파는 시장도 큼. 강좌 제작자들은 새 유행을 배우는 $700짜리 한정가 영상 강좌를 상사가 승인하게 만들어야 하는데, 그러려면 업계가 이미 모두 아는 옛것에서 멀어지게 해야 함. 그래서 새것을 강하게 밀고 옛것을 deprecated로 만듦
  • 가장 이상한 건 그 기반인 JS/HTML 자체는 본질적으로 매우 안정적인 기술이라는 점임
    15년 전에 작성한 작은 5KLOC짜리 순수 JS 웹앱이 한 줄도 바꾸지 않은 채 지금도 약 10명이 매일 쓰고 있음. 오히려 Win32 애플리케이션보다 더 잘 버팀
    프론트엔드의 churn 대부분은 단순히 정치적·조직적 실패에 가깝다고 봄
  • JS에서 6개월마다 뭔가를 다시 써야 하는 것처럼 느껴지지만, 사실 그렇게 하지 않는 것도 충분히 가능함. 다만 절제와 프로젝트에 무엇을 끌어들이는지 진지하게 신경 쓰는 태도가 필요함
    순수 JS/jQuery 시절에 시작했을 때 의존성 관리는 사실상 .js 파일을 vendor/ 디렉터리에 복사해 넣는 방식이었음. 이후 nodejs/npm이 나오고, 프론트엔드에선 npm 전 bower도 쓰였고, 갑자기 직접 만들지 말고 모듈을 내려받으라는 조언이 표준이 됨
    하지만 이미 그때도 수천 줄의 숨은 코드를 직접 소유하지 않고, 재미로 오픈소스를 하는 자원봉사자들에게 맡기는 게 맞는지 의문을 품은 사람이 많았음
    지금도 프로젝트를 오래 유지하고 싶다면 보이지 않는 부분을 너무 비대하게 만들지 않을 수 있음. “이 라이브러리에서 함수 하나만 필요하니 전체 라이브러리에 의존하지 말고 그 함수만 코드베이스에 복사하고 테스트를 붙이자”는 방식으로 작은 문제를 처리할 수 있음
    그래서 이건 JavaScript 자체 문제가 아니라 사람과 프로세스의 문제라고 봄. 이런 문제를 겪지 않는 JS 개발자도 많지만, 생태계의 큰 부분은 그렇지 않음
  • 최악인 건 이게 문화적 측면이라는 점임. 이런 deprecated와 깨지는 변경 지옥은 수백만 개의 작은 선택이 쌓인 결과임
    “MultiselectDropdown을 MultiSelectButtonDropdown으로 바꾸면 어때? API도 완전히 새걸로 바꾸자!” 같은 ‘매우 중요한’™ 깨지는 변경의 결과를 고치느라 매일 수천 인시가 쓰임
    깨지는 API의 엄청난 비용을 이해하는 문화가 거의 없음. Go를 10년 해온 뒤라 특히 답답함. Go는 하위 호환성 약속이 있고, 이게 Go 라이브러리 개발자들의 호환성과 깨지는 변경에 대한 태도에도 영향을 주는 듯함. 10년 전에 작성한 코드가 최신 Go에서 그대로 컴파일되고 동작하는 건 정말 좋은 경험임
    이 JS/웹 지옥에서 벗어나려고 Flutter로 옮긴 적도 있는데 꽤 잘 맞았고, 웹 스택의 우발적 복잡성을 많이 잊을 수 있었음. 하지만 “패키지를 깨도 괜찮다”는 문화가 Dart 생태계에도 스며들고 있어 매우 짜증남
  • 주로 프론트엔드를 하지만 “Python 광산”에서도 충분히 시간을 보낸 입장에서 똑같이 느낀다. Python은 deprecated되고 업그레이드 불가능한 라이브러리와 의존성이 뒤섞인 끔찍한 혼합물임
    솔직히 프론트엔드보다 훨씬 심하다고 봄. 프론트엔드는 그래도 TypeScript와 언어 특성 덕분에 피해 범위가 비교적 sane한 수준으로 제한됨. Python에서는 정말 말 그대로 무엇이든 할 수 있고, 그래서 라이브러리 작성자들도 말 그대로 무엇이든 함. 모듈 import 방식을 바꾸고 싶으면 바꾸고, 메타클래스로 클래스 동작에 대한 모든 가정을 깨고 싶으면 가능함. 정적 타입이 도와줄 거라 생각해도 Partial 같은 사소한 것도 안 되고, 두 객체가 같은 타입인지 정적으로 단언하는 것도 안 됨
    라이브러리가 바뀐다고 투덜대는 걸 보면 웃김. Python 2에서 3으로의 전환은 너무 끔찍해서, 이전 직장에는 Python 3으로 업그레이드할 계획이 전혀 없는 1억 줄 규모 Python 모놀리스가 있었음. SqlAlchemy 1에서 2로 가는 건 8단계 마이그레이션이고 사실상 전체 재작성이며, 하나라도 깨지면 사이트가 내려감. 그런데 React가 선택적으로 hooks를 추가했다고 불평함
    이상한 건 인터넷에는 “프론트엔드 러닝머신” 글이 넘치지만, 그 반대편에 대해 투덜대는 글은 잘 보이지 않는다는 점임

• “엔지니어라면 핵심 웹 기술을 깊이 이해할수록 시간이 지나도 훨씬 높은 시장 가치를 유지할 수 있다”는 말에 대해, 프론트엔드를 거의 20년 해오며 여러 큰 패러다임 변화를 겪었으니 의견을 말할 자격은 있다고 봄
  핵심 웹 기술을 모두 알면 더 균형 잡힌 엔지니어가 되는 건 확실히 맞음. 하지만 그것이 채용 시장에서 더 매력적으로 보이게 해주는지는 회의적임. 이 지식이 중요하지 않아서가 아니라, 채용 결정권자들은 대체로 패턴 매칭을 하기 때문임
  “시장 가치”를 최대화하고 싶다면 여전히 React를 매우 잘해야 함. 이건 기본 입장권에 가깝고, 나머지는 훌륭하지만 그 기반이 없으면 선택지가 줄어듦. 아마 글쓴이가 그 뜻으로 말했는데 내가 잘못 읽은 걸 수도 있음

  • 기본 웹 기술을 깊이 아는 건 매우 중요하고 높게 평가됨. 특히 큰 회사일수록 숙련된 엔지니어에게 프레임워크 자체는 사소한 세부사항이고, 어떤 프레임워크든 일주일 안에 익혀 생산성을 낼 수 있다는 걸 알기 때문에 플랫폼 자체에 대한 깊은 지식으로 높은 시장 가치를 가질 수 있다고 봄
    다만 컨설팅이나 계약직 같은 역할에선 원 댓글에 동의함. 큰 컨설팅 회사에서 채용하거나 면접 대상 여부를 결정하는 사람들과 함께 일해보면, 자신들이 선호하는 스택이나 현재 고객사가 쓰는 스택을 이미 모르는 사람은 거의 자동으로 탈락시킴. 기술 아키텍트들도 그러니 비기술 채용 담당자만의 문제가 아님. 숙련도와 무관하게 기술 자체에 적응하는 시간을 원하지 않음
    이런 역할에서는 계속 최신 상태를 유지하는 게 매우 중요함. 그렇지 않으면 채용 매니저가 엔지니어가 실력을 평가하기도 전에 buzzword가 없다는 이유로 이력서를 버림
  • 30년 동안 시장에 있었고 프론트엔드로 지구상에서 손꼽히는 좋은 직업들도 해봤지만, 첫 React 프로젝트는 작년에야 했음
    특이한 경우일 수도 있지만 React를 모른다는 게 문제가 된 적은 없었음. “기본 입장권”이라는 표현은 너무 강함
  • 프론트엔드 친구들이 같은 일을 반복하는 프레임워크를 계속 다시 배우기보다 API 설계, Unix 도구, 네트워킹, 테스트와 그 밖의 수많은 것들을 배우는 편이 더 낫다고 봄
  • 어느 정도는 맞지만, 풀스택 엔지니어는 “시장 가치” 최상단과는 거리가 있음
    프론트엔드는 보상에 꽤 단단한 상한이 있음. 일정 수준 이상으로 올라가면 다시는 UI를 만들 필요가 없어짐
  • 지난 10년 넘게 프론트엔드를 하고 있고 전체 개발 경력은 20년이 넘는데, 원 댓글에 동의함
    대부분의 회사, 심지어 큰 회사도 핵심 기초를 크게 신경 쓰거나 검증하거나 그 기준으로 채용하지 않음. “React를 잘함”이나 “Next.js 경험 많음” 같은 기준으로 채용함
    기초는 처음부터 무언가를 만들 때 훌륭하지만, 실제 회사는 그런 일을 거의 하지 않음. 대개 생태계가 크고 문서가 좋은 기성품을 가져다 씀. 그런 것들을 잘하면 훨씬 쉽게 채용되고, 기초는 그 과정에서 배울 수 있음

• “어떤 프레임워크를 고르든 5년 뒤엔 obsolete가 된다”는 말은 좀 낡은 논리처럼 보임
  주로 프론트엔드 개발자는 아니지만 프론트엔드를 할 때 피하지는 않고, 지난 10년 정도 React를 써왔음. Svelte 쪽으로 분위기가 일부 옮겨가고 있지만 Svelte가 React를 추월할 때쯤이면 아마 Svelte도 그만큼 오래 프로덕션에서 쓰인 뒤일 것임. Angular도 언젠가 힘이 빠질 수 있지만 Angular1과 Angular2+ 시절을 함께 보면 React보다 더 오래됐음
  프론트엔드 개발이 빠르게 움직이는 건 맞지만 그렇게까지 나쁘진 않음. 지루한 선택을 하면 지루한 결과가 나옴

  • Angular를 예로 들면 맞는 말이지만 놓치는 부분도 있음
    Angular1과 2는 이름만 빼면 거의 비교할 수 없을 정도로 달랐고, 많은 개발자가 여기서 데였음. Angular 자체도 꽤 크게 바뀌고 있음. v1에서 Angular2로 넘어갈 때만큼 심하진 않지만, 그래도 상당한 재적응이 필요할 정도임. 모든 것이 standalone component, 새 템플릿 문법, signals 등으로 이동하고 있음
    React도 비슷함. 함수형 컴포넌트와 hooks의 등장으로 큰 패러다임 전환이 있었음. 호환은 됐지만 서로 매우 달랐음
    더 일반적인 패러다임에서도 마찬가지임. 처음엔 전부 서버 사이드 렌더링이었다가, 단일 페이지 앱으로 전력 질주했고, 다시 서버 사이드 렌더링으로 돌아왔지만 이번엔 hydration이 있는 부분적 서버 사이드 렌더링이 됨
  • 오늘날의 React는 10년 전 React와 매우 다름
    다른 프레임워크라고 해도 될 만큼 다르니, nuance는 있지만 그 논리가 완전히 죽은 건 아님
  • React를 10년 정도 해왔고 며칠 전부터 Svelte 5를 만져보기 시작했음
    작업하기 정말 단순함. 간단한 주식 배분 앱을 만들었는데 가장 놀란 건 번들 크기였음. gzip 기준 9KB였고, 아는 어떤 프레임워크보다 작음. 어느 정도 “반-JS”에 가까운 htmx보다도 작음
  • “obsolete”는 너무 강한 단어임
    오래된 프레임워크도 아주 오래 실행할 수 있음. 그 스택을 아는 사람이 존재하고 필요할 때 고용해 작업할 수 있다면 그 스택은 obsolete가 아님. “오래됐다”거나 “레거시”는 맞을 수 있음. 하지만 그걸 다룰 사람이 아무도 남지 않는 날이 오기 전까지는 obsolete가 아님
  • React만이 아니라 동료들이 설치한 온갖 임의 패키지들도 문제임

• 이걸 프론트엔드 문제라고 부르는 게 흥미로움. 프론트엔드 문제가 아니라 거대한 생태계에 새 참여자가 계속 들어오는 문제임
  15년 전 Java가 혁신의 최전선에 있었을 때도 똑같이 봤음. 몇 년 사이에 수십 개의 프레임워크와 여러 빌드 시스템이 나왔음. React 17에서 18로의 변화는 Perl 5에서 6, Python 2에서 3으로 가는 것보다 훨씬 작은 변화임
  백엔드에서는 “새 프레임워크를 쓰자” 대신 “새 언어를 쓰자”가 나옴. 최신 유행은 뭔가를 Rust로 다시 쓰는 것이고, 그 전엔 Go, Haskell, Scala, F#도 있었음
  React에서 Svelte 같은 것으로 프론트엔드 코드를 옮기는 게 성가시다고 생각한다면, VB 6 앱을 다시 써보면 됨. 데이터가 코드 안에 있는 RPC 같은 건 말할 것도 없음
  엔지니어링 관행의 불안정성이 문제가 아니라는 뜻은 아님. 큰 문제임. 다만 프론트엔드만의 문제는 아님

  • React는 11년 됐는데, 온라인에는 React 개발자들이 권장하는 방식과 다른 방식으로 하라고 알려주는 자료가 놀라울 만큼 많음. 그것도 최근 몇 년 사이 자료만 봐도 그럼
    webpack도 13년 됐지만, 최근 몇 년 안에서도 설정 방식이 극적으로 바뀌었음
    Apache 설정이 이 시스템들만큼 자주 바뀌었다면 아무도 Apache를 쓰지 않았을 것임
  • 일화적으로 동의함. 내가 일했던 곳들은 백엔드 시니어가 많았고, 그들은 프론트엔드가 쉽고 건드릴 가치가 없다고 생각하면서 백엔드 쪽 “다음 반짝이는 것”은 스스로 결정했음
    이전 직장에서는 2년 동안 데이터베이스 마이그레이션이 두 번 있었고, 총 1년의 엔지니어링 시간을 썼음. 일부 비핵심 테이블이 아니라 모든 테이블이 대상이었음. 뭔가 깨지거나 윗선에서 왜 이렇게 느리냐고 물으면, 경험이 부족하다는 이유로 프론트엔드를 배우는 엔지니어들을 탓했음
  • Java 개발자 입장에서는 이건 프론트엔드 문제임
    25년 넘게 Java 개발자로 일했고, 처음 10년 조금 넘는 기간은 풀스택 개발을 했으며 그게 당시 회사들의 일반적인 형태였음. 이제는 프론트엔드 별도 팀이 있는 게 보통이고, 웹·iOS·Android로 세 팀이 있는 경우도 많음. 내게는 AngularJS에서 Angular로 넘어가던 시기쯤 그 변화가 있었음
    Java도 처음 10년 정도는 빠르게 바뀌었고, 특히 처음 3년은 매우 빨랐음. 하지만 그 시기는 끝났음. Java 5는 큰 변화였고 Java 8에도 주요 기능이 있었지만 Java 8은 2014년임. 우리 팀은 최근에야 Java 11로 옮겼고, 지금은 Java 24가 나왔음. 나는 Java 11 기능을 써본 적도 없고 무엇인지도 모름. 10년 동안 새 언어 기능을 하나도 배우지 않았음
    빌드 도구는 지난 15년간 같고, IDE는 지난 20년간 같음. 주로 쓰는 프레임워크도 10년간 같음. 마지막 직장으로 옮겼을 때 코드베이스 구조가 이전 팀과 정확히 같았음
    Java로 웹 서비스를 만드는 건 해결된 문제임. 좋은 의미로 완전히 지루하고, COBOL 같음
    프론트엔드는 90년대 후반과 2000년대 초에도 빠르게 변했지만, 그 뒤로도 계속 빠르게 변해왔음. 몇 년 전에 만든 개인 UI 프로젝트는 완전히 낡아버렸음
    EJB 이후 시대에 내가 작업했던 Java 프로젝트라면, 오늘날 Java 개발자를 찾아 투입해도 바로 생산성을 낼 수 있을 것임. 그 개발자가 프로젝트가 만들어진 뒤에 태어났더라도 가능함. 배워야 할 낡은 라이브러리가 몇 개 있을 뿐임
  • Scala는 그 자체만으로도 매년 혁명을 겪곤 했음

• 러닝머신에서 내려오는 방법은 프론트엔드 프레임워크를 아예 쓰지 않는 것임. 임의의 다른 프레임워크를 골라 나중에 다시 쓰는 게 아님
  서버 사이드 렌더링, 필요한 때만 JavaScript, 회사 안에서 백엔드와 프론트엔드 인력을 나누지 않는 방식이 필요함

  • 백엔드와 프론트엔드 인력을 나누지 않는 것이 어디서든 얻을 수 있는 가장 큰 이득임
    한 엔지니어가 SSR 웹 뷰에 필요한 정확한 컬럼만 가져오도록 SQL을 작성하고, 그 웹 뷰도 책임질 수 있으면 API나 ORM 같은 걸 단 1초도 고민할 필요가 없음. SQL과 현대적인 순수 HTML/CSS/JS만 알면 됨. 하는 일 대부분이 비즈니스의 뷰(SQL)를 DOM(HTML)으로 변환하는 것이 되면서 서버 측 프로그래밍 생태계는 뒤로 물러남
    최종 형태는 RDBMS 안에서 웹 콘텐츠를 SSR하는 것이라고 봄. Oracle APEX 같은 방식임. 하지만 대부분의 엔지니어는 아직 그 대화를 할 준비가 안 되어 있음. 나도 실제 현장에서 처음 봤을 땐 그랬음. 우리는 고통받는 방식에 너무 애착이 있음
  • 백엔드/프론트엔드 분리는 정말 나쁜 실험이었음
    프론트엔드가 과도하게 복잡해지는 문제를 악화시켰음. 프론트엔드 팀에 사람이 있으니 그들이 계속 일감을 만들고 복잡성을 더함. 웹 개발만 알고 다른 건 모르는 사람이 너무 많아진 것도 문제임
  • 요즘 CSS가 할 수 있는 일이 놀라움
    사이드 프로젝트에서 초기 제약 중 하나를 JavaScript를 끄더라도 전체 사이트가 우아하게 기능 저하되도록 하는 것으로 잡았음. 그러다 보니 보통 JavaScript로 할 기능을 추가하려 할 때마다 “이걸 JavaScript 없이 할 수 있나?”라고 묻게 됐는데, 지금까지는 놀랍게도 항상 답이 yes였음
    기본 HTML 컨트롤에 대한 CSS 선택자만으로도 요즘은 정말 많은 걸 할 수 있음. 그 코드베이스에는 아직 JS 한 줄도 없음
  • 100% 동의하지만 “필요할 때만 JavaScript”는 논쟁적인 표현임. 특히 엔지니어링 중심 문화가 없을 때 더 그럼
    제품/디자인 팀은 사용성, 성능, 접근성, 좋은 엔지니어링을 전혀 고려하지 않고 가능한 한 많은 JavaScript 장식을 넣으라고 밀어붙일 수 있음
  • 백엔드와 프론트엔드를 나누지 않는 건 어렵음
    나는 프론트엔드를 잘하지 못하고, 디자이너도 없음. 백엔드는 훨씬 잘하지만 팀의 다른 사람들이 프론트엔드 디자인에 나보다 재능이 있음

• 첫 웹사이트를 만들 때 “Svelte가 React보다 낫다”, “solid-js가 다음 대세가 될 것이다” 같은 글을 읽고 그게 웹 개발의 중요한 부분이라고 생각했음
  초보자는 MDN을 읽고 나머지는 무시하는 게 좋음

  • 초보자가 API 레퍼런스만 보고 바로 순수 JavaScript를 작성하기가 얼마나 접근하기 어려운지 사람들이 잊는 것 같음
    사람들에게는 튜토리얼과 walkthrough가 필요하고, 이 모든 것이 어떻게 동작하는지에 대한 내부 이해를 쌓아야 함
    프레임워크는 그런 부분을 추상화하는 데 도움을 줌
  • React는 충분히 오래됐고 깊게 자리 잡아서 꽤 잘 알아둘 만한 투자 수익이 있음
    하지만 최근의 Next.js와 SSR 집착은 아닐 수도 있음. 개인적으로는 이게 React 쪽의 몰락 요인이 될 수도 있다고 봄

• 최근 몇 년간 순수 JS와 CSS가 발전한 것을 생각하면, 그리고 display: none 애니메이션 같은 흥미로운 기능이 거의 채택 단계에 온 것을 보면, 서버에서 템플릿 HTML을 만들고 필요한 곳에만 JS를 쓰는 방식이 그 어느 때보다 타당해 보임
  React로 주로 먹고사는 사람으로서 하는 말임
  글쓴이처럼 나도 이런저런 방식으로 20년 동안 프론트엔드를 해왔음. 생태계, churn, 프론트엔드와 백엔드 사이 상태를 동기화하는 곡예는 정말 미친 수준임
  최근 Go templates와 HTMX로 개념 증명 프로젝트를 시작했고, React처럼 “컴포넌트”로 UI를 만드는 느낌을 근사하려고 하고 있음. 아직 거친 부분이 많지만 가능성은 있음. 솔직히 HTMX가 필요한지도 아직 확실치 않음. 이벤트 리스너를 직접 관리하기 시작했는데, 그쪽이 더 마음에 드는 것 같음
  흥미롭게도 사용자 역할과 권한에 기반한 복잡한 UI 상태 관리는 서버에서 훨씬 쉬움. 사용자가 볼 수 있는 HTML만 보내면 끝임
  다만 React, Vue 등은 엄청난 추진력이 있음. 사고방식의 집단적 전환이 어떻게 시작될 수 있을지 모르겠음. 특히 UI를 만드는 방식으로 프론트엔드 프레임워크밖에 모르는 개발자들이 많다는 점을 고려하면 더 그렇음

• “어떤 프레임워크를 고르든 5년 뒤엔 obsolete가 된다”는 말은 잘 모르겠음
  10년 넘게 프로로 React를 써왔음

  • package.json에 의존성이 몇 개나 선언되어 있음? 팀은 어떤 node/npm 버전을 씀?
    충분히 최근 버전을 쓰고 인기 라이브러리를 사용한다면, npm install 중 하위 의존성에 대한 deprecated 알림이 쌓이는 걸 봤을 것임
  • 10년 넘게 프로로 React를 써왔지만 5년 전 React는 obsolete임. 말 그대로 현재 도구로는 빌드가 안 됨
    공정하게 말하면 React 코드 자체는 하위 호환성을 꽤 잘 유지해왔다고 봄. React의 잘못은 아님. 하지만 5년 전에 쓰던 빌드 시스템들은 모두 바뀌었고 하위 호환성을 깨뜨렸음. 컴포넌트 생명주기 메서드도 잊고 있었음
    React처럼 잘 관리되는 프로젝트도 그 생태계의 지저분함에서는 벗어날 수 없음
    항상 선택할 수 있는 건 아니지만, 요즘은 보통 순수 JS를 빌드 시스템 없이 import하고, 가능한 한 Python/Django 백엔드에서 처리하며 JavaScript 생태계에서 완전히 빠져나오는 방식을 택함. 후회한 적은 없음
  • 컴포넌트 생명주기 메서드에서 hooks와 HOC로 넘어간 거 기억 안 남?
  • 2025년에 Create React App 지원은 어떰?
    아직 앱을 React 15에 두고 있음?
  • 현재 회사는 아직 React 16이고 deprecated 때문에 겨우 18로 가려고 하는 중임
    React 16에서 동작하는 모든 WYSIWYG 편집기는 더 이상 지원되지 않음. 보안 이슈가 발견되면 “운에 맡기는” 상황임. 아니면 쓰지 말아야 함
    React 16은 아직 지원되지만 확실히 obsolete임

• 반론은 프레임워크를 채택하지 않으면 결국 팀 밖 사람들이 이해하지 못하고, 문서화도 대체로 부실하며, 기존 프레임워크에 이미 있는 기능을 추가하느라 계속 작업해야 하는 자체 프레임워크를 만들게 된다는 것임
  프론트엔드에는 공통으로 필요한 기능과 해결해야 할 공통 문제가 있음. 아무것도 없이 시작하기보다 적어도 뭔가를 깔고 시작하는 게 낫지 않나?

  • 이런 문제를 실제로 봤음
    내부 프레임워크를 본 적이 없으니 바로 생산성을 낼 수 있는 사람을 찾는 게 불가능함. 문서가 아주 잘 되어 있어도 배우고 체화하는 데 시간이 걸림. 장기 채용이라면 최악은 아니지만, 임시로 개발자가 더 필요해지면 답이 없음
  • 이게 맞는지는 잘 모르겠음
    다른 곳에서도 썼지만 거의 모두가 웹앱을 원하거나 자신들이 웹앱을 갖고 있다고 생각하지만, 실제로는 대개 동적 웹사이트일 뿐임. 동적 웹사이트를 만들기 위해 프레임워크를 쌓아 올릴 필요는 없음

• 이건 프론트엔드 문제가 아니라 JS 생태계 문제임. 백엔드에서도 일어남
  JS 환경은 의존성이 수십, 수백 개의 다른 의존성을 가진 완전한 난장판임. 예를 들어 Fastify 기반 Node 프레임워크인 Platformatic의 의존성 그래프는 다음과 같음
  https://npmgraph.js.org/?q=platformatic#zoom=h
  이 의존성들은 어느 순간이든 버려질 수 있음. Axios나 Express처럼 거대한 의존성도 한때 방치된 것처럼 보였음
  그리고 각 의존성은 유지관리자가 옳다고 생각하는 방식에 지배됨. 며칠 전엔 프로덕션에서 쓰는 의존성 하나가, 주당 약 2,500만 다운로드를 기록하고 React가 약 2,600만인 수준이며 GitHub 저장소 1,000만 개에서 쓰이는데도, 약 3년 전 Safari 버전 지원을 끊어도 된다고 결정했음. Safari가 미국 모바일 시장 점유율 50% 이상이라는 점을 생각하면 정말 미친 일임

  • 의존성 368개, 유지관리자가 한 명뿐인 의존성 179개, 사용된 라이선스 8종이라니 사양함