외주 개발 추가 요청 관리: 버그 수정과 과업 변경을 나누고 서면으로 승인하는 법

진행 중 쏟아지는 요청, 막을 게 아니라 통제할 대상입니다

외주 개발이 중반에 접어들면 발주자 쪽에서 자연스럽게 요청이 늘어납니다. 화면을 직접 보면 생각이 구체화되고, 내부 사용자와 임원의 의견이 더해지기 때문입니다. 요청 자체는 문제가 아닙니다. 문제는 그 요청이 범위·공수·비용·납기에 어떤 영향을 주는지 아무도 산정하지 않은 채 "이 정도는 당연히 포함"이라는 말로 쌓여갈 때 생깁니다.

이렇게 통제되지 않은 범위 변경을 스코프 크리프라고 부릅니다. 미국 프로젝트관리협회(PMI)의 Pulse of the Profession 2018 조사에서는 지난 12개월간 완료된 프로젝트의 절반이 넘는 비율이 스코프 크리프를 경험했고, 이는 5년 전보다 높아진 수치로 보고됐습니다. 즉 변경은 특수한 사고가 아니라 거의 모든 프로젝트에서 일어나는 기본값에 가깝습니다. 그래서 요청을 막는 규칙이 아니라, 요청을 받아들이되 통제 가능한 상태로 관리하는 절차가 필요합니다.

1단계: 모든 요청을 '버그 수정'과 '과업 변경'으로 먼저 나눕니다

변경관리의 출발점은 분류입니다. 들어온 요청이 둘 중 무엇인지부터 판단해야 비용과 책임의 주체가 갈립니다.

• 버그 수정: 이미 합의한 과업 내용대로 동작해야 하는데 그렇지 않은 경우입니다. 로그인 후 특정 버튼이 눌리지 않는다거나, 합의한 계산식과 다른 금액이 표시되는 경우가 여기 해당합니다. 원칙적으로 공급자가 계약 범위 안에서 바로잡아야 할 사항입니다.
• 과업 변경: 합의한 적 없는 기능·화면·연동을 새로 더하거나, 합의한 동작의 조건 자체를 바꾸는 경우입니다. "목록에 엑셀 내보내기도 넣어 주세요", "결제 수단을 하나 더 붙여 주세요" 같은 요청이 여기 해당합니다. 이건 수정이 아니라 추가 과업입니다.

판단이 애매한 요청도 많습니다. 이때 기준이 되는 문서가 바로 과업내용서입니다. 과학기술정보통신부가 소프트웨어진흥법 시행에 맞춰 배포한 SW분야 표준계약서는, 발주자가 공급자와 합의한 과업의 내용과 범위를 명확히 기재한 과업내용서를 발급해 과업 내용을 확정하도록 하고 있습니다. 어떤 요청이 범위 안인지 밖인지 다툼이 생기면, 기억이나 구두 약속이 아니라 이 문서에 적힌 내용이 기준선 역할을 합니다. 계약 초기에 과업내용서를 구체적으로 작성해 두는 일이 이후 모든 변경 판단의 토대가 됩니다.

2단계: 요청마다 범위·공수·비용·납기 영향을 산정합니다

과업 변경으로 분류된 요청은 수용 여부를 정하기 전에 영향부터 평가합니다. 개발을 모르는 발주자라도 공급자에게 다음 네 가지를 묻고 답을 문서로 받으면 됩니다.

• 범위 영향: 이 요청이 기존 어떤 기능·화면과 맞물리는지, 손대야 할 지점이 어디까지 번지는지.
• 공수 영향: 추가로 필요한 작업량과 투입 인력.
• 비용 영향: 추가 공수에 따른 비용 발생 여부와 규모.
• 납기 영향: 기존 일정이 밀리는지, 밀린다면 어느 작업이 뒤로 가는지.

작은 요청이라도 이 네 가지를 한 줄씩 적게 하는 것이 핵심입니다. "간단한 건데요"라는 말이 모여 일정을 무너뜨리는 경우가 많기 때문입니다. 영향이 거의 없는 요청이라면 평가 결과에 "영향 미미, 현 일정 내 수용"이라고 적으면 됩니다. 평가 자체를 생략하지 않는 것이 통제의 시작입니다.

3단계: 과업내용서를 기준선으로 서면 승인하고 기록합니다

영향 평가가 끝나면 수용·보류·거절을 결정하고, 수용하기로 한 변경은 반드시 서면으로 확정합니다. 앞서 언급한 표준계약서도 계약 내용과 과업의 변경은 상호 합의하여 서면으로 변경하도록 규정하고, 확정된 과업내용서를 토대로 계약금액·계약기간 등 조건을 검토해 필요하면 계약을 변경하도록 정하고 있습니다. 또한 공급자가 계약금액이나 계약기간 등 조건의 조정을 요청할 수 있도록 하고 있습니다. 변경이 비용과 일정에 영향을 줄 때 이를 조정하는 길을 계약 차원에서 열어 둔 것입니다.

실무에서는 변경요청서(또는 변경관리대장)를 한 장으로 운영하면 충분합니다. 다음 항목을 담으면 됩니다.

• 요청 일자와 요청자, 요청 내용
• 버그 수정 / 과업 변경 분류
• 범위·공수·비용·납기 영향 평가 결과
• 수용 / 보류 / 거절 결정과 사유
• 양측 승인 표시(결재, 서명, 또는 이메일 회신)

한국 스타트업 현장에서는 메신저로 요청이 오가다 기록이 흩어지는 일이 흔합니다. 메신저로 논의하더라도 확정은 이메일 회신이나 공유 문서의 승인란처럼 되짚을 수 있는 형태로 남기는 습관이 중요합니다. 이렇게 쌓인 기록은 정산 시점의 분쟁을 줄이고, 다음 프로젝트의 견적 근거로도 쓰입니다.

마무리: 변경을 환영하되 절차로 받으세요

좋은 변경관리는 요청을 거절하는 기술이 아니라, 요청을 받아들일 수 있는 형태로 바꾸는 절차입니다. 분류하고, 영향을 평가하고, 서면으로 확정하는 이 세 단계가 돌아가면 발주자는 추가 요청을 자유롭게 꺼내면서도 비용과 일정이 어디로 가는지 늘 파악할 수 있습니다.

FIRSTPIP은 SI·업무 시스템 구축 과정에서 과업내용서 기준선과 변경관리대장을 함께 운영하는 방식으로 프로젝트를 진행합니다. 범위 변경이 잦을 수밖에 없는 ERP·관리시스템 구축을 앞두고 있다면 SI 개발 서비스에서 진행 방식을 확인해 보시기 바랍니다.