MFA 예시 4가지: 가입·로그인·고액 이체·비밀번호 재설정에서 얼굴 인증 쓰는 법

트렌드
2026-10-27

MFA 예시 얼굴 인증은 어떤 업무 순간에 적용하나요?

MFA 예시 얼굴 인증은 회원가입, 로그인, 고액 이체, 비밀번호 재설정에서 서로 다른 목적으로 활용됩니다. 가입할 때는 처음 등록하는 사람이 누구인지 확인하고, 로그인할 때는 등록된 계정의 정상 이용자인지 판단합니다. 고액 이체에서는 실제 거래를 실행해도 되는 사람인지 다시 확인하며, 비밀번호 재설정에서는 계정을 되찾으려는 사람이 기존 소유자인지 검증합니다.

다중 인증(MFA)은 지식·소유·생체처럼 서로 다른 종류의 인증 요소를 조합하는 방식입니다. 얼굴 인증은 그중 생체 요소에 해당합니다. 신분증 사진과 촬영한 얼굴을 비교하는 최초 신원확인(eKYC)은 등록자의 신원을 검증하는 과정으로, 그것만으로 MFA가 완성되는 것은 아닙니다. 반대로 이미 등록된 기기에서 얼굴을 인식한다고 해서 항상 서버가 신분증 사진과 얼굴을 대조하는 것도 아닙니다. 두 절차를 구분해야 서비스 단계별 인증 정책을 정할 수 있습니다.

‍

이번 글은 일반적인 MFA 기술 설명보다, 각 시나리오에서 언제 추가 인증을 요구하고, 어떤 실패를 어떻게 처리할지에 집중합니다. MFA 개념과 업종별 적용 사례는 다중 인증 MFA 금융기관·IT기업 보안 사례 총정리, 글로벌 기업의 적용 방식은 다중 인증(MFA) 적용 사례에서 따로 확인할 수 있습니다.

‍

시나리오 1. 회원가입: 최초 계정과 실제 사용자 연결

‍

 

상황: 신규 이용자가 처음 계정을 만드는 순간

금융·거래 플랫폼에 신규 이용자가 가입할 때는 실제로 존재하는 사람인지, 제출한 신분증의 소유자와 가입자가 같은 사람인지 확인해야 합니다. 이메일 주소나 휴대전화 번호를 확인하는 것만으로는 실명이나 신분증 소유 관계를 확인하기 어렵습니다. 도용된 신분증 이미지로 가입하거나, 다른 사람의 얼굴 사진을 카메라에 보여주는 방식도 고려해야 합니다.

가입 시점의 목적은 기존 계정에 다시 접근하도록 허용하는 것이 아니라, 이후 인증의 기준이 될 신뢰 가능한 최초 등록 정보를 만드는 것입니다. 따라서 계정 생성이 완료되기 전에 신원확인 결과와 향후 사용할 인증수단의 등록 상태를 별도로 관리하는 구성이 적합합니다.

‍

인증 요소: 신분증 확인·얼굴 매칭 후 소유 요소 등록

‍

  1. 이용자가 신분증을 촬영하면 OCR로 정보를 추출하고, 진위확인과 사본판별로 발급정보 및 제출 이미지의 위험을 각각 확인합니다.
  2. 카메라로 촬영한 얼굴을 신분증 사진과 비교하고, 라이브니스(얼굴 위변조 탐지)를 통해 사진·영상 등으로 대체한 시도를 판별합니다.
  3. 최초 신원확인에 통과한 이용자에게 인증 앱, 신뢰할 수 있는 기기 또는 패스키 등 소유 요소를 등록하도록 합니다. 서비스 정책에 따라 비밀번호 같은 지식 요소와 조합합니다.
  4. 신원확인 결과, 인증수단 등록 완료 여부, 동의 및 처리 이력을 각기 구분해 저장합니다. 생체 이미지의 저장 여부와 보관 기간은 개인정보 처리 정책에 따라 별도로 결정합니다.

