Workload–Runtime Signatures of Parallel Scaling Bottlenecks: A Cross-Language Empirical Study of Rust, Julia, Haskell, and Python

현대적인 컴퓨터는 거대한 문제를 더 빠르게 해결하기 위해 노동력을 분할하도록 설계된, 마치 팀의 일꾼들처럼 많은 처리 장치들로 구성되어 있습니다. 수십 년 동안, 프로그램이 이러한 일꾼들을 얼마나 잘 사용하는지 판단하는 표준적인 방법은 속도 향상(speedup), 즉 일꾼을 추가했을 때 작업이 얼마나 더 빨라지는지를 측정하는 것이었습니다. 만약 한 명의 일꾼이 작업을 수행하는 데 10분이 걸린다면, 완벽한 시스템은 두 명의 일러가 있을 때 5분, 열 명의 일꾼이 있을 때 1분이 걸려야 합니다. 그러나 현실 세계에서는 일꾼을 추가하더라도 수익 체감 현상이 발생하는 경우가 많습니다. 때로는 작업이 거의 빨라지지 않기도 하고, 심지어는 더 느려지기도 합니다. 이는 일꾼들이 고립되어 일할 수 없기 때문입니다. 그들은 서로 조율하고, 데이터를 공유하며, 서로를 기다려야 합니다. 컴퓨터 과학자들의 핵심 질문은 단일 일꾼이 얼마나 빠른가가 아니라, 작업량이 변할 때 전체 팀이 어떻게 행동하느냐 하는 것입니다. 이러한 팀을 구축하는 데 사용되는 명령어 세트인 프로그래밍 언어들은 이 조율 과정을 근본적으로 다른 방식으로 처리합니다. 어떤 언어는 메모리를 자동으로 관리하고, 어떤 언어는 수동 제어를 요구하며, 어떤 언어는 혼란을 방지하기 위해 단일 락(lock)을 사용하는 반면, 어떤 언어는 일꾼들이 서로의 작업을 훔칠 수 있게 허용하기도 합니다. 작업량이 변할 때 팀의 일꾼들이 정확히 어디에서, 왜 어려움을 겪기 시작하는지 이해하는 것은 기상 예보부터 금융 모델링에 이르기까지 효율적인 소프트웨어를 구축하려는 엔지니어들에게 매우 중요합니다.

최근 한 연구는 단순한 속도 순위를 넘어 이러한 실패의 구체적인 메커니 heavy mechanics를 이해하기 위해 착수했습니다. 오스트리아 기술 연구소(Austrian Institute of Technology)의 연구진은 네 가지 대중적인 프로그래밍 언어인 Rust, Julia, Haskell, Python을 조사했습니다. 이 언어들은 병렬 작업을 관리하는 방식에 있어 매우 다른 철학을 대변하기 때문에 선정되었습니다. Rust는 프로그래머에게 자동 정리 기능 없는 엄격한 메모리 제어권을 부여하고, Julia는 코드를 실행 중에 최적화하기 위해 JIT(just-in-time) 컴파일러를 사용하며, Haskell은 독특한 지연 평가(deferred evaluation)와 경량 스레드 시스템에 의존하고, Python은 대중적이지만 병렬 처리를 위해 별도의 프로세스를 사용해야 하는 글로벌 락(global lock)에 의해 제약을 받습니다. 연구팀은 단순히 몇 가지 작업에 이 언어들을 실행한 것이 아니라, 각 언어가 특정 조건 하에서 어떻게 행동하는지 관찰하기 위해 통제된 환경을 구축했습니다. 그들은 세 가지 뚜렷한 유형의 작업을 테스트했습니다: 결과물을 지속적으로 병합해야 하는 정렬 작업, 대규모 집합에서 가장 가까운 점들을 찾는 기하학적 탐색, 그리고 조율이 거의 필요 없는 단순 합계 계산입니다. 그들은 1명, 2명, 4명, 8명, 16명의 일꾼을 사용하여 이 작업들을 실행했으며, 입력 크기를 다양하게 조절하면서 총 소요 시간뿐만 아니라 그 시간이 정확히 어떻게 소비되었는지도 측정했습니다.

연구진은 프로그램이 느려지는 이유가 결코 "언어가 느리다"와 같은 단일하고 보편적인 원인이 아님을 발견했습니다. 대신, 병목 현상은 작업의 형태와 일꾼의 수에 따라 달라집니다. 그들은 총 시간을 세 부분으로 나누는 방법을 도입했습니다: 일꾼들이 실제 계산을 수행하는 데 쓰는 시간, 결과를 결합하는 데 쓰는 시간, 그리고 대기나 데이터 이동과 같은 오버헤드에 소비되는 나머지 시간입니다. 일꾼이 추가됨에 따라 이 세 부분이 어떻게 변하는지 추적함으로써, 그들은 각 언어와 작업 조합에 대한 "시그니처"를 식별할 수 있었습니다. 예를 들어, 방대한 숫자 목록을 정렬할 때, 대부분의 언어에서 병목 현상은 결국 일꾼들이 숫자를 정렬하는 단계에서 정렬된 조각들을 다시 병합하는 데 필요한 시간으로 전이되었습니다. 이는 Rust든 Python이든 상관없이 발생했는데, 작업의 알고리즘 구조 자체가 팀이 일하는 시간보다 대화하는 데 더 많은 시간을 쓰도록 강제했기 때문입니다. 이러한 경우, 일꾼을 더 추가하는 것은 병합 단계를 더욱 비싸게 만들어 속도 향상을 정체시켰습니다.

