17. AI Frameworks 단계별 학습 문서

원문 경로

/Users/keumky/Documents/New project 3/sources/mlsysbook/17-frameworks/source.md

짧은 소개

이 장은 TensorFlow, PyTorch, JAX 같은 머신러닝 프레임워크가 왜 필요한지 설명해요. 프레임워크는 단순히 모델 코드를 편하게 쓰는 도구가 아니라, 수학적 모델을 실제 하드웨어에서 빠르고 안정적으로 실행하게 해주는 핵심 소프트웨어 계층입니다.

특히 이 장은 계산 그래프, 자동 미분, 텐서, 실행 방식, 하드웨어 최적화, 배포 환경별 프레임워크 선택까지 연결해서 다뤄요. 그래서 프레임워크를 “라이브러리”가 아니라 “AI 시스템을 움직이는 기반 구조”로 보는 것이 중요해요.

읽는 방법

처음부터 모든 세부 구현을 외우려고 하면 어렵습니다. 이 장은 세 번에 나누어 읽는 방식이 좋아요.

읽을 때는 다음 흐름을 계속 기억하면 좋아요.

모델 아이디어
  -> 텐서로 숫자 데이터를 표현
  -> 계산 그래프로 연산 관계를 표현
  -> 자동 미분으로 기울기 계산
  -> 실행 모델이 CPU/GPU/TPU에 맞게 최적화
  -> 훈련, 추론, 배포 환경에 맞는 프레임워크 선택

이 장의 한 줄 요약

머신러닝 프레임워크는 수학적 모델을 텐서, 계산 그래프, 자동 미분, 하드웨어 실행, 배포 생태계로 연결해 주는 AI 시스템의 핵심 추상화 계층입니다.

1단계: 중학교 수준

프레임워크는 AI 개발용 주방이에요

요리를 할 때 재료만 있다고 바로 훌륭한 음식을 만들기는 어렵죠. 칼, 냄비, 도마, 불 조절 장치, 레시피가 필요해요.

AI 개발도 비슷해요. 데이터와 아이디어만 있다고 바로 큰 모델을 만들 수는 없어요. 숫자를 담는 그릇, 계산 순서를 정리하는 방법, 실수를 줄이는 도구, 빠른 기계에 일을 맡기는 장치가 필요해요. 이것들을 모아 둔 작업 공간이 머신러닝 프레임워크입니다.

프레임워크는 복잡한 계산을 대신 정리해줘요

AI 모델은 아주 많은 숫자를 다뤄요. 사람이 직접 모든 숫자의 움직임을 따라가려면 너무 복잡합니다.

프레임워크는 이런 일을 대신 해줘요.

계산 그래프는 요리 순서표와 비슷해요

라면을 끓일 때 물을 끓이고, 면을 넣고, 스프를 넣고, 기다리는 순서가 있죠. 순서가 틀리면 결과가 이상해져요.

AI 모델도 마찬가지예요. 입력 데이터가 들어오면 여러 계산 단계를 지나 결과가 나와요. 프레임워크는 이 계산 순서를 지도처럼 정리해서 어떤 일을 먼저 하고, 어떤 일을 나중에 해야 하는지 알아냅니다.

자동 미분은 틀린 이유를 찾아주는 도우미예요

모델이 답을 틀렸다고 해볼게요. 중요한 것은 “틀렸다”에서 끝나는 것이 아니라, 어디를 얼마나 고쳐야 하는지 아는 거예요.

자동 미분은 마치 선생님이 시험지를 보고 “이 부분을 조금 더 고치면 점수가 올라가요”라고 알려주는 것과 비슷해요. 개발자가 모든 계산을 손으로 고치지 않아도, 프레임워크가 모델 안의 많은 숫자를 어떤 방향으로 바꿔야 할지 계산해줘요.

프레임워크마다 성격이 달라요

모든 도구가 같은 일에 좋은 것은 아니에요. 연필은 스케치에 좋고, 붓은 그림에 좋고, 자는 직선을 그을 때 좋아요.

프레임워크도 성격이 달라요.

1단계 중간 정리

프레임워크는 AI 모델을 만드는 사람 대신 복잡한 계산 순서, 숫자 관리, 학습 방향, 빠른 실행, 실제 배포를 도와주는 도구 모음이에요. 이 장의 핵심은 “프레임워크 선택은 문법 취향이 아니라 시스템 선택”이라는 점입니다.

2단계: 고등학교 수준

큰 흐름: 입력에서 배포까지

이제 비유를 조금 벗겨볼게요. 프레임워크 안에서는 보통 다음 순서로 일이 진행돼요.

데이터 입력
  -> 텐서로 변환
  -> 모델 연산 수행
  -> 예측값 계산
  -> 손실 계산
  -> 자동 미분으로 기울기 계산
  -> 파라미터 업데이트
  -> 저장 또는 배포

여기서 핵심은 모델이 결국 많은 함수를 연결한 구조라는 점이에요. 입력값을 넣으면 예측값이 나오고, 예측값과 정답의 차이를 줄이도록 내부 숫자를 바꿔요.

텐서는 숫자 배열의 일반화예요

프레임워크는 대부분의 데이터를 텐서로 다뤄요.

텐서는 단순한 숫자 상자가 아니에요. 모양, 숫자 정밀도, 어느 장치에 올라가 있는지, 메모리에 어떤 순서로 저장되는지 같은 정보도 함께 가져요.

계산 그래프는 함수 연결 지도예요

간단한 모델을 다음처럼 볼 수 있어요.

