GPU와 NPU, 각종 가속기가 뒤섞인 환경에서 소프트웨어를 짜는 일은 점점 더 많은 실무자의 일상이 되고 있다. 그런데 이 세계의 고질적인 고통은 성능 튜닝이 아니라, 새벽 3시에 터지는 세그폴트나 학습 1200스텝에서 느닷없이 나는 메모리 부족 오류처럼 '엉뚱한 곳에 있던 데이터'가 뒤늦게 사고를 일으킨다는 점이다. Vx는 바로 이 문제를 겨냥한 시스템 프로그래밍 언어다. CPU·GPU·NPU·가속기의 메모리를 타입 시스템 안으로 끌어들여, 호스트 스레드가 디바이스 포인터를 역참조하는 코드를 런타임 크래시가 아니라 컴파일 오류로 잡아낸다. 현재 애플 실리콘 기반 macOS와 x86_64 리눅스를 지원한다.
가속기를 인프라가 아니라 의미론으로
Vx의 핵심 발상은 '이기종성은 런타임이 아니라 타입 시스템에 속한다'는 것이다. 대부분의 언어는 가속기를 인프라로 취급한다. 개발자는 수식을 쓰고, 거대하고 불투명한 런타임이 그 연산을 어디로 보낼지 알아서 정한다. 반면 Vx는 데이터가 어디에 놓였는지를 의미론의 일부로 본다. NPU의 고대역폭 메모리에 고정된 텐서는 호스트 DRAM에 있는 텐서와 아예 다른 타입이며, 둘 사이를 오가려면 명시적인 transfer() 호출이 필요하다. 심지어 하드웨어적으로 경계를 넘는 비용이 0일 때에도 그렇다. 애플의 통합 메모리에서는 이 transfer가 사실상 아무 코드로도 컴파일되지 않지만, 그래도 소스에 적어두게 한다. 데이터 지역성은 바이너리를 프로파일링해서가 아니라 소스를 읽는 것만으로 증명될 수 있어야 한다는 철학이다.
런타임이 아니라 컴파일 타임으로 당겨온 버그들
Vx가 노리는 것은 평소 런타임 크래시, 조용한 데이터 손상, 특정 스텝에서의 메모리 부족으로 나타나던 버그를 타입 검사 단계로 앞당겨 잡는 일이다. 구체적으로는 호스트에서 디바이스 포인터를 역참조하는 경우, NPU SRAM에 고정된 값이 호스트 표현식으로 새어 나가는 경우, 선언된 메모리 공간에 작업 집합이 들어가지 않는 배치 등을 바이너리가 만들어지기도 전에 걸러낸다. 비동기 전송이 아직 가시화되지 않은 버퍼를 읽는 상황은 SMT 증명기로 해소하고, 소비된 버퍼의 use-after-move는 변성과 영역 추적을 갖춘 보로우 체커로 막는다. 경로가 선언되지 않은 두 메모리 공간 사이의 전송이나, 수반 함수가 정의되지 않은 영역을 미분하려는 시도도 오류로 처리된다. 요컨대 이기종 메모리에서 나는 사고의 상당수를 타입 수준의 정적 규칙으로 환원한 셈이다.
하드웨어를 '읽는' 컴파일러
흥미로운 설계는 비용 모델을 다루는 방식이다. 대부분의 컴파일러는 비용 모델을 내부에 하드코딩하지만, Vx는 외부의 머신 파일을 읽어 들인다. 이 파일은 실제 부품의 메모리 계층과 인터커넥트를 기술하며, 컴파일러는 그에 비추어 특정 배치를 허용하거나 거부한다. 단위 환산은 부동소수점이 아니라 정확한 정수 변환으로 처리해, SI 접두사는 십진(GB=10의 9승), IEC 접두사는 이진(GiB=2의 30승)으로 엄밀히 구분한다. 벤더 스펙시트에서 옮겨 적은 수치가 시트가 의도한 그대로의 값을 유지한다는 뜻이다. 저장소에는 H100, H200, B200, A100, MI300X, 애플 M4, 그리고 다중 GPU 노드를 위한 머신 파일이 각각 출처를 명시한 채 들어 있고, 검증되지 않은 수치는 '미검증'으로 표시된다.
컴파일러 내부 구조도 결정론과 병렬성을 위해 다듬어졌다. 모든 심볼과 명목 타입, 단형화된 변형은 256비트 평면 식별자를 갖는다. 명목 타입 시스템과 재귀 타입의 강제 박싱으로 모듈 간 결합을 끊어, 질의 엔진이나 락 경합 없이 코어 전반에 걸쳐 파이프라인이 병렬로 돈다. 컴파일은 포인터를 따라가는 트리가 아니라 평면 배열을 순회하는 방식이다. 덕분에 동일한 소스는 직렬로 빌드하든 병렬로 빌드하든 바이트 단위로 동일한 MLIR을 만들어낸다. 이 성질은 '그러길 바란다' 수준이 아니라 테스트 스위트에서 단일 스레드, 4스레드, 스레드 풀을 아예 제거한 경로, 그리고 매번 새 해시 시드를 받는 신규 프로세스 재컴파일 코퍼스까지 포함해 단언된다. 다만 이 보장은 프런트엔드가 내보내는 MLIR에 한정되며, 그 아래 단계는 LLVM의 몫이다. 벤더는 컴파일러를 패치하는 대신 MLIR 패스 플러그인으로 확장한다.
어디에 쓰고 어디에 쓰지 말아야 하나
실무적으로 Vx의 위치는 분명하다. 파이토치 사용자는 학습 루프 도중 아키텍처를 바꾸고, 텐서 모양을 출력해 그 값으로 분기하고, 그대로 진행한다. 사전 컴파일 방식에 데이터 지향적이고 정적으로 영역을 나누는 Vx에서는 그런 동적 유연성을 누리려면 상당한 수고가 든다. 반대로 열 종류의 서로 다른 실리콘을 넘나들면서도 반드시 정확하고 빨라야 하는 코드라면 Vx가 제값을 한다. 즉 아직 무엇을 만들지 탐색하는 단계의 코드에는 맞지 않고, 요구사항이 굳어져 신뢰성과 성능을 한꺼번에 담보해야 하는 커널·추론 경로 같은 영역에 적합하다는 얘기다. 이 경계를 분명히 그어둔 점이 오히려 언어의 성격을 잘 설명한다.