MVP 개발 기간 단축 가이드 2026: 무엇을 빼면 줄고 무엇을 빼면 더 걸리나요

MVP 기간을 줄인다는 건 개발자가 코드를 더 빨리 치게 만드는 게 아니라, 결정과 대기와 되돌림을 줄이는 것이에요. 출시까지 걸리는 시간은 만드는 시간, 정하는 시간, 기다리는 시간, 다시 만드는 시간으로 나뉘는데 발주자가 손댈 수 있는 건 뒤의 셋이에요. 그래서 기간 단축은 속도의 문제가 아니라 무엇을 빼고 무엇을 남길지 정하는 결정의 문제예요.

이 글은 출시 날짜가 이미 박혀 있는 창업자와 기획자를 위해 썼어요. 투자 미팅이든 시즌이든 경쟁사 출시든, 날짜는 정해졌는데 그 안에서 무엇을 줄여야 진짜 줄고 무엇을 줄이면 나중에 더 걸리는지를 항목별로 갈라 볼게요. 어떤 도구가 있는지, 어떤 스택이 나은지는 다른 글의 몫이고, 비용이 어떻게 구성되는지도 MVP 개발 비용은 무엇으로 정해지나에서 따로 다뤘어요.

MVP 기간을 줄인다는 건 정확히 무엇을 줄이는 건가요?

출시까지의 시간을 네 덩어리로 쪼개면 이야기가 선명해져요. 첫째는 실제로 만드는 시간이에요. 둘째는 무엇을 만들지 정하는 시간이고요. 셋째는 누군가의 답을 기다리는 시간, 넷째는 이미 만든 걸 뜯어고치는 시간이에요.

발주자가 개발사에 속도를 요구할 때 겨냥하는 건 첫 번째 덩어리예요. 그런데 첫 번째는 사람과 도구가 정해지는 순간 거의 고정돼요. 반대로 나머지 셋은 발주자의 습관과 준비 상태에 따라 크게 흔들려요. 기간을 줄이겠다면 손댈 곳은 흔들리는 쪽이에요.

기간을 줄여 달라는 요청이 잘 안 먹히는 첫 번째 이유가 여기 있어요. 요청을 받는 쪽은 첫 번째 덩어리만 손댈 수 있는데, 그 덩어리는 이미 줄일 만큼 줄여 놓은 상태일 때가 많거든요. 남은 여지는 발주자 쪽에 있어요.

그래서 이 글의 기준은 하나예요. 지금 빼서 네 덩어리의 총합이 줄어드는가, 아니면 지금 한 덩어리를 줄이는 대신 다른 덩어리를 키우는가. 같은 빼기라도 이 기준에서 결과가 정반대로 갈려요.

실제로 시간을 먹는 구간은 어디인가요?

일정이 밀렸을 때 사람들은 개발 구간을 의심하지만, 멈춰 있던 자리는 그 앞이나 옆인 경우가 많아요. 결정이 안 나서 손을 못 댄 구간, 자료가 안 와서 비워둔 화면, 외부 서비스 승인이 안 떨어져서 붙이지 못한 기능 같은 것들이요.

이 구간들의 공통점은 한 가지예요. 멈춰 있는 동안 누구도 바쁘지 않다는 걸 느끼지 못한다는 거예요. 개발자는 다른 화면을 붙잡고 있고, 디자이너는 다음 화면을 그리고 있고, 발주자는 회의 중이에요. 다들 일하고 있는데 출시일만 조용히 밀려요. 그래서 일정 점검에서 물어야 할 질문은 지금 무엇을 하고 있느냐가 아니라 지금 무엇이 무엇을 기다리고 있느냐예요.

표의 오른쪽 열에는 코드가 한 줄도 없어요. 기간을 줄이는 결정의 무게중심이 어디에 있는지 보여주는 대목이에요. 범위를 어디서 끊어야 하는지는 MVP 범위는 어디서 끊어야 하나에서 절차로 다뤘어요.

