90% 완료의 함정
마지막 10%가 90%인 이유
"작업 진행률이 어떻게 되나요?"
"90% 완료됐습니다!"
일주일 후...
"지금은 몇 %인가요?"
"음... 95%요."
또 일주일 후...
"아직도 안 끝났나요?"
"거의 다 됐는데... 98%쯤?"
이게 바로 90% 증후군입니다.
소프트웨어 개발에는 오래된 농담이 있습니다. "첫 90%를 완료하는 데 전체 시간의 90%가 걸리고, 나머지 10%를 완료하는 데 또 90%가 걸린다."
농담이 아니라 현실입니다.
90%가 실은 50%인 이유
개발자들이 진행률을 판단할 때 이런 착각을 합니다.
개발자 머릿속에는 화면 구현 100% 완료, 기본 기능 100% 완료, API 연동 80% 거의 완료로 진행률 93%라고 생각합니다.
하지만 실제 전체 작업은 화면 구현 100%, 기본 기능 100%, API 연동 80%, 엣지 케이스 0%(시작도 안 함), 에러 핸들링 0%(생각도 안 함), 성능 최적화 0%(나중에...), 보안 검증 0%(있었나?), 테스트 0%(당연히 나중), 버그 수정 0%(버그가 있을까?), 문서화 0%(굳이...?)로 실제 진행률은 40%입니다.
보이는 것만 세면 90%, 전체를 세면 40%.
진행률 착시의 심리학
첫 번째는 완료의 정의가 모호하다는 것입니다. "완료"가 뭔가요? 개발자는 "코드 다 짰어요"라고 하지만, PM은 "테스트는요?"라고 물으면 개발자는 "아... 그것도 포함이었어요?"라고 합니다.
두 번째는 파레토 법칙의 함정입니다. 80/20 법칙의 역설로 80%의 기능을 20%의 시간에 구현하고, 나머지 20%의 기능에 80%의 시간이 소요됩니다. 마지막 20%가 진짜입니다.
세 번째는 복잡도의 지수적 증가입니다. 처음에는 단순하게 두 숫자를 더하는 함수를 1분이면 완성할 수 있다고 생각하지만, 나중에는 입력 검증, 오버플로우 체크, 정밀도 처리, 로깅, 캐싱까지 추가하여 2시간이 걸립니다.
실제 사례: 로그인 기능
한 스타트업의 실제 진행률 보고입니다.
Day 1은 "50% 완료!"로 로그인 폼 UI, 기본 검증이 완료되었습니다.
Day 3은 "80% 완료!"로 백엔드 API, 세션 관리가 완료되었습니다.
Day 5는 "90% 완료!"로 로그인 성공 케이스가 완료되었습니다.
Day 10은 "95% 완료..."로 비밀번호 찾기, 소셜 로그인, 2FA가 진행 중입니다.
Day 15는 "98% 완료..."로 브라우저 호환성, 모바일 최적화, 보안 취약점 수정이 진행 중입니다.
Day 20은 "99% 완료..."로 부하 테스트, 에러 메시지 다국어, 로그인 실패 5회 제한, CAPTCHA가 진행 중입니다.
Day 25는 "정말 완료!"였습니다.
예상 5일 → 실제 25일 (5배)
정확한 진행률 측정법
첫 번째는 Binary Progress(0% or 100%)입니다. 가장 정직한 방법으로 완료 아니면 미완료입니다. 장점은 명확함이고, 단점은 진행 상황 파악이 어렵습니다.
두 번째는 Definition of Done 체크리스트입니다. Task: 로그인 API의 Progress Checklist로 기능 구현 20%, 단위 테스트 15%, 통합 테스트 15%, 코드 리뷰 10%, 문서화 10%, 보안 검증 10%, 성능 테스트 10%, 배포 준비 10%로 완료 8개 중 3개이면 진행률 37.5%입니다.
세 번째는 Story Point 기반입니다. 로그인 폼 3점 완료, 검증 로직 5점 완료, 세션 관리 8점 완료, 에러 처리 5점 진행중, 보안 강화 8점 시작 전, 테스트 5점 시작 전으로 완료 16점, 전체 34점, 진행률 47%입니다.
네 번째는 번다운 차트 활용입니다. 남은 작업 시간을 그래프로 보면 예상선은 점점 내려가지만, 실제선은 평평해지는 구간이 90% 증후군입니다.
90% 증후군 예방법
첫 번째는 작업을 작게 쪼개기입니다. "로그인 기능" 40시간 대신 로그인 폼 UI 2시간, 이메일 검증 1시간, 비밀번호 검증 1시간, API 엔드포인트 2시간, JWT 토큰 생성 2시간, 세션 저장 1시간처럼 각각 완료 가능한 크기로 나눕니다.
두 번째는 숨겨진 작업 미리 포함입니다. 현실적인 추정으로 보이는 작업에 테스트 30%, 디버깅 20%, 리팩토링 10%, 문서화 10%, 코드리뷰 10%, 통합 20%를 추가하여 총 2배로 계산합니다.
세 번째는 3점 추정법 사용입니다. PERT 추정법으로 낙관적, 현실적, 비관적 추정의 평균을 계산합니다. 예를 들어 로그인 기능을 낙관 3일, 현실 5일, 비관 10일로 추정하면 (3 + 4×5 + 10) / 6 = 5.5일입니다.
네 번째는 일일 체크인입니다. Daily Progress Check로 어제 완료한 것(구체적으로), 오늘 할 것(측정 가능하게), 블로커, 실제 남은 작업(솔직하게)을 확인합니다.
팀별 대응 전략
PM을 위한 팁으로 90% 보고를 들었을 때 "Definition of Done 체크리스트 보여주세요", "테스트는 작성하셨나요?", "엣지 케이스는 처리하셨나요?", "문서는 업데이트하셨나요?"라고 물어보면 대부분 "아..."라고 답합니다.
개발자를 위한 팁으로 진행률 보고 시 "기능은 90%, 전체는 60%입니다", "Happy Path는 완료, 예외 처리 진행 중", "3일 더 필요합니다"(구체적 시간)라고 보고합니다.
경영진을 위한 팁으로 프로젝트 상태 파악 시 진행률보다 남은 작업 수를 보고, 번다운 차트의 기울기를 보고, 데모 가능한 기능을 확인합니다.
90% 증후군 체크리스트
프로젝트가 90% 증후군에 빠졌는지 확인합니다. 2주 이상 90%대 진행률 유지, "거의 다 됐어요"를 3번 이상 들음, 남은 작업 리스트가 늘어남, 예상 완료일이 계속 미뤄짐, 팀원들이 지쳐 보임 중 3개 이상 해당하면 90% 증후군입니다.
마무리: 정직한 진행률이 최선
"90% 완료"는 거짓말이 아닙니다. 착각일 뿐입니다.
해결책:
작업을 작게 나누고, 숨은 작업을 미리 계산하며, Binary(0/100) 또는 체크리스트를 사용하고, 일일 점검하며, 솔직하게 커뮤니케이션합니다.
마지막 10%가 전체의 50%라는 걸 인정하면, 더 정확한 계획을 세울 수 있습니다.
"90% 완료"라고 하지 마세요.
"10개 중 9개 완료"라고 하세요.
숫자는 거짓말하지 않습니다.
정확한 진행률 관리와 투명한 프로젝트 추적이 필요하신가요? Plexo를 확인해보세요.