바다 이야기: 죽음을 향한 행진
이번 글은 제 개발자 인생에서 가장 인상 깊었고, 아쉬웠고, 후회도 많았던 프로젝트에 대한 짧은 회고입니다. 이야기 주인공은 바로 삼성전자 시절, 핸드폰용 자체 플랫폼인 바다(bada)입니다. 인터넷을 검색해보니 다행히 공개된 이야기들과 겹치는 내용은 거의 없네요.
제가 아는 바다의 역사는 대략 다음과 같습니다.
그림에서 보다시피 제가 직접 관여한 기간은 4년 남짓이며, 중심 인력은 아니었기 때문에 지금부터 풀어놓을 이야기는 사실과 다소 다를 수 있음을 미리 말씀드립니다. (반박 시 님이 맞음! ^^)
이 과제는 흥미로운 점이 많습니다. 우선 앞 그림의 주 타임라인에서는 편의상 일직선으로 표현했지만, 바다는 선형으로 점진적으로 성장한 플랫폼이 아닙니다. SHP부터 Matrix까지는 각기 다른 목적을 지닌 독립된 프로젝트였습니다. 더욱이 바다는 아이폰과 안드로이드의 등장이라는 급작스러운 시장 변화에 대응하기 위해 서둘러서 결과를 내야 할 처지였습니다. 여기에 정치적인 이유들까지 더해져서 대략 다음 그림처럼 조금 기괴한 형태로 출발하게 되었습니다.
SHP부터 Matrix까지, 빠르게..
주인공인 바다 이야기를 하려면, 보다 먼저 태어난 그 구성요소들부터 가볍게 만나봐야 하겠죠. SHP부터 시작하겠습니다.
SHP(Samsung Handset Platform)는 대성공을 거둔 피처폰용 플랫폼입니다. 피처폰 시절에는 소프트웨어 플랫폼이 부각되지 않았어서 대중에게는 알려지지 못했지만, SHP는 론칭 후 연간 수천만 대의 폰에 탑재된 히트작입니다. 그 공을 인정받아 프로젝트를 이끈 리더 A님은 당시에는 흔치 않던 특진과 삼성인상 수상 등 S급 인재로 대우받기 시작합니다. 성과와 실력뿐 아니라 외모도 출중하셔서 저희 조직에서는 아이돌 같은 존재였죠. 어쨌든 프로젝트를 사업부로 이관하고, 이 분은 차세대 플랫폼을 구상합니다. 바로 Ocean입니다.
Ocean은 시대를 잘못 태어난 비운의 플랫폼이라고 생각합니다. 핵심 모듈들을 모두 컴포넌트화하여 동적으로 로드/언로드할 수 있었고, 같은 방식으로 앱도 설치할 수 있었습니다. 내부 설계는 물론 API도 상당히 깔끔했습니다. 문제는 시기가 2003~2005년 정도였다는 것이었죠. 아이폰 등장 전이라서, 상대적으로 고사양을 요구했던 미래지향적 특성들이 시장에서 환영받지 못했습니다. A님은 이 프로젝트를 접으면서 오픈소스로 풀고자 하였으나, 뜻을 이루기에는 당시의 삼성전자가 너무 보수적이었던 거 같습니다. (곁가지로, Ocean은 추후 바다 프로젝트가 ‘바다’라는 이름을 얻는 데 큰 영향을 줍니다.)
Matrix는 (지금 용어로는) IoT 시대를 대비한 미들웨어 플랫폼이라 할 수 있겠습니다. GPS, 카메라, 온도 등등 수많은 센서 데이터를 빠르게 취합하여 다양한 응용 서비스를 구현할 수 있게 도와주었습니다. 운영체제로는 리눅스와 윈도우 모바일을 지원했습니다. 그런데 프로젝트가 나름 잘 진행되던 중 큰 사건이 터집니다. 바로 아이폰의 등장입니다.
아이폰의 등장으로 삼성전자는 비상이 걸렸으며, 대응책 모색에 여념이 없었습니다. 당시 선택지는 꽤 많았습니다.
* 윈도우 모바일
* 심비안
* 리모(LiMo)
* 안드로이드(아직 제품 출시 전)
* 새로운 자체 플랫폼
* ..
새로운 자체 플랫폼으로 낙점된 것이 바로 바다입니다. 물론 당시에는 존재하지 않던 플랫폼이었지만, SHP를 성공시킨 이후 꾸준히 모바일 플랫폼을 개발해 온 A님께 기대를 걸어본 거 같습니다.
한편 이 시기에 Matrix팀이 속해 있던 ‘소프트웨어 센터’ 조직이 공중분해되었습니다. 그 과정에서 온전하게 살아남은 유일한 팀이 바로 A님이 이끌던 Matrix팀이었습니다. 살아남았을 뿐 아니라 오히려 규모가 훨씬 커졌습니다.
바다, 잘못된 시작과 전략
당연하게도 우리에게는 플랫폼을 차분히 다시 설계하고 개발할 여유가 없었습니다. 가용한 기존 자원을 최대한 재활용해야 했죠. 그래서 (앞에서도 보았듯이) 대략 다음 그림과 같은 형태로 출발하기로 했습니다.
SHP는 수많은 삼성 피처폰에서 수년간 검증된 플랫폼이었고, Ocean은 최초 개발 당시 미래 지향적으로 설계되었기 때문에 다시 가져와 활용하기에 크게 무리가 없었습니다. 그리고 Matrix에서 스마트폰에 유용한 컴포넌트들을 가져와서 기본 틀을 완성했습니다. 여기에 아직 부족한 기능과 기본 앱 등을 더 구현해야 했고, 앱스토어 같은 백엔드 서비스, 서드파티 개발자용 SDK 등을 준비해야 했습니다.
하지만 (아마도 주로 정치적인 이유로) 첫 발을 내딛기조차 순탄치 않았습니다. 그 후 여러 현실적인 어려움과 (제 생각으로는) 전략적 실수가 더해져서 절대 성공할 수 없어 보이는 프로젝트가 되었습니다. 바다의 미래를 암울하게 하는 가장 큰 장애물은 다음 네 가지로 보였습니다.
* 임베디드 OS로 뒷걸음질
* 상처투성이로 돌아온 SHP
* 앱 개발을 C++로
* 프리미엄 포기 전략
여기서 +1으로, ‘갤럭시 S의 백태클’도 한몫했습니다. 하나씩 가볍게 부연하겠습니다.
1. 임베디드 OS로 뒷걸음질
제가 가장 처음 좌절한 부분입니다. 직전 프로젝트인 Matrix는 리누스와 윈도우 모바일 위에서 동작했습니다. 경쟁 제품인 아이폰은 OS X(macOS의 당시 이름)을, 안드로이드는 리눅스를 선택했는데 우리는 임베디드 OS라니.. 눈앞이 막막했습니다.
물론 우리가 몰라서, 혹은 원해서 한 선택이 아니었습니다. 이미 삼성 내부에는 리모(LiMo) 플랫폼을 이끄는 조직이 있었고, 안드로이드 플랫폼을 이끄는 조직도 따로 있었습니다. 즉, 리눅스 기반 조직이 둘이나 있었습니다. 더구나 그 조직의 리더들은 부사장급이었던 반면 바다팀 리더는 아직 수석이었습니다. 수석 → 상무 → 전무 → 부사장 순이었으니, 위상 차이가 엄청났죠. 다른 전략적인 이유도 있었겠습니다만, 어쨌든 어쩔 수 없이 임베디드 OS에서 시작해야 했습니다.
(추후 리눅스에서도 돌아가게 되었고, Tizen에 흡수되었습니다.)
2. 상처투성이로 돌아온 SHP
SHP 역시 A님이 주도해 개발했지만, 사업부로 이관한 지 6년 정도가 지났습니다. 그리고 당시는 ‘통신사가 절대 갑’인 시절이었습니다. 핸드폰 제조사는 힘이 없었기 때문에, 전 세계 통신사들의 입맛에 맞게 스펙과 기능을 바꿔서 출시하던 시절이었죠. 실제로 삼성전자가 1년에 출시하는 폰이 500가지가 넘었습니다. 그런 시절을 지나오다 보니 SHP도 자연스럽게 수많은 갈래로 찢겨 있었고, 코드도 넝마가 되어 있었습니다.
그나마 쓸만한 브랜치를 선택하였으나, 깔끔과는 거리가 멀었습니다. 제 관점에서 가장 우려되는 부분은 예외 처리였습니다. 앱에서 API를 호출하면 대부분 SHP까지 내려갔다가 옵니다. 그 과정에서 자연스럽게 여러 예외가 발생할 수 있겠죠. 예외는 원인을 정확하게 알아야 중간 계층에서 직접 처리할지, 윗단으로 넘길 지를 정할 수 있습니다. 하지만 수년간 야생에서 피투성이가 된 SHP는 원인 모를 예외를 남발했습니다. 중간에서 처리하지도 못하고 앱 개발자에게 Unknown 예외를 던질 수밖에 없었습니다. ‘이 간단한 기능에서 Unknown 예외가 날 이유가 뭐가 있지?’ 싶은 API들이 엄청 많아졌습니다.
3. 앱 개발을 C++로
바다 앱은 C++로 개발해야 했습니다. 한편 저는 예전부터 C++는 지나치게 복잡하여, 진입장벽이 높고 생산성도 떨어진다고 생각했습니다. 플랫폼이나 엔진처럼 성능과 효율을 극한까지 높여야 하는 기반 기술이라면 C++는 좋은 선택일 수 있습니다. 하지만 사용자 앱까지 C++를 강제하는 건 미래가 아니라고 봤습니다.
크게 공감을 얻지 못한 우려였지만, 지금 주변을 돌아보면 결과적으로 제 생각대로 흘러온 거 같습니다. 플랫폼에 상관없이, 앱을 C++로 개발하는 비중은 빠르게 줄어왔습니다.
저는 자바를 주력으로 사용하다가 Matrix팀에 합류하여 생산성 차이를 많이 느껴왔습니다. 언어 자체도 복잡하지만, IDE 등 개발 도구가 너무 뒤떨어졌습니다. 뛰어난 개발자라면 언어에 따른 차이는 크지 않다고들 합니다만, 더 많은 개발자를 포용하려면 지원 도구와 언어 자체도 매우 중요할 것입니다.
추후 커뮤니티 반응을 보면 C++ 자체보다는 SDK와 IDE 쪽 문제가 더 심각했던 거 같습니다. 그런데 이런 도구를 개발하는 데도 언어 자체의 복잡도가 영향을 많이 줍니다. 예전에 정적 분석 도구를 개발하던 분의 말씀에 따르면 C++가 자바보다 1000배는 복잡하다고 하더군요(물론 그때의 자바는 지금보다 훨씬 간결했습니다).
4. 프리미엄 포기 전략
바다팀이 꾸려지고 수개월 후, 바다는 프리미엄 폰이 아닌 ‘중급 ~ 중고급’ 시장을 겨냥한다는 전략 발표가 있었습니다. 저는 이해할 수 없었죠. 당시에도 하드웨어의 발전 속도는 엄청났습니다. 올해의 프리미엄폰이 1~2년이면 중급폰이 되는 혁신의 전장에서, 후발주자가 처음부터 프리미엄을 포기한다? 나오자마자 그저 그런 폰이라는 느낌을 주지 않을까 우려됐습니다.
이 결정의 배경이 정치였는지, 전략이었는지는 모르겠습니다. 만약 전략적인 이유였다면, 아마도 여러 스마트폰 플랫폼이 오랜 기간 공존할 거로 예상했던 게 아닌가 싶습니다. 만약 그랬다면 초기에 중저가 폰들로 나름의 영역을 구축한 후 또 다른 승부수를 던져볼 생각이었을 수도 있었을 거 같습니다. 하지만 제 눈에는 아이폰과 안드로이드 말고는 오래 버틸 만한 선수가 보이지 않았습니다.
당시 시장을 지배하던 심비안은 너무 난잡했습니다. 경쟁 플랫폼이어서 잠시 분석해보았는데, 십여 분 정도 훑다가 ‘신경 쓸 필요 없겠다’라고 결론지었습니다.
윈도우 모바일은 Matrix 시절에 많이 써봤습니다. 플랫폼 자체도 별로였고 개발 환경도 열악했습니다. 당시에는 경쟁 플랫폼들도 별반 다르지 않았기에 ‘그런가 보다’ 했지만, 아이폰 SDK를 접하고 ‘이렇게도 할 수 있는 걸 MS는 그동안 뭘 했나’ 싶을 만큼 넘을 수 없는 격차가 느껴졌습니다. MS도 빠르게 인지하고 이 플랫폼을 포기했습니다. 한참 후에 나온 윈도우 폰(Windows Phone)은 버전업 때마다 하위 호환을 끊는 등, 수많은 삽질 끝에 자멸했습니다.
리모는 기술력 부족한 회사들의 연합체라서 제대로 된 성과를 빠르게 내기 어려운 구조였습니다. 프로젝트에 참여 중이던 지인들 이야기를 들어봐도 많이 갑갑했습니다.
(+1) 갤럭시 S의 백태클
어느 정도 시간이 흘렀고 저는 바다팀을 떠났습니다. 결정적인 이유는 다른 데 있었지만, 바다에서 미래가 보이지 않았기에 굳이 출시 때까지 머물러 있을 이유를 찾지 못했습니다. 그래서 이번 이야기는 제가 팀을 떠난 후에 벌어진 일입니다. 이 기간에 저는 다른 팀에서 갤럭시 S에 탑재될 앱을 개발하고 있었습니다.
상기한 여러 이유들과 몇 차례의 일정 지연에도 불구하고 바다의 첫 시작은 나쁘지 않았습니다. 첫 폰인 웨이브(Wave)는 바다를 세상에 처음 선보이는 제품이서인지 프리미엄 스펙에 세련된 디자인으로 출시되었습니다. 첫 해에 무려 500만 대가 팔렸다고 하네요. 그런데 삼성 내부에서 갑자기 뒷덜미를 낚아챘습니다. 갤럭시 S가 성공적으로 데뷔한 것입니다.
갤럭시 S는 삼성전자에서 사활을 건 프로젝트였습니다. 바다팀보다 훨씬 높은 분이 이끄는 조직의 제품이며, 웨이브보다 비쌌습니다. 이런 상황에서 웨이브와 갤럭시 S는 공유하는 자원이 하나 있었으니, 바로 OLED 디스플레이였습니다. 당시 OLED는 최첨단 기술이어서 두 폰이 나눠 쓰기에는 생산량이 부족했습니다. 그래서 삼성은 결단합니다. 웨이브 생산을 중단하기로.. 그 후로 갤럭시 시리즈는 승승장구하고, 바다폰은 더 이상 프리미엄 하드웨어의 맛을 보지 못합니다.
갤럭시 S가 성공하지 못했다 한들 바다가 성공했을 것이냐? 저는 그렇게 보지는 않습니다. 초기 사용자 기반은 훨씬 늘어났겠지만 앱 생태계를 꾸려 나가는 일은 여전히 험난했을 겁니다. 실제로 바다팀은 SDK와 커뮤니티 지원에 대한 불만을 쉽게 잠재우지 못했고, 1.0 이후 개발과 릴리스도 그리 순탄해 보이지 않았습니다.
또한 갤럭시 S가 실패했더라도 삼성이 안드로이드를 곧바로 폐기하지는 않았을 겁니다. 다음 제품으로 또다시 반격의 기회를 노렸겠지요. 혹시라도 포기했다면 ‘애플 vs. 안드로이드 진영 vs. 삼성(바다)’의 구도가 전개됐을 텐데, 승리하는 모습은 상상하기 어렵네요. 자칫 심비안의 뒤를 따랐을 지도요.
종합 정리
지금까지의 여러 요인들을 정리하면 다음 그림처럼 되겠네요.
바다는 어쩔 수 없이 임베디드 OS를 써야 해서 메모리, 프로세스, 파일 관리, 보안 등 OS의 기본기 측면에서 경쟁 제품들에 크게 밀렸습니다. SHP부터 Matrix까지는 비록 한 사람이 이끌었다고는 하나, 다른 시간대에 다른 목적으로 만들어진 독립된 플랫폼들입니다. 이들을 하나로 모아 매끄럽게 동작시키는 일은 결코 쉽지 않습니다. 게다가 독립했다가 돌아온 SHP는 골병이 들어 플랫폼의 안정성을 위협했습니다. 여기에 앱 개발도 쉽지 않고, 내부의 적까지..
아쉬움과 후회
지금 되돌아보면, 이 프로젝트에 참여하며 아쉬운 점이 너무 많습니다. 그중 딱 두 가지만 이야기해 보겠습니다.
1. 역량에 비해 안 좋게만 남은 이미지
결과적으로 바다는 시장에 안착하지 못했습니다. 특히나 앱 개발자들에게 좋은 인상을 심어주는 데 실패했습니다. 그래서 기술력에 비해 혹독한 평을 듣게 되었다고 생각합니다.
SDK 개발과 커뮤니티 지원 역량은 확실히 많이 부족했던 거 같습니다. SHP부터 Matrix까지 모두 사내용이었기 때문에 일반 개발자 대상의 SDK와 개발 지원은 제대로 경험해 본 사람이 없었습니다. 바다 론칭 시에는 외부 인력을 더 보강했겠지만, 국내에서 이런 경험이 풍부한 사람은 거의 없었을 겁니다.
한편 앞서 이야기했듯이, 바다는 굉장히 불합리한 조건에서 출발했습니다. 세상에 쉬운 프로젝트가 어디 있겠냐마는, 그래도 숱한 악조건 속에서도 포기하지 않고 도전하는 정신이 지금 생각하면 실로 놀랍습니다. 이런 사람들이 있기에 새로운 혁신이 이루어지고 세상이 조금씩 발전하는 걸 겁니다.
순수하게 기술적인 선택들로 아키텍처가 꾸려졌다면, 혹은 Ocean 프로젝트가 중단 없이 계속 발전해 왔다면 조금은 더 재미난 경쟁이 되었으리라 생각합니다.
2. 이상을 좇다가 팀에 융화되지 못함
이번에는 저에 대한 아쉬움입니다. 저는 이 프로젝트에 참여할 당시 이상을 좇던 사람이었습니다. 여러 면에서 우수한 팀이었음에도, 이상이라는 눈높이에서 바라보니 현실은 항상 부족할 수밖에 없었습니다. 또 한편으로 저는 굉장히 성숙하지 못했습니다. 냉철하게 현실을 직시할 줄 몰랐고, 조급했으며, 사람들과 소통하는 스킬도 부족했습니다. 그러다 보니 어느새 저는 팀에 융합되지 못하는 부정적인 사람이 되어 있었습니다. 되돌아보면 배울 게 참 많았는데 기회를 살리지 못해 너무 아쉽습니다.
팀 이동을 결심하고 마지막 면담 자리에서 리더인 A님께서 이렇게 말씀하셨습니다. “네게 해주고 싶은 말이 있지만, 제대로 들리지 않을 것 같다.” 실제로도 당시의 저는 제대로 듣지 못했을 겁니다. 무슨 말씀이냐고 한 번 여쭈었어야 했는데, 그러지조차 않았으니까요. 무슨 말씀을 해주시려던 것인지 지금까지도 무척 궁금합니다. 당시는 몰라도, 조금은 더 성숙한 지금의 저라면 이해할 수 있을 텐데 말입니다.
마치며
바다는 역사가 짧지 않은 만큼 조각조각 이야깃거리가 정말 많습니다만, 궁금해할 사람이 거의 없을 테니 이 정도에서 마무리하겠습니다.
