Steve Jobs Ends iPhone SDK Panic

casaubon · 2007-11-21, 07:46 AM

Steve Jobs Ends iPhone SDK Panic

October 17th, 2007 | Markets, Mobiles,

Software, Tech, the Media

Daniel Eran Dilger

2월에 아이폰/아이포드 터치용 소프트웨어 개발킷을 선보일 예정이라는 공식적인 발표가 나왔다. 애플이 써드파티 개발자들을 박해한다고 떠들던 입들이 무색해졌다.

올해 초, 아이폰의 선 이후, 모든 맥 개발자들 입장에서 볼 때, 갑자기 아이폰 소프트웨어 시장가치가 분명해졌다. 6월 말 발표 이후, 해커들은 말 그대로 아이폰의 문을 열어제껴왔다. 소프트웨어의 설치를 위해서였다.

그러나 애플과 애플 제품 헐뜯기에만 혈안이 되어있는 비판가들이 있다. 이들은 어떤 발표이건 무조건 공격하는 모순적인 이들이다.

It Can’t Be OS X!
애플이 실제로 새 휴대폰에 맥오에스텐 기반의 소프트웨어를 사용한다 믿지 않는 이들도 있다. 아이폰이 ARM 프로세서를 사용한다는 이유다.

Slashdot | iPhone Not Running OS X

그들은 애플이 "오에스 텐"이라고만 붙인 이름이 브랜드일 뿐이라 주장한다. 10년 전, 마이크로소프트가 데스크톱 윈도 브랜드를 활용하기 위해 WinCE를 만들었던 것과 매한가지라는 내용이다. 물론 브랜드가 맞기는 맞다. 1월달 필자 주장처럼 차라리 맥오에스텐이라 부르는 편이 나았을지도 모르겠다.

필자는 당시 넥스트가 프로세서 독립적인 OS를 만들어왔다는 점과 함께, 작년에 PowerPC에서 인텔로의 이주를 위한 포팅도 해냈다는 점을 지적하였다. 애플이 이미 90년대 초반부터 개발에 직접 도움을 주었던 프로세서인 ARM에 포팅 못할 이유라도 있는가? ARM은 원래 뉴튼 메시지패드용 프로세서였다. 2001년 이래 나온 아이포드용 프로세서이기도 하다.

그들은 틀렸다. 아이폰은 나왔고, "오에스 텐 1.0"이라는 이름이 붙기는 했지만, 맥오에스텐과 같은 기반의 시스템이었다.

iPhone 인사이드: Mac OS X과, ARM, 그리고 iPod OS X
iPhone은 어째서 Symbian을 선택하지 않았을까
iPhone의 OS X과 Leopard, 그리고 Vista

It Can’t Be Secured!
그러자 이번에는 아이폰의 보안에 문제가 있으리라는 공격이 나왔다. Gartner의 듈래니(Ken Dulaney)도 개중 하나다. 그는 아이폰에 파이어월이 없다는 주장을 펼쳤다.

듈래니는 아이폰이 파이어월이 있는지를 알지 못한다. 오에스텐 설치시, 파이어월 제공이 없다면서, 그는 휴대용 기기에 파이어월이 어째서 필요한지 설명도 하지 않았다.

윈도모바일이 파이어월을 제공하던가? 뭐라도 하던가? 파이어월이 있으면 윈도모바일의 충돌을 막을 수 있을까? 혹시 그 때문에 윈도모바일 부팅이 그리도 느린 것일까?

Secret iPhone Details Lost in a Sea of Hype and Hate

It Must Be Secured!
다른 일상적인 컴퓨터처럼, 패치가 필요할 보안 문제를 아이폰도 갖고 있다 지적하는 보안 전문가들도 있다.

이들이 갖는 첫 번째 오류는 아이폰이 사용하는 오픈소스 소프트웨어 코드 검색을 통해 알 수 있다. 사실 보안 연구자들도 이 과정을 통해 보안문제 해결을 권유할 수 있으며, 애플은 아이폰 데뷔 한 달여만에 그러한 취약성을 업데이트로 패치시켰다.

이를 오픈소스의 투명성, 보안성을 확인시켜주는 증거로 삼는 대신, 전문가들은 발견된 오류를 재빠르게 패치시킨 업데이트를 두고 문제점이라 돌려 말했다. 분명 이들은 돈받고 글 쓰는 자들이다.

10 FAS: 10 - Apple’s Mac and iPhone Security Crisis

It Can’t Be Broken Into!
애플이 보안오류를 패치한 뒤, 재빠르게 이론적인 아이폰의 보안문제를 퍼뜨린 이들도 많다. 애플의 업데이트가 아이폰에 써드파티 소프트웨어를 설치하려는 시도를 막았기 때문이다. 아무래도 이들은 인정받은 악성 소프트웨어만 마술처럼 없애줄 보안패치를 기대했던 모양이다. 즉, 자기들이 아이폰에 집어넣으려는 비인증 애플리케이션은 합법적으로 설치가 가능한, 그런 패치를 예상했다는 것이다.

애플의 최신 보안 업데이트의 문제는 그러한 펌웨어가 들어간시스템을 보장해주지 못한다.

Computerworld의 엘간(Mike Elgan)은 아이폰의 펌웨어 해킹 시도를 융통성 있게 해 줄 방법을 열어 줬어야 한다 주장한다. 하지만 애플은 그러하지 않았다. 엘간이 생각한 그 이유는? 애플이 "오만해서"이다.

기술에 대해 잘 모르는 저널리스트들은 그 때 이후로, 애플이 어떻게 사용자들을 "격리(bricked)"시켰는지 떠들어댔다. 그런 일은 일어나지 않았다. 문을 활짝 열고나서, 보안을 적절히 제공해주는 제품은 없다.

Arrogance Unleashed: The Foul Stench of Computerworld’s Mike Elgan

Open Isn’t Magic.
서버에 리눅스를 설치한다면, 원하는 해킹이나 수정을 마음껏 할 수 있다. 하지만 그렇게 해도 시스템이 언제나처럼 안전하리라는 말은 제아무리 리누스 토발즈(Linus Torvalds)도, 리눅스 배포회사도 못한다.

소프트웨어를 수정하면, 새로운 소프트웨어 빌드에 대한 책임도 져야 한다. 웹서버에 필자가 아파치를 설치하고, 수정도 했다면, 다음 버전에서도 그대로 돌아갈지 기대할 수 없다. 필자 고유의 해킹이 커뮤니티의 업데이트와 어떻게 돌아갈지를 염두에 둬야 한다.

마찬가지로, 사용자들이 펌웨어를 멋대로 손질해가지고, 문제 없이 업데이트를 할 수 있는 이상세계는 없다. 애플이 사용자를 격리시켜버렸다고 자동적으로 적는 이들은 현실감각이 없거나, 사기꾼이다.

The Sorry State of Mobile Software.
경쟁 휴대폰 업체나 통신사들도 애플이 "우리의 자유를 증오한다"고 주장하는 대열에 끼어들었다. 이유는? 자신들의 휴대폰이 써드파티용 소프트웨어를 돌릴 수 있어서이다.

휴대폰용 소프트웨어가 안정적으로 뭔가 쓸 만하다면야, 그 주장은 설득력을 지닌다. 하지만 절대 다수는 그렇지 못하다. 휴대폰용 소프트웨어라는 것이 이러하다.

존재하지도 않는 윈도모바일의 문제를 해결한다.
오히려 악성 소프트웨어로 떠 있다. 아무 이유 없다.
가격이 너무 높다.
혹은, 아이폰에서 이미 돌아간다.

써드파티 소프트웨어를 둘러싼 억측

Flip Flopping?
월스트리트저널의 윙필드(Nick Wingfield)는 애플이 "아이폰 소프트웨어 전략을 뒤집었다."고 표현했다. 비판가들이 거론하기 전까지 애플은 전혀 고려하지 않았다는 주장이다.

그러나 현실적으로 아이폰 소프트웨어 개발을 전혀 공개하지 않으리라고 말한 자는 애플이 아니라 오히려 필자였다. 기사 시리즈에서 필자는 애플이 아이폰을 무제한적으로 개발공개하지 않으리라면서 여섯 가지 이유를 제시하였다. 또한 아이폰용 애플리케이션 시장을 애플이 어떻게 서서히 개방할지에 대해서도 논했었다. 가능성이 아예 막히지는 않았다고 말한 것이 다행스럽다.

iPhone 내부 공개는 없다
iPhone은 정말 폐쇄된 플랫폼인가?
iPhone, 어떻게 개방될까?

What Jobs Really Said.
사실 잡스도 애플이 절대로 써드파티를 원치 않는다는 발언을 한 적도 없음을 지적하겠다. 1월달 뉴욕타임스와의 인터뷰에서, 마코프(John Markoff)는 잡스를 다음과 같이 인용하였다.

"아이폰의 모든 것을 정의내렸습니다. 휴대폰도 컴퓨터와 똑같아서는 안되겠죠. 그래도 애플리케이션 세 가지 정도는 있어야 하잖을까요. 그래야 휴대폰을 쓰죠. 컴퓨터라기보다는 아이포드와 더 닮은 형태입니다."

잡스는 이렇게도 지적하였다. "잘 작동해야 해요. 하지만 소프트웨어를 로딩시켜서야 그럴 수 없죠. 그렇다고 해서 아이폰에 설치할 소프트웨어 구매도 불가능해지리라는 뜻까지는 아닙니다. 전부 재작성해야한다는 말도 아니에요. 통제된 환경이라고 봐야 할 테죠."

썬의 조이(Bill Joy)의 지적이 있다. "전세계의 영리한 이들 대다수는 여러분의 조직을 위해서 일하지 않는다." 잡스도 그 점을 분명 알고 있다.

Give Me Something To Work With Here.
언론과 주주들 앞에서 필자가 잡스에게 물었던 점이 있다. 5월달, 필자는 그에게 써드파티나 개인 기업용 개발킷의 여부에 대해 질문했었다. 그의 답변은 개방과 보안문제 간에 균형잡기를 갖고 "노력하는 중"이라 답했다.

6월, All Things Digital 컨퍼런스에서도 잡스는 같은 답변을 되풀이했다. "[써드파티 개발 지원을] 작업중입니다. 몇 가지 좋은 아이디어가 있죠. 아마 하반기쯤, 보안 문제 없이, 써드파티가 애플리케이션을 작성할 방법을 찾아낼 겁니다."

"누구도 완벽하지는 못하지만, 아이폰 충돌은 정말 원하지 않습니다. 이 문제를 해결하고 싶어요. 조금만 인내심을 가져주신다면, 원하는 걸 모두 가질 수 있게 될 겁니다."

즉각적인 답변은 웹 애플리케이션이었다. 사파리의 보안 문서는 잘 알려져있으며, 자바스크립트를 사용한 웹 애플리케이션 구축 시장도 널리 개방되어 있다. 애플의 방안이 그저 "언 발에 오줌누기"밖에 못된다는 불만이 나왔다.

폴 써롯(Paul Thurrott)은 그런 불만이야말로 애플에게 미래가 없다는 신로라 주장했다. 애플은 악이오, 독점자다. 아무래도 그는 나중에 애플이 워싱턴 주 레드먼드에 본사를 뒀다고 불평을 시작할 것이다. 틀림 없다.

Steve Jobs Walks the Tightrope Again - New York Times
Developers see possibilities in iPhone apps - Macworld
2007년 애플주주총회 참관기
An iPhone SDK? Predictions for WWDC 2007!

Adjusted Expectations.
애플 싯가가 1500억 달러에 이른다 하더라도, 애플 총 직원수가 18000명에 불과하다는 점을 잊는 이들이 있다. 비슷한 싯가를 가진 인텔의 직원 수는 88000명이다. 애플은 HP나 IBM보다도 싯가가 높은데, HP의 직원 수는 15만 명, IBM은 35만 명이다. 마이크로소프트 싯가는 애플의 두 배에 이르지만, 직원 수는 애플의 네 배인 79000명이다.

즉, 훨씬 더 적은 인원을 갖고서도 엄청난 가치를 만드는 곳이 애플이다. 즉, 다른 대기업들처럼 정리해고도 똑같이 실시할 수는 없다. 게다가 애플은 매년, 엄청난 주목을 받는 제품을 날로 확대시켜가고 있는 중이다. 게다가 그 성공률도 놀라울 정도로 높다.

현재와 2월달을 비교해 보자. 아이폰 개방에 있어서 과거 있었던 문제를 해결할 시간이 생겨났다. 애플이 아이폰 소프트웨어 시장을 어떻게 개방할지는 두고 볼 일이다.

Less Than Totally Open.
잡스는 "개방성"으로 돈을 벌려하는 노키아를 언급했다. 노키아는 아이폰이 "폐쇄적"이라 주장한다. 알려진 개발자가 추적할 수 있는 디지탈서명이 있지 않으면 애플리케이션 설치가 불가능하다는 이유였다. 잡스의 말이다.

"'완전 개방'과는 좀 다른, 전화기의 문제입니다. 우린 우리의 방향이 올바르다고 보며, 사용자들을 악성 소프트웨어에서 지켜주는만큼, 아이폰의 놀라운소프트웨어 플랫폼에 네이티브로 접근할 수 있을 진보적인 시스템을 작업중입니다."

잡스는 또한 휴대폰용 악성 소프트웨어가 실제로 있는 문제라면서, 바이러스와 같이 배포된다 지적하였다. 그러면서 제일 바이러스에 많이 감염된 휴대폰이 Symbian이라는 사실은 언급하지 않았다. 노키아에게 부끄러운 일이다.

Third Party Applications on the iPhone - Apple

iTunes Store for Developers.
잡스의 발언을 보면, 애플이 "진보적인 시스템"을 제공한다는 의미인 듯 하다. 현재 아이포드의 게임 배포 시스템과 유사한 점이 많을 것이다. 이미 지난 가을 때부터 필자가 언급해 오던 사실이다.

그러면 합법적인 소프트웨어를 추적하여 관라하기도 쉬울 뿐더러, 소프트웨어의 값도 더 낮출 수 있다. 그러면서도 개발자들은 더 많은 돈을 벌 수 있을 것이다.

