2편에서
청크 크기(ingestChunkSize)를 6→2→1로 낮출수록 사실관계 오류
발생률이 40%→10~13%→0%로 정확히 줄어드는 걸 네 번의 실험으로 확인했다.
결론을 정리하기 전에, 저녁에 집에 있는 노트북 1에서도 실험을 이어 가기로
했다. 그런데 실험을 다시 준비하던 그날 밤, 결론보다 사고가 먼저 왔다.
그날 밤, 충돌 마커가 그대로 커밋됐다 — 두 컴퓨터에서 git을 번갈아 쓸 때
이 실험은 노트북 1과 노트북 2 양쪽에서 번갈아 같은 저장소를 push하는
구조라, 두 기기가 동시에 손을 대면 git이 감당 못 할 상황이 생길
수 있다는 건 알고 있었다. 그날 밤 정확히 그 일이 벌어졌다. 낮에 실험을
돌린 노트북 2가 17시 9분에 자기 쪽 작업을 커밋해 올렸고, 그로부터 약
4시간 뒤 노트북 1이 그걸 미처 반영하지 못한 채 자기 작업을 21시 10분에
커밋했다. 1분 뒤인 21시 11분, 두 기기의 서로 다른 변경 내역을 합치는 병합
커밋이 하나 생겼는데 — 이 병합 과정에서 자동으로 못 합쳐진 부분에
git이 남기는 표시(<<<<<<<로 시작하는 충돌 마커)가 정리되지 않은
채 그대로 파일 77개에 박혀 커밋됐다.
플러그인 버그는 전혀 아니었다. 두 사람이 아니라 한 사람이 기기 두 대를 번갈아 쓰다가, 한쪽 작업을 push까지 마치기 전에 다른 쪽에서 작업을 또 만들어버린 것뿐이었다. 원인을 확인한 뒤 대응은 간단했다 — 충돌이 난 wiki 폴더를 통째로 지우고, 노트북 1에서 같은 원본 30개를 다시 노트 정리(ingest)로 새로 만들었다. 34분 만에 정리가 끝났다.
이 사고 자체는 30여 분짜리 해프닝으로 끝났지만, 여기서 얻은 교훈은 이후 실험 전체의 운영 원칙이 됐다 — 한 기기에서 하던 작업을 push까지 완전히 끝낸 뒤에만 다른 기기로 넘어간다. 두 기기를 동시에 열어놓고 각자 작업하지 않는다는 원칙이다.
수습하고 나니 설정 하나가 눈에 걸렸다 — OpenAI reasoning effort 설정
사고를 수습한 직후, 청크 크기와는 완전히 다른 설정값 하나가 눈에
걸렸다. 이 플러그인에는 openaiReasoningEffort라는 또 다른 설정이 있다.
low/medium/high 세 단계로 AI 모델이 답을 내기 전에 얼마나 깊게
“생각”하게 할지 정하는 값이다(기본값은 medium). 설정 화면의 설명
문구에는 이렇게 쓰여 있었다 — “High: 깊은 추론 (정보 보존율 및
자가 검증 극대화, 소요 시간/비용 증가)”. 이 문구를 다시 읽는
순간 심장이 철렁했다. “정보 보존율”이라니 — 그게 바로 지금까지
청크 크기 탓으로 돌렸던 그 fidelity 문제와 정확히 같은 걸 가리키는
말 아닌가?
노트북 1 설정을 확인해보니 High였다. 그런데 실험 대부분을 실행했던 노트북 2는 그 값을 확인한 적이 없었다. 만약 노트북 2가 처음부터 Medium이었다면, 지금까지 “청크 크기 효과”라고 믿었던 것의 상당 부분이 사실은 “reasoning effort 차이”였을 가능성이 생긴 것이다. 게다가 볼트를 git으로 관리하는 저장소는 raw/wiki 폴더 내용만 추적할 뿐 플러그인 설정 파일은 대상이 아니어서, 과거 시점 노트북 2의 실제 설정값을 사후에 복원할 방법이 없었다. 노트북 2는 낮에 쓰는 회사 노트북이라 그날 밤에는 직접 열어 볼 수도 없었다. 심증만 남은 채, 일단 짐작(아마 Medium이었을 것)만 해 두었다.
확인할 수 있는 것부터, 진짜 실험을 시작했다
노트북 2의 값을 확인할 수 없다고 손을 놓을 수는 없었다. 확인하고 싶었던 질문은 두 가지였다. reasoning effort가 정말 fidelity에 영향을 주는가? 그리고 그 영향이 지금까지 “청크 크기 효과”라고 믿어온 것과 얼마나 섞여 있었는가? 이 질문에 답하려면 이번엔 기기를 바꾸는 대신, 같은 기기, 같은 설정에서 딱 한 가지 값만 바꿔가며 다시 실험해야 했다.
4편에서 이어진다.