SI 프로젝트에서 범위가 불어나는 구조와 이를 막는 변경관리 설계

프로젝트가 끝날 무렵이면 양쪽 모두 비슷한 생각을 합니다.

발주 측에서는 "이 정도는 당연히 포함된 것 아니었나"라고 생각하고, 수행 측에서는 "계약에 없던 것을 계속 요구받았다"고 느낍니다. 둘 다 진심입니다. 그래서 더 풀기 어렵습니다.

이 상황의 원인은 대체로 어느 한쪽의 잘못이 아닙니다. 착수 시점에 범위가 충분히 확정되지 않았고, 그 사실을 양쪽 모두 인지하지 못한 채 시작한 것입니다.

이 글은 SI 프로젝트에서 범위가 늘어나는 전형적인 경로와, 그것을 관리 가능한 형태로 만드는 방법을 정리한 내용입니다. 발주 담당자와 수행 측 모두에게 해당되는 내용으로 썼습니다.

1. 늘어난 것이 아니라 원래 모호했던 것입니다

범위 논쟁의 상당수는 "추가 요구"가 아니라 해석 차이에서 나옵니다.

같은 문장을 다르게 읽습니다

요구사항 정의서에 이런 문장이 있다고 해봅시다.

관리자는 회원 정보를 조회하고 관리할 수 있어야 한다.

발주 측은 이 문장을 읽으면서 검색, 필터, 정렬, 엑셀 내보내기, 일괄 수정, 변경 이력 조회, 권한별 노출 제어를 떠올립니다. 평소 쓰던 시스템이 그렇기 때문입니다.

수행 측은 같은 문장에서 목록 조회와 상세 조회, 수정, 삭제를 떠올립니다. 문장에 적힌 그대로입니다.

둘 다 그 문장을 성실하게 읽었습니다. 그런데 산정한 공수는 몇 배 차이가 납니다.

모호함을 만드는 표현들이 있습니다

요구사항 문서에서 해석 차이를 만드는 표현은 대체로 정해져 있습니다.

표현 유형 예시 확정해야 할 것
포괄 동사 관리한다, 처리한다, 연동한다 구체적으로 어떤 동작인지
정도 부사 신속하게, 안정적으로, 편리하게 측정 가능한 기준값
범위 미지정 각종, 다양한, 기타 대상 항목의 전체 목록
수량 미지정 여러 개의, 복수의 최대 몇 개까지
주체 미지정 자동으로, 시스템이 무엇이 언제 실행하는지
유사 시스템 참조 A사와 같은 수준으로 어떤 기능을 어디까지

이 표현들이 문서에 남아 있으면, 그 부분은 나중에 반드시 논쟁이 됩니다. 착수 전에 하나씩 지워나가는 작업이 필요합니다.

화면 설계가 요구사항을 드러냅니다

기능 목록 수준에서는 합의된 것처럼 보이다가, 화면 설계에 들어가면 차이가 드러납니다. 화면에는 구체적인 항목과 동작을 그려야 하기 때문입니다.

이 시점에 나오는 질문들입니다.

  • 이 목록은 한 번에 몇 건씩 보여줍니까
  • 검색 조건은 무엇이 필요합니까
  • 이 값을 수정하면 관련된 다른 데이터도 함께 바뀝니까
  • 권한에 따라 보이지 않아야 하는 항목이 있습니까
  • 동시에 두 사람이 수정하면 어떻게 됩니까

이런 질문에 답하는 과정이 곧 요구사항 구체화입니다. 여기서 나온 내용이 원래 범위인지 추가인지를 판단하는 기준이 있어야 합니다. 없으면 그때그때 힘의 균형으로 결정됩니다.

구체화와 추가를 가르는 기준

기준은 착수 회의에서 합의해 회의록에 남깁니다. 논쟁이 생긴 뒤에 기준을 만들면 그 기준 자체가 협상 대상이 됩니다. 저희는 아래 질문을 위에서부터 차례로 적용합니다.

순서 질문 그렇다면
1 기준선 문서에 해당 기능이나 항목이 글자로 적혀 있습니까 구체화
2 적혀 있지 않지만, 적힌 기능이 동작하려면 반드시 있어야 합니까 (예: 목록 조회에 딸린 페이지 나눔) 구체화
3 기준선의 기능 수, 화면 수, 연동 대상 수, 데이터 항목 수가 늘어납니까 추가
4 새로운 사용자 유형이나 권한 체계, 외부 시스템이 등장합니까 추가
5 이미 확인을 받은 설계나 구현을 다시 해야 합니까 변경 (재작업 비용 발생)
6 위 어디에도 해당하지 않습니까 협의체 안건으로 상정

2번이 가장 자주 다투는 자리입니다. "반드시 있어야 한다"는 말은 그 항목이 없으면 적힌 기능을 쓸 수 없다는 뜻으로 좁게 읽어야 합니다. 있으면 편리한 정도라면 3번으로 넘어갑니다. 앞의 회원 관리 예시라면 목록의 페이지 나눔은 2번이고, 엑셀 내보내기와 일괄 수정은 3번입니다.

판정 결과는 구체화로 결론이 난 경우에도 기록합니다. 구체화로 흡수한 항목이 얼마나 쌓였는지는 이후 일정 협의에서 근거가 됩니다.

2. 범위가 실제로 늘어나는 경로

해석 차이와 별개로, 진짜 추가가 발생하는 경로도 있습니다. 이것들은 사전에 예측 가능합니다.

이해관계자가 뒤늦게 등장합니다

착수 시점에는 주관 부서와만 협의합니다. 그러다 중간 보고 즈음에 다른 부서가 참여하면서 새로운 요구가 들어옵니다.

  • 회계 부서가 전표 처리 방식을 요구
  • 정보보안 담당이 접근 통제 기준을 제시
  • 현업 실무자가 실제 업무 흐름과 다르다고 지적
  • 감사 부서가 이력 관리 요건을 추가

이 요구들은 대체로 타당합니다. 문제는 그 시점에 이미 설계가 상당 부분 진행되어 있다는 것입니다.

예방책은 착수 단계에서 이해관계자를 식별해두는 것입니다. 누가 이 시스템을 쓰는지, 누구의 승인이 필요한지, 어느 부서의 규정이 적용되는지를 목록으로 만들어두면 뒤늦은 등장을 줄일 수 있습니다.

연동 대상 시스템의 사정이 바뀝니다

