외주 개발을 맡기고 나면 완성일까지 기다리기만 하는 경우가 많습니다. 그러다 납품 직전에 열어 보고 “이게 아닌데”를 깨닫으면 고칠 시간도 예산도 부족합니다. 중간 점검은 문제를 작을 때 발견하는 가장 좋은 방법입니다. 이 글은 중간 점검에서 말 대신 화면과 파일로 확인할 것들을 정리합니다.
중간 점검은 언제, 얼마나 자주
몇 달짜리 일이라면 2주에 한 번 정도가 무난합니다. 계약할 때 점검 날짜와 방식(화상회의, 방문, 시연 링크 공유)을 함께 정해 두면, 점검을 요청하는 일이 눈치 보이지 않습니다. 계약 때 정할 다른 조건은 외주 개발 맡기기 전 꼭 정할 것에 정리했습니다.
보여 달라고 할 것
1. 돌아가는 화면
진행률 몇 퍼센트라는 숫자보다 실제로 눌러 볼 수 있는 화면이 정확합니다. 완성되지 않았더라도 만든 부분까지 시연해 달라고 하세요. 디자인 시안이나 기획 문서만 계속 보여 준다면, 실제 개발이 얼마나 진행됐는지 다시 물어볼 필요가 있습니다.
2. 남은 일 목록
처음에 정한 기능 목록을 기준으로 완료, 진행 중, 남음을 표시해 달라고 합니다. 기능 목록이 없다면 이번 기회에 함께 만드세요. 만드는 방법은 앱 개발 외주 견적, 기능 목록부터 쓰는 법에 있습니다.
3. 바뀐 범위
개발하다 보면 “이 기능은 빼고 저 기능을 넣자” 같은 변경이 생깁니다. 변경은 그때그때 기록하고, 일정이나 비용에 영향이 있는지 확인해 두세요. 말로만 정한 변경은 나중에 서로 기억이 다를 수 있습니다.
4. 우리 데이터로 한 테스트
개발사의 예시 데이터로는 잘 돌아가도, 실제 직원 명단이나 실제 상품 목록을 넣으면 문제가 드러나는 경우가 많습니다. 개인정보를 뺀 실제와 비슷한 자료를 주고 그걸로 시연해 달라고 하세요.
5. 소스코드가 어디에 있는지
계약에서 소스코드를 받기로 했다면, 코드가 어디에 저장되고 있는지(코드 저장소), 우리가 접근할 수 있는지 중간에 확인해 두면 좋습니다. 납품 때 한꺼번에 받는 것보다 안전합니다.
직접 써 본 점검 기록 예시
아래는 가상의 “사내 비품 신청 프로그램”을 맡긴 지 2주차에 중간 점검을 했다고 가정하고 직접 채워 본 기록입니다. 이 프로그램의 요구사항은 견적을 받기 전에 쓰는 한 장짜리 요구사항 문서의 예시와 같습니다.
써 보니 칸마다 **“다음까지”**를 적는 것이 가장 유용했습니다. 다음 점검 때 이 칸만 보면 무엇이 됐는지 바로 확인할 수 있습니다. 기록은 점검이 끝난 날 메일로 서로 공유해 두면 나중에 근거가 됩니다.
점검이 끝난 뒤 할 일
점검이 끝나면 그날 확인한 내용과 다음까지 할 일을 짧게 정리해 개발사와 서로 확인합니다. 회의에서 “좋네요”라고 넘어간 부분도 글로 남겨 두면, 나중에 “그때 괜찮다고 하셨잖아요” 같은 오해를 줄일 수 있습니다. 시연에서 고칠 점을 발견했다면 바로 고쳐 달라고 할지, 마지막에 모아서 고칠지도 함께 정하세요. 작은 수정은 모아서 처리하는 편이 일정에 덜 부담이 됩니다.
또 우리 쪽 담당자가 할 일도 함께 적어 두세요. 테스트용 자료를 언제까지 줄지, 화면 문구를 누가 정할지처럼 의뢰자 쪽에서 늦어지면 개발도 함께 늦어집니다. 점검은 개발사를 감시하는 자리가 아니라 양쪽이 같은 그림을 보고 있는지 맞춰 보는 자리라고 생각하면 훨씬 수월합니다.
이런 신호가 보이면
- 시연을 계속 미루거나, 매번 같은 화면만 보여 준다.
- 남은 일 목록이 점검 때마다 늘어나는데 이유 설명이 없다.
- 담당자가 자주 바뀌거나 연락이 늦어진다.
이런 신호가 보이면 일정을 다시 확인하고, 필요하면 범위를 줄여 꼭 필요한 기능부터 완성하는 방향으로 조정하는 것이 좋습니다.
자주 묻는 질문
Q. 개발을 몰라서 시연을 봐도 판단이 어려워요. 기술적인 판단보다 “내가 쓰는 순서대로 해 봤을 때 막히는 곳이 있는가”를 보면 됩니다. 실제 업무 순서대로 직접 눌러 보는 것이 가장 좋은 점검입니다.
개발을 맡길 곳을 찾고 있다면 GyeokSang의 개발 의뢰 안내도 참고해 보세요. 점검 방식에 대한 질문은 문의로 보내 주시면 됩니다.