만약 필자 추측이 맞다면, 아이폰이 소프트웨어 설치 문제와 스파이웨어, 바이러스로 가득찬 또 하나의 PC 플랫폼이 되지는 않으리라던 잡스의 오랜 주장을 해석할 수 있다. 아이폰은 보다 아이포드에 가까워진다는 의미다.

iPhone 인사이드: 써드파티 소프트웨어

애플은 음악과 아이튠스처럼, 소프트웨어 개발자를 위한 메커니즘을 선보일 듯 하다. 저가에 대량으로 소프트웨어를 판매할 시장 조성이다. 그러면 보다 공정한 이윤과 더 넓은 배포 시장이 나올 수 있다.

필자는 파인더 스토어라는 아이디어를 냈었다. 아이포드/아이폰 소프트웨어 플랫폼과 묶을 수 있는 아이디어다. 독립 개발자들도 공정한 몫을 받을 수 있게 된다면? 음악가들과 불법복제 간의 관계처럼, 정직한 구매자들의 구입만으로 이뤄지는 현 시장은 바뀔 수 있다. 즉, 아이폰/아이포드터치용 아이튠스 스토어는 매우 합리적이다.

물론 그렇다고 해서 전문 비판가들의 불만까지 잠재울 수는 없으리라.

What do you think? I really like to hear from readers. Comment in the Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

Steve Jobs Ends iPhone SDK Panic — RoughlyDrafted Magazine

bpwook · 2007-11-25, 08:43 AM

"잘 작동해야 해요. 하지만 소프트웨어를 로딩시켜서야 그럴 수 없죠. 그렇다고 해서 아이폰에 설치할 소프트웨어 구매도 불가능해지리라는 뜻까지는 아닙니다. 전부 재작성해야한다는 말도 아니에요. 통제된 환경이라고 봐야 할 테죠."

이 부분이 약간 문맥이랑 안 맞는 것 같아서 원문을 찾아봤는데요...

“These are devices that need to work, and you can’t do that if you load any software on them. That doesn’t mean there’s not going to be software to buy that you can load on them coming from us. It doesn’t mean we have to write it all, but it means it has to be more of a controlled environment.”
이 부분은 저라면,
"이것들은 동작해야만 하는 장치들입니다. 아무 소프트웨어나 로딩시켜서는 그럴 수 없습니다. 그것은 우리에게서 구입한 소프트웨어만 로딩할 수 있다는 의미가 아닙니다. 우리가 모든 프로그램들을 작성해야 하는 것이 아닙니다. 다만, 그것은 조금 더 통제된 환경이어야만 한다는 것 입니다."
와 같이 해석할 것 같습니다. 우리말로 예쁘게 쓰는 재주는 없어서 좀 지저분합니다만, 의미는 이 쪽이 조금 더 적당한 것 같습니다.

언제나 까소봉님의 해석에 감사하고 있습니다. 건필하세요.

casaubon · 2008-03-14, 12:04 AM

iPhone 2.0 SDK: The No Multitasking Myth
March 13th, 2008 | History, Journal, Markets, Mobiles, Software, Tech, the Media

Daniel Eran Dilger

아이폰 2.0 SDK를 두고 악랄한 우려를 개발해낸 전문가들이 있다. 이들이 말하는 첫 번째 문제는 아이폰이 한 번에 여러 개의 애플리케이션을 돌릴 수 없어보인다는 점이다. 이들에 따르면 오리지날 맥이나 Palm Pilot처럼 아이폰은 멀티태스킹 능력이 떨어지지만, 윈도 모바일용의 WinCE는 그렇지 않다고 한다. 이들은 틀렸다. 왜인지 알아보자.

The iPhone is Unix.
일단 아이폰이 어떻게 돌아가는지, 코어 OS가 어떤지를 보면 된다. 아이폰의 커널은 맥오에스텐의 커널과 같다. 즉, 표준형 유닉스 하부시스템을 구성하는 Mach와 BSD의 하이브리드이며, 다중 프로세서와 다중 사용자를 지원한다.

이 시점에서 Palm OS 또한 멀티태스킹 커널상에서 만들어졌다는 점을 지적해야겠다. 그러나 Palm은 Kadak으로부터 싱글-태스킹 환경만 라이센스받았다. 이 때문에 Palm OS는 80년대 중반의 클래식 맥오에스와 대단히 유사해졌다. 첫 번째 애플리케이션을 종료시켜야 두 번째 애플리케이션이 돌아갔기 때문이다.

애플은 아이폰에서 같은 문제를 겪지 않았다. 애플 스스로 아이폰 커널을 소유하고 있기때문에, 멀티태스킹을 막을 만한 외부적인 기술 제한이 없었다. 아이폰은 전화 통화중에도 Maps 프로그램을 돌릴 수 있으며, 전화 통화가 끝나기 전에 웹페이지 링크를 따라들어갈 수도 있다. 모두 첫 번째 광고에 이미 나온 기능이다.

웹브라우징을 할 때 전화가 울리고, 다른 작업을 할 때 백그라운드 상에서 음악이 돌아가며, 메일도 확인한다. 확실히 멀티태스킹을 한다는 얘기다. 그렇다면 SDK 문서는 어째서 "한 번에 하나의 아이폰 애플리케이션을 돌릴 수 있다."라 쓰여 있을까? 아이폰이 클래식 맥이나 Palm Pilot과 똑같은 구조적인 문제는 일단 없다는 점부터 시작해 보자.

iPhone의 BSD 유닉스
어처구니 없는 Palm의 실수연발

Multitasking Macs before Unix.
오리지날 맥은 다중 애플리케이션을 한 번에 돌릴 만한 자원을 갖지 못했다. 첫 번째 맥 사용자들은 한 번에 하나의 애플리케이션만 돌릴 수 있었는데, 이는 심각한 제한이었다. 1985년, 앤디 허츠펠드(Andy Hertzfeld)는 Switcher라는 유틸리티를 만들어서, 활성화중인 애플리케이션을 중지시키고 새 애플리케이션을 돌릴 수 있도록 했었다. 1987년, 애플은 동시에 여러 개의 애플리케이션을 보여주고, 그 사이를 빠르게 이동시켜주는 MultiFinder를 출시한다.

그러나 클래식 맥은 유닉스-스타일의 선점형 멀티태스킹을 하지 않았다. 선점형 멀티태스킹이란, 운영체제가 활성화중인 애플리케이션에게 프로세싱 자원을 엄격하게 관리하여 부여하는 방식이다. 클래식 맥은 그 대신 협력형 멀티태스킹을 사용하여 프로세서 상에서 순번을 바꾸는 식에 의존하였다. 즉, 애플리케이션 하나가 무한루프에 들어가게 되면, 전체 머신이 멈춰지는 문제를 야기할 수 있었다.

유닉스에서는 이런 일이 일어나지 않는다. 프로세스를 신뢰하지 않기 때문이다. 커널이 이 프로세스를 관리하는데, 작동이 멈춰지면, 그 작동을 넘어서서 시스템 차원에까지 영향을 끼치지는 않게 된다. 시스템 자체를 멈추게 될 프로세스는 커널 그 자신이다. 즉, 커널 상의 모든 소프트웨어는 극단적으로 안정적이다. 이 때문에 애플은 개발자들에게, 불필요할 경우, 되도록이면 커널 익스텐션으로 프로그램 작성을 하지 말도록 권장한다.

Folklore.org: Macintosh Stories: Switcher

Just Because You Can, Doesn’t Mean You Should.
아이폰은 유닉스의 ‘kernel in command’ 아키텍쳐를 갖고 있다. 하지만 동시에 여러 가지 애플리케이션을 돌릴 수 있다고 해서, 개발자들에게 이를 무조건 허용하는 것이 좋다는 의미는 아니다. 맥오에스텐에서 여러 가지 애플리케이션을 활성화시키는 일은 그다지 큰 문제를 일으키지 않는다. 시스템이 RAM 한도를 벗어나는 경우, 시스템은 비활성중인 애플리케이션을 하드드라이브 상의 가상메모리에 집어 넣는다. 다시 활성화시킬 때까지 동면시키는 것이다.

아이폰의 가상 메모리 시스템도 같지만, 기가바이트 급의 RAM이나 가상메모리 스왑공간이 충분한 하드 드라이브까지 갖고 있진 않다. 아이폰의 RAM은 128MB이며, VRAM이 11MB 정도이고, 시스템이 점유한 용량이 19MB 정도이다. 즉, 사용자가 사용할 수 있는 메모리는 76MB 정도다.

백그라운드 프로세스 양을 조절해야, 아이폰의 오에스텐은 우선 활성중인 애플리케이션에 더 많은 RAM을 할당시킬 수 있다. 아이폰은 일반적인 목적의 컴퓨터가 아니며, 휴대폰과 브라우저, 아이포드의 합체이다. SDK가 야기한 제한때문에, 아이폰은 상당한 게임용 플랫폼이면서, 바로 사무용 애플리케이션으로 돌아갈 수도 있다. 이 모두가 휴대폰 자체의 기능과 브라우징, 아이포드를 희생시키지 않아도 된다. 다른 기기들은 그렇지 못하다.

furbo.org · What the iPhone specs don’t tell you
Mac OS X 마이크로커널의 미신을 벗긴다 1-3

The Problem With Background Processes.
물론 아이폰은 보통의 스마트폰 RAM의 두 배를 갖고 있지만, 백그라운드 프로세스가 돌아간다고 하면 76MB 정도는 우스워진다.

RAM만이 아니다. 미디어 재생과 WebKit 렌더링, 전화와 라디오신호 처리, VoIP 데이터암호화, 푸시 이메일과 문자 메시지, 정보 관리 모두가 제대로 돌아가지 않으면 안될 필수 기능들이다.

휴대폰의 핵심 기능이 사용할 광대역 외에도, 프로세서가 소비하는 별도의 백그라운드 프로세스가 생기면, 전화기는 뜨거워지고, 전기도 닳아서 배터리 수명이 짧아진다. 결국 기기 자체의 수명도 줄인다는 얘기다.

따라서 아이폰이 생각한대로 움직이도록, 발열이 심해지지 않도록, 새 애플리케이션을 설치해도 배터리 수명에 지장이 없도록 해야 할 가이드라인을 지정해줘야 한다. 그것이 애플의 책임이다. 써드파티가 멋대로 백그라운드 프로세스를 잡아먹게 놓아 둬서는 안된다. 개발자들에게 문을 활짝 연 뒤에, 프로세서 관리를 못한다면서 사용자를 타박해서도 안된다. 무책임한 행동이다.

iPhone의 OS X: Mach 커널과 RAM

The Problem with Foreground Multiprocessing.
백그라운드 문제만 있지는 않다. 전면부(foreground)에서 돌아가는 다중 애플리케이션의 문제도 있다. 물론 아이폰은 분명 어디서든지 다중 애플리케이션을 한 번에 돌릴 능력을 갖추었다. 전화 받으면서, 홈스크린으로 되돌아간 다음 다른 애플리케이션을 돌릴 수 있으니 말이다. 통화중에는 화면 최상단에 녹색 막대가 나타나서, 언제든 전화중 상태의 화면으로 되돌아갈 수 있다.

다른 애플리케이션(물론 이 경우 Safari는 웹페이지를 돌아다니다가 충돌을 일으킬 경우가 잦다)이 돌아갈 때 아이튠스는 오디오를 돌릴 수 있다. 어디에서건, 아이포드 재생 컨트롤러 Home 버튼을 더블클릭해서 아이포드 재생 컨트롤러를 화면상에 불러들일 수 있다.

두 사례 모두 보면, 화면 인터페이스에 다소 제약이 있다. 일부러 그런 것이다. 돌아가고 있는 다른 애플리케이션이 없으면, 활성화중인 애플리케이션과 중요한 백그라운드 프로세스에 더 많은 자원을 할당할 수 있다. 위에 언급한 바와 마찬가지이다. 이뿐만이 아니다. 사용자 입장에서 인터페이스도 크게 단순해진다.

아이포드 기능도 주요 기능이기는 하지만, 아이폰은 휴대폰이기에 독특한 면이 있다. 하지만 프로세서 안에서 모든 애플리케이션이 자기 자리를 점유해버린다면, 남는 자리가 안 생길 것이다. 더군다나 아이폰 디스플레이는 그 많은 애플리케이션이 다 뜰 만큼 크지도 않다. 물론 그럴 수도 있겠지만 휴대용 기기에 적절하지 않은 인터페이스로 만들어 놓고 애플릿을 구겨 넣은 다른 곳보다 애플은 더 휴대용 기기를 더 잘 알고 있다.

Rocket Launching.
시스템 정책을 따르기보다 애플리케이션 스스로가 결정을 내리도록 해야 한다는 의견이 들리기는 좋을지 몰라도, 실제로는 그리 좋지 못하다. 사실 애플의 정책은 사파리에 대한 써드파티 애플리케이션과 동일하다. 사용자가 Home 버튼을 눌렀을 때, 시스템은 현재 애플리케이션 데이터를 저장한 다음, 애플리케이션을 종료시키고, 애플리케이션 메뉴가 있는 Springboard를 내놓는다. 다음에 애플리케이션을 다시 활성화시키면, 종료됐을 때와 같은 상태로 시작한다.

이 활성화 시간이 너무나 빠르기에, 사용자 입장에서는 가상 메모리 상에서 돌아가는 애플리케이션을 다시 불러들이는 것이나, 종료시켰다가 필요해서 다시 활성화시키는 것이나 별 차이 없다고 느끼게 마련이다. 물론 기술적인 차이는 있다. 애플리케이션 종료가 배터리 수명 등, 자원 사용에는 더 효율적이다. 사용자들도 그것을 알아차릴 것이다.

이 때문에 애플은 SDK에서 이렇게 적고 있다. "한 번에 하나의 아이폰 애플리케이션을 돌릴 수 있으며, 써드-파티 애플리케이션은 백그라운드에서 돌리지 않는다. 사용자가 다른 애플리케이션으로 전환시키거나, 통화를 하고 이메일을 확인할 때, 해당 애플리케이션은 종료된다는 의미다."

