휴대전화에서 이메일 주소를 적으려는데 @를 입력하려면 키보드를 바꿔야 합니다. 저장된 주소도 제안되지 않고, 붙여 넣은 주소의 일부 문자가 지워집니다. 입력칸 하나의 문제처럼 보이지만 형식, 자동완성, 키보드, 값 처리라는 서로 다른 결정이 겹친 결과일 수 있습니다.
이메일 폼을 만들 때는 어떤 값인지, 누구의 어떤 정보인지, 어떤 입력 도구가 편한지를 각각 정합니다. 여기서는 문의 답변을 받을 주소를 입력하는 상황을 중심으로 설명하고, 로그인 이름으로 이메일을 쓰는 경우와도 비교합니다.
세 속성은 서로 대신하지 않습니다
| 속성 | 담당하는 역할 | 보장하지 않는 것 |
|---|---|---|
type="email" | 이메일 형식의 입력과 브라우저 기본 검사 | 주소 존재·소유권·메일 수신 |
autocomplete="email" | 입력값의 의미를 알려 자동완성에 도움 | 모든 기기의 동일한 제안 표시 |
inputmode="email" | 이메일에 맞는 가상 키보드의 힌트 | 이메일 형식 검사나 강제 키보드 배열 |
| required | 이 입력칸을 비워 제출하지 못하도록 제약 | 주소가 실제 회신 가능한지 여부 |
MDN은 inputmode가 입력 형식을 강제하지 않는 힌트라고 설명합니다. 따라서 type="text" inputmode="email"만 넣고 형식 검사가 된다고 생각하면 안 됩니다. 반대로 type="email"은 여러 모바일 브라우저에서 적절한 키보드를 유도하므로 inputmode를 반드시 함께 써야만 @키가 생긴다는 식의 규칙도 정확하지 않습니다.
회신 주소에는 목적과 레이블을 함께 둡니다
다음 HTML은 문의 폼 안에 넣을 입력 부분의 예입니다. 전송 코드가 아니며, 실제 수집 목적과 개인정보 안내는 운영 방식에 맞게 작성해야 합니다. placeholder가 입력 뒤 사라지더라도 필드 이름은 남도록 label을 연결합니다.
<label for="reply-email">답변받을 이메일</label>
<p id="reply-email-help">문의 답변을 받을 주소를 입력하세요.</p>
<input id="reply-email"
name="reply_email"
type="email"
autocomplete="email"
inputmode="email"
spellcheck="false"
aria-describedby="reply-email-help"
required>id와 label의 for를 연결하고, 서버에서 어떤 값인지 구분할 name도 둡니다. 자동완성은 브라우저에 저장된 정보와 구현 조건의 영향을 받습니다. 속성을 넣었는데 제안이 안 보인다고 바로 실패로 단정하지 말고 저장 정보가 있는 환경과 없는 환경을 나눠 확인합니다.
W3C의 Identify Input Purpose는 사용자 자신의 정보를 받는 해당 입력 목적을 프로그램이 파악할 수 있어야 한다는 기준을 설명합니다. 브라우저가 실제로 자동 입력해 주는 장면만으로 판정하는 기준은 아닙니다. 문의 대상이 누구이며 이메일을 왜 받는지 정하는 내용은 문의 페이지의 범위와 회신 안내와 함께 설계할 수 있습니다.
로그인 ID라면 같은 이메일 문자열도 목적이 다릅니다
이메일 주소를 계정 이름으로 쓰는 로그인 화면이라면 자동완성 목적은 username으로 표현하는 방식을 검토합니다. 입력 형식이 이메일뿐인 서비스는 type="email" autocomplete="username"처럼 형식과 목적을 함께 나타낼 수 있습니다. 일반 아이디도 허용하는 로그인이라면 이메일 형식으로만 제한하면 안 됩니다.
영수증을 받을 주소와 사용자가 로그인하는 주소가 다른 화면도 있습니다. 두 칸을 같은 필드처럼 취급해 하나를 고칠 때 다른 값을 덮지 않도록 구분합니다. 주소를 두 번 확인 입력하게 하는 방식도 목적을 검토해야 합니다. 단순 반복 입력이 실제 오발송을 해결하는지, 사용자가 붙여넣거나 저장된 주소를 선택할 수 있는지를 함께 생각합니다.
주소를 친절하게 고쳐 주려다 다른 값으로 만들지 않습니다
모든 주소를 단순한 영문·숫자 조합으로 가정하면 name+project@example.com 같은 형태를 막을 수 있습니다. @앞의 플러스 기호나 점을 일괄 삭제하는 처리는 사용자가 입력한 주소를 바꿉니다. 겉보기에 비슷한 주소를 자동으로 합치거나 전체를 임의 규칙으로 소문자화하기 전에 백엔드와 메일 처리 정책을 확인해야 합니다.
도메인 오타가 의심돼도 사용자 동의 없이 유명 메일 서비스의 주소로 바꾸지 않습니다. “example.con이 맞나요?”처럼 확인을 도울 수는 있지만 원래 주소를 수정할 수 있는 상태로 남겨야 합니다. 자동완성에서 회사의 옛 주소가 선택된 경우도 있으므로 최종 확인 화면에서 입력값을 다시 읽을 수 있게 합니다.
| 입력 상황 | 관찰할 내용 | 피할 처리 |
|---|---|---|
| name+project@example.com 붙여넣기 | 플러스와 전체 주소가 유지되는가 | 기호를 지워 다른 주소 만들기 |
| 긴 이름과 하위 도메인 | 입력 끝과 커서 위치를 확인할 수 있는가 | 짧은 고정 길이로 잘라 저장 |
| 저장된 옛 주소 선택 | 수정 후 새 값이 유지되는가 | 자동완성이 수정값을 다시 덮음 |
| 잘못된 형식 name.example.com | 구체적인 형식 안내가 나오는가 | 내용을 모두 지우고 처음부터 입력 요구 |
이 예시는 실제 이메일로 보내는 테스트 목록이 아닙니다. 계정이나 고객 정보를 수집하지 않는 허용된 시험 환경에서 입력 보존과 안내를 살펴보는 데 사용합니다. 국제화된 주소의 지원 범위는 브라우저 기본 검사와 서버·메일 서비스가 다를 수 있으므로, “모든 이메일을 지원한다”는 문구를 검증 없이 붙이지 않습니다.
형식이 맞아도 주소가 존재한다는 뜻은 아닙니다
MDN의 email 입력 문서는 형식 검사가 주소의 존재를 증명하지 않는다고 설명합니다. 빈 값 허용 여부도 required 같은 제약에 따라 달라집니다. 클라이언트 검사는 우회될 수 있으므로 서버의 입력 검증과 오류 처리도 필요합니다. 이때 서버가 거절한 이유를 사용자에게 필요한 범위에서 설명하고, 입력한 값은 가능한 한 보존합니다.
주소 소유 확인이 업무상 필요한 경우에는 별도의 확인 절차가 필요합니다. 하지만 회신 문의를 받는 폼마다 회원가입 수준의 인증을 강제할 필요가 있는지는 따로 판단해야 합니다. 형식이 맞음, 전송 요청이 성공함, 수신함에 도착함, 상대가 읽음은 서로 다른 상태입니다. 문의의 전송·수신·답변 구분으로 확인할 단계를 정할 수 있습니다.
키보드 모양보다 입력 과정을 끝까지 봅니다
모바일에서 @키가 보이는지 확인한 뒤에는 자동완성 선택, 중간 글자 수정, 전체 붙여넣기, 필수값을 비운 제출까지 이어갑니다. 가로로 긴 주소라도 입력칸 전체를 줄여 글자를 지나치게 작게 만들기보다 커서와 끝부분을 확인할 수 있도록 합니다. 주소가 화면에 짧게 보인다는 사실과 서버로 잘려 보내지는 문제는 별도로 대조합니다.
오류 메시지를 띄울 때는 “잘못되었습니다”만 쓰지 말고 이메일 형식을 확인할 수 있도록 설명합니다. 오류를 위쪽 요약과 입력칸 가까이에 연결하는 방법은 문의폼 오류 요약이 다룹니다. 이 글에서 정한 속성들은 그보다 앞단에서 올바른 정보를 편하게 입력하도록 돕는 장치입니다.
참고한 공식 자료
원문 확인일: 2026년 10월 4일. 수치와 화면 구성은 설명용 예제이며 실제 고객 사이트의 측정 결과가 아닙니다.