Jan David Nose 인터뷰 | Rust 블로그

콘텐츠 팀은 미국 워싱턴 주 시애틀에서 열린 RustConf 2025에서 첫 번째 바쁜 대외 활동을 진행했습니다. 그곳에서 우리는 프로젝트와 더 넓은 커뮤니티에서 일어나고 있는 흥미로운 일들에 대해 여러 사람과 이야기를 나눌 수 있었습니다.

Jan David Nose, 인프라 팀

이 인터뷰에서 Xander Cesari는 당시 인프라 팀의 전담 엔지니어 중 한 명이었던 Jan David Nose와 마주 앉았습니다. 인프라 팀은 Rust가 개발되고 배포되는 기반 인프라—CI/CD 도구와 crates.io를 포함해—를 유지·개선하는 일을 합니다.

최근 소프트웨어 공급망 공격 이슈와 관련해, 우리는 이 영상을 평소보다 빠른 일정으로 몇 주 먼저 공개했지만, 인터뷰 자체는 다른 언어와 생태계에서 패키지 공격이 드러나기 이전에 진행되었습니다.

인터뷰 영상을 여기에서 시청하시거나 아래를 클릭해 보세요.

---

대본

Xander Cesari: 안녕하세요, Rust 프로젝트 콘텐츠 팀의 Xander Cesari입니다. 지금은 시애틀에서 열리고 있는 RustConf 2025 마지막 날, 마지막 한 시간에 녹음을 하고 있습니다. 정말 길면서도 놀라운 이틀이었는데요. 지금 저는 Rust 언어의 알려지지 않은 영웅들인 Rust 프로젝트 인프라 팀의 팀원 한 분과 함께 앉아 있습니다. 자기소개와 어떻게 참여하게 되었는지 이야기해 주시겠어요?

Jan David Nose: 네, 물론이죠. 저는 JD입니다. 풀네임은 Jan David인데, 특히 국제적인 상황에서는 그냥 JD라고 합니다. 저는 지난 3년간 Rust 재단의 정규 직원으로 일해 왔고, 사실상 풀타임으로 오픈 소스에 기여하는 ‘잭팟’을 맞았다고 할 수 있겠네요. 그동안 내내 Rust 프로젝트 인프라 팀에 있었고요. 지난 2년간은 Jake와 함께 팀 리드를 맡고 있습니다. 인프라 팀은 여러 조각으로 이루어져 있지만, 한마디로 Rust가 가능하도록 만드는 역할을 하는 팀입니다.

Xander Cesari: 인프라 팀의 책임 범위를 대략적으로 설명해 주실 수 있을까요?

Jan David Nose: 물론이죠. 높은 수준에서 보면, 우리는 두 개의 다른 집단을 지원한다고 생각합니다. 한쪽에는 언어의 사용자들이 있고, 다른 한쪽에는 언어를 유지 관리하는 사람들에게 좋은 도구를 제공하려고 합니다.

Jan David Nose: 먼저 유지 관리자 측면부터 이야기해 보겠습니다. 이는 Rust가 어떻게 빌드되는지와 관련된 모든 것을 의미합니다. 누군가 기여를 하거나 PR을 올리는 순간부터, 우리는 그 PR이 실제로 잘 동작하는지 확인하는 지속적 통합(continuous integration)을 운영합니다. 현재 상태를 양호하고 일관된 상태로 유지하기 위해 배경에서 돕는 봇과 도구들이 많이 있습니다. GitHub에서 라벨을 달고 사람을 멘션하는 등의 사소하지만 중요한 triage 도구들도 많고요. 이런 부분들이 인프라 팀 전체가 관리하는 범위입니다.

Jan David Nose: 그리고 사용자 측면에서는, 가장 중요한 두 가지는 사용자가 실제로 Rust를 다운로드할 수 있도록 보장하는 것입니다. 우리는 crates.io 자체를 개발하는 팀은 아니지만, 사용자에게 크레이트를 전달하는 데 필요한 인프라를 지원합니다. 모든 다운로드는 우리가 운영하는 콘텐츠 전송 네트워크(CDN)를 거칩니다. Rust 릴리스도 마찬가지고요. 그래서 제가 제 일을 잘 못하면—실제로 그런 적도 있었고요—전 세계적인 crates.io 장애가 발생해 아무도 뭔가를 다운로드하지 못하는 사태가 날 수도 있습니다. 대략 이런 두 개의 큰 서비스 영역을 우리가 운영하고 있다고 보시면 됩니다.

Xander Cesari: 알겠습니다. 유지 관리자 쪽 얘기를 좀 더 해 보면, GitHub의 Rust 조직은 아주 크고 활동량이 많으며 코드도 방대합니다. GitHub에서 큰 코드베이스가 개발되는 사례는 많지만, Rust 같은 규모의 프로그래밍 언어 자체가 GitHub에서 개발되는 경우는 많지 않죠. 언어와 그에 필요한 도구를 개발하는 데에는 일반적인 소프트웨어 프로젝트와 다른 고유한 어려움이 있나요?

Jan David Nose: 언어 그 자체보다는, Rust의 생애 주기 초기에 내려진 몇 가지 아키텍처 결정과 더 관련된 점들이 떠오르네요. 특히 GitHub, 그리고 GitHub가 우리에게 불편을 토로한 덕에 우리에게도 골칫거리가 되었던 것 중 하나는, 꽤 오랫동안 crates.io의 인덱스가 GitHub의 Git 저장소였다는 점입니다. Rust가 성장하면서 해당 저장소의 활동량이 너무 많아졌고, 그 단일 저장소가 소모하는 리소스가 너무 커져 GitHub 입장에서 곤란한 상황을 야기했습니다(아주 점잖게 표현하자면 그렇습니다). 그게 계기가 되어 HTTP 기반의 웹 인덱스로 옮기는 작업이 시작됐습니다. 이건 Rust가 플랫폼과 잘 맞지 않는 부분이 있었고, 동시에 플랫폼 제공자 입장에서도 Rust 때문에 고생하게 되는 사례였죠.

Jan David Nose: Rust 자체로 돌아가서 특히 CI를 보면, 우리는 Rust가 지원하는 모든 타깃과 플랫폼에서 잘 동작하는지 확인하고 싶어 합니다. 그 말은 곧, 극도로 폭넓은 CI 파이프라인을 운용한다는 뜻입니다. 모든 Tier 1 타깃에 대해 모든 테스트를 돌리고, 릴리스 아티팩트를 빌드하고, 그걸 전부 S3에 업로드하죠. Tier 2 타깃에 대해서도 가능한 한 많은 걸 하려고 하고, 어느 정도는 Tier 3에서까지도 테스트를 돌리려 합니다. 그 결과 엄청난 규모의 빌드 파이프라인이 되었어요. 오늘 Marco가 지난 1년간 우리가 CI에서 무엇을 해 왔는지 발표를 했는데, 그 발표를 준비하면서 조사한 숫자 중 하나가 우리가 한 달에 누적 300만 빌드 분(minute)을 쓴다는 것이었습니다. CPU 시간으로 따지면 매달 약 6년에 해당합니다.

Jan David Nose: 특히 오픈 소스 프로젝트 관점에서 보면, 우리는 GitHub Actions를 가장 많이 사용하는 프로젝트 중 하나입니다. 전체적으로 봤을 때 가장 큰 소비자는 아니고, 상업적 프로젝트 중에는 훨씬 더 큰 데가 분명 있지만요. 그래도 커뮤니티에 최상의 서비스를 제공하고 우리가 내놓는 결과물이 고품질인지 확인하고자 하는 욕심 때문에, 이 규모를 관리하는 것이 우리에겐 고유한 도전 과제가 되었습니다. Rust가 점점 인기를 얻고 더 많은 플랫폼을 타깃으로 삼으려 할수록, 이 문제는 계속 커지는 문제이기도 하고요.

