압축 파일시스템은 서로 충돌하는 두 목표를 해결해야 합니다. 압축 범위를 넓히면 반복되는 바이트열을 더 많이 찾을 수 있지만, 독립 블록을 작게 유지해야 요청한 영역만 읽고 압축을 풀 수 있습니다. Harbin Institute of Technology, Shenzhen과 Huawei Technologies가 FAST 2026에서 발표한 RubikFS는 블록 크기 외에 데이터 배치도 조정할 수 있다고 판단했습니다[1]. 배포 전에 한 번 만드는 읽기 전용 이미지라면 비슷하고 자주 접근하는 청크를 같은 블록에 모아 두 목표를 함께 개선할 수 있습니다.
새 압축 알고리즘을 제안한 연구는 아닙니다. RubikFS는 고정 크기이면서 페이지 경계에 맞춘 압축 블록을 유지하고 LZ4, Zstandard, LZMA를 사용합니다. 달라지는 부분은 어떤 청크를 같은 블록에 넣을지 정하는 이미지 생성기입니다. 여섯 개 공개 임베디드·컨테이너 이미지에서 EROFS와 Squashfs 구성보다 압축률을 최대 42.60% 높였습니다. 별도의 인기 데이터 시험에서는 불필요한 읽기를 최대 70.70%, 실행시간을 최대 65.03% 줄였습니다. 서로 다른 압축기와 트레이스에서 나온 최댓값이므로 하나의 성능 배수로 합쳐서는 안 됩니다.
블록 경계가 압축에 필요한 데이터를 갈라놓습니다
EROFS와 Squashfs는 이미지를 독립적으로 압축할 수 있는 블록으로 나눕니다. 파일 하나를 읽기 위해 전체 이미지를 풀지 않아도 된다는 장점이 있습니다. 그러나 블록은 바이트 유사도가 아니라 기존 파일 배치에 따라 만들어집니다. 실행 코드, 데이터 섹션, 스크립트, 바이너리 자산이 한 블록에 섞이고, 서로 닮은 내용은 멀리 떨어질 수 있습니다. 압축 사전 범위 밖의 반복 패턴은 사용할 수 없습니다.
블록을 4 KB에서 1 MB까지 키우는 방법만으로는 이미지를 연속 바이트열로 압축한 결과에 도달하지 못했습니다. 큰 블록은 작은 데이터를 읽을 때 관계없는 바이트도 더 많이 가져옵니다. 논문은 이 상충 관계의 원인을 데이터 혼합으로 정의합니다. 따라서 시스템이 판단할 대상은 블록 크기뿐 아니라 그 블록에 어떤 데이터를 넣을지입니다.
읽기 전용 이미지는 배치를 바꿀 기회를 제공합니다. IoT 펌웨어, 보드 이미지, 컨테이너 계층은 배포 전에 만들고 실행 중에는 수정하지 않습니다. 파일시스템 인덱스가 논리 주소와 새 물리 위치를 연결하면 내부 순서를 바꿀 수 있습니다. RubikFS는 이미지 생성 때 계산 비용을 더 쓰고 이후의 모든 배포본에서 이득을 얻습니다. 한 번 만든 이미지를 많은 장치에 배포할수록 유리하지만, 갱신할 때마다 배치를 다시 계산해야 하는 쓰기 중심 파일시스템에는 같은 비용 구조가 성립하지 않습니다.
네 단계가 이미지 생성을 배치 파이프라인으로 바꿉니다
먼저 데이터 그룹화 단계가 넓은 콘텐츠 유형을 나눕니다. 유사할 가능성이 낮은 청크 사이의 비교를 줄여 계산량을 낮춥니다. 실행 코드와 실행 데이터는 서로 분리하고, 바이너리 내부의 구조화된 섹션을 기존 파일 순서보다 강한 첫 번째 분류 기준으로 사용합니다. 우연히 바이트 패턴만 비슷하고 접근 특성은 다른 데이터를 잘못 묶을 가능성도 줄어듭니다.
다음 단계는 파일을 내용 기반 청크로 나누고 완전히 같은 데이터를 제거합니다. 작은 파일이 지나치게 많은 메타데이터를 만들지 않으면서 큰 파일은 충분히 세밀하게 나누도록 청크 크기를 파일 크기에 맞춥니다. 논문이 보고한 인덱스 오버헤드는 청크 크기에 따라 0.018%~2.93%입니다. 중복 제거는 같은 청크만 찾을 수 있으므로 일부만 닮은 데이터는 처리하지 못합니다.
유사도 정렬 단계가 남은 부분 중복을 다룹니다. 청크 내용을 표본으로 뽑아 작은 특징 집합으로 만들고, 특징이 닮은 청크를 간선으로 연결한 그래프를 만든 뒤 작은 부분 그래프로 나눕니다. 같은 그룹의 청크를 압축 사전 범위 안에 배치하면 멀리 떨어져 있던 반복 바이트열도 압축기가 사용할 수 있습니다. 기본 표본 비율은 1/128, 부분 그래프 크기는 청크 64개입니다. 청크 32·64·128개를 비교한 민감도 시험에서 압축률 차이는 0.03배 미만이었으므로 특정 값 하나에만 의존한 결과는 아닙니다.
마지막으로 인기 데이터 그룹화가 실행시간의 지역성을 지킵니다. 유사도만 따라 정렬하면 자주 읽는 페이지가 차가운 블록 사이에 흩어질 수 있습니다. RubikFS는 인기 청크를 먼저 모으고 그 제약 안에서 유사도 순서를 계산합니다. 이 과정이 오프라인 저장 밀도 최적화를 실제 실행 시점의 파일시스템 설계로 바꿉니다.
이미지 생성과 이미지 읽기를 분리해 평가했습니다
이미지 생성 시험은 CPU 코어 32개와 DRAM 128 GiB가 있는 서버에서 수행했습니다. 실행시간 시험은 QEMU 기반 NVMe SSD 에뮬레이터인 FEMU를 사용했고, 4 KB 페이지와 페이지당 75 마이크로초 읽기 지연을 설정했습니다. 임베디드 호스트는 CPU 코어 2개, DRAM 1 GiB, Linux 6.16으로 구성했습니다. 재현 가능한 I/O 조건이라는 장점이 있지만 여러 상용 플래시 장치에서 측정한 결과는 아닙니다.
입력은 42 MB OpenHarmony 이미지부터 771 MB Friendica 컨테이너 이미지까지 여섯 개입니다. openEuler, 더 큰 OpenHarmony 보드 이미지 두 개, Yocto 루트 파일시스템도 포함합니다. 4 KB~1 MB 블록에서 EROFS, Squashfs, 전체 이미지를 한 번에 압축한 기준선과 비교했습니다. LZ4, Zstandard, LZMA는 각각 평가에서 정한 최고 압축 수준을 사용했습니다.
RubikFS는 모든 구성에서 두 블록 압축 파일시스템보다 높은 압축률을 보였고 일부 이미지에서는 전체 이미지 압축 기준선도 넘었습니다. 원래 멀리 떨어진 반복 바이트열을 압축기 사전 안으로 옮겼기 때문입니다. 평가한 LZ4 사전은 최대 64 KB이므로 효과가 더 크게 나타납니다. 파일시스템 블록만 키워서는 사전 범위가 늘지 않지만 데이터 순서를 바꾸면 반복 내용을 그 범위 안으로 가져올 수 있습니다.
비교할 때 블록 크기 정의가 다르다는 조건을 지켜야 합니다. Squashfs는 압축 전 크기를, EROFS와 RubikFS는 압축 후 목표 크기를 사용합니다. 전체 이미지 기준선은 독립 블록의 임의 접근도 포기합니다. 같은 기능을 제공하는 대체 시스템이 아니라 압축 밀도의 참고 상한입니다.
인기 데이터 배치가 큰 블록의 실행시간 비용을 줄입니다
논문은 openEuler 데이터의 12% 또는 40%를 인기 데이터로 지정한 두 트레이스를 만들었습니다. 12%는 저자들이 밝힌 운영 경험인 10%~15%에 가깝고, 40%는 압축률 손실을 확인하기 위한 강한 조건입니다. 1 MB 블록에서 RubikFS는 세 압축기 모두 EROFS와 Squashfs보다 적은 데이터를 읽고 더 빨리 끝났습니다.
12% 트레이스에서 LZ4 RubikFS는 16.41 MB를 읽고 1.21초에 완료했습니다. EROFS는 56.00 MB와 2.89초가 필요했습니다. LZMA는 10.13 MB만 읽었지만 압축 해제 비용 때문에 3.72초가 걸렸습니다. 저장 이미지가 가장 작은 구성이 실행도 가장 빠르다는 보장은 없음을 보여 줍니다.
인기 데이터 40% 조건에서는 LZ4가 3.02초, Zstandard가 3.03초, LZMA가 6.34초였습니다. 인기 데이터 제약이 압축률에 미친 차이는 이 강한 조건에서도 0.11배 미만입니다. 대부분의 저장 밀도를 보존하면서 불필요한 블록 읽기를 줄인 결과입니다. 실제 장치에서는 압축률만 보지 말고 CPU 성능과 부팅 마감 시간에 맞춰 압축기를 선택해야 합니다.
오프라인 계산은 한 번만 내지만 예산에서 사라지지 않습니다
그래프 생성과 분할은 이미지 생성 비용을 추가합니다. RubikFS는 유사도 분석 전에 콘텐츠 유형을 나눠 이 비용을 줄입니다. 데이터 그룹화가 없는 정렬기와 비교하면 생성시간을 21.97%~74.39% 줄였습니다. 절대 시간은 이미지마다 크게 달랐습니다. 일부 큰 OpenHarmony 이미지에서는 유사도 정렬에 수백 초가 추가됐지만, 42 MB 이미지에서는 정렬 덕분에 압축 자체가 빨라져 전체 생성시간이 오히려 줄었습니다.
이 비용은 중앙에서 한 번 만들고 널리 복제하는 아티팩트에 적합합니다. 펌웨어 업체는 몇 분을 한 번 사용하고 같은 결과를 수백만 장치에 배포할 수 있습니다. 커밋마다 컨테이너 계층을 다시 만드는 파이프라인은 생성기 CPU 시간, 변경되지 않은 계층의 재사용 가능성, 릴리스 승격 지연까지 계산해야 합니다.
이미지를 봉인하기 전에 인기 데이터를 알아야 한다는 조건도 있습니다. 부팅 경로가 안정적인 임베디드 장치는 프로파일을 만들기 쉽습니다. 범용 컨테이너는 서비스와 버전마다 접근이 달라질 수 있습니다. 인기 집합을 잘못 정해도 정합성이 깨지지는 않지만 실행시간 지역성은 일반 블록 압축 수준으로 돌아갈 수 있습니다.
실제 도입에서는 읽은 바이트와 CPU 시간을 함께 봐야 합니다
RubikFS는 압축기 하나를 고르는 문제를 이미지 배치, 압축기, 접근 프로파일을 함께 설계하는 문제로 바꿉니다. 첫 번째 지표는 유효 페이지 하나를 얻기 위해 실제 장치에서 읽은 바이트입니다. 두 번째는 해당 CPU에서 사용한 압축 해제 시간입니다. 최종 이미지 크기, 시작 지연, 이미지 생성시간도 같은 표에 넣어야 합니다.
변경되지 않는 이미지, 반복되는 구조화 콘텐츠, 안정된 인기 집합, 많은 배포 수량을 가진 시스템이 가장 적합합니다. 쓰기 가능한 데이터, 이미 압축되거나 암호화되어 유사도가 적은 자산, 인기 페이지를 예측할 수 없는 작업에는 이점이 작습니다. 평가는 최대 771 MB 이미지까지 수행했으므로 수 GB 규모로 계속 다시 만드는 컨테이너 환경은 별도 검증이 필요합니다.
도입 시험에서는 같은 압축기와 블록 목표를 사용하는 EROFS 또는 Squashfs를 유지하고 정렬 단계만 추가해야 합니다. 그래야 데이터 배치의 가치를 분리할 수 있습니다. 평균 읽기 시간뿐 아니라 시작 지연의 꼬리값도 확인해야 합니다. 잘못 묶인 소수의 부팅 필수 페이지가 장치 준비 시간을 결정할 수 있기 때문입니다.
읽기 전용 파일시스템 이미지는 단순한 파일 목록이 아니라 미리 컴파일한 배치입니다. 코드 컴파일러가 제어 흐름과 캐시 지역성을 사용하듯 이미지 생성기는 콘텐츠 유사도와 예상 접근을 입력으로 사용할 수 있습니다. 한계도 같은 지점에 있습니다. 실제 접근이 생성 때 사용한 프로파일과 달라질수록 이 컴파일의 가치는 줄어듭니다.
출처와 저작권 안내
이 글은 공개된 FAST 2026 논문을 독립적으로 분석한 편집 다이제스트입니다. USENIX 공식 논문 페이지에서 원문을 확인하고 작동 원리, 측정값, 평가 조건, 한계를 우리 표현으로 다시 썼습니다. 원문의 문장, 표, 도판은 사용하지 않았습니다. 본문 도판과 썸네일은 보고된 구조와 데이터를 바탕으로 이 글을 위해 새로 만들었습니다. 저작권 © 2026 원저자.