테스트 피라미드 모델

단위 테스트는 테스트 피라미드 모델의 가장 아래 넓은 기반을 구성하는 테스트 계층이다. 이는 소프트웨어의 가장 작은 단위, 즉 개별 함수, 메서드, 클래스와 같은 단일 컴포넌트를 격리하여 검증하는 것을 목표로 한다. 단위 테스트의 핵심은 테스트 대상 코드를 외부 의존성(예: 데이터베이스, 네트워크, 파일 시스템)으로부터 분리하는 것이다. 이를 위해 목 객체(Mock Object)나 스텁(Stub)과 같은 테스트 대역을 활용하여 격리된 환경을 조성한다.

단위 테스트는 일반적으로 개발자가 직접 작성하며, 테스트 주도 개발(TDD) 방법론에서 핵심적인 역할을 한다. 주요 특징은 다음과 같다.

이러한 테스트는 코드의 특정 입력에 대한 출력을 검증하여 버그를 조기에 발견하고, 리팩토링 시 회귀 오류를 방지하는 안전망 역할을 한다. 또한, 잘 작성된 단위 테스트는 코드의 동작을 문서화하는 효과도 제공한다.

통합 테스트는 단위 테스트로 검증된 개별 모듈이나 컴포넌트들이 함께 연결되어 상호작용할 때 올바르게 동작하는지 확인하는 테스트 단계이다. 이는 주로 API, 데이터베이스, 외부 서비스, 또는 여러 클래스 간의 인터페이스와 데이터 흐름에 초점을 맞춘다. 단위 테스트가 격리된 환경에서의 로직 검증이라면, 통합 테스트는 이러한 단위들이 조립된 후의 실제 동작 환경과 유사한 조건에서의 검증을 목표로 한다.

주요 접근 방식은 하향식, 상향식, 샌드위치 방식 등으로 구분된다. 하향식 통합 테스트는 상위 모듈부터 테스트하며 하위 모듈은 스텁으로 대체한다. 상향식 통합 테스트는 반대로 하위 모듈부터 테스트하며 상위 모듈과의 연결을 위해 드라이버를 사용한다. 샌드위치 방식은 이 두 가지를 혼합한 방법이다.

통합 테스트는 단위 테스트보다 실행 속도가 느리고 설정이 복잡할 수 있으나, 시스템의 핵심 연결 고리에서 발생할 수 있는 오류를 조기에 발견하는 데 결정적인 역할을 한다. 따라서 테스트 피라미드 모델에서 이는 단위 테스트 층과 종단 간 테스트 층 사이의 필수적인 중간 단계로 위치하며, 전체 테스트 스위트의 안정성과 효율성을 높이는 기반을 제공한다.

종단 간 테스트는 테스트 피라미드 모델의 최상단에 위치하며, 사용자 관점에서 애플리케이션의 전체 흐름을 검증하는 테스트 수준이다. 단위 테스트와 통합 테스트가 개별 모듈이나 컴포넌트 간 상호작용을 확인한다면, 종단 간 테스트는 데이터베이스, 네트워크, 외부 서비스, 사용자 인터페이스 등 모든 시스템 구성 요소가 통합된 상태에서 실제 사용 시나리오대로 작동하는지를 확인한다. 일반적으로 웹 브라우저나 모바일 앱을 자동화하여 사용자의 클릭, 입력, 탐색과 같은 행위를 시뮬레이션하는 방식으로 수행된다.

이 테스트의 주요 목표는 시스템이 비즈니스 요구사항을 최종적으로 충족시키는지, 그리고 여러 하위 시스템이 조화롭게 협력하여 하나의 완전한 기능을 제공하는지 검증하는 것이다. 예를 들어, "사용자가 상품을 검색하고 장바구니에 담아 결제를 완료하는" 과정 전체를 하나의 테스트 케이스로 구성한다. 이를 통해 프론트엔드와 백엔드 서버, API, 데이터베이스 등 전 계층에 걸친 결함을 발견할 수 있다.

그러나 종단 간 테스트는 실행 속도가 느리고, 환경 구성이 복잡하며, 테스트가 불안정해질 가능성이 높다는 단점을 지닌다. 네트워크 지연이나 외부 서비스의 일시적 장애와 같은 외부 요인에 쉽게 영향을 받기 때문이다. 따라서 테스트 피라미드 모델에서는 이러한 테스트를 최소한으로 유지하고, 신뢰성 높은 핵심 비즈니스 시나리오에만 집중하는 것을 권장한다. 대부분의 검증은 하위 계층인 단위 테스트와 통합 테스트에서 수행하고, 종단 간 테스트는 전체 시스템의 정상 작동을 최종 확인하는 역할로 제한하는 것이 효율적이다.

테스트 피라미드 모델의 핵심 원칙 중 하나는 각 테스트 계층의 실행 비용과 속도를 고려하여 적절한 비율로 테스트를 구성하는 것이다. 피라미드의 넓은 기반을 이루는 단위 테스트는 실행 속도가 매우 빠르고 비용이 저렴하다. 이는 일반적으로 메모리 내에서 실행되며 외부 의존성을 목 객체나 스텁으로 대체하기 때문이다. 따라서 개발자는 코드 변경 시 수천 개의 단위 테스트를 몇 분 내에 실행하여 빠른 피드백을 받을 수 있다.

