Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
개발자 / 오픈소스

“차세대 C++는 누가 될까” 러스트vs.카본vs.Cpp프론트 언어 차이 살펴보기

Martin Heller 2022.11.16
C와 C++는 프로그래밍 세계를 움직인다. 파이썬, 고 같은 신생 프로그래밍 언어가 주목받는 상황에서, 선뜻 납득하기 어려운 이야기일 수도 있다. 하지만 일반적으로 사용되는 고성능 데스크톱 애플리케이션과 운영체제 대다수는 C++, 임베디드 애플리케이션은 주로 C로 개발된다. 스마트폰 앱이나 웹 애플리케이션 개발 이야기가 아니다. 그런 영역은 자바, 코틀린, 오브젝티브 C, 스위프트 같은 각 플랫폼에 맞는 특수 언어를 사용해야 한다. 물론 C나 C++을 사용할 수 있지만 빠른 속도가 필요한 특정 반복문이나 여러 운영체제에 공통으로 들어가는 라이브러리 개발에만 쓰인다. 
 
ⓒ Getty Images Bank 

C와 C++는 오랜 기간 동안 시스템 프로그래밍을 주도했기에 이를 대체할 언어는 찾기 어렵다. 그럼에도 불구하고 많은 전문가가 이제 두 언어를 보내줄 때라고 지적한다. 프로그래머는 언제나 더 나은 대안을 포용해야 하기 때문이다. 마이크로소프트 애저 사업부 CTO 마크 러시노비치는 최근 “C와 C++ 개발자들은 러스트로 전환해야 한다”라며 “업계에서 두 언어를 사라질 언어라고 선언해야 한다”라고 밝혀 큰 반향을 일으키기도 했다.

많은 개발자가 실제 제품 개발 과정에서 C와 C++를 대체할 언어로 러스트를 주목한다. 하지만 다른 선택지도 존재한다. 카본과 Cpp프론트 같은 언어다. 세 언어의 장점을 본격적으로 살펴보기 전에 먼저 C와 C++의 역사와 문제점을 확인해보자. 
 

C++의 문제점

C++는 비야네 스트롭스트룹이 1979년 벨 연구소에서 개발한 언어다. C++는 C에 객체 지향 기능을 비롯해 여러 개선 사항을 더하는 것이 목적이었기 때문에 초기에는 ‘객체가 있는 C’라고 불리기도 했다. 1983년 공식 이름이 C++로 정해지고, 1985년에는 벨 연구소 뿐만 아니라 일반 대중에게도 공개했다. 최초의 상용 C++ 컴파일러인 C프론트(Cfront)가 이때 나왔다. C프론트를 이용하면 C++를 C로 변환한 다음 컴파일하고 링크할 수 있다. 향후 C++ 컴파일러는 링커로 바로 넣을 수 있는 객체 코드 파일을 지원했다.

스트롭스트룹이 1985년 ‘C++ 프로그래밍 언어(C++ Programming Language)’ 그리고 1990년 ‘ARM-주석을 곁들인 C++ 참조 설명서(The Annotated C++ Reference Manual)’라는 책을 출판한 이후부터 C++ 표준화 노력도 본격화됐다. 그 결과 1998년, 2003년, 2011년, 2014년, 2017년, 2020년 ANSI/ISO C++ 표준이 나왔고, 2023년에도 새로운 표준이 나올 예정이다. 또한 보완점을 정의하기 위한 중간 기술 명세도 있다.

C++ 표준이 새로 업데이트될 때마다 기능이 추가됐지만, 아직 C++의 학습 난이도를 줄이거나 컴파일 속도를 더 빠르게 해주는 기능은 없다. 특히 C++로 수백만 줄 분량의 프로그래밍을 해본 사람을 알 것이다. C++ 프로그램은 컴파일 과정에서 유독 많은 시간이 필요하다. 구글 개발자이자 고 언어를 만든 롭 파이크는 “2007년 9월쯤에 구글에서 C++로 작성된 간단한 프로그램을 수정하고 있었는데, 방대한 분산 컴파일 클러스터에서 해당 프로그램을 컴파일해보니 약 45분을 기다려야 했다”고 말했다. 파이크는 이 문제를 해결하는 과정에서 고 언어를 구상하고 개발했다고 한다. 고는 현재 많은 곳에서 확대되고 있지만, 아직 C++ 프로그래머들의 마음까지는 얻지 못했다. 

