보이지 않는 인프라를 다시 다듬겠다는 선언
좋은 시스템은 화려한 기능 위에 서 있는 것처럼 보이지만, 실제로는 보이지 않는 기반 위에서 버틴다.
2026년 3월 2일 Meta는 Investing in Infrastructure: Meta's Renewed Commitment to jemalloc라는 글을 통해 jemalloc에 대한 “재투자”를 공식적으로 선언했다. 핵심 메시지는 단순하다. jemalloc은 여전히 Meta의 소프트웨어 스택에서 매우 중요한 구성 요소이며, 앞으로는 유지보수 부담을 낮추고 코드베이스를 현대화하면서도 최신 하드웨어와 워크로드에 맞게 계속 진화시키겠다는 것이다. Meta는 여기에 더해 오픈소스 커뮤니티와의 협업, 외부 기여, 공동 로드맵 수립까지 분명히 약속했다.
이 발표가 흥미로운 이유는, 이 글이 “새로운 기능 출시”가 아니라 “기초 체력 복구”에 관한 이야기이기 때문이다. Meta는 jemalloc을 리눅스 커널, 컴파일러와 나란히 놓일 정도로 중요한 기반 소프트웨어로 설명한다. 즉, 최종 사용자는 잘 못 보지만, 전체 서비스의 성능·안정성·운영 효율에 장기적으로 큰 영향을 미치는 층이라는 뜻이다.
jemalloc이 원래 왜 중요했을까
jemalloc은 범용 malloc(3) 구현체로, 핵심 목표를 메모리 단편화 억제와 높은 동시성 확장성에 둔다. 공식 저장소 설명에 따르면 jemalloc은 2005년 FreeBSD의 libc allocator로 처음 실사용에 들어갔고, 2010년 무렵부터는 힙 프로파일링, 모니터링, 튜닝 훅 같은 개발자 지원 기능까지 넓혀 가며 “실전용 allocator”로 발전해 왔다.
이 맥락은 Meta가 2011년에 공개한 jemalloc 글을 보면 더 선명해진다. 당시 Facebook은 대규모 서버 애플리케이션 환경에서 allocator에 세 가지를 동시에 요구했다. 첫째, 할당과 해제가 빨라야 하고, 둘째, 실제 사용 메모리와 RAM 사용량의 관계가 예측 가능해야 하며, 셋째, 운영 환경에서 메모리 사용 패턴을 분석할 수 있도록 힙 프로파일링이 가능해야 했다. Facebook은 당시 존재하던 allocator들이 이 세 가지를 동시에 만족시키지 못했다고 보고, jemalloc에 힙 프로파일링과 여러 최적화를 더해 이를 해결하려 했다.
이후 jemalloc은 Meta 내부 인프라에서도 꽤 깊이 자리 잡았다. 2019년 Meta는 Memscout이라는 도구를 공개하면서, jemalloc이 Facebook 인프라 서비스 전반의 기본 allocator라고 설명했다. 즉 jemalloc은 “어떤 한 제품에서 쓰이는 라이브러리”가 아니라, 운영과 성능 분석의 중심축 역할까지 해온 셈이다.
그런데 왜 굳이 “Renewed Commitment”일까
이번 발표에서 가장 눈에 띄는 대목은 Meta가 기술적인 성과보다 먼저 반성을 말한다는 점이다. Meta는 최근 몇 년 동안 jemalloc 개발을 이끌던 핵심 엔지니어링 원칙에서 점차 멀어졌고, 일부 결정은 단기적인 이점을 줬지만 결국 기술 부채를 쌓아 장기적인 진전을 늦췄다고 인정했다. 또한 커뮤니티 피드백을 진지하게 받아들였고, 프로젝트 창립자인 Jason Evans를 포함한 커뮤니티 구성원들과 대화하며 관리 방식 자체를 바꾸고 있다고 설명했다.
이 문장을 더 무겁게 만드는 배경도 있다. Jason Evans는 2025년 6월 공개한 회고 글에서 jemalloc이 2004년 구상되어 20년 가까이 공개적으로 사용되어 왔지만, 당시 기준으로는 “active upstream development has come to an end”라고 적었다. 그러니 2026년 Meta의 발표는 단순한 유지보수 공지가 아니라, 사실상 “중단되어 가던 기반 프로젝트를 다시 장기 모드로 돌리겠다”는 신호로 읽힌다.
Meta는 그 결과로 원래의 jemalloc 오픈소스 저장소가 다시 unarchive되었다고 밝혔다. 그리고 신뢰는 말이 아니라 행동으로 쌓인다는 점을 인정하면서, 앞으로 프로젝트의 건강성과 진척으로 이를 보여 주겠다고 했다. 이 문장 하나만 봐도 이번 글의 주제가 성능 숫자보다 프로젝트 운영 철학에 더 가깝다는 걸 알 수 있다.
Meta가 앞으로 집중하겠다고 밝힌 4가지
Meta는 앞으로 jemalloc에서 네 가지 축에 집중하겠다고 정리했다. 첫째는 기술 부채 정리와 리팩터링, 둘째는 Huge-Page Allocator(HPA) 개선, 셋째는 packing·caching·purging 중심의 메모리 효율 개선, 넷째는 AArch64(ARM64) 플랫폼에서의 기본 성능 개선이다. 이 네 가지는 각각 독립된 항목처럼 보이지만, 사실은 모두 “allocator를 최신 하드웨어와 대규모 서비스 환경에 다시 맞추겠다”는 하나의 방향으로 이어진다.
1) 기술 부채 정리
가장 먼저 기술 부채를 전면에 둔 점이 중요하다. allocator는 겉에서 보면 malloc/free만 제공하는 단순한 구성 요소처럼 보이지만, 실제 내부는 동시성 제어, 페이지 관리, 메타데이터, 캐시, purge 정책, huge page 활용 같은 요소가 복잡하게 얽혀 있다. Meta가 이 계층에서 “유지보수 부담을 낮추고 코드베이스를 현대화하겠다”고 말한 건, 성능 최적화보다 앞서 지속 가능한 개발 구조를 되찾겠다는 의미에 가깝다.
2) Huge-Page Allocator와 THP
이번 발표에서 기술적으로 가장 눈에 띄는 키워드는 HPA와 THP다. Meta는 HPA를 더 발전시켜 transparent hugepages(THP)를 더 잘 활용하고, 그 결과 CPU 효율을 높이겠다고 했다. jemalloc 공식 문서에는 이미 opt.thp가 존재하며, 운영체제가 지원할 때 THP를 "always", "never", "default"로 제어할 수 있다. 또 opt.metadata_thp를 통해 allocator 내부 메타데이터에 대해서도 THP 사용을 제어할 수 있다.
이게 그냥 옵션 몇 개 추가된 수준이 아니라는 점도 확인된다. jemalloc의 현재 개발 브랜치에는 opt.hpa, hpa_slab_max_alloc, hpa_hugification_threshold, hpa_hugify_delay_ms, hpa_purge_threshold 등 HPA 관련 옵션이 다수 존재하고, stats.arenas.<i>.hpa_shard_*처럼 HPA shard 단위 통계도 별도로 잡혀 있다. 즉 HPA는 “거대한 페이지를 써 보자” 정도의 실험이 아니라, allocator 내부 설계에서 상당한 비중을 차지하는 축으로 커졌다는 뜻이다.
이 흐름은 과거 릴리스 노트에서도 이어진다. jemalloc 5.1.0 릴리스에는 내부 메타데이터에 대한 THP 지원과 opt.thp, opt.metadata_thp 추가가 포함되어 있다. 다시 말해 Meta의 이번 계획은 갑자기 등장한 새 주제가 아니라, 예전부터 이어져 온 huge page 관련 설계를 더 본격적으로 밀어붙이겠다는 선언이다.
3) 메모리 효율: packing, caching, purging
Meta가 언급한 “packing, caching, purging”도 굉장히 allocator다운 표현이다. jemalloc 문서만 봐도 thread-specific cache(tcache)는 작은 객체 할당을 스레드별 캐시에서 처리해 동기화 비용을 줄이지만, 그 대가로 메모리 사용량이 늘 수 있다고 설명한다. 즉 allocator는 언제나 CPU 효율과 메모리 효율 사이의 교환관계를 다룬다.
또 jemalloc 통계는 allocated, active, metadata, resident, mapped, retained처럼 메모리 상태를 세분화해서 보여 준다. 예를 들어 allocated는 애플리케이션이 실제 할당한 바이트 수이고, active는 활성 페이지 기준 사용량이며, resident는 물리 메모리에 상주하는 페이지 기준의 최대치, retained는 운영체제에 반환하지 않고 잡아 둔 가상 메모리 양이다. 이 분리는 “프로세스가 메모리를 얼마나 먹는가”가 단순한 숫자 하나로 설명되지 않음을 보여 준다. Meta가 packing·caching·purging 개선을 약속한 건 결국 이 여러 층위의 메모리 비용을 다시 더 정교하게 다루겠다는 뜻이다.
4) AArch64 최적화
마지막으로 AArch64 최적화는, 지금 인프라 시장의 흐름을 생각하면 아주 현실적인 과제다. Meta는 ARM64 플랫폼에서 jemalloc이 별도 튜닝 없이도 좋은 성능을 내도록 하겠다고 했다. jemalloc 이슈 트래커의 2024년 논의에서도 ARM64가 4K, 16K, 64K 페이지 크기를 지원하고, 기본 설정이 이를 충분히 포괄하지 못하면 애플리케이션이 충돌할 수 있다는 지적이 있었다. 즉 ARM64 최적화는 단순 성능 향상만이 아니라, 페이지 크기 다양성까지 고려한 기본 호환성 문제이기도 하다.
이 발표가 왜 더 의미 있게 느껴질까
jemalloc GitHub 릴리스 페이지를 보면 현재 최신 정식 릴리스는 2022년 5월의 5.3.0으로 표시된다. 여기에 2025년 Jason Evans의 회고 글까지 함께 놓고 보면, 이번 Meta 발표는 “좋은 allocator니까 계속 쓰겠다” 수준이 아니라, 장기간 둔화된 업스트림의 생명력을 다시 회복시키겠다는 선언에 가깝다.
그래서 이번 글을 읽으며 가장 인상적이었던 부분은 성능 수치가 아니라 태도였다. Meta는 jemalloc이 높은 레버리지와 높은 책임을 동시에 갖는 기반 소프트웨어라고 말했고, 단기적 이익보다 원칙이 더 중요하다는 점을 다시 강조했다. 결국 이번 발표의 핵심은 “allocator를 빠르게 만들겠다”가 아니라, 신뢰할 수 있는 기반 소프트웨어를 다시 제대로 돌보겠다는 데 있다.
정리
이번 Meta 글은 화려한 기술 발표문이라기보다, 인프라 엔지니어링의 기본으로 돌아가겠다는 선언문에 가깝다. jemalloc은 오랫동안 높은 성능의 allocator였지만, 이번 발표가 말해 주는 건 성능 그 자체보다 더 큰 이야기다. 좋은 인프라는 한 번 잘 만들어 두고 끝나는 게 아니라, 기술 부채를 정리하고, 커뮤니티와 신뢰를 회복하고, 새로운 하드웨어 환경에 맞춰 계속 다시 설계해야 유지된다는 것이다.
그리고 바로 그 점 때문에, 이 글의 제목은 jemalloc 이야기이지만 실제 주제는 “보이지 않는 기반에 다시 투자하는 엔지니어링 조직의 태도”라고 보는 편이 더 정확하다.
