검색어 소프트웨어이야기에 대한 글을 관련성을 기준으로 정렬하여 표시합니다. 날짜순 정렬 모든 글 표시
검색어 소프트웨어이야기에 대한 글을 관련성을 기준으로 정렬하여 표시합니다. 날짜순 정렬 모든 글 표시

2011년 8월 19일 금요일

삼성이 M&A를 통해서 이번에는 소프트웨어 경쟁력을 갖출 수 있을까?


필자가 1년반쯤 전에 쓴 삼성의 소프트웨어 경쟁력에 대한 글을 보면 새삼 감회가 새롭니다. 요즘 한창 이슈가 되고 있는 M&A 등의 이슈를 다루고 있다. 단순한 상황 뿐만 아니라 방법도 제시를 하려고 했었다.
아래는 해당 글들이 있다.

2010/01/05 - [소프트웨어이야기] - 삼성은 왜 소프트웨어를 잘 만들지 못할까?
2010/01/23 - [소프트웨어이야기] - 삼성이 바다를 출시해서는 안되는 이유
2010/02/08 - [소프트웨어이야기] - 삼성이 앞으로도 소프트웨어를 잘 만들 수 없는 이유
2010/03/02 - [소프트웨어이야기] - 삼성이 소프트웨어 분야에서도 최고가 되려면?

삼성이 왜 소프트웨어 경쟁력이 부족하고 어떻게 소프트웨어 경쟁력을 갖출 수 있는지 나름대로 방법을 제시했었다. 특히 3/2 글에서는 좀더 실패를 해서 소프트웨어 중요성을 더 깨달아야 한다고 했었는데 좀더 실패를 경험한 모양이다.

그 때 제시를 했던 것이 크게 두가지였다.

첫째, 
소프트웨어 회사 M&A이다. 물론 국내 소프트웨어 회사는 아니다. 국내의 다른 소프트웨어 회사와 비교하면 삼성의 소프트웨어 역량은 차라리 높은 편이다. Global한 경쟁이 안된다 뿐이지 국내에서는 잘하는 셈이다. 그도 그럴 것이 우수한 소프트웨어 인력 싹 쓸이 해갔고 그동안 효율적이지는 않지만 소프트웨어에 물질적으로 엄청난 투자를 해왔기 때문이다. 그럼에도 글로벌 Software회사와는 엄청난 차이를 보이고 있는 것은 어쩔 수 없다. 심지어는 몇명이 뭉쳐서 만든 실리콘밸리의 스타트업 회사보다 개발 문화나 역량 면에서 못한 것은 안타가운 일이다.

둘재, 
소프트웨어를 잘아는 전문 경영인들을 확보해야 한다. 이들이 조직내에서 밀리지 않도록 꾸준한 지원도 필요하다. 그동안 소프트웨어 전문가들이 있었음에도 조직내에서 제 목소리를 내지 못하고 단기적인 비즈니스 논리에 밀려서 제대로 힘을 못써왔고 많이들 밀려나고 말았다.

그럼 이번에는 삼성이 제대로 소프트웨어 역량을 강화할 수 있을 것인가? 궁금하지 않을 수 없다. 

삼성이 이토록 소프트웨어 역량 강화에 관심을 가지는 이유는 살아남기 위해서이다. 진작부터 여런 산업 분야에서Hardware보다 Software 비중이 점점 높아지고 있었는데 공룡 조직의 느린 움직임으로는 이를 따라 잡지 못하고 있었다. 연일 신문에서는 소프트웨어를 떠들지만 사실 단어로서 의미 이상을 느끼고 있는지 모르겠다. Hardware 중심으로 마인드가 박힌 조직이 단시일내에 바뀌기란 불가능하다. 

최고 경영층에서 M&A를 강조하고 있기 때문에 뭔가 사기는 살 것이다. 하지만 M&A를 통해서 절대로 사올 수 없는 것이 있다. 바로 
"Soft적인 기업 문화"이다. 소프트웨어 역량을 갖추기 위해서는 "Soft적인 기업 문화"가 필요한다. 삼성과는 너무나 거리가 멀다. 

지금 Hardware는 잘하고 있는데 Software가 부족해서 "사온다"의 의미로는 이미 너무나 부족해졌다. 

필자는 
"삼성의 상당한 조직은 완전히 Software적으로 재편되어야 한다"고 생각한다. 이는 삼성 뿐만이 아니다. 이제 상당히 많은 산업 분야가 Software가 중심이고 Hardware는 부가적인 것이 이미 되었고 점점 더 가속화가 되고 있다.

M&A를 통해서 핵심 기술과 특허를 사올 수는 있지만 이는 "공룡에 분칠"하는 정도일 것이다. 지금 필요한 것은 대대적인 조직문화 탈바꿈이고 이를 이끌 수 있는 "수혈"이 필요하다. 수혈은 소프트웨어 전문 경영인을 말한다. 물론 몇몇 우수한 소프트웨어 전문 경영인들이 있기는 하지만 조직에 비해서는 너무나도 적은 인원이고 더 큰 힘도 필요하다. 지금 바뀌지 않으면 기회가 없을지도 모른다.

안타까운 것은 이러한 시도가 너무나 무모해 보이기도 한다. 이러한 변화를 기존 조직의 기득권층이 과연 받아들이고 융합이 될 것인가? 필자는 어렵다고 본다. 따라서 전 조직이 아니라 소프트웨어 비중이 높은 조직부터 바뀌거나 아예 기존 조직과 거리를 두는 새로운 조직을 만드는 것이 차라리 가능성이 있어 보인다.

필자는 삼성이 Soft하게 바뀌는 것이 국내 소프트웨어 산업에도 많은 도움이 될 것으로 생각한다. Soft적인 마인드는 자연스러운 공생의 길을 가게 만들것이다.

미우나 고우나 삼성은 국내 소프트웨어 업계 뿐만아니라 전체 경제에 막대한 영향을 주고 있으므로 잘 되어야 한다. 

소프트웨어에 있어서는 과거처럼 안 된다는 것을 빨리 깨달아야 한다. 
소프트웨어는 생각하는 것보다 1,000배쯤 어렵고 복잡한 것이다. 
돈주고 쉽게 사올 수 있는 것도 아니다. 
소프트웨어적인 역량이 있는 회사만이 좋은 회사를 사와도 도움이 되는 것이다.
지금의 마인드를 바꿀 수 없다면 점점 뒤쳐질 수 밖에 없을 것이다.

2010년 2월 8일 월요일

삼성이 앞으로도 소프트웨어를 잘 만들 수 없는 이유

저는 이미 삼성의 소프트웨어에 대한 글을 몇개 올린 적이 있습니다.

이글의 제목은 좀 과격해보이기는 하지만 현재 문제가 뭔지 파악해보고 해결책을 생각해보고자 이와 같은 제목을 붙였습니다.
사실  이글들은 삼성 뿐만 아니라 국내 대기업 대부분에 해당하는 글이며, 삼성이 대표기업이고 현재 스마트폰 열풍의 한 가운데 있기 때문에 대표주자로서 언급이 되고 있는 겁니다. 다른 대기업들이나 중견기업들도 별반 다를게 없다는 얘기죠. 저는 이에 대한 상당한 근거들을 가지고 있습니다. 물론 직접적인 데이터는 컨설팅 비밀이라서 공개할 수 없습니다. 하지만 통계를 근거로 이 이야기를 공유하고자 합니다.

이 글들에 대해서 문제점만 지적하지 말고 해결책도 제시해달라는 의견들이 있어서 얘기를 조금 더 진전시켜보고자 합니다. 앞으로 쓸 글들의 일부는 삼성과 여러 대기업 뿐만 아니라 중소 소프트웨어 회사들에게도 해당이 될 것입니다.

저는 소프트웨어 개발자 한사람 또 소프트웨어 공학 컨설턴트로서 삼성을 비롯해서 2,3명 규모의 모든 소프트웨어 회사들까지 모두 정말 잘되기를 바라고 있으며 그 안에서 소프트웨어를 개발하는 개발자들이 
  • 즐겁게 일하고
  • 육체/정신 건강을 지킬 수 있는 적절한 시간동안 일하고
  • 주위에서도 좋은 직업으로 바라봐주고
  • 좋은 비전을 가지고 있으며
  • 연봉도 다른 직종에 비해서 상대적으로 많이 받기를 바랍니다. 
  • (꿈같은 얘기가 아니고 다른 나라에서는 벌어지고 있는 현상입니다.)
해결책을 제시하기 전에 오늘은 먼저 왜 기업이 바뀌기가 어려운지 먼저 얘기를 하려고 합니다. 그래야 해결책이 눈이 보일 겁니다. 

축구를 잘하기 위해서 기초체력을 기르고 기초 기술과 팀웍, 전술을 익히면 된다고 하고 이게 모든 해결 방법이면 얼마나 좋겠습니다. 축구를 잘하는 원리는 간단하겠지만 지금 문제가 있다면 해결책은 그렇게 간단하지 않습니다. 예를 들어 우리나라가 축구를 잘하기 위해서 축구협회가 문제면 이를 해결해야 할 겁니다.

