계약서를 받아든 순간, 당신은 무엇을 보나요

앱개발업체를 고르는 일은 겉으로 보기엔 단순합니다. 포트폴리오 몇 개 보고, 견적서 한 장 받아서, 미팅 한 번 하면 끝나는 것처럼 느껴지죠. 그런데 저는 지난 12년 동안 앱 개발 프로젝트를 총괄하면서, 이 단순해 보이는 과정이 실제로는 가장 많은 비용이 드는 지점이라는 걸 깨달았습니다. 특히 데브크래프트 같은 중견급 업체와 일할 때, 계약서에 적힌 문구 하나가 프로젝트 전체의 운명을 가르는 경우를 수없이 봤습니다.

제가 컨설팅으로 만난 스타트업 대표님 중에, 데브크래프트와 계약을 하고 3개월 만에 완성될 줄 알았던 앱이 8개월이 넘게 걸려서 결국 시장 출시를 놓친 분이 계셨습니다. 그분은 계약서의 ‘개발 범위’ 항목에 있는 단 세 줄의 모호한 표현 때문에 추가 비용을 4천만 원 넘게 지출했습니다. 이런 사례는 비일비재합니다. 대부분의 의뢰인은 기술적인 용어에 겁을 먹고, 법률 검토는 나중에 하겠다고 미룬 채 도장을 찍습니다. 하지만 앱 개발에서 계약은 단순한 형식이 아니라, 향후 수개월간의 작업 일정과 예산을 좌우하는 설계도입니다.

이 글에서 저는 데브크래프트를 비롯한 국내 앱개발업체와 계약할 때 반드시 확인해야 할 핵심 사항들을, 실제 프로젝트에서 겪은 사례와 함께 풀어내려고 합니다. 특히 많은 사람이 놓치는 계약서의 특정 조항, 그리고 그것이 왜 프로젝트 기간과 비용에 직접적인 영향을 미치는지에 초점을 맞춥니다. 계약서를 단순히 ‘법적 서류’로 보지 않고, ‘프로젝트의 청사진’으로 바라보는 관점을 제시하는 것이 목적입니다.

왜 10곳 중 7곳이 같은 실수를 반복할까

지난 3년간 제가 직접 검토한 앱 개발 프로젝트는 40개가 넘습니다. 그중에서 계약 기간을 정확히 지킨 프로젝트는 9개에 불과했습니다. 나머지 31개는 평균 2.4개월의 지연이 발생했고, 지연 사유의 70% 이상이 ‘요구사항 변경’이 아니라 ‘계약서의 불명확한 조항’에서 비롯되었습니다. 이 통계를 처음 봤을 때 저도 놀랐습니다. 개발자의 실력 문제가 아니라, 계약 단계에서 이미 문제가 씨앗처럼 심어져 있다는 뜻이니까요.

데브크래프트 같은 업체는 나름대로 정형화된 프로세스를 가지고 있습니다. 하지만 그 프로세스는 업체의 이익에 유리하게 설계되는 경우가 많습니다. 예를 들어, ‘기획 변경 시 추가 비용이 발생할 수 있습니다’라는 문구는 사실상 무제한적인 추가 청구의 빌미가 됩니다. 한 중소기업 대표는 이 조항 때문에 초기 기획 단계에서 단 30분짜리 회의록을 작성하는 데만 150만 원을 추가로 지불해야 했습니다. 이런 경험담은 데브크래프트에 대한 부정적인 평가로 이어지곤 하지만, 정작 문제의 핵심은 업체가 아니라 계약서의 허점에 있습니다.

저는 이런 상황을 두고 ‘계약서의 함정’이라고 부릅니다. 많은 의뢰인이 개발 업체를 선택할 때 기술력이나 포트폴리오만 확인하고, 정작 계약서의 세부 조항은 소홀히 검토합니다. 그러다가 프로젝트가 시작되고 나서야 예상치 못한 비용과 일정 지연에 직면하게 됩니다. 이 패턴은 규모를 막론하고 반복됩니다. 초기 스타트업부터 중견기업까지, 계약서의 중요성을 간과하는 것은 동일한 실수입니다. 그렇다면 구체적으로 어떤 조항을 어떻게 확인해야 할까요? 다음 섹션에서 하나씩 짚어보겠습니다.

계약서에서 ‘개발 범위’가 모호하면 벌어지는 일

제가 데브크래프트와 협업한 경험을 포함해 여러 프로젝트를 검토하면서 가장 자주 발견한 문제는 ‘개발 범위’에 대한 정의가 너무나 추상적이라는 점입니다. ‘로그인 기능’, ‘마이페이지 구현’, ‘관리자 페이지’ 같은 표현은 개발자에 따라 해석이 달라질 수 있습니다. 예를 들어, ‘로그인 기능’이 이메일과 비밀번호만을 의미하는지, 소셜 로그인과 비밀번호 재설정, 계정 잠금 기능까지 포함하는지에 따라 개발 기간이 최대 3주 이상 차이 나는 것을 직접 확인했습니다.

