2007년 11월에 작성된 글들

Mac OS X에 관한 진실, 그리고 오해

스티브잡스가 복귀하면서 ‘맥은 고가’라는 인식을 깨고 비교적 저가의 보급형 라인업을 수 년간 유지해 오면서, 눈에 확 띌 정도는 아니지만 알음알음 점유율이 늘고 있는 모양이다.

한국은 옛날에 쓰던 구형 맥 DTP ‘장비’들 외에는(특히 OS X으로 오면서) 황무지나 다름 없다고 할만한 시장이었는데, 인텔 플랫폼으로 이주하면서 무려 윈도가 네이티브로 돌아간다는 맥북이 탄력을 받아 시장이 갑자기 ‘뻥’하고 커진 느낌이다.
단적인 예로 2006년 맥북 출시 이전에 한국에서 가장 큰 규모를 자랑해 온 애플포럼이 2001년경 부터 모아 온 회원은 대략 만명 남짓이었다. 헌데 맥북이 출시된 후 두어 달 지났을까 싶은 짧은시간 만에 기록은 무너지고 네이버 맥북카페가 최다 맥유저 모임으로 등극한 것(현재는 회원수 4만명을 넘고 있다)만 보아도 이런 정황의 근거가 되지 않을까 싶다.

그러면서, 맥OS에 대한 국내의 관심도 자연스럽게 커져서 ‘맥은 뭐가 있다더라’, ‘어떤게 좋더라/구리더라’등등 이야기도 활발해 지고 ‘맥이 아니면 모두 하찮다’라는 소위 맥빠와 반대급부의 ‘맥은 이쁘장한 쓰레기’라는 맥까의 등장과 함께 도대체 맥을 메인으로 쓰지 않는 사람들은 무엇이 진실인지 더 초점이 흐려지는 경우가 생기고 있는 듯하다. 그래서 지난 몇 년간 맥을 써 오면서 본 것 들과, 무엇이 사람들을 홀리고 또 무엇이 사람들을 짜증나게하는지 느낀 바를 정리해 본다.

맥에는 뭔가 새로운 기술이 있다?

아쉽지만(?) 그렇지 않다. 이런 인식이 확산 된 데에는 잡스나 애플 홍보자료들의 과장도 일조를 했지만, 그보다 맥을 오래 쓰면서 들은게 많네 하는 이들이 보는 정보의 소스에 문제가 있다는 생각이다. 잠시 이야기가 다른 길로 빠지지만, 이 문제는 국내에 맥과 맥유저가 지금보다 훨씬 적었던 시절에 애플포럼과 같은 폐쇄적인 그룹에서 검증되지 않은 자료들을 섭취해 오던 것이 분명 문제의 발단 중 하나가 되었다고 본다.

가짜 잡스와 SCO, 그리고 리눅스
왜 RD의 글들이 나쁜가…

‘시간이 있으면’ 위의 글들의 분위기를 한 번 느껴보면 좋을 것 같다. 뭔가 굉장히 설득력 있는 것 처럼 보이는 글이지만 뭔가 찝찝한 기분을 공감할지 모르겠다. 마치 ‘삐라’와 유사한 뉘앙스를 풍기는 이런 글들이 수도 없이 번역되어 있다. 물론 사실인 내용도 많지만 궁극적으로 ‘애플은 절대 선이다’, ‘맥은 우월하다’, ‘스티브잡스는 신이다’라는 이야기하기 위해 부분적인 fact만을 모아서 보여주는 글들은 영양가를 논하기 어렵다. 문제는 이런 글과 논지를 같이하는 사람들이 꽤 많다는 점이다. ‘그냥 무조건 맥이 좋다’라고 이야기하는 것 보다 더 위험한 것이 바로 이것.

여하튼 본론으로 돌아와서, 맥OS에는 분명 윈도에서 볼 수 없었던 이런저런 기술들이 녹아 있는 것은 사실이다. 몇 가지 예를 들어보면,

  • Quartz Extreme, Core Image/Video/Animation - OpenGL로 데스크탑 그래픽을 가속
  • Spotlight - 데스크탑 인덱싱
  • Xgrid - 그리드 컴퓨팅 지원
  • Bonjour - 자동화된 ad-hoc 근거리 무선 네트워킹

