그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록JavaScript
JavaScript

자바스크립트 메모리 관리는 어떻게 동작하나요?

실무4/5
설계3/5
인간4/5
기초4/5

면접관의 질문 의도

자동 GC라는 사실만 아는지, 아니면 도달 가능성과 알고리즘 차이까지 보고 누수 원인을 추적할 수 있는지를 가른다.

큐레이션 답변

학습 자료

자바스크립트는 값을 만들 때 엔진이 메모리를 자동으로 할당하고, 더 이상 어디서도 닿을 수 없는 객체를 가비지 컬렉터가 회수한다. 원시값은 보통 스택에, 객체는 힙에 동적으로 놓이고, 변수에 들어가는 건 객체 자체가 아니라 그 참조다. GC는 참조 카운팅처럼 참조 수만 세는 방식 대신, 루트(전역·실행 중 스택)에서 출발해 도달 가능한 것만 살리는 mark-and-sweep을 기본으로 쓴다. 그래서 개발자가 free를 부르지 않아도 회수가 일어나지만, 닫지 않은 클로저나 캐시처럼 참조가 남아 있으면 회수 대상이 되지 않는다.

좋은 답변 구조

  1. 01값 생성에서 회수까지 흐름을 큰 틀로 설명한다
  2. 02원시값과 객체 참조가 어디에 어떻게 저장되는지 구분한다
  3. 03참조 카운팅의 한계와 mark-and-sweep의 도달 가능성 판단을 비교한다
  4. 04자동 GC라도 참조가 남으면 회수되지 않는 경계를 짚는다

자주 실수하는 포인트

자동 GC이므로 메모리 관리를 신경 쓸 필요가 없다고 본다
참조가 살아 있는 객체도 시간이 지나면 알아서 회수된다고 오해한다
메모리 사용량이 늘어나는 것을 모두 누수로 단정한다
GC를 호출하면 즉시 그 자리에서 메모리가 회수된다고 본다

실무 맥락

  • 탭을 오래 켜두는 SPA에서 메모리 사용량이 천천히 누적되는 환경
  • 대시보드·에디터처럼 객체가 자주 생기고 사라지는 대용량 데이터 화면
  • 성능 회귀가 의심돼 힙 스냅샷이나 메모리 프로파일을 떠야 하는 상황

본인 경험에 녹이는 힌트

힙 스냅샷으로 누수 의심 객체를 추적했던 경험을 어떤 참조 체인이 남아 있었는지로 풀 수 있다

이벤트 리스너나 캐시를 정리하지 않아 메모리가 쌓였던 경험을 GC 회수 조건과 엮어 설명할 수 있다

메모리 개선 전후 사용량 지표를 들고 가 측정 기반 개선 사례로 연결할 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1GC가 stop-the-world를 일으키는 이유는 무엇인가요
Q2클로저와 캐시 구조에서 누수를 줄이려면 어떻게 설계해야 하나요
Q3WeakMap이나 WeakRef는 어떤 상황에서 의미가 있나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문