스타트업을 위한 조직론

스타트업의 젊은 경영자 중에는 관리 경험이 부족하여 조직관리에 취약한 사람이 많다. 반대로 관리 경험이 많거나 특히 조직관리가 아주 철저한 대기업 출신들은 종종 스타트업에 걸맞지 않은 부담스런 관리 기법을 적용하여 효율성을 떨어뜨리곤 한다.

그럼 스타트업은 어떤 조직관리가 적합할까?

일반 기업에 적합한 조직관리 기법은 소프트웨어 회사와 맞지 않는다. 특히 작은 조직에는 적합하지 않다. 반대로 취미생활 하듯 조직을 관리하면 평생 구멍가게를 못 벗어난다. 전혀 준비가 안된 상태에서 비즈니스가 잘되면 조직은 커지고 회사가 급속도로 비효율적으로 변하게 마련이다. 비즈니스는 잘 되는데 이런 문제로 어려워진 회사를 많이들 알고 있을 것이다.

일반적인 소프트웨어 조직도 마찬가지지만 효율적인 소프트웨어 개발을 위해서는 특히 스타트업이라면 외형적인 조직관리는 Zero에 가까워야 한다. 대신에 몇 가지 필요한 요소가 있다.

첫째 기반시스템 활용

소프트웨어 회사에 필수적인 기반 시스템 두 가지는 SCM(소스코드관리시스템)과 ITS(이슈트랙시스템 또는 버그관리시스템)이다. 추가로 Wiki를 쓰기도 한다. 일반관리를 제외한 거의 모든 관리 부담은 기반시스템이 다 흡수를 한다.

이를 통해 별도 지시, 보고서 작성, 보고에 들어가는 품을 대폭 줄일 수 있다. 잘만 활용하면 10분의 1까지 줄일 수 있다. One-man 컴퍼니라면 시스템 대신 공책이나 엑셀을 쓰기도 하는데 회사가 커지면 문제가 된다. 혼자 일해도 기반시스템을 활용하는 것이 더 효율적이다. 시스템을 구축하는 비용과 관리부담을 걱정하곤 하는데 호스팅을 이용하면 된다.

Atlassian에서는 이슈트랙시스템인 Jira를 10명까지는 한 달에 만원이면 이용할 수 있다. Git나 Murcurial을 5명까지는 무료로 10명이면 한 달에 만원으로 무제한 용량을 사용할 수 있다. Wiki도 마찬가지다. Github를 이용할 수도 있다. 여기에 관한 자세한 내용은 추후 다시 다루겠다.

회사가 웬만큼 성장할 때까지는 이런 저렴한 호스팅을 사용하는 것이 효과적이다. 추후에 Migration도 문제없다. 보안문제를 걱정하곤 하는데 이는 기우이다.

둘째 문서다.

흔히 혼자서 또는 2,3명이 개발을 하면 문서가 필요 없다고 생각한다. 이는 사실이 아니다. 문서를 잘 작성하지 못하거나 제대로 작성해본 경험이 없거나 작성하기 싫어서 대는 핑계일 뿐이다. 문서를 작성하면서 개발을 하는 것이 더 빠르고 효율적이다.

좀더 정확하게 말하면 상황에 맞게 적절하게 작성해야 한다. 스펙을 작성할 때도 정말 간단하게 적을 수도 있고 Unit test가 일부를 대신하기도 하고 설계는 종이에 해도 된다. 또한 상당부분을 기반시스템이 보완하므로 정작 필요한 문서 양은 많지 않다. 조직이 적다고 변변한 문서도 없이 개발을 한다면 그 자체로 비효율적이고 조직이 커질수록 커뮤니케이션 비용이 급속도로 늘어나고 커뮤니케이션 오류로 인한 재작업 비용이 크게 증가한다.

셋째 역할구분이다.

스타트업에서는 개발자 한 명이 많은 역할을 한다. 기본적으로 기획, 분석/설계, 구현, 테스트, 디자인(종종), 기술영업, 기술지원 등 이루 말할 수 없는 많은 일을 한다. 그렇게 준비 없이 회사가 성장하면 개발자 인원수는 몇십배로 늘었는데 하는 일을 별반 다르지 않은 경우가 허다하다. 디자인과 테스트를 분리하기도 하지만 제대로 분리가 안되고 나머지 일들은 그대로 수행하는 경우가 많다.

이유는 개발자의 역할을 정확하게 정의를 하지 못해서 발생한다. 많은 경영자들은 이 모든 일들이 개발자가 원래 해야 할 일이라고 착각한다. 이를 방지하려면 조직의 전문성에 대한 이해가 먼저 필요하다.

혼자 일을 해도 기획, 개발, 테스트를 구분해서 일해야 한다. 필요한 문서도 만들어야 한다. 혼자 일해도 그렇게 일하는 것이 더 효율적이다. 그러다가 회사가 커지면 개발자만 N배로 늘리는 것이 아니고 적절한 비율로 전문적인 역할을 분리하고 프로세스를 만들어나가면 된다. 전문적인 조직으로 분리하는 순서와 비율은 회사마다 다르지만 보통의 순서는 테스트, UI디자인, 마케팅, 기술지원, 기술영업 등이다.

혼자 일해도 역할이 잘 구분되면 부족한 부분을 외주로 돌릴 수도 있다. 한두명이 일한다고 역할을 섞어서 일하면 다른 사람이 효과적으로 도와주기도 어려워진다.

지금까지 얘기한 방식은 스타트업에도 해당하지만 일반적인 소프트웨어 회사도 별반 다르지 않다. 처음부터 이런 조직관리를 준비해야 회사가 커져도 효율성을 계속 유지할 수 있다. 일반적인 회사는 인원이 20명, 50명, 100명, 300명을 넘어갈 때 큰 위기를 한번씩 맞는다.

관리 패러다임이 바뀌고 이때마다 여러 가지 관리기법을 추가한다. 이러한 방법은 소프트웨어 회사에는 잘 적용되지 않는다. 오히려 일반적인 회사의 관리 패러다임을 소프트웨어 회사에 적용하면 효율이 더 떨어진다. 소프트웨어 회사에는 소프트웨어 회사에 알맞은 관리가 필요하다.

이글은 Tech it에 기고한 글입니다.

생각은 쉽게 바뀌지 않는다.

많은 회사에서 경영자, 개발자들이 소프웨어를 좀더 효과적으로 개발하기 위해서 다양한 시도를 한다.