입력 x
  -> 가중치 w와 결합
  -> 편향 b 더하기
  -> 활성화 함수 통과
  -> 예측 y
  -> 정답과 비교해 손실 계산

고등학교 수준으로 보면 모델은 대략 다음 관계를 계속 확장한 것과 비슷해요.

$$ y = wx + b $$

여기서 x는 입력, w는 중요도를 나타내는 가중치, b는 기준점을 옮기는 값, y는 예측값이에요. 딥러닝 모델은 이런 단순한 관계를 아주 많이 쌓고, 중간에 비선형 변환을 넣어서 복잡한 패턴을 배워요.

계산 그래프는 이 함수들이 어떤 순서로 연결되어 있는지 보여줘요. 그래프가 있으면 프레임워크는 다음을 판단할 수 있어요.

• 어떤 계산을 먼저 해야 하는지
• 어떤 계산은 동시에 해도 되는지
• 어떤 중간값을 나중에 다시 써야 하는지
• 어떤 연산을 하나로 합치면 더 빠른지
• 기울기를 어떤 순서로 거꾸로 계산해야 하는지

자동 미분은 오차를 줄이는 방향을 계산해요

학습의 목표는 손실을 줄이는 거예요. 손실은 예측이 정답과 얼마나 다른지 나타내는 값입니다.

손실을 $L$이라고 하면, 프레임워크는 각 파라미터가 손실에 얼마나 영향을 주는지 계산해요.

$$ \frac{\partial L}{\partial w} $$

이 값은 “가중치 $w$를 조금 바꾸면 손실 $L$이 얼마나 변하는가”를 뜻해요. 값이 크면 그 가중치가 손실에 큰 영향을 주고 있다는 뜻입니다.

프레임워크는 계산 그래프를 따라 앞으로 계산한 뒤, 거꾸로 돌아오면서 기울기를 계산해요.

순전파: 입력 -> 예측 -> 손실
역전파: 손실 -> 각 연산의 기울기 -> 파라미터 수정 방향

정적 그래프와 동적 그래프

프레임워크의 실행 방식은 크게 두 가지로 생각할 수 있어요.

현대 프레임워크는 둘 중 하나만 고집하지 않아요. 개발할 때는 즉시 실행으로 편하게 실험하고, 성능이 필요한 부분은 컴파일이나 그래프 변환으로 최적화하는 혼합 방식을 많이 사용해요.

하드웨어가 프레임워크 설계를 바꿔요

CPU, GPU, TPU, 모바일 NPU는 계산을 잘하는 방식이 달라요. 그래서 프레임워크는 같은 모델이라도 어느 장치에서 실행하느냐에 따라 다른 최적화를 해야 해요.

예를 들어 큰 행렬 곱셈은 GPU나 TPU에서 매우 빠를 수 있어요. 하지만 작은 연산을 너무 자주 나누어 실행하면 메모리 이동 비용이 커져서 느려질 수 있어요. 그래서 프레임워크는 여러 연산을 합치는 operation fusion, 숫자 정밀도를 낮추는 quantization, 메모리를 미리 계획하는 memory planning 같은 전략을 씁니다.

2단계 중간 정리

프레임워크는 다음 네 가지 질문에 답하는 시스템이에요.

3단계: 대학교 수준

3.1 Purpose: 프레임워크는 핵심 추상화 계층이에요

원문은 프레임워크를 “이론과 실제 구현 사이의 다리”로 설명해요. 머신러닝 이론은 선형대수, 최적화, 미분으로 표현되지만, 실제 시스템에서는 이것을 실행 가능한 코드로 바꾸어야 해요. 이때 CPU, GPU, TPU, 분산 클러스터, 모바일 칩 같은 서로 다른 하드웨어까지 고려해야 합니다.

프레임워크가 없다면 매 프로젝트마다 다음을 직접 구현해야 해요.

• 텐서 연산
• 행렬 곱셈과 convolution
• 자동 미분
• 메모리 할당과 해제
• GPU/TPU 커널 호출
• 분산 학습 통신
• 모델 저장, 변환, 배포

현대 딥러닝은 수백만에서 수십억 개의 파라미터를 다루기 때문에, 이런 구현을 손으로 반복하는 것은 경제적으로도 기술적으로도 어렵습니다. 그래서 프레임워크 선택은 단순한 개발 편의가 아니라 성능, 확장성, 배포 가능성, 유지보수성을 결정하는 아키텍처 결정이 됩니다.

3.2 Framework Abstraction and Necessity: 왜 추상화가 필요한가요?

딥러닝 모델의 훈련은 크게 순전파와 역전파로 구성돼요. 순전파에서는 입력 데이터가 여러 층을 통과하며 예측을 만들고, 역전파에서는 손실에서 출발해 각 파라미터의 기울기를 계산해요.

이 과정은 수학적으로는 명확하지만, 시스템 구현은 복잡합니다.

추상화의 핵심은 개발자가 모델 구조에 집중하게 하면서도, 하위 계층에서는 효율적인 실행을 유지하는 것입니다. 하지만 추상화는 성능 한계도 만들 수 있어요. 프레임워크의 그래프 표현, 메모리 전략, 병렬화 방식, 하드웨어 추상화가 시스템 전체의 한계를 정하기 때문입니다.

3.3 Historical Development Trajectory: 프레임워크의 진화

프레임워크는 갑자기 등장한 것이 아니라, 수치 계산 라이브러리에서 딥러닝 플랫폼으로 단계적으로 발전했어요.

