전문가칼럼

DBMS, DB 구축 절차, 빅데이터 기술 칼럼, 사례연구 및 세미나 자료를 소개합니다.

성능 테스트를 이끄는 리더가 IT 서비스의 주역이 된다

전문가칼럼
DBMS별 분류
DB일반
작성자
dataonair
작성일
2011-04-12 00:00
조회
13072





성능 테스트를 이끄는 리더가 it 서비스의 주역이 된다

성능 테스트 프로세스와 준비사항

포드에서 최초로 도입한 컨베이어 벨트는 자동차의 대량생산을 가능케 했다. 이것이 가능했던 이유는 자동차를 제작하는 과정에 따라 각 단계 별로 수행해야 하는 일을 정의했기 때문이다. 그리고 모든 단계가 종료됐을 때는 한 대의 완성된 자동차가 나오도록 설계했기 때문이다.이와 같이 하나의 결과를 얻기 위해 전체 업무를 단계 별로 나누고 각 단계별로 수행해야 하는 일들을 정의한 것을 프로세스(process)라고 한다.일반적으로 프로세스는 업무묶음을 의미하며, 프로세스를 전체 업무에 적용하는 이유는 바로 효율성 때문이다.


지금부터 효과적이고 효율적인 성능 테스트 수행을 위해서 어떤 단계들이 요구되며, 각 단계별로 어떤 업무를 수행해야 하는지 그리고 각 업무는 어떤 조직이 분담해 진행하는지 알아보겠다.

성능 테스트 프로세스

대부분의 사람들이 성능 테스트를 수행하는 데 많은 노력이 필요하지 않는 것으로 오해한다. 하지만 성능 테스트는 실제 it 서스 전반에 대한 성능을 검증하고 확보하는 활동이기에, 사항에 따라서 매우 복잡한 절차를 거치게 되고 이에 따른 시간과 노력도 만만치 않게 들어간다.

일반적으로 성능 테스트는 계획.분석, 설계.구현, 실행, 완료.리포팅 단계로 진행된다. 이 중 가장 업무 비중이 큰 구간을 꼽으라면 계획분석과 설계구현 단계로 구성된 준비과정이다. 왜냐하면 성능 테스트를 수행하기 위해 논리적이고 물리적인 환경을 구성하는 과정이기 때문이다. 테스트 수행 환경이 구성되지 않은 상황에서는 당연히 정확한 테스트를 수행할 수 없다.

또 준비과정에서 기존 성능 자료를 수집하고 이에 따른 워크로 드를 분석하는 과정은 이후 테스트를 수행할 때 기준과 근거가 되기에, 이 부분이 정확하게 진행되지 못한다면 수행결과가 나온다 하더라도 테스트 결과 자체의 신뢰도에 타격을 입게 된다.


테스트 수행 단계는 실제 테스트를 수행해 이슈사항을 발견하고, 이를 통해 개선사항을 도출하는 과정이다. 이 단계는 업무의 개수와 발생된 이슈의 성격에 따라 시간이 매우 유동적이다.명심할 것은 업무의 개수에 따른 일정 변화는 예측가능 하지만 이슈가 발생하는 경우의 일정변화는 예측하기 힘들다.

이런 과정들을 거치면 여러 가지 회의록과 분석자료 그리고 개선사항 도출에 따른 개선사항 내역서가 산출물로 나오는데, 일반적으로 계획서와 결과 보고서에 그 내용이 포함돼 나온다.
<표 1>은 각 단계별 주요 업무와 그에 따른 output을 정리한 내용이다.
07_01.png
<표 1> 성능 테스트 수행단계 및 업무

이제부터 각 단계의 주요 업무들이 필요한 이유와 어떤 활동들을 통해 이루어지는지 자세하게 살펴보겠다.
우선 계획.분석단계는 테스트를 수행하기 위해 논리적인 환경을 구성하는 단계이다. 테스트 수행을 위한 논리적인 환경은 테스트의 목적 및 목표설정과 테스트 조직구성 그리고 기타 테스트에 필요한 사항뿐만 아니라 고려사항에 대한 협의와 합의를 통해서 설정되는 모든 것들을 아우른다.

이 단계에서 반드시 수행해야 하는 업무는 테스트를 수행하는 목적을 명확히 해 수행범위를 정하고, 목표를 설정해 테스트의 최종 완료조건을 설정하는 것이다. 그 이유는 테스트의 목적과 목표에 따라서 테스트 수행에 필요한 일정이나 소요비용 등이 변동되기 때문이다.

그 이후에는 테스트 수행방안을 선택해야 하는데, 마련된 테스트 수행방안이 테스트 목적에 정확하게 부합하는지를 최우선으로 고려해야 한다. 이 단계에서는 테스트 방법론을 설정하고 측정하는 모니터링 항목들을 정의한다.

