424. 조건 커버리지 (Condition Coverage)

핵심 인사이트 (3줄 요약)

본질: 조건 커버리지 (Condition Coverage)은(는) 소프트웨어 공학의 핵심 개념으로, 복잡한 시스템을 체계적으로 설계·관리하기 위한 원칙과 기법이다.

가치: 이 개념을 올바르게 적용하면 소프트웨어의 품질·유지보수성·재사용성이 향상되고, 개발 생산성과 팀 협업 효율이 높아진다.

판단 포인트: 도입 시에는 비용·복잡도·조직 성숙도를 함께 고려해야 하며, 맹목적 적용보다 프로젝트 특성에 맞는 선택적 적용이 핵심이다.

Ⅰ. 개요 및 필요성

소프트웨어 논리의 70%는 복합 조건문으로 이루어져 있습니다. if ( 나이 >= 19 && 음주 측정 결과 < 0.03) 같이 조건식 A와 조건식 B가 합쳐진(Compound) 녀석들 말입니다.

결정(분기) 커버리지 테스터는 이 덩어리가 전체적으로 한 번 $True$가 나오고 한 번 $False$가 나오게 세팅하고 100% 테스트를 끝냈다고 자랑합니다.

TC 1: 나이 25(T) AND 음주 0.01(T) ➔ 전체 결과: True
TC 2: 나이 15(F) AND 음주 0.05(F) ➔ 전체 결과: False

위 두 개만 해봐도 분기가 $T/F$로 모두 갈렸으니 결정 커버리지는 만족합니다. 그런데 갑자기 프로그램이 사형 선고를 받습니다. "어? 성인인데 음주 수치가 0.05(F)가 나온 상황은 테스트 아예 안 했네?" 이 끔찍한 눈먼 구멍을 메우기 위해 돋보기를 들고 이빨을 들이미는 것이 바로 **조건 커버리지(Condition Coverage)**입니다! 조건 커버리지는 덩어리 결과는 버리고, **개별 부품인 나이 $>=19$가 T/F를 가졌나? 음주 수치 $<0.03$이 T/F를 독자적으로 모두 가졌나?**를 끝까지 캐묻는 현미경 검사입니다.

┌──────────────────────────────────────────────────────────────┐
│                  조건 커버리지 타격 부위 분해의 예시                │
├──────────────────────────────────────────────────────────────┤
│ [원시 코드]                                                    │
│  if ( 점수 > 80 [조건A]   OR   출석률 == 100 [조건B] ) {         │
│      장학금 지급!!                                             │
│  }                                                           │
│                                                              │
│ [조건 커버리지 100% 달성 목표: "껍데긴 가라, 부품만 산다"]             │
│   목표: 조건 A가 True/False, 조건 B가 True/False를 다 가져볼 것!       │
│                                                              │
│   테스트 케이스 1: 점수 90 (A=True) , 출석률 90 (B=False)          │
│   테스트 케이스 2: 점수 50 (A=False), 출석률 100(B=True)           │
│                                                              │
│  ▶ 결과적으로 A입장에서도 참/거짓 해봤고, B입장에서도 참/거짓 해봤다!    │
│  ▶ 이로써 내부 부품에 숨은 오류 폭탄은 다 제거 완료(100% 합격!)         │
└──────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 로봇 장난감 검사를 할 때, 결정 커버리지는 "버튼 누르니 로봇이 걷고, 또 누르니 섰네. 합격(전체 결괏값)"이라고 평가하지만, 조건 커버리지는 "왼쪽 다리의 작은 톱니(조건A)가 한번 돌아갔고 안 돌아갔나? 오른쪽 큰 톱니바퀴(조건B)가 한 번 멈추고 굴렀나?"라고 겉모습 대신 뱃속 다이얼들의 미세 작동 여부만 하나하나 따지는 독종 정비사입니다.

Ⅱ. 아키텍처 및 핵심 원리

