실전:리팩토링, 다르게 생각하기. Part 4
비즈니스의 속도, 개발 방법을 바꾸다.
비즈니스의 속도가 민첩하게 변화되면서 가장 크게 변화된 것은 팀의 구조와 개발팀, 기획팀의 거버넌스 체계입니다. 다음의 그림을 보죠.
고객과 내부의 작업자를 연결한 비즈니스의 구성에 있어서 고속으로 기획 및 개발이 이루어지려면 어떻게 해야 할까요? 기존의 피라미드 구조의 권한을 가진 거버넌스 구조로 이런 기민한 비즈니스 민첩성을 가질 수 있을까요?
매우 당연하게 비즈니스의 통제와 관련된 직원에 대해서 엄청난 권한 이향이 발생되게 됩니다. 소비자의 요구사항이 거의 직접 내부 작업자들에게 연결됩니다.
기존의 프로세스와 시스템 중심의 구조에서 의사결정 중심의 구조로 이동하게 되며, 이 구조는 DevOps의 구조의 형태로 진행되게 됩니다. 보통, DevOps구조를 명확하게 가지고 있는 곳이라면, 팀의 체계가 세분화되고, 배포 권한들이나 신규 기획 및 구현과 관련된 '권한'등이 대부분 팀원들이나 조직원들에게 이동되게 됩니다.
당연하게 배포 자동화 프로세스나 QC/QA 등의 체계 등이 매우 세분화되고 유연한 형태로 변화된 구조만이 이러한 DevOps구조에 적합합니다.
제가 속한 와탭의 경우에도 거의 가상화 된 조직으로 구성되어져 움직이는 매우 기민한 DevOps조직입니다.
분명한 것은 '고객'부터 기업 조직 내의 다양한 '점'들이 모두 이어지게 됩니다.
디지털 마케팅과 기업의 서비스는 하나다
라고 정의할 수 있습니다.
디지털 마케팅, 비즈니스의 속도에 대해서 소프트웨어 공학에서의 해결책들은 대부분 계획과 설계에 집중화되어 있습니다. 실제, 구현되고 동작되는 서비스들의 모든 액션이나 로그들을 추적할 수 없기 때문에 '모델'을 세우고 그 모델을 중심으로 프로세스와 품질을 추상적으로 관리하려 했습니다.
그 대표적인 3가지의 프로세스 평가 모형들은 다음과 같습니다.
하지만, 이 방법들은 기민하게 가동되는 1주일 간격으로 배포가 동작하는 디지털 비즈니스의 환경에는 적합하지 않습니다. 다른 방법을 찾아야 합니다.
더군다나, 대표적인 경험 중심의 학문도 변화하고 있습니다.
그 대표적인 학문은 바로 '의학'입니다. 기존의 임상의학의 경우에는 아픈 환자에 대한 모델과 의료행위에 대한 기존에 증명된 모델들을 통해서 과학적인 방법으로 접근하는 방법으로 의료행위가 동작하였습니다. 의사 또한 직접 증상을 관찰하고 자신의 가설을 통하여 환자를 치료했죠.
하지만, 시대가 변했습니다. 환자들은 connected health기술들을 통해서 데이터들을 방대하게 수집하고, 의사들 역시 새로운 논문이나 신약, 치료법들에 대해서 데이터 분석과 경험적인 서포트를 받기 위해서 방대한 데이터 분석의 도움을 받아서 진료를 하기 시작했습니다.
의학 역시, 기존에 다루지 않았던 데이터들에 대해서 집중하기 시작했습니다.
이제, 소프트웨어 개발도 이러한 관점으로 변화되어야 하지 않을까요?
기존의 리팩터링들이 체크리스트와 프로세스, 기법 등을 통하여 유용한 결과를 얻어내는 모델의 형태를 취하는 추상적인 단계로 실증적이지 못했고, 매우 많은 시간들이 필요했습니다.
특히, 리팩터링의 관점들은 다음의 단계들을 진행했지만, 그 작업은 매우 방대하며, 실제 개발기간보다 더 더 필요한 것이 사실입니다.
중복된 코드 Duplicated Code
긴 메서드 Long Method
거대한 클래스 Large Class
게으른 클래스 Lazy Class
추측성 일반화 Speculative Generality
임시 필드 Temporary Field
메시지 체인 Message Chains
미들 맨 Middle Man
부적절한 친밀 Inappropriate Intimacy
다른 인터페이스를 가진 대체 클래스 Alternative Classes with Different Interface
불완전한 라이브러리 클래스 Incomplete Library Class
데이터 클래스 Data Class
거부된 유산 Refused Bequest
주석 Comments
하지만, 관점을 이런 행위와 모델의 접근법이 아니라, 실제 구현되고 동작중인 서비스에서 문제를 찾는 방법으로 접근법을 바꾸고 의료행위에서 자신의 경험에만 의존하는 것이 아니라, 의료영상기기인 MRI를 사용하듯이 방법을 바꾸어야 합니다.
다음의 프로파일들을 자동으로 추출한다면 위에서 언급된 리팩터링 작업의 상당 부분들이 실증적으로 처리할 수 있습니다.
특정 시점의 Transaction End-List
특정 시점의 SQL Query List
특정 시점의 Nested Web-Transaction End-List
특정 시점의 User, Transaction, Resource List
특정 시점의 Remote HTTP Call List
특정 시점의 Method List
물론, 모든 소스를 검토하고 다시 리뷰하는 시간을 거치면서 작업하면 좋겠지만, 작업 시간의 효율은 매우 떨어집니다.
그래서, SW 구조에 맞추어서 사용자들이 실제 서비스를 사용하는 행위와 해당 행위의 웹 트랜잭션을 기반으로 해당 서비스의 실제 상태(CPU, 메모리, 네트워크)등의 트랜잭션을 추적 관리하고, 이를 기반으로 통계적인 접근법을 사용하는 방법으로 문제가 큰 부분부터 잡아들어가는 방법을 사용하도록 유도하겠습니다.
이 방식은 다음의 그림으로 표현할 수 있습니다.
물론, 이러한 데이터들을 추출하고, 정제하고, 통계적으로 빠르게 접근할 수 있는 방법을 제공한다면, 리팩터링은 전체 소스를 뒤져가면서 논리적인 상황들을 연상하는 방법만으로 접근하는 것이 아니라는 것을 보여줍니다.
이제, 기존 리팩터링의 방법을 넘어서서 메서드 프로파일링을 기반으로 웹 트랜잭션을 세밀하게 검토하고 관리할 수 있습니다.
물론, 이러한 방법은 그냥 되는 것이 아닙니다. WebService Performance Framework라는 도구의 도움을 받아야 합니다. 이 Framework는 메서드 레벨의 추적이 가능할때 부여할 수 있습니다. 기존에 만들어졌던 APM제품들은 이런 접근이 불가능합니다. ( 국내외 모든 APM 제품 기준 )
또, 자랑합니다. 필자는 25년을 소프트웨어 공학을 해왔습니다만, 이렇게 손쉽고 빠르고, 정확하게 메소드 레벨을 추적하는 기술을 본적이 없습니다. 그렇습니다. 와탭의 APM( http://www.whatap.io )은 가능합니다. 그것도, 고가의 설치형 APM이 아니라, 필요시에 필요한 만큼만 서비스받아서 문제를 해결할 수 있습니다.
(월 몇만원의 서비스로 리팩토링 전문가를 고용해보십시요. )
빠르게 변화해야 하는 비즈니스의 속도, 기존 리팩토링으로는 해결할 수 없습니다. 와탭은 기존의 정적 분석과 동적 분석을 뛰어넘어, 숨겨진 메서드의 문제들을 통계적으로 추적 관찰할 수 있습니다.
hidden method troubble 처리 기법은 와탭의 Active Stack 기술(특허 : 10-2016-0078864)은 비즈니스의 속도가 필요한 모든 IT기업에게 정말 매력적인 방법을 제공합니다.
