AI 에이전트에게 프로그램을 C나 Rust로 다시 쓰게 하면 소프트웨어가 빨라진다는 기대와 달리, 언어를 바꾸는 것만으로 의미 있는 속도 향상을 얻을 수 있는 경우는 제한적이다. 대부분의 프로그램은 언어 실행 속도보다 데이터 입출력이나 작업 설계의 영향을 더 크게 받는다.
데이터베이스를 사용하는 CRUD 웹사이트에서는 요청 처리 시간의 50%가 데이터베이스 조회에 쓰일 수 있다. 나머지 절반을 C로 다시 써서 두 배 빨라지더라도 전체 요청 시간은 최대 절반가량 줄어드는 데 그친다. 실제로는 약 1.5배 향상에 가까울 수 있다. 이는 입출력 대기 시간이 큰 프로그램에 아믈달의 법칙이 적용되는 사례다. 데이터베이스뿐 아니라 외부 API나 디스크 읽기·쓰기 때문에 기다리는 프로그램도 많다. 예를 들어 curl의 코드를 100배 빠르게 만들어도 네트워크를 기다리는 시간이 대부분이라면 차이를 체감하기 어렵다.
CPU 연산이 많은 작업도 반드시 프로그램 전체를 빠른 언어로 옮겨야 하는 것은 아니다. 위키의 마크다운 변환에는 cmark-gfm 같은 라이브러리를 쓸 수 있고, 파이썬도 PyTorch와 TensorFlow 같은 라이브러리를 통해 C 코드에 연산을 맡길 수 있다. 파이썬 프로그램이 실행 시간의 80%를 GPU 행렬 곱셈에 쓴다면, 해당 연산은 이미 최적화된 C나 어셈블리 코드에서 이뤄지므로 C로 다시 써도 빨라질 가능성은 낮다.
물론 느린 언어로 CPU 연산을 많이 수행하는 프로그램에는 최적화 여지가 있을 수 있다. 실제로 Actual Computer는 tiktoken을 어셈블리로 다시 작성해 상당한 속도 향상을 제공했다고 밝혔다. 이들은 tiktoken보다 4~23배 빠르다고 주장했으며, 글쓴이는 자신의 노트북에서 약 5배 빠른 결과를 봤다고 설명한다. 다만 글쓴이는 이 향상이 Rust와 파이썬 바인딩의 고유한 느린 속도 때문이라기보다 정규식 의존성을 없앤 재설계에서 비롯됐을 가능성이 있다고 덧붙인다. 토큰화는 추론에 드는 시간의 일부이므로, 이 최적화만으로 컴퓨팅 분야 전체를 바꾸기는 어렵다는 설명이다.
속도를 크게 높이는 방법은 대개 프로그램이 하는 일을 다시 설계하는 것이다. 2018년 브라이언 캔트릴(Bryan Cantrill)은 C 프로그램을 Rust로 옮기려다 기존의 세밀한 최적화 설계가 Rust의 빌림 검사기와 맞지 않아, 단순한 방식으로 새로 작성했다. 20% 이상 느려질 것으로 예상했지만 결과는 30% 빨랐다. 캔트릴의 설명에 따르면, Rust가 이진 탐색 트리보다 캐시 효율이 높은 B-트리를 선호한 점이 한 이유였다. 두 언어의 상대 성능을 다룬 후속 글도 참고할 수 있다.
글에서 제시하는 설계 변경 사례는 느린 작업을 캐시하거나 비동기로 처리하는 것, 순차 작업을 병렬화하는 것, 여러 SQL 질의를 하나로 합쳐 N+1 질의 문제를 해결하는 것, 느린 질의를 개선하는 것, 현재 페이지에 필요하지 않은 데이터 조회를 생략하는 것이다. 큰 작업을 나눠 병렬 처리하는 방법으로는 HTTP 범위 요청이 예시로 언급된다.
따라서 AI 에이전트에게 속도 개선을 맡길 때는 처음부터 다른 언어로 다시 쓰게 하기보다, 먼저 프로그램을 프로파일링해 병목을 찾고 작업량을 줄이는 재설계 방안을 제안하도록 하는 편이 낫다는 주장이다. 병목이 실제로 CPU 연산에 있고 작업량 자체를 줄일 수 없는 드문 경우에는 해당 부분만 더 빠른 언어로 작성하는 것이 도움이 될 수 있다. 이 글은 다른 언어로 옮기는 일이 이식성·효율성·유지보수성 측면에서 유용할 수는 있지만, 순수한 실행 속도만을 원한다면 프로그램 설계에 집중하는 편이 낫다고 결론짓는다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요