AWS 무료 에뮬레이터 Floci를 사용해 보았습니다.

학습 예제를 만들 일이 있어서 LocalStack을 써보려고 했는데 Community 버전이 3월말에 종료된다고 해서

무료를 찾다보니 Floci라는 것을 봤습니다.

 

AWS를 로컬에서 흉내 내는 도구, 비용 아끼는 데 도움이 되는 도구, 많아야 학생 실습용 정도라고 생각했는데요.

 

그런데 이번에 이걸 가지고 예제 앱을 여러 개 붙여 보고, 마지막엔 RDS랑 ElastiCache까지 연결도 해보고,

거기에 Grafana, Prometheus, Loki까지 올려보니 생각보다 나쁘진 않았습니다.

 

이 글은 설치법을 차근차근 설명하려는 글은 아닙니다.  

설치는 여기에서 확인할 수 있습니다.

https://github.com/hectorvent/floci

GitHub - hectorvent/floci: Light, fluffy, and always free - AWS Local Emulator

 

오히려 직접 만져보면서 "처음엔 이렇게 생각했는데, 실제로는 이쪽이 더 중요했다" 싶었던 부분들을 적어보려는 글에 가깝습니다.

 

읽는 분이 초보자라면 아마 저와 비슷한 착각을 몇 번쯤 하실 것 같고,  

이미 AWS를 어느 정도 만져본 분이라면 "로컬 에뮬레이터를 어디까지 믿어야 하는가"를 정리하는 글로 읽히면 좋겠습니다.

 

Floci를 보게 된 이유는 의외로 단순했다

AWS를 공부하거나 테스트하려고 하면 너무 당연하게 깔려 있는 전제가 있습니다.

• AWS 계정이 필요하다.
• 외부 네트워크로 실제 AWS endpoint에 붙을 수 있어야 한다.

그런데 막상 교육 환경이나 폐쇄망 환경을 생각해 보면 이게 생각보다 자주 안 맞습니다.

• 학생 입장에선 계정 만들려고 카드부터 연결하는 게 부담
• 어떤 조직은 외부 AWS에 바로 붙는 것 자체가 어려움
• 또 어떤 팀은 계정 발급이나 권한 승인보다 먼저 구조를 확인 필요

이럴 때 필요한 건 그냥 "무료로 AWS 쓰는 법"이 아니라,  

계정이나 네트워크 문제랑 조금 떨어져서 AWS를 어떻게 쓰는지 먼저 연습해볼 수 있는 환경이었습니다.

 

제가 Floci를 본 이유도 딱 그 정도였습니다.  

학생들한테 "계정부터 만들어라"라고 하기 전에, 적어도 흐름은 로컬에서 먼저 익히게 해주고 싶었습니다.

 

LocalStack VS Floci

Floci를 이야기하면 거의 자동으로 LocalStack 얘기가 같이 따라옵니다.  

자료도 훨씬 많고, 이름도 더 익숙하니까요.

 

하지만 LocalStack은 2026년 3월에 Community Edition 종료 수순에 들어가므로 유료 또는 다른 방식으로 사용해야 합니다.

https://blog.localstack.cloud/2026-upcoming-pricing-changes/

Important Updates to Pricing & Packaging for LocalStack for AWS

 

LocalStack은 여전히 존재합니다. 다만 최근 변화들을 보고 나면, 예전처럼 "계정 없이 바로 시작하는 로컬 AWS 에뮬레이터"를 찾던 사람 입장에서는 자연스럽게 다른 선택지도 보게 됩니다. 저는 그 흐름 안에서 `floci`를 보게 됐습니다.

 

그러니까 Floci의 가치는 누가 빠진 자리를 대신한다는 데만 있는 건 아닙니다.  

애초에 시작할 때 단순하다는 점이 꽤 큽니다.

 

써보니 '무료'보다 '반복 가능성'이 더 크게 느껴졌다

로컬 에뮬레이터를 보면 보통 제일 먼저 드는 생각이 비용입니다.  

틀린 말은 아닙니다. 

RDS, ElastiCache 같은 건 실제 AWS에 올리자마자 과금이 시작되니까요.

