Julia 1.13은 새 연구 프로젝트라면 공식 juliaup으로 Apple Silicon Mac에 설치하고, 기존 프로젝트라면 원래 환경을 보존한 뒤 별도 환경에서 회귀 검증해야 합니다. Mac이 없으면 원격 Apple Silicon Mac에서 패키지, 결과, 그래픽, 장시간 작업까지 확인한 다음 이전 여부를 결정합니다.
이 글은 Windows 또는 Linux 장비만 가진 연구자, Julia 구버전 과제를 Julia 1.13으로 옮기려는 연구자, 연구실의 재현 환경을 관리하는 대학 기술 지원 담당자를 위한 점검 안내입니다.
마지막 갱신: 2026년 9월 19일. 버전 상태와 설치 경로는 Julia 공식 다운로드 페이지와 공식 플랫폼 안내를 기준으로 확인했습니다.
먼저 버전과 설치 경로를 고정합니다
2026년 9월 19일 기준으로 Julia 1.13.0은 2026년 9월 9일 공개된 현재 안정 버전으로 안내되고 있으며, Apple Silicon용 공식 빌드가 제공됩니다. 일반적인 연구 환경에서는 비공식 패키지 저장소의 오래된 빌드보다 공식 juliaup 경로를 먼저 검토해야 합니다. 버전 상태는 Julia 1.13 공식 배포 자료에서 다시 확인하십시오.
안정 버전은 새 프로젝트와 일반 계산에 적합합니다. 장기 지원 채널은 조직의 유지 정책이 우선이며, 구버전 논문은 호환성 검증 없이 옮기면 안 됩니다. 개발 미리보기 채널은 패키지 개발이나 특정 수정 사항 확인이 목적일 때만 사용합니다.
설치 직후에는 다음 세 가지를 기록합니다.
juliaup status
which julia
julia --version터미널에 julia가 실행된다는 사실만으로는 충분하지 않습니다. juliaup이 관리하는 경로인지, 예전에 설치한 실행 파일이 먼저 잡히는지, 실제 버전이 Julia 1.13인지 함께 남겨야 합니다. 설치 명령과 채널 동작은 Julia 설치 설명서를 기준으로 확인합니다.
아키텍처 혼합 증상을 먼저 분리합니다
Apple Silicon Mac, Julia 실행 파일, 외부 명령줄 의존성은 각각 확인해야 합니다. Mac이 Apple Silicon이라고 해서 모든 C 라이브러리, Fortran 라이브러리, 사전 빌드 아티팩트가 같은 방식으로 준비되는 것은 아닙니다.
다음 현상이 있으면 단순한 패키지 설치 실패로 보지 마십시오.
- 패키지 해석은 끝났지만 아티팩트 로딩에서 실패합니다.
- Julia 패키지는 설치되지만 외부 실행 파일을 찾지 못합니다.
- C 또는 Fortran 라이브러리 로딩 단계에서 아키텍처 오류가 납니다.
- 같은 명령이 터미널 종류에 따라 다른 Julia를 실행합니다.
which julia 결과, Julia 버전, 프로젝트 경로를 기록합니다. 이후 문제가 난 패키지의 공식 문서에서 Apple Silicon 지원 여부와 외부 의존성을 따로 확인합니다. Julia의 바이너리 아티팩트는 플랫폼별 파일을 가져올 수 있으므로, [Pkg 아티팩트 문서](https://pkgdocs.julialang.org/v1.5/artifacts/)의 동작 원리도 함께 확인해야 합니다.
Rosetta를 처음부터 설치하는 방식은 권하지 않습니다. arm64 경로가 없는 오래된 의존성이 확인될 때만 별도의 호환 환경으로 격리하십시오. 기존 arm64 환경 전체를 변환하는 해결책으로 사용하면 어떤 실행 파일이 어느 아키텍처인지 추적하기 어려워집니다.
경로 충돌은 삭제보다 기록과 격리로 처리합니다
터미널에서 Julia를 찾지 못하거나, 설치한 버전과 다른 버전이 열리는 경우에는 사용자 설정을 먼저 삭제하지 마십시오. ~/.zshrc 또는 다른 셸 설정에 예전 경로가 남아 있을 수 있고, 그래픽 터미널과 원격 셸이 서로 다른 초기화 파일을 읽을 수도 있습니다.
다음 순서로 처리합니다.
which julia와juliaup status결과를 파일에 저장합니다.julia --version으로 실제 실행 버전을 기록합니다.- 셸 설정에서 Julia 관련 경로가 중복으로 선언됐는지 확인합니다.
juliaup의 기본 채널을 원하는 안정 채널로 지정합니다.- 새 터미널을 열어 경로와 버전을 다시 비교합니다.
- 기존 프로젝트가 계속 같은 Manifest를 읽는지 확인합니다.
Project.toml, Manifest.toml, 코드와 데이터를 별도 위치에 복사합니다. 주 디렉터리를 무차별 삭제하거나 재설치하는 방식은 연구 결과를 되돌리기 어렵게 만듭니다.
패키지 오류는 네트워크 계층별로 판별합니다
연구 패키지 설치가 멈췄을 때는 전체 오류 메시지의 마지막 문장만 보지 말고 첫 번째 유효한 오류를 찾습니다. 등록소 접근 실패인지, 패키지 서버 연결인지, 저장소 내려받기인지, 아티팩트 취득인지, 로컬 컴파일인지에 따라 조치가 달라집니다.
Julia의 패키지 환경은 프로젝트 파일과 의존성 해석 결과를 함께 관리합니다. 기본적인 환경 생성과 활성화는 Pkg 환경 관리 문서를 따르십시오.
프로젝트 폴더에서 다음처럼 최소 환경을 만듭니다.
using Pkg
Pkg.activate(".")
Pkg.instantiate()그 뒤에는 복잡한 연구 패키지 전체를 한 번에 설치하지 말고, 작은 패키지와 대표 프로젝트를 나눠 시험합니다. 학교 네트워크에서 HTTPS, 대리 서버, 인증서 정책이 막히면 보안 정책을 우회하지 말고 네트워크 관리자에게 Julia 공식 도메인과 필요한 접속을 확인받아야 합니다. Pkg가 어떤 통신 단계를 사용하는지는 Pkg 프로토콜 문서에서 확인할 수 있습니다.
프로젝트 파일로 기존 연구 환경을 보존합니다
전역 환경은 잠깐 기능을 확인할 때만 사용하십시오. 논문, 수업 과제, 연구실 공동 프로젝트는 각각 독립된 Project.toml과 Manifest.toml을 가져야 합니다. Project.toml은 직접 의존성을 설명하고, Manifest.toml은 실제로 해석된 의존성 상태를 고정하는 역할을 합니다. 자세한 파일 규칙은 TOML 파일 공식 설명을 참조하십시오.
기존 과제를 Julia 1.13으로 옮길 때는 다음 판단을 적용합니다.
- 기존 결과가 중요하고 구버전 환경이 재현되면 원래 환경을 유지합니다.
- 새 환경에서 패키지 설치만 성공하면 되는 경우 별도 Julia 1.13 프로젝트를 만듭니다.
- 핵심 의존성이 바뀌면 별도 Manifest로 결과를 다시 계산합니다.
- 출력이 다르면 패키지를 계속 올리기보다 버전, 난수 시드, 입력 데이터, 파일 형식을 비교합니다.
실제 연구 작업으로 통과 여부를 결정합니다
설치가 끝났다고 판단하기 전에 다음 항목을 차례로 확인합니다.
- 프로젝트를 활성화하고
Pkg.instantiate()가 완료되는지 확인합니다. - 대표 패키지를 불러오고 처음 실행할 때의 오류를 기록합니다.
- 공개 데이터 또는 비식별 데이터를 사용해 대표 계산을 실행합니다.
- 결과 파일을 저장하고 다시 읽어 핵심 출력이 일치하는지 확인합니다.
- 그래픽 창이나 노트북 연결이 필요한 경우 실제 출력까지 확인합니다.
- 긴 작업을 실행한 뒤 원격 연결이 끊겼을 때 작업 상태와 결과 파일이 남는지 확인합니다.
- Linux에서 얻은 기준 결과와 숫자, 난수 시드, 처리 행 수, 의존성 상태를 비교합니다.
다음 조건이면 계속 사용합니다.
- Julia 경로와 아키텍처가 예상과 일치합니다.
- 패키지와 아티팩트가 오류 없이 준비됩니다.
- 대표 결과와 그래픽 출력이 기준 결과와 설명 가능한 범위에서 일치합니다.
- 연결이 끊겨도 장시간 작업 결과를 회수할 수 있습니다.
설치 선택과 원격 검증을 비교합니다
| 선택지 | 적합한 경우 | 장점 | 중단 또는 주의 조건 |
|---|---|---|---|
공식 juliaup | 새 Julia 1.13 프로젝트 | 채널과 버전 분리가 쉽습니다 | 조직의 고정 배포 정책과 충돌할 수 있습니다 |
| 직접 설치 파일 | 네트워크나 배포 절차가 제한된 연구실 | 설치 파일을 직접 관리할 수 있습니다 | 버전 전환과 중복 경로를 따로 관리해야 합니다 |
| 기존 환경 유지 | 논문 결과와 구버전 패키지가 중요할 때 | 재현 기준을 보존합니다 | 새 기능 검증은 별도 환경이 필요합니다 |
| 원격 Apple Silicon Mac | Mac이 없고 macOS 검증이 필요할 때 | 구매 전 실제 프로젝트를 시험할 수 있습니다 | 네트워크, 그래픽, 장시간 작업을 별도 검증해야 합니다 |
결정 조건
- 새 프로젝트이고 구버전 호환성이 중요하지 않다면 공식
juliaup과 Julia 1.13을 선택합니다. - 기존 논문 프로젝트이고 기준 결과가 보존되어야 한다면 구환경을 유지하고 Julia 1.13을 격리해 비교합니다.
- arm64 아티팩트가 준비되고 외부 라이브러리도 같은 경로라면 네이티브 환경을 계속 사용합니다.
- 오래된 의존성에만 x86_64 요구가 확인되면 그 의존성만 별도 호환 환경으로 분리합니다.
- Mac이 없고 대표 과제의 결과와 그래픽을 확인해야 한다면 단기 원격 환경에서 먼저 검증합니다.
- 결과 차이를 설명하지 못하거나 네트워크 정책이 해결되지 않으면 마이그레이션을 중단하고 원래 환경으로 돌아갑니다.
Windows 또는 Linux 중심의 현재 환경은 익숙하고 기존 도구가 많다는 장점이 있지만, macOS 전용 검증을 할 때마다 장비를 빌리거나 연구실 일정을 기다려야 하고 Apple Silicon의 아티팩트와 그래픽 동작을 직접 확인하기 어렵다는 단점이 있습니다. 반대로 MACGPU의 원격 Apple Silicon Mac은 단기 회귀 시험에 적합하지만, 장기적으로 무거운 작업을 계속 수행하거나 물리 장치와 직접 연결해야 하는 경우에는 자체 장비나 별도 연구실 인프라가 더 적합할 수 있습니다. 이미 프로젝트 파일과 검증 데이터를 준비했다면 먼저 원격 환경에서 Julia 1.13 회귀를 끝내고, 그 결과를 바탕으로 계속 임대할지, Mac을 마련할지, Linux와 macOS를 병행할지 결정하는 편이 비용과 재현성 모두를 통제하기 쉽습니다.