압축 효율을 높인 메스포틴 RLE: 비트맵 기반 가변 런 저장 방식

초록

본 논문은 전통적인 런‑길이 인코딩(RLE)의 비효율성을 보완하기 위해, 문자별 압축 가능성을 사전 판단하고 압축 가능한 문자에만 런 정보를 저장하는 메스포틴‑RLE 방식을 제안한다. 256비트의 압축 가능성 비트맵을 헤더에 두어, 압축 불가능한 문자에 대해서는 런 바이트를 생략하고 문자만 기록함으로써 최악의 경우에도 32바이트(256비트) 이상의 오버헤드가 발생하지 않는다.

상세 분석

메스포틴‑RLE는 기존 RLE가 “문자‑런” 순서(예: ‘A5’)로 데이터를 저장하면서, 압축이 불가능한 경우에도 런 바이트를 강제로 삽입해 데이터 크기가 증가하는 구조적 한계를 지적한다. 이를 해결하기 위해 두 가지 핵심 아이디어를 도입한다. 첫째, 256비트(32바이트) 크기의 비트맵을 파일 앞부분에 배치해 각 ASCII 코드가 압축 가능한지(연속된 동일 문자 2회 이상 등장) 여부를 미리 표시한다. 둘째, 실제 데이터 스트림에서는 “문자‑런”이 아니라 “문자‑다음문자” 순서로 기록한다. 압축 가능한 문자라면 뒤에 런(1바이트) 값을 붙이고, 압축 불가능한 문자라면 바로 다음 문자로 이동한다. 디코딩 시에는 동일한 비트맵을 참조해 현재 문자가 압축 가능한지 판단하고, 필요하면 다음 바이트를 런으로 해석한다.

이 설계는 다음과 같은 장점을 제공한다. 1) 압축 불가능한 문자에 대한 불필요한 런 저장을 완전히 제거해 최악의 경우에도 원본 크기에 32바이트만 추가한다. 2) 비트맵이 고정 길이이므로 스트림 전체 길이에 비례한 메타데이터 오버헤드가 발생하지 않는다. 3) 구현이 단순해 기존 RLE 인코더/디코더에 비트맵 생성·검사 로직만 추가하면 된다.

하지만 몇 가지 한계도 존재한다. 비트맵은 전체 ASCII 집합을 가정하므로, 멀티바이트 문자 인코딩(예: UTF‑8)에서는 비트맵 크기가 급증하거나 의미가 퇴색한다. 또한 압축 가능성 판단을 사전 스캔해야 하므로 인코딩 단계가 두 번 수행돼 시간 복잡도가 증가한다(특히 대용량 스트림에서). 런 길이 표현이 1바이트에 제한되므로 255를 초과하는 연속 구간은 추가 바이트를 사용해 확장해야 하는데, 이는 구현 복잡성을 높인다. 마지막으로, 비트맵 자체가 압축되지 않으므로 이미 압축된 데이터에 재적용할 경우 오히려 부피가 늘어날 위험이 있다.

전반적으로 메스포틴‑RLE는 “압축 가능한 경우에만 런을 저장한다”는 직관적인 최적화를 통해 전통적인 RLE의 가장 큰 약점을 보완했으며, 특히 ASCII 기반 텍스트나 제한된 문자 집합을 다루는 임베디드 시스템에서 유용할 것으로 기대된다.