Invent, Suggest, Panic!
엔지니어링에 대해 잘 모르는 블로그들이 있다. 이름도 기가 막히게, BoyGenius Report라고 되어있는데, 이곳이 최근 써드파티 애플리케이션도 백그라운드에서 돌아가게 해달라며, 동등한 권리를 요구하는 청원에 나섰다. 종료시킬 필요 없이 애플리케이션간에 전환이 가능하게 해 달라는 것이다. 듣기에는 좋게 들린다. 하지만 제대로 알고 하는 얘기일까?

엡슈타인(Zach Epstein)은 아이폰에 "진정한 멀티태스킹이 없다"면서, 개발자인 발루섹(Robert Balousek)을 인용하였다. "AOL 인스턴트 메신저같은 애플리케이션을 돌린다면, 통화가 오거나 브라우징을 할 때마다, 나중에 다시 로그인해야 할 것이다. 못읽은 메시지는 영원히 못읽게 되고, 대화는 끝이다."

그러나 콕스(Christopher Cox)는 이런 지적을 했다. "이 글 저자는 크게 오버하고 있다. [...] 간섭이 있을 때, 애플리케이션이 정지해서, 현재의 데이터를 저장하게 된다. 다시 애플리케이션을 돌리면, 예전 메시지는 여전히 남아 있다. [...] AIM 서버도, 프로그램이 접속 끊기 신호를 보낸다거나, 특정 시간 이상 연결되어있지 않는 이상, 접속을 끊지 않는다. 즉, AIM 애플리케이션으로 되돌아가면, 메시지도 바로 나타난다는 의미다. 재접속 할 필요가 없다. 물론 AIM에 24시간 내내 접속해 있고 싶다면야, 단점이 될 것이다. 그 뿐이다. 그러나 대부분은 그럴 정도의 마음가짐을 갖고있지 않다."

iPhone SDK Honeymoon Over - No Background Processes?! | The Boy Genius Report

What Would Happen If Apple Didn’t Know Any Better.
아이폰 SDK와 관련, 멀티태스킹이 안되리라는 주장이 헛것이라는 점을 알았다. 잘못된 정보다. 그런데 혹시, 애플이 제한을 가하지 않을 경우 아이폰이 어쩌면 더 나아질 가능성은 없을까? 추측할 일도 없다. 듣기 좋은 발린 단어 나열만 좋아하는 위원회 식의 엔지니어링을 통해, 만들어진 확실한 사례가 있기 때문이다. 마이크로소프트의 WinCE이다.

마이크로소프트는 WinCE를 유닉스와 같은 멀티태스킹 아키텍쳐로 간주하지만, 가상메모리 구조를 갖고 있기는 해도, 동시에 돌릴 수 있는 프로세스가 32개에 불과하다. 또한 각각의 프로세스가 갖는 가상 어드레스 공간 또한 32MB 뿐이다. 하지만 이 정도 사양도, 수 년 후에나 널리 쓰일 WinCE 6.0 사양이다. 그 때까지 멀티태스킹 WinCE라는 주장은 근본적으로 오류다. 물론 실상은 그보다 더 열악하다.

멀티태스킹 기능을 효율적으로 사용하지 못하게 막으면서도, WinCE는 써드파티의 백그라운드 프로세스만은 제한이 두지 않았다. 하지만 휴대용 기기에서 다중의 애플리케이션을 돌리는 것은 좋지 않다. 그 이유는 많다. 첫 번째 이유는 필자가 이미 명시한, 자원 사용의 문제다. 필자 대신, WinCE 옹호자인 헤러라(Chris De Herrera)의 말로 해 보겠다.

"한 번에 여러 가지 애플리케이션을 돌려놓으면, 전면부 애플리케이션이 눈에 띄게 느려질 때가 있다. 이런 현상은 운영체제가 백그라운드 애플리케이션에게 자원을 써 주어야 하기 때문이다. 이 때 필자가 권장하는 바는, 소프트웨어의 재시동이다."

Like kill on the road,
Windows has failed to respond.
Control! Alt! Delete!

그런데 또 하나의 이유가 있다. 같은 시간에 그 많은 걸 들여다 볼 화면이 없다는 것이다. 실질적인 화면 크기가 정해져 있기에, 데스크톱처럼 다중의 겹쳐지는 창과 제목막대, 창끼리 전환하는 기능을(Lisa가 최초로 보여준 기능이다) 들여다보는 것이 실질적으로 유용하지 않다. 하지만 마이크로소프트는 아랑곳하지 않고, 90년대 후반 이후, 맥 데스크톱 UI를 베낀 윈도를 그 조그마한 화면에 애써 구겨 넣었다.

그러니 팔릴리가 없다. WinCE 기기는 너무나 복잡해져서 그걸로 뭘 어떻게 할지 이해하기도 힘들어졌다. 게다가 충돌도 잦고, 배터리 수명도 절망적이었다. 아이폰은 너무나 간단해서, 일단 돌려본 다음, 별다른 훈련 없이 잘 쓸 수 있다. 그저 잘 돌아가는 아이폰이다. 애플이 Dock과 Finder 데스크톱을 아이폰에 구겨 넣으려 했다면, 아이폰 역시 절망적으로 안팔렸을 것이다.

WinCE와 Windows Mobile의 처절한 실패사

Less is More; More with Less.
아이폰은 WinCE에 비해 더 나은 멀티태스킹 커널을 갖고 있다. 서류상에 나온 모든 기능을 다 하려들다가, 결국 아무 것도 잘 못해고 팔리지도 않는 기기를 만들어내는 마이크로소프트식 시스템이 아니다. 애플 엔지니어들은 아이폰 2.0 SDK에 제한을 가해서 사용자에게 더 유용한 애플리케이션을 덧붙이도록 할 것이다.

새 소프트웨어가 나오기도 전에, 기존 아이폰 판매량은 이미 미국 내에서 윈도 모바일 휴대폰의 판매량을 크게 넘어섰다. 아이폰의 스마트폰 시장 점유율은 27%이고, 모든 모바일 웹 트래픽의 71%를 차지하는 휴대폰이 아이폰이다.

마이크로소프트는 데스크톱 PC와 마찬가지다. 복잡함을 벗어나 WinCE를 애플 아이폰처럼 만들기는 불가능할 것이다. 이미 나와 있는 윈도 모바일 애플리케이션들이 모두 프로세서 백그라운드에서 돌아갈 권리를 갖고 있어서, 스마트폰을 느리고, 비효율적으로 만들기 때문이다. 제일 열광적인 윈도 옹호자들조차 끌지 못할 정도로 복잡해진 것이 윈도 모바일이다.

아이폰도 당연히 똑같은 문제를 겪어야 한다고 주장하는 꼴을 보니, 실용성과 단순성을 그들이 왜그리 이해못하는지 확실히 알 만하다.

iPhone과 경쟁하기 - 소프트웨어

What do you think? I really like to hear from readers. Comment in the Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

iPhone 2.0 SDK: The No Multitasking Myth

casaubon · 2008-03-17, 09:37 PM

iPhone 2.0 SDK: Java on the iPhone
March 14th, 2008 | History, Journal, Markets, Mobiles, Software, Tech, the Media

Daniel Eran Dilger

아이폰 SDK가 나온지 얼마 안 되어서, 썬이 아이폰용 자바 Micro Edition 플랫폼을 선보이겠다는 발표를 하였다. 애플이 허용할 경우, 썬이 과연 그런 플랫폼을 내놓을지, 도대체 이것이 아이폰 사용자들에게 어떤 의미가 있는지에 대한 문제가 남아있다. 더 흥미로운 점도 있다. 자바가 어디에서 왔는지, 휴대기기 영역에서 어디로 향할지이다.

A Window into Sun’s Java.
Xerox PARC에서 그래픽 데스크톱을 해방, 매킨토시로 가져온 스티브 잡스는 애플을 떠나서 NeXT를 설립한다. 그 후 그는 제록스에서 개척한 여러 가지 다른 개념을 갖고 여러 프로젝트를 관리하기 시작한다.

device independent graphics: 제록스에 있던 존 워녹(John Warnock)은 PostScript를, 후에는 어도비에서 PDF를 만든다.
standard networking: 제록스의 봅 멧카프(Bob Metcalf)가 고안했으며, 후에 3Com이 Ethernet으로 상용화시킨다.
object oriented coding: 제록스의 Smalltalk이다. 브래드 콕스(Brad Cox)가 C와 혼합시켜서 오브젝티브-C가 된다.

넥스트는 오브젝티브-C를 채용하였고, 그 결과 독특한 기능을 갖게 되었다. 애플의 맥처럼 90년도 당시 데스크톱 개발환경은 대부분 파스칼을 사용하였다. 마이크로소프트 DOS와 윈도는 C/C++이었다.

1988년, 넥스트스텝(NeXTSTEP) 개발프레임웍과 함께 견고하게 통합되어 있던 오브젝티브-C는 마이크로소프트의 MFC보다 훨씬 강력하고 쉬운 개발 환경을 제공했다. 당시 MFC는 C 윈도 API 상에 얇은 C++ 기능을 제공하는 정도였다. 마이크로소프트는 2000년 .Net이 등장하기 전까지, 넥스트에 견줄 만한 개발 프레임웍을 전혀 제공하지 않았다.

맥을 베낀지 10년 후, 잡스와 제휴한 뒤, 잡스의 기수을 베낀다는 마이크로소프트 전략 상대는 썬 마이크로시스템즈였다. 썬과 넥스트는 1993년, 썬 Solaris용 넥스트 개발환경을 만들기 위해 협력한다. 시스템 포팅을 하고, OpenStep 사양(누구나 NeXT 애플리케이션을 자기 운영체제에서 돌릴 수 있는 사양이다)을 1994년에 개발한 뒤 1996년, 썬은 관심을 다른 프로젝트로 돌린다. 자바였다.

iPhone용 OS X과 WinCE, Palm, Symbian, 리눅스
Yellow Box의 죽음, 그리고 Cocoa

Sun Brews a Familiar Tasting Platform.
Java는 다음을 포함하였다.

Java language와 컴파일러
Java Virtual Machine: 플랫폼 독립적인 바이트코드를 돌리는 가상머신
Java API framework: 클래스 라이브러리

자바 언어 신택스는 C++에 기반을 두었지만, 자바의 객체 모델은 오브젝티브-C에서 빌려왔다. 자바 API도 NeXTSTEP 프레임웍에서 대거 빌려 왔다. 썬의 자바만이 아니었다. 애플과 IBM(그리고 나중의 HP)도 Taligent의 일부로서 넥스트 프레임웍을 대거 베꼈다. 반면, 마이크로소프트만은 일단 약속먼저 하였다. 빌 게이츠가 1991년, Cairo 프로젝트를 약속한 것이다. 그리고나서 5년이 흘렀다. 썬만이 넥스트스텝 프레임웍에 견줄 만한 뭔가를 만들어냈을 뿐이다. 그것이 1995년에 나온 자바 1.0이었다. Taligent 일부도 결국 자바 API에 흡수되었다.

90년대 하반기 내내 기술업계는 자바로 들끓었다. 처음에는 느리고, 성숙이 덜 되어 있으며, 미완성되었다는 평을 들었지만, "한 번 작성, 어디서나 실행(write once, run anywhere)"이라는 점때문에 잠재성을 본 이들은 매우 많았다. 마이크로소프트만은 그 잠재성을 윈도에 대한 위협으로 간주하였고, 자바의 크로스 플랫폼 기능을 파괴시키기 위해 상당한 노력을 기울인다. 자바를 단순히, 또 다른 윈도용 애플리케이션 구축 방식으로 만들어버린 것이다.

넥스트를 인수한 뒤, 애플은 자바를, 새로 인수한 넥스트 소프트웨어를 광고할 수단으로 보았다. 애플은 자바 개발자들의 친숙성을 위해, 오브젝티브-C 신택스를 다소 변경하는 것을 고려하였고, 오브젝티브-C 대신, 자바 언어를 사용할 수 있도록 자바 브릿지를 제공하기도 하였다. 또한 새로운 넥스트-기반 프레임웍을 Cocoa로 변경하였다. 같은 프레임웍으로 썬이 밀었던 자바 환경에 대응하는 이름이랄 수 있었다.

1990-1995: 핑크와 탈리전트, 코플랜드의 비밀
1990-1995: 카이로로 가는 머나먼길

The Caffeine Buzz Wears Off.
원래 썬이 자바로 노렸던 것은 모든 플랫폼의 플랫폼이었다. 여러 플랫폼용 자바 Runtime Environment을 개발하면서, 썬은 모두가 자바코드로 한 번 자바 애플리케이션을 작성하는 시장을 희망하였다.

Win32 API를 사용하는 언어가 무엇이건 간에, 자바 코드로의 작성이었다. 썬은 또한 자바가 웹의 공통언어가 되기를 바랬다. 웹페이지의 모든 인터랙티브 애플릿이 자바로 이뤄지기를 바란 것이다.

마이크로소프트는 썬의 희망이 죽기를 희망하였다. 그런데 썬이 되려 마이크로소프트를 돕는다. 자바는 웹이나 데스크톱 애플릿 상에서 그리 훌륭한 퍼포먼스를 내지 못하였다. 윈도에서 자바를 제대로 돌리고 싶었던 썬은 맥이나 다른 플랫폼용 JRE를 소흘히 하였고, 웹 플러그인도 제대로 안 돌아갔다. 게다가 사용자 인터페이스 툴이 3류였기에, 자바 애플릿의 외양은 하나같이 끔찍했다. 느리고, 못생겼으며, 사용이 불가능하다는 명성을 얻자, 마이크로소프트의 공작은 빠른 성공을 거두게 된다.

이와 반면, 같은 기간동안 훨씬 더 약했던 애플도 마이크로소프트로부터 압박을 받는다. 퀵타임을 죽이라는 압박이었다. 그러나 퀵타임 환경은 살아남는다. 애플은 윈도용 퀵타임 구현의 통제권을 마이크로소프트에게 위임하거나, 협력하지 않았다. 반면 썬은 자바를 두고 어리석게도 마이크로소프트와 협력했었다.

