전 세계 규제 기관과 표준 기구가 메모리 안전 언어 채택을 요구하는 가운데, 왜 메모리 안전하지 않은 코드가 법적·재무적·평판 리스크가 되는지, 그리고 Rust가 그 해법으로 주목받는 이유를 설명합니다.
소프트웨어가 핵심 인프라를 구동하거나, 민감한 데이터를 처리하거나, 규제된 시장의 고객에게 제공되는 제품을 담당하고 있다면, 소프트웨어 보안을 둘러싼 규제 환경에 주의를 기울여야 합니다.
전 세계 정부는 하나의 메시지로 수렴하고 있습니다. 메모리 안전하지 않은 코드는 책임 리스크입니다. 새로운 규제, 행정부 지침, 조달 요건은 지금 행동하지 않는 조직이 점점 더 큰 법적, 재무적, 평판 리스크에 직면하게 될 것임을 분명히 하고 있습니다.
Rust는 가장 흔한 종류의 보안 취약점을 컴파일 시점에 제거합니다. 이것은 마케팅 문구가 아니라 언어의 기술적 속성이며, Google, Microsoft, the White House가 이를 확인했습니다.
이 글에서는 그 근거를 정리합니다. 규제 환경, 사방에서 커지는 압박, 그리고 왜 지금 전문가의 안내를 받아 행동하는 것이 조직이 살 수 있는 가장 현명한 보험인지 설명합니다.
규제 이야기를 하기 전에, 먼저 문제 자체를 살펴보겠습니다.
대규모 C 및 C++ 코드베이스의 전체 보안 취약점 중 70%는 메모리 안전 문제입니다. 버퍼 오버플로, use-after-free, null pointer 역참조, 그리고 이와 유사한 버그들입니다.
이 문제들은 역사상 가장 중대한 사이버 공격들 가운데 일부의 근본 원인입니다. White House ONCD 보고서는 이를 분명하게 표현합니다.
“Some of the most infamous cyber events in history, the Morris worm of 1988, the Slammer worm of 2003, the Heartbleed vulnerability in 2014, the Trident exploit of 2016, the Blastpass exploit of 2023, were headline-grabbing cyberattacks that caused real-world damage to the systems that society relies on every day. Underlying all of them is a common root cause: memory safety vulnerabilities. For thirty-five years, memory safety vulnerabilities have plagued the digital ecosystem, but it doesn’t have to be this way.”
Anjana Rajan, Assistant National Cyber Director for Technology Security
세계 최고 수준의 숙련된 프로그래머들이 가장 면밀히 검토되는 코드를 다루더라도, 오직 규율만으로는 이런 버그를 제거할 수 없습니다. System76의 Jeremy Soller는 우리의 Rust in Production podcast에서 이렇게 말했습니다.
“I have so many examples of skilled programmers using the absolute top of the line. Just recently there was a glibc issue, and it can be exposed remotely through PHP code. A glibc issue can allow remote code execution. There is no library in the Linux ecosystem that is as heavily used as glibc. If there was a smart person who could apply some kind of technique to glibc, they have, they did, and yet for 24 years there was a vulnerability present. This is a fact of the language itself.”
바로 glibc 이야기입니다. 컴퓨팅에서 가장 중요하고, 가장 많이 검토되며, 가장 혹독한 실전 검증을 거친 라이브러리 중 하나입니다. 뛰어난 엔지니어들이 C로 작성했습니다. 그런데도 원격 코드 실행 취약점이 20년이 넘도록 눈앞에 숨어 있었습니다.
이것은 사람의 문제가 아니라 도구의 문제입니다. 그리고 이것이야말로 Rust가 해결하도록 설계된 문제의 정확한 범주입니다!
한때 보안 연구자들의 틈새 관심사였던 것이 이제는 주류 정책 우선순위가 되었습니다. 전 세계의 정부와 표준 기구는 이제 메모리 안전 언어로의 전환을 명시적으로 요구하고 있습니다. 아래는 가장 중요한 전개를 정리한 비완전한 연대표입니다.
2024년 2월, White House ONCD는 “Back to the Building Blocks: A Path Toward Secure and Measurable Software.”라는 제목의 중요한 보고서를 발표했습니다.
이 보고서는 소프트웨어 제조사가 메모리 안전 프로그래밍 언어를 채택함으로써 취약점의 전체 범주를 예방할 수 있다고 주장합니다. 그리고 메모리 안전을 국가 안보의 문제로 명시적으로 규정합니다.
“We, as a nation, have the ability and the responsibility to reduce the attack surface in cyberspace and prevent entire classes of security bugs from entering the digital ecosystem but that means we need to tackle the hard problem of moving to memory safe programming languages.”
Harry Coker, U.S. National Cyber Director
이 표현은 결코 이상적인 구호가 아니라, 향후 정부 조달, 준수 요건, 책임 기준의 방향을 알리는 정책 지침입니다.
백악관 보고서 이전인 2022년 11월에도 National Security Agency는 “Software Memory Safety”라는 Cybersecurity Information Sheet를 발행했습니다.
NSA는 조직에 다음을 권고합니다.
중요하게도, NSA는 전통적으로 C와 C++가 지배해 온 시스템 프로그래밍 분야, 특히 성능이 매우 중요한 사용 사례를 위한 메모리 안전 대안으로 Rust를 이름으로 직접 지목합니다.
문서는 이렇게 말합니다.
“NSA recommends that organizations use memory safe languages when possible and bolster protection through code-hardening defenses such as compiler options, tool options, and operating system configurations.”
**Cybersecurity and Infrastructure Security Agency (CISA)**와 FBI는 2025년 1월에 업데이트된 Product Security Bad Practices 지침을 공동 발표했습니다.
Product Properties 아래에 나열된 첫 번째 “나쁜 관행”은 모호함이 없습니다(강조는 원문).
“The development of new product lines for use in service of critical infrastructure or NCFs in a memory-unsafe language (e.g., C or C++) where readily available alternative memory-safe languages could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.”
CISA는 또한 메모리 안전하지 않은 언어로 작성된 기존 제품의 경우, 공개된 메모리 안전 로드맵이 없는 것 자체가 나쁜 관행이라고 명시합니다. 그들의 권고는 다음과 같습니다.
“Software manufacturers should publish a memory safety roadmap by the end of 2025, outlining their prioritized approach to eliminating memory safety vulnerabilities in priority code components written in memory unsafe languages.”
핵심 인프라용 소프트웨어를 만드는 조직인데 아직 메모리 안전 로드맵이 없다면, 이미 흐름에 뒤처져 있는 것입니다.
**Defense Advanced Research Projects Agency (DARPA)**는 TRACTOR 프로그램, 즉 Translating All C To Rust를 시작했습니다.
DARPA의 자체 요약은 이 사안의 전략적 중요성을 분명히 보여줍니다.
“After more than two decades of grappling with memory safety issues in C and C++, the software engineering community has reached a consensus. It’s not enough to rely on bug-finding tools. The preferred approach is to use ‘safe’ programming languages that can reject unsafe programs at compile time, thereby preventing the emergence of memory safety issues.”
인터넷의 탄생을 지원한 기관인 DARPA가 자동화된 C-to-Rust 변환에 상당한 자원을 투자하고 있습니다. 목표는 “숙련된 Rust 개발자가 작성했을 것과 동일한 품질과 스타일의” Rust 코드를 만들어, “C 프로그램에 존재하는 메모리 안전 보안 취약점의 전체 범주를 제거하는 것”입니다.
미국 국방부가 C에서 Rust로의 자동화된 마이그레이션에 자금을 지원하고 있다면, 전략적 방향은 이보다 더 분명할 수 없습니다.
EU의 Cyber Resilience Act (CRA)는 유럽 시장에서 판매되는 모든 디지털 요소 포함 제품에 대해 의무적인 사이버 보안 요건을 설정합니다.
CRA에 따라 제조사는 다음을 해야 합니다.
CRA는 특정 프로그래밍 언어를 의무화하지는 않지만, 취약점 관리, 안전한 개발 관행, 제조사 책임에 관한 요구사항은 메모리 안전 언어 사용에 대한 강한 경제적 유인을 만듭니다. 규제가 악용 가능한 취약점에 대해 책임을 묻게 된다면, 그 전체 범주를 제거하는 것은 좋은 사업 판단입니다.
CRA는 개발 위치와 무관하게 EU 시장에 출시되는 모든 디지털 요소 포함 제품에 적용됩니다. 유럽에서 소프트웨어나 연결형 하드웨어를 판매한다면, 이것은 이미 현실입니다.
독일은 메모리 안전 소프트웨어를 지원하는 데 가장 적극적인 정부 중 하나입니다.
독일 연방 정보보안청(BSI)은 NIS-2 규제 대상 기업을 위한 보안 조치를 발표했으며, 여기서 메모리 안전 프로그래밍 언어의 예로 Rust를 이름으로 직접 권고합니다. “Development” 섹션에서 BSI는 다음을 권고합니다.
“Verwendung speichersicherer Programmiersprachen, beispielsweise Rust.” (Use of memory-safe programming languages, for example Rust.)
이 내용은 입력 검증, 암호화, 공격 표면 최소화, 안전한 코딩 관행을 포함한 더 넓은 security-by-design 요구사항의 일부이며, BSI는 이를 NIS-2 준수에 필수적이라고 봅니다. 국가 사이버 보안 기관이 규제 지침에서 Rust를 직접 언급한다는 사실은 중요합니다.
여기에 더해, 독일 연방 경제기후보호부의 지원을 받는 Sovereign Tech Fund는 Rust 생태계 개발에 직접 투자해 왔습니다.
미국의 **National Institute of Standards and Technology (NIST)**는 Secure Software Development Framework (SSDF)를 유지 관리하고 있으며, 이는 미국 정부 조달 전반에서 참조됩니다. SSDF는 메모리 안전 언어를 자연스럽게 선호하게 만드는 관행을 권고합니다. 즉, 원천에서 취약점 범주를 줄이고, 소프트웨어 자재명세서(SBOM)를 유지하며, 엄격한 코드 리뷰와 테스트를 수행하는 것입니다.
NIST 지침은 Executive Order 14028의 기초가 되며, 이 행정명령은 미국 연방 정부에 판매되는 소프트웨어가 SSDF 관행을 준수해야 한다고 요구합니다. 메모리 안전하지 않은 언어로 소프트웨어를 만드는 정부 계약업체와 공급업체는 자사 소프트웨어가 이러한 요구사항을 충족함을 입증해야 하는 부담이 점점 커지고 있습니다.
한 걸음 물러서서 패턴을 살펴봅시다.
| Source | Action | Year |
|---|---|---|
| Google/Microsoft | Independently confirmed ~70% of CVEs are memory safety issues | 2019–present |
| NSA | Published guidance recommending memory-safe languages | 2022 |
| Germany | Funded Rust ecosystem through the Sovereign Tech Fund | 2023–present |
| White House / ONCD | Called on industry to adopt memory-safe languages | 2024 |
| DARPA | Funded automated C-to-Rust translation (TRACTOR) | 2024 |
| EU | Enacted the Cyber Resilience Act with mandatory security requirements | 2024 |
| CISA / FBI | Listed memory-unsafe languages as a product security bad practice | 2024–2025 |
| NIST | Published SSDF; basis for federal procurement requirements | Ongoing |
이것은 메모리 안전하지 않은 코드가 핵심 시스템에서 용납할 수 없는 위험이라는 전 세계적이고, 초당파적이며, 범산업적인 합의입니다.
방향은 분명합니다. 문제는 조직이 이것을 다뤄야 하느냐가 아니라 언제 다루게 되느냐, 그리고 자기 조건으로 할 것이냐 아니면 외부 압력 아래서 하게 되느냐입니다.
당신의 소프트웨어가 핵심 인프라와 연결되거나, 민감한 데이터를 처리하거나, 규제된 시장에 출시된다면, 위의 규제 방향은 당신에게 적용됩니다. 제가 함께 일하는 대부분의 조직은 내부 Rust 전문성을 쌓고 신뢰할 수 있는 메모리 안전 로드맵을 작성하는 데 얼마나 오래 걸리는지 과소평가합니다.
저는 기업이 그 격차를 줄이도록 돕고 있으며, 보통 수개월의 시행착오를 절약하게 합니다. **무료 평가 통화 예약하기**를 통해 마감일이 속도를 결정하기 전에 어떤 위험에 노출되어 있는지 함께 파악해 봅시다.
의사결정자라면 이렇게 묻는 것이 당연합니다. “왜 Rust인가? 다른 메모리 안전 언어도 있지 않나.”
맞습니다. Java, Go, C#, Python도 모두 메모리 안전합니다. 하지만 그 언어들은 다른 문제 집합을 해결합니다.
가비지 컬렉터 없이 시스템 수준의 성능이 필요할 때, 기존 C/C++ 코드와 상호 운용해야 할 때, 베어 메탈에서 동작하는 코드, 커널, 임베디드 장치, 혹은 지연 시간에 민감한 네트워크 인프라에서 돌아가는 코드를 작성해야 할 때, 실제 프로덕션 준비가 된 메모리 안전 언어는 정확히 하나뿐입니다. 바로 Rust입니다.
제가 최근 choosing Rust에 관한 글에서 썼듯이:
ls조차 C 코드 5천 줄에 이르며, “그저 파일 이름을 출력하는” 도구치고는 상당한 공격 표면을 가집니다.Google, Microsoft, Amazon, Meta, Cloudflare, Discord는 모두 독립적으로 같은 결론에 도달했고, 핵심 인프라를 위해 Rust에 대규모 투자를 하고 있습니다. Microsoft의 Azure CTO는 새로운 프로젝트는 C나 C++ 대신 Rust로 작성해야 한다고 밝혔습니다. 이제 Linux kernel과 Windows kernel 모두 Rust 코드를 포함하고 있습니다.
도입을 결정하기 전에 Rust의 장기적인 지속 가능성에 회의적이라면, 저는 생태계 성숙도, 기업 투자, 자금 구조 측면에서 Rust가 왜 장기적으로 건전한 선택인지 설명한 글도 썼습니다.
일부 조직은 이 환경을 보고 이렇게 생각합니다. “규제가 최종 확정될 때까지 기다리자. 필요해지면 그때 행동하자.”
이것은 실수입니다.
버그는 늦게 발견될수록 수정 비용이 기하급수적으로 증가합니다. 컴파일 시점에 잡힌 취약점은 사실상 비용이 들지 않습니다. 반면 프로덕션에서 발견되면 Microsoft 자체 추정에 따르면 평균적으로 CVE당 $150,000의 비용이 듭니다. 그리고 여기에 규제 벌금, 침해 통지 비용, 평판 손상, 고객 신뢰 상실은 포함되지도 않았습니다.
마찬가지로, 메모리 안전 언어로의 마이그레이션은 스위치를 켜듯 할 수 있는 일이 아닙니다. 다음이 필요합니다.
지금 시작하는 조직은 규제의 망치가 떨어질 때 준비가 되어 있을 것입니다. 기다리는 조직은 부족한 Rust 전문성에 프리미엄 비용을 지불하며 허둥대고, 준수 마감일을 놓치게 될 것입니다.
“Why Rust in Production?”에서 논의하듯, Rust는 단지 버그를 막는 것에 그치지 않습니다. 온콜 부담을 줄이고, 개발자 자신감을 높이며, 장기 유지보수 비용을 낮춥니다. Google 설문조사에서는 개발자의 85%가 다른 언어의 코드보다 팀의 Rust 코드에 더 높은 신뢰를 느낀다고 답했습니다. 즉, 모든 보안 이점에 더해 회사는 개발 속도에서도 이득을 얻고, 이는 더 빠른 시장 출시와 더 낮은 개발 비용으로 이어집니다.
저는 10년 동안 Rust와 함께 일해 왔고, 클라우드 인프라부터 임베디드 시스템까지 다양한 산업의 팀이 Rust를 프로덕션에 도입하도록 도왔습니다. 매끄러운 도입과 고통스러운 도입의 차이는 거의 항상 이전에 그 일을 해본 사람이 있느냐에 달려 있습니다.
마이그레이션을 저울질하고 있거나, 로드맵을 만들고 있거나, 첫 번째 Rust 팀을 교육하려 한다면, 이야기해 봅시다. 한 번의 대화로도 몇 달간의 잘못된 우회를 피할 수 있습니다.
CISA가 모든 소프트웨어 제조사가 2025년 말까지 메모리 안전 로드맵을 공개하라고 권고한다면, 그 안에는 무엇이 들어 있어야 할까요?
최소한 다음은 포함되어야 합니다.
이것이 바로 제가 corrode에서 고객과 함께 하는 일의 핵심입니다. 우리는 클라우드 인프라, 임베디드 장치, 백엔드 서비스 등 여러 산업의 조직이 실용적인 Rust 도입 전략을 개발하도록 도왔습니다.
(조직 측면의 완전한 가이드는 Rust Business Adoption Checklist를 참고하세요.)
이미 벅찬 업무 위에 이 전환까지 혼자 헤쳐 나가기는 어렵습니다. 하지만 좋은 소식이 있습니다. 이 모든 것을 처음부터 혼자 알아낼 필요는 없습니다.
Rust 생태계는 성숙했고, 도구는 훌륭하며, 참고할 수 있는 산업 경험도 점점 쌓이고 있습니다. 대부분의 조직에 부족한 것은 동기가 아닙니다. 안내입니다.
바로 그 지점에서 제가 도움을 드립니다.
corrode에서 저는 이 전환을 헤쳐 나가는 조직을 위해 특별히 설계된 Rust 컨설팅과 교육을 제공합니다. 저는 팀이 다음을 할 수 있도록 도왔습니다.
또한 저는 Rust in Production podcast를 통해 현실의 Rust 도입 사례를 수년간 기록해 왔습니다. 여기서 Microsoft, Cloudflare, 1Password, Volvo, 그리고 많은 다른 기업이 경험을 공유합니다.
저는 이 블로그에서도 Rust의 장기 도입에 관한 실질적인 문제들을 다룹니다. 학습 곡선을 완만하게 만드는 방법부터 장기 유지보수 전략까지, 그리고 기반 소프트웨어를 위한 Rust를 이해하는 내용까지 다룹니다.
이 모든 것은 당신이 실제 근거에 기반해, 자신 있게, 충분한 정보를 바탕으로 의사결정을 내릴 수 있도록 존재합니다.
이것을 비즈니스 관점에서 말해 보겠습니다.
Rust 컨설턴트를 고용하는 것은 조직을 위한 보험입니다. 컨설팅 비용은 다음과 비교하면 반올림 오차에 가깝습니다.
지금 시작하면 일정, 예산, 범위를 당신이 통제할 수 있습니다. 어떤 구성 요소를 먼저 마이그레이션할지 선택할 수 있습니다. 팀을 지속 가능한 속도로 교육할 수 있습니다. 필요해지기 전에 조직 내부 지식을 구축할 수 있습니다.
기다리면 규제 기관, 고객, 경쟁사 같은 누군가가 조건을 정하게 됩니다.
소프트웨어를 더 안전하게 만들어야 한다는 압력은 정부, 산업, 표준 기구가 소프트웨어 책임을 바라보는 방식의 구조적 변화입니다. 메모리 안전은 가장 낮게 달린 열매이며, Rust는 성능 희생 없이 이를 제공하는 유일한 프로덕션 준비 언어입니다.
제가 권하는 것은 다음과 같습니다.
저는 위의 어느 하나든, 또는 전부든 기꺼이 도와드리고 싶습니다.
Rust를 평가 중이거나 준수를 위해 메모리 안전 로드맵을 만들어야 한다면, 무료 초기 상담을 위해 연락하세요.
저는 스타트업부터 Fortune 500 기업까지 모든 규모의 조직과 함께 일하며, Rust 도입을 실용적이고 지속 가능하며 규제 요구사항에 부합하도록 만듭니다.
당신의 조직이 뒤처지는 쪽이 아니라 앞서가는 쪽이 되도록 합시다.
2026년에 Rust가 법적으로 요구되나요? 어떤 단일 규제도 Rust를 이름으로 직접 의무화하지는 않습니다. 그러나 2026년의 규제 환경은 메모리 안전 언어 쪽으로 분명하게 이동했습니다. CISA는 새로운 핵심 인프라 소프트웨어에 메모리 안전하지 않은 언어를 사용하는 것을 “나쁜 관행”으로 분류합니다. EU Cyber Resilience Act는 제조사에게 악용 가능한 취약점에 대한 책임을 묻습니다. 독일의 BSI는 NIS-2 지침에서 Rust를 명시적으로 언급합니다. 메모리 안전 언어라면 무엇이든 선택할 자유는 있지만, 성능과 zero-cost abstractions가 중요한 시스템 프로그래밍에서는 Rust만이 유일한 프로덕션 준비 옵션입니다.
메모리 안전 로드맵이란 무엇이며, 2026년에 꼭 필요할까요? 메모리 안전 로드맵은 시간이 지남에 따라 조직이 어떻게 메모리 안전 취약점을 줄여 나갈지를 보여주는 문서화된 계획입니다. CISA는 소프트웨어 제조사가 2025년 말까지 이를 공개할 것을 권고했습니다. 2026년에는 특히 정부 기관에 소프트웨어를 판매하거나 핵심 인프라 분야에서 운영한다면, 로드맵이 없는 것이 점점 더 명백한 준수 공백으로 여겨집니다. 신뢰할 수 있는 로드맵에는 메모리 안전하지 않은 코드의 목록, 메모리 안전 언어로 진행하는 신규 개발 계획, 고위험 구성 요소를 위한 마이그레이션 전략, 그리고 이정표가 포함된 일정이 들어갑니다.
왜 Go, Java 또는 다른 메모리 안전 언어가 아니라 Rust인가요? Go, Java, C#, Python은 모두 메모리 안전하지만, 가비지 컬렉터와 런타임이 필요합니다. 베어 메탈 성능, 직접적인 하드웨어 접근, 커널 수준 코드, 또는 기존 C/C++ 코드베이스와의 긴밀한 통합이 필요할 때, 이런 언어들은 실행 가능한 대체재가 아닙니다. Rust는 2026년에 가비지 컬렉터 없이 C와 C++와 같은 수준에서 동작하는 유일한 메모리 안전 언어이기 때문에, Google, Microsoft, Amazon, Linux kernel, Windows kernel이 가장 성능에 민감한 구성 요소를 위해 이를 채택한 것입니다.
기존 조직에서 Rust 도입에는 얼마나 걸리나요? 팀 규모, 코드베이스 복잡성, 마이그레이션 범위에 따라 다릅니다. 보통 적절한 교육과 멘토링이 있다면 작은 팀이 Rust에서 생산성을 갖추는 데 2개월에서 4개월이 걸립니다. 첫 번째 프로덕션 구성 요소는 3개월에서 6개월 안에 출시할 수 있습니다. 완전한 메모리 안전 로드맵을 세우고 실행하는 것은 대부분의 조직에서 수년에 걸친 노력이며, 바로 그렇기 때문에 기다리지 않고 2026년에 시작하는 것이 중요합니다. 지금 시작하는 조직은 준수 마감이 더 강화될 때 조직 내부의 Rust 전문성을 갖추게 됩니다.
C 또는 C++에서 Rust로 점진적으로 마이그레이션할 수 있나요? 예. Rust의 FFI(Foreign Function Interface)는 C/C++에서 Rust를 호출하고 그 반대도 가능하게 해줍니다. 이는 전체 코드베이스를 다시 쓰지 않고도 모듈이나 구성 요소 하나씩 마이그레이션할 수 있다는 뜻입니다. 대부분의 성공적인 Rust 도입은 위험도가 높은 네트워크 노출 구성 요소 하나에서 시작해 점차 확장됩니다. DARPA의 TRACTOR 프로그램은 자동화된 C-to-Rust 변환 연구에까지 자금을 지원하고 있으며, 이는 이 마이그레이션 경로의 전략적 중요성을 보여줍니다.
Rust 컨설턴트는 실제로 무엇을 하나요? Rust 컨설턴트는 도입 과정에서 비용이 많이 드는 시행착오 단계를 건너뛸 수 있게 도와줍니다. 여기에는 코드베이스 중 어떤 부분을 먼저 마이그레이션할지 평가하기, 기존 개발자 교육하기, Rust 코딩 표준과 CI/CD 관행 수립하기, FFI 상호 운용 계층 설계하기, 아키텍처 결정 검토하기, 규제 요구사항을 충족하는 메모리 안전 로드맵을 만드는 데 도움 주기가 포함됩니다. 목표는 팀이 Rust에서 자립할 수 있게 만드는 것이지, 외부 도움에 영구적으로 의존하게 만드는 것이 아닙니다.
Rust 컨설팅 업체가 실제로 결과를 낼 수 있는지 어떻게 평가하나요? 공개된 실적을 보세요. 그들의 기술 글을 읽고 깊이를 직접 판단할 수 있나요? 이름을 아는 기업과 함께 일한 적이 있나요? 검토할 수 있는 코드를 공개하나요? 블로그 글, 오픈소스 기여, 컨퍼런스 발표, 팟캐스트처럼 공개된 방식으로 활동하는 컨설팅 업체는 어떤 영업 자료보다 훨씬 더 강한 신호를 줍니다. 또한 얼마나 많은 Rust 프로젝트를 프로덕션에 출시했는지, 과거 고객이 이후 자립할 수 있었는지도 물어봐야 합니다.
대형 컨설팅 회사보다 1인 Rust 전문가와 일하는 장점은 무엇인가요? 대형 컨설팅 회사에서는 실제로 누가 올지 아는 경우가 드뭅니다. 영업 미팅에 나온 사람이 코드를 작성하는 사람이 아닙니다. 1인 전문가는 아키텍처를 평가한 사람과 pull request를 리뷰하고, 개발자를 멘토링하고, Slack에서 질문에 답하는 사람이 동일하다는 뜻입니다. 인수인계도 없고, 전달 과정에서 지식이 사라지지도 않으며, 당신의 예산으로 주니어 개발자가 배우는 일도 없습니다. 대신 제약은 수용 능력입니다. 1인 전문가는 한 번에 제한된 수의 고객과만 일할 수 있고, 이는 보통 각 계약에 더 높은 몰입을 의미합니다.