1. APM 정의와 필요성
2. 애플리케이션 매져를 통한 관리
3. 성공적인 APM 활용방안(이번호)

정확한 애플리케이션 측정으로 효율 극대화

어트리뷰트·메트릭스 추출로 가치 향상 … 아웃소싱·6 시그마와 연계

김종수
솔루링크 상무
jskim@solulink.co.kr

애플리케이션 포트폴리오 관리(APM)는 눈에 보이지 않는 기업의 응용프로그램 소스를 분석해 기술적 데이터를 추출하고 이를 계량화함으로써 비즈니스 차원으로 기업의 애플리케이션을 관리하는 것을 의미한다. 기업에서 애플리케이션을 계획/설계/구축/인도/유지보수 하는 일련의 활동은 비즈니스를 수행하는데 절대적으로 필요한 사항이 됐다. 또한 이에 대한 예산도 지속적으로 증가, CEO 및 CIO의 주요 관심 대상이 됐다. 이제 애플리케이션 소스코드로부터 추출된 어트리뷰터와 메트릭스를 애플리케이션 관리에 활용하는 방안에 대해 알아본다.

일반적으로 프로젝트 수립은 과거 유사한 프로젝트를 수행한 경험으로 나온 측정치나 혹은 전문가들의 경험에서 우러나온 측정치를 추정치로 삼고 일을 진행하는 경우가 대부분이다. 하지만 기존 애플리케이션이 존재한 상황에서 혹은 기존 애플리케이션과 밀접하게 연계된 시스템 개발이라는 상황에서 보면, 기존 애플리케이션으로부터 어트리뷰터를 추출해 이를 기반으로 계획을 수립하고 평가를 한다면 보다 사실적이며 누구나 인정할 수 있는 발판을 마련할 것이다.
현존 애플리케이션에 대한 소스분석을 통해 어트리뷰트 및 메트릭스를 추출하는 것은 애플리케이션에 대한 변경 영향 분석 이상의 가치를 제공하는 첫걸음이 된다. 이해를 돕기 위해 어트리뷰터와 메트릭스를 간단하게 정리했다.

·어트리뷰트(attribute) : 코드 라인 수, 아티팩트(artifact) 수, 백 화이어드(Back Fired) 기능점수, 파일 수, 프로그램 수, SQL 아티팩트 수, 웹페이지 수
·메트릭스(matrix) : 어트리뷰트를 기반으로 산업 또는 ISO 등 기관 표준에서 제공하는 값과의 연계를 통해 수치화 한 것

변경에 대한 영향분석에서 시작됐던 애플리케이션 마이닝 기술이 포트폴리오로 진화하면서 애플리케이션으로부터 추출한 어트리뷰트 및 메트릭스를 통해 보다 현실적으로 애플리케이션을 이해하고 관리할 수 있게 된 것이다.

애플리케이션 현황 분석 사례
IT 부서에서 자신들이 운영하는 기업 애플리케이션에 대한 현황을 파악하는 것을 예로 들어보고자 한다. 관리자는 시장 환경 변화에 따라 기존 애플리케이션의 기능으로는 한계가 있다고 판단해 이를 개선하고자 한다. 이를 위해 그 동안 애플리케이션 유지보수에 대해 어떤 작업을 해왔으며, 어떤 상태에 있는지를 알고 싶어한다. 먼저 현 애플리케이션에 대한 현황을 각 애플리케이션 단위로, 구성 기술 단위로 살펴봤다. 애플리케이션에 대한 이러한 기술적인 세밀한 뷰는 개발자 또는 관리자에게 애플리케이션을 기능적인 측면과 기술적인 측면에서 보다 잘 이해할 수 있게 도와준다.
<그림 1>에서 빌링(Billing) 애플리케이션을 사용한 기술 관점에서 살펴볼 때, 코볼(COBOL), 자바, SQL로 구성된 것을 볼 수 있으며, 자바가 큰 비중으로 사용된 것을 알 수 있다. 그리고 각 언어에 대한 인덱스를 통해 현황을 한 눈에 이해할 수 있게 함으로써, 애플리케이션에 대한 기술적 이해가 가능하게 한다. 그리고 여기에 애플리케이션 구조에 대한 사항, 즉 코볼과 자바프로그램에 대한 연계성, 그리고 데이터베이스 관계들에 대한 구조를 도시화한다면 전체 애플리케이션을 보다 잘 이해할 수 있다. APM 도구들은 소스 분석을 통해 애플리케이션을 개괄적인 모습뿐 아니라 이와 관련한 세부적인 프로파일을 제공함으로써 이해를 돕는다.
우선 CRM 애플리케이션에 대한 그 동안 어떤 활동들이 있었는지를 파악해 보기로 한다. 애플리케이션 개발 및 유지보수 활동 사항을 보기 위해서는 과거 시점의 상태와 기준 시점의 상태를 비교함으로써 애플리케이션 그 자체에 어떤 변화가 있었는지를 보고, 기술적 변화에 따른 투입 인력과 비용을 계산하면 각 단위 기술 변경에 대한 노력과 비용을 파악할 수 있다. 여기에서는 2월과 7월을 기준으로 메트릭스를 비교했다.
<표 1>에서 보는 바와 같이 CRM 애플리케이션 2004년 2월 버전과 7월 버전을 비교해보면 코드라인과 아티팩트, 기능점수가 줄어들고 복잡성과 표준화 위배 부문도 준 것을 볼 수 있다. 이 기간 동안 불필요한 기능을 제거하고 소스를 정리하는 등 애플리케이션을 정련하는 작업을 지속해 온 것으로 판단할 수 있다.
애플리케이션을 동일한 언어로 작성해도 복잡성의 정도에 따라 이를 유지보수 하는데 필요한 인원의 숙련도를 고려해야 하는 만큼, 좀 더 기술적인 사항으로 들어가 복잡성을 살펴봤다. 여기에서는 아티팩트를 4가지(Low complexity, Moderate Complexity, High Complexity, Very High Complexity)로 복잡성을 구분했다.
이 프로그램의 경우에는 복잡성이 낮은 것으로 볼 수 있으며, 따라서 숙련된 상급 개발자나 프로그래머가 투입되지 않아도 유지보수가 가능한 것으로 볼 수 있다. 그러나 만일 아티팩트 사이즈가 급격하게 증가한다면 이는 유지보수 인력 확보를 위해 주력해야 할 것이다.
빌링(Billing) 애플리케이션의 경우에는 아티팩트 사이즈가 증가했는데 특히 데이터베이스와 관련된 프로그램을 아티팩트 규모를 기준으로 조사해 보면 <그림 3>과 같다.
<그림 4>에서 보면 코드라인이 두 배 이상 증가했고, 특히 큰 규모의 아티팩트가 급격하게 증가한 것으로 보아 성능을 저하시킬 수 있는 상황이 예견되며 성능 관련 테스트 및 튜닝 작업이 무엇보다 먼저 필요하다는 것을 판단할 수 있는 자료가 된다.
IT 투자는 제한적이기 때문에 효과적으로 사용하는 방안을 모색하는 것이 중요하다. 실 애플리케이션으로부터 추출한 어트리뷰터와 메트릭스를 기반으로 업무 범위를 설정하고 일정을 수립하고 인원을 배치할 뿐 아니라 품질을 모니터링하는 것은 애플리케이션 생명주기 전반에 걸쳐 효율적인 관리가 가능하다는 것을 말한다.