casaubon

Copland 2010 revisited: Apple's language and API future

By John Siracusa



기술의 미래를 예견하기란 까다로운 일이기 마련이다. 멀리 갈 것 없다. 빌 게이츠에게 물어보시라. 하지만 예측이 주는 매력은 강력하다. 가끔은 필자도 예상을 맞출 때가 있다. 2008년, 필자는 다음의 글을 썼다."애플/어도비의 불길한 미래, 오직 전쟁만 있을 뿐." 모호하지만 유머로 과장하였고, 특정 시간을 맞추지는 않았다. 성공적인 예언의 요소는 다 갖춘 셈이다.

하지만 그 외에는 필자도 별로 운이 안따라 주었다. 5년 전, 필자는 Avoiding Copland 2010라는 제목의 시리즈 기사(세 부분으로 나뉘었다)를 쓴 적이 있었다. 이 기사의 메시지는 솔직했고, 특정 사안을 지적했으며, 제목에 특정 해까지 언급했었다. 간단히 말해서, 완벽한 실패작이었다. 자, 지금이 바로 2010년이다. 바로 그 '미래'가 왔다! 냉수라도 마시고 속차려야 할까, 아니면 의기양양 날뛰어야 할까. 할 일부터 하자. 도대체 "코플랜드 2010은 무엇에 대한 것이었을까?

Background

코플랜드(Copland)는 애플이 차세대 운영체제를 만드는데 실패한 시도 중 하나였다. 그 중에서도 제일 악명 높은 운영체제의 코드명이었다. 코플랜드 프로젝트를 시작했던 1990년대 당시, "차세대"는 메모리 보호와 선점형 멀티태스킹을 의미했다. 둘 다 클래식 Mac OS에는 없던 기능이다. 그 때 이후로 코플랜드는 애플도 인정한, 그리고 회사를 거의 파괴시켜버린 실패작의 기린아가 되었다. 당시 기준에서 애플 소프트웨어 플랫폼에 심각한 기술격차가 있었다는 점을 드러낸 주역이 코플랜드였다. 애플은 결국 전에 쫓아낸 애플 창립자를 모셔오고, 유망한 현대적인 운영체제를 인수하고 나서야 문제를 해결할 수 있었다.

기사의 첫 번째 글을 보면 필자가 이렇게 주장했음을 알 수 있다. 맥오에스텐의 일부인 오브젝티브-C 언어와 Cocoa API는 경쟁에서 뒤떨어질 위험을 안고 있으며, 2010년께가 되면 메모리-관리 언어와 API가 없어서 또 다른 코플랜드-류의 위기를 겪게 될 수도 있다고 썼다. 두 번째 글에서는 필자 논지를 다음과 같이 정교하게 구성하였다.

• 완전 자동화 메모리 관리는 결국 데스크톱 OS 주요 애플리케이션 개발환경의 기능이 될 것이다.
• 2010년이 되면 다른 업체들 모두 완전 자동화 메모리 관리를 해주는 언어와 API를 채택할 것이다.
• 그리고 기존(2005년) 기술과 그 발전물들은, 메모리 관리와 API에 대한 애플의 필요를 충족시켜주지 못할 것이다.

당시에도 이 가정은 상당수가 논쟁을 불러일으킬만 했다.

세 번째 글에서 필자는 오브젝티브-C와 코코아를 추월할만한 언어와 API가 어떤 것이 있는지에 대해 다루었다. 또한 더 큰 그림을 보기 위해 그 시기를 의심스러워 하는 자들을 부추기기도 하였다.

그럼에도 불구하고 언젠가는 코코아와 오브젝티브-C가 쇠퇴하리라는 점은 누구나 인정할 수 있을 것이다. 좋다. 그 시기가 2050년이 되어야 이뤄지리라고 볼 수도 있겠다. 하지만 언젠가는 마찬가지이다. 그렇잖은가? 그렇다면 무엇이 코코아를 대체할까? 무엇이 코코아를 대체할 수 있을까? 차세대 언어와 API 전쟁에서 애플의 다음 움직임은 무엇일까?

