답을 잘하는 비결은 모델이 아니다: 내 데이터로 추론하는 법

네 데이터에 기반한 인공지능, 인터넷 지식이 아니라 네 계약서와 정책과 회의록을 근거로 답하는 시스템을 만들고 싶다면, 모델부터 고르지 않는 편이 낫다. 네 자료가 어떤 모양인지, 사람들이 어떤 질문을 던지는지부터 보면 구조는 대부분 정해진다.

한 줄로 말하면 이렇다. 비결은 똑똑한 모델이 아니라, 질문에 맞는 증거를 잘 찾아서 모델 앞에 올려놓는 일이다. 그래서 이 글의 중심은 '답을 만드는 법'이 아니라 '자료를 정리하고, 찾고, 검증하는 법'이다.

나는 이 주제를 고유 데이터 기반 생성 시스템 설계 보고서로 먼저 정리했다. 아래는 그 보고서를 바탕으로, 이 글 하나만 읽어도 시스템을 설계할 수 있게 풀어 쓴 글이다. 표와 수치는 보고서와 같고, 설계할 때 어디에 손을 대야 하는지를 더 자세히 적었다. 원본이 필요하면 언제든 보고서 PDF를 내려받으면 된다.

질문에 답하기 전에, 책상 위에 근거가 될 자료를 먼저 골라 놓는다

도서관으로 보면 네 단계다

고유 데이터로 답하는 시스템은 도서관과 같다.

자료를 검색하기 좋게 잘게 나누는 일을 청킹(Chunking) 이라고 한다. 책을 쪽 단위로 나누는 일이다. 나눈 조각에 '의미의 좌표'를 붙여 비슷한 내용을 찾게 만드는 일이 임베딩(Embedding) 이다. 주제에 분류 번호를 붙이는 일과 같다. 질문이 오면 관련 조각을 꺼내 오는 일이 검색(Retrieval) 이고, 꺼내 온 조각을 읽고 답을 쓰는 일이 생성(Generation) 이다.

이 네 단계를 합친 가장 기본적인 방식을 검색 증강 생성(Retrieval-Augmented Generation, RAG) 이라고 부른다. 검색으로 재료를 보강한 뒤 답을 생성한다는 뜻이다. 문제는 단순하다. 네 단계 중 하나라도 부실하면, 마지막 답이 통째로 틀린다.

나누고, 좌표를 붙이고, 찾아오고, 답을 쓴다. 네 단계 중 하나라도 부실하면 답이 통째로 틀린다

자주 나오는 용어만 먼저 풀어 둔다. 토큰(Token) 은 AI가 글을 읽는 최소 단위다. 한국어 한 글자는 보통 1–2개 토큰이다. 비용과 분량은 토큰 수로 센다. 벡터(Vector) 는 글의 의미를 숫자 배열로 바꾼 것이고, 벡터 데이터베이스(Vector Database) 는 그 숫자로 '의미가 비슷한 글'을 빠르게 찾아 주는 저장소다. 키워드 검색(BM25) 은 단어가 실제로 등장하는지를 따진다. 이름이나 제품 코드처럼 정확한 단어가 중요할 때 강하다. 하이브리드 검색(Hybrid Search) 은 의미 검색과 키워드 검색을 함께 쓰는 방식이다. 재정렬(Reranking) 은 넓게 찾은 후보를 질문과 하나씩 대조해 순위를 다시 매기는 일이다. 환각(Hallucination) 은 근거 없이 그럴듯한 내용을 지어내는 현상이다.

나머지 용어는 나올 때마다 그 자리에서 풀겠다.

왜 기본 검색 증강 생성은 쉽게 깨지는가

인터넷 강좌의 기본형은 하루면 시범용으로 만들 수 있다. 문서를 모으고, 일정 크기로 자르고, 의미 좌표를 붙여 저장한 뒤, 질문과 비슷한 조각을 찾아 AI에게 주고 답을 쓰게 한다.

실제 업무에 붙이면 답이 자주 어긋난다. 이 방식은 하나의 기술이 아니라 여섯 단계가 이어진 작업 흐름이기 때문이다. 최종 품질은 가장 약한 단계가 결정한다.

실패를 '모델이 부족해서'라고 보면 해결책이 모델 교체밖에 남지 않는다. 실제로는 답을 쓰기 훨씬 전, 자료를 해석하고 나누고 저장하는 단계에서 이미 정해지는 경우가 많다.

조각을 자르는 순간 정보가 사라진다

조각은 검색의 단위다. 경계를 잘못 자르면, 그 정보는 어떤 좋은 검색 기술을 써도 찾을 수 없다. 문맥이 사라지는 방식은 여섯 가지다.

가리키는 대상이 빠진다. '이 회사', '해당 기술', '그 계획'만 남으면 무엇에 대한 얘기인지 알 수 없다. 글의 구조가 빠진다. 제목과 본문, 본문과 부록이 떨어지면 그 글이 문서에서 어떤 역할인지 모른다. 표의 맥락이 빠진다. 데이터 행과 열 제목이 떨어지면 숫자가 엉뚱한 항목에 붙는다. 원인과 결과가 갈라진다. 시간은 옛 계획과 바뀐 계획을 떨어뜨리고, 논리의 연결은 주장과 근거, 예외 조건을 떼어 놓는다.