삼성이라고 소프트웨어의 중요성을 하나도 모르겠습니까? 잘 알겁니다. 특히 밑으로 내려올수록 더 잘 알것이고 경영진들은 그걸 피부로 느낄만큼 소프트웨어를 잘 알지도 못하죠. 그런데 몇십년을 소프트웨어에 투자를 했는데도 지금 좋은 소리를 듣지 못하고 있고 제 생각에 앞으로도 크게 나아질 것 같지 않은 이유를 분석해보겠습니다.

먼저 위쪽을 보겠습니다.

기업은 클수록 정치, 파벌에 따라서 조직이 움직입니다. 특히 고위층은 실력만 가지고 되는 것은 아니고 실적과 함께 정치도 중요하죠. 하지만 제가 알기로는 국내에는 소프트웨어 전문가가 부족하거니와 그나마 있는 소프트웨어 전문가들도 대기업내에서 그렇게 확실한 파워를 가지고 있지 못합니다. 또한 기업은 성과가 최고의 덕목인데, 소프트웨어 전문가들은 장기적인 뷰로 사사건건 문제를 지적하고 장기투자, 문화 등을 논하기 때문에 기존 하드웨어 파벌에 비해서 이쁨을 받기는 어렵습니다. 항상 위기라고 주장하는 상황에서 툭하면 밀려나기 일쑤입니다.
결국 소프트웨어를 이해하지 못하는 경영자가 아무리 소프트웨어 투자를 한다고 해도 소프트웨어 개발 역량은 별반 나아지지 않습니다.
최근의 스마트폰 사태에서도 힘을 얻어야 할 소프트웨어 전문가들이 오히려 힘을 얻지 못하는 상황이 벌어지는 것이 어찌보면 당연한 수순이라고 볼 수 있습니다. 누가 이 스마트폰 사태를 순식간에 해결할 수 있느냐라는 질문에 당장 밀어 붙여서 올해안에 스마트폰 시장을 점령할 수 있다고 말하는 하드웨어파에게 솔직함이 죄인 소프트웨어 전문가들은 밀려날 수밖에 없을 것 같습니다. 알고 거짓말은 못하죠. 하지만 모르면 용감하다고... (이건 제가 생각하는 현재 상황의 시나리오입니다.)
기업들은 크나 작으나 주로 이런 식의 단기적인 관점으로 기업의 전략이 결정되고 있고, 이렇기 때문에 우리나라에서는 대부분 CTO(Chief technical officer)가 제대로 힘을 발휘 못합니다. 적어도 소프트웨어가 중요한 회사라면 CTO가 힘이 있고 제역할을 할 수 있어야 합니다. 우리나라에는 소프트웨어 회사에서 CTO역할을 할 수 있는 인재도 부족하거나와 CTO와 연구소장을 혼동하는 사람들도 많은 것이 안타깝습니다.

장기적인 관점에서 용단을 하고 힘을 줄수 있는 사람은 한사람 밖에 없어보이네요.

개발자들도 현재 환경에 너무 익숙해져 버려서 현재 열악한 상황에서 고생을 하고 있지만 이를 바꾸겠다고 하면 저항을 하게 됩니다. 
이유야 여러가지가 있습니다. 
옛날에도 이런 저런 시도를 많이 했는데 일만 많아지고 바뀌는 것이 없다고 하기도 하고 뭔가 바뀌면 기존의 방식에서 나만이 가지고 있던 파워를 잃게 될까봐 걱정을 하기도 합니니다. 또 뭔가 바뀌는 것이 무조건 싫기도 합니다.
안타까운 얘기지만 현재 개발자들을 제대로 바꾸기에는 너무 멀리 왔습니다. 정말 오랜 시간이 걸릴 겁니다. 그전에 여러 저항에 부딪혀서 포기할 것 같습니다. 
소프트웨어 개발은 문화인데, 너무 큰 조직이 기존의 방식에 너무 익숙해져 있어서 바꾸기에는 어려워 보입니다. 
"길들여져 버렸어"라고 밖에 할말이 없습니다.

그동안의 제 소프트웨어 지식과 컨설팅 경험으로 이쪽에서 살펴보고 저쪽에서 분석을 해봐도 획기적인 시도를 하기 전에는 삼성이 앞으로도 소프트웨어를 잘 만들 방법이 잘 안보입니다. 조금더 연구해보고 다음에 진짜 해결책에 대한 글을 써보도록 하죠.

비단 이 이야기가 삼성뿐만의 이야기 일까요? 우리나라 거의 대부분의 소프트웨어 회사의 이야기입니다. 자신의 회사는 전혀 그렇지 않다는 분은 제게 알려주세요. 정말 좋은 소수이 소프트웨어 회사 중 하나이거나 문제를 전혀 인식조차 못하는 회사일 겁니다. 제가 문제가 뭔지 철저히 분석해서 알려드리고 앞으로 어떤 문제들이 벌어지는지 예언도 해드리겠습니다.

이 글을 보고 삼성의 최고 경영진에서 소프트웨어파에 힘을 실어주는 일이 생기기는 어렵겠지만 바뀌면 좋겠네요. 대한민국 경제에 너무 큰 영향을 주고 있는 삼성이기에 저는 항상 잘되기를 기원하고 있습니다.

2010년 3월 2일 화요일

삼성이 소프트웨어 분야에서도 최고가 되려면?

최근 삼성과 소프트웨어에 대한 글들을 몇 건 올리면서 정말로 다양한 의견을 접하게 되었습니다.
댓글뿐만 아니라 메일을 통해서도 의견을 들을 수 있었습니다. 

그 중에는 삼성 관계자 분들도 있었고, 삼성 내부 개발자, 삼성 협력사의 개발자들도 많이 있었습니다. 
현재 삼성으로 대표되는 대한민국 대기업들의 소프트웨어 개발 현황을 살펴보고 해결책을 찾아보려고 하는 블로그 글에 상당히 과민반응을 보이는 글들을 보면서 현 상황을 더욱 잘 짐작하게 해줍니다.
특히, 인상적인 글들은 삼성 내부 개발자와 삼성 협력사의 개발자의 글들이었습니다. 상당히 충격적인 증언들도 있었습니다. 댓글과 메일을 포함해서 삼성 내부 소프트웨어 조직의 심각성을 좀더 잘 알 수 있었습니다.
어쨌든 모든 댓글 및 메일을 보내주신 분들에게 감사 드립니다.

이제 결론을 내릴 때가 된 것 같습니다. 애초의 글들의 목적은 도무지 가망이 없어 보이는 대한민국의 소프트웨어 환경, 특히 삼성으로 대표되는 대기업들의 열악한 소프트웨어 개발 환경을 극복하고 소프트웨어 분야에서도 최고가 되는 방법을 찾아보려는 것이었습니다. 제 사견이긴 하지만, 그 동안의 소프트웨어 개발 및 컨설팅 경험을 근거로 나름대로 전문적이고 현실적인 방법을 찾아보려고 노력했습니다.

그럼 삼성이 소프트웨어 분야에서도 최고가 되는 방법의 시나리오를 보죠.

1. 좀더 실패가 필요합니다. 
어이 없는 결론이기는 하지만 몇번 더 실패를 통해서 소프트웨어의 중요성을 좀더 깨달아야 합니다.
현재 돌아가는 상황을 보면 소프트웨어 분야에 있어서 실패를 했고 실력은 부족하고 소프트웨어에 투자를 해야 한다는 간단한 현황을 진정으로 인식하고 있는 것으로 보이지 않습니다.
제가 삼성 및 대기업의 소프트웨어 개발 능력 부족을 지적하는 글을 작성한 이후에 놀랍게도 신문, 방송 모두 거의 똑같은 의견을 연일 쏟아 냈습니다. 이에 대응하여 삼성에서 발표한 극복 방안은 대부분 단기적이고 비전문가적인 접근들이었습니다. 소프트웨어 전문가라면 금방 문제가 있다는 것을 눈치챌 정도로 허술한 것들이었습니다. 
이는 현재상황을 진정으로 이해하고 있는 것이라고 볼 수 없습니다. 안타깝게도 몇번의 실패를 더 해야 진짜 문제가 심각하고 이대로는 안 된다는 것을 알 수 있을 것 같습니다. 삼성 내부에서도 아랫사람들이 아무리 얘기를 해봤자 시장에서 크게 실패하기 전에는 이를 깨닫기 어려울 것 같은 같습니다.
개인적인 바램은 최상위 경영층에서 가능하면 빨리 이를 인지해야 할 것 같습니다. 자칫하면 너무 늦을 수도 있습니다.

