유지보수성 지수(MI)는 소프트웨어 품질 측정에서 가장 널리 사용되는 복합 지표 중 하나입니다. MI는 코드의 크기, 복잡성, 볼륨이라는 세 가지 구조적 속성을 하나의 수치 점수로 요약하여 코드 변경의 난이도를 예측합니다. 최신 언어의 경우 공식, 임계값, 도구가 잘 정립되어 있습니다. 하지만 COBOL의 경우 상황이 더 복잡하며, 대부분의 팀은 일반 공식을 조정 없이 그대로 사용하거나, 점수가 개발자의 실제 경험과 일치하지 않는다고 판단하여 정량적 측정을 아예 포기합니다.
두 접근 방식 모두 오해의 소지가 있는 결과를 초래합니다. COBOL의 구문적 맥락에서 구성 요소가 어떻게 작동하는지 이해하지 않고 표준 MI 공식을 COBOL에 적용하면 체계적으로 편향된 점수가 산출되어 고품질 프로그램이 미흡해 보이고 저품질 프로그램이 허용 가능한 수준으로 보이게 됩니다. 측정을 완전히 포기하면 현대화 결정에 필요한 정량적 기반이 부족해져 비즈니스 이해관계자에게 정당성을 입증하고 수천 개의 프로그램으로 구성된 포트폴리오에 대한 개선 작업의 우선순위를 정할 수 없게 됩니다.
COBOL 메트릭에 대한 완벽한 정보를 얻으세요
SMART TS XL COBOL 프로그램의 복잡성, 팬인(fan-in) 범위, JCL 종속성 깊이를 동시에 기준으로 순위를 매깁니다.
더 많은 정보올바른 접근 방식은 MI 공식이 COBOL에서 구체적으로 무엇을 측정하는지, 품질을 과소평가하거나 과대평가하는 부분은 어디인지, COBOL 특유의 사각지대를 보완하는 보조 지표는 무엇인지, 그리고 최신 언어 코드베이스에서 파생된 일반적인 벤치마크가 아닌 실제 포트폴리오에 맞춰 임계값을 조정하는 방법을 이해하는 것입니다. 이 가이드는 이 네 가지 사항을 모두 다루며, COBOL MI 프로그램을 구현하는 데 필요한 기술적 깊이와 현대화 결정을 내리는 데 필요한 실질적인 지침을 제공합니다.
기술적인 설명에 앞서 마지막으로 한 가지 짚고 넘어가겠습니다. 유지보수성 지수(Maintainability Index, MI)는 다양한 지표들을 종합하여 프로젝트의 여러 부분에 대한 상대적인 유지보수 부담을 전체적으로 보여주려고 합니다. 이러한 전체적인 관점은 COBOL 포트폴리오에 특히 유용합니다. 왜냐하면 어떤 단일 지표도 전체적인 상황을 완벽하게 포착할 수 없기 때문입니다. MI는 시작점이지, 전체 이야기는 아니지만, 시작하기에 가장 적합한 지점입니다.
COBOL에서 유지보수성 측정이 최신 언어보다 더 중요한 이유는 무엇일까요?
2년 이상 작성되었고, 테스트가 잘 되어 있으며, 작성팀이 직접 유지보수하는 자바 또는 파이썬 코드베이스의 유지보수성을 측정하는 것은 유용한 정보를 제공하지만, 시급한 문제는 아닙니다. 코드는 작성자가 읽기 쉽고, 로직은 문서화되어 있거나 테스트를 통해 도출할 수 있으며, 변경 비용은 팀의 숙련도에 따라 제한됩니다.
규제 산업 분야의 COBOL 포트폴리오는 세 가지 측면에서 차이가 있으며, 이로 인해 정량적 유지보수성 측정은 품질 관리 활동이 아닌 운영상의 필수 요소가 됩니다.
지식 격차가 존재합니다. 대부분의 COBOL 코드에는 공식적으로 문서화되지 않은 비즈니스 로직이 포함되어 있습니다. 수십 년 전에 작성된 배치 작업에는 아무도 기억하지 못하는 규칙이 인코딩되어 있습니다. 코드를 유창하게 읽고 변경 비용을 정확하게 예측할 수 있는 개발자들은 은퇴하고 있습니다. 남아 있는 개발자들은 포트폴리오의 일부에 대해서만 부분적으로 알고 있습니다. 정량적 지표가 없다면 변경 비용 예측은 전적으로 어떤 개발자에게 묻느냐에 따라 달라지며, 이러한 예측의 변동성이 너무 커서 프로젝트 계획을 신뢰할 수 없게 됩니다.
규모 문제가 있습니다. 일반적인 COBOL 포트폴리오는 수천 개의 프로그램으로 구성되어 있으며, 그중 상당수는 수년 동안 손대지 않은 상태입니다. 어떤 팀도 현대화 프로그램 시작 전에 수천 개의 프로그램을 수동으로 평가할 수는 없습니다. 전체 포트폴리오에 걸쳐 몇 시간 만에 자동으로 계산할 수 있는 지표는 수주에 걸친 수동 검토 작업을 대체합니다.
사업 타당성 분석 요건. 현대화 프로그램에는 투자 정당성 입증이 필요합니다. 수백만 달러 규모의 현대화 예산을 승인하는 경영진은 투자 타당성을 뒷받침하는 정량적 증거를 요구합니다. MI 점수, MI에서 도출된 기술 부채 비율, MI 임계값을 참조한 변경 비용 추정치는 비기술적 이해관계자에게도 제시할 수 있는 형태로 이러한 증거를 제공합니다.
MI 공식 및 COBOL 관련 구성 요소
유지보수성 지수를 계산하는 데 가장 일반적으로 사용되는 공식은 다음과 같습니다.
MI = 171 - 5.2 × ln(Halstead Volume) - 0.23 × (Cyclomatic Complexity) - 16.2 × ln(Lines of Code)대부분의 상용 도구에서 사용되는 마이크로소프트의 제한된 변형은 이를 0~100 척도로 매핑합니다.
MI (bounded) = max(0, (171 - 5.2 × ln(HV) - 0.23 × CC - 16.2 × ln(LOC)) × 100 / 171)각 구성 요소에는 COBOL과 관련된 특정 고려 사항이 있습니다.
COBOL 코드 줄 수
COBOL 소스 파일은 식별(IDENTIFICATION), 환경(ENVIRONMENT), 데이터(DATA), 프로시저(PROCEDURE)의 네 부분으로 구성됩니다. 식별 부분은 프로그램을 식별합니다. 환경 부분은 실행 환경을 설명합니다. 데이터 부분은 데이터 구조를 정의합니다. 실행 가능한 명령문은 오직 프로시저 부분에만 포함됩니다.
측정 관련 질문: LOC는 네 개의 디비전 전체에 걸쳐 모든 줄을 계산해야 할까요, 아니면 PROCEDURE DIVISION 문만 계산해야 할까요?
관리 정보(MI) 측면에서 모든 줄(데이터 선언 포함)을 계산하면 실행 복잡성 증가 없이 코드 줄 수(LOC)가 상당히 늘어납니다. 레코드 레이아웃을 정의하는 400줄의 DATA DIVISION과 100줄의 PROCEDURE DIVISION을 가진 COBOL 프로그램은 100줄의 DATA DIVISION과 400줄의 PROCEDURE DIVISION을 가진 프로그램과 유지보수 특성이 다르지만, 코드 줄 수만 고려하면 두 프로그램은 동일하게 취급됩니다.
모범 사례: COBOL MI 계산 시 전체 소스 코드 줄 수 대신 프로시저 디비전 문 개수(빈 줄, 주석 줄, 디비전/섹션/단락 헤더 제외)를 사용하십시오. 이렇게 하면 실행 파일의 복잡성과 더 밀접하게 관련된 LOC 값을 얻을 수 있습니다.
COPY 멤버 문제: COPY 문은 컴파일 시점에 외부 소스 멤버를 포함합니다. 200줄의 데이터 정의로 확장되는 COPY 문은 소스 파일에는 한 줄만 추가되지만 컴파일된 프로그램에는 200줄이 추가됩니다. 일부 도구는 논리적 LOC(복사 후 확장)를 계산하고, 다른 도구는 물리적 소스 코드 줄 수를 계산합니다. COPY 문을 많이 사용하는 프로그램의 경우 이 차이가 몇 배나 커질 수 있습니다.
주의: MI 도구가 물리적 소스 코드 라인 수를 계산하는 경우, COPY 명령어를 많이 사용하는 프로그램은 실제보다 더 작고 유지 관리하기 쉬운 것처럼 보일 수 있습니다. 도구에서 LOC 계산이 COPY 명령어 사용 전 또는 후에 이루어지는지 항상 확인하십시오.
COBOL에서의 순환 복잡도
순환 복잡도는 코드의 가독성과 유지보수성을 측정하는 코드 품질 지표로, 코드 내에서 독립적인 경로가 몇 개 존재하는지를 측정합니다. COBOL에서 독립적인 경로를 생성하는 결정 구조는 다음과 같습니다.
| COBOL 구성 | 순환적 복잡성 영향 |
|---|---|
IF ... END-IF | IF당 +1 |
IF ... ELSE ... END-IF | IF 조건문 하나당 +1점 (ELSE 조건문은 경로를 추가하지 않습니다) |
EVALUATE ... WHEN | WHEN 절당 +1 |
PERFORM UNTIL condition | UNTIL 조건당 +1 |
PERFORM VARYING ... WITH TEST BEFORE/AFTER | 변동당 +1 |
AT END READ에 관한 조항 | +1 |
ON EXCEPTION / NOT ON EXCEPTION | 예외 처리기당 +1개 |
ON OVERFLOW / NOT ON OVERFLOW | 오버플로 처리기당 +1개 |
ON SIZE ERROR | 크기 오류 처리기당 +1 |
88레벨 조건 이름에 대한 사각지대: COBOL의 88레벨 조건 이름은 IF 및 EVALUATE 문에 나타나는 논리 조건을 생성하지만, 실제로는 DATA DIVISION에 정의됩니다. 여러 결정 구조에서 참조되는 88레벨 조건이 20개 있는 프로그램은 PROCEDURE DIVISION의 문장 개수만으로는 설명할 수 없는 훨씬 더 복잡한 동작을 보입니다. 순환 복잡도는 결정 지점의 수를 계산하지만, 88레벨 이름과 이를 검증하는 논리 사이의 의미적 관계는 포착할 수 없습니다.
암묵적 복잡성을 통해 수행: PERFORM SECTION-A THRU SECTION-Z SECTION-A와 SECTION-Z 사이의 모든 단락을 실행합니다. 단락의 수와 그 안에 있는 결정 구조는 모두 PERFORM 문의 유효 복잡도에 포함되지만, 문 수준에서 계산된 CC는 이를 고려합니다. PERFORM THRU 중간에 무엇이 있든 상관없이 하나의 경로로 간주합니다.
COBOL의 할스테드 볼륨
할스테드 볼륨(Halstead Volume)은 연산자와 피연산자의 수를 기준으로 프로그램의 크기와 복잡성을 측정하는 지표입니다. COBOL에서는 다음과 같습니다.
연산자는 COBOL 동사와 키워드입니다. 예를 들어 MOVE, ADD, SUBTRACT, MULTIPLY, DIVIDE, COMPUTE, IF, PERFORM, READ, WRITE, OPEN, CLOSE, CALL, GO TO, EVALUATE, WHEN 등이 있습니다.
피연산자 는 데이터 이름, 리터럴 및 비유적 상수입니다. 여기에는 DATA DIVISION에 정의된 데이터 항목, 숫자 및 문자열 리터럴, 그리고 COBOL 비유적 상수(공백, 0, 높은 값, 낮은 값)가 포함됩니다.
장황함의 정도: COBOL은 동일한 논리를 표현할 때 현대 언어보다 훨씬 더 장황합니다. 자바 표현식은... total = quantity * unitPrice * (1 - discount) 네 개의 연산자와 네 개의 피연산자로 구성된 한 줄짜리 코드입니다. COBOL로 표현하면 다음과 같습니다.
코볼
COMPUTE WS-TOTAL = WS-QUANTITY * WS-UNIT-PRICE
* (1 - WS-DISCOUNT)연산자와 피연산자 측면에서는 거의 동일하지만, 자바에서는 세 줄로 계산할 수 있는 복잡한 연산을 COBOL에서는 다섯 줄 이상 필요로 할 수 있습니다. 이는 표현식 체이닝이 불가능하고 중간 작업 저장 필드를 사용해야 하기 때문입니다. 따라서 COBOL이 동일한 계산을 더 많은 언어 토큰으로 표현하기 때문에 할스테드 볼륨(Halstead Volume)은 동등한 자바보다 더 높아집니다.
실질적인 결과는 다음과 같습니다. COBOL 프로그램은 동일한 논리를 사용하는 현대 언어 프로그램보다 할스테드 볼륨(Halstead Volume)이 더 높습니다. 할스테드 볼륨이 높을수록 유지 관리 효율(MI)이 낮아집니다. 따라서 COBOL 프로그램은 유지 관리가 더 어려워서가 아니라 구문이 더 장황하기 때문에 동일한 복잡성을 가진 현대 언어 프로그램보다 MI 점수가 체계적으로 낮게 나옵니다.
COBOL에서 표준 MI의 한계점: 네 가지 맹점
표준 MI 공식은 정확하게 계산하더라도 실제 변경 비용에 상당한 영향을 미치는 COBOL 유지보수성의 네 가지 측면을 간과합니다.
1. 멤버 커플링 복사
300개의 프로그램에 포함된 COBOL 카피북은 유지 관리 종속성으로, 해당 카피북에 변경 사항이 발생하면 300개의 프로그램 모두에 영향을 미칩니다. 이러한 연결은 MI 공식의 어떤 구성 요소에도 나타나지 않습니다. 20개의 카피북을 포함하는 프로그램은 MI에서 카피북이 없는 프로그램과 동일하게 처리되는 300개의 암묵적 종속성을 갖습니다.
보조 지표: 복사 멤버 종속성 개수(Copy Member Dependency Count), 프로그램의 DATA DIVISION에 있는 고유한 COPY 문의 개수입니다. COPY 결합도가 높은 프로그램은 변경 전에 영향 분석을 통해 동일한 카피북 정의를 공유하는 다른 프로그램을 파악해야 합니다.
2. 팬인(카운트별 호출)
150개의 다른 프로그램에서 호출되는 COBOL 서브프로그램은 MI 점수와 관계없이 변경 위험이 높은 대상입니다. 150개의 프로그램에서 호출되는 유지보수성이 높은 서브프로그램(MI = 85)은 아무도 호출하지 않는 유지보수성이 낮은 유틸리티(MI = 45)보다 안전하게 변경하기가 더 어렵습니다. MI 공식은 프로그램의 사용 빈도를 고려하지 않습니다.
보조 지표: 팬인(Fan-In)은 CALL 또는 동적 디스패치를 통해 특정 프로그램을 호출하는 서로 다른 프로그램의 수를 나타냅니다. 팬인은 하위 프로그램의 내부 복잡성과 관계없이 하위 프로그램의 변경 위험을 결정하는 주요 요인입니다.
3. JCL 의존성 깊이
15개의 하위 종속 작업(해당 프로그램 이후에 실행되고 출력에 의존하는 작업)을 가진 JCL 작업에 의해 호출되는 COBOL 프로그램은 MI(구성 정보)의 범위를 완전히 벗어나는 운영상의 위험을 내포하고 있습니다. MI=55인 독립 실행형 프로그램은 복잡한 배치 종속성 체인의 중심에 있는 MI=80인 프로그램보다 수정 위험이 적습니다.
보조 지표: JCL 종속성 깊이, JCL 작업 네트워크에서 하위 종속성 체인의 깊이. JCL 종속성 깊이가 높은 프로그램은 내부 MI 점수와 관계없이 모든 변경 사항에 대해 더 넓은 테스트 범위가 필요합니다.
4. 사멸 코드 인플레이션
사용되지 않는 단락과 섹션, 즉 정의되어 있지만 어떤 실행 경로에서도 호출되지 않는 COBOL 코드는 LOC(라인 수)와 Halstead Volume(할스테드 볼륨)을 증가시키지만, 실제 코드의 유지 관리 부담에는 영향을 미치지 않습니다. 사용되지 않는 코드가 600줄이고 실제 코드가 200줄인 프로그램은 사용되지 않는 코드가 변경 비용과 무관하더라도 MI(관리 정보)에서 해당 코드 때문에 불이익을 받게 됩니다.
보조 지표: 데드 코드 비율(Dead Code Percentage)은 프로덕션 실행 경로에서 도달할 수 없는 PROCEDURE DIVISION 문의 비율입니다. 데드 코드 비율이 높을수록 MI로 계산된 LOC(라인 오브 코드)와 Halstead Volume(할스테드 볼륨)이 상당히 부풀려졌음을 나타냅니다.
완벽한 COBOL 메트릭스 제품군
COBOL 유지보수성을 완벽하게 측정할 수 있는 단일 지표는 없습니다. 다음 도구 모음을 함께 사용하면 전체적인 상황을 파악할 수 있습니다.
| 메트릭 | 무엇을 측정하는가 | COBOL 관련 참고 사항 | 1 차 사용 |
|---|---|---|---|
| 유지 보수성 지수 | 전반적인 유지보수 용이성 (복합재료) | 절차 부서 진술에 적용하고 사본 처리를 확인합니다. | 기본 품질 점수; 포트폴리오 순위 |
| 순환적 복잡성 | 독립적인 실행 경로의 수 | 평가 시점, 수행 시점, 종료 시점, 예외 발생 시를 포함합니다. | 프로그램별 변경 작업량; 테스트 케이스 수 추정치 |
| 할스테드 볼륨 | 계산 부하(연산자 + 피연산자) | 동등한 수준의 최신 언어 프로그램보다 더 높은 가치를 기대하십시오. | MI의 일부; COBOL 포트폴리오 내 프로그램 간 비교 |
| 복사 회원 수 | 공유 정의를 통한 의존성 결합 | COPY 회원 수가 15명 이상인 프로그램은 변경 사항을 적용하기 전에 영향 분석을 수행해야 합니다. | 변경 위험 분류 |
| 팬인(콜드바이) | 이 이름을 사용하는 프로그램이 몇 개나 될까요? | 하위 프로그램의 변경 위험을 유발하는 주요 요인 | 마이그레이션 순서; 변경 권한 임계값 |
| 데드 코드 % | 접근할 수 없는 절차 코드 비율 | 제외되지 않은 경우 LOC/HV를 확대하고, 변환 범위에서 제외합니다. | 현대화를 위한 범위 축소 |
| JCL 종속성 깊이 | 다운스트림 배치 작업 체인 깊이 | COBOL 소스 코드만으로는 계산할 수 없으며, JCL 분석이 필요합니다. | 운영 변경 위험; 테스트 범위 |
| 중첩된 PERFORM 깊이 | PERFORM 호출의 최대 중첩 수준 | 깊은 중첩은 CC로 포착되지 않는 구조적 복잡성을 나타냅니다. | 리팩토링 우선순위 |
COBOL 임계값 보정
표준 MI 임계값은 최신 언어 코드베이스에서 파생되었으며 COBOL에 직접 적용되지 않습니다. 아래 표는 표준 임계값과 COBOL에 적합한 해당 임계값을 비교하고 조정 근거를 설명합니다.
| 점수 범위 | 표준 해석 | COBOL 해석 | 이론적 해석 |
|---|---|---|---|
| 85-100 | 유지보수성이 매우 높음 | 유지보수성이 매우 우수함(일관성 우수함) | 이 범위에서 가장 우수한 COBOL 프로그램 점수를 받았으며, 구조가 깔끔하고 적절한 규모를 가지고 있습니다. |
| 65-84 | 적당히 유지보수 가능 | 유지보수성은 중간 정도이며, COPY 결합 및 팬인 검토가 필요합니다. | 표준 임계값은 유효하지만, 여기서는 보조 지표가 더 중요합니다. |
| 50-64 | 상태가 좋지 않아 리팩토링이 필요합니다. | 한계점, 맥락에서 평가 | 잘 구성된 COBOL 프로그램조차도 장황함 때문에 높은 점수를 받는 경우가 많습니다. 구문 오류와 실제 문제를 구분하려면 CC와 팬인(fan-in) 기능을 활용하세요. |
| 25-49 | 매우 가난한 | 상태가 좋지 않거나, CC 수치가 높거나 LOC가 과도할 가능성이 있습니다. | 이 범위의 프로그램은 단순히 COBOL의 장황함뿐만 아니라 구조적인 문제를 확실하게 나타냅니다. |
| 0-24 | 중요하고 대규모의 리팩토링 | 매우 중요하며, 시정 또는 폐기 시 최우선 순위입니다. | 표준적인 해석과 일치함 |
핵심 보정 지침: 프로그램별 임계값을 설정하기 전에 전체 COBOL 포트폴리오에 대해 MI를 실행하십시오. 포트폴리오 중앙값과 사분위 범위(IQR)를 계산하십시오. "주의 필요" 임계값은 자체 포트폴리오의 25번째 백분위수, 즉 특정 코드베이스의 하위 25%에 해당하는 프로그램으로 설정하십시오. Java 프로그램에서 도출된 임계값보다 낮은 점수를 받은 프로그램을 기준으로 설정하지 마십시오. 이 접근 방식은 자체적으로 보정되며 COBOL의 체계적인 장황화 효과를 고려합니다.
현대화 결정을 위한 MI 활용
MI 점수는 구체적인 운영 의사결정에 도움이 될 때 가장 가치가 높아집니다. 주요 활용 사례는 다음과 같습니다.
마이그레이션 단계 순서. MI 점수가 높은 프로그램(유지 관리가 잘 되어 있고 복잡성이 낮은 프로그램)은 초기 마이그레이션 단계에 가장 적합합니다. 이러한 프로그램은 검증이 용이하고, 문서화되지 않은 예외 상황이 발생할 가능성이 적으며, 마이그레이션된 환경에서 예상치 못한 동작이 발생할 위험도 낮습니다. MI 점수가 낮은 프로그램은 팀의 경험과 자신감이 축적되고 비즈니스 로직 추출이 완료된 후, 후기 단계에서 마이그레이션하는 것이 좋습니다.
유지보수 우선순위. MI가 25번째 백분위수 미만이면서 팬인(많은 프로그램에서 호출됨)이 높거나 JCL 의존성 깊이가 높은 프로그램은 가장 위험한 조합을 나타냅니다. 즉, 다른 많은 프로그램이 의존하는 구조적으로 복잡한 프로그램입니다. 이러한 프로그램은 변경 관련 결함이 발생할 가능성이 가장 높고, 결함이 발생했을 때 수정하는 데 가장 많은 비용이 소요됩니다. 따라서 기술 부채 감소 프로그램의 최우선 대상이 되어야 합니다.
자체 개발 vs. 구매 결정. COBOL 프로그램을 장기적으로 유지할지, 아니면 SaaS나 최신 솔루션으로 교체할지 평가할 때, MI 점수와 변경 비용 이력은 자체 개발 vs. 구매를 결정하는 데 필요한 정량적 근거를 제공합니다. MI 점수가 30점이고 지난 3년간 15번 수정되었으며, 각 수정 작업에 예상보다 훨씬 오랜 시간이 소요된 프로그램의 경우, 유지보수 비용을 문서화하여 교체 비용과 비교할 수 있습니다.
변경 승인 임계값. 일부 조직에서는 MI 점수를 사용하여 필요한 변경 승인 수준을 결정합니다. 특정 MI 임계값 미만의 프로그램은 운영 환경에 배포하기 전에 더욱 엄격한 검토, 독립적인 테스트 및 추가 승인을 받아야 합니다. 이를 통해 모든 변경 사항을 수동으로 평가할 필요 없이 품질을 고려한 변경 관리 프로세스를 구축할 수 있습니다.
MI가 할 수 없는 한 가지는 변화가 사업에 미치는 영향을 예측하는 것입니다. 규제 자본 계산을 수행하는 MI 점수 85점의 프로그램은 중요도가 낮은 보고 기능을 수행하는 MI 점수 40점의 프로그램만큼이나 많은 테스트와 검증이 필요합니다. MI는 변화에 필요한 노력만을 측정할 뿐, 변화의 결과를 측정하는 것은 아닙니다. 완전한 위험 평가를 위해서는 두 가지 측면 모두 필요합니다.
방법 SMART TS XL COBOL 유지보수성 지표를 수립하고 추적합니다.
단일 COBOL 프로그램에 대한 MI(관리 정보) 계산은 간단합니다. 하지만 COPY 확장을 고려하고, 사용되지 않는 코드를 식별하고, 기존 MI에서 누락된 추가 메트릭을 보완하는 등 수천 개의 프로그램으로 구성된 포트폴리오에 대해 정확하게 MI를 계산하려면 대규모 자동화 분석이 필요합니다.
SMART TS XL의 정적 코드 분석 이 가이드에 설명된 모든 COBOL 메트릭 세트를 전체 포트폴리오에 걸쳐 동시에 계산합니다. MI는 전체 소스 라인 수가 아닌 PROCEDURE DIVISION 문 개수를 사용하여 계산되며, 공유 데이터 정의가 올바르게 할당되도록 분석 전에 COPY 확장이 수행됩니다. 순환 복잡도는 IF 문뿐만 아니라 EVALUATE WHEN 절, PERFORM UNTIL 조건 및 예외 처리기 분기도 고려합니다. 할스테드 볼륨은 PROCEDURE DIVISION의 COBOL 동사와 데이터 피연산자를 기반으로 계산됩니다.
십자가, SMART TS XL MI는 기존 공식에서 누락된 지표를 보완합니다. 애플리케이션 종속성 매핑 포트폴리오 내 모든 프로그램에 대한 팬인 값(호출 횟수)을 생성하여 MI 점수와 관계없이 고위험 프로그램을 식별합니다. JCL 확장 이 기능은 모든 프로그램에 대한 JCL 종속성 심층 분석을 제공하여 COBOL 수준의 MI 분석을 JCL 분석만이 드러낼 수 있는 운영 위험 상황과 연결합니다.
영향 분석 기능 에서 제공하는 데드 코드 식별 기능은 인바운드 실행 경로가 없는 단락 및 섹션을 표시하여 MI 계산에서 데드 코드를 제외하고 프로그램의 낮은 MI 점수가 실제 복잡성을 반영하는지 아니면 과장된 LOC를 반영하는지 판단하는 데드 코드 비율 지표를 제공합니다.
엔터프라이즈 검색 기능을 통해 전체 메트릭 데이터 세트를 쿼리할 수 있습니다. 예를 들어, MI가 40 미만이고 팬인(fan-in)이 20 이상인 모든 프로그램을 JCL 종속성 깊이 순으로 정렬하여 찾고, 포트폴리오에서 최우선 순위의 개선 대상을 수백만 줄의 COBOL 코드 전체에서 단 한 번의 쿼리로 검색할 수 있습니다. 이러한 쿼리 가능한 메트릭 인벤토리는 위에서 설명한 유지 관리 우선순위 지정, 마이그레이션 순서 지정 및 변경 승인 애플리케이션의 기반이 됩니다.
마지막으로, 시간이 지남에 따라 추적되고 각 주요 변경 주기 후에 다시 계산되는 MI는 프로그램이 개선되고 있는지 또는 악화되고 있는지를 보여줍니다. SMART TS XL이 분석은 캐시된 스냅샷이 아닌 최신 소스 코드를 기반으로 실행되므로, 측정 지표가 특정 시점의 평가가 아닌 분석 시점의 코드베이스 실제 상태를 반영하여 정확성을 보장합니다.
언어에 맞는 측정 기준
유지보수성 지수(Maintainability Index, MI)는 COBOL 포트폴리오에 있어 유효하고 가치 있는 지표이지만, COBOL의 구문적 특성이 구성 요소와 어떻게 상호 작용하는지에 대한 이해를 바탕으로 적용할 때만 그 진가를 발휘합니다. COBOL 프로그램에 일반적인 임계값을 적용하면 오해의 소지가 있는 결과가 나옵니다. MI가 간과하는 COPY 결합도, 팬인(fan-in), JCL 의존성 깊이, 데드 코드 비율 등의 지표를 MI에 보완적으로 활용하면 개발자들이 COBOL 포트폴리오에서 실제로 경험하는 상황을 더 정확하게 파악할 수 있습니다.
이러한 지표를 효과적으로 활용하는 조직은 지표를 프로그램 품질에 대한 최종 판단이 아니라 정보에 기반한 대화를 위한 출발점으로 여기는 조직입니다. MI 점수는 하나의 신호입니다. 이 신호는 주의 깊게 살펴볼 가치가 있으며, 변경 비용이 많이 들고 수정 위험이 높은 프로그램, 그리고 현대화 시작 전에 해결해야 할 중요한 문제를 일관되게 알려줍니다. 하지만 MI가 할 수 없는 것은 코드를 읽는 개발자의 판단을 대체하거나, 단일 지표로는 포착할 수 없는 의존성과 비즈니스 로직을 드러내는 구조적 분석을 대신하는 것입니다.
