커버리지 갭 분석 — 강한 곳 말고 빈 곳을 측정으로 찾기

문제 — 강한 곳에 더 쌓는 편향

작업물을 늘릴 때 사람은 잘하는 영역에 더 추가한다. 프론트엔드를 잘하면 프론트엔드 글을 더 쓰고, 익숙한 모듈에 테스트를 더 짠다. 쉽고 즐거우니까.

문제는 가치는 보통 빈 영역에 있다. 이미 두꺼운 곳을 더 두껍게 하는 건 한계 효용이 낮고, 비어 있는 곳은 위험이 숨어 있다.

그런데 빈 영역은 안 보인다. 본인 머릿속 분포는 최근 작업에 편향돼서 "골고루 하고 있다"는 착각이 든다. 측정해야 보인다.

해법 — 분포를 측정한다

작업물을 차원별로 집계해서 분포를 본다. 강한 셀과 빈 셀이 숫자로 드러난다.

# 예: 노트를 토픽별로 집계
grep -h "^topics:" src/content/notes/*.mdx \
  | tr -d '[]' | sed 's/topics: //' | tr ',' '\n' \
  | sed 's/^ *//' | sort | uniq -c | sort -rn

10 frontend     ← 두꺼움
 9 workflow
 5 performance
 4 backend       ← frontend의 절반
 1 security      ← 거의 빔 ← 여기
 0 testing       ← 완전히 빔 ← 여기

"security 1, testing 0"이 한눈에 보인다. 머릿속으로는 "골고루"였는데 측정하면 편향이 드러난다.

어느 차원으로 자르나

같은 작업물도 자르는 차원에 따라 다른 갭이 보인다.

• 주제(topic): 어느 도메인이 비었나
• 형식(format): 어느 형태가 부족한가 (노트만 많고 케이스 없음)
• 관점(perspective): 구체 vs 추상, 기술 vs 운영
• 난이도/깊이: 입문만 많고 심화 없음
• 시간(recency): 오래된 것만, 최근 것 없음

여러 차원으로 잘라봐야 한 차원에선 안 보이던 갭이 드러난다.

일반화 — 어디에나 적용

분포 측정 → 갭 발견은 도메인 무관하게 작동한다.

• 테스트 커버리지: 모듈별 테스트 수. 핵심 모듈이 비었나 (라인 커버리지 %만 보면 "어느 종류"가 안 보임 — 모듈·경로별로 자른다)
• 문서: 기능별 문서 유무. 자주 묻는 기능이 문서 0인가
• 에러 처리: 코드 경로별 에러 핸들링. happy path만 있고 실패 경로 비었나
• 스킬 포트폴리오: 본인 역량을 도메인별로. 한쪽만 두껍나
• 고객/매출: 세그먼트별 분포. 한 고객 의존도 과한가

측정 → 우선순위

갭을 찾았다고 다 채우는 게 아니다. 갭 × 중요도로 우선순위.

갭	중요도	우선순위
testing 0	높음 (회귀 위험)	1
security 1	높음	2
design 4	낮음 (충분)	—

비어 있어도 중요하지 않으면 안 채워도 된다. 빈 영역 + 높은 중요도가 진짜 타깃.

함정

• 머릿속 분포를 신뢰: "골고루 하고 있다"는 최근 편향. 반드시 측정.
• 총량만 보기: "100개나 있네"는 분포를 안 보여준다. 차원별로 자른다.
• 한 차원만 보기: 주제로는 골고루인데 형식으로는 편향일 수 있다. 여러 차원.
• 갭=무조건 채우기: 중요하지 않은 빈 곳까지 채우면 자원 낭비. 갭 × 중요도.
• 커버리지 %에 속기: "80% 커버"가 핵심 경로를 포함하는지는 % 만으론 모름. 경로·모듈별로 분해.
• 측정을 게임: "갭 0 만들기"가 목표가 되면 억지로 채운 저품질이 분포만 채운다. 측정은 방향이지 점수가 아님.

핵심

사람은 강한 곳에 더 쌓고 빈 곳을 못 본다. 작업물의 분포를 차원별로 측정하면 머릿속 편향이 숫자로 드러난다. 그다음 갭 × 중요도로 우선순위를 정해 빈 곳을 채운다.

관련

/notes/ai-output-mode-collapse — 생성물 분포 측정으로 수렴 감지 /notes/recurring-trap-to-checklist — 빈 곳에 숨은 위험을 검사로 /notes/recruiter-10-seconds — 포트폴리오의 분포가 첫인상을 결정