옛날 얘기로 시작해봅니다. 지금부터 10년도 더 오래된 옛날(?)에 우리나라 컴퓨터 학습은 무조건 BASIC부터 시작되었습니다. 오죽하면 국민학생 대상의 컴퓨터 학원의 필수 코스가 BASIC이었고 그 교재 시장만 꽤 있었으니까요.
사실 저도 한때 그런 분위기에 편승하여 국민학교 컴퓨터 선생을 한 6개월 했었던 기억이 있군요. 아이들에게 기존 선생님은 베이직을 가르쳤다는데 저는 차마 그렇게는 못 하겠더라구요. 그래서 제가 한 것은 무었이었을까요? 그건 바로 한메타자를 깔아서 그걸로 타자 연습이라도 열심히 하게끔 했던 기억이 납니다.
왜 갑자기 옛날 얘기냐구요? 우연이 본 오프라인 행사 안내에서 학생들을 위한 새로운 언어인 SCRATCH 기반의 내용을 보고 옛날 생각이 떠올라 몇자 적어보았습니다.
SCRATCH란 자세히 보진 않았지만 비쥬얼 프로그래밍 언어의 일종인 것 같습니다.
당연이 새 언어를 위한 개발툴을 설치하고 언어를 배워서 여러 가지 장난감을 만들어 보는 것이라 생각됩니다.
재미있는 건 과거 Apple 8비트 시절의 LOGO 과 목적과 접근 방법이 비슷하다는 겁니다. 교육용 언어로 설계하면서 적절한 객체지향 언어의 어려운 점을 단순화하여 그것을 위한 Tool을 제공하는 겁니다.
다른 점이라면 이제 인터넷 시대에 맞게 만든 결과물을 쉽게 "Publish" 할 수 있는 기능을 내장하고 공유함으로써 새로운 재미를 제공하는 거지요. 과거에는 교실에서 Apple 컴퓨터로 수업하던 것을 인터넷에서 많은 사람들과 서로 내용물을 공유하고 다시 ReMix나 Mashup 할 수 있는 개념이 추가된 LOGO라 할 수 있습니다.
뭐 시간적으로 좀 여유가 있으신 분이거나 또한 더욱 더 시간에 여유가 있는 자녀분에게 창의력 교육을 시키고 싶으시다면 아래 행사에 참여해보시기 바랍니다. (여유가 없는 제 자신에 한탄을 하고 있고, 레고 마인드스톰 사서 아들 녀석 주었더니 몇 번 가지고 놀고 처 박아 둔 가슴아픈 기억이 새록새록~)
만세. 집에 와서 온오프 믹스를 확인해 보니 대기자 3번에서 정확히 참가자 100번으로 바뀌어 있군요. (정원 100명) 아젠다는 다음과 같습니다. 덧붙여서. 일단 스크래치라는게 뭐냐면. 스크래치’는 한마디로 ‘비주얼 프로그래밍 플랫폼’이다 라고 하시네요;; 말씀하신 그대로 '그림'을 기반으로 프로그래밍 할 수 있는 방식입니다. 비주얼적이라고 하면 많이들 비주얼 베이직 스타일을 떠올리시는데 그런식으로 기존에 만들어진 컨트롤만 비주얼리티한 환경이 아니..
이미 공지했던 스크래치 데이 다녀왔습니다. ^^ 10:45-11:45 : 스크래치에 대하여, 역사 문화적 맥락, 스크래치 컨퍼런스(MIT MediaLab) 경험 공유. - 죄송합니다. 늦잠자서 늦게 도착했어요. 들어갔더니 ' 끝났네요. 각자 식사하시고 오세요.? ' 라고 하시더군요.. 아래는 각 아젠다와 그 아젠다에 대한 '녹음' 본입니다. 뭐 소리가 잘 안들릴수도 있고 (싸구려 mp3이다보니;;) 녹음 상태가 그리 훌륭하지는 않으나 어쨌든 소리부터..
최근 Palm은 Pre와 같이 발표한 새로운 OS인 webOS에 대한 개발 도구를 조만간 발표하겠다는 기사가 나왔다. 기사를 보면 예상대로 webOS용 어플리케이션 개발은 웹 표준 기술인 HTML, CSS, JavaScript 을 가지고 개발 할 수 있다고 한다.
여기서 우리가 주목할 것은 HTML5에 추가된 표준인 Local Stroage 기능을 활용한다는 점이다. (참조 : HTML 5 "data-*" 속성(attribute) 추가! ) 사실 이러한 Local Storage 기능은 웹 기반 기술을 가지고 어플리케이션을 개발하는데 필수적인 요소라고 할 수 있다. 왜냐하면 휴대폰 소프트웨어가 아무리 Always connected device라고 하여도 네트워크의 성능등을 고려한다면 local storage를 활용하지 않는 것은 바보 같은 접근이라고 할 수 있다.
어쩃든 이런 기능을 포함했긴 하지만 webOS는 철저하게 웹 어플리케이션 개발자 친화적인 개발 환경이라고 할 수 있다.
왜 Palm은 Apple처럼 Objective-C도 아닌, Android처럼 Java도 아닌 웹 기술(사실 Javascipt 기반이라고 부를 수 있는) 기반으로 개발 환경을 제공하게 되었을까?
사실 이렇게 개발 환경의 근간을 바꾸는 결정은 쉽게 바꿀 수 있는 일이 아니다. 이와 관련해서 모든 개발툴부터 기존 어플리케이션과의 호환성등 다양한 문제들이 발생하기 때문이다. 현재까지 알려진 내용으로 속단하기는 이르지만 webOS의 핵심 Sync 엔진이라고 할 수 있는 Synergy는 기존 PalmOS의 Sync 기반도 아닌 것으로 보인다.
여러 가지 이유가 있겠지만 제일 큰 이유는 바로 고객들의 사용 환경의 변화가 제일 크지 않았을까 생각된다.
PalmOS가 처음 발표되던 1996년을 기억해보자. 아직 Google, Inc도 설립하기 전이다. 인터넷이 지금만큼 활성화되지도 않았고 소위 "인터넷 버블"이라고 부르던 시절 이전이다. 당연히 사람들은 대부분의 정보를 PC에 보관하고 있었고, PalmOS가 탑재된 PDA의 핵심 용도는 PIMS였다.
PIMS의 정보는 당연히 PC에 보관되는 것이 상식이었고, PC에 있는 PIMS 정보와 Sync를 얼마나 편하게 해주냐가 PDA의 핵심 경쟁력이었다.
이제 2008년으로 Back to the Future 해 보자. 사람들(우리나라말고~)의 PIMS 정보는 지금 어디에 있는가? 아마도 PC보다 구글 주소록에 Facebook에 그리고 MSN 메신저에 MySpace에 있다고 할 수 있다. 이제는 PC에 있는 정보와 Sync보다 웹에 있는 정보와 연동이 중요한 시절이 된 것이다. 이제 과거의 PDA에 해당되는 스마트폰에 주어진 기대치는 어떻게 하면 웹에 있는 정보와 빠르게 연동될 수 있는가이다.
개발자 Pool은 어떤가? 이제 PC Nativce 소프트웨어 개발자들보다 Java 개발자가 더 많고 그것보다 더 많은 것이 바로 웹 소프트웨어 개발자이다. 웹 소프트웨어 개발이 더 빠르고 더 신뢰성 검증이 쉽고 더 배포가 편리하다. 따라서 이러한 웹 소프트웨어 개발자들의 지원을 빠르게 화고할 수 있는 방안은 무엇이가?
이것들이 바로 webOS가 웹 표준 기술로 간 이유이다. 사실 Apple도 똑 같은 이유로 2G에서 웹 개발을 유도했었고 Google도 바라는 바이지만 Native 개발 환경보다는 VM기반의 Java를 선택했다. 그리고 Palm은 Web Runtime 기반이라고 할 수 있는 webOS를 선택한 것이다.
물론 Palm의 이러한 선택이 너무 빠를 수도 있고 Apple처럼 번복될 수도 있다. 그러나 최소한 이런 트렌드 자체는 아마도 거스를 수 없는 방향인 것만은 점점 분명해지는 것으로 보인다.
Yes, there are new shiny platforms like the iPhone and delayed but soon to be launched Android,
and yes, you can do great things with those. Things you wouldn't have
dreamed about doing in J2ME. But, your users are not necessarily using
them. To be exact, whatever your target is, 0% use Android
currently.... And as for the iPhone it is true that it has gained a
very nice chunk of the smartphones market share in the US (27%), but
its global marketshare when you take into account all phones (not just
smartphones) is 0.14%...
물론 맞는 얘기다. 하지만 그 내용에 대한 댓글을 보면 내가 하고 싶은 얘기를 잘 얘기하고 있다.
Whatever
is done to make it easier to develop apps on J2ME, the problems still
exist from the consumer side. No matter how many of those devices are
in the field if few apps are going to be purchases on them anyway.
Discovery,
purchase, installation and use are still so much more difficult than on
the iPhone that sales are severely limited compared to what will be
seen with the AppStore. Not to mention the costs of revenue sharing
with carriers and the issues dealing with pSMS for developer and
consumer alike.
The best reason to develop for AppStore has
nothing to do with shiny new technology and everything to do with a
good business case to develop with the least hassle to reach the
largest possible number of consumers actually likely to find and buy
your app with a good percentage of that revenue going to the developer.
즉 블로그 주인의 글은 "개발자" 관점에서만 언급했다는 얘기다. 시장에 J2ME가 아무리 많아도, 그 플랫폼이 개발하기에 익숙해도 결국 Application이 안 팔리고 있다는 점이 중요하다는 얘기다.
그러면 iPhone 어플리케이션은 왜 팔리는가? 그건 결국 "iTunes"라는 PC Application 때문이다. 이 녀석은
1. Application에 대한 "Discovery", "purchase", "installation"을 모두 단순화시켜준다.
2. 통신비용의 부담도 없이 PC를 통한 Sideloading은 물론, WiFi로 OTA도 가능하고
3. 구매를 할 만한 고객들에게 Application을 전달해주고 있다
아래 다른 사람의 글을 보면 "왜 제조사의 Pre-install도 한계가 있는지 얘기하고 있다.
Faisal Memon
said...
Dale Larson's comment is completely
spot on. I've talked to app
developers, seen presentations from
3rd party software developers, etc.
and they all say that:
1. You write a great app.
2. Customers don't download it
- awareness?
- mechanism?
- download cost!
3. Handset vendors don't pre-install it
- they take a large $ cut
- pre-qualification fees & process
- security certificate signing
headaches
4. Second class citizen problem
- apps don't match native UI L&F
- app lives in its own world; not
part of a continuous UI workflow
Unless you've already bedded in
your brand and got users on-board
(e.g. you are a facebook.com) your
opportunities are low indeed.
I claim that the only way to make
a success of mobile app development
is to first make a success as a
web app, or PC app.
I'm a big fan of Java ME (I worked
at Sun, and also worked at
Esmertec porting the JVM), and
know the complaints because lots
of folks come to us (I work at
Symbian) to complain about the
problems above.
The solution is really something
like the iTunes Music store maybe
with some of the architectural
niceness that Android gives you.
Maybe a hybrid solution will be
forged on the (upcoming) Symbian
Foundation OS.
역사기록물 관리 관련한 일을 하면서 아이폰에 유달리 관심이 생기는 이유는 사실 좀 복잡하다. 홍보의 문제, 역사기록물에 관한 소식을 효과적으로 배포할 수 있는 문제 문제는 여전히 생태계란 말이야, 멍충아! 문제는 개별 디바이스나 아이튠즈 등의 단일 어플리케이션이 아니라 그것들이 서로 연결되는 생태계
드디어 구글폰의 실체인 안드로이드(Android) SDK가 공개되었다. 예상대로 오픈 소스 기반의 다양한 솔루션들을 잘 혼합하여 Platform을 구성했다. 특히 관심을 끄는 것은 "자바(Java)" 기반의 Application Framework을 제공한다는 점이다. 아래 그림은 안드로이드 개발자 홈페이지에서 가져온 아키텍처 구성도이다.
우선 주요 구성 컴포넌트를 살펴보자
Application framework : 자바 기반의 어플리케이션 개발 Framework
Optimized graphics 2D 그래픽, OpenGL ES 1.0 엔진 (하드웨어 종속적)
SQLite : DB 엔진
Media support : MPEG4, H.264, MP3, AAC, AMR, JPG, PNG,
GIF
GSM Telephony : 하드웨어 종속적
Bluetooth, EDGE, 3G, and WiFi : 하드웨어 종속적
Camera, GPS, compass, and accelerometer : 하드웨어 종속적
Rich development environment : 에뮬레이터를 포함한 이클립스 Plugin
최근 정보를 통해서 알게 된 것은 대부분의 컴포넌트가 자바로 만들어졌다고 들었다. 하지만 실체를 열어보니 역시 그렇지는 않았다.
위의 그림에서 보면 빨간색은 리눅스 커널 영역을 의미하고, 녹색은 이미 개발되어진 오픈 소스 기반의 솔루션들을 사용한 것을 알 수 있으며, 파란색 컴포넌트들이 아마 자바로 구글쪽에서 이번에 개발한 것으로 보인다. 물론 노란색의 자바 VM을 포함해서 말이다.
결국 안드로이드는 기존의 것을 잘 활용하라는 오픈 소스의 원칙과 많은 개발자들을 끌어들이기 위한 "자바(Java)"라는 카드를 선택한 것 같다. 지금 판단으로는 적절한 선택이 아니였나 생각된다. 만약 안드로이드가 100% 오픈 소스로 제공된다면 (아직 소스를 열어보지 않아서 모르겠지만) 누군가 또 열심히 상위 Application Framework를 C/C++ 언어 버전을 만들어주시는 놀라운 분들이 나올지도 모르겠다.
결국 안드로이드는 오픈 소스와 자바를 선택했다. 이것은 무엇을 의미하는가? 그러한 선택이 휴대폰 개발의 미래의 방향이라고 생각해도 과언이 아닐 것이다. 세계적인 영향력을 가진 구글과 30여개의 세계 굴지의 회사들이 오픈 소스와 자바를 선택한 것이다.
아이러니한 것은 철저한 오픈 소스 기반의 안드로이드 같은 아키텍처는 더욱 더 시스템 개발자와 어플리케이션 개발자의 계층을 분리시키게 될 것이다. 늦은 감이 있지만 휴대폰 개발에도 이제 시스템 계층을 전혀 모르고도 어플리케이션을 개발할 수 있는 시점이 오기 시작한 것이다. PC에서는 이미 10년 전부터 일어났던 일이 이제 휴대폰 개발업계에서 시작된 것이다.
이것은 결과적으로 무엇을 촉발시키게 될까? 그것은 바로 휴대폰 개발자를 더 이상 C언어 개발자만으로 채울 필요가 없다는 것을 의미하게 된다. 결과적으로 휴대폰 개발에도 이제 개발자를 구하기 쉬운 자바 개발자(자바 학원만 나온?)로 구성해서 좀더 효율적이고 생산적인 휴대폰 어플리케이션 개발이 가능하다는 것을 예측할수 있다. 이제 자바를 공부해야하나?
PS. 성급한 예측일지는 몰라도 이렇게 되면 휴대폰 개발 외주를 좀더 주기 쉽다는 뜻이 되는데 자바 개발자를 많이 데리고 있는 회사가 국내에 어디더라? 주식을 좀 사야할라나?
몇일 전 모바일 시장에 난리가 났었다. 그 이유는 구글이 바로 구글폰이 아닌 모바일폰 개방형 플랫폼인 안드로이드를 들고 나왔기 때문이었다. 애플의 맥 OS X가 아이폰으로 아이폰을 업고 승승장구하는 애플는 그렇다고 쳐도 기존 모바일 OS에 강세를 띠고 있던 '심비안'과 '윈도우모바일'을 개발한 노키아와 마이크로소프트사와 구글의 안드로이드의 발표에 애써 태연한 척하지만 심히 불안하기만 하다. 이번에 공개된 내용은 모바일 플랫폼 안드로이드가 탑재된 휴대..
블로그 잠깐 쉬겠다고 한 지가 벌써 두 달이 가까워졌네요. 처음에는 회사일이 바쁘다는 핑계로 잠시 쉰다고 했었는데... 나중에는 다시 시작하려니 다시 글을 쓸 엄두가 나질 않아 지금까지 부담만 느끼다가 시간이 가 버렸습니다. 그러다가 11월 5일경 소문만 무성하던 Google Phone이 안드로이드라는 Linux 기반의 Mobile Platform 이라는 발표가 있고나서 입이 간질 간질한 게 참을 수가 없더군요. 그래서 결국 이렇게 인터넷 여기 저기..
요즘, 구글이 만들고 있는 개방적 핸드폰 플랫폼인 안드로이드(Android)가 여기저기서 언급되고 있습니다. 안드로이드는 리눅스를 기반으로 하고 있지요. 지금까지 핸드폰용 소프트웨어의 개발은 그 핸드폰을 개발한 업체나 그 업체의 허락을 받은 회사만 할 수 있었습니다. 그러나, 구글 안드로이드는 이것을 모두가 할 수 있도록 확대했습니다. 즉, 누구나 자신만의 핸드폰용 소프트웨어를 개발할 수 있도록 한 것이지요. 이는 핸드폰 산업의 주도권이 하드웨어에...
구글 폰에 대한 기대가 굉장히 많았지요. 최근에 주가가 $700이상 올라간 이유가 아마도 애드센스에 따른 수익증가 뿐 아니라 구글 폰에 대한 은근한 기대감도 없지 않을 겁니다. 막상 발표된 구글 폰은 하드웨어가 아닌 새로운 오픈소스 형태의 OS였습니다. 지금까지 핸드폰들의 OS가 윈도우즈 모바일, 팜OS, 심비안 등 다양성 때문에 소프트웨어 개발자는 이들 모두에게 적용될 수 있도록 실행파일들을 만들어야 하는 불편함 등이 있었지요. 모든 핸드폰에 사용..
This is a technical answer to only part of a business problem.
I think that Apps are the new Singles and AppStore transforms the whole business the way iTunes changed digital music -- talking about digital formats wasn't relevant once there was a complete ecosystem change.
Whatever is done to make it easier to develop apps on J2ME, the problems still exist from the consumer side. No matter how many of those devices are in the field if few apps are going to be purchases on them anyway.
Discovery, purchase, installation and use are still so much more difficult than on the iPhone that sales are severely limited compared to what will be seen with the AppStore. Not to mention the costs of revenue sharing with carriers and the issues dealing with pSMS for developer and consumer alike.
The best reason to develop for AppStore has nothing to do with shiny new technology and everything to do with a good business case to develop with the least hassle to reach the largest possible number of consumers actually likely to find and buy your app with a good percentage of that revenue going to the developer.