"이메일이 인증이다" 패턴

• 일부 사용자는 비밀번호를 기억하거나 관리하는 대신, 매번 “비밀번호를 잊었습니다” 절차를 로그인 방식처럼 사용함
• 실제 흐름은 로그인 페이지에서 복구 링크를 이메일로 받고, 임시 비밀번호를 입력한 뒤 다음 방문 때도 같은 과정을 반복하는 구조임
• 이 습관은 의식적인 보안 전략이라기보다, 시간이 지나며 굳어진 학습된 행동에 가까움
• 비밀번호 관리자와 2단계·다중 인증 같은 개선책도 사용자에게는 보안 강화보다 마찰 증가로 느껴질 수 있음
• 시스템 설계는 사용자의 반복 행동을 전제로 삼고, 더 나은 사용 방식으로 자연스럽게 옮겨가도록 유도할 필요가 있음

---

로그인처럼 쓰이는 비밀번호 복구

• 일부 사용자는 온라인 계정에 로그인할 때 비밀번호를 입력하지 않고 복구 절차를 매번 반복함
  • 로그인 페이지에 도착함
  • “I forgot my password”를 클릭함
  • 이메일로 이동함
  • 복구 링크를 클릭함
  • 기억하지 않을 임시 비밀번호를 입력함
  • 이후 같은 과정을 반복함
• 왜 그렇게 하는지 물으면 답하지 못하거나, 이유를 생각해본 적이 없다고 반응함
• 이 행동은 아침에 정한 로그인 전략이 아니라, 시간이 지나며 굳어진 반복 절차에 가까움

보안 개선이 사용자에게 만드는 마찰

• 이 방식은 사용자가 암호 문구를 기억하지 않아도 되는 낮은 노력의 해결책으로 작동함
• 비밀번호 관리자, 신원 도용, 2단계 인증과 다중 인증, 사용자명/비밀번호 방식의 노후화는 이미 널리 논의된 주제임
• 더 나은 보안 절차는 종종 장벽과 마찰을 늘려, 사용자가 자연스럽게 받아들이기 어려울 수 있음
• 설계자는 사용자의 학습된 행동을 고려해, 시간이 지나며 더 나은 사용 방식으로 이동할 수 있는 흐름을 만들어야 함

[GN⁺]

Hacker News 의견들

• 이메일 계정은 온라인 인증에서 가장 보편적인 공통분모임. 휴대폰도 경쟁력이 있지만 잃어버릴 수 있고, 전화번호는 더 흔하고 오래가지만 보안 수준은 주요 이메일 제공업체 계정보다 훨씬 낮음
  “인터넷용 상상 속 인증 시스템”을 설계하려면 먼저 계정 복구부터 봐야 함. 멋진 인증기를 잃어버렸을 때 답이 “그냥 접근 못 함”이나 “동료 패널이 신원을 보증함”이라면, 그 시스템은 인간이 아니라 상상 속 지적 생명체를 사용자로 삼아야 작동함

  • 이게 수년간 블록체인/암호화폐에 반대해 온 가장 큰 이유였음. “키를 잃으면 지갑도 잃는다”는 방식은 현실 사용자와 근본적으로 맞지 않음
    인간은 실수에서 복구할 수 있어야 함
  • 정부 발급 디지털 신분증이 이 문제의 많은 부분을 해결할 수 있음. 자체 문제가 있겠지만, 개인 식별을 정부에 맡기는 건 Google 같은 업체의 계정 잠금보다 가치 있고 덜 위험해 보임
  • 안타깝게도 Google 같은 주요 이메일 제공업체에서도 “그냥 접근 못 함”이 흔한 패턴임. 휴대폰을 잃어버리거나 도난당한 뒤 계정에서 영구적으로 잠긴 사람들이 이를 잘 보여줌
  • “주요 제공업체 이메일 계정”에도 “이유 없이 계정을 정지했고, 이의제기 방법도 없고, 왜 정지했는지도 알려주지 않는다”는 단서가 붙음
  • 동료 패널이 개인의 신원을 보증하는 방식은 흥미로운 설계 문제임. 적절히 분산된 인증 비밀을 관련 당사자의 지시에 따라 재조합할 수 있는 공통 시스템이 있다면 꽤 매끄럽게 만들 수도 있음
    보통 인간에게도 작동하게 만들 수 있을까? 충분히 설계할 수 있는 창의력은 있다고 봄

