2020 State of Performance Engineering report: (2) Organisation

Chapter 2: Organisation of performance engineering

이번 Chapter는 현재 여러분이 소속된 조직구조와 업무패턴이 가지고 있는 효과에 대해 이해하는데 도움이 됩니다. 이들을 이해함으로써, 비즈니스 목적을 만족시키는 Performance Engineering이 되도록 조직을 개선하고자 할 때 적용해 보실 수 있습니다.

Modern trends in the organisation structure

최근 몇년동안, Time to Market이 단축되고 있습니다. 비즈니스와 앱들은 더욱 더 고객중심적으로 확장 되어가고 있습니다. 이를 달성하기 위해서는, 더 큰 속도와 더 큰 응답성능을 갖출 필요가 있습니다.

이번 설문조사의 결과에 따르면, 기업들은 Performance Testing을 구성하는데 있어 다양한 접근방식을 가지고 있음을 보여주고 있습니다. 전체 응답자의 37%는 대부분 특화된 Quality Engineering Team을 가지고 있으며, 29%는 협업방식을 사용하고 있고, 17%는 개발팀이 자발적으로 업무를 수행하고 있으며, 15%는 전체 업무를 아웃소싱에 의존하고 있습니다.

생각보다 너무 많은 회사들이 Performance Testing을 아웃소싱하고 있다는 점은 놀라운 사실입니다. 이는 개발팀들이 Code에 오너십을 가지고 Performance Testing에 참여하는 현재의 추세에 역행하고 있기 때문입니다. 명확한 트렌드 중 하나는, Agile팀이 어느정도는(46%) Performance Testing에 적극적으로 참여하고 있다는 점입니다. 우리는 이러한 트렌드가 증가하길 기대합니다.

기업에서 Performance Testing을 수행하는 구성원들은 유동적인 것으로 보이며, 향후 몇년 사이에 변화될 가능성이 있습니다. 우리는 Performance Testing에 영향을 미치는 두 가지 구조적인 움직임(Tectonic Movements)이 있다고 믿고 있습니다. Agile Development Practices의 채택과 DevOps로의 이동이 그것입니다.

Agile은 개발팀이 보다 자발적으로 업무를 수행하는 것을 가능하게 하며, 업무에 대한 오너십과 책임을 더 많이 가지게 합니다. 또한, 개발과 배포의 관점에서 보다 빈번한 반복을 이끌어냅니다. 따라서, 이러한 Agile팀들은 지연시간이 짧고, 쉽게 반복 가능한 Performance Testing이 필요합니다.

Performance Testing을 운영하는 전통적인 모드는, 성능테스트 팀의 전문가와 일정을 잡고 상용환경에 배포하기 바로 직전에 한번만 수행하는 것이었으며, 목적에 적합하지도 않았습니다.(지금까지 그래오지 않았나요?) 전문가들 중 한 사람으로부터의 구체적인 예시는 다음과 같습니다. ‘Performance Testing Experts’는 “…성능테스트를 수행하고, 테스트의 복잡성을 검토하고, commit한지 3주 후에 결과를 제공하고, 다음 프로젝트로 이동합니다.” 하지만, Agile Sprints는 그보다 더 짧은 기간에 시작과 종료가 되어버리는 것이 현실입니다!

Performance Testing의 일부 또는 전체를 수행하고 있는 팀들에서 일어나고 있는 움직임이, Software Performance에 특화된 전사 전문가 조직(a centralised body of expert)에 속했었던, 그리고 현재에도 소속되어 있는 구성원들 모두에게 깊은 영향을 끼치고 있습니다.

전문가들과의 인터뷰를 통해 명확해지고 있는 사실은, 이 팀들이 역량을 갖춘 전문가 팀(Competent Specialist Teams)으로 진화할 기회가 있으며, 점점 더 그 연관성이 증가하고 있다는 점입니다. 반면에, 약하고, 느리고, 고립된 상태로 남아있는 구성원들은 연관성과 가치 측면에서 감소하게 되고, 더 이상 Gatekeepers나 Mandatory로 남아 있을 수 없습니다.

품질 게이트키퍼(Quality Gatekeeper)

품질 게이트키퍼(Quality Gatekeeper)는 개발 단계에서 소스코드 품질 강화를 위해 조직의 품질 게이트(품질 요구사항)를 설정하고, 품질 게이트를 통과하지 못하는 소스 코드는 중앙 저장소에 반영되지 못하게 하는 품질 보장 활동을 말합니다.

일반적으로 품질 게이트키퍼를 위한 활동은 커밋 빌드 검증(Commit Build Verification), 동료 검토(Peer Code Review), 정적 분석을 통한 목표 품질 게이트 통과, 코드 인스펙션 등의 활동이 있습니다.

