UGLYPEAR AI 사업 전환 완료: 고성능 문서 압축 × RAG 데이터 엔지니어링 기반신규 사업 알아보기 →

온프레미스/에어갭 환경의 문서 도구 고르기: 데이터 주권을 위한 다섯 축 점검

Knowledge Worker/Intelligence Foundation 이 2025년에 발표한 보고서가 조금은 뼈아픈 수치를 내놓았다. 지식 관리 프로그램이 없는 기업의 직원은 파일을 찾는 데 주당 평균 8.5시간을 썼다. 반면 그런 프로그램을 도입한 기업은 그 시간이 4.6시간으로 줄었다. 주당 3.9시간 절약은 1,000명 규모 조직이라면 연간 98명분의 정규 인력에 해당한다.

이 생산성 이야기를 데이터 주권이라는 문맥에 놓아보자. 규제 산업이나 공공 기관, 기밀을 다루는 기업에게 문서는 '클라우드에 놔도 되는 것'이 아니다. 그런데 현장 직원은 여전히, 내부망 밖으로 나가선 안 될 파일을 외부 클라우드 전송이나 SaaS로 계속 흘려보내고 있다. 보안 경계 안쪽에 문서 기반을 다시 세우는 일—그것이 찾는 시간을 줄이는 것 이상으로 중요한 과제다.

데이터 주권을 의식해야 하는 건 일부 업계만이 아니다. 의료·법무·금융·방위·공공, 그리고 지역의 핵심 인프라를 담당하는 조직은 민감 데이터를 자사 네트워크 밖으로 내보내는 것 자체가 허용되지 않으며, 계약상 혹은 법집행상의 이유로 외부 전송이 제한된다. 그런 조직에게 문서의 압축·검색·지식화는 '어느 클라우드에 맡길까'가 아니라 '어떻게 내부망에서 끝낼까'가 되는 질문이다. 도구를 도입해도 그 도구가 몰래 클라우드로 데이터를 보낸다면 주권은 지켜지지 않는다. '편리함'과 '보안 경계' 사이에서 사실상 후자를 포기해 온 조직이 적지 않다. 이 글은 그 균형을 되찾을 구체적인 선을 그려본다.

왜 에어갭을 전제로 한 문서 기반이 필요한가

클라우드 퍼스트가 십 년 이어진 결과, 많은 조직은 문서의 '정리·압축·검색·지식화'를 외부 서비스에 맡겨왔다. 하지만 데이터 주권을 중시하는 현장에서는 그 전제가 무너져 있다. 의료·법무·금융·방위·공공 같은 분야에서는 민감 데이터를 자사 내부 네트워크 밖으로 내보내는 것 자체가 허용되지 않는다.

더 골치 아픈 건 '방치 데이터'다. 스토리지 분석 기업 Komprise 의 조사에 따르면, 기업 NAS 데이터의 60〜70%는 90일 넘게 전혀 참조되지 않는다. 그런데도 가장 비싼 1차 스토리지를 계속 점유하고 있다. 에어갭 환경에서 이 문서들을 압축하고, 의미로 검색하고, 자동으로 분류·아카이브할 수 있다면 스토리지 비용과 운영 부하를 동시에 낮출 수 있다.

방치 데이터는 비용 문제만이 아니다. 참조되지 않는 파일일수록 오래된 형식과 모호한 권한을 품기 쉽고, 누가 책임지는지 모른 채 내부망 구석에 쌓인다. 방치해 두면 스토리지 요금보다 무서운 건 사고가 났을 때다. 추적 범위가 눈덩이처럼 불어난다. 보안팀 입장에서는 건드리지 않을 수 없는 데이터를 최소한 '의미로 검색되고 자동 분류되는' 상태로 만들어 두는 것이 방어의 첫 단추다.

