AI 비서가 파일을 압축하지 못하는 이유와 실무자가 그 틈을 메우는 법

작은 테스트를 하나 해보자. 매일 쓰는 그 AI 비서를 켜고, 바탕화면에 있는 1.2GB짜리 프로젝트 폴더를 "이메일로 보낼 수 있을 만큼만 줄여줘"라고 시켜보라. 아마 대부분은 해내지 못할 것이다. 비서가 멍청해서가 아니다. 설계상 하나의 능력을 빠뜨리고 태어났다. 글자는 읽어내면서도, 이진 파일 그 자체의 무게는 건드리지 못한다. 이 틈이 바로 압축이 들어가야 할 자리다.

데이터의 규모부터 짚어보자. IDC는 전 세계 데이터 총량이 2024년에 약 149ZB에서 180ZB 사이였고, 2028년이면 394ZB까지 치솟을 것으로 추정한다. 그중 80~90%는 비정형 파일, 즉 문서·이미지·오디오·영상이다. 이건 개인 하드와 팀 공유 폴더 곳곳에 흩어져 있다. 양은 불어나는데, 사람이 다루는 방식은 별로 안 변했다. IDC의 또 다른 조사에 따르면 지식 노동자는 하루 평균 약 2.5시간을 업무에 필요한 정보를 찾는 데 쓴다. 근무 시간의 30%가량이다. 파일은 계속 쌓이고 찾기는 점점 느려지는데, 이건 AI 비서가 가장 잘 도와줘야 할 상황이다. 그런데 막상 "줄여줘"라는 한 단계를 진짜로 넘기려 하면, 대다수 AI 도구는 멈춰버린다.

사람과 데이터의 관계가 얼마나 엉망인지 보여주는 조사도 있다. Compass Datacenters가 실시한 설문에서 응답자의 77%는 필요한 것보다 더 많은 데이터를 쌓아둔다고 털어놓았다. 95%는 파일을 지운 적이 있지만, 그 방법을 제대로 안다고 자신하는 이는 10%뿐이었다. 더 흥미로운 건 태도다. 59%는 디지털 파일을 정리하는 일보다 설거지를 하는 편을 택했고, 42%는 나중에 쓸 일이 생길까 봐 지우기를 두려워했다. 정리도 못 하고 버리지도 못 하니, 저장소는 부풀어 오르고 비서는 그 안을 헤매기만 한다. 이쯤 되면 압축은 단순한 용량 절약이 아니라, 데이터와의 관계를 통제하는 가장 작은 시작점이 된다. 그런데 아이러니하게도, 이렇게 쌓인 파일 더미를 정리할 도구로 사람들은 다시 AI 비서를 찾는다. 비서가 파일 크기 자체는 못 건드리니, 결국 그 틈은 그대로 남는다.

왜 멈출까. 결국 AI 비서는 토큰을 다루고, 의미를 이해하고, 대신 글을 쓰고 고치는 데 능하다. 압축이 하는 일은 파일 그 자체를 건드린다. 즉 의미를 잃지 않고 중복 정보를 짜내는 일이다. 이건 서로 다른 두 가지 작업이다. "AI가 다 할 수 있는데 압축 정도야"라고 생각하는 팀이 많다. 결과는 보통 두 가지다. 나온 파일이 그대로 크기만 하거나, 아예 깨져버리거나. 겉보기엔 도구가 무능해 보인다. 아니, 좀 더 들여다보면 진짜 빠진 건 어떤 버튼이 아니라, '압축 능력'과 'AI 워크플로' 사이를 잇는 설계다. 그래서 compress-mcp 압축 서비스 같은 존재가 필요하다. 압축을 비서가 수시로 부를 수 있는 하나의 동작으로 만드는 것 말이다.

그런데 이걸 제대로 하려면, 일을 아는 사람과 버튼만 누르는 사람은 생각이 완전히 다르다.

가장 먼저, 많은 이가 의식조차 못 하는 전제가 있다. 제대로 하는 엔지니어는 '압축 연동' 코드를 한 줄 쓰기 전에, 요청자가 절대 요구하지 않을 한 가지를 먼저 한다. 바로 레이블이 붙은 평가 세트를 만드는 일이다. 어중간하게 파일 몇 개 대충 돌려보는 게 아니다. 압축 후 무엇이 성공인지 명확히 정의한다. 부피는 얼마나 줄었는지, 도장과 도표는 살아있는지, 열었을 때 정상적으로 보이는지를 말이다. 이 자가 없으면 그 뒤의 모든 "잘 되네"는 빈말이다. 땅에 줄 긋고 시작하는 것과 같다. 다만 대부분이 그 긋기를 귀찮아할 뿐이다.

