 |
소프트웨어 분야에 진정 블루오션은 없는가 |
 |


김도형 dynaxis@alticast.com
양방향 TV 솔루션 개발을 해 왔고 현재는 DMB를 위한 자바 규격 표준화와 제품 개발을 맡고 있다. JSR 242, JSR 272 등 방송 관련 JSR에 전문가로 참여했으며, 자바 외에 프로그래밍 언어 전반, XML 등 다양한 분야에 걸쳐 관심을 가지고 있다.
2007년 12월 4일
|
|
 |
|
"인류가 발명할 수 있는 것은 이미 모두 발명되었다" - 찰스 H. 듀엘(Charles H. Duell, 미국 특허청장, 1899)
이 문구는 자주 인용되는 문구로, 아마 들어본 사람이 많을 것이다. 이런 문구 중에는 정작 당사자는 그런 말을 한 적이 없는데 잘못 전해진 것이 꽤 많은 편인데 이 문구도 그렇다고 한다(http://findarticles.com/p/articles/mi_m2843/is_3_27/ai_100755224). 어느 분야나 마찬가지겠지만 소프트웨어 분야에 종사하는 사람들도 이 문구와 별반 다를 바 없는 이야기를 입에 달고 산다. "이제 소프트웨어 쪽에서 획기적인 것이 있나?", "소프트웨어로 돈 될 만한 거리가 있나?" 등.
그래서 이번에는 소프트웨어 분야에 정말 해 볼게 그렇게 없나에 대해 생각해 보고자 한다. 제대로 쓰면 "소프트웨어 사업 아이디어 10선"이라는 제목에 하드커버로 제본하고 출퇴근 전철 안에서 가볍게 독파할 수 있는 분량에 맞춰 만 원 남짓하게 팔아 돈 꽤나 챙기겠지만 사업 아이디어가 그리 쉽게 나오겠는가. 2005년 국내에 발간돼 센세이션을 일으킨 "블루오션 전략"도 새로운 블루오션을 알려주지 않아도 도움이 되듯, 과거와 최근 동향을 살피면서 뭔가 힌트를 찾아보는 것만으로도 나름 주의가 환기되지 않을까 한다. "블루오션 전략"이 사례로 드는 블루오션이 결코 기존 레드오션과 멀리 떨어진 전혀 다른 분야에 있는 것이 아니듯, 소프트웨어 분야에서의 블루오션도 많은 경우 전혀 새로운 것은 아니라고 생각한다.
들어가기에 앞서 이 글에서는 소프트웨어 쪽이라도 개인적으로 듣고 분석해 알고 있는 여러 분야를 언급하다 보니 그 분야 종사자 입장에는 다소 맞지 않는 이야기가 있을지도 모른다. 혹시 그런 부분이 있으면 언제든지 이메일로 알려 주시면 참고하고 기회를 만들어 첨언하겠다.
나에게 쉬운 건 남에게도 쉬울까?
1994년 경기도 소재의 육군 모 부대에서 개인적으로 겪었던 일이다. 당시는 방위병이 있던 때라 동사무소 향방 요원에게 지급될 월급 액수를 매달 은행에 통보해 줘야 했다. 부대 인사계원(인사계원도, 필자도 방위병이었다)이 은행에서 제공한 간단한 프로그램을 이용해 매달 수백 명에 달하는 사병들의 지급액을 일일이 손으로 입력해야 했는데, 분량이 분량이다 보니 꽤 시간을 잡아 먹을 수 밖에 없었다. 안 그래도 일이 많아 야근이 잦은 인사계원에게는 꽤 성가신 일이었다.
그런데 재미있는 것은 매달 근무 일수 때문에 금액이 바뀌기는 하지만 수백명 각각의 월급이 다 다른 게 아니라는 점이었다. 서너 그룹으로 나눠보면 같은 그룹에 속한 사병은 항상 같은 금액을 받게 돼 있었다. 개인적인 호기심에 은행에서 준 프로그램을 살펴보니 베이직(BASIC)으로 작성됐고 최종 파일이 그저 텍스트 파일일 뿐임을 곧 알 수 있었다. 그 다음 한 일은? 당연히 텍스트 편집기 프로그램을 열어 "찾기/바꾸기" 메뉴를 선택, 1분도 안 돼 인사계원의 골치거리 하나를 끝내줄 수 있었다. 대가는 당시로는 진미였던 전자레인지에 녹인 냉동 만두였다. 한술 더 떠 그 인사계원은 옆 부대에 그 노하우를 가르쳐 주고 본전을 뽑았다. 가벼운 일화지만 소프트웨어 분야에도 나에게는 쉽지만 남에게는 그리 쉽지 않은 부분을 간과한 예가 적지 않다.
온라인 게임 서버의 예
얼마 전 자바 사이트에서 반가운 기사를 하나 보았다(http://java.sun.com/developer/technicalArticles/Interviews/kesselman_qa.html). 최근 오픈 소스로 공개된 프로젝트인 다크스타(Darkstar) 관련 인터뷰 기사인데, 개인적으로는 이 프로젝트가 오픈 소스로 공개되기 전 JavaOne에서 접한 적이 있다. 당시 샌프란시스코에서 스파이더맨 2를 봤으니 2004년이었던 것 같은데 이제 오픈 소스로 공개되었으니 어느 정도 진척이 있었을 것이고, 온라인 게임 업계로서는 새로운 시도를 해볼 좋은 기회가 아닌가 한다.
이 프로젝트는 MMORPG(Massively Multiplayer Online Role-Playing Game)처럼 동시 접속자가 많은 온라인 게임이나 세컨드라이프 같은 대규모 온라인 커뮤니티를 위한 서버 플랫폼이다. 다크스타는 생각해 보면 당연하지만 현재 온라인 게임에서는 구현하고 있지 못한 일을 가능하게 하는 일종의 서버 쪽 "게임 엔진"이라고 할 수 있다. 인터뷰를 읽어 보면 알겠지만 편의를 위해 요약하자면 다크스타는 기존 온라인 게임 업계에 다음과 같은 해법을 제시하려 하고 있다.
- 영역(Zone)이나 서버(Shard, 사실은 서버군)로 사용자가 뿔뿔이 흩어지지 않고 모두 한 세계에서 활동할 수 있는 온라인 게임
- 더 많은 게임 상태를 더 안정되게 저장해 서버가 다운되더라도 캐릭터 정보 외에 배경 등 변화가 남아 있고 다운되기 전 손실이 극소화되는 게임
- 영역이나 서버가 별도로 없고 동일한 서버에 동시에 여러 게임을 돌릴 수도 있게 함으로써 모든 서버의 가동율을 높여 천문학적인 온라인 게임 퍼블리싱 비용을 감소
개인적으로는 모 게임 업체 사장님이 영역 서버 내에서 상업성이 있을 수준의 동시접속자를 처리할 수 있게 성능을 끌어내는 것도 그리 쉽지 않다며, 서버 쪽에서도 네트워킹과 데이터베이스 같은 분야에 전문성을 가진 사람이 서버 쪽 "게임 엔진"을 내놓는 날이 곧 올 것이라고 이야기 했던 기억이 난다. 생각 외로 온라인 게임 업계의 초점이 게임성이나 클라이언트 쪽에 많이 가 있다는 생각을 했는데 위 인터뷰를 읽어보면 비슷한 이야기가 나온다(현 온라인 게임 서버 구축이 쉽다거나 엉망이라는 뜻이 아니다. 오해 마시길...).
|
Game developers, by and large, are not server developers, so they focus on their clients. They generally attend minimally to what's needed on the server side -- just enough to make sure their game will work. We're bringing Sun's considerable knowledge and expertise in scalable network systems to the online multiplayer game industry. Nobody else in the game industry has that expertise, and nobody else is approaching online game development with that focus.
|
해석하면 "게임 개발자들은 대체로 서버 개발자가 아닙니다. 그래서 주로 클라이언트 쪽에 초점을 맞춥니다. 또 일반적으로 서버 쪽에 필요한 요소에 대해서는 최소한만 주의를 기울입니다. 즉, 게임이 제대로 동작하기에 충분한 정도까지만 말이죠. 우리(다크스타 팀)는 확장성 있는 네트워크 시스템에 대한 썬의 풍부한 지식과 전문성을 온라인 멀티플레이어 게임 업계에 적용하고 있습니다. 게임 업계의 다른 누구도 그런 전문성을 가지고 있지 못하고, 누구도 온라인 게임 개발을 그런 관점에서 접근하지 않고 있습니다." 정도가 되겠다. 먼저 내가 안다고 남도 잘 안다는 편견부터 깨뜨려 보면 어떨까?
시장은 공평하지 않다
시장 경제 하에서 사는 우리는 시장이 자원 분배 평준화를 약속하는 체제가 아님을 잘 알고 있다. 여러분이 소프트웨어 개발자라면 자신이 일할 수 있는 분야를 한번 떠올려 보라. 고작해야 웹, 데이터베이스, 게임, 데스크톱 애플리케이션, 그리고 모호하게 임베디드 시스템 정도가 떠오르지 않는가?
하지만 소프트웨어가 필요한 곳은 생각하는 것보다 훨씬 많다. 그럼 당장 떠오르는 분야는 왜 쉽게 떠올릴 수 있는 걸까? 많은 돈이 오가고 충분히 개발된 시장이기 때문이다. 결국 그렇지 않은 음지가 절대적으로 많을 것이라 직감할 수 있다. 이처럼 단순히 전문 분야가 다른 사람들끼리의 교류가 필요한 정도가 아니라 인적 자원 자체가 충분히 투입되고 있지 않고 소프트웨어에 대한 전반적인 인식도 떨어지는 분야도 있다. 이른바 인력의 쏠림으로 인해 소외된 분야다.
ATM/CD 업계의 고민
이 글을 준비하면서 물어보니 그 사이 상황이 많이 바뀌긴 했던데 우리가 은행에서 흔히 볼 수 있는 ATM(Automatic Teller Machine)/CD(Cash Dispenser) 기계 시장에도 나름 소프트웨어 관련 고민들이 있다. 최근 ATM/CD기는 모두 PC 기반에 윈도우를 운영체제로 사용하고 있고 또 보안상의 이유로 근간에 윈도우를 필수화하고 있다고는 하는데, 불과 몇 년 전 이 업계가 특화된 하드웨어에서 탈피해 PC로 갈아타면서 비용에서 혁신을 이룬 후 몇 가지 고민이 있었다고 한다. ATM/CD기는 고가이기는 하지만 고가의 각종 센서를 사용하고 금형 등 기구 개발 비용도 커서 마진이 결코 넉넉하지 않다고 한다. 이 때문에 1차적으로 생기는 고민은 운영체제로 사용하는 윈도우의 상대적으로 비싼 가격이었다. 그 다음 문제는 개발 환경인데 애플리케이션 수준에서 C/C++로 작업하는 각종 소프트웨어의 유지 보수 문제였다. 어디나 마찬가지지만 소프트웨어가 오래 되고 원 작성자가 퇴사라도 하면 대체 어디가 필요한 모듈이고 어디가 불필요한지조차 파악하기 힘들어지는 법, 신뢰도가 중요한 ATM/CD기에서 이런 상황이 닥치면 간혹 입찰에 들어가 벤치마크 테스트 도중에 문제 없기를 기도하는 진풍경이 빈번히 발생할 수 밖에 없다.
예전 이야기를 들으면서 개인적으로 제안했던 해법은 리눅스에 자바 SE 사용이었는데 문제는 초기에 리눅스 기반으로 이행하고 자바 기반으로 틀을 닦아줄 인력이 없고 그런 해법에 대한 업체의 인식이 낮았다는 점이다(역시 해당 업계 종사자들을 폄하하는 의도는 아니다. 솔직히 이런 초기 이행을 맡을 인력은 고정적으로 확보하고 있을 필요까지는 없다고 생각한다).
재미있는 것은 최근 다른 일로 자바 SE 임베디드의 라이선스 조건을 문의한 적이 있는데 이 때 들은 이야기로는 독일의 경우 ATM에 자바를 적용한 사례가 있고 그 이유인즉 고객별, 설치 지역별로 꽤 빈번히 수정되어야 하는 ATM의 특성상 소프트웨어 관리 등의 문제를 고려할 때 자바처럼 어느 정도 소프트웨어 신뢰성을 담보하고 들어갈 수 있는 솔루션을 택하게 됐다는 것이다.
임베디드 소프트웨어는 양지에?
최근 휴대전화, MP3 플레이어 등 범람하는 디지털 기기의 홍수 속에서 나름 임베디드 소프트웨어 분야에 대한 인지도는 상당히 높아진 듯하다. 그렇다면 임베디드 소프트웨어 분야는 "양지"에 있다고 이야기할 수 있는 것일까? 개인적으로는 아니라고 생각한다. 윈도우 CE 정도를 제외하면 임베디드 시스템 쪽 소프트웨어 개발 환경은 벌써 10년 넘게 거기서 거기다.
그동안 서버 쪽에서는 자바처럼 고수준 언어와 PHP, 루비(Ruby)처럼 스크립트 언어를 사용하게 되었다. 그뿐만 아니라 서버 관련 프레임워크와 개발 환경은 날이 갈수록 발전하고 있다. 데스크톱으로 와도 사정은 마찬가지다. 마이크로소프트의 C/C++ 개발 환경만 해도 근간 많은 발전을 해 왔고 최근에는 자바나 .NET 환경에서 작성된 상업 애플리케이션도 많이 늘어났다.
물론 제한된 임베디드 시스템 자체의 한계와 하드웨어 하부를 건드려야 하는 일이 빈번한 상황에서 윈도우 CE나 리눅스 정도가 아니면 편한 개발 환경을 제공하기 힘든 것이 사실이라 할 수도 있겠지만 개인적으로는 결코 그렇지만은 않다고 생각한다. 투입에서 차이가 있었다는 것이 개인적인 견해다. 자바 ME가 수많은 휴대전화와 디지털 TV 수신기에 탑재되어 있지만 아직은 임베디드 시스템을 구축하기 위한 도구라기보다는 콘텐츠 플레이어에 가깝다.
소프트웨어진흥원에서 지난 11월 16일에 "비IT산업의 임베디드SW 기술 융합 세미나"를 개최했다. 해당 사이트가 링크를 걸 수 없는 구조로 되어 있어서 설명하면, 세미나 개요와 자료는 상단 "SW정보센터" 메뉴에서 "진흥원 발간자료"를 선택해 "세미나/행사자료"를 선택하면 된다.
자료 중 진흥원 쪽 발표 자료를 보면 첫째, 생각 외로 하드웨어를 직접 손대는 드라이버나 OS보다 애플리케이션에 해당하는 부분의 오류 발생률이 어느 분야나 제일 높다는 점이 재미있다. 저수준이라 더 나은 도구를 제공하지 못하는 게 문제 핵심이 아니라는 이야기다(물론 저수준 쪽 코드도 적절한 도구를 쥐어 줌으로 개선의 여지가 있다고 생각한다). 둘째는 비IT 분야, 즉, 우리가 쉽게 떠올리지 못하는 분야에 생각 외로 소프트웨어 측면에서 할 일이 많다는 점이다. 국내 굴지의 디지털 TV 셋톱박스 제조 업체에서 들은 이야기다. 이 분야에 처음 뛰어 들었을 때는 하드웨어 80%, 소프트웨어 20%였다면 지금은 하드웨어 20%, 소프트웨어 80%라는 이야기였다. 모든 분야에서 소프트웨어의 중요성이 커지고 있다.
친구가 다녔던 인체를 측정하는 기기(구체적으로 이야기하면 다 알 만한 회사라 모호하게만 언급한다)를 만드는 업체는 외국에 비해 후발 주자였다. 결국 국산 제품으로 위치를 확보, 선두 주자를 압박하면서 안착했는데, 거기에는 여러 이유가 있었지만 그 중 중요한 요인 중 하나는 경쟁사와 차별되는 쉬운 사용자 인터페이스였단다. 문제는 그 회사도 상당 시기까지 저수준 프로그래밍을 하는 하드웨어 엔지니어에 의존해 소프트웨어를 만들었고 심지어 OS조차 없이 개발하는 환경이었는데, 현재의 제품이 나오기 위해 소프트웨어 인력이 보강되고 체계적인 프레임워크를 구축해 나갔음은 말할 나위가 없다.
결국 시장은 자원을 평준화해 공급하지는 않는다. 하지만 다행인 것은 해당 분야의 인식이 제대로 잡히고 솔루션 개발, 컨설팅 등의 형식으로 시작하면 이런 분야들도 당장 빛을 보고 더 나아가 시장 규모가 더 성장할 수 있다는 점이다.
 |

|
소프트웨어 업계에 창세기는 없다
소프트웨어 업계에서 블루오션의 "발견"은 말 그대로 남보다 뛰어난 통찰력과 발상의 전환에 따르는 "발견"이지 "창조"는 아니었다고 생각한다. 몇 가지 예를 들어보자. 제록스(Xerox) PARC 연구소에서 맥의 전유물로 알려진 GUI 개념을 빌려(?)온 일화는 아이콘을 비롯한 많은 책에서 찾아볼 수 있다. 오늘날 서버 환경을 혁신적으로 바꿔 버린 자바도 사실 "창세"의 결과는 아니었다. 가상기계 개념도, 가베지 콜렉션도, 인터페이스 같은 언어의 핵심 개념들도 이미 학계이 있던 걸 잘 조합해 튜닝한 것이라고 보는 편이 맞다. 자바의 아버지인 제임스 고슬링(James Gosling)의 엔지니어로서 탁월한 균형 감각에는 찬사를 보내지만 개인적으로는 오베론(Oberon) 같은 언어/OS처럼 비록 학계에서만 떠돌았지만 탁월한 엔지니어링의 결정체가 많았다고 생각한다. 차이는 회사에서 만들어져 잘 "마케팅"됐다는 점이 아닐까 한다. C++도 마찬가지 예다.
결국 소프트웨어 분야에서 "창세기"가 블루오션으로 인도하는 예언서가 아니라면 현재 학계와 업계에서 쏟아내는 다양한 성과와 실패에서 블루오션으로 가는 열쇠를 건져내는 것도 충분히 가능할 것이다. 현재 기술과 관례는 그것이 현 상황에서 최적이라서 존재하는 것이 아니다. 그저 업계는 그 속성상 변화를 두려워할 수 밖에 없다. 그런 상황에서 자바와 같은 시도가 틀을 깨면 블루오션을 창출할 수 있는 것이다. 예를 들어 자바에 이르러 일반화된 가베지 콜렉션 개념의 경우 학계에서는 직접 메모리 관리에 비해 느리고 비효율적이라는 편견에 대해 합당한 해답까지 내어 놓았던 상황이었다. 자바는 보수적인 업계의 흐름에 변화를 준 것일 뿐이다.
마치면서
소프트웨어 분야에서 늘 간과하는 부분에 대해 생각하는 바를 두서 없이 정리해 보았다. 늘 그렇지만 새로운 시장을 열려면 통찰력과 남다른 사고 전환이 필요하다. 서로 다른 분야의 사람들과 교류하고, 잘 모르는 분야에도 관심을 가져 보며, 각종 논문과 소식에도 귀를 기울여 보자. 사실 인력이 넘쳐나는 대형 회사 내에도 마찬가지 기회가 있을 수 있다. 최근 인력을 흡수하다시피하고 있는 대형 포탈 사이트도 정작 부분부분을 보면 많은 허점이 보인다. 새로운 기회는 항상 내 옆에 있다.
[지난 developerWorks Column 보기]
|
 |
|
 |