가입 단계의 신분증 확인 + 얼굴 매칭은 본인확인의 연속된 검증 절차입니다. 이를 곧바로 서로 다른 인증 요소를 사용한 MFA라고 표시하지 않도록 주의해야 합니다.

‍

실패 시 처리: 촬영 오류와 신원 불일치 분리

빛 반사, 흔들림, 얼굴 가림 등 촬영 품질 문제는 이유를 안내하고 재촬영을 허용할 수 있습니다. 반면 신분증 정보 불일치, 사본 의심, 얼굴 불일치, 라이브니스 실패는 단순 촬영 실패와 구분해야 합니다. 일정 횟수 이상 반복되거나 위험 신호가 겹치면 가입을 보류하고 추가 확인 대상으로 전환합니다.

가입을 완료하지 못한 세션에는 이체·출금 같은 거래 권한을 주지 않으며, 실패한 얼굴 이미지와 신분증 이미지는 업무상 필요한 범위와 보관 정책에 따라 처리합니다. 반복 실패를 무제한 재시도로 허용하지 않는 정책도 함께 설계해야 합니다.

‍

시나리오 2. 로그인: 등록된 이용자의 정상 접근 확인

‍

‍

상황: 기존 계정에 새로운 세션으로 접속하는 순간

로그인에서는 가입할 때 검증한 신원을 매번 처음부터 다시 확인하기보다, 이미 등록된 이용자가 접근하는지 확인하는 것이 목표입니다. 평소 사용하던 기기에서 접속하는 경우와 새 기기·낯선 환경에서 접속하는 경우의 위험도가 같지는 않습니다. 로그인 실패가 반복되거나 접속 환경이 급변하면 추가 인증 조건을 적용할 수 있습니다.

동일한 로그인 화면이라도 일반 접속과 의심 접속을 구분하면, 정상 이용자에게 불필요한 인증을 반복하도록 요구하지 않으면서 위험도가 높은 요청에 더 엄격하게 대응할 수 있습니다.

‍

인증 요소: 비밀번호와 등록 기기·OTP·생체 인증의 조합

일반적인 조합은 비밀번호(지식 요소) + 인증 앱 OTP 또는 등록 기기(소유 요소)입니다. 기기 내 얼굴 인식으로 보호되는 패스키를 쓰는 경우에도, 서버는 기기 또는 인증자의 암호학적 증명을 검증해야 합니다. 단순히 스마트폰 화면에 얼굴 인식 성공 표시가 나타났다는 이유만으로 서버 인증을 통과시켜서는 안 됩니다.

새 기기 로그인, 반복된 비밀번호 오류, 평소와 다른 행동 등이 포착되면 얼굴 재인증을 추가하는 정책을 검토할 수 있습니다. 이때 얼굴 매칭의 비교 기준은 최초 등록 과정에서 적법하게 확보한 기준 정보와 연계되어야 합니다. 로그인 단계에서 다시 신분증 촬영까지 요구할지는 서비스 위험도와 고객 경험을 고려해 정합니다.

‍

실패 시 처리: 계정 접근 제한과 대체 인증 경로

비밀번호 오류는 횟수 제한과 지연 정책을 적용하고, OTP 만료나 푸시 알림 무응답은 재전송·재시도 조건을 구분합니다. 얼굴 인증이 조명이나 카메라 문제로 실패한 경우에는 재촬영 안내를 제공하되, 얼굴 불일치나 위변조 의심 결과는 같은 사유로 취급하지 않습니다.

특히 푸시 승인 요청을 반복해 보내는 공격이나 SIM 스왑을 이용한 문자 인증 가로채기를 고려하면, SMS만을 유일한 복구 수단으로 두는 방식은 위험할 수 있습니다. 반복된 이상 징후가 있으면 세션을 제한하고 기존 등록 기기 또는 별도 본인확인 절차로 전환합니다.

‍

시나리오 3. 고액 이체: 거래 실행 직전 추가 재인증

‍

‍

상황: 로그인 후에도 별도 승인이 필요한 거래

