큰 문서, AI가 감당 못 해? 로컬 압축의 MCP 접근법

법무팀의 아침은 늘 비슷한 장면으로 시작된다. 누군가 수백 페이지 입찰 문서를 채팅 창에 집어넣고 "핵심 조항 뽑아줘"라고 부탁한다. AI는 답 대신 처리 한도를 이유로 그대로 중간에서 잘라버린다. 사람은 한숨을 쉬고, 파일을 손으로 쪼개 다시 붙인다. "너무 커서 AI가 못 돌린다"는 이 벽은 모든 직장에 조용히 있다.

재정부 등 아홉 부처가 지난해 5월에 낸 통지(财会〔2025〕9호)를 기억하는가. 각 기관의 회계 소프트웨어가 2027년 12월 31일까지 전자증빙 회계 데이터 표준에 맞춰 고칠 것을 요구한 것이다. 재무 얘리로 들릴 수도 있다. 하지만 깊이 보면, 기업의 문서 처리가 다시 포맷되고 있다는 또 다른 변화와 같은 방향을 가리킨다. AI 도구 대부분은 그 변화를 아직 따라잡지 못했다.

병목은 모델이 똑똑한지가 아니다. "너무 큰 걸 감당 못 한다"는 데 있다. 수백 페이지 계약서, 산더미 스캔 자료, 프로젝트 전체의 설계안을 그대로 큰 모델에 던지면, 컨텍스트 한도를 넘겨 잘리거나 토큰 비용이 보내기 버튼을 누를 기운을 앗아간다. IDC는 벌써 계산해 둔 바 있다. 문서 관련 문제가 기업 생산성 손실의 21.3%를 차지하고, 정보 근로자 1인당 연간 약 19,732달러의 손실에 해당한다고. 파일이 너무 크고, 너무 잘게, 너무 엉망인 것은 AI를 실제 업무 흐름에 박아넣을 때 보이지 않는 벽이 되고 있다.

UglyPear 데이터의 주축은 고성능 문서 압축과 RAG 데이터 엔지니어링 기반이다. 모두 완전 프라이빗 배포로, 데이터는 사내망을 벗어나지 않음. 이 선을 따라 우리가 만든 것이 compress-mcp라는 구조다. 한 마디로 "말 한마디로 줄어드는" 압축 서비스다. 이건 또 하나의 독립 소프트가 아니다. MCP 서비스이며, WorkBuddy나 천문(千问), 백련(百炼) 같은 AI 도구에 꽂히고, 에이전트가 한 마디 자연어로 파일을 줄이게 한다.

MCP를 사람말로 풀자. MCP는 Model Context Protocol의 줄임으로, AI 도구에 외부 능력을 잇는 열린 규약이다. 예전엔 각 에이전트가 외부 기능을 부르려 할 때마다 바퀴를 다시 만들고 연결 코드를 처음부터 써야 했다. MCP가 있으면 능력 쪽이 그 능력을 '서비스'로 싸고, 에이전트는 자기 기능 부르듯 그것을 부른다. 압축 같은 동작은 이 방식에 본래 잘 맞는다. 안정적이고 재사용 가능하며, 매번 사람이 손으로 돌릴 것이 아니기 때문이다.

그럼 왜 화면에 버튼 하나 더 얹지 않고 MCP로 했을까. 진짜 병목은 "압축 도구가 있느냐"가 아니라 "AI가 그것을 돌릴 수 있느냐"에 있다. 큰 파일을 AI에 맡기려면 대화를 잠깐 나와 수동으로 압축 돌리고 다시 붙여야 했다. 흐름이 끊기면 사람은 쓸 의지를 잃는다. compress-mcp는 stdio와 HTTP 이중 채널을 타고, 6+1개 내장 도구를 갖추며, 그 위에 계량과 라이선스 구조를 갖춘다. 개발자에게 이는 각 AI 플랫폼마다 연결을 다시 쓸 필요가 없음을 뜻한다. 에이전트가 "이 계약서 메일 보낼 만하게 줄여줘"라면 압축은 로컬에서 조용히 끝난다. 기업에게 내장 계량은 압축이 몇 번 돌고 얼마나 용량을 뺐는지 보여주고, 라이선스 기구는 인증을 바깥에서 받아내니 따로 짤 필요가 없다.

