floci 는 자기 기계에서 돌리는 클라우드 에뮬레이터 모음이다. AWS, Azure, GCP, OCI 네 곳에 각각 별도 프로그램과 별도 포트, 별도 네이티브 바이너리가 붙고 모두 MIT 라이선스이며 서로 의존하지 않는다. 하나만 띄워도 되고 넷을 나란히 띄워도 된다. 클라우드 계정도 auth token 도 필요 없고 기능 제한도 텔레메트리도 없다. Docker 만 돌면 옮길 수 있고 Windows, macOS, Linux 가 같은 것을 쓴다. 막 나온 2.4 에는 오백 건이 넘는 변경이 들어갔고 거의 모두 서비스 커버리지의 깊이에 쓰였다.

네 개의 클라우드, 네 개의 프로그램, 네 개의 포트

배치는 단순하다. 본체가 AWS 를 맡아 4566 에서 기다리고 Azure 판이 4577, GCP 판이 4588, OCI 판이 4599 에서 기다린다. 하나하나가 컨테이너 하나, 포트 하나, 프로토콜 한 벌이고 데이터는 섞이지 않는다. 여러 클라우드를 동시에 만지는 사람에게는 기능 목록보다 실용적이다. 같은 테스트 스크립트에서 endpoint 만 바꾸면 다른 클라우드에서 다시 돌릴 수 있고, 클라우드마다 가상 기계와 계정을 준비하지 않아도 된다.

이름은 권적운 가운데 팝콘처럼 생긴 구름에서 왔고 영어로는 cirrocumulus floccus 라고 쓴다. 이름과 목표가 맞는다. 클라우드를 책상으로 옮기려는 것이 아니라 클라우드의 접점을 책상에 한 벌 두어 코드를 우선 작은 규모에서 통과시키려는 것이다.

네이티브 바이너리가 아끼는 몇 초

에뮬레이터는 Quarkus Native 로 빌드되고 아래에 GraalVM 의 Mandrel 배포판이 있다. 나오는 것은 JVM 안의 꾸러미가 아니라 네이티브 기계어다. 공개된 수치는 차가운 시작까지 24 밀리초, 대기 시 메모리 13 MiB, 이미지 약 90 MB 다. 코드를 쓰는 사람에게는 빠르다는 뜻뿐이다. 파이프라인에는 다른 뜻이 있다. 작업마다 환경을 만들고 끝나면 걷어 내는 방식이 통하려면 시작 비용이 스무 개 병렬 작업을 감당할 만큼 싸야 한다.

이런 도구의 흔한 방식은 컨테이너 안에서 완전한 서비스를 돌리는 것이고, 시작에 몇 초에서 수십 초, 상주로 수백 MB 를 차지하며, 병렬 행렬이 오면 메모리를 다투고 시간 초과를 기다린다. 네이티브 컴파일은 그 둘을 함께 낮춘다. 대가는 긴 빌드와 일부 의존성에 반사 설정을 더하는 일이고, 사전 컴파일 방식이 공통으로 지는 거래다.

진짜 엔진이 받쳐 주는 프로토콜 충실도

에뮬레이터가 가장 자주 넘어지는 곳은 겉보기가 맞는 경우다. 데이터 구조도 상태 코드도 같고 동작이 다르며, 로컬 테스트는 모두 통과하고 운영 첫 시간에 깨진다. floci 의 답은 흉내로 때우지 않고 무거운 데이터 서비스를 진짜 엔진에 넘기는 것이다. Lambda 호출은 모두 진짜 Docker 컨테이너에서 돌고 Node.js, Python, Java, Go 의 환경 변수는 운영과 맞춰 둔다. RDS 는 진짜 PostgreSQL, MySQL, MariaDB 를 띄우고 전체 수명 주기와 스냅숏 복원이 있으며 JDBC 트래픽과 IAM 데이터베이스 인증을 지난다.

ElastiCache 는 진짜 Redis 컨테이너이고 floci 가 앞에서 SigV4 프록시를 맡는다. MSK 뒤에는 Redpanda, Athena 질의는 DuckDB sidecar 로 떨어지고, EC2 의 RunInstances 는 SSH 키 주입과 UserData 실행, 두 세대의 IMDS 메타데이터 서비스를 갖추어 컨테이너를 띄운다.

프로토콜 층에서 둘은 따로 짚을 만하다. IAM 은 장식이 아니다. Lambda, RDS, ECS, EC2, MSK, ECR, OpenSearch 가 모두 SigV4 검증을 하고, 정책을 잘못 쓰면 운영이 아니라 로컬에서 떨어진다. 프로젝트는 AWS SDK 호환 테스트 1925 건을 스스로 유지하며 전부 통과한다고 밝힌다. 공식 자기 보고이고 제3자 검증은 아니지만, 지금 쓰는 환경을 대체할 수 있는지 판단하기에는 충분하다.

하나의 콘솔, 네 개의 실행 환경