같은 빼기인데 왜 어떤 건 줄고 어떤 건 늘어나나요?

빼기에는 두 종류가 있어요. 하나는 지우는 빼기예요. 없애도 나중에 그 자리로 돌아올 일이 없는 것들이요. 다른 하나는 미루는 빼기예요. 지금 안 하면 나중에 반드시 해야 하고, 그때는 이미 쌓인 것 위에서 해야 해서 더 오래 걸리는 것들이에요.

이 구분이 필요한 이유는 급할 때 나오는 제안이 둘을 섞어서 오기 때문이에요. 지금 일정이 안 맞으니 이것도 빼고 저것도 빼자는 말이 나오는데, 그 목록 안에는 진짜로 없어도 되는 것과 나중에 더 비싸게 돌아올 것이 함께 들어 있어요. 목록을 받아서 한 줄씩 판정하지 않으면, 줄인 일정만큼 나중에 되돌려 주게 돼요.

일정이 급할수록 이 둘이 뒤섞여요. 둘 다 당장은 일이 줄어든 것처럼 보이거든요. 판정 기준은 이 질문 하나예요. 이걸 빼면 나중에 다시 손대야 하나요, 아니면 영영 안 해도 되나요.

표를 한 줄로 요약하면 이래요. 겉에 보이는 것은 지워도 되고, 밑에 깔리는 것은 미루면 안 돼요. 화면과 기능은 나중에 얹어도 그 자리에 얹히지만, 데이터와 사용자 구분과 돈의 구조는 나중에 바꾸면 이미 쌓인 것을 전부 건드려야 하거든요.

표가 기능 이름이 아니라 구조 이름으로 적혀 있는 건 일부러예요. 로그인이나 결제 같은 기능 하나하나를 이번 범위에 넣을지 뺄지는 검증 목표에 따라 갈리는 별개 판단이라, 기능 단위로 넣고 빼는 기준은 앞서 링크한 범위 확정 절차 쪽에서 보는 게 맞아요. 여기서 미루지 말라고 한 건 그 기능을 만들라는 뜻이 아니라, 나중에 그 기능이 들어올 자리를 데이터에 남겨 두라는 뜻이에요.

기능은 어디까지 빼도 되나요?

기능을 뺄 때 기준으로 삼을 건 중요도가 아니라 검증하려는 질문이에요. 이번 출시로 확인하려는 게 무엇인지 한 문장으로 쓸 수 있으면, 그 문장에 안 걸리는 기능은 전부 후보에서 빠져요.

반대로 그 문장이 없으면 어떤 기능도 뺄 수 없어요. 전부 언젠가 필요한 것처럼 보이니까요. 그래서 기능 목록을 줄이는 작업은 기능 회의가 아니라 가설 회의로 시작해야 해요.

기능을 빼자는 말에 팀이 저항하는 이유는 손실감 때문이에요. 이미 그려 본 화면, 이미 설명해 둔 기능을 지우는 건 뒤로 가는 것처럼 느껴지거든요. 그런데 빼기의 목적은 제품을 작게 만드는 게 아니라 답을 먼저 받는 것이에요. 답을 받고 나면 남은 기능의 우선순위가 달라져 있기도 해요.

빼기로 한 기능은 지우지 말고 따로 적어 두세요. 목록이 남아 있어야 회의 때마다 같은 기능이 다시 올라오는 일을 끊을 수 있어요. 무엇을 어디까지 적어야 개발사가 되묻지 않는지는 기능 명세서에 무엇까지 적어야 하나에 정리돼 있어요.

여기서 한 가지 주의할 게 있어요. 기능을 빼면 만드는 시간은 줄지만, 뺀 기능 자리에 사람이 들어가는 경우가 생겨요. 자동으로 처리되던 일을 누군가 손으로 하게 되는 거죠. 그건 개발 기간을 줄이는 대신 운영 부담을 늘리는 교환이라, 검증 기간이 짧을 때만 유리한 선택이에요. 그래서 뺄 때는 그 일을 누가 손으로 받을지도 같이 정해 둬야 해요.

