레이블이 소프트웨어이야기인 게시물을 표시합니다. 모든 게시물 표시
레이블이 소프트웨어이야기인 게시물을 표시합니다. 모든 게시물 표시

2014년 9월 30일 화요일

구멍가게 될텐가? 글로벌 SW기업 될텐가?

나는 소프트웨어 스타트업 및 중소기업 관계자를 자주 만난다. 주로 소프트웨어 개발이나 마케팅 전략에 대해서 얘기를 한다. 최근에도 몇몇 기업의 대표를 만났다. 

대부분의 기업들은 국내 시장에만 머무르지 않고 해외로 진출해서 글로벌 기업으로 성장하기를 원하고 있다. 한 두명이 시작해서 세계적인 회사가 된 뉴스를 보면 우리도 그렇게 될 수 있다는 꿈을 가지게 된다. 그러기 위해서 국내에서 일단 인지도를 쌓고 고객을 확보하여 캐시카우를 만든 후에 이를 기반으로 해외 진출한다는 전략을 가지고 있는 경우가 많다. 

하지만 이런 전략은 계획대로 되지 않는 경우가 많다. 그냥 국내 시장에서 허덕대다가 그저그런 기업으로 남거나 문을 닫는다. 

물론 처음부터 해외시장은 거들떠도 보지 않고 국내 시장에서만 승부를 보는 전략도 있고 분야에 따라서 나쁜 전략도 아니다. 국내 소프트웨어 시장이 세계 시장의 2~3%에 불과하지만 지역특성이 강한 분야도 있어서 효과적인 전략이 될 수도 있다. 

하지만 국내를 발판으로 해외로 나가보자는 전략이 잘 먹혀 들어가지 않는 이유를 알아보자. 

A사는 기업용 서비스를 개발하는 회사인데 처음부터 글로벌 서비스를 목표로 시작을 한 회사다. 충분한 자본을 가지고 시작하지 않았기 때문에 먼저 돈을 벌어야 했다. 그래서 국내에서 몇몇 기업과 계약을 맺어 서비스를 제공했고, 상당 기간 고객들이 원하는 기능에 매달리느라고 글로벌 서비스에 필요한 준비를 별로 하지 못했다.

글로벌 서비스는 모든 프로세스가 완전히 자동화 되어 사람의 수동 개입이 거의 없어야 하는데 국내 고객에 대응을 하다 보니 상당 부분 사람의 노력이 들어가야 하는 반자동 서비스가 되었다. 지금은 고객이 100배로 늘어도 큰일이며 시스템의 구조를 바꾸려면 추가로 개발을 매우 많이 해야 한다. 이미 개발해 놓은 것이 많으므로 시스템 복잡도는 점점 증가하게 되었고, 이 모든 것이 미래 개발의 큰 부담이 되고 있다. 

B사는 기업용 웹 솔루션을 만드는 스타트업이다. 국내 시장에서는 어느 정도 인지도를 쌓았다. 그리고 정부 지원을 받아서 해외 진출을 하기 위해 글로벌 버전을 새로 개발하고 있다. 

국내에서 영업이 꽤 잘되어서 매출액이 급격히 늘었다. 하지만 국내 기업을 지원하느라고 개발자를 많이 채용해야 했다. 그러다 보니 많은 개발자의 월급을 주려면 상당한 매출을 계속 일으켜야 했다. 그렇게 계속 국내 고객을 발굴하고 기업들의 요구사항에 매달리다보니 처음에 계획했던 글로벌 솔루션에 투자할 시간이 점점 줄어들었다. 국내 고객이 캐시카우라서 포기할 수도 없고, 이를 위해서 많은 개발자는 계속 필요하고 이런 고리에서 빠져 나올 수가 없다. 

C사는 유럽의 작은 나라 소프트웨어 회사다. 지원수는 30명 정도지만 전세계 수많은 고객을 가진 글로벌 기업이다. 이 회사의 솔루션은 매우 단순하다. 비즈니스 전략도 단순하다. 구매도 온라인으로 이루어지고 모든 정보는 인터넷에 공개가 되어 있다. 고객지원도 온라인으로만 이루어진다. 서비스데스크 시스템을 통해서 기술문의나 사용문의를 처리하고 있다. 

고객이 전세계에 흩어져 있어서 지원을 요청한다고 방문을 할 수도 없고, 전화 지원도 언어 장벽 때문에 어렵다. 따라서 제품에 대한 문서화가 잘 되어 있고, 모든 지원은 자동화된 프로세스가 잘 구축되어 있다. 그래서 적은 개발 인원과 지원 인력으로 수많은 고객을 지원하는 것이 가능하다. 

