AI 에이전트 관리, 에이전트 뒤의 사람을 생체 인증으로 확인하는 시점

트렌드
2026-10-27

AI 에이전트 관리에서 사람 확인은 언제 필요한가요?

AI 에이전트 관리는 에이전트를 만들고, 권한을 주고, 운영하다가, 필요가 없어지면 정리하기까지의 전 과정을 다루는 일입니다. 이 과정에서 에이전트 뒤에 있는 사람을 확인하는 일은 매번 필요한 것이 아니라, 에이전트의 책임자가 정해지거나 바뀌는 시점에 집중적으로 필요합니다. 대표적인 시점은 에이전트를 처음 만들 때, 권한을 주거나 넓힐 때, 소유자가 바뀔 때, 그리고 담당자가 퇴사해 에이전트를 정리할 때입니다. 이 네 시점에 사람 확인이 빠지면 에이전트는 계속 움직이는데 그 행동을 책임질 사람은 확인되지 않은 상태가 됩니다.

반대로 에이전트가 요청을 보낼 때마다 사람을 확인하면 자동화의 이점이 사라집니다. 그래서 일상적인 작업은 에이전트에 맡기고, 책임자를 정하거나 바꾸는 순간에만 사람을 확실하게 확인하는 방식이 운영 부담과 보안 사이의 균형을 맞추는 방법입니다.

‍

에이전트는 늘어나는데 담당자는 바뀝니다

에이전트는 만드는 데 드는 비용이 낮아 부서마다, 업무마다 빠르게 늘어납니다. 반면 에이전트를 만든 사람은 부서를 옮기거나 회사를 떠납니다. 만든 사람이 떠난 뒤에도 계속 작동하는 에이전트, 누가 소유자인지 기록이 남지 않은 에이전트는 관리 범위 밖에서 권한을 쓰게 됩니다. 사람 확인 시점을 정해 두는 것은 이렇게 주인이 불분명한 에이전트가 생기지 않도록 하는 장치입니다. 권한 범위를 정하고 최소 권한을 적용하는 방법은 AI 에이전트 권한 관리 글에서 다뤘고, 이 글은 사람을 확인해야 하는 시점에 집중합니다.

‍

사람 확인 방식은 어떻게 다른가요?

에이전트 뒤의 사람을 확인하는 생체 인증 방식은 크게 두 가지입니다. 두 방식은 확인해 주는 내용이 달라서, 시점에 따라 나눠 쓰는 것이 효율적입니다.

  • 기기 내 생체 인증: 스마트폰이나 노트북의 지문, 얼굴 잠금 해제를 이용하는 방식입니다. 등록된 기기를 가진 사람이 기기에 등록한 생체 정보와 일치한다는 것을 빠르게 확인합니다. 다만 그 사람이 실제로 누구인지, 처음 기기에 생체 정보를 등록한 사람이 본인이었는지는 알려 주지 않습니다. 생체 정보가 기기 안에서만 처리되는 경우가 많아 서비스 쪽에서 별도로 생체 정보를 다루지 않아도 된다는 장점이 있습니다.
  • 얼굴 매칭과 라이브니스: 신분증 사진과 지금 촬영한 얼굴을 비교하고, 카메라 앞의 얼굴이 사진이나 화면이 아닌 실제 사람인지 확인하는 방식입니다. 기기와 관계없이 그 사람이 신분증의 주인이라는 것을 확인할 수 있습니다.

‍

시점에 따라 방식을 나눕니다

책임자를 새로 정하는 시점, 즉 에이전트 생성과 소유자 변경에는 실제 신원을 확인하는 얼굴 매칭과 라이브니스를 씁니다. 이미 신원이 확인된 사람이 같은 기기에서 반복적으로 하는 확인, 예를 들어 관리 화면 로그인에는 기기 내 생체 인증으로 충분한 경우가 많습니다. 권한을 넓히는 시점은 넓히려는 권한의 위험도에 따라 둘 중 하나를 고릅니다.

기기 내 생체 인증만으로 부족한 경우도 분명히 있습니다. 여러 사람이 함께 쓰는 공용 기기라면 누구의 생체 정보가 등록되어 있는지 알기 어렵고, 기기를 분실하거나 새 기기로 바꾸면 기존 확인 기록과의 연결이 끊어집니다. 이런 경우에는 기기와 관계없이 신분증과 얼굴로 다시 확인하는 절차를 거치는 것이 안전합니다.

‍

알체라 eKYC로 책임자의 신원을 확인하면

에이전트를 만들거나 소유자가 바뀌는 시점처럼 책임자를 새로 정하는 순간에는 기기를 가진 사람이 아니라 실제 신원을 확인하는 방식이 필요합니다. 알체라 eKYC는 신분증 OCR로 정보를 인식하고 사본판별을 거친 뒤, 촬영된 얼굴의 위변조 여부를 판별하고 신분증 사진과 매칭하여 본인 여부를 확인합니다.

에이전트를 만들 때는 무엇을 확인하나요?

에이전트를 만드는 순간 그 에이전트의 소유자가 정해집니다. 이때 확인한 사람이 이후 에이전트가 하는 모든 일의 책임자가 되므로, 계정 로그인만으로 넘어가지 않고 얼굴 매칭과 라이브니스로 본인을 확인합니다.

  • 소유자 신원: 에이전트를 만드는 사람이 계정의 실제 주인인지 확인합니다.
  • 생성 목적: 에이전트가 어떤 업무를 위해 만들어졌는지 함께 기록합니다.
  • 연결 정보: 소유자의 확인 결과와 에이전트 ID를 하나의 기록으로 묶습니다.
  • 사용 기간: 특정 프로젝트처럼 한시적으로 쓰는 에이전트라면 사용 종료 예정일을 함께 정합니다.

