에서 서버리스 애플리케이션 테스트 AWS - AWS 권장 가이드
개요사전 조건정의목표

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

에서 서버리스 애플리케이션 테스트 AWS

Amazon Web Services(기여자기여자)

2026년 3월(문서 기록)

이 가이드에서는 서버리스 애플리케이션을 테스트하는 방법론과 테스트 중 발생할 수 있는 문제를 설명하고 모범 사례를 소개합니다. 이러한 테스트 기법은 더 빠르게 반복하고 더 확실하게 코드를 릴리스할 수 있도록 돕기 위한 것입니다.

이 가이드는 서버리스 애플리케이션을 위한 테스트 전략을 수립하려는 개발자를 대상으로 합니다. 가이드를 시작점으로 삼아 테스트 전략에 대해 알아보고, Serverless Test Samples 리포지토리를 방문하여 이 가이드에 설명된 패턴과 모범 사례를 따르는 테스트의 예를 확인할 수 있습니다. 이 가이드에서는 서버리스 테스트 방법론을 설명하고, 서버리스 애플리케이션을 테스트할 때 고객이 직면하는 문제를 설명하고, 서버리스 애플리케이션을 테스트하기 위한 모범 사례를 소개합니다. 이러한 기법은 개발자가 더 빠르게 반복하고 더 자신 있게 릴리스할 수 있도록 돕기 위한 것입니다.

개요

자동화된 테스트는 애플리케이션 품질과 개발 속도를 보장하는 데 도움이 되는 중요한 투자입니다. 또한 테스트는 개발자 피드백을 가속화합니다. 개발자는 애플리케이션을 빠르게 반복하고 코드 품질에 대한 피드백을 받을 수 있기를 원합니다. 많은 개발자들은 데스크톱 환경(운영 체제에 직접 또는 컨테이너 기반 환경 내)에 배포하는 애플리케이션을 작성하는 데 익숙합니다. 데스크톱 또는 컨테이너 기반 환경에서 작업할 때는 대개 전적으로 데스크톱에서 호스팅되는 코드를 대상으로 테스트를 작성합니다. 그러나 서버리스 애플리케이션에서 아키텍처 구성 요소는 데스크톱 환경에 배포할 수 없고 대신 클라우드에만 존재할 수 있습니다. 클라우드 기반 아키텍처에는 지속성 계층, 메시징 시스템, 보안 구성 요소, APIs 및 기타 구성 요소가 포함될 수 있습니다. 이러한 구성 요소를 사용하는 애플리케이션 코드를 작성할 때는 테스트를 설계하고 실행하는 가장 좋은 방법을 결정하기가 어려울 수 있습니다.

이 가이드는 마찰과 혼란을 줄이고 코드 품질을 높이는 테스트 전략을 수립하는 데 도움이 됩니다.

사전 조건

이 가이드에서는 사용자가 소프트웨어 품질 보장을 위해 자동화된 소프트웨어 테스트를 사용하는 방법을 포함하여 자동화된 테스트의 기본 사항을 잘 알고 있다고 가정합니다. 이 가이드에서는 서버리스 애플리케이션 테스트 전략을 개괄적으로 소개하며 테스트 작성에 대한 실습 경험이 필요하지 않습니다.

정의

이 가이드에서는 다음 용어를 사용합니다.

  • 단위 테스트는 단일 아키텍처 구성 요소에 대해 코드를 대상으로 단독으로 실행되는 테스트입니다.

  • 통합 테스트 는 일반적으로 클라우드 환경에서 둘 이상의 아키텍처 구성 요소에 대해 실행됩니다.

  • End-to-end 전체 애플리케이션 또는 워크플로의 동작을 확인합니다.

  • 에뮬레이터는 클라우드 리소스를 프로비저닝하거나 호출하지 않고도 클라우드 서비스를 모방하도록 설계된 애플리케이션(종종 타사에서 제공)입니다.

  • 모의(가짜라고도 함)는 종속성을 해당 종속성의 시뮬레이션으로 대체하는 테스트 애플리케이션의 구현입니다.