서버 측면에서 보면, 자바는 극도로 가치가 높다. 썬은 웹서버 개발에 있어서 자바를 성공시켰다. 웹서버의 경우, 상당한 하드웨어 자원이 있기에, 자바의 퍼포먼스 문제를 해결할 수 있으며, 사용자 인터페이스가 별 문제가 되지 않는다. 썬이 웹서버용 자바를 민 이유는, SPARC 서버를 판매할 하나의 수단이기도
해서이다. 당시 마이크로소프트는 모든 것을 윈도-PC 전용으로 내세우려던 때이다. JVM 포팅만 되면, 자바는 어디에서건 돌릴 수 있다. 이 이유때문에, 수많은 웹 애플리케이션 서버가 자바로 포팅되었다. 그 중에는 애플의 WebObjects도 있다.

퀵타임을 죽여라

Jittery Handheld Desperation.
서버 영역의 성공을 거둔 것 이외에, 썬은 간소화시킨 자바인 자바 ME(원래는 J2ME였다. SE는 표준 에디션, EE는 기어용 에디션으로 나눠서였다. ME는 마이크로 에디션)로 휴대용 기기를 노린다. 썬은 심지어 자바 ME가 "휴대용 기기에 있어서 제일 유비쿼터스인 애플리케이션 플랫폼"이라고도 말하였다. 상당한 수의 휴대폰 업체들이 각자 자바 ME를 만들어서이다.

문제는 휴대폰이 컴퓨터보다 일관적이지 못하다는 데에 있었다. 따라서 자바는 전반적으로 실패한다. 데스크톱만 보더라도, 유명한 자바 애플리케이션은, 파일공유용인 Limewire와 Azureus 정도밖에 없다. 맥이 100% 순수 자바 개발용이라 애플이 손수 광고해도 이 정도이다. 이유가 있다. 자바를 가지고 윈도와 맥, 리눅스를 상호 연결하기보다, 일단 집에서 사용하는 개발툴을 갖고 개발한 다음, 애플의 네이티브 Cocoa 프레임웍을 사용하여 크로스 플랫폼 포팅을 하는 데에 더 관심이 많아서이다.

Java ME in the Mobile World.
휴대용 기기만 보면, 자바 상황은 더욱 안좋다. 제약은 훨씬 더 많으면서, 기기별 차이점은 대단히 크다. PC 영역의 마이크로소프트처럼, 썬도 Connected Limited Device Configuration과 Mobile Information Device Profile(자바 ME 사용자 인터페이스의 휴대폰용 최소 규약이다)을 출판시키는 등, 표준화를 위해 노력하였다.

썬은 JRE 구현을 휴대폰 업체들에게 맡기는데, 이 때문에 모든 자바 ME 휴대폰은 약간씩 다른 기능을 제공하면서, 똑같은 애플릿도 각자 다르게 구현하였다. 이 때문에 "한 번 작성, 어디서나 디버그"라는 악평을 얻게 된다. 마이크로소프트도 윈도를 PC 업체들에게 아예 맡겨버리진 않았다. 그랬다가는 윈도용 애플리케이션이 각기 하드웨어별로 다르게 나왔을 것이다. 좋아질리가 없다.

Java ME는 스마트폰 개발에 있어서도, 상당한 제약에 발목 잡힌 상태다. 휴대폰은 통신사들이 휴대폰 디자인을 해버리고, 스스로 통신망을 통제해버리는 산업이기 때문이다. 자바 ME 애플리케이션은 보통 1MB 이하 크기인데, 통신사 통신망은 보통 전송량을 300KB로 제한한다. 이 때문에 자바 ME 소프트웨어 대부분을 간단한 게임으로 전락시켰다. 게임이 아니더라도, 특정 휴대폰의 장점을 못살리는 자잘한 프로그램밖에 못 되었다.

Texas Holdem의 J2ME 버전이 아래의 위 그림이다. 밑에는 Palm OS 버전과 아이포드용 버전, 그리고 Verizon의 BREW 버전이 나와 있다.(클릭하면 커진다.) 특별할 것이 없다. 아이폰용 버전이 아이포드용보다 더 나으리라 기대할 만하다.

Why Would Anyone Want Java ME on the iPhone?
자바 ME(J2ME) 환경을 아이폰에 넣는다는 말은, 맥에 CP/M 환경을 넣는다는 말과 유사할 것이다. 아이폰을 산다면, 아이폰의 깔끔하고 사용하기 쉬운 인터페이스때문에 사는 것이다. 여기에 무거운 자바 ME 런타임을 설치해서 어리둥절할 이유가 없다.

훨씬 떨어지는 휴대폰용 소프트웨어 애플릿에 향수를 느낀 나머지, 썬은 아이폰에 누군가 자바 ME를 설치하리라 희망하는 모양이다. 그것이 1년 전, ABI Research의 분석가 솔리스(Philip Solis)의 마음이었다. 그는 아이폰이 J2ME 휴대폰에서나 돌리는 쓰레기 소프트웨어를 못돌린다면서, 써드파티 소프트웨어가안돌아가니 아이폰도 스마트폰이 아니라 주장했었다.

썬에게는 큰 문제가 있다. 애플이 별도의 API 런타임을 아이폰에 업로드하지 않기 바란다고 말했기 때문이다. SDK 동의서를 보면 이런 글이 있다. "플러그인 아키텍쳐를 통해, 혹은 다른 프레임웍이나 API를 호출하는 식을 포함한, 그 어떤 방식으로도 애플리케이션이 다른 실행가능 코드를 설치하거나, 실행시키지 못한다. 애플의 Published API와 내장 인터프리터가 돌리는 코드를 제외하고, 애플리케이션에서, 그 어떤 인터프리티드 코드를 다운로드하거나 사용할 수 없다."

즉, 자바 ME JRE를 가볍게 거부한다는 의미다. 자바 ME MRE는 자바 API를 사용한 인터프리티드 코드로서 자바 애플릿을 읽거나 실행한다. 그러고보니, 이 규칙은 어도비 Flash와 마이크로소프트 Silverlight도 배제하게 되어 있다.

iPhone, 누구를 위협하는가
써드파티 소프트웨어를 둘러싼 억측

Is Apple Going Too Far?
혹시 애플이 아이폰 팔려고 너무 나가는 것은 아닐까? 차라리 모든 하드웨어 업체들에게 아이폰 소프트웨어를 독점적으로 라이센스시키고, 휴대폰용 소프트웨어 시장을 독점화시킨다면, 그 말이 맞을 것이다.

그러나 다행히도 애플은 고유의 사업방식을 갖고, 휴대폰 시장에서 경쟁을 벌일 뿐이다. BMW가 라디오 번들을 시키기 위해, Bose와 파나소닉, 소니 등 모든 업체에 라이센스 계약을 맺어야 할 이유가 없듯, 굳이 썬을 초대해서, 자바 ME API라는 경쟁상대에게 의자까지 안겨다줄 이유가 없다. 모든 휴대폰용 소프트웨어를 독점화시키고 다른 경쟁자의 진입을 막는 마이크로소프트 방식을 따랐다면, 물론 다른 문제가 됐을 터이다.

통합된 하드웨어 업체로서 애플의 사업방식과, 소프트웨어 라이센스 거간꾼으로서, 강을 지나다니는 모든 배에게 통항세를 받는 해적이기도 한 마이크로소프트의 사업방식은 크게 다르다. 애플은 썬의 jPhone을 막지 않았으며, 제한하지도 않았다. 자바 ME를 휴대폰에 밀어 넣으려는 썬의 시도에 개입하지도 않았다.

Sun, 아이폰 경쟁에 뛰어들다

A Reversal of Fortune for Sun and Microsoft.
아이러니컬하게도 썬은 이미 마이크로소프트가 WinCE/윈도모바일로 가진 거간꾼의 위치를 이미 점유하였다. 휴대폰 대부분에 J2ME가 들어갔기 때문이다. 그러나 J2ME는 크게 뒤쳐졌으며, 선택사항도 허술하고, 호환성도 별로 안좋으며, 통신사들이 여러 가지 게임만 내세우려하는데, 굳이 설치하려는 사용자들은 거의 없다. 데스크톱의 마이크로소프트와, 휴대폰의 썬이 매한가지라는 의미다. 애플이 휴대폰 영역을 확장시킬수록, 썬은 잃을 수밖에 없다.

자바는 한 가지 휴대폰만 빼고, 거의 모든 휴대폰에 다 들어가 있다. 그런데 사람들이 이야기하고, 해외에서까지 비싼 값을 주고 이용하고야 마는, 게다가 심각나 애플리케이션 계획이 놓여 있는 휴대폰이 바로자바가 없는 그 휴대폰이다. 썬도 파티에 참가하고 싶을 것이다. 하지만 맞는 드레스가 없다. 자바 ME 드레스?

썬은 넥스트와 파트너를 맺었다가 포기해버린 전력을 갖고 있다. 심지어 그 후, Lighthouse Design을 인수하여 넥스트용 애플리케이션 출시를 막은 뒤 포기해버리기도 하였다. 되려 공포에 떨 만하다. 넥스트에서 가져온 개념으로부터 떨어져 나왔지만, 넥스트 소프트웨어가 10년 후 휴대기기 영역을 뒤바꿀지 미리 알았더라면, 좀 다른 결정을 내렸을지 모르겠다. 애플 아이폰 잠수함이 부상하면서 마이크로소프트 윈도 모바일은 물론, 썬의 모바일 구상까지 점차 흐트러지고 있다.

What do you think? I really like to hear from readers. Comment in the Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

iPhone 2.0 SDK: Java on the iPhone?

aingoppa · 2008-03-18, 03:28 AM

이 아저씨가 자기가 아는 게 많으니 자기 말이 맞다고 하는 것처럼 자주 느껴졌는데, 이번에 iPhone의 Background Process에서 하는 말을 보니 정말 뒤집어질 것 같습니다. 나중에 Apple이 이 부분을 지원해 주기라도 하면 그 때 어떤 말을 할지 정말 기대됩니다.

Camus · 2008-03-19, 01:06 AM

aingoppa 님, 좀 더 자세히 설명해 주시면 재미있을 것 같습니다.

언급하신 내용들을 조금 풀어서 설명해주실 수 있으신가요? 궁금하네요~

aingoppa · 2008-03-19, 03:23 AM

홧김에 글을 적어버려서 좀 그렇네요.

전에 Steve Jobs가 말한것처럼 iPhone이 crashing machine이 되지 않는 절충선에 있는 SDK라고는 생각 되긴 합니다. iPhone에 대한 직접적인 접근 대신 여러 고급 API를 제공해서 깔끔하고 안정정인 Application을 만들 수 있기도 합니다. 그렇다고 해서 Background process같은 것을 지원하지 않고 그것이 바보같은 프로그래머의 어리석은 자원 남용을 막는 좋은 방법이라고 말해버리면 그걸 읽고 프로그래머들이 좋아할 수 있을까요.

이번에 SDK가 나오면 만들고 싶었던 것들이 몇가지 있었습니다. 하지만 Apple에서 거부 메일을 받고 실제 SDK의 한계가 보여서 재미가 없네요. Apple에서도 같은 Tool을 사용해서 만든다고 하던데 Framework도 정말 같은 것을 사용하는지 궁금하기도 합니다.

seungjin · 2008-03-19, 10:25 AM

인용:

aingoppa 님이 쓰신 글

Apple에서 거부 메일을 받고 실제 SDK의 한계가 보여서 재미가 없네요.

전 Apple id로 접속했더니, $99 내라고 하길래 바로 브라우져 닫아 버렸는데,
애플에서 하라고 해도, 할지 안할지 망설여 지내요. (물론 꽁자면 합니다.)

안드로이드가 나오면 어떻게 변할지 궁금합니다.

javanese · 2008-03-19, 11:33 AM

음.. iPhone SDK를 아직 제대로 살펴보지는 못했습니다만.. 저로서는 개별 애플리케이션이 Background Process로 돌지 않도록 막은 것은 오히려 개발하기 편하다고 느낍니다. 꼭 자원 남용을 하지 않더라도 애플리케이션 여러개가 동시에 떠있는 것 자체가 부담되지 않나요? WinCE 사용하면서 제일 짜증나는게 태스크 관리라서.. 사용자 입장에서도 한번에 하나 동작한다는 가이드라인은 오히려 깔끔할 것 같습니다.

물론 애플리케이션 특성상 Background Process가 필요할 수도 있지만 그런 애플리케이션에는 별도의 정책을 두는 것이 타당하다고 봅니다. 원 글의 저자가 강조하는 것은 더 나은 multi thread 환경을 갖추고도 남용하지 않는 기본 정책을 칭찬하는 것일 뿐이고, Background Process의 의미도 로우레벨 프로세스라기 보다는 화면에 나타나지도 않으면서 의미없이 동작하는 애플리케이션의 의미로 한정하고 있는 것 같습니다. 알람 같은 것을 구현하려면 물론 Background Process가 필요하겠지만 그런 것까지 포괄해서 쓸데없다고 하는 의미는 아닌 것 같네요. 그런 것을 구현하기 위한 메커니즘은 따로 제공되리라 생각됩니다. (이미 있을지도?)

오히려 걱정되는 것은 애플리케이션 스위칭 할때마다 새로 프로세스를 시작하다보니 컨텍스트 유지와 시동 시간의 이슈가 있겠지만 뭐 그거야 각자 알아서 해결해야겠죠. preinstall 되어 있는 애플 제공 애플리케이션들도 컨텍스트 유지를 전혀 안해버리니 좀 불편한 감은 있지만 일관되게 적용되는 것이라 크게 거부반응은 없는것 같기도 합니다.

casaubon님 번역 감사합니다. 정말 재미있게 잘 읽었습니다.