Jan David Nose: 우리가 어떤 타깃을 CI 파이프라인에서 빌드하고 테스트하기 시작하면, Tier 1 타깃들 중 일부는 클라우드 서비스 제공자에게 해당 하드웨어의 VM을 달라고 요청하기만 하면 되지만, 일부는 클라우드에서 그냥 실행할 수 있는 종류의 하드웨어가 아닐 수도 있습니다. 타깃을 제거하는 일은 아마 거의 없을 것이고요. 그래서 "지금도 이렇게 큰데, 5년, 10년, 15년 뒤에는 어떤 모습일까? 우리가 지향하는 품질 수준을 어떻게 유지할 수 있을까?" 같은 점을 고민해야 하는 흥미로운 과제가 됩니다.

Xander Cesari: 어딘가에 HIL(Hardware-In-the-Loop) 실험실 같은 게 있나요?

Jan David Nose: 지금 딱 그 이야기가 실제로 진행 중인 논의의 핵심을 건드리셨네요. 현재 우리의 타깃 티어 정책(target tier policy)에는 CI에서 돌아갈 수 있어야 한다는 조항이 있습니다. 그 말은 곧, 실제로 CI에서 돌리고 테스트할 수 있는 것만 엄선해서 Tier 1으로 승격시켜 왔다는 뜻입니다. 그리고 그동안의 전제는 GitHub Actions에서 실행 가능해야 한다는 것이었어요. 지금까지는 GitHub가 네이티브로 지원하거나 제공하는 하드웨어 외에는 거의 쓰지 않았습니다.

Jan David Nose: 그런데 바로 이 지점에서, Rust의 인기가 높아지면서 변화가 생겼습니다. 우리는 방금 IBM 플랫폼과 RISC-V 지원 요청을 받았는데, 이 플랫폼들은 GitHub에서 네이티브로 지원되지 않습니다. 이 때문에 "도대체 이걸 어떻게 지원할 것인가?"라는 내부 논의가 시작됐어요. 우리 프로젝트가 테스트용 하드웨어를 제공할 수 있는 기업들이 참여할 수 있도록 어떻게 지원할 수 있을지, 거기에 어떤 함의가 있는지 고민 중입니다.

Jan David Nose: 한편으로는 흥미로운 제약과 고려 사항이 있습니다. 예를 들어, 다른 사람의 하드웨어가 잠시 내려가 있다는 이유로 PR이 무작위로 실패하는 상황은 원하지 않겠죠. 우리는 이미 하루에 병합할 수 있는 PR 수 자체가 리소스 상 제한되어 있는 상황이라, 프로세스에 이런 잡음을 추가하면 Rust에 대한 기여 속도가 정말 크게 느려질 수 있습니다. 또 다른 한편으로는 보안 문제도 있습니다. 특히 어떤 타깃을 Tier 1으로 승격한다고 했을 때, 그 하드웨어에서 릴리스 아티팩트를 빌드하려면 그것들이 실제로 안전하고, 누군가가 RISC-V용 Rust 컴파일러 타깃에 백도어를 몰래 심지 못하도록 보장해야 합니다.

Jan David Nose: 우리가 사는 지금의 세상에서는 공급망 보안이 엄청난 화두이기 때문에, 이런 점이 특히 중요해요. Rust와 언어, 커뮤니티, 생태계 전체의 성장을 지원하면서도, 우리가 배포하는 것들이 신뢰할 수 있고, 안전하며, 성능도 좋은지를 동시에 보장하는 방법을 찾아야 합니다. 이것이 점점 더 중요하고 흥미로운 작업 영역이 되고 있어요. 지금까지는 GitHub가 지원하는 플랫폼 안에서만 어떻게든 버텨왔는데, 이제는 사람들이 우리에게 다가와 "하드웨어를 제공해 줄게요", "스폰서를 할게요", "우리 플랫폼에서 테스트하도록 도와줄게요"라고 제안하는 상황이 펼쳐지고 있는 게 정말 멋집니다. 다만, 아직 이 문제에 대한 좋은 정답은 없습니다. 외부 하드웨어를 사용하기 위해 무엇을 고려해야 하는지, 어떤 요건이 필요한지, 그 의미가 무엇인지 여전히 고민하고 있는 단계입니다.

Xander Cesari: 그렇죠, 모두가 Rust가 어디서나 돌아가기를 바라지만, 그걸 유지 관리하는 비용은 거의 기하급수적으로 커지는 느낌이네요.

Jan David Nose: 그 지점이 정말 흥미롭습니다. IBM을 예시로 들면, 이건 재미있는 사례죠. 집에 IBM 플랫폼을 갖고 있는 사람이 얼마나 될까요? 전 세계적으로 봐도 그 플랫폼의 사용자 수는 꽤 적습니다. 하지만 IBM은 Rust에 크게 투자하고 있고, 이를 현실로 만들려고 노력하며, 하드웨어를 제공할 의지도 있습니다.

Jan David Nose: 우리 입장에서는 이런 질문이 생깁니다. 어느 선까지 허용해야 할까? 플랫폼을 승격하기 위해 필요한 일정 수준의 사용량 같은 게 있어야 할까? 아니면 가능한 한 많은 플랫폼을 Tier 1으로 승격시키는 방향을 택할까? 이런 논의를 해야 할 필요 자체가 지금까지는 거의 없었습니다. Rust가 더 널리 채택되고 기업들이 여기에 진지하게 자금과 리소스를 투입하기 시작한 지금에서야 비로소 떠오르고 있는 주제죠. 그리고 그건 꽤 흥미로운 변화이기도 합니다.

Jan David Nose: 이 특정한 사례에서는, 기업들이 먼저 인프라 팀에 접근해서 "우리가 가진 플랫폼을 CI에 추가하려면 어떻게 해야 하나요?"를 묻습니다. 그게 Tier 1 지원을 향한 첫 단계가 되는 셈이죠. 하지만 더 넓게 보면, Rust 프로젝트의 더 큰 범위와도 나누어야 할 논의입니다. 예를 들어 Tier 1 승격의 경우, 컴파일러 팀의 승인도 필요하고, 인프라 팀의 승인도 필요합니다. 생태계 전체의 커지는 요구를 어떻게 뒷받침할 수 있을지 논의하는 데 훨씬 더 많은 사람들이 관여해야 합니다.

Xander Cesari: 이번 인터뷰 전체를 관통할 주제가 벌써 보이는 것 같네요.

Jan David Nose: 100% 그렇게 될 겁니다.

Xander Cesari: 이 파이프라인의 또 다른 도구 중에, 저는 꽤 오랫동안 전혀 모르고 있다가, 다른 컨퍼런스의 발표를 보고 알게 된 게 있습니다. 바로 Crater인데요. 인터넷에서 찾을 수 있는 모든 Rust 코드를 실행해 보려고 시도하는 도구라고 알고 있습니다. 이 도구가 무엇을 하는지, 그리고 릴리스 프로세스에 어떻게 통합되어 있는지 설명해 주실 수 있을까요?

Jan David Nose: 누군가 GitHub에서 Rust 컴파일러에 새로운 기능이나 버그 수정을 추가하는 PR을 만들면, 소위 Crater 실행(Crater run)이나 실험(experiment)을 시작할 수 있습니다. Crater는 사실상 큰 규모의 머신 플릿으로, 가능한 한 많은 크레이트를 가져오려고 합니다. 이상적으로는 모든 크레이트를 테스트하고 싶지만, 여러 이유로 그건 불가능합니다. 일부 크레이트는 안정적으로 빌드되지 않아서, 우리는 그런 크레이트를 제외하는 리스트를 유지하고 있어요. 정확한 수치는 기억이 가물가물하지만, 지금은 전체 크레이트의 대략 60% 정도를 테스트하는 걸로 알고 있습니다.

