레인레테 :: 작은 달팽이집속 바다.

1. 맨땅에 개발하던 시대.
아주아주아주아주 먼 옛날. 
소형 컴퓨터라는 것이 방 하나를 꽉 채울 만큼 큼직했던 시절.
디버깅이라는 것이 실제로 진공관 사이에 끼어 죽어있는 벌레를 처리하는 것이었던 때에 모든 개발자들은 컴퓨터 작동에 필요한 모든 논리를 처음부터 만들어내야 했어요. 

자동차를 만들 때마다 고무를 녹여 타이어를 만들고, 철을 녹여서 엔진을 만드는 격이었죠.


2. 라이브러리가 등장하다.
그러다가 누군가가 이런 생각을 했어요. 
그럼 미리 고무를 잔뜩 녹여서 타이어를 만들어놓으면, 자동차를 조립하기 편하겠네?
그래서 많은 개발자들은 일일이 고무를 녹이는 대신 타이어를 파는 가게에서 바퀴를 사다가 끼기만 하면 되었어요. 
자동차를 만드는 시간은  획기적으로 단축되었고, 모든 개발자들은 이것이 마법이라고 생각했어요. 

이런 타이어 같은 것을 '라이브러리' 라고 해요. 미리 만들어진 부품을 가져다가 쓰는거죠.


3. 프레임워크의 시대가 도래하다.
이렇게 타이어를 팔던 가게가 번성하던 어느 날, 새로운 자동차가 필요해진 A씨는  이런 생각을 했어요. 
'내가 왜 자동차를 만드는데 이 모든 부품을 다 알아야 하는 걸까? 그냥 조립이 다 되어 있으면 안되는걸까?'
그래서 A씨는 엔진, 타이어, 핸들 등이 다 붙어있는 자동차를 만들어 팔기로 했어요. 
이 자동차를 구매하는 사람들은 '색깔' 이나 '선루프'  등의 옵션만 선택하면 되게 된 거죠. 

이렇게 '자동차'를 만들기 위한 '꼭 필요한 부품들이 미리 조립되어 있는 것' 을 프레임워크라고 합니다.

이런 식으로 컴퓨터 프로그래밍은 발전되어 왔답니다.

더이상 사람들은 자동차에 대해서 정확히 어떤 구조로 굴러가는지 알 필요 없이 엑셀레이터를 밟으면 굴러가고 브레이크를 밟으면 멈추며, 핸들을 돌리면 방향이 바뀐다는 것만 알면 되는거죠.

참 아름다운 세상이에요.


4. 문제가 생겼을 때는 어떻게 하지?
끝!
.. 이라고 하면 참 아릅답고 행복했을 때지만, 현실은 그렇지 않아요. 
여느날처럼 자동차로 출근을 하던 B씨는 갑자기 달리던 자동차가 덜컥 멈추는 황당한 사태를 맞이하게 되었어요.
자동차에 대한 지식이라고는 운전하는 법과 라디오 켜는 법밖에 모르던 B씨에게 이건 낭패였죠.

그래서 B씨는 '인터넷'이라는 이름의 친구에게 다급하게 전화를 합니다. 
'인터넷'은 자기가 알고 있는 지식을 총 동원해서 B씨를 도와주려고 하지만
B씨는 도대체 왜 자동차가 멈추었는지 알 길이 없었기 때문에 설명하기가 너무 어려웠어요.

결국 B씨는 '인터넷'에게  '고렙 개발자' 라고 하는 이름의 자동차 수리가게를 소개받았죠.


5.  결국 구조를 다 알아야 하네?! 
'자동차 수리가게' 에서는 B씨에게 '엔진오일도 없고 미션 상태도 좋지 않네요.' 라고 말을 해 줬어요.
그렇지만 B씨는 자동차 안에 왜 엔진오일이 필요한 건지, 미션이라는건 도대체 무엇인지 알 수가 없었어요.
그냥 '고쳐주세요' 라고 말하는 수밖에 없었죠.

그리고 생각했어요. 
'아. 정상적인 상태일때는 미리 조립되어 있는 것이 참 편리하지만, 문제가 생기면 결국 기본 구조를 다 알아야 하는구나.'


6. 제조사에서는 어떻게?
이런 상황을 자동차 제조 회사에서도 모를리가 없죠. 
그래서 자동차 회사에서는 '최신 자동차 조립기술'에 맞는 '최신 전자제어장치'를 집어넣기로 했어요.
엔진오일이 없으면 계기판에서 경고등이 나오는 장치에요. 
이제 더이상 B씨는 엔진오일이 없어서 자동차가 달리다가 멈추는 일은 없을 꺼에요! 

.. 물론 여전히 미션의 상태는 확인할 수 없겠지만요. 

또 시대가 바뀌면서 자동차가 그냥 운송수단에서 레져로 바뀐다는것을 자동차 회사는 간파했어요.
그래서 자동차의 시트를 푹신하게 바꾸고, 크루즈 기능을 넣어서 자동 운전이 가능하게 만들었죠. 
즉, 이 회사는 '자동차'라는 프레임워크와 그걸 만드는 기본 재료인 '시트'를 통채로 다 맞춰서 바꾸는 거에요. 

이런걸 제일 잘하는 회사 이름은 마이크로소프트에요.

웹 여행을 할 때 쓰는 자동차 "ASP.NET" 을 시대에 맞춰서 "ASP.NET MVC 나 ASP.NET AJAX" 로 변신시키고, 
데스크탑에 코어가 여러개 달린 컴퓨터 시대가 도래하자 "패러럴" 기능을 아얘 언어에 통합시켜 버렸답니다. 

덕분에 운전자들은 '크루즈' 기능을 어떻게 쓰는건지 배워야 했지만
대신 일정한 속도로 달릴 특정 상황에는 엑셀레이터를 안밟아도 되는 편안함을 얻게 된 거에요. 


7. 튜닝 한번 해볼까?
멋쟁이 C씨는 자신의 자동차가 다른 자동차들과 똑같아 보이는게 싫었어요. 
그래서 자동차 문이 옆으로 열리는 대신 위로 열리게 개조를 한 거에요.

그런데 자동차 문을 바꿔놓고 보니 멋지기는 한데, 자동차가 달릴때 자꾸 바람소리가 들려와요.
알고보니 자동차회사가 이 자동차를 설계할 때 초정밀 계산기로 계산해 둔 자동차가 달릴때  외부 바람에 대한 마찰역학계수를 C씨는 몰랐기 때문이었어요. 

결국 C씨는 위로 열리는 문을 뜯어내고 다시 옆으로 열리게 개조하는 수밖에 없었습니다. 

이렇게 프레임워크는 '구조상 하위호환성을 유지하면서 업그레이드하는 것'은 멋쟁이 C씨가 할 수 있는 일이 아니었네요. 자동차 회사만 가능하군요. 


8. 낡았어. 바꿔야겠어. 
오랫동안 차를 잘 타고 다니던 'D' 씨는 이 차가 시대의 흐름에 맞지 않는다고 느꼈어요. 
주위 친구들은 다들 최신 기종인 'Ruby on rails" 를 타고 다니는데 자신만 'Structs' 를 타고 다니는건 촌스러워 보였거든요. 
그래서 이 차가 자신에게 맞나 한번 타보기로 했어요.
아니 그런데 이게 뭐에요.
핸들은 오른쪽에 있는 데다가 기어가 핸들 옆에 붙어있고, 심지어는 크루즈 모드도 없어요. 게다가 더욱 더 이해할 수 없게  여기는 뭐에 쓰는지 모를 '에어 브레이크'라는 기능도 있다는 거에요. 
D씨는 도대체 이걸 어떻게 운전하는지조차 알 수 없어서 친구들에게 물어봤지만, 친구들은 '우왕 이게 킹왕짱 익숙해지면 완전 편해' 라고만 할 뿐이었어요.
물론 몇몇 친구들은 적극적으로 나서서 'Ruby on Rails' 에 익숙해지는데 도움을 줬지만, 이미 'Structs'에 익숙해신 D씨는 도저히 이해할 수가 없는 것들 투성이었죠.
결국 D씨는  '옛것이 좋은 것이여' 라는 말을 남긴 채   'RoR'을 사용하는 것을 포기했답니다.

이렇게 프레임워크는 한번 익숙해지면, 다른걸로 갈아타기가 너무 힘든 경우가 많아요. 각 프레임워크는 각 프레임워크를 관통하는 철학이 있거든요. 




조금은 프레임워크에 대해서 이해가 가시나요? 

저는 책을 남들만큼 읽는 편입니다. 1년을 기준으로 단행본을 약 100권 남짓. Reference 서적까지 합치면 200권정도. 매주/달 나오는 잡지까지 읽는다는 기준으로 약 1000권정도 읽습니다. 그렇게 책을 읽다 보면 내용이 비슷한 경우도 있고  전혀 다른 통찰을 얻는 경우도 있죠.

이 책은 후자입니다. 요새는 어쩌면 대세가 되어버린 플래폼에 대해서 다루고 있는데요. 이게 좀 웃긴게, 내용은 알찬데 목차가 꽤나 부실합니다. 사람이 책을 읽었다고 해서 전부 기억할 수 없는 이상 어떤 실마리라는 것이 있어야 하는데.. 이렇게 따로 기록을 해 두는 책이 아니면 잊어버리기 일쑤죠. 게다가 지금 글을 쓰기는 하는데 읽은지는 꽤 된지라 메모만을 바탕으로 적는 거라서 약간은 불안하군요 ^^;;