계약서가 좋은 예다. 4조에는 '고객은 매달 일정 금액을 낸다'고 되어 있고, 9조에는 '예외적으로 환불되는 조건'이 있다. '환불이 되나요?'라는 질문에 4조만 찾아오면 잘못된 결론이 나온다. 조각 하나를 찾았다는 것과, 답에 필요한 증거를 충분히 찾았다는 것은 전혀 다른 일이다.

점검법은 한 문장이다. 사람이 그 조각만 읽고 무슨 말인지 알 수 없으면, AI도 알 수 없다.

질문 종류가 안 맞으면 구조부터 틀린다

기본 검색 방식은 '답이 문서 어딘가 한 곳에 들어 있는' 질문에 강하다. 다음 세 종류는 구조적으로 약하다.

전역 질문(Global Question) 은 '이 자료 전체에서 반복되는 주제는?'처럼 모든 문서를 훑어야 한다. 조각 몇 개만 가져오는 구조로는 답할 수 없다. 다중 홉 질문(Multi-hop Question) 은 'A 프로젝트 담당자가 이전에 맡았던 고객사는?'처럼 사실을 여러 번 연결해야 한다. 집계·계산 질문(Aggregation) 은 '지난 분기 계약은 몇 건인가?'처럼 세거나 합산해야 한다. 이것은 검색이 아니라 데이터베이스 질의의 영역이다.

숫자 질문을 검색으로 풀려고 하면, 설계가 그 지점에서 이미 틀린다.

방법론보다 먼저: 여덟 가지 질문

구조를 고르기 전에 내 자료와 내 질문을 살펴봐야 한다. 아래 여덟 가지에 답하면 선택지는 대부분 좁혀진다.

질문 종류를 나눠 보는 표도 설계 메모로 써 두면 좋다.

방법론 이름보다 자료의 크기, 질문의 종류, 숫자의 유무부터 묻는다

평가 집합(Evaluation Set)이 출발점이다

가장 먼저 할 일은 기술 선택이 아니다. 실제 사용자가 던질 질문 50–100개와, 각 질문의 정답이 어느 문서 어디에 있는지를 모아 두는 일 이다. 이것이 평가 집합이다. 조각 크기, 검색 방식, 재정렬 사용 여부를 감이 아니라 숫자로 비교하려면 이게 있어야 한다.

쉬운 질문만 넣으면 점수가 거짓말을 한다. 답이 자료에 없는 질문, 연결형 질문, 최신 정보 질문, 제품 번호처럼 정확한 단어를 찾아야 하는 질문도 반드시 섞어야 한다.

평가 집합을 만들 때는 질문마다 네 칸만 채우면 된다. 질문 문장, 정답이 들어 있는 문서와 위치, 질문 종류, 답이 자료에 있는지 없는지. 이 네 칸이 있으면 나중에 '찾기를 실패한 것인지, 찾았는데 답을 잘못 쓴 것인지'를 나눌 수 있다.

자료 준비에서 품질의 70%가 갈린다

쓰레기가 들어가면 검색도 쓰레기다

PDF, 스캔, 표, 발표 자료는 구조를 살려 읽는 전용 도구를 쓴다. 표는 글로 뭉개지 말고 열 제목과 행의 구조를 유지한다. 웹 문서와 마크다운은 제목의 상하 관계를 정보로 보존한다. 이 제목 경로가 나중에 조각의 문맥을 되살리는 가장 값싼 재료가 된다.

중복 문서, 옛 판본, 초안은 지우거나 판본 정보를 붙인다. 같은 정책의 옛 판본과 새 판본이 함께 들어가면 AI는 둘을 섞어 답한다.

모든 조각에는 최소한의 메타데이터를 붙인다. 출처 문서, 위치(절·쪽), 만든 날짜와 고친 날짜, 소유자, 볼 수 있는 사람의 범위, 문서 종류. 원본 파일, 뽑아낸 글, 표 구조, 원본에서의 위치를 서로 연결해 보관하지 않으면 나중에 출처를 댈 수 없다.

자료 종류마다 따로 챙길 것도 다르다. 발표 자료는 슬라이드와 발표자 메모를 연결해야 하고, 이메일은 보낸 사람·받는 사람·답장 흐름·날짜가 문맥이다. 회의 녹취는 말한 사람, 시간, 논의·결정·할 일을 구분해야 조각이 살아난다.

나누기에는 정답이 없고, 자료별 기본값이 있다

연구들이 공통으로 말하는 교훈은 두 가지다. 똑똑해 보이는 나누기 방법이 항상 이기지는 않는다. 그리고 조각이 너무 작으면 관련 조각을 찾아내는 비율은 올라가도, 정작 답을 만들 문맥이 부족해진다. 많이 찾았는데 답은 틀리는 함정이다.

실무에서 검증이 많이 된 출발점은 구조를 따라 재귀적으로 나누기(Recursive Chunking) 다. 문단, 그다음 문장, 그다음 단어 순으로 자연스러운 경계를 우선해 자른다. 크기는 약 512 토큰, 이웃 조각과 10–20%를 겹치게 두는 것이 기본값이다.

여기에 두 기법을 더하면 기본형이 된다.

