Published on

Logto: AI 앱의 병목은 모델이 아니라 인증·권한 컨트롤 플레인이다

Authors

키워드: AI 앱 인증 · OAuth 2.1 · OIDC · RBAC · 멀티테넌시 · MCP 인증

AI 앱을 만들 때 많은 팀이 먼저 보는 것은 모델이다. 어떤 모델이 더 싸고, 어떤 모델이 더 긴 컨텍스트를 받고, 어떤 모델이 tool calling을 잘하는지부터 비교한다. 하지만 실제 제품으로 가는 순간 병목은 다른 곳으로 이동한다. 누가 어떤 조직의 어떤 데이터와 어떤 도구에 접근할 수 있는가가 더 어려워진다.

2026년 6월 30일 GitHub Trending에 오른 Logto는 그래서 흥미롭다. README는 Logto를 “SaaS and AI apps”를 위한 오픈소스 인증·인가 인프라라고 소개하고, OIDC, OAuth 2.1, 멀티테넌시, Enterprise SSO, RBAC를 전면에 둔다. 단순히 로그인 버튼을 붙이는 라이브러리가 아니라, AI 앱이 실제 고객·조직·권한·도구 호출을 다루기 위해 필요한 identity control plane 쪽에 가깝다.

Logto AI app auth control plane cover

이 글의 핵심 주장은 간단하다. AI 앱의 다음 경쟁력은 “모델 호출을 붙였다”가 아니라 사람, 조직, 에이전트, API, 도구 권한을 같은 정책 언어로 묶는 능력에서 나온다. Logto가 특별한 이유도 바로 이 지점에 있다.

기준 시점: 이 글은 2026-06-30에 확인한 Logto GitHub README, GitHub API 메타데이터, Logto 공식 문서 기준이다. 인증·인가 제품의 기능과 가격·클라우드 정책은 바뀔 수 있으니 실제 도입 전 공식 문서를 다시 확인해야 한다.

왜 지금 Logto인가: AI 앱이 “데모”에서 “조직용 제품”으로 넘어가는 신호

Logto의 GitHub 설명은 꽤 노골적이다. “Authentication and authorization infrastructure for SaaS and AI apps, built on OIDC and OAuth 2.1 with multi-tenancy, SSO, and RBAC.” 여기서 AI라는 단어는 장식처럼 붙어 있지 않다. AI 앱이 B2B 제품이 되는 순간 필요한 요구사항이 한 줄에 압축돼 있다.

  • 사용자 로그인만이 아니라 조직 단위 접근 제어가 필요하다.
  • 관리자, 멤버, 게스트, 외부 고객, 서비스 계정의 권한이 달라야 한다.
  • 에이전트가 API와 도구를 호출할 때도 사람과 같은 정책 경계 안에 있어야 한다.
  • 고객사별 데이터, 워크플로, 결제, 감사 로그가 섞이면 안 된다.

2026년 6월 30일 기준 GitHub API에서 Logto는 TypeScript 기반 저장소로 12,500개 안팎의 스타와 850개 이상의 포크를 보였고, 전날에도 업데이트가 있었다. Trending 카드도 “SaaS and AI apps”라는 포지셔닝을 그대로 노출했다. 즉 이건 오래된 IAM 제품을 AI라는 말로 다시 포장한 정도가 아니라, AI 앱 빌더들이 인증·권한 계층을 제품 아키텍처의 중심으로 다시 보고 있다는 신호로 읽을 수 있다.

챗봇에 로그인 붙이기와 AI 제품의 권한 설계는 완전히 다르다

AI auth architecture shift

초기 AI 앱은 단순했다. 사용자가 로그인한다. 프롬프트를 보낸다. 서버가 모델 API를 호출한다. 결과를 보여준다. 이 정도라면 인증은 사실상 “누가 유료 사용자인가”를 확인하는 장치에 가깝다.

