AWS, 로컬에서 AWS 앱을 테스트하는 AWS Emulator 공개

AWS Emulator, AWS API를 내 노트북으로 가져오다

AWS는 2026년 11월 11일자 AWS News Blog에서 Daniel Abib의 글로 AWS Emulator를 발표했습니다. 개발자 자신의 컴퓨터에서 실행하는 Amazon Web Services 로컬 에뮬레이터입니다. AWS CLI, AWS SDK, 그리고 코딩 에이전트는 클라우드에서 쓰는 것과 같은 AWS API를 사용해 로컬 HTTPS 엔드포인트로 이 에뮬레이터에 접속합니다. AWS에 따르면 추가 서비스 요금은 없고, 실제로 AWS에 배포한 리소스에 대해서만 비용을 냅니다. 소스 코드는 GitHub에 공개되어 있습니다. Linux에서는 RPM 또는 Debian 패키지로 설치하고, macOS와 Windows에서는 Docker로 실행합니다. 바로 쓸 수 있는 이미지는 제공되지 않으며, 문서에 있는 짧은 Dockerfile로 직접 빌드해야 합니다.

로컬 실행 흐름

사용법은 단순합니다. 패키지를 설치하고 aws-emulator 명령을 실행한 뒤, 도구가 로컬 엔드포인트를 바라보게 설정합니다. 시작할 때 에뮬레이터는 자체 자격 증명, 설정 파일, 인증서를 만들어 ~/.aws/emulator/9297/ 디렉터리에 저장합니다. HTTPS는 127.0.0.1:9297에서 제공되므로 자기 컴퓨터에서만 접근할 수 있습니다. 그다음 AWS_ENDPOINT_URL 같은 환경 변수 몇 개를 설정하고, 실제 AWS 자격 증명을 공급할 수 있는 변수는 해제합니다. 애플리케이션 코드는 바꿀 필요가 없습니다.

키는 시작할 때마다 새로 만들어집니다. 액세스 키 ID는 EMULATOR로 시작하므로 실제 키와 혼동할 일이 없고, 다른 키로 서명한 요청은 거부됩니다. 계정은 하나뿐이며 번호는 000000000000입니다. 글의 시연에서는 S3 버킷을 만들고 객체를 복사한 다음, Kiro 코딩 에이전트에게 DynamoDB 테이블 생성, 항목 쓰기, 다시 읽기를 맡깁니다. 모두 실제 계정이 아니라 로컬 엔드포인트를 대상으로 합니다. 기존 테스트 모음도 같은 방식으로 쓸 수 있습니다. 에뮬레이터를 시작하고, 테스트 스크립트에 같은 변수를 설정한 뒤, 평소처럼 실행하면 됩니다.

빠르고 격리된 테스트를 위한 임베디드 모드

테스트용으로는 두 번째 방법이 있습니다. 임베디드 모드는 테스트 프로세스 안에서 에뮬레이터를 직접 만들고, SDK의 HTTP 클라이언트로 연결합니다. 임베디드 인스턴스마다 상태가 따로이므로 테스트끼리 버킷, 테이블, 큐를 공유하지 않으며 많은 수를 병렬로 돌릴 수 있습니다. 출시 시점에 이 모드는 AWS SDK for Rust에서만 쓸 수 있고, aws-emulator-embedded 크레이트를 사용합니다. 에뮬레이터를 별도 프로세스로 실행할 때는 일부 SDK에서 인증서를 신뢰하도록 추가 설정이 필요합니다. 글은 예로 AWS SDK for Java의 트러스트 스토어를 듭니다. 프로세스로 실행하면 모든 요청에 SigV4 서명을 요구하고, /__admin/health 엔드포인트를 제공하므로 스크립트나 컨테이너가 준비될 때까지 기다린 뒤 테스트를 시작할 수 있습니다.

AWS가 충실도를 재는 방법

로컬에서 통과한 테스트가 AWS에서도 통과하지 않는다면 에뮬레이터는 쓸모가 없습니다. 그래서 AWS는 충실도 테스트를 사용합니다. AWS SDK로 하나의 워크플로를 실행하고 AWS의 동작을 검증하는 짧은 프로그램입니다. 각 테스트는 먼저 실제 AWS에서 검증됩니다. 상태 코드, 본문, 정확한 오류 코드와 메시지, 워크플로가 만든 리소스까지 모든 응답이 AWS와 일치해야 통과로 칩니다. AWS는 릴리스마다 서비스별 결과를 k 대 n 형식으로 공개합니다. 테스트 목록은 aws-emulator-evaluation-suite 저장소에 공개되어 있으며, 아직 통과하지 못하는 테스트도 포함됩니다. 새 테스트가 추가되면 에뮬레이터가 나아져도 점수가 내려갈 수 있다고 AWS는 설명합니다. 아직 구현되지 않은 작업은 HTTP 501을 반환하므로, 테스트는 우연히 통과하지 않고 곧바로 실패합니다.

에이전트가 만들고 검토한다

AWS는 에뮬레이터를 AWS API 모델로부터 에이전트가 만들고 유지한다고 밝혔습니다. 이를 위해 Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline, AWS CodeCommit을 사용합니다. 한 에이전트 그룹은 차이를 찾아 항목마다 이슈를 등록하고, 다른 그룹은 테스트를 작성하고 동작을 구현하며 변경을 검토합니다. 변경이 푸시되면 파이프라인이 실행되어 충실도 테스트를 돌린 뒤에야 공개 저장소에 반영됩니다. 독립된 보안 에이전트가 수정 과정과 릴리스 파이프라인에서 적대적인 관점으로 변경을 살핍니다. 이는 AWS가 자사 프로세스를 직접 설명한 내용이며, 글에는 제3자 감사가 제시되어 있지 않습니다.

미리 알아 둘 제약

글은 제약을 솔직하게 밝힙니다. 에뮬레이터는 AWS처럼 IAM 정책과 리소스 기반 정책을 평가하지 않으므로, AWS에서 거부될 요청이 로컬에서는 성공할 수 있습니다. AWS는 애플리케이션이 안전한지 시험하는 용도로는 쓰지 말라고 권고합니다. 에뮬레이터 하나는 계정 하나처럼 동작하며, 계정 간 또는 리전 간 동작은 없습니다. AWS와의 일치 정도는 서비스와 기능마다 다르므로, 쓰는 서비스의 충실도 점수를 확인해야 합니다. 기본적으로 익명 사용 및 오류 데이터를 보내며, 끌 수 있습니다. 글 아래에서 한 독자가 하나의 댓글로 시작할 때마다 인증서가 새로 만들어지는 점과 .NET SDK의 청크 서명 S3 업로드가 저장되는 방식의 결함 등을 지적합니다. 이는 독립적으로 검증되지 않은 사용자 보고일 뿐 AWS의 발표가 아닙니다. AWS가 답하기 전까지는 확인되지 않은 내용으로 다뤄야 합니다.

개발자에게 의미하는 것

지금 실제 AWS 계정으로 테스트하는 팀에게, 충분히 충실한 로컬 엔드포인트는 비용과 대기 시간을 줄여 주고 코딩 에이전트가 안전하게 시도하고 반복할 공간도 줍니다. 대가는 분명합니다. 로컬에서 통과했다고 해서 운영 환경의 동작이 보장되지는 않으며, 보안 규칙은 특히 그렇습니다. 테스트 작업에는 실제 자격 증명을 두지 말고, 출시 전 최종 확인은 AWS에서 하십시오.