품질을 빼면 기간이 줄어드나요?

품질은 하나의 덩어리가 아니에요. 갈라 놓고 보면 빼도 되는 것과 절대 못 빼는 것이 섞여 있어요.

현장에서 품질을 낮추자는 말이 나올 때 실제로 겨냥하는 건 보이는 쪽이에요. 화면을 덜 다듬고, 애니메이션을 빼고, 대응 기기를 줄이자는 이야기죠. 그건 시간이 실제로 줄어드는 선택이에요. 문제는 그 말이 밑에 깔린 쪽까지 함께 끌고 갈 때 생겨요.

보기 좋은 것은 나중에 고쳐도 되지만, 무너지면 되돌릴 수 없는 것은 처음부터 있어야 해요. 품질을 뺀다는 말이 나올 때는 어느 쪽을 말하는지부터 확인하세요.

이 구분을 회의에서 쓰려면 품질이라는 단어를 아예 안 쓰는 게 나아요. 품질을 낮추자고 말하는 대신 어느 화면의 무엇을 덜 다듬을지 지목하면, 못 빼는 쪽이 딸려 나가는 일이 생기지 않아요.

문서를 빼면 빨라지나요?

문서는 기간 단축 논의에서 오해받기 쉬운 항목이에요. 쓰는 데 시간이 드니까 빼면 빨라질 것 같지만, 실제로는 문서가 없을 때 그 시간이 되묻기와 재작업으로 옮겨가요.

문서 없이 시작해도 처음 얼마간은 빨라 보여요. 회의에서 말로 합의하고 바로 만들기 시작하니까요. 어긋남이 드러나는 건 만든 결과를 처음 확인하는 자리예요. 그때 나오는 말이 생각한 거랑 다르다는 말이고, 그 문장 하나가 여러 날치 작업을 되돌려요. 문서는 쓰는 데 드는 시간과 안 써서 되돌리는 시간을 맞바꾸는 거래예요.

다만 모든 문서가 같은 값을 하지는 않아요. 판단 기준은 그 문서가 없을 때 누군가 추측으로 일을 시작하게 되는가예요. 추측이 들어가는 자리를 막는 문서는 남기고, 이미 정해진 걸 보기 좋게 옮겨 적는 문서는 빼도 돼요.

남겨야 할 문서도 분량으로 승부할 필요는 없어요. 문장이 길어서가 아니라 애매해서 되묻는 거니까요. 어떤 항목이 들어가야 해석이 갈리지 않는지는 요구사항정의서는 무엇을 담는 문서인가에서 항목별로 다뤘어요.

인프라와 운영 준비는 미뤄도 되나요?

서버 구성, 도메인, 계정 명의, 배포 절차 같은 것들은 만들기 시작할 때는 안 보이다가 출시 직전에 한꺼번에 튀어나와요. 그리고 이런 항목에는 우리 팀의 속도와 무관한 대기 시간이 붙어요. 명의 확인, 결제 수단 등록, 심사 같은 절차가 껴 있으니까요.

인프라를 빼자는 말은 잘 안 나와요. 대신 조용히 뒤로 밀려요. 눈에 보이는 화면이 아니라서 진척 보고에 안 잡히고, 급한 화면이 생기면 그 뒤로 또 밀리거든요. 그러다 출시 주에 몰려서 나타나요.

그래서 인프라는 빼는 대상이 아니라 앞으로 당기는 대상이에요. 개발이 끝난 뒤에 시작하면 그 대기 시간이 일정 맨 끝에 그대로 얹히지만, 착수와 동시에 걸어두면 개발과 나란히 흘러가요.

