Cyclomatic complexity - 코드의 복잡성을 정량적으로 측정하기

Cyclomatic Complexity

Cyclomatic complexity(a.k.a. CC)는 코드의 복잡성을 나타내는 지표 중 하나다. CC를 계산하는 방법은 매우 간단하다. 단순히 코드의 컨트롤 플로우가 분기하는 부분의 개수를 세면 된다.

CC를 처음 제안했던 Thomas J. McCabe는 함수 하나의 CC가 10을 넘기지 말도록 했지만 이건 76년에 나온 기준이고, 지금의 소프트웨어는 40년 전과 비교가 되지 않게 복잡해진 만큼 15나 20까지는 괜찮다고 주장하는 사람도 있다. 어찌됐든 간에 중요한 것은 CC가 커지면 커질수록 소프트웨어의 에러가 발생할 확률¹⁾이 증가한다는 것이다. 최댓값을 얼마로 잡을지는 프로젝트의 성격과 팀의 성향에 따라서 다르게 잡지만, 지난 40년간 코드의 복잡도를 정적으로 측정할 수 있는 몇 안 되는 지표로써 널리 쓰이고 있다.

Extended Cyclomatic Complexity

하지만 CC가 단순히 분기점만을 세기 때문에 불만을 가지는 사람들이 있었다. 그들이 불만을 가지는 이유는 크게 2가지다. 우선 CC는 단순히 분기점의 수를 세기 때문에, 실제로 같은 코드를 어떻게 표현하느냐에 따라서 값이 달라진다.

그래서 단순히 분기점을 세는 것이 아니라 조건문에 들어가는 Boolean operator(&&, ||)의 수를 더하는 지표가 나왔다. 이를 Extend Cyclomatic Complexity(a.k.a ECC)라고 부른다.

Modified Cyclomatic Complexity

CC에 다른 이유로 불만을 가지는 사람들도 있다. 원래의 CC는 switch에 사용되는 case 문의 수만큼 증가한다. 하지만 대부분의 경우 switch 문에 들어가는 구문은 매우 간단하다. CC의 원래 목적이 코드의 복잡성을 측정하기 위함이라는 것을 생각하면 실제 코드를 복잡하게 하지 않는 switch 때문에 매우 증가하는 CC는 불공평하다. 그래서 나온 것이 Modified Cyclomatic Complexity(a.k.a. MCC)다. MCC는 case 문의 개수와 상관없이 switch 문이 수를 1만 증가시킨다.

앞에서도 말했듯이 CC나 그 변종들은 계산이 간단하고 대부분의 경우에 유용하기 때문에 실제로 많이 쓰이는 지표 중 하나다. 하지만 CC는 어디까지나 분기가 많으면 코드가 복잡해진다는 경험에 기반을 두는 지표다. 따라서 일의 성격에 따라서 CC가 높을 때 코드의 가독성이 높아지는 경우도 있다. 게다가 성능이나 다른 요소들로 인해 코드의 간결성을 포기해야 하는 경우도 있기 때문에 어느 정도로 엄격하게 규칙을 적용해야 하는지는 프로젝트의 성격에 따라 달라진다.

---

1) 정확히는 에러가 있는 함수를 수정했을 때 다른 에러가 발생할 확률이 증가한다.