기본 콘텐츠로 건너뛰기

[스타트업] 정부과제, 스타트업은 어떻게 활용해야 하나?


[스타트업] 정부과제, 스타트업은 어떻게 활용해야 하나?


아래 제시된 표는 미래창조과학부의 <2016년 4대 전략과 16대 과제> 입니다. 그리고 4대 전략의 첫 번째에는 '스타트업 7대 강국 진입'이 당당히 명시되어 있습니다. 아마도 올해에는 그 어느 때보다도 더 많은 스타트업 지원 정부 과제가 계획되어 있을 것으로 예상되는 상황입니다. 그러나 정부 과제에 대한 비판적 의견도 적지 않습니다. 문제와 고객, 그리고 제품 등에 집중해야 할 스타트업에게 정부 과제는 '공짜 점심' 같은 달콤한 유혹일지도 모릅니다. 그렇다면, 스타트업은 정부 과제를 어떻게 활용해야 할까요?
정답은 없을 테지만, 적어도 이렇게 하면 안된다는 필자의 경험담을 바탕으로 해당 포스트를 통해 작은 팁을 전해보고자 합니다.

필자는 대학원 시절부터 졸업 후, 처음 6년간 일했던 벤처 회사에서, 그리고 사운들리에 조인해서까지 어림잡아 30~40개 이상의 국가 과제에 참여해 왔습니다. 그러나 실제 제품 개발과 직접적으로 연결되었던 정부 과제는 이전에 다녔던 회사의 초기에 2번 정도, 그리고 사운들리에 입사하고 현재 수행하고 있는 정부 과제 1건, 다 합쳐서 3번 정도가 다 인 것 같습니다.
대학원 시절, 과제 수행은 연구에 집중하고 제품에는 별 신경을 안 쓸 수 있다고 면죄부를 받을 수 있을 지 모릅니다. 하지만, 회사에서 수행했던 대부분의 과제들이 제품과 동떨어져 있었다는 것은 지금 돌이켜보면 정말로 중대한 실수였다는 생각이 듭니다. 그럼에도 불구하고, 그 수 많은 정부 과제를 수행했던 데에는 다음과 같은 단계적 자기 합리화가 있었습니다.


<1단계>
"우리 팀은 열심히 제품을 개발하고 있다. 현재 제품 개발에는 많은 비용이 투입되고 있다. 대부분의 멤버는 문제와 제품에 집중하고, 한 두명만 정부 과제에 투입되면 나머지 멤버들의 인건비의 상당 부분과 제품 개발을 위해 필요한 재료비, 장비비, 운영비 등을 지원할 수 있다. 따라서 이것은 매우 효율적인 일이다."

결과적으로 이것은 전혀 효율적이지 않은 접근이었습니다. 별도의 과제를 수행하는 팀원들은 자신이 팀을 먹여살린다는 자부심보다는 제품 개발에서 소외되는데 따른 소외감을 느끼게 됨을 목격하게 되었고, 팀의 역량은 분산되었던 것 같습니다. 한 두명이 투입되어 가짜 개발을 하고, 좀비를 먹어살리는 정부 과제 수행은 결국, 대국민 사기일 뿐이라는 생각이 듭니다.

<2단계>

"우리도 도움을 받았으니 우리도 그 빚을 갚아야 한다. 우리 제품과는 직접 관계없지만 이번에 이 과제를 함께 수행해서 그 동안 많은 도움을 받았던 XXX 교수님께 또는 OOO 사장님께 보답할 차례이다." 

많은 경우, 정부 과제는 산학 협력 또는 콘소시엄의 형태로 진행되며, 대학 교수 혹은 다른 기업들과 서로 상호 도움을 주고 받게 됩니다. 이것이 참 무서운 것이 은혜와 보답은 돌고 돌아 과제가 과제를 물고 오고, 끈끈한 인맥이 만들어지게 되는데, 이러한 선순환(?)은 스타트업에게는 결과적으로 독이 될 수 있습니다.

<3단계>

"우리는 우리 제품을 성공시킬 때까지 생존해야 한다. 생존하기 위해 무엇이라도 해야 한다. 당장 다음 달이면 직원들 월급 줄 돈이 없다. 이것저것 따질 때가 아니다."

우리는 치열한 시장 경쟁 속에서 생존을 꿈꾸며, 궁극적으로 성장하기 위해 어쩔 수 없이 정부 과제를 시작하였지만, 점점 더 우리의 문제, 고객, 제품이 아닌 과제에 우리의 자원과 집중이 분산되어 감을 목격하게 되었습니다.

