많은 소프트웨어 프로젝트가 등장하는 이유는 어딘가에서 프로그래머가 개인적인 문제를 해결해야 했기 때문이다.

그런 일은 그레이든 호어(Graydon Hoare)에게도 일어났다. 2006년, 호어는 오픈소스 브라우저 회사 모질라(Mozilla)에서 일하는 29세의 컴퓨터 프로그래머였다. 어느 날 그가 밴쿠버에 있는 아파트로 평소처럼 귀가했더니 엘리베이터가 고장 나 있었다. 엘리베이터 소프트웨어에 충돌이 일어난 것이었다. 사실 엘리베이터 고장은 처음 일어난 일도 아니었다.

호어의 집은 21층이었다. 그는 계단을 오르면서 짜증이 났고 “컴퓨터 프로그래머들이 충돌 없이 작동하는 엘리베이터도 만들지 못하는 게 어처구니없다!”고 생각했다. 호어는 프로그램이 메모리를 사용하는 방식 때문에 이런 충돌이 발생한다는 것을 알고 있었다. 엘리베이터 같은 장치의 내부 소프트웨어는 흔히 C++이나 C언어 같은 프로그래밍 언어로 작성되며, 프로그래머들이 두 언어를 사용해 매우 빠르게 실행되는 간결한 코드를 작성할 수 있다. 그러나 C++이나 C언어를 사용하면 충돌을 일으키는 오류인 ‘메모리 버그’가 쉽게 발생하는 것이 문제다. 마이크로소프트(Microsoft)는 자사 코드의 취약점 가운데 70%가 이들 언어로 작성된 코드의 메모리 오류 때문인 것으로 추정한다.

대부분의 사람은 21층까지 계단을 터벅터벅 걸어 올라가야 하는 상황과 마주하면 화를 내는 게 전부이다. 그러나 호어는 이 상황에서 뭔가를 하기로 결정했다. 그는 노트북을 열고 새 컴퓨터 언어를 설계하기 시작했다. 간단하고 빠르지만, 메모리 버그가 없는 코드를 작성하는 언어 설계가 목표였다. 그는 생존을 위해 ‘과도하게 설계(over-engineering)’된 매우 강인한 곰팡이류의 이름을 따서 새 언어에 ‘러스트(Rust)’라는 이름을 붙였다.

그로부터 17년이 지난 현재, 러스트는 세계에서 가장 인기 있는 새 언어가 되었다. 러스트를 사용해서 코딩하는 프로그래머는 280만 명에 달하며, 마이크로소프트에서 아마존에 이르기까지 수많은 기업이 러스트를 미래의 핵심 언어로 보고 있다. 채팅 플랫폼 디스코드(Discord)는 러스트를 사용해 시스템 속도를 개선했고, 드롭박스(Dropbox)는 이용자 컴퓨터와의 파일 동기화에 러스트를 사용했다. 클라우드플레어(Cloudflare)는 러스트를 이용해 인터넷 트래픽의 20% 이상을 처리한다.

개발자들의 토론 게시판 ‘스택 오버플로(Stack Overflow)’가 전 세계 개발자를 대상으로 실시한 연례 여론조사에서 러스트는 7년 연속 가장 ‘사랑받는’ 프로그래밍 언어로 뽑혔다. 심지어 미국 정부도 프로세스를 더 안전하게 만드는 방법으로 러스트 소프트웨어를 열정적으로 홍보하고 있다. 다른 성공적인 오픈소스 프로젝트처럼 러스트도 많은 ‘자원봉사자’에 의해 관리되고 있으며, 현재는 충성심 강한 수백 명의 자발적인 기여자가 도움을 주고 있다. 호어는 모질라의 핵심 팀을 포함한 다른 엔지니어들에게 러스트 프로젝트를 넘겨주고 2013년 기쁜 마음으로 프로젝트에서 물러났다.

누군가가 새 컴퓨터 언어를 만드는 것이 드문 일은 아니다. 수많은 개발자가 사이드 프로젝트로 작은 언어들을 만든다. 그러나 그렇게 만들어진 새 언어가 제대로 자리 잡고 자바스크립트(JavaScript)나 파이선(Python), 자바(Java) 같은 잘 알려진 언어와 어깨를 나란히 하는 일은 유성 충돌만큼이나 드문 일이다. 그렇다면 러스트는 어떻게 그런 일을 해낸 것일까?