연동은 상대가 있는 일입니다. 우리 계획대로 되지 않습니다.

  • 연동 규격서를 받아보니 예상과 다름
  • 상대 시스템이 동시에 개편 중이라 일정이 밀림
  • 상대 측 담당자가 협의에 응하지 않음
  • 연동에 필요한 권한이나 회선이 준비되지 않음

연동 항목은 계약 시점에 규격서 확보 여부를 확인하는 것이 안전합니다. 규격서 없이 연동 범위를 산정하는 것은 추정일 뿐입니다. 연동 구간에서 확인할 항목은 외부 시스템 연동에서 장애가 생기는 자리 — 인터페이스 설계 원칙에 따로 정리했습니다.

데이터 이관에서 예상 밖의 일이 생깁니다

기존 시스템의 데이터를 옮기는 작업은 거의 항상 예상보다 큽니다.

  • 실제 데이터를 받아보니 정합성이 맞지 않음
  • 문서화되지 않은 예외 데이터가 다수 존재
  • 코드 체계가 여러 번 바뀐 이력이 있음
  • 이관 대상 기간이 협의되지 않음

데이터 이관을 범위에 넣을 때는 실제 데이터 샘플을 먼저 확인해야 합니다. 건수만 듣고 산정하면 대체로 틀립니다. 이관 전에 볼 것들은 레거시 데이터 이관 — 옮기기 전에 확인해야 하는 것들에서 다뤘습니다.

작은 요청이 누적됩니다

한 건 한 건은 거절할 이유가 없는 요청들이 있습니다.

  • 이 버튼 위치만 좀 바꿔주세요
  • 여기에 항목 하나만 추가해주세요
  • 엑셀로 내려받는 기능도 있으면 좋겠는데요
  • 이 화면도 모바일에서 보이게 해주세요

각각은 반나절이면 됩니다. 그래서 대부분 그냥 처리합니다. 문제는 이런 요청이 프로젝트 기간 내내 이어진다는 점입니다.

수십 건이 쌓이면 무시할 수 없는 공수가 되지만, 어디에도 기록되어 있지 않기 때문에 나중에 일정이 부족해졌을 때 근거로 쓸 수 없습니다. 수행 측은 "작은 요청이 계속 있었다"고 말하고, 발주 측은 "큰 걸 요구한 적 없다"고 답합니다. 양쪽 다 사실입니다.

해결책은 거절이 아니라 기록입니다. 처리하되 목록에 남겨두면, 누적량을 숫자로 보여줄 수 있습니다. "말씀하신 건 처리하겠습니다. 다만 이런 요청이 현재 32건이고 합계 공수가 이 정도입니다"라고 말할 수 있는 것과 없는 것은 차이가 큽니다.

일정 압박이 범위를 키우기도 합니다

역설적이지만, 일정이 촉박할수록 범위가 늘어나는 경우가 있습니다.

분석·설계 기간을 줄이고 개발부터 시작하면, 확정되지 않은 채로 만들게 됩니다. 만들고 나서 확인하면 다르다는 지적이 나오고, 고치는 과정에서 새로운 요구가 붙습니다. 결과적으로 처음부터 정하고 시작했을 때보다 더 오래 걸립니다.

앞 단계를 줄여서 확보한 시간은 뒤에서 더 큰 비용으로 돌아옵니다. 일정이 빠듯하다면 범위를 줄이는 것이 분석 기간을 줄이는 것보다 안전합니다.

법규나 제도가 바뀝니다

프로젝트 기간이 길면 그 사이에 관련 규정이 개정될 수 있습니다. 이 경우 대응은 필요하지만, 계약 범위에는 없던 일입니다.

이런 경우를 대비해 계약서에 법규 변경 시 처리 방침을 넣어두는 편이 낫습니다. 협의 대상으로 명시해두기만 해도 나중에 다툼이 줄어듭니다.

3. 변경을 막는 것이 아니라 관리하는 것입니다

변경 자체를 없앨 수는 없습니다. 목표는 변경이 보이지 않게 스며드는 것을 막는 것입니다.

기준선을 확정하고 시점을 남깁니다

변경을 판단하려면 비교 대상이 있어야 합니다. 요구사항 정의서와 화면 설계서를 특정 시점에 확정하고, 그 이후의 차이를 변경으로 보는 방식입니다.

확정할 때 필요한 것들입니다.

  • 문서 버전과 확정 일자
  • 양측 확인 서명 또는 승인 기록
  • 확정 이후 변경은 절차를 거친다는 합의

이 기준선이 없으면 "원래 그렇게 하기로 했다"는 주장이 양쪽에서 나오고, 확인할 방법이 없습니다.

기준선은 한 번에 정해지지 않습니다. 단계마다 더 구체적인 문서가 앞 단계 문서를 대신합니다.

시점 기준선 문서 이 시점 이후 변경으로 보는 것
계약 체결 계약서, 과업내용서(요구사항 정의서), 산출내역서 기능·연동·이관 대상의 증감
분석 완료 요구사항 명세서, 요구사항 추적표 초판 요구사항 ID 단위의 추가·삭제·수정
설계 완료 화면 설계서, 인터페이스 정의서, 데이터 모델 화면 항목, 연동 전문, 테이블 구조의 수정
통합 테스트 착수 테스트 시나리오, 배포 대상 버전 결함 수정을 제외한 모든 수정

뒤 단계로 갈수록 같은 변경이라도 되돌려야 하는 산출물이 많아집니다. 그래서 설계 완료 시점의 확인을 가장 엄격하게 받습니다. 기준선 문서는 수정 권한을 제한한 저장소에 두고, 확정본은 파일명과 문서 안에 버전과 일자를 함께 적습니다. 메신저로 주고받은 파일 가운데 어느 것이 확정본인지 가리는 데 시간을 쓰는 일이 실제로 생깁니다.

변경요청을 문서로 받습니다

구두나 메신저로 들어온 요청을 그대로 반영하기 시작하면 관리가 불가능해집니다. 간단한 양식이라도 문서로 받는 절차가 필요합니다.

변경요청서에 들어갈 항목입니다.

항목 내용
요청 번호와 일자 추적을 위한 식별자
요청자와 소속 권한 있는 사람의 요청인지 확인
변경 내용 무엇을 어떻게 바꾸는지
요청 사유 업무상 필요, 법규 대응, 오류 수정 등
변경 유형 구체화, 추가, 변경, 삭제 가운데 무엇인지
기존 내용과 변경 내용 기준선 문서의 문장과 바꾸려는 문장을 나란히
관련 문서 영향받는 요구사항 항목과 화면 번호
미반영 시 영향 반영하지 않으면 생기는 업무상 문제
영향도 공수, 일정, 비용, 다른 기능에 미치는 영향
산출 근거 공수와 금액을 계산한 방법
회신 기한 영향도 회신일과 승인 여부 결정일
처리 결과 승인·반려·보류와 그 사유, 결정자