2007-11-21, 07:46 AM	#1
casaubon Moderator Registered: Sep 2001 My Mac: MacBook Air Posts: 2,140 오프라인	iPhone SDK 2.0 Steve Jobs Ends iPhone SDK Panic October 17th, 2007 \| Markets, Mobiles, Software, Tech, the Media Daniel Eran Dilger 2월에 아이폰/아이포드 터치용 소프트웨어 개발킷을 선보일 예정이라는 공식적인 발표가 나왔다. 애플이 써드파티 개발자들을 박해한다고 떠들던 입들이 무색해졌다. 올해 초, 아이폰의 선 이후, 모든 맥 개발자들 입장에서 볼 때, 갑자기 아이폰 소프트웨어 시장가치가 분명해졌다. 6월 말 발표 이후, 해커들은 말 그대로 아이폰의 문을 열어제껴왔다. 소프트웨어의 설치를 위해서였다. 그러나 애플과 애플 제품 헐뜯기에만 혈안이 되어있는 비판가들이 있다. 이들은 어떤 발표이건 무조건 공격하는 모순적인 이들이다. It Can’t Be OS X! 애플이 실제로 새 휴대폰에 맥오에스텐 기반의 소프트웨어를 사용한다 믿지 않는 이들도 있다. 아이폰이 ARM 프로세서를 사용한다는 이유다. Slashdot \| iPhone Not Running OS X 그들은 애플이 "오에스 텐"이라고만 붙인 이름이 브랜드일 뿐이라 주장한다. 10년 전, 마이크로소프트가 데스크톱 윈도 브랜드를 활용하기 위해 WinCE를 만들었던 것과 매한가지라는 내용이다. 물론 브랜드가 맞기는 맞다. 1월달 필자 주장처럼 차라리 맥오에스텐이라 부르는 편이 나았을지도 모르겠다. 필자는 당시 넥스트가 프로세서 독립적인 OS를 만들어왔다는 점과 함께, 작년에 PowerPC에서 인텔로의 이주를 위한 포팅도 해냈다는 점을 지적하였다. 애플이 이미 90년대 초반부터 개발에 직접 도움을 주었던 프로세서인 ARM에 포팅 못할 이유라도 있는가? ARM은 원래 뉴튼 메시지패드용 프로세서였다. 2001년 이래 나온 아이포드용 프로세서이기도 하다. 그들은 틀렸다. 아이폰은 나왔고, "오에스 텐 1.0"이라는 이름이 붙기는 했지만, 맥오에스텐과 같은 기반의 시스템이었다. iPhone 인사이드: Mac OS X과, ARM, 그리고 iPod OS X iPhone은 어째서 Symbian을 선택하지 않았을까 iPhone의 OS X과 Leopard, 그리고 Vista It Can’t Be Secured! 그러자 이번에는 아이폰의 보안에 문제가 있으리라는 공격이 나왔다. Gartner의 듈래니(Ken Dulaney)도 개중 하나다. 그는 아이폰에 파이어월이 없다는 주장을 펼쳤다. 듈래니는 아이폰이 파이어월이 있는지를 알지 못한다. 오에스텐 설치시, 파이어월 제공이 없다면서, 그는 휴대용 기기에 파이어월이 어째서 필요한지 설명도 하지 않았다. 윈도모바일이 파이어월을 제공하던가? 뭐라도 하던가? 파이어월이 있으면 윈도모바일의 충돌을 막을 수 있을까? 혹시 그 때문에 윈도모바일 부팅이 그리도 느린 것일까? Secret iPhone Details Lost in a Sea of Hype and Hate It Must Be Secured! 다른 일상적인 컴퓨터처럼, 패치가 필요할 보안 문제를 아이폰도 갖고 있다 지적하는 보안 전문가들도 있다. 이들이 갖는 첫 번째 오류는 아이폰이 사용하는 오픈소스 소프트웨어 코드 검색을 통해 알 수 있다. 사실 보안 연구자들도 이 과정을 통해 보안문제 해결을 권유할 수 있으며, 애플은 아이폰 데뷔 한 달여만에 그러한 취약성을 업데이트로 패치시켰다. 이를 오픈소스의 투명성, 보안성을 확인시켜주는 증거로 삼는 대신, 전문가들은 발견된 오류를 재빠르게 패치시킨 업데이트를 두고 문제점이라 돌려 말했다. 분명 이들은 돈받고 글 쓰는 자들이다. 10 FAS: 10 - Apple’s Mac and iPhone Security Crisis It Can’t Be Broken Into! 애플이 보안오류를 패치한 뒤, 재빠르게 이론적인 아이폰의 보안문제를 퍼뜨린 이들도 많다. 애플의 업데이트가 아이폰에 써드파티 소프트웨어를 설치하려는 시도를 막았기 때문이다. 아무래도 이들은 인정받은 악성 소프트웨어만 마술처럼 없애줄 보안패치를 기대했던 모양이다. 즉, 자기들이 아이폰에 집어넣으려는 비인증 애플리케이션은 합법적으로 설치가 가능한, 그런 패치를 예상했다는 것이다. 애플의 최신 보안 업데이트의 문제는 그러한 펌웨어가 들어간시스템을 보장해주지 못한다. Computerworld의 엘간(Mike Elgan)은 아이폰의 펌웨어 해킹 시도를 융통성 있게 해 줄 방법을 열어 줬어야 한다 주장한다. 하지만 애플은 그러하지 않았다. 엘간이 생각한 그 이유는? 애플이 "오만해서"이다. 기술에 대해 잘 모르는 저널리스트들은 그 때 이후로, 애플이 어떻게 사용자들을 "격리(bricked)"시켰는지 떠들어댔다. 그런 일은 일어나지 않았다. 문을 활짝 열고나서, 보안을 적절히 제공해주는 제품은 없다. Arrogance Unleashed: The Foul Stench of Computerworld’s Mike Elgan Open Isn’t Magic. 서버에 리눅스를 설치한다면, 원하는 해킹이나 수정을 마음껏 할 수 있다. 하지만 그렇게 해도 시스템이 언제나처럼 안전하리라는 말은 제아무리 리누스 토발즈(Linus Torvalds)도, 리눅스 배포회사도 못한다. 소프트웨어를 수정하면, 새로운 소프트웨어 빌드에 대한 책임도 져야 한다. 웹서버에 필자가 아파치를 설치하고, 수정도 했다면, 다음 버전에서도 그대로 돌아갈지 기대할 수 없다. 필자 고유의 해킹이 커뮤니티의 업데이트와 어떻게 돌아갈지를 염두에 둬야 한다. 마찬가지로, 사용자들이 펌웨어를 멋대로 손질해가지고, 문제 없이 업데이트를 할 수 있는 이상세계는 없다. 애플이 사용자를 격리시켜버렸다고 자동적으로 적는 이들은 현실감각이 없거나, 사기꾼이다. The Sorry State of Mobile Software. 경쟁 휴대폰 업체나 통신사들도 애플이 "우리의 자유를 증오한다"고 주장하는 대열에 끼어들었다. 이유는? 자신들의 휴대폰이 써드파티용 소프트웨어를 돌릴 수 있어서이다. 휴대폰용 소프트웨어가 안정적으로 뭔가 쓸 만하다면야, 그 주장은 설득력을 지닌다. 하지만 절대 다수는 그렇지 못하다. 휴대폰용 소프트웨어라는 것이 이러하다. 존재하지도 않는 윈도모바일의 문제를 해결한다. 오히려 악성 소프트웨어로 떠 있다. 아무 이유 없다. 가격이 너무 높다. 혹은, 아이폰에서 이미 돌아간다. 써드파티 소프트웨어를 둘러싼 억측 Flip Flopping? 월스트리트저널의 윙필드(Nick Wingfield)는 애플이 "아이폰 소프트웨어 전략을 뒤집었다."고 표현했다. 비판가들이 거론하기 전까지 애플은 전혀 고려하지 않았다는 주장이다. 그러나 현실적으로 아이폰 소프트웨어 개발을 전혀 공개하지 않으리라고 말한 자는 애플이 아니라 오히려 필자였다. 기사 시리즈에서 필자는 애플이 아이폰을 무제한적으로 개발공개하지 않으리라면서 여섯 가지 이유를 제시하였다. 또한 아이폰용 애플리케이션 시장을 애플이 어떻게 서서히 개방할지에 대해서도 논했었다. 가능성이 아예 막히지는 않았다고 말한 것이 다행스럽다. iPhone 내부 공개는 없다 iPhone은 정말 폐쇄된 플랫폼인가? iPhone, 어떻게 개방될까? What Jobs Really Said. 사실 잡스도 애플이 절대로 써드파티를 원치 않는다는 발언을 한 적도 없음을 지적하겠다. 1월달 뉴욕타임스와의 인터뷰에서, 마코프(John Markoff)는 잡스를 다음과 같이 인용하였다. "아이폰의 모든 것을 정의내렸습니다. 휴대폰도 컴퓨터와 똑같아서는 안되겠죠. 그래도 애플리케이션 세 가지 정도는 있어야 하잖을까요. 그래야 휴대폰을 쓰죠. 컴퓨터라기보다는 아이포드와 더 닮은 형태입니다." 잡스는 이렇게도 지적하였다. "잘 작동해야 해요. 하지만 소프트웨어를 로딩시켜서야 그럴 수 없죠. 그렇다고 해서 아이폰에 설치할 소프트웨어 구매도 불가능해지리라는 뜻까지는 아닙니다. 전부 재작성해야한다는 말도 아니에요. 통제된 환경이라고 봐야 할 테죠." 썬의 조이(Bill Joy)의 지적이 있다. "전세계의 영리한 이들 대다수는 여러분의 조직을 위해서 일하지 않는다." 잡스도 그 점을 분명 알고 있다. Give Me Something To Work With Here. 언론과 주주들 앞에서 필자가 잡스에게 물었던 점이 있다. 5월달, 필자는 그에게 써드파티나 개인 기업용 개발킷의 여부에 대해 질문했었다. 그의 답변은 개방과 보안문제 간에 균형잡기를 갖고 "노력하는 중"이라 답했다. 6월, All Things Digital 컨퍼런스에서도 잡스는 같은 답변을 되풀이했다. "[써드파티 개발 지원을] 작업중입니다. 몇 가지 좋은 아이디어가 있죠. 아마 하반기쯤, 보안 문제 없이, 써드파티가 애플리케이션을 작성할 방법을 찾아낼 겁니다." "누구도 완벽하지는 못하지만, 아이폰 충돌은 정말 원하지 않습니다. 이 문제를 해결하고 싶어요. 조금만 인내심을 가져주신다면, 원하는 걸 모두 가질 수 있게 될 겁니다." 즉각적인 답변은 웹 애플리케이션이었다. 사파리의 보안 문서는 잘 알려져있으며, 자바스크립트를 사용한 웹 애플리케이션 구축 시장도 널리 개방되어 있다. 애플의 방안이 그저 "언 발에 오줌누기"밖에 못된다는 불만이 나왔다. 폴 써롯(Paul Thurrott)은 그런 불만이야말로 애플에게 미래가 없다는 신로라 주장했다. 애플은 악이오, 독점자다. 아무래도 그는 나중에 애플이 워싱턴 주 레드먼드에 본사를 뒀다고 불평을 시작할 것이다. 틀림 없다. Steve Jobs Walks the Tightrope Again - New York Times Developers see possibilities in iPhone apps - Macworld 2007년 애플주주총회 참관기 An iPhone SDK? Predictions for WWDC 2007! Adjusted Expectations. 애플 싯가가 1500억 달러에 이른다 하더라도, 애플 총 직원수가 18000명에 불과하다는 점을 잊는 이들이 있다. 비슷한 싯가를 가진 인텔의 직원 수는 88000명이다. 애플은 HP나 IBM보다도 싯가가 높은데, HP의 직원 수는 15만 명, IBM은 35만 명이다. 마이크로소프트 싯가는 애플의 두 배에 이르지만, 직원 수는 애플의 네 배인 79000명이다. 즉, 훨씬 더 적은 인원을 갖고서도 엄청난 가치를 만드는 곳이 애플이다. 즉, 다른 대기업들처럼 정리해고도 똑같이 실시할 수는 없다. 게다가 애플은 매년, 엄청난 주목을 받는 제품을 날로 확대시켜가고 있는 중이다. 게다가 그 성공률도 놀라울 정도로 높다. 현재와 2월달을 비교해 보자. 아이폰 개방에 있어서 과거 있었던 문제를 해결할 시간이 생겨났다. 애플이 아이폰 소프트웨어 시장을 어떻게 개방할지는 두고 볼 일이다. Less Than Totally Open. 잡스는 "개방성"으로 돈을 벌려하는 노키아를 언급했다. 노키아는 아이폰이 "폐쇄적"이라 주장한다. 알려진 개발자가 추적할 수 있는 디지탈서명이 있지 않으면 애플리케이션 설치가 불가능하다는 이유였다. 잡스의 말이다. "'완전 개방'과는 좀 다른, 전화기의 문제입니다. 우린 우리의 방향이 올바르다고 보며, 사용자들을 악성 소프트웨어에서 지켜주는만큼, 아이폰의 놀라운소프트웨어 플랫폼에 네이티브로 접근할 수 있을 진보적인 시스템을 작업중입니다." 잡스는 또한 휴대폰용 악성 소프트웨어가 실제로 있는 문제라면서, 바이러스와 같이 배포된다 지적하였다. 그러면서 제일 바이러스에 많이 감염된 휴대폰이 Symbian이라는 사실은 언급하지 않았다. 노키아에게 부끄러운 일이다. Third Party Applications on the iPhone - Apple iTunes Store for Developers. 잡스의 발언을 보면, 애플이 "진보적인 시스템"을 제공한다는 의미인 듯 하다. 현재 아이포드의 게임 배포 시스템과 유사한 점이 많을 것이다. 이미 지난 가을 때부터 필자가 언급해 오던 사실이다. 그러면 합법적인 소프트웨어를 추적하여 관라하기도 쉬울 뿐더러, 소프트웨어의 값도 더 낮출 수 있다. 그러면서도 개발자들은 더 많은 돈을 벌 수 있을 것이다. 만약 필자 추측이 맞다면, 아이폰이 소프트웨어 설치 문제와 스파이웨어, 바이러스로 가득찬 또 하나의 PC 플랫폼이 되지는 않으리라던 잡스의 오랜 주장을 해석할 수 있다. 아이폰은 보다 아이포드에 가까워진다는 의미다. iPhone 인사이드: 써드파티 소프트웨어 애플은 음악과 아이튠스처럼, 소프트웨어 개발자를 위한 메커니즘을 선보일 듯 하다. 저가에 대량으로 소프트웨어를 판매할 시장 조성이다. 그러면 보다 공정한 이윤과 더 넓은 배포 시장이 나올 수 있다. 필자는 파인더 스토어라는 아이디어를 냈었다. 아이포드/아이폰 소프트웨어 플랫폼과 묶을 수 있는 아이디어다. 독립 개발자들도 공정한 몫을 받을 수 있게 된다면? 음악가들과 불법복제 간의 관계처럼, 정직한 구매자들의 구입만으로 이뤄지는 현 시장은 바뀔 수 있다. 즉, 아이폰/아이포드터치용 아이튠스 스토어는 매우 합리적이다. 물론 그렇다고 해서 전문 비판가들의 불만까지 잠재울 수는 없으리라. What do you think? I really like to hear from readers. Comment in the Forum or email me with your ideas. Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks! Steve Jobs Ends iPhone SDK Panic — RoughlyDrafted Magazine __________________ FAQ

