지식 베이스가 자꾸 엉뚱한 답을 할 때 — 프라이빗 의미 검색이 풀어냅니다

사내 지식 베이스에 "작년에 우리가 진짜 벌었나?"라고 터놓고 한번 물어보세요. 대답이 제대로 나옵니까?

많은 분이 해봅니다. 돌아오는 건 대개 뜬금없는 발췌 몇 줄이거나, 아예 옆 부서 이야기를 늘어놓는 경우입니다. 모델이 멍청해서가 아닙니다. 그 앞단의 '검색'이 제대로 된 문단을 건져 올리지 못한 탓입니다. 아무리 말을 잘하는 모델이라도, 잘못된 재료를 들이밀면 진지하게 틀린 말만 합니다.

UglyPear Data가 RAG 데이터 엔지니어링 기반을 만들어 온 흐름은 https://www.uglypear.com/ko/products/ 에서 보실 수 있습니다. 그동안 점점 더 확신하게 된 한 가지가 있습니다. 프라이빗 지식 베이스에서 진짜 목을 조이는 건 검색입니다. 이번 글에서 그 이야기를 조금 풀어보려 합니다.

수치로 보는 '찾지 못하는' 현실

우리가 매일 쓰는 기업 데이터는 생각보다 방치돼 있습니다. Komprise가 조사한 바에 따르면, 기업 NAS 데이터의 60~70%는 90일 넘게 전혀 건드리지 않으면서도 비싼 1차 스토리지에 그대로 올라가 있습니다. 쌓아만 두고 거의 들여다보지 않는 데이터가 전체의 대부분이라는 뜻입니다.

그러면 직원들은 그걸 찾는 데 얼마나 쓸까요. McKinsey 측정에 따르면, 지식 노동자는 일주일 근무 시간의 약 19%를 정보를 찾고 모으는 데 씁니다. 하루로 치면 약 1.5시간입니다. 그리고 Asana의 'Anatomy of Work' 연구를 보면, 한 번 끊긴 뒤 다시 집중하기까지 평균 23분이 걸리고, 하루에 약 35개의 앱을 오가며 전환합니다.

이 세 수치를 나란히 놓고 보면 하나의 그림이 그려집니다. 데이터는 산더미인데, 정작 필요할 때 꺼내 쓰지 못해서 찾는 시간과 전환 비용이 쌓이고, 그만큼 업무 속도는 느려집니다. 문제의 시작은 '저장'이 아니라 '찾기'입니다.

의미 검색은 무엇을 고치는가

쉽게 말해, 키워드 검색은 "글자가 맞는가"를 보고, 의미 검색은 "뜻이 가까운가"를 봅니다.

원리는 이렇습니다. 문서를 잘게 쪼개어 각 조각을 '뜻을 나타내는 숫자 나열'로 바꿔 벡터 저장소에 둡니다. 질문을 던지면 그 질문도 같은 방식의 숫자 나열로 바뀌고, 저장소 안에서 "누가 더 가까운가"를 잽니다. '영업수익'과 '돈을 얼마나 벌었나'는 글자로는 멀지만, 뜻의 공간에서는 자연스럽게 붙어 있습니다. 사람이 동의어 사전을 일일이 관리할 필요가 없습니다.

그래서 키워드보다 정확한 근본 이유는, 문자 매칭이 아니라 내용의 뜻을 이해한다는 데 있습니다. 독자 입장에서 이득은 명확합니다. 구어로, 줄임말로, 업계 은어로 물어도 시스템이 그에 맞는 문단을 집어냅니다.

구체적인 예를 하나 들겠습니다. 한 재무 팀이 "작년 법인세 확정신고 안 했나?"를 찾으려 합니다. 키워드 검색은 '법인세' '확정신고'라는 글자 그대로만 훑습니다. 하지만 정작 그 일을 적어둔 건 '2025 세무 사항 설명'이라는 문서 안, 제목 없는 각주 하나일 수 있습니다. 의미 검색은 글자를 가리지 않습니다. 뜻을 읽으니 그 각주도 거둬냅니다.

최근 다듬은 검색층, 무엇이 달라졌나

의미 검색 층을 한 차례 전체 연결로 다듬었습니다. 말하자면 이렇습니다. 전체 문서 블록에 대한 의미 벡터를 빠짐없이 채웠고, 구어체 질문에 대한 이해가 눈에 띄게 안정됐습니다. 그리고 끝에서 끝까지 이어지는 질의응답 소요 시간이 수백 초대에서 십수 초대로 내려왔습니다. 구어와 서술형을 섞은 회귀 질문 묶음을 돌렸더니, 모두 목표 문단을 적중했습니다.