문서를 작성하고 소스코드를 관리하고 이슈를 관리하고 프로젝트 관리 기법을 도입한다. 이런 외형적인 시도를 해도 생각은 쉽게 바뀌지 않는다. 특히 경영자들의 마인드가 잘 바뀌지 않는다. 소프트웨어 개발을 제대로 이해하지 못했기 때문이다.

실리콘 밸리와 우리나라에서 소프트웨어를 개발할 때 가장 큰 차이를 보이는 것이 있다.

스펙을 바꾸는 것이 얼마나 큰 일인지에 대한 생각이다. 실리콘밸리에서는 스펙을 바꾸는 일이 개발팀에 엄청나게 큰 부담을 주고 일정과 비용이 영향을 주는지 경영진을 비롯한 모든 직원들이 알고 있기 때문에 스펙을 쉽게 바꾸려고 하지 않는다. 그렇기 때문에 스펙을 작성할 때 철저히 리뷰를 한다. 리뷰를 소홀히 하다가 나중에 빠진 거나 잘못된 것을 바꾸기가 쉽지 않기 때문이다. 그래서 스펙이 제대로 적히고 잘 검토가 되고 프로젝트에서 매우 중요한 역할을 한다.

그런데 우리나라에서는 스펙을 바꾸는 것이 얼마나 큰일인지 잘 인식하지 못한다. 경영자뿐만 아니라 개발자도 그런 경우가 많다. 어차피 주먹구구식으로 개발하기 때문에 스펙 변경을 대수롭지 않게 생각하거나 자포자기식 개발자도 많다. 그래서 스펙을 작성하기 않기도 하거나 대충 작성하다 마는 경우가 많다.

교육을 하고 설득을 하고 귀가 아프도록 얘기를 해도 피부로 느끼기 전에는 생각이 잘 바뀌지 않는다. 이는 방법론에 따라서 다른 얘기는 아니다. 이미 스펙이 결정된 후에는 어떠한 방법론에서도 스펙 변경은 큰 일이다. 

물론 스펙 변경이 불가능한 것이 아니다. 비용 증가를 감수하고도 변경해야 할 이유가 있으면 합리적이고 적절한 절치를 통해서 변경해야 한다.

보통의 경영진은 프로젝트 진행 도중에 이런 저런 요구를 하고 싶게 마련이다. 프로젝트에 관여해서 영향력을 행사하고 싶은 욕구가 있는 경우도 있다. 이럴 때 요구사항을 잘 받아주는 개발자가 우리나라에서는 더 높은 평가를 받곤하지만 회사 전체적으로는 손해가 되는 일이다. 정말 급한 요구사항이 아니라면 다음 버전으로 미루면 되는 일이다. 

소프트웨어 개발에서 스펙을 함부로 바꾸면 안된다는 것만 깨달으면 소프트웨어 공학의 80%는 터득한 것이다. 거의 대부분의 다른 문화는 다 여기서 파생된다. 안타까운 것은 외워서 되는 것이 아니라는 것이다.

스타트업과 궁합이 맞는 개발자

소프트웨어 스타트업의 두 가지 필수 요소를 꼽으라면 좋은 아이디어와 뛰어난 개발자이다.

개발자가 스스로 창업을 하기도 하지만 좋은 아이디어를 가지고 개발자 파트너를 물색하기도 하고 본인이 개발자라고 하더라도 추가로 개발자 파트너를 찾기도 한다. 좋은 개발자는 스타트업의 성공의 중요한 열쇠이지만 구하기 쉽지 않다. 또한, 어떠한 개발자가 스타트업에 꼭 필요한 개발자인지 판단하기 어렵다. 실력이 뛰어나 보이지만 막상 일을 그르치는 개발자도 있다.

만약 스타트업을 위해서 개발자 파트너를 찾고 있다면 어떤 조건이 필요한지 알아보자. 물론 일반적인 소프트웨어 회사에서 개발자를 선택하는 방법과 같은 조건도 있지만 사뭇 다른 요소도 있다.

1.특정 분야 유경험자?

개발자 채용이나 파트너 선택에서 흔히 하는 실수 중 하나가 특정 분야 유경험자의 가치를 너무 높게 보는 것이다.

물론 해당 분야의 경험이 풍부하다면 바로 실무에 투입되어서 일할 수 있는 장점이 있다. 스타트업이 아니고 이미 성숙된 회사라면 대부분 기존 제품 개발과정에서 변변한 기록도 없고 뒤죽박죽이라서 해당 분야에 경험이 풍부한 사람이 아니면 제대로 일할 수 없는 경우가 대부분이다. 그렇지 않은 경우도 있지만 드물다. 또한 개발자들이 많이 들어왔다 나갔다 하므로 무조건 당장 써먹을 수 있는 개발자를 선호한다.

하지만 스타트업이라면 얘기가 좀 다르다. 우선, 개발자 파트너를 특정 분야 유경험자로 한정 지으면 범위가 너무 좁아진다. 소프트웨어에는 수천 가지의 Domain이 있는데 그렇게 범위를 좁히면 좋은 개발자를 구하기 힘들어진다.

오랜 기간 한 분야에만 종사하고 있는 개발자들 중에는 의외로 소프트웨어 개발 능력은 형편 없는 경우가 매우 많다. 대신 Domain 지식만 풍부해서 해당 분야에서 조금만 벗어나도 별 쓸모가 없어지곤 한다. 특히 스타트업은 아직 개발해야 할 분야가 고정 되지 않았기 때문에 특정 분야 유경험자만 찾다가는 골치덩어리 개발자를 떠안게 될지도 모른다.

특정 분야 유경험자보다는 무조건 뛰어난 개발자를 골라야 한다. 분석, 설계, 구현 능력이 뛰어난 개발자가 분야가 바뀌어도 빠른 시간 내에 실력을 발휘할 수 있다. 처음에는 유경험자보다 약간 느릴 수 있지만 역전되는 것은 순식간이다.

실리콘밸리를 보더라도 개발자들이 특정 분야에 국한하지 않고 어떠한 소프트웨어 회사라도 마음대로 옮겨 다닐 수 있는 이유이다.

실리콘밸리에서 개발자를 채용할 때 특정 분야 유경험자보다는 문제 해결 능력이 뛰어난 개발자를 뽑는 것이 그 이유이다. 심지어는 사용하고 있는 개발 언어의 경험을 보지 않는 경우도 있다.

물론, 특정 분야 유경험자가 꼭 필요한 분야도 있기는 하지만 이는 일반적인 케이스가 아니므로 여기서는 언급하지 않는다.