BLAS와 LAPACK은 지금도 현대 프레임워크의 깊은 하위 계층에서 중요한 역할을 해요. 신경망의 많은 계산은 결국 행렬-행렬 곱셈, 행렬-벡터 곱셈, 분해, 선형 시스템 풀이 같은 연산으로 내려가기 때문입니다.

NumPy는 n차원 배열을 Python에서 자연스럽게 다루게 했고, SciPy는 최적화와 과학 계산 기능을 더했어요. Scikit-learn은 이 수치 계산 기반 위에 분류, 회귀, 군집화 같은 전통적 머신러닝 알고리즘을 사용하기 쉬운 API로 만들었습니다.

딥러닝 시대로 넘어오면서 Theano는 계산 그래프와 GPU 가속을 중요한 개념으로 제시했어요. Caffe는 convolution 연산을 컴퓨터 비전 모델에 맞게 최적화했고, Torch는 즉시 실행에 가까운 개발 경험을 강조했어요. TensorFlow는 정적 계산 그래프와 분산 실행을 통해 대규모 production 시스템을 겨냥했고, PyTorch는 동적 그래프와 Python 친화적 디버깅으로 연구 생산성을 크게 높였어요. JAX는 NumPy 스타일 API에 함수형 변환, 자동 미분, JIT 컴파일을 결합했습니다.

3.4 Hardware-Driven Framework Architecture Evolution: 하드웨어가 만든 변화

원문은 프레임워크 발전이 하드웨어 발전과 강하게 연결되어 있다고 설명해요. CUDA가 등장하면서 GPU를 범용 행렬 계산에 사용할 수 있게 되었고, 딥러닝 훈련 속도는 크게 달라졌습니다.

GPU는 많은 계산을 병렬로 처리하는 데 강해요. 큰 행렬 곱셈처럼 계산량이 많은 작업은 GPU에서 높은 효율을 낼 수 있습니다. 하지만 activation 함수처럼 각 원소에 독립적으로 적용되는 작은 연산은 메모리에서 데이터를 읽고 쓰는 비용이 더 커질 수 있어요. 그래서 프레임워크는 여러 작은 연산을 하나의 커널로 합치는 kernel fusion을 사용합니다.

TPU는 tensor 연산에 특화된 가속기예요. 특히 systolic array 구조를 사용해 행렬 곱셈과 convolution을 효율적으로 처리합니다. TPU를 잘 활용하려면 프레임워크가 고수준 연산을 TPU가 좋아하는 조밀한 행렬 연산으로 변환해야 해요.

모바일 NPU와 Apple Neural Engine, Qualcomm NPU 같은 장치는 전력 효율이 중요합니다. 이 환경에서는 FP32보다 INT8 같은 낮은 정밀도 연산이 유리할 수 있어요. 따라서 프레임워크는 mixed precision, quantization, sparse computation을 지원해야 합니다.

ASIC, FPGA, Graphcore, Cerebras, SambaNova 같은 특수 하드웨어가 등장하면서 프레임워크는 중간 표현(IR)을 더 중요하게 사용하게 되었어요. IR은 사용자 코드와 하드웨어별 기계 코드 사이에 있는 표현입니다. 같은 모델을 여러 장치에 맞게 최적화하려면 IR이 필요합니다.

3.5 Fundamental Concepts: 네 개의 계층

원문은 현대 프레임워크를 네 계층으로 설명해요.

이 네 계층은 따로 움직이지 않아요. 계산 그래프가 연산 의존성을 제공하면, 데이터 계층은 텐서와 메모리를 관리하고, 개발자 인터페이스는 이를 사용하기 쉬운 API로 감싸며, 실행 계층은 실제 하드웨어에 맞게 최적화합니다.

3.6 Computational Graphs: 계산 그래프

계산 그래프는 모델의 연산과 데이터 흐름을 방향성 있는 그래프로 표현하는 구조예요. 노드는 연산이고, 간선은 데이터 의존성입니다. 원문은 이를 DAG, 즉 순환이 없는 방향 그래프로 설명해요.

예를 들어 행렬 곱셈, bias 더하기, ReLU, normalization, pooling은 모두 그래프의 노드가 될 수 있어요. 텐서는 노드 사이를 이동하는 데이터입니다.

계산 그래프가 중요한 이유는 네 가지예요.

• 자동 미분을 가능하게 해요.
• 어떤 연산이 어떤 값에 의존하는지 알 수 있어요.
• 병렬 실행과 device placement를 분석할 수 있어요.
• 모델 저장, 변환, 배포를 위한 중간 표현이 될 수 있어요.

신경망 그림과 계산 그래프는 다릅니다. 신경망 그림은 사람이 구조를 이해하기 위한 그림에 가깝고, 계산 그래프는 프레임워크가 실제로 실행과 미분과 최적화를 하기 위해 사용하는 정밀한 수학적 표현입니다.

정적 계산 그래프

정적 그래프는 define-then-run 방식이에요. 실행 전에 전체 연산 구조를 먼저 정의합니다. 이 방식의 장점은 전체 그래프를 미리 볼 수 있다는 점이에요.

전체 구조를 알면 프레임워크는 다음 최적화를 할 수 있어요.

• 중복 연산 제거
• kernel fusion
• memory planning
• device placement 최적화
• XLA 같은 컴파일러 기반 최적화
• 반복 실행을 위한 그래프 직렬화

단점도 있어요. 실행 중 조건문이나 입력 길이에 따라 구조가 바뀌는 모델은 표현하기가 어렵고, 디버깅할 때 중간값을 즉시 확인하기가 불편할 수 있습니다.

