LinkedIn 탭 두 개가 2.4GB의 RAM을 먹는다. 스무 개가 아니라, 두 개다. dev.to에 올라온 이 글이 Hacker News에서 600점을 넘기며 화제가 됐을 때, 개발자들이 공유한 반응은 분노가 아니었다. 놀랍게도—무감각이었다. 한 개발자는 단일 LinkedIn 탭이 3.2GB에 달하는 걸 목격했고, 또 다른 사람은 탭 메모리가 42GB까지 치솟는 걸 추적한 끝에 백그라운드에서 돌아가는 서드파티 봇 방지 서비스를 범인으로 지목했다. 그런데 아무도 놀라지 않았다. 그게 진짜 문제다.
숫자를 한번 냉정하게 들여다보자. HTTP Archive의 2026년 2월 데이터에 따르면, 중간값 웹 페이지가 실어 나르는 JavaScript는 780KB다. 불과 몇 년 전 540KB에서 44% 증가한 수치다. 페이지 전체 무게는 2.2MB, 첫 렌더 전에 발생하는 JavaScript 요청만 24개다. 어느 대형 뉴스 사이트는 헤드라인 네 줄을 보여주는 데 49MB 데이터와 422개의 네트워크 요청을 동원했다. Windows 95 설치 파일과 맞먹는 용량이다. 이건 버그가 아니다. 누군가 의도적으로 선택을 쌓아온 결과다.
그 선택의 패턴이 흥미롭다. Standish Group 연구에 따르면 소프트웨어 기능의 64%는 거의 또는 전혀 사용되지 않는다. Pendo는 이 수치를 80%로 본다. 하지만 쓰이지 않는 그 기능들은 여전히 JavaScript를 로드하고, 이벤트 리스너를 등록하고, 메모리를 조금씩 갉아먹는다. SPA 아키텍처는 이 문제를 구조적으로 악화시켰다. 거대한 번들을 선불로 싣고, 복잡한 상태 트리를 구축하고, 정작 정리는 잘 하지 않는다—해제되지 않는 React 컴포넌트, 클리어되지 않는 타이머, 끝없이 자라는 캐시. 우리는 개발자 경험과 배포 속도를 최적화했고, 그 청구서는 사용자의 브라우저가 받았다.
이쯤에서 dev.to에 올라온 다른 글 하나를 꺼내보고 싶다. 한 개발자가 작은 비영리 단체 웹사이트를 4번 리빌드한 경험을 공유했다. 요구사항은 단순했다—랜딩 페이지 하나, 행사 참석 관리 기능 하나. 첫 버전은 React + PHP + MySQL로 잘 돌아갔다. 그런데 그는 스스로 목표를 바꿨다. "알림, 동시 이벤트, 계정 시스템, 댓글, 이미지, 무한 확장"—아무도 요청하지 않은 것들을. Next.js + Go + PostgreSQL으로 재구축했고, 월 $21의 인프라 비용이 소규모 단체에 부담이 됐다. 세 번째 버전은 Directus를 붙였는데 콜드 스타트에만 7~13초가 걸렸다. 네 번째에 와서야 그는 깨달았다. 처음부터 필요한 건 일주일짜리 Next.js + PostgreSQL이었다는 것을.
이 이야기가 LinkedIn의 2.4GB 메모리 문제와 다르게 보일 수 있지만, 뿌리는 같다. "확장성 = 복잡도"라는 착각. 그 개발자는 회고에서 이렇게 말했다. "복잡한 솔루션은 친구들과 술자리에서 자랑하기 좋은 것이지, 코드베이스에서 발견하고 싶은 게 아니다." 확장성은 절대적인 개념이 아니다. 무엇을 위한, 얼마나의 확장성인지를 물어야 한다. 그 질문을 생략하면 아무도 요청하지 않은 기능을 위한 메모리 누수가 쌓인다.
반면 같은 Next.js와 SVG로 교육용 수학 게임을 만든 사례는 다른 방향을 가리킨다. 7x.games의 개발자는 무거운 게임 엔진(WebGL, Phaser) 대신 DOM과 React 상태만으로 아이들을 위한 Number Bonds 퍼즐을 구현했다. 핵심 판단은 명확했다—이 문제에 이 도구가 필요한가? SVG로 연결선을 그리면 4K 스마트보드와 깨진 아이폰 화면 모두에서 픽셀 퍼펙트로 스케일된다. 모바일 키보드가 게임 UI를 밀어올리는 문제는 커스텀 넘패드로 해결했다. 기술 선택의 기준이 '멋있어 보이는가'가 아니라 '사용자 경험에 실제로 필요한가'였다.
웹 블로트는 단순히 느린 로딩의 문제가 아니다. HTTP Archive와 Web Sustainability Guidelines 커뮤니티에 따르면 인터넷은 연간 약 10억 톤의 CO2를 생산하는데, 이는 항공 산업 전체와 맞먹는다. 저사양 기기 사용자에게는 일부 '단순한' 웹 페이지가 배틀로얄 게임보다 더 나쁜 성능을 보인다는 Tom's Hardware 분석도 있다. 그리고 비즈니스 관점에서 Google의 Core Web Vitals는 블로트가 심한 사이트를 검색 순위에서 직접적으로 페널티를 준다. 성능 최적화는 기술적 취향의 문제가 아니라 전환율과 검색 가시성이 걸린 비즈니스 지표다.
우리가 다시 물어야 할 질문은 하나다. "이 기술이 사용자에게 실제로 어떤 가치를 주는가?" 780KB의 JavaScript를 기본값으로 받아들이기 전에, 그 안에 실제로 사용되는 코드가 얼마나 되는지 물어야 한다. 화려한 스택을 쌓기 전에, 그 복잡도의 비용을 누가 치르는지 물어야 한다. LinkedIn은 예외가 아니라 우리가 만들어온 정상의 표본이다. 그리고 그 정상을 다시 정의하는 건, 다음 프레임워크 업데이트가 아니라 지금 코드를 짜는 우리의 판단에 달려 있다.