사내 지식 베이스가 엉뚱한 답을 내놓나요? 먼저 문서 단계를 점검하세요

회사의 지식 베이스가 엉뚱한 대답을 내놓으면, 대부분의 팀은 가장 비싼 쪽부터 손을 댄다. 모델을 더 크게, 더 비싼 것으로 바꾸고 프롬프트는 길게 늘린다. 그런데 돈은 나갔는데 답은 여전히 딴소리다.

이건 좀 반직관적이다. 문제의 원인이 모델에 있지 않을 때가 많기 때문이다. 모델에 던져지기 직전, 문서라는 층이 이미 무너져 있는 경우다.

흔한 풍경 하나를 떠올려보자. 법무팀의 5년 치 계약서, 고객 지원 티켓, 제품 매뉴얼, 스캔 이미지가 어지럽게 한 폴더에 들어있다. 이걸 통째로 모델에 던져 '알아서 이해해'라고 한다. 모델이 읽는 건 정리되지 않은 원본 수십 GB고, 찾아내는 건 파일명과 키워드로 억지 매칭한 몇 페이지다. 그러니 엉뚱한 문장을 엉뚱한 곳에 붙여 내놓는 건 당연하다. 모델이 멍청해서가 아니다. 처음부터 들어간 재료가 엉망이었을 뿐이다.

모델을 키우기 전에, 바닥부터 보세요

모델 교체가 올리는 건 천장이다. 바닥이 아니다.

여기 자주 놓치는 비용 구조가 있다. 문서가 저장소에 들어가기 전의 '위생 상태'—용량, 형식, 민감 필드, 중복—가 검색 품질의 상한을 결정한다. 모델이 아무리 뛰어나도 입력이 더러우면 소용없다. 업계에선 이를 데이터 위생(data hygiene)이라 부른다. '지저분하고, 크고, 더러운' 문서를 먼저 치워두는 게, 나중에 연산을 붓는 것보다 훨씬 비용이 적게 든다.

겉으로는 모델 탓처럼 보인다. 하지만 곰곰이 따져보면 뿌리는 그보다 앞에 있다. 검색의 본질적 문제는 '모델이 똑똑하냐'가 아니라 '사용자가 진짜 원하는 정보가 정확히 잡히느냐'다. 이 제일 원리는 모든 모델 기술보다 앞선다. 모델은 마지막 공정일 뿐, 앞 공정들이 틀어지면 아무리 애써도 되살리지 못한다.

엔지니어링 기반이 도대체 하는 일

제대로 지식 베이스를 만드는 사람은 원본 파일을 곧바로 모델에 주지 않는다. 먼저 엔지니어링 기반(data-engineering base)을 한 번 거친다. 문서를 압축해 가볍게 만들고, 형식을 통일하고, 규칙에 따라 민감 정보를 가리고, 검색에 알맞게 잘라서 출처와 함께 넣는다. 이 일에는 통용되는 공정이 있다. 수집, 정제, 분할, 벡터화, 검색, 생성—여섯 단계 각자가 마지막 답변의 품격을 좌우한다.

눈치 빠른 팀은 요구사항에 없던 일도 더 한다. 실제 질의응답 쌍을 모아 검수용 표준 질의집(golden set)을 먼저 만들고, '어느 정도 정확해졌다'는 느낌이 아니라 검색 품질을 숫자로 관리한다. 특정 유형의 질문이 퇴보했는지 지속적으로 회귀 테스트를 돈다. 장시간 작업을 시작하기 전에는 '실패하면 어떤 모양일지, 경계는 어디인지'를 미리 그려둔다. 혼합 검색, 재정렬, 질의 재작성, 의미 기반 분할, 그리고 오프라인 평가 프레임워크로 품질을 재는 일—이 모두 공개된 엔지니어링 상식이지 어느 한 곳만의 비법이 아니다. 다만 이걸 매 단계 재현 가능하게 만드는 일은, 기반 자체를 하나의 제품으로 다듬어야 한다.