필자 개인적으로도 200만 줄 분량의 C++ 코드를 작업한 경험이 있다. 이 업계에서는 짧은 분량이라고 할 수 있는데, 8코어 단일 컴퓨터에서 컴파일과 링크 작업을 끝마치는 데 몇 시간이 걸렸다. 비주얼 스튜디오에 로드해서 모든 문자를 해석하는 데만 약 10분이 걸렸다. 당시 컴파일 문제를 극복하기 위해 필자가 사용한 방법은 자동화였다. 스크립트를 만들어서 야간에 공유 레포지토리에서 코드의 새 복사본을 가져온 다음 처음부터 전체를 컴파일했다. 느린 로딩 문제는 매일 아침마다 비주얼 스튜디오를 연 다음 팀원들과 함께 물을 끓이고 차를 우려내 마시는 방법으로 해결했다. 비주얼 스튜디오의 느린 로딩 문제는 이후 해결됐다고 들었다.
 

러스트의 장점

C++의 대안을 찾는 개발자에게 러스트, 카본, Cpp프론트는 모두 좋은 선택지다. 일단 셋 중에서 프로덕션 수준으로 사용 가능한 언어는 러스트가 유일하다. 러스트 공식 홈페이지에서는 러스트의 장점을 성능, 안정성, 생산성이라고 설명한다. 실제로 러스트는 빠르고 안전하고 사용하기 쉽도록 설계됐으며, 안정적이고 효율적인 소프트웨어를 구축하는 것을 목표로 개발되고 있다. 

성능 측면에서 러스트는 빠르고 메모리 효율성도 높다. 런타임 또는 가비지 콜렉터가 없다. 따라서 성능이 중요한 서비스를 구동하고 임베디드 디바이스에서 실행되고 다른 언어와 손쉽게 통합된다. 안정성 측면을 보면, 러스트의 풍부한 형식 시스템과 소유권 모델은 메모리 안전성과 스레드 안전성을 보장하며, 개발자는 이를 사용해서 많은 종류의 컴파일 버그를 제거할 수 있다. 

생산성의 경우 뛰어난 문서화, 오류 메시지가 포함된 친절한 컴파일러, 그리고 통합 패키지 관리자와 빌드 툴, 자동 완성 및 형식 검사가 포함된 스마트한 다중 편집기 지원, 자동 포맷터 등을 포함한 최상급 툴을 자랑한다.

러스트 관련 참고 자료도 점점 많아지고 있다. 예를 들어 명령줄 툴 빌드, 웹어셈블리 컴파일(자바스크립트를 강화하는 방법), 네트워크 서비스 구축, 리소스가 적은 임베디드 시스템을 위한 소프트웨어 만들기 등이 있다. 프로덕션에서의 러스트를 도입한 사례도 많이 찾아볼 수 있다. 파이어폭스, 드롭박스, 클라우드플레어, NPM, 옐프, 인플럭스DB(InfluxDB)의 IOx에서 러스트를 도입해 제품을 만들고 있다. 인플럭스DB의 경우, 현재 아파치 애로우(Apache Arrow)에서 사용할 수 있는 러스트 네이티브 기반 SQL 쿼리 엔진 데이터퓨전(DataFusion) 개발 과정에서 러스트를 사용하고 있다.

다만 러스트는 C++만큼은 아니지만 배우기가 어렵다는 평이 있다. 핵심 장점은 안정성이다. 즉, 세이프 러스트(Safe Rust)에서는 형식 안전성이나 메모리 안전성에 대해 걱정할 필요가 없다. 또한 필요한 경우 unsafe 속성을 사용해서 안전하지 않은 코딩 방식을 사용할 수도 있다. 때로는 원시 포인터를 역참조하고 C 함수를 호출하고 정적 변수를 변경하거나 union 필드에 액세스해야 한다. 모두 안전하지 않은 방식이므로 러스트 프로그램에서 이를 사용하려면 안전하지 않은 것으로 표시를 해야 한다. 안전하지 않은 코드에서 개발자가 저지를 수 있는 실수를 컴파일러가 교정해준다고 단정할 수 없으므로 수동 확인도 필요하다.
 

카본의 장점

