일 년 전 제안된 Safe C++가 중단되고, 대신 제약 기반의 ‘프로파일’ 접근이 표준화의 우선순위가 된 배경과 관련 문서들을 요약하며 개인적 견해를 정리합니다.
1년 전, Safe C++ 제안이 나왔다. 목표는 기존 C++ 코드를 깨뜨리지 않으면서 Rust가 제공하는 것과 유사한 강한 보장(메모리 안전성, 타입 안전성, 스레드 안전성)을 제공하는 안전한 하위 집합/컨텍스트를 C++에 추가하는 것이었다. 이는 C++의 확장, 즉 상위 집합에 해당한다. 옵트인 방식은 안전 컨텍스트에 속하는 코드 부분을 명시적으로 표시하는 것이었다. 저자들은 이렇게까지 밝혔다:
안전 컨텍스트의 코드는 Rust로 작성된 코드와 동일한 수준의 강력한 안전 보장을 제공합니다.
나머지는 기존 C++의 의미에서 “unsafe” 상태로 남는다. 이는 기존 코드는 계속 동작하고, 새로 작성하거나 리팩터링한 부분은 안전성을 얻을 수 있음을 의미한다. Rust를 작성해 본 이들에게 Safe C++는 Rust와 유사한 점이 많고, C++의 설계에 맞추기 위한 조정이 일부 있다. 또한 C++에는 이미 방대한 “unsafe 코드” 기반이 있기 때문에, Safe C++는 안전과 비안전을 혼합하고 점진적으로 마이그레이션할 수 있는 메커니즘을 제공해야 했다. 그런 의미에서 Safe C++의 모든 안전 기능은 옵트인이다. 기존 코드는 예전처럼 컴파일되고 동작한다. 안전 컨텍스트를 도입해도 이를 사용하지 않는 코드는 깨지지 않는다.
이 제안은 내 관심을 끌었다. C++를 안전하게 만드는 좋은 타협처럼 보였지만, 초안 제안으로서 미해결된 문제들이 있었고 이는 지극히 정상적이다. 예를 들어, borrow checker와 수명(lifetime) 오류에 대한 에러 리포팅을 어떻게 할지, 또는 제네릭 코드와 템플릿이 수명 로직과 안전/비안전 한정자와 어떻게 상호작용할지 등이 있다. 이는 일부 예시에 불과하며, 제안서는 매우 길고 정교하다. 게다가 나는 프로그래밍 언어 설계자가 아니므로 더 나은 대안이 있을 수도 있다.
어쨌든 오늘 그 제안이 더 이상 추진되지 않는다는 것을 알게 됐다. 오늘 아침 제안을 다시 떠올리면서 한동안 업데이트를 보지 못했다는 걸 깨달았기 때문이다. 그래서 찾아보았고 Reddit에서 몇 가지 답변을 발견했다.
Safe C++ 제안의 원저자 중 한 명인 Sean Baxter의 답변:
Safety and Security 작업 그룹은 Safe C++보다 Profiles를 우선시하기로 표결했습니다. 업데이트는 Profiles 담당자들에게 문의하세요. Safe C++는 더 이상 진행하지 않습니다.
그리고 다시:
Rust의 안전성 모델은 위원회에서 인기가 없습니다. 내가 더 일을 해도 그 사실은 바뀌지 않습니다. Profiles가 논쟁에서 이겼습니다. 개발자들이 혜택을 볼 수 있도록 use-after-free 버그, 데이터 레이스, 데드락, 리소스 누수를 제거하기 위한 Profiles의 언어를 표준에 넣는 데 모든 노력을 기울여야 합니다.
그래서 프로파일(Profiles) 관련 문서[1][2][3][4]를 읽어보았다. 내가 이해한 바를 요약해 보면: 프로파일은 특정 안전 속성을 보장하기 위해 언어와 라이브러리 사용 방식에 제약을 가하는 C++의 모드를 정의하려는 것이다. 이들은 주로 컴파일 타임 제약이지만, 실무적으로는 일부 검사가 제한적인 런타임 오버헤드를 추가하는 라이브러리 설비로 구현될 수도 있다. 완전히 새로운 언어 구문을 도입하는 대신, 프로파일은 주로 기존 기능과 사용법을 제한한다. 발상은 간단하다. 프로파일을 활성화하면, 그 프로파일을 사용하는 코드는 해당 제약을 준수하겠다고 동의하는 것이다. 활성화하지 않으면 이전과 동일하게 동작한다. 따라서 역호환적이다.
프로파일은 덜 급진적이고 더 채택하기 쉬운, 기본적으로 더 안전한 C++처럼 보인다. Rust 모델을 강제로 도입하기보다 C++의 가장 흔한 함정을 해결하는 데 초점을 맞춘다. 나는 Safe C++가 더 야심찼다고 본다. 새로운 구문, 타입 한정자, 안전 대 비안전 컨텍스트 등을 도입하자고 했기 때문이다. 위원회의 일부는 그것이 너무 무겁다고 느꼈고, 프로파일은 더 실용적인 경로로 여겨진다. 주된 반론은 명확하다. 프로파일은 Safe C++가 제공하려 했던 것보다 제약이 약할 수 있다.
여기저기서 달린 댓글을 읽어 보면, 커뮤니티에는 Rust 모델 채택에 대한 눈에 띄는 저항이 있다. 한편으로는 이해가 간다. Rust처럼 쓰고 싶다면 Rust를 쓰면 된다. 역사적으로 C++는 다른 세계의 기능을 끌어와 스스로에 통합해 왔다. 이 경우, C++의 안전 하위 집합은 이미 비공식적으로 어느 정도 존재한다고 본다. 프로파일은 이미 실무에서 존재하는 것을 표준화하고 통일하려는 시도다. 기술적으로 근본적인 새로운 의미론을 추가하지 않는다. 대신 제약, 의무, 그리고 보장을 제공한다.
내 생각에, 위원회와 전체 C++ 커뮤니티의 선호를 고려할 때, Safe C++ 제안을 높이 평가했고 구체적인 성과를 기대하긴 했지만, C++의 맥락을 감안하면 제안된 대로 프로파일을 표준화하여 통합하는 편이 훨씬 더 현실적이라고 본다. 프로파일이 완벽하진 않겠지만 없는 것보단 낫다. 집행의 균등성이 떨어질 수 있고 원칙적으로 Safe C++보다 약할 수도 있다. 만능의 보장을 주지는 못하겠지만, 앞으로 나아갈 수 있는 현실적인 경로다.
[2] C++ 프로파일: 프레임워크
[3] 프로파일이란 무엇인가?
Hacker News와 Reddit에서 대화에 참여하세요.
