보이지 않는 자산 수치화 … 검증된 애플리케이션 활용 가능

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

일반 제조업체에서 시작된 6 시그마 활동이 전사적으로 확산되면서, IT 조직에서도 고품질 서비스 및 생산성 향상이라는 슬로건을 내걸고 CMM 활동과 연계한 다양한 움직임이 일고 있다. 하지만 응용 애플리케이션과 같은 소프트웨어는 눈에 보이는 것이 아니고, 정형화된 부품을 생산해 내는 제조산업과는 달리 개인에 따라 프로그래밍하는 방법이 다양하기 때문에 관리 또는 생산성 향상을 측정하는 메져(Measure)를 찾는 것은 쉬운 일이 아니다.
이번호에서는 소프트웨어 측정을 위한 메져에 대해 이론적인 설명보다는 실업무적인 접근을 통해 소프트웨어인 기업 애플리케이션을 전략적으로 관리하기 위한 현실적인 방안을 다루고자 한다. <편집자>

애플리케이션의 중요성이 점점 더 커지고 있는 상황에서 여러 애플리케이션을 운영하고 개발하는 IT 부서에서 이를 어떻게 관리할 것인가가 중요한 이슈로 대두되고 있다. 다양한 기술의 등장과 아웃소싱의 확산, 업무 통합 등 다양한 환경 변화는 IT 부분에 있어서도 많은 변화를 요구하고 있다. 막대한 비용이 들어가는 애플리케이션 구축이나 운영이 개발업체 또는 SI업체의 제안만으로 투자에 대한 결정을 하거나, 운영에 들어가는 비용을 예측해 이를 예산화하는 일이 이제는 불가능하게 됐고, 설득력있는 데이터를 바탕으로 IT 투자를 계획하고 수행하며 이에 대한 결과를 모니터링 하기를 요구 받고 있다.

애플리케이션 메져(Measure)의 역할을 살펴보면 다음과 같다.
-측정할 수 없으면 관리할 수 없으며, 향상도 기대할 수 없다.
애플리케이션을 측정하는 가장 중요한 이유는 보이지 않는 자산을 수치화함으로써 관리가 용이하도록 하는 것이다.
-1천명의 전문가의 말보다는 정확하게 도출된 하나의 측정치가 더욱 가치가 있다.
애플리케이션에 대한 투자 및 관리는 여러 사람들이 협업을 필요로 하는 것으로서 추상적이거나 개념적인 것보다는 수치화하거나 구체화한 것이 더욱 힘을 얻게 된다.
-아웃소싱의 증가
IT 개발 및 운영을 아웃소싱하면서 고객과 서비스 업체 사이에는 갈수록 불협화음이 심해진다. 애플리케이션 변경 및 진화에 대한 일정 및 노력, 비용에 대해 서로 상이한 목소리를 내고 각자의 의견이 옳다는 것을 증명하기 위해 노력한다. 애플리케이션에 대한 일관되고 검증된 측정치는 계약자간에 상호 동일한 시각으로 현상을 보게 하고 상호 협의할 수 있도록 지원한다.

