긴 문서를 넣으면 AI가 중간을 놓칠까 — 48,000자 문서에 사실 한 줄 심고 244회 실측
혹시 회의록 뭉치를 통째로 붙여넣고 "3층 회의실 담당자 누구야"라고 물었다가 "문서에 없습니다"를 받아본 적 있으시죠? 분명히 적혀 있는데 말이죠. 그럴 때 대부분 "역시 긴 문서는 AI가 중간을 놓치는구나"라고 결론짓고 넘어갑니다.
정말 중간을 놓치는 거라면 문서를 잘라 넣는 수밖에 없습니다. 월급도 안 나가는 AI 일꾼한테 일 시키자고 사장이 문서를 손으로 토막 내는 신세가 되는 거죠. 그래서 가상의 사내 규정 문서를 2,000자부터 48,000자까지 만들고, 그 안 다섯 지점에 유일한 사실 한 줄을 심은 뒤 총 244회를 돌려봤습니다. 2026년 8월 3일, 로컬 gemma3:4b 기준입니다.
결론부터 적으면 통념이 재현되지 않았습니다. 컨텍스트 창만 제대로 지정하면 48,000자 문서에서 방해 요소 없는 80회는 80회 다 맞혔습니다. 위치도 상관없었고요. 대신 전혀 다른 두 군데에서 무너졌습니다.
무엇을 어떻게 쟀나
토큰 한 톨에 원가를 매기는 시네가 "문서를 잘라 넣으세요"라는 조언에 노동을 얹기 전에, 그 조언이 맞는지부터 재봤습니다. 일꾼 탓을 하려면 일감부터 제대로 줬는지 확인해야 하니까요. 채우기 텍스트는 저작권 지뢰를 피하려고 전부 직접 썼습니다. 가상 회사의 사내 규정 조항 40종을 고유한 조 번호로 순환시켜 2,000 / 8,000 / 24,000 / 48,000자 문서를 만들었습니다. 여기에 채우기에 절대 안 나오는 사실 한 줄을 심습니다. 담당자 이름(총무팀 김하늘 주임), 식대 금액(12500), 반복 일정(매월 셋째 주 목요일), 양식 번호(GX-4718) 네 종류이고, 전부 이 가상 규정 안에서만 쓰는 값입니다.
심는 자리는 문서의 0 / 25 / 50 / 75 / 100% 지점입니다. 심은 조항은 채우기 조항과 형식이 똑같습니다. 형식이 다르면 눈에 띄어서 "위치 효과"가 아니라 "튀는 문장 찾기"를 재게 되니까요. 그리고 질문 하나를 던져 심은 값이 그대로 돌아오는지만 기계로 대조했습니다.
대조군으로 그 문장 한 줄만 준 경우를 4회 넣었습니다. 4/4 정답이었습니다. 이게 틀렸다면 회상 능력이 아니라 질문이나 채점기가 깨진 것이라 실험 자체를 접어야 했습니다.
원자료·프롬프트 전문·회차별 원응답은 실행기가 자동으로 남깁니다. 이 글의 모든 수치는 그 기록을 채점기가 정답키와 대조한 결과이고, 사람이 숫자를 적어 넣는 자리는 없습니다.
통념부터: 길이도 위치도 문제가 아니었습니다
방해 요소가 없는 조건에서 네 가지 길이를 각 20회씩 돌린 결과입니다.
| 문서 길이 | 실제 프롬프트 토큰(중앙값) | 정답 | 회차당 소요(중앙값) |
|---|---|---|---|
| 2,000자 | 1,397 | 20/20 | 4.30초 |
| 8,000자 | 5,007 | 20/20 | 4.61초 |
| 24,000자 | 14,683 | 20/20 | 5.51초 |
| 48,000자 | 29,149 | 20/20 | 6.79초 |
80회 중 80회. 심은 자리가 맨 앞이든 한복판이든 맨 뒤든 차이가 없었습니다. 48,000자면 A4로 스물몇 장이고 토큰으로는 29,149개인데, 4B짜리 작은 일꾼이 그 안에서 이름 하나를 정확히 집어냅니다. 회차당 6.79초짜리 야근으로요.
여기서 중요한 건 이 녀석이 대단하다는 얘기가 아니라 "긴 문서라서 못 찾는다"가 이 조건에서는 틀린 진단이라는 겁니다. 진단이 틀리면 손대는 곳도 틀립니다. 멀쩡한 파이프라인을 붙잡고 문서를 잘게 쪼개는 작업부터 시작하게 되거든요.
첫 번째 함정: 비슷한 조항이 섞이면 옆에서 답을 집어옵니다
진짜 문서에는 비슷한 조항이 널려 있습니다. 회의실 조항이 하나만 있는 규정은 없죠. 그래서 일꾼에게 주는 일감을 현실에 맞게 어질러 놨습니다. 같은 형식에 값만 다른 방해 조항 3개를 문서 곳곳에 흩뿌리고 같은 질문을 던진 겁니다. 3층 소회의실 담당자를 물으면서 2층·5층·지하 강당 담당자 조항을 같이 넣어두는 식입니다.
정답률이 80/80(100%)에서 62/80(77.5%) 로 떨어졌습니다. 그리고 틀린 18회 중 17회가 "모르겠다"가 아니라 옆 조항의 값을 그대로 가져온 것이었습니다.
위치별로 보면 곡선이 통념과 다릅니다. 흔히 말하는 "중간을 잃는다"라면 50% 지점이 최악이어야 하는데, 실제로 제일 낮은 건 25% 지점(8/16, 50%) 이었고 50% 지점은 12/16이었습니다. 양 끝은 거의 안 틀렸습니다(맨 앞 16/16, 맨 뒤 15/16). 정확히는 "중간을 잃는다"가 아니라 "양 끝이 아니면 헷갈린다" 에 가깝습니다.
문항별로도 갈렸습니다. 사람 이름이 12/20으로 가장 취약했고(방해 값을 8회 집어옴), 식대 금액은 19/20으로 거의 안 흔들렸습니다. 사람 이름 네 개가 다 "총무팀 ○○ 직급"이라 서로 닮은 반면, 12500과 9000은 숫자 모양부터 다르기 때문으로 보입니다. 다만 이건 이 네 문항에서 관찰된 것이지, "이름은 취약하고 숫자는 안전하다"는 일반 법칙으로 옮길 근거는 이 측정에 없습니다.
제일 섬뜩했던 건 값을 섞어버린 회차입니다. 서버 점검 일정을 물었더니 "매월 넷째 주 금요일 밤 11시" 라고 답했는데, 넷째 주 금요일은 파일 서버(방해 조항) 일정이고 밤 11시는 위키 서버(정답) 시각입니다. 두 조항을 반씩 접붙인 문장이죠. 옆자리 주임 서류에서 날짜만 베껴 와 제 보고서에 붙여놓고 태연한 인턴을 보는 기분인데, 읽는 사람 입장에서는 어느 쪽도 검증할 생각이 안 듭니다. 그럴듯하게 완성돼 있으니까요.
두 번째 함정: 기본 설정이면 문서의 93%가 그냥 버려집니다
여기가 이번 측정에서 제일 실용적인 부분입니다. 위 결과는 전부 컨텍스트 창을 32,768로 명시하고 얻은 것입니다. 그런데 로컬 모델을 굴리는 사람 대부분은 그런 옵션을 건드리지 않습니다. 그래서 아무 설정도 하지 않은 팔을 80회 따로 돌렸습니다. 사장이 서류를 통째로 던져주고 "알아서 읽어" 하는 상황이죠.
| 조건 | 실제 들어간 토큰 | 정답 | 모른다고 답함 | 지어냄 |
|---|---|---|---|---|
| 2,000자 | 1,349 (전부) | 20/20 | 0 | 0 |
| 8,000자 | 2,051 | 8/20 | 8 | 4 |
| 24,000자 | 2,051 | 4/20 | 12 | 4 |
| 48,000자 | 2,051 | 4/20 | 10 | 6 |
들어간 토큰이 세 길이 모두 똑같이 2,051입니다. 48,000자 문서의 29,149토큰 중 2,051개만 들어갔다는 뜻이고, 본문의 93%가 모델에 닿지도 못했다는 뜻입니다. 2,000자 문서만 온전히 들어가서 20/20이 나왔고, 이 팔의 전체 정답률은 80회 중 36회, 45% 였습니다.
그런데 어디가 잘렸을까요. 위치별로 쪼개 보면 칼로 자른 듯 갈립니다. 24,000자와 48,000자에서는 맨 뒤에 심은 4회만 맞고 나머지 네 지점은 전부 0/4였습니다. 8,000자는 뒤쪽 두 지점(75%·100%)만 살아남았고요. 2,000자만 다섯 지점 전부 4/4입니다. 즉 앞에서부터 잘려 나가고 뒤쪽이 남습니다. 회의록 앞머리의 참석자 명단이나 계약서 첫 장의 당사자 정보처럼, 하필 중요한 게 앞에 오는 문서라면 정확히 그 부분이 사라집니다.
더 나쁜 건 잘렸다는 경고가 어디에도 안 뜬다는 겁니다. 오류도 아니고 빨간 글씨도 없습니다. 44회 실패 중 30회는 그래도 "문서에 없습니다"라고 정직하게 답했지만, 14회(전체의 17.5%)는 없는 답을 지어냈습니다. 있지도 않은 "제102조", "제384조" 같은 조항 번호를 붙여서요. 사람 눈에는 잘린 흔적이 안 보이니 그 답을 그대로 받아 적게 됩니다.
이건 우리가 로컬 AI 사실성·환각 저항 실측에서 봤던 패턴과 같습니다. 그때도 정형화된 지식 문항에서 지어낸 이름을 실물처럼 인용했었죠. 못 읽었다고 말하는 대신 읽은 척 보고서를 채워 오는 일꾼인 셈인데, 월급을 안 주니 뭐라 할 수도 없습니다. 모델은 자기가 모른다는 사실 자체를 잘 모릅니다.
그래서 뭘 바꾸면 되나
일꾼을 탓하기 전에 사장이 손볼 게 네 가지 있습니다.
- 문서를 자르기 전에 컨텍스트 창부터 확인하세요. 이번 측정에서 문서 길이 자체는 정답률을 전혀 떨어뜨리지 않았습니다. 잘라 넣는 작업은 창을 늘린 뒤에도 여전히 틀릴 때 시작해도 늦지 않습니다. 책상 좁은 인턴한테 서류를 산더미로 안겨놓고 일 못한다고 하는 격이었으니까요.
- 긴 문서일수록 중요한 내용을 뒤로 보내세요. 잘릴 때 남는 쪽은 뒤입니다. 질문도 문서 뒤에 붙이는 편이 안전합니다.
- 비슷한 항목이 여러 개면 질문에 구분자를 박으세요. "회의실 담당자"가 아니라 "3층 소회의실 담당자"처럼 물어야 하고, 그래도 이번처럼 77.5%입니다. 이름·코드처럼 서로 닮은 값일수록 답을 그대로 믿지 말고 원문에서 한 번 확인하세요.
- 애초에 통째로 안 넣는 방법도 있습니다. 로컬 RAG로 내 문서 검색 실측에서는 필요한 조각만 찾아 넣는 방식으로 검색 10/10, 최종 정답 9/10이 나왔습니다. 문서가 길고 질문이 반복된다면 그쪽이 토큰값도 덜 듭니다.
- 반복 실행은 안전장치가 아닙니다. AI 답변 재현성 실측에서 확인했듯 temperature를 0으로 고정하면 8번 다 같은 답이 나오는데, 그 8번이 다 똑같이 틀린 계산인 경우가 있었습니다. 두 번 물어서 같은 답이 나왔다는 건 검증이 아닙니다.
이 측정의 한계
정직하게 적어둡니다. 이건 gemma3:4b 한 모델의 결과입니다. 일꾼 한 명 근무평가로 회사 전체를 판단하면 안 되죠. 다른 모델, 특히 상용 대형 모델은 다르게 나올 수 있고 컨텍스트 창 기본값도 제품마다 다릅니다.
문서도 한계가 뚜렷합니다. 조항 40종을 순환시켜 만들었기 때문에 진짜 문서보다 훨씬 균질합니다. 실제 계약서나 회의록처럼 문체와 밀도가 들쭉날쭉한 텍스트에서는 결과가 나빠질 가능성이 큽니다. 그리고 이번에 잰 건 단답 회상 한 가지입니다. 여러 사실을 엮어 요약하거나 표로 정리하는 작업은 이 측정 범위 밖이고, 그쪽은 문서 요약 정확도 실측에서 이미 다른 방식으로 정보를 버린다는 걸 확인했습니다.
마지막으로 회차 수입니다. 이 녀석에게 시킨 위치별 칸은 16회, 문항별 칸은 20회입니다. 한두 회차가 뒤집히면 몇 %포인트는 움직이는 크기라, "25% 지점이 정확히 50%다"보다는 "양 끝보다 안쪽이 약했다" 정도로 읽는 게 맞습니다. 반면 방해 조항 없는 80/80과 기본 설정에서 잘린 2,051토큰은 회차 수와 무관하게 단단한 사실입니다.
이 글은 cinevyze 운영자가 해당 도구를 직접 테스트하고 결과를 비교·검수해 정리·편집했습니다. 판단·사실확인은 모두 사람이 했고, 글 다듬는 일부 과정에 AI 도구의 도움을 받았습니다.
댓글
댓글 쓰기