직원 20명 사내 시스템, Supabase Micro면 충분할까?

데이터베이스2026년 7월 29일글: 홍서진, Duolabs10분 읽기blog capacity-planning model-openai-gpt-5.5 postgresql supabase technical-note

사내 시스템을 새로 만들 때 인프라를 처음부터 크게 잡아야 할지 고민하게 됩니다. 특히 Supabase Pro를 검토하면 Micro와 Small의 월 비용 차이는 크지 않지만, 어떤 기준으로 선택해야 하는지는 가격표만 보고 판단하기 어렵습니다.

직원 20명 안팎이 사용하는 전자결재, 인사정보, 자산 관리, 공지, 업무 요청 같은 시스템이라면 대체로 Micro로 시작해도 충분합니다. 중요한 것은 전체 직원 수보다 동시에 실행되는 쿼리의 수, 쿼리 복잡도, 배치 작업과 데이터 증가 속도입니다.

이 글에서는 2026년 7월 Supabase 공식 문서를 기준으로 무료 프로젝트 제한, Pro 과금 구조, Micro와 Small의 차이, 실제 운영 판단 기준을 정리합니다. 가격과 제공량은 바뀔 수 있으므로 도입 시점에는 공식 요금표를 다시 확인해야 합니다.

무료 플랜은 활성 프로젝트 2개까지

Supabase Free 플랜은 활성 프로젝트를 최대 2개까지 사용할 수 있습니다. 이 제한은 조직별로 따로 적용되는 것이 아니라, 사용자가 Owner 또는 Admin으로 참여한 모든 무료 조직을 합산해 계산합니다.

예를 들어 무료 조직 하나에 프로젝트 2개를 두거나, 무료 조직 2개에 프로젝트를 하나씩 둘 수 있습니다. 일시 중지된 프로젝트는 이 제한에 포함되지 않으며, 무료 프로젝트는 1주일 동안 활동이 없으면 자동으로 일시 중지될 수 있습니다.

개인 실험이나 개발 환경에는 유용하지만, 매일 사용해야 하는 사내 운영 시스템에는 자동 중지가 없는 Pro 플랜이 더 적합합니다.

Pro는 개수 제한보다 프로젝트별 과금 구조를 봐야 한다

Pro 플랜에는 Free처럼 활성 프로젝트 2개라는 고정 상한이 명시되어 있지 않습니다. 대신 프로젝트마다 전용 Postgres Compute가 배정되고, 프로젝트를 추가할수록 Compute 비용이 늘어납니다.

Pro 기본요금은 월 25달러이며 매월 10달러의 Compute 크레딧이 포함됩니다. 이 크레딧은 기본 Micro 프로젝트 하나의 Compute 비용을 상쇄할 수 있습니다.

기본 Compute만 사용한다고 가정하면 예상 월 비용은 다음과 같습니다.

구성	계산	예상 월 비용
Pro + Micro 1개	$25 + $10 - $10 크레딧	약 $25
Pro + Small 1개	$25 + $15 - $10 크레딧	약 $30
Pro + Micro 2개	$25 + $20 - $10 크레딧	약 $35
Pro + Micro 3개	$25 + $30 - $10 크레딧	약 $45

환율, 세금, 데이터 전송량, 스토리지, Auth 사용량과 부가 기능에 따른 비용은 별도입니다. Compute는 시간 단위로 계산되므로 프로젝트가 월중에 추가되거나 크기가 바뀌면 실제 금액도 달라집니다.

Micro와 Small 사양 비교

두 등급 모두 공유형 2코어를 사용합니다. 가장 큰 차이는 메모리, 권장 데이터베이스 크기와 연결 한도입니다.

항목	Micro	Small
월 Compute 가격	약 $10	약 $15
CPU	공유형 2코어	공유형 2코어
메모리	1GB	2GB
권장 최대 DB 크기	10GB	50GB
직접 DB 연결	60개	90개
Pooler 클라이언트 연결	200개	400개

여기서 권장 최대 DB 크기는 Compute가 원활히 다룰 수 있는 용량에 대한 안내입니다. Pro 플랜에 기본 포함되는 디스크 용량과는 다른 개념입니다. Pro는 프로젝트당 8GB의 디스크를 기본 제공하고, 이를 초과한 사용량은 별도로 과금됩니다.

직원 20명이면 Micro로 충분한 이유

직원이 20명이라고 해서 20개의 DB 연결이 계속 유지되는 것은 아닙니다. Supabase Data API를 사용하는 일반적인 웹 애플리케이션은 요청이 발생할 때 필요한 쿼리를 실행하고 결과를 반환합니다. 실제 부하는 등록된 사용자 수보다 동시 요청과 쿼리 효율에 더 크게 좌우됩니다.

다음과 같은 사내 시스템은 Micro로 시작하기에 적합합니다.

전자결재와 업무 요청
직원·부서·권한 관리
자산과 비품 관리
사내 공지와 간단한 문서 메타데이터
휴가 신청과 일정 관리
일반적인 목록, 검색, 등록, 수정 화면