풀어서 말하면 이겁니다. "적자 났어?", "돈은 어디서 들어왔지?" 같은 말투로 물어도, 이제는 정확히 그 페이지를 찾아냅니다. 이 단계가 끝나야 지식 베이스는 '검색은 되는데'에서 '물으면 딱 답하는' 곳이 됩니다. 이 흐름을 어떻게 제품에 녹였는지는 https://www.uglypear.com/ko/products/ 를 보시면 됩니다.

검색과 압축은 한 팀입니다

이 두 가지를 함께 생각하는 분은 드뭅니다. 하지만 프라이빗 지식 베이스 안에서는 앞뒤로 붙어 있는 한 쌍입니다.

문서가 들이밀어지기 전에 부피가 크고 중복이 많으면, 벡터 저장소도 같이 비대해져서 검색이 느리고 비쌉니다. 계약서와 보고서, 설계도를 본뜻 그대로 한 번 압축하면 부피가 줄고 의미 블록이 깔끔해져서 검색 효율이 자연스레 올라갑니다. UglyPear Data의 방향은 줄곧 압축과 RAG 데이터 엔지니어링을 한데 묶는 것이었습니다. 앞단에서 문서를 슬림하게, 뒷단에서 검색을 정확하게, 그리고 데이터는 고객 내망을 벗어나지 않게 하는 식입니다.

그러니 선택할 때 모델 파라미터만 쳐다보지 마십시오. 진짜 계산을 해보면, 압축과 검색 두 공정의 조합이 더 큰 모델 하나 바꾸는 것보다 효과적인 경우가 적지 않습니다.

세 가지 방식을 한자리에

이름에 '검색'이 붙어 있어서 다 비슷해 보입니다. 아래 표로 차이를 펼쳐 보겠습니다. 잣대는 일관되게, 바로 비교될 수 있게 잡았습니다.

이 표를 보면 결정이 쉬워집니다. 공개해도 되는 데이터라면 앞의 둘 중 하나면 충분합니다. 하지만 계약서, 급여, 진료 기록, 고객 명단처럼 '문 밖으로 나갈 수 없는' 것들이라면 세 번째 열만 남습니다. 각 방식의 장단을 더 깊이 정리한 글은 https://www.uglypear.com/ko/blog/ 에 있습니다.

디지털 비축의另一面

앞서 Komprise 수치를 다시 떠올려 보십시오. 90일 넘게 손대지 않는 데이터가 60~70%입니다. 겉보기에는 '너무 많이 저장했다'지만, 속 원인은 '쓰지 못한다'입니다. 파일이 산처럼 쌓인 건 정리 도구가 하나 부족해서가 아니라, 무언가를 찾을 때마다 쓰레기 더미에서 열쇠를 뒤적이는 격이기 때문입니다. 검색이 파일 이름과 눈에만 의존하면, 데이터가 많아질수록 불안은 커집니다.

프라이빗 의미 검색의 가치는 바로 이 지점에 닿습니다. 파일을 대신 지우지는 않지만, "한마디 던지면 제대로 된 걸 건져준다"입니다. 데이터는 여전히 조용히 내망에 누워 있고, 아무도 가져가지 않습니다.

왜 '프라이빗'을 강조하는가

많은 팀이 처음 지식 베이스를 만들 때, 편하자고 곧바로 공용 클라우드 방식을 올립니다. 그러면 문제가 따라옵니다. 계약서, 급여, 진료 기록 같은 문서는 한번 내망을 벗어나면 더 이상 내 통제 아래 있지 않습니다.

UglyPear Data의 RAG 데이터 엔지니어링 기반은 전면 프라이빗 배포를 지향합니다. 원본 데이터는 이사하지 않고, 영역을 벗어나지 않으며, 검색과 질의응답은 모두 고객이 보유한 네트워크 안에서 마칩니다. 기반에는 다종 민감정보에 대한 자동 비식별이 내장돼 있습니다. 예를 들어 계약서 속 주민번호, 보고서 속 금액 필드 같은 것은 입고 전에 식별되어 처리됩니다. 어떻게 구현했는지는 이 자리에서 펼치지 않겠습니다. 능력의 경계만 분명히 전달합니다. UglyPear Data의 프라이빗 배포 방식은 https://www.uglypear.com/ko/products/ 에서 확인할 수 있습니다.