이 기사에서 필자는 오브젝티브-C를 가비지 콜렉션과 Java/JVM, C#/.NET/Mono, 심지어 과거 애플의 Dylan의 합체로 여겼고, 실용적인, 기술적인, 그리고 정치적인 이유에서 안좋게 여겼었다. 필자는 될 수 있는 한 빨리, 코코아/오브젝티브-C의 계승자를 애플이 찾아야 하며, 그 작업은 길고 어려우리라는 결론을 내렸다.

The future is now

자, 그럼 지금은 어떻게 되었나? 제목과 시기를 그대로 맞춰본다면 결론은 명확하다. 애플은 현재 코플랜드와 같은 소프트웨어 플랫폼의 위기를 겪고 있지 않다. 혹시 매우 다른 종류의 위기를 겪고 있을련지 모르겠지만 그것은 주제가 다르다. Wall Street (그리고 애플 자신의 재무재표)의 의견으로 볼 때 애플의 미래는 밝다.

그렇다면 필자는 왜 그렇게 틀렸을까? 필자의 가정을 다시 생각해 보자. 완전한 자동 메모리관리가 현재 데스크톱 소프트웨어 개발의 "기대받던 기능"이 되었는가? 그러한 듯 하다. 맥오에스텐 개발자 대부분은 그렇지 않지만 말이다. 오브젝티브-C에 가비지 컬렉션도 추가가 되었고, 애플 스스로가 그 사용을 장려하고 나섰다. 그런데 필자가 5년 전 묘사했던 "2등 시민의 문제점"도 나타나긴 했다. 애플 자신을 포함하여 코코아 개발자들 대부분이, 애플리케이션을 작성할 때 여전히 수동형 retain/release 메모리 관리를 사용하고 있기 때문이다. 요즘 맥 개발자들은 모두가 가비지 컬렉션을 아무 생각없이 선택한다. 하지만 잠재적으로 가비지 컬렉션이 퍼포먼스를 떨어뜨릴 수 있다는 생각도 하고 있다.

경쟁 데스크톱 플랫폼 대부분과는 다르다. 마이크로소프트 윈도의 .NET 프레임웍과 C#에서는 메모리-관리 코드가 기본사양이고, 다른 모든 것은 위험하게 여긴다. 소스코드에서 "unsafe" 키워드로 표시되기도 한다.

그럼에도 불구하고 맥 개발자와 사용자들은 코플랜드 시절 선점형 멀티태스킹과 메모리 보호에 대해 별다른 공포감을 느끼지 않았다. 위기가 오고 있다고는 해도 지금이 위기는 아님이 분명하다. 그렇다면 필자는 어째서 "2010년"을 거론했을까?

Now the future is later

마이크로소프트는 10년도 더 전에 .NET Common Language Runtime을 작성하기 시작하였다. 그 때 이후로 Python이나 Ruby같은 dynamic languages 지원 개선처럼 중요한 기능 업데이트를 네 번 하였다. 이것이 데스크톱 소프트웨어 플랫폼 경쟁이라면, 기술적으로 얘기할 때, 애플은 이미 왕좌를 넘겨주고 있다.

하지만 이런 현실과는 달리 맥 개발자들의 마음에 이런 기술적 문제는 존재하지를 않는다. 그 이유를 세 음절로 알려주겠다. 모바일. 애플의 iOS에 대한 강조(이전에는 iPhone OS)가 계속 어지럽게 올라가고 있다. 데스크톱에서는 최근에 보지도 못한 풍경인 128에서 256 MB의 RAM과 같은 제약이 있고, 1GHz가 최대 속도인 in-order CPU에다가, 가상 메모리 시스템 안에 swap이 전혀 없는 것이 모바일이다. 애플이 너무 적은 RAM만 허용한 데스크톱이나 노트북을 출하한지 10년도 더 넘었으며, 디스크에 가상메모리를 페이징시키지 않는 맥은 더 옛날에 내놓았었다. 아, 그런데 말이다. iOS에는 오브젝티브-C 가비지 컬렉션이 없다.