위의 예시 코드를 다시 살펴봅시다. 조건 커버리지는 달성했지만 시스템에 치명적인 배신이 벌어집니다. TC1 (A=T, B=F) 의 전체 덩어리 결과 $\rightarrow$ True OR False = 결과 True (장학금 지급) TC2 (A=F, B=T) 의 전체 덩어리 결과 $\rightarrow$ False OR True = 결과 True (장학금 지급)

어라? 내부 부품 A와 B는 억울함 없이 참, 거짓을 다 한 번씩 밟았음에도 불구하고, 정작 덩어리(분기문 전체)는 두 번 모두 결과가 참(True)으로만 흘러갑니다! 즉, 장학금을 지급받지 못하는 else 구문으로는 단 1번도 내려가지 않습니다! 이게 바로 그 유명한 화이트박스 기출문제, **"조건 커버리지 100%는 결정 커버리지 100%를 보장하지 못한다"**는 학술적 진리입니다. 안쪽 부품들의 조화가 어긋나 엉뚱하게 겉 껍데기 문이 반쪽짜리로만 닫혀버리는 무서운 약점입니다.

📢 섹션 요약 비유: 체육대회에서 체육 교사(조건 커버리지)가 "모든 학생이 달리기(T)랑 휴식(F)을 다 한 번씩 반반 섞어서 했네!"라고 칭찬했지만, 막상 청백전 종합 점수판(결정 커버리지)을 보니 이상한 대진표 꼬임 때문에 청군(True)만 스코어가 100번 오르고 백군(False)으론 점수가 1점도 안 올라가서 행사가 망해버린 꼴입니다.

항목	설명	비고
핵심 특성	조건 커버리지 (Condition Coverage)의 핵심 특성과 동작 방식	필수 이해 요소
적용 범위	어떤 프로젝트·상황에서 활용하는지	선택 기준
제약 조건	적용 시 주의해야 할 전제·한계	트레이드오프

Ⅲ. 비교 및 연결

순수한 100% 조건 커버리지만을 쓰는 회사는 거의 없습니다. 왜냐하면 '전체 결정(분기) 경로'를 무시해버리는 너무 위험한 사상누각이기 때문입니다. 실무의 테스트 엔지니어들은 이 조건 커버리지와 결정 커버리지 각각의 치명적 결점들을 꿰매어 완벽한 괴물을 창조해 냈습니다.

이것이 그 유명한 **조건/결정 커버리지 (Condition/Decision Coverage)**이며 한 발 더 나아가 항공 우주 방위산업의 최강 군주라 불리는 **변경 조건/결정 커버리지 (MC/DC)**의 기둥이 됩니다. 이 기법들은 "야, A랑 B 각각 참/거짓 한 번씩 다 돌고(조건 달성), 동시에 전체 껍데기 나가는 문도 참/거짓 다 밟아!(결정 달성)"라고 테스터의 영혼을 갉아먹으며 소스코드를 불태워 무오류의 신전으로 만듭니다.

📢 섹션 요약 비유: 엔진 안에 있는 왼쪽 볼트도 조였다 풀고 오른쪽 너트도 조이고 풀었는데(조건 100%), 자동차 시동이 안방향으로만 걸리는(결정 실패) 한심한 짓을 막으려고, 퀄리티 제어관(MC/DC)이 나타나 두 개를 동시에 압박해서 완벽한 명품 엔진 라인을 구축하는 과정입니다.

Ⅳ. 실무 적용 및 기술사 판단

조건 커버리지가 빛을 발하는 순간은, 단락 평가(Short-circuit evaluation)로 인해 특정 오류가 영원히 가려지는 마스킹(Masking) 현상을 박살 낼 때입니다. if ( user != null && user.getAge() > 20 ) 코드에서, 앞 조건(A)이 False면 프로그램 속성에 의해 뒤의 죽음의 조건(Null 오류 포함 조건 B)은 검사하지도 않고 버립니다.

