RAM이 많다고 다 좋을까? 메모리 풍요가 만든 새로운 저주

메모리가 남아돌면 뭐가 문제일까

예전엔 "RAM 4GB도 사치"라고 하던 시절이 있었어요. 지금은 노트북도 16GB, 32GB가 기본이고 워크스테이션이라면 64GB, 128GB도 어렵지 않게 만나죠. 그런데 게임 개발자이자 글 잘 쓰기로 유명한 Fabien Sanglard가 "Mo RAM, Mo Problems"라는 글에서 의외의 이야기를 꺼냈어요. RAM이 많아질수록 오히려 새로운 종류의 문제들이 생긴다는 거예요. 제목은 노토리어스 B.I.G.의 "Mo Money Mo Problems"를 비튼 농담이지만, 안에 담긴 관찰은 꽤 진지합니다.

풍요가 만드는 게으름

이 글의 핵심 주장은 단순해요. 자원이 풍족해지면 그 자원을 신중하게 다루는 문화가 사라진다는 거예요. 1990년대만 해도 게임 한 편이 640KB 안에서 돌아갔고, 개발자는 어셈블리 한 줄, 비트 한 칸까지 아껴 썼어요. 지금은 가장 단순한 "Hello World" 데스크톱 앱을 Electron으로 만들면 200MB가 우습게 나옵니다. 이게 뭐냐면, 크롬 엔진을 통째로 들고 다니는 거거든요. 메모리가 싸졌으니 "굳이 줄일 이유가 없다"는 판단이 누적되면서 소프트웨어가 점점 무거워진 거죠.

글에서 짚는 진짜 문제는 단순히 "용량 낭비"가 아니에요. 캐시(cache) 효율이 떨어진다는 점이에요. CPU가 RAM에서 데이터를 한 번 읽어오는 데는 수백 사이클이 걸리는데, L1·L2·L3 캐시에 자주 쓰는 데이터가 들어가 있으면 그걸 몇 사이클 만에 꺼내 쓸 수 있어요. 그런데 데이터 구조가 메모리 여기저기 흩어져 있고 한 객체당 차지하는 크기가 크면 캐시에 잘 안 들어가고, 결국 RAM까지 매번 다녀와야 합니다. 결과적으로 RAM이 충분한데도 프로그램이 느려지는 역설이 생기는 거예요.

DRAM은 왜 안 빨라지는가

또 하나 중요한 포인트가 있어요. CPU 성능은 지난 수십 년 동안 어마어마하게 빨라졌지만, DRAM의 접근 지연(latency) 은 거의 그대로예요. 용량은 GB 단위로 늘었어도 한 번 다녀오는 시간은 1990년대와 2020년대가 크게 다르지 않아요. 그래서 현대 CPU 설계의 절반은 "어떻게든 RAM에 안 가게 하는 기술"입니다. 캐시 계층, 분기 예측, 프리페처(미리 가져오기), out-of-order 실행 같은 게 다 이걸 위한 장치예요.

이 맥락에서 "메모리가 남아도니까 자료구조 막 짜도 된다"는 태도는 실제로 성능을 깎아먹어요. 요즘 게임 엔진과 데이터베이스 엔진에서 Data-Oriented Design, Structure of Arrays(SoA), arena allocator 같은 개념이 다시 주목받는 이유가 여기 있어요. 이게 뭐냐면, 객체지향식으로 "한 객체 안에 모든 필드를 모아두자"가 아니라, "같은 종류의 필드끼리 배열로 묶어두자"는 발상이에요. 이렇게 하면 캐시에 쭉 이어진 데이터가 들어가서 순회 성능이 몇 배씩 빨라지거든요.

업계가 보내는 신호

최근 몇 년 사이 흐름을 보면 이 "풍요의 저주"에 대한 반작용이 확실히 있어요. Rust가 인기를 얻은 배경에는 GC 없이도 안전하게 메모리를 다룰 수 있다는 매력이 있고, Zig는 명시적 할당자(allocator)를 일급 시민으로 다루며 메모리 사용을 다시 의식하게 만들죠. Apple이 통합 메모리 아키텍처(UMA)를 밀고, NVIDIA가 Grace Hopper에서 CPU·GPU 메모리를 통합하는 것도 "단순히 더 많이"가 아니라 "어떻게 잘 쓸까"의 방향이에요. Discord나 Figma처럼 처음엔 Electron으로 시작했다가 핵심 부분을 네이티브로 다시 짜는 사례도 같은 맥락이고요.

반대편에는 LLM이 있어요. 70B 파라미터 모델 한 번 띄우는 데 140GB의 VRAM이 필요한 시대니까요. 이쪽은 양자화(quantization), KV 캐시 최적화, FlashAttention처럼 메모리 사용량을 어떻게든 줄이려는 연구가 폭발적으로 진행되고 있죠. 즉 한쪽에선 "메모리 막 써", 다른 쪽에선 "한 바이트도 아껴"라는 두 흐름이 동시에 흐르는 흥미로운 시점입니다.

한국 개발자에게 주는 시사점

실무에서 당장 적용할 만한 건 두 가지예요. 첫째, 프로파일링을 메모리 사용량과 캐시 미스 관점에서도 해보세요. 리눅스라면 perf stat로 cache-misses를 찍어볼 수 있고, macOS에서는 Instruments의 Counters 템플릿을 쓸 수 있어요. "내 코드 어디서 캐시를 못 타고 있나"를 한 번 보면 시야가 확 넓어집니다. 둘째, 자료구조를 설계할 때 "이 배열을 순회할 때 한 줄에 몇 바이트가 들어오지?"를 의식해보세요. 64바이트 캐시 라인 안에 의미 있는 데이터가 얼마나 들어가는지가 성능을 결정해요.

물론 모든 코드를 이렇게 짤 필요는 없어요. 사내 어드민 페이지를 캐시 친화적으로 짠다고 사업이 더 잘되진 않으니까요. 다만 핫패스(hot path), 그러니까 가장 자주 실행되는 루프나 렌더링 루프 같은 곳에서는 이 사고방식이 큰 차이를 만듭니다.