이 새로운 현실은 애플 개발자들의 마음 속에 더 높은 수준의 프로그래밍 언어와 프레임웍의 시계를 돌려놓아버렸다. C의 수퍼셋(superset)으로서 오브젝티브-C는 다시금 자신의 지위를 공고히 하였다. 포인터와 C의 structs같은 로레벨에 per-byte-precise 엔트리로 프로그래밍하기는 여전히 어렵다. 특히나 애플리케이션이 계속 OS로부터 메모리 부족 경고를 받고 있다면 더욱 더 그러하다.

게다가 휴대용 기기에서는 사용자 인터페이스의 반응성이 대단히 중요하다. 직접적이고 생생한 사용자 인터페이스를 유지하려는 애플의 가차없는 결정은 아이폰을 차별화시켜주는데 큰 역할을 하고 있다. 초기 터치스크린 휴대폰과 수많은 아이폰 복제 모델들과 차별을 시켜줘야 하기 때문이다. 심지어 지금도 새 아이폰과 베낀 기종들을 차별화시켜주는 중요한 요소가 목록 스크롤링이나 터치감이다. 애매하지만 감지가 가능한 차이점이 그것이다. 그리고 메모리의 한계때문에 개발자들은 어쩔 수 없이 반응용 인터페이스에서 iOS 네이티브 API의 로레벨까지, 적어도 점선이라도 그릴 수밖에 없다.

Reality check

그런데 이 말에는 어폐가 있다. 데스크톱 최대의 경쟁자 마이크로소프트처럼, 모바일 시장에서 제일 격심한 경쟁자인 안드로이드는 메모리가 관리되는 언어와 API를 자사의 모바일 플랫폼에 제공하고 있다. 현대적인 개발기술에 있어서 애플을 앞서는 분야 중 하나가 이것이다. 그리고 구글의 최신 안드로이드 판을 보면, 구글은 실수를 저지르지 않았다. don't-call-it-Java인 Dalvik 가상머신은 꽤 잘하고 있다. (레지스터-기반의 가상머신이라는 아이디어에 대해서는 필자가 조금이나마 예측을 했다고 주장하겠다. Dalvik이 이 디자인을 결국 사용하게 되리라 말한 바 있다.)

또 있다. 구글은 심지어 애플이 그동안 구축하기 위해 도와왔던 로-레벨 라이브러리도 만들기 시작했다. 구글 스스로 퍼포먼스를 늘려서, 안드로이드 폰만으로 아이패드까지 넘볼 수준이 되었다. 그렇다. WebKit은 C++로 작성되어 있고, 그 점이 주안점이다. 더 높은수준의 API를 애플리케이션 개발자들에게 제공해도 고성능에 방해를 받지 않는다는 점이다. 즉, 개발자들이 로-레벨 라이브러리를 통해 성능을 개선시킬 수 있다는 이야기도 된다.

구글만이 아니다. 마이크로소프트 또한 주기적으로 .NET 플랫폼을 통해 프레임웍을 전달해왔다. 심지어 더 높은 수준의 언어와 API도 윈도폰 7 시리즈에 추가시켰다. 불쌍한 Palm도 개발자들에게 더 많은 추상화와 안정망을 제공하였다. 애플의 실제 경쟁 상화이 이러하다.

물론 괄목할만한 모바일 시장의 성공과 비교해 보면 이런 기술적인 사항은 초라해지게 마련이다. Palm에게 있어서도 꽤 안좋게 작용하였다. 결국 HP는 친숙한 웹기술 기반의 SDK를 보고 Palm을 인수했기 때문이다. 하지만 그들은 애플의 모바일 사용자 인터페이스의 지배에 대한 제일 가는 위협이다. 물론 구글도 있다. 구글은 어디 다른 곳으로 가지 않을 것이다. 마이크로소프트도 어쩜 알 수 없는 노릇 아닌가?

개별 경쟁사들의 운명은 일단 제쳐두자. 제일 위험한 경쟁사들이 애플 것보다 한 세대 앞선 언어와 API를 제공하고 나섰다는 사실 자체가 우려스런 신호이다. 다시 말하건데, 이 모두가 메모리가 부족하고 CPU도 한계가 있는 모바일 영역에서 나왔다. 데스크톱에서도 애플은 역시 저 멀리 뒤떨어져 있다.