하지만 에이전트 기능이 들어오면 구조가 바뀐다.

  1. 사용자는 에이전트에게 업무를 위임한다.
  2. 에이전트는 여러 API, 데이터베이스, 문서 저장소, 내부 툴을 호출한다.
  3. 일부 호출은 사용자의 권한으로 실행되고, 일부는 서비스 계정의 권한으로 실행된다.
  4. 같은 사용자가 여러 조직에 속할 수 있고, 조직마다 역할이 다를 수 있다.
  5. 실행 결과는 나중에 감사·재현·승인 흐름에서 다시 검토돼야 한다.

이때 필요한 것은 로그인 UI가 아니라 권한의 경로를 설명할 수 있는 시스템이다. “이 사용자가 이 조직에서 이 스코프를 가진 토큰으로 이 API 리소스에 접근했다”를 말할 수 있어야 한다. Logto 문서가 RBAC, API resource, organization template, organization-level API resources를 나눠 설명하는 이유가 여기에 있다.

특히 개발자가 놓치기 쉬운 포인트는 API 보호와 제품 기능 권한이 다르다는 점이다. Logto 문서는 조직 단위 API 리소스와 조직 단위 non-API permission을 별도로 설명한다. 전자는 /organizations/{organizationId}/members 같은 API 데이터 접근에 가깝고, 후자는 UI·워크플로·관리 기능 안에서 “무엇을 할 수 있는가”를 제어하는 권한이다.

AI 에이전트 제품에서는 이 둘을 섞으면 위험해진다. 모델이 버튼을 대신 누르거나, 워크플로를 실행하거나, 백엔드 API를 호출할 수 있기 때문이다. 그래서 권한 설계는 “API 게이트웨이에서 막자”로 끝나지 않는다. UI, 워크플로, 백엔드 로직, 도구 호출, 감사 로그가 같은 모델을 공유해야 한다.

멀티테넌시는 데이터베이스 스키마 문제가 아니라 에이전트 행동 경계 문제다

Multi-tenant AI permission boundaries

Logto 공식 문서의 organization experience 섹션은 B2B SaaS에서 고객 조직이 직접 조직을 만들고, 멤버를 초대하고, 역할을 관리하는 흐름을 다룬다. 이것은 일반 SaaS에서도 중요하지만 AI 앱에서는 더 중요해진다.

AI 앱의 멀티테넌시는 단순히 tenant_id 컬럼을 붙이는 문제가 아니다. 에이전트가 하는 일은 종종 데이터 조회보다 넓다.

  • 조직 A의 문서를 읽고 요약한다.
  • 조직 B의 CRM에 태스크를 만든다.
  • 조직 C의 관리자 설정을 바꾼다.
  • 특정 고객사의 내부 지식베이스에서 검색한다.
  • 외부 SaaS API를 대신 호출한다.

이런 시스템에서 테넌트 격리가 느슨하면 “모델이 잘못 답했다”가 아니라 “고객 데이터와 권한이 섞였다”가 된다. 그래서 organization-level API resource가 중요하다. Logto 문서는 조직에 스코프가 묶인 API 리소스를 통해 멤버, 역할, 설정, 대시보드, 결제, 감사 엔드포인트 같은 테넌트별 데이터 접근을 제어할 수 있다고 설명한다.

여기서 실무적인 해석은 이렇다.

설계 질문데모 앱식 답변운영 제품식 답변
사용자는 누구인가로그인한 계정여러 조직에 속한 주체
에이전트는 어떤 권한인가서버 API 키사용자/조직/서비스 계정에 묶인 제한 권한
데이터 경계는 어디인가DB 쿼리 조건토큰, 조직 컨텍스트, API 리소스, 감사 로그
실패 시 무엇을 추적하나프롬프트와 응답권한 결정, tool call, 스코프, 조직, 호출 주체

AI 에이전트가 강력해질수록 “모든 도구를 한 번에 연결해준다”는 말은 매력적이면서도 위험하다. 좋은 제품은 연결을 많이 해주는 제품이 아니라, 조직별·역할별·작업별로 연결을 안전하게 제한할 수 있는 제품이다.

