메모리 관리와 가비지 컬렉션

우리는 지금까지 자바스크립트의 문법, 동작 원리, 비동기 처리, 모듈 시스템 등 다양한 주제를 학습했습니다.

이 지식은 코드를 어떻게 작성할 것인가에 집중되어 있습니다.

하지만 코드를 실행하는 순간 컴퓨터 자원, 특히 메모리(Memory)를 사용하게 됩니다.

코드가 메모리를 어떻게 쓰고, 불필요해진 메모리를 어떻게 해제하는지 이해해야 성능 최적화와 애플리케이션 안정성을 확보할 수 있습니다.

자바스크립트는 C/C++ 같은 저수준 언어와 달리, 개발자가 직접 메모리를 할당하거나 해제할 필요가 없습니다.

자바스크립트 엔진이 가비지 컬렉션(Garbage Collection) 메커니즘으로 자동 관리하기 때문입니다.

다만 이 자동 관리는 메모리 관리를 전혀 신경 쓰지 않아도 된다는 뜻이 아닙니다.

가비지 컬렉션의 동작 원리를 이해해야 의도치 않은 메모리 누수(Memory Leak)를 막고 애플리케이션 성능을 최적화할 수 있습니다.

이번 장에서는 자바스크립트 메모리의 할당, 회수, 누수 시나리오, 방지 방법을 순서대로 살펴보겠습니다.

자바스크립트 메모리 생명주기

프로그래밍 언어에서 메모리 관리는 일반적으로 다음과 같은 생명주기를 가집니다.

자바스크립트에서는 이 모든 과정이 엔진에 의해 자동으로 처리됩니다.

값의 종류와 메모리 할당 방식

값과 참조를 구분할 때 스택과 힙 모델을 사용할 수 있습니다. 다만 ECMAScript가 모든 값의 실제 저장 위치나 크기를 지정하는 것은 아니며, 엔진의 표현과 최적화에 따라 달라집니다.

let a = 10;    // 숫자 원시 값
let b = "hello"; // 문자열 원시 값; 실제 저장 방식은 엔진에 따름
let c = true;  // 불리언 원시 값

let obj = { name: "Alice", age: 30 }; // obj는 객체를 참조
let arr = [1, 2, 3];               // arr는 배열 객체를 참조
let func = function() { console.log("hi"); }; // func는 함수 객체를 참조

let obj2 = obj; // obj2는 obj가 가리키는 동일한 힙 메모리 주소를 가리킴
obj2.age = 31;
console.log(obj.age); // 결과: 31 (obj와 obj2는 같은 객체를 참조하므로)

원시 값의 대입과 객체 참조의 대입을 구분하세요. 객체를 다른 변수에 대입하면 객체를 복제하지 않고 같은 객체를 참조하게 됩니다. 주소를 계산하는 대신 obj === obj2와 어느 변경이 공유되는지를 확인하면 됩니다.

가비지 컬렉션 (Garbage Collection)

앞 장의 객체 참조·클로저를 바탕으로 루트에서 어떤 경로가 남는가를 추적합니다. null 대입 한 번이나 순환 참조의 존재만으로 회수 여부를 결론 내리지 않습니다.

자바스크립트는 더 이상 필요 없는(도달 불가능한) 객체를 자동으로 찾아내 메모리에서 해제하는 가비지 컬렉션(Garbage Collection, GC) 메커니즘을 사용합니다.

GC의 목표는 개발자가 수동으로 메모리를 관리할 필요 없이 메모리 누수를 방지하고 효율적인 자원 사용을 가능하게 하는 것입니다.

도달 가능성 (Reachability) 개념

가비지 컬렉션은 기본적으로 도달 가능성(Reachability)이라는 개념을 사용하여 메모리를 해제할지 말지를 결정합니다.

• 루트(Roots): 런타임이 현재 유지하는 접근 경로의 출발점입니다. 여기서는 필요한 실행 환경의 바인딩, 전역·모듈 환경, 활성 문서와 등록된 작업 등을 모델로 봅니다. 실제 루트와 최적화는 엔진에 따릅니다.
  • 전역 let·const나 모듈 바인딩이 모두 window·global의 속성인 것은 아닙니다.
  • 문서에서 떼어낸 DOM 노드가 자동으로 영구 루트가 되는 것도 아닙니다. 다른 루트에서 그 노드로 이어지는 경로가 남는지 확인합니다.