애플리케이션 포트폴리오 메져에 대한 이해
대부분의 기업들이 비즈니스 목적에 따라 애플리케이션 또는 프로젝트에 대한 여러 메져를 계획, 수집하고 이를 분석하는 여러 활동을 하고 있는데 이는 프로젝트나 애플리케이션을 통제(Control), 평가(Evaluate), 이해(Understand), 그리고 예측(Predict)하기 위함이다.
측정(Measurement)은 현재 상황을 평가하거나 미래 상황을 예측하는 활동에 활용되는 것으로써, 실 세계의 현상, 특성, 결과를 숫자로 표현하는 활동이나 프로세스를 의미한다.
메져(Measure)는 측정 단위 또는 표준을 의미하는데 정보 요구와 관련된 어트리뷰터(Attribute)로 구성된다. 애플리케이션 개발과 관련해 가장 중요한 메져로는 일정, 비용, 사이즈, 그리고 품질 등을 들 수 있으며, 숫자로 표현된 메져를 메트릭(metric)이라고 한다.
현재 거론되고 있는 대부분의 메져는 프로젝트라는 프로세스 차원에서 필요하다. 현재 가지고 있는 자원을 최대한 활용, 이익을 극대화하기 위해 프로젝트를 효율적으로 계획하고 수행하는데 목적을 두고 있는 것이다.
그런데 고객 또는 기업의 입장에서 보면 기업 활동의 근간이 되는 애플리케이션 자체에 대한 정보는 충분하게 가지고 있지 않다. 프로젝트 산출물인 애플리케이션과 문서가 시간이 지남에 따라 노후화돼 회사 캐비닛 안에 쌓여 있을 뿐, 애플리케이션에 대한 지식은 시간이 갈수록 부족함을 느끼게 된다.
따라서 애플리케이션에 대한 변경 및 진화, 통합이 진행되고 있는 애플리케이션 생명주기에 대한 전반적인 관리가 어렵게 된다. 애플리케이션 생명주기에 걸친 관리 및 전략 수립을 위해서는 프로젝트 기반의 프로세스에 대한 어트리뷰터뿐 아니라 제품(애플리케이션)에 대한 어트리뷰터를 획득해 이를 의사결정의 기반으로 삼아야 하는 것이다.
프로젝트 포트폴리오 관리와 애플리케이션 포트폴리오 관리는 각각 관점이 다른데 포레스터의 자료에 의하면 프로젝트 포트폴리오의 목적은 다음과 같다.

-진행 중이거나 계획하고 있는 프로젝트에 대한 정보 수집, 중복 방지
-효과적인 자원 할당
-비즈니스 가치 향상

애플리케이션 포트폴리오 관리의 목적은 다음과 같다.
　
-애플리케이션에 대한 유지보수나 진화에 대한 의사결정을 비즈니스 방향에서 결정
-비즈니스에 필수적인 애플리케이션을 정의하고 이에 대한 서비스 지원 및 자원 배분
-아웃소싱에 대한 협의 도출

이러한 사항들은 프로젝트 개시, 구축, 운영이라는 단계에서 프로젝트 포트폴리오 관리가 애플리케이션 포트폴리오 관리로 이관되고 있다.
애플리케이션에 대한 메져 중 가장 중요한 요소로 꼽히는 것은 사이즈, 납기(일정), 품질, 그리고 비용 등인데, 이들은 프로젝트 계획시 반드시 고려돼야 하는 것으로 프로젝트 관리를 통해 축적되고 표준화되는 것들이다. 그러나 개발하고 있는 애플리케이션에 대한 소스 코드 차원의 실 데이터나 기존의 애플리케이션에 대한 메져는 충분하게 제공되지 않고 있다.
개발 중이거나 운영되고 있는 애플리케이션에 대한 자세한 정보를 획득할 수 있다면 이를 프로젝트 경험과 연계해 보다 자세하고 정밀한 프로젝트 규모나 비용 등을 산정할 수 있을 것이다. 즉 아파트 32평이라는 단편적인 사실이 아니라 방이 3개가 있고, 화장실이 2개가 있으며, 거실은 천연재인 마루로 마감한, 전체 20층에서 15층에 위치한 32평 아파트라고 정의하는 것이 보다 구체적인 정보인 것이다.
일반적으로 많이 범하는 오류 중 하나가 손쉽게 수집할 수 있는 데이터를 메져화 함으로써 메져를 위한 목적을 반영하는데 문제가 발생하는 점이다. 또한 처음부터 필요하다고 생각되는 모든 메져를 대상으로 많은 자원과 시간을 들여 측정하려고 시도해 메져에 대한 부담감으로 인해 도중에 그만둬 버리거나 데이터를 지속적으로 수집, 관리하지 않아 정확성을 잃어 간다는 것이다.

