<div id="readability-page-1" class="page"><response-element ng-version="0.0.0-PLACEHOLDER"><link-block _nghost-ng-c539156122=""><a href="https://androidkr.blogspot.com/2025/11/ai-1-gpu-tpu.html" target="_blank">1부: 아키텍처 차이점</a></link-block></response-element>에서 우리는 <a data-preview="" href="https://www.google.com/search?ved=1t:260882&amp;q=define+GPU&amp;bbid=7673110288092522152&amp;bpid=8181871143210177446" target="_blank">GPU</a>와 <a data-preview="" href="https://www.google.com/search?ved=1t:260882&amp;q=define+TPU&amp;bbid=7673110288092522152&amp;bpid=8181871143210177446" target="_blank">TPU</a>의 물리적 본질을 파헤쳤습니다. GPU는 유연한 병렬 처리를 위한 수천 개의 독립적인 코어(스위스 아미 나이프)이고, TPU는 행렬 연산에 극도로 최적화된 거대한 시스톨릭 어레이(레이저 커터)입니다.<div _ngcontent-ng-c607179692="" aria-busy="false" aria-live="off" dir="ltr" id="model-response-message-contentr_2cffe4c0ba48e165" inline-copy-host="">하지만 하드웨어는 엔진일 뿐입니다. 그 엔진을 움직이려면 운전대와 페달, 즉 소프트웨어가 필요합니다.아무리 강력한 칩이라도 개발자가 프로그래밍할 수 없다면 무용지물입니다. 바로 이 지점에서 AI 인프라의 가장 치열한 전투가 벌어지고 있습니다. 엔지니어 입장에서 GPU와 TPU를 다루는 경험은 어떻게 다를까요? 왜 수많은 기업이 여전히 비싼 <a data-preview="" href="https://www.google.com/search?ved=1t:260882&amp;q=define+NVIDIA+GPU&amp;bbid=7673110288092522152&amp;bpid=8181871143210177446" target="_blank">NVIDIA GPU</a>를 고집할까요? 그리고 Google은 이 견고한 성벽을 어떻게 무너뜨리려 하고 있을까요?2부에서는 하드웨어 사양을 넘어, 실제 개발 현장의 이야기로 들어갑니다.<hr data-path-to-node="7"><h3>1. NVIDIA의 제국: 15년 동안 쌓아 올린 "CUDA 해자(Moat)"</h3>오늘날 AI 연구 및 개발의 표준이 NVIDIA GPU인 이유는 단순히 칩의 성능 때문만이 아닙니다. 진짜 이유는 <a data-preview="" href="https://www.google.com/search?ved=1t:260882&amp;q=define+CUDA&amp;bbid=7673110288092522152&amp;bpid=8181871143210177446" target="_blank">CUDA</a>라는 거대한 소프트웨어 생태계에 있습니다.2007년에 출시된 CUDA(Compute Unified Device Architecture)는 개발자가 C++과 유사한 언어로 GPU 코어를 직접 제어할 수 있게 해 주었습니다. 이는 혁명이었습니다. 그래픽 칩을 범용 연산 장치로 사용할 수 있는 문이 열린 것입니다."편안한 길"의 유혹수년 동안 수많은 연구자와 엔지니어가 CUDA를 사용하여 딥러닝에 필요한 기본 연산(행렬 곱셈, 컨볼루션 등)을 최적화했습니다. NVIDIA는 이를 집대성하여 <code><a data-preview="" href="https://www.google.com/search?ved=1t:260882&amp;q=cuBLAS&amp;bbid=7673110288092522152&amp;bpid=8181871143210177446" target="_blank">cuBLAS</a></code>, <code><a data-preview="" href="https://www.google.com/search?ved=1t:260882&amp;q=cuDNN&amp;bbid=7673110288092522152&amp;bpid=8181871143210177446" target="_blank">cuDNN</a></code>과 같은 고도로 최적화된 라이브러리를 제공합니다.대부분의 AI 개발자는 CUDA 코드를 직접 짜지 않습니다. 대신 <a data-preview="" href="https://www.google.com/search?ved=1t:260882&amp;q=define+PyTorch&amp;bbid=7673110288092522152&amp;bpid=8181871143210177446" target="_blank">PyTorch</a>나 <a data-preview="" href="https://www.google.com/search?ved=1t:260882&amp;q=define+TensorFlow&amp;bbid=7673110288092522152&amp;bpid=8181871143210177446" target="_blank">TensorFlow</a> 같은 상위 프레임워크에서 <code>torch.matmul()</code> 같은 함수를 호출합니다. 그러면 프레임워크가 알아서 NVIDIA 엔지니어들이 땀 흘려 깎아 만든 최적의 CUDA 커널을 호출합니다.이것이 바로 NVIDIA의 "해자(Moat)"입니다.<ol data-path-to-node="15" start="1"><li>성숙도: 상상할 수 있는 거의 모든 AI 모델이 GPU에서 즉시 작동합니다. 버그를 만나면 스택오버플로우에 이미 수백 개의 해결책이 있습니다.</li><li>도구: 디버깅, 프로파일링(성능 분석) 도구가 매우 성숙하여 성능 병목 현상을 현미경처럼 들여다볼 수 있습니다.</li><li>인력: 시장에 나온 거의 모든 AI 엔지니어는 GPU 기반 개발 환경에 익숙합니다.</li></ol>GPU를 선택하는 것은 '포장된 도로'를 달리는 것과 같습니다. 통행료(하드웨어 비용)는 비싸지만, 목적지까지 가는 가장 확실하고 편안한 방법입니다.<hr data-path-to-node="17"><h3>2. 패러다임 전환: XLA와 컴파일러 접근 방식</h3>그렇다면 Google은 NVIDIA의 견고한 성벽에 어떻게 도전하고 있을까요? 그들은 완전히 다른 접근 방식을 취했습니다.1부에서 TPU를 "경직된 조립 라인"이라고 표현했습니다. 이 거대한 시스톨릭 어레이를 효율적으로 사용하려면 데이터가 언제 어디로 흘러가야 할지 완벽하게 계획되어야 합니다. 사람이 수동으로 CUDA 커널을 짜듯이 TPU를 제어하는 것은 매우 어렵고 비효율적입니다.그래서 Google은 "컴파일러"에 베팅했습니다. 그 핵심이 바로 XLA(Accelerated Linear Algebra)입니다."어떻게(How)"가 아니라 "무엇을(What)"GPU(CUDA) 방식이 칩에게 "A 메모리에서 데이터를 가져와서, B 코어에서 계산하고, C로 옮겨라"라고 미시적으로 지시하는 것이라면,TPU(XLA) 방식은 칩에게 전체적인 수학 계산 그래프를 던져주고 "이 전체 계산을 수행하는 가장 효율적인 방법을 네가 알아서 찾아내라"고 명령하는 것입니다.XLA 컴파일러는 여러분이 작성한 전체 모델 코드를 분석합니다. 그리고 여러 개의 작은 연산을 하나의 큰 연산으로 합치거나(Operator Fusion), TPU의 메모리 구조에 맞게 데이터 배치를 최적화한 후, TPU가 실행할 수 있는 기계어 코드를 생성합니다.이론적으로 이것은 완벽합니다. 개발자는 하드웨어 세부 사항을 몰라도 되고, 컴파일러가 하드웨어의 성능을 극한까지 짜내주니까요. 하지만 현실은 언제나 더 복잡합니다.<hr data-path-to-node="27"><h3>3. 개발자의 도구 상자: JAX와 PyTorch/XLA</h3>XLA라는 컴파일러 엔진을 사용하기 위해 개발자는 어떤 핸들을 잡아야 할까요?A. JAX: TPU의 모국어 (The Native Way)현재 TPU를 가장 효율적으로 사용하는 방법은 <a href="https://docs.jax.dev/en/latest/notebooks/thinking_in_jax.html" target="_blank">JAX</a> 프레임워크를 사용하는 것입니다. JAX는 Python의 NumPy와 거의 비슷해 보이지만, 사실은 XLA 컴파일러를 위한 아주 얇은 래퍼(Wrapper)입니다.JAX는 "함수형 프로그래밍" 패러다임을 강제합니다. 이는 처음 접하는 개발자에게는 진입 장벽이 될 수 있지만, 컴파일러가 병렬 처리를 최적화하기에는 최상의 조건입니다. Google의 최신 거대 모델들(<a data-preview="" href="https://www.google.com/search?ved=1t:260882&amp;q=Google+Gemini&amp;bbid=7673110288092522152&amp;bpid=8181871143210177446" target="_blank">Gemini</a>, <a data-preview="" href="https://www.google.com/search?ved=1t:260882&amp;q=Google+PaLM&amp;bbid=7673110288092522152&amp;bpid=8181871143210177446" target="_blank">PaLM</a> 등)은 대부분 JAX 기반으로 만들어졌습니다. TPU의 성능을 극한까지 끌어내고 싶다면 JAX가 정답입니다.B. PyTorch/XLA: 타협과 공존 (The Bridge)하지만 전 세계 AI 개발자의 대다수는 PyTorch를 사랑합니다. 그들에게 새로운 언어(JAX)를 배우라고 강요하는 것은 TPU 도입의 큰 장벽이었습니다.그래서 탄생한 것이 <a href="https://docs.pytorch.org/xla/release/r2.8/index.html" target="_blank">PyTorch/XLA</a>입니다. 이는 기존 PyTorch 코드를 거의 그대로 가져와 XLA가 이해할 수 있는 형태로 변환해 주는 다리 역할을 합니다. 초기에는 불안정했지만, 최근 몇 년간 Meta와 Google의 협력으로 비약적인 발전을 이뤘습니다. 이제는 Hugging Face의 수많은 모델을 코드 몇 줄 수정만으로 TPU에서 돌릴 수 있습니다.<hr data-path-to-node="36"><h3>4. 현실 점검: TPU 개발의 날카로운 모서리</h3>XLA와 JAX가 많이 발전했지만, 여전히 GPU 개발 경험만큼 매끄럽지는 않습니다. TPU 도입을 고려할 때 반드시 알아야 할 '고통 포인트'가 있습니다.가장 큰 문제는 "동적 형태(Dynamic Shapes)"에 대한 혐오입니다.XLA 컴파일러는 완벽한 최적화를 위해 입력 데이터의 크기(Shape)를 미리 정확히 알고 싶어 합니다. 만약 들어오는 데이터의 크기가 계속 바뀐다면(예: 길이가 다른 문장을 처리하는 자연어 모델), XLA는 그때마다 새로운 그래프를 다시 컴파일해야 합니다. 이 "재컴파일" 과정은 매우 느려서 전체 학습 속도를 심각하게 저하시킬 수 있습니다.GPU는 유연한 코어 덕분에 이런 동적인 변화에 비교적 둔감하지만, TPU에서는 입력 데이터를 고정된 크기로 맞추는 '패딩(Padding)' 작업 등 추가적인 엔지니어링 노력이 필요할 때가 많습니다.<hr data-path-to-node="42"><h3>요약: 익숙함 vs. 효율성</h3>2부를 요약하자면, 소프트웨어 관점에서의 대결은 다음과 같습니다.<ul data-path-to-node="45"><li>GPU (CUDA): 15년간 다져진 익숙하고 편안한 길. 방대한 커뮤니티와 도구. 어떤 모델이든 당장 돌릴 수 있는 유연함. 하지만 그 대가로 하드웨어 비용이 높습니다.</li><li>TPU (XLA/JAX): 컴파일러가 주도하는 새로운 패러다임. 하드웨어에 맞는 최적화가 필요하고 초기 학습 곡선이 있지만, 조건이 맞으면 압도적인 효율성을 제공합니다.</li></ul><div><table data-path-to-node="1"><thead><tr><td>특징</td><td>CUDA (NVIDIA GPU)</td><td>XLA/JAX (Google TPU/GPU)</td></tr></thead><tbody><tr><td>기본 철학</td><td>명시적 제어 (Imperative): 개발자가 하드웨어 동작 방식(스레드, 메모리)을 직접 코딩</td><td>선언적 &amp; 컴파일러 기반 (Declarative): 개발자가 수학적 계산 그래프를 정의하면 컴파일러가 최적화</td></tr><tr><td>핵심 방식</td><td>커널(Kernel) 기반: 작은 연산 단위(커널)를 순차적으로 실행.</td><td>전체 그래프 최적화: 전체 계산 그래프를 분석하여 연산 융합(Fusion) 및 최적화 수행.</td></tr><tr><td>주요 장점</td><td>극강의 유연성 &amp; 성숙도: 어떤 복잡한 로직도 구현 가능. 방대한 라이브러리(cuDNN 등)와 커뮤니티.</td><td>자동 최적화 &amp; 효율성: 하드웨어 전문 지식 없이도 높은 성능 달성 가능. 연산 융합을 통한 메모리 대역폭 절약.</td></tr><tr><td>주요 단점</td><td>높은 난이도: 성능 최적화를 위해 하드웨어 구조에 대한 깊은 이해 필요.</td><td>동적 실행에 취약: 입력 크기나 로직이 동적으로 변할 경우 잦은 재컴파일로 인한 성능 저하 발생 가능.</td></tr><tr><td>개발자 경험</td><td>C/C++ 확장 코딩 또는 고수준 프레임워크(PyTorch)의 추상화된 API 사용.</td><td>Python(NumPy 스타일)으로 작성하며, 함수형 프로그래밍 패러다임에 익숙해져야 함.</td></tr><tr><td>주 사용 하드웨어</td><td>모든 NVIDIA GPU</td><td>Google TPU (주력), NVIDIA/AMD GPU (지원)</td></tr><tr><td>비유</td><td>수동 변속기 스포츠카: 숙련된 드라이버에게 최고의 성능 제공.</td><td>자율 주행 자동차: 목적지만 입력하면 알아서 최적 경로로 주행.</td></tr></tbody></table></div>이제 우리는 하드웨어의 차이(1부)와 소프트웨어 개발 환경의 차이(2부)를 모두 이해했습니다.마지막 3부에서는 이 모든 정보를 종합하여 최종 결정을 내리는 단계로 넘어갑니다. 성능 벤치마크, 비용 효율성등을 살펴보겠습니다.</div></div>

Blog for Android & IT

1부: 아키텍처 차이점
에서 우리는 GPU와 TPU의 물리적 본질을 파헤쳤습니다. GPU는 유연한 병렬 처리를 위한 수천 개의 독립적인 코어(스위스 아미 나이프)이고, TPU는 행렬 연산에 극도로 최적화된 거대한 시스톨릭 어레이(레이저 커터)입니다.
하지만 하드웨어는 엔진일 뿐입니다. 그 엔진을 움직이려면 운전대와 페달, 즉 소프트웨어가 필요합니다.
아무리 강력한 칩이라도 개발자가 프로그래밍할 수 없다면 무용지물입니다. 바로 이 지점에서 AI 인프라의 가장 치열한 전투가 벌어지고 있습니다. 엔지니어 입장에서 GPU와 TPU를 다루는 경험은 어떻게 다를까요? 왜 수많은 기업이 여전히 비싼 NVIDIA GPU를 고집할까요? 그리고 Google은 이 견고한 성벽을 어떻게 무너뜨리려 하고 있을까요?
2부에서는 하드웨어 사양을 넘어, 실제 개발 현장의 이야기로 들어갑니다.
1. NVIDIA의 제국: 15년 동안 쌓아 올린 "CUDA 해자(Moat)"
오늘날 AI 연구 및 개발의 표준이 NVIDIA GPU인 이유는 단순히 칩의 성능 때문만이 아닙니다. 진짜 이유는 CUDA라는 거대한 소프트웨어 생태계에 있습니다.
2007년에 출시된 CUDA(Compute Unified Device Architecture)는 개발자가 C++과 유사한 언어로 GPU 코어를 직접 제어할 수 있게 해 주었습니다. 이는 혁명이었습니다. 그래픽 칩을 범용 연산 장치로 사용할 수 있는 문이 열린 것입니다.
"편안한 길"의 유혹
수년 동안 수많은 연구자와 엔지니어가 CUDA를 사용하여 딥러닝에 필요한 기본 연산(행렬 곱셈, 컨볼루션 등)을 최적화했습니다. NVIDIA는 이를 집대성하여 cuBLAS, cuDNN과 같은 고도로 최적화된 라이브러리를 제공합니다.
대부분의 AI 개발자는 CUDA 코드를 직접 짜지 않습니다. 대신 PyTorch나 TensorFlow 같은 상위 프레임워크에서 torch.matmul() 같은 함수를 호출합니다. 그러면 프레임워크가 알아서 NVIDIA 엔지니어들이 땀 흘려 깎아 만든 최적의 CUDA 커널을 호출합니다.
이것이 바로 NVIDIA의 "해자(Moat)"입니다.
성숙도: 상상할 수 있는 거의 모든 AI 모델이 GPU에서 즉시 작동합니다. 버그를 만나면 스택오버플로우에 이미 수백 개의 해결책이 있습니다.
도구: 디버깅, 프로파일링(성능 분석) 도구가 매우 성숙하여 성능 병목 현상을 현미경처럼 들여다볼 수 있습니다.
인력: 시장에 나온 거의 모든 AI 엔지니어는 GPU 기반 개발 환경에 익숙합니다.
GPU를 선택하는 것은 '포장된 도로'를 달리는 것과 같습니다. 통행료(하드웨어 비용)는 비싸지만, 목적지까지 가는 가장 확실하고 편안한 방법입니다.
2. 패러다임 전환: XLA와 컴파일러 접근 방식
그렇다면 Google은 NVIDIA의 견고한 성벽에 어떻게 도전하고 있을까요? 그들은 완전히 다른 접근 방식을 취했습니다.
1부에서 TPU를 "경직된 조립 라인"이라고 표현했습니다. 이 거대한 시스톨릭 어레이를 효율적으로 사용하려면 데이터가 언제 어디로 흘러가야 할지 완벽하게 계획되어야 합니다. 사람이 수동으로 CUDA 커널을 짜듯이 TPU를 제어하는 것은 매우 어렵고 비효율적입니다.
그래서 Google은 "컴파일러"에 베팅했습니다. 그 핵심이 바로 XLA(Accelerated Linear Algebra)입니다.
"어떻게(How)"가 아니라 "무엇을(What)"
GPU(CUDA) 방식이 칩에게 "A 메모리에서 데이터를 가져와서, B 코어에서 계산하고, C로 옮겨라"라고 미시적으로 지시하는 것이라면,
TPU(XLA) 방식은 칩에게 전체적인 수학 계산 그래프를 던져주고 "이 전체 계산을 수행하는 가장 효율적인 방법을 네가 알아서 찾아내라"고 명령하는 것입니다.
XLA 컴파일러는 여러분이 작성한 전체 모델 코드를 분석합니다. 그리고 여러 개의 작은 연산을 하나의 큰 연산으로 합치거나(Operator Fusion), TPU의 메모리 구조에 맞게 데이터 배치를 최적화한 후, TPU가 실행할 수 있는 기계어 코드를 생성합니다.
이론적으로 이것은 완벽합니다. 개발자는 하드웨어 세부 사항을 몰라도 되고, 컴파일러가 하드웨어의 성능을 극한까지 짜내주니까요. 하지만 현실은 언제나 더 복잡합니다.
3. 개발자의 도구 상자: JAX와 PyTorch/XLA
XLA라는 컴파일러 엔진을 사용하기 위해 개발자는 어떤 핸들을 잡아야 할까요?
A. JAX: TPU의 모국어 (The Native Way)
현재 TPU를 가장 효율적으로 사용하는 방법은 JAX 프레임워크를 사용하는 것입니다. JAX는 Python의 NumPy와 거의 비슷해 보이지만, 사실은 XLA 컴파일러를 위한 아주 얇은 래퍼(Wrapper)입니다.
JAX는 "함수형 프로그래밍" 패러다임을 강제합니다. 이는 처음 접하는 개발자에게는 진입 장벽이 될 수 있지만, 컴파일러가 병렬 처리를 최적화하기에는 최상의 조건입니다. Google의 최신 거대 모델들(Gemini, PaLM 등)은 대부분 JAX 기반으로 만들어졌습니다. TPU의 성능을 극한까지 끌어내고 싶다면 JAX가 정답입니다.
B. PyTorch/XLA: 타협과 공존 (The Bridge)
하지만 전 세계 AI 개발자의 대다수는 PyTorch를 사랑합니다. 그들에게 새로운 언어(JAX)를 배우라고 강요하는 것은 TPU 도입의 큰 장벽이었습니다.
그래서 탄생한 것이 PyTorch/XLA입니다. 이는 기존 PyTorch 코드를 거의 그대로 가져와 XLA가 이해할 수 있는 형태로 변환해 주는 다리 역할을 합니다. 초기에는 불안정했지만, 최근 몇 년간 Meta와 Google의 협력으로 비약적인 발전을 이뤘습니다. 이제는 Hugging Face의 수많은 모델을 코드 몇 줄 수정만으로 TPU에서 돌릴 수 있습니다.
4. 현실 점검: TPU 개발의 날카로운 모서리
XLA와 JAX가 많이 발전했지만, 여전히 GPU 개발 경험만큼 매끄럽지는 않습니다. TPU 도입을 고려할 때 반드시 알아야 할 '고통 포인트'가 있습니다.
가장 큰 문제는 "동적 형태(Dynamic Shapes)"에 대한 혐오입니다.
XLA 컴파일러는 완벽한 최적화를 위해 입력 데이터의 크기(Shape)를 미리 정확히 알고 싶어 합니다. 만약 들어오는 데이터의 크기가 계속 바뀐다면(예: 길이가 다른 문장을 처리하는 자연어 모델), XLA는 그때마다 새로운 그래프를 다시 컴파일해야 합니다. 이 "재컴파일" 과정은 매우 느려서 전체 학습 속도를 심각하게 저하시킬 수 있습니다.
GPU는 유연한 코어 덕분에 이런 동적인 변화에 비교적 둔감하지만, TPU에서는 입력 데이터를 고정된 크기로 맞추는 '패딩(Padding)' 작업 등 추가적인 엔지니어링 노력이 필요할 때가 많습니다.
요약: 익숙함 vs. 효율성
2부를 요약하자면, 소프트웨어 관점에서의 대결은 다음과 같습니다.
GPU (CUDA): 15년간 다져진 익숙하고 편안한 길. 방대한 커뮤니티와 도구. 어떤 모델이든 당장 돌릴 수 있는 유연함. 하지만 그 대가로 하드웨어 비용이 높습니다.
TPU (XLA/JAX): 컴파일러가 주도하는 새로운 패러다임. 하드웨어에 맞는 최적화가 필요하고 초기 학습 곡선이 있지만, 조건이 맞으면 압도적인 효율성을 제공합니다.
특징CUDA (NVIDIA GPU)XLA/JAX (Google TPU/GPU)
기본 철학명시적 제어 (Imperative): 개발자가 하드웨어 동작 방식(스레드, 메모리)을 직접 코딩선언적 & 컴파일러 기반 (Declarative): 개발자가 수학적 계산 그래프를 정의하면 컴파일러가 최적화
핵심 방식커널(Kernel) 기반: 작은 연산 단위(커널)를 순차적으로 실행.전체 그래프 최적화: 전체 계산 그래프를 분석하여 연산 융합(Fusion) 및 최적화 수행.
주요 장점극강의 유연성 & 성숙도: 어떤 복잡한 로직도 구현 가능. 방대한 라이브러리(cuDNN 등)와 커뮤니티.자동 최적화 & 효율성: 하드웨어 전문 지식 없이도 높은 성능 달성 가능. 연산 융합을 통한 메모리 대역폭 절약.
주요 단점높은 난이도: 성능 최적화를 위해 하드웨어 구조에 대한 깊은 이해 필요.동적 실행에 취약: 입력 크기나 로직이 동적으로 변할 경우 잦은 재컴파일로 인한 성능 저하 발생 가능.
개발자 경험C/C++ 확장 코딩 또는 고수준 프레임워크(PyTorch)의 추상화된 API 사용.Python(NumPy 스타일)으로 작성하며, 함수형 프로그래밍 패러다임에 익숙해져야 함.
주 사용 하드웨어모든 NVIDIA GPUGoogle TPU (주력), NVIDIA/AMD GPU (지원)
비유수동 변속기 스포츠카: 숙련된 드라이버에게 최고의 성능 제공.자율 주행 자동차: 목적지만 입력하면 알아서 최적 경로로 주행.
이제 우리는 하드웨어의 차이(1부)와 소프트웨어 개발 환경의 차이(2부)를 모두 이해했습니다.
마지막 3부에서는 이 모든 정보를 종합하여 최종 결정을 내리는 단계로 넘어갑니다. 성능 벤치마크, 비용 효율성등을 살펴보겠습니다.

AI 실리콘 전쟁, 2부: CUDA 해자(Moat) vs. XLA 혁명—GPU와 TPU 개발의 실제

댓글