부모-자식 나누기(Parent-Child Chunking) 는 작은 자식 조각으로 정확히 찾되, 답을 만들 때는 그 조각이 속한 부모 절 전체를 보낸다. 찾는 단위와 읽는 단위를 나누면 정확함과 문맥을 동시에 얻을 수 있다. 시작점으로는 검색용 조각 300–600 토큰, 부모 문맥 1,500–3,000 토큰을 비교해 볼 수 있다. 누구에게나 맞는 숫자는 아니므로 내 평가 집합으로 확인해야 한다.

늦은 나누기(Late Chunking) 는 순서를 뒤집는다. 먼저 문서 전체를 읽어 글자 하나하나의 의미 표현을 만든 뒤, 그다음에 조각 경계로 나눈다. 각 조각에 문서 전체의 문맥이 스며들어, 다른 곳에서 설명된 대상을 가리키는 조각도 잘 찾아진다. AI를 불러 설명문을 만들 필요가 없어 비용이 들지 않는다. 대신 문서 길이가 임베딩 모델이 한 번에 읽을 수 있는 한도, 예를 들어 8,192 토큰을 넘으면 쓸 수 없다.

저장은 한 번 잘못하면 전부 다시 만든다

임베딩 모델을 바꾸면 숫자 공간 자체가 달라져 전부 다시 만들어야 한다. 모델 이름과 판본을 조각마다 기록하고, 바꿀 때는 새것과 옛것을 함께 쓰는 전환 계획을 세운다. 바뀌지 않은 조각은 내용과 모델 판본으로 만든 지문을 열쇠로 써서 건너뛴다.

의미 검색용과 키워드 검색용, 두 가지를 모두 만든다. 나중에 검색 단계에서 보완할 수 없기 때문이다. 권한과 날짜, 부서, 접근 등급 같은 걸러내기용 정보는 저장할 때 넣는다. 검색한 뒤에 걸러내는 방식은 보안과 정확함 모두에서 실패한다.

한국어는 조사부터 다르다

한국어는 단어 뒤에 조사와 어미가 붙는다. '계약서를'과 '계약서'를 컴퓨터는 다른 단어로 볼 수 있다. 키워드 검색에는 말을 최소 단위로 쪼개는 형태소 분석(Morphological Analysis)이 필요하다. 노리(Nori), 키위(Kiwi), 메캡(MeCab) 같은 도구가 이 일을 한다. 어떤 분석기를 고르느냐가 검색 정확도에 직접 영향을 준다.

임베딩 모델의 한국어 실력은 영어 시험 성적과 다를 수 있다. 반드시 내 자료로 직접 비교해야 한다. 한·영이 섞인 자료라면 한국어 질문-한국어 문서, 영어 질문-영어 문서, 한국어 질문-영어 문서, 그리고 회사 줄임말·사람 이름·제품 번호처럼 정확한 단어 찾기를 모두 시험한다.

찾기: 실패 종류마다 막는 층을 둔다

조각이 스스로를 설명하게 하기

앤트로픽이 2024년 9월 발표한 문맥 기반 검색(Contextual Retrieval) 은 나누기의 문맥 손실을 저장하는 시점에 정면으로 해결한다. 문서를 조각으로 나눈 뒤, 조각마다 작은 AI에게 원문 전체와 그 조각을 함께 주고, 이 조각이 문서 안에서 무엇을 설명하는지를 50–100 토큰의 짧은 설명으로 쓰게 한다. 그 설명을 조각 앞에 붙인 글로 의미 검색용 저장소와 키워드 검색용 저장소를 모두 만든다.

원래 조각이 '매출이 전 분기 대비 3% 늘었다'뿐이라면, 앞에 이런 설명이 붙는다. '이 내용은 ACME 사의 2023년 2분기 실적 공시의 일부이며, 전 분기 매출은 3억 1,400만 달러였다.' 이제 이 조각은 스스로를 설명하므로, 'ACME 2분기 매출'이라는 질문에도 걸린다.

문서 요약 한 덩어리를 모든 조각에 붙이는 방식은 효과가 제한적이었다. 조각마다 맞춤 설명을 다는 것이 핵심이다. 다른 문서에서만 뜻이 정해지는 용어가 있다면 용어집을 설명 생성 지시에 넣는다. 생성된 설명은 파생 자료다. 원문과 설명은 따로 보관하고, 답변의 출처 표시는 반드시 원문으로 연결해야 한다.

비용은 저장할 때 한 번만 낸다. 문서 전체를 한 번 올려 두고 조각마다 재사용하면, 발표 당시 기준으로 문서 100만 토큰당 약 1.02달러로 추산됐다.

앤트로픽이 여러 분야 자료로 측정한 '검색 실패율'은 정답 조각이 상위 20개 안에 아예 없는 비율이다.

어느 한 기술이 혼자 다 해결하지 않는다. 문맥 붙이기는 한 종류의 실패를, 키워드 검색 추가는 또 다른 종류를, 재정렬은 또 다른 종류의 실패를 막는다. 검색 품질은 하나의 비법이 아니라, 서로 다른 실패를 하나씩 막는 층을 쌓아서 만든다.

이 수치는 앤트로픽의 시험 자료 기준이다. 검색 실패가 67% 줄었다는 뜻이지, 답변 정확도가 67% 올랐다는 뜻이 아니다. 내 자료에서의 효과는 내 평가 집합으로 다시 재야 한다.

두 검색을 합친 뒤, 다시 골라 낸다