윈도에 없었던 것들 중에 이런 것들이 대표적일 것이다. 하지만 이제는 대부분 윈도(비스타)에서도 된다. 게다가 이러한 것들이 새로운 기술인 것도 아니다. 물론 일찍부터 진보적(?)으로 많이 알려지지 않은 기술들을 비교적 일찍 발굴해서 쓸만하게 포장한 것은 높이 사지만, 그렇다고 그것들을 애플이 모두 만들었거나 처음 적용한 것은 아니라는 것이다.

그나마 이런 것들마저 빼고 나면 우리가 쓰고 있는 데스크탑 OS들은 근본적으로 기술적인 차이가 없다는 것이 정설이라 할 수 있다. 즉, 어떤 것은 기술적으로 후져서 뻑나고, 어떤 것은 기술적으로 우월해서 안정적이라고 할 수 없다. OS에 대한 경험담을 늘어 놓는 사람들이 많지만, 대부분은 특정한 개별적인 환경에서 단편적인 특성만을 이야기하는 경우다.

잠시 다른 얘기지만, 한 때 모노리딕커널(윈도NT계열, 리눅스, BSD, 솔라리스 등)이 마이크로커널(Mach커널, 미닉스 등)에 비해 후진 기술로 인식되었지만, 시간이 지난 지금까지 둘 다 사용되고 있고 기술적인 차이가 있을 뿐 우위는 없는 것으로 결론 지어졌다.

맥OS은 마이크로커널의 대명사인 Mach커널을 쓰는걸로 알고 있는 사람이 많지만, 지금의 커널은 XNU커널로 Mach에서 출발하긴 했지만 마이크로커널의 성격을 거의 잃고 하이브리드커널의 성격이 훨씬 강하다고 할 수 있다.(XNU=X is Not Unix라고 이름 붙여 놓고 맥은 유닉스 시스템이다 라고 광고하는 것도 재미있다) 반면 윈도의 NT커널은 하이브리드커널 형태에서 개선을 거듭하면서 모노리딕커널의 형태로 자리잡은 것으로 알려 져 있다.
어쨌거나 결론은 이러한 기술적인 우위, 우월이라는 얘기는 현실적으로 의미가 없다는 것이다.

사람들을 매료되게 만드는 것들

맥OS가 본질적으로 다른 데스크탑 OS와 다르지 않다라는 얘기를 한참 했는데, 그렇다면 대체 왜 맥OS에 열광하는 사람들이 나오는 걸까.
개인적으로는 맥OS의 User Experience의 세심함에서 그이유 중 하나를 찾을 수 있다고 본다.

분명 XP의 가이드라인이 look 위주의 가이드라인을 제공하던 것에서 많이 발전해서 이제는 거의 대등한 수준의 가이드라인을 제시하고는 있지만, 아직 비스타의 것들은 아직은 조금은 낯설고 새로운 내용들이 추가되어 있는 것을 알 수 있다. 반면 맥OS의 것들은 이미 대부분 수 년 전에 완성되어서 계속 사용되고 있는 것들이다.

두 OS의 가이드라인을 보면 둘 다 잘 되어 있는 가이드라인이지만 세세한 차이를 발견할 수 있다. 예로 프로그레스바에 대한 가이드라인을 비교해 보자.

비스타가 거의 같은 느낌의 프로그레스 인디케이터를 이용해서 여러가지 진행상태를 아우르는 반면, 맥의 인디케이터는 상황별로 조금 다른 형태의 것을 쓰도록 권고하고 있다.

options.png

또 다른 예로, 스크롤바를 보면 윈도의 스크롤바는 기본적으로 드래그 할 수 있는 썸네일과 양쪽 끝에 붙어 있는 방향 버튼이 있는데, 맥의 것은 이 양쪽에 붙어있는 방향 버튼을 OS에서 유저 편의에 따라 한쪽에 모을 수도 있고, 윈도처럼 양 쪽에 각각 붙어있게 할 수도 있다. 그리고 썸네일과 버튼 사이의 빈 공간을 클릭하게 되면 썸네일이 그 방향으로 진행하게 되는데, 맥에서는 이 액션을 해당 방향 진행인지 해당 위치로 점프인지를 지정할 수가 있다.