애플리케이션에 대한 메져
애플리케이션 포트폴리오 관리란 관점에서 애플리케이션에 대한 정보를 획득하는 것은 엔지니어링 기술을 필요로 한다. 애플리케이션을 분석해 기술적 어트리뷰터를 추출하고 이를 비즈니스 관점의 메져로 발전시킴으로써 보다 애플리케이션에 대한 객관적이고 설득력 있는 정보를 제공할 수 있다. 애플리케이션에 대한 분석은 기본적으로 사이즈(규모), 복잡도, 비용, 품질, 표준화 등을 들 수 있다.

1) 애플리케이션 사이즈
애플리케이션 사이즈는 크게 기능점수(Function Point)를 계산하는 방법과 라인수 (LOC)를 계산하는 방법으로 구분할 수 있다.
기능점수는 프로그램 소스 라인수와는 관계없이 기능에만 초점을 맞추어 산정하는 방식으로 1970년 중반에 IBM에서 규모에 대한 효과적이고 예측 가능한 척도를 만들기 위해 탄생했다. 이 방법은 논리적으로 연관된 데이터 또는 제어 정보 그룹을 처리하거나 저장하는 트랜잭션 및 데이터기능 유형을 식별하는 것을 포함한다. 그리고 데이터 양이나 복잡도에 따라 몇 가지 요소들에 의해 가중치가 매겨지며 미조정기능점수와 일반 시스템 특성을 합해 계산된다. 우리나라에서도 2004년부터 기능점수 산정방식을 공공기관에서 선택했으며 일반 기업에서도 그 동안 투입됐던 기술인력의 수 대신 기능점수로 개발 및 유지보수의 대가를 지불하기 시작하고 있다.
기능점수는 소프트웨어 생명주기 동안에 여러 단계, 즉, 요구사항, 설계단계, 시험단계, 구현단계, 유지보수 단계에서 계산될 수 있다.

2) 복잡성(Complexity)
애플리케이션에 대한 복잡성을 측정하는데는 여러 가지 방법이 있으나 일반적인 방법으로는 싸이클로메틱 복잡성(Cyaclomatic Complexity), OO복잡성(Object Oriented Complexity), 4GL 복잡성, SQL 복잡성 등으로 구분할 수 있다.

* 싸이클로메틱 복잡성(Cyaclomatic Complexity)
1976년 토마스 맥케이브(Thomas McCabe)에 의해 개발된 싸이클로메틱 복잡성은 하나의 모듈에 대한 독립적인 경로의 수를 계산함으로써 소프트웨어 품질을 측정하는 방식으로 가장 일반적으로 사용되는 지표이기도 하다. 많은 조사들 통해 싸이클로메틱 복합성은 소스 코드에서 발견된 에러의 수와 밀접하게 연관되어 있다는 것이 증명됐다. 복잡도에 따라 작성된 코드에 대한 이해도와 변경의 용이성을 예측할 수 있으며, 테스트 범위 및 규모를 정할 수 있다. 복잡성이 낮은 애플리케이션의 경우에는 쉽게 이해할 수 있으며, 변경이 용이하고, 테스트하기가 간단하고 이에 따라 에러 발생률도 낮다. 이 방법은 코드의 복잡성을 측정함으로써, 개발자들은 잠재된 문제들이 있는 곳을 파악해 코드의 품질을 정확하게 측정할 수 있다.

* OO메트릭스(OO Metrics)
자바, C++ 과 같은 오브젝트 프로그래밍 언어들은 객체간의 상속성 및 깊이(Depth) 등 객체지향 프로그래밍 특성을 기반으로 한 복잡도를 수치로 계산한 것으로 상속, 캡슐화, 다형성 등에 대한 복잡도를 측정한다. 이들에 대한 요소는 다음과 같다.

- 클래스 개수
- High Cyclomatic Complexity Class(WMC metric): 복잡성이 높은 클래스 개수
- High Density of Inheritance Class(DIT Metric): 상속 Depth가 높은 클래스 개수
- 인터페이스 개수
- High Length Class:소스코드 라인수가 긴 클래스 개수
- High Weight Class: 클래스 내부 멤버 변수와 메써드의 개수가 많은 클래스 개수

