정말로 여러 테넌트가 당신의 아이덴티티 시스템을 관리하기 위해 필요한가요?

오늘날 저코드 도구와 클라우드 서비스의 성숙도가 높아지면서 AI 도구화의 가속화와 함께 앱 개발의 진입 장벽이 크게 낮아지고 있으며 시장에 점점 더 많은 앱이 등장하고 있습니다.

복잡한 앱이든 간단한 앱이든 대부분의 앱은 사용자 등록 및 로그인 시나리오를 포함하여 사용자가 더 안정적이고 안전하며 맞춤화된 서비스를 받을 수 있도록 합니다. 그리고 사용자 로그인 및 등록 문제를 해결하기 위한 첫 번째 단계는 아이덴티티 시스템을 구축하는 것입니다.

많은 소비자 대상 앱의 경우 아이덴티티 모델이 상대적으로 단순하거나 이메일과 비밀번호만 필요할 수도 있습니다. 빠르게 성장하고 새로운 사용자를 유치하는 단계의 앱의 경우 이는 충분합니다. 하지만 앱에 자체 비즈니스 모델이 생기면, 가장 간단한 경우 예를 들어 광고를 제공하기 위해 일반 사용자 계정과 광고주 계정을 구분할 필요가 있습니다. 광고주 계정은 광고 투여 규모와 콘텐츠 등을 맞춤화할 수 있지만, 일반 사용자는 일부 무료 콘텐츠와 광고만 볼 수 있습니다.

Logto는 클라우드 기반의 아이덴티티 솔루션이며, 특별한 요구를 가진 사용자가 사용자 정의를 수행할 수 있도록 클라우드 서비스와 같은 커널을 가진 오픈 소스 소프트웨어(OSS) 솔루션도 있습니다. Logto의 서비스는 여러 테넌트 시스템에 구축되어 있으며, Logto 사용자는 자신의 계정을 생성하고 계정 내에서 여러 테넌트를 관리할 수 있습니다. 다른 다양한 아이덴티티 클라우드 서비스도 유사한 아키텍처를 가지고 있으며, 각 다른 클라우드 서비스는 각각의 "테넌트" 정의를 가지고 있어, 이 기사에서 논의하는 테넌트 모델은 Logto의 시나리오에 국한되며 다른 공급업체의 경우 다른 대응 개념이 있을 수 있습니다.

특히 Logto의 멀티 테넌트 모델에서는 테넌트 간의 데이터(모든 최종 사용자 정보)가 격리된다는 것이 중요하며, Logto 사용자는 비즈니스 요구에 따라 하나의 Logto 계정 내에서 최종 사용자 계정 데이터를 관리할 수 있습니다. 많은 다른 아이덴티티 클라우드 서비스는 각 계정에 하나의 테넌트만 지원할 수 있어 여러 테넌트를 동시에 관리해야 하는 사용자는 자주 계정을 전환해야 하며, 이는 사용자 경험이 저하됩니다.

그렇다면 어떤 계정 모델이 앱에 적합한 지 어떻게 선택해야 할까요? 여기 세 가지 사례를 살펴보겠습니다.

사례 1: 앱은 최종 사용자에게 직접 서비스를 제공합니다#

이 유형의 앱에서 아이덴티티 모델은 매우 간단합니다. 예를 들어 음악 스트리밍 앱을 사용해 보겠습니다 — 관리자를 제외하고(이 경우 Logto의 사용자 'foo'는 테넌트 소유자로 기본 관리자 액세스를 가집니다), 최종 사용자만 있습니다.

이 시나리오에서 최종 사용자는 세 가지 유형으로 나눌 수 있습니다:

1. 무료 플랜 사용자: 무료 음악만 재생할 수 있습니다.
2. 유료 플랜 사용자: 무료 음악을 재생하고 자신만의 재생 목록을 만들 수 있습니다.
3. 프리미엄 사용자: 무료 음악 재생 및 재생 목록 생성 외에도 HiFi 음악을 재생할 수 있습니다.

위의 애플리케이션 시나리오에서 우리는 다른 권한이 부여된 세 가지 유형의 역할(무료, 유료, 프리미엄)만 필요합니다. 따라서 최종 사용자가 로그인한 후, Logto는 그가 가진 역할에 기반하여 특정 서비스를(예: HiFi 음악 접근) 제공할지 결정할 수 있습니다. 이 시점에서 우리는 단일 테넌트만으로 요구 사항을 충족할 수 있습니다.

사례 2: 전자상거래 플랫폼 앱#

서드-파티 서비스 제공자와 최종 사용자를 연결하는 플랫폼은 매우 일반적인 2C 비즈니스 모델입니다. 두 가지 사용자를 고려할 필요가 있습니다 - 전자상거래 앱을 예로 들면, 이들은 판매자(서비스 공급자)와 구매자(최종 사용자)입니다.

