B2B SaaS 개발, 기업·관리자·직원 계정 구조에서 달라지는 것

B2B SaaS를 개발할 때 일반 회원가입 기능만 생각하고 시작하는 경우가 있습니다.

사용자가 이메일로 가입하고 로그인한 뒤 서비스를 이용하면 되는 구조처럼 보일 수 있습니다.

하지만 기업 고객이 사용하는 SaaS라면 한 명의 사용자와 하나의 계정만으로 설명하기 어렵습니다.

• 하나의 기업에 여러 직원이 소속될 수 있습니다.
• 기업마다 관리자가 따로 필요할 수 있습니다.
• 직원별로 사용할 수 있는 기능이 다를 수 있습니다.
• 기업 단위로 요금제와 사용량을 관리할 수 있습니다.
• 퇴사자와 부서 이동을 처리해야 할 수 있습니다.
• 기업별 데이터가 서로 섞이지 않아야 합니다.
• 서비스 운영자는 모든 기업을 관리해야 합니다.

따라서 B2B SaaS 개발 비용은 화면 수보다 기업·사용자·권한·결제·데이터를 어떤 관계로 설계하는지에 따라 크게 달라집니다.

일반 회원 서비스와 B2B SaaS의 차이

일반적인 B2C 서비스는 사용자 한 명이 하나의 계정을 가지고 자기 데이터를 관리하는 구조로 시작할 수 있습니다.

사용자
→ 요금제
→ 결제
→ 개인 데이터

B2B SaaS는 다음과 같은 구조가 필요할 수 있습니다.

기업
→ 기업 관리자
→ 팀 관리자
→ 직원
→ 기업별 요금제
→ 기업별 사용량
→ 기업별 데이터

사용자 한 명이 여러 기업에 속할 수도 있고, 하나의 기업 안에서 역할이 달라질 수도 있습니다.

기본 데이터 구조

B2B SaaS에서는 일반적으로 다음 개체를 구분해서 생각할 수 있습니다.

1. 기업

서비스를 계약하고 사용하는 조직입니다.

관리할 수 있는 정보:

• 기업명
• 사업자등록번호
• 대표자
• 담당자
• 연락처
• 주소
• 계약 상태
• 요금제
• 결제 방식
• 이용 시작일
• 이용 종료일
• 직원 수
• 기업 설정

2. 사용자

서비스에 로그인하는 실제 사람입니다.

• 이름
• 이메일
• 휴대폰
• 비밀번호
• 최근 로그인
• 계정 상태
• 개인 설정

3. 기업 소속

사용자와 기업의 관계를 저장합니다.

사용자 A
→ 기업 1의 관리자
→ 기업 2의 일반 직원

사용자 정보와 기업 소속 정보를 분리하면 한 사용자가 여러 기업에 참여하는 구조를 지원하기 쉽습니다.

4. 역할과 권한

기업 안에서 사용자가 무엇을 할 수 있는지 정의합니다.

• 기업 소유자
• 기업 관리자
• 팀 관리자
• 일반 직원
• 열람 전용 사용자
• 결제 담당자

5. 서비스 운영 관리자

SaaS를 제공하는 회사의 관리자입니다.

• 전체 기업 관리
• 요금제
• 결제
• 사용량
• 문의
• 장애
• 계정 정지
• 관리자 지원

기업 고객의 관리자와 서비스 운영 관리자는 서로 다른 역할입니다.

기업 계정 생성 방식

1. 사용자가 기업을 직접 생성

일반적인 SaaS 가입 흐름입니다.

사용자 회원가입
→ 기업명 입력
→ 기업 생성
→ 생성자가 기업 소유자 역할 획득
→ 직원 초대

초기 스타트업과 중소기업 대상 서비스에 적합할 수 있습니다.

2. 운영자가 기업을 생성

계약이 완료된 기업만 사용할 수 있는 서비스에서 활용할 수 있습니다.

영업 계약
→ 운영자가 기업 계정 생성
→ 기업 관리자 초대
→ 직원 등록

기업별 계약 금액과 기능이 다른 경우에 적합할 수 있습니다.