러스트가 그렇게 유용한 이유를 이해하기 위해서는 프로그래밍 언어가 컴퓨터 메모리를 다루는 방식을 들여다볼 필요가 있다.

단순하게 가정해보면 컴퓨터의 동적 메모리를 칠판에 비유할 수 있다. 소프트웨어는 실행되는 동안 동적 메모리라는 칠판에 끊임없이 작은 데이터 조각들을 맞추면서 데이터 위치를 추적하고, 데이터가 필요하지 않으면 칠판에서 지운다. 그러나 각기 다른 컴퓨터 언어들은 이 작업을 다른 방식으로 처리한다. C나 C++ 같은 오래된 언어는 소프트웨어가 칠판을 사용하는 방식과 시기 관련해서 프로그래머에게 많은 권한을 주기 위해 설계됐다. 그 권한은 유용하다. 동적 메모리를 더 많이 통제할 수 있으면 프로그래머는 소프트웨어 실행 속도를 높일 수 있다. 이런 이유로 C와 C++은 하드웨어와 직접 상호작용하는 코드의 일종인 ‘베어메탈(bare metal)’ 코드를 작성하는 데 자주 사용된다. 투석(dialysis) 기계부터 금전등록기에 이르기까지 윈도(Windows)나 리눅스(Linux) 같은 운영체제가 없는 기기들은 베어메탈 코드로 실행된다. (베어메탈 코드는 어느 시점에 운영체제가 하드웨어와 통신해야 하는 고급 시스템에서도 사용된다. 윈도, 리눅스, 맥(Mac)OS 커널은 모두 상당 부분 C 언어로 작성되어 있다.)

“러스트를 쓰는 건 즐겁다. 말이 조금 이상하게 들릴 수 있지만, 러스트는 환상적인 언어고 재미있다. 러스트를 쓰고 있으면 마법사가 된 듯한 기분을 느낄 수 있다. 이는 다른 언어를 쓸 때는 절대 일어나지 않는 일이다.”

파커 팀머만, 소프트웨어 엔지니어

그러나 C나 C++ 같은 언어는 속도가 빠른 대신 그로 인해 발생하는 단점도 있다. 그런 언어를 사용할 때 프로그래머는 어떤 메모리에 데이터가 기록되고 있는지, 언제 기록이 지워지는지 계속해서 주의 깊게 살펴보아야 한다. 그러다가 깜빡하고 기록된 내용을 삭제하지 않으면 충돌이 일어난다. 실제로 무언가가 기록되어 있는 메모리 공간을 소프트웨어가 비어 있다고 착각해 사용하려고 할 수 있기 때문이다. 또는 디지털 침입자가 몰래 숨어 들어올 빌미를 제공할 수도 있다. 프로그램이 메모리를 제대로 정리하지 않아서 지워졌어야 할 정보(비밀번호, 금융 정보 등)가 아직 남아 있는 것을 해커가 알게 되면 해당 데이터를 몰래 수집할 수도 있다. C나 C++ 코드 부분이 점점 늘어나면 매우 신중한 프로그래머도 수많은 메모리 오류를 범하면서 소프트웨어를 버그로 채울 가능성이 있다.

드론 업체 퓨전 엔지니어링(Fusion Engineering)의 공동 설립자이자 러스트의 라이브러리팀 책임자인 마라 보스(Mara Bos)는 “C나 C++을 사용할 때 코드가 언제든지 무작위로 문제를 일으킬 수 있다는 두려움을 갖게 된다”고 설명한다.