테스트 수행 방법론이 결정되면, 테스트의 완료조건을 공유하고 전체적인 테스트 수행일정을 수립해야 한다. it 서비스의 특성상 인력 투입기간이 곧 비용이기 때문에 전체 일정을 수립하는 부분은 고객과 서비스 제공업체 모두에게 매우 민감한 작업이라 할 수 있다.

설계.구현 단계에서는 성능 테스트 수행을 위한 물리적인 환경이 구성돼야 한다. 여기서 말하는 물리적인 환경이란 실제 테스트 대상 시스템, 테스트 대상 업무의 스크립트, 테스트 시나리오, 모니터링 등을 모두 말한다.

이를 준비하기 위해 테스트 대상 업무가 어떤 패턴으로 수행되는지와 얼마의 빈도로 수행되는지 등에 관한 워크로드를 분석한다. 여기서 워크로드는 업무 수행패턴과 빈도를 의미하며, 실제성능 테스트 시나리오를 작성하는 근거가 된다.

워크로드 분석이 완료되면 테스트 대상 업무를 확정하고, 테스트 시나리오를 설계한다. 테스트 시나리오는 테스트 수행방안과 순서 등의 내용을 포함해야 하며, 목표인 고객 요구사항과 각 시나리오를 연결시킬 수 있어야 한다. 상세내용에는 각 테스트 수행과정에서 테스트 업무 비율과 빈도에 관한 구체적인 수치가 표시돼야 한다.

그리고 테스트를 수행하기 위한 환경이 구성돼야 하는데, 이를 위해서는 구간별 네트워크가 반드시 개통돼 있어야 하며 테스트대상 업무를 사용할 때 필요한 데이터들이 준비돼 있어야 한다. 그리고 테스트 엔지니어가 스크립트 작업이나 모니터링 준비를 할 수 있는 환경도 완성돼 있어야 한다.

테스트 시나리오 설계와 테스트 환경구성이 완료되면 테스트스크립트 작성을 시작한다. 테스트 스크립트는 대상 업무의 흐름에 따라 작성해야 하며, 테스트 스크립트를 작성하면서 테스트 데이터에 대한 검증도 병행한다.

테스트 스크립트 작성까지 완료되면 설계된 테스트 시나리오에 따른 부하 발생 시나리오를 구현.적용하며, 사전 정의된 성능 측정요소들을 모니터링 할 수 있도록 준비한다. 비로소 성능 테스트를 위한 물리적인 준비가 완료된 것이다.

성능 테스트의 실행은 성능 요소 측정과 발생이슈의 추적 및개선방안 도출 그리고 재분석으로 구분할 수 있다. 이 활동을 통해 성능 검증과 확보가 이뤄져야 한다.
07_02.png
<그림 1> 성능 테스트 실행 절차

테스트 실행은 성능 테스트의 목적이 성능 검증이냐, 성능 확보냐에 따라 과정의 반복여부가 결정된다. 성능 검증의 경우 현재 성능 요소를 측정해 이슈를 도출한 상태에서 테스트 활동을종료할 수 있지만, 성능 확보는 목표 성능이 테스트 종료조건이 되기 때문이다.

대부분 성능 확보를 목적으로 하는 테스트는 그 요건이 대부분 현재 업무에 대한 변경이기 때문에, 변경 전후를 비교하는 테스트가 주로 실시된다. 이 때 성능 기준이 현재 업무의 성능 수준이 되기에 현재 성능의 기준 데이터를 만드는 과정이 매우 중요하다.
실제 테스트가 완료되면 마감리포팅 단계로 들어가는데, 지금까지 테스트를 수행한 자료들을 취합하고 그 결과를 보고서로 작성해 보고한다.
이 과정에서 중요한 활동이 두 가지 있는데, 첫 번째는 결과 보고서 작성이고 두 번째는 이슈 리스트 작성이다. 결과 보고서는 고객사에 제공되는 서비스 수준에 대한 보고이면서 서비스 장애와 관련된 내용이 주를 이룬다.

이슈 리스트는 내부자료로 활용할 수 있으며, 성능 테스트 중에는 운영상 발생할 수 있는 다양한 장애상황이 제공되기 때문에 현상에 따른 원인과 조치방안을 정리해 놓으면 내부 인력의 역량향상에 크게 효과를 볼 수 있는 자료로 활용할 수 있다.

성능 테스트 수행 조직 및 r&r

지금까지 성능 테스트의 전체 프로세스에 대해 이야기했다. 테스트를 수행할 때는 누가 어떤 일들을 해야 하는지에 대한 기본적인 교통정리가 필요하다. 그래서 테스트 조직에 대해 간단히 살펴에는 넓은 범위에서 진단과 모니터링이 실시되기 때스트를 수행할 수 없다. 이런 이유로 성능 테스트를 수행할 때에는 전문 인력으로 구성된 성능 테스트 조직과 개발그룹 그리고운영조직 등이 함께 성능 테스트를 수행해야 한다. <그림 2>는 성능 테스트를 수행하기 위해서 어떻게 조직을 구성해야 하는지 설명하고 있다.
07_03.png

