HTML autocomplete 속성 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

HTML autocomplete 속성 기준 정리

autocomplete 속성은 브라우저가 입력값을 자동완성하거나 자동채움할 때 어떤 의미로 해석해야 하는지 알려 주는 힌트다. 2026년 7월 10일 확인 기준 WHATWG HTML Living Standard는 이 속성이 단순히 on과 off만 받는 것이 아니라, section-*, shipping, billing, username, one-time-code 같은 detail token 조합도 받을 수 있다고 설명한다.

실무에서 헷갈리는 지점은 세 가지다. 자동완성을 완전히 끄고 싶은 경우에 off가 어디까지 의미가 있는지, 주소나 결제 폼처럼 같은 종류의 필드를 여러 묶음으로 나눌 때 어떤 token 조합을 써야 하는지, 그리고 form과 각 개별 필드의 autocomplete 중 무엇이 우선하는지다. 이 글은 WHATWG HTML Living Standard를 기준으로 선택 규칙만 정리한다.

autocomplete는 정확히 무엇을 제어할까?

표준은 autocomplete를 브라우저가 사용자의 과거 입력을 기억해 제안하거나, 저장된 프로필 정보를 미리 채울 때 참고하는 규칙으로 다룬다. 즉 서버 검증 규칙이나 입력 필수 여부를 정하는 속성은 아니다.

그래서 이 속성은 "이 필드가 어떤 데이터인지"를 브라우저에 알려 주는 의미가 강하다. 이름, 이메일, 현재 비밀번호, 새 비밀번호, 1회용 코드처럼 의미가 분명한 token을 주면, 브라우저는 그 의미에 맞는 자동채움 동작을 선택할 수 있다.

on, off, detail token은 언제 구분할까?

상황	무난한 선택	이유
필드 의미를 명확히 전달하고 싶다	detail token 사용	username, email, postal-code처럼 의미 기반 자동채움이 가능하다
폼 단위로 일반 자동완성 허용 여부만 정하고 싶다	on 또는 off	가장 단순한 전체 기본값을 줄 수 있다
배송지와 청구지처럼 같은 필드가 두 묶음 있다	section-*와 shipping/billing 조합	브라우저가 서로 다른 그룹으로 구분하기 쉽다
숨김 필드에 의미 토큰을 주고 싶다	detail token만 사용	표준상 hidden input에서는 on, off를 쓸 수 없다

폼에만 지정하면 각 필드가 모두 따라갈까?

표준 처리 모델을 보면 개별 필드에 유효한 autocomplete 값이 없을 때는 form 소유자의 설정을 참고할 수 있다. 그리고 그것도 없으면 최종 기본값은 on 쪽으로 정리된다.

따라서 운영 기준은 단순하다. 폼 전체에서 대체로 허용 또는 비허용을 정하고 싶다면 <form autocomplete="...">에 기본값을 두고, 예외가 필요한 필드만 개별 token으로 덮어쓰는 구성이 읽기 쉽다.

detail token은 어떤 순서로 쓰는 편이 맞을까?

WHATWG 표준은 detail token 목록을 단일 문자열로 해석하며, 경우에 따라 최대 token 수와 카테고리를 검사한다. 실무에서는 보통 다음 순서를 유지하면 혼란이 적다. 필요하면 먼저 section-*로 그룹을 나누고, 그다음 shipping 또는 billing을 붙인 뒤, 마지막에 실제 필드 의미인 street-address, postal-code, email 같은 token을 둔다.

<input autocomplete="section-checkout shipping postal-code">
<input autocomplete="section-checkout billing postal-code">
<input autocomplete="username">
<input type="password" autocomplete="current-password">

이렇게 두면 같은 우편번호라도 배송지와 청구지가 서로 다른 목적이라는 점을 브라우저에 더 분명하게 전달할 수 있다.

off를 주면 브라우저가 반드시 기억하지 않을까?

