Out of Memory

컴퓨터 과학에서의 메모리 부족 현상

Out of Memory(OOM, 메모리 부족)는 컴퓨터 시스템에서 프로그램이나 운영체제가 필요로 하는 메모리(주로 RAM)를 더 이상 할당할 수 없는 상태를 의미하는 컴퓨터 과학 용어이다. 흔히 OOM이라는 약자로 널리 통용되며, 게이머나 개발자들 사이에서는 "메모리 터졌다", "오붐났다" 등의 은어로도 불린다.

1. 개요#

현대의 운영체제는 프로세스가 메모리를 요청할 때마다 이를 할당해주는데, 물리 메모리와 스왑(Swap) 영역을 모두 소진하여 더 이상 할당할 메모리가 남아있지 않으면 시스템은 다양한 방식으로 이 상황에 대응하게 된다. 이 대응 과정에서 프로그램이 강제 종료되거나, 시스템 전체가 멈추거나(행), 심한 경우 커널 패닉에 준하는 불안정 상태에 빠질 수 있다.

OOM은 특정 운영체제나 프로그램에 국한된 문제가 아니라 윈도우, 리눅스, macOS, 안드로이드, iOS 등 메모리 관리를 수행하는 모든 시스템에서 발생할 수 있는 보편적인 현상이며, 최근에는 인공지능 모델 학습 과정에서의 VRAM 부족 역시 대표적인 OOM 사례로 자주 언급된다.

2. 상세#

2.1 발생 원인#

OOM이 발생하는 원인은 크게 다음과 같이 분류할 수 있다.

• 메모리 누수(Memory Leak)
  • 프로그램이 더 이상 사용하지 않는 메모리를 해제하지 않고 계속 점유하는 현상. 시간이 지날수록 사용 메모리가 누적되어 결국 시스템 전체의 메모리를 고갈시킨다. C, C++처럼 수동으로 메모리를 관리하는 언어에서 흔히 발생하지만, 가비지 컬렉션을 사용하는 언어에서도 참조가 남아있는 객체가 해제되지 않아 발생할 수 있다.
• 과도한 메모리 요청
  • 대용량 파일 처리, 고해상도 텍스처 로딩, 대규모 배열 할당 등 프로그램이 정상적인 동작 과정에서 물리적으로 감당 불가능한 양의 메모리를 한 번에 요청하는 경우.
• 무한 루프 또는 재귀
  • 잘못된 반복문이나 재귀 함수 호출로 인해 객체나 배열이 무한정 생성되는 경우.
• 부족한 물리 메모리 및 스왑 공간
  • 애초에 시스템에 장착된 RAM 용량이 작거나, 스왑 파일/파티션이 비활성화되어 있거나 너무 작게 설정된 경우.
• 다중 프로그램 동시 실행
  • 여러 무거운 프로그램이나 가상 머신, 브라우저 탭을 동시에 실행하여 누적된 메모리 사용량이 한계를 초과하는 경우.

2.2 시스템별 대응 방식#

2.2.1 리눅스: OOM 킬러#

리눅스 커널에는 OOM Killer(Out-Of-Memory Killer)라는 메커니즘이 내장되어 있다. 시스템의 가용 메모리가 임계치 이하로 떨어지면 커널은 오버커밋(overcommit)된 메모리 요청을 그대로 허용하다가, 실제로 메모리가 고갈되는 순간 특정 프로세스를 강제로 종료시켜 시스템 전체가 멈추는 것을 방지한다.

이때 어떤 프로세스를 종료할지는 oom_score라는 점수를 기반으로 결정되며, 메모리를 많이 점유하고 있으면서도 시스템에 덜 중요하다고 판단되는 프로세스일수록 우선적으로 종료 대상이 된다. 사용자는 /proc/[PID]/oom_score_adj 값을 조정하여 특정 프로세스가 종료되지 않도록 우선순위를 낮출 수 있다.

$ dmesg | grep -i "out of memory"
[12345.678901] Out of memory: Killed process 4321 (chrome) total-vm:..., anon-rss:...

위와 같은 로그가 커널 메시지에 남는 것이 OOM 킬러가 작동했다는 대표적인 증거이다.

2.2.2 윈도우#

윈도우는 리눅스와 달리 OOM 킬러 같은 명시적인 메커니즘 대신, 페이지 파일(가상 메모리)을 적극적으로 활용하여 물리 메모리 부족 상황을 최대한 지연시킨다. 페이지 파일마저 고갈되면 개별 프로그램에서 "메모리가 부족합니다(Out of Memory / Insufficient memory)"라는 오류 메시지를 띄우며 해당 프로그램이 응답 없음 상태에 빠지거나 강제 종료되는 경우가 많다. 심한 경우 시스템 전체가 심각하게 느려지며 사실상 조작이 불가능한 상태(freeze)가 되기도 한다.