글로벌 기업이 목표인 회사에게 국내 시장은 우선 공략 전략은 자칫 빠지기 쉬운 함정이 될 수 있다. 지역이 국내라서, 국내 고객들이 괴팍해서 그렇다는 것은 아니다. 로컬 비즈니스 전략으로 고객별 커스터마이징과 오프라인 지원에 매달리는 전략이 문제라는 것이다. 일단 이런 전략으로 시작한 기업은 '개미 지옥'에 빠진 기업과 같다. 처음에는 이렇게 돈을 번 후 멋지게 빠져나가서 성장을 하고 싶지만, 일단 발을 들여 놓으면 처음에 생각한 것과 다르게 점점 더 깊게 빠져 들어가는 '개미 지옥'이 된다. 

기술적으로도 로컬 제품을 먼저 만들었다가 글로벌 제품으로 성장하는 것은 매우 어렵다. 서비스도 마찬가지다. 패러다임을 완전히 달리 해야 하는 것이라서 처음부터 글로벌 시장을 타깃으로 한 제품을 만들지 않으면 어렵다. 

글로벌 제품의 특성은 다음과 같아야 한다. 

첫째, 소프트웨어 국제화가 잘 되어 있어야 한다. 

소프트웨어 국제화란 여러 언어와 국가를 지원할 수 있는 구조로 만든다는 것인데 국제화 전문가의 도움 없이 제대로 국제화를 하기란 거의 불가능하다. 10년 이상의 소프트웨어 국제화 경험이 있어야만 제대로 국제화를 할 수 있다. 

소프트웨어는 처음에 개발을 시작할 때부터 국제를 하는 것이 가장 좋다.국제화가 안된 소프트웨어도 처음에 영어를 기반으로 개발한 소프트웨어는 나중에 국제화가 용이하지만 그렇지 않은 경우 국제화가 힘들어진다. 또한 영어로 개발된 제품은 국제화를 하지 않아도 영어를 받아들이는 전세계 모든 회사에 판매를 할 수가 있다. 

소프트웨어 자체는 훌륭하지만 국제화에 발목 잡혀서 실패한 회사가 꽤 된다. 번역이 잘 못되거나 해당 국가의 문화나 표기 방법을 고려하지 않거나 개발 비용이 너무 과도하게 들어가서 실패를 하게 된다. 

둘째, 유지보수와 고객지원이 용이하며 거의 온라인으로 지원할 수 있도록 해야 한다. 물론 소프트웨어 품질이 높아서 장애와 지원요청이 별로 없어야 한다. 소프트웨어 장애 시 몇 번의 클릭으로 장애 리포트를 전송할 수 있도록 하고, 개발사에서는 자동으로 분석할 수 있는 시스템이 잘 구축되어 있어야 한다. 고객과는 온라인으로 소통하며 모든 이력은 데이터베이스에 기록되어서 미래의 고객 지원에 활용된다. 

요즘은 고객끼리 정보를 공유하는 서비스를 제공해서 고객지원에 들이는 노력을 더욱 절약하는 기업들이 있다. 

셋째, 기업 내부적으로는 개발에 필요한 문서가 잘 작성되어 있고, 고객에게는 충분한 정보를 문서로 제공한다. 개발 시에 꼭 필요한 문서를 충분히 잘 작성하므로 고객에게 제공되는 사용자 매뉴얼, 기술 백서 등의 문서가 자연스럽게 잘 만들어진다. 그래서 고객들은 문서를 통해서 충분히 정보를 제공 받으므로 지원 요청이 줄어든다. 물론 고객에게 정보를 제공하기 위해서 처음부터 문서화를 잘하는 것이 아니다. 개발 시에 필요한 문서를 제대로 만드는 것이 가장 빨리 개발하는 방법이기 때문에 문서를 잘 적는 것이다. 

넷째, 개별 고객의 요구사항에 흔들리지 않고 개발사가 제품의 로드맵을 주도한다. 고객의 요구사항에 귀를 기울이지만 전체를 파악하는데 노력을 하고 한 고객이 원하는 것에는 휘둘리지 않는다. 이 때문에 잃게 되는 10%의 고객보다는 나머지 90%의 고객을 유지하는데 집중한다. 따라서 소프트웨어를 급하게 개발하지도 않는다. 

다섯째, 고객이 아무리 많아도 소스코드는 한벌인 경우가 많다. 국내 소프트웨어 회사들이 가장 많이 빠지는 함정이 슈퍼 고객을 지원하기 위해서 소스코드가 갈라지거나 국제화를 위해서 별도로 개발을 하는 것이다. 눈앞의 이득만 쫓다가 수십배의 손해를 보는 경우가 허다하다. 

