지난주 저는 우리 AI 에이전트가 작업 도중 세션을 계속 잃어버리는 문제를 디버깅하고 있었습니다. 그때 문득 생각이 들었습니다. 우리는 기본적으로 15년 전 엔터프라이즈 IT 팀들이 SSO (Single Sign-On) 및 IAM (Identity and Access Management)을 통해 해결했던 것과 동일한 문제를 풀고 있다는 사실 말입니다. 유일한 차이점은 이번에 로그인하는 "사용자"가 인간이 아니라, 스스로 결정을 내리는 소프트웨어 조각이라는 점입니다.

현재 AI 에이전트를 구축하는 대부분의 팀은 인증 (auth)을 사후 고려 사항으로 취급하고 있습니다. 어딘가에 하드코딩된 API 키, 10개의 에이전트가 공유하는 하나의 서비스 계정, 어떤 에이전트가 어떤 작업을 수행했는지 아무도 모르는 상황 말입니다. 저는 이런 패턴을 이미 여러 번 목격했으며, 솔직히 말해서 이는 재앙이 일어나기만을 기다리는 상황과 같습니다.

그렇다면 엔터프라이즈 ID 관리에서 이미 파악한 내용이 무엇인지, 그리고 우리가 그것을 어떻게 빌려올 수 있는지 이야기해 봅시다.

1. 인간이든 아니든, 모든 ID는 고유한 자격 증명이 필요하다

엔터프라이즈 환경에서는 두 명의 직원이 하나의 로그인을 공유하도록 두지 않습니다. 그렇게 되면 감사 추적 (audit trail)은 무용지물이 되고, 책임 소재 (accountability)는 사실상 사라지기 때문입니다. 동일한 논리가 에이전트에도 적용됩니다. 만약 에이전트 A와 에이전트 B가 하나의 API 키를 공유하고 있는데 문제가 발생한다면, 어떤 에이전트가 피해를 입혔는지 어떻게 추적할 수 있겠습니까? 각 에이전트는 반드시 자신만의 머신 ID (machine identity)를 가져야 합니다.

2. 정적 키보다는 수명이 짧은 토큰을 사용하라

이것은 새로운 내용이 아닙니다. OAuth2와 SAML은 오래전에 우리에게 이 점을 가르쳐 주었습니다. 환경 설정 파일에 몇 달 동안 머물러 있는 정적 API 키는 시한폭탄과 같습니다. 에이전트는 수명이 짧은 토큰 (short-lived tokens)을 요청하고 이를 갱신해야 하며, 에이전트의 작업이 완료되는 즉시 해당 토큰은 만료되어야 합니다. Okta나 Azure AD와 같은 엔터프라이즈 IAM 도구들은 인간을 위해 이 작업을 자동으로 수행합니다. 우리는 에이전트를 위한 그에 상응하는 체계가 필요합니다.

3. 최소 권한 원칙은 타협할 수 없는 원칙이다

"나중에 필요할지도 모르니까"라는 생각으로 에이전트에게 광범위한 권한을 부여하고 싶은 유혹이 있다는 것을 압니다. 하지만 이것은 바로 RBAC (Role-Based Access Control)가 표준 관행이 되기 전, 초기 엔터프라이즈들이 저질렀던 실수와 정확히 일치합니다. 캘린더를 읽기만 하면 되는 에이전트가 전체 이메일 계정에 대한 쓰기 권한을 가져서는 안 됩니다. 항상 범위를 축소하십시오.

4. 위임된 권한(Delegated authority)은 명시적이어야 합니다

사실 이 부분이 흥미로운 지점입니다. 에이전트가 사용자를 "대신하여(on behalf of)" 행동할 때, 엔터프라이즈 ID(Enterprise Identity) 관리에는 이미 이에 대한 패턴이 존재합니다. OAuth의 위임 모델(Delegation model)이나, 심지어 더 오래된 Kerberos 제약 위임(Kerberos constrained delegation) 같은 것들 말이죠. 에이전트는 단순히 자신의 정체성(Identity)뿐만 아니라, 자신이 누구를 대신하여 행동하고 있는지에 대한 증거를 지니고 있어야 합니다. 그렇지 않으면 다음과 같은 기본적인 질문에조차 답할 수 없게 됩니다: 이 작업이 사용자에 의해 승인된 것인가, 아니면 에이전트가 독단적으로 행동한 것인가?

5. 일회성 로그인이 아닌 지속적인 검증(Continuous verification)

기업들은 "한 번 로그인하면 영원히 신뢰하는" 방식에서 제로 트러스트(Zero Trust)로 전환했습니다. 맥락(Context)에 기반하여 매번, 모든 요청을 검증하십시오. 에이전트는 행동 방식에 있어 인간보다 훨씬 더 예측 불가능하기 때문에, 이 원칙은 두 배로 적용됩니다. 세션 시작 시 에이전트를 한 번 인증하고 잊어버리지 마십시오. 계속해서 확인해야 합니다.

솔직히 말해서, 이 중 어느 것도 그리 새로운 생각은 아닙니다. ID 및 액세스 관리(IAM, Identity and Access Management) 전문가들은 이미 이 전투를 치러왔고, 실수를 저질렀으며, 이를 위한 표준을 만들어 두었습니다. 우리는 단지 시스템 내의 새로운 유형의 행위자에게 동일한 원칙을 적용하고 있을 뿐입니다.

제가 주목하고 있는 점은, 많은 AI 인프라 팀들이 이미 IAM 세계에 존재하는 것들을 단순히 조정하기만 하면 될 일을, 처음부터 다시 인증(Auth) 체계를 만들고 있다는 것입니다. 물론 에이전트가 버튼을 클릭하는 인간에 비해 더 빠르고, 더 자율적이며, 때로는 예측 불가능하게 행동할 수 있다는 점을 고려한 몇 가지 수정은 필요하겠지만 말입니다. AI 에이전트 버전의 자격 증명 유출(Credential leak)이 다음번 큰 뉴스 헤드라인을 장식하기 전에, 이에 대해 고민해 볼 가치가 있습니다.