5영업일은 반드시 지켜야 하는 법정 기한인가

법정 유일한 숫자로 적힌 값은 아닙니다. 착수 합의에 양쪽이 같은 숫자를 남겼는지를 먼저 봅니다. 숫자 없는 기다림은 지연으로 집계되지 않습니다.

현업이 바빠서 5일을 못 지키면

바쁜 주를 일정에 휴가처럼 넣습니다. 기한을 지운 채 제출만 반복하면 재작업이 개발 진척 뒤에 숨습니다.

무응답을 전부 동의로 봐도 되나

착수 합의에 그 문장이 있고, 금액, 권한, 연계는 제외했을 때만 검토 완료로 넘깁니다. 문장이 없으면 미검토입니다.

코멘트가 서로 모순이면 기한은 언제 끝나나

취합 1영업일을 발주사 PM 일정에 둡니다. 모순을 수행사에게 그대로 넘기면 기한은 끝나지 않고 질문만 왕복합니다.

산출물 검토 기한 정하기 - 회신 일수가 없으면 검수가 왜 밀리나

금요일 오후에 설계서 PDF를 올리면, 다음 주 수요일 주간회의에서야 첫 코멘트가 나오는 현장이 있습니다. 수행사 달력으로는 나흘이 지났는데 발주사 달력으로는 검토가 시작도 안 된 상태죠. 회신 기한이 계약이나 착수 합의에 없으면 그 나흘은 누구의 지연도 아닌 빈 시간이 됩니다. 빈 시간이 산출물 3건에서 반복되면 개발 착수는 밀리고, 밀린 주는 검수 기간을 잠식하죠. 기한을 적자고 하면 현업은 바빠서 못 본다고 말합니다. 못 보는 주를 일정에 안 넣으면 그 말은 매주 반복되죠. 이번 포스팅에서는 검토 기한을 영업일 몇 개로 적고, 무응답을 어떻게 처리할지 자세히 다뤄보도록 하겠습니다. 산출물 일정이 반복해서 밀린다면 회신 칸부터 맞춰 보세요.

산출물	출발 기한	기한 초과 시
회의록, 이슈 목록	3영업일	미검토로 남기지 않고 결정 요지 확정
화면 설계	5영업일	이후 코멘트는 변경 후보
요구 목록	5영업일	설계 착수 전제와 분리
전환, 권한, 연계	10영업일	침묵 동의에서 제외
여러 팀 동시 검토	5영업일 + 취합 1일	늦은 팀만 별도 트랙

산출물 두께별 검토 기한의 출발점

회신 없는 나흘은 누구의 지연일까?

기한이 없으면 그 나흘은 지연으로 집계되지 않습니다. 집계되지 않은 날은 다음 산정에도 안 들어갑니다.

수행사는 제출일을 완료로 보고, 발주사는 읽기 시작한 날을 시작으로 봅니다. 두 날짜 사이가 비어 있으면 주간보고의 지연 일수는 0으로 남죠.

0으로 남은 나흘이 설계, 인터페이스, 전환 계획에서 각각 반복되면 12일이 일정 밖에 쌓입니다. 일정 밖에 쌓인 날은 책임 소재가 없어 서로 기다린 시간이 됩니다.

기다린 시간 동안 개발자는 가설계로 화면을 올립니다. 가설계로 올린 화면은 코멘트가 도착하는 순간 재작업이 됩니다.

WBS에 제출일과 회신일을 따로 두지 않으면 이 재작업은 개발 진척의 감소로도 안 보입니다. 진척은 그대로고 남은 일만 늘어납니다.

남은 일이 검수 2주 전에 보이면 이미 버퍼가 없습니다.

검토 기한은 며칠로 적는 게 맞을까?

현장에서는 보통 5영업일을 출발점으로 두고, 페이지가 두꺼우면 7영업일이나 10영업일로 늘립니다.

5영업일은 법령에 박힌 유일한 숫자가 아닙니다. 착수 때 양쪽이 같은 숫자를 적었는지가 먼저죠.

페이지 40장 설계서와 8장 회의록에 같은 5일을 주면, 설계서 쪽은 항상 넘깁니다. 두께를 기준으로 칸을 나눕니다.

