▲

GitHub 웹사이트가 Safari에서 느리게 동작함

 (github.com/orgs)
1P by GN⁺ 22시간전 | ★ favorite | 댓글 1개
  • 최근 몇 달간 Safari 브라우저에서 GitHub 웹사이트의 속도가 점차 저하됨
  • 대형 PR이나 수천 줄의 코드 파일에서 화면 렌더링이 사실상 불가능해짐
  • 브라우저의 렌더링 프로세스 100% 사용과 스크롤 시 빈 화면 표시, 검색·코멘트 기능 심각한 지연 현상 발생
  • CSS 변경 및 transform 사용이 Safari의 성능 버그와 충돌하며 문제를 유발함, Chrome 등 타 브라우저는 상대적으로 양호함
  • WebKit에서 일부 성능 패치가 이뤄졌으나, Safari의 차기 릴리즈 전까지는 GitHub 프론트엔드 팀의 임시 대응 필요성 언급됨

배경 및 주요 문제

  • 최근 Safari 브라우저에서 GitHub 웹사이트 접근 시 전체적으로 성능 저하 현상이 두드러짐
  • 특히 Pull Request(PR)에서 수천 줄 이상의 변경사항을 확인하거나 대용량 코드 파일을 탐색할 때 렌더링 자체가 불가능해지는 수준에 도달함
  • Activity Monitor에서 렌더링 프로세스가 100% CPU를 차지하며, 페이지 렌더링 속도가 너무 느려 스크롤 시 화면이 빈 공간으로 나타남
  • 검색, 코멘트 등 인터랙티브 기능은 심각하게 지연되고, PR 리뷰 시 체크박스 클릭조차 몇 초 이상 소요되는 문제 발생
  • 하이엔드 Apple Silicon이 장착된 최신 MacBook Pro에서도 동일 현상 발생, Chrome이나 다른 브라우저 사용 시는 훨씬 나은 경험을 제공함

문제의 원인 및 분석

  • Safari 18.6 버전(및 베타/테크 프리뷰) 사용자들의 공통적인 불만 접수
  • 특정 사용자는 Safari뿐만 아니라 GitHub에서만 유독 심각한 성능 저하가 발생한다고 언급함
  • CSS 선택자와 transform: translateY의 대량 사용이 Safari의 GPU 레이어 처리 한계와 직접적으로 충돌하는 것으로 기술됨
    • GitHub 프론트엔드가 모든 텍스트 라인을 transform: translateY로 배치하면서, Safari는 수천 개의 GPU 레이어를 만들게 됨
    • Chrome은 이런 애니메이션이 없을 경우 레이어 생성을 최적화하여 상대적으로 덜 느린 성능을 보여줌
    • 임시 방안으로 transform 속성 제거 스크립트 적용 시 속도가 빨라지나, 위치 정밀도가 완벽하지 않음

사용자 경험 및 다양한 제보

  • 여러 사용자가 PR에서 리뷰어·라벨 추가, PR 설명 수정 등 모든 상호작용이 수 초 이상 지연되는 불편을 토로함
  • Safari에서 접속 시, 코드 브라우저 및 자동완성(검색바, 커맨드 팔레트 등) UI가 매우 느려짐
  • iOS Safari에서 뒤로 가기 네이티브 버튼 등 브라우저 기능도 제대로 작동하지 않는 사례 존재
  • 접근성(VoiceOver) 측면에서도 성능 저하가 심해, 시각장애 사용자는 거의 사용이 불가해진 상황 발생

해결 및 대응 논의

  • WebKit(사파리 엔진) 측에서 최근 해당 CSS/컴포지터 성능 문제의 일부 패치를 진행했으나, Safari의 다음 릴리즈 이전까지는 즉시 해결이 어려움
  • GitHub 엔지니어들에게는 차기 Safari 릴리즈 예정 전 버그 대응 제안 및 성능 이슈 사전 소통 필요성이 언급됨
  • 다양한 프론트엔드 UI 변화(예: PR 파일 변경 UI, 신규 기능 등)가 성능 저하와 직접적으로 연관된 것으로 보고됨
  • 일부 사용자는 Graphite.dev, GitLab, 커스텀 프로토콜 라우터(예: Finicky, Velja 등)로 우회 사용 혹은 대체 UI 활용

기타 논평 및 실사용자 팁

  • 일시적인 우회 방안으로, Safari에서 이슈/PR 생성 후 테이블 방식의 라벨 추가 기능 사용 조언
  • 지나치게 복잡한 CSS와 엔지니어링 구조 변화, 크롬 원메뉴화에 대한 우려와 다양한 브라우저 지원 필요성 강조된 목소리 존재
  • 일부 사용자는 성능 문제에 대해 비판적, 혹은 유머러스한 논평을 추가함(불필요한 감정적 논쟁은 토론상 주의 요구)
  • 성능 최적화가 필요한 프론트엔드 개발 방식 재고 및 멀티 브라우저 테스트의 중요성에 대한 내부적/외부적 의견 제기

결론

  • GitHub의 최근 UI 구조 변화와 CSS 활용 방식이 Safari의 고유 렌더링 특성과 충돌하며, 업계 표준 협업 플랫폼에서 치명적인 브라우저 불편을 유발함
  • WebKit 및 GitHub 모두의 적극적인 개선 의지가 필요하며, Safari·접근성 사용자 중심의 대응이 단기적으로 요구됨
  • 개발 업무에 지장을 줄 정도의 퍼포먼스 문제로, 커뮤니티 내 공감대와 분노가 크게 형성됨
▲
GN⁺ 22시간전  [-]
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이 크지 않아도 제대로 작동이 안 되는 상황임
답변달기