어떻게 확장가능한 사업모델을 갖출 것인가?

회사가 많이 바쁘다. 내가 하는 일이라고는 이미 계약한 사업 관리하고 새로 들어오는 일 자르는 게 전부다. 일이 많아 기뻐야 할 텐데 별로 기쁘지 않고 우울하다. 회사가 확장가능한 사업모델을 가지고 있지 않다는 것을 증명하는 셈이니까.

 

직원을 더 채용하면 되지 않느냐고 묻기도 하는데 그게 덫이다. 지금 같은 사업구조에서는 사람을 더 뽑은만큼 더 많은 일을 해야 하고 더 많은 일을 하기 위해 또 사람을 뽑아야 한다. 멈추면 쓰러지는 외발자전거 타기와 같다. 매출이 늘어나고 직원이 많아지면 외형적 성장을 달성하는 것이기는 하나 그 속을 보면 결국 사람 쥐어짜기와 다를 바 없어 불편하다.

 

사람이 아니라 시스템이 돈을 버는 구조를 갖추기 위해 이래저래 머리를 굴려보고 시도도 하는데 성과가 그리 좋지 않다.

 

우선 우리 회사 주력 제품을 패키지로 만들어 파는 것이다. 근데 잘 안 된다. 패키지라고 이름 붙이기 부끄러운 수준이다. 패키지 만들어 보자고 의기투합하다가도 돈 벌려고 개발자들이 고객 사이트에 맨날 불려간다. 공간정보 시장은 대표적인 고관여 상품(High involving product) 시장이다. 우리 제품 사가도 현장에 적용하려면 다시 소프트웨어 엔진단부터 고쳐야 하는 경우가 많아 결국 엔진 개발자들이 현장에 투입되는 경우가 많다. 시장에서 고객 요구 사항 들어주며 개발하고(SI) 이를 다시 제품에 반영하자고 하는데 맨날 SI만 하다가 지치고 만다. 그래도 개발자들이 고생하고 회사 이름이 좀 알려지면서 올해는 패키지 판매량이 증가한 게 다행이기는 하다.

 

둘째는 소위 Central Cook 개념을 도입해 본 것이다. 이 수준의 회사에서 완벽한 패키지를 만드는 건 불가능해 보이니 한 80% 수준의 제품을 연구소에서 만들어 현장 조직(SI)에 주고 나머지는 현장에서 수정보완하며 맞춤형으로 개발하자는 개념이다. 많은 요식업 체인에서 가조리된 식재료를 체인점에 내리면 현장 체인점은 데우고 볶아서 예쁘게 내놓는 방식에서 아이디어를 차용했다. 이것도 잘 안 된다. 80% 수준의 제품을 이해하고 그 위에서 개발할 수 있는 사람은 결국 우리 회사 현장 개발자 조직 뿐이다. 외부 개발자들이 Mapbox나 OpenLayers 같은 걸 이용해서는 금방 개발하지만 우리 회사 제품을 이용해서는 이렇게 빠르게 개발하지 못한다. 개발용이성과 확장성 등이 많이 부족하다는 이야기. 엔진 개발자와 현장 개발자가 하는 일이 달라 소통이 안 되는 경우도 많다.

 

마지막으로 시도하고 있는 건 클라우드 서비스다. 바빠서 많은 신경을 못 쓰고 있지만 내심 많은 기대를 하고 있는 시도다. 최근 나는 직원들에게 우리 회사의 비전으로 '공간정보계의 Redhat, 오픈소스계의 ESRI'를 떠벌리고 있다. 공간정보 업계에서 오픈소스로 Redhat 같은 성공을 이루고, 오픈소스를 개발하고 활용해 ESRI 같은 라인업을 가져보자는 이야기다. 둘을 살펴보다 클라우드 서비스라는 공통점을 발견했고 회사의 내적자산과 오픈소스를 활용해 도전해 볼 수 있는 가능성을 보았다. 그래서 한 번 해 보는 거다. 아마 빠르면 올해 말 늦어도 내년 초에는 뭔가 하나 나오지 않을까 기대 중이다.

 

요즘 AI가 핫한데 난 AI가 돈 벌어주고 인간은 노는 사회인 디지털 아테네를 상상한다. 사람이 아니라 기계가 돈을 벌어야 한다는 이야기. 여하간 항상 고생하는 직원들에게 미안하고 고맙고 그렇다. 아, 오늘 밤 왜 이리 멜랑콜리하지? 흠...

 

2020년 8월 2일
신상희