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이 데이터 스크래핑 탐지를 강화하는 건 어느 정도 이해됨