그런데 막상 손으로 계속 붙여보다 보니, 비용보다 더 크게 느껴진 건 반복 가능성이었습니다.

 

이번에 제가 만든 예제들도 대부분 "서비스 하나 호출해보기" 수준이 아니라,  

실제로 AWS에서 자주 보게 되는 조합을 로컬에서 계속 반복해볼 수 있게 하는 쪽에 가깝습니다.

• S3 + DynamoDB
• SQS + SNS + DynamoDB
• Cognito
• DynamoDB + CloudWatch Logs
• Secrets Manager + KMS
• Kinesis
• CloudFormation
• RDS + ElastiCache

 

이걸 실제 AWS에서 처음부터 다 만지기 시작하면,

코드보다 먼저 계정, 권한, 리전, 과금, 정리 순서 같은 것들이 자꾸 앞에 나옵니다.

 

반면 Floci에서는 적어도 기본 전제가 고정돼 있습니다.

• endpoint는 http://localhost:4566
• region은 us-east-1
• 자격증명은 더미로도 충분하고
• CLI나 SDK 패턴도 꽤 익숙한 쪽을 유지합니다

이러면 적어도 "AWS를 어떤 흐름으로 생각해야 하는가"를 먼저 반복해 볼 수 있습니다.

 

여기서 중요한 건, 이게 실제 AWS랑 같다는 뜻은 아니라는 점입니다.  

오히려 이번에 만져보면서는 그 반대를 더 자주 느꼈습니다.

 

에뮬레이터는 어디까지나 에뮬레이터입니다.  

실제 AWS의 운영 현실을 완전히 복제해주는 도구가 아니라,  

AWS의 리소스 흐름과 사용 패턴을 로컬에서 연습하게 해주는 도구에 더 가깝습니다.

 

여기서 많이들 착각하는 것 같습니다.

 

• endpoint-url만 붙이면 끝난다
• 에뮬레이터에서 되면 실제 AWS에서도 당연히 된다.

둘 다 아주 틀린 말은 아닌데, 그대로 믿고 들어가면 금방 이상해집니다.

 

endpoint-url은 그냥 시작점일 뿐이고, 실제로는 profile을 따로 두거나 .aws-local 같은 식으로 격리하는 편이 훨씬 낫습니다.  

그리고 에뮬레이터에서 돌아갔다는 건 "흐름을 연습해봤다"에 더 가깝지, 운영 검증이 끝났다는 뜻은 아닙니다.

 

실제로 제일 오래 붙잡고 있었던 건 RDS랑 ElastiCache였다.

이번에 제일 기억에 남는 건 `RDS + ElastiCache` 예제를 붙이는 과정이었습니다.

처음엔 정말 단순하게 생각했습니다.

 

• Floci가 RDS를 지원한다.
• ElastiCache도 지원한다.
• 포트도 열려 있다.
• 그럼 Web + DB + Cache 예제도 금방 되겠지

그런데 이게 생각보다 전혀 안 됐습니다.

겉으로 보이는 에러는 전형적이었습니다.

• port binding 관련 에러
• Java 쪽 bind exception
• proxy가 안 붙는 느낌

솔직히 말하면 저도 한동안은 "포트 충돌인가?", "지원이 아직 덜 된 건가?" 쪽으로 생각했습니다.  

초보자라면 거의 반드시 여기서 비슷하게 생각할 것 같습니다.

 

그런데 실제 원인은 훨씬 덜 눈에 띄는 쪽에 있었습니다.

• docker.sock 접근 권한
• 컨테이너의 user/group
• docker.sock에 실제로 걸린 group id
• backend container를 붙이기 위한 runtime network

 

즉, 문제는 단순히 `RDS` API가 안 되는 게 아니었습니다.  

그 API 뒤에서 실제 backend container를 띄우는 런타임이 권한 때문에 막히고 있던 거였죠.

결국 제가 확인한 건 docker.sock의 group mismatch였고, 그걸 맞춘 뒤에야 예제가 제대로 붙었습니다.

 

이걸 겪고 나니까, 로컬 AWS 에뮬레이터에서 어려운 건 API 자체보다도  