영향도 항목이 핵심입니다. 요청을 받았을 때 "가능합니다" 또는 "어렵습니다"로 답하는 대신, 무엇이 얼마나 바뀌는지를 제시하면 논의가 감정이 아닌 판단의 영역으로 넘어갑니다.

"기존 내용과 변경 내용"을 나란히 적는 칸은 생략하기 쉽지만 남겨둘 만합니다. 요청자가 이 칸을 채우다가 기준선 문서에 이미 있는 내용이라는 점을 알게 되는 경우도 있고, 반대로 수행 측이 놓친 요구사항이 드러나기도 합니다.

작성 예시입니다. 번호 체계와 수치는 설명을 위해 만든 값입니다.

변경요청서 CR-014
요청일        : 20XX-05-12        요청자 : 발주사 운영팀 OOO (변경 요청 권한자)
변경 유형     : 추가
관련 항목     : REQ-ADM-012 회원 목록 조회 / 화면 ADM-MEM-010
기존 내용     : 관리자는 회원 목록을 조회할 수 있다. (검색 조건: 이름, 가입일)
변경 내용     : 조회 결과를 엑셀 파일로 내려받는 기능을 추가한다.
요청 사유     : 월별 회원 현황 보고서 작성에 사용
미반영 시 영향 : 보고서 작성 시 화면 내용을 수작업으로 옮겨 적어야 함
영향도        : 별지 영향도 분석서 IA-014 참조
회신 기한     : 영향도 회신 05-15 / 승인 여부 결정 05-19
처리 결과     : (검토 후 기재)

이 예시에서 눈여겨볼 부분은 내려받는 파일에 개인정보가 담긴다는 점입니다. 요청서에는 "엑셀 내보내기" 한 줄이지만 영향도 분석에서는 내려받기 권한, 사유 입력, 내려받기 이력 기록이 함께 올라옵니다. 요청서에 적힌 문장보다 실제 범위가 커지는 대표적인 경우입니다.

영향도를 산정할 때 함께 보는 것들

변경 하나가 미치는 범위는 생각보다 넓습니다.

  • 설계 문서 수정
  • 개발 공수
  • 이미 작성된 테스트 항목 수정
  • 연동 대상 시스템과의 재협의
  • 데이터 구조 변경 시 기존 데이터 처리
  • 교육 자료와 매뉴얼 갱신
  • 다른 기능에 미치는 영향

개발 공수만 계산하면 실제보다 작게 나옵니다. 특히 이미 완료된 작업을 되돌리는 비용이 누락되기 쉽습니다.

기능 밖의 항목도 같은 목록에서 확인합니다. 요청서에는 드러나지 않지만 운영 단계에서 비용으로 돌아오는 것들입니다.

관점 확인할 질문
개인정보 수집·조회·내려받기 대상 항목이 늘어납니까. 처리 목적이나 보관 기간이 달라집니까
보안 새 권한이나 역할이 필요합니까. 접근 기록을 남겨야 하는 동작입니까
성능 조회 건수, 동시 사용자, 배치 처리 시간이 설계 때의 가정을 넘습니까
운영 모니터링 항목, 백업 대상, 장애 대응 절차가 바뀝니까
유지보수 외부 라이브러리나 유료 서비스가 추가됩니까. 계약 종료 후 누가 비용을 부담합니까

영향도 분석 절차

영향도 분석은 담당자마다 결과가 달라지기 쉬운 작업입니다. 순서를 정해두면 편차가 줄어듭니다.

  1. 요청 내용 확정 — 요청자와 10~20분 정도 통화하거나 만나 변경 전후의 동작을 문장으로 확정합니다. 해석이 갈린 채로 분석하면 분석을 다시 하게 됩니다.
  2. 유형 판정 — 앞에서 정한 기준으로 구체화인지 추가인지 변경인지 판정합니다. 구체화라면 영향도 분석 없이 기록만 남기고 끝냅니다.
  3. 영향 범위 추적 — 요구사항 추적표에서 해당 요구사항 ID에 연결된 화면, 모듈, 테이블, 인터페이스, 테스트 항목을 뽑습니다.
  4. 작업 분해 — 영향받는 산출물마다 신규 작업과 재작업을 나눠 적습니다. 이미 확인받은 산출물을 고치는 일은 재작업입니다.
  5. 공수와 일정 산정 — 작업별 공수를 더하고, 그 작업이 주 일정 경로에 있는지 확인합니다. 공수가 작아도 연동 테스트 일정에 걸리면 납기가 밀립니다.
  6. 대안 작성 — 전부 반영, 일부만 반영, 다음 단계로 이관의 세 가지를 기본으로 놓고 각각의 공수와 일정을 적습니다. 대안이 하나뿐이면 논의가 승인이냐 거부냐로 좁아집니다.
  7. 회신 — 합의한 기한 안에 영향도 분석서를 보냅니다. 분석에 시간이 더 필요하면 기한 전에 사유와 새 기한을 알립니다.

분석 자체에도 공수가 듭니다. 분석에 하루 이상 걸릴 요청이라면 분석 착수 여부부터 승인을 받는 편이 낫습니다. 분석 공수를 누가 부담하는지 계약에 적어두면 이 단계에서 다툴 일이 없습니다.

위 변경요청 CR-014에 대한 영향도 분석서 예시입니다. 공수는 설명용 값이며 실제 값은 시스템 구조에 따라 달라집니다.

영향 대상 작업 내용 구분 공수(인일)
화면 설계서 ADM-MEM-010 내려받기 버튼, 사유 입력 창 추가 재작업 0.5
회원 관리 모듈 엑셀 생성 API, 내려받기 권한 검사 신규 2.0
권한 정의서 내려받기 권한 추가, 역할별 부여 기준 재작업 0.5
감사 로그 내려받기 이력(사용자, 일시, 사유, 건수) 기록 신규 1.0
테스트 시나리오 권한별·대량 건수 시나리오 추가 신규 1.0
관리자 매뉴얼 해당 절 갱신 재작업 0.5
합계 5.5
대안 내용 공수(인일) 일정 영향
A 전부 반영 5.5 통합 테스트 착수 2일 지연
B 내려받기만 반영, 사유 입력과 이력은 제외 3.0 영향 없음. 개인정보 내려받기 이력이 남지 않음
C 이번 범위에서 제외, 차기 이관 목록에 등록 0 영향 없음

