Fakecloud: 통합 테스트용 로컬 AWS 에뮬레이터

AI 요약

Fakecloud는 애플리케이션 코드에서 일반 AWS SDK, CLI, IaC 도구를 그대로 사용하면서 로컬 환경에서 통합 테스트를 실행하는 오픈소스 에뮬레이터입니다. 제작자는 단일 바이너리나 Docker 이미지로 실행하고, 계정이나 인증 토큰 없이 더미 자격 증명을 사용할 수 있다고 설명합니다. 라이선스는 AGPL-3.0입니다.

테스트에서 제공하는 기능

앱은 AWS API를 호출하고, 테스트 코드는 Fakecloud SDK를 이용해 실행 결과를 확인하거나 비동기 작업을 직접 제어합니다. TypeScript, Python, Go, PHP, Java, Rust SDK가 있으며, 이메일·메시지·Lambda 호출 등을 사후에 들여다보고 대기열 초기화나 검증을 수행합니다. S3 알림, SNS 팬아웃, EventBridge 대상, DynamoDB Streams, Cognito 트리거, Step Functions 작업 연동 등 서비스 간 동작도 지원한다고 안내합니다.

제작자는 105개 서비스와 7,508개 작업을 제공하며, 구현된 API 작업 3,932개를 대상으로 Smithy 모델에서 생성한 테스트 변형 248,557개가 모두 통과한다고 주장합니다. 다만 페이지의 비교표에는 46개 서비스가 ‘완전한 적합성’을 갖췄다고 적혀 있습니다. Hacker News 댓글에서는 이 주장이 DynamoDB에 해당하지 않는다는 반론과 함께 구체적인 테스트 결과가 제시됐습니다.

적합성 주장에 대한 검증

한 댓글 작성자는 DynamoDB 테스트 1,279건 중 583건이 실패했다며, 중첩 속성 갱신 오류, 요청하지 않은 필드 반환, 같은 키의 중복 갱신 등을 예로 들었습니다. 제작자는 해당 문제를 확인하고 수정에 착수했으며, Parity Suite를 CI에 연결하겠다고 답했습니다. 따라서 제품 소개의 적합성 수치만으로 실제 서비스와의 동작 일치를 판단하기는 어렵습니다. DynamoDB Local도 실제 AWS와 다른 결과를 낼 수 있다는 지적도 나왔습니다.

테스트 환경을 둘러싼 의견

댓글에서는 로컬 에뮬레이터가 비용과 설정 시간을 줄여주지만, 실제 AWS의 동작과 차이가 생길 수 있다는 우려가 맞섰습니다. 일부는 실제 AWS에 테스트용 인프라를 만들어 검증하는 편이 더 높은 신뢰를 준다고 주장했고, 다른 이용자는 이 방식이 로컬 에뮬레이터와 종단 간 테스트의 차이를 놓친다고 반박했습니다. 인라인 목(mock)이나 의존성 주입을 선호하는 의견도 있었습니다.

설치 방식과 프로젝트 신뢰도에 관한 논쟁도 있었습니다. 웹사이트의 설치 스크립트를 내려받아 바로 셸에서 실행하는 방식은 검토와 무결성 확인이 어렵다는 비판이 나왔고, 제작자 신원과 사이트 완성도를 우려하는 댓글도 있었습니다. 반면 curl 파이프 설치는 흔한 방식이라는 반응과, Cargo로 설치할 수 있다는 안내도 이어졌습니다.

Hacker News 반응

• @igetspam — LocalStack이 떠난 자리를 Floci가 이미 채우고 있는데, Fakecloud는 Floci와 어떻게 다른가요?
  • @WalterGR — Floci는 어제 댓글 47개가 달린 토론에서 다뤄졌습니다.
• @bilekas — 큰 시스템은 기반 작업이 많이 필요합니다. 예를 들어 Terraform 인프라 설정을 넘기면 도구가 직접 환경을 구성하는 기능이 있으면 좋겠습니다.
  • @igetspam — 저는 Floci와 floci-gcp에서 Terraform을 매주 사용합니다.
• @Lucasoato — 이런 프로젝트는 반갑지만, 강한 커뮤니티가 없으면 창업자가 회사를 만들고 투자받은 뒤 유용한 기능을 유료화하는 일이 걱정됩니다. LocalStack에서 그런 모습을 봤습니다.
• @otterley — MiniStack도 있습니다. LocalStack이 개발자 작업 흐름을 망가뜨리기 시작한 뒤 갈라져 나온 프로젝트입니다. Fakecloud와 웹사이트는 대충 AI로 만든 듯하고 제작자도 익명이라 신뢰를 쌓는 데 시간이 걸릴 것 같습니다. curl 파이프 설치도 꺼림칙합니다.
  • @straygarr — curl 파이프 설치는 리눅스에서 흔하고 AWS CLI도 사용합니다. 문제는 개발자를 신뢰하지 못해 악성 스크립트를 실행할 가능성이 있다는 뜻인가요?
  • @x3n0ph3n3 — curl 파이프는 설치를 되돌리기 어렵고, 자산에 서명이나 무결성 검사가 있는지 확인하기도 어렵습니다.
• @arpinum — ‘46개 서비스의 완전한 적합성’은 사실과 다릅니다. DynamoDB 구현은 API 전체에 한참 못 미칩니다.
  • @arpinum — 제 테스트 1,279건 중 583건이 실패했습니다. ADD m.a.c :inc가 중첩 숫자를 바꾸지 않고 m.a.c라는 최상위 속성을 만들었습니다. TransactGetItems는 요청하지 않은 필드도 반환했습니다.
  • @lucas_vieira — 감사합니다. 말씀하신 세 가지부터 DynamoDB 문제를 확인하고 있습니다. Parity Suite도 좋네요. Fakecloud CI에 연결하고 있습니다.
• @goostavos — 통합 테스트의 가치는 목을 쓰지 않고 실제 외부 시스템이 기대대로 동작하는지 확인하는 데 있습니다. 실제 서비스 대신 가짜 서비스를 쓰면 실제 동작의 미묘한 차이를 놓칠 수 있습니다. AWS SDK로 테스트 인프라를 직접 만들면 더 높은 확신을 얻을 수 있습니다.
  • @joshribakoff — 통합 테스트와 종단 간 테스트를 혼동하는 것 같습니다.
• @zeronone — SES 지원은 정말 좋아 보입니다. LocalStack보다 낫습니다.

원문: Hacker News / 번역·요약: Trawling