LinkedIn이 두 개의 탭에서 2.4GB RAM을 사용함

• LinkedIn 웹사이트가 두 개의 브라우저 탭만 열었을 때 2.4GB의 메모리를 소비
• 웹 애플리케이션의 비효율적인 리소스 사용 문제로 지적됨
• 브라우저 성능과 사용자 경험 저하 가능성 제기
• 대규모 프론트엔드 프레임워크나 광고·추적 스크립트의 영향이 원인으로 언급됨
• 주요 플랫폼의 웹 최적화 필요성이 다시 부각됨

---

LinkedIn 웹사이트의 과도한 메모리 사용

• LinkedIn을 두 개의 탭에서 실행했을 때 총 2.4GB RAM이 사용된 사례가 보고됨
• 단순한 페이지 탐색만으로도 높은 메모리 점유율이 발생해 웹 자원 관리의 비효율성이 드러남
• 이러한 현상은 브라우저 성능 저하와 사용자 경험 악화로 이어질 수 있음

원인과 시사점

• 대형 프론트엔드 프레임워크, 광고 및 추적 스크립트, 복잡한 클라이언트 렌더링 구조 등이 메모리 사용 증가의 요인으로 지목됨
• 주요 웹 플랫폼들이 리소스 최적화와 경량화에 더 집중해야 함을 보여주는 사례로 평가됨
• 사용자 입장에서는 탭 수 제한이나 브라우저 확장 기능 관리가 필요함

[GN⁺]

Hacker News 의견들

• “Voyager 1이 69KB 메모리와 8트랙 테이프 레코더로 돌아간다”는 사실과 지금의 상황을 비교하면 정말 극적인 대비처럼 느껴짐

  • 맞음, 요즘은 5G 통화가 끊기고, LinkedIn은 GB 단위 메모리를 쓰고, 냉장고조차 업데이트해야 불이 켜지는데, Voyager 1은 여전히 69KB로 우주를 날고 있음
  • 그 시절엔 69KB도 엄청난 용량이었을 것임. 1KB당 1,000달러쯤 했을지도 모르고, 우주 방사선 내성 메모리라면 그보다 10배쯤 비쌌을 수도 있음
  • 지금은 단순한 채팅 앱도 LinkedIn이 하는 거의 모든 걸 100MB 미만의 RAM으로 처리할 수 있음
  • 물론 Voyager 1은 훨씬 단순한 제품이라, 그만큼 적은 메모리를 쓰는 게 당연함

• 현실적으로 LinkedIn은 이상한 사람들로 가득하지만, 사실 대부분의 소셜미디어가 다 비슷하게 형편없음
  Facebook도, Twitter도, 결국 다 나쁜 방향으로 흘러감. Google+는 그나마 지역 기반으로 경험을 제한할 수 있는 도구가 있어서 가능성이 있었음

  • 요즘 사법기관도 비슷한 인식을 가진 듯함. Meta와 Google이 계속 규제에 시달리지만, 동시에 새로운 혁신 기업이 등장하지 못하도록 막고 있음. 규제의 역효과로 혁신이 더 어려워지는 악순환이 생김
  • LinkedIn은 특히 최악임. 영감 포르노 같은 글과 정치적 논쟁이 섞여서 정신이 멍해짐. 그런데 구직 시 LinkedIn URL을 요구하니 억지로 계정을 유지해야 함
  • 소셜미디어가 나쁜 이유는 기업의 불투명한 비즈니스 관행 때문이기도 하지만, 사용자들 스스로의 문제이기도 함. 혹시 Mastodon 써봤는지 궁금함
  • HN과 소셜미디어의 차이가 뭔지 궁금함. 개인화된 피드가 있으면 ‘소셜’인 건가, 아니면 그래프 기반 추천이 핵심인가 하는 생각이 듦
  • LinkedIn은 마치 기업 광고 뉴스피드 같음. 성인들이 자발적으로 구독하는 광고판 느낌임

• AWS도 비슷하게 RAM을 많이 먹음. 회사 VM에서 AWS 탭을 몇 개만 열어도 1.4GB쯤 차지함. 단순한 텍스트 페이지조차 기가바이트 단위 메모리를 쓰는 경우가 많아짐
  Reddit 새 UI나 DeepL 번역기처럼 겉보기엔 단순한데 CPU가 폭주하는 사이트도 많음. 혹시 LLM이 자동으로 코드를 수정하다가 성능 최적화를 놓친 건 아닐까 싶음

  • 문제는 많은 웹 프레임워크가 “그냥 돌아가는” 복잡한 앱을 쉽게 만들게 하지만, 성능은 고려하지 않는다는 점임. 예전 OpenAI 웹 UI도 매번 전체 대화 내역을 다시 렌더링해서 끔찍하게 느렸음
  • BestBuy 사이트를 보다가 아이폰이 뜨겁게 달아오르고 배터리가 급속히 닳았음. 마치 암호화폐 채굴이라도 하는 듯한 수준이었음
  • 요즘 웹사이트들은 사용자 행동을 추적하려고 자바스크립트로 자체 브라우저를 내장하는 수준임
  • 예전에 Slack 데스크톱 앱이 내 IDE보다 메모리를 더 써서, 컴파일할 때마다 Slack을 꺼야 했음
  • 요즘 웹 개발자들 사이에 CSS 필터 남용 경쟁이 있는 듯함. DeepL 페이지를 한 시간 켜놨더니 노트북이 뜨거워졌는데, 영상이 무한 SEEK 루프에 빠져 CPU를 태우고 있었음. Google이 Web Vitals에 리소스 사용량을 포함시켜야 한다고 생각함

