오픈 소스 소프트웨어 공동체에서 아키텍처 이식성, 빅 엔디언, 32비트 지원을 둘러싼 흔한 반대 논리를 비판하고, 다양한 플랫폼 지원이 소프트웨어 품질과 공동체에 왜 중요한지 설명한다.
검색
게시일: 2026년 4월 3일 작성자: Spots
참고: 이것도 정말 기술적인 글입니다. PowerPC와 ARM의 차이를 모르는 분들은 아마 이번 글은 건너뛰셔도 됩니다. 내일은 다시 일반 독자를 위한 글로 돌아오겠습니다!
오늘 저녁 친구 한 명이 실수로, 자유로운 표현의 보루라는 그 Hacker News의 엔디언성 스레드를 제게 링크해 주었습니다. (가상의 펜 끝에서 그늘이 뚝뚝 떨어지는 게 느껴지시나요.) 이 글은 예전 블로그를 위해 초안을 잡아 두었지만, 끝맺음이 충분히 좋다는 확신이 들지 않아 끝내 올리지 않았습니다. 그런데 오늘 Zach가 이걸 마저 하게 만들었네요. 결말도 다시 썼습니다.
사랑하는 독자 여러분, 저는 더 넓은 오픈 소스 소프트웨어 공동체 전반에 퍼진 이식성에 대한 적대감에 지쳐 갑니다. 결국 대부분의 프로젝트가 자신들의 잘못을 깨닫게 되는데도, 이식성에 반대하는 똑같이 진부한 주장을 계속 듣는 일은 피곤합니다. 그래서 여기 제가 자주 듣는 가장 흔한 주장들과, 그에 대한 제 반박을 정리해 보겠습니다.
제가 듣는 주장 가운데 가장 불쾌하고 또 가장 흔한 것은, 제가 제안했거나 실제로 작성한 포트가 “오늘날에는 관련이 없는” “오래된” 아키텍처를 위한 것이라는 말입니다.
Linux가 지원하는 아키텍처 가운데 상업적 실용성이 완전히 사라진 것은 DEC Alpha AXP와 Itanium뿐입니다. Itanium은 Linux 커널 6.7에서 제거되었고, 이 일은 예전 블로그에서 따로 글 하나를 쓸 정도의 사건이었으니, 이 녀석은 논의에서 빼겠습니다.
제 생각에 Alpha는 RISC 아키텍처의 핵심 개념 몇 가지를 배우기에 매우 귀중한 자원입니다. 실제로 RISC-V 팀은 Alpha에서 상당한 영감을 받았다고 말했고, 쿼드워드 저장과 관련된 몇몇 특이점만 아니었다면 자신들만의 ISA를 새로 만들기보다 그것을 되살리려 했을지도 모릅니다. 저는 그 아키텍처에서 아직도 배울 가치가 있는 교훈이 더 많다고 생각하고, 그래서 그쪽 개발이 계속 진행되는 모습을 꽤 반갑게 보고 있습니다! 이 흐름은 주로 그 주변의 Gentoo 공동체가 이끌어 왔습니다.
MIPS에 대해서 말하자면, 지금도 상업적 지원이 붙은 제품에서 판매되고 사용됩니다. SPARC는 특허가 없는 개방형 아키텍처이며, 이는 대단히 가치 있습니다. PowerPC는 계속 진화하고 있고, 구형 PPC 시스템은 실제로 확장 가능한 RAM, PCI Express 슬롯 등을 갖춘 RISC 워크스테이션을 아주 저렴하게 구할 수 있는 방법입니다. 심지어 Motorola 68000 아키텍처조차 오늘날에도 임베디드 분야에서 계속 쓰이고 있습니다.
공동체가 어떤 아키텍처용 포트를 여러분에게 제공한다는 것은, 그것이 나온 지 4일이 되었든 40년이 되었든, 공동체가 실제로 그 위에서 여러분의 소프트웨어를 쓰고 싶어 한다는 뜻입니다. 그렇지 않다면 아무도 그런 수고를 들이지 않을 테니까요. 이런 포트 작업은 어렵고, 저 같은 작성자들은 상위 프로젝트가 신경 쓰게 만드는 일 자체가 이미 힘겨운 싸움이라는 걸 잘 알고 있습니다. 우리는 건강을 위해서도 아니고, 무슨 게임처럼 이 일을 하는 것도 아닙니다. 우리가 실제로 가진 문제를 해결하기 때문에 하는 것입니다.
또 하나 짚고 싶은 점이 있습니다. 저는 “진짜” 586(Intel Pentium, 약 1995년)에 Linux를 부팅해 봄으로써 Linux 커널의 실제 보안 버그를 찾아냈습니다. 원인은 커널 static_key API의 잘못된 사용이었고, 그 결과 586에서는 루트가 아닌 사용자도 보호된 API에 접근할 수 있었지만, 더 새로운 아키텍처에서는 조용히 묻혀 버렸습니다. 커널 개발자들이 사용하던 586의 QEMU 에뮬레이션에서도 이 문제는 드러나지 않았는데, CR4 에뮬레이션에 버그가 있었기 때문입니다.
저는 “리틀 엔디언이 이겼다”거나 “빅 엔디언은 이제 더 이상 존재하지 않는다” 같은 말을 자주 듣습니다. 이 말은 틀렸을 뿐 아니라, 마치 전쟁처럼 사태를 틀 짓습니다. 바로 Hacker News에서 본 이런 수사 때문에 저는 이 글 초안을 다시 꺼내 마무리하게 되었습니다. 저는 건강한 컴퓨팅 생태계를 위해 두 종류의 엔디언이 모두 필요하다고 진심으로 믿으며, 둘 중 하나라도 존재하지 않는 소프트웨어 공학에는 참여하고 싶지 않습니다. 단호하게 말해서요.
제 친구들 사이에서는 엔디언 정합성이 거의 밈이 되어 있습니다. 제가 모든 코드를 빅 엔디언과 리틀 엔디언 시스템 양쪽에서 반드시 테스트해야 한다고 워낙 강하게 주장하기 때문입니다. 모르시는 분들을 위해 설명하자면, 엔디언성은 컴퓨터가 숫자를 저장하는 방식일 뿐입니다. 빅 엔디언 시스템은 인간이 쓰는 방식대로 숫자를 저장합니다. 가장 큰 자리 숫자가 먼저 옵니다. 리틀 엔디언 시스템은 그 반대로 저장합니다. 가장 작은 자리 숫자가 먼저 옵니다. 그래서 ‘big’과 ‘little’인 것입니다.
저는 개인적인 개발 생활에서는 빅 엔디언 시스템을 선호하는 편입니다. 특히 크래시 덤프를 읽을 때 작업하기가 더 쉽기 때문입니다. 빅 엔디언 시스템은 또한 어떤 종류의 버그를 훨씬 더 빠르고 쉽게 드러나게 합니다. 리틀 엔디언 시스템에서는 숨어 있을 수 있는 버그가, 빅 엔디언에서는 “빠르게 실패”하면서 드러나는 셈입니다. 여기에는 보안 버그로 이어질 수 있는 잘못된 형 변환 같은 부류가 포함됩니다.
최근에는 Git에서 메모리 손상 버그가 발견되었습니다. 그리고 그 버그가 발견된 이유는 빅 엔디언 컴퓨터에서 테스트 스위트가 제대로 동작하지 않았기 때문입니다. 그 버그는 리틀 엔디언에도 있었지만, 거기서는 테스트 스위트를 충돌시키지 않았습니다. 저는 추가로 Clang의 잘못된 메모리 읽기/저장 문제도 찾아냈는데, 이 역시 어디에서나 잘못된 코드였지만 32비트 빅 엔디언 하드웨어에서만 충돌이 발생했습니다.
엔디언에 안전한 코드를 작성하는 일은 보통 어렵지 않습니다. 엔디언에 안전하지 않은 코드는 기껏해야 형편없이 작성되어 유지보수가 더 어렵고, 최악의 경우에는 보안 버그를 가리고 있을 가능성도 있습니다. 어떤 프로젝트 관리자라도 자기 프로젝트에 빅 엔디언 포트를 추가하는 패치를 받으면 기뻐서 뛰어올라야 합니다. 특히 테스트 통과 보고와 소프트웨어가 잘 동작한다는 보고까지 포함되어 있다면 더더욱 그렇습니다. 그것은 당연해야 하는 수준의 제정신을 갖춘 코드베이스라는 신호이며, 그런데도 오늘날에는 그런 사실이 눈에 띄게 느껴질 정도입니다.
오늘날 존재하면서 오직 빅 엔디언만 사용하는 유명한 아키텍처로는 System/390(s390x) 메인프레임과 SPARC가 있습니다. 빅 엔디언과 리틀 엔디언 어느 쪽도 될 수 있는 바이엔디언 아키텍처에는 PowerPC(네, Power9와 10도 포함입니다!)와 Arm이 있습니다. 손쉽게 구할 수 있고 저렴한 BE CI 컴퓨터가 필요하다면, 실제로 Pine A64와 대부분의 Raspberry Pi 보드를 빅 엔디언 모드로 부팅할 수 있습니다! 이 분야는 언젠가 제가 집중하고 싶은 개발 영역이기도 합니다.
32비트에 대한 반대 논리 상당수는 “오래된 것”에 대한 논리의 변형입니다. 대부분의 32비트 아키텍처가 64비트 후속 아키텍처보다 먼저 나왔기 때문입니다. RISC-V는 자사 ISA의 32비트 변종을 도입했으니 완전히 맞는 말은 아니지만, 대부분의 32비트 아키텍처가 64비트보다 오래되었다는 점은 인정합니다.
이미 말했듯이, “오래되었다”는 것이 항상 “나쁘다” 혹은 “더 열등하다”를 뜻하지는 않습니다. 이 기회에 한 가지 덧붙이자면, 개발도상국에서는 물론이고 선진국 안의 더 가난한 공동체에서도 많은 사람들이 데스크톱 하드웨어로 32비트 ARM 시스템이나 Celeron에 의지해 살아가고 있습니다.
32비트 아키텍처에 반대하며 제기되는 또 다른 논리는 메모리 공간입니다. 4 GB로 제한되며, 대부분의 경우 실제로는 그보다 조금 적습니다. HPC나 머신 러닝 분야에서 32비트 지원이 부족한 점에는 나름 할 말이 있습니다. 그 분야에서는 방대한 데이터셋을 사용하니까요. 하지만 대부분의 소프트웨어 프로그램은 그런 영역에 속하지 않습니다. 4 GB 메모리 장벽이 웹 브라우저, 이메일 클라이언트, 프로그램 컴파일러 같은 소프트웨어의 실행 시작을 어떤 식으로든 막아야 할 현실적인 이유는 없습니다.
바로 그 이유 때문에 32비트 지원은 때로 조금 더 어렵습니다. 최적화와 효율성이 필요하기 때문인데, 너무 많은 소프트웨어 프로그램이 바로 그것을 갖추지 못하고 있습니다. 이것은 우리 업계의 오랜 과제였고, 앞으로도 계속 그럴 것입니다. 누군가 여러분의 소프트웨어를 32비트에서 돌아가게 만드는 데 성공했다면, 그 포트를 받아들여야 합니다. 그렇게 하면 64비트 시스템에서도 여러분의 소프트웨어가 효율성을 유지하도록 도와주기 때문입니다. 결국 모든 프로그램이 4 GB 안에 들어가야 한다면, 여러분이 너무 당연하게 누리고 있는 32 GB RAM 워크스테이션에서는 무려 프로그램 8개를 동시에 돌릴 수 있다는 뜻입니다! 그런 성능이면 얼마나 멋진 멀티태스킹이 가능할지 생각해 보세요!
오픈 소스와 자유 소프트웨어 프로젝트는 거의 언제나 참여자들에게 열정 프로젝트입니다. 자유 소프트웨어가 상업적 이해관계에 의해 통제되는 경우에도, 그 위에서 일하는 직원들은 자신이 유지보수하는 소프트웨어에 어떤 형태로든 개인적인 애착을 느낍니다. Linux가 이렇게까지 거대해진 것은 어떤 하나의 기술적 장점 때문이 아니라, 그 뒤에 있던 열정적인 사람들 덕분입니다.
마무리하며 이 점을 다시 한 번 아주 분명하게 강조하고 싶습니다. 여러분이 자유 소프트웨어 프로젝트의 관리자이면서 공동체가 만든 다른 아키텍처용 포트를 거부한다면, 그것은 공동체와 소프트웨어의 전체적인 품질에 엄청난 해를 끼치는 일입니다. Linux 커널이 보여 주었듯, 공동체의 요구와 관심이 커졌다 줄었다 함에 따라 새로운 포트를 받아들이고 오래된 포트를 폐기하는 일은 가능합니다.
꼭 그래야 한다면 Itanium과는 작별을 고하세요. 하지만 여러분의 공동체가 여러분이 한 번도 상상하지 못했던 곳에서 여러분의 코드를 보고 싶어 한다면, 그것을 진정한 칭찬으로 받아들이세요. 그리고 공동체와 함께 그들의 꿈을 모두가 혜택을 얻을 수 있는 공동의 현실로 만들어 가세요. 결국 우리가 여기 있는 이유가 바로 그것이니까요. 우리 공동체에 도움이 되기 위해서 말입니다!
이 글은 Spots가 Tech Stuff에 올렸습니다. 고유 링크를 북마크하세요.
이메일 주소는 공개되지 않습니다.필수 입력 칸은 * 로 표시됩니다.
댓글 *
이름 *
이메일 *
웹사이트
다음에 댓글을 남길 때를 위해 이 브라우저에 내 이름, 이메일, 웹사이트를 저장합니다.
이메일로 후속 댓글 알림 받기.
이메일로 새 글 알림 받기.
