개발자 면접 필수! Cyclomatic Complexity와 Maintainability Index, 7가지 오해와 진실

개발자 면접에서 자주 나오는 Cyclomatic Complexity와 Maintainability Index! 예비 개발자들이 꼭 알아야 할 코드 품질 지표의 7가지 오해를 풀고, 실무와 면접에서 자신감 있게 활용하는 방법을 친절하게 설명해 드립니다.

안녕하세요, 예비 개발자 여러분! 면접 준비하시면서 Cyclomatic Complexity (순환 복잡도)나 Maintainability Index (유지보수성 지수) 같은 용어, 한 번쯤 들어보셨을 거예요. 때로는 이 용어들이 너무 어렵게 느껴지거나, '그래서 이걸 왜 알아야 하지?'라는 의문이 들 때도 있으셨을 텐데요.

이 지표들은 단순히 이론적인 개념이 아니라, 여러분이 앞으로 마주할 코드의 품질과 직결되는 아주 중요한 친구들이거든요. 특히 개발자 면접에서 이 지표에 대한 질문을 받게 되면, 단순히 정의만 외워서 답하는 것보다 그 이면에 담긴 개발자의 코드 품질 철학을 보여주는 것이 훨씬 중요하답니다. 또, 실무에 나가서는 여러분이 작성하거나 동료들과 함께 작업하는 코드의 '건강 상태'를 파악하는 데 결정적인 역할을 하죠.

그래서 오늘은 여러분이 Cyclomatic Complexity와 Maintainability Index에 대해 가지고 있을 수 있는 흔한 오해들을 쏙쏙 뽑아내, 면접관이 정말 궁금해하는 개발자의 관점과 실무에서 어떻게 활용되는지를 친근하고 명확하게 설명해 드리려고 해요. 개발자로서 한 단계 더 성장하고 싶다면, 이 글을 통해 코드 품질 지표에 대한 진짜 이해를 얻어가세요!

---

📑 목차

• 1. 오해: Cyclomatic Complexity는 낮을수록 무조건 좋다?
• 그럼 적절한 Cyclomatic Complexity는 어느 정도일까요?
• 2. 오해: Maintainability Index는 점수만 높으면 장땡이다?
• Maintainability Index: 절대값 vs. 변화 추이
• 3. 오해: 이 지표들은 코드 리뷰나 리팩토링할 때만 중요하지 않나요?
• 개발 초기 단계부터의 중요성
• 면접에서 이 지표를 언급하는 이유
• 4. 오해: 복잡도는 단순히 if/else 개수로만 결정되는 거 아닌가요?
• 5. 오해: Maintainability Index가 낮으면 무조건 코드가 나쁜 건가요?
• 레거시 코드의 경우
• 새로운 복잡한 기능 구현
• 6. 오해: 이런 지표들은 자동화 도구로만 확인하면 끝 아닌가요?
• 도구의 한계와 사람의 역할
• 7. 오해: 면접에서 이런 지표를 왜 물어보는 걸까요?
• 코드 품질에 대한 이해와 관심
• 기술 부채 인식 및 관리 능력
• 문제 해결 및 개선 의지
• 커뮤니케이션 및 협업 능력
• 마무리하며: 코드 품질, 개발자의 책임이자 자부심!

Image by PIRO4D on Pixabay

1. 오해: Cyclomatic Complexity는 낮을수록 무조건 좋다?

많은 분이 Cyclomatic Complexity는 낮을수록 좋다고 생각하시죠? 물론 틀린 말은 아니지만, 항상 그런 것만은 아니랍니다. 이 지표는 코드의 독립적인 실행 경로 수를 나타내거든요. 쉽게 말해, 코드가 얼마나 복잡하게 분기되고 반복되는지를 측정하는 거예요.

일반적으로 복잡도가 낮으면 코드를 이해하기 쉽고, 테스트하기 용이하며, 오류 발생 가능성도 줄어듭니다. 예를 들어, 100줄짜리 코드의 복잡도가 5라면 테스트 케이스 5개 정도로 주요 경로를 커버할 수 있다는 의미가 되죠. 하지만 복잡도가 50이라면, 훨씬 많은 테스트가 필요하고 코드 이해도 어려워진다는 뜻입니다.

하지만 여기서 오해가 생길 수 있어요. '무조건 낮춰야 한다'는 강박은 오히려 불필요한 추상화나 과도한 함수 분리를 낳을 수 있거든요. 때로는 특정 비즈니스 로직 자체가 복잡해서, 이를 하나의 함수 내에서 응집력 있게 처리하는 것이 오히려 가독성과 응집력을 높이는 결과를 가져오기도 합니다. 예를 들어, 여러 단계를 거치는 결제 로직이나 복잡한 상태 머신을 구현할 때는 어느 정도의 복잡도는 불가피할 수 있어요.

