1. 비개발자가 개발자의 코드를 평가할 필요는 없습니다.
코드 품질이나 기술구조는 전문적인 영역입니다. 발주자가 개발자가 아니라면 이를 직접 평가하려고 하기보다 사업과 사용자 관점에서 확인할 수 있는 결과에 집중하는 편이 현실적입니다.
2. 진행상황을 확인할 다섯 가지 자료만 확보하세요.
무엇을 개발하기로 했고 현재 어디까지 완료됐는지 확인
완료됐다는 기능을 발주자가 직접 실행할 수 있는 환경
오류·미완료·확인 필요사항과 처리상태
최초 요구와 이후 추가·변경된 요청을 구분
현재 위치와 다음 검수·완료 예정 시점
발주자가 답해야 개발이 진행되는 정책·디자인·업무조건
3. 기능목록에 상태를 붙이면 진행률이 보입니다.
복잡한 개발관리 도구가 없어도 기능별 상태만 일관되게 관리하면 프로젝트 흐름을 훨씬 쉽게 파악할 수 있습니다.
| 기능 | 상태 | 발주자 확인 | 남은 내용 |
|---|---|---|---|
| 회원가입 | 완료 | 테스트 완료 | - |
| 로그인 | 완료 | 확인 필요 | 비밀번호 오류 시 메시지 확인 |
| 상품 등록 | 진행 중 | - | 이미지 업로드 연결 |
| 결제 | 진행 중 | - | 결제사 테스트 연동 |
| 관리자 통계 | 미착수 | - | 다음 단계 예정 |
상태 이름은 프로젝트에 맞게 정하면 됩니다. 중요한 것은 “90%”처럼 해석이 필요한 숫자보다 완료 / 진행 중 / 미착수 / 확인 필요처럼 실제 행동과 연결되는 상태를 사용하는 것입니다.
4. 주간회의는 ‘지난주 설명’보다 ‘이번 결과 확인’ 중심으로 하세요.
이번 기간에 끝난 기능을 실제 화면에서 확인
오류·지연·기술적 문제와 영향 확인
발주자가 정해야 할 정책·요구사항 결정
다음 회의에서 무엇을 보여줄지 명확히 설정
회의가 끝날 때 “다음 주까지 많이 진행하겠습니다”보다 “다음 회의에서는 회원가입부터 결제 직전까지 직접 테스트할 수 있습니다”처럼 확인 가능한 결과가 정해져 있는 편이 좋습니다.
5. 기술용어보다 결과 중심으로 질문하세요.
| 알기 어려운 질문 | 비개발자에게 더 유용한 질문 |
|---|---|
| 백엔드 개발률이 몇 %인가요? | 현재 실제로 처음부터 끝까지 사용할 수 있는 기능은 무엇인가요? |
| API는 다 끝났나요? | 이 화면에서 저장한 내용이 관리자 화면까지 정상적으로 전달되나요? |
| DB 작업은 얼마나 됐나요? | 등록한 데이터를 다시 조회·수정했을 때 정상적으로 반영되나요? |
| 테스트는 했나요? | 어떤 사용자 시나리오를 테스트했고 아직 확인하지 않은 것은 무엇인가요? |
| 일정 문제없죠? | 현재 지연 가능성이 있는 작업은 무엇이고 전체 일정에 어떤 영향을 주나요? |
진행이 늦었다면 원인부터 구분하세요.
일정 지연이 항상 개발업체의 문제인 것은 아닙니다. 요구사항 변경, 발주자의 의사결정 지연, 외부 API 승인, 디자인 변경, 예상하지 못한 기술 문제 등 여러 원인이 있을 수 있습니다. 중요한 것은 원인을 숨기지 않고 일정과 범위에 미치는 영향을 함께 관리하는 것입니다.
6. 비개발자용 진행상황 체크리스트
비개발자는 코드를 확인할 필요가 없습니다. ‘약속한 기능이 실제로 동작하는가’를 확인하세요.
기능목록 + 테스트 환경 + 업무 시나리오 + 이슈목록 + 일정만 꾸준히 확인해도 외주개발의 진행상황을 훨씬 구체적으로 파악할 수 있습니다.