20명에서 100명까지, 사내 시스템 배포 아키텍처 설계하기

사내 시스템은 직원 수가 적다고 해서 항상 가볍지 않다. 20명이 쓰는 문서 변환 시스템은 100명이 쓰는 단순 결재 시스템보다 더 많은 CPU와 저장 공간을 요구할 수 있다. 그래서 배포 구조는 인원수보다 동시 접속, 요청 시간, 파일 크기, 실시간 연결 수, 장애 허용 시간을 기준으로 정해야 한다.

먼저 업무를 네 종류로 나눈다

화면과 짧은 API 요청: 로그인, 목록 조회, 결재, 설정 변경

데이터와 권한: 사용자, 조직, 업무 기록, 접근 정책

파일: 첨부 문서, 이미지, 내보내기 결과

오래 걸리는 작업: PDF 생성, 메일 발송, 대량 가져오기, AI 처리

이 구분을 하면 서비스마다 맡길 역할이 선명해진다. 화면과 짧은 API는 Vercel, 데이터와 인증은 Supabase, 파일은 Cloudflare R2나 Amazon S3, 오래 걸리는 작업은 큐와 상시 워커가 맡는 구성이 출발점으로 좋다. 한 서버에 모두 넣는 것보다 장애 범위를 나누기 쉽고, 사용량이 늘 때 필요한 부분만 확장할 수 있다.

권장 기본 구조

영역 | 시작 구성 | 커질 때 먼저 볼 지표
웹과 API | Vercel | 함수 실행 시간, 오류율, 전송량
데이터와 인증 | Supabase | DB CPU, 메모리, 연결 수, 느린 쿼리
파일 | R2 또는 S3 | 저장량, 다운로드 전송량, 요청 수
백그라운드 작업 | 소형 상시 컨테이너 1대와 큐 | 대기 작업 수, 가장 오래된 작업의 나이
관측 | 외부 가용성 확인, 오류 추적, 플랫폼 지표 | 알림 빈도, 평균 복구 시간

Vercel Functions는 요청과 응답 본문에 4.5MB 제한이 있으므로 큰 파일을 API에 통과시키는 설계는 피하는 편이 안전하다. 파일은 브라우저가 서명된 URL로 객체 저장소에 직접 올리고, API에는 파일의 키와 상태만 기록한다. Vercel Functions 제한

Supabase의 작은 Compute도 연결 한도가 정해져 있다. 예를 들어 Micro는 직접 연결 60개, Supavisor 트랜잭션 풀 연결 200개가 안내되어 있다. 직원이 20명이라는 숫자만 보고 판단하지 말고, 서버리스 함수가 연결을 얼마나 만들고 풀링을 제대로 쓰는지 확인해야 한다. Supabase Compute와 연결 수

20명, 50명, 100명에서 달라지는 것

20명

관리형 서비스를 우선한다. 웹, DB, 인증, 저장소를 직접 관리하지 않고 제품 기능과 권한 설계에 집중하는 편이 대체로 유리하다. 워커가 필요한 작업이 없다면 상시 서버도 두지 않는다. 다만 백업 복구 시험과 비용 알림은 처음부터 설정한다.

50명

평균 사용량보다 업무가 몰리는 시간을 본다. 출근 직후, 월말 마감, 일괄 보고서 생성처럼 짧은 시간에 부하가 집중되면 큐와 워커를 분리한다. 운영 로그의 보존 기간, 관리자 권한, 배포 승인 절차도 이 시점부터 명문화하는 것이 좋다.

100명

단일 장애 지점을 목록으로 만든다. 워커가 한 대뿐이면 작업은 중단돼도 데이터가 사라지지 않아야 하고, DB 장애가 나면 누가 복구를 시작할지 정해져 있어야 한다. 운영 환경과 시험 환경을 분리하고, 이전 배포로 돌아가는 절차와 복구 목표 시간도 실제 훈련으로 확인한다.

확장 순서는 지표가 정한다

무조건 VPS나 쿠버네티스로 옮길 필요는 없다. DB CPU가 계속 높으면 쿼리와 인덱스를 먼저 살피고, 큐가 쌓이면 워커를 늘린다. 파일 전송 비용이 커지면 저장소와 캐시 정책을 조정한다. 긴 연결이 핵심이면 실시간 계층만 별도로 검토한다.

Supabase는 관리형 환경에서 백업과 모니터링을 제공하지만, 직접 호스팅하면 서버 준비, 보안 패치, Postgres 유지보수, 재해 복구와 관측까지 사용자가 책임진다. 단순히 월 서버 가격만 비교하면 이 차이가 빠진다. Supabase 셀프 호스팅 책임 범위

배포 전에 확인할 질문

직원 수가 아니라 동시에 몇 명이 어떤 작업을 하는가?

30초를 넘는 작업과 재시도가 필요한 작업은 무엇인가?

가장 큰 업로드와 다운로드 파일은 얼마나 되는가?

서비스가 한 시간 멈추면 어떤 업무가 중단되는가?

데이터가 몇 분 전으로 돌아가도 되는가?

야간 장애 알림을 받고 복구할 담당자가 있는가?

좋은 사내 시스템 아키텍처는 처음부터 큰 구조를 만드는 것이 아니다. 업무를 짧은 요청, 데이터, 파일, 긴 작업으로 나누고, 관측된 병목만 독립적으로 키울 수 있게 만드는 것이다. 20명에서 시작하더라도 이 경계를 지켜 두면 100명까지 가는 동안 전체를 다시 만들 가능성이 크게 줄어든다.