어찌됐든, 기억나는대로 좀 적어두려고 합니다.






책 내용이 꽤나 좋습니다. 목차는 어설픈데 비해서 내용은 꽉 차 있습니다. 교수님들이 그저 연구실에 틀어박혀서 현실을 무시한 채로 이론을 전개하는 비현실적인 내용들과는 달라요. 이런 연구방법이 안좋다는 것이 아니고, 이런 연구방법들은 그저 이론적 토대를 세우는 것이기에 실생활에 적용하려는 사람들에게는 한번 더 생각하고 정리하거나 혹은 정리된 내용을 획득하는 일들이 필요하죠. 그러한 수고를 덜어주는 책이라고 생각하시면 됩니다.



책 자체가 실용서를 표방했지만 실제로 완전 실용서는 아니고, '왜 그런가'를 다루는 학문적인 분야와 '어떻게 해야 하는가'를 다루는 실용서의 중간쯤에 걸쳐있습니다. 즉 내용이 xx한 현상들이 있다. 이러한 것들은 왜 생겼으며 그 종속변수들과 외생변수들은 무엇이고 이럴때 우리는 어떻게 하는것이 현명할 것인가.. 에 대해서 다루고 있습니다. 굳이 실생활에 사용하지 않더라도 알아두면 생각하는 방법을 익히는데 도움이 됩니다.
책 자체가 체크리스트 형식이므로 실전에도 어느정도 도움은 가능할듯하고요.



보이지 않는 엔진이라는 책이 2008년에 나왔었습니다. 간략하게 요약하자면 성장 동력 혹은 유지 동력으로서 플래폼 생태계를 만들어두면 전면으로 나서는 것이 아니라 한걸음 물러나서 생태계를 유지함으로서 돈을 벌 수 있다..정도인데요. 여기서 플래폼 전략이라는게 제일 처음 등장했다..라고 하는군요. 몰랐습니다. 사실 아주 예전부터 플래폼 전략은 있어왔지만 정리한게 이 책이 처음이라는 뜻이겠지요. 이때는 앱스토어가 이렇게까지 뜨기 전이라서 비중이 적지만 그 외  각 소프트웨어 분야에 대해서 플래폼이 어떻게 구성되었는가를 잘 표현해 줍니다. 사람들이 흥미있어하는 주제가 빼곡합니다. 꼭 읽어보시길.





예시는 꽤나 많지만 핵심은 중요 포인트를 공략해라..정도가 되겠네요.

단 주의해야 할 것이, 이 포스트는 어디까지나 책을 읽은 '결과물'일 뿐 '마켓을 보는 프레임'은 아닙니다. 꼭 읽어보시고 결론 뿐만 아니라 세상을 보는 '프레임'을 익히는 걸 연습하시길 부탁드립니다.

구차니님의 기억의 근원 / 기억의 시작 이라는 글을 보고 생각나는게 있어서 기록해 둡니다.

사람이 무언가를 기억하는데는 한계가 있습니다. 그저 실험으로 연역법으로 추정할 수밖에 없는 분야라서 진짜인지 어쩐지는 모르겠으나, 인간이 하나의 항목에 대해서 기억할 수 있는 최대 갯수는 약 7개 정도밖에 안된다는 군요.

우리는 이러한 기억의 손실을 막기 위해서 여러가지 방법을 씁니다.
그중 하나가 추상화이고 다른 하나는 반복,  나머지 하나는 이야기입니다.




추상화는 단순합니다. 뭉뚱그리는거죠.
예를 들어서 '곤충'이라고 한다면 다리가 여섯개여야 하고 절지동물이어야 하고 머리 가슴 배로 나누어져야 한다. 라는 정보만 기억하는 겁니다. (사실은 기준이 몇개 더 있지만 패스. 더 알고 싶으신 분은 위키피디아 곤충 항목 참조하세요)
그래서 새로운 벌레를 발견했을때 저 기준만 가지고 곤충이라는 것을 판단합니다. 그래서 잠자리는 곤충인데  거미는 곤충이 아니구나..라고 구분지을 수 있는거죠.
여기까진 문제가 없습니다. 그런데, 생각해보면 잠자리하고 일개미는 같은 곤충일 뿐 완전히 생긴것도 다르고, 하는일도 다르고, 사실상 그닥 비슷한 면도 없습니다. 단적으로 잠자리는 날아다니는데 일개미는 못날잖아요 ^^;;
이런 차이점에 대해서는 일일이 '개미'와 '잠자리'의 특성에 대해서도 기억을 해야 하기 때문에 다 기억을 못하기 십상입니다. 게다가 개미는 여왕개미와 수캐미와 일개미는 생긴모양 자체가 다르기 때문에 더 헷깔리기도 하죠. 오히려 수캐미는 일개미보다는 벌에 더 가깝게 생겼거든요.
이렇게 뭉뚱그려버리면 기억하기는 쉽지만 세부적인 것은 구분 할 수 없는 '추상화의 함정'이 생겨버립니다.
한번 사이즈를 줄여버린 픽셀 방식의 그림은 다시는 크게 만들 수 없듯이요.




반복이라는 건 말 그대로 한번에 기억하지 못하는 것을 여러번 보면서 기억하는걸 말합니다. 중고등학교 시절에 단어장 외우던 기억 있으시죠? 자동차를 'Car' 라고 부르는 것은 아무리 생각해도 추상화 시킬 수 있는 부분이 없습니다. 왜 이렇게 불러야 하는지 모르는거에요. 추상화로 할 수 있는 것은 기껏해야 Car의 Type은 Truck, SUV .. 등이 있다.. 정도죠. 이렇게 하나의 개체에 대해서 추상화를 시킬 수 있는 부분은 한계가 있기 때문에 끊임없는 반복으로 이것을 뇌리에 박아둡니다. 우리의 뇌는 대뇌피질에 뉴런의 결합작용으로 기억을 하는데, 반복할수록 뉴런의 결합작용이 강해져서 더 오래 기억하거든요. 반면 뉴런은 자극이 없으면 서서히 그 연결고리가 느슨해집니다. 다시 말하면 끊임없이 자극을 새로 해 주지 않으면 잊어버린다는 소리죠.




그래서 우리는 이야기라고 불리는 '흐름'에 의존해서 기억을 되살립니다. 즉 각 기억사이에 연관관계를 가져가는 겁니다. 고등학교 역사 수업이 지리 수업보다 기억하기 쉬운 이유는 흐름이 있기 때문입니다. 예컨데 고구려와 백제가 신라에게 멸망되었기 때문에 통일신라가 되었다. 라는 식으로요. 반면 지리는 그런 연관관계가 전혀 없습니다. 코스타리카 공화국 옆에 '니카라과'와  '파나마' 가 있다는 건 어떤 연관관계도 없죠. 그냥 우연히 옆에 있는 나라 이름인 겁니다. 이런건 기억을 이어붙이기 힘들어요. 우리나라 옆에 일본하고 중국이 있다는건 오랜 반복학습의 결과이기도 하지만, 한국 일본 중국은 예로부터 서로 관련되어 왔었고 영향을 주고받았기에 서로간에 이야기가 생겼고, 그 결과 기억하기 쉬워졌죠.
이야기의 단점은  흐름은 오래 기억되는 반면 이야기에서 부각되지 않은 곁가지 기억들은 모두 소멸한다는 겁니다. 혹시 백설공주에 나오는 난장이 이름 아시나요? 난장이의 이름 따위는 공주가 왕자님 만나는 흐름하고는 아무 관계도 없기 때문에 아무도 기억 못합니다.




저도 모르겠습니다(...) 그냥 기억에 대해서 적어보고 싶었어요.

저는 개인적으로 시간관리에 상당히 관심이 많습니다.적게 일하고 많이 벌어 리치왕이 되자는 욕망에도 충실한 편이고요.  그러다보니 시간관리에 신경을 쓰게 되죠.

시간관리라고 하면 뭐가 생각나시나요?
프랭클린 플래너? GTD?

프랭클린 플래너나 GTD가 추구하는 바는 모두 동일합니다. 바로 시간을 효율적으로 써서 여유시간을 가지자는 거죠. 다만 접근하는 방법이 프랭클린 플래너쪽은  커다란 방향을 잘 정하자..로 시작하는 반면 GTD는 빨리 해치울 수 있는 건 빨리 해치우자..정도만 다르군요.

반면 이 책이 주장하고 있는 바는, 목적은 같지만 방법은 조금 다릅니다. 뭐라고 딱 이름붙이기 어렵기는 한데.. 방향 자체는 프랭클린 플래너쪽에 가깝네요.




책은 꽤나 두꺼운 편입니다. 저는 책을 읽을때 먼저 총 몇페이지 정도 되나 보고, 목차를 훑어봐서 개요를 파악한 다음, 슥슥슥 넘겨서 일단 훑어보고, 다시한번 돌아와서 첨부터 다시 슥슥슥 보면서 눈에 띄는 부분에 좀 더 집중하고..하는 식으로 보는 편이라서 책 페이지에 민감합니다. 그리고 이런식의 방향제시서적들은 핵심을 얇게 간추려야지 두꺼우면 죄악이라고 생각하기 때문에(...)
총 416페이지군요.





목차만 봐도 기가 질린다고요? 문제없습니다. 왜냐하면, 잘 나온 책이 대부분 그렇듯이, 목차가 사실상 모든걸 말해주기 때문입니다. :)

