같은 동작을 한 번 실행한 뒤 “이 문장도 결과에 있는지 확인해 줘”라고 조건을 바꿀 수 있다. 예전 성공을 그대로 쓰면 새 조건을 확인하지 않은 것이고, 새 작업으로 보고 다시 실행하면 같은 입력을 두 번 보낼 수 있다. 북극성의 Gemini 경로는 이 두 실패를 나누기 위해 행동 지문과 검증 지문을 분리했다.

동작과 완료 질문은 같은 정보가 아니다

action key에는 현재 입력과 선택한 actions, 새 대화 여부, 확인 대상을 넣는다. timeout과 completion 같은 검증 옵션은 같은 방식으로 넣지 않는다. 반면 verificationHash에는 completion·resultText·expectedDraft를 둔다. 무엇을 했는지와 무엇을 확인해야 끝나는지를 다른 자료로 만든 것이다.

이 분리를 하지 않고 모든 옵션을 하나로 hash하면 대기 시간을 늘리거나 완료 문구를 바꾼 요청이 새로운 행동처럼 보일 수 있다. 반대로 검증 옵션을 그냥 버리면 예전 완료를 새 질문의 답으로 재사용한다. 중복을 막는 기준과 충분히 확인한 기준이 둘 다 필요했다.

예전 confirmed에 새 조건이 맞는지 비교한다

confirmed 영수증이 현재 대상이나 결과 URL과 연결되면 verificationHash를 비교한다. 새 값과 다르면 GEMINI_REUSE_VERIFICATION_REQUIRED로 멈춘다. 원래 결과를 읽어 확인하고 같은 작업을 재전송하지 말라는 오류다. 예전 성공 표시를 바꾸어 새 조건도 맞았다고 반환하지 않는다.

이 분기가 모든 새 조건을 자동으로 확인해 주는 만능 재검증기는 아니다. 실제로 어떤 본문과 매체를 읽어야 할지는 호출자가 현재 결과에서 확인해야 한다. 오류를 명확히 남겨 새 확인의 필요와 새 행동의 불필요를 동시에 전달한 것이다. 실패의 다음 행동까지 구분할 수 있는 결과가 필요했다.

대기 시간만 바꾸는 것은 동작을 바꾸지 않는다

같은 확인 조건에서 timeout만 늘리면 행동 key와 verificationHash가 그대로여서 이전 확인 결과를 재사용할 수 있다. 기존 시험은1000ms와2000ms의 설정에서 입력 효과가 한 번인지 본다. 다른 시험도 질문의 대기 시간만 바꿨을 때 보내기가1회인지 확인한다.

여기서 reused는 과거에 확인한 같은 조건의 영수증을 재사용했다는 뜻이다. 현재 페이지의 모든 내용이 방금 다시 검증됐다는 말은 아니다. 기존 receipt와 URL의 연결을 보는 코드 범위를 정확히 설명해야 한다. 이전 확인, 현재 관찰, 새 조건 검증을 같은 fresh 성공으로 섞지 않았다.

옛 영수증도 무조건 새 검증으로 승격하지 않는다

verificationHash가 없는 과거 기록에는 제한된 기본 조건 예외가 있다. completion이 기본 changed이고 추가 resultText나 expectedDraft가 없을 때만 예전 기록을 받아들인다. 새 초안 전제나 별도 완료 문구가 생기면 같은 예외로 넘기지 않는다. 과거 데이터 호환과 검증 기준 완화를 같은 것으로 만들지 않았다.

dispatched 기록이면 confirmed 재사용과 다르게 OUTCOME_UNCERTAIN으로 멈춘다. 실제 전송 여부와 원래 결과를 읽을 일이 남았다는 뜻이다. 완료 조건의 hash를 바꾸거나 새 key를 만들어 이 보호를 피하면 안 된다. 식별자를 바꾸는 것이 불확실한 업무를 안전하게 만드는 것은 아니기 때문이다.

시험은 거짓 재사용과 중복 입력을 함께 본다

기존 시험은 필드 입력을 한 번 확인한 뒤 같은 action에 다른 완료 문구를 요구한다. 새 검증은 거절되고 fill 횟수는1이어야 한다. 과거 영수증의 기본 조건은 보존하되 expectedDraft를 바꾸면 재전송 없이 거절하는 시험도 있다. 새 조건 실패와 새 행동 방지를 함께 확인한 것이다.

이번에는 해당 코드와 시험을 읽었고 원래 AI 서비스의 요청을 다시 보내지 않았다. 독립 생성 관찰 모듈은 이 receipt/hash 재사용 전체를 구현한 프로그램이 아니다. 그 모듈의32개 시험은 관찰 상태를 다루며 이 영수증 변경 검수와 범위가 다르다. 관련 구현의 존재를 전체 동일 기능의 공유로 과장하지 않는다.

더 엄격한 확인이 더 많은 실행을 뜻하지 않게 한다

고객이 결과를 더 자세히 확인하고 싶어 하는 것은 자연스럽다. 확인 조건을 추가했다는 이유로 같은 질문·업로드·수정을 다시 실행하게 만들면 검수를 요청하기도 조심스러워진다. 원래 효과를 보존한 채 더 확인할 부분을 분리해야 한다.

나는 실행의 동일성과 검증의 동일성을 다른 값으로 두는 방법을 이 사례에서 남기고 싶었다. 현재 설명은 Gemini의 해당 경로에 대한 것이며 다른 서비스의 key 구성이 모두 같다는 뜻은 아니다. 어떤 요청을 다시 보내지 않아야 하는지와 어떤 조건이 아직 입증되지 않았는지를 함께 읽을 수 있어야 한다.