B안처럼 통제 장치를 뺀 대안은 공수가 작아 채택되기 쉽습니다. 분석서에 빠지는 통제와 그 결과를 명시하고, 발주 측 정보보호 담당의 확인을 받도록 적어둡니다. 접근 기록과 내려받기 통제를 설계에 넣는 방법은 문서 보안 요구사항을 만족하는 시스템 설계 — 접근통제·워터마크·감사로그에서 다뤘습니다.

처리 절차와 권한을 정합니다

변경요청을 누가 검토하고 누가 승인하는지 정해두어야 합니다.

요청 접수 → 영향도 분석 → 검토 회의 → 승인/반려 → 기준선 갱신 → 이력 보관

규모에 따라 승인 권한을 나누는 방식도 있습니다. 일정 공수 이하는 PM 간 합의로 처리하고, 그 이상은 별도 협의체로 올리는 구성입니다. 모든 변경을 최고 단위에서 결정하면 절차가 병목이 됩니다.

아래는 승인 단계를 나눈 예시입니다. 기준 수치는 사업 규모에 맞춰 정해야 하며, 여기 적은 값은 형식을 보여주기 위한 것입니다.

등급 조건 (하나라도 해당하면 상위 등급) 결정 주체 회신 기한 처리 방식
간이 공수 1인일 이하, 일정 영향 없음, 데이터 구조·연동·권한 변경 없음 양측 PM 2영업일 관리대장 기록 후 진행
일반 공수 1인일 초과 10인일 이하, 주요 일정 영향 없음 양측 PM, 주간 회의 승인 5영업일 변경요청서와 영향도 분석서
중대 공수 10인일 초과, 납기·계약금액 영향, 데이터 구조·연동 대상·보안 요건 변경 변경 협의체 (양측 책임자) 10영업일 위 문서와 대안 비교, 계약 변경 검토

단건 기준만 두면 작은 요청을 여러 건으로 나눠 넣는 일이 생깁니다. 누적 기준을 함께 둡니다. 예를 들어 간이 처리 누적 공수가 계약 공수의 일정 비율에 이르면 이후 요청은 등급과 관계없이 협의체에 올린다는 식입니다.

승인 여부를 논의할 때 보는 기준도 미리 정해둡니다.

판단 기준 승인 쪽 보류·반려 쪽
필요성 법규 대응, 없으면 업무 수행이 불가능 있으면 편리한 수준, 대체 수단 존재
시점 해당 기능의 구현 착수 전 통합 테스트 착수 이후
영향 범위 한 화면, 한 모듈 안에서 끝남 데이터 구조나 연동 전문을 바꿈
재원 계약 변경 또는 다른 항목과 교환 가능 금액·기간 조정 수단이 없음
이관 가능성 운영 개시 전에 반드시 있어야 함 운영 개시 후 추가해도 문제없음

보류·반려 쪽이 많은 요청은 거절하기보다 차기 이관 목록으로 옮기는 편이 합의가 쉽습니다. 요청이 없던 일이 되는 것이 아니라 시점이 뒤로 가는 것이기 때문입니다.

승인된 변경은 기준선 문서에 반영하고 버전을 올린 뒤에 작업을 시작합니다. 급해서 작업을 먼저 시작해야 한다면 그 사실과 사후 처리 기한을 요청서에 적어둡니다. 기록 없이 먼저 만든 것은 나중에 변경으로 인정받기 어렵습니다.

요구사항과 산출물을 연결해둡니다

변경이 들어왔을 때 영향 범위를 빠르게 파악하려면, 요구사항 항목과 실제 산출물이 연결되어 있어야 합니다.

요구사항 ID → 화면 번호 → 개발 모듈 → 테스트 항목

이 연결이 있으면 "이 요구사항을 바꾸면 무엇이 영향을 받는가"를 추적할 수 있습니다. 없으면 매번 사람의 기억에 의존하게 되고, 누락이 생깁니다.

요구사항 추적표의 예시입니다. ID 체계는 설명용입니다.

요구사항 ID 요구사항 출처 화면 모듈·API 테이블 테스트 상태 변경 이력
REQ-ADM-012 회원 목록 조회 제안요청서 3.2 ADM-MEM-010 member/list MEMBER TC-ADM-031~034 구현 완료
REQ-ADM-012-1 회원 목록 엑셀 내려받기 CR-014 ADM-MEM-010 member/export MEMBER, AUDIT_LOG TC-ADM-035~037 설계 중 CR-014 승인으로 추가
REQ-ADM-013 회원 정보 수정 제안요청서 3.2 ADM-MEM-020 member/update MEMBER, MEMBER_HIST TC-ADM-040~044 테스트 중
REQ-IF-004 인사 시스템 조직 정보 연동 기술협상서 2.1 해당 없음 if/org-sync ORG, IF_LOG TC-IF-010~015 대기 규격서 미수령

운영할 때 지키는 규칙입니다.

  • 출처 열을 비워두지 않습니다. 출처가 제안요청서나 계약 문서가 아닌 행은 변경요청 번호가 있어야 합니다. 둘 다 없는 행이 기록 없이 들어온 범위입니다.
  • 요구사항 하나가 화면이나 테스트에 연결되지 않은 채 남아 있으면 누락입니다. 반대로 어떤 요구사항에도 연결되지 않은 화면은 근거 없이 만들어진 것입니다. 단계가 끝날 때마다 양방향으로 확인합니다.
  • 삭제된 요구사항은 행을 지우지 않고 상태를 바꿉니다. 지우면 왜 없어졌는지 설명할 수 없게 됩니다.
  • 변경이 승인되면 추적표를 먼저 고칩니다. 설계서와 코드를 고친 뒤에 추적표를 맞추려 하면 대개 맞추지 못합니다.

연결 관계는 완료 여부를 확인하는 데도 쓰입니다. 요구사항 목록과 산출물이 연결되어 있으면 어떤 항목이 아직 구현되지 않았는지, 어떤 항목의 테스트가 남았는지를 한눈에 볼 수 있습니다. 검수 단계에서 근거 자료로도 활용됩니다.

별도 도구가 없어도 됩니다. 표 하나로 관리해도 효과가 있습니다. 중요한 것은 요구사항이 추가되거나 변경될 때 이 표도 함께 갱신하는 것입니다. 갱신되지 않는 문서는 금방 신뢰를 잃고 아무도 보지 않게 됩니다.

반영하지 않기로 한 것도 기록합니다