목표

이 가이드의 모범 사례는 다음과 같은 두 가지 주요 목표를 달성하는 데 도움을 주기 위한 것입니다.

  • 서버리스 애플리케이션의 품질 향상

    • 아키텍처 경계에서의 테스트

    • 코드 경계에서 테스트

  • 기능 구현 또는 변경 시간 단축

소프트웨어 품질 향상

애플리케이션 품질은 개발자가 다양한 시나리오를 테스트하여 기능을 확인하는 능력에 따라 크게 달라집니다. 자동 테스트를 구현하지 않거나 일반적으로 테스트가 필요한 시나리오를 적절하게 다루지 않는 경우 애플리케이션의 품질을 확인하거나 보장할 수 없습니다.

서버 기반 아키텍처에서 팀은 테스트 범위를 쉽게 정의할 수 있습니다. 애플리케이션 서버에서 실행되는 모든 코드를 테스트해야 합니다. 서버에 호출되는 다른 구성 요소나 서버가 호출하는 종속성은 서버의 애플리케이션을 담당하는 팀이 외부 구성 요소나 테스트 범위를 벗어난 것으로 간주하는 경우가 많습니다.

서버리스 애플리케이션은 자체 환경에서 실행되는 AWS Lambda 함수와 같은 더 작은 작업 단위로 구성되는 경우가 많습니다. 팀은 단일 애플리케이션 내에서 이러한 더 작은 단위의 배수를 담당하게 될 것입니다. 일부 애플리케이션 기능은 Amazon Simple Storage Service(S3) 또는 Amazon Simple Queue Service(Amazon SQS)와 같은 관리형 서비스에 전적으로 위임하거나 내부에서 개발한 코드를 사용하지 않고 생성할 수 있습니다. 소프트웨어 테스트를 위한 기존 서버 기반 모델에서는 관리형 서비스를 애플리케이션 외부로 간주하여 제외할 수 있습니다. 이로 인해 적용 범위가 충분하지 않아 중요한 시나리오가 수동 탐색 테스트로 제한되거나 환경에 따라 결과가 달라지는 몇 가지 통합 테스트 사례로 제한될 수 있습니다. 따라서 관리형 서비스 동작과 클라우드 구성을 포함하는 테스트 전략을 채택하면 소프트웨어 품질을 개선할 수 있습니다.

아키텍처 경계에서의 테스트

서버리스 애플리케이션이 증가함에 따라 여러 아키텍처 구성 요소에 자연스럽게 분산됩니다. 분산 AWS 기능을 사용하지만 end-to-end 동작을 이해하기 어려울 수 있습니다.

자연 경계 식별

서버리스 모범 사례(함수 1개 = 작업 1개, 분리)에 따라 아키텍처를 설계할 때 하위 시스템 주위의 자연 경계를 확인할 수 있습니다. 이러한 경계는 애플리케이션의 논리적 분리 지점을 나타냅니다.

테스트 계약으로서의 경계

이러한 아키텍처 경계는 엣지를 테스트하기 위한 훌륭한 후보입니다. 각 경계를 계약으로 취급하고 정의된 사양에 따라 작동하는지 확인합니다. 이러한 경계를 테스트 검증을 삽입할 수 있는 애플리케이션의 심이라고 생각하십시오.

주요 이점

다음은 아키텍처 경계에서 테스트할 때 얻을 수 있는 주요 이점입니다.

  • 집중 테스트 범위 - 전체 애플리케이션을 이해할 필요 없이 하위 시스템을 독립적으로 테스트합니다.

  • 계약 검증 - 시스템이 발전함에 따라 각 경계가 예상 동작을 유지하는지 확인합니다.

  • 이중 용도 계측 - 이러한 동일한 경계로 인해 프로덕션 환경에서 뛰어난 관찰성 후크가 생성됩니다.

  • 테스트 하네스 - 비동기 서버리스 시스템을 테스트할 수 있습니다. 이는 이벤트가 하위 시스템을 통해 흐를 때 이벤트를 캡처하고 검증하여 이벤트 기반 아키텍처를 테스트하는 데 도움이 됩니다.

