이전에 MVC Song을 소개했던 포스트가 있었는데,
알고보니 그 이후로도 이 아저씨의 신작이 계속 나오고 있었던 모양이다.

컨츄리한 멜로디에 계몽적인(?) 가사를 달아서 천역덕스럽게 부르면서 세뇌시키는 현장들.
메마르기 쉬운 개발자로 일하면서도 풍류를 잃지 않는 모습이 멋져 보인다.

MVC Song이 워낙 포스가 강하긴 했지만, 다른 노래들도 재미있게 들어볼만 하다.
개인적으론 Release Me가 아주 인상적이었다.

MVC Song @ WWDC 2003

Modelin’ Man @ WWDC 2004

Release Me @ WWDC 2007 (발표는 WWDC 2005)

I Love View @ WWDC 2007

Designated Initializer @ WWDC 2008

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++ 표준안(가칭 C++0x)이 머지 않은 모양이다. (2008년까지 완성해서 2009년에 발표 할 계획을 가지고 있다고 하니…)

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

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

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