2026 Mojo 컴파일러 소스 빌드: 맥 메모리가 부족할 때 어떻게 해야 할까?

2026년 8월 18일, Mojo 컴파일러와 도구 모음이 Apache 2.0 라이선스와 LLVM 예외 조항으로 공개되었습니다. 공식 공개 안내에 따르면 저장소에는 build-mojo와 prebuilt-mojo 설정이 함께 제공됩니다. 결론은 간단합니다. 컴파일러 본체를 읽거나 고치거나 디버깅할 때만 build-mojo를 선택하고, 표준 라이브러리 개발과 예제 실행, MAX 대상 빌드에는 prebuilt-mojo를 우선 사용해야 합니다.

공식 문서에는 Mojo 개발을 위한 일반적인 메모리 요구 사항만 있고, Apple Silicon Mac에서 전체 컴파일러 소스 빌드가 안정적으로 끝나는 메모리 하한은 공개되지 않았습니다. 따라서 특정 용량을 보장값처럼 믿기보다, 실제 피크 메모리와 반복 빌드 성공률을 기록한 뒤 로컬 빌드를 계속할지 고메모리 원격 맥으로 옮길지 결정해야 합니다.

마지막 업데이트: 2026년 8월 26일. 공개 안내, 현재 저장소의 빌드 문서, 시스템 요구 사항, Bazel 명령 참고 자료를 기준으로 확인했습니다. 빌드 설정이나 MAX 제한이 바뀌면 명령을 다시 검증해야 합니다.

이 글은 이런 독자를 위한 안내입니다.

• Apple Silicon Mac에서 Mojo 컴파일러를 단일 단계로 디버깅하거나 수정하는 개발자
• Bazel 실행이 운영 체제에 의해 종료되거나 스왑 메모리가 급증한 엔지니어
• 로컬 맥, 원격 맥, prebuilt-mojo를 조합할 개발 환경을 평가하는 팀 책임자

처음부터 전체 컴파일러를 빌드하지 않아도 되는 경우

Mojo를 사용해 표준 라이브러리 코드를 만들거나 예제를 실행하는 것이 목적이라면 컴파일러 본체를 다시 만들 필요가 없는 경우가 많습니다. prebuilt-mojo는 변경하지 않은 컴파일러를 내려받아 사용하는 경로입니다. 반대로 컴파일러 내부 동작을 추적하거나 파서, 의미 분석, 코드 생성 단계 자체를 수정하려면 build-mojo가 필요합니다.

표준 라이브러리 수정은 먼저 현재의 사전 빌드 컴파일러로 원하는 동작을 재현해 보아야 합니다. 표준 라이브러리의 소스만 바꾸는 작업이라면 매번 컴파일러 본체를 다시 빌드하는 방식은 불필요한 대기 시간을 만듭니다. 다만 저장소의 빌드 의존성이 바뀌었거나 컴파일러 내부 변경이 표준 라이브러리 동작과 직접 연결되었다면 build-mojo로 다시 검증해야 합니다.

MAX 대상은 별도로 분리해야 합니다. 공식 빌드 안내는 현재 로컬에서 만든 컴파일러를 MAX 대상 빌드에 사용할 수 없으며, MAX 커널이나 모델을 수정할 때도 prebuilt-mojo가 필요하다고 설명합니다. 이 제한을 무시하면 메모리 문제로 잘못 판단하기 쉽습니다. 저장소의 빌드 설명에서 실행 대상과 설정을 먼저 확인해야 합니다.

또 하나의 비용도 있습니다. 컴파일러와 도구 모음 기여는 현재 열려 있지 않으며, 2026년 말까지 열겠다는 내용은 계획입니다. 현재 저장소와 기여 안내를 확인하지 않고 제출을 전제로 큰 환경을 준비하면, 당장 반영할 수 없는 변경에 빌드 비용만 투입할 수 있습니다.

첫 빌드 전 기록해야 할 맥 환경

실패 원인을 찾으려면 빌드가 끝난 뒤의 느낌이 아니라 시작 전 상태가 필요합니다. 다음 항목을 같은 형식으로 기록합니다.

1. 칩과 운영 체제 확인
   Apple Silicon Mac인지 확인하고, 공식 Mojo 시스템 요구 사항과 현재 macOS 및 Xcode 명령 줄 도구 버전을 대조합니다.

2. 저장소와 래퍼 확인
   사용할 커밋을 고정하고 저장소를 받은 뒤 ./bazelw가 실행되는지 확인합니다. 시스템에 따로 설치한 Bazel이 아니라 저장소가 지정한 래퍼를 사용해야 팀 간 결과 비교가 쉬워집니다.