sort.png

잠깐 다른 부분을 살펴 보자. 이것은 아이튠즈의 라이브러리에서 일부 곡을 앨범명으로 정렬 한 상태이다. 헌데 뭔가 다른 것이 보이지 않는가. 보통 기계적으로 캐릭터 단위로 정렬 한다면 정렬 순서는 1999 > 200Km… > 2000 Watts… > 9th 가 될 것이다. 하지만 위의 결과 처럼 사람이 구분하는 단위로 읽어서 정렬 된 것을 볼 수 있다. 유사하게 영어 문자열에서 관사(A, The 등)로 시작하는 부분은 생략하고 정렬 한다든지 (Lemon > The Melon > Orange 하는 식) 한자와 함께 정렬하면 한글로 된 항목 중간에 한자의 독음으로 같이 정렬 된다든지 하기도 한다.

icons.png

이 외에도 헤드폰 단자에 플러그를 삽입했을 때와 하지 않았을 때의 볼륨이 각각 별개로 설정되어서 갑자기 헤드폰을 뽑았을 때 도서관 같은 조용한 장소에서 소리가 새어 나와 곤란한 경우가 없다거나, 데스크탑 화면 어디서나 하드웨어 가속을 이용해서 별도의 돋보기 프로그램 없이 화면을 마우스 휠로 확대해서 볼 수 있고, 메일이나 메시지가 오는 등의 이벤트가 생기면 해당 프로그램들의 아이콘에 상태가 반영 되는 등 이런 디테일의 섬세함을 열거하자면 끝을 맺기가 쉽지 않을 것이다.

다소 단적인 예로 접근해 보았지만, 맥OS의 유저 인터페이스는 단순히 심미적인 아름다움 이전에 작은 부분들에서도 기능적인 설계가 무척 잘 되어 있다는 것이 내가 반한 맥OS User Experience의 섬세함이다.

혹자는 이러한 것들이 대체 왜 ‘필요’한 것이냐고 종종 반문해 온다. 그 질문은 이러한 세세한 것들이 얼마나 컴퓨팅을 편리하게 해 주는지를 간과하고 있거나 느껴보지 못 했기 때문이라고 생각한다. 이런 편리에 빠져들게 되면 소위 얘기하는 다른 대체품을 쓰고 싶어도 ‘대안이 없는’ 상황에 직면하게 되기 쉽다. 많은 음원들을 통합해서 관리 할 방법을 제시하는 아이팟+아이튠즈의 현실적인 대안이 없음을 호소하며 어쩔 수 없이(?) 아이팟을 쓴다는 사람들의 이야기를 들어본 적이 있는지 모르겠다. 개인적으로 늘상 하고 다니는 얘기지만 필요는 ‘만들어 지는’ 것이 아니라 ‘만들어 내는’ 것이다. 쓰다 보니 필요해 진 것이지, 모든 것이 처음부터 필요를 느껴서 만든 것은 아니라는 것이 대답이 될 수 있다.

사람들로 하여금, 다른 제품으로 대체하기 어렵다는 것을 각인 시키는 것. 그것이 맥OS가 사람들을 홀리는 방법이다. (MS가 오피스와 같은 걸출한 킬러 애플리케이션과 개방적인 플랫폼으로 애플보다 대체 불가능한 환경을 더 확고히 굳히긴 했지만 말이다)

맥이 잘하고 있는 것과, 잘하지 못하고 있는 것들의 단편들

결국 이런 관점에서 이어 나간다면, 맥의 강점은 데스크탑 OS의 시류를 리드하는 적절한 기술들의 채용과 함께 특유의 섬세함을 갖추고 있다는 점이다.

비스타도 이제 Aero를 통해 구현하고 있고, 리눅스에서도 Compiz, Beryl등을 통해 하드웨어 가속을 받는 데스크탑 그래픽을 구현하고 있어 많이 화려해 졌지만, 과연 맥OS에서 처럼 효과적으로 생산성을 높이는 작용을 하는지는 의문이다.

