고객의 변경 요청에는 곧바로 “됩니다” 또는 “안 됩니다”라고 답하지 않는 편이 좋습니다. 먼저 해결하려는 문제를 확인하고, 기존 합의에서 달라지는 범위와 비용·일정·책임을 계산한 뒤, 선택지와 수용 기준을 함께 승인해야 해요. 승인 전에는 착수하지 않고 완료 후에는 합의한 기준으로 결과를 확인하는 것이 핵심입니다.
실무 흐름은 요청 → 문제 확인 → 선택지와 트레이드오프 → 변경 승인 → 수용 기준 → 사후 검증으로 잡을 수 있습니다. 이 순서를 문서로 남기면 고객의 사업 맥락과 공급사의 전문성을 함께 반영하면서도, 구두 요청이 무제한 재작업으로 이어지는 일을 줄일 수 있어요.
무조건 수용과 일방 거절 사이에 변경 관리가 있습니다
좋은 파트너십은 고객 요청을 그대로 수행하는 관계도, 공급사가 전문성을 앞세워 요청을 일방적으로 막는 관계도 아닙니다. 고객은 사업 목표와 현장 제약을 설명하고, 공급사는 구현·운영 영향과 대안을 제시합니다. 양쪽이 영향을 확인한 뒤 책임 있는 승인자가 선택하는 구조가 필요해요.
| 판단 방식 | 요청을 다루는 방법 | 전문가의 역할 | 관계와 결과 |
|---|---|---|---|
| 무조건 수용 | 요청 문장대로 바로 착수 | 실행만 담당 | 빠르게 보이지만 범위·비용·품질 책임이 흐려질 수 있음 |
| 일방 거절 | 기존 계약 범위만 반복해 설명 | 방어 논리만 제시 | 변경 위험은 막지만 고객의 실제 문제를 놓칠 수 있음 |
| 공동 변경 관리 | 문제를 확인하고 대안별 영향을 비교한 뒤 승인 | 질문, 영향 분석, 선택지 제안, 검증 | 상호 존중을 유지하면서 책임과 기대 결과를 명확히 함 |
전문가의 제안은 고객의 판단을 대신하는 결론이 아닙니다. 고객이 중요하게 보는 성과와 공급사가 파악한 제약을 같은 표에 올려, 무엇을 얻고 무엇을 포기하는지 보이게 만드는 일에 가깝습니다.
1. 요청 문장보다 해결하려는 문제를 먼저 확인합니다
“필드를 하나 더 추가해 주세요”라는 요청만으로는 작업을 정의하기 어렵습니다. 보고서 누락을 막으려는 것인지, 규제 대응에 필요한 것인지, 특정 담당자의 수기 업무를 줄이려는 것인지에 따라 더 적절한 해결책이 달라질 수 있어요.
요청을 받은 사람은 다음 다섯 가지를 먼저 확인해 주세요.
| 확인 항목 | 확인할 질문 | 남길 근거 |
|---|---|---|
| 현재 문제 | 지금 어떤 오류·지연·불편이 발생하나요? | 사례, 화면, 업무 기록, 문의 내역 |
| 기대 결과 | 변경 뒤 무엇이 가능해지면 해결된 것으로 볼까요? | 측정 가능한 결과 또는 확인 방법 |
| 대상 | 어떤 사용자·업무·거래·기간에 적용되나요? | 대상 목록과 제외 대상 |
| 시급성 | 특정 날짜가 필요한 이유는 무엇인가요? | 외부 마감, 계약 일정, 내부 의사결정일 |
| 미변경 영향 | 이번에 바꾸지 않으면 어떤 손실이나 불편이 남나요? | 대체 절차와 감수 가능한 수준 |
이 단계에서는 고객의 표현을 평가하거나 정답을 미리 정하지 않습니다. “제가 이해한 문제는 A이고, 원하는 결과는 B가 맞을까요?”라고 되짚어 양쪽이 같은 문제를 보고 있는지부터 맞춰 주세요.
2. 기존 기준선과 비교해 변경 범위를 고정합니다
변경은 기존 합의와의 차이입니다. 따라서 현재 계약서, 제안서, 작업명세서, 일정표, 승인된 회의록 중 무엇을 기준선으로 삼는지 먼저 정해야 해요. 기준선이 없다면 변경 범위도 계산할 수 없습니다.
범위는 ‘추가되는 것’만 적지 말고 다음처럼 나눠 주세요.
- 추가: 새로 만들어야 하는 기능, 산출물, 업무
- 수정: 이미 완료했거나 진행 중인 항목에서 바뀌는 부분
- 제외: 이번 변경에 포함하지 않는 요구
- 대체: 새 요구를 넣는 대신 빼거나 축소할 기존 범위
- 의존성: 함께 바뀌어야 하는 데이터, 시스템, 계약 문구, 운영 절차
작은 문구 수정처럼 보여도 테스트, 교육, 데이터 정비, 매뉴얼 수정이 따라오면 운영 범위가 달라질 수 있습니다. 반대로 비용·위험·계약 조건에 영향이 없고 기존 승인 범위 안에서 처리할 수 있다면 별도의 계약 변경이 아니라 운영 조정으로 관리할 수 있어요. 이 구분 기준은 프로젝트 시작 때 금액, 투입시간, 일정 영향, 위험 수준으로 합의해 두는 편이 좋습니다.
3. 찬반 대신 선택지와 트레이드오프를 제시합니다
요청을 수용할 수 있는지 하나만 검토하면 협의가 찬반 대립으로 흐르기 쉽습니다. 최소한 현재 범위를 유지하는 안, 범위를 교환하는 안, 일정이나 예산을 조정하는 안을 함께 비교해 주세요.
| 선택지 | 범위 | 비용 | 일정 | 얻는 것 | 포기하거나 남는 것 |
|---|---|---|---|---|---|
| A. 기존 계획 유지 | 변경하지 않음 | 변동 없음 | 변동 없음 | 기존 약속을 지킴 | 새 문제는 대체 절차로 관리 |
| B. 범위 교환 | 새 요청을 넣고 우선순위가 낮은 항목을 제외 | 제한적 변동 | 기존 일정 유지 가능성 검토 | 핵심 문제를 반영 | 제외 항목의 효익을 포기 |
| C. 추가 변경 | 기존 범위에 새 요청을 추가 | 증분 비용 반영 | 완료일 조정 가능 | 기존 약속과 새 요구를 모두 수행 | 예산·일정 부담 증가 |
| D. 임시 대응 후 별도 단계 | 최소 대응만 먼저 수행 | 단기·후속 비용 분리 | 긴급일과 본 작업 일정 분리 | 시급한 문제를 먼저 완화 | 임시 절차와 후속 작업이 남음 |
선택지는 많을 필요가 없습니다. 의사결정자가 통제할 수 있는 범위·예산·일정 가운데 무엇을 조정할지 보일 정도면 충분해요. 공급사는 추천안을 제시하되, 추천 이유와 받아들이기 어려운 조건도 함께 적어야 합니다.
4. 변경 영향표에서 비용과 일정을 계산합니다
요청을 승인하기 전에는 아래 항목을 한 장에 모아 주세요. 특히 직접원가, 재작업, 일정 영향은 같은 원인을 중복 계산하지 않도록 산출 근거를 붙입니다.
| 변경 영향 항목 | 기록할 내용 | 산출·확인 방법 |
|---|---|---|
| 변경 범위 | 추가·수정·제외·대체 항목과 영향받는 산출물 | 기준선 문서의 항목과 나란히 비교 |
| 직접원가 | 새 작업에 직접 필요한 외부 지출과 내부 투입시간 원가 | 수량 × 단가, 시간 × 완전원가 시간당 단가 |
| 재작업 | 폐기하거나 다시 수행해야 하는 완료·진행 작업 | 재작업 시간과 폐기 비용을 별도 표시 |
| 일정 영향 | 추가 작업, 재작업, 테스트, 승인 대기로 달라지는 완료일 | 작업 의존성과 흡수 가능한 여유일 확인 |
| 책임자 | 영향 분석, 실행, 검증, 최종 의사결정 담당자 | 역할별 이름 또는 직책 지정 |
| 승인 기록 | 승인·보류·반려 결과, 승인자, 일시, 문서 버전 | 이메일·전자결재·서명 문서 등 계약상 합의한 방식으로 보존 |
증분 수행원가는 다음처럼 계산할 수 있어요.
증분 수행원가
= 추가 외부지출
+ 신규 작업시간 × 완전원가 시간당 단가
+ 재작업시간 × 완전원가 시간당 단가
+ 폐기·취소 비용재작업 시간이 신규 작업시간에 이미 들어 있다면 다시 더하지 않습니다. 기존 월 고정 인건비를 완전원가 시간당 단가에 반영했다면 같은 급여를 별도 항목으로 한 번 더 넣지 않아야 해요.
일정은 작업일을 단순히 모두 더하기보다 선후 관계를 확인합니다.
순일정 영향
= 추가 작업일 + 재작업일 + 추가 검증·승인 대기일
- 기존 일정에서 흡수 가능한 여유일병렬로 처리할 수 있는 작업은 같은 날짜에 겹칠 수 있으므로 중복 합산하지 않습니다. 반대로 앞선 작업이 끝나야 시작할 수 있는 검증은 별도 대기일로 반영해 주세요.
기회비용은 실행원가와 분리해 봅니다
기회비용은 다른 일을 포기함으로써 잃는 가치입니다. 현금 지출이나 장부상 원가와 성격이 다르므로, 처음부터 증분 수행원가에 섞지 말고 의사결정용 별도 열에 적는 편이 안전해요.
예를 들어 새 요청 때문에 내부 인력 32시간을 옮겼다면, 그 32시간의 완전원가를 직접원가와 재작업에 반영할 수 있습니다. 같은 32시간을 다시 ‘기회비용’으로 더하면 중복일 수 있어요. 다른 유료 프로젝트를 실제로 미뤄 포기한 공헌이익처럼 별개의 손실을 합리적으로 추정할 수 있을 때만 경제성 비교에 추가하고, 추정 근거를 따로 남겨 주세요.
| 비용 구분 | 예시 | 합산 원칙 |
|---|---|---|
| 증분 현금지출 | 외주비, 추가 라이선스, 특근 수당, 취소 수수료 | 실제 추가 지출만 합산 |
| 내부 자원 원가 | 추가·재작업 시간 × 완전원가 시간당 단가 | 같은 시간을 한 번만 반영 |
| 기회비용 | 미룬 대안 프로젝트의 예상 공헌이익 | 현금·시간 원가와 분리해 비교하고 중복 여부 확인 |
| 정량화하지 않은 위험 | 고객 일정 차질, 품질 저하 가능성 | 금액 합계에 억지로 넣지 말고 영향도와 대응책 기록 |
5. 승인 기록이 남은 뒤 변경 작업을 시작합니다
승인 문서에는 단순히 “진행해 주세요”만 남기지 않습니다. 무엇을 승인했는지 다시 해석하지 않아도 되도록 아래 내용을 함께 고정해 주세요.
- 변경 요청 ID와 기준선 문서 버전
- 승인한 범위와 명시적으로 제외한 범위
- 선택한 대안과 주요 트레이드오프
- 증분 비용, 지급 조건, 변경된 완료일
- 고객 측 의사결정자와 공급사 측 실행 책임자
- 수용 기준, 검증 방법, 검증 예정일
- 승인 일시와 효력 발생일
- 후속 변경이 생길 때 다시 거칠 절차
영국 정부의 고가·복잡 서비스 계약용 Model Services Contract Guidance도 변경 요청, 영향 평가, 승인 후 이행을 구분하고 비용·일정·서비스 수준·필요 자원을 영향 평가에 포함하도록 안내합니다. 이는 변경 관리 항목을 설계할 때 참고할 수 있는 공공계약 모델이며, 국내 민간 B2B 계약에 그대로 적용되는 법적 기준은 아닙니다.
국내에서도 모든 B2B 거래를 같은 법으로 다루지는 않습니다. 다만 하도급거래 공정화에 관한 법률 제3조가 적용되는 추가·변경위탁이라면 작업 시작 전 서면 발급 등 별도 요건이 문제될 수 있어요. 거래 당사자의 지위, 위탁 유형, 계약 조항에 따라 적용 여부가 달라지므로 이 글의 관리표나 일반적인 이메일 승인만으로 법적 요건을 모두 충족한다고 단정해서는 안 됩니다. 분쟁 가능성이 있거나 대금·책임 범위가 크다면 실제 계약서와 적용 법령을 기준으로 법률 전문가의 확인을 받으세요.
6. 착수 전에 수용 기준을 정하고 완료 뒤 다시 확인합니다
“고객이 만족하면 완료” 같은 기준은 확인 시점마다 달라질 수 있습니다. 승인 전에 대상, 조건, 기대 결과, 허용 오차, 확인 자료, 수용 책임자를 정해 주세요.
| 수용 기준 항목 | 작성 예시 |
|---|---|
| 대상 | 월간 보고서의 국내 법인 거래 데이터 |
| 실행 조건 | 승인된 양식과 2026년 7월 마감 데이터 사용 |
| 기대 결과 | 승인된 세 항목이 보고서에 표시되고 합계가 원천 데이터와 일치 |
| 허용 오차 | 금액 불일치 0원, 필수값 누락 0건 |
| 제외 조건 | 해외 법인과 과거 월 소급 수정은 이번 범위에서 제외 |
| 확인 자료 | 결과 보고서, 대조표, 예외 목록 |
| 수용 책임자 | 고객 측 재무 책임자 |
| 확인 기한 | 납품 후 3영업일 이내 |
수치는 프로젝트 특성에 맞게 정해야 합니다. 예시의 ‘0원’이나 ‘3영업일’은 업계 표준이 아니라 작성 방식을 보여주기 위한 값이에요.
완료 후에는 납품 여부만 확인하지 말고 승인 당시 예상과 실제를 비교합니다.
- 승인 범위와 실제 산출물이 일치하는가
- 수용 기준별 증거가 남아 있는가
- 실제 직접원가와 재작업 시간이 예상 범위 안이었는가
- 변경으로 다른 일정·품질·운영 절차에 부작용이 생기지 않았는가
- 처음 확인한 문제가 실제로 줄었는가
- 다음 요청부터 기준선이나 승인 절차를 바꿔야 하는가
NASA의 변경 추적·영향 평가 지침과 변경 승인 지침도 표준화된 요청 기록, 영향 분석, 승인 추적, 구현 후 검증 결과의 연결을 강조합니다. 소프트웨어·시스템 프로젝트용 지침이므로 모든 서비스 계약의 의무를 정하는 자료는 아니지만, 변경 이력을 끝까지 추적하는 운영 구조에는 참고할 수 있어요.
변경 요청에 답할 때 바로 쓸 문장
요청하신 내용은 확인했습니다. 해결하려는 문제는 [문제]이고,
원하는 결과는 [기대 결과]로 이해했습니다.
현재 합의 범위와 비교하면 [추가·수정·제외 항목]이 달라집니다.
선택지는 [A안]과 [B안]이며, 각각 비용·일정·품질 영향은 [영향]입니다.
[추천안]을 권하는 이유는 [근거]입니다.
변경 범위, 증분 비용, 완료일, 책임자, 수용 기준을 승인해 주시면
승인된 버전을 기준으로 착수하고 [검증일]에 결과를 함께 확인하겠습니다.이 문장은 요청을 거절하기 위한 장벽이 아닙니다. 고객의 문제를 더 정확히 풀고, 양쪽이 감수할 비용과 책임을 같은 기준으로 합의하기 위한 출발점입니다.
