프로젝트 중반쯤 되면 이런 메시지를 보내게 됩니다.
"아 그리고 이거 하나만 추가로... 상품 목록에서 가격순 정렬도 되면 좋을 것 같아요."
업체는 대개 "네, 확인해 볼게요"라고 답합니다. 그리고 이런 게 열 번쯤 쌓이면, 어느 날 "일정이 3주 밀릴 것 같습니다"라는 연락이 옵니다. 발주자는 당황합니다. 각각은 다 작은 거였는데.
이 상황에서 누가 잘못했는지 따지는 건 대체로 소용이 없습니다. 발주자는 만들어지는 걸 보면서 생각이 구체화되는 게 자연스럽고, 업체는 관계를 생각해서 작은 요청을 그때그때 받아 줍니다. 양쪽 다 합리적으로 행동했는데 결과가 나쁩니다.
빠진 건 절차입니다.
요구가 늘어나는 건 실패가 아니다
먼저 짚을 게 있습니다. 개발 중에 요구가 바뀌는 걸 막으려는 접근은 대개 실패합니다.
발주자가 처음부터 완벽한 요구사항을 쓸 수 있었다면 좋았겠지만, 실제로는 화면이 나오기 전까지 뭘 원하는지 정확히 알기 어렵습니다. 종이에 적힌 "상품 목록"과 실제로 눌러 보는 상품 목록은 다른 경험이고, 후자를 보고 나서야 "아, 정렬이 필요하겠네"가 떠오릅니다.
그래서 목표는 변경을 없애는 게 아니라 변경을 눈에 보이게 만드는 것입니다. 보이지 않는 변경이 쌓이는 게 문제지, 변경 자체가 문제가 아닙니다.
세 줄짜리 변경 절차
거창한 프로세스가 필요 없습니다. 착수할 때 이렇게만 합의해 두면 됩니다.
- 요청은 한곳에 모아서 적는다 (메신저 말고).
- 업체는 각 요청에 공수(일)와 금액, 일정 영향을 적어 회신한다.
- 발주자가 "진행"이라고 답한 것만 작업한다.
이게 전부입니다. 핵심은 2번입니다. 요청과 승인 사이에 숫자를 보는 단계를 끼워 넣는 것.
"가격순 정렬 추가"라는 요청에 "0.5일 / 10만원 / 일정 영향 없음"이라는 답이 붙으면, 발주자는 그 자리에서 진행 여부를 판단할 수 있습니다. 반대로 "3일 / 60만원 / 오픈 1주 지연"이 붙으면 대부분 "그럼 오픈하고 나서 하죠"가 됩니다.
이 단계 없이 "네, 해드릴게요"만 반복되면 마지막에 3주가 한꺼번에 나타납니다.
요청 목록은 이렇게 생겼습니다
구글 시트 한 장이면 충분합니다. 노션도 좋고요. 중요한 건 메신저가 아닌 곳에 쌓인다는 것입니다.
| 번호 | 요청 | 요청일 | 공수 | 금액 | 일정 영향 | 상태 |
|---|---|---|---|---|---|---|
| 1 | 상품 가격순 정렬 | 09-06 | 0.5일 | 10만 | 없음 | 진행 |
| 2 | 카카오 로그인 추가 | 09-08 | 3일 | 60만 | +3일 | 오픈 후 |
| 3 | 관리자 엑셀 내려받기 | 09-10 | 1일 | 20만 | 없음 | 진행 |
| 4 | 상세페이지 디자인 변경 | 09-12 | 2일 | 40만 | +2일 | 검토중 |
이 표의 진짜 가치는 각 줄이 아니라 합계입니다. 4건에 6.5일, 130만원. 이게 눈에 보이면 "이번 달 추가 요청은 여기까지 하자"는 판단이 자연스럽게 나옵니다. 표가 없으면 그 판단을 할 근거가 없습니다.
왜 늦게 말하면 더 비싼가
같은 요구라도 언제 말하느냐에 따라 비용이 크게 달라집니다. 직관적이지 않은 부분이라 짚고 갑니다.
기획 단계에서 "정렬 기능이 필요해요"라고 하면, 그건 문서 한 줄 고치는 일입니다.
개발 중에 말하면 코드를 쓰는 일이고, 이미 만든 부분과 어긋나지 않게 맞추는 일이 붙습니다.
검수 단계에서 말하면 코드를 고치고, 그 변경이 다른 기능을 깨지 않았는지 다시 확인하고, 이미 통과한 검사를 다시 돌려야 합니다. 앞에서 세운 일정과 인력 배치가 이미 끝난 뒤라 사람을 다시 붙이는 비용도 생깁니다.
그래서 비용은 대체로 이런 모양으로 늘어납니다.
기획 중 ▏ 1
개발 초반 ▍▍ 2~3
개발 후반 ▍▍▍▍▍ 5~7
검수 중 ▍▍▍▍▍▍▍▍▍ 10 이상
정확한 배수는 상황마다 다르지만, 방향은 늘 같습니다. 떠오른 요구는 빨리 말하는 게 싸다. 애매해서 나중에 말하려고 미뤄 두는 게 가장 비쌉니다.
"이건 원래 포함 아니에요?"를 가르는 법
가장 껄끄러운 대화입니다. 발주자는 당연히 포함이라 생각하고, 업체는 추가라고 봅니다.
이걸 감정 문제로 만들지 않는 방법은 하나뿐입니다. 요구사항 문서를 펴 놓고 대조하기.
문서에 있으면 포함, 없으면 추가. 문서에 있는데 표현이 애매하면 그건 협의 대상. 이 기준이 있으면 대화가 5분이면 끝납니다.
기준이 없으면 "상식적으로", "보통은" 같은 말이 오가고, 그건 결론이 안 납니다. 그래서 착수 전에 요구사항을 문서로 만들어 두는 게 결국 이 순간을 위한 준비입니다. (견적 요청서 만들기로 그 문서를 만들 수 있습니다.)
문서에 없는데 정말 없으면 안 되는 기능이라면, 그건 "누가 빼먹었나"보다 "지금 넣으면 얼마인가"로 넘어가는 게 빠릅니다. 책임 소재를 가리는 대화에서 이기더라도 일정은 그대로 밀립니다.
교환 카드를 만들어 두기
추가 요구가 있을 때마다 돈을 더 쓰는 것만이 답은 아닙니다. 빼는 카드도 있습니다.
"카카오 로그인 추가하는 대신, 처음에 넣기로 한 SNS 공유 기능은 빼도 될까요?"
3일짜리를 넣고 2일짜리를 빼면 순증이 1일입니다. 대부분의 프로젝트에는 처음에 넣기로 했지만 실제로 중요하지 않은 기능이 몇 개씩 있습니다. 요구사항에 필수·권장·선택 등급을 매겨 두면 이 카드를 꺼내기가 쉬워집니다. 등급 없이 전부 필수로 잡아 두면 뺄 게 없어서 늘리는 수밖에 없습니다.
착수 전에 합의할 문장
계약서에 넣거나, 못 넣으면 착수 메일에라도 남겨 두세요.
변경 처리 계약 범위 외 추가 요구는 요청 목록에 기록하고, 수급인은 3영업일 내에 예상 공수·금액·일정 영향을 회신한다. 도급인의 서면 승인 후 착수하며, 승인 없이 수행한 작업은 청구하지 않는다. 승인된 변경은 일정과 대금에 반영한다.
마지막 두 문장이 양쪽을 다 지킵니다. 앞 문장은 발주자를 지키고(승인 안 했는데 청구되는 일 방지), 뒷 문장은 업체를 지킵니다(승인했으면 일정과 돈에 반영).
정리
- 개발 중 요구가 느는 건 정상입니다. 없애려 하지 말고 보이게 만드세요.
- 요청과 승인 사이에 공수·금액·일정 영향을 보는 단계를 넣으세요.
- 요청은 메신저 말고 목록에 쌓으세요. 합계가 보여야 판단이 됩니다.
- 떠오른 건 빨리 말하는 게 쌉니다. 미룰수록 비싸집니다.
- 넣을 때 뺄 것도 같이 보세요.
이 절차를 제안했을 때 반기는 업체가 좋은 업체입니다. 변경이 기록되면 업체도 "이만큼 더 했다"를 증명할 수 있으니까요. 절차가 없어서 손해 보는 건 사실 양쪽 다입니다.
일정이 왜 밀리는지 구조적으로 보고 싶으면 8주 일정이 13주가 되는 구조를, 요구사항을 처음 정리하는 방법은 요구사항이 정리가 안 될 때를 보세요.