2.2.3 모바일 환경#

안드로이드는 Low Memory Killer(LMK) 혹은 후속 기술인 LMKD를 통해 백그라운드 앱을 우선적으로 종료하여 메모리를 확보한다. iOS 역시 유사한 방식으로 백그라운드 앱을 종료시키며, 포그라운드 앱이 메모리를 과도하게 사용할 경우 해당 앱 자체가 강제 종료(크래시)되기도 한다.

2.3 게임에서의 OOM#

고사양 게임, 특히 텍스처 용량이 큰 오픈월드 게임이나 모드(mod)를 다량으로 설치한 게임에서 OOM 크래시가 빈번하게 발생한다. 대표적으로 다음과 같은 사례가 자주 언급된다.

• 모드를 과도하게 설치한 베데스다의 오픈월드 게임들에서 텍스처 모드가 VRAM 및 시스템 메모리 한계를 초과하여 "Out of Memory" 오류와 함께 튕기는 현상.
• 32비트 실행 파일 기반 게임의 경우 프로세스당 메모리 할당 한계(약 4GB, 실질적으로는 2~3GB대)에 도달하여 발생하는 OOM.
• 대규모 텍스처 팩이나 셰이더팩을 설치한 마인크래프트에서 자바 힙 메모리 한계 초과로 발생하는 "java.lang.OutOfMemoryError".

이러한 이유로 커뮤니티에서는 실행 파일의 4GB 패치, 힙 메모리 할당량(-Xmx 옵션) 조정, 텍스처 압축 등을 대안으로 제시하곤 한다.

2.4 인공지능 학습에서의 VRAM OOM#

2020년대 들어 딥러닝 모델의 규모가 급격히 커지면서, GPU의 VRAM(비디오 메모리) 부족으로 인한 OOM이 일반적인 시스템 메모리 부족만큼이나 흔하게 언급되는 문제가 되었다. 흔히 CUDA OOM 또는 그냥 VRAM OOM이라 불리며, 딥러닝을 다루는 개발자·연구자 사이에서는 거의 통과의례처럼 취급된다.

2.4.1 발생 원인#

• 모델 크기 자체의 증가: LLM이나 대형 디퓨전 모델의 파라미터 수가 수십억~수천억 개에 달하면서, 모델 가중치를 GPU 메모리에 올리는 것만으로도 VRAM을 상당량 소모한다.
• 배치 크기(Batch Size) 과다: 한 번에 처리하는 데이터 샘플 수(배치 크기)를 지나치게 크게 설정하면 순전파·역전파 과정에서 저장해야 할 활성화 값과 그래디언트가 비례해서 증가해 VRAM을 초과한다.
• 그래디언트 및 옵티마이저 상태: 학습 시에는 단순히 모델 가중치뿐 아니라 그래디언트, Adam 등 옵티마이저의 모멘텀·분산 상태까지 함께 저장해야 하므로, 추론(inference)보다 학습(training)이 훨씬 많은 메모리를 요구한다. 일반적으로 풀 파인튜닝 기준 학습에 필요한 메모리는 추론 대비 3~4배 이상으로 알려져 있다.
• 시퀀스 길이(Context Length) 증가: 트랜스포머 계열 모델은 어텐션 연산의 메모리 사용량이 입력 시퀀스 길이의 제곱에 비례해 증가하는 특성이 있어, 긴 문맥을 처리할수록 VRAM 소모가 급격히 늘어난다.
• 메모리 파편화(Fragmentation): 할당과 해제가 반복되면서 VRAM 내에 사용 가능한 공간이 조각조각 흩어져, 총 여유 메모리는 충분해 보여도 연속된 큰 블록을 할당하지 못해 OOM이 발생하는 경우도 있다.

2.4.2 대표적인 오류 메시지#

PyTorch 기반 환경에서는 다음과 같은 형태의 오류가 대표적이다.

RuntimeError: CUDA out of memory. Tried to allocate 2.00 GiB (GPU 0; 
23.69 GiB total capacity; 20.91 GiB already allocated; 
1.23 GiB free; 21.45 GiB reserved in total by PyTorch)

TensorFlow에서는 ResourceExhaustedError라는 이름으로 유사한 오류가 발생한다.

2.4.3 대처 방법#