그 API가 기대하는 런타임 전제를 내가 얼마나 이해하고 있는가?라는 생각이 더 강하게 들었습니다.

 

사실 저는 이게 꽤 중요한 감각이라고 생각합니다.  

클라우드 서비스를 쓴다는 건 문법만 아는 게 아니라, 그 서비스가 돌아가기 위해 필요한 조건들도 어느 정도는 같이 이해해야 한다는 뜻이니까요.

 

그래서 결국 Web + DB + Cache 예제 완성

중간에 그냥 포기할 수도 있었는데, 오히려 원인이 권한과 실행 환경 쪽이라는 걸 확인하고 나니까 더 만들어야겠다는 생각이 들었습니다.

결국 `product-catalog-cache`라는 hands-on을 추가했고, 구성은 일부러 아주 기본적으로 잡았습니다.

• Web UI
• API server
• RDS PostgreSQL
• ElastiCache

패턴도 일부러 `cache-aside`로 두었습니다.

• 조회는 cache 먼저 확인
• miss면 DB 조회
• DB 결과를 cache에 저장
• 쓰기 요청이 오면 cache invalidate

이렇게 하면 "원본 데이터는 어디에 있고, 가속 계층은 어디에 있는가"가 꽤 분명하게 보입니다.  

그리고 이런 구조는 실무에서도 너무 자주 보니까, 연습용으로도 나쁘지 않았습니다.

 

모니터링은 생각보다 훨씬 빨리 붙여야 했다

이번 작업에서 제 생각이 제일 많이 바뀐 부분은 아마 여기였습니다.

처음엔 저도 "로컬 실습인데 `Grafana`까지는 좀 과하지 않나?" 싶었습니다.

그런데 직접 작업하다 보니, 모니터링이 없으면 실패 원인을 자꾸 엉뚱하게 짚게 됩니다.

 

예를 들어 똑같이 "안 된다"여도 실제 의미는 다 다릅니다.

• 내 API 코드가 틀렸는가?
• Floci endpoint가 죽었는가?
• RDS backend container가 안 떴는가?
• ElastiCache proxy 포트가 안 붙었는가?
• AWS resource는 있는데 앱이 못 읽는가?

이걸 로그 몇 줄만 보고 계속 추측하기 시작하면 시간이 금방 사라집니다.

 

그래서 이번엔 아예 공용 monitoring stack을 붙였습니다.

• Grafana
• Prometheus
• Loki
• Promtail
• Floci service exporter

앱 메트릭과 서비스 메트릭은 생각보다 꽤 다릅니다.

앱 메트릭은 대체로 이런 걸 보여줍니다.

• 요청 수
• 응답 시간
• 특정 도메인 이벤트 수
• cache hit / miss

서비스 메트릭은 이런 걸 보여줍니다.

• SQS queue depth
• DynamoDB item count
• S3 object count / bytes
• CloudWatch Logs stream / event 수
• RDS / ElastiCache proxy reachability
• 현재 생성된 AWS local resource 수

 

둘을 분리해서 보기 시작하면, "뭔가 안 된다"가 아니라

• 애플리케이션은 정상인데 service side가 비정상인지
• resource는 살아 있는데 app이 못 붙는지
• app은 붙지만 기대한 데이터가 안 나오는지

를 훨씬 빨리 구분할 수 있습니다.

 

결국 모니터링은 나중에 붙이는 장식이라기보다,  

적어도 저한테는 디버깅이 어디서부터 꼬였는지 가늠하게 해주는 기준점에 가까웠습니다.

물론 정상 어플리케이션이 아니기 때문에 APM까진 넣지 않았지만 추후에 필요하시면 넣으시겠죠?

 

Floci를 누구에게나 무조건 추천할 생각은 없습니다.

그래도 직접 써본 기준으로는 이런 경우 꽤 괜찮았습니다.

 

학생 / 초보자 / 교육 환경 이쪽은 꽤 잘 맞는 편이라고 느꼈습니다.  

AWS 계정 준비 자체가 장벽이거나, 수강생 전원이 같은 조건에서 반복 실습해야 하거나,  

