내용은 입력됐는데 보내기 버튼이 늦게 나타나거나 활성화될 수 있다. 이때 입력부터 다시 하면 중복이 생기고, 짧은 일반 탐색만으로 실패라고 단정하면 정상적인 준비 시간을 놓친다. 북극성의 Gemini 경로는 입력 검증 뒤 보내기 준비를 읽으며 기다리는 별도 단계를 뒀다.
내용 입력과 전송 준비는 같은 순간이 아니다
send는 먼저 현재 입력란을 찾고 내용이 비어 있지 않은지 확인한다. browser.fill 뒤 최신 composer 참조에서 verifyField로 값이 정확한지 읽는다. checked와 matches가 모두 맞아야 한다. 버튼이 켜져 있다는 이유로 내용 검증을 생략하거나 이전 입력이 남아 있으리라 가정하지 않는다.
반대로 내용이 맞다는 사실도 버튼 준비 완료를 뜻하지 않는다. 서비스가 첨부나 도구 모드, 입력 처리를 이어갈 수 있다. 나는 이 두 상태를 하나의 입력 성공으로 합치지 않았다. 값을 보낸 단계와 사이트가 다음 동작을 받을 수 있는 단계를 분리하면 실패 원인도 좁힐 수 있다.
전용 기다림은 읽기만 반복한다
필드 확인 뒤 until에서 enabled send 제어가 있는지 관찰한다. 대기 한도는 이번 timeout과60초 중 작은 값이다. 조건이 맞으면 그 뒤에 보내기 클릭을 한다. 기다리는 동안 fill이나 보내기 클릭을 반복하는 함수가 아니다. 전용 영상 입력기가 일반 탐색보다 늦게 준비되는 경우를 고려한 연결이다.
60초가 모든 요청에 꼭 필요한 지연도 성공 보장 시간도 아니다. 더 일찍 준비되면 진행하고 한도 내에 준비되지 않으면 GEMINI_SEND_NOT_READY다. 목적은 더 오래 무조건 기다리는 것이 아니라 준비라는 사건을 읽을 위치를 명확히 만드는 것이었다.
준비 전과 전송 뒤의 대기는 다른 자료를 본다
보내기 전에는 현재 입력과 버튼 상태를 읽는다. 보낸 뒤에는 새 응답 group과 busy, 본문·매체 안정 조건을 읽는다. 전자의 실패를 결과 생성이 느린 것으로 부르면 진단이 달라진다. 버튼을 누르지 못했는데 AI가 답을 못 만들었다고 기록해서는 안 된다.
새 응답이 늦는다고 입력란을 다시 채우는 것도 같은 혼동이다. 요청이 어디까지 전달됐는지 기록을 보고 다음 관찰을 정해야 한다. 나는 기다림을 하나의 상태로 만들기보다 무엇을 기다리는지 이름을 붙여 남기려 했다. 작업자가 불필요한 재입력을 하지 않을 근거가 된다.
dispatched라는 기록도 실제 클릭 횟수와 구분한다
현재 코드는 mark(dispatched)를 fill보다 먼저 저장한다. 따라서 보내기 준비가 실패해 실제 클릭이 없어도 보수적인 dispatched 기록이 남을 수 있다. 이 이름을 서비스로 질문이 확실히 전송됐다는 영수증으로 해석하면 안 된다. 원래 절차가 외부 입력 경로에 들어갔음을 보호하는 기록으로 읽는다.
후속 호출은 같은 기록이 불확실하면 OUTCOME_UNCERTAIN으로 멈춘다. 실제 상태를 읽고 무엇이 남았는지 확인해야 하며 새 key로 우회 재전송하지 않는다. 이 글은 모든 전송 전 실패가 자동으로 복구된다고 주장하지 않는다. 코드가 선택한 보수성과 남은 확인 책임을 함께 설명했다.
시험은 한 번 입력하고 기다렸는지 확인한다
기존 시험은 입력 뒤30번의 읽기가 지난 다음 보내기 제어를 보여 준다. 전체 흐름이 완료돼도 fill과 보내기 클릭은 각각1회여야 한다. 준비가 끝내 오지 않는 경우에는 입력1회와 클릭0회를 확인한다. 성공 메시지만 보는 시험보다 대기 중 반복 동작이 없었는지가 중요했다.
이 시험은 fake timer와 소유한 합성 화면 응답을 사용한다. 실제 제공자의30번 관찰이나 네트워크 시간을 측정한 결과가 아니다. 이번 콘텐츠 작업에서는 시험 코드를 읽었고 실제 AI 요청을 새로 보내지 않았다. 지연 fixture와 실서비스 경험을 같은 근거로 쓰지 않는다.
공유 관찰기에도 전송 기능을 넣지 않았다
공유 모듈은 새 응답·매체·시간 초과를 선언한 snapshot으로 비교한다. 입력란을 채우거나 보내기 버튼을 기다리는 원래 UI 연결은 구현하지 않는다. request_sent=False라는 결과가 붙는 이유다. 이 예제를 실행해도 외부 요청은 발생하지 않는다.
나는 준비 상태를 읽는 코드와 실제 외부 행동을 분리하면 여러 프로그램에서도 재사용하기 쉽다고 본다. 다만 둘을 연결하는 단계에서는 실제 대상과 권한, 현재 입력을 확인해야 한다. 읽으며 기다리는 기능이 재전송 버튼이 되지 않게 하는 경계까지 함께 설계해야 했다.