C++는 왜 두 진영으로 갈라졌나: 툴링이 만든 균열

C++의 미래를 둘러싼 논쟁이 어느 때보다 거세다. 레딧이나 해커뉴스 같은 커뮤니티는 물론이고, 표준을 결정하는 위원회(WG21) 회의장에서도 갈등의 흔적을 어렵지 않게 찾을 수 있다. 겉으로만 보면 언어가 분열하고 있고, 밀려드는 압력을 표준위원회가 감당하지 못한다는 불신이 퍼지는 것처럼 보인다. 실제로 상당수 사용자들이 대안을 찾아 나서고 있다.

대표적인 사례가 구글이다. 구글은 세계에서 가장 큰 C++ 코드베이스 중 하나를 보유했고, 그동안 이 언어로부터 엄청난 효용을 얻어왔다. 그럼에도 이른바 ABI 투표를 기점으로 '표준화 프로세스'에 대한 신뢰를 잃었다. 이는 언어 자체에 대한 불신이 아니라, 정부 규제 가능성, 경쟁 언어의 부상, 성능과 안전성에 대한 요구가 동시에 커지는 상황에서 C++가 스스로 진화할 수 있는가에 대한 회의다.

바꿀 수 없는 코드라는 전제

그렇다면 왜 C++는 그냥 바뀌지 못하는가. 답은 의외로 단순하다. 허브 서터(Herb Sutter)는 프로파일 관련 논문에서 이렇게 정리했다. 수십 년의 경험이 일관되게 보여준 사실은, 대규모 코드베이스를 가진 대부분의 고객이 엄격성 규칙을 만족시키기 위해 코드의 1%조차 바꾸지 않으려 하며, 규제가 강제하지 않는 한 안전을 이유로도 그렇게 하지 않는다는 것이다. 놀라운 이야기는 아니다. 기존 코드 변경을 최소화해야 한다는 이 전제가 이후 모든 설계 결정의 출발점이 된다.

흥미로운 대비는 챈들러 카루스(Chandler Carruth)의 위원회 소개글에서 드러난다. 그는 Clang 기반의 자동 리팩터링 도구를 이끌었고, 구글 내부에서 이를 1억 줄이 넘는 전체 C++ 코드베이스로 확장했다고 밝힌다. 전체 코드베이스에 대한 분석과 리팩터링 적용을 20분 안에 해낼 수 있다는 것이다. 핵심은 바로 이 '자동화된 툴링'이다.

진짜 경계선은 언어가 아니라 빌드 능력

여기서 저자는 두 개의 뚜렷하게 다른 C++ 사용자 집단이 존재한다고 본다. 한쪽은 마이그레이션을 비교적 매�끄럽게 처리할 수 있는 집단으로, 버전이 관리되는 소스로부터 전체 스택을 빌드할 수 있는 부류다. 다른 한쪽은 1998년의 사전 빌드된 라이브러리를 여전히 쓰는 부류다. 전체 의존성 스택을 깔끔하고 명확하게, 가능하면 자동화된 테스트와 함께 소스에서 빌드할 수 있는가—이것이 두 진영을 가르는 가장 결정적인 선이다.

주목할 점은 이 차이가 C++ 언어 자체와는 거의 무관하다는 것이다. 구글 코드베이스가 얼마나 '모던 C++' 관용구를 따르는지는 부차적이다. 정작 중요한 건 툴링의 품질과 소스에서 빌드할 수 있는지 여부다. 현실에서는 이것이 이분법이 아니라 연속적인 스펙트럼이지만, 거대 기술 기업들이 자신들의 코드베이스를 빌드 가능하고 린트되며 버전이 관리되는 상태로 끌어올리기까지 얼마나 많은 비용과 노력이 들었을지는 짐작만 할 뿐이다.

툴링은 누구의 책임인가

많은 이들이 툴링은 표준위원회의 책임이 아니라고 말하고, 그 말은 맞다. 위원회는 구체적 구현이 아니라 언어 명세에 집중하며, 툴링에 대한 책임을 의도적으로 내려놓았다. 서로 다른 컴파일러 구현을 통합하는 표준이라는 성격을 감안하면 이해할 만한 선택이기도 하다. 다만 저자는 Go가 제대로 해낸 한 가지가 바로 '툴링이 중요하다'는 인식이었다고 지적한다. 그에 비해 C++는 통합된 빌드 시스템도, 통합에 가까운 패키지 관리 시스템도 없으며, 파싱과 분석이 극도로 어렵고, 변경할 때마다 하이럼의 법칙(Hyrum's Law)과 힘겨운 싸움을 벌인다. 다만 툴링 전담 연구 그룹인 SG15가 존재하긴 한다.

이 균열은 안전성 프로파일(Safety Profiles)과 모듈 같은 최근 기능의 성격도 설명해준다. 프로파일은 기존 코드를 바꾸지 않고도 개선을 얻게 하려는 것이고, 모듈 역시 헤더 파일을 그대로 모듈로 import할 수 있게 하는 방향으로 설계된다. 둘 다 무엇보다 '레거시 C++'를 염두에 둔다. 마이그레이션을 요구하는 기능은 위원회 입장에서 애초에 성립하지 않는다. 저자는 이를 나쁜 결정이라 보지 않는다. 하위 호환성은 많은 이들에게 매우 중요한 가치이기 때문이다.

실무자가 새겨둘 지점

한국의 C++ 실무자에게 이 글이 주는 함의는 분명하다. 어떤 C++ 논문이나 기능 제안을 읽을 때, 그것이 모던 C++ 진영을 위한 것인지 레거시 C++ 진영을 위한 것인지를 먼저 구분해야 한다는 것이다. 두 진영은 서로 다른 문제를 풀고 있으며, 그래서 안전성 프로파일과 션 백스터(Sean Baxter)의 'Safe C++' 제안은 종종 같은 문제를 다루는 것처럼 오해되지만 실제로는 완전히 다른 대상을 겨냥한다. 위원회가 Safe C++ 같은 급진적 변화에 부정적인 이유도 이 균열이 더 벌어지는 것을 막으려는 데 있다.

물론 위원회 일부가 자신의 미학적 취향에 반하는 진화를 막으려 완고하게 버티는 것 아니냐는 시선도 있다. 저자는 단정하지 않으면서도, 완전한 구현과 여러 컴파일러에서의 동작을 요구하면서 정작 모듈이나 프로파일처럼 검증된 구현이 없는 대형 프로젝트에는 관대하다는 이중 잣대 이야기를 들어왔다고 전한다. 여기에 ABI 호환성을 깨는 순간 열릴 문제까지 더해지면, 이 길을 얼마나 더 갈 수 있을지는 미지수다. 결국 이 글이 던지는 메시지는 하나로 수렴한다. 방언 없는 단일 C++이라는 이상은 이미 오래전에 유효성을 잃었고, 남은 것은 툴링과 빌드 능력이라는 축을 따라 갈라진 두 개의 현실이라는 점이다.