명령줄 말고 화면도 있다. 구조는 보기보다 공들였다. 브라우저의 UI 는 React 와 Vite 로 만들어져 4500 에서 기다리고 /api 로 시작하는 요청만 받는다. 그 뒤에서 Bun 과 Hono 로 쓴 Cloud Proxy API 가 4501 에서 기다리며 클라우드별로 AWS, Azure, GCP, OCI 네 어댑터에 나눠 준다. 어댑터가 각 실행 환경의 프로토콜로 옮기고 4566 에서 4599 포트로 내려보낸다.

문서의 한 줄이 이 분업을 정확히 말한다. UI 는 클라우드를 모르고 프록시는 구현을 모르며 어댑터가 옮기고 실행 환경이 실행한다.

장점은 화면과 클라우드가 떨어져 있다는 것이다. 클라우드를 늘리려면 어댑터와 서비스 기술을 더하면 되고 콘솔은 바꾸지 않는다. 실제로는 첫 화면이 도는 인스턴스의 서비스 수와 자원 수를 내고, 클라우드 전환은 오른쪽 위 버튼 하나이며, 저장 화면에서는 버킷 이름과 종류, 속한 클라우드, 만든 시각이 보이고 만들기와 지우기가 같은 줄에 있다. Azure 인스턴스는 9 of 28 services available 로 나온다. 커버리지는 클라우드의 성숙도를 따라가며 넷을 똑같이 다루지 않는다.

2.4 가 힘을 쓴 곳

2.4 는 10 월 31 일에 나왔다. 저장소가 자동으로 만드는 변경 기록에 따르면 이 판에는 새 기능 210 건, 성능 개선 10 건, 결함 수정 294 건, 합계 514 건이 들어 있다. 어디로 몰렸는지는 한눈에 보인다. EC2 가 62 건, CloudFormation 이 59 건, DynamoDB 가 40 건, Lambda Web 이 22 건이다. CloudFormation 쪽은 구체적인 자원 유형을 채우는 일로, EC2 접두사 목록, WAFv2 의 IP 집합, SES 의 메일 신원과 수신 규칙, Route53 레코드 집합, Redshift 이벤트 구독, RDS 클러스터의 역할 연결이 들어간다.

하나씩 읽으면 지루한 항목뿐이다. 모아 보면 말하는 것은 하나다. 인프라 코드를 그대로 로컬에서 돌리고 싶다는 것이다. Terraform, OpenTofu, CloudFormation 템플릿을 진짜 클라우드에서 시험하는 비용은 돈과 시간이고, 로컬에서 시험하는 비용은 재시작 한 번이다. 공개 주기도 그 쓰임에 맞춰 안정판을 매달 15 일과 월말에 자르고 그 사이에는 nightly 표시가 주 줄기를 따라가므로, 고친 것이 다음 날 손에 들어온다.

시작하기 전에 알아 둘 것

커버리지가 고르지 않다는 것이 먼저 받아들일 현실이다. AWS 쪽이 주력이고 서비스는 백을 넘으며, Azure, GCP, OCI 는 눈에 띄게 작다. 콘솔에는 coming soon 표시가 붙은 항목도 남아 있다. 어느 클라우드를 주로 쓸지 그 화면의 서비스 목록을 먼저 보고 정하고, 넷이 같은 두께라고 가정하지 않는 편이 좋다.

Docker 도 필요하다. 뒤에서 진짜 엔진을 띄우는 서비스는 모두 컨테이너 실행 환경이 있어야 하고, 그 층이 기계에 없으면 그 능력은 비어 있다. 상태도 기본이 일회용이다. 멈추고 다시 띄우면 깨끗한 클라우드가 나온다. 테스트에는 장점이고 오래 로컬 데이터를 쌓으려는 사람에게는 단점이니, 쓰기 전에 저장 설정을 먼저 읽어 두자.

부하 시험에 쓸 도구도 아니다. 지키는 것은 프로토콜 동작이고 처리량 지표가 아니다. 공개된 Lambda 처리량은 초당 289 회 요청으로, 기능을 확인하기에는 충분하고 용량을 재는 데는 의미가 없다.

더 근본적인 판단은 로컬 클라우드의 값이 청구서를 아끼는 데 있지 않다는 것이다. 고치고 돌리고 결과를 보는 순환을 수십 초로 줄이고, 코딩을 돕는 도구에 마음껏 망가뜨려도 되는 자리를 주는 데 있다. 에뮬레이터 네 개, 콘솔 하나, 네이티브 바이너리 한 벌은 그 순환을 둘러싼 거래다. 그래서 프로토콜과 엔진이 촘촘하고 커버리지가 성긴 것이다.

클라우드를 내 기계로 옮기는 것은 안 된다. 클라우드의 접점을 옮기는 것은 된다. floci 가 고른 것은 뒤쪽 길이다. 실제 환경을 대신하겠다고 약속하지 않고, 시도할 때마다의 실패가 청구서 밖에서 일어난다고만 약속한다.