실전:리팩토링, 다르게 생각하기. Part I

부제:만들기 전에 무언가를 해결하는 것이 효과적일까?

10년 넘도록 동작하던 레거시에 가까운 코드로 동작하던 A기업의 고객 시스템에서 지속적으로 성능 문제가 발생하고 있다면 해당 서비스의 담당자는 머리를 잡고 고민할 것이다.

여러 가지 고민을 하겠지만, 대부분의 결론은 '서버'의 용량을 증설하는 Scale Up이나 Scale Out으로 결론이 난다. 소스나 내부에 대해서 어떻게 할 수 없을 경우가 대부분이기 때문이다.

분명한것은, 어떤 방법으로 증설하던 '비용'이 추가적으로 발생할 것이며, 이 '비용'에 대해서 부연설명을 하거나 해명을 할 준비를 하게 된다.

임원회의 때에 땀을 흘리며 브리핑을 할 것인지, 수월하게 할것인지에 대해서 고민하게 된다. 이런 문제는 어느 회사, 어떤 조직, 어떤 관리장의 입장에서도 비슷하게 발생한다.

지속적으로 성능 문제가 발생한다는 것은 어떤 것일까? 대표적인 케이스들만 서술한다면 사용자가 로그인하기 힘들다던가, 반응이 느려서 고객센터에게 전화가 많이 오거나, 홈페이지에 댓글이 연달아 달리는 경우일 것이다.

문제는 이 문제가 과거에는 잘 동작하던 시스템이었는데, 모바일 시대로 바뀌면서 발생하는 경우이다.

과거에는 해당 서비스들이 기업 내부의 직원들이 주로 다루었기 때문에 아주 큰 문제를 일으키지는 않았다.

하지만, 사용자들이 증가하고 모바일로 유사 서비스들이 제공되는 시대로 돌입하면서, 기존에 유야무야 존재하던 버그나 성능장애에 대한 이슈들은 이제 실제 고객의 클레임이나 고객의 불평불만을 접수하는 CS 부서의 주된 요청사항의 하나가 되었다.

매번 고객담당부서의 아우성을 IT 인프라 운영부서나 개발 총괄이 들을 수밖에 없는 시대가 된 것이다.

물론, 이런 문제를 해결하기 위해서 소프트웨어를 연구하는 많은 사람들은 그 해결책을 찾기 위해서 많은 연구를 하고, 대응책을 마련했다. 그 대표적인 것은 바로 '프로세스 평가 모형'을 만들어서 만들어지거나 만들어진 소프트웨어, IT서비스의 문제를 해결하려고 한 것이다.

대표적인 것 3가지를 살펴보자.

하나. ISO 9000 ( ISO 9000-3)

품질경영원칙을 미리 정립하고 시스템 기준으로 구축한다면 소프트웨어 품질이 좋아져서 IT서비스가 매우 효과적으로 운영될 것이라는 생각으로 만들어진 품질 기준이다.

프로세스의 관점으로 고객만족을 지속적으로 개선하자는 것이며, 경영자의 책임이나 소프트웨어 개발에 투여되는 자원들에 대한 관리, 구현체에 대한 측정 분석 및 개선책을 통해서 SW 개발과 공급, 설치와 유지보수를 위한 지침서들을 통해서 이런 성능 장애와 품질문제를 해결하고자 한 것이다.

둘. CMM(Capability Maturity Model)
SW 개발 조직의 실제 수행평가를 통해서 품질을 잡고자 하는 시도였다. 미 국방성(SEI Software Engineering Institute)에서 추진한 방법으로, 신뢰성 있고 사용하기 편리한 소프트웨어는 '성숙된 조직'에서 얻어 낼 수 있다는 가설 위에서 출발했다.

그러므로, 보다 '성숙된 개발 조직'을 갖추기 위한 체크 방법과 구현 방법들이 주로 고민되었다.

셋. SPICE(Software Process Inprovement and Capability dEtermination)

CMM의 성숙도 모형과 ISO/IEC12207의 SW생명주기 모형을 결합하여 프로세스의 능력 결정과 프로세스 개선을 위한 방법으로 품질을 높이고, 성능을 잡는 방법을 고안한 것이다.

이런 소프트웨어 공학들이 실제 소프트웨어를 개발하고 Lean 하고 기민하게 움직이는 현재의 소프트웨어 개발 방법과 비교한다면 너무도 추상적인 개념과 측정할 수 없는 개발자나 개발 조직 등의 품질을 잡으려고 한 시도였다고 솔직하게 이야기하자.

과거, IT 비즈니스의 신규 기능이나 신규 서비스의 개발이 9개월 이상 소요되던 시대에는 이러한 방법을 통해서 반복적인 설계와 미리 예측된 상황들에 대해서 고민하면서 이 문제를 개발 전과 개발 중에 해결하려고 애를 쓴 것이기 때문에 나름 의미가 있었다.

하지만, 현재의 IT서비스를 돌아보자. 빠르면 1주, 늦어도 2~3주에 한 개의 IT서비스가 새로 만들어지며, 기획부서는 데이터를 직접 분석하여 새로운 서비스를 만들어낼 준비를 한다. 개발자들은 빠르게 이렇게 만들어지는 서비스들을 대응해야 하는 고속 개발의 시대로 접어들었다.

더군다나, 사용자들의 행동 패턴을 예측할 수 없는 모바일 기기들에 대해서 대응하는 IT서비스를 구현하기 위해서 수십만, 수백만의 사용자들을 고려해야 하는 MSA의 시대이다.

이제는 소프트웨어들은 어느 정도의 품질과 어느 정도의 성능을 위한 공학적인 도움은 받았으나, 그동안 공학의 '모델'에서 애써 외면하던 5%의 영역이 실제 IT서비스에서 문제를 일으키기 시작한 것을 다들 몸으로 느끼고 있다.

대표적인 것이 특정 시간, 특정 일자만 되면 CPU가 급등하거나 네트워크가 급등하는 등의 반복적인 상황이 발생하고 있다는 것이다. 이런 상황들은 '모형'에서는 대부분 오차로 인지하는 영역들이며, 특이한 영역으로 구분되었기 때문에 '공학'은 고민하지 않았다.

관리적으로는 경위서나 사유서로 대체하고... 1년에 며칠만 고생하면 되었기 때문이다. 하지만, 모바일 시대에서 이런 방식으로는 경쟁회사와 경쟁업체에게 자사의 서비스에 대한 신뢰도를 급락하게 하는 주요한 사유가 된다.

사용자들은 '어떤 날' '어떤 시간'에 성능장애를 겪고 있다면, 기존의 '소프트웨어 공학'만으로는 해결이 안 된다는 것을 이제 깨달아야 한다. 사용자들에게는 WebService Application Performance Framework의 접근법이 필요하고, 해당 장애나 문제를 일으키는 '한 줄의 코드'에 집중해야 한다.

기존의 공학은 이 '한 줄의 코드'를 유추와 분석, 가설과 모형으로 찾아냈지만, 현재의 IT기술은 소프트웨어 개발자들에게 관련 스냅샷과 프로파일링 기법으로 빠르게 1줄의 코드를 빠르게 찾아낼 수 있는 시대로 돌입했다.

다음의 사례를 참조하시기를... '2년 동안 못 찾은 모바일 뱅킹의 장애 원인을 진단하다.'

데이터기반의 리팩토링이 가능하도록 모니터링을 재해석한 와탭!

http://whatap.io