* 4GL 복잡성(Complexity)
이는 사용자가 직접 접하는 화면과 관련된 것으로서 각 화면의 컨트롤과 이벤트, 그리고 라인수에 의에 측정된다. 측정 요소는 ‘폼’등이 있다.

- 폼(Form) : 화면 개수
- 헤비 폼(Heavy Form) 개수 : 콘트롤과 이벤트 개수에 의해 판단
- 길이 폼(Length Form) 개수 : 코드 라인의 길고 짧음에 의해 결정
- 데이터 레이어를 많이 사용하는 폼(Form) : 폼에서 DB를 호출하는 수에 따른 판단
- 하이 팬 아웃 폼(High Fan-Out Form) : 해당하는 화면에서 다른 화면 또는 모듈을 호출하는 수

* SQL 복잡성(Complexity)
오라클 데이터베이스의 PL/SQL이나 MS SQL의 T-SQL처럼 데이터베이스와 연관된 SQL에 대한 싸이클로메틱 복잡성을 측정한다. 이에 대한 요소로는 Raw SQL 복잡성, 서브 질의 개수, FROM 절 개수, GROUP BY 개수 등이 있다.

3) 표준화(Standard)
애플리케이션에 대한 표준화는 여러가지가 있으나 여기에서는 네이밍 컨벤션(naming Convention), 문서화, 베스트 프랙티스 등에 다루고자 한다.

* 네이밍 컨벤션(Naming Convention)
프로그램 소스를 작성하는 규칙에 대한 것으로서 스태틱 함수(Static function) 의 경우에는 소문자로 시작하고, 스태틱 함수가 아닌 경우에는 대문자로 시작하여야 하며, 메크로인 경우에는 대문자로 구성하고 타입일 경우 접미사 ‘_t’를 붙여야 하는 등에 대한 코딩 규칙으로 ISO 규칙을 근간으로 기업의 업무에 적합한 규칙을 기반으로 한다.

* 문서화
여기서 문서화란 프로그램상에서의 문서를 의미한다. 표준화된 문서는 이해가 용이하며 작업자가 프로그램 작성시 빠질 수 도 있는 부분을 사전에 정의함으로써 애플리케이션에 대한 이해를 촉진하는데 있다. 헤더 파일(Header File)에 대한 설명이 있는지, 헤더 파일에 대한 설명이 전체 코드의 5% 이상이어야 하는 규칙은 프로그램에 대한 설명만으로 애플리케이션을 이해 할 수 있게 도와준다. 또한 C 파일이나 C 함수에 대한 설명이 적합하게 기록돼 있는지를 파악하는 것 또한 중요한 부분이라 하겠다.

* 일반 코딩 표준 또는 베스트 프랙티스(Best Practice)
코딩 라인 수, 함수 코드 라인 수, 매크로(macro) 코드 라인 수가 기준 선을 넘지 않도록 유도하는 것은 판독성을 향상시킬 수 있으므로 유지보수 및 변경이 용이하도록 할 수 있다. 그리고 선언만 하고 참조하지 않는 함수나 변수, 파일들을 파악하는 것은 애플리케이션에 대한 정확한 규모를 산정하거나 프로그램을 정련하는데 도움이 된다.

* 아키텍쳐(Architecture)
하나의 C 파일은 최소한 한 개의 헤더파일을 가져야 하며, 다른 헤더 파일을 포함하고 있는 지에 대한 분석과 헤더 파일이 다른 include파일에 포함돼 있는지, 또한 C 코드가 곧바로 데이터베이스에 접근하고 있는지에 대한 분석은 애플리케이션에 대한 아키텍쳐를 생각해 볼 수 있게 한다.

* 성능(performance)
애플리케이션에 대한 성능에 영향을 미칠 수 도 있는 부분을 분석하기 위한 것으로 시그널 함수를 사용하는 함수, 메모리를 사용하는 함수, 그리고 strcat 등을 사용하는 함수 목록을 살펴 봄으로써 이를 가늠할 수 있다.

