안전한 공공기관 지식베이스 구축: 프라이빗 RAG와 문서 압축

시청 민원 창구 앞에 서 있는 한 시민을 떠올려 보자. 그는 지난달 받은 안내문을 들고 왔는데, 창구 공무원이 화면에서 꺼낸 근거 문서는 딱 보기에도 세 해 전 버전이다. 둘은 서로 다른 문서를 두고 대화하고 있는 셈이다. 이 장면은 누군가의 실수가 아니다. 수많은 공공기관이 겪는, 그리고 좀체 드러나지 않는 구조적 문제다.

많은 기관이 종이 문서를 스캔해 공유 폴더에 올리기만 하면 "지식베이스"가 생겼다고 믿는다. 솔직히 말해 이는 지식베이스에 대한 가장 큰 오해다. 공공 부문의 진짜 난관은 "안 남는다"가 아니라 "관리도 못 하고, 쓰기도 어렵다"에 있다. 파일은 쌓일수록 많아지는데, 당장 꺼내 쓰면서도 믿고 의사결정에 쓸 수 있는 비중은 점점 줄어든다. 차라리 이런 시스템을 "파일 캐비닛"이라 부르는 편이 지식베이스라 부르는 것보다 정직할 것이다.

불안해질 만한 숫자 하나부터 보자. 전 세계에서 유통 중인 PDF만 이미 3조(3 trillion) 부를 넘겼다. 그리고 어느 한 주요 협업 플랫폼만 놓고 보아도 하루 신규 업로드 파일이 20억 개를 웃돈다. 공공 시스템은 그보다 훨씬 무겁다. 공문, 회의록, 심사卷宗, 도면, 음성·영상까지. 형식은 뒤섞이고 버전은 끝없이 늘어나며 보존 기간은 십 년 단위로 깊게 뻗는다. 양은 불어났는데, 찾을 수 있는 속도는 그를 따라가지 못했다.

M-Files가 Vanson Bourne에 의뢰해 전 세계를 대상으로 진행한 조사가 그 고통을 정확히 짚는다. 응답자의 96%가 "문서의 최신 버전을 찾기 어렵다"고 답했고, 83%는 "이미 있는 문서를 찾지 못해 그냥 새로 만들었다"고 했다. 이걸 공공의 문맥에 놓으면 상황이 무거워진다. 한 가지 정책 해석이 부서별로 조금씩 다르게 저장되어 있고, 그중 어느 것이 "현재 유효한 것"인지 아무도 확신하지 못한다. 시민이 창구에 나타났을 때 공무원이 꺼내든 근거가 삼 년 전 낡은 문서일 수 있다는 뜻이다. 이렇게 조용히 무질서로 흘러가는 비용은, 그 어떤 저장 용량 부족보다 크다.

흥미로운 건, 해법이 "하드디스크를 더 사는 것"에 있지 않다는 점이다.

UglyPear Data는 "압축 × RAG 데이터 엔지니어링 기반"을 한 기관의 자체 인프라에서만 돌아가는 형태로 묶어 배포 가능하게 만들었고, 최근 전체 파이프라인의 엔드투엔드 검증까지 마쳤다. 그중 공공 부문 팀이 가장 주목할 만한 지점은 생각보다 미묘하다. 권한이 "파일에 붙어 있는 것"이 아니라는 것이다. 권한은 검색하는 순간에야 비로소 효력을 낸다. 말로 하면 헛속말처럼 들리지만, 실제로 작동하는 모습을 보면 전혀 다른 그림이 펼쳐진다.

한 문서 안에 공개와 비밀이 공존할 때

어느 한 문서는 늘 그렇듯, 공개해도 되는 업무 동향과 절대 밖으로 나가선 안 되는 내부 초안이 섞여 있다. 예전 방식은 파일 단위로 전부 아니면 전부를 택하게 강요했다. 다 열어두거나 다 잠그거나. 어느 쪽도 만족스럽지 못했다. 지금의 기반은 공개에서 제한급까지 이어지는 분류 체계를 지원하고, 그 체계를 내용 세그먼트 단위까지 내려보낸다. 부서도 다르고 직급도 다른 사람이同一个 지식베이스를 검색할 때, 각자는 자신에게 허가된 그 부분만 본다. "사람마다, 문단마다" 달라지는 이 권한 모델은 공공의 현실에 파일 단위 일괄 잠금보다 훨씬 잘 맞는다. 같은 보고서라도 국장은 한 세트의 조치를 보고, 주무관은 또 다른口径을 보게 되는 것. 본래 그래야 마땅한 모습이다.