이용자가 정상적으로 로그인했더라도 고액 이체, 신규 수취인 등록, 출금 계좌 변경은 별도의 위험 판단이 필요합니다. 계정에 이미 접근한 공격자가 세션을 탈취했을 가능성까지 고려해야 하기 때문입니다. 이 단계의 질문은 단순히 ‘로그인한 사람인가’가 아니라 ‘이 거래 내용을 확인한 본인이 지금 실행하는가’입니다.

‍

서비스는 금액만으로 고위험 여부를 판단하기보다 신규 수취인, 평소 거래 패턴과의 차이, 기기 변경 직후 거래 등 여러 조건을 조합할 수 있습니다. 아래 절차는 실제 특정 금융사의 구현 사례가 아닌 플랫폼 설계 예시입니다.

‍

인증 요소: 거래 내용 확인 + 소유 요소 + 얼굴 재인증

‍

  1. 이체 금액, 수취 계좌, 수취인 정보를 별도 승인 화면에 명확히 표시하고 이용자가 내용을 확인하도록 합니다.
  2. 등록 기기 또는 인증 앱으로 거래 승인 요청을 보내고, 가능한 경우 승인 데이터가 해당 거래 내용과 연결되도록 설계합니다. 단순 로그인 세션의 성공 여부만 재사용하지 않습니다.
  3. 위험도가 높은 요청에는 얼굴 재인증과 라이브니스 검사를 추가해, 현재 승인하는 사람이 사전에 확인한 이용자와 일치하는지 점검합니다.
  4. 서버는 거래 대상, 승인 시각, 인증 결과, 위험 판정이 모두 일치하는지 확인한 후 최종 실행 여부를 결정합니다. 인증 결과의 유효 시간과 재사용 조건은 거래 정책으로 제한합니다.

‍

얼굴 인증은 거래 실행자의 신원을 재확인하는 수단입니다. 거래 금액의 적정성, 수취인의 신뢰성, 사기 계좌 여부까지 얼굴 인증이 판단하는 것은 아닙니다. 따라서 거래 위험 분석과 얼굴 인증 결과를 각기 다른 검증 항목으로 관리해야 합니다.

‍

실패 시 처리: 이체 보류와 승인 상태 초기화

라이브니스 실패나 등록 얼굴 불일치가 발생하면 이체를 실행하지 않고 보류하는 흐름이 필요합니다. 이용자가 금액 또는 수취 계좌를 바꿨다면 이전에 통과한 인증 결과를 그대로 적용하지 않고 새로운 거래 승인 과정을 시작해야 합니다. 타임아웃, API 오류, 네트워크 단절은 본인확인 실패와 구분하되, 확인되지 않은 상태에서 거래가 자동 승인되도록 두지 않습니다.

반복된 얼굴 불일치나 비정상적인 거래 요청은 추가 심사 대상으로 넘길 수 있습니다. 반면 일시적인 촬영 품질 문제는 제한된 재시도를 제공하고, 거래 실행 결과가 중복 반영되지 않도록 요청 식별자와 상태를 관리해야 합니다.

‍

알체라 eKYC 얼굴 인증으로 고위험 재인증을 구성하면

고액 이체 직전에는 얼굴 매칭과 라이브니스 검사가 필요한 시점에만 호출되도록 구성할 수 있습니다. 알체라 eKYC는 촬영한 얼굴의 위변조 여부를 판별하고 신분증 사진 등 기준 이미지와 동일인 여부를 확인하는 기능을 제공합니다. 고객사 시스템은 이 결과를 등록 기기 인증, 이체 승인 정책, 거래 보류 처리와 연결합니다. 얼굴 검증은 알체라가 제공하되, 이체 실행 권한과 최종 승인 판단은 고객사의 서비스가 관리한다는 구분이 중요합니다.

‍

시나리오 4. 비밀번호 재설정: 계정 복구 과정의 본인확인

‍

‍

상황: 기존 인증수단을 사용하지 못하는 순간

비밀번호를 잊었거나 기존 휴대전화를 잃어버린 이용자는 정상 로그인 절차를 통과하지 못할 수 있습니다. 이때 비밀번호 재설정 또는 인증수단 초기화를 요청하는 절차는 공격자에게도 계정 접근 경로가 될 수 있습니다. 특히 다른 사람의 전화번호를 탈취하는 SIM 스왑, 고객센터 직원을 속여 인증수단을 해제하게 하는 헬프데스크 사칭을 고려해야 합니다.

