정부지원사업으로 만든 서비스가 지속 가능하지 않은 이유
정부지원사업 선정 이후, 협약과 개발, 결과 보고까지는 순조롭습니다. 문제는 이듬해부터입니다. 지원금이 커버하지 않는 유지보수, 특약이 없으면 개발사에 귀속되는 소스코드 저작권, 원개발사와의 단절까지, 정부지원사업 서비스 개발에서 협약 단계에 미리 챙길 것들을 정리했습니다.
Aug 10, 2026
정부지원사업으로 앱이나 서비스를 개발하는 과정은 대체로 순조롭게 흘러갑니다. 선정 공고가 난 이후부터 각 분야별 필요 인력 및 외주사들과 협약을 맺고, 개발이 진행되고, 결과 보고서가 들어갑니다. 시연도 잘 됐고 정산도 끝났습니다. 서류상으로는 성공한 사업입니다. 그러나 문제는 그다음 해에 시작됩니다. 서비스는 돌아가고 있는데, 유지 및 보수 작업에 생각보다 시간과 비용이 많이 투입됩니다.
이 글은 창업지원금이나 바우처로 앱 개발을 했거나 앞둔 회사를 위해 씁니다. 지원사업 구조의 어디에서 실질적인 공백이 생기는지, 종료 1년 뒤에 어떤 장면을 마주치게 되는지, 그리고 협약 단계에서 계약서에 무엇을 넣어야 그 장면을 피할 수 있는지. 순서대로 정리합니다.
지원금의 목적은 개발비, 그렇다면 유지 및 보수 관리는?
먼저 규모부터 보겠습니다. 중소벤처기업부 산하 창업진흥원의 2026년 공고 기준으로 예비창업패키지의 사업화 자금은 평균 4천만 원, 창업 3년 이내 기업이 대상인 초기창업패키지는 평균 5천만 원에 최대 1억 원까지입니다. 하나의 앱, 혹은 웹 서비스 하나를 만드는 제작비 구간과 얼추 겹칩니다. 그러니 지원금으로 개발을 완료하는 것 자체는 충분히 가능합니다.
그러나 미묘한 간극은 그다음 구간에서 생깁니다. 소프트웨어 생애비용의 60~80%는 출시 이후의 유지보수와 운영에서 발생하기 때문입니다. 그러나 지원금은 협약 기간의 제작 활동까지만 지원합니다. 서비스 비용에서 가장 큰 덩어리가, 지원이 끝나는 바로 그 지점부터 시작되는 셈입니다. 이 비용 구조는 「유지보수 비용의 진실」에서 자세히 다뤘습니다.
그러나 이 간극은 제도의 맹점이 아닙니다. 지원사업의 목적이 사업화의 시작을 돕는 것이니, 제작 구간을 지원하는 것은 너무나도 자연스러울 뿐더러 사업의 목적과 부합합니다. 문제는 창업지원금을 받은 대표나 의사결정권자가 이 간극을 모른 채 "지원금으로 개발이 끝났다"고 생각할 때 생깁니다. 끝난 것은 제작입니다. 서비스는 이제 막 시작됐을 뿐입니다.
지원사업 일정에 맞춘 개발은 검수가 얕아집니다
지원사업 개발에는 일반 외주 개발에 없는 제약이 하나 더 있습니다. 종료일이 사업 내용이 아니라 회계연도에 맞춰져 있다는 점입니다.
2026년 데이터바우처 지원사업의 일정을 보면 구조가 보입니다. 공모 접수가 2~3월, 선정 평가와 협약이 4~5월. 사업 수행 기간은 6월 1일부터 11월 30일까지입니다. 선정돼도 협약이 끝나야 착수할 수 있고 11월 말까지는 결과가 나와야 하니, 실제 개발에 쓸 수 있는 시간은 6개월 안팎으로 처음부터 정해져 있습니다. 바우처 개발만이 아니라 대부분의 지원사업이 이 당해년도 종료 구조를 공유합니다.
기간이 고정되면 무엇이 조정될 수밖에 없을까요. 결국은, 품질입니다. 개발 후반에 일정이 밀리면 기능 구현이 우선되고, 검수와 문서화가 뒤로 밀립니다. 결과 보고와 시연에 올라가는 화면은 완성도가 높은데 코드 문서, 관리자 매뉴얼, 테스트처럼 눈에 안 보이는 산출물은 얇아집니다. 시연에서 멀쩡히 돌아가던 서비스가 반년 뒤 유지보수 단계에서 문제를 드러내는 이유가 여기 있습니다.
지원사업 종료 1년 뒤, 흔히 마주치는 세 가지 이슈
협약 종료 보고서를 낸 지 여덟 달 뒤, 한 초기 창업기업의 예약 서비스에 첫 장애가 났습니다. 결제 연동이 멈췄는데 협약 기간에 함께 일했던 개발 업체 담당자는 퇴사한 뒤였고, 유지보수 계약은 처음부터 없었습니다. 도메인 갱신 알림은 두 달째 아무도 열어보지 않는 관리자 계정으로 가고 있었습니다. 이 기업이 마주친 상황은 셋으로 나뉩니다. 정부지원사업 앱 개발 이후에 반복되는 전형적인 장면들입니다.
유지보수 계약이 없다
협약 기간의 개발 계약은 종료 보고와 함께 끝납니다. 그 뒤의 장애 대응, 보안 업데이트, 도메인과 호스팅 관리는 누구의 업무도 아닌 상태가 됩니다. 방치된 서비스의 결말은 비슷합니다. 어느 날 도메인이나 호스팅 만료로 접속이 끊기고, 보안 취약점이 쌓인 채로 고객을 만납니다.
소스코드는 받았는데 소유권이 없다
가장 덜 알려진 오류이자 함정입니다. 외주로 만든 프로그램의 저작권은, 계약서에 양도 특약이 없으면 발주자가 아니라 개발사에 귀속되는 것이 원칙입니다. 대법원이 2000년 11월 판결에서 세운 기준입니다. 프로그램 도급계약에는 발주자 귀속을 인정하는 "업무상 저작물" 규정이 적용되지 않는 것이 원칙이라고 판시했습니다.
소스코드 파일을 전달받는 것과 저작권을 양도받는 것은 별개입니다. 파일이 손에 있어도 그렇습니다. 양도 조항이 없으면 나중에 다른 개발사를 통해 이 코드를 고치거나 확장할 때 법적 문제가 생길 수 있습니다. 결과 보고서에 소스코드 제출이 포함돼 있었다고 해서 소스코드 소유권까지 확보된 것은 아니라는 뜻입니다.
후속 개발 견적이 신규 개발만큼 나온다
서비스가 살아남아서 기능을 추가하려는 시점에, 정작 원개발사와 연락이 닿지 않는 경우가 많습니다. 국내 창업기업의 5년 생존율은 34.7%입니다. 지원사업의 개발을 수행하는 소규모 개발사와 공급기업도 그 통계 안에 있습니다. 원개발사가 사라진 코드를 새 외주 개발사가 이어받으려면 구조 분석부터 다시 해야 하고, 문서가 없으면 그 비용은 뜁니다. "기능 하나 추가하는데 왜 이 견적이 나오느냐"는 질문의 답은 대부분 하나입니다. 그 코드를 아는 사람이 세상에 없기 때문입니다. 이어받을 수 있는 코드인지 가늠하는 방법은 「코드를 못 읽어도 품질을 판단하는 법」에 정리해 뒀습니다.
계약서를 잘 쓰는 기업은 소스코드 소유권과 종료 이후를 계약에 넣습니다
세 가지 이슈의 공통점이 있습니다. 이 모든 사안을 협약 단계에서 예방할 수 있다는 것입니다. 개발 업체와 발주 계약을 맺을 때 아래 네 가지가 문서에 있는지 확인하면 됩니다.
첫째, 저작권 양도 조항. 소스코드 제출과 별도로 프로그램 저작권이 발주자에게 양도된다는 사실과 그 시점, 방법을 명시합니다.
둘째, 인수인계 산출물 목록. 소스코드, 관리자 계정, 서버와 도메인 접근 권한, 기술 문서까지 받을 항목을 계약서에 적습니다. 실무에서는 문서만 넘겨받는 것으로 부족해서, 개발자가 직접 코드를 설명하는 대면 인수인계를 2~3일 일정으로 계약에 넣는 것을 권합니다.
셋째, 협약 종료 후의 유지보수 조건. 지원금 밖의 일이라 자부담 예산이 들지만, 종료 시점에 급하게 협상하는 것보다 발주 때 함께 정하는 쪽이 조건이 좋습니다.
넷째, 지원 범위 밖의 로드맵. 지원금으로 만들 범위와 이후 확장할 범위를 처음부터 나눠 두면, 지원금 규모에 서비스 전체를 욱여넣는 무리한 설계를 피할 수 있습니다.
같은 지원사업에 선정된 두 회사가 있었습니다. 한 곳은 발주 계약서에 저작권 양도와 인수인계 목록, 종료 후 1년의 유지보수 조건을 넣었습니다. 다른 곳은 표준 절차대로 개발 계약만 맺었습니다. 협약 기간에는 두 회사의 결과물이 비슷했습니다. 갈린 것은 이듬해입니다. 기능 확장이 필요해졌을 때 첫 회사는 기존 개발사와 유지보수 계약 연장으로 바로 진행했고, 두 번째 회사는 연락이 어려워진 개발사 대신 새 업체를 찾아 코드 분석부터 다시 시작했습니다.
외주 개발사를 검증하는 방법은 「외주 개발사 선정 프로세스」와 「반드시 물어봐야 할 10가지 체크리스트」에 정리돼 있습니다. 지원사업이라고 해서 이 검증을 건너뛸 이유는 없습니다.
지원사업이 이미 끝났다면 지금 확인할 것
정부지원사업 외주 개발 관련 협약이나 계약이 이미 종료된 상태라면 순서는 다음 세 가지 과정이 수반되어야 합니다. 회수와 진단, 그리고 의사 결정. 크게 보면 이렇게 나눌 수 있습니다.
- 먼저 회수. 소스코드 최신본과 관리자 계정, 서버·도메인 접근 권한이 지금 우리 손에 있는지 확인하고, 없다면 원개발사와 연락이 되는 지금 확보해 둡니다.
- 저작권 양도가 계약에 없었다면 추가 합의로 정리할 수 있는지도 이때 물어봅니다.
- 다음은 진단. 받아 둔 코드가 다른 개발자가 이어받을 수 있는 상태인지 문서화 수준과 구조를 점검합니다.
- 마지막으로 결정. 진단 결과를 놓고 원개발사와 유지보수 계약을 맺을지, 다른 개발사로 이관할지, 당장은 최소 관리만 할지 정합니다.
서비스가 멈춘 뒤에 이 과정을 시작하면 세 단계 모두 비용이 올라갑니다. 특히 회수는 원개발사와 연락이 닿는 동안에만 쉽습니다. 이 확인은 장애가 나기 전에, 지금 해 두는 것이 좋습니다.
정부지원사업 지원금의 가치는 종료 후에 판가름납니다
다시 한번 분명히 언급하지만, 이 지원사업은 좋은 취지의 제도입니다. 창업지원을 받은 기업의 5년 생존율은 일반 창업기업의 두 배 수준이라는 분석이 있고, 초기 자금 부담을 낮춰 시도 자체를 가능하게 만듭니다. 2026년 정부 지원의 방향도 신규 창업을 늘리는 쪽에서 이미 만들어진 기업을 키우는 쪽으로 옮겨 가고 있습니다. 지원금으로 만든 서비스를 살리고 확장하는 일은 앞으로 더 중요해진다는 뜻입니다.
그래서 결론은 하나로 도달합니다. 창업지원금의 가치는 협약이 끝난 뒤에 판가름납니다. 협약 단계에서 저작권과 인수인계와 유지보수를 계약에 넣는 짧은 의사결정이, 1년 뒤 서비스가 종료되는 기로에 놓일지, 혹은 계속 성장하는 흐름을 가릅니다.
스파르타빌더스는 지원사업 개발을 진행할 때 소스코드와 저작권, 인수인계 패키지를 계약 표준으로 제공하고, 협약 종료 후의 유지보수와 확장 로드맵까지 발주 단계에서 함께 설계합니다. 정부지원사업으로 앱 개발을 앞두고 있거나 이미 만든 서비스의 이후가 고민이라면, 위의 체크리스트부터 확인해 보시기 바랍니다.
자주 묻는 질문
Q1. 지원사업 앱 개발 업체는 어떻게 선택해야 합니까?
일반 외주 개발사와 같은 기준으로 검증하면 됩니다. 지원사업이라 업체 선택 폭이 제한되는 경우(공급기업 풀 등)에도, 유사 프로젝트 실적과 인수인계 방식, 종료 후 유지보수 가능 여부는 물어볼 수 있습니다. 협약 일정에 쫓겨 검증을 생략하는 것이 가장 흔한 실수입니다.
Q2. 소스코드를 받았으면 소유권도 발주 기업에 귀속되는 것이 아닙니까?
별개입니다. 계약서에 저작권 양도 특약이 없으면 프로그램 저작권은 개발사에 귀속되는 것이 판례상 원칙입니다. 소스코드 파일 제출은 결과물 납품이지 권리 양도가 아니므로, 계약서에 저작권 양도 조항이 있는지 확인해야 합니다. 구체적인 상황은 법률 전문가의 검토를 받는 것이 안전합니다.
Q3. 협약 종료 후 유지보수 비용은 얼마나 잡아야 합니까?
시스템 규모와 사용자 수에 따라 다르지만, 지원금과 별도의 자부담 예산이라는 점이 중요합니다. 소프트웨어 생애비용의 60~80%가 출시 이후에 발생하므로, 지원사업을 신청하는 시점부터 종료 후 최소 1년의 운영 예산을 사업 계획에 넣어 두는 것이 현실적입니다.
Q4. 원개발사와 연락이 안 되면 다른 개발사가 이어받을 수 있습니까?
소스코드와 계정, 문서가 확보돼 있다면 가능합니다. 다만 문서가 없거나 코드 구조가 정리돼 있지 않으면 분석 비용이 커지고, 상태가 나쁘면 재구축이 더 경제적일 수도 있습니다. 이관 가능 여부를 판단하는 첫 단계는 지금 가진 산출물(코드·계정·문서)을 확인하는 것입니다.
Q5. 지원금 규모에 맞춰 기능을 줄여야 합니까?
줄이는 것이 맞습니다. 지원금으로 서비스 전체를 만들려고 하면 모든 기능이 얕아집니다. 핵심 기능을 지원금 범위에서 완성도 있게 만들고 나머지는 이후 로드맵으로 나누는 쪽이, 협약 기간의 결과물 품질과 종료 후의 확장성 모두에 유리합니다.
Share article