Julia는 동적 언어를 빠르게 만들어 두 언어 문제를 해결했다

과학 컴퓨팅은 두 언어 워크플로에 정착해 있었다. 연구자들은 Python, MATLAB, R 같은 동적 언어로 프로토타이핑하고 분석한 뒤, 느린 부분을 C나 Fortran으로 다시 작성했다. 2020년 Ars Technica의 특집 기사와 그에 대한 Hacker News 토론은 그 이음새의 비용을 드러냈다. 스크립팅 계층은 고성능을 표현할 수 없고, 빠른 계층은 작성하기 고통스럽고 유지하기 어렵다.

Julia의 승부수는 그 이음새를 완전히 없애는 것이었다. 그 컴파일러는 타입 추론과 LLVM 기반 JIT를 사용해 각 함수를 실제로 호출되는 구체적 인자 타입에 맞춰 컴파일하므로, 동적이고 수학 같은 언어가 잘 작성된 C에 가까운 속도로 실행될 수 있다. 다중 디스패치 — 단일 수신자가 아니라 모든 인자 타입으로 메서드를 선택하는 것 — 는 패키지들이 서로의 제네릭 함수를 확장할 수 있게 하며, 이것이 독립적인 라이브러리들이 각자 자신의 C 코어를 감싸는 대신 서로 조합되는 방식이다.

2020년까지 이 설계는 단지 벤치마크가 아니라 실제 운영 결과를 보여주고 있었다. RelationalAI는 자사의 클라우드 지식 그래프 데이터베이스가 100% Julia로 작성되었다고 밝혔고, Pumas 모델링 플랫폼은 제약 회사들에 공급되어 FDA 제출에 사용되고 있었으며, 댓글 작성자들은 미분 방정식에서 수학적 최적화에 이르기까지 Julia 라이브러리가 최고 수준이 된 생태계 전체를 지적했다. 버전 1.5가 당시 최신이었고, 핵심 개발자들은 1.0 이후 실제 호환성 깨짐이 없었다고 주장했다.

비판자들도 할 말이 있었다. 느린 첫 플롯과 시작 지연, 미성숙한 도구, Python보다 적은 실전 검증 라이브러리 등이다. 옹호자들은 Revise.jl을 통한 반복 개발과 하나의 새로운 메서드로 핫스팟 하나를 패치할 수 있는 능력 덕분에 같은 코드가 탐색과 운영 모두에 쓰인다고 답했다. 그것이 바로 이 설계의 요점이었다.

동적 언어 자체가 네이티브 속도로 컴파일되게 만들었다

타입 추론과 JIT 특수화는 프로그래머가 핫 경로를 위해 방언을 바꾸지 않고도 제네릭하고 표현력 있는 코드를 빠르게 만든다.

다중 디스패치는 패키지들이 다른 패키지의 함수에 메서드를 추가할 수 있게 하므로, ODE 솔버와 최적화 같은 생태계가 서로의 C 코어를 복제하는 대신 조합된다.

과학자들은 문제를 성능 패러다임에 맞추기 위해 재구성하는 대신 문제에 대한 정신 모델을 유지하며, 이는 재작성 버그의 한 부류 전체를 줄인다.

하나의 코드베이스가 탐색과 운영 모두에 쓰이므로, 프로토타입이 실제로 실행되는 시스템과 어긋날 수 없다.

재작성 단계를 없애려면 두 언어 사이에 더 나은 다리를 놓지 말고, 표현 계층이 곧 운영 계층인 하나의 언어를 만들어라.

Ars Technica 특집 기사는 2020년 10월에 게재되었고 그 Hacker News 스레드는 284점과 212개 댓글을 모았으며, Julia 개발자들도 논쟁에 참여했다. 설계 근거는 이미 저자들이 2018년 논문 "Julia: Dynamism and Performance Reconciled by Design"에서 정리했으며, 2020년 스레드는 연구 프로토타입만이 아니라 RelationalAI와 제약 모델링에서의 배포를 보여주었다. 스레드가 지목한 트레이드오프 — 시작 지연, 도구 성숙도, 라이브러리 범위 — 는 생태계의 상시 과제로 남았다.