코드 품질은 측정 가능합니다. 이 말은 당연하게 들리지만, 소프트웨어 제품을 구매하기 전 CTO가 묻는 질문이나 리팩토링 프로그램을 시작하기 전 기술 리더가 묻는 질문, 즉 "코드가 좋은지 어떻게 알 수 있나요?"에 답하려고 하면 이야기가 달라집니다. "잘 작동하니까"도, "팀에서 검토했으니까"도 답이 될 수 없습니다. 정답은 일관되게 적용되는 객관적인 측정 지표에 있습니다. 함수별 순환 복잡도, 모듈별 유지보수성 지수, 1,000줄당 결함 밀도, 컴포넌트별 테스트 커버리지, 스프린트별 파일 코드 변경률 등이 그 예입니다. 이러한 지표들은 모두 수치로 나타낼 수 있으며, 추세를 분석하고 벤치마킹하여 개선 방안을 마련할 수 있습니다.
문제는 코드 품질 지표들이 서로 대체 불가능하고 보편적으로 해석될 수 없다는 점입니다. COBOL 프로그램에서 높은 유지보수성 지수가 파이썬 스크립트에서 같은 점수를 받는 것과는 의미가 다릅니다. 순환 복잡도 15는 잘 테스트된 상태 머신에서는 허용 가능한 수준이지만, 유효성 검사 함수에서는 심각한 문제로 간주됩니다. 결함 밀도가 KLOC당 2개 버그인 것은 시스템 프로그래밍에서는 훌륭한 수준이지만, 안전에 중요한 임베디드 애플리케이션에서는 매우 위험한 수준입니다. 지표를 유용하게 활용하려면 각 지표가 무엇을 측정하는지, 무엇이 지표를 높이거나 낮추는지, 그리고 어떤 임계값이 적절한지 이해해야 합니다. 이 글에서는 바로 이러한 내용을 다룹니다.
코드 품질이란 무엇인가요?
코드 품질이란 소스 코드가 정확성, 유지보수성, 가독성, 효율성, 보안성, 테스트 용이성 등 측정 가능한 속성들을 얼마나 잘 충족하는지를 나타내는 정도입니다. 어떤 단일 속성만으로 품질을 정의할 수는 없습니다. 코드는 제대로 실행되지만 가독성이 떨어지면 개발자가 이해할 수 없기 때문에 안전하게 수정할 수 없어 변경될 때마다 품질이 저하됩니다. 가독성은 좋지만 테스트되지 않은 코드는 숨겨진 결함을 가지고 있습니다. 테스트는 되었지만 구조적으로 복잡한 코드는 규모가 커질수록 결함이 더 많이 발생합니다. 복잡성이 커질수록 특정 변경으로 인해 예상치 못한 문제가 발생할 확률이 높아지기 때문입니다.
ISO/IEC 25010 표준의 공식적인 정의에 따르면 소프트웨어 품질의 여덟 가지 특성은 기능 적합성, 성능 효율성, 호환성, 사용성, 신뢰성, 보안, 유지보수성, 이식성입니다. 소스 코드의 경우, 런타임 동작이 아닌 코드 자체에서 직접 측정할 수 있는 특성은 유지보수성, 신뢰성(결함 및 복잡성 지표로 근사화), 보안(정적 분석을 통해), 기능 적합성(테스트 커버리지를 통해)입니다. 나머지 특성은 측정을 위해 코드 실행이 필요합니다. 따라서 코드 품질 지표는 소프트웨어 품질의 전체가 아닌, 정의되고 중요한 부분 집합을 다룹니다.
코드 품질이 중요한 이유
기술팀은 코드 품질이 왜 중요한지 잘 알고 있습니다. 하지만 비즈니스 이해관계자나 내부적으로 코드 품질의 중요성을 설득해야 하는 팀에게는 비용과 시간이라는 측면에서 그 중요성이 더욱 부각됩니다. 맥킨지와 IT 소프트웨어 품질 컨소시엄(CISQ)의 연구에 따르면 개발자들은 새로운 기능을 개발하는 대신 기존의 기술 부채를 해결하는 데 30~40%의 시간을 소비하는 것으로 나타났습니다. 코드 품질이 낮으면 기술 부채가 누적됩니다. 초기에 발견되지 않은 결함, 불필요하게 복잡한 기능, 별도로 유지 관리해야 하는 중복된 로직 블록 하나하나가 다음 변경 작업의 비용을 증가시킵니다. 반면 높은 코드 품질은 시스템 수명 주기 전반에 걸쳐 이러한 비용을 지속적으로 줄여줍니다.
코드 품질 측정 지표: 완벽 참조
아래 표는 코드 품질 측정의 모든 주요 범주를 포괄하는 지표들을 제시합니다. 각 지표에 대해 정의, 측정 방법, 허용 범위 및 해석 방법을 설명합니다. 아래 표의 임계값은 업계에서 널리 인용되는 벤치마크를 반영한 것이며, 안전이 중요한 환경이나 규제가 엄격한 환경에서 작업하는 팀은 더 엄격한 임계값을 적용해야 합니다.
복잡성 측정항목
순환적 복잡성 함수 또는 메서드를 통과하는 선형적으로 독립적인 경로의 수를 측정합니다. 1976년 토마스 맥케이브가 도입했으며 현재까지 가장 널리 사용되는 복잡성 측정 지표입니다. 이 공식은 결정 지점을 계산합니다. if, else if, switch 경우, 루프 조건, catch 블록과 조건 연산자를 포함하면 1이 더해집니다. 분기가 없는 함수의 순환 복잡도는 1입니다.
| 순환적 복잡성 | 해석 |
|---|---|
| 1-5 | 간단하고 테스트하기 쉽습니다. |
| 6-10 | 적당하고 관리 가능한 수준 |
| 11-20 | 복잡해지면 테스트가 어려워집니다. |
| 21-50 | 위험도가 매우 높으므로 리팩토링을 권장합니다. |
| 50+ | 검증 불가능하며, 결함이 있을 가능성이 매우 높음 |
높은 순환 복잡도는 결함 밀도와 강한 상관관계를 보입니다. IEEE 소프트웨어 엔지니어링 트랜잭션에 발표된 연구에 따르면 순환 복잡도가 10을 넘는 함수는 더 간단한 함수보다 결함 발생률이 현저히 높습니다. 레거시 코드베이스에서 순환 복잡도를 분석할 때 중요한 것은 전체 구조를 리팩토링하지 않고 수년간 유지보수 과정에서 누적된 결정 로직을 가진 함수를 찾는 것입니다.
NPath 복잡도는 중첩된 조건문과 반복문을 포함하여 함수를 통과하는 고유한 실행 경로의 수를 계산합니다. 순환 복잡도가 분기를 선형적으로 계산하는 반면, NPath 복잡도는 분기를 곱합니다. 예를 들어, 세 개의 순차적인 if-else 블록을 가진 함수의 순환 복잡도는 4이지만, 각 조건이 독립적으로 참 또는 거짓일 수 있으므로 NPath 복잡도는 8입니다. NPath 복잡도는 중첩이 많아질수록 기하급수적으로 증가합니다. 200을 넘는 값은 어떤 팀도 현실적으로 작성할 수 있는 것보다 훨씬 더 많은 테스트 케이스가 필요한 함수임을 나타냅니다.
인지적 복잡성 SonarSource에서 도입한 이 지표는 코드에 포함된 경로의 개수가 아니라 코드를 이해하기 얼마나 어려운지를 측정합니다. 선형 분기보다 중첩된 구조에 더 큰 불이익을 줍니다. if 내부 while 다른 내부 if 연속 3개보다 높은 점수 if 동일한 순환 복잡도를 갖는 문장들. 인지 복잡도는 개발자가 코드를 읽을 때 실제로 겪는 어려움과 더 잘 부합합니다. 메서드당 인지 복잡도가 15를 넘으면 일반적으로 검토 대상으로 표시되며, 25를 넘으면 대부분의 개발자가 실제로 이해하기 어려워하는 함수를 나타냅니다.
할스테드 메트릭스는 소스 코드의 네 가지 요소(고유 연산자 수(n1), 고유 피연산자 수(n2), 전체 연산자 수(N1), 전체 피연산자 수(N2))로부터 일련의 측정값을 도출합니다. 이러한 요소들을 기반으로 할스테드는 다음과 같은 지표들을 계산합니다.
- 음량 (N × log2(n)): 정보 콘텐츠 구현 크기
- 어려움 (n1/2 × N2/n2): 코드를 작성하거나 이해하는 데 얼마나 어려운지를 나타내는 추정치
- 노력 (용량 × 난이도): 코드를 구현하거나 이해하는 데 필요한 총 정신적 노력 추정치
할스테드 메트릭은 유사한 순환 복잡도를 가진 함수들을 비교하여 어느 함수가 이해하기 더 어려운지 판단하는 데 특히 유용합니다. 명확하게 명명된 변수에 대해 10개의 분기를 가진 함수는 계산된 인덱스와 단일 문자 식별자에 대해 10개의 분기를 가진 함수보다 할스테드 난이도가 낮습니다.
유지보수성 지표
유지보수성 지수(Maintainability Index) 는 원래 Paul Oman과 Jack Hagemeister가 개발했으며, 이후 Microsoft Visual Studio에서 표준 유지보수성 측정 기준으로 채택되었습니다. 이 지수는 Halstead 볼륨, 순환 복잡도, 코드 라인 수를 하나의 점수로 결합합니다.
Visual Studio의 수식은 0에서 100 사이의 점수를 생성합니다.
| 유지 보수성 지수 | 평점 |
|---|---|
| 20-100 | 유지보수 가능(녹색) |
| 10-19 | 유지보수 필요성이 중간 정도임 (노란색) |
| 0-9 | 유지 관리가 어려움 (빨간색) |
유지보수성 지수는 요약 통계입니다. 세부적인 모듈 간 비교보다는, 유지보수성이 낮은 파일이나 모듈 등 이상치를 식별하는 데 가장 유용합니다. 파이썬에서는 radon 이 라이브러리는 유지보수성 지수를 직접 계산합니다. Visual Studio에서는 코드 메트릭 창에 표시됩니다. 정적 코드 분석 플랫폼에서 유지보수성 지수는 일반적으로 순환 복잡도 및 코드 라인 수와 함께 표준 출력 지표 중 하나입니다.
LOC(Lines of Code)와 KLOC(Keep Itful Code)는 코드베이스의 크기를 줄 수 또는 수천 줄 단위로 측정합니다. LOC 자체만으로는 코드 품질에 대한 정보를 얻을 수 없지만, 다른 지표들을 위한 필수적인 기준점을 제공합니다. 결함 밀도는 KLOC당 버그 수, 주석 밀도는 LOC당 주석 수, 테스트 밀도는 LOC당 테스트 어설션 수로 나타냅니다. 또한 LOC는 복잡성의 비용을 나타냅니다. 순환 복잡도가 20인 500줄짜리 함수는 동일한 복잡도를 가진 50줄짜리 함수보다 훨씬 더 큰 문제입니다.
코드 변경률(Code Churn) 은 시간이 지남에 따라 코드가 변경되는 속도를 나타내며, 단위 시간당 파일당 추가된 코드 줄 수, 삭제된 코드 줄 수, 수정된 코드 줄 수를 합산하여 측정합니다. 코드 변경률이 높다는 것은 불안정성을 의미합니다. 자주 변경되는 코드는 처음부터 올바르지 않았던 설계, 불안정한 요구 사항 또는 지속적인 패치가 필요한 버그에 대한 대응일 수 있습니다. 마이크로소프트의 연구에 따르면 코드 변경률이 상위 10%에 해당하는 파일은 변경률이 낮은 파일보다 결함이 5배 더 많았습니다. 코드 변경률과 결함률을 함께 추적하면 잦은 변경이 품질을 향상시키는지 아니면 새로운 문제를 야기하는지 파악할 수 있습니다.
코드 커버리지 메트릭
단위 테스트 커버리지 는 코드베이스에서 단위 테스트에 의해 실행되는 코드 라인, 분기 또는 조건의 비율을 나타냅니다. 가장 의미 있는 형태는 분기 커버리지입니다. 즉, 코드의 각 결정이 참과 거짓 결과 모두에서 적어도 하나의 테스트를 통해 실행될 수 있는지 여부를 보여줍니다. 라인 커버리지는 조작하기 쉽습니다. 아무것도 검증하지 않고 모든 라인을 실행하는 테스트는 100% 라인 커버리지를 달성하고 아무것도 잡아내지 못합니다.
단위 테스트 커버리지에 대한 업계 표준:
- 50% 미만: 부적절함, 대부분의 결함은 검사에서 발견되지 않음
- 50-75%: 보통 수준, 주요 경로 포함, 예외적인 경우는 누락될 가능성 높음
- 75~90%: 대부분의 애플리케이션 코드에 적합
- 90% 이상: 안전이 매우 중요하거나 신뢰성이 높은 시스템에 적합합니다.
안전 필수 애플리케이션의 코드 커버리지는 더욱 엄격한 기준을 따릅니다. 항공 소프트웨어에 대한 DO-178C 및 기능 안전에 대한 IEC 61508은 표준 단위 테스트에서 달성하는 수준을 뛰어넘는 커버리지 요구 사항(최고 중요도 수준에 대한 MC/DC 커버리지)을 명시하고 있습니다. 안전 필수 애플리케이션의 코드 품질을 향상시키려면 조건/결정 커버리지를 추적하고 인증 기관에서 요구하는 공식적인 증거를 생성할 수 있는 커버리지 도구가 필요합니다.
테스트 밀도는 프로덕션 코드의 크기에 대한 테스트 어설션의 수를 측정하여 코드 커버리지를 보완하는 지표입니다. 테스트 밀도가 낮지만 코드 커버리지가 높은 경우, 의미 있는 동작 검증 없이 코드만 실행하는 테스트가 있을 수 있습니다. 반대로 테스트 밀도가 높지만 코드 커버리지가 낮은 경우, 코드베이스의 특정 부분에 테스트가 집중되어 있을 수 있습니다.
결함 지표
버그 밀도 (또는 결함 밀도)는 코드 1,000줄(KLOC)당 확인된 결함 수를 나타냅니다. 이는 코드 정확성을 측정하는 가장 직접적인 정량적 지표입니다. CISQ의 업계 벤치마크에 따르면 상용 기성 소프트웨어는 테스트 전 KLOC당 평균 15~50개의 결함이 있는 것으로 나타났습니다. 테스트 및 출시 후에는 고품질 상용 소프트웨어의 경우 일반적으로 KLOC당 1개 미만의 결함이 발생합니다.
정적 분석 결과 테스트 또는 실제 사용을 통해 결함이 확인되기 전에 대략적인 결함 밀도를 파악할 수 있습니다. SonarQube, Checkmarx와 같은 도구를 사용할 수 있습니다. SMART TS XL 알려진 결함 및 취약점 유형과 관련된 패턴을 파악하기 위해 코드베이스를 분석하고, 심각도별로 분류된 잠재적 문제 수를 산출합니다. 심각한 결함 및 차단 결함 발견 건수를 코드 라인 수(LOC)로 나눈 비율은 코드가 테스트 단계에 도달하기 전에 코드 품질을 조기에 파악할 수 있는 지표를 제공합니다.
코드 스멜 밀도는 코드 한 줄당 안티 패턴, 중복 코드, 지나치게 긴 함수, 과도한 클래스 결합, 기능 욕심, 갓 오브젝트 등의 존재 여부를 측정합니다. 코드 스멜은 당장 오류를 발생시키지는 않지만, 향후 결함 발생 및 유지보수 비용 증가의 원인이 됩니다. 코드 스멜 밀도가 높은 코드베이스는 누적된 구조적 문제점을 해결해야 하므로 향후 모든 변경 작업의 비용이 증가합니다.
가독성 및 스타일 지표
댓글 밀도 주석 줄 수와 코드 줄 수의 비율입니다. 최적의 범위는 언어와 팀의 관례에 따라 다르지만 일반적으로 10~30% 사이입니다. 10% 미만이면 문서화가 불충분한 코드를 나타낼 수 있으며, 50% 이상이면 코드가 너무 복잡하여 명확하지 않은 논리에 대한 광범위한 설명이 필요함을 나타낼 수 있습니다. 주석의 양보다 질이 더 중요합니다. 코드가 무엇을 하는지 다시 설명하는 주석이 더 효과적입니다.// increment i by 1)는 아무런 가치를 더하지 않지만, 특정 알고리즘이 선택된 이유를 설명하는 주석은 상당한 가치를 더합니다.
명명 규칙 준수는 프로젝트의 명명 규칙을 따르는 식별자(변수, 함수, 클래스)의 비율을 측정합니다. 자동화 도구는 린팅 설정의 일부로 명명 규칙을 강제할 수 있습니다. 일관된 명명은 개발자가 이름만으로 식별자의 용도를 예측할 수 있게 해주므로, 익숙하지 않은 코드를 읽을 때 발생하는 인지 부하를 줄여주기 때문에 가독성을 크게 향상시키는 요소 중 하나입니다.
코드 중복률은 코드베이스에서 여러 위치에 걸쳐 중복된 코드의 비율을 측정합니다. 일반적으로 중복률이 5%를 넘으면 문제가 있는 것으로 간주됩니다. 중복된 코드는 유지보수 노력을 증가시킵니다. 중복된 로직의 버그는 모든 복사본에서 찾아 수정해야 하며, 동작 변경 사항은 모든 복사본에 일관되게 적용해야 합니다. 또한 중복은 코드베이스의 실제 크기를 가립니다. 100,000만 줄처럼 보이는 시스템에도 40,000만 줄의 고유한 로직과 60,000만 줄의 복사본이 포함되어 있을 수 있습니다.
보안 및 기술 부채 지표
SonarQube는 기술 부채 비율을 코드베이스의 예상 개발 비용 대비 예상 수정 비용의 비율로 정의합니다. 기술 부채 비율이 5% 미만이면 깔끔한 코드베이스로 간주되며, 20%를 초과하면 상당한 누적 부채가 발생하여 향후 개발 속도를 현저히 늦출 수 있음을 나타냅니다.
보안 취약점 밀도는 KLOC당 보안 검토가 필요한 코드 패턴(확인된 취약점이 아닌)인 보안 취약점의 수를 계산합니다. 예를 들어 매개변수화되지 않은 SQL 쿼리, 더 이상 사용되지 않는 암호화 함수 사용, 유효성 검사를 거치지 않은 입력 처리 등이 있습니다. 정적 분석 도구는 이러한 패턴을 식별하고 수동 보안 검토가 필요한 항목으로 표시합니다.
취약점 밀도는 KLOC당 확인된 보안 취약점 수를 나타내며, 일반적으로 CVSS 심각도별로 분류됩니다. 이 지표는 릴리스 후 보안 감사 또는 지속적인 보안 모니터링 파이프라인에서 가장 의미가 있습니다.
코드 품질 측정 방법: 실용적인 접근법
코드 품질 측정은 일회성 작업이 아니라 개발 워크플로에 내재된 지속적인 활동입니다. 실용적인 4단계 접근 방식은 측정 경험이 없는 코드베이스를 기반으로 시작하는 팀에게 효과적입니다.
1단계: 기준선 설정. 변경 작업을 수행하기 전에 코드베이스 전체에 대한 정적 분석을 완벽하게 실행합니다. 순환 복잡도 분포, 파일별 유지보수성 지수, 결함 밀도, 코드 커버리지, 중복률의 현재 값을 기록합니다. 이 기준선은 향후 모든 측정값의 비교 기준이 됩니다. 기준선이 없으면 변경 사항이 품질을 향상시키는지 저하시키는지 판단할 수 없습니다.
2단계: 임계값 정의. 각 측정 항목에 대해 상황에 맞는 허용 가능한 임계값을 설정합니다. 상용 웹 애플리케이션과 안전에 중요한 의료 기기는 적절한 임계값이 다릅니다. 이러한 임계값을 프로젝트 품질 표준에 문서화하고 전체 팀이 볼 수 있도록 공개합니다.
3단계: CI/CD에 통합합니다. 모든 커밋 또는 풀 리퀘스트에서 주요 메트릭을 계산하도록 CI 파이프라인을 구성합니다. 메트릭이 허용 범위를 벗어나는 변경 사항에 플래그를 지정합니다. 임계값 이상의 순환 복잡도를 가진 새 코드가 추가되거나, 임계값 미만의 코드 커버리지가 발생하거나, 심각한 정적 분석 오류가 발견되는 병합은 차단합니다. 이를 통해 메트릭 임계값을 지침에서 강제적인 표준으로 전환합니다.
4단계: 스냅샷이 아닌 추세를 검토하세요. 단일 지표 수치는 유용한 정보를 제공하지만, 추세는 실질적인 조치를 취할 수 있게 해줍니다. 특정 모듈의 코드 변경률이 증가하는 추세, 릴리스 주기 전반에 걸쳐 코드 커버리지가 감소하는 추세, 또는 특정 파일의 유지보수성 지수가 하락하는 추세는 스냅샷 측정으로는 놓칠 수 있는 문제를 나타냅니다. 각 스프린트 회고에서 지표 추세를 검토하세요.
엔터프라이즈, 애자일 및 안전 필수 환경에서의 코드 품질 지표
애자일 개발에서의 코드 품질 지표
애자일 팀은 코드 품질 지표와 관련하여 특정한 어려움에 직면합니다. 짧은 개발 주기 내에 작동하는 소프트웨어를 제공하는 데 중점을 두다 보니 품질 문제가 해결되기 전에 출시해야 한다는 압박감이 생길 수 있습니다. 해결책은 지표를 포기하는 것이 아니라 완료 기준에 지표를 포함시키는 것입니다. 스토리는 기능이 작동하는 것만으로 완료되는 것이 아니라, 기능이 작동하는 동시에 새로운 코드가 팀의 품질 기준을 충족할 때 완료됩니다.
애자일 환경에서 선행 지표는 미래에 발생할 문제를 예측하는 데 도움이 되는 지표로, 코드 변경률, 스프린트당 새로 발생하는 기술 부채, 릴리스별 정적 분석 오류 건수 추세 등이 있습니다. 후행 지표는 이미 발생한 결과물을 측정하는 지표로, 테스트에서 발견된 결함 밀도, 유지보수에 소요되는 시간과 신규 기능 개발에 소요되는 시간, 릴리스별 운영 환경 장애 발생률 등이 있습니다.
기술 실사(Technical Due Diligence)를 위한 코드 품질
인수합병 거래, 공급업체 선정 및 시스템 도입 과정에서 기술적 실사에는 전체 코드베이스에 걸쳐 코드 품질에 대한 체계적인 평가가 필요합니다. 이 맥락에서 가장 중요한 지표는 다음과 같습니다.
- 유지보수성 지수 분포코드베이스에서 빨간색, 노란색, 녹색 영역에 속하는 비율은 각각 몇 퍼센트입니까?
- 기술부채비율개발 비용 대비 예상되는 복구 비용은 얼마입니까?
- 결함 밀도KLOC당 알려진 결함 수는 몇 개이며, 이는 업계 벤치마크와 어떻게 비교되는가?
- 테스트 커버리지자동화된 테스트로 커버되는 코드베이스의 비율은 몇 퍼센트이며, 어떤 수준(라인, 분기, 조건)에서 테스트가 수행되었습니까?
- 의존성 건강외부 의존성이 얼마나 존재하는지, 얼마나 많은 의존성이 오래되었거나 폐기되었는지, 그리고 아키텍처가 얼마나 깊이 결합되어 있는지를 파악합니다.
- 코드 중복코드베이스에서 중복되는 부분의 비율을 파악하여 유지보수 위험을 예측합니다.
기업 코드 평가를 위한 영향 분석 의 맥락에서 살펴보았듯이 , 각 구성 요소가 품질 지표에서 어떤 점수를 받았는지뿐만 아니라 구성 요소 간의 의존 관계를 이해하는 것은 정확한 실사를 위해 필수적입니다. 예를 들어, 고립된 저품질 모듈은 관리 가능한 수준의 수정 비용을 나타낼 수 있지만, 복잡한 의존성 그래프의 중심에 있는 동일한 모듈은 훨씬 더 큰 위험을 내포합니다.
안전 필수 애플리케이션 및 핀테크 애플리케이션의 코드 품질
항공, 자동차, 의료기기 및 산업 제어 분야의 안전 필수 애플리케이션은 일반적인 상용 소프트웨어보다 훨씬 높은 코드 품질 기준을 요구합니다. 주요 차이점은 다음과 같습니다.
- 순환 복잡도 제한은 일반적으로 10 이하로 설정되며, 예외가 있는 경우에는 공식적인 근거를 제시해야 합니다.
- 보장 범위 요구 사항은 회선 또는 분기 보장 범위 대신 MC/DC(수정된 조건/결정 보장 범위)를 사용합니다.
- 정적 분석은 인증된 도구를 사용하여 수행해야 하며, 위반 사항은 문서화하고 해결하거나 공식적으로 승인해야 합니다.
- 코드 변경 빈도는 안전 지표로 모니터링됩니다. 안전에 중요한 모듈의 변경 빈도가 높으면 추가 검토 및 재검증이 수행됩니다.
핀테크 애플리케이션은 규제 프레임워크로부터 유사한 압력을 받고 있습니다. PCI DSS는 안전한 코딩 표준과 코드 검토 프로세스를 요구합니다. 금융 보고 시스템에 대한 SOX 준수는 요구사항부터 코드, 테스트에 이르기까지 문서화된 추적성을 요구합니다. 코드 품질 지표는 이러한 프로세스가 제대로 작동하고 있음을 객관적으로 입증하는 증거를 제공합니다. 예를 들어, 코드 커버리지 보고서는 테스트의 존재를, 정적 분석 보고서는 알려진 취약점 패턴의 검증을, 복잡성 보고서는 검토자가 코드를 합리적으로 평가할 수 있었음을 보여줍니다.
언어별 코드 품질 지표
파이썬 코드 품질 지표 를 사용하여 계산할 수 있습니다 radon (순환 복잡도 및 유지보수성 지수) pylint (코드 냄새 및 스타일 위반) coverage.py (테스트 범위) bandit (보안 문제) mypy or pyright (타입 정확성). 유지보수성 지수는 다음과 같습니다. radon 파이썬에 맞춰 수정된 할스테드 공식을 사용합니다. A등급은 20점 이상, B등급은 10~20점, C등급은 10점 미만입니다.
RPG 코드 품질 IBM i 시스템에서는 표준 품질 측정 도구가 RPG 구문을 분석하지 못하기 때문에 특수 도구가 필요합니다. SMART TS XL 이 기능은 RPG 프로그램에 대한 순환 복잡도, 코드 라인 수 및 종속성 분석을 제공하며, 이는 특히 이전에는 품질 측정을 자동화하는 것이 불가능했던 대규모 레거시 코드베이스를 관리하는 IBM i 환경에 매우 유용합니다.
코드 검토 지표
코드 검토는 그 효과를 측정할 수 있는 품질 관리 활동입니다.
- 적용 범위 검토커밋된 코드 중 병합 전에 공식적인 검토를 거친 코드의 비율
- 검토 결과 발견된 결함검토 과정에서 발견된 결함 수와 검토 대상 변경 세트의 크기 비율
- 검토 소요 시간: 풀 리퀘스트가 생성된 시점부터 검토 및 병합될 때까지 걸리는 시간
- 리뷰 댓글 해결률: 코드 변경으로 이어지는 리뷰 댓글의 비율과 기각된 댓글의 비율
일반적으로 성과가 우수한 팀은 90% 이상의 코드 검토율, 검토 100줄당 평균 1~3개의 결함 발견, 그리고 짧은 처리 시간을 보입니다. 코드 검토 지표는 코드 검토가 품질 검증의 역할을 하는지 아니면 형식적인 절차에 그치는지를 파악하는 데 도움이 됩니다.
지속적인 코드 품질 모니터링
일회성 코드 품질 측정은 지속적인 모니터링보다 훨씬 가치가 떨어집니다. 코드 품질은 코드베이스의 고정된 속성이 아니라 커밋할 때마다 변화합니다. 오늘날 품질이 우수해 보이는 코드베이스라도 품질 지표를 지속적으로 추적하지 않으면 촉박한 개발 과정에서 세 번의 스프린트 만에 품질이 크게 저하될 수 있습니다.
효과적인 지속적인 코드 품질 모니터링에는 다음이 포함됩니다.
- 커밋별 메트릭 계산순환 복잡도 및 정적 분석 결과는 모든 푸시마다 계산됩니다.
- 트렌드 대시보드: 주요 지표의 시간 경과에 따른 시각적 표시 (매일 또는 릴리스별로 업데이트됨)
- CI/CD의 품질 게이트유지보수성, 보안 및 결함 위험에 영향을 미치는 지표에 대한 최소 임계값의 자동 적용
- 회귀 감지릴리스 간 메트릭이 잘못된 방향으로 크게 변동할 경우 알림을 보냅니다.
코드 품질 개선의 주요 지표, 즉 다음 릴리스에서 품질이 좋아질지 나빠질지를 예측하는 신호는 코드 커버리지 추세 방향, 스프린트당 새로 추가된 복잡성, 그리고 해결된 코드 스멜과 새로 발생한 코드 스멜의 비율입니다. 이러한 지표들이 올바른 방향으로 움직이면 품질이 향상됩니다. 그렇지 않을 경우, 품질 저하가 완전히 발생하기 전에 예측할 수 있습니다.
방법 SMART TS XL 코드 품질을 측정하고 개선합니다.
SMART TS XL 이 도구는 개발 환경의 모든 언어 및 플랫폼(COBOL, JCL, Java, .NET, Python, JavaScript, TypeScript, RPG, SQL 등)에 걸쳐 이 문서에 설명된 모든 코드 품질 지표를 계산합니다. 대부분의 품질 도구는 한 번에 하나의 언어만 처리하는 반면, SMART TS XL 이 도구는 전체 시스템의 통합 품질 모델을 구축하여 언어 간 품질 비교, 파일 수준이 아닌 시스템 수준에서 지표 추적, 단일 언어 도구로는 파악할 수 없는 구성 요소 간 품질 문제 식별을 가능하게 합니다.
대규모의 다국어 코드베이스를 보유한 기업 조직의 경우, 정적 코드 분석 능력 SMART TS XL 기술적 실사, 레거시 시스템 현대화 계획 및 지속적인 품질 개선에 모두 필요한 기준 측정값을 제공합니다. 종속성 매핑 이 기능은 품질 평가를 구조적 문제까지 확장합니다. 즉, 어떤 구성 요소에 가장 많이 의존하는지, 어떤 변경 사항이 가장 큰 영향을 미치는지, 품질 지표와 의존성 중심성을 결합했을 때 코드베이스의 어떤 영역이 유지 관리 위험이 가장 높은지 파악할 수 있습니다.
SMART TS XL's의 코드 품질 메트릭은 API를 통해 DevOps 파이프라인과 통합되어 CI/CD 계층에서 품질 게이트를 구현할 수 있습니다. 커밋에서 순환 복잡도가 임계값을 초과하는 함수가 추가되거나, 코드 커버리지가 구성된 최소값 미만으로 감소하거나, 심각한 정적 분석 오류가 발생하면 파이프라인은 개발자에게 측정된 내용과 임계값을 초과한 이유를 정확하게 알려주는 특정 진단 메시지와 함께 빌드를 실패시킬 수 있습니다. 이를 통해 품질 관리가 릴리스 후 감사에서 개발 중 피드백으로 전환되어 품질 문제를 가장 저렴하게 수정할 수 있는 시점에 발견함으로써 품질 문제 해결 비용을 절감할 수 있습니다.
코드 품질은 보고서가 아니라 팀의 규율입니다.
코드 품질 지표의 가치는 팀이 그 지표를 어떻게 활용하는지에 따라 결정됩니다. 분기별 코드 품질 보고서가 발표되더라도 아무런 조치가 취해지지 않는다면, 보고서가 없는 것보다 더 나쁩니다. 왜냐하면 품질 관리가 이루어지고 있다는 착각을 불러일으키지만, 코드베이스는 방치된 채 악화되기 때문입니다. 지표는 구체적인 조치를 유도할 때 비로소 가치를 지닙니다. 예를 들어, 새로운 함수에서 순환 복잡도가 급증하면 해당 함수가 병합되기 전에 리팩토링 논의가 시작되고, 모듈의 코드 커버리지가 떨어지면 테스트 스프린트가 진행되며, 특정 컴포넌트에서 결함 밀도가 높아지면 해당 컴포넌트의 설계에 대한 공식적인 검토가 이루어지는 경우처럼 말입니다.
그러한 문화를 구축하려면 적절한 시점, 즉 개발 중에 지표를 공개하고 이를 구체적인 팀 목표와 연결해야 합니다. 매 스프린트 회고에서 코드 품질 추세를 검토하고, 완료 기준에 품질 임계값을 포함하며, 지표 하락을 기능 하락만큼 심각하게 받아들이는 팀은 유지 관리 비용이 적게 들고 장기적으로 프로덕션 환경에서 발생하는 장애도 적은 코드베이스를 구축하게 됩니다. 측정은 시작점일 뿐이며, 실천이 결과를 만들어냅니다.
