슈퍼컴퓨터 30년사 — 하드웨어는 진화했지만 언어는 왜 그대로일까

HPC 세계의 이상한 시간 정지

HPC(High Performance Computing, 고성능 컴퓨팅)라는 분야가 있어요. 쉽게 말하면 슈퍼컴퓨터로 거대한 계산을 돌리는 영역이에요. 기상 예측, 신약 개발 시뮬레이션, 핵융합 연구, 최근에는 거대 AI 모델 학습까지 다 여기 들어갑니다. 그런데 Chapel이라는 병렬 프로그래밍 언어를 만드는 팀에서 '지난 30년 동안 HPC 하드웨어는 어마어마하게 변했는데 정작 쓰는 언어는 거의 안 바뀌었다'는 흥미로운 회고글을 올렸어요.

뭐가 얼마나 안 바뀌었냐면, 아직도 HPC 코드의 상당수가 Fortran으로 돌아가요. 네, 그 1957년에 나온 Fortran 맞아요. C와 C++도 많이 쓰이고, 병렬 처리는 여전히 MPI(Message Passing Interface)와 OpenMP에 의존합니다. 이 둘은 각각 1994년, 1997년에 나온 기술이에요. 한편 그사이 하드웨어는 단일 CPU에서 멀티코어로, 다시 GPU 가속으로, 최근엔 수만 개의 노드를 연결한 엑사스케일(초당 10의 18제곱번 연산) 시대로 넘어왔거든요.

핵심 내용 — 하드웨어 변화의 규모

글에서 지적하는 하드웨어 진화를 잠깐 짚고 가면요. 1990년대 중반만 해도 최고 수준의 슈퍼컴퓨터가 기가플롭(초당 10억 연산) 수준이었어요. 2008년에 페타플롭(10의 15제곱)을 넘었고, 2022년 Frontier가 엑사플롭을 찍었죠. 연산 능력이 10억 배 이상 올라간 거예요. 그사이 메모리 계층은 훨씬 복잡해졌고, 네트워크 토폴로지도 단순한 트리 구조에서 드래곤플라이 같은 고급 구조로 진화했어요.

이런 환경에서 성능을 제대로 뽑으려면 코드가 데이터 지역성(data locality)을 잘 이해해야 해요. 이게 뭐냐면, 계산할 데이터가 CPU 코어 가까이에 있어야 빠르다는 원리예요. 멀리 있는 메모리나 다른 노드에서 데이터를 가져오면 연산 속도보다 데이터 이동 시간이 훨씬 커져서 성능이 바닥을 칩니다. 문제는 Fortran+MPI 조합으로 이걸 표현하려면 프로그래머가 일일이 '이 데이터는 저 노드로 보내고, 저 계산 결과는 이쪽으로 받고' 하는 걸 수작업으로 써야 한다는 거예요.

왜 새 언어로 안 넘어갈까

글에서는 새 언어 도입이 지지부진한 이유를 몇 가지로 정리해요. 첫째, 레거시 코드의 무게예요. 기상청 예보 모델이나 원자력 시뮬레이션 코드는 수십 년간 수백만 줄씩 쌓여 왔어요. 이걸 새 언어로 다시 쓴다는 건 기능 검증까지 포함하면 수년짜리 프로젝트예요. 둘째, 성능의 확실성이에요. HPC 사용자들은 벤치마크에 극도로 민감해서, 새 언어가 10% 느리면 아예 쳐다보지도 않아요.

셋째, 인력 파이프라인이에요. 과학자와 엔지니어들이 학부·대학원에서 배우는 게 여전히 Fortran과 C+MPI거든요. 새 언어로 논문을 쓰면 리뷰어들이 '재현 가능성이 떨어진다'며 깎는 경우도 있어요. 이건 기술 문제가 아니라 문화 문제예요.

그래도 도전은 계속 있어요. Chapel 자체가 Cray(현재 HPE)에서 만든 병렬 언어고, Julia, X10, Fortress 같은 시도도 있었어요. 최근엔 Rust의 병렬 라이브러리인 Rayon이나 Python의 mpi4py, JAX 같은 것도 HPC 영역에 스며들고 있고요. Chapel은 특히 전역 뷰 프로그래밍(global-view programming)을 강조해요. 여러 노드에 흩어진 데이터를 하나의 거대한 배열처럼 다루게 해주는 개념인데, 프로그래머가 통신 코드를 직접 쓸 필요가 없어요.

업계 맥락 — AI 시대의 변수

재미있는 건 최근 AI가 이 판을 흔들고 있다는 점이에요. GPT나 Llama 같은 거대 언어 모델을 학습시키는 일은 본질적으로 HPC 작업이거든요. 그런데 이쪽은 Fortran이 아니라 PyTorch와 JAX로 돌아갑니다. NVIDIA의 CUDA 생태계, 그리고 그 위에 쌓인 Python 레이어가 실질적인 '현대 HPC 언어' 자리를 꿰찬 거예요.

전통 HPC 커뮤니티와 AI 커뮤니티가 같은 하드웨어(같은 GPU 클러스터)를 놓고 서로 다른 소프트웨어 스택을 쓰고 있는 셈이에요. 앞으로 이 두 세계가 합쳐질지, 아니면 각자의 길을 갈지는 흥미로운 관전 포인트예요. MOJO 같이 Python 호환성을 유지하면서 시스템 프로그래밍 성능을 내려는 언어도 나오고 있고요.

한국 개발자에게 주는 시사점

한국에도 KISTI(한국과학기술정보연구원)의 누리온 같은 슈퍼컴퓨터가 있고, 이걸 쓰는 연구실이 많아요. 물리, 화학, 기상, 생명과학 전공자들이 실질적으로 코드를 돌리거든요. 그런 분들께는 이 글이 '내가 Fortran만 쓰는 게 뒤쳐진 건 아닐까?' 하는 고민에 대한 답을 주는 느낌이에요. 뒤쳐진 게 아니라 산업 구조가 그렇게 굳어 있는 거고, 대신 Chapel이나 Julia 같은 대안도 조금씩 공부해두면 미래 가치가 있다는 거죠.

일반 백엔드나 웹 개발자분들께는 '추상화의 대가(cost of abstraction)'라는 개념을 다시 생각해볼 계기가 돼요. 성능이 극단적으로 중요한 영역에서는 왜 50년 된 언어가 살아남는지, 그 반대급부로 왜 개발 생산성이 중요한 영역에서는 Python이 지배하는지, 각 영역의 트레이드오프를 이해하면 기술 선택의 감각이 훨씬 깊어져요.