M2M과 서비스 계정: 에이전트 워크플로의 숨은 주체를 다뤄야 한다

AI 제품에는 사람만 있는 게 아니다. 백엔드 워커, 스케줄러, 데이터 동기화 잡, RAG 인덱서, 평가 파이프라인, 알림 봇, MCP 서버가 있다. 이들은 사용자의 클릭 없이도 API를 호출한다. 그래서 machine-to-machine 인증과 서비스 계정 모델이 필요하다.

Logto 문서의 organization experience 흐름도 백엔드가 Logto Management API에 접근할 때 machine-to-machine authentication을 사용하라고 안내한다. 이 부분은 사소하지 않다. 많은 AI 앱은 초기에 “서버에 관리자 API 키 하나”로 시작한다. 빠르다. 하지만 시간이 지나면 누가 어떤 작업을 수행했는지, 어떤 조직 범위에서 실행됐는지, 어느 스코프가 필요한지 설명하기 어려워진다.

좋은 운영 기준은 다음과 같다.

  • 사람 사용자와 서비스 주체를 구분한다.
  • 에이전트가 호출하는 API마다 필요한 스코프를 최소화한다.
  • 조직 컨텍스트가 필요한 작업은 토큰과 요청 모두에서 조직을 명확히 드러낸다.
  • 관리자성 작업은 별도 승인·감사 경로를 둔다.
  • 장기 실행 에이전트 작업은 시작 권한과 실제 실행 권한을 분리해 기록한다.

이건 대기업만의 문제가 아니다. 작은 팀일수록 처음부터 이런 경계를 잡아야 나중에 “AI 기능을 꺼야 하는” 상황을 피할 수 있다.

Logto MCP Server가 보여주는 방향: 에이전트에게도 로그인과 동의가 필요하다

MCP auth and governance

Logto 문서에서 특히 눈에 띄는 것은 Logto MCP Server다. 공식 문서는 이를 remote MCP 서버라고 설명하고, Claude Code나 Claude Desktop 같은 AI 애플리케이션에 https://mcp.logto.io를 추가한 뒤 Logto Cloud 계정으로 로그인해 사용할 수 있다고 안내한다.

이 기능이 중요한 이유는 “MCP도 결국 인증 제품의 사용자가 된다”는 점을 보여주기 때문이다. MCP는 에이전트가 외부 도구와 만나는 표준 인터페이스로 빠르게 자리 잡고 있다. 그런데 MCP 서버가 강력해질수록 질문은 바뀐다.

  • 이 에이전트는 누구의 계정으로 연결됐는가?
  • 어떤 스코프의 도구만 볼 수 있는가?
  • 사용자는 언제 동의했고 언제 연결을 끊을 수 있는가?
  • tool call은 나중에 감사할 수 있는가?
  • 문서 검색 답변은 출처를 남기는가?

Logto MCP Server 문서는 AI가 프레임워크를 감지하고 Logto 애플리케이션을 만들고 통합 코드를 생성할 수 있다고 설명한다. 앞으로 RBAC, permission management, multi-tenancy setup 같은 기능도 더해질 예정이라고 한다. 이 방향은 꽤 상징적이다. 인증 제품도 이제 “관리 콘솔에서 사람이 설정하는 도구”에서 “에이전트가 안전하게 조작할 수 있는 운영 표면”으로 확장되고 있다.

다만 여기서 중요한 것은 자동화 그 자체가 아니다. 핵심은 에이전트가 인증·권한 인프라를 만질 때도 OAuth, 동의, 스코프, 감사 가능성이 필요하다는 점이다. MCP 서버를 붙였다고 해서 에이전트에게 관리자 권한을 통째로 주는 순간, 생산성 도구가 아니라 내부 보안 사고의 새로운 경로가 된다.

Logto를 볼 때의 실무 체크리스트

Logto를 당장 도입하라는 결론보다 중요한 것은, AI 앱 팀이 어떤 질문을 해야 하는지다. 실제 제품 설계를 점검한다면 아래 항목부터 봐야 한다.

