문서 압축의 흔한 오해: 잘못된 상식에서 엔지니어링 해법까지

대부분의 사람은 압축 도구를 고를 때, 여기저기서 들은 몇 가지 말을 기준으로 판단한다. 들으면 다 맞는 것 같은데, 막상 진짜 문서에 대면 자꾸 걸린다. 우선 그 말들을 꺼내놓고, 하나씩 깨보고, 그다음에 진짜 돌아가는 엔지니어링이 어떻게 생겼는지 보자.

흔히들 믿는 "상식"

첫째, 압축률을 아무리 높게 적어도 좋다. 90%를 쓰는 곳이 제일 대단하다.

둘째, 모든 파일은 크게 줄여야 한다. 안 눌리면 그건 도구가 형편없는 것이다.

셋째, 온라인 압축 사이트나 로컬 도구나 결과는 같다. 어차피 압축하는 거니까.

넷째, 압축하면 파일이 상한다. 도장이나 서명은 압축하고 나면 흐릿해진다.

다섯째, 압축은 한 번에 끝나는 일이다. 하나의 슬라이더로 모든 포맷을 커버한다.

이 다섯 가지, 어느 것 하나 제대로 선 게 없다.

오해 1: 압축률이 높을수록 좋다 — 절댓값을 자로 삼는 게 잘못

압축률은 절댓값이 아니라 "여분(redundancy)"에 대한 비율이다. 섀넌은 정보 이론에서 이렇게 결론지었다. 한 데이터에서 문맥을 보고 예측할 수 있는 부분은 모두 여분이며, 압축이 할 수 있는 일은 더 짧은 부호로 그 여분을 다시 표현해 그 데이터의 "정보 엔트로피" 하한에 다가가는 것이다.

아주 직관적인 예를 들어보자. 한글에서 "의"는 아주 자주 나오고 "묘"는 좀처럼 안 나온다. 자주 쓰는 글자엔 더 짧은 비트를, 드문 글자엔 더 긴 비트를 배당하면, 전체 길이는 "모든 글자를 똑같이 길게"보다 훨씬 짧아진다. 압축 알고리즘은 정보를 없애는 게 아니라, 예측 가능한 부분에 더 이상 비트를 들이지 않는 것뿐이다.

문제는 이렇다. 이미 엔트로피 한계에 가까운 포맷, 가령 JPEG, MP4, ZIP, 그리고 PDF 안에서 이미 최적화된 이미지는 더 누를 공간이 극히 작다. 이건 도구가 약한 게 아니라, 바탕이 이미 꽉 찬 것이다. 진짜 물어야 할 건 "네가 다루는 그 파일 종류에서 여분이 얼마나 되냐"지, 남이 광고하는 90%를 쳐다보는 게 아니다. 높은 숫자를 내세우는 도구는 대개 특정 표본에서만 성립한다.

오해 2: 안 눌리면 도구 탓 — 파일 자체의 바탕을 무시하는 게 잘못

문서와 문서는 생각보다 다르다. 최적화되지 않은 PDF, Office 문서, 스캔본은 부피 속에 엄청난 여분을 숨기고 있다. 같은 회사 로고, 같은 폰트 세트가 수십 페이지에 걸쳐 한 번만 참조하는 게 아니라 반복 임베딩되기도 하고; 많은 스크린샷과 스캔본이 화면에 필요한 해상도를 훨씬 넘겨 저장되기도 하며; 편집 흔적, 불필요한 구조 트리, 숨은 썸네일도 조용히 자리를 잡는다.

이런 여분을 걷어내면 부피를 육할에서 팔할(60~80%)은 거뜬히 줄일 수 있을 때가 많다. 반대로, 이미 압축된 이미지나 이미 묶인 컨테이너는 애초에 여분이 적어 안 눌리는 게 당연하다. 그러니 "안 눌린다"는 건 흔히 파일 바탕이 얇은 것이지, 엔진이 뭉개진 게 아니다. 압축 결과를 보려면, 그 파일에 도대체 얼마나 짜낼 수 있는 물기가 있는지부터 봐야 한다.

오해 3: 온라인과 로컬은 같다 — "데이터가 밖으로 나가는 것"을 사소하게 여기는 게 잘못

압축은 계산 집약적이면서도 극도로 민감한 작업이다. 아직 서명하지 않은 계약서나 고객 정보가 든 보고서를 어느 온라인 압축 사이트에 끌어다 놓는 순간, 파일은 이미 네 기기를 떠나 제3자 서버로 들어간다. IBM의 2025년 데이터 유출 보고서에 쉽게 지나치는 숫자가 하나 있다. 데이터 유출 원인 중 26%가 인적 오류라는 점이다. 외부 공격보다 더 평범하고, 그래서 더 흔하다. 민감한 파일을 출처가 불분명한 온라인 도구에 맡기는 건, 딱 이런 본래 피할 수 있는 인적 노출에 해당한다.