2. 경험이 많은 개발자?

흔히 경험이 많은 개발자가 실력이 뛰어날 것으로 생각하는데 우리나라에서는 통하지 않는다. 물론 경험 많은 개발자 중에서 뛰어난 개발자가 꽤 있는 것은 사실이지만 기대하고 있는 것만큼 많지가 않다.

그 이유는 우리나라 개발 환경이라는 것이 막노동판과 비슷해서 초급 때 벽돌 100장 쌓던 사람이 고참이 되면 200장 쌓을 수 있는 식이다. 공사판 10년 경험이면 멋진 빌딩을 설계할 수 있을 것으로 기대하는 것과는 거리가 멀다. 제대로 된 분석, 설계 경험이 부족하고 개발문화라는 것이 너무 척박해서 오랫동안 개발을 한다고 해서 실력이 많이 향상되지 않는다. 단지, 숙달되고 능숙해지며 해당 분야의 지식이 주로 쌓인다. 여전히 분석, 설계 역량은 미천하고 개발문화는 잘 모르는 경우가 허다하다.

스타트업에는 차리라 경험이 적더라도 두뇌가 뛰어난 개발자가 필요하다. 경험이 너무 많은 것보다 경험은 적당하지만 머리가 좋은 개발자가 다양한 도전에서 뛰어난 결과물을 만들어낸다.

또한 경험이 너무 많으면 수많은 잘못된 문화와 관행에 너무 젖어서 스타트업에서 필요한 혁신을 해내지 못한다. 정말 뛰어난 두뇌를 가지고 있다면 경력이 1,2년이라도 전혀 문제가 되지 않는다. 기존 조직의 개발 문화에서는 별로 배울 것이 없기 때문이다. 기존 환경에서 배운 것이 적은 개발자들이 새로운 스타트업에서 더 좋은 개발문화를 정착할 가능성이 더 높다. 기존에 잘못된 관행에 젖어 있는 수많은 개발자들은 이를 부정하고 화를 낼 수도 있지만 그것이 곧 반증이다.

3. 빨리 개발하는 개발자?

스타트업은 다양한 시도와 빠른 전략이 매우 필요하다. 그래서 빨리 개발을 하는 개발자를 선호하지만 빨리 개발하는 개발자보다는 확실하게 마무리를 잘 해내는 개발자가 더 필요하다. 이는 개발자의 성향과 관련이 있다.

어떤 개발자는 첫 번째 프로토타입은 매우 빨리 만들어내지만 마무리를 제대로 못하는 개발자가 있고 약간은 느려 보이지만 착실하게 개발을 해서 꼼꼼하게 마무리를 하여 제품을 제대로 만들어 내는 개발자가 있다. 이러한 성향은 쉽게 바뀌는 것이 아니므로 일당백을 해야 하는 스타트업에서는 확실하게 마무리를 잘하는 개발자가 더 필요하다. 그렇게 개발하는 것이 최종적으로는 더 빠르다.

같이 일을 해본 경험이 있다면 이러한 개발자를 가려낼 수 있을 것이다.

4. 개성이 강한 개발자?

스타트업에서는 개발자의 실력보다 더 필요한 것이 과연 얼마나 뜻을 하나로 모아서 나아갈 수 있는가 이다. 이 또한 개발자의 성향과 관련이 있다. 회사의 정책이나 비전에 적극적으로 따르는 개발자가 있는가 하면 부정적이고 따로 행동하는 개발자가 있다. 회사의 정책과 비전을 따르지 않는 개발자는 실력이 아무리 뛰어나도 스타트업의 파트너로는 적당하지 않다. 실력만 보고 동참을 시켰다가 두고두고 고생을 하게 될 것이다.

개발자 하나하나가 영향력이 매우 큰 스타트업에서는 특히 중요한 조건이다.

5. 개인 시간이 소중해?

스타트업에서 꼭 필요한 것 중 하나가 멤버들의 헌신이다. 일반 회사에서 항상 야근을 강요하는 그런 헌신이 아니다. 회사에 시간과 노력과 위험부담을 같이 투자한 파트너들로서 미래의 결실을 공유하고자 하는 것이므로 헌신은 매우 필요하다. 따라서 헌신할 수 없는 개발자는 고려하지 않는 것이 좋다.

나이, 가정, 주변 환경이 헌신을 가로막는 경우도 고려를 해야 한다. 가장 중요한 것은 정신적으로 얼마나 헌신을 할 자세가 되어 있는가 이다. 이는 하루 아침에 판단할 수는 없고 스타트업의 중요한 개발자 파트너 구하기 위한 것이라면 꾸준히 관찰을 해야 알 수 있는 요소이다.

아이디어가 스타트업의 중요 요소이듯이 좋은 개발자도 꼭 필요한데 겉모습만 보고 대충 채용을 했다가는 차라리 시작을 안 하느니만 못한 경우가 많다. 몇 년 후에 창업을 생각하고 있다면 주변의 개발자 중에서 위 다섯 가지 조건이 맞는 개발자를 꾸준히 물색해둬야 한다. 그리고 친하게 지내라. 그 중에 한 두명이 당신의 스타트업 파트너가 될 것이다.

이 글은  Tech it에 기고한 글입니다.

스타트업의 착각들

필자는 많은 스타트업을 만날 기회가 있고 가끔은 스타트업 파운더가 우리 회사를 찾아와서 도움을 요청하기도 한다. 처음 만나면 먼저 회사의 전략이 무엇인지 물어보는데 여러가지 일이 벌어진다.

대부분은 파운더들이 자신들의 전략을 제대로 설명하지 못한다. 한참을 들어도 무슨 말인지 잘 이해가 안 되는 경우가 많고 이해가 살짝 되도 “이거 되겠는데”라는 생각이 바로 안 든다. 이런 경우는 제대로 된 전략이 없거나 좋은 전략이 있는데 설명을 잘 못하는 경우이다. 두 가지 다 문제이기는 마찬가지다.

자신의 분야에서만 통용되는 전문용어를 섞어가면서 기승전결 없이 마구 설명하면 대부분의 사람들이 이해하지 못하고 호응을 끌어낼 수 없다. 회사의 전략을 제대로 설득할 수 있는 것은 매우 중요하다. 이 통해 투자를 유치하고 파트너와 비즈니스를 도모한다. 직원을 뽑을 때도 회사의 전략과 비전을 보여주고 뽑는다.

“30초 엘리베이터 스피치”라는 것이 있다.

