MSA에는 무엇이 더 적합할까 EC2 vs ECS+Fargate vs Lambda
📘MSA
ECS는 컨테이너 오케스트레이션 서비스이고, Fargate는 ECS나 EKS에서 서버를 직접 관리하지 않고 컨테이너를 실행하게 해주는 서버리스 컴퓨팅 엔진입니다.
이 글의 결론부터 먼저 말하면 이렇습니다.
일반적인 웹/API 중심 MSA라면 ECS+Fargate가 가장 균형이 좋고,
이벤트 기반·보조 기능·간헐 실행 작업이라면 Lambda가 강하며,
OS 제어권이나 레거시 의존성이 크다면 EC2가 여전히 맞습니다.
이건 “무조건 하나가 정답”이라는 뜻이 아니라, 서비스의 실행 방식과 운영 부담이 다르기 때문에 서비스 성격별로 선택지가 달라진다는 이야기입니다. AWS도 Lambda를 서버리스·이벤트 기반 컴퓨팅으로, EC2를 가상 서버 기반 컴퓨팅으로, ECS+Fargate를 컨테이너 기반 마이크로서비스 선택지로 설명합니다.
먼저 기준을 맞춰야 한다
EC2는 가장 전통적인 방식입니다. 가상 서버를 직접 띄우고, 운영체제와 애플리케이션을 설정하고, 보안과 네트워킹, 스토리지까지 직접 관리합니다. AWS 문서도 EC2를 “가상 서버를 원하는 만큼 생성하고, 보안과 네트워킹을 구성하고, 스토리지를 관리할 수 있는 서비스”로 설명합니다.
반면 ECS+Fargate는 컨테이너를 기준으로 사고합니다. ECS가 컨테이너 배포·관리·확장을 맡고, Fargate는 그 컨테이너를 EC2 서버 클러스터를 직접 운영하지 않고 실행하게 해줍니다. 즉 ECS+Fargate는 “컨테이너 기반 MSA를 운영하되 서버 관리는 줄이고 싶다”는 요구에 가깝습니다.
Lambda는 출발점 자체가 다릅니다. AWS는 Lambda를 서버리스, 이벤트 기반 컴퓨팅 서비스로 설명하며, 서버와 운영체제 유지보수, 용량 프로비저닝, 자동 확장 같은 인프라 관리를 AWS가 맡는다고 안내합니다. 즉 Lambda는 “서비스를 오래 켜두고 운영한다”보다 “이벤트가 오면 코드를 실행한다”에 더 가깝습니다.
이렇게 기준을 맞추고 보면 비교 포인트가 명확해집니다.
- 서버를 직접 만져야 하나
- 컨테이너 단위로 서비스를 운영할 건가
- 이벤트 기반으로 짧게 실행되는 기능인가
- 팀이 인프라 운영을 어디까지 감당할 수 있나
EC2가 더 맞는 경우
EC2는 제어권이 가장 큽니다.
운영체제 설정, 시스템 패키지 설치, 에이전트 구성, 네트워크 튜닝, 프로세스 구조 같은 것을 세밀하게 다룰 수 있습니다. AWS 문서도 EC2 인스턴스에서 운영체제와 애플리케이션을 직접 설정·구성할 수 있다고 설명합니다.
그래서 이런 경우 EC2가 맞습니다.
첫 번째, 레거시 Java 서비스가 크고 무겁게 붙어 있는 경우입니다.
예를 들어 오래된 Spring 기반 업무 시스템이 있고, WAS 설정, OS 튜닝, 특정 보안 모듈, 로컬 파일 경로, 배치 스크립트, 시스템 서비스 등록까지 강하게 얽혀 있다면 굳이 억지로 Lambda나 Fargate로 옮기기보다 EC2가 현실적입니다. 이건 AWS 문서의 “OS와 애플리케이션을 직접 설정·구성할 수 있다”는 EC2 특성과 잘 맞는 실무적 해석입니다.
두 번째, 서버 내부를 세밀하게 제어해야 하는 경우입니다.
예를 들어 네이티브 라이브러리, 특정 백그라운드 프로세스, 커스텀 에이전트, 파일 시스템 기반 처리, 특수 네트워킹 구성이 필요한 서비스는 EC2가 편합니다. 컨테이너나 함수 모델로 억지 추상화를 하면 오히려 운영 복잡도가 올라갑니다. 이 역시 EC2의 높은 제어권에 기반한 판단입니다.
다만 단점도 분명합니다.
서버 패치, 확장, 장애 대응, 이미지 관리, 배포 자동화, 오토스케일링, 보안 운영까지 팀이 더 많이 책임져야 합니다. 그래서 MSA를 하겠다고 하면서 실제로는 “서비스 수만 늘고 서버 운영 부담도 같이 늘어나는” 구조가 되기 쉽습니다. AWS가 EC2를 직접 구성하고 관리하는 가상 서버 모델로 설명하는 이유가 바로 그 책임 범위 때문입니다.
ECS+Fargate가 더 맞는 경우
대부분의 팀에서 MSA의 기본 선택지로 가장 먼저 검토할 만한 것은 ECS+Fargate입니다.
이유는 단순합니다.
MSA는 보통 서비스를 독립 배포 단위로 나누고, 각 서비스를 API 또는 메시지 기반으로 운영합니다. 이때 컨테이너는 배포 단위를 고정하기 좋고, ECS는 그 컨테이너의 배포·관리·확장을 단순화해줍니다. 여기에 Fargate를 붙이면 EC2 클러스터 운영 부담까지 줄일 수 있습니다. AWS도 ECS를 완전관리형 컨테이너 오케스트레이션 서비스로, Fargate를 서버나 EC2 클러스터를 관리하지 않고 컨테이너를 실행하는 기술로 설명합니다.
그래서 이런 경우 ECS+Fargate가 특히 잘 맞습니다.
첫 번째, Spring Boot 기반 Java MSA를 여러 개 운영하는 경우입니다.
예를 들어 회원, 주문, 결제, 알림 서비스가 각각 별도 애플리케이션으로 나뉘어 있고, 각 서비스가 HTTP API를 계속 제공해야 한다면 Lambda보다 ECS+Fargate가 자연스럽습니다. 컨테이너로 표준화하기 쉽고, 서비스별 CPU·메모리 단위를 나눠 배포하기 좋습니다. 이건 ECS가 컨테이너 애플리케이션의 배포·관리·확장을 맡고, Fargate가 서버 관리 부담을 줄여준다는 공식 정의에서 바로 따라오는 선택입니다.
두 번째, 팀이 인프라 운영보다 애플리케이션 개발에 집중하고 싶은 경우입니다.
EC2 기반 MSA는 서비스 수가 늘수록 서버 운영 이슈도 같이 커집니다. 반면 ECS+Fargate는 컨테이너 이미지만 잘 관리하면 비교적 일관된 배포 모델을 만들기 쉽습니다. AWS가 Fargate에서 “가상 머신 클러스터를 프로비저닝, 구성, 스케일링할 필요가 없다”고 설명하는 이유가 여기에 있습니다.
세 번째, 서비스는 계속 떠 있어야 하지만, 서버 자체는 관리하고 싶지 않은 경우입니다.
예를 들어 내부 관리자 API, 외부 B2B 연동 API, 인증 서버, 웹 백엔드처럼 항상 살아 있는 프로세스가 필요한 경우가 그렇습니다. Lambda처럼 호출 때마다 실행되는 모델보다, 컨테이너 서비스로 상시 운영하는 쪽이 더 자연스러운 케이스입니다. 이건 AWS의 서비스 정의를 바탕으로 한 실무적 판단입니다.
Lambda가 더 맞는 경우
Lambda는 “작고 짧고 이벤트성 있는 기능”에 강합니다.
AWS는 Lambda가 서버리스·이벤트 기반 모델을 따르며, 이벤트 소스나 AWS 서비스가 함수를 트리거한다고 설명합니다. 또 서버와 운영체제 유지보수, 용량 프로비저닝, 자동 확장 같은 부분을 Lambda가 관리한다고 안내합니다.
그래서 Lambda가 특히 잘 맞는 경우는 이런 쪽입니다.
첫 번째, 비동기 보조 기능입니다.
예를 들어 회원 가입 후 이메일 발송, 이미지 썸네일 생성, 파일 업로드 후 후처리, 스케줄성 정리 작업 같은 것은 Lambda와 잘 맞습니다. AWS도 Lambda 예시로 스케줄 작업, 스트림 처리, 웹 애플리케이션 백엔드, 데이터베이스 연계 등을 제시합니다.
두 번째, 트래픽이 들쭉날쭉한 기능입니다.
항상 켜둘 필요는 없지만 요청이 오면 바로 처리해야 하는 기능은 Lambda가 유리할 수 있습니다. AWS 결정 가이드는 Lambda가 예측 불가하거나 bursty한 트래픽에 비용 효율적일 수 있다고 설명합니다.
세 번째, 언어를 섞어 써야 하지만 서비스 하나를 통째로 추가하기는 애매한 경우입니다.
예를 들어 메인 서비스는 Java인데, Python 오픈소스 맞춤법 검사기를 특정 기능에만 쓰고 싶다고 해보겠습니다. 이때 그 기능 호출이 간헐적이고, 전체 Python 서비스를 상시 운영할 정도의 크기가 아니라면 Lambda로 Python 함수를 따로 두는 방식이 꽤 합리적입니다. AWS는 Lambda가 여러 언어를 지원하고, 다른 AWS 서비스에 의해 트리거되거나 웹/모바일 애플리케이션에서 직접 호출될 수 있다고 설명합니다. 즉 Java 본체를 건드리지 않고 “작은 Python 기능 하나만 분리” 하는 데 Lambda가 잘 맞습니다. 이건 공식 문서의 다중 언어 지원과 이벤트/호출 모델을 바탕으로 한 실무적 추천입니다.
같은 예시라도 반대로 볼 수도 있습니다.
만약 그 Python 맞춤법 검사기가 요청량이 많고, 응답 지연에 민감하고, 별도 라이브러리·런타임 관리가 복잡하며, 사실상 독립 서비스로 계속 떠 있어야 한다면 Lambda보다 ECS+Fargate로 Python 마이크로서비스를 하나 두는 편이 더 나을 수 있습니다. Lambda는 이벤트 기반 모델이고, AWS도 전통적인 웹 애플리케이션과는 다른 프로그래밍 패러다임이라고 설명합니다. 즉 “Python을 쓴다”만으로 Lambda가 정답은 아니고, 사용 패턴이 Lambda형인지를 봐야 합니다.
그럼 MSA에는 무엇이 제일 적합할까
이 질문에는 사실 “MSA의 어떤 서비스인가”라고 다시 묻는 게 맞습니다.
항상 떠 있어야 하는 웹/API 서비스라면 ECS+Fargate가 가장 무난합니다.
Java, Spring Boot, FastAPI, Node API처럼 상시 서비스가 필요한 애플리케이션을 컨테이너로 운영하기 쉽고, MSA의 “서비스별 독립 배포”와 잘 맞습니다. AWS도 마이크로서비스 구현에서 ECS와 Fargate를 주요 선택지로 제시합니다.
짧고 독립적인 이벤트 처리 기능이라면 Lambda가 더 맞습니다.
알림, 파일 변환, 데이터 후처리, 스케줄 배치, 특정 보조 기능처럼 “작업 단위”가 분명한 서비스는 Lambda가 깔끔합니다. AWS는 Lambda를 이벤트 기반 서비스로 설명하며, 이벤트 주도 아키텍처에서의 활용을 강조합니다.
레거시가 깊고 OS 제어가 중요한 서비스라면 EC2가 여전히 유효합니다.
굳이 컨테이너나 함수로 억지 분해하는 것보다, 먼저 VM 위에서 안정화한 뒤 점진적으로 쪼개는 것이 더 현실적인 경우가 많습니다. 이건 EC2가 가상 서버를 직접 운영하는 모델이라는 정의에서 따라오는 결론입니다.
즉 MSA의 정답은 하나가 아니라 보통 이렇게 나뉩니다.
- 핵심 API 서비스: ECS+Fargate
- 이벤트성 보조 기능: Lambda
- 아직 못 쪼갠 레거시 또는 특수 서버: EC2
이 조합이 실무에서는 가장 많이 납득되는 그림입니다. AWS가 마이크로서비스 구현에서 ECS/Fargate/EC2/Lambda를 모두 선택지로 제시하는 것도 결국 이런 이유입니다.
마무리
MSA에는 무엇이 더 적합할까? EC2 vs ECS+Fargate vs Lambda라는 질문에 대한 제 답은 이렇습니다.
일반적인 MSA의 기본값은 ECS+Fargate입니다.
서비스를 컨테이너 단위로 나누고, 독립 배포하고, 서버 운영 부담을 낮추기 좋기 때문입니다.
하지만 모든 것을 ECS+Fargate로 갈 필요도 없고, 모든 것을 Lambda로 쪼갤 필요도 없습니다.
Java 본체 옆에 작은 Python 오픈소스 기능을 붙이는 정도라면 Lambda가 더 예쁠 수 있고, 반대로 그 Python 기능이 사실상 하나의 상시 서비스라면 ECS+Fargate가 더 낫습니다. 레거시가 무겁고 서버 제어가 중요하면 EC2가 맞습니다. 이 판단은 결국 서비스의 실행 방식, 운영 부담, 트래픽 패턴, 런타임 분리 필요성으로 갈립니다.
한 줄로 줄이면 이겁니다.
“MSA라고 해서 무조건 Lambda도 아니고, 무조건 EC2도 아니다. 상시 API는 ECS+Fargate, 이벤트성 기능은 Lambda, 특수·레거시는 EC2가 가장 현실적인 출발점이다.”