• 도달 가능한 객체: 루트에서부터 참조 체인을 따라갈 때 접근할 수 있는 모든 객체를 도달 가능한 객체라고 합니다.
• 가비지 (Garbage): 도달 가능한 객체가 아닌 모든 객체는 가비지로 간주되어 가비지 컬렉션의 대상이 됩니다. 즉, 어떤 변수도 참조하지 않거나, 참조하더라도 루트로부터 도달할 수 없는 객체는 가비지가 됩니다.

let user = {
    name: "John"
};
// user 객체는 'user' 변수에 의해 참조되므로 도달 가능합니다.

user = null; // 이제 user 변수는 null을 가리킵니다.
             // { name: "John" } 객체는 더 이상 어떤 변수도 참조하지 않으므로 가비지가 되어 GC 대상이 됩니다.

let user1 = { name: "Alice" };
let user2 = user1; // user2도 { name: "Alice" }를 참조합니다.

user1 = null; // { name: "Alice" }는 여전히 user2에 의해 참조되므로 가비지가 아닙니다.

user2 = null; // 이제 { name: "Alice" }는 더 이상 참조되지 않으므로 가비지가 됩니다.

마크-스윕 (Mark-and-Sweep) 알고리즘

가장 널리 사용되는 가비지 컬렉션 알고리즘 중 하나입니다.

아래는 회수 비용을 줄이기 위한 기법의 개요입니다. 특정 예제의 객체가 어느 세대에 있고 언제 회수되는지까지 이 설명으로 예측할 수는 없습니다.

• Generational Collection: 객체를 새로운 세대와 오래된 세대로 나누어 관리합니다. 새로 생성된 객체는 빠르게 가비지가 될 확률이 높고, 오래된 객체는 오랫동안 살아남을 확률이 높다고 가정합니다. 따라서 새로운 세대에 대한 GC를 더 자주, 더 빠르게 수행하여 효율성을 높입니다.
• Incremental GC: GC 작업을 한 번에 모두 수행하지 않고, 작은 조각으로 나누어 점진적으로 수행합니다. 이는 GC로 인해 애플리케이션이 잠시 멈추는 현상(Stop-The-World)을 줄여 사용자 경험을 향상시킵니다.

메모리 누수 (Memory Leak)

가비지 컬렉션이 자동으로 메모리를 해제해주지만, 개발자의 실수로 인해 더 이상 필요 없는 객체가 도달 가능한 상태로 남아 있게 되는 경우가 발생합니다.

이렇게 되면 가비지 컬렉터가 해당 객체를 가비지로 인식하지 못해 메모리에서 해제하지 못하게 되고, 결국 메모리 사용량이 계속 증가하는 현상이 발생하는데, 이를 메모리 누수(Memory Leak)라고 합니다.

메모리 누수가 심해지면 애플리케이션의 성능이 저하되고, 결국 크래시(Crash)로 이어질 수 있습니다.

function createLeakyGlobal() {
    // 'use strict'가 없으면 window.leakyVar = '...' 가 됨
    leakyVar = "나는 의도치 않은 전역 변수!";
}
createLeakyGlobal();
// leakyVar는 계속 메모리에 남아있습니다.

let data = { value: "important data" };
setInterval(() => {
    // data 객체를 참조하는 콜백이 계속 실행되므로, data는 GC 대상이 되지 않음
    console.log(data.value);
}, 1000);
// data = null; // 다른 참조가 없으면 기존 객체는 GC 대상이 됨. 이후 콜백의 data.value 접근은 TypeError

// 방지법: 필요 없으면 반드시 타이머를 해제합니다.
let timerId;
function startTimerLeak() {
    let count = 0;
    timerId = setInterval(() => {
        console.log(count++);
        if (count > 5) {
            clearInterval(timerId); // 타이머 명시적 해제
        }
    }, 500);
}
startTimerLeak();

function startTimerForPractice() {
    let payloadForTimer = { label: "학습 데이터" };
    const idForTimer = setInterval(() => {
        console.log(payloadForTimer.label);
    }, 1000);
    return function stopTimerForPractice() {
        clearInterval(idForTimer);
        payloadForTimer = null;
    };
}
const stopForTimer = startTimerForPractice();
stopForTimer();
console.log("타이머 정리 요청 완료");