표준은 autocomplete의 필드 이름이 off일 때 사용자 에이전트가 값을 기억하지 않고 과거 값을 제안하지 않아야 한다고 설명한다. 다만 같은 표준은 사용자 에이전트가 사용자가 원하면 이 설정을 재정의할 수 있다고도 둔다.

즉 작성자 입장에서 off는 강한 힌트이지만, 절대적인 강제 장치로 보면 안 된다. 민감 정보 보호가 정말 중요하다면 자동완성 속성만 기대하지 말고 인증 흐름과 저장 정책 전체를 함께 봐야 한다.

 

 

hidden input에도 on이나 off를 써도 될까?

표준은 hidden 상태의 input에서는 on과 off 키워드를 허용하지 않는다. 이 경우에는 autofill detail token 목록만 허용된다.

그래서 hidden input에 의미를 남기고 싶다면 일반 토글 키워드보다 실제 목적 token을 써야 한다. 반대로 그냥 습관적으로 모든 input에 autocomplete="off"를 넣는 패턴은 hidden 필드에서는 표준과 맞지 않을 수 있다.

로그인, 비밀번호 변경, 일회용 코드 입력은 어떻게 나눌까?

필드 의미	권장 token	구분 이유
로그인 식별자	username	이메일 형식 아이디가 아니어도 식별자 의미를 직접 전달할 수 있다
현재 비밀번호	current-password	기존 로그인 자격 증명과 연결된다
새 비밀번호	new-password	비밀번호 생성 또는 변경 흐름임을 구분한다
일회용 인증 코드	one-time-code	영구 저장 비밀번호와 다른 입력 의미를 전달한다

실무에서 무난한 작성 기준

• 필드 의미가 명확하면 on보다 detail token을 우선한다.
• 같은 종류 필드가 두 세트 이상이면 section-*와 shipping/billing으로 묶음을 구분한다.
• 폼 기본 정책은 form에 두고, 예외 필드만 개별 속성으로 덮어쓴다.
• off를 보안 강제 수단으로 오해하지 않는다.
• hidden input에는 on, off 대신 허용된 detail token만 쓴다.

FAQ

Q. 이메일 입력이면 항상 autocomplete="email"만 쓰면 될까?

대체로 그 편이 더 명확하다. 표준상 필드 의미를 직접 주는 token이 자동채움 해석에 더 유용하다. 다만 로그인 식별자가 꼭 이메일 형식인 것은 아니라면 username이 더 맞을 수 있다.

Q. form autocomplete="off"면 모든 하위 필드가 완전히 비활성화될까?

표준 처리 모델상 기본값에는 영향을 줄 수 있지만, 브라우저가 사용자 선택으로 이를 재정의할 여지도 남아 있다. 그리고 개별 필드의 유효한 값이 따로 있으면 그 해석도 함께 봐야 한다.

Q. 주소 폼에서 청구지와 배송지가 같아 보여도 token을 나눠야 할까?

두 묶음을 실제로 별도 입력받는 화면이라면 나누는 편이 안전하다. 표준은 billing과 shipping 구분 token을 제공하므로, 같은 postal-code라도 목적을 구분할 수 있다.

정리

autocomplete 속성은 단순 편의 기능이 아니라, 브라우저가 필드 의미를 읽는 힌트 체계다. 2026년 7월 10일 기준 WHATWG HTML Living Standard를 기준으로 보면 핵심은 세 가지다. 가능하면 detail token으로 의미를 직접 주고, 같은 종류 필드가 여러 세트면 section-*와 shipping/billing을 함께 쓰며, off는 절대 강제가 아니라는 점이다.

대부분의 서비스에서는 로그인, 주소, 결제 폼처럼 의미가 분명한 곳부터 token을 명시하는 구성이 무난하다. 반대로 모든 필드에 기계적으로 autocomplete="off"를 넣는 방식은 표준 의도와도 맞지 않고, hidden input에서는 아예 허용되지 않을 수 있다.

참고 자료

• WHATWG HTML Living Standard: Autofill and the autocomplete attribute