의미 검색과 키워드 검색은 점수 체계가 달라 그대로 더하면 한쪽 점수만 살아남는다. 점수가 아니라 순위를 기준으로 합치는 상호 순위 결합(Reciprocal Rank Fusion, RRF) 을 표준으로 쓴다.

실무 기본 흐름은 이렇다. 넓게 약 150개를 뽑아 관련 있는 것을 놓치지 않고, 재정렬로 20개로 좁혀 정확도를 높인다. 재정렬 도구는 질문과 조각을 쌍으로 함께 읽고 관련도를 다시 매긴다. 미리 계산해 둔 숫자끼리 비교하는 것보다 비용은 더 들지만 훨씬 정확하다. 그래서 역할이 나뉜다. 검색은 넓게 찾고, 재정렬은 정확하게 줄인다.

앤트로픽 실험에서는 최종적으로 상위 20개를 AI에게 보내는 구성이 5개나 10개보다 효과적이었다. 너무 많으면 AI가 산만해질 수 있어 직접 평가해야 한다.

질문도 문서처럼 다듬는다

검색 실패의 절반은 문서가 아니라 질문 쪽 문제다. 아래 기술은 저장소를 건드리지 않아 도입이 빠르다.

앞 대화에 기대는 질문('그건 얼마야?')은 혼자서도 뜻이 통하는 검색 질문으로 다시 쓴다. 여러 면을 가진 질문은 표현을 여러 개로 늘려 각각 검색하고 결과를 합친다. 가상 답안(HyDE) 은 AI가 먼저 모범 답안 같은 글을 쓰고 그 글로 검색한다. 답안은 문서와 문체가 비슷해, 질문보다 목표 문서에 가까워지는 경우가 많다. 'A와 B를 비교하라'는 A 찾기와 B 찾기로 쪼갠다. 날짜, 부서, 문서 종류 같은 조건은 질문에서 뽑아 검색 범위부터 좁힌다.

찾기 실패가 많을 때 저장소를 손대기 전에, 이 질문 쪽 기술부터 붙여 보는 것이 가장 싸다.

답 쓰기: 찾은 증거를 답으로 바꾸는 규칙

검색이 좋아도 답을 쓰는 지시가 허술하면 지어낸 답이 돌아온다. 최소 규칙은 이렇다.

제공된 자료만으로 답하고, 없으면 모른다고 답하게 한다. 이 지시만으로 환각이 사라지지는 않으므로 출처 검증과 짝을 이뤄야 한다. 주장마다 출처 조각을 표시하게 하고, 답이 만들어진 뒤 그 출처가 실제로 그 주장을 뒷받침하는지 자동으로 검사한다. 겉보기에만 출처가 있는 경우를 잡기 위해서다.

무조건 많은 문서를 넘기지 말고, 검증할 수 있는 원문, 문서 이름·판본·쪽, 적용되는 시간 범위, 발견된 관계, 문서끼리 어긋나는 점까지 묶어 보낸다. 가장 관련 높은 조각을 앞과 뒤에 두고, 중복은 지운다. 같은 문서의 조각은 원래 순서대로 정렬하면 이야기의 흐름이 살아난다. 중간에 묻힌 정보는 놓치기 쉽다.

조각 전체 대신 질문에 답하는 문장만 뽑아 보내면 토큰 비용을 30–60% 줄일 수 있다. 다만 압축 과정 자체가 정보를 잃을 수 있어 평가로 확인해야 한다.

관련도가 기준 아래면 추측 대신 '자료에서 찾지 못했다'고 답하고, 어떤 자료를 찾았는지 보여 주는 것이 신뢰를 지킨다. AI가 스스로 매긴 확신 점수를 정확도의 증거로 삼아서는 안 된다. 원문에 있는 사실과, 그로부터 이끌어 낸 추론은 답 안에서 구분해 표시하게 한다.

여러 문서를 연결해야 할 때

마이크로소프트 리서치가 제안한 그래프 검색 증강 생성(GraphRAG) 은 저장하는 단계에서 AI가 문서 전체에서 대상과 관계를 뽑아 지식 그래프를 만들고, 서로 가깝게 연결된 대상 묶음마다 요약을 미리 만들어 둔다.

특정 대상 주변을 살펴 세부 질문에 답하는 지역 검색(Local Search), 커뮤니티 요약을 나눠 읽고 합치는 전역 검색(Global Search), 전체 맥락에서 시작해 점점 구체적인 후속 검색으로 좁혀 가는 드리프트 검색(Drift Search)이 있다. 강점은 다중 홉 질문과 전체 요약에서 평면적인 조각 검색과 격차가 벌어진다는 점이다. 그래프의 경로를 따라가므로 답의 근거를 구조적으로 추적할 수도 있다.

대가도 분명하다. 그래프를 만드는 비용이 기본 방식의 3–5배 수준이고, 같은 대상의 다른 표기('삼성전자'와 'Samsung')를 하나의 점으로 합치는 일의 품질이 전체 품질을 좌우한다. 단순한 사실 찾기가 대부분인 시스템에 도입하면 비용만 는다.

