크롬 브라우저는 왜 메모리를 계속 먹을까

크롬 메모리 누수의 구조적 이유와 DevTools로 확인하는 방법

크롬을 오랜 시간 켜 두다 보면 탭을 많이 열지 않았는데도 메모리 사용량이 계속 증가하는 경우가 있습니다.
이때 개발자 도구를 확인해 보면 특정 웹사이트의 문제라기보다, 크롬 브라우저 자체가 메모리를 점점 더 점유하고 있는 것처럼 보이기도 합니다.

이 글에서는 웹 개발자의 코드 문제를 넘어 크롬 브라우저 구조 관점에서 왜 메모리 누수처럼 보이는 현상이 발생하는지,
그리고 Chrome DevTools 공식 문서가 설명하는 원인과 관찰 방법을 정리해 드리겠습니다.

 

크롬은 원래 메모리를 많이 사용하도록 설계된 브라우저입니다

먼저 중요한 전제부터 말씀드리겠습니다.

크롬의 높은 메모리 사용량은 단순한 최적화 부족이나 버그가 아니라, 안정성과 보안을 우선시한 구조적 설계의 결과입니다.

크롬은 다음과 같은 다중 프로세스 아키텍처를 사용합니다.

• Browser Process
• Renderer Process (탭 단위 분리)
• GPU Process
• Network Process
• Utility Process

각 탭과 iframe, 확장 프로그램이 서로 다른 프로세스로 분리되기 때문에
하나의 페이지가 오류를 일으켜도 전체 브라우저가 종료되지 않습니다.

다만 이 구조는 메모리를 즉시 반환하지 않는 방향으로 동작하는 특징을 갖고 있습니다.

 

크롬의 메모리 누수란 정확히 무엇을 의미할까요

Chrome DevTools 문서에서 말하는 메모리 문제는
일반적으로 생각하는 “메모리가 절대 해제되지 않는다”는 의미와는 다소 차이가 있습니다.

크롬에서 관찰되는 메모리 문제는 주로 다음과 같은 경우입니다.

1. 더 이상 필요하지 않은 객체가 GC 대상이 되지 않는 경우
2. 해제 가능한 메모리를 성능상 이유로 유지하는 경우
3. OS로 반환되지 않고 내부 캐시로 남아 있는 경우

즉, 논리적인 누수와 설계상 유지되는 메모리가 혼재되어 있습니다.

 

크롬이 메모리를 쉽게 내려놓지 않는 구조적 이유

1. V8 엔진의 힙 재사용 전략

크롬의 자바스크립트 엔진인 V8은 한 번 확장된 힙 메모리를 즉시 운영체제에 반환하지 않습니다.

그 이유는 다음과 같습니다.

• 메모리 재할당 비용이 큼
• 다시 메모리가 필요해질 가능성이 높음
• 성능 안정성이 메모리 절감보다 중요함

이로 인해 가비지 컬렉션이 발생했음에도 DevTools에서 JS Heap 크기가 크게 줄지 않는 경우가 자주 나타납니다.

이는 누수라기보다 의도적인 메모리 유지 전략에 가깝습니다.

 

2. Renderer 프로세스 단위의 메모리 유지

탭을 닫았다고 해서 항상 메모리가 즉시 해제되지는 않습니다.

다음과 같은 기능이 영향을 줍니다.

• 뒤로 가기 캐시 BFCache
• 탭 복원 세션
• prerendering
• back forward navigation

사용자는 탭을 닫았다고 인식하지만, 크롬은 빠른 화면 복원을 위해 해당 Renderer 프로세스를 일정 시간 보관합니다.

공식 문서에서도 탭 종료와 메모리 해제는 동일한 개념이 아님을 명확히 설명하고 있습니다.

 

3. GPU 프로세스와 이미지 캐시

크롬은 이미지 디코딩 결과, 캔버스 데이터, 텍스처 정보를 GPU 메모리와 적극적으로 공유합니다.

이 과정에서 다음과 같은 현상이 발생할 수 있습니다.

• 화면에서 사라진 요소가 GPU 메모리에 남아 있음
• 스크롤된 이미지가 캐시로 유지됨
• Canvas, WebGL, CSS 애니메이션 사용 시 급격한 메모리 증가

따라서 화면상으로는 단순한 페이지라도 GPU 메모리 사용량은 지속적으로 증가하는 것처럼 보일 수 있습니다.

 

4. 확장 프로그램이 만드는 보이지 않는 메모리 문제

크롬 메모리 문제의 상당 부분은 웹사이트가 아니라 확장 프로그램에서 발생합니다.

확장 프로그램은 다음과 같은 작업을 수행할 수 있습니다.

• 백그라운드 스크립트 상시 실행
• 모든 탭에 content script 주입
• DOM, 이벤트, 메시지 채널 유지

특히 장시간 실행되는 백그라운드 서비스는 가비지 컬렉션과 무관하게 메모리를 점유하는 경우가 많습니다.

 

Chrome DevTools가 말하는 “문제가 되는 메모리 상태”

공식 문서에서 정의하는 문제 상황은 다음과 같습니다.

• 동일한 사용자 행동을 반복했을 때
• 동일한 시나리오 이후에도
• Heap snapshot 간 객체 수가 지속적으로 증가
• Detached DOM tree가 누적
• Allocation timeline이 우상향

중요한 점은 메모리를 많이 쓰는 것과, 메모리가 계속 증가하는 것은 전혀 다른 문제라는 것입니다.

 

크롬 메모리 문제를 확인할 때의 올바른 접근 방법

1. 단일 Heap snapshot은 기준이 될 수 없습니다

Heap snapshot 하나만 보고 메모리 누수라고 판단해서는 안 됩니다. 반드시 다음 과정을 거쳐야 합니다.

• 동일한 시나리오 반복 실행
• 최소 2회 이상의 스냅샷 비교
• 객체 수와 retained size 변화 확인

 

2. Detached DOM tree는 가장 중요한 신호입니다

Chrome DevTools 문서에서도 가장 강조하는 항목입니다. Detached DOM은 다음 상태를 의미합니다.

• 화면에서는 제거됨
• 자바스크립트 참조는 남아 있음
• Renderer 프로세스 메모리에 계속 유지됨

이 현상이 반복되면 탭을 닫기 전까지 메모리는 줄어들지 않습니다.

 

3. Allocation Timeline은 시간 기반 누수를 보여줍니다

Heap snapshot이 정적인 분석이라면, Allocation Timeline은 시간 흐름에 따른 메모리 변화를 보여줍니다.

• 특정 사용자 행동 이후 메모리 증가
• GC 이후에도 기준선이 상승
• 반복적인 증가 패턴 확인 가능

이 패턴이 보인다면 크롬 내부 구조 또는 웹 로직 중 어느 한쪽에 문제가 존재합니다.

 

정리하며

크롬의 메모리 누수 현상은 단순히

• 웹 개발자의 실수
• 크롬의 최적화 부족

때문에 발생하는 문제가 아닙니다. 대부분은 다음 요소가 복합적으로 작용한 결과입니다.

• 안정성을 우선한 다중 프로세스 구조
• V8 엔진의 힙 관리 전략
• 사용자 경험을 고려한 캐싱 정책
• GPU 처리 및 확장 프로그램의 영향

따라서 크롬의 메모리 문제를 분석할 때는 “얼마나 사용하고 있는가”보다
“왜 계속 증가하는가”를 중심으로 보시는 것이 중요합니다.