가입 양식 권장사항

사용자의 가입, 로그인 및 계정 세부 정보 관리 작업을 간단히 수행할 수 있습니다.

사용자가 사이트에 로그인해야 하는 경우 로그인 양식을 잘 설계하는 것이 중요합니다. 이러한 현상은 연결 상태가 좋지 않거나 모바일을 사용하거나 서두르거나 스트레스를 받는 사용자에게 특히 그렇습니다. 디자인이 부실한 가입 양식은 이탈률이 높습니다. 이탈이 발생할 때마다 사용자가 이탈하거나 불만족스러워하게 된다는 의미는 단순히 가입 기회를 놓친 것이 아니라는 의미일 수 있습니다.

다음은 모든 권장사항을 보여주는 매우 간단한 가입 양식의 예입니다.

체크리스트

가능하면 로그인하지 않음

가입 양식을 구현하고 사용자에게 사이트에서 계정을 만들도록 요청하기 전에 정말로 필요한지 여부를 고려하세요. 가능하면 로그인이 필요한 기능을 제한하는 것은 피해야 합니다.

가장 좋은 가입 양식은 '가입 양식 없음'입니다.

사용자에게 계정을 만들도록 요청하면 사용자와 사용자가 달성하고자 하는 목표가 결정됩니다. 여러분은 호의를 구하고 사용자에게 개인 정보를 믿고 맡길 것을 요청합니다. 저장하는 모든 비밀번호와 데이터 항목은 개인 정보 보호 및 보안과 관련된 '데이터 부채'를 수반하므로 사이트의 비용과 책임이 됩니다.

사용자에게 계정 생성을 요청하는 주된 이유가 탐색 또는 탐색 세션 사이의 정보를 저장하는 것이라면 대신 클라이언트 측 저장소를 사용하는 것이 좋습니다. 쇼핑 사이트에서는 구매를 위해 계정을 만들어야 하는 것이 장바구니 이탈의 주요한 이유로 언급됩니다. 비회원 결제를 기본값으로 설정해야 합니다.

명확한 로그인 정보 표시