반면, 피라미드의 중간에 위치하는 통합 테스트는 데이터베이스, API, 외부 서비스와의 상호작용을 검증하므로 실행 속도가 상대적으로 느리고 설정 비용이 더 든다. 피라미드의 꼭대기에 있는 종단 간 테스트는 실제 브라우저나 모바일 장치를 통해 전체 시스템 흐름을 검증하는데, 이는 가장 느리고 불안정하며 유지보수 비용이 가장 높은 테스트 유형이다.

이러한 비용과 속도의 차이는 테스트 피라미드가 단위 테스트를 가장 많이, E2E 테스트를 가장 적게 작성하도록 권장하는 근본적인 이유이다. 아래 표는 각 테스트 계층의 일반적인 특성을 비교한 것이다.

효율적인 테스트 전략은 빠르고 저렴한 테스트로 대부분의 결함을 조기에 발견하고, 느리고 비싼 테스트는 반드시 필요한 핵심 비즈니스 흐름에만 집중하여 적용하는 것이다. 이는 전체적인 개발 생산성을 높이고, CI/CD 파이프라인의 효율을 극대화하며, 소프트웨어의 품질을 경제적으로 유지하는 데 기여한다.

테스트 피라미드 모델은 테스트 자동화의 신뢰성을 높이는 데 기여한다. 피라미드 하단에 위치한 다수의 단위 테스트는 개별 컴포넌트의 동작을 격리하여 검증하므로, 테스트가 실패할 경우 결함의 원인을 매우 명확하고 빠르게 특정할 수 있다. 이는 디버깅 시간을 단축시키고, 결국 전체 소프트웨어 품질에 대한 신뢰도를 향상시킨다. 반면, 상단의 종단 간 테스트는 실패 시 원인을 추적하기 어려운 경우가 많다.

이 모델은 테스트 스위트의 유지보수성 측면에서도 장점을 가진다. 단위 테스트와 통합 테스트는 일반적으로 종단 간 테스트보다 작성과 이해가 쉽고, 실행 환경에 대한 의존도가 낮다. 따라서 애플리케이션의 기능이 변경되거나 확장될 때, 하위 계층의 테스트를 수정하는 것이 상위 계층의 복잡한 테스트 시나리오를 조정하는 것보다 상대적으로 간단하고 비용이 적게 든다. 이는 장기적인 프로젝트 생명주기 동안 테스트 자산을 관리하는 부담을 줄여준다.

또한, 테스트 피라미드는 테스트의 안정성을 보장한다. 하위 계층의 테스트는 외부 시스템(예: 데이터베이스, 네트워크, 사용자 인터페이스)의 불안정한 요소로부터 격리되어 실행되는 경우가 많다. 이로 인해 플레이키 테스트(flakey test, 일관되지 않은 결과를 내는 테스트)가 발생할 확률이 낮아지고, 테스트 결과에 대한 신뢰성이 높아진다. 안정적인 테스트 스위트는 지속적 통합 파이프라인의 핵심 요소로 작동하여, 개발팀이 변경 사항을 자주 통합하고 배포하는 데 자신감을 부여한다.

테스트 전략 수립은 테스트 피라미드 모델을 프로젝트에 효과적으로 도입하기 위한 첫 단계이다. 이 과정에서는 프로젝트의 도메인, 기술 스택, 팀의 역량, 비즈니스 요구사항을 종합적으로 분석하여 적절한 테스트 계층의 비율과 범위를 결정한다. 일반적으로 피라미드의 기반을 이루는 단위 테스트에 가장 많은 투자를 하고, 상위 계층인 통합 테스트와 종단 간 테스트는 핵심 비즈니스 흐름이나 시스템 간 연동에 집중하여 수를 제한하는 것이 원칙이다.

구체적인 전략 수립을 위해 다음 항목들을 고려하는 것이 일반적이다.

전략은 정적 문서가 아니라 지속적으로 검토하고 조정해야 하는 살아있는 지침이다. 정기적인 회고를 통해 테스트 스위트의 실행 시간, 유지보수 비용, 결함 발견 시점 등의 지표를 분석하고, 피라미드의 각 계층 간 균형이 최적화되었는지 평가한다. 이를 통해 초기에 수립한 테스트 전략이 프로젝트의 성장과 변화에 맞게 진화하도록 한다.

테스트 피라미드의 각 계층을 효과적으로 구현하기 위해서는 적절한 도구와 프레임워크를 선택하는 것이 중요하다. 선택은 사용하는 프로그래밍 언어, 애플리케이션 아키텍처, 팀의 숙련도, CI/CD 파이프라인과의 통합 용이성 등을 종합적으로 고려하여 이루어진다.

