모 러스트 빠돌이가 프갤에서 이상한 짓을 하므로

그에 현혹되지 말라고 LLM으로 글 작성했습니다.

📝 러스트 비동기 구현과 범용적 멀티플렉싱 활용에 대한 고찰

러스트(Rust) 언어를 사용하여 라이브러리를 개발할 때, 비동기 처리를 구현하는 방식은 향후 애플리케이션의 유연성, 이식성, 그리고 다른 언어와의 상호 운용성에 중대한 영향을 미칩니다. 특히, 러스트의 고유한 async/await구문 및 관련 생태계를 활용할 경우 발생할 수 있는 잠재적인 문제점과 범용적인 멀티플렉싱(Multiplexing) 방식을 채택하는 것의 이점을 학문적 관점에서 논의하고자 합니다.

1. 러스트 고유의 async/await 사용 시 발생 가능한 문제점

러스트의 async/await는 언어 수준에서 비동기 프로그래밍을 지원하는 강력한 기능입니다. 이는 상태 기계(State Machine) 변환을 통해 제어 흐름을 최적화하며, 제로 코스트 추상화(Zero-Cost Abstraction)를 제공하는 것을 목표로 합니다. 그러나 이 방식을 라이브러리 수준에서 채택할 경우 다음과 같은 문제가 발생할 수 있습니다.

1.1. 언어 고착화(Language Lock-in) 및 이식성 제약

• 생태계 의존성: 러스트의 async/await는 Future 트레이트 및 특정 비동기 런타임(예: Tokio, async-std)에 깊이 의존합니다. 라이브러리가 이러한 러스트 고유의 비동기 생태계에 종속되면, 해당 라이브러리를 러스트가 아닌 다른 언어(예: C, Python, Java)로 포팅(Porting)하거나 해당 언어의 바인딩(Binding)을 제작하는 것이 극히 어렵거나 불가능해집니다.
• ABI 비호환성: async 함수에 의해 생성되는 Future 객체는 컴파일러가 생성하는 복잡한 상태 기계 구조를 가지며, 이는 러스트의 안정적인 애플리케이션 이진 인터페이스(Application Binary Interface, ABI)의 범위를 벗어납니다. 따라서 FFI(Foreign Function Interface)를 통해 다른 언어에 노출하기 위한 범용적인 C ABI 호환성을 확보하기가 어렵습니다.

1.2. 타 언어 바인딩 제작 시 성능 하락 위험

• 컨텍스트 전환 부하: 러스트의 Future를 외부 언어 환경에서 실행하고 그 결과를 다시 러스트로 가져오는 과정은, 두 언어의 런타임 간에 컨텍스트를 빈번하게 전환해야 함을 의미합니다. 이러한 컨텍스트 전환 오버헤드는 성능 하락의 주요 요인이 될 수 있습니다.
• 비동기 런타임 통합 문제: 타 언어의 비동기 메커니즘(예: Python의 asyncio, Node.js의 이벤트 루프)과 러스트의 비동기 런타임을 통합하는 과정에서 복잡성이 증가하고, 두 시스템 간의 스케줄링 충돌이나 자원 관리 문제가 발생하여 예상치 못한 성능 저하를 초래할 수 있습니다.

2. 범용적 멀티플렉싱을 활용한 비동기 구현의 이점

위와 같은 문제점을 회피하고 라이브러리의 범용성을 높이기 위해서는, 운영체제(OS) 수준에서 널리 지원되는 범용적인 I/O 멀티플렉싱 메커니즘을 활용하는 것이 합리적입니다.

2.1. 범용적 I/O 멀티플렉싱 메커니즘

범용적 멀티플렉싱은 단일 스레드 또는 제한된 스레드 풀 내에서 다수의 I/O 작업을 효율적으로 처리할 수 있도록 설계된 OS 기능을 의미합니다. 주요 메커니즘은 다음과 같습니다.

• 유닉스 계열: epoll (Linux), kqueue (FreeBSD, macOS)
• 윈도우 계열: IOCP (Input/Output Completion Port)

2.2. 범용적 멀티플렉싱 활용의 이점

• OS 및 언어 독립성: 이러한 메커니즘은 OS 커널에 의해 표준적으로 제공되며, 대부분의 현대 프로그래밍 언어는 이들에 접근할 수 있는 표준 라이브러리 또는 외부 라이브러리 바인딩을 제공합니다. 따라서 라이브러리가 특정 언어의 비동기 생태계가 아닌, OS의 저수준(Low-level) I/O 인터페이스에 의존하게 되어 이식성이 극대화됩니다. 
• FFI 호환성 용이성: 라이브러리의 핵심 로직을 동기적인(Synchronous) 인터페이스로 외부에 노출하고, 내부적으로만 비동기 멀티플렉싱을 사용하여 I/O 효율성을 달성할 수 있습니다. 이는 FFI를 통한 C ABI 노출을 용이하게 하여 타 언어 바인딩 제작 시 성능 저하를 최소화합니다. 외부 언어는 동기 함수를 호출하는 것처럼 보이지만, 내부 러스트 라이브러리는 효율적인 I/O 대기(Waiting)를 수행합니다.
• 유연한 통합: 타 언어 애플리케이션이 이미 자체적인 이벤트 루프나 비동기 런타임을 가지고 있는 경우, 러스트 라이브러리는 외부 환경에 I/O 디스크립터(Descriptor)나 이벤트 핸들을 제공하여 외부 이벤트 루프에 통합될 수 있습니다. 이는 중복된 런타임 운영을 피하고 자원의 효율적인 공유를 가능하게 합니다.

3. 결론

러스트로 고성능 라이브러리를 개발할 때, 최종 사용자 애플리케이션의 유연성과 이식성을 최우선 목표로 설정해야 합니다. 러스트의 고유한 async/await 생태계는 러스트 애플리케이션 내부에서는 최적의 성능을 제공할 수 있으나, 라이브러리를 타 언어에 제공할 경우 언어 고착화 및 심각한 성능 저하를 유발할 위험이 높습니다.

따라서, 라이브러리 개발 시에는 러스트의 비동기 프리미티브(Primitive) 대신 OS 수준의 범용적인 I/O 멀티플렉싱(예: epoll, kqueue, IOCP)을 활용하여 내부적인 비동기 I/O 효율성을 확보하고, 외부 인터페이스는 C ABI 호환성을 갖는 동기 함수 형태로 노출하는 전략이 학문적, 공학적 관점에서 가장 바람직하다고 판단됩니다.