GopherCon 2022: Test Infrastructure as a Service - 마이크로서비스 테스트의 새로운 접근법

개요

CrowdStrike의 마이크로서비스 테스트 인프라를 Python 기반 CLI에서 Go 기반 서비스로 전환한 사례를 다룹니다. 이 발표는 수백 개의 Go 마이크로서비스를 운영하면서 직면한 테스트 확장성 문제를 어떻게 해결했는지, 그리고 “Test Infrastructure as a Service” 접근법이 왜 현대 클라우드 네이티브 환경에서 더 효과적인지를 실무 경험을 바탕으로 설명합니다.

이 영상은 CrowdStrike의 소프트웨어 엔지니어 Neha Agarwal이 GopherCon 2022에서 발표한 콘텐츠입니다. CrowdStrike는 사이버 보안 분야의 글로벌 기업으로, 클라우드 네이티브 아키텍처를 기반으로 한 수백 개의 Go 마이크로서비스를 운영하고 있습니다. 이러한 대규모 환경에서 축적된 실전 경험은 마이크로서비스 테스트 전략을 수립하는 개발팀에게 신뢰할 만한 인사이트를 제공합니다.

핵심 내용

레거시 테스트 프레임워크의 한계

CrowdStrike는 클라우드 네이티브 아키텍처에서 수백 개의 Go 기반 마이크로서비스를 운영하고 있습니다. 이러한 서비스들은 API, 메시징 프로토콜, Protocol Buffers 등을 통해 서로 통신하며, 빠른 배포 주기로 인해 모든 통합 테스트를 CI/CD 파이프라인에서 실행해야 했습니다.

기존에는 Python 기반 CLI 프레임워크를 사용했지만, 시간이 지나면서 다음과 같은 심각한 문제들이 발생했습니다:

모놀리식 저장소 문제: 처음에는 작은 규모로 시작했지만, 시간이 지나면서 모든 서비스의 테스트 케이스가 하나의 거대한 저장소에 집중되었습니다. 이는 코드 베이스의 복잡도를 기하급수적으로 증가시켰고, 특정 서비스의 테스트를 수정하려 해도 전체 저장소에 영향을 미칠 수 있다는 부담감이 있었습니다.

유지보수 비용 증가: 프레임워크가 SDET(Software Development Engineer in Test) 팀에 의해 완전히 유지관리되면서, 규정 준수 문제가 발생할 때마다 유지보수 비용이 증가했습니다. 개발팀이 직접 테스트를 작성하고 관리하는 것이 아니라, 별도 팀에 의존하는 구조는 협업 효율성을 떨어뜨렸습니다.

Kafka 기반 테스트의 한계: CLI 기반 테스트의 가장 큰 문제는 Kafka 컨슈머와 같이 지속적인 연결이 필요한 시나리오를 테스트할 수 없다는 점이었습니다. CLI는 테스트가 끝나면 연결을 종료하기 때문에, 실시간 메시지 스트림을 처리하는 서비스를 제대로 검증할 수 없었습니다.

실무에 적용할 때는 현재 사용하는 테스트 프레임워크의 확장성을 평가해보는 것이 좋습니다. 특히 마이크로서비스 개수가 증가하면서 테스트 저장소가 지나치게 커지고 있는지, 특정 팀에만 유지보수 부담이 집중되는지를 확인해야 합니다. 다만 모든 조직이 CrowdStrike처럼 수백 개의 서비스를 운영하는 것은 아니므로, 소규모 환경에서는 기존 접근법이 충분히 효과적일 수 있다는 점도 염두에 두어야 합니다.

Test Infrastructure as a Service 개념

이러한 문제를 해결하기 위해 CrowdStrike의 엔지니어 Jason Parecki가 “Test as a Service”라는 새로운 개념을 제안하고 개발했습니다. 이는 테스트를 독립적인 Go 모듈로 만들어 프로덕션 서비스와 동일한 방식으로 배포하는 접근법입니다.

핵심 아키텍처: 각 제품 Go 모듈 내에 테스트 애플리케이션을 함께 포함시키는 “매크로 모듈” 구조를 도입했습니다. 이제 하나의 Go 모듈이 도메인 관련 애플리케이션뿐만 아니라 테스트 애플리케이션도 함께 포함하며, 이 테스트 애플리케이션은 원하는 모든 프로덕션 클라우드에 배포될 수 있습니다.

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