코드 경계에서 테스트

Lambda 코드와 같은 인프라 코드를 핵심 비즈니스 로직과 분리하여 명확한 코드 경계를 정의합니다. 이렇게 분리하면 테스트 전략을 간소화하는 고유한 테스트 범위가 생성됩니다.

경계 패턴

Lambda 함수에 두 개의 명확한 코드 경계를 설정합니다.

  • 외부 경계(Lambda 핸들러) -와 관련된 문제를 처리하는 슬림한 어댑터 계층 AWS Lambda

  • 내부 경계(비즈니스 로직) - Lambda 런타임과 독립적인 순수 비즈니스 로직 메서드

어댑터로서의 핸들러(외부 범위)

Lambda 함수 핸들러는 다음과 같은 씬 계층이어야 합니다.

  • 수신 event 및 context 객체에서 데이터 추출

  • 추출된 데이터를 검증합니다.

  • 비즈니스 로직 메서드에 관련 세부 정보만 전달합니다.

  • Lambda의 예상 형식으로 결과를 반환합니다.

비즈니스 로직(내부 범위)

핵심 비즈니스 로직은 다음과 같아야 합니다.

  • Lambda 관련 세부 정보와 독립적으로 운영

  • 간단하고 검증된 입력 수락

  • 예측 가능한 출력 반환

  • 초기화에 최소 종속성 필요

범위별 이점 테스트

  • 내부 경계 테스트 - Lambda 복잡성 또는 환경 설정 없이 비즈니스 로직에 대한 포괄적인 단위 테스트

  • 외부 경계 테스트 - 어댑터 계층의 이벤트 처리 및 데이터 추출을 검증하는 집중 통합 테스트

  • 최소한의 테스트 오버헤드 - 대부분의 테스트에 복잡한 환경이나 광범위한 종속성이 필요하지 않음

이 경계 기반 접근 방식을 사용하면 대부분의 코드를 순수 함수로 테스트하면서 Lambda 테스트를 최소화하고 대상으로 지정할 수 있습니다.

기능 구현 또는 변경 시간 단축

반복적인 개발 주기 동안 이러한 문제를 포착하여 소프트웨어 버그 및 구성 문제가 비용 및 일정에 미치는 영향을 최소화할 수 있습니다. 개발자가 이러한 문제를 감지하지 못하면 더 많은 사람이 문제를 식별하기 위해 추가 노력을 투자해야 합니다.

서버리스 아키텍처에는 API 호출을 통해 중요한 애플리케이션 기능을 제공하는 관리형 서비스가 포함될 수 있습니다. 이러한 이유로 개발 주기에는 행복한 경로(이러한 서비스와의 상호 작용이 예상대로 작동하는 경우)와 슬픈 경로(통화가 실패하거나 예상치 못한 응답을 반환하거나 환경 간에 다르게 작동하는 경우)를 모두 검증하는 테스트가 포함되어야 합니다. 이러한 테스트를 수행하지 않으면 로컬 환경과 배포된 환경 간의 차이로 인해 문제가 발생할 수 있습니다. 이 경우 수정 사항을 재현하고 확인하는 데 추가 시간을 할애해야 합니다. 이제 반복할 때마다 기본 설정과 다른 환경에 대한 변경 사항을 검증해야 하기 때문입니다.

적절한 서버리스 테스트 전략을 세우면 다른 서비스에 대한 호출을 포함한 테스트에 대한 정확한 결과를 제공하여 반복 시간을 단축할 수 있습니다.