판단 기준은 이 질문이에요. 이 항목이 우리 팀의 손만으로 끝나나요, 아니면 바깥의 승인이 필요한가요. 바깥이 끼는 항목은 예외 없이 착수 첫 주에 걸어두는 게 맞아요. 우리 손으로 끝나는 항목만 뒤로 미룰 후보가 돼요.

한 가지 더 있어요. 계정과 도메인의 명의는 처음부터 발주자 쪽으로 만들어 두는 게 좋아요. 나중에 옮기는 일은 기술 작업이 아니라 절차 작업이라, 일정 막바지를 통째로 잡아먹는 자리가 되기 쉬워요.

순서를 못 바꾸는 일과 병렬로 돌릴 수 있는 일은 무엇인가요?

기간이 줄어드는 또 다른 길은 빼기가 아니라 겹치기예요. 다만 아무거나 겹칠 수는 없어요. 앞의 결과가 있어야 시작할 수 있는 일이 있으니까요.

표에서 눈여겨볼 건 마지막 두 줄이에요. 외부 기관의 승인과 심사는 우리가 아무리 빨리 만들어도 줄지 않는 구간이라, 일정 계획에서 가장 먼저 자리를 잡아야 해요. 연동이 왜 일정 변수인지는 외부 서비스 연동이 왜 일정을 흔드나에서 사례로 풀었어요.

겹치기에는 조건이 하나 붙어요. 겹쳐 놓은 두 일이 서로 다른 사람의 손에 있어야 한다는 거예요. 같은 사람이 두 가지를 번갈아 잡으면 겹친 게 아니라 나눠 한 거라서 총 시간은 그대로거나 오히려 늘어요. 일정표에서 두 줄이 나란히 그려져 있으면 그 줄을 누가 맡는지부터 확인하세요.

겹치기를 실제로 굴리려면 지금 무엇이 무엇을 기다리는지가 한눈에 보여야 해요. 일정표를 어떻게 읽어야 지연이 보이는지는 일정표에서 지연 신호를 어떻게 읽나에서 다뤘어요.

발주자는 어떤 방식으로 일정을 늦추나요?

일정 지연의 원인을 개발사 쪽에서만 찾으면 고칠 수 있는 게 없어요. 발주자 쪽에서 만들어지는 지연은 유형이 분명하고, 그래서 미리 막을 수도 있어요.

여섯 줄 모두 개발과 무관해요. 그런데도 일정에 미치는 영향은 큰 편이에요. 기간을 줄이고 싶다면 개발사에 요구하기 전에 이 표부터 자기 팀에 적용해 보는 게 순서예요.

이 유형들이 잘 안 보이는 이유는 하나하나가 짧기 때문이에요. 답변 한 번, 자료 한 건, 회의 한 차례처럼 개별로 보면 사소한 크기예요. 그런데 이런 대기가 프로젝트 내내 반복되면서, 그리고 서로 겹치면서 일정에 자리를 잡아요. 지연은 큰 사고가 아니라 작은 대기의 누적으로 만들어져요.

결정을 하루 미루면 왜 하루보다 더 밀리나요?

결정 지연이 위험한 이유는 지연이 그대로 전달되지 않고 불어나기 때문이에요. 답을 기다리는 동안 그 자리를 비워두는 게 아니라 다른 일을 시작하게 되는데, 나중에 답이 오면 이미 시작한 일과 맞물려서 손댈 곳이 늘어나요.

게다가 한 사람이 한 가지를 붙잡고 있을 때는 그쪽이 멈추면 그 사람의 다음 작업까지 자리가 밀려요. 그래서 결정은 정확하게 내리는 것보다 정해진 날에 내리는 것이 일정에는 더 유리할 때가 있어요. 되돌릴 수 있는 결정이라면 특히 그래요.

그래서 일정을 관리한다는 건 진척을 확인하는 일이 아니라 대기를 없애는 일에 가까워요. 매주 회의에서 남길 결론도 진행률 숫자가 아니라, 이번 주에 누가 무엇을 언제까지 주기로 했는지예요.