• 배치 크기 축소: 가장 간단하고 직접적인 해결책이지만 학습 속도나 그래디언트 추정의 안정성에 영향을 줄 수 있다.
• 그래디언트 누적(Gradient Accumulation): 배치 크기를 줄이는 대신 여러 스텝에 걸쳐 그래디언트를 누적한 뒤 한 번에 업데이트하여, 메모리는 적게 쓰면서도 사실상 큰 배치로 학습한 것과 유사한 효과를 낸다.
• 혼합 정밀도 학습(Mixed Precision Training): 32비트 부동소수점 대신 16비트(FP16/BF16)를 사용해 메모리 사용량과 연산 속도를 동시에 개선한다.
• 그래디언트 체크포인팅(Gradient Checkpointing): 역전파에 필요한 중간 활성화 값을 모두 저장하지 않고 일부만 저장한 뒤 필요할 때 재계산하는 방식으로, 연산량을 늘리는 대신 메모리 사용량을 크게 줄인다.
• 모델 병렬화 및 분산 학습: DeepSpeed의 ZeRO, FSDP(Fully Sharded Data Parallel) 등을 이용해 모델 가중치·옵티마이저 상태·그래디언트를 여러 GPU에 나누어 저장한다.
• 양자화(Quantization) 및 LoRA: 추론 시에는 모델을 INT8/INT4 등으로 양자화하고, 파인튜닝 시에는 전체 파라미터 대신 일부 저랭크(low-rank) 파라미터만 학습하는 LoRA(Low-Rank Adaptation) 기법을 사용해 필요한 메모리를 대폭 줄인다.
• 오프로딩(Offloading): VRAM에 다 올리지 못하는 부분을 시스템 RAM이나 NVMe SSD로 내려서 관리하는 방식. 속도는 느려지지만 아예 학습이 불가능한 상황은 피할 수 있다.

2.4.4 여담#

• Kaggle, Google Colab 등 무료/저사양 GPU 환경에서 개인 연구자나 학생들이 모델을 학습시키다가 "또 오붐났다"며 하소연하는 것은 딥러닝 커뮤니티의 흔한 밈(meme)이자 일상이다.
• VRAM OOM은 단순히 코드를 잘못 짜서 발생하는 문제라기보다, 하드웨어 자원과 모델 규모 사이의 근본적인 트레이드오프에서 비롯되는 경우가 많아, 위 대처법들을 조합해도 결국 "더 큰 GPU를 사는 것"이 가장 확실한 해결책이라는 자조 섞인 농담이 자주 나온다.

3. 관련 오류 메시지#

프로그래밍 언어 및 런타임 환경별로 OOM 상황에서 발생하는 대표적인 예외/오류는 다음과 같다.

환경	오류명
Java	java.lang.OutOfMemoryError
파이썬	MemoryError
C++ (표준 라이브러리)	std::bad_alloc
Node.js	FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
리눅스 커널	Out of memory: Kill process ...
PyTorch	RuntimeError: CUDA out of memory
TensorFlow	ResourceExhaustedError

4. 예방 및 대처 방법 (일반)#

• 메모리 프로파일링: Valgrind, VisualVM 등의 도구를 사용해 메모리 누수를 사전에 탐지한다.
• 스왑 영역 확대: 물리 메모리가 부족한 환경에서는 스왑 파티션이나 스왑 파일의 크기를 늘려 여유를 확보한다. 다만 스왑은 디스크 기반이라 속도가 느려 근본적인 해결책은 아니다.
• 리소스 제한 설정: cgroups, Docker의 --memory 옵션 등을 통해 프로세스별 메모리 사용량 상한선을 명시적으로 설정한다.
• 가비지 컬렉션 튜닝: JVM 계열 언어의 경우 힙 크기(-Xmx, -Xms)와 GC 알고리즘을 상황에 맞게 조정한다.
• 페이지네이션 및 스트리밍 처리: 대용량 데이터를 한 번에 메모리에 올리지 않고 나누어 처리한다.

5. 여담#

• 온라인 커뮤니티, 특히 게임 관련 커뮤니티에서는 컴퓨터가 갑자기 느려지거나 프로그램이 튕겼을 때 원인 불문하고 "오붐(OOM) 났다"라고 표현하는 경우가 많은데, 실제로는 OOM이 아닌 다른 원인(드라이버 충돌, 과열 등)인 경우도 상당수 섞여 있어 정확한 원인 파악 없이 통칭되는 경우가 흔하다.
• 서버 운영 환경에서는 OOM 킬러가 의도치 않게 중요한 프로세스(데이터베이스 등)를 종료시켜 장애로 이어지는 사례가 있어, 운영자들은 흔히 oom_score_adj 조정이나 별도의 모니터링 알림 설정을 통해 이를 예방한다.

6. 관련 문서#

• 메모리 누수
• 가상 메모리
• 스왑
• 커널 패닉
• 가비지 컬렉션
• 딥러닝
• VRAM