90년대에는 자바, 자바스크립트, 파이선 같은 새로운 언어들이 인기를 끌었다. 이 언어들은 매우 다른 접근법을 취했다. 프로그래머들의 스트레스를 줄이기 위해 이들 소프트웨어가 실행되고 있을 때 주기적으로 메모리를 청소하는 ‘가비지 컬렉터(garbage collector)’로 관리했다. 그러면 메모리 오류가 발생하지 않는 코드를 작성할 수 있다. 메모리에 대한 프로그래머의 세분화된 통제권이 사라진 것은 단점이었다. 게다가 자동으로 메모리를 청소하는 데 상당한 처리 시간이 필요했기 때문에 프로그램 실행 속도가 느려질 수밖에 없었다. 이들 언어로 작성된 소프트웨어는 더 많은 메모리를 사용한다. 결과적으로 프로그래밍의 세계는 대략 두 부류로 나눠지게 되었다. 빠르게 실행되어야 하는 소프트웨어나 각종 기기 제어용 내장 소프트웨어의 경우에는 C나 C++로 작성되고, 코드 세계에서 점점 더 큰 부분을 차지하고 있는 휴대폰 앱이나 웹 앱의 경우에는 자동 메모리 청소가 가능한 새 언어들이 사용되었다.

호어는 이 두 접근법의 장점을 절충한 언어를 만들려는 목적으로 러스트를 설계했다. 러스트를 사용하면 프로그래머는 데이터가 입력되는 메모리 공간이 어디인지 수동으로 파악할 필요가 없다. 그런 작업은 러스트가 알아서 처리한다. 그러나 러스트는 프로그램 내부에서 데이터가 사용되거나 복제되는 방식에 다수의 엄격한 규칙을 부과한다. 프로그래머는 그런 코딩 규칙을 배워야 하기 때문에 이 부분은 파이선이나 자바스크립트를 사용할 때보다 더 번거롭다. 코드를 작성하는 것이 더 어려울 수 있지만, 그래도 실수로 치명적인 메모리 버그를 삽입할지도 모른다는 두려움은 가질 필요가 없다. 메모리는 안전하다. 결정적으로, 러스트는 ‘동시성 안전(concurrency safety)’도 제공한다. 다시 말해 현재의 프로그램들은 한 번에 다양한 작업을 수행한다. 코드의 다른 스레드(컴퓨터에서 연속적으로 실행되고 있는 프로그램 내에서 실행되는 여러 흐름의 단위)가 거의 동시에 동일한 메모리 공간을 수정하려고 할 수 있는데, 러스트의 메모리 시스템은 이러한 현상을 방지한다.

러스트 설계를 시작하려고 노트북을 처음 열었을 때 호어는 이미 10년 차 베테랑 프로그래머로서 모질라에서 풀타임으로 근무하고 있었다. 러스트는 처음에 사이드 프로젝트에 불과했다. 호어는 몇 년 동안 작업에 매달렸다. 그가 마침내 다른 개발자들에게 러스트를 공개했을 때 반응은 엇갈렸다. 이메일에서 호어는 “열광하는 사람도 있었지만, 의구심을 갖거나 러스트가 절대 제대로 작동하지 않을 것이라고 말하는 이들도 많았다”고 말했다.

그러나 모질라의 임원들은 흥미를 느꼈다. 그들은 더 나은 브라우저 엔진을 구축하는 데 러스트가 도움이 될 수 있다는 것을 깨달았다. 브라우저는 위험한 메모리 버그가 발생할 가능성이 많은 복잡한 소프트웨어로 악명 높다.

러스트에 관여한 직원 중에는 프로그래밍 언어 박사 과정을 떠나서 모질라에 합류한 패트릭 월턴(Patrick Walton)이 있었다. 그는 자바스크립트의 개발자 브렌던 아이크(Brendan Eich)가 ‘러스트에 대한 디자인 결정을 논의할 예정인데 함께하지 않겠느냐’며 자신을 모질라 회의실로 이끌었다고 설명한다. 월턴은 러스트가 환상적이라고 생각했고 언어 개발을 위한 엔지니어팀에 합류했다. 또 다른 팀원인 모질라 엔지니어 니코 마차키스(Niko Matsakis)와 펠릭스 클락(Felix Klock)은 메모리와 코딩 언어에 대해 학문적으로 연구한 경험이 있었다.

