📄 사내 문서 AI 검색, 23만 건 앞에서 무너졌다
회사에 AI를 도입할 때 가장 먼저 나오는 아이디어는 대체로 비슷하다. "사내 문서를 전부 넣고 물어보면 답해주는 걸 만들자." 시연용으로 문서 몇백 건을 넣어보면 결과가 꽤 그럴듯하다. 그런데 실제 조직의 문서 전체를 붙이는 순간 답이 흔들리기 시작한다. 많은 팀이 이 지점에서 "모델이 부족한 건가, 검색이 부족한 건가"를 놓고 몇 달을 소모한다.
문제는 이걸 제대로 측정한 자료가 거의 없었다는 것이다. 기업 내부 문서는 외부에 공개될 수 없고, 그렇다고 연구용으로 만든 합성 데이터는 지나치게 단순해서 실제 환경을 대변하지 못했다. 최근 arXiv에 공개된 CorporateBench는 바로 이 빈칸을 겨냥한 벤치마크다.
무엇을 만들었나
연구진은 규모가 다른 네 개의 가상 기업을 통째로 만들어냈다. 직원 수는 12명부터 1만 명까지 걸쳐 있고, 각 기업의 문서는 시간에 따라 변해가는 지식베이스에서 뽑아냈다.
| 항목 | 내용 |
|---|---|
| 평가 말뭉치 규모 | 23만 건 이상의 문서 |
| 가상 기업 수 | 4개 (직원 12명부터 1만 명까지) |
| 평가 축 | 정보 추출 / 지식베이스 질의 |
| 평가 대상 | LLM 5종 |
| 검증 방식 | 사람이 검증한 다중 과제 질의응답 |
핵심 결과는 한 문장으로 요약된다. 입력 규모가 현실적인 수준에 가까워질수록 모델 성능이 뚜렷하게 나빠졌다. 문서가 몇백 건일 때 잘하던 모델이, 실제 회사만 한 규모에서는 눈에 띄게 흔들린다는 뜻이다.
어떻게 만들었길래 의미가 있나
이 벤치마크에서 눈여겨볼 부분은 데이터를 만든 방식이다. 보통 합성 데이터셋은 질문과 답을 하나씨 짝지어 만든다. 그러다 보니 문서끼리 앞뒤가 안 맞는 경우가 생기고, 결국 "모델이 틀린 것"과 "데이터가 이상한 것"을 구분할 수 없게 된다.
CorporateBench는 반대 순서로 접근했다. 먼저 하나의 일관된 세계를 기술하는 지식베이스를 만들고, 그 지식베이스가 시간에 따라 변해가는 과정을 정의한 뒤, 거기서 문서를 뽑아냈다. 그래서 문서가 수십만 건으로 늘어나도 문서 사이의 논리적 일관성이 보장된다. 인사 발령이 있었다면 그 이후 문서에서는 직책이 바뀌어 있고, 그 변화가 문서 전체에 걸쳐 어긋나지 않는다.
평가는 두 축으로 나뉘다. 하나는 정보 추출로, 흔어진 문서에서 필요한 사실을 찾아내는 능력이다. 다른 하나는 지식베이스 질의로, 찾아낸 사실들을 조합해 답을 구성하는 능력이다. 실무에서 흔히 겪는 "검색은 되는데 종합을 못 한다" 또는 그 반대의 상황을 구분해서 볼 수 있게 한 설계다.
그래서 진짜 의미하는 것
이 논문을 "LLM은 아직 멀었다"로 읽으면 절반만 읽은 것이다. 몇 가지를 구분해서 볼 필요가 있다.
첫째, 이건 모델의 지능 문제라기보다 규모의 문제다. 같은 모델이 작은 문서 묶음에서는 잘한다. 달라진 것은 모델이 아니라 입력의 크기다. 그러니 사내 도입이 잘 안 될 때 더 좋은 모델로 바꾸는 것이 항상 답은 아니다. 검색 단계에서 후보 문서를 얼마나 잘 좁혀주느냐가 그만큼, 혹은 그보다 더 중요하다는 신호로 읽는 편이 실용적이다.
둘째, 시연 규모와 운영 규모의 간극을 측정 가능한 형태로 확인했다는 점이 중요하다. 많은 조직이 파일럿에서 좋은 결과를 얻고 전사 확대를 결정한다. 이 논문은 그 결정 사이에 놓인 위험을 지적한다. 파일럿 결과는 전사 규모의 성능을 예측해주지 않는다.
셋째, 한계도 분명하다. 네 기업 모두 합성 데이터다. 실제 회사 문서에는 오탈자, 중복된 옛날 버전, 맥락 없이 잘린 메모처럼 합성 데이터가 재현하기 어려운 지저분함이 있다. 즉 이 벤치마크의 결과는 실제 환경에서의 성능 상한선에 가까울 가능성이 있다. 현실에서는 더 나쁘 수 있다는 뜻이다.
또 하나 짚어둘 점이 있다. 공개된 초록 단계에서는 모델별 구체적 점수가 제시되지 않았다. "규모가 커질수록 나빠진다"는 방향성은 분명하지만, 어느 지점에서 얼마나 떨어지는지는 본문을 확인해야 한다. 도입 판단을 수치에 걸 생각이라면 원문을 직접 보는 편이 좋다.
마무리
사내 문서 AI를 검토하고 있다면 이 연구가 주는 실질적인 조언은 하나다. 파일럿을 실제 운영 규모의 문서량으로 해보라는 것. 문서 300건으로 검증한 결과는 문서 30만 건에서의 결과를 말해주지 않는다. 그리고 성능이 떨어질 때 모델부터 바꾸기보다, 모델에게 실제로 몇 건의 문서가 전달되고 있는지를 먼저 확인해볼 만하다.
출처
Sil Hamilton, Albert Yu Sun, Oscar J. Romero 외 4명, "CorporateBench: Large-Scale Q&A Benchmarking with Temporal Knowledge Bases", arXiv:2608.27391, 2026년 8월 27일. https://arxiv.org/abs/2608.27391v1