반려된 요청을 기록에서 빼면 나중에 같은 요청이 다시 들어옵니다. 반려 사유와 함께 남겨두면 재논의 시간을 줄일 수 있습니다.

차기 사업으로 넘기기로 한 항목도 별도로 정리해둡니다. 프로젝트 종료 시점에 이 목록이 다음 사업의 요구사항 초안이 됩니다.

변경 관리대장으로 누적을 봅니다

개별 요청서와 별도로 모든 요청을 한 줄씩 적는 관리대장을 둡니다. 간이 처리한 요청과 구체화로 판정한 요청도 여기에는 들어갑니다.

번호 접수일 요청 요약 유형 등급 공수(인일) 일정 영향 결과 결정일 기준선 반영 버전
CR-013 05-08 목록 기본 정렬을 가입일 역순으로 구체화 간이 0.2 없음 반영 05-08 화면 설계서 v1.3
CR-014 05-12 회원 목록 엑셀 내려받기 추가 일반 5.5 2일 승인(A안) 05-19 요구사항 v1.2
CR-015 05-14 조직도 연동 대상에 계열사 추가 추가 중대 분석 중 분석 중 보류

주간 보고에는 이 대장에서 뽑은 네 가지 숫자를 넣습니다. 접수 건수, 승인된 누적 공수, 계약 공수 대비 비율, 기한을 넘긴 미결 건수입니다. 숫자가 매주 보고서에 올라가면 양측 책임자가 누적을 일찍 알게 되고, 프로젝트 말미에 한꺼번에 정산하자는 이야기가 나오지 않습니다.

대장에는 요청자 이름과 업무 내용이 들어갑니다. 조회 권한은 프로젝트 관계자로 한정하고, 종료 후 보관 기간과 폐기 방법은 계약의 자료 반환 조항에 맞춥니다.

4. 공공사업에는 별도의 제도가 있습니다

공공 소프트웨어사업이라면 과업 변경에 관한 법정 절차가 존재합니다. 아래 내용은 2026년 10월에 국가법령정보센터에서 확인한 조문을 기준으로 정리했습니다.

과업심의위원회

소프트웨어 진흥법은 국가기관등의 장이 소프트웨어사업 추진에 관한 사항을 심의하기 위해 과업심의위원회를 두도록 규정하고 있습니다.(소프트웨어 진흥법 제50조)

심의 대상은 과업내용의 확정, 그리고 과업내용 변경의 확정과 이에 따른 계약금액·계약기간 조정입니다. 국가기관등의 장은 특별한 사정이 없으면 심의 결과를 계약에 반영해야 하고, 사업자는 과업내용 변경으로 계약내용 변경이 필요할 때 위원회 개최를 요청할 수 있습니다(같은 조 제2항, 제3항).

위원회는 위원장을 포함해 5명 이상 10명 이내로 구성하며, 해당 기관 소속이 아닌 위원이 과반수여야 합니다.(소프트웨어 진흥법 시행령 제45조) 발주기관 내부 회의와 다른 점이 여기에 있습니다.

실무적으로 중요한 점이 있습니다. 과업 변경이 계약금액 조정의 근거가 될 수 있다는 것이 제도로 규정되어 있다는 사실입니다. 변경 사항을 기록으로 남기지 않으면 이 절차를 활용할 수 없습니다.

변경 절차와 기한

시행령과 고시에 정해진 흐름을 순서대로 옮기면 다음과 같습니다.

단계 내용 근거
요청 사업자가 과업변경요청서(별지 제13호서식)를 발주기관에 제출합니다. 공동수급체는 구성원 전체의 동의를 받아 대표구성원이 신청합니다 지침 제26조 제1항, 제2항
개최 요청 요청서를 받은 발주기관이 위원장에게 위원회 개최를 요청합니다. 발주기관 쪽에서 변경이 필요한 경우에도 계약상대자에게 통보하고 개최를 요청합니다 지침 제26조 제1항, 제3항
심의 변경 사유의 적정성, 계약금액·계약기간 조정의 적정성을 심의합니다. 재적위원 과반수 출석, 출석위원 과반수 찬성으로 의결합니다 지침 제27조 제1항, 시행령 제46조 제2항
결과 통보 발주기관은 개최 요청을 받은 날부터 14일 이내에 심의·의결 결과와 조치계획을 사업자에게 통보합니다. 추가 조사가 필요한 경우 등에는 사업자와 협의해 한 차례, 14일 이내로 연기할 수 있습니다 시행령 제47조 제5항
계약 변경 사업자는 조치계획을 근거로 계약변경을 요청할 수 있고, 발주기관은 요청받은 날부터 30일 이내에 조정해야 합니다 지침 제28조 제2항
재심의 통지 내용에 이의가 있으면 통지받은 날부터 14일 이내에 재심의를 요청할 수 있습니다 지침 제28조 제3항
기록 발주기관은 과업내용변경 관리내역서(별지 제15호서식)를 작성합니다. 계약금액을 조정하는 경우에는 반드시 작성해야 합니다 지침 제28조 제1항

근거 조문은 소프트웨어 진흥법 시행령(대통령령 제36338호, 2026. 6. 3. 시행)과 소프트웨어사업 계약 및 관리감독에 관한 지침(과학기술정보통신부고시 제2023-15호, 2023. 5. 15. 시행)입니다.

이 절차에서 수행 측이 놓치기 쉬운 것이 세 가지 있습니다.

  • 변경은 해당 부분을 이행하기 전에 절차를 마쳐야 합니다. 지침 제26조 제5항이 원칙으로 정하고 있고, 예외는 용역계약 일반조건을 준용해 인정합니다. 먼저 만들고 나중에 정산을 요청하는 순서는 원칙에서 벗어납니다.
  • 요청하지 않으면 열리지 않을 수 있습니다. 현행 지침 제24조의2는 사업자가 개최를 요청하지 않은 경우 발주기관이 위원회 개최를 하지 않을 수 있도록 하고 있습니다. 관계를 생각해 요청을 미루면 절차 자체가 시작되지 않습니다.
  • 입찰공고에 절차가 적혀 있는지 확인합니다. 시행령 제47조 제6항은 입찰공고에 사업자가 위원회 개최를 요청할 수 있다는 사실 등 과업 변경 절차를 명시하도록 하고 있습니다. 제안 단계에서 이 문구를 확인해두면 착수 후 절차를 꺼내기가 수월합니다.

무엇이 변경으로 인정됩니까

