소프트웨어가 느린 이유는 느린 언어가 아니라 나쁜 설계 때문이다

블로그 글 본문 대부분을 옮겼어요. 끝부분 일부 사례와 각주는 생략했어요.

주장

AI가 소프트웨어를 더 빠른 언어로 다시 써서 빠르게 만들 거라는 말이 많지만, 대체로 사실이 아니래요. 대부분 프로그램은 C나 Rust로 다시 써도 의미 있게 빨라지지 않아요.

C가 Python보다 50배 빠를 수 있는데 왜 그럴까요? 글쓴이의 답은 두 가지예요.

1. 소프트웨어 성능은 보통 언어 속도가 아니라 I/O가 좌우해요.
2. 언어 속도가 중요한 곳에서는 느린 언어에도 이미 C 수준 속도를 내는 인기 라이브러리가 있어요.

I/O에 묶인 프로그램

데이터베이스를 쓰는 단순한 CRUD 웹사이트를 생각해 보래요. 요청 시간의 50%가 현재 사용자, 요청한 레코드, 멤버십·설정을 가져오는 DB 쿼리라면, C로 다시 써도 나머지 50%만 빨라질 수 있어요. 아무리 잘해도 2배, 실제로는 1.5배에 가까울 거래요.

대부분 실제 프로그램은 이렇게 데이터 입출력을 기다리는 데 시간을 써요. 외부 API, 디스크 읽기·쓰기도 마찬가지예요. curl 코드를 100배 빠르게 해도 네트워크를 기다리느라 차이를 못 느낄 거래요.

CPU를 많이 쓰는 일은요?

위키가 마크다운을 HTML로 바꾸는 일처럼 CPU를 쓰는 작업은 빠른 언어로 바꾸면 크게 빨라지는 게 맞아요. 그래서 이런 앱은 이미 cmark-gfm 같은 빠른 라이브러리를 불러 써요. Python이 느린 언어인데도 머신러닝과 수학에서 경쟁력 있는 이유가 이거래요.

느린 언어로 CPU 작업을 많이 하는 프로그램도 있지만, 대개 중요하지 않은 프로그램이에요. 중요했다면 AI 이전에 누군가 이미 최적화했을 테니까요. 물론 예외는 있어요. Actual Computer가 최근 tiktoken을 어셈블리로 다시 써서 상당한 속도 향상을 얻었대요. 하지만 이런 식으로 분야를 뒤집지는 못한다고 봐요.

설계가 성능을 정해요

글쓴이는 대부분 소프트웨어가 가능한 것보다 훨씬 느리다는 데는 동의하고, 그걸 크게 빠르게 할 여지도 낙관해요. 다만 그 속도 향상은 더 빠른 언어로 다시 쓰기가 아니라 프로그램 재설계에서 올 거래요.

Bryan Cantrill의 2018년 사례가 그 근거예요. C 프로그램을 Rust로 옮기려다 정교하게 최적화된 C 설계가 Rust 빌림 검사기와 맞지 않아 포기하고, Rust로 순진하게 다시 짰더니 20% 느려질 거란 예상과 달리 30% 더 빨랐대요. 이유는 Rust가 이진 탐색 트리 대신 캐시 효율이 좋은 B-트리를 쓰기 때문이었어요. CPU 중심 작업에서도, 빠른 C를 아주 잘 쓰는 사람의 손에서도, 성능은 자료구조와 설계가 좌우했다는 거예요.