요구사항 변경이 비싼 진짜 이유

상황 — 12개 업무 영역, 매일 바뀌는 요구사항

프로그램 관리·수익성 분석 시스템이었습니다. 수주·원가·수익성·품질·일정까지 12개 업무 영역을 하나로 묶어야 했고, 현업·PMO·개발팀이 함께 움직였습니다.

여러 부서가 함께 쓰는 시스템에서는 요구사항이 매일 들어오고, 어제 정한 것이 오늘 바뀝니다.

문제 — 변경 한 건이 끌고 오는 일들

대형 프로젝트에서 변경이 두려운 이유는 코드를 고치는 시간이 아닙니다. 변경 한 건이 들어오면 이런 일이 줄줄이 따라옵니다.

• 요구사항을 분석하고 영향 범위를 확인합니다.
• 설계 문서를 고칩니다.
• 테스트 시나리오를 다시 씁니다.
• 배포하고 진척 보고를 고칩니다.

흔한 대응과 그 대가

이 일을 모두 사람이 손으로 하니 변경은 비싸고 느립니다. 그래서 보통은 요구사항을 미리 묶어 두거나 변경 요청서로 막습니다. 그러면 몇 달 뒤 오픈하는 날, 현업에게서 ‘이게 아닌데’라는 말을 듣게 됩니다.

접근 — 질문을 바꾸다

질문을 ‘변경을 어떻게 막을까’에서 ‘변경 한 건을 처리하는 비용을 어떻게 낮출까’로 바꿨습니다.

답은 사람을 더 넣는 것이 아니었습니다. 변경을 따라다니는 분석·문서·테스트·코드·기록은 AI 에이전트가 맡고, 사람은 범위를 승인하고 결과를 확인하도록 일을 다시 나눴습니다.

결과

16주 동안 요구사항 500여 건을 반영했습니다. 이 기간에는 머지된 변경을 하루 3회 정해진 시각에 배포했습니다(기준일 2026년 10월 8일).