2. 소프트웨어 전문 경영자를 다시 중용해야 합니다.
기업의 경영자 인사는 다분히 정치적인 요소가 강합니다. 그러기 때문에 소프트웨어 전문 경영자가 중용되거나 오래 버티기가 힘들지만, 진짜 실패를 통해서 최고의 자리를 유지하기 위해서는 소프트웨어에 투자하는 수밖에 없다는 것을 깨닫고 나면 이를 이끌 소프트웨어 전문 경영자가 필요합니다. 
대기업의 소프트웨어 현황을 대변하는 말 중 하나가 "조삼모사"입니다.
"조三모四"아니 "조三모七"을 주장하는 소프트웨어 전문 경영자보다 "조四모一"을 얘기하는 경영자가 더 오래 살아남습니다. 여기서 저녁의 "일"은 얘기거리도 안됩니다. 소프트웨어 분야에서는 "조三모四현상이 더욱 극명하게 나타납니다.
애플은 아이폰의 플랫폼은 단 하나만을 사용하고 있고 구글도 안드로이드 하나를 사용하고 있습니다. 안드로이드는 핸드셋마다 변경될 수는 있지만 상당부분 호환성을 유지하고 있습니다.
그런데 국내의 한 굴지의 핸드폰 제조사는 지금까지 나온 6,000여개의 핸드셋에서 서로 다른 6,000개의 플랫폼을 사용하고 있습니다. 이를 공통으로 사용할 수 있는 플랫폼을 개발 할 수도 있었겠지만, 하나의 핸드셋만 놓고 보면 소스코드 복사해서 따로 만드는 것이 시간이 더 단축되기 때문에 "조三모七"이 아니고 "조四모一"을 선택한 것입니다. 
"一"이 아니고 마이너스 상황이 되고 소프트웨어가 지속적으로 발목을 잡기 전에 "소프트웨어 전문 경영자"가 이를 극복할 수 있도록 해야 할 것입니다. 또한 기존의 조직, 기존 사업부에서 결국 단기적인 실적 목표에 또 밀려 나지 않도록 새로운 조직이 필요할 것이며 정치논리에 밀리지 않도록 최상위 경영층의 지원이 필요합니다.

3. 외국의 전문 SW회사를 인수합니다.
삼성 내부의 개발조직을 가지고 어떻게 잘해보기에는 이미 늦은 듯 합니다. 물론 삼성 내부에도 뛰어난 개발자들이 많이 있지만, 조직으로 놓고 보면 얘기가 달라집니다. 이런 조직에서 오랫동안 길들여진 개발자들은 대부분 제대로 된 소프트웨어 개발 조직에서 제 역할을 하는 것을 기대하기는 힘듭니다. 
그렇다고 새로운 조직을 신입 개발자들을 뽑아서 만들어가기에는 시간이 이를 허용하지 않습니다. 
따라서 외국의 뛰어난 전문 SW회사를 인수해야 합니다. 이 또한 정치 논리가 아니고 진짜 소프트웨어 회사를 제대로 평가할 수 있는 전문가 그룹에서 삼성의 미래에 도움이 되는 소프트웨어 회사를 선택해서 제대로 평가하여 인수해야 합니다.
소프트웨어 전문 경영자는 인수한 SW회사와 삼성의 가교역할을 해야 합니다.

4. 인수한 SW회사는 삼성 내부의 개발조직과는 분리를 해야 합니다.
인수한 외국의 SW회사는 삼성 내부 개발자들과는 너무나 다른 개발문화를 가지고 있습니다. 이들을 자칫 그냥 섞어 놓다가는 둘 다 망칠 수 있습니다. 따라서 삼성 내부 개발자 중에서도 철저한 평가를 통해서만 인수한 SW회사로 이동이 가능할 것입니다. 아직 삼성의 개발문화에 많이 길들여지지 않았지만, 영어를 잘하고 똑똑한 개발자들은 인수한 SW회사와 섞어서 일하는 것이 가능할 것입니다. 
이 과정을 통해서 서서히 글로벌 소프트웨어 개발 문화를 익혀나가는 것이 필요합니다. 즉, 삼성에서 직접 활약할 선임 소프트웨어 개발자들을 양성해야 합니다.

5. 독자적인 성장을 할 수 있도록 보호를 해주고 지원해야 합니다.
인수한 소프트웨어 회사에도 "조삼모사"논리로 기존의 개발문화를 깨게 되면 평범한 소프트웨어 회사가 되어 버릴 수도 있습니다. 기존의 삼성 조직에 필요한 것들은 개발자 순환을 통해서 조금씩 익혀나가고 인수한 소프트웨어 회사에서는 독자적인 사업 영역을 계속 가져갈 수 있도록 보호를 해주고 지원해야 합니다. 이런 SW회사를 여러 개 인수하여 다양한 개발 문화를 접해야 합니다. 

6. 기존 조직의 반대와 방해로부터 보호를 받아야 합니다.
이러한 과정에서 내부 조직의 반대와 방해에 부딪힐 것은 뻔합니다. 이러한 방해는 아주 작은 소프트웨어 회사들에서도 존재하는데 삼성 같은 거대 기업은 말할 필요가 없습니다. 이를 보호해줄 수 있는 사람은 삼성내의 최상위 경영층 밖에 없을 겁니다. 이렇게 5년, 10년 투자가 이루어져야 소프트웨어 분야에서도 최고라는 소리를 조금씩 듣기 시작할 수 있을 겁니다.

고민 끝에 내린 시나리오는 이렇지만, 이 시나리오의 최대 키포인트는 바로 최고 경영층의 지원일 겁니다. 현재 상황을 얼마나 심각하게 깨닫고 기존의 경영자들은 이를 해결 할 수 없다는 것을 얼마나 빨리 깨닫느냐가 관건이라고 할 수 있습니다.

대한민국 소프트웨어 개발환경은 대기업, 중소기업 가리지 않고 열악하기 그지없습니다. 특히 삼성은 우리나라 경제의 가장 큰 버팀목이기도 하지만 수많은 중소 소프트웨어 회사의 밥줄이며 동시에 목줄을 죄고 있습니다. 삼성이 잘하면 모두 상생할 수도 있지만, 잘못하면 삼성은 약간의 타격이지만, 중소 소프트웨어 회사들은 와해되기 때문에 이것이 삼성이 소프트웨어 분야에서도 잘해야 하는 제가 생각하는 가장 큰 이유입니다. 

이는 비단 삼성만의 문제는 아닙니다. 제 바램은 이런 목소리를 통해서 소프트웨어 환경이 조금씩 나아지는 길로 가는 것입니다. 

2010년 1월 23일 토요일

삼성이 바다를 출시해서는 안되는 이유

일전에 삼성이 왜 소프트웨어를 잘 개발하지 못하는지에 대한 글을 쓴적이 있습니다.

2010/01/05 - [소프트웨어이야기] - 삼성은 왜 소프트웨어를 잘 만들지 못할까?

개인적인 생각이지만 바다의 정식 출시가 임박할수록 점점 걱정스러워지고 있습니다.
일단 이글은 삼성을 비난하려고 작성한 글이 아닙니다. 삼성이 잘되어야 하는 이유를 잘 알고 있는 한 사람으로서 현재 상황에 대한 소프트웨어 공학적인 우려를 말하고자 하는 사견임을 밝혀둡니다.

일단 삼성이 왜 바다를 출시하고 싶어 했는지 그 마음은 충분히 이해를 합니다. 기존에 피처폰에서 삼성은 눈부신 성과를 거두었고, 10여년전만해도 경외의 대상이던 여러 Global 회사를 추월하고 이제 Nokia만 앞에 보이는 상황입니다. 이 과정에서 너무 큰 자신감을 가지게 된게 아닌가 생각되는 군요.

삼성의 대단한 저력과 성과는 인정합니다. 하지만 삼성이 이렇게 핸드폰 분야에서 성공한 이유를 제대로 알아야 합니다. 하드웨어 제조 능력과 탁월한 마케팅 능력이 있었던 것이지 소프트웨어를 잘 만들어서는 절대로 아니라고 봅니다. 삼성에게 자신들의 시장을 내준 Global 회사들이 소프트웨어를 제대로 만드는 능력이 삼성보다 부족해서 삼성에게 진 것이 아닐겁니다. 그런데 이런 결과가 삼성에게 소프트웨어에 대한 자신감까지 불어 넣어 준 것이 아닌가 생각이 듭니다.

기존 피처폰에서는 소프트웨어 개발 능력 부족이 사업을 성공하는데 결정적인 요소로 작용하지 않았다고 봅니다. 소프트웨어 개발력의 부족함은 인력과 자금으로 보충하고 소프트웨어 개발자들의 헌신적인 야근으로 어떤 글로벌 회사들도 불가능했던 초단기간에 새로운 모델의 핸드폰을 만들어서 출시를 해왔습니다. 이러다보니 경영층에서는 개발팀의 소프트웨어 개발 능력을 대단히 높게 과대평가 했을지도 모릅니다. 어떤 회사보다 빨리 개발을 해내기 때문에 소프트웨어를 잘 이해하지 못하는 경영자들은 착각하기 충분하다고 봅니다. 하지만 이러한 무리한 개발이 계속 되면서 소프트웨어를 잘 개발할 수 있는 역량을 닦을 기회조차 박탈당했기 때문에 현재 삼성이 가지고 있는 소프트웨어 개발 능력은 삼성의 위상에 걸맞지 않에 뒤처져 있다고 생각합니다.

