AI 에이전트 보안, 딥페이크로 위임자를 사칭하는 공격과 본인 확인 대응

트렌드
2026-10-27

AI 에이전트 보안에서 딥페이크 사칭은 어떤 위협인가요?

AI 에이전트는 누군가 맡긴 권한으로 결제, 데이터 조회, 메일 발송 같은 일을 대신 처리합니다. 공격자 입장에서는 에이전트를 직접 해킹하는 것보다, 에이전트에게 권한을 맡기는 사람인 위임자로 가장하는 편이 훨씬 쉽습니다. 위임자의 얼굴을 딥페이크로 만들어 본인 확인을 통과하면, 공격자는 정상적인 절차를 거쳐 에이전트의 권한을 얻게 됩니다. 이 경우 에이전트의 행동 기록은 모두 정상으로 보이기 때문에 피해를 알아차리기도 어렵습니다.

딥페이크로 위임자를 사칭하는 경로는 크게 세 가지입니다. 에이전트를 등록할 때 위임자의 얼굴을 위조하는 방법, 영상 통화에서 위임자인 척 승인을 받아 내는 방법, 카메라를 거치지 않고 조작된 영상을 직접 주입하는 인젝션 공격입니다. 특히 등록과 승인이 모두 원격으로 이루어지는 비대면 환경에서는 공격자가 위임자를 직접 만날 필요가 없어 시도하는 데 드는 비용이 낮습니다. 경로마다 막는 방법이 다르기 때문에 하나씩 나눠서 대비해야 합니다.

‍

에이전트가 있으면 사칭 피해가 더 빨라집니다

사람이 직접 일을 처리할 때는 사칭에 성공해도 공격자가 한 건씩 손으로 처리해야 합니다. 에이전트는 확인된 권한으로 같은 작업을 빠르게 반복하기 때문에, 한 번의 사칭이 짧은 시간 안에 여러 건의 결제나 대량의 데이터 반출로 이어질 수 있습니다. 에이전트 보안 체계 전반의 구성은 기업 AI 에이전트 보안 시스템 구축 글에서 다뤘고, 이 글은 딥페이크를 이용한 위임자 사칭에 대응하는 방법에 집중합니다.

‍

등록 단계에서 얼굴을 위조하는 공격은 어떻게 막나요?

에이전트를 등록하고 권한을 처음 맡기는 단계에서 본인 확인이 뚫리면, 그 뒤의 모든 기록이 공격자를 위임자로 인정하게 됩니다. 이 단계에서 쓰이는 위조 방식은 위임자의 사진을 출력해 비추는 방식, 휴대폰이나 모니터에 사진이나 영상을 띄워 촬영하는 방식, 정교한 가면을 쓰는 방식, 그리고 딥페이크로 만든 영상을 화면에 재생하는 방식입니다. 모두 카메라 앞에 실제 사람이 아닌 무언가를 보여 주는 공격이라 프레젠테이션 공격이라고 부릅니다. 최근에는 생성형 AI로 위임자의 얼굴이 고개를 돌리고 눈을 깜빡이는 영상까지 쉽게 만들 수 있어, 정해진 동작을 따라 하는지만 보는 방식으로는 부족해지고 있습니다.

‍

신분증과 얼굴을 함께 확인합니다

프레젠테이션 공격을 막으려면 얼굴만 보지 않고 신분증과 얼굴을 함께 확인해야 합니다.

  • 신분증 사본판별: 제출된 신분증이 실물인지, 출력물이나 화면을 다시 촬영한 사본인지 가려냅니다.
  • 얼굴 위변조 판별: 카메라 앞의 얼굴이 사진, 화면, 가면, 재생 영상이 아니라 실제 사람인지 확인합니다. 흔히 라이브니스라고 부르는 단계입니다.
  • 얼굴 매칭: 신분증 사진과 촬영한 얼굴이 같은 사람인지 비교합니다.

세 단계 중 하나라도 빠지면 빈틈이 생깁니다. 얼굴 매칭만 하면 사진을 비춰 통과할 수 있고, 위변조 판별만 하면 실제 사람이지만 다른 사람인 경우를 놓칩니다. 신분증에 공격자의 얼굴을 넣어 위조한 경우에는 얼굴 매칭이 그대로 통과하기 때문에, 신분증이 실물인지 확인하는 단계도 반드시 함께 있어야 합니다.

‍

알체라 eKYC로 등록 단계의 위조를 막으면

등록 단계의 얼굴 위조를 막으려면 신분증과 얼굴 양쪽에서 위조 여부를 함께 확인할 수 있어야 합니다. 알체라 eKYC는 사본판별을 통해 출력물이나 화면을 다시 촬영한 신분증을 걸러내고, 촬영된 얼굴의 위변조 여부를 판별한 뒤 신분증 사진과 매칭하여 동일인 여부를 확인합니다. 얼굴 위변조 판별에는 국내에서 유일하게 RGB 카메라 기반으로 iBeta 얼굴 위변조 탐지(PAD) 평가를 통과한 기술이 적용되어 있습니다.

‍

영상 통화로 승인을 사칭하는 공격은 어떻게 막나요?