2007-11-25, 08:43 AM	#2
bpwook Senior Member Registered: Apr 2006 My Mac: MacBook Pro The very first model. 1.83Ghz Posts: 210 오프라인	"잘 작동해야 해요. 하지만 소프트웨어를 로딩시켜서야 그럴 수 없죠. 그렇다고 해서 아이폰에 설치할 소프트웨어 구매도 불가능해지리라는 뜻까지는 아닙니다. 전부 재작성해야한다는 말도 아니에요. 통제된 환경이라고 봐야 할 테죠." 이 부분이 약간 문맥이랑 안 맞는 것 같아서 원문을 찾아봤는데요... “These are devices that need to work, and you can’t do that if you load any software on them. That doesn’t mean there’s not going to be software to buy that you can load on them coming from us. It doesn’t mean we have to write it all, but it means it has to be more of a controlled environment.” 이 부분은 저라면, "이것들은 동작해야만 하는 장치들입니다. 아무 소프트웨어나 로딩시켜서는 그럴 수 없습니다. 그것은 우리에게서 구입한 소프트웨어만 로딩할 수 있다는 의미가 아닙니다. 우리가 모든 프로그램들을 작성해야 하는 것이 아닙니다. 다만, 그것은 조금 더 통제된 환경이어야만 한다는 것 입니다." 와 같이 해석할 것 같습니다. 우리말로 예쁘게 쓰는 재주는 없어서 좀 지저분합니다만, 의미는 이 쪽이 조금 더 적당한 것 같습니다. 언제나 까소봉님의 해석에 감사하고 있습니다. 건필하세요. bpwook 님께서 2007-11-25 09:15 PM 에 수정하셨습니다..

2008-03-14, 12:04 AM	#3
casaubon Moderator Registered: Sep 2001 My Mac: MacBook Air Posts: 2,140 오프라인	iPhone 2.0 SDK: 멀티태스킹 미신 iPhone 2.0 SDK: The No Multitasking Myth March 13th, 2008 \| History, Journal, Markets, Mobiles, Software, Tech, the Media Daniel Eran Dilger 아이폰 2.0 SDK를 두고 악랄한 우려를 개발해낸 전문가들이 있다. 이들이 말하는 첫 번째 문제는 아이폰이 한 번에 여러 개의 애플리케이션을 돌릴 수 없어보인다는 점이다. 이들에 따르면 오리지날 맥이나 Palm Pilot처럼 아이폰은 멀티태스킹 능력이 떨어지지만, 윈도 모바일용의 WinCE는 그렇지 않다고 한다. 이들은 틀렸다. 왜인지 알아보자. The iPhone is Unix. 일단 아이폰이 어떻게 돌아가는지, 코어 OS가 어떤지를 보면 된다. 아이폰의 커널은 맥오에스텐의 커널과 같다. 즉, 표준형 유닉스 하부시스템을 구성하는 Mach와 BSD의 하이브리드이며, 다중 프로세서와 다중 사용자를 지원한다. 이 시점에서 Palm OS 또한 멀티태스킹 커널상에서 만들어졌다는 점을 지적해야겠다. 그러나 Palm은 Kadak으로부터 싱글-태스킹 환경만 라이센스받았다. 이 때문에 Palm OS는 80년대 중반의 클래식 맥오에스와 대단히 유사해졌다. 첫 번째 애플리케이션을 종료시켜야 두 번째 애플리케이션이 돌아갔기 때문이다. 애플은 아이폰에서 같은 문제를 겪지 않았다. 애플 스스로 아이폰 커널을 소유하고 있기때문에, 멀티태스킹을 막을 만한 외부적인 기술 제한이 없었다. 아이폰은 전화 통화중에도 Maps 프로그램을 돌릴 수 있으며, 전화 통화가 끝나기 전에 웹페이지 링크를 따라들어갈 수도 있다. 모두 첫 번째 광고에 이미 나온 기능이다. 웹브라우징을 할 때 전화가 울리고, 다른 작업을 할 때 백그라운드 상에서 음악이 돌아가며, 메일도 확인한다. 확실히 멀티태스킹을 한다는 얘기다. 그렇다면 SDK 문서는 어째서 "한 번에 하나의 아이폰 애플리케이션을 돌릴 수 있다."라 쓰여 있을까? 아이폰이 클래식 맥이나 Palm Pilot과 똑같은 구조적인 문제는 일단 없다는 점부터 시작해 보자. iPhone의 BSD 유닉스 어처구니 없는 Palm의 실수연발 Multitasking Macs before Unix. 오리지날 맥은 다중 애플리케이션을 한 번에 돌릴 만한 자원을 갖지 못했다. 첫 번째 맥 사용자들은 한 번에 하나의 애플리케이션만 돌릴 수 있었는데, 이는 심각한 제한이었다. 1985년, 앤디 허츠펠드(Andy Hertzfeld)는 Switcher라는 유틸리티를 만들어서, 활성화중인 애플리케이션을 중지시키고 새 애플리케이션을 돌릴 수 있도록 했었다. 1987년, 애플은 동시에 여러 개의 애플리케이션을 보여주고, 그 사이를 빠르게 이동시켜주는 MultiFinder를 출시한다. 그러나 클래식 맥은 유닉스-스타일의 선점형 멀티태스킹을 하지 않았다. 선점형 멀티태스킹이란, 운영체제가 활성화중인 애플리케이션에게 프로세싱 자원을 엄격하게 관리하여 부여하는 방식이다. 클래식 맥은 그 대신 협력형 멀티태스킹을 사용하여 프로세서 상에서 순번을 바꾸는 식에 의존하였다. 즉, 애플리케이션 하나가 무한루프에 들어가게 되면, 전체 머신이 멈춰지는 문제를 야기할 수 있었다. 유닉스에서는 이런 일이 일어나지 않는다. 프로세스를 신뢰하지 않기 때문이다. 커널이 이 프로세스를 관리하는데, 작동이 멈춰지면, 그 작동을 넘어서서 시스템 차원에까지 영향을 끼치지는 않게 된다. 시스템 자체를 멈추게 될 프로세스는 커널 그 자신이다. 즉, 커널 상의 모든 소프트웨어는 극단적으로 안정적이다. 이 때문에 애플은 개발자들에게, 불필요할 경우, 되도록이면 커널 익스텐션으로 프로그램 작성을 하지 말도록 권장한다. Folklore.org: Macintosh Stories: Switcher Just Because You Can, Doesn’t Mean You Should. 아이폰은 유닉스의 ‘kernel in command’ 아키텍쳐를 갖고 있다. 하지만 동시에 여러 가지 애플리케이션을 돌릴 수 있다고 해서, 개발자들에게 이를 무조건 허용하는 것이 좋다는 의미는 아니다. 맥오에스텐에서 여러 가지 애플리케이션을 활성화시키는 일은 그다지 큰 문제를 일으키지 않는다. 시스템이 RAM 한도를 벗어나는 경우, 시스템은 비활성중인 애플리케이션을 하드드라이브 상의 가상메모리에 집어 넣는다. 다시 활성화시킬 때까지 동면시키는 것이다. 아이폰의 가상 메모리 시스템도 같지만, 기가바이트 급의 RAM이나 가상메모리 스왑공간이 충분한 하드 드라이브까지 갖고 있진 않다. 아이폰의 RAM은 128MB이며, VRAM이 11MB 정도이고, 시스템이 점유한 용량이 19MB 정도이다. 즉, 사용자가 사용할 수 있는 메모리는 76MB 정도다. 백그라운드 프로세스 양을 조절해야, 아이폰의 오에스텐은 우선 활성중인 애플리케이션에 더 많은 RAM을 할당시킬 수 있다. 아이폰은 일반적인 목적의 컴퓨터가 아니며, 휴대폰과 브라우저, 아이포드의 합체이다. SDK가 야기한 제한때문에, 아이폰은 상당한 게임용 플랫폼이면서, 바로 사무용 애플리케이션으로 돌아갈 수도 있다. 이 모두가 휴대폰 자체의 기능과 브라우징, 아이포드를 희생시키지 않아도 된다. 다른 기기들은 그렇지 못하다. furbo.org · What the iPhone specs don’t tell you Mac OS X 마이크로커널의 미신을 벗긴다 1-3 The Problem With Background Processes. 물론 아이폰은 보통의 스마트폰 RAM의 두 배를 갖고 있지만, 백그라운드 프로세스가 돌아간다고 하면 76MB 정도는 우스워진다. RAM만이 아니다. 미디어 재생과 WebKit 렌더링, 전화와 라디오신호 처리, VoIP 데이터암호화, 푸시 이메일과 문자 메시지, 정보 관리 모두가 제대로 돌아가지 않으면 안될 필수 기능들이다. 휴대폰의 핵심 기능이 사용할 광대역 외에도, 프로세서가 소비하는 별도의 백그라운드 프로세스가 생기면, 전화기는 뜨거워지고, 전기도 닳아서 배터리 수명이 짧아진다. 결국 기기 자체의 수명도 줄인다는 얘기다. 따라서 아이폰이 생각한대로 움직이도록, 발열이 심해지지 않도록, 새 애플리케이션을 설치해도 배터리 수명에 지장이 없도록 해야 할 가이드라인을 지정해줘야 한다. 그것이 애플의 책임이다. 써드파티가 멋대로 백그라운드 프로세스를 잡아먹게 놓아 둬서는 안된다. 개발자들에게 문을 활짝 연 뒤에, 프로세서 관리를 못한다면서 사용자를 타박해서도 안된다. 무책임한 행동이다. iPhone의 OS X: Mach 커널과 RAM The Problem with Foreground Multiprocessing. 백그라운드 문제만 있지는 않다. 전면부(foreground)에서 돌아가는 다중 애플리케이션의 문제도 있다. 물론 아이폰은 분명 어디서든지 다중 애플리케이션을 한 번에 돌릴 능력을 갖추었다. 전화 받으면서, 홈스크린으로 되돌아간 다음 다른 애플리케이션을 돌릴 수 있으니 말이다. 통화중에는 화면 최상단에 녹색 막대가 나타나서, 언제든 전화중 상태의 화면으로 되돌아갈 수 있다. 다른 애플리케이션(물론 이 경우 Safari는 웹페이지를 돌아다니다가 충돌을 일으킬 경우가 잦다)이 돌아갈 때 아이튠스는 오디오를 돌릴 수 있다. 어디에서건, 아이포드 재생 컨트롤러 Home 버튼을 더블클릭해서 아이포드 재생 컨트롤러를 화면상에 불러들일 수 있다. 두 사례 모두 보면, 화면 인터페이스에 다소 제약이 있다. 일부러 그런 것이다. 돌아가고 있는 다른 애플리케이션이 없으면, 활성화중인 애플리케이션과 중요한 백그라운드 프로세스에 더 많은 자원을 할당할 수 있다. 위에 언급한 바와 마찬가지이다. 이뿐만이 아니다. 사용자 입장에서 인터페이스도 크게 단순해진다. 아이포드 기능도 주요 기능이기는 하지만, 아이폰은 휴대폰이기에 독특한 면이 있다. 하지만 프로세서 안에서 모든 애플리케이션이 자기 자리를 점유해버린다면, 남는 자리가 안 생길 것이다. 더군다나 아이폰 디스플레이는 그 많은 애플리케이션이 다 뜰 만큼 크지도 않다. 물론 그럴 수도 있겠지만 휴대용 기기에 적절하지 않은 인터페이스로 만들어 놓고 애플릿을 구겨 넣은 다른 곳보다 애플은 더 휴대용 기기를 더 잘 알고 있다. Rocket Launching. 시스템 정책을 따르기보다 애플리케이션 스스로가 결정을 내리도록 해야 한다는 의견이 들리기는 좋을지 몰라도, 실제로는 그리 좋지 못하다. 사실 애플의 정책은 사파리에 대한 써드파티 애플리케이션과 동일하다. 사용자가 Home 버튼을 눌렀을 때, 시스템은 현재 애플리케이션 데이터를 저장한 다음, 애플리케이션을 종료시키고, 애플리케이션 메뉴가 있는 Springboard를 내놓는다. 다음에 애플리케이션을 다시 활성화시키면, 종료됐을 때와 같은 상태로 시작한다. 이 활성화 시간이 너무나 빠르기에, 사용자 입장에서는 가상 메모리 상에서 돌아가는 애플리케이션을 다시 불러들이는 것이나, 종료시켰다가 필요해서 다시 활성화시키는 것이나 별 차이 없다고 느끼게 마련이다. 물론 기술적인 차이는 있다. 애플리케이션 종료가 배터리 수명 등, 자원 사용에는 더 효율적이다. 사용자들도 그것을 알아차릴 것이다. 이 때문에 애플은 SDK에서 이렇게 적고 있다. "한 번에 하나의 아이폰 애플리케이션을 돌릴 수 있으며, 써드-파티 애플리케이션은 백그라운드에서 돌리지 않는다. 사용자가 다른 애플리케이션으로 전환시키거나, 통화를 하고 이메일을 확인할 때, 해당 애플리케이션은 종료된다는 의미다." Invent, Suggest, Panic! 엔지니어링에 대해 잘 모르는 블로그들이 있다. 이름도 기가 막히게, BoyGenius Report라고 되어있는데, 이곳이 최근 써드파티 애플리케이션도 백그라운드에서 돌아가게 해달라며, 동등한 권리를 요구하는 청원에 나섰다. 종료시킬 필요 없이 애플리케이션간에 전환이 가능하게 해 달라는 것이다. 듣기에는 좋게 들린다. 하지만 제대로 알고 하는 얘기일까? 엡슈타인(Zach Epstein)은 아이폰에 "진정한 멀티태스킹이 없다"면서, 개발자인 발루섹(Robert Balousek)을 인용하였다. "AOL 인스턴트 메신저같은 애플리케이션을 돌린다면, 통화가 오거나 브라우징을 할 때마다, 나중에 다시 로그인해야 할 것이다. 못읽은 메시지는 영원히 못읽게 되고, 대화는 끝이다." 그러나 콕스(Christopher Cox)는 이런 지적을 했다. "이 글 저자는 크게 오버하고 있다. [...] 간섭이 있을 때, 애플리케이션이 정지해서, 현재의 데이터를 저장하게 된다. 다시 애플리케이션을 돌리면, 예전 메시지는 여전히 남아 있다. [...] AIM 서버도, 프로그램이 접속 끊기 신호를 보낸다거나, 특정 시간 이상 연결되어있지 않는 이상, 접속을 끊지 않는다. 즉, AIM 애플리케이션으로 되돌아가면, 메시지도 바로 나타난다는 의미다. 재접속 할 필요가 없다. 물론 AIM에 24시간 내내 접속해 있고 싶다면야, 단점이 될 것이다. 그 뿐이다. 그러나 대부분은 그럴 정도의 마음가짐을 갖고있지 않다." iPhone SDK Honeymoon Over - No Background Processes?! \| The Boy Genius Report What Would Happen If Apple Didn’t Know Any Better. 아이폰 SDK와 관련, 멀티태스킹이 안되리라는 주장이 헛것이라는 점을 알았다. 잘못된 정보다. 그런데 혹시, 애플이 제한을 가하지 않을 경우 아이폰이 어쩌면 더 나아질 가능성은 없을까? 추측할 일도 없다. 듣기 좋은 발린 단어 나열만 좋아하는 위원회 식의 엔지니어링을 통해, 만들어진 확실한 사례가 있기 때문이다. 마이크로소프트의 WinCE이다. 마이크로소프트는 WinCE를 유닉스와 같은 멀티태스킹 아키텍쳐로 간주하지만, 가상메모리 구조를 갖고 있기는 해도, 동시에 돌릴 수 있는 프로세스가 32개에 불과하다. 또한 각각의 프로세스가 갖는 가상 어드레스 공간 또한 32MB 뿐이다. 하지만 이 정도 사양도, 수 년 후에나 널리 쓰일 WinCE 6.0 사양이다. 그 때까지 멀티태스킹 WinCE라는 주장은 근본적으로 오류다. 물론 실상은 그보다 더 열악하다. 멀티태스킹 기능을 효율적으로 사용하지 못하게 막으면서도, WinCE는 써드파티의 백그라운드 프로세스만은 제한이 두지 않았다. 하지만 휴대용 기기에서 다중의 애플리케이션을 돌리는 것은 좋지 않다. 그 이유는 많다. 첫 번째 이유는 필자가 이미 명시한, 자원 사용의 문제다. 필자 대신, WinCE 옹호자인 헤러라(Chris De Herrera)의 말로 해 보겠다. "한 번에 여러 가지 애플리케이션을 돌려놓으면, 전면부 애플리케이션이 눈에 띄게 느려질 때가 있다. 이런 현상은 운영체제가 백그라운드 애플리케이션에게 자원을 써 주어야 하기 때문이다. 이 때 필자가 권장하는 바는, 소프트웨어의 재시동이다." Like kill on the road, Windows has failed to respond. Control! Alt! Delete! 그런데 또 하나의 이유가 있다. 같은 시간에 그 많은 걸 들여다 볼 화면이 없다는 것이다. 실질적인 화면 크기가 정해져 있기에, 데스크톱처럼 다중의 겹쳐지는 창과 제목막대, 창끼리 전환하는 기능을(Lisa가 최초로 보여준 기능이다) 들여다보는 것이 실질적으로 유용하지 않다. 하지만 마이크로소프트는 아랑곳하지 않고, 90년대 후반 이후, 맥 데스크톱 UI를 베낀 윈도를 그 조그마한 화면에 애써 구겨 넣었다. 그러니 팔릴리가 없다. WinCE 기기는 너무나 복잡해져서 그걸로 뭘 어떻게 할지 이해하기도 힘들어졌다. 게다가 충돌도 잦고, 배터리 수명도 절망적이었다. 아이폰은 너무나 간단해서, 일단 돌려본 다음, 별다른 훈련 없이 잘 쓸 수 있다. 그저 잘 돌아가는 아이폰이다. 애플이 Dock과 Finder 데스크톱을 아이폰에 구겨 넣으려 했다면, 아이폰 역시 절망적으로 안팔렸을 것이다. WinCE와 Windows Mobile의 처절한 실패사 Less is More; More with Less. 아이폰은 WinCE에 비해 더 나은 멀티태스킹 커널을 갖고 있다. 서류상에 나온 모든 기능을 다 하려들다가, 결국 아무 것도 잘 못해고 팔리지도 않는 기기를 만들어내는 마이크로소프트식 시스템이 아니다. 애플 엔지니어들은 아이폰 2.0 SDK에 제한을 가해서 사용자에게 더 유용한 애플리케이션을 덧붙이도록 할 것이다. 새 소프트웨어가 나오기도 전에, 기존 아이폰 판매량은 이미 미국 내에서 윈도 모바일 휴대폰의 판매량을 크게 넘어섰다. 아이폰의 스마트폰 시장 점유율은 27%이고, 모든 모바일 웹 트래픽의 71%를 차지하는 휴대폰이 아이폰이다. 마이크로소프트는 데스크톱 PC와 마찬가지다. 복잡함을 벗어나 WinCE를 애플 아이폰처럼 만들기는 불가능할 것이다. 이미 나와 있는 윈도 모바일 애플리케이션들이 모두 프로세서 백그라운드에서 돌아갈 권리를 갖고 있어서, 스마트폰을 느리고, 비효율적으로 만들기 때문이다. 제일 열광적인 윈도 옹호자들조차 끌지 못할 정도로 복잡해진 것이 윈도 모바일이다. 아이폰도 당연히 똑같은 문제를 겪어야 한다고 주장하는 꼴을 보니, 실용성과 단순성을 그들이 왜그리 이해못하는지 확실히 알 만하다. iPhone과 경쟁하기 - 소프트웨어 What do you think? I really like to hear from readers. Comment in the Forum or email me with your ideas. Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks! iPhone 2.0 SDK: The No Multitasking Myth __________________ FAQ