비스타에 에어로를 쓰면서 창을 생성하고 그리는 과정들이 훨씬 매끄럽고 퀄리티가 좋아졌다고 느끼지만, 반면 과연 사용자가 데스크탑 가속을 통해 기능적으로 얻는 이득이 무었인지는 알기가 어렵다. 현란한 Alt+Tab 전환효과 정도가 생각나는 정도. Compiz나 Beryl은 거의 직접 사용해 본 시간이 없어서 평가하기가 곤란하지만, 데모 동영상을 통해서 봤던 대부분은 출렁거리며 떠 다니는 창과 큐브 형태로 전환되는 가상 데스크탑이 대부분을 차지하고 있었던 것으로 기억한다.

맥OS에 가속기능이 들어가면서 실시간으로 창들의 스케일을 조정해서 겹치지 않게 조정하는 엑스포제나, 비주얼한 계정 스위칭 같은 기능들은 상대적으로 좀 더 독창적이면서 생산성 향상에 기여하는 예로 볼 수 있을 것 같다. 또, 데스크탑 위에 오버레이 되는 대시보드나 최근 추가 된 가상 데스크톱 기능은 원래 유사한 기능을 제공하는 것들이 있었지만 어떻게 더 발전적인 방향으로 하드웨어 가속을 적용할 수 있는지를 보여 준 사례였다. 그 외에도 마우스커서를 대면 확산적으로 아이콘들의 스케일이 커지는 독은 대단해 보이진 않지만, 맥의 트레이드마크가 될 정도로 성공적이었다.

맥OS에서 된다고 광고하는 것 중 하나는 애플리케이션 설치와 삭제가 단지 아이콘을 드래그 해서 넣고 빼는 것만으로 이루어진다는 것이다. 이것은 두 가지의 실체를 가지고 있는데, 그 첫 번째는 드래그 해서 넣는 것이 단순히 애플리케이션의 바이너리나 아이콘이 아니라 실제로는 폴더(!)라는 것이다. 지금 맥OS를 쓰고 있다면 임의의 폴더를 만들어서 폴더의 이름에 ‘.app’를 추가해 보길 바란다. 이런 식으로 폴더에 몇몇 특정한 확장자를 지정하면 마치 파일처럼 인식하는 것 뿐이다. 당신은 지금까지 폴더를 드래그 해서 넣고 있었던 것. 물론 그 안에는 필요한 바이너리니 리소스니 로컬라이징이니 라이브러리 등이 파일 형태로 잔뜩 들어있다.

다른 한 가지는 시스템에 뭔가 컴포넌트나 시스템 라이브러리/설정을 추가하길 원하는 경우에는 맥OS라도 인스톨러가 필요하다는 것. 유저가 파일 단위로 원하는 장소에 배치를 해서 설치하기를 기대하기는 힘드니 어쩔 수 없지 않은가? 실상은 별반 다를게 없다는 얘기다.

언인스톨러가 프로그램마다 별도로 존재한다고 불평하는 얘기도 들리지만, 이건 개인적인 취향으로 보인다. 나는 윈도에서 ‘프로그램 추가/삭제’ 창을 띄울 때 마다 목록을 만드느라 버벅이는데 신물이 난 상태라 애플리케이션 단위로 분산되어 있는 것을 더 선호한다.