엘리베이터를 타고 사무실에 올라 가면서 30초 동안 사장에게 자신의 제안 내용을 설명해서 OK를 얻어내는 것이다. 그러기 위해서는 장황하게 설명해서는 안 된다. 30초 동안 핵심 내용을 간결하게 사장님이 알 수 있는 용어로 설득력 있게 설명하는 것이 “30초 엘리베이터 스피치”다.

회사의 전략은 “30초 엘리베이터 스피치”와 같이 설명할 수 있어야 한다. 스타트업이라면 모든 직원이 자기 회사의 전략을 제대로 설명할 수 있어야 한다. 지금 당장 친구에게 전략을 설명해보자. “오! 이거 끝내주는데”라는 반응이 오나 보자. 그렇지 않다면 전략이 신통치 않거나 설명을 제대로 못한 것이다.

그럼 본론으로 돌아와서 스타트업들이 가지고 있는 착각에는 무엇이 있는지 알아보자.

1. 세계 최초

많은 스타트업들은 자신들이 세계 최초라고 주장하고 그렇게 믿고 있다. 우리나라에서는 세계 최초라는 말을 너무 많이 들어서 이제는 식상할 정도이다. 세계 최초가 매우 중요한 경우도 있지만 대부분은 중요하지 않다. 세계 최초보다는 고객이 원하는 것을 주는 것이 더 중요하다. 성공한 대부분의 스타트업들은 세계 최초가 아님에도 크게 성공을 했다.

세계 최초라고 주장을 할 때 사실은 세계 최초가 아니거나 세계 최초라고 해도 별 의미가 없는 경우가 99%이다.

첫 번째 경우는 세계 최초가 아니고 “내가 생각하기에는 세계 최초”이다. 전세계에서 무슨 일이 벌어지는 다 알 수 없기 때문에 우물 안에서 세계 최초인 것이다. 둘째 세계 최초라고 해도 고객이 원하지 않거나 별로 가치가 없는 경우에는 적당한 비즈니스 전략이 아니다.

세계 최초를 쫓을 것이 아니라 들으면 무릎을 딱 치게 만드는 고객이 필요를 충족시켜 주는 전략이 되어야 한다.

2. 아무나 못 만든다.

우리 소프트웨어는 워낙 기술이 어려워서 다른 회사는 흉내내지 못하다고 말하는 경우를 종종 본다. 이런 경우 경영자가 개발자들에게 속고 있는 경우가 많다. 진짜 어려운 기술인 경우는 그리 많지 않다.

스타트업이 접근하기 쉬운 전략은 정말 어려운 기술이 아니라 대기업은 손대기 힘든 작은 시장이다. 요즘은 조금 바뀌었지만 Global 기업이나 대기업들은 메이저 시장이 아니면 웬만하면 뛰어들지 않는다. 그런 니치마켓에는 스타트업이 아이디어를 가지고 공략할 수 있는 타깃이 많이 있고, 지역별로 특수한 시장을 공략하는 것도 좋은 전략이다. 이미 성장한 메이저 시장은 큰 자본이 아니면 공략하기 어렵다.

스타트업이 니치마켓이라고 공략한 시장이 전세계를 주도하는 커다란 시장으로 성장하는 사례를 우리는 많이 봐왔다. 스타트업이라면 틈새를 잘 노려야 한다.

두 가지를 합쳐서 좋은 전략도 있다. 기술은 적당히 어려운데 시장이 작아서 메이저 업체들이 뛰어들지 않은 경우 경쟁대상 업체들 중에는 독보적인 기술을 보유할 수는 있다. 이것은 매우 좋은 전략 중 하나이지만 시장이 성장하면 메이저 업체들의 먹이가 될 수 있으므로 항상 대비를 해야 한다.

3. 우리 개발자들은 실력이 세계 최고

자신감은 좋지만 자만심은 금물이다. 흔히 실리콘밸리 개발자보다 우리나라 개발자들이 실력은 더 뛰어나다는 주장을 하곤 한다. 하지만 이는 내가 아는 한 사실이 아니다. 우리나라 개발자들이 못한다는 것이 아니고 각 개인차일 뿐이고 어디나 잘하는 개발자가 있고 못하는 개발자들이 있다. 실리콘밸리에 뛰어난 개발자가 더 많을 가능성이 더 높기는 하다. 왜냐하면 소프트웨어 개발자는 미국에서 최고의 직업 중 하나이기 때문에 최고의 두뇌들이 선택하는 전공과 직업이다.

또한 좋은 소프트웨어 개발문화가 자리 잡고 있어서 그 속에서는 개발자가 더 잘 성장할 수 있다. 초급개발자끼리 비교하는 것은 승산이 있어도 10년, 20년 이상 경력의 개발자를 비교하면 우리가 밀릴 가능성이 매우 높다. 실제로 내가 만나본 실리콘밸리 개발자들은 분석, 설계, 코딩 능력에서 압도적인 능력을 가지고 있었다. 우리나라 개발자들도 뛰어난 개발자들이 많지만 고개를 갸우뚱하게 만드는 고참개발자도 매우 많다.

스타트업에는 우수한 개발자가 필요는 하다. 한 사람이 일당백의 역할을 해야 하기 때문이다. 그렇다고 전국구의 최고의 개발자가 꼭 필요한 것은 아니다. 고객이 원하는 것을 잘 만들어내고 마무리를 잘 할 수 있는 실력과 경험이 있으면 된다. 천재가 아니면 만들 수 없는 소프트웨어는 그리 많지 않다. 또한 회사가 성장하면 뛰어난 개발자 소수와 대부분의 괜찮은 개발자로 개발팀을 꾸리면 된다.

핵심은 천재는 아닌 개발자들과 함께 좋은 전략과 기획, 그리고 잘 쓰여진 스펙과 설계를 가지고 잘 개발할 수 있는 문화 및 프로세스를 자리잡게 하는 것이다.

4. 남들은 운이 좋아서 성공했다.

스타트업으로 시작해서 현재 Global하게 성공한 회사들을 보면 왠지 대부분 운이 좋았던 것 같다. 정말 운이 좋아서 성공할 가능성보다 잘했는데 운이 나빠서 실패할 가능성이 훨씬 높다. 아이디어, 전략, 기술력 모두 뛰어나지만 억세게 재수가 없어서 IMF를 만나서 실패하거나 Global 회사의 무료 공개 전략으로 시장 자체가 사라져 버려서 망하는 경우가 종종 있다. 중견기업 이상이 되면 이를 버틸 체력이 있지만 스트타업은 한번에 쓰러지기도 한다. 이런 천재지변은 어쩔 수 없다.

