듀오랩스가 사내 시스템을 설계하고 운영하는 7가지 원칙

사내 시스템의 좋은 아키텍처는 가장 큰 서버나 가장 복잡한 기술 조합이 아니다. 현재 업무를 무리 없이 지원하고, 문제가 생겼을 때 되돌릴 수 있으며, 사용자가 늘면 필요한 부분만 확장할 수 있는 구조다.

듀오랩스가 선택할 수 있는 최적의 전략도 여기에 있다. 웹, 데이터베이스, 파일, 백그라운드 작업을 무조건 한곳에 모으거나 모든 서비스를 직접 운영하는 대신, 관리형 서비스로 작게 시작하고 운영상 이점이 확인된 부분에만 VPS와 상시 서버를 사용한다.

이 글은 특정 제품을 정답으로 제시하기보다 듀오랩스가 사내 시스템을 설계하고 운영할 때 유지하려는 판단 기준을 정리한다.

1. 직원 수보다 업무가 멈췄을 때의 영향을 먼저 본다

20명이 쓰는 시스템이 100명이 쓰는 시스템보다 가벼울 것이라고 단정할 수 없다. 대용량 문서 변환, 실시간 협업, 외부 시스템 연동이 많다면 적은 인원으로도 높은 부하가 발생한다.

아키텍처를 정할 때는 다음 질문부터 확인한다.

• 동시에 몇 명이 어떤 업무를 하는가?
• 가장 큰 파일은 얼마나 되는가?
• 30초 이상 걸리는 작업이 있는가?
• 몇 초의 화면 갱신 지연을 허용할 수 있는가?
• 한 시간의 장애가 어떤 업무를 중단시키는가?
• 몇 분 전 데이터로 돌아가도 업무를 복구할 수 있는가?

직원 수는 참고값이다. 실제 결정은 동시 접속, 작업량, 파일 크기, 허용 중단 시간으로 내린다. 20명에서 100명까지, 사내 시스템 배포 아키텍처 설계하기

2. 시스템을 네 가지 역할로 분리한다

듀오랩스의 기본 구조는 화면과 짧은 API, 데이터와 인증, 파일, 오래 걸리는 작업을 구분하는 것이다.

역할	우선 검토할 구성	분리하는 이유
화면과 짧은 API	Vercel 같은 관리형 웹 플랫폼	배포와 확장이 단순하다
데이터와 인증	Supabase 같은 관리형 백엔드	DB, 인증, 권한을 함께 관리하기 쉽다
파일	Cloudflare R2 또는 Amazon S3	큰 파일이 애플리케이션 서버를 통과하지 않는다
오래 걸리는 작업	큐와 소형 상시 워커	실패, 재시도, 진행률을 독립적으로 관리한다

역할이 나뉘면 특정 부분의 부하가 늘어도 전체 시스템을 옮길 필요가 없다. 파일 전송량이 늘면 저장소와 캐시를 조정하고, 대기 작업이 쌓이면 워커만 늘릴 수 있다.

3. 관리형 서비스로 시작하고 직접 운영은 이유가 생겼을 때 선택한다

대표와 개발자, 운영 담당자의 역할이 겹치는 작은 조직에서는 사람의 시간이 가장 부족한 자원이다. 서버 가격 몇 달러를 줄이기 위해 보안 패치, DB 백업, 장애 복구 업무를 매달 떠안으면 제품 개선에 쓸 시간이 줄어든다.

그래서 듀오랩스는 관리형 서비스로 시작하는 것을 기본값으로 둔다. 다음과 같은 신호가 확인될 때 직접 운영이나 VPS를 검토한다.

• 큐를 계속 확인하는 상시 워커가 필요하다.
• 서버리스 실행 시간이나 메모리 제약과 맞지 않는 작업이 있다.
• 장시간 연결이나 특정 시스템 프로그램이 필요하다.
• 부하가 일정해 고정 서버의 자원을 꾸준히 활용할 수 있다.
• 운영 비용 절감액이 관리 시간과 장애 위험보다 충분히 크다.

VPS가 필요하더라도 전체 시스템을 한 번에 옮기지 않는다. 상시 워커처럼 VPS의 장점이 분명한 부분부터 혼합형으로 운영한다. 월 10달러 VPS가 정말 더 저렴할까? 숨은 운영 비용 계산하기

직접 운영을 시작한 서버에는 계정과 SSH, 방화벽, 업데이트, 비밀정보, 로그와 백업을 서비스 배포 전에 적용한다. VPS를 만들었다면 가장 먼저 해야 할 보안 설정 10가지

4. 단순한 기술부터 사용하고 복잡성은 요구사항이 증명한다

몇 초 늦어도 되는 화면에 WebSocket을 먼저 넣거나, 간헐적인 작업 때문에 상시 서버를 두지 않는다. 가장 단순한 방식이 업무 조건을 충족한다면 그 방식이 운영에도 유리하다.

• 화면 갱신은 Polling부터 검토한다.
• 서버에서 브라우저로 보내기만 한다면 SSE를 검토한다.
• DB 변경 알림과 사용자 상태는 Supabase Realtime을 검토한다.
• 양방향 고빈도 통신이 핵심일 때 WebSocket 전용 계층을 검토한다.