3. 기업 관리자가 가입 신청

기업 관리자 가입 신청
→ 사업자 정보 제출
→ 서비스 운영자 검토
→ 승인
→ 기업 계정 활성화

가입 대상과 기업 정보를 확인해야 하는 서비스에서 사용할 수 있습니다.

4. 회사 도메인으로 자동 연결

특정 이메일 도메인을 기준으로 기업 소속을 판단할 수 있습니다.

user@company.com 가입
→ company.com 도메인 확인
→ 기존 기업 가입 요청

주의할 점:

• 공용 이메일
• 계열사
• 여러 도메인
• 외부 계약직
• 이메일 도메인 변경
• 허가 없이 자동 소속되는 문제

자동 가입보다 기업 관리자 승인 절차를 함께 사용하는 것이 안전할 수 있습니다.

기업 관리자

기업 관리자는 자기 조직의 사용자를 운영합니다.

가능한 기능:

• 직원 초대
• 직원 삭제
• 직원 역할 변경
• 팀 관리
• 기업 설정
• 사용량 확인
• 요금제 확인
• 결제수단 관리
• 기업 통계
• 파일과 데이터 관리

기업 관리자가 모든 데이터를 볼 수 있는지, 직원 개인 데이터는 제한할지 정해야 합니다.

기업 소유자와 관리자를 구분할까?

기업 소유자는 계약과 결제, 기업 삭제처럼 중요한 권한을 가질 수 있습니다.

기업 소유자

• 결제
• 요금제
• 기업 삭제
• 소유권 이전
• 모든 관리자 권한

기업 관리자

• 직원
• 팀
• 콘텐츠
• 일반 설정
• 통계

기업 소유자가 퇴사하거나 연락이 끊기는 경우를 대비해 소유권 이전 기능이 필요할 수 있습니다.

직원 초대

B2B SaaS에서 자주 필요한 기능입니다.

일반적인 흐름:

기업 관리자가 이메일 입력
→ 초대 메일 발송
→ 사용자가 초대 링크 클릭
→ 회원가입 또는 로그인
→ 기업 소속 등록

정해야 할 항목:

• 초대 링크 유효기간
• 이미 가입된 사용자
• 가입되지 않은 사용자
• 중복 초대
• 초대 취소
• 초대 재발송
• 초대 시 역할 지정
• 요금제 인원 제한
• 허용 이메일 도메인

대량 직원 등록

직원이 많은 기업은 한 명씩 초대하기 어려울 수 있습니다.

엑셀 업로드 항목:

• 이름
• 이메일
• 부서
• 직책
• 역할
• 사번

필요 기능:

• 양식 다운로드
• 컬럼 검증
• 중복 이메일
• 이미 가입된 사용자
• 잘못된 역할
• 일부 성공·실패
• 결과 파일
• 초대 이메일 발송 여부

조직과 팀

기업 안에서 부서와 팀을 관리할 수 있습니다.

기업
→ 본부
→ 부서
→ 팀
→ 직원

필요 기능:

• 조직 생성
• 상위 조직
• 팀 관리자
• 직원 이동
• 조직별 데이터
• 조직별 통계
• 조직 삭제

조직 단계가 기업마다 다르면 고정된 본부·부서·팀보다 유연한 계층 구조가 필요할 수 있습니다.

역할 기반 권한

역할에 따라 접근 가능한 기능을 정합니다.

역할만으로 충분하지 않다면 권한을 세부적으로 나눌 수 있습니다.

회원 조회
회원 초대
회원 삭제
결제 조회
결제 수정
파일 다운로드
통계 조회
설정 변경

사용자별 맞춤 권한

기업 관리자가 직원별로 권한을 직접 조합하도록 만들 수도 있습니다.

자유도는 높지만 다음 문제가 생길 수 있습니다.

• 권한 설정이 복잡함
• 잘못된 권한 부여
• 고객 지원 증가
• 권한 조합 테스트 증가
• 관리자 인수인계 어려움

초기에는 정해진 역할 몇 개로 시작하는 편이 운영하기 쉬울 수 있습니다.

기업별 데이터 분리

