리눅스 배포판의 메모리 사용량은 보통 기본값으로 받아들여지지만, 선언형 구성을 특징으로 하는 NixOS에서는 설정을 다듬어 얼마나 더 내려갈 수 있는지가 종종 화제가 된다. 한 운영자가 자신의 VPS 템플릿(TierHive)을 기준으로 NixOS의 RAM 사용량을 최소한으로 줄여 본 기록을 공개했는데, 애초에 특별한 작업이라 생각하지 않았지만 주변에서 놀라워하는 반응을 보고 정리에 나섰다고 한다. 작성자 본인도 반나절이면 끝날 줄 알았던 작업이 실제로는 사흘 가까이 걸렸다고 덧붙였다. 블로그용으로 작성한 메모가 아니었던 탓에 중간중간의 세부 조정은 일부 빠졌을 수 있다는 단서도 함께 달았다.
변경 전후의 숫자
핵심은 숫자다. 아무것도 손대지 않은 기본 배포 상태에서는 cloud-init을 포함해 1024MB RAM에서 '간신히' 돌아갔다. 부팅 후 메모리 사용량은 288MB, 커널 모듈은 89개가 로드된 상태였고, 같은 릴리스를 대상으로 한 단순 재빌드(rebuild)에는 896MB가 필요했다. RAM을 768MB로 낮춘 환경에서는 nix-build가 익명 메모리 505MB 지점에서 OOM 킬러에 의해 강제 종료됐다. 빌드 과정 자체가 메모리를 상당히 요구한다는 점을 보여주는 수치다.
조정을 거친 뒤에는 512MB VPS에서 유휴 시 96MB만 사용하며 커널 모듈은 54개로 줄었다. 더 인상적인 부분은 빌드 안정성이다. 채널 업데이트와 재빌드를 함께 수행하고, 원할 경우 커널을 7.3으로 교체하는 작업까지 포함해도 최대 371MB를 정점으로 512MB 안에서 OOM 없이 완료됐다. 모든 수치는 작성자 본인의 환경에서 두 번째 부팅 몇 분 뒤, 아무도 로그인하지 않은 깨끗한 상태에서 측정한 값이다. 일부는 정확히 기록했고 일부는 KB 단위를 생략하고 MB 단위만 남겼다고 밝혀, 참고용 기준치로 받아들이는 편이 적절하다.
여전히 어려운 작업: 릴리스 점프
다만 512MB로도 끝내 버거운 작업이 하나 있다. 바로 릴리스 간 이동, 즉 26.05에서 unstable로 건너뛰는 경우다. 4GB 디스크 환경에서 첫 시도는 약 30분을 끌다가 nix-build가 OOM으로 종료됐는데, 이때 기존 세대(generation)는 멀쩡히 돌아가고 있었다. 필요한 파일이 이미 내려받아진 상태였기에 같은 작업을 다시 돌리자 완료됐다. 작성자는 릴리스 점프를 할 때는 그 기간만이라도 RAM을 넉넉히 주거나, 아예 두 번 돌릴 각오를 하라고 권한다. 30분을 기다릴 게 아니라 5~10분 뒤 종료하고 재실행하는 편이 낫다는 것이다. 다만 이번 대상이 테스트할 수 있는 유일한 선택지였던 사전 릴리스(pre-release)였던 만큼, 그 특수성이 영향을 줬을 가능성도 열어 뒀다.
한 가지 분명히 할 점은 이 작업이 디스크 공간 절약과는 다른 영역이라는 것이다. 작성자는 디스크 최소화에는 별도의 과제와 단점이 따른다고 보고, 해당 옵션들을 TierHive NixOS 템플릿에 기본 적용하지 않기로 했다. 사용자가 예상하지 못한 기본값을 만들 위험이 크다는 판단에서다. 디스크 절약을 원한다면 이미 공개된 별도 가이드(nixcademy의 NixOS 이미지 최소화 글)를 참고해 직접 조합하라고 안내한다. 또한 공유된 구성 파일 중 tierhive.nix에는 cloud-init, 비밀번호 초기화, 예약 블록 같은 플랫폼 성격의 설정이 섞여 있어, RAM 절감과 직접 관련된 부분만을 떼어 보는 안목이 필요하다.
실무자에게 주는 시사점
국내에서도 저사양 VPS나 NAT 기반 인스턴스로 소규모 서비스를 운영하는 경우가 적지 않다. 이 기록은 NixOS가 선언형 구성의 유연함을 활용하면 512MB급 환경에서도 실사용이 가능하다는 구체적 증거를 제시한다는 점에서 참고 가치가 있다. 동시에 한계도 분명하다. 평상시 유휴 사용량이 낮다는 것과, 전체 재빌드·채널 업데이트·릴리스 점프 같은 '피크 작업'을 감당하는 것은 전혀 다른 문제라는 사실이다. 특히 빌드 순간의 메모리 수요가 운영의 병목이 되므로, 메모리 산정 시 유휴치가 아니라 최대 작업 부하를 기준으로 삼아야 한다.
또한 모든 수치가 단일 운영자의 측정이며 일부는 근사치라는 점, 테스트 대상이 사전 릴리스였다는 점을 감안하면 그대로 복제해 재현된다고 단정하기는 이르다. 자신의 워크로드로 직접 측정하고, 릴리스 점프처럼 메모리를 많이 쓰는 작업에는 일시적으로 RAM을 늘리거나 재실행 전략을 쓰는 운영 습관을 함께 마련하는 편이 현실적이다. 작성자 역시 더 낮출 여지가 있는지 다른 이들의 실험과 공유를 기대한다고 밝힌 만큼, 이 수치들은 완결된 정답이라기보다 각자 환경에서 출발점으로 삼을 만한 기준선에 가깝다.