Hacker News 의견

• Github 웹사이트는 어디서나 느린 편임. 성능이나 UX/UI, 모든 면에서 좋은 소프트웨어라고 할 수 없으며, 여러 사람들의 KPI와 기획이 들어간 결과물이란 생각이 듦. 개발자들을 위한 소셜 네트워크라는 것 자체가 가장 “혁신적인” 부분이고, 일상적인 개발 업무에는 너무 평이해서 Gitlab이 훨씬 낫다고 느껴질 정도임. 이 문제는 Rails 때문이 아니고, 기술로 포장해서 본질을 피해가는 것은 옳지 않다고 봄

  • Github의 문제는 Rails가 아니라 React로 옮겨갔기 때문임. 예전 SSR 기반 Github는 정말 빠르고 대용량 PR도 문제없이 검토할 수 있었음
  • 몇 년 동안 Github를 쓰지 않다가 올해 다시 써보니 얼마나 느려졌는지에 정말 놀랐음. 인터랙션할 때마다 느림 때문에 모든 사용 방식을 다 바꿔야 했음. 무언가 잘못된 기분이 계속 들고, 몇 초 동안 아무 반응이 없으면 왠지 서버가 멈춘 듯한 불안함이 생김
  • 10년간 Phabricator를 쓰다가 Github로 오니 품질 차이가 커서 당황스럽고, 이게 표준이라는 게 믿기지 않음. Phabricator가 이제는 메인테넌스만 되는 것이 아쉬움 Phabricator 위키
  • Github가 예전에는 정말 쾌적했었는데, SPA로 바뀐 뒤부터 답답해짐
  • 예전에 CTO가 레거시 앱 성능 저하 원인을 무조건 Rails 탓으로 돌리며 Java로 갈아엎자고 했던 경험이 있음. 사실은 무능한 기획자, 경영진, 경험 부족한 개발자들의 누적된 결과가 근본 원인이었음. 10년 넘게 잘못 관리된 프로젝트라면 어떤 스택이든 결과는 같음

• WebKit 팀이 지난 2일간 Github 성능 이슈 개선을 적용함 관련 링크. 팀 내에서 대규모 PR(1000개 파일 이상)을 만들기도 했는데, 동료들은 PR이 로딩될 때까지 기다리다 “열리면 승인해줄게”라는 말을 함

  • 모든 사람이 JS와 React가 문제라고 하지만, 실제로 이번 패치는 CSS 성능과 관련된 것임
  • Chrome과 파생 브라우저가 렌더링 엔진을 사실상 장악한 상황이므로, Firefox의 성장세가 둔한 요즘 macOS/iOS에서 Safari를 계속 경쟁력 있게 만들어주는 Apple의 변화가 반가움
  • 1000개 이상 파일이 포함된 PR이 구체적으로 어떤 작업인지 궁금함
  • 사실 Safari WebKit에 Github가 과도하게 부하를 주면서 드러난 버그였음. 개발자나 사용자인 우리는 원인을 Github 탓으로만 돌리기 쉬움
  • 웹킷 패치가 실제 사용자가 받으려면 얼마나 걸리는지 궁금함. 사파리는 OS 업데이트를 기다려야 하는지, 아니면 크롬/파이어폭스처럼 업데이트가 빠른 편인지 알고 싶음