Jan David Nose: 이 실험은 PR의 코드를 가져와 그걸로 Rust 컴파일러를 빌드하고, 그 빌드된 컴파일러로 크레이트들을 빌드합니다. 그다음 제안한 변경에 따른 회귀(regression)가 있는지 보고해 주죠. 이는 새로운 버전과 새로운 기능을 도입할 때도 역호환성을 유지하는 데 매우 중요한 도구입니다. "컴파일러에 이 기능을 추가했을 때, 생태계가 여전히 잘 컴파일되는가? 어디에서 문제가 발생하는가?"를 물어볼 수 있게 해 주니까요. 그리고 그 다음 단계는 컴파일러 팀의 영역입니다. 이 정도의 깨짐(breakage)은 허용 가능한지, 기능을 조정해야 하는지 등을 결정해야 하죠. Crater가 있기 때문에, 이런 논의를 생태계 전체에 미치는 실제 영향 데이터를 바탕으로 할 수 있습니다.

Xander Cesari: Rust를 도입하는 기업이 늘면서, 언어가 얼마나 안정적이고 역호환적인지를 자주 묻는 것 같습니다. 다른 언어에서 대버전 업그레이드가 큰 혼란과 대규모 코드 수정으로 이어진 사례도 많이 들리고요. 코드를 crates.io에 올려두었다면, 컴파일러 팀이 역호환성을 위해 이미 그 코드를 테스트하고 있을 확률이 있다는 사실은 꽤 안심이 됩니다.

Jan David Nose: 네, 그럴 가능성이 꽤 높다고 생각합니다. 특히 Python 2에서 Python 3로의 마이그레이션을 떠올려 보면, 업계 전체가 그런 대규모 버전 점프에서 많은 걸 배운 것 같아요. 제가 컴파일러 팀 소속도 아니고, 당시 의사결정에 참여한 것도 아니라 팀을 대신해 말할 수는 없지만, Rust 설계에서 역호환성이 그렇게나 중요한 이유 중 하나가 바로 거기에 있다고 느낍니다. 우리는 가능한 한 고통 없이 최신 상태를 유지하고, 언어를 실수로 망가뜨리거나 생태계 전체가 한 번에 움직여야 하는 고통스러운 마이그레이션 지점을 만들지 않으려고 합니다.

Xander Cesari: Crater와 비슷한 걸 도입해서 내부의 사설 크레이트 저장소에 돌리는 조직이 있나요? 대형 기술 기업들이나 다른 컴파일러, 혹은 다른 언어 쪽에서요. 아니면 이건 진짜로 Rust 컴파일러 팀을 위해 특화된 도구인가요?

Jan David Nose: Crater 자체를 도구로 돌리는 다른 사례는 제가 아는 한 없습니다. 다만 Crater는 우리가 다른 곳에서도 사용하는 샌드박싱 프레임워크 위에 구축되어 있습니다. 예를 들어 docs.rs가 문서를 빌드할 때 같은 기반 인프라를 일부 사용합니다. 우리는 Crater 안에 있는 기능성을 가능한 한 다른 곳과 공유하려고 하지만, Crater를 우리와 같은 방식으로 사용하는 조직은 아직 들어본 적이 없습니다.

Xander Cesari: 알겠습니다. 또 다른 큰 부분은, 인프라 팀이 유지 관리자를 지원하는 동시에 crates.io에서 크레이트를 내려받는 Rust 사용자와 소비자도 지원한다는 점입니다. crates.io 자체는 팀 범위 밖이라고 하셨지만, 백엔드의 많은 부분을 지원하고 있는 것 같네요.

Jan David Nose: 네, 맞습니다. crates.io는 그 자체로 팀이 있고, 그 팀에서 웹 애플리케이션과 API를 유지 관리합니다. 사람들이 다운로드하는 실제 크레이트 파일들은 우리의 인프라에 호스팅되어 있습니다. 인프라 팀은 그 앞단에 있는 CDN을 운영합니다. 모든 크레이트 다운로드가 우리가 유지하는 인프라를 통과하죠. 우리는 이 공용 인터페이스에서 crates.io 팀과 아주 긴밀히 협업합니다. 그들은 앱과 API를 소유하고 있고, 우리는 파일이 최종 사용자에게 전달되도록 보장합니다.

Xander Cesari: crates.io에 새로운 버전이 올라갈 때마다 업로드된 파일에 대한 검증과 다양한 체크가 많이 이루어질 것 같은데, 그런 부분은 전부 crates.io 애플리케이션 내부에서 이루어지는 건가요?

Jan David Nose: Cargo는 crates.io API를 사용해 크레이트 파일을 업로드합니다. crates.io에는 그게 유효한지, 모든 게 올바른지 검증하는 내부 로직이 많이 들어 있습니다. 인프라 팀 입장에서는 그 부분을 블랙박스로 취급합니다. crates.io가 할 일을 하고, 업로드에 만족하면 그 파일을 S3에 저장합니다. 그 시점부터는 인프라가 파일을 접근 가능하게 만들고 다운로드할 수 있도록 해서, 사람들이 여러분의 크레이트를 사용할 수 있게 하는 일을 맡습니다.

Xander Cesari: Rust가 어느 정도 자신의 성공의 희생양이 된다는 주제로 다시 돌아가 보면, 모든 트래픽 그래프와 다운로드 그래프가 꾸준히 우상향일 것 같습니다.

Jan David Nose: 재단 쪽에서 동료 한 분이 크레이트 다운로드가 10억 건 늘어나는 데 얼마나 걸리는지를 자주 체크하시는데, 그 숫자가 계속 빠르게 줄고 있습니다. 3년 전에는 어땠는지 정확히 기억은 안 나지만, 몇 배 단위로 줄어든 건 확실합니다. 다운로드 트래픽에서는 분명한 지수 성장을 보고 있어요. 연간 다운로드 트래픽이 거의 2배씩 늘고 있고, 이 추세는 꽤 안정적입니다. Rust가 생태계에서 상당히 활발히 채택되고 있고, 사람들이 점점 더 다양한 용도로 쓰고 있다는 느낌을 받습니다.

Xander Cesari: 인프라 팀은 그 성장을 어떻게 따라가고 있나요? 앞서 나가고 있나요, 아니면 야근이 많나요?

Jan David Nose: 야근이 없었다고 하면 거짓말이겠죠. 제가 인프라 팀에서 일한 지난 3년 동안, 매년마다 다른 종류의 ‘불’을 끄는 게 팀의 테마였던 것 같습니다.

Jan David Nose: 어떤 문제를 해결하면 그다음 문제가 터지는 식으로 계속 바뀝니다. 다행히도 지금까지는 대부분의 화재가 동시에가 아니라 순차적으로 일어났어요. 제가 합류했을 때는 대역폭이 가장 큰 이슈였습니다. 작년에는 주로 CI가 이슈였고요. 3년 전쯤에는 트래픽이 두 배로 늘어나는 반면, 그 당시 우리가 받던 스폰서십 용량은 한계에 다다르는 변곡점에 도달했습니다.

Jan David Nose: 2~3년 전쯤 Fastly가 우리를 Fast Forward 프로그램에 받아 주었고, 그 이후로 우리 모든 대역폭을 후원해 주고 있습니다. 그 덕분에 저는 밤에 훨씬 잘 잘 수 있게 됐죠. Fastly와는 정말 좋은 관계를 유지하고 있고, 우리가 한계에 부딪힐지 모른다는 두려움을 지우는 데 매 순간 큰 도움을 주었습니다. 더 넓은 오픈 소스 커뮤니티에서도 굉장히 활발하게 활동하고 있고요. 가장 유명한 예로는 PyPI와 Python 생태계를 후원하고 있는데, 거기에 비하면 우리는 아주 작은 물고기에 가깝습니다. 그런 점이 우리에게도 이 성장세를 감당하고, 사람들이 기대하는 수준의 crates와 릴리스를 계속 제공할 수 있겠다는 큰 자신감을 줍니다.