'재현 가능'이라는 말은 구호로 소비되기 쉽다. 어떤 지식 베이스가 진짜 쓸모 있는지, 독립적으로 증명할 수 있는 건 뭘까. 공급자가 혼자 보여주는 시연이 아니다. 독립 표착된 표준 질의집, 오프라인 지표의 재현, 블라인드 A/B 테스트의 안정성, 지속 통합 파이프라인에 상주하는 회귀 스위트, 그리고 사용자의 실제 이용 신호가 흘러 들어오는 구조. 이게 빠지면 '더 정확해졌다'는 그저 느낌일 뿐이다.

한 걸음 더: 전처리를 블랙박스에서 꺼내다

전처리를 관측 가능한 공정으로 만드는 일, 이건 최근 꽤 과소평가된 진전이다.

수천 건의 문서를 압축하고 형식을 바꾸고 저장소에 넣는 데 몇 시간이 걸린다고 치자. 전통적인 흐름에서는 그 사이 어디서 멈췄는지, 어느 한 파일이 조용히 실패했는지 전혀 보이지 않는다. UglyPear 데이터의 최근 RAG 기반은 여기서 한 걸음 나갔다. 문서 전처리—압축, 형식 변환 같은 오래 도는 배치 작업—를 관측 가능한 파이프라인으로 만든 것이다. 진행 상황이 보이고, 어느 단계가 느린지 어느 파일이 깨졌는지 바로 짚어낼 수 있으며, 필요하면 되돌려서 다시 돌릴 수 있다.

독자가 얻는 이득은 명확하다. 더 이상 검은 화면을 멍하니 기다릴 필요가 없다. 그리고 맨 마지막에 '사실 문서의 마지막 30%는 저장소에 들어오지도 않았다'는 걸 발견하는 일도 사라진다.

작아 보이는 변화 같지만, '그냥 돌아가기만 하면 된다'와 '운영에 써도 믿을 수 있다'를 가르는 선이다.

왜 이 공정들이 통하는지, 메커니즘부터

왜 이 공정들이 진짜로 통하는지, 기능 목록보다 메커니즘을 먼저 설명하는 게 낫다.

압축부터 보자. 법무팀 계약 하나가 수백 MB라면, 전체를 그대로 넣는 순간 저장과 검색이 동시에 무너진다. 원리는 이렇다. 문서 안에는 반복 정보, 불필요한 객체, 다시 부호화할 수 있는 미디어가 많다. 이걸 용도에 맞춰 다시 부호화하면 부피는 보통 60%에서 80%까지 줄고, 글자와 도장 같은 핵심 정보는 남는다. 돌아와서 독자 이득을 보면: 같은 검색 저장소라도 가벼워지면 응답이 빨라지고 비용이 낮아진다. 큰 파일이 '모델에 안 들어간다'는 막힘도 사라진다.

검색을 보자. 파일명으로 '2024년 공급업체 협약'을 찾다가 안 잡히면 끝이다. 내용의 의미로 찾으면, 모델이 '누구랑 맺었고 무엇에 관한 건지, 조항은 어디 있는지'를 안다. 이것이 파일명 매칭 대비 의미 검색의 격차다. 문자를 보는 게 아니라 뜻을 보는 것이다. 다만 의미가 아무리 강해도 더러운 입력을 구해내진 못한다. 앞단의 정제와 분할이 의미 검색이 몇 할의 힘을 내게 할지 결정한다.

배포 형태도 빼놓을 수 없다. 민감 문서가 가장 두려워하는 건 모델이 틀리는 게 아니라, 데이터가 내부망을 빠져나가는 거다. 프라이빗 배포는 전처리와 검색 전체를 당신의 환경에서 돌린다. 문서가 회사 네트워크를 떠나지 않는다. 이는 '더 큰 클라우드 모델을 산다'는 길과 다른 길이다. 데이터를 내주고 똑똑해짐을 사는 길, 그리고 똑똑함을 집 안에 두는 길이다.

