왜 kt cloud는 FastAPI 대신 Robyn을 선택했을까?

 

[비교분석] FastAPI는 충분히 빠르지 않다? Robyn과의 성능 차이 직접 비교

 

 

kt cloud에서 FastApi가 아닌 Robyn이라는 웹 프레임워크를 도입했다고 해서 찾아보게 되었습니다.

 

해당 글의 문단별로 내용을 기록하고, 이에 대한 제 생각을 작성해보고자 합니다.

Robyn이란?

Python 문법을 유지하면서 Rust 런타임을 사용하는 고성능 웹 프레임워크 라고 합니다.

왜 Fast API가 아닌가?

이전에는 Python의 웹 개발에 Django나 Flask가 주로 사용되었고, 최근에는 FastAPI를 주로 사용하고 있습니다.

 

FastAPI가 아무리 비동기로 동작한다고 하더라도 Python 인터프리터 위에서 구동되다보니, 요청의 헤더를 검사하고 페이로드를 검증하는 등 CPU 연산을 수행하는데, 많은 코어를 할당하더라도 한 번에 하나의 스레드만 Python 바이트 코드를 실행할 수 있어, 고부하 상황에서 응답 시간이 튀는 현상이 있었다고 합니다.

 

그래서, Rust라는 고성능 엔진에 Python이라는 편리한 인터페이스를 씌운 Robyn이라는 웹프레임워크를 선택하게 되었다고 합니다.

개인적인 생각

Rust에는 Axum이라는 빠른 웹 라이브러리가 존재합니다.

 

Axum은 Rust로만 이루어져 있어, Robyn 라이브러리보다는 성능이 뛰어납니다.

 

그러나, Axum은 Rust의 라이브러리로만 작동되어, Python에서는 사용할 수 없습니다.

 

물론, Rust를 학습하여 이를 활용하여 개발을 하는 방식이 더 좋을수는 있지만, kt cloud의 현재 상황에서는 python 문법을 유지한채, 성능을 향상시키는 방법에 대해서 생각했던거 같습니다.

 

TypeScript의 7.0 버전의 컴파일러를 Rust가 아닌 Golang으로 포팅한것과 마찬가지의 이유라고 생각합니다.

 

https://blog.gaerae.com/2025/03/a-10x-faster-typescript-go.html

아키텍쳐 구현

현재 vLLM과 같은 서빙 생태계의 주류 엔진들이 FastAPI를 내장하여 API 기능을 제공한다는 점을 보아, FastAPI가 Python 생태계에서 견고한 신뢰성과 대중성을 얻고 있습니다.

 

하지만, FastAPI가 아닌 Robyn이라는 다소 과감한 선택지를 택한 이유는 '성능에 대한 집착' 때문입니다.

 

추론 엔진이 비즈니스 로직과 섞이지 않고, 오직 연산에만 집중할 수 있도록 트랙픽을 처리하는 앞단 API 서버만큼은 압도적인 처리량을 보장해야 한다 판단했습니다.

• 백엔드 추론 엔진 레이어가 이미 Python 프레임워크 기반으로 동작하고 있고, API 서버 레이어도 Python 스택을 사용할 경우, 자원 관리 측면에서 Python 인터프리터의 제약이 양쪽 레이어에 중첩될 위험이 있습니다.
• 입구에 아예 다른 엔진을 배치함으로써, 네트워크 I/O 핸들링과 프로토콜 파싱 단계에서의 부하를 Python 레이어로부터 완전히 독립시켰습니다.

Robyn의 가장 큰 장점은 Rust의 강력한 성능을 Python의 익숙한 문법으로 누릴 수 있어, FastAPI나 Flask를 사용해 본 개발자라면 별도의 학습 곡선 없이 즉시 적용할 수 있는 수준이라는 점입니다.

 

Robyn은 네트워크 응답을 구성하는 저수준 작업들을 Rust 레이어에서 최적화하여 처리하므로, 개발자는 복잡한 튜닝 없이도 프레임워크가 제공하는 '기본적인 고성능'을 그대로 서비스에 녹여낼 수 있습니다.

개인적인 생각

LLM 추론 엔진의 대부분이 vLLM이고, 이는 Python으로 이루어져 있어, 앞단 API 또한 Python이라면 성능적인 측면에서 매우 느릴 것이라고 생각을 하고 있었는데, kt cloud에서 이를 해결하기 위하여 Robyn을 도입하였다고 생각합니다.

 

현재 vLLM의 느린 시작 시간과 무거운 의존성과 GC가 문제가 된다는 것을 인지한 어느 한 개발자가 Rust로 구성한 rvLLM이라는 것을 개발한 것을 본적이 있습니다.

 

하지만 이 또한, vLLM 생태계를 대체하기에는 오래 걸릴것이라고 생각합니다.

 

앞서 이야기한것처럼, 기존 개발 상태에서 크게 벗어나지 않으면서 성능을 올릴 수 있다면 최고의 판단이라고 생각합니다. 물론, 제가 알지 못하는 수고스러움이 들지도 모릅니다.

