Files
2nd/10_Wiki/Topics/Architecture/Cyclomatic Complexity.md
T

4.9 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, inferred_by, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score tags raw_sources last_reinforced github_commit inferred_by tech_stack
wiki-2026-0508-cyclomatic-complexity Cyclomatic Complexity 10_Wiki/Topics needs_review self
none A 0.92
uncategorized
2026-05-08 pending Claude Opus 4.7 (auto-normalize 2026-05-08)
language framework
unspecified unspecified

Cyclomatic Complexity

📌 한 줄 통찰 (The Karpathy Summary)

Cyclomatic Complexity(순환 복잡도)는 소프트웨어 공학에서 코드의 복잡성을 평가하기 위해 사용되는 소프트웨어 측정 지표 중 하나입니다 [1]. 리팩토링의 결과와 품질을 평가하는 추상 구문 트리(AST) 기반 지표로 활용되며, 코드의 결합도 분석과 함께 사용됩니다 [2]. 성공적인 구조적 리팩토링을 거친 코드는 일반적으로 함수당 평균 순환 복잡도 수치가 감소하여 유지보수성이 향상되는 특징을 보입니다 [3, 4].

📖 구조화된 지식 (Synthesized Content)

  • 리팩토링을 통한 복잡도 감소: AI를 활용한 리팩토링 사례 연구에 따르면, 비대한 라우팅 레이어의 로직을 여러 기능별 전용 레이어로 모듈화하여 재분배한 결과 전체 함수의 수는 늘어났음에도 함수당 평균 순환 복잡도는 2.24에서 2.13으로 낮아졌으며, 라우팅 레이어 자체의 평균 복잡도는 1.97까지 하락했습니다 [3, 4].
  • 실증적 연구에서의 검증: 마이크로소프트의 대규모 시스템(Windows 7) 진화 기록 분석에서도, 리팩토링이 우선적으로 집중된 상위 5%의 모듈은 나머지 95%의 일반 모듈에 비해 순환 복잡도(Cyclomatic complexity)를 비롯한 여러 복잡성 지표(Fan-in, Fan-out 등)를 더 큰 폭으로 감소시키는 것으로 확인되었습니다 [5, 6].
  • 품질 측정의 객관적 척도: 순환 복잡도는 아키텍처의 의존성 분석과 같은 AST 기반 메트릭과 함께 사용되어, 변경된 코드가 단순히 재배치된 것을 넘어 실제적인 구조적 개선(예: 응집도 높은 자기 완결적 모듈로의 전환)을 이루었는지 검증하는 도구로 쓰입니다 [2, 3].
  • (참고: 제공된 소스 내에 순환 복잡도를 계산하는 정확한 수학적 공식이나 구체적인 이론적 산출 기준에 대한 관련 정보는 부족합니다.)

⚠️ 모순 및 업데이트 (Contradictions & Updates)

  • 구성 요소 및 코드 라인 수(LOC) 증가: 순환 복잡도를 낮추기 위해 응집도 높은 여러 개의 작은 모듈이나 함수로 논리를 분리하는 최적화를 거치면, 필연적으로 시스템 내 전체 함수 및 컴포넌트의 수는 증가하게 됩니다(예: 806개에서 1,022개로 증가) [3]. 결과적으로 개별 함수의 복잡도는 감소하지만 전체 코드 라인 수(LOC)와 파일 수는 오히려 증가하는 반대 급부(Trade-off)가 발생합니다 [7-9].
  • 다차원적인 평가의 필요성: 순환 복잡도와 같은 지표가 개선되었다고 해서 소프트웨어 수정 비용이 모든 측면에서 줄어드는 것은 아닙니다. 리팩토링된 모듈은 복잡도 수치가 낮아지더라도, 구조적 변경으로 인해 수정 사항이 시스템 여러 곳에 흩어지는 '교차 절단 변경(crosscutting changes)'을 유발할 수 있으므로 단일 지표가 아닌 다차원적인 영향 평가가 반드시 수반되어야 합니다 [8, 9].

Last updated: 2026-05-03

🤖 LLM 활용 힌트 (How to Use This Knowledge)

언제 이 지식을 쓰는가:

  • (TODO)

언제 쓰면 안 되는가:

  • (TODO)

🧪 검증 상태 (Validation)

  • 정보 상태: needs_review
  • 출처 신뢰도: A
  • 검토 이유: (P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)

🧬 중복 검사 (Duplicate Check)

  • 기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
  • 처리 방식: UPDATE (자동 정규화)
  • 처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

🔗 지식 연결 (Graph)

  • Parent: 10_Wiki/Topics
  • Related: (TODO: 최소 2개)
  • Opposite / Trade-off: (TODO)
  • Raw Source: 직접 입력

🕓 변경 이력 (Changelog)

날짜 변경 내용 처리 방식 신뢰도
2026-05-08 P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) UPDATE A

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

  • (TODO)

선택 B를 써야 할 때:

  • (TODO)

기본값:

(TODO)

안티패턴 (Anti-Patterns)

  • [안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)