Rust 는 웹·API 서버에서 많이 쓰나 — 쓰는 방식 다섯 가지

Rust 를 쓰는 곳 가운데 가장 많이 꼽히는 것이 서버 백엔드·웹·네트워크 서비스다. 다만 웹 서비스 전체를 Rust 로 짓기보다, 느린 부분만 떼어 내거나 지연이 튀면 안 되는 서비스·앞단 프록시·서버리스 함수에 쓰는 경우가 많다. 이 편은 공식 설문과 각 회사의 공식 발표로 다섯 가지 방식을 정리한다. 실행한 예제는 없다.

01 얼마나 쓰나

Rust 팀의 2024년 공식 설문 결과(2025-02-13)는 회사에서 Rust 를 쓰는 분야를 두고 "서버 백엔드, 웹·네트워크 서비스, 클라우드 기술에서 특히 인기가 있다" 고 정리했다. 같은 설문에서 응답자의 45% 가 자기 조직이 Rust 를 "가볍지 않게(non-trivial)" 쓴다고 답했고, 전년보다 7%p 늘었다.

3편의 스택 오버플로 설문처럼 Rust 를 쓰는 개발자 자체는 아직 많지 않다. 그러니 "웹 서버는 Rust 가 대세" 가 아니라, Rust 를 쓰는 사람들이 가장 많이 만드는 것이 서버 라고 읽는 것이 맞다.

02 쓰는 방식 다섯 가지

1. 느린 부분만 Rust 로 떼어 낸다 — 피그마

피그마의 실시간 공동 편집 서버는 Node.js(TypeScript)였다. 단일 스레드라 큰 문서 하나를 처리하는 동안 다른 파일이 모두 멈췄다. 2018년 글에서 피그마는 처음에는 서버 전체를 Rust 로 다시 쓰려 했지만, 당시 Rust 의 비동기 생태계가 덜 자라 그만두고 성능에 민감한 부분만 Rust 자식 프로세스로 옮겼다고 썼다. 네트워크(HTTP·WebSocket)는 Node.js 가 그대로 맡고, 둘은 표준 입출력으로 이야기한다. 직렬화 시간이 10배 넘게 줄었다.

가장 흔하고 위험이 적은 방식이다. 기존 서비스를 그대로 두고, 측정해서 가장 느린 곳만 바꾼다.

2. 지연이 튀면 안 되는 서비스를 통째로 — 디스코드

디스코드는 읽음 상태 서비스를 Go 에서 Rust 로 옮겼다(2020). GC 때문에 생기던 지연 튐을 없애려는 것이었다(1편). 서비스 하나를 통째로 옮기되, 회사 전체가 아니라 그 서비스 하나부터 했다.

3. 맨 앞의 프록시·게이트웨이 — 클라우드플레어

모든 요청이 지나가는 맨 앞자리는 작은 비효율이 곧 큰 비용이 된다. 클라우드플레어는 이 자리를 Rust 프레임워크 Pingora 로 만들어 공개했다(3편). API 게이트웨이·리버스 프록시·로드 밸런서가 이 갈래다.

4. 서버리스 함수 — AWS Lambda

AWS 는 2025년 11월 14일 Lambda 의 Rust 지원을 정식(GA)으로 올렸다. 그 전까지는 실험 단계라 운영에 권하지 않았는데, 이제 AWS 지원과 Lambda SLA 를 받는다. 실행 파일 하나로 배포되고(1편) 메모리를 적게 쓰는 점이 함수 단위 과금과 잘 맞는다.

5. 일반 REST API

처음부터 Rust 로 짓는 REST API 도 많다. 이 시리즈에서 다룬 크레이트가 그대로 기본 조합이다.

배포는 1편의 실행 파일 하나를 작은 컨테이너 이미지에 넣는 경우가 많다. 2편의 컴파일 시간 때문에 CI 에서 빌드 캐시를 쓰는 것이 거의 필수다.

03 실습 — 내 서비스에 적용한다면

1. 지금 서비스에서 가장 느리거나 가장 비싼 엔드포인트 하나를 고른다(측정한 숫자로).
2. 그 부분이 CPU 를 많이 쓰는지(계산·직렬화·압축), 기다림이 많은지(DB·외부 API)를 본다. 앞의 것이면 Rust 로 떼어 낼 만하고, 뒤의 것이면 언어를 바꿔도 크게 빨라지지 않는다.
3. 떼어 낸다면 피그마처럼 별도 프로세스나 작은 서비스로 시작하고, 나머지는 그대로 둔다.

CRUD 위주의 사내 관리 화면처럼 DB 를 기다리는 시간이 대부분인 서비스는, 2편의 비용을 치를 만큼 얻는 것이 적다. 다음 편은 axum 으로 REST API 를 실무 모양으로 짜는 법이다.