노노니 | 실전 서비스 기획자의 인사이트 블로그

외주로 서비스를 만들다 보면 "아, 이 기능을 바꾸고 싶다", "더 좋은 아이디어가 떠올랐다"는 순간이 옵니다. 기획 변경은 언제까지 가능할까요? 그리고 변경하면 어떤 영향이 있을까요? 계약 방식과 진행 단계에 따라 달라집니다.

 

턴키 계약에서는 기획 변경이 치명적입니다

턴키 계약(기획, 디자인, 개발을 한 업체가 모두 진행)에서 기획 변경 요청은 일정 지연과 추가 비용 발생의 주요 원인이 됩니다.

턴키 계약은 전체 일정과 비용이 정해져 있고, 기획-디자인-개발이 순차적으로 진행됩니다. 기획이 끝나야 디자인이 시작되고, 디자인이 끝나야 개발이 시작됩니다. 만약 디자인이나 개발 중에 기획을 변경하면, 이미 진행된 작업을 다시 해야 합니다.

예를 들어 디자인이 50% 진행된 시점에 "이 화면 구조를 바꾸고 싶어요"라고 하면, 이미 완성된 디자인을 버리고 새로 해야 합니다. 개발 중에 "이 기능을 추가하고 싶어요"라고 하면, 이미 짜인 코드 구조를 변경해야 할 수도 있습니다.

결과적으로 일정은 늘어나고, 외주사는 "계약 범위를 벗어난 추가 작업"이라며 추가 비용을 청구할 가능성이 높습니다.

 

기획 분리 계약은 변경에 유연합니다

기획만 분리해서 진행하는 경우 기획 변경이 훨씬 자유롭습니다. 기획 단계에서 충분히 수정하고 완성한 후, 디자인과 개발을 시작하기 때문입니다.

기획 일정이 2개월이라고 가정할 때, 기획의 50% 시점(1개월 차)에 변경이 일어나더라도 기간 지연은 최대 1개월 정도이고, 비용은 기획 비용의 150% 수준까지만 상승합니다.

전체 프로젝트 비용에서 기획 비용은 보통 10% 정도입니다. 기획 비용이 50% 증가해도 전체 비용은 10% 정도만 상승하는 것입니다. 턴키 계약에서 중간에 변경하면 전체 비용이 20-30% 증가할 수 있는 것과 비교하면 훨씬 안전합니다.

또한 기획만 완료한 후 디자인과 개발 업체를 다시 선정할 수 있어서, 변경된 기획에 가장 적합한 업체를 찾을 수도 있습니다.

 

화면 설계 시작 후에도 변경 가능합니다

화면 설계가 시작되는 2주차 이후에도 얼마든지 변경이 가능합니다. 모든 내용을 뒤집는 게 아닌 이상, 일부 기능이나 화면을 수정하는 것은 기획 단계에서 충분히 반영할 수 있습니다.

"로그인 방식을 이메일에서 전화번호로 바꾸고 싶어요", "검색 기능을 메인 화면에 추가하고 싶어요" 같은 변경은 기획 단계에서는 문서만 수정하면 되므로 부담이 적습니다.

물론 "전체 서비스 방향을 커머스에서 커뮤니티로 바꾸고 싶어요" 같은 근본적인 변경은 처음부터 다시 해야 하므로 조심해야 합니다.

 

디자인·개발 중 기획 변경은 일정 지연이 큽니다

문제는 디자인이나 개발 작업이 진행되는 중에 기획이 변경되는 경우입니다. 이때는 일정 지연 이슈가 커집니다.

일부 기능이 없어지는 것은 영향이 적습니다. 디자인이나 개발에서 해당 부분을 빼면 되고, 오히려 작업량이 줄어드니 일정에 차질이 없습니다.

하지만 기능이 추가되거나 수정되면 해당 기능에 대한 작업량이 무산됩니다. 이미 디자인한 화면을 버리고 새로 만들어야 하고, 이미 개발한 코드를 수정하거나 버려야 합니다.

더 큰 문제는 기획 변경이 완료될 때까지 작업이 중단된다는 것입니다. 기획 변경에 1주일이 걸리면, 디자인과 개발도 1주일 멈춥니다.

 

작업 기간이 길수록 더 좋은 아이디어가 떠오릅니다

