Self Service를 위한 VuGen에 대한 관점의 전환

이번 글에서는, 홍성진 매니저님의 최근 글인 “Integration of Loadrunner Cloud and VUGEN“에서 잠깐 언급하신 ‘VuGen’과 관련하여, PJT팀이 Self Service를 시작하기 위해 필요한 관점의 전환에 대해 정리해 보고자 합니다. VuGen 자체의 전문적인 사용방법은 홍성진 매니저님이 추후 연재하실 예정(!)이므로, 여기서는 ‘관점의 변화’ 측면에서 간단히 정리해 보도록 하겠습니다.

1. LoadRunner VuGen 사용자가 적은 이유

VuGen은 ‘Virtual User Generator’의 약자로, LoadRunner에서 부하발생을 위한 Script를 작성하기 위한 도구입니다.

성능테스트 시장점유율 1위이며, 다른 성능 테스트 도구 대비 사용자 측면에서 매우 편리한 기능을 제공하는 완성형 도구임에도 불구하고, 아직까지도 VuGen을 이용하여 Script를 작성하고 LoadRunner기반 성능 테스트를 수행할 수 있는 인력이 드문 현실은 어떤 이유들 때문일까요?

이 궁금증을 풀기 위해, 우선 과거로부터 현재까지 LoadRunner와 관련하여 어떠한 이슈와 변화들이 있었는지에 대해 간단히 살펴보겠습니다.

2. 기존 Lock Key방식의 License가 가져온 이슈들

기존에는 LoadRunner를 구입하면, 그 구성요소로서 VuGen, Controller, Analysis 3개의 Applicaion이 1Set의 제품으로 제공 및 설치 되었습니다. 이때 적용되는 License가 특정 서버 또는 특정 노트북에 한정되어 물리적인 Lock Key 방식으로 묶이게 되기 때문에, 성능 테스트 담당자 외에 다른 구성원들이 쉽게 접근하기는 구조적으로 어려운 도구였던 것이 사실입니다.

한편, 일부 회사(ex. 금융, 통신 등)에서는 Permanent License를 구입하여 내부망 서버에 LoadRunner 제품을 설치한 후, 원격데스크톱 접속으로 접근하도록 하여, 회사 내 여러 PJT팀들이 License를 공유하는 방식으로 사용하기도 했습니다. 하지만, 이 경우에도 하나의 License를 동시에 사용하는 것은 불가능한 구조이기 때문에, 한 날짜에 두 팀이 성능테스트를 해야 한다면, 한 팀은 주간에, 다른 팀은 야간에 밤을 새서 해야만 하는 상황이 발생하게 됩니다.

PJT 상황 때문이 아닌, 단지 Tool License 사용제약 이슈로 인해, 시스템 Open 막바지 시점에 바쁜 엔지니어들이 성능테스트를 위해 야간과 새벽에 근무해야 하는 비효율적인 상황들이, 과거부터 근 20여년이 지난 현재까지도 간간히 발생하고 있습니다.

3. PJT현장에서의 학습 기회 제한

위와 같이, 전사차원의 성능 테스트 도구가 있음에도, License가 특정 서버 또는 특정 노트북에 종속되게 되면, PJT 현장의 구성원들 입장에서는 해당 도구를 써 볼 수 있는 기회가 제한되는 상황이 발생하게 됩니다.

PJT 개발자 입장에서 보면, 성능테스트 단계에서 LoadRunner기반 성능테스트 수행 상황을 자주 접하고, 성능테스트 담당자와 함께 계획/설계 단계에 긴밀히 협업하여 Script 작성을 지원하고, 밤낮으로 성능 테스트를 수행하는 횟수가 점차 늘어감에도 불구하고, 직접 Script를 작성해보고 테스트를 수행해볼 수 있는 기회는 거의 없는 것이 사실입니다.

HP에서 LoadRunner ‘Community Edition’이라는 이름으로 뒤늦게 50Vuser까지 All Protocol에 대해 무료로 사용해볼 수 있는 Full Version이 제공 되었음에도, PJT에서 이미 LoadRunner는 ‘좋은건 알지만 비싸서 써보지는 못하는 도구’로서의 이미지가 굳혀진 터라, 개발자 입장에서는 쉽게 접할 수 있는 오픈소스도구인 JMeter 등에 먼저 관심이 가게되는 것은 어쩌면 당연한 결과였는지도 모릅니다.

그 결과, LoadRunner를 사용하여 성능테스트를 수행할 수 있는 사람은 전사조직의 몇몇 성능테스트 담당자 아니면 외부 벤더의 성능테스트 전문가 정도로 유지되다 보니, 2000년대 초중반부터 LoadRunner를 학습하고 성능테스트를 수행해온 그 당시 2~30대의 전문인력들이 현재까지 그 명맥을 이어오고 있을 뿐, 회사 내외부를 살펴보더라도 신규 인력이 학습을 통해 LoadRunner기반 성능전문인력으로 새롭게 성장하여 나타나는 경우는 보기 드문 상태가 된 것 같습니다.

4. Agile 개발 팀을 위해 탄생한 LoadRunner Cloud

LoadRunner Cloud는 아주 새로운 제품은 아닙니다. 지난 2014년 7월에 HP에서 새로운 Cloud기반 성능테스트 도구로서 ‘StormRunner Load’라는 이름으로 먼저 출시된 바 있습니다.

출시 당시의 기사를 잠깐 살펴보면 다음과 같습니다.

HP refreshes Performance Testing Suite with StormRunner Load for Agile app development teams

