SST에서 ECS(Fargate) 컨테이너로 마이그레이션

2025-07-07
AWS-ECSmigration

ecs-architecture

스타트업 특성상 인력의 한계로 클라우드 엔지니어의 공석을 개발자인 우리가 직접 설계하고 운영하고 있었지만 최근에 팀에 클라우드 엔지니어 Jade의 합류로 클라우드에 관련한 많은 지식을 배울수 있었다.
그래서 현구조에 대한 리뷰하면서 장기적으로 운영/관리 측면에서 어떻게하면 효율적, 안정적으로 관리할지에 대한 피드백을 받았다.

처음 우리 팀이 제품을 만들었을 때만 해도 “일단 빨리 만들어서 굴러가게 하자”가 목표였다. 그때 선택한 건 AWS Lambda 기반 서버리스 아키텍처였다.
빠르게 기능을 출시하고 관리 부담을 최소화하기 위해 SST기반의 서버리스 아키텍처를 선택했다.
SST는 IaC로 인프라를 관리하고 이벤트 기반으로 자동 확장되어 초기 운영 비용과 리소스 관리 부담을 줄여주어서 많이 애용했다.

하지만 서비스가 성장하면서 단순히 이벤트를 처리하는 함수 단위 시스템만으로는 한계가 명확해졌다.
이 시점에서 우리는 AWS ECS(Fargate) 기반 컨테이너 아키텍처로의 전환을 결정했다.

🧩 왜 Lambda로는 한계가 있었을까?

Cold Start 문제

사용자 요청이 불규칙하게 들어오는 상황에서 Lambda의 Cold Start 지연이 눈에 띄기 시작했다.
특히 외부 API를 호출하거나 네트워크 초기화가 필요한 작업에서는 수백 밀리초의 지연이 누적되어 사용자 경험에 영향을 주었다.

장기 실행 작업의 제약

우리의 워크로드 중 일부는 데이터 분석이나 이미지 처리처럼 지속적인 배치성 작업을 요구했는데 이 제한이 문제였다.
결국 작업을 쪼개거나 비효율적인 Queue 설계를 해야 했다.

의존성 관리 복잡도 증가

서비스가 커질수록 Lambda 함수 간의 의존성이 얽히면서 관리가 어려워졌다.
공통 라이브러리를 여러 Lambda에 중복 배포하거나 버전 관리에 혼선이 생겼다.
반면에 컨테이너 환경에서는 모든 의존성을 하나의 이미지로 묶을 수 있어 일관성이 유지된다.

비용 구조의 변화

초기에는 Lambda가 매우 경제적이었다.
하지만 트래픽이 일정 수준을 넘어서면서 실행 횟수당 과금 구조가 누적되어 ECS Fargate의 고정 비용보다 비싸지는 시점이 왔다.
규모가 커질수록 서버리스의 장점이 줄어들고 컨테이너의 효율성이 커졌다.


🛠️ 우리는 ECS를 선택

ECS는 컨테이너 오케스트레이션 서비스이고 Fargate는 SST와 동일한 서버리스이지만 컨테이너로 구성된다.
ECS 옵션들을 통해 인스턴스 관리 없이도 직접 런타임, 환경 변수, 네트워크 설정, 자원 할당을 세밀하게 제어할 수 있다.

“Lambda의 간결함은 유지하되, 컨테이너 수준의 제어력을 갖자.”

이게 바로 이번 마이그레이션의 핵심 방향이었다.


⚙️ 마이그레이션 전략

  1. Lambda 함수 분석 및 그룹화
    • 유사한 기능을 수행하는 Lambda를 묶어 하나의 마이크로서비스 단위로 통합
  2. **도커라이징
    • Dockerfile을 빌드, 의존성 및 실행 환경을 컨테이너에 포함
  3. ECS 서비스 구성
    • Fargate 런타입으로 태스크 정의
    • 서비스별 CPU/MEM 자원 할당 및 Auto Scaling 정책 적용
  4. CI/CD 파이프라인 개선
    • GitHub Actions → ECR → ECS로 자동 배포 파이프라인 구축

🧠 이번 마이그레이션에서 느낀 점

Lambda는 진짜 훌륭한 서비스다. 다만 규모가 커지면 단점이 명확히 드러난다는 걸 이번에 체감했다.
결국 인프라 아키텍쳐라는건 단순히 기술의 선택이 아니라 팀의 운영 방식과 속도를 결정하는 철학이라고 생각한다.

Lambda는 “빠르게 움직이고, 가볍게 유지하고 싶은” 팀에 어울린다. 반면에 ECS(Fargate)는 “안정성과 제어력을 챙기고 싶은” 팀에 맞는다.

하지만 이러한 한계를 느끼기전의 단계까지는 이만한게 없는것 같다ㅎ
SST에 자세히 알고 싶다면 AWS Lambda와 SST Warm 옵션의 정확한 이해를 확인하세요!

우리 팀은 이제 그 균형점을 찾은 것 같다. 이번 인프라 전환으로 운영의 예측 가능성과 확장성을 얻게 되었다.
클라우드 관리는 서비스 상황과 다양한 조건들을 따져보면서 그에 맞는 최선의 선택을 할수 있음에 매번 재미를 느낀다.
더욱 성장해서 복잡성 있는 구조를 설계해보고 싶다.

이미지 출처 - https://containersonaws.com/visuals/ecs-architecture/

  • 🧩 왜 Lambda로는 한계가 있었을까?
    • Cold Start 문제
    • 장기 실행 작업의 제약
    • 의존성 관리 복잡도 증가
    • 비용 구조의 변화
  • 🛠️ 우리는 ECS를 선택
  • ⚙️ 마이그레이션 전략
  • 🧠 이번 마이그레이션에서 느낀 점