도현의 AI 워크플로우

AI가 만든 number 입력칸에서 1.5가 거부되면 최솟값·최댓값만 보지 말고 step도 확인하세요. min=0인 예제에서 step을 생략하면 기본 간격은 1이므로, 범위 안의 소수라도 유효성 검사를 통과하지 못할 수 있습니다. 목차 1. 범위 안이라는 말과 유효하다는 말 2. 같은 범위에서 간격만 바꾼 예제 3. any와 pattern을 다른 역할로 읽기 4. AI 초안에 돌려줄 구체적인 수정 요청 5. 자주 묻는 질문 1. 범위 안이라는 말과 유효하다는 말 min과 max는 숫자의 범위를, step은 기준값에서 허용되는 간격을 정합니다. MDN은 number 입력의 기본 step을 1로 설명하며, 간격의 기준은 min이 있으면 min, 그렇지 않으면 value, 둘 다 없으면 0이라고 안내합니다. 그래서 검수 메모에는 “0부터 10까지”만 쓰지 말고 “0부터 10까지, 0.5 간격”처럼 의도한 단위까지 남기는 편이 좋습니다. AI에게 요청한 문장과 생성된 속성을 나란히 대조할 수 있습니다. 2. 같은 범위에서 간격만 바꾼 예제 <input type="number" min="0" max="10"> <input type="number" min="0" max="10" step="0.5"> 입력 예시 기본 간격 1 0.5 간격 1 간격에 맞음 간격에 맞음 1.5 간격에 맞지 않음 간격에 맞음 1.25 간격에 맞지 않음 간격에 맞지 않음 11 최댓값 초과 최댓값 초과 위 표는 표시한 두 코드와 값의 수학적 관계를 정리한 자체 예제입니다. 모든 브라우저의 오류 문구나 화살표 모양이 같다는 뜻은 아닙니다. 실제 편집기에서 저장된 속성과 사용자가 값을 입력한 뒤의 검증 결과를 함께 확인하세요. 3. any와 pattern을 다른 역할로 읽기 간격 제한이 필요 없는 수치라면 step="any"가 있습니다. 다...

AI가 만든 텍스트 입력칸에 minlength="3"이 있어도 빈칸을 반드시 막는 것은 아닙니다. 최소 길이 조건과 필수 입력 조건은 다르기 때문입니다. 필수로 받을 정보라면 required도 확인하고, 빈칸·짧은 값·충족한 값을 실제로 입력해 각각 검수하세요. 목차 1. 최소 길이와 필수 여부를 나누기 2. 목적을 정한 뒤 required 추가 3. 실제 입력으로 검수 기록 남기기 4. 자주 묻는 질문 1. 최소 길이와 필수 여부를 나누기 MDN은 minlength가 required를 뜻하지 않으며, 필수가 아닌 입력칸은 빈 문자열인 상태로 제출할 수 있다고 설명합니다. 입력한 값의 길이 조건과 아예 값을 넣어야 하는 조건을 같은 것으로 읽지 마세요. 여기서는 일반 text 입력칸의 브라우저 기본 검증을 예로 듭니다. 길이는 UTF-16 코드 단위로 계산하므로 이모지 등이 포함되면 눈에 보이는 글자 수와 다를 수 있습니다. 아래 표는 이 차이가 생기지 않는 영문 ab·abc 예시로 비교합니다. <label for="nickname">별명</label> <input id="nickname" name="nickname" type="text" minlength="3"> 같은 입력칸에서 검수 minlength="3"만 있을 때 required도 있을 때 빈칸 필수 조건이 아니므로 빈 값 허용 필수 값 누락 확인 직접 입력한 ab 최소 길이 미달 확인 최소 길이 미달 확인 직접 입력한 abc 길이 조건 충족 이 두 조건 충족 MDN minlength의 빈 값 조건 확인 2. 목적을 정한 뒤 required 추가 정말 필수로 받아야 하는 값인지 먼저 정하세요. 모든 칸을 필수로 바꾸는 것이 검수의 목적은 아닙니다. 필수 항목에는 사용자에게 보이는 안내와 적절한 이름표도 필요합니다. 화면에 별표를 붙였다는 사실과 H...