3. 통합 메모리와 여유 공간 기록
   전체 통합 메모리 용량만 적지 말고, 시작 직전 사용 가능 메모리와 디스크 여유 공간을 함께 기록합니다. 공식 일반 요구 사항은 컴파일러 전체 소스 빌드의 보장 하한이 아닙니다.

4. 백그라운드 작업 분리
   가상 머신, 컨테이너, 대규모 색인 작업, 브라우저의 고메모리 탭을 종료하거나 이름을 적어 둡니다. 같은 맥에서도 이 상태가 달라지면 Bazel 종료 시점이 달라질 수 있습니다.

5. 스왑과 메모리 압력 확인
   활동 모니터에서 메모리 압력 그래프, 스왑 사용량, 압축 메모리를 기록합니다. Apple의 메모리 사용량 안내처럼 스왑 사용량 하나만으로 원인을 단정하지 말고 압력 그래프와 함께 봐야 합니다.

첫 시도는 KGEN 대상 하나로 제한합니다

처음부터 전체 테스트를 실행하면 컴파일러 빌드 실패와 테스트 실패가 섞입니다. 공식 저장소에서 안내하는 KGEN 대상에 집중해 다음과 같이 실행합니다.

./bazelw run --config=build-mojo KGEN:mojo

명령의 대상과 설정은 저장소의 현재 빌드 지침에서 실행 전에 다시 확인합니다. 저장소의 기본 가지가 바뀌면 대상 이름이나 인자가 달라질 수 있기 때문입니다.

첫 실행에서는 다음 다섯 가지를 별도 기록합니다.

• 저장소 커밋
• 시작과 종료 시각
• 메모리 압력과 피크 스왑
• Bazel의 마지막 오류 단계
• 운영 체제의 종료 메시지와 최종 종료 코드

빌드가 성공하면 이미 설치된 Mojo가 우연히 호출되지 않았는지 확인해야 합니다. 작은 소스 파일을 하나 만들고, 실행 경로와 버전 출력이 로컬 산출물을 가리키는지 확인합니다. PATH에 남아 있는 사전 빌드 도구와 작업 트리의 산출물을 섞으면 성공처럼 보이는 잘못된 검증이 발생합니다.

메모리 부족과 다른 실패를 먼저 나눕니다

Bazel 작업이 멈췄다는 사실만으로 메모리 부족이라고 결론 내리면 안 됩니다. 다음 증거 사슬을 순서대로 확인합니다.

• 시스템 메모리 압력: 활동 모니터에서 압력이 높아지고 스왑이 계속 늘어나는지 봅니다.
• Bazel 동시 실행 과다: 여러 컴파일 작업이 동시에 실행되며 사용량이 급증하는지 Bazel 로그에서 확인합니다.
• 디스크 부족: 캐시와 임시 산출물이 저장될 공간이 부족한지 확인합니다.
• 단일 작업 이상: 특정 작업 하나에서 반복적으로 멈추거나 같은 오류가 나는지 비교합니다.
• 도구 모음 누락: Metal 관련 도구가 없다는 오류가 별도로 표시되는지 봅니다.

자원 압력이 확인되면 다음 순서로 조정합니다.

1. 빌드 중인 다른 작업을 닫습니다.
2. 로컬 Bazel 동시 실행 수를 낮춥니다.
3. Bazel이 사용할 자원 선언이나 작업 관련 옵션을 현재 공식 명령 줄 참고 자료에 맞춰 조정합니다.
4. 같은 KGEN 대상만 다시 실행합니다.
5. 동일한 단계에서 다시 종료되면 원시 로그와 활동 모니터 기록을 보존합니다.

여기서 중요한 것은 스왑을 계속 늘려 버티는 방식이 아니라는 점입니다. 냉간 빌드가 여러 차례 같은 방식으로 불안정하다면, 로컬 맥에서 반복하는 비용이 원격 환경을 준비하는 비용보다 커집니다. 그 시점에는 prebuilt-mojo로 일상 작업을 유지하고, 컴파일러 본체를 꼭 빌드해야 하는 작업만 고메모리 원격 맥으로 옮기는 편이 합리적입니다.

주의: Metal 도구 모음이 없다는 오류는 메모리 부족과 다른 문제입니다. Apple Metal 개발 문서에 맞는 도구와 프로젝트 요구 사항을 확인한 뒤, 도구 모음 오류가 사라졌을 때 메모리 진단을 다시 해야 합니다.

build-mojo와 prebuilt-mojo를 같은 샘플로 비교합니다