이름만 같은 변종도 여럿이다. 레이지그래프RAG(LazyGraphRAG)는 미리 요약 만들기를 질문 시점으로 미뤄 저장 비용을 크게 줄인다. 라이트RAG(LightRAG)는 새 자료를 덧붙이기 쉽다. 히포RAG(HippoRAG)는 다중 홉에 강하고 보내는 글이 짧다. 랩터(RAPTOR)는 조각을 묶어 요약하기를 반복해 아래에서 위로 요약 나무를 만든다. 도입을 검토할 때는 어떤 변종인지부터 확인해야 한다.

ICLR 2026의 GraphRAG-Bench 연구가 가장 균형 잡힌 판단 근거를 준다. 단순한 사실 찾기는 기본 방식이 같거나 더 낫다. 그래프가 관련은 있지만 필요 없는 정보까지 끌어와 답의 품질을 떨어뜨리기 때문이다. 앞선 연구에서는 그래프 방식이 일반 질의응답에서 기본 방식보다 정확도가 13.4% 낮았다. 복잡한 추론과 맥락 요약에서는 그래프가 확실히 앞선다. 다만 마이크로소프트 그래프RAG의 전역 검색은 질문당 문맥이 수만 토큰까지 커질 수 있다. 많이 가져오는 것이 곧 잡음이다.

이미 구조가 있는 자료는 AI로 뽑지 말고 직접 넣는다. 조직도, 고객-계약-담당자 관계, 프로젝트 이력처럼 틀이 명확한 자료는 그래프 데이터베이스에 직접 넣고 질의하는 편이 정확하고 저렴하다. 관계에도 출처와 유효 기간이 필요하다. '과거에 담당했던 프로젝트를 지금도 담당한다'고 답하는 일을 막기 위해서다.

그래프는 기본 방식을 대체하기보다 보완한다. 한 곳에서 찾는 질문은 하이브리드 검색으로, 연결·전역 질문만 그래프 경로로 보내는 길 나누기(Routing)가 현실적이다.

넣을 때 미리 정리하기

안드레이 카르파티가 제안한 LLM Wiki 는 방향이 정반대다. 질문이 올 때마다 원본 조각을 뒤지는 대신, 자료를 넣는 시점에 AI가 원본을 읽고 사람이 읽을 수 있는 마크다운 위키로 미리 정리해 둔다.

원본 층은 AI가 읽기만 하고 절대 고치지 않는다. 위키 층은 AI가 쓰고 유지하는 페이지이며, 모든 페이지에 원본 출처 연결이 필수다. 목차는 질문이 오면 AI가 가장 먼저 읽는 지도다. 수집, 질의, 점검이 순환한다. 새 자료를 넣으면 관련 페이지 10–15개를 고치고, 질문은 목차를 먼저 읽은 뒤 필요한 페이지만 열어 답하며, 좋은 답변은 다시 위키로 쌓인다. 점검은 페이지끼리 어긋나는 내용, 낡은 주장, 연결되지 않는 페이지를 주기적으로 찾아낸다.

핵심 차이는 정리 비용을 언제 치르느냐다. 기본 방식은 질문할 때마다 조각을 찾아 매번 다시 종합한다. 위키는 넣을 때 한 번 깊게 읽고, 서로 참조하게 하고, 어긋나는 내용까지 정리해 둔다. 원본이 자주 바뀌면 필요할 때 찾기가, 지식이 쌓이고 재사용될수록 미리 정리하기가 유리하다.

한계도 분명하다. 실무 보고로는 단일 주제 100–400개 문서, 약 40만 단어 수준이 상한이다. 그 이상이면 목차만으로 탐색하기 어려워져 검색 도구가 다시 필요하다. AI가 잘못 연결한 관계가 위키에 남으면 이후 모든 답변에 영향을 준다. 원본 불변 원칙, 출처 연결, 판본 기록, 정기 점검이 안전장치다.

그래서 두 층을 나눠야 안전하다. 증거 층(Evidence Layer) 은 실제 원본 문서와 기록이다. 사실 확인의 기본 근거다. 지식 층(Knowledge Layer) 은 위키, 그래프, 요약, 임베딩이다. 찾기와 추론을 돕는 파생 지식이다. 위키와 그래프는 유용한 미리 만들어 둔 보기이지만, 원본의 권위를 자동으로 물려받지는 않는다. AI가 쓴 위키 내용을 다시 AI가 아무 검증 없이 사실로 쓰는 순환은 특히 위험하다.

검색 자체를 건너뛰는 길

자료가 작으면 통째로 넣고, 크면 에이전트가 도구로 필요한 만큼 찾아 읽게 할 수도 있다. 다만 어느 쪽이든 'AI에게 무엇을 보여 줄지 고르는 문제'는 사라지지 않는다.

앤트로픽은 지식 자료가 20만 토큰, 책으로 치면 약 500쪽 미만이면 검색 시스템을 만들지 말고 전체를 프롬프트에 넣으라고 권했다. 프롬프트 캐싱(Prompt Caching)을 쓰면 반복 질문의 대기 시간은 절반 이하로, 비용은 최대 90%까지 줄어든다. 학계에서는 이를 캐시 증강 생성(Cache-Augmented Generation, CAG) 으로 정리했다. 단점은 자료가 바뀔 때마다 캐시를 다시 만들어야 하고, 첫 요청 비용이 크다는 점이다.

