메타에서 커스텀 XR OS를 구축하는 것에 대한 John Carmack의 반대 주장

(twitter.com/ID_AA_Carmack)

1P by GN⁺ 3일전 | ★ favorite | 댓글 1개

John Carmack는 Meta의 커스텀 XR OS 개발에 반대 입장 표명
그는 자체 운영체제 개발이 복잡성과 리스크 증가로 이어짐을 강조함
기존 플랫폼 활용이 개발 효율성과 자원의 최적 활용에 더 효과적임을 주장함
Carmack는 시장에서의 신속한 혁신과 대응을 위해 표준 OS 기반 전략을 추천함
그는 불필요한 기술적 분열과 파편화를 피할 필요성을 강조함

John Carmack의 Meta 커스텀 XR OS 반대 논거

배경

John Carmack는 Meta가 자체적으로 커스텀 XR(확장현실) OS를 개발하는 방안에 대해 부정적 견해를 가지는 것으로 알려짐
XR OS는 AR/VR 등 확장현실 기기에서 동작하는 운영체제를 의미함

주요 주장 요약

Carmack는 이미 시장에 존재하는 플랫폼(Android, Windows 등) 위에서 개발할 경우, 개발 속도와 혁신이 더욱 가속화됨을 언급함
커스텀 OS 개발은 복잡성 증가, 버그 발생 위험, 장기적 유지보수 부담 등 여러 문제점을 동반함
자체 플랫폼 구축에 자원 투입시, 기존 생태계의 표준화된 도구와 기술을 활용하는 장점이 희생됨
신기술 및 사용자 요구 변화에 보다 신속하게 대응하려면 기존 OS를 적극적으로 활용하는 전략이 효과적임
커스텀 OS는 개발자와 소비자 모두에게 호환성 문제와 학습 비용을 유발할 수 있음

결론

Carmack는 장기적으로 기술과 서비스의 파편화를 방지하고, 확장성과 활용성을 극대화하기 위해 커스텀 XR OS 개발보다 기존 플랫폼 활용 전략을 선호함

▲

GN⁺ 3일전 [-]

Hacker News 의견

