2단계 인증이란? 쉬운 설명 가이드

2단계 인증(2FA)은 본인이 맞는지 확인하기 위해 서로 다른 두 종류의 증명을 요구하는 로그인 방식입니다. 보통 알고 있는 것, 예를 들어 비밀번호와, 가지고 있는 것, 예를 들어 휴대폰이나 보안 키를 함께 요구합니다. 범죄자가 비밀번호를 훔치거나 추측하더라도, 두 번째 요소 없이는 들어갈 수 없습니다. 중요한 계정을 보호하는 가장 간단한 방법 중 하나입니다.

AI로 만들 때 중요한 이유

AI 빌더에 “로그인”을 요청하면 보통 이메일과 비밀번호가 나옵니다. 좋은 출발점이지만, 비밀번호는 재사용되고, 피싱되고, 유출됩니다. 앱에 고객 기록, 청구서, 관리자 기능, 결제 설정처럼 가치 있는 것이 있다면, 비밀번호 하나가 도난당하는 것만으로 모든 것이 노출될 수 있습니다.

2FA는 처음에는 떠올리지 않았을 결정들에도 영향을 줍니다:

• 누가 사용해야 하는가. 선택 사항으로 둘지, 관리자에게만 요구할지, 모든 사용자에게 요구할지?
• 어떤 방식을 지원하는가. 앱의 코드, 문자 메시지, 패스키, 보안 키.
• 잠겼을 때 어떻게 하는가. 휴대폰 분실은 2FA를 쓰는 앱에서 가장 흔한 고객 지원 요청입니다.
• 어디서 강제하는가. 확인은 반드시 서버에서 이루어져야 합니다. 브라우저에서만 2FA 화면을 숨기는 방식은 우회될 수 있습니다.

암호화 기술을 직접 만들 필요는 없습니다. 검증된 라이브러리와 인증 제공업체가 이를 처리합니다. 하지만 무엇을 요청해야 하는지는 알아야 합니다.

일상 속 비유

은행의 대여 금고를 생각해보세요. 열려면 신분증(은행이 당신이 누구인지 확인하는 것 또는 알고 있는 것)과 동시에 실제 열쇠(가지고 있는 것)가 필요합니다. 서명을 베낀 도둑은 열쇠가 없으니 들어갈 수 없습니다. 열쇠를 소매치기한 도둑도 신분 확인에서 막힙니다.

2FA도 같은 원리로 작동합니다. 비밀번호는 서명이고, 휴대폰이나 보안 키는 실제 열쇠입니다. 둘 중 하나만으로는 충분하지 않습니다.

세 가지 종류의 요소

미국 국립표준기술연구소(NIST)의 디지털 신원 가이드라인 같은 보안 표준은 요소를 세 가지 종류로 나눕니다:

핵심 단어는 서로 다른입니다. 비밀번호와 보안 질문은 둘 다 알고 있는 것이므로, 진정한 2단계 인증이 아닙니다. 한 번의 유출로 둘 다 드러날 수 있다면 하나로 쳐야 합니다.

일반적인 2FA 방식 비교

NIST 지침은 코드를 직접 입력하는 방식(SMS, 이메일, 인증 앱)을 피싱에 강하지 않은 방식으로 보고, 전화망으로 코드를 보내는 방식은 “제한적”으로 표시합니다. WebAuthn/FIDO2 표준에 기반한 패스키와 하드웨어 보안 키는 피싱에 강한 방식으로 인정합니다.

실용적인 결론은 이렇습니다. 인증 앱은 대부분의 앱에 강하고 쉬운 기본값이며, 사용자가 익숙하다면 패스키 제공도 가치가 있습니다.

실제 예시: 고객 포털의 2FA

작은 회계 사무소가 고객과 세무 서류를 공유하는 포털을 만들었다고 가정해봅시다. 합리적인 2FA 설정이 어떻게 작동하는지 단계별로 보겠습니다.

켜기(등록). 고객 Priya가 설정을 열고 “2단계 인증 켜기”를 클릭합니다. 앱이 비밀 값을 만들고 QR 코드로 보여줍니다. 그녀가 인증 앱으로 스캔하면 6자리 코드가 나오기 시작합니다. 설정이 제대로 되었는지 확인하기 위해 현재 코드를 포털에 입력합니다. 앱은 복구 코드 10개를 보여주고, 안전한 곳에 저장하라고 요청합니다.

그 후의 로그인.

1. Priya가 이메일과 비밀번호를 입력합니다. 서버가 이를 확인합니다.
2. 서버는 그녀를 바로 로그인시키지 않고, 세션을 “비밀번호 확인 완료, 두 번째 요소 대기 중” 상태로 표시하고 코드 화면을 보여줍니다.
3. 그녀는 앱의 코드를 입력합니다. 서버는 저장된 비밀 값과 대조하며, 약간의 시계 오차를 허용합니다.
4. 이제야 서버가 완전한 세션을 만들고 그녀가 문서를 볼 수 있게 합니다.