왜 이 일에 이토록 공을 들여야 할까? IBM의 《2025 데이터 유출 비용 보고서(Cost of a Data Breach Report 2025)》가 하나의 기준점을 준다. 전 세계 데이터 유출 평균 비용은 444만 달러(약 4.44 million USD)에 이르렀고, 평균 수습 주기는 241일이었다. 공공 데이터의 민감도는 그보다 더 높고, 한 번 새나갔을 때의 대가는 돈의 영역을 훌쩍 넘는다. 지식베이스를 기관 자체 환경 안에 두고, 데이터가 내부망을 절대 떠나지 않게 하면 노출 면적 자체가 뿌리에서 줄어든다. 여기서 말하는 "프라이빗 배포"란 유행을 좇는 구호가 아니라, 하나의 바닥선이다.

문을 잠그는 것만으로는 부족하다

닫아걸기만 해선 안 된다. 공공 팀이 마주하는 훨씬 실무적인 걱정이 따로 있다. "기존 시스템의 데이터를 과연 옮길 수나 있을까?"

"지식베이스를 만든다"는 말을 들으면 가장 흔히 떠오르는 반응이 "그럼 운영 데이터베이스를 다 옮겨야 하는 거 아니야?"다. 보통은 아니다. 성숙한 접근법은 기관이 이미 쓰고 있는 데이터베이스에 직접 연결한다. 원본 데이터는 제자리에, 그리고 해당 도메인 안에 머무르되, 컴플라이언스 규칙 아래에서 검색 가능하고 인용 가능해진다. 공공 기관 입장에서 이건 뼈를 깎는 데이터 이관이 필요 없다는 뜻이다. 학적·사회보장·심사 인·허가 시스템은 지금처럼 그대로 돌아가고, 지식 계층은 곁에서 그걸 빌려 쓰기만 하면 된다. 낡은 시스템을 밀어내지 않고도 새로운 역량이 자라난다. 이런 온화한 진화야말로 조직 안에서 실제로 채택되는 길이다.

또 하나 사람들이 자주 놓치는 위험은 "업데이트가 과거 것을 지워버린다"는 점이다. 공공 문서는 강한 보존 요구가 붙는다. 십 년 전卷宗도 어느 날 갑자� 조회가 필요해질 수 있다. 이 기반은 증분 업데이트를 지원한다. 새 문서는 매번 처음부터 다시 구축하지 않고 델타로 처리하고, 모든 업데이트마다 스냅샷을 남겨 문제가 생기면 롤백할 수 있다. 일괄 삭제에는 실수로 인한 대량 삭제를 막는 보호 장치가 있어, 한 번의 잘못된 동작이 도서관 전체를 지워버리는 일을 막아준다. 풀어说면, 공공 담당자가 가장 두려워하는 두 문장 — "이제 찾을 수가 없다"와 "실수로 지워버렸다" — 을 아예 프로세스 안에 가두어버리는 셈이다.

압축은 별개의 문제가 아니다

압축 이야기를 꺼내는 까닭은, 이것을 쉽게 딴 딴 일로 치부하기 좋기 때문이다. 공공 문서에는 PDF, 스캔본, OFD, 이미지, 음성·영상이 즐비하고, 그 크기가 파일 하나에 수십~수백 메가에 이르기 일쑤다. 메일로는 못 보내고, 보관하면 저장을 꽉 채우고, 열기만 해도 버벅인다. 공개된 시험에서 443쪽짜리 OFD 문서를 압축하는 데 124초가 걸렸고, 이미지를 압축한 뒤 대형 언어모델에 넣을 때의 토큰 비용은 약 85.9% 줄었다(GPT-4o 기준 측정). 압축과 RAG는 두 가지 따로 노는 사업이 아니다. 한 사슬의 앞뒤 고리다. 파일을传输와 저장에 유리하게 줄인 뒤, 그 구조를 지식베이스로 뽑아내고, 그제야检索와 생성이 돌아간다. 순서를 거꾸로 하면, 언어모델은 시작도 하기 전에 문서 크기부터 거부하고 만다.

여기서 짚고 넘어갈 점. 압축이 본문의 명료함을 해치지 않는다는 사실이다. 압축은 저장·전송 크기에만 손을 대며, 인장(Seal)이나 표 구조 같은 핵심 판형 요소는 압축 후에도 그대로 보존된다. 본문은 구조적으로 추출되어检索에 쓰이므로 내용의 온전함엔 영향이 없다.

세 갈래 길, 무엇이 다른가

공공 지식베이스를 짓는 세 가지 경로가 진짜로 어디서 갈리는지, 한 표로 정리했다.

