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명까지 가는 동안 전체를 다시 만들 가능성이 크게 줄어든다.
함께 읽기
- 듀오랩스가 사내 시스템을 설계하고 운영하는 7가지 원칙사내 시스템의 좋은 아키텍처는 가장 큰 서버나 가장 복잡한 기술 조합이 아니다. 현재 업무를 무리 없이 지원하고, 문제가 생겼을 때 되돌릴 수 있으며, 사용자가 늘면 필요한 부분만 확장할 수 있는 구조다.
- 대용량 파일은 왜 서버를 거치지 않고 R2나 S3로 올려야 할까?브라우저가 파일을 애플리케이션 서버에 보내고, 서버가 다시 객체 저장소로 전달하는 방식은 이해하기 쉽다. 하지만 파일이 커지면 서버는 같은 데이터를 두 번 전송하고, 메모리와 실행 시간을 오래 점유한다. 서버리스 환경의 본문 크기 제한에도 걸리기 쉽다.
- 백업보다 중요한 복구: 20명에서 100명 규모의 사내 시스템 백업 설계백업이 성공했다는 알림은 데이터를 되살릴 수 있다는 보증이 아니다. 파일이 손상됐거나, 필요한 암호화 키가 없거나, 복구 순서를 아무도 모르면 백업은 있어도 업무를 재개할 수 없다. 사내 시스템의 백업 설계는 저장 횟수보다 복구 목표와 복원 시험에서 시작해야 한다.
- 일로와 서비스 배포 비용웹과 모바일 앱을 함께 제공하는 서비스를 배포할 때는 화면을 올리는 비용만 계산해서는 안 됩니다. 데이터베이스, 캐시, 실시간 통신, 백그라운드 작업, 이미지 저장소까지 포함해야 실제 운영비에 가까워집니다.
- 직원 20명에서 50명까지, Vercel과 Supabase 비용은 얼마나 들까?사내 시스템을 만들 때 가장 자주 나오는 질문 중 하나는 "직원 수가 늘어나면 서버 비용도 같은 비율로 늘어나는가"입니다. Vercel과 Supabase 조합에서는 직원 수보다 배포를 관리하는 개발자 수, 동시에 발생하는 요청, 데이터베이스 쿼리와 배치 작업이 비용에 더 큰 영향을 줍니다.