바로 지금이 2010이다. "미래"이건 아니건, GUI 애플리케이션 개발자들이 애플리케이션 메모리를 헤집고 돌아다니면서 배드 포인터 데레퍼런스를 일일이 걷어내는 광경은 좀 웃길 따름이다. 세상이 움직였다. 애플도 움직여야 한다.

Things are more like they are now than they have ever been

And so continues one of the biggest constants in software development: the unerring sense among developers that the level of abstraction they're current working at is exactly the right one for the task at hand.

무슨 생각들 하시는지 알고 있다. 당신, 코코아 개발자. 당신은 필자가 흥분했다고 생각하실 것이다. 코코아와 오브젝티브-C는 애플 최대의 힘이라 말할 것이다. 기술 시한 폭탄이라니! 더구나 C의 유산에도 불구하고, 애플의 오브젝티브-C를 "로레벨"로 자리매김하는 것이 불공정하다고 생각하실 것이다. 오브젝티브-C의 다이나믹 기능과 랭귀지 기능을 보라. 저 강력한 자바에도 이런 것들이 여지껏 없다. 그리고 가비지 컬렉션을 잊지 말라. iOS에도 결국 들어오리라 확신한다!

어찌됐건 필자의 주장은 모두 포인트가 아니라고 말할 것이다. 그 증거는 백문이 불여일견. 누가 더 나은 애플리케이션을 만드는가? 누가 최고의 사용감을 제공하는가? 누가 돈을 버는가? 애플의 데스크톱/모바일 플랫폼의 기술적인 약점이라 하는 부분이 있지만 그것이 정말 중요하진 않다. 전혀 영향이 없잖은가!

소프트웨어 개발에 있어서 최대의 상수도 지속된다. 현재 작업중인 추상화의 수준이 바로 올바른 태스크용의 추상화이리라는 정확한 느낌이다. 더 낮은 수준이면 야만스럽고, 더 높은 수준이면 허세다. 자원의 낭비를 가져올 테니까 말이다. 업계 전반에 걸쳐 추상화의 전체적인 수준이 더 높아질수록 그 느낌은 사실이다.

처음에 C 프로그래머들은 어셈블리를 더 이상 작성하지 않아도 되리라 상상하였지만, C++의 vtable 디스패치는 여전히 너무나 느리다. 그리고나서 C++ 프로그래머들은 C의 절반쯤이나 구현했을까 싶은 오브젝트 시스템에 원통함을 느낀다. 여기에 자바가 너무나 웃긴 돼지처럼 내동댕이쳐졌다. 훨씬 나중에 자바 프로그래머들은 포인터와 수동형 메모리 관리를 비웃었지만, JavaScript 또한 웹 폼용 장난감 수준의 "스크립팅" 언어라는 놀림을 받았다.

단기적으로야 그들이 종종 옳다. 하지만 그런 시각은 한 가지 관점만을 제시한다. 그렇다면 다음 세대로의 전환까지 어느 정도 시간이 남았을까? 업계 최전선을 보면 된다. 애플은 어쩌면 새로이 발견해낸 모바일 시장덕분에 시간을 좀 벌었다고 여길지 모르겠지만, 경쟁 상황을 볼 때 그것은 애플의 바람일 따름일 수 있다.

Trading up is hard to do

2010년의 위기가 없긴 하지만, 애플은 결국 이 문제를 해결해야 한다. 5년 전에 생각했던 이유와 같다. 지금은 오히려 그 때보다 더 우려스럽다. 개발 플랫폼은 정말 바꾸기 힘들기 때문이다. 첫 번째는 새 API를 만들고 새 언어를 개발하거나 선택하는 기술적인 이유때문에 그러하다. 훌륭한 API를 개발하고 성숙시키려면 수 년은 걸린다. 코코아를 보면 알만하다.

