1. 화면의 작은 변경이 다섯 곳에 영향을 줄 수 있습니다.
예를 들어 회원가입 화면에 ‘사업자 유형’ 항목을 하나 추가한다고 가정해보겠습니다. 화면에 선택박스 하나를 넣는 것으로 끝날 수도 있지만, 이 값이 실제 서비스 정책에 사용된다면 여러 영역이 함께 바뀔 수 있습니다.
01화면
입력항목과 표시방법 변경
02업무 로직
유형별 처리조건 추가
03DB
저장 구조와 조회조건 변경
04관리자·연동
관리화면·API 등에 값 반영
05테스트
기존·신규 시나리오 재검증
사용자에게는 입력항목 하나지만, 개발자에게는 여러 시스템 요소가 연결된 변경일 수 있습니다.
2. 같은 변경도 언제 요청하느냐에 따라 비용이 달라집니다.
| 변경 시점 | 예상되는 영향 | 일반적인 특징 |
|---|---|---|
| 기획 단계 | 요구사항·화면설계 수정 | 아직 구현 전이라 상대적으로 영향이 작을 수 있음 |
| 디자인 단계 | 화면·컴포넌트·사용자 흐름 재작업 | 디자인 범위에 따라 수정 작업 발생 |
| 개발 중 | 코드·DB·API·기존 기능 수정 | 이미 구현한 부분과의 연결관계 확인 필요 |
| 테스트 중 | 개발 수정 + 기존 테스트 재수행 | 완료된 기능까지 회귀 테스트가 필요할 수 있음 |
| 오픈 직전 | 배포·데이터·일정까지 영향 | 변경 위험과 일정 부담이 커질 수 있음 |
항상 늦은 변경이 비싸다고 단정할 수는 없지만, 이미 구현·검증된 범위가 많을수록 변경 영향도 함께 커질 가능성이 높습니다.
3. 추가 비용은 ‘코딩 시간’만으로 생기지 않습니다.
| 작업 | 변경 시 발생할 수 있는 일 |
|---|---|
| 요구사항 분석 | 기존 기능과 변경 요구의 차이 및 영향 범위 확인 |
| 기획·디자인 | 화면, 사용자 흐름, 정책 문서 수정 |
| 개발 | 프론트엔드·백엔드·DB·연동 코드 변경 |
| 테스트 | 변경 기능뿐 아니라 영향을 받는 기존 기능 재검증 |
| 일정 조정 | 기존 작업 순서와 담당자의 계획 재조정 |
| 배포·문서 | 설정·배포 절차·관련 문서 업데이트 |
4. 모든 변경을 바로 개발할 필요는 없습니다.
특히 MVP 단계에서는 개발 중 새로운 아이디어가 계속 나올 수 있습니다. 중요한 것은 좋은 아이디어가 떠올랐다는 이유만으로 즉시 넣는 것이 아니라 현재 검증 목표에 꼭 필요한지 판단하는 것입니다.
| 질문 | 판단 |
|---|---|
| 현재 MVP의 핵심 가설 검증에 꼭 필요한가? | 필요하면 영향 분석 후 이번 범위 반영 검토 |
| 없으면 사용자가 핵심 업무를 완료할 수 없는가? | 필수 흐름이라면 우선순위 높게 검토 |
| 사용자 검증 후 판단해도 되는가? | 가능하면 다음 버전 후보로 보류 |
| 기존 기능을 대체하는가, 새 기능을 더하는가? | 범위와 테스트 영향 확인 |
| 변경으로 일정이 늦어져도 지금 넣어야 하는가? | 사업 일정과 검증 효과를 함께 비교 |
5. 변경 요청은 ‘요청 → 영향 → 선택 → 합의 → 반영’ 순서로 관리하세요.
01요청 기록
무엇을 왜 바꾸는지 작성
02영향 분석
기능·일정·비용 영향 확인
03우선순위 판단
지금 필요한지 다음으로 미룰지 결정
04조건 합의
비용·일정·범위를 확정
05개발·검수
반영 후 영향 기능까지 확인
이 과정을 거치면 개발업체도 일방적으로 비용을 청구하기 어렵고, 발주자도 변경이 전체 프로젝트에 미치는 영향을 알고 선택할 수 있습니다.
변경을 막는 것이 아니라 ‘변경 비용을 보이게’ 만드는 것이 중요합니다.
개발 중 요구사항이 바뀌는 것 자체가 잘못은 아닙니다. 사용자 검증이나 사업환경 변화 때문에 반드시 바꿔야 할 수도 있습니다. 문제는 변경의 영향을 확인하지 않은 채 계속 누적하는 것입니다.
좋은 변경관리는 “바꾸지 마세요”가 아니라 “바꾸면 무엇이 달라지는지 알고 선택하세요”에 가깝습니다.
6. 요구사항 변경 전 체크리스트
왜 변경해야 하는지 사업·사용자 관점의 이유가 명확하다.
현재 MVP 또는 이번 개발단계에 반드시 필요한 변경인지 확인했다.
화면 외에 업무 로직·DB·관리자·외부연동 영향을 확인했다.
이미 완료된 기능을 다시 테스트해야 하는지 확인했다.
추가 비용과 일정 변경 규모를 반영 전에 확인했다.
이번 개발에 넣을지 다음 버전으로 미룰지 비교했다.
변경된 요구사항을 문서 또는 이슈로 기록했다.
변경 후 무엇을 기준으로 검수할지 정했다.
한 줄 원칙
요구사항 변경의 비용은 ‘수정할 화면의 크기’가 아니라 ‘다시 확인해야 할 영향 범위’에서 발생합니다.
변경 자체를 두려워할 필요는 없습니다. 영향 범위와 비용·일정을 확인하고, 지금 필요한 변경인지 선택하는 것이 중요합니다.