인베스트리 투자조합 관리 ERP, Athena 정보보호관리 시스템, Lotus Soft 창업사관학교 지원 플랫폼. 세 가지 모두 B2B SaaS 프로젝트입니다. B2B SaaS를 개발하면서 반복적으로 마주치는 공통 과제들을 정리합니다.
B2B SaaS가 B2C 앱과 다른 점
B2C 앱은 “일반 사용자 한 명”을 위한 서비스입니다. 회원가입하면 바로 쓸 수 있고, 데이터는 내 것입니다.
B2B SaaS는 다릅니다. “기업 조직”이 사용하고, 조직 내에 여러 역할의 사용자가 있으며, 기업마다 데이터가 철저히 분리되어야 합니다.
이 차이가 설계의 핵심 복잡성을 만듭니다.
핵심 설계 1 — 멀티테넌트 아키텍처
SaaS의 가장 중요한 설계 개념입니다. 하나의 플랫폼을 여러 기업(테넌트)이 공유하되, 각 기업의 데이터는 완전히 분리되어야 합니다.
Lotus Soft의 경우: 슈퍼 어드민(플랫폼 전체 관리), 서브 어드민(창업사관학교), 테넌트(입주 스타트업) 3계층으로 나뉩니다. 각 레이어가 볼 수 있는 데이터와 할 수 있는 작업이 다릅니다.
인베스트리의 경우: GP(업무집행조합원)별로 독립적인 ERP 공간을 가집니다. A GP의 데이터는 B GP가 절대 볼 수 없어야 합니다.
멀티테넌트 구현 방식은 크게 세 가지입니다:
- 데이터베이스 분리: 테넌트별로 별도 DB. 격리성 최고, 비용 높음.
- 스키마 분리: 같은 DB, 테넌트별 스키마. 중간 수준.
- 행 수준 분리: 같은 테이블, 테넌트 컬럼으로 필터. 비용 낮음, 격리 구현 주의 필요.
규모와 보안 요구사항에 따라 방식을 선택해야 합니다.
핵심 설계 2 — 권한 관리 시스템 (RBAC)
Role-Based Access Control. 역할에 따라 접근 권한을 부여하는 방식입니다.
예를 들어 Athena 정보보호관리 시스템에서:
- 슈퍼 어드민: 모든 기업 데이터 접근, 시스템 설정 변경
- 기업 어드민: 자사 데이터만 접근, 부서원 계정 관리
- 일반 사용자: 자신의 업무 영역만 접근, 입력 가능
권한 시스템을 처음부터 잘 설계하지 않으면, 나중에 “이 메뉴는 이 사람만 봐야 하는데…”라는 요청이 올 때마다 전체 코드를 손봐야 합니다.
핵심 설계 3 — 복잡한 데이터 구조 시각화
B2B SaaS는 복잡한 데이터를 다룹니다. 인베스트리의 경우 투자조합 → 피투자조합 → 투자 내역 → 관련 서류로 이어지는 계층 구조가 있습니다.
이 복잡성을 사용자가 쉽게 이해하고 작업할 수 있도록 UI/UX를 설계하는 것이 가장 큰 도전이었습니다.
핵심 원칙:
- 현재 어디 있는지 항상 알 수 있도록 (브레드크럼, 사이드바 강조)
- 가장 자주 하는 작업을 가장 적은 클릭으로
- 대용량 데이터를 페이지 속도 저하 없이 표시
핵심 설계 4 — 기존 업무 방식 디지털화
Athena는 윈도우 설치 프로그램으로 운영되던 것을 웹으로 전환한 프로젝트입니다. 엑셀 형식의 데이터를 웹에 연동하고, 입력값을 자동으로 문서화·시각화합니다.
“기존에 엑셀로 하던 걸 그대로 웹으로”라는 요청은 생각보다 많습니다. 이때 주의할 점은 엑셀의 유연성을 과도하게 따라가려 하면 안 된다는 것입니다. 웹 서비스는 엑셀이 아닙니다. 엑셀보다 편리한 특정 작업 흐름을 설계하고, 데이터 시각화로 부가가치를 더하는 것이 맞습니다.
핵심 설계 5 — 온보딩과 사용 지원
B2B SaaS는 “쓰기 어렵다”는 평가를 받으면 바로 이탈입니다. 특히 기존 방식(엑셀, 설치 프로그램)을 쓰던 사람들에게 새로운 시스템은 거부감을 줍니다.
설계 포인트:
- 첫 로그인 후 단계별 가이드 (온보딩 투어)
- 자주 하는 작업에 대한 툴팁
- 도움말 문서 또는 인앱 가이드
- 이전 방식 대비 어떻게 편리해졌는지 명확히 보여주기
수익화 모델 설계
SaaS의 과금 모델은 크게 세 가지입니다.
사용자 수 기반: 월 활성 사용자(MAU) 또는 시트 수에 따라 과금. 가장 일반적.
기능 티어 기반: Free/Pro/Enterprise로 나눠 기능 범위로 과금. Lotus Soft처럼 계정 유료화 버전에 따라 기능이 달라지는 구조.
사용량 기반: API 호출 수, 처리량 등에 따라 과금. AI 기능이 있는 서비스에 적합.
마치며
B2B SaaS의 성공 요건은 단순합니다. “담당자가 매일 열게 되는 도구” 가 되어야 합니다. 매일 쓰게 되면 전환 비용이 높아지고, 전환 비용이 높아지면 장기 계약이 됩니다.
그러려면 기술적 완성도보다 업무 플로우에 얼마나 잘 맞아떨어지는가가 더 중요합니다. 개발 전에 “이 서비스를 쓸 사람이 하루에 어떻게 일하는가”를 깊이 이해하는 시간이 반드시 필요합니다.