그렇다고 길수록 좋은 것은 아니다. 크로마가 2025년 7월 발표한 문맥 부패(Context Rot) 연구는, 18개 최신 모델 모두가 입력이 길어질수록 성능이 떨어진다는 것을 보였다. 숨은 바늘 찾기(Needle in a Haystack) 같은 단순 시험에서는 거의 만점이지만, 비슷하지만 틀린 방해 정보가 섞이거나 의미를 이해해야 하면 길이에 따라 정확도가 내려간다. 긴 문맥의 중간에 묻힌 정보는 놓치기 쉽다는 중간 소실(Lost in the Middle) 도 같은 종류의 문제다. 넣을 수 있다는 것과 잘 쓴다는 것은 다르다.

에이전트형 검색(Agentic Retrieval)은 자료를 미리 다 처리하지 않고, 파일 경로나 연결 주소 같은 가벼운 참조만 들고 있다가 도구로 필요한 부분만 불러온다. 클로드 코드가 초기의 지역 벡터 저장소를 이 방식으로 바꾼 이유가 여기에 있다. 최신성과 보안에서는 유리하지만, 미리 계산된 검색보다 느리고, 같은 탐색을 매번 반복하며, 멈추는 조건을 설계하지 않으면 무한 반복에 빠진다. 쉬운 질문은 고정 흐름으로, 어려운 질문만 에이전트 경로로 보내는 적응형 길 나누기(Adaptive Routing)가 균형점이다.

모델 컨텍스트 프로토콜(Model Context Protocol, MCP)은 구글 드라이브, 고객 관리 시스템, 사내 데이터베이스 같은 원본을 에이전트의 도구로 노출한다. 자료를 별도 저장소로 복사하지 않아도 늘 최신이고, 원본의 권한 체계를 그대로 쓸 수 있다. 반대로 원본 시스템의 검색 품질과 호출 속도 제한에 그대로 묶인다. 자주 묻는 핵심 자료는 별도 저장소나 위키로 정리해 두는 혼합 구성이 현실적이다.

줄글이 아닌 자료

내 데이터가 줄글만은 아니다.

발표 자료나 스캔 문서에서 가장 큰 손실은 그림을 글자로 옮기는 단계에서 일어난다. 콜팔리(ColPali) 같은 페이지 그림 기반 검색은 그 단계를 건너뛰고, 문서 쪽 전체를 그림으로 보고 그림 자체의 의미로 찾는다. 대가는 쪽마다 벡터가 많아 저장 공간이 크다는 점이다. 문서가 적으면 그림을 볼 수 있는 모델에게 쪽 그림을 직접 보내는 편이 더 단순할 수 있다.

가격, 재고, 일정, 수치 합계처럼 이미 표 형태로 있는 자료는 조각으로 쪼개는 순간 정확도를 잃는다. '지난달 지역별 매출 합계'는 의미 검색이 아니라 데이터베이스 질의(SQL) 로 답해야 한다. 읽기만 가능한 계정을 쓰고, '매출' 같은 지표의 정의를 미리 정리한 층을 두고, AI가 만든 질의를 실행 전에 검증한다.

말투, 답변 형식, 분류 기준처럼 '사실이 아니라 방식'의 문제는 미세 조정(Fine-tuning) 이 이긴다. 매주 바뀌는 사실을 외우게 하면, 고칠 수 없고 출처를 댈 수 없고 사람별 권한을 적용할 수 없는 낡은 지식이 된다. 역할은 한 문장이다. 검색은 지식을 주고, 미세 조정은 행동을 다듬으며, 긴 문맥은 작업 기억이다.

권장 구조: 네 층과 질문 길잡이

대부분의 실용적인 시스템에는 처음부터 전면적인 그래프를 넣기보다, 단계적으로 확장하는 설계를 권한다. 핵심은 저장소를 여러 개 쓰는 것이 아니라, 원본·검색용 정리·관계 지식·종합 지식을 서로 분리해 관리하는 것이다.

원본 증거, 검색 가능 지식, 구조화 지식, 종합 지식을 같은 층에 섞지 않는다

1층은 원본 증거다. 문서를 바꾸지 않고 보관하는 원본 서류함이다. 2층은 검색 가능 지식이다. 조각, 임베딩, 키워드 색인, 메타데이터다. 3층은 구조화 지식이다. 대상, 관계, 주장, 시간 정보다. 4층은 종합 지식이다. 위키, 주제별 요약, 비교 보고서다.

질문마다 길을 나눈다. 특정 계약의 해지 조건은 하이브리드 검색과 부모-자식으로 조항·예외·원문을 함께 확보한다. 모든 프로젝트의 공통 실패 원인은 그래프 전역 검색이나 위키 요약 층으로 보낸다. 지난 분기 매출 합계는 데이터베이스 질의로 보낸다. 보고서 한 건을 처음부터 끝까지 평가하는 일은 긴 문맥이 맞다. 두 회사의 관계와 관련 쟁점은 그래프로 찾고 원문으로 확인한다. 종합 보고서를 쓰라는 요청은 에이전트형 탐색으로 보낸다.

하나의 질문에 여러 길을 동시에 쓰는 경우도 많다. 그래프로 관계를 찾고, 그 관계에 연결된 계약 원문을 하이브리드 검색으로 확인한 뒤, 금액은 데이터베이스 질의로 검증하는 식이다.