동적 계산 그래프

동적 그래프는 define-by-run 방식이에요. 코드를 실행하면서 그래프가 만들어집니다. PyTorch가 이 방식을 널리 알렸어요.

동적 그래프는 Python의 조건문, 반복문, 변수 길이 입력과 잘 맞습니다. 실행 즉시 결과를 확인할 수 있으므로 디버깅과 연구 실험에 매우 유리해요.

하지만 전체 그래프를 미리 알 수 없기 때문에 정적 그래프만큼 공격적인 전역 최적화를 하기 어렵습니다. 런타임에 메모리를 할당하므로 장시간 실행에서는 fragmentation이 생길 수도 있어요.

그래프와 gradient 계산

계산 그래프는 역방향 자동 미분의 핵심 자료구조입니다. 순전파 중에는 각 연산 결과와 backward에 필요한 정보를 저장해요. backward가 호출되면 프레임워크는 그래프를 역위상 순서로 거꾸로 순회하며 chain rule을 적용합니다.

중요한 점은 gradient 계산량이 변수 조합 수처럼 폭발하지 않고, 그래프의 연산 수에 거의 비례하도록 관리된다는 것입니다. 의존성이 그래프에 기록되어 있기 때문에 각 기울기를 필요한 순서에 맞게 누적할 수 있어요.

3.7 Automatic Differentiation: 자동 미분

자동 미분은 컴퓨터 프로그램으로 작성된 함수를 작은 기본 연산으로 나누고, 각 연산에 chain rule을 적용해 정확한 기울기를 계산하는 방법입니다.

수치 미분은 작은 변화량을 넣어 근사하지만, 자동 미분은 연산 규칙을 따라 기계 정밀도 수준의 도함수를 계산해요. 딥러닝에서는 손실이 보통 하나의 스칼라이고, 파라미터는 매우 많기 때문에 reverse mode 자동 미분이 특히 중요합니다.

Forward mode

Forward mode는 값과 그 값의 미분 정보를 함께 앞으로 전달해요. 입력이 적고 출력이 많은 함수에 유리합니다.

개념적으로는 각 값이 다음 쌍을 들고 이동하는 것과 비슷해요.

$$ (\text{value}, \text{derivative}) $$

장점은 메모리 사용량이 비교적 일정하다는 점입니다. 중간값을 많이 보관하지 않아도 돼요. 그래서 입력 변화가 출력에 어떻게 퍼지는지 보는 민감도 분석, saliency, 일부 온라인 학습 상황에서 유용할 수 있습니다.

단점은 많은 입력 변수 각각에 대한 기울기를 구해야 할 때 계산 비용이 커진다는 점입니다. 신경망 파라미터가 수백만 개라면 forward mode만으로 전체 gradient를 구하는 것은 비효율적이에요.

Reverse mode

Reverse mode는 먼저 순전파로 값을 계산하고, 이후 출력에서 입력 방향으로 거꾸로 기울기를 전파합니다.

딥러닝 훈련에서는 손실 $L$이 하나이고, 파라미터 $\theta$가 매우 많아요. 우리가 원하는 것은 다음과 같은 값입니다.

$$ \nabla_\theta L $$

즉, 모든 파라미터에 대한 손실의 기울기예요. Reverse mode는 하나의 backward pass로 많은 파라미터에 대한 gradient를 효율적으로 계산할 수 있어 딥러닝 훈련의 기본 방식이 됩니다.

다만 reverse mode는 순전파 중간값을 저장해야 해요. 예를 들어 어떤 layer의 출력은 backward에서 그 layer의 gradient를 계산할 때 필요합니다. 그래서 깊은 네트워크에서는 activation memory가 매우 커질 수 있습니다.

자동 미분의 메모리 최적화

프레임워크는 reverse mode의 메모리 부담을 줄이기 위해 여러 전략을 사용해요.

원문은 gradient checkpointing이 메모리를 크게 줄일 수 있지만 훈련 시간이 늘어날 수 있다고 설명해요. 이는 메모리와 계산 시간 사이의 전형적인 trade-off입니다.

프레임워크별 자동 미분 전략

PyTorch는 실행 중 연산을 기록하는 dynamic tape 기반 autograd를 사용해요. 자연스러운 Python control flow와 잘 맞고, backward 후 gradient를 바로 확인할 수 있어 연구와 디버깅에 좋습니다. 대신 전체 그래프 최적화에는 추가 컴파일 경로가 필요할 수 있어요.

TensorFlow의 전통적 방식은 정적 그래프 분석을 바탕으로 gradient 그래프까지 최적화하는 접근이었어요. TensorFlow 2.x는 eager execution을 기본으로 하지만, 그래프 컴파일 기능을 통해 production 최적화를 유지합니다.

JAX는 함수형 프로그래밍과 program transformation을 중심으로 자동 미분을 제공합니다. grad, jit, vmap, pmap 같은 변환을 조합할 수 있어요. 대신 순수 함수와 불변 데이터 구조에 익숙해야 합니다.

3.8 Data Structures: 텐서와 특수 자료구조

프레임워크의 데이터 구조는 숫자를 담는 역할과 시스템 메모리를 관리하는 역할을 동시에 합니다.

텐서

텐서는 scalar, vector, matrix를 더 높은 차원으로 일반화한 자료구조예요. 하지만 프레임워크의 텐서는 수학적 배열 이상의 정보를 가집니다.

