ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 앱개발기간 다시 계산하기, AI 시대에 맞는 기준은 얼마일까
    카테고리 없음 2026. 8. 6. 11:40

    견적서마다 날짜가 다른 이유부터 짚어보겠습니다

    똑같은 기획안을 세 곳에 보냈는데 돌아온 답이 제각각인 경험, 앱을 준비해보신 분이라면 대부분 겪으셨을 겁니다. 금액도 금액이지만 일정이 특히 그렇습니다. 어느 곳은 두 달이면 된다 하고, 어느 곳은 반년을 잡아야 한다고 합니다.

    이럴 때 판단이 서지 않는 것이 당연합니다. 짧게 부르는 쪽이 손이 빠른 것인지, 길게 부르는 쪽이 솔직한 것인지 알 방법이 없기 때문입니다.

    여기에 요즘은 변수가 하나 더 생겼습니다. AI가 코드를 대신 써주는 시대인데 예전 일정을 그대로 받아들여야 하느냐는 물음입니다. 타당한 지적입니다. 몇 년 전에 통용되던 숫자를 지금 그대로 쓰기는 어렵습니다.

    미리 말씀드리면, 업체 간 일정이 갈리는 건 실력 문제가 아니라 무엇까지를 그 기간 안에 넣었느냐에서 비롯됩니다. 인공지능 덕에 빨라진 것도 맞지만 모든 공정이 같은 비율로 당겨진 것은 아닙니다. 그리고 지나치게 촉박한 일정에는 여전히 사연이 있으며, 그 사연은 대개 착수한 뒤에 모습을 드러냅니다.

    이 글에서는 공정별로 실제 얼마가 필요한지, AI가 손대준 구간은 어디까지인지, 업체마다 답이 갈리는 세 가지 배경은 무엇인지, 마지막으로 무리 없이 일정을 앞당기는 방법까지 순서대로 짚어보겠습니다. 일정은 곧 사업의 문제입니다. 오픈 날짜를 믿고 광고를 걸어두고 사람까지 뽑아뒀는데 출시가 미뤄지면, 그 손실은 온전히 의뢰자가 떠안게 됩니다.

     

    기획에서 출시까지, 요즘은 이 정도가 듭니다

    공정을 하나씩 떼어놓고 보겠습니다. 출발점은 기획입니다. 무엇을 만들지 확정하고 화면 이동과 정책을 정리하는 작업으로, 규모에 따라 2주에서 한 달 남짓이 필요합니다. 이어지는 디자인은 뼈대만 있던 화면에 옷을 입히는 과정이고 대략 2주에서 4주가 소요됩니다.

    이 앞쪽 두 공정을 서둘러 넘기면 뒤에서 몇 배로 갚게 됩니다. 기획이 흔들린 채 개발에 들어가면 만들어놓은 화면을 다시 뜯는 일이 반복되기 때문입니다. 초반 일정을 아끼려다 전체가 길어지는 전형적인 경우입니다.

    다음이 개발입니다. 앱 화면과 서버를 실제로 구축하는 구간이고 기능 규모에 따라 한 달에서 석 달 이상까지 편차가 가장 큽니다. AI 도구의 영향을 가장 크게 받은 곳도 여기입니다. 그 뒤로 오류와 기기 호환성을 잡는 테스트가 2주에서 3주, 마지막으로 애플과 구글에 올려 심사를 받는 절차가 붙습니다. 심사 자체는 며칠이면 끝나지만 반려되면 고쳐서 다시 줄을 서야 합니다.

    합쳐보면 기능이 단출한 앱은 한 달에서 두 달, 결제나 예약처럼 흔히 필요한 기능이 들어간 서비스라면 3개월에서 4개월 정도가 지금 시점의 합리적인 앱개발기간입니다. 얼마 전까지는 같은 규모에 여섯 달을 잡는 것이 관행이었지만, 개발 공정이 압축되면서 전체 스케줄도 함께 앞당겨졌습니다.

    그러니 지금 여섯 달짜리 일정을 제안받으셨다면 근거를 확인해보실 만합니다. 정말 기능이 방대한 것인지, 아니면 예전에 쓰던 산정표를 손보지 않고 그대로 꺼낸 것인지 말입니다.

    덧붙이면 공정이 일렬로만 흐르지는 않습니다. 디자인이 끝난 화면부터 먼저 개발에 들어가는 식으로 겹쳐 돌리면 단순 덧셈보다 총 기간이 짧아집니다. 다만 이런 병행은 진행을 촘촘히 챙길 수 있을 때 성립하는 이야기이고, 관리가 느슨하면 오히려 되돌리는 일이 늘어 기간이 불어납니다.

     

    AI로 짧아진 구간은 어디까지일까요

    여기서 한 번 정리하고 가야 할 것이 있습니다. 개발이 빨라진 것은 분명한 사실이지만, 앱을 만드는 모든 공정이 고르게 단축된 것은 아니라는 점입니다. 이걸 구분하지 못하면 일정 계산이 어긋납니다.

    확실하게 시간이 줄어든 쪽은 손이 많이 가는 반복 작업입니다. 화면의 기본 골격을 세우는 일, 데이터를 저장하고 불러오는 정형화된 코드, 테스트 코드를 채워 넣는 작업, 처음 다루는 라이브러리 사용법을 뒤지던 시간이 여기 해당합니다. 조사 기관마다 제시하는 수치는 제각각이지만, 이런 반복 코딩에서 시간이 크게 절약된다는 점은 대체로 일치합니다.

    반면 거의 그대로인 구간도 있습니다. 무엇을 만들 것인지 결정하는 과정, 의뢰자 쪽 확인과 회신을 기다리는 시간, 여러 시스템을 연결하고 예외 상황을 하나씩 막는 작업, 실기기에서 직접 돌려보는 검증, 그리고 스토어 심사입니다. 이 공정들은 코드 작성 속도와 무관하게 흘러갑니다.

    짚어둘 만한 결과도 있습니다. 경력이 쌓인 개발자를 대상으로 진행한 통제 실험에서는 AI 도구를 사용했을 때 완료까지 오히려 더 오래 걸렸다는 보고가 나오기도 했습니다. 생성된 코드를 읽고 맞는지 따져보고 손보는 시간이 추가되기 때문입니다. 결국 도구를 얼마나 능숙하게 부리느냐에서 결과가 갈립니다.

    요약하면 이렇습니다. AI는 만드는 속도는 끌어올려주지만 판단하는 속도와 확인하는 속도까지 끌어올려주지는 않습니다. 그래서 전체 일정이 짧아진 지금은 기획과 검증이 차지하는 비중이 상대적으로 더 커졌다고 이해하시는 편이 맞습니다.

     

    첫째, 같은 3개월이 서로 다른 3개월입니다

    업체마다 답이 갈리는 첫 번째 배경은 범위를 어디까지 잡느냐입니다. 어떤 곳은 기획과 디자인, 검증까지 통째로 넣어 여섯 달을 이야기합니다. 다른 곳은 코드를 짜는 구간만 떼어 석 달이라고 답합니다. 동일한 프로젝트인데 겉으로 드러난 숫자는 두 배로 벌어집니다. 어느 쪽도 속인 것은 아니지만, 나란히 놓고 비교할 수 없는 숫자인 것입니다.

    가장 흔히 빠지는 것이 운영자용 화면입니다. 이용자가 쓰는 앱만 헤아리고 회원 관리나 콘텐츠 등록처럼 뒤에서 돌아가는 시스템을 계산에서 제외하는 경우인데, 이 부분이 전체 작업량에서 차지하는 몫은 결코 가볍지 않습니다. 여기에 서버 세팅, 심사 대응, 출시 직후 자잘한 문제를 잡는 기간까지 얹으면 격차는 더 커집니다.

    그래서 일정을 견줘보실 때는 총 몇 개월이냐고 묻는 대신 공정별로 쪼갠 표를 요청하시는 편이 낫습니다. 기획 몇 주, 디자인 몇 주, 개발 몇 주, 검증 몇 주로 나뉜 문서를 내놓는 곳과 개월 수만 툭 던지는 곳은 무게가 다릅니다. 그 표 안에 운영자 화면과 심사 기간이 들어가 있는지도 같이 살펴보시면 좋습니다.

     

    둘째, 몇 명이 어떻게 붙느냐가 속도를 만듭니다

    두 번째 배경은 인력 배치입니다. 개발자 두 사람이 이 프로젝트만 붙잡고 있는 경우와, 한 사람이 다른 일을 끼고 틈틈이 진행하는 경우는 작업량이 같아도 걸리는 날짜가 달라집니다. 서류상으로는 똑같은 석 달이어도 실제로 투입된 시간은 전혀 다를 수 있습니다.

    일을 다시 아래로 넘기는 구조인지도 속도를 좌우합니다. 사이에 한 단계가 끼면 간단한 질문 하나에도 며칠이 흐르고, 고쳐달라는 요청이 반영되기까지의 시간도 길어집니다. 상담 자리에서 실제로 누가 몇 명 붙는지, 개발을 그 회사가 직접 수행하는지 확인해보시면 제시된 일정을 얼마나 믿어도 될지 감이 잡힙니다.

    중간에 결과물을 확인하는 절차가 마련되어 있는지도 놓칠 수 없는 부분입니다. 2주에 한 번씩 진행 상황을 보여주는 방식이라면 방향이 틀어져도 초기에 되돌릴 수 있습니다. 반대로 완성 전까지는 보여드릴 것이 없다고 하는 곳은 막판에 대대적인 수정이 몰리면서 일정이 한꺼번에 무너지는 일이 잦습니다.

     

    셋째, 짧게 부르는 데는 이유가 따로 있습니다

    세 번째가 가장 조심하셔야 할 대목입니다. 수주를 위해 일정을 실제보다 짧게 제시하는 경우입니다. 우선 한 달이면 된다고 말해두고 착수한 다음, 진행 과정에서 이 기능은 시간이 더 든다며 조금씩 늘려가는 방식입니다. 이미 계약서에 서명하고 착수금까지 넣은 의뢰자는 끌려갈 수밖에 없습니다. 앱을 만드는 과정에 익숙하지 않을수록 이런 방식에 걸려들기 쉽습니다.

    근래에는 여기에 AI가 홍보 문구로 얹힙니다. 인공지능으로 작업하니 몇 주면 충분하다는 식입니다. 앞서 정리한 대로 AI가 덜어주는 것은 코드를 작성하는 시간이지 기획과 검증을 포함한 전체 일정이 아닙니다. AI를 쓴다는 이유만으로 기간이 반으로 준다고 설명하는 곳이 있다면, 그 절반이 정확히 어느 공정에서 나왔는지 짚어달라고 하셔야 합니다.

    만약 정말로 그 짧은 일정에 맞춰 끝낸다면 어딘가는 깎여 나갑니다. 제일 먼저 잘리는 것이 검증 기간입니다. 확인 없이 세상에 나온 앱은 이용자를 시험 대상으로 삼는 셈이 되고, 출시 초기의 오류와 낮은 별점으로 값을 치르게 됩니다. AI가 코드를 대량으로 뽑아내는 지금은 이 위험이 더 커졌습니다. 생산된 분량은 늘었는데 사람이 눈으로 확인한 분량은 그만큼 늘지 않았기 때문입니다.

    그래서 저는 유난히 촉박한 일정을 제안받으셨다면 그 안에 검증이 몇 주 잡혀 있는지 되물어보시라고 말씀드립니다. 이 한 가지 질문에 돌아오는 답이 얼마나 구체적인가에서, 그 일정이 계산해서 나온 숫자인지 영업을 위해 부른 숫자인지 상당 부분 드러납니다.

    계약 문서에 일정 조항을 담아두는 것도 좋은 장치입니다. 공정별 완료 시점과 그때 넘겨받을 산출물을 적어두고 무엇을 끝낸 상태를 완료로 볼지 정해두면, 진행 중이라는 답변만 되풀이되는 상황을 피할 수 있습니다. 일정이 밀렸을 때 어느 쪽 책임인지 가늠할 잣대도 함께 마련됩니다.

     

    급하시다면 일정이 아니라 기능을 덜어내십시오

    오픈 시점을 앞당겨야 할 사정이 있으시다면, 날짜를 조여 붙이는 대신 담을 것을 덜어내는 쪽이 정답입니다. 서비스가 통하는지 확인할 만큼의 최소 기능만 실어 먼저 내보내는 방식, 흔히 MVP라고 부르는 접근입니다. 넣을 기능을 절반으로 줄이면 앱개발기간은 실제로 짧아지고 완성도를 깎을 필요도 없습니다. 똑같은 두 달이라도 모든 기능을 허겁지겁 밀어 넣은 두 달과 핵심만 차분히 다듬은 두 달은 나오는 결과가 완전히 다릅니다.

    AI 도구가 일상화되면서 이 방식의 매력은 한층 커졌습니다. 만드는 속도가 붙은 만큼 첫 출시 이후 기능을 덧붙이는 간격도 촘촘해졌기 때문입니다. 예전에는 다음 버전까지 몇 달을 기다려야 했으니 처음부터 다 담으려는 조급함이 생겼지만, 지금은 반응을 확인하고 얹어가는 편이 분명히 유리합니다.

    먼저 내놓아 얻는 이득은 시간만이 아닙니다. 실제 이용자가 어떻게 쓰는지 보고 다음에 만들 것의 순서를 정할 수 있어서, 결국 아무도 건드리지 않을 기능에 몇 달을 쏟는 낭비가 애초에 생기지 않습니다. 요즘 기준으로 최소 기능만 담은 앱은 한 달에서 두 달 사이면 출시를 논의할 수 있는 수준에 이릅니다.

    일정에는 의뢰자 쪽에서 보탤 수 있는 몫도 있습니다. 필요한 자료가 늦게 넘어오거나 회신이 밀리면 그만큼 뒤로 밀립니다. 시안을 제때 봐주시고 테스트에 참여해주시고 결정 사항을 빠르게 알려주시는 것만으로도 전체 진행이 몇 주씩 당겨지는 일이 흔합니다.

    진행 도중의 기능 추가 요청 역시 지연의 큰 축입니다. 만들어지는 것을 보다 보면 욕심이 생기는 게 자연스럽지만, 그때마다 범위를 벌리면 끝나는 날은 계속 뒤로 갑니다. 새로 떠오른 생각은 다음 버전 목록에 적어두고 1차 범위는 지켜내는 것, 일정을 관리하는 가장 실전적인 원칙입니다.

     

    마무리 — 약속한 날짜를 지키는 쪽이 결국 빠릅니다

    토리토시스템은 20년 넘게 현장을 지켜온 개발진이 일을 아래로 넘기지 않고 직접 수행합니다. 그래서 일정을 뽑는 사람과 실제로 만드는 사람이 같습니다. AI 도구 역시 실무에서 적극적으로 활용하고 있고, 그만큼 줄어든 시간은 줄어든 대로 일정에 담아 말씀드립니다. 다만 확인하는 일까지 기계에 넘기지는 않습니다.

    오늘 짚어본 내용을 간추리겠습니다. 하나, 흔한 형태의 서비스 앱이라면 기획에서 출시까지 3개월에서 4개월 정도가 지금의 현실적인 기준이며, 예전에 통용되던 여섯 달은 더 이상 들어맞지 않습니다. 둘, 그러나 AI가 덜어준 것은 코드를 쓰는 구간이고 기획과 회신 대기, 연동, 검증, 심사는 예전과 다르지 않습니다.

    셋, 업체 간 일정 차이는 대개 포함 범위에서 비롯되므로 공정별 표를 놓고 비교하셔야 합니다. 넷, 몇 명이 전담으로 붙는지와 직접 개발하는 구조인지가 체감 속도를 결정합니다. 다섯, 지나치게 짧은 일정은 검증을 깎아 만든 숫자인 경우가 많고, AI를 언급하며 반으로 줄인다는 곳에는 어느 공정에서 줄었는지 확인하셔야 합니다. 여섯, 일정을 앞당기고 싶으시다면 압박이 아니라 기능 축소로 접근하시는 편이 안전합니다.

    받아보신 제안서 가운데 유독 날짜가 짧은 것이 있다면 오늘 정리해드린 질문들을 던져보시기 바랍니다. 준비 중이신 서비스에 맞는 일정이 어느 정도인지 가늠이 안 되신다면, 넣고 싶은 기능을 정리해 보내주시는 것만으로도 답을 드릴 수 있습니다.

    앱 개발 상담이 필요하시면 토리토시스템에 편하게 문의해 주세요.

    토리토시스템 공식 홈페이지 바로가기

     

    댓글

Designed by Tistory.