서비스를 만들다 보면 작업 기간이 길어질수록 더 좋은 서비스안이 생각납니다. 처음에는 몰랐던 것들이 보이고, 사용자 관점에서 다시 생각하면 개선점이 발견되고, 경쟁 서비스를 보면서 새로운 아이디어가 떠오릅니다.

"2개월 전에는 이게 최선이라고 생각했는데, 지금 보니 이렇게 하는 게 훨씬 낫네요" 하는 순간이 반드시 옵니다. 이것은 자연스러운 현상입니다.

문제는 그 아이디어를 언제 반영하느냐입니다. 기획 단계에서 떠오른 것이라면 바로 수정하면 됩니다. 하지만 개발 막바지에 떠오른 것이라면 신중해야 합니다.

모든 좋은 아이디어를 다 넣으려다 보면 프로젝트가 끝나지 않습니다. 우선순위를 정하고, 지금 꼭 필요한 것과 나중에 추가할 수 있는 것을 구분해야 합니다.

 

오픈 전 변경은 신중하게 판단하세요

오픈 전에 기획을 변경해서라도 반영해야 할 만큼 중요한 것이라면, 외주사와 논의를 통해 가능 여부를 타진하세요.

일정에 큰 영향이 없다면(1-2주 정도 지연) 반영하는 것을 고려할 수 있습니다. 하지만 영향이 크다면(1개월 이상 지연) 다른 방법을 생각해야 합니다.

 

완성 후 오픈을 미루고 수정하는 전략

일정에 큰 영향을 주는 변경이지만 꼭 필요하다면, 서비스 제작을 완료한 후 오픈을 시키지 말고 추가적인 수정 작업을 진행하는 것을 추천합니다.

이 방법의 장점:

• 현재 계약 범위는 정상적으로 완료됩니다
• 검수와 납품을 받아 소유권을 확보합니다
• 별도 계약으로 수정 작업을 진행하면 명확합니다
• 수정 작업을 다른 업체에 맡길 수도 있습니다

예를 들어 "결제 기능을 추가하고 싶다"면:

1. 일단 결제 없는 버전으로 개발 완료
2. 검수하고 인수받기
3. 별도 계약으로 결제 기능 추가 개발
4. 결제 기능까지 포함해서 정식 오픈

이렇게 하면 현재 외주사와의 계약 분쟁 없이, 깔끔하게 추가 개발을 진행할 수 있습니다.

 

변경 요청 시 문서로 남기세요

기획 변경을 요청할 때는 반드시 문서로 남기세요. 구두나 메신저로만 이야기하면, 나중에 "그런 말 한 적 없다", "그건 추가 비용이다" 같은 분쟁이 생깁니다.

변경 요청서에 포함할 내용:

• 무엇을 왜 변경하고 싶은지
• 기존 기획과 어떻게 다른지
• 일정과 비용에 미치는 영향 (외주사 답변)
• 변경 승인 여부와 서명

외주사로부터 "이 변경은 3주가 더 걸리고, 추가 비용 500만원입니다"라는 답변을 받으면, 그것도 문서로 받아서 보관하세요.

 

경미한 수정과 기획 변경을 구분하세요

모든 변경이 "기획 변경"은 아닙니다. 경미한 수정과 기획 변경을 구분해야 합니다.

경미한 수정 (계약 범위 내):

• 버튼 문구 변경
• 안내 문구 수정
• 화면 순서 조정
• 디자인 색상 미세 조정

기획 변경 (추가 비용 발생 가능):

• 새로운 화면 추가
• 새로운 기능 추가
• 화면 구조 변경
• 사용자 플로우 변경

 

변경이 잦다면 애자일 방식을 고려하세요

만약 서비스 방향이 확정되지 않아서 변경이 자주 일어날 것 같다면, 전통적인 계약 방식보다 애자일(Agile) 방식을 고려하세요.

애자일 방식은 전체를 한 번에 만드는 것이 아니라, 2-4주 단위로 작은 기능을 만들고 검토하고 수정하는 방식입니다. 매 주기마다 방향을 조정할 수 있어서 변경에 유연합니다.

다만 애자일 방식은 총 비용이 얼마가 될지 정확히 예측하기 어렵고, 발주사가 적극적으로 참여해야 하므로 시간 투자가 많이 필요합니다.