2차 인증 직접 구현하기 — 인증 앱·문자·TOTP 비교와 슈퍼베이스 코드

코드를 보기 전에 용어부터 맞추겠습니다. 셋을 자주 섞어 쓰지만 층위가 다릅니다.

• 2차 인증(2FA) — 비밀번호 하나만으로 끝내지 않고, 두 번째 증거를 한 번 더 요구하는 방식입니다. 비밀번호(아는 것)에 더해, 휴대폰 안의 인증 앱(가진 것)을 두 번째 요소로 씁니다.
• 다중 인증(MFA) — 2차 인증을 일반화한 말입니다. 요소를 두 개 이상 쓰면 모두 MFA이고, 정확히 두 개면 2FA입니다. 슈퍼베이스 문서는 MFA라는 용어를 씁니다.
• 일회용 비밀번호(OTP) — 한 번 쓰고 버리는 6자리 숫자 코드 자체를 가리킵니다. 이 코드를 만들어 내는 방식이 TOTP(시간 기반)와 HOTP(횟수 기반)로 갈립니다.

정리하면, 우리가 만들 것은 비밀번호 다음에 6자리 OTP를 한 번 더 받는 2FA이고, 그 OTP를 만드는 표준으로 TOTP를 쓰는 구조입니다. 아래 표로 한 번 더 비교합니다.

한 가지 짚을 점은, 카카오 로그인이나 네이버 로그인 같은 소셜 로그인은 그 자체가 2차 인증이 아니라는 것입니다. 소셜 로그인은 비밀번호 관리를 외부에 맡기는 인증 위임이고, 그 위에 우리 서비스가 별도의 2차 요소를 더 얹을 수 있습니다. 그래서 소셜 로그인을 쓰더라도 민감한 작업 앞에 TOTP를 한 겹 더 두는 설계가 가능합니다.

TOTP가 신기해 보이는 이유는, 인증 앱이 서버와 통신하지 않는데도 매번 같은 6자리가 맞아떨어지기 때문입니다. 비밀은 두 가지를 양쪽이 똑같이 공유한다는 데 있습니다. 하나는 등록 시점에 단 한 번 주고받은 비밀 키(secret), 다른 하나는 누구에게나 똑같은 현재 시각입니다.

동작은 이렇게 흘러갑니다. 서버가 무작위 비밀 키를 만들어 QR 코드로 보여주면, 사용자의 인증 앱이 그 키를 저장합니다. 이후 앱은 30초마다 (현재 시각 ÷ 30초)와 비밀 키를 해시 함수(HMAC-SHA1)에 넣어 6자리를 뽑아냅니다. 서버도 같은 비밀 키와 같은 시각으로 같은 계산을 하므로 결과가 일치합니다. 네트워크가 끊긴 비행기 안에서도 코드가 맞는 이유가 이것입니다.

HOTP라는 변형도 있습니다. 시간 대신 카운터(몇 번째 코드인지)를 쓰는 방식인데, 카운터가 양쪽에서 어긋나기 쉬워 실무에서는 거의 TOTP를 씁니다. 우리도 TOTP만 다루겠습니다.

2차 요소로 무엇을 쓸지가 첫 갈림길입니다. 흔히 쓰는 세 가지를 비용·보안·구현 난이도로 비교하겠습니다.

SMS는 직관적이지만 약점이 분명합니다. 문자 한 건마다 발송 비용이 들고, 1인 서비스에 사용자가 늘면 그대로 고정비가 됩니다. 보안 측면에서도 유심 스와핑(번호 탈취)이나 문자 가로채기에 취약해, 국제 보안 가이드는 SMS를 권장 수단에서 점점 내리는 추세입니다. 무엇보다 국내에서 문자를 보내려면 발송 대행사를 붙이고 발신번호 사전 등록을 해야 해서, 1인 개발자에게는 설정 부담이 큽니다.

