Rust를 회사 업무로 쓰고난지 5개월 정도
Table of Contents
새로 이직한 회사에서 Rust를 쓰고 있습니다. 이직한지 5개월이 지나고 느낀 바를 서술 해보고자 합니다. 문법적인 세세한 장점은 제쳐두고 그냥 간단하게 느낀 바를 서술 합니다.
장점 #
- 개발하려는 도메인에 잘아는 개발자가 있으며, 최소 2인에서 코드리뷰를 서로 잘해주면 안전하게 코딩할수 있습니다.
- C언어와 비교를 하면 매우 편리한점이 많습니다.
- C언어/펌웨어 만 하던 사람으로서는 다른 현대언어 대비 좀더 친숙하게 느껴지고 대부분의 행위/설계가 reasonable 하게 느껴집니다.
- 개인적인 의견으로는 프론트엔드 빼고는 많은 부분에 적용할 수 있습니다. [펌웨어, 운영체제 종속 유틸리티, 백엔드]
- 개발하는 비즈니스 로직에 대한것이 아닌 순수 CS에 대한 공부/도전 요소가 계속 생깁니다.
- 타겟 아키텍처 (CPU, Operating System)가 어떤 것이 오든, 대응하기 매우 편리합니다.
단점 #
우리는 FullStack을 넘어 EntireStack 개발자가 될 수 있을까?
- 각각의 고난포인트 마다 기본적으로 요구하는 지식이 큽니다.
- 가끔은 개인시간을 넘어드는 공부/도전 요소가 계속 생깁니다. [저에겐 단점이 아니나, 사람에 따라 단점이라고 느낄 수 있다고 생각합니다.]
- 구인시 제한이 많습니다.
- 이 언어의 장점이 뭐야? 라는 질문을 받았을 때, 요구하는 지식 범위가 매우 커질 수 밖에 없습니다. 그리고 그 지식범위는 대다수의 관심사 저 멀리 일 수 있습니다.
- 임베디드에서 사용하고, 국내 개발자 풀을 본다면, 같이 러스트를 쓸 임베디드 개발자를 구하기가 어렵고, 임베디드 개발자에게 추가적으로 요구되는 능력의 풀이 꽤 기하급수적으로 늘어납니다. 임베디드 개발을 주(主)로 하진 않으나 rust를 고려하지않아도 임베디드 개발자 풀이 너무 적습니다.
- 꼭 제가 쓰려고하는 칩은 rust 임베디드 지원이 애매합니다. (여기에 대한 답은 제가 스스로 기여를 하는 것이긴합니다.) 아직까지는 커뮤니티가 chip-shortage인 상황에 알짜베기 단가/lead time 면에서 쓸만한 칩보다는 toy-project로 쓸만한 칩에 더 치중에 되어있습니다.
기타 #
- 이전회사에서 코드리뷰관련해서 매우 깐깐하게 했었고 지금 회사에서는 어떻게 되나 걱정했었는데. 제가 초반에 느낀바로는 C언어 대비 문법이 고도화 되어있기에 스타일이 지나치게 개인마다 달라서 리뷰할 때 이 문제가 병목사항이라 생각했습니다만. 많은것 들을 clippy가 어느정도 해주고 typo check와 어느정도 선에서 합의볼수 있는 수준의 test만 있으면 리뷰는 문제없네요.
- 서로가 자연스레 건전한 CS 주제로 토론을 할 수 있습니다
여러 아키텍처에 적절한 대응이 가능 #
우선 모든 아키텍처를 적절하게 대응한다라는 면은 시스템 프로그래밍 혹은 펌웨어 프로그래밍의 가치 중 하나입니다. 그럼 기존에 이러한 프로그래밍을 하기위해서 어떠한 언어를 썼을까요. 바로 C와 **C++**입니다. 하지만 해당 언어로 바로 빠르게 빠르게 시작(Getting Start) 하기위해서는 Makefile 이나 CMake 설정부터 해줘야 했으며, 아키텍처가 추가될 때 마다 이에 대응해줘야 했습니다. 여기에 해당 아키텍처를 위한 컴파일러, 개발환경, 라이브러리 세팅은 별도입니다.
그럼 다른 언어와 비교를 해보겠습니다. 현재는 Go-Lang과 Rust를 비교하는 사람은 거의 없으나, 5년전에는 많이들 비교했던 것 같습니다. 시스템 프로그래밍의 영역을 OS위에서만 비교한다고 했을때에는 둘 다 훌륭한 언어입니다. 앞으로 말한 것은 매우 무리수인 발언이나, Rust개념상의 no-std, OS가 없거나 일반적인 OS와는 매우 형질이 다른경우에는 대응이 어렵습니다. [필자는 펌웨어 개발을 이전에 하였으며, 제품 출하가 가능한 펌웨어 개발이 가능한가를 추가로 따지고 있습니다.]
Rust는 당장에 빠르게 프로토타이핑 하기는 어렵다. #
회사/개발조직에서 사용 언어? 프레임워크)으로서 Rust를 선택한다면, 개인적인 선호는 후순위로 미룬 채 회사의 입장에서 생각해봐야합니다.
- 우리가 개발할 수 있는 것을 실현해줄 수 있는 매게체인가.
- 개발자를 적절히 구인할 수 있는가.
- 개발 시간 소요가 어떻게 되는가.
- 빠르고 정확하게 돌아가는가.
- 구성원들이 쓰고싶어하는가. (다른 의미로 취향)
Rust는 (2), (3) 항목에서 낮은 점수를 받을 가능성이 크며, 특히나 (2) 항목에서는 절대적으로 그렇다고 생각합니다.
위와 같은 단점을 극복하고라도 Rust를 선택해야만 한다면 특히나 (4), (5) 의 원인이 클 것입니다. 이렇게 된다면 개발조직, 개발자 입장에서는 최대한 Rust의 장점을 부각하는 사건이나 결과가 있어야지만 이를 자의적이든 타의적이든 유지하게 될 것 입니다.
아무리 회사에서 정해주는 언어를 쓰면되지만, 그래도 선택할수 있고 Rust를 계속 쓰고싶다면 부각하고 싶을 겁니다. (좀 서술하기 어려운 부분입니다. 감정적인 영역이 겹쳐져 있어서요)
그러면 Rust 의 장점을 최대한 살려서 개발하려면 많은 지식을 요구하게 되버립니다. 다른 문장으로 러닝 커브가 높아집니다. 어떻게 보면 스스로 무덤을 파는 행위가 될 수도, 기회가 될 수 도 있습니다.
하지만 많은 지적 가치를 얻을 수 있는 기회 #
멀티 프로세싱/프로세서(SMP) 개념이나 캐시의 개념, GPGPU이 없으며, 세세한 부분에 있어서 현대적인 메모리 모델과는 다르던 시절입니다. 그리고 지금까지는 C언어로 이러한 부분을 핸들링 하고 있습니다. 그리고 이러한 개념들을 고려하면서 개발해야하는 상황에 놓인다면 많은 어려움이 있습니다.
하지만 Rust는 이를 어느정도 쉽게 극복할 수 있는 인프라가 마련되어 있거나, 앞으로도 더 마련될 여지가 있습니다. 그리고 애매한 문장이지만, Rust를 통해 간접으로 어려운 컴퓨터나 운영체제의 아키텍처 설계에 대해 좀더 면밀히 볼 수 있는 기회가 마련이 되는 것 같습니다. 이는 Rust 컴파일러의 안전을 위한 제약경고를 통해서도 얻을 수 있으며, 우연치 않게 많은 고수들로 이뤄진 시스템 프로그래밍 개발자들이 많은 커뮤니티의 영향이 원인으로 작용한다고 생각합니다. 멀티 플랫폼에 대한 얘기를 조금더 하자면, 커뮤니티의 강력함으로 인해 멀티플랫폼이 매우 잘 대응 된다고도 생각합니다.
언제 쯤 충분한 Rust 개발자가 되었다고 할 수 있을까? #
정답은 없습니다.
하지만 개인적인 생각으로는 해당 프레임워크 혹은 언어가 가져다주는 장점을 남들이 이해할 수 있게끔 설명할 수 있다면 ____ 개발자라고 말 할 수 있지 않을까? 라고 생각합니다.
하지만 아쉽게도 Rust 는 이를 서술 하기가 매우 어렵습니다. 당장에 소유권 부터 설명해야 합니다만. 일단 기본적으로 실행 중인 processs의 stack, heap 부터 이해를 해야합니다.
이러한 문제로 설득시키려고 하는 대상에게 많은것을 설명해줄 능력이 되야하거나, 듣는 대상이 수준이 높기에 정확하고 매우 깊은 설명이 요구되는 상황입니다.
처음부터 설명의 난이도가 HARD MODE 인 것은 아쉽지만, 혼자 개발하는 세상도 아닐 뿐더러, 우리가 개발을 할때에 Pull-Request를 진정으로 넣고 싶다면 Review를 해주는 사람에게 설명을 잘 하거나, 잘 할수 있도록 코드를 짜는 것은 어느정도 필요하다 생각합니다.
그러한 과정 속에서 설명을 할 수 있는 지식의 바탕과 말 솜씨를 늘릴 수 있으며, 더 나아가서 서술 한대로 어떠한 기술에 대해 설명할 수 있는 능력이 갖춰지지 않을까 생각합니다.
다음 혹은 다다음에 회고록을 작성 할 때에는 Rust 회사에서 써서 얻었던 실제의 이득, 손실에 대해서 다뤄보도록 하겠습니다.