2008-03-17, 09:37 PM	#4
casaubon Moderator Registered: Sep 2001 My Mac: MacBook Air Posts: 2,140 오프라인	iPhone 2.0 SDK: 아이폰과 자바 iPhone 2.0 SDK: Java on the iPhone March 14th, 2008 \| History, Journal, Markets, Mobiles, Software, Tech, the Media Daniel Eran Dilger 아이폰 SDK가 나온지 얼마 안 되어서, 썬이 아이폰용 자바 Micro Edition 플랫폼을 선보이겠다는 발표를 하였다. 애플이 허용할 경우, 썬이 과연 그런 플랫폼을 내놓을지, 도대체 이것이 아이폰 사용자들에게 어떤 의미가 있는지에 대한 문제가 남아있다. 더 흥미로운 점도 있다. 자바가 어디에서 왔는지, 휴대기기 영역에서 어디로 향할지이다. A Window into Sun’s Java. Xerox PARC에서 그래픽 데스크톱을 해방, 매킨토시로 가져온 스티브 잡스는 애플을 떠나서 NeXT를 설립한다. 그 후 그는 제록스에서 개척한 여러 가지 다른 개념을 갖고 여러 프로젝트를 관리하기 시작한다. device independent graphics: 제록스에 있던 존 워녹(John Warnock)은 PostScript를, 후에는 어도비에서 PDF를 만든다. standard networking: 제록스의 봅 멧카프(Bob Metcalf)가 고안했으며, 후에 3Com이 Ethernet으로 상용화시킨다. object oriented coding: 제록스의 Smalltalk이다. 브래드 콕스(Brad Cox)가 C와 혼합시켜서 오브젝티브-C가 된다. 넥스트는 오브젝티브-C를 채용하였고, 그 결과 독특한 기능을 갖게 되었다. 애플의 맥처럼 90년도 당시 데스크톱 개발환경은 대부분 파스칼을 사용하였다. 마이크로소프트 DOS와 윈도는 C/C++이었다. 1988년, 넥스트스텝(NeXTSTEP) 개발프레임웍과 함께 견고하게 통합되어 있던 오브젝티브-C는 마이크로소프트의 MFC보다 훨씬 강력하고 쉬운 개발 환경을 제공했다. 당시 MFC는 C 윈도 API 상에 얇은 C++ 기능을 제공하는 정도였다. 마이크로소프트는 2000년 .Net이 등장하기 전까지, 넥스트에 견줄 만한 개발 프레임웍을 전혀 제공하지 않았다. 맥을 베낀지 10년 후, 잡스와 제휴한 뒤, 잡스의 기수을 베낀다는 마이크로소프트 전략 상대는 썬 마이크로시스템즈였다. 썬과 넥스트는 1993년, 썬 Solaris용 넥스트 개발환경을 만들기 위해 협력한다. 시스템 포팅을 하고, OpenStep 사양(누구나 NeXT 애플리케이션을 자기 운영체제에서 돌릴 수 있는 사양이다)을 1994년에 개발한 뒤 1996년, 썬은 관심을 다른 프로젝트로 돌린다. 자바였다. iPhone용 OS X과 WinCE, Palm, Symbian, 리눅스 Yellow Box의 죽음, 그리고 Cocoa Sun Brews a Familiar Tasting Platform. Java는 다음을 포함하였다. Java language와 컴파일러 Java Virtual Machine: 플랫폼 독립적인 바이트코드를 돌리는 가상머신 Java API framework: 클래스 라이브러리 자바 언어 신택스는 C++에 기반을 두었지만, 자바의 객체 모델은 오브젝티브-C에서 빌려왔다. 자바 API도 NeXTSTEP 프레임웍에서 대거 빌려 왔다. 썬의 자바만이 아니었다. 애플과 IBM(그리고 나중의 HP)도 Taligent의 일부로서 넥스트 프레임웍을 대거 베꼈다. 반면, 마이크로소프트만은 일단 약속먼저 하였다. 빌 게이츠가 1991년, Cairo 프로젝트를 약속한 것이다. 그리고나서 5년이 흘렀다. 썬만이 넥스트스텝 프레임웍에 견줄 만한 뭔가를 만들어냈을 뿐이다. 그것이 1995년에 나온 자바 1.0이었다. Taligent 일부도 결국 자바 API에 흡수되었다. 90년대 하반기 내내 기술업계는 자바로 들끓었다. 처음에는 느리고, 성숙이 덜 되어 있으며, 미완성되었다는 평을 들었지만, "한 번 작성, 어디서나 실행(write once, run anywhere)"이라는 점때문에 잠재성을 본 이들은 매우 많았다. 마이크로소프트만은 그 잠재성을 윈도에 대한 위협으로 간주하였고, 자바의 크로스 플랫폼 기능을 파괴시키기 위해 상당한 노력을 기울인다. 자바를 단순히, 또 다른 윈도용 애플리케이션 구축 방식으로 만들어버린 것이다. 넥스트를 인수한 뒤, 애플은 자바를, 새로 인수한 넥스트 소프트웨어를 광고할 수단으로 보았다. 애플은 자바 개발자들의 친숙성을 위해, 오브젝티브-C 신택스를 다소 변경하는 것을 고려하였고, 오브젝티브-C 대신, 자바 언어를 사용할 수 있도록 자바 브릿지를 제공하기도 하였다. 또한 새로운 넥스트-기반 프레임웍을 Cocoa로 변경하였다. 같은 프레임웍으로 썬이 밀었던 자바 환경에 대응하는 이름이랄 수 있었다. 1990-1995: 핑크와 탈리전트, 코플랜드의 비밀 1990-1995: 카이로로 가는 머나먼길 The Caffeine Buzz Wears Off. 원래 썬이 자바로 노렸던 것은 모든 플랫폼의 플랫폼이었다. 여러 플랫폼용 자바 Runtime Environment을 개발하면서, 썬은 모두가 자바코드로 한 번 자바 애플리케이션을 작성하는 시장을 희망하였다. Win32 API를 사용하는 언어가 무엇이건 간에, 자바 코드로의 작성이었다. 썬은 또한 자바가 웹의 공통언어가 되기를 바랬다. 웹페이지의 모든 인터랙티브 애플릿이 자바로 이뤄지기를 바란 것이다. 마이크로소프트는 썬의 희망이 죽기를 희망하였다. 그런데 썬이 되려 마이크로소프트를 돕는다. 자바는 웹이나 데스크톱 애플릿 상에서 그리 훌륭한 퍼포먼스를 내지 못하였다. 윈도에서 자바를 제대로 돌리고 싶었던 썬은 맥이나 다른 플랫폼용 JRE를 소흘히 하였고, 웹 플러그인도 제대로 안 돌아갔다. 게다가 사용자 인터페이스 툴이 3류였기에, 자바 애플릿의 외양은 하나같이 끔찍했다. 느리고, 못생겼으며, 사용이 불가능하다는 명성을 얻자, 마이크로소프트의 공작은 빠른 성공을 거두게 된다. 이와 반면, 같은 기간동안 훨씬 더 약했던 애플도 마이크로소프트로부터 압박을 받는다. 퀵타임을 죽이라는 압박이었다. 그러나 퀵타임 환경은 살아남는다. 애플은 윈도용 퀵타임 구현의 통제권을 마이크로소프트에게 위임하거나, 협력하지 않았다. 반면 썬은 자바를 두고 어리석게도 마이크로소프트와 협력했었다. 서버 측면에서 보면, 자바는 극도로 가치가 높다. 썬은 웹서버 개발에 있어서 자바를 성공시켰다. 웹서버의 경우, 상당한 하드웨어 자원이 있기에, 자바의 퍼포먼스 문제를 해결할 수 있으며, 사용자 인터페이스가 별 문제가 되지 않는다. 썬이 웹서버용 자바를 민 이유는, SPARC 서버를 판매할 하나의 수단이기도 해서이다. 당시 마이크로소프트는 모든 것을 윈도-PC 전용으로 내세우려던 때이다. JVM 포팅만 되면, 자바는 어디에서건 돌릴 수 있다. 이 이유때문에, 수많은 웹 애플리케이션 서버가 자바로 포팅되었다. 그 중에는 애플의 WebObjects도 있다. 퀵타임을 죽여라 Jittery Handheld Desperation. 서버 영역의 성공을 거둔 것 이외에, 썬은 간소화시킨 자바인 자바 ME(원래는 J2ME였다. SE는 표준 에디션, EE는 기어용 에디션으로 나눠서였다. ME는 마이크로 에디션)로 휴대용 기기를 노린다. 썬은 심지어 자바 ME가 "휴대용 기기에 있어서 제일 유비쿼터스인 애플리케이션 플랫폼"이라고도 말하였다. 상당한 수의 휴대폰 업체들이 각자 자바 ME를 만들어서이다. 문제는 휴대폰이 컴퓨터보다 일관적이지 못하다는 데에 있었다. 따라서 자바는 전반적으로 실패한다. 데스크톱만 보더라도, 유명한 자바 애플리케이션은, 파일공유용인 Limewire와 Azureus 정도밖에 없다. 맥이 100% 순수 자바 개발용이라 애플이 손수 광고해도 이 정도이다. 이유가 있다. 자바를 가지고 윈도와 맥, 리눅스를 상호 연결하기보다, 일단 집에서 사용하는 개발툴을 갖고 개발한 다음, 애플의 네이티브 Cocoa 프레임웍을 사용하여 크로스 플랫폼 포팅을 하는 데에 더 관심이 많아서이다. Java ME in the Mobile World. 휴대용 기기만 보면, 자바 상황은 더욱 안좋다. 제약은 훨씬 더 많으면서, 기기별 차이점은 대단히 크다. PC 영역의 마이크로소프트처럼, 썬도 Connected Limited Device Configuration과 Mobile Information Device Profile(자바 ME 사용자 인터페이스의 휴대폰용 최소 규약이다)을 출판시키는 등, 표준화를 위해 노력하였다. 썬은 JRE 구현을 휴대폰 업체들에게 맡기는데, 이 때문에 모든 자바 ME 휴대폰은 약간씩 다른 기능을 제공하면서, 똑같은 애플릿도 각자 다르게 구현하였다. 이 때문에 "한 번 작성, 어디서나 디버그"라는 악평을 얻게 된다. 마이크로소프트도 윈도를 PC 업체들에게 아예 맡겨버리진 않았다. 그랬다가는 윈도용 애플리케이션이 각기 하드웨어별로 다르게 나왔을 것이다. 좋아질리가 없다. Java ME는 스마트폰 개발에 있어서도, 상당한 제약에 발목 잡힌 상태다. 휴대폰은 통신사들이 휴대폰 디자인을 해버리고, 스스로 통신망을 통제해버리는 산업이기 때문이다. 자바 ME 애플리케이션은 보통 1MB 이하 크기인데, 통신사 통신망은 보통 전송량을 300KB로 제한한다. 이 때문에 자바 ME 소프트웨어 대부분을 간단한 게임으로 전락시켰다. 게임이 아니더라도, 특정 휴대폰의 장점을 못살리는 자잘한 프로그램밖에 못 되었다. Texas Holdem의 J2ME 버전이 아래의 위 그림이다. 밑에는 Palm OS 버전과 아이포드용 버전, 그리고 Verizon의 BREW 버전이 나와 있다.(클릭하면 커진다.) 특별할 것이 없다. 아이폰용 버전이 아이포드용보다 더 나으리라 기대할 만하다. Why Would Anyone Want Java ME on the iPhone? 자바 ME(J2ME) 환경을 아이폰에 넣는다는 말은, 맥에 CP/M 환경을 넣는다는 말과 유사할 것이다. 아이폰을 산다면, 아이폰의 깔끔하고 사용하기 쉬운 인터페이스때문에 사는 것이다. 여기에 무거운 자바 ME 런타임을 설치해서 어리둥절할 이유가 없다. 훨씬 떨어지는 휴대폰용 소프트웨어 애플릿에 향수를 느낀 나머지, 썬은 아이폰에 누군가 자바 ME를 설치하리라 희망하는 모양이다. 그것이 1년 전, ABI Research의 분석가 솔리스(Philip Solis)의 마음이었다. 그는 아이폰이 J2ME 휴대폰에서나 돌리는 쓰레기 소프트웨어를 못돌린다면서, 써드파티 소프트웨어가안돌아가니 아이폰도 스마트폰이 아니라 주장했었다. 썬에게는 큰 문제가 있다. 애플이 별도의 API 런타임을 아이폰에 업로드하지 않기 바란다고 말했기 때문이다. SDK 동의서를 보면 이런 글이 있다. "플러그인 아키텍쳐를 통해, 혹은 다른 프레임웍이나 API를 호출하는 식을 포함한, 그 어떤 방식으로도 애플리케이션이 다른 실행가능 코드를 설치하거나, 실행시키지 못한다. 애플의 Published API와 내장 인터프리터가 돌리는 코드를 제외하고, 애플리케이션에서, 그 어떤 인터프리티드 코드를 다운로드하거나 사용할 수 없다." 즉, 자바 ME JRE를 가볍게 거부한다는 의미다. 자바 ME MRE는 자바 API를 사용한 인터프리티드 코드로서 자바 애플릿을 읽거나 실행한다. 그러고보니, 이 규칙은 어도비 Flash와 마이크로소프트 Silverlight도 배제하게 되어 있다. iPhone, 누구를 위협하는가 써드파티 소프트웨어를 둘러싼 억측 Is Apple Going Too Far? 혹시 애플이 아이폰 팔려고 너무 나가는 것은 아닐까? 차라리 모든 하드웨어 업체들에게 아이폰 소프트웨어를 독점적으로 라이센스시키고, 휴대폰용 소프트웨어 시장을 독점화시킨다면, 그 말이 맞을 것이다. 그러나 다행히도 애플은 고유의 사업방식을 갖고, 휴대폰 시장에서 경쟁을 벌일 뿐이다. BMW가 라디오 번들을 시키기 위해, Bose와 파나소닉, 소니 등 모든 업체에 라이센스 계약을 맺어야 할 이유가 없듯, 굳이 썬을 초대해서, 자바 ME API라는 경쟁상대에게 의자까지 안겨다줄 이유가 없다. 모든 휴대폰용 소프트웨어를 독점화시키고 다른 경쟁자의 진입을 막는 마이크로소프트 방식을 따랐다면, 물론 다른 문제가 됐을 터이다. 통합된 하드웨어 업체로서 애플의 사업방식과, 소프트웨어 라이센스 거간꾼으로서, 강을 지나다니는 모든 배에게 통항세를 받는 해적이기도 한 마이크로소프트의 사업방식은 크게 다르다. 애플은 썬의 jPhone을 막지 않았으며, 제한하지도 않았다. 자바 ME를 휴대폰에 밀어 넣으려는 썬의 시도에 개입하지도 않았다. Sun, 아이폰 경쟁에 뛰어들다 A Reversal of Fortune for Sun and Microsoft. 아이러니컬하게도 썬은 이미 마이크로소프트가 WinCE/윈도모바일로 가진 거간꾼의 위치를 이미 점유하였다. 휴대폰 대부분에 J2ME가 들어갔기 때문이다. 그러나 J2ME는 크게 뒤쳐졌으며, 선택사항도 허술하고, 호환성도 별로 안좋으며, 통신사들이 여러 가지 게임만 내세우려하는데, 굳이 설치하려는 사용자들은 거의 없다. 데스크톱의 마이크로소프트와, 휴대폰의 썬이 매한가지라는 의미다. 애플이 휴대폰 영역을 확장시킬수록, 썬은 잃을 수밖에 없다. 자바는 한 가지 휴대폰만 빼고, 거의 모든 휴대폰에 다 들어가 있다. 그런데 사람들이 이야기하고, 해외에서까지 비싼 값을 주고 이용하고야 마는, 게다가 심각나 애플리케이션 계획이 놓여 있는 휴대폰이 바로자바가 없는 그 휴대폰이다. 썬도 파티에 참가하고 싶을 것이다. 하지만 맞는 드레스가 없다. 자바 ME 드레스? 썬은 넥스트와 파트너를 맺었다가 포기해버린 전력을 갖고 있다. 심지어 그 후, Lighthouse Design을 인수하여 넥스트용 애플리케이션 출시를 막은 뒤 포기해버리기도 하였다. 되려 공포에 떨 만하다. 넥스트에서 가져온 개념으로부터 떨어져 나왔지만, 넥스트 소프트웨어가 10년 후 휴대기기 영역을 뒤바꿀지 미리 알았더라면, 좀 다른 결정을 내렸을지 모르겠다. 애플 아이폰 잠수함이 부상하면서 마이크로소프트 윈도 모바일은 물론, 썬의 모바일 구상까지 점차 흐트러지고 있다. What do you think? I really like to hear from readers. Comment in the Forum or email me with your ideas. Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks! iPhone 2.0 SDK: Java on the iPhone? __________________ FAQ