By Jamie Hinks published September 16, 2014

HP는 Agile 개발 팀이 간단하고 직관적이며 확장 가능한 Cloud 플랫폼을 사용하여, 애플리케이션 제공 및 품질을 가속화할 수 있도록 설계된 새로운 소프트웨어 솔루션으로서 성능 테스트 제품군을 업데이트했습니다.

HP StormRunner Load라고 불리는 이 솔루션은 LoadRunner 및 Performance Center를 포함하는 기존 성능 테스트 제품군에 합류하여 테스트를 크게 개선하는 데 특히 중점을 둡니다.

“기업이 애플리케이션과 솔루션을 Cloud로 계속 마이그레이션함에 따라, 사용자 수 증가에 따른 애플리케이션 프로그램의 성능이 저하되지 않도록 해야 합니다.”라고 HP Software의 애플리케이션 제공 관리 총괄 관리자인 Raffi Margaliot은 말했습니다.

“HP StormRunner Load는 Agile 팀이 확장 가능한 고성능 클라우드 기반 최신 앱을 제공하는 동시에, HP에 대한 기존 투자를 활용할 수 있도록 특별히 설계되었습니다.”

StormRunner Load는 앱을 개발할 때 더 스마트한 테스트 기술을 사용하려는 Agile 개발 팀을 지원하기 위해 노력하고 있습니다. 이를 통해 팀은 솔루션 간에 테스트 스크립트를 재사용하고 StormRunner Load를 사용하여 동적으로 확장할 수 있습니다.

Source: https://www.itproportal.com/2014/09/15/hp-refreshes-performance-testing-suite-stormrunner-load-agile-app-development-teams/

StromRunner Load 출시의 목적은 위의 기사에서 강조하고 있듯이, Agile팀이 Cloud기반 성능테스트 환경에서 빠르게 성능측정을 수행하고, 고품질의 애플리케이션을 출시할 수 있도록 지원하는데 그 목적이 있음을 알 수 있습니다.

문제는, Agile 환경하의 PJT 개발팀 입장에서는 기존의 LoadRunner조차도 아직 익숙하지 않은 도구이기 때문에, ‘Scalable, High-Performing Cloud-based Modern Apps’ 개발을 돕기위한 성능테스트 도구로서 StormRunner Load가 제시되더라도, 신속하게 이 Tool을 적용할 준비는 전혀 되어있지 않았다는 점입니다.

이런 상황을 근본적으로 개선하기 위한 방향으로서, 2020년 Micro Focus는 지난번 우리가 함께 살펴본 바 있는 LoadRunner Family “re launch”를 추진하게 된 것이 아닌가 생각이 듭니다.

5. VuGen과 LoadRunner Cloud

우리가 그동안 살펴 보았듯이, LoadRunner Cloud는 더이상 특정 회사 내부망의 서버나 전사 성능테스트 조직이 보유한 특정 노트북에 License가 종속되어 존재하지 않습니다.

PJT에서 Cloud기반으로 구동되는 LoadRunner Cloud를 사용하고 싶다면, 원하는 시간에 웹 브라우저로 바로 접속하여, 부하발생하고 싶은 국가와 지역을 선택하여 바로 부하를 줄 수 있습니다.

부하 발생 및 실시간 모니터링하는 Controller와, 수행 결과를 바로 분석할 수 있는 Analysis의 기능들이 모두 LoadRunner Cloud로 통합되었기 때문에, 이제 남아있는 것은 VuGen입니다.

기존에는 VuGen, Controller, Analysis가 LoadRunner라는 하나의 제품으로 구성되어 있었다면, 이제는 VuGen과 LoadRunner Cloud로 두개의 역할만이 구분되어 사용됩니다.

비용 측면에서도, Vugen은 무료로 다운로드 받아 사용 가능하기 때문에 Script 작성과 사전 Tool 검증은 부담없이 수행하고, LoadRunner Cloud에서 실제 부하발생이 시작되고 끝나는 시간동안에 대해서만 발생하는 부하 비용(ex. $0.3/VUH)을 고려하면 됩니다.

6. Self Service, 변화의 시작

개발자가 ‘본인이 만든 애플리케이션’을 대상으로 성능 Script를 작성하는 것은, 제 3자인 성능테스트 담당자가 짧은 시간동안 구조를 익히고 Script를 작성하는 것보다 훨씬 쉽고 효율적입니다. Script 작성을 위해 필요했던 성능 테스트 담당자와 개발자간의 회의 및 질의과정이 Self Service를 통해 상당부분 단축될 수 있습니다.

단위 업무별 성능 측정 및 개선 작업이 사전에 Self Service로 이루어진다면, 성능 테스트 단계에서는 남아있는 주요 성능이슈들을 모아 종합적인 관점에서 성능테스트 전문 조직과 함께 측정 및 최적화하는 마지막 과정을 효과적으로 수행할 수 있게 됩니다.

정리하면, PJT 개발자 입장에서 VuGen을 통해 부하를 발생하고자 하는 대상 업무의 Script 작성이 가능한 단계로 넘어올 수만 있다면, 바로 대상 시스템의 성능을 측정하고 결과를 확인하는 환경은 이미 준비되어 있다는 것을 LoadRunner Cloud는 말해주고 있습니다. 이러한 Cloud기반 환경에서, ‘관점의 변화를 통한 Self Service의 시작’은 생각보다 멀리있지 않은 것 같다는 생각을 하며 이번 글을 마칩니다.

감사합니다.

[끝]