또 다른 배경은 데이터 그 자체가 불어나고 있다는 점이다. IDC의 중국 전망에 따르면 국내는 비정형 데이터 증가가 빠른 시장 중 하나로, 향후 5년간 51 ZB에서 129 ZB로 늘고 연 30~40% 성장한다. 파일은 앞으로도 계속 커질 일만 남았다. 압축은 '옵션'에서 AI 워크플로의 기반 인프라로 옮겨가고 있다. 그리고 그것은 먼저 올려받고 나서 처리하는 게 아니라 로컬에서 일어나는 게 바람직하다.

AI가 큰 파일을 만지게 하는 몇 가지 길을 비교해 보자. 차이는 의외로 구체적이다.

이 표는 우열을 가르려는 게 아니다. 판단을 돕는다. 파일이 백 메가를 가볍게 넘고 계약서나 차트 같은 민감 정보를 담는다면, 로컬에 두고 한 마디로 부를 수 있는 방식이 제격이다. 가끔 그림 하나 압축하는 정도라면 클라우드 SaaS도 충분하다. 알맞게 쓰면 그만이다.

구체적인 예를 들자. 법무가 443페이지 OFD 입찰 문서를 대화에 던지고 AI에 주요 조항 추출을 맡긴다 치자. 원파일이 커서 그대로 주면 분명 타임아웃 날 것이다. 에이전트에게 "먼저 압축하고 읽어"라 하면 compress-mcp가 로컬에서 처리해 마치고, 공식 실측으로 끝까지 124초다. 더 실감 나는 건 이미지다. GPT-4o 기준으로 먼저 압축해 모델에 넘기면 이미지 관련 토큰 비용을 85.9% 줄일 수 있다. 매일 문서와 부대끼는 팀에게 이 비용은 쌓이는 성질의 것이다.

지식 팀 상황도 상상해 보라. 서고엔 십 년치 넘는 스캔 자료가 쌓여 있고, RAG에 넣어 질의응답하고 싶다. 원파일은 크고 흐려서 그대로 들어가면 저장도 잡아먹고 검색도 느려진다. 에이전트에게 입고 전 "한꺼번에 압축해"라 하면 compress-mcp가 본기에서 그 산을 정리하고, 이어 RAG 데이터 엔지니어링 기반의 여섯 공정으로 잇는다. 압축이 먼저, 검색이 나중, 둘 다 내망에서 돌아간다. 민감 자료는 처음부터 끝까지 장치를 떠나지 않는다.

모든 상황에 MCP를 끌어들이는 게 값어치 있는 건 아니다. 가끔 그림 두 장 압축해 메신저에 보내는 정도라면 폰의 소도구면 족하다. 굳이 서비스 하나 꿸 이유가 없다. compress-mcp가 진짜 이득인 건 "파일이 크고, 빈도가 높고, 비밀 유지 관문을 거치는" 국면이다. 매일 지식고에 들어오는 스캔 자료, 계약 심사 라인의 전처리, 고객 지원 지식고 입고 전 다이어트 같은 것들. 압축을 에이전트가 언제든 부를 수 있는 능력으로 두면 절약되는 건 두 가지다. 사람이 도구 사이를 왕복하는 그 미세한 인내, 그리고 파일이 사내망을 나가는 그 미세한 위험. 이건 SmartSlim이나 Maggie File을 대체하는 게 아니다. 둘의 밑바탕 능력을 AI 워크플로에 한 가닥 선으로 잇는 것이다. "압축"을 한 번의 수동 조작에서 에이전트 스스로 하는 일로 바꾼다. 개발자에게는 끈적한 코드 더미를 안 써도 됨을 뜻하기도 한다. 플랫폼마다 업로드, 폴링, 콜백을 다시 쓸 필요 없이 MCP가 그 주고받음을 표준화한다.

잘리는 잊기 쉬운 게 프라이버시다. UglyPear 데이터 제품은 일관되게 본기에서 돌고, 파일은 장치를 떠나지 않으며, 13종 AI 민감 정보 탐지조차 로컬에서 끝낸다. compress-mcp도 마찬가지다. 그저 "압축"을 에이전트가 부를 수 있는 능력으로 바꿀 뿐, 파일은 처음부터 끝까지 사내망을 나가지 않는다. 로펌, 클리닉, 재무처럼 비밀 유지를 바닥선으로 삼는 기관엔 "빨리 압축한다" 이상으로 무겁다.

