왜 나는 무료 오픈소스 AWS emulator를 만들고 있는가
I’m happy to translate the article for you, but I need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have that, I’ll provide the Korean translation while keeping the source link, formatting, markdown, and technical terms unchanged.
배경
며칠 전, localstack:latest가 이제 계정과 인증 토큰을 필요로 하게 되면서 CI가 실패하기 시작했습니다. 빌드가 깨졌습니다. 나는 한동안 LocalStack이 독점 모델로 전환하는 것을 눈치챘지만, 이번이 바로 실질적으로 영향을 미친 순간이었습니다. 동료도 같은 문제를 발견했지만, 나는 이미 해결 방안을 작업 중이었습니다. 빌드를 패치했지만, 여전히 남은 질문은 다음과 같습니다: 실제 문제가 드러나기 전에 오래된 버전을 얼마나 오래 사용할 수 있을까?
나는 테스트에 깊은 애정을 가지고 있습니다— Chai.js의 유지 관리자가 될 정도로요. 무언가를 만들 때, 테스트 인프라가 최우선입니다.
왜 목(mock)이 문제인가
나는 어떤 종류의 테스트가 중요한지에 대해 구체적인 의견을 가지고 있다. 나는 목 자체를 싫어하는 것이 아니라, 대부분의 코드베이스가 목을 사용하는 방식을 싫어한다. 목에 과도하게 의존하면 실제 동작을 검증하지 못하는 테스트가 된다. 이런 테스트는 실제 결과보다 함수가 올바른 순서로 호출되는지를 확인하는, 일종의 배관 작업을 테스트하게 된다.
가장 안 좋은 점은 목을 사용한 테스트가 잘못된 자신감을 주는 경우이다. 테스트가 잘못된 내용을 주장하고, 목은 단순히 당신이 지정한 값을 반환하고, 테스트는 통과하지만, 코드에는 여전히 버그가 존재해 프로덕션에 배포될 수 있다.
AWS 위에서 개발한다면, 200을 모든 것에 반환하는 스텁이 아니라 AWS와 같은 동작을 하는 무언가와 통신하는 통합 테스트가 필요하다. 에뮬레이터는 실제 동작을 구현해야 한다: API A를 호출하고 그 다음 API B를 호출하면 AWS에서 부수 효과 C가 발생한다면, 테스트 환경에서도 부수 효과 C가 발생해야 한다.
그것이 LocalStack이 제공하던 것이며, 내가 유지하고 싶었던 무료 및 오픈 소스이다.
Source: …
fakecloud 소개
저는 2026년 4월 4일에 fakecloud를 시작했습니다. 시작 3일 만에 이미 13개의 AWS 서비스를 지원했으며, 300개가 넘는 커밋과 1,000개 이상의 테스트가 작성되었습니다.
이러한 빠른 진행을 가능하게 만든 두 가지 핵심 요소는 다음과 같습니다:
- LLM을 힘 증폭기로 활용 – 저는 대형 언어 모델을 많이 사용했지만, 이해하지 못하는 코드를 생성하기 위해서가 아니라 엄격한 가드레일 아래 개발 속도를 높이기 위해서였습니다. 모든 기능은 엔드‑투‑엔드(E2E) 테스트와 함께 제공되며, 이 테스트가 바로 가드레일 역할을 합니다. LLM이 실제 AWS 동작과 일치하지 않는 코드를 생성하면 테스트가 이를 잡아냅니다.
- Rust – 정적 타입, 강력한 타입 시스템, 그리고 가비지 컬렉션이 없는 성능을 이유로 Rust를 선택했습니다. fakecloud는 100 ms 미만에 시작하고 단일 바이너리로 실행됩니다—Docker도, 런타임 의존성도 없습니다.
fakecloud는 확장 가능한 프로덕션 클라우드가 아니라 테스트 도구입니다. 테스트 도구에 가장 중요한 요구사항은 정확성입니다.
실제 적용에서의 정확성
실제 AWS에서 CreateQueue → SendMessage → ReceiveMessage 순으로 호출했을 때 특정 속성을 가진 메시지를 받는다면, fakecloud도 정확히 동일하게 동작해야 합니다. 이와 다른 동작은 버그입니다.
현재 우리는 다음을 통해 이를 검증하고 있습니다:
- 공식
aws-sdk-rust크레이트를 사용한 280개 이상의 E2E 테스트. - 공식 AWS Smithy 모델을 기준으로 검증된 34,856개의 자동 생성 적합성 테스트 변형, 13개 서비스의 983개 API 작업 전부를 100 % 적합성으로 커버.
단기 계획: 실제 AWS 계정과 fakecloud를 나란히 실행하여 테스트 스위트를 동시에 실행하고, 행동 일치를 자동으로 검증할 예정입니다.
지원되는 서비스
| 서비스 | 작업 |
|---|---|
| S3 | 107 작업 – 객체, 멀티파트 업로드, 버전 관리, 수명 주기, 알림, 암호화 |
| SQS | 23 작업 – FIFO 대기열, 데드레터 대기열, 롱 폴링, 배치 작업 |
| SNS | 34 작업 – SQS로 팬아웃, HTTP 전달, 필터 정책, 플랫폼 애플리케이션 |
| EventBridge | 57 작업 – 패턴 매칭, 예약 규칙, 연결, API 대상, 엔드포인트 |
| IAM | 128 작업 – 사용자, 역할, 정책, 그룹, 인스턴스 프로파일, OIDC/SAML 공급자 |
| STS | 11 작업 – 역할 가정, 세션 토큰, 연동, 자격 증명 만료 |
| SSM | 146 작업 – 파라미터, 문서, 명령, 유지 관리 창, 연결, 자동화, 세션 |
| DynamoDB | 57 작업 – 테이블, 항목, 트랜잭션, PartiQL, 백업, 글로벌 테이블, 스트리밍 |
| Lambda | 10 작업 – 함수 CRUD, 호출, 이벤트 소스 매핑 |
| Secrets Manager | 23 작업 – 버전 관리, 소프트 삭제, 순환, 복제, 리소스 정책 |
| CloudWatch Logs | 113 작업 – 그룹, 스트림, 필터링, 전달, 변환기, 이상 탐지 |
| KMS | 53 작업 – 암호화, 별칭, 키 관리, 권한 부여, 사용자 지정 키 저장소 |
| CloudFormation | 8 작업 – 템플릿 파싱, 리소스 프로비저닝 |
교차 서비스 동작
서비스 간에 상호 작용할 수 있습니다. 예를 들어 S3 알림은 SNS 또는 SQS로 전달될 수 있고, SNS는 SQS로 팬아웃할 수 있으며, EventBridge 규칙은 일정에 따라 트리거되어 대상에 전달됩니다. 이러한 교차 서비스 동작은 통합 테스트에 필수적이며, 다른 에뮬레이터에서는 종종 누락되거나 잘못 구현됩니다.
사용법
curl -fsSL https://raw.githubusercontent.com/faiscadev/fakecloud/main/install.sh | bash에뮬레이터 실행:
fakecloudAWS SDK를 http://localhost:4566 주소와 더미 자격 증명으로 지정:
Endpoint: http://localhost:4566
AccessKeyId: dummy
SecretAccessKey: dummy이것만으로도 로컬 AWS 호환 환경에서 테스트를 시작할 수 있습니다.
라이선스 및 기여
코드는 에 호스팅되어 있으며 AGPL‑3.0 하에 공개됩니다—상업적 사용을 포함한 자유롭고 오픈 소스 라이선스입니다.
통합 테스트를 위한 로컬 AWS 에뮬레이터가 필요하다면 fakecloud를 사용해 보세요. 실제 AWS와 다르게 동작하는 부분이 있으면 이슈를 열어 주세요; 버그이며, 저희가 수정하겠습니다.