Programming Rust? 결국은 성격의 문제

Disclaimer: 몇 가지 알려진 사실과 작성자의 주관적 의견에 근거한 포스트입니다.

Rust는 다르다.

Rust를 두고, System programming 언어이냐, General Purpose, high level 언어이냐에 대한 많은 견해들이 있습니다.

혹자는 Rust의 native code에의 지향이나, runtime에 의존하지 않는 특성 등을 두고 시스템 프로그래밍 언어라고하고,

누군가는 Memory 해제등의 low level디테일을 몰라도 프로그래밍이 가능하다는 점을 두고 general purpose high level 언어라고 말을 합니다.

하지만 사실 러스트를 두고 이 언어가 두 진영중 어디에 속하는 지를 분류하는 것은, 이 언어가 실제 그 두 기능을 할 수 있느냐와는 다른 문제입니다.

결론적으로, 러스트는 'System programming도, high-level programming도 가능한' 언어입니다.

아마 그런 점이 러스트를 향한 뜨거운 관심들의 이유라고 생각합니다.

굳이 왜 러스트인가?

필자는 현재 Rust로 회사 내에서 구독, 결제, 태스크 관리 등의 서비스를 개발하고 있습니다. 그냥 회사에서 러스트를 쓴다는 것 자체에

많은 분들이 "그걸 왜 굳이 러스트로 짜?" 라는 질문들을 하곤 하시는데요, 그에 대한 저의 답변은 이렇습니다.

• 프로그램 내에서 동시성 이슈가 발생할 수 없다.
• Type satefy가 매우 뛰어나다.
  - Undefined behaviour가 나타날 수 없다.
  - 리팩토링이 매우 쉽다.
• 빠르다.
• 메모리 효율성이 매우 뛰어나다.

사실, 다른 수많은 장점들을 제쳐두고, 저는 러스트를 한번 접한 사람들이 러스트를 떠날 수 없는 이유에 대해서, 위의 두가지 특성이 가장 큰 원인을

제공한다고 생각합니다.

하지만 '굳이'에 대한 판단은 주관적이므로, 제 경험에 근거해 러스트가 좋은 선택인 경우와 보다 안 좋은 선택인 경우를 공유해드리고자 합니다.

러스트를 사용이 곤란한 경우

1. Client library 사용이 중요한 경우

Rust의 전체 에코시스템은 꾸준히 성장하고 커지고 있지만, 여전히 특정 솔루션들에 대한 library는 미흡하거나 개선되어야하는 점들이 많습니다.

예를 들어, RDBMS등에 대한 driver 및 client는 production-ready로, 대부분의 비즈니스 요구사항은 쉽게 해결이 되지만 MongoDB driver

client library는 사용성이 매우 떨어집니다.

2. 컴퓨터 사이언스에 대한 호기심이 별로 중요하지 않은 조직인 경우.

러스트로 프로그래밍을 하는 것은, computer science에 대한 다양한 지식들을 요구합니다. 가령 Pointer에 대한 개념이나,

Stack - Heap memory, fat pointer, smart pointer 등의 개념등이 이해되어 있지 않으면,

일반적인 웹 서버를 구축하는 것 조차도 꽤나 버거운일일지도 모릅니다.

이런 요구사항에 기초해서, 개인 혹은 조직의 분위기가,

"이게 어떻게 가능한 거지?"

에 대한 질문을 귀하게 여기는 조직이 아니라면, 개인과 조직의 성장에 Rust는 너무 헤비한 언어일 수도 있습니다.

러스트 사용이 좋은 경우

1. 컴퓨팅 비용을 작게 가져가고 싶은 경우.

필자의 회사는 Python으로 운영되던 서비스를 Rust로 porting한 경험이있습니다. Kuberenetes 환경에서 Python instance가 차지하는 RAM의 크기는 단순히 load된 상태에서 800mb에 해당하는 수준이었습니다.
-> 러스트로 변환후 5mb 수준으로, 160배에 해당하는 메모리적 이점을 얻었습니다.

2. Green field 영역에서 새로운 프로젝트를 시작해야하는 경우

개척되지 않은 비즈니스 문제를 해결해야하는 경우, 필연적으로 잦은 business model의 변경이 일어납니다.

많은 사람들이 러스트의 생산성을 들어, 이러한 영역들에 러스트가 적합하지 않을 것이라고 생각하지만, 종전에 기술한 Type safety 특성 덕분에,

러스트는 되려 빠르고 안정적인 개발을 가능하게 합니다. 여기서 '안정적' 이라는 말은 단순히 타입을 신뢰할수 있는 수준을 넘어서

개발 과정에서 필연적인 리팩토링에 있어서도, 빠른 리빌드가 가능하다는 것을 의미합니다.

3. 채팅, 협업툴 등의 동시성 이슈를 해결해야하는 경우

Go community에서는 동시성 이슈를 해결하는 방법에 대해 다음과 같이 말합니다.

Don't communicate by sharing memory; share memory by communicating

메모리를 공유함으로써 소통하지 말고, 소통함으로써 메모리를 공유해라?

일견 어려운 말인 것 같지만, "channel"을 사용해서 공유 메모리를 관리하라는 말인데요.

Rust는 동일한 기능"도" 제공을 하지만, 사실 그냥 전역 변수에 접근을 해도 문제가 원천적으로 발생할 수 없습니다.

그 말은, 구현에 있어서 보다 직관적이고 안전하게 동시성 이슈를 해결할 수 있다는 말이고,

시스템 퍼포먼스와 안정성이 동시에 요구되는 프로그램을 개발해야하는 경우,러스트에 대적할 수 있는 언어는 없다고 생각이 됩니다.

꼭 러스트여야 하는가?

필자는 개발자의 언어 능숙도가, 특정 언어의 가치를 산정하는데 개입되면 안된다고는 생각하지만,

어떤 시스템의 도입이 긍정적인지, 부정적인지에 대한 판단은 조직 구성원들의 순응도, 적합도, 특성 등을 고려하여 판단해야 하므로,

러스트를 도입 당위성에 대한 여부도 객관적 지표와 더불어 개발 조직 구성원들의 관심과 흥미가 중요한 영역이라고 생각합니다.