Offcanvas

How To / 개발자 / 애플리케이션

C·C++ 개발자 노린다··· ‘러스트’ 언어란? 뜨는 이유는?

2018.12.07 Serdar Yegulalp  |  InfoWorld
러스트 언의 독창적인 접근법은 C, C++를 비롯한 다른 다른 언어와 비교해 더 우수한 코드와 더 적은 단점이라는 혜택을 구현한다. 

속도, 안전성, 편의성. 지금까지의 소프트웨어 개발은 이들 중 두 마리 토끼 이상을 잡지 못했다. 이용이 간편하고 안전한 언어는 속도가 느리다(파이썬이 좋은 예이다). 한편 퍼포먼스를 강조하는 언어들은 이용이 어렵고 안전성이 떨어졌다(C와 C++를 생각해 보라). 

과연 저 세 마리 토끼를 모두 잡는 언어는 세상에 없는 것일까? 설령 그런 언어가 있다 해도, 과연 상용화가 될 수 있을까? 그레이든 호어가 만들고 모질라 리서치가 스폰서 하는 ‘러스트’는 세 마리 토끼를 모두 잡기 위해 나온 언어다. (구글의 고(Go) 언어 역시 비슷한 목표를 가지고 나온 언어이지만, 러스트는 그에 더해 최대한 성능을 양보하지 않는 것을 목표로 하고 있다.)


관련 영상: 러스트로 더욱 안전한 소프트웨어 개발하기

러스트는 시스템 수준의 빠른 소프트웨어를 제작하기 위한 언어이다. 이 2분짜리 영상을 보면 러스트가 어떻게 메모리나 매니지먼트와 같은 까다로운 프로그래밍 이슈를 우회하는지 잘 설명돼 있다.

러스트는 빠르고, 안전하며, 무엇보다 합리적인 수준의 프로그래밍 난이도를 보장한다. 러스트는 또한 널리 사용되도록 설계되어 있으며 승자 독식의 프로그래밍 언어 경쟁에서 '참가에 의의를 두는' 낙오된 언어가 되지 않도록 신경 썼다. 

안전을 속도, 개발 역량 등과 동등한 위치에 두어야 하는 이유는 많다. 실제로 우리 주변에는 안전을 최우선으로 여기지 않는 언어를 사용하여 제작된 소프트웨어들이 무척 많으며 심지어 그 중 일부는 중요 인프라스트럭처를 구성하고 있기도 하다.

러스트가 갖는 프로그래밍 상의 이점
러스트는 파이어폭스 브라우저의 주요 구성요소를 부분적으로 재확보하기 위한 모질라 연구 프로젝트로 시작됐다. 이러한 결정을 내리기 까지는 몇 가지 주된 이유가 있었다. 첫째로 파이어폭스가 현대식 멀티코어 프로세서를 더 잘 사용할 수 있도록 해야 했으며, 둘째로 웹 브라우저의 보편성은 그만큼 브라우저가 안전해야 함을 의미하기 때문이었다.

이러한 장점들은 브라우저뿐만 아니라 모든 소프트웨어에 필요하기 때문에 브라우저 프로젝트로 시작한 러스트는 프로그래밍 언어 프로젝트로 진화했다. 러스트는 다음과 같은 특성을 통해 안전, 속도 및 사용 편의성을 달성했다.

러스트는 빠르다
러스트 코드는 여러 플랫폼에 걸쳐 기본 시스템 코드로 컴파일된다. 바이너리는 자체 포함되며 런타임이 없고, 생성된 코드는 C 또는 C++로 작성된 코드와 함께 기능한다.

러스트는 안전하다
러스트는 안전하지 않은 메모리 사용을 시도하는 프로그램을 컴파일링 하지 않는다. 대부분의 메모리 오류는 프로그램이 실행 중일 때 발견된다. 러스트의 구문과 언어 은유는 다른 언어에서 흔히 나타나는 메모리 관련 문제(null 또는 댕글링 포인터, 데이터 레이스 등)가 절대 생산까지 영향을 미치지 않도록 않도록 보장한다. 컴파일러는 이러한 이슈에 플래그를 지정하고 프로그램이 실행되기 전에 수정하도록 강제한다.

러스트는 간접 비용이 적게 발생시킨다
러스트는 엄격한 규칙을 통해 메모리 관리를 통제한다. 러스트의 메모리 관리 시스템은 '소유'라고 불리는 메타포를 통해 언어 구문으로 표현된다. 러스트 언어에서 주어진 가치는 한 번에 하나의 변수에 의해서만 ‘소유’되거나 유지, 조작될 수 있다.

객체 간에 소유권이 이전되는 방법은 컴파일러에 의해 엄격히 관리되므로, 런타임에 메모리 할당 오류와 같은 돌발 상황이 발생하지 않는다. 이런 식의 접근은 또한 Go나 C#와 같은 언어에서처럼 부산물 수집(garbage-collected) 메모리 관리가 없다는 것을 의미한다. (이 역시 러스트의 퍼포먼스를 강화하는 요소가 된다.) 러스트 프로그램의 모든 메모리는 소유권 메타포를 통해 추적되고 자동으로 방출된다.