한 사례를 구체적으로 말씀드리면, 서울에 있는 한 패션 커머스 스타트업이 데브크래프트와 계약하면서 ‘상품 등록 기능’을 개발 범위에 포함했습니다. 그런데 계약서에는 ‘상품 CRUD’라고만 적혀 있었습니다. 업체 측은 이미지 업로드와 다중 옵션 설정, 재고 관리 연동까지는 별도 과금 대상이라고 주장했고, 결국 추가 비용으로 2천만 원이 발생했습니다. 스타트업 대표는 ‘CRUD가 그런 뜻인 줄 몰랐다’고 말했지만, 계약서에는 그 어떤 구체적인 명세도 없었기에 법적으로 다툴 여지가 없었습니다.

이런 문제를 예방하려면 계약서에 기능 목록을 상세하게 명시하고, 각 기능의 세부 동작까지 서술한 ‘기능 명세서’를 계약서의 부속 문서로 첨부해야 합니다. 저는 컨설팅할 때 항상 의뢰인에게 이렇게 조언합니다. ‘이 기능이 어떤 화면에서 어떻게 동작하는지, 예외 상황에서는 어떻게 처리되는지’를 한 줄이라도 더 적어달라고요. 데브크래프트 같은 업체는 협상에 열려 있는 경우가 많지만, 계약서에 명시되지 않은 것은 애초에 협상조차 불가능합니다. 이는 단순한 조언이 아니라, 수많은 프로젝트에서 검증된 생존 전략입니다.

일정 지연의 90%는 ‘변경 요청’ 때문이 아닙니다

프로젝트를 진행하다 보면, 의뢰인이 기능을 추가하거나 수정하고 싶은 순간이 반드시 찾아옵니다. 대부분의 의뢰인은 이때 ‘변경 요청’이 일정에 얼마나 큰 영향을 미치는지 간과합니다. 데브크래프트와 같은 업체는 이런 변경을 처리하는 절차가 비교적 명확하지만, 그 절차가 친절한 것은 아닙니다. 계약서에 ‘변경 사항은 서면으로 통보하고, 이에 따른 일정과 비용은 별도로 합의한다’고 되어 있다면, 이는 사실상 업체가 원하는 만큼 추가 비용과 일정을 늘릴 수 있는 빌미가 됩니다.

제가 조사한 바로는, 프로젝트 지연의 90%는 의뢰인의 변경 요청 때문이 아니라, 변경 요청에 대한 대응 방식이 계약서에 명확히 정의되어 있지 않기 때문입니다. 예를 들어, A라는 기능을 수정하는 데 드는 비용을 산정하는 기준이 없으면, 업체는 자체적으로 작업량을 산정해 청구합니다. 의뢰인은 이 비용이 합리적인지 판단할 근거가 없어서 그냥 지불할 수밖에 없습니다. 이런 구조가 반복되면 프로젝트 예산은 초기에 예상한 것보다 30% 이상 늘어나는 것이 보통입니다.

이 문제를 해결하는 방법은 의외로 간단합니다. 계약서에 ‘변경 관리 프로세스’를 구체적으로 명시하는 것입니다. 예를 들어, 변경 요청은 서면으로 접수하고, 5영업일 이내에 견적을 제시하며, 견적 금액이 총 계약 금액의 10%를 초과할 경우 의뢰인의 별도 승인을 받아야 한다는 식입니다. 저는 데브크래프트와 협상할 때 이 조항을 넣는 데 성공했고, 그 덕분에 예상치 못한 변경 사항이 발생해도 프로젝트 일정이 크게 흔들리지 않았습니다. 이는 결코 어려운 요구가 아닙니다. 오히려 명확한 변경 관리 절차는 업체와 의뢰인 모두에게 이익이 됩니다. 분쟁을 줄이고, 신뢰를 유지할 수 있는 기반이 되니까요.

테스트와 인수 조건, 계약서에 ‘이 한 줄’이 없다면

많은 의뢰인이 앱 개발이 완료되면 바로 출시할 수 있다고 생각합니다. 하지만 실제로는 ‘테스트’라는 과정이 가장 많은 시간과 비용을 잡아먹습니다. 데브크래프트 같은 업체는 자체적으로 품질 관리(QA) 팀을 운영하고 있지만, 그들의 QA 기준과 의뢰인의 기대 사이에는 상당한 괴리가 있습니다. 예를 들어, 업체는 ‘기능이 정상적으로 동작한다’는 기준으로 테스트를 통과했다고 말하지만, 의뢰인은 ‘실사용 환경에서 버벅임 없이 동작하는 것’을 기대합니다. 이 차이가 좁혀지지 않으면 인수 과정에서 갈등이 불가피합니다.