실험적이면서 새로운 언어인 카본은 2022년 7월 19일 CPP 노스(CPP North) 회의에서 발표됐다. 처음부터 C++의 후속 언어를 염두에 두고 개발됐다. 아직 바로 프로덕션 수준에서는 사용하기는 어렵지만, 소스코드를 공개하고 디스코드를 운영하며 거버넌스 모델도 따로 가지고 있다. 또한 온라인에서 사용하거나 맥OS 또는 리눅스에 설치할 수 있는 인터프리터가 있다. 현재 컴파일러, 툴체인이 없고 완성된 0.1 언어 설계는 없다.

카본은 성능이 중요한 소프트웨어를 위한 언어다. 그래서 소프트웨어의 발전을 이끄는 기능, 읽고 이해하고 쓰기 쉬운 코드, 실용적인 안전성과 테스트 메커니즘, 빠르고 확장 가능한 개발, 현대적 OS 플랫폼과 하드웨어 아키텍처 및 환경, 기존 C++ 코드와의 상호 운용성 및 마이그레이션을 지원한다. 따로 지양하는 부분도 공개해 두었다. 카본은 전체 언어 및 라이브러리를 위한 안정적인 애플리케이션 바이너리 인터페이스(ABI) 개발과 완벽한 하위 또는 상위 호환성 보장에 대해서는 신경 쓰지 않는다.

카본을 이끄는 인물은 마이크로소프트 개발자 출신인 케이트 그레고리, ISO C++ 표준 위원회 임원인 리차드 스미스, 구글 수석 소프트웨어 엔지니어 챈들러 카루스다. 그레고리에 따르면, 하위 호환성을 포기하면 C++ 언어에서는 허용되지 않는 긍정적인 변화를 시도할 자유를 얻게 되며 기술 부채 감소라는 큰 혜택도 얻게 된다. 카본은 하위 호환성 대신 툴 기반 버전 업그레이드와 C++ 마이그레이션을 제공하게 된다. 툴 기반 업그레이드와 마이그레이션은 언어에 주요 변경 사항이 발생할 때마다 C++ 개발자들이 해야 하는 고통스럽고 긴 수동 업그레이드보다 훨씬 더 편리하다.

다음 코드 예제는 카본 레포지토리에서 가져온 것인데, 살펴볼 부분이 많다. 필자가 도움이 될 만한 주석을 추가했다.

//packages are namespaces as well as units of distribution
//Nothing in Carbon goes into the global namespace, unlike C++
//There is only one api file per package. Other files are impl
 
package Sorting api;
 
//fn declares a function
//[T means the parameter type T is generic
//Note the change from <...> to [...] for generics
//:! Means the passed type is checked at compile time
//Comparable and Movable are attributes of the generic T
//Slice hasn’t been fully specified, but think Go slices
//-> is a return value type
//i64 is a 64-bit signed integer type
//var declares a mutable variable
//& is the address-of operator, as in C/C++
 
fn Partition[T:! Comparable & Movable](s: Slice(T))
     -> i64 {
  var i: i64 = -1;
 
  for (e: T in s) {
    if (e <= s.Last()) {
      ++i;
      Swap(&s[i], &e);
    }
  }
  return i;
}
 
//let declares an immutable constant r-value
 
fn QuickSort[T:! Comparable & Movable](s: Slice(T)) {
  if (s.Size() <= 1) {
    return;
  }
  let p: i64 = Partition(s);
  QuickSort(s[:p - 1]);
  QuickSort(s[p + 1:]);
}


카본 코드 예제를 더 보려면 공식 문서와 카본 탐색기 테스트 데이터를 참고해보자. 흥미롭게도 C++ 창시자 스트롭스트룹은 카본에 별 관심이 없는 듯하다. 스트롭스트룹은 “카본은 너무 새로운 언어이고 사양도 부족해서, 지금은 유의미한 기술적 논평을 할 수 없다”라고 밝혔다.
 

Cpp프론트의 장점

허브 서터는 10년 동안 ISO C++ 표준 위원회 의장을 역임한 인물이다. 서터는 마이크로소프트 소속 소프트웨어 아키텍트로, C++/CLI, C++/CX, C++ AMP 및 기타 기술의 언어 확장 설계를 이끌었다. Cpp2와 Cpp프론트에 대해 서터는 “내 목표는 C++ 그 자체를 발전시켜 C++를 10배 더 간단하고 안전하고 유용하게 만드는 것”이라고 밝혔다.

