무슨 일이냐면요
프로그래밍 언어 중에 이름이 'Ü'인 게 있다고 하면 좀 당황스럽죠? 독일어에서 쓰는 움라우트가 붙은 그 알파벳 맞아요. 발음은 '위' 정도로 하면 되는데요, 한 개발자가 취미 삼아 시작해서 꽤 오랫동안 꾸준히 키워온 컴파일 언어예요. 화려한 회사 뒤에 있는 언어는 아니지만, 들여다보면 "요즘 시스템 언어들이 고민하는 지점을 혼자서 진지하게 풀어보고 있구나" 싶은 그런 프로젝트예요.
여기서 '시스템 언어'가 뭐냐면요, 운영체제나 게임 엔진, 데이터베이스처럼 성능이 정말 중요하고 메모리를 직접 다뤄야 하는 프로그램을 만들 때 쓰는 언어를 말해요. C, C++, Rust가 대표적이죠. 자바스크립트나 파이썬처럼 '알아서 메모리 관리해주는' 편한 언어가 아니라, 내가 직접 챙겨야 하는 대신 그만큼 빠른 언어들이에요.
어떻게 생겼냐면
Ü는 문법만 보면 C++이랑 정말 비슷해요. C++ 써본 사람이면 "어 이거 거의 똑같은데?" 하고 바로 읽을 수 있을 정도예요. 클래스도 있고, 템플릿(제네릭, 즉 타입을 일반화해서 재사용하는 기능)도 있고, 연산자 오버로딩 같은 것도 다 있어요.
그런데 핵심은 안전성이에요. C++의 가장 큰 골칫거리가 뭐냐면, 이미 해제한 메모리를 또 건드린다거나(use-after-free), 배열 범위를 넘어서 접근한다거나 하는 실수가 컴파일 시점엔 안 잡히고 실행 중에 펑 터진다는 거예요. 보안 취약점의 상당수가 여기서 나와요. Ü는 Rust가 했던 것처럼, 참조(reference)가 누구를 가리키고 있고 언제까지 살아있는지를 컴파일러가 추적해서, 위험한 코드를 아예 빌드 단계에서 막아버려요. '빌려쓰기 검사(borrow checking)'와 비슷한 개념을 자기 식대로 구현한 거죠.
또 하나 재밌는 건 컴파일 백엔드로 LLVM을 쓴다는 점이에요. LLVM이 뭐냐면, Rust나 Swift, Clang(C++ 컴파일러)도 다 갖다 쓰는 '컴파일러 공용 엔진' 같은 거예요. 소스코드를 받아서 실제 기계어로 최적화해 뽑아주는 부분을 LLVM이 담당해요. 덕분에 혼자 만든 언어인데도 생성된 코드의 성능은 C++급으로 나올 수 있는 거예요. 바닥부터 다 만들 필요 없이 검증된 엔진 위에 언어 설계만 얹은 거죠.
업계 흐름에서 보면
사실 'C++의 안전한 후계자'를 노리는 시도는 지금 엄청 많아요. Rust가 가장 성공했고, 구글이 미는 Carbon, 헤르프 서터가 주도하는 cppfront(Cpp2) 같은 것도 있어요. 다들 "C++의 성능과 생태계는 살리면서 메모리 안전성을 더하자"는 비슷한 목표를 향해 가고 있거든요. Ü는 이 큰 흐름 안에서 개인 개발자가 만든, 그렇지만 완성도는 무시 못 할 한 갈래라고 보면 돼요.
특히 Rust가 C++ 문법을 거의 버리고 새로 짠 데 비해, Ü는 C++ 개발자가 적응 비용 거의 없이 넘어올 수 있게 친숙한 문법을 유지했다는 점이 차별화 포인트예요. "안전성은 갖고 싶은데 Rust의 낯선 문법은 부담스럽다"는 사람한테는 흥미로운 선택지인 셈이죠.
한국 개발자에게
당장 실무에 Ü를 도입하자는 얘기는 아니에요. 생태계나 라이브러리, 채용 시장을 생각하면 현실적으로 어렵죠. 다만 이런 언어를 들여다보는 건 공부 측면에서 꽤 값져요. '컴파일러가 어떻게 메모리 안전성을 검사하는가'라는 요즘 시스템 프로그래밍의 가장 뜨거운 주제를, 작고 읽기 쉬운 코드베이스로 살펴볼 수 있거든요. 거대한 Rust 컴파일러를 뜯는 것보다 입문하기 좋아요. 언젠가 자기만의 언어나 DSL(특정 목적에 맞춘 작은 언어)을 만들어보고 싶은 분이라면, '한 사람이 LLVM 위에 어디까지 만들 수 있는가'의 좋은 본보기이기도 하고요.
마무리
혼자서도 LLVM을 등에 업으면 'C++스러우면서 안전한 언어'를 진지하게 만들 수 있다는 걸 보여주는 사례예요. 여러분은 메모리 안전성을 위해서라면 익숙한 C++ 문법을 버리고 Rust로 갈 수 있나요, 아니면 Ü처럼 문법은 그대로 두고 안전성만 더한 쪽이 더 끌리나요?
🔗 출처: Hacker News