메모리는 실제로 일렬로 저장되기 때문에, 2차원이나 4차원 텐서를 어떻게 선형 주소에 매핑할지가 중요합니다. row-major와 column-major는 접근 패턴이 다르고, stride는 다차원 인덱스가 실제 메모리 주소로 변환되는 방식을 나타내요.

숫자 정밀도도 중요해요. FP32는 안정적인 훈련에 자주 쓰이고, FP16이나 BF16은 GPU/TPU에서 빠른 훈련에 사용됩니다. INT8은 추론에서 메모리와 전력 사용을 크게 줄일 수 있어요. 다만 낮은 정밀도는 오차와 정확도 손실을 만들 수 있으므로 mixed precision과 quantization 정책이 필요합니다.

도메인별 자료구조

텐서만으로 전체 ML 워크플로를 처리할 수는 없어요. 원문은 dataset, parameter, execution 구조를 함께 설명합니다.

Dataset 구조가 느리면 GPU가 계산할 준비를 마치고도 데이터를 기다리게 됩니다. 그래서 parallel loading, caching, prefetching, shuffling이 중요해요.

Parameter 구조는 분산 학습에서 더 복잡해집니다. 여러 GPU가 같은 모델 복사본을 갖고 각자 gradient를 계산한 뒤, 이를 동기화해야 해요. 큰 모델에서는 gradient 통신량이 매우 커지므로 압축, all-reduce, sharding 같은 기법이 필요합니다.

Execution 구조는 중간 activation, gradient, 임시 buffer의 수명을 관리합니다. 어떤 값은 backward가 끝나면 지워도 되고, 어떤 값은 여러 연산에서 공유되므로 더 오래 보관해야 해요.

3.9 Programming and Execution Models: 프로그래밍 방식과 실행 방식

원문은 개발자가 코드를 쓰는 방식과 프레임워크가 실행하는 방식이 밀접하게 연결되어 있다고 설명해요.

Symbolic 방식은 전체 계산 구조를 미리 알 수 있어 memory reuse, operation fusion, kernel selection에 유리합니다. 하지만 개발자는 전체 그래프를 머릿속에 두고 작업해야 하며, 오류가 실행 시점에 드러나는 경우가 많아요.

Imperative 방식은 일반 Python처럼 한 줄씩 실행되므로 중간 텐서 값을 바로 볼 수 있어요. 강화학습, 가변 길이 sequence, 조건 분기가 많은 모델에 편합니다. 대신 런타임에 그래프가 생기므로 전체 최적화 범위가 제한됩니다.

JIT는 이 둘 사이의 절충입니다. TensorFlow의 graph 변환, PyTorch의 컴파일 경로, JAX의 jit처럼 자주 실행되는 계산을 잡아 최적화된 그래프로 바꿀 수 있어요. 첫 실행에는 컴파일 비용이 있지만, 이후 반복 실행에서 성능 이득을 얻을 수 있습니다.

분산 실행

모델과 데이터가 커지면 한 장치에서 훈련할 수 없어요. 프레임워크는 data parallelism과 model parallelism을 제공합니다.

Data parallelism은 각 장치가 mini-batch 일부를 처리한 뒤 gradient를 합칩니다. PyTorch의 분산 데이터 병렬, TensorFlow의 분산 전략, JAX의 병렬 실행 기능이 이런 복잡성을 추상화해요.

Model parallelism은 모델이 너무 커서 한 장치 메모리에 들어가지 않을 때 필요합니다. layer를 나누는 pipeline parallelism, weight를 나누는 tensor parallelism, optimizer state까지 나누는 sharding 방식이 있습니다. 원문은 DeepSpeed와 Megatron-LM 같은 도구가 이런 고급 병렬화를 PyTorch 위에서 확장한다고 설명해요.

3.10 Core Operations: 핵심 연산 계층

프레임워크의 고수준 API는 결국 하드웨어에서 실행되는 핵심 연산으로 내려갑니다. 원문은 이를 세 계층으로 설명해요.

GEMM은 다음 형태의 행렬 곱셈이에요.

$$ C = \alpha AB + \beta C $$

여기서 $A$, $B$, $C$는 행렬이고, $\alpha$, $\beta$는 scaling factor입니다. 완전연결층과 많은 convolution 최적화는 GEMM 계열 연산으로 변환될 수 있어요.

Element-wise 연산은 덧셈, 곱셈, 지수, 로그, activation처럼 각 원소에 독립적으로 적용되는 연산입니다. 이런 연산은 계산 자체보다 메모리 이동이 병목이 되기 쉬워요. 그래서 여러 element-wise 연산을 fusion하면 중간 텐서 생성과 메모리 왕복을 줄일 수 있습니다.

System-level operation은 그래프 의존성을 보고 어떤 연산을 먼저 실행할지, 어떤 buffer를 재사용할지, 어떤 device stream에서 실행할지 결정합니다. 이 계층이 잘못 설계되면 수학적으로 같은 모델이어도 실제 성능은 크게 달라질 수 있어요.

3.11 Framework Architecture: API와 추상화

프레임워크 아키텍처는 강력한 계산 기능을 개발자가 사용할 수 있는 API로 정리합니다.

API는 보통 여러 추상화 수준을 제공해요.

좋은 프레임워크는 한 수준만 강요하지 않고, 필요하면 낮은 수준과 높은 수준을 섞어 쓸 수 있게 해야 해요. 연구자는 low-level 제어가 필요할 수 있고, 제품 팀은 high-level workflow 자동화가 더 중요할 수 있습니다.

3.12 Framework Ecosystem: 생태계

프레임워크는 core library만으로 끝나지 않아요. 실제 개발 경험은 주변 생태계까지 포함합니다.