또한 이 연구는 서로 다른 언어들이 서로 다른 방식으로 실패한다는 것을 보여주었습니다. 거대한 숫자 목록을 합산하는 것과 같이 순수하게 계산 중심적인 작업일 때는 네 가지 언어 모두 잘 확장되었으며, 일꾼들은 거의 모든 시간을 계산에 사용했습니다. 그러나 높은 수준의 조율이 필요한 작업에서는 차이가 극명해졌습니다. 병렬 실행을 위해 별도의 프로세스에 의지하는 Python은 프로세스 간에 데이터를 이동하는 데 상당한 시간을 소비했는데, 이는 다른 언어들에는 존재하지 않는 비용이었습니다. 하지만 연구진이 이 데이터 이동 비용을 제거했을 때도 Python은 여전히 병합 단계에서 어려움을 겪었으며, 이는 제한 요소가 언어의 오버헤드가 아니라 종종 알고리즘 자체에 있음을 증명했습니다. Julia와 Rust는 오버헤드에 낭비되는 시간이 거의 없었지만, 이들 역시 결과를 결합하는 데 걸리는 시간의 제한을 받았습니다. 독특한 스레딩 방식을 가진 Haskell은 병합 단계가 들이닥치기 전까지 일꾼들이 다른 언어들보다 더 오래 유용한 작업을 수행할 수 있도록 균형을 유지했습니다.

이 연구의 핵심 발견은 프로그램이 효율적으로 확장되는 지점이 고정되어 있지 않으며, 작업의 구체적인 조합과 일꾼의 수에 달려 있다는 것입니다. 연구진은 "병목 전이 지점(bottleneck transition points)"을 식별했는데, 이는 지연의 주된 원인이 한 유형의 활동에서 다른 유형으로 바뀌는 순간을 의미합니다. 정렬 작업의 경우, 이 전환은 종종 팀이 8명의 일원을 갖추었을 때 발생했습니다. 그전까지 일꾼들은 계산에 몰두했지만, 그 이후에는 주로 결과를 병합하기 위해 대기했습니다. 기하학적 탐색의 경우, 이 작업은 일꾼들이 더 오래 바쁘게 움직일 수 있게 해주었기 때문에 16명의 일원을 가질 때까지 전환이 늦게 나타났습니다. 연구는 개발자들이 단순히 가장 빠른 언어를 선택하고 잘 되기를 바라는 식의 접근을 해서는 안 된다고 제안합니다. 대신, 자신의 구체적인 문제의 구조를 살펴봐야 합니다. 만약 문제가 결과 결합을 많이 포함한다면 병목은 병합 과정이 될 것이며, 어떤 언어 최적화도 이를 해결할 수 없습니다. 만약 문제가 주로 계산 위주라면, 언어의 선택이 순수 속도 측면에서 더 중요해집니다.

연구진은 작업량의 특성을 초기에 살펴봄으로써 이러한 한계를 예측할 수 있는지 테스트했습니다. 그들은 작은 규모의 테스트 런을 통해 계산과 조율에 소비되는 시간의 비율을 측정함으로써, 더 많은 일꾼이 추가될 때 확장이 어디서 무너질지를 예측할 수 있다는 것을 발견했습니다. 이는 엔지니어들에게 실질적인 도구를 제공합니다. 어떤 언어를 사용할지 추측하는 대신, 소규모 테스트를 실행하여 시간의 붕괴를 측정하고, 자신의 특정 작업이 조율 비용으로 인해 벽에 부딪힐 가능성이 있는지 확인할 수 있습니다. 연구는 병렬 소프트웨어의 성능이 언어의 정적인 속성이 아니라, 작업의 구조와 언어의 런타임 시스템 사이의 동적인 상호작용이라고 결론짓습니다. 이러한 상호작용을 매핑함으로써, 연구진은 프로그램이 왜 느려지는지에 대해 언어의 메모리 관리 때문인지, 데이터 이동 비용 때문인지, 혹은 결과를 결합하는 데 따르는 내재적인 어려움 때문인지를 정확히 진단할 수 있는 방법을 제시했습니다. 이 접근 방식은 단순히 순위를 매기는 것을 넘어, 진정으로 확장 가능한 소프트웨어를 구축하는 방법에 대한 더 깊고 유용한 이해로 분야를 진전시킵니다.