멀티테넌시
VEXPLOR에서 테넌트는 고객사 하나의 독립된 공간입니다. 여러 고객사가 같은 플랫폼을 사용해도 각 테넌트의 사용자·설계·업무 데이터는 서로 보이지 않습니다. 로그인할 때 받은 토큰이 「어느 테넌트 소속인가」를 증명하고, 모든 서비스가 그 정보를 기준으로 데이터를 나눕니다. 배포로 만들어진 업무 테이블은 테넌트마다 따로 마련된 데이터베이스 영역에 생성됩니다.
무엇인가
아파트 단지를 떠올려 보면 쉽습니다. 건물(플랫폼)과 관리사무소(공통 서비스)는 함께 사용하지만, 각 세대(테넌트)의 출입문과 살림살이는 따로입니다. 옆집 열쇠로는 우리 집 문이 열리지 않습니다.
VEXPLOR의 멀티테넌시도 같습니다.
| 함께 사용하는 것 | 테넌트마다 따로인 것 |
|---|---|
| 화면 프로그램, 서비스, 솔루션 템플릿, AI 모델 | 사용자·부서·역할, 캔버스 설계, 배포된 업무 테이블과 데이터, 알림 설정, Edge 디바이스, AI 대화 기록 |
테넌트가 만들어지고 사용되는 흐름
- 가입: 회사 정보를 입력해 가입하면 테넌트가 하나 만들어지고, 그 테넌트의 기본 역할이 함께 준비됩니다. 회사 고유 주소로 사용할 식별자(슬러그)는 가입 화면에서 중복 여부를 바로 확인합니다.
- 구성원 초대: 관리자가 이메일로 구성원을 초대하면, 초대를 수락한 사용자는 그 테넌트에 소속됩니다.
- 로그인: 사용자가 로그인하면 토큰에 소속 테넌트 정보가 담깁니다.
- 요청: 화면에서 보낸 모든 요청은 API 게이트웨이를 거칩니다. 게이트웨이는 토큰 서명을 확인한 뒤에만 테넌트 정보를 뒤쪽 서비스에 전달합니다.
- 데 이터 접근: 각 서비스는 전달받은 테넌트 정보로 읽고 저장할 데이터를 한정합니다.
- 배포: 캔버스를 배포하면 그 테넌트 전용 데이터베이스 영역에 업무 테이블이 만들어집니다.
데이터를 나누는 세 가지 방법
VEXPLOR는 한 가지 방법에만 의존하지 않고 아래 세 가지를 겹쳐 사용합니다.
1. 토큰 기준 확인
테넌트 정보는 오직 서명이 확인된 로그인 토큰에서 나옵니다. 화면이나 외부 프로그램이 요청에 다른 테넌트의 식별자를 직접 넣어도 게이트웨이와 서비스가 이를 토큰 값과 비교해 다르면 거부합니다. 로그인은 되어 있는데 소속 테넌트가 없는 요청도 거부됩니다.
2. 플랫폼 데이터의 테넌트 표시
사용자·역할·캔버스·알림처럼 플랫폼이 관리하는 데이터에는 모두 「어느 테넌트의 것인가」가 표시되어 있고, 조회할 때 항상 그 조건이 붙습니다. 일부 데이터는 데이터베이스 자체의 행 단위 보안 정책을 추가로 적용해, 프로그램 쪽 조건이 빠지더라도 다른 테넌트의 행이 보이지 않게 합니다.
3. 업무 테이블의 테넌트별 영역 (Schema-per-tenant)
캔버스에서 설계해 배포한 테이블은 **테넌트마다 별도의 데이터베이스 영역(스키마)**에 생성됩니다. 같은 「작업지시」 테이블이라도 A사의 것과 B사의 것은 이름만 같을 뿐 물리적으로 다른 테이블입니다. 배포된 화면에서 조회·저장할 때는 요청한 사용자의 테넌트 영역만 대상으로 삼습니다.
| 방법 | 막는 것 |
|---|---|
| 토큰 기준 확인 | 요청을 조작해 다른 테넌트로 들어가려는 시도 |
| 테넌트 표시 + 행 단위 정책 | 플랫폼 데이터 조회에서 조건이 빠지는 실수 |
| 테넌트별 영역 | 업무 테이블 이름이 같아서 생기는 혼동, 한 테넌트의 구조 변경이 다른 테넌트에 주는 영향 |
왜 테넌트별 영역을 선택했나
업무 테이블을 모든 고객사가 하나의 큰 테이블로 함께 사용하는 방식도 있습니다. VEXPLOR가 테넌트별 영역을 선택한 이유는 다음과 같습니다.
- 고객사마다 테이블 구조가 다릅니다. 노코드 플랫폼에서는 고객사가 컬럼을 추가하고 관계를 바꿉니다. 영역이 분리되어 있으면 A사가 컬럼을 추가해도 B사의 테이블은 그대로입니다.
- 배포를 독립적으로 할 수 있습니다. 한 테넌트의 배포나 되돌리기가 다른 테넌트에 영향을 주지 않습니다.
- AI도 같은 경계를 지킵니다. AI가 데이터를 다룰 때도 요청한 사용자의 테넌트를 기준으로만 조회하고, 데이터베이스에서는 삭제 권한이 아예 없는 별도 권한으로 동작합니다.
테넌트 단위로 적용되는 것들
| 항목 | 내용 |
|---|---|
| 구독 플랜 | 테넌트마다 플랜이 있으며, 플랜에 따라 만들 수 있는 테이블 수와 동시에 진행할 수 있는 배포 수가 달라집니다. |
| 요청량 제한 | 요청량은 테넌트와 접속 위치를 묶어 따로 셉니다. 한 테넌트가 많은 요청을 보내도 다른 테넌트의 한도는 줄지 않습니다. |
| 솔루션 메뉴 기본값 | 관리자가 테넌트 기본 메뉴 표시를 정하고, 사용자는 자기 화면에서만 표시 여부를 바꿀 수 있습니다. |
| 감사 기록 | 데이터 변경 기록은 테넌트별로 저장되고 그 테넌트 안에서만 조회됩니다. |
운영 지원 접속
플랫폼 운영자가 문제 해결을 위해 고객사 화면을 확인해야 할 때가 있습니다. 이 경우에도 허용된 일부 동작만 할 수 있고, 지원 접속 세션은 정해진 시간이 지나면 끝나며, 지원 접속 중 호출한 모든 요청은 누가 무엇을 했는지 기록됩니다.
실무 팁
데이터를 서로 보면 안 되는 별도 회사라면 테넌트를 나눕니다. 같은 회사 안의 공장·부서라면 하나의 테넌트 안에서 부서와 권한 범위로 나누는 편이 관리가 쉽습니다. 테넌트가 다르면 데이터가 완전히 분리되어 합쳐 보기 어렵기 때문입니다.
구성원은 관리자 초대로 추가합니다. 초대 없이 새로 가입하면 별도의 테넌트가 하나 더 만들어지므로, 기존 회사 공간에 합류하려면 반드시 초대를 받아야 합니다.
외부 시스템이 VEXPLOR API를 호출할 때도 해당 테넌트 사용자의 토큰이 필요합니다. 요청 본문이나 주소에 테넌트 식별자를 넣어도 토큰의 테넌트와 다르면 거부됩니다.