삼성의 소프트웨어 개발능력은 삼성이 제쳤던 핸드폰 회사들이나 애플, 구글과는 비교도 할 수 없을만큼 떨어진다고 봅니다. 부정하고 싶겠지만 긍정적인 증거는 별로 없는 것이 현실입니다. 그동안 소프트웨어에 얼마나 투자를 해왔을까요? 소프트웨어를 잘 아는 경영자를 등용하고 믿어주고 밀어줬나요? 제가 알기로는 그렇지 않지 않습니다.

스마트폰은 기존에 삼성이 크게 성공시킨 피처폰과는 다릅니다. 피처폰 처럼 몇날 며칠 개발자들이 코피 쏟아가면서 개발하면 되는게 아닙니다. 게다가 스마트폰 OS(Platform)의 개발은 몇차원 더 높은 개발입니다. 정말 소프트웨어를 잘 만드는 회사가 아니면 제대로 만들수가 없습니다. 이런 종류의 소프트웨어를 개발할 때 가장 깊게 고려해야 하는 요소는 눈에 보이는 기능이 아닙니다. 수많은 비기능 요소가 훨씬 중요합니다. 앞으로 바다를 통해서 전세계 수많은 개발자들이 소프트웨어를 개발을 해야 합니다. 이때 발생하는 모든 요소를 고려해야 합니다. 전세계 개발자들이 삼성 개발자들처럼 밤새며 개발하게 만들 건가요? 하나의 Application을 만드는 것과는 차원이 다른 얘기입니다. 물론 고려야 했겠지만, 현재 삼성의 위상에 걸맛게 모든 사람들이 기대하는 바를 충족실킬 만큼 소프트웨어 개발 능력은 갖추고 있지 않기 때문에 출시후 겪게 수많은 문제들이 눈에 보이는 듯합니다.

능력의 한계를 알아야 합니다. 능력을 훨씬 뛰어넘는 무모한 도전은 대단한 도약 아니면 엄청난 실패를 가져옵니다. 삼성은 그동안 이러한 한계를 많이 뛰어 넘어왔습니다. 하지만 소프트웨어 분야에 있어서 만은 엄청난 실패가 기다리고 있는 듯합니다. 바다의 도전은 기존과는 다른 도전입니다. 소프트웨어에 있어서 능력이 안되는 것은 안되는 겁니다. 진정한 소프트웨어 개발역량을 갖추려면 소프트웨어 분야에 제대로 투자해서 10년은 걸릴 겁니다. 그래도 조직내의 복잡한 역학관계 때문에 어려울 겁니다.

사실 저는 바다는 출시를 포기하는 것이 삼성에 더 이익이라고 생각합니다. 일단 출시를 해 놓으면 되돌릴 수가 없습니다. 이제부터 돈은 돈대로 들어가고 욕먹을 시간일 될 것입니다. 유지보수는 끝없이 들어갈겁니다. 아기는 한번 낳으면 다시 엄마 뱃속으로 들어가라고 할 수 없습니다. 그리고 바다의 유지보수는 삼성만의 이슈가 아닙니다. 이를 기반으로 소프트웨어를 개발한 전세계 개발자들과 관련됩니다. 삐끗하면 핸드폰 하나 망치는게 아닙니다. 그 파급효과가 얼마나 큰지 지금 상상할 수 있어야 합니다.

정말 바다가 순항을 하면서 칭송을 받는 상황이 발생한다면 삼성은 나 뿐만아니라 어느 누구도 모르는 끝내주는 소프트웨어 개발팀을 수백명 양성을 해왔고 이들이 바다를 개발했다는 것인데 이런 기적같은 일이 벌어지겠습니까? 지금도 바다가 큰 성공을 거두기를 기대하고는 있지만, 그리 희망적으로 생각되지 않습니다.

차라리 안드로이드폰을 더 잘 만들기 위해 투자하는 것이 더 좋은 선택이라고 생각합니다. 사실 이것도 쉽지는 않습니다. 기존 피처폰 만드는 마인드로 또 밤세워가며 Copy & paste가 난무하는 개발을 한다면 별로 나아질 것이 없습니다. 그렇지만 바다에 투자할 막대한 노력을 현실성있는 안드로이드폰 개발에 투자를 하는 것이 좋을 겁니다. 

이미 삼성은 스마트폰 분야에서 상대적으로 뒤쳐지기 시작했다고 봅니다. 만약에 바다가 크게 실패한다면 그동안 이룩해 놓은 휴대폰 분야에서 삼성의 브랜드에 크게 타격을 줄지도 모릅니다. 

삼성은 그동안 수차례 엄청난 변화를 통해서 세계 제1의 IT회사가 되었습니다. 앞으로 한단계 더 점프를 하려면 소프트웨어 분야를 손놓고는 어렵습니다. 어렵더라도 내부에서 여러 방해에 부딛히더라도 소프트웨어에 투자를 해야 합니다. 비싼 툴 사주고 복잡한 프로세스 만드는 것이 소프트웨어에 대한 투자가 아닙니다. 애플, 구글 또는 실리콘밸리의 작은 소프트웨어 회사들이 어떻게 소프트웨어를 개발하는지 보십시오. 기존 조직에서 안된다면 소프트웨어 분야는 새로운 조직에서 새로운 경영자와 때묻지 않은 새로운 개발자들로 새로 시작해서 Global 경쟁력을 갖춘 소프트웨어 조직으로 키우는 것도 한 방법일 겁니다. 
정말 소프트웨어 분야는 잘 될 가능성이 없다면 그냥 하드웨어 분야에서 더 큰 성공을 거두는 것이 좋겠네요. 지금의 삼성처럼요. 

이미 "바다"의 출시가 기정 사실이라면 "바다"의 "순항"을 간절히 기원합니다.  

2015년 5월 5일 화요일

외국에서 팔리는 소프트웨어 만들기 위한 소프트웨어 국제화 (1)


가장 먼저 소프트웨어 국제화에 대한 이야기로 글을 시작하려고 한다.

오래 전부터 소프트웨어 세계에는 국경이 없었다. 거의 모든 사람들은 수십 나라에서 개발된 다국적 소프트웨어를 사용하고 있다. 앱을 하나 개발해서 앱스토어에 올리면 바로 다음날부터 전세계 수십, 수백 나라에서 즉시 사용된다.

이제 소프트웨어 국제화는 소프트웨어 개발자라면 필수적으로 알아야 할 지식이다. 소프트웨어 국제화 전문가가 되기 위해서는 십 수년의 공부와 경험이 필요하지만 최소한의 기본 지식은 갖추도록 하자.

기본적으로 영어권 개발자들이 만든 소프트웨어는 국제화에 대해서 별로 신경을 안 써도 큰 문제 없이 전세계에서 사용되는 경우가 많다. 우리도 영어만 지원하는 소프트웨어를 얼마나 많이 써왔던가? 비단 메시지만 영어로 나오는 것뿐만 아니라 날짜 표기, 이름 표기 등도 우리 문화와는 다르지만 소프트웨어를 사용하는 데는 큰 문제가 없다. 물론 한국어 폰트가 깨지는 등 문제가 있는 경우도 많지만 개발자들은 이런 것은 신경도 안 쓰는 경우가 많다. 우리는 소수 사용자이기 때문이다.

하지만 비 영어권 개발자들이 만든 소프트웨어는 상황이 전혀 다르다. 기본적으로 우리 문화에 맞춰서 개발한 소프트웨어는 영어권뿐만 아니라 우리나라를 제외한 대부분의 나라에서 거부감을 갖게 된다. 그만큼 우리나라 개발자들이 만든 소프트웨어가 전세계로 확산되기는 쉽지 않다. 그러다 보면 전세계 1% 시장이라는 우리나라 소프트웨어 시장만을 대상으로 소프트웨어를 만들게 된다.

100배 큰 시장으로 나가기 위해서는 소프트웨어 국제화를 잘 알아야 한다.

일단 용어부터 알아보자.

첫 번째 용어는 국제화, 영어로는 Internationalization이다. 이 용어는 1985년에 Apple에서 사용하기 시작하였다. 오랫동안 이렇게 긴 영어 단어로 사용되다가 유니코드 컨소시엄에서 i18n이라는 줄임말을 사용하기 시작했다. 사실 정확하게 누가 먼저 사용했는지는 알기 어렵다. "인터네셔널라이제이션"이라는 긴 단어를 발음하다보면 혀가 꼬이기 일쑤다. 그래서 i와 n 사이에 18글자의 알파벳이 있다는 의미로 i18n을 사용하기 시작했다.

