AI 시대에 Rust가 주목받는 이유와 Python 연동 구조

Python으로 만든 AI 서비스가 데이터 전처리에서 느려지는 이유

거대 언어 모델(LLM)을 호출하는 웹 서버나 에이전트를 Python으로 만들다 보면 의외의 지점에서 속도 저하를 겪게 됩니다. 그래픽카드(GPU)에서 돌아가는 모델 추론 자체는 빠른데, 모델에 넣을 긴 문서를 토큰 단위로 쪼개거나 수천 건의 JSON 응답 형식을 검사하는 앞뒤 단계에서 CPU 사용량이 100%로 치솟으며 전체 응답이 밀리는 현상입니다.

실제로 Python 생태계에서 매일 쓰이는 핵심 AI 도구들을 열어 보면 무거운 작업은 이미 다른 언어가 처리하고 있습니다. 오픈AI의 토크나이저인 tiktoken, 허깅페이스의 tokenizers와 safetensors, 데이터 검증 라이브러리인 Pydantic v2, 그리고 초고속 패키지 관리자인 uv까지 모두 내부 핵심 엔진이 Rust로 작성되어 있습니다.

이 글에서는 Rust가 어떤 원리로 C·C++ 수준의 빠른 속도와 메모리 안전성을 동시에 달성하는지 기본 개념부터 쉽게 짚어 봅니다. 나아가 AI 서비스 인프라와 AI 코딩 에이전트 환경에서 왜 Rust가 핵심 언어로 자리 잡았는지, 그리고 기존 Python 프로젝트에서는 어떤 기준으로 도입해야 하는지 차례대로 살펴봅니다.

실행 전에 기계어로 번역하고 메모리 규칙을 검사하는 Rust

Rust는 모질라(Mozilla) 연구소에서 출발해 2015년 5월 첫 정식 버전(1.0)이 공개된 시스템 프로그래밍 언어입니다. Rust의 특징을 한 문장으로 요약하면, C나 C++만큼 빠르게 실행되면서도 프로그램이 죽거나 해킹 통로가 되는 메모리 실수를 실행 전에 미리 막아 주는 언어입니다.

속도 차이는 코드를 실행하는 방식에서 나옵니다. Python은 프로그램을 실행할 때 인터프리터가 코드를 한 줄씩 읽어가며 해석하기 때문에 작성하기는 편하지만 반복 계산에서 속도가 느립니다. 반면 C·C++와 Rust는 프로그램을 실행하기 전에 컴파일러가 전체 코드를 컴퓨터가 바로 읽을 수 있는 기계어로 미리 번역해 둡니다.

문제는 데이터를 담는 메모리 공간을 다 쓰고 난 뒤에 발생합니다. 스택과 힙 메모리 나눠 보기에서 다루었듯, 크기가 유동적인 데이터는 힙(Heap) 메모리에 올라갑니다. 지금까지의 언어들은 이 힙 메모리를 관리하기 위해 두 가지 방식 중 하나를 택했습니다.

• 수동 관리(C·C++): 개발자가 직접 메모리를 빌리고 반납하는 코드를 적습니다. 별도의 관리 비용이 없어 매우 빠르지만, 이미 반납한 메모리를 다시 읽거나(Use-After-Free) 정해진 크기를 넘겨 쓰는(Buffer Overflow) 실수가 생겨도 컴파일러가 모두 잡아내지 못합니다.
• 자동 수거(Python·Java·Go): 실행 중에 가비지 컬렉터(Garbage Collector)가 주기적으로 돌아다니며 더 이상 쓰지 않는 메모리를 찾아 치웁니다. 메모리 실수는 줄어들지만, 청소기가 도는 순간 프로그램 응답이 미세하게 멈추거나 추가 메모리를 소모합니다.

Rust는 이 두 가지 대신 소유권(Ownership)이라는 세 번째 방식을 사용합니다. 규칙은 단순합니다. 메모리 위의 모든 값에는 주인 역할을 하는 변수가 단 하나만 존재하며, 그 변수가 속한 코드 블록({})이 끝나는 정확한 줄에 컴파일러가 메모리 반납 코드를 자동으로 끼워 넣습니다.

다른 함수가 값을 잠시 읽거나 수정해야 할 때는 소유권을 넘기지 않고 참조만 빌려줍니다. 이때 컴파일러 내부의 빌려주기 검사기(Borrow Checker)가 값을 빌려간 기간과 수정 여부를 추적합니다. 만약 한쪽에서 값을 고치는 동시에 다른 쪽에서 읽으려 하거나, 이미 사라진 값을 가리키려 하면 실행 파일을 아예 만들지 않고 에러 위치를 알려줍니다. 덕분에 가비지 컬렉터 없이도 메모리 안전성을 지킬 수 있습니다.