반대로 별것 없는데 지독하게 운이 좋아서 성공한 것이라고 생각했는데 그 속을 보면 대단한 노력과 실력이 있는 경우가 많다. 얼마 전 싸이(Psy)가 인터뷰에서 어떤 철학자가 말하길 “노력이 기회를 만나면 운”이라고 했다. 거의 대부분은 성공 뒤에는 노력이 있다. 스타트업은 앉아서 기회를 기다리는 것이 아니고 끊임 없이 기회를 찾아서 자신의 운으로 만나는 노력을 해야 한다.

그러기 위해서 빨리 실패를 인정하고 창의적으로 새로운 것을 받아들이고 기회를 옅보는 전략이 필요하다.

스타트업들은 번뜩이는 아이디어 또는 뛰어난 기술을 가진 대신 전략이 빈약한 경우가 매우 많다. 실리콘밸리만 하더라도 들으면 환상적인 아이디어와 뛰어난 전략의 수많은 기획서가 투자자들의 투자를 기다리고 있다. 하나하나 다 성공할 것 같은 기가 막힌 아이디어이고 전략인데 이중에 95%가 3년 안에 망한다고 한다. 스타트업의 전략을 딱 들으면 주머니에서 돈을 꺼내서 투자할 수 있을 정도로 기가 막히지 않으면 전략을 바꾸거나 전략을 설명하는 방법을 가다듬어야 한다. 그러고 나서야 5%의 터널에 진입할 준비가 된 것이다.

이글은 Tech it에 기고한 글입니다.

소프트웨어 개발시 일을 작게 쪼개야 하는 이유

대부분의 소프트웨어는 수명에서 수백명, 많게는 수천명이 같이 개발한다. 그래서 효과적으로 일을 나눠서 개발할 수 있어야 한다. 심지어는 혼자서 개발을 할 때도 일을 쪼개야 한다. 

왜 일은 쪼개야 하고 어떻게 쪼개야 하는것일까? 대부분의 다른 산업 분야는 일을 잘 쪼깬다. 시계하나를 개발해도 각 부품을 따로 개발해서 조립한다. 따로 개발하기 전에 이미 어떻게 연결이 되는지 인터페이스를 완벽하게 정의하고 개발한다. 그렇지 않으며 나중에 조립이 안되서 처음부터 다시 개발해야 할 수도 있다.

소프트웨어 프로젝트에서 일을 서로 어떻게 나눠서 개발을 하고 있는지 생각해보자. 

흔히 사용하는 방법이 화면 단위로 일을 나누는 것이다. 이 방법은 일을 나누기는 쉬워보이지만 문제가 많다. 나눠서 한 일이 서로 통합이 잘 안되고, 서로 중복된 개발도 많이 하게 된다. 다 개발해 놓고 서로 맞추는데 많은 시간을 소모하곤 한다.

일을 효과적으로 쪼개는 방법은 프로그램을 컴포넌트 단위로 잘 쪼개는 것이다. 컴포넌트는 특정 일을 담당하는 모듈로서 Class일 수도 있고, Class의 집합일 수도 있고, 함수의 집합일 수도 있다. 형태는 별로 중요하지 않다. 중요한 것은 컴포넌트의 외부 인터페이스가 간단하고 명료하게 잘 정의가 되면 되는 것이다.

분석/설계 과정에서 컴포넌트의 인터페이스가 잘 정의되면 많은 개발자들이 일을 나눠서 할 수 있게 된다. 10명이 개발을 하다가 시간이 부족하여 5명을 추가로 더 투입해도 큰 문제없이 개발이 가능하다.

서로 의존성이 있는 모듈들을 동시에 개발할 수 있게 된다. 특정 컴포넌트의 개발이 완료되어야 동작하는 모듈도 인터페이스가 확정되어 있으면 미리 개발을 할 수 있다. 개발 기간이 단축되는 것이다. 물론 모든 모듈이 다 개발되어야 테스트가 가능하지만 구현은 미리 해 놓을 수 있다.

또, 일부 모듈은 외주를 주는 것도 가능해진다.

이렇게 소프트웨어를 컴포넌트로 잘 나누게 되면 그 과정에서 문서화가 되고 서로 리뷰를 통해서 문제점을 발견하고 가장 뛰어난 아키텍처를 만들 수 있다. 또한 작업의 단위가 작아야 일정을 충분히 예측할 수 있다.

코딩을 시작하기 전에 이미 문서를 통해서 검증이 되고 공유가 된다. 그래야 변경이 최소화되고 가장 빠르게 소프트웨어를 개발할 수 있다.

분석 과정에서 부터 이미 주요 컴포넌트를 나누는 작업이 시작되고 외부 인터페이스를 정의하게 된다. 설계의 정도는 프로젝트마다 매우 다르지만 컴포넌트를 좀더 작게 나누고 function prototype까지 정의를 하면 설계가 완성된다. 간단한 프로젝트인 경우에는 스펙에서 정의한 컴포넌트와 인터페이스만 가지고 별도의 자세한 설계 없이 구현이 가능하다.

이렇게 일을 쪼개는 이유는 소프트웨어를 가장 빨리 개발하기 위한 것이다. 그렇지 않고 그냥 대충 일을 나눠서 서로 뭉쳐서 긴밀하게 의논해가면서 개발을 하는 것이 더 빨라 보인다고 생각하는 사람들이 매우 많다. 이 방법은 초기에 빠른 결과물을 보여주어서 초반에는 빨라 보이지만 결국 통합에서 지연되고 많은 재작업으로 시간을 소비하고 버그를 더 많이 만들어내어서 또 지연된다.

당장 코딩부터 시작하기 보다 생각을 더 많이 해서 컴포넌트를 잘 나눠 일을 쪼개서 재작업을 최소화하고 한번에 구현을 해 내는 것이 소프트웨어를 개발하는 가장 빠른 방법이다.

성공하는 스타트업 파운더의 DNA

요즘 하루를 애니팡 하트를 받는 것으로 시작한다. 조용했던 내 카카오톡은 애니팡 하트를 받는 메시지로 가득 찼다. 최근에 가장 Hot한 게임이 애니팡이고 많은 사람들이 그 성공 스토리에 관심을 가지고 있다. 그러면서 자신도 그런 성공을 할 수 있을까 생각을 하기도 한다.