실무에서 쓸 수 있는 규칙은 단순해요. 되돌리기 쉬운 결정은 그 자리에서 내리고, 되돌리기 어려운 결정만 회의를 잡아요. 데이터 구조나 결제 방식처럼 뒤에서 바꾸기 힘든 항목만 신중하게 다루면 돼요.

빨리 해달라는 요청은 왜 일정에 반영되지 않나요?

이 말이 안 먹는 이유는 상대가 노력을 안 해서가 아니라, 문장 안에 상대가 실행할 수 있는 내용이 없어서예요. 무엇을 빼도 되는지, 무엇을 나중으로 미뤄도 되는지, 어떤 기준으로 덜 만들어도 되는지가 빠져 있으니까요.

덧붙이면 이 말은 부작용도 있어요. 속도를 요구받은 쪽은 무엇을 줄여도 되는지 모르는 상태라, 줄여도 되는 걸 줄이는 대신 눈에 안 보이는 쪽을 줄여요. 확인을 덜 하거나, 예외 처리를 건너뛰거나, 나중에 정리하기로 미루는 식이죠. 그건 기간을 줄인 게 아니라 되갚을 항목을 늘린 거예요.

일정을 실제로 움직이는 말은 권한을 주는 말이에요. 빼도 된다는 허락, 미뤄도 된다는 합의, 이 정도면 됐다는 기준선 같은 것들이요.

오른쪽 열의 공통점이 보이나요. 전부 발주자가 무언가를 결정해 주는 문장이에요. 속도를 요구하는 대신 결정을 넘기는 것, 그게 발주자가 기간에 개입하는 거의 유일한 방법이에요.

덜 만들기로 했다면 무엇을 합의해 둬야 하나요?

덜 만들기로 한 결정은 말로만 남으면 나중에 분쟁이 돼요. 출시 뒤에 이게 왜 없느냐는 이야기가 나오면 뺀 게 아니라 빠뜨린 게 되니까요. 그래서 빼기는 반드시 기록으로 남겨야 해요.

남길 내용 중에서 제일 중요한 건 다시 볼 시점이에요. 무엇을 뺐는지와 왜 뺐는지는 회의록만 뒤져도 나오지만, 언제 다시 볼지는 아무도 안 적어 두거든요. 다시 볼 시점이 적혀 있어야 빼기가 포기가 아니라 순서 조정이 돼요.

표를 따로 만들 것까지도 없어요. 회의록 맨 아래에 다섯 칸만 붙여 두면 충분해요. 중요한 건 형식이 아니라 빼기가 문서 어딘가에 남아 있다는 사실이에요.

빼기를 기록하지 않으면 또 하나 생기는 문제가 있어요. 같은 논의가 반복돼요. 회의 때마다 누군가 그 기능을 다시 꺼내고, 왜 뺐는지를 다시 설명하고, 다시 합의하는 데 시간을 써요. 결정 자체보다 결정을 다시 하는 일이 일정을 더 먹어요.

덜 만들기로 한 범위는 견적과 계약에도 그대로 이어져야 해요. 범위가 줄었는데 문서가 그대로면 나중에 어느 쪽이 맞는지를 두고 시간을 쓰게 돼요. 견적서에서 무엇을 확인해야 하는지는 견적서에서 범위와 제외를 어떻게 확인하나에 정리돼 있어요.

짧은 기간 안에 확인하려면 무엇을 어떻게 나눠야 하나요?

기간이 짧을수록 한 번에 확인하는 단위를 작게 쪼개야 해요. 마지막 주에 몰아서 확인하면 그때 나온 수정 요청을 반영할 시간이 남아 있지 않거든요. 반대로 매주 동작하는 상태를 확인하면 어긋난 방향을 그 주 안에서 되돌릴 수 있어요.