그다음은 가장 원초적인 층위로 내려가 보자. 파일이 왜 클까. 안에 중복이 잔뜩 들어있기 때문이다. 반복되는 바이트, 쓰이지도 않는 메타데이터, 사람 눈이 가려지지도 못할 해상도의 픽셀들. 압축의 본질은 "파일을 작게 만든다"는 현상 자체가 아니다. "의미를 최대한 보존하면서 중복을 빼는 것"이다. 이 가장 밑바닥의 진리를 받아들이면 선택이 명확해진다. 따져봐야 할 건 "광고가 얼마나 줄인다고 하느냐"가 아니라, "무슨 기준으로 중복을 빼는지, 뺀 뒤 복원이 되는지, 네가 중요한 포맷을 잘 다루는지"다. 입을 열자마자 10분의 1로 줄여준다고 약속하는 쪽은 오히려 경계해야 한다. 좋은 평가 세트는 이 밑바닥 원리를 구체적인 포맷으로 옮긴다. 계약서의 전자 서명이 깨지지 않는지, 스캔한 양식의 텍스트 레이어가 남는지, 설계 도면의 치수가 어긋나지 않는지까지 항목으로 적어둔다. 그래야 "의미 보존"이 추상 명세가 아니라 검사표가 된다.

업계에는 함께 알아두면 좋은 몇 가지 일반적인 방법이 있다. 그중 하나는 압축을 '도구 호출'로 만드는 것이다. AI 비서가 표준 프로토콜을 통해 외부 능력을 부르게 하고, 압축 로직을 모델 안에 억지로 밀어 넣지 않는 방식이다. MCP, 즉 Model Context Protocol은 이 흐름에서 널리 거론되는 표준 중 하나다. 압축을 모델이 억지로 하는 겸업이 아니라, 비서가 언제든 부를 수 있는 동작으로 만든다. 또 하나는 로컬 우선이다. 파일이 내 기기나 내부망을 떠나지 않고, 압축은 본 기기에서 끝난다. 민감한 내용이 경계 밖으로 나가지 않는다. 거기에 토큰 비용을 장부에 올리는 방법도 있다. 파일을 먼저 날씬하게 만든 뒤 검색과 모델에 넣으면, RAG로 들어가는 토큰 수가 직접 줄어든다. 아끼는 건 토큰 값만이 아니다. 색인되는 덩어리가 작아지면 검색 지연도 줄고, 질의와 더 밀접한 조각만 올라가니 검색 품질 자체도 좋아진다. 이 단계에서 아끼는 돈은 진짜 돈이다.

그렇다면 무엇이 '제대로 연결했다'를 독립적으로 증명할까. 업체가 자기가 빠르다고 하는 말도 아니고, 데모 영상에서 골라낸 그 하나의 파일도 아니다. 믿을 수 있는 건 진짜 사용 속에서 나오는 신호다. 압축한 파일을 사람이 계속 쓰는지, 오류율이 낮은지, 같은 배치를 반복해 압축해도 결과가 안정적인지. 더 딱딱하게는, 재현 가능한 대조 실험이다. 같은 표본을 두고 압축 켜고 끄고에서 부피와 사용 가능성이 얼마나 다른지, 숫자를 놓고 본다. 회귀 테스트 모음을 들여다보면 구체적인 검사 항목이 보인다. 같은 파일을 몇 번 압축해도 허용 오차 안에서 같은 바이트 크기로 떨어지는지, 도입한 새 버전이 어제까지 잘 나오던 포맷을 깨뜨리지 않는지, CI가 매 커밋마다 지켜본다. 블라인드 테스트와 이런 회귀 모음은 어떤 미사여구보다 쓸모 있다.

시선을 다시 우리가 할 수 있는 일로 가져오자. compress-mcp가 네 AI 워크플로에 어떻게 붙는지 궁금하다면, 그것이 메우려는 건 바로 위의 그 틈이다. 네가 쓰던 주류 AI 비서에 말 한마디로 압축을 부르게 하고, "이거 좀 줄여줘"를 비서가 알아듣고 해낼 수 있는 동작으로 바꾼다. 이미 쓰는 AI 비서에 꽂히고, "이거 압축해"라고 하면 본 기기에서 일을 끝낸다. 내내 파일은 네 환경을 떠나지 않고, 데이터는 내부망 안에 머문다. 법무·의료·금융처럼 민감 파일을 건드릴 수 없는 팀에게 이 점은 특히 핵심적이다. 압축이 로컬에서 일어나니, 공유하기 전에 이미 날씬해져 있고 외부로 나갈 때 리스크가 한 층 옅어진다. 예를 들어 변호사가 증거 자료 묶음을 상대방에게 보내기 전, 비서에게 "이 폴더 50MB 이하로 줄여서"라고 하면, 파일은 사무실 네트워크 안에서만 처리되고 외부 전송 직전에만 크기가 잡힌다. 이 과정에서 어느 단계도 클라우드를 거치지 않는다.