유연한 실행 방식: Test as a Service는 두 가지 실행 모드를 지원합니다. 첫째, 개발자가 로컬에서 버그 수정을 빠르게 테스트해야 할 때는 커맨드 라인에서 실행할 수 있습니다. 둘째, 엔드포인트를 통해 서비스 형태로 테스트를 실행할 수도 있습니다. 테스트를 온디맨드로 실행하거나 Cron 작업을 통해 주기적으로 모니터링할 수 있어, 서로 다른 시간대와 여러 클라우드 환경에서의 동작을 지속적으로 확인할 수 있습니다.

특히 흥미로운 점은 이 접근법이 Kafka 컨슈머 기반 테스트에서 지속적인 연결을 유지할 수 있다는 것입니다. 이를 프로덕션 배포 시나리오에 적용하면 실시간 이벤트 스트림을 처리하는 마이크로서비스의 동작을 실제 환경과 유사하게 검증할 수 있고, 개발 환경에서는 로컬에서 빠른 피드백 루프를 통해 버그를 신속하게 수정할 수 있습니다.

인프라 재사용과 관찰성

Test as a Service의 또 다른 중요한 장점은 기존 프로덕션 마이크로서비스에서 사용하는 인프라를 그대로 활용할 수 있다는 점입니다.

메트릭과 대시보드: 프로덕션 서비스와 동일한 메트릭 수집 메커니즘을 테스트 서비스에도 적용할 수 있습니다. Grafana 대시보드를 구축하여 서로 다른 타임라인과 여러 클라우드 환경에서의 테스트 결과를 쉽게 모니터링할 수 있으며, 각 테스트 케이스의 실행 시간을 측정하여 특정 트래픽이 많은 시간대에 발생하는 불안정성(flakiness)도 원활하게 모니터링할 수 있습니다.

실전 사례: Neha Agarwal은 Kafka 백엔드, 데이터 스토어, UI와 통합되는 새로운 기능 서비스를 테스트하는 사례를 소개했습니다. 새로운 테스트 서비스에 필요한 모든 의존성을 추가하고 더미 이벤트를 생성하는 것이 매우 간편했으며, 테스트 서비스에서 이미 익스포트한 라이브러리와 밀접하게 연동되었습니다.

API 엔드포인트: 테스트 서비스는 라이브러리를 통해 다음과 같은 엔드포인트를 노출합니다:

GET/POST 엔드포인트: Cron 스케줄러를 생성하거나 온디맨드로 테스트를 실행
GET 엔드포인트: 테스트 서비스에서 익스포트한 테스트 케이스 목록 조회
Queries 엔드포인트: 스케줄러나 즉석 테스트 실행의 결과 조회

이러한 접근법은 개발팀이 테스트 결과를 실시간으로 모니터링하고, 프로덕션 환경과 동일한 수준의 관찰성(observability)을 확보할 수 있게 합니다.

실전 가이드

Test Infrastructure as a Service를 실제 환경에 도입하려면 다음 과정을 따라해볼 수 있습니다:

먼저 기존 테스트 프레임워크 평가부터 시작합니다. 이 단계에서는 현재 테스트 저장소의 크기, SDET 팀의 유지보수 부담, Kafka나 실시간 스트림 처리가 필요한 서비스 비율을 파악해야 합니다. 대략 1-2주 정도의 평가 기간이 필요하며, 이를 통해 전환의 필요성을 정량적으로 판단할 수 있습니다.

다음으로 파일럿 프로젝트 선정을 진행합니다. 복잡도가 중간 정도이면서 Kafka나 메시지 스트림을 사용하는 서비스를 선택하는 것이 좋습니다. 여기서 Jason Parecki가 개발한 라이브러리(또는 유사한 오픈소스 도구)를 활용하여 코드 제너레이터로 테스트 스위트의 기본 구조를 생성하고, 파일럿 서비스에 필요한 통합 테스트를 작성합니다. 초기 설정 시에는 프로덕션 서비스와 동일한 의존성 관리 방식을 따르는 것이 중요하며, 예상 소요 시간은 약 2-4주 정도입니다.

마지막으로 배포 및 모니터링으로 마무리합니다. 테스트 서비스를 프로덕션 클라우드에 배포하고, Grafana 대시보드를 구축하여 테스트 결과와 실행 시간을 시각화합니다. Cron 작업을 설정하여 주기적으로 테스트를 실행하고, 온디맨드 실행을 위한 API 엔드포인트를 팀에 공유합니다. 성공 지표는 테스트 실행 성공률이 95% 이상, 플래키 테스트 감소율 50% 이상, 개발자 피드백 루프 개선 정도로 확인할 수 있으며, 이후에는 다른 서비스로 점진적으로 확대 적용하고 CI/CD 파이프라인에 통합하는 방향으로 발전시킬 수 있습니다.