러스트는 융통성이 있다
러스트는 필요하다면 어느 정도의 위험도 감수할 수 있도록 되어 있다. 러스트의 안전 장치는 C/C++의 ‘raw pointer’와 같이 메모리를 직접적으로 조작해야 하는 경우 부분적으로 비활성화 시키는 것이 가능하다. 

여기서 중요한 것은 '부분적으로' 라는 것인데, 러스트의 메모리 안전 오퍼레이션은 절대로 완전히 비활성화 될 수는 없기 때문이다. 그리고 안전 오퍼레이션을 부분적으로 비활성화 한다고 해도 일반적인 사용 사례에서는 '안전벨트'를 풀을 필요가 거의 없으므로, 결과적으로는 안전의 기본 값이 훨씬 높은 소프트웨어가 탄생하게 된다.

러스트는 사용하기 쉽다
이처럼 러스트는 장점이 많은 언어이지만, 쉽게 사용할 수 없다면 그런 장점들은 무용지물이 되고 만다. 때문에 러스트 개발자들과 커뮤니티는 러스트를 초보자들에게도 최대한 쉽고 유용하게 만들기 위해 노력해 왔다. 

러스트 바이너리를 생산하는 데 필요한 모든 것은 같은 패키지에 담겨 있다. GCC와 같은 외부 컴파일러는 러스트 생태계(소스로부터 컴파일하는 C 라이브러리 등) 밖에서 다른 구성요소를 컴파일하는 경우에만 필요하다. 마이크로소프트 윈도우 사용자들 역시 이등 시민 취급을 받지 않아도 된다. 러스트 툴 체인은 윈도우에서도 리눅스 및 맥OS에서와 같은 기능을 한다.

러스트는 크로스-플랫폼 언어다
러스트는 리눅스, 윈도우 및 맥OS의 세 가지 주요 플랫폼에서 모두 작동한다. 만약 개발자가 교차 컴파일하거나, 현재 실행하고 있는 것과 다른 아키텍처나 플랫폼에 대한 바이너리를 생산하고 싶다면, 조금 더 많은 작업이 수반되지만, 러스트의 일반적인 임무 중 하나는 그러한 작업에 필요한 무거운 짐을 덜어 주는 것이다. 

러스트는 현재 대부분의 메이저 플랫폼에서 작동하긴 하지만, 사실 '모든 곳에서 컴파일링 가능한 언어'는 러스트 개발자들의 목표는 아니었다. 그저 인기 있는 몇몇 플랫폼, 불필요한 양보를 할 필요가 없는 플랫폼들에서만 컴파일이 가능하다.

러스트는 강력한 언어 기능을 제공한다
기존 사용하던 익숙한 언어보다 더 적은, 혹은 빈약한 기능을 가진 새로운 언어를 가지고 작업하고 싶어 하는 개발자는 거의 없을 것이다. C++ 같은 언어와 비교했을 때, 러스트가 지닌 기능들은 훨씬 개발자의 구미를 당기게 할 만하다. 매크로(Macros), 일반론(generics), 패턴 매칭(patternmatching) 및 ("traits"를 통한)구성은 모두 러스트의 중요 기능들이다.

러스트는 유용한 표준 라이브러리를 가지고 있다
러스트의의 주요 목표 중 하나는 C와 C++ 개발자들이 가능하면 러스트를 사용하도록 장려하는 것이다. 그러나 C와 C++ 사용자는 컨테이너, 컬렉션 및 반복기를 사용하고, 문자열 조작을 수행하고, 프로세스와 스레딩을 관리하고, 네트워크 및 파일 I/O를 수행하는 등 적절한 표준 라이브러리를 원하고 있다.

러스트는 그 모든 것, 그리고 그 이상을 표준 라이브러리 안에서 할 수 있다. 크로스-플랫폼 언어인 러스트의 표준 라이브러리는 플랫폼 간에 신뢰성 있게 포팅할 수 있는 것들만 포함할 수 있다. 리눅스의 epoll과 같은 플랫폼별 기능은 libc, mio 또는 Tokio와 같은 타사 라이브러리의 기능을 통해 지원될 수 밖에 없다. 

표준 라이브러리 없이 러스트를 사용하는 것도 가능하다. 일반적으로, 표준 라이브러리 없이 러스트를 사용하는 이유는 플랫폼 의존성이 없는 바이너리를 구축하기 위함이다(예 : 내장형 시스템 또는 OS 커널).

러스트는 다양한 서드파티 라이브러리 ‘크레이트’를 가지고 있다
프로그래밍 언어의 유용성을 평가하는 한 가지 척도는 서드파티를 사용해 얼마나 많은 것을 할 수 있느냐이다. (크레이트라 불리는) 러스트 라이브러리의 공식 저장소인 카고(Cargo)는 약 1만 개의 크레이트를 열거하고 있다. 