Meta에서 일하는 문제점은, 내가 성과를 내면 오히려 세상을 더 안 좋게 만드는 걸 돕는 셈임… 진짜 영웅은 돈과 효율을 낭비하는 사람들이라는 생각임 실력 있다면 다른 곳에서 경력을 쌓는 걸 추천함
- 소프트웨어 엔지니어가 인류에 봉사할 수 있는 최고의 방법 중 하나는 Meta나 TikTok 같은 회사에 들어가서 가능한 오래 못하는 척하는 것임
- 나는 Facebook과 연관 서비스는 차단하고 zstd는 쓸 거임 세상은 흑백 논리가 아님
- 그건 너무 단순한 시각임 Meta의 핵심 사업에 대해 어떻게 생각하든, 이 회사는 다양한 오픈소스 프로젝트와 VR, 데이터센터 기술 등 소셜미디어랑 크게 상관없는 R&D에도 많은 엔지니어를 고용해서 일하게 함 관심 분야 연구로 월급 받는 것 중에는 더 나쁜 길도 있다고 봄
- 좀 비관적인 의견이긴 한데, 지금까지 데이터로 보면 반박하기 쉽지 않음
- 하지만 사실 모든 대기업, 심지어 모든 상장기업에도 해당되는 포인트 아닌가 싶음 창업자가 처음엔 다른 목표도 있었겠지만 시간이 지날수록 결국 이익만이 목표가 되고, 보통 이익은 나쁜 일에 집중할수록 훨씬 더 많이 생김 이건 시스템적인 문제임
나는 다양한 저수준 소프트웨어, BSP, 거의 운영체제 전체를 만들어봤는데, 요즘 OS를 직접 만들지 않는 진짜 이유는 실리콘 벤더들 때문임 예전에는 드라이버를 직접 쓸 수 있게 상세한 명세를 줬지만, 요즘엔 애매모호한 설명에다가 퀄리티 떨어지는 Linux 드라이버만 던져줌 게으름도 있지만, 복잡성이 커졌기 때문임 현대 하드웨어는 너무 복잡해서 전체를 문서화하는 데만도 오래 걸리고, 직접 드라이버를 쓰면 그보다 더 오래 걸림
- 인텔은 아직도 제대로 된 문서를 줌 고속 NIC용으로 아주 자세한 문서가 공개돼있고, 실제로 e810 100Gb 이더넷 카드 같은 경우 공식 2750페이지짜리 데이터시트만으로 드라이버를 처음부터 쓸 수 있음 다른 벤더들은 (1) 무시하거나 (2) NDA를 요구하거나 (3) 허접한 리눅스/FreeBSD 드라이버 문서만 보여줌 NVMe SSD처럼 다른 하드웨어들은 상황이 어떤지 잘 모르겠음
- 나도 최근에 취미 OS에서 "소프트 리부트" 버튼 지원하려다 진짜 힘들어서 포기함 (GCP에서 리부트 속도 빠르게 하려고) OS Dev Wiki 지침, Linux랑 FreeBSD 소스까지 다 읽었지만 진전이 전혀 없었음 윈도우든 리눅스든 리스타트할 때 쓰는 기능임 며칠 버리다가 결국 포기했음 OS 개발자는 정말 다른 결로 만들어진 사람들이고, 보통 경제적 압박 안 받는 듯함
- “현대 하드웨어가 너무 복잡해서 문서화가 어렵다”라는 말 많이들 하는데, 다 핑계라고 생각함 팀에 새 직원 트레이닝도 해야 하고, 테스팅 관리도 해야 해서 원래 복잡하면 더 자세히 문서화해야 함 즉, 실리콘 벤더들의 변명은 와닿지 않음
- 요즘 진지하게 OS 직접 만들 생각이라면, 하드웨어에 대해 매우 강력한 통제를 갖던가, 아니면 OS에 servant Linux 인스턴스를 포함하는 방법밖에 없을 것 같음 윈도우는 버그 같지만 일단 드라이버가 붙어있고, 리눅스는 무료인 버그 드라이버들임 OS가 리눅스 하이퍼바이저 위에 클라이언트로 계속 돌아도 괜찮으면 그 길로 가는 것도 방법이고, 아니라면 하드웨어 지원 기능을 내 OS로 하나씩 조금씩 옮기는 수밖에 없음. 다만 그 속도가 리눅스 새 의존성 생기는 것보다 빨라야 함…
- 특정 OS 종류의 경우엔 리눅스 하드웨어 지원을 대부분 포팅된 LKL(https://github.com/lkl/linux) 쓰고 하드웨어 접근용 후크만 추가하면 쉽게 가져올 수 있다고 생각함 물론 코어 플랫폼/칩셋용 코드는 따로 써야겠지만, 나머지 I/O 장치는 거의 커버됨 일반적인 모놀리식 커널보다는, 유저 모드 드라이버 지원하는 스타일이면 더 잘 동작할 듯함
John의 얘기, 내가 실제로 누군가 만들어줬으면 좋겠다고 생각하는 시스템을 딱 설명함 “뭔가 완전히 색다른 컴퓨터를 만들고 싶으면, 이미 존재하는 솔루션의 중력 우물에서 빠져나오려면 사실상 은둔한 수도승 엔지니어 집단이 필요함” 상상실험 해보면: - 월 생활비가 200달러인 곳 정하기 - 살기 좋은 마을 만들기 (맑은 공기, 건강한 음식, 좋은 학교 등) — 부자가 후원해도 크게 부담 없을 만큼 - 소프트웨어, 인터넷 거의 없는 컴퓨터만 잔뜩 제공하기 - 전혀 새로운 컴퓨팅을 처음부터 만들어보기 인내심이 핵심임. 수십년 걸릴 거임
- 이 아이디어 완전 흥미로움 그런 낮은 생활비 따질만한 장소가 어딘지 궁금함 근데 진심으로 궁금한 건 지금 왜 바로 실현 불가능한 문제를 풀려는지? CPU 같은 하드웨어부터 시작해야 하나? 예전에 Intel 출신 엔지니어가 했던 말 기억남 — 현대 ISA, CPU uArch, GPU 같은 것까지 전부 배우고 완전히 새로 만드는 건 직접 경험하고 삽질까지 다 해보려면 은퇴할 무렵이나 가능함
- 10년 넘게 직접 OS 만들어보고 있는데, 진짜 뭔가 해보고 싶다면 할 일이 아님 물론 재밌긴 함, 때론 상상함. 언젠가 엄청난 개발자 군단이 붙으면 어디까지 성장할지. (물론 돈은 안 벌릴 거지만)
- 솔직히 이건 엄청 멋진 SF 컨셉 같음
Meta에서 운영체제 관련해서 Microsoft에서 온 사람들이 많은데, 이분들 원래 OS 만드는 데 관심이 많았음 근데 Meta에서는 XR 작업에 투입됐고, 당연히 커스텀 OS를 만들고 싶어했음
John Carmack이 Meta에서 한 것 때문에 이제는 진지하게 받아들이기가 힘듦 SerenityOS만 봐도 Windows나 Linux보다 더 쓰기 편하고 일관성 있는 시스템 만드는 게 충분히 가능했음 분명한 비전, 추진력, 헌신이 “톱 엔지니어” 고용이나 “고품질 코드”보다 더 핵심임 — 그런 게 있으면 어차피 좋은 코드와 인재가 따라옴 이게 Meta에서 불가능한 이유고, Linux가 지금 그 모양인 이유임 실제 장애물은 결국 드라이버임. 참고: Thirty-Million line 문제 — caseymuratori.com 블로그
Oculus 합병 후 근무하면서 XROS가 핵심 기술 팀에게 정말 번거롭고 산만한 존재였음 여러 기술 스택에 이미 해결해야 할 문제들이 산더미였는데, XROS라는 아이디어는 오큘러스가 FB에 완전히 통합된 후에 나옴 내가 볼 땐 FB 팀(혹은 개인) 몇몇이 ARVR 트렌드에 합류하고 싶었던 것으로 느껴짐 Carmack이 완전히 옳았고, 리오그 이후로 그의 영향력이 점점 줄어 몸소 악영향을 느낌
- XROS 팀 대부분은 FB 본사가 아니라 산업에서 경력직으로 영입함 (대부분 E5/E6 레벨) FB SWE는 기술역량이 안 맞았고, 부트캠프 출신도 몇 있었지만 성공 못 하고 금방 다른 데로 옮김
- Oculus 오픈소스 커뮤니티를 망치고, 커뮤니티가 돈 모아준 프로젝트를 또 하나의 Meta 사슬로 만들어 개인정보 챙겨간 것에 분노함 그래도 페이첵은 두둑했기를 바람
나는 2002~2004년쯤 Microsoft에서, OS 개발자 몇 명이 Bill Gates의 Think Week를 위해 해커톤처럼 작성한 내부 논문을 읽었음 .NET 기반 위에 GC, 메모리 매니지먼트 다 직접 넣은 완전 새 운영체제였고, 각종 하드웨어에서 부팅도 되고 재밌는 기능도 많았음 명확하게 Windows와는 호환 제로라는 디자인이었고, 아마 그게 실패 이유였을 듯 몇몇 OS 전문가가 한 달 정도 집중해서 해낸 작업이었는데, 정말 재미있었음
- Singularity였나? Wikipedia의 설명 Microsoft Research의 공식 페이지
- Midori 프로젝트였던 듯 사실 수년간 100명 넘게 투입했던 Microsoft Research 대규모 프로젝트임 ZDNet의 미도리 프로젝트 기사
John Carmack가 XROS 팀 매니저에게 “팀원 기분 상하게 한다”라며 HR에 신고당했다는 얘기가 나왔음 사실 나는 Carmack의 공개 커뮤니케이션에서 항상 프로페셔널하고 친절하다고 느껴왔음 나도 비슷한 HR-무기화 경험이 있는데, 이런 일은 회사 분위기를 위축시킴 — 한 번 누가 내 말이 싫다고 HR에 제소할 수 있다는 생각이 들면, 그 다음부턴 다들 발언에 엄청 조심함
- Carmack이 퇴사 전 내부 포스트를 계속 팔로우했는데, 자원 낭비에 엄청 엄격했고, 손 추적 기능이 자주 고장 나면 거기에 수치를 근거로 지적함 그의 메시지는 항상 “Apple은 하드웨어를 잡았으니 이제 효율적인 소프트웨어가 미래의 열쇠다”라는 관점이었고, Meta의 방만함은 결국 조직 내 힘싸움 때문임
- Lucovsky는 직접 OS를 처음부터 만들겠다고 고집하다가 현장 프로덕트 팀이 고객에게 실제 뭔가 제공해야 된다는 현실성을 못 봤고, 그래서 밀려났음 그가 남긴 독성(본인은 심각성 모름)도 영향 비슷한 행동이 Google에서도 반복됐는데, 거기도 결국 밀려나게 됐고 공식적으로는 스스로 사임했다고 마무리됨 트위터 참고 1 트위터 참고 2
- John은 실제로 대면하면 굉장히 직설적이고 날카로울 때가 있음 자기가 신념 없는 일에는 지나치게 비판적일 수 있고, 그럴 때는 파워 밸런스상 반박하기도 어려움
- Meta는 당시 내부 분위기가 좀 이상했음 PSC(성과평가)가 중요해서, Carmack 같은 전설적 인사가 내 프로젝트를 “자원 낭비”라 평하면 그게 평가에 직격탄이었음 “임팩트”는 Facebook에서 “이게 회사에 얼마나 유용한가”를 재는 중요한 축임
- Google에서도 비슷한 장면을 봤음 Distinguished engineer가 junior 엔지니어에게 처음엔 부드럽게, 그후 똑부러지게 “그건 안 좋은 아이디어니까 그만 두라”고 했더니 HR이 개입한 경험 있음 이런 와중에, 더는 시간·노력을 쏟기 싫어서 문제를 그냥 넘긴 적도 있음
Google에서 Flutter 팀이 Fuchsia 만들 때 있었음 정말 뛰어난 인재 (내가 봤던 가장 우수한 엔지니어들)였고, 인원도 수백 명에 규모도 컸음 기술적으로는 대단히 훌륭했지만, 애초에 누가 사용하게 되는지 명확한 답을 아무도 못함 Kernel만 새로 만들고 기존 Linux 대체 같은 목표였다면 괜찮았겠지만, 반대로 운영체제를 kernel, UI, window manager까지 모든 레이어를 처음부터 만들려 했음 결국 Home Hub 같은 UI만 있는 특수 기기만 타겟했고, 그마저도 기존 제품 대비 굳이 이렇게 복잡하게 OS를 바꿔야 하는 이유를 제시 못함 아직도 Fuchsia가 계속되고 있다는 게 어이없을 정도로 납득 안 됨 구글이 구조조정하면서 필수팀은 자원 삭감하면서도 이런 프로젝트에는 인력을 남겨둔 걸 보면 더욱 우울함 오히려 이걸 왜 살려두는지 진짜 모르겠음
- 단기 성과만 보면 변명을 찾기 어렵지만, 장기적으로 생각하면 새 OS 개발도 타당함 Google은 실제로 장기 투자에 관심 있고, 프로젝트가 대외적으로 명분을 내세울 필요도 없음 굳이 비판하는 쪽이 오히려 이상한 것 같음. 필요하면 참여, 아니면 그냥 무시하면 됨 새로운 애플리케이션 생태계 창출은 애초에 목표가 아니었고, 가장 어려운 건 평소엔 당연하다고 여기는 수많은 기술을 전부 구현해야 한다는 점임. 힘들지만 불가능하지 않음 선택지가 늘어나 나쁠 건 없음 — 브라우저 시장은 다양성 중요하다고 하면서 OS 시장은 독점이 괜찮다는 모순적 논리 대신, 더 다양한 OS가 좋은 격임
- 일부 기기(Home Hub)를 시작점으로 삼는 거고, 거기서 경험/수익 쌓고 점점 확장해나가는 게 목표였던 듯함 한꺼번에 모든 걸 대체하겠다고 시작한 건 아닐 거라 생각함
- Fuchsia가 사실은 여러 OS와 앱 패키지들이 완전 컨테이너로 돌아가는 새로운 패러다임이라고 이해했었음 내 상상으로는 웹에서도 돌아가고, 여러 머신에서 같이 돌릴 수도 있는 미래의 OS를 그리고 있었음 여러 인스턴스를 같은 머신에서 돌려서 각각 다른 유저에게 맞춰주는 방식도 기대했음
- 나는 Fuchsia가 구글이 뛰어난 커널 엔지니어들을 경쟁사로 안 가게 붙잡아두려는, 일종의 소모전 프로젝트라는 느낌이 들었음
- Home Hub에 Fuchsia 탑재를 강제로 밀어붙여서 기존 스택은 바로 레거시가 됐고, 그 후 계속 일정이 지연돼도 아무런 결과가 없었음 OS 직접 만드는 건 멋있어 보였지만, 프로젝트 전체가 나머지 팀들의 일에 악영향만 준 느낌임
요즘엔 리눅스 커널을 바이패스해서 직접 하드웨어로 접근하는 게 간단해졌고, 코어 많은 CPU도 흔함 핵심은 코어를 격리해서 스레드를 할당하고, 커널 바이패스 기법으로 직접 하드웨어 제어. 코어 사이 소통은 링버퍼로 하면, 거의 하드웨어에 최적화된 성능에 더해 관리/모니터링/디버깅은 리눅스 커널의 장점도 함께 쓸 수 있음
- /dev/mem을 mmap해서 물리 메모리 직접 접근하는 것처럼, 언제든 커널 바이패스가 가능함

답변달기