불행히도, 기존 API를 더 새롭고 높은 수준의 언어와 런타임으로 단순히 포팅시킨 다음에 잘 돌아가리라 기대할 수는 없다. 더 높은 수준의 랭귀지로 이주하면, 이전 API에서 제일 어색하고 거추장스러운 컨벤션과 컨셉, 엔티티를 제거할 수 있다. 가령 메써드가 있는 프레임웍이 다음처럼 나타난다는 얘기이다.

NSInteger myCount = [[myDict objectForKey:@"count"] integerValue];

NSArray *myArray = [myString componentsSeparatedByString:@","];

myItem = [myArray objectAtIndex:i];

이론상 이런 프레임웍이 다음의 것을 지원하는 언어 형태로 나오지는 않는다.

myCount = myDict["count"];

myArray = myString.split(",");

myItem  = myArray[i];

새 언어에 걸맞는 새 API가 필요하지만, 다음 문제에 비하면 빙산의 일각에 불과하다. 기존 플랫폼의 분위기를 유지하면서 새 언어와 API로 개발자들을 이주시키는 문제다. 기술적으로 훌륭한 선택을 하였고, 모든 개발자들이 당신의 선택에 따라 이주하고, 또 이주할 수 있다고 가정한다 하더라도, 이런 이주에는 시간과 에너지가 필요하다. 기업과 개인 개발자 양측 모두에게서 말이다. 그러는 동안 현재 플랫폼이 아직 수명을 다 하려면 한참 남은 경쟁사들은 그런 이주의 부담이 없다. 즉, 당신이 이주를 벌이는 동안 경쟁사가 당신의 개발자들을 낚을 수 있다.

보통의 평범한 최종-사용자시라면 필자가 거론하고 있는 문제에 대해 공포감을 갖기 힘들 것이다. 그런데 당신이 개발자라면, 앞서 언급했다시피 필자의 주장을 물리치기 쉬울 것이다. 사실 필자 스스로가 1990년대, 코플랜드 위기 속에서 살아왔으며, 코플랜드때문에 애플이 거의 죽을뻔했다는 사실을 알기에 과장해서 반응하고 있는지도 모른다. 대단히 많은 부분이 그러하리라 확신한다.

하지만 그런 위기의 애플은 오래 전에 지나갔다. 분명히 지나갔다. 이런 기술 문제는 제아무리 중요하다 하더라도, 완전히 무시한다거나 완벽하게 부적절한 대처를 할 경우에만 위기로 발전할 수 있다. 지난 10년간 애플은 문제 해결을 노력해왔고, 정말 임무를 잘 해냈다. 따라서 상황은 좋아보인다. 그러나 두 번째 가능성을 생각해보면, 전망이 그렇게 장미빛은 아니다.

오브젝티브-C와 코코아를 알고 사랑하는 사람들 중, 제일 규모가 큰 집단은 당연히 애플이다. 그리고 이 애플 사람들은 새 언어와 API를 찾는데 그리 공격적이지 않다. "앱스토어 정책"에서 보듯, 애플의 경향은 외부의 의견과는 달리, 자기가 최고라 생각하는 경로로 치닫는다. 따라서 이 문제에 대해 그리 심각하게 여기지 않는 것이다.

최근 마이크로소프트는 포괄적인 제품을 내는 데에 있어서 무능함을 보여주었지만, 그래도 마이크로소프트는 기술적인 발전을 예견할 능력과 의지를 갖고 있다. 마이크로소프트는 애플이 처음 시도에 나서기 이전에도, 윈도 NT를 개발하면서 현대적인 OS 개발에 있어서 코플랜드-위기를 피했다. 그리고 소비자용 OS까지 NT로 넘어가기까지 몇 번의 업데이트를 통해, 다듬기도 하였다.

자바가 떴을 때, 시기적으로 좀 늦긴 했지만, C++ 캠프에 집착하던 마이크로소프트는 대단히 빠르게 인재와 자금력을 동원하여 .NET 가상머신과 C# 언어로 그 간격을 메꿀 수 있었다. 기술적으로 그만큼 뛰어나지 않은 회사라면 다른 경로를 택했을 것이다. 현재의 랭귀지와 API가 새로운 후보보다 중요한 장점을 지니고 있다면서, 경쟁성을 유지하기 위해 별다르게 해야 할 일이 없다고 주장할 것이다. 달리 말해서, "무시하고, 내 갈길을 가겠다" 정책이다.