로컬에서 끝내는 게 더 확실한 방식이다. 데이터가 처음부터 끝까지 기기를 떠나지 않으니 프라이버시 걱정은 자연히 사라지고, 로컬 일괄 처리는 네트워크 대역폭이나 동시 처리 제한도 받지 않는다. 컴플라이언스 기준을 지켜야 하는 팀이라면, "처리 과정에서 데이터가 내부 네트워크를 벗어나지 않는다"를 단단한 요구사항으로 두는 게 사후 감사보다 믿을 만하다.

오해 4: 압축하면 도장이 흐릿해진다 — 무손실과 유손실의 경계를 가리지 않는 게 잘못

엔지니어링에서 압축은 두 가지로 나뉜다. 무손실 압축은 풀었을 때 원본과 바이트 단위로 일치함을 보장한다. 문서, 코드, 데이터처럼 "바이트 하나만 틀려도 에러"인 내용은 무손실로 가야 한다. 유손실 압축은 사람의 눈이나 귀가 잘 못 느끼는 디테일을 의도적으로 버려 부피를 확보한다. 이미지, 영상, 오디오는 바로 이 지각 부호화에 기대는데, 인간 시각이 고주파 디테일과 색상(chroma)에 둔감하다는 특성을 이용해 눈에 안 띄는 정보부터 먼저 걷어내는 식이다.

까다로운 건 이거다. PDF나 Office 문서는 본질적으로 "혼혈체"다. 반드시 무손실로 가야 할 텍스트 구조와 벡터 그래픽이 있는가 하면, 유손실로 처리해도 됐을 비트맵, 스크린샷, 스캔 페이지가 잔뜩 임베딩돼 있다. 하나의 파라미터로 억지로 누르면, 지켜야 할 텍스트 구조를 망가뜨리거나, 이미 최적화된 이미지에 헛수고를 하게 된다. 올바른 방법은 나누어 정복하는 것이다. 텍스트와 구조는 무손실 경로로, 임베딩된 이미지 자원은 지각 부호화로 따로 다시 부호화하고, 중복 객체는 중복 제거를 해서 각자 가장 좋은 해법을 찾게 한다.

이것도 왜 아카이빙 현장에서 판형 충실도를 그토록 강조하는지 설명해 준다. 전자 기록의 보존 기준은 압축이 여분만 거두되, 판형이나 검증 가능성을 해쳐서는 안 된다는 데 있다. 압축은 어디까지나 중복에서만 손을 대야 하지, 판형과 검증 가능성은 건드려선 안 되니 그 요구와 모순되지 않는다.

오해 5: 하나의 슬라이더로 다 된다 — 상황의 트레이드오프를 과소평가하는 게 잘못

압축은 결코 "작을수록 좋다"가 아니라, 네 제약 안에서 딱 맞게 누르는 일이다. 세 가지 전형적 상황의 트레이드오프는 완전히 다르다. 아카이빙 상황에선 시간이 병목이 아니니 더 세게 누르고, 장기 저장과 전송 비용 최소화를 추구한다. 메일 첨부 상황에선 보낼 수 있을 만큼 누르는 게 목표이면서, 도장·서명·표는 또렷이 읽혀야 하니 품질 우선이다. 웹과 모바일 상황에선 가벼움이 우선이고, 열리는 속도도 함께 챙긴다.

한 걸음 더 나아간 엔지니어링 가치는 "포맷을 가로지르는 일관된 기준"에 있다. 같은 배치의 파일이 PDF든 이미지든 Office든, 압축하고 나면 비슷한 범위의 부피로 떨어지게 하면, "이번에 압축하면 너무 작아지진 않을까, 너무 커지진 않을까"를 파일마다 추측할 필요가 없어진다.

이 인식을 어떻게 엔지니어링으로 옮겼는지

위 다섯 가지를 땅에 박아두면, 제대로 된 압축 엔지니어링은 최소한 네 가지를 갖춰야 한다.

첫째, 나누어 정복하는 파이프라인. 텍스트 구조는 무손실로, 임베딩 이미지는 지각 부호화로 다시 부호화하고, 중복 객체는 중복 제거해서 각자 최적해를 찾는다. 문서에 임베딩된 이미지와 객체까지 파이프라인에 넣어 통째로 처리할 때, 비로소 전체 이득이 실제로 현금화된다. 겉껍질 컨테이너만 누르는 게 아니다.