• 우리 서비스는 꽤 가벼운 성격의 비즈니스라, 사용자가 계정을 편의상만 씀. 정착한 방식은 이렇다: 사용자가 이메일을 입력하고, 이메일로 인증 코드를 보내고, 사용자가 코드를 입력하면 사실상 무기한 로그인되는 매우 긴 쿠키를 발급함
  기존 계정 여부는 중요하지 않고, 새 이메일이면 새 계정을 만들면 됨. 가끔 여러 이메일을 가진 사용자가 실수로 새 계정을 만들지만, 가입과 로그인 전환율이 크게 좋아져서 감수할 만함. 코드 유효시간과 시도 횟수에는 위험 분석이 필요하고, 가능하면 잠금 메커니즘을 쓰는 게 좋음. 서비스가 그다지 중요하지 않다면 이 전략을 추천함. iOS Mail도 이제 Messages의 일회용 코드 기능처럼 이런 방식을 지원해서 일부 사용자에게는 꽤 편함

  • 내가 본 데이터 기준으로는 이 방식이 전자상거래 매출을 극대화하는 데 압도적으로 좋음
    구매자에게 계정을 강요하지 말고 세부 정보만 요청하면 됨. 어차피 브라우저가 자동완성함. 이후 주문 상태 확인 링크를 이메일로 보내고, 다음 주문 때 다시 이메일을 물어보면 됨. 추가 마찰은 “가입 사용자”를 얻는 이점보다 더 큰 매출 손실을 만듦
  • 작은 B2C 앱을 운영 중인데, 사용자는 이메일 주소만으로 가입하고 비밀번호 필드 자체가 없음. 계정이 생성되고 해당 기기에서는 무기한 로그인됨
    다른 기기에서 로그인해야 할 때만 새 비밀번호를 요청할 수 있음. 이러면 가입 마찰과 약한 비밀번호가 줄어듦. 대부분은 어차피 다른 기기에서 로그인할 일이 거의 없음
  • 이 로그인 방식을 여러 번 구현해 봤고, “사용자 계정”이 무엇인지에 대한 수많은 가정을 걷어내야 했던 경험에서 나온 방식임. 실제로 양쪽 모두가 원하는 대로 퍼널을 작동시키려면 이런 단순화가 필요했음
    익명성을 보존해야 하는 영역이 아니라면 이렇게 해도 되고, 나중에 패스키를 통합하면 됨. 단점은 비밀번호 공유가 불가능해지므로 계정 하나에 여러 사용자를 관리하는 문제를 더 일찍 생각해야 한다는 것임. 하지만 의식적으로 다루면 퍼널이나 사용자 경험은 결국 좋아짐. 또 보안은 사용자 이메일 제공업체들의 평균 보안 수준에 묶이지만, 보통 필요한 수준보다 낫다. 비밀번호는 나중에 필요해질 때 두 번째 요소로 쓰거나 다른 요소를 추가할 수 있고, B2B라면 바로 SAML이나 OIDC로 갈 수 있음. B2B나 D2C에서는 늘 잘 작동했고, 예외 상황은 획득 이점 때문에 해결할 가치가 있었음
  • 이런 로그인 방식을 본 적이 있는데, 이메일에 앱 홈으로 보내면서 이미 로그인된 상태가 되는 링크를 보내면 안 되나?
    코드를 복사하고, 로그인 페이지를 열어 둔 탭을 찾고, 붙여넣는 과정이 번거로움
  • 거의 단일 폼에 가까운 작은 CRUD 앱에서 이 방식을 썼는데, 캠페인 기간 동안 지원 요청이 거의 0에 가까워서 충분히 가치 있었음

