개발자

러스트 언어를 좋아하는 이유, 그리고 싫어하는 이유 7가지

Peter Wayner | InfoWorld 2022.10.12
요즘은 매일 새로운 프로그래밍 언어가 만들어지는 것 같다. 대부분 소프트웨어 개발자에게 필요한 이상으로 많은 프로그래밍 언어가 있다. 프로그래머는 번뜩이는 천재성으로 새롭고 멋진 뭔가를 만들기 시작한다. 그러나 많은 경우 틈새 언어가 되어 한 가지 고충이나 특정 문제를 해결하는 데 사용된다. 새 프로그래밍 언어가 주류로 올라서서 광범위하게 사용되는 경우는 극히 드물다. 
 
ⓒ Getty Images Bank

러스트(Rust)는 새로운 언어 중에서 개발자가 실제 엔터프라이즈 프로덕션에서 실행되는 코드를 작성하는 수준까지 성장한, 매우 드문 사례 중 하나다. 확실히 러스트는 틈새 언어다. 러스트의 목표는 시스템 프로그래머를 비롯해 수십, 수천, 심지어 수십만 건의 이벤트를 동시에 처리하는 코드를 만들고자 하는 사람에게 유용한 언어가 되는 것이다. 이와 같은 시스템을 만드는 것 자체도 어렵고 시스템에서 버그를 찾아 수정하기는 더 어렵다. 러스트는 시스템을 만들기 위한 최선의 방법에 관한 심층적이고 이론적인 온갖 사고를 살아 숨쉬는 실제 언어로 바꿔준다. 

러스트 코어팀은 매년 개발자 설문을 실시한다. 2021년에는 최초로 모든 러스트 프로그래머의 절반 이상이 실무에서 러스트를 사용한다는 설문 결과가 나왔다. 더 이상 취미가 아니라 사용자가 실행할 전문적인 코드를 생산하는 데 사용하고 있다는 의미다. 

개발자가 러스트를 사용한 프로그래밍에서 좋아하는 점과 싫어하는 점을 살펴보자. 
 

좋아하는 이유 1. 규모와 동시성이 뛰어나다 

개발자가 규모와 동시성 문제, 즉 많은 소스로부터 동시에 들어오는 입력을 처리하기 위한 요구사항에 대처하는 과정에서 소프트웨어의 복잡성은 높아졌다. 이 때문에 많은 개발자가 러스트를 오늘날의 아키텍처에 적합한 툴을 만들기 위한 최선의 언어로 생각한다. 

높은 확장성이 필요한 애플리케이션의 대표적인 예로 웹 브라우저가 있다. 그렇게 보면 파이어폭스를 개발한 모질라에서 러스트가 탄생했다는 사실도 놀랍지는 않다. 모질라 개발자들은 당시 사용하던 코드에서 발생하는 문제를 연구하면서 더 나은 해결책을 모색했고, 그렇게 해서 나온 결과물이 러스트다. 
 

싫어하는 이유 1. 너무 복잡한 동시성 모델 

멀티쓰레드 시스템은 갈수록 인기를 얻고 있지만, 많은 개발자에게는 사실 필요가 없다. 과학 프로그래머는 무한한 데이터 스트림을 처리하는 싱글 쓰레드 함수를 주로 사용한다. 웹 개발자는 웹사이트를 만들기 위한 단순하고 선언적인 접근 방식을 제공하는 PHP 코드를 쓸 수 있다. 서버리스 프로그래머는 하나의 함수를 만들고 어려운 부분은 다른 사람에게 맡기면 된다. 

더 정교한 웹 애플리케이션을 만들어야 하는 개발자는 멀티쓰레드 애플리케이션을 다루기 위한 또 다른 전략을 제공하는 Node.js를 선택할 수 있다. Node.js의 이벤트 기반 모델과 프로미스 기반 코드는 단순명료한 결과를 생산할 수 있다. 

결국 이 모든 이야기는 러스트의 멀티쓰레드 프로그래밍 모델이 많은 프로그래머에게 실제 필요한 이상의 정교함을 제공한다는 의미다. 부가적인 기능을 무시하고 사용할 수도 있지만, 복잡성을 아예 배제하는 편을 선호하는 프로그래머도 있다. 필요가 없기 때문이다. 
 

좋아하는 이유 2. 러스트는 현대적 언어다 

오늘날 프로그래밍 언어 설계는 분석이 더 용이한 소프트웨어를 만들도록 코더를 이끄는 함수형 언어를 만드는 데 초점을 둔다. 러스트도 이 추세에 속하는 언어다. 중첩된 함수 호출 시퀀스로 코드를 설계하도록 이끄는 러스트의 논리적이고 함수적인 구문을 좋아하는 개발자가 많다. 

또한 러스트를 만든 사람들은 IoT의 기능을 유지하는 데 필요한 저수준 비트뱅잉 프로그래밍을 처리할 수 있는 무언가를 만들고자 했다. 러스트는 극히 현실적인 이와 같은 과제를 현대적인 스타일로 해결할 방법을 모색하는 프로그래머에게 딱 맞는 조합이다. 
 