B2B SaaS에서 가장 중요한 요소 중 하나입니다.

기업 A의 사용자는 기업 B의 데이터를 볼 수 없어야 합니다.

분리 대상:

• 프로젝트
• 문서
• 파일
• 사용자
• 고객
• 통계
• 결제
• AI 생성 결과
• 설정

화면에서 다른 기업 데이터를 숨기는 것만으로는 부족합니다.

서버에서 모든 데이터 요청마다 사용자의 기업 소속과 권한을 확인해야 합니다.

URL 직접 접근

사용자가 다른 기업 데이터의 주소를 직접 입력할 수 있습니다.

/company-a/project/100
/company-b/project/101

버튼을 숨겼더라도 서버 권한 검사가 없으면 데이터가 노출될 수 있습니다.

한 사용자의 여러 기업 소속

컨설턴트와 대행사, 여러 법인을 운영하는 사용자는 여러 기업에 속할 수 있습니다.

필요 기능:

• 현재 기업 전환
• 기업별 역할
• 기업별 알림
• 기업별 결제
• 마지막 사용 기업
• 기업별 데이터 완전 분리

화면 상단에서 현재 선택한 기업을 명확하게 보여주는 것이 좋습니다.

기업 전환

현재 기업: 카멜레온컴퍼니

[기업 변경]
- 기업 A
- 기업 B
- 개인 작업공간

기업을 전환한 뒤 이전 기업의 데이터가 캐시에 남거나 섞이지 않도록 확인해야 합니다.

개인 작업공간

사용자가 기업에 가입하기 전 개인 공간을 제공할 수 있습니다.

개인 작업공간
→ 기업 초대 수락
→ 개인 데이터를 기업으로 이전

개인과 기업 데이터의 소유권과 이전 조건을 정해야 합니다.

직원 퇴사

기업 관리자가 직원의 접근을 제거할 수 있어야 합니다.

정해야 할 내용:

• 즉시 로그인 차단
• 기업 소속만 제거
• 개인 계정은 유지
• 직원이 만든 데이터의 소유
• 담당 프로젝트 이전
• 파일
• 활동 이력
• 결제 좌석 감소
• 재초대

퇴사자의 작업물을 함께 삭제하면 기업 데이터가 손실될 수 있습니다.

일반적으로 기업에서 생성한 데이터는 기업에 남기고 사용자 접근만 제거하는 방식이 필요할 수 있습니다.

직원 이동

직원이 다른 팀이나 기업으로 이동할 수 있습니다.

• 팀 이동
• 역할 변경
• 담당 업무 변경
• 기존 데이터 접근
• 통계 반영
• 변경 이력

기업 소유권 이전

기업 소유자가 퇴사할 수 있습니다.

흐름 예시:

현재 소유자
→ 새 소유자 선택
→ 본인 확인
→ 소유권 이전
→ 이메일 안내

운영 관리자가 지원 요청을 통해 소유권을 변경할 수도 있습니다.

중요한 변경이므로 이력과 승인 절차가 필요할 수 있습니다.

기업 요금제

B2B SaaS의 요금제는 다음 기준으로 구성할 수 있습니다.

• 직원 수
• 관리자 수
• 저장 용량
• 프로젝트 수
• AI 사용량
• API 호출량
• 기능
• 고객사 수
• 월간·연간

좌석 기반 요금

사용 가능한 직원 수를 기준으로 과금합니다.

예시:

베이직: 최대 5명
프로: 최대 20명
엔터프라이즈: 별도 협의

확인할 조건:

• 초대 대기 사용자도 좌석에 포함하는가?
• 정지 회원은 포함하는가?
• 월 중간에 좌석을 추가하면 어떻게 과금하는가?
• 삭제한 직원의 좌석은 즉시 복구되는가?
• 읽기 전용 사용자는 별도인가?

사용량 기반 요금

• 생성 횟수
• 파일 용량
• 처리 데이터
• API 호출
• 메시지
• 다운로드

기업 전체 사용량과 직원별 사용량을 함께 확인할 수 있습니다.

기업별 계약 요금

