.svg)
AI 솔루션 문의하기
위협 탐지 에이전트형 AI는 계정 접근과 서비스 이용 기록에서 평소와 다른 행동을 분석하고, 추가 확인이 필요한 사건을 선별하도록 설계할 수 있습니다. 특히 크리덴셜 스터핑 봇, 딥페이크를 이용한 비대면 가입, 프롬프트 인젝션은 침입 경로와 대응 방식이 달라 같은 차단 정책으로 다루기 어렵습니다.
기업의 가입·로그인·거래 서비스에서는 모든 고객에게 같은 강도의 본인확인을 반복하기보다, 위험도가 높은 요청에만 추가 검증을 요구하는 방식이 운영 효율에 적합합니다. 탐지 시스템이 의심 계정이나 요청을 분류하고, 인증 시스템이 해당 계정의 사용자가 실제 등록된 본인인지 재확인하도록 업무를 분리하는 것입니다.
여기서 탐지는 공격 가능성을 판단하는 단계이고, 차단은 인증 실패나 권한 정책 위반에 따라 로그인·거래·계정 변경을 제한하는 단계입니다. 에이전트형 AI가 위험 신호를 발견했다고 해서 곧바로 계정을 폐쇄하거나 모든 API 호출을 막도록 만들 필요는 없습니다. 반대로 얼굴 인증을 도입했다고 해서 봇의 반복 로그인 시도나 AI 에이전트의 잘못된 도구 호출까지 모두 해결되는 것도 아닙니다.
보안관제(SOC)는 서버·네트워크·단말의 보안 이벤트를 폭넓게 모아 분석합니다. 이번 글에서 다루는 범위는 그중에서도 고객 계정의 가입·로그인·인증·거래 이벤트를 연결해 의심 계정을 찾는 흐름입니다. 로그인 실패 횟수만 확인하는 대신 기기 변경, 인증 수단 변경, 거래 요청 및 이전 인증 결과를 함께 검토하면 사건을 더 구체적으로 분류할 수 있습니다.
AI 자동화 공격 대응에서는 공격자가 무엇을 반복하거나 위조하는지에 따라 탐지 데이터를 달리 수집해야 합니다. 다음 세 유형은 같은 '이상행동'처럼 보이더라도 검증 대상이 서로 다릅니다.
크리덴셜 스터핑(Credential Stuffing)은 다른 서비스에서 유출된 아이디·비밀번호 조합을 로그인 화면에 대량 입력해 유효한 계정을 찾는 공격입니다. 자동화 도구는 짧은 시간에 여러 계정으로 접속하거나 여러 기기·IP를 오가며 시도할 수 있습니다.
중요한 점은 봇의 반복 요청 자체는 얼굴 인증으로 처리하지 않는다는 것입니다. 접속 시도 단계에서는 속도 제한과 자동화 방어가 필요합니다. 이후 계정을 장악했을 가능성이 있는 요청에 얼굴 재인증을 추가하는 방식이 적절합니다.
딥페이크 가입은 합성·변조한 얼굴 이미지나 영상을 비대면 신원확인에 제출하여 다른 사람으로 등록하려는 시도입니다. 경우에 따라 화면 재촬영이나 카메라 입력 경로에 조작 영상을 주입하는 방식도 고려해야 합니다.
라이브니스 검사는 제출된 얼굴 영상이 실제 촬영된 사람의 얼굴인지 판별하는 데 활용됩니다. 그러나 라이브니스 통과만으로 신분증 명의와 동일인임을 증명하지는 않습니다. 가입 절차에서는 신분증 사진 또는 신뢰할 수 있는 등록 얼굴과의 비교가 별도로 필요합니다.
프롬프트 인젝션(Prompt Injection)은 AI 에이전트가 읽는 문서, 메시지, 웹페이지, 도구 응답 등에 악성 지시를 심어 원래 업무 범위를 벗어난 행동을 유도하는 공격입니다. 예를 들어 고객 문의를 요약하도록 연결한 에이전트가 외부 문서 속 지시를 따르며 불필요한 고객정보 조회 API를 호출하려는 상황입니다.
단, 프롬프트 인젝션을 얼굴 인증만으로 차단할 수는 없습니다. AI 에이전트의 실행 권한과 도구 호출 자체를 검증하는 통제가 우선입니다. 얼굴 재인증은 그중 특정 계정의 소유자가 승인해야 하는 고위험 작업에만 연결합니다.
에이전트형 AI는 탐지와 사건 분류, 얼굴 인증·라이브니스는 선택된 계정의 신원 재확인에 역할을 두는 것이 명확합니다. 두 기능을 같은 솔루션의 단일 판단으로 취급하지 않고 서비스 서버에서 검증 결과를 결합해야 합니다.
탐지 시스템은 로그인·가입·거래·API 로그를 분석해 위험 신호를 묶고, 추가 확인이 필요한 사유를 서비스에 전달합니다. 이때 위험 등급만 내보내기보다 어떤 이벤트가 발생했는지, 어느 계정과 작업에 해당하는지를 함께 기록해야 담당자가 판단 근거를 검토할 수 있습니다. 에이전트형 AI의 판단은 위험 분류를 돕는 결과이지, 고객의 신원이나 범죄 여부를 확정하는 증거가 아닙니다.
얼굴 인증은 현재 촬영한 얼굴이 기존에 신뢰할 수 있는 방식으로 확인·등록한 기준 얼굴과 일치하는지 비교합니다. 라이브니스·위변조 판별은 사진, 영상, 마스크 등으로 얼굴 입력을 속이려는 시도를 검토하는 기능입니다. 두 검사를 함께 사용하더라도 플랫폼은 판정 기준과 재시도·추가 심사 정책을 따로 마련해야 합니다.
원래 가입 시 검증된 기준 얼굴이 없는 계정이라면 '얼굴 재인증'만으로 해결할 수 없습니다. 이 경우 신분증과 얼굴을 함께 확인하는 최초 신원확인 절차를 먼저 설계해야 합니다.
이 흐름에서 알체라 eKYC는 의심 계정이 재인증할 때 필요한 얼굴 매칭 및 얼굴 위변조 판별 단계에 연결할 수 있습니다. 플랫폼이 위험도를 평가하고 재인증을 요청하면, 알체라 얼굴 인증 기능을 통해 새로 촬영한 얼굴과 기준 얼굴의 일치 여부 및 라이브니스·위변조 판별 결과를 받아 서비스 서버가 최종 처리합니다. 알체라가 크리덴셜 스터핑이나 프롬프트 인젝션을 탐지한다고 의미하는 것은 아닙니다. API 연동의 구체적인 결과 처리 구조는 알체라 안면인증 API 연동 가이드에서도 확인할 수 있습니다.
위험 기반 본인확인을 설계할 때는 평상시 로그인 경험을 유지하면서 의심 요청의 실행만 제어하는 구조가 적합합니다. 로그인 성공, 고액 거래, 비밀번호 재설정, 출금 계좌 변경처럼 사고 영향이 큰 시점을 별도 정책으로 다룹니다.
서비스는 가입·로그인 시각, 기기 변경, 요청 빈도, 거래 유형, 기존 인증 결과를 수집합니다. 탐지 시스템은 규칙과 분석 결과를 결합해 재검증 대상 계정과 해당 사유를 반환합니다. 위험 기준은 업종과 거래 특성에 맞게 설계하며, 모든 이용자를 일괄 재인증 대상으로 지정하지 않습니다.
탐지 결과가 의심 수준이면 고객이 출금, 계좌 변경, 개인정보 변경 등 민감한 작업을 실행하려는 순간 얼굴 재인증 화면을 표시합니다. 재인증 결과는 현재 요청의 계정·세션·작업에 연결하고 유효 시간을 제한합니다. 단순히 과거에 인증을 통과했다는 사실만으로 이후 모든 고위험 요청을 허용하지 않도록 설계합니다.
사용자가 얼굴을 촬영하면 라이브니스·위변조 판별 결과와 기준 얼굴 매칭 결과를 확인합니다. 서비스 서버는 두 결과와 탐지 위험도, 작업 권한을 함께 검토해 실행 허용·재촬영·추가 심사·보류 중 하나로 처리합니다. 라이브니스 실패와 얼굴 불일치는 사유가 다르므로 운영 기록에서도 분리하는 편이 좋습니다.
탐지와 인증을 연동한 뒤에는 정상 고객의 불필요한 인증 반복을 줄이고, 실제 위험 작업이 우회되지 않도록 운영 규칙을 점검해야 합니다. 위험 신호, 인증 결과, 작업 실행 여부를 각각 기록하면 잘못 차단된 사례와 놓친 사례를 구분해 검토할 수 있습니다.
탐지 결과가 높은 위험이라고 해서 무조건 얼굴 인증만 제시할 필요는 없습니다. 이미 확인된 공격 트래픽은 속도 제한이나 접근 차단을 먼저 적용하고, 사람의 계정 소유 여부를 다시 확인해야 하는 작업에만 얼굴 인증을 요청합니다.
프롬프트 인젝션 대응은 계정 재인증과 분리해 운영합니다. AI 에이전트가 외부 문서를 읽었다는 이유만으로 높은 권한을 얻지 못하도록 도구별 접근 범위, API 매개변수 검증, 실행 로그, 고위험 호출에 대한 사람 승인을 설정해야 합니다. 실제 사용자가 계정 변경을 승인해야 하는 경우에만 사람 승인 과정에 얼굴 인증을 결합하는 구조가 적절합니다.
얼굴 인증 결과를 저장할 때는 작업 식별자, 검증 일시, 성공·실패 상태, 정책 판정 등 필요한 범위를 정합니다. 얼굴 이미지와 생체정보는 처리 목적·법적 근거·보유 기간·삭제 정책을 검토해야 하며, 재인증 화면에서도 수집·이용 목적을 분명히 안내해야 합니다. 탐지 결과가 부정확할 수 있으므로 운영자가 판단을 재검토하는 경로도 마련해 두는 것이 좋습니다.
운영 전 테스트에서는 일반 로그인, 봇의 반복 로그인 시도, 로그인 성공 후 계좌 변경, 딥페이크가 의심되는 가입, 에이전트의 권한 밖 API 호출을 서로 다른 시나리오로 구분합니다. 일반 고객의 요청이 불필요하게 멈추지 않는지, 의심 계정의 중요 작업은 인증 결과가 나올 때까지 대기하는지, 인증을 우회한 직접 API 요청이 서버에서 거부되는지 확인해야 합니다.
또한 얼굴 인증 통과 이후에도 거래 유형과 권한 정책을 검사해야 합니다. 얼굴 인증 성공은 그 사람이 누구인지에 관한 확인 결과이지, 해당 사용자가 요청한 모든 작업을 허용한다는 의미가 아니기 때문입니다. 재인증 발생률, 재촬영 비율, 심사 전환 건수, 오탐 문의를 운영 지표로 관리하면 고객 불편과 위험 대응을 함께 조정할 수 있습니다.
위협 탐지 에이전트형 AI와 얼굴 인증·라이브니스를 함께 설계할 때 핵심은 모든 의심 이벤트를 일괄 차단하는 것이 아니라, 공격 유형별 방어 수단을 나누고 필요한 계정에만 재인증을 요구하는 것입니다. 크리덴셜 스터핑에는 봇 방어와 이상행동 분석을, 딥페이크 가입에는 얼굴 위변조 판별과 신원 비교를, 프롬프트 인젝션에는 도구 권한 통제와 고위험 실행 승인을 중심으로 정책을 마련해야 합니다.
도입 전에는 탐지에 사용할 이벤트, 재인증을 요구할 거래, 기준 얼굴의 확보 방법, 라이브니스 실패 처리, 사람 승인·운영자 검토 경로를 먼저 확정하는 것이 좋습니다. 이를 바탕으로 탐지 → 의심 계정 선별 → 얼굴 재인증 → 최종 실행 판단을 분리하면 기존 고객 경험과 보안 통제 범위를 함께 관리할 수 있습니다.
.png)
.svg)
.svg)