싫어하는 이유 2. 배우기 어렵다 

어떤 면에서 러스트를 배운다는 것은 프로그래밍을 처음 직업으로 삼은 시점부터 추종해온 개념과 기법을 잊어버리는 과정이다. 예를 들어 자바스크립트, 자바와 같은 더 오래된 언어에서 필수 요소인 범위와 소유권 개념을 러스트에서는 버려야 한다. 

러스트의 장점을 활용하려면 버그로 이어질 수 있는, 익숙한 몇 가지 기능을 기꺼이 포기해야 한다. 러스트는 언어 구문도 복잡하다. 지나치게 복잡하다고 말하기도 한다. 더 이상 중괄호냐 괄호가 없느냐의 문제가 아니라 대괄호, 수직선, 부등호까지 등장한다. 콜론 하나로는 충분하지 않은지 이중 콜론도 사용된다.  

복잡한 멀티쓰레드 툴을 구축하는 러스트 개발자라면 러스트의 구문 복잡성을 ‘감수할 가치가 있는 단점’으로 볼 수 있다. 함수적 흐름을 훤히 읽는 진정한 러스트 팬이라면 복잡성을 즐기기까지 한다. 그러나 그 외의 사람들에겐 힘들 뿐이다. 러스트의 모든 의미론적 규칙을 배우는 것은 보편적인 사용자에게는 엄두가 나지 않는 일이다. 
 

좋아하는 이유 3. 러스트 컴파일러에 지시할 수 있다

어떤 개발자는 러스트에 필요한 온갖 부가적인 세부 요소와 형식을 장점으로 보기도 한다. 덕분에 힌트를 넣어서 어떤 작업이 진행되는지 컴파일러가 더 쉽게 이해하고 잠재적인 버그를 잡아내도록 할 수 있기 때문이다. 장황한 코드는 개발자가 하고자 하는 일을 더 세밀하게 지정할 수 있게 해주고 이는 컴파일러 오류를 방지하는 데 도움이 된다. 러스트를 사용하는 개발자는 코드가 할 일에 관한 힌트를 주입함으로써 더 좋으면서 더 빠른 코드를 쓸 수 있다. 
 

싫어하는 이유 3. 컴파일러에 지시하는 것은 쓸데없는 짓이다

그냥 루프를 만들면 아무 충돌 없이 실행되는 언어를 원하는 개발자도 있다. 이들은 개발자가 신경을 쓸 필요가 없도록 백그라운드 작업을 알아서 처리해주는 언어를 원한다. 간혹 컴파일러가 생산하는 코드가 조금 느리거나 버그가 있더라도 괜찮다. 많은 경우 별로 복잡하지도 않고 디버그가 어려운 작업도 아니기 때문이다. 러스트 컴파일러에 필요한 온갖 부가적인 세부 사항을 힘들여 채우는 것보다 그냥 하드웨어를 더 늘리는 편이 더 값싼 해결 방법이다. 
 

좋아하는 이유 4. 뛰어난 하위 호환성 

러스트 개발팀은 언어가 발전하더라도 코드는 계속 실행되도록 하는 데 상당히 공을 들인다. 언어의 새로운 버전이 나와도 이전 코드가 계속 컴파일되고 실행되도록 하기 위해 노력한다. 다른 언어에서는 이런 부분을 무시하는 경우도 있다. 러스트의 열렬한 추종자들은 끊임없이 다시 쓸 필요 없이 코드베이스를 그대로 유지할 수 있다는 점을 자주 강조한다. 러스트는 스스로의 역사를 존중하는 언어이기 때문이다. 
 

싫어하는 이유 4. 러스트는 엄밀히 말해 객체 지향이 아니다

러스트가 객체 지향 프로그래밍 원칙을 따르지 않는다는 점은 일부 프로그래머에게 문제가 된다. 러스트에서도 객체 지향 프로그래밍의 몇 가지 측면을 모조할 수는 있다. 진정한 러스트 팬이라면 러스트 구성자로 OOP를 모방하는 좋은 방법을 알고 있을 것이다. 그러나 정교한 형식 계층 구조를 구축하고자 하는 개발자는 러스트에 좌절감을 느끼게 된다. 
 

좋아하는 이유 5. 러스트의 비동기 처리 모델이 더 안전하다 

러스트의 비동기 프로그래밍 모델은 개발자가 상호 독립적으로 실행되는 개별 함수를 만든 다음 결과를 조인할 수 있게 해준다. 많은 개발자는 이 구조가 더 빠르면서 버그도 적은 코드를 빌드하는 데 도움이 된다고 말한다. 
 

싫어하는 이유 5. 비동기 코딩은 어렵다 