구체적으로 생각해 보자. 법무 부서가 십 년치 계약서와 판례를 들고 있는데, 이 모두를 외부 검색 SaaS 에 던지는 건 비밀유지 의무상 불가능하다. 같은 일이 의료의 차트, 금융의 심사 기록, 공공 기관의 공문서에도 해당한다. 그런데 현실은 '일단 공유 폴더에 놔둔다'가 이어지고, 찾는 시간도 유출 위험도 커진다. 문서 기반을 온프레/에어갭으로 갖는 건 이 현장의 모순을 푸는 첫걸음이다. 결국 문서 기반을 어디에 둘지는 '보안 원칙'이 아니라 '운영의 현실'이 답을 정한다.

선정 프레임워크: 다섯 가지 축

에어갭/온프레미스용 문서 도구를 고를 때 어느 축을 보면 좋을까. 아래는 UglyPear Data 가 고객과 함께 짜는 선정 프레임워크다. '서버 불필요' 같은 한 줄짜리 마케팅 문구만 보고 판단하지 말고, 항목마다 점수를 매겨보길 권한다. 축마다 판단 기준을 더 깊이 파고 싶다면 기술 블로그에 선정 사고를 정리해 두었다.

축 볼 것 흔한 함정 적응 포인트
아키텍처 온프레 기기의 CPU/OS를 네이티브로 지원하는가 x86용 버전만 있어 전용기에서 켜자마자 멈춤 대상 환경용 네이티브 버전
배포형태 온프레/에어갭 사설화인가, 상시 통신 필수인가 공공망 SaaS에 강하게 묶여 내부망만으론 동작 안 됨 완전 사설화. 데이터는 내부망 밖으로 나가지 않음
포맷커버 PDF·Office·스캔·이미지·음영상 등 8개 포맷 PDF만 다루고 다른 포맷을 놓침 다포맷을 끝에서 끝까지 처리, 판면 보존
컴플라이언스 민감 정보 비식별화와 감사 추적 비식별화 없어 유출 위험 높음 13개 분류 민감 정보 자동 탐지
성능 대용량 파일 처리량과 동시 처리 단일 처리로 수백 MB에서 멈춤 자체 개발 엔진의 로컬 병렬 처리

이 표에서 핵심은 다섯 축이 독립하지 않는다는 점이다. 예컨대 아키텍처가 네이티브가 아니면 성능도 컴플라이언스도 바닥부터 무너진다. 반대로 배포 형태에 '상시 통신 필수'가 섞여 있기만 해도 에어갭 요건은 채울 수 없다. 한 항목이라도 '조건부'가 붙으면, 그 도구는 온프레 전제 현장에 맞지 않는다고 봐도 좋다.

온프레미스 도입 서비스가 실제로 건네는 다섯 가지

소프트웨어를 '설치했다'는 건 첫걸음일 뿐이다. 진짜 도입은 다섯 가지로 이뤄진다.

환경 검증—대상 서버/단말의 OS와 아키텍처 위에서 기동과 핵심 기능을 끝까지 돌린다.
네이티브 제공—대상 아키텍처에 맞춘 네이티브 버전을 전달해 번역 계층에 기대지 않는다.
포맷 호환 테스트—고객의 실제 과거 문서를 뽑아 압축·변환하고, 판면·문자 인코딩에 어긋남이 없는지 확인한다.
성능 튜닝—내부망 기기의 연산력을 꽉 쓰면서도 화면을 굳히지 않게 조율한다.
컴플라이언스 점검—민감 항목이 들어가기 전 자동으로 비식별화하고, 조작에 흔적을 남긴다.

이 다섯은 단순한 작업 순서가 아니다. 에어갭 현장에서는 '바깥망에 한 번도 닿지 않고 여기까지 돌아가는가'가 도입 성패를 가른다. 그래서 검증도 조율도 고객의 격리된 환경 안에서 끝까지 완결시킨다.

제품이 어떻게 맞는가

