Shift Left Performance Testing 개요

Quality at Speed

빠르게 변화하는 IT환경에서 기업들은 성공적인 Digital Transformation 추진을 위해 DevOps 및 Agile프랙티스의 채택을 점차 확대해 나가고 있으며, 인프라 환경 또한 Cloud기반으로 빠르게 전환되고 있습니다. 이러한 환경변화로 인해, Project팀에게 SW개발을 위해 주어지는 기간은 상대적으로 점차 단축되어가고 있는 추세를 보이고 있습니다.

이러한 상황을 함께 현장에서 경험하며 전사 성능테스트를 지원하고 있는 구성원의 입장에서는, 고객이 기대하는 수준 이상의 성능품질을 확보하면서도 정해진 Open일정을 준수해야 하는 ‘Quality at Speed’에 대한 압박이 커지고 있는 것이 사실입니다. 현재 당사에서는 전사 SWAT(System Workload Analysis and Tuning) 조직의 전문역량에 기반하여, 제 3자 관점에서 신속하면서도 철저하게 성능 테스트 및 최적화 튜닝을 제공함으로써, 이러한 문제상황들을 효과적으로 해결해 나가고 있습니다.

한편, SW개발조직/문화/프로세스/프랙티스 전반에 걸친 변화의 방향에 따라, 성능테스트 영역 또한 최초로 수행되는 시점이 ‘왼쪽으로 이동’되는 추세가 관찰되고 있습니다. 기존의 시스템 오픈 전 제 3자 관점의 성능테스트와는 별개로, SW개발 Lifecycle 초기부터 Project팀 자체적으로 성능 수준을 평가하고 개선영역을 식별하는 Self-Service기반의 “Shift Left Performance Testing”이 바로 그 변화의 대상입니다.

이번 글에서는 최신 비즈니스 환경에서 요구되는 속도에 맞게 고품질SW를 제공받기 원하는 고객 needs에 적기대응하기 위해, ‘Quality at Speed’ 전략중의 하나로 관심받고 있는 Shift Left Performance Testing의 기본 개념에 대해 알아보도록 하겠습니다.

Shift Left Performance Testing이란?

‘성능 테스트가 왼쪽으로 이동한다’라는 것은 위의 그림을 통해 쉽게 알 수 있듯이, 개발자와 성능테스트 담당자가 SW개발 Lifecycle 초기 단계부터 성능테스트를 수행할 수 있다는 것을 의미합니다. 좀더 이해를 돕기 위해, 우선 글로벌 테스트 기업인 Ciginiti에서 언급하고 있는 ‘Shift Left’ 용어에 대한 정의를 살펴보면 다음과 같습니다.

Shift Left is the practice of focusing on quality from day one of a project in order to identify and fix defects as they arise. It requires accountability and increased communication with all stakeholders in the process to ensure the project is staying in-scope. (Shift Left는 결함 발생 즉시 식별하고 수정하기 위해 프로젝트 첫 시작일부터 품질에 중점을 두는 프랙티스입니다. 프로젝트가 Scope내에 유지되고 있음을 보장하기 위해서는 프로세스에 참여하는 모든 이해 관계자들간에 책임감 및 보다 많은 커뮤니케이션이 요구됩니다.)

그동안 일반적인 성능테스트는 (사용대상이 한정된) 전문 자동화도구에 기반하여, 다양한 비즈니스 도메인별 경험이 많은 소수의 성능테스트 전문가에 의해 전담 진행되었으며, SW 개발 Lifecycle이 끝나가는 시점에 성능인프라를 구축한 후 수행되어 왔습니다. 하지만, 개발된 모든 API를 대상으로 성능테스트를 수행하는 것은 제한된 시간상 현실적으로 어렵기 때문에, Workload분석에 기반하여 핵심적이고 많이 사용하는 기능(ex. 규모에 따라 5개~20여개 이내로 한정) 위주로 성능테스트가 수행되고 있으며, 나머지 개발 영역에 대한 성능품질은 여전히 개발자의 역량에 의존적인 상황에 있는 것이 사실입니다.

한편, Project팀의 입장에서는 Agile개발 프랙티스를 잘 준수하고 있더라도, 각 스프린트별 종료시점에 가보면 ‘성능이슈’가 해결되지 않은 채로 제품이 개발되었음을 뒤늦게 인지하는 경우가 많은 것이 현실입니다. 이로인해, 성능결함 수정을 위한 Rework 비용이 계속 늘어나는 상황을 반복적으로 경험하고 있습니다. 이러한 문제들을 해결하고자, SW개발 초기단계부터 ‘엄격한 성능테스트 수행을 위한 Project팀 문화’가 필요함을 강조하는 과정에서 나온 것이 “Shift Left Performance Testing”입니다.