아주 간단하게 요약해보면, 우리는 모두 시간에 치여 살아가고 있고, 언제나 시간은 모자랍니다. 왜일까요? 그건 우선순위를 정하고 아니고의 문제도 있지만, 해야 할 일의 본질을 꿰뚫어보지 못하고 허둥지둥하고 있기 때문이기도 합니다. 이렇게 해야할 일의 본질을 꿰뚫어본다는건, 다르게 말하면 나를 도와주는 사람 혹은 기계를 옆에 두고, 전체를 파악해서 흐름을 압축해서 해치워버리는걸 말하는거죠. 이렇게 시간을 압축해서 쓰는 방법으로 일처리를 하고 나면, 남은 시간은 당신의 것입니다! 정도겠네요.




개인적으로는 전작인 단순하게 살아라 는 못읽었습니다만, 사실 뭐 굳이 읽을 필요성도 못느낍니다. 제목이나 알라딘에서 훑어본 내용으로 봤을때는, 빈둥거리는 것이 더 효율적으로 일하는 방법! 이라는 방법론을 제시한 책이라고 생각되니까요.

오히려 비슷한 책으로 4Hour 라는 책이 있습니다. 국내 이름은 4시간이군요. 이름은 좀 손이 안가는 제목이기는 하네요 ^^;,  판매부수가 어느정도 되는지는 모르겠으나 우연히 도서관에서 집어들었는데.. 참 괜찮다는 생각이 들더군요. 이 책은 일주일에 4시간 정도 일하기..라는 방법을 말하고 있습니다. 상징적인 의미가 아니라 말 그대로 일주일에 4시간 일하기에요. 허무맹랑한 소리는 아니고, 어느정도 합리적인 부분도 있어요. 게다가 자신의 경험을 바탕으로 한 것이라서, 은근슬쩍 멘토의 느낌도 띄는군요. 책의 키포인트는 로버트 기요사키의 부자아빠 가난한 아빠와 비슷하게 시스템을 만들어놓고 남들이 일하게 시켜라..정도입니다.

가장 위에서 언급한 프랭클린 플래너..는 스티븐 코비 박사의 성공하는 사람의 7가지 습관이라는 책에서 나온 방법론입니다. 워낙 유명한 책이라 많이들 읽어보셨을꺼라 믿지만, 혹시라도 아직 안읽어본 분들은 읽어보셔도 좋습니다. 내용이 좋고,디테일한데다가 어느정도의 방향성을 제시해 줍니다. 많은 사람들의 인생을 바꿨죠.

GTD에 대한 책을 원하신다면 물론 데이비드 알렌 박사가 제일처음에 주창한 책을 추천합니다. GTD라는 원리 자체가 이 책에서 나왔으니까요.  국내 이름은 끝도없는일 깔끔하게 해치우기..군요. 걸리는 시간별로 일을 분배해서 해치워라..라는 내용입니다.

여담이지만 전에 리뷰해둔 [RL.R ead] - 머리가 좋아지는 1분 공부법. 정확히 1분을 투자할 가치가 있는 책. 과의 연장선상에도 있네요. [RL.R ead] - 정보 정리의 기술. 184페이지를 두쪽으로 요약해보면 도 마찬가지고요.




빈둥거려라. 단, 그냥 빈둥대지 말고, 효율적으로 일을 정리해서 처리하고 빈둥거려라. 그리고 남은 삶을 즐겨라 정도 되겠네요.

여기저기 찾아봐도 코어 OS 레이어인지 어플리케이션 프레임워크 레이어인지 단순히 UI레이어인지 알수가 없어서 바다 공식 홈페이지를 찾아봤다.

영어로 되어있다 -_-;
어쩔수 없이 발번역을 하기로 했다.


그런데 이것만 봐서는 여전히 뭔지 알 수가 없다.



그래서 나보다 먼저 분석해 둔 분들이 있을꺼라 생각하고 웹서핑을 시작한다.


※ 삼성전자, 독자 스마트폰 OS '바다' 공개에 보면 바다는 그냥 완전히 Low Level OS라고 설명되어 있다. 즉 기존에 피쳐폰에 들어가던 RTOS를 업그레이드한 버전이라는 것이다.

※ 바다 OS가 Nucleus RTOS 기반인가요? 라는 다음 지식에서도 같은 답변이 나온다. 여기서는 멘토그래픽사에서 상용 RTOS 로 출시한  Nucleus 를 기반으로 설계되었고, 여기에  touch with frame work라는 UI를 입혀서 나온것이 바다라는 것이다.

※이건 그저 UI 레이어라고 말씀하시는 분도 계셨다.
삼성의 Bada 플랫폼 vs 노키아의 QT 플랫폼 - 삼성의 바다 플랫폼에 대한 이해 #bbuser #bada

※안드로이드 펍의 삼성 바다 웨이브 S8500 사진, 스펙 및 동영상  이라는 글의 댓글에 보면 머리에 꽃을 님이 작성하신 질문이 나오는데.. 은근히 묻혀버렸다(..)
그리고 그 아래에 시나브로님께서는 모바일 기기용 통합 UI플랫폼 이라고 말씀해 주셨다. 즉 커널이 무엇이든 관계없이 UI측면을 동일하게 가져갈 수 있다고 친절하게 부연설명까지 붙여 주셨다.
역시 하단에 madhatter님께서는 조금 다른 의견을 말씀해 주셨는데, 여기에 좀 주목해야 할 점이 있다.

일단 강조해두고 아래에서 다시 분석해보자.



코어 레이어든, 디바이스 레이어든, VM 레이어든, UI 레이어든 사실 사용자 입장에서는 별 관계가 없다. 다만 이걸 개발하고 판매하는 사람 입장에서는 이 바다에 뛰어들만한 가치가 있느냐를 판단해야 하는 거라서 , 큰 관계가 있다.

이게 코어/디바이스 레이어라는 것은 , 하나의 핸드폰에 바다 OS만 올라갈 수 있다는 의미다. 즉, 아이폰에 Iphone OS만 올라가고, 갤럭시S에는 안드로이드만 올라가는거랑 똑같다는 거다. 바꾸어 말하면, 아이폰 어플을 갤럭시에서 못쓰듯이 그 OS에 맞는 어플만 쓸 수 있다는 의미다.

그게 아니라 UI 레이어라면, 바다 OS는 사실상 OS가 아니라는 뜻이 된다. 예를 들면 햅틱에도 햅틱 UI가 들어가고, 옴니아에도 햅틱 UI가 들어간다. 그렇다고 해서 햅틱하고 옴니아가 같은 OS를 쓰는것은 아니지 않는가? 어디까지나 햅틱은 피쳐폰이고, 옴니아는 (WM을 탑재한) 스마트폰이니 말이다.

만약에 이것이 미들 프레임워크 레이어라면 이야기는 전혀 달라진다. 그러니까.. 만약에 바다 OS가 자체적인 RTOS 기반으로도 작동되고, 안드로이드 위에서도 작동되고, 아이폰 위에서도 작동되고(이건 애플이 허락을 해줘야 해서 해줄지 모르겠다) 한다면 어떻게 되는걸까?
사용자는 안드로이드 어플과 바다 어플을 동시에 사용할 수 있게 된다.
이런식으로 가상머신위에서 실행되는 것은 의외로 데스크탑쪽에는 많다. Virtual Machine이라고 하니까 Virtual PC나 VM웨어를 사용해서 완전히 다른 OS를 띄운다고 상상하기 쉬운데, 실은 그냥 프로그램을 실행시키기 위한 레이어가 하나 더 있는거다. 대표적인 것이 .net Framework와 JavaVM이다. 이것들은 이 프로그램 자체로 순수한 가상머신을 구현하고, 그 가상머신이 진짜 가상머신과 통신하는 구조다.



먼저 본인이 그림판 신공을 통해  성심성의껏 그린 아래 그림을 한번 보자.

만약에  갤럭시의 새 버전인 안드로메다(...) 에 위와같은 구조가 올라간다고 생각해보자.
기반은 안드로이드로 만들고, 그 위에 바다 OS가 올라간다. 그럼 안드로메다는 안드로이드 기반 어플인 카카오톡 같은것도 잘 되고, 바다 특유의 어플리케이션인 '저행성 끝까지(가칭)' 도 잘 실행된다. 게다가 굳이 뻣뻣한 안드로이드 OS를 튜닝할 필요 없이, 바다 위에 UI 레이어를 올려버리면 훨씬 포팅도 간단해진다. 그리고 바다 OS는 VM 기반이기 때문에 (정확히 말하면 그냥 안드로이드 어플리케이션 중 하나기 때문에) 안드로이드가 아닌 그냥 '웨이브' 폰 위에 바다 OS를 올려도 바다 특유의 어플인 '저행성 끝까지'는 잘 실행된다는 얘기다.

이 이야기는 개발자나 마케터들에게도 꽤나 중요한 이야기인데, 바다 OS까지 올라간 폰이라면 선택의 폭은 두배가 된다. 사용자에게 어필할 포인트가 많아진다는 면에서는 마케터에게 유리하고, 한번 만들어놓으면 어떤 스마트폰이든 바다가 채택된 폰의 경우 무조건 실행된다는 점을 보장한다는 면에서는 개발자들에게 유리하다.




바다 공식 홈페이지의 EcoSystem 항목을 보면 이런 그림이 있다.

