'거의 다 됐다'가 가장 위험하다
엔지니어링에서 가장 위험한 보고는 실패 보고가 아닙니다. "거의 다 됐어요" 입니다. 나사 몇 개만 안 끼웠을 뿐 사실상 끝났다는 보고 — 그런데 그 "몇 개"가 정작 핵심인 경우가 너무 많습니다.
90·90 법칙
소프트웨어에 유명한 농담이 있습니다.
"처음 90%가 시간의 90%를 쓴다. 나머지 10%가 또 다른 90%를 쓴다."
도식 렌더링 중…
"되는 것처럼 보이는" 단계(A)에서 완료를 선언하면, 안 보이는 절반(B: 엣지케이스·통합·검증)이 통째로 빠집니다. 그게 "나사 몇 개"의 정체입니다 — 보이지 않을 뿐 가장 어려운 부분.
완료의 조건 — 측정된 증거
"완료"라고 말하려면 무엇이 충족돼야 할까요? 핵심은 선언이 아니라 증거입니다.
- 사용자가 명시한 모든 항목이 실제로 작동하는가 (클릭·실행 증거 포함)
- 코드/단위 테스트(L0/L1)가 아니라 E2E 실제 동작(L2)까지 확인했는가
- defer/partial/missing 항목을 숨기지 않고 표로 드러냈는가
⚠️ 숨긴 미완성이 신뢰를 무너뜨린다 — "다 됐다"고 했는데 사용자가 캐물으니 그제야 빠진 게 나오는 패턴. 한 번 그러면, 그 다음 "완료"는 영영 의심받습니다. 미완성을 먼저 드러내는 게 손해처럼 느껴져도, 그게 신뢰를 지키는 유일한 길입니다.
"PASS"는 측정에서만 나온다
이건 strict_pass와 정확히 같은 정신입니다. mission_success=1이 진짜 성공이 아니듯, "코드가 돈다"가 "완료"가 아닙니다.
💡 불편한 게이트가 정확한 게이트다 — 엄격한 완료 기준은 성공률을 낮춰 보이게 하고, 보고를 길게 만듭니다(빠진 것까지 다 적어야 하니까). 그 불편함이 바로 정확함입니다. 깔끔한 "완료"보다, 빠진 것이 표로 적힌 "부분 완료"가 훨씬 신뢰됩니다.
한 줄 정리
📌 "거의 다 됐다"가 가장 위험하다 — 안 보이는 마지막 10%(엣지케이스·통합·검증)가 사실 절반이다. 완료는 선언이 아니라 측정된 증거다: 명시 항목 전부 작동 확인(L2+), 누락은 숨기지 말고 표로. 불편하게 엄격한 게이트가 신뢰를 지킨다.