모질라 임원들은 러스트가 더 나은 브라우저 구축에 도움이 될 수 있음을 깨닫고 여러 엔지니어를 프로젝트에 투입했다. 여기에는 프로그래밍 언어 박사 과정을 떠나서 모질라에 합류한 패트릭 월턴(1), 메모리와 코딩 언어에 대해 학문적으로 연구한 경험이 있었던 니코 마차키스(2)와 펠릭스 클락(3), 현재 러스트 개발자 도구팀을 운영하고 있는 마니시 고레가오카르(4)가 있다.

2009년, 모질라는 러스트를 공식적으로 후원하기로 결정했다. 러스트는 오픈소스이므로 개발자들에게 운영 책임이 있지만, 모질라는 엔지니어들에게 기꺼이 돈을 주고 러스트 개발을 지원하기 시작했다. 러스트팀은 모질라의 회의실을 차지했다. 모질라 리서치(Mozilla Research)의 공동 설립자 데이브 허먼(Dave Herman)은 이 회의실에 ‘너드 소굴(the nerd cave)’이라는 별명을 붙이고 문 앞에 이름표를 붙였다. 그로부터 10년 동안 모질라는 러스트를 담당할 풀타임 엔지니어를 십여 명 고용한 것으로 호어는 추정한다.

월턴은 “무언가 대단한 것을 만들고 있다고 모두가 느꼈다”고 당시를 회상한다. 그러한 흥분은 모질라 건물 바깥으로까지 확장됐다. 2010년대 초, 러스트는 전 세계 모든 기술 분야에서 자원봉사자들을 끌어모으고 있었다. 그중에는 빅테크(big tech) 직원들도 있었다. 주요 기여자 중 한 명은 독일의 고등학생이었다. 월턴은 2010년 브리티시 컬럼비아에서 열린 모질라 콘퍼런스에서 일어난 일을 기억한다. 콘퍼런스에서 아이크는 실험적인 언어의 강연이 있을 거라고 하면서 “프로그래밍 언어에 푹 빠진 진정한 너드가 아니면 참석하지 말라”고 당부했다. 그리고 당연히 강연실은 가득 찼다.

2010년대 초까지 모질라 엔지니어들과 전 세계에서 자원한 기여자들은 러스트의 핵심인 ‘메모리 관리 방식’을 점차 다듬어갔다. 그들은 ‘소유권(ownership)’이라는 시스템을 만들어서 데이터가 하나의 변수로만 참조될 수 있도록 했다. 이러한 시스템은 메모리에 문제가 발생할 가능성을 현저히 줄인다. 러스트의 컴파일러(compiler, 작성한 코드를 컴퓨터에서 실행되는 소프트웨어로 변환하는 프로그램)는 소유권 규칙을 엄격하게 적용한다. 프로그래머가 해당 규칙을 위반하면 컴파일러는 코드를 변환하여 실행 가능한 프로그램으로 바꾸는 작업을 거부한다.

러스트가 사용하는 많은 방식은 새로운 것이 아니었다. 러스트는 개발자도구팀을 운영하는데 러스트 개발 초기 모질라에서 근무한 마니시 고레가오카르(Manish Goregaokar)는 “그 방식들은 거의 수십 년 된 연구들이었다”고 말한다. 그러나 러스트 엔지니어들은 잘 다듬어진 이러한 개념들을 발견하여 실용적이고 유용한 기능으로 능숙하게 전환했다.

팀이 메모리 관리 시스템을 개선하면서 러스트에는 자체적인 가비지 컬렉터가 필요하지 않게 되었고 2013년 가비지 컬렉터를 제거했다. 컴퓨터가 메모리 청소를 수행할 때 주기적으로 중단되던 일이 없어지면서, 러스트로 작성한 프로그램은 더 빠르게 실행될 수 있었다. 호어는 러스트가 여전히 가비지 컬렉터 같은 요소를 가지고 있다고 주장하는 소프트웨어 엔지니어들도 있을 거라고 지적한다. 그들이 말하는 요소는 ‘참조 카운팅(reference counting)’ 시스템이라고 불리는데 러스트의 메모리 소유권 작동 방식에 포함된다. 그러나 어느 쪽이든 러스트는 놀라울 만큼 효율적인 성능을 갖게 되었다. 러스트는 C와 C++에 가까워졌지만, 메모리는 안전했다.

