테마
11. VM 배포 실전: Lightsail로 시작하는 프로덕션 기초
배포를 처음 배울 때는 추상화가 높은 서비스보다, 서버 한 대를 어떻게 띄우고 외부에 연결하는지를 먼저 보는 편이 전체 그림을 잡기 쉽다. Lightsail은 그 출발점으로 괜찮다.
학습 목표
- Lightsail이 어디까지 단순화해 주고, 어디부터 직접 판단해야 하는지 설명할 수 있다
- 배포 목표를
고가용성,확장성,자가 복구,CI/CD,보안기준으로 나눠 볼 수 있다 - VM 배포에서 Static IP, Load Balancer, 도메인, HTTPS, 프로세스 관리가 어떻게 이어지는지 이해한다
- VM 기반 배포의 장점과 한계를 알고 다음 단계로 Docker/ECS가 왜 필요한지 설명할 수 있다
1. 배포를 볼 때 먼저 잡아야 할 다섯 가지 목표
원문 강의의 핵심 문제의식은 맞다.
배포를 "서버 한 대 켜기"로만 보면 금방 막힌다. 운영 관점에서는 최소한 아래 다섯 가지를 함께 봐야 한다.
| 목표 | 질문 |
|---|---|
| 고가용성 | 서버 하나가 죽어도 서비스가 계속 살아 있는가 |
| 확장성 | 요청이 늘면 버틸 수 있는가, 줄면 비용을 줄일 수 있는가 |
| 자가 복구 | 장애가 나면 사람이 직접 들어가야만 복구되는가 |
| CI/CD | 코드를 올릴 때마다 사람이 SSH로 들어가 수동 배포하는가 |
| 보안 | 외부 공개 포트, 비밀값, 권한이 과하게 열려 있지는 않은가 |
Lightsail은 이 다섯 가지를 모두 완벽하게 해결하는 도구는 아니다.
대신 처음 그림을 익히는 데 필요한 운영 개념을 비교적 적은 설정으로 보여 주는 서비스다.
2. 왜 Lightsail부터 시작할까?
현재 기준에서 AWS 배포 경로를 아주 단순하게 나누면 이렇게 볼 수 있다.
| 선택지 | 특징 | 잘 맞는 상황 |
|---|---|---|
| Lightsail | 월 고정 요금, 단순한 UI, 빠른 VM 시작 | 학습, MVP, 사이드 프로젝트, 작은 서비스 |
| EC2 | 더 세밀한 제어, AWS 다른 서비스와 깊게 연결 | 중간 이상 복잡도, 세밀한 네트워크/인스턴스 운영 |
| ECS Fargate | 컨테이너 오케스트레이션, 자동 복구/확장에 강함 | 운영 자동화, 다중 서비스, 장기 확장 |
원문처럼 Low level AWS vs High level PaaS 비교도 유효하다.
다만 2026년 관점에서는 "무조건 AWS가 정답"보다 어떤 수준의 제어가 필요한가가 더 중요하다.
- 빠르게 데모를 띄우고 싶다 -> Lightsail
- 운영 구조를 직접 이해하고 싶다 -> Lightsail 또는 EC2
- 서비스가 커지고 배포 자동화·오토스케일링·서비스 디스커버리가 중요하다 -> ECS Fargate
Lightsail Container Service도 있다
Lightsail은 VM만 있는 서비스가 아니다. 다만 이 시리즈는 VM -> 컨테이너 -> ECS 오케스트레이션 흐름을 배우는 데 목적이 있으므로, 컨테이너 운영은 13장에서 ECS Fargate 기준으로 정리한다.
3. 샘플 앱은 왜 필요한가?
원문은 Node.js, TypeScript, Redis, Jest, SuperTest까지 꽤 자세히 다룬다.
이 시리즈에서는 그 구현 과정보다 배포 대상이 어떤 성질을 가져야 하는가만 남긴다.
샘플 앱에서 중요한 점은 세 가지다.
- 웹 애플리케이션 포트가 있다
- 빌드와 테스트 단계가 있다
- 외부 의존성(Redis 같은 상태 저장 서비스)이 존재한다
즉, 샘플 앱은 "어떤 언어로 짰는가"보다 빌드 -> 테스트 -> 실행 -> 외부 서비스 연결 구조를 보여 주는 용도다.
Spring Boot, FastAPI, Go, NestJS로 바뀌어도 배포 판단 기준은 거의 같다.
4. Lightsail 배포의 기본 구조
이 구조를 보면 Lightsail 단계에서 배우는 것이 분명해진다.
- 서버 한 대를 띄우는 법
- 고정 주소를 붙이는 법
- 로드 밸런서와 헬스 체크
- 도메인과 HTTPS 연결
- 애플리케이션 프로세스 관리
- 수동 배포를 자동화로 치환하는 법
5. 배포 전에 먼저 할 보안 기본
원문도 MFA를 강조하는데, 이건 지금도 중요하다.
- 루트 계정은 결제와 긴급 복구 용도로만 두고 일상 작업에 쓰지 않는다
- MFA를 켠다
- 애플리케이션 배포용 권한과 개인 관리자 권한을 분리한다
- GitHub Actions에서 AWS API를 직접 호출해야 한다면 장기 Access Key보다 OIDC 기반 IAM Role 연합을 우선 검토한다
Lightsail 서버에 SSH로 접속해 배포하는 경우에도 비밀값은 최소화해야 한다.
- 배포용 SSH 키는 목적별로 분리
- GitHub 저장소 시크릿에 필요한 값만 저장
.env를 리포지토리에 커밋하지 않음
6. 인스턴스, Static IP, Load Balancer
인스턴스
Lightsail 인스턴스는 "간단한 EC2"에 가깝다.
학습과 소규모 서비스에서는 빠르게 시작할 수 있다는 장점이 있다.
다만 운영에서는 다음을 반드시 같이 봐야 한다.
- 스냅샷/백업 전략
- 인스턴스 교체 시 데이터 지속성
- 상태 저장 서비스를 같은 VM에 같이 넣을지 여부
Static IP
인스턴스를 재시작하면 퍼블릭 IP가 바뀔 수 있다.
외부 접점을 안정적으로 유지하려면 Static IP 또는 Load Balancer 앞단 주소를 사용해야 한다.
Load Balancer
로드 밸런서는 단순히 트래픽을 나누는 장치가 아니다.
- 헬스 체크를 통해 죽은 인스턴스를 제외한다
- HTTPS 종료 지점이 된다
- 나중에 인스턴스를 여러 대로 늘릴 준비가 된다
가격은 항상 공식 페이지에서 다시 본다
Lightsail 인스턴스나 로드 밸런서 요금은 시점에 따라 바뀔 수 있다. 문서에서는 구조와 트레이드오프만 익히고, 실제 비용 판단은 AWS 공식 가격 페이지에서 확인하는 편이 맞다.
7. 도메인과 HTTPS
배포가 끝났다고 해서 IP 주소로만 접속하는 상태에 머무르면 운영 품질이 낮다.
일반적인 흐름은 아래와 같다.
- 도메인을 확보한다
- Route 53 또는 해당 DNS에 레코드를 연결한다
- 인증서를 발급받는다
- 로드 밸런서에 HTTPS를 연결한다
- HTTP -> HTTPS 리다이렉트를 건다
실무 포인트는 두 가지다.
- 인증서를 앱 프로세스 안에 직접 넣기보다 로드 밸런서에서 TLS 종료하는 구조가 일반적으로 관리가 쉽다
- 도메인 연결은 "기능이 붙은 뒤 마지막에"가 아니라, 헬스 체크와 HTTPS 흐름을 검증할 수 있는 초반 단계에 같이 보는 편이 좋다
8. 프로세스 관리와 무중단에 가까운 갱신
VM 위에서 Node.js 같은 애플리케이션을 돌릴 때 원문은 PM2를 사용한다.
이 선택은 VM 단계에서는 여전히 실용적이다.
- 프로세스 재시작 관리
- 로그 확인
- 여러 CPU 코어 활용
reload기반의 비교적 부드러운 갱신
다만 이건 VM 시대 도구라는 점을 같이 기억해야 한다.
- 컨테이너 환경에서는 보통
한 컨테이너 = 한 프로세스원칙이 더 자연스럽다 - ECS로 넘어가면 PM2보다 서비스 단위 재시작과 롤링 업데이트가 더 중요해진다
즉, PM2는 "운영 프로세스 관리 개념을 익히는 단계"로 보면 충분하다.
9. 상태 저장 서비스는 가능하면 분리한다
원문은 Redis를 별도 인스턴스로 떼는 흐름을 보여 준다.
이 방향은 학습용으로 유효하다. 앱 서버와 상태 저장 서비스를 한 VM에 몰아넣는 것보다 낫기 때문이다.
하지만 운영 관점의 기본 원칙은 더 분명하다.
- DB, Redis 같은 상태 저장 서비스는 가능하면 Managed Service부터 검토
- 앱 서버는 교체 가능해야 하고 상태 저장 계층은 별도 수명주기를 가져야 한다
예를 들어:
- Redis -> ElastiCache
- 관계형 DB -> RDS 또는 Aurora
직접 Redis를 띄우는 학습은 "네트워크 분리와 내부 통신"을 익히는 데 도움은 되지만, 운영 기본값으로 삼기엔 위험하다.
10. GitHub Actions로 VM 배포 자동화
Lightsail 단계의 CD는 보통 아래 중 하나다.
- SSH로 접속해
git pull,npm install,npm run build, 프로세스 reload - 아티팩트를 만들어 원격 서버에 복사 후 재시작
이 접근은 초기에 충분히 쓸 만하지만, 한계가 빠르게 드러난다.
- 서버가 여러 대가 되면 배포 대상 추적이 번거롭다
- 롤백이 느슨하다
- 서버마다 환경 차이가 생길 수 있다
- 사람이 SSH로 직접 들어가게 되는 습관이 남기 쉽다
그래서 VM 자동화는 "자동화의 시작점" 으로 이해하는 편이 좋다.
배포 파이프라인의 큰 구조를 익힌 뒤, 다음 단계에서 이미지를 기준으로 배포하는 ECS 방식으로 넘어간다.
11. Lightsail 방식의 장점과 한계
장점
- 배우기 쉽다
- 월 비용 예측이 쉽다
- 인스턴스 한 대를 기준으로 운영 개념을 익히기 좋다
- 정적 IP, 로드 밸런서, HTTPS, 프로세스 관리, CI/CD를 한 번에 경험할 수 있다
한계
- 수평 확장이 금방 번거로워진다
- 서버 환경 차이를 계속 관리해야 한다
- 비밀값, OS 패치, 프로세스 재시작, 로그 수집까지 사람이 신경 쓸 지점이 많다
- 상태 저장 서비스와 앱 서버의 분리가 어색해지기 쉽다
즉, Lightsail은 출발점으로는 좋지만 종착점으로는 제한적이다.
12. 다음 단계로 넘어가는 기준
아래 징후가 보이면 컨테이너와 ECS를 검토할 시점이다.
- 서버가 2대 이상 필요해졌다
- 배포 때마다 "이 서버에도 같은 명령을 쳐야 하나?"가 반복된다
- 환경 차이 때문에 "로컬에서는 되는데 서버에서는 안 된다"가 자주 나온다
- 롤백과 헬스 체크를 더 체계적으로 하고 싶다
- 앱 외에 워커, Redis, 스케줄러 등 서비스 수가 늘어난다
이제 질문은 "AWS를 쓸까 말까"가 아니라 VM을 유지할까, 컨테이너와 오케스트레이션으로 갈까가 된다.
13. PR 리뷰 체크리스트
- 루트 계정 대신 별도 사용자/역할로 운영하고 있는가
- 앱 프로세스를 루트 권한으로 직접 80 포트에 바인딩하지 않는가
- Static IP, Load Balancer, 도메인, HTTPS가 분리된 역할로 설계되어 있는가
- 앱 서버와 상태 저장 서비스를 한 VM에 무리하게 몰아넣지 않았는가
- 배포가 사람의 수동 SSH 절차에 지나치게 의존하고 있지 않은가
핵심 정리
- Lightsail은 AWS 배포의 출발점을 배우기에 좋은 서비스다
- VM 배포를 배우는 목적은 서버 한 대 띄우기가 아니라
주소, 부하 분산, HTTPS, 프로세스, CI/CD, 보안을 함께 이해하는 데 있다 - 운영 규모가 커지면 상태 저장 서비스 분리와 컨테이너 오케스트레이션이 자연스럽게 다음 단계가 된다
관련 문서
출처
- AWS 공식 문서
- 원문 자료:
ing-0019-aws-배포.md