i18n은 소프트웨어를 여러 나라 언어와 문화를 지원하기 쉬운 구조로 만드는 것이다. 국제화가 잘된 소프트웨어는 쉽게 여러 나라 언어를 지원할 수 있다. i를 소문자로 쓰는 이유는 대문자로 쓸 경우 L의 소문자와 헷갈리기 때문이다.

두 번째 용어는 지역화, 영어로는 Localization이다. 이 또한 줄여서 L10n이라고 한다. L를 흔히 대문자로 쓰는 이유도 역시 헷갈리지 않게 하기 위함이다. 

L10n은 소프트웨어를 특정 지역의 언어와 문화를 지원하도록 만드는 것이다. 예를 들면 중국어나 일본어를 지원하는 것이다.


전세계 개발자와 회사들은 1980년대부터 본격적으로 소프트웨어 국제화와 지역화에 대해서 연구를 해왔고 그 결과 1991년 유니코드가 탄생을 하였고 수많은 표준이 제정되었다. 그 지식과 정보는 너무나 방대해서 어느 개발자도 모두 알기는 어렵다. 따라서 앞으로 이 중에서 소프트웨어 개발자가 알아야 할 필수적인 내용을 연재하겠다.

이 글인 네이버포스트에 게재한 글입니다.

2013년 11월 2일 토요일

SW개발과 빨리빨리 문화의 저주(개발문화 시리즈3)

이번에 다룰 개발문화 이야기는 '빨리빨리 문화'다. 

일을 빨리 하자는게 나쁜 건 아니다. 오히려 이런 '빨리빨리 문화' 덕분에 우리나라가 짧은 기간에 성장했을지도 모른다. 더 짧은 시간에 똑 같은 일을 해낼 수 있다는 것은 경쟁력이 있는 것이다. 우리는 그동안 많은 산업분야에서 '빨리빨리 문화'의 혜택을 입었고, 관련 노하우도 많다. 

그런데, 이런 '빨리빨리 문화'가 소프트웨어 분야에서는 독이 되는 경우가 많다. 실제로 독이 되는 경우를 많이 보았다. 시제품은 빨리 만드는데 본제품을 완성하는데는 시간이 훨씬 오래 걸리며 품질도 떨어지고 시간이 흐를수록 유지보수가 무척 어려워져서 제품을 포기하는 경우도 흔하다. 상황을 수습하지 못해, 회사의 종말로 이어질 때도 있다. 

유독 왜 소프트웨어 분야에서 '빨리빨리 문화'가 문제가 되는 것일까?  원인은 세가지로 요약할 수 있다. 

첫째, 소프트웨어는 훨씬 복잡하다. 다른 분야에는 미안하지만 소프트웨어는 가장 복잡한 지식산업이다. 빨리 개발해야 한다고 열심히 코딩부터 시작해서 으쌰으쌰 개발하면 아키텍처는 뒤죽박죽 되고 개발 기간도 오래 걸린다. 그렇다고 차근차근 모든 설계서를 만들고 설계서대로 개발하면 좋겠지만 그렇게 하면 웬만한 프로젝트를 마무리는데 10년쯤 걸릴 것이다. 절묘한 절충이 가장 어렵다. 

둘째, 소프트웨어는 예술이다. 소프트웨어 아키텍처를 만들어 가는 과정은 예술과 비슷하다. 예술은 재촉한하거나 야근을 한다고 해서 빨리, 더 좋은 결과가 나오는 것은 아니다. 수많은 요구사항과 비즈니스 전략 등을 종합하여 가장 적합한 아키텍처를 만드는데 시간이 부족하면 부실한 아키텍처가 되고 개발에 들어갔거나 유지보수시 이를 바꾸려면 비용은 100배, 1000배가 더 든다. 

셋째, 소프트웨어는 생명체와 같다. 소프트웨어는 건축에서 개념을 가져온 것도 많고 실제 비슷한 것도 많다. 하지만 빌딩은 일단 완공되면 100년동안 기본 구조가 거의 안바뀌지만 소프트웨어는 보통 출시되도 계속 성장한다. 소프트웨어는 출시 후부터 초기 개발비용보다 약 4배의 돈이 더 드는 것으로 알려져 있다. 하지만 아키텍처가 부실하다면 4배가 아니라 40배의 비용을 더 들이고도 업그레이드 및 유지보수가 어려울 수 있다. 

그럼, '빨리빨리 문화'가 문제니 차근차근 천천히 개발을 해야 할까? 그건 전혀 아니다. 수많은 성공한 글로벌 소프트웨어 회사들은 천천히 개발을 해서 성공한 것이 아니다. 소프트웨어 개발의 최대 미덕은 소프트웨어를 빨리 개발하는 것이다. 소프트웨어 개발을 조금이라도 느리게 하는 모든 방법론, 규칙, 제약, 프로세스는 잘못된 것이다. 

'빨리빨리 문화'가 소프트웨어 개발을 오히려 더 느리게 하고 다른  문제들도 일으키기 때문에 문제라는 것이다. '빨리빨리 문화'는 소프트웨어 개발 프로젝트에서 다음과 같은 것들을 유발한다. 

-프로젝트 지식, 정보, 자료 공유의 부재 
-부실하고 확장성이 떨어지는 아키텍처 
-특정 개발자에게 종속됨 
-수많은 중복된 코드 
-개발자의 인간다운 삶과 성장 포기 
-점점 증가하는 유지보수 비용 

이런 현상은 개발 방법론과는 상관없이 벌어진다. SRS(Software requirements specification) 형태로 스펙을 제대로 쓰던 TDD를 하던 이는 모두 소프트웨어를 빨리 개발하기 위한 방법이다. 문서작성, 코드리뷰, 프로세스 등 모든 것은 소프트웨어를 빨리 개발하려는 것인데 이런 것들이 개발을 느리게 하니 그냥 개발하자고 하는 것은 완전히 착각이다. 

물론 이런 방법들이 소프트웨어를 빨리 개발하는데 도움이 되려면 뛰어난 아키텍트도 필요하고 회사의 개발문화 성숙도도 높아야 한다. 

빌딩을 빨리 만들겠다고 벽돌부터 서둘러 쌓아야 한다고 생각하는 사람은 없을 것이다. 기초공사와 설계가 잘되어야 어떤 방식으로든 빌딩을 빨리 만들 수 있다. 소프트웨어도 견고하고 확장성이 있는 아키텍처가 있어야 요구사항 변경에 대응이 잘되고 협업이 용이하며 개발 기간을 단축하고 비용도 절약할 수 있다. 

사실 무리한 일정 압박이 아키텍처에 큰 문제를 일으킨다는 것을 개발자 대부분은 잘 알고 있다. 그럼에도 '빨리빨리 문화'를 가속화시키는 주범은 따로 있다. 바로 경영자와 고객이다. 

대부분의 경영자에게 단기 성과는 생존 문제다. 회사 오너라면 조금 낫지만 많은 경영자들은 2년, 3년 단기 계약을 한다. 그 기간 안에 가시적인 성과를 내지 않으면 재계약이 어려워질 수 있다. 소프트웨어에 대한 깊은 이해도 부족하지만 미래를 고려할 시간은 더욱 없다. 6개월, 1년안에 성과를 내는 것이 가장 중요한 경영자는 영업이 가장 중요하고 단기 매출에 집착하며 아키텍처는 신경 쓸 여유가 없다. 

제대로 된 CTO가 있다면 CEO가 그렇게 마음대로 할 수는 없지만 우리나라에서는 CTO가 제대로 역할을 하기 어렵다. 

고객도 문제다. 우리나라 고객들은 이중적이다. 우리나라 개발사에는 버그를 당장 내일 고쳐줄 것을 요구하지만 글로벌 회사는 6개월 후에 고쳐주는 것을 고마워한다. 글로벌 회사는 아무리 얘기를 해도 빨리 고쳐주지 않는 다는 것을 알기 때문이다. 

우리나라 고객들은 개발자가 고객 회사에 들어와서 일해주기를 원한다. 스펙을 제대로 정리하고 효율적인 커뮤니케이션을 통해서 개발하는데 익숙하지 않기 때문에 옆에 앉혀놓고 종을 부리듯이 개발하기를 원한다. 

국내에서는 그런 고객의 입맛에 맞춰줘서 성공한 사례가 꽤 있다. 이런 문화는 국내 시장의 진입장벽이 되기도 한다. 그렇게 해서 우리나라에서는 1위에 등극했지만 이를 바탕으로 글로벌 시장으로 나아가는데는 큰 문제가 있다. 

개발문화가 비효율적이고 아키텍트의 역량이 떨어져서 세계 시장에서 패하는 경우가 많다. 그럼 외국 고객은 어떨까? 다는 아니지만 대부분 버그를 내일 고쳐 준다고 하면 의아하게 생각한다. 특히 매우 중요한 시스템이라면 이런 개발사의 신속한 대응은 오히려 개발사에 대한 신뢰를 떨어뜨리기도 한다. 

