서버리스에서 벤더 종속을 피하는 구조 설계
FaaS(Function as a Service) 기반 서버리스 아키텍처는 운영 비용 절감과 빠른 확장성 덕분에 많은 팀이 채택하고 있다. 그러나 AWS Lambda나 Azure Functions 같은 플랫폼에 비즈니스 로직이 직접 결합되면, 클라우드 전환 비용이 급격히 높아진다. 특정 벤더의 SDK나 이벤트 모델에 종속된 코드는 이식성을 잃고, 결국 플랫폼 변경이나 멀티클라우드 전략을 실행하기 어렵게 만든다.
이 문제를 해결하는 핵심 전략은 Clean Architecture 원칙을 서버리스 환경에 그대로 적용하는 것이다. 비즈니스 로직을 도메인 레이어에 고립시키고, 외부 인프라(클라우드 플랫폼, 이벤트 트리거, HTTP 어댑터)는 바깥 레이어에서만 다루도록 구조화한다. 이렇게 하면 핵심 로직은 어떤 런타임 환경에서도 재사용 가능한 상태를 유지할 수 있다.
Spring Cloud Function과 Gradle 모듈로 레이어 분리하기
Spring Cloud Function은 이 구조를 실현하는 데 실질적인 도움을 준다. Function<I, O>, Consumer<T>, Supplier<T> 같은 표준 Java 함수형 인터페이스를 기반으로 비즈니스 로직을 작성하면, 동일한 코드를 AWS Lambda 어댑터나 Azure Functions 어댑터에 연결하는 것만으로 배포 환경을 전환할 수 있다.
// 도메인 레이어: 플랫폼 비의존
@Bean
fun processOrder(): Function<OrderRequest, OrderResult> = { request ->
orderService.handle(request)
}
Gradle 멀티모듈 구성을 통해 레이어 경계를 물리적으로 강제할 수 있다. 예를 들어 :domain, :application, :adapter-aws, :adapter-azure 모듈로 분리하면, 도메인 모듈이 클라우드 SDK에 의존하는 것을 빌드 수준에서 원천 차단할 수 있다. 아키텍처 규칙이 코드 컨벤션이 아닌 빌드 구조로 보장된다는 점이 실무에서 큰 강점이다.
:domain ← 비즈니스 로직, 외부 의존 없음
:application ← 유즈케이스 조합
:adapter-aws ← Lambda 핸들러 연결
:adapter-azure ← Azure Functions 연결
Terraform CDK로 멀티클라우드 IaC 운영하기
인프라 코드 역시 동일한 분리 원칙을 적용할 수 있다. **Terraform CDK(CDKTF)**를 활용하면 Kotlin 코드로 AWS와 Azure 인프라를 동시에 정의하고 배포할 수 있다. 플랫폼별 리소스 선언은 다르지만, 공통 추상화 레이어를 두면 환경별 배포 파이프라인을 일관된 방식으로 관리할 수 있다.
실제 데모에서는 동일한 Kotlin 서비스 코드를 AWS Lambda와 Azure Functions에 동시 배포하는 과정을 시연했다. 비즈니스 로직 변경 없이 어댑터와 IaC 설정만 교체함으로써 플랫폼 전환이 가능하다는 것을 검증한 것이다. 특정 클라우드 서비스에 네이티브 기능(예: AWS SQS 트리거, Azure Event Grid)을 활용하면서도, 핵심 도메인은 보호되는 구조를 실현할 수 있다.
정리
- Clean Architecture + Spring Cloud Function 조합으로 비즈니스 로직을 클라우드 플랫폼으로부터 완전히 격리할 수 있다.
- Gradle 멀티모듈로 레이어 경계를 빌드 수준에서 강제하면, 의존성 역전 원칙을 팀 전체가 자연스럽게 준수하게 된다.
- Terraform CDK를 활용한 멀티클라우드 IaC는 벤더 종속 없이 클라우드 네이티브 기능을 유지하는 현실적인 운영 전략이다.