V 프로그래밍 언어

Park Joon-Kyu
Oct 23 · 9 min read

알 만한 사람들은 이미 알지만 국내 커뮤니티에서 갑자기 전도유망한 미래의 프로그래밍 언어처럼 소개되고 있길래 써 보는 글.

이미 몇 달 전 HN, 레딧에서 잠깐 화제가 됐다가 얼마 전부터 한국 커뮤니티에서 갑자기 이름이 오르내리고 있는 V라는 프로그래밍 언어가 있다. 아직 개발 초기 단계고 12월까지 정식 버전을 릴리스하는 것이 목표라고 한다.

홈페이지에서 V 언어에서 주장하는 특징들을 살펴보자.

  • 안전성 (Null 없음, 전역변수 없음, 바운드 체킹, 변수와 구조체는 기본적으로 immutable, …)
  • 쓰레기 수집참조 카운팅 없이 컴파일 타임에 메모리 안전성을 보장
  • C만큼 빠르며 추가 오버헤드 없는 C 연동을 지원
  • 1초당 120만 줄의 코드를 컴파일 가능
  • 작고 가벼운 컴파일러: 컴파일러를 컴파일하는데 1MB의 용량만 필요하며 0.15 ~ 0.5초 사이에 컴파일이 됨
  • C/C++ 코드를 V로 변환 가능. DOOM 소스 코드를 V로 변환하면 0.7초 내에 컴파일이 가능.
  • 핫 코드 리로딩
  • 크로스 컴파일 지원
  • 패키지 매니저 (vpm)
  • REPL
  • 스크립트 기능
  • 3D 그래픽스 라이브러리 내장
  • 크로스플랫폼 GUI 라이브러리 내장
  • 웹 프레임워크 내장
  • ORM 내장

그야말로 “Too good to be true” 들의 향연이다. 작고 빠르고 가벼운데다 쉬우면서 안전하고 강력하기까지 하다. 만약 이 목록에 나온 대로만 만들어진다면 세상의 모든 프로그래밍 언어를 집어삼키기 충분할 것이다. 게다가 이 모든 것을 단 혼자서 만들고 있다니.

이 언어의 제작자는 휘황찬란한 기능들의 목록으로 사람들의 이목을 집중시켰고 Patreon으로 기부도 받기 시작했다. 이 언어의 실현 가능성에 의문을 가지고 소스 코드가 없는 등 여러 정황들로 이 언어가 사기라고 주장하는 사람들이 나타나기 시작했다. 제작자가 이들과 벌인 논쟁은 HN에서 확인할 수 있다.

6월 22일 실제 동작하는 바이너리와 함께 GitHub에 소스 코드가 공개되었다. V는 활발히 개발 중이며 동작하는 결과물이 있다는 것을 증명하였으나 구현체의 실체를 들여다 볼 수 있는 기회 또한 제공했다. 릴리스된 컴파일러의 소스 코드를 통해 확인할 수 있는 사실은, V의 현재 구현은 알파 수준도 못 되며 광고하는 기능의 상당수가 구현되지 않았다는 것이다. 공개 시점에서 밝혀진 언어의 상태는 아래와 같다. 정식으로 릴리스되지 않은 알파 버전이라는 점을 감안하자.

  • V 컴파일러는 lexer와 parser 정도만 구현되어 있고, 실제로는 기계어를 생성하지 않으며 V 코드를 C 코드로 변환해주는 트랜스파일러이다. V 컴파일러는 gcc, clang, msvc 등 다른 C 컴파일러를 호출해서 변환된 C 코드를 기계어로 번역한다. 홈페이지에서 주장하는 zero dependency는 틀렸다.
  • V 컴파일을 실행하면 V가 몰래 /var/tmp아래에 tcc라는 디렉토리를 만들고 Tiny C Compiler를 설치한다. 실제 머신 코드 생성은 이 TCC가 담당한다. 그렇다. 현재 V가 자랑하는 빠른 속도는 대부분 TCC 덕이다. 게다가 TCC는 디버그 빌드용이다. 릴리스용 빌드는 clang 또는 gcc를 써야 한다.
  • 그렇다면 정말 컴파일러가 1초에 120만 줄의 코드를 컴파일할 수 있을까? 이 글에 따르면 아닌 것 같다. 120만줄 짜리 코드를 생성해서 컴파일을 시켜 보았는데, 50003번째 줄을 읽자 컴파일러가 뻗어버렸고 컴파일러가 50003번째 줄까지 달하는데 2초 가량이 소요되었다고 한다. 초당 120만 줄이라는 구체적인 수치는 어떻게 나온 걸까?
  • 메모리 안전성: 광고한 대로 쓰레기 수집과 참조 카운팅이 없지만, 현재 구현에는 메모리 관리라는 개념이 아예 없다. 컴파일러 레벨에서 메모리 안전성을 보장하려면 RustOwnership 같은 개념이 필요한데, 문서에는 아무 것도 없고 Work in progress라는 단서만 붙어있다. 컴파일러에서 내놓는 C 코드를 봐도 메모리를 해제하는 코드가 전혀 호출되지 않는다. 즉 현재 구현에서 메모리 누수는 버그가 아니라 기능이다.
  • 핫 코드 리로딩은 코드를 .dll/.so로 컴파일하여 GetProcAddress()/ dlsym() 으로 바꿔치우는 방식으로 구현되어 있다. 이 방식은 제한된 상황에서만 사용할 수 있다. 예를 들어 구조체나 메모리 레이아웃이 바뀌는 변경은 적용될 수 없으며 이 경우에는 프로그램이 깨질 것이다.
  • REPL과 스크립트는 실제로는 컴파일러를 돌려서 바이너리를 뽑아내 실행하는 방식이다. 컴파일이 워낙에 빠르다 보니 인터프리터처럼 동작하는 것처럼 보일 뿐이다.
  • 표준 라이브러리는 아직 존재하지 않는다. 문서에도 없다.
  • 현 시점에서 DOOM 소스 코드를 V 코드로 변환하는 것은 불가능하다. 배포 버전에서 C → V변환 기능은 아예 막혀 있고, GitHub 저장소에 DOOM 소스 코드의 p_enemy.c 파일 하나만 변환된 결과가 올라와 있다. (이 파일을 다시 C로 변환해서 DOOM 소스 코드에 집어 넣으면 drop-in replacement로 동작한다고는 한다.)
  • 3D 그래픽스 라이브러리는 단순한 OpenGL 바인딩인데, 전체 OpenGL API의 10%도 커버하지 않고 있다.
  • GUI 라이브러리는 텅텅 비어 있다.