글로벌 회사를 계획했지만 캐시카우를 만들기 위해서 로컬 비즈니스와 커스트마이징 또는 SI를 해야 밖에 없는 상황이 있을 수도 있다. 하지만 이런 전략은 "개미 지옥"과 같다는 것을 명심하자. 절대로 빠져오지 못할 만큼 깊게 빠지지는 말아야 한다. 정신을 똑바로 차리고 있지만 않으면 영원히 못 빠져 나온다. 

가장 좋은 방법은 마약에 빠지지 말고 처음부터 글로벌 전략을 펼치는 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

2014년 8월 30일 토요일

나는 한달 동안 휴가를 갈 수 있을까?

내가 만약 한달 동안 휴가를 간다면 회사에서는 무슨 일이 벌어질까각자 한번 상상을 해보자.

내가 있던 없던 상관없이 회사는  돌아갈까아니면 내가 관련된 일들이 진행되지 않아서 회사가 마비가 될까내가 없으면 회사가   돌아가도 문제지만 내가 있으나 없으나 회사가 아무  없이 돌아가도 불안하다혹시 내가 없어도 되는 사람이 아닌가 걱정이 되기도 한다.

유지보수가 어렵게 코딩하는 방법” 이란 책도 있다원제는 “How to write unmaintainable code : Ensure a job for life ;-) This essay is a joke!”이다 책은 조크이지만 내가 없으면 유지보수가 몇배몇십배 어려워지는 온갖 다양한 방법을 소개하고 있다사실 본인도 유지보수가 어려워지는 방법들이다.

 년에 한번씩 강제로 한달 동안 휴가를 가야 하는 회사가 있다휴가기간 한달 동안 원격지에서 일을  있다는 것이 아니다진짜 휴가를 가야 한다이런 강제 휴가제도를 만든 이유는 어느 직원이던지  직원이 없어도 회사가  돌아가야 하기 때문이다업무의 특수성 때문에 한달 동안 자리를 비울 없는 직원이 있다면 회사의 조직을 바꾸던지 프로세스를 바꿔서 다른 사람으로 대체가 가능하거나보완이 가능하도록 한다누구든지 한달간 휴가를 떠나도 아무런 문제가 없이 해놔야 한다.

이런 회사에서는 직원들이 언제든지 짤릴  있다는 불안감을 가져야 할까?

가상의 이야기가 있다원자력 발전소에서 일하는 홍길동은 절대로 3 이상 휴가를   없다홍길동은 오랜 노하우로 적절하게 원자로의 온도를 조절하는 특수한 능력을 가지고 있고 홍길동 외에는 그런 기술이 없다고 하자홍길동은 수동으로 온도 제어장치 조절이 가능한데 자동 처리 시스템을 갖추려면 엄청난 비용과 많은 추가 인력이 필요하다고 한다회사 입장에서는  비용을 투자 하는 것보다홍길동만  유지하면 적은 비용으로 발전소 운영이 가능하고 홍길동은 자신이 없으면 발전소가 돌아가지 않는 상황에 자부심을 가지고 있다하지만 홍길동은 격무에 시달려서 회사를 그만두거나 불의의교통사고를 당할 수도 있다 나라의 발전소에서  높은 연봉으로 데려갈 수도 있다.

나는 강연이나 세미나를   자주 묻는다. “지금 당장 퇴사를 해도 회사에  문제가 없는 사람”. 그러면 거의 대부분 손을 드는 사람이 없다실제로 퇴사를 해도 문제가 없는 사람이 없을 수도 있고 다른 사람들 눈치를 보기도 한다.

반대로 그럼 당장 퇴사하면 회사가  돌아가는 사람” 손을 들라고 하면  사람들이 당당하게 손을번쩍 든다 사람은 떠밀려서 손을 든다그러면서 주변에서는 웅성웅성 말들이 많아진다약간의 빈소적인 말도 들려온다대부분의 회사에서 공통적인 현상이다.

우리 주변의 소프트웨어 회사들 중에는 개발자 한두명만 퇴사를 해도  영향을 받는 회사가 많다회사의 경영진은 문서화도 잘되어 있고 공유도  되어 있어서 문제 없다고 하는 경우도 있지만 속을 들여다 보면 유지보수에  쓸모도 없는 문서에 공유는 형식적으로 되어 있어서 실제로는  문제지만쉬쉬” 하는 경우가 많다개발자들도 자신이 없을  회사가   돌아가는 상황을 그렇게 나쁘게만보지 않기 때문에  이슈로 생각하지 않는다.

