Bluetape4k AWS Part 4: Spring Cloud AWS와 비교하기

비교의 목적은 승부를 내는 것이 아니라, 반복되는 AWS 작업을 어디에 맡길지 정하는 것입니다.

2026-06-04 · bluetape4k-aws series · Part 4

이 글은 bluetape4k-aws 시리즈의 4편입니다. Part 1에서는 프로젝트 개요와 mental model을 봤고, Part 2에서는 core module과 AWS 서비스 지원 현황을 정리했습니다. Part 3에서는 Spring Boot와 Ktor 통합을 살펴봤습니다. 이번 글에서는 Java 진영에서 널리 쓰이는 Spring Cloud AWS와 bluetape4k-aws를 직접 비교합니다.

먼저 전제를 분명히 하겠습니다. 현재 bluetape4k-aws는 Spring Cloud AWS와 접근법이 다릅니다. Spring Cloud AWS가 Spring Boot 애플리케이션에서 AWS managed service를 편하게 쓰도록 해 주는 Spring 중심 통합이라면, bluetape4k-aws는 AWS Java SDK v2와 AWS Kotlin SDK 위에서 Kotlin/JVM 서비스가 반복적으로 구현해야 하는 부분을 편리한 함수로 제공합니다. 그리고 그 공통 기능을 Spring Boot 4 또는 Ktor 3에 맞게 연결합니다.

하지만 방향이 다르다고 해서 목표 기능이 좁다는 뜻은 아닙니다. 앞으로 Spring Cloud AWS가 제공하는 편의 기능을 bluetape4k-aws에서도 계속 채워 갈 예정입니다. 동시에 Ktor 통합 기능도 같은 수준으로 확장합니다. Spring Boot 사용자에게 익숙한 기능과 Ktor 사용자에게 필요한 coroutine 실행 흐름을 각 프레임워크 방식에 맞춰 같은 AWS helper 계층 위에서 제공하는 것이 이 프로젝트의 방향입니다.

두 라이브러리는 같은 AWS SDK 계열 위에 서 있지만, 반복 작업을 맡기는 위치가 다릅니다.

이 글의 관점

현재만 놓고 보면 Spring Boot 애플리케이션만 운영하고, 팀이 이미 Spring Cloud 방식에 익숙하며, Spring Cloud AWS가 제공하는 template, listener, external configuration 기능으로 충분하다면 Spring Cloud AWS를 먼저 보는 것이 좋습니다. 공식 문서와 생태계가 있고, Spring Boot auto-configuration 관점에서 AWS 통합을 설명하기 쉽습니다.

bluetape4k-aws는 이 지점에서 다른 접근을 택합니다. Spring Cloud AWS가 Spring 안쪽의 사용성을 먼저 다듬는다면, bluetape4k-aws는 Kotlin/JVM 공통 helper를 먼저 만들고 그 위에 Spring Boot 4 또는 Ktor 3 adapter를 올립니다. Java SDK v2 쪽에서는 CRT 기반 HTTP client와 S3 TransferManager를 적극적으로 사용할 수 있게 하고, AWS Kotlin SDK 쪽에서도 CRT를 기본 방식으로 사용하면서 필요하면 다른 HTTP engine으로 바꿀 수 있게 둡니다.

그래서 이 글은 어느 하나를 고르라는 판정이 아닙니다. 현재는 적용 범위가 다르지만, 앞으로 bluetape4k-aws는 Spring Cloud AWS가 제공하는 편의 기능을 Spring Boot 4 adapter에 계속 보강하고, 동시에 Ktor 3 adapter에도 대응 기능을 넓혀 갈 예정입니다. Ktor 서비스, coroutine 중심 helper, CRT 기반 대용량 S3 전송, Exposed database registry, local emulator 중심 테스트 같은 요구가 함께 생기면 bluetape4k-aws가 맡을 수 있는 영역이 더 분명해집니다.

같은 문제, 다른 책임 경계

두 라이브러리는 모두 AWS SDK를 애플리케이션 코드에서 직접 반복해서 다루는 일을 줄입니다. 하지만 무엇을 프레임워크가 맡고, 무엇을 애플리케이션이 명시적으로 고르는지에서 차이가 납니다.