러스트에서도 코드에 대해 세심하게 생각해야 할 필요성이 없어지지는 않는다. 러스트라 해도 교착이나 지연으로부터 코드를 보호하지는 못한다. 단지 더 나은 조언과 버그가 적은 구조를 제공할 뿐이다. 좋은 애플리케이션 설계와 깔끔한 코드 작성은 여전히 개발자의 책임이다. 러스트가 마술봉이라면 좋겠지만 현실은 그렇지 않다. 러스트는 문제를 최소화하고 명확하게 보이는 위험을 줄여줄 뿐이다. 
 

좋아하는 이유 6. 추상화 없는 프로그래밍 

러스트는 바이트를 다루는 저수준 코드를 작성하는 시스템 수준 프로그래머를 지원하도록 설계됐다. 원시 비트에 액세스할 수 있는 수단을 제공하고 프로그래머가 그 수단을 사용하도록 유도한다. 러스트 언어는 운영체제와 네트워크 스택의 하위에 속하는 대부분의 오래된 C 또는 어셈블리 언어 코드와 공존하도록 만들어졌다. 진짜 프로그래머는 최상의 응답성을 가진 최선의 스택을 구축하기 위해 이와 같은 액세스를 원한다. 러스트가 바로 그걸 제공한다. 
 

싫어하는 이유 6. 바이트 수준 액세스는 위험하다 

많은 언어가 바이트 수준 액세스를 피하는 방향으로 발전한 데는 다 이유가 있다. 바이트 수준 액세스는 프로그래머를 문제로 끌어들이기 십상이다. 일부 프로그래머는 언어의 숨겨진 백엔드가 메모리 할당과 데이터 표현의 세부 사항을 처리해주는 편을 선호한다. 
 

좋아하는 이유 7. 더 좋은 가비지 수집 방법 

인기 있는 많은 언어는 내부 메모리 할당과 가비지 수집을 알아서 해주는데, 가비지 수집기가 모든 작업을 멈추게 할 때까지는 좋은 서비스다. 가비지 수집으로 인해 금요일 밤 컴퓨터에서 재생 중인 영화가 멈추는 정도야 견딜 수 있겠지만 의료 기기에서 그런 일이 발생한다면 치명적일 수 있다. 

러스트 언어는 독자적인 메모리 관리 방법을 사용한다. 전통적인 GC만큼 포괄적이지는 않지만 더 강력할 수 있다. 유능한 개발자는 러스트의 메모리 모델을 사용해서 뛰어난 성능을 얻을 수 있지만 이를 위해서는 형식 시스템과 원자적 참조 카운팅을 마스터해야 한다. 

골수 러스트 팬은 직접 메모리를 관리하는 방식을 좋아한다. 수많은 쓰레드를 어지럽게 다루면서 코드의 응답성을 보장해야 하는 일이라 해도 이들은 직접 하는 편을 더 선호한다. 좋은 싫든 러스트는 개발자의 손에 힘을 쥐어 준다. 
 

싫어하는 이유 7. 메모리 관리는 골칫거리 

인기 있는 많은 프로그래밍 언어(예를 들어 자바)가 내부 메모리 관리를 구현한 이유는 그렇게 하면 메모리 누출 및 여타 버그가 방지되기 때문이다. 대부분의 프로그램에서 가비지 수집에 의해 이따금 발생하는 불편함은 별 문제가 되지 않는다. 프로그래머라면 메모리에 대해 신경을 쓰지 않는 편을 선호할 것이다. 

또한 러스트가 전통적인 가비지 수집의 대안을 제시하는 유일한 언어도 아니다. 예를 들어 Node.js는 멀티쓰레드 코딩을 간소화하고 자바스크립트의 런타임 메모리 관리에 의존할 수 있게 해준다. 가끔 멈추지만 사용자가 문제삼지 않는다면 감수할 가치는 충분하다. 
 

결론 : 러스트는 여전히 새롭고 발전 중인 언어 

러스트가 비동기 코딩을 위한 최선의 모델을 제공하는지, 가비지 수집을 없애는 것이 정말 개발자에게 도움이 되는지 여부 등은 논쟁의 소재다. 그러나 러스트는 여전히 매우 새로운 언어다. 개발자들은 러스트의 세부 사항을 적극적으로 연구하면서 러스트를 다루는 최선의 방법을 발견해 나가는 중이다. 러스트 프로그램을 만드는 올바른 방법에 정해진 답은 없으며 개발자들은 계속해서 배우고 실험하는 중이다. 

러스트는 개발자나 프로젝트에 따라 최선의 언어일 수도 있고 아닐 수도 있다. 또 일반적으로 소프트웨어를 만들기 위한 최선의 솔루션일 수도 있고 아닐 수도 있다. 그러나 탐구할 기회가 풍부한 재미있는 선택지다. 러스트는 언어로서 참신하며 배우려면 뇌를 많이 써야 한다. 프로그래머에게 러스트는 직면한 과제에 대해 다시 생각하고 목표를 재구성하고 현대 소프트웨어를 작성하기 위한 최선의 방법을 찾아 나설 이유를 부여한다. 그것만 해도 충분히 좋지 않은가? 
editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.