2012년에 러스트에 관여했고 그 후로 10년 동안 관련 문서를 작성한 프로그래머 스티브 클라브닉(Steve Klabnik)은 가비지 컬렉터를 제거하면서 “더 효율적이고 성공적인 언어가 탄생했다”고 설명한다.

그 과정에서 러스트 커뮤니티는 새로 온 사람들에게 유난히 친절하고 개방적인 것으로 알려진 문화도 만들고 있었다. 당시 모질라의 러스트팀에서 일했던 마이크로소프트의 수석 엔지니어 넬 샴렐 해링턴(Nell Shamrell-Harrington)은 “아무도 상대를 ‘초짜’라고 부르지 않는다”며 “어떤 질문도 바보 같은 질문으로 여겨지지 않는다”고 설명한다.

그녀는 이러한 태도가 문화가 된 건, 호어가 조기에 러스트 기여자라면 누구든 준수해야 하는 ‘행동강령’을 게시했기 때문이라고 생각한다. 그 행동강령은 괴롭힘을 금지하는 내용을 담고 있었다. 러스트 커뮤니티는 해당 규칙을 수용했다. 러스트 커뮤니티의 오랜 구성원들은 그러한 규칙 덕분에 다른 언어 커뮤니티보다 러스트 커뮤니티에 성 소수자 개발자들의 비율이 더 높다고 설명한다. 심지어 프로그래머가 실수했을 때 러스트 컴파일러가 띄우는 오류 메시지도 이례적으로 세심하다. 오류 메시지는 오류 내용을 설명하면서 정중하게 수정 방법을 제안한다.

샴렐 해링턴은 “C와 C++ 컴파일러는 내가 실수하면 스스로 형편없는 사람인 것처럼 느끼게 한다”고 웃으면서 말한다. 반면에 “러스트 컴파일러는 매우 안전한 코드를 작성할 수 있도록 안내해주는 것 같다”고 덧붙였다.

2015년까지 팀은 기업들이 실제 고객을 위한 소프트웨어 개발에 사용할 수 있을 정도로 신뢰할 수 있는 ‘안정적인’ 버전의 러스트를 최종적으로 출시하는 데 몰두했다. 모질라가 러스트를 산하에 둔 지 6년이 지난 시점이었다. 오랜 개발 기간 동안 프로그래머들은 품질이 좋지 않더라도 러스트의 데모 버전을 열정적으로 테스트했다. 고레가오카르는 “컴파일러가 계속해서 문제를 일으켰다”고 당시를 회상했다. 이제 러스트 ‘1.0’ 버전이 마침내 세상에 나올 차례였다.

월턴은 노트북을 들여다보면서 몇 시간을 보냈던 일을 기억한다. 클라브닉은 “마지막 2주 동안 45페이지에 달하는 문서 작업을 했다”고 당시를 회상한다. 마침내 2015년 5월 15일, 팀은 러스트의 첫 번째 버전을 발표했다. 전 세계의 ‘러스트 너드’들은 모여서 축하 파티를 벌였다.

모질라의 투자는 곧 성과를 내기 시작했다. 2016년, 모질라의 한 개발팀은 러스트를 사용하여 구축한 새로운 브라우저 엔진 ‘서보(Servo)’를 출시했다. 다음 해, 또 다른 팀이 웹사이트가 표시되는 방법을 구체화하는 데 사용하는 언어인 CSS를 렌더링하는 파이어폭스(Firefox)의 일부 코드를 러스트로 다시 작성했다. 이를 통해 파이어폭스의 성능이 눈에 띄게 향상되었다. 모질라는 MP4 멀티미디어 파일을 처리할 때 악성 코드를 수용할 위험이 있는 코드도 러스트로 다시 작성했다.

스스로를 ‘러스타시안(Rustacean)’이라고 부르는 러스트 개발자들은 다른 회사도 러스트 도입을 시작했다는 소식을 곧 듣게 되었다.

삼성 개발자들은 프랑스의 모질라 사무소에서 근무하고 있던 클락에게 러스트를 사용하기 시작했다고 밝혔다. 페이스북(Facebook, 이후 메타로 사명 변경)은 프로그래머들이 내부 소스 코드를 관리하는 데 사용하는 소프트웨어를 러스트로 재설계했다. 현재 메타(Meta)에서 일하고 있는 월턴은 “이는 이루 말할 수 없을 정도로 중요한 일”이었다고 말한다.

