Zig, Odin, Jai, Rust, Nim, Carbon처럼 'C 또는 C++를 대신하겠다'고 표방하는 시스템 언어가 근래 부쩍 늘었다. C3라는 언어를 직접 만들고 있는 한 개발자는 자신이 그 대열에 서 있으면서도, '과연 C를 갈아치우는 것이 가능한가'라는 질문을 스스로에게 던진다. 그가 내놓은 답은 상당히 냉정하다. 새 언어가 아무리 매력적으로 보여도 결국 실패할 가능성이 크다는 것이다. 이 글은 그 비관론의 근거를 조목조목 정리한 것으로, 신기술 도입을 검토하는 실무자에게는 오히려 유용한 체크리스트가 된다.
언어가 아니라 생태계를 상대해야 한다
핵심 논지는 C의 진짜 힘이 문법이 아니라 그 주위에 쌓인 도구와 관성에 있다는 데 있다. 정적 분석기, 메모리 누수·데이터 레이스 탐지기 같은 도구는 수많은 사람이 C를 대상으로 오랫동안 만들어 왔다. 잘 알려지지 않은 특수 플랫폼을 지원해야 한다면, 그 플랫폼은 십중팔구 사용자가 C를 쓴다고 전제한다. C가 오늘날 컴퓨팅의 공용어이기 때문에 도구를 만들 가치가 생기고, 그렇게 만들어진 도구가 다시 C의 지위를 굳힌다는 자기강화 구조다. 이미 돌아가는 툴체인을 가진 조직이 굳이 언어를 바꿀 이유를 찾기란 어렵다. 새 툴체인을 구축하는 비용을 정당화하려면 '조금 더 나은' 수준이 아니라 압도적인 생산성 이득이 필요하다.
성숙하지 않은 언어에는 다른 위험도 따라붙는다. 초창기 언어는 버그가 많고 의미론이 크게 바뀔 수 있으며, '컴파일 속도가 빠르다'거나 'C보다 빠르다'는 홍보 문구가 기능이 다 채워진 뒤에도 지켜질지 불확실하다. 오픈소스라 포크할 수 있다고는 하지만, 언젠가 자신이 직접 유지보수해야 할지도 모르는 언어를 도입하려는 기업은 많지 않다. 여기에 숙련 개발자 풀이 작다는 채용 문제가 겹친다. C 개발자는 뽑는 법을 알지만 신생 언어 개발자는 어떻게 구해야 할지조차 막막하다는 것이다.
'더 나은 문법'은 장점이 아니다
저자가 특히 경계하는 것은 언어 설계자들이 자기 언어의 이점을 과대평가하는 경향이다. 그는 흔히 내세우는 강점들을 '가짜 장점'이라 부른다. C보다 나은 문법은 대체로 주관적이며, 오히려 문법이 다르다는 사실 자체가 큰 단점이다. 기존 C 코드를 그대로 가져다 쓸 수 없고 한 줄 한 줄 다시 써야 할 수도 있기 때문이다. 성능도 마찬가지다. C는 사실상 아무런 검사를 하지 않기에, 경쟁 언어가 넣은 안전성 검사는 런타임 비용으로 돌아온다. 결국 '안전 모드'에서만 검사를 켜고 '고속 모드'는 C만큼 위험해지는 타협에 이른다. 다만 foreach로 경계 검사를 자동화하거나 '포인터+길이'나 널 종료 배열 대신 슬라이스를 쓰는 것처럼, 구조적으로 더 안전해지는 예외는 존재한다고 인정한다.
'생산성이 높아진다'는 흔한 주장에도 저자는 회의적이다. 비즈니스에서 시간이 가장 많이 드는 일은 코드를 짜는 것이 아니라 해야 할 일이 무엇인지 규정하는 과정이기 때문이다. 그래서 10~20% 생산성 향상은 체감조차 되지 않고, 100% 향상조차 확실한 효과를 담보하지 못한다. 기업에 실제로 중요한 것은 단 하나, 단점을 감수하고서라도 그 언어가 수익에 기여하는가이다.
결국은 '킬러 피처'와 상호운용성
그렇다면 무엇이 언어를 살리는가. 저자는 C가 흉내 낼 수 없는 고유한 셀링 포인트, 즉 킬러 피처를 든다. 자바가 등장했을 때 경쟁 언어들이 주지 못한 여러 강점을 한꺼번에 제시했던 것처럼 말이다. 더 강력한 경로는 특정 무언가를 쓰기 위해 그 언어를 반드시 배워야만 하는 독점적 상황이다. 브라우저 스크립팅의 자바스크립트, 초기 맥·iOS 앱의 오브젝티브C, 플러터의 다트가 그런 사례이며, 루비와 파이썬처럼 인기 프레임워크가 언어를 끌어올린 경우도 있다. 예시로 든 언어 중 게임 엔진을 함께 묶는 Jai의 전략은 이 관점에서 합리적으로 평가된다. 엔진이 충분히 좋다면 사람들이 언어까지 배우게 되기 때문이다.
상호운용성도 결정적이다. C 코드를 손쉽게 호출하거나 C에서 호출될 수 없는 언어라면, 외부 코드와 접점을 만드는 거의 모든 작업에 추가 비용이 발생한다. 저자는 자바가 가졌던 강점 중 하나로 패키지 매니저에 의존하지 않고도 바이너리 라이브러리를 매끄럽게 쓰는 이른바 '라이브러리 사용성'을 꼽으며, 이에 필적하는 언어를 아직 보지 못했다고 덧붙인다.
마지막으로 저자는 'C를 고치자'는 발상 자체의 함정을 짚는다. C89·C99와 100% 호환되면서 코드베이스만 깔끔하게 다시 쓰면 되지 않느냐는 제안에 대해, 그렇게 하는 순간 그것은 더 이상 C가 아니라고 잘라 말한다. 흥미로운 대목은 'C를 대체한다'와 'C의 대안이 된다'를 구분하는 부분이다. Odin을 만든 진저 빌은 자신이 C를 대체하려는 것이 아니라고 명시적으로 밝힌 바 있는데, 이는 신생 언어가 반드시 왕좌를 노릴 필요는 없다는 현실적 태도를 보여준다. 열정과 인기는 도움이 되지만 검증된 가치를 대신하지는 못하며, 언어의 성패는 오직 C가 쓰이는 상당수 영역에서 개발자에게 더 큰 실질 가치를 만들어낼 수 있느냐에 달려 있다는 것이 그의 결론이다.