기업 입장에서 이것은 두 가지가 동시에 성립함을 뜻합니다. 지식 베이스가 회사 업무를 실제로 '안다'는 것, 그리고 업무 데이터는 그 서버 몇 대를 한 번도 떠난 적 없다는 것입니다.

한 대형 병원 정보 담당자와 나눈 이야기가 생각납니다. 진료 기록과 영상 자료는 그 누구도 건드리면 안 되는데, 임상에서는 "한마디로 특정 환자 군의 과거력을 바로 불러오고" 싶어 했습니다. 공용 클라우드 방식은 첫 단추인 규정 준수에서 막혔습니다. 결국 전면 프라이빗으로 갔습니다. 검색과 질의응답을 모두 원내 서버에서 돌리고, 민감 필드는 입고 전에 비식별했습니다. 의사는 매끄럽게 물어보고, 감사도 트집을 잡지 못했습니다. 이런 상황에서 '내망을 벗어나지 않는가'는 가점이 아니라 전제입니다.

누가 이 이야기를 진지하게 보아야 하는가

몇 부류의 팀이 쓰임새가 큽니다. 법무와 재무는 계약서, 증빙, 대장이 어느새 만 단위로 쌓입니다. 제조와 의료는 도면, 진료 기록, 공정 문서가 전문적이면서도 예민합니다. 그리고 "지식은 다 베테랑 머릿속에 있는데, 신입이 반나절 뒤져도 못 찾는" 어떤 팀이든 해당됩니다.

지금 당신의 고민이 "데이터가 없어서"가 아니라 "데이터는 있는데 꺼내지도 못하고, 꺼내도 맘 놓고 쓰지 못해서"라면, 그 원인은 대개 검색 층에 있습니다. 더 비싼 모델이 부족한 게 아닙니다.

자주 묻는 질문

Q. 의미 검색과 그냥 거대언어모델에 묻는 건 무엇이 다른가요?
A. 거대언어모델 자체는 회사 내부 문서를 모릅니다. 의미 검색은 "당신 자료 중 관련 문단을 찾는" 일을, 모델은 "그 문단을 바탕으로 답을 엮는" 일을 합니다. 둘이 맞물려야 진지하게 지어낸 답이 나오지 않습니다.

Q. 프라이빗 배포하면 느리지 않나요?
A. 예전에는 그랬습니다. 벡터가 덜 만들어지고 연결이 안 다듬어져서였습니다. 전체 의미 벡터를 채우고 검색 연결을 마친 뒤에는, 끝에서 끝까지 이어지는 질의응답이 십수 초대까지 내려와 일상 질의 체감으로는 충분합니다.

Q. 민감정보는 어떻게 내망 밖으로 안 나가게 하죠?
A. 전면 프라이빗 배포 아래서는 원본 데이터가 이사하지 않고 영역을 벗어나지 않으며, 검색과 질의응답은 고객 내망에서 마칩니다. 기반에 다종 민감정보 자동 비식별이 내장돼 있어, 입고 전에 식별해 처리합니다. 사람이 건건이 확인하는 방식이 아닙니다.

Q. 파일 형식이 아주 뒤죽박죽인데 지식 베이스에 넣을 수 있나요?
A. 계약서, 보고서, 작업표, 설계도, 회의록 같은 흔한 형식은 대부분 담을 수 있습니다. 다만 그 전에 압축과 형식 정비를 해서 부피와 중복을 줄여야 검색 효율이 올라갑니다.

Q. 지식 베이스를 만드는데 아주 큰 팀이 필요한가요?
A. 아닙니다. 명확한 검색·비식별 전략과 프라이빗 배포 능력이 있으면 충분합니다. 작은 팀도 알맞은 기반을 쓰면, 흩어진 자료를 "한마디 물으면 답하는" 내부 비서로 바꿀 수 있습니다.

지금 사용해 보기

프라이빗 의미 검색이 실제로 어떻게 도는지 보고 싶다면, UglyPear Data의 RAG 데이터 엔지니어링 기반을 살펴보세요: https://www.uglypear.com/ko/products/

엔지니어링 실무와 선택 가이드는 기술 블로그에 정리돼 있습니다: https://www.uglypear.com/ko/blog/

손에 든 문서가 많고 뒤죽박죽인 데다 내망 밖으로도 나갈 수 없다면, 한 부서 지식 베이스로 작은 범위 시범을 권합니다. 검색과 비식별부터 한번에 맞추고 나서 넓히는 게 좋습니다: https://www.uglypear.com/ko/