Core libraries

Core library는 텐서 연산, 자동 미분, 기본 layer, optimizer를 제공합니다. 내부적으로는 C++, CUDA, vendor library 같은 저수준 최적화를 사용하면서, 사용자에게는 간결한 API를 제공해요.

Extensions and plugins

Extensions는 프레임워크를 특정 영역과 하드웨어로 확장합니다.

• computer vision, NLP용 모델과 전처리 도구
• GPU/TPU/NPU acceleration plugin
• 분산 학습 확장
• visualization과 experiment tracking
• custom operator와 backend

개발과 디버깅 도구

Jupyter notebook, profiler, debugger, graph visualizer, experiment tracker는 모델 개발 속도와 안정성에 큰 영향을 줍니다. ML 프로젝트에서는 코드만 버전 관리하는 것으로 부족할 때가 많아요. 데이터, 모델 weight, hyperparameter, 실험 결과까지 추적해야 재현성이 생깁니다.

배포 도구

모델을 실제 서비스로 옮기려면 압축, 변환, serving, versioning, monitoring 도구가 필요해요. 프레임워크 생태계가 이런 도구를 얼마나 잘 제공하는지는 production 성공 가능성을 크게 바꿉니다.

3.13 System Integration: 실제 시스템과의 통합

프레임워크는 독립된 섬처럼 쓰이지 않아요. 데이터 파이프라인, 클라우드, 컨테이너, 서빙 시스템, 모니터링 도구와 연결되어야 합니다.

Hardware integration

TensorFlow와 PyTorch는 CUDA 기반 GPU 실행을 지원하고, TensorFlow와 JAX는 TPU와도 강하게 연결됩니다. 대규모 분산 환경에서는 all-reduce, checkpointing, elastic training 같은 기능이 중요해요.

장애도 고려해야 합니다. 큰 클러스터에서는 메모리 오류, 네트워크 분리, 하드웨어 장애가 언제든 생길 수 있어요. 그래서 프레임워크와 주변 시스템은 일정 간격으로 상태를 저장하고, 일부 장치가 바뀌어도 훈련을 이어갈 수 있어야 합니다.

Infrastructure dependencies

실제 환경에서는 Apache Spark, Beam 같은 데이터 처리 도구, Docker, Kubernetes, 데이터베이스, 메시지 큐, microservice architecture와 통합해야 해요. TensorFlow Serving 같은 도구는 학습된 모델을 inference service로 제공하는 데 쓰입니다.

Production requirements

Production 배포에서는 batch prediction, real-time serving, horizontal scaling, caching, load balancing, model versioning이 필요해요. 또한 성능 지표, concept drift, 입력과 출력 로그, 감사 가능성을 모니터링해야 합니다.

End-to-end pipeline

MLOps 관점에서는 데이터 준비, 훈련, 검증, 배포, 모니터링, 재훈련이 하나의 pipeline으로 묶입니다. Kubeflow, MLflow, DVC 같은 도구는 이런 lifecycle을 관리하는 데 도움을 줘요.

3.14 Major Framework Platform Analysis: 주요 프레임워크

TensorFlow ecosystem

TensorFlow는 Google Brain에서 공개한 프레임워크로, data flow graph와 production 배포를 강하게 의식해 설계되었습니다. 생태계가 매우 넓어요.

TensorFlow는 serving, TFX, Lite, Lite Micro처럼 학습 이후의 운영 단계까지 폭넓게 제공한다는 점이 강점입니다. 다만 production 최적화는 quantization, operator fusion, 하드웨어별 tuning 등 상당한 엔지니어링 투자를 요구할 수 있어요.

PyTorch

PyTorch는 연구 친화적 프레임워크로 성장했어요. 동적 계산 그래프, Python control flow, 즉시 실행, autograd tape가 핵심입니다.

장점은 실험과 디버깅이 빠르다는 점이에요. 중간 텐서를 바로 확인할 수 있고, 조건문이나 반복문이 자연스럽게 모델에 들어갑니다. 그래서 학계와 연구 조직에서 널리 쓰였습니다.

PyTorch도 production 역량을 계속 강화하고 있어요. TorchServe, PyTorch Lightning, 컴파일 경로, 분산 학습 생태계가 발전하면서 연구와 배포 사이의 간격을 줄이고 있습니다.

JAX

JAX는 NumPy와 비슷한 사용감을 유지하면서 함수형 변환을 강하게 지원합니다. 모델 함수는 가능한 한 순수 함수로 작성하고, 파라미터는 외부에서 명시적으로 전달하는 방식이 자연스럽습니다.

JAX의 핵심은 다음 변환들이에요.

이 방식은 수학적 알고리즘 연구와 고성능 수치 계산에 강하지만, 상태를 객체 안에 숨기는 방식에 익숙한 개발자에게는 학습 곡선이 있습니다.

설계 철학 비교

프레임워크는 단순히 기능 목록으로 고르기보다, 팀의 일하는 방식과 프로젝트의 수명주기에 맞춰 선택해야 해요.

3.15 Deployment Environment-Specific Frameworks: 배포 환경별 특화

모델은 데이터센터에서만 실행되지 않아요. 클라우드, edge, 모바일, microcontroller까지 환경이 달라지면 프레임워크 요구사항도 달라집니다.

ONNX와 상호운용성

프레임워크가 많아지면 모델을 옮기기 어려워져요. ONNX는 모델 구조와 파라미터를 프레임워크 중립적으로 표현하는 형식입니다.