비교 기준	Spring Cloud AWS	bluetape4k-aws
기본 관점	Spring Boot와 Spring Cloud 생태계에서 AWS managed service를 쓰기 쉽게 만든다.	Kotlin/JVM 서비스가 AWS SDK 위에서 반복적으로 구현하는 작업을 줄인다.
프레임워크 범위	Spring Boot starter, auto-configuration, Spring template, annotation listener 중심이다.	aws-java, aws-kotlin, aws-exposed 공통 helper 위에 Spring Boot 4 또는 Ktor 3 adapter를 둔다. Spring Boot 쪽 편의 기능도 계속 확장한다.
SDK 기준	AWS Java SDK v2를 Spring Boot auto-configuration과 연결한다.	AWS Java SDK v2와 AWS Kotlin SDK를 모두 다루고, Kotlin extension, coroutine, DSL builder를 제공한다.
async 기능	Spring messaging/listener/container 추상화와 AWS SDK async client를 Spring 방식으로 감싼다.	CompletableFuture, suspend, Flow를 명시적으로 연결하고, 애플리케이션 코드가 coroutine 형태로 쓰기 쉽게 한다.
S3 대용량 전송	S3 integration과 template/resource 모델을 제공한다.	Java SDK v2 쪽에서 CRT client와 S3 TransferManager helper를 강조하고, Spring Boot adapter에서 S3TransferOperations로 노출한다.
Ktor	대상 프레임워크가 아니다.	Ktor 3 plugin, SigV4, S3 REST client, SQS consumer, DynamoDB plugin, Exposed plugin을 제공하고, Spring Boot 쪽 기능 확장과 함께 계속 지원한다.
dependency 정책	starter가 Spring Boot 애플리케이션에 필요한 auto-configuration과 의존성을 가져온다.	AWS service dependency는 가능한 명시적으로 두고, 애플리케이션이 필요한 SDK module만 선택하게 한다.
local testing	Spring Cloud AWS test/testcontainers module과 sample이 있다.	Floci 우선, LocalStack fallback, Testcontainers 기반 examples를 같은 series에서 계속 검증한다.

이 표만 보면 bluetape4k-aws가 더 넓어 보일 수 있지만, 지금 시점에는 기능 수보다 책임 경계를 봐야 합니다. Spring Boot 애플리케이션 안에서 Spring이 AWS 통합의 중심이 되길 원하면 Spring Cloud AWS가 잘 맞습니다. Kotlin/JVM 공통 helper를 먼저 세우고, 그 위에서 Spring Boot 4 또는 Ktor 3를 선택해 쓰고 싶다면 bluetape4k-aws가 잘 맞습니다. 장기적으로는 Spring Boot adapter의 편의 기능도 Spring Cloud AWS가 제공하는 범위에 가깝게 넓혀 갈 계획입니다.

Spring Cloud AWS가 편한 경우

Spring Cloud AWS는 이름 그대로 Spring Cloud와 Spring Boot 애플리케이션을 기준으로 설계됩니다. 최신 README 기준으로 Spring Cloud AWS 4.x는 Spring Boot 4.0.x, Spring Framework 7.0.x, AWS Java SDK 2.x 조합을 대상으로 하고, S3, SNS, SES, Parameter Store, Secrets Manager, SQS, CloudWatch, DynamoDB, Spring Integration AWS, Kinesis Stream Binder 등을 지원합니다.

이런 경우에는 Spring Cloud AWS를 먼저 검토하는 편이 좋습니다.

• 애플리케이션이 Spring Boot 중심이고, AWS 통합도 Spring bean, properties, starter로 관리하고 싶다.
• SQS consumer를 @SqsListener와 Spring message conversion 모델로 설명하고 싶다.
• S3를 S3Template, resource abstraction, Spring Boot configuration property와 함께 쓰고 싶다.
• Secrets Manager나 Parameter Store를 Spring external configuration으로 자연스럽게 가져오고 싶다.
• 팀이 Spring Cloud release train, starter BOM, Spring actuator/observability 관례에 익숙하다.

이 장점은 단순히 “기능이 많다”는 뜻이 아닙니다. Spring Boot 팀이 Spring Boot 애플리케이션을 운영할 때 이미 알고 있는 언어로 AWS 통합을 설명할 수 있다는 점이 큽니다. Spring Cloud AWS는 이 환경에서 반복되는 설정을 줄이고, Spring 방식으로 확장할 수 있는 지점을 제공합니다.

bluetape4k-aws가 다르게 푸는 지점

bluetape4k-aws는 출발점이 조금 다릅니다. Spring Boot adapter가 있지만, 프로젝트의 중심은 Spring이 아니라 Kotlin/JVM에서 AWS SDK를 다룰 때 반복되는 부분입니다. 그래서 core module이 먼저 있고, framework adapter가 그 위에 올라갑니다. 현재는 이 구조 때문에 Spring Cloud AWS와 기능 구성이 1:1로 같지는 않습니다. 다만 앞으로는 Spring Cloud AWS가 제공하는 Spring Boot 편의 기능을 bluetape4k-aws-spring-boot에도 꾸준히 보강하고, 같은 AWS helper 계층을 Ktor adapter에도 연결해 Spring Boot 4 서비스 또는 Ktor 서비스에서 선택해 사용할 수 있게 하는 방향으로 확장합니다.

