문자열을 보냈다는 응답만으로 원하는 글이 입력됐다고 보기 어려웠다. 줄바꿈이 사라지거나 편집기가 늦게 반영하고 글자가 일부만 들어갈 수 있다. 나는 입력 뒤 실제 값을 기대한 값과 대조하고, 어긋났을 때 같은 내용을 다시 밀어 넣지 않게 했다.

전달과 반영을 같은 순간으로 보지 않는다

드라이버가 Input.insertText를 보낸 뒤에도 편집기 내부 상태가 따라오는 데 시간이 걸릴 수 있다. 특히 보이는 모듈과 실제 입력이 나뉜 편집기는 네이티브 입력을 비동기로 반영한다. 전송 성공과 값 검증을 따로 둬야 이 차이를 설명할 수 있다.

현재 입력 경로는 verifyFill로 실제 값을 대조한다. 특정 네이티브 편집기 경로에서는 짧은 제한 안에서 읽기만 반복해 반영을 기다린다. 늦다는 이유로 입력을 다시 실행하지 않는다. 기다림이 결과를 읽는 것인지 행동을 반복하는 것인지 코드에서 구분했다.

비교 규칙이 원고를 마음대로 바꾸지 않게 한다

일반 input과 textarea는 실제 value를 기대 문자열과 비교한다. 지정한 편집기 모듈은 그 문단 구조에서 읽은 값을 쓰고 CRLF를 LF로 맞추는 좁은 처리를 한다. 공백과 여러 빈 문단을 무조건 trim해서 성공으로 만드는 방식은 아니다.

빈 contenteditable은 구조적으로 BR이나 빈 문단을 가질 수 있어 좁은 빈 값 판정을 둔다. 하지만 여러 문단과 실제 공백, 내장 매체까지 빈 것으로 지우지는 않는다. 나는 편집기의 표현 차이를 다루되 원고 내용 차이까지 감추지 않는 비교가 필요하다고 봤다.

외부 확인 함수는 값 전체 대신 일치를 돌려준다

browser.verifyField는 checked와 matches 같은 결과를 돌려준다. 확인을 위해 실제 값이 내부에서 읽혀도 호출자에게 본문 전체를 다시 내보내는 일반 추출과는 다른 계약이다. 다만 특정 편집기 구성 확인은 추가 구조 차이를 돌려줄 수 있으므로 모든 결과가 참값 하나라고 단정하지 않는다.

page API는 fill 응답의 새 관찰을 받아 새 참조로 verifyField를 부른다. matches가 거짓이면 FIELD_MISMATCH로 끝낸다. 비교 실패를 가린 채 verified를 표시하거나 자동으로 같은 문장을 다시 쓰지 않는다. 입력값을 확인하는 기능도 현재 문서와 참조 조건 위에서 동작해야 했다.

실패 진단은 차이가 생긴 위치를 좁힌다

네이티브 편집기 입력이 확인되지 않으면 INPUT_NOT_VERIFIED와 제한된 요약을 남길 수 있다. 기대·실제 글자 수와 줄 수, 첫 차이 위치와 일부 문자 코드 같은 자료다. 원고 전체를 진단 로그에 복사하는 방식으로 시작하지 않았다.

이 요약도 민감 정보 검토가 필요 없는 만능 익명화 결과는 아니다. 글자 수와 코드도 자료의 일부이므로 공개할 때는 실제 원고를 넣지 않고 합성 사례로 설명한다. 진단 자료가 있다는 것과 원인이 고쳐졌다는 것도 별개다. 나는 실패를 읽을 수 있게 만들되 자동 재입력의 근거로 쓰지 않게 했다.

값이 맞아도 저장은 다음 질문이다

입력란에 기대한 문장이 있다는 사실은 외부 서버에 원고가 저장됐다는 뜻이 아니다. 미전송 채팅과 편집 중 초안도 값은 맞을 수 있다. 발행·예약·업로드 결과는 각각의 확인 조건을 더 읽어야 한다. 입력 검증을 전체 업무 완료로 확대하지 않는다.

기존 page API fixture 시험은 새 참조를 사용한 값 확인과 변경 횟수를 본다. 일반 입력·유니코드 관련 과거 시험의 범위도 따로 남아 있다. 이 글은 현재 readback 구현과 해당 시험 코드를 대조했다. 실제 업체 원고를 넣어 새 외부 저장 시험을 수행하지 않았다.

고객에게도 어느 단계가 끝났는지 보여 준다

업무 프로그램에서 입력 완료와 저장 완료를 다른 문구로 보여 주면 사용자가 현재 상태를 이해하기 쉽다. 에이전트도 마찬가지다. 필드 일치, 저장 확인, 외부 공개를 같은 성공으로 쓰지 않아야 다음 행동을 정확히 고른다.

나는 값 확인을 잘못된 입력을 조용히 고치는 장치보다 차이를 드러내는 경계로 만들었다. 입력이 늦으면 읽고, 다르면 멈추고, 저장이 필요하면 별도 결과를 확인한다. 편집기마다 읽는 표현과 제한이 다르므로 새 서비스를 연결할 때는 그 규칙을 합성 원고로 재현하고 실제로 검증해야 한다.