지시는 Python이 내리고 무거운 계산은 Rust가 맡는 분업

AI 인프라가 Rust를 적극적으로 채택한다고 해서 기존 Python 코드를 모두 버리고 처음부터 다시 짜야 하는 것은 아닙니다. 현대 AI 소프트웨어 스택에서 Python과 Rust는 서로를 대체하는 경쟁자가 아니라 역할을 나눈 파트너로 동작합니다.

Python은 연구자와 개발자가 모델 구조를 설계하고 외부 API나 에이전트 흐름을 조립하는 조종석 역할을 맡습니다. 그 아래에서 수백만 개의 텍스트 조각을 자르고, 텐서 파일의 안전성을 검사하고, 대규모 스키마를 검증하는 엔진 역할은 C·C++와 Rust가 담당합니다.

이 두 언어를 매끄럽게 이어 주는 대표적인 다리가 PyO3입니다. PyO3와 빌드 도구인 maturin을 사용하면 Rust로 작성한 함수를 일반 Python 확장 모듈로 컴파일할 수 있습니다. 사용하는 쪽에서는 기존 코드의 import 문 한 줄만 바꾸면 되므로, Python의 편리한 문법을 그대로 유지하면서 병목 구간의 실행 속도만 끌어올릴 수 있습니다.

현재 AI 및 데이터 생태계에서 Python 겉모습 아래 Rust 엔진을 결합해 쓰는 대표적인 오픈소스 도구는 다음과 같습니다.

AI 시대에 Rust가 더욱 적합해진 세 가지 이유

단순히 실행 속도가 빠르다는 점만으로는 최근 운영체제 커널과 AI 인프라 전반에서 일어나는 변화를 모두 설명하기 어렵습니다. 지금 Rust가 주목받는 배경에는 보안 비용, 멀티스레드 병렬 처리, 그리고 AI 코딩 에이전트의 등장이라는 세 가지 흐름이 맞물려 있습니다.

1. 대규모 시스템의 메모리 보안 취약점 감소

시스템 소프트웨어에서 발생하는 심각한 보안 사고의 상당수는 잘못된 메모리 접근에서 비롯됩니다. 구글 보안 블로그가 2025년 11월 공개한 안드로이드 보고서(Rust in Android: move fast and fix things)는 신규 코드를 Rust 같은 메모리 안전 언어로 작성했을 때의 효과를 구체적인 수치로 보여 줍니다.

해당 보고서에 따르면 안드로이드에서 메모리 안전 취약점이 전체 취약점 중 차지하는 비중은 2025년 처음으로 20% 아래로 내려갔습니다. 과거 C와 C++ 코드에서는 코드 100만 줄(MLOC)당 약 1,000건의 메모리 안전 취약점이 발견된 반면, 약 500만 줄 규모로 늘어난 안드로이드 Rust 코드에서는 취약점 밀도가 1,000분의 1 이하 수준으로 낮아졌습니다. 실행 중에 터진 버그를 사후에 추적해 패치하는 대신, 컴파일 단계에서 미리 걸러낸 덕분에 코드 리뷰 시간과 배포 후 롤백 비율까지 함께 줄어들었습니다.

2. 전역 인터프리터 락(GIL) 한계 돌파와 안전한 병렬 처리

AI 서빙 서버나 에이전트 런타임은 동시에 들어오는 수십 개의 요청을 지체 없이 병렬로 처리해야 합니다. 프로세스와 스레드 구분하기에서 살펴보았듯, 표준 Python(CPython)에는 전역 인터프리터 락(GIL; Global Interpreter Lock)이라는 잠금 장치가 있습니다. 한 프로세스 안에서 스레드를 여러 개 띄우더라도 한 순간에 단 하나의 스레드만 Python 바이트코드를 실행할 수 있도록 막아 두어, 순수 Python 계산 코드는 CPU 코어가 많아도 처리량이 잘 늘어나지 않습니다.

반면 PyO3로 연결한 Rust 함수 내부에서는 무거운 계산을 수행하는 동안 Python의 GIL을 잠시 풀어 둘 수 있습니다(py.allow_threads). 여러 스레드가 잠금 대기 없이 모든 CPU 코어를 동시에 사용하여 계산을 끝낸 뒤 결과만 Python으로 돌려줍니다. 나아가 스레드끼리 데이터를 주고받을 때 발생할 수 있는 경쟁 상태(Data Race)도 Rust의 타입 시스템(Send와 Sync 트레이트)이 컴파일 시점에 미리 검사하여 차단합니다.