• LinkedIn의 bot 차단 서비스(protechts.net) 가 내 노트북 RAM 42GB를 잡아먹은 적이 있음. Firefox가 미친 듯이 스왑을 돌리길래 확인했더니 culprit이 그거였음.
  스크린샷도 있음. iframe 이름이 “humanSecurityEnforcerIframe”이라니, 정말 아이러니함

• 이 문제를 영구적으로 해결하는 방법이 있음. 탭을 닫고 LinkedIn을 다시 열지 않으면 됨

  • 이메일 부담을 줄이는 기묘한 팁도 하나 있음

• 누가 아직도 LinkedIn을 쓰는지 모르겠음. 로그인하면 전부 AI 생성 글과 이미지뿐이고, 마치 드라마 Severance 한 장면 같음

  • 대부분의 사용자는 피드를 읽지도, 글을 올리지도 않음. 단지 구직과 인맥 관리용으로만 씀. 오히려 피드 활동이 많은 지원자는 근무 시간에 LinkedIn에 너무 몰두한 사람으로 보여서 리스크로 간주됨
  • 나도 마지막 직장을 LinkedIn에서 구했고, 여전히 리크루터 연락이 꾸준히 옴. 피드는 전혀 안 봄
  • 예전엔 로그인 게이트를 보면 ‘가입해야겠다’ 생각했는데, 지금은 ‘여긴 나를 원하지 않네’라고 생각함. 그래서 LinkedIn이 오히려 채용에 역효과일 수도 있음
  • LinkedIn은 너무 형편없어서 오히려 감정적으로 무감각하게 쓸 수 있음. 예전 Facebook처럼 옛 동료들과 연락할 때만 씀
  • 대부분 피드를 즐기지 않음. LinkedIn은 거의 쓰기 전용(write-only) 플랫폼임. 더 나은 대안이 필요하지만, 자동화된 스팸과 알고리즘이 어디든 따라붙는 게 문제임.
    나도 예전에 데이팅 스타트업을 운영했는데, ChatGPT 등장 이후 차별화 포인트가 사라져 접었음. AI 기반 리크루팅도 결국 더 자동화된 스팸으로 흐를 위험이 큼

• LinkedIn이 스크롤 속도를 인위적으로 제한하는 게 미친 짓처럼 느껴짐. 마치 끈적한 몰라세스 속을 걷는 느낌임

  • 이걸 우회하는 방법을 찾았음. uBlock Origin에 다음 규칙을 추가하면 됨:
    www.linkedin.com##main:style(font-size: 16px !important;)
  • 구직 페이지를 넘길 때마다 새 페이지가 리스트 맨 아래에서 시작해서 다시 위로 스크롤해야 함. 2026년에 이런 UI가 존재한다는 게 놀라움
  • 스크롤 강제 제어는 정말 미치게 함
  • 이런 아이디어를 낸 MBA를 상상해보면 웃김. Microslop식 엔지니어링의 정수임
  • 이런 스크롤 하이재킹은 제품 사고의 부패를 보여줌. 사용자를 느리게 만들어 체류 시간을 늘리려는 트릭인데, 접근성 도구나 키보드 네비게이션을 망가뜨림. 구형 노트북은 이미 LinkedIn에서 버벅이는데, 여기에 인위적 지연까지 더함

• 예전 웹 브라우저는 사용자가 RAM이나 캐시 한도를 직접 설정할 수 있었음. 지금은 그런 자원 제어권이 완전히 사라져 아쉬움

  • 결국 원격 코드 실행을 항상 허용해야만 텍스트를 읽을 수 있는 시대가 된 셈임

• LinkedIn이 1.3GB를 쓰는 이유가 궁금함. 메모리 덤프 분석을 누가 해줬으면 함.
  브라우저가 “남는 RAM은 낭비”라며 미리 점유한다는 설명도 들었지만, 그건 핑계처럼 들림. 필요할 때 OS에 요청하면 되지, 왜 미리 다 차지하나 싶음

• LinkedIn이 브라우저 확장 프로그램을 검사해서 스크린 스크래핑 방지를 시도하는 게 아닐까 추측함
  관련 스레드 참고

  • 하지만 그 코드는 아주 작고, 진짜 원인은 아님. 오히려 스팸 리크루터가 너무 많아서, LinkedIn이 데이터 스크래핑 탐지를 강화하는 건 어느 정도 이해됨

[duqduqduq]

It’s a bit absurd to see so much nonsense being spouted that a developer who understands web architecture wouldn’t say. There are dozens of reasons for the high memory usage by browsers, yet you’re claiming it’s all the site’s fault? Where did you get such idiotic nonsense mixed with your imagination to spout such rubbish? Even the V8 engine selectively allocates more memory if there is spare user resources, and if the browser strategically delays CG, it easily exceeds 1GB... If you don't know, ask an AI, you idiots.