과거 문서를 찾지 못해 감사에서 탈락한 금융사, 프라이빗 RAG로 거버넌스를 되살리다

수년 전 승인을 마친 여신 건이었다. 감사관이 특정 날짜의 전자 문서 원본을 요구했고, 담당자는 검색창에 계약 번호를 넣었다. 결과는 빈 화면. 보관 시스템은 부서마다 따로 굴러갔고, 파일명 규칙은 팀마다 달랐으며, 그 문서가 어느 서버에 있는지 아무도 확신하지 못했다. 며칠을 뒤진 끝에 감사는 '문서 보존 및 제출 불이행'으로 종료되었다. 한 줄 오답이 아니라, 찾지 못한 한 장이 회사의 신뢰 등급을 흔들었다.

이런 일이 드문 게 아니다. 금융사는 태생적으로 증명해야 한다. 대출을 내줬다면 근거를, 고객을 의심했거나 의심하지 않았다면 그 판단의 흔적을, 규제 당국이 부른 문서는 언제든 꺼내 보일 수 있어야 한다. 그런데 문서는 계속 쌓인다. IDC가 추산한 바에 따르면 전 세계 데이터는 2024년에 약 149–180 제타바이트(ZB) 규모였고, 2028년에는 394 ZB까지 불어난다. 그중 80–90%가 비정형 데이터, 즉 사람이 읽는 문서와 이미지, 메시지로 채워진다. 금융사의 저장 공간은 늘고, 찾아야 할 문서는 늘고, 정작 손에 잡히는 건 줄어든다.

UglyPear 데이터는 이 문제를 '압축'과 '검색'을 하나로 묶어 본다. 고성능 문서 압축 SmartSlim과 RAG 데이터 엔지니어링 기반을 결합한 접근이다. 핵심은 위치에 있다. 완전 프라이빗, 온프레미스 배포로 데이터가 인트라넷 밖으로 나가지 않게 두고, 압축으로 문서 볼륨을 60–80% 줄인다. 크기를 줄이는 건 비용 때문만이 아니다. 작아져야 검색 인덱스에 들어가고, 들어가야 의미를 읽히며, 읽혀야 감사관 앞에서 빈 화면이 사라진다.

문서 거버넌스가 어려워지는 두 가지 흐름

데이터가 늘어나는 것만으로는 문제가 설명되지 않는다. 진짜 고통은 '늘어난 만큼 찾는 시간도 늘어난다'는 데 있다. Smallpdf가 2025년 미국 직원 1,005명을 대상으로 조사한 결과를 보면, 금융 종사자는 일주일에 평균 6.1시간을 '본 적 있는 파일'을 찾는 데 썼다. 조사 대상 업종 가운데 가장 나빴다. 이들이 동시에 열어두는 탭은 평균 8.5개, 28%는 10개 이상을 붙잡고 일한다. Kaspersky가 같은 해 1,066명을 대상으로 한 조사에서는 57%가 중요한 파일을 찾지 못한다고 답했고, 정기적으로 정리한다는 사람은 30%뿐이었으며, 26%는 이른바 '쓰레기 폴더'를 따로 가지고 있었다.

숫자背后의 문장은 이렇다. 사람들은 정리보다 쌓는 쪽을 택하고, 쌓인 뒤에는 파일명으로밖에 못 찾고, 못 찾으면 결국 감사나 실무에서 시간을 깎아낸다. 금융 문서 거버넌스는 기술 과제이기 전에 '찾을 수 있느냐'의 문제다.

파일명 검색과 의미 검색, 어디가 다른가

대부분의 금융 문서 검색은 여전히 파일명에 의존한다. "2023_여신_계약서_최종_v2_진짜최종.pdf" 같은 이름이 붙어 있어야 찾는다. 그런데 실무에서는 이름이 통일되지 않는다. 부서마다, 사람마다, 시점마다 다르게 부른다. 내용이 '부실채권 조기 상환 위약금 면제'를 다루고 있어도 파일명에 그 단어가 없으면 검색은 실패한다.

의미 검색은 다르게问다. 문서의 내용을 벡터로 읽어, "조기 상환할 때 위약금을 깎아준 적 있나?"라는 질문의 뜻을 이해하고 답이 들어 있는 문서를 건져낸다. 파일명이 엉망이어도 상관없다. 금융 문서처럼 비정형이 지배적인 영역에서는 이 차이가 결정적이다. 다만 의미 검색만으로는 부족하다. 키워드가 정확할 땐 키워드가 더 빠르고, "작성일 2024년 1분기" 같은 조건은 메타데이터 필터가 더 확실하다. 그래서 제대로 된 시스템은 둘을 섞는다.