곧 러스트는 매우 중요한 소프트웨어의 핵심에 등장하기 시작했다. 2020년, 드롭박스는 러스트로 다시 작성한 새로운 ‘동기화 엔진(sync engine, 이용자의 컴퓨터와 드롭박스 클라우드 공간의 파일 동기화를 지원하는 소프트웨어)’을 공개했다. 이 시스템은 원래 파이선으로 작성됐지만, 당시 파일 수십억 개(그리고 온라인으로 동기화된 파일 수조 개)를 처리하고 있었다. 최근 드롭박스를 떠난 소프트웨어 엔지니어 파커 팀머만(Parker Timmerman)은 “러스트 덕분에 그 복잡한 작업을 더 쉽고 심지어 쾌적하게 처리할 수 있었다”고 설명한다.

그는 “러스트를 쓰는 건 즐겁다. 말이 조금 이상하게 들릴 수 있지만, 러스트는 환상적인 언어고 재미있다. 러스트를 쓰고 있으면 마법사가 된 듯한 기분을 느낄 수 있다. 이는 다른 언어를 쓸 때는 절대 일어나지 않는 일이다”라고 말하며, “우리는 확실히 엄청난 승부를 걸었다. 그건 신기술이다”라고 덧붙였다.

일부 기업은 러스트가 메모리 버그에 대한 두려움을 완화시켰다는 것을 인지하고 있었다. 마라 보스는 러스트를 사용해서 자사의 드론 제어용 소프트웨어를 다시 코딩했다. 원래는 C++로 작성된 소프트웨어였다.

다른 기업들은 가비지 컬렉터가 사라진 기쁨을 누리고 있었다. 디스코드의 엔지니어들은 소프트웨어의 많은 부분에 사용했던 고(Go) 언어의 가비지 컬렉터가 자꾸 속도 저하를 일으키는 것에 오랫동안 불만을 품고 있었다. 엔지니어들은 가비지 컬렉터가 작동할 필요가 없을 정도로 코드를 신중하게 작성했지만, 해당 소프트웨어에서는 2분마다 가비지 컬렉터가 실행됐다. 결국 2020년에 엔지니어들은 시스템을 러스트로 바꿨고, 소프트웨어 구동 속도가 10배 더 빨라지게 되었다.

아마존(Amazon)의 클라우드 컴퓨팅 플랫폼인 아마존 웹 서비스(Amazon Web Services, AWS)의 임원과 엔지니어들도 러스트로 더 안전하고 빠른 코드를 작성할 수 있다고 확신하고 있다. 지난해 회사를 떠나기 전, AWS에 러스트팀을 만들었던 셰인 밀러(Shane Miller)는 “러스트는 다른 언어에서 얻을 수 없는 이점을 제공하는 특별한 위치에 있다. 러스트를 사용하면 한 가지 언어로 여러 가지 능력을 확보할 수 있다”고 말한다.

러스트 기반 코드에 관한 한 연구에서 AWS가 가장 중요하게 생각할 듯한 내용을 발견했다. 연구에 따르면 러스트로 작성한 코드는 AWS에서 일반적으로 사용하는 자바 언어로 작성한 유사 프로그램과 비교해도 전력을 절반밖에 사용하지 않을 정도로 효율적인 것으로 나타났다. 밀러는 “현재의 두 배에 달하는 작업량 처리 데이터 센터를 만들 수 있다”고 말한다. 또는 크기가 절반에 불과한 데이터 센터에서 현재의 작업량을 처리할 수도 있다. 그러면 데이터 센터를 교외가 아닌 도시 안에 만들 수도 있을 것이다.