드래그 해서 설치하도록 되어있는 프로그램 중에 시스템에 뭔가 설정파일 같은 것을 남겨 놓는 놈들이 있다. 이런 놈들은 휴지통으로 드래그해서 버리더라도 찌꺼기가 남는다는 것이 불만인 사람들을 많이 보았다. 개인적으로도 꽤 불만인데 이런 부분은 개발자들의 스타일의 문제이기도 하다. 앞서 얘기했던 파일처럼 보이는 폴더를 지원 함으로써 그 폴더 하위에 설정 파일을 수정할 수 있도록 되어 있는데, 불필요하게 시스템단에 설정파일을 생성하는 경우를 볼 수 있었다. 이런 놈들은 파일 생성 과정에서 OS가 퍼미션을 요구하게 되므로 보통 계정 패스워드를 묻는 창을 띄우곤 한다. 기억해 뒀다가 그런 놈들은 삭제하면서 부산물들도 같이 처리해 주는 수 밖에… :(

한국에서 맥OS를 쓰는 데 있어 가장 큰 걸림돌은 바로 한글처리 부분이다. 이 부분은 여태까지 써 오면서 굉장히 여러 번 실망을 해 왔다. 체감상 10년 전의 리눅스 데스크탑 배포판의 한글처리 구현의 수준을 느낄 수 있다고 생각하면 된다.

기본적으로 애플리케이션의 패키징 구조는 지원하는 모든 언어의 리소스를 포함할 수 있도록 유기적으로 구성되어 있어 훌륭하다고 할 수 있지만, 기본적인 입력에서 자주 문제를 일으키는 한글 입력기와, 화면출력용이 아닌 인쇄용으로 만들어진 시스템폰트가 대표적인 한글 문제이다. 특히나 한글 폰트는 유니코드 코드셑에 포함되는 문자들도 거의 가지고 있지 않은(레퍼드에서 보완 됨) 무성의의 극치를 보여주기도 했다.

반면 대조적으로 일본어 지원이 거의 완벽하다시피 한 것에 대해 일부 사람들은 ‘일본의 맥 점유율이 높기 때문’으로 치부하고 넘어가려고 하는데, 닭이 먼저인지 달걀이 먼저인지의 논쟁을 하고 싶지는 않다. 부실한 로컬라이징의 문제는 보는 관점에 따라 같은 가치를 지불하고도 손해를 보는 것일 수 있다. 매니아와 빠돌이의 차이는 얼마나 객관적이고 비판적인 자세를 유지할 수 있는지에서 기인한다.

꼬리

한참 이런 저런 얘기를 벌여 놨는데, 글이 길어져서 대충 용두사미의 마무리를 지어야 할 것 같다.

여러 OS들은 지향하는 바가 조금씩 다르고, 각각의 매력을 가지고 있기도 하다.(실제로 본인은 윈도와 리눅스에도 많은 애증을 가지고 있고, 윈도는 밥벌이(!) 플랫폼이기도 하다) 그 중, 맥OS만 특별히 걸출한 OS라고 말하기 힘들다. 아니, 혹 그렇게 말 하고 싶은 생각이 들더라도 그것이 사실이 아닌 이상 그렇게 이야기 하지 않아야 한다.(어떤 분들, 제발…)

맥OS에 대해서 아쉬운 점도 무척 많지만, 꽤 세심한 매력이 곳곳에 있는 별난 OS임은 분명하다. 그리고 그 세심한 센스에 열광하고 선호하는 유저가 조금씩 늘고 있는 것 같은 요즈음이다. 윈도가 아닌 데스크탑 OS가 세를 키우고 있다는 것도 굉장히 흥미롭지 않은가?(사실은 좀 더 옛날에 리눅스 데스크탑이 이 만큼 커 주길 기대했었지만)

이래저래 당분간은 맥을 계속 쓰게 될 것 같다. ‘대안이 없어서’ ;)

*) 언제든지 글의 내용에 대한 비판은 적극 환영입니다.

매직넘버 0xCAFEBABE 이야기

0xCAFEBABE는 컴파일 된 자바 클래스 파일의 매직넘버로 널리 알려져 있다. (인텔 x86과 같은 리틀엔디안 머신에서는 메모리로 올린 후엔 0xBEBAFECA, PowerPC는 빅엔디안)
헌데 우연히 Mac OS X의 바이너리(Obj-C로 만든 Cocoa기반의)를 열어 봤는데 이 것도 매직넘버가 CAFEBABE로 나오는게 아닌가!

자바 바이너리가 아닌게 확실한데, 이것 참 이상한 일이다 싶어서 누군가 해명 해 놓은 내용이 있나 찾아봤다. 그 내용들 중 비교적 본질에 근접했다고 생각되는 이야기들 중에서 정리해서 번역을 해 봤다. 중간중간 오역 투성이지만 전체적인 맥락에서 이해 해 주시길…