• Microsoft가 Github를 인수하자마자 Github는 거의 바로 JavaScript 렌더링 방식(SPA)으로 전환함. 이전에는 2011년형 Mac Mini에서 JavaScript를 꺼 놓아도 Github 탐색이 가능했으나, 현재는 JS를 켜도 구형 브라우저 호환성 때문에 Github 사용이 불가해짐. 어느 쪽이 더 문제인지 말하기 어렵지만, 양쪽 모두에게 책임이 있다고 생각함. 최신 기기로 바꿀 수도 있겠지만, 의도적으로 구형 기기 지원을 포기하고 미래의 기능성보다 계획적 단종(planned obsolescence)을 강요하는 분위기에서 웹 표준에 대한 믿음마저 깨지는 느낌임

  • 만약 오늘 처음 알게 된다면, OpenCore Legacy Patcher를 사용해 2007년형 Mac까지도 macOS를 최신 버전으로 올릴 수 있음 OpenCore Legacy Patcher 링크
  • 크롬이나 파이어폭스를 설치해서 쓰는 건 어떤지 궁금함
  • Turing completeness가 왜 거짓말처럼 느껴지는지 의문임. 계획적 단종도 있지만, 현대 소프트웨어 환경은 추상화가 지나치게 많아짐. 만약 모든 소프트웨어를 C언어로 짜야 했다면 지금의 세상은 매우 달랐을 것임. 너무 높은 추상화에 빠진 것 같지만, 이미 여기까지 왔으니 돌이키긴 어려움. Turing completeness 자체는 이와 거의 무관하며, 오히려 그 결과로 더 큰 자원 소모를 요구하게 됨
  • Turing completeness는 성능과는 무관하다는 점을 강조함. 이론적으로는 현재 기기에서 최신 기기를 에뮬레이트할 수도 있음
  • 2011년 Mac Mini의 OS 지원이 중단된 것에 대해 불만을 갖는 사람도 있지만, 8년 이상 지난 브라우저로 인터넷을 쓰는 건 보안적으로도 집을 문 다 열어놓는 것과 비슷하다고 생각함

• React에 대한 비판이 많지만, 이번 이슈는 CSS transform 문제임. 관련 링크 내용을 실제로 읽어보길 권함

• Forgejo, Codeberg, SourceHut로 마이그레이션하는 걸 추천함. Github와 Gitlab에 비하면 번개처럼 빠름 Forgejo / Codeberg / SourceHut

  • Forgejo 서버를 망가진 회선(초당 킬로비트 수준)으로 몇 주간 돌렸는데도 꽤 잘 버텼음. 푸시/풀은 어떻게든 동작했지만, 액션은 100MB 이상 전송이 필요해서 힘들었음

• 대규모 조직에서 어떻게 이런 문제가 반복되는지 궁금함. 주요 브라우저 테스트에서 성능 문제를 분명 발견했을 듯한데, 누군가 강행 승인을 내린 것인지 이해가 안 됨

  • 현재 IT 업계는 세 그룹이 있음: 1) PM이 무리하게 출시 압박을 주고, 속도만 중시함. 2) 개발자는 이런 요청에 반발하며 지속적으로 정치적 자본을 소모하고 번아웃됨. 3) 모든 것에 무관심하게 주어진 일만 기계적으로 하는 개발자 집단. 결국 문화 자체에 문제가 있고, C레벨에서 전면적으로 개혁하지 않으면 바뀌지 않음. 대부분 임원은 이걸 바꿀 의지가 없음
  • 큰 조직에서 기술 스택을 결정할 때 가장 중요한 기준은 “채용과 해고가 얼마나 쉬운가”임. React 개발자는 많지만 Rails는 찾기 어려움. 개발자의 의견은 무시되고, 조직의 필요가 우선되면서 느린 서비스와 나쁜 품질로 이어짐. 개발자들도 문제를 알지만, 생존이 우선임
  • 예전에는 “IBM을 사면 해고당하지 않는다”는 말이 있었다면, 지금은 “React를 쓰지 않으면 해고 당한다”는 분위기임. 모두가 React를 쓰다 보니, Github조차 느려지는 현상이 계속됨. 나쁜 개발자는 남들이 쓰는 걸 따라가고, 좋은 개발자는 KISS 원칙에 따라 가장 단순한 도구를 고르는 것임
  • 대형 조직에서 “소유권”이 모호해지고 회전율, 단기 목표 위주로 인해 이런 문제가 항상 반복됨. 기능 추가 압박과 기술부채가 누적되고, 책임감은 사라짐. 문제 제기하면 오히려 갈등이 생기고 성과 개선 플랜으로 내몰림