판단의 기준선은 계약 문서입니다. 지침은 계약 체결 시 발주기관과 계약상대자가 합의한 사업수행계획서나 과업내용서로 과업 내용이 구체화되면, 계약 체결 이후에는 그 문서의 내용을 확정된 과업내용으로 본다고 정하고 있습니다(지침 제25조 제5항). 사업수행계획서를 형식적으로 써서 내면 안 되는 이유입니다.

과업심의 가이드는 적정한 과업변경을 세 가지로 나눕니다.(공공소프트웨어사업 과업심의 가이드, 2021년 1월판)

유형 예시 처리
법령 개정 등 법·제도 변경에 따른 변경 법령상 업무처리 방식의 변경 위원회 심의, 계약기간·금액 조정 등 후속 조치
기술적·정책적 환경 변화에 따른 변경 별도 사업으로 하는 것보다 예산이 절감되거나 편의성·행정 효율이 개선되는 경우 위원회 심의, 후속 조치
발주기관과 사업자가 금액·기간 조정 없이 가능하다고 합의한 경미한 변경 사용자 인터페이스의 경미한 수정 위원회 심의 없이 진행 가능

같은 가이드는 경미한 변경이라도 합의한 내용을 양측 서명이 들어간 회의록이나 요구사항 추적표로 남기도록 권고합니다. 또 심의에서 확인할 사항으로 과업 변경인지 과업 구체화인지를 들고 있습니다. 앞에서 정리한 구체화와 추가의 구분이 공공사업에서는 심의 항목이 됩니다.

계약금액은 어떤 기준으로 조정합니까

지침은 변경되는 과업내용에 따른 계약금액 조정의 기준을 소프트웨어사업대가의 기준을 준용해 산정하도록 하고 있습니다(지침 제27조 제3항). 과업심의 가이드는 이를 「SW사업 대가산정 가이드」를 준용한다고 설명하며, 변경 규모는 원칙적으로 기능점수(FP)로 적고 기능점수 산출 내역서를 붙이도록 안내합니다.

실무에서 뜻하는 바는 이렇습니다.

  • 계약 때의 산출내역서가 금액 조정의 기준선이 됩니다. 가이드는 수·발주자가 합의한 기능점수로 산출내역서를 작성하고 이를 계약금액 조정의 기준선으로 쓴다고 설명합니다. 계약 시점에 기능 목록과 기능점수를 합의해두지 않으면 얼마나 늘었는지를 셀 단위가 없습니다.
  • 공수로만 관리한 변경 내역은 그대로 쓰기 어렵습니다. 변경 관리대장에 인일과 함께 영향받는 기능 수와 기능점수를 같이 적어두면 심의 자료로 옮기기 쉽습니다.
  • 전체 기능점수 안에서의 증감은 다르게 취급될 수 있습니다. 가이드(2021년 1월판)의 비용부담 권고안은 전체 기능점수를 초과하는 추가·변경은 발주기관이, 초과하지 않는 추가·변경은 사업자가 부담하는 것으로 제시합니다. 빠진 기능과 늘어난 기능을 함께 집계해야 하는 이유입니다.
  • 예산이 없으면 과업을 줄이는 방향으로 조정됩니다. 가이드는 계약금액 조정이 곤란한 경우 기존 계약기간과 계약금액 범위 안에서 과업을 재조정하는 방법을 함께 안내합니다.

대가산정 가이드는 KOSA가 공표하며, 이 글을 고친 시점(2026년 10월)에 협회 누리집에 게시된 가장 최근 전체 개정판은 2025년 개정판입니다.(SW사업 대가산정 가이드 2025년 개정판) 기능점수당 단가와 보정계수는 개정판마다 바뀌고 예산 편성 연도에 따라 적용 기준이 달라질 수 있으므로, 이 글에는 수치를 적지 않습니다. 산정할 때는 해당 사업에 적용되는 연도의 가이드를 직접 확인해야 합니다.

2027년 2월부터 달라지는 점

소프트웨어 진흥법 제50조는 2026년 8월 11일 개정되었고(법률 제21865호), 2027년 2월 12일부터 시행됩니다.(소프트웨어 진흥법, 2027. 2. 12. 시행본)

항목 현행 2027. 2. 12. 시행
심의 결과 반영 특별한 사정이 없으면 계약 등에 반영 반영에 필요한 재원을 확보할 의무 추가 (제2항)
위원회 개최 사업자가 요청하면 특별한 사정이 없는 한 수용 과업 변경 가능성이 높은 사업 등 대통령령으로 정하는 계약은, 공정이 설계 완료 등 대통령령으로 정하는 진도에 이르면 특별한 사정이 없는 한 개최 의무 (제4항 신설)
간소화·생략 법률에는 규정이 없고, 고시가 과업내용 확정 심의의 간소화 대상을 규정 과학기술정보통신부장관이 정하는 사업은 심의 절차를 간소화하거나 생략 가능 (제5항 신설)

적용 범위에 주의가 필요합니다. 부칙은 개정된 제2항, 제4항, 제5항을 법 시행 이후 체결하는 계약부터 적용하도록 정하고 있습니다. 2027년 2월 12일 전에 체결한 계약은 계속 사업이라도 종전 규정에 따릅니다.

의무 개최 대상이 되는 계약의 범위와 "설계 완료 등"의 구체적 진도는 대통령령에 위임되어 있습니다. 이 글을 고친 시점의 시행령에는 해당 내용이 아직 반영되어 있지 않으므로, 하위 법령이 정비되면 다시 확인해야 합니다.

이 장은 법령과 공식 가이드의 내용을 실무 관점에서 옮긴 것이며 법률 자문을 대신하지 않습니다. 법령과 고시는 개정되므로 실제 사업에는 국가법령정보센터의 현행 조문과 발주기관의 계약 조건을 확인해 적용하시기 바랍니다.

민간 계약에서는 무엇이 다릅니까

과업심의위원회는 국가기관등이 발주하는 사업에 적용되는 제도입니다. 민간 계약에는 같은 절차가 없고, 당사자가 계약서에 적은 내용이 기준이 됩니다.

구분 공공 계약 민간 계약
변경 절차의 근거 소프트웨어 진흥법 제50조, 시행령, 고시 계약서의 변경 조항. 없으면 그때마다 협의
판단 주체 외부 위원이 과반수인 과업심의위원회 당사자가 정한 협의체 또는 양측 책임자
회신 기한 요청받은 날부터 14일 (한 차례 연기 가능) 계약에 적은 기한. 적지 않으면 기한 없음
금액 조정 기준 소프트웨어사업대가 기준 준용, 기능점수 중심 계약에 적은 단가(인월 단가, 기능 단가 등)
기준선 문서 과업내용서, 사업수행계획서, 산출내역서 계약서에 첨부하거나 인용한 문서
재원 편성된 예산 범위. 조정이 곤란하면 과업 재조정 당사자 합의