회의록과 이슈 목록은 3영업일, 화면 설계는 5영업일, 전환과 권한처럼 여러 팀이 보는 문서는 10영업일. 숫자를 합의문에 한 줄로 남기면 수요일의 코멘트가 기한 안인지 밖인지가 계산됩니다.

요구사항 식별 산출물도 같은 표를 탑니다. 요구 목록만 기한이 없으면, 설계는 빨리 돌아와도 전제가 늦게 바뀝니다.

전제가 늦게 바뀌면 설계 회신 5일은 의미가 없습니다.

무응답은 합의로 볼 수 있을까?

침묵을 동의로 보려면 그 문장이 착수 합의에 있어야 합니다. 없으면 침묵은 미검토입니다.

기한이 지났는데 메일이 없으면 수행사는 이견 없음으로 닫고 싶어 합니다. 발주사는 못 본 것이지 동의한 것이 아니라고 말하죠.

둘 다 기한 문장이 없으면 성립합니다. 착수 합의에 한 줄을 넣습니다.

기한까지 회신이 없으면 제출본을 검토 완료로 보고 개발에 넘긴다. 다만 금액, 권한, 대외 연계는 침묵 동의에서 제외한다.

제외 항이 없으면 무거운 문서까지 자동 통과합니다. 자동 통과한 권한표는 검수 주간에 뒤집힙니다.

뒤집힘이 변경관리로 가지 않고 결함으로 가면, 원인인 무응답이 품질 숫자로 위장됩니다. 위장된 숫자는 다음 주 인력 투입 논의로 새고, 검토 칸은 계속 비어 있습니다.

코멘트가 개발 착수 뒤에 오면 어떻게 할까?

기한 안의 코멘트는 설계를 고치는 쪽으로 돌립니다. 기한을 넘긴 코멘트는 변경 후보로 올려 일정 영향을 적습니다.

개발이 3일 진행된 뒤에 버튼 위치가 바뀌면, 그 3일의 일부를 버립니다. 버린 날을 그냥 흡수하면 다음 문서도 늦게 도착합니다.

기한 안에 온 코멘트는 설계 버전을 올려 반영합니다. 기한 뒤에 온 코멘트는 변경 요청으로 올려, 반영 여부와 추가 일수를 같은 주에 결정하죠.

결정 없이 바로 고치면 발주사는 늦어도 다 받아 주는 선례를 봅니다. 선례가 두 번 쌓이면 기한은 장식입니다.

장식이 된 기한은 검수 범위까지 늦춥니다. 검수 시나리오가 설계 변경을 따라 다시 쓰이면, 시나리오 작성 5일이 임계경로에 새로 붙습니다.

새로 붙은 5일을 오픈 버퍼에서 빼기 전에, 그 코멘트가 기한 안이었는지부터 표시합니다.

검토 주체가 여러 팀이면 기한은 어떻게 나눌까?

팀별 기한을 직렬로 이어 붙이지 않습니다. 같은 5영업일 안에 병렬로 받고, 취합 1일을 따로 둡니다.

현업, 보안, 인프라가 차례로 보면 5일이 15일이 됩니다. 15일은 설계 기간보다 길어지는 달이 있죠.

제출 당일에 세 팀에 같이 보내고, 각 팀의 기한은 같은 날짜로 둡니다. 취합은 발주사 PM이 그다음 1영업일에 합니다.

한 팀이 침묵이면 그 팀만 무응답 규칙을 적용하고, 다른 팀의 코멘트는 먼저 반영합니다. 전원 회신을 기다리면 가장 바쁜 팀이 일정을 결정합니다.

가장 바쁜 팀의 항목이 보안 점검처럼 무거우면, 그 항목만 10영업일 트랙으로 분리합니다. 분리하지 않은 채 전체를 기다리게 하면 화면 문구 수정도 보안 일정을 탑니다.

검증(Validation) 전에 설계 버전이 몇 번 바뀌었는지를 조서에 적으면, 검수 대상이 어느 회신까지 포함했는지가 남습니다.