화면에서 보이는 값과 제출 항목은 다릅니다
대출 신청 화면에 항목 코드 K17이 보인다고 합시다. 사용자가 그 코드를 고칠 수 없도록 만든 입력란도 구현 방법은 여러 가지입니다. disabled(디세이블드, 비활성화)는 입력란을 비활성 상태로 만들고, readonly(리드온리, 읽기 전용)는 텍스트를 사용자가 수정하지 못하게 합니다.
두 입력란은 비슷하게 보여도 폼 데이터 구성 결과가 다릅니다. 브라우저의 표준 절차는 비활성화된 필드를 건너뜁니다. 반면 읽기 전용이라는 이유만으로 필드를 제외하지 않습니다. 화면에 값이 있는지와 제출 항목에 그 값이 있는지를 각각 확인해야 합니다.
같은 코드로 상태 하나만 바꾸어 봅니다
활동은 입력란 이름을 code, 값을 K17로 시작합니다. 상태를 비활성화로 두면 화면에는 K17이 보이지만 데이터 항목은 빈 배열입니다. 읽기 전용으로 바꾸면 화면의 값은 같아도 code와 K17이라는 이름·값 한 쌍이 나타납니다.
결과 영역은 상태 이름을 보고 답을 흉내 내지 않습니다. 실제 폼 요소에 new FormData(form)을 실행한 결과를 표시합니다. 일반 입력 상태로 바꾸어 K18처럼 가상 코드를 고친 뒤 읽기 전용으로 바꾸면, 바뀐 값이 그대로 포함되는지도 확인할 수 있습니다. 브라우저 안의 구성 결과이며 전송 성공 표시가 아닙니다.
읽기 전용이어도 이름이 없으면 항목이 만들어지지 않습니다
입력란의 id는 화면에서 요소를 식별하거나 설명과 연결할 때 쓰지만, 폼 데이터의 항목 이름을 대신하지 않습니다. 이 활동의 name(네임, 제출 항목 이름) 선택을 “이름 없음”으로 바꾸어 보세요. 읽기 전용이고 K17이 보이더라도 항목은 사라집니다.
이름이 없는 경우와 값이 빈 경우도 다릅니다. 이름 code는 유지한 채 일반 입력에서 값을 모두 지우면 code와 빈 문자열이라는 항목이 남습니다. 수신하는 프로그램은 항목 누락과 빈 값을 다르게 처리할 수 있으므로 AI가 둘을 같은 것으로 정리해서는 안 됩니다.
체크박스와 서버 검증에는 별도의 규칙이 필요합니다
여기서 비교한 것은 텍스트 입력란입니다. readonly는 체크박스와 버튼에 같은 방식으로 적용되지 않습니다. 또 상위 fieldset의 비활성화나 사용자 스크립트가 제출 데이터를 다시 만드는 경우처럼 추가 조건이 있으면 더 확인할 사항이 생깁니다.
읽기 전용은 사용자가 화면에서 편집하는 동작을 제한하는 속성이지 데이터의 진위를 보증하는 보안 장치가 아닙니다. 서버가 코드를 믿어도 되는지는 권한과 원래 기록을 별도로 검증해야 합니다. 화면의 제한만으로 신뢰성을 판단하지 않는 것이 AI의 검토에도 중요합니다.
AI의 보고에는 구성·전송·저장을 따로 적습니다
“입력란에 K17이 표시됨”, “폼 데이터에 code=K17이 포함됨”, “서버가 그 값을 받음”, “서버에 저장됨”은 서로 다른 관찰입니다. 이 실험으로 확인하는 것은 두 번째 단계까지입니다. 전송과 저장은 실행하지 않았으므로 성공했다고 쓸 수 없습니다.
상태와 name을 조합해 예측한 뒤 결과를 비교하세요. 값이 누락되면 먼저 disabled와 name을 확인하고, 그다음 실제 전송 코드를 조사하는 순서를 만들 수 있습니다. AI에게 화면 사진만 주고 제출 결과까지 확정하라고 요구하기보다, 어떤 증거가 더 필요한지 물어보는 편이 정확합니다.