Source: http://pseg.or.kr/pseg/atlassian/8663

전문가의 역할은 동시에 진화하고 있습니다. 우리는 다음 섹션에서 이 주제를 다룰 것입니다.

“Performance testing is still mainly carried out by specialised teams” (37%)

‘Specialised Teams’는 두 가지 유형의 팀을 포함하고 있습니다. 전통적인 ‘Center of Excellence’와 ‘DevOps-ready를 지향하는 팀’이 바로 그것입니다.

Performance TCoE(Testing Center of Excellence) 예시

Source: https://ovniland.com/the-future-use-of-load-testing-tools-for-its-end-users/

단일 조직으로서 Performance에 대해 책임을 가졌던 ‘Center of Excellence’ 그룹의 최고의 날들은 이제 저물어가고 있습니다. 옛날 Gatekeeper로서의 역할은 이제 신뢰성이 부족합니다. 대신, 자기주도적(self-directed)으로, 또한 동료(Peers)로서 Staff들이 업무를 수행하기를 기대되어지고 있으며, 이들 팀에는 Gatekeepers가 거의 참여하지 않고 있습니다. ‘Specialised Quality Engineering Teams’는 다른 구성원들과 함께 업무를 수행하는 Attitude만 제외한다면, 나쁘지 않습니다(not ‘bad’). 건강한 팀들은 Performance Engineering을 여러 업무 역할들 중 일부로 수행하는 구성원들이, 아직 업무가 익숙하지 않아서 일으키는 실수들을 감소시켜 줄 수 있습니다. 이 조직 모델은 Application Performance에 대해, 기업 차원의 강력한 조정 기능을 제공해 주지는 않습니다.

‘DevOps initiative’에 파견된, ‘Low-Latency Core Team’의 Specialist Performance Engineers는 동시에 여러 개발 팀들을 도울 수 있습니다. 이들은 또한 ‘Good Engineering Practices’를 여러팀에 걸쳐 제공하는데 도움을 줄 수 있습니다. 이러한 ‘Modern Centralised Bodies’는 End-to-End Customer Journey를 보다 더 자세히 평가함으로써, 최종 사용자의 입장을 지지하는 위치로서 자리잡아 가고 있습니다. 이들은 팀들의 직접적인 오너십 외부에 있는 테스트에 대해서도 수행이 가능하도록 지원합니다(e.g. Point Assessment부터 Continuous Integration 까지). 이들은 구체적인 경험과 노하우를 통해 Feature Teams의 Transformation을 가속화시킵니다. 이들은 품질 정의에 있어 핵심요소인 Performance를 유지합니다. 그 일환으로, 이들은 Practices를 새롭게 교체하고, 자동화 도구를 검토하며, 전체 조직들간에 동일성(uniformity) 및 재사용성을 확장하는 방법에 도전으로써, 지속 가능한 혁신을 추진합니다.

“Performance testing is directly handled by autonomous Agile teams” (17%)

Agile과 DevOps는 Performance Testing Activities에 대해 과감한 변화를 요구합니다. 그것이 설계 단계이든, 가용한 지원 프로세스를 만드는 과정이든(Data, Service, Environment), 테스트가 수행되는 시점이든, 또는 전반적인 Orchestration이든 간에 상관없습니다. 이것은 전략적인 수준, 방법론과 프로세스, 강력한 기술적인 구성요소들에 대한 Mindset을 의미합니다.

설문조사 결과의 분석을 통해, 우리는 회사들이 종종 Performance Testing의 중요성을 간과한채로 Agile로 이동하고 있다는 것을 실감하고 있습니다. Agile 개발에서의 Performance Testing에 대해, 기존과 동일하게 Waterfall Software Development에서의 Release Candidate처럼, Validation Process의 가장 마지막 순간에 와서야 Performance Testing을 수행해왔던 것으로만 생각해서, 거의 방치되고 있는 것처럼 보입니다. 이러한 명백한 방치는 불분명하고 신뢰할수 없는 아키텍쳐 요구사항으로 이어질 수 있습니다.

Agile Software Development Practices에서, 자율성과 팀간 협업의 올바른 균형을 찾는 것은 복잡할 수 있습니다. 어떤 경우에는, 기술의 선택이 실제적인 제약을 가져올 수도 있습니다. 예를 들어, 어떤 소프트웨어 라이선스는 그들이 필요로하는 어느곳에서나 수행될 수 있도록 허용하기 보다는, 특정 사용자나 특정 컴퓨터에서만 Performance Tests가 가능하도록 Lock을 걸어놓는 경우도 있습니다.