심층 분석

영상은 CrowdStrike의 실전 경험을 바탕으로 Test as a Service 접근법의 실용성을 잘 설명하고 있습니다. 특히 기존 Python CLI 프레임워크의 구체적인 문제점과 이를 어떻게 해결했는지를 명확히 제시한 점이 인상적입니다.

다만 몇 가지 보완이 필요한 부분도 있습니다. 첫째, 마이그레이션 비용에 대한 언급이 부족합니다. 기존 Python 기반 테스트를 Go 기반으로 전환하는 데 드는 시간과 리소스, 그리고 팀의 러닝 커브에 대한 구체적인 수치나 경험이 추가되었다면 더 현실적인 판단 자료가 되었을 것입니다.

둘째, 소규모 조직에서의 적용 가능성이 불확실합니다. CrowdStrike처럼 수백 개의 마이크로서비스를 운영하는 대규모 환경에서는 이 접근법의 장점이 명확하지만, 수십 개 이하의 서비스를 운영하는 중소규모 팀에서는 오히려 오버엔지니어링이 될 수 있습니다. 실무에 적용하실 분들은 현재 운영하는 마이크로서비스의 개수, 테스트 복잡도, 팀의 Go 숙련도를 먼저 평가해야 합니다.

셋째, 테스트 격리와 환경 관리에 대한 심화 내용이 부족합니다. 여러 테스트 서비스가 동시에 프로덕션 클라우드에 배포될 때 네트워크 격리, 데이터베이스 격리, 환경 변수 관리를 어떻게 하는지에 대한 베스트 프랙티스가 포함되었다면 더욱 완성도 높은 발표가 되었을 것입니다.

현재 마이크로서비스 테스트 분야에서는 서비스 메시(Service Mesh)와 통합한 카오스 엔지니어링, 프로덕션 환경에서의 테스트(Testing in Production) 등이 주목받고 있습니다. 향후 Test as a Service 접근법이 이러한 트렌드와 어떻게 결합될 수 있을지도 고려해볼 필요가 있습니다.

데이터 기반 인사이트

CrowdStrike는 수백 개의 Go 기반 마이크로서비스를 클라우드 네이티브 아키텍처로 운영하고 있으며, 이는 대규모 사이버 보안 플랫폼의 복잡도를 보여줍니다. 이러한 환경에서 빠른 배포 주기를 유지하려면 모든 통합 테스트가 CI/CD 파이프라인에서 자동으로 실행되어야 하며, 이는 테스트 인프라의 확장성과 유지보수성이 비즈니스 성공에 직결됨을 의미합니다.

발표에서 언급된 Grafana 대시보드를 통한 테스트 메트릭 시각화는 DevOps 성숙도 모델에서 중요한 지표입니다. 테스트 실행 시간, 성공률, 플래키 테스트 비율 등을 실시간으로 모니터링함으로써 테스트 품질을 지속적으로 개선할 수 있습니다. 실제로 DORA(DevOps Research and Assessment) 리포트에 따르면, 배포 빈도와 변경 실패율은 소프트웨어 전달 성과의 핵심 지표이며, 이러한 메트릭을 추적하는 조직은 그렇지 않은 조직보다 평균 2배 이상 높은 성과를 보입니다.

Jason Parecki가 개발한 exportable Go module은 CrowdStrike 내부에서 검증된 라이브러리로, 코드 제너레이터를 통해 테스트 스위트의 기본 구조를 자동으로 생성할 수 있습니다. 이는 개발자 생산성을 크게 향상시키며, Conway’s Law(조직 구조가 시스템 설계에 반영된다는 법칙)에 따라 팀이 자체적으로 테스트를 소유하고 관리하는 문화를 촉진합니다.

Kafka 기반 테스트의 경우, 기존 CLI 방식에서는 지속적인 연결을 유지할 수 없었지만, Test as a Service로 전환하면서 이 문제가 해결되었습니다. Apache Kafka 공식 문서에 따르면, 컨슈머는 최소 수초에서 수분 이상 연결을 유지하며 메시지를 폴링해야 하므로, CLI 기반 테스트는 본질적으로 이러한 시나리오를 검증할 수 없었습니다.

GopherCon 2022는 Go 커뮤니티의 대표적인 컨퍼런스로, 전 세계 Go 개발자들이 참여하여 최신 트렌드와 베스트 프랙티스를 공유하는 행사입니다. CrowdStrike의 사례가 이 무대에서 발표되었다는 것은 Go 생태계에서 마이크로서비스 테스트 전략에 대한 관심이 높다는 것을 보여줍니다.

