V 언어 리뷰 (2023) — 약속과 실제 구현 사이의 간극

AI 요약

이 글은 V 언어를 6개월 동안 사용한 경험과 작성 과정에서 확인한 Discord 논의를 바탕으로, 특정 커밋 b66447cf11318d5499bd2d797b97b0b3d98c306 시점의 실제 동작을 검토합니다. 리뷰어는 V 웹사이트가 제시하는 간결한 문법과 여러 약속이 실제 구현에서도 성립하는지 문서, 생성된 C 코드, Valgrind 결과, 간단한 실행 예제로 확인합니다. 글의 출발점은 언어를 배울 때 가장 먼저 확인하는 문서인데, V의 문서가 사실상 하나의 큰 docs.md 파일이며 주요 기능을 충분히 설명하지 않는다는 지적입니다. 예를 들어 i128과 u128에는 수년째 “곧 지원”된다는 표시가 남아 있고, int의 크기 설명도 릴리스 0.4.3에서 64비트 시스템 기준 64비트로 바뀌었습니다. 제네릭 문서도 몇 개의 코드 예제만 제공하며, 향후 동작을 약속하는 문장이 자주 등장한다고 설명합니다.

■ 메모리 관리와 manual 모드

V는 Garbage Collection, arena, manual memory management, autofree라는 네 가지 메모리 관리 방식을 제시합니다. 리뷰어는 GC와 arena는 상대적으로 동작하지만, manual과 autofree는 실제 애플리케이션에 사용하기 어렵다고 평가합니다. manual 모드에서는 모든 할당에 libc의 malloc이 사용되고 개발자가 직접 해제해야 하는데, 표준 라이브러리 내부에서 발생한 할당이 정리되지 않는 사례가 있습니다. 예로 string의 is_ascii 메서드는 내부에서 bytes()를 호출하며, 이 과정에서 할당된 메모리를 정리하지 않아 manual 모드에서 누수가 발생한다고 설명합니다. vweb의 공식 Hello World 예제에서도 요청을 처리하는 배열이 해제되지 않으며, CLI 프로그램에서 흔히 쓰는 문자열 보간도 할당 이후 정리되지 않는다고 지적합니다. 따라서 manual 모드는 모든 코드를 직접 작성하고 누수가 중요하지 않은 단순한 프로그램 정도에서만 사용할 수 있다고 결론 내립니다.

■ autofree 검증

V 문서는 -autofree 옵션이 컴파일러에 free 호출을 삽입해 객체의 약 90~100%를 자동으로 정리하고, 나머지는 GC가 처리한다고 설명합니다. 그러나 리뷰어는 이 설명이 문장마다 실제와 다르다고 주장합니다. 먼저 간단한 Data 구조체와 bool 배열만 사용하는 프로그램을 -autofree로 컴파일한 뒤 Valgrind로 실행했을 때, 6번 할당과 5번 해제 후 2바이트가 definitely lost로 남았습니다. 프로그램에는 배열 하나만 있었지만 총 1,085바이트가 할당된 점도 함께 지적합니다.

vweb 서버 예제에서는 요청을 보내지 않고 10초 동안 실행했는데도 총 2,659번의 할당 중 264번만 해제됐고, 종료 시 2,395개 블록과 122,833바이트가 남았습니다. definitely lost는 1,004바이트, indirectly lost는 106바이트였으며, still reachable도 121,451바이트였습니다. 리뷰어는 이를 통해 autofree가 최소한의 서버 실행에서도 누수를 막지 못한다고 설명합니다. 또한 특정 커밋에서 -autofree 옵션을 넘기면 gc_mode이 no_gc로 설정되도록 바뀐 코드를 제시합니다. 그 이전에는 free 함수가 Boehm GC가 활성화된 경우 실제 해제를 하지 않는 no-op이 될 수 있었고, 생성된 C 코드에서도 _v_free 함수의 본문이 비어 있었습니다. 이후 수정이 이루어져도 GC가 비활성화된 상태에서 누수가 남기 때문에, 문서의 “남은 객체는 GC가 해제한다”는 설명과 일치하지 않는다고 주장합니다.

리뷰어는 V의 텍스트 에디터 Ved를 -autofree로 빌드해 누수가 없다는 작성자의 시연도 재현하려 했지만, TOML 값을 map[string]toml.ast.Value에서 []toml.ast.Value로 변환할 수 없다는 panic을 만났다고 적습니다. autofree 없이 빌드하면 정상적으로 동작했으며, 언어 컴파일러 자체를 v self -autofree -o v2로 빌드한 뒤 ./v2 self을 실행했을 때도 string_starts_with에서 invalid memory access가 발생했다고 설명합니다. 이에 따라 autofree가 여러 차례 production ready가 될 것이라고 약속됐지만 여전히 초기 단계라고 결론 내립니다.

■ 기본 GC 모드와 불필요한 할당