“29% are adopting a collaborative approach”

APIs와 Microservices를 사용하여 설계된 Lightweight Apps에서는, 더 작고 더 빈번한 Performance Tests를 수행하는 것이 적합할 수 있습니다. 만약 그렇다면, ‘Collaborative Approach’가 가장 장래성이 있어 보입니다.

전사조직(A Centralised Body)은 Feature Teams에게 올바른 전략을 조언하는 역할을 수행합니다. 그것은 자동화 도구나 방법론, 또는 업무 자동화 차원의 참여일 수도 있습니다. 예상 가능한 함정은 이러한 ‘Centralised Body’는 산업화와 반복력을 가능하게 하는 역할(an enabler of industrialisation and repeatability) 보다는, 단순히 Skills 제공자로서만 그 활동이 제한적으로 운영될 수 있다는 점입니다. ‘Collaborative Organisational Model’은 새로운 Code의 첫줄이 작성되기 이전 시점에서조차 실질적인 계획과 모델링이 달성될 가능성을 높여 줍니다. ‘Collaborative Approach’는 또한 여러 팀들간의 격차를 좁히는 데도 중심적인 역할을 수행합니다.

우리의 경험상, Agile Development Practices를 도입하는 회사들에서는, Performance Testing을 포함한 Performance Engineering의 관점에서 광범위하면서도 지속적인 영향이 발생하고 있습니다. 그 영향은 자동화 도구를 누가 선정하고 비용을 지불하는지에서부터, Performance에 관여하는 전문가와 Agile팀 개발자의 Skillsets에 이르기까지, 거의 모든 측면의 업무에 영향을 미치게 됩니다. 이러한 업무에 실제 참여하는 회사와 구성원들이 적극적으로 적용을 추진하지 않는다면, 그들은 전혀 관련없는 테스트를 수행함으로써, 돈과 에너지를 낭비하게 될 위험에 처하게 됩니다.

전통적인 Performance Testers와 Performance Testing Practices가 고립된 섬처럼 몇년 더 남아있을지도 모르겠습니다. 그러나, 많은 변화들이 이들 주위에서 발생하고 있고, 이들의 역할 또한 원하든 원치않든 변화하고 있습니다. 역으로, 조직이 잘 정비된 이후에는, Performance Engineering이 필요와 기대에 부합하는 도움을 제공하는 업무관계를 통해 활성화될 가능성이 있습니다.

The evolution of the role of performance tester

사람들의 기억 속에서, Performance Tester의 스킬은 대부분 성능테스트 도구를 사용하는 것과 결과를 분석하는 것이었습니다. 이들은 Tests, Ramp up Time, Traffic Profiles, 그리고 Ramp Downs을 설계했습니다. 이들은 보통 전문적이고, 헌신적인 Performance Testers로 구성된 팀의 일원이었습니다. 핵심기술은 병목현상을 식별한 후, DBA, 네트워크 전문가 등을 찾아 문제 해결에 참여시켜는 역량이었습니다. 이들의 팀은 부하발생도구를 사용하기 위해 필요한 매우 비싼 라이선스를 포함한, 테스팅 관련 예산을 통제하였습니다.

이제, DevOps 환경에서는 Performance Testing에 대해 효과적이고 연관성있게 수행하는 구성원에 대한 새로운 역할이 있습니다. 현재는 두가지 유사한 역할들이 있습니다. 성능테스트 도구를 사용하여 자동화된 테스트를 생성하는 방법을 이해하고 있는 Performance Testers와, Build Pipelines 등을 자동화하는 것을 돕는 DevOps Automation Specialists입니다.

DevOps Automation Specialists는 일반적으로 성능 테스트 도구들에 익숙하지 않습니다. 더 적절하게는, 그들은 성능테스트와 관련된 설계에 필요한 사항들에 대해서도 익숙하지 않습니다. 그들은 이 두 가지를 통합하고 사용할 수는 있지만, 명백함을 뛰어넘는 테스트의 중요성(the importance of testing beyond the ‘obvious’)에 대해서는 인식하지 못할 수 도 있습니다.

이와는 대조적으로, performance testers는 통제되고 숙련된 테스트 환경에서, 테스트를 설계하고 성능 테스트 도구를 사용하는 법은 잘 알고 있지만, Pop-up Test Environment(that lasts for minutes rather than days)와 지속적인 Build Pipeline에서 성능테스트를 설계하고 실행하기 위한 통합 방법에 대해서는 이해하지 못하고 있습니다. 현재, 전체적인 관점에서 자동화 전략을 적절하게 정의할 수 있는 전문가가 부족한 상태입니다. 기업들은 전문가들간의 공백을 메워줄 수 있는, Bridge 역할을 수행하는 구성원들이 필요합니다. 다음 질문의 답변이 가리키는 바에 따르면, 모든 성능테스트가 전문가에 의해 수행되어 왔던 시절은 이제 지나갔습니다.

