Terraform vs Serverless Framework, Lambda가 많아질수록 생기는 고민
요즘 AWS에서
Terraform + Lambda + SQS 조합으로 구조를 잡는 경우가 많다.
인프라를 코드로 관리한다는 점에서 Terraform은 여전히 가장 신뢰가 가는 선택지다.
CloudFormation은 AWS 네이티브이긴 하지만
가독성, 재사용성, 유지보수 측면에서 Terraform에 비해 아쉬운 점이 많다고 느껴왔다.
그래서 “인프라는 Terraform”이라는 기준은 꽤 확고한 편이다.
그런데 문제는 Lambda 개발 경험이다.
Lambda 함수 개수가 적을 때는 Terraform로도 충분하다.
하지만 함수가 수십 개로 늘어나기 시작하면 이야기가 달라진다.
zip 빌드 관리
핸들러 디렉토리 구조
공통 설정 반복
이벤트 소스(SQS, SNS 등) 연결
이 모든 걸 Terraform으로 관리하다 보면 점점 “인프라 코드인지, 애플리케이션 코드인지” 경계가 흐려진다. 반면 Serverless Framework는 Lambda를 중심으로 한 개발 경험이 굉장히 좋다.
함수 단위로 구조가 명확하고
SQS, API Gateway, Cron 같은 이벤트 연결도 직관적이고
배포 단위도 서비스 기준으로 깔끔하다
그래서 자연스럽게 이런 고민이 생긴다.
CloudFormation보다 Terraform이 더 좋은데
Lambda 개발 경험은 Serverless가 더 낫다
둘 다 IaC 툴인데… 이걸 섞어 써도 되는 걸까
혼용은 가능하다. Terraform으로 VPC, 네트워크, 공통 인프라를 만들고 Serverless Framework로 Lambda와 이벤트만 관리하는 방식도 실제로 많이 쓰인다.
하지만 그 순간부터 또 다른 고민이 시작된다.
소스 오브 트루스가 두 개가 되고
리소스 의존성은 암묵적으로 맞춰야 하고
팀이 커질수록 “이건 어디서 관리하지?”라는 질문이 늘어난다
그렇다고 하나로 통일하자니 또 아쉽다.
Terraform 하나로 가면 Lambda 관리가 번거롭고
Serverless 하나로 가면 큰 인프라까지 맡기기엔 부담스럽다
요즘은 이 둘의 경계선을 어디까지로 잡는 게 맞는지를 계속 고민하고 있다.
“완벽한 도구”보다는, 어디까지 책임지게 할 것인가의 문제에 더 가까운 것 같기도 하다.
비슷한 구조를 운영 중인 팀들은
이 문제를 어떻게 풀고 있는지 궁금해진다.