핵심 인사이트

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

테스트를 제품 코드와 함께 관리하라 – Python CLI 프레임워크를 별도로 운영하면 시간이 지날수록 모놀리식 저장소가 되어 유지보수 비용이 급증한다. 대신 각 Go 모듈 내에 테스트 애플리케이션을 포함시키는 매크로 모듈 구조를 도입하면, 서비스와 테스트가 동일한 저장소에서 버전 관리되고 의존성이 일관되게 유지된다. 이는 Conway’s Law를 따라 팀이 자신의 테스트를 소유하고 빠르게 반복할 수 있게 한다.
Kafka와 같은 지속 연결 서비스는 CLI 테스트로 검증할 수 없다 – 실시간 메시지 스트림을 처리하는 Kafka 컨슈머는 최소 수초에서 수분 이상 연결을 유지해야 하지만, CLI는 테스트 종료 시 모든 네트워크 연결을 끊는다. Test as a Service를 도입하면 테스트 서비스를 프로덕션처럼 배포하여 goroutine에서 지속적으로 연결을 유지하며, 컨슈머와 프로듀서가 계속 연결된 상태로 실제 환경과 동일한 시나리오를 검증할 수 있다.
프로덕션 인프라를 테스트에 재사용하여 관찰성을 확보하라 – 테스트 서비스를 별도 프레임워크가 아닌 Go 마이크로서비스로 구현하면, 기존에 프로덕션 서비스에서 사용하는 메트릭 수집, Grafana 대시보드, 알림 메커니즘을 그대로 활용할 수 있다. 이를 통해 여러 클라우드와 다양한 타임라인에서 테스트 결과를 모니터링하고, 특정 트래픽 시간대의 플래키 테스트를 조기에 발견하여 DORA 메트릭(배포 빈도, 변경 실패율)을 개선할 수 있다.
코드 제너레이터로 진입 장벽을 낮춰라 – Jason Parecki가 개발한 라이브러리는 테스트 스위트의 프로토타입, 설정 파일, 기본 테스트 케이스를 자동으로 생성하므로 개발자가 처음부터 테스트 구조를 설계할 필요가 없다. 이는 신규 팀원의 온보딩 시간을 단축하고, 모든 팀이 일관된 테스트 패턴을 따르도록 유도하며, 엔터프라이즈 환경에서 수백 개 서비스를 확장할 때 표준화된 테스트 아키텍처를 보장한다.
온디맨드 실행과 Cron 스케줄링을 모두 지원하여 유연성을 확보하라 – Test as a Service는 두 가지 실행 방식을 제공한다. 개발자가 로컬에서 버그 수정을 빠르게 검증해야 할 때는 커맨드 라인으로 실행하고, 프로덕션 환경의 지속적인 모니터링이 필요할 때는 API 엔드포인트를 통해 Cron 작업으로 주기적으로 실행한다. 향후에는 PR(Pull Request) 단계에서 테스트를 자동 실행하고, 테이블 드리븐 테스트와 정규식 매칭을 지원하여 Python pexpect와 유사한 수준의 유연성을 제공할 예정이다.

요약자 노트

이 글은 GopherCon 2022에서 발표된 내용을 기반으로 작성되었으며, CrowdStrike의 실전 사례를 중심으로 Test Infrastructure as a Service 접근법을 정리했습니다. 발표에서 언급된 Jason Parecki의 라이브러리가 오픈소스로 공개되었는지는 확인되지 않았으므로, 유사한 접근법을 구현하려면 자체 개발이나 오픈소스 대안을 찾아야 할 수 있습니다.

또한 발표는 CrowdStrike처럼 수백 개의 마이크로서비스를 운영하는 대규모 환경을 전제로 하고 있으므로, 소규모 팀에서는 이 접근법의 복잡도가 실제 이점보다 클 수 있습니다. 마이그레이션 비용, 테스트 격리 전략, 환경 관리 세부사항 등은 발표에서 충분히 다뤄지지 않았으므로, 실무 도입 시 추가 검토가 필요합니다.

마지막으로 영상에서 언급된 향후 개선 사항(PR 단계 테스트, 테이블 드리븐 테스트, 정규식 매칭)은 발표 시점 기준 계획 단계이므로, 현재 구현 여부는 CrowdStrike 팀에 문의하거나 관련 커뮤니티를 통해 확인하시기 바랍니다.

GopherCon 2022: Test Infrastructure as a Service – 마이크로서비스 테스트의 새로운 접근법

개요