관련 함수를 읽었는데 다음 판단이 다시 같은 검색을 요청한다면 모델의 집중력만 탓할 수는 없다. 북극성의 과거 부분 수리에는 추가 조회가 앞의 문맥을 덮는 문제가 있었다. 무엇을 읽었는지와 실제 읽은 조각을 함께 유지하지 않으면 제한된 조사도 제자리로 돌아갔다.
같은 검색으로 돌아간 실제 기록을 먼저 남겼다
과거 영상 시작 시험에서는 unsupported_control 검색 뒤 관찰 함수를 읽고 다시 같은 검색으로 돌아왔다. 반복 방지 게이트가 멈춰 수정과 설치는 진행되지 않았다. 이 실패를 수리 성공으로 고쳐 기록하지 않았다. 각 조회가 이전 extra를 덮던 코드가 조사 대상이 됐다.
게이트가 불편하다고 반복 제한을 없애면 같은 조사가 더 오래 이어질 수 있다. 문제는 제한의 존재보다 다음 판단이 무엇을 실제로 전달받는지였다. 나는 읽은 검색이라는 표식만 남는 경우와 코드 조각이 함께 남는 경우를 나눠 보았다. 읽었다는 기억과 판단할 근거는 같은 자료가 아니다.
조회 키 원장과 조각 목록을 따로 유지한다
seen은 완료한 조회의 정체성을 기억하고 contextBlocks는 실제 결과를 모은다. 다음 prompt에는 두 자료를 함께 만든 extra가 들어간다. 같은 요청을 summary 문장만 바꿔 반복해도 새 조회로 보지 않도록 key에는 kind·queries·search·referenceUrl을 쓰고 summary는 넣지 않는다.
한 번 공급한 코드 범위에는 경로·현재 해시·줄 범위로 만든 supplied 표식도 있다. 같은 파일 이름이어도 해시나 범위가 달라질 수 있다. 반대로 표현만 달라진 동일 요청을 새 정보로 인정하면 제한된 호출 수를 같은 곳에서 소모한다. 중복 키와 결과 조각을 각각 관리해야 하는 이유다.
모든 과거 조각을 영원히 보내는 기억은 아니다
rememberContext는 base와 조회 원장을 고려해 남은 바이트 한도를 계산한다. 새 조각이 너무 길면 UTF-8 경계를 지켜 자르고, 여러 조각의 합이 넘으면 오래된 block부터 뺀다. 전체 prompt도 42,000바이트 상한을 다시 검사한다. 원래 제한을 풀어서 기억 문제를 해결한 것이 아니다.
따라서 두 작은 조각이 남았다는 시험을 모든 과거 조각이 언제나 보존된다는 보장으로 읽으면 안 된다. 원장에는 이미 조회했다는 표식이 있어도 오래된 본문은 예산 때문에 빠질 수 있다. 그런 경우에는 더 좁고 구체적인 다른 범위를 요청해야 한다. 제한된 기억의 누락을 숨기지 않는 안내가 함께 필요하다.
세 번째 호출이 실제로 받은 문장을 검사한다
회귀 시험은 첫 응답에서 검색을, 두 번째에서 helper의 symbol 조회를 요청하게 한다. 세 번째 모델 대역이 받은 prompt에는 첫 파일과 두 번째 파일의 해시, 완료 조회 원장이 모두 있어야 한다. 마지막에 고유 before/after 조각 수정안을 돌려줘 전체 흐름도 이어지는지 본다.
이 시험은 모델이 무엇을 이해했는지 추측하는 방식이 아니라 실제 전달 문자열을 확인한다. 다만 응답은 결정된 대역이므로 실제 서비스의 추론 성공률을 측정한 것은 아니다. 이번 집필에서는 그 원본 시험을 읽었고 과거 자동수리 실행을 새로 돌리지 않았다. 전달 검증과 자연어 판단의 성능은 별개다.
현재 조사에서는 누적 자료의 의미를 확인한다
이 원장은 제거된 내장 수리 경로의 역사적 구현이다. 현재 외부 Codex가 작업한다고 같은 조회 원장을 자동으로 사용한다는 뜻은 아니다. 가져올 수 있는 기준은 다음 판단에 필요한 근거가 실제로 남는지 확인하고 중복 요청·문맥 한도·불확실 결과 보호를 함께 유지하는 것이다.
공유 구조 보고서 모듈은 이 문맥 원장이나 코드 조회를 구현하지 않는다. 원문 없이 오류 단서를 설명하는 또 다른 작은 계약이다. 나는 기억을 늘린다는 말을 긴 대화를 전부 보내는 방식으로 해결하지 않았다. 필요한 단서를 보관하는 방법과 한도 때문에 빠진 단서를 다시 찾는 방법까지 구별해 남겼다.