EC2→hb5u CUDA 바이너리 빌드 배포 설계

— glibc 비대칭과 CUDA 크로스 타겟팅 전략

저자: EROS
일자: 2026-07-08
버전: v1
분류: build · cross-compile · cuda · deployment · thesis-3d

1. 환경 실측

# EC2 (빌드 환경)
$ uname -m       → x86_64
$ cat /etc/os-release → Amazon Linux 2023
$ ldd --version  → GNU libc 2.34

# hb5u (실행 환경)
$ uname -m       → x86_64
$ cat /etc/os-release → Ubuntu 25.10 (Questing Quokka)
$ ldd --version  → Ubuntu GLIBC 2.42
$ nvidia-smi     → RTX 5060 Laptop, compute 12.0, CUDA 13.2

2. 사령관 질문 분석 — "크로스 컴파일이 필요한가?"

2.1 CPU 아키텍처 관점

EC2와 hb5u 모두 x86_64. 이 경우 전통적 의미의 크로스 컴파일(예: x86→ARM)은 불필요하다. 같은 ISA이므로 EC2에서 생성된 기계어 명령어가 hb5u에서 그대로 실행된다.

2.2 CUDA 타겟 관점 — 이건 크로스 타겟팅

EC2: GPU 없음 → nvcc가 PTX/SASS 생성 불가 (GPU 없어도 컴파일은 가능)
hb5u: RTX 5060 Laptop, compute capability 12.0 (Blackwell)

nvcc -arch=sm_120을 EC2에서 실행하면 GPU 없이도 hb5u GPU에서 실행될 Blackwell SASS 코드를 생성할 수 있다. 이것이 CUDA 크로스 타겟팅이다. CPU 크로스 컴파일과 개념적으로 동일하지만, 컴파일러(nvcc)가 기본적으로 지원한다.

2.3 glibc 버전 관점 — 핵심 비대칭

이것이 실제 설계에서 가장 중요한 차이점이다.

빌드(EC2): glibc 2.34
실행(hb5u): glibc 2.42

glibc 하위 호환 원칙: glibc는 하위 호환성을 보장한다. 즉: - glibc 2.34에서 빌드 → glibc 2.34 이상 환경에서 실행 가능 ✅ - glibc 2.42에서 빌드 → glibc 2.42 미만 환경에서 실행 불가 ❌

따라서 낮은 버전(EC2 2.34) 빌드 → 높은 버전(hb5u 2.42) 실행 = 안전.

반대 방향(hb5u에서 빌드 → EC2로 배포)은 불가:

hb5u 빌드 바이너리가 glibc 2.42 심볼 참조
EC2 glibc 2.34에서 로드 시 → symbol lookup error

3. 빌드 전략 — EC2에서 빌드, hb5u로 배포

3.1 의존성 설계

layout_engine 바이너리
  ├─ libcuda.so.1      [동적] hb5u 드라이버에 존재 → 배포 불필요
  ├─ libcudart.so      [정적 링크] -cudart static → 바이너리에 포함
  ├─ libstdc++.so      [정적 링크] -static-libstdc++ → 바이너리에 포함
  ├─ libgcc_s.so       [정적 링크] -static-libgcc → 바이너리에 포함
  └─ libc.so (glibc)   [동적, 불가피] → EC2 2.34 빌드로 호환성 확보

glibc는 완전 정적 링크가 사실상 불가능하다 (DNS 리졸버 등 동적 로드 구조). 대신 낮은 버전(EC2 2.34)에서 빌드해 호환성을 확보한다.

3.2 빌드 명령

# EC2에서 실행 (nvcc 설치 후)
nvcc -O3 \
    -arch=sm_120 \
    -cudart static \
    -Xcompiler "-O3 -static-libgcc -static-libstdc++" \
    layout_engine.cu -o layout_engine

# 의존성 검증
ldd layout_engine
# 기대 출력:
#   linux-vdso.so.1
#   libcuda.so.1 => /lib/x86_64-linux-gnu/libcuda.so.1
#   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
#   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
# → libcudart, libstdc++, libgcc 없음 (정적 링크됨)

# hb5u 배포
scp layout_engine hb5u:/home/moos/dev_ws/dual_arms/scripts/

3.3 -arch=sm_120 지원 nvcc 버전

sm_120 (Blackwell)은 CUDA 12.8+에서 지원된다. EC2에 설치할 nvcc 버전이 12.8 이상이어야 한다.

# EC2에서 확인
nvcc --list-gpu-arch | grep sm_120
# 없으면 cuda-toolkit 버전 업그레이드 필요

4. 대안 전략 비교

전략 A 선택 근거: glibc 하위 호환 원칙으로 호환성 보장됨. hb5u sudo 문제 우회 가능. EC2는 이미 제어권이 있음.

5. glibc 심볼 버전 검증 방법

빌드 후 의도치 않게 높은 glibc 심볼이 참조되지 않았는지 확인:

# 바이너리가 요구하는 최소 glibc 버전 확인
objdump -p layout_engine | grep GLIBC
# 예: GLIBC_2.17, GLIBC_2.34 등
# → 2.34 이하 심볼만 있으면 hb5u(2.42)에서 실행 보장

6. 빌드 파이프라인 설계

[EC2] ~/hypercode/services/layout-engine/
  ├─ layout_engine.cu      # CUDA 소스
  ├─ Makefile              # 빌드 자동화
  └─ deploy.sh             # scp → hb5u + viz_server 재시작

[Makefile]
build:
    nvcc -O3 -arch=sm_120 -cudart static \
         -Xcompiler "-O3 -static-libgcc -static-libstdc++" \
         layout_engine.cu -o layout_engine
    objdump -p layout_engine | grep GLIBC  # 심볼 검증

deploy: build
    scp layout_engine hb5u:/home/moos/dev_ws/dual_arms/scripts/
    ssh hb5u 'kill $(pgrep -f viz_server.py); bash /tmp/start_viz.sh'

[deploy.sh]
#!/bin/bash
make deploy

7. 결론

사령관의 직관이 정확했다. EC2와 hb5u는 CPU ISA는 동일하지만 glibc 버전(2.34 vs 2.42)이 다르다. 그러나 이는 전통적 크로스 컴파일 문제가 아니라 glibc 하위 호환 방향 문제다.

해결 원칙: 1. 항상 낮은 glibc 환경(EC2)에서 빌드 → 높은 환경(hb5u)에서 실행 보장 2. CUDA 크로스 타겟팅: -arch=sm_120으로 EC2에서 hb5u GPU용 코드 생성 3. 정적 링크 최대화: cudart, libstdc++, libgcc 정적 링크 → libcuda.so.1 하나만 동적 4. objdump로 심볼 검증: 빌드 후 최소 glibc 버전 확인 자동화

다음 단계: EC2에 nvcc(CUDA 12.8+) 설치 후 layout_engine.cu 구현 및 배포.