[참고] 자유 스레딩 Python(Free-threaded Python)과의 관계

Python 3.13과 3.14부터 실험적으로 도입된 자유 스레딩(3.14t 등) 모드를 사용하면 GIL을 끌 수 있습니다. 다만 GIL이 사라지면 여러 스레드가 동시에 같은 변수를 수정할 때 발생하는 경쟁 상태를 개발자가 직접 막아야 하므로, 스레드 안전성을 컴파일러가 강제하는 Rust 확장 모듈의 가치는 여전히 높습니다.

3. AI 코딩 에이전트를 잡아주는 컴파일러 가드레일

가장 결정적인 변화는 사람이 아닌 AI가 코드를 작성하기 시작했다는 점입니다. 과거에는 수십만 줄의 C나 Python 코드를 Rust로 옮기는 인건비와 학습 장벽이 매우 높았습니다. 하지만 최근에는 대형 언어 모델(LLM)과 코딩 에이전트에게 기존 코드를 주고 변환을 맡기는 시도가 빠르게 확산되고 있습니다. 미국 국방고등연구계획국(DARPA)이 2024년 7월 발족한 TRACTOR 프로그램 역시 LLM과 정적·동적 분석 기술을 결합해 오래된 C 코드를 안전한 Rust 코드로 자동 변환하는 것을 목표로 삼고 있습니다.

코드 작성 비용이 낮아지면 남는 과제는 "AI가 작성한 수천 줄의 코드를 어떻게 검증하고 믿을 것인가"입니다. AI 에이전트가 C++나 동적 언어로 코드를 생성하면 문법만 맞을 경우 잘못된 메모리 참조나 스레드 충돌 위험이 숨어 있어도 일단 빌드가 통과됩니다.

반면 Rust 환경에서는 컴파일러가 엄격한 출고 전 검사관 역할을 맡습니다. AI 에이전트가 소유권 규칙이나 스레드 안전 규칙을 어긴 코드를 작성하면 rustc 컴파일러가 빌드를 거부하고, 어느 줄에서 어떤 규칙이 깨졌는지 구조화된 에러 메시지로 즉시 돌려줍니다. AI 에이전트 루프 관점에서 보면 컴파일러의 에러 출력 자체가 에이전트가 스스로 코드를 고치게 만드는 정밀한 피드백 신호(Guardrail)가 됩니다.

AI 코딩 에이전트를 활용해 Python의 병목 구간을 Rust로 옮길 때 거치게 되는 3단계 검증 구조는 다음 그림과 같습니다.

그림: AI 에이전트가 Rust 컴파일러와 테스트·측정 피드백을 거쳐 모듈을 완성하는 흐름

컴파일러가 1차로 메모리와 스레드 안전성을 보장하고, 기능 테스트가 2차로 계산 결과의 일치 여부를 확인하며, 다중 스레드 성능 측정이 3차로 실제 속도 향상을 검증해 에이전트에게 피드백을 돌려주는 구조입니다.

작은 예제로 보는 스레드 안전 검사와 병렬 카운터

Rust 컴파일러가 실행 전에 어떻게 스레드 사고를 막아 주는지 작은 코드로 확인해 봅니다. 아래 예제는 별도의 로컬 설치 없이도 Rust 공식 플레이그라운드에서 그대로 붙여 넣어 실행할 수 있으며, 안정 버전(stable, 2021 에디션) 컴파일러에서 동작을 검증했습니다.

먼저 단일 스레드 전용 참조 타입인 Rc<i32>를 다른 스레드로 넘기려 시도하는 잘못된 코드입니다.

use std::rc::Rc;
use std::thread;
 
fn main() {
    let counter = Rc::new(0);
    let shared = Rc::clone(&counter);
 
    // 단일 스레드용 참조(Rc)를 새 스레드로 넘기면 컴파일러가 빌드를 차단함
    thread::spawn(move || {
        println!("{}", shared);
    });
}

이 코드를 빌드하면 프로그램이 실행되기 전에 다음과 같은 컴파일 에러가 출력됩니다.

error[E0277]: `Rc<i32>` cannot be sent between threads safely
 --> src/main.rs:9:19
  |
9 |       thread::spawn(move || {
  |  _____-------------_^
  | |     |
  | |     required by a bound introduced by this call
10| |         println!("{}", shared);
11| |     });
  | |_____^ `Rc<i32>` cannot be sent between threads safely
  |
  = help: within `{closure@src/main.rs:9:19: 9:26}`, the trait `Send` is not implemented for `Rc<i32>`