공격자의 시점. Priya의 비밀번호가 다른 사이트에서 유출되었다면, 공격자는 3단계에서 막힙니다. 코드 입력 실패는 모두 집계되며, 여러 번 틀리면 계정이 일시적으로 잠기고 Priya에게 이메일이 전송됩니다.

휴대폰을 잃어버렸을 때. Priya는 복구 코드 중 하나로 로그인하고, 2FA를 끈 뒤 새 휴대폰으로 다시 켜서 새 복구 코드를 받습니다. 사용한 복구 코드는 다시는 쓸 수 없습니다.

직원의 경우. 사무소 회계사들은 모든 고객의 파일을 볼 수 있으므로, 포털은 직원 계정에 2FA를 필수로 요구합니다. 등록을 마치기 전에는 대시보드에 접근할 수 없습니다.

주요 용어 설명

흔한 실수와 오해

• “2FA를 쓰면 계정을 해킹할 수 없다.” 훨씬 어려워질 뿐입니다. 피싱 사이트는 입력된 코드를 실시간으로 가로챌 수 있으며, 그래서 패스키가 존재합니다.
• 브라우저에서만 코드 확인하기. 서버가 비밀번호 확인 후 완전한 세션을 발급한다면, 코드 화면은 장식에 불과합니다. 서버는 두 번째 요소가 통과하기 전까지 접근을 거부해야 합니다.
• 코드 추측 횟수 제한 없음. 6자리 코드에는 백만 가지 경우의 수가 있습니다. 요청 제한(rate limiting)과 잠금이 없으면 공격자는 계속 추측할 수 있습니다.
• 복구 방법을 잊기. 복구 코드가 없으면 휴대폰을 잃을 때마다 고객 지원 요청이 되거나, 고객이 잠겨버립니다.
• TOTP 비밀 값을 부주의하게 저장하기. 공유 비밀 값은 데이터베이스에 암호화되어 있어야 하며, 설정 후에는 다시 보여주지 않아야 합니다.
• 사용자가 검증 없이 2FA를 끄도록 허용하기. 2FA를 끄거나 계정 이메일을 바꿀 때는 비밀번호와 현재 코드를 다시 요구해야 합니다.
• 비밀번호와 보안 질문을 2FA로 여기기. 그렇지 않습니다. 둘 다 알고 있는 것입니다.

AI 빌더에 요청할 내용

• “인증 앱(TOTP)을 사용하는 선택형 2단계 인증을 추가해줘. 설정용 QR 코드를 보여주고, 켜기 전에 확인 코드를 입력받게 해줘.”
• “2FA를 켜면 일회용 복구 코드 10개를 보여줘. 비밀번호처럼 해시해서 저장해줘.”
• “2FA는 서버에서 강제해줘. 두 번째 요소가 통과하기 전까지는 완전한 세션을 주지 마.”
• “코드 입력 시도를 제한하고, 여러 번 실패하면 15분 동안 로그인을 잠가줘. 그럴 때는 사용자에게 이메일을 보내줘.”
• “관리자 계정에는 2FA를 필수로 해줘.”
• “2FA를 끄거나 계정 이메일을 바꿀 때는 비밀번호와 현재 코드를 요구해줘.”
• “직접 암호화를 구현하지 말고, 잘 알려진 라이브러리나 우리 인증 제공업체의 내장 2FA를 써줘.”
• “어떤 방식을 사용했고 비밀 값을 어디에 저장하는지 설명해줘.”

호스팅 인증 제공업체를 쓴다면, 이미 2FA나 패스키를 제공하는지 확인하세요. 내장 기능을 켜는 편이 보통 직접 만든 코드보다 안전합니다. 단계별 방법은 2단계 인증 추가 방법에서 보실 수 있고, 그 기반이 되는 로그인 개념은 인증이란 무엇인가에서 다룹니다.

Mythex에서의 2단계 인증

Mythex는 앱 사용자를 위한 로그인 시스템을 내장하고 있지 않으므로, 2FA는 선택한 인증 방식의 일부입니다. 프로젝트의 데이터베이스로 뒷받침되는 자체 이메일과 비밀번호 로그인이거나, 2FA를 제공하는 호스팅 제공업체일 수 있습니다. 채팅에서 에이전트에게 추가를 요청하면 되며, 제공업체 키는 채팅이 아니라 프로젝트 비밀 값에 넣습니다. 앱에 로그인 추가하기 문서에 시작용 프롬프트가 있어 이를 응용할 수 있고, 직접 만든 앱의 보안은 키 관리 습관을 다룹니다. 출시 전에는 AI로 만든 앱을 위한 보안 체크리스트를 확인하세요.

자주 묻는 질문