Xander Cesari: 어떤 면에서는 Rust가 그 모든 인프라를 완전히 투명하게 만드는 데 정말 성공한 것 같아요. 터미널에서 그냥 Cargo 명령을 치면 모든 게 마법처럼 돌아가니까요.

Jan David Nose: 그 말은 듣기만 해도 기분이 좋네요. 오픈 소스 인프라 팀을 운영할 때 흥미로운 측면 중 하나가 바로 그런 부분입니다. Rust의 첫 안정 버전이 나온 지 10년, Rust 자체가 시작된 지는 15년쯤 됐다고 보면, 그 대부분 기간 동안 인프라는 자원봉사자들이 운영했습니다. 저는 여기 온 지 3년밖에 안 됐고, 첫 번째 전담 인프라 엔지니어였어요. 그러니 10~12년가량은 인프라를 전부 자원봉사자들이 돌린 셈이죠.

Jan David Nose: 그런 환경에서는 ‘그냥 잘 돌아가는 것’이 정말 중요했습니다. 서버에 불이 나거나 다운로드가 멈췄다고 해서, 새벽에 자원봉사자를 호출해서 페이지를 날릴 수는 없으니까요. 처음부터 우리의 인프라는 가능한 한 단순하고 신뢰할 수 있도록 설계되어 왔습니다. CDN도 마찬가지입니다. 저는 Fastly에게 항상 약간 죄송한 마음이 있어요. Fastly는 정말 놀라운 스폰서입니다. 컨퍼런스에서 만날 때마다, 혹은 새 기능을 발표할 때마다, "우리 새 기능 써 보실래요?", "프로덕션에서 Fastly를 어떻게 사용하고 있는지 이야기해 주실래요?"라고 묻는데, 매번 "저희 설정은 정말 단순합니다. HTTP 헤더 몇 개만 세팅했어요. 그게 전부입니다"라고 말해야 하거든요.

Jan David Nose: Fastly 플랫폼은 정말 멋지지만, 우리는 가장 작은 기능 집합만 쓰고 있습니다. 대부분 자원봉사자로 구성된 아주 작은 팀이 이 모든 걸 유지해야 하기 때문이죠. 프로젝트가 지속 가능하도록, 화려한 신기술을 쫓기보다는 항상 단순성과 신뢰성을 우선해 왔습니다.

Xander Cesari: 자원봉사 기반 조직은 워라밸을 신경 쓸 수밖에 없어 보이는데, 그건 굉장히 좋은 점이기도 하고, 거기서 배울 교훈도 많을 것 같네요.

Jan David Nose: 네, 확실히 아주 흥미로운 환경입니다. 일반적인 기업이나 상업 팀과는 작동 방식이 다르고, 다른 규칙이 있어요. 일정 기간에 우리가 얼마나 많은 일을 할 수 있는지 생각할 때, 자원봉사자들이 언제 시간을 낼 수 있을지, 언제 활동할지, 그들의 삶에서 무슨 일이 일어나는지 예측하기 어렵기 때문에 우리가 접근하는 방식도 달라야 합니다.

Jan David Nose: 지난 몇 년 동안 우리는 발생할 수 있는 화재의 개수를 줄이려고 노력해 왔고, 화재가 생기면 자원봉사자를 최대한 보호하고, 풀타임 직원이 그 부담을 떠안으려 해 왔습니다. 그 흐름이 3년 전 저부터 본격적으로 시작됐고, 작년에 Marco가 합류해 인프라 쪽에 쏟을 수 있는 역량이 늘었습니다. 인프라 측면에서 할 일이 워낙 많아서, 저 혼자 풀타임으로 일한다고 해도 인력이 턱없이 부족했거든요.

Xander Cesari: 그러니까 풀타임은 두 분이고, 나머지는 모두 자원봉사자인 거군요.

Jan David Nose: 네, 맞습니다. 팀 전체는 대략 8명 정도이고, 그중 Marco와 저는 Rust 재단에서 급여를 받고 인프라에만 전념합니다. 그리고 몇몇 자원봉사자분들이 각자의 영역에서 일하고 계시죠.

Jan David Nose: 우리가 책임지는 범위가 워낙 넓기 때문에, 인프라 팀은 다른 팀들에 비해 다소 사일로(silo) 형태로 일하는 편이기도 합니다. 각자 인프라의 아주 특정한 부분에 깊은 애정을 갖고 집중하는 사람들이 있어요. 그렇지 않으면, 한 사람이 알아야 할 것이 너무 많아집니다. 이런 구성은 꽤 잘 맞고, 팀의 다른 분들과 함께 일하는 것은 정말 멋진 경험입니다.

Jan David Nose: 저는 운 좋게도 이 일을 풀타임으로 할 수 있는 특권을 가지고 있기 때문에, 더 큰 부담을 떠안고, 자원봉사자들이 재미있게 참여할 수 있는 공간을 만들려고 합니다. 위험이 적고, 뭔가가 갑자기 불이 날 가능성이 낮은 흥미로운 작업에 참여할 수 있도록 하는 거죠. 와서 일을 한 덩어리 처리하고, 삶이 바빠져서 2주 정도 자리를 비워도 괜찮은 환경을 만들고자 합니다. 누군가는 서버와 불을 계속 지키고 있으니까요.

Jan David Nose: 그런 일의 상당수는 유지 관리자 쪽에 가깝습니다. GitHub 앱이나 triage를 돕는 봇 같은 것들이죠. 그쪽은 잘못돼도 위험도가 상대적으로 낮습니다. 반대로 사용자 쪽에서 DNS 설정을 잘못 건드리면—누군가 그런 적이 있었는데요—30분 동안 아무도 크레이트를 다운로드하지 못하는 상황을 초래할 수 있습니다. 여기서 ‘아무도’란 정말 문자 그대로 전 세계의 모든 사용자를 의미합니다. 그런 경험을 자원봉사자에게 겪게 하고 싶지는 않습니다. 엄청난 스트레스거든요. 실제로 그런 부담 때문에 번아웃을 느꼈던 것이 제가 처음 이 일을 맡게 된 이유 중 하나이기도 합니다.

Jan David Nose: 풀타임 직원 입장에서는 그런 부담이 조금 더 감당 가능한 편입니다. 우리는 시간을 더 많이 쓸 수 있고, 스트레스를 관리할 방법도 더 많으니까요. 솔직히, 전적으로 자원봉사자로 구성된 인프라 팀이 그동안 이뤄 낸 일들을 보면, 정말 놀랍다는 말밖에 나오지 않습니다. 그들이 무엇을 만들었고 Rust를 여기까지 끌고 왔는지 믿기 어려울 정도예요.

Xander Cesari: 2025년에 웹 트래픽을 관리하는 사람이라면 누구나, AI나 기타 목적의 봇·스크레이퍼 때문에 트래픽이 폭발적으로 늘었다는 이야기를 하고 있을 것 같습니다. Rust 네트워크도 그런 영향을 받았나요?

Jan David Nose: 네, 분명히 영향을 받고 있습니다. 약간 다른 팀에서 다루는 부분이긴 하지만, 특히 docs.rs 쪽에서 크롤러가 우리를 강하게 두드릴 때가 있었고, 그로 인해 서비스를 체감할 수 있을 만큼 느려지기도 했습니다. 크롤러가 폭주하면서 짧지만 아주 강한 트래픽 폭증이 일어나는 상황을 우리가 뼈저리게 인식하고 있습니다.