마크주커버그는 19살에 Facebook을 설립했고, 빌게이츠도 20살에 마이크로소프트를 만들었다. 스티브잡스는 21살에 Apple사를 설립했다. 레리페이지가 Google을 만들었을 때의 나이가 25살이다. 이런 얘기를 들으면 어린 나이에도 좋은 아이디어가 있으면 성공할 수 있을 것도 같은 생각을 들게 한다. 애니팡을 만든 선데이토즈도 20대 후반에 친구 3명이 시작하였다.

미국에서도 모두 성공할 것 같아서 시작한 스타트업의 95%~99%가 3년 안에 문을 닫는다. 실패를 해도 다시 도전을 하면 되기는 하지만 이런 낮은 성공률이 우리를 주저하게 만드는 가장 큰 요소이다.

그럼 스타트업의 성공한 파운더가 되기 위해서는 어떠한 조건들을 갖춰야 할까? 물론 누구도 확실한 성공 조건을 제시할 수 없다. 또한 운이 중요한 요소로 작용하기도 한다. 따라서 아래 조건과 일치를 했다고 성공이 보장되는 것은 절대로 아니다. 반대로 아래 내용과 많은 부분들이 일치하지 않거나 반대라면 스타트업의 파운더가 되기에는 부적합하다고 생각해볼 수는 있다. 사견이니 참고만 하기 바란다.

뛰어난 관찰력과 통찰력

많은 성공한 스타트업 파운더들은 세상에 새로운 기술이 나왔을 때 남들보다 먼저 그 가능성을 알아보고 행동에 옮겼다. 해당 기술의 폭발적인 성장 후에는 누구나 알지만 남들보다 먼저 알아챈 것이다. 소셜게임의 가능성을 먼저 알아챈 Zynga나 선데이토즈가 그렇다. 인터넷, 스마트폰 등 새로운 혁신 기술이 나올 때마다 이를 먼저 알아본 스타트업의 파운더들이 있었고 상당수는 성공했다.

신기술뿐만 아니라 기존 기술의 불편한 점도 가볍게 보지 않는 관찰력도 좋은 자세 중 하나다. 주변에서 쉽게 보는 것들에서 문제점을 찾거나 엉뚱한 발상을 해서 회사의 핵심 아이템으로 키운 경우가 적지 않다. 꼭 최초일 필요도 없다. 남들이 해 놓은 것에서 개선점을 찾거나 더 재미있게 만드는 방식으로도 얼마든지 가능성이 있다.

결단력과 실행력

많은 사람들이 기회를 알아차린다. 세상에 World Wide Web이 출연하고 스마트폰이 나왔을 때 대단한 물건임을 알아차린 사람은 엄청나게 많지만 기존의 자리를 박차고 나와서 스타트업을 시작한 사람은 극소수에 불과하다. 무모함은 경계를 해야 하지만 마음만 먹고 실행하지 않으면 아무 것도 되지 않는다. 아무리 철저히 준비해도 완벽한 준비는 없기 때문에 적당한 준비와 결단력이 필요하다. 많은 스타트업의 파운더들은 그들의 유전자에 결단력이 들어 있는 것 같다.

일을 즐긴다.

내가 만나본 파운더들은 소프트웨어 개발 자체를 매우 즐겁게 생각하고 그래서 더욱 즐겁게 일하려고 자신만의 일을 시작한 경우가 많았다. 사실 소프트웨어 개발은 즐거운 일이고 일을 즐기는 것이 무한한 열정의 원동력이 된다. 아무리 돈이 되는 아이템이 있다고 하더라도 즐겁게 일할 수 없다면 이를 이끄는 힘이 약해진다. 게임, 음악 등 자신이 좋아하는 분야에서 많은 경험을 쌓고 동일 분야로 창업하여 성공한 파운더들이 많다.

좋은 파트너

스타트업을 혼자 시작할 수 있을까? 물론 가능하다. 하지만 회사를 운영하는 모든 중압감을 혼자 짊어져야 한다. 또한 개발과 비즈니스를 혼자 감당해야 하는데 쉽지 않다. 한 사람의 생각은 오류에 빠지기도 쉽다. 혼자 창업을 하게 될 경우 적은 부담감으로 쉽게 포기할 가능성도 높아진다.

스타트업의 적당한 시작 인원은 2~3명으로 생각된다. 실제 많은 성공한 스타트업이 그러했다. 대부분은 개발자들끼리 시작하거나 비즈니스를 담당하는 사람이 한 명 포함되는 경우가 일반적이다. 스타트업은 초기에는 개발이 그만큼 중요하기 때문이다. 스타트업을 시작하고자 마음을 먹은 사람들은 좋은 아이디어를 생각하는 것도 중요하지만 좋은 파트너를 찾는 일이 가장 중요하다고 할 수 있다.

적절한 경험

분야마다 필요한 경험의 기간은 다르다. 해당 분야의 기술을 섭렵할 정도의 기간이 짧게는 3년에서 길게는 10년이 될 수도 있다. 스타트업을 시작하면 한 두 명이 회사 전체의 일을 다 해야 한다. 그래서 경험이 너무 적다면 문제가 될 수도 있다. 반대로 너무 많은 경험을 쌓게 되면 나이도 많아지고 가진 것이 많아져서 쉽게 모험을 하지 못한다. 또한 기존의 시스템에 익숙해져서 아이디어가 적어지고 변화가 쉽지 않다. 너무 많은 경험을 가진 것보다 딱 필요한 만큼만 적당히 경험을 하는 것이 좋다.

헌신할 수 있는 체력

부수적인 요소이기는 하지만 나이가 너무 많거나 헌신할 수 있는 체력이 없다면 문제가 될 수도 있다. 따라서 스타트업을 시작할 거라면 체력이 소진되기 전에 시작하는 것이 어떨까? 아무리 체력 관리를 잘해도 나이에 따른 체력저하는 거스를 수 없는 자연의 섭리인가보다.

실패를 빨리 인정하는 자세

스타트업이 첫 번째 전략에서 바로 성공한 경우는 매우 드물다. 성공한 스타트업의 파운더들은 크고 작은 실패를 빠르게 인정하고 끊임없이 변화를 해 온 경우가 많다. 스타트업은 수많은 크고 작은 실패를 하는 것이 당연하다. 문제는 얼마나 빨리 실패를 알아차리고 전략을 변경하는가에 달려 있다. 자신의 실수와 실패를 쉽게 인정하지 않거나 고집이 센 경우 이미 비용을 너무 많이 치러서 회복하기 어려운 상황에 빠지는 경우가 매우 많다. 대기업은 이런 실패들에도 끄떡없지만 스타트업은 한번에 무너지기도 한다.

