그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Architecture
Architecture

코드 커버리지를 어떻게 보고 계신가요

실무4/5
설계4/5
인간4/5
기초2/5

면접관의 질문 의도

커버리지를 '높을수록 좋다'고만 답하는 사람과, 지표 종류·한계·상황별 적용 기준을 함께 답하는 사람을 구분하려는 질문이다. 답에 따라 변경 기반 커버리지·테스트 피라미드·뮤테이션 테스팅으로 깊이를 더 캐물을 수 있다.

큐레이션 답변

학습 자료

코드 커버리지는 테스트 실행 중 프로덕션 코드의 어느 부분이 한 번이라도 지나갔는지를 비율로 보여주는 지표다. 라인 커버리지는 실행된 줄을, 브랜치는 분기 결과를, 조건은 개별 조건식의 참/거짓 조합까지 본다. 같은 100% 라인 커버리지라도 브랜치를 보면 절반밖에 안 덮였을 수 있다. 그래서 커버리지는 '얼마나 돌았나'를 알려주지 '제대로 검증했나'는 답하지 않는다.

좋은 답변 구조

  1. 01커버리지를 '실행 범위 측정 지표'로 정의하고 라인·브랜치·조건의 차이를 짚는다
  2. 02높은 커버리지가 결함 탐지력을 보장하지 못하는 이유를 행복 경로 사례로 설명한다
  3. 03도메인 리스크·변경 빈도에 따라 커버리지 기준을 다르게 거는 트레이드오프를 정리한다
  4. 04어떤 경로에 어느 커버리지 종류를 어느 임계로 둘지를 상황 기준으로 단정한다

자주 실수하는 포인트

라인 커버리지 100%를 보고 모든 분기가 검증됐다고 단정한다
예외·에러 처리 경로는 거의 안 보면서 행복 경로만 두텁게 덮어 숫자만 올린다
전사 일률적인 단일 임계값(예: 무조건 80%)을 두고 도메인별 리스크 차이를 무시한다
커버리지가 낮은 영역을 곧바로 '품질 미달'로 해석하고 폐기할 코드와 핵심 코드를 구분하지 않는다

실무 맥락

  • CI에서 커버리지 임계로 머지를 막거나 변경 기반 커버리지 게이트를 운영하는 환경
  • 오래된 레거시 코드에 테스트를 점진적으로 보강하면서 우선순위를 정해야 하는 모듈
  • 결제·정산처럼 분기 하나가 실수익에 직결돼 분기·조건 커버리지까지 봐야 하는 도메인

본인 경험에 녹이는 힌트

커버리지 100%였는데도 운영에서 분기 누락 버그가 났던 경험이 있다면 라인 vs 브랜치 차이를 자기 사례로 풀 수 있다

팀에서 80%·90% 같은 단일 임계값을 걸었다가 행복 경로 테스트가 양산됐던 경험이 있다면 임계의 의미와 한계를 비판적으로 답할 수 있다

결제·인증처럼 리스크가 높은 모듈만 커버리지 기준을 다르게 잡아본 경험이 있다면 지표를 도메인 차등으로 운영하는 시각으로 연결할 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1라인 커버리지와 브랜치 커버리지는 어떤 코드에서 가장 크게 갈리나요
Q2변경 기반 커버리지 게이트는 전체 커버리지 게이트와 비교해 어떤 장단이 있나요
Q3커버리지가 낮아도 괜찮다고 판단할 영역은 어떤 기준으로 가르나요
Q4뮤테이션 테스팅은 커버리지의 어떤 약점을 보완하나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문