여러 지점이 한 시스템을 쓴다면, 견적은 왜 달라질까요 | 확인할 5가지
가맹점·지점이 늘어날 서비스는 데이터를 가르는 방식부터 다르게 설계해요. 테넌트 ID 컬럼 하나로 필터링하는 방식과 DB를 물리적으로 분리하는 방식은 보안 수준과 비용이 크게 갈려요. 발주 전 확인할 5가지를 정리했어요.
핵심 요약 — 지점·가맹점이 여러 개인 서비스는 데이터를 어떻게 가르느냐부터 설계가 갈려요. 테넌트 ID 컬럼으로 구분하는 방식은 빠르지만 필터링을 놓치면 다른 지점 데이터가 노출될 위험이 있고, 데이터베이스를 물리적으로 분리하면 안전하지만 관리 대상이 늘어나요. 실무에서는 둘을 섞은 하이브리드 방식을 많이 씁니다. 발주 전 확인해둘 5가지를 정리했어요.
“본사 하나, 지점 여러 개가 같은 관리자 화면을 쓰게 해주세요.”
프랜차이즈나 여러 지점을 운영하는 서비스에서 자주 나오는 요청이에요. 화면 자체는 지점이 하나일 때와 비슷해 보이는데, 견적을 받아보면 생각보다 커요. 원인은 화면이 아니라 데이터를 가르는 방식에 있어요.
1. 지점 하나 늘 때마다 뭐가 달라지나요
지점이 하나일 때는 “이 데이터가 누구 것인지” 고민할 필요가 없어요. 그런데 지점이 두 개가 되는 순간, A지점 관리자가 로그인했을 때 B지점 데이터가 절대 보이면 안 된다는 조건이 하나 생겨요.
이 조건은 화면 하나에만 걸리지 않아요. 주문 목록, 회원 목록, 통계, 알림까지 시스템 안의 모든 조회와 저장에 “어느 지점 것인지”를 확인하는 절차가 깔려요. 지점 수가 늘어날수록 새로 추가되는 화면이 아니라, 기존 화면 하나하나에 붙는 확인 절차가 견적을 밀어 올려요.
2. 데이터를 가르는 방법, 이 세 가지가 있어요
지점(테넌트)별로 데이터를 나누는 방식은 크게 세 가지예요.
| 방식 | 설명 | 특징 |
|---|---|---|
| 테넌트 ID 컬럼 | 모든 표에 지점 구분 컬럼을 두고 조회 시 필터링 | 구현이 빠르지만 필터를 빠뜨리면 위험 |
| 스키마 분리 | 지점별로 데이터 영역(스키마)을 나눔 | 격리 수준이 높아지지만 관리 대상 증가 |
| 데이터베이스 분리 | 지점별로 데이터베이스 자체를 따로 둠 | 가장 안전하지만 비용·운영 부담이 큼 |
가장 빠른 방법은 테넌트 ID 컬럼 방식이에요. 다만 이 방식은 모든 조회 쿼리에 지점 구분값이 자동으로 들어가도록 강제해야 안전해요. 그렇지 않으면 개발자가 쿼리 하나를 놓쳤을 때 다른 지점의 데이터가 그대로 노출될 수 있어요.
3. 왜 하이브리드로 많이 가나요
스키마나 데이터베이스를 지점별로 완전히 분리하면 안전하긴 한데, 지점이 50개, 100개로 늘어나면 그만큼 관리해야 할 데이터베이스도 늘어나요. 반대로 테넌트 ID 컬럼 방식만 쓰면 비용은 낮지만 실수 위험이 남아요.
그래서 실무에서는 공유 데이터베이스 + 논리적 격리를 기본 구조로 두고, 결제 정보나 개인정보처럼 민감도가 높은 데이터만 별도 저장소로 분리하는 하이브리드 전략을 많이 씁니다. 어떤 데이터를 분리 대상으로 볼지는 서비스 성격에 따라 달라서, 설계 초기에 지점 수 계획(10개인지 1,000개인지)과 함께 정해야 해요. 기능이 늘어날 때마다 무엇을 걷어낼지 판단하는 기준은 SaaS 4종 운영으로 배운 기능 욕심 줄이는 법에서 다룬 원칙과도 이어져요.
4. 지점마다 다른 걸 원하면 어떻게 되나요
“본사는 전체 통계를 봐야 하고, 지점은 자기 데이터만 봐야 해요”까지는 표준적인 요구예요. 그런데 여기서 한 걸음 더 나가 “A지점만 이 기능을 켜주세요”, “B지점은 이 화면 순서를 다르게 해주세요”가 붙기 시작하면 이야기가 달라져요.
지점마다 다른 설정을 허용하려면 권한·기능을 데이터로 관리하는 구조(누가, 무엇을, 어디까지 볼 수 있는지)가 필요해요. 이 부분을 코드에 지점 이름을 직접 박아 처리하면, 지점이 하나 늘 때마다 코드를 다시 배포해야 하는 상황이 생겨요. 권한을 세분화하는 설계 기준은 계정만 나눠주세요가 왜 견적을 키울까요에서 더 다뤘어요.
5. 발주할 때 적으면 좋은 항목
지점·가맹점 시스템을 “관리자 페이지 1식”으로 뭉뚱그리지 말고, 아래를 먼저 정해서 요구사항에 넣어보세요.
| 항목 | 정할 내용 |
|---|---|
| 지점 규모 | 초기 지점 수와 향후 늘어날 규모 예상치 |
| 데이터 격리 방식 | 컬럼 필터링·스키마 분리·DB 분리 중 무엇을 쓸지 |
| 민감 데이터 | 결제·개인정보 등 별도 분리가 필요한 항목 |
| 지점별 커스터마이징 | 지점마다 다른 화면·기능을 허용할지 |
| 본사 권한 범위 | 본사가 전체를 볼 수 있는 범위와 방식 |
이 다섯 줄이 있으면 “지점 관리 기능”이라는 한 단어 안에 무엇이 들어가는지 업체마다 같은 기준으로 비교할 수 있어요.
마무리
지점·가맹점이 여러 개인 시스템은 화면 개수가 아니라 데이터를 가르는 방식에서 견적이 갈려요. 저희는 10년 이상 다양한 규모의 프로젝트를 진행하며 자체 SaaS 4종도 함께 운영해온 개발사예요. 지금 계획 중인 서비스의 지점 수가 늘어날 예정이라면, 데이터 격리 방식부터 먼저 정하는 걸 권해드려요. 지점 확장 구조 상담받기 →
관련 글