[원문] Why CAFEBABE?

{전략}

저는 1986년쯤 부터 1995년까지 썬에서 대부분 디버거와 C++컴파일러 일을 했습니다. 1991년 무렵, C++ 컴파일러의 기반 코드였던 Tau Metric이 판매 되기 시작하여 썬이 이걸 구입하기 이전에, C++ 컴파일러의 프론트엔드(썬의 CIR에 넣기 위한)를 구현하기 시작한 팀이 있었습니다. 저는 “C++, A Front End”의 약자인 “CAFE”(1989년경으로 기억합니다)라는 이름의 프로젝트에 합류한 사람들 중 한 명 이었습니다. 우리는 Tau Metric을 구입하기 전 단지 몇 달 동안만 이 일을 했고, 회사는 이미 훨씬 완성 된 다른 C++ 컴파일러를 가진 상태였습니다. 우리는 Tau Metric을 사고 프로젝트 이름인 “Cafe”는 유지 됐지만, 이제는 그 컴파일러 프로젝트의 이름으로 전환 되었습니다.

그 컴파일러가 썬의 제품이었을 때에, 마케팅을 할 사람이 있어야 했습니다. Kim Polese가 그 사람 이었습니다. 그녀는 “Cafe”의 제품 매니저 였는데, 저는 사람들이 그녀를 “babe”로 칭하는 것을 쉽게 볼 수 있었습니다. 그녀는 나중에 썬의 준 비밀리에 개발 된 Oak(후에 Java가 된)의 책임자가 되었습니다.

{중략}

Dave Winer가 Kim Polese의 사진을 가리키면서, Steve Zeller가 0xCAFEBABE 매직넘버를 유닉스의 /etc/magic 파일에서 봤다는 것을 언급 했습니다. 그 파일 리스트는 이 전에 “cafebabe”를 골랐던(다른 종류의 파일에 두 번 고른) Mike DeMoney가 만든 것입니다.

{후략}
- Doug Landauer

[원문] 0xCAFEBABE & 0xFEEDFACE

{전략}

자바의 매직넘버는 Mach-O커널의 fat파일 매직넘버와 같습니다. 흥미롭게도 두 개의 매직넘버를 2년 간격을 두고 뽑은 (썬의)책임자는 NeXT출신의 Mike DeMoney입니다.

{후략}
- Larry Schwimmer

그게 만약 사실이라면 조금 흥미롭겠군요.

단순히 사실을 말 하자면, 제가 NeXT를 떠나 책임자로 일하기까지(썬의 자바의 출생지에서) 저는 자바의 매직넘버를 고르는 일을 하지 않았습니다. 도착하기 전에 이미 잘 골라 놨더군요. 제가 NeXT에서 Mach 커널의 fat바이너리 작업을 했기 때문에 제가 NeXT mach-o의 넘버를 골랐을 수 있습니다.(그랬는지 기억나지 않지만)

저는 이 이야기가 아마도 NeXT의 친구(지금은 애플의 아무개 - 본인이 원하면 말할 수 있음)가 이것 관련해서 저를 놀리던 것에서 시작 되었다고 믿습니다. 농담이 스스로의 생명력을 가지게 됐다고 생각합니다. 혹은 그는 아마도 제가 Mach-o일을 했고 자바팀으로 가서 이런 연관성을 만들었다고 정말로 가정하고 있는 지도 모르겠습니다. 그럴 듯한 이야기네요, 다시 말 하지만 사실이 아닙니다.

저는, 16진 표기로 늘어 놓을 수 있는 “예쁜” 단어들의 수가 한정되어 있어서, 두 독립 그룹이 십중팔구 같은 것을 뽑는 것이 전혀 놀랍지 않다는게 이 이야기의 진실이라고 생각합니다. (놀라운건 그걸 이해하지 못한 사람들이 더 많다는 것이죠)