Jan David Nose: 이건 인프라 관점에서 새로운 도전 과제입니다. 이런 트래픽에 어떻게 대응할지, 그리고 docs.rs를 자신의 업무를 위해 참조하고자 하는 실제 사용자들이 서비스를 못 쓰게 되는 상황을 막기 위해 어떻게 서비스를 보호할지 고민해야 합니다. CDN 측면에서는 우리 제공업체들이 대개 트래픽을 감당해 줍니다만, 애플리케이션 레벨에서 더 큰 타격을 받는 경우가 많습니다.

Jan David Nose: CDN 쪽에서는 crates.io 전체를 긁어 가려는 트래픽도 보입니다. 아마도 크레이트 생태계를 통째로 LLM에 집어넣으려는 의도겠죠. 다행히 지난 2년 동안 crates.io 애플리케이션이 이런 트래픽 급증에 덜 영향을 받도록 많은 작업을 해 왔습니다. 지금은 다운로드 요청이 crates.io 애플리케이션을 전혀 거치지 않고 CDN으로 바로 전달되기 때문에, API가 이런 폭주에 시달리지 않습니다. 예전 같으면 분산 서비스 거부(DDoS) 공격처럼 보였을 겁니다. 온갖 소스에서 너무 많은 요청이 몰려와 감당할 수 없는 상황이었겠죠.

Jan David Nose: 백엔드에서 스택을 안정적으로 유지하기 위한 작업을 많이 해 왔고, 그런 덕분에 버티고는 있지만, 지난 1년 동안 게임의 룰이 바뀐 건 분명합니다. 크롤러의 활동이 예전보다 훨씬 활발해졌다는 게 눈에 보입니다.

Xander Cesari: 이해됩니다. Fastly도 아마 이 문제를 다루고 있겠죠. 그쪽 비즈니스 모델도 이 새로운 인터넷 환경에 맞게 탄탄해져야 할 테니까요.

Jan David Nose: 맞습니다. 예를 들어 우리가 지금 논의하고 있는 주제 중 하나가 docs.rs입니다. 지금은 AWS의 CloudFront 뒤에서 호스팅되고 있지만, Fastly 뒤로 옮기자는 이야기를 하고 있습니다. Fastly를 쓰면 봇 보호(bot protection) 같은 기능을 활용해 크롤러를 차단할 수 있기 때문이죠.

Jan David Nose: 이건 지난 6개월 동안 우리의 대화가 어떻게 바뀌었는지를 잘 보여주는 사례입니다. 연초만 해도 이런 주제를 이야기하게 될 거라고는 생각하지 못했습니다. 우리는 다른 것들을 우선순위로 두고 있었어요. docs.rs의 경우, 그 기반 인프라를 재구성하겠다는 장기 계획이 있었고, 그쪽에 에너지를 쏟을 거라고 예상했습니다. 하지만 업계에서 모두가 가능한 한 많은 데이터를 모으려는 흐름이 생기면서 우선순위가 바뀌었습니다. 우리가 직면한 문제와 그 문제를 해결하는 순서가 달라진 거죠.

Xander Cesari: 대부분이 자원봉사자이고, 몇 안 되는 상근 인력 중 한 명이라 보면, 재미있는 다음 기능보다는 화재 진압에 더 많이 투입될 수밖에 없을 것 같네요.

Jan David Nose: 사실이긴 한데, 제가 하는 일이 전부 ‘불끄기’뿐이라고 말하면 너무 부정적으로 들리겠네요. 가끔 그런 기분이 들긴 합니다. 어느 기술 스택이든 그렇듯, 유지 보수 오버헤드가 상당히 크기 때문에, 인프라 쪽은 특히 그 대가를 치르고 있다고 느낄 때가 있어요.

Jan David Nose: 예를 들어 Marco는 올해 우리가 운영하는 모든 서버를 하나하나 훑으면서 목록을 만들고, 패치가 제대로 되어 있는지, 운영체제 버전이 최신인지 확인하는 데 시간을 꽤 들였습니다. Ubuntu 머신들을 최신 LTS 버전으로 업그레이드하기도 했고요. 약간 잡무처럼 느껴진다고 할까요. 그냥 해야만 하는, 하지만 그 자체로 흥미로운 프로젝트라고 하긴 어려운 작업이죠.

Jan David Nose: 반면 CDN 설정을 손보고, 봇 보호 기능이 어떻게 동작하는지, 우리에게 유의미한지 살펴보는 작업은 genuinely 흥미로운 편입니다. 벤더가 제공하는 새로운 도구를 직접 다뤄 볼 수 있고, 업계 전반이 마주한 새로운 문제를 함께 풀어 나가는 작업이니까요. 이런 새로운 트래픽과 어떻게 맞서 싸울지, 봇을 차단했을 때의 함의는 무엇인지, 실제 사용자를 차단할 위험은 어느 정도인지 등을 고민해야 합니다. 누군가 curl 스크립트를 잘못 설정했는데, 겉보기에는 사이트를 크롤링하는 것처럼 보일 수도 있으니까요.

Jan David Nose: 그래서 이 영역은, 우리 풀타임 인력 입장에서도 상당히 흥미로운 분야입니다. 확실히 ‘지루한’ 업무의 비중이 크긴 하지만, 세상이 변하는 속도에 맞춰 우리도 함께 적응해 나가고 있다는 점에서 흥미를 유지하게 해 줍니다. 하나 변하지 않는 것이 있다면, 세상은 늘 바뀐다는 점이죠.

Xander Cesari: 이와 관련해, 최근 뉴스에서 많이 다뤄진 변화 중 하나가 소프트웨어 공급망 보안입니다. 특히 xz-utils 사건 이후로 오픈 소스 보안에 대한 이야기가 많죠. 이 사건이 당신이 일하는 환경을 얼마나 바꾸어 놓았나요?

Jan David Nose: xz-utils 침해 사건은 무서웠습니다. 이걸 ‘깨달음을 준 사건’이라고 말하긴 어렵겠어요. 공급망 보안이 큰 이슈라는 건 예전부터 알고 있었고, 이번이 첫 번째 침해도 아니었으니까요. 하지만 그 사건이 벌어진 방식은 참 불편한 감정을 불러일으켰습니다. 누군가가 1년 반에 걸쳐 오픈 소스 프로젝트에서 사회적 신뢰를 쌓고, 그걸 이용해 백도어를 심었다는 사실이요.

Jan David Nose: 이걸 Rust 맥락에서 생각해 보면 이렇습니다. 모든 팀이 유지 관리자가 더 필요하다고 말합니다. 현재 기여자들에게 일이 너무 많고, Rust의 성장이 조직 전체에 부담을 준다고요. 우리는 개방적이고 환영하는 프로젝트가 되고 싶고, 실제로 지금 새로운 사람들을 많이 모셔 와야 하는 상황이기도 합니다. 누군가 나타나 "도와드리고 싶어요, 저를 온보딩 해 주세요"라고 말하고, 1년간 꾸준히 기여하다가 악의적인 행동을 한다면, 우리도 충분히 그런 공격에 취약합니다. 이건 Rust만의 문제라기보다, 오픈 소스라는 모델 자체가 가진 고유한 문제라고 생각합니다.

Xander Cesari: 그렇죠. 그건 오픈 소스 문화 자체와 상충하는 문제이기도 하죠.

Jan David Nose: 맞습니다. 그래서 우리는 프로젝트와 생태계 전체가, 장기적인 게임을 할 수 있는 지속적인 공격자(persistent threat actor)를 어떻게 다룰지 고민하고 있습니다. 누군가를 1년 동안 풀타임으로 오픈 소스에 투입해 공격하게 만드는 건, 예전까지 우리가 우려해 왔던 위협 모델과는 완전히 다른 차원의 문제입니다.