오브젝티브-C와 코코아에 대한 애플의 태도가 대게 이러하다. 어느 시나리오로 될지 아시겠는가?

Reality check, part two

다시 말해서, 여러분의 반응은 짐작이 간다. "기술적으로 뭐라 해서 우리를 두렵게 만들지 말라. 현대적인 멀티-랭귀지 런타임에 대한 마이크로소프트의 측은한 헌신은 모바일 시장점유율에서 마이크로소프트를 돕지 못했다. 윈도/오피스 외에는 그 어느 영역도 마이크로소프트가 지배하지 못한다." 물론 모두 맞는 말씀이시다. 이렇게 기술적인 문제를 성공적으로 제기한다 하더라도, 그 자체가 성공의 열쇠는 아니다.

하지만 문제가 있다. 마지막 장에서 언급할 문제인데, 과연 애플의 오브젝티브-C와 코코아에 대해 "어떤 태도"인지, 미래 계획이 어떠한지에 대해 애플 말고 아는 이가 있는가? 원래의 코플랜드 2010년 칼럼을 쓴지 얼마 안되어서 애플은 LLVM 프로젝트를 공개하기 시작했다. 혹시 애플의 LLVM, 그리고 현재의 Clang이 플랫폼의 장기적인 전략 차원에서 나온 것일까? 물론 도움은 되리라고 보지만, 그정도가지고는 부족하다. 그런데 실상은 우리들 중 아무도 알고 있지 않다는데 있다.

심지어 필자는 애플이 이 점에 대해 무엇을 할지에 대해 심사숙고하기도 했다. 해결책이 있다면, 그것을 밀 터이다. 믿어달라. 지금까지 앞으로 나이를 먹어갈 플랫폼에 대해 어떤 방법을 쓸지에 대한 좋은 아이디어가 있다.

Then you will know the web, and the web shall set you free

애플은 다른 업체의 API를 라이센스 없이 쓸 수 없다. 외부 누군가에게 자신의 운명을 좌지우지하게 할 수 없기 때문이다. 경쟁사가 완전히 통제하지 않는다 하더라도 지배를 받는 프로그래밍 랭귀지를 선택하지 않을 가능성이 높다. 그렇다면 선택은 두 가지가 남는다. 모두를 스스로 해내느냐, 아니면 "회사가 없는" 해결책(단일 주체가 통제하지 않는 해결책)을 찾느냐이다.

지금까지 애플은 웹-기반 기술에 대대적으로 투자를 해왔다. 즉, 후자를 택한 것으로 보인다. 물론 웹은 더 할 나위 없이 회사가 없는 플랫폼의 제왕이다! 애플의 WebKit은 브라우저 엔진 전쟁에서 기린아(모바일 영역 뿐이지만)가 되었으며, 진보적인 웹 표준도 만들어내고 있다. (비록 잘 못할 때도 있지만 말이다). 그리고 애플이 사용하고 있는 SproutCore HTML5 애플리케이션 프레임웍도 있다. 최근의 웹 애플리케이션과 함께, 애플 내부에서 공개적으로 실험중인 웹 프레임웍인 PastryKit가 SproutCore를 사용한다.

사실 웹 기술을 사용하면 애플이 지닌 잠재적인 문제 다수를 깔끔하게 해결할 수 있다. 세계적인 언어와 API를 스스로 만들어내는 대신, 전체 업계와 함께 해결책을 만들어내면 되니 말이다. 그 어느 단일 경쟁사가 웹을 통제하고 있지도 않다. 그래서 애플이 이 부분에 있어서 다른 어떤 기술 기업들보다 영향력을 행사하는지도 모른다.