여기서 확인이란 화면 캡처를 보는 게 아니라 직접 눌러보는 것이에요. 눌러봐야 빠진 흐름이 보이고, 빠진 흐름을 일찍 발견할수록 고치는 비용이 작아요. 주 단위로 어떻게 굴리는지는 매주 돌아가는 버전을 어떻게 확인하나에서 운영 방식으로 다뤘어요.

확인 주기를 짧게 가져가는 건 감시가 아니라 보험이에요. 어긋난 방향은 늦게 발견할수록 되돌릴 양이 커지니까요. 같은 수정 요청도 그 화면을 만든 주에 오면 손질이고, 출시 직전에 오면 재작업이에요.

쪼개는 기준도 중요해요. 기능별로 쪼개는 것보다 사용자가 한 번에 겪는 흐름으로 쪼개는 게 나아요. 가입 화면만 완성된 상태는 눌러볼 수 없지만, 가입부터 첫 사용까지 이어지는 흐름은 짧아도 눌러볼 수 있으니까요.

확인 자리에서 발주자가 할 일도 정해져 있어요. 좋다거나 아쉽다는 감상이 아니라, 이 상태로 넘어가도 되는지에 대한 가부예요. 가부가 안 나오면 그 화면은 확인을 받은 게 아니라 확인 대기로 한 주를 더 보내게 돼요.

직접 만드는 길이 기간을 줄여주는 경우는 언제인가요?

기간을 줄이는 결정 중에는 만드는 방식 자체를 바꾸는 것도 있어요. 다만 이건 만능 선택지가 아니라 조건부 선택지예요. 판단 기준은 검증하려는 게 시장인가, 만드는 방식 자체인가예요.

확인하려는 게 사람들이 돈을 낼지, 쓸지 같은 시장 쪽 질문이고, 화면과 흐름이 일반적인 형태로 표현된다면 직접 만드는 길이 착수 시점을 크게 앞당겨요. 반대로 우리만의 처리 방식이나 데이터 구조가 제품의 핵심이라면, 직접 만들기 시작했다가 도중에 갈아타면서 기간이 늘어나요.

만드는 방식은 한 번 정하면 되돌리는 비용이 큰 결정이에요. 그래서 이 결정은 급해질 때가 아니라 착수 전에 내려야 해요. 일정이 밀린 뒤에 방식을 바꾸는 건 남은 기간을 줄이는 게 아니라 처음부터 다시 시작하는 것에 가까워요.

이 결정을 내리면 어떤 부류의 도구가 답이 되는지는 갈래가 정해져 있어요. 각 갈래에서 실제로 무엇을 쓰고 어디까지 되는지는 코딩 없이 직접 만드는 길은 어디까지 가능한가에서 따로 다뤘어요.

줄인 기간은 어디서 되갚게 되나요?

기간을 줄이는 결정에는 거의 언제나 청구서가 따라붙어요. 문제는 청구서가 언제, 어떤 형태로 오는지 모르고 결정할 때예요. 알고 선택하면 관리할 수 있는 부담이지만, 모르고 선택하면 출시 직후에 갑자기 나타나요.

오른쪽 두 열을 보면 되갚는 시점이 전부 출시 이후예요. 그래서 기간을 줄이는 결정은 출시일까지만 보고 내리면 안 되고, 출시 뒤 몇 주까지 포함해서 봐야 해요.

되갚는다는 말을 부정적으로만 읽을 필요는 없어요. 검증이 목적이라면 나중에 갚기로 하고 지금 앞당기는 게 맞는 선택일 때도 있어요. 중요한 건 갚을 항목이 무엇인지 적어 두는 거예요. 적어 두면 계획이고, 안 적어 두면 사고가 돼요.

이 표를 미리 보면 좋은 이유가 하나 더 있어요. 출시 직후에 생길 일을 알고 있으면 그때 쓸 시간과 사람을 미리 비워 둘 수 있거든요. 출시일만 목표로 잡은 계획은 출시 다음 주에 아무 자리도 남겨두지 않아서, 되갚을 일이 전부 급한 일로 들어와요.

