왜 마지막에 가서야 문제를 발견하게 되는가

많은 발주사가 계약 후 개발사를 “믿고 맡긴다”는 이유로 중간 점검을 생략합니다. 문제는 개발이 순차적으로 진행되지 않고, 여러 기능이 동시에 진행되다가 마지막에 한꺼번에 합쳐지는 경우가 많다는 것입니다. 이 구조에서는 다음 문제가 자주 발생합니다.

• 화면 디자인은 다 됐지만 실제 데이터 처리 로직은 손도 못 댄 상태
• 일부 기능이 다른 기능과 충돌해 통합 단계에서 재작업 필요
• 발주사가 원했던 것과 다르게 이해된 부분이 마지막에야 발견됨

이런 문제는 마지막 주가 아니라 초기 몇 주 안에 발견하면 대응이 훨씬 쉬워집니다. 그래서 프로젝트를 주 단위로 나누어 검수하는 습관이 중요합니다.

전체 기간을 주차별로 나누는 기본 틀

이 틀은 프로젝트 규모에 따라 조정하되, 각 구간마다 “무엇을 확인해야 완료로 볼 것인가”를 미리 정의해두는 것이 핵심입니다.

주간 점검 회의, 이렇게 진행하면 효과적이다

매주 길게 회의할 필요는 없습니다. 30분 이내로 아래 4가지만 확인하는 방식을 권장합니다.

1. 지난주 완료 예정이었던 것 중 실제로 완료된 것
2. 완료되지 않았다면 그 이유와 새로운 예상 완료일
3. 이번 주 진행할 작업과 발주사가 확인해야 할 것
4. 새롭게 발견된 이슈나 결정이 필요한 사항

이 네 가지를 매주 짧게라도 확인하면, 몇 주씩 밀려서 마지막에 몰아서 문제가 터지는 상황을 피할 수 있습니다. 회의 내용은 간단히 텍스트로 기록해 다음 회의 때 비교하세요.

스코프 세분화, 어디까지 나눠야 하는가

전체 프로젝트를 “회원 기능 개발”처럼 큰 단위로만 나누면 진척도를 가늠하기 어렵습니다. 아래처럼 더 작은 단위로 나누는 것이 효과적입니다.

세분화하면 “회원 기능 80% 완료”처럼 모호한 보고 대신, “회원가입 폼, 로그인 완료 / 비밀번호 찾기 진행 중”처럼 명확한 현황 파악이 가능합니다.

중간 검수에서 발견된 문제, 이렇게 처리하라

주간 점검에서 문제가 발견됐을 때는 감정적으로 대응하기보다 아래 절차로 정리하세요.

1. 문제 정의 — 무엇이 합의된 범위와 다른지 구체적으로 기록
2. 원인 구분 — 개발사의 착오인지, 요구사항 자체가 불명확했는지 구분
3. 대응 방식 결정 — 무상 재작업 대상인지, 변경관리(추가 견적) 대상인지 판단
4. 일정 영향 확인 — 전체 일정에 영향이 있다면 다음 주차 계획도 함께 조정

이 절차가 없으면 문제 하나가 발견될 때마다 감정적 다툼으로 이어지기 쉽습니다. 변경관리 기준은 SOW 기능 명세 작성법에서 다루는 조항과 함께 적용하면 좋습니다.

발주사가 매주 준비해야 할 최소한의 역할

발주사가 아무 준비 없이 회의에만 참석하면 점검이 형식적으로 흘러갑니다. 매주 아래 정도는 준비하는 것이 좋습니다.

• 지난주 전달받은 시안·데모를 실제로 확인해보고 의견 정리
• 다음 단계에 필요한 콘텐츠(텍스트, 이미지)를 미리 준비
• 결정이 필요한 사항(디자인 방향, 문구 등)은 회의 전 내부적으로 의견 정리

발주사의 확인이 늦어지는 것 자체가 전체 일정을 늦추는 가장 흔한 원인입니다. 특히 콘텐츠(텍스트, 이미지) 준비가 늦어지면 개발이 다 끝나도 오픈이 지연되는 경우가 많습니다.

소규모 프로젝트도 세분화가 필요한가

4주 이하의 짧은 프로젝트라도 최소한 2회 이상의 중간 점검을 권장합니다.

• 1차 점검(전체 일정의 약 40% 시점) — 디자인 방향과 핵심 화면 구조 확인
• 2차 점검(전체 일정의 약 80% 시점) — 실제 기능 동작과 콘텐츠 반영 상태 확인

짧은 프로젝트일수록 문제를 발견했을 때 대응할 시간이 더 부족하기 때문에, 오히려 점검 시점을 놓치지 않는 것이 중요합니다. 프로젝트 관리가 처음이라 막막하다면 무료 견적요청을 통해 일정·점검 계획을 함께 상담받아보세요.