우리나라 개발사끼리는 이러한 고객 요구사항에 서로 잘 맞춰주겠다고 진흙탕싸움을 하고 있기 때문에 모두 다 힘들어지고 그 폐해는 고스란히 개발자에게 돌아간다. 개발자는 인간다운 삶을 포기해야 하기도 하고 그런 개발 환경에서는 개발자로서 성장하기도 힘들어진다. 

'빨리빨리 문화'가 바뀌기 어려운 것은 사실이다. 고객도, 경영자도, 개발자도 바뀌어야 한다. 내가 어떻게 세상을 바꾸겠는가? 하지만 세상을 바꾸는 첫걸음은 내가 바뀌는 것이다. 내가 바뀌는 것의 시작은 깨닫는 것이다. 지금은 당장 나만 바뀌면 나만 손해를 볼 것이다. 

하지만 내가 바뀌고 동료가 바뀌지 않으면 '빨리빨리 문화'는 영원히 바뀌지 않을 것이다. 회사에서 아키텍처의 중요성을 깨닫고 아키텍트를 키우고 영업과 개발의 균형을 유지하는데 노력하고 급하게보다는 제대로 빨리 개발하기 위한 방법들을 강구해야 한다. 

기반시스템, 방법론, 프로세스 모두 적절히 필요하다. 다른 여러가지 개발문화의 성숙도를 높여가는 것도 '빨리빨리 문화'를 고치는데 도움이 된다. 결국 우리가 바꿔 나가야 한다. 

'닭이 먼저냐 달걀이 먼저냐' 이슈와 비슷하지만 개발문화 성숙도 문제를 깨닫는 것만으로도 의미가 크다. 문화란 글이 아니라 경험을 통해서 배워야 하고 경험자에게 배워야 시행착오를 줄일 수 있다. 꾸준히 관심을 가지고 익히는 자세가 필요하다.


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

2010년 12월 14일 화요일

해외에 소프트웨어를 팔려면 이것이 꼭 필요하다.

연초에 소프트웨어의 국제화와 지역화를 언급하면서 조만간 이에 대한 글을 올리겠다고 했는데, 벌써 10개월이 지났네요. 
2010/02/11 - [소프트웨어이야기] - 애플은 한국어와 한글을 구분하지 못한다?

그래서 간단하게 정리를 해보려고 합니다.

일단 다음의 기본 용어는 알아두는 것이 좋습니다.

 i18n(internationalization) - 국제화를 말하며 i와 n사이에 18개의 알파벳이 있어서 i18n으로 줄여말합니다. 소프트웨어가 여러 언어(locale)를 지원하기 용이한 형태로 만드는 것을 말합니다. i가 소문자인 이유는 알파벳엘(l) 또는 숫자일(1)과 혼동되기 때문입니다. 

 L10n(localization) - 지역화를 말하며 l과 n사이에 10개의 알파벳이 있어서 L10n으로 줄여말합니다. 소프트웨어를 해당 지역에서 사용할 수 있도록 메시지나 기능을 해당지역에 맞춰주는 것을 말합니다.

Locale - 지역화의 단위입니다. 한국어를 공식적으로 쓰는 나라는 우리나라밖에 없어서 (북한예외) Locale과 나라를 동일시하기도 하는데 영어만 아더라도 여러나라에서 쓰고 캐나다에서는 영어와 프랑스어를 모두 쓰게 됩니다. 따라서 Locale에는 언어 정보와 지역정보가 같이 포함되어 있습니다. 제 글에서는 국가와 혼영해서 사용했으니 알아서 이해하세요.

최근의 소프트웨어들을 보면 국경은 의미가 없어진지 오래입니다. 특히 스마트폰이 폭발적으로 보급되면서 개발자들과 세계 각국의 사용자들은 더욱 가까워졌습니다.

그래서 지역화된 소프트웨어가 더욱 절실해졌습니다. 그런데 우리나라 상황을 보면 아직도 많은 소프트웨어들이 국제화와 지역화에 관심을 기울이지 않고 있습니다. 그러다보니 국내에서 성공한 제품들을 들고 해외에 진출을 하다가 국제화와 지역화의 어려움에 막혀서 좌절하곤 합니다.

 국제화, 지역화 방법은 표준을 따라야 합니다.

국제화와 지역화에대한 소프트웨어 개발의 표준(De facto)이 정립된지는 매우 오래되었지만, 국내에서는 별로 관심을 받지 못하는 것이 사실입니다. 그렇게 어렵지 않은 기술임에도 관심들이 별로 없고 관심이 있다고 하더라도 흩어져 있는 정보를 모두 모아서 하나의 그림으로 보기 어려운 상황입니다. 어렵지는 않다고 했지만 매우 복잡하기 때문에 처음에 이해하기란 쉽지 않습니다.

대부분의 소프트웨어 회사들은 국제화와 지역화 과정에서 표준적인 방법을 따르지 않고 스스로 연구한 방법을 사용하다가 큰 낭패를 보게 됩니다. 왜냐하면 국제화와 지역화에 대한 방대한 지식을 소수의 개발자가 연구해서 체계화 하기란 불가능합니다. 전세계 수백명의 개발자들이 십수년간 모여서 완성한 것을 우습게 보면 안됩니다.

그래서 스스로의 방법은 대부분 실패하게 됩니다. 

 초기부터 국제화와 지역화를 고려해야 합니다.

소프트웨어 개발 초기부터 국제화와 지역화를 신경쓰지 않다가 제품을 다 완성한 후에 나중에 반영을 하게 되면 또 엄청난 비용이 들고 그 방법이 잘못되었다면 비용을 많이 들이고도 또 실패합니다.

소프트웨어가 다른 언어를 지원해야 할 가능성이 단 1%라도 있다면 저는 국제화와 지역화를 적용하여 소프트웨어를 개발합니다. 초기부터 적용하는 것은 비용이 추가로 거의 들지 않기 때문입니다.

 소프트웨어는 하나로 만들어야 합니다.

여러개로 지역화된 소프트웨어 별로 Master가 별도로 존재한다면 이를 관리하는데 또 엄청난 비용을 지불해야 합니다. 표준적인 방법들은 대부분은 하나의 소프트웨어에서 여러개의 언어(locale)을 지원할 수 있도록 미리 준비되어 있습니다.

Locale별로 여러벌의 소프트웨어가 존재한다면 이를 관리하는 비용은 기하급수로 증가하여 혼돈의 상태를 경험하게 됩니다. 이 과정에서 수많은 오류가 발생하고 해외 진출 실패의 주요 원인이 되곤 합니다.

 메시지 번역이 지역화의 전부가 아닙니다.

흔히들 우리나라에서 성공한 제품을 가지고 해외에 진출한다고 영어버전을 만들고 일본어, 중국어 버전을 만들곤 합니다. 이때 그냥 메시지만 번역을 해서 지역화된 제품이라고 생각하곤 합니다. 하지만 이런 제품을 해외에 가지고 나갔다가는 낭패를 보기 일쑤입니다. 외국과 우리나라가 그렇게 비슷하다고 생각하면 착각입니다.

숫자만하더라도 우리나라에서는 1,234.56이라고 쓰는 것을 독일에서는 1.234,56이라고 씁니다. 즉 콤마와 소숫점을 반대로 사용합니다. 

이런식으로 언어(locale)이 고려해야 할 것은 메시지외에도 Collate, Ctype, Monetary, Numeric, Time이 있습니다. 이것들은 표준적으로 정해 놓은 것이고 비표준적인 요소는 이보다 훨씬 많습니다. 비표준적인 요소들은 제품마다 별도로 분석해야 합니다.
 메시지도 단순히 번역하는 것이 다가 아닙니다.

간단한 예로 나라마다 어순이 다르고 단수, 복수의 표현이 다릅니다.

우리나라에는 단수, 복수에 따른 차이가 거의 없지만, 영어에는 복수가 있지요. 하지만 폴란드어는 1개일때 2~4개일때, 5개 이상일 때 서로 표현이 다릅니다. 게다가 12~14개로 넘어가면 또 반복이 됩니다.

이렇듯 거의 모든 요소에서 다른 나라에서는 과연 이대로 쓰는지 의심을 해봐야 합니다. 경험도 많이 필요합니다. 그러면서 자연스럽게 문장의 표현 방법도 글로벌하게 문제가 없는 방법을 사용하게 됩니다.

또한, 번역을 했을 때 문장의 길이가 천차만별이기 때문에 UI 디자인시 문장의 길이를 충분히 길다고 생각하고 디자인을 해야 합니다.

이러한 모든 것이 습관이 되어 있다면 간단한 일이지만 초기에는 매우 귀찮은 일이 됩니다.
 유니코드는 기본입니다.