라디오 선택지마다 글자가 붙어 있어도 “무엇을 고르는 질문인지”가 빠질 수 있습니다. 관련 선택지는 fieldset으로 묶고 legend에 짧은 질문을 쓰세요. 각 선택지의 label도 따로 필요합니다. 목차 1. 질문을 읽지 않고도 선택지를 이해할 수 있나요? 2. 수령 방법 예시를 요소별로 읽어 보세요 3. AI 초안을 검수할 때는 관계를 질문하세요 4. 자주 묻는 질문 1. 질문을 읽지 않고도 선택지를 이해할 수 있나요? “직접 수령”, “택배 수령”은 선택지의 이름입니다. 이 둘이 답하는 질문은 “수령 방법”입니다. 화면에 질문을 굵게 쓰는 것과 입력 요소에 그 관계를 전달하는 것은 별도로 검수해야 합니다. W3C WAI는 관련 폼 요소를 시각적으로, 코드 안에서도 묶으라고 안내합니다. fieldset은 관련 요소의 컨테이너이고 legend는 묶음의 제목입니다. 라디오 버튼 그룹은 이 구분을 확인하기 좋은 예입니다. W3C 폼 요소 묶기·legend 공식 예시 보기 2. 수령 방법 예시를 요소별로 읽어 보세요 <fieldset> <legend>수령 방법</legend> <input type="radio" id="pickup" name="delivery" value="pickup"> <label for="pickup">직접 수령</label> <input type="radio" id="shipping" name="delivery" value="shipping"> <label for="shipping">택배 수령</label> </fieldset> 요소 이 예시의 역할 legend “수령 방법”이라는 그룹 질문 label for 각 input의 고유id와 연...

입력 칸을 고칠 수 없게 보이게 했다고 제출 데이터까지 같아지는 것은 아닙니다. 텍스트 입력의 readonly와 disabled를 나누어 실제 FormData 항목 을 확인하세요. 목차 1. 보이는 상태와 제출 데이터를 나누기 2. 작은 폼에서 차이 확인 3. 서버 검증은 별도로 유지 4. 자주 묻는 질문 1. 보이는 상태와 제출 데이터를 나누기 WHATWG HTML 표준은 readonly를 사용자 편집을 막는 속성으로 설명합니다. disabled와 같은 뜻이 아니며 readonly는 텍스트 계열 입력에 적용됩니다. 체크박스나 버튼에 같은 효과가 있다고 가정하지 마세요. AI가 작성한 프로필 수정 화면을 검토한다면, 변경 불가 ID를 readonly로 보여 주는지 disabled로 비활성화하는지 먼저 읽습니다. 이 선택이 서버에서 필요한 값을 빠뜨리거나 예상과 다른 제출을 만들 수 있습니다. 2. 작은 폼에서 차이 확인 직접 구성한 로컬 예제는 name="account" value="reader" readonly와 name="plan" value="basic" disabled를 같은 폼에 두고 new FormData(form)을 읽습니다. 확인 결과 account=reader는 포함되고 plan은 제외됐습니다. 실제 서비스의 계정 정보나 인증 자료는 사용하지 않았습니다. 예제 입력 편집 상태 FormData 확인 account / readonly 사용자 수정 제한 account=reader 포함 plan / disabled 비활성화 plan 항목 제외 속성만 보고 판단 화면이 비슷해 보임 실제 키·값을 함께 비교 3. 서버 검증은 별도로 유지 readonly는 접근 권한을 보장하는 보안 경계가 아닙니다. 서버는 전달된 값을 별도로 검증해야 합니다. 제출 전에 값을 복구하는 숨은 스크립트를 더하기보다, 어떤 필드가 제출돼야 하는지와 서버의 기대 형식을 먼저 명확히 하세요. 검토 기록 확인 질...