<그림 2>는 현재 필자가 소속된 곳의 조직구성이다. 성능 테스트 수행 시, 각 담당자들의 담당해야 하는 업무들이 적은 편이 아 니지만 대표적으로 수행하는 업무들을 <표 2>에 나열해봤다.

<표 2>에서 보는 것같이 조직 별로 수행하는 업무가 서로 상이하기 때문에 테스트 담당자와 pm은 각 조직간 연결점의 역할을 충실히 수행해야 하며 주기적인 대화를 통해 놓치는 구간이 없게 성능 테스트를 진행시켜야 한다. 그리고 각 서포트 조직이나 티 어 별 성능 관리자들은 이슈가 발견되었을 때는 그 사실을 숨김없이 공유해 올바른 해결방안이나 개선안이 마련되도록 노력해 야 한다.
07_04.png
<표 2> 일반적인 성능 테스트 수행 시 담당자 별 r&r

체크리스트

처음 성능 테스트를 수행할 때에는 어떤 것들을 준비해야 하고, 다음 단계를 위해서 어떤 준비를 해야할지 잘 모르고 진행한다. 각 단계별로 얻어야 하는 내용이 무엇이며 이를 위해 준비해야 하는 것들이 무엇인지를 잘 정리해둔다면 의사결정과 성능 테스트 진행에 소비되는 시간과 비용을 현격하게 줄일 수 있다.

따라서 각 단계별로 체크리스트를 만드는 것이 좋다. 물론 매테스트 상황마다 체크리스트가 변경될 수 있다. 하지만 공통적으로 반드시 확인해야 할 것들이 있을 터, 이것들을 잘 정리한다면 성능 테스트의 전 과정을 보다 수월하게 진행할 수 있을 것이다.

<표 3>은 각 단계별 필수 확인사항을 정리한 것이다.
07_05.png
<표 3> 성능 테스트 단계별 체크리스트 요약

사이트나 업무특성에 따라 구체적인 항목이 다를 수 있겠지만, 결국 해당항목을 확인했을 때는 그 내용을 명확하게 알 수 있어야 한다.
많은 일들이 그렇지만, 업무량에 비해 성능 테스트를 수행할때 주어지는 시간은 길지 않다. 따라서 어떤 일을 어떻게 수행해야 하는지 미리 계획하지 않는다면 그만큼 소요되는 비용도 늘어날 것이다. 그 뿐인가 전 단계에서 정확하게 수행되지 않은 업무는 반드시 다음 단계의 업무에 안 좋은 영향을 끼칠 수밖에 없다. 잘못된 데이터로 수행한 테스트 결과나 기존 운영환경과 너무도 이질적인 환경에서 수행한 테스트 결과를 믿을 수 있을까 당연히 신뢰도는 떨어지고 성능 테스트를 수행한 것 자체가 무의미해진다.
또 성능 테스트 특성 상, 환경이 바뀌거나 성능 테스트 항목이잘못 측정되는 경우에는 앞서 수행한 측정값이 무의미해진다. 최악의 경우 테스트 조직 전체가 잘못된 성능 테스트 절차를 수행해 모든 테스트를 처음부터 다시 수행하는 일도 심심치 않게 일어나고 있다.

거듭 강조하지만, 성능 테스트를 수행하는 것은 매우 복잡한 작업이며 수많은 변수들이 존재하기 때문에 한번 어그러진 테스트를 고집스럽게 진행하는 것은 일을 더욱 힘들고 어렵게 만든다. 이런 상황을 원천적으로 없애고 발생하더라도 최소화시키기 위해서는 성능 테스트 수행단계를 정리할 필요가 있으며, 매단계 마다 테스트 환경이나 데이터, 시나리오 등을 꼼꼼하게 확인하고, 각 단계별 필수 수행업무를 정리해 업무 부하를 최소화 해야 한다.

또 성능 테스트는 테스트 엔지니어나 테스트 pm만 수행하는 것이 아닌, 성능 관리자와 시스템 각 티어 별 엔지니어 그리고 개발자 등이 함께 현상을 모니터링 하고 분석하는 과정이기에 전체적인 테스트 흐름을 관리하는 사람이 되기 위해서는 반드시 수행해야 하는 과정을 숙지해야 한다.

이번 기고에는 성능 테스트의 수행단계와 조직 그리고 r&r에 대해서 이야기했다. 아직 성능 테스트 분야로 공식적이고 정형화 된 업무수행 단계는 없지만, 각 성능 관리조직 별로 자체적인 수행단계는 있을 것으로 여겨지며 앞에서 소개한 단계와는 크게 차이가 없을 것으로 생각된다. 결국, 보다 나은 서비스를 제공하기 위해서 성능 테스트를 수행해야 한다면, 올바른 테스트 수행단계와 체계를 세우는 것이 가장 효과적이고 효율적일 것이다.
과연 이런 올바른 단계와 체계를 세워 성능 테스트를 수행하면어떤 결과를 얻어낼 수 있을까 다음 기고에서 실제 사례를 통해 알아보겠다