이 표는 어떤 제품에 대한 평가가 아니라, 무엇을 보고 평가해야 하는지 보여주는 틀이다. 표의 항목들을 놓고 공공 팀이 스스로 몇 가지를 물어보면 된다. 데이터를 우리 네트워크 밖으로 보낼 수 있는가? 한 문서 안의 공개·비밀 내용을 따로 권한 줄 수 있는가? 기존 시스템을 옮기지 않고 연결할 수 있는가? 업데이트가 잘못돼도 되돌릴 수 있는가? 이를 명확히 답하면, 길은 저절로 가려진다.

공공 부문이 직면한 역설

공공의 문맥이 가진 특수성을 다시 거듭 말해둔다. 투명하게 서비스해야 하면서도 분류는 굳게 지켜야 한다. 낡은 시스템과 연결하면서도 처음부터 다시 짜선 안 된다. 십 년 전卷宗은 보존하면서도 오늘의 언어모델은 돌려야 한다. 서로 모순처럼 보이는 이 요구들을 한데 엮어내는 접근법만이, 실제로 땅에 떨어지는 해법이다.

데이터 주권(data sovereignty)의 관점에서 보면, 공공 기관이 택할 수 있는 길은 생각보다 좁다. 망분리(air-gapped) 환경, 로컬 우선(local-first), 온프레미스(on-premises) 운영 — 이 키워드들은 기술 유행이 아니라 공공이 지켜야 할 운영 원칙이다. 외부로 데이터가 나가지 않는다는 전제 위에서만, 비로소 지식베이스가 "공공의 도구"라 불릴 자격을 얻는다.

더 넓은 그림이 궁금하다면 RAG 데이터 엔지니어링 기반과 UglyPear Data 제품 개요를 살펴보길 권한다. 그밖의 엔지니어링 노트는 기술 블로그에 정리되어 있다.

지금 시작하기

공공 지식베이스나 프라이빗 문서 허브를 구상 중이라면, 한 부서와 한 가지 문서 유형만 골라 작은 파일럿으로 시작해 보자. "압축 — 구조화 — 검색 — 권한부여"라는 작은 고리를 우선 한 번 돌려보는 것이다. 관련 제품과 솔루션은 RAG 데이터 엔지니어링 기반과 UglyPear Data 제품 개요에서 확인할 수 있고, 배포와 선정 세부 사항은 기술 블로그를 참고하면 된다.

자주 묻는 질문

Q: 공공 데이터는 반드시 프라이빗으로 배포해야 하나?
A: 민감 정보가 걸린 지식베이스라면, 프라이빗 혹은 온프레미스 배포가 더 안전한 기본값이다. 데이터를 내부망 안에 둔다. 순수 공개 정보라면 더 유연하게 다룰 수 있다. 핵심은 민감도에 따라 등급을 나누어 대응하는 것이지, 모든 것을 한 가지 규칙으로 몰아넣는 것이 아니다.

Q: 기존 업무 시스템의 데이터를 전부 옮겨야 하나?
A: 아니다. 접근법은 기존 데이터베이스에 직접 연결할 수 있어, 원본 데이터가 자리를 지키고 해당 도메인 안에 머무르면서도 검색·인용 가능해진다. 뼈를 깎는 데이터 이관을 피할 수 있다.

Q: 한 문서에 공개 내용과 비밀 구절이 함께 있으면 어떻게 관리하나?
A: 세그먼트 단위 분류를 지원하며, 권한은 검색 시점에 허가에 따라 내려간다. 직급별로 각자에게 허가된 부분만 본다. 파일 단위로 전부 아니면 전부를 택할 필요가 없다.

Q: 업데이트하면 옛 버전이 덮어써져서 사라지지 않나?
A: 증분 업데이트와 스냅샷 롤백을 지원하므로 언제든 되돌릴 수 있다. 일괄 삭제에는 오삭제 방지 보호가 있어 운영자 실수 위험을 낮춘다.

Q: 압축하면 검색 품질이나 원문의 명료함이 떨어지나?
A: 압축은 저장·전송 크기에만 맞춰지며, 인장이나 표 구조 같은 핵심 판형 요소는 압축 후에도 보존된다. 본문은 구조적으로 추출되어 검색에 쓰이므로 내용의 온전함에는 영향을 주지 않는다.

마무리하며

처음의 오해로 돌아가 보자. 지식베이스의 본모습은 "종이를 하드디스크로 옮긴 것"이 결코 아니다. 맞는 사람이, 맞는 순간에, 맞는 부분만 보게 하고, 데이터는 늘 자기 손안에 두는 것. 공공이 풀어야 할 숙제는 구체적이다. 열어서 서비스하되 분류는 지키고, 낡은 시스템과는 연결하되 재구축은 피하며, 십 년 전卷宗은 간직하면서 오늘의 언어모델도 돌려야 한다. 이 seemingly 모순된 요구를 한 줄로 꿰는 접근법만이, 비로소 땅에 닿는다.