그러나 불행히도 이 의미는 애플의 통제도 아니라는 의미가 된다. 더구나 웹 기술이 전통적인 GUI 애플리케이션 개발환경까지 도달하려면 아직 한참 남았다. 숙련된 코코아 개발자들 대다수는 이 점을 잘 알고 있으며, 말하자면, 웹기술에 대한 대안이 있다고 치면, 그 대안을 보고나서 당황해한다.

이 때문에 필자는 애플의 웹기술 활용이 보조적인 선택이라 생각한다. 첫 번째 선택이 무엇일지도 알게되면 훨씬 편안해질 텐데 말이다.

Taking my lumps

그럼에도 불구하고, Copland 2010에 대한 필자의 초조감은 여전하다. 분명 필자는 이 문제가 사라지지 않았다고 생각하며, 시간이 갈수록 점점 더 중대해지리라고 본다. 물론 5년 전부터 두려워하던 자의 입에서 나오는 소리이니, "더 중대해지리라"는 의미는 각자에 따라 다를 수 있겠다.

코코아 맥오에스텐과 iOS 이용자는 고사하고, 개발자들에게 당신의 플랫폼이 이제 늙었으며, 기술적으로 열등하니 망하리라고 말하고자 함이 아니다. 하지만 필자는 이 문제를 되짚어보고 싶었다. 필자는 장기적인 예측도 해가며 오랜동안 애플에 대한 글을 써왔다. 스스로도 책임이 있다. 기술 전문가입네 하는 사람들의 끔찍한 예언을 편리하게 잊어버리는 광경은 필자도 무척 싫어한다.

필자는 애플을 돕고 싶다. 필자의 글을 읽을지도 모를 애플 내 결정자들을 통해 직접적으로 하든, 적어도 이 문제에 대해 생각이라도 하게 만드는 식으로 간접적으로 하든 (그들의 결론이 필자와 같지 않더라도) 애플을 돕고 싶다. 애플을 포함하여 흥미를 가진 이들 모두에게 이 문제를 되새기게 만들고 싶다.

마지막으로 필자가 좋은 미스터리를 사랑한다는 사실을 인정하겠다. 5년 전, 애플의 미래 랭귀지와 API 계획이 무엇인지 필자는 전혀 알지 못했고, 지금도 알지 못한다. 그런데 우리가 오랜동안 가진 판타지 대부분이 실제로 구체화되었다. 새 OS와 애플 폰, 신화 속의 태블릿이 등장했기 때문이다. 랭귀지와 API도 그러하지 않으리라는 보장이 없다. 그래서 데드라인이 몇 년도일지를 구태여 위험하게시리 쓰지 않는 것으로 결정내렸다. 필자는 계속 기다릴 것이다. 기다리는 이가 필자만은 아니리라는 희망을 품고서.


Copland 2010 revisited: Apple's language and API future

__________________

fericia

이 글을 읽고 잠시 뒤에 메모리 오류를 만나서 헤메다 보니...이분 말씀이 더 와닿는 듯한 느낌이...
뭐, Obj-C(와 Xcode)가 괜찮은 부분도 있지만 뭔가 반자동스러운 부분이 혼란을 주는 것 같습니다.

경험이 없으면 만들어 버리는 오류도 오류지만(retain cycle 같은거)...
가끔씩은 정말 아주 잡아내기 어려운 상황도 벌어지는 것 같아요(특히 내가 어떻게 제어하기 곤란란 파운데이션 안에서 오묘한 타이밍 문제로 벌어지는 오류같은 것)...

...그래도 Core Foundation을 그냥 쓰는 것 보다는 Cocoa가 조금 더 나은 것 같지만...

WWDC 2010의 LLVM에 대한 프레젠테이션을 보니...
XCode4에 와서야 경쟁사(및 여타 유명 IDE를 활용한 개발환경)의 개발환경 수준을 좀 따라잡으려 하는구나...하는 생각이 듭니다.
(...이전에는 안한 것이 아니라 못한것이 아닌가...하는 생각이)
물론 순수 개발이야 텍스트 환경에서도 가능은 합니다만...지금처럼 프로젝트 하나가 꽤 비대해지는 상황에서 좋은 개발환경이 생산성에 주는 영향은 무시 못하는 것 같구요.