사내 규정 챗봇을 운영하던 팀에서 이런 문의가 올라와요. 육아휴직 분할 사용이 가능하냐는 질문에 챗봇이 "가능하다"고 답했는데, 실제 규정에는 특정 조건에서만 허용된다는 단서가 붙어 있었다는 거죠. 담당자가 확인해 보니 규정 문서는 최신 버전이 맞게 올라가 있었고, 그 단서 조항도 문서 안에 분명히 들어 있었고요.
문제는 그 단서가 검색되지 않았다는 데 있었어요. 조항 본문과 단서가 서로 다른 청크로 잘려 있었고, 질문과 유사도가 높게 나온 쪽은 본문뿐이었으니 모델은 자기가 받은 것만 가지고 답한 셈이죠. 그러니까 모델은 틀리지 않았어요. 틀린 건 모델에게 무엇을 줄지 결정한 쪽이었고, 그 결정은 프롬프트가 아니라 훨씬 앞 단계에서 이미 내려져 있었죠.
이런 상황에서 대부분의 팀이 가장 먼저 하는 일은 프롬프트를 고치는 거예요. "제공된 문서에만 근거해서 답하라", "예외 조항이 있는지 반드시 확인하라" 같은 지침을 시스템 프롬프트에 계속 덧붙이죠. 그런데도 품질이 기대만큼 오르지 않는 이유는 단순해요. 프롬프트는 이미 들어온 것을 어떻게 다룰지 정할 뿐, 무엇이 들어올지는 정하지 않으니까요.
LLM에는 DDL이 없죠
데이터베이스 관리자에게는 언제나 손잡이가 있었어요. 집계 값이 이상하면 쿼리를 뜯어봤고, 스키마가 업무를 못 담으면 데이터 모델을 고쳤고, 응답이 느려지면 인덱스를 다시 잡았죠. 문제를 발견한 사람이 문제가 있는 지점으로 곧장 가서 고칠 수 있었다는 뜻이에요.
데이터 웨어하우스라는 개념을 만든 Bill Inmon은 최근 「Data Management in the Age of AI」(2026년 7월 5일)에서 이 특성을 직접 통제라고 부르면서, 40년 데이터 관리사를 훑은 끝에 생성형 AI 환경에서는 그 손잡이가 사라졌다는 결론에 도달해요. 답변이 틀렸을 때 열어볼 스키마가 없고 고칠 테이블이 없죠. 모델 가중치는 우리 것이 아니고, 파인튜닝을 한다 해도 특정 답변 하나를 겨냥해 고치는 일은 불가능하고요.
그가 남긴 비유는 인형극이에요. 인형을 손으로 직접 움직이는 게 아니라 줄을 당겨서 움직이는 것, 그게 생성형 AI 환경의 데이터 관리라는 거죠. 그리고 그 줄은 하나뿐이에요. 무엇을 입력할 것인가.
Inmon이 데이터 관리자에게 남긴 가장 강한 문장도 여기서 나와요. 다른 걸 아무것도 못 하더라도 업무와 무관한 텍스트가 LLM에 들어가지 않게 막는 것만으로 충분하다는 것. 그는 이유를 두 가지로 들어요. 처리할 데이터가 줄어드니 쿼리마다 비용이 절감되고, 업무 관련 텍스트만 남으니 LLM이 다루는 범위가 명확해진다는 거죠.
RAG를 굴려본 분이라면 여기까지는 익숙한 이야기일 텐데, 정작 중요한 건 그다음이에요.
그 통제는 시스템의 어디에서 일어날까요
Inmon의 글은 필요성까지만 말하고 멈춰요. 텍스트를 걸러야 하고, 온톨로지와 분류체계를 만들어야 하고, 전사 논리 데이터 모델과 결합해야 하고, 계속 갱신해야 한다는 거죠. 전부 맞는 말이지만 전부 당위여서, 그 통제가 실제로 어느 지점에서 실행되는지는 나오지 않아요.
답은 리트리벌 파이프라인이에요. 어떤 문서를 인덱싱했는지, 어떤 크기로 잘랐는지, 질의를 어떻게 변환했는지, 검색 결과 중 몇 개를 어떤 기준으로 골랐는지 — 컨텍스트에 들어갈 내용을 실제로 결정하는 판단들이 전부 여기 모여 있죠. 앞의 육아휴직 사례에서 답을 바꾼 것도 프롬프트가 아니라 청킹 경계였고요.
데이터 엔지니어에게 익숙한 말로 옮기면 이렇게 돼요. 리트리벌 파이프라인은 새로운 ETL이죠. 원천에서 뽑아 변환하고 목적지에 적재하는 구조가 그대로인데, 목적지가 웨어하우스가 아니라 LLM의 컨텍스트 윈도우라는 점만 다르고요. 그리고 하나 더 다른 점이 있어요. 이 ETL에는 대부분의 조직에서 데이터 계보도 감사 로그도 없다는 거죠.
정형 데이터 쪽이었다면 상상하기 어려운 상태예요. 어떤 원천에서 온 데이터가 어떤 변환을 거쳐 이 리포트의 이 숫자가 됐는지 추적할 수 없는 웨어하우스를 그냥 두는 조직은 없는데, LLM 앱에서는 그게 기본값처럼 굳어져 있죠.
2단계 선별을 파이프라인으로 옮겨보면
Inmon은 텍스트 선별을 두 단계로 봐요. 먼저 넓은 범위에서 원천 텍스트를 확보하고, 그중에서 업무 관련 데이터를 다시 추린다는 거죠. 개념은 명료한데 구현으로 내려오면 판단할 게 꽤 많아져요.
1차 선별: 무엇을 인덱싱할까요
가장 중요하면서 가장 자주 건너뛰는 단계예요. 사내 문서함을 통째로 밀어 넣는 선택은 편하지만, 그 순간 폐기된 정책과 3년 전 조직도와 초안 상태의 제안서까지 전부 검색 대상이 되죠. 문서에 "폐기"라고 적혀 있지 않은 이상 LLM은 그걸 알 방법이 없고요.
인덱싱 전에 정리되어야 하는 것들을 꼽으면 대략 이래요.
문서 생애주기 — 초안과 승인본과 폐기본 중 무엇을 넣을 것인가
유효기간 — 가격표나 정책처럼 시점에 묶인 문서의 만료 기준
권한 경계 — 검색 결과가 사용자의 열람 권한을 넘지 않도록 하는 분리 기준
정본 지정 — 같은 내용이 PDF와 위키와 슬라이드로 흩어져 있을 때 어느 것을 기준으로 삼을 것인가
이 판단은 도구가 대신해 주지 않아요. 문서를 소유한 조직과 합의해야 하는 영역이고, 실제 RAG 프로젝트에서 가장 오래 걸리는 부분도 보통 여기죠.
청킹: 검색 단위를 정하는 일
문서를 어떻게 자르느냐가 검색 품질을 크게 좌우해요. Dify에서 청크 최대 길이는 문자 수 기준으로 설정하고, 인접 청크 사이에 겹치는 구간을 두는 오버랩 설정도 함께 조정할 수 있죠. 겹침을 두는 이유가 곧 앞서 본 육아휴직 사례를 막기 위해서고요.
수치보다 먼저 잡아야 할 원칙이 하나 있어요. 청크는 물리적 길이가 아니라 의미가 끝나는 지점에서 잘려야 해요. 고정 길이로만 자르면 표가 중간에서 끊기고, 조항의 단서만 따로 떨어져 나가 본문 없이 컨텍스트에 들어가는 일이 생기죠. 규정 문서에서 특히 위험한데, "다만 다음의 경우는 예외로 한다"만 검색되면 모델은 예외를 원칙으로 답하니까요.
그래서 구조가 있는 문서는 구조를 따라가야 해요. 마크다운 헤딩, HTML 섹션, 계약서 조항 번호가 청킹 경계의 1순위 후보이고, Dify에서는 구분자를 지정해 이 경계를 잡을 수 있죠.
작게 자를수록 질의와 정확히 매칭되지만 맥락이 날아가고, 크게 자를수록 맥락은 살지만 검색 정확도가 떨어지는 딜레마가 여기서 생겨요. Dify의 부모-자식 청킹은 이 둘을 나눠서 처리하는 방식으로, 작은 자식 청크로 질의를 매칭하되 검색 결과로는 그 청크가 속한 부모 청크 전체를 돌려주죠. 규정이나 기술 매뉴얼처럼 앞뒤 맥락이 있어야 답이 되는 문서라면 이쪽이 안전하고요.
메타데이터: 온톨로지 대신 쓸 수 있는 것
Inmon은 텍스트 환경에 정형 데이터 모델 대신 온톨로지와 분류체계가 필요하다고 말해요. 방향은 맞지만, 전사 온톨로지 구축은 대기업에서도 몇 년이 걸리고 상당수가 완성되지 못한 채 흐지부지되죠. 그의 처방을 곧이곧대로 따르려다 아무것도 시작하지 못하는 조직이 나올 수 있다는 뜻이에요.
현실적인 대안은 문서 단위 메타데이터고요. 온톨로지의 완결성은 포기하되, 검색 시점에 필터로 쓸 최소한의 속성만 정의하는 방식이죠. Dify는 문자열, 숫자, 시간 세 가지 타입의 메타데이터를 지원하고 조건 간 AND/OR 조합도 가능하니, 이 정도만 잡아도 꽤 많은 게 통제돼요.
department— 소관 조직doc_type— 규정 / 매뉴얼 / 회의록 / 제안서effective_date— 유효 시작일status— 초안 / 승인 / 폐기access_level— 열람 권한 등급
다섯 개면 폐기 문서를 검색에서 빼고, 이번 분기에 유효한 정책만 조회하고, 사용자 권한 안에서만 결과를 돌려주는 일이 전부 가능해져요. 온톨로지가 주려던 가치의 상당 부분을 훨씬 싸게 확보하는 셈이죠.
메타데이터가 검색 품질만 건드리는 것도 아니고요. 어떤 답변이 어떤 상태의 어떤 문서에서 나왔는지 나중에 설명하려면 그 속성이 애초에 기록돼 있어야 하니, 감사 가능성의 토대이기도 해요.
검색과 리랭킹: 2차 선별
Inmon이 말한 두 번째 선별이 여기예요. 인덱싱된 것 전체에서 이번 질의에 필요한 것만 추려내는 단계죠.
하이브리드 검색은 거의 기본으로 깔고 가는 게 나아요. 벡터 검색만으로는 제품 코드나 조항 번호처럼 글자 그대로 맞아야 하는 토큰을 놓치는데, Dify는 벡터 검색과 전문 검색, 하이브리드 검색 중에서 고를 수 있고 가중치도 조정되죠. 사내 문서처럼 고유 용어가 많은 환경이라면 키워드 쪽 비중을 벡터와 대등하게 두는 편이 안정적이고요.
메타데이터 필터링은 검색 뒤가 아니라 앞에 둬요. 폐기 문서를 검색한 다음 걸러내는 것과 애초에 검색 대상에서 빼는 것은 결과도 비용도 다르니까요.
리랭킹은 1차 검색으로 후보를 넓게 가져온 뒤 상위 몇 개만 남기는 구조로 써요. 1차가 재현율을 맡고 2차가 정밀도를 맡는 분업인데, 여러 지식베이스를 함께 쓰는 앱이라면 각 지식베이스에서 나온 결과를 통합해 다시 정렬해야 하므로 사실상 필수에 가깝죠.
Top-K는 늘린다고 좋아지지 않아요. 관련 없는 청크가 컨텍스트에 섞이면 모델은 그것도 근거로 취급하죠. 토큰 비용은 K에 비례해서 늘지만 정확도는 어느 지점부터 정체하거나 오히려 떨어지고, 그 변곡점은 도메인마다 다르고요. 그래서 이건 감으로 정할 게 아니라 재서 정해야 하는 값인데, 이 이야기는 뒤에서 다시 할게요.
앱마다 지식베이스를 두면 벌어지는 일
Inmon의 글에서 가장 오래 남는 대목은 데이터 무결성 문제를 설명하는 부분이에요. 애플리케이션이 늘어나면서 같은 데이터가 여러 곳에 저장됐고 위치마다 값이 달라졌다는 것, 그래서 조직의 문제가 데이터를 갖는 것에서 어떤 데이터를 믿어야 하는지 판단하는 것으로 바뀌었다는 것. 그는 이 상태를 거미줄이라 부르면서, 애플리케이션과 기술을 더 얹는 걸로는 해결되지 않고 오히려 문제가 빨라진다고 썼죠. 필요한 건 기술적 수정이 아니라 아키텍처적 해결이었다는 게 그의 결론이고요.
1990년대에 쓰인 진단인데 지금 대부분의 조직에서 그대로 재현되고 있어요.
고객지원 봇이 자기 지식베이스를 만들어요. 사내 정책 Q&A 앱이 또 하나를 만들죠. 영업팀 제안서 도우미가 세 번째를 만들고요. 세 곳 모두에 같은 취업규칙 PDF가 들어가 있는데, 각각 다른 청킹 설정으로, 서로 다른 시점에 인덱싱되어 있어요. 그래서 같은 질문에 세 앱이 다른 답을 하죠.
원인을 찾기도 쉽지 않고요. 규정이 개정됐는데 한 곳만 재인덱싱됐을 수도 있고, 청크 경계가 달라서 한 곳에서는 단서 조항이 함께 검색되고 다른 곳에서는 잘렸을 수도 있죠. 어느 쪽이든 사용자 눈에는 "AI가 부정확하다"로 보이지만 실제 원인은 모델이 아니라 데이터 관리에 있어요.
Inmon이 물리적 중앙집중은 불가능해졌으니 의미론적 중앙집중으로 가야 한다고 말한 지점이 여기예요. 데이터가 여러 곳에 흩어져 있더라도 그게 무엇을 뜻하는지는 한 곳에서 관리돼야 한다는 거죠.
LLM 앱 환경으로 옮기면 결론은 하나로 모여요. 지식베이스는 앱의 소유물이 아니라 조직의 자산이어야 하죠. 앱마다 문서를 복제하는 대신 조직 단위로 지식베이스를 두고 앱이 그걸 참조하는 구조여야, 규정이 개정됐을 때 한 곳만 고치면 되고 청킹 설정이 하나뿐이니 답이 갈리지 않아요. Dify에서 지식베이스가 앱 바깥의 독립된 객체이고 하나의 지식베이스에 연결된 앱 목록을 지식베이스 쪽에서 확인할 수 있게 한 것도 같은 이유에서고요. 앱 안에 문서를 넣는 구조였다면 앱이 늘어나는 만큼 거미줄도 같이 늘어나죠.
6개월 뒤에 같은 답을 재현할 수 있을까요
거버넌스 조직 입장에서 이건 품질 문제가 아니라 규정 준수 문제예요.
금융이나 의료, 공공처럼 AI 답변이 업무 판단에 쓰이는 영역이라면 그 판단의 근거를 사후에 재구성할 수 있어야 하죠. 감사에서 요구하는 건 "AI가 그렇게 답했다"가 아니라 "어떤 문서의 어느 부분을 근거로 그렇게 답했고 그 문서는 당시 유효한 버전이었다"이니까요.
정형 데이터 파이프라인에서는 당연한 요구인데, 리트리벌 쪽으로 오면 다음 질문들에 답하지 못하는 조직이 많아요. 이 답변에 실제로 들어간 청크는 무엇인가. 그 청크의 출처 문서는 어느 버전이었나. 검색 후보 중 무엇이 탈락했고 왜인가. 그리고 이 답변을 6개월 뒤에 다시 만들어낼 수 있는가.
마지막 게 제일 까다롭죠. 지식베이스는 계속 갱신되니 문서 버전을 기록해 두지 않으면 같은 질문에 같은 답이 나온다는 보장이 없어요. 웨어하우스에서 스냅샷과 이력 테이블로 풀었던 문제가 리트리벌 계층에서 똑같이 반복되는 셈이고요.
도구가 할 수 있는 일은 여기서 분명해져요. 어떤 청크가 어떤 점수로 뽑혔는지 보이게 하고, 그 청크가 어느 문서에서 왔는지 따라갈 수 있게 하고, 문서 버전을 추적 가능하게 만드는 것. Dify가 검색 테스트에서 각 청크의 점수와 출처 문서를 함께 보여주고 설정을 바꿔가며 결과를 비교할 수 있게 한 것도 개발자 편의 기능이라기보다 이 요구에 대한 답에 가깝죠. 간접 통제는 통제점이 보일 때만 통제이고, 안 보이면 그냥 방치니까요.
아직 우리도 재보지 못한 것
여기까지가 설계 원칙인데, 솔직히 아직 숫자로 답하지 못하는 질문이 하나 있어요.
같은 문서를 다른 설정으로 인덱싱했을 때 답변은 실제로 얼마나 갈릴까요.
앞에서 이걸 문제라고 써놓긴 했지만 근거는 현장 관찰이지 측정값이 아니에요. 청크 길이를 절반으로 줄였을 때 동일 질의에 대한 답이 달라지는 비율이 몇 퍼센트인지, 그중에서 표현만 다른 게 아니라 결론이 실제로 반대인 경우가 얼마나 되는지, 우리도 체계적으로 재보지 않았죠. 업계 전반에도 이 수치는 거의 공개돼 있지 않고요.
Inmon이 말한 비용 절감 효과도 마찬가지예요. 불필요한 텍스트를 걷어내면 쿼리마다 비용이 준다는 건 방향으로는 자명하지만, 실제 절감폭은 도메인과 설정에 따라 달라지죠.
그래서 숫자를 지어내는 대신 재는 방법을 공개할게요. 아래 프로토콜은 각자의 데이터로 그대로 돌려볼 수 있게 짰어요. 남의 벤치마크보다 자기 도메인에서 나온 수치가 언제나 더 쓸모 있고, 우리도 같은 방식으로 측정을 진행 중이라 결과는 후속 글에서 정리할 예정이고요.
부록: 리트리벌 설정 평가 프로토콜
준비 [평가 질의 세트]
실제 사용 로그에서 최소 50개를 뽑되 다음 유형이 고르게 섞이도록 해요.
단일 문서로 답이 되는 질의
여러 문서를 종합해야 하는 질의
예외나 단서 조항이 답의 핵심인 질의
지식베이스에 답이 없는 질의 (거절하는지 보려고)
시점에 따라 답이 달라지는 질의 (버전 처리를 보려고)
질의마다 정답 근거 문서와 해당 구간을 사람이 미리 지정해 둬요. 이 작업이 전체 공수의 절반을 넘지만 생략하면 이후 측정이 전부 무의미해지죠.
축 1 [비용]
청크 길이와 Top-K 조합별로 쿼리당 평균 입력 토큰을 기록해요.
청크 길이 | Top-K | 평균 입력 토큰 | 쿼리당 비용 | 정답 근거 포함률 |
|---|---|---|---|---|
500자 | 3 | 1,240 | $0.0037 | 68% |
500자 | 5 | 2,050 | $0.0062 | 84% |
1,000자 | 3 | 2,380 | $0.0071 | 89% |
1,000자 | 5 | 3,910 | $0.0117 | 91% |
정답 근거 포함률은 사람이 지정해 둔 근거 구간이 실제로 컨텍스트에 들어간 비율이에요. 비용만 보면 언제나 작은 쪽이 유리하니 이 열이 없으면 표가 의미를 잃죠.
축 2 [정확도]
같은 질의 세트로 설정을 바꿔가며 답변을 만들고 채점해요.
정답률 — 근거에 부합하는 답변 비율
환각률 — 근거에 없는 내용을 단정한 비율
적절한 거절률 — 답이 없는 질의에 모른다고 답한 비율
비교할 조합은 최소 네 가지를 권해요. 벡터 검색만 / 하이브리드 검색 / 하이브리드 + 리랭킹 / 하이브리드 + 리랭킹 + 메타데이터 필터.
채점은 사람이 하는 게 정확하지만 규모가 커지면 LLM 채점으로 대체할 수 있는데, 이 경우 전체의 10~20%를 사람이 교차 검증해서 채점 신뢰도를 함께 보고해요.
축 3 [일관성]
본문에서 제기한 거미줄 문제를 숫자로 바꾸는 부분이에요.
같은 문서 집합을 서로 다른 설정으로 인덱싱해 지식베이스 A와 B를 만들어요
동일한 질의 세트를 양쪽에 던져요
답변 쌍을 세 범주로 나눠요 — 동일(표현만 다름) / 부분 상이(정보 누락은 있으나 모순은 아님) / 모순(결론이 다름)
모순 비율이 이 측정의 핵심 지표죠. 이 수치가 유의미하게 나온다면 앱마다 지식베이스를 따로 두는 구조가 실제로 답변 불일치를 만들고 있다는 증거가 돼요.
보고할 때 함께 밝힐 것
문서 집합의 규모와 도메인, 임베딩 모델과 리랭커 모델, 생성 모델과 온도 설정, 질의 세트 구성 비율, 채점 방식과 채점자 신뢰도. 이게 빠지면 재현이 안 되죠.
정리하자면 Inmon이 말한 간접 통제는 결국 이런 뜻이 돼요. 모델을 못 고치니 입력을 고쳐야 하는데, 입력을 고치려면 먼저 입력이 어떻게 정해지는지 보여야 한다는 것. 청킹 설정 하나, 메타데이터 필드 하나, Top-K 값 하나가 답변을 바꾸는 판단이라면 그 판단은 코드 여기저기에 흩어져 있을 게 아니라 한자리에 모여서 눈에 보여야 하죠. 그러고 나서야 재보고 고칠 수 있으니까요.
물론 여기까지가 도구가 할 수 있는 일의 끝이에요. 어떤 문서를 정본으로 삼을지, 폐기된 규정을 누가 폐기 처리할지, 부서마다 다르게 쓰는 용어를 어떻게 맞출지는 도구가 대신 정해주지 않죠. Inmon이 전사 논리 데이터 모델을 이야기하면서 CDO라는 자리의 필요성을 함께 말한 것도 그래서일 텐데, 40년 전 데이터 무결성 문제가 조직의 합의로만 풀렸던 것처럼 이번에도 결국 같은 순서를 밟게 될 것 같아요. 다만 그때와 달라진 게 하나 있다면, 이제는 그 합의가 지켜지고 있는지를 파이프라인에서 확인할 수 있다는 점이고요.
오픈네트웍시스템 ㅣ 권태규