- Published on
모던 Fortran & 과학 컴퓨팅 2026 완벽 가이드 - Fortran 2023 · LFortran · gfortran · NumPy · SciPy · JAX · Julia · APL · J · K 심층 분석
- Authors

- Name
- Youngju Kim
- @fjvbn20031
프롤로그 — Fortran은 죽었다, Fortran 만세
2026년에도 Fortran을 다룬다고 하면 두 가지 반응이 나온다. 첫째, "왜?" 둘째, "아직 살아 있나?" 둘 다 틀린 질문이다. 올바른 질문은 이것이다. "왜 Fortran은 1957년부터 70년이 지나도록 사라지지 않는가?"
답은 단순하다. 과학 컴퓨팅의 핵심은 배열 연산이고, 배열 연산을 Fortran보다 잘하는 언어는 아직 없다. 컴파일러는 70년치 최적화 기법을 쌓았고, BLAS·LAPACK·ScaLAPACK·PETSc는 Fortran으로 짜였으며, ECMWF의 IFS와 NCAR의 CESM, 일본 RIKEN의 NICAM, CMIP6의 모든 기후 모델은 여전히 Fortran으로 돈다. 슈퍼컴퓨터 Top500의 절반은 Fortran 컴파일을 우선 지원한다.
하지만 2026년 과학 컴퓨팅 풍경은 Fortran 단독이 아니다. Python의 NumPy/SciPy/Pandas/Polars가 데이터 분석 표준이 됐고, Julia 1.11은 동적 언어로서 Fortran에 근접한 성능을 낸다. JAX는 자동미분과 XLA로 ML과 과학 컴퓨팅의 경계를 흐리고, Mojo는 Python 문법으로 SIMD/GPU를 노린다. APL 가족 — J, K, BQN, Uiua — 은 배열 사고의 극단을 보여준다.
이 글은 그 지형 전체를 정리한다. Fortran 2023 표준의 새로움, 컴파일러 8종(gfortran/LFortran/Flang/NVIDIA HPC/ifx/AOCC/XLF/Cray), HPC 병렬화(OpenMP/MPI/CAF/DO CONCURRENT), 기후·공학 모델 코드베이스, Python·Julia·R·MATLAB 생태계, APL 가족, GPU와 양자, 슈퍼컴퓨터(Fugaku/Nurion/Frontier), 데이터 포맷(HDF5/NetCDF/FITS)까지 — 한 편이 끝나면 2026년 과학 컴퓨팅 지도를 손에 든다.
1장 · Fortran은 왜 죽지 않는가 — 70년치 관성의 정체
먼저 가장 자주 들리는 오해를 정리하자.
"Fortran은 노인용 언어다." 절반은 맞고 절반은 틀리다. Fortran 코드를 쓰는 사람의 평균 연령은 높다. 하지만 코드 자체는 늙지 않았다. 2023년 12월 ISO/IEC 1539:2023(Fortran 2023)이 발표됐고, 2018·2008·2003·95 표준이 차례로 OOP·코어레이·서브모듈·동시 실행을 들여왔다. 2026년 Fortran은 1990년 Fortran과 다른 언어다.
"Python이 다 대체했다." Python은 언어 레벨에선 그렇다. 하지만 Python의 NumPy/SciPy 내부는 C와 Fortran(LAPACK)으로 짜여 있다. 그러니까 "Python이 Fortran을 죽였다"가 아니라 "Python이 Fortran을 프론트엔드 없이 쓰는 법을 가르쳐줬다"가 정확하다.
"새 프로젝트는 다 Julia/JAX로 시작한다." 신생 과학 ML 프로젝트는 그렇다. 하지만 NCAR, ECMWF, NASA, JAXA, KMA, NOAA가 운영하는 프로덕션 기후 모델은 100만 줄 단위 Fortran이다. 이걸 새 언어로 다시 쓸 자원은 누구에게도 없다.
Fortran이 사라지지 않는 진짜 이유는 세 가지다.
- 배열 어휘.
A(:,2:N) = B(:,1:N-1) + C(:,1:N-1)한 줄이 명시적 루프 + 컴파일러 자동 벡터화로 풀린다. NumPy가 흉내내는 그 어휘의 원전이다. - 수치 정확성과 ABI 안정성. Fortran 표준은 IEEE 754 부동소수점, 컴파일러 간 호출 규약, 모듈 인터페이스를 못 박았다. 2003년 Fortran 코드가 2026년 컴파일러에서 그대로 돈다.
- HPC 라이브러리 자산. BLAS(1979), LAPACK(1992), ScaLAPACK, FFTW, PETSc, Trilinos — 수십만 함수가 Fortran 호출 규약을 전제로 작성됐다. 이걸 버리는 비용이 천문학적이다.
그러니 Fortran을 배우는 사람보다 Fortran 호출법을 배우는 사람이 훨씬 많다. NumPy 사용자는 LAPACK을 호출하는 셈이고, JAX는 LAPACK을 BLAS로 거쳐 XLA가 다시 컴파일한다. Fortran은 직접 쓰는 언어에서 기반암으로 옮겨갔다.
2장 · Fortran 표준 진화 — 77, 90, 95, 2003, 2008, 2018, 2023
표준의 흐름을 한 번에 보자.
1957 FORTRAN I IBM 704, John Backus, 컴파일러의 시초
1966 FORTRAN 66 첫 ANSI 표준
1978 FORTRAN 77 구조화 IF/DO, CHARACTER 타입
1991 Fortran 90 자유 형식, 배열 표기, 모듈, 동적 할당
1997 Fortran 95 FORALL, WHERE, PURE
2004 Fortran 2003 OOP, C 상호운용, 절차 포인터
2010 Fortran 2008 CoArrays, submodule, DO CONCURRENT, BLOCK
2018 Fortran 2018 팀, 이벤트, 추가 CAF 기능
2023 Fortran 2023 CONDITIONAL expr, $token, 추가 배열 연산
핵심 분기점은 1991년 Fortran 90이다. FORTRAN 77까지가 "옛 Fortran"이고, Fortran 90 이후가 "모던 Fortran"이다. 자유 형식 소스, 모듈, 배열 슬라이싱, 동적 할당이 들어오면서 C++나 Python 못지않은 추상화가 가능해졌다.
Fortran 2003은 OOP를 들였다. type, extends :: shape 클래스 상속, 추상 인터페이스, 다형성, 한정 절차(type-bound procedure)가 정식 표준이 됐다. ISO_C_BINDING이 들어와 C 라이브러리 호출이 표준화됐다.
Fortran 2008은 병렬을 들였다. CoArrays(real :: x[*])로 다중 노드 데이터 공유, DO CONCURRENT로 안전 병렬 루프, submodule로 컴파일 단위 분리가 가능해졌다.
Fortran 2023의 새 기능은 작지만 상징적이다. 조건 식 merge보다 직관적인 if (cond) then val1 else val2, $token 토큰, 향상된 배열 연산. 모던 Fortran은 더는 90년대 언어가 아니다.
3장 · Fortran 컴파일러 8종 — 2026년 라인업
Fortran 컴파일러는 다양하지만, 2026년에 실제 쓰이는 건 8종이다.
| 컴파일러 | 라이선스 | 강점 | 약점 |
|---|---|---|---|
| gfortran (GCC 14) | GPL | 가장 널리 쓰임, 무료 | 최신 표준 일부 지연 |
| LFortran 0.50 | MIT | 모듈식, 인터랙티브 REPL | 아직 베타, F90 일부만 |
| Flang (LLVM) | Apache 2 | LLVM 백엔드, 활발 개발 | 옛 Flang 폐기 |
| NVIDIA HPC SDK | 무료 사용 | GPU(CUDA Fortran), OpenACC | GPU 외엔 보통 |
| Intel ifx | 무료 | LLVM 기반, 인텔 CPU 최적화 | 옛 ifort 폐기 |
| AMD AOCC | 무료 | AMD CPU 최적화 | 사용 사례 적음 |
| IBM XLF | 상용 | POWER/Z 최적화 | 상용, 폐쇄 생태계 |
| Cray Fortran | 상용 | Top500 슈퍼컴퓨터 | Cray 시스템 한정 |
gfortran은 GCC의 일부로 14.x가 2025년 5월 릴리스됐다. Fortran 2008 거의 전부와 Fortran 2018 상당 부분, Fortran 2023의 일부를 지원한다. 학습·연구 환경에선 사실상 기본값이다.
LFortran 0.50(2025년)은 가장 흥미로운 신참이다. 2022년 Ondřej Čertík이 시작한 MIT 라이선스 컴파일러로, 인터랙티브 모드가 있다. lfortran 명령어로 REPL을 띄우고 한 줄씩 Fortran을 실행할 수 있다 — Python 같은 경험을 Fortran에서. 백엔드는 LLVM, C, x86, WASM 다중 지원. ASR(Abstract Semantic Representation) 중간 표현이 깔끔해 다른 도구의 기반이 되기에 좋다.
**Flang (LLVM)**은 LLVM 프로젝트의 Fortran 프론트엔드다. 이전 PGI 기반 "Classic Flang"은 2023년에 폐기됐고, 현재는 "F18"로 시작한 새 Flang이 LLVM 18+ 본류에 들어가 있다. 2025년부터 본격 운영 단계로 쓰인다.
NVIDIA HPC 컴파일러는 PGI를 인수해 만든 것으로, CUDA Fortran과 OpenACC의 사실상 표준 구현이다. GPU에 직접 코드를 띄우려면 사실상 이것을 쓴다. nvfortran 명령어로 호출한다.
Intel ifx는 옛 ifort의 후계로, LLVM 기반이다. 2024년부터 ifort는 비사용 권고로 전환됐고, ifx가 표준이 됐다. 인텔 CPU의 AVX-512 같은 SIMD 명령에서 최고 성능을 낸다. oneAPI 패키지에 포함돼 무료다.
AMD AOCC는 LLVM Flang을 베이스로 AMD Zen 아키텍처에 최적화한 빌드다. EPYC 서버에서 gfortran보다 5~15% 빠른 경우가 흔하다.
IBM XLF는 POWER 시스템과 z/OS의 표준 Fortran 컴파일러로, 상용 라이선스다. 금융·기후 모델 일부가 여기 묶여 있다.
**Cray Fortran(CCE)**은 HPE Cray EX 시스템 — Frontier, Aurora, El Capitan 같은 엑사스케일 슈퍼컴퓨터 — 의 최적 컴파일러다. 이거 없이는 Top500 1위 머신에서 최대 성능을 못 낸다.
4장 · LFortran 깊게 보기 — Fortran의 IPython 모먼트
LFortran은 2026년 시점에서 가장 흥미로운 Fortran 프로젝트다. 왜?
첫째, 인터랙티브 REPL. 70년간 Fortran은 컴파일-실행 사이클을 강제했다. LFortran은 그걸 깬다.
$ lfortran
LFortran 0.50.0
>>> integer :: i, n
>>> n = 10
>>> do i = 1, n
... print *, i*i
... end do
1
4
9
16
25
36
49
64
81
100
Jupyter 커널도 있다. Fortran 노트북이 가능해졌다. 교육 현장이 폭발적으로 반응한 이유다.
둘째, 모듈식 아키텍처. LFortran은 프론트엔드(파서·AST)와 백엔드(LLVM·C·x86·WASM)가 깔끔히 분리돼 있다. ASR(Abstract Semantic Representation)이라는 중간 표현으로 모든 백엔드를 통일한다. 다른 도구가 ASR을 읽어 Fortran 코드 분석·변환을 할 수 있다.
셋째, WebAssembly 출력. lfortran --backend=wasm 하면 .wasm 바이너리가 나온다. 브라우저에서 Fortran을 돌릴 수 있다 — 교육과 시연에 큰 의미다.
넷째, MIT 라이선스. gfortran(GPL)과 달리 LFortran은 상업 사용·통합에 자유롭다. 임베디드 시스템이나 클라우드 서비스가 Fortran 컴파일러를 끼워 쓰기에 적합하다.
다만 한계도 명확하다. 2026년 5월 기준 LFortran은 Fortran 90의 일부, 2008의 일부만 구현했다. CoArray, OpenMP, OpenACC는 미완성이다. 실제 HPC 코드를 컴파일하기엔 아직 이르다. 그러나 6개월마다 큰 진전을 보여서, 2027년쯤이면 운영 환경에서 쓸 수준이 될 가능성이 높다.
5장 · fpm — Fortran의 Cargo / pip
Fortran의 가장 약한 고리는 빌드 시스템이었다. C++에 CMake·Conan, Rust에 Cargo, Python에 pip가 있는 동안 Fortran은 Makefile + autoconf 시대에 머물렀다.
**fpm(Fortran Package Manager)**이 그걸 바꿨다. 2020년 fortran-lang.org 커뮤니티가 시작해 2024년 1.0이 나왔다.
# fpm.toml
name = "my_project"
version = "0.1.0"
[dependencies]
stdlib = { git = "https://github.com/fortran-lang/stdlib" }
fftpack = { git = "https://github.com/fortran-lang/fftpack" }
[[executable]]
name = "myapp"
source-dir = "app"
main = "main.f90"
$ fpm build
$ fpm run
$ fpm test
$ fpm install
Cargo와 거의 똑같은 경험이다. 의존성은 Git URL로 가져오고, 빌드는 자동 병렬, 테스트 프레임워크 통합, 패키지 인덱스(fpm-registry)까지 갖췄다.
fpm 덕에 Fortran 라이브러리 생태계가 다시 살아났다. fortran-lang/stdlib(표준 라이브러리), fortran-lang/fftpack, fortran-lang/fortuno(테스트), awvwgk/json-fortran, jacobwilliams/json-fortran, certik/fastGPT 같은 활발한 프로젝트가 fpm 기반으로 자라고 있다.
6장 · OpenMP · MPI · CoArray · DO CONCURRENT — Fortran 병렬 4종
Fortran의 진짜 강점은 병렬성이다. 4가지 모델을 어떻게 골라야 하나.
┌────────────────────────────────────────────────────────────────┐
│ Fortran 병렬화 4 모델 │
│ │
│ OpenMP 단일 노드, 다중 스레드, 공유 메모리 │
│ !$omp parallel do │
│ │
│ MPI 다중 노드, 메시지 전송, 분산 메모리 │
│ call MPI_Send / MPI_Recv │
│ │
│ CoArray (CAF) 분산이지만 Fortran 문법으로 표현 │
│ a[5] = a[3] + b[1] │
│ │
│ DO CONCURRENT 컴파일러가 자동 병렬화하는 안전 루프 │
│ do concurrent (i=1:N) │
└────────────────────────────────────────────────────────────────┘
OpenMP 5.2(2021)는 단일 노드 다중 스레드 모델이다. 지시문(directive) 한 줄로 루프를 병렬화한다.
!$omp parallel do reduction(+:s)
do i = 1, N
s = s + a(i) * b(i)
end do
!$omp end parallel do
가장 쉽고 가장 널리 쓰인다. gfortran, ifx, NVIDIA HPC 모두 OpenMP 5.x를 지원한다. OpenMP 5.2는 GPU 오프로딩도 표준화했다 — !$omp target 지시문으로 CUDA/HIP/SYCL 없이 GPU에 코드를 띄울 수 있다.
MPI 4.1(2023)은 다중 노드 메시지 전송 표준이다. 슈퍼컴퓨터의 표준 통신 방식이다. OpenMPI, MPICH, Intel MPI, Cray MPICH 등 구현이 다양하다. MPI 4.1은 부분 데이터타입, 영속 컬렉티브, 세션 모델을 들였다.
**CoArray Fortran(CAF)**은 Fortran 2008에 들어온 표준 분산 모델이다. 별도 라이브러리 호출 없이 언어 문법으로 다중 노드 데이터 공유를 표현한다.
real :: a(100)[*] ! 모든 이미지가 a(100)을 가짐
a(:) = a(:)[3] ! 이미지 3의 a를 내 a에 복사
sync all ! 모든 이미지 동기화
CAF는 학습 곡선이 가장 가파르지만 가장 우아하다. OpenCoArrays는 GFortran/gcc 위에서 CAF를 MPI로 구현하는 라이브러리다.
DO CONCURRENT(Fortran 2008)는 컴파일러가 자동 병렬화하는 안전 루프다.
do concurrent (i = 1:N) local(tmp)
tmp = a(i)**2
b(i) = tmp + c(i)
end do
루프 반복 간 의존성이 없음을 언어가 보장하므로 컴파일러가 자유롭게 벡터화·스레드화·GPU 오프로드한다. NVIDIA nvfortran은 DO CONCURRENT를 자동으로 GPU에 띄운다 — OpenMP나 OpenACC 지시문 없이.
7장 · BLAS · LAPACK · PETSc — HPC 라이브러리 생태계
Fortran을 직접 안 써도 BLAS와 LAPACK은 거의 모두가 쓴다. NumPy, MATLAB, R, Julia, Octave, SciPy — 전부 LAPACK 호출이 핵심이다.
┌────────────────────────────────────────────────────────────────┐
│ HPC 수치 라이브러리 스택 │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ 응용층: SciPy, NumPy, MATLAB, Julia, R │ │
│ └──────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────┐ │
│ │ LAPACK (1992) — 선형대수 (행렬 풀이) │ │
│ └──────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────┐ │
│ │ BLAS (1979) — 벡터/행렬 기본 연산 │ │
│ └──────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────┐ │
│ │ ScaLAPACK/PETSc — 분산 메모리 확장 │ │
│ └──────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘
**BLAS(Basic Linear Algebra Subprograms)**는 1979년에 시작한 표준 인터페이스다. Level 1(벡터-벡터), Level 2(행렬-벡터), Level 3(행렬-행렬) 세 단계로 나뉜다. Level 3가 가장 중요하다 — gemm(general matrix multiply) 한 함수가 슈퍼컴퓨터 성능 측정의 표준 벤치마크가 됐다.
구현은 다양하다. OpenBLAS(오픈소스, 가장 인기), Intel MKL(인텔 CPU 최적화, 무료 사용), AMD AOCL(AMD 최적화), BLIS(연구용, 모듈식), Apple Accelerate(M 시리즈), NVIDIA cuBLAS(GPU).
LAPACK은 BLAS 위에서 선형대수 알고리즘을 구현한다. LU 분해, QR 분해, SVD, 고유값 — 거의 모든 행렬 문제가 LAPACK 호출 하나로 풀린다. 35만 줄 Fortran으로, 1992년 첫 릴리스 후 30년 넘게 다듬어졌다.
ScaLAPACK은 LAPACK의 분산 메모리 버전이다. MPI 위에서 동작하며, 슈퍼컴퓨터에서 수십만 코어로 행렬 분해를 한다.
**PETSc(Portable Extensible Toolkit for Scientific Computation)**는 Argonne National Lab가 만든 PDE 풀이 라이브러리다. 희소 행렬, 비선형 풀이, 시간 적분, 메시 관리를 통합한다. Fortran과 C 모두에서 호출 가능하며, 대규모 시뮬레이션(유체역학, 전자기, 양자화학)의 백본이다.
Trilinos는 Sandia National Lab의 PETSc 대안이다. 더 모듈식이고 C++ 기반이지만 Fortran 호환 인터페이스를 제공한다.
**FFTW(Fastest Fourier Transform in the West)**는 MIT의 FFT 라이브러리로, 자기조정 알고리즘으로 하드웨어에 맞게 최적화된 코드를 런타임에 생성한다. 신호 처리, 천체물리, 양자역학에서 필수.
8장 · 기후 모델 — NEMO, CESM, ECMWF IFS, CMIP6
Fortran의 진짜 왕국은 기후 모델이다. CMIP6(Coupled Model Intercomparison Project Phase 6)에 등록된 30+ 기후 모델의 거의 전부가 Fortran으로 짜여 있다.
| 모델 | 기관 | 코드 규모 | 주 컴파일러 |
|---|---|---|---|
| NEMO | EU 컨소시엄 | 500K 줄 | gfortran, ifx |
| CESM | NCAR (미국) | 1.5M 줄 | Intel, gfortran |
| ECMWF IFS | ECMWF | 2M+ 줄 | Cray, gfortran |
| NICAM | RIKEN (일본) | 500K 줄 | Cray, Fujitsu |
| GFDL CM4 | NOAA | 800K 줄 | Intel |
| HadGEM3 | UK Met Office | 600K 줄 | Cray, Intel |
| MPI-ESM | 독일 MPI | 700K 줄 | Intel |
| KIM | 한국 기상청 | 400K 줄 | Intel |
**NEMO(Nucleus for European Modelling of the Ocean)**는 유럽의 해양 시뮬레이션 표준이다. 50만 줄 Fortran 90+, MPI로 분산, OpenMP로 노드 내 병렬. 위성 관측과 자료동화를 통해 실시간 해양 상태를 재현한다.
**CESM(Community Earth System Model)**은 NCAR의 종합 지구 시스템 모델이다. 대기(CAM), 해양(POP), 해빙(CICE), 육지(CLM), 결합기(CPL)로 구성되며 150만 줄이 넘는다. CMIP6 미국 측 기여의 중심이다.
**ECMWF IFS(Integrated Forecasting System)**는 세계에서 가장 정확한 글로벌 일기예보 모델이다. 200만 줄 Fortran, 8000+ 모듈, Cray 슈퍼컴퓨터에서 매일 4회 예보를 낸다. 2026년 시점 IFS 49R3가 정식 운영 버전이다.
**NICAM(Nonhydrostatic ICosahedral Atmospheric Model)**은 RIKEN(일본)의 정20면체 격자 대기 모델이다. Fugaku 슈퍼컴퓨터에서 3.5km 해상도 글로벌 시뮬레이션을 돌린다. 일본의 슈퍼컴퓨터 활용 전략의 상징이다.
이런 코드를 Python이나 Julia로 새로 쓰는 건 비현실적이다. 검증·인증·운영 안정성에 30년 이상이 들어갔다. 새 언어로 부분 모듈을 추가하는 시도는 있지만, 핵심 동역학 커널은 Fortran에 남는다.
9장 · Python 과학 스택 — NumPy / SciPy / Pandas / Polars
Fortran이 기반이라면 Python은 프론트엔드다. 2026년 과학 컴퓨팅 워크플로우의 사실상 표준 진입점은 Python이다.
NumPy 2.x(2024년 2.0, 2026년 2.3)는 다차원 배열의 사실상 표준이다. 내부적으로 LAPACK·BLAS를 호출하고, ndarray 한 객체에 수십 년치 최적화가 들어있다. 2.0에서 큰 API 정리가 있었고(string dtype, scalar promotion 변경), 2.3에서 GPU 백엔드 통합이 진행 중이다.
SciPy 1.16(2026)은 NumPy 위에서 과학 계산 함수를 제공한다. 적분, ODE, 최적화, 신호처리, 통계, 희소행렬, 보간 — 거의 모든 과학 계산 영역을 덮는다. 내부는 Fortran(LAPACK, ODEPACK, MINPACK, FFTPACK)과 C로 짜여 있다.
Pandas 2.x(2024년 2.0, 2026년 2.4)는 데이터프레임 표준이다. 2.0에서 PyArrow를 백엔드로 채택해 성능과 메모리 효율이 크게 좋아졌다. 시계열·범주형·결측치 처리에서 R의 data.frame을 능가하는 수준이 됐다.
Polars 1.x(2024년 1.0)는 Rust로 짠 Pandas 대안이다. 컬럼형 메모리, lazy 평가, 자동 병렬, Apache Arrow 네이티브. 큰 데이터셋에서 Pandas보다 5~50배 빠르다. 2026년 1.20대 — Pandas 호환 API와 GPU 백엔드(cuDF 통합)가 안정됐다.
NetworkX(그래프), scikit-learn(ML), statsmodels(통계), xarray(라벨드 N차원 배열, NetCDF 친화), Dask(분산 NumPy/Pandas)가 그 위에 쌓인다.
10장 · JAX · Equinox · Flax — 자동미분 시대의 과학 컴퓨팅
JAX(Google, 2018)는 NumPy의 API를 그대로 두면서 자동미분과 XLA 컴파일을 더한 라이브러리다. 2026년 JAX 0.5/1.0이 정식 안정화 단계로 진입했다.
import jax.numpy as jnp
from jax import grad, jit
def loss(x):
return jnp.sum(jnp.sin(x)**2)
grad_loss = jit(grad(loss))
g = grad_loss(jnp.array([1.0, 2.0, 3.0]))
핵심 기능은 4가지 변환이다.
grad— 자동미분jit— XLA 컴파일vmap— 자동 벡터화pmap— 자동 분산
@jit로 데코레이트된 함수는 XLA가 컴파일하고, GPU/TPU에서 그대로 돈다. NumPy 코드 한 줄도 안 고치고 100배 빨라지는 경험을 준다.
Equinox(Google DeepMind 출신, 2022)는 JAX에 PyTorch 스타일 모델 정의를 더한다.
Flax(Google, 2020)는 JAX의 대표적 NN 프레임워크다. NN 모델, 학습 루프, 체크포인트, 분산을 표준화한다.
JAX 생태계는 ML을 넘어 과학 컴퓨팅으로 번진다. JAX-FEM(유한요소), JAX-CFD(유체역학), JAX-MD(분자동역학)가 활발한 예다. 자동미분이 PDE 풀이와 결합하면 역설계 최적화가 자연스러워진다 — 입력 형상을 미분해 원하는 출력을 내는 형상을 찾는다.
11장 · Numba · Cython · PyPy · Mojo — Python 가속화 4종
Python의 약점은 인터프리터 속도다. 이를 메우는 4가지 접근.
Numba(Anaconda, 2012)는 LLVM 기반 JIT다. 데코레이터 하나로 Python 함수가 C 수준 속도로 돈다.
from numba import njit
@njit
def sum_loop(n):
s = 0.0
for i in range(n):
s += i**2
return s
NumPy와 잘 어울리고, CUDA 백엔드도 있다. ML보다 과학 컴퓨팅·시뮬레이션에서 자주 쓰인다.
Cython(2007)은 Python과 C의 중간 언어다. .pyx 파일에 타입 주석을 더하면 컴파일된 .so가 나온다. NumPy의 일부, scikit-learn의 핵심 알고리즘이 Cython으로 짜였다.
PyPy 7.3(2026)은 별도 JIT Python 인터프리터다. CPython보다 4~10배 빠르지만 NumPy/SciPy 호환성이 떨어진다. 순수 Python 비즈니스 로직에 좋다.
Mojo(Modular, 2023; Chris Lattner)는 Python의 슈퍼셋을 자처하는 새 언어다. LLVM 기반, SIMD/GPU 네이티브, 정적 타이핑 옵션. 2025년 0.7이 나왔고 2026년 1.0이 임박했다. Python 코드를 그대로 들여와 점진적으로 정적 타입을 더해 가속한다. 야심은 크지만 아직 라이브러리 생태계가 얇다.
12장 · Julia 1.11 — 동적 + 빠름의 약속
Julia(2012)는 "Walks like Python, runs like C"를 표어로 출발했다. 2026년 시점 1.11이 LTS, 1.12가 안정 진행 중이다.
Julia의 강점은 4가지다.
- LLVM JIT 컴파일. 동적 언어인데 컴파일 언어 수준 속도가 나온다.
- 다중 디스패치. 함수가 인자 타입 조합마다 다른 메서드를 가진다 — 과학 컴퓨팅에 자연스럽다.
- 메타프로그래밍. Lisp 수준 매크로로 DSL 작성이 쉽다.
- 수학 친화 문법. 유니코드 변수명(
α, β, γ), 연산자 오버로딩.
생태계 핵심은 DifferentialEquations.jl — 세계 최고의 ODE/PDE 풀이 라이브러리다. SUNDIALS와 함께 사실상 표준. Flux.jl(ML), MLJ.jl(ML 메타 프레임워크), Symbolics.jl(상징 계산), Pluto.jl(반응형 노트북), Plots.jl, Makie.jl(시각화).
**SciML(Scientific Machine Learning)**은 Julia의 차별화 영역이다. 미분방정식 + 신경망 = "Universal Differential Equations"로, 물리 법칙과 데이터를 함께 학습한다. Julia 1.11이 이 분야의 사실상 표준이다.
다만 Julia의 시장 점유는 Python보다 훨씬 작다. 학계 채택은 활발하지만 산업 채택은 아직 제한적이다.
13장 · R 4.5 · MATLAB 2026 · Mathematica 14 — 상용 진영
오픈소스 외에 상용 도구는 여전히 중요하다.
R 4.5(2026)는 통계의 표준 언어다. tidyverse(dplyr, ggplot2, tidyr) 생태계가 데이터 분석 워크플로우의 표준이 됐다. Posit(이전 RStudio)가 IDE와 클라우드 서비스, Quarto(다언어 노트북)을 만든다. 2026년 R 4.5는 ALTREP 개선, 병렬 BLAS 통합, 네이티브 파이프 |> 안정화가 핵심.
MATLAB R2026a(MathWorks)는 공학 시뮬레이션의 산업 표준이다. Simulink는 자동차·항공·전력 시스템 설계에서 사실상 의무다. 2026년 버전은 MATLAB Copilot(LLM 어시스턴트), GPU Coder 강화, 자동 ROS 2 코드 생성을 들였다. 라이선스는 비싸지만 산업 인증 가치가 있다.
Octave 9(2026)는 MATLAB과 거의 호환되는 오픈소스 대안이다. 학습용·소규모 연구에선 충분하지만 Simulink가 없어 대체 불가능한 영역이 있다.
Wolfram Mathematica 14(2024)는 상징 계산의 황제다. Wolfram Language로 상징·수치·시각화·노트북을 통합한다. LLMFunction이 정식 들어와 GPT/Claude를 함수처럼 호출한다.
SageMath 10.4(2026)는 SymPy, Maxima, PARI/GP, GAP을 묶은 종합 오픈소스 CAS다. Python 기반이라 진입이 쉽다.
14장 · APL 가족 — 배열 사고의 극단
**APL(A Programming Language)**은 Kenneth Iverson이 1962년에 발표한 표기법에서 시작한 언어다. 특수 문자(⍴, ⍳, ←, ⌽)로 배열 연산을 표현하며, "한 줄이 한 페이지"라는 표현이 어울린다.
⍝ 평균 계산
mean ← {(+/⍵)÷≢⍵}
mean 1 2 3 4 5
3
APL은 죽지 않았다. 오히려 2026년 가족이 늘었다.
| 변종 | 표기 | 라이선스 | 강점 |
|---|---|---|---|
| Dyalog APL | 유니코드 기호 | 상용 | 산업 표준, 금융 |
| GNU APL | 유니코드 기호 | GPL | 오픈, ISO 호환 |
| J | ASCII | GPL | Iverson 후속, 무료 |
| K (kdb+/q) | ASCII | 상용 | HFT/금융 표준 |
| BQN | 유니코드 | MIT | 현대화, 함수형 |
| Uiua | 유니코드 | MIT | 스택형, 2023+ |
| Co-dfns | 유니코드 | MIT | APL → GPU 컴파일 |
Dyalog APL은 상용 APL의 사실상 표준이다. 금융, 보험, 통신에서 쓰인다. JetBrains 스타일 IDE 지원도 있다.
J(1990)는 Iverson이 ASCII 문자로 다시 만든 APL이다. 유니코드 키보드 없이도 쓸 수 있다.
K + kdb+ + q(Kx Systems)는 금융 시계열 DB의 사실상 표준이다. q는 K 위의 SQL 같은 질의 언어. 글로벌 은행·HFT 회사 거의 모두가 kdb+를 쓴다. 라이선스가 비싸지만(연간 수십만 달러) 대체 불가능하다.
**BQN(Big Question Notation)**과 Uiua(2023)는 21세기 APL이다. BQN은 함수형 패러다임을 더했고, Uiua는 스택 기반(Forth-like)이다. 둘 다 활발한 커뮤니티가 있다.
Co-dfns는 APL 부분집합을 GPU로 컴파일한다 — 배열 언어의 진정한 미래일 수 있다.
배열 언어는 시장 점유는 작지만 사상적 영향은 크다. NumPy의 broadcasting, Pandas의 vectorization, JAX의 functional 변환은 모두 APL이 1962년에 보여준 아이디어다.
15장 · GPU 컴퓨팅 — CUDA / ROCm / oneAPI / Triton / CuPy
2026년 과학 컴퓨팅에서 GPU는 선택이 아니라 기본이다.
CUDA 13(NVIDIA, 2025)는 GPU 컴퓨팅 사실상 표준이다. CUDA C, CUDA Fortran, CUDA Python(이전 cuda.core), cuBLAS, cuDNN, cuSPARSE, cuSOLVER, cuFFT 등 라이브러리 스택. 14년치 최적화와 생태계 자산이 있다.
ROCm 6.x(AMD, 2024)는 AMD GPU의 CUDA 대안이다. HIP라는 CUDA 유사 API로 코드 이식이 비교적 쉽다. El Capitan(LLNL, AMD MI300) 슈퍼컴퓨터가 ROCm 기반이다.
oneAPI(Intel, 2020)는 SYCL 표준 기반 인텔 GPU 프로그래밍 환경이다. Aurora 슈퍼컴퓨터(Argonne)가 사용한다.
Triton(OpenAI, 2021)은 GPU 커널을 Python으로 짜는 언어다. CUDA보다 추상화 수준이 높고, PyTorch 백엔드의 일부를 차지한다. 학습·연구 환경에서 폭발적으로 쓰인다.
CuPy(Preferred Networks, 2017)는 NumPy의 CUDA 대체다. import cupy as np 한 줄로 NumPy 코드가 GPU에 띄워진다.
OpenACC는 OpenMP의 GPU 친화 사촌이다. 지시문으로 GPU 오프로드를 표현한다. Fortran과 가장 잘 어울려 NVIDIA HPC 컴파일러의 주력이다.
GPU 시대의 진짜 변화는 언어가 GPU를 가린다는 점이다. JAX, Julia, CuPy를 쓰는 사람은 자기가 GPU에 무얼 띄우는지 안 봐도 코드가 돈다. Fortran 사용자는 DO CONCURRENT 한 줄로 GPU가 자동으로 떨어진다.
16장 · 슈퍼컴퓨터 — Fugaku, Nurion, Frontier, El Capitan
Top500(매년 6월, 11월 발표)은 슈퍼컴퓨터 순위 리스트다. 2026년 상위 머신을 보자.
| 순위 | 머신 | 기관 | 성능 (Rmax PF) | 아키텍처 |
|---|---|---|---|---|
| 1 | El Capitan | LLNL (미국) | 1742 | AMD EPYC + MI300A |
| 2 | Frontier | ORNL (미국) | 1206 | AMD EPYC + MI250X |
| 3 | Aurora | Argonne (미국) | 1012 | Intel Sapphire Rapids + Max GPU |
| 4 | Eagle | Microsoft Azure | 561 | NVIDIA H100 |
| 5 | Fugaku | RIKEN (일본) | 442 | Fujitsu A64FX (ARM) |
Fugaku(2020 도입, 일본 RIKEN)는 ARM 기반 슈퍼컴퓨터로 2020~2021년 Top500 1위였다. Fujitsu A64FX 칩(48코어 ARM + SVE 512비트 벡터)을 158,976개 노드로 구성. CPU만으로 1.4 ExaFLOPS를 냈다 — GPU 없이. 2026년 시점 5위로 내려왔지만 여전히 활발히 운영된다. 후속 "Fugaku-NEXT"가 2030년 가동을 목표로 설계 중이다.
Nurion(2018, 한국 KISTI)은 한국 최대 슈퍼컴퓨터로 Intel Xeon Phi 기반이다. 25.7 PF로 도입 당시 Top500 11위. 현재는 더 밀려났지만 국내 기상·바이오·항공우주 연구의 중심이다. 후속 KISTI 6호기가 2026년 도입 진행 중이다.
Frontier(2022, ORNL)는 세계 첫 ExaFLOPS 머신이다. AMD EPYC CPU와 Instinct MI250X GPU로 구성. 기후·핵융합·재료 시뮬레이션의 미국 측 거점.
El Capitan(2024, LLNL)은 2026년 5월 기준 Top500 1위다. AMD MI300A(APU — CPU + GPU 통합)를 채택해 1.74 ExaFLOPS. 핵무기 시뮬레이션과 기후가 주 용도.
Aurora(2024, Argonne)는 Intel Max GPU 기반이다. AI/HPC 융합 워크로드가 주 타깃.
이런 머신에서 도는 코드의 절대 다수가 Fortran 또는 C++다. 슈퍼컴퓨터 사용 시간은 시간당 수만 달러에 거래되며, "1% 성능 향상"이 막대한 가치다. 그래서 Cray, Fujitsu, NVIDIA의 전용 컴파일러가 살아남는다.
17장 · 슈퍼컴퓨터 관리 — Slurm / PBS Pro / LSF / Spack
슈퍼컴퓨터 사용자는 보통 직접 머신을 돌리지 않는다. 큐 시스템에 작업을 제출하고 결과를 받는다.
Slurm(SchedMD, 2003)은 가장 널리 쓰이는 오픈소스 작업 스케줄러다. Top500의 60% 이상이 Slurm을 쓴다.
#!/bin/bash
#SBATCH --job-name=climate_run
#SBATCH --nodes=128
#SBATCH --ntasks-per-node=64
#SBATCH --time=24:00:00
#SBATCH --partition=large
mpirun -n 8192 ./nemo.exe
sbatch script.sh로 제출, squeue로 큐 확인, scancel로 취소.
PBS Pro(Altair)와 LSF(IBM)는 상용 대안이다. 옛 슈퍼컴퓨터 다수가 PBS 또는 LSF를 쓴다.
Spack(LLNL, 2013)은 HPC 환경의 패키지 관리자다. apt/yum과 달리 같은 라이브러리의 여러 버전·컴파일러 조합을 동시에 설치할 수 있다.
$ spack install petsc@3.19.0 +mpi ^openmpi@4.1.5 %gcc@13.2.0
PETSc 3.19, MPI 백엔드, OpenMPI 4.1.5, GCC 13.2.0으로 빌드. 같은 시스템에 PETSc 3.20, Intel MPI, ifx 빌드도 따로 깔 수 있다. 슈퍼컴퓨터 운영자에게 필수.
Easybuild(벨기에 KU Leuven)는 Spack의 유럽판 경쟁자다.
18장 · 과학 데이터 포맷 — HDF5 / NetCDF / FITS / MAT
대규모 과학 데이터는 CSV나 JSON로 안 된다. 4가지 포맷이 표준이다.
**HDF5(Hierarchical Data Format 5)**는 NCSA가 만든 자기설명형 바이너리 포맷이다. 트리 구조로 데이터셋과 메타데이터를 담고, 압축, 청크, 병렬 I/O를 지원한다. 천체물리, 기후, 생명과학에서 표준.
**NetCDF(Network Common Data Form)**는 UCAR가 만든 기후·해양 데이터 표준 포맷이다. NetCDF 4부터는 HDF5 위에서 동작한다. ECMWF, NCAR, NOAA의 모든 모델 출력이 NetCDF다.
**FITS(Flexible Image Transport System)**는 천문학의 표준 포맷이다. 1981년에 표준화돼 NASA, ESA, JWST가 모두 FITS로 데이터를 배포한다.
**MAT(MATLAB 파일)**는 MATLAB의 네이티브 바이너리다. v7.3부터는 HDF5 기반이다. SciPy의 scipy.io.loadmat로 Python에서 읽을 수 있다.
Apache Parquet과 Apache Arrow가 빅데이터 진영의 표준이지만, 과학 컴퓨팅에선 아직 NetCDF/HDF5가 우세하다.
Zarr(2018)는 NetCDF/HDF5의 클라우드 친화 대안이다. 청크를 S3 객체로 분산 저장해 분산 분석에 적합하다. xarray와 결합해 사용한다.
19장 · Mojo · LFortran · 차세대 과학 언어
2020년대 후반에 들어와 과학 컴퓨팅의 차세대 언어 후보가 셋 등장했다.
Mojo(Modular, 2023)는 Chris Lattner(LLVM/Swift 창시자)가 만들었다. Python 슈퍼셋을 자처하며, LLVM/MLIR 기반으로 SIMD/GPU를 네이티브 지원한다. 2026년 1.0 임박. 야심은 "Python의 사용성 + C++의 성능 + Fortran의 배열 연산"이다.
LFortran(2022)은 이미 6장에서 본 대로 Fortran의 IPython 모먼트다.
Bend(2024)는 GPU 친화 함수형 언어다. CPU 코드를 자동으로 GPU 병렬화한다. 아직 실험적이지만 패러다임 전환의 가능성을 보인다.
Julia 1.x도 여전히 후보다. 1.11/1.12에서 ABI를 잠그면서 산업 채택의 마지막 장벽을 낮추고 있다.
이 중 어느 하나가 Fortran을 대체할 가능성은 낮다. 그러나 새 과학 프로젝트의 기본 선택이 될 가능성은 있다. 5~10년 후 풍경은 크게 다를 것이다.
20장 · 양자 컴퓨팅과 과학 — Qiskit / Cirq / PennyLane
양자 컴퓨터는 아직 NISQ(잡음 있는 중간 규모) 단계지만, 과학 시뮬레이션에서 의미 있는 결과가 나오고 있다.
Qiskit(IBM)은 Python 기반 양자 SDK다. IBM Quantum 하드웨어(127~1121큐비트)를 클라우드에서 쓴다. 화학 시뮬레이션, 최적화, ML이 주 응용 영역.
Cirq(Google)는 Sycamore와 Willow(105큐비트, 2024) 하드웨어를 쓴다. 양자 우월성 실험의 도구.
PennyLane(Xanadu)은 양자 ML 특화 프레임워크다. PyTorch/JAX와 통합된다.
양자 컴퓨팅과 Fortran의 접점은 고전 시뮬레이터다. 양자 회로를 고전 컴퓨터에서 시뮬레이션할 때 핵심 연산이 텐서 수축(tensor contraction)이고, 이건 결국 BLAS gemm 호출이다. Cray, NVIDIA, Intel의 양자 시뮬레이터 백엔드는 모두 BLAS/LAPACK에 의존한다.
이 주제는 별도 글에서 더 깊이 다룬다. 여기선 양자 컴퓨팅도 결국 수치 선형대수 위에 서 있다는 점만 짚고 넘어간다.
21장 · 한국·일본의 과학 컴퓨팅 — KISTI / RIKEN / AIST
**KISTI(한국과학기술정보연구원)**는 한국의 슈퍼컴퓨터 운영 기관이다. Nurion(5호기, 25.7PF), Tachyon2를 운영하며 2026년 6호기 도입을 진행 중이다. 한국 기상청 KIM 모델, 핵융합 연구원의 KSTAR 시뮬레이션이 KISTI에서 돈다.
서울대 슈퍼컴퓨터도 별도 운영된다. NVIDIA DGX 클러스터와 InfiniBand 기반. AI 연구가 주 워크로드.
KAIST, GIST, UNIST도 각자 슈퍼컴퓨터 자원을 운영한다.
**RIKEN(이화학연구소)**은 일본의 대표 과학 연구소다. Fugaku를 운영하며 NICAM 기후 모델, MD 시뮬레이션, 양자 시뮬레이션을 돌린다. 2030년 가동 목표의 차세대 Fugaku-NEXT가 설계 중이다.
**AIST(산업기술종합연구소)**는 일본의 응용 과학 연구 기관이다. ABCI(AI Bridging Cloud Infrastructure) 슈퍼컴퓨터를 운영하며 AI/HPC 융합 워크로드를 다룬다. ABCI 3.0이 2024년 가동을 시작했다.
**JAMSTEC(해양연구개발기구)**는 Earth Simulator를 운영한다. 1세대(2002), 2세대(2009), 3세대(2015), 4세대(2021) — NEC SX-Aurora TSUBASA 벡터 머신으로, 일본의 벡터 컴퓨팅 전통이 살아있는 곳이다.
한일 양국의 과학 컴퓨팅 전통은 깊다. 일본의 벡터 컴퓨터 전통(Earth Simulator, Fugaku)과 한국의 GPU/AI 전환이 대조적이다.
22장 · 노트북 환경 — Jupyter / Quarto / Marimo / Pluto
과학 컴퓨팅의 일상 도구는 노트북이다. 2026년 풍경.
Jupyter(2014, 이전 IPython)는 사실상 표준이다. Python/Julia/R/Fortran(LFortran)/Scala 등 40+ 커널을 지원한다. JupyterLab 4.x가 차세대 인터페이스.
Quarto(Posit, 2022)는 R Markdown의 후속이다. Python/R/Julia/JS 다언어 문서를 PDF/HTML/Word/EPUB로 출력한다. Quarto Manuscripts는 학술 논문 작성용.
Marimo(2023)는 반응형 Python 노트북이다. Pluto.jl처럼 셀 간 의존성을 자동 추적하고, .py 파일로 저장된다. Git diff가 잘 되고 reproducibility가 좋다.
Pluto.jl(2020)은 Julia의 반응형 노트북이다. 셀 하나를 바꾸면 의존하는 모든 셀이 자동으로 다시 실행된다. 교육과 시연에 강하다.
Deepnote, Hex, Noteable은 클라우드 노트북 서비스다. 협업과 SQL/Python 통합에 강점.
이 주제는 별도 노트북 글에서 더 깊이 다룬다.
23장 · 과학 컴퓨팅 학습 경로 — 학생 / 연구자 / 공학자
마지막으로 누가 무엇을 배워야 하는지 정리한다.
대학생 (학부):
- Python + NumPy + Matplotlib (기본 도구)
- Jupyter 노트북 (작업 환경)
- Git/GitHub (협업)
- 선형대수와 수치해석 (이론)
- 관심 분야 따라 R/Julia/MATLAB 중 하나 추가
대학원생 (석박사):
- 학부 + SciPy + scikit-learn (응용)
- PyTorch 또는 JAX (자동미분)
- 영역별 도메인 라이브러리 (예: 천체물리는 Astropy)
- HPC 사용법 (SLURM, Spack)
- Fortran 읽기 능력 (기존 코드 이해)
기후·해양 연구자:
- Fortran 쓰기 능력 필수
- NetCDF/HDF5/xarray
- NEMO/CESM/IFS 같은 운영 모델 코드 이해
- MPI/OpenMP 병렬화
- Cray/Intel 컴파일러 사용법
공학자 (시뮬레이션):
- MATLAB + Simulink (사실상 표준)
- ANSYS/ABAQUS/COMSOL (상용 도구)
- Python 보조 (데이터 처리)
- 일부 Fortran (레거시 솔버)
데이터 과학자:
- Python + Pandas + Polars
- SQL 능숙
- scikit-learn → PyTorch/JAX
- 클라우드 노트북 (Hex, Deepnote)
- 통계 위해 R도 가능
핵심은 Python을 기본으로 두고, 영역에 따라 Fortran/Julia/R/MATLAB을 더하는 것이다. 한 도구로 모든 걸 하는 시대는 끝났다.
24장 · 자주 묻는 질문 — Q&A
Q. 2026년에 Fortran을 새로 배울 가치가 있나?
A. 프로젝트를 새로 시작하는 거라면 Julia나 Python이 낫다. 다만 기후·고에너지물리·HPC 연구자라면 Fortran 읽기는 필수다. 100만 줄짜리 운영 모델을 이해해야 한다.
Q. NumPy/SciPy가 Fortran보다 느린가?
A. 일대일 비교는 아니지만, NumPy의 내부는 결국 Fortran(LAPACK)/C(BLAS)다. 사용자 코드가 NumPy 함수 호출 위주면 Fortran과 비슷한 속도가 나온다. 사용자 코드가 Python for-loop 위주면 100배 느려진다. Numba/Cython으로 그 부분을 가속할 수 있다.
Q. Julia가 Fortran을 대체할까?
A. 단기에는 안 한다. 운영 코드 재작성 비용이 너무 크다. 장기에는 새 프로젝트의 상당 부분을 Julia가 가져갈 가능성이 있다.
Q. LFortran은 언제 운영 환경에서 쓸 수 있나?
A. 2026년 5월 기준 LFortran은 베타다. 빠르면 2027년, 늦으면 2028~2029년에 운영 수준이 될 것이다.
Q. Mojo는 어떤가?
A. 야심은 크지만 라이브러리 생태계가 얇다. 1.0이 나와도 NumPy/SciPy 수준의 자산을 쌓으려면 5~10년이 필요하다.
Q. APL은 정말 쓸 만한가?
A. 금융 HFT는 K/q가 사실상 표준이다. 그 외엔 사상적 흥미가 더 크다. NumPy 사용자는 APL 정신모델을 익히면 NumPy 코드가 우아해진다.
25장 · 마치며 — Fortran의 역설과 과학 컴퓨팅의 미래
Fortran의 가장 큰 역설은 이것이다. "가장 오래된 고수준 언어가 여전히 가장 빠른 언어 중 하나다."
이 역설의 해답은 단순하다. Fortran은 특정 문제(배열 연산)를 처음부터 잘하도록 설계됐다. 70년이 지나면서 더 좋아진 거다. C는 시스템 프로그래밍을 잘하도록 설계됐고, Python은 사용성을 잘하도록 설계됐다. 각자 자기 영역에서 최강이다.
2026년 과학 컴퓨팅은 언어 다양성의 시대다. Fortran은 운영 모델의 기반암으로 남고, Python이 프론트엔드를 가져가고, Julia가 새 프로젝트를 노리고, JAX가 ML/과학을 융합한다. APL은 사상으로 살고, MATLAB은 산업으로 살고, R은 통계로 산다.
이 글이 그 지형 전체의 지도가 됐길 바란다. 마지막으로 행동 권고. (1) 이미 도구가 있다면 그걸 더 깊이 파라. 새 도구는 신중하게 추가하라. (2) Python + NumPy는 공용 어휘다. 어떤 영역이든 이건 알아야 한다. (3) Fortran을 쓰지 않더라도 읽는 법은 익혀라 — 과학 컴퓨팅 라이브러리의 절반이 결국 Fortran으로 시작한다. (4) Julia/JAX/Mojo 같은 신참은 관찰하라. 5년 후 표준이 될지 죽을지 아직 모른다.
기후가 변하고, 입자 가속기가 돌고, 슈퍼컴퓨터가 ExaFLOPS를 넘어선다. 그 모든 것의 뒤에서 컴파일된 배열 연산이 도는 한, Fortran의 자식들은 계속 일할 것이다. Fortran은 죽지 않는다 — 단지 형태를 바꿔 살아남는다.
참고 자료 (References)
- Fortran 2023 표준 (ISO/IEC 1539:2023): https://www.iso.org/standard/82170.html
- fortran-lang.org 커뮤니티 허브: https://fortran-lang.org/
- LFortran 프로젝트: https://lfortran.org/
- gfortran (GCC): https://gcc.gnu.org/fortran/
- LLVM Flang: https://flang.llvm.org/
- NVIDIA HPC SDK: https://developer.nvidia.com/hpc-sdk
- Intel ifx / oneAPI: https://www.intel.com/content/www/us/en/developer/tools/oneapi/fortran-compiler.html
- Fortran Package Manager (fpm): https://fpm.fortran-lang.org/
- Fortran stdlib: https://stdlib.fortran-lang.org/
- OpenMP 5.2 사양: https://www.openmp.org/specifications/
- MPI 4.1 문서: https://www.mpi-forum.org/docs/
- LAPACK: https://www.netlib.org/lapack/
- BLAS: https://www.netlib.org/blas/
- PETSc: https://petsc.org/release/
- NumPy 2.x 문서: https://numpy.org/doc/stable/
- SciPy 문서: https://docs.scipy.org/doc/scipy/
- JAX 문서: https://docs.jax.dev/
- Julia 1.11 문서: https://docs.julialang.org/en/v1/
- Top500 2025년 11월 리스트: https://top500.org/lists/top500/2025/11/
- RIKEN Fugaku: https://www.r-ccs.riken.jp/en/fugaku/
- KISTI 슈퍼컴퓨터: https://www.ksc.re.kr/eng
- ECMWF IFS: https://www.ecmwf.int/en/forecasts/documentation-and-support
- NCAR CESM: https://www.cesm.ucar.edu/
- CMIP6: https://www.wcrp-climate.org/wgcm-cmip/wgcm-cmip6
- APL Wiki: https://aplwiki.com/
- Modular Mojo: https://docs.modular.com/mojo/
- HDF5: https://www.hdfgroup.org/solutions/hdf5/
- NetCDF: https://www.unidata.ucar.edu/software/netcdf/
마지막 업데이트: 2026-05-16. 다음 글에서는 이 글에서 짚은 한 분야 — 기후 모델 코드 깊이 보기 — 를 깊게 다룰 예정이다.