1) 로그인보다 권한 모델을 먼저 그렸는가

“Google 로그인 붙이기”는 시작일 뿐이다. 사용자, 조직, 역할, API 리소스, 서비스 계정, 에이전트 작업을 한 장의 권한 모델로 그릴 수 있어야 한다. 이 모델이 없으면 나중에 기능이 늘어날수록 예외 규칙만 쌓인다.

2) 조직 컨텍스트가 토큰과 API에 명시되는가

B2B AI 앱에서는 같은 사용자가 여러 고객사에 속할 수 있다. 조직 선택 UI만 있고 백엔드 토큰·API 호출에 조직 컨텍스트가 명확하지 않으면 사고가 난다. Logto가 organization-level API resources를 강조하는 이유가 여기에 있다.

3) 에이전트 tool call을 일반 API 호출처럼 감사할 수 있는가

AI가 호출한 작업은 “모델이 알아서 했다”로 처리하면 안 된다. 누가 위임했고, 어떤 스코프로 실행됐고, 어떤 도구가 호출됐고, 결과가 무엇이었는지 남겨야 한다. 특히 고객 데이터, 결제, 관리자 설정, 외부 SaaS 변경 작업은 필수다.

4) M2M 주체와 사람 주체를 섞지 않는가

스케줄러나 워커가 관리자 API 키 하나로 모든 조직을 건드리는 구조는 빠르지만 오래가지 못한다. 서비스 계정도 최소 권한, 조직 범위, 감사 로그를 가져야 한다.

5) MCP 연결에 로그인·동의·스코프가 있는가

MCP 서버는 에이전트에게 새로운 손발을 달아준다. 그래서 연결 과정은 편해야 하지만, 권한은 더 엄격해야 한다. “사용자가 어떤 MCP 서버에 어떤 권한을 줬는가”를 제품이 설명할 수 있어야 한다.

SEO 관점에서 보는 기회: “AI 앱 인증”은 아직 과소평가된 검색 의도다

한국어 검색에서는 아직 “AI 앱 만들기”, “AI 에이전트 프레임워크”, “RAG 구축” 같은 키워드가 더 눈에 띈다. 반면 실제 운영 단계에서 더 중요한 “AI 앱 인증”, “AI 에이전트 권한 관리”, “MCP OAuth”, “멀티테넌트 AI SaaS”, “RBAC AI 앱” 같은 검색 의도는 아직 얇다.

하지만 제품을 만드는 사람에게는 이쪽이 훨씬 실전적이다. 모델 선택은 바꿀 수 있다. 프롬프트도 바꿀 수 있다. 하지만 고객 조직, 권한, 감사 로그, 서비스 계정, MCP 연결 방식을 잘못 잡으면 나중에 제품 전체를 다시 설계해야 한다.

그래서 Logto의 Trending 등장은 작은 신호지만 의미가 있다. AI 앱 생태계의 관심이 “어떤 모델을 쓸까”에서 “어떻게 안전하게 제품화할까”로 이동하고 있다는 증거이기 때문이다.

결론: AI 앱의 진짜 운영 계층은 identity다

Logto는 “또 하나의 auth 서비스”로만 보면 평범해 보일 수 있다. 하지만 AI 앱이라는 맥락에서 보면 다르게 보인다. 에이전트가 사용자 대신 API를 호출하고, 여러 조직의 데이터에 접근하고, MCP 서버를 통해 외부 도구와 연결되는 시대에는 인증·인가가 부가 기능이 아니다.

AI 앱의 운영 계층은 identity다. 모델은 추론을 담당하지만, 제품은 누가 무엇을 할 수 있는지를 책임져야 한다. Logto가 보여주는 방향은 명확하다. AI 앱을 오래 운영하려면 OAuth/OIDC, RBAC, 멀티테넌시, 서비스 계정, MCP 인증을 뒤늦게 붙이는 것이 아니라 처음부터 컨트롤 플레인으로 설계해야 한다.

참고한 주요 출처

Discuss on Twitter • View on GitHub