그 배경의 압축 엔진은 최근 몇 년 사이 계속 가벼워져 왔다. 처음엔 이런 능력도 외부 의존성을 한가득 달고 나와 배포가 묵직했는데, 뒤엔 그 의존성을 걷어내고 더 깔끔한 단일 파일 형태로 바뀌었다. 다른 시스템에 심을 때 실행 환경을 짓누르지 않고, 사설 배포도 매끄럽다. 규제를 받는 산업일수록 외부 의존성을 줄이는 건 곧 심사 통과와 직결된다. 별도 런타임 없이 단일 파일로 돌아가면 보안 검증 범위도 좁아지고 감사도 쉬워진다. AI 워크플로를 도는 사람 입장에서 이건 압축 한 단계가 거의 무부하라는 뜻이다. 추가 인프라를 거의 안 먹고, 파일 하나 줄이려고 새 플랫폼을 짤 필요도 없다.

자연스럽게 한 가지 질문이 따라온다. 다 같은 '압축 능력'인데, 나는 도대체 어떤 형태를 써야 할까. 아래 표는 흔한 연동 방식 몇 가지를 나란히 놓은 것이다. 결론을 대신 내리는 게 아니라, 분명히 봐야 할 차원을 주려는 의도다.

표의 차원은 일관된다. 누가 쓰는지, 어떻게 쓰는지, 데이터가 어디에 머무는지, 대표 상황이 무엇인지. "가장 좋은" 건 없다. 네 실제 흐름에 달라붙는 것만 있을 뿐이다.

처음 그 테스트로 돌아가 보자. AI 비서가 파일을 압축 못 하는 건 멍청해서가 아니다. 압축은 본래 독립적이고 호출 가능하며 로컬 우선인 능력이어야 하고, 모델에 맡긴 겸업이 되어선 안 된다는 뜻이다. 일을 아는 이의 움직임은, 무엇을 압축할지·무슨 기준으로 압축할지·압축 후 어떻게 검증할지부터 생각한 뒤에야 워크플로에 붙이는 것이다. "AI"라는 글자만 보면 만사가 해결된 줄 아는 태도와는 거리가 멀다.

네 팀이 이미 AI 비서로 문서를 다루면서도, 보내기 힘든 큰 파일 때문에 울상 짓는 공유 드라이브에 시달린다면, "비서가 말 한마디로 파일을 줄일 수 있을까"라는 가장 작은 동작부터 시도해 보라. 이 한 틈만 먼저 메우면, 그 뒤의 검색·정리·모델 투입이 비로소 매끄럽게 돌아간다.

FAQ

Q: compress-mcp는 일반 압축 소프트웨어와 무엇이 다른가?
A: 일반 압축 소프트웨어는 너가 직접 켜고 파일을 골라야 한다. compress-mcp는 네가 쓰던 AI 비서가 말 한마디로 부르게 하고, 본 기기에서 돌아가서 AI 워크플로에 붙는다. 둘은 대체 관계가 아니라 '수동'과 'AI가 스케줄하는'의 차이다.

Q: 압축이 로컬에서 돌면 민감한 내용이 밖으로 나가나?
A: 아니다. 압축은 온전히 네 기기 혹은 내부망 안에서 끝나고, 파일은 네 환경을 떠나지 않으며 데이터는 도메인 안에 머문다. 법무·의료·금융 같은 민감한 상황일수록 이 점이 중요하다.

Q: AI가 부르는 압축이 파일을 망가뜨리진 않나?
A: 압축이 믿을 만한지 가르는 건 명확한 인수 기준이다. 부피는 얼마나 줄었는지, 도장과 도표가 살았는지, 열리는지. 이걸 고르기 전에 먼저 물어봐라. 마케팅 슬로건보다 훨씬 낫다.

Q: 우리 팀은 RAG를 쓰는데 압축과 검색의 관계는?
A: 파일을 먼저 날씬하게 만든 뒤 검색과 모델에 넣으면, RAG로 들어가는 토큰은 줄고 검색은 더 집중된다. 압축은 검색 품질의 전처리 단계이지, 딴 일이 아니다.

Q: AI 비서에 연결한다고 해서 파일을 클라우드에 올려야 하나?
A: 아니다. 로컬 우선 방식으로, 압축은 네 환경 안에서 끝난다. 네가 능동적으로 보내는 파일만 나가고, 그땐 이미 한 번 날씬해진 뒤다.

지금 바로 써보기

AI 비서가 말 한마디로 파일을 줄이게 만들고 싶은가? compress-mcp 압축 서비스가 네 워크플로에 어떻게 붙는지 확인하고, 더 많은 실무 이야기는 UglyPear Data 기술 블로그에서 보라. 제품 라인업은 여기에서 한눈에 볼 수 있다.