한 문장으로 정리하면 이렇다. 문서형 자료는 미리 정리해 두고, 데이터베이스와 업무 앱은 원본을 그때그때 조회하며, 에이전트가 질문 종류에 맞는 도구를 골라 근거를 모은 뒤 출처와 함께 답한다.

작게 시작할 때는 원문 저장은 파일 저장 공간, 메타데이터와 관계는 PostgreSQL, 의미 검색은 pgvector, 키워드 검색은 PostgreSQL 전체 글 검색으로 충분하다. 그래프도 처음부터 전용 데이터베이스가 필요하지 않다. 관계의 양과 탐색 깊이가 작으면 관계 표로 시작하고, 질의가 복잡해질 때 옮기면 된다. 한국어는 엘라스틱서치(Elasticsearch)의 노리처럼 형태소 분석과 사용자 정의 사전을 지원하는 도구가 유리하다.

오늘 이 글만으로 설계하려면

가상의 팀 하나를 놓고 따라가 보자. 정책 문서, 계약서, 회의록, 매출 표가 섞여 있고, 질문은 '환불 기한이 며칠인가', '지난 분기 계약은 몇 건인가', 'A 담당자가 전에 맡은 고객사는?', '올해 반복된 실패 원인은?'이 섞여 들어온다.

먼저 분량을 토큰으로 환산한다. 전체가 20만 토큰 아래이고 잘 안 바뀌면 긴 문맥과 캐시부터 시험한다. 그보다 크면 검색 층을 둔다. 실제 질문 80개를 모아 종류를 센다. 단일 사실이 60%, 숫자 합계가 15%, 연결이 15%, 전역 요약이 10%라면, 기본형은 하이브리드 검색이고 숫자만 SQL로 빼고, 연결·전역 요약만 나중에 그래프나 위키를 얹는다.

자료를 넣을 때는 정책과 계약은 장·절 구조를 살리고, 표는 열 제목을 모든 조각에 반복하며, 회의록은 말한 사람과 결정 사항으로 나눈다. 모든 조각에 출처, 날짜, 권한을 붙인다. 의미 검색과 키워드 검색을 함께 만들고, 한국어면 형태소 분석을 켠다. 문맥 기반 검색과 재정렬을 기본값으로 두고, 평가 집합으로 실패율을 잰다.

답을 쓸 때는 근거만 쓰게 하고, 출처를 강제하며, 근거가 없으면 모른다고 답하게 한다. 환불 질문에는 예외 조항이 같은 꾸러미에 들어오는지 확인한다. 매출 합계 질문은 검색이 아니라 읽기 전용 데이터베이스 질의로 보낸다.

그다음 주에는 실패한 질문만 모은다. 찾기 실패가 많으면 문맥 설명과 재정렬을 보고, 답 쓰기 실패가 많으면 출처-내용 일치 검사를 더한다. 연결 질문의 비중이 실제로 높을 때만 그래프를 검토한다. 이 순서를 지키면 유행하는 이름을 따라가지 않아도 시스템이 무너지지 않는다.

개인이나 소규모 팀이고 문서가 수백 건 이하라면, 벡터 저장소부터 세우는 것은 대개 순서가 틀렸다. 에이전트 도구와 마크다운 폴더로 LLM Wiki를 유지하는 편이 더 빠르다. 원본은 따로 두고, 규칙 파일에 '원본 수정 금지, 출처 연결 필수'를 적은 뒤 수집·질의·점검을 반복한다. 위키가 수백 문서를 넘어 목차만으로 찾기 어려워지면 지역 하이브리드 검색을 붙이면 된다.

팀 제품이고 매일 질문이 있다면, 구조를 살리는 나누기 → 문맥 기반 검색 → 하이브리드 검색 → 재정렬 → 출처 강제가 기본값이다. 법률·의료·금융·정책처럼 틀리면 큰 분야는 여기에 구조화 자료 도구, 권한 거르기, 감사 기록, 출처 검증을 더한다.

숫자로 보기 전에는 바꾸지 않는다

평가는 두 층으로 나눈다. 찾는 데 성공했는데 답이 틀린 것인지, 찾는 것 자체가 실패한 것인지를 구분하지 않으면 어디를 고쳐야 하는지 알 수 없다.

검색 층에서는 상위 K개 안에 정답 근거가 들어왔는지, 얼마나 위에 있는지를 잰다. 생성 층에서는 답의 주장이 근거로 뒷받침되는지(충실도, Faithfulness), 질문에 답하고 있는지를 잰다. 출처 표시가 겉모양뿐인지도 따로 본다. 권한 없는 자료가 새는지, 느린 경우에도 쓸 만한지, 질문당 비용이 감당되는지도 운영 지표로 둔다.

오픈소스 평가 도구 레이가스(Ragas)는 충실도(Faithfulness), 답변 관련성, 문맥 정밀도(Context Precision), 문맥 재현율(Context Recall)을 표준으로 제공한다. 충실도만 낮으면 답 쓰기 문제, 재현율이 낮으면 찾기 문제, 정밀도가 낮으면 재정렬·거르기 문제다. 채점은 AI를 판정자로 쓰되, 일부 표본은 사람이 직접 확인해 판정자 자체가 믿을 만한지 점검한다.