면접관은 단순히 '낮아야 좋아요!'라는 답변보다, 복잡도와 가독성, 그리고 기능적 효율성 사이의 균형을 이해하는지를 궁금해할 거예요. "복잡도가 높으면 리팩토링을 고려하지만, 비즈니스 로직의 본질적인 복잡성 때문에 불가피한 경우에는 테스트 코드 보강과 문서화를 통해 관리합니다"와 같은 답변이 더 성숙한 개발자의 태도를 보여줄 수 있답니다.

그럼 적절한 Cyclomatic Complexity는 어느 정도일까요?

일반적으로 10 이하를 권장하는 경우가 많지만, 이는 절대적인 기준이 아니에요. 프로젝트의 특성, 팀의 컨벤션, 그리고 해당 코드의 도메인 복잡도에 따라 유연하게 판단해야 합니다. 중요한 건 왜 복잡도가 높은지, 그리고 어떻게 관리하고 개선해 나갈지에 대한 고민이거든요.

---

2. 오해: Maintainability Index는 점수만 높으면 장땡이다?

Maintainability Index (유지보수성 지수)는 이름 그대로 코드를 얼마나 쉽게 유지보수할 수 있는지를 나타내는 지표예요. Halstead Volume (코드의 길이와 복잡도), Cyclomatic Complexity, Lines of Code (코드 라인 수) 등을 복합적으로 고려해서 산출하죠. 점수가 높을수록 유지보수하기 좋은 코드라고 평가받습니다.

물론 높은 점수는 좋은 코드의 중요한 신호지만, 단순히 '점수만 높으면 장땡'이라는 생각은 큰 오해일 수 있어요. MI는 절대적인 점수 자체보다 그 점수의 변화 추이(Trend)를 함께 보는 것이 훨씬 중요하거든요.

예를 들어, 어떤 모듈의 MI가 80점으로 높은 편인데, 계속해서 점수가 하락하고 있다면? 이는 잠재적인 문제를 나타내는 경고등일 수 있어요. 새로운 기능을 추가하거나 버그를 수정하는 과정에서 코드가 점차 복잡해지고 있다는 뜻이거든요. 반대로 MI가 60점으로 다소 낮더라도, 점수가 꾸준히 유지되거나 개선되고 있다면 해당 코드가 잘 관리되고 있다고 볼 수도 있습니다.

면접에서는 단순히 '높아야 좋은 코드예요'라고 답하기보다, 지속적인 관찰과 개선의 중요성을 언급하는 게 더 좋은 인상을 줄 수 있어요. "MI가 높은 것도 중요하지만, 더 중요한 건 지속적인 모니터링을 통해 점수의 하락을 방지하고, 필요할 때 적절한 리팩토링을 통해 점수를 유지하거나 개선하려는 노력입니다"라고 말이죠.

Maintainability Index: 절대값 vs. 변화 추이

지표	절대값 (예: MI 85점)	변화 추이 (예: 85점 -> 70점)
의미	현재 코드의 유지보수 용이성 수준	코드 품질의 변화 방향성, 기술 부채 증가/감소 추이
해석	높으면 유지보수가 용이하다고 평가 (일반적으로 65 이상 권장)	하락 시: 기술 부채 증가 경고, 리팩토링 필요성 상승/유지 시: 코드 품질 관리 양호
실무 적용	특정 시점의 코드 스냅샷 평가	지속적인 품질 관리의 핵심 지표, 리팩토링 우선순위 결정

---

3. 오해: 이 지표들은 코드 리뷰나 리팩토링할 때만 중요하지 않나요?

많은 분이 Cyclomatic Complexity나 Maintainability Index 같은 지표들이 이미 작성된 코드를 리뷰하거나, 문제가 있을 때 리팩토링할 때만 중요하다고 생각하시죠? 하지만 이건 큰 오해입니다! 이 지표들은 소프트웨어 개발 생명주기(SDLC) 전반에 걸쳐 아주 중요한 역할을 하거든요.

개발 초기 단계부터의 중요성

사실 코드 품질 지표는 코드를 작성하기 시작하는 설계 및 구현 단계부터 고려되어야 해요. 어떤 기능을 구현할 때, 단순히 '동작하게 만드는 것'을 넘어 '어떻게 하면 더 읽기 쉽고, 유지보수하기 좋게 만들 수 있을까?'를 고민하는 태도가 중요하거든요.