• 이쯤 되면 이메일 주소로 일회용 URL 링크를 보내고 한 번 클릭으로 로그인하게 하면 되지 않나? 10분 안에 만료되고 1회용으로 폐기되게 하면 됨
  물론 처음 링크를 가진 사람은 누구든 계정으로 로그인할 수 있지만, 어차피 이메일에서만 접근 가능함. 이메일 계정 이상의 보안 감각은 다 날아가지만, 현실이 이미 그 지점에 와 있음. 휴대폰 메시지로 “로그인 인증하려면 클릭: www.someurl.com?p=134234535” 같은 패턴을 쓰면, 멍청하게 코드를 입력하지 않아도 되는 2단계 인증이 됨

  • 여러 웹앱에서 이 방식을 쓰고 있는데, 사용자에게 혼란스럽고(“왜 이미 계정이 있지? 가입한 적 없는데!”), 비용도 들고(이메일 발송은 무료가 아님), 느리기도 함
    이메일이 스팸으로 가거나, 그레이리스팅 때문에 몇 시간 동안 로그인 못 하거나, 도착까지 1분 걸리는데 그마저 너무 길게 느껴질 때가 있음. 추천할지는 잘 모르겠음
  • 이런 방식만 제공하는 사이트가 30초 안에 이메일을 못 보내면 정말 싫음
    휴대폰으로 보내는 “로그인 인증 클릭”은 코드와 링크를 둘 다 줘야 함. 항상 로그인하는 기기가 휴대폰인 건 아니므로 “1234 입력 또는 클릭”이 되어야 함
  • Netdata 같은 일부 사이트가 그렇게 함
    하지만 비밀번호 관리자가 사용자명/비밀번호 조합을 자동 입력하는 것보다 느림. 이메일을 기다리고 링크를 눌러야 하기 때문임
  • 정확히 이 로그인 절차로 웹앱을 만들고 있는데, 모바일에서 문제가 있었음. Gmail 같은 앱은 미리보기 없이 링크를 브라우저로 복사하게 해주지 않고, 그 미리보기가 링크를 소비해 버림(next.js auth)
    Gmail 인앱 브라우저에 로그인하고 싶은 게 아니라 일반 브라우저에 로그인하고 싶은데 꽤 성가심
  • 그럴 거면 차라리 싱글 사인온으로 끝까지 가는 편이 나음. 사용자의 95%는 어차피 Gmail, Outlook, Apple 중 하나를 쓸 것임
    “메일로 링크 보내기”보다 “Google로 로그인” 버튼이 낫고, 어느 쪽이든 추적은 가능함

• 사람이 모든 별것 아닌 서비스마다 비밀번호를 만들어 기억한다는 생각은 현실적이지 않음. 또 하나의 비밀번호 기반 인증 시스템을 만드는 건 일종의 역할놀이에 가까움
  비밀번호는 보통 두 방식 중 하나로 쓰임: 하나의 실제 비밀번호로 보호되는 비밀번호 관리자, 또는 서비스마다 반복되는 같은 비밀번호. 거의 모든 서비스가 이메일 복구를 제공하므로 실제로는 이메일이 인증 수단임. 개인 이메일은 잘 바꾸지 않고, 공유하지 않으며, 재사용되지도 않음. 아마 개인 이메일을 전화번호보다 오래 썼을 가능성이 큼. 현재 이메일 주소를 쓰는 동안 전화번호는 최소 다섯 번 바뀌었고, 그 번호들은 이제 다른 사람들이 쓰고 있음

  • 파생 비밀번호도 있는데, 일종의 혼합형임. 사람이 기억하는 패턴일 수도 있고, 도메인별로 계산해 주는 관리 도구일 수도 있음
    그리고 비밀번호 찾기 기능은 최소한 주소 소유자에게 모든 시도를 알려줌. 비밀번호 기반 로그인은 새 위치에서 로그인할 때마다 항상 이메일을 보내지는 않음
  • Apple은 “그냥 1Password/Keychain 비밀번호를 입력하면 안 되고 이메일로 귀찮게 해야 하는” 과정을 훨씬 낫게 만들었음. 최소한 이메일이나 문자를 인식해서 코드를 대신 입력해 줄 때는 그럼

