요약(TL;DR): Go 서비스가 cgo, CUDA 툴킷, 비대한 Python 의존성 없이 NVIDIA GPU와 직접 통신할 수 있도록 gocu

요약(TL;DR): Go 서비스가 cgo, CUDA 툴킷, 비대한 Python 의존성 없이 NVIDIA GPU와 직접 통신할 수 있도록 gocudrv를 구축했습니다. 단 하나의 정적 바이너리(Static binary)로 구현되었습니다. 지난달 저는 운영 중인 AI 서비스를 검토하고 있었습니다. 핵심 비즈니스 로직은 깔끔하고 효율적인 Go(15MB 바이너리)로 작성되어 있었지만, GPU 접근은 Python 사이드카(Sidecar)를 통해 라우팅되고 있었습니다. 그 결과는 고통스러웠습니다: 사용하지 않는 CUDA 툴킷과 PyTorch 의존성으로 인해 비대해진 8.4GB의 Docker 이미지, 오토스케일링(Autoscaling) 시 발생하는 4분의 콜드 스타트(Cold start), Go → Python → GPU 사이의 추가적인 직렬화(Serialization) 및 네트워크 홉(Network hops). 우리는 "GPU는 Python의 영역이다"라는 이유로 이를 받아들여 왔습니다. 저는 그 가설에 도전하기로 했습니다.

불가능해 보이는 빌드: CGO_ENABLED=0
대부분의 Go 개발자들은 CUDA를 사용하려면 cgo가 필요하다고 가정합니다. 대신, 저는 C 컴파일러를 완전히 우회하기 위해 purego와 함께 (NVIDIA 드라이버가 설치된 곳이라면 어디든 이미 존재하는) CUDA Driver API를 사용했습니다.

// internal/platform/platform_linux.go
func LibraryCandidates () [] string {
return [] string {
"libcuda.so.1",
"/usr/lib/x86_64-linux-gnu/libcuda.so.1",
"/usr/lib/wsl/lib/libcuda.so.1",
// WSL2에서 원활하게 작동함
}
}

gocudrv는 런타임(Runtime)에 libcuda.so를 로드합니다. 표준 go build가 작동하며, Mac에서 Linux를 타겟으로 빌드할 때도 마찬가지입니다.

결과 증명: 크기 및 빌드 비교

저수준 커널 성능 (RTX 4070 Ti에서 10M 요소 벡터 덧셈 수행)

단순 벡터 덧셈(~114 MB 데이터)의 경우:

• H→D 복사 (Host to Device Copy): 19.3 ms
• 커널 실행 (Kernel Launch): 3.4 ms
• D→H 복사 (Device to Host Copy): 25.6 ms
• 총 GPU 파이프라인 (Total GPU Pipeline): 48.3 ms

이 수치들은 순수한 GPU 작업량을 나타냅니다.

이전의 Python 사이드카 (sidecar) 설정에서는 다음과 같은 추가 비용도 발생했습니다:

• JSON/Protobuf 직렬화 (serialization)
• 로컬 네트워크 소켓 전송 (Go → Python)
• Python 인터프리터 + PyTorch 오버헤드 (overhead)

진정한 승리는 반드시 마이크로 벤치마크 (micro-benchmarks)에서 PyTorch를 이기는 것이 아니라, 사이드카 레이어 전체와 그 운영 복잡성을 제거하는 데 있습니다.

단순한 래퍼 (Wrapper) 그 이상

Pure Go가 느리다는 것을 의미하지는 않습니다. 저는 PCIe 전송 지연 시간 (latency)을 숨기기 위해 처음부터 비동기 중첩 (asynchronous overlap)에 집중했습니다:

stream, _ := ctx.NewStream() // DMA 전송 시작 — 즉시 반환
err := buf.CopyFromHostAsync(ctx, stream, hostBuffer) // GPU가 계산하는 동안 Go는 유용한 작업을 수행할 수 있음
// ...
err = stream.Synchronize(ctx) // 필요한 경우에만 동기화

이것이 2026년에 중요한 이유

AI는 연구용 데모에서 핵심 인프라 (critical infrastructure)로 변화하고 있습니다. Go는 안정성, 동시성 (concurrency), 관찰 가능성 (observability), 그리고 운영 예측 가능성 (operational predictability) 측면에서 탁월하며, 이는 바로 프로덕션 모델 서빙 (production model serving)이 요구하는 사항입니다.

Python 사이드카를 제거하면 다음과 같은 이점을 얻을 수 있습니다:

• 획기적으로 작은 이미지 크기와 빠른 배포 (deploys).
• 훨씬 더 나은 콜드 스타트 (cold start) 시간.
• 단일 언어 및 단일 바이너리 (훨씬 단순한 관찰 가능성 및 디버깅).
• GIL(Global Interpreter Lock) 없음, 더 나은 P99 꼬리 지연 시간 (tail latencies).

현재 상태 (솔직하게)

gocudrv는 아직 초기 단계이며 실험적입니다. 핵심 기능(장치 관리, 메모리 관리, PTX 로딩, 스트림, 비동기 복사)은 현재 작동하지만, 복잡한 고성능 추론 서빙 (inference serving)을 수행할 준비는 아직 되지 않았습니다. 저는 현재 CUDA Graphs, Events & Timing, 그리고 멀티 GPU 지원을 활발히 작업 중입니다.

프로덕션 환경에서 무거운 Python AI 런타임 (runtimes)을 운반하는 것에 지친 Go 엔지니어라면, 여러분의 피드백과 기여를 환영합니다. → link