• 설계 단계: 시스템 아키텍처나 모듈 설계를 할 때부터 각 컴포넌트의 역할과 책임 분리를 명확히 하면, 자연스럽게 복잡도가 낮은 코드를 작성할 기반을 마련할 수 있어요.
• 구현 단계: 함수를 작성할 때부터 단일 책임 원칙(SRP)을 지키고, 불필요한 분기를 피하며, 명확한 변수명을 사용하는 습관은 낮은 복잡도와 높은 유지보수성으로 이어집니다.

면접에서 이 지표를 언급하는 이유

면접관이 이런 지표들을 질문하는 이유는 단순히 여러분이 정의를 외우고 있는지를 확인하려는 게 아니에요. 개발자로서 코드 품질에 대한 철학과 문제 해결 능력을 보고 싶어 하는 거거든요.

• 품질 의식: '좋은 코드'에 대한 기준을 가지고 있는지, 기술 부채를 인지하고 관리하려는 의지가 있는지를 보여줄 수 있습니다.
• 예방적 사고: 문제가 발생한 후에 고치는 것보다, 미리 품질 지표를 활용하여 잠재적인 문제를 예방하려는 태도를 어필할 수 있어요.
• 소통 능력: 팀 내에서 코드 품질에 대한 논의를 시작하고, 합리적인 근거를 바탕으로 리팩토링의 필요성을 설득하는 데 이 지표들이 중요한 근거 자료가 될 수 있음을 보여주는 거죠.

결론적으로, 이 지표들은 코드 리뷰나 리팩토링 도구로만 사용되는 것이 아니라, 개발자의 사고방식과 코드 작성 습관을 형성하는 데 중요한 기준이 된답니다.

---

4. 오해: 복잡도는 단순히 if/else 개수로만 결정되는 거 아닌가요?

Cyclomatic Complexity는 코드의 독립적인 경로 수를 센다고 말씀드렸죠? 이때 많은 분이 '그럼 단순히 `if`문이나 `else`문이 많으면 복잡도가 높아지는 거네?'라고 생각하시곤 해요. 물론 `if/else`는 복잡도에 큰 영향을 주지만, 이것만이 전부는 아니랍니다.

Cyclomatic Complexity는 다음과 같은 결정점(decision point)들을 기준으로 계산됩니다:

• 함수의 시작점 (진입점)
• if, else if, else
• for, while, do-while
• switch (각 case 문), default
• && (AND), || (OR) 같은 논리 연산자
• catch 블록
• 삼항 연산자 (? :)

이 결정점들이 추가될 때마다 코드의 독립적인 실행 경로가 늘어나고, 따라서 복잡도도 증가하는 방식이에요. 예를 들어볼까요?

// 예시 1: 단순한 if문
function checkAge(age) { // +1 (진입점)
    if (age > 18) { // +1
        return "성인입니다.";
    } else { // else는 if와 연결되므로 추가 복잡도 없음
        return "미성년자입니다.";
    }
}
// Cyclomatic Complexity: 2 (진입점 1 + if 1)

// 예시 2: 논리 연산자가 포함된 if문
function checkEligibility(age, hasLicense) { // +1
    if (age > 18 && hasLicense) { // +1 (if) +1 (&&)
        return "운전 가능";
    } else {
        return "운전 불가능";
    }
}
// Cyclomatic Complexity: 3 (진입점 1 + if 1 + && 1)

// 예시 3: switch문
function getDayName(day) { // +1
    switch (day) {
        case 1: // +1
            return "월요일";
        case 2: // +1
            return "화요일";
        default: // +1
            return "그 외";
    }
}
// Cyclomatic Complexity: 4 (진입점 1 + case 1 + case 1 + default 1)

보시면 아시겠지만, 단순히 `if/else` 개수만 세는 것이 아니라, 코드가 논리적으로 분기될 수 있는 모든 지점을 계산에 포함하는 것을 알 수 있죠? 이런 디테일을 이해하고 있다면, 면접에서 복잡도에 대한 질문에 더 깊이 있는 답변을 할 수 있을 거예요.

---

Image by PIRO4D on Pixabay

5. 오해: Maintainability Index가 낮으면 무조건 코드가 나쁜 건가요?

Maintainability Index가 낮다는 것은 코드를 유지보수하기 어렵다는 뜻이니, '무조건 나쁜 코드'라고 단정 짓기 쉽죠. 하지만 이 역시 맥락과 상황에 따라 다르게 해석해야 하는 중요한 지점이에요.

레거시 코드의 경우

