바이브코딩 방어로 시도한 100% 커버리지

바이브코딩 방어로 시도한 100% 커버리지

사람이 하면 허상이었던 100% 커버리지를 trip-planner v2.1에서 다시 꺼낸 이유와 1회차 실험 회고.

바이브코딩 방어로 시도한 100% 커버리지

TL;DR
테스트 커버리지 100%는 사람이 했을 땐 허상에 가까운 목표였습니다.
작성, 유지, 판단의 비용이 누적되어 70%를 유지하는 것조차 버거웠기 때문입니다.
AI가 코드와 테스트를 동시에 작성하면서 작성/유지 비용이 흡수되었고, trip-planner v2.1 마일스톤에서 stmts/lines/funcs 100%, branches 96.9%까지 도달했습니다.
다만 96.9%에서 멈춘 이유는 기술 한계가 아니라 사람의 거부였고, 비용이 0에 수렴해도 기준을 지키는 건 여전히 사람의 의지라는 점이 1회차 실험의 핵심 회수입니다.

100%라는 숫자를 다시 꺼낸 이유

테스트 커버리지 100%는 한때 농담에 가까운 수치였습니다. 실무에서 70~80%를 유지하는 것조차 버거웠고, 100%를 목표로 삼는 순간 작성/유지 비용이 기능 개발 속도를 잡아먹었습니다.

trip-planner v2.1 마일스톤(9이슈)을 정리하면서 이 숫자를 다시 꺼낸 까닭은 단순합니다. 바이브코딩(vibe coding)으로 작성한 코드를 1인 개발자가 어떻게 신뢰할 것인가, 라는 질문에 답을 시도해본 자리였기 때문입니다.

100%가 허상이었던 이유, 비용 3종 해부

100%가 허상이었던 이유를 “테스트 짤 시간이 없어서”로 정리하면 일부만 본 것입니다. 실제로 작용하는 비용은 세 갈래로 나뉩니다.

작성 비용. 테스트 코드 자체를 짜는 시간입니다. 시나리오 도출, mock 구성, 단언문 작성까지 들어갑니다.

유지 비용. 실무에서 가장 무거운 비용입니다. 기능 변경 한 번이 테스트 N개를 깨뜨리고, 그 N개를 다시 통과시키는 비용이 새 기능 비용을 추월하는 순간 70%조차 지키기 어렵습니다.

판단 비용. 가장 보이지 않지만 가장 큰 비용입니다. “이건 테스트해야 하나, 말아야 하나”를 매 순간 결정하는 인지 부담입니다. 개발자 머릿속에서 백그라운드로 돌아가다가, 마감이 가까워지면 “그냥 넘기자”는 결정이 누적됩니다.

세 비용은 곱셈처럼 작동합니다. 유지 비용이 폭발하는 순간 작성 의지가 꺾이고, 작성 의지가 꺾이면 판단의 기본값이 “안 짠다”로 굳어집니다. 70~80%가 한계였던 건 게으름이 아니라 비용 구조의 균형점이었습니다.

AI가 흡수한 두 가지 비용

바이브코딩이 “AI가 코드를 짜준다”에 그쳤다면 100% 커버리지 시도는 합리적이지 않습니다. 작성 비용 한 갈래만 흡수되고, 유지 비용은 그대로 사람 몫이기 때문입니다.

시도가 가능했던 건 두 비용이 동시에 흡수되었기 때문입니다.

비용흡수 방식
작성 비용AI가 신규 테스트 코드 생성
유지 비용기능 변경 시 AI가 깨진 테스트를 즉시 갱신
판단 비용사람 몫으로 남음 (어디까지 테스트할지의 기준)

작성과 유지 두 갈래가 0에 수렴하면서 70%의 균형점이 무너졌습니다. 100%를 목표로 잡아도 비용 곡선이 폭발하지 않게 된 것입니다.

v2.1 마일스톤, 시도와 도달

trip-planner v2.1은 9이슈 규모였고, 마일스톤 종료 시점에 커버리지 100%를 목표로 잡았습니다. threshold는 70%에서 시작해 단계적으로 끌어올리는 방식이었습니다.

도달 결과는 다음과 같습니다.

항목결과
stmts100%
lines100%
funcs100%
branches96.9%
테스트 수116 (Vitest 93 + pytest 16 + Playwright 7)

단위 테스트만으로 채우지 않고 Playwright E2E 7개를 함께 운용하면서 단위 테스트의 사각지대를 보완했습니다. 커버리지와 E2E 조합이 1인 운영 환경에서 가장 비용 대비 효과가 좋았습니다.

96.9%에서 멈춘 이유

주목할 지점은 branches 96.9%입니다. 기술적으로 100%가 불가능했던 것은 아닙니다.

마일스톤 막바지에 AI(작업을 수행한 Claude)가 threshold를 낮추자고 제안한 순간이 있었습니다. “이 분기는 도달하기 어렵습니다. 80%로 조정하시겠습니까?” 류의 제안이었습니다.

제안을 거부한 건 사용자였습니다. 거부 이후 추가 분기 커버를 시도하면서 96.9%까지 상승했고, 마지막 일부 분기는 의도적으로 남겼습니다.

이 과정이 시사하는 바는 단순합니다. 비용이 0에 수렴해도, 기준을 지키는 의사결정 자체는 여전히 사람의 몫이라는 점입니다. 판단 비용이 사람 몫으로 남는다는 위 분석과 맞물리는 결론입니다.

1회차 실험의 회수

가설은 다음과 같았습니다. “AI가 작성/유지 비용을 흡수하면 100% 커버리지가 매 버전 품질 게이트로 가능해진다.”

1회차 결과로 확인된 것은 부분 검증입니다.

  • 가능: stmts/lines/funcs 100%까지는 비용 폭발 없이 도달
  • 한계: branches 100%는 별도 의사결정이 필요한 영역
  • 조건: 사람이 기준 낮춤 제안을 거부할 수 있어야 유지

일반론으로 확장하기엔 1회차이고, 프로젝트 규모(9이슈)도 작은 편입니다. 다만 “100% 커버리지 = 방어 완료”라는 결론보다 “비용 구조가 바뀌었으니 다시 시도할 가치가 생겼다”는 결론이 더 현실적인 회수로 보입니다.

다음 마일스톤에서 같은 시도를 반복하면서 분기 커버리지의 안정 구간을 측정해볼 계획입니다.

이 글은 Claude와 함께 작업했습니다.

This post is licensed under CC BY 4.0 by the author.