const button = document.getElementById('myButton');
button.addEventListener('click', function onClick() {
    // 이 함수가 외부 스코프의 큰 객체를 참조한다면 메모리 누수 발생 가능성
    console.log("버튼 클릭!");
});
// DOM에서 제거해도 외부 참조가 button/리스너를 계속 유지하면 누수 가능
// 해제하려면 등록에 쓴 함수 참조를 바깥 변수에 보관해 removeEventListener에 전달해야 함
// 위 기명 함수 표현식의 onClick 이름은 함수 바깥에서 사용할 수 없음

let longLivedRef = null;

function createClosure() {
    let largeData = new Array(1000000).fill('some string'); // 큰 배열
    longLivedRef = function() { // 이 클로저가 largeData를 참조
        console.log(largeData.length);
    };
}

createClosure();
// longLivedRef 함수가 null로 설정되거나, longLivedRef를 참조하는 다른 변수가 없어지기 전까지 largeData는 해제되지 않습니다.
// longLivedRef = null; // 이렇게 해야 largeData가 GC 대상이 됩니다.

메모리 누수 진단 도구: 크롬 개발자 도구의 Performance 탭이나 Memory 탭을 활용하면 실시간으로 메모리 사용량을 모니터링하고, 특정 시점의 힙 스냅샷(Heap Snapshot)을 찍어 어떤 객체들이 메모리에 남아 있는지 분석하여 메모리 누수를 진단할 수 있습니다.

같은 화면을 열고 닫는 동작을 예를 들어 세 번 반복한 뒤, 힙 스냅샷에서 계속 남는 객체의 개수와 retainer path(그 객체를 유지하는 참조 경로)를 비교하세요. 메모리 숫자가 한 번 증가했다는 사실만으로 누수를 확정하지 않습니다. 캐시나 아직 실행되지 않은 회수도 영향을 주며, 개발자 도구에서 잡아 둔 객체 참조도 관찰에 영향을 줄 수 있습니다. 도구 버전에 따라 화면 이름은 달라질 수 있습니다.

아래 다이어그램은 메모리 증가가 관찰될 때 어떤 참조부터 의심하고 해제해야 하는지 정리한 진단 흐름입니다.

독립 연습: null 뒤에도 남는 경로

아래 코드는 메모리를 실제로 회수하는 시점을 측정하는 실험이 아닙니다. A와 B 시점에 { label: "기록" } 객체로 가는 경로를 각각 그려 보세요. 객체가 회수 대상이 될 수 있는 시점과 출력되는 배열 길이를 구분해야 합니다.

let ownerForMemory = { label: "기록" };
const registryForMemory = [];
registryForMemory.push(ownerForMemory);
ownerForMemory = null;
console.log("A", registryForMemory.length);
registryForMemory.length = 0;
console.log("B", registryForMemory.length);

근거: MDN 도달 가능성과 메모리 관리의 한계.

메모리 관리 정리

이 절에서는 누수 시나리오를 증상 기준으로 분류하고, 해제 책임이 있는 객체를 선별하는 관점을 강조합니다.

이번 장에서는 자바스크립트의 메모리 관리 방식과 가비지 컬렉션(Garbage Collection) 원리를 다뤘습니다.

값과 객체 참조의 차이, 가비지 컬렉터가 도달 가능성을 기준으로 회수 대상을 찾는 Mark-and-Sweep 알고리즘을 확인했습니다.

또한, 자동 메모리 관리에도 불구하고 개발자의 실수로 인해 발생할 수 있는 메모리 누수(Memory Leak)의 주요 시나리오(의도치 않은 전역 변수, 해제되지 않은 타이머/이벤트 리스너, 클로저의 잘못된 사용 등)를 파악하고, 이를 방지하기 위한 실제적인 방법들을 살펴보았습니다.

메모리 관리 원리를 이해하면 누수가 생기는 참조 경로를 더 빨리 찾을 수 있습니다.

개발자 도구로 메모리 사용량을 주기적으로 확인하고, 타이머·이벤트 리스너·클로저가 불필요한 참조를 남기지 않는지 점검해야 합니다.

메모리 누수는 대부분 “루트에서 아직 도달 가능한 참조”가 남아 있을 때 발생합니다.

메모리 누수는 전역 변수, 타이머, 이벤트 리스너, 클로저가 만든 retainer path를 루트부터 순서대로 확인합니다.