‘Shift Left’ 적용을 위한 자동화 프레임워크 측면의 변화

Shift Left Performance Testing을 적용하기 위해서는, Project팀에서 기능이 구현되는 시점에 기능별 단위 테스트 외에도 성능 테스트가 추가적으로 수행될 수 있도록 지원하고, 성능이슈가 발생하면 즉시 보고하는 체계로 프로세스가 변화되어야 합니다. 이를 지원하기 위해서는, 성능 테스트가 자동으로 실행가능하도록 CI(Continuos Integration) 프로세스의 일부로 통합되어야 합니다. 이를 통해, 개발자는 빌드단계의 일부로 성능검증 환경을 지원받게 되고, 각 코드 체크인 후 기능 및 단위 테스트와 함께 성능 테스트를 로컬 환경에서 수행할 수 있게 됩니다.

■ 참고. LoadRunner 와 Jenkins CI의 통합 방법

LoadRunner의 경우, Jenkins CI Server를 위한 Application Automation Tools 플러그인을 제공하고 있으며, LoadRunner Controller 시나리오를 Build Script의 일부로 실행하기위한 메커니즘을 제공합니다. 이 플러그인은 성능 테스트 Script를 Build Step으로 Trigger하도록 허용하고, Jenkins User Interface에 성능테스트 수행결과 화면을 제공합니다.

출처: “Integrate LoadRunner with Jenkins CI”, Microfocus

실 적용 사례로서 위의 Microfocus의 예를 살펴보면, 새롭게 추가되는 ‘단위 성능테스트’ 영역은 CI Pipeline의 일부로 통합되면서 ‘Performance Engineering Framework’의 형태로 운영됩니다. Project팀은 이 자동화 프레임워크를 통해 새로운 구성 요소가 추가될 때마다 전체 성능에 미치는 미묘한 영향을 사전에 파악하고 적기에 성능결함을 제거할 수 있게 됩니다.

개발 초기단계부터 성능 관련 결함을 발견 할 수 있는 체계로 변화한다는 것은, 결과적으로 회사의 개발 문화가 함께 변화한다는 것이며 개발자가 성능테스트에 참여하는 것을 의미합니다. 이를 통해, 개발팀은 전체 개발영역이 빌드되는 시점까지 더 이상 기다리지 않고, 성능 저하현상이 발견되는 즉시 당일 내에 자신이 개발한 기능의 성능품질을 향상시킬 수 있습니다.

그러면, 업무 프로세스는 어떻게 변화해야 할까?

우선, 이러한 변화를 수용하기 위해서는 Project팀의 인식 전환이 필요합니다. ‘성능테스트는 전사품질조직만 수행하는 것이다’라는 기존 고정관념에서 벗어나는 것이 필요합니다. 전체 개발 프로세스에서 지속적으로 성능 테스트를 수행하고 그 영역을 점차 확대해 나감으로써, 결과적으로는 ‘적은 비용으로 더 나은 제품을 만들수 있다’는 확신이 필요합니다.(아래 IBM Systems Sciences Institute의 연구결과에 따르면, 일단 Release 되고 난 이후에 발견된 결함을 수정하기 위해서는, 100배이상의 비용이 필요하다는 통계는 이미 잘 알려진 사실입니다.)

다음으로, Project팀은 각 스프린트별 종료 조건(Exit Criteria)으로 ‘성능테스트 수행완료’ 여부를 추가하는 것이 필요합니다. ‘개발이 완료되었다’는 선언에는 각 스프린트에서 성능테스트 또한 정상적으로 완료되었다는 의미가 포함되어야 합니다.

마지막으로, 이러한 변화가 효과적이고 지속적으로 강화되기 위해서는 업무의 일부로 잘 정착할 수 있도록 프로세스화가 필요합니다. 다음과 같은 선진 기업들의 Best Practice들을 참고하여, 주어진 역할에 맞게 업무 및 커뮤니케이션을 수행할 수 있도록 프로세스를 지원해야 합니다.

■ The Best Practices Performance Testing within a Sprint