Jan David Nose: 예전에는 crates.io에 가장 큰 위협이, 제가 실수로 CDN 플러그를 뽑는 것이라고 농담처럼 이야기하곤 했습니다. 그런데 지금은 상황이 달라졌죠. 현재의 더 큰 위협은 누군가가 우리가 내놓는 릴리스나 공급망, 혹은 crates.io 자체에 악성 코드를 심는 것입니다. 우리 시스템에 우리가 전혀 대비하지 못한 방식으로 침투해서, 대부분이 자원봉사자로 구성된 조직 특성상 새로운 유형의 공격에 너무 느리게 대응하게 만들 수 있습니다.

Jan David Nose: 지난 3년을 돌아보면, 특히 첫 해 이후에 이런 변화가 확연해졌습니다. 트래픽이 두 배로 늘고, Rust 사용량이 크게 늘고, Windows 커널과 Android, iOS 일부에 Rust가 사용된다는 뉴스가 계속 나왔어요. 그러다 보니 어느새 Rust가 ‘도처에’ 있게 되었습니다. 그런 ‘도처’ 전체를 공격하고 싶은 누군가에게, Rust를 겨냥하는 것은 꽤 매력적인 목표가 됩니다. 이건 확실히 우리 등에 과녁을 붙인 셈이고, 우리가 일하는 환경을 바꿔 놓았어요.

Jan David Nose: Rust 재단에 전담 보안 엔지니어가 있다는 사실이 정말 다행입니다. 그분은 많은 위협 모델링을 수행하고, 인프라 보안 측면에서도 우리와 협업해 왔습니다. 크레이트 생태계와 공급망 공격을 방지하는 쪽에서도 많은 작업이 진행 중이고요. 다행히 인프라 팀이 이걸 혼자 해결해야 하는 건 아닙니다. 그렇지만 이 주제가 훨씬 더 큰 주목을 받고 있고, 앞으로의 큰 도전 과제 중 하나가 될 겁니다. 대개 자원봉사로 운영되는 프로젝트가 이런 위협에 어떻게 따라잡을 것인가 하는 점이요.

Xander Cesari: 그리고 이건 업계 전체의 문제이기도 하죠. Rust 패키지 매니저만의 문제가 아니라, Python, JavaScript, Nix 등 모든 패키지 레지스트리가 비슷한 고민을 하고 있습니다. 서로 돕고 배움을 공유하는 업계 차원의 논의가 있나요?

Jan David Nose: 네, 관련해서 활발히 진행되는 논의가 많이 있습니다. 사실 이 주제를 떠올리면 약간 웃음이 나오기도 하는데, 거기에는 깊은 공감과 동시에 약간의 안도감이 섞여 있습니다. 다른 패키지 생태계에서 침해가 발생했다는 소식을 들을 때마다, "이번에는 npm이구나" 하고 서로 공유하거든요. 우리만 당하는 게 아니라는 사실을 다시 상기시키는 일이기도 하죠.

Jan David Nose: 우리는 업계 전체, 그리고 다른 생태계에서 어떤 일이 일어나는지를 계속 주시하려 합니다. 어떤 새로운 위협이나 공격 벡터가 등장하는지, 어떤 부분에서 어려움을 겪고 있는지 말이에요. 때로는 그게 보안 문제일 수도 있고, 때로는 사용성 문제일 수도 있습니다. 예를 들어 1년 반 전쯤 npm에는 "everything" 패키지라는 게 있었어요. 누군가가 npm에 존재하는 모든 패키지를 의존성으로 선언한 패키지였고, 그 때문에 인덱스가 완전히 망가졌습니다. 우리는 이런 사건을 보면서 "crates.io도 비슷한 상황에서 곤란을 겪지 않을까? 뭔가 바꿔야 할까?"라고 자문합니다.

Jan David Nose: 보안 쪽에서도 다른 생태계가 무엇을 하고 있는지 면밀히 들여다봅니다. 패키징 커뮤니티에서는 다양한 패키지 매니저들이 조금씩 더 자주 모여, 서로 공통으로 겪는 문제가 무엇인지 논의하기 시작했습니다. 농담 반 진담 반으로 하는 말이지만, 우리 모두 결국은 ‘파일을 인터넷으로 배송하는’ 일을 하는 셈이거든요. npm 패키지든 크레이트든, 결국 텍스트 파일 뭉치를 zip에 넣어 보내는 거죠. 인프라 관점에서 보면 문제의 성격이 상당히 비슷합니다.

Jan David Nose: 이런 커뮤니티가 이제는 PyPI에 어떤 문제가 있는지, crates.io에는 어떤 문제가 있는지, npm 쪽에서는 무슨 일이 벌어지는지 등을 더 자주 이야기하게 되었습니다. 모든 생태계가 공통으로 겪는 문제 중 하나는—이미 오래된 생태계까지 포함해서—대역폭 수요가 크게 증가하고 있다는 점입니다. 그 배경에는 AI의 등장과 확산이 크게 작용합니다. 예를 들어 PyPI는 다운로드 차트를 공개하는데, 그 자료를 보면 정말 놀랍습니다. Python은 오랫동안 느리게 지수 형태로 증가하는, 관리 가능한 성장세를 유지해 왔어요. 그런데 1~2년 전부터 갑자기 큰 ‘하키 스틱’이 나타납니다. 사람들이 PyPI가 모델 배포에 아주 좋은 시스템이라는 걸 발견했기 때문입니다. 당시에는 파일 크기 제한도 없어서, 미리 컴파일된 GPU 모델을 그대로 올릴 수 있었죠.

Jan David Nose: 이런 패턴은 곳곳에서 나타납니다. 이 때문에 패키징 생태계 전체가 "오픈 소스는 여전히 자원이 부족한데, 트래픽 수요는 계속 늘어난다. 이 상황에서 우리가 함께 어떤 해결책을 찾을 수 있을까?"를 고민하는 새로운 시대로 접어들었습니다. crates.io도 그런 논의를 함께 하고 있고요. Python, npm, Rust 등 서로 다른 생태계가 매우 비슷한 문제를 공유하고 있다는 사실을 보는 건 흥미로운 일입니다.

Xander Cesari: 커뮤니티가 더 작고 취미 중심일 때는, 패키지 매니저에 무엇이 들어가는지에 대해 규칙을 느슨하게 가져가도 됩니다. 모두가 무엇을 하려는지 그 취지를 알고 있고, 딱딱한 규칙과 제재 없이도 잘 굴러가죠. Rust 세계도 이제는 패키지 크기, 허용되는 파일, 배포 방식 같은 것에 대해 훨씬 더 엄격한 규칙을 고민해야 할까요?

Jan David Nose: 재미있게도, 우리는 그 반대 방향에서 출발하고 있습니다. 다른 생태계와 비교할 때, 우리는 애초부터 꽤 엄격한 제한을 두고 있었습니다. 크레이트 하나의 크기는 대략 최대 10MB 정도로 제한되어 있고, 어떤 종류의 파일을 넣을 수 있는지도 제한이 있습니다. 역설적으로, 이런 제한이 지금과 같은 시기에 우리의 트래픽을 관리 가능한 수준으로 유지하는 데 도움을 주었습니다.

Jan David Nose: 동시에 이 제한이 모든 Rust 사용 사례에 부합하지 않을 수 있다는 주장도 타당합니다. 어떤 경우에는, 로컬에서 컴파일하기 어렵거나, 컴파일 시간이 너무 길거나, 흔치 않은 헤더에 의존하기 때문에, 미리 컴파일된 무언가를 크레이트에 포함하고 싶을 수도 있습니다. crates.io 패키지 포맷이 지금이 최종 형태라고 보지는 않습니다.

Jan David Nose: 여기에는 흥미로운 보안 문제가 얽혀 있습니다. 미리 컴파일된 바이너리나 페이로드 이야기를 하다 보면, curl | sh 같은 명령을 볼 때마다 머릿속에 울리는 작은 경고음이 떠오르죠. "이걸 신뢰해도 되는가?"라는 질문이요. 검토하기 어려운 미리 컴파일된 블롭이 들어 있는 크레이트를 다운로드할 때도 같은 의문이 생깁니다.

