권한 변경 시 재인증 필수... AI 에이전트 대리결제 사용자 본인확인 오남용 zero 도전

사람이 직접 결제하지 않는 거래의 주체를 구분

‍

AI 에이전트가 사용자를 대신해 결제하는 환경에서는 화면을 조작한 사람과 실제 거래를 요청한 사용자가 일치하지 않을 수 있다는 점을 고려해야 합니다. 기존 온라인 결제에서는 이용자가 직접 상품을 선택하고 결제 절차를 진행하는 경우가 많았지만, 에이전트 기반 환경에서는 사용자의 요청을 전달받은 시스템이 여러 단계를 대신 수행할 수 있습니다. 

이에 따라 결제 시스템은 단순히 로그인 계정이 존재하는지를 확인하는 것에서 나아가 실제 대리행위를 요청한 사용자가 누구인지 확인할 필요가 있습니다. 본인확인은 결제가 실행되는 순간에만 적용하기보다 에이전트에게 거래를 맡기는 과정과 실제 결제 과정 사이를 연결하는 방식으로 설계할 수 있습니다.

‍

대리행위를 요청한 사용자와 에이전트를 별도로 식별

AI 에이전트가 결제를 수행한다고 해서 에이전트 자체가 거래의 주체가 되는 것은 아닙니다. 사용자와 에이전트의 식별정보를 분리해 관리하는 구조가 필요합니다. 사용자의 계정이나 신원확인 정보와 에이전트의 식별정보를 연결해두면 이후 거래가 어떤 사용자에 의해 요청됐고 어떤 시스템을 통해 실행됐는지 확인할 수 있습니다. 특히 하나의 사용자가 여러 에이전트를 사용하거나 하나의 에이전트가 여러 서비스와 연결되는 환경에서는 이러한 구분이 더욱 중요해질 수 있습니다. 거래 기록에도 사용자 식별정보와 에이전트 식별정보를 함께 남겨야 문제가 발생했을 때 실제 실행 경로를 추적하기 수월합니다.

‍

최초 위임 시점에 사용자의 신원을 확인하는 방식

‍

AI 에이전트에 결제 관련 업무를 처음 맡길 때는 해당 요청을 보낸 사람이 실제 계정 이용자인지를 확인하는 절차를 둘 수 있습니다. 이 과정에서 eKYC나 기존에 등록된 본인확인 수단 등을 활용해 대리결제 기능을 설정한 사용자의 신원을 확인하고 위임 상태를 등록할 수 있습니다. 이후 모든 거래마다 동일한 절차를 반복하기보다 최초 위임 결과와 이후 거래를 연결하는 구조를 검토할 수 있습니다. 다만 위임 정보가 변경되거나 장기간 사용되지 않았던 계정에서 새로운 대리결제가 발생하는 경우처럼 별도의 확인이 필요한 조건은 따로 설정할 수 있습니다.

‍

대리결제 본인확인에 필요한 정보

사용자와 에이전트의 관계를 확인할 수 있는 항목

• 사용자 식별정보: 본인확인을 거쳐 확인된 계정 소유자 정보
• 에이전트 식별정보: 거래를 실행한 AI 에이전트 또는 연결 서비스 정보
• 위임 상태: 사용자가 대리결제를 허용했는지 여부
• 위임 범위: 에이전트가 대신 수행할 수 있는 거래의 조건
• 실행 기록: 실제 결제가 요청되고 처리된 시점
• 인증 이력: 본인확인 방식과 확인 결과
• 변경 내역: 위임 조건이나 연결 정보가 변경된 기록

‍

위임 정보가 바뀌면 기존 본인확인만으로 처리하지 않아야

‍

사용자가 AI 에이전트에 대리결제를 맡긴 뒤에도 위임 내용은 변경될 수 있습니다. 새로운 서비스를 연결하거나 거래 조건을 수정하고, 기존에 사용하던 에이전트를 다른 시스템으로 교체하는 상황도 발생할 수 있습니다. 이때 처음 위임할 당시 확인한 신원정보만으로 변경 요청까지 자동 승인하지 않도록 하는 기준을 마련할 필요가 있습니다. 특히 대리결제의 범위가 넓어지는 변경이라면 사용자가 직접 변경을 요청했는지 다시 확인하는 절차를 적용할 수 있습니다. 변경 전후의 위임 상태를 함께 기록하면 이후 어떤 조건에서 에이전트의 결제 권한이 달라졌는지도 확인할 수 있습니다.

‍

‍

반복적인 결제 절차를 줄이는 장점

AI 에이전트의 장점 중 하나는 사용자가 반복적인 결제 절차를 직접 수행하지 않아도 된다는 점입니다. 따라서 모든 거래에서 사용자에게 매번 별도의 본인확인을 요구하는 방식은 대리결제의 편의성을 떨어뜨릴 수 있습니다. 대신 사전에 확인된 위임관계와 거래 조건이 정상적으로 유지되는 동안에는 간소화된 절차를 적용하고, 기존 조건에서 벗어나는 경우 추가 확인을 요구하는 구조를 고려할 수 있습니다. 예를 들어 새로운 결제 환경이나 예상하지 못한 거래 조건이 나타났다면 해당 시점에서 사용자 확인을 요청할 수 있습니다. 본인확인 절차의 횟수보다 어떤 상황에서 다시 확인할 것인지가 시스템 설계에서 중요한 요소가 됩니다.

‍

대리결제 과정에서 발생하는 예외도 구분해야

‍

본인확인 과정에서 오류가 발생하거나 사용자의 인증이 정상적으로 완료되지 않았다고 해서 곧바로 부정한 대리결제로 판단해서는 안 됩니다. 인증 실패와 실제 사용자 불일치, 시스템 오류, 위임정보 오류는 서로 다른 상황일 수 있기 때문입니다. 예를 들어 얼굴인증이나 다른 인증수단의 기술적 오류로 확인이 중단된 경우에는 재시도나 다른 확인 방법을 제공할 수 있습니다. 반면 등록된 사용자 정보와 현재 확인된 정보가 일치하지 않는다면 별도의 검토가 필요할 수 있습니다. 이런 상태를 각각 구분해 기록해야 정상적인 이용자가 기술적인 문제 때문에 불필요하게 거래 제한을 받는 상황도 줄일 수 있습니다.

‍

거래가 끝난 뒤에도 대리결제 경로를 확인할 수 있어야

‍

AI 에이전트가 결제를 대신 수행하는 환경에서는 결제 승인 결과만 남기는 것보다 사용자 요청부터 에이전트의 실행, 본인확인, 실제 거래 처리까지 이어지는 과정을 연결해 기록하는 것이 중요합니다. 이를 통해 거래가 발생한 이후에도 누가 대리결제를 설정했는지, 어떤 에이전트가 실행했는지, 당시 본인확인이 어떤 상태였는지를 확인할 수 있습니다. 특히 사용자가 거래 사실을 확인하거나 결제 과정에 대한 이의가 제기된 경우 이러한 이력은 처리 과정에서 참고자료가 될 수 있습니다. 개인정보와 인증정보를 다루는 만큼 모든 기록을 동일하게 보관하기보다 목적과 접근권한에 따라 필요한 범위를 정해 관리하는 방식도 함께 검토할 필요가 있습니다.

‍

‍