성능은 조기에 고려해야 한다.

- Rebecca Parsons
- 블로그 : http://www.thoughtworks.com/what-we-say/CTO-blog.html

Rebecca Parsons 박사는 ThoughtWorks의 최고 기술 고문이다. 그녀는 전기통신에서 신생 인터넷 서비스까지 여러 업계에서 20년 이상 어플리케이션 개발 경험을 가지고 있다. Rebecca는 여러 프로그램 위원회에서 언어와 인공 지능 출판에서 책을 썼으며, 여러 저널에 리뷰를 썼다. 그녀는 대규모 분산 객체 어플리케이션의 구축과 이종 시스템의 통합에 선두적인 경험을 넓히고 있다.






비즈니스 사용자는 기능 요구사항을 통해 우선 자신들의 요구를 표현합니다. 성능, 복원성, 가동성, 지원 요구 등과 같은 시스템의 비기능 측면은 아키텍트의 영역입니다. 하지만, 종종 비기능 요구사항에 대한 사전 테스팅이 개발 생명주기에서 매우 늦게까지 남게 되면, 때론 운영 팀에게 전부 넘겨지기도 합니다. 이는 너무나 흔히 발생하는 실수입니다.

그 이유는 다양합니다. 추측하건대 실질적으로 요구된 기능을 수행하지 않는다면 빠르고 복원이 강한 시스템을 만든다는 것은 의미가 없다는 것 같습니다. 환경과 테스트는 그 자체로 복잡합니다. 아마 제품화된 시스템의 초기 버전은 크게 활용되지 않을 것입니다.

하지만, 프로젝트 개발 기간에서 늦게까지 성능을 추구하지 않는다면 성능이 변화할 때에 대한 엄청난 양의 정보를 잃어버리는 것입니다. 성능이 주요한 아키텍처 기준이고 설계 기준이라면, 성능 테스팅은 가능한 한 빨리 시작되어야 합니다. 만일 2주 반복 기반의 애자일 방법론을 사용하고 있다면, 성능 테스트는 늦어도 세번째 반복 과정에 포함되어야 한다고 저는 주장합니다.

왜 이것이 그렇게 중요할까요? 가장 큰 이유는 성능을 떨어뜨리게 만드는 변화의 종류를 아는 사람이 최소한 여러분이기 때문입니다. 성능 문제에 직면했을 때 전체 아키텍처에 대해 생각하는 대신에 가장 최근의 변경에 집중해야 합니다. 초반에 그리고 자주 성능 테스트를 수행하면 집중해야 할 변화의 범위를 좁히게 됩니다.

초기 테스팅에서 성능을 진단하는 것조차 할 수 없을지도 모르지만, 작업 시작에 대한 성능 수치의 기준을 갖게 됩니다. 이러한 일련의 데이터는 성능 문제에 대한 원천을 진단하고 실마리를 찾는데 중요한 정보를 제공합니다.

이러한 방법은 또한 실질적인 성능 요구사항에 대해 검증된 아키텍처적이고 설계적인 선택을 하게 해줍니다. 특히 엄격한 요구사항을 가지는 시스템에 대해서 초기 검증은 시스템을 시간에 맞춰 인도하는데 중요합니다.

기술적인 테스팅은 또한 지속하기가 매우 어렵습니다. 적절한 환경을 마련하고, 적합한 데이터를 생성하고, 모든 필요한 테스트 케이스를 정의하는 것은 시간이 걸립니다. 조기 성능 테스트를 강조함으로써 테스트 환경을 점증적으로 마련할 수 있으며, 그에 따라 성능 문제를 발견할 때 훨씬 많은 비용을 줄이게 됩니다.


원문 : 모든 아키텍트가 알아야 하는 97가지 사실 - It's never too eary to think about performance