날짜가 이미 박혀 있다면 무엇부터 정해야 하나요?

날짜를 못 바꾸는 상황이라면 순서는 거꾸로예요. 무엇을 만들지 정하고 기간을 재는 게 아니라, 기간에 맞춰 무엇을 뺄지 정하는 거예요.

날짜가 먼저 정해진 상황에서 가장 흔한 실수는 목록을 그대로 둔 채 일정만 압축하는 거예요. 만들 것은 그대로인데 기간만 줄이면 줄어드는 건 기간이 아니라 완성도예요. 그리고 그 완성도는 출시 직전 검수에서 한꺼번에 드러나요.

순서는 이렇게 잡으면 돼요. 먼저 그날 반드시 돌아가야 하는 흐름을 하나로 못 박아요. 그다음 그 흐름에 안 걸리는 기능을 목록에서 빼요. 그러고 나서 승인과 심사처럼 우리가 줄일 수 없는 구간을 일정 맨 앞으로 당겨요. 마지막으로 결정과 자료의 담당자와 기한을 붙여요.

이 네 가지가 정해지면 개발사는 속도를 요구받지 않아도 빨라져요. 되물을 일이 줄고, 기다릴 일이 줄고, 다시 만들 일이 줄어드니까요. MVP 전반이 어떤 흐름으로 굴러가는지는 MVP는 무엇이고 어떤 순서로 만드나에서 처음부터 훑을 수 있어요.

포텐랩이 발주자와 일정을 잡을 때도 첫 회의에서 정하는 건 기능 목록이 아니라 이 네 가지예요. 기간은 만드는 사람의 속도보다 정하는 사람의 준비에서 더 크게 갈리거든요.

기간 단축 결정을 어떤 순서로 점검하면 되나요?

마지막으로 이 글의 판단 기준을 한자리에 모아 둘게요. 일정 회의에 들어가기 전에 이 순서대로 확인하면 무엇을 빼야 할지가 정리돼요.

점검 항목을 나열하기 전에 하나만 짚을게요. 이 글에서 계속 갈라 본 기준은 결국 되돌릴 수 있는가 하나예요. 되돌릴 수 있는 것은 지금 빼고, 되돌릴 수 없는 것은 지금 정해요. 이 한 줄만 들고 회의에 들어가도 목록이 빠르게 정리돼요.

• 이번 출시로 확인하려는 질문을 한 문장으로 쓸 수 있나요
• 그 문장에 안 걸리는 기능을 목록에서 빼 뒀나요
• 뺀 항목이 지우는 빼기인지 미루는 빼기인지 갈라 놨나요
• 밑에 깔리는 구조를 미루는 쪽에 넣지는 않았나요
• 승인과 심사처럼 우리가 못 줄이는 구간을 맨 앞에 뒀나요
• 결정권자와 답변 기한이 정해져 있나요
• 자료 목록에 담당자와 마감일이 붙어 있나요
• 매주 눌러볼 수 있는 상태를 받기로 합의했나요
• 빼기로 한 항목을 언제 다시 볼지 적어 뒀나요

아홉 줄 중에 개발 속도에 관한 항목은 하나도 없어요. 기간을 줄이는 결정은 결국 발주자의 자리에서 내려지고, 그 결정이 얼마나 일찍 명확해지는지가 출시일을 정해요. 계약 전에 무엇을 확인해야 하는지는 계약 전에 무엇을 확인해야 하나에서 항목별로 볼 수 있어요.

자주 묻는 질문

개발 인원을 늘려 달라고 하면 기간이 줄어드나요?

항상 그렇지는 않아요. 사람이 늘면 나눠 줄 수 있는 일은 빨라지지만, 나눌 수 없는 일에는 효과가 없고 대신 서로 맞추는 대화가 늘어나요. 특히 이미 진행 중인 프로젝트에 사람을 더하면 기존 인원이 설명하는 데 시간을 써요. 인원을 묻기 전에 지금 무엇이 무엇을 기다리고 있는지부터 확인하는 게 순서예요.