지역화된 소프트웨어를 개발하다보면 항상 부딪히는 것이 문자코드의 충돌입니다.
유니코드를 사용하지 않아도 지역화된 소프트웨어를 개발할 수 없는 것은 아니지만, 여러 군데에서 매우 귀찮은 일이 발생하게 됩니다.
따라서 유니코드를 기본으로 생각하면 복잡한 문제들이 대부분 해소가 됩니다.
기존에 ANSI 프로그램만 작성을 하다가 유니코드 프로그램을 작성하는 것이 낯설고 어려울 수 있지만 이 또한 적응이 되고 나면 그렇게 어려운 일도 아닙니다.

단, 유니코드 및 문자셋, 코드셋, 인코딩 등 복잡한 컨셉을 모두 제대로 이해하는 것은 보통 어려운 일이 아닙니다. 그렇지 않다면 개발을 하다가도 "어찌어찌 하니 우연히 되더라"하는 식의 개발이 되기도 합니다.

유니코드가 적용된 지역화된 소프트웨어를 개발하려면 갖춰야할 기본 지식이 매우 많습니다.

 꾸준히 유지보수 할 수 있는 프로세스를 만들어야 합니다.

지역화된 소프트웨어를 만들때 흔히 발생하는 문제점이 처음에 한번 개발은 어떻게든 해 냈는데, 유지보수 단계에서 상당히 곤란한 상황에 처한다는 겁니다. 한국어를 포함해서 영어, 중국어, 일본어 그러고 여러 언어를 지원하다보면 패치를 만들어가 업그레이드를 할 때 매번 새로 추가된 메시지와 삭제, 변경된 메시지를 추려서 각각의 언어로 번역을 하고 제품에 반영해서 또 테스트를 해야 하는데 그게 잘 안되고 뒤죽박죽되기 일쑤입니다. 툭하면 어떤 언어에서는 메시지가 제대로 안나오곤 합니다.
지역화 프로세스는 번역과정을 빼고는 모두 자동화를 해서 추가로 비용이 들지 않아야 합니다.

각 개발자나 회사에서 스스로 만든 지역화 방법을 사용하면 좋지 않은 결정적인 이유가 유지보수 입니다. 대부분의 개인들이 만든 지역화 방법은 유지보수까지 완벽하게 반영하지 못한 것이 대부분이기 때문입니다.
 결론

필자는 무슨 소프트웨어를 만들지간에 국제화는 무조건 생각합니다. 이미 알고 있는 마당에서 비용이 추가로 들것도 별로 없습니다.
하지만, 초기에 국제화를 생각하지 않고 나중에 영업이 잘되서 해외 진출을 한번 해보려고 하면 국제화와 지역화는 큰 걸림돌이 될 겁니다. 
이 또한 알면 무지 쉬운데 모르면 한없이 어려운 분야 중 하나입니다.
"유비무환". 미리미리 준비해서 언제든지 글로벌 소프트웨어 회사들과 경쟁할 준비를 해놓읍시다.

이번 글에는 소프트에어의 국제화와 지역화의 필요성과 개념만 정리를 했는데, 그 구체적인 방법은 너무 광범위 해서 블로그 글로 모두 적기는 어려울 것 같습니다. 하지만 기회가 되면 한가지씩 올려 볼 수는 있을 것 같습니다.

혹시 소프트웨어의 국제화와 지역화가 필요하기는 한데 어려움을 겪고 있거나 이미 스스로 방법을 만들어서 쓴맛을 본 분들이 있으면 연락해주세요. 도움이 되어 드리면 좋겠습니다. :)

2009년 11월 13일 금요일

SRS에 대한 인식의 변화

그 동안 본 블로그를 통해서 소프트웨어 개발에서 SRS(Software Requirements Specification)가 얼마나 중요한 역할을 하는지에 대해서 수 차례 역설한 적이 있습니다.

2009/08/03 - [프로젝트/요구사항분석] - 이건 기능이 아닌데
2009/07/30 - [프로젝트/요구사항분석] - 고객이 요구사항을 너무 자주 바꿔요.
2009/05/04 - [프로젝트/요구사항분석] - Track me, if you can
2009/04/22 - [프로젝트/요구사항분석] - 개발자들이 바글바글한 외딴섬에 떨어진다면
2009/02/12 - [프로젝트/요구사항분석] - 요구사항 분석의 출발점
2009/02/04 - [개발프로세스] - 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은?
2009/01/29 - [소프트웨어이야기] - Head First Software Development 리뷰
2009/01/21 - [프로젝트/요구사항분석] - UI Mock-up
2009/01/20 - [프로젝트/요구사항분석] - 샘플만 보여주세요.
2009/01/19 - [프로젝트/요구사항분석] - 그냥 쓸 수 있겠네요.
2008/11/19 - [프로젝트/요구사항분석] - SRS(Software Requirements Specification)의 중요성
2008/11/03 - [소프트웨어이야기] - 프로젝트 산출물을 프로젝트 종료 후에 만들고 있나요?
지금까지는 SRS라는 용어조차 한번도 들어본 적이 없는 소프트웨어 개발자나 관련자들이 많았었습니다. 하지만 이제는 조금씩 SRS라는 용어에 대해서 알기 시작하는 것 같습니다. 또 소프트웨어 개발에서 있어서 요구분석이 왜 중요한지에 대해서 조금씩 인식해가는 것 같습니다.

그 예로 최근에는 정부에서도 소프트웨어 기업들의 경쟁력 강화, 특히 해외 시장 진출 시 경쟁력 확보를 위해서SRS 작성을 중요한 요소로 보고 정부 지원 과제에 포함을 하고 있습니다.
이러한 과제에 평가위원으로 참석을 해보니 아직은 많은 소프트웨어 회사들이 분석능력을 제대로 갖추고 있고, SRS를 잘 쓸 수 있는 역량을 갖췄다고 보기는 어렵습니다. 하지만 제대로 된 소프트웨어를 짧은 시간에 개발하기 위해서는 분석을 제대로 하여 SRS를 작성하고 SDP를 만들어야 한다는 것을 인지한 것만으로도 큰 변화라고 볼 수 있습니다. 필요성을 인식하는 것이야 말로 변화가 가능하게 하는 원동력입니다.

다만, 문제는 분석을 잘해야 한다는 것, 즉 SRS를 잘 써야 한다는 것을 인식하고도 SRS를 잘 적는 방법을 배울 곳이 없다는 것입니다. Software 선진국에서는 수십년 간 개발자들이 SRS를 써 왔기 때문에 서로 Template는 조금씩 달라도 개발자로서 일을 하는 동안에 계속 접해 왔고, 써왔기 때문에 따로 배우고 말 것도 없이 SRS를 쓸 줄 알게 되었습니다. 물론 모든 개발자가 SRS를 다 제대로 쓸 줄 아는 것도 아니고 그럴 필요도 없지만, 소프트웨어 프로젝트를 시작할 때 누군가가 SRS를 작성하고 관련자들과 리뷰를 하는데 전혀 문제가 없습니다. 

하지만 이제 시작인 우리나라는 배울 곳도 없고, 스스로 연구하고 공부해서 작성하기에는 요구분석이라는 분야 자체가 너무 어렵습니다. 그 동안 여러 회사에서 스스로 작성했다고 하는 SRS를 분석해보면 합격점을 줄 수 있는 것은 거의 전무했다고 해도 과언이 아닙니다. 그렇다고 미국 회사에 가서 몇 년 배우고 오기도 어려운 실정입니다. 또, 국내에서는 학교나 학원에서 배울 수 있는 환경도 되지 않습니다. 그렇게 배운다고 해도 몇몇 기법만 배우고 핵심은 파악하지도 못하게 됩니다. 그 이유가 대부분의 교수나 강사가 소프트웨어 프로젝트에서 실제로 SRS를 써본적이 거의 없이 이론적으로 배운 정도이기 때문입니다. 실제 프로젝트에서 SRS를 제대로 써본 경험을 많이 가지고 있는 경험자와 같이 SRS를 써보면서 꾸준히 배워 나가는 것이 가장 적절한 방법입니다.

물론 몇몇 개발 방법론에서는 SRS를 작성하지 않습니다. 하지만 이러한 방법론에서도 스펙이 필요 없다고 하는 것은 아닙니다. 다만 스펙을 바라보는 관점과 적는 방법이 다를 뿐입니다. 따라서 스펙의 개념을 정확하게 알고 SRS를 잘 작성할 줄 아는 개발자들이라면 스펙의 형태가 테스트케이스가 되든 어떤 다른 형태가 되든 문제는 없습니다. 즉, 소프트웨어 분석역량이 문제입니다. 