여기에서 아이덴티티 모델을 구축하는 두 가지 방법이 있습니다:

1. 구매자와 판매자 사용자 그룹을 동일한 테넌트에 배치합니다.

2. 구매자와 판매자를 각각 다른 두 개의 테넌트에 배치합니다.

예제를 더 쉽게 이해할 수 있도록, 구매자는 주문을 하거나 제품 설명을 볼 수 있다고 가정합니다. 판매자는 제품 가격을 변경하고, 제품 설명을 변경하며, 제품 재고를 볼 수 있습니다. 판매자는 제품 설명을 보고 문제를 찾아 시기적절하게 제품 정보를 업데이트할 수 있습니다.

아이덴티티 모델 1의 경우, 하나의 앱만 있습니다. 등록한 모든 사용자는 구매자가 됩니다. 만약 누군가 무언가를 팔아야 한다면, 그들은 판매할 제품을 추가할 수 있으며, 그러한 최종 사용자는 구매자 권한 외에도 판매자 권한을 얻어 자신의 제품을 관리할 수 있습니다.

아이덴티티 모델 2의 경우, 각 테넌트는 자체 고유 아이덴티티 정보와 자체 개별 허가 게이트웨이를 가지고 있기 때문에, 각 테넌트는 자체 앱이 필요합니다. 예제의 경우, 구매자 앱과 판매자 앱이 존재하게 됩니다. 구매자 계정은 판매자가 될 수 없고, 판매자 계정도 구매자가 될 수 없습니다. 판매자가 모델 1처럼 자신의 제품 설명을 구매자의 시각에서 보고 싶다면, 판매자 앱에서 동일한 기능을 재구현해야 하거나 구매자 앱 계정을 등록하여 확인해야 합니다. 이는 많은 복잡성을 추가하지만, 장점은 구매자와 판매자 아이덴티티가 완전히 격리된다는 것입니다.

판매자가 관리해야 할 제품이 많다면, 아이덴티티 모델 2를 사용하고 보다 전문화된 판매자 앱을 개발하는 것이 더 나은 선택일 것입니다. 모델 1은 eBay와 같은 플랫폼에 적합하며 판매자가 많은 제품을 가지고 있지 않고 과도하게 복잡한 제품 관리 기능이 필요하지 않은 경우에 적합합니다.

사례 3: IT 컨설팅 기업이 만든 앱#

IT 기술 컨설팅 기업이 있으며, 고객이 IT 시스템을 직접 개발할 수 있는 능력이 없어 이 기업의 기술 서비스를 이용해야 한다고 가정해 봅시다.

이 회사에 두 명의 고객이 있으며, 하나는 서점의 내부 도서 관리 시스템이고, 다른 고객은 호텔의 예약 시스템입니다.

서점 주인의 관점에서 보면, 당연히 호텔 손님이 내 도서 관리 시스템에 무작위로 로그인할 수 없도록 하고 싶을 것입니다. 이는 매우 위험할 것이기 때문입니다. 따라서 프라이버시 보호 측면에서 각 고객에게 별도의 테넌트를 설정하고, 테넌트 정보 분리 메커니즘을 활용하여 고객의 데이터가 다른 고객에게 보이지 않도록 해야 합니다.

이전에 언급한 바와 같이, 여러 테넌트를 생성할 필요가 있는 경우에도, Logto는 하나의 계정에서 여러 테넌트를 관리할 수 있도록 도와주므로, 여러 계정을 직접 생성하고 관리해야 하는 일부 다른 서비스보다 더 편리하고 안전합니다.

위에서 설명한 예제를 통해, 언제 여러 테넌트를 생성해야 하고, 어떤 시나리오에서는 단일 테넌트나 여러 테넌트를 가질 수 있는지 알아내었으며, 자신의 비즈니스 요구에 따라 적합한 아이덴티티 모델 솔루션을 선택할 수 있을 것입니다.

Logto 팀은 "여러 테넌트를 생성해야 하는지 여부"가 어떤 비즈니스에도 방해가 되지 않도록 하는 것을 목표로 하고 있습니다. 만약 자신의 비즈니스 시나리오가 단일 테넌트로 실현될 수 있는지 확신이 없다면, Logto 커뮤니티에 참여하여 상담해 보세요. 여러분의 질문은 다른 사람의 질문일 수도 있으므로 직면한 문제를 우리와 공유하여 Logto 제품의 확장성을 향상시키는 데 도움을 주시기 바랍니다.

앱을 위한 아이덴티티 프레임워크를 선택하는 경우, Logto는 소규모 비즈니스부터 대규모 애플리케이션까지 다양한 비즈니스 시나리오에 적합한 즉시 사용 가능한 솔루션을 제공하므로 시도해볼 가치가 있습니다!