메져 획득의 현실적인 어려움과 방안
애플리케이션을 새롭게 구축해야 하는 프로젝트에서는 고객의 요구사항을 분석하고 이에 대한 기능을 고려함으로써 애플리케이션에 대한 규모가 나오고 복잡성을 계산할 수 있다. 하지만 대부분의 기업들이 이미 애플리케이션을 운영하고 있으며, 새로운 애플리케이션이라 할 지라도 기존 애플리케이션과 직·간접적으로 연관이 있다. 따라서 기존의 애플리케이션을 분석하는 일은 무엇보다 먼저 수행돼야 할 부분중의 하나이다.
그러나 CMM활동이나 6시그마 활동을 하는 IT팀에서 먼저 애플리케이션에 대한 메져를 정의하고 이와 관련된 데이터를 수집하고자 하나 이들 데이터를 취득하는데 많은 어려움을 겪고 있다. 필요한 데이터를 획득하는 일이 각 작업자, 즉, 사람에 의해 이뤄지다 보니 이에 대한 불평과 불만이 증가 할 수 밖에 없다. 심지어 CMM레벨을 인증 받은 일부 SI업체의 실 개발자들이나 관리자들은 자신들이 혜택을 받은 것이 전혀 없으며 오히려 잔 업무만 늘었다고 하기도 한다.
따라서 애플리케이션에 대한 필요 정보를 획득하기 위해서 적절한 도구를 사용하는 것을 고려해야 한다. 목적에 따라 프로그래밍으로 도구를 개발할 수도 있고, 애플리케이션 분석 전문 도구를 도입할 수도 있다.

* 애플리케이션 분석
여러 언어로 구성돼 있는 애플리케이션으로부터 필요한 정보를 추출하기 위해서는 여러 요소가 필요하며 주요 언어별로 필요한 항목을 보면 다음과 같다.
이러한 정보를 저장소(리파지토리)에 구축한 후 이 데이터를 기준으로 필요한 정보를 추출해 필요한 사람들이 적시에 정보를 공급받을 수 있도록 해야 한다.

* 갱신 자동화
데이터를 유지하는데 실패하는 대부분의 경우는 변경된 부분에 대한 데이터를 갱신하는데 많은 노력이 들어가 지속적인 갱신이 이뤄지지 않는 경우다. 이 경우 정보 사용자들은 더 이상 데이터를 신뢰하지 않아 사용하지 않게 됨으로써 자연적으로 도태된다. 따라서 갱신에 대한 자동화 또는 최소한의 노력이 들어가게끔 프로세스화 하는 것은 애플리케이션 정보를 유지하는데 필수적인 사항이다.

* 애플리케이션 정보 제공
애플리케이션으로부터 추출한 데이터는 구축된 저장소(리파지토리)에서 다양한 정보를 필요한 사람에게 적절한 정보를 제공해 작업 및 의사결정에 도움이 되도록 지원할 수 있어야 한다.
의사결정자 또는 경영진에게는 애플리케이션 진화에 필요한 비용 및 일정, 그리고 필요한 기술과 인원에 대한 지표(Indicator)가 필요하고 팀장 및 관리자에게는 애플리케이션 규모나 복잡성, 그리고 표준화 등에 대한 메져가, 개발자들에게는 프로그램에 대한 프로파일과 표준화를 위배 하고 있는 부분에 대한 소스레벨의 자세한 정보가 필요하다.
이번호에서는 애플리케이션에 대한 메져와 그 필요성, 그리고 이들을 획득하기 위해 필요한 사항들에 대해 설명했다. 그러나 보다 중요한 것은 애플리케이션으로부터 추출한 어트리뷰터나 메져를 비즈니스 차원에서 분석하고 애플리케이션 개발이나 진화에 활용하는 것이다.
다음 호에서는 메져를 분석하고 활용하는 방안과 현재 IT부서에서 적극 활용중인 CMM이나 6시그마에 도움을 주는 사항에 대해 서술하고자 한다.