성공과 진척에 대한 측정지표 또한, 기술적인 지표에서 비즈니스적인 지표로 진화하고 있습니다. 이것은 기술적인 지표가 중요하지 않다고 말하는 것은 아니지만, 그 초점이 기술적인 것 보다는 비즈니스와 수익의 측정지표에 맞추어져 있다는 것입니다.

순수하게 전담팀에 의해서만 수행되던 성능으로부터, 성능공학의 민주화(the democratisation of performance engineering)로 우리가 이동해감에 따라, 자동화 도구의 선정 또한 동시에 변경될 것 입니다. 사용법을 배우는데 몇달에서 몇년이 걸리던 자동화 도구는, 스마트함을 본질적으로 갖춘, Low-code 및 Low-touch가 고려된 도구들로 교체될 것입니다.

이러한 역할은 Agile Transformation과 함께 진화하게 될 것입니다. 예를 들어, 전통적으로 설계 단계(creating, writing, and updating test cases)에 관련된 모든 Activities는, 요구사항 변경 및 빈번한 코드 변경에 대해 반응적으로 수행됩니다. (어떤 형태이든) Agile로 가는 길에 있는 조직들은 동일 주기, 동일 Sprint에 적합한, 엄격하고 체계적인 Performance Testing이 필요합니다. 또한, 이해관계자들(비즈니스 분석가로부터 개발자 및 테스터까지)이 잘 정비된 구조로 머물면서, 유연성을 유지할 수 있도록 지원해야 합니다.

Performance Engineers는 특히 DevOps의 맥락에서 보다 광범위한 스킬들을 획득해야 합니다. 이러한 스킬들은 TDD(test-driven development), BDD(business-driven development) 그리고 MBT(model-based testing)과 같은 Software Testing의 추가적인 접근법과, 이들을 Performance Testing을 통해 보완하는 방법을 포함하고 있습니다. 또한, Data Engineering, System Monitoring 및 Observability가 관련된 역량입니다. 그들은 또한 다양한 사람들과 효과적으로 업무를 수행하는 방법을 배우고, 함께 일하는 팀들과 책임을 공유할 수 있어야 합니다. 이러한 전문직은 사용자 경험(The User Exprerience)이라는 진정한 목적에 ‘re-focused’되고 있습니다.

비즈니스 팀과의 상호작용은 요구사항을 이해하고 테스트의 정확성을 검증하는 것만큼이나 동등하게 중요합니다. 이는 Performance Testers가 소비하는 전체 시간의 18%정도까지 차지합니다. 이러한 상호작용은, 특히 상용환경에서 Performance Indicators의 이력이 없는 신규 애플리케이션에서 더욱 중요합니다.

Modern trends in tooling

마지막으로, 설문 조사결과에 따르면, 응답자의 38%가 ‘중앙 집중화된 전사차원의 성능테스트 및 모니터링 솔루션(Centralised, Enterprise-wide Performance Testing and Monitoring Solution)’을 가지고 있다고 응답했으며, 또 다른 32%는 그들이 사용하기 원하는 시점에 사용할 수 있는 Centralised Tools를 가지고 있다고 답변했습니다. 전반적으로, 이러한 전사조직(Centralised Teams)의 역할과 목적은 변화가 필요합니다. 우리가 인터뷰한 전문가들에 따르면, 이들은 다양한 소프트웨어 도구들을 선정하고 관리할 가능성이 낮습니다. 이제, 도구들은 Engineering Organisation을 넘나들며 사용되고 있으며, 이들이 도구의 선정에 영향을 미칠 가능성이 있습니다. 예산 또한 QA(Quality Assurance)나 Testing 부서로부터 소프트웨어 개발 담당 임원(VP of software development)에게로 이동하고 있습니다.

일부 상용 소프트웨어 도구는 라이선스 계약에 의해, 조직의 특정 구성원만 사용 가능하도록 사용자를 제한하기도 합니다. 만약 그렇다면, 이러한 도구들은 Project나 Team 차원에서 performance testing을 수행하기 원하는 경우나, 지속적인 사용을 원하는 경우에는 적합하지 않습니다.

다음 글에서는, ‘Chapter 3 Practices of performance engineering’에 대해 계속 이어 나가도록 하겠습니다.

Source: https://www.us.sogeti.com/explore/research/reports/state-of-performance-engineering/