외주 분쟁의 80%는 변경관리에서: 우리가 합의한 5단계

저희가 7년 동안 30개가 넘는 프로젝트를 마무리하면서 분쟁이 발생한 자리를 정리해보니, 다수가 한 가지 단계에서 시작됐습니다. 변경관리. 다시 말해 “이것만 하나 더 추가해주세요” 가 어떻게 처리되는가의 문제였습니다.

기능 누락이나 디자인 어긋남, 일정 지연 모두 그 자체가 분쟁의 직접 원인은 아닙니다. 변경이 발생한 뒤에 그 변경이 견적·일정·범위 중 어디에 어떤 영향을 주는지 합의되지 않았을 때, 마지막에 “왜 이렇게 늘어났느냐” 의 다툼이 시작됩니다.

오늘은 변경관리 5단계를 어떻게 운영하면 견적과 일정이 어긋나지 않는지, 계약서에 들어가야 할 5줄짜리 조항 샘플, 그리고 발주사 분이 외주사 미팅에서 직접 확인하실 3가지를 정리해드립니다. 외주 견적서 항목 보는 법 글을 먼저 보셨다면 흐름이 더 잘 보이실 겁니다.

”추가는 해드릴게요” 한마디로 일어나는 일 3가지

변경관리 절차가 명문화되어 있지 않은 프로젝트에서 가장 자주 마주치는 사고는 다음 세 가지입니다.

첫째, 견적이 부풀어 오릅니다. 개발 중간중간 “이것만 하나 더”, “이것도 함께” 가 누적되면 마지막에 견적이 처음보다 20~40% 늘어나 있는 일이 흔합니다. 추가될 때마다 영향도가 계산되지 않으면 총합을 발주사 분이 미리 추정하실 방법이 없습니다.

둘째, 기록이 없습니다. 메신저 대화 한 줄로 시작된 변경 요청은 시간이 지나면 누가 언제 무엇을 요청했는지 추적이 어렵습니다. 결과적으로 “이건 원래 들어가는 거 아니었습니까?” 와 “그건 추가로 요청하셔서 비용이 발생합니다” 의 다툼이 됩니다. 어느 쪽이 맞든, 분쟁 자체가 비용입니다.

셋째, 일정이 어긋납니다. 변경 하나가 일정에 어떻게 반영되는지 합의되지 않으면, 출시일이 임박해서야 “이 기능 때문에 2주 더 필요합니다” 가 등장합니다. 마케팅 일정과 매출 계획이 그 자리에서 흔들립니다.

이 세 가지를 동시에 해결하는 절차가 변경관리 5단계입니다. 변경 통제는 PMI도 핵심 영역으로 다루는 표준 절차로, 통합 변경 통제(Integrated Change Control) 라는 이름으로 정의되어 있습니다.

변경관리 5단계 운영법

저희가 모든 프로젝트에 명문화해두는 절차는 다음 다섯 단계입니다. 복잡한 도구는 필요하지 않습니다. Slack 한 채널과 WBS 한 장이면 충분합니다.

1. 변경 요청 — 메신저 한 줄도 양식으로

변경 요청은 반드시 양식이 있는 글로 시작해야 합니다. “회원가입에 토스 본인인증을 추가하고 싶습니다, 출시 전 적용 희망” 정도로 충분합니다. 누가, 언제, 무엇을, 왜 요청했는지가 한 곳에 남아 있어야 다음 단계가 가능합니다.

저희는 Slack 전용 채널에 변경 요청 템플릿 4줄을 고정해 두고, 발주사 분이 그 양식대로만 적어주시면 그다음 단계가 자동으로 시작되도록 운영합니다. “말로만 부탁드린” 변경은 단계 1을 통과하지 않은 것으로 간주합니다.

2. 영향도 회신 — 48시간 안에 숫자로

외주사는 요청을 받은 뒤 48시간 안에 영향도를 회신해야 합니다. 영향도에는 다음 네 가지가 반드시 들어갑니다.

• 영향받는 WBS 행 (예: 1.4 본인인증 연동)
• 추가/감소 공수 (예: +1.5MD)
• 일정 변화 (예: 마일스톤 2 일정 +1일)
• 비용 변화 (예: +X만 원)