분석역량의 부족은 부실한 스펙문서를 만들게 되고 이는 설계, 구현 기간에 많은 혼란과 재작업을 초래하고 출시 후에도 유지보수 비용을 크게 증가시킵니다. 그 동안 우물 안 개구리처럼 내수시장에서 소수의 개발자를 데리고 고객이 원하는 대로 뚝딱 만들어서 장사를 했는데, 소프트웨어 볼륨이 커지고 해외 시장에 진출을 하려니까 딱 벽에 부딪히는 겁니다. 이 과정에서 무리하게 해외 진출을 추진하다가 유명을 달리한 회사들이 상당히 많습니다. 그렇다고 세계 시장의 1%밖에 안되는 국내 SW시장에서만 놀기에는 국내 시장은 너무나 작습니다. 왠만큼 성장한 회사라면 해외 시장 진출의 유혹을 떨처버리기 어렵습니다.  

물론 SRS, 스펙, 분석능력이 이 모든 것을 해결해주지는 않습니다. 하지만, 가장 중요하고 핵심적인 요소라 확신합니다. 이는 저만의 주장이 아니고 제가 존경하는 수많은 실전 소프트웨어 전문가들의 주장이기도 합니다. 그러한 맥락으로 앞으로 SRS, 스펙, 분석역량 향상에 대한 글을 종종 올려보려고 합니다. 블로그를 통한 지식전달이 얼마나 효과가 있겠는지 의문은 들지만, 필요성에 대한 인식만 생기더라도 글을 올린 보람을 있을 것으로 생각됩니다.

이와 관련된 궁금증, 의견, 경험, 고민거리, 정보, 아이디어 등 어떤 것이라도 같이 교환하고 싶습니다. 댓글이나 방명록, 메일로 얼마든지 보내주세요. 제가 해결해드릴 수 있는 것은 해결해드리죠.
그리고 교육을 받고 싶으신 개발자나 회사라면 연락 주시기 바랍니다. 제가 여건이 되는 한도내에서는 많은 소프트웨어 개발자들에게 전달하고 싶습니다.

2010년 2월 9일 화요일

스마트폰 앱스토어가 진짜 대박이 아닌 이유

요즘 스마트폰이 IT 이슈의 정점에 있어서 스마트폰 관련 글을 계속 올리게 됩니다.
개발자의 한사람으로서 스마트폰의 급속한 확대는 좋은 징조임이 분명합니다. 하지만 종종 스마트폰 어플리케이션을 만들어서 앱스토어에 올리면 쉽게 대박을 맞을 수 있을 것 같은 기사들이 눈에 띕니다.


물론 거품을 경고하는 기사들이 많은 것은 사실이지만 좋은 것만 보인다고 대박 기사가 더 눈에 들어오는 것은 사실입니다. 개발자들은 "실패담은 내 이야기는 아닐거야"라고 자신에게는 관대한 판단을 내기는 것이 일반적입니다.

이런 종류의 기사들을 읽어보면 전문가들이 말을 인용하는 칼럼형식의 기사는 좀 나은데 기자들이 직접 작성하는 누구나 혼자서 쉽게 소프트웨어를 개발해서 성공할 수 있다는 식의 기사가 많습니다. 그래서 현 상황을 좀 냉정하게 바라보고자 합니다.

긍정적인 측면

확실히 앱스토어가 개발자들에게는 기회의 땅입니다. 어플리케이션을 만들기만 하면 바로 전세계 소비자와 바로 만날 수 있는 기회를 제공했습니다. 마케팅을 얼마나 잘하느냐는 다른 이슈이지만, 어마어마한 마케팅 비용을 들이지 않고도 일단 소비자와 접할 수 있다는 것은 엄청난 기회입니다. 정말 좋은 소프트웨어가 마케팅 비용이 없어서 사라지는 것을 막을 수 있습니다.

또한 스마트폰 앱 시장은 계속 커지고 있고 잠재 고객은 점점 늘어가고 있습니다. 
That's it.

부정적인 측명

기회는 균등합니다. 나에게 기회인 것은 전세계 모든 개발자들에게 동일한 기회입니다. 초창기를 제외하고는 소비자와 쉽게 자신의 어플리케이션을 보여줄 수 있는 것이 그리 매력적인 조건이 아닐 겁니다. 정말 좋은 소프트웨어가 아니면 이 장점이 큰 장점이 아닙니다. 또한 스마트폰 앱 시장이 점점 커지면서 메이저 소프트웨어 업체들이 뛰어들 준비를 하고 있습니다. 기존의 시장과 별반 다를바 없는 치열한 전투장이 될 겁니다.

시장은 그렇다 치고, 개발자 입장에서 바라보도록 하죠.

스마트폰이라고 해서 소프트웨어를 개발하기 더 쉬워진 것은 아닙니다. 잘 만들어진 Framework를 보면 개발이 더 쉬운 것처럼 착시현상을 일으키기도 하지만, 이것이 소프트웨어 개발 전체 프로세스에 미치는 영향은 5%도 되지 않습니다. OOP 컨셉이 없는 개발자들은 오히려 뒤죽박죽을 만들어 버리기 일쑤입니다. SDK를 이용한 코딩보다도 스펙을 제대로 정하고 설계를 하고 테스트를 하는게 비중이 더 높습니다. 이는 기존의 다른 소프트웨어를 개발하는 것과 별단 다르지 않습니다. 즉, 기존에 소프트웨어를 잘 개발하던 개발자나 회사가 이또한 잘 할겁니다.

스마트폰 앱이라고 해서 한번 만들고 끝나는 것이 아닙니다. 일반적으로 소프트웨어는 유지보수 비용이 개발비용의 2~5배 정도 들어간다고 합니다. 그래서 한번 만들어놓은 앱을 꾸준히 유지보수를 해야 하는데, 개인이 이를 감당하기에는 어려움이 있을 수 밖에 없습니다. 진짜 전업으로 매달려야 합니다. 또한 버그 관리, 소스관리, 스펙 관리가 그렇게 쉽지 않습니다. 기존의 소프트웨어 회사들도 크나 작으나 이들을 잘 해내지 못하는 것이 현실입니다. 그렇다고 혼자 개발을 한다고 이 이슈가 사라지지 않습니다. 진짜 혼자 다 해야 합니다.

또, 어쩌다 꽤 인기있는 앱을 만들어서 중박정도를 했다고 해도 꾸준히 매출을 유지하기 위해서 업그레이드와 새로운 제품을 계속 만들어내야 합니다. 앱 개발이 전업이 되었다는 얘기는 꾸준히 수익을 창출해야 한다는 얘기입니다. 회사라면 크나 작으나 나름 각 분야의 전문가들이 힘을 합쳐서 일하기 때문에 진짜 자신이 잘하는 분야에 집중할 수 있어서 꾸준히 발전해 나가는 것이 혼자 북치고 장구치고 하는 것보다는 유리합니다. 자칫하면 수주대토(守株待兎)가 될 수 있습니다.

소프트웨어 개발이라는 것의 대부분은 팀으로 일을 했을 때 더 잘 할 수 있는 것들인데, 혼자서 한다는 것은 한계에 부딪히게 됩니다.  아이디어의 한계, 기술의 한계가 그겁니다. 물론 혼자 일하는 것을 좋아하는 개발자들중에서는 팀웍을 이뤄서 제대로 일하는 방법을 모르기 때문인 경우도 있습니다. 어떠한 경우라도 혼자서 1인회사를 해나가는 것은 쉽지 않은 결정입니다.

이미 소프트웨어 개발에 상당한 공력을 가지고 있는 개발자 몇명을 제외하고는 아무리 좋은 아이디어로 좋은 앱을 개발했다고 하더라도 혼자 개발하는 것은 스스로의 성장에도 지장을 줄 수 있습니다. 물론 이런 시도는 도전의식과 비즈니스 경험을 쌓을 수 있어도 소프트웨어 개발자로서의 경험은 상대적으로 놓치게 됩니다. 자칫 평생 혼자 개발해야 편한 개발자가 될 수도 있습니다. 실패에서 얻는 것도 있지만 잃는 것도 크다는 것을 명심해야 합니다.

소프트웨어 개발자로서 사회에 첫발을 디뎠다면 아무리 대학때 소프트웨어를 좀 개발해 봤어도 조직에서 팀을 이뤄서 개발하는 방법과 그 문화를 어느정도 익히는 것이 필요합니다. 물론 좋은 환경의 소프트웨어 회사라야 하겠죠. 그리고 나서도 확신이 선다면 시도해볼 수 있는 도전이라고 생각은 합니다. 하지만 결코 기존의 소프트웨어 환경에 비하여 성공확률이 더 높아졌다고 생각해서는 안됩니다. 이또한 노력하는 사람에게 더 많은 기회를 제공할 겁니다. 자신의 성공확률에서 바뀐 것은 아무것도 없습니다.

이 상황을 너무 부풀려서도 너무 축소해서도 안됩니다. 확실히 기회가 생긴 것은 맞습니다. 하지만 냉철한 가슴으로 생각하고 도전해야 합니다. 또, 이를 이용해서 부추기는 선정적인 기사는 좀 줄어야 하겠습니다.