이러한 현상 때문에 아버지가 돌아가셨는데 상중에도 회사를 나와서 일을 했다는 경우를 들기도 하고신혼여행도 제대로 못가는 경우도 발생한다.

그럼 이런 현상이 회사에는 불리하지만 개발자에게는 유리한 현상일까단기적으로는 그렇게 생각할 있지만 장기적으로는 얘기가 완전히 달라진다.

나는 당장 퇴사하면 회사가  돌아가는 사람 하루 빨리 정리를 해야 하고, “지금 당장 퇴사를 해도 회사에  문제가 없는 사람 회사에  필요한 사람이라고 얘기한다. “당장 퇴사하면 회사가 돌아가는 사람 많다면 회사가 갑자기 망해도 이상하지 않은 상황이다이렇게 망한 회사들은 이런이유 때문에 망한 것이라는 것을 알아채기는 쉽지 않다.

지금 당장 퇴사를 해도 회사에  문제가 없는 사람” 중에는 정말로 하는 일이 없어서 있으나 마나 사람이 있을 수도 있지만 그건 주제에서 벗어난 얘기고 대부분  동안 해왔던 일들이 문서화가  되어 있고공유가 잘되어 있으며 다른 사람이 이어 받아서 처리하는데 문제가 없는 경우다이런 사람은회사의 미래의 프로젝트를 위해서  필요한 사람이다.

반대의 경우는  동안 저질러 놓은 일이 많고 자신이 아니면 유지가  된다 하나 해결하려고 해도  개발자에게 물어봐야 하고다른 사람들은 시스템에 대해서 이해하기도 어렵고  개발자가 한두 시간이면 뚝딱 해결할  있는 것을 유지보수 개발자에게 시키면 며칠이 걸려도 해결이 어렵고해결을 했다고 해도  다른 문제를 만들어 냈을까봐 두렵다회사입장에서는  리스크가 아닐  없없다하지만 회사에서는 이런 개발자를 핵심 개발자라고 착각하고 질질 끌려 다닌다.

물론 개발자가 일부러 이런 경우는 흔치 않다회사의 문화프로세스가 엉망이니 그냥 열심히 하던대로 개발을 하다 보면 이런 현상은 십중팔구 일어난다특히나 개발 능력이 뛰어난 개발자들에게서이런 현상이   일어난다혼자서 많은 양의 코딩을 해내지만 같이 공유하고 리뷰를 해줄 개발자가없고혼자서 제품 하나를 뚝딱 만들어도 유지보수에서 발을 빼기 어렵게 된다일부러 유지보수가 어렵게 코딩하는 사람은 없겠지만 작성해놓은 코드를 보면 유지보수가 어렵게 코딩하는 방법” 이란 책을 공부한 사람처럼 코딩하는 경우도 있다.

이렇게 자신의 과거 업무에 발목이 잡혀있는 개발자들은 앞으로 나아가면서 성장하기 어렵다회사의미래 프로젝트좀더 어렵고 재미있는 일을 못하게 된다새로운 기술이나 지식을 익힐 기회는 점점 줄어들고 매일 하던 반복적인 유지보수에 매달리거나 과거에 해놓은 일의 기억을 헤집는 일을 주로 하게된다자신의 과거의 업무에서 자유로워지는 일은 자신의 가치를 좀더 높이는 일이다.

물론 우리나라 회사에서는 이런 것이 통하지 않는다고 주장하는 사람도 있을 것이다개발자를 부품으로만 생각하는 회사는 개발자가 없어도 문제없게 만들어 놓은 개발자는 언제든지 자를  있다실제이런 회사도 많이 있고 이런 회사에서 일하는 개발자라면 유지보수가 어렵게 코딩하는 방법  공부하기를 바란다.

개발자가 자신이 없어도 회사가 문제 없이 돌아가게 하려면 공유를  해야 한다문화적으로 성숙되고 프로세스를  갖춘 회사라면 모든 개발업무가 진행되면서 자연스럽게 공유가 되는 시스템을 갖추고 있다중간 중간 리뷰 과정을  거치고 문서화가 되며 지식과 경험이 자연스럽게 여러 사람과 공유가 된다이런 프로세스를 뒷받침할 기반시스템도 적절히 갖추고 있다공유를 위한 공유가 아니기 때문에 훨씬 자연스럽고 부담도 없다.

자신은 어떤가 생각을 해보자한달간 휴가를   있을까회사의 모든 직원이 각자 한달간 휴가를  있을까그렇지 않다면 무엇을 바꿔야 할지 생각해보자.