글로벌 마인드

이 부분은 아쉬움이 크다. 처음부터 로컬 전략이라면 상관이 없지만 글로벌 시장을 지향하면서도 국내의 많은 스타트업이 국내를 벗어나지 못했다. 즉 전세계 시장의 1~2%에 불과한 시장에서 경쟁하는 경우가 대부분이다. 마음을 먹는다고 갑자기 글로벌 마인드가 생기는 것도 아니다.

몸에 베어 있어야 하고 글로벌화를 위한 기술도 잘 알아야 한다. 5천만명을 고객으로 할지 50억명을 고객으로 할지는 스타트업에게 매우 중요한 전략적 요소이다. 글로벌 시장을 겨냥한다면 글로벌 마인드와 더불어 유창한 영어 실력은 기본적으로 필요하다고 할 수 있다. 아니면 영어가 유창한 파트너를 둬야 한다.

항상 기회는 조용하게 다가온다. 남들이 다 알 때쯤이면 시끄러워진다. 과거 10여년동안 스타트업 붐이 여러 번 있었다. Web과 Web2.0이 있었고 스마트폰과 SNS로 인해서 또 붐이 일고 있다. 물론 10여전과 같이 거품이 크게 일고 있지는 않지만 분위기가 나쁘지 않다. 그런 붐에 무작정 편승하는 것이 좋은 생각은 아니지만, 확신과 열정이 있고 준비가 충분하다면 좋은 시기를 선택하는 것도 나쁜 방법은 아니다.

필자는 우리나라 소프트웨어 생태계를 바꾸는 유일한 방법은 수많은 스타트업이 탄생하는 것으로 생각하고 있다. 실패도 있겠지만 많은 스타트업이 성공하고 성장하고, 또 새로운 스타트업이 많이 탄생하는 사이클을 이뤄야 소프트웨어 생태계가 개선되고 개발 문화가 좋은 방향으로 바뀌어 나갈 것으로 생각한다.

이 글은 Tech it에 기고한 글입니다.

국제화 시 고려해야 할 49가지

소프트웨어를 국제화해야 하기 위해서는 고려해야 할 것이 한두가지가 아니다. 그런데 많은 회사들은 메시지나 번역하면 되는 것으로 안다. 그렇게 쉽게 접근하다가는 해외 진출을 하면할 수록 문제가 커지고 비용이 늘어서 점점 어려워진다.

실제 만나본 거의 대부분의 회사가 국제화를 제대로 적용하지 못해서 낭패를 보고나 해외에서 크게 실패를 하였다. 비효율성이 높고 문제가 많아도 제품의 크기가 작거나 고객수가 적다면 그럭저럭 버티지만 큰 제품이나 대규모 서비스는 타격이 엄청나다. 심지어는 회사가 휘청할 정도의 문제를 야기 시키기도 한다.

국제화 기술은 알아야 할 지식도 많고 경험도 많이 필요하다. 

기본적으로 국제화(i18n)과 지역화(L10N)으로 나뉜다. 국제화(i18n)은 소프트웨어가 여러 Locale을 지원할 수 있는 기본 기술이고 지역화(L10N)은 각 Locale을 지원하는 것이다.

이 과정에서 고려해야 할 것은 수백가지가 넘는다. 그 중에서 49가지만 알아보자. 만약에 국제화된 소프트웨어를 개발하고 있는 개발자라면 이중에서 몇가지나 알고 있는지 세어보자. 어떤 항목은 그 하나가 엄청나게 큰 것도 있다. 특별하게 순서를 가지고 정리한 것은 아니지만 하나씩 살펴보자. 

