2026 Mojo 소스 컴파일에 필요한 Mac 통합 메모리는 얼마인가요?

빌드 명령은 시작되지만 중간에 멈추거나 Mac이 심하게 느려집니다.
가장 빠른 해법은 모델 로딩 성공과 Mojo 소스 컴파일 메모리를 분리해 판단하는 것입니다. 16 GB와 24 GB는 제한된 대상이나 시간차 실행부터 확인하고, 최초 전체 빌드는 32 GB에서 검증하며, Agent와 Bazel 테스트를 동시에 유지하려면 64 GB부터 시험하는 편이 안전합니다.

이 글은 처음 Mojo 컴파일러를 소스에서 빌드하려는 오픈 소스 기여자를 위한 안내입니다. 로컬 Agent와 모델 서버, 개발 도구를 함께 실행하는 개발자와 단기 클라우드 맥으로 팀의 장비를 검증하려는 기술 책임자에게도 맞습니다.

마지막 업데이트: 2026년 8월 28일. Mojo의 공개 범위와 빌드 절차는 공식 공개 안내와 공식 저장소를 기준으로 확인했습니다.

먼저 나눠야 할 것: 도구 사용과 전체 소스 빌드

Mojo를 설치해 예제만 실행하는 일, 표준 라이브러리를 수정하는 일, 컴파일러 자체를 소스에서 만드는 일은 서로 다른 작업입니다. 여기에 전체 테스트와 Bazel 기반 검증을 추가하면 메모리 곡선도 달라집니다. 따라서 “Mojo를 실행할 수 있는 Mac”과 “Mojo를 안정적으로 빌드하는 Mac”을 같은 기준으로 부르면 안 됩니다.

공식 저장소의 운영 체제 작업 문서는 소스 저장소에서 작업하는 절차와 빌드 명령을 별도로 설명합니다. 공식 작업 문서의 빌드 절차를 먼저 확인한 뒤 다음 항목을 기록해야 합니다.

• 대상 커밋
• 빌드 종류와 추가 선택 사항
• Bazel 명령과 동시 작업 수
• 의존성 다운로드 여부
• 캐시 삭제 여부
• 테스트 범위와 Agent의 동시 실행 여부

이 기록이 없으면 32 GB에서 성공했다는 결과도 다른 커밋이나 다른 캐시 상태에 그대로 적용할 수 없습니다.

첫 번째 기준: 실행 시작보다 완료 상태를 보십시오

최초 전체 빌드는 용량 판단의 기준점입니다. 명령이 실행되었다는 사실만으로 통과라고 기록하지 마십시오. 다음 네 가지를 함께 남겨야 합니다.

1. 빌드가 마지막 단계까지 정상 종료됐는지 확인합니다.
2. 활동 모니터에서 메모리 압력과 교환 사용량을 기록합니다.
3. 빌드 중 편집기, 터미널, 모델 서버가 응답을 유지하는지 확인합니다.
4. 같은 조건으로 다시 실행해 결과가 반복되는지 확인합니다.

macOS의 메모리 압력은 단순 사용량과 다른 지표입니다. Apple의 메모리 압력 안내처럼 압력 그래프와 교환 사용량을 함께 봐야 합니다. 저장 공간이 남아 있어도 그것은 교환 영역을 받아 주는 장소일 뿐입니다. 통합 메모리를 대신하지 않습니다.

주의: 순간 피크가 낮았다는 기록보다 빌드 도중 지속적인 교환이 발생했는지, 작업 시간이 비정상적으로 늘었는지, 프로세스가 종료됐는지가 더 중요한 합격 조건입니다.

16 GB Mac에서도 Mojo를 소스에서 컴파일할 수 있습니까?
제한된 빌드 대상이나 캐시가 준비된 증분 빌드는 시도할 수 있습니다. 그러나 최초 전체 빌드와 전체 테스트를 같은 조건으로 완료했다고 확인하지 못했다면 “충분하다”고 결론 내리면 안 됩니다. 16 GB는 학습용 검증이나 순차 실행에 가깝고, 동시에 여러 개발 도구를 유지하는 기준으로는 여유가 작습니다.

두 번째 기준: Bazel 병렬성과 캐시를 따로 비교하십시오

Bazel은 병렬 작업 수, 의존성 다운로드, 캐시 적중 여부에 따라 자원 사용량이 달라집니다. 기본 설정으로 빠르게 끝난 증분 빌드를 장기간 필요한 용량의 증거로 쓰면 안 됩니다. Bazel 명령줄 선택 사항을 확인하고, 기본 병렬 실행과 제한된 병렬 실행을 각각 기록하십시오.

비교 방법은 단순해야 합니다.

• 같은 커밋과 같은 빌드 명령을 사용합니다.
• 첫 실행에서는 캐시를 비운 상태를 유지합니다.
• 다음 실행에서는 캐시 적중 상태를 별도로 기록합니다.
• 한 번에 병렬성 하나만 바꿉니다.
• 성공 여부, 총 시간, 메모리 압력, 교환 사용량을 함께 남깁니다.

32 GB와 64 GB Mac 중 무엇으로 시작해야 합니까?
Agent 없이 최초 전체 빌드와 필요한 테스트만 수행한다면 32 GB를 출발점으로 삼아 실측할 수 있습니다. 반대로 Bazel 테스트, 코드 색인, 모델 서버와 터미널을 계속 유지해야 한다면 64 GB에서 먼저 검증하는 편이 낫습니다. 64 GB가 항상 필요한 것은 아니지만, 동시 실행의 실패 비용을 줄이는 시작점이 됩니다.