압축, 정리, 검색은 같은 생각의 다른 출구다. SmartSlim은 파일을 "작게" 만드는 제품선이고, Maggie File은 파일을 "정돈"하는 걸 맡는다. compress-mcp는 압축 능력을 떼어 AI 도구가 직접 부를 수 있는 부품으로 만든다. 셋 다 로컬에서 돈다. 더 위로는 RAG 데이터 엔지니어링 기반이 여섯 공정과 여덟 능력으로 흩어진 파일을 답할 수 있는 지식으로 바꾼다. 이것도 완전 프라이빗, 데이터는 사내망을 벗어나지 않음. compress-mcp와 이 기반은 이어 보인다. 앞은 "크다"를 "작다"로, 뒤는 "작다"를 살려 쓴다.

고르는 법은 복잡하지 않다. 오래 높은 빈도로, 계속 갱신하고 싶으면 구독형(SmartSlim은 월 20.4위안부터)을. 한 번 사서 끊고, 여러 기기 자기 용도로, 자료는 내 것이어서 매달 이을 필요 없으면 매입형(Maggie File, 기기 3대 묶음 지원, 키는 사자마자 발행)을. 압축 능력을 자사 AI 시스템에 박고 싶은 개발자에겐 "말 한마디로 줄어드는" MCP 서비스인 compress-mcp가 이 상황을 위해 있다. 셋은 대체 관계가 아니라, 당신이 어느 층에 서느냐로 고르는 것이다. 손안의 AI 비서를 큰 파일에 더 잘 대응시키고 싶기만 하다면 compress-mcp가 바꿈이 가장 작고 가장 먼저 시험하기 쉬운 한 걸음이다. 문서가 진짜로 많아져 관리나 질문이 필요해지면 그 위에 Maggie File과 RAG 기반을 잇기만 하면 늦지 않는다.

결국 compress-mcp가 푸는 건 작지만 성가신 문제다. 파일이 너무 커서 AI가 못 돌린다. 그것은 뭘 대체할 마음 없이, 다만 "줄인다"를 에이전트가 입만 열면 할 수 있는 일로 만들고, 게다가 모두 당신 기계 위에서 행한다.

지금 바로 사용해 보기

문서가 커서 AI가 감당 못 하면, 당장 수많은 설정을 외울 필요는 없다. compress-mcp는 WorkBuddy, 천문, 백련 같은 AI 도구 연결을 상정하고, 본기에서 돌며 데이터는 사내망을 벗어나지 않음. 제품 페이지는 여기. 원리와 실전의 자세함은 UglyPear 데이터 기술 블로그가 계속 새로고침하고 있다. 먼저 제품 목록을 훑어보길 권한다.

자주 묻는 질문

Q: compress-mcp는 반드시 인터넷 연결이 필요한가요?
A: 필요 없습니다. 본기에서 돌고 파일은 장치를 떠나지 않으며 압축은 모두 로컬에서 끝나, 프라이버시 요구가 높은 자료에 맞습니다.

Q: SmartSlim과 무슨 관계인가요?
A: SmartSlim은 압축 제품선입니다. compress-mcp는 그 압축 능력을 MCP 서비스로 싸서 AI 도구가 직접 부르게 합니다. 밑바탕 엔진은 동일하고, 드러내는 방식만 다릅니다.

Q: 연결이 번거롭나요, 코드 많이 쓰나요?
A: 쓸 필요 없습니다. stdio와 HTTP 이중 채널을 타고 6+1개 내장 도구를 갖추어 AI 에이전트가 자연어로 부르니 개발자는 플랫폼별 개별 대응이 불필요합니다.

Q: 데이터가 사내망을 나가나요?
A: 나가지 않습니다. compress-mcp는 본기 처리로 파일이 장치를 떠나지 않고 13종 AI 민감 정보 탐지도 로컬에서 끝납니다.

Q: 어떤 파일 형식을 지원하나요?
A: PDF, 이미지, 동영상, 오디오, Office, OFD, 스캔 자료 등 8종 형식을 포괄하며 압축은 모두 본기에서 끝납니다.