그림은 뭔가 오묘해 보이지만, [RL.M arketing] - 윈도7폰. 진짜 망할까? 에서 말했던 선순환 구조를 나타낸 것에 불과하다. 다시한번 기술하자면 폰이 팔린다 -> 어플을 만든다 -> 어플 쓸라고 또 폰이 팔린다. .. 라는 것이다.

즉, 여태까지 삼성은 전화기 판매 수익으로만 돈을 벌었다. 어플리케이션이 많이 사용되면 전화기가 많이 팔리니 그건 좋겠다만, 그 외에 추가적인 수입은 없었단 얘기다. 그런데 가만히 보니 이거.. 꽤나 돈이 될 것 같다. 그래서 어플리케이션 시장을 우리도 한번 시작해보자..라는게 이 바다 OS다.




삼성 '바다'를 처음 채용한 폰. 'Wave(S8500) MWC에서 첫 공개! 삼성의 저의는? 이라는 글 하단에 보면 삼성은 '피쳐폰같은 스마트폰'을 만들고자 했다는 단락이 나온다. 또한 이러한 시선은 삼성 피쳐폰에 바다OS 탑재계획은 탁월한 선택! 이라는 껍데기님의 글에서도 같이 느껴진다.

그렇다. 삼성이 하면 쉽다. 왜냐하면 삼성은 세계에서 굴지의 핸드폰 업체기 때문이다.
아무리 삼성이라고 해도 완전히 새로운 시장을 파고 들어가는건 어렵다. 아직은 포화상태가 아니어서 시장의 틈바구니를 만들어야 하는 스마트폰 시장에서 이미 아이폰과 안드로이드는 절대 강자로 싸우고 있다. 여기를 억지로 비집고 들어가는건 쉬운일이 아니지만, 삼성 브랜드를 달고 나오는 모든 폰에 바다 OS가 기본으로 깔린다면 이야기는 달라진다. 피쳐폰이건 뭐건간에 모든 핸드폰은 OS가 설치되어 있기 때문이다.

혹시 LG에서 나왔던 맥스라는 폰 기억하는가? 그냥 피쳐폰이었는데도 불구하고, 어플리케이션을 설치할 수 있었다. 그런데 어플리케이션 SDK가 공개되어 있지 않아서 모든 어플을 한 업체가 다 만드는 바람에 숫자와 호환성의 한계에 부딛혀 말아먹었다(...)
다행히 바다폰은 이럴일은 없다. SDK도 열려있고 (개발하기 쉽든 어렵든 간에) 뭔가 외부업체에서 개발을 할 수는 있는 것이다. 문턱이 높다낮다와는 다른 문제겠지만..


바다폰 혹은 바다 OS는 어떻게 보면 iPhone보다 더 쉬운 피쳐폰 같은 스마트폰을 지향한다. (피쳐폰에 어플 깔 수 있으면 그게 스마트폰이지 뭔가..) 고로 피쳐폰만큼 저렴해야 하며, 그렇다고 어플의 질이 떨어져서도 안된다.
삼성이 교훈삼아야 할 부분이 하나 있다. 바로 노키아다. 노키아는 아이폰이 나오기 한참 전부터 심비안 플래폼을 만들어왔고, 바다와 똑같은 전략을 펼쳤다. 말이 심비안 플래폼이지, 심비안은 그 버전이 엄청나게 많다. 노키아는 하이엔드 핸드폰부터 초저가형까지 모두 심비안을 집어넣어서 팔았었다.  그런데 지금, 왜 노키아는 망해가고 있는가?

이 답을 찾지 못하면, 바다도 망한다.



덧.
다행히도 유럽에는 잘팔리고 있다고 한다.

덧2.
옥션에 봤는데 웨이브폰을 4.5만원짜리 지정요금제를 다음달 말까지 유지하는 조건으로 그냥 주고 있다. 이정도면 꽤나 경쟁력 있는 가격으로 나온듯.

[RL.Application] - DE File Numberer. v0.1. 파일명을 일괄로 바꿔주는 프로그램.
을 만들면서 느꼈던 것들입니다.












뭐가 이리 오래걸린걸까요?





완전 초 단순한 프로그램이라서 만드는데 별로 안걸릴 줄 알았습니다.



그리고 제가 가장 익숙하게 다루는 언어가 c#이라서 이걸로 뚝딱뚝딱 만들었죠.
프로토타입이 만들어질때까지 약 1-2시간정도 걸렸습니다.



그랬더니 바로 두가지 문제를 지적당했습니다.

2.1. 저 선택취소 버튼이 뭘 의미하는가?
선택취소 버튼을 누르면 어떻게 되냐고 묻더군요.
그 래서 선택취소 버튼은 말 그대로 이미 리스트에 올라가있는 파일들을 다 지워버린다고 말해줬습니다. 그랬더니 파일들을 체크박스로 선택하고 그 선택된것만 지워버리는게 어떻냐고 피드백을 줘서, 그렇게 고쳤습니다. 이렇게 뜯어고치는데 한시간 정도 더 소요됐고요.

2.2. 이 간단한 프로그램을 돌리는데 왜 1G 남짓이나 되는 프로그램을 설치해야 하는데?

 닷넷 프레임워크는 인터넷에서 다운받아보면 약 1G 조금 안되는 용량을 가지고 있습니다.
그런데 제가 생각해도 막막한 겁니다. 도대체 왜 이걸 돌리는데 닷넷 프레임워크를 깔아야 한다고 설명할 수 있을까. 프레임워크 레이어라서 사실상 필요한 라이브러리가 다 그안에 들어있다..라고 말해줘야 하는데, 깊이 들어가다보면 설명이 너무 복잡해지더군요.



그래서 다른 언어로 다시 짜야겠다고 생각했습니다. 최소한 복잡한 닷넷 프레임워크 필요없이 간단하게 동적 DLL링크시키는 방식으로요.
뭘로 짤까 고민좀 해봤습니다. 그리고 목록이 쭉 나왔죠.





Python으로 실제로 파일을 불러오고 변경시키는 논리 자체는 어렵지 않습니다. 오히려 C#에서 사용하는 제네릭 형식을 훨씬 편하게 쓸 수 있고, 제가 즐겨 사용하는 리스트 형식이 내장되어 있어서 프로그램을 개발하는데 편리하죠. 동적 언어의 특성때문에 조금 느리기는 하지만, 이 간단한 프로그램에는 별 상관없을꺼라 생각했습니다.

그런데 문제가 하나 생깁니다. 바로 괜찮은 IDE가 없다는 거죠. 저는 4GL 형식의 아주 심플한 화면 구성이 필요했습니다. 일일이 Tkinter 를 코드로 치고싶지는 않았어요. 간단하게 만들 수 있는거면 간단한게 최고다..라는 주의라서,  괜찮은 IDE가 있나 찾아봤습니다.

4.1. Boa-Constructor

이거야 됐어! 라고 생각했지만.. 왠지 모르게 작동하지 않았습니다(...)
BOA는 설치파일 형식으로 배포는 되지만, 실제 실행은 Lib 폴더 안에 들어가서 boa.pyw 을 실행해야 하는 형태입니다. 그런데 왠지 모르게 IDE만 뜨고 보아 자체는 전혀 실행되지 않았습니다. 그리고 Reference 를 영어로 봐야하는 압박 귀찮음도 있었고요.
물론 공식 그래픽 라이브러리인 Tkinter가 아니라 WxPython을 사용하는 거라서 바게님의 포스트를 참고하여 PyWin을 설치했습니다. wxPython은 python 3.1용 버전이 릴리즈된게 없어서 일단은 py27버전을 설치했고요. (이게 문제인지도..)
여하튼 되지 않습니다. 봵!

4.2 PythonCard

 PythonCard는 제가 원하는 모양이 아니라서 포기.

4.3. KomoDo

ActiveState사의 KomoDo는 유료라서 포기 ($382 = 2011.02.23일 오후 4시 기준 428,604 원..)




Small Basic은 예전 GW-Basic의 추억을 생각하며 그냥 막코딩해볼까 하고 찾아봤습니다만, 그래픽 라이브러리는 있는데 너무 제한이 많고.. GOTO 문이 난무하는걸 보면서 포기...
게다가 재미있는 게, Small Basic은 퍼블리싱을 할 경우 Visual Basic .net 으로 자동으로 코드를 바꿔줍니다. 결국은 스몰 베이직도 닷넷 프레임워크가 실행시에 필요하단 얘기죠.

FBEdit 는 FreeBasic 이라는 Quick-Basic의 추억을 되살리면서 만든 베이직 컴파일러의 IDE입니다. 현재 FreeBasic 프로젝트 자체는 정체 상태입니다만, 이미 완성도가 높아질만큼 높아졌으므로 그냥 써보기로 했습니다. 언어에 최소한 프로시져랑 함수 정도는 있더라구요.
FBEdit 외에 FBIDE 프로젝트도 있습니다만... 만들다 만건지.. 사이트가 엉망이길래 포기.


그런데.. 이게 ... 너무 MFC 방식입니다.
윈폼 개발시에 C++ 로 하는것처럼..  보라 윈폼이 시작할때 파라미터의 포인터 난무를....
처음부터 C++ 로 만들 생각을 안했던게, 너무 귀찮고 복잡하거든요. 논리를 세우는데 집중할 수 있는게 아니라, 컴퓨터가 어떤식으로 동작하는지를 먼저 머리속에 그리고, 그다음에 논리를 세워야 하는데.. 이걸 가능하면 피하고 싶었습니다.