• React 개발자로서 이 스레드를 보며 세상의 혐오를 실감함. 비현실적인 일정, 백엔드 로직까지 프론트에 얹는 SPA의 함정이 많음. React 자체가 잘못된 선택인지, 진짜 잘 만든 React 앱이 있는지 궁금함

  • 오랫동안 React/SPA의 열렬한 팬이었지만, 점점 C++ MFC 데스크탑 앱 만들던 시절보다 오히려 개발이 더 어려워졌다는 걸 깨달음. 선언적 마크업이 인지 부하를 줄인다고 하더니, 오히려 선언적 UI와 이벤트/상태 관리의 복합성이 커져서 절차적으로 개발하던 때보다 복잡해짐. 예전 C++ 코드는 오히려 React hook보다 이해하기 쉬웠음
  • SPA에 대한 비판이 많지만, 정말 잘 만든 React/Angular 앱도 있음. 예: Clockify. 문제 있는 앱도 SSR로 렌더한다고 해서 UX가 갑자기 좋아질 것 같지는 않음. 실제 원인은 품질보다 빠른 기능 릴리즈만 신경 쓰는 조직 분위기임
  • 이런 기술은 성능이 안 좋을 때만 부각됨. 모두가 매일 웹 기술을 쓰다 보니 욕하기 쉬움. 특히 초보 개발자가 많이 쓰는 기술이어서 더욱 비난받음. 경계 허물기가 심한 예시임
  • React 자체의 문제가 아니라, 사용하는 개발자가 잘못 쓰는 게 문제임. 수많은 최적화가 있어도 잘못 엮어 쓰면 클릭 반응이 1.3초나 걸리는 현상이 생김
  • React 자체는 나쁘지 않고, SPA 구성이 구조적으로 문제가 될 때가 많음. React는 단순히 SPA를 쓰기 쉽게 만든 도구임

• 컴퓨팅 전반적으로 모든 게 느려진 느낌임. 최신 Mac Studio M4 Max, 64GB RAM을 써도 2011년 MacBook Pro 때보다 모든 웹사이트가 느려짐

  • 15년 전 인터넷을 썼을 때 확실히 느리기는 했지만, 그땐 웹에서 복잡한 스프레드시트나 디자인 툴은 사용하지 않았음. M 시리즈 Mac은 지금까지 써 본 중 가장 빠른 컴퓨터임(Linux 데스크탑 빼고)
  • 웹 개발자는 사용자 하위 10% 정도 사양의 기기를 써보고 개발해야 맞다고 생각함. 아니면, 성능 자체를 WCAG(웹 접근성) 기준으로 삼는 것도 방법임

• HN에서 Github가 React로 UI를 마이그레이션하면서 느려졌다는 얘기를 많이 들었지만, 실제로 그런지 궁금함. 소규모 프로젝트에서는 영향이 없어서 확실한 근거를 찾고 싶음

  • 최근 읽은 블로그 글에서 원인을 잘 설명함. 요약하자면, PR 뷰에서 DOM 노드가 10만 개 이상 렌더링되고, 그중 상당수가 보이지 않는 SVG 노드임. SPA 라우팅 때문에 내비게이션도 훨씬 느려진다는 분석임 관련 블로그 / HN 토론
  • 최근 PR diff 페이지가 새롭게 리디자인되면서 DOM이 더 비대해진 것 같음

• Safari뿐만 아니라 Firefox에서도 Github가 엄청 느린데, 로딩 스피너 표시가 곳곳에 보이고 페이지 전환도 전보다 오래 걸림. 기존의 완벽히 잘 동작하던 SSR을 도대체 무슨 지표로 SPA로 바꿨는지 이해가 안 감

  • 최근엔 Chrome에서도 비슷한 문제가 있음. 세 가지 브라우저 모두, PR이 크지 않아도 제대로 작동이 안 되는 상황임