이들 중 상당수가 공통 라이브러리 및 프레임워크에 API 결합하고 있기 때문에 러스트는 그러한 프레임워크와 함께 하나의 언어 옵션으로 사용될 수 있다. 그러나 러스트 커뮤니티에서는 아직까지 전체적인 품질 및 효용성에 기초한 상세한 소개나 크레이트 순위를 공개하고 있지 않기 때문에, 직접 사용해 보거나 커뮤니티에서 설문조사를 해 보지 않고는 어떤 크레이트가 최선인지 선택할 방법이 없다.

러스트는 IDE 지원이 훌륭하다
다시 말하지만, 개발자들은 자신이 선택한 IDE에 대한 지원이 거의 없거나 전혀 없는 언어에는 관심이 없다. 러스트가 최근 러스트 컴파일러로부터 마이크로소프트 비주얼 스튜디오 코드(Visual Studio Code)와 같은 IDE에 실시간 피드백을 제공하는 러스트 랭기지 서버(Rust Language Server)를 도입한 이유도 여기에 있다.


러스트 랭기지 서버에서 송출된 비주얼 스튜디오 코드 내 라이브 피드백. 러스트 랭기지 서버는 기본 구문 체킹 이상의 피드백을 제공한다. 

러스트 언어의 단점들
이처럼 러스트는 장점과 매력이 많은 언어이지만, 단점도 있다. 이러한 단점은 기존 커뮤니티 멤버들과 새로운 '러스타시안(rustacean, 러스트 팬들은 스스로를 이렇게 부른다)' 들 모두에게 문제로 지적 받고 있다.

러스트는 생겨난 지 얼마 안 된 새로운 언어다.
러스트는 2015년에야 비로소 1.0 버전을 출시한, 이른바 '어린' 언어다. 그래서 이제 핵심적인 언어 구문과 기능성이 어느 정도 안정이 되었지만, 그 주변의 많은 다른 것들은 여전히 유동적인 상태로 남아 있다.

예를 들어, 비동기적 운영은 여전히 러스트 언어 구문에서 잘 표현되지 않는다. 비동기식으로 비동기식 작업을 구현하고 키워드를 기다리는 작업이 진행 중이다.

러스트는 배우기 어렵다
현실적으로 훨씬 더 문제가 되는 것은 러스트의 메타포를 배우기가 어려울 수 있다는 점이다. 소유권, 대여와 같은 러스트의 메모리 관리 개념들은 처음에는 누구라도 어리둥절하고 당황하게 만들 수 밖에 없다. 많은 '뉴비' 러스트 프로그래머들이 "버로우 체커(borrow checker)와의 싸움" 이라 불리는 일종의 통과 의례를 거치게 되는데 이를 통해 컴파일러가 변이 가능한 것과 불가능한 것을 얼마나 세심하게 분리하는지 직접 경험하게 된다.

러스트는 복잡하다
이처럼 러스트가 '어려운' 이유 중에는 러스트의 메타포가 다른 언어들에 비해 장황한 코드를 만드는 것도 있다. 예컨대, 러스트의 문자열 결합은 문자열 1+string2 만큼 항상 간단하고 직관적이지는 않다. 하나는 변이 가능하고, 다른 하나는 변이가 불가능할 수도 있다. 러스트는 컴파일러가 추측하도록 내버려 두기 보다는 프로그래머가 직접 이런 문제들을 어떻게 처리할 것인지 설명하도록 한다. 

또 다른 예로, 러스트와 C/C++가 함께 작동하는 방식을 들 수 있다. 대부분의 경우, 러스트는 C 또는 C++로 작성된 기존 라이브러리에 연결하는 데 사용된다. C와 C++를 사용한 프로젝트가 러스트로 처음부터 다시 작성되는 경우는 거의 없다. (그리고 설령 그렇다고 해도 점진적으로 작성되는 경향이 있다.)

러스트 로드맵
러스트 팀은 이러한 많은 문제들을 인식하고 있으며, 이를 개선하기 위해 노력하고 있다. 예를 들어, 러스트 팀은 러스트를 보다 쉽게 C 및 C++와 함께 사용할 수 있도록 하기 위해 바인드젠(Bindgen)과 같은 프로젝트를 확장할 것인지 여부를 조사하고 있는데, 이 프로젝트는 C 코드에 대한 러스트 바인딩을 자동으로 생성한다. 러스트 팀은 또한 버로우(borrowing)와 라이프타임(lifetime)을 보다 유연하고 이해하기 쉽게 만들 계획이다. 

이런 저런 단점에도 불구하고, 러스트는 그 어떤 언어도 시도하지 않았던 방식을 통해 안전하고, 동시적이며, 실용적인 시스템 언어를 제공하고 있으며 개발자들의 기존 작업을 보완하는 방식으로 이를 해내고 있다. ciokr@idg.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

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

Copyright © 2024 International Data Group. All rights reserved.