ProGlove의 Lambda 100만 함수 운영, 무엇이 핵심인가
ProGlove는 산업용 웨어러블 기기를 제조하는 회사로, AWS Lambda 함수를 100만 개 이상 운영하는 SaaS 플랫폼을 구축했다. 이 사례가 주목받는 이유는 단순히 숫자가 크기 때문이 아니라, 아키텍처 설계 방식 자체가 기존의 멀티테넌트 SaaS와 근본적으로 다르기 때문이다.
일반적인 SaaS는 하나의 인프라에 여러 고객 데이터를 논리적으로 분리하는 공유 테넌트 모델을 채택한다. 반면 ProGlove는 각 고객에게 전용 AWS 계정을 할당하고, 그 안에 Lambda 함수를 개별적으로 배포하는 구조를 선택했다. 수천 개의 고객 계정이 존재하고, 각 계정 내에 다수의 Lambda 함수가 배포되면서 총합이 100만 개를 넘어선 것이다.
계정 단위 격리 전략의 실무적 의미
고객별로 AWS 계정을 분리하는 접근은 운영 복잡도를 높이는 대신 여러 실질적인 이점을 제공한다.
- 보안 경계 강화: IAM, VPC, 리소스 정책이 계정 단위로 완전히 분리되어 테넌트 간 데이터 유출 위험이 구조적으로 차단된다.
- 장애 격리(Blast Radius 최소화): 특정 고객 계정에서 Lambda 스로틀링이나 오류가 발생해도 다른 고객에게 영향을 미치지 않는다.
- 규제 준수 용이성: 금융, 제조 등 규제가 엄격한 산업에서 고객별 감사 로그와 컴플라이언스 경계를 독립적으로 관리할 수 있다.
- 비용 추적 명확화: 계정별 AWS 비용이 자동으로 분리되어 고객별 원가 분석이 직관적으로 가능하다.
Java 백엔드 개발자 관점에서 보면, 이 구조는 마치 MSA에서 서비스를 도메인 단위로 분리하는 논리와 유사하다. 다만 분리 단위가 서비스가 아니라 고객(테넌트) 자체라는 점이 다르다.
대규모 서버리스 운영의 기술적 고려사항
100만 개의 Lambda 함수를 실제로 운영하려면 배포 자동화와 중앙 거버넌스가 필수다. 수천 개의 계정에 함수를 일관되게 배포하고 업데이트하려면 AWS Organizations, Control Tower, 그리고 IaC(Infrastructure as Code) 도구의 조합이 필요하다.
# 예시: 계정별 Lambda 배포를 위한 Terraform 구조
module "customer_lambda" {
source = "./modules/customer"
for_each = var.customer_accounts
account_id = each.value.account_id
function_name = "proglove-worker-${each.key}"
runtime = "java17"
}
Java 기반 Lambda의 경우 Cold Start 문제가 계정 수가 늘어날수록 더 넓은 영향을 미친다. ProGlove 같은 구조에서는 각 계정의 Lambda가 독립적으로 워밍업되므로, GraalVM 네이티브 이미지나 SnapStart(Java 전용 Lambda 기능) 같은 최적화 전략을 계정 템플릿 수준에서 표준화하는 것이 중요하다.
또한 모니터링 측면에서 수천 개 계정의 CloudWatch 로그와 메트릭을 중앙에서 집계하는 파이프라인 설계도 빠뜨릴 수 없는 운영 과제다.
정리
- 고객별 AWS 계정 분리는 보안, 장애 격리, 비용 추적 면에서 강력한 이점을 제공하지만, 배포 자동화와 중앙 거버넌스 체계가 반드시 선행되어야 한다.
- Java 기반 Lambda 대규모 운영 시 Cold Start 최적화(SnapStart, GraalVM)를 계정 템플릿 수준에서 표준화하는 것이 중요하다.
- 멀티테넌트 SaaS 설계 시 논리적 분리(DB 스키마, 네임스페이스)와 물리적 분리(계정, 클러스터) 중 어느 전략이 적합한지는 고객 수, 규제 요건, 운영 역량을 함께 고려해야 한다.