테스트 피라미드의 죽음

마이크로서비스 시대의 새로운 테스팅 토폴로지

Sep 9. 2025 brunch_membership's

피라미드는 무너지고 있습니다

2009년, Mike Cohn이 『Succeeding with Agile』에서 제안한 테스트 피라미드는 QA 업계의 황금률이었습니다. 단위 테스트를 기반으로, 통합 테스트를 중간에, E2E 테스트를 꼭대기에 두는 이 구조는 10년 이상 의심받지 않는 진리였습니다. 70% 단위 테스트, 20% 통합 테스트, 10% E2E 테스트라는 비율은 마치 자연법칙처럼 받아들여졌습니다.

하지만 2025년 현재, 우리는 더 이상 피라미드 안에 살지 않습니다.

마이크로서비스 아키텍처가 보편화되면서, 전통적인 테스트 피라미드는 현실과 맞지 않는다는 평가가 늘고 있습니다. 단일 모놀리스 애플리케이션을 가정한 이 모델은 수십, 수백 개의 서비스가 복잡하게 얽혀 있는 현대 시스템에서는 한계를 보이고 있습니다.

업계 보고서들이 이를 명확히 보여줍니다. Netflix는 대규모 트래픽 전환에서 트래픽 리플레이를 활용해 변경사항을 무중단으로 사전 검증하는 접근을 공개했습니다. Spotify는 허니콤 모델이라는 새로운 테스팅 접근법을 만들어야 했고, Uber는 비동기 이벤트 처리의 복잡성으로 인한 도전을 공유했습니다.

한국에서도 2022년 카카오 데이터센터 화재 이후, 분산 시스템의 복잡성과 테스트의 한계를 절실히 경험했습니다. 단일 장애점(Single Point of Failure)이 전체 서비스에 미치는 영향을 기존 테스트로는 예측하지 못했던 것입니다.

[케이스 스터디: 카카오 데이터센터 화재(2022)]

무슨 일이? SK C&C 판교 데이터센터 화재로 카카오톡, 카카오페이, 카카오뱅크 등 전 서비스가 최대 127시간 중단. 일상 소통부터 금융 거래까지 마비되며 디지털 인프라 의존도를 실감

그 후? 카카오는 이중화 강화, 자체 데이터센터 구축, 멀티 클라우드 전략 등 인프라 다변화 가속. 업계 전반에 DR(재해복구) 시스템 재점검 붐

시사점: 테스트 피라미드만으로는 데이터센터 레벨 장애, 네트워크 파티션, 리전 간 페일오버 같은 인프라 위험을 포괄하기 어렵다. 통합/서비스 테스트와 함께 관찰가능성 모니터링, 카오스 엔지니어링 같은 운영 실험이 필수

왜 피라미드는 실패했을까요

분산 시스템의 복잡성: 단위의 재정의

마이크로서비스 환경에서 "단위"의 정의 자체가 모호해졌습니다. 전통적인 관점에서 단위는 하나의 함수, 하나의 클래스, 기껏해야 하나의 모듈이었습니다. 하지만 분산 시스템에서는 이야기가 완전히 달라집니다.

예를 들어, 전자상거래 플랫폼의 "주문 처리"를 생각해보세요. 이 간단해 보이는 기능 하나가 실제로는 재고 서비스, 결제 서비스, 배송 서비스, 알림 서비스, 사용자 서비스를 거칩니다. 각 서비스는 독립적으로 배포되고, 독립적으로 스케일링되며, 독립적으로 실패합니다.

서비스 A의 완벽한 단위 테스트가 99.9%의 커버리지를 자랑한다고 해도, 서비스 B가 응답 형식을 살짝 바꾸는 순간 전체 시스템이 무너질 수 있습니다. 더 심각한 것은, 이런 실패가 "순차적 의존성 실패"로 이어진다는 점입니다. A가 B를 호출하고, B가 C를 호출하는 체인에서, C의 작은 변경이 A까지 도달하는 데 걸리는 시간과 영향도를 예측하기란 거의 불가능합니다.

대규모 분산 시스템에서는 '꼬리 지연(tail latency)'이 전체 체감 성능을 좌우한다는 점이 널리 보고되어 왔습니다. Google의 Dean과 Barroso는 "The Tail at Scale"(2013) 논문에서 이런 극단적인 변동성을 상세히 분석했습니다. 이런 변동성은 전통적인 테스트 방법론으로는 재현조차 어렵습니다.

네트워크 폴라시(Network Fallacy)의 현실화

분산 컴퓨팅의 8가지 오류(Fallacies of Distributed Computing) 중 첫 번째는 "네트워크는 신뢰할 수 있다"는 가정입니다. 테스트 피라미드는 암묵적으로 이 오류를 내포하고 있었습니다. 단위 테스트에서는 네트워크가 존재하지 않고, 통합 테스트에서는 로컬 네트워크만 사용하며, E2E 테스트조차 통제된 환경에서 실행됩니다.

실제 프로덕션 환경에서는 패킷 손실, 네트워크 파티션, 비대칭 네트워크 지연이 일상적으로 발생합니다. 한국 IT 환경에서는 특히 클라우드 리전 간 통신, CDN 캐시 무효화, 다중 IDC 구성에서 이런 문제가 빈번하게 나타납니다. 국내 금융 서비스들은 리전 간 통신 지연과 안정성을 핵심 고려사항으로 삼고 있으며, 리전 간 트래픽과 지연을 정밀하게 관측하고 전환하는 실전 파이프라인을 구축하고 있습니다.

더 나아가, 서비스 메시와 사이드카 프록시의 도입으로 네트워크 토폴로지 자체가 동적으로 변합니다. Istio나 Linkerd 같은 서비스 메시는 트래픽을 동적으로 라우팅하고, 서킷 브레이커를 적용하며, 리트라이 정책을 실행합니다. 이런 인프라 레벨의 동작은 애플리케이션 레벨의 단위 테스트로는 절대 검증할 수 없습니다.

테스트 격리의 역설: Mock에서 Service Virtualization까지

피라미드는 테스트의 격리를 미덕으로 삼았습니다. Mock과 Stub으로 외부 의존성을 차단하고, 순수한 로직만 검증하라고 가르쳤습니다. 하지만 이는 테스팅 진화의 시작점일 뿐이었습니다.

- Mock 단계의 한계: Mock을 만들 때 우리는 외부 서비스의 동작을 가정합니다. 하지만 이 가정은 만들어진 순간부터 낡기 시작합니다. Spotify는 2018년 엔지니어링 블로그에서 오래된 Mock이 실제 서비스 동작과 달라져 "좀비 Mock"이 되는 문제를 지적했습니다.