
딥페이크로 의심되는 시도가 감지되었을 때 그 시도를 걸러내는 것만으로 대응이 끝나지 않습니다. 걸러낸 이후 해당 계정을 어떻게 처리하고 이미 진행 중이던 다른 거래는 어떻게 다룰지가 함께 정해져 있지 않으면 탐지 결과가 실제 피해 방지로 이어지지 못할 수 있습니다. 딥페이크 시도가 확인된 시점에 계정을 임시로 동결하고 진행 중인 출금이나 이체를 함께 보류하는 절차가 탐지 기능과 한 세트로 연결되어야 대응체계라 부를 수 있습니다. 탐지 기능만 갖추고 그 뒤의 조치가 정리되어 있지 않으면 실제 사고 상황에서 담당자가 매번 판단을 새로 내려야 하는 부담이 남습니다.
딥페이크 시도가 확인되면 가장 먼저 해당 계정에서 진행될 수 있는 자산 이동을 제한하는 조치가 필요합니다. 이 조치가 늦어지면 이미 시도된 부정 이체가 완료되어 버릴 수 있습니다. 계정 동결과 자산 이동 제한을 자동으로 함께 실행하도록 구성한다면 담당자의 수동 확인을 기다리는 동안 발생할 수 있는 시간 차이를 줄이는 데 도움이 될 수 있습니다. 정당한 이용자가 동결로 인해 겪는 불편을 줄이기 위한 신속한 재확인 절차도 함께 마련될 필요가 있습니다.

탐지 기준이 실제로 얼마나 정확한지는 이론적인 설계만으로는 확인하기 어렵습니다. 내부 인력이 알려진 딥페이크 제작 방식을 이용해 자체 시스템에 모의 공격을 시도하고 그 결과를 분석하는 절차를 정기적으로 진행한다면 실제 공격이 발생하기 전에 탐지 기준의 허점을 미리 확인하는 데 효과적일 수 있습니다. 이 모의 공격은 외부에 알려지지 않은 최신 수법까지 포함해 반복적으로 갱신될 필요가 있습니다.

한 거래소에서 발견된 새로운 딥페이크 공격 수법은 다른 거래소에서도 곧 시도될 가능성이 있습니다. 거래소마다 이 수법을 각자 알아채야 한다면 대응이 그만큼 늦어집니다. 확인된 공격 수법의 특징을 거래소 간에 공유하는 체계를 마련한다면 아직 해당 수법을 직접 겪지 않은 거래소도 미리 대비할 수 있는 시간을 확보하는 데 도움이 될 수 있습니다. 이 공유는 이용자의 개인정보 대신 공격 수법의 기술적 특징에 한정해 이루어질 필요가 있습니다.

딥페이크로 인한 피해가 실제로 발생하면 이후 수사기관에 협조하거나 피해 경위를 소명해야 하는 상황이 이어집니다. 이 시점에 관련 기록이 정리되어 있지 않으면 소명에 걸리는 시간이 길어집니다. 딥페이크로 의심되는 시도가 감지된 순간부터 관련 영상과 판별 근거, 이후 조치 이력을 위변조되지 않는 형태로 함께 보관하는 절차를 마련한다면 사고 이후의 대응에 걸리는 시간을 줄이는 데 도움이 될 수 있습니다.
딥페이크 대응체계는 한 번에 완성되지 않으며 탐지 기준을 먼저 갖추고 그 위에 동결 절차와 모의 공격 검증 그리고 거래소 간 정보 공유를 순서대로 더해가는 방식으로 다듬어질 필요가 있습니다. 각 단계에서 발견된 허점을 다음 단계 설계에 반영한다면 체계 전체가 한 방향으로만 쌓이지 않고 실제 공격 양상에 맞춰 계속 조정될 수 있습니다. 조직의 규모와 자원에 따라 이 단계를 밟아가는 속도는 다르게 정해질 수 있습니다.
