"러스트"와 "고"를 선택하는 방법
2021.03.17
© CIO Korea/ Serdar Yegulalp | InfoWorld,
10년이 채 되지 않는 기간 동안 2개의 새로운 프로그래밍 언어가 엔터프라이즈 개발의 주요 언어로 부상했다. 구글에서 만들어진 고(Go), 모질라에서 탄생한 러스트(Rust)다.
2개의 언어 모두 현대 소프트웨어 개발의 필수 요소인 정교하고 통합된 툴체인, 메모리 안전성, 오픈소스 개발 모델, 강력한 사용자 커뮤니티를 제공한다.
이렇게 비슷한 부분을 제외하면 러스트와 고는 서로 극명하게 다른 언어다. 서로 다른 목적으로, 다른 요구를 해결하고 다른 종류의 프로그램을 작성하도록 만들어졌다.
따라서 러스트와 고를 비교할 때는 어느 언어가 '객관적으로 더 우수한가'가 아니라, 주어진 프로그래밍 작업에서 '어떤 언어가 더 적합한가'의 시각에서 봐야 한다. 이를 염두에 두고 러스트와 고의 주요 차이점과 각 언어가 적합한 작업의 종류에 대해 살펴보자.
성능 측면에서의 러스트 vs. 고
러스트의 대표적인 장점은 안정성, 사용의 용이함과 함께 성능인데, 이 가운데서도 성능을 가장 큰 장점으로 볼 수 있다. 러스트 프로그램은 메모리 취급 및 처리를 위한 러스트의 제로 코스트(zero-cost) 런타임 추상화 덕분에 C 및 C++와 대등하거나 거의 근접한 속도로 실행된다.
물론 러스트 프로그램도 어떻게 작성되느냐에 따라 느려질 수 있지만, 최소한 러스트는 안전이나 편리함을 위해 선택의 여지없이 성능을 희생하지는 않는다. 러스트의 비용이라면 개발자가 메모리 관리를 위한 러스트의 추상화를 배우고 마스터해야 한다는 점이다.
반면 고는 개발자 편의성을 위해 어느 정도의 런타임 속도를 희생한다. 메모리 관리는 고 런타임이 담당하므로 런타임 관련 오버헤드가 필연적으로 발생한다. 그러나 많은 시나리오에서 이 타협은 무시해도 되는 수준이다.
고는 프로그래머가 모든 객체에 대해 강력한 형식을 요구해야 한다는 작은 대가를 치르는 대신 기본적으로 파이썬(Python)과 같은 다른 편의성 중심 언어에 비해 몇 배 더 빠른 속도를 제공한다(파이썬의 편리성과 유연성에는 성능 측면에서 상당한 비용이 따른다).
요약하자면 러스트는 전체적으로 더 빠르지만 대부분의 일상적인 사용례에서 러스트와 고 사이의 속도 차이는 미미하다. 성능이 절대적인 요구 사항인 상황에서는 여러 측면에서 러스트가 고보다 우수하다.
메모리 관리 측면에서의 러스트 vs. 고
러스트와 고의 메모리 관리는 언어들의 성능 특성과 밀접하게 관련된다.
러스트는 메모리 관리를 위해 제로 코스트 추상화를 통한 컴파일 타임 소유권 전략을 사용한다. 이는 러스트 프로그램은 라이브 상태가 되기 전에 대부분의 메모리 관리 문제를 포착할 수 있음을 의미한다. 메모리 안전성이 확보되지 않은 러스트 프로그램은 컴파일이 되지 않는다.
개발 세계의 상당 부분이 잘못된 메모리 관리 탓에 안전하지 않은 것으로 드러난 소프트웨어 위에서 돌아가고 있음을 감안한다면, 러스트의 접근 방법은 진작에 도입되었어야 마땅하다.
앞서 언급했듯이 러스트의 이 안정성에 따르는 대가는 비교적 높은 학습 난이도다. 프로그래머는 러스트의 메모리 관리 기능을 적절히 사용하는 방법을 알아야 하며 이를 위해서는 시간과 연습이 필요하다. C, C++, C# 또는 자바에서 건너온 개발자가 러스트를 익히려면 코드를 쓰는 방법에 관한 생각의 변화가 필요하다.
참고로 서드파티 프로젝트를 사용한 추가 요소의 형태로 러스트에 가비지 수집을 도입할 수 있다. 이미 'gc crate'라는 프로젝트가 존재하지만 여전히 초기 상태다. 그러나 러스트의 기반 패러다임은 가비지 수집을 사용하지 않는다.
고도 러스트와 마찬가지로 메모리 안전성을 제공하는데, 메모리 관리가 런타임에 자동으로 처리되는 방식이다. 프로그래머는 수천 라인의 고 코드를 쓰면서도 메모리 할당이나 해제에 대해서는 전혀 생각하지 않아도 된다.
런타임 가비지 수집기의 경우 프로그래머에게 어느 정도 통제 기능이 있다. 가비지 수집 임계값을 변경하거나 수동으로 수집을 트리거해서 가비지 수집 주기로 인해 다른 작업이 방해를 받는 경우를 방지할 수 있다.
또한 고에서도 프로그래머의 수동 메모리 관리도 일부 가능하지만 언어의 기능 자체가 가급적 그렇게 하지 않도록 되어 있다. 예를 들어 포인터를 사용해서 변수에 접근할 수 있지만 unsafe 패키지(프로덕션에서 실행되는 소프트웨어에 대해서는 현명하지 않은 선택)를 사용하지 않는 한 포인터 연산을 수행해서 메모리의 임의 영역에 접근할 수는 없다.
당면한 프로그래밍 작업에서 수동 메모리 할당과 해제가 필요하다면(예를 들어 저수준 하드웨어 또는 최대 성능 시나리오) 애초에 이런 작업을 위해 설계된 언어인 러스트가 더 낫다. 고의 자동 메모리 관리가 그 조건에서 무조건 결격 사유라고 전제해서는 안 되지만 고성능 시나리오에서 러스트가 더 적합하다는 것은 입증된 사실이다.
최근 사례로 디스코드(Discord)가 핵심 백엔드 서비스용 언어를 고에서 러스트로 바꿨는데, 그 이유 중에는 고의 메모리 모델 및 가비지 수집과 관련된 문제도 있다. 디스코드 서비스의 러스트 버전은 수동 튜닝이 전혀 적용되지 않은 첫 버전부터 성능에서 고 버전보다 앞섰다.
개발 속도 측면에서의 러스트 vs. 고
개발 속도가 프로그램 속도보다 더 중요할 때도 있다. 파이썬은 비록 실행 속도는 내세울 것이 없지만 소프트웨어를 가장 빨리 쓸 수 있는 언어로 지금의 자리에 올랐다. 고의 매력도 이와 비슷하다. 명료함과 단순함은 빠른 개발 프로세스의 기반이 된다. 컴파일 시간이 짧으며 고의 런타임은 파이썬(및 다른 개발자 친화적인 인터프리트 언어)보다 훨씬 더 빠르다
(후략)
[원본기사 : https://www.itworld.co.kr/news/186713]
※ 본 내용은 한국아이디지(주) (https://www.idg.co.kr/)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒ 2020 International Data Group. 무단전재 및 재배포 금지.
번호 | 제목 | 조회수 | 작성 |
---|---|---|---|
공지 | [Open UP 활용가이드] 공개SW 활용 및 개발, 창업, 교육 "Open UP을 활용하세요" | 397271 | 2020-10-27 |
공지 | [Open UP 소개] 공개SW 개발·공유·활용 원스톱 지원 Open UP이 함께합니다 | 387098 | 2020-10-27 |
9297 | 틸론, 개방형 OS ‘K구름’ 공개 | 4524 | 2021-03-31 |
9296 | 리눅스 커널에 '러스트' 쓰는 날 올까 | 5049 | 2021-03-31 |
9295 | [주간 OSS 동향 리포트]오픈SSL(OpenSSL) 취약점 해결한 보안 업데이트 발표 | 4948 | 2021-03-29 |
9294 | 안드로이드 앱들 상당수가 취약점 가지고 있다 | 4599 | 2021-03-29 |
9293 | 루비 언어와 닮은꼴··· 크리스탈 1.0 릴리스 이모저모 | 5007 | 2021-03-29 |
9292 | TLS 구축케 해 주는 오픈SSL 프로젝트서 고위험군 취약점 2개 나와 | 4407 | 2021-03-29 |
9291 | 페도라 리눅스 34 베타 출시…그놈40 포함 | 4483 | 2021-03-26 |
9290 | "러스트"와 "고"를 선택하는 방법 | 5653 | 2021-03-19 |
9289 | [주간 OSS 동향 리포트]국내에서 가장 많이 사용하는 오픈소스는 '제이쿼리' | 5605 | 2021-03-16 |
9288 | 자연어 생성의 편견과 기타 유해성에 대처하기 | 4614 | 2021-03-16 |
0개 댓글