도현의 AI 워크플로우

autocomplete는 브라우저가 폼 값을 어떻게 미리 채울지 알려 주는 힌트이고, datalist는 작성자가 제공한 추천 값 목록입니다. 추천 목록을 넣었다고 사용자가 그 안의 값만 제출할 수 있도록 검증까지 끝난 것은 아닙니다. 목차 1. 자동완성이라는 이름을 두 역할로 나눕니다 2. input의 list와 datalist의 id를 연결합니다 3. 목록 밖 입력과 접근성을 확인합니다 1. 자동완성이라는 이름을 두 역할로 나눕니다 AI가 만든 폼을 검토할 때 “자동완성을 넣었다”는 설명만으로 기능을 판단하지 마세요. 저장된 연락처 같은 정보를 채우는 힌트인지, 화면 작성자가 미리 정한 선택지를 제안하는 것인지 먼저 묻는 편이 좋습니다. 구성 역할 따로 확인할 일 autocomplete 브라우저의 사전 입력을 위한 힌트 입력 목적에 맞는 토큰·실제 브라우저 동작 datalist 연결된 입력란의 추천값 목록 밖 값 허용·검증 요구 select 정해진 선택지를 고르는 별도 입력 방식 업무에서 필요한 선택 제한 2. input의 list와 datalist의 id를 연결합니다 아래는 가상의 메모 분류를 제안하는 짧은 예시입니다. 실제 계정 정보나 개인정보를 받지 않는 학습용 코드이며, 동작하는 신청 서비스를 배포한 결과는 아닙니다. <label for="note-topic">메모 분류</label> <input id="note-topic" name="topic" list="topic-ideas"> <datalist id="topic-ideas"> <option value="독서"></option> <option value="생활"></option> </datalist> list의 값과 datalist의 id가 맞아야 연결됩니다. 추천 항목을...

inputmode="numeric" 은 숫자 입력에 맞는 가상 키보드를 보여주기 위한 힌트입니다. 이 속성 하나가 문자 입력을 금지하거나 제출값을 검사해 주지는 않습니다. AI에 ‘숫자만 받는 입력칸’을 부탁한 뒤 휴대폰에서 숫자 키패드가 보였다고 검토를 끝내기 쉽습니다. 무엇을 편하게 입력하도록 할지와 어떤 값을 허용할지는 따로 적어두세요. 목차 1. inputmode가 맡는 역할 2. 짧은 코드에서 빠진 조건 찾기 3. 검수 메모를 두 칸으로 나누기 4. 자주 묻는 질문 1. inputmode가 맡는 역할 MDN은 inputmode를 사용자가 입력할 데이터의 종류를 브라우저에 알려주는 힌트로 설명하고, 이 속성이 유효성 요구사항을 강제하지는 않는다고 명시합니다. numeric은 숫자 키보드, decimal은 사용자의 지역에 맞는 소수 구분자가 포함된 키보드를 위한 값입니다. 마이너스 키 제공 여부는 기기에 따라 달라질 수 있습니다. 따라서 코드 검토 메모에 ‘숫자 입력 완료’라고 한 줄만 쓰면 키보드가 편해졌다는 뜻인지, 값의 허용 조건을 확인했다는 뜻인지 알기 어렵습니다. 입력 화면에서 관찰한 것과 데이터 규칙에 대해 확인한 것을 분리하세요. 2. 짧은 코드에서 빠진 조건 찾기 <label for="sample-code">연습용 코드</label> <input id="sample-code" type="text" inputmode="numeric"> 위 코드는 학습용 예시입니다. 요구사항이 ‘숫자 네 자리’라면 코드를 보는 사람은 네 자리라는 조건을 어디에서 처리하는지 추가로 찾아야 합니다. 숫자 키보드를 기대하는 속성이 있다는 사실만으로 자릿수·빈 값·붙여넣기 처리까지 구현됐다고 표시하지 않습니다. AI에 수정 요청을 할 때도 ‘숫자만 되게’ 대신 실제 필요한 값의 형태를 적어보세요. 예를 들어 ‘이 연습용 칸은 네 자리 문자열을 받으...