Lazarus는 Delphi의 오픈소스 구현입니다. 정확히 말하면, 위에서 말한 FreeBasic과 FBEdit의 관계처럼 FreePascal이라는 Object Pascal의 오픈소스 구현이 있고, 그 위에 Lazarus라는 IDE가 올라가는 형태입니다.

한때는 시대를 풍미했던 터보 파스칼의 기억을 되살려가며 한번 해보려고 했습니다만..
이게 IDE 기능 자체는 놀랍도록 좋습니다. 구현체 자체는 Delphi 2005랑 상당히 비슷하게 되어 있고, 기능도 훌륭해요. 인텔리센스도 잘 먹습니다. 그리고 4GL시대에 (한때는 Visual Basic과 어깨를 겨루었던) 맞춘 기능을 모조리 구현해놨습니다.
조금 특이한 것이, 각각의 창이 둥실둥실 떠다닙니다. 그러니까, 소스코드창은 소스코드창대로, Object Inspector 는 Object Inspector 대로, 디버거는 디버거대로 떠다닙니다. 위치를 잘 맞춰주지 않으면 어느순간 소스코드창에 가려져서 디버그 트레이스가 사라져 버립니다 (...)

이걸 포기한 이유는 두가지인데요.
하나는 디버깅 트레이스에서 조사식을 찍어보면, Object의 Property 와 Method 목록이 펼쳐지지 않아요. 저는 개체 하나의 값이 전체적으로 어떻게 변하나를 조사식으로 일일이 찍어보는 버릇이 있는데, 이게 힘들더군요.
다른 하나는 파스칼 언어 자체의 한계입니다. 이걸 한계라고 해야 할 지는 모르겠는데, C언어 계열에서는 각 변수가 컨텍스트 안에서만 존재한다는 규칙이 있습니다.
예를들면

여기서 BeginNumber는 For 문 밖에, innerVar 변수는 For문 안에서만 존재하는 변수죠.
그런데 파스칼은 이게 안됩니다. 모든 변수는 프로시져(혹은 메서드) 시작점에서 정의되어야 합니다. 즉, 각 변수는 필요한 컨텍스트가 있는데, 이걸 지정하는게 안되더군요.

그래서 또 포기.

드디어 대망의 Visual Basic입니다.
4GL 시대를 주름잡았던 툴이죠. 그리고 많은 초보자들을 프로그래밍의 세계로 이끌었던 툴이기도 합니다.
사실 Visual Basic 언어 자체가 그리 잘된 언어는 아닙니다만.. 언어에 비해서 IDE 수준은 높은 편이고, 필요한 기능을 COM 을 통해 아주 쉽게 확장할 수 있다는 면에서 너무 좋더군요. 여하튼 저는 원하는것만 할 수 있으면 되니까.. 라고 생각하고 대충 다 만들어 놨었습니다.
리스트 구현체가 동적 배열을 끊임없이 Allocation해야 하니까 불편하긴 한데, 이건 뭐 그냥 그럭저럭 쓸만하니까 무시했습니다.

그런데 이게 결정적으로  파일을 읽어들이는 CommonDialog 와 File Rename 하는 부분에서 버그가 있는 겁니다. (...)
처음에 파일 목록을 CommonDialog로 읽어들일때는 아무 문제가 없지만, FILE A as B로 파일 이름을 한번 바꾸고 나면 문제가 생깁니다. CommonDialog에서는 파일이름이 변경되었다고 나오는데, 실제로 탐색기에서 체크해보면 전혀 안바뀌는겁니다. (-_-)
제가 잘 몰라서 그러는건지, 아니면 NTFS 시스템상에서 제대로 작동을 안하는건지, 아니면 제가 패치를 안받아서 그런건지는 모르겠는데... 어쨌든 안됩니다.

게다가 이미 버림받은 언어기 때문에 (더이상 제품군 출시가 안돼죠..) VBA로만 살아남은듯하고요.




그래서 개발 툴을 약 열개를 깔아보고 테스트해보고 만들어보고 하다가 위에 언급했던 한계들로 인해 결국 포기하고 c#으로 만들수밖에 없었습니다. -_-
이과정이 약 13일 걸렸군요.
나머지 하루 정도는 테스트하고 간단한 설명글 넣고 하는데 투자했습니다. 뭐 프로그램 자체를 만드는 시간은 약 3시간 정도였고, 테스트하는데 그것보다 오랜 시간이 걸렸으니 TDD 가 되는건가요 (...)






그런데 다 만들어놓고 릴리즈해놓고 나니 이런 생각이 문득 듭니다.
지금은 사장되어 버린 툴을 쓰던 사람들은 다 어디로 갔을까.. 새로운 길을 찾아 VB.NET으로, 혹은 다른 언어를 선택했을까. 관리자로 변신했을까. 아니면 이바닥을 은퇴했을까..

IT는 정말 무섭도록 빨리 변화합니다. 하루밤만 지나고나면 신기술이 나와있고, 무슨 방법론이 이리 쏟아져 나오는지 이제는 이름도 못외우겠습니다. 과거에는 네트워크 컴퓨팅이라고 불리던게 뜬금없이 클라우드라는 이름표를 달고 나와서는 신기술이 되어버리고, 미묘한 부분만 바뀐  프로토콜은 이게 최고라고 선전합니다.

프로그래밍 언어는 (요새는 좀 덜합니다만 ) 여전히 마이너리그에서 미친듯이 쏟아져나오고 있죠. Rails가 유행할때는 모두가 루비를 할 줄 알아야 했고, 와우에 Lua가 쓰였다고 하니까 게임기획자들의 필수언어가 되어버렸던 기억이 있네요. (지금도 그런가요?)

ORM이 유행할때 자바 개발자들은 Hibernate 정도는 할 줄 아는게 기본이어야 했고 .net 쪽은 ado.net에 덧대어 Linq를 쓸 수 있어야 했죠. (공부할 시간은 대체 언제...)


게다가 웃긴게 이제는 다시는 사용하지 않을꺼라던 언어를 유지보수 과정에서 써야 할 일도 생깁니다. 멀리 볼 것도 없이 Y2K 사태 기억하시나요? 갑자기 Cobol 프로그래머 단가가 상상을 초월하게 올라갔었죠.


문득 생각합니다.
신기술이 나오는 건 좋고, 우리 (개발자)들의 삶을 편안하게 해주려는 목적은 잘 알겠지만, 이게 정말 나를 편안하게 해주는 길일까..하고요.


긴글 읽어주셔서 고맙습니다.

비관적인 전망이 산처럼 나오고 있습니다.
플래폼은 나왔지만 점유율이 바닥을 기는데다가 나오는 폰들은 아얘 화제도 안되고 있는 형편이죠.
현재 경쟁자라고 할 수 있는 아이폰이나 안드로이드 쪽은 거대한 소재거리도 없는 측면인데도, 끊임없이 양산되어 나오는 포스팅은 각 플래폼의 어플 소개 혹은 새로운 갤럭시 플레이어가 나왔네.. 정도일뿐 윈도 7폰은 아웃 오브 안중인 상황이죠.




많은 사람들이 생각하는 것과는 다르게, 어플리케이션의 부재는 생각보다 금방 채워집니다. 앱스토어가 있는 애플이나 안드로이드가 그렇듯이, 선순환 구조만 만들어지면 됩니다. 즉, 폰이 팔린다 -> 시장을 보고 개발 업체가 뛰어든다 -> 어플을 쓰기 위해 폰이 팔린다. -> ... 무한 반복
이 형태만 되면 되는거죠.

처음에 아이폰이 출발했을 때 앱스토어의 어플 갯수는 고작 550개였습니다. 그런데 지금은 100억 다운로드가 넘어갔죠..
원문 : Ten billion downloads and counting: The history of Apple's App Store, and its all-time top apps
한국어 : 앱스토어의 역사와 백억번!!의 누적 다운로드





간단합니다. 딱 두가지만 있으면 되요.
하나는 훌륭한 개발 환경이 있는가.
다른 하나는 윈도폰 시장이 돈벌이가 될만한가.

첫번째는 이미 만족한듯합니다. 이미 Window Mobile(WM) 계열과는 다르게 개발 도구를 무료로 MS에서 배포하고 있고 (Visual Studio Express )
개발을 위한 도구 자체는 안드로이드 개발 플래폼인 이클립스보다, 아이폰 개발을 위한 XCode보다 훨씬 훌륭합니다. 그리고 MSDN이라는 상상을 초월하게 좋은 API 메뉴얼도 있죠.
물론 코드만 실컷 쳐서 개발이 끝나는게 아니기 때문에 .. 디자이너를 위한 자원이라던가 혹은 기획자들을 위한 자원도 필요합니다. 이들의 연동도 필요하고요.
그러기 위해서.. 윈도폰은 SilverLight를 통한 개발도 지원합니다. SilverLight 개발 플래폼은 디자이너를 위한 Expression Studio를 지원하는데요. 여기에는 일러스트레이터와 엄청 비슷하게 생긴 Expression Design이라던가, 플래시와 비슷한 Expression Blend라던가 하는 것들이 포함되어 있습니다.

두번째가 가장 사람들이 꺼려하는 부분일텐데, 이게 과연 돈벌이가 될만한 시장인가.. 에 대해서 가늠을 해봐야 하죠.




