RustConf 2025에서 Chandler Carruth가 Rust와 Carbon의 상호운용성 접근을 비교했다. 그는 C++ 브라운필드 코드를 점진적으로 메모리 안전하게 전환하려는 Carbon의 전략과, 러스트의 강점과 한계를 대비시키며 두 언어가 상호 보완적으로 공존할 필요가 있다고 주장했다.
러스트와 카본 비교 [LWN.net]
LWN .net 소스에서 전하는 뉴스
* [LWN FAQ](https://lwn.net/op/FAQ.lwn)
* [기고 안내](https://lwn.net/op/AuthorGuide.lwn)
사용자: 암호: | |
LWN 구독자의 혜택 LWN 구독의 가장 큰 가치는 저희가 발행을 계속할 수 있도록 돕는 것이지만, 그뿐만 아니라 구독자는 모든 사이트 콘텐츠에 즉시 접근하고 여러 추가 기능을 이용할 수 있습니다. 오늘 가입해 주세요!
By Daroc Alden
2025년 9월 16일
러스트와 C/C++ 간의 안전하고 사용하기 편한 상호운용성은 워싱턴주 시애틀에서 열린 RustConf 2025에서 인기 있는 주제였다. Chandler Carruth는 러스트와 실험적 "(C++)++" 언어인 Carbon의 상호운용성 접근을 비교하는 발표를 했다. 그의 최종 결론은, 시간이 지나며 러스트의 타 언어 인터페이스 능력이 확장되고는 있지만, 가까운 시일 내에 C++ 상호운용성의 완전한 해법을 제공하지는 못할 것이라는 것이었다 — 따라서 기존 C++ 프로젝트를 점진적으로 업그레이드하는 데 Carbon이 다른 접근을 취할 여지가 있다는 것이다. 그의 슬라이드는 예제 코드를 더 자세히 살펴보고 싶은 독자에게 공개되어 있다.
청중 상당수가 이미 Carbon을 알고 있는 듯했기에, Carruth는 언어의 동기에 대해 긴 시간을 쓰지 않았다. 간단히 말해, Carbon은 C++의 난해한 문법 일부를 덜어내고, 컴파일러가 검사할 수 있는 메모리 안전성 주석을 더 잘 달 수 있게 하는 C++ 대체 프런트엔드를 만들려는 프로젝트다. Carbon은 C++과 완전히 호환되도록 의도되었으며, 기존 C++ 프로젝트를 파일 단위로 Carbon으로 다시 쓸 수 있고, 이상적으로는 컴파일러나 빌드 시스템을 전혀 바꾸지 않아도 된다. 다만 Carbon은 아직 사용할 수 있는 상태는 아니다 — 프로젝트 기여자들이 언어의 더 복잡한 세부 사항을 채워 넣고 있는데, 그 이유는 Carruth의 발표에서 분명해졌다.
![Image 4: [Chandler Carruth]](https://static.lwn.net/images/2025/chandler-carruth-rustconf-small.png)
"RustConf에서 러스트가 아닌 프로그래밍 언어 이야기를 하는 건 항상 조금 흥미진진합니다"라고 Carruth는 말문을 열었고, 객석에서는 웃음이 나왔다. 그는 오랫동안 C++로 일해 왔고, 2020년 프로젝트가 시작될 때부터 Carbon을 개발해 왔다. 현재 그는 구글의 언어 및 컴파일러 팀의 일환으로 Carbon 작업에 대해 급여를 받고 있다. 그는 구글의 연구 자료를 잠깐 보여주었는데, 구글이 다루는 보안 취약점의 대다수가 메모리 안전한 언어로 예방될 수 있었음을 시사했다. 다만 RustConf 청중이 메모리 안전성의 이점을 잘 알고 있을 것이라 예상했기에 그 주제에 오래 머무르지는 않았다.
문제는, 세상에는 C와 C++로 쓰인 기존 소프트웨어가 아주 많다는 것이다. 그 소프트웨어를 마법처럼 사라지게 할 방법은 없다. 그중 일부라도 메모리 안전한 언어로 이전하려면, 그 언어들이 기존 소프트웨어 생태계의 나머지와 통합되어야 한다고 그는 말했다. 상호운용성은 있으면 좋은 것이 아니라 — 메모리 안전한 언어를 도입할 수 있게 만드는 핵심 요소다.
러스트에는 이미 C/C++ 코드와 상호운용을 가능케 하는 여러 도구가 있다. Carruth는 러스트의 기본 외부 함수 인터페이스, bindgen과 cbindgen, cxx 크레이트, 그리고 구글의 Crubit을 열거했다. 하지만 그는 이들 어느 것도 기존 C++ 소프트웨어에 정말 좋은 해법은 아니라고 주장했다. 그는 소프트웨어를 "그린필드(신규, C++에 강하게 결합되지 않고, 추상화 경계가 강한)"와 "브라운필드(기존 C++에 강하게 결합되고, 거대한 API 표면을 가짐)" 사이의 스펙트럼상에 있다고 정의했다. 그린필드 소프트웨어는 비교적 러스트로 옮기기 쉽다 — 기존 바인딩 도구를 활용해 모듈 단위로 옮길 수 있기 때문이다. 브라운필드 소프트웨어는 훨씬 어렵다. 쉽게 분해할 수 없으므로, C++로 작성된 코드와 러스트로 작성된 코드 사이의 인터페이스가 훨씬 더 복잡하고 양방향이 되어야 하기 때문이다.
문제는, 러스트가 언젠가 그 격차를 메울 수 있느냐는 것이다. 그는 그렇지 않다고 — 적어도, 가까운 시일 내에는, 그리고 천문학적인 노력이 없다면 — 생각한다. 하지만 러스트가 메모리 안전에 접근하는 유일한 방법은 아니다. 이상적으로는 기존 C++ 코드를 제자리에서 메모리 안전하게 만들 수 있어야 한다. 많은 이들이 그렇게 하려 시도했지만, "C++ 위원회가 아마 그걸 하지는 않을 것"이다. 현재 상태의 C++에 메모리 안전을 성공적으로 더할 방법은 없다고 그는 말했다.
그럼에도, 기반 언어에서 더 유능하고 유연한 후속 언어로 전환하는 데 성공한 언어들이 몇 가지 있다. TypeScript는 JavaScript의 진화이고, Swift는 Objective-C의 진화이며, C++ 자체도 C의 진화다. Carruth는 Carbon이 C++의 유사한 진화가 될 수 있다고 본다 — 가장 뿌리 깊은 브라운필드 소프트웨어를 우선시하면서, 메모리 안전한 언어로 점진적 마이그레이션을 할 수 있는 경로 말이다. 러스트는 메모리 안전 문제를 그린필드 방향에서 접근하고, Carbon은 반대편에서 접근한다고 그는 말했다. 그래서 러스트와 Carbon은 꽤 다른 언어가 된다.
그의 발표의 실제 초점은 두 언어의 차이가 어디에 있는지, 그리고 각 언어가 서로에게서 무엇을 배울 수 있다고 생각하는지 보여주는 데 있었다. 러스트와 Carbon의 문법은 "극단적으로 다르지는" 않다. 그가 집중하고자 한 차이는 더 추상적이다. 예컨대 러스트에서 컴파일 단위는 여러 모듈로 구성될 수 있는 하나의 크레이트다. 따라서 모듈 간 상호 참조(사이클)가 허용되며, 그것이 그냥 동작한다. 이는 Carbon이 지원할 수 없는 것이다. 왜냐하면 "기존 C++ 코드는 개별 파일을 분리해 컴파일할 수 있는 능력에 종종 기묘하게 의존"하기 때문이다. 그래서 Carbon은 C++의 모델을 계승한다. 전방 선언, (선택적) 분리된 헤더 파일, 그리고 더 복잡한 링커를 포함해서 말이다. 이는 Carbon의 모델을 더 복잡하게 만든다. 하지만 그 복잡성은 무에서 온 것이 아니다 — "그건 C++에서 온다".
또 다른 예는 트레이트와 클래스의 차이다. 문법적으로 보면 러스트의 트레이트와 Carbon의 클래스는 크게 다르지 않다 — Carbon은 메서드를 struct 정의 내부에 쓰고, 러스트는 따로 쓴다는 정도의 차이다 — 하지만 개념적으로는 큰 차이가 있다. Carbon은 상속, 가상 함수, protected 필드 등을 다뤄야 한다. "이것들은 러스트에는 존재하지 않는, 그래서 다루지 않아도 되는 복잡성"이다. Carbon은 C++ API가 있는 그 자리에서 그것을 맞이하고자 한다고 그는 말했다. 심지어 C++/Carbon 경계를 넘어 상속할 수도 있다.
이런 종류의 차이는 언어 전반에 광범위하게 퍼져 있다. 연산자 오버로딩, 제네릭, 형 변환은 Carbon에서 더 복잡하다. 왜 이렇게 하는가? 이런 추가 복잡성이 왜 가치가 있는가? 설명을 위해, 그는 가상의, 그러나 흔치 않은 편은 아닌 C++ API 예제를 보여주었다:
int EVP_AEAD_CTX_seal_scatter(
const EVP_AEAD_CTX *ctx,
std::span<uint8_t> out,
std::span<uint8_t> out_tag,
size_t *out_tag_len,
std::span<const uint8_t> nonce,
std::span<const uint8_t> in,
std::span<const uint8_t> extra_in,
std::span<const uint8_t> ad);
이 예제는 BoringSSL 암호 라이브러리의 실제 함수에서 가져와 각색한 것이다. 각 std::span은 포인터와 길이의 조합이다. 이를 러스트에서 충실히 표현하는 데 있어서의 핵심 문제는 사실 코드 자체에는 보이지 않는다. 이 함수의 문서는 out이 반드시 in과 같은 포인터이거나, 혹은 완전히 겹치지 않는 메모리 조각이어야 한다고 설명한다. 포인터가 같으면, 함수는 주어진 평문 입력 버퍼를 제자리에서 암호화한다. 그렇지 않으면, 암호화된 출력은 입력 버퍼를 건드리지 않고 출력 버퍼에 기록된다. 다른 포인터들은 서로 에일리어싱해서는 안 된다.
Carbon은 아직 진행 중이지만, 이런 API를 기계적으로 검사 가능한 방식으로 표현하는 현재 계획은 "에일리어스 집합(alias set)"을 사용하는 것이다. 이는 어떤 포인터들이 서로 에일리어싱이 허용되는지, 그리고 어떤 포인터들은 허용되지 않는지를 보여주는 주석(애너테이션)이다. 결과적인 Carbon 코드는 다음과 같을 수 있다:
fn EVP_AEAD_CTX_seal_scatter[^inout](
ctx: const EVP_AEAD_CTX ^*,
out: slice(u8 ^inout),
out_tag: slice(u8 ^),
out_tag_len: u64 ^*,
nonce: slice(const u8 ^),
input: slice(const u8 ^inout),
extra_input: slice(const u8 ^),
ad: slice(const u8 ^)) -> i32;
여기서 inout은 특정 에일리어스 집합에 붙인 이름으로, out과 input을 주석 처리하는 데 사용된다. 함수 시그니처의 다른 모든 포인터들은 에일리어스 집합이 지정되어 있지 않으므로, 컴파일러가 서로 에일리어싱할 수 없도록 보장한다.
이 API를 러스트로 표현하려고 하면 제대로 작동하지 않는다. 언어가 가변 참조가 서로 에일리어싱되는 것을 절대 허용하지 않기 때문에, 제자리(in-place) 처리와 복사 처리의 경우를 위해 서로 다른 시그니처를 가진 두 개의 별도 래퍼 함수를 만들게 된다. 이 함수를 포함하는 모듈을 러스트로 다시 쓰는 작업은, 실제 코드의 단순한 번역과 인터페이스의 리팩터링이 뒤섞인 복잡한 과정이 된다.
Carruth에 따르면 상호운용성 측면에서 Carbon의 힘은, 이런 것들을 분리해 작은, 별개의 단계로 수행하게 해준다는 점이다. 그는 또 다른 C++ 프로그램 예시를 보여주었는데, 실제로는 메모리 안전했지만 러스트의 수명 분석과는 맞지 않는 경우였다. 메모리 안전성에 대한 전산적 분석은 결코 완벽할 수 없기 때문에 Carbon이 여기에서 훨씬 더 잘할 수 있을 것 같지는 않다 — 하지만 Carbon에서는 컴파일러가 메모리 안전하다고 증명할 수 없는 패턴을 오류가 아닌 경고로 바꿀 수 있다.
이처럼 C++이 있는 자리에서 그것을 맞이하려는 초점은 Carbon을 다른 언어로 만든다. 상호운용성과 점진적 마이그레이션에 특별히 맞춤화되며, 이는 공짜가 아니다. 언어를 다른 방식보다 더 복잡하게 만든다. Carruth는 이것이 모든 언어에 대해 올바른 절충이라고 생각하지는 않는다. 하지만 목표가 소프트웨어 생태계 전반에서 메모리 안전한 소프트웨어를 갖는 것이라면, 러스트와 Carbon 모두가 설 자리가 있어야 한다고 그는 본다. 이것은 언어 간 경쟁이 아니라, 다양한 프로젝트의 상이한 요구를 함께 포괄하기 위해 두 다른 언어가 함께 일하는 것이다.
| 이 글의 색인 항목 |
|---|
| 컨퍼런스 |
댓글을 게시하려면
2025년 9월 16일 17:10 UTC (화) 게시자: jbills (구독자, #161176) [링크] (42개의 응답)
"C++ 위원회가 아마 그걸 하지는 않을 것"
C++ 진영이 들으면 안 됩니다. 그들은 프로파일이 C++에서 안전성을 위한 유일한 실행 가능한 해결책이라고 완강히 주장하고 있거든요.
2025년 9월 16일 22:21 UTC (화) 게시자: willy (구독자, #9762) [링크] (41개의 응답)
관련 의견: https://www.theregister.com/2025/09/16/safe_c_proposal_di...
2025년 9월 16일 22:39 UTC (화) 게시자: Wol (구독자, #4433) [링크] (40개의 응답)
분명 C++ 쪽에서는 메모리-안전 함수가 오직 다른 메모리-안전 함수만 호출하도록 제한하는 것을 원치 않는 듯합니다. 그런데 그건 러스트의 절대적인 기본 원칙이죠.
하지만 그게 안전성의 근본 요구 사항 아닌가요? 제가 이해하기로는, 프로파일의 가장 큰 문제는 서로 다른 프로파일의 코드를 섞으면, 프로파일이 제공해야 할 보장이 사라진다는 점 아닙니까!?
그래서 "프로파일은 하나뿐"이라고 하지 않는 이상, 프로파일은 작동하지 않습니다. 그러니 STL이 단일 프로파일을 강제하게 될 겁니다. 그 말은 다른 모든 프로그램도 같은 프로파일을 써야 한다는 뜻이죠. 그러면 C++ 진영은 — 실제로는 — 안전한 함수가 비-안전한 함수를 호출하는 것을 금지하게 됩니다... 바로 그들이 하고 싶지 않다고 말했던 것을요.
감사합니다,
Wol
2025년 9월 16일 23:32 UTC (화) 게시자: pizza (구독자, #46) [링크] (37개의 응답)
분명 C++ 쪽에서는 메모리-안전 함수가 오직 다른 메모리-안전 함수만 호출하도록 제한하는 것을 원치 않는 듯합니다. 그런데 그건 러스트의 절대적인 기본 원칙이죠.
어... 러스트는 비-안전한 것들을 호출하는 데 아무 문제도 없습니다. 그 반대도 마찬가지고요.
2025년 9월 17일 0:28 UTC (수) 게시자: NYKevin (구독자, #129325) [링크] (36개의 응답)
조금 관대하게 보자면, 핵심은 안전하지 않은 함수를 안전한 함수에서 호출하는 것이 거의(하지만 완전히는 아님) Java에서 체크 예외를 던지는 함수를 호출하는 것만큼 성가시다는 점이라고 생각합니다. 물론 이것은 의도적입니다 — 합리적으로 피할 수 있다면 안전하지 않은 함수를 호출해서는 안 되며, 러스트는 정말로 필요할 때 참을 수 있을 정도로만 불편함을 낮춰 줍니다.
하지만 C++은 러스트가 아닙니다. C++에는 검증 불가능한 비-안전 레거시 코드의 긴 꼬리가 있습니다. 그런 코드에 대한 모든 호출이 러스트에서의 unsafe 호출만큼 성가시다면, C++ 개발자들은 안전 프로파일을 끄는 방법을 곧잘 찾아낼 것이고 실제로 그렇게 할 겁니다.
저는 안전 프로파일이 실행 가능하다고 말하는 게 아닙니다 — 안전 프로파일을 면밀히 살펴본 대부분의 합리적인 사람들처럼, 아마 운명이 정해져 있다고 봅니다. 하지만 애초에 좋은 대안이 있었는지도 잘 모르겠습니다. 표준 위원회는 정말 궁지에 몰려 있었습니다.
2025년 9월 17일 5:38 UTC (수) 게시자: DemiMarie (구독자, #164188) [링크] (32개의 응답)
C++를 아예 폐기하고, 사람들이 코드를 다시 작성해야 한다고 말할 때가 온 건 아닌지 궁금합니다. 맞아요, 엄청난 산 같은 작업이 되겠지만, 제가 아는 순수 소프트웨어적 해결책으로는 그게 유일합니다. CHERI는 하드웨어로 메모리 비안전성을 해결할 수 있지만, 그 하드웨어는 아직 사용 불가능합니다.
2025년 9월 17일 7:11 UTC (수) 게시자: viro (구독자, #7872) [링크] (23개의 응답)
당신 말만 믿고 사람들이 엄청난 양의 일을 하라고 하는 것에 관해: "나는 깊고 광활한 심연에서 정령을 불러낼 수 있다". 그에 대한 대답을 기억하시오?
당신은 존재하지 않는 권위를 전제하고 있습니다. 당신에게도, 다른 누구에게도 말이죠.
2025년 9월 17일 8:55 UTC (수) 게시자: smurf (구독자, #17840) [링크] (22개의 응답)
현실을 직시합시다. C와 C++는 메모리 안전하지 않으며, 그렇게 만들도록 설득될 수도 없습니다. 그러니 네, "폐기"되어야 합니다.
그렇다고 해서 누군가가 무언가를 다시 작성하도록 강요된다는 뜻은 아닙니다. 폐기된 소프트웨어(와 하드웨어)는 오래도록 살아남곤 합니다.
다만 세 줄 이상을 바꿔야 할 일이 생긴다면, 그 폐기 태그는 관리자가 터무니없는 라이브러리에 또 하나의 반창고를 붙이라고 우기는 대신, 이성적인 것으로 다시 쓰자고 설득하는 데 도움이 됩니다 — 그리고 이는 장기적으로 엄청난 시간을 아끼게 되는 경우가 많습니다.
2025년 9월 17일 9:40 UTC (수) 게시자: smurf (구독자, #17840) [링크] (20개의 응답)
어쨌든, 이미 다양한 사람과 조직들에 의해 폐기되었다고 봐야 합니다. 예를 들어 CISA:
중요 인프라 또는 NCF(국가 핵심 기능)에 사용하기 위한 새로운 제품 라인을 메모리-비안전 언어(예: C 또는 C++)로 개발하는 것은 … 위험하며 국가 안보, 국가 경제 안보, 그리고 국가 공중 보건 및 안전에 대한 위험을 크게 높입니다.
– CISA, 제품 보안 나쁜 관행
2025년 9월 17일 17:43 UTC (수) 게시자: hmh (구독자, #3838) [링크] (19개의 응답)
하지만 CISA가 거의 항상 방대한 의존성 집합과 거대한 SBOM을 갖게 되는 언어들에 대해 뭐라고 하나요?
C와 C++에 대해 뭐든 불평하셔도 좋지만, 의존성 지옥은 C와 C++ 생태계에서는 드뭅니다. 종종 주방 싱크대까지 전부 포함하는 소수의 유명 프레임워크를 사용하기 때문인데, 그런 것들은 잘 유지되고 철저히 관리됩니다(예: glib, Qt).
그러니, 네, 일반적으로는 C와 C++를 폐기해야 할지도 모르지만, 제 생각에는 의존성 지옥은 어떤 보안 민감 맥락에서도 용납되어서는 안 됩니다. 잘 작성된 C 또는 C++를 사용하는 것보다 훨씬 나쁜 문제입니다.
2025년 9월 17일 19:32 UTC (수) 게시자: NYKevin (구독자, #129325) [링크] (8개의 응답)
러스트는 거대한 의존성을 강요하지 않습니다. 심지어 메모리 할당자도 강요하지 않습니다. 거대한 의존성들은 개발자(그리고 그 연장선상에 있는 사용자 및 다른 이해관계자)들이 그 의존성의 이점을 좋아해서, 바퀴를 다시 발명하는 대신 그것들을 선택하기 때문에 존재합니다.
2025년 9월 18일 13:52 UTC (목) 게시자: LtWorf (구독자, #124958) [링크] (7개의 응답)
이런 말은 다소 무의미합니다.
언어에 큰 표준 라이브러리나 몇 개의 잘 정립된 꽤 큰 라이브러리가 없으면, 필연적으로 많은 의존성을 갖게 됩니다.
2025년 9월 19일 3:52 UTC (금) 게시자: NYKevin (구독자, #129325) [링크] (6개의 응답)
표준 라이브러리가 크지 않다면
그게 무슨 상관이죠? C, C++, 러스트 어느 쪽도 큰 표준 라이브러리를 갖고 있지 않습니다. 음, C++는 좀 크다고 주장할 수는 있겠네요... 그래도 (예: 파이썬)에 비하면 한참 부족합니다(그리고 그 기능의 상당수는 러스트의 stdlib에도 있습니다).
또는 몇 개의 잘 정립된 꽤 큰 라이브러리가 없다면,
이건 러스트 문제가 아니라, "개발자 전반이 큰 라이브러리를 좋아하지 않는다" 문제라고 봅니다. 러스트는 큰 라이브러리를 충분히 지원할 수 있습니다. 개발자들이 생산하거나 사용하지 않기로 선택하는 것은 Cargo 덕에 작은 라이브러리를 생산하고 사용하는 것이 상대적으로 고통이 덜하기 때문입니다. 우리는 빌드와 패키징 시스템이 충분히 편리한 거의 모든 프로그래밍 환경에서 비슷한 행동을 봅니다(Go, JavaScript 등 — 하지만 Java, C, C++ 등은 아님). 빌드/패키징 시스템에 심각한 결함이 있지만 그럭저럭 쓸만한 파이썬의 경우에는, 큰 라이브러리와 작은 라이브러리가 뒤섞여 있습니다.
이제, 이게 중요하지 않다고 주장할 수도 있겠죠. 어쨌든 의존성이 많은 언어라는 겁니다. 하지만 잠시 그 함의를 생각해보세요. 본질적으로, 당신은 "좋은" 언어는 당신이 선호하는 방식으로 개발자들이 일하게 만들기 위해 "나쁜" 빌드 시스템을 가져야 한다고 주장하게 됩니다. 제 더 넓은 요지는 시장은 당신과 당신의 선호에 답하지 않는다는 겁니다. 큰 라이브러리를 원한다면, 직접 작성하거나, 다른 누군가에게 의뢰하거나, 모노레포를 사용하는 고용주를 찾으면 됩니다.
2025년 9월 19일 11:02 UTC (금) 게시자: excors (구독자, #95769) [링크] (1개의 응답)
본질적으로, 당신은 "좋은" 언어는 당신이 선호하는 방식으로 개발자들이 일하게 만들기 위해 "나쁜" 빌드 시스템을 가져야 한다고 주장하게 됩니다.
그건 러스트의 기본 설계 철학처럼 들리네요 — 러스트는 의견이 분명한 언어이고, 그 의견은 전통적으로 인기 있는 것들과 다를 때가 있습니다.
예: 많은 생 포인터가 필요한 코드를 작성하는 데는 "나쁩니다"(예: 소유권이 복잡하지만 Rc+RefCell의 런타임 오버헤드를 감당할 수 없는 코드). 문법은 C보다 더 투박하고, 에일리어싱 규칙은 더 복잡하며 덜 명확하게 정의되어 있고, 성능이 더 나쁠 수도 있습니다(러스트 포인터는 타입 기반 엄격 에일리어싱이 없습니다). 문서는 무시무시한 경고로 가득하고, 커뮤니티는 unsafe를 너무 많이 사용하면 당신을 멀리할 겁니다, 등등.
C에서 온 프로그래머들은 종종 그런 방식으로 코드를 작성하고 싶어합니다. 그들이 구현하려 하는 첫 번째 자료구조 중 하나는 연결 리스트인데, C는 그걸 정말 잘하지만 러스트는 정말 못하죠. 하지만 러스트가 그걸 못하는 이유는, 러스트 설계자들이 당신이 그런 방식으로 코드를 작성하지 않기를 원하기 때문입니다. 생 포인터를 사용할 때 상당한 마찰이 있기를 원하는데, 그건 당신이 생 포인터를 쓰지 말아야 하기 때문입니다. 단기적으로는 C 프로그래머들을 화나게 하겠지만, 그들의 이익을 위한 것이고 장기적으로는 그것을 고마워하게 될 겁니다.
그 철학과 완전히 일관되게, 언어 설계자들이 거대한 의존성 트리는 위험하다고(다른 언어에서 온 프로그래머들이 그렇게 일하는 걸 좋아하는 것처럼 보여도), 언어와 도구를 그러한 방식을 덜 편하게 만들도록 설계할 수도 있었을 겁니다. Cargo.toml에 모든 추이적 의존성 소유자의 명시적 허용 목록을 요구해, 개발자들이 신뢰하는 무작위 GitHub 사용자의 수를 의식하게 만들고, 공동 유지관리되는 크레이트 묶음 쪽으로 끌리게 만든다든지요. C의 빌드 시스템 같은 우연히 끔찍한 일은 하지 말되, 언어 설계자들이 최선의 관행이라고 결정한 방향으로 사용자들을 이끄는 뭔가를 하자는 겁니다. 그들은 언어의 다른 많은 부분에서 이미 그렇게 해왔습니다.
이번에는 러스트가 그런 결정을 내리지 않았지만, 그랬어도(그리고 어쩌면 그랬어야) 이상하지 않다고 봅니다.
2025년 9월 19일 12:25 UTC (금) 게시자: farnz (구독자, #17727) [링크]
논쟁적으로 말하면, 바로 그런 일을 cargo vet 같은 도구가 합니다. 관심 있는 조직(예: Debian, FSF, Google, CENELEC 등)이, 현재 승인된 의존성 목록을 가져갈 수 있는 URL과 그들의 감사 기준을 설정해 줄 수 있습니다. 그런 다음 "메인 아카이브에 들어가고 싶다면, 의존성에 대해 'debian-main' 기준을 충족해야 한다"거나 "Chrome 빌드 시스템의 새로운 의존성은 우리 'safe-to-deploy' 감사 기준을 충족해야 한다"는 식으로 요구할 수 있습니다. 이것은 "방대한 의존성 트리"를 길들이는데, 당신이 의존성을 스스로 감사하고(그리고 이를 문서화한 audits.toml을 공개하고), 혹은 다른 사람의 의존성 감사를 가져오도록 요구합니다. 물론, 여전히 상관하지 않는 사람들에게는 거대한 의존성 트리를 허용합니다.
2025년 9월 22일 22:09 UTC (월) 게시자: marcH (구독자, #57642) [링크] (3개의 응답)
하지만 잠시 그 함의를 생각해보세요. 본질적으로, 당신은 "좋은" 언어는 당신이 선호하는 방식으로 개발자들이 일하게 만들기 위해 "나쁜" 빌드 시스템을 가져야 한다고 주장하게 됩니다.
그건 다음처럼 들립니다: "좋은" 언어는 개발자들이(비-안전한) 선호 방식 대신 (메모리-안전한) 당신이 선호하는 방식으로 일하도록 강제하기 위해 생 포인터 사용 경험을 "나쁘게" 만들어야 한다.
못 참겠네요 미안(그리고 excors에게 감사 https://lwn.net/Articles/1038755/)
오늘날 대규모 소프트웨어 공급망 공격 시대에는, "cargo vet" 같은 것들이 중요합니다. 그것이 최선의 해결책인지, 그리고 "방대한 의존성 트리"에 대해 강한 의견이 있는지는 모르겠습니다. 하지만 분명 대부분의 개발자들이 선호하는 방식(= AI가 임의의 고아 오픈소스 라이브러리를 가져오는 코드를 쓰게 하고 일찍 퇴근하기)을 하지 못하게 하는 일종의 SBOM 제약이 있어야 합니다.
(누군가 "그냥 당신의 개발자를 교육하고 통제하고 관리하세요"라고 답하지 않길 바랍니다. 그건 "신화의 직장" 논증입니다)
2025년 9월 23일 8:11 UTC (화) 게시자: taladar (구독자, #68407) [링크] (1개의 응답)
당신의 공급망 논증(AI를 통한 것이든 아니든)은 사실 잘 맞지 않습니다. 많은 커미터가 있는 대규모 의존성 프로젝트는, 유지관리자 누구도 잘 알지 못하는 곳에 누군가가 무작위 코드를 슬쩍 집어넣기 더 쉬운 편이지, 작은 의존성 묶음이 더 취약한 것은 아닙니다.
유지되지 않는 의존성에 대해서는, 바로 그 때문에 RUSTSEC의 미유지 라이브러리 공지가 있고, cargo-deny 같은 도구가 있습니다. 물론, 의존성이 미유지 상태인지 감지하는 방식은 개선될 수 있습니다. 하지만 큰 의존성을 유지된 것처럼 가장하는 것(실제로는 코드베이스의 50%는 유지되고 50%는 수년간 아무도 들여다보지 않은 코드인 경우)보다는 본질적으로 여전히 낫습니다.
2025년 9월 23일 15:16 UTC (화) 게시자: marcH (구독자, #57642) [링크]
혹시 다른 댓글에 답글을 다신 건가요? 제 댓글을 다시 읽어봤는데, 당신이 방금 근거 없이 단정한 것처럼 "접근 A가 B보다 공급망 공격에 더 취약하다"는 내용은 찾아볼 수가 없네요.
저는 단지 공급망 공격이 극심하고 아직 충분히 심각하게 다뤄지지 않고 있다고 썼을 뿐입니다. 제 생각에 오늘날 가장 중요한 질문은 그게 어디에서 가장 많이 오는가가 아닙니다. 최선의 방어가 무엇인가입니다. 이상적으로는, 그 방어는 어디에서 오든 효과적이어야 합니다.
2025년 9월 23일 15:53 UTC (화) 게시자: farnz (구독자, #17727) [링크]
SBOM 제약과 러스트 생태계와 관련해서, 저는 하나의 필수 도구와, "장기적 방향"을 놓고 경쟁하는 두 가지가 있다고 봅니다. 필수 도구는 cargo deny인데, 세 가지 중요한 기능(그리고 SPDX 라이선스 태그 검사)을 제공합니다:
그 위에, 최소한 "이 의존성의 코드는 신뢰할 수 있는 당사에 의해 감사를 받았다"와 "작동해서 쓰고 있지만 릴리스 전에 감사를 해야 한다"를 구분해 주는 기능이 필요합니다. cargo vet은 명시적으로 구성된 신뢰 감사 목록(추이적 신뢰 없음)으로 이를 수행하고, cargo crev은 웹오브트러스트 방식으로 합니다.
저는 어느 도구에도 특별한 편견이 없습니다. 둘 다 작동 가능해 보이며, 어떤 것이 선호될지는 당신이 무엇을 하는지와 누구를 신뢰할지 결정하는 방식의 세부에 달려 있습니다.
2025년 9월 18일 7:09 UTC (목) 게시자: taladar (구독자, #68407) [링크] (9개의 응답)
솔직해집시다. C와 C++에서는 의존성 수가 더 적고, 개별 의존성은 종종 거대한데, 그건 그들의 빌드 시스템이 새로운 프로젝트를 만들고 많은 프로젝트를 포함시키는 일을 고통스럽게 만들기 때문이지, 하나의 거대한 의존성에 모든 것을 집어넣는 것이 좋은 생각이어서가 아닙니다.
2025년 9월 18일 13:55 UTC (목) 게시자: LtWorf (구독자, #124958) [링크] (8개의 응답)
그 말이 왜 의존성 수가 적은지를 설명하는 건 맞습니다. 하지만 최종 결과는 의존성이 적다는 것이고, 그런 의존성들은 더 잘 알려져 있고 테스트가 잘 되어 있으며, 심사하기도 쉬운 경향이 있습니다.
2025년 9월 18일 15:11 UTC (목) 게시자: farnz (구독자, #17727) [링크] (7개의 응답)
의존성이 적다고 해서 더 잘 테스트되거나 심사가 쉬워진다는 뜻은 아닙니다 — 제 경험상 오히려 정반대입니다. 당신이 신경 써야 하는 것은, 사용하는 각 기능 구성요소가 잘 테스트되어 있고 심사하기 쉬운가입니다. 각 기능 구성요소가 각자의 라이브러리에 있다면 이는 비교적 쉽습니다. 테스트와 변경 사항을 보고 유지관리 방식에 만족하는지 확인하면 됩니다.
여러 기능 구성요소를 묶어 놓은 큰 라이브러리(예: 12개의 "Essentials"와 47개의 "Add-ons"로 구성된 Qt)에서는 더 어려워집니다. 라이브러리 전체로는 테스트가 잘 되어 있고 유지관리가 잘 될 수 있지만, 당신이 신경 쓰는 부분이 테스트되지 않았고 집안 스타일에 맞춘 정기 리포매팅 이상의 유지관리를 거의 받지 못한다면, 그건 당신에게 소용이 없습니다.
작은 라이브러리는 담고 있는 기능 구성요소가 더 적은 경향이 있습니다. 따라서 라이브러리 전체 상태에서 당신이 신경 쓰는 구성요소의 상태로 일반화할 때 맞을 확률이 더 높습니다. 단일 구성요소만 가진 라이브러리에서는 자명합니다(라이브러리의 상태와 구성요소의 상태가 같습니다). 흥미로운 구성요소가 소수인 경우에도 대체로 그렇습니다.
그리고 제 경험상, 라이브러리가 잘 테스트되고 기능적임을 심사하는 사람들은 하위 구성요소에 대해 심층 분석을 하지 않는 경향이 있습니다. 그들은 Qt를 하나의 것으로 간주하고, 따라서 Qt GUI가 잘 테스트되었고 고품질 코드라면 Qt CoAP도 좋을 가능성이 높다고 가정합니다. 하지만 그것들은 별개의 구성요소이고, Qt GUI와 Qt CoAP를 작업하는 엔지니어들이 겹치지 않을 수도 있습니다.
2025년 9월 18일 15:46 UTC (목) 게시자: pizza (구독자, #46) [링크] (3개의 응답)
당신이 신경 써야 하는 것은, 사용하는 각 기능 구성요소가 잘 테스트되어 있고 심사하기 쉬운가입니다.
당신은 기술적인 측면만 보고 있습니다.
규제/컴플라이언스 등 부담은 고유 구성요소 수에 선형으로 증가하며, 구성요소 복잡도로 인한 노력은 보통 큰 고정 기본 오버헤드에 의해 압도됩니다.
(어쩌면 이런 예가 있을 수 있겠네요. $dayjob-1에서는 각 고유 타입/사이즈의 나사마다 별도의 서류 작업과 제조/배치 추적이 필요했습니다. 왜냐하면 3테슬라 자기장에 >1MW 기울기 펄스를 주면... 작은 나사라도 치명적인 발사체가 되기 때문이죠)
2025년 9월 18일 16:18 UTC (목) 게시자: farnz (구독자, #17727) [링크] (2개의 응답)
제 경험상, 규제 영역에서는 하나의 라이브러리에서 100개의 기능 구성요소를 얻느냐, 각자 하나의 구성요소를 가진 100개의 라이브러리를 쓰느냐에 관심이 없습니다 — 그들은 사용한 각 구성요소에 대해 컴플라이언스 부담을 요구하지, 공급자마다 요구하지 않습니다. 나사가 모두 The Phillips Screw Company에서 왔다고 해서 고유 타입/사이즈마다 서류 작업을 피할 수는 없습니다. 어차피 각 고유 타입/사이즈마다 서류를 해야 합니다. 소프트웨어에서도 유사합니다 — 모두 "Qt"라고 해서 사용하는 각 구성요소에 대한 서류를 피할 수 있는 것은 아닙니다.
2025년 9월 22일 23:05 UTC (월) 게시자: marcH (구독자, #57642) [링크] (1개의 응답)
제 경험상, 규제 영역에서는 하나의 라이브러리에서 100개의 기능 구성요소를 얻느냐, 각자 하나의 구성요소를 가진 100개의 라이브러리를 쓰느냐에 관심이 없습니다 — 그들은 사용한 각 구성요소에 대해 컴플라이언스 부담을 요구하지, 공급자마다 요구하지 않습니다.
"규제 영역"의 정확한 범위가 뭔지는 모르겠지만, 여기 $BIGCORP에서는 분명 어느 정도의 공급자별 작업이 있습니다. 공급자에 대해 전혀 신경 쓰지 않는 컴플라이언스 프로세스가 어떻게 가능하죠?
나사가 모두 The Phillips Screw Company에서 왔다고 해서 고유 타입/사이즈마다 서류 작업을 피할 수는 없습니다
적어도 공급자 정보는 복사/붙여넣기 할 수 있죠. 서로 다른 100개의 공급자를 조사하는 것보다는 훨씬 적은 작업입니다.
2025년 9월 23일 8:18 UTC (화) 게시자: farnz (구독자, #17727) [링크]
일부 규제 프로세스에서는, 컴플라이언스 프로세스가 공급자에 전혀 신경 쓰지 않습니다. 대신, 빌드 시스템이 접근할 수 있는 모든 코드 줄이 (a) 회사의 지정된 직원에 의해 승인되었고, (b) 지정된 직원의 승인 없이 해당 코드에 변경이 가해지지 않도록 하는 프로세스가 존재함을 보여줘야 합니다. 이는 의존성을 업데이트할 때마다 두 버전의 차이를 비교해야 하고, 문맥 내에서 줄 단위로 변경을 감사해야 함을 의미합니다. 사내 신규 코드에서 하는 것과 마찬가지로요. 그리고 작은 라이브러리 100개가 있다고 해서 공급자 100개여야 하는 것은 아닙니다 — 예를 들어 Qt는 한 공급자에서 나온 59개의 라이브러리입니다. 그리고 59개의 라이브러리로 나뉘어 있기 때문에, 규제 시스템에 Qt를 끌어오면, Qt 전체를 검토할 필요 없이 사용하는 Qt 라이브러리만 검토하면 됩니다 — 59개가 아니라 아마 2~3개 정도만요.
2025년 9월 19일 0:51 UTC (금) 게시자: mathstuf (구독자, #69389) [링크] (2개의 응답)
또 다른 점은, 더 큰 프로젝트는 비선형적으로 더 큰 소프트웨어 프로세스와 인프라를 요구한다는 것입니다. 집중된 1천 줄짜리 라이브러리를 테스트하는 것은 꽤 사소합니다. 그런 것 10개를 테스트하는 것도 여전히 할 만합니다. 한편, 수백만 줄 프로젝트의 테스트 방식을 알아내는 것은 완전히 별개의 과업입니다. 다음을 전부 한 번에 상대해야 하기 때문입니다:
큰 테스트 슈트
실행 시간이 길다
상호연결된 부분이 많아, 작은 변경이 수많은 테스트에 영향을 줄 수 있다
기여를 완전히 직렬화하지 않으면서 순서를 정하고 싶은 욕구(머지 트레인)
그래서 커버리지 기반 테스트 선택, CI 샤딩, 알림 규칙(CODEOWNERS), 캐시 관리, 머신 조율 등과 같은 것들을 디렉터리 수준에서 갖추게 됩니다. 프로젝트 수준에서 집중되어 있는 포지들보다 훨씬 더 말이죠.
물론, 소프트웨어 프로세스에 무언가를 추가하고 싶다면, 단일 프로젝트 레포에 적용하는 것이 수십 개에 적용하는 것보다 훨씬 쉽습니다. 하지만 저는 소프트웨어 프로세스 업사이클이(모놀리식이든 분리되어 있든, 모노레포든 멀티레포든) 프로젝트가 겪는 전체 변동에서 아주 얇은 영역이라고 생각합니다.
2025년 9월 19일 10:42 UTC (금) 게시자: farnz (구독자, #17727) [링크] (1개의 응답)
당신이 어떻게 인식하는지는 또한 당신이 체인의 어디에 있는지에 달려 있습니다. 다운스트림 소비자로서, 내가 1천만 줄(LOC)의 코드를 심사해야 한다면, 1천만 LOC를 심사해야 합니다. 그 1천만 LOC가 500만 LOC짜리 라이브러리 두 개에 있든, 1천 LOC짜리 라이브러리 1만 개에 있든, 나에게 특별히 도움이 되지 않습니다. 어쨌든 전부 심사하고, 내 기준(무엇이든 간에)에 맞게 전부 테스트되었음을 확인해야 합니다.
그러나 업스트림은 당신이 말한 모든 이유로 더 작은 라이브러리로 나누는 것에서 이득을 봅니다. 한 번에 전체 1천만 LOC에 영향을 미치는 단일 변경을 하는 사람은 드뭅니다. 따라서 더 작은 라이브러리에 있는 모든 이점을 얻고 싶어합니다.
Qt는 여기에 아주 좋은 예입니다. 바로 당신이 지적한 고통 때문에 많은 작은, 독립적인 조각으로 분리되어 있습니다. 그 말은 또한 내가 어떤 프로젝트에서 Qt를 사용한다면, "하나의 라이브러리"를 심사하는 게 아니라, 내가 사용하는 Qt의 N개 부분집합을 심사한다는 뜻이기도 합니다.
더 큰 과제는 그룹 간 감사 공유입니다. cargo vet과 crev 같은 것들이 기술적 측면에서는 도움이 되지만, 사회적 측면은 훨씬 더 풀기 어려운 견과입니다.
2025년 9월 19일 11:17 UTC (금) 게시자: smurf (구독자, #17840) [링크]
Qt는 여기에 아주 좋은 예입니다. 바로 당신이 지적한 고통 때문에 많은 작은, 독립적인 조각으로 분리되어 있습니다.
어떤 의미의 "독립적"이냐에 달려 있겠죠.
원하는 조각만 잡아올 수는 있습니다(한계 내에서). 하지만 새로운 기능이 필요한 조각만 업데이트하고, 나머지는 10년 전의 영광에 남겨두는 것은(그때 심사했으니, 안 망가졌다면 …) 통하지 않을 겁니다. (극단적 예로 libboost를 생각해 보세요.)
물론, 의존성 지옥은 Qt나 Boost만의 문제가 아닙니다… 하지만 진정으로 독립적인 라이브러리는 보통 자신들의 의존성 버전 요구를 더 명시적으로 밝힙니다. "2025-09 당시 최신의 libfoo 버전을 가져와"라는 다소 암시적인 표현보다는요.
2025년 9월 17일 14:04 UTC (수) 게시자: nim-nim (구독자, #34454) [링크]
그 말은 곧 조직들이 새로운 소프트웨어 투자 가치를 평가할 때, 오래된 C++ 코드베이스에 재투자할 가능성이 낮아진다는 뜻입니다.
"더 안전한" C++ 프로파일/파생물을 만드는 모든 요점은 CEO들에게 C++ 구덩이에 더 많은 돈을 붓도록 설득하는 것입니다. 제안은 새로운 부분을 "안전한" 파생물로 작성할 것이라 말하고, 자금 제공자는 언젠가는 전체가 안전해질 것이라고 강하게 믿게 됩니다(언젠가는, 돼지가 날게 될 때쯤이겠지만, 자기 자리를 지키고 싶은 사람은 공개적으로 그렇게 말하지 않겠죠).
2025년 9월 17일 9:53 UTC (수) 게시자: farnz (구독자, #17727) [링크] (7개의 응답)
그런데 C++를 어떻게 폐기하죠? 회사 내부라면, 같은 품질의 일을 다른 언어에서도 하거나 더 잘할 수 있는 충분한 엔지니어를 확보할 수만 있다면 관리 가능합니다 — "새로운 C++는 금지, 어기면 해고"를 명령하고 끝입니다.
하지만 회사 밖에서는 그럴 수 없습니다 — 제가 개인적으로 C++로 코드를 작성하는 것을 어떻게 막을 수 있나요? 다른 사람들과 C++ 코드를 공유하는 것을 어떻게 막을 수 있죠? 다른 사람들이 제 C++ 코드를 보고 재사용하는 것을 어떻게 막나요?
안전이 사람들에게 중요한 것으로 드러난다면, 저는 C++가 포트란의 길을 갈 것이라고 예상합니다. 완전히 사라지지는 않겠지만, 몇몇 틈새를 제외하고는 덜 쓰이게 될 것입니다.
2025년 9월 17일 10:11 UTC (수) 게시자: Wol (구독자, #4433) [링크] (2개의 응답)
그런데 C++를 어떻게 폐기하죠?
기업과 정부가 금지하기 시작하면, 대학교는 가르치는 것을 멈출 것입니다.
이력서에 C++가 크게 보이면 플러스가 아니라 마이너스가 된다면, 학생들은 그것을 배우지 않겠죠.
그 일이 일어나면, 프로그래머들은 직장에서 주 언어로 쓰지 않기 때문에 개인적으로 C++를 쓰는 것도 멈출 겁니다.
그리고 C++는 코볼과 포트란 같은 레거시 언어 대열에 합류할 겁니다. 유지보수 프로그래머가(바랄 뿐이지만) 큰돈을 받고 오래된 코드를 계속 돌리겠죠.
감사합니다,
Wol
2025년 9월 18일 14:10 UTC (목) 게시자: LtWorf (구독자, #124958) [링크] (1개의 응답)
그럼 Qt를 대체할 좋은 것이 있나요? 그게 없으면 그런 일은 일어나지 않을 거라 봅니다.
그리고 Qt는 수많은 예 중 하나일 뿐입니다.
2025년 9월 18일 14:55 UTC (목) 게시자: smurf (구독자, #17840) [링크]
https://blog.logrocket.com/state-rust-gui-libraries/에는 GUI 라이브러리가 11개 나열되어 있습니다… 아마 그중 하나가 당신의 특정 사용 사례에 맞을 겁니다.
솔직히, Qt는 난해하고 디버그하기 매우 어려운 혼돈입니다(GTK도 마찬가지). 증거: 거의 어떤 비사소한 프로그램이든 콘솔에서 시작해서 경고가 쏟아지는 것을 보세요.
그렇긴 해도, Rust/Qt 바인딩은 존재합니다. 잘 작성되었다면, GUI 코드를 안전하게 만드는 데 꽤 도움이 될 수 있습니다. 코드 100%를 한 번에 교체할 필요는 없어요. 1%씩 100번이면 똑같이 효과가 있습니다.
2025년 9월 17일 10:45 UTC (수) 게시자: excors (구독자, #95769) [링크] (3개의 응답)
폐기(deprecate)는 금지(ban)를 의미하지 않습니다. "우리는 이걸 사용하지 말라고 생각하며, 앞으로는 이것을 지원하는 데 노력을 덜 들일 가능성이 높다"고 말하는 것입니다.
누구나 그렇게 말할 수 있고, 당신은 언제든지 무시할 자유가 있습니다. 중요한 것은 그 말을 하는 사람이 신뢰받는 전문가이거나/이거나 당신에게 어떤 영향력을 가질 때뿐입니다. (그들이 전문가라면, 당신은 그들이 그 기능을 사용하지 말라고 말하는 좋은 이유가 있다고 가정할 수 있으며, 당신 스스로 전체 논리를 따라가 같은 결론에 이르는 데 시간을 낭비하지 않아도 됩니다. 그들이 영향력을 가진다면, 예를 들어 새로운 컴파일러가 당신의 오래된 소프트웨어와 호환될지 여부에 영향을 미칠 수 있다면, 그들의 논리는 중요하지 않습니다. 미래의 호환성 고통을 피하기 위해 지금 그들의 조언을 따르는 것을 고려해야 합니다. 하지만 여전히 무시하고 그 결과를 받아들일 자유는 있습니다.)
표준 기구는 전문성과 영향력을 모두 가지고 있으므로, 그들이 무언가를 폐기한다고 말할 때는 중요합니다. 하지만 커뮤니티 합의나 기업 정책, 개인 개발자 등에 의해서도 무언가가 폐기될 수 있습니다. 누구든 "우리는 C++를 사용하지 말아야 한다고 생각하며, C++에 대한 명세/도구/문서 작성을 멈추고, 우리의 애플리케이션에서 C++ 라이브러리 사용을 중단하고, C++ 프로젝트에 기여하는 것을 중단하겠다"고 말할 수 있으며, 모두가 동의하지 않아도 상관없습니다 — 모두가 C++에서 서서히 벗어나는 데 기여합니다.
2025년 9월 17일 12:41 UTC (수) 게시자: farnz (구독자, #17727) [링크] (2개의 응답)
하지만 전 세계적으로 C++를 폐기하려면, 전 세계의 신뢰받는 전문가 대부분이 C++가 폐기되었다고 말해야 한다는 뜻입니다. 저는 가까운 미래에 그런 길이 보이지 않습니다. C++를 의미 있게 폐기시키는 데 필요한 사람들이 현재 C++를 지지하고 있기 때문입니다.
장기적으로는 EU의 사이버 회복력 법(Cyber Resilience Act) 같은 것들이 이런 일반적인 방향으로 밀어붙일 것입니다. 상업적 주체들이 보안을 외부효과로 취급하는 것을 멈추게 만들기 때문입니다. 하지만 그건 매우 느린 과정입니다.
2025년 9월 17일 16:26 UTC (수) 게시자: smurf (구독자, #17840) [링크] (1개의 응답)
전 세계적으로 C++를 폐기하려면, 전 세계의 신뢰받는 전문가 대부분이 C++가 폐기되었다고 말해야 한다는 뜻입니다
그럴 필요는 없습니다. 인증된(그래서 비싼) 출입 통제 시스템의 표준을 인증하는 표준 조직을 관할하는 정부 기관이 "C++는 폐기되었다"고 말하면, 이는 곧 갱신 시 추가 정당화/심사를 요구한다는 것으로 직결됩니다. C++ 전문가들이 아무리 많아도 말입니다.
2025년 9월 17일 16:38 UTC (수) 게시자: farnz (구독자, #17727) [링크]
제가 아는 대부분의 표준은 사용 언어에 관심이 없습니다 — 그 결과 C++를 폐기하는 일은 없을 겁니다. 대신 "자격을 갖춘(qualified) 컴파일러"라는 개념이 있고, 컴파일러가 자격을 갖추었고 그 자격의 주의사항을 충족한다면, 바이너리 수준이 아니라 소스 수준에서 인증을 받을 수 있습니다. 페로신(Ferrocene)은 자격을 갖춘 컴파일러의 예입니다. 프로젝트 문서를 사용해 이 컴파일러의 자격 요건을 충족하는지 판단할 것입니다. 이 경우 안전 매뉴얼의 제약에서 페로신의 주의사항이 무엇인지 알려줍니다.
C++ 컴파일러의 자격 주의사항이 점차 더 엄격해지는 것을 보게 될 수도 있고, 이는 당신이 C++를 폐기하게 만드는 영향을 줄 수 있습니다(특히 그것들이 더 넓은 C++ 커뮤니티의 "관습과 관행"과 충돌하기 시작한다면). 하지만 인증이 이끄는 최대치는 그 정도일 것입니다.
2025년 9월 17일 6:50 UTC (수) 게시자: Wol (구독자, #4433) [링크] (1개의 응답)
음...
그렇다면 약한(weak) 프로파일과 강한(strong) 프로파일 — 가급적 어떤 모듈에 어떤 것이 적용되는지 지정하는 프라그마와 함께 — 을 두는 게 어떨까요?
약한 프라그마는 단지 그 모듈을 검사하고, "이 코드는 멍청한 짓을 하지 않는다. 다만 호출하는 것들까지는 보증하지 않는다"고 말합니다. 강한 프라그마는 Java의 체크 예외처럼 — "이 코드는 멍청한 짓을 하지 않고, 호출하는 루틴도 그렇다"고 하겠죠.
오래 걸리겠지만, 그러면 곳곳에서 정책으로, 코드를 수정할 때마다 약한 프라그마를 적용하고, 그걸 통과시키고, 강한 프라그마도 통과하는지 확인하도록 할 수 있습니다. 즉, 한 모듈씩 조금씩 앞으로 밀어붙이는 셈이죠?
감사합니다,
Wol
2025년 9월 18일 1:55 UTC (목) 게시자: mathstuf (구독자, #69389) [링크]
즉, 한 모듈씩 조금씩 앞으로 밀어붙이는 셈이죠?
우선, 이게 적용 가능하려면 모듈로의 마이그레이션이 선행되어야 합니다.
2025년 9월 17일 9:41 UTC (수) 게시자: farnz (구독자, #17727) [링크]
이미 거부된 해결책이 하나 있습니다. 불행히도, 이는 "레거시 코드 호출을 가능하게 하는 주석을 추가"하는 기능도 하기 때문입니다. 특수한 종류의 블록이 아이템을 감싸며, 그 블록 내부의 모든 것(포함하여 import된 모듈)은 체크 및 안전하지 않더라도, 사용 시점에서의 주석 없이도 안전한 코드에서 사용할 수 있게 합니다. 이 블록은 내부의 모든 것을 포함하기 때문에 #include로 가져온 모든 것을 포함합니다. 그리고 특별한 마커가 있는 특수 블록이기 때문에, 이런 블록 사용에 대해 시니어 개발자 검토를 요구하는 도구를 작성하는 것이 가능합니다.
2025년 9월 17일 8:24 UTC (수) 게시자: danielthompson (구독자, #97243) [링크] (1개의 응답)
분명 C++ 쪽에서는 메모리-안전 함수가 오직 다른 메모리-안전 함수만 호출하도록 제한하는 것을 원치 않는 듯합니다. 그런데 그건 러스트의 절대적인 기본 원칙이죠.
흥미롭게도 러스트는 2024 에디션에서 여기서 한 발 더 나아갔습니다: 이제 unsafe 함수가 본문에서 unsafe를 사용해야 한다고 가정하지 않습니다. 현재로서는 기본 활성화된 경고일 뿐이지만, unsafe 함수 내부에서도 도구들은 이제 슈퍼파워에 접근하기 전에 unsafe 키워드 사용을 강하게 권장합니다.
https://doc.rust-lang.org/nightly/rustc/lints/listing/all...
2025년 9월 17일 22:55 UTC (수) 게시자: NYKevin (구독자, #129325) [링크]
이는 처음부터 unsafe 함수가 본문에서 unsafe한 일을 하는 것을 허용하는 것이 큰 의미가 없었기 때문입니다. unsafe 키워드는 두 가지 전혀 다른 의미를 갖습니다:
함수 시그니처의 지정자로서, API의 일부이며, 함수가 컴파일러에 의해 강제되지 않는 비자명한 안전 전제 조건을 가진다는 것을 알립니다. 관례적으로 이러한 전제 조건은 함수의 문서 주석의 "Safety" 헤더 아래에 나열됩니다.
코드 블록으로서, 그 블록 내부의 하나 이상의 연산이 강제되지 않는 안전 전제 조건을 가지며, 개발자가 그 전제 조건을 수동으로 준수하겠다는 인식을 나타냅니다. 관례적으로, 그 블록에는 해당 시점의 전제 조건이 왜 성립하는지 설명하는 SAFETY 주석이 달립니다.
컴파일러는 프로그래머가 특정 unsafe 블록으로 지키겠다고 약속하는 전제 조건이 무엇인지, 혹은 특정 unsafe 함수나 기타 unsafe 연산*이 요구할 수 있는 정확한 전제 조건이 무엇인지 알지 못하기 때문에, 둘을 서로 대조할 방법이 없습니다. 그래서 프로그래머가 고의로 모든 unsafe 블록을 가능한 한 작게 만드는 일은 드물지 않습니다. 오직 하나의 연산만 unsafe로 감싸면, 그 하나의 연산의 전제 조건만 신경 쓰면 되고, 안전하다고 잘못 믿었던 구성요소에 대해 무관한 약속을 실수로 하지 않게 됩니다. 다행히 러스트는 unsafe 블록(그리고 블록 전반)을 표현식으로 취급합니다. 따라서 허용하려는 unsafe 연산만 정확히 특정하고, 나머지 표현식은 안전한 코드로 남겨둘 수 있습니다.
unsafe 함수가 본문에서 별도의 unsafe 블록 없이 unsafe한 일을 하는 것을 허용함으로써, 오래된 러스트 에디션은 이 두 의미를 부적절하게 혼합했습니다. 더 중요한 것은, unsafe 블록에 포함되는 코드의 양을 최소화하기 훨씬 더 어렵게 만들었다는 점입니다.
2025년 9월 16일 20:15 UTC (화) 게시자: warrax (구독자, #103205) [링크]
제 생각에 그들은 항상 그것을 그렇게만(그 이상도 이하도 아닌) 마케팅해 왔습니다.
2025년 9월 17일 1:58 UTC (수) 게시자: hmanning77 (구독자, #160992) [링크] (4개의 응답)
Carbon이 어떻게 전개될지 정말 궁금합니다. 발표에서 언급했듯이, C++는 이미 C 코드에 대해 유사한 진화 경로를 제공하지만, 실제로는 그렇게 잘 되지 않았습니다. 때로는 사람들이 C API를 std::unique_ptr와 std::vector로 감싸는 데 시간을 들이지만, 똑같이 자주 C 타입과 함수 사용이 C++ 코드로 새어 나오는 경우도 있습니다. 이론적으로는 더 나은 기준을 강제하자고 말할 수 있습니다. 실제로는 사람들은 해야 할 일이 많고, 시간은 적습니다. 아마도 Carbon은 "이걸 작동시키기 위해 C++를 조금만" 쓰고 싶은 유혹을 억제할 방법을 찾을까요?
2025년 9월 18일 7:16 UTC (목) 게시자: taladar (구독자, #68407) [링크] (2개의 응답)
개인적으로 "C++는 C의 후속작"이라는 말은 언제나 마케팅일 뿐이었고, 실제로 그렇게 취급된 적은 없다고 생각합니다. 본질적으로 실패한 마케팅이죠.
2025년 9월 18일 14:56 UTC (목) 게시자: smurf (구독자, #17840) [링크] (1개의 응답)
음, 한때 "cfront"라는 것이 있었죠. C++를 C로 변환하는…
2025년 9월 18일 18:38 UTC (목) 게시자: ejr (구독자, #51652) [링크]
그리고 템플릿 인스턴스화 방식과 ODR(One Definition Rule)을 둘러싼 전쟁이 이어졌죠...
2025년 9월 22일 23:19 UTC (월) 게시자: marcH (구독자, #57642) [링크]
이론적으로는 더 나은 기준을 강제하자고 말할 수 있습니다. 실제로는 사람들은 해야 할 일이 많고, 시간은 적습니다. 아마도 Carbon은 "이걸 작동시키기 위해 C++를 조금만" 쓰고 싶은 유혹을 억제할 방법을 찾을까요?
네, 결국 핵심은 강제입니다. 가장 "쉬운" 방법 중 하나는 보너스를 그 "조금의 C++" 비율에 연동하는 겁니다. 또 그 비율이 목표 임계치 아래로 떨어질 때까지 릴리스를 막을 수도 있습니다 — 다른 품질 지표와 정확히 똑같이요. 또한 그 비율에 더 많은 필수 검토, 테스트 커버리지, 프로세스 오버헤드 등을 부과할 수도 있습니다 — 그 "조금의 C++"로 사는 삶을 고통스럽게 만드는 거죠.
방법은 많습니다 — 상상력을 발휘하세요. 하지만 그 모두는 강력한, 위에서 아래로의 경영진 드라이브를 요구합니다. 그 드라이브는 기술력이 충분한 일부 회사에는 존재합니다. 그 안전 드라이브는 Carbon을 성공하게 만들기에 충분할 수도 있습니다 — 바로 그것이 러스트를 성공으로 이끈 방식처럼요.
그 발표자는 참고로 어디에 고용되어 있죠? :-)
2025년 9월 17일 15:31 UTC (수) 게시자: Karellen (구독자, #67644) [링크] (1개의 응답)
Herb Sutter의 cpp2 대체 C++ 문법/언어에서 영감이나 아이디어를 가져온 게 있는지 궁금합니다.
어느 정도는 비슷한 개념적 공간에서 작업하는 것처럼 보입니다.
2025년 9월 17일 21:58 UTC (수) 게시자: ajb (구독자, #9694) [링크]
그 말은 몇 년 전 Ben Werther와 Damian Conway의 유사한 제안을 떠올리게 하네요: https://dl.acm.org/doi/pdf/10.1145/240964.240981
글쎄요, 둘 다 C++에 대한 새로운 문법 바인딩이라는 점에서는 비슷합니다. 실제 문법이 닮았는지는 잘 모르겠네요.
2025년 9월 25일 21:04 UTC (목) 게시자: simlo (손님, #10866) [링크]
다른 언어로 직접 호출하지 말고, 시스템을 여러 프로세스로 구축하세요. 각 프로세스는 선택한 언어로 작성할 수 있습니다. protobuf 같은 것을 사용하면 모든 언어에서 통신의 일부를 구현하지 않아도 되도록 도와줄 수 있지만, 시스템 전체 상태의 일부는 다양한 언어에 복제되어야 하므로, 그런 시스템에 새 언어를 추가하는 비용이 0이 되지는 않을 것입니다.
거대한 모놀리식 프로그램은 그 자체로 나쁜 아이디어입니다 — 특히 메모리 비안전 언어에서는요. 그러니 모든 C++ 코드를 더 작은 프로그램들로 분할하고, 새로운 것들은 러스트 — 혹은 파이썬이나 … — 로 추가하는 것이 합리적인 접근일 수 있습니다.
Copyright © 2025, Eklektix, Inc.
이 기사는 Creative Commons CC BY-SA 4.0 라이선스 조건에 따라 재배포할 수 있습니다
댓글과 공개 게시물의 저작권은 작성자에게 있습니다.
Linux는 Linus Torvalds의 등록 상표입니다