지난해 말, 한 지역 은행의 준법감시팀은 손에 잡히지 않는 숫자를 하나 정리했다. 공유 폴더와 메일 첨부, 외부 위탁 시스템 여기저기에 흩어진 제도 문서와 감독 당국 통보, 실사 보고서를 모두 모으면 이백만 건이 넘었다. 그들이 원했던 건 들었을 때 무척 평범해 보이는 일이었다. 업무 담당자가 자연어로 질문하면, 시스템이 출처까지 달아 답을 주는 것. 그런데 막막해진 지점이 세 군데였다. 데이터는 내망을 나갈 수 없고, 문서 형편은 천차만별이라 스캔본과 PDF가 대부분을 차지했으며, 무엇보다 두려운 건 모델이 아주 확신에 찬 투로 틀린 말을 하는 상황이었다. 한 줄 한 줄이 다 근거로 거슬러 올라갈 수 있어야 했다.
이 문제는 UglyPear Data가 몇 해째 풀어온 문제다. 우리가 만드는 것은 고성능 문서 압축과 검색 증강 생성(RAG)을 결합한 데이터 엔지니어링 기반이다. 여기엔 단 하나의 원칙만 있다. 완전 프라이빗 배포, 데이터는 내망을 벗어나지 않는다는 것.
처음 이 은행은 외부의 편리한 도구를 한 번 시도해 보려 했다. 그러다 준법감시팀이 제동을 걸었다. 고객 정보가 섞인 문서를 외부로 보낼 수 없다는 게 아니라, 보낼 수 있는지조차 확신할 수 없었기 때문이다. 그 지점에서 '모델이 얼마나 똑똑하느냐'는 질문은 쏙 들어갔다. 남은 질문은 오직 하나, '우리 망 안에서, 우리 데이터로, 근거를 달고 답할 수 있느냐'뿐이었다.
금융 기관이 믿고 쓸 수 있는 사내 지식 베이스를 세우려면 어떤 단계를 거쳐야 하는지, 피할 수 없는 몇 가지 고비를 중심으로 풀어보겠다.
지식 베이스가 필요하면서도 두려운 이유
지식 노동자의 시간은 상당 부분 '찾는 일'에 스르륵 사라진다. IDC가 정보 업무 종사자 1,200명을 대상으로 진행한 설문에 따르면, 직원들은 문서를 찾는 데 일주일에 평균 4.5시간을 쓴다. 금융 환경에 놓으면 이 수치는 더 올라가는 경우가 많다. 제도는 많고 버전은 뒤죽박죽이며 부서를 가로지르는 검색이 잦아서, 어느 한 문서가 '지금 유효한 최신본'인지 확인하는 것만으로 반나절이 증발하곤 한다.
진짜 골칫거리는 데이터 자체의 예민함이다. IBM의 2025년 데이터 유출 비용 보고서를 보면, 탈취된 데이터 중 고객 개인식별정보(PII)가 53%, 임직원 PII가 37%, 지식재산권이 33%를 차지했다. 그리고 지식재산권 기록 하나가 유출될 때의 비용은 최대 178달러에 이른다. 은행이나 증권사, 보험사 입장에서 계약서와 고객 자료, 리서치 보고서를 묶음째로 퍼블릭 클라우드 모델에 맡기는 건 금고 문을 활짝 열어두는 것과 비슷하다.
데이터는 멈추지 않고 불어난다. Komprise의 2026년 보고서에 따르면 대기업의 74%가 5PB가 넘는 비정형 데이터를 보관 중이고, 40%는 10PB를 넘기며, IT 리더의 85%는 2026년까지 저장 비용 지출이 계속 오를 것으로 본다. 금융 기관의 아카이브와 영상, 로그는 딱 그런 데이터다. 자리를 잡아먹으면서도 자주 꺼내 쓰지 않는. 그래서 청구서는 조용히 불어난다.
문제는 양만 큰 게 아니라 '쓸모 있는 순간'이 불규칙하다는 점이다. 분기 말 감사 때는 어제까지 잊고 있던 문서가 갑자기 생명줄이 되고, 평소엔 몇 년째 잠든 파일이 한 번에 수만 건씩 불려 나온다. 이런 비정형 더미를 매번 사람 손으로 뒤지게 두면, 찾는 비용이 데이터를 가진 비용을 넘어선다. 지식 베이스는 바로 이 틈을 메우려는 시도다. 다만 그 시도가 외부로 데이터를 빼돌리는 방식이어선 안 된다는 게 금융의 조건이다.
압축은 나중에 할 일이 아니라 전제 조건
RAG하면 벡터 저장소에 문서를 쑤셔 넣고 질문하면 된다고 생각하는 분이 많다. 현실은 훨씬 지저분하다. 모델에 넣는 원문이 크고 시끄럽고 불필요한 텍스트로 가득 차 있으면, 토큰 비용과 검색 노이즈가 동시에 폭주한다. 답은 희석되고 청구서는 올라가며, 검색 단에선 엉뚱한 조각을 들고 온다.
우리가 택한 방식은 저장소에 들어가기 전에 전처리 단계를 한 번 더 거치는 것이다. PDF, 이미지, 동영상, 오디오, Office 문서, OFD, 스캔본 등 흔히 쓰는 형식을 통일된 방식으로 다룬다. 압축이 필요한 곳은 줄이고, 탈감이 필요한 곳은 가리고, 구조를 뽑아내야 할 곳은 뽑아낸다.
금융 문서가 까다로운 건 종류가 섞여 있다는 점이다. 같은 '계약서'라도 워드로 쓴 것, 스캔한 종이, 표가 깨진 PDF가 섞여 있다. 형식마다 풀어야 할 문이 다르고, 그 문을 제대로 안 열면 검색 단에선 표면만 긁어오고 속내용은 빠진다. 그래서 전처리는 '어떤 모델을 쓰느냐'보다 앞서 오는 일이다. 문서가 깨끗하게 정리되어야 모델이 할 일도, 비용도, 오답도 줄어든다. 공개 벤치마크를 보면 443쪽짜리 OFD 문서를 끝까지 처리하는 데 약 124초가 걸리고, 이미지 자산을 압축한 뒤 GPT-4o에 넣었을 때 토큰 비용이 약 85.9% 줄었다. 부피는 보통 60~80% 빠지는데, 같은 검색 예산으로 더 많은 자료를 커버할 수 있고 같은 답이 깨끗한 맥락 위에서 나온다는 뜻이다.
최근 우리는 프라이빗 지식 베이스 라인을 '인도할 수 있고 검수할 수 있는' 지점까지 한 걸음 더 밀어붙였다. 최소한의 검수 가능한 시스템이 엔드투엔드 실측을 통과했다. 업로드부터 증분 적재, 출처가 추적되는 다경로 검색, 인용이 제약된 질의응답, 사용량 계량까지 전 구간을 아우른다. 게다가 한 번의 명령으로 고객 내망 안에 컨테이너 형태로 배포할 수 있고, 완전히 오프라인으로 돈다. 금융 기관 입장에선 어떤 외부 서비스에도 데이터를 보내지 않고, 사내에 '물으면 답하고, 답마다 출처를 표시하는' 지식 베이스를 세울 수 있다는 뜻이다. 최적화 뒤 검색과 답변 응답은 예전엔 1분 넘게 기다려야 했으나, 최적화 이후로는 1초 미만, 즉 아주 짧은 순간 안에 끝난다. 그래서 사람들이 동료에게 메일 돌리는 대신 실제로 쓰게 된다.
세 갈래, 그리고 실제 다른 점
금융 기관이 지식 베이스를 마련하는 길은 보통 세 갈래다. 진짜 차이는 데이터 주권과 문서 전처리 능력에 놓여 있다.
| 구분 | 직접 구축 | 퍼블릭 클라우드 위탁 | UglyPear 프라이빗 RAG 기반 |
|---|---|---|---|
| 데이터가 내망을 나가는가? | 통제 가능하나 연산 자원을 직접 마련해야 함 | 보통 클라우드로 업로드됨 | 내망을 벗어나지 않음 |
| 규제 준수 및 감사 | 직접 책임 | 서비스 제공자 인증에 의존 | 프라이빗 배포, 답변 추적 및 감사 가능 |
| 문서 전처리(해석·탈감·압축) | 자체 구축 필요, 작업량 큼 | 일부 지원 | 내장됨, 8개 주요 형식 지원 |
| 출시까지 걸리는 시간 | 김 | 짧음 | 중간, 컨테이너 방식 제공 |
| 가장 잘 맞는 상황 | 팀 역량에 따라 다름 | 탄력적 확장에 유리 | 중대형 기관의 내망 환경 |
데이터 주권 요구가 높고 문서 종류가 뒤죽박죽이며, 빨리 효과를 보고 싶은 기관이라면 프라이빗 RAG 기반이 보통 더 안정적인 선택이다. 가장 어려운 단계, 즉 문서를 깨끗하게 모델에 넣는 일을 남의 일로 넘기지 않고 먼저 풀어두기 때문이다.
직접 구축은 통제력이 가장 크지만, 문서 전처리부터 감사 체계까지 한 팀이 처음부터 끌어안아야 해서 출시까지 시간이 길어진다. 퍼블릭 클라우드 위탁은 손이 적게 가지만, 데이터가 망을 나간다는 전제가 따라붙는다. 금융에서 이 전제는 종종 '검토 불가'로 직결된다. 프라이빗 기반은 그 사이 어딘가다. 전처리는 이미 갖춰져 있고, 배포는 고객 내망 안에서 끝난다. 그래서 '우리 망 안에서, 우리 데이터로'라는 조건을 지키면서도 처음부터 모든 문을 직접 열 필요는 없다.
실제 적용할 때 몇 가지
예민한 정보는 앞단에서 처리하자. 우리 기반에는 13개 범주의 AI 민감정보 탐지가 내장되어 있어, 문서 속 얼굴·신분증·인장 같은 영역을 탈감한다. 모델에 들어가선 안 될 필드가 맥락 창에 끼어들지 않게 막는 것이다. 한 번에 끝내려 들지 말자. 고가치 문서 한 부류, 가령 감독 통보나 상품 매뉴얼부터 시작해 동작을 확인한 뒤 넓혀가면 된다. 그리고 '모든 답은 출처를 달아야 한다'를 검수 기준에 넣어라. 출처가 없는 답은 금융 현장에선 믿을 수 없다. 잘못된 인용이 잘못된 결정으로 이어질 수 있는 곳이니까.
검색 예산을 모델만큼이나 생각하자. 적재 전에 압축하는 일이야말로 방대하고 이질적인 문서 묶음을 반복해서 경제적으로 질의할 수 있게 하는 열쇠다. 누군가 질문할 때마다 토큰 절감은 복리로 붙는다. 그래서 한 번의 전처리 투자가 계속 이자를 낸다.
기반이 다루는 형식은 PDF, 이미지, 동영상, 오디오, Office, OFD, 스캔본 등 8개 주요 범주에 걸쳐 있다. 스캔본과 OFD 같은 판형 문서도 해석하고 압축한 뒤 적재할 수 있다. 압축이 핵심 내용을 지운다는 걱정엔 공개 벤치마크로 답한다. 443쪽 OFD가 끝까지 124초면, 부피는 60~80% 줄이면서 가독성을 지키고 인장과 판면 같은 핵심 정보엔 별도 보호 기제가 있다.
고가치 문서 한 부류부터 시작한다는 말은 구체적이다. 감독 통보나 상품 매뉴얼처럼 자주 찾으면서도 버전 혼선이 잦은 문서를 먼저 올린다. 그 묶음 하나로 '질문하면 출처와 함께 답이 온다'는 경험을 팀 안에 심으면, 다음 부류를 추가하는 건 설정이 아니라 데이터만 더 넣는 일이 된다. 점진적으로 넓히는 이 흐름이 프라이빗 지식 베이스를 무리 없이 사내에 안착시키는 비결이다.
사람의 습관도 따로 챙겨야 한다. 아무리 좋은 지식 베이스도, 답을 믿지 않는다면 아무도 쓰지 않는다. 그래서 초기엔 '이건 출처가 맞나'를 사람이 직접 견주어 보는 구간을 남겨두는 게 좋다. 시스템이 달아주는 인용을 업무 담당자가 한 번씩 눈으로 확인하며 신뢰를 쌓으면, 나중엔 질문하고 답을 받는 흐름 자체가 업무의 기본이 된다. 기술보다 이 습관의 전환이 프라이빗 지식 베이스가 사내에 뿌리내리는 진짜 속도를 결정한다.
자주 묻는 질문
Q: 금융 기관이 RAG 지식 베이스를 써도 데이터는 정말 내망을 안 나가나요?
A: 프라이빗 배포를 택하면 문서 해석, 압축, 벡터화부터 답변 생성까지 전부 고객이 보유한 서버나 내부 망에서 이뤄집니다. 외부 클라우드 서비스가 전혀 개입하지 않으므로 데이터 주권은 기관 안에 머뭅니다.
Q: 스캔본이나 OFD처럼 까다로운 형식도 그대로 쓸 수 있나요?
A: 가능합니다. 기반은 PDF, 이미지, 동영상, 오디오, Office, OFD, 스캔본 등 8개 주요 형식을 포괄하며, 스캔본과 OFD 같은 판형 파일도 해석하고 압축한 뒤 적재할 수 있습니다.
Q: 압축하면 중요한 내용이 사라지지 않나요?
A: 압축은 가용성 우선 원칙을 따릅니다. 공개 벤치마크에서 443쪽 OFD가 끝까지 124초에 처리되고, 부피는 60~80% 줄이면서 가독성을 보존하며 인장과 판면은 전용 보호 기제를 둡니다.
Q: 퍼블릭 클라우드 모델을 직접 부르는 것보다 프라이빗이 비싸지 않나요?
A: 단기적으로는 프라이빗에 자체 연산 자원이 필요하지만, 장기적으로 아끼는 건 토큰 비용과 규제 리스크입니다. 문서를 적재 전에 압축하면 토큰 비용이 크게 내려가고(이미지 자산은 공개 벤치마크 기준 약 85.9% 절감), 데이터 유출로 인한 잠재 손실도 사라집니다.
Q: 작은 팀도 쓸 수 있나요?
A: 프라이빗 기반은 중대형 기관의 내망 환경에 가장 잘 맞습니다. 개인이나 소규모 팀은 UglyPear Data의 데스크톱 제품인 SmartSlim으로 시작해 단말 한 대에서 문서 압축과 정리를 먼저 해결할 수 있습니다.
지금 사용해 보기
소속 기관이 프라이빗 지식 베이스를 검토 중이라면, 다음 입구에서 더 알아보시면 됩니다.
- 제품 둘러보기: SmartSlim과 MagiFiler
- RAG 데이터 엔지니어링 기반 안내: UglyPear Data 홈
- 더 많은 엔지니어링 실무와 벤치마크: UglyPear Data 기술 블로그
데이터는 내부에 두고, 답은 근거와 함께. 금융 기관이 진짜 풀어야 할 문제는 모델이 아니라, 문서를 깨끗하게 모델에 넣는 일이었습니다. 그 한 단계를 먼저 정직하게 해내면, 남은 건 기관의 데이터를 어떻게 더 잘 물을지 고민하는 일뿐입니다.