.svg)
AI 솔루션 문의하기
기계 간 인증(M2M, Machine to Machine)은 사람이 개입하지 않는 상태에서 서버, 서비스, 프로그램이 서로가 믿을 수 있는 상대인지 확인하는 방식입니다. AI 에이전트가 사내 시스템이나 외부 API에 접근할 때도 대부분 이 방식으로 인증을 받습니다. 문제는 기계 간 인증이 증명하는 대상이 요청을 보낸 기계뿐이라는 점입니다. 에이전트가 결제를 요청했을 때, 기계 간 인증은 그 요청이 등록된 에이전트에서 왔다는 것은 확인해 주지만, 에이전트에게 결제를 지시한 사람이 권한을 가진 본인인지는 알려 주지 않습니다. 에이전트가 많아질수록 기계 간 요청은 폭발적으로 늘어나고, 그 안에서 사람의 지시로 시작된 요청과 자동으로 반복되는 요청을 구분하기는 점점 어려워집니다.
기계 신뢰는 이 요청이 우리가 등록한 프로그램에서 왔는가를 묻습니다. 사람 신뢰는 이 일을 시킨 사람이 실제로 그 권한을 가진 본인인가를 묻습니다. 예전에는 프로그램이 정해진 일만 반복했기 때문에 기계 신뢰만으로 충분했습니다. AI 에이전트는 사람의 지시에 따라 매번 다른 일을 하므로, 기계 신뢰만으로는 누가 그 일을 시켰는지 알 수 없습니다. 탈취된 사용자 계정으로 에이전트에게 지시하면 기계 간 인증은 모두 정상으로 통과합니다. 상황에 따라 추가 인증을 요구하는 방식은 컨텍스트 기반 AI 인증 시스템 글에서 다뤘고, 이 글은 기계 신뢰와 사람 신뢰를 함께 설계하는 방법에 집중합니다.
AI 에이전트 환경에서 많이 쓰는 기계 간 인증 방식은 세 가지입니다.
서비스가 발급한 고정된 문자열을 요청에 함께 보내는 방식입니다. 구현이 가장 간단해 널리 쓰이지만, 한 번 발급하면 오래 유지되는 경우가 많아 코드나 설정 파일, 로그에 남았다가 유출되기 쉽습니다. 유출되면 누구나 그 키로 요청을 보낼 수 있고, 키만으로는 실제 요청자를 구분하기 어렵습니다. 그래서 API 키는 위험이 낮은 조회용으로 범위를 좁히고, 사용할 수 있는 서버나 네트워크를 제한해 두는 것이 일반적인 보완 방법입니다.
에이전트가 클라이언트 ID와 비밀값으로 인증 서버에서 짧게 만료되는 접근 토큰을 받아 쓰는 방식입니다. 토큰마다 허용 범위를 정할 수 있고 만료 시간이 짧아 API 키보다 안전합니다. 다만 이 방식은 사용자 없이 프로그램 자체의 권한으로 동작하도록 만들어진 흐름이라, 토큰 안에 어느 사람의 지시인지는 담기지 않습니다.
요청을 보내는 쪽과 받는 쪽이 서로 인증서를 확인한 뒤에 통신하는 방식입니다. 인증서가 없는 기계는 아예 연결할 수 없어 기계 신뢰 수준이 가장 높습니다. 대신 인증서 발급과 교체, 만료 관리에 운영 부담이 따르고, 마찬가지로 지시한 사람에 대한 정보는 담지 않습니다.
세 방식은 기계를 얼마나 강하게 확인하느냐에서 차이가 날 뿐, 지시한 사람을 확인하지 못한다는 한계는 같습니다. 그래서 위험이 큰 작업에는 기계 간 인증 위에 사람 확인을 한 층 더 올려야 합니다.
기계 간 인증 위에 사람 확인을 더하려면 본인 확인 서비스와 연동하는 구간도 같은 수준의 기계 간 보안을 갖춰야 합니다. 알체라 eKYC는 API 인증에 OAuth 2.0을, 통신에 TLS 1.3을 적용하고 있으며, 촬영된 얼굴의 위변조 여부를 판별한 뒤 신분증 사진과 매칭하여 지시한 사람이 실제 본인인지 확인합니다.
사람 확인을 모든 요청에 붙이면 자동화의 의미가 사라집니다. 기계 신뢰만으로 처리할 구간과 사람 신뢰가 필요한 구간을 나눠, 다음 세 위치에 붙이는 것이 일반적입니다.
일반적인 조회나 정해진 범위 안의 반복 작업은 기계 간 인증만으로 처리하고, 위 세 위치에서만 사람을 확인하면 운영 부담을 크게 늘리지 않고도 빈틈을 줄일 수 있습니다. 예를 들어 거래처 대금을 정산하는 에이전트라면 매일 거래 내역을 조회하고 정산표를 만드는 일은 기계 간 인증만으로 처리하고, 실제로 대금을 보내는 호출이나 새 거래처 계좌를 등록하는 호출에서만 담당자의 얼굴을 확인하는 식입니다.
사람 확인을 붙였다면, 그 결과가 기계 쪽 기록과 연결되어야 의미가 있습니다. 요청 기록에 에이전트 ID만 남으면 나중에 누가 시킨 일인지 다시 찾아야 합니다.
이렇게 연결해 두면 사고가 났을 때 어떤 에이전트가 누구의 지시로 무엇을 했는지 한 번에 확인할 수 있습니다.
사람 확인을 마쳤다는 사실도 기계 사이에서 전달되어야 합니다. 이때 단순히 확인 완료라는 표시만 넘기면 중간에서 위조될 수 있습니다. 본인 확인을 통과하면 해당 요청 한 건의 내용과 묶인 승인 정보를 짧은 유효 시간과 함께 발급하고, API를 받는 쪽에서는 그 승인 정보가 지금 들어온 요청의 내용과 일치하는지 확인한 뒤에 실행합니다. 이렇게 하면 한 번 받은 승인을 다른 요청에 다시 쓰거나, 승인받은 뒤 금액이나 대상을 바꾸는 일을 막을 수 있습니다. 승인 정보를 발급하고 검증하는 구간 역시 기계 간 통신이므로, 앞에서 다룬 OAuth 2.0이나 mTLS로 보호해 기계 신뢰와 사람 신뢰가 서로를 받쳐 주는 구조를 만듭니다.
기계 자격 증명은 사람 계정보다 눈에 덜 띄어 관리에서 빠지기 쉽습니다.
기계 자격 증명의 목록은 사람 계정 목록과 별도로 관리하되, 각 자격 증명에 책임자 한 명을 반드시 연결해 둡니다. 책임자가 없는 자격 증명은 정기 점검에서 우선 정리 대상으로 분류하면 관리 범위 밖에 남는 기계를 줄일 수 있습니다.
.png)
.svg)
.svg)