현재 앱스토어에 등록된 어플 갯수는 2011년 1월 22일 기준 약 35만개, 안드로이드 마켓에 등록된 갯수는 약 20만개입니다. 이중에서 최소한 TOP 100 안에는 들어야 사람들이 이것에 대해서 최소한 '인지'는 할 수 있는 수준이 되죠.

마치 서부시대에 사람들이 우우우 달려가서는 이땅은 내꺼 하고 깃발꽂으면 내꺼가 되는 시스템같네요. 그만큼 오히려 시장은 열려있고 진입장벽이 낮다는 말도 되죠.




그럴수는 없죠. 현재 망한 플래폼이라고 인정받는 WM 시장도 어플리케이션은 있습니다. 그것도 상상하는 것보다 '훨씬 많이' 있습니다. 자그마치 2000년부터 시작된 플래폼인걸요.
다만 이것이 널리 퍼지지 못했던 이유는 , 그당시만 해도 무선인터넷이라는건 정말 돈많은 사람들의 사유지였으며, 어플리케이션이 '인터넷'을 통해서가 아니라 독립적으로 실행되는것이 대부분이었던 부분과, 이러한 어플리케이션들이 한군데 모여있는게 아니라 '능력껏' 구해야 하는 시스템이었던 때문입니다. 결국 데스크탑과 완전히 동일하게 배포한 어플리케이션들이 문제가 되었던 거죠. 애플은 이런점을 깨달았고, 결국 앱스토어를 런칭합니다. 얼마전에는 맥스토어도 런칭했죠. (여담이지만 맥스토어는 그다지 색다르지는 않더군요.. 보통 사람들이 말하는 앱스토어의 맥킨토시 판이라기보다는, 우분투 소프트웨어 센터가 생각나더라고요. 다만 우분투는 리눅스 배포판이기 때문에 사람들이 돈주고 뭔가 사는걸 되게 싫어하는 편이고, 그래서 결제 절차같은건 없습니다. )




도스 플래폼이 갑자기 뜬건, 도스가 훌륭해서가 아니라 최초의 스프레드 시트라 불리는 로터스123이 있었기 때문입니다. IBM이 아무리 하드웨어를 잘 만들었어도 이걸로 뭔가를 할 수 없다면 그 기계는 글러먹은거죠. 그거랑 똑같은겁니다.
현재 윈도7폰에서는 소셜 허브 전략을 펼치고 있는데요.. 사실 이건 잘못된 선택이라고 생각합니다. 소셜 허브 전략 자체가 나쁘다는게 아니라, 이건 아이폰이건 안드로이드건 다 할 수 있는 겁니다. 오히려 플래폼 벤더들이나 개발회사들은 더 많이 팔리는 플래폼에 배팅을 하고 싶어하지, 누가 살지 아무도 모르는 윈도폰에 배팅을 하고 싶어하지 않습니다.
림의 블랙베리가 왜 많이 팔렸는지 기억하시나요? 림의 블랙베리는, 비지니스맨들을 위해서 푸시메일이라는걸 처음 지원했습니다. 그리고 키보드가 달려있어서 외부에서도 언제든지 이메일을 통한 의사소통을 원활하게 만들었죠. 마지막으로 림에서 관리하는 보안으로 내부관리를 했죠.
그런데, 이 기능을 아이폰도, 안드로이드도 지원하기 시작한 겁니다. 림의 유일한 장점은 사라졌고, 시장은 냉혹해서 점유율은 날로 떨어지고 있습니다.

다시 킬러 소프트웨어 얘기로 돌아와보면, 기존에 WM에 있었던 킬러 소프트웨어들은 대표적으로 ListPro라던가, 혹은 MDict라던가 하는 것들이 있습니다. ListPro는 데이터를 관리하는 툴이고, MDict는 사전 툴입니다. 이게 아직 안드로이드나 아이폰으로 없어서 못넘어간다는 분들도 계시더군요. 이런게 터지는 순간, 선순환은 시작됩니다.

마치 '카카오톡 써?'라는 말로 아이폰이나 안드로이드를 구매하는 것처럼요 :)




사람들은 아이폰과 WP7을 비교하면서 자꾸만 UI가 달라졌다는 이야기를 합니다.
핵심은 그게 아니라, 이 똑똑한 전화기가 무엇을 할 수 있느냐죠.
UI를 이쁘게 만드는건 역대 모든 기업상 애플이 제일 잘하고 있습니다. 디자인에 사람의 감성을 담고 있죠. MS가 그걸 모르고 있을 리도 없고, 굳이 그걸로 경쟁하고 싶지도 않을겁니다. 다만, 아이폰의 UI를 그대로 가져간다면 MS표 아이폰 짝퉁밖에 안되기 때문에 멋진 UI를 새로 만들어낸겁니다.

구글이 안드로이드 플래폼을 만들면서 가장 중요시했던 것이 '사용자 경험'이 아니라, '어떻게 하면 구글 서비스를 가장 현명하게 팔아먹을까'입니다.
즉, 구글의 사업모델인 '광고'를 어떻게 하면 많이 많이 보이게 할 수 있을까.. 그러기 위해서는 사용자들이 구글의 서비스에 익숙해져야 한다. 익숙해지기 위해서는 항상 소지하고 다니는 핸드폰 플래폼을 노리는 것이 어떨까..에서 시작한게 안드로이드죠.

크롬 OS도, 크롬 브라우져도 마찬가지입니다. 파이어폭스는 따로 검색창이 있는데 크롬은 그런것도 없죠. 특별히 불편한 설정을 하지 않으면 무조건 구글에서 찾습니다.
그런데 찾는 항목에 따라서 구글이 잘찾는게 있고, 네이버가 잘찾는게 있고 (카페글이라던가)
다음이 잘찾는게 있죠. (대표적인게 지도.) 이걸 무조건 구글 서비스로 일원화시키는겁니다. 그리고 igoogle을 통해서 개인화 서비스를 하고, 클라우드 컴퓨팅이라 거창하게 이름붙인  모바일과 데스크탑의 사용자 경험 일체화를 통해서 구글에 사용자들을 종속시키겠다는거죠.


윈도폰에서 주목해야 할 UX의 변화는, 아이콘이냐 밀어서 컨트롤하냐의 차이가 아닙니다. 어떻게 작동하는 것이 자신들의 플래폼 목적에 부합하는가..를 생각해야죠.
MS는 동시에 두마리의 토끼를 노리고 있습니다. 하나는 기존의 WM 시리즈와 같이 OS 의 리테일을 통한 이득, 그리고 다른 하나는 Bing이라는 검색엔진을 위시한 개인화 서비스.
사실 여태까지 MS의 개인화 서비스 수준은 엉망진창이었습니다만, 이제는 서서히 달라질 겁니다. 뭐니뭐니해도 익스체인지 서버라는 단단한 기술력이 있고, 세상에서 가장 돈 많은 기업이라는 든든한 후원자가 있으니까요.
그런데 저는 아무리 생각해도 밀어서 실행시키는것과 검색엔진이나 다른 서비스들과의 연동을 모르겠습니다. -_-




윈도우 7폰은 하위호환성을 포기했습니다. 그러니까, 여태까지 12년동안 쌓아올렸던 어플리케이션을 일거 포기한다는 어마어마한 결정을 내린거죠.
일장일단이 있겠지만, 현재로서는 현명한 선택이라고 생각합니다. 기존의 구식 UI로는 도저히 표현하기 힘들었던 새로운 세계를 재창조하는 것이고, 오히려 유물을 떨쳐낸다고 생각합니다.
반면 이런생각을 합니다. 윈도7폰이 뜬다면, XDA같은 곳에서 오히려 이 위에 돌아가는 윈도우 모바일 에뮬레이터를 만들어낼 수 있지 않을까 하고요.
MS가 닷넷을 리눅스에 올리기 위해서 직접 작업을 하지 않고 모노 프로젝트같은것을 후원할 가능성도 있고요.

실제로 윈도 7폰은 최소사양이 어마어마합니다.

정전식 터치 스크린 : 4개이상의 터치 포인트

센서 : 가속 센서, A-GPS, 조도 센서, 근접 센서, 나침반

카메라 : 5메가 이상의 카메라와 카메라 버

미디어 : 일반적 코덱과 가속 지원

메모리 : 256 ram, 8GB 내부 스토리지

GPU : 다이렉트X 9 가속

프로세서 : ARM v7 이상 (스냅드래곤의 스콜피온 , 아이폰의 Corte A8 이상)

해상도 : 800*480 WVGA 480*320 HVGA

키보드 : 옵션

버튼 : 전면 버튼

이정도라면 2003년부터 사실상 별 변화가 없는 윈도우 모바일을 에뮬레이팅할 자원은 충분하죠.




노키아 플래폼이 더해졌다는게 오히려 더 손해가 된다는 분석들도 있습니다.
이미 한번 엎질러져버린 심비안 플래폼인데다가, 점점 점유율이 바닥으로 향하고 있다는 기사들, 그리고 자체적으로도 위기의식을 강하게 느꼈는지 우리는 불타는 플래폼 위에 서 있다. 라는 표현까지 써 가며 격하게 반응하고 있죠.
이에 맞서서 노키아 직원들은 시위를 하고 있고요.
원문 : More than a thousand employees” walk out of Nokia offices

이게 확실히 '노키아' 입장에서는 그럴지도 모릅니다. 노키아라는 이름을 만방에 떨쳤던 심비안 플래폼을 반쯤 사장시키고, 새로운 자체 플래폼인 미고와 윈도7폰 양자 체제로 가는 형태가 되는 거니까요.