또한 서터는 “C++의 대체 구문이 있다면 ‘지금은 존재하지 않는 새로운 코드 버블’에서 하위 소스 호환성 제약으로부터 자유로운 임의의 개선(예를 들어 기본값 변경, 안전하지 않은 부분 제거, 언어를 컨텍스트 없이 순서 독립적으로 만들기, 30년에 상응하는 학습 적용하기 등)을 이룰 수 있다”라고 설명했다. 

서터는 2015년과 2016년에 ‘신텍스 2(Cpp2)’ 설계 작업을 했고, 2015년부터 논의된 ISO C++ 발전 제안과 컨퍼런스 발표 중에 나온 내용을 프로토타입화하기 위한 Cpp프론트 컴파일러를 만들고 있다. 현재 이 프로토타입에는 C++를 위한 대안 신텍스 2가 포함된다. 대안 신텍스 2는 다른 방법으로는 단절적 변화(breaking change)가 되는 부분을 포함한 전체 설계를 가능하게 해준다.

서터의 Cpp프론트 회귀 모음에는 C++와 Cpp2 코드가 혼합된 예제 수십 개와 순수 Cpp2 예제 수십 개가 포함된다. 스트롭스트룹의 C프론트와 마찬가지로 서터의 Cpp프론트는 Cpp2를 바로 객체 코드로 컴파일하는 것이 가능해질 때까지 새 신텍스를 사용한 Cpp2 개발과 실험을 가능하게 해주는 다리 역할을 한다.
 

러스트, 카본, Cpp프론트의 성숙도

러스트와 카본, Cpp프론트는 모두 C++ 대체 언어를 지향한다. 카본은 5년 개발 주기를 가지고 있기에 프로덕션에 적용하기 위해서 몇 년 더 기다려야 할 것이다. Cpp프론트는 5년보다는 빨리 프로덕션용으로 나올 수 있고 러스트는 이미 일반 개발 업무에 충분히 쓸 수 있는 정도다. 세 언어 모두 C++와 바이너리 수준에서 상호 운용이 가능하거나 앞으로 그렇게 될 예정이다. 즉, 세 언어 모두 C++가 아닌 새 모듈을 추가함으로써 기존 C++ 프로그램에 대한 점진적 개선을 할 수 있다. 

Cpp프론트의 경우 C++와 Cpp2 소스 코드의 혼합은 적어도 부분적으로는 구현됐으며, 서터의 회귀 모음에 포함돼 있다. 카본 툴에는 C++ 소스 코드의 자동 마이그레이션이 포함될 예정이다. C++ 코드를 100% 마이그레이션할 것인지, 아니면 코드의 일부분을 수동으로 다시 써야 하고 그렇지 않을 경우 제대로 동작하지 않고 카본 표준을 위반하게 되는지, 또는 그대로 두고자 한다면 안전하지 않은 것으로 표시해야 하는지 등은 아직 정해지지 않았다. 

러스트는 이미 메모리 안전성을 입증했다. 따로 안전하지 않은 코드로 표시하지 않으면, 컴파일 자체가 되지 않는다. 카본과 Cpp프론트도 메모리 안전 메커니즘을 구현할 것이다. 단지 아직은 그게 어떤 형태가 될지 정확히 알 수 없다. 러스트는 C++를 아는 사람이라 해도 배우기가 쉽지는 않다. 다만 필자가 듣기로는 완전히 처음부터 새로 시작하는 사람인 경우 C++보다는 러스트를 배우는 쪽이 조금 더 쉽다고 한다. 어쨌든 C++와 고 프로그래머는 보통 1~2주 정도면 러스트의 감을 잡을 수 있다.

허브 서터의 Cpp2의 경우 현재 Cpp프론트가 생성하는 C++는 상당히 지저분하지만, 확실한 점은 C++ 프로그래머 입장에서 전환하기는 비교적 쉽다는 것이다. 카본의 C++ 전환 툴은 기본 자바 코드의 변환으로 코틀린 학습을 지원하는 인텔리J와 비슷한 방식으로 병렬 편집 도구를 가능하게 해야 한다. 결국 스트롭스트룹이 카본에 대한 언급에서 암시했듯이 각 언어와 그 툴이 어떻게 발전해 나갈지는 더 지켜봐야 알 수 있을 것이다.
editor@itworld.co.kr
 Tags 러스트 CPP프론트 카본
Sponsored
IDG 설문조사

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

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

Copyright © 2022 International Data Group. All rights reserved.