왜 0xCAFEBABE인가?

AI 요약

Java의 .class 파일은 첫 4바이트에 0xCAFEBABE를 기록합니다. 파일 형식을 읽는 도구는 이 값을 먼저 확인해 해당 파일이 Java class file일 가능성이 있는지 빠르게 가립니다. 16진수 값으로는 32비트이며, 십진수로는 3,405,691,582입니다.

1996년 5월, Bill Venners는 두 번째 JavaWorld 글인 《The Class File Lifestyle》을 준비하다가 이 매직 넘버의 유래를 궁금해했습니다. 그는 comp.lang.java 뉴스그룹에 “왜 이 값이 선택됐는가”를 물었습니다. 당시 답변에서는 먼저 파일 형식을 식별하려면 어떤 매직 넘버나 문자열이든 필요하다고 설명했습니다.

32비트 값과 CAFE라는 표현

Alastair Mayer는 32비트 매직 넘버가 다루기 쉽고 다른 값과 겹칠 가능성도 낮다고 추측했습니다. Java와 커피의 연관성을 표현하고 싶어도 16진수에는 A부터 F까지만 쓰므로 J나 V를 넣을 수 없습니다. 그래서 CAFE를 포함한 표현을 골랐다는 해석입니다. 당시 논의에는 A FAB CAFE, CAFE FACE, CAFE A FAD, A BAD CAFE 같은 대안과 0xC0FFEE도 등장했습니다. 0xC0FFEE를 32비트로 쓰면 0x00C0FFEE가 되며, 이를 “Object Oriented Coffee”로 읽을 수 있다는 농담도 나왔습니다.

실제 선택 이유

Java 팀의 Patrick Naughton은 0xCAFEBABE가 Java라는 이름이 언급되기 훨씬 전에 정해졌다고 설명했습니다. 선택 기준은 재미있고, 독특하며, 기억하기 쉬운 값이었고, 두 번째 후보는 0xDEADBABE였습니다. Peet's Coffee의 귀여운 바리스타를 떠올리게 하는 표현이 훗날 Java라는 이름을 미리 암시한 것은 우연이라고 덧붙였습니다.

매직 값의 다른 사례

토론에서는 사람이 메모리와 디버거에서 쉽게 알아볼 수 있는 16진수 값을 다른 시스템도 사용해 왔다는 사례가 이어졌습니다. Burroughs B6700은 48비트 워드의 초기화되지 않은 메모리를 0xBADBADBADBAD로 채웠습니다. 0xDEADBEEF는 잘못된 값이나 초기화되지 않은 영역을 표시하는 값으로 언급됐고, AIX의 RS/6000은 0xDEADBEAF를 사용한다는 답변도 나왔습니다. Solaris 커널은 kmemfree()로 반환된 블록에 0xCAFEFEED를 기록하며, IRIX arena 파일의 시작에는 0xDEADBABE가 쓰인다는 사례도 제시됐습니다.

한 참여자는 NeXTSTEP의 fat binary에서 서로 다른 프로세서용 바이너리를 구분하는 값으로 0xCAFEBABE를 봤다고 회상했습니다. 이 값이 Java에 사용되기 전부터 다른 시스템에 등장했다는 주장도 있었지만, Patrick Naughton의 설명은 Java 팀이 선택한 직접적인 이유를 재미와 기억 용이성으로 정리합니다. .class 파일의 매직 넘버는 형식 식별에 쓰이고, 비슷한 16진수 값은 메모리 오류와 사용되지 않은 영역을 찾는 디버깅 표지로도 쓰입니다.

Lobsters 반응

• @mdaniel — 20여 년 전 Burroughs B6700이 48비트 워드의 ‘초기화되지 않은’ 메모리를 0xBADBADBADBAD로 채웠다는 부분은 한편으로 정말 멋집니다. 다른 한편으로는 48비트 워드라니요 :-D BCD가 6비트였던 것과 관련 있다고 추측합니다.
• @dimonomid — 비슷한 목적으로 이런 ‘멋진’ 숫자를 쓰는 일은 꽤 흔합니다. 예전 Tneo RTOS 프로젝트는 여전히 태스크 스택을 초기화할 때 0xFEEDFACE를 사용합니다. 디버거에서 사용하지 않은 스택 공간을 확인하는 데 유용합니다. 0xCAFEBABE는 Java에 정말 잘 맞습니다. 마음에 듭니다.

원문: Artima / 번역·요약: Trawling