90DaysOfDevOps (Day 16)

고태규·2025년 9월 22일
0

DevOps

목록 보기
15/21
post-thumbnail

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 16 - Smarter, Better, Faster, Stronger - Testing at Scale


1. 기존 성능 테스트 프레임워크의 문제점


현대의 클라우드 네이티브 환경에서는 단순한 부하 테스트를 넘어서 고도화된 성능 테스트가 필수적이다.

  • 인프라 변경 검증: 쿠버네티스의 오토스케일린 정책이나 서비스 메시 (Linkerd 등) 도입과 같은 인프라 수준의 변경이 전체 시스템에 미치는 영향을 정밀하게 측정해야함
  • 복잡한 시나리오 시뮬레이션: 실제 서비스 장애 상황을 가정한 재해 복구 (DR) 시나리오나, 현실적인 사용자 행동 패턴을 다양한 규모로 시뮬레이션할 필요가 있음.
  • 일반 부하 테스트: 다양한 트래픽 수준에서 시스템이 어떻게 반응하는지에 대한 기본적인 이해가 필요함.

이렇게 성능 테스트의 요구사항이 고도화되면서, 기존 '성능 테스트 프레임워크'가 가진 문제점들이 부각되기 시작했다.

1-1. 비효율적인 리소스 사용 및 환경 호환성 문제

  • 현실적인 사용자 시나리오를 지원하는 프레임워크일수록, 리소스 소모가 매우 심했음.
  • 리소스가 제한적인 CI/CD 및 쿠버네티스 환경과 호환성이 떨어져 메모리 부족이나 과도한 CPU 사용 문제를 일으켰음. -> 현대적인 개발환경에서 사용하기 어렵다는 단점이 존재함.

1-2. 현대적인 모니터링 도구와의 연동 어려움

  • 테스트 결과를 '데이터독 (DataDog)'과 같은 최신 모니터링 솔루션으로 전송하는 기능이 없거나 매우 미흡
  • 데이터를 연동하기 위해서는 사용자가 직접 서드파티 확장 프로그램을 컴파일 하거나 자체적으로 통합코드를 개발하는 불편함 존재

1-3. 끔찍한 개발자 경험 (Developer Experience, DX)

  • 대부분의 성능 테스트 프레임워크는 문서가 부실하고, CLI가 직관적이지 않아 학습 곡선이 가파른 상황
  • 기술 자체가 2000년대 패러다임에 머물러 있어, 최신 어플리케이션의 복잡한 구조나 다양한 프로토콜 (HTTP/3, gRPC 등)을 테스트하기에 적합하지 않은 상황

2. 왜 성능 테스트 기술은 정체되었는가


2-1. 테스트는 비용이라는 인식의 악순화

  • 테스트 도구는 개발자 경험 (DX)이 나쁘고, 원하는 시나리오를 구현하는 데에 시간과 돈이 많이 들어 비용 중심 (Cost Center)로 취급됨.
  • 비용으로 취급되어 도구의 성능이나 기능, DX 개선에 투자를 하지 않음
  • 투자가 없으니 기술은 정체되고, 이러한 부담은 모두 개발자가 떠앉게 됨.
  • 이는 다시 '테스트는 비용이다'라는 인식을 강화하며 악순환이 반복되는 상황

2-2. 시대의 변화를 따라가지 못하는 기술

과거에는 메어메탈 서버, VM 클러스터 환경을 사용하며, 테스트 결과는 CSV, XML 같은 정적 파일로 충분하였다.

하지만, 현재는 쿠버네티스, 서버리스 중심의 복잡하고 정교한 분산 시스템을 사용하며, 테스트 결과는 그라파나 (Grafana), 데이터톡 같은 최신 대시보드나 데이터베이스로 즉시 전송되어 분석되어야 하는 상황이다.

또한, 과거와 달리 현재는 전 세계 사용자를 대상으로 서비스하며, '바이럴(입소문)'처럼 예측 불가능한 트래픽 폭증이 잦은 상황이다.

기존 성능 테스트 프레임워크들은 이런 글로벌하고 예측 불가능한 시나리오를 쉽게 시뮬레이션하는 기능이 부족하다.


3. 시뮬레이션 프레임워크


3-1. 시뮬레이션 프레임워크란?

기존 도구의 한계를 극복하기 위해선 새로운 비전이 필요하다.