오랜 기간 서비스되어 온 레거시 코드는 MI가 낮은 경우가 많습니다. 여러 개발자의 손을 거치고, 초기 설계가 현재 요구사항과 맞지 않거나, 급박한 기능 추가로 인해 복잡도가 높아졌을 수 있거든요. 이런 코드들이 MI가 낮다고 해서 무조건 '나쁘다'고 할 수는 없어요. 오히려 오랫동안 안정적으로 동작하며 비즈니스 핵심 기능을 수행하는 중요한 코드일 수도 있습니다.

이런 경우, MI가 낮다는 것은 기술 부채가 있음을 인지하고, 장기적인 관점에서 점진적인 리팩토링을 계획해야 한다는 신호로 받아들여야 합니다. 무턱대고 낮은 MI를 이유로 전체를 뒤엎는 것은 큰 위험을 초래할 수 있으니까요.

새로운 복잡한 기능 구현

때로는 새로운 기능 자체가 매우 복잡한 도메인 로직을 포함할 수 있어요. 예를 들어, 금융 시스템의 복잡한 정산 로직이나 인공지능 모델의 데이터 처리 파이프라인처럼요. 이런 경우, 아무리 클린 코드를 지향해도 초기 구현 단계에서는 MI가 다소 낮게 나올 수 있습니다.

이때 중요한 것은 개발팀의 의지와 관리 노력이에요. '지금은 복잡하지만, 차후 리팩토링을 통해 점차 개선해 나갈 계획이다'와 같은 명확한 목표와 함께 테스트 코드 강화, 문서화 등을 통해 낮은 MI로 인한 위험을 관리하려는 노력이 동반되어야 합니다.

면접관은 여러분이 지표의 절대값보다 상황적 맥락을 이해하고 합리적인 판단을 내릴 수 있는지를 보고 싶어 해요. "MI가 낮더라도 해당 코드가 핵심 비즈니스 로직을 담당하고 안정적으로 동작한다면, 당장의 전면 리팩토링보다는 점진적인 개선 계획을 수립하고 테스트 커버리지를 높여 안정성을 확보하는 것이 중요하다고 생각합니다"와 같은 답변은 매우 실무적인 통찰력을 보여줄 수 있습니다.

---

6. 오해: 이런 지표들은 자동화 도구로만 확인하면 끝 아닌가요?

Cyclomatic Complexity나 Maintainability Index 같은 코드 품질 지표들은 SonarQube, ESLint 플러그인, IDE 통합 도구 등 다양한 자동화 도구를 통해 쉽게 측정하고 확인할 수 있어요. 그래서 '도구가 다 해주니까, 그냥 결과만 보면 끝 아니야?'라고 생각하기 쉽죠. 하지만 이것도 반은 맞고 반은 틀린 오해입니다.

자동화 도구는 분명 엄청난 생산성을 제공해요. 수많은 코드 라인을 순식간에 분석하고, 시각적으로 보기 쉽게 리포트를 생성해 주니까요. 하지만 도구는 숫자를 제공할 뿐, 그 숫자의 의미를 해석하고 어떤 조치를 취할지는 결국 개발자의 몫이거든요.

도구의 한계와 사람의 역할

• 맥락의 이해: 도구는 코드가 왜 그렇게 작성되었는지, 어떤 비즈니스 로직을 담고 있는지 알지 못합니다. 특정 함수의 복잡도가 높게 나왔더라도, 그게 정말 리팩토링이 필요한 '나쁜' 코드인지, 아니면 어쩔 수 없는 '복잡한' 코드인지는 사람이 판단해야 해요.
• 합의와 결정: 도구는 '이 코드의 MI가 50입니다!'라고 알려줄 뿐, '이 코드를 리팩토링할까요, 말까요?'라는 질문에 답해주지 않아요. 팀원들과 함께 논의하여 리팩토링의 우선순위를 정하고, 어떤 방식으로 개선할지 결정하는 과정이 필요합니다.
• 학습과 성장: 지표를 통해 문제점을 발견하고, 이를 해결하는 과정에서 개발자는 더 나은 코드를 작성하는 방법을 배우고 성장하게 됩니다. 단순히 도구의 알림을 끄거나 무시하는 것은 성장 기회를 놓치는 것이나 다름없죠.

면접에서 "저희는 SonarQube를 사용해서 자동으로 코드 품질을 관리합니다!"라고만 답하기보다는, "자동화 도구의 지표를 참고하여 코드 리뷰 시 논의의 근거로 삼고, 팀원들과 함께 리팩토링 우선순위를 정하며 지속적으로 코드 품질을 개선해 나갑니다"와 같이 도구 활용을 넘어선 개발자의 주도적인 역할을 강조하는 것이 훨씬 인상적일 거예요. 도구의 한계를 이해하고 사람의 판단과 논의의 중요성을 강조하는 건 매우 성숙한 개발자의 태도거든요.

