제목: 해킹을 당해야 러스트를 쓴다는 말은 보안 논리가 아니라 재난 숭배임


“해킹 같은 것을 당해봐야 러스트가 널리 쓰인다”는 말에는 일부 사실과 큰 비약이 섞여 있다.

대형 보안 사고가 메모리 안전성에 대한 관심을 높이고 러스트 채택을 촉진할 수는 있다. 『러스트 담론을 해체하다』도 하트블리드 같은 사고 이후 메모리 안전성에 대한 산업계 요구가 커졌고, 러스트가 그 배경에서 주목받았다고 설명한다.

하지만 여기서 “그러므로 해킹을 당해야 한다”는 결론은 나오지 않는다.

책은 러스트의 채택을 단일 원인으로 설명하지 않는다.

러스트의 채택은 기술적 배경, 개발자 경험, 서사, 기관 후원과 공동체가 상호작용한 결과다.

즉 보안 사고는 여러 채택 요인 중 하나일 뿐이다. Cargo와 툴체인, 기존 코드 규모, 인력, 전환 비용, 생태계, 경영 판단과 규제도 함께 작용한다. 해킹을 필수 조건으로 바꾸는 것은 가능한 촉진 요인을 필연적 조건으로 과장하는 것이다.

더 큰 문제는 “해킹”과 “메모리 안전 취약점”을 같은 것으로 취급한다는 점이다.

책 3.2절은 다음과 같이 구분한다.

러스트의 안전성은 모든 버그가 없다는 뜻이 아니라, 정의된 범위의 메모리 오류와 미정의 동작을 방지하는 보증이다.

명령어 삽입, 인증 오류, 권한 설계 실패, SQL 인젝션, 공급망 공격, 잘못된 클라우드 설정과 운영 실수는 러스트로 작성했다고 자동으로 사라지지 않는다. 실제로 러스트 표준 라이브러리에서도 메모리 오류가 아닌 명령어 삽입 취약점이 발생한 적이 있다.

그러므로 다음과 같은 추론은 성립하지 않는다.

해킹당했다
→ C나 C++ 때문이었다
→ 러스트였다면 막혔다
→ 러스트를 쓰지 않은 업체는 무능하거나 부패했다

이 네 단계는 각각 따로 증명해야 한다.

그리고 “문란하고 저능한 업계”, “쓰레기 업체를 싹 다 폐업시키고 정상화해야 한다”는 말은 기술 분석이 아니다.

접대와 부패로 계약을 따내는 업체가 실제로 있다면 계약 자료, 내부통제, 법 집행과 조달 제도로 판단하면 된다. 러스트 사용 여부는 기업 윤리의 측정 기준이 아니다.

부패한 회사도 러스트를 사용할 수 있고, 정직하고 유능한 회사도 Java, C, Ada, Go를 선택할 수 있다. 언어 선택을 도덕성과 지능의 증거로 사용하는 순간 기술 논의는 신분 판정으로 바뀐다.

책 8.5절은 이런 구조를 다음과 같이 지적한다.

특정 기술의 숙련이나 채택을 일반 지능, 직업적 자격 또는 정상성의 기준으로 확대하면 논의는 기술 평가에서 사람과 집단의 지위 판정으로 이동한다.

러스트가 적합한 분야에서는 러스트를 도입하면 된다. 메모리 안전 위험이 큰 신규 시스템, 네트워크 경계, 파서, 드라이버와 고위험 구성요소에서는 강력한 선택지가 될 수 있다.

하지만 기존 시스템에서는 부분 교체, 리팩터링, 샌드박싱, 퍼징, 정적 분석, 권한 분리와 다른 메모리 안전 언어가 더 현실적일 수도 있다. 무엇이 적절한지는 사고를 기다려 결정하는 것이 아니라 위험, 비용, 코드 규모와 실패 조건을 비교해서 결정해야 한다.

해킹 피해는 기술 홍보 행사가 아니다.

피해를 입는 것은 추상적인 “업계”가 아니라 개인정보가 유출된 사용자, 서비스가 중단된 고객과 복구 비용을 부담하는 노동자들이다. 타인의 피해를 “신선한 긴장감”이나 업계 정화의 기회로 보는 것은 보안 의식이 아니라 재난을 기술 확산의 도구로 소비하는 태도다.

러스트의 가치는 실제 보증과 적용 조건으로 증명하면 된다.

해킹을 기다릴 필요도 없고, 다른 언어를 쓰는 업체를 저능하거나 쓰레기라고 부를 필요도 없다.


『러스트 담론을 해체하다』
2.1 기술적 배경: 메모리 안전성과 성능 목표
3.2 러스트 안전성의 정의, 경계와 한계
8.5 자격과 정상성의 규정: 게이트키핑과 담론적 배제