• 답은 단순함. 보통 서비스 제공자가 사용자를 위해 만들어 둔 불편함과 관련 있음. 이 경우엔 명확해 보이는데, 이메일 제공업체 세션은 보통 사실상 끝나지 않고 브라우저 캐시를 지우지 않는 한 로그인된 채로 남아 있음
  자기 서비스 인증 토큰도 Gmail과 같은 수명으로 만들고, 대안으로는 매번 일회용 비밀번호로 로그인할 수 있게 하면 됨. 하지만 12시간짜리 인증 토큰 같은 신성모독적 관행은 그만둬야 함. 그러면 사용자는 다시는 비밀번호 복구로 로그인하지 않을 것임

  • 진짜 이유는 해당 웹사이트들이 그냥 제대로 동작하지 않기 때문일 수도 있음
    예전에 Epic과 Spotify 계정에서 문제가 있었음. 계정을 만들고 일주일 쓰면 세션이 만료되고 Spotify가 계정에서 내쫓음. 로그인하려 하면 비밀번호가 틀렸다고 하는데, 비밀번호 관리자에 저장돼 있으니 불가능한 일임. 결국 이메일로 재설정할 수밖에 없음. 처음 몇 번은 이메일을 받고 재설정해도 같은 패턴이 반복되고, 3~4번 지나면 이메일조차 안 와서 새 계정을 만들어야 했음. 지금은 Google 계정으로 Spotify에 로그인해 쓰고 있고 아직 문제 없음. 하지만 일반 이메일로 쓰면 그들의 인증 시스템은 그냥 작동하지 않음
  • 이게 진실에 더 가까운 힌트라고 봄. Gmail과 Cloudflare를 비롯한 많은 “고보안 조직”은 인증 세션이 매우 김. 이유는 이런 시스템을 쓰는 사람의 PC에 누군가 접근했고, 사용자가 로그아웃하지 않은 상태일 확률이 실제로 매우 낮기 때문임. 대부분의 해킹은 원격에서 약한 비밀번호를 노림
    문제는 위험을 측정하고 “이 사이트에 정말 2단계 인증이 필요한가?”, “30분 세션 시간이 합리적인가?”를 판단할 일관된 언어가 부족하다는 것임. 최신 백신이 있다면 대부분은 로그인 상태를 유지하고 싶어 할 것임. 어떤 사이트 문제를 고치려고 쿠키를 전부 지우라는 요청을 받아본 적 있나? 내 답은 항상 거절임. “계정은 당신 것이고, 로그인 상태를 유지해 해킹 위험을 감수하겠다면 그건 서비스 운영사가 아니라 당신의 위험”이라는 말을 들은 적이 있는데 점점 더 동의하게 됨. 노트북이 로그인된 상태에서 누군가 EC2 인스턴스를 전부 지웠다면, 더 일찍 로그아웃시키지 않은 AWS 탓이 아니라 당신 탓임. AWS가 할 수는 있겠지만 왜 그래야 하나? 부주의한 1명을 보호하려고 100만 명을 짜증나게 할 이유가 없음
  • 맞는 말임. 플랫폼이 세션 제한과 강제 2단계 인증으로 보모처럼 구는 데 지쳤음. 그냥 설정에 토글을 두면 됨