민간 계약이라고 해서 법의 적용이 전혀 없는 것은 아닙니다. 소프트웨어 진흥법 제38조는 하도급을 포함한 소프트웨어사업 계약 전반에 공정계약의 원칙을 두고 있습니다. 계약 내용이 한쪽에 현저하게 불공정한 경우로서, 계약 체결 이후 과업내용의 변경에 따른 계약금액과 계약기간의 변경을 상당한 이유 없이 인정하지 않거나 그 부담을 상대방에게 떠넘기는 경우에는 그 부분에 한해 무효로 한다고 정합니다(제38조 제3항 제1호). 다만 개별 조항이 여기에 해당하는지는 사안마다 판단이 필요한 문제입니다.

민간 사업에서 가져올 만한 것은 구조입니다. 핵심은 과업 변경을 판단하는 별도의 협의 창구를 두는 것입니다. PM 간 협의만으로 처리하면 관계가 악화되기 쉽습니다. 양측 상위 책임자가 참여하는 정기 협의체를 두면 개별 사안이 감정 문제로 번지는 것을 줄일 수 있습니다. 공공 제도의 회신 기한, 서면 통지, 관리내역서 작성은 민간 계약의 변경 조항에 그대로 옮겨 쓸 수 있는 장치입니다.

5. 계약 단계에서 정리해둘 것들

변경관리는 프로젝트 중에 시작하는 것이 아니라 계약에서 시작됩니다.

범위를 문서로 특정합니다

계약서에 "요구사항 정의서에 따름"이라고만 적혀 있으면, 그 문서의 모호함이 그대로 계약의 모호함이 됩니다.

  • 범위에 포함되는 것을 목록으로 명시합니다
  • 포함되지 않는 것도 명시합니다. 이 항목이 의외로 중요합니다
  • 산출물 목록과 각각의 완료 기준을 정합니다
  • 검수 기준과 절차를 정합니다

"제외 사항"을 적는 것을 꺼리는 경우가 있는데, 명시해두면 오히려 양쪽 모두에게 안전합니다.

전제 조건을 적습니다

수행 측의 일정 산정은 여러 전제 위에 서 있습니다. 그 전제가 깨지면 일정도 달라집니다.

  • 발주 측이 제공하기로 한 자료와 제공 시점
  • 연동 대상 시스템의 규격서 제공 여부
  • 테스트 환경과 계정 제공 시점
  • 의사결정 소요 기간
  • 현업 인터뷰 가능 일정

이런 전제를 계약 문서에 남겨두면, 지연이 발생했을 때 원인을 확인할 수 있습니다. 적어두지 않으면 모든 지연이 수행 측의 책임처럼 보이게 됩니다.

검수 기준을 구체적으로 적습니다

범위 논쟁이 가장 격해지는 시점은 검수 단계입니다. 기준이 모호하면 여기서 한꺼번에 터집니다.

  • 무엇을 확인해 합격·불합격을 판정하는가
  • 검수 기간은 얼마이고, 그 안에 회신이 없으면 어떻게 되는가
  • 결함의 등급을 어떻게 나누고, 어느 등급까지 해결되어야 합격인가
  • 재검수 절차와 횟수 제한이 있는가
  • 검수 이후 발견된 결함은 하자보수로 처리하는가

결함 등급 구분이 특히 중요합니다. 업무가 불가능한 오류와 화면 문구가 어색한 것을 같은 기준으로 다루면 합의가 되지 않습니다. 등급별로 판정 기준을 나눠두면 논의가 정리됩니다.

변경 절차 자체를 계약에 넣습니다

  • 변경요청 접수 방법과 양식
  • 영향도 회신 기한
  • 승인 권한과 절차
  • 계약금액·기간 조정 기준
  • 협의 결렬 시 처리 방법

이 조항들은 분쟁을 막기 위한 것이 아니라 논의를 빠르게 하기 위한 것입니다. 절차가 정해져 있으면 매번 방법부터 협의할 필요가 없습니다.

이 가운데 가장 자주 비어 있는 것이 금액 조정 기준입니다. 변경이 생긴 뒤에 단가를 협상하면 변경의 타당성과 단가가 한꺼번에 다퉈집니다. 계약 때 방식을 골라 적어둡니다.

방식 계약에 적어둘 것 맞는 경우 주의할 점
인월 단가 등급별 인월 단가, 공수 산정 방법 민간 계약, 변경 내용이 다양한 사업 공수 추정 자체가 다툼이 됩니다. 작업 분해 내역을 붙입니다
기능 단위 단가 기능점수 또는 화면·연동 건당 단가, 산정 규칙 공공 계약, 기능 수가 명확한 사업 성능 개선, 이관처럼 기능 수로 잡히지 않는 작업은 따로 정합니다
범위 교환 추가 항목과 같은 규모의 기존 항목을 제외하는 절차 총액과 납기가 고정된 사업 제외한 항목은 차기 이관 목록에 올려 기록을 남깁니다
예비 공수 계약 금액에 포함한 변경 대응 공수와 차감 규칙 요구사항 확정도가 낮은 초기 사업 소진 현황을 주기적으로 공유하지 않으면 소진 시점에 다툽니다

공공 계약에서는 금액 조정 방식이 법령과 계약 조건으로 정해지는 부분이 크므로, 위 표는 주로 민간 계약의 조항을 설계할 때 참고할 내용입니다.

기간 조정도 같은 조항에서 다룹니다. 변경이 승인되면 납기가 어떤 계산으로 달라지는지, 발주 측 회신이 기한을 넘기면 그 일수를 어떻게 처리하는지를 적습니다. 금액은 조정되었는데 납기는 그대로인 상태가 가장 흔한 누락입니다.

6. 자주 나오는 질문

요구사항을 어느 수준까지 상세하게 써야 합니까

계약 단계에서 모든 화면의 모든 항목을 확정하기는 어렵습니다. 현실적인 기준은 공수 산정이 가능한 수준입니다.

기능 단위로 다음 정보가 있으면 대체로 산정이 가능합니다.

  • 어떤 데이터를 다루는가
  • 화면이 몇 개 필요한가
  • 외부 연동이 있는가
  • 권한 구분이 있는가
  • 특별한 처리 규칙이 있는가

이보다 상세한 내용은 착수 후 분석·설계 단계에서 구체화하되, 그 구체화가 어디까지 원래 범위인지를 정해두면 됩니다.

