노코드 백엔드를 위한 다중 테넌트 SaaS 데이터 모델 옵션

문제: 테넌트를 분리하면서 속도 저하를 막기\n\n다중 테넌시는 하나의 소프트웨어가 여러 고객(테넌트)을 서비스하는 것을 뜻하며, 각 테넌트는 자신 데이터만 볼 수 있어야 합니다. 어려운 점은 그걸 일관되게 적용하는 것입니다: 단순히 한 화면에서만이 아니라 모든 API 호출, 관리자 화면, 내보내기, 백그라운드 작업 전체에 걸쳐서요.\n\n데이터 모델은 대부분의 팀이 예상하는 것보다 일상 운영에 더 큰 영향을 미칩니다. 권한, 보고, 성장에 따른 쿼리 속도, 그리고 작은 버그가 얼마나 위험해질 수 있는지를 결정합니다. 필터 하나만 빼먹어도 데이터가 유출될 수 있고, 너무 강하게 격리하면 보고 작업이 번거로워집니다.\n\n일반적으로 세 가지 방식으로 다중 테넌트 데이터 모델을 구조화합니다:\n\n- 모든 테이블에 tenant_id가 있는 하나의 데이터베이스\n- 하나의 데이터베이스 안에 테넌트별로 분리된 스키마\n- 테넌트별로 분리된 데이터베이스\n\n노코드 백엔드로 시각적으로 빌드하더라도 동일한 트레이드오프가 적용됩니다. AppMaster 같은 도구는 설계에서 실제 백엔드 코드와 데이터베이스 구조를 생성하므로 초기 모델링 결정은 빠르게 프로덕션 동작과 성능에 드러납니다.\n\n예를 들어 헬프데스크 도구를 생각해보세요. 모든 티켓 행에 tenant_id가 있으면 “모든 오픈 티켓”을 쿼리하기는 쉽지만 모든 곳에서 테넌트 체크를 강제해야 합니다. 반대로 각 테넌트에 스키마나 DB를 주면 기본적으로 격리가 강하지만, “모든 고객의 평균 처리 시간” 같은 크로스-테넌트 보고는 더 손이 많이 갑니다.\n\n목표는 보고, 지원, 성장에 마찰을 추가하지 않으면서 신뢰할 수 있는 분리 수준을 갖는 것입니다.\n\n## 빠른 선택법: 결정을 좁히는 4가지 질문\n\n데이터베이스 이론부터 시작하지 마세요. 제품이 어떻게 사용될지, 매주 운영에 무엇이 필요한지부터 시작하세요.\n\n### 보통 정답을 쉽게 만드는 네 가지 질문\n\n1) 데이터 민감도가 얼마나 높고 규제가 엄격한가? 의료, 금융, 엄격한 고객 계약은 보통 더 강한 격리(분리 스키마나 별도 DB)를 요구합니다. 위험을 줄이고 감사 대응을 쉽게 해줍니다.\n\n2) 자주 크로스-테넌트 보고가 필요한가? “모든 고객” 메트릭(사용량, 매출, 성능)을 자주 봐야 한다면 tenant_id가 있는 단일 DB가 가장 단순한 경우가 많습니다. 별도 DB는 여러 곳을 쿼리해서 결과를 합쳐야 하므로 더 어렵습니다.\n\n3) 테넌트들끼리 얼마나 달라질까? 테넌트가 커스텀 필드, 워크플로, 통합을 많이 필요로 하면 스키마나 DB 분리가 변경 유출 가능성을 줄입니다. 대부분이 동일한 구조라면 tenant_id가 깔끔합니다.\n\n4) 팀이 현실적으로 운영할 수 있는 범위는? 격리가 강할수록 작업이 늘어납니다: 백업, 마이그레이션, 구성 요소, 실패 지점이 많아집니다.\n\n실용적 접근은 상위 두 가지 선택을 프로토타입으로 만들어 권한 규칙, 보고 쿼리, 모델 변화 시 롤아웃 방식을 테스트하는 것입니다.\n\n## 접근법 1: 모든 행에 tenant_id를 둔 하나의 데이터베이스\n\n가장 흔한 설정입니다: 모든 고객이 동일한 테이블을 공유하고 각 테넌트 소유 레코드에 tenant_id가 붙습니다. 운영상 단순한 이유는 데이터베이스와 마이그레이션을 한 번만 관리하면 되기 때문입니다.\n\n규칙은 엄격합니다: 행이 테넌트에 속하면 tenant_id를 포함해야 하고 모든 쿼리는 이를 필터해야 합니다. 테넌트 소유 테이블은 보통 사용자, 역할, 프로젝트, 티켓, 인보이스, 메시지, 파일 메타데이터, 테넌트 데이터를 연결하는 조인 테이블을 포함합니다.\n\n유출을 줄이려면 tenant_id를 비협상적으로 다루세요:\n\n- 테넌트 소유 테이블에서 tenant_id를 필수(NOT NULL)로 만들기\n- tenant_id로 시작하는 인덱스 추가(예: tenant_id, created_at)\n- 고유 규칙에 tenant_id 포함(예: 테넌트별 이메일 고유)\n- tenant_id를 UI 폼뿐 아니라 모든 API와 비즈니스 흐름에 전파\n- 클라이언트 필터뿐 아니라 백엔드에서 강제\n\nPostgreSQL에서는 행 수준 보안(RLS) 정책이 동적 쿼리가 많을 때 강력한 안전망이 될 수 있습니다.\n\n참조 데이터는 보통 두 그룹 중 하나입니다: tenant_id가 없는 공유 테이블(예: countries)과 tenant_id를 포함하는 테넌트 범위 카탈로그(예: 커스텀 태그, 파이프라인).\n\nAppMaster로 빌드한다면 간단한 습관이 대부분의 사고를 막습니다: 인증된 사용자의 테넌트를 Business Process 로직에서 모든 생성/조회 전에 설정하고 그 패턴을 일관되게 유지하세요.\n\n## 권한 영향: 접근 방식별 변화\n\n권한이 다중 테넌시의 성패를 좌우합니다. 데이터 레이아웃은 사용자 저장 방식, 쿼리 범위 지정 방식, 관리 화면에서의 실수 방지 방법을 바꿉니다.\n\n단일 DB와 모든 행의 tenant_id에서는 보통 하나의 Users 테이블을 공유하고 각 사용자를 테넌트와 역할에 연결합니다. 핵심 규칙은 같아서 모든 읽기/쓰기는 작은 테이블(설정, 태그, 로그 등)에도 테넌트 범위를 포함해야 합니다.\n\n분리된 스키마에서는 로그인, 비밀번호, MFA 같은 공통 인증 레이어는 공유하고 테넌트 데이터는 각 테넌트 스키마에 둡니다. 권한은 쿼리를 실행하기 전에 올바른 스키마로 라우팅하는 문제가 일부 됩니다.\n\n분리된 데이터베이스에서는 격리가 가장 강하지만 권한 로직은 인프라로 이동합니다: 올바른 DB 연결 선택, 자격 증명 관리, 전사 직원 계정 처리 등입니다.\n\n세 접근법 모두에서 교차 테넌트 위험을 줄이는 일관된 패턴이 있습니다:\n\n- tenant_id를 세션이나 토큰 클레임에 넣고 필수로 취급\n- 엔드포인트 여기저기에 흩어지는 대신 중앙(미들웨어나 단일 Business Process)에 테넌트 검사를 집중\n- 관리자 도구에서 테넌트 컨텍스트를 명확히 표시하고 명시적인 테넌트 전환 요구\n- 지원 접근은 감사 로그가 있는 임시 가장(impersonation) 사용\n\nAppMaster에서는 인증 직후 테넌트 컨텍스트를 저장하고 API 엔드포인트와 Business Process에서 재사용해 모든 쿼리가 스코프 안에 있도록 하는 것이 일반적입니다. 지원 담당자는 UI가 우연히 필터한 덕분에 보는 것이 아니라, 앱이 테넌트 컨텍스트를 설정한 뒤에만 주문을 볼 수 있어야 합니다.\n\n## tenant_id 모델의 보고 및 성능\n\ntenant_id 단일 DB 접근에서는 보고가 보통 직관적입니다. 글로벌 대시보드(MRR, 가입, 사용량)는 모든 사람을 대상으로 한 쿼리로 실행할 수 있고, 테넌트별 보고는 같은 쿼리에 필터만 추가하면 됩니다.\n\n단점은 시간이 지남에 따른 성능입니다. 테이블이 커지면 한 테넌트의 과도한 활동이 ‘시끄러운 이웃’이 되어 더 많은 행을 만들고 쓰기를 촉발해 공통 쿼리를 느리게 할 수 있습니다.\n\n인덱싱으로 이 모델을 건강하게 유지하세요. 대부분의 테넌트 범위 읽기는 tenant_id로 시작하는 인덱스를 사용해 데이터베이스가 해당 테넌트의 슬라이스로 바로 점프할 수 있어야 합니다.\n\n좋은 기준:\n\n- tenant_id가 첫 컬럼인 복합 인덱스 추가(예: tenant_id + created_at, tenant_id + status, tenant_id + user_id)\n- 크로스-테넌트 쿼리가 필요할 때만 진정한 글로벌 인덱스 유지\n- tenant_id를 잊는 조인/필터를 주시(느린 스캔 유발)\n\n보존 및 삭제 계획도 필요합니다. 한 테넌트의 기록이 모두의 테이블을 팽창시킬 수 있습니다. 테넌트별 보존 정책이 다르다면 소프트 삭제와 테넌트별 예약 아카이빙을 고려하거나 tenant_id로 키된 아카이브 테이블로 오래된 행을 옮기세요.\n\n## 접근법 2: 테넌트별 분리 스키마\n\n분리 스키마는 하나의 PostgreSQL 데이터베이스를 사용하지만 각 테넌트에 스키마(예: tenant_42)를 부여합니다. 해당 스키마 안의 테이블은 그 테넌트에만 속합니다. 여러 데이터베이스를 운영하는 오버헤드 없이 각 고객에게 "미니 데이터베이스"를 주는 느낌입니다.\n\n일반적으로 전역 서비스는 공유 스키마에 두고 테넌트 데이터는 테넌트 스키마에 둡니다. 구분은 보통 모든 고객과 공유해야 하는 것과 절대 섞이면 안 되는 것을 나누는 기준입니다.\n\n전형적 분리는 다음과 같습니다:\n\n- 공유 스키마: tenants 테이블, 플랜, 청구 기록, 기능 플래그, 감사 설정\n- 테넌트 스키마: 주문, 티켓, 재고, 프로젝트, 커스텀 필드 같은 비즈니스 테이블\n- 경우에 따라(제품에 따라): 사용자가 여러 테넌트에 접근할 수 있으면 사용자와 역할을 공유쪽에 둘 수도 있음\n\n이 모델은 테이블이 서로 다른 네임스페이스에 있으므로 크로스-테넌트 조인 위험을 줄여줍니다. 또한 하나의 스키마를 타겟으로 백업하거나 복원하기가 더 쉽습니다.\n\n팀을 놀라게 하는 것은 마이그레이션입니다. 새 테이블이나 컬럼을 추가할 때 모든 테넌트 스키마에 변경을 적용해야 합니다. 테넌트가 10개면 관리하기 쉽지만 1,000개라면 스키마 버전을 추적하고 배치로 마이그레이션을 실행하며 하나의 실패한 테넌트가 나머지를 막지 않도록 실패 안전성을 확보해야 합니다.\n\n인증과 청구 같은 공유 서비스는 보통 테넌트 스키마 밖에 둡니다. 실용적 패턴은 공유 인증(하나의 사용자 테이블 + 테넌트 멤버십 테이블)과 공유 청구(Stripe 고객 ID, 인보이스)를 두고 테넌트 스키마는 테넌트 소유 비즈니스 데이터를 저장하는 것입니다.\n\nAppMaster를 쓰는 경우 Data Designer 모델이 공유 스키마와 테넌트 스키마에 어떻게 매핑되는지 초기에 계획하고, 로그인이나 결제를 깨뜨리지 않도록 글로벌 서비스를 안정적으로 유지하세요.\n\n## 분리 스키마의 보고 및 성능\n\n분리 스키마는 기본적으로 tenant_id만 있는 모델보다 더 강한 분리를 제공합니다. 권한을 스키마 단위로 설정할 수 있고 각 테넌트 테이블이 물리적으로 구분됩니다.\n\n대부분 보고가 테넌트별이라면 쿼리가 단순합니다. 특정 테넌트의 테이블만 읽으면 되므로 지속적으로 필터링할 필요가 없습니다. 이 모델은 또한 일부 테넌트에 추가 테이블이나 커스텀 컬럼이 필요한 "특수" 테넌트를 지원하기도 쉽습니다.\n\n스키마 단점은 전체 테넌트를 아우르는 집계 보고입니다. 여러 스키마를 쿼리할 수 있는 보고 레이어가 필요하거나 공통 스키마에 요약 테이블을 유지해야 합니다.\n\n일반적 패턴:\n\n- 테넌트별 대시보드는 해당 테넌트 스키마만 쿼리\n- 각 테넌트에서 야간 집계를 수행해 중앙 분석 스키마에 적재\n- 테넌트 데이터를 웨어하우스 친화 형식으로 복사하는 내보내기 작업\n\n성능은 보통 테넌트 수준 워크로드에 대해서 양호합니다. 인덱스는 테넌트별로 작아지고 한 스키마의 과도한 쓰기가 다른 스키마에 미치는 영향이 적습니다. 단점은 운영 오버헤드: 새 테넌트를 프로비저닝하면 스키마 생성, 마이그레이션 실행, 모델 변경 시 모든 스키마 정렬이 필요합니다.\n\n테넌트별 맞춤이 필요하거나 많은 데이터베이스를 운영하고 싶지 않은데 더 강한 격리가 필요할 때 스키마는 좋은 선택입니다.\n\n## 접근법 3: 테넌트별 별도 데이터베이스\n\n테넌트별 별도 데이터베이스는 각 고객에게 전용 데이터베이스(또는 같은 서버의 별도 데이터베이스)를 제공합니다. 가장 격리가 강한 옵션으로, 한 테넌트의 데이터가 손상되거나 설정이 틀리거나 부하가 과도해도 다른 테넌트로 전파될 가능성이 낮습니다.\n\n규제 환경(의료, 금융, 정부)이나 엄격한 분리, 맞춤 보존 규칙, 전용 성능을 기대하는 엔터프라이즈 고객에 적합합니다.\n\n온보딩은 프로비저닝 워크플로가 됩니다. 신규 테넌트가 가입하면 시스템은 데이터베이스를 생성하거나 복제하고, 기본 스키마(테이블, 인덱스, 제약)를 적용하고, 자격증명을 안전하게 저장하고, API 요청을 올바른 데이터베이스로 라우팅해야 합니다.\n\nAppMaster로 빌드한다면 핵심 설계 선택은 테넌트 디렉터리(테넌트와 DB 연결을 매핑한 중앙 목록)를 어디에 두고 모든 요청이 올바른 연결을 사용하게 할지입니다.\n\n업그레이드와 마이그레이션이 주요 트레이드오프입니다. 스키마 변경은 더 이상 "한 번 실행"이 아니라 "모든 테넌트에 대해 실행"해야 합니다. 따라서 팀은 종종 스키마 버전을 관리하고 테넌트별로 진행 상황을 추적하는 제어된 작업으로 마이그레이션을 실행합니다.\n\n장점은 제어입니다. 대형 테넌트부터 먼저 마이그레이션해 성능을 관찰한 뒤 점진적으로 변경을 롤아웃할 수 있습니다.\n\n## 분리 DB의 보고 및 성능\n\n별도 DB는 사고 이해가 가장 쉽습니다. 우발적 크로스-테넌트 읽기가 발생할 가능성이 낮고 권한 실수는 보통 한 테넌트에만 영향을 줍니다.\n\n성능 장점도 큽니다. 무거운 쿼리, 대량 임포트, 테넌트 A의 과도한 리포트가 테넌트 B를 늦추지 않습니다. 시끄러운 이웃 보호가 강하고 테넌트별 리소스 튜닝도 가능합니다.\n\n단점은 보고에서 드러납니다. 모든 테넌트 합계 분석은 가장 어렵습니다. 실무에서 통하는 패턴으로는 핵심 이벤트나 테이블을 중앙 보고 DB로 복사하거나, 이벤트를 웨어하우스로 전송하거나, 테넌트별 보고를 실행해 결과를 합산(테넌트 수가 적을 때)하는 방법 등이 있습니다.\n\n운영 비용도 큽니다. 데이터베이스 수가 많아지면 백업, 업그레이드, 모니터링, 사고 대응이 늘고, 각 테넌트마다 커넥션 풀을 두면 연결 한계에 빨리 도달할 수 있습니다.\n\n## 데이터 유출이나 골칫거리를 일으키는 흔한 실수\n\n대부분의 다중 테넌트 문제는 "대규모 설계 실패"가 아닙니다. 작은 누락이 보안 버그, 지저분한 보고, 값비싼 정리로 성장하는 경우가 많습니다. 다중 테넌시는 나중에 붙이는 기능이 아니라 습관으로 다뤄질 때 작동합니다.\n\n흔한 유출은 조인 테이블(user_roles, invoice_items, 태그 등)에서 테넌트 필드를 빼먹는 경우입니다. 겉으로는 아무 문제 없어 보이지만 보고나 검색이 그 테이블을 통해 조인하면 다른 테넌트의 행을 끌어옵니다.\n\n또 다른 문제는 관리자 대시보드가 테넌트 필터를 우회하는 것입니다. 보통은 "지원용으로만" 시작했다가 재사용되면서 문제가 됩니다. 노코드 도구도 위험을 바꾸지 않습니다: 모든 쿼리, 비즈니스 프로세스, 엔드포인트는 동일한 테넌트 범위를 가져야 합니다.\n\nID도 함정입니다. 테넌트 간에 공유되는 사람이 읽기 쉬운 ID(예: order_number = 1001)를 전역 고유로 가정하면 지원 도구와 통합이 레코드를 섞어버립니다. 테넌트 범위 식별자를 내부 기본 키와 분리하고 조회 시 테넌트 컨텍스트를 포함하세요.\n\n마지막으로 팀은 확장 시 마이그레이션과 백업을 과소평가합니다. 10개 테넌트로는 쉬운 일이 1,000개가 되면 느리고 위험해집니다.\n\n대부분의 고통을 예방하는 빠른 점검 목록:\n\n- 모든 테이블(조인 테이블 포함)에 테넌트 소유권을 명시\n- 하나의 테넌트 스코핑 패턴을 정하고 모든 곳에서 재사용\n- 보고와 내보내기는 테넌트 스코프 없이는 실행할 수 없게(진정한 글로벌인 경우 제외)\n- API와 지원 도구에서 테넌트가 애매한 식별자는 피함\n- 복원 및 마이그레이션 절차를 성장 후가 아니라 초기부터 연습\n\n예: 지원 담당자가 "invoice 1001"을 검색해 잘못된 테넌트를 불러오는 경우는 작은 버그지만 큰 영향을 줍니다.\n\n## 확장 시나리오 예: 첫 고객부터 확장까지\n\n20명 규모 회사가 고객 포털(인보이스, 티켓, 간단한 대시보드)을 출시한다고 합시다. 첫 달에 10개 테넌트를 예상하고, 1년 내 1,000개로 성장할 계획입니다.\n\n초기에는 대부분의 경우 모든 고객 데이터 테이블에 tenant_id를 두는 단일 DB 모델이 가장 단순합니다. 빠르게 빌드할 수 있고 보고가 쉬우며 설정 중복을 피할 수 있습니다.\n\n10개일 때 가장 큰 위험은 성능이 아니라 권한입니다. 작은 필터 누락(예: tenant_id를忘れた "list invoices" 쿼리)이 데이터를 유출할 수 있습니다. 팀은 테넌트 검사를 한 곳(공유 비즈니스 로직 또는 재사용 가능한 API 패턴)에서 강제하고 테넌트 스코핑을 비협상으로 다뤄야 합니다.\n\n10에서 1,000으로 이동하면서 요구사항이 바뀝니다. 보고가 더 무거워지고 지원 요청으로 "이 테넌트의 전체 내보내기"가 필요해지며 몇몇 큰 테넌트가 트래픽을 지배해 공유 테이블을 느리게 만듭니다.\n\n실용적 업그레이드 경로 예시:\n\n1) 동일한 앱 로직과 권한 규칙을 유지하되 고부하 테넌트를 분리 스키마로 이동\n2) 가장 큰 테넌트(또는 규정 준수 고객)는 별도 데이터베이스로 이동\n3) 모든 테넌트에서 읽는 공유 보고 레이어를 유지하고 무거운 보고는 비사용 시간에 스케줄 실행\n\n오늘 안전하게 데이터를 분리할 수 있는 가장 단순한 모델을 선택하고, "소수의 대형 테넌트" 문제를 위해 마이그레이션 경로를 계획하세요. 처음부터 그걸 최적화하려고 하지 마세요.\n\n## 다음 단계: 모델을 선택하고 노코드 백엔드에서 프로토타입하기\n\n보호해야 할 우선순위(데이터 격리, 운영 단순성, 테넌트별 확장성)를 기준으로 선택하세요. 자신감은 작은 프로토타입을 만들고 실제 권한·보고 케이스로 깨보는 데서 옵니다.\n\n간단한 시작 가이드:\n\n- 대부분 테넌트가 작고 단순한 크로스-테넌트 보고가 필요하면 모든 행에 tenant_id를 두고 시작하세요.\n- 더 강한 분리가 필요하지만 여전히 하나의 DB로 관리하고 싶다면 테넌트별 분리 스키마 고려\n- 규정 준수나 전용 성능이 필요하면 테넌트별 별도 데이터베이스 고려\n\n빌드 전에 테넌트 경계를 평이한 언어로 작성하세요. 역할(owner, admin, agent, viewer)을 정의하고 각 역할이 무엇을 할 수 있는지, 그리고 "글로벌" 데이터(플랜, 템플릿, 감사 로그)가 무엇인지 정하세요. 보고가 어떻게 작동할지 결정하세요: 테넌트별만 허용할지, 내부 직원용 "모든 테넌트" 보기를 허용할지.\n\nAppMaster를 사용하는 경우 이러한 패턴을 빠르게 프로토타입할 수 있습니다: Data Designer에서 테이블을 모델링( tenant_id, 고유 제약, 쿼리가 의존하는 인덱스 포함)하고 Business Process Editor에서 규칙을 강제해 모든 읽기/쓰기가 테넌트 스코프를 유지하도록 하세요. 참고로 AppMaster는 appmaster.io에 있습니다.\n\n실용적 최종 테스트: 두 개의 테넌트(A와 B)를 만들고 비슷한 사용자와 주문을 추가한 뒤 동일한 흐름을 양쪽에서 실행하세요. 테넌트 A의 보고서를 내보내고 의도적으로 테넌트 B의 ID를 같은 엔드포인트에 전달해 보세요. 프로토타입은 그런 시도가 항상 실패하고 핵심 보고서가 현실적 데이터 크기에서 빠르게 실행될 때만 "충분히 안전"하다고 볼 수 있습니다.