압축을 맡는 것이 SmartSlim 이다. PDF·이미지·동영상·오디오·Office·스캔 문서 등 8개 포맷을 끝에서 끝까지 처리하고, 일부 지역에서 의무화되는 OFD 까지 지원한다. 대상 환경용 네이티브 버전을 갖춰 두었기 때문에 전용기나 내부망 단말에서도 그대로 돌아간다. 압축은 기기 안에서 끝나며, 데이터가 외부 서버로 넘어가는 일은 없다. 공식 실측에서 443쪽 문서를 처음부터 끝까지 압축하는 데 124초. 이미지를 압축해 대형 언어 모델에 넣으면 토큰 비용을 85.9% 줄일 수 있다(GPT-4o 검증). 에어갭 환경에서는 로컬로 끝내는 이 설계가 특히 힘을 발휘한다. 연산을 아끼면서 그물망 밖으로는 아무것도 내보내지 않는다. 자세한 사항은 SmartSlim 제품 페이지를 참고하길 바란다.

제품의 흐름도 놓치지 말자. SmartSlim 의 PDF 압축은 예전에는 외부 도구에 기대야 했던 부분이 있었다. 최근 업데이트에서 이 부분을 자체 개발 압축 엔진만으로 끝내는 구조로 바꿨다. 사용자 입장에서 이득은 분명하다. 들여와야 할 구성이 줄고, 환경 검증과 포맷 확인에 걸리는 공정이 짧아진다. 격리된 환경일수록 구성이 하나 줄어드는 것만으로 손이 확실히 덜 간다.

문서를 '정리된다' 쪽은 MagiFiler 가 맡는다. 내부망에 파일이 흩어지고 안 보이는 건 옛날부터의 버릇이다. MagiFiler 면 대화형 자연어로 파일을 조작하고, 내용 의미로 검색하고, 자동으로 분류·태그·보관할 수 있다. macOS·Windows·Linux 를 지원하며 기기 3대까지 묶을 수 있다. 일시불 매입형 과금에 라이선스 키는 즉시 발행된다. SmartSlim 이 '작게 압축'을, MagiFiler 가 '찾아진다'를 지탱한다. 둘은 서로 보완하는 능력이다. 자세한 내용은 MagiFiler 제품 페이지에서 확인할 수 있다.

RAG 데이터 엔지니어링 기반은 '대형 언어 모델에 먹인다'를 푼다. 지식 베이스를 에어갭 환경에서 진짜 쓸모 있게 쓰려면 흩어진 문서를 모델이 먹을 구조 데이터로 바꾸는 작업이 본질적 난관이다. 당사 RAG 기반은 여섯 공정과 여덟 능력을 갖추고, 사설화 배포로 데이터를 내부망 밖에 내보내지 않으며, 내장된 13개 분류 AI 민감 정보를 자동 비식별화한다. 여기서 피해 갈 수 없는 게 보안 맥락이다. IBM 의 'Cost of a Data Breach Report 2025'에 따르면 5곳 중 1곳 기업이 직원의 비승인 AI 도구 사용(섀도우 AI)을 계기로 데이터 유출을 겪었다. 그런 기업의 평균 유출 비용은 동종 기업보다 67만 달러나 높았고, 유출을 당한 조직의 63%는 AI 거버넌스 정책조차 없었다. RAG 를 완전 사설화 환경에서 돌리는 건 섀도우 AI라는 유출 경로를 막는 일과 같다. 기반의 전체 모습은 RAG 데이터 엔지니어링 기반 페이지에서 볼 수 있다.

에어갭 문서 방안을 평가 중이라면 제품 목록에서 각 도구의 요건을 대조해 보길 권한다.

이런 현장에 맞는다

모든 조직에 두루 해당하는 건 아니다. 다음 가운데 어느 하나라도 해당하면 온프레/에어갭 문서 기반은 검토할 가치가 있다. 계약이나 기록을 외부 SaaS 에 맡길 수 없는 법무·의료·금융 부서—여기선 '검색은 되는데 밖으로는 안 나간다'가 기본선이다. 규제나 감사로 데이터 반출이 금지된 공공 기관—내부망만으로 압축·검색·지식화가 끝나야 감사 대응이 성립한다. 그리고 방대한 과거 문서를 안고 있으면서 비싼 1차 스토리지를 짓누르는 정보 시스템 부서—방치 데이터를 압축·아카이브하면 용량과 비용이 함께 내려간다. 공통점은 '클라우드에 맡길 수 없다'는 것이다.