2008-03-19, 11:33 AM	#9
javanese New Member Registered: Jul 2006 My Mac: MacBook Pro C2D 2.16, MacBook Black CD, iPod Touch 16G, iPod Nano Nike+ Posts: 10 오프라인	음.. iPhone SDK를 아직 제대로 살펴보지는 못했습니다만.. 저로서는 개별 애플리케이션이 Background Process로 돌지 않도록 막은 것은 오히려 개발하기 편하다고 느낍니다. 꼭 자원 남용을 하지 않더라도 애플리케이션 여러개가 동시에 떠있는 것 자체가 부담되지 않나요? WinCE 사용하면서 제일 짜증나는게 태스크 관리라서.. 사용자 입장에서도 한번에 하나 동작한다는 가이드라인은 오히려 깔끔할 것 같습니다. 물론 애플리케이션 특성상 Background Process가 필요할 수도 있지만 그런 애플리케이션에는 별도의 정책을 두는 것이 타당하다고 봅니다. 원 글의 저자가 강조하는 것은 더 나은 multi thread 환경을 갖추고도 남용하지 않는 기본 정책을 칭찬하는 것일 뿐이고, Background Process의 의미도 로우레벨 프로세스라기 보다는 화면에 나타나지도 않으면서 의미없이 동작하는 애플리케이션의 의미로 한정하고 있는 것 같습니다. 알람 같은 것을 구현하려면 물론 Background Process가 필요하겠지만 그런 것까지 포괄해서 쓸데없다고 하는 의미는 아닌 것 같네요. 그런 것을 구현하기 위한 메커니즘은 따로 제공되리라 생각됩니다. (이미 있을지도?) 오히려 걱정되는 것은 애플리케이션 스위칭 할때마다 새로 프로세스를 시작하다보니 컨텍스트 유지와 시동 시간의 이슈가 있겠지만 뭐 그거야 각자 알아서 해결해야겠죠. preinstall 되어 있는 애플 제공 애플리케이션들도 컨텍스트 유지를 전혀 안해버리니 좀 불편한 감은 있지만 일관되게 적용되는 것이라 크게 거부반응은 없는것 같기도 합니다. casaubon님 번역 감사합니다. 정말 재미있게 잘 읽었습니다. javanese 님께서 2008-03-19 11:42 AM 에 수정하셨습니다.. 이유: 감사 인사를 깜빡했어요 ^^

2008-03-18, 03:28 AM	#5
aingoppa Senior Member Registered: Aug 2006 My Mac: . Posts: 261 오프라인	이 아저씨가 자기가 아는 게 많으니 자기 말이 맞다고 하는 것처럼 자주 느껴졌는데, 이번에 iPhone의 Background Process에서 하는 말을 보니 정말 뒤집어질 것 같습니다. 나중에 Apple이 이 부분을 지원해 주기라도 하면 그 때 어떤 말을 할지 정말 기대됩니다.

2008-03-19, 01:06 AM	#6
Camus Senior Member Registered: Jan 2002 My Mac: Powerbook G4 15" 1.25 SuperDrive , iPod 10G Posts: 249 오프라인	aingoppa 님, 좀 더 자세히 설명해 주시면 재미있을 것 같습니다. 언급하신 내용들을 조금 풀어서 설명해주실 수 있으신가요? 궁금하네요~

2008-03-19, 03:23 AM	#7
aingoppa Senior Member Registered: Aug 2006 My Mac: . Posts: 261 오프라인	홧김에 글을 적어버려서 좀 그렇네요. 전에 Steve Jobs가 말한것처럼 iPhone이 crashing machine이 되지 않는 절충선에 있는 SDK라고는 생각 되긴 합니다. iPhone에 대한 직접적인 접근 대신 여러 고급 API를 제공해서 깔끔하고 안정정인 Application을 만들 수 있기도 합니다. 그렇다고 해서 Background process같은 것을 지원하지 않고 그것이 바보같은 프로그래머의 어리석은 자원 남용을 막는 좋은 방법이라고 말해버리면 그걸 읽고 프로그래머들이 좋아할 수 있을까요. 이번에 SDK가 나오면 만들고 싶었던 것들이 몇가지 있었습니다. 하지만 Apple에서 거부 메일을 받고 실제 SDK의 한계가 보여서 재미가 없네요. Apple에서도 같은 Tool을 사용해서 만든다고 하던데 Framework도 정말 같은 것을 사용하는지 궁금하기도 합니다.