파일 입력칸에 accept=".png,.jpg"가 있다고 해서 서버가 이미지 파일만 받도록 검증된 것은 아닙니다. accept는 파일 선택을 돕는 힌트이며, 실제 파일 형식과 크기·전송 처리의 검증은 별도로 확인해야 합니다. 목차 1. accept는 선택창 안내입니다 2. 확장자와 MIME 형식을 구분해 읽으세요 3. 민감하지 않은 작은 샘플로 결과를 비교하세요 4. 자주 묻는 질문 1. accept는 선택창 안내입니다 MDN은 accept 속성을 브라우저가 올바른 파일을 고르도록 돕는 힌트로 설명합니다. 많은 환경에서는 사용자가 다른 파일도 선택할 수 있으므로, 선택된 파일이 요구 조건을 충족하는지는 서버 쪽에서 검증해야 합니다. 가령 AI 초안에 <input type="file" accept=".png,.jpg"> 가 있다면, 먼저 화면의 안내 문구와 실제 허용하려는 형식을 비교하세요. 파일 선택창에서 이미지가 잘 보였다는 결과만으로 파일 내용이나 용량 검사까지 통과한 것으로 기록하지 않습니다. 2. 확장자와 MIME 형식을 구분해 읽으세요 accept에는 점으로 시작하는 확장자, MIME 형식, image/*와 같은 형식 범주를 쓸 수 있고 여러 값은 쉼표로 나눕니다. “사진 한 장만”을 받으려는 화면인지, 여러 이미지를 받으려는 화면인지도 먼저 정해 두세요. 여러 파일 선택은 multiple이라는 별도 속성이 담당합니다. 초안에서 본 것 검수할 질문 accept=".png,.jpg" 안내한 파일 형식과 맞는가 accept="image/*" 범위를 넓게 받으려는 의도인가 multiple 여러 개 선택이 실제 요구사항인가 제출 완료 메시지 선택만 했는지, 전송·접수도 끝났는지 같은 “이미지”라도 운영 목적에 따라 필요한 형식과 용량이 다를 수 있습니다. 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와 연...

AI가 만든 HTML 폼에 이름표가 보이는데 이를 눌러도 입력칸에 연결되지 않는다면, label의 for와 입력칸의 id를 먼저 비교하세요. 화면에서 가까이 놓였다는 것과 코드로 연결됐다는 것은 별개의 확인입니다. 목차 1. for는 입력칸의 id와 연결합니다 2. 보기에는 비슷해도 연결이 끊어진 예시 3. 저장한 화면에서 클릭과 키보드를 함께 확인 4. 입력칸을 label 안에 넣는 방식도 있습니다 5. 자주 묻는 질문 1. for는 입력칸의 id와 연결합니다 W3C WAI의 폼 이름표 안내는 명시적으로 연결할 때 label의 for 값과 폼 컨트롤의 id 값을 정확히 일치시키도록 설명합니다. 먼저 같은 철자로 연결됐는지 확인하고, 화면의 배치만 보고 연결됐다고 판단하지 마세요. <label for="visitor-name">방문자 이름</label> <input id="visitor-name" name="visitor" type="text"> 위 예시에서 이름표는 visitor-name이라는 id를 가리킵니다. 입력칸의 name은 visitor입니다. for가 name을 찾는 것으로 생각해 두 값을 함께 바꿀 필요는 없습니다. 전송에 쓰는 이름과 화면 이름표의 연결을 따로 검수하세요. 항목 이 예시의 값 검수할 질문 label의 for visitor-name 연결할 입력칸의 id와 같은가 input의 id visitor-name 이름표가 가리키는 대상인가 input의 name visitor 전송 항목 이름으로 의도한 값인가 2. 보기에는 비슷해도 연결이 끊어진 예시 <label for="visitor-name">방문자 이름</label> <input id="guest-name" name="visitor" type="text"> 두 번째 예시는 label...

AI가 만든 HTML 폼에서 체크하지 않은 항목이 전송 데이터에 없다고 해서 바로 저장 오류라고 판단하지 마세요. 일반 HTML 체크박스는 미선택 상태에서 이름과 값 자체가 전송되지 않는 동작을 합니다. 목차 1. 화면의 빈 체크칸과 false 값은 다릅니다 2. 선택적 뉴스레터 항목의 예시 3. AI 폼 검수 질문 네 가지 4. 저장 버그로 판단하기 전에 1. 화면의 빈 체크칸과 false 값은 다릅니다 MDN의 HTML 체크박스 문서는 선택하지 않은 체크박스의 이름과 값이 서버에 제출되지 않는다고 설명합니다. 선택한 경우에는 name과 value가 전달되며, value를 생략했으면 기본값 on을 사용합니다. 따라서 빈 체크칸이 보인다는 것, false라는 값이 전송됐다는 것, 수신 데이터에 항목이 없다는 것은 서로 다른 상태입니다. 폼과 서버의 약속이 어떻게 되어 있는지를 확인해야 합니다. 2. 선택적 뉴스레터 항목의 예시 가상의 선택 항목을 name="news" value="yes" 인 체크박스로 만들었다고 가정합니다. 일반 HTML 폼 전송에서 체크하면 news=yes가 전달되고, 체크하지 않으면 news 항목이 빠집니다. 화면·코드 상태 전송 결과의 예시 news를 체크함 news=yes news를 체크하지 않음 news 항목 없음 체크했으나 value를 생략함 news=on 이는 선택적 기능을 설명하는 예시이며 실제 개인정보 동의 양식을 구현한 완성 예시는 아닙니다. 어떤 값을 필수로 받아야 하는지는 제품의 요구와 실제 처리 방식에 맞춰 별도로 정해야 합니다. 3. AI 폼 검수 질문 네 가지 질문 확인할 내용 현재 상태인가? checked 속성의 기본값과 사용자의 현재 선택 구분 이름이 있는가? 전송에 사용할 name과 화면 라벨 구분 값이 무엇인가? 명시한 value와 생략 시 기본값 구분 항목 없음은 어떻게 읽나? 서버가 미선택·누락·오류를 어떻게 처리하는지 필수 동의나 사용자 선택을 임의로 체크한 상태로 바...

입력 칸을 고칠 수 없게 보이게 했다고 제출 데이터까지 같아지는 것은 아닙니다. 텍스트 입력의 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는 접근 권한을 보장하는 보안 경계가 아닙니다. 서버는 전달된 값을 별도로 검증해야 합니다. 제출 전에 값을 복구하는 숨은 스크립트를 더하기보다, 어떤 필드가 제출돼야 하는지와 서버의 기대 형식을 먼저 명확히 하세요. 검토 기록 확인 질...

폼 안의 “미리보기” 버튼을 눌렀는데 제출이 실행된다면 버튼 글자보다 type 속성을 먼저 확인하세요. 일반적인 form에 연결된 button에서 type을 생략하면 기본 제출 동작이 적용됩니다. 목차 1. “미리보기”라는 글자가 동작을 정하지 않습니다 2. 세 가지 역할을 표로 정하기 3. 같은 연습 폼에서 한 항목씩 확인하기 4. 자주 묻는 질문 1. “미리보기”라는 글자가 동작을 정하지 않습니다 MDN은 button의 type으로 submit, reset, button을 설명합니다. 일반적인 폼 안에서 type이 생략된 버튼은 제출 버튼으로 동작할 수 있습니다. 폼 검증에서 제출이 막히는 경우도 있으므로, 눌렀을 때 화면이 바뀌지 않았다는 사실만으로 type이 올바르다고 판단하지 않습니다. <form> <button>미리보기</button> <button type="submit">제출</button> </form> 위 코드는 첫 버튼의 이름과 기본 역할이 어긋날 수 있는 예시입니다. 실제 개인정보나 운영 중인 신청서로 시험하기 전에 복사한 연습 화면에서 확인하는 편이 좋습니다. 2. 세 가지 역할을 표로 정하기 하려는 일 type의 기본 의미 함께 확인할 것 최종 제출 submit 제출 대상과 검증 조건 일반 클릭 동작 button 미리보기 등을 수행할 별도 처리 폼 값 되돌리기 reset 사용자가 입력한 값에 미치는 영향 <button type="button">미리보기</button> <button type="submit">제출</button> type="button"을 쓰면 그 자체의 기본 제출 동작은 없습니다. 그렇다고 미리보기 기능이 자동으로 생기지는 않습니다. 클릭을 처리하는 코드가 필요하고, 그 코드가 다시 제출을 호출하도록 작성돼 있다면 별도로 점검해야 합니다...

HTML의 details에 open="false"를 써도 처음부터 열립니다. open은 불리언 속성이어서 값의 문자열보다 속성이 존재하는지가 기준이기 때문입니다. 처음에 닫힌 상태를 원하면 open 속성 전체를 제거하세요. 목차 1. false라는 글자가 닫힘 스위치는 아닙니다 2. 시작 상태를 비교하는 짧은 예제 3. 코드와 공개 페이지를 함께 확인 4. 자주 묻는 질문 1. false라는 글자가 닫힘 스위치는 아닙니다 MDN은 open이 불리언 속성이라고 설명합니다. 속성이 있으면 펼쳐지고, 없으면 기본적으로 내용이 숨겨집니다. 문자열 "false"를 넣어도 존재하는 속성인 점은 같으므로 닫힌 상태가 되지 않습니다. AI가 만든 HTML 초안이나 다른 예제를 검토할 때 “false라는 단어가 있으니 닫혔겠지”라고 판단하기 쉬운 부분입니다. 코드의 단어 뜻과 브라우저가 속성을 처리하는 규칙을 나눠 보세요. 2. 시작 상태를 비교하는 짧은 예제 작성한 시작 태그 초기 상태 <details> 닫힘 <details open> 열림 <details open="false"> 열림 아래는 이 글을 위해 만든 최소 예제입니다. 닫힌 초기 상태를 원하므로 시작 태그에서 open을 뺐습니다. 펼치는 제목은 summary에 넣고 본문은 그 다음에 둡니다. <details> <summary>준비물 확인</summary> <p>필요한 준비물을 적습니다.</p> </details> 열린 초기 상태를 원할 때만 첫 줄을 <details open> 으로 바꿉니다. 닫힘을 만들려고 빈 문자열이나 "false"로 값을 바꾸는 대신 속성의 존재 여부를 확인하세요. 3. 코드와 공개 페이지를 함께 확인 MDN은 summary를 클릭하거나 포커스가 있을 때 스페이스 키로 펼침 상태를 바꾸는 동작을 설명합니다. ...

AI 초안의 이미지가 로컬 미리보기에서 보였다고 공개 글에서도 같은 주소로 로딩되는 것은 아닙니다. 상대 경로는 기준이 되는 문서 주소에 따라 해석됩니다. 업로드한 파일의 공개 주소와 저장된 src를 직접 대조해야 합니다. 목차 1. 상대 경로는 문자열 두 개를 이어 붙이는 규칙이 아닙니다 2. 끝 슬래시와 맨 앞 슬래시를 대조하는 예시 3. 공개 검수에서 남길 네 가지 증거 4. 자주 묻는 질문 1. 상대 경로는 문자열 두 개를 이어 붙이는 규칙이 아닙니다 MDN은 상대 참조를 현재 디렉터리, 상위 디렉터리, 사이트 루트 등을 기준으로 해석한다고 설명합니다. HTML 이미지의 src에는 상대 주소나 절대 주소를 쓸 수 있지만, CMS에서 저장한 글의 위치와 내 컴퓨터 폴더는 같은 기준이 아닙니다. 예시 도메인과 경로는 아래 비교를 위해 만든 것입니다. 실제 사이트나 이미지를 제공하는 주소가 아닙니다. 공개 글에는 자신의 허용된 미디어 저장소에 실제로 올라간 파일 주소를 사용하세요. 2. 끝 슬래시와 맨 앞 슬래시를 대조하는 예시 기준 주소 src 예시 해석되는 주소 https://example.com/posts/guide/ photo.jpg https://example.com/posts/guide/photo.jpg https://example.com/posts/guide photo.jpg https://example.com/posts/photo.jpg https://example.com/posts/guide/ /images/photo.jpg https://example.com/images/photo.jpg 첫 두 행은 기준 주소 끝의 슬래시가 다릅니다. 마지막 행의 src는 사이트 루트에서 시작합니다. 이 표를 보고 내 CMS의 파일 경로를 추측해 새로 만들지는 마세요. 경로 해석의 차이를 이해한 뒤 실제 저장된 이미지 주소를 확인하는 용도입니다. 파일이 컴퓨터에만 있다면 먼저 플랫폼의 정상 업로드 기능으로 저장합니다. 업로드 성공 메시지, 파일의 공개 주...

공개 화면에 &amp; 가 그대로 남았다면, 먼저 HTML 원문을 넣은 것인지 일반 텍스트로 넣은 것인지 확인하세요. HTML 문자 참조를 두 번 변환한 경우와 코드 예시로 일부러 보여 주는 경우도 나누어야 합니다. 목차 1. 원문과 화면은 같은 문자열이 아닙니다 2. 작은 예시로 변환 횟수 확인 3. 전체 치환 전에 의도부터 나누기 4. 자주 묻는 질문 1. 원문과 화면은 같은 문자열이 아닙니다 WHATWG HTML 표준의 이름 있는 문자 참조 목록은 amp; 를 U+0026의 & , lt; 를 < , gt; 를 > 에 대응시킵니다. HTML 본문의 텍스트로 해석될 때 원문에 적힌 문자 참조와 화면에 보이는 문자는 달라질 수 있습니다. 편집기의 HTML 모드와 일반 글쓰기 모드는 입력을 다루는 방식이 다를 수 있습니다. AI가 준 문자열을 붙여 넣기 전에 현재 모드가 무엇인지 확인하고, 저장한 뒤 실제 미리보기에서 보이는 결과를 읽어야 합니다. 원문에서만 검색하고 검수를 끝내면 표시 문제를 놓칠 수 있습니다. 2. 작은 예시로 변환 횟수 확인 HTML 텍스트 원문 화면의 결과 해석할 질문 Tom &amp; Jerry Tom & Jerry 한 번 해석된 문자 참조인가? Tom &amp;amp; Jerry Tom &amp; Jerry 원하는 결과보다 한 번 더 변환됐나? 코드 예시로 문자 참조를 설명함 &amp; 자체를 보여 줌 의도적으로 보존할 예시인가? 위 표는 화면 결과를 직접 비교하는 예시입니다. 일반 텍스트 편집기에 같은 문자열을 넣었을 때는 HTML로 해석되지 않을 수 있으므로, 표의 결과를 모든 입력창에 그대로 대입하지 마세요. 가상의 제목 “Tom & Jerry”가 목적이라면 제목 칸과 본문 HTML에서 각각 저장 후 표시를 확인합니다. 제목·본문·검색 설명은 별도 입력 항목이므로 한 곳이 맞는다는 이유로 나머지도 맞다고 추정하지 않습니다. 3. 전체 치환 전에 의도부터 나누기...

한국어로 된 HTML 초안이라면 글자가 잘 보이는지만 보지 말고 언어 선언도 확인하세요. AI가 영문 예제 틀을 사용하면 lang="en" 같은 값이 본문 언어와 맞지 않게 남을 수 있습니다. 실제로 그런 오류가 있는지는 초안과 저장된 페이지를 대조해야 알 수 있습니다. 이 글은 웹페이지 전체를 만드는 HTML과 CMS 본문에 넣는 조각을 구분해 검수하는 방법입니다. 언어 선언 하나를 고쳤다고 번역, 접근성 검수, 검색 노출까지 모두 끝났다고 보고하지는 마세요. 목차 1. UTF-8과 lang은 다른 질문입니다 2. 전체 문서와 본문 조각을 구분하기 3. 다른 언어 문장과 저장 결과 확인하기 4. 자주 묻는 질문 1. UTF-8과 lang은 다른 질문입니다 W3C의 언어 선언 안내는 페이지의 기본 텍스트 언어를 html 요소의 언어 속성으로 선언하도록 설명합니다. 반면 문자 인코딩은 자연어를 하나로 식별하는 값이 아닙니다. 같은 UTF-8 문서 안에 여러 언어가 들어갈 수 있으므로 두 항목을 따로 확인해야 합니다. 검수 질문 확인 대상 그것만으로 끝나지 않는 일 글자가 깨지는가? 파일·전송의 인코딩 본문 언어의 정확한 선언 기본 언어가 무엇인가? 페이지 html 요소의 lang 다른 언어 구간의 표시 본문 일부가 다른 언어인가? 해당 구간을 감싼 요소 번역 정확성과 문체 검수 CMS가 그대로 저장했는가? 공개 페이지의 실제 구조 초안 파일만의 확인 예를 들어 한글이 정상 출력되는 페이지라도 기본 언어 값은 따로 확인할 수 있습니다. 반대로 언어 값이 맞아도 글자 깨짐의 원인이 해결됐다고 판단할 수는 없습니다. 증상과 설정의 관계를 한 칸씩 나누는 것이 검수의 출발점입니다. 2. 전체 문서와 본문 조각을 구분하기 직접 만드는 일반 HTML 문서의 한국어 기본 언어 예시는 <html lang="ko"> 처럼 표현할 수 있습니다. 아래 예시는 언어 속성의 위치를 보여 주기 위한 짧은 코드이며 완성된 웹페이지가 아닙...

Markdown에서 [설명](주소) 는 링크이고  는 이미지 문법입니다. AI 초안의 이미지가 글자 링크로만 보이면 맨 앞의 느낌표와 실제 편집기의 Markdown 지원부터 확인하세요. 주소가 있다는 것만으로 이미지가 올라간 것은 아닙니다. 이번 검수는 문법, 완성 이미지의 내용, 공개 경로를 따로 보는 방식입니다. 아래 예시는 설명용이며 reading-room.jpg 라는 실제 파일을 제공하거나 업로드한 주소가 아닙니다. 목차 1. 느낌표와 대괄호의 역할 2. alt와 선택 제목을 나눠 검수하기 3. 저장 뒤 공개 화면에서 확인 4. 자주 묻는 질문 1. 느낌표와 대괄호의 역할  CommonMark 안내는 이미지가 링크와 비슷하지만 느낌표로 시작한다고 설명합니다. 대괄호는 대체텍스트 자리이며 내용이 비어 있어도 문법의 대괄호 자체는 필요합니다. 괄호 안에는 이미지 경로를 넣습니다. 문법을 맞췄어도 HTML 전용 편집기나 일반 텍스트 입력칸에서는 소스가 그대로 남을 수 있습니다. 이때 느낌표를 계속 추가하기보다 편집기가 제공하는 이미지 삽입 기능을 사용하는 것이 맞는지 확인하세요. 2. alt와 선택 제목을 나눠 검수하기 항목 확인 질문 잘못된 완료 판단 대체텍스트 완성된 그림과 본문 맥락을 설명하는가 제작 프롬프트를 그대로 넣음 선택 제목 title 덧붙일 설명이 실제 필요한가 title을 넣었으니 alt도 있다고 생각 이미지 경로 공개 독자가 접근할 수 있는가 내 PC에서 열리니 업로드 완료 공개 표시 이미지가 로딩되고 문구가 잘리지 않는가 편집 미리보기만 확인 대체텍스트에는 이미지 생성 지시를 남기지 마세요. “따뜻한 느낌으로 그려줘”보다 그림의 실제 대상과 관계를 설명하는 문장이 독자에게 도움이 됩니다. 선택 제목을 넣었다고 대체텍스트 검수가 끝나는 것은 아닙니다. 3. 저장 뒤 공개 화면에서 확인 먼저 원고 한 벌을 보존하고, 해당 편집기가 처리하...

AI가 작성한 초안을 옮겼는데 [^1] 이 그대로 보인다면, 먼저 입력한 문법과 최종 편집기의 지원 여부를 확인하세요. 각주가 화면에 예쁘게 붙는지 확인하는 일과, 그 각주가 본문 주장을 뒷받침하는지 확인하는 일은 별개입니다. 위첨자 숫자가 생겼다고 사실 확인까지 끝난 것은 아닙니다. 아래 예시는 GitHub의 공식 각주 설명을 출발점으로, 블로그 초안을 옮길 때 사용할 수 있는 검수 순서를 정리한 것입니다. 목차 1. 본문 표기와 정의가 한 쌍인지 확인 2. 같은 Markdown이어도 최종 화면을 확인 3. 표시 검수 다음에는 근거 검수 4. 자주 묻는 질문 1. 본문 표기와 정의가 한 쌍인지 확인 GitHub Docs는 대괄호 안의 캐럿(^)과 식별자를 이용하는 각주 문법을 안내합니다. 본문의 참조와, 콜론 뒤에 내용을 적는 정의를 맞추어 사용합니다. 아래는 문법을 설명하기 위해 직접 만든 가상 문장입니다. 확인해야 할 안내가 있습니다[^sample]. [^sample]: 안내 원문과 확인 날짜를 적습니다. 검수할 때는 본문에 [^sample] 만 있고 정의가 빠지지 않았는지, 정의의 식별자가 다른 철자로 바뀌지 않았는지 먼저 보세요. 예시의 ‘안내 원문’은 실제 근거를 넣어야 하는 자리이며, 이 문장 자체가 어떤 사실의 출처는 아닙니다. 2. 같은 Markdown이어도 최종 화면을 확인 GitHub의 공식 설명에서는 각주 정의를 본문 가까이에 적더라도 각주가 문서 아래에 표시된다고 안내합니다. 또 GitHub wiki에서는 각주가 지원되지 않는다 고 명시합니다. 따라서 ‘GitHub에서 된 문법이므로 모든 편집기에서 된다’고 생각하면 안 됩니다. GitHub Docs 각주 안내 블로그 편집기로 옮길 때는 짧은 예시 하나를 미리보기에서 확인하세요. 문자로 남는지, 본문 숫자와 각주 내용이 실제로 연결되는지, 스마트폰 화면에서도 읽을 수 있는지를 보시면 됩니다. 지원을 확인하지 못했다면, 해당 편집기의 기본 링크 기능으로 문장 가까이에 출처를 표시하는 방...

AI 초안에서 별표가 강조로 바뀌지 않거나 대괄호가 링크가 되지 않는다면, 해당 기호 앞의 역슬래시를 확인하세요. 기호를 문자 그대로 보여주기 위한 이스케이프일 수 있습니다. 먼저 의도한 결과가 서식인지 실제 기호인지 정해야 고칠 위치가 분명해집니다. 목차 1. 기호 앞의 역슬래시가 하는 일을 확인하세요 2. 코드 영역인지 일반 문장인지 먼저 나누세요 3. 한 문장을 복사해 원문과 미리보기를 비교하세요 4. 자주 묻는 점 1. 기호 앞의 역슬래시가 하는 일을 확인하세요 CommonMark 0.31.2는 ASCII 문장부호 앞에 역슬래시를 붙여 그 기호의 마크다운 기능을 막을 수 있다고 설명합니다. 반면 다른 문자 앞의 역슬래시는 그대로 남을 수 있습니다. 따라서 모든 역슬래시를 일괄 삭제하는 방식은 적절한 검수 순서가 아닙니다. 원문 예시 CommonMark 기준의 읽는 방법 \*배송 안내\* 별표를 포함한 문구로 표시; 강조를 요구한 것과 구분 \[문의\] 대괄호를 문자로 표시하려는 의도 확인 \가나다 한글 앞 역슬래시는 문장부호 이스케이프와 다르게 취급 예시는 원문 자체를 보여주도록 표에 넣었습니다. 실제 게시 도구가 CommonMark와 다른 규칙을 쓰는 경우에는 그 도구의 미리보기도 함께 확인하세요. 2. 코드 영역인지 일반 문장인지 먼저 나누세요 역슬래시 이스케이프 규칙은 코드 블록과 인라인 코드 안에서 같은 방식으로 작동하지 않습니다. 원문을 가르치기 위해 기호를 보여주는 코드 예시를, 일반 본문의 강조 실패와 혼동하지 마세요. 가령 독자에게 입력할 마크다운을 설명하는 문장이라면 별표가 보이는 것이 목표일 수 있습니다. 반대로 행사 안내의 중요한 문구를 강조하려던 문장이라면 별표가 남는 결과를 수정해야 할 수 있습니다. 기호 하나보다 문장의 역할을 먼저 정하면 불필요한 치환을 줄일 수 있습니다. 3. 한 문장을 복사해 원문과 미리보기를 비교하세요 문제가 보이는 한 문장과 주변 문맥을 별도로 보존합니다. 일반 본문인지 코드 예시인지 적습니다. 실제로...

AI가 만든 마크다운에서 [안내][자료] 가 링크 대신 그대로 보인다면, 문서에 맞는 정의 줄이 있는지 확인하세요. 참고 링크는 눈에 보이는 문구와 별도로 적은 라벨을 통해 목적지를 찾습니다. 아래 예시는 CommonMark 0.31.2를 기준으로 설명합니다. 실제 게시 서비스가 마크다운을 지원하는지, 어떤 문법을 적용하는지도 확인해야 합니다. 편집기에 글자를 붙였다는 사실만으로 클릭 가능한 링크가 저장됐다고 보지는 않습니다. 목차 1. 표시 문구·라벨·목적지 세 부분 2. 복사 범위에서 정의가 빠지지 않았는지 3. 같은 라벨을 두 번 쓰면 첫 정의 확인 1. 표시 문구·라벨·목적지 세 부분 [배포 안내][release-note] [release-note]: https://example.com/releases 이 자체 예시에서 표시 문구는 “배포 안내”, 라벨은 “release-note”, 목적지는 예시용 주소입니다. 실제 작업에서는 존재하고 공개된 목적지로 바꾸세요. 정의 줄은 그 링크보다 앞이나 뒤에 둘 수 있고, 자체가 본문 문단으로 표시되는 요소는 아닙니다. 부분 점검할 질문 첫 대괄호 독자가 무슨 안내인지 알 수 있나 둘째 대괄호 정의 줄의 라벨과 맞나 정의 줄 콜론과 목적지가 있는가 공개 화면 실제 링크로 렌더링되고 이동하나 2. 복사 범위에서 정의가 빠지지 않았는지 본문 위쪽만 복사하고 문서 끝의 정의 줄을 빼면 참고 링크가 끊어질 수 있습니다. 원고를 나눠 옮길 때는 링크 사용 부분과 정의를 같은 게시 문서에 포함하세요. 정의 줄은 일반 문단을 중간에서 끊어 만들 수 없습니다. 실무에서는 앞 문단 다음에 빈 줄을 두고 정의를 따로 배치하면 검토하기 쉽습니다. 이 배치는 가독성을 위한 제안이며 모든 위치에서 빈 줄이 필수라는 뜻은 아닙니다. 3. 같은 라벨을 두 번 쓰면 첫 정의 확인 CommonMark는 일치하는 정의가 여러 개면 먼저 나온 정의를 사용합니다. 문서 끝에 새 주소만 추가했는데 링크가 계속 옛 주소로 간다면 앞쪽의 같은 라벨을 ...

AI 초안에 백틱으로 감싼 짧은 구절이 있다면 그 안의 별표나 태그를 일반 본문처럼 해석하지 마세요. CommonMark의 인라인 코드에서는 내용을 코드 구간으로 읽습니다. 별표로 감쌌다고 기울임이 되거나 HTML 태그가 곧바로 적용되는 문맥이 아닙니다. 기준은 CommonMark 0.31.2, 6.1 Code spans 입니다. 실제 게시 도구가 같은 Markdown 규칙을 지원하는지는 별도로 미리보기에서 확인합니다. 목차 1. 시작과 끝의 백틱 길이를 먼저 맞추기 2. 비슷한 문자열 두 개를 구분하기 3. 줄바꿈과 양 끝 공백도 결과에 영향을 줍니다 4. AI 초안을 검수하는 네 단계 5. 자주 묻는 질문 1. 시작과 끝의 백틱 길이를 먼저 맞추기 인라인 코드 구간은 같은 길이의 백틱 묶음으로 열고 닫습니다. 짧은 구절을 감싸는 일반적인 한 개짜리 백틱만 기억하면, 내용 자체에 백틱이 들어가는 예시를 잘못 고칠 수 있습니다. 검수할 때는 여는 기호와 닫는 기호를 먼저 찾고 그 사이를 한 덩어리로 봅니다. 내용에 백틱이 필요하면 더 긴 구분자를 쓰는 방법을 사양에서 확인할 수 있습니다. 본문에서 백슬래시를 붙이면 해결될 것이라고 가정하지 마세요. 코드 구간 안에서는 일반적인 백슬래시 이스케이프가 처리되지 않습니다. 2. 비슷한 문자열 두 개를 구분하기 작성한 문자열 CommonMark에서 확인할 것 검수 질문 *보류* 일반 본문에서는 강조 구문 강조를 의도했는가 `*보류*` 별표까지 코드 내용으로 표시 별표가 보이는 것이 오류인가 `<em>대기</em>` 태그 문자를 코드 내용으로 표시 태그 적용을 기대하고 있지는 않은가 `a b` 코드 구간 내부의 연속 공백 게시 도구의 실제 표시를 확인했는가 표의 예시는 자체 검수용입니다. 원문 문자열과 결과 화면을 나란히 확인해 의도와 다른 부분만 수정하세요. 코드 안의 문장 부호를 문체 교정 대상으로 일괄 삭제하면 설명하려던 문법 예시를 망칠 수 있습니다. 3. 줄바꿈과 양 끝 공백도 결과에 ...

초안에 구분선을 넣었는데 바로 윗문장이 크게 보인다면, 먼저 문장과 --- 사이의 빈 줄 을 확인하세요. CommonMark에서는 문장 바로 아래의 하이픈 줄을 Setext 제목으로 해석할 수 있습니다. 구분선이 목적이면 앞뒤에 빈 줄을 둔 예와 비교해 보세요. 아래는 CommonMark 0.31.2를 기준으로 한 간단한 사례입니다. 게시 플랫폼이 다른 문법이나 자체 편집 규칙을 사용한다면 최종 미리보기에서 결과를 확인해야 합니다. 목차 1. 두 원고의 차이는 빈 줄입니다 2. 하이픈 줄은 앞의 텍스트와 함께 읽힙니다 3. 내용 검수와 서식 검수를 한 표에서 섞지 마세요 4. 간단한 검수 연습 5. 자주 묻는 질문 6. 명세에서 Setext 제목 범위 확인하기 1. 두 원고의 차이는 빈 줄입니다 첫 번째 예는 제목, 두 번째 예는 문단 뒤 구분선이 되는 형태입니다. 문구의 의미를 바꾸는 작업이 아니라 원고의 구조를 명확하게 하는 작업입니다. 검수 메모 --- 위 예는 CommonMark에서 2단계 제목으로 해석됩니다. 검수 메모 --- 다음 문단 두 번째 예는 검수 메모라는 문단과 구분선, 다음 문단을 나눕니다. 예시를 문서에 넣을 때 코드 블록으로 보여 줄지 실제 구조로 사용할지도 구별하세요. 2. 하이픈 줄은 앞의 텍스트와 함께 읽힙니다 명세의 Setext 제목은 텍스트 뒤에 = 또는 -로 된 밑줄을 놓는 형식입니다. =는 1단계, -는 2단계 제목에 해당합니다. 여러 텍스트 줄이 빈 줄 없이 이어졌다면 그 내용이 함께 제목으로 묶일 수도 있습니다. 따라서 구분선 모양만 찾는 검수보다 앞 문단의 끝과 빈 줄을 함께 보는 검수가 유용합니다. 목록·인용문·코드 등 다른 블록 안에서는 별도 규칙이 적용되므로 이 짧은 예를 모든 위치에 그대로 일반화하지 않습니다. 3. 내용 검수와 서식 검수를 한 표에서 섞지 마세요 검수 대상 확인할 질문 수정 후 확인 문장 전달할 의미가 맞는가? 문구를 바꿨다면 의미 재검토 제목 구조 윗문장이 제목이어야 하는가? 제목 단계와...