개발 중에 바꾸고 싶을 때 지켜야 할 순서

개발이 절반쯤 지났을 때 한 스타트업 대표님이 투자자 미팅을 다녀오셨습니다. 「예약 화면에 쿠폰을 넣으면 좋겠다」는 말을 들으셨다고 합니다. 대표님은 그날 저녁 개발사 담당자에게 메신저로 짧게 요청을 보냈습니다.

다음 주에 쿠폰 입력칸이 생겼습니다. 그런데 결제 금액이 맞지 않았습니다. 환불할 때 쿠폰을 돌려줄지도 정해지지 않았습니다. 관리자 화면에는 쿠폰을 만드는 곳이 없었습니다. 한 줄짜리 요청이 화면 다섯 장을 건드리고 있었던 것입니다.

개발 중에 생각이 바뀌는 것은 자연스러운 일입니다. 문제는 바꾸는 방식입니다.

핵심은 바꿀 내용을 개발사에 말하기 전에 화면설계부터 고치는 것입니다. 고친 화면설계로 영향받는 화면과 일정을 확인하고, 합의한 뒤에 개발에 넘깁니다. 이 순서를 지키면 변경이 생겨도 비용과 일정이 크게 흔들리지 않습니다.

말로 한 변경은 반쪽만 반영됩니다

메신저나 통화로 전한 변경은 듣는 사람이 이해한 만큼만 반영됩니다. 개발자는 요청받은 화면만 고칩니다. 그 기능이 다른 화면에 미치는 영향까지 찾아보는 것은 개발자의 일이 아니기 때문입니다.

또 기록이 남지 않습니다. 몇 주 뒤 「이건 왜 이렇게 되어 있죠」라는 질문이 나오면 아무도 답하지 못합니다. 납품받을 때도 무엇이 원래 범위이고 무엇이 추가였는지 가리기 어렵습니다.

변경 요청은 이 순서로 합니다

1. 바꾸고 싶은 이유를 한 줄로 적습니다. 「쿠폰을 넣고 싶다」보다 「첫 예약 고객에게 할인을 주고 싶다」처럼 목적을 적습니다. 목적을 알면 더 간단한 방법이 보이기도 합니다.
2. 화면설계에서 바뀌는 화면을 모두 찾습니다. 사용자 화면, 관리자 화면, 알림, 결제와 환불까지 따라가 봅니다.
3. 바뀐 화면을 먼저 고칩니다. 무엇이 보이고, 누르면 어떻게 되는지 화면 단위로 적습니다.
4. 개발사에 영향과 일정을 묻습니다. 고친 화면설계를 보내고 추가 기간과 비용이 생기는지 확인합니다.
5. 지금 할지, 다음 차례로 미룰지 정합니다. 오픈 일정이 더 중요하면 미루는 것도 좋은 결정입니다.
6. 변경 이력에 남깁니다. 날짜, 바뀐 화면, 합의한 내용을 한 줄씩 적어 둡니다.

작은 변경과 큰 변경을 구분합니다

모든 변경에 같은 절차를 밟으면 일이 느려집니다. 기획자는 보통 영향 범위로 나눕니다.

세 번째 줄에 해당하는 변경은 사실상 새 기능입니다. 이때는 이번 오픈에 꼭 필요한지부터 다시 묻는 것이 좋습니다.

변경 창구는 한 사람으로 둡니다

대표님, 마케팅 담당자, 운영 담당자가 각자 개발사에 요청하면 서로 부딪히는 변경이 생깁니다. 회사 안에서 의견을 먼저 모으고, 한 사람이 정리해서 보냅니다. 개발사 쪽도 받는 사람을 한 명으로 정해 달라고 하면 누락이 줄어듭니다.

변경을 줄이는 가장 좋은 방법은 시작 전에 메뉴 구조와 화면설계를 충분히 정해 두는 것입니다. 그래도 바꿀 일은 생깁니다. 그때 고칠 기준 문서가 있으면 변경은 혼란이 아니라 관리할 수 있는 일이 됩니다.

자주 묻는 질문

개발 중에 기능을 바꾸면 비용이 꼭 추가되나요?

계약 내용과 변경 크기에 따라 다릅니다. 문구나 배치 정도는 보통 범위 안에서 처리하지만, 여러 화면에 걸친 기능은 추가 비용이 생기는 경우가 많습니다. 요청 전에 고친 화면설계를 보여 주고 먼저 물어보시는 것이 안전합니다.

개발사가 변경 요청을 거절하면 어떻게 하나요?

거절 이유를 먼저 들어 보십시오. 이미 만든 구조를 크게 흔드는 변경이라면 다음 차례로 미루는 편이 나을 수 있습니다. 화면설계를 기준으로 이야기하면 감정 싸움이 아니라 범위 이야기가 됩니다.

변경 이력은 어떤 형식으로 남기면 되나요?

거창한 양식은 필요 없습니다. 날짜, 바뀐 화면 이름, 바꾼 이유, 합의한 일정과 비용을 표 한 장에 한 줄씩 적으면 충분합니다. 납품받을 때 이 표가 확인 기준이 됩니다.