회신이 늦거나 영향도가 모호하면 그 자체가 다음 분쟁의 씨앗입니다. 48시간 SLA는 외주사의 기본 약속이고, 발주사 분이 첫 미팅에서 확인하실 핵심 항목입니다.

3. 발주사 승인 — 메신저 한 줄도 서면

영향도를 받으신 발주사 분은 진행 여부를 서면으로 회신하셔야 합니다. 메신저 한 줄도 서면입니다. “+1.5MD, +X만 원으로 진행 부탁드립니다” 정도면 충분합니다.

말로 “그럼 진행해주세요” 만 오간 변경은 단계 3을 통과하지 않은 것이라 보십시오. 분쟁이 발생하면 그 변경에 대해서는 외주사가 청구 근거를, 발주사 분이 거부 근거를 잃습니다. 양쪽 모두 손해입니다.

4. 신규 행 추가 — 기존 행은 절대 수정하지 않습니다

승인된 변경은 WBS의 신규 행으로 추가합니다. 기존 행을 수정하지 않습니다. 예를 들어 “1.4 본인인증 NICE 연동” 행은 그대로 두고, “1.7 본인인증 토스 추가 (1.5MD, 2026-05-13 추가, 요청자: 발주사 김XX)” 행을 새로 만듭니다.

기존 행을 수정하면 변경 이력이 사라집니다. 누가 언제 무엇을 추가했는지가 한 곳에 남아 있어야, 3개월 뒤에 누군가 “이건 처음부터 있던 거 아닌가요?” 라고 물어도 즉시 답이 나옵니다. 좋은 WBS는 변경 이력 그 자체입니다. WBS의 자세한 양식은 WBS란 무엇인가 글에 7컬럼 양식과 함께 정리해 두었습니다.

5. 회고 반영 — 다음 데모에서 결과 확인

변경이 반영되면 그다음 데모에서 결과를 함께 확인합니다. 추가된 기능이 의도대로 동작하는지, 다른 기능에 부작용은 없는지, 일정이 회신한 대로 늘어났는지를 발주사 분이 직접 보십니다.

회고 단계가 빠지면 “추가는 했는데 동작이 이상하다” 의 잔불이 마지막 검수까지 남습니다. 데모는 변경관리의 마지막 검증대입니다. 주 단위 데모 흐름을 어떻게 잡는지는 후속 글에서 따로 정리해드릴 예정입니다.

5단계 한눈에 비교

각 단계가 빠졌을 때 어떤 사고가 발생하는지를 표로 정리하면 다음과 같습니다.

변경관리 5단계 — 단계별 산출물과 누락 시 사고

단계	산출물	누락 시 사고
1. 요청	양식 있는 서면 요청	”말로만 부탁드린” 변경 누적
2. 영향도	WBS·공수·일정·비용 4항목	총 견적 예측 불가
3. 승인	발주사 서면 회신	양측 모두 청구·거부 근거 상실
4. 신규 행	WBS 행 + 요청자·일자	”원래 있던 기능 아닌가요?” 분쟁
5. 회고	다음 데모에서 검증	”추가는 했는데 동작 이상” 잔불

계약서·견적서 부속 문서에 넣을 5줄 샘플

위 5단계는 다음과 같이 5줄 정도면 문서로 명문화됩니다. 발주사 분이 계약서 또는 견적서 부속 문서에 그대로 가져다 쓰셔도 좋은 권장 문구입니다.

변경관리 절차
1. 모든 변경 요청은 지정된 채널(Slack)에 양식에 따라 서면으로 한다.
2. 외주사는 요청 접수 후 48시간 이내에 영향받는 WBS 행, 공수, 일정,
   비용의 변화를 회신한다.
3. 발주사는 회신을 받은 뒤 서면(메신저 포함)으로 진행 여부를 승인한다.
4. 승인된 변경은 WBS에 신규 행으로 추가하며, 기존 행은 수정하지 않는다.
5. 변경 결과는 다음 정기 데모에서 양측이 함께 검증한다.

위 5줄에 가까운 변경 절차가 어딘가에 합의되어 있다면 분쟁 가능성이 크게 낮아집니다. 계약서, 견적서 부속 문서, 프로젝트 킥오프 회의록 어디든 좋습니다. 외주사가 이런 절차를 명문화하기를 망설인다면 절차 자체에 자신이 없다는 신호로 보셔도 됩니다.