• 비밀번호 찾기 단계를 없애거나 비밀번호 자체를 없앤 사이트를 본 적 있음. 이메일이 인증임
  이메일 주소를 입력하고, 코드가 담긴 이메일을 받고, 코드를 입력해 로그인하는 방식임. 왜 이렇게 하는지는 이해하지만, 이메일을 여러 개 쓰는 입장에서는 꽤 싫음. 어떤 이메일을 써야 하는지 기억하려고 비밀번호 관리자에 이메일과 메모를 넣어야 했고, 비밀번호가 없는 항목처럼 남음

  • 매직 링크를 쓰는 마찰이 너무 커서 그런 웹사이트에 돈을 쓰지 않고 대안을 찾은 적 있음
    제대로 된 로그인 시스템도 못 만들면 약속한 기능을 제공할 실력도 부족할 가능성이 크다고 봄. 매직 링크는 이제 귀찮음을 넘어 필터가 됐음
  • B2B SaaS에서 이 방식을 씀. 개별 사용자는 6개월에 한두 번 로그인할까 말까 하므로 비밀번호 없는 로그인이 유리함
    자주 쓰지 않는 서비스의 비밀번호를 기억하라는 부담이 없고, 회사 온보딩도 쉬움. 회사가 사용자 CSV를 올리면, 사용자들은 비밀번호를 만들고 확인하고 규칙을 맞추는 과정 없이 바로 작업을 시작할 수 있음. 이메일 링크는 선호하지 않음. 휴대폰 앱의 미리보기나 기업 바이러스 스캐너 등이 링크를 “클릭”해 버리기 때문임
  • 비기술 소비자의 상당수는 비밀번호 관리자를 쓰지 않을 것임. 비밀번호 가입만 제공하고 매직 링크나 코드를 제공하지 않으면, 대다수 소비자에게 더 어려운 삶을 만드는 셈임
    둘 다 제공하더라도, 비밀번호를 요구하면서 이메일 확인까지 시키면 가입 흐름에서 더 많이 이탈할 것 같음. 게다가 비밀번호와 여러 이메일 로그인 흐름을 처리하지 않아도 되니 코드도 훨씬 단순함
  • 바우처를 교환하는 “게스트 로그인” 사이트에서 이 방식을 제공했는데, 계정을 만들고 싶지 않을 수 있는 사람에게는 유효한 사용 사례라고 봄
    바우처를 이메일과 연결해야 하므로, 나중에 바우처 분실로 지원 문제가 생길 때를 대비해 링크 클릭으로 소유를 확인해야 했음. 이후 계정을 만들면 예전에 받은 바우처도 볼 수 있음
  • 사이트가 내 비밀번호를 저장하지 않는다는 뜻이라, 걱정할 게 줄어듦

• 이 글을 읽고 나서야 내가 Best Buy에서 정확히 이 방식을 쓰고 있다는 걸 깨달았음
  의도한 건 아님. 1Password에 비밀번호가 저장돼 있어서 맞다는 걸 아는데, bestbuy.com에서 뭔가 사려고 할 때마다 어떤 계정 탈취 방지가 걸려서 비밀번호가 틀렸다고 거짓으로 말함. 내 쪽 문제일 수도 있다고 충분히 믿음. 광고 차단기나 로컬 DNS 차단 같은 것일 수 있음. 하지만 몇 번 반복되면 디버깅할 의욕이 사라지고 그냥 저항이 가장 적은 경로를 따르게 됨

  • 혹시 최대 길이 불일치가 아닌가? 비밀번호 변경 필드와 로그인 페이지의 maxlength가 다른 경우가 매우 흔함
    예를 들어 비밀번호 변경 때 60자 비밀번호를 넣었는데 로그인 페이지의 최대 길이가 40자면, 로그인할 때 “비밀번호 틀림”이 됨. 그래서 나는 이제 애플리케이션 설정에 최대 길이를 저장해 모든 비밀번호 필드에 전파되게 하는 정책을 씀. 확인해 보니 실제로 길이 불일치가 있음. 비밀번호 설정 폼은 maxlength가 54인데 로그인 페이지에는 maxlength가 없음. 따라서 비밀번호가 54자를 넘고 1Password가 저장 비밀번호를 자동으로 54자 이하로 자르지 않는다면 로그인할 수 없음