첫 번째 차이는 SDK 선택권입니다. bluetape4k-aws-java는 AWS Java SDK v2를 쓰는 서비스에 sync, async, coroutine extension을 제공합니다. S3에서는 CRT 기반 S3AsyncClient를 만들 수 있고, S3TransferManager를 사용하는 upload/download helper를 제공합니다. 대용량 파일 처리에서는 작은 object API만으로 충분하지 않은 경우가 많기 때문에, 이 부분을 처음부터 중요한 사용 흐름으로 봅니다. S3ClientFactory는 transfer manager를 만들 때 virtual thread executor도 기본 선택지로 제공합니다.

두 번째 차이는 AWS Kotlin SDK입니다. bluetape4k-aws-kotlin은 native suspend API와 DSL builder를 그대로 살리면서, HTTP engine 기본값을 CRT로 둡니다. 필요하면 HttpClientEngine을 주입해 다른 구현으로 변경할 수 있지만, 기본 사용 흐름은 CRT를 쓰도록 정리되어 있습니다. Kotlin 서비스 입장에서는 Java SDK v2 helper와 Kotlin SDK helper를 같은 프로젝트 안에서 비교하고 선택할 수 있습니다.

세 번째 차이는 Ktor입니다. Spring Cloud AWS는 Spring 애플리케이션을 대상으로 하지만, bluetape4k-aws는 Ktor 3 adapter를 별도 module로 둡니다. AwsSigV4Plugin, S3KtorClient, SqsConsumer, DynamoDbKtorPlugin, AwsExposedPlugin은 Spring Boot auto-configuration을 흉내 내지 않습니다. Ktor의 install(...), route helper, lifecycle event에 맞춰 AWS 작업을 연결합니다. 앞으로 Spring Boot adapter에 추가되는 편의 기능도 가능한 한 Ktor 쪽 사용 방식에 맞춰 제공하는 것이 목표입니다.

네 번째 차이는 dependency 경계입니다. bluetape4k-aws는 AWS service dependency를 무조건 모두 끌어오지 않고, 애플리케이션이 실제로 쓰는 SDK module을 명시하도록 둡니다. 라이브러리는 helper와 adapter를 제공하지만, runtime에서 어떤 AWS client를 포함할지는 서비스가 선택합니다. 이 방식은 설정할 것이 조금 더 보이지만, module graph와 운영 binary를 의식적으로 관리할 수 있습니다.

SQS와 S3에서 드러나는 차이

SQS는 두 라이브러리의 성격이 가장 잘 드러나는 영역입니다. Spring Cloud AWS는 SqsTemplate, SqsMessageListenerContainer, @SqsListener, message conversion, acknowledgement, batch processing, observability 같은 Spring messaging 기능을 제공합니다. Spring Boot 애플리케이션에서는 queue listener를 Spring bean lifecycle 안에서 설명할 수 있습니다.

bluetape4k-aws-spring-boot도 @SqsListener와 coroutine listener container를 제공합니다. 지금은 Spring Cloud AWS와 같은 abstraction을 모두 갖춘 상태라기보다, Kotlin coroutine handler가 SQS receive, delete, visibility timeout, retry, manual acknowledgement를 덜 반복하게 하는 데 초점을 둡니다. 향후에는 Spring Cloud AWS가 제공하는 listener 편의 기능을 계속 따라가면서, Ktor 쪽에서는 annotation 대신 SqsConsumer plugin이 application start/stop lifecycle에 맞춰 polling runtime을 관리하는 방향을 유지합니다.

S3도 비슷합니다. Spring Cloud AWS는 Spring 애플리케이션 안에서 S3를 template/resource 관점으로 다루기 좋습니다. bluetape4k-aws는 여기에서 한 발 더 SDK 실행 방식 쪽으로 내려갑니다. 작은 object 작업에는 coroutine template과 helper를 쓰고, 큰 파일 처리에는 CRT 기반 async client와 S3TransferManager를 사용합니다. Spring Boot adapter에서는 이것을 S3TransferOperations로 노출하고, core module에서는 transfer manager extension을 제공합니다.

이 차이는 성능만의 문제가 아닙니다. 운영 코드에서 “이 서비스의 S3 전송은 어떤 HTTP client와 어떤 transfer runtime을 쓰는가”를 명시할 수 있어야 합니다. bluetape4k-aws는 그 결정을 프레임워크 안에 완전히 숨기기보다, 설정과 client factory, operation helper로 분리해 둡니다.

함께 쓸 수 있나

가능합니다. 다만 한 AWS 경계에는 하나의 책임 주체만 두는 것이 좋습니다. 예를 들어 같은 Spring Boot 애플리케이션에서 Spring Cloud AWS와 bluetape4k-aws-spring-boot가 같은 SQS queue listener를 동시에 관리하게 만들면, 누가 receive loop, ack, retry, visibility timeout을 책임지는지 흐려집니다.

