GopherCon 2022: 마이크로서비스 테스트를 서비스로 - CrowdStrike의 Test Infrastructure as a Service

개요

CrowdStrike의 클라우드 네이티브 마이크로서비스 환경에서 기존 테스트 프레임워크의 한계를 극복하고, 지속적 연결이 필요한 Kafka 기반 테스트를 효과적으로 실행하기 위한 새로운 접근법을 제시합니다. 수백 개의 Go 모듈 기반 마이크로서비스를 운영하면서 발견한 문제점들을 해결하고, 테스트를 독립적인 서비스로 배포하여 프로덕션 환경에서도 실행 가능하게 만든 혁신적인 방법론입니다.

이 영상은 CrowdStrike의 엔지니어 Neha Agarwal이 GopherCon 2022에서 발표한 내용으로, 실제 대규모 프로덕션 환경에서 검증된 테스트 인프라 구축 경험을 담고 있습니다. CrowdStrike는 사이버보안 분야의 선도 기업으로, 클라우드 네이티브 아키텍처와 Go 언어를 활용한 마이크로서비스 개발에 있어 업계 최고 수준의 기술력을 보유하고 있습니다.

핵심 내용

기존 테스트 프레임워크의 한계

CrowdStrike는 초기에 Python 기반 CLI 테스트 프레임워크를 사용했습니다. 하지만 시간이 지나면서 심각한 문제점들이 드러났습니다.

첫째, 모든 서비스의 테스트 케이스가 단일 레포지토리에 집중되면서 크기가 급격히 증가했습니다. 이는 유지보수 비용의 급증으로 이어졌고, SDET(Software Development Engineer in Test) 팀이 전담으로 관리해야 하는 부담스러운 상황이 되었습니다.

둘째, 컴플라이언스 이슈가 발생할 때마다 수정 비용이 과도하게 높았습니다. 단일 레포지토리 구조 때문에 작은 변경사항도 전체 테스트 프레임워크에 영향을 미쳤기 때문입니다.

셋째, 그리고 가장 치명적인 문제는 Kafka 기반 테스트에서 발생했습니다. CLI 환경에서는 지속적인 네트워크 연결을 유지할 수 없기 때문에, 메시지 스트림을 실시간으로 소비하고 검증하는 테스트가 사실상 불가능했습니다. 이는 이벤트 기반 마이크로서비스 아키텍처에서 치명적인 테스트 공백을 의미했습니다.

Test as a Service – 새로운 패러다임

이러한 문제들을 해결하기 위해 CrowdStrike의 엔지니어 Son Paroky가 개발한 것이 “Test Infrastructure as a Service” 개념입니다. 핵심 아이디어는 테스트 코드를 독립적인 마이크로서비스로 만드는 것입니다.

이 접근법의 가장 큰 특징은 exportable Go module로 제공되는 라이브러리입니다. 프로덕트 Go 모듈이 이 라이브러리를 import하면, 동일한 도메인 내에서 애플리케이션 코드와 테스트 애플리케이션을 함께 관리할 수 있습니다. 테스트 애플리케이션은 프로덕션 클라우드 환경에 실제로 배포되어 서비스로 실행됩니다.

라이브러리는 코드 제너레이터를 포함하고 있어, 테스트 스위트의 프로토타입과 구조, 그리고 기본 테스트 케이스와 설정 파일들을 자동으로 생성합니다. 개발자는 빠르게 시작할 수 있으며, 서비스 소스 코드와 동일한 레포지토리에서 통합 테스트를 작성하고 필요한 의존성을 직접 관리할 수 있습니다.

특히 흥미로운 점은 테스트 실행 방식의 유연성입니다. 개발자가 로컬에서 버그 수정 코드를 테스트할 때는 커맨드 라인에서 실행할 수 있고, 프로덕션 환경에서는 HTTP 엔드포인트를 통해 서비스 형태로 실행할 수 있습니다. 온디맨드 실행은 물론이고, Cron 작업으로 등록하여 주기적으로 모니터링할 수도 있습니다.

실전 적용 사례와 아키텍처

발표자는 Kafka 통합이 필요한 새로운 기능 서비스를 테스트하는 실제 사례를 공유했습니다. 이 서비스는 Kafka, 백엔드 데이터 스토어, UI와 통합되어야 했습니다.

테스트 서비스에 필요한 의존성을 추가하고 더미 이벤트를 생성하는 것이 매우 간단했습니다. 테스트 서비스가 이미 export하는 라이브러리들을 활용하여 테스트를 작성할 수 있었기 때문입니다.