단위 테스트 계층에서는 JUnit, pytest, Jest와 같은 프레임워크가 널리 사용된다. 이들 도구는 빠른 실행 속도와 격리된 테스트 환경을 제공하는 데 중점을 둔다. Mockito, Sinon.JS와 같은 목 객체 라이브러리는 외부 의존성을 격리하는 데 유용하게 활용된다. 통합 테스트에는 Spring Boot Test, Rails Testing, supertest와 같이 데이터베이스나 외부 API와의 상호작용을 검증할 수 있는 도구가 적합하다. 종단 간 테스트는 Selenium, Cypress, Playwright와 같은 브라우저 자동화 도구를 주로 사용하여 사용자 시나리오를 모방한다.

선택 시 고려해야 할 주요 요소는 다음과 같다.

도구 선택은 한 번에 고정되는 것이 아니라, 프로젝트의 성장과 기술 스택의 변화에 따라 주기적으로 재평가되어야 한다. 예를 들어, 최근에는 더 나은 개발자 경험과 디버깅 기능을 제공하는 Cypress나 Playwright가 기존의 Selenium을 대체하는 경우가 많다. 각 계층에 적합한 도구를 조합하여 전체 테스트 슈트가 효율적으로 운영되도록 구성하는 것이 핵심이다.

테스트 다이아몬드는 기존 테스트 피라미드 모델의 한계를 보완하기 위해 제안된 변형 모델이다. 이 모델은 피라미드 형태 대신 다이아몬드(마름모) 형태로 테스트 계층을 시각화하며, 가장 많은 비중을 차지하는 테스트 유형이 중앙에 위치한다. 일반적으로 단위 테스트와 종단 간 테스트가 하단과 상단의 꼭짓점을 형성하고, 중앙에는 통합 테스트와 컴포넌트 테스트가 넓은 영역을 차지하는 구조를 가진다.

이 모델의 핵심은 통합 테스트의 중요성을 재조명하는 데 있다. 현대의 마이크로서비스 아키텍처나 복잡한 외부 시스템 연동 환경에서는 단순한 단위 테스트만으로는 시스템의 상호작용을 충분히 검증하기 어렵다. 따라서 실제 환경과 유사한 수준에서 여러 모듈이 함께 작동하는지를 확인하는 통합 테스트에 더 많은 투자와 비중을 두어야 한다는 주장이 테스트 다이아몬드의 기반이다. 이는 상대적으로 느리고 취약한 종단 간 테스트에만 의존하는 위험을 줄이는 동시에, 빠르지만 고립된 단위 테스트의 부족한 점을 메꾸는 균형 잡힌 접근법을 제시한다.

테스트 다이아몬드 모델을 적용할 때 고려할 사항은 다음과 같다.

결론적으로, 테스트 다이아몬드는 모든 상황에 적용되는 만능 해결책이 아니라, 특정 복잡도와 아키텍처를 가진 프로젝트에서 더 실용적인 테스트 분배를 고민한 결과물이다. 이 모델은 테스트 전략이 프로젝트의 실제 요구사항에 따라 진화해야 함을 강조한다[2].

테스트 트로피는 테스트 피라미드 모델에 대한 대안적 시각으로, 마틴 파울러가 제시한 테스트 피라미드가 모든 상황에 최적의 모델은 아니라는 비판에서 출발한다. 이 개념은 켄트 C. 돗스가 2017년 블로그 글 "The Testing Trophy and Testing Classifications"에서 처음으로 명시적으로 제안했다[3]. 테스트 트로피는 테스트의 종류를 계층적 중요도가 아니라, 각 테스트 유형이 제공하는 가치와 효용에 초점을 맞춰 분류한다.

테스트 트로피 모델은 일반적으로 네 가지 주요 테스트 범주를 강조하며, 이를 트로피 모양의 시각적 도표로 나타낸다. 이 모델의 핵심은 가장 넓은 면적을 차지하는, 즉 가장 큰 가치를 제공하는 테스트 유형에 더 많은 투자를 해야 한다는 것이다. 일반적인 구성은 다음과 같다.

테스트 트로피의 핵심 철학은 정적 테스트를 가장 기초적이고 효과적인 방어선으로 강조하는 데 있다. 타입스크립트나 ESLint 같은 도구를 활용한 정적 분석은 비교적 낮은 비용으로 많은 버그를 초기에 잡아낼 수 있다. 따라서 개발 프로세스에서 이 부분에 충분한 비중을 두어야 한다고 주장한다. 또한 통합 테스트를 단위 테스트보다 더 실용적이고 현실적인 버그 발견 수단으로 평가하며, 테스트 스위트에서 더 큰 비중을 차지해야 할 수 있다고 본다.

이 모델은 특히 프론트엔드 웹 애플리케이션과 같이 사용자 인터페이스와 다양한 외부 의존성을 다루는 복잡한 시스템에서 더 실용적인 접근법으로 받아들여진다. 모든 것을 작은 단위로 격리하여 테스트하기 어려운 경우, 실제로 상호작용하는 몇 개의 모듈을 함께 테스트하는 통합 테스트가 더 의미 있는 피드백을 제공할 수 있기 때문이다. 테스트 트로피는 엄격한 계층 구조보다는 프로젝트의 맥락과 필요에 따라 테스트 전략의 균형을 맞추는 유연성을 장점으로 내세운다.