압축은 전제다, 온프레미스는 바닥선이다

금융 문서를 RAG로 다루려면 먼저 그 문서가 인덱스에 들어갈 수 있어야 한다. 수백 메가바이트짜리 스캔 계약서, 이미지가 가득한 보고서는 그대로 두면 처리조차 느리거나 누락된다. SmartSlim이 여기서 볼륨을 60–80% 줄인다. 중요한 건 인장(날인)과 서식이 보존된다는 점이다. 금융 문서에서 도장 하나, 서식 한 줄은 법적 효력의 일부이므로, 압축이 시각적·구조적 정확성을 해치면 안 된다. 줄이되 본질은 그대로 둔다.

그리고 배포 위치다. 금융 규제에서 데이터가 어디에 머무는지는 선택이 아니라 바닥선이다. 온프레미스, 즉 회사 내부망에 두면 데이터가 인트라넷을 벗어나지 않는다. 외부 클라우드로 문서를 보내지 않으니 전송 구간에서 생길 수 있는 이탈 위험 자체가 사라진다. 압축과 온프레미스를 함께 갖출 때 비로소 '안에서 작게, 안에서 똑똑하게'가 성립한다.

전문가라면 들여다보는 깊이

검색 품질을 '느껴보니 괜찮더라'로 끝내면 안 된다. Serious한 RAG 시스템은 검색 품질을 정량화하는 라벨 평가 세트부터 시작한다. 질문과 정답 문서 쌍을 손으로 매겨두고, 새 모델이나 새 설정이 들어올 때마다 그 세트 위에서 지표를 재는 식이다. 정보 요구의 제1원리를 따져보는 습관도 필요하다. 사용자가 진짜로 묻는 건 '파일명'이 아니라 '이 상황에서 근거가 되는 내용'이라는 점을 명확히 정의해야, 평가도 시나리오도 맞게 짜인다.

실패와 경계를 분석하는 태도도 빠지지 않는다. 의미 검색이 헛소리를 내는 지점, 메타데이터가 빈약해 필터가 무력해지는 지점, 긴 문서에서 정답이 묻혀 버리는 지점을 일일이 짚어야 한다. 그 대응으로 하이브리드 검색(의미+키워드), 리랭킹(1차 후보를 다시 정렬), 메타데이터 필터, 그리고 무엇보다 오프라인 평가가 붙는다. 골든 세트라는 확정된 정답 묶음을 두고, 재현 가능한 오프라인 지표를 매번 똑같이 돌리며, 지표가 깎이면 CI(지속적 통합) 회귀로 막아내는 구조다. 이런 깊이는 '잘 돌아간다'는 주장을 '증명 가능하다'는 상태로 바꾼다. 금융 같이 틀리면 비용이 큰 영역에서는 이 증명이 곧 도입의 명분이 된다.

최근 버전에서 달라진 권한의 결

UglyPear 데이터의 최근 RAG 기반 버전은 권한 제어를 한 단계 더 잘게 쪼갰다. 문서 전체가 아니라 프래그먼트, 즉 문서의 일부 단위로 권한을 나누는 방식이다. 같은 계약서라도 역할에 따라 보이는 부분이 다르다. 여신 담당자는 금리 조항을, 준법 담당자는 조항 전체를, 외부 감사관은 허락된 일부만 본다. 무엇보다 이 권한은 검색할 때 실시간으로 적용된다. 문서를 다 올리고 나중에 태그를 붙여 사후 정리하는 방식이 아니다. 질문이 들어오는 순간 권한이筛去한다.

운영 측면에서도 기존 업무 DB에 직접 연결하는 형태를 취한다. 데이터를 별도 영역으로 옮겨 담지 않고 원래 있던 곳에 둔 채 다룬다. 증분 업데이트로 바뀐 분량만 반영하고, 스냅샷 롤백으로 잘못된 상태를 되돌리며, 오삭제 방지로 실수로 지워지는 일을 막는다. 이 구성은 엔드투엔드 검증을 통과한 상태로 운영에 붙일 수 있다. 기존 시스템을 건드리지 않으면서 거버넌스만 얹는 형태라, 도입 부담이 큰 금융사에도 맞는다.

세 가지 현장 시나리오