• 대부분의 사람에게 컴퓨터 작업은 대충 될 때까지 무식하게 반복 시도하는 일임. 소프트웨어는 밑바닥 시스템을 세세히 이해하는 사람들이 만들지만, 그런 이해가 없는 사람들을 위해 만들어짐
  사용자는 한 번 작동하는 패턴을 찾으면 거기에 머무름. 이제 많은 학교가 교육에 태블릿을 쓰면서 이런 경향은 더 커지고 있음. 컴퓨터가 어떻게 작동하는지 감을 잘 못 잡음. 대부분은 깊이 생각하지 않음. 그냥 거기 있고, 원래 망가져 있는 것에 익숙하니 클릭 몇 번 더 하는 게 뭐 대수겠나

  • 소프트웨어 개발자 중 실제로 자신이 하는 일을 깊게 이해하는 사람은 아마 10% 정도일 것임. 오히려 개발자들이 뭘 하는지 제대로 이해하지 못하기 때문에 일반 사람들이 형편없는 소프트웨어를 반복 시도로 겨우 쓰는 것임

• 과장해서 말하면 로그인 흐름은 동일함
  A) 웹사이트에 가서 비밀번호 관리자를 통해 임의 문자열을 복사해 붙여넣고, 본인 확인을 위해 이메일로 온 TOTP 요청을 받음. 또는 B) 웹사이트에 가서 비밀번호 찾기를 누르고, 로그인 링크를 받은 뒤 임의 문자열을 입력함. 많은 경우 B가 실제로 더 빠르고, 거의 더 느리지도 않음. “기억하기” 체크박스는 아무 효과가 없음

  • 비밀번호 관리자에서 누가 복사해 붙여넣기를 하나?
    내 흐름은 둘보다 낫다고 봄. 사이트에 가면 Safari가 자동 입력을 제안하고, TouchID/FaceID를 쓰고, 2단계 코드를 요청받음. SMS나 이메일로 오면 Safari가 자동 입력을 제안함. TOTP 방식이어도 Safari가 자동 입력해 줌. 아주 쉬움. 패스키는 두 번째 단계와 SMS/이메일 대기가 없어서 더 쉬움
  • TOTP는 이메일로 보내는 성격의 것이 아님. TOTP의 핵심은 현재 시간과 미리 공유된 비밀값으로 인증 코드를 직접 생성할 수 있다는 데 있음
  • 그레이리스팅이 있으면 B 흐름은 10분쯤 걸릴 수 있음
  • B 방식은 이메일에 접근할 수 있는 곳이라면 어디서든 가능하고, 앱이나 휴대폰이 내 손에 있는지 여부에 의존하지 않음
  • 브라우저가 비밀번호를 기억하지 않나?

• 동기는 바로 이해됨. “비밀번호를 잊었다”를 쓰면 비밀번호를 기억할 필요가 없음. 그리고 계정 보안이 더 약해지는 것도 아님. 어차피 그 경로는 공격자에게도 열려 있었기 때문임
  일부 웹사이트는 이걸 기본 흐름으로 삼고, 누군가에게 로그인 버튼을 이메일로 보낼 수 있다면 비밀번호 자체가 무의미하다고 암묵적으로 주장함. 개인적으로는 싫음. 이메일을 신뢰하지 않고, 수십 개 계정의 단일 장애점이 되는 것도 싫음. 두 번째 요소만으로 로그인할 수 있다면 그건 2단계 인증이 아님. 재설정 옵션 없이 비밀번호로 로그인하고 싶지만, 현실은 그렇지 않음

  • 이메일을 2단계 인증으로 보호하면 다시 2단계 인증이 됨