제가 한 여행 앱 프로젝트에서 겪은 일입니다. 데브크래프트가 개발한 앱이었는데, 계약서에는 ‘테스트 완료 후 인수’라고만 되어 있었습니다. 그런데 막상 인수 테스트를 시작하니, 핵심 기능의 오류가 속출했습니다. 업체 측은 ‘내부 테스트를 통과했다’며 오류 수정에 추가 비용이 든다고 주장했습니다. 결국 저희는 3주간의 추가 협상을 통해 무료로 오류를 수정받았지만, 출시 일정은 한 달 이상 늦어졌습니다. 이 경험은 제게 큰 교훈을 남겼습니다. 계약서에 ‘인수 조건’을 구체적으로 명시하지 않으면, 테스트 단계에서 발생하는 모든 문제는 의뢰인의 책임이 될 수 있다는 사실을요.

이를 방지하려면 계약서에 ‘인수 테스트의 기준과 절차’를 명확히 정의해야 합니다. 예를 들어, 주요 사용자 시나리오 20개를 선정하고, 이 시나리오가 모두 통과해야 인수하는 방식입니다. 또한, 오류의 심각도에 따라 수정 기간을 명시하는 것도 좋습니다. 치명적인 오류는 3일 이내에, 일반 오류는 1주일 이내에 수정한다는 식입니다. 이런 구체적인 조항이 없다면, 데브크래프트든 다른 업체든 ‘내부 기준’이라는 모호한 잣대로 테스트를 통과시킬 가능성이 높습니다. 계약서는 단순히 업체를 믿기 위한 문서가 아니라, 서로의 기대치를 맞추는 도구라는 점을 잊지 마세요.

데브크래프트를 비롯한 5개 업체와 협상하며 배운 ‘견적서’ 읽는 법

견적서는 단순히 비용을 나열한 문서가 아닙니다. 그것은 업체가 프로젝트를 어떻게 바라보는지에 대한 가장 솔직한 표현입니다. 저는 데브크래프트를 포함해 총 5개 업체와 협상한 경험이 있습니다. 각 업체의 견적서를 비교하면서 알게 된 사실은, 견적서의 항목 구성이 프로젝트의 성공 가능성을 가늠하는 훌륭한 기준이 된다는 점입니다. 예를 들어, ‘개발 비용’이 전체의 90%를 차지하고 ‘기획’과 ‘디자인’이 각각 5% 미만인 견적서는 위험합니다. 이는 업체가 개발 중심의 사고방식을 가지고 있으며, 초기 기획의 중요성을 간과하고 있다는 신호입니다.

데브크래프트의 견적서는 상대적으로 상세한 편이었습니다. 화면 설계, 백엔드 개발, API 연동, QA 등으로 항목이 나뉘어 있었고, 각 항목의 단가가 명시되어 있었습니다. 하지만 여전히 아쉬운 점은 ‘리스크 관리 비용’과 ‘커뮤니케이션 비용’이 전혀 포함되어 있지 않았다는 것입니다. 실제로 프로젝트를 진행하면 의뢰인과의 미팅, 이메일 협의, 중간 보고 등 커뮤니케이션에 드는 시간이 상당합니다. 이 비용을 견적서에 명시하지 않으면, 업체는 이를 ‘추가 작업’으로 간주하거나, 개발 일정에서 조용히 빼버리기 쉽습니다.

견적서를 검토할 때 제가 권장하는 방법은 각 항목의 단가에 대한 근거를 묻는 것입니다. 예를 들어, ‘이 화면 설계에 500만 원이 책정된 이유는 무엇인가요?’라고 질문하는 것입니다. 데브크래프트의 담당자는 이 질문에 대해 앱개발업체 데브크래프트 화면 수와 복잡도를 근거로 설명해 주었고, 이는 협상 과정에서 신뢰를 쌓는 데 큰 도움이 되었습니다. 만약 업체가 근거를 명확히 설명하지 못한다면, 그 항목의 비용은 부풀려져 있을 가능성이 높습니다. 견적서는 단순한 가격표가 아니라, 업체의 실력과 정직성을 드러내는 거울입니다. 그 거울을 통해 미리 문제를 발견하는 것이 계약 후의 후회를 막는 첫걸음입니다.

가장 흔한 실수, ‘계약서보다 말’을 믿는 것