그런데 이건 노키아 입장이고, 반대로 MS의 입장에서 생각해 봅시다.
PC를 예를 들어 생각해보면, MS의 입장에서는 삼보 컴퓨터가 망하든말든 별 관계없습니다. 약간의 매출타격은 있겠지만, 심한건 아니죠. 왜냐하면 MS의 윈도우 플래폼을 팔아줄 업체는 삼보 말고도 많으니까요.

동일하게 모바일 시장에서 생각해보면.. 답은 나옵니다.
MS는 노키아가 (가능하면 안망하면 좋겠지만) 망한다해도 별 관계가 없죠. 이미 노키아의 이름을 걸고 WM7 휴대폰이 보급만 되면 플래폼의 보급이라는 MS의 의 목적은 달성되는 중이기 때문이죠. 실제로 노키아와 MS가 한 협약에 대해서는 구체적으로 모르겠습니다만, 공상제작소님의 분석이 정확한듯합니다.
노키아는 MS의 지원을 받아 폰을 만들고, MS는 플래폼을 확대시키는거죠.
여기까지만 보면 윈윈인데... 조금만 지나보면 알겠지만, 플래폼이 넓어지면 노키아 말고도 참여 업체가 많아집니다. 삼성은 안드로이드, 바다 플래폼에 이어서 (돈이 된다고 판단된다면) 이쪽에도 뛰어들 가능성이 높고, 이는 LG, 모토로라, 심지어는 델.. 등도 마찬가지입니다.

이렇게 플래폼이 이미 넓어지고 게임의 규칙이 바뀌면 노키아는.. 토사구팽이 될 확률이 높습니다.

물론 노키아도 이 점을 잘 알고 있을 겁니다. 그렇다면 노키아는 윈도우폰 시장에서 무언가 차별화를 두어야 할 테고요.
이 점에 대해서는 학주니님께서 분석해 놓으신 내용이 훌륭합니다. 한번 읽어보세요. :)
간단하게 요약하자면,

입니다.
다만 간과하지 말아야 할 것이, 삼성이 갤럭시S로 안드로이드 프리미엄 시장을 잠식하듯 노키아가 이걸 잠식할 수 있는지에 대해서는 조금 의문입니다.
노키아의 입장에서는 윈도7폰의 개발 비용을 (사실상) MS로부터 조달받는 셈인데, MS로서는 가능하면 많은 핸드폰 제조사가 참여하는 것이 좋거든요 ;-)



현재 윈도7폰이 고전하고 있는건 사실입니다. 그리고 이걸 이기기 위해서 고군분투하는것도 사실이죠.
앞날은 아무도 모릅니다. 아이폰이 언제까지나 독주할 듯 했지만 안드로이드는 그 뒤를 바짝 따라왔고, 나머지 주자는 어떻게 될지 아무도 모르죠.
다만 MS의 소프트웨어 역사를 봤을때 몇번이고 실패해서 결국은 시장을 재패한 MS의 방식으로 봤을때, 윈도 7폰은 망할지 몰라도, 패러다임이 바뀌지 않는 한 방식이 동일한 후속 버전에 대해서는 어느순간 시장 점유율을 넓힐것이라고 생각합니다.


덧.
이글 다 읽으셨으면 용자입니다. -_-b

학주니님의

이메일을 쓰면 구시대? 우편 - 이메일 - 메시징이라는 시스템의 변화 속에서...

라는 글과 더불어서, 요새는 이메일 시스템이 점점 사라질꺼라는 글들을 보면서 생각나는 것들이 있어서 간단하게 정리해 둡니다.
이메일은 사실상 Unix 가 태생되던 시기부터 있던 서비스였고,
언제나 시/공간적 제약을 넘어서 아날로그를 디지털로 바꾼 대표주자로 인식되곤 했었죠.
그러한 이메일 시스템이 드디어 사라질 것이라고 다들 예견합니다.

그런데, 정말 그럴까요?
전세계적으로 이메일의 사용 빈도가 떨어진다는 통계는
조사기관이 어디인지 안나와있어서 정확히 잘 모르겠고요 ^^;;

이게 만약 사실이라고 해도, 이것은 점유율을 낮출 뿐이지
실제로 이메일 서비스의 종말을 이야기하는건 아닐꺼라 생각합니다.

확실히 예전에 비해서 개인 대 개인의 의사소통 시스템으로서의 이메일의 필요성은 많이 줄어들 것입니다.
이것은 경제학에서 말하는 대체제 효과 때문인데요.
이전에 이메일의 경쟁 상대가 그저 손으로 쓴 편지였다면
지금은 통신사의 문자메세지(SNS) 서비스, 메신저 뿐만이 아니라
카카오톡이나 마이피플같은 문자메세지 대체 서비스까지도 경쟁자가 되고 있습니다.
마침 어제 네이버톡도 오픈했고요
[분류 전체보기] - 네이버는 당신의 모든것을 알고있다.
물론 학주니님께서 말씀하신 '페이스북 메신저'서비스를 포함해서 말입니다.


반면 그렇다면 이메일이 살아남을 수 있는 분야는 어디일까요?

가장 쉽게 생각할 수 있는 시스템으로서 '기업내 의사소통'을 들 수 있습니다.
기업내/외 의사소통의 경우에는 그저 가볍게 이야기를 나누는 통로로서 이메일을 사용하기보다는 오히려 그 기록과 흔적을 남기기 위한 방법이라는 측면이 강합니다.
즉, 각 기업의 의사결정상 책임소재를 확실하기 위한 방도로써 많이 쓰이죠.
공식적인 의사결정과 책임이 따르는 분야에 있어서는 가벼움보다 조금 더 무거움을 지향해야 할 때 이메일 시스템은 살아남을 것입니다.

위의 사례를 보면 알 수 있듯이, 각각의 의사소통은 타켓층을 가집니다.



여기서 페이스북 메신저가 노리는 것은 오히려 기존에 SMS 시장이 가지고 있는 2. 피드백을 요하는 교류. 이지 3. 의 이메일이 가지고 있는 공지적 성격이 아닐꺼라 생각합니다.



그리고 페이스북 메신저 이야기가 나와서 말인데,
페이스북 메신저가 (지금은 전세계에서 가장 쿨한 기업일지는 몰라도)
영원하리라는 보장은 그 어디에도 없습니다.
반면 이메일은 POP3와 SMTP, IMAP 이라는 공용 프로토콜이 있고,
이는 오픈 프로토콜이기에 어느 서비스 벤더이든 구현할 수 있습니다.
따라서 오히려, 특정 벤더에 속하지 않는 시스템이 되는 거죠.

오히려 페이스북 메신저에서 주목해야 할 부분은 우리나라의 LG U Plus와 페이스북이 연동한 것처럼 기존 통신사의 SMS 서비스와 새로운 메시징 서비스의 결합으로 인해서 얻는 시너지 효과라고 생각합니다.
모든 메세징이  다 페이스북으로 모인다면, 이쪽의 네트워크 트래픽과 더불어광고모델은 확실해지겠죠.
그리고 모든 메세징이 한군데로 모인다는 모토 또한 실현 가능할 꺼구요.

반면 불확실성도 존재합니다.
페이스북 입장에서는 당연할지도 모르겠지만 이 메신저의 프로토콜은 공개하지 않고 있고,이는 페이스북이 어느순간 하락새로 치닫게 되면, 모든 라이프로그가 사라진다는걸 의미합니다.
이메일은 절대 이럴 일이 없죠^^;;


덧.
페이스북의 메시징 시스템이 한국의 포털에서는 당연한 '쪽지'와 비슷하다고 생각하는건 저뿐인가요? ^^;;

mepay님의 글

네이버 오픈마켓 진출의 희생양 '네이버 블로그'

과  여기에 엮인 글

썬도그 님의

네이버 메인에서 블로거 글들이 점점 사라진다

라는 글을 읽고

네이버 블로그, 다음 블로그, 네이트의 이글루스, 파란 .. 등

거대 포털에서 블로그 서비스가 사라질 수도 있다는 생각이

문득 들었다.




예전부터 종종 생각해 왔던 것이

거대 포털들은 블로그 서비스를 하면서 대체 어떤 목적을 가지고 있을까

트래픽의 상승인가 아니면 다른 무언가일까..였다.

그런데 가만히 보면 네이버에서 애드포스트라는 서비스를 제공한지

그리 오랜 시간이 되지 않았고,

이글루스의 팝스 또한 마찬가지였다.

유일하게 오래된 곳은 티스토리에서 구글의 애드센스를 붙이는 거였지만

이건 티스토리의 수익과는 전혀 무관함으로 논외로 치고

애드포스트나 팝스처럼 블로거에게 수익이 날 경우

서비스를 제공하는 벤더와 나눠먹기하는 구조가 된 지는 얼마 되지 않았다는 얘기다.


그럼 그전까지는 도대체 왜 포털에서 블로그 서비스를 제공한 걸까?

네이버같은 경우에는 우습게도 외부 검색이 모두 막혀있었으므로

네이버 블로거들의 컨텐츠를 보고싶다면 네이버로 들어오는수밖에 없었다.

이로 인한 포털 메인의 트래픽이 증가했고, 광고효과는 극대되었었고..

그런데 어느 순간 네이버의 외부검색이 풀렸고, 이런건 아무 쓸데가 없어졌다.

즉, 구글에서 뭔가를 찾아도 바로 네이버 블로그 포스트까지 진입한다는 거다.