테스트 서비스는 다음과 같은 REST API 엔드포인트들을 노출합니다:

Scheduler 엔드포인트: Cron 기반 스케줄러를 생성하는 POST 요청
Executor 엔드포인트: 온디맨드로 테스트를 실행하는 POST 요청
Test List 엔드포인트: 등록된 테스트 케이스 목록을 조회하는 GET 요청
Queries 엔드포인트: 스케줄러나 온디맨드 테스트의 실행 결과를 조회하는 GET 요청

테스트가 실행되면 메트릭이 자동으로 export되어 Grafana 대시보드로 시각화됩니다. 이를 통해 서로 다른 타임라인과 클라우드 환경에서 테스트 결과를 모니터링할 수 있습니다. 각 테스트 케이스의 실행 시간도 측정되므로, 트래픽이 많은 시간대의 불안정성(flakiness)이나 성능 저하를 쉽게 발견할 수 있습니다.

이 방식의 가장 큰 승리는 Kafka consumer 기반 테스트에서의 지속적 연결 유지입니다. 테스트 서비스가 마이크로서비스로 배포되어 있기 때문에, goroutine으로 실행되는 테스트들이 데이터 서비스의 producer와 consumer로 계속 연결된 상태를 유지할 수 있습니다. 이는 이전 CLI 기반 접근법에서는 불가능했던 시나리오입니다.

실전 가이드

Test as a Service를 실제로 적용하려면 다음 과정을 따라해볼 수 있습니다:

먼저 테스트 라이브러리를 프로젝트에 통합합니다. Go 모듈 기반 마이크로서비스 프로젝트에 test-as-a-service 라이브러리를 import합니다. 이 라이브러리는 CrowdStrike의 내부 도구이지만, 유사한 구조를 직접 구현할 수 있습니다. 필요한 사전 지식은 Go 언어와 마이크로서비스 아키텍처에 대한 기본 이해입니다. 초기 설정은 대략 1-2시간 정도 소요됩니다.

다음으로 코드 제너레이터로 테스트 스캐폴딩을 생성합니다. 라이브러리의 코드 제너레이터를 실행하여 테스트 스위트의 기본 구조, 샘플 테스트 케이스, 설정 파일들을 자동 생성합니다. 여기서 중요한 팁은 생성된 코드의 구조를 충분히 이해한 후 커스터마이징을 시작하는 것입니다. 특히 의존성 주입 패턴과 테스트 라이프사이클을 명확히 파악하면 나중에 복잡한 테스트 시나리오를 구현할 때 큰 도움이 됩니다.

마지막으로 테스트 서비스를 배포하고 모니터링을 설정합니다. 생성된 테스트 애플리케이션을 프로덕션 클라우드 환경에 마이크로서비스로 배포합니다. CI/CD 파이프라인에 통합하고, Grafana 대시보드를 설정하여 메트릭을 시각화합니다. 배포가 성공적으로 완료되었는지는 테스트 서비스의 헬스체크 엔드포인트와 첫 번째 온디맨드 테스트 실행 성공 여부로 확인할 수 있습니다. 이후에는 Cron 스케줄러를 추가하여 주기적인 회귀 테스트를 설정하고, 알림 메커니즘을 연결하여 테스트 실패 시 즉시 대응할 수 있도록 발전시킬 수 있습니다.

심층 분석

이 접근법은 테스트를 일급 시민(first-class citizen)으로 취급한다는 점에서 매우 혁신적입니다. 테스트 코드가 프로덕션 환경에서 실제 서비스로 실행되며, 프로덕트 마이크로서비스와 동일한 인프라 혜택을 누립니다.

강점:

지속적 연결 유지: Kafka consumer 기반 테스트, 웹소켓 테스트, 스트리밍 데이터 파이프라인 테스트 등 연결 지속성이 필요한 시나리오를 완벽히 지원합니다
인프라 재사용: 기존 마이크로서비스 인프라를 그대로 활용하므로 메트릭 수집, 로깅, 알림, 대시보드 구축이 추가 비용 없이 가능합니다
개발자 경험 향상: 테스트 코드가 서비스 코드와 같은 레포지토리에 있어 의존성 관리가 단순해지고, 코드 리뷰와 버전 관리가 일관됩니다
유연한 실행 방식: 로컬 CLI, 온디맨드 API 호출, Cron 스케줄링 등 다양한 방식으로 실행 가능합니다

한계점과 고려사항:

