외주 개발 진척 관리: 마일스톤·주간보고·스프린트 데모로 중간에 확인하기
최종 검수에서 문제가 터지는 이유
개발을 외주로 넘긴 발주자가 가장 자주 겪는 어려움은 "지금 잘 되고 있는지"를 알 수 없다는 점입니다. 계약서에 적힌 완료일만 바라보다가 막판 검수에서 기능 누락, 일정 지연, 합의하지 않은 범위 변경이 한꺼번에 드러나는 일이 반복됩니다. 이 시점에는 되돌릴 시간도, 협상할 여지도 거의 남아 있지 않습니다.
이것은 특정 업체의 문제라기보다 구조의 문제에 가깝습니다. PMI의 2018 Pulse of the Profession(전 세계 프로젝트 전문가 설문, 한국 한정 조사는 아님)에 따르면 조사 대상 프로젝트의 48%가 일정을 지키지 못했고 43%는 예산을 초과했으며, 완료된 프로젝트의 52%는 통제되지 않은 범위 변경, 이른바 스코프 크리프를 겪었습니다. 중간에 상태를 확인할 장치가 없으면 발주자는 이 흐름을 끝에 가서야 알게 됩니다.
핵심은 지연과 범위 변동을 숨기지 않고 중간에 드러나게 만드는 것입니다. 그러려면 계약 단계부터 진척을 확인하는 네 가지 장치를 정해 두어야 합니다.
지급과 연동한 마일스톤 설정
마일스톤은 단순한 일정표가 아니라 "무엇이 끝나면 돈을 지급한다"는 합의입니다. 지급 시점을 완료 산출물과 묶어야 업체도 발주자도 같은 기준을 보게 됩니다. 계약 단계에서 다음을 문서로 고정하세요.
- 완료 정의(Definition of Done): 각 마일스톤에서 "완료"가 무엇인지 기능 목록과 검수 조건으로 적습니다. "로그인 개발"이 아니라 "소셜 로그인 2종, 비밀번호 재설정, 실패 처리까지 동작"처럼 확인 가능한 문장으로 씁니다.
- 지급 비율: 착수금에 과도한 비중을 싣지 말고, 중간 마일스톤과 최종 검수에 의미 있는 금액을 남겨 둡니다. 마지막 지급분이 너무 작으면 막판 수정 요청에 대한 지렛대가 사라집니다.
- 검수 기간과 하자 보수 범위: 각 마일스톤마다 발주자가 확인할 기간, 수정 요청 횟수, 하자 보수 조건을 함께 적습니다.
마일스톤을 2주에서 4주 단위로 잘게 나누면 문제가 빨리 보입니다. 간격이 길수록 첫 확인 시점이 멀어지고, 그만큼 되돌릴 비용이 커집니다.
양식을 고정한 주간보고
주간보고는 "열심히 하고 있습니다" 같은 서술형 메일이 아니라 비교 가능한 표여야 합니다. 양식을 고정해 두어야 매주 같은 눈금으로 진척을 읽을 수 있습니다. 다음 항목을 한 장짜리 양식으로 받으세요.
- 계획 대비 실적: 지난주 계획한 작업과 실제 완료한 작업을 나란히 적습니다. 완료, 진행 중, 미착수로 상태를 구분합니다.
- 지연 항목과 원인: 늦어진 작업이 있으면 원인(요건 불명확, 외부 연동 대기, 인력 변동 등)과 복구 계획을 함께 적습니다. 원인 없는 지연 보고는 다음 주에 반복됩니다.
- 다음 주 계획: 다음 보고 때 이 항목으로 실적을 검증합니다.
- 리스크와 결정 대기 사항: 발주자가 답해 줘야 진행되는 질문을 모아 둡니다. 여기가 비어 있는데 진도가 안 나간다면 다른 곳에서 문제가 숨고 있다는 신호입니다.
한국의 소규모 발주 환경에서는 구두나 메신저로 상황을 주고받다 기록이 흩어지는 경우가 많습니다. 같은 양식을 매주 쌓아 두면 분쟁이 생겨도 경과를 근거로 이야기할 수 있습니다.
문서가 아닌 동작하는 빌드로 하는 데모
진척을 가장 정확하게 보여 주는 것은 보고서가 아니라 실제로 돌아가는 빌드입니다. 반복(스프린트) 주기마다 발주자가 직접 눌러 볼 수 있는 화면이나 접속 가능한 테스트 환경으로 데모를 받으세요. 슬라이드로 설명하는 진척은 검증할 수 없지만, 동작하는 빌드는 그 자리에서 확인됩니다.
- 발주자가 핵심 흐름을 직접 조작해 봅니다. 담당자가 마우스를 쥐고 시연하는 것과 발주자가 눌러 보는 것은 다릅니다.
- 데모에서 나온 피드백과 범위 변경 요청은 그 자리에서 기록하고, 추가 작업이면 일정과 비용 영향을 함께 합의합니다. 이 과정이 스코프 크리프를 중간에 드러내는 장치입니다.
- 완벽한 화면을 기다리지 말고 불완전해도 동작하는 상태를 자주 보는 편이 안전합니다.
참고로 Digital.ai의 18th State of Agile Report(응답자 약 350명, 주로 대기업 애자일 코치·컨설턴트 중심이라 소규모 발주 환경과는 표본 특성이 다름)에서는 응답자의 74%가 순수한 프레임워크 대신 하이브리드나 자체 변형 방식을 쓴다고 답했습니다. 교과서적인 스프린트를 그대로 따를 필요는 없고, 발주 규모에 맞게 데모 주기를 정하되 "동작하는 빌드로 확인한다"는 원칙만 지키면 됩니다.
공유 이슈 트래커 운영
주간보고와 데모 사이에 생기는 크고 작은 요청과 버그는 공유 이슈 트래커 한 곳에 모읍니다. 발주자와 개발사가 같은 도구를 보고, 각 이슈에 담당자, 우선순위, 상태, 기한을 붙여 두면 "말했는데 반영이 안 됐다"는 분쟁이 줄어듭니다. 범위 변경도 새 이슈로 등록해 일정·비용 영향을 함께 적어 두면 나중에 근거가 됩니다.
정리하면 진척 관리는 다음 네 가지를 계약 단계부터 정해 두는 일입니다. 지급과 묶은 마일스톤, 양식을 고정한 주간보고, 동작하는 빌드 데모, 공유 이슈 트래커입니다. 이 장치들은 지연과 범위 변동을 끝이 아니라 중간에 드러내기 위한 것이며, 막판 리스크를 줄이는 가장 현실적인 방법입니다.
진척 관리 체계를 갖춘 SI 파트너와 함께 프로젝트를 진행하고 싶다면 SI·업무 시스템 개발 서비스에서 진행 방식을 확인해 보시기 바랍니다.