FastAPI vs Robyn 벤치마크

백엔드 서버를 FastAPI에서 Robyn으로 직접 변경해가며 실직적인 성능 변화를 확인했습니다.

동시 접속자 50명 가정

• CPU: Intel Xeon (Cascadelake) - 16 Cores
• Memory: 90GB RAM

초당 처리량(Requests Per Second, RPS)에서 Robyn은 763.28 RPS, FastAPI는 651.02 RPS로 약 17.2% 향상된 성능을 보여줬습니다.

 

FastAPI가 Python의 이벤트 루프 제약 내에서 자원을 분배하며 병목을 형성할 때, Robyn은 각 코어의 성능을 최대한 활용하며 더 많은 동시 요청을 안정적으로 소화했습니다.

 

서비스 품질을 결정짓는 지연 시간(Latency)에서 Robyn은 96.4ms, FastAPI는 286.4ms로 3배나 더 빠른 안정성을 입증했습니다.

지표	Robyn	FastAPI	개선율
처리량(Requests/sec)	763.28	651.02	+17.2%
상위 99% 지연(P99)	96.4ms	286.4ms	+197%
최악의 응답 시간 (MAX)	143.4ms	674.8ms	+370%

고부하 상황에서의 안정성 비교

별도의 비즈니스 로직 없이, 간단한 JSON 바디만 즉시 응답하는 조건으로 1,000명의 가상 유저가 동시에 접근하는 테스트를 진행하였습니다.

지표	Robyn	FastAPI	결과 분석
평균 응답 시간 (Avg)	0.1862s	0.1141s	FastAPI가 수치상 우위
상위 95% 지연(P95)	0.2775s	0.9216s	Robyn이 3.3배 안정적
상위 99% 지연(P99)	0.3432s	1.7410s	Robyn이 5.1배 안정적

 

FastAPI가 하위 50%까지는 0.02초로 매우 빠르지만, 상위로 갈수록 지연 시간이 폭발적으로 증가합니다.

• P90 (0.13s) → P95 (0.92s) → P99 (1.74s)

동시 접속자가 1,000명에 달하자, Python의 단일 이벤트 루프가 병목 현상을 일으켜, 10% 이상의 유저는 1초가 넘는 지연을 경험하게 됩니다. 반면, Robyn은 처음부터 끝까지 응답 시간이 매우 촘촘하여 보여 있습니다.

• P90 (0.20s) → P95 (0.27s) → P99 (0.34s)

평균은 FastAPI보다 조금 느려보일 수 있으나, 전체 사용자의 99%가 0.3초 내에 응답을 받아 최악의 상황에서도 서비스 품질이 일정하게 유지됩니다.

시스템 한계돌파 테스트

"터지지 않고 버틸 수 있는가"를 확인하기 위해 12_000명의 동시 접속자가 한번에 몰리는 테스트를 진행했습니다.

지표	Robyn	FastAPI	결과 분석
성공한 요청 수	12,000 / 12,000	7,809 / 12,000	FastAPI의 약 35% 실패
에러 발생	0건	4,191건 (EOF, Reset)	FastAPI 서버 오류

결정적 차이 : 성능보다 중요한건 생존

초당 처리량(RPS)이나 지연 시간을 비교하는 것은 의미 없고, 서버가 살아남았느냐가 핵심입니다.

 

 

동시 접속자가 12,000명에 달하자 FastAPI는 파이썬 이벤트 루프가 네트워크 소켓을 제때 처리하지 못해 OS레벨에서 강제로 연결을 끝어버려 EOF 에러와 다수의 COnnection Reset을 내뱉어, 전체 요청의 1/3이 유실된 서비스 장애 상태입니다.

 

반면, Robyn은 12,000건의 요청 중 단 한건의 에러도 없이 100% 성공시켰습니다.

 

응답 시간은 평균 1.2초대로 늘어났지만, 이는 서버가 죽지 않고 모든 대기열을 끝까지 처리했다는 증거입니다.

엔지니어링 인사이트

벤치마크 결과가 시사하는 바는 실제 서비스 운영 환경에서 가장 위협적인 요소는 평소의 속도가 아니라, 고부하 상황에서 간헐적으로 발생하는 지연입니다.

• Tail Latency의 압도적 방어력: 테스트 결과, FastAPI는 부하가 임계치에 도달할 때 P99 지연 시간이 평균 대비 무려 15배나 튀어버리는 불안정성을 보였던 반면, Robyn은 1.8배 수준의 매우 타이트한 방어선을 유지했습니다. 이는 사용자에게 항상 일정한 응답성을 보장해야 하는 서비스 게이트웨이로서 엄청난 강점입니다.
• 이벤트 루프의 한계 vs 멀티스레딩의 견고함: Python의 asyncio 기반 이벤트 루프는 동시 접속이 급증할 때 컨텍스트 스위칭 오버헤드로 인해 응답 지연이 도미노처럼 발생하는 구조적 취약점이 있습니다. 하지만 Robyn의 Rust 엔진은 시스템 레벨에서 멀티스레드를 직접 제어하며 수만 개의 커넥션을 훨씬 견고하고 공평하게 관리합니다.