현실적인 조합은 이렇게 나뉩니다.

• Spring Boot 애플리케이션의 Spring 중심 SQS/S3/config 통합은 Spring Cloud AWS에 맡긴다.
• Kotlin helper가 필요한 일부 module에서는 bluetape4k-aws-java나 bluetape4k-aws-kotlin만 사용한다.
• Ktor 서비스는 bluetape4k-aws-ktor를 사용하고, Spring Boot 서비스와는 공통 AWS helper와 설정 규칙만 맞춘다.
• 대용량 S3 전송처럼 CRT와 TransferManager 선택이 중요한 곳은 bluetape4k-aws-java helper를 별도 경계로 둔다.

핵심은 중복 등록을 피하는 것입니다. 같은 queue, 같은 bucket operation, 같은 configuration source를 두 라이브러리가 동시에 소유하지 않도록 서비스 경계를 정하면 됩니다.

선택 기준은 프레임워크 선호가 아니라 반복되는 AWS 작업을 어디에 맡길지입니다.

선택 가이드

다음 기준으로 지금 적합한 출발점을 고를 수 있습니다.

상황	먼저 볼 선택
Spring Boot 애플리케이션이고 Spring Cloud 관례가 이미 팀 표준이다.	Spring Cloud AWS
Spring Boot에서 AWS 통합을 starter, properties, template, listener로 설명하고 싶다.	Spring Cloud AWS
Kotlin coroutine을 중심으로 AWS Java SDK v2 async client를 감싸야 한다.	bluetape4k-aws-java
AWS Kotlin SDK를 쓰면서 CRT 기본 방식과 DSL helper를 같이 쓰고 싶다.	bluetape4k-aws-kotlin
Spring Boot 4 서비스 또는 Ktor 3 서비스가 같은 AWS helper 규칙을 사용해야 한다.	bluetape4k-aws
Ktor에서 SigV4, S3 REST client, SQS consumer, DynamoDB plugin이 필요하다.	bluetape4k-aws-ktor
S3 대용량 파일 처리에서 CRT와 TransferManager 사용을 명시하고 싶다.	bluetape4k-aws-java / bluetape4k-aws-spring-boot
Exposed database registry를 AWS Secrets Manager나 Parameter Store와 연결하고 싶다.	bluetape4k-aws-exposed / bluetape4k-aws-spring-boot

이 기준은 어느 라이브러리가 더 우수하다는 판정표가 아닙니다. Spring Cloud AWS는 Spring 애플리케이션을 Spring답게 운영하기 위한 성숙한 선택입니다. bluetape4k-aws는 Kotlin/JVM 서비스가 AWS SDK를 직접 다룰 때 반복되는 작업을 줄이고, 선택한 프레임워크가 Spring Boot 4이든 Ktor 3이든 같은 공통 helper를 사용할 수 있게 하기 위한 선택입니다. 앞으로는 Spring Cloud AWS가 제공하는 Spring Boot 편의 기능을 계속 흡수하면서, Ktor 통합 기능도 함께 넓혀 가는 것이 목표입니다.

운영에서 남는 책임

어느 라이브러리를 쓰더라도 AWS 운영 책임이 사라지지는 않습니다. IAM policy, encryption, timeout, retry, idempotency, queue ordering, DLQ, S3 multipart threshold, DynamoDB capacity, table migration, local emulator와 실제 AWS의 차이는 여전히 애플리케이션과 운영 환경이 결정해야 합니다.

특히 SNS HTTP endpoint를 받을 때는 signature validation을 반드시 애플리케이션 책임으로 다뤄야 합니다. bluetape4k-aws-spring-boot의 SNS parser는 message type, topic ARN, token, payload를 편하게 꺼내는 도구이지, 인증을 끝내는 보안 장치가 아닙니다. Spring Cloud AWS를 쓰더라도 같은 원칙이 적용됩니다. 라이브러리가 parsing과 wiring을 도와도 trust boundary는 별도로 설계해야 합니다.

참고한 자료

• Spring Cloud AWS: GitHub README
• Spring Cloud AWS 4.0.2: Reference documentation
• bluetape4k-aws: GitHub repository
• bluetape4k-aws: aws-spring-boot README
• bluetape4k-aws: aws-ktor README

다음 글에서는 examples/와 bluetape4k-workshop/aws에 있는 실전 예제를 더 상세하게 소개할 예정입니다. 이번 글이 선택 기준을 세웠다면, Part 5는 그 기준이 실제 코드에서 어떻게 이어지는지 확인하는 글이 됩니다.

시리즈 링크

• Part 1: bluetape4k-aws overview
• Part 2: core module과 AWS 서비스 지원 현황
• Part 3: Spring Boot와 Ktor 통합
• Part 4: bluetape4k-aws vs Spring Cloud AWS
• Part 5: 실전 예제로 적용하기