요즘 이런 이야기를 자주 듣습니다.

“우리는 사내 문서를 MCP로 붙였어요. 에이전트가 알아서 찾아 읽습니다.”

작은 팀에서는 실제로 잘 됩니다. 저희가 재봤더니 **문서 2만 건까지는 96.2%**로, 어떤 검색보다도 정확했습니다.

문제는 그다음입니다.

어떻게 쟀나

한국어 위키 150만 문단을 코퍼스로 놓고, 문서량만 늘려가며 정답 문단을 찾아내는지 봤습니다.

코퍼스 3단계. 2만 문단(150만 토큰), 14만 문단(1천만 토큰), 150만 문단(1억 토큰). 작은 게 큰 것의 부분집합이라 질문도 정답도 그대로고 문서량만 늘어납니다
에이전트는 시늉이 아니라 실물입니다. 실제 코딩 에이전트를 폴더에 넣고 ls, grep, cat으로 찾게 했습니다
정답은 공개 데이터셋(MIRACL 한국어)의 것을 그대로 썼습니다. 질의 213개, 질의당 정답 중앙값 2건
채점에 LLM을 쓰지 않았습니다. 정답 목록과 기계적으로 대조했습니다. 판정자 편향이 들어갈 자리가 없습니다

96.2%에서 25.0%로

정답 문단을 상위 10건 안에 넣은 비율입니다.

	2만 문단	14만 문단	150만 문단
파일 탐색 에이전트	96.2%	—	25.0%
벡터 검색	95.3%	92.5%	81.2%
키워드 검색(BM25)	73.7%	58.2%	39.9%

여기서 볼 것은 두 곡선의 모양이 다르다는 점입니다.

에이전트는 96.2%에서 25.0%로 71점 떨어집니다. 같은 구간에서 검색은 95.3%에서 81.2%로 14점 떨어집니다. 문서가 70배 늘어도 검색은 대부분을 지켜냅니다.

에이전트가 못 푼 게 아닙니다. 후보를 발견하지 못한 겁니다. 정답 문단을 손에 쥐여주면 잘 씁니다. 문제는 150만 개 파일 중에서 그 문단에 도달하지 못한다는 것입니다.

진짜 문제는 정확도가 아니었다

더 불편한 숫자가 따로 있었습니다.

	2만 문단	150만 문단
없는 문서 ID를 지어낸 비율	4.4%	11.6%
질문당 소요 시간	39초	177초

문서가 늘수록 에이전트는 존재하지 않는 문서를 근거로 댑니다. 10건 중 1건 이상입니다. 시간은 4.5배를 쓰고요.

이게 왜 무서운가 하면, 정확도가 낮은 건 눈에 보이지만 지어낸 근거는 안 보이기 때문입니다. 문서 ID가 그럴듯하게 붙어 있으면 사람은 확인하지 않습니다.

찾다 지치면 지어냅니다. 사람도 그렇습니다.

검색 도구 하나를 쥐여줬더니

같은 에이전트에, 같은 폴더를 그대로 두고, 검색 명령 하나만 더 줬습니다. 모델도 프롬프트 형식도 예산도 채점도 전부 같습니다. 차이는 그 하나뿐입니다.

150만 문단에서, 같은 질문 40건입니다.

	정확도	소요 시간	지어낸 근거
폴더만	25.0%	177초	11.6%
폴더 + 검색	75.0%	91초	0.0%

정확도는 3배, 시간은 절반, 지어낸 근거는 112건 중 0건입니다.

지어낸 근거가 0이 된 게 정확도보다 중요합니다. 검색이 돌려준 목록에서 고르게 되니 애초에 지어낼 대상이 없어집니다. 없는 파일명을 만들 이유가 사라지는 겁니다.

에이전트가 나쁜 게 아니었습니다. 찾는 방법이 없었을 뿐입니다.

한국어에서는 벡터가 키워드의 두 배였다

같은 실험을 영어(코로나 논문 17만 건)로도 돌려봤는데, 거기서는 키워드 검색이 벡터를 앞섰습니다. 한국어는 정반대였습니다.

150만 문단	hit@10
벡터 검색	81.2%
키워드 검색	39.9%

두 배 넘게 차이가 납니다.

이유는 언어 구조입니다. “그리스의 수도는”에서 키워드 검색은 그리스의를 하나의 토큰으로 잡습니다. 문서에 그리스는, 그리스에서로 적혀 있으면 못 맞춥니다. 조사와 어미가 붙는 언어에서 표면 문자열 매칭은 구조적으로 불리합니다.

한국어 문서로 RAG를 만든다면 이 차이는 선택의 문제가 아닙니다.

하이브리드가 항상 답은 아니다

키워드와 벡터를 섞으면(RRF) 보통 더 좋아집니다. 실제로 영어 실험에서는 전 구간에서 섞은 쪽이 8~12점 앞섰습니다.

한국어에서는 갈렸습니다.

	2만 문단	14만 문단	150만 문단
벡터만	95.3%	92.5%	81.2%
섞으면	95.8%	90.1%	77.0%

작을 때는 섞는 쪽이 낫고, 커지면 벡터 단독이 낫습니다.

약한 레인을 섞으면 좋은 후보가 밀려납니다. 한국어에서 키워드 검색이 39.9%까지 떨어지는 구간에서는, 그 결과를 섞는 것이 오히려 손해였습니다.

“하이브리드가 정답”이라는 말도 코퍼스와 언어를 보고 해야 합니다.

그래서 언제 검색 인프라가 필요한가

이 실험이 답하는 질문은 하나입니다. “우리 문서량에서 지금 방식이 아직 괜찮은가.”

문서가 수만 건이라면 에이전트에 폴더를 붙이는 것으로 충분합니다. 실제로 그게 더 낫습니다(96.2%)
십만 건을 넘어가면서 벌어지기 시작합니다
백만 건이면 폴더만으로는 안 됩니다. 정확도가 4분의 1로 떨어지고, 답이 틀렸다는 걸 알 수 없게 되는 게 더 문제입니다

고칠 방법은 모델을 바꾸는 게 아니었습니다. 같은 모델에 검색 하나를 붙이니 25.0%가 75.0%가 됐습니다.

한국어 A4 한 장이 대략 1,000토큰입니다. 1억 토큰은 문서 10만 장 정도입니다. 몇 년 굴린 회사면 그 정도는 금방 넘습니다.

이 숫자를 그대로 믿으면 안 되는 부분

정직하게 붙입니다.

에이전트 쪽은 질의 80건(작은 코퍼스), 40건(큰 코퍼스)으로 쟀습니다. 검색 쪽 213건보다 적어서 신뢰구간이 넓습니다. 방향은 분명하지만 소수점을 따질 숫자는 아닙니다
코퍼스가 위키 문단입니다. 사내 문서는 중복도 많고 버전도 갈려서 더 어렵습니다. 이 숫자는 낙관적입니다
이 실험은 “찾았는가”만 잽니다. 여러 문서를 종합하거나 모순된 내용을 판단하는 능력은 안 잽니다. 그 영역에서는 에이전트의 값어치가 따로 있습니다

정리하면

문서 에이전트를 도입할 때 보통 모델을 고릅니다. 이 실험이 말하는 건 다릅니다. 같은 모델이 문서량에 따라 96%도 되고 25%도 됩니다. 갈린 건 모델이 아니라 문서를 찾는 방법이었습니다.

그리고 그 차이는 문서가 쌓일수록 벌어집니다. 지금 잘 되는 것이 내년에도 잘 된다는 뜻은 아닙니다.