<4단계>

"우리 제품은 망했다. 그런데 우리가 그 때 그 과제에서 개발했던 그것이 정말 문제인 것 같고, 제품으로서 가능성이 보인다. 다시 과제를 기획해서 정말 제품으로 만들어 보자!"

세번째 단계에서 시간이 흐르자 팀 내에서 우리 제품은 실패했다는 공감대가 형성되었습니다. 사실 이 단계에서는 이미 과제로 생존하는데 익숙해져서 좀비로 라도 영생을 누리고 싶은 것인지 아니면, 그 동안 정부 과제에 투입한 시간과 자원에 대한 본전 생각에서인지 과제에서 개발한 기술이나 결과물과 사랑에 빠지게 될 수 있습니다.

불치병에 걸린 너무나도 사랑하는 연인을 살리기 위해, 나는 어쩔 수 없이 매춘을 하게 되었습니다. 그러나, 그렇게까지 해서 살리려 했던 그 연인은 세상을 떠나 버렸습니다. 괜찮습니다. 어쩌면 내가 몸을 팔기 위해 만난 지금 이 사람이, 진정한 사랑인 것 같기도 합니다.
자기 합리화가 얼마나 어리석은 일인지 극적인 비유를 궁리하다가 위와 같은 비유를 생각해 보았습니다.

각설하고, 마지막으로 필자가 생각하는 스타트업이 정부 과제를 활용하는데 지켜야 할 원칙은 다음과 같습니다.

  • R&D 관련 과제의 경우, 당신의 팀이 풀고자 하는 문제를 해결하는데 꼭 필요한 기술 개발에 부합된 과제 만을 수행하라.
    • RFP가 이미 고정된 과제인 경우, 핏이 비슷해 보인다고 해서 억지로 끼워 맞춰 사업 제안하려 하지 마라. (극히 예외적인 경우를 제외하고, 다른 사람이 만든 RFP 가 당신의 제품과 딱 맞아떨어질 확률은 거의 없다)
    • 제안 내용을 직접 기획해야 하는 경우, 최대한 과제의 개발 과정과 결과가 당신의 제품과 직접 연결될 수 있도록 기획 하라. (정부 과제로 인한 오버 헤드를 최소화할 수 있고, 과제를 위한 추가 업무나 개발은 최대한 피해야 한다)
    • 과제의 정량적 목표는 정말 당신의 제품이 가져야 할 핵심적 지표로 설정하라. (이것을 간과하면, 나중에 과제 실패 판정을 피하려고 해당 목표를 달성하기 위해 팀의 역량을 엄청나게 쏟아부어야 한다)
    • 다년차 사업이라면, 매 사업 연차가 끝나면 문제, 고객, 시장, 제품의 변화에 따라 과제의 개발 내용을 수정을 요청하라. (근거가 명확하면 어느 정도 선에서는 연구 개발 내용의 수정이 가능하다. 하지만, 대부분의 경우 정량적 목표는 수정이 불가하므로 정량적 목표는 제안서 작성 시, 변화하기 힘든 기술적이고 정량적인 핵심 지표로 잡는 것이 좋다)
  • R&D 이외의 각종 컨설팅, 지식재산권, 디자인, 마케팅, 제품화 지원 등 기타 지원 과제는 정말 사업적으로 시급한 도움이 필요한 사업만을 수행하라.
    • 해당 정부 사업이 정말 당신의 팀에게 현재 필요한 요소인지 냉정하게 판단해야 한다.
    • 사업을 위해 다 필요해 보이지만, 세상에 공짜는 없다. 오버 헤드 없는 정부 과제는 없다.
  • 정부 과제 브로커는 무조건 무조건 피해라.
    • 과제 브로커는 컨설팅 업체를 빙자한 전문 브로커에서부터 대학교수, 과제 전문용역 개발 회사 등 다양한 형태가 존재한다.
    • 과제 브로커는 달콤한 유혹으로 스타트 업을 유혹하는데, 결과적으로 100% 모두 다 필자의 기준으로는 사기꾼들이었다.
  • 정부 과제 완전 초보자를 위한 과제 지원 깨알 팁:
    • 과제 공고문은 대부분 친절하지 않다. 공고문을 검토하고, 질문 거리를 잘 정리해서 담당자에게 전화를 거는 것이 가장 좋다.
    • 이메일에 상세히 빠르게 답변해주는 담당자는 별로 없다. 그렇다고 여러 번 전화를 하면 담당자를 짜증나게 할 것이다.
    • 국가 연구비 표준매뉴얼 (수시로 업데이트 되니 최신판을 구글링) 정도는 한 번 정독하고 질문하자. 일부 담당자들은 업데이트되는 규정에 대해 숙지 못하고 있다.
    • 정부 과제 제안서 작성은 일반적인 사업 제안서 작성과 완전히 다를 수 있다.
    • 많은 과제들이 심사채점 기준을 공개한다. 그에 맞게 제안서를 준비하는 것이 좋다. 배점이 높은 부분에 집중할 필요가 있다.
    • 채점표 다음으로는 심사 위원에 맞는 맞춤형 작성이 요구된다. 심사 위원이 학계 중심인지 현업 중심인지 알아보고, 사업이나 시장을 중심으로 기술할 지, 연구나 기술에 집중하여 기술할 지 고민하라.
    • 국가 과제는 사적 이익을 도모하라고 세금을 지원하는 것이 아니다. 당신의 과제가 국가 경제와 국민들에게 어떻게 기여할 수 있는지를 최대한 강조하라.

