저장된 원고를 불러오는 버튼을 한 번 눌렀는데 작업이 오래 멈춰 있었다. 검증 기록을 보면 페이지 안의 버튼이 아니라 브라우저가 띄운 확인창이 다음 처리를 기다리고 있었다. 이 사례를 다시 읽으며 내가 중요하게 본 것은 확인을 자동으로 눌렀다는 기능보다, 답한 뒤에도 무엇이 아직 끝나지 않았는지 프로그램이 구별하도록 만든 과정이다.
버튼을 못 찾은 것이 아니라 다른 계층을 보고 있었다
이번에 읽은 사례의 확인창은 페이지 DOM에 나타나는 팝업이 아니었다. 문서 안에서 이름과 역할이 맞는 버튼을 계속 찾는 방식만으로는 처리할 수 없었다. 이전 검증에서는 별도 화면 조작으로 확인창을 처리했지만, 후속 구현은 브라우저의 대화상자 이벤트를 관찰하고 고정된 응답 경로를 추가했다.
같은 오류를 버튼 탐색 실패라고만 부르면 새 클릭을 보내거나 숨긴 요소를 드러내는 쪽으로 수리가 흐르기 쉽다. 나는 이 사례를 입력 대상의 계층을 구별한 수정으로 읽었다. 페이지 요소를 조작하는 경로와 네이티브 확인창을 읽는 경로가 다르며, 어느 쪽도 임의의 페이지 내용을 새로운 실행 지시로 취급하지 않는다.
범용 명령 대신 읽기와 명시 응답만 열었다
외부 인터페이스에는 readDialog와 respondDialog라는 고정된 동작을 뒀다. 응답에는 현재 확인창 ID와 명시적인 참·거짓이 필요하다. 임의 프로토콜 명령이나 실행할 코드를 넘기고, 입력형 prompt에 문자열을 대신 넣는 인터페이스로 넓히지 않았다. 관찰한 확인창과 이번 응답을 정확하게 연결하려는 선택이었다.
원래 계약은 지원하는 종류와 문구 길이, 출처를 확인하고 로그인·권한·결제 같은 민감한 경고는 사람 인계 대상으로 남긴다. 문구 필터가 모든 위험을 판별하는 완전한 장치라는 뜻은 아니다. 일반 확인창처럼 보인다는 이유만으로 사용자가 요청하지 않은 승인이나 외부 작업까지 허용할 수는 없다. 이번 콘텐츠 작업에서도 실제 확인창에는 응답하지 않았다.
응답 뒤에 남은 원래 명령을 시험에서 드러냈다
초기 검수는 확인창에 답해도 원래 네이티브 명령이 아직 끝나지 않을 수 있다는 경합을 짚었다. 구현은 먼저 실패하는 시험으로 이 경우를 재현한 뒤, 입력 Promise와 뒤의 정리 작업이 끝날 때까지 대기 상태를 유지하도록 고쳤다. 확인창이 사라졌다는 사건만으로 원래 명령의 수명까지 끝난 것으로 보지 않은 것이다.
이 대기 중에는 새 입력뿐 아니라 원래 결과 확인도 막는다. 중지 뒤 새 작업으로 넘어가더라도 같은 탭의 미완료 명령을 없는 일로 만들지 않는다. 중지 요청을 했다는 사실과 이미 전달된 네이티브 명령이 취소됐다는 사실은 다르다. 이 작은 경합을 해결하려고 전체 입력 보호를 풀지 않고 명령이 실제로 남아 있는지를 추적했다.
창을 닫는 조건과 원고가 돌아오는 조건을 분리했다
응답 경로가 성공해도 ActionBroker의 원래 결과 대기는 남는다. 실제 작업이 처음 요구한 텍스트나 상태, 변화 조건을 별도로 읽어야 한다. 원래 버튼을 다시 누르는 대신 그 조건을 확인하는 경로를 사용한다. 확인창 응답의 성공을 원고 복원 성공으로 바꿔 쓰지 않기 위해서다.
결과 확인은 새로 편한 조건을 고르는 과정도 아니다. 원래 작업이 묶어 둔 기대를 계속 사용하고, 명령이나 정리가 미완료라면 그 검사조차 시작하지 않는다. 공개해 둔 결과 비교 모듈은 전후 관찰과 원래 조건의 관계를 설명한다. 이번 공유 코드는 거기에 앞서 확인창과 명령의 수명을 구별하는 부분만 따로 만든 합성 예제다.
확인창 ID는 다른 탭과 문서로 가져갈 수 없었다
대화상자에는 현재 탭과 문서 세대가 함께 묶인다. 오래된 ID나 문서가 바뀐 경우에는 응답을 보내기 전에 거절한다. 작업 쪽에서도 프로필과 실행 세대를 확인하고 원래 결과가 남아 있는 탭과 다른 탭을 혼동하지 않는다. 다른 문서가 같은 문구의 확인창을 띄웠다고 같은 응답 대상으로 취급해서는 안 된다.
외부 제어 통로에도 관찰과 명시 응답이 들어갈 자리가 필요했다. 일반 입력이 대기 중이라는 이유로 그 입력을 풀어 줄 제한된 확인창 관찰까지 모두 막으면 서로 기다리게 된다. 실제 관련 시험은 일반 작업의 경합 차단을 유지하면서 이 고정된 경로가 살아 있는지 본다. 아무 명령이나 동시에 실행할 수 있게 만든 변경은 아니다.
실제 검증 기록과 이번 글의 확인 범위를 나눴다
과거 0.1.215 기록에는 설치판에서 확인창을 MCP로 한 번 처리하고 원래 결과를 확인한 사례가 남아 있다. 원고와 첨부, 기존 탭·프로젝트·설정의 보존도 함께 기록돼 있다. 같은 기록의 회귀·추출본·SDK 시험은 당시 해당 환경의 근거다. 모든 사이트나 다른 컴퓨터의 확인창을 검증했다는 의미로 확대하지 않는다.
이번에는 그 보고서와 현재 선택 소스, 관련 단위·통합 시험을 읽었다. 원래 브라우저를 재시작하거나 원고를 불러오고, 게시·예약을 새로 실행하지 않았다. 최신 공통 실행기록 읽기 수정도 다른 질문으로 남겨 두었다. 한 번의 확인창 복구가 이전의 불확실한 외부 발행 결과까지 해결했다는 보고를 만들지 않으려는 구분이다.
재사용할 것은 자동 확인이 아니라 완료의 기준이다
새 모듈은 브라우저에 답하지 않는다. 문맥을 고정하고 응답 결과, 닫힘, 원래 명령 종료, 원래 조건의 일치를 각각 기록한다. 16개 합성 시험과 ZIP 추출 재시험으로 이 좁은 경계를 확인하며, 다섯 실행 기록을 두 언어의 선택기로 읽을 수 있게 했다. 실제 OS나 원제품 시험의 성공을 새 모듈에 빌려 주지 않았다.
독자가 업무 도구에 이 생각을 적용한다면 먼저 완료 문장을 나눠 보면 좋다. 응답을 보냈다는 것, 확인창이 사라졌다는 것, 원래 명령이 끝났다는 것, 요청한 결과가 확인됐다는 것이 각각 어떤 근거를 필요로 하는지 적는 것이다. 편리한 자동화는 확인 버튼을 빨리 누르는 데서만 나오지 않는다. 다음 입력을 보내도 되는 순간을 정확히 설명할 수 있어야 한다.