SI 프로젝트 일정 지연, 범위와 릴리스를 다시 나누는 기준
“일정은 이미 밀렸는데, 무엇을 빼도 되는지 판단하기 어렵습니다.”
“기능을 줄이면 나중에 다시 만들 일이 커지지 않을까요?”
“발주사와 개발사 사이에서 변경 범위를 어떻게 합의해야 할까요?”
일정이 늦어졌다면 기능을 일괄적으로 줄이기보다, 첫 릴리스가 실제 업무를 끝까지 처리할 수 있는지를 기준으로 범위와 출시 순서를 다시 정해야 합니다. 핵심 업무 흐름을 지키고, 나머지는 후속 릴리스의 조건과 함께 명시적으로 분리하는 방식입니다.
크로플에서 SI 수탁개발을 진행하며 일정이 흔들린 프로젝트를 검토할 때, 저는 기존 기능 목록과 납기를 모두 유지하겠다는 합의가 가장 위험해질 수 있다고 봤습니다. 우선순위만 말로 바꾸면 막판에 검수 기준도 함께 흐려지기 때문입니다. 일정 지연 대응의 출발점은 기능 수를 줄이는 일이 아니라, 첫 릴리스가 완결해야 할 업무 흐름을 다시 합의하는 일입니다.
일정이 늦어졌을 때 가장 먼저 정할 것은 무엇인가요?
첫 릴리스에서 사용자가 완료해야 할 업무 한 가지를 정하고, 그 흐름을 끊는 기능만 남겨야 합니다. 화면 수나 기능 수가 아니라 업무의 시작·처리·확인까지 이어지는지가 판단 기준입니다.
예를 들어 예약 업무 시스템은 예약 등록 화면만으로 운영이 시작되지 않을 수 있습니다. 담당자가 예약 내용을 확인하고 상태를 바꾸며 필요한 사람에게 정보를 전달하는 흐름까지 이어져야 합니다. 반면 첫 출시 시점에 꼭 필요하지 않은 상세 통계, 화면별 디자인 변형, 자동 알림의 세분화는 후속 릴리스 후보가 될 수 있습니다.
이때는 ‘좋아 보이는 기능’과 ‘없으면 업무가 멈추는 기능’을 나눠야 합니다. 요구사항 회의에서 기능마다 다음 질문을 적용해 보세요.
- 이 기능이 없으면 첫 출시 후 실제 업무를 진행할 수 있는가?
- 사람이 임시로 처리할 수 있다면, 출시 초기 운영량에서 그 방식이 감당 가능한가?
- 이 기능은 다른 기능의 전제인가, 아니면 사용 편의나 확장성을 높이는 요소인가?
- 다음 릴리스로 옮길 때 데이터 구조나 현재 설계에 되돌리기 어려운 문제가 생기는가?
첫 번째와 네 번째 질문에 모두 ‘예’라면 첫 릴리스에 남길 가능성이 큽니다. 반대로 임시 운영이 가능하고, 후속 구현 때 구조를 크게 되돌릴 필요가 없다면 미루는 선택을 검토할 수 있습니다.
기능을 빼는 대신 릴리스를 어떻게 나눠야 하나요?
릴리스는 중요도가 낮은 기능을 모아두는 목록이 아니라, 출시 후 어떤 업무를 운영할 수 있는지 설명하는 단위여야 합니다. 기능별 순위보다 먼저 운영 가능한 상태를 정의해야 합니다.
다음 표처럼 세 층으로 나누면 대화의 기준을 맞추기 쉽습니다.
| 구분 | 판단 기준 | 다루는 방식 |
|---|---|---|
| 첫 릴리스 필수 | 없으면 핵심 업무 흐름이 멈춤 | 범위와 검수 조건을 구체화해 유지 |
| 첫 릴리스 보완 | 수작업 대체는 가능하지만 운영 부담이 큼 | 일정 여유와 의존성을 확인해 선택 |
| 다음 릴리스 후보 | 편의·자동화·고도화 성격이 강함 | 제외 사유와 재논의 시점을 기록 |
‘다음에 하자’는 말만으로는 충분하지 않습니다. 후속 릴리스 후보마다 최소한 기능의 목적, 구현에 필요한 선행 조건, 우선순위를 다시 검토할 시점을 남겨야 합니다. 그래야 첫 릴리스가 끝난 뒤 빠진 약속처럼 기능이 다시 들어오는 일을 줄일 수 있습니다.
데이터 구조, 외부 시스템 연동, 권한 체계는 화면에 보이지 않아도 후속 기능의 기반이 될 수 있습니다. 저는 구현 브리프를 작성할 때 무엇을 만들지뿐 아니라 무엇을 만들지 않을지도 함께 적습니다. 제외한 기능이 현재 구조에 어떤 준비를 요구하는지까지 구분해야 범위를 줄이면서도 후속 구현의 되돌림을 줄일 수 있습니다.
일정이 더 밀릴 위험은 어떻게 확인하나요?
남은 기능의 난이도보다 의존성과 미확정 사항을 먼저 확인해야 일정 위험을 판단할 수 있습니다. 완료된 화면이 많아도 정책 결정이나 외부 연동이 남아 있으면 마지막 구간의 일정은 흔들릴 수 있습니다.
범위 재조정 회의에서는 기능을 완료·진행·미착수로만 나누지 말고, 아래 항목을 별도로 표시하는 편이 좋습니다.
- 정책 결정이 필요한 항목: 예외 처리, 권한 기준, 승인 절차처럼 발주사 판단이 필요한 내용
- 외부 의존 항목: API 제공, 계정 발급, 데이터 전달, 심사처럼 다른 조직이나 서비스의 응답이 필요한 내용
- 검수 미정 항목: 완료된 결과를 어떤 조건에서 통과로 볼지 합의되지 않은 내용
- 구조 영향 항목: 뒤로 미뤄도 되지만 지금 데이터 모델이나 권한 설계에는 반영해야 하는 내용
이 목록의 목적은 책임을 가리는 것이 아니라, 개발팀이 통제할 수 있는 일과 결정 또는 협조를 기다려야 하는 일을 분리하는 데 있습니다. 발주사 담당자는 정책 결정이 필요한 항목부터 확정하고, PM은 그 결정이 개발·테스트·검수에 미치는 영향을 같은 문서에서 확인할 수 있게 정리해야 합니다.
발주사와 개발사는 무엇을 문서로 합의해야 하나요?
범위 조정 문서에는 남기는 기능만큼 제외하거나 미루는 기능과 각 릴리스의 검수 조건을 분명히 써야 합니다. 그래야 출시 직전에 기존 요구사항이 다시 들어왔을 때 무엇을 다시 결정해야 하는지 확인할 수 있습니다.
회의록이나 변경 문서에는 다음 내용을 짧게라도 남겨 두세요.
- 첫 릴리스의 목적: 어떤 사용자 또는 담당자가 어떤 업무를 할 수 있어야 하는지
- 포함 범위: 기능명뿐 아니라 처리 가능한 조건과 예외 범위
- 제외 범위: 이번에 구현하지 않는 기능과 제외 이유
- 후속 릴리스 후보: 재검토 시점, 선행 조건, 우선순위 판단 주체
- 검수 기준: 정상 처리, 권한별 동작, 오류 처리, 데이터 확인처럼 통과를 판단할 항목
- 변경 영향: 일정, 비용, 연동, 운영 방식 가운데 달라지는 부분
검수 기준은 ‘화면이 열리는가’보다 ‘합의한 업무 결과가 만들어지는가’에 가까워야 합니다. 특히 기능 추가 요청이 들어오면 기존 범위 안의 수정인지, 일정·비용·검수 조건을 다시 정해야 하는 변경인지를 먼저 분리해 기록해야 합니다.
기능을 줄이면 품질까지 낮아지는 것 아닌가요?
범위를 줄이는 일은 품질 기준을 낮추는 일이 아니라, 제한된 기간에 검증할 대상을 줄여 핵심 업무 흐름의 완성도를 지키려는 선택이어야 합니다. 다만 권한, 데이터 정합성, 운영상 반드시 확인해야 할 처리 조건까지 편의 기능처럼 미뤄서는 안 됩니다.
일정 압박이 커지면 테스트를 생략하거나 예외 처리를 나중으로 보내자는 제안이 나올 수 있습니다. 이때는 어떤 항목이 후속으로 미룰 수 있는 기능인지, 어떤 항목이 첫 릴리스의 품질 조건인지를 구분해야 합니다. 예를 들어 권한별 접근 조건이나 주요 데이터의 저장·조회 조건은 화면 수를 줄여도 유지해야 할 기반일 수 있습니다.
저는 시스템 설계에서 하나의 데이터 모델을 여러 화면과 기능이 공유하도록 보는 편입니다. 릴리스마다 화면은 달라져도 데이터 기준이 흔들리면 후속 개발과 검수가 어려워질 수 있기 때문입니다. 반대로 초기 이용량이 제한적이고 담당자가 수작업으로 확인할 수 있는 알림 고도화나 리포트 자동화는 후속으로 분리할 여지가 있습니다. 이는 모든 프로젝트에 같은 답을 적용하자는 뜻이 아니라, 운영 위험과 되돌림 비용을 함께 보자는 실무 기준입니다.
결론
일정이 지연된 SI 프로젝트에서 지켜야 할 기준은 원래 기능 목록이 아니라, 첫 릴리스가 실제 업무를 끝까지 처리할 수 있는지입니다. 남길 기능, 임시 운영할 기능, 후속 릴리스로 넘길 기능을 같은 기준으로 나누고 문서로 합의하세요.
먼저 첫 릴리스의 업무 흐름 하나를 문장으로 적어 보세요. 이어 각 기능에 대해 ‘없으면 흐름이 멈추는가’, ‘수작업 대체가 가능한가’, ‘지금 구조에 반영해야 하는가’를 확인하면 됩니다. 제외 항목과 검수 조건까지 남겨야 범위 조정이 막연한 축소가 아니라 다음 결정을 위한 릴리스 계획이 됩니다.
자주 묻는 질문
일정이 늦으면 무조건 MVP로 줄여야 하나요?
아닙니다. 핵심 업무가 불완전해진다면 단순 축소보다 일정 조정이나 단계적 오픈을 함께 검토해야 합니다. MVP라는 이름보다 첫 출시 후 운영 가능한 상태인지가 더 중요합니다.
이미 개발 중인 기능도 다음 릴리스로 미룰 수 있나요?
가능하지만, 중단 비용과 현재 구조에 미치는 영향을 먼저 봐야 합니다. 일부만 구현된 기능이 다른 핵심 기능의 기반이라면 화면 노출은 미뤄도 내부 구조는 마무리하는 편이 나을 수 있습니다.
발주사가 기능을 계속 추가하면 어떻게 해야 하나요?
새 요구사항은 기존 범위 안의 수정인지, 일정·비용·검수에 영향을 주는 변경인지 분리해 기록해야 합니다. 영향이 있다면 우선순위, 대체로 제외할 항목, 일정 영향을 함께 결정해야 합니다.
다음 릴리스 일정까지 지금 확정해야 하나요?
정확한 날짜보다 재검토 조건과 담당자를 정하는 일이 먼저입니다. 첫 릴리스 운영 결과, 외부 연동 준비, 정책 확정처럼 우선순위가 바뀌는 조건을 남겨 두면 무리한 약속을 줄일 수 있습니다.
제 도움이 필요하시다면
일정이 흔들린 프로젝트라면 기능 목록을 다시 정리하는 데서 멈추지 않고, 운영 흐름·구현 범위·검수 기준을 한 문서에서 맞춰야 합니다. 크로플은 SI 수탁개발과 프로젝트 관리 경험을 바탕으로 현재 요구사항을 첫 릴리스와 후속 릴리스로 나누고, 구현 브리프와 검수 기준을 정리하는 일을 지원할 수 있습니다.
이미 개발이 진행 중인데 정책 결정이 남아 있거나, 기능은 많지만 출시 가능한 범위가 보이지 않거나, 발주사와 개발사 사이에서 ‘완료’의 의미가 다를 때 특히 이 정리가 필요합니다. 현재 일정, 남은 기능, 확정되지 않은 항목을 기준으로 논의 범위를 먼저 정리할 수 있습니다.
