서버리스, 상주 서버, 정적 호스팅을 나누는 기준

기술 실무 설계 시리즈 3/8

운영 도구를 만들 때 백엔드를 어떻게 구성할지 고민하게 된다.

모든 것을 Lambda로 만들까?

EC2나 ECS 같은 상주 서버를 둘까?

React SPA는 서버에서 서빙해야 할까?

이 질문에는 하나의 정답이 없다.

요청의 성격에 따라 실행 모델을 나누는 것이 더 현실적이다.

먼저 워크로드를 나눈다

기술을 고르기 전에 작업을 분류해야 한다.

운영 콘솔에는 보통 다음 종류의 작업이 섞여 있다.

• 정적 화면 제공
• 짧고 잦은 조회 API
• 인증과 쿠키 처리
• 오래 걸리는 파일 생성
• 이벤트성 동기화
• 월별 통계 적재

이 작업들은 같은 실행 모델을 요구하지 않는다.

정적 화면은 S3와 CloudFront가 잘 맞는다.

짧고 잦은 API는 상주 서버가 나을 수 있다.

드물고 무거운 작업은 Lambda worker가 적합할 수 있다.

정적 호스팅이 맞는 경우

React SPA는 빌드 후 정적 파일이 된다.

SEO나 서버 렌더링이 중요하지 않은 내부 운영 콘솔이라면 정적 호스팅으로 충분할 수 있다.

적합한 조건:

• React Router 기반 SPA
• SEO 중요도 낮음
• 서버 렌더링 불필요
• 정적 파일 배포로 충분
• HTTPS와 캐시만 필요

이 경우 S3 + CloudFront가 단순하고 운영 부담이 낮다.

애플리케이션 서버가 정적 파일 서빙까지 맡을 필요는 없다.

서버리스가 맞는 경우

Lambda는 이벤트성 작업에 잘 맞는다.

다음 조건이면 서버리스가 적합하다.

• 호출 빈도가 낮거나 들쭉날쭉하다.
• 실행 시간이 제한 안에 들어온다.
• 상태를 외부 저장소에 둘 수 있다.
• 작업이 독립적이다.
• 인프라 운영 부담을 줄이고 싶다.

예를 들어:

• 외부 데이터 동기화
• JSON 파일 생성
• 리포트 worker
• 단발성 처리 API
• 파일 생성 후 storage 업로드

서버리스는 "서버가 없다"가 아니라, 서버 운영 책임을 줄이는 선택이다.

상주 서버가 맞는 경우

상주 서버는 계속 떠 있는 프로세스다.

다음 조건이면 상주 서버가 유리할 수 있다.

• 짧고 잦은 요청이 많다.
• 낮은 지연 시간이 중요하다.
• DB connection pool이 필요하다.
• 쿠키 기반 인증을 자연스럽게 처리해야 한다.
• 여러 API가 같은 상태나 connection을 공유한다.

예를 들어 대시보드 조회나 분석 API는 상주 서버가 잘 맞을 수 있다.

Lambda로도 만들 수 있지만, 호출마다 DB connection을 만들거나 cold start를 고려해야 한다면 상주 서버가 더 단순할 수 있다.

같은 백엔드에 다 넣지 않는 이유

모든 API를 하나의 서버에 넣으면 처음에는 편하다.

하지만 작업 성격이 다르면 문제가 생긴다.

오래 걸리는 리포트 생성이 같은 서버에서 돌면 짧은 조회 요청에 영향을 줄 수 있다.

반대로 모든 것을 Lambda로 만들면 잦은 조회와 DB connection 관리가 부담될 수 있다.

그래서 작업 성격별로 나눈다.

작업	적합한 모델
SPA 정적 파일	S3 + CloudFront
대시보드 조회	상주 API 서버
리포트 생성	Lambda worker
외부 동기화	Lambda
생성 파일 저장	Object storage

이 표는 기술 선호가 아니라 요청 패턴의 결과다.

운영 관점의 차이

실행 모델마다 운영 책임이 다르다.

정적 호스팅:

• 서버 운영 없음
• 캐시와 배포가 중요
• SPA fallback 필요

서버리스:

• 인프라 운영 부담 낮음
• timeout, memory, cold start 고려
• 로그와 비동기 실패 추적 필요

상주 서버:

• connection pool 유지 가능
• 낮은 지연
• 서버 패치와 배포 관리 필요
• process/container 상태 확인 필요

어떤 책임을 감당할지 선택하는 것이 설계다.

나중에 바꿀 수 있게 하기

처음 선택이 영원할 필요는 없다.

중요한 것은 나중에 바꿀 수 있는 경계를 두는 것이다.

예를 들어 API 도메인을 Gateway나 CloudFront 앞에 두면 백엔드를 Lambda에서 상주 서버로 바꿔도 클라이언트 URL을 유지할 수 있다.

Docker image로 상주 서버를 운영하면 나중에 EC2에서 ECS로 옮기기 쉽다.

파일은 object storage에 두면 worker 실행 위치가 바뀌어도 결과 저장 구조가 유지된다.

정리

서버리스, 상주 서버, 정적 호스팅은 경쟁 관계가 아니다.

각자 잘 맞는 일이 다르다.

실행 모델은 기술 취향이 아니라 요청 패턴과 운영 책임의 결과다.

좋은 기준은 다음이다.

• 정적 파일은 정적 호스팅
• 짧고 잦은 조회는 상주 서버
• 드물고 무거운 작업은 서버리스 worker
• 파일 산출물은 object storage
• 경계는 나중에 바꿀 수 있게 둔다

이렇게 나누면 작은 운영 도구도 더 안정적으로 굴러간다.

함께 볼 GitHub 저장소

• practical-system-design-playbook