무엇보다 먼저 개념과 흐름을 익히는 게 중요할 때는 꽤 편합니다.

 

실제 AWS endpoint에 바로 붙기 어려운 환경에서도 의미가 있습니다.  

계정 발급이나 네트워크 승인이 바로 안 나는 경우, 또는 운영 반입 전에 구조를 먼저 검증해보고 싶은 경우엔  

"적어도 로컬에서 이 흐름이 어떻게 생겼는가"를 먼저 확인할 수 있다는 것만으로도 꽤 도움이 됩니다.

 

비용보다 반복성이 중요한 경우

여러 아키텍처 조합을 빠르게 반복해보고 싶은 사람에게도 잘 맞습니다.  

CLI나 SDK 패턴을 계속 손으로 익혀야 하는 경우라면, 매번 실제 클라우드 환경을 정리하고 다시 올리는 것보다 훨씬 가볍습니다.

 

실제 AWS 계정이 이미 있고, 운영 검증이 우선인 경우

이 경우엔 결국 IAM, 네트워크, 권한, 리전, 계정 구조를 실제 AWS에서 봐야 합니다.  

로컬 에뮬레이터로 개념을 확인하는 것보다, 실제 환경에서 빨리 검증하는 쪽이 더 낫습니다.

 

완벽한 AWS 동일성을 기대하는 경우

그건 애초에 에뮬레이터에 기대할 성질이 아닙니다.  

로컬 도구는 학습과 빠른 반복을 위한 것이지, 실제 AWS 전체 현실을 완전히 대신해 주는 건 아니니까요.

그래서 `floci`를 "AWS를 대체하는 도구"라고 이해하면 조금 방향이 어긋납니다.  

오히려 AWS를 배우고, 구조를 실험하고, 반복해보는 데 괜찮은 연습장 정도로 보는 편이 더 맞습니다.

 

이번에 예제와 모니터링을 같이 만든 이유

이번에 단순히 예제 앱만 만든 게 아니라 monitoring stack까지 같이 붙인 이유는,  

초보자가 제일 많이 배우는 순간이 "성공했다"보다 "왜 실패했는지를 나눠서 이해했을 때"라고 생각했기 때문입니다.

 

마무리

이번에 직접 붙여보면서 느낀 건, Floci의 핵심을 "무료"라는 단어 하나로 설명하기엔 좀 부족하다는 점이었습니다.

 

AWS를 어떻게 사고해야 하는지 연습할 수 있다는 점,  

초보자가 놓치기 쉬운 runtime 조건을 강제로 보게 만든다는 점,  

그리고 모니터링을 통해 앱 문제와 서비스 문제를 분리해서 보게 해준다는 점이 더 크게 남았습니다.

 

특히 RDS + ElastiCache 구간에서 부딪힌 문제는 저한테 꽤 오래 남을 것 같습니다.  

겉으로는 Java bind error처럼 보여도, 실제로는 docker.sock 권한과 group 정렬 문제였고,  

그걸 잡고 나서야 비로소 "지원 서비스 목록"이 실제 동작으로 이어졌으니까요.

 

이건 초보자에게도 꽤 중요한 감각이라고 생각합니다.  

클라우드 서비스를 쓴다는 건 단순히 API 문서를 읽는 게 아니라,  

그 서비스가 돌아가기 위해 필요한 실행 전제를 같이 이해하는 일이기도 하니까요.

 

그래서 저는 `floci`를 지금 이렇게 정리하고 싶습니다.

 

모든 사람에게 꼭 필요한 도구는 아닙니다.  

그런데 어떤 환경에서는 충분히 실용적이고,  

AWS를 처음 배우는 사람에게는 생각보다 좋은 훈련 도구가 될 수 있습니다.

 

시간 되시면 제가 테스트한 저장소도 한 번 보셔도 좋겠습니다.

 

- 공식 Git: https://github.com/hectorvent/floci

GitHub - hectorvent/floci: Light, fluffy, and always free - AWS Local Emulator

- 제가 테스트한 Git: https://github.com/niceguy61/floci_test

GitHub - niceguy61/floci_test