
순환 복잡도가 높은 소스 코드
#include <stdio.h>
int complexLogic(int a, int b, int c, int d, int e)
{
int result = 0;
if (a > 0) {
if (b > 0) {
if (c > 0) {
result += 1;
} else if (c == 0) {
result += 2;
} else {
result += 3;
}
} else if (b == 0) {
if (d > 10) {
result += 4;
} else if (d > 5) {
result += 5;
} else {
result += 6;
}
} else {
result += 7;
}
} else if (a == 0) {
for (int i = 0; i < 5; i++) {
if ((i % 2 == 0 && e > 0) || (i % 2 != 0 && e < 0)) {
result += i;
} else {
result -= i;
}
}
} else {
int i = 0;
while (i < 3) {
switch (i) {
case 0:
if (b > c) result += 10;
else result += 11;
break;
case 1:
if (c > d) result += 12;
else if (c == d) result += 13;
else result += 14;
break;
case 2:
if (e > 100) result += 15;
else result += 16;
break;
default:
result += 17;
}
i++;
}
}
if (result > 50 && a != 0 && (b > 0 || c > 0)) {
result *= 2;
} else if (result > 20 || d < 0) {
result += 5;
} else {
result -= 5;
}
return result;
}
int main(void)
{
printf("Result: %d\n", complexLogic(1, -1, 0, 7, 3));
return 0;
}
소프트웨어 아키텍처는 답이 없기 때문에 순환복잡도에 대한 정도는 그때 그때 경우에 따라 다르다고 볼 수가 있다. 알고리즘이 복잡한 문제의 경우 아키텍트는 순환복잡도cyclomatic complexity(CC)를 모니터링 하면서 이런 부분을 잘 살펴야 한다.
도메인 자체의 복잡도를 고려하지 않을 경우, 일반적으로 10이하의 CC는 괜찮다고 보는 것이 업계 표준이지만 우리는 임계치가 너무 높고 5 이하로 나와야 응집도가 괜찮은 짜임새 있는 코드라고 생각 한다.
자바 진영에서는 Crap4J라는 측정 도구를 써서 CC와 코드 커버리지를 함꼐 측정하면 코드가 얼마나 불량한지(대충 짜는지) 파악할 수 있습니다. CC가 50 이상 나오는 코드는 커버리지를 아무리 높여도 구제 불능 입니다. 어느 상용 소프트웨어 C 함수의 순환복잡도를 측정해 보았을때 800이 넘는 케이스도 있었다. 4000라인이 넘는 코드가 함수 하나에 몰려 있었고 IF문과 While문이 여기저기 도배 되어 있었다.
순환 복잡도를 낮게 하려면?
테스트 주도 개발(TDD) 같은 엔지니어링 프랙티스는 주어진 문제 영역에서 대체로 더 작고 덜 복잡한 메서드를 생성하는 긍정적인 효과를 갖고 온다. TDD를 수행하는 개발자는 간단한 테스트를 작성한 다음, 테스트를 통과시키는 가장 적은 양의 코드를 작성하려고 합니다. 이처럼 구체적인 동작과 명확한 테스트 경계에 집중하면 짜임세 있고 고도로 응집된 메서드를 개발할 수 있으며 그 결과 순환 복잡도도 낮게 나옵니다.
해당 글은 소프트웨어 아키텍처 101에 쓰여진 글을 요약한 내용이다.

![[소프트웨어 아키텍처] 정책요소와 세부사항이란?](https://codecampai.com/wp-content/uploads/2026/02/image-39-768x515.jpg)
![[소프트웨어 아키텍처] 가이드라인을 활용한 프로젝트 관리](https://codecampai.com/wp-content/uploads/2026/01/image-26-768x419.jpg)
![[소프트웨어 아키텍처] 파이프라인 아키텍처란 무엇인가?](https://codecampai.com/wp-content/uploads/2026/01/image-10-768x374.jpg)
![[소프트웨어 아키텍처] 의존성 역전 원칙(DIP)에 대해서 알아보자.](https://codecampai.com/wp-content/uploads/2026/01/image-50-768x419.jpg)
![[소프트웨어 아키텍처] 중복된 데이터를 해결하는 단일 책임 원칙(SRP)](https://codecampai.com/wp-content/uploads/2026/01/image-39-768x419.jpg)
![[소프트웨어 아키텍처] 아키텍트의 리더십 스킬 3가지](https://codecampai.com/wp-content/uploads/2026/01/image-30-768x1152.jpg)