개발이 시작되고 나면 묘한 불안이 찾아옵니다. 화면을 하나씩 만들어가는 과정을 보면서, "아, 여기는 이렇게 하는 게 맞았을까"라는 생각이 자꾸 드는 거예요. 처음엔 확신을 갖고 정했던 기획인데, 실제 결과물을 보니까 바꾸고 싶은 부분이 눈에 들어옵니다.
그런데 바꾸자고 하면 비용이 올라가는 건 아닌지, 일정이 밀리는 건 아닌지 걱정이 돼요. 개발사한테 "여기 좀 바꿀 수 있나요?"라고 물어보는 것 자체가 부담스럽게 느껴지기도 합니다. 혹시 이미 다 만들어놓은 걸 뒤집는 건 아닌가 싶거든요.
아마 이 글을 읽고 계신 분도 비슷한 상황이거나, 앞으로 개발을 시작하면 이런 순간이 올까 봐 미리 궁금한 분일 거예요. 결론부터 말씀드리면, 개발 도중에 기획이 바뀌는 건 정상입니다. 다만 "어떻게 바뀌느냐"에 따라 결과가 완전히 달라집니다.
바뀌는 것 자체는 문제가 아닙니다
기획은 머릿속에서 만든 것이고, 개발은 그걸 실제로 구현하는 과정이에요. 머릿속 그림과 실제 결과물 사이에 차이가 생기는 건 당연합니다. 화면을 처음 보는 순간 "아, 이건 이렇게 하는 게 더 자연스럽겠다"를 느끼는 건, 기획이 잘못됐다는 게 아니라 기획이 구체화되고 있다는 뜻이에요.
그래서 좋은 개발 프로세스에서는 이 변경을 전제로 설계합니다. 한 번에 다 만들고 끝에 확인하는 게 아니라, 중간중간 결과물을 보면서 방향을 조정하는 구조를 잡거든요. 앞선 글에서 다뤘던 화면 설계 단계를 꼼꼼히 거쳤더라도, 개발 과정에서 더 나은 방법이 보이는 건 자연스러운 일입니다.
그런데 문제가 되는 변경이 따로 있습니다.
위험한 건 "바뀌는 것"이 아니라 "늘어나는 것"입니다
개발 도중의 기획 변경은 크게 두 종류로 나뉩니다.
하나는 기존 범위 안에서의 수정입니다. "이 버튼의 위치를 여기로 옮기자", "이 화면에서 보여주는 정보 순서를 바꾸자" 같은 거예요. 이건 설계를 조정하는 수준이라 비용이나 일정에 큰 영향이 없습니다.
다른 하나는 범위 자체가 늘어나는 변경입니다. "결제 기능은 2차로 미뤘는데, 역시 1차에 넣고 싶어요", "관리자 페이지에 통계 대시보드도 추가해주세요" 같은 거예요. 이건 성격이 완전히 다릅니다. 새로운 기능이 들어가면 화면도 늘어나고, 데이터 구조도 바뀌고, 테스트 범위도 커지거든요. 당연히 비용과 일정에 영향을 줍니다.
문제는 이 두 가지의 경계가 애매할 때가 많다는 겁니다. "여기에 필터 하나만 추가해주세요"가 단순한 수정인 것 같지만, 실제로는 검색 로직 전체를 바꿔야 하는 경우도 있어요. 본인 입장에서는 작은 요청인데, 개발 입장에서는 큰 변경이 되는 거죄. 이걸 구분하지 못한 채 요청만 계속 쌓이면, 일정은 밀리고 비용은 올라가고, 어느 순간 "왜 이렇게 늦어지는 거예요?"라는 상황이 됩니다.
기획 변경이 생겼을 때, 이렇게 확인하세요
개발 도중에 바꾸고 싶은 게 생기면, 바로 "이거 바꿔주세요"라고 하기 전에 세 가지를 확인하는 습관을 들이면 좋습니다.
개발사에 "이걸 바꾸면 범위가 달라지나요?"라고 한 마디만 물으면 됩니다. 범위 안이면 바로 진행하면 되고, 범위 밖이면 추가 비용과 일정이 얼마나 드는지를 확인한 뒤에 결정할 수 있어요. 이 확인 없이 요청만 쌓이면, 나중에 추가 비용이 한꺼번에 나와서 양쪽 다 당황하게 됩니다.
개발 도중에 떠오르는 아이디어는 대부분 좋은 아이디어입니다. 그런데 "좋은 아이디어"와 "지금 꼭 들어가야 하는 기능"은 다른 문제예요. 1차 출시에 없으면 서비스가 안 돌아가는 건지, 아니면 2차 업데이트에 넣어도 되는 건지를 구분해야 합니다. 앞선 글에서 다뤘던 "이건 나중에 해도 된다"를 정하는 판단이 여기서도 그대로 적용돼요.
카카오톡이든 이메일이든, "이 부분을 이렇게 바꾸고 싶습니다"를 글로 남겨두는 게 중요합니다. 구두로만 이야기하면 나중에 "이건 원래 포함이었잖아요" vs "이건 추가 요청이었잖아요"로 엇갈리거든요. 간단한 메모라도 기록이 있으면 양쪽 다 명확해집니다.
변경이 불안하지 않으려면, 중간 확인 구조가 있어야 합니다
기획 변경이 두려운 진짜 이유는 변경 자체가 아니라, "지금 어디까지 와 있는지 모르는 상태에서 바꿔야 하는 것"이에요. 개발이 시작된 뒤 한두 달 동안 아무 소식 없다가 갑자기 결과물을 받으면, 그때 바꾸고 싶은 게 한꺼번에 쏟아집니다. 바뀌는 양이 많아지니 비용도 커지고, 일정도 밀리는 거예요.
그래서 중요한 건 중간 확인 주기를 정해두는 겁니다. 일주일이든 이주일이든 간격을 정해서, 지금까지 만들어진 화면을 눈으로 직접 보는 시간을 갖는 거예요. 이 구조가 있으면 변경이 생겨도 작은 단위로 조정할 수 있습니다. 한 달 뒤에 열 개를 바꾸는 것보다, 이주일마다 두세 개씩 잡아가는 게 비용도 적고 스트레스도 훨씬 적거든요.
흐름소프트에서 프로젝트를 진행할 때 정기 데모를 꼭 잡는 이유가 이겁니다. 개발 중간중간 화면을 공유하면서 "여기는 이대로 괜찮은지, 바꿀 부분이 있는지"를 함께 확인합니다. 이렇게 하면 기획 변경이 "갑작스러운 뒤집기"가 아니라 "자연스러운 방향 조정"이 되거든요. 변경 요청이 생겼을 때도 범위 안인지 밖인지를 그 자리에서 바로 짚어드릴 수 있어서, 나중에 추가 비용으로 당황하는 상황도 예방됩니다.
정리하면 이렇습니다
개발 도중에 기획이 바뀌는 건 정상입니다. 실제 결과물을 보면서 더 나은 방향이 보이는 건 자연스러운 과정이에요. 다만 "기존 범위 안의 수정"과 "범위를 늘리는 변경"은 성격이 완전히 다르고, 이걸 구분하지 않으면 비용과 일정이 조용히 커집니다.
변경이 생겼을 때는 범위 안인지 밖인지를 먼저 확인하고, 지금 꼭 필요한 건지를 따져보고, 기록으로 남기세요. 그리고 이런 판단을 작은 단위로 반복할 수 있도록 중간 확인 주기를 정해두면, 기획 변경이 프로젝트를 흔드는 게 아니라 프로젝트를 더 좋게 만드는 과정이 됩니다.
다음 글에서는 개발과 검증 단계를 연결하겠습니다. 베타테스트를 언제, 어떻게 시작해야 하는지 — 이전에 다뤘던 베타테스트 시리즈와 함께 읽으면 전체 흐름이 이어집니다.
