1. 같은 ‘80%’라도 의미는 전혀 다를 수 있습니다.
| 상황 | 겉으로 보이는 상태 | 실제 남은 일 |
|---|---|---|
| A | 전체 화면의 80%가 만들어짐 | DB 연결과 핵심 업무 로직이 상당 부분 남음 |
| B | 주요 기능은 동작함 | 오류처리·권한·검증·테스트가 남음 |
| C | 개발환경에서 거의 완료 | 운영 서버 구성·배포·외부서비스 연결이 남음 |
| D | 기능 단위로 개발·테스트 완료 | 일부 잔여 기능과 최종 검수만 남음 |
“80%”보다 먼저 물어야 할 질문은 “완료된 80%를 지금 직접 확인할 수 있나요?”입니다.
2. 진행률은 다섯 가지 관점에서 확인하세요.
01화면
필요한 화면과 입력·조회 UI가 실제로 구현됐는가?
02기능
버튼만 있는 것이 아니라 업무 로직이 실제 동작하는가?
03데이터
등록·수정·조회·삭제와 데이터 연결이 정상적인가?
04예외처리
잘못된 입력, 권한, 오류 상황을 적절히 처리하는가?
05운영환경
실제 서버에서 배포·연동·로그·백업 등을 확인할 수 있는가?
3. 기능별로 ‘완료’의 기준을 정하면 진행률이 보입니다.
예를 들어 회원가입 기능을 “화면이 만들어졌다”만으로 완료 처리하면 실제 상태를 과대평가할 수 있습니다. 기능 하나를 다음처럼 단계별로 확인할 수 있습니다.
화면 구현확인입력항목과 버튼이 설계대로 보이는가?
기능 연결확인가입 요청이 실제 서버 로직과 연결되는가?
데이터 저장확인필요한 데이터가 정상적으로 저장·조회되는가?
검증·오류처리확인중복가입·잘못된 입력 등 예외 상황을 처리하는가?
테스트확인합의된 주요 시나리오에서 정상 동작하는가?
프로젝트마다 완료 정의는 달라질 수 있지만, 최소한 팀과 발주자가 같은 기준으로 “완료”를 판단할 수 있어야 합니다.
4. 중간검수는 보고서보다 실제 시연을 중심으로 하세요.
진행 보고서에 “회원관리 90%, 결제 70%, 관리자 80%”라고 적혀 있는 것보다 테스트 가능한 주소에서 주요 사용자 흐름을 직접 실행해보는 편이 훨씬 많은 정보를 줍니다.
| 확인 방식 | 좋은 질문 |
|---|---|
| 화면 시연 | 이 화면에서 실제 저장까지 보여줄 수 있나요? |
| 업무 흐름 | 회원가입 → 로그인 → 핵심 기능까지 처음부터 실행해볼 수 있나요? |
| 예외 상황 | 잘못된 값이나 중복 요청이 들어오면 어떻게 되나요? |
| 관리자 | 사용자가 만든 데이터를 관리자가 실제로 확인·처리할 수 있나요? |
| 운영환경 | 현재 결과물이 개발 PC가 아니라 테스트 서버에서도 동작하나요? |
5. 이런 진행 보고가 반복되면 상태를 더 구체적으로 확인하세요.
| 신호 | 추가 확인할 내용 |
|---|---|
| 진행률 숫자만 매주 올라간다 | 이번 주 실제로 완료된 기능과 검수 가능한 결과물 |
| 화면 캡처만 전달된다 | 화면 뒤의 기능·데이터가 실제 연결됐는지 |
| “거의 끝났다”가 반복된다 | 남은 작업을 기능 단위로 목록화할 수 있는지 |
| 테스트 주소를 계속 받을 수 없다 | 언제부터 발주자가 직접 확인할 수 있는지 |
| 완료 기준이 계속 바뀐다 | 최초 요구사항과 변경사항이 구분되어 관리되는지 |
6. 비개발자도 확인할 수 있는 중간검수 체크리스트
완료된 기능과 남은 기능을 목록으로 구분할 수 있다.
완료됐다는 기능을 테스트 환경에서 직접 실행할 수 있다.
화면뿐 아니라 저장·조회 등 실제 기능 동작을 확인했다.
주요 사용자 흐름을 처음부터 끝까지 실행해봤다.
잘못된 입력이나 권한 등 주요 예외 상황을 확인했다.
관리자 기능과 사용자 기능이 실제 데이터로 연결되는지 확인했다.
현재 남은 이슈와 해결 예정 시점을 확인할 수 있다.
추가 요구사항과 기존 요구사항의 오류 수정이 구분되어 있다.
한 줄 원칙
개발 진행률은 퍼센트가 아니라 ‘직접 확인할 수 있는 완료 기능’으로 판단하세요.
“80% 완료”라는 설명보다 무엇이 실제로 동작하고, 무엇이 아직 남아 있는지를 기능 단위로 확인할 수 있을 때 프로젝트 상태를 제대로 판단할 수 있습니다.