공유 문서 검색으로 전환한 뒤에도 일부 클라이언트는 자기 디스크에서 문서를 찾고 있었다. 서버의 응답은 유효했지만 클라이언트는 로컬 문서 폴더가 있는지 확인하거나 로컬 사본을 다시 읽었다. 원문을 가진 서버에 검색을 맡겼는데, 답을 받는 쪽에 같은 원문이 없어서 실패한 경우였다.
설치본을 확인한 기록에는 서로 다른 두 실패 지점이 나온다. 한쪽은 접근할 수 없는 로컬 문서 디렉터리에 존재 확인을 걸었다. 여기서 막히면 공유 검색을 포기하고 로컬 검색으로 넘어갔고, 비어 있는 로컬 문서 모음에서는 답을 얻지 못했다. 다른 쪽은 유효한 공유 응답을 받은 뒤 AI에 넘길 본문을 조립하면서 로컬 사본을 다시 요구했다. 서버가 고른 원문 경로는 이 단계에서 빠졌다.
서버만 정상인지 확인해서는 이 실패를 놓친다. 같은 요청을 받는 서버가 성공하더라도 실제 클라이언트는 자기 파일시스템 조건 때문에 그 결과를 버릴 수 있다. 두 경우 모두 서버의 검색 결과를 최종 근거로 만드는 과정에 로컬 사본이 끼어 있었다.
로컬 검색은 남기고 공유 읽기의 조건을 바꾸다
로컬 검색은 서버에 접근할 수 없을 때 쓸 별도의 선택지가 될 수 있다. 다만 이번에 실패한 흐름에서는 유효한 서버 응답을 로컬 파일 조건 때문에 거부한 뒤 빈 로컬 모음으로 돌아갔다. 복구 경로가 있어도 읽을 로컬 자료가 없다면 도움이 되지 않는다. 공유 읽기를 택한 요청에까지 사본 존재를 요구하면서 이미 받은 근거도 쓰지 못했다.
수정은 공유 읽기에서 입증된 두 로컬 의존성을 제거했다. 서버 응답의 원문 경로·해시·발췌·블록 식별자·신선도를 확인하는 검사는 유지했다. 결과 안의 경로와 본문을 검증하는 일과 클라이언트 디스크에 사본이 존재해야 한다는 조건을 구분한 것이다. 로컬 검색을 명시적으로 선택하는 복구 경로도 남겼다.
수정한 코드와 실제로 쓰는 진입점
검증 기록은 격리한 수정 후보가 통과한 결과와 설치된 클라이언트를 부른 결과를 분리했다. 최종 기록에서는 설치된 명령줄 도구나 등록된 네이티브 도구 진입점 16개 중 15개가 강제 옵션 없이 기본 공유 읽기를 실행했다. 호출 전후의 설치 버전, 공유 응답과 대상에 저장된 결과 기록도 맞춰 확인했다. 나머지 한 곳은 연결되지 않아 미확인으로 남았다. 이 숫자는 설치 진입점의 확인 범위이며, 오래 실행 중인 대화 세션까지 전부 바뀌었다는 결과는 아니다.
이 사례에서 고친 곳은 문서를 더 잘 찾는 알고리즘이 아니었다. 이미 돌아온 근거를 받는 도중 클라이언트가 요구하던 로컬 폴더와 사본이었다. 서버가 문서를 찾은 다음에도 클라이언트가 그 문서를 다시 찾으려 한다면, 중앙에 원문을 모은 것만으로 읽기 경로가 독립하지는 않는다.