Julia가 또 한 번 버전을 올렸어요
Julia 1.13이 정식으로 나왔어요. Julia는 파이썬처럼 쓰기 편하면서 C처럼 빠른 걸 목표로 만들어진 과학 계산용 언어인데요, 수치 해석이나 시뮬레이션, 최적화 문제를 다루는 분들 사이에서는 꽤 자리를 잡았어요. 한국에서는 아직 파이썬에 비해 사용자가 많지 않지만, 최근 몇 년의 릴리스가 하나같이 '진입 장벽 허물기'에 집중하고 있어서 지금이 다시 한 번 살펴볼 만한 시점이에요.
이 글에서는 Julia가 왜 이런 방향으로 가고 있는지, 1.13이 그 흐름에서 어떤 위치인지 풀어볼게요.
Julia의 고질병 두 가지
Julia를 써본 분이라면 두 가지 불만을 아실 거예요. 첫째는 '첫 실행이 느리다'는 거예요. 이게 뭐냐면, Julia는 함수를 처음 호출할 때 인자 타입에 맞춰 그 자리에서 기계어로 컴파일해요(JIT 컴파일). 그래서 실행 자체는 빠른데, 처음 한 번은 컴파일 때문에 몇 초씩 기다려야 했죠. 플롯 라이브러리를 불러와서 그래프 하나 그리는데 수십 초 걸리던 시절도 있었어요. 커뮤니티에서는 이걸 'time to first plot' 문제라고 불렀어요.
둘째는 '배포가 어렵다'는 거예요. 파이썬은 그래도 pip으로 설치하면 되고, Go나 Rust는 바이너리 하나로 끝나는데, Julia는 실행 환경 전체를 끌고 다녀야 했어요. 컴파일러와 런타임이 같이 들어가니 몇백 MB짜리 배포물이 되는 거죠. 그래서 '연구실에서는 쓰는데 서비스에는 못 올린다'는 평가가 오래 따라다녔어요.
지난 몇 년의 해법, 그리고 1.13
첫 번째 문제는 1.9와 1.10에서 크게 나아졌어요. 패키지를 미리 컴파일해서 네이티브 코드 형태로 저장해두는 패키지 이미지(pkgimage) 기능이 들어오면서, 라이브러리를 처음 불러오는 시간이 몇 배씩 줄었거든요. 1.11에서는 배열의 밑바닥 구조를 Memory 타입으로 새로 짜서 성능과 컴파일러 최적화 여지를 넓혔고요.
두 번째 문제는 1.12부터 본격적으로 손을 댔어요. 실험적 기능으로 들어온 --trim 옵션이 핵심인데요. 이게 뭐냐면, 프로그램이 실제로 사용하는 코드만 남기고 나머지를 전부 잘라내서 작은 실행 파일을 만드는 기능이에요. 기존 sysimage 방식은 수백 MB가 기본이었는데, trim을 거치면 몇 MB 단위의 바이너리를 만드는 게 가능해졌어요. 다만 동적 디스패치(실행 중에 타입을 보고 호출할 함수를 고르는 것)가 남아 있는 코드는 trim이 못 잘라내기 때문에, 타입이 컴파일 시점에 정해지도록 코드를 써야 한다는 조건이 붙어요. 1.12에서는 또 REPL에서 struct를 재정의할 수 있게 되는 등 개발 경험 개선도 있었죠.
1.13은 이 흐름을 이어서 다듬는 릴리스로 보시면 돼요. 정적 컴파일 쪽에서는 trim이 다룰 수 있는 코드 범위를 넓히고, 잘라낼 수 없는 부분이 있을 때 왜 안 되는지를 더 친절하게 알려주는 방향으로 진화하고 있어요. 그리고 이번 사이클에서 특히 눈여겨볼 건 컴파일러 자체를 Julia로 옮겨오는 작업이에요. 파서는 이미 1.10에서 JuliaSyntax라는 Julia 구현으로 바뀌었고, 그 다음 단계인 lowering(문법 트리를 컴파일러가 다루기 쉬운 형태로 바꾸는 단계)도 기존 Scheme 계열 구현에서 Julia 구현으로 넘어가는 작업이 진행되어 왔어요. 이게 완성되면 매크로 에러 메시지가 좋아지고, 언어 도구를 만드는 사람들이 컴파일러 내부에 훨씬 쉽게 접근할 수 있게 돼요. 이 외에도 멀티스레딩과 GC 개선, 표준 라이브러리를 언어 본체와 따로 업그레이드할 수 있게 떼어내는 작업 등 세부 항목이 많으니, 구체적인 변경 목록은 공식 하이라이트와 NEWS 파일을 한 번 훑어보시길 권해요.
업계 맥락: 다들 같은 벽을 넘고 있다
재미있는 건 다른 언어들도 같은 문제를 풀고 있다는 거예요. 파이썬은 Mojo 같은 별도 언어나 Numba 같은 JIT 라이브러리로 성능 문제를 우회해 왔고, 3.13부터는 실험적 JIT과 GIL 제거를 직접 시도하고 있죠. 반대로 Julia는 이미 성능은 있으니 '작고 빠르게 시작하는 배포물'을 만드는 쪽으로 가는 중이에요. 결국 두 진영이 서로의 장점을 향해 다가가고 있는 셈이에요.
Rust나 Go와 비교하면 Julia의 정적 컴파일은 아직 조건이 많아요. 하지만 과학 계산 코드를 굳이 Rust로 다시 짜지 않고도 CLI 도구나 마이크로서비스로 배포할 수 있는 길이 열린다는 건 큰 변화예요.
한국 개발자에게 주는 시사점
수치 계산, 최적화, 시뮬레이션 쪽 일을 하시는 분이라면 지금 Julia는 몇 년 전과 다른 언어라고 봐도 돼요. 예전에 '첫 실행 느려서 접었다'면 다시 한 번 열어볼 만해요. 특히 DifferentialEquations.jl이나 JuMP 같은 생태계는 파이썬에 대응물이 없거나 훨씬 느린 경우가 많아요.
서비스 개발자라면 아직은 관망해도 돼요. trim은 여전히 실험적이고, 웹 프레임워크 생태계는 파이썬이나 Go에 한참 못 미쳐요. 다만 '연구팀이 만든 Julia 모델을 서비스에 붙여야 한다'는 상황이 온다면, 이제는 별도 바이너리로 뽑는 선택지가 있다는 걸 기억해 두세요.
마무리
한 줄 정리: Julia 1.13은 새 문법보다 '작게 컴파일하고, 컴파일러를 Julia 자신으로 짓는' 장기 프로젝트의 진행 보고서에 가까운 릴리스예요.
여러분은 어떠세요? 파이썬 대신 Julia를 실무에 도입해 본 경험이 있으신가요? 아니면 여전히 '파이썬 + 네이티브 확장'이 현실적인 답이라고 보시나요?
🔗 출처: Hacker News