정부과제 과업 범위에서 욕심을 내면 안 되는 이유

정부 지원사업에 선정되면 창업자들은 자연스럽게 이런 생각을 합니다. "이 기회에 최대한 많이 만들어두자", "앱도 같이 완성하자", "시제품도 넉넉하게 잡아두자." 사업비가 생겼고, 협약 기간도 있으니 가능한 많은 것을 이루고 싶은 마음은 당연합니다.

그런데 실제로 과제를 진행해보면, 과업 범위를 넓게 잡을수록 오히려 핵심을 완성하지 못하는 경우가 반복됩니다. 이 글은 정부과제 과업 범위를 잡을 때 창업자들이 자주 빠지는 오해들을 짚어드립니다.

과업 범위는 넓게 잡는 것이 아니라, 완성할 수 있게 잡는 것이 맞습니다.

1. 시제품 수량: 많을수록 유리하다는 착각

과제 산출물로 시제품 수량을 많이 잡으면 평가에서 유리하다고 생각하는 창업자들이 있습니다. 10개, 20개. 숫자가 크면 성과가 커 보이는 것은 사실입니다. 그런데 시제품의 비용 구조는 양산과 완전히 다릅니다.

양산은 수량이 늘어날수록 단가가 낮아지는 구조입니다. 반면 시제품은 1개가 추가될 때마다 부품비, 제작비, 조립비, 수정 대응 비용이 거의 그대로 반복해서 붙습니다. 설계가 확정되지 않은 상태에서 수량을 늘리면, 수정이 발생했을 때 그 비용이 전체 수량에 곱해집니다. 처음 몇 개로 핵심 기능과 구조를 검증한 뒤, 필요에 따라 수량을 추가하는 방식이 현실적입니다.

시제품 수량을 정할 때 먼저 물어야 할 것

• 이 수량이 무엇을 위한 것인가: 평가 시연용 1개와 사용자 테스트용 몇 개가 실제 필요한 전부인 경우가 많습니다.
• 설계가 확정된 상태인가: 설계 변경 가능성이 남아 있다면 수량을 늘리는 것이 오히려 리스크입니다.
• 협약 기간 안에 완성 가능한가: 수량이 많을수록 제작 기간도 길어집니다. 일정을 역산해서 수량을 정해야 합니다.

2. 앱 개발: 협약 기간 안에 전부 완성하려는 욕심

하드웨어 시제품과 앱을 동시에 과업 범위에 넣는 경우가 많습니다. 제품과 앱이 연동되는 구조라면 함께 완성해야 한다는 생각은 맞습니다. 다만 문제는 범위입니다. iOS와 Android를 동시에, 모든 기능을 협약 기간 안에 완성하겠다는 계획은 대부분 현실적이지 않습니다.

앱 개발에는 플랫폼별 등록 절차, 심사 기간, 기기 호환성 테스트 등 개발 시간 외에 추가로 필요한 시간이 있습니다. 하드웨어 시제품이 완성된 이후에야 본격적인 연동 테스트가 가능하기 때문에, 하드웨어 일정이 조금이라도 밀리면 앱 개발 일정 전체가 압축됩니다. 이 구조를 인지하지 못하고 과업을 잡으면 협약 기간 말에 둘 다 미완성인 상태로 마무리되는 결과가 나옵니다.

하드웨어 일정이 기준이 되어야 앱 개발 일정도 현실적으로 잡힙니다.

3. 전원·배터리: 단순 기기처럼 생각하는 오해

배터리로 구동되는 제품을 시제품으로 만들 때, 창업자들이 자주 과소평가하는 항목이 전원 설계입니다. "배터리 용량을 크게 잡으면 되지 않나요?"라는 질문이 대표적입니다. 배터리 용량은 사용 시간에 영향을 주는 하나의 변수일 뿐이고, 실제 전원 설계는 훨씬 복잡한 구조입니다.

특히 구동부(모터, 펌프, 액추에이터 등)가 포함된 제품은 구동 순간의 순간 소모 전류가 평균 소비 전력과 크게 다릅니다. 여기에 센서 상시 대기, 무선 통신 유지까지 더해지면 전력 소모 구조는 단순 계산으로 예측되지 않습니다. 배터리 용량 외에도 발열, 충전 안전 회로, 내부 공간까지 함께 검토되어야 하는 이유입니다.

• 순간 소모 전류 vs 평균 소비 전력: 구동부가 작동하는 순간의 전류 피크는 배터리와 회로에 큰 부담을 줍니다. 이를 고려하지 않으면 배터리 수명이 예상보다 훨씬 짧아집니다.
• 발열 문제: 소형 기기일수록 내부 공간이 좁아 열이 빠져나가기 어렵습니다. 전원 설계 단계에서 발열 조건을 함께 검토해야 합니다.
• 초기 시제품의 현실적 목표: 첫 시제품에서 장시간 배터리 성능까지 전제하면 설계 복잡도가 크게 올라갑니다. 핵심 기능 검증이 가능한 수준의 배터리 운용 조건으로 시작하고, 이후 단계에서 최적화하는 접근이 현실적입니다.

4. 공통 원인: 과업 범위도 AI가 잡아줬을 가능성

위에서 언급한 오해들이 동시에 나타나는 의뢰서에는 공통점이 있습니다. 문서 완성도는 높고 항목도 빠짐없이 채워져 있지만, 각 항목의 현실적 조건은 검토되지 않은 채 나열되어 있다는 것입니다. 시제품 수량도, 앱 개발 범위도, 배터리 사양도 모두 "이렇게 하면 좋겠다"는 수준으로 적혀 있습니다.

앞서 다룬 것처럼, AI는 과업 범위를 이론적으로 정리하는 데는 유용합니다. 그러나 "이 협약 기간과 사업비 안에서 실제로 완성 가능한 범위가 어디까지인가"는 실전 경험에서 나오는 판단입니다. AI가 넓게 제시한 범위를 창업자 본인이 좁혀야 하고, 그 판단이 없으면 과업 범위는 자연스럽게 욕심이 담긴 수준으로 잡히게 됩니다.

과업 범위는 가능한 것을 기준으로 잡아야 합니다. 원하는 것을 기준으로 잡으면 안 됩니다.

제언: 과제의 목적은 완성입니다, 계획이 아닙니다