세 제품은 각자 역할을 나누면서도 하나의 흐름으로 이어진다. SmartSlim 이 부피를 줄이고, MagiFiler 가 정리하고, RAG 기반이 지식으로 바꾼다. 모두 내부망 안에서 끝나므로 경계를 넘는 데이터는 생기지 않는다. 작게 시작해 세 지표로 효과를 재면, 다음 부서로 넓힐 근거가 생긴다. 이 흐름은 기존 보안 정책과도 부딪히지 않는다.

도입을 시작하는 시점

에어갭화는 시스템을 갈아치우는 것만으로 끝나지 않는다. 문서라는 선도 함께 넘어야 한다. 작은 범위의 파일럿을 권한다. 어느 한 부서의 문서 관리나 스토리지 최적화 현장을 하나 골라 SmartSlim·MagiFiler·RAG 기반을 내부망 위에서 돌려보자. 주목할 건 압축률, 파일 검색 소요 시간, 지식 베이스 구축 주기라는 세 지표다. 시험 이용 입구는 SmartSlim 제품 페이지에, 도구 비교는 제품 목록에, 더 깊은 기술 해설과 선정 사고는 기술 블로그에 있다.

자주 묻는 질문

Q: 에어갭 환경에선 전용 하드웨어가 필수인가.
A: 꼭 그렇진 않다. 중요한 건 애플리케이션 계층이 그 환경에서 네이티브로 돌고 데이터가 그물망 밖으로 나가지 않는 것. 기존 사내 서버나 단말 위에 사설화해 올리면 충분한 경우가 많다. 까다로운 포맷 호환이 필요하면 도입 단계에서 함께 검증한다. 초기에는 한 대의 워크스테이션으로 개념 증명을 해보길 권한다.

Q: 기존 클라우드 문서 도구를 그대로 옮길 수 있나.
A: 대부분 안 된다. 클라우드 전제 도구는 상시 통신을 전제로 해 내부망만으론 안 돌아간다. 정답은 온프레/에어갭을 네이티브로 받치고 다포맷을 덮는 도구를 고르는 것. 호환 계층을 덧씌워 때우는 건 운영 중 언제 무너질지 모르는 부채를 지는 셈이다. 전자 인장이나 서명이 든 문서라면 잘못 건드렸다가 복구 불가 사고로 이어지기도 한다.

Q: 사설화 배포와 SaaS, 어떻게 나눠 쓰나.
A: 내부 문서·계약·재무 데이터를 다루면 완전 사설화를 우선하길 권한다. 데이터는 내부망 밖으로 내보내지 않는다. 대외 전시용 가벼운 용도만 SaaS 대상이다. 경계를 어디에 그을지는 데이터의 민감도가 정하며, 그 기준을 문서로 남겨두면 감사 대응도 수월해진다.

Q: RAG 기반은 에어갭 위에서 실제로 돌아가나.
A: 돈다. 대상 환경용 네이티브 버전으로 조율해 지식 엔지니어링 여섯 공정을 로컬에서 마친다. 민감 정보 비식별화는 들어가기 전 자동 실행되고 외부 연산 자원에 기대지 않는다. 모델을 바깥으로 내보낼 필요도, 추론을 밖에 맡길 필요도 없다.

Q: 도입 서비스에 옛 문서 이동도 포함되나.
A: 포맷 호환 테스트 틀에 포함된다. 과거 문서의 판면·문자 인코딩을 뽑아 검증한다. 다만 전체 소장 이동 공수는 실제 데이터량별로 별도 견적이며 표준 도입 패키지엔 들지 않는다. 범위는 파일럿 단계에서 함께 정한다.