“최근 사흘 동안 바뀐 자료를 찾아 달라”고 물었는데 오래된 문서만 돌아온다. 도구 호출 기록은 남아 있고 오류도 없다. 이런 결과를 받으면 질문을 더 길게 쓰거나 AI에게 검색을 다시 시키기 쉽다. 하지만 검색기가 날짜 조건을 실행하지 않는다면, 문장을 보강해도 같은 문서가 계속 상위에 남을 수 있다.
실제 자동 글쓰기 경로에서 비슷한 일이 확인됐다. 11월 12일에 11월 10~12일의 Wiki·로그·출처 변경을 요청했지만, 돌아온 것은 10월 27일의 기억 채택 메모 한 건이었다. 11월 10일에도 같은 오래된 메모가 선택됐다. 다른 날에는 요청에서 피하라고 했던 비교 주제가 결과에 포함됐다. 호출 성공과 요구 충족 사이에 간격이 있었다.
질문의 날짜와 검색기의 날짜 조건은 다르다
당시 일반 조회기는 질문 전체를 단어로 나눠 문서와 맞는 정도를 계산했다. 검색 대상도 Wiki의 메타·키워드·분석 폴더 바로 아래 Markdown으로 한정돼 있었다. 일별 로그와 출처 기록은 그 목록에 없었다. 질문에 “최근”, “변경”, “제외”를 넣어도 요청한 기간을 필터링하거나 특정 주제를 의미상 제외하는 동작으로 이어지지 않았다.
갱신 날짜를 참고하는 코드가 있다고 해서 최신 자료를 먼저 찾는 것도 아니었다. 이 경로에서는 날짜가 점수 동률을 가르는 데 쓰였다. 질문과 단어가 많이 겹친 오래된 요약이 먼저 올라오면, 더 최근이지만 검색 범위 밖에 있는 출처는 경쟁할 기회조차 없다.
반환은 최대 3건이고 최고 점수의 95% 안에 든 후보만 남겼으며, 발췌에는 900자 제한이 있었다. 결과가 짧다는 사실만으로 원래 자료가 적다고 판단할 수 없는 이유다.
| 확인할 것 | 이 사례에서 드러난 차이 |
|---|---|
| 어디를 찾았는가 | 일반 문서 조회 범위에 로그·출처 기록이 포함되지 않음 |
| 날짜를 어떻게 썼는가 | 기간 필터가 아니라 점수 동률의 정렬 기준 |
| 어디에서 줄었는가 | 후보 수·점수 문턱·발췌 길이에 각각 제한이 있음 |
수집 함수가 있어도 작성기에 도착하지 않을 수 있다
문제를 좁히는 데는 실제 실행 경로가 도움이 됐다. 조사한 11월 8~12일의 예약 세션 다섯 건은 각각 context helper를 추가 연구 입력 없이 호출했고, Wiki 조회 도구도 한 번씩 불렀다. 복구된 11월 10~12일 helper 출력에서는 후보와 연구 목록이 비어 있었다. 다만 11월 8~9일의 전체 캐시 출력은 확보되지 않아, 그 이틀의 본문 입력까지 같았다고 단정할 수는 없다.
코드에는 최근 72시간의 로그와 출처를 모으는 함수가 남아 있었다. 그런데 실제 진입점은 그 함수를 부르지 않고 가져온 입력 패킷에서만 후보를 받았다. 수집 기능의 존재와 작성 입력의 연결이 따로 움직인 셈이다. “Wiki를 조회했다”는 기록 하나로는 최근 출처의 본문이 작성기에 전달됐는지 알 수 없었다. 빈 후보 목록 뒤에 범위가 좁은 일반 조회가 이어지면, 이미 잘 요약된 과거 메모를 계속 재사용하기 쉬운 조건이 된다.
따라서 이때의 검증 대상은 도구 호출 횟수가 아니라 연결이었다. 실행된 진입점에서 어느 수집 함수를 거쳤는지, 어떤 파일 버전이 선택됐는지, 실제 발췌가 context 출력에 있는지, 원고의 어느 설명이 그 발췌를 사용했는지를 이어서 확인해야 한다. 후보 제목만 전달된 경우와 본문이 전달된 경우도 구분해야 한다.
부분 조회를 빈 결과로 바꾸지 않기
보완된 경로를 통한 이번 작성 입력에는 최근 활동에서 찾은 후보 9건과 실제 출처 발췌, 버전 해시가 들어왔다. 다만 조회 상태는 partial이었다. 누락 항목이 남아 있고 전체 열거 완료도 확인되지 않았다. 읽기 불가 목록이 비어 있다는 것만으로 전체 범위를 다 봤다고 할 수 없다. 이 입력은 전달된 자료를 근거로 글을 쓰는 데 쓸 수 있지만, 다른 글감은 없다는 결론을 뒷받침하지 않는다.
자신의 검색 경로를 점검할 때는 실패한 요청 하나를 그대로 남긴 뒤, 결과에 있어야 할 자료의 종류와 날짜를 먼저 적어 두는 편이 좋다. 다음으로 실제 열거 범위, 기간 필터의 적용 여부, 정렬 순서와 잘림 조건을 확인한다. 마지막에는 도구가 돌려준 문서 식별자·발췌·버전이 소비자 입력까지 이어지는지 본다. 정상적인 빈 범위, 권한 오류, 예산에 따른 부분 조회는 서로 다른 결과로 남겨야 한다.
이 사례만으로 모든 반복 원고의 원인이나 AI의 내부 의도를 설명할 수는 없다. 일반 조회 자체가 나쁜 것도 아니다. 특정 문서를 찾는 조회와 최근 변경에서 소재를 발견하는 조회가 서로 다른 요구였고, 실제 입력 경로가 후자를 충족하지 못했다. 같은 도구를 썼다는 확인 뒤에, 같은 자료가 실제로 도착했는지를 한 번 더 물어야 하는 경우였다.