지금 이 순간에도 정부 과제 공고문을 읽으며 해당 과제에 지원할 지 말지 고민하고 있을 스타트업 인들에게, 필자의 경험담이 조금이나마 도움이 되었길 바랍니다. 감사합니다.

사운들리에서 현재 웹 / 안드로이드 / 서버 개발자를 채용하고 있습니다. 글로벌 기술력 가진 사운들리에 팀원으로 합류하세요 ~:) --> 채용공고

댓글

이 블로그의 인기 게시물

[Insight] 안드로이드 백그라운드 서비스 개발시 고려해야 할 사항

[Insight] 안드로이드 백그라운드 서비스 개발시 고려해야 할 사항

지난 시간엔 사운들리 백엔드에 대해 설명을 드렸었죠. 이번 시간엔 사운들리 서비스중 클라이언트에 해당하는 안드로이드 SDK, 그 중에서도 백그라운드 서비스에 초점을 맞추어 설명을 해 볼까 합니다. 안드로이드의 특징 중 하나로 Service를 들 수 있습니다. 이 서비스란 녀석은 백그라운드에서 실행 될 수 있다는 점이 가장 큰 특징인데요. 물론 iOS 에서도 일부 지원은 합니다만 매우 제한적인 경우(음악 재생 등)에만 사용 가능합니다.
제가 생각하는 백그라운드 서비스 개발 시 유의 사항은 아래와 같습니다. 동작 기간 - 상시 동작 해야 하는가, 특정 조건에서 특정 작업을 할때만 동작 해야 하는가글로벌 프로세스 사용 유무 - 서로 다른 어플리케이션에서 접근이 가능 해야 하는가동작 조건 - 특정 시간 혹은 기간마다 동작 해야 하는가, 특정 이벤트 발생시 동작 해야 하는가그 외에도 많은 부분들이 있지만 일단 저 정도만 고려해도 개인적인 생각으로는 충분히 개발 가능하다고 생각 합니다. 그러면 각각에 대해서 좀 더 자세하게 알아 볼까요?
1. 동작 기간동작 기간에 대해서 이야기 하기 전에 먼저 유저 레벨에서 가장 많이 사용하는 Service 와 IntentService 의 차이점에 대하여 짚고 넘어가보겠습니다. Service 를 상속`Context#startService//Context#stopService` 혹은 `Context#bindService(w/BIND_AUTO_CREATE)//Context#unbindService` 를 통해 수명 조절 (Service 내에서 Service#stopSelf 를 호출하는 방법도 있습니다.)Service 시작된 이후에 커뮤니케이션 가능수명 종료 API(stopService or unbindService) 를 호출 하기 전에는 프로세스가 사라지지 않음 (물론 LMK에 의해서 종료 된다던지 등등이 있지만 여기서는 논외로 하겠습니다.)IntentService 를 상속start…

[스타트업] [Insight] 사운들리 코드 품질 관리 이야기

[스타트업] [Insight] 사운들리 코드 품질 관리 이야기
 안녕하세요 "사운들리"입니다 :)

오늘은 사운들리의 코드 품질 관리에 대해 이야기 해보려 합니다. 몇몇 개발자에게는 지루하고 악몽같은 이야기일 수 있겠네요.
제 경우에는 예전에는 이런 품질이라는 단어를 멀리했지만 결국 제가 작성한 코드에 발목을 많이 잡히다 보니, 자연스레 관심을 갖게 되었습니다.