번호	항목	설명
1	언어 구분	한 국가에도 언어가 여러가지이기도 하고 하나의 언어가 여러 나라에서 서로 다르게 쓰이기도 한다.
2	지역 구분	지역과 국가가 완전히 일치하지는 않는다. 언어와 지역 정보가 합쳐져서 Locale이 된다. 소프트웨어는 Locale 단위로 지역화(L10N)를 한다.
3	소프트웨어의 인코딩 전략	소프트웨어가 지원해야 할 인코딩은 매우 복잡하다. Multibyte를 지원하냐 Unicode를 지원하냐에 따라서 인코딩이 다르고 Software, File, Database, Network 별로 다른 인코딩 전략을 사용해야 한다.
4	현지 로케일의 인코딩으로 Export	지역에 따라서 특정 인코딩을 선호하기도 하고 Software의 인코딩과 다른 인코딩으로 Export를 하기도 한다.
5	시스템에 따른 인코딩 차이	거의 대부분의 OS는 Unicode를 지원하지만 OS에 따라서 Unicode이 인코딩이 다르다. UTF-16(UCS2) 또는 UTF-32이 그 예이다.
6	로칼 요구사항의 차이	지역화(L10N)시 현재의 요구사항을 반영한다. 하나의 소스코드와 하나의 팩키지로 지역 요구사항을 반영할 수 있도록 한다.
7	메시지 번역	Locale별로 번역을 한다.
8	메시지 번역 프로세스	소스코드에서 메시지를 추출하고 번역하고 제품에 반영한다. 소스코드가 수정되면 수정된 메시지를 쉽게 반영할 수 있는 프로세스가 필요하다. 번역을 제외한 모든 부분은 자동화가 되어야 한다.
9	메시징 기술	메시징 기술은 수도 없이 많지만 여기서 언급한 모든 것을 지원하는 메시징 기술은 별로 없다. 거의 대부분의 회사는 개발툴에서 번들로 제공하는 간단한 메시징 기술을 사용하는데 이 정도로는 아주 간단한 소프트웨어 밖에 제대로 지원하지 못한다.
10	문자 인코딩 변환	소프트웨에서는 여러가지 인코딩을 사용하기 때문에 수시로 변환을 해야 한다.
11	번역에 따른 문자열 길이 변화	메시지를 번역하면 메시지의 길이가 변한다.
12	국제화를 고려한 UI 디자인	메시지의 길이는 지역에 따라서 바뀌기 때문에 이를 고려하여 UI를 디자인 해야 한다.
13	단수, 복수 표현의 차이	단수, 복수가 없는 언어도 있고 영어보다 훨씬 복잡한 단수, 복수를 사용하는 언어도 있다. 대표적인 것이 폴란드어이다. 메시징 기술은 이것을 지원해야 한다.
14	쓰기 방향의 차이 (오른쪽, 왼쪽)	언어 별로 쓰는 방향이 다르다.
15	커서의 이동 방향  (오른쪽, 왼쪽)	오른쪽 화살표를 눌러도 커서가 왼쪽으로 이동하는 언어도 있다.
16	키보드 글자 배치	언어별로 키보드의 글자배치가 다르다.
17	키보드의 단축키 차이	키보드에 따라서 단축키가 서로 다르다.
18	문자입력기(IME)차이	언어별로 문자입력기가 다르다.
19	폰트의 차이	언어별로 사용하는 폰트가 다르다. 서로 다른 폰트를 고려해야 한다.
20	글자의 크기 차이	언어별로 기본 글자의 크기가 다르다. 특히 중국어는 영어보다 크기가 크다.
21	숫자 표기 방법	나라별로 숫자의 표기가 다르다. 콤마(,)와 점(.)를 표시하는 방법이 다르다. 심지어는 콤마(,)대신 공백을 사용하는 나라도 있다.
22	띄어쓰기 사용의 차이	영어와 한글에 띄어쓰기가 있기 때문에 모든 언어에 띄어쓰기가 있을 것 같지만, 띄어쓰기가 아예 없는 언어도 많아서 띄어쓰기를 기준으로 단어를 분리하면 안된다.
23	쉼표, 마침표 사용의 차이	쉼표와 마침표의 사용도 언어마다 다르다.
24	날짜 표기법의 차이	01/02/03을 읽는 방법은 나라마다 다르다. 미국, 한국, 호주가 각각 다르다.
25	타임존 고려	국제화된 소프트웨어를 만들려면 타임존을 고려해야 한다.
26	썸머타임 고려	썸머타임을 고려해야 하는 나라가 있다.
27	대소문자 구분의 차이	언어마다 대소문자가 다르다. 대소문자가 없는 언어도 있다.
28	관사 사용법 차이	언어마다 관사가 다르다. 관사가 없는 나라도 있다.
29	맞춤법 검사 모듈	맞춤법 검사 기능이 있다면 국제화를 고려해야 한다.
30	사전 제공	사전을 제공한다면 국제화를 고려해야 한다.
31	정렬 방법의 차이	문자열의 순서가 언어마다 다르다. 대부분의 소프트웨어는 목록을 정렬해야 한다. 이때 국제화 기술을 적용해야 한다.
32	화폐 단위의 차이	지역별로 화폐의 단위 및 그 표기법이 다르다.
33	길이, 무게, 부피 단위 차이	지역별로 측정 단위가 다르다.
34	종이 크기의 차이	지역별로 인쇄에서 사용하는 용지의 명칭이 다르다.
35	온도 단위 차이	지역별로 사용하는 온도의 단위가 다르다.
36	주소 형식의 차이	지역별로 주소 표시 형식이 다르다.
37	전화번호 등의 현지화	소프트웨어에서 전화번호를 사용한다면 지역별로 다른 형식을 지원해야 한다.
38	이름 표기법의 차이	지역별로 이름 표기법이 다르다. 이름의 구성, 순서가 다르다.
39	현지 법률 및 제도 적용	현지 법률이나 제도와 표준을 지원해야 한다.
40	문화에 따른 아이콘의 차이	동일한 아이콘이라고 하더라도 문화에 따라서 완전히 다르게 인식할 수 있고 금기시 되는 이미지들도 있다.
41	알파벳을 형상화한 아이콘	아이콘 중에는 알파벳을 형상화 한 것들이 있는데 이는 언어에 따라서 바뀌어야 한다. 대표적인 것이 Bold 아이콘인 "B"이다. 언어에 따라서 Bold가 "B"로 시작하지 않는다.
42	텍스트를 포함한 아이콘	아이콘에 텍스트가 포함된 경우가 있다. 이때 텍스트의 길이 폰트의 크기 등을 고려해야 한다.
43	이모티콘 차이	나라별로 이모티콘이 다르고 지역화된 이모티콘도 있다.
44	색상의 의미 차이	나라별로 색상의 의미가 완전히 다르다. 선호 색상도 다르다.
45	O, X 등 기호의 차이	언어별로 기호의 의미는 천차만별이다. 우리에게 X는 틀렸다는 의미지만 영어에서는 Check라는 의미가 있다.
46	유니코드 처리	국제화된 소프트웨어를 개발하려면 유니코드는 기본이다. 누구나 다 아는 것도 유니코드이지만 유니코드를 제대로 알려면 1,2년 가지고는 모자르다.
47	외부 라이브러리의 유니코드 지원 고려	외부라이브러리들이 유니코드를 지원하지 않는 경우가 있다. 이를 고려해야 한다.
48	파일 시스템의 지원 인코딩	OS별로 파일 시스템의 인코딩이 서로 다르다. 이를 고려해야 한다.
49	멀티 Lingual 고려	하나의 소프트웨어로 수많은 언어를 동시에 지원하고 바꿀 수 있어야 한다.

여기에 모든 것을 다 나열한 것은 아니다. 하지만 이중에서 필요한 일부를 고려하지 않고 소프트웨어를 개발한다면 이것은 버그가 될 것이고 또는 해당 국가에서 보면 어색하고 기분 나뿐 소프트웨어가 될 수도 있다. 물론 소프트웨어의 종류에 따라서 국제화시 고려해야 하는 항목이 다르다. 따라서 위의 모든 것을 모든 프로젝트에서 고려해야 하는 것은 아니다. 한번씩은 생각해봐야 할 항목들이다.

좋은 소프트웨어를 가지고 비즈니스를 아무리 잘해도 국제화가 잘 안된 소프트웨어는 현지에서 성공하기 어렵다.

1~49번까지의 항목들이 제목만 본다고 쉽게 해결할 수 있는 것은 아니다. 하나의 항목을 가지고 10년 넘게 연구하고 개발하고 있는 것도 있을 정도로 크고 복잡한 것도 있다. 제대로 국제화를 적용하고 싶다면 국제화 전문가의 도움을 받는 것도 한 방법이다. 이것을 처음부터 제대로 하지 않고 시행착오를 거쳐서 고객이 버그를 찾을 때마다 하나씩 고쳐주는 것은 끝도 없고 제품의 이미지는 처음부터 추락할 것이다. 

확실한 것은 국제화를 스스로 생각해서 직접 개발하면 잘못될 가능성이 99%이다. 대부분은 이미 국제 표준이나 기술이 있으므로 직접 개발하기보다는 제대로 완성된 기술을 이용해야 한다.

국제화 기술이 소프트웨어 해외 진출 필수임을 잊지 말자.