"아, 그리고 이것도 추가해주세요."

프로젝트 진행 중에 이 말이 나오지 않는 프로젝트는 없습니다. 비즈니스 환경이 바뀌기도 하고, 만들다 보니 더 좋은 아이디어가 떠오르기도 합니다. 요구사항 변경 자체가 나쁜 것은 아닙니다. 문제는 그 비용을 인식하지 못하는 것입니다.

"이것도 추가해주세요"의 누적 비용

작은 변경이 작지 않은 이유

"버튼 하나 추가하는 건 금방이잖아요?"

버튼 하나를 추가하려면:

• UI 디자인 변경
• 프론트엔드 컴포넌트 개발
• 버튼 클릭 시 동작할 백엔드 API
• 해당 API의 비즈니스 로직
• 에러 처리
• 테스트

버튼 하나가 아니라, 하나의 기능이 추가되는 것입니다. 그리고 이런 "작은" 추가가 5번, 10번 쌓이면 원래 계획에 없던 기능이 한 묶음 추가됩니다.

비용은 시점에 따라 달라진다

같은 기능이라도 언제 추가하느냐에 따라 비용이 다릅니다.

• 기획 단계에서 추가: 문서 한 줄 수정. 비용 거의 없음
• 디자인 단계에서 추가: 화면 설계 수정. 비용 약간 발생
• 개발 중간에 추가: 이미 만든 코드 구조 수정. 비용 상당
• 개발 완료 후 추가: 완성된 시스템에 끼워 넣기. 비용 매우 높음

늦게 바꿀수록 비용이 기하급수적으로 올라갑니다.

범위 변경이 일정에 미치는 영향

비용보다 더 큰 문제는 일정입니다.

연쇄 지연

기능 하나가 추가되면 그 기능과 연결된 다른 기능도 수정해야 합니다. A를 추가하면 B의 데이터 구조가 바뀌고, B가 바뀌면 C의 화면도 수정해야 합니다. 하나의 변경이 연쇄적으로 일정을 밀어냅니다.

우선순위 혼란

원래 계획된 기능과 새로 추가된 기능 중 뭘 먼저 해야 하나? 추가 요청이 들어올 때마다 우선순위가 흔들리면, 개발팀은 방향을 잃습니다. 이것도 저것도 하다가 아무것도 완성하지 못하는 상황이 됩니다.

품질 저하

일정은 그대로인데 할 일이 늘어나면, 결국 테스트를 줄이게 됩니다. "일단 만들고 나중에 고치자." 이 판단이 런칭 후 버그 폭탄으로 돌아옵니다.

변경 관리 프로세스

요구사항 변경을 막을 수는 없습니다. 하지만 관리할 수는 있습니다.

변경 요청서

변경이 필요하면, 구두가 아니라 문서로 요청합니다. 무엇을 변경하고, 왜 필요한지를 기록합니다. 문서화하면 "이거 했었나?" 같은 분쟁이 사라집니다.

영향도 분석

개발사는 변경 요청에 대해 "이걸 바꾸면 일정이 며칠 늘어나고, 비용이 얼마 추가됩니다"를 분석해서 공유합니다. 클라이언트는 이 정보를 보고 "그래도 바꿀 것인가"를 판단합니다.

합의 후 진행

변경의 비용과 일정 영향을 양쪽이 합의한 후에 작업을 시작합니다. "일단 해주세요, 비용은 나중에 이야기하죠"는 반드시 분쟁으로 이어집니다.

프로덕트 메이커는 모든 프로젝트에서 격주 스프린트 기반으로 진행하며, 변경 요청은 다음 스프린트에 반영합니다. 현재 스프린트의 작업을 보호하면서도, 변경을 유연하게 수용하는 구조입니다.

자주 공유하고, 자주 피드백 받는다

저희가 화이트박스 방식을 쓰는 이유가 여기에 있습니다. 격주마다 동작하는 결과물을 보여드리고, 거기서 피드백을 받습니다. 프로젝트 마지막에 완성품을 공개하면서 "이게 아닌데요"가 터지는 폭탄을 방지하는 겁니다. 2주마다 방향을 확인하니까, 틀어져도 2주치만 수정하면 됩니다. 3개월 뒤에 틀어진 걸 발견하면 3개월치를 엎어야 합니다.

다만 "피드백을 유연하게 받는다"가 "무한히 바꿔준다"는 뜻은 아닙니다. 자전거를 만들기로 한 프로젝트에서 피드백을 반영하다 보니 자동차가 되어가는 — 이건 범위 변경이지 피드백이 아닙니다. 방향을 조정하는 것과 목적지를 바꾸는 것은 다릅니다.

*프로젝트 범위와 일정에 대해 상담이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요.*