내 코드가 얼마나 복잡한지 측정하는 방법들, 제대로 알아보자

복잡한 코드, 느낌이 아니라 숫자로 말할 수 있을까?

코드 리뷰를 하다 보면 "이 함수 좀 복잡한데?"라는 말을 하거나 듣게 되잖아요. 그런데 "복잡하다"는 게 정확히 뭘 의미하는 걸까요? 줄 수가 많으면 복잡한 건지, 조건문이 많으면 복잡한 건지, 아니면 읽기 어려우면 복잡한 건지… 사실 이건 꽤 오래된 질문인데요, 소프트웨어 공학에서는 코드 복잡도를 정량적으로 측정하려는 시도가 여러 가지 있어왔어요. 오늘은 대표적인 코드 복잡도 측정 방법들을 쉽게 풀어보려고 해요.

가장 기본: 순환 복잡도(Cyclomatic Complexity)

가장 유명한 건 순환 복잡도(Cyclomatic Complexity)예요. 1976년에 Thomas McCabe라는 분이 제안한 건데, 이게 뭐냐면 코드에서 독립적인 실행 경로가 몇 개인지 세는 거예요.

쉽게 설명해볼게요. 아무런 분기가 없는 함수, 그러니까 위에서 아래로 쭉 실행되는 코드의 순환 복잡도는 1이에요. 여기에 if문이 하나 들어가면 2가 되고, if-else에 for 루프까지 있으면 3, 4 이렇게 올라가는 거죠. 계산 공식은 M = E - N + 2P인데, E는 간선(edge) 수, N은 노드 수, P는 연결된 컴포넌트 수예요. 코드를 그래프로 그려서 계산하는 건데, 실무에서는 그냥 "분기점의 개수 + 1"로 대략 계산할 수 있어요.

일반적으로 순환 복잡도가 10 이하면 괜찮고, 20을 넘으면 리팩토링을 고려해야 한다고 보는데요. 이 지표의 장점은 단순하고 직관적이라는 거예요. 하지만 한계도 분명해요. 예를 들어, switch문에 case가 10개 있으면 순환 복잡도가 확 올라가는데, 실제로 그 코드가 읽기 어렵냐 하면 꼭 그렇지는 않거든요. 각 case가 단순한 매핑이라면 오히려 명확한 코드일 수 있잖아요.

사람이 느끼는 복잡함: 인지 복잡도(Cognitive Complexity)

순환 복잡도의 한계를 보완하려고 나온 게 인지 복잡도(Cognitive Complexity)예요. SonarSource에서 제안한 건데, 핵심 아이디어는 "기계가 실행하는 경로 수"가 아니라 "사람이 코드를 읽을 때 느끼는 어려움"을 측정하겠다는 거예요.

인지 복잡도는 몇 가지 규칙으로 계산되는데요. 첫째, if, for, while 같은 흐름 제어문이 나올 때마다 1점이 추가돼요. 둘째, 이게 중요한데, 중첩(nesting)될 때마다 가산점이 붙어요. 그러니까 if 안에 if가 있으면 바깥 if는 1점이지만 안쪽 if는 2점이 되는 식이에요. 왜냐하면 실제로 중첩된 조건문은 머릿속에서 추적해야 할 맥락이 늘어나니까 더 읽기 어렵잖아요.

재미있는 차이가 있어요. 아까 말한 switch문의 경우, 순환 복잡도에서는 case 개수만큼 점수가 올라가지만 인지 복잡도에서는 switch 자체가 1점이에요. 사람 입장에서는 switch문 하나를 이해하는 건 그렇게 어렵지 않으니까요. 반면에 if 안에 for 안에 try-catch 안에 또 if가 있는 코드는 인지 복잡도가 확 올라가요. 실제로 그런 코드는 읽기가 정말 힘들잖아요.

오래됐지만 여전히 쓰이는 것들

이 외에도 코드 복잡도를 측정하는 방법은 꽤 다양해요. Halstead 복잡도라는 것도 있는데, 이건 코드에 사용된 연산자와 피연산자의 수를 기반으로 프로그램의 난이도, 볼륨, 노력 등을 계산하는 방법이에요. 1977년에 나온 거라 좀 오래되긴 했지만, 코드의 "밀도"를 나타내는 데 나름 유용해요.

유지보수성 지수(Maintainability Index)도 있어요. 이건 순환 복잡도, Halstead 볼륨, 코드 라인 수를 조합해서 하나의 점수로 만든 건데, Visual Studio 같은 IDE에서 기본으로 제공하기도 해요. 0~100 사이의 점수가 나오고, 20 미만이면 유지보수가 어렵다는 신호예요.

그리고 단순하지만 의외로 효과적인 라인 수(Lines of Code)도 있어요. 함수 하나가 200줄이 넘으면 복잡도 점수를 계산할 것도 없이 뭔가 잘못된 거잖아요. 때로는 가장 단순한 지표가 가장 실용적이기도 해요.

도구로 직접 측정해보기

이론만 알면 아쉬우니까, 실제로 쓸 수 있는 도구도 알아볼게요. 언어별로 다양한 도구가 있는데요.

Python이라면 radon이라는 패키지가 순환 복잡도와 유지보수성 지수를 한번에 보여줘요. pip install radon 하고 radon cc your_file.py -s를 실행하면 함수별 복잡도 등급이 A부터 F까지 나와요. JavaScript/TypeScript는 complexity-report나 ESLint의 complexity 규칙을 활용할 수 있고요. Java는 PMD, Checkstyle 같은 정적 분석 도구에 순환 복잡도 체크가 포함되어 있어요.

여러 언어를 한번에 분석하고 싶으면 SonarQube를 쓰면 되는데요, SonarQube는 인지 복잡도까지 지원해서 순환 복잡도만으로는 놓칠 수 있는 문제를 잡아줘요. CI/CD 파이프라인에 연동해서 "복잡도가 일정 수준을 넘으면 머지 차단"하는 식으로 활용하는 팀도 많아요.

한국 개발자에게 주는 시사점

한국 스타트업이나 SI 현장에서는 "일단 돌아가면 된다"는 분위기 때문에 코드 복잡도 관리가 뒷전이 되기 쉬운데요. 하지만 서비스가 커지고 팀원이 바뀌면 복잡한 코드는 결국 부채가 돼요. 특히 신규 입사자가 코드를 파악하는 데 걸리는 시간이 코드 복잡도와 직결되거든요.

꼭 거창한 시스템을 도입할 필요 없이, 코드 리뷰에서 "이 함수의 인지 복잡도가 15가 넘네요"라고 구체적인 숫자로 이야기하는 것만으로도 리뷰 품질이 달라져요. "복잡해 보이는데요"라는 주관적 의견보다 "복잡도 점수가 X입니다"가 훨씬 설득력 있고 감정적인 마찰도 적거든요.

추천 드리는 건, 일단 자기가 작성한 코드 중 가장 긴 함수 하나를 골라서 순환 복잡도와 인지 복잡도를 측정해보는 거예요. 숫자로 보면 "아, 이 부분이 문제구나"가 바로 보이거든요. 중첩된 조건문을 얼리 리턴(early return)으로 풀어내거나, 조건을 의미 있는 이름의 변수로 추출하는 것만으로도 인지 복잡도가 크게 떨어져요.