사용자가 간편하게 가입, 로그인, 계정 세부정보 관리를 할 수 있도록 지원하세요.
사용자가 사이트에 로그인해야 하는 경우 효과적인 가입 양식 디자인이 중요합니다. 이는 특히 인터넷 연결이 불안정하거나, 휴대기기를 사용하거나, 급한 상황이거나, 스트레스를 받고 있는 사용자에게 적용됩니다. 설계가 잘못된 가입 양식은 이탈률이 높습니다. 이탈은 가입 기회를 놓치는 것뿐만 아니라 불만족스러운 사용자를 잃는 것을 의미할 수 있습니다.
다음은 모든 권장사항을 보여주는 매우 간단한 가입 양식의 예입니다.
체크리스트
- 가능한 경우 로그인을 피하세요.
- 계정을 만드는 방법을 명확하게 표시합니다.
- 계정 세부정보에 액세스하는 방법을 명확하게 표시하세요.
- 양식의 불필요한 요소를 삭제합니다.
- 세션 길이 고려
- 비밀번호 관리자가 비밀번호를 안전하게 제안하고 저장하도록 지원합니다.
- 유출된 비밀번호를 허용하지 마세요.
- 비밀번호 붙여넣기 허용
- 비밀번호를 일반 텍스트로 저장하거나 전송하지 마세요.
- 비밀번호 업데이트를 강제하지 마세요.
- 비밀번호를 간편하게 변경 또는 재설정할 수 있습니다.
- 제휴 로그인을 사용 설정합니다.
- 계정 전환을 간편하게 만듭니다.
- 다중 인증 제공 고려
- 사용자 이름을 주의해서 사용합니다.
- 실험실뿐만 아니라 현장에서도 테스트
- 다양한 브라우저, 기기, 플랫폼에서 테스트
가능하면 로그인하지 않기
가입 양식을 구현하고 사용자에게 사이트에서 계정을 만들도록 요청하기 전에 정말로 필요한지 고려하세요. 가능하면 로그인 후에만 기능을 사용할 수 있도록 하지 마세요.
가장 좋은 등록 양식은 등록 양식이 없는 것입니다.
사용자에게 계정을 만들라고 요청하면 사용자가 달성하려는 목표에 방해가 됩니다. 사용자에게 부탁을 하고 개인 정보를 믿고 맡길 것을 요청하는 것입니다. 저장하는 모든 비밀번호와 데이터 항목에는 개인 정보 보호 및 보안 '데이터 부채'가 발생하며, 이는 사이트의 비용과 책임이 됩니다.
탐색 또는 탐색 세션 간에 정보를 저장하기 위해 사용자에게 계정 생성을 요청하는 것이 주된 이유라면 대신 클라이언트 측 저장소를 사용하는 것이 좋습니다. 쇼핑 사이트의 경우 사용자가 구매를 위해 계정을 만들어야 하는 것이 장바구니 이탈의 주요 원인으로 꼽힙니다. 비회원 결제를 기본으로 설정해야 합니다.
로그인을 명확하게 표시
페이지 오른쪽 상단에 로그인 또는 로그인 버튼을 표시하는 등 사이트에서 계정을 만드는 방법을 명확하게 표시합니다. 모호한 아이콘이나 모호한 표현 ('참여하세요', '가입')을 제공하고 탐색 메뉴에 로그인을 숨기지 마세요. 사용성 전문가인 스티브 크루그는 웹사이트 사용성에 대한 이 접근 방식을 생각하게 하지 마세요라고 요약했습니다. 웹팀의 다른 구성원을 설득해야 하는 경우 애널리틱스를 사용하여 다양한 옵션의 영향을 보여주세요.
여기에 표시된 것보다 큰 창 크기에서는 Gmail에 로그인 링크와 계정 만들기 버튼이 표시됩니다.
Google과 같은 ID 제공업체를 통해 가입하고 이메일과 비밀번호를 사용하여 가입한 사용자의 계정을 연결해야 합니다. ID 제공업체의 프로필 데이터에서 사용자의 이메일 주소에 액세스하고 두 계정을 일치시키면 쉽게 할 수 있습니다. 아래 코드는 Google 로그인 사용자의 이메일 데이터에 액세스하는 방법을 보여줍니다.
// auth2 is initialized with gapi.auth2.init()
if (auth2.isSignedIn.get()) {
var profile = auth2.currentUser.get().getBasicProfile();
console.log(`Email: ${profile.getEmail()}`);
}
계정 세부정보에 액세스하는 방법을 명확하게 표시하세요.
사용자가 로그인하면 계정 세부정보에 액세스하는 방법을 명확하게 안내합니다. 특히 비밀번호를 변경하거나 재설정하는 방법을 명확하게 안내합니다.
양식의 불필요한 내용 삭제
가입 과정에서는 복잡성을 최소화하고 사용자의 집중력을 유지하는 것이 중요합니다. 불필요한 항목을 삭제합니다. 지금은 방해나 유혹을 받을 때가 아닙니다.
가입 시 최대한 적은 정보를 요청하세요. 필요한 경우에만, 그리고 사용자가 해당 데이터를 제공하면 분명한 이점을 얻을 수 있는 경우에만 추가 사용자 데이터 (예: 이름, 주소)를 수집합니다. 전송하고 저장하는 모든 데이터 항목에는 비용과 책임이 발생한다는 점에 유의하세요.
사용자가 연락처 세부정보를 올바르게 입력하도록 하기 위해 입력란을 두 번 만들지 마세요. 이렇게 하면 양식 작성 속도가 느려지고 양식 필드가 자동 완성되는 경우에는 적절하지 않습니다. 대신 사용자가 연락처 세부정보를 입력하면 확인 코드를 전송한 후 사용자가 응답하면 계정 생성을 계속하세요. 이는 일반적인 가입 패턴으로 사용자는 익숙합니다.
사용자가 새 기기나 브라우저에서 로그인할 때마다 코드를 전송하여 비밀번호 없이 로그인할 수 있도록 하는 것이 좋습니다. Slack 및 Medium과 같은 사이트에서는 이 버전을 사용합니다.
제휴 로그인과 마찬가지로 이 방법을 사용하면 사용자 비밀번호를 관리할 필요가 없습니다.
세션 길이 고려
사용자 ID에 어떤 접근 방식을 사용하든 세션 길이(사용자가 로그인 상태를 유지하는 시간 및 로그아웃의 원인)에 관해 신중하게 결정해야 합니다.
사용자가 모바일을 사용 중이거나 데스크톱을 사용 중인지, 데스크톱에서 공유 중인지 또는 기기를 공유 중인지 고려하세요.
비밀번호 관리자가 비밀번호를 안전하게 제안하고 저장하도록 지원
서드 파티 및 내장 브라우저 비밀번호 관리자가 비밀번호를 제안하고 저장하도록 지원하면 사용자가 비밀번호를 직접 선택, 기억 또는 입력할 필요가 없습니다. 비밀번호 관리자는 최신 브라우저에서 잘 작동하며 기기, 플랫폼별 앱, 웹 앱 간에 계정을 동기화하고 새 기기에도 동기화합니다.
따라서 가입 양식을 올바르게 코딩하고 특히 올바른 자동 완성 값을 사용하는 것이 매우 중요합니다. 가입 양식의 경우 새 비밀번호에 autocomplete="new-password"를 사용하고 가능하면 다른 양식 필드(예: autocomplete="email" 및 autocomplete="tel")에 올바른 자동 완성 값을 추가합니다. 또한 가입 및 로그인 양식에서 form 요소 자체와 모든 input, select, textarea 요소에 서로 다른 name 및 id 값을 사용하여 비밀번호 관리자를 도울 수 있습니다.
또한 적절한 type 속성을 사용하여 모바일에 적절한 키보드를 제공하고 브라우저의 기본 내장 유효성 검사를 사용 설정해야 합니다.
결제 및 주소 양식 권장사항에서 자세히 알아보세요.
사용자가 안전한 비밀번호를 입력하도록 합니다.
비밀번호 관리자가 비밀번호를 추천하도록 사용 설정하는 것이 가장 좋습니다. 사용자에게 브라우저 및 서드 파티 브라우저 관리자가 추천하는 강력한 비밀번호를 수락하도록 권장해야 합니다.
하지만 많은 사용자가 직접 비밀번호를 입력하려고 하므로 비밀번호 강도에 관한 규칙을 구현해야 합니다. 미국 국립표준기술원(NIST)에서는 안전하지 않은 비밀번호를 피하는 방법을 설명합니다.
유출된 비밀번호 허용 안함
비밀번호에 어떤 규칙을 선택하든 보안 침해로 노출된 비밀번호는 허용해서는 안 됩니다.
사용자가 비밀번호를 입력하면 이미 유출된 비밀번호가 아닌지 확인해야 합니다. Have I Been Pwned 사이트에서 비밀번호 확인을 위한 API를 제공하거나 직접 서비스를 실행할 수 있습니다.
Google 비밀번호 관리자를 사용하면 기존 비밀번호가 유출되었는지 확인할 수도 있습니다.
사용자가 제안한 비밀번호를 거부하는 경우 거부된 이유를 구체적으로 알려줍니다. 사용자가 값을 입력한 즉시 문제를 인라인으로 표시하고 해결 방법을 설명합니다. 가입 양식을 제출하고 서버의 응답을 기다려야 하는 후에 표시하지 마세요.
비밀번호 붙여넣기 금지하지 않음
일부 사이트에서는 비밀번호 입력란에 텍스트를 붙여넣을 수 없습니다.
비밀번호 붙여넣기를 허용하지 않으면 사용자에게 불편을 끼치고 기억하기 쉬운 비밀번호를 사용하도록 유도하여 더 쉽게 침해될 수 있으며, 영국 국가 사이버 보안 센터와 같은 조직에 따르면 실제로 보안이 저하될 수 있습니다. 사용자는 비밀번호를 붙여넣으려고 할 때 나중에 붙여넣기가 허용되지 않는다는 사실을 알게 되므로 비밀번호 붙여넣기를 허용하지 않으면 클립보드 취약점을 방지할 수 없습니다.
일반 텍스트로 비밀번호를 저장하거나 전송하지 마세요.
비밀번호를 솔트 처리 및 해싱해야 하며 자체 해싱 알고리즘을 고안하려고 시도해서는 안 됩니다.
비밀번호 업데이트 강제 안 함
사용자에게 비밀번호를 임의로 업데이트하도록 강요하지 마세요.
비밀번호 업데이트를 강제하면 IT 부서에 비용이 많이 들고 사용자에게 불편을 줄 수 있으며 보안에 큰 영향을 미치지 않습니다. 또한 사용자가 안전하지 않은 기억하기 쉬운 비밀번호를 사용하거나 비밀번호를 기록해 두도록 유도할 수 있습니다.
비밀번호를 강제로 업데이트하는 대신 비정상적인 계정 활동을 모니터링하고 사용자에게 경고해야 합니다. 가능하면 데이터 유출로 인해 유출된 비밀번호도 모니터링해야 합니다.
또한 사용자에게 계정 로그인 기록에 대한 액세스 권한을 제공하여 로그인이 발생한 위치와 시점을 표시해야 합니다.
비밀번호를 간편하게 변경하거나 재설정할 수 있도록 지원
사용자에게 계정 비밀번호를 업데이트하는 위치와 방법을 명확하게 안내합니다. 일부 사이트에서는 놀라울 정도로 어렵습니다.
물론 사용자가 비밀번호를 잊어버린 경우 간편하게 재설정할 수 있도록 해야 합니다. Open Web Application Security Project에서는 비밀번호 분실 시 처리 방법에 관한 자세한 안내를 제공합니다.
비즈니스와 사용자를 안전하게 보호하려면 사용자가 비밀번호가 유출된 것을 발견한 경우 비밀번호를 변경하도록 지원하는 것이 특히 중요합니다. 이를 더 쉽게 하려면 비밀번호 관리 페이지로 리디렉션되는 /.well-known/change-password URL을 사이트에 추가해야 합니다. 이렇게 하면 비밀번호 관리자가 사용자를 사이트의 비밀번호를 변경할 수 있는 페이지로 직접 안내할 수 있습니다. 이 기능은 현재 Safari, Chrome에 구현되어 있으며 다른 브라우저에도 제공될 예정입니다. 널리 알려진 비밀번호 변경 URL을 추가하여 사용자가 비밀번호를 쉽게 변경할 수 있도록 지원에서는 이를 구현하는 방법을 설명합니다.
사용자가 원하는 경우 계정을 간편하게 삭제할 수 있도록 해야 합니다.
서드 파티 ID 공급자를 통한 로그인 제공
많은 사용자가 이메일 주소와 비밀번호 가입 양식을 사용하여 웹사이트에 로그인하는 것을 선호합니다. 하지만 사용자가 제휴 로그인이라고도 하는 서드 파티 ID 공급업체를 통해 로그인할 수 있도록 허용해야 합니다.
이 접근 방식에는 몇 가지 장점이 있습니다. 제휴 로그인을 사용하여 계정을 만드는 사용자의 경우 비밀번호를 요청하거나, 전달하거나, 저장할 필요가 없습니다.
제휴 로그인에서 확인된 추가 프로필 정보(예: 이메일 주소)에 액세스할 수도 있습니다. 즉, 사용자가 해당 데이터를 입력할 필요가 없으며 개발자가 직접 인증할 필요가 없습니다. 통합 로그인을 사용하면 사용자가 새 기기를 구매할 때도 훨씬 쉽게 설정할 수 있습니다.
웹 앱에 Google 로그인 통합에서는 가입 옵션에 제휴 로그인을 추가하는 방법을 설명합니다. 기타 여러 ID 플랫폼을 사용할 수 있습니다.
간편하게 계정 전환하기
많은 사용자가 기기를 공유하고 동일한 브라우저를 사용하여 계정을 전환합니다. 사용자가 제휴 로그인에 액세스하든 안 하든 계정 전환을 간편하게 만들어야 합니다.
다중 인증 제공 고려
다중 인증이란 사용자가 두 가지 이상의 방법으로 인증을 제공하도록 하는 것을 의미합니다. 예를 들어 사용자에게 비밀번호를 설정하도록 요구하는 것 외에도 이메일 또는 SMS 문자 메시지로 전송된 일회용 패스코드를 사용하거나 앱 기반 일회용 코드, 보안 키 또는 지문 센서를 사용하여 인증을 시행할 수 있습니다. SMS OTP 권장사항 및 WebAuthn으로 강력한 인증 사용 설정에서는 다중 인증을 구현하는 방법을 설명합니다.
사이트에서 개인 정보 또는 민감한 정보를 처리하는 경우 다중 인증을 제공하거나 시행해야 합니다.
사용자 이름에 주의하기
사용자 이름이 필요하지 않거나 필요해질 때까지 사용자 이름을 요구하지 마세요. 사용자가 이메일 주소 (또는 전화번호)와 비밀번호만으로 가입하고 로그인할 수 있도록 허용합니다. 원하는 경우 제휴 로그인도 사용할 수 있습니다. 사용자에게 사용자 이름을 선택하고 기억하도록 강요하지 마세요.
사이트에 사용자 이름이 필요한 경우 사용자 이름에 부당한 규칙을 적용하지 마세요. 또한 사용자가 사용자 이름을 업데이트하는 것을 막지 마세요. 백엔드에서는 사용자 이름과 같은 개인 정보를 기반으로 하는 식별자가 아닌 모든 사용자 계정의 고유 ID를 생성해야 합니다.
또한 사용자 이름에 autocomplete="username"를 사용해야 합니다.
다양한 기기, 플랫폼, 브라우저, 버전에서 테스트
사용자가 가장 많이 사용하는 플랫폼에서 가입 양식을 테스트하세요. 양식 요소 기능은 다를 수 있으며 표시 영역 크기의 차이로 인해 레이아웃 문제가 발생할 수 있습니다. BrowserStack을 사용하면 다양한 기기와 브라우저에서 오픈소스 프로젝트를 무료로 테스트할 수 있습니다.
분석 및 실제 사용자 모니터링 구현
사용자가 가입 양식을 사용하는 방식을 파악하려면 실험실 데이터와 현장 데이터가 필요합니다. 애널리틱스 및 실제 사용자 모니터링(RUM)은 사용자의 실제 환경에 관한 데이터 (예: 가입 페이지가 로드되는 데 걸리는 시간, 사용자가 상호작용하는 UI 구성요소 또는 상호작용하지 않는 구성요소, 사용자가 가입을 완료하는 데 걸리는 시간)를 제공합니다.
- 페이지 분석: 가입 흐름의 모든 페이지에 대한 페이지 조회수, 이탈률, 종료
- 상호작용 분석: 목표 유입경로 및 이벤트는 사용자가 가입 절차를 중단하는 위치와 가입 페이지의 버튼, 링크, 기타 구성요소를 클릭하는 사용자의 비율을 나타냅니다.
- 웹사이트 성능: 사용자 중심 측정항목을 통해 가입 절차가 느리게 로드되거나 시각적으로 불안정한지 확인할 수 있습니다.
작은 변화만으로도 가입 양식의 작성 완료율에 큰 차이를 줄 수 있습니다. 애널리틱스 및 RUM을 사용하면 변경사항을 최적화하고 우선순위를 지정할 수 있으며 로컬 테스트에서 노출되지 않는 문제를 사이트에서 모니터링할 수 있습니다.