대기업과 기관은 공개 요금제가 아니라 별도 계약으로 운영할 수 있습니다.

관리 항목:

• 계약 금액
• 계약 기간
• 기능
• 사용자 수
• 결제 방식
• 갱신일
• 담당 영업자
• 특약
• 관리자 메모

카드결제와 수동 계약

카드 정기결제

• 월간·연간
• 자동 갱신
• 결제 실패
• 해지
• 요금제 변경

수동 계약

• 견적서
• 세금계산서
• 계좌이체
• 계약 기간
• 운영자 수동 활성화

두 방식을 함께 지원할 수도 있습니다.

기업별 기능 설정

계약에 따라 특정 기능만 활성화할 수 있습니다.

• AI 기능
• API
• 고급 통계
• SSO
• 데이터 다운로드
• 외부 연동
• 전용 브랜딩

운영자가 기업별 기능을 켜고 끌 수 있게 만들 수 있습니다.

기업별 설정

기업 관리자가 변경할 수 있는 정보:

• 기업명
• 로고
• 대표 색상
• 이메일 발신명
• 시간대
• 언어
• 알림
• 기본 권한
• 보안 정책
• 데이터 보관 기간

화이트라벨 SaaS라면 도메인과 화면 브랜딩까지 달라질 수 있습니다.

SSO

대기업은 기존 회사 계정으로 로그인하기를 원할 수 있습니다.

• Google Workspace
• Microsoft Entra ID
• SAML
• 기타 기업 인증

SSO 연동에서는 다음을 정해야 합니다.

• 기업별 설정
• 자동 사용자 생성
• 역할 매핑
• 퇴사자 차단
• 일반 로그인 허용 여부
• 여러 도메인
• 테스트 환경

기업별 보안 요구

기업 고객이 다음을 요청할 수 있습니다.

• 비밀번호 정책
• 2단계 인증
• IP 제한
• 접속 로그
• 관리자 변경 이력
• 파일 다운로드 제한
• 세션 만료
• 데이터 삭제
• 특정 지역 서버
• 보안 점검 자료

모든 고객의 요구를 처음부터 지원하기보다 목표 고객에 필요한 기준부터 정하는 것이 좋습니다.

기업 관리자 대시보드

확인할 수 있는 정보:

• 활성 직원
• 초대 대기
• 요금제
• 사용량
• 저장 용량
• 결제
• 팀별 활동
• 최근 작업
• 이용 한도

서비스 운영 관리자

SaaS 제공 회사의 관리 기능입니다.

기업 관리

• 기업 목록
• 계약 상태
• 요금제
• 직원 수
• 이용 시작·종료
• 정지
• 메모

기업 상세

• 관리자
• 직원
• 결제
• 사용량
• 문의
• 최근 활동
• 오류
• 기능 설정

사용자 지원

기업 고객의 요청을 처리할 수 있습니다.

• 직원 초대 문제
• 소유권 이전
• 결제 오류
• 사용량 보상
• 계정 정지 해제
• 데이터 복구

관리자가 고객 계정으로 대신 로그인하는 기능은 편리할 수 있지만 보안과 개인정보 문제가 있으므로 접근 조건과 이력을 엄격하게 관리해야 합니다.

감사 로그

중요한 변경을 기록합니다.

• 직원 초대·삭제
• 역할 변경
• 기업 설정
• 결제
• 파일 다운로드
• 데이터 삭제
• 관리자 접근

저장할 정보:

• 사용자
• 기업
• 행동
• 대상
• 시각
• 변경 전·후
• 접속 정보

기업별 통계

• 활성 사용자
• 기능 사용량
• 프로젝트 수
• 생성 건수
• 저장 용량
• 기간별 변화
• 팀별 사용량

통계가 요금과 연결되면 계산 기준을 명확하게 정해야 합니다.

알림

기업 관리자에게 보낼 수 있는 알림:

• 직원 초대 수락
• 좌석 한도 도달
• 사용량 한도
• 결제 실패
• 계약 만료
• 보안 알림
• 중요한 데이터 변경

직원에게 보낼 수 있는 알림:

• 기업 초대
• 역할 변경
• 담당 업무
• 관리자 공지
• 서비스 결과

개인정보와 데이터 소유

B2B SaaS에서는 사용자 개인과 기업 중 누가 데이터의 운영 주체인지 명확히 정해야 합니다.

검토할 내용:

• 직원이 생성한 데이터
• 퇴사 후 데이터
• 기업 계약 종료
• 데이터 다운로드
• 데이터 삭제
• 백업 보관
• 기업 관리자 접근 범위
• 서비스 운영자 접근 범위

구체적인 법적 정책은 사업과 데이터 성격에 맞게 전문가의 검토를 받는 것이 안전합니다.

기업 계약 종료

계약이 끝나면 다음 처리가 필요할 수 있습니다.

계약 종료 예정
→ 관리자 안내
→ 데이터 다운로드 기간
→ 서비스 접근 제한
→ 데이터 보관
→ 최종 삭제

즉시 삭제할지 일정 기간 보관할지 정책을 정해야 합니다.

개발 비용을 결정하는 요소

MVP로 시작하는 방법

1단계

• 기업 생성
• 기업 관리자
• 직원 이메일 초대
• 관리자·직원 역할
• 기업별 데이터 분리
• 기본 요금제
• 운영 관리자

2단계

• 팀과 부서
• 역할 세분화
• 기업 통계
• 좌석 과금
• 감사 로그
• 계약 종료 처리

3단계

• SSO
• 기업별 기능
• 화이트라벨
• API
• 고급 보안
• 여러 기업 소속

기업 회원이 핵심이라면 개인 서비스로 먼저 만든 뒤 나중에 억지로 조직 구조를 추가하기보다 초기 데이터 설계부터 기업을 고려하는 것이 좋습니다.

요구사항 양식

서비스 목적:
주요 기업 고객:
기업 가입 방식:
기업 승인:
기업 관리자:
기업 소유자:
직원 초대:
대량 등록:
사용자 역할:
팀·부서:
한 사용자의 여러 기업 소속:
기업별 데이터:
요금제:
좌석 기준:
사용량 기준:
카드결제·수동 계약:
기업별 기능:
SSO:
감사 로그:
계약 종료:
데이터 다운로드:
관리자 기능:
예상 기업 수:
기업당 예상 직원 수:

검수 체크리스트

[ ] 기업 생성
[ ] 기업 관리자
[ ] 직원 초대
[ ] 초대 만료
[ ] 중복 초대
[ ] 역할 변경
[ ] 팀 이동
[ ] 직원 삭제
[ ] 퇴사자 접근 차단
[ ] 기업별 데이터 분리
[ ] 다른 기업 URL 접근 차단
[ ] 기업 전환
[ ] 좌석 한도
[ ] 사용량 제한
[ ] 결제 실패
[ ] 계약 종료
[ ] 운영 관리자
[ ] 감사 로그
[ ] 모바일

견적서에서 확인할 항목

• 일반 회원 기능만 포함되는가?
• 기업과 사용자 데이터가 분리되어 있는가?
• 직원 초대와 대량 등록이 포함되는가?
• 역할별 권한이 서버에도 적용되는가?
• 기업별 요금제와 좌석 수가 포함되는가?
• 퇴사자와 소유권 이전이 포함되는가?
• 운영 관리자가 기업별 상태를 확인할 수 있는가?
• 기업별 사용량과 통계가 포함되는가?
• SSO와 기업별 기능 설정은 별도인가?
• 계약 종료 후 데이터 처리 기능이 포함되는가?

마무리

B2B SaaS의 핵심은 일반 회원 기능에 회사명 입력칸을 추가하는 것이 아닙니다.

다음 구조를 함께 설계해야 합니다.

• 기업과 사용자 관계
• 기업 관리자와 직원 역할
• 기업별 데이터 분리
• 직원 초대와 퇴사 처리
• 요금제와 좌석
• 기업 고객 운영 관리자
• 계약 종료와 데이터 처리

기업 구조가 서비스의 핵심이라면 초기 MVP부터 최소한의 기업·관리자·직원 관계를 반영하는 것이 좋습니다.