성공하는 스타트업 파운더의 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%이다. 대부분은 이미 국제 표준이나 기술이 있으므로 직접 개발하기보다는 제대로 완성된 기술을 이용해야 한다.

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