V 웹사이트는 value type, string buffer, 단순한 추상화 없는 코드 스타일을 통해 불필요한 할당을 피한다고 설명합니다. 리뷰어는 구조체를 인터페이스로 변환하면 이를 피할 방법 없이 heap 할당이 발생한다고 지적합니다. 생성된 C 코드에는 구조체를 복제하기 위해 memdup과 _v_malloc을 사용하는 코드가 나타납니다. 또한 escape analysis가 없어 함수 안에서 어떤 값의 주소를 취하기만 해도 heap에 할당됩니다. 주소가 함수 밖으로 실제로 탈출하는지 분석하지 않고, 주소를 취한 사실만으로 heap 할당을 선택한다는 설명입니다. [heap] 속성은 이 문제의 해결책으로 제시되지만, 특정 인스턴스만이 아니라 해당 구조체의 모든 인스턴스를 heap에 배치하므로 불필요한 할당을 만들 수 있다고 지적합니다.

string builder로 “hello”를 만들었을 때 문자열 길이는 5바이트지만 gc_heap_usage 측정값은 48바이트였고, “hello world” 문자열 보간에서는 11글자에 304바이트가 할당됐습니다. 리뷰어는 이를 V가 내세우는 “최소한의 할당”과 맞지 않는 측정 결과로 제시합니다.

■ arena와 언어 안전성

-prealloc으로 활성화하는 arena는 프로그램 시작 시 큰 메모리 블록을 확보하고, 이후 할당을 그 안에서 처리하는 방식입니다. 짧은 수명의 프로그램이나 컴파일러처럼 종료 시 한꺼번에 메모리를 해제할 수 있는 작업에 적합하며, 작은 객체의 할당 비용을 줄일 수 있다고 설명합니다. 그러나 구현에는 __global g_memory_block 전역 변수가 있고, 리뷰어는 멀티스레드 접근을 보호하는 mutex를 찾지 못했다고 지적합니다. 이 사실이 문서가 아니라 구현 파일의 주석에만 적혀 있어 사용자가 소스 코드를 직접 읽어야 한다는 점도 문제로 제시합니다.

웹사이트의 안전성 주장도 검토합니다. unsafe 코드를 고려하지 않으면 null이 없다고 하지만 포인터 필드에 0을 넣을 수 있고, null 포인터 역참조에서는 invalid memory access가 발생합니다. 오버플로는 최근에야 수정됐으며, 포인터 비교 예제는 생성된 C 코드에서 undefined behavior가 됩니다. 초기화되지 않은 interface 필드 역시 정의되지 않은 값처럼 동작해 런타임 오류를 일으킵니다. 반면 C interop과 runtime reflection 없는 built-in serialization은 웹사이트의 설명대로 동작하는 항목으로 인정합니다.

■ 바이너리 크기 검증

V 웹사이트는 의존성 없는 native binary와 약 250KB 크기의 간단한 웹 서버를 강조합니다. 리뷰어가 Ubuntu 22.04에서 V 0.4.3 계열로 공식 vweb 예제를 빌드한 결과, -Os만 사용한 바이너리는 4,511,876바이트였습니다. -Os -flto와 -skip-unused를 함께 적용해도 2,784,628바이트였고, 여기에 -d use_openssl을 추가한 결과는 1,565,316바이트였습니다. 따라서 측정된 바이너리 크기가 웹사이트의 250KB 주장과 크게 다르다고 결론 내립니다.

■ Lobsters 반응

• @otde — 관련 글입니다. “V의 기묘한 세계”, “V는 vaporware입니다”(그리고 그에 해당하는 업데이트 글)도 있습니다. “기묘하다”는 표현이 잘 어울립니다. 그들이 초기 약속을 실제로 이행할 수 있을지, 아니면 약속이 계속 희석되기만 할지 어느 정도나 될지 궁금합니다.

• @cpurdy — 무엇보다 컬트에 더 가까워 보입니다. 방금 그 글을 읽었고, 다른 사람들이 발견한 문제를 발표했을 때의 이전 글과 이후 폭로 글도 몇 편 읽어 보았습니다. 예를 들면 https://justinas.org/the-bizarre-world-of-v 입니다. 수년 동안 Hacker News에 올라온 글들도 살펴봤는데, 이 사람의 글 https://news.ycombinator.com/item?id=45082256 같은 사례에서는 맹목적인 추종과 독설이 특히 강합니다. 오픈 소스 프로젝트든 상용 제품이든, 또는 그 무엇이든 계획, 실제 현실, 알려진 공백을 정직하게 설명하는 것이 중요합니다. 결국 이런 프로젝트의 복잡한 세부 사항을 이해하는 데 필요한 수년의 경험이 없는 사람들도 합리적인 도입 여부 판단을 내릴 수 있도록 신뢰할 수 있는 정보를 빠르게 얻을 수 있어야 합니다. 이 프로젝트는 거의 모든 가능한 방식에서 그 기준을 놀라울 정도로 계속 충족하지 못하고 있습니다.

원문: n-skvortsov-1997.github.io / 번역·요약: Trawling