AI 코딩 도구를 쓰면 기간이 얼마나 줄어드나요?

숫자로 답하기 어려운 질문이에요. 줄어드는 폭은 도구 자체보다 만들 것이 얼마나 명확하게 정해져 있는지에 달려 있거든요. 무엇을 만들지가 흔들리는 상태에서는 만드는 속도가 빨라져도 다시 만드는 횟수가 함께 늘어서 총 기간이 그대로일 수 있어요. 도구는 만드는 시간에만 작용하고 정하는 시간과 기다리는 시간에는 작용하지 않아요.

기간을 줄이면 비용도 같이 줄어드나요?

연결돼 있지만 같은 방향으로만 움직이지는 않아요. 만들 것을 줄여서 기간이 짧아지면 비용도 함께 내려가요. 반면 같은 범위를 그대로 두고 기간만 압축하면 인원이나 일정 부담이 늘어서 비용은 오히려 올라갈 수 있어요. 기간과 비용을 같이 줄이려면 손대야 할 건 일정표가 아니라 기능 목록이에요.

지금 개발팀이 없다면 채용 시간까지 포함해서 비교해야 하나요?

네. 사내에서 만들기로 했다면 채용과 합류에 걸리는 시간이 착수일을 뒤로 미루니까 그 구간까지 같은 달력에 올려놓고 봐야 해요. 이미 팀이 있다면 이야기가 달라지고요. 다만 어느 쪽을 고르든 결정을 얼마나 빨리 내리는지가 기간을 더 크게 흔들어서, 방식을 바꾸는 것보다 결정 구조를 정리하는 쪽이 효과가 빠르기도 해요.

스토어 심사 기간은 일정에 어떻게 잡아야 하나요?

우리가 줄일 수 없는 구간이라 일정 맨 끝이 아니라 맨 앞에서 계획해야 해요. 개발자 계정 생성과 사업자 확인 같은 절차도 함께 걸리니 착수 시점에 신청부터 해두세요. 심사에서 반려되면 수정하고 다시 제출하는 왕복이 생기니, 제출 시점을 출시일에 붙여 두지 말고 여유를 두고 잡는 게 안전해요.

테스트를 사용자에게 맡기면 기간이 줄어드나요?

일부는 그래요. 다양한 환경에서 써보게 하면 우리 팀이 못 본 문제가 빨리 드러나거든요. 다만 가입, 결제처럼 끊기면 곤란한 흐름은 미리 확인해 둬야 해요. 첫 화면에서 막히면 사용자가 피드백을 남기기 전에 떠나버려서, 검증하려던 것 자체를 확인하지 못하게 돼요.

미뤄 둔 기능이 묻히고 있다는 신호는 어떻게 알아채나요?

신호는 대화에서 먼저 나와요. 회의에서 그 기능 이름이 나왔는데 왜 뺐는지를 아무도 바로 설명하지 못하면, 그건 목록에서 사라졌다는 뜻이에요. 같은 기능을 두고 논의가 처음부터 다시 시작되는 것도 같은 신호고요. 그때는 기능을 다시 논의하지 말고, 뺀 이유와 다시 볼 시점을 적어 둔 자리부터 찾으세요.

이미 일정이 밀린 상태라면 무엇부터 해야 하나요?

남은 기간을 다시 나누기 전에 지금 무엇이 무엇을 기다리고 있는지부터 목록으로 받으세요. 대기 중인 항목 중 발주자가 풀 수 있는 것이 있다면 그게 가장 빠른 조치예요. 그다음 출시일에 반드시 돌아가야 하는 흐름을 다시 못 박고, 거기 안 걸리는 항목을 출시 뒤로 미루는 합의를 문서로 남기면 돼요.

함께 읽으면 좋은 글

• 범위는 어디서 끊나
• 비용은 무엇으로 정해지나
• 기능명세서에 무엇까지 적나