만약 결정(분기) 커버리지만 대충 맞추면 뒤의 부품 user.getAge()가 어떤 미친 버그를 일으킬지 영원히 모릅니다. 이때 조건 커버리지 추적기가 강제로 칼을 들이밀며 "야, B조건 저 뒷놈도 강제로 True/False가 되도록 입력값 멱살 잡고 끌고 와바!"라고 지시함으로써, 꽁꽁 숨어 영원히 호출 안 된 널 포인터 무덤방(Method null)을 파헤쳐내는 일등 공신이 됩니다.

📢 섹션 요약 비유: 형사가 조직을 털 때 "보스만 자백받았으니 사건 끝(분기 커버리지)"이라고 종결하지 않고, 꼬리 자르기 당해서 저 밑에서 영원히 숨을 뻔한 말단 졸개(뒤쪽 마스킹 조건식 B)까지 억지로 끌고 와서 "너도 알리바이 찬성/반대 다 대봐!" 라며 집요하게 물고 늘어지는 참된 수사 기법입니다.

Ⅴ. 기대효과 및 결론

조건 커버리지(Condition Coverage)는 하나의 통나무 상자처럼 보였던 복합 논리 분기문(if문)을 쪼개서 개별 세포들 단위의 건전성(Health)을 확보해 준 위대한 화이트박스 해단(解斷) 도구입니다. 비록 그 자체만으로는 시스템의 전체 흐름을 이탈시키는 약점이 존재하지만, 이 현미경적 통찰력이 없었다면 우리는 영원히 A || B || C || D라는 수십 개의 지옥 폭탄 묶음 안에서 결함이 숨어 자라는 것을 방치했을 것입니다. 조건 커버리지는 더 완벽한 무결점 아키텍처(MC/DC)로 향하기 위해 테스터들이 반드시 깎고 다듬어야만 하는 코드의 투명한 수정체 역할을 수행하고 있습니다.

📢 섹션 요약 비유: 수박(결정문)을 통째로 쪼개보고 "오케이, 반 갈라지네 합격!"하는 게 아닙니다. 조건 커버리지는 수박 속에 박힌 까만 씨앗(개별 조건부품)들을 핀셋으로 하나하나 뽑아가며 안 썩고 건강한지 100% 점거하는 무광고급 미세 검열 테스트입니다.

📌 관련 개념 맵

개념	연결 포인트
소프트웨어 공학 (Software Engineering)	조건 커버리지 (Condition Coverage)의 상위 학문 체계이며 품질·생산성 향상의 공통 목표를 공유한다
소프트웨어 생명주기 (SDLC, Software Development Life Cycle)	조건 커버리지 (Condition Coverage)은 SDLC의 특정 단계에서 핵심적으로 적용된다
품질 보증 (QA, Quality Assurance)	조건 커버리지 (Condition Coverage) 적용 결과는 QA 활동을 통해 검증되고 측정된다
형상 관리 (SCM, Software Configuration Management)	조건 커버리지 (Condition Coverage)에서 생성된 산출물은 SCM을 통해 체계적으로 관리된다

📈 관련 키워드 및 발전 흐름도

소프트웨어 위기 (Software Crisis) 인식
    │
    ▼
조건 커버리지 (Condition Coverage) 개념 정립
    │
    ▼
표준화 및 방법론 체계화 (ISO, CMMI, Agile)
    │
    ▼
클라우드 네이티브·AI 기반 확장 적용
    │
    ▼
지속적 개선 및 DevOps·MLOps 통합

이 흐름은 소프트웨어 위기 인식 → 체계적 방법론 개발 → 표준화 → 현대적 플랫폼 적용으로 이어지는 발전 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

조건 커버리지 (Condition Coverage)은 레고 블록으로 성을 만들 때처럼, 규칙을 정하고 역할을 나누어 함께 작업하는 방법이에요.
혼자서 막 만들면 나중에 무너지거나 고치기 어렵지만, 약속을 지키면 누구나 쉽게 고치고 더 크게 만들 수 있어요.
그래서 소프트웨어 공학은 프로그래머들이 좋은 프로그램을 빠르고 안전하게 만들 수 있게 도와주는 '규칙 모음집'이에요.