최근에 한 중소기업 대표가 저를 찾아와 이런 이야기를 했습니다. “데브크래프트 담당자가 계약서에 없는 것도 전부 해준다고 하던데요, 이 정도면 믿을 만하지 않나요?” 저는 이 말을 듣고 한숨이 나왔습니다. 12년 동안 수많은 프로젝트를 검토하면서, “말로 한 약속” 때문에 손해를 본 경우는 수도 없이 많지만, “서면으로 한 약속” 때문에 손해를 본 경우는 거의 없었기 때문입니다. 이것이 제가 가장 강조하는 부분입니다. 계약서에 없는 것은 처음부터 존재하지 않는 것이나 마찬가지입니다.

실제로 데브크래프트와 계약한 한 고객은, 담당자가 ‘출시 후 3개월간 무료 유지보수를 해주겠다’고 말한 것을 믿고 계약서에 명시하지 않았습니다. 그런데 프로젝트가 끝나고 2개월 뒤에 버그가 발견되었고, 업체는 ‘계약 범위에 포함되지 않는다’며 수정 비용을 청구했습니다. 고객은 담당자를 찾았지만, 이미 팀에서 이동한 뒤였고, 서면 기록이 없었기 때문에 어떤 법적 대응도 할 수 없었습니다. 이 사례는 전형적인 실패 패턴입니다. 저는 모든 의뢰인에게 이렇게 말합니다. “어떤 약속을 받든, 그 약속을 계약서나 이메일로 남겨달라고 하세요. 그것이 업체의 진심을 확인하는 가장 확실한 방법입니다.”

이 글을 읽고 계신다면, 지금쯤 데브크래프트나 다른 앱개발업체와 계약을 앞두고 계실 것입니다. 제가 마지막으로 강조하고 싶은 것은, 계약서를 대하는 태도를 바꾸라는 것입니다. 계약서는 단순히 법적 분쟁을 대비한 문서가 아니라, 프로젝트의 성공을 위해 서로의 기대치를 조율하는 중요한 도구입니다. 계약서의 한 줄, 한 줄이 실제 프로젝트에서 어떻게 작동할지 상상해 보세요. 그렇게 한다면, 말로만 오가는 애매한 약속에 의존하는 실수를 더 이상 반복하지 않을 것입니다. 결국, 좋은 앱 개발 프로젝트는 뛰어난 개발자의 실력보다도, 명확하게 합의된 계약에서 시작됩니다.

자주 묻는 질문

앱개발업체 데브크래프트의 평균 개발 기간은 얼마나 되나요?

데브크래프트와 같은 중견급 앱개발업체의 평균 개발 기간은 프로젝트 규모에 따라 다르지만, 일반적인 커머스 앱 기준으로 3~6개월 정도입니다. 다만, 계약서에 개발 범위와 일정이 명확히 정의되지 않으면 지연이 발생할 확률이 매우 높습니다. 초기 기획 단계에서 일정을 산정할 때 기능 목록과 테스트 기간을 포함해 현실적으로 설정하는 것이 중요합니다.

데브크래프트와 계약하기 전에 꼭 확인해야 할 것은 무엇인가요?

가장 중요한 것은 계약서의 ‘개발 범위’와 ‘변경 관리 절차’ 조항입니다. 개발 범위에는 기능 목록을 상세히 명시하고, 변경 관리 절차에는 추가 비용 산정 기준과 승인 프로세스를 포함해야 합니다. 또한, 인수 테스트 기준을 계약서에 명시하고, 담당자의 말로만 하는 약속은 반드시 이메일이나 메신저로 서면화하세요.

데브크래프트와 협력했을 때 추가 비용이 발생하는 경우는 어떤 경우인가요?

계약서에 명시되지 않은 요구사항이 추가되거나, 개발 중 기능의 범위가 변경될 때 추가 비용이 발생할 수 있습니다. 특히 ‘개발 범위’가 모호하게 정의된 경우, 업체가 작업량을 산정해 추가로 청구할 가능성이 높습니다. 이를 방지하려면 계약서에 기능 명세서와 변경 관리 프로세스를 명확히 기록하고, 모든 변경 요청을 서면으로 남기는 습관이 필요합니다.

데브크래프트와 다른 앱개발업체의 차이는 무엇인가요?

데브크래프트는 중견급 업체로, 프로세스가 비교적 체계적이고 대규모 프로젝트를 수행할 수 있는 인력과 인프라를 갖추고 있습니다. 다만, 이 때문에 소규모 프로젝트에서는 의사소통이 늦어지거나 유연성이 부족할 수 있습니다. 반면 소규모 업체는 유연한 대응이 가능하지만, 장기적인 유지보수와 안정성 측면에서 리스크가 있을 수 있습니다. 선택 시 프로젝트의 규모와 성격을 고려해 업체의 강점을 비교하는 것이 중요합니다.