인증 앱 방식(TOTP)은 그 반대입니다. 코드를 사용자 휴대폰이 직접 계산하니 발송 비용이 0원이고, 표준이 공개돼 있어 어떤 인증 앱과도 호환됩니다. 제가 직접 붙여 본 결과 구현도 가장 단순했습니다. 보안 키(WebAuthn·하드웨어 키)는 가장 강력하지만 물리 기기가 필요해, 사내 어드민처럼 사용자가 한정된 곳이 아니면 일반 서비스에는 과한 선택입니다.

슈퍼베이스를 쓰고 계신다면 이게 가장 빠른 길입니다. 비밀 키 생성·QR 코드·검증·세션 등급 관리를 슈퍼베이스가 다 처리하므로, 우리는 화면 흐름만 붙이면 됩니다. 저는 tech.ambitstock 본체를 Next.js와 슈퍼베이스, 버셀(Vercel)로 1인 운영하고 있어서 어드민 보호에 이 방식을 그대로 썼습니다.

전체 흐름은 세 단계입니다. (1) enroll로 새 요소를 등록하며 QR을 받아 사용자에게 보여주고, (2) challenge로 검증 요청을 만든 뒤, (3) 사용자가 입력한 6자리를 verify로 확인합니다. 먼저 등록 부분입니다.

등록으로 받은 qr_code를 화면에 띄우면 사용자가 인증 앱으로 찍습니다. 그다음 사용자가 앱에 뜬 6자리를 입력하면, 그 값으로 검증을 마쳐 요소를 활성화합니다. 검증 단계는 challenge와 verify가 한 쌍입니다.

핵심 개념이 AAL(Authenticator Assurance Level)입니다. 비밀번호만으로 로그인한 세션은 aal1, 여기에 2차 인증까지 통과하면 aal2가 됩니다. 그래서 민감한 페이지(결제·관리자 화면)는 aal2일 때만 접근을 허용하도록 막으면 됩니다. 로그인 직후 현재 등급을 확인하는 코드는 다음과 같습니다.

인증을 직접 만든 백엔드(Node·Next.js API 라우트)라면 표준 라이브러리로 같은 결과를 얻을 수 있습니다. 검증된 조합은 비밀 키 생성·검증용 speakeasy와 QR 이미지 생성용 qrcode입니다. 둘 다 의존성이 가볍고 오래 검증됐습니다.

구현은 슈퍼베이스 흐름과 똑같이 (1) 비밀 키 발급, (2) QR 표시, (3) 코드 검증 세 단계입니다. 먼저 등록 시 비밀 키를 만들고 사용자에게 보여줄 QR을 생성하는 서버 코드입니다.

사용자가 QR을 등록한 뒤 입력한 6자리를, 저장해 둔 비밀 키와 맞춰 검증합니다. 여기서 시계 오차를 흡수하는 window 값이 등장합니다.

여기서 보안상 절대 빠뜨리면 안 되는 두 가지가 있습니다. 첫째, 비밀 키(base32)는 서버 데이터베이스에만 저장하고 클라이언트로 절대 보내지 않습니다. 둘째, 검증에 성공한 코드를 짧은 시간 동안 재사용하지 못하게 막아야 합니다. TOTP 코드는 30초간 유효한데, 공격자가 같은 코드를 그 안에 가로채 재전송하면 통과될 수 있기 때문입니다. 마지막으로 쓴 코드의 시각을 기록해 같은 칸의 코드를 두 번 받지 않도록 거르면 안전합니다.

2차 인증을 붙이면 새로운 사고가 생깁니다. 사용자가 휴대폰을 바꾸거나 잃어버려 인증 앱이 사라지면, 본인인데도 영영 못 들어오는 잠금 상태에 빠집니다. 이걸 대비하지 않으면 2FA는 보안 기능이 아니라 고객센터 문의 폭탄이 됩니다.

표준 해법이 복구 코드(recovery code)입니다. 등록을 마치는 순간, 한 번만 쓸 수 있는 일회용 코드 8~10개를 한꺼번에 발급해 사용자가 안전한 곳에 보관하게 합니다. 인증 앱을 잃으면 이 코드 중 하나로 로그인해 2FA를 다시 설정합니다. 구현 시 지켜야 할 원칙은 다음과 같습니다.