Rc<i32>는 여러 스레드가 동시에 접근할 때 참조 횟수가 꼬일 수 있는 타입입니다. 다른 언어였다면 실행 중에 간헐적으로 숫자가 틀리거나 메모리가 깨졌겠지만, Rust 컴파일러는 스레드 간 전달 자격(Send 트레이트)이 없다며 E0277 에러로 빌드를 즉시 멈춥니다.

이번에는 컴파일러의 안내에 따라 스레드 간 안전한 공유를 지원하는 원자적 참조 카운터(Arc)와 상호 배제 잠금(Mutex)으로 바꾼 뒤, 스레드 4개가 각각 10만 번씩 숫자를 더하는 코드입니다.

use std::sync::{Arc, Mutex};
use std::thread;
 
fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];
 
    for _ in 0..4 {
        let shared = Arc::clone(&counter);
        handles.push(thread::spawn(move || {
            for _ in 0..100_000 {
                // 잠금을 획득한 스레드만 안전하게 값을 1씩 증가시킴
                let mut num = shared.lock().unwrap();
                *num += 1;
            }
        }));
    }
 
    for h in handles {
        h.join().unwrap();
    }
 
    println!("최종 카운터 값: {}", *counter.lock().unwrap());
}

빌드 후 실행하면 몇 번을 반복해도 데이터 유실 없이 정확한 합계가 출력됩니다.

최종 카운터 값: 400000

컴파일러가 막지 못하는 한계와 실무 도입 기준 3가지

Rust 컴파일러가 강력한 안전망을 제공하지만, 컴파일을 통과했다고 해서 모든 문제가 끝나는 것은 아닙니다. 특히 AI 에이전트에게 코드 변환을 맡길 때는 컴파일러가 검사하는 범위와 사람이 별도로 검증해야 할 범위를 명확히 구분해야 합니다.

• 논리적 결과 불일치: 컴파일러는 메모리 규칙과 타입이 맞는지만 검사할 뿐, 토큰 분할 규칙이나 수학 공식이 원래 Python 코드와 똑같이 동작하는지는 알지 못합니다.
• 과도한 잠금으로 인한 속도 저하: 스레드 안전 규칙을 통과하기 위해 공유 캐시나 사전에 잠금(Mutex나 RwLock)을 걸 때, 단어 조각 하나를 조회할 때마다 잠금을 걸고 풀도록 짜면 스레드들이 줄을 서서 기다리느라 오히려 기존 Python 코드보다 느려질 수 있습니다.

따라서 현업에서 Python 코드의 일부를 Rust 모듈로 옮기거나 AI 에이전트에게 변환을 지시할 때는 다음 세 가지 기준을 순서대로 적용하는 것이 안전합니다.

1. 순수 Python 반복문부터 골라내기: 이미 NumPy, PyTorch, 또는 C 라이브러리로 돌아가는 행렬·벡터 연산은 Rust로 다시 작성해도 속도 차이가 크지 않거나 초기 구현에서 오히려 느려질 수 있습니다. 프로파일러로 확인했을 때 순수 Python의 for 반복문이나 문자열 처리, 복잡한 조건 분기가 CPU 시간을 대부분 차지하는 함수부터 분리합니다.
2. 변환 전에 입출력 일치 테스트 고정하기: 코드를 옮기기 전에 기존 Python 함수가 다양한 입력(빈 문자열, 특수문자, 대용량 텍스트 등)에서 내놓는 결과를 정답으로 기록한 자동화 테스트를 먼저 만듭니다. 새 모듈은 기존 테스트를 100% 그대로 통과해야 합니다.
3. 단일 스레드와 다중 스레드 처리량을 함께 재기: 테스트를 통과한 뒤에는 실제 서비스 크기와 비슷한 입력으로 단일 스레드 속도와 여러 스레드가 한 인스턴스를 공유할 때의 속도를 각각 측정합니다. 다중 스레드에서 속도가 떨어진다면 잠금을 문서나 배치 단위로 한 번만 걸도록 측정 수치를 바탕으로 구조를 다듬습니다.

참고 문서

• Rust 1.0 공식 발표 (Rust Blog, 2015-05-15)
• The Rust Programming Language — 소유권(What Is Ownership?)
• The Rust Programming Language — Send와 Sync를 통한 동시성 확장
• Google Security Blog — Rust in Android: move fast and fix things (2025-11-13)
• DARPA — Eliminating Memory Safety Vulnerabilities Once and For All (TRACTOR, 2024-07-31)
• PyO3 공식 가이드 — Rust bindings for Python
• Hugging Face Tokenizers 공식 저장소
• Pydantic Core (pydantic-core) 공식 저장소