‍

생성 목적을 남겨 두면 나중에 에이전트가 목적과 다른 일을 할 때 바로 알아챌 수 있고, 정리할 때도 이 에이전트가 아직 필요한지 판단하는 기준이 됩니다. 본인 확인이 끝나기 전에는 에이전트가 실제 작업을 시작하지 못하도록 생성 절차를 설계해 두면, 확인을 건너뛴 에이전트가 운영에 들어가는 일을 막을 수 있습니다.

권한을 주거나 넓힐 때는 언제 다시 확인하나요?

처음 만든 에이전트는 좁은 권한으로 시작하는 것이 일반적입니다. 문제는 운영하면서 권한이 조금씩 넓어지는 과정입니다. 권한을 넓히는 요청이 실제 소유자에게서 왔는지 확인하지 않으면, 탈취된 계정 하나로 에이전트의 권한을 크게 늘릴 수 있습니다.

  • 조회 권한 추가처럼 위험이 낮은 확대는 기기 내 생체 인증으로 소유자를 확인합니다.
  • 결제, 외부 전송, 다른 시스템 접근처럼 위험이 큰 권한 추가는 얼굴 매칭과 라이브니스로 다시 확인합니다.
  • 권한을 넓힌 시각, 넓힌 범위, 확인 방식과 결과를 기록합니다.

권한을 넓힌 뒤에는 일정 기간이 지나면 다시 좁히거나 재확인을 받도록 만료일을 함께 정해 두는 것이 좋습니다. 예를 들어 고객 문의에 답하던 에이전트에 환불 처리 권한을 추가한다면, 돈이 움직이는 권한이므로 얼굴 매칭으로 소유자를 다시 확인하고 시범 운영 기간을 만료일로 정한 뒤 기간이 끝나면 운영 결과를 보고 연장 여부를 판단합니다.

‍

소유자가 바뀌면 어떻게 확인하나요?

담당자가 다른 부서로 옮기거나 업무가 다른 팀으로 넘어가면 에이전트의 소유자도 바뀌어야 합니다. 이 과정이 계정 이름만 바꾸는 식으로 처리되면 새 소유자가 실제로 그 업무를 맡은 사람인지 확인되지 않습니다.

  • 기존 소유자가 이전을 요청하고, 새 소유자가 얼굴 매칭과 라이브니스로 본인을 확인합니다.
  • 새 소유자의 업무에 맞게 권한을 다시 검토하고, 필요 없는 권한은 이전 시점에 정리합니다.
  • 기존 소유자에게 남아 있던 접근 권한과 토큰을 해제합니다.
  • 이전 기록에는 기존 소유자, 새 소유자, 이전 사유와 날짜, 각자의 확인 결과를 함께 남깁니다.

‍

기존 소유자와 새 소유자를 모두 확인하는 이유는, 한쪽만 확인하면 누군가 소유자 변경을 이용해 에이전트를 가로챌 수 있기 때문입니다. 팀 전체가 함께 쓰는 에이전트라도 소유자는 개인 한 명으로 지정해야 합니다. 소유자가 팀으로만 되어 있으면 문제가 생겼을 때 누가 확인하고 조치할지 정해지지 않기 때문입니다.

퇴사자의 에이전트는 어떻게 정리하나요?

가장 놓치기 쉬운 시점이 퇴사입니다. 계정은 퇴사일에 닫혀도 그 사람이 만든 에이전트는 별도 토큰으로 계속 작동하는 경우가 있습니다.

  • 퇴사 절차에 해당 직원이 소유한 에이전트 목록 확인을 넣습니다.
  • 계속 필요한 에이전트는 새 소유자에게 넘기고, 새 소유자는 본인 확인을 거칩니다.
  • 필요 없는 에이전트는 중지한 뒤 토큰과 권한을 모두 회수하고, 정리 기록을 남깁니다.

정기적으로 소유자가 없거나 오래 쓰이지 않은 에이전트를 찾아 같은 방식으로 정리하면 관리 범위 밖의 에이전트를 줄일 수 있습니다. 인사 시스템의 퇴사 처리와 에이전트 관리 목록을 연결해 두면, 퇴사가 확정되는 시점에 정리 대상 에이전트가 자동으로 표시되어 담당자가 놓치지 않고 처리할 수 있습니다.

‍

정리: AI 에이전트 관리, 시점별 사람 확인 점검 목록

  1. 에이전트를 만들 때 소유자를 얼굴 매칭과 라이브니스로 확인하고 생성 목적을 기록하는가
  2. 권한을 넓힐 때 위험도에 따라 확인 방식을 나누고 만료일을 정하는가
  3. 소유자가 바뀔 때 기존 소유자와 새 소유자를 모두 확인하는가
  4. 퇴사 절차에 소유 에이전트 정리가 들어 있는가
  5. 소유자가 없거나 오래 쓰이지 않은 에이전트를 정기적으로 찾아 정리하는가
  6. 시점마다 확인 방식과 결과를 에이전트 ID와 함께 기록하는가

‍

‍