Jan David Nose: Rust 재단에서는 이와 관련한 작업과 연구를 많이 진행하고 있습니다. crates.io 팀에서 일하는 제 동료 Adam이 이런 질문들에 답을 찾기 위해 뒤에서 많은 일을 하고 있어요. 예를 들어, 크레이트를 게시하기 전에 어떤 종류의 보안 검사를 수행해, 악성 페이로드를 포함하지 않았는지 확인할 수 있을까? 이런 정보를 어떻게 드러낼 것인가? 게시자에게 허용되지 않는 파일을 포함했다고 어떻게 알려줄 것인가? 또 사용자 입장에서는 crates.io를 방문했을 때, 어떻게 그 크레이트가 얼마나 잘 유지 관리되고 있고 얼마나 안전한지 판단할 수 있도록 도와줄 것인가? 같은 질문들입니다.

Jan David Nose: 이런 논의는 생태계 전반에서 폭넓게 이루어지고 있습니다. 인프라 측면에서 우리는 체인의 꽤 아래쪽에 위치해 있어요. 결국 crates.io가 구축하는 보안 스캐닝 인프라와 통합하는 역할을 맡게 됩니다. 우리가 직접 보안 연구를 할 필요는 없지만, 그 기능들이 동작하도록 뒷받침해야 합니다.

Jan David Nose: 아직 해야 할 일은 아주 많습니다. Rust가 지금도 이미 훌륭하고, 저도 Rust를 쓰는 걸 정말 좋아하지만, 우리가 여전히 아주 젊은 생태계라는 사실을 기억하는 게 중요합니다. Python은 지금 매우 성숙하고 안정적이지만, 벌써 25년이 넘은 언어입니다. Rust는 안정 언어로 10년 정도밖에 되지 않았어요. 아직 배워야 할 것도, 해결해야 할 것도 많습니다.

Xander Cesari: Rust 생태계는 다른 언어보다 더 빨리 이런 문제에 부딪히고 있는 걸까요? Rust가 기저 소프트웨어로서 성공해, 다른 언어보다 더 보안에 민감한 영역에서 사용되고 있기 때문에, Python 세계보다 더 이른 시기에 이런 어려운 문제를 마주하게 된 것인지 궁금합니다.

Jan David Nose: 저는 어느 정도 그렇다고 생각합니다. 다른 생태계는 이런 문제를 고민할 시간이 좀 더 많았을 겁니다. 우리는 더 압축된 타임라인에서 움직이고 있어요. 그뿐 아니라 지금은 단순히 더 많은 일이 벌어지고 있는 시대입니다. 오픈 소스는 크게 성공했고, 어디에나 존재합니다. 그 말은 곧, 보안이 중요한 곳이 예전보다 훨씬 많다는 뜻이기도 하죠.

Jan David Nose: 이런 상황은 오픈 소스의 성공, 생태계 전체에서 벌어지는 일, 그리고 우리가 속한 산업의 특성과 함께 찾아온 것입니다. 그래서 어떤 문제는 더 짧은 시간 안에 해결해야 하는 압박이 있습니다. 반면에 우리는 짐이 덜하다는 장점도 있습니다. 기술 부채가 적고, 15년 치의 역사가 덜 쌓여 있죠. 덕분에 어떤 영역에서는 선두에 설 수 있습니다. 예를 들어 21세기형 오픈 소스 프로젝트가 필요로 하는 인프라가 무엇인지, 패키지 생태계가 어떻게 안전성을 유지할 수 있는지에 대해 고민할 여지가 더 많습니다.

Jan David Nose: 이 지점에서 Rust 재단을 꼭 언급하고 싶습니다. 재단은 이런 작업을 적극적으로 지원합니다. 저와 Marco 같은 사람을 고용해 인프라에 전념하게 하고, Walter와 Adam에게 보안에 집중할 수 있는 역할을 맡기며, 조직 차원에서 공급망 문제를 매우 진지하게 다루고 있습니다. 또한 재단은 다른 생태계와 협력해 서로 배우고 함께 성장하며 더 나은 업계를 만들고자 노력하고 있습니다.

Jan David Nose: 뒤편에서는 동료들이 Rust가 비교적 젊은 언어임에도 이런 대화의 자리에 함께할 수 있도록, 즉 다른 생태계와 한 자리에 앉아 이야기할 수 있도록 끊임없이 길을 열어 주고 있습니다. 덕분에 우리는 다른 생태계가 이미 겪은 일에서 배우는 동시에, 앞으로 어디로 나아갈지에 대한 논의에도 목소리를 낼 수 있습니다. 여기에는 지속 가능성이라는 중요한 주제도 포함됩니다. 장기적으로 프로젝트를 어떻게 재정적으로 뒷받침할 것인가, 인프라를 운영하고 유지 관리자를 지원하기 위해 필요한 인적·재정적 자원을 어떻게 확보할 것인가 같은 점들입니다. 솔직히 제 일이 관계 관리와 예산 계획—스폰서 크레딧이 다음에 들어올 때까지 잘 버티도록 하는 일—을 이렇게 많이 포함하게 될 줄은 처음에는 예상하지 못했습니다.

Xander Cesari: 대부분의 오픈코어 비즈니스 모델은 비용이 많이 들지 않는 것(소프트웨어)은 무료로 제공하고, 사용량에 따라 비용이 늘어나는 것(서비스)에 요금을 부과합니다. Rust의 경우에는 둘 다 무료입니다. 채택에는 최고지만, 비즈니스 관점에서는 꽤 창의적인 접근이 필요할 것 같네요.

Jan David Nose: 네, 그리고 여기에는 서로 반대 방향으로 끌어당기는 힘들이 있습니다. 오픈 소스 프로젝트로서, 우리는 누구나 Rust를 무료로 사용할 수 있기를 바랍니다. 훌륭한 사용자 경험도 제공하고 싶습니다. 다운로드 이야기로 돌아가 보면, 비용을 훨씬 줄일 수 있는 방법이 있긴 합니다. 예를 들어 모든 것을 하나의 지리적 위치에서 호스팅하는 방법이 있죠. 그렇게 하면, 호주 같은 곳의 사용자들도 유럽에서 데이터를 받아야 하고, 사용자 경험은 확실히 나빠집니다.

Jan David Nose: 대신 우리는 더 비싼 서비스를 사용하더라도 Rust 사용자들에게 더 좋은 경험을 제공하고자 합니다. 여기에는 진짜 긴장이 있습니다. 한쪽에서는 우리가 할 수 있는 최선을 다하고 싶고, 다른 한쪽에서는 이런 선택들이 비용을 수반한다는 사실을 인정해야 합니다.

Xander Cesari: 저는 인프라를 "된다/안 된다"의 이진 상태로만 생각해 왔던 것 같습니다. 그런데 말씀을 듣고 보니, 이건 슬라이더에 가깝네요. 얼마나 비용을 쓰느냐에 따라 어떤 품질의 서비스를 제공할지가 달라지는 거군요. Rust 인프라 팀이나 패키징 세계 전반에서, 이런 보안 문제에 도움을 줄 새로운 기술이 등장하고 있나요? 새로운 샌드박싱 기술이나, 더 상위 수준의 지원 같은 것들 말입니다.

Jan David Nose: 많은 사람들이 여러 각도에서 이 문제를 다루고 있습니다. 내부적으로도 이 주제에 대해 많이 이야기해 왔어요. 특히 Crater와 관련해서요. Crater는 크레이트들을 전부 가져와 빌드하고, 컴파일러로부터 피드백을 얻는 도구입니다. 누군가 악성 코드를 포함한 크레이트를 게시하면, 우리는 그걸 다운로드해서 빌드하게 됩니다.

