조용히 무언가를 만들어 왔습니다. 이제 이야기할 때가 되었군요.

지난 몇 달 동안, 저는 머릿속을 떠나지 않는 무언가를 만드는 데 몰두해 왔습니다.

그것이 화려해서도 아니었고, 거대한 출시 마감일이 있어서도 아니었습니다. 하지만 AI 에이전트 (AI agents)가 인증 (authentication)과 권한 (permissions)을 처리하는 방식을 볼 때마다, 무언가 근본적으로 잘못되었다는 느낌을 지울 수 없었기 때문입니다.

그래서 저는 만들기 시작했습니다.

아무도 충분히 크게 이야기하지 않았던 문제

현재 AI 에이전트 (AI agents)는 어디에나 있습니다. 팀들은 이를 구축하고, 실험하고, 배포하고 있습니다. 생태계는 대부분의 사람들이 따라잡을 수 있는 속도보다 더 빠르게 움직이고 있습니다.

하지만 제가 계속해서 주목한 점이 있습니다. 에이전트 (agents)를 위한 인증 (authentication), 인가 (authorization), 그리고 권한 관리 (permission management)에 있어서 그 경험이 엉망이었다는 것입니다.

도구가 존재하지 않아서가 아니었습니다. 도구들이 서로 맞지 않았기 때문입니다. 한 곳에서 에이전트 (agent)를 작성하고, 다른 곳에서 권한을 설정한 다음, 또 다른 완전히 별개의 인터페이스에서 실제로 무엇이 실행되고 있는지 이해하려고 노력해야 했습니다.

마치 세 가지 다른 언어로 쓰인 설명서를 가지고 가구를 조립하는 기분이었습니다.

그리고 개발자들이 실제로 일하는 방식을 존중하면서 이 문제를 구체적으로 해결하려는 사람은 아무도 없는 것 같았습니다.

제가 계속해서 되새겼던 믿음

코드 한 줄을 쓰기 전부터, 저는 계속해서 되돌아오는 하나의 믿음이 있었습니다.

코드가 진실의 원천 (source of truth)이어야 합니다.

개발자들은 프로그래밍 방식으로 에이전트 (agents)를 구축합니다. 그들은 코드로 생각합니다. 이러한 에이전트 (agents)를 둘러싼 인증 (authentication) 계층은 개발자가 문맥 전환 (context-switch)을 해야 하는 별개의 세계가 아니라, 그 연장선상에서 자연스럽게 느껴져야 합니다.

도구는 코드 안에 존재해야 합니다. 에이전트 (Agents)는 코드 안에 존재해야 합니다. 제어 평면 (control plane)은 당신이 구축한 것을 보고 관리할 수 있도록 도와야지, 실제로 구축을 수행하는 장소가 되어서는 안 됩니다.

단순하게 들릴 수도 있습니다. 하지만 제가 살펴본 거의 모든 것은 어떤 방식으로든 이 원칙을 위반하고 있었습니다.

제가 만들고 있는 것

현재는 AgentAuthLayer라고 부르고 있지만, 솔직히 말씀드리면 아직 이름에 대해 고민 중입니다.

그 핵심은 AI 에이전트 (AI agents)를 위해 특별히 구축된 인증 (authentication) 및 인가 (authorization) 레이어입니다.

아이디어는 간단합니다. 에이전트를 구축할 때, 이를 제어하는 권한 (permissions), 신원 (identities), 그리고 액세스 제어 (access controls)는 동일한 워크플로 (workflow)와 동일한 멘탈 모델 (mental model) 내에서 에이전트와 나란히 정의되어야 합니다. 팀이 무엇이 실행되고 있는지 확인하거나, 감사 (audit)하거나, 관리해야 할 때, 코드에 존재하는 그대로를 반영하는 제어 평면 (control plane)이 있어야 합니다. 그 이상도, 그 이하도 아닙니다.

예상치 못한 상황도, 작성한 내용과 실제로 실행 중인 내용 사이의 괴리 (drift)도 없어야 합니다.

이것이 지금 중요한 이유

우리는 흥미로운 시점에 와 있습니다.