일단, 어떤 소프트웨어가 좋은 품질의 소프트웨어일까요?
좋은 품질이란?  책에 나올법한 내용을 보면, 아래와 같은 항목을 토대로 소프트웨어 품질을 판단한다고 합니다.
ISO/IEC 9126 : Software engineering - Product quality Functionality: 명시된 요구사항을 잘 충족했는지Reliability: 명시된 조건과 시간 아래에서 일정 성능을 유지 하는지Usability: 사용하기 위해 어느정도의 노력과 자원이 필요한지Efficiency: 소모 자원과 성능간의 효율Maintainability: 수정하기 위해 어느정도의 노력이 필요한지Portability: 다른 환경에서도 사용 할수 있는지출처: https://en.wikipedia.org/wiki/ISO/IEC_9126  뭔가 복잡해 보이지만, 결국 개발자라면 위의 항목은 누구나 추구하게 되는 가치라고 생각 합니다.

그런데 말입니다.이런 좋은 내용을 마음 속으로만 간직한 채 코드를 작성하면 정말 좋은 소프트웨어를 만들 수 있을까요? 저는 객관적인 방법으로 코드를 평가한다면 좋은 피드백이 될 것이라고 생각합니다. (물론 이 성적표를 남에게 보여주는 것과는 다른 문제에요 ㅎㅎ)
어떻게 품질을 체크하는가  소프트웨어의 품질을 체크하는 데에 다양한 방법과 툴이 제시되고 있는데요, 저는 크게 두 가지로 분류 해보겠습니다.
유저 입장의 품질: 유저의 요구사항에 맞는 소프트웨어인지 체크개발자 입장의 품질: 내가 지금 이 코드를 의도한 대로 잘 작성하고 있는지 체크 유저 입장의 품질은 언급하지 않아도 중요함을 누구나 알고 있습니다. 이…

[스타트업] [Insight] 사운들리 방송 송출테스트 이야기

[스타트업] [Insight] 사운들리 방송 송출테스트 이야기
안녕하세요 "사운들리"입니다 :)


 오늘은 사운들리 사운드 비콘을 방송 콘텐츠에 실어 보내어 시청자의 모바일로 유용한 정보를 전달하기 위해 가장 중요하고, 힘들지만 마치고 나면 모든 팀원들이 가장 뿌듯함을 느끼는 방송 송출테스트 이야기를 하려 합니다.


송출 테스트, 사운들리가 그 어려운 걸 또 해냅니다.
<디지털 방송의 송출 경로>
 위 그림은 우리나라 디지털 방송의 송출 경로의 한 예입니다. 실제 방송국이 지상파인지, 종편인지, 기타 케이블 채널인지 등에 따라 세부적인 변화가 더 있을 수 있지만, 위 그림만 보셔도 충분히 복잡해 보이실 것입니다.
 우리나라는 DMB 등 일부 영역을 제외하고 디지털 방송 영역에서 대부분 미국식 표준 ATSC 관련 표준을 따르고 있지만, 유럽 국가와 뉴질랜드 등은 유럽식 표준인 DVB 관련 표준을 따르고 있습니다. 사운들리가 실제 송출테스트를 통해 증명하기 전까지 마주친 수많은 방송 실무자들, 방송 장비 업계 관계자, 학계 연구자들은 다양한 방송 장비에 의해서 사운들리 사운드 비콘이 유실되거나 왜곡되어 서비스가 불가능할 것 이라며 포기하라고 하였습니다.

 하지만 이렇게 복잡하고 다양한 환경에서 사운들리는 대한민국과 터키에서 모두 서비스를 성공(!)함으로써 미국식 디지털 방송의 대표적인 예인 대한민국과 전형적인 유럽식 디지털 방송의 예인 터키 모두에서 서비스 제공이 가능하다는 것을 증명해 냈습니다 :)


방송 송출, 그 험난한 검증의 시간  그렇다면 이렇게 복잡한 방송망을 거치고 나서도 사운들리 사운드 비콘이 시청자의 모바일로 안전하고 완전하게 전달될 수 있다는 것을 테스트하기 위해 어떤 과정을 거치는지 살펴보겠습니다.

 사운들리가 방송 쪽으로 사업 방향을 잡고 나서 가장 힘들고 오랜 시간이 걸린 부분 중 하나가 방송국들에게 기술의 안전성과 안정성, 정확성을 설득하는 것이었습니다.
기술의 안전성: 시청자 또는 반려 동물에게 선진국들의 가장 보수적인 규제 보다…