예를 들어 PyTorch에서 연구한 모델을 ONNX로 내보낸 뒤, ONNX Runtime이나 TensorRT 같은 추론 도구에서 실행할 수 있어요. 이는 연구용 프레임워크와 배포용 런타임을 분리하는 실용적인 방법입니다.

Cloud ML

Cloud 환경은 계산 자원이 많기 때문에 대규모 분산 학습, 큰 데이터셋, TPU/GPU cluster 활용, cloud storage와 monitoring 연동이 중요합니다. TensorFlow, PyTorch, JAX는 모두 cloud에서 사용되지만, 분산 실행과 하드웨어 최적화 방식은 서로 달라요.

TensorRT는 NVIDIA GPU 추론 최적화에 특화된 도구로, layer fusion, precision calibration, kernel auto-tuning을 통해 throughput과 latency를 개선합니다.

Edge ML

Edge 환경은 데이터가 생기는 곳 가까이에서 낮은 지연시간으로 추론하는 것이 중요해요. TensorFlow Lite, Edge Impulse 같은 도구가 대표적입니다.

Edge에서는 모델 유연성보다 추론 속도, resource 사용량, 다양한 하드웨어 대응이 더 중요할 수 있어요. 정적 그래프, quantized tensor, custom operator가 자주 사용됩니다. 자동 미분은 보통 줄이거나 제거하고 inference에 집중합니다.

Mobile ML

Mobile 환경은 edge보다 에너지 효율과 사용자 경험 제약이 더 강합니다. TensorFlow Lite, Apple Core ML, Qualcomm Neural Processing SDK 등이 사용돼요.

모바일 프레임워크는 배터리, 발열, RAM, 앱 업데이트 방식을 고려해야 합니다. 모델 업데이트와 versioning도 중요하고, 제한적인 on-device learning을 지원하는 경우도 있어요.

TinyML

TinyML은 microcontroller처럼 극도로 작은 장치에서 ML을 실행하는 영역입니다. TensorFlow Lite Micro가 대표적이에요.

이 환경에서는 몇 KB 수준의 메모리, 낮은 전력, 운영체제 부재 같은 제약이 있습니다. 따라서 정적 메모리 할당, ahead-of-time compilation, 8-bit보다 더 공격적인 quantization, microcontroller instruction set 최적화가 중요합니다. 자동 미분은 거의 사용하지 않고, 학습은 보통 장치 밖에서 수행해요.

3.16 Performance and Resource Optimization Platforms: 효율 중심 프레임워크

원문은 효율을 나중에 붙이는 기능이 아니라 처음부터 설계 조건으로 보는 흐름을 설명해요.

모델 크기와 계산량 줄이기

효율 중심 프레임워크는 quantization, pruning, knowledge distillation을 워크플로에 통합합니다.

Intel Neural Compressor, Apache TVM, Hugging Face Optimum은 이런 최적화 흐름을 지원하는 예시로 등장합니다.

하드웨어와 프레임워크 공동 최적화

Mixed precision은 FP16/BF16 계산과 FP32 누적을 조합해 속도와 안정성을 맞춥니다. PyTorch의 AMP 같은 기능은 어떤 연산을 낮은 정밀도로 실행해도 되는지 자동으로 판단하려고 해요.

Sparse computation은 하드웨어가 지원하는 sparsity 패턴에 모델을 맞춥니다. 예를 들어 특정 구조적 sparsity에서는 정확도 손실을 작게 유지하면서 속도와 메모리를 개선할 수 있어요.

Apache TVM과 MLIR 같은 compilation framework는 그래프를 분석해 하드웨어별 최적 커널을 생성합니다. 이 단계에서는 메모리 계층, 명령어 집합, 병렬화 방식까지 고려합니다.

Production 성능 요구사항

실제 서비스에서는 정확도만으로 충분하지 않아요. latency, throughput, peak memory, energy, cost가 함께 중요합니다.

TensorRT와 ONNX Runtime은 inference 최적화를 제공하고, DeepSpeed와 FairScale은 큰 모델의 메모리 부담을 줄이는 데 도움을 줍니다. Triton Inference Server는 inference serving과 scheduling을 다룹니다.

성능 평가 방법

효율을 평가할 때는 정확도만 보면 안 됩니다.

MLPerf Inference 같은 benchmark는 다양한 모델과 하드웨어에서 성능을 비교하기 위한 표준화된 기준을 제공합니다. Nsight Systems, Intel VTune 같은 profiler는 병목을 찾는 데 도움을 줘요.

3.17 Systematic Framework Selection Methodology: 프레임워크 선택 방법

원문은 프레임워크 선택을 체계적인 평가 문제로 다룹니다. 단순히 “많이 쓰니까”가 아니라, 모델 요구사항, 소프트웨어 의존성, 하드웨어 제약, 운영 요구사항, 팀 역량을 함께 봐야 해요.

모델 요구사항

모델이 어떤 연산을 쓰는지, 훈련이 필요한지 추론만 필요한지, quantization이 필요한지 확인해야 합니다.

TensorFlow 계열 예시를 보면 차이가 뚜렷해요.

소프트웨어 의존성

TensorFlow와 TensorFlow Lite는 운영체제를 전제로 하지만, TensorFlow Lite Micro는 OS 없이도 동작할 수 있어요. 또한 model memory mapping, accelerator delegation, runtime library 크기 같은 요소가 환경별로 달라집니다.

하드웨어 제약

