컴퓨터 성능을 이야기할 때 대부분은 CPU 속도나 RAM 용량부터 떠올리게 된다. 나도 예전에는 서버 성능이라는 게 결국 CPU가 얼마나 빠르게 계산하고 메모리가 얼마나 많은지만 중요하다고 생각했었다. 그런데 운영체제와 서버 구조를 조금씩 공부하다 보니까 현대 서버는 생각보다 “메모리 주소를 찾는 과정”에서도 엄청난 비용이 발생할 수 있다는 걸 알게 됐다. 특히 AI 서버, 데이터베이스 서버, 가상화 환경처럼 메모리를 엄청 많이 사용하는 시스템에서는 CPU가 실제 계산보다 메모리 주소 변환 때문에 더 바빠질 수도 있다고 한다. 그리고 이런 문제를 줄이기 위해 등장한 대표적인 메모리 최적화 기술 중 하나가 바로 Huge Page다. 처음 이름만 들었을 때는 그냥 메모리 페이지 크기 늘리는 기능 정도로 생각했는데, 구조를 이해하고 나니까 왜 데이터베이스 서버와 AI 서버에서 Huge Page를 굉장히 중요하게 보는지 조금 감이 오기 시작했다. 특히 인상 깊었던 건 현대 CPU는 단순 계산 속도만 중요한 게 아니라, 메모리 주소를 얼마나 빠르게 찾을 수 있는가도 엄청 중요한 시대가 되었다는 점이었다. 나도 처음에는 RAM만 충분하면 끝인 줄 알았는데, 실제로는 메모리 주소 변환 자체가 CPU 성능 병목이 될 수 있다는 게 꽤 충격적으로 느껴졌다.
CPU는 메모리를 사용할 때마다 주소 변환 과정을 거쳐야 한다
현대 운영체제는 대부분 가상 메모리(Virtual Memory) 구조를 사용한다. 쉽게 말하면 프로그램은 자신만의 독립적인 메모리 공간을 사용하는 것처럼 보이지만, 실제 물리 메모리(RAM) 주소와는 별도로 관리된다는 의미다. 처음에는 나도 “그냥 RAM 주소 바로 쓰면 되는 거 아닌가?”라고 생각했는데, 가상 메모리는 보안과 안정성, 멀티태스킹 때문에 굉장히 중요한 구조라고 한다. 문제는 CPU가 메모리에 접근할 때마다 가상 주소를 실제 물리 주소로 변환해야 한다는 점이었다. 이 과정에서 운영체제는 Page Table이라는 구조를 사용한다. 즉 CPU는 메모리 데이터를 읽기 전에 먼저 “이 가상 주소가 실제 RAM 어디에 있는지”를 찾아야 하는 것이다. 나도 처음에는 주소 변환 정도야 금방 끝날 줄 알았는데, 현대 서버처럼 수십~수백 GB 메모리를 사용하는 환경에서는 이런 주소 변환 작업도 엄청난 비용이 될 수 있다고 한다. 특히 일반적인 Linux 시스템에서는 보통 4KB 단위 페이지(Page)를 사용하는데, 메모리 사용량이 커질수록 관리해야 할 페이지 수와 Page Table 크기도 엄청나게 증가하게 된다. 결국 CPU는 실제 계산보다 메모리 주소 찾는 작업에 자주 시간을 쓰게 되는 것이다. 그리고 이 과정에서 중요한 역할을 하는 게 바로 TLB(Translation Lookaside Buffer)라는 캐시 구조다. CPU는 최근 사용한 주소 변환 결과를 TLB에 저장해서 다시 빠르게 사용할 수 있도록 하는데, 문제는 페이지 수가 너무 많아지면 TLB에 전부 담기 어려워진다는 점이었다. 결국 TLB Miss가 발생하면 CPU는 다시 Page Table을 뒤져야 하고, 이 과정에서 성능 손실이 발생하게 되는 것이다.
Huge Page는 페이지 크기를 키워서 주소 변환 부담을 줄인다
Huge Page의 핵심은 굉장히 단순하다. 바로 메모리 페이지 크기를 크게 만들어서 CPU가 관리해야 하는 페이지 수 자체를 줄이는 것이다. 예를 들어 일반적인 Linux 시스템은 기본적으로 4KB 페이지를 많이 사용하지만, Huge Page는 2MB 또는 그 이상의 큰 페이지 단위를 사용할 수 있다. 처음에는 나도 “페이지 크기 좀 커진다고 그렇게 차이가 큰가?” 싶었는데, 실제로는 페이지 수 자체가 줄어들면서 TLB 부담이 크게 감소할 수 있다고 한다. 예를 들어 1GB 메모리를 관리한다고 가정하면 4KB 페이지를 사용할 때는 엄청나게 많은 페이지 엔트리가 필요하지만, Huge Page를 사용하면 훨씬 적은 수의 페이지로 관리할 수 있다. 결국 CPU 입장에서는 TLB에 더 많은 주소 정보를 효율적으로 담을 수 있고, TLB Miss 발생 확률도 줄어들게 되는 것이다. 나도 처음에는 CPU 성능 병목이라고 하면 캐시(Cache) 정도만 생각했는데, 실제로는 메모리 주소 변환 자체도 굉장히 중요한 문제라는 걸 느끼게 됐다. 특히 데이터베이스 서버나 AI 서버처럼 엄청난 메모리를 계속 접근하는 환경에서는 Huge Page 효과가 꽤 크다고 한다. 예를 들어 Oracle DB나 PostgreSQL 같은 데이터베이스 시스템에서도 Huge Page 설정을 중요하게 보는 경우가 많고, 가상화 환경이나 GPU 메모리 처리에서도 Huge Page가 적극적으로 사용된다고 한다. 결국 현대 서버는 단순히 RAM 용량이 큰 게 아니라, 메모리 주소를 얼마나 효율적으로 관리할 수 있는가까지 최적화해야 하는 시대가 된 것이다.
그래서 현대 데이터센터는 CPU 계산보다 메모리 접근 최적화를 더 중요하게 보기도 한다
지금까지 공부했던 DMA, RDMA, DPDK, XDP 같은 기술들을 보면 공통점이 하나씩 있었다. 바로 CPU가 불필요한 작업을 하지 않게 만들고 데이터 흐름을 최대한 효율적으로 만드는 방향이라는 점이었다. Huge Page 역시 완전히 같은 흐름 위에 있다. 다만 이번에는 네트워크가 아니라 메모리 주소 변환 자체를 최적화하는 방향인 것이다. 특히 AI 서버와 데이터베이스 서버처럼 메모리 사용량이 엄청난 환경에서는 단순 계산 속도보다 메모리 접근 효율이 훨씬 중요한 경우도 많다고 한다. 나도 처음에는 서버 최적화라는 게 CPU와 GPU 스펙 경쟁이라고만 생각했는데, 실제로는 메모리 주소 변환과 TLB 효율까지 전부 성능에 영향을 준다는 게 꽤 흥미로웠다. 특히 최신 데이터센터는 CPU 계산 성능이 워낙 빨라졌기 때문에, 오히려 메모리 접근 지연과 주소 변환 비용이 더 큰 병목처럼 느껴지는 경우도 있다고 한다. 결국 현대 컴퓨터 구조는 단순 계산 속도 경쟁이 아니라, 데이터를 얼마나 빠르게 찾고 이동시키며 CPU가 실제 계산에 집중할 수 있게 만드는가의 경쟁으로 계속 발전하고 있었던 것이다. Huge Page는 그런 흐름 속에서 “메모리 주소 찾기”라는 보이지 않는 비용까지 최적화하려는 대표적인 기술처럼 느껴졌다.
한 줄로 정리하면 Huge Page는 메모리 페이지 크기를 크게 만들어 TLB Miss와 주소 변환 부담을 줄이는 기술이며, 대용량 메모리를 사용하는 데이터베이스·AI·가상화 서버에서 CPU 메모리 접근 성능을 높이는 중요한 최적화 방식이다.