소규모 변경까지 전부 문서로 해야 합니까

모든 변경에 절차를 걸면 프로젝트가 느려집니다. 기준을 두는 편이 낫습니다.

  • 문구 수정, 화면 배치 조정처럼 공수 영향이 거의 없는 것은 간이 처리
  • 일정 공수 이상, 또는 데이터 구조·연동에 영향을 주는 것은 정식 절차

다만 간이 처리한 것도 기록은 남겨야 합니다. 개별로는 작아도 누적되면 무시할 수 없는 양이 됩니다. 나중에 "작은 것들이 계속 쌓였다"는 사실을 보여줄 근거가 됩니다.

이미 범위가 많이 늘어난 상태라면 어떻게 합니까

먼저 현재 상태를 정리하는 작업이 필요합니다.

  1. 계약 시점의 범위와 현재 진행 중인 범위를 나란히 정리합니다
  2. 차이 항목을 하나씩 확인하고 추가된 경위를 확인합니다
  3. 해석 차이인지 실제 추가인지 구분합니다
  4. 남은 일정과 공수를 다시 산정합니다
  5. 이 내용을 근거로 협의합니다

이 작업 없이 "일정이 부족하다"고만 말하면 설득력이 없습니다. 무엇이 얼마나 늘었는지를 항목으로 보여주어야 논의가 시작됩니다.

기록이 없는 상태에서 시작한다면 회의록, 메일, 메신저 대화, 저장소의 커밋 이력에서 요청 시점과 요청자를 거꾸로 찾아 관리대장을 채웁니다. 근거를 찾지 못한 항목은 따로 표시해 두고 협의 자료에서는 근거가 있는 항목과 섞지 않습니다. 정리한 날을 새 기준선으로 합의하고 그 뒤로는 절차를 적용합니다.

금액도 기간도 조정할 수 없다면 어떻게 합니까

총액과 납기가 고정된 사업에서는 변경을 받는 방법이 범위 안에서의 교환밖에 없습니다.

  • 추가할 항목과 비슷한 규모의 항목을 기준선에서 빼고, 뺀 항목을 차기 이관 목록에 올립니다
  • 운영 개시에 꼭 필요한 것과 개시 후에 넣어도 되는 것으로 나눠 단계를 분리합니다
  • 교환할 항목이 없으면 그 사실을 협의체 회의록에 남깁니다

공공사업의 과업심의 가이드도 계약금액 조정이 곤란한 경우 기존 계약기간과 계약금액 범위 안에서 과업을 재조정하는 방법을 안내합니다. 어느 경우든 무엇을 빼고 무엇을 넣었는지를 문서로 남기는 것이 요점입니다. 남기지 않은 교환은 검수 단계에서 미구현 항목으로 돌아옵니다.

발주 측 입장에서는 무엇을 준비해야 합니까

수행 측에만 관리를 요구하는 것으로는 부족합니다. 발주 측에서 준비할 것들입니다.

  • 의사결정 창구 단일화 — 여러 부서가 각자 요구하면 수행 측은 무엇을 따라야 할지 알 수 없습니다
  • 내부 합의 선행 — 부서 간 이견은 수행 측에 전달하기 전에 정리하는 편이 낫습니다
  • 자료 제공 일정 확보 — 요청한 자료가 늦어지면 일정이 밀립니다
  • 검수 인력 확보 — 검수가 밀리면 다음 단계도 함께 밀립니다

7. 착수 전 점검 목록

범위 확정

  • 요구사항 문서에서 포괄 동사·정도 부사·범위 미지정 표현을 걸러냈는가
  • 각 기능의 공수 산정이 가능한 수준까지 구체화되었는가
  • 범위에 포함되지 않는 항목이 명시되어 있는가
  • 산출물 목록과 완료 기준이 정의되어 있는가
  • 검수 기준과 절차가 합의되어 있는가

사전 확인

  • 이해관계자와 승인 권한자를 식별했는가
  • 연동 대상 시스템의 규격서를 확보했는가
  • 데이터 이관 대상의 실제 샘플을 확인했는가
  • 발주 측 제공 자료와 제공 시점이 문서화되어 있는가

변경 절차

  • 기준선 문서와 확정 시점이 기록되어 있는가
  • 변경요청 양식과 접수 경로가 정해져 있는가
  • 영향도 산정 항목에 재작업 비용이 포함되어 있는가
  • 승인 권한이 규모별로 구분되어 있는가
  • 반려·보류 항목도 기록으로 남기는가
  • 계약금액·기간 조정 기준이 계약에 명시되어 있는가
  • 구체화와 추가를 가르는 기준을 착수 회의에서 합의하고 회의록에 남겼는가
  • 영향도 회신 기한과 승인 결정 기한이 정해져 있는가
  • 간이 처리 요청의 누적 기준이 있는가
  • 요구사항 추적표의 모든 행에 출처가 적혀 있는가
  • 변경 관리대장의 누적 수치를 주간 보고에 넣기로 했는가

공공사업의 경우

  • 과업심의위원회 운영 방식을 확인했는가
  • 과업 변경 시 심의 요청 절차를 알고 있는가
  • 입찰공고와 제안요청서에 과업 변경 절차가 명시되어 있는지 확인했는가
  • 사업수행계획서와 과업내용서가 변경 판단의 기준선이 될 만큼 구체적인가
  • 산출내역서에 기능 목록과 기능점수가 합의되어 있는가
  • 계약 체결일이 2027년 2월 12일 이후인지, 개정 규정의 적용 대상인지 확인했는가
  • 관련 법령과 지침의 최신 내용을 확인했는가

마치며

범위 관리의 목적은 변경을 막는 것이 아닙니다. 프로젝트가 진행되면 상황은 바뀌고, 더 나은 방법이 보이기도 합니다. 변경 자체는 자연스러운 일입니다.

문제가 되는 것은 변경이 기록되지 않고 스며드는 경우입니다. 아무도 언제 무엇이 늘었는지 모르는 상태로 끝나면, 남는 것은 서로에 대한 불신뿐입니다.

요구사항의 모호한 표현을 미리 걷어내고, 기준선을 확정하고, 변경을 문서로 받아 영향도와 함께 판단하는 것. 각각은 번거로운 절차처럼 보이지만, 프로젝트 후반의 소모를 줄이는 가장 확실한 방법입니다.

저희는 공공·민간 영역에서 시스템 구축 사업을 수행해왔습니다. 프로젝트 범위 정의나 요구사항 정리 단계에서 도움이 필요하시면 편하게 문의해주세요.

함께 보면 좋은 글

참고 자료