1편에서
같은 원본 30개, 같은 플러그인인데 기기(노트북 1 vs 노트북 2)만 바꿨더니 결과 노트 수가 189개에서 63개로 줄어드는 걸
봤다. 유력한 용의자는 ingestChunkSize — 원문을 노트로 정리하는 기능(ingest)이 원본을 한 번에
몇 개씩 묶어서 AI에 보낼지 정하는 설정값이었다. 노트북 1은 2, 노트북 2는
6이었다. 이 값 하나가 정말 원인인지 확인하려면, 나머지는 전부
고정한 채 이 값만 바꿔가며 다시 재봐야 했다.
노트 개수 말고, “내용이 맞는가”도 재기로 했다 — LLM 요약 정확도(fidelity)
노트 개수 차이만으로는 부족했다. 노트가 적게 나왔다는 건 “덜 쪼갰다”는 뜻일 수도 있지만, 그 자체가 “틀렸다”는 뜻은 아니다. 진짜 중요한 질문은 따로 있었다 — 청크를 키워서 여러 원본을 한 번에 몰아넣으면, 모델이 그 내용을 요약하는 정확도 자체가 떨어지는가?
이 질문에 답하려면 raw 원본과 거기서 나온 wiki 노트를 한 줄 한 줄 대조해야 했다. 숫자, 날짜, 인명, 인용문, 인과관계가 원문 그대로 살아있는지를 확인하는 작업이다. 이 글에서는 이런 종류의 사실관계 오류(날조·누락·왜곡·다른 원본 내용이 섞여 들어오는 교차오염)를 통틀어 “fidelity 문제”라고 부른다.
청크=6 결과부터 전수 대조했다(Run B) — LLM 요약에서 인물·인용 출처가 빠지는 문제
먼저 노트북 2가 청크=6으로 만든 바로 그 63개 노트를 원본 30개와 전수 대조했다. 원본 30개 중 **12개(40%)**에서 fidelity 문제가 나왔다. 그것도 오탈자 수준이 아니라 꽤 심각한 것들이었다.
“AI-Native Engineer가 되는 법”이라는 원문에서 나온 노트에는, 그 글을 실제로 쓴 저자(Meta 소속 Shah Rahman)의 이름이 어디에도 없었다. Anthropic의 보안 사건 언급도, “vibe coding”이라는 용어를 처음 만든 사람이 Andrej Karpathy라는 귀속도 사라졌다. 다른 원문에서는 인용문을 만든 사람(“workslop”이라는 용어의 창시자 Jeff Hancock)의 이름이 통째로 빠졌고, 또 다른 원문에서는 C++ 관련 제안을 실제로 발표한 인물(Vinnie Falco)과 그의 인용문 자체가 사라졌다. 한국 연금 정책을 다룬 기사에서는 통계를 발표한 국회의원 이름과, 그 정책이 나오게 된 정치적 인과관계(대통령 발언 → 특정 정당의 입법 추진)가 두 노트 어디에도 남지 않았다.
패턴은 명확했다 — 이름 있는 사람·기관·출처가 압축 과정에서 통째로 증발하는 것. 게다가 한 원문의 표현이 전혀 다른 원문에서 나온 노트에 그대로 섞여 들어가는 사례도 두 건 나왔다. 예를 들어 어느 조직심리학 노트의 “관련 문서” 목록에 완전히 무관한 벤치마크 글이 링크로 붙어 있었는데, 이건 같은 청크에 함께 묶여 처리된 다른 원본의 흔적이 새어 들어온 것으로 보였다.
청크를 2로 되돌렸더니(Run C)
같은 원본, 같은 기기(노트북 2)에서 청크만 2로 되돌려 다시 돌렸다. 노트는 108개(63개보다는 늘고 노트북 1의 189개엔 못 미치는 애매한 숫자였다), fidelity 문제는 **3/30(10%)**으로 뚝 떨어졌다. 그나마 남은 세 건도 본문 내용 자체는 정확했고, “관련 문서” 링크가 엉뚱한 곳을 가리키거나 미묘한 표현 차이(“mid-level engineer”를 “mid-career engineer”로 살짝 다르게 옮긴 정도) 같은 경미한 것들이었다. Run B의 지배적 패턴이었던 “이름 있는 인물·기관 통째 누락”은 단 한 건도 재현되지 않았다.
청크를 최소인 1로 낮췄더니(Run D)
한 걸음 더 나가서 청크를 1(원본을 한 번에 하나씩만 처리)로 낮춰 같은 원본 30개를 또 돌렸다. 결과는 30개 전부 이상 없음, fidelity 문제 0건. 지금까지 네 번의 실험 중 유일하게 완벽한 결과였다.
4-way 종합 — 청크 사이즈와 요약 정확도
| 청크=2(노트북 1) | 청크=6 | 청크=2(재현) | 청크=1 | |
|---|---|---|---|---|
| 노트 개수 | 189 | 63 | 108 | 146 |
| fidelity 문제 | 4/30(13%) | 12/30(40%) | 3/30(10%) | 0/30(0%) |
청크를 6→2→1로 낮출수록 fidelity 문제 발생률이 40%→10~13%→**0%**로 정확히 단조 감소했다. 네 번의 실험이 전부 같은 방향을 가리키는 일관된 증거였다. 노트 개수(atomicity)는 청크 크기와 대체로 같은 방향으로 움직이긴 했지만 완전히 깔끔하게 비례하진 않았다 — 청크=1의 146개가 청크=2(노트북 1)의 189개보다 오히려 적었다. 같은 설정이어도 매 실행마다 자연스러운 편차가 있다는 뜻이었다.
여기서 결론을 내려도 됐을 것 같았다. “청크 크기가 fidelity를 좌우한다” — 실험 네 번이 전부 같은 방향을 가리키고 있었으니까. 그런데 이 결론에 도장을 찍기 직전, 완전히 다른 각도에서 의심이 하나 들어왔다. 두 기기의 설정이 정말 청크 크기 하나만 달랐을까? 그리고 그 의심을 확인하려던 바로 그날 밤, 실험과는 전혀 무관한 사고가 하나 터졌다.
3편에서 이어진다.