네이버의 포털 메인페이지를 거치지 않는 블로그 포스트는

네이버 입장에서는 그저 트래픽 부담일 뿐, 아무것도 안남는 장사다.

그래서 네이버는 어떤 경로로 들어오든 간에 포털에 수익을 가져올 수 있게

애드포스트를 오픈한거고..




그런데 막상 뚜껑을 열고 보니 네이버 애드포스트는 생각보다 그닥 장사가 안된다.

여전히 트래픽은 상상을 초월하게 먹고있는 네이버 블로그가

돈이 안되는 사업이라고?

그래서 네이버는 한번 더 생각해본다.

 어떻게 하면 이 블로그 서비스가 수익을 가져다 줄 수 있을까?

하지만 딱히 생각나는건 없다.

트랙백을 막을 수 있게 해 두고,

서로이웃이라는 장치를 만들어서 네이버 안에서 돌 수 있게 하고,

RSS를 통한 외부이웃 글 읽기를 통해서

네이버 안에서 데이터가 돌게 하는 방법 말고는 딱히 돌파점이 안보인다.

이러한 점은 네이트의 이글루스도 마찬가지이며, 다음 블로그도 마찬가지이다.

오히려 다음 블로그쪽은 더 막막한 것이..

다음은 블로그 서비스를 두개 운영하고 있다.

하나는 다음 포털 자체에서 서비스하는 다음 블로그,

그리고 하나는 티스토리인데... 이거 두개 다 돌파점이 안보이는거다.

그래서 이 시장을 뚫을려고 한게 다음 애드클릭스에 이은 다음 애드뷰인데..

아시다시피, 효과는 그다지 없는 상태이다.




이러한 시사점은 단순히 블로그 서비스에 국한되는 것이 아니다.

웹툰은 어떠한가? 보면 알겠지만

옆에 자그마한 광고가 있는 것 외에는 그다지 수익원이 없다.

그렇지만 하나의 서비스에서 100개도 넘는 웹툰 작가들의 원고료만 해도

만만치 않을 터, 이게 과연 웹툰 자체의 광고 트레픽으로 타산이 맞는걸까?

그리고, 요새 스마트폰의 플래폼 확장으로 인해서 웹툰 어플이 속속 나오고 있는데

이 어플들에서는 그나마 광고도 안들어간다.





반면 네이버가 작년에 오픈한 오픈캐스트를 한번 살펴보자.

여기는 그냥 링크모음인데,

유저들이 각각 유용하다고 생각한 링크들을 짧막한 소개와 함께

외부에서는 이 오픈캐스트에 다이렉트에 접근할 수 있는 방법이 없다.

즉, 여전히 네이버 포털을 통해서만 들어갈 수 있는 것이다.

이쪽이 오히려 네이버에서 남기고 싶어하는 서비스가 아닐까..싶은 생각도 든다.


mepay님께서 말씀하신, 네이버 블로그의 상업화와 커머스 업체로서의 가능성은

오히려 네이버쪽에서는 환영해야 할 일이다.

다만 , 여전히 커머스 업체로서 그저 공간만 제공하는 라쿠텐 모델이 아니라

안전결제로서의 플래폼 역할을 하는 역할을 자처하는 것이 훨씬 현명하다.

네이버 중고나라 카페를 보면 알겠지만,

상상을 초월하는 양의 물건들이 매일 거래되는 시점에서

소위 '쿨매'라 불리는 사용자간 직거래 방식을 가능한한 지양시키고

이 수수료를 받아먹는게 네이버 입장에서는 현명하지 않을까..




말이 길어졌는데, 짧게 요약하면 다음과 같다.

블로그 서비스들이 다른 수익원을 (연계해서든 직접이든 간에)

찾아내지 못한다면, 다음 플래닛이 사라졌던 것처럼

어느순간 포털의 블로그는 사라질 수도 있다.



덧.
내가 티스토리를 쓰는 이유는 처음부터 위와같은 상황을 고려했기 때문이다.
티스토리는 블로그 백업 기능이 있어서, 최악의 경우 내가 웹 호스팅을 하더라도
내 블로그 데이터를 그대로 옮길 수 있기 때문이다.


관련글.
[RL.M arketing] - 네이버 애드포스트로 억대연봉? 장난해?
[RL.M arketing] - 이글루스의 광고인 팝스. 성공할까요?

초보자 (보통 뉴비라고 부르는) 들이 아무리 애를 써도

구루를 따라잡을 수 없는 이유.

구루들이 개발을 잘 하는데는 여러가지 이유가 있다.

그중 한가지, 그리고 절대적인 이유가 바로

'경험'이다.

수많은 문제를 풀어가며 쌓인 경험들,

 그 많은 경험이 쌓임에 따라서 쌓인 내공이라는 것은

절대로 초보자들, 그리고 그 구루보다 실력이 없는 사람들이

쉬이 따라잡을 수 없는 것이다.


그런데 이 내공이라는 건 대체 뭘까?

어떤 Domain Specific한 문제에 있어서

구루의 내공은 절대적인 힘을 발휘한다.

Domain Specific이라는 것은 꽤나 다양한 의미를 지니는데,

예컨데 개발 플래폼일 수도 있고,

언어에 대한 지식일 수도 있으며,

개발 방법론에 대한 사유일수도 있다.

물론 특정 분야에 대한 전문적인 지식을 포함해서 말이다.


초보자들이라고 해도

개발 플래폼에 대해서 남들에 비해 세배 더 열심히 공부하고,

언어에 대한 지식은 도서관을 섭렵했으며,

개발 방법론에 대해서는 이름만 대면 하루종일 썰을 풀 수도 있고,

심지어는 특정 분야의 종사자도 혀를 내두를 만큼 빠삭할 수도 있다.

그런데 왜 초보자들은 절대로 구루의 내공을 따라잡을 수 없는걸까?



우리는 절대로 남의 코드를 읽지 않는다.

사실 현업에서 일하면서 남의 코드를 읽을 일은

기존에 다른 사람이 만들어놓은 소스코드를

버그 혹은 수정사항의 발생으로 유지보수할 때 뿐이다.

이렇게 (어쩔수 없이) 타인의 코드를 읽어야 할 때에도

대부분의 사람들은 그저 자신과 코딩 스타일이 다르다는 이유로

투덜거리고는 한다.

물론, 실제로 쉽게 풀 수 있는 문제를 굉장히 지저분하게 풀어놓은 경우도 있으나

이 또한 기존에 개발을 했던 개발자의 사유의 산물이다.

이렇게  기존 사람이 문제를 풀기 위해서 밟아온 과정은

 전혀 이해하려고 하지 않은 채,

그저 스타일이 다르다는 이유로, 쉬이 이해할 수 없다는 이유로

그 코드는 '쓰레기' 취급을 받는다.


언제나 프로그래밍은 결과 지향적이기 때문인지도 모른다.

과정이야 어쨌든 사실 엔드 유저에게 보이는 모습은

그냥 결과물로서 말한다.

개발자들도 어차피 최종 산출물을 뽑아내야 하는 사람들이기에

더더욱 결과물로서 말한다.

그들은, 끊임없이 사고한다.

그리고 절대로 그 사고를 타인과 나누지 않는다.

소스코드를 읽어보면 알겠지만

History가 그대로 남아있는 소스는 대부분 없다.

그저 알고리즘 수정. 이런 주석만 붙어있을 뿐이다.

이런건 SVN같은 형상관리 프로그램으로 관리하면 된다지만,

미안하지만 SVN의 History Source를 읽는 케이스는

이 버그가 대체 누구의 잘못인가를 따지기 위한 상황 말고는 못봤다.


무언가를 배우기 위해 가장 빠른 방법은

다른사람이 어떤 과정을 밟았는지에 대해서 보고, 따라하고, 습득하고,

고쳐나가고, 직접 만들어보고, 내것으로 만드는 것이다.

우리는 , 보고, 따라하고, 습득하고, 고쳐보고..는 모두 다 생략한채로

언제나 자신의 취향이 100% 반영된 바퀴를 새로 발명한다.

그리고 기뻐한다.



서점에 가면 수많은 자기개발서와 성공서들이 쌓여있다.

그런데 유난히 IT 분야에는 그저 영웅 만들기에만 치중할 뿐, 이런건 거의 없다.

이것이 실용학문의 한계라고 하기에는 뭔가 우습다.

원래는 사유학문인 경제분야에서는 이런책이 끝도 없이 쏟아져 나오는데,

실용학문인 IT분야는 그저 자신의 방법론만 설파할 뿐

그 방법론이 어떠한 사고과정을 걸쳐 펼쳐졌는지는 절대 말하지 않는다.



Agile에서는 말한다. ProtoType을 만들고,서서히 뜯어고쳐라.

한국의 현업에서는 말한다. ProtoType을 만들어라. 그리고 프로젝트 종료.



IT는, 절대로 타인의 경험을 공유하지않는다.

소스포지등에 보이는 수많은 프로젝트들 중에서

그 많은 소스코드들 중에서

자신이 개발하는 분야에서 1등인 오픈소스 프로그램의 소스코드를

읽어본 사람은 몇이나 될까.


다른사람의 생각의 과정과 그 결과물이 도출된 원인을 배우지 않는 한,

뉴비는 스스로 깨달아갈 뿐, 절대로 구루의 옆에 설 수 없다.



관련글
[RL.T hink.] - 지식 권하는 사회..슬프다.