활성화하기 전에, 이 기능은 enable_local_logins와 enable_local_logins_via_email이 모두 true여야만 켤 수 있으므로 이 두 설정이 true인지 확인하세요. DiscourseConnect(enable_discourse_connect)를 사용 중인 경우 이 기능을 활성화할 수 없습니다.
변경 사항이 활성화되면 코드 로그인 경로가 자동으로 나타납니다.
신규 계정을 위한 랜덤 사용자 이름
인식 가능한 사용자 이름이 포함된 이메일 없이 가입하는 신규 회원에게는 이제 user1과 같은 일반적인 플레이스홀더 대신 "QuietFalcon42"와 같은 친근하게 생성된 이름이 부여됩니다. 계정 준비 단계에서 제안된 이름이 미리 입력되며, 새로운 이름을 생성하기 위한 주사위 버튼이 포함됩니다.
제안 이름 뒤에 있는 단어 목록은 random_username_adjectives 및 random_username_nouns 사이트 설정을 통해 구성할 수 있으므로, 커뮤니티는 자신의 톤이나 언어에 맞게 조정할 수 있습니다. 이전의 번호 기반 폴백을 유지하려면 enable_random_usernames를 비활성화하여 옵트아웃할 수 있습니다.
여러분의 생각은?
이제 여러분의 차례입니다: 이 새로운 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 무엇이 좋고 나쁜지, 무엇이 잘 작동하고 무엇이 개선될 수 있는지 알려주세요.
이 새로운 플로우(흐름)는 제 비밀번호 관리자가 저에게 권해온 “이메일 생성, 사용자 이름 입력, 비밀번호 생성, 저장” 전략을 제거하고, 모든 단계 전에 이메일을 먼저 입력하도록 강제합니다. 이메일 인증 코드 방식 자체에는 문제가 없습니다(오히려, 특히 코드 내용이 이메일 제목에 포함된다면 거의 선호하는 편입니다) 하지만, 다른 계정 데이터 입력란을 제거하는 것에 대해서는 강하게 반대합니다. 만약 기술적 배경이 전혀 없는 사용자라면, 이런 식의 정보가 없는 박스에 이메일을 입력하는 것이 일반적인 디자인이 아니기 때문에 자신의 이메일을 함부로 입력하지 않을 것이라 생각합니다. 이것이 영구적인 변경 사항이 되기 전에, 해당 입력란을 다시 복원해 주셨으면 좋겠습니다.
이메일 코드, 또는 "매직 링크"라고도 불리는 방식은 괜찮지만, 사용자를 패스키 사용으로 유도하면 경험이 훨씬, 훨씬 좋아집니다.
이메일 코드의 가장 큰 문제 중 하나는 앱 내 브라우저(예: Gmail의 앱 내 브라우저)에서 사용자가 원하는 대로 동작하지 않는다는 점입니다.
매직 링크와 관련해 사람들이 가장 자주 겪는 문제는, 일반적인 브라우저에서 사이트에 로그인했다고 생각하지만 실제로는 앱 내 브라우저를 통해 로그인된 상태라는 것입니다. 예를 들어, 사용자가 이메일로 로그인 링크를 받은 후 Gmail 앱을 열어 “404 Media에 로그인” 버튼을 클릭하면 전화기가 웹페이지를 로드합니다. 하지만 이는 네이티브 Safari 브라우저가 아니라 Gmail의 웹 브라우저를 통해 웹사이트를 로드하는 것입니다.
패스키는 이 문제를 해결합니다.
먼저, 매직 링크를 사용하는 웹사이트는 현재 매직 링크 작동 방식에 대해 불만을 제기한 고객들에게 패스키를 선택적(옵트인) 기능으로 제공할 수 있습니다. 문제가 발생하지 않도록 일종의 소프트 론칭으로, 해당 기능을 100% 옵트인으로 설정할 수 있습니다.
그 후, 웹사이트 운영자가 패스키가 매직 링크 관련 사용자 경험 문제를 실제로 해결하는지 확신하게 되면, 로그인 후 90일마다 또는 패스키의 크로스 디바이스 로그인 기능을 사용하여 로그인할 때 사용자에게 패스키 추가를 제안할 수 있습니다. Apple 기기를 사용하는 사용자를 위한 이러한 제안의 프레이밍은 다음과 같이 할 수 있습니다: 다음에 이메일을 확인할 필요가 없도록 하려면, Face ID나 Touch ID로 빠르고 안전하게 로그인할 수 있도록 패스키를 설정해 보세요.
이 접근 방식에 매우 공감합니다! 다만, 가입 절차가 완료되기 전에 표시 이름(display name)을 변경할 수 없다는 점이 조금 신경에 거슬립니다. 가입 과정 중에 이름을 변경할 수 있는 옵션을 추가할 수 있다면 좋겠다고 생각합니다.
저의 커뮤니티에서는 Prioritize username in UX 사이트 설정을 비활성화했습니다. 이로 인해 UI 전반에서 전체 이름/표시 이름이 우선적으로 표시됩니다. 이런 상황에서 사용자가 즉시 이름을 커스터마이즈할 수 있는 옵션이 없다면, "user21"과 같이 자동 할당된 이름은 프론트엔드에서 꽤 보기 좋지 않게 보입니다.
이 새로운 플로우에서는 매직 링크를 보내지 않습니다. 코드만 전송합니다. 사용자는 같은 페이지에 머물러 있으며, 이메일에서 코드를 복사하여 가입 폼에 붙여넣습니다. 따라서 이 새로운 접근 방식은 인앱 브라우저에서 문제를 해결하는 데 도움이 됩니다(이 변경 사항의 주요 장점 중 하나입니다).
이는 가입 시 비밀번호 단계에서 다음으로 수행하고 싶은 일입니다. 앱과 웹사이트가 패스키 지원을 확대하고 있으며, 다양한 맥락에서 패스키 유도 메시지를 자주 볼 수 있으므로 Discourse에도 추가하는 것이 타당합니다. (비밀번호에서 패스키로의 전환에서 이러한 지원의 임계값에 도달하는 것은 매우 도움이 됩니다.)
이것은 좀 이상한 인용입니다. DomMcD가 저를 인용한 것처럼 보이지만, 사실은 그렇지 않습니다.
저는 해당 단계를 테스트해 본 적이 없습니다. 저는 Meta에서 신규 사용자와 관련된 제 관찰 사항에 대해 언급하고 있을 뿐입니다. 가입 시 특정 필드를 보느냐의 여부는 중요하지 않습니다. 다른 사람들이 그 필드를 어떻게 다루는지에 대해 제가 어떻게 대응해야 하는지가 중요하니까요.
또한 이름이 어떻게 처리되는지도 궁금합니다. 모든 사용자가 생성된 사용자명을 사용하는 것은 아닌 것 같지만, 이름이 userXXX로 설정된 사용자가 더 많다는 것을 알아차립니다.
사용자명을 변경해도 여전히 그런 이름이 부여되는 것 같습니다. 이로 인해 같은 숫자가 반복적으로 사용되다가, 해당 사용자명이 이미 사용 중이면 다음 숫자로 다시 시작되는 현상이 발생한다고 합니다.
변경된 사항
커뮤니티에서 1회용 로그인 코드 활성화하기
활성화하기 전에, 이 기능은 
신규 계정을 위한 랜덤 사용자 이름
여러분의 생각은?