페이지 오른쪽 상단에 있는 로그인 또는 로그인 버튼 등을 사용하여 사이트에서 계정을 만드는 방법을 분명하게 합니다. 모호한 아이콘이나 모호한 문구 ('탑승하세요!', 탐색 메뉴에 로그인을 숨기지 마세요. 사용성 전문가 Steve Krug가 웹사이트 사용성에 관한 접근 방식을 요약했습니다. Don't make me think! 웹팀원들을 설득해야 한다면 애널리틱스를 이용해 다양한 옵션의 영향을 보여주세요.

Android 휴대전화에서 모의 전자상거래 웹사이트가 표시된 스크린샷 2개. 왼쪽은 다소 모호한 로그인 링크 아이콘을 사용하고, 오른쪽은 단순히 '로그인'이라고 표시되어 있습니다.
로그인을 명확하게 설정하세요. 아이콘이 모호할 수도 있지만 로그인 버튼 또는 링크는 분명합니다.
Gmail 로그인 스크린샷: 로그인 버튼이 표시된 페이지 1개를 클릭하면 계정 만들기 링크도 있는 양식으로 연결됩니다.
Gmail 로그인 페이지에 계정을 만들 수 있는 링크가 있습니다.
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과 같은 사이트는 이 버전을 사용합니다.

medium.com에서 비밀번호 없이 로그인

제휴 로그인과 마찬가지로 사용자 비밀번호를 관리할 필요가 없다는 추가적인 이점이 있습니다.

세션 길이 고려

사용자 ID에 어떤 접근 방식을 취하든 세션 길이에 대해 신중한 결정을 내려야 합니다. 즉, 사용자가 로그인한 상태로 유지되는 시간 및 사용자를 로그아웃시키는 원인이 될 수 있습니다.

사용자가 모바일 또는 데스크톱을 사용하는지, 데스크톱에서 공유하는지, 기기를 공유하는지 고려하세요.

비밀번호 관리자가 안전하게 비밀번호를 제안하고 저장하도록 지원

서드 파티 및 내장된 브라우저 비밀번호 관리자가 비밀번호를 제안하고 저장하도록 지원하면 사용자가 직접 비밀번호를 선택하거나 기억하거나 입력할 필요가 없습니다. 비밀번호 관리자는 최신 브라우저에서 원활하게 작동하며 기기 간, 플랫폼별 및 웹 앱, 새 기기 간 계정을 동기화합니다.

따라서 가입 양식을 올바르게 코딩하는 것이 매우 중요하며, 특히 올바른 자동 완성 값을 사용해야 합니다. 가입 양식의 경우 새 비밀번호에 autocomplete="new-password"를 사용하고 가능한 경우 autocomplete="email"autocomplete="tel"와 같은 다른 양식 필드에 올바른 자동 완성 값을 추가합니다. 가입 양식과 로그인 양식에서 form 요소 자체와 input, select, textarea 요소에 서로 다른 nameid 값을 사용하여 비밀번호 관리자를 지원할 수도 있습니다.

또한 적절한 type 속성을 사용하여 모바일에서 적절한 키보드를 제공하고 브라우저에서 기본 제공되는 기본 유효성 검사를 사용 설정해야 합니다. 자세한 내용은 지급 및 주소 양식 권장사항을 참고하세요.

사용자가 안전한 비밀번호를 입력하도록 하기

비밀번호 관리자가 비밀번호를 추천하도록 설정하는 것이 가장 좋은 방법이며, 사용자가 브라우저 및 서드 파티 브라우저 관리자가 제안한 안전한 비밀번호를 수락하도록 권장해야 합니다.

하지만 비밀번호를 직접 입력하기를 원하는 사용자가 많으므로 비밀번호 안전성 규칙을 구현해야 합니다. 미국 국립표준기술원(National Institute of Standards and Technology)에서는 안전하지 않은 비밀번호를 방지하는 방법을 설명합니다.

유출된 비밀번호 허용 안함

비밀번호에 어떤 규칙을 선택하든 보안 침해로 노출된 비밀번호를 허용해서는 안 됩니다.

사용자가 비밀번호를 입력하면 이미 도용된 비밀번호가 아닌지 확인해야 합니다. Do I Been Pwned 사이트에서 비밀번호 확인을 위한 API를 제공합니다. 또는 직접 서비스로 실행할 수도 있습니다.

Google의 비밀번호 관리자를 사용하면 기존 비밀번호가 유출되었는지 확인할 수도 있습니다.

사용자가 제안한 비밀번호를 거부하는 경우 거부된 이유를 구체적으로 설명해야 합니다. 사용자가 가입 양식을 제출하고 서버의 응답을 기다려야 하는 것이 아니라 사용자가 값을 입력하는 즉시 문제를 인라인으로 표시하고 해결 방법을 설명합니다.

비밀번호가 거부된 이유를 명확하게 설명해야 합니다.

비밀번호 붙여넣기 금지 안함

일부 사이트에서는 비밀번호 입력에 텍스트를 붙여넣을 수 없습니다.

비밀번호 붙여넣기를 허용하지 않으면 사용자를 성가시게 하고 기억하기 쉽고 (따라서 손상되기 쉬움) 비밀번호를 사용하도록 권장하며 영국 국립 사이버 보안 센터와 같은 조직에 따르면 실제로는 보안을 저하시킬 수 있습니다. 사용자는 비밀번호를 붙여넣기한 에만 붙여넣기가 허용되지 않는다는 사실을 알게 됩니다. 따라서 비밀번호 붙여넣기를 허용하지 않아도 클립보드 취약점을 피할 수는 없습니다.

일반 텍스트로 비밀번호를 저장하거나 전송하지 않습니다.

비밀번호를 솔트 처리 및 해싱해야 하며 나만의 해싱 알고리즘을 고안하려고 해서는 안 됩니다.

비밀번호 강제 업데이트 안함

사용자가 임의로 비밀번호를 업데이트하도록 강요하지 마세요.

비밀번호 업데이트를 강제 시행하면 IT 부서에 큰 부담이 되고 사용자를 성가시게 할 수 있으며 보안에 큰 영향을 미치지 않습니다. 또한 사람들이 안전하지 않은 기억하기 쉬운 비밀번호를 사용하거나 비밀번호를 물리적으로 기록하도록 부추길 수도 있습니다.

비밀번호를 강제로 업데이트하기보다는 비정상적인 계정 활동이 있는지 모니터링하고 사용자에게 경고해야 합니다. 가능하다면 정보 유출로 인해 유출된 비밀번호가 있는지도 모니터링해야 합니다.

또한 사용자에게 계정 로그인 기록에 대한 액세스 권한을 제공하여 로그인이 발생한 위치와 시기를 표시해야 합니다.

Gmail 계정 활동기록 페이지
Gmail 계정 활동기록 페이지

간단하게 비밀번호 변경 또는 재설정하기

계정 비밀번호를 어디에서 어떻게 업데이트해야 하는지 사용자에게 명확히 설명해야 합니다. 어떤 사이트에서는 놀라울 정도로 어렵습니다.

또한 사용자가 비밀번호를 잊어버리더라도 쉽게 재설정할 수 있도록 해야 합니다. Open Web Application Security Project는 분실한 비밀번호 처리 방법에 관한 자세한 안내를 제공합니다.

비즈니스와 사용자를 안전하게 보호하려면 비밀번호가 유출된 사실을 사용자가 알게 되었을 때 비밀번호를 변경하도록 지원하는 것이 특히 중요합니다. 이를 더 쉽게 하려면 비밀번호 관리 페이지로 리디렉션되는 /.well-known/change-password URL을 사이트에 추가해야 합니다. 이렇게 하면 비밀번호 관리자가 사이트 비밀번호를 변경할 수 있는 페이지로 사용자를 직접 이동할 수 있습니다. 이 기능은 현재 Safari, Chrome에서 구현되며 다른 브라우저에서도 지원될 예정입니다. 비밀번호 변경을 위한 잘 알려진 URL을 추가하여 사용자가 비밀번호를 쉽게 변경할 수 있도록 지원에서는 이를 구현하는 방법을 설명합니다.

또한 사용자가 원하는 경우 간편하게 계정을 삭제할 수 있도록 해야 합니다.

서드 파티 ID 공급업체를 통한 로그인 제공

대부분의 사용자는 이메일 주소와 비밀번호 가입 양식을 사용하여 웹사이트에 로그인하는 것을 선호합니다. 하지만 사용자가 서드 파티 ID 공급업체(제휴 로그인이라고도 함)를 통해 로그인할 수도 있어야 합니다.

WordPress 로그인 페이지
Google 및 Apple 로그인 옵션이 표시된 WordPress 로그인 페이지

이 방식에는 여러 가지 장점이 있습니다. 제휴 로그인을 사용하여 계정을 만드는 사용자의 경우 비밀번호를 요청하거나 커뮤니케이션하거나 저장할 필요가 없습니다.

또한 제휴 로그인을 통해 이메일 주소와 같은 확인된 추가 프로필 정보에 액세스할 수 있습니다. 즉, 사용자가 해당 데이터를 입력하지 않아도 되며, 개발자가 직접 확인을 수행할 필요가 없습니다. 또한 통합 로그인을 사용하면 사용자가 새 기기를 사용할 때 훨씬 더 쉽게 실행될 수 있습니다.

웹 앱에 Google 로그인 통합에서는 가입 옵션에 통합 로그인을 추가하는 방법을 설명합니다. 다른 많은 ID 플랫폼을 사용할 수 있습니다.

간편한 계정 전환

많은 사용자가 기기를 공유하고 동일한 브라우저를 사용하여 계정 간에 전환합니다. 사용자의 통합 로그인 액세스 여부와 관계없이 계정 전환을 간단하게 해야 합니다.

Gmail, 계정 전환 표시 중
Gmail에서 계정 전환

다중 인증(MFA) 제공 고려

다중 인증(MFA)은 사용자가 두 가지 이상의 방법으로 인증을 제공하도록 하는 것을 의미합니다. 예를 들어 사용자에게 비밀번호를 설정하도록 요구하면서 이메일이나 SMS 문자 메시지로 전송되는 일회용 비밀번호를 사용하거나 앱 기반 일회용 코드, 보안 키 또는 지문 센서를 사용하여 인증을 시행할 수도 있습니다. SMS OTP 권장사항WebAuthn으로 강력한 인증 사용 설정에서는 다중 인증 구현 방법을 설명합니다.

사이트에서 개인 정보 또는 민감한 정보를 처리하는 경우 다중 인증(MFA)을 제공(또는 시행)해야 합니다.

사용자 이름 관리하기

사용자 이름이 꼭 필요한 경우가 아니면 사용자 이름을 요구하지 마세요. 사용자가 이메일 주소 (또는 전화번호)와 비밀번호만 사용하거나 원하는 경우 제휴 로그인으로만 가입하고 로그인할 수 있게 합니다. 사용자가 사용자 이름을 선택하고 기억하도록 강요하지 마세요.

사이트에서 사용자 이름을 요구하는 경우, 사용자 이름에 부당한 규칙을 적용하거나 사용자가 사용자 이름을 업데이트하지 못하도록 해서는 안 됩니다. 백엔드에서는 사용자 이름과 같은 개인 정보를 기반으로 하는 식별자가 아니라 모든 사용자 계정의 고유 ID를 생성해야 합니다.

또한 사용자 이름에 autocomplete="username"를 사용해야 합니다.

다양한 기기, 플랫폼, 브라우저, 버전에서 테스트

사용자에게 가장 일반적인 플랫폼에서 가입 양식을 테스트합니다. 양식 요소 기능이 다양할 수 있으며 표시 영역 크기의 차이로 인해 레이아웃 문제가 발생할 수 있습니다. BrowserStack은 다양한 기기와 브라우저에서 오픈소스 프로젝트를 위한 무료 테스트를 지원합니다.

분석 및 실제 사용자 모니터링 구현

사용자의 가입 양식 사용 방식을 이해하려면 필드 데이터와 실습 데이터가 필요합니다. 애널리틱스와 실제 사용자 모니터링(RUM)은 가입 페이지를 로드하는 데 걸리는 시간, 사용자가 상호작용하는 UI 구성요소, 사용자가 가입을 완료하는 데 걸리는 시간 등 실제 사용자 경험에 대한 데이터를 제공합니다.

작은 변화로 가입 양식의 완료율이 크게 달라질 수 있습니다. 애널리틱스와 RUM을 사용하면 변경사항을 최적화하고 우선순위를 지정할 수 있으며, 로컬 테스트에서 노출되지 않는 문제가 있는지 사이트를 모니터링할 수 있습니다.

계속 학습하기

사진: @ecowarriorprincess, Unsplash