두 경로를 서로 다른 예제로 시험하면 캐시와 경로 혼용을 발견하기 어렵습니다. 같은 최소 Mojo 파일을 사용하고, 새 셸에서 실행 경로와 Bazel 설정을 명시합니다.

• 컴파일러 본체를 수정하거나 디버거로 내부를 따라가야 하면 build-mojo
• 표준 라이브러리와 일반 예제를 빠르게 확인하면 prebuilt-mojo
• MAX 커널이나 모델을 만들면 prebuilt-mojo
• 단순히 Mojo를 설치하고 사용하는 목적이면 전체 소스 빌드를 시작하지 않음

prebuilt-mojo 경로는 다음처럼 저장소의 현재 지침에 맞춰 확인합니다.

./bazelw run --config=prebuilt-mojo KGEN:mojo

두 명령에서 모두 같은 샘플의 결과를 저장하고, 실행 파일 위치와 버전 출력을 비교합니다. 한쪽은 캐시를 사용하고 다른 쪽은 사전 설치 파일을 사용하면 결과가 섞일 수 있습니다. 저장소 밖에 설치된 실행 파일을 임시로 PATH에서 제외하는 것도 좋은 검증 방법입니다.

조건별 전환 기준과 비용 점수

다음 조건 목록으로 선택을 고정하면 팀원이 바뀌어도 판단이 흔들리지 않습니다.

• 컴파일러 내부 코드를 읽거나 수정해야 한다면 build-mojo를 선택합니다. 단, 먼저 KGEN 최소 대상으로 환경을 검증합니다.
• 표준 라이브러리만 수정하고 컴파일러 내부 변경이 없다면 prebuilt-mojo부터 선택합니다. 컴파일러 재빌드는 변경이 실제로 연결될 때만 합니다.
• MAX 대상 또는 MAX 커널과 모델을 작업한다면 prebuilt-mojo로 돌아갑니다. 로컬 build-mojo 성공 여부와 관계없이 적용되는 제한입니다.
• 메모리 압력이 낮고 같은 커밋의 반복 빌드가 안정적이면 로컬 빌드를 유지합니다.
• 시스템 종료, 스왑 급증, 장시간 무진행이 반복되면 동시 실행을 낮춘 뒤 한 번만 재검증하고, 계속 실패하면 원격 맥으로 전환합니다.
• Metal 도구 모음 오류가 남아 있으면 메모리 증설이나 원격 이전보다 도구 모음부터 수정합니다.

점수는 성능 등급이 아니라 작업 목적과 운영 비용을 비교하기 위한 내부 판단값입니다. 공식 문서가 Apple Silicon Mac의 전체 소스 빌드 메모리 하한을 제시하지 않았으므로, 이 표를 특정 메모리 용량의 보장표로 사용해서는 안 됩니다.

첫 주에 남겨야 할 빌드 기록

팀에서 장비를 바꾸거나 저장소를 갱신할 때는 다음 기록을 한 줄 단위로 남깁니다. 동일 저장소 커밋과 동일 샘플을 사용해야 비교가 가능합니다.

첫 주의 합격 기준은 최소 컴파일러 대상 성공, 같은 샘플 실행 성공, 필요한 테스트 통과, 연속 실행에서 운영 체제 종료가 다시 발생하지 않는 상태입니다. 팀이 장비를 자주 교체한다면 원격 맥 개발 환경 선택 안내와 도입 가능한 맥 대여 옵션을 함께 비교하되, 고정 메모리 구성을 먼저 가정하지 말고 필요한 빌드 로그를 기준으로 환경을 검증해야 합니다.

현재 맥에서 계속 빌드하는 방식은 장비를 따로 관리하지 않아도 된다는 장점이 있지만, 메모리 압력으로 다른 작업까지 멈출 수 있고, 스왑으로 시간이 늘어나며, 팀원이 같은 환경을 재현하기 어렵다는 단점이 있습니다. 고메모리 원격 맥은 이런 자원 충돌을 분리할 수 있지만 네트워크 지연, 원격 접속 권한, 사용 시간 비용을 관리해야 합니다. 따라서 컴파일러 본체를 반복해서 빌드하는 팀이라면 로컬에서 불안정한 작업을 억지로 지속하기보다 JexMac의 원격 맥 환경을 시험하고, 원격 접속과 운영 절차를 확인한 뒤 실제 로그로 이전 효과를 판단하는 편이 낫습니다. 일상적인 표준 라이브러리와 MAX 작업은 계속 prebuilt-mojo로 처리하면 원격 환경 사용량도 필요한 작업에 한정할 수 있습니다.