같은 자료와 같은 질문으로 여섯 방식을 견주면 설계 선택의 증거가 된다. 긴 문맥, 의미 검색만, 하이브리드, 문맥 기반 검색과 재정렬, 하이브리드와 부모-자식, 그래프·위키 확장형. 처음부터 전체 자료에 적용할 필요는 없다. 대표 질문 100–200개면 충분하다.

나누기 방식, 임베딩 모델, 가져올 개수, 지시문 중 무엇 하나라도 바꾸면 평가 집합을 다시 돌린다. 평가 없는 변경은 개선이 아니라 주사위 던지기다. 공개된 시험 수치는 방향만 알려 준다. 크기는 내 자료로 재야 한다.

운영과 보안이 시범용과 실제를 가른다

문서가 바뀌면 해당 조각만 골라 다시 저장한다. 문맥 기반 검색을 쓰면 문맥 설명도 함께 다시 만든다. 원본에서 지운 문서가 검색 저장소에 남아 있으면 폐기된 규정으로 답한다. 벡터, 그래프, 위키, 캐시 모두에서 지워졌는지 확인해야 한다.

권한은 찾기 단계에서 적용한다. 답을 만든 뒤에 걸러 내는 방식은 이미 늦다. 질문, 다시 쓴 질문, 찾은 조각 번호, 재정렬 점수, 최종 출처를 기록하지 않으면 '왜 그렇게 답했나'에 영원히 답할 수 없다. 법률·의료·재무처럼 중요한 결과는 사람 검토를 거치게 한다.

검색된 문서 안에 '이전 지시를 무시하라' 같은 문장이 들어 있을 수 있다. AI가 이를 명령으로 착각하면 악의적인 문서가 시스템 전체를 조종할 수 있다. 찾아온 문서는 언제나 자료로만 다루고, 명령으로 실행하지 않는다. 외부 웹이나 이메일을 수집하는 시스템이라면 특히 중요하다.

하지 말아야 할 것

평가 집합 없이 조각 크기부터 조정하지 않는다. 의미 검색 하나로 모든 질문을 받지 않는다. 코드·이름·날짜 질문에서는 거의 항상 틀린다. 미세 조정으로 사실을 가르치지 않는다. 긴 문맥을 대규모 지식 자료의 대체재로 쓰지 않는다. 그래프를 유행으로 도입하지 않는다. 관계 질문이 핵심이 아닐 때는 3–5배 비용을 내고 단순 조회만 느려진다.

검색 성공을 답변 성공으로 착각하지 않는다. 상위 목록에 들어간 것과 AI가 그것을 근거로 답한 것은 별개로 검증한다. 권한은 답을 쓴 뒤가 아니라, 찾을 때 적용한다. 실패를 모델 탓으로만 돌리지 않는다. AI가 만든 위키와 요약을 원본처럼 믿지 않는다. 생성된 문맥 설명을 원문과 한 덩어리로 보관하지 않는다.

맺으며

좋은 시스템은 똑똑한 모델이 아니라 좋은 증거 공급망이다. 지난 2년의 발전은 그 문제의식을 하나씩 제도로 바꾼 과정이었다. 문맥 기반 검색은 조각에 문맥을 되돌려 주었다. 그래프는 관계 그 자체를 저장 대상으로 삼았다. LLM Wiki는 검색 대신 미리 정리를 택했다. 에이전트형 검색은 찾기를 한 번의 동작이 아니라 판단의 반복으로 바꿨다. 캐시 증강 생성과 긴 문맥은, 작을 때는 아예 찾지 않는 것으로 답했다.

설계자의 일은 이 이름들을 외우는 것이 아니다. 내 질문이 어디서 실패하는지를 측정하고, 그 실패에 맞는 층을 하나씩 쌓는 것이다. 측정, 제대로 된 기본형, 문맥 되살리기, 질문 종류별 확장, 필요한 곳에만 에이전트를 쓰는 일. 이 순서를 지키면 방법론의 유행이 바뀌어도 시스템은 무너지지 않는다. 바뀌는 것은 층이지, 원칙이 아니기 때문이다.

기계가 자료를 대신 찾아 주는 시대에, 사람에게 남는 것은 어떤 증거를 믿을지 정하는 일이다. 그 질문의 다른 면은 기계가 다 해주는 시대, 무엇이 사람을 사람답게 하는가에서 이어 두었다.

이 글의 근거가 된 보고서 원본은 여기서 내려받을 수 있다. 표와 참고 문헌, 설계 체크리스트가 그대로 들어 있다.

참고한 자료

수치는 각 자료가 공개한 시험 기준이며, 방향을 판단하는 근거로 제시한 것이다. 실제 도입 효과는 자체 평가 집합으로 다시 재야 한다.

• 송재희, 고유 데이터 기반 생성 시스템 설계 보고서 (2026년 10월)
• Anthropic, Introducing Contextual Retrieval (2024.9.19)
• Microsoft Research, GraphRAG (2024.4)
• Microsoft Research, LazyGraphRAG (2024.11)
• Xiang et al., GraphRAG-Bench (ICLR 2026)
• Chroma, Context Rot (2025.7)
• Chan et al., Cache-Augmented Generation (WWW 2025)
• Andrej Karpathy, LLM Wiki (2026.4)
• Faysse et al., ColPali (ICLR 2025)
• Anthropic, Effective Context Engineering for AI Agents (2025.9)
• OWASP, RAG Security Cheat Sheet