• 발급은 등록 직후 단 한 번만 보여줍니다. 화면을 닫으면 다시 못 봅니다.
• 데이터베이스에는 원문이 아니라 해시로 저장합니다. 비밀번호처럼 단방향 해시(bcrypt 등)로 보관해야 유출돼도 안전합니다.
• 한 번 쓴 코드는 즉시 폐기합니다. 재사용을 막아야 일회용의 의미가 삽니다.
• 남은 개수를 사용자에게 알려 떨어지기 전에 재발급하도록 안내합니다.

기술이 맞아도 화면이 낯설면 사용자는 중간에 포기합니다. 특히 한국 사용자는 카카오·네이버·토스의 간편 인증에 익숙해서, 인증 앱을 따로 깔아 QR을 찍는 흐름 자체가 생소할 수 있습니다. 제가 화면을 다듬으며 신경 쓴 포인트를 정리합니다.

• 인증 앱 설치부터 손을 잡아줍니다. "인증 앱을 여세요"로 시작하지 말고, 구글 OTP·Microsoft Authenticator 등 어떤 앱을 어디서 받는지 링크와 함께 먼저 안내합니다. 앱이 없는 사용자가 대부분이라는 전제로 화면을 짜야 합니다.
• QR을 못 찍는 경우의 수동 입력 키를 항상 함께 보여줍니다. PC에서 로그인하는 사용자는 같은 화면의 QR을 휴대폰으로 못 찍습니다. base32 비밀 키를 복사 버튼과 함께 두면 막힘이 줄어듭니다.
• 6자리 입력칸은 숫자 키패드로 띄웁니다. 모바일에서 inputmode="numeric"을 주면 자판이 바로 숫자로 떠서 입력이 빨라집니다.
• 30초 갱신을 설명합니다. 코드가 자꾸 바뀌는 걸 오류로 오해하는 분이 있어, "코드는 30초마다 바뀝니다"라는 한 줄을 입력칸 옆에 둡니다.
• 복구 코드 보관 안내를 한국어로 분명히 합니다. 캡처하거나 출력해 두라고 구체적으로 말해야 나중에 잠금 사고를 줄입니다.

로그인 위임은 카카오·네이버 같은 소셜 로그인에 맡기고, 그 위에 결제나 관리자 작업처럼 정말 위험한 행동 앞에서만 2차 인증을 한 번 더 요구하는 설계가 한국 사용자 정서에 잘 맞았습니다. 모든 로그인마다 OTP를 강제하면 이탈이 커지니, 위험한 구간에만 거는 단계적 적용을 권합니다.

케이스 → 원인 → 해결 순으로 자주 막히는 지점을 정리합니다. 대부분 처음 붙일 때 한 번씩 겪는 것들입니다.

특히 첫 번째와 세 번째가 흔합니다. 서버 시각 문제는 클라우드라면 대개 동기화돼 있지만, 직접 띄운 가상 서버나 로컬 도커에서 시각이 밀려 있으면 멀쩡한 코드가 계속 거부됩니다. 재사용 방지는 코드 줄 수가 얼마 안 돼 빠뜨리기 쉬운데, 보안의 핵심이라 반드시 넣으셔야 합니다.

참고 자료

• Supabase 공식 문서 — Multi-Factor Authentication(MFA) 가이드 : enroll·challenge·verify와 AAL 개념, RLS 연동 예제까지 가장 정확한 1차 출처입니다.
• RFC 6238 — TOTP: Time-Based One-Time Password Algorithm : TOTP의 표준 명세 원문으로, 시간 단계·window·HMAC 계산 방식의 근거입니다.
• speakeasy GitHub 저장소 : 직접 구현 시 쓰는 TOTP 라이브러리의 API와 옵션(window·encoding 등)을 확인할 수 있습니다.