홈페이지에서 위의 기능들이 이미 준비되어 있는 것마냥 엄청나게 뻥을 쳐댔는데 릴리스 이후 홈페이지에서 준비되지 않은 기능들에 WIP를 달아놓긴 했다. 12월까지 WIP를 전부 제거하고 약속했던 기능들을 전달하겠다고 하는데 지켜볼 일이다.

여기서부터는 V 언어에 대한 개인적인 의견이다.

  • 신생 언어가 미완성인 것 자체가 비난받을 일은 아니다. 나 역시 한 명의 소프트웨어 개발자로서 완성된 제품을 전달하는 것이 얼마나 어려운 일인지는 잘 안다. 문제는 — 다른 많은 사람들도 지적했지만 — 기만적인 마케팅에 있다. 지금의 구현 상태와 홈페이지에 있는 홍보 문구와의 온도차는 상당히 크게 느껴진다.
  • 홈페이지에서 0.4초, 초당 120만 줄, C++의 400배 등등 극단적인 수치를 언급한 것 역시 잘 모르는 사람들을 낚기 딱 좋다고 느꼈다. 과연 이 수치가 얼마나 현실을 반영하고 있으며 정식 릴리스 이후에도 유지가능한 수치일까?
  • 뻥을 친 것 자체만 놓고 보면 그냥 과한 자신감의 발로라고 볼 수도 있다. 하지만 이 언어의 제작자는 과장된 홍보를 하고 이미 Patreon을 통해 돈을 벌고 있다. 몇몇 사람들이 V를 사기극이라고 생각했던 이유가 여기에 있다고 생각한다.
  • V 컴파일러가 진짜 컴파일러가 아니라 트랜스파일러인 부분은 크게 문제될 부분은 아니라고 생각한다. Bjarne Stroustrup이 만든 최초의 C++ 컴파일러인 Cfront 역시 C++ 코드를 C로 변환하는 트랜스파일러였다. 처음부터 성숙한 제품을 만들기 어려운 상황에서는 기존 생태계를 이용하는 것이 효과적이라 본다.
  • V 컴파일러가 자랑하는 빠른 속도는 단지 지금 컴파일러가 하는 일이 별로 없어서라고 생각한다. 기능이 추가되고 구현이 성숙된 뒤에도 이 속도를 유지할 수 있을까? 물론 개발자는 속도를 위해 앞으로도 최선을 다하겠지만 개인적으로는 잘 모르겠다. 소프트웨어의 복잡도는 마음먹은 대로 쉽게 컨트롤 가능한 것이 아니다.
  • C → V, C++ → V 기능은 약속한 대로 구현될수 있을지 의문이다. C도 쉽지 않은데 C++의 복잡도는 상상을 초월하는 수준이다. 예상되는 수많은 엣지 케이스에 전부 대응할 수 있을지 모르겠다.
  • 미안한 얘기지만 컴파일러 소스 코드의 퀄리티는 엉망이다. 구조화, 추상화의 원칙이 거의 적용되어 있지 않은 것처럼 보이며 유지보수 가능한 코드로 보이지 않는다. 한줄 한줄 손으로 짠 파서가 소스 코드를 읽으며 추상 구문 트리로 변환해서 분석하지도 않는다. 이 코드베이스에서 메모리 관리, 최적화 등의 복잡한 기능들을 어떻게 구현할 수 있을지 감이 잡히지 않는다. V가 잘 된다면 컴파일러는 새로 만드는게 더 나을 것 같다.
  • 개인적으로 가장 이해가 가지 않는 부분은, 지금까지 이만큼 만들어놓은 상황에서 메모리 관리에 대해서 아무런 생각이 없다는 점이다. 아니, 이건 언어를 만들때 가장 먼저 생각해야 하는 부분이 아닌가??? 메모리 모델과 타입 시스템이 어떻게 만들어지는지에 따라서 지금까지 만들어놓은 언어 명세와 컴파일러를 전부 갈아엎어야 할 수도 있다. 제작자는 처음 언어를 설계할 때 이 부분에 대해서 깊게 생각해보지 않은 것이 분명하다.
  • 결국 V가 지향하는 컴파일 타임 메모리 안전성을 달성하기 위해서는 Linear type system만 강제하거나 Rust 처럼 Lifetime, Ownership, Borrowing 등이 포함된 엄청나게 복잡한 시스템을 구현해야 한다. 전자는 제약이 커서 힘들고 현실적으로는 후자 말곤 답이 없는데, Rust의 극악한 복잡도와 진입 장벽의 주 원인이 이것임을 생각해보자. V가 추구하는 쉽고 간단하면서 안전한 언어라는 목표가 애초부터 달성 가능한 목표였는가?
  • 언어의 전반적인 느낌은 Go와 Rust를 섞어 놓은 느낌인데, Go를 좋아해본 적이 없는 입장에서 굳이 섞을 필요가 있나 싶기도 하다.
  • 언어에 기본적으로 포함되어 있는 패키지들이 대체로 과하다는 느낌이 든다. 과연 그래픽스, GUI, 웹 프레임워크가 언어의 핵심 구성요소로 제공되어야 하나? 잘 모르겠다.
  • 개발자가 우선 순위 설정을 잘 못하고 있다는 생각이 계속 든다. 단적으로 처음부터 표준 라이브러리를 설계하지 않은 점. 현재 표준 라이브러리의 상태는 그야말로 황무지나 다름없는데, (예를 들어 현재 hashmap 구현에는 int만 넣을 수 있다) 상식적으로 생각해서 핫 리로딩, GUI, 웹 프레임워크, ORM 같은거 만들 시간에 메모리 모델이랑 표준 라이브러리부터 먼저 설계해야 하는 것이 아닌가?
  • 그때그때 원하는 기능들을 탑다운으로 언어 스펙에 집어넣고 있다는 느낌도 크다. 예를 들면, JSON 역직렬화 기능은 컴파일러에 빌트인된 기능이다. 언어가 제정신으로 만들어졌다면 이 기능을 컴파일러에 직접 내리꽂는 대신 Reflection 스펙을 추가하고 그 위에 직렬화/역직렬화 프레임워크를 구현한 뒤 그 위에 JSON 지원을 추가했을 것이다. 그리고 #flag linux -I/usr/local/include/openssl 따위의 directive가 언어 명세에 들어가야 할 필요가 있는가? ORM도 마찬가지다. 언어 스펙에 ORM 같은 걸 구현하고 있을 시간에 훌륭한 ORM을 라이브러리로 구현할 수 있는 언어적 토대를 구축하는 것이 우선이다.
  • 전반적인 감상은 한 명의 개발자가 너무 많은 기능들을 한꺼번에 짧은 시간 내에 개발하려다가 난장판을 만들고 있는 것처럼 보인다. 지금은 수정됐지만, macOS용 http 모듈에서 다운로드 함수가os.system() 함수로 curl 명령을 실행시키는 형태로 구현되어 있다. 아무리 바빠도 그렇지, 제정신인 프로그래머라면 이딴 코드를 짜면 안 된다.
  • 결론은, V의 현재 구현 상태는 당초 약속했던 강력하고 안전하고 쉽고 간단하고 메인테이너블한 언어와 거리가 있으며 당장 달성할 수 있을 것으로 예상되지도 않는다. 만약 이 홍보 문구에 혹해서 V를 파 보고 싶다면 말리고 싶다.
  • 그러나 이러니 저러니 해도 소스 코드를 공개한 이후로 V는 꾸준히 주목을 받고 있고 기여 또한 늘어나고 있다. 현재 구현이 엉망이어서 그렇지 이 언어가 제시하는 비전이 많은 사람들에게 어필했을 것이라고 생각한다. 건강한 커뮤니티가 형성되어서 이 언어가 좀 더 나은 방향으로 발전했으면 하는 마음이 있다. 다만 개발자가 그동안 HN, 레딧 등에서 비판에 신경질적으로 대응해온 모습을 보면 걱정이 되는 것도 사실이다.

Park Joon-Kyu

Written by

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade