# CUDA에 도전하는 ROCm: ‘한 걸음씩 나아가기’ > Clean Markdown view of GeekNews topic #28524. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28524](https://news.hada.io/topic?id=28524) - GeekNews Markdown: [https://news.hada.io/topic/28524.md](https://news.hada.io/topic/28524.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-15T07:33:09+09:00 - Updated: 2026-04-15T07:33:09+09:00 - Original source: [eetimes.com](https://www.eetimes.com/taking-on-cuda-with-rocm-one-step-after-another/) - Points: 2 - Comments: 2 ## Topic Body - AMD는 **Nvidia CUDA 생태계**에 대응하기 위해 **AI 소프트웨어 스택 ROCm**을 중심으로 데이터센터 GPU 전략을 강화하고 있음 - ROCm은 초기의 단순 펌웨어 묶음에서 **완전한 소프트웨어 플랫폼**으로 발전했으며, **6주 주기 릴리스 체계**를 도입해 안정적 사용성을 확보 중임 - **OneROCm**을 통해 CPU, GPU, FPGA 간 **AI 스택 통합과 이식성 확보**를 추진하며, **Triton·MLIR** 기반 코드 재활용으로 개발 효율을 높이고 있음 - ROCm은 **펌웨어를 제외한 전 구성요소를 오픈소스화**해 커뮤니티 혁신 속도를 흡수하고, **Strix Halo 노트북과 Windows 버전**에서도 기본 지원됨 - AMD는 **개발자 피드백 대응과 커뮤니티 신뢰 회복**을 중시하며, ROCm을 향후 **10년간 지속 가능한 개발자 중심 플랫폼**으로 발전시키는 것을 목표로 함 --- ### AMD ROCm의 진화와 CUDA 경쟁 전략 - AMD는 **데이터센터 GPU 시장**에서 Nvidia의 CUDA 생태계에 대응하기 위해 **AI 소프트웨어 스택 ROCm**을 핵심 전략으로 추진 중임 - **AI 소프트웨어 부문 부사장 Anush Elangovan**은 ROCm 개발을 “산을 오르는 일처럼 한 걸음씩 나아가는 과정”으로 표현하며, 지속적 개선과 통합을 강조함 - 그는 **스타트업 Nod.ai 인수**를 통해 AMD에 합류했으며, Nod 팀은 **Shark, Torch.MLIR, IREE** 등 주요 오픈소스 프로젝트에 기여한 경력을 보유함 - AMD는 ROCm을 통해 **CPU, GPU, FPGA 간 AI 스택 통합(OneROCm)** 을 추진하며, 소프트웨어 개발 주기를 6주 단위로 단축해 “사용자가 버전을 의식하지 않아도 되는 수준”을 목표로 함 - ROCm은 현재 **AI 지원 엔지니어링 전환**을 준비 중이며, 오픈소스 생태계와 개발자 커뮤니티 중심의 확장을 가속화하고 있음 ### ROCm의 발전과 소프트웨어 전략 - ROCm은 초기에는 **여러 펌웨어 조각을 묶은 형태**였으나, 2년 반의 투자 이후 완전한 소프트웨어 플랫폼으로 발전함 - Elangovan은 Google Chrome 팀의 개발 문화를 벤치마킹해 **정기적 릴리스 주기와 안정적 사용자 경험**을 목표로 함 - ROCm은 “그냥 작동하는” 소프트웨어로 자리 잡았으며, 향후 **6주 주기 릴리스 체계**로 전환 예정임 - AMD는 **하드웨어 중심 기업에서 소프트웨어 중심 기업으로 전환** 중이며, 다음 단계로 **AI 보조 엔지니어링(AI-assisted engineering)** 을 핵심 전환점으로 삼고 있음 ### AI 스택 통합과 이식성 - AMD는 **OneROCm**을 통해 CPU, GPU, FPGA 등 다양한 하드웨어 간 **AI 스택 통합**을 실현함 - 일부 구성요소는 여전히 하드웨어 종속적이지만, 모든 가속은 ROCm 스택을 통해 수행되어 **이식성(portability)** 확보 - **Triton** 프레임워크 확산으로 GPU 간 호환성 문제가 완화됨 - 과거에는 CUDA 커널을 HIP 커널로 변환했으나, 현재는 **Triton 커널을 작성해 AMD와 Nvidia 모두에서 실행 가능** - AMD는 Triton 및 **MLIR 컴파일러 인프라**에 적극 투자하며, Torch.MLIR 유지보수를 통해 다양한 하드웨어로 코드 재타깃팅 지원 - 대부분의 추론 고객은 **vLLM, SGLang** 등 LLM 프레임워크를 사용하며, CUDA 코드 변환 요청은 감소함 - 새로운 주의(attention) 알고리듬이 등장하면 **Triton 기반 커널을 하루이틀 내 최적화** 가능 - **HIPify**는 여전히 HPC 고객용으로 제공되며, 새로운 커널 작성에는 **Claude AI**를 활용해 검증 및 코드 생성을 수행함 ### 오픈소스 전략 - ROCm은 **펌웨어를 제외한 전 구성요소를 100% 오픈소스**로 공개함 - 오픈소스화로 개발자 커뮤니티의 검증을 받는 동시에 **AMD보다 빠른 커뮤니티 혁신 속도**를 활용 가능 - 누구나 컴파일러, 런타임 등 원하는 지점에서 참여할 수 있으며, **AMD의 협업 속도에 제한받지 않음** - AMD는 **개발자 커뮤니티 확장**을 적극 추진 중이며, **Strix Halo 탑재 노트북에서 ROCm이 기본 지원**됨 - Instinct 데이터센터 하드웨어와 **동일한 날에 Windows 버전 ROCm 업데이트**를 배포함 ### 개발자 커뮤니티와 피드백 문화 - Elangovan은 개발자와의 직접 소통을 중시하며, **X(Twitter)** 를 통해 실시간 피드백을 수집함 - “ROCm”, “ROCm sucks”, “AMD software not working” 등의 키워드를 모니터링하며, 모든 게시물에 직접 응답 - 대부분의 문제는 **교육과 지원 부족**에서 비롯되며, 익명 개발자에게도 직접 조언을 제공함 - AMD는 GitHub에서 ROCm 관련 **1,000건 이상의 불만 조사**를 진행했고, 1년 내 모두 해결함 - 구형 하드웨어 지원 요청이 많았으며, 현재는 **AMD 또는 커뮤니티가 유지보수 중** - 이러한 대응으로 개발자 신뢰가 회복되었으며, “AMD는 문제를 해결한다”는 인식이 확산됨 - Elangovan은 **MI450 GPU(2026년 하반기 출시 예정)** 에 기대를 표하며, ROCm을 **향후 10년간 지속 가능한 플랫폼**으로 발전시키겠다고 강조함 - 새로운 하드웨어 등장 시에도 개발자가 걱정하지 않아도 되는 **안정적 생태계 구축**을 목표로 함 ### 미래 방향과 철학 - Elangovan은 Nod.ai 시절의 경험을 바탕으로, **컴파일러 기술이 거의 모든 가속기 기업에 채택된 사례**를 언급함 - 그는 “확신을 가지고 한 걸음씩 나아가야 한다”며, ROCm의 발전을 **지속적 실행의 결과**로 정의함 - AMD는 CUDA를 단순히 복제하는 수준을 넘어, **차별화된 ROCm 기능**을 개발 중이며, 장기적으로 **개발자 중심 플랫폼**으로 자리매김을 목표로 함 ## Comments ### Comment 55724 - Author: picopress - Created: 2026-04-18T00:11:43+09:00 - Points: 1 드라이버부터 좀... ### Comment 55346 - Author: neo - Created: 2026-04-15T07:33:10+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47745284) - 지난주 동안 **TheRock를 stagex로 포팅**하면서 ROCm을 musl/mimalloc 기반 툴체인으로 빌드하려고 시도했음 보안·프라이버시가 중요한 워크로드에서 단일 컴파일러로만 빌드된 바이너리를 신뢰할 수 없기 때문임 30개 이상의 의존성과 커스텀 LLVM을 패키징하느라 악몽 같은 시간이었지만, 오늘 아침 드디어 런타임 빌드에 성공했음 AMD 하드웨어가 완전한 오픈 환경에서 동작한다는 점 덕분에 **고보안 워크로드**에 희망이 보임 - 나도 ROCm을 musl 위에서 패키징하려고 했음, 특히 **Alpine Linux용**으로 커스텀 LLVM 포크와 여러 패키지를 넘기긴 했지만 결국 시간 낭비라 포기했음 지금은 Vulkan 지원이 있는 llama.cpp를 쓰는데 충분히 만족스러움 혹시 빌드 레시피를 공유해준다면 Alpine 포팅의 마지막 단계를 넘기는 데 도움이 될 것 같음 - 이런 상황을 반복해서 보는 게 안타까움 작년에 AMD의 약속을 믿고 주주 캠페인을 멈췄지만, 이제는 정말 행동이 필요하다고 느낌 [unlockgpu.com/action-plan](https://unlockgpu.com/action-plan/) - [이슈 #3477](https://github.com/ROCm/TheRock/issues/3477)을 보면 마음이 아픔 이런 식이면 안 됨, 이 작업은 분명히 **활용 가능해야 함** - 혹시 Nvidia를 신뢰하지 않는 이유가 **드라이버가 폐쇄형**이라서인가? Nvidia도 오픈소스 드라이버를 개선하겠다고 약속했음 개인적으로는 Intel이 32GB VRAM을 1000달러 수준에 제공하는 점이 더 매력적임 - “단일 컴파일러로만 빌드된 바이너리를 신뢰할 수 없다”는 말이 흥미로움 서로 다른 컴파일러로 .o 파일을 섞어 링크하는 방식인가? 혹시 **Reflections on Trusting Trust** 문제를 실제로 회피하려는 워크로드인지 궁금함 - 2월부터 AMD에 **gfx1201용 튜닝된 Tensile 커널**을 rcom-libs에 포함해달라고 요청 중인데, 아무도 담당자를 모름 개발자 Discord에서도 답이 없어 답답함. 기술적 문제 외에도 AMD의 **조직적 병목**이 드러나는 사례 같음 - GitHub에 이슈를 올려봤는지? [zichguan-amd](https://github.com/zichguan-amd)나 [harkgill-amd](https://github.com/harkgill-amd)가 관련 담당자일 수 있음 - AMD는 ROCm 관련해서 아직 **수년의 격차**를 따라잡아야 함 AI 연산이 가능한 자사 GPU조차 전부 지원하지 않고, 지원되는 경우에도 버그가 많음 Linux용 AMDGPU 드라이버는 6.6 이후 계속 불안정함 - 인재를 못 구하는 이유는 단순함. 세계 최고 기업들과 **인재 경쟁**을 해야 하는데, AMD는 불과 10년 전까지만 해도 회사 존폐 위기였음 - 결국 **급여를 충분히 주지 않기 때문** 아닐까 - ROCm을 너무 오래 방치했음. 5년 전 내 친구들이 내부에서 투자 확대를 설득했지만 실패했음 AI가 중요해지는 걸 못 본 건 명백한 실책임 AMD가 경쟁력을 갖추면 업계 전체가 좋아질 텐데, 이건 스스로 자초한 일임 - 이건 문화적 문제일 수도 있음 예전 ATI 시절부터 **버그 많은 드라이버**로 악명이 있었고, AMD가 인수한 뒤에도 그 문화가 바뀌지 않은 듯함 - 작년에 AMD가 GitHub에서 ROCm 관련 불만을 수집했는데, 1000건 모두 해결됐다고 발표했음 하지만 실제로는 **옛 하드웨어 지원이 거의 늘지 않았음** - 여러 위키를 뒤져서 수동으로 카드 지원을 해킹해야 하는 수준이라면, 그걸 “지원 추가”라고 부를 수 있을지 의문임 - ROCm이 모든 AMD 카드에서 **출시 즉시 지원**되는 날이 오면 그때야 비로소 홍보를 믿을 수 있을 것 같음 예전에 400 시리즈 같은 최신 카드도 버려버린 건 큰 실수였음 경영진이 소프트웨어 스택에 더 투자하길 바람 - CUDA도 완벽하진 않음. 예를 들어 GB10은 출시된 지 꽤 됐지만 여전히 **미구현 기능**이 많음 - ROCm은 일반 소비자용 GPU, 예를 들어 RX 580 같은 카드에서는 지원되지 않음 대신 Vulkan 백엔드는 잘 작동함 - 2018년에 RX 580을 샀는데, RDNA1·RDNA2 GPU 지원이 부족한 점이 아쉬움 GCN 아키텍처는 이제 지원이 끊긴 게 당연하다고 생각하지만, RDNA 세대는 여전히 **지원 부족**이 문제임 - ROCm은 보통 두 세대의 GPU만 지원함 현재는 RDNA3·RDNA4만 가능하고, CUDA는 여전히 **Turing**까지 지원함 [공식 문서](https://rocm.docs.amd.com/projects/install-on-linux/en/latest/) 참고 - RX 5700을 쓰는데, 지원되는 ROCm 버전이 너무 오래돼 Ollama를 돌릴 수 없음 Vulkan 백엔드는 잘 되지만, 공식 지원까지 1~2년이 걸렸음 - Vulkan은 잘 작동하지만, C++·Fortran·Python JIT 커널이나 IDE 통합, 디버깅, 라이브러리 지원이 부족함 - 예전에는 RX580으로 ROCm을 썼던 것 같은데, 지금은 **지원 종료**된 건가? - ROCm 스택을 **정리(clean-up)** 해줬으면 함 단순히 `git clone --recurse-submodules rocm` 후 configure/make로 빌드할 수 있게 하고, 누락된 의존성을 명확히 출력해줬으면 함 지금은 구조 없이 여러 구성요소를 던져놓은 수준이라, **일관된 아키텍처**가 보이지 않음 - 나는 **OpenVINO와 SYCL**로 CUDA에 맞서는 팀임 Intel의 iGPU·dGPU가 최근 가격도 합리적이고 소프트웨어 지원도 좋아졌음 게임용이 아니라 CV나 데이터 사이언스 워크로드에서는 꽤 잘 스케일링됨 - AMD 경영진에게 전하고 싶은 ROCm 관련 피드백임 (1) 서버급 GPU만 지원하고 **소비자용 GPU/APU를 무시**한 건 전략적 실수임 개발자 대부분은 개인 노트북에서 실험하고 나중에 서버로 확장함 CUDA처럼 성능이 낮더라도 소비자용 GPU에서 돌아가게 해야 함 (2) 두 세대만 지원하는 정책은 고객 입장에서 **비합리적**임 [공식 문서](https://rocm.docs.amd.com/projects/install-on-linux/en/docs-) 참고 CUDA는 강력한 **하위 호환성**을 유지함 (3) Triton에만 집중하고 HIP을 2등급 취급하는 건 잘못된 방향임 여전히 C/C++ 기반 HPC·시뮬레이션·과학 코드가 많음 AMD GPU는 FP64 성능이 강점인데, 그걸 스스로 버리는 셈임 (4) 마지막으로 **패키징 품질**을 개선해야 함 배포판 패키저와 협력하는 게 큰 비용이 들지 않으며, Nvidia 대비 경쟁 우위를 줄 수 있음 - CUDA는 **polyglot 지원**이 강점임 Python, Julia 등 다양한 언어에서 커널을 직접 작성할 수 있고, IDE·디버거·라이브러리 통합도 훌륭함 GPGPU 생태계 전체를 보면 AMD와 Intel은 아직 CUDA의 **에코시스템 완성도**를 따라가지 못함 - 패키징은 사실 쉬운 일이 아님 대부분의 기업은 `/opt/foo/` 같은 **벤더 설치 방식**을 택함 이렇게 하면 배포판이 나중에 자체 패키징하기도 쉬워짐 하지만 이를 이해하려면 오픈소스 생태계 경험이 있는 인력이 필요함 - NVIDIA도 비슷한 실수를 하고 있음 소비자용 고 VRAM GPU 출시를 늦추며 서버 시장에 집중 중임 AMD가 이 틈을 잘 활용하면 기회가 될 수 있음 - 사실 ROCm은 공식 지원이 아니어도 **비공식적으로 동작**함 예를 들어 7900 XT에서도 잘 돌아감 단지 AMD가 테스트 리소스를 투자하지 않아 “공식 지원”으로 표기하지 않을 뿐임 - 예전에 **컴퓨트 셰이더**를 다뤄본 경험으로는 CUDA, ROCm, OpenCV 모두 설치가 너무 번거로움 의존성도 크고, CUDA는 11GB나 됨 그냥 Vulkan을 쓰는 게 낫다고 생각함. 플랫폼 종속도 없고 “그냥 작동함” - Vulkan은 설치는 쉽지만 코드가 복잡함 셰이더 컴파일과 리소스 설정만 해도 수백 줄이 필요하고, GPU 주소를 다루려면 확장이 필요함 - Windows에서는 3GB짜리 exe 설치, Linux에서는 저장소 추가 후 설치면 끝임 그게 몇 시간씩 걸릴 일인가 싶음 - Vulkan은 **저수준 API**라 단순한 작업도 200줄 이상 필요함 예전에는 NVIDIA에서 그래픽 모드로 전환하면 **성능이 20% 향상**되는 버그(?)도 있었음