여신 심사. 심사역이 "이 차주, 과거에 조기 상환 위약금을 깎아준 적 있나?"라고 묻는다. 파일명 검색이었다면 부서별로 흩어진 계약서를 일일이 뒤져야 했겠지만, 의미 검색은 해당 조항이 든 프래그먼트를 바로 건져준다. 권한에 따라 심사역이 볼 수 있는 범위 안에서만 답이 나오니, 민감 조항이 새어나갈 걱정도 줄어든다.

AML 실사. 의심 거래를 파악하려면 수년 치 고객 대화, 신고서, 내부 메모를 교차 확인해야 한다. 비정형이 지배적인 이 영역에서 키워드만으로는 패턴을 놓치기 쉽다. 압축으로 인덱스 부담을 줄인 상태에서 의미 검색을 돌리면, "이 고객이 자금 출처를 설명하지 못한 정황"을 담은 문서들을 모아 맥락을 읽을 수 있다.

규제 보고. 당국이 특정 기간의 의사결정 근거를 제출하라고 할 때, 산재한 문서를 수집해 정리하는 데 며칠을 쓰지 않아도 된다. 온프레미스에 머무는 데이터 위에서 검색하고, 필요한 프래그먼트만 추려 제출용으로 묶는다. 문서가 인트라넷을 벗어나지 않으니 제출 절차 자체의 컴플라이언스 바닥선도 지켜진다.

세 가지 배포 방식을 나란히

표에서 보듯 로컬 분산 보관은 데이터는 안 나가지만 찾는 방식이 파일명에 묶이고, 온라인 SaaS는 편하지만 데이터가 밖으로 나간다. 프라이빗 배포는 둘의 단점을 피하면서 압축과 의미 검색, 프래그먼트 단위 권한까지 갖춘다.

지금 사용해 보기

• SmartSlim 제품 소개: 고성능 문서 압축으로 볼륨 60–80% 감소, 인장·서식 보존, 온프레미스에서 데이터 밖으로 안 나감.
• UglyPear 데이터 한국어 메인: 압축 × RAG 데이터 엔지니어링 기반의 프라이빗 배포 위치와 전체 라인업.
• 기술 블로그: 금융 문서 거버넌스와 프라이빗 RAG 적용 사례, 운영 노하우.

자주 묻는 질문

Q: 금융사는 왜 굳이 프라이빗 배포를 고민해야 하나요?
A: 규제 환경에서 데이터가 어디에 머무는지는 바닥선입니다. 외부 SaaS로 문서를 보내면 전송·보관 구간에서 이탈 위험이 생기고, 금융사는 그 책임을 피하기 어렵습니다. 온프레미스로 내부망 안에 두면 데이터가 인트라넷을 벗어나지 않아 컴플라이언스 명분이 더 탄탄해집니다.

Q: 문서를 압축하면 인장이나 날인이 지워지지 않나요?
A: SmartSlim은 압축하면서 인장과 서식, 구조적 정확성을 보존하도록 설계되어 있습니다. 금융 문서에서 도장 하나, 서식 한 줄은 법적 효력의 일부이므로, 압축이 본질을 해치지 않는 것이 전제입니다. 줄이되 근거로서의 형태는 그대로 둡니다.

Q: 기존 업무 DB의 데이터를 외부로 옮겨야 하나요?
A: 아닙니다. 최근 버전은 기존 업무 DB에 직접 연결해 데이터를 별도 영역으로 옮기지 않고 다룹니다. 원래 있던 곳에 둔 채 증분 업데이트로 바뀐 분량만 반영하므로, 이동에 따른 이탈 우려 없이 거버넌스를 얹을 수 있습니다.

Q: 의미 검색과 키워드(파일명) 검색, 뭐가 다른가요?
A: 파일명 검색은 이름에 단어가 있어야 찾고, 금융 문서는 부서마다 이름 규칙이 달라 자주 실패합니다. 의미 검색은 내용을 이해해 "조기 상환 위약금을 깎아준 적 있나?" 같은 질문의 뜻으로 문서를 건져냅니다. 제대로 된 시스템은 둘을 섞어 씁니다. 키워드가 정확할 땐 키워드가 빠르고, 뜻을 읽어야 할 땐 의미 검색이 유리합니다.

Q: 문서가 많아지면 검색 속도가 느려지지 않나요?
A: 압축으로 볼륨을 60–80% 줄이면 인덱스 부담 자체가 가벼워집니다. 거기에 하이브리드 검색과 리랭킹, 메타데이터 필터를 얹어 후보를 정제하므로, 문서가 쌓여도 응답이 크게 무뎌지지 않습니다. 더불어 오프라인 평가 세트로 지표를 지켜보며 속도와 정확도를 함께 관리할 수 있습니다.