들어가며: 왜 Rust Actix-web에 주목하게 됐나
백엔드 개발을 하다 보면 한 번쯤은 "이 서버, 도대체 왜 이렇게 느리지?"라는 벽에 부딪히게 됩니다. 저도 그랬습니다. Node.js와 Spring Boot로 몇 년간 서비스를 운영하다가, 트래픽이 몰리는 시간대마다 응답 지연이 생기는 걸 보면서 다른 선택지를 진지하게 고민하기 시작했죠. 그때 눈에 들어온 게 바로 Rust였고, 그중에서도 웹 프레임워크인 Actix-web이었습니다. 오늘은 제가 실제로 운영 환경에 Actix-web을 도입하면서 겪은 성능 비교 경험을 솔직하게 풀어보려 합니다.
목차
- 들어가며: 왜 Rust Actix-web에 주목하게 됐나
- Actix-web의 성능, 숫자로 확인해보기
- 실제 운영에서 얻은 실전 팁
- 장단점 비교와 도입 시 고려사항
- 마무리: 누구에게 추천할까
Actix-web을 선택한 배경
처음엔 단순한 호기심이었습니다. TechEmpower 벤치마크에서 Actix-web이 매번 상위권을 차지하는 걸 보면서 "벤치마크야 어차피 이상적인 환경이잖아"라고 반신반의했죠. 하지만 우리 팀의 핵심 API 게이트웨이가 점점 병목이 되면서, 진짜 고성능 서버가 필요한 시점이 왔습니다. Rust는 가비지 컬렉터가 없어 GC 멈춤이 없고, 컴파일 타임에 메모리 안정성을 보장한다는 점이 매력적이었습니다.
Actix-web의 성능, 숫자로 확인해보기
막연한 기대만으로 도입할 수는 없으니, 동일한 조건에서 직접 부하 테스트를 돌려봤습니다. 단순 JSON 응답을 반환하는 엔드포인트를 만들고, wrk로 동시 접속 500, 30초간 측정했습니다. 결과는 솔직히 좀 놀라웠습니다.
처리량(Throughput) 비교
같은 AWS c5.xlarge 인스턴스에서 Node.js(Express)는 초당 약 1만 8천 건을 처리했고, Spring Boot는 약 2만 2천 건이었습니다. 그런데 Rust Actix-web은 초당 약 9만 건을 넘겼습니다. 4~5배 차이가 난 거죠. 처음엔 측정 오류인 줄 알고 세 번이나 다시 돌렸습니다. Actix-web의 고성능 서버 아키텍처가 멀티스레드 액터 모델 기반으로 CPU 코어를 알뜰하게 쓴다는 게 체감되는 순간이었습니다.
지연 시간(Latency)과 메모리 사용량
처리량만큼 중요한 게 꼬리 지연(tail latency)입니다. p99 기준으로 Actix-web은 12ms 수준을 유지한 반면, Node.js는 부하가 몰릴 때 80ms까지 튀었습니다. GC가 없는 Rust의 장점이 여기서 확실히 드러났습니다. 메모리도 인상적이었는데, 동일 부하에서 Spring Boot가 500MB 이상을 먹을 때 Actix-web은 40MB 안팎으로 안정적이었습니다. 컨테이너 비용을 생각하면 이건 무시할 수 없는 차이입니다.
실제 운영에서 얻은 실전 팁
벤치마크는 화려하지만, 막상 실서비스에 올리면 예상 못한 일들이 생깁니다. 제가 시행착오 끝에 얻은 팁들을 공유합니다.
팁 1: 워커 수와 커넥션 풀을 꼭 튜닝하라
Actix-web은 기본적으로 CPU 코어 수만큼 워커를 띄웁니다. 하지만 DB가 병목인 워크로드라면 워커를 늘려도 의미가 없습니다. 오히려 데이터베이스 커넥션 풀(sqlx, deadpool 등) 크기를 코어 수와 맞춰 조정하는 게 핵심입니다. 저는 처음에 이걸 놓쳐서 "왜 벤치마크만큼 안 나오지?" 하며 한참 헤맸습니다.
팁 2: 컴파일 시간을 각오하고 개발 흐름을 바꿔라
Rust의 가장 큰 진입장벽은 컴파일 시간입니다. 작은 수정에도 빌드가 수십 초 걸릴 수 있어요. cargo watch와 sccache를 함께 쓰면 증분 빌드가 훨씬 빨라집니다. 이걸 세팅하기 전과 후의 개발 생산성 차이가 정말 큽니다. 솔직히 이 부분은 Node.js의 즉각적인 핫 리로드가 그리워지는 순간이 있긴 합니다.
팁 3: 에러 핸들링은 처음부터 ResponseError로 설계하라
Rust의 Result 타입과 ? 연산자는 강력하지만, 웹 응답으로 변환하는 부분을 초반에 잡아두지 않으면 나중에 코드 전반을 고쳐야 합니다. 커스텀 에러 타입에 ResponseError 트레잇을 구현해두면, 비즈니스 로직에서는 그냥 ?만 써도 적절한 HTTP 상태 코드로 자동 변환됩니다. 이 패턴을 초기에 잡은 프로젝트와 아닌 프로젝트의 유지보수성이 하늘과 땅 차이였습니다.
장단점 비교와 도입 시 고려사항
모든 기술이 그렇듯 Actix-web도 만능은 아닙니다. 냉정하게 정리해봤습니다.
장단점 한눈에 보기
| 구분 | 장점 | 단점 |
|---|---|---|
| 성능 | 초당 9만+ 처리, GC 없는 안정적 지연 | 최적화 없이는 잠재력 발휘 어려움 |
| 메모리 | 40MB 수준의 낮은 사용량 | 소유권 모델 이해 필요 |
| 개발 경험 | 타입 안정성, 런타임 에러 급감 | 긴 컴파일 시간, 가파른 학습 곡선 |
| 생태계 | 핵심 라이브러리는 충분히 성숙 | Java/Node 대비 레퍼런스 부족 |
도입 전 반드시 점검할 것
팀의 러닝 커브를 무시하면 안 됩니다. Rust의 소유권과 라이프타임 개념은 숙련된 개발자도 익히는 데 몇 주는 걸립니다. 만약 빠른 기능 출시가 최우선이고 트래픽이 크지 않다면, 굳이 Actix-web으로 갈 이유가 없을 수도 있습니다. 반대로 인프라 비용 절감과 안정적인 고성능 서버가 사업의 핵심 경쟁력이라면, 초기 투자는 충분히 회수됩니다.
마무리: 누구에게 추천할까
정리하자면, Rust Actix-web은 "고성능과 안정성이 정말 절실한 팀"에게 강력히 추천합니다. 구체적으로는 대규모 트래픽을 받는 API 게이트웨이, 실시간 데이터 처리 서버, 마이크로서비스의 성능 핵심 구간, 그리고 클라우드 비용을 한 푼이라도 아껴야 하는 서비스에 적합합니다.
반대로 프로토타입을 빠르게 찍어내야 하는 스타트업 초기 단계나, 팀에 Rust 경험자가 전혀 없고 학습에 투자할 여유가 없다면 잠시 보류하셔도 좋습니다. 저는 6개월간 운영하면서 새벽에 GC 알람으로 깨는 일이 사라졌고, 서버 비용도 절반 가까이 줄었습니다. 진입장벽은 분명 높지만, 그 벽을 넘고 나면 보이는 풍경이 꽤 괜찮습니다. 고성능 서버를 고민 중이라면, Actix-web을 한 번쯤 진지하게 후보에 올려보시길 권합니다.