실시간 얼굴 합성 기술이 발전하면서, 영상 통화 화면에 다른 사람의 얼굴을 입혀 대화하는 일이 가능해졌습니다. 공격자는 이를 이용해 영상 통화로 위임자인 척하며 담당자에게 에이전트 권한 확대나 송금 승인을 요청합니다. 상대의 얼굴과 목소리가 익숙하면 담당자는 의심하지 않고 요청을 처리하기 쉽습니다. 예를 들어 출장 중인 임원이 영상 통화로 급한 거래처 결제를 위해 에이전트의 결제 한도를 올려 달라고 요청하면, 담당자는 상대가 임원이라고 믿고 설정을 바꿀 수 있습니다. 공격자는 그 직후 에이전트를 통해 결제를 실행합니다.

‍

 

  • 영상 통화를 승인 수단으로 쓰지 않습니다. 영상 통화는 대화 수단일 뿐이고, 승인은 정해진 본인 확인 절차를 거친 경우에만 인정합니다.
  • 다른 채널로 다시 확인합니다. 영상 통화로 받은 요청은 사내 메신저나 등록된 전화번호처럼 미리 정해 둔 다른 채널로 요청자에게 직접 확인합니다.
  • 승인은 위임자 본인이 직접 합니다. 다른 사람이 대신 승인을 넣는 구조를 없애고, 위임자가 얼굴 위변조 판별을 거친 본인 확인으로만 승인하도록 합니다.
  • 요청 내용을 기록합니다. 누가 어떤 채널로 무엇을 요청했는지 남겨 두면, 같은 방식의 사칭이 반복될 때 빠르게 알아챌 수 있습니다.

급하다는 이유로 절차를 건너뛰자는 요청 자체를 사칭의 신호로 보고, 예외 없이 같은 절차를 따르도록 내부 규칙을 정해 두는 것이 중요합니다.

‍

인젝션 공격은 무엇이 다르고 어떻게 대응하나요?

인젝션 공격은 카메라 앞에 무언가를 보여 주는 대신, 카메라 입력 자체를 바꿔치기하는 방식입니다. 가상 카메라 프로그램이나 에뮬레이터를 이용해 딥페이크 영상을 실제 카메라가 촬영한 것처럼 앱에 직접 넣습니다. 화면을 다시 찍는 과정이 없어 반사나 화면 경계 같은 흔적이 남지 않기 때문에, 프레젠테이션 공격을 막는 방식만으로는 놓칠 수 있습니다. 공격자가 가진 위임자의 사진 몇 장만으로도 딥페이크 영상을 만들어 주입할 수 있기 때문에, 공개된 프로필 사진이 많은 임원이나 관리자일수록 표적이 되기 쉽습니다.

  • 촬영 환경 확인: 실제 기기의 카메라에서 들어온 영상인지, 가상 카메라나 에뮬레이터를 거친 입력인지 확인합니다.
  • 기기 무결성 확인: 루팅이나 탈옥, 변조된 앱처럼 입력을 조작할 수 있는 환경인지 점검합니다.
  • 촬영 세션 확인: 본인 확인을 요청한 세션과 실제로 영상이 들어온 세션이 같은지 확인해 중간에 끼어든 입력을 걸러냅니다.

‍

인젝션 공격 대응은 앱과 서버 양쪽에서 함께 설계해야 하므로, 본인 확인 솔루션을 도입할 때 어떤 방식으로 인젝션을 막는지 미리 확인해 두는 것이 좋습니다. 웹 브라우저에서 본인 확인을 받는 경우에는 앱보다 입력을 조작하기 쉬운 환경이 많으므로, 고위험 작업의 승인만큼은 점검이 가능한 앱이나 기기에서 받도록 제한하는 방법도 함께 검토합니다.

‍

운영 중 사칭 시도는 어떻게 발견하나요?

막는 장치를 갖춰도 공격은 계속 시도됩니다. 운영 기록에서 아래와 같은 신호가 보이면 사칭 시도일 가능성을 의심합니다.

  • 같은 계정에서 본인 확인 실패가 짧은 시간에 반복되는 경우
  • 처음 보는 기기나 위치에서 등록이나 권한 변경이 요청되는 경우
  • 에이전트 등록 직후 결제나 대량 데이터 반출 같은 고위험 작업이 바로 요청되는 경우
  • 짧은 시간 안에 여러 계정에서 비슷한 방식의 등록 시도가 이어지는 경우

이런 신호가 보이면 해당 에이전트의 고위험 작업을 잠시 멈추고, 위임자에게 다른 채널로 연락해 요청 사실을 확인합니다. 확인 결과와 조치 내용은 다음 공격을 분석할 수 있도록 기록으로 남깁니다. 의심 신호의 기준은 처음부터 완벽하게 정하기 어렵기 때문에, 실제로 확인된 사칭 시도와 오탐 사례를 모아 기준을 주기적으로 조정합니다. 정상 사용자가 자주 걸리는 기준은 완화하고, 실제 공격에서 나타난 패턴은 새 기준으로 추가하는 방식입니다.

‍

정리: 딥페이크 위임자 사칭 대응 점검 목록

  1. 에이전트 등록 시 신분증 사본판별, 얼굴 위변조 판별, 얼굴 매칭을 모두 거치는가
  2. 영상 통화로 받은 요청을 승인으로 인정하지 않고 다른 채널로 다시 확인하는가
  3. 승인은 위임자 본인이 얼굴 위변조 판별을 거친 본인 확인으로만 하는가
  4. 가상 카메라, 에뮬레이터, 변조된 기기 같은 인젝션 경로를 점검하는가
  5. 반복 실패, 새 기기, 등록 직후 고위험 요청 같은 사칭 신호를 모니터링하는가
  6. 사칭이 의심되면 고위험 작업을 멈추고 위임자에게 다른 채널로 확인하는 절차가 있는가

‍