한국어
에이전틱 앱을 위한 인증 및 아이덴티티의 변화된 점과 바뀌지 않은 점
인공지능 에이전트가 점점 더 능력 있고 연결됨에 따라, 안전하고 확장 가능한 에이전틱 제품을 구축하기 위해서는 인증 및 아이덴티티에 대한 강력한 기반이 필요합니다. 이 가이드는 변화된 점, 바뀌지 않은 점, 그리고 새로운 환경을 탐색하기 위해 모든 제작자가 알아야 할 사항을 설명합니다.
Guamian
Product & Design
Product & Design
인공지능 에이전트가 점점 더 능력 있고 연결됨에 따라, 안전하고 확장 가능한 에이전틱 제품을 구축하기 위해서는 인증 및 아이덴티티에 대한 강력한 기반이 필요합니다. 이 가이드는 변화된 점, 바뀌지 않은 점, 그리고 새로운 환경을 탐색하기 위해 모든 제작자가 알아야 할 사항을 설명합니다.
최근에 나는 이 기사를 검토했으며 에이전트 인증에 대한 언급이 있었습니다:
이것이 어떤 모습일 수 있는지에 대한 힌트를 보고 있습니다. 예를 들어 최신 MCP 사양에는 OAuth 2.1을 기반으로 한 인증 프레임워크가 포함되어 있어 AI 에이전트에게 원시 비밀 대신 범위가 지정된, 철회 가능한 토큰을 제공할 가능성을 신호합니다. AI 에이전트가 실제 AWS 키를 받는 대신, 단기간 유효한 자격증명이나 특정한 작업을 수행할 수 있는 기능 토큰을 얻는 시나리오를 상상할 수 있습니다.
https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/
이것이 새로운 것이라는 인상을 받는 보안 또는 CIAM 분야에 있지 않은 많은 친구들과 사람들이 있지만 분명히 그렇지는 않습니다. OAuth는 범위가 지정된 권한(액세스 토큰)을 가진 토큰을 포함하는 표준 기반의 권한 부여 프로토콜입니다. 이러한 토큰은 시간-제한적이고, 범위-제한적이며, 이는 자원 및 서비스에 대한 보안과 적절한 접근 제어를 보장합니다. 글로벌 SaaS 시장(예전 AI)에서는 대부분의 전문적인 아이덴티티 솔루션이 이미 이것에 기반을 두고 있습니다.
당신이 Google 계정을 Notion이나 Zoom 같은 서드파티 앱에 연결할 때, 이는 Google 비밀번호를 노출하지 않고도 캘린더나 연락처에 대한 접근 권한만 요청하기 위해 OAuth를 사용합니다. 이 권한은 언제든지 Google 계정 설정에서 철회할 수 있습니다. 이런 위임된 접근 패턴이 바로 OAuth를 설계한 이유이며, 이는 오늘날 에이전틱 애플리케이션에 확장되는 동일한 기반입니다.
두 가지 주요 프로토콜이 등장하고 있습니다: MCP와 A2A.
그러나 인증 및 권한 부여의 경우에는 둘 다 여전히 OAuth와 같은 확립된 산업 표준에 의존합니다.
MCP 인증 서버는 반드시 OAuth 2.1을 구현해야 하며, 기밀 및 공공 클라이언트를 위한 적절한 보안 조치를 포함해야 합니다.
A2A 클라이언트는 A2A 프로토콜 자체 외부의 프로세스를 통해 필요한 자격증명 자료(e.g., OAuth 2.0 토큰, API 키, JWT)를 획득할 책임이 있습니다. 이는 OAuth 플로우(인증 코드, 클라이언트 자격증명), 안전한 키 배포 등을 포함할 수 있습니다.
Google에 따르면:
A2A는 보안 및 운영을 위한 새로운, 독점적 기준을 발명하는 대신 기존 엔터프라이즈 인프라와 널리 채택된 모범 사례와 원활하게 통합하는 것을 목표로 합니다.
많은 과대 광고와 FOMO 콘텐츠가 에이전트가 더 보편화됨에 따라 에이전트 아이덴티티를 관리하는 시스템이 필요하다는 아이디어를 밀어붙이고 있습니다.
그 답은: 예와 아니요.
예, 왜냐하면 인간과 기계 사이에 새로운 레이어를 도입하고 있기 때문입니다. 다음과 같은 실제 요구가 있습니다:
그러나 대부분의 기술적 경우에는 '에이전트 아이덴티티'라는 공식적인 개념을 만들 필요가 없습니다.
에이전트 ≠ 사용자, ≠ 서비스 계정.
모든 에이전트 뒤에는 여전히 사용자가 존재하며, 보통 사용자 아이덴티티가 충분합니다.
오늘날 대부분의 에이전트는:
그런 의미에서 에이전트는 단지 도구로서의 기능일 뿐이며 전 세계적으로 고유한 ID가 필요하지 않습니다.
예를 들어:
AI 이전에도 머신-투-머신 (M2M) 인증이란 개념이 있었습니다.
M2M은 서비스 간의 자동화된 데이터 교환을 의미하며, 사람은 개입하지 않습니다.
이 맥락에서 인증은 종종 클라이언트 앱이나 서비스 계정을 사용합니다.
만약 정말로 에이전트에게 아이덴티티가 필요하다면(감사를 위해 등), 앱 ID를 사용하면 충분합니다.
이것은 바뀌지 않았습니다. 제품이 에이전트를 포함하든 하지 않든, 아이덴티티 시스템의 아키텍처는 사용자가 누구인지와 시스템이 사용자와 어떻게 상호작용하는가에 달려 있습니다.
소비자를 대상으로 하는 에이전틱 제품을 구축하는 경우: 경량화된 로그인 방법(이메일, 전화, 소셜 로그인)과 에이전트와 상호작용하는 개인을 관리하기 위한 통합 사용자 풀을 필요로 합니다. 에이전트는 위임된 토큰(e.g., via OAuth)을 사용하여 이 사용자들을 대신하여 행동합니다.
예:
AI 스케줄링 비서 또는 AI 주도의 캘린더 봇을 구축하고 있다고 상상해 보세요.
각 사용자는 개인 Google 계정으로 로그인합니다. 시스템은 OAuth를 사용하여 캘린더에 액세스할 권한을 얻습니다. 에이전트는 자체 아이덴티티를 가지지 않고, 사용자의 토큰을 사용하여 회의를 일정에 추가하고, 사용 가능 여부를 확인하고, 알림을 보냅니다. 아이덴티티 아키텍처는 간단합니다: 하나의 글로벌 사용자 풀, 토큰 저장소, 사용자 당 동의 추적.
기업-간(B2B) 에이전틱 플랫폼을 구축하는 경우:
개별 사용자뿐만 아니라 조직 수준에서도 아이덴티티를 지원해야 합니다. 이는 다음을 포함합니다:
예:
내부 워크플로우를 자동화하는 AI 에이전트를 제공하는 플랫폼을 구축하고 있다고 상상해 보세요 — 로그를 모니터링하고 경고를 보내는 보안 분석가 봇이나 CRM 데이터에서 이메일을 작성하는 영업 보조원이 될 수 있습니다.
당신의 플랫폼을 사용하는 각 회사는:
이 경우, 당신의 아이덴티티 아키텍처는 다중 테넌트 디자인, 범위가 지정된 에이전트 권한, 조직별 정책을 지원해야 합니다. 에이전트는 여전히 사용자 대신 작동하지만, 권한과 아이덴티티 경계는 비즈니스 테넌트 별로 강제됩니다.
두 경우 모두, 아이덴티티 모델은 에이전트가 어떻게 작동하고 무엇에 접근할 수 있으며, 당신의 시스템이 책임성을 어떻게 보장하는지를 정의합니다.
이 가이드를 사용하여 아이덴티티 및 제품 아키텍처를 계획하는 데 도움을 받으세요.
https://docs.logto.io/introduction/plan-your-architecture/b2c
https://docs.logto.io/introduction/plan-your-architecture/b2b
에이전트 앱인지 여부에 상관없이, 이러한 기본 보안 계층은 사용자와 시스템 보호를 위해 필요합니다:
자격 증명이 손상되더라도 무단 액세스를 방지합니다.
예: 에이전트가 거래나 아이덴티티 설정 변경과 같은 고위험 작업을 수행할 때는, 사람을 루프에 유지하고 MFA를 사용하여 작업을 진행하기 전에 동작을 확인해야 합니다.
자격 증명 재충전이나 봇 주도의 회원가입과 같은 자동화된 남용을 차단합니다.
예: 크로로시키 시도를 방지하고, 로그인 시도가 3번 실패한 후 CAPTCHA를 표시합니다.
사용자와 에이전트가 허용된 것만 접근하도록 보장합니다.
예: 회사 워크스페이스에서 AI 어시스턴트는 캘린더 이벤트를 읽을 수 있지만, 명시적으로 더 높은 역할이 할당되지 않은 한 청구 데이터에 접근할 수 없습니다.
UX를 개선하고 약한 비밀번호의 위험을 줄입니다.
예: 사용자가 이메일로 전송된 매직 링크 또는 얼굴인증 같은 생체 정보를 사용하여 로그인이 가능하도록 합니다.
이 기능은 특히 민감한 데이터 및 시스템 간에 에이전트가 운영을 시작할 때 전통적인 앱과 에이전트 기반 앱 모두에 적용됩니다.
에이전트 및 다중 에이전트 워크플로우가 등장함에 따라, 사용자, 에이전트, API, 및 MCP 서버가 모두 상호작용하는 새로운 사용 사례가 등장하고 있습니다. 이러한 시나리오의 수와 다양성은 과거보다 훨씬 빠르게 증가하고 있습니다.
이러한 연결이 이루어질 때마다, 권한 부여가 그 어느 때보다 가시적으로 됩니다. 사용자는 명확한 동의를 주어야 하고, 시스템 전반에서 권한이 신중하게 관리될 필요가 있습니다. 이것이 바로 모두가 이제 **“사람을 루프에 포함시킨다”**에 대해 이야기하는 이유입니다. 사용자에게 에이전트가 할 수 있는 작업과 승인된 범위에 대한 충분한 통제와 가시성을 제공하는 것이 보장됩니다.
MCP 생태계가 확장됨에 따라, 당신의 앱은 더 이상 독립형 서비스일 뿐만 아니라, 더 큰 연결망의 일부분입니다.
LLM에 풍부하고 유용한 문맥을 제공하기 위해, 당신의 에이전트는 필요할 수 있습니다:
다수의 MCP 서버에 접근
예: Jira에서 작업 업데이트를 가져오고, Google 캘린더에서 팀 가용성을 확인하고, Salesforce에서 영업 데이터를 가져오는 AI 프로젝트 관리자를 상상해보세요. 이 각각은 다른 MCP 서버에 의해 작동될 수 있습니다. 주간 요약을 하나 생성하려면, 에이전트는 여러 데이터 소스와 안전하게 상호작용해야 합니다. 이것이 인증 및 권한 부여가 중요한 이유이며, 모든 연결을 보호하고 데이터 공유를 제어하기 위함입니다.
외부 API 및 도구와 연결
예: 고객 지원 에이전트가 Shopify에서 주문 이력을 가져오고, Zendesk에서 티켓을 업데이트하며, Slack에서 워크플로우를 트리거해야 할 수 있습니다. 통합 없이는 에이전트가 고립되고 비효율적이 됩니다.
에이전트가 더 많은 책임을 맡게 됨에 따라 통합은 유용성의 핵심이 됩니다. 당신의 AI 제품은 그 자체로 할 수 있는 것뿐만 아니라, 연결된 생태계 내에서 무엇을 접근하고 조율하며 추론할 수 있는지가 중요합니다. 그렇기 때문에 상호운용성을 구축하는 것이 안전하고 유연하게 어느 때보다 중요합니다.
AI 시대에서는 보안적이고 유연한 통합의 필요성이 커지고 있습니다. 그로 인해 OAuth 2.0과 OIDC가 그 어느 때보다 중요해졌습니다.
주요 사용 사례는 다음을 포함합니다:
이러한 프로토콜은 안전하고, 토큰 기반이며, 사용자 동의에 기반한 접근을 제공합니다.
이는 에이전틱, 연결된 시스템의 세계에서 매우 중요합니다. 이 기사를 확인하여 OAuth와 OIDC가 왜 중요한지 알아보세요.
에이전틱 제품이 발전함에 따라, 아이덴티티 및 권한 부여의 핵심 원칙은 동일하지만, 컨텍스트가 변화하고 있습니다. 에이전트는 위임, 동의, 접근을 위한 새로운 표면을 도입합니다. 그래서 OAuth 같은 개방형 표준을 준수하고, 명확한 아키텍처를 구축하며, 견고한 보안 관행을 시행하는 것이 단순한 모범 사례를 넘어서, 기초입니다. 현재 주의를 기울여 설계하면, AI 구동의 미래에서 시스템이 자신감, 유연성, 신뢰와 함께 확장될 수 있습니다.