왜 우리는 계정, 비밀번호, 개인 데이터 없이 인증을 구축했는가

Source: Dev.to

The problem we kept seeing

많은 실제 상황에서 계정은 제품이 아니다:

• 이벤트 접근(온라인 또는 오프라인)
• 일회성 또는 단기간 세션
• 관리자 또는 내부 도구
• 클라이언트·파트너를 위한 임시 접근
• 존재 증명·제어 증명 흐름

그런데 대부분의 인증 솔루션은 다음을 강요합니다:

• 사용자를 생성하고,
• 식별자를 저장하고,
• 복구 흐름을 관리하고,
• 실제로 필요하지 않은 개인 데이터를 책임지는 것.

이로 인해 다음이 증가합니다:

• 법적 위험(GDPR, 데이터 유출)
• 엔지니어링 복잡성
• 사용자 인지 부하

The idea: access without identity

간단한 질문을 던졌습니다: 인증이 계정을 소유하는 것이 아니라 접근을 증명하는 것이라면 어떨까?

그래서 사용자가 아니라 접근 패스와 작업합니다.

• 사용자 이름 없음
• 이메일 없음
• 저장된 개인 데이터 없음
• 암호학적 증명만 존재

How it works (high level)

핵심 흐름은 QR + TOTP를 기반으로 하지만, 사고 모델이 다릅니다:

1. 서비스가 임시 접근 패스를 생성합니다.
2. 패스는 QR 코드 형태로 표현됩니다.
3. 사용자는 이를 TOTP 호환 앱으로 스캔합니다.
4. 서버가 코드를 암호학적으로 검증합니다.
5. 계정 없이 접근이 허용됩니다.

핵심 특성

• 비밀키는 사용자의 기기 밖으로 나가지 않습니다.
• 서버는 암호화된 비PII 데이터만 저장합니다.
• 패스는 짧은 수명, 범위 지정, 폐기가 가능합니다.

서버 입장에서는 사람을 식별할 것이 전혀 없습니다—오직 증명이 유효한지만 판단합니다.

Why QR + TOTP?

우리는 의도적으로 다음을 배제했습니다:

• 독점 앱,
• 매직 링크,
• 전화번호,
• 생체인식 잠금.

TOTP는:

• 널리 지원되고,
• 오프라인에서도 사용 가능하며,
• 잘 알려져 있고,
• 감사가 쉬움.

QR은:

• 빠르고,
• 기기 간 호환이 가능하며,
• 비전문가에게 직관적.

두 가지를 결합하면 다음과 같은 흐름을 만들 수 있습니다:

• 사용자는 간단하고,
• 개발자는 예측 가능하며,
• 데이터는 최소화됩니다.

What this is not

이는 다음의 대체가 아닙니다:

• 완전한 사용자 계정,
• 소셜 로그인,
• 아이덴티티 관리.

다음이 필요하다면:

• 사용자 프로필,
• 장기 아이덴티티,
• 개인화,
• 소셜 그래프,

전통적인 인증이 여전히 타당합니다. 이 접근법은 아이덴티티가 불필요한 과부하인 경우에 적용됩니다.

Why we are sharing this early

우리는 이 접근법을 공개적으로, 그리고 신중히 검증하고 있습니다. 관심 분야는 다음과 같습니다:

• 우리가 놓칠 수 있는 엣지 케이스,
• 이 모델이 무너지는 시나리오,
• 계정이 여전히 불가피한 사용 사례.

실제 시스템에서 인증 복잡성을 겪은 엔지니어들의 피드백이 특히 가치 있습니다.

읽어 주셔서 감사합니다. 댓글에서 트레이드‑오프, 보안 고려사항, 실제 제약 조건 등에 대해 자유롭게 논의해 주세요.