'문장마다 출처를 단다'는 얘길 따로 빼는 이유는, 흔히 덧붙이는 장식으로 치부되지만 실은 필수이기 때문이다. 규제 업종에서 한 답변이 어느 파일의 어느 페이지를 인용했는지 가리킬 수 없으면 감사도 책임 소재도 불가능하다. 엔지니어링 기반은 분할과 입고 단계에서 매 문단에 추적 표시를 박고, 생성할 때 출처를 함께 내민다. 요구사항 쪽에선 '별로 안 중요해 보이는' 대목이지만, 알고 보는 사람은 이걸 검수의 레드라인으로 본다. 규정 준수를 앞당긴다는 건, 문서가 저장소에 들어가기 전에 이런 규칙을 세운다는 뜻이지 문제 터지고 나서 메우는 게 아니다.

쉽게 잘못 계산하는 비용 장부도 있다. 전처리를 앞서 하지 않는 대가는 일회성이 아니다, 굴러가며 불어난다. 검색은 점점 부정확해지고 사용자는 점점 신뢰를 거두며, 결국 아예 쓰지 않게 된다. 그러면 처음에 들인 연산이 모두 물거품이 된다. 반대로 전처리 관문을 앞단에서 단단히 하면, 뒤이은 모든 질의응답의 품질이 더 높은 바닥 위에 선다. 한계 비용은 오히려 낮아진다. 이건 돈을 얼마나 아끼느냐의 문제가 아니라, 이 길이 통하느냐의 문제다.

직접 넣는 것과 미리 정제하는 것, 표로 보기

원본을 그대로 모델에 투입하는 것과 기반을 거쳐 정제하는 것을, 잴 수 있는 다섯 가지 축에서 견줘보자.

세 가지 데이터가 말하는 이유

왜 이 단계를 생략하면 안 되는지, 바깥의 세 수치가 말해준다.

민감 정보 비식별을 왜 생략하면 안 되는가. IBM의 2025년 데이터 유출 비용 보고서에 따르면, 탈취된 데이터 중 고객 개인 식별 정보(PII)가 53%, 직원 개인 정보가 37%, 지식재산권(IP)이 33%를 차지했다. 그리고 지식재산권은 건당 손실이 가장 커서 178달러에 이른다. 지식 베이스가 이런 필드를 그대로 내보내기만 해도, 위험은 '일어날 수도 있는' 게 아니라 이미 '일어난' 상태다.

정보를 찾느라 허비하는 시간도 무시 못 한다. 맥킨지(McKinsey)에 따르면, 지식 노동자는 근무 주의 약 19%를 정보를 찾고 모으는 데 쓴다. 전처리가 안 된 지식 베이스는 이 시간을 줄이는 대신 늘린다. 엉뚱한 답이 나오면 사람이 다시 뒤져봐야 하니, 원래 잃던 19% 위에 재작업 시간까지 얹어진다. 제대로 정제된 베이스는 이 19%를 되찾는 도구여야 한다. 먹히지 않으면 도입 자체가 낭비다.

저장 측의 압박도 작지 않다. Komprise의 고객 조사에서, 기업 주저장장치 데이터의 60~70%가 90일 넘게 접근되지 않았음에도 가장 비싼 1차 저장소에 그대로 머물러 있었다. 지식 베이스가 가벼움과 계층화를 하지 않으면, 이 '차가운 데이터' 덩어리를 그저 키우기만 한다. 계층화란 자주 쓰는 뜨거운 데이터와 아닌 것을 가려 저장 위치를 나누는 일이다. 전처리 단계에서 이 구분을 두면, 비싼 1차 저장소를 점유하는 쓸모 없는 부피를 줄일 수 있다.

다시 처음 질문으로