동시에 접속하는 사람이 몇 명에서 10명 안팎이고, 대부분의 화면이 인덱스를 활용한 짧은 CRUD 쿼리라면 Micro의 1GB 메모리와 연결 한도로도 충분할 가능성이 높습니다.

Small을 고려해야 하는 상황

직원 수가 적어도 다음 작업이 겹치면 Compute 부담이 빠르게 커질 수 있습니다.

수십만 건 이상의 데이터를 한 번에 집계하는 통계 화면
대용량 CSV·엑셀 가져오기와 내보내기
전문 검색이나 벡터 검색
OCR, 문서 분석 결과를 대량으로 저장하는 작업
여러 자동화와 예약 배치의 동시 실행
실시간 구독이 많은 대시보드
복잡한 Row Level Security 정책과 다중 조인
DB 용량이 8GB를 넘어 계속 증가하는 서비스

Small은 월 5달러 정도를 더 내고 메모리와 연결 여유를 두 배 가까이 확보합니다. 업무 중단 비용이 크거나 배치와 보고서가 많은 시스템이라면 처음부터 Small을 선택하는 것도 합리적입니다.

Vercel과 연결할 때 주의할 점

Vercel 같은 서버리스 환경에서는 직원 수보다 연결 방식이 더 중요할 수 있습니다.

Supabase 클라이언트의 Data API를 사용한다면 애플리케이션이 Postgres 직접 연결을 별도로 관리할 필요가 없습니다. Prisma나 Drizzle 같은 ORM으로 Postgres에 연결한다면 서버리스 함수마다 직접 연결을 만들지 말고 Supavisor의 transaction mode를 사용하는 것이 좋습니다.

Transaction pooler는 짧게 실행되는 서버리스 요청이 제한된 DB 연결을 공유하도록 돕습니다. 연결 문자열은 Supabase Dashboard의 Connect 화면에서 확인할 수 있으며, 일반적으로 transaction mode는 6543 포트를 사용합니다. 준비된 문장을 지원하지 않는 제약도 있으므로 ORM 설정을 함께 확인해야 합니다.

운영 후 확인할 지표

처음부터 사양을 크게 잡기보다 실제 사용량을 보고 올리는 편이 비용과 안정성의 균형을 맞추기 쉽습니다. Supabase도 작은 Compute로 시작하고 Dashboard에서 CPU와 메모리를 관찰한 뒤 필요할 때 확장하는 방식을 안내합니다.

운영 초기에는 다음 항목을 확인합니다.

업무 시간대 CPU와 메모리 사용 추세
느린 쿼리와 인덱스 누락
직접 연결과 Pooler 연결 사용량
주요 화면의 응답 시간
배치 실행 중 사용자 화면의 지연 여부
월별 DB와 Storage 증가량

일시적인 CPU 상승만으로 바로 확장할 필요는 없습니다. 높은 메모리 사용, 연결 대기, 반복되는 쿼리 지연이 업무 시간에 지속될 때 Small로 변경하는 것이 좋습니다. Compute 크기 변경에는 짧은 중단이 발생할 수 있으므로 업무 시간을 피해 진행해야 합니다.

성능보다 먼저 챙겨야 할 보안

직원 20명 규모에서는 Compute 성능보다 권한 설계가 더 큰 위험 요소가 되기 쉽습니다.

업무 테이블마다 Row Level Security를 적용합니다.
부서, 직책, 담당 업무에 따라 읽기와 쓰기 권한을 구분합니다.
service role 키는 브라우저에 노출하지 않고 서버 환경 변수로만 관리합니다.
관리자 계정에는 다중 인증을 적용합니다.
퇴직자 계정과 세션을 즉시 회수할 수 있는 절차를 만듭니다.
자동 백업이 있다는 이유로 복구 검증을 생략하지 않습니다.

Pro 플랜은 일일 백업을 7일간 보관하지만, 중요한 사내 데이터라면 별도 내보내기와 복구 훈련도 함께 준비하는 것이 안전합니다.

듀오랩스가 보는 선택 기준

직원 20명 규모의 일반적인 사내 CRUD 시스템이라면 Pro + Micro로 시작하는 선택이 합리적입니다. 실제 부하가 확인되지 않은 상태에서 Small 이상을 먼저 선택하기보다, 쿼리와 권한 구조를 단순하게 설계하고 운영 지표를 기준으로 확장하는 편이 좋습니다.

반대로 복잡한 보고서, 대량 가져오기, 검색과 자동화가 핵심 기능이라면 월 5달러의 차이보다 업무 시간의 안정성이 중요합니다. 이런 경우에는 Small로 시작해 메모리와 연결 여유를 확보하는 것이 낫습니다.

결국 선택 기준은 직원 수 하나가 아닙니다. 동시 사용 패턴, 쿼리 복잡도, 배치 작업, 데이터 증가 속도를 함께 보아야 합니다. 작은 사양에서 측정하고 근거가 생겼을 때 확장하는 것이 가장 현실적인 용량 계획입니다.