원문은 binary size와 memory footprint가 TensorFlow, TensorFlow Lite, TensorFlow Lite Micro 순으로 크게 줄어든다고 설명해요. 큰 데이터센터용 프레임워크는 x86, GPU, TPU를 대상으로 하고, Lite는 모바일/edge processor를, Micro는 Cortex-M, DSP, MCU를 대상으로 합니다.

Production-ready 평가 요소

Embedded나 mobile 환경에서는 inference latency, memory, power, FLOPS 활용률을 정량적으로 봐야 합니다. 예를 들어 INT8 추론은 FP32보다 에너지를 훨씬 덜 쓸 수 있고, operator fusion은 이론 성능 대비 실제 활용률을 높일 수 있어요.

Scalability도 중요합니다. prototype 하나에서 잘 동작하는 것과 수많은 장치에 안정적으로 업데이트하는 것은 다릅니다. version management, rollback, monitoring, deployment pipeline까지 고려해야 해요.

생태계와 장기 유지 가능성

프레임워크의 커뮤니티, 문서, pretrained model, third-party tool, cloud service integration도 중요합니다.

PyTorch는 연구 커뮤니티와 최신 모델 생태계가 강하고, TensorFlow는 production pipeline과 serving 도구가 강하며, JAX는 함수형 수치 계산과 program transformation 커뮤니티가 강해요. Hugging Face, MLflow, Weights & Biases, TensorBoard, ONNX Runtime 같은 주변 도구도 실제 선택에 큰 영향을 줍니다.

장기적으로는 vendor lock-in과 migration path도 봐야 합니다. ONNX 같은 표준 형식, framework-agnostic data pipeline, custom operator 문서화는 미래 전환 비용을 낮춰요.

3.18 Systematic Framework Performance Assessment: 성능 평가

성능 평가는 정확도, 속도, 메모리, 에너지, 운영 통합을 모두 보는 과정이에요.

정량 평가

대표 모델과 대표 하드웨어를 정하고 동일 조건에서 평가해야 합니다. vision에서는 ResNet-50, mobile에서는 MobileNet 계열, language에서는 BERT 계열처럼 대표 workload를 정할 수 있어요.

Benchmark protocol

공정한 평가를 위해서는 dataset, batch size, precision, hardware, warm-up, measurement 방법을 통일해야 해요. profiler를 통해 framework overhead, kernel efficiency, memory allocation, garbage collection 비용도 확인해야 합니다.

운영 성능

실제 환경에서는 cold start, warm-up, steady-state latency가 모두 중요합니다. 동시에 들어오는 요청, batching, 여러 모델 인스턴스 공유, container 배포, monitoring 연동, 장애 복구도 평가해야 해요.

구조화된 선택 절차

좋은 선택 절차는 다음 순서로 진행할 수 있어요.

요구사항 정의
  -> 후보 프레임워크 선정
  -> 대표 workload benchmark
  -> 정확도/성능/resource trade-off 평가
  -> production 통합과 운영 리스크 평가
  -> migration과 장기 유지 가능성 검토

3.19 Common Framework Selection Misconceptions: 흔한 오해

원문은 프레임워크 선택에서 자주 생기는 오해를 정리합니다.

핵심은 “프레임워크는 black box가 아니다”라는 점이에요. 편리한 API 뒤에는 그래프 표현, 자동 미분, 메모리 수명, 커널 선택, 장치 통신이 숨어 있습니다. 이를 모르고 선택하면 배포 단계에서 병목과 장애를 만나기 쉽습니다.

3.20 Summary: 이 장이 남기는 메시지

이 장은 프레임워크를 다음처럼 정리합니다.

• 프레임워크는 수학적 모델을 실제 실행 가능한 시스템으로 바꾸는 추상화 계층입니다.
• 계산 그래프, 자동 미분, 텐서, 실행 모델은 현대 딥러닝 프레임워크의 핵심 개념입니다.
• PyTorch, TensorFlow, JAX는 서로 다른 철학을 가진 프레임워크입니다.
• 배포 환경이 cloud, edge, mobile, TinyML로 달라지면 프레임워크도 달라져야 합니다.
• 선택 기준은 API 취향이 아니라 모델 요구사항, 하드웨어, 성능, 배포, 생태계, 장기 유지 가능성입니다.

복습 질문

1. 머신러닝 프레임워크가 단순 라이브러리가 아니라 시스템 추상화 계층이라고 말하는 이유는 무엇인가요?
2. 계산 그래프는 자동 미분, 병렬 실행, 모델 배포와 각각 어떻게 연결되나요?
3. 정적 그래프와 동적 그래프의 장단점을 개발 단계와 production 단계로 나누어 설명해보세요.
4. Forward mode 자동 미분과 reverse mode 자동 미분은 어떤 상황에서 각각 유리한가요?
5. Reverse mode 자동 미분에서 activation memory가 문제가 되는 이유는 무엇인가요?
6. 텐서의 shape, dtype, device, stride가 성능에 영향을 주는 이유를 설명해보세요.
7. Data parallelism과 model parallelism은 무엇이 다르고, 각각 어떤 통신 비용을 만들까요?
8. TensorFlow, PyTorch, JAX의 설계 철학을 한 문장씩 비교해보세요.
9. ONNX가 프레임워크 생태계에서 해결하려는 문제는 무엇인가요?
10. Cloud, edge, mobile, TinyML 환경에서 프레임워크 선택 기준이 어떻게 달라지나요?
11. Quantization, pruning, knowledge distillation은 프레임워크 수준에서 어떤 지원을 필요로 하나요?
12. “인기 있는 프레임워크를 쓰면 된다”는 선택 방식이 위험한 이유는 무엇인가요?