Polling, SSE, WebSocket, Supabase Realtime 중 무엇을 선택할까?

파일도 같은 원칙을 적용한다. 대용량 파일은 웹 서버가 중계하지 않고 브라우저가 서명된 URL로 객체 저장소에 직접 올리게 한다. 애플리케이션은 권한, 검사, 상태 관리에 집중한다. 대용량 파일은 왜 서버를 거치지 않고 R2나 S3로 올려야 할까?

5. 오래 걸리는 작업은 업무 상태로 설계한다

보고서 생성, 대량 메일, 파일 변환을 API 요청 안에서 끝내려 하면 타임아웃과 중복 실행이 발생하기 쉽다. 듀오랩스는 이런 작업을 접수됨, 대기 중, 처리 중, 완료, 실패, 취소됨처럼 명확한 상태 전이로 다룬다.

API는 요청을 검증하고 작업 ID를 반환한다. 큐와 워커가 실제 작업을 처리하며, 실패하면 정해진 기준으로 재시도한다. 화면은 작업 상태와 다음 행동을 보여 준다. 이 방식은 사용자 경험뿐 아니라 장애 복구와 운영자의 판단도 단순하게 만든다. 오래 걸리는 작업을 API에서 바로 처리하면 안 되는 이유

6. 백업, 모니터링, 롤백과 비용 알림은 첫 배포에 포함한다

운영 장치는 사용자가 많아진 뒤 추가하는 부가 기능이 아니다. 사용자가 한 명이어도 중요한 데이터가 있다면 복구할 수 있어야 한다.

듀오랩스의 최소 운영 기준은 다음과 같다.

• 외부에서 핵심 URL을 확인한다.
• 애플리케이션 오류와 배포 버전을 연결한다.
• DB와 파일의 백업을 확인하고 실제 복원 시험을 한다.
• 직전 정상 버전으로 돌아가는 절차를 유지한다.
• 클라우드 총액과 서비스별 사용량에 알림을 둔다.
• 긴급 알림에는 담당자와 첫 대응 절차를 연결한다.

백업 성공 알림보다 마지막 복원 성공 시각이 중요하다. 백업보다 중요한 복구: 20명에서 100명 규모의 사내 시스템 백업 설계

사용자가 신고하기 전에 장애를 발견하려면 외부 가용성, 오류, 자원, 업무 지표를 함께 본다. 서버가 멈추기 전에 알 수 있을까? 소규모 서비스 모니터링 구성

배포는 이전 버전과 DB 호환성을 유지해야 빠르게 되돌릴 수 있다. 배포가 실패해도 5분 안에 되돌리는 소규모 서비스 운영법

비용도 장애처럼 감지하고 대응한다. 클라우드 비용 폭탄을 막는 예산과 사용량 알림 설정

7. 직원 수가 아니라 관측된 신호에 따라 확장한다

규모	우선할 운영 전략
약 20명	관리형 서비스 중심, 최소 모니터링, 외부 백업과 복원 시험
약 50명	큐와 워커 분리, 운영·시험 환경 구분, 담당자와 대응 절차 지정
약 100명	단일 장애 지점 점검, 중요 작업 이중화, 복구 목표와 전체 복구 훈련

이 표는 자동 확장 규칙이 아니다. DB 연결 포화, 느린 쿼리, 오류율, 큐 적체, 파일 전송량, 복구 시간 같은 지표가 실제 판단 기준이다. 문제가 쿼리에 있다면 서버를 키우기 전에 쿼리를 고치고, 워커만 부족하다면 워커만 늘린다.

듀오랩스 운영에 맞는 실행 전략

듀오랩스가 유지하기 좋은 방식은 일회성 구축보다 반복 가능한 운영 기준을 만드는 것이다.

1. 새 프로젝트를 시작할 때 업무 중단 영향과 데이터 중요도를 분류한다.
2. 웹, 데이터, 파일, 긴 작업의 경계를 아키텍처 문서에 남긴다.
3. 첫 배포와 함께 모니터링, 백업, 비용 알림, 롤백 절차를 만든다.
4. 매달 사용량과 운영 시간을 함께 검토한다.
5. 확장 신호가 확인된 부분만 별도 서비스나 VPS로 이동한다.
6. 분기마다 복원과 롤백을 직접 시험하고 결과를 기록한다.

이 전략은 특정 클라우드에 모든 것을 맡기는 방식도 아니고, 모든 것을 직접 운영하는 방식도 아니다. 관리형 서비스가 사람의 시간을 아껴 주는 곳에서는 적극적으로 사용하고, 상시 워커나 고정 부하처럼 직접 운영의 이점이 분명한 곳에서는 작은 서버를 선택하는 현실적인 혼합형 전략이다.

듀오랩스는 가장 비싼 인프라나 가장 복잡한 구조를 먼저 선택하지 않는다. 현재 업무에 필요한 만큼 작게 시작하되, 장애가 발생해도 복구할 수 있고 사용자가 늘면 필요한 부분만 확장할 수 있는 시스템을 지향한다.