결론적으로 Robyn은 단순한 빠른 프레임워크를 넘어서, 고부하 환경에서도 지연 시간의 요동을 최소화하고 서버의 생존력을 끝까지 보장해야 하는 엔터프라이즈 AI 플랫폼 API 서버로서의 적합성을 수치로 완벽히 증명해냈습니다.

 

이번 검증을 통해 얻은 확신을 바탕으로, Robyn을 플랫폼의 핵심 관문 엔진으로 채택하여 안정적인 API Gateway 환경을 구축할 수 있었습니다.

개인적인 생각

초당 처리량, 최악의 응답 시간과 같이 처리량에 따른 시간은 직접 해보진 않았지만, 확실히 Rust가 빠를 것이라고 생각하였습니다.

 

그러나, 1,000명 동시 접근 테스트에서 평균 응답시간이 FastAPI가 더 수치상 우위라는 사실에 살짝 놀랐습니다.

 

그러나, 평균적으로는 Robyn이 확실히 빨랐고, 동시 접속자가 12,000명으로 많아지는 환경에서 FastAPI 대비, 모든 요청을 처리하는 안정성을 보여줬습니다.

 

글에서 설명한 내용처럼 서비스가 빨리 처리하고, 지연이 걸리지 않는 것 또한 중요하나, 얼마나 안정적으로 해당 서비스를 제공해주냐가 가장 우선수위라고 생각합니다.

 

아무리 빠른 서비스라도, 결국 안정적으로 유지되지 않으면 사용자들이 떠나갈테니깐요~

결론 및 인사이트

Robyn 도입과 벤치마크 과정은 단순히 더 빠른 프레임워크를 찾는 여정을 넘어, "Python의 유연함과 Rust의 견고함을 결합했을 때 인프라의 한계를 어디까지 확장할 수 있는가"를 실증적으로 확인하는 과정이였습니다.

• 성능 그 이상의 안정성: Robyn은 단순히 처리량(Throughput)이 높은 것을 넘어, 고부하 상황에서 CPU와 메모리 리소스를 매우 효율적이고 일정하게 제어했습니다. 이는 Nginx와 같은 저수준 설정의 복잡함에서 벗어나면서도, 시스템 레벨의 최적화 이점을 Python 코드로 직접 핸들링할 수 있다는 강력한 메리트를 제공합니다.
• 성숙도와 기회비용: 물론 신생 프레임워크인 만큼 생태계의 성숙도는 기존 라이브러리들에 비해 부족할 수 있습니다. 예상치 못한 동작을 디버깅하거나 공식 문서 외의 오픈소스 코드를 직접 분석해야 하는 수고로움이 따르지만, 이는 성능적 우위를 선점하기 위해 지불해야 할 합당한 비용이기도 합니다.

도입 가이드

• 추천: 극한의 성능이 요구되는 AI/ML 서빙 레이어, Python의 기민한 개발 속도와 Rust의 Low-level 제어력이 모두 필요한 고성능 API 서비스
• 고려사항: 풍부한 레퍼런스와 커뮤니티의 검증된 가이드가 필수적인 보수적인 프로젝트 환경에서는 기술적 난도가 높게 느껴질 수 있습니다.

기술의 주류 여부와 상관없이, 서비스의 병목을 해결하고 최적의 사용자 경험을 제공할 수 있는 기술을 탐구하는 것은 엔지니어에게 매우 가치있는 일입니다.

글을 읽고 난후

AI가 나오고 Rust가 나왔을 때, 'Python으로 모델을 만들고 Rust로 만든 API 서버에서 모델을 서빙하면 어떨까?'라는 생각을 한적이 있습니다.

 

실제로 Python 기반의 vLLM뿐만 아니라 Rust로 구현된 rvLLM이 등장하고, Python의 FastAPI를 대체하거나 보완하는 Rust 런타임 기반 프레임워크인 Robyn 같은 사례들을 보면, Rust가 점차 기존 서비스 환경에 자연스럽게 스며들고 있다고 느껴집니다.

 

이 글은 현재 코드 구조를 크게 변경하지 않더라도, 최소한의 수정만으로도 충분한 성능 향상을 이끌어낼 수 있음을 보여준다고 생각합니다.

 

만약 현재 사용 중인 서비스의 언어나 프레임워크에서 성능 개선이 필요하다면, 우선은 구조를 유지한 채로 적용할 수 있는 작은 개선부터 시도해보고, 필요에 따라 언어나 프레임워크 변경까지 고려하며 다양한 방식으로 개선을 진행해보는 것이 좋습니다.

 

그리고 각 접근 방식에 대한 성능 비교를 통해, 상황에 가장 적합한 선택을 하는 것이 중요하다고 생각합니다.