현대적인 테스트 프레임워크는

  • 대부분의 컴퓨팅이 분산환경이므로, 분산 실행을 기본으로 지원해야함
  • 로컬, CI/CD 등 어떤 환경에서도 코드 변경 없이 테스트 가능해야함
  • 결과를 필요한 곳 (대시보드, DB등)에 실시간으로 전송해야함
  • 개발자가 사용하기 편해야함.

이여야 한다.

이러한 비전을 실현하기 위한 해결책으로 '시뮬레이션 프레임워크(Simulation Framework)'라는 새로운 개념이 제시되었다.

이는 단순히 부하를 주는 것을 넘어, 시스템의 동작을 현실적으로 모방하는 데 초점을 맞춘 테스트 도구이다.



3-2. 시뮬레이션 프레임워크는 무엇이 다른가?

기존 테스트가 정해진 요청만 반복하는 로봇 같았다면, 시뮬레이션 프레임워크는 실제 사용자처럼 생각하고 시스템을 학습하여, 테스트의 지능과 개발자의 경험을 모두 극대화한다.

1. 테스트의 지능과 현실성 극대화

  • 진짜 사용자처럼 행동을 모방: 단순히 API를 순서대로 호출하는 것을 넘어, '워크플로우(DAG)'를 통해 "로그인 후 → 상품 탐색 → 여러 상품 동시 장바구니 담기 → 결제 시도"와 같은 복잡하고 비순차적인 사용자 과정 전체를 테스트함.

  • Full-Stack 관점의 테스트: 하나의 테스트 안에서 UI(Playwright)와 API(HTTP/gRPC)를 동시에 검증하여, 사용자의 클릭 한 번이 백엔드에 미치는 전체 영향을 완벽하게 파악할 수 있음.

  • 스스로 학습하고 똑똑해지는 기능: 테스트를 실행하며 얻은 데이터를 바탕으로 다음 테스트에 필요한 최적의 설정을 자동으로 추천하고 조정해줌.

  • 데이터 기반의 명확한 답변: 인프라 변경 전후의 성능을 비교하기 위해 A/B 테스트 기능을 내장하여, "어떤 설정이 더 나은가?"에 대한 명확한 데이터 기반의 답을 제공함.

2. 개발자의 '경험(DX)'과 '속도' 최우선

  • 테스트 작성의 높은 자유도: YAML/JSON 형식에 얽매이지 않고, 파이썬(Python) 같은 익숙한 프로그래밍 언어로 테스트를 작성하여 복잡한 로직도 손쉽게 구현하고 외부 라이브러리도 자유롭게 활용할 수 있음.

  • 실행과 분석 과정의 혁신: CLI 하나로 노트북, CI/CD, 쿠버네티스 등 어떤 환경에서든 코드를 바꿀 필요 없이 테스트를 즉시 실행할 수 있음.

  • 기다림 없는 피드백 루프: 느린 CI/CD 파이프라인을 기다릴 필요 없이, 노트북에서 RPC로 클러스터에 바로 테스트를 던져 즉각적인 피드백을 받을 수 있음.

  • 실시간 결과 리포팅: 테스트 결과는 코드에서 직접 데이터독, 그라파나 같은 대시보드로 실시간 전송되어, 결과 분석을 위한 불필요한 과정을 완전히 제거함.


4. 시뮬레이션 프레임워크 공식 정의


앞서 말한 시뮬레이션 프레임 워크 기능들을 종합하여 시뮬레이션 프레임워크를 다음과 같이 정의할 수 있다.
  • 현실성: 통합 테스트처럼 현실적인 사용자 워크플로우를 작성하지만, 성능 테스트의 속도와 동시성으로 실행됨.

  • 지능성: 데이터 과학 접근법과 통계를 활용하여 설정을 자동화하고, 시스템 변경의 영향을 더 잘 이해하도록 도움.

  • 현대성: 쿠버네티스, 서버리스 등 현대적인 클라우드 네이티브 컴퓨팅 환경을 완벽하게 지원.

  • 개발자 중심: 개발자 경험(DX)을 최우선으로 하여, 빠르고 유익한 피드백을 통해 개발자의 행복을 극대화함.

  • 개방성 및 통합성: 다양한 리포팅 서비스, 데이터베이스, 프로토콜과 쉽게 연동됨.

데브옵스 엔지니어들은 시스템에서 통찰력을 얻는 것이 매우 중요하다.

따라서, 시뮬레이션 프레임워크는 너무 늦기 전에 시스템이 부하에 어떻게 반응하는지 이해하고, 문제를 사전에 에방하는 데 필수적인 프레임워크이다.

0개의 댓글