Jan David Nose: Rust에서는 빌드 스크립트가 머신에서 사실상 무엇이든 할 수 있다는 점이 특히 큰 도전 과제입니다. 그래서 우리에게는 강력한 샌드박싱이 필요합니다. 우리는 자체 샌드박싱 프레임워크를 구축해서, 각 크레이트 빌드를 격리된 컨테이너에서 실행하고 있습니다. 덕분에 악성 코드가 탈출해 호스트 시스템을 건드리지 못하게 막을 수 있죠.

Jan David Nose: 우리는 Crater에서 이 문제를 특히 예민하게 느끼고 있지만, Crater에만 국한되지 않는 해결책—사용자들의 머신도 같은 위험으로부터 보호할 수 있는 해결책—을 마련할 수 있다면 가장 이상적일 것입니다. 재단 쪽의 Walter 같은 분들이 이 문제에 적극적으로 매달리고 있습니다. Cargo나 crates 팀에서도 분명 비슷한 논의가 있을 거예요. 패키지와 관련된 팀이라면 누구나 이 문제를 각자의 각도에서 보고 있으니까요. 우리는 모두 함께 모여 해결책을 찾아야 하고, 그 과정에서 정말 흥미로운 작업이 많이 벌어지고 있습니다.

Xander Cesari: 곧 도움이 도착하길 바랍니다.

Jan David Nose: 저는 낙관적으로 보고 있습니다.

Xander Cesari: 트래픽이나 그 밖의 모든 게 지수 함수처럼 증가하고 있습니다. 언젠가는 완만해지긴 해야 할 텐데요.

Jan David Nose: 두고 봐야겠죠. Rust는 아직 젊은 언어입니다. 이 성장이 언제 둔화될지 저도 잘 모르겠습니다. 채택이 계속 늘어나는 만큼, 꽤 오랫동안 성장 곡선이 유지될 것이라는 주장도 그럴듯합니다.

Jan David Nose: RustConf 같은 컨퍼런스에 와 보면, 시간이 지나면서 어떤 기업들이 참여하는지 그 구성의 변화가 정말 흥미롭습니다. 예를 들어 Rivian이 자사의 차량에서 Rust를 어떻게 사용하는지에 대한 발표도 있었고, 다른 자동차 제조사들이 Rust를 탐색 중이라는 이야기들도 들었습니다. 몇 년 전만 해도 상상하기 어려웠거나, 언어 자체가 아직 그 수준으로 성숙하지 않았던 애플리케이션에도 Rust가 점점 들어가고 있습니다.

Jan David Nose: 이런 흐름이 이어지는 동안에는, 우리가 아직 진출하지 않았던 도메인으로 Rust가 확장되면서 새 성장 물결이 생길 것이라고 생각합니다. 그 덕분에 지금 우리가 보고 있는 지수 곡선이 꽤 오래 유지될 수도 있고요. 누가 Rust를 사용하고, 어떤 식으로 사용하는지—때로는 ‘우주’ 같은 전혀 예상치 못한 분야에서까지—지켜보는 일은 정말 놀라운 경험입니다.

Jan David Nose: 저는 Rust의 미래에 대해 매우 낙관적입니다. 채택이 늘어나면서 Rust를 어떻게 활용하는지에 대한 새로운 교훈들이 생길 것이고, Rust로 무언가를 만드는 사람들이 정말 창의적인 아이디어를 많이 보여줄 것입니다. 기업 채택이 늘어나면, 생태계에 새로운 투자 물결도 기대할 수 있습니다. 회사들이 생태계와 코어 프로젝트의 여러 부분에 풀타임으로 일하는 사람들을 고용하게 되겠죠. 앞으로 10년이 어떻게 펼쳐질지 정말 궁금합니다. 저도 아직 모르니까요.

Xander Cesari: 지금 Rust의 상태는, 마치 자동차를 쫓아가던 개가 마침내 자동차를 잡았는데, 이젠 뭘 해야 할지 모르는 상황 같기도 합니다.

Jan David Nose: 네, 꽤 좋은 비유인 것 같습니다. 우리는 어느새 성공의 모든 결과를 충분히 생각해 보지 않았다는 사실을 깨닫고 있는 상황에 놓였습니다. 해마다 새로운 도전 과제가 어떻게 바뀌는지를 지켜보는 건 정말 흥미로운 일입니다. 성장세가 계속되는 한, 1년 전에는 아무 문제도 아니었던 것이 갑자기 문제가 되는, 새로운 성장통을 계속 겪게 됩니다.

Jan David Nose: 우리는 성장 속도를 따라가기 위해 인프라 일부를 끊임없이 다시 짓고 있고, 이 흐름이 곧 멈출 것 같지는 않습니다. 사용자 입장에서는 이게 굉장히 신나는 일이기도 합니다. 언어와 생태계가 이 속도로 성장하는 만큼, 앞으로 어떤 흥미로운 것들이 나올지 기대하게 되거든요. 지금은 전혀 예상할 수 없는 것들 말이죠.

Jan David Nose: 프로젝트 입장에서는 동시에 아주 현실적인 과제들도 있습니다. 필요한 인프라를 어떻게 재정적으로 감당할 것인가, 유지 관리자와 기여자를 어디서 어떻게 찾을 것인가, 사람들이 번아웃되지 않고 일할 수 있는 건강한 환경을 어떻게 만들 것인가 같은 점들입니다. 해야 할 일이 정말 많지만, 그만큼 흥미로운 자리이기도 합니다.

Xander Cesari: 터미널에 매직처럼 작동하는 Cargo 명령을 계속 안전하게 돌아가게 해 주셔서 감사합니다. 이 인터뷰를 통해 전달하고 싶은 메시지가 하나 있다면, Rust를 사용하는 기업이라면 인프라 팀이 계속 일할 수 있도록 기부를 고려해 보라는 것이겠네요.

Jan David Nose: 우리는 언제나 새로운 Rust 재단 회원을 환영합니다. 특히 기업 입장에서는 재단 회원이 되는 것이 우리가 하는 일을 지원하는 가장 좋은 방법 중 하나입니다. 그 덕분에 우리는 예산을 확보해 프로젝트에 풀타임으로 일하는 사람들을 고용하거나, 스폰서십으로 받지 못해 실제 비용을 지불해야 하는 인프라의 빈틈을 메우는 데 쓸 수 있습니다.

Jan David Nose: 그리고 회사가 아니더라도, 도와주실 분은 언제나 환영입니다. 인프라 팀에는 Rust로 작성된 봇들이 많이 있고, 비교적 쉽게 기여할 수 있는 영역도 있습니다.

Xander Cesari: 범위가 작고 이해하기 쉬운 봇들이라, 기여자들이 금방 파악하고 도울 수 있겠네요.

Jan David Nose: 네, 맞습니다. 인프라 쪽은 조금 더 어렵긴 합니다. 우리가 사용하는 클라우드 인프라에 대한 접근 권한을 그냥 드릴 수는 없으니까요. 프로덕션 시스템에 접근할 수 없기 때문에 자원봉사자로 기여하기 어려운 영역도 분명 있습니다. 그래도 여전히 할 수 있는 일은 많이 있습니다.

Jan David Nose: 다른 팀들처럼 우리도 다소 인력이 부족한 편입니다. 그러니 컨퍼런스에서 저나 Marco를 보시면 와서 이야기를 나눠 주세요. 할 일이 많습니다.

Xander Cesari: Rust를 돌아가게 하는 일에 힘써 주셔서 정말 감사합니다.

Jan David Nose: 저야말로 기쁘게 하고 있습니다.

Xander Cesari: 좋습니다. 오늘 인터뷰 정말 감사했습니다.