발주사가 미팅에서 확인할 3가지

외주사를 처음 만나신 미팅에서 다음 세 가지를 직접 물어보십시오. 30분 안에 변경관리의 성숙도를 확인하실 수 있습니다.

첫째, “변경 요청 양식이 있습니까?” 라고 물어보십시오. 양식이 있는 회사라면 즉시 보여줄 수 있습니다. 없거나 “그때그때 협의하면 된다” 고 답한다면 단계 1이 없는 회사라고 이해하시면 됩니다.

둘째, “영향도 회신은 며칠 안에 받을 수 있습니까?” 라고 물어보십시오. “최대한 빨리 드린다” 같은 답이라면 SLA가 없다는 뜻입니다. 48시간, 길어도 72시간 안에 회신을 약속하는 회사가 안전합니다.

셋째, “변경 이력은 어디에 남습니까?” 라고 물어보십시오. WBS 신규 행 또는 별도 변경 로그 파일을 보여줄 수 있어야 합니다. “메신저 검색하면 나온다” 가 답이라면 단계 4가 없는 회사입니다.

이 세 가지가 모두 명확한 외주사라면 변경관리 분쟁이 발생할 확률은 크게 낮아집니다. 7가지 항목을 한 번에 점검하고 싶으시다면 IT 외주 맡기기 전에 꼭 확인해야 할 7가지 글도 함께 보시면 좋습니다.

마지막으로

변경관리는 외주사를 위한 보호 장치가 아닙니다. 발주사 분을 위한 장치입니다. 절차가 없으면 한 줄 메신저로 추가된 기능 하나가 마지막에 견적과 일정을 동시에 흔들고, 책임 소재까지 흐려집니다. 5단계와 5줄짜리 계약 조항만으로 그 흔들림이 거의 사라집니다.

샐링잇은 모든 프로젝트에서 Slack 전용 채널, 48시간 영향도 회신, WBS 신규 행 추가 흐름을 함께 운영합니다. 다음 글에서는 위시켓과 크몽 두 플랫폼이 발주사 입장에서 어떻게 다른지를 정산·중재·산출물 기준으로 풀어드릴 예정입니다.

자주 묻는 질문

Q. 변경관리 5단계는 누가 작성하고 운영하나요?

외주사가 운영합니다. 발주사 분은 변경 요청을 양식에 따라 보내주시고, 영향도 회신을 검토한 뒤 서면으로 승인 여부만 회신해주시면 됩니다. 신규 행 추가와 회고 일정은 외주사가 책임지고 진행합니다.

Q. 영향도 회신이 48시간 안에 안 오면 어떻게 해야 하나요?

계약서에 48~72시간 SLA를 명시해두시는 것이 가장 깔끔한 해결책입니다. 회신이 늦어지면 그 자체가 다음 변경 요청을 지연시키기 때문에, 계약서에 "지연 시 다음 마일스톤 일정 연장" 같은 조항을 함께 넣어두시는 분도 많습니다.

Q. 메신저 대화는 정말 "서면" 으로 인정되나요?

국내 법원 판례상 Slack·카카오톡·이메일 같은 전자 메시지는 합의의 증거로 인정됩니다. 다만 "그럼 진행해주세요" 처럼 모호한 표현보다 "+1.5MD, +30만 원으로 진행 동의합니다" 같이 금액·범위가 명시된 메시지가 더 강한 증거가 됩니다.

Q. 작은 수정도 모두 5단계를 거쳐야 하나요?

실무적으로는 "공수 0.5MD 미만 / 일정·비용 영향 없음" 같은 사소한 수정은 단계 2(영향도) 와 3(승인) 을 간소화해 한 줄 합의로 끝내는 경우가 많습니다. 다만 어떤 기준으로 간소화하는지를 계약 초기에 합의해 두는 것이 좋습니다.

Q. 5단계를 도입했는데도 분쟁이 발생하면 어떻게 하나요?

5단계의 산출물(요청 메시지, 영향도 회신, 승인 메시지, WBS 신규 행 기록) 이 모두 남아 있으면 분쟁 자체가 분쟁이 아닙니다. 어느 단계에서 어떻게 합의됐는지가 추적 가능하기 때문입니다. 5단계는 분쟁을 막는 장치가 아니라, 발생해도 즉시 해결할 수 있게 만드는 장치입니다.