일부 오랜 기여자들은 러스트의 성공에 다소 긴장하고 있다. 거대 기술 기업들이 러스트를 채택하면서 러스트에 대한 그들의 영향력도 커지고 있기 때문이다. 그런 기업들은 엔지니어들을 고용해서 러스트 개발에 시간을 쏟게 할 만큼 자본이 많다. 예를 들어 러스트팀 리더 중 몇몇은 아마존과 마이크로소프트의 직원들이다. 다른 기여자들은 남는 시간에 러스트 업무를 처리해야 한다. 예를 들어 보스(Bos)는 화웨이(Huawei)에서 러스트 계약직 업무를 하면서 동시에 드론 스타트업을 운영하고 있다. 러스트 라이브러리팀의 책임자 역할은 무급으로 담당한다.

보스는 이런 현상이 오픈소스 프로젝트에서 흔히 나타난다고 설명한다. 대기업들은 프로젝트에 더 많이 관여할 여유가 있기 때문에 자신들에게 필요한 문제를 해결하는 쪽으로 프로젝트 방향을 바꿀 수 있지만, 규모가 작은 기업들은 그럴 수 없다. 보스는 “결과적으로 큰 기업들은 어느 정도 영향력을 가질 수밖에 없다”고 말한다. 그러나 그녀는 아직까지 경종을 울리는 행동을 한 기업은 없다고 설명한다. 러스트에 대한 아마존 개입을 우려하는 클라브닉(그는 작년에 러스트에서 손을 뗐다)도 보스의 의견에 동의한다. 그는 “그런 현상에 대해 우려하고 있다. 그러나 아직 심각하게 나쁜 상황은 아니라고 생각한다”고 말한다.

2021년 주요 기술 기업들은 자발적으로 러스트에 기여하고 있는 프로그래머들을 지원하기 위해 돈을 모아서 비영리 ‘러스트 재단(Rust Foundation)’을 설립했다. 출범 초기 2년 동안 밀러가 이끈 이 재단은 러스트의 주요 기능에 작업을 원하는 프로그래머들에게 2만 달러(약 2,600만 원)의 보조금을 제공하고, 단기적으로 재정 지원이 필요한 기여자들에게 ‘생계 보조금’을 지급한다. 또 러스트 코드를 호스팅하는 서버에 자금을 지원하고 서버의 24시간 연중무휴 운영을 보장하는 기술 회사에도 비용을 지급한다. 밀러에 따르면 기존의 오픈소스 방식에서는 “기본적으로 인생의 50%를 쏟아부은 두 명의 자원봉사자”가 그런 작업을 담당했다고 말하면서 “둘 중 한 명은 이탈리아에 사는 학생이었다”고 덧붙였다.

러스트는 놀라울 정도로 빠르게 성장했다. 2006년에 처음 탄생한 러스트는 이제 청소년기를 지나 성숙기로 접어들었다. 자동차 회사들은 자동차 운행에 중요한 코드를 작업하는 데 러스트를 도입하고 있다. 항공우주 기업들도 러스트를 활용하고 있다. 드롭박스의 팀머만은 “러스트는 모든 곳에서 사용될 것”이라고 예측한다. 마이크로소프트 경영진은 심지어 다른 많은 기업이 비공개로 고민하고 있을 가능성이 있는 내용을 공개적으로 제안했다. 새로운 코드에 러스트 사용을 늘리고 C와 C++ 사용을 줄이다가 결국에는 아예 사용을 중단하겠다는 것이다.

지금도 사용되고 있는 오래된 C와 C++ 코드가 사라지지는 않을 것이다. 아마도 수십 년 동안 계속해서 남아 있을 것이다. 그러나 러스트가 빠른 실행 속도를 필요로 하는 새로운 베어메탈 코드 작성의 일반적인 방법이 된다면, 매년 점진적으로 우리의 소프트웨어 지형이 더 믿을 수 있고 안정적이며 충돌 취약성이 낮은 방향으로 바뀌는 모습을 목격하게 될지도 모른다.

이러한 상황에 가장 놀라게 될 이는 당연히 호어일 것이다. 그는 “대부분의 언어는 제대로 열매를 맺지 못하고 죽는다”고 말했다. 

*이 글을 쓴 클라이브 톰슨(Clive Thompson)은 뉴욕시에 거주하는 과학기술 저널리스트이며, 《은밀한 설계자들: 세상을 변화시키는 새로운 종족》(원제: Coders: The Making of a New Tribe and the Remaking of the World)의 저자이다.