AI 에이전트로 무언가를 구축하는 대부분의 팀은 여전히 실험 모드에 있습니다. 그들은 빠르게 움직이며, 이것저것 시도해 보고, 무엇이 작동하는지 확인합니다. 인증 (Authentication)은 나중에 해결해야 할 문제처럼 느껴집니다.

하지만 "나중"이라는 것은 예상보다 더 빨리 찾아오곤 합니다.

팀이 프로토타입 (prototype)에서 다른 사람들이 의존하는 실제 서비스로 넘어갈 때, 질문은 빠르게 변합니다. 이 에이전트는 누구를 대신하여 행동할 수 있는가? 무엇을 할 수 있도록 허용되었는가? 어떻게 검증하는가? 문제가 발생했을 때 어떻게 액세스 권한을 취소 (revoke)하는가?

이것들은 단순한 기술적 질문이 아닙니다. 이것은 신뢰 (trust)에 관한 질문입니다.

그리고 현재 대부분의 팀은 이에 대한 명확한 답을 가지고 있지 않습니다.

지금까지 배운 것들

이것을 만들면서 저는 다양한 형태로 계속해서 재학습하게 되는 무언가를 배웠습니다.

기능을 추가하는 것은 쉽습니다. 깔끔한 멘탈 모델 (mental model)을 유지하는 것은 어렵습니다.

항상 더 많은 것을 하고 싶은 유혹이 생깁니다. 더 많은 통합 (integrations), 더 많은 설정 (settings), 더 많은 대시보드 (dashboards), 더 많은 옵션들 말이죠. 하지만 경험을 복잡하거나 단절된 것처럼 느끼게 만드는 무언가를 추가할 때마다, 무언가 잘못되었다는 느낌을 받았습니다.

목표는 가장 강력한 인증 시스템을 만드는 것이 아닙니다. 목표는 오늘날 현대적인 AI 시스템이 실제로 구축되는 방식에 자연스럽게 느껴지는 시스템을 만드는 것입니다.

그것은 들리는 것보다 더 어려운 문제입니다.

이것은 시작일 뿐입니다

AgentAuthLayer는 아직 초기 단계입니다. 아주 초기 단계입니다.

앞으로 갈 길이 멉니다. 더 나은 권한 모델 (Permission models), 더 풍부한 ID 워크플로우 (Identity workflows), 더 강력한 관측성 (Observability), 팀을 위한 더 매끄러운 온보딩 (Onboarding) 등 해야 할 일들이 많습니다. 목록은 길지만, 저는 이 모든 과정에 진심으로 설레고 있습니다.

하지만 앞으로 나아갈 방향을 이야기하기 전에, 이것이 어디에서 시작되었는지 먼저 공유하고 싶었습니다.

만약 여러분이 AI 에이전트 (AI agents)를 구축하고 있거나, 에이전트 플랫폼 (Agent platforms)을 작업 중이거나, 혹은 에이전트 중심의 세상 (Agentic world)에서 보안과 권한이 어떤 모습이어야 할지 고민하고 있다면, 여러분의 이야기를 듣고 싶습니다. 어떤 문제에 부딪히고 계신가요? 무엇이 아직 해결되지 않았다고 느끼시나요? 무엇이 실제로 여러분의 삶을 더 편하게 만들어 줄 수 있을까요?

이것은 고립된 상태가 아니라 대화를 통해 해결되는 종류의 문제입니다.

그리고 저는 이제 막 시작했을 뿐입니다.

직접 사용해보고 소통하세요

📦 PyPI에서 설치하기 → pypi.org/project/agentauthlayer
💼 LinkedIn에서 연결하기 → linkedin.com/in/vaibhav-ahluwalia-83887a227

AgentAuthLayer는 아직 아주 초기 단계에 있습니다. 아키텍처 (Architecture), API, 그리고 개발자 경험 (Developer experience) 모두 진화하고 있으며, 오늘날 빌더(Builders)들이 보내주는 피드백은 이 프로젝트가 다음에 나아갈 방향에 직접적인 영향을 미칠 것입니다. 여러분의 생각을 공유해 주신다면 정말 감사하겠습니다.