초기 러닝 커브: 테스트를 서비스로 설계하고 배포하는 것은 전통적인 테스트 작성보다 복잡합니다. 팀 전체가 마이크로서비스 아키텍처와 Go 언어에 익숙해야 합니다
리소스 비용: 각 테스트 스위트가 독립적인 서비스로 배포되므로, 인프라 리소스(컴퓨팅, 네트워크, 스토리지) 비용이 증가할 수 있습니다
보안 및 격리: 테스트 서비스가 프로덕션 환경에 배포되므로, 테스트 데이터와 프로덕션 데이터의 격리, 접근 권한 관리, 네트워크 세그먼테이션 등에 각별한 주의가 필요합니다

최근 마이크로서비스 아키텍처에서 “Testing in Production”이 주요 트렌드로 자리잡고 있습니다. Chaos Engineering, Canary Deployment, Feature Flags와 결합하여 프로덕션 환경에서 실시간으로 시스템 동작을 검증하는 것이 중요해지고 있습니다. CrowdStrike의 접근법은 이러한 트렌드의 최전선에 있으며, Netflix, Uber, Amazon 등 선도 기업들도 유사한 방향으로 진화하고 있습니다.

데이터 기반 인사이트

CrowdStrike의 사례는 구체적인 규모와 통계를 제공합니다:

수백 개의 Go 모듈 기반 마이크로서비스 운영 중
클라우드 네이티브 아키텍처로 여러 프로덕션 클라우드에 배포
빠른 배포 주기로 CI/CD 파이프라인에서 모든 통합 테스트 실행 필요

출처의 신뢰도 측면에서, 이 발표는 GopherCon 2022에서 진행된 공식 세션입니다. GopherCon은 Go 언어 커뮤니티에서 가장 권위 있는 컨퍼런스 중 하나이며, 발표자 Neha Agarwal은 CrowdStrike에서 실제 프로덕션 시스템을 운영하는 엔지니어입니다.

핵심 인사이트

영상을 본 후 기억해야 할 다섯 가지:

테스트를 일급 시민으로 취급하라 – 테스트 코드를 독립적인 마이크로서비스로 배포하면 프로덕션 환경에서 지속적으로 실행하며 시스템을 검증할 수 있습니다. 이는 특히 Kafka 같은 메시지 브로커를 사용하는 이벤트 기반 아키텍처에서 필수적입니다.
기존 인프라를 최대한 재사용하라 – 테스트 서비스를 마이크로서비스로 만들면 메트릭 수집, 로깅, 알림, 대시보드 등 기존 프로덕트 서비스를 위해 구축한 모든 인프라를 그대로 활용할 수 있습니다.
코드 제너레이터로 진입 장벽을 낮춰라 – 테스트를 서비스로 만드는 것은 복잡해 보이지만, 잘 설계된 라이브러리와 코드 제너레이터가 있다면 개발자들이 빠르게 시작할 수 있습니다.
유연한 실행 방식으로 다양한 사용 사례를 지원하라 – 동일한 테스트 코드를 로컬 CLI에서도, 프로덕션 환경의 HTTP API로도, Cron 스케줄러로도 실행할 수 있다는 것은 개발자 경험과 운영 효율성 양쪽을 모두 만족시킵니다.
Testing in Production의 전략적 가치를 이해하라 – 프로덕션 환경에서 테스트를 실행하는 것은 단순히 기술적 도전이 아니라 비즈니스 가치를 창출합니다. 실제 트래픽 패턴, 데이터 볼륨, 네트워크 레이턴시 하에서 시스템 동작을 검증함으로써 스테이징 환경에서는 발견할 수 없는 문제들을 조기에 감지할 수 있습니다.

요약자 노트

이 발표는 대규모 마이크로서비스 환경에서의 테스트 전략에 대한 실용적인 인사이트를 제공하지만, 몇 가지 고려사항이 있습니다.

한계점:

발표에서는 테스트 서비스 배포로 인한 추가 인프라 비용에 대한 구체적인 언급이 없습니다
프로덕션 환경에서 테스트를 실행할 때의 보안 리스크와 데이터 격리 전략에 대한 상세한 설명이 부족합니다
Table-driven test와 regex matching 지원이 최근 추가되었다고 했지만, 구체적인 구현 예시나 기존 테스트 마이그레이션 방법은 다루지 않았습니다

현재 업계 동향: 2025년 현재, 클라우드 네이티브 테스트 도구들이 빠르게 발전하고 있습니다. Testcontainers, LocalStack, KIND(Kubernetes in Docker) 같은 도구들은 로컬 개발 환경에서도 프로덕션과 유사한 테스트를 가능하게 합니다.

GopherCon 2022: 마이크로서비스 테스트를 서비스로 – CrowdStrike의 Test Infrastructure as a Service

개요