비밀번호 변경과 인증수단 전체 재등록은 위험이 같지 않습니다. 기존 기기를 보유한 이용자의 비밀번호 변경보다, 모든 인증수단을 잃었다고 주장하는 이용자의 계정 복구를 더 엄격하게 설계하는 편이 합리적입니다.

‍

인증 요소: 기존 신뢰 수단 확인 또는 신규 신원 재검증

기존 등록 기기가 남아 있다면 그 기기에서 복구 요청을 승인하도록 구성할 수 있습니다. 등록 기기가 없다면 가입 당시 검증한 정보와 신분증 진위확인·얼굴 매칭·라이브니스 등을 다시 대조하는 대체 신원확인 절차를 검토합니다. 문자 인증코드만 받았다는 사실을 계정 소유의 충분한 증거로 간주하지 않도록 합니다.

복구가 승인되더라도 새로운 비밀번호나 인증수단을 등록하기 전 기존 등록 연락처로 알림을 보내고, 위험도에 따라 대기 시간이나 거래 제한을 적용할 수 있습니다. 인증수단 재등록이 완료되면 기존 세션과 복구용 토큰의 유효성을 재검토해야 합니다.

‍

실패 시 처리: 자동 복구 중단과 수동 심사

제출 신분증이 기존 계정과 불일치하거나 얼굴 매칭·라이브니스 검사가 반복 실패하면 자동 복구를 중단합니다. 기존 연락처와 새 연락처의 정보가 갑자기 달라졌거나 단기간에 복구 요청이 반복되는 경우도 추가 확인 신호입니다. 이런 요청을 고객센터가 구두 확인만으로 승인하지 않도록 내부 승인 조건과 상담 기록 기준을 정합니다.

복구 실패 시에는 재시도 횟수, 대체 접수 경로, 수동 심사 결과 통보 방식을 안내합니다. 반대로 복구 성공 후에는 비밀번호 변경·인증수단 변경·기존 세션 해제가 정확히 반영됐는지 확인하고, 예상하지 못한 복구가 발생했을 때 이용자가 신고할 수 있는 경로를 제공해야 합니다.

‍

정리: MFA 예시 얼굴 인증 도입 전 시나리오별 점검 사항

MFA 얼굴 인증의 설계 기준은 인증 횟수를 늘리는 것이 아니라, 각 업무 단계에서 확인해야 할 사실을 구분하는 것입니다. 가입에서는 신분증과 얼굴로 최초 신원을 확인하고, 로그인에서는 등록된 인증수단을 검증하며, 고액 이체에서는 거래 실행 직전 추가 승인을 받습니다. 비밀번호 재설정에서는 기존 인증수단을 사용할 수 없는 상황을 악용한 계정 탈취를 경계해야 합니다.

운영 담당자는 다음 질문을 기준으로 인증 정책을 검토할 수 있습니다.

‍

  • 회원가입: 신분증 진위확인·사본판별·얼굴 매칭 결과가 일치하는지, 실패한 가입을 어떻게 보류할지
  • 로그인: 정상 접속과 의심 접속에 서로 다른 인증 조건을 적용하는지, 등록 기기 분실 시 대체 경로가 있는지
  • 고액 이체: 얼굴 재인증이 실제 이체 내용과 연결되는지, 인증 실패 시 거래를 실행하지 않는지
  • 비밀번호 재설정: SIM 스왑·헬프데스크 사칭에 대비했는지, 계정 복구 후 기존 세션과 인증수단을 정리하는지

‍

다른 MFA 도입 방식과 업종별 사례를 살펴보려면 앞서 소개한 알체라 내부 콘텐츠를 참고할 수 있습니다. 실제 인증 시스템에서는 얼굴 검증 결과와 거래 승인 결정을 분리하고, 실패 유형별로 재시도·보류·수동 심사를 나누는 것이 중요합니다.

‍