둘째, 상황별 분류. 아카이빙·메일·웹 각각 따로 기준을 두고, 포맷을 가로질러 압축 후 부피를 일치시켜 사용자가 파일마다 추측하지 않아도 되게 한다.

셋째, 로컬 우선. 파일은 줄곧 네 기기에 머물고, 일괄 처리도 네트워크나 동시 처리 제한을 안 받는다. 컴플라이언스 기준을 지켜야 하는 팀에겐 "파일이 내부 네트워크 안에 머문다"를 처리 흐름의 단단한 제약으로 두는 게, 사고 터지고 나서 감사하는 것보다 안정적이다. 그래서 하드웨어 네이티브로 빌드돼 번역 계층 하나가 줄어든 압축 파이프라인이 기업에서 더 선호되는 까닭이 여기 있다. 배포가 가볍고, 행동이 더 통제되며, 출력이 더 재현 가능하고, 프라이빗 배포도 더 매끄럽다.

넷째, 규모의 콜드 데이터에 지렛대 의식. Komprise의 고객 조사에 따르면, 기업 NAS에서 60%에서 70%에 이르는 데이터가 90일 넘게 접근되지 않았음에도 여전히 가장 비싼 주 저장소를 차지하고 있다. 이 여분을 짜내면 아껴지는 건 고스란히 스토리지 청구서다.

선택할 때 따져봐야 할 차원

흔히 쓰는 세 가지 유형을 한데 놓고 보면, 차이는 주로 데이터 향방, 포맷 커버리지, 일괄·분류 능력, 그리고 컴플라이언스 통제 가능성에 있다.

네가 다루는 파일이 주로 오피스 문서, 스캔본, 흔한 이미지라면 로컬 압축 도구가 가성비 최고다. 파일이 많아져 자동화된 아카이빙이 필요해지거나, 파일 검색·정리와 연결하고 싶어질 때는 "압축"과 "파일 조직"을 하나의 워크플로로 설계해 볼 수도 있다. 예를 들어 먼저 MagiFiler 로 자료를 정리하고, 다음에 SmartSlim 으로 한꺼번에 슬림화하면, 둘이 따로 처리하는 것보다 훨씬 속 편하다.

자주 묻는 질문

Q: 왜 어떤 PDF는 거의 안 눌릴까?
A: 그 안에 임베딩된 이미지가 이미 최적화돼 엔트로피 한계에 가깝거나, 부피의 대부분이 무손실로 가야 할 텍스트 구조에서 나오는 경우가 많다. 도구가 고장 난 게 아니라 애초에 여분이 적은 것이다.

Q: 압축하면 계약서의 도장·서명이 흐릿해지나?
A: 디테일을 지키는 가벼운 다시 부호화 경로를 타면, 목표는 디테일을 희생하는 게 아니라 여분 부피를 걷어내는 것이다. 스캔본이나 도장이 든 문서는 압축하고 나서 핵심 위치를 열어 확인한 뒤 보관하는 걸 권한다.

Q: 로컬 압축과 온라인 압축, 부피 차이가 크나?
A: 진짜 문서라면 둘 다 꽤 누를 때가 많다. 차이는 주로 "얼마나 누르느냐"가 아니라 "파일이 제3자를 다녀왔느냐"에 있다. 공개된 자료엔 온라인 도구도 무방하지만, 민감 정보가 든 파일은 로컬 처리를 더 권한다.

Q: 모든 포맷을 다 압축할 수 있나?
A: 흔한 오피스·이미지 포맷과 스캔본은 보통 꽤 눕힐 공간이 있고, 이미 고도로 최적화된 포맷은 이득이 제한적이다. 의료 영상, 지리 정보, 라이다 데이터 같은 전문 롱테일 포맷은 대개 타깃 압축 전략이 필요해 범용 파라미터를 그대로 쓸 수 없다.

위几条을 이어보면, 문서 압축의 진짜 모습은 사실 소박하다. 여분이 어디 있는지 먼저 보고, 종류별로 나누어 처리한 뒤, 네 상황 제약 안에서 균형을 잡는 것. "나누어 정복하고, 로컬에서 끝내고, 포맷을 가로질러 일관되게" 하는 도구라면 일상이 가장 속 편하다.

이런 니즈가 마침 네 워크플로에 걸쳐 있다면, 단일 압축률 숫자에 설득되는 대신 이 관점으로 도구를 평가해 보라. 파일 처리와 로컬 우선에 관한 더 많은 엔지니어링 메모는 https://www.uglypear.com/blog/ 에서 볼 수 있다.