Go에서 Rust로 갈아타는 회사들, 2026년 백엔드 언어 선택의 새 기준

“Go면 충분하다"고 말하던 시절이 있었습니다. 그런데 2026년 현재, 분위기가 묘하게 바뀌고 있는데요. Discord, Cloudflare, Figma 같은 회사들이 백엔드 핵심 컴포넌트를 Go에서 Rust로 옮기는 사례가 늘면서, 백엔드 언어 선택의 기준 자체가 재정의되고 있습니다. 오늘은 이 흐름을 한번 정리해보겠습니다.

왜 다들 Go를 떠나고 있을까

먼저 짚어둘 점은, Go가 나빠서가 아니라는 겁니다. Go는 여전히 훌륭한 언어인데요. 다만 특정 워크로드에서 한계가 드러나기 시작했습니다.

가장 자주 언급되는 건 GC(가비지 컬렉터) 지연 문제입니다. Discord가 2020년에 발표했던 유명한 케이스가 있죠. “Read States” 서비스를 Go로 운영하다가 2분마다 발생하는 GC 스파이크 때문에 결국 Rust로 갈아탔다는 이야기인데요. 그때만 해도 “그건 Discord 같은 특수 케이스"라고 치부됐습니다.

그런데 2026년 들어서는 이게 더 이상 특수 케이스가 아닙니다. AI 인퍼런스 서비스, 실시간 게이밍 백엔드, 고빈도 거래 시스템처럼 P99 레이턴시가 비즈니스 지표에 직접 꽂히는 도메인이 폭발적으로 늘었기 때문입니다. ForrestKnight의 “Why Everyone’s Switching to Rust” 영상이 1년도 안 돼 47만 뷰, 좋아요 1만 7천을 넘긴 것도 이 흐름을 반영합니다.

AI 시대가 만든 변곡점

흥미로운 건 AI 붐이 이 마이그레이션을 가속화하고 있다는 점입니다. Bit Yodha 채널의 “Python Is Too Slow for AI in 2026 — Rust Is Taking Over” 같은 영상이 등장하는 이유인데요.

AI 인프라 스택을 들여다보면 답이 나옵니다. 토큰 토크나이저, 벡터 데이터베이스, 임베딩 파이프라인, 모델 서빙 게이트웨이까지 — 이런 컴포넌트들은 마이크로초 단위의 응답 시간이 중요합니다. 그리고 메모리 사용량도 빡빡하게 관리해야 하죠. Hugging Face의 토크나이저가 Rust로 작성된 이유, OpenAI의 tiktoken이 Rust로 다시 짜인 이유, Qdrant와 Meilisearch가 처음부터 Rust로 만들어진 이유가 다 여기 있습니다.

Go의 GC와 채널 기반 동시성은 일반적인 마이크로서비스에는 최고지만, AI 핫패스에서는 예측 가능한 지연이 더 중요한데요. 이 부분에서 Rust가 우위를 가져가고 있습니다.

그래도 Rust로 다 갈아타라는 건 아닙니다

여기서 중요한 균형감각이 필요합니다. ForrestKnight의 영상 제목이 “Why Everyone’s Switching to Rust (And Why You Shouldn’t)“인 것도 그 이유인데요. 모두가 Rust로 가는 건 답이 아닙니다.

Rust의 진입 장벽은 여전히 높습니다. 보로우 체커(borrow checker)와 라이프타임 개념에 익숙해지려면 최소 3-6개월의 러닝 커브가 필요한데요. 평균 개발자 채용 기간이 4-6주인 한국 스타트업 현실에서는 부담입니다. 게다가 일반적인 CRUD API, 어드민 백오피스, 내부 도구 같은 영역에서는 Go가 압도적으로 생산성이 높습니다.

실제로 회사들이 마이그레이션하는 패턴을 보면 전면 교체가 아니라 부분 교체입니다. 성능 임계 경로(critical path)만 Rust로 옮기고, 비즈니스 로직과 글루 코드는 여전히 Go나 Python으로 유지하는 하이브리드 전략이 주류입니다.

2026년 새로운 선택 기준 세 가지

그렇다면 지금 백엔드 언어를 고를 때 어떤 기준으로 봐야 할까요. 정리해보면 세 가지 축으로 압축됩니다.

첫째, 레이턴시 SLA의 엄격성입니다. P99 100ms가 허용되는 서비스라면 Go로 충분합니다. P99 10ms 아래를 요구한다면 Rust 도입을 고려할 시점인데요.

둘째, 워크로드의 특성입니다. I/O 바운드(데이터베이스 조회, 외부 API 호출 위주)라면 언어 차이는 거의 무의미합니다. CPU 바운드이거나 메모리 집약적이라면 Rust의 이점이 살아납니다.

셋째, 팀의 성숙도와 채용 시장입니다. Rust 경력자는 한국 시장에서 여전히 희귀합니다. 팀에 Rust 시니어가 한 명도 없다면, 첫 도입은 사이드 프로젝트나 비핵심 컴포넌트부터 시작하는 게 안전합니다.

마무리: 언어는 도구일 뿐, 문제 정의가 먼저

Go에서 Rust로 가는 흐름은 분명 실재하지만, 그것이 “Go의 시대가 끝났다"는 의미는 아닙니다. 오히려 백엔드 엔지니어링이 더 세분화되고 있다는 신호로 보는 게 맞는데요. 범용 서비스는 Go, 성능 핫패스는 Rust, 데이터 처리는 Python 같은 식으로 말이죠.

여러분의 서비스에서 가장 큰 병목은 어디에 있나요. 그 답을 먼저 찾고 나서 언어를 고르는 게, 트렌드를 좇아 마이그레이션 비용을 떠안는 것보다 훨씬 현명한 선택일 겁니다.