과거에 잠겨있는 것이 별로 좋은 선택은 아니지만, 여러분이 제가 NeXT에서 CAFEBABE를 고른데 대해 힐난할 수 있습니다. 하지만 자바에 다시 하진 않았습니다.
흥미는 없군요. Larry Schwimmer가 누군지 모르겠군요. 그 사람이 저에게 이야기 한 적은 없습니다.
-Mike DeMoney

제가 아는 한, 저는 이 일에 있어 유죄인 당사자입니다. 저는 NeXT 연관성에 대해 전혀 신경쓰지 않았습니다. 작은 숫자의 흥미로운 16진 표기는 조합의 재료가 될 수 있습니다. 자바의 CAFEBABE의 유래는 이렇습니다.

우리는 종종 점심을 먹으러 St Micahel’s Alley라고 불리는 곳에 갑니다. 이 지역의 전설에 따르면, 오랜 옛날에,

{중략}

우리가 그 곳에 가곤 했을 때, 우리는 그 곳을 Cafe Dead라고 이름 붙였습니다. 글자의 선을 쭉 따라가다 보니, 그 녀석이 이건 16진수다 라고 알려 주었습니다. 저는 몇몇 파일 포맷의 코드를 수정하는 중이었고, 지속 개체(persistent object) 파일을 위한 것 하나와 클래스를 위한 하나, 두 종류의 매직넘버가 필요했습니다. 저는 CAFEDEAD를 개체 파일 포맷으로 썼고, “CAFE” 다음에 붙일 4개의 16진 문자를 찾고 있었습니다. 저는 “BABE”가 꽂혔고 그걸 쓰기로 결정 했습니다. 그 때는 그게 끔찍하게 중요하다거나 운명적인 것이라고 생각하지 않았습니다. 그래서 CAFEBABE는 클래스 파일 포맷으로, CAFEDEAD는 지속 개체의 포맷이 되었죠. 하지만 지속 개체의 조합(persistent object facility)은 없어졌고, CAFEDEAD는 쓸모 없어졌습니다. - 결과적으로 RMI로 대체됐죠.
-James Gosling

순서대로 요약하자면, NeXT에서 썬으로 옮겨 간 개발자가 NeXTSTEP에 썼던 CAFEBABE라는 매직넘버를 자바에도 그대로 우려먹어서 문제가 생겼다는 비난에 대해 우연의 일치라며 극구 부인하던 중에, 본좌가 등장하면서 작명가는 본인이며 우연이었다로 마무리가 된다.

쳇… 별거 없잖아; 분위기 보니 Mike DeMoney라는 사람이 처음에 왜 CAFEBABE를 골랐을지 찾아보려 했던 것도 별로 재미 없을 것 같다.

C++0x

차기 C++ 표준안(가칭 C++0x)이 머지 않은 모양이다. (2008년까지 완성해서 2009년에 발표 할 계획을 가지고 있다고 하니…)

관련하여 차기 표준안에 대한 제안서를 정리 해 둔 페이지에서 이미 차기 표준안 작업에 포함 된 문서들 위주로 훑어 보다 보니 꽤 흥미롭다.

템플릿 선언시 부등호 기호 ‘<,>’가 중첩되면 비트연산자가 되어버리는 바람에 꼭 공백을 넣어줘야 하는 바보같은 문제에서 부터, ‘long long’과 같은 타입에 대해서 새로운 형으로 대체하자든지, 널포인터에 대해 nullptr라는 키워드를 추가 한다거나, r-value 레퍼런스(Type&&같은 헛갈리기 좋을 것 같은 모양을 하고 있던데…), thread-safe/lock-free 액세스에 대한 지원+멀티쓰레딩 라이브러리 제공(대환영!) 등등 여러가지 제안이 이미 궤도에 올랐고, 더 많은 수의 제안들이 검토단계의 리스트에 올라와 있다. 여러가지 개선 된다니 좋지만 한 동안 새로운 내용들과 씨름은 피할 수 없을 모양이다.

한참 밑에 있는 내용들을 보면 차기 표준안 이후에는 가비지 컬렉션도 고려 할 모양인가 본데… 아무래도 C++은 C의 패러다임에서 점점 멀어질 수 밖에 없는 운명인가 보다.