세 번째 기준: 로컬 Agent의 빈 상태와 작업 상태를 분리하십시오

로컬 Agent는 유휴 상태에서도 모델 서버와 색인 프로세스를 유지할 수 있습니다. 긴 문맥을 처리하거나 도구를 호출하면 추가 버퍼와 작업 결과가 생깁니다. MLX는 Apple 칩의 통합 메모리를 모델과 운영 체제가 함께 사용하는 구조로 설명합니다. MLX 통합 메모리 문서를 참고하되, 모델이 로드된다는 사실을 Mojo 빌드 여유 공간으로 해석해서는 안 됩니다.

27B급 모델의 메모리 요구를 다룬 제삼자 자료도 양자화 방식과 문맥 길이, 실행 도구에 따라 결과가 달라집니다. Qwen 3 27B의 MLX 테스트 조건은 Agent 동시 실행의 배경 자료로만 사용해야 하며, Mojo의 공식 메모리 문턱값으로 사용할 수 없습니다.

다음처럼 세 상태를 나눠 시험하십시오.

• 모델 서버만 켠 유휴 상태
• 긴 문맥과 도구 호출을 포함한 Agent 작업 상태
• Agent 작업을 유지한 채 Mojo 전체 빌드와 Bazel 테스트를 실행한 상태

첫 번째와 두 번째가 통과해도 세 번째가 실패하면 동시 실행 용량은 부족한 것입니다. Agent를 종료한 뒤 빌드하는 것은 “교대 실행” 결과이지 “동시 실행” 결과가 아닙니다.

용량 선택표: 숫자보다 작업 완료 조건이 우선입니다

아래 표는 공식적인 최소 사양이 아닙니다. 공식적으로 모든 Mojo 빌드 대상에 공통으로 적용되는 메모리 문턱값은 공개되지 않았습니다. 각 용량은 어떤 검증부터 시작할지 정하는 실무용 구분입니다. Mac mini의 메모리 선택지는 Apple 공식 사양에서 해당 판매 시점에 다시 확인해야 합니다.

네 번째 기준: 결과를 조건문으로 바꾸십시오

다음 조건을 순서대로 적용하면 구매와 임대를 구분하기 쉽습니다.

• 최초 전체 빌드가 끝까지 성공하고 교환 압력이 낮으며 반복 결과가 안정적이면, 현재 용량으로 개발을 이어갑니다.
• 빌드는 성공하지만 Agent를 켜면 시스템 응답이 무너지면, 작업을 교대하거나 더 큰 Mac을 단기 임대해 비교합니다.
• 기본 병렬성에서 실패하고 제한된 병렬성에서만 성공하면, 속도 손실과 장기 사용 시간을 비용에 포함합니다.
• 캐시가 있을 때만 성공하면, 캐시를 비운 재검증을 통과하기 전에는 팀 표준으로 채택하지 않습니다.
• 32 GB에서 전체 빌드가 안정적이지만 Agent와 테스트를 함께 유지해야 하면, 64 GB를 먼저 대조한 뒤 실제 피크와 사용 기간으로 구매 여부를 결정합니다.
• 장기간 같은 무거운 부하를 매일 실행하거나 물리 장치 연결이 필요하면, 단기 임대보다 자체 장비가 적합할 수 있습니다.

다섯 번째 단계: 임대 시험에서 남겨야 할 기록

단기 맥 임대는 “명령이 실행되는가”를 보는 시간이 아닙니다. 팀의 재현 가능한 작업을 그대로 돌려 실패 조건을 찾는 시험이어야 합니다. MacHTML의 맥 관리 콘솔을 사용한다면 접속 정보와 실행 시각을 기록하고, 별도로 다음 로그를 보관하십시오.

1. Mac 칩과 통합 메모리 용량을 기록합니다.
2. Mojo 커밋과 공식 빌드 명령을 고정합니다.
3. Bazel 병렬성, 캐시 상태, 의존성 다운로드 여부를 적습니다.
4. Agent 모델, 문맥 조건, 도구 호출 시나리오를 고정합니다.
5. 메모리 압력, 교환 사용량, 종료 여부와 총 소요 시간을 저장합니다.
6. 같은 시험을 반복해 성공과 실패가 재현되는지 확인합니다.

접속이나 사용 중 문제가 생기면 MacHTML 도움말에서 환경별 안내를 확인할 수 있습니다. 인접한 두 용량을 같은 기간에 비교해야 “큰 용량이 빠르다”가 아니라 “어느 조건에서 실패하지 않는가”를 판단할 수 있습니다.

현재 Mac으로 계속 진행하는 선택은 비용이 낮지만, 16 GB나 24 GB에서 교환이 반복되면 빌드 시간과 작업 중단 비용이 누적됩니다. 반대로 큰 Mac을 바로 구매하면 실제 Agent 동시 부하가 작을 때 자원이 남을 수 있고, 팀의 커밋과 테스트 범위가 바뀌면 초기 선택을 다시 검증해야 합니다. 그래서 아직 기준 커밋이 고정되지 않았거나 단기 기여 작업이라면 MacHTML의 맥 임대 요금과 시험 환경을 확인해 자신의 빌드와 Agent 재생 스크립트를 먼저 비교하는 편이 합리적입니다. 장기 고정 부하와 물리 장치 요구가 없다면, 이 방식으로 32 GB와 64 GB의 실제 완료 상태를 확인한 뒤 구매 결정을 늦출 수 있습니다.