처음 질문으로 돌아가자. 사내 지식 베이스가 엉뚱한 답을 내놓는 건, 열 번 중 아홉은 모델 탓이 아니다. 문서라는 관문이 제대로 열리지 않은 탓이다. 전처리를 관측 가능하고 되돌릴 수 있고, 데이터가 내부망을 떠나지 않는 공정으로 만든 다음에야 모델 얘기를 꺼내야 한다. 순서가 틀리면 아무리 연산을 부어도 물에 떠 있는 박을 누르는 격이다. 모델은 어디까지나 도구일 뿐, 재료를 가려내는 일은 그 앞단에 있다.

지금 확인하기

회사의 문서를 진짜로 써먹고 싶다면, UglyPear 데이터의 제품과 사례를 들여다보세요.

• RAG 데이터 엔지니어링 기반과 프라이빗 배포: https://www.uglypear.com/ko/products/
• 문서 압축과 형식 정규화: https://www.uglypear.com/ko/products/
• 더 많은 엔지니어링 실무와 도입 가이드: https://www.uglypear.com/ko/blog/
• UglyPear 데이터 한국어 사이트: https://www.uglypear.com/ko/

자주 묻는 질문

지식 베이스가 엉뚱한 답을 내놓으면, 더 큰 모델로 바꿔야 하나요, 데이터를 고쳐야 하나요?

대개는 데이터 문제입니다. 모델이 아무리 강해도 입력 품질이 정하는 상한 안에 갇힙니다. 문서의 압축, 정제, 분할, 비식별을 먼저 바로잡아야 검색 품질의 상한이 올라갑니다. 모델 교체는 '천장이 충분히 높으냐'를 푸는 일이고, 엔지니어링 기반은 '바닥이 충분히 단단하냐'를 푸는 일입니다.

문서 압축하면 도장이나 주요 조항이 사라지지 않나요?

사라지지 않습니다. 압축은 용도를 나누어 유무손실을 정합니다. 글자, 도장, 도표 같은 핵심 정보는 보존(무손실) 경로를 타고, 중복 객체와 미디어는 다시 부호화합니다. 공개된 실측에서 443쪽 분량의 공식 전자 문서(OFD 형식)를 약 124초 만에 처리했고, 선명도와 도장 모두 그대로 남았습니다.

민감 정보 비식별은 어떻게 작동하나요? 본문을 해치지 않나요?

규칙에 따라 이름, 신분증, 금액, 영업 비밀 등 범주를 식별해 가립니다(총 13개 범주). 건드려야 할 곳만 건드리고 본문의 의미는 최대한 유지합니다. 구체적으로 어느 필드를 가릴지는 여러분의 규정 준수 목록과 맞춰 정하는 걸 권합니다.

프라이빗 배포와 클라우드 모델 직접 쓰기, 핵심 차이는 뭔가요?

핵심은 데이터의 위치입니다. 프라이빗 배포는 전처리와 검색을 모두 당신의 환경에서 돌립니다. 문서가 내부망을 떠나지 않습니다. 클라우드 모델은 쓰려면 내용을 밖으로 보내야 합니다. 계약서, 진료 기록, 재무 자료처럼 다루기 민감한 자료는 로컬에 머무는 편이 규정 준수 관점에서 깔끔합니다. air-gapped(물리적 격리망) 환경에서도 동일하게 운용됩니다.

문서가 많지 않은 소규모 팀도 데이터 엔지니어링 기반이 필요한가요?

'많으냐'를 보는 게 아니라 '지저분하냐'를 보세요. 수천 건뿐이어도 형식이 뒤섞이고 민감 필드가 섞여 있으며 장기 보관이 필요하다면, 관측 가능한 전처리 하나로 재작업을 크게 줄일 수 있습니다. 문서가 적으면 오히려 공정을 먼저 매끄럽게 돌려놓고 사업이 커지면서 키우기 좋습니다.