---

Image by danieltibi on Pixabay

7. 오해: 면접에서 이런 지표를 왜 물어보는 걸까요?

자, 이제 가장 중요한 질문에 답할 시간이에요. 면접관은 왜 여러분에게 Cyclomatic Complexity나 Maintainability Index 같은 다소 이론적인 지표들을 물어보는 걸까요? 단순히 지식을 테스트하려는 것만은 아니랍니다. 면접관은 이 질문을 통해 여러분의 잠재력과 개발자로서의 가치관을 파악하고 싶어 하거든요.

면접관이 이런 지표를 묻는 주된 이유는 다음과 같아요.

1. 코드 품질에 대한 이해와 관심
2. 여러분이 단순히 기능 구현에만 급급한 개발자가 아니라, 품질 높은 코드를 작성하고 유지보수하는 데 관심을 가지고 있는지 알고 싶어 합니다. 이는 기술 부채를 줄이고, 장기적으로 안정적인 서비스를 만드는 데 필수적인 요소거든요.
3. 기술 부채 인식 및 관리 능력
4. 이 지표들은 기술 부채(Technical Debt)를 객관적으로 측정하는 도구예요. 면접관은 여러분이 기술 부채의 존재를 인지하고, 그것이 프로젝트에 미칠 영향을 이해하며, 이를 어떻게 관리하고 줄여나갈지에 대한 고민이 있는지를 확인하고 싶어 합니다.
5. 문제 해결 및 개선 의지
6. 지표가 낮게 나왔을 때, '이 코드는 나빠!'라고 단정 짓는 것이 아니라, '왜 낮게 나왔을까?', '어떻게 개선할 수 있을까?'를 고민하고 구체적인 해결 방안을 제시할 수 있는 능력을 보고 싶어 해요. 이는 곧 실제 프로젝트에서 마주하는 다양한 문제들을 해결해 나가는 과정과 연결되거든요.
7. 커뮤니케이션 및 협업 능력
8. 코드 품질 지표는 객관적인 데이터를 기반으로 팀원들과 코드에 대해 논의하고, 리팩토링의 필요성을 설득하며, 합의를 이끌어내는 데 중요한 역할을 합니다. 면접관은 여러분이 이런 데이터를 활용하여 효율적으로 소통하고 협업할 수 있는 개발자인지를 평가하고 싶을 거예요.

따라서 면접에서 이 질문을 받으면, 단순히 정의를 말하는 것을 넘어 "저는 이 지표들을 활용하여 코드의 건강 상태를 파악하고, 팀과 함께 더 나은 코드를 만들기 위해 노력하는 개발자가 되고 싶습니다"와 같은 여러분만의 철학을 담아 답변하는 것이 정말 중요하답니다.

---

마무리하며: 코드 품질, 개발자의 책임이자 자부심!

어떠셨나요? Cyclomatic Complexity와 Maintainability Index, 이제는 단순히 어렵고 복잡한 지표가 아니라, 여러분이 더 좋은 개발자로 성장하는 데 필요한 든든한 가이드이자 도구라는 것을 느끼셨으면 좋겠어요.

이 지표들을 이해하고 활용하는 능력은 면접에서 여러분의 기술적 깊이와 품질에 대한 열정을 보여줄 수 있는 강력한 무기가 될 겁니다. 또한, 실무에서는 여러분이 작성하는 코드의 건강과 지속 가능성을 지키는 데 결정적인 역할을 할 거예요.

기억하세요. 코드를 잘 만드는 것은 단순히 기능을 구현하는 것을 넘어, 누구나 이해하고 쉽게 유지보수할 수 있는 코드를 만드는 것을 의미합니다. 이 글이 여러분의 개발 여정에 작은 도움이 되었기를 바라며, 앞으로도 코드 품질에 대한 꾸준한 관심을 가지고 성장해 나가시길 응원할게요!

오늘 다룬 내용에 대해 궁금한 점이 있거나, 여러분만의 코드 품질 관리 노하우가 있다면 댓글로 자유롭게 공유해주세요! 함께 배우고 성장하는 기회가 되기를 바랍니다. 😊

📌 함께 읽으면 좋은 글

• [데이터 엔지니어링] 기업 셀프서비스 BI, 데이터 거버넌스로 성공시키는 실전 전략
• [테스트 QA] 함수 호출 검증, 아직도 Mocking만 고집하시나요? Test Spy로 놓치고 있는 것들
• [게임 개발] 인디 게임 출시 전, 스팀 상점 페이지 최적화에 실패하는 치명적인 이유

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.