• 시스템 아키텍쳐 협의 및 계획 수립 과정에 참여하여 성능관련 요구사항을 수집하고 문서화한다.
• 고객 및 이해관계자간 긴밀한 협력을 통해 각 ‘Performance Stroy’에 대한 수용 기준을 정의한다.
• Project 초기, 계획단계 및 Infra구축 단계에 성능테스트 엔지니어가 참여한다.
• 성능테스트 엔지니어는 개발(스프린트)팀의 구성원으로 포함된다.
• 개발자가 User Story기반 코딩을 수행하는 동안, 성능테스트 엔지니어는 Test Case 및 Data준비를 수행한다.
• 성능과 관련있는 User Story는 기능테스트가 완료되는 즉시 성능테스트 엔지니어에게 전달한다.
• 단위성능테스트를 수행하면서 개발자, 아키텍트 및 시스템 분석가에게 지속적인 피드백을 제공한다.
• 사용된 성능테스트 자산은 프로젝트 및 버전별로 공유한다.
• 스프린트내 시간활용도를 높이기 위해 업무시간 이후 테스트가 수행되도록 자동화 기반 스케쥴링을 적용한다.

  출처: “Performance testing in Agile environments”, HP

성능테스트관련 User Story 작성 예시

마지막으로, Shift Left Performance Testing 개념이 현실적으로는 ‘어떻게 Agile 환경과 성능테스트가 연관성을 가지고 업무에 적용될 수 있는지’ 이해를 돕기 위해, 아래 간단한 예시를 드는 것으로 기본 개념에 대한 설명을 마무리하고자 합니다.

Element	Description
개발대상	Mobile Web으로 제공되는 영업관리 애플리케이션
사용자 규모	현재 가입자 5천명
고객 비즈니스 목표	“총 가입자수를 6개월 내에 1만명 수준으로 확대하기 위해, Accelerated Mobile Pages를 적용하여 모바일 장치에서의 페이지 로딩 속도를 높이고, Web3.0으로 업그레이드하여 어떤 컴퓨터나 단말기에서도 가입자가 원하는 데이터에 접속하고 즉시 사용할 수 있도록 하고자 함”
고객 요구사항	“영업관리 애플리케이션의 담당자로서, 해당 서비스가 최대 1만명의 사용자까지 확장 수행될 수 있도록 함으로써, 신규 가입자와 기존 가입자 모두 응답시간 지연 없이 애플리케이션을 사용할 수 있어야 합니다”
스프린트 요구사항	“영업관리 애플리케이션의 담당자로서, 해당 서비스가 1만명의 동시사용자(Concurrent User) 상황에서도 정상적으로 수행되어야 하며, 영업정보 조회 시 응답시간(Response Time) 3초 이내에 해당 결과가 스크린에 표시되어야 합니다.”
스프린트 수행	각 스프린트별로 3초이내 조회 요구사항이 유지됨을 확인하였습니다. 일부 스프린트에서 응답성능 지연이 확인되었으나, 스프린트 종료 전 바로 수정반영 되었습니다.
성과	비기능 요구사항 달성여부가 각각의 스프린트에서 확인되었기 때문에 3초 이내의 응답성능을 만족하는 애플리케이션이 고객에게 적기제공 되었습니다.만약, 최종 스프린트 시점까지 성능 측정이 미뤄졌다면, 제품출시가 늦어지거나 성능 요구사항을 만족시키지 못한채로 상용배포 되었을 것입니다.

요약

지금까지 Shift Left Performance Testing의 기본적인 개념에 대해 간단히 살펴보았습니다. 성능테스트의 시점이 왼쪽으로 이동한다고 해서, 기존에 전사조직이 수행하던 제 3자 관점의 성능테스트 및 최적화 튜닝 업무까지 완전히 대체되는 것은 아니며, SW 개발 Lifecycle 전반에 걸친 ‘성능테스트 확장’을 통해 성능관련 Decision Point가 추가되는 개념으로 접근하시면 됩니다.

Shift Left Performance Testing을 통해, Project팀은 각 스프린트별로 새롭게 개발되는 기능 또는 결함수정 영역에 대해 성능측정과 함께 의사결정을 위한 품질 피드백을 바로 얻을 수 있게 됩니다. 또한, 성능저하요소에 대한 빠른 판단과 함께 개발영역 전반에 대한 최적화가 가능해짐으로, 결과적으로는 전체적인 제품 관점에서 성능이 우수한 제품을 고객에게 적기 제공할 수 있는 품질기반 체계로 전환할 수 있게 됩니다.