“프로그래밍 언어는 사용하지 않는 메모리를 어떻게 자동으로 정리할까?”
많은 언어(Java, Python, Go 등)는 개발자가 메모리를 직접 관리하지 않아도 된다.
그 이유가 바로 가비지 컬렉션(Garbage Collection, GC) 때문이다.
이번 글에서는 GC가 무엇인지, 어떻게 동작하는지, 장단점과 필요성까지 한 번에 정리한다.
1. 가비지 컬렉션이란?
가비지 컬렉션(GC)은
프로그램에서 더 이상 사용하지 않는 객체(메모리)를 자동으로 찾아 삭제하는 메모리 관리 시스템이다.
즉,
개발자가 일일이 free()를 하지 않아도
런타임(JVM, Python 인터프리터 등)이 알아서 메모리를 정리해준다.
예전 C 언어처럼 “직접 할당/해제”하지 않아도 된다는 것이 가장 큰 특징이다.
2. 왜 필요할까?
GC가 없는 언어(C/C++)에서는 개발자가 직접 메모리를 해제한다.
하지만 이 과정에서 대표적으로 아래 문제가 발생한다.
● 메모리 누수(Memory Leak)
해제해야 하는 객체를 깜빡하면 메모리가 계속 쌓여 프로그램이 느려진다.
● 댕글링 포인터(Dangling Pointer)
이미 해제된 메모리를 참조하는 위험한 상황.
● Use-After-Free
지워진 객체를 다시 사용하는 심각한 버그 → 보안 취약점의 원인.
● Double Free
같은 메모리를 두 번 해제하면 프로그램이 바로 Crash.
이런 문제를 방지하기 위해
GC는 프로그램 전체의 메모리를 자동으로 감시하고 정리하는 관리자 역할을 한다.
3. GC는 어떻게 동작할까?
GC의 핵심 개념은 Reachability(도달 가능성)이다.
✔ (1) 현재 사용 중인 객체 찾기
스택, 전역 변수, 레지스터 등에서
현재 프로그램이 “참조하고 있는 객체”들을 확인한다.
이것을 Root(루트)라고 부른다.
✔ (2) Root에서 연결된 객체 추적
Root에서 접근 가능한 모든 객체를 “사용 중”이라고 표시(mark)한다.
✔ (3) 아무도 참조하지 않는 객체 삭제 -> Count 가 0 일때
Root에서 연결되지 않은 객체는 다시 접근할 방법이 없기 때문에
→ GC가 삭제하고 메모리를 회수(cleanup).
4. 대표적인 GC 방식
Mark & Sweep
- 살아있는 객체 표시(mark)
- 표시되지 않은 객체 제거(sweep)
Java에서 기본적으로 사용되는 형태.
Copying GC
살아있는 객체만 다른 영역으로 복사하고
이전 영역 전체 삭제.
Young Generation(일시적 객체)에서 많이 사용.
Generational GC (세대별 GC)
“대부분의 객체는 금방 죽는다”는 통계 기반.
- Young Generation → 짧은 시간 안에 사라지는 객체
- Old Generation → 오래 살아남은 객체
Java, Go 등이 이 구조를 채택.
5. GC의 단점도 있다
● Stop-the-world
GC가 실행되는 동안 프로그램이 잠시 멈춘다.
레이턴시가 중요한 게임/트레이딩 서비스에서는 문제될 수 있음.
● 메모리 사용량 증가
복사 기반 GC는 영역을 반씩 나눠야 하고
여러 관리 정보도 필요해 C/C++보다 메모리를 더 많이 사용한다.
● 실행 시점 예측 어려움
언제 GC가 돌지 100% 예측할 수 없다.
(튜닝하지 않으면 갑자기 지연 발생 가능)
6. GC의 장점
● 메모리 관리 부담 감소
free(), delete 같은 해제 작업 필요 없음.
● 안정성 향상
메모리 누수, 댕글링 포인터, UAF 같은 위험한 버그를 크게 줄인다.
● 개발 생산성 증가
비즈니스 로직에 집중할 수 있다.
● 객체지향 언어와 잘 맞는다
객체 생성/소멸이 많은 구조에서도 안정적.
7. GC는 “전역함수로 치우는 것”이 아니다
종종 오해하는 부분인데, GC는 다음과 같은 방식이 아니다.
✗ 어떤 전역함수를 호출해 지우는 것
✗ 개발자가 명시적으로 삭제 요청하는 것
실제 의미는 아래와 같다.
✔ 언어 런타임(JVM, Python 인터프리터 등)이
✔ 프로그램 전체를 감시하고
✔ 더 이상 쓰지 않는 객체를 자체 판단으로 삭제하는 시스템
즉, GC는 백그라운드에서 항상 동작하는 자동 메모리 관리자이다.