콘텐츠로 이동

P5-9.1 GPU와 병렬 처리

Section ID: P5-9.1 Version: v2026.07.20

P5-8장까지는 딥러닝 모델 내부에서 일어나는 학습 계산과 regularization을 보았습니다. 여기서 시야를 조금 넓히면 다음 질문이 생깁니다.

이렇게 많은 파라미터와 반복 계산이 필요한 딥러닝이, 왜 특정 시기부터 갑자기 실용적으로 보이기 시작했는가?

이 질문에 답할 때 빼놓기 어려운 요소가 GPU(graphics processing unit)와 병렬 처리(parallel processing)입니다.

딥러닝 확산은 알고리즘 아이디어만으로 이루어진 것이 아니라, 같은 연산을 매우 많이 동시에 처리할 수 있는 계산 자원의 발전과 강하게 연결되어 있다.

계산 자원 이야기가 다시 추상적으로 느껴질 때는 개념사전의 GPU(graphics processing unit)병렬 처리(parallel processing) 항목을 함께 다시 봅니다.

GPU가 병렬 처리를 필요로 하는 질문

  • 딥러닝은 왜 계산량이 많은가?
  • CPU와 GPU를 입문 수준에서 어떻게 구분하면 좋은가?
  • 병렬 처리란 무엇이며, 딥러닝과 왜 잘 맞는가?
  • 딥러닝 확산의 역사에서 GPU가 왜 전환점처럼 언급되는가?

이 절에서는 딥러닝이 왜 같은 수치 연산을 매우 많이 반복하는 문제로 보이는지, 그리고 그 반복 계산이 왜 GPU와 병렬 처리에 잘 맞는지를 먼저 닫습니다. 즉, 여기서는 계산 자원의 큰 그림을 붙잡는 데 집중합니다.

대신 이번 절에서 바로 더 구체화할 질문도 분명합니다. GPU가 잘 처리하는 딥러닝 계산이 실제로 어떤 데이터 묶음과 shape로 주어지는지는 다음 절 P5-9.2에서 배치(batch)와 텐서(tensor) 계산으로 이어서 설명합니다. Transformer가 왜 GPU 병렬 처리와 잘 맞았는지는 P5-14.4에서 다시 회수합니다.

연산 반복과 계산 자원의 판단 기준

  • 딥러닝이 큰 행렬 연산과 반복 계산 때문에 계산 자원에 민감하다는 점을 설명할 수 있습니다.
  • CPU와 GPU의 차이를 작업 배치 방식 중심으로 직관적으로 설명할 수 있습니다.
  • 병렬 처리가 딥러닝의 학습 속도와 실용성에 어떤 영향을 주었는지 말할 수 있습니다.
  • AlexNet 같은 역사적 전환점을 GPU 관점에서 읽을 수 있습니다.

딥러닝은 왜 계산량이 많은가

딥러닝 모델은 한 번의 예측에도 많은 곱셈과 덧셈을 수행합니다. 학습 단계에서는 여기에 손실 계산, 역전파, optimizer 업데이트까지 더해집니다.

예를 들어:

  • 입력이 많고
  • 은닉층이 크고
  • 데이터가 많고
  • epoch를 여러 번 돌면

연산량은 매우 빠르게 커집니다.

특히 딥러닝에서는 다음 같은 계산이 반복됩니다.

  • 벡터(vector)와 행렬(matrix) 곱
  • 큰 텐서(tensor) 단위의 덧셈과 곱셈
  • 배치(batch) 단위 반복 계산

즉, 딥러닝은 복잡한 한 문제 하나보다, 비슷한 수치 연산을 엄청 많이 반복하는 문제에 가깝습니다.

CPU와 GPU를 입문 수준에서 어떻게 구분할까

다음 비유가 가장 안전합니다.

  • CPU는 비교적 적은 수의 강한 작업자들이 다양한 일을 유연하게 처리하는 쪽에 가깝고
  • GPU는 매우 많은 수의 작업자들이 비슷한 일을 동시에 나누어 처리하는 쪽에 가깝습니다

이 비유는 완벽한 하드웨어 설명은 아니지만, 딥러닝과의 궁합을 설명하는 데에는 충분합니다.

즉:

  • 운영체제, 브라우저, 복잡한 조건 분기 같은 작업은 CPU 감각이 강하고
  • 같은 수치 연산을 대량으로 반복하는 작업은 GPU 감각이 강합니다

딥러닝은 바로 후자와 잘 맞습니다.

병렬 처리(parallel processing)는 무엇인가

병렬 처리는 여러 계산을 동시에 나누어 처리하는 방식입니다. 다음처럼 이해하면 충분합니다.

서로 독립적이거나 비슷한 계산을 한 줄로 차례대로 처리하지 않고, 여러 계산 자원에 나누어 동시에 처리하는 것

딥러닝에서는 특히:

  • 한 배치에 들어 있는 여러 샘플
  • 행렬의 여러 원소 계산
  • 여러 채널(channel)과 feature map 연산

이 병렬화에 잘 맞습니다.

즉, 딥러닝은 같은 패턴의 수치 연산을 많이 반복한다는 점 때문에 GPU형 병렬 처리에 잘 맞는 구조를 갖습니다.

왜 딥러닝과 병렬 처리가 잘 맞는가

딥러닝 연산은 대체로 다음 세 특징으로 요약할 수 있습니다.

  • 큰 행렬을 만든다
  • 같은 연산을 많은 위치에 적용한다
  • 여러 샘플을 한꺼번에 처리한다

이 구조는 각 계산을 서로 나누기 쉬운 편입니다.

예를 들어:

  • 이미지 한 장의 서로 다른 위치에 합성곱(convolution)을 적용하거나
  • 배치 안의 여러 샘플에 같은 선형층(linear layer)을 적용하거나
  • 행렬의 여러 원소를 동시에 계산하는 것은

GPU의 강점과 잘 맞습니다.

딥러닝은 같은 종류의 수치 계산을 대량으로 반복하기 때문에, 많은 계산 유닛이 동시에 움직이는 방식과 잘 맞는다.

이 차이를 순차 처리와 병렬 처리로 나누어 그리면 다음과 같습니다.

flowchart TD
  subgraph CPU["CPU식 순차 처리"]
    direction TB
    A1["샘플 1"] --> B1["계산"]
    B1 --> C1["샘플 2"]
    C1 --> D1["다시 계산"]
    D1 --> E1["샘플 3 순서"]
  end

  GAP["비교 기준: 같은 계산을 어떻게 배치하는가"]

  subgraph GPU["GPU식 병렬 처리"]
    direction TB
    subgraph INPUTS["동시에 모이는 샘플"]
      direction LR
      A2["샘플 1"] --> A3["샘플 2"]
      A4["샘플 3"] --> A5["샘플 4"]
    end
    A2 --> P["같은 행렬 연산"]
    A3 --> P
    A4 --> P
    A5 --> P
    P --> O["출력을 함께 생성"]
  end

  CPU --> GAP --> GPU

이 도식에서 먼저 확인할 결과는, GPU의 핵심이 더 복잡한 계산을 한다는 점보다 같은 계산을 여러 샘플과 위치에 한꺼번에 배치하기 쉽다는 점이라는 사실입니다.

역사에서 GPU가 왜 전환점처럼 보이나

딥러닝 아이디어 자체는 최근에 갑자기 생긴 것이 아닙니다. 퍼셉트론, 다층 신경망, 역전파 같은 핵심 개념은 더 오래전부터 있었습니다. 그런데도 특정 시기 이후에 딥러닝이 급속히 확산된 이유 중 하나는 계산할 수 있게 되었기 때문입니다.

특히 2012년 AlexNet은 다음 요소가 함께 결합된 전환점으로 자주 설명됩니다.

  • 대규모 데이터(ImageNet)
  • 더 깊은 CNN 구조
  • GPU 기반 학습
  • 학습 기법과 정규화 기법의 결합

즉, 아이디어만으로는 부족했고, 그 아이디어를 실제 규모로 돌릴 수 있는 계산 자원이 함께 필요했습니다.

AlexNet은 왜 자주 언급되나

AlexNet은 다음처럼 이해하면 됩니다.

딥러닝이 연구 개념을 넘어 실질적 성능 전환점으로 보이게 만든 대표 사례

AlexNet이 자주 언급되는 이유는 단순히 모델이 컸기 때문이 아닙니다. GPU를 활용한 대규모 학습이 이미지 인식에서 큰 성능 차이를 보여 주면서, 딥러닝의 실용성이 널리 인식되기 시작했기 때문입니다.

이 때문에 GPU는 단순한 부품이 아니라, 딥러닝 역사에서 아이디어를 산업 규모 실험으로 올려 준 장치처럼 보입니다.

사례 및 예시

사례. 같은 위험 점수 계산을 하나씩 돌릴 때와 배치로 묶을 때

공장 라인 4개의 센서값으로 위험 점수를 만든다고 해 보겠습니다. 각 라인은 feature 3개를 갖고 있고, 모든 라인에 같은 가중치 벡터를 적용합니다. 사람은 처음에는 라인 1 점수, 라인 2 점수, 라인 3 점수를 차례대로 계산해도 결국 같은 결과가 나오니 큰 차이가 없다고 느끼기 쉽습니다. 작은 예제에서는 실제로 그 말이 맞습니다. CPU로도 각 라인을 하나씩 계산하며 점수가 어떻게 만들어지는지 충분히 따라갈 수 있습니다.

하지만 이 절에서 더 중요하게 볼 차이는 결과값보다 계산을 조직하는 방식입니다. 라인이 4개가 아니라 4천 개가 되고, 같은 선형 연산이 한 학습 step마다 반복되면 같은 계산을 한 줄씩 순서대로 돌리는가배치 전체를 한 번에 묶는가의 차이가 바로 커집니다. GPU와 병렬 처리의 핵심도 여기에 있습니다. 더 복잡한 수학을 갑자기 추가하는 것이 아니라, 같은 종류의 곱셈과 덧셈을 많이 쌓아 두고 동시에 처리하기 쉬운 구조를 만든다는 점입니다.

즉, 이 사례에서 먼저 확인해야 할 결과는 두 가지입니다.

  • 샘플별 반복 계산과 배치 행렬 계산은 같은 점수를 만들 수 있는가
  • batch가 커질수록 순차 반복 부담이 얼마나 빠르게 커지는가

이 사례를 먼저 고정해 두면, 바로 아래 예제에서 same resultscalar multiply count를 왜 같이 보는지 더 자연스럽게 연결됩니다.

연습 및 예제

이번 예제의 목표는 같은 선형 연산이 샘플 하나에만 적용될 때와 배치 전체에 한 번에 적용될 때를 나란히 보는 것입니다.

입력:

  • 라인 4개, feature 3개인 작은 배치
  • 모든 라인에 공통으로 적용할 가중치 3개

출력:

  • 라인별 위험 점수
  • 한 번의 행렬 계산으로 얻은 점수
  • 반복 계산 횟수
  • 더 큰 batch로 커질 때 반복 계산 규모가 어떻게 늘어나는지 비교

문제 상황:

  • 배치 계산은 같은 연산을 샘플마다 반복하는 대신 한 번의 행렬 연산으로 묶어 처리한다는 점을 직접 확인할 필요가 있다
  • 작은 예제에서도 반복 횟수 증가를 같이 보면 왜 계산 자원이 실험 가능성을 바꾸는지 읽기 쉽다

확인할 개념:

  • 배치 행렬 계산은 여러 샘플 점수를 한 번에 만든다
  • 반복 계산과 행렬 계산이 같은 결과를 낸다는 점을 확인하면 배치 처리의 의미가 더 분명해진다
  • batch가 커질수록 순차 반복 규모가 바로 커진다는 점을 같이 봐야 한다

초심자 기준에서는 이 예제를 다음 세 단계로 읽는 편이 좋습니다.

읽는 단계 먼저 볼 것 바로 이어서 붙잡을 질문
1 라인별 점수가 어떻게 계산되는가 샘플별 반복 계산과 배치 계산이 같은 점수를 만드는가
2 scalar multiply count가 몇 번인가 같은 연산이 batch가 커질수록 얼마나 빨리 불어나는가
3 CPU와 GPU를 왜 따로 말하는가 결과가 같아도 계산 조직 방식이 실험 가능 범위를 바꾸는가

입력(input):

위에 정리한 라인 batch와 공통 가중치 벡터를 사용합니다.

코드를 보기 전에 먼저 무엇이 같고 무엇이 커질지 예상해 보면 좋습니다.

비교 먼저 예상해 볼 비교 예상 이유
scores_one_by_one vs scores_batch 같은 결과가 나올 가능성 계산 의미 자체는 같고 묶는 방식만 다르기 때문입니다.
scalar multiply count batch와 feature가 커질수록 바로 늘어날 가능성 샘플 수와 feature 수만큼 반복 곱셈이 누적되기 때문입니다.
실험 부담 batch와 모델이 커질수록 CPU식 순차 계산 부담이 더 커질 가능성 같은 종류의 반복 계산이 빠르게 늘어나기 때문입니다.

여기서 실제로 확인하려는 차이도 단순 계산량 비교에서 끝나지 않습니다. 같은 점수를 얻더라도 CPU 쪽 읽기는 이번 실험 하나를 끝내는 데 얼마나 오래 걸리는가로 이어지고, GPU 쪽 읽기는 batch 크기, 입력 특징 수, 가중치 설정을 몇 번이나 다시 바꿔 볼 수 있는가로 이어져야 합니다. 즉, 이 절의 계산 차이는 결국 실험 회전 가능성 차이까지 연결되어야 합니다.

이 표의 목적은 결과는 같지만 계산 부담은 커진다는 점을 분리해서 읽는 것입니다. 이번 코드는 batch 크기feature 수를 직접 바꿔 볼 수 있게 두어, 어떤 값이 반복 계산 증가에 더 민감한지 바로 실험해 보게 합니다.

# 같은 라인 위험 점수를 sample별 반복 계산과 batch 행렬 계산으로 비교하고, batch/feature 크기에 따른 곱셈 수 증가를 확인하는 예제입니다.
import numpy as np

# 4 lines, 3 features each
batch = np.array([
    [1.0, 0.5, 2.0],
    [0.2, 1.5, 0.3],
    [1.2, 0.1, 0.7],
    [0.0, 2.0, 1.0],
])

weights = np.array([0.4, 0.8, -0.3])
probe_batch_sizes = [4, 8, 16, 32]
probe_feature_sizes = [3, 6]


def scalar_multiply_count(batch_size, feature_count):
    return batch_size * feature_count


scores_one_by_one = []
scalar_multiply_total = 0
for sample in batch:
    score = 0.0
    for x, w in zip(sample, weights):
        score += x * w
        scalar_multiply_total += 1
    scores_one_by_one.append(round(score, 3))

scores_batch = batch @ weights
scaling_table = {
    feature_count: [
        scalar_multiply_count(batch_size, feature_count)
        for batch_size in probe_batch_sizes
    ]
    for feature_count in probe_feature_sizes
}

print("batch shape =", batch.shape)
print("weights shape =", weights.shape)
print("scores_one_by_one =", scores_one_by_one)
print("scores_batch =", np.round(scores_batch, 3).tolist())
print("scalar multiply count =", scalar_multiply_total)
print("same result =", np.allclose(scores_one_by_one, np.round(scores_batch, 3)))
print("probe batch sizes =", probe_batch_sizes)
print("estimated scalar multiplies when feature count = 3 =", scaling_table[3])
print("estimated scalar multiplies when feature count = 6 =", scaling_table[6])

출력에서는 scores_one_by_one과 scores_batch가 같은지 먼저 보고, 그 계산이 batch와 feature가 커질 때 어떤 속도로 불어나는지 이어서 보면 됩니다.

1
2
3
4
5
6
7
8
9
batch shape = (4, 3)
weights shape = (3,)
scores_one_by_one = [0.2, 1.19, 0.35, 1.3]
scores_batch = [0.2, 1.19, 0.35, 1.3]
scalar multiply count = 12
same result = True
probe batch sizes = [4, 8, 16, 32]
estimated scalar multiplies when feature count = 3 = [12, 24, 48, 96]
estimated scalar multiplies when feature count = 6 = [24, 48, 96, 192]
  • 계산 내용 자체는 같아도, 실제 딥러닝 프레임워크는 이런 연산을 배치 전체 행렬 계산으로 묶어 처리합니다
  • 예제처럼 작은 데이터에서도 같은 곱셈이 12번 반복되며, batch나 feature가 커지면 이 반복 횟수는 바로 커집니다
  • GPU의 강점은 이런 반복 곱셈과 덧셈을 대량으로 병렬 처리하는 데 있습니다

첫 번째 산출물은 라인별 위험 점수입니다. 샘플별 반복 계산과 배치 행렬 계산은 같은 점수를 만들지만, 이 그래프가 보여 주는 핵심은 결과가 같다가 아니라 같은 결과를 다른 계산 조직으로 얻는다는 점입니다.

샘플별 반복 계산과 배치 행렬 계산의 위험 점수 비교

두 번째 산출물은 scalar multiply count 증가 곡선입니다. 현재 예제의 4개 라인, 3개 feature에서는 곱셈이 12번 필요하지만, batch 크기와 feature 수를 함께 키우면 같은 종류의 반복 계산이 얼마나 빨리 불어나는지 더 직접적으로 읽을 수 있습니다.

batch 크기 증가에 따른 scalar multiply count

비교 지금 읽어야 할 핵심
scores_one_by_one vs scores_batch 결과는 같지만 계산 조직 방식이 다릅니다.
12 -> 24 -> 48 -> 96 증가 batch와 feature가 커질수록 같은 종류의 곱셈 부담이 빠르게 불어납니다.
CPU vs GPU 감각 GPU의 가치는 같은 계산을 더 빨리 끝내는 데서 끝나지 않고, 더 큰 batch와 더 많은 실험을 실제로 가능하게 만드는 데 있습니다.

출력 숫자를 읽을 때도 같은 결과가 나왔는가그 결과를 얻기 위해 감당해야 할 계산 규모를 분리해서 봐야 합니다. 초심자 기준에서는 출력 줄을 다음처럼 하나씩 다시 읽으면 좋습니다.

출력 줄 바로 읽어야 할 의미 다음으로 이어질 질문
same result = True 샘플별 반복 계산과 배치 계산은 수학적으로 같은 일을 합니다. 그렇다면 실제 차이는 계산을 어떤 조직으로 처리하느냐에 있는가
scalar multiply count = 12 작은 batch에서도 같은 곱셈이 여러 번 반복됩니다. 샘플 수, feature 수, layer 수가 커지면 반복 부담은 어디까지 커지는가
estimated scalar multiplies when feature count = 3/6 batch뿐 아니라 feature 수도 반복 계산 증가 속도를 함께 밀어 올립니다. 어떤 입력 크기와 어떤 모델 폭까지가 실제로 실험 가능한 범위인가
비교 출력에서 먼저 보이는 것 결과만 보면 남기 쉬운 해석 GPU 관점까지 보면 바뀌는 해석
scores_one_by_one vs scores_batch 점수는 완전히 같습니다. 그러면 계산 방식 차이는 중요하지 않다고 보기 쉽습니다. 수학적으로 같은 연산이라도, 어떻게 묶어 처리하느냐가 실용 속도와 처리 규모를 바꿉니다.
12 -> 24 -> 48 -> 96 증가 batch와 feature를 키우면 반복 계산 추정치가 빠르게 커집니다. 작은 예제에서는 숫자가 단순하니 실제 부담도 단순하게 늘어날 것처럼 보기 쉽습니다. 실제 모델에서는 batch, feature, layer가 함께 커져 반복 계산이 곧 실험 병목으로 바뀝니다.
CPU vs GPU 감각 작은 예제는 CPU로도 충분히 끝납니다. GPU는 편의용 가속 정도라고 보기 쉽습니다. 계산 자원은 단순 속도 차이가 아니라, 더 큰 batch와 더 많은 시도를 가능한 작업 범위로 바꾸는 조건입니다.
실험 운영 기준 CPU식 읽기만 하면 쉬운 판단 GPU 관점까지 읽고 바뀌는 판단
batch 크기 조정 같은 점수만 나오면 batch를 바꿔 볼 이유가 약하다고 느끼기 쉽다 batch를 키웠을 때 반복 계산 부담이 얼마나 커지는지 알면, 어떤 범위까지 실험을 돌릴 수 있을지 먼저 가늠하게 된다
하이퍼파라미터 탐색 learning rate나 모델 폭을 여러 번 바꾸는 것이 그냥 시간이 조금 더 드는 문제처럼 보일 수 있다 같은 연산이 빠르게 불어나면, 계산 자원에 따라 시도 가능한 설정 수 자체가 달라진다는 점을 먼저 보게 된다
모델 규모 확장 feature나 layer를 늘리면 정확도만 좋아질 것처럼 느끼기 쉽다 실제로는 반복 계산과 메모리 부담이 같이 커져, 성능 기대보다 먼저 실행 가능한가를 따져야 한다

이 결과를 운영 실험으로 바꾸면, CPU식 읽기는 같은 점수가 나오니 계산 방식 차이는 부차적이라는 판단으로 흐르기 쉽고, GPU 관점 읽기는 어떤 batch와 어떤 설정까지 실제로 반복 실험이 가능한가를 먼저 따지게 만듭니다. 이 절에서 읽어야 할 전환점은 단순 속도 차이가 아니라 바로 이런 실험 설계 가능 범위의 차이입니다.

Part 5에서 GPU 절이 중요한 이유는 단순히 하드웨어 지식을 넣기 위해서가 아닙니다. 딥러닝을 순수한 수학 이론으로만 보면, 왜 특정 시기에 갑자기 산업적 전환이 일어났는지 설명이 비게 됩니다.

이 절은 다음 연결을 만들어 줍니다.

  • Part 2의 벡터/행렬/NumPy 계산
  • Part 5의 역전파와 optimizer
  • 다음 Part의 LLM 대규모 학습과 추론 비용

즉, GPU 절은 딥러닝이 왜 큰 계산 산업이 되었는가를 설명하는 역사적 연결 고리입니다.

여기서 한 번 멈추고, 언제 모델 구조보다 계산 자원 관점부터 먼저 떠올려야 하는가를 짧게 고정해 두면 뒤 장을 읽을 때 판단 축이 덜 흔들립니다.

먼저 떠올릴 질문 GPU·병렬 처리 관점이 먼저 필요한 이유 아직 이 절에서 깊게 들어가지 않을 것
모델이 왜 갑자기 너무 느려졌는가 같은 연산이 대량 반복되는지, 배치와 행렬 계산이 병목인지 먼저 봐야 하기 때문 프레임워크 커널 최적화, CUDA 내부 구현
실험을 여러 번 돌려야 하는데 시간이 너무 오래 걸리는가 계산 자원은 단순 속도 문제가 아니라 실험 회전 자체를 가능하게 만드는 조건이기 때문 TPU, NPU, 분산 학습 인프라 상세
모델이 커질수록 왜 학습 가능 여부 자체가 달라지는가 파라미터 수와 입력 크기 증가가 메모리와 연산량 한계를 함께 밀어 올리기 때문 메모리 대역폭, 하드웨어 아키텍처 세부

체크리스트

  • GPU(graphics processing unit)와 병렬 처리(parallel processing)가 왜 딥러닝 확산과 강하게 연결되는지 설명할 수 있는가?
  • 계산 자원 발전이 모델 구조 발전과 어떻게 맞물렸는지 말할 수 있는가?
  • 딥러닝은 큰 수치 연산을 반복하는 계산 문제라는 점을 설명할 수 있는가?
  • GPU는 비슷한 계산을 대량으로 동시에 처리하는 데 강하다는 점을 말할 수 있는가?
  • GPU를 딥러닝을 더 빨리 돌리는 부품 정도로만 말하지 않고, 대량 반복 계산을 실제 실험 규모로 올려 주는 조건으로 설명할 수 있는가?
  • 같은 점수를 샘플별 반복 계산과 배치 행렬 계산으로 모두 얻을 수 있지만, 계산 조직 방식이 실험 가능 범위를 바꾼다는 점을 설명할 수 있는가?
  • 모델 구조보다 실행 속도와 실험 회전이 더 큰 병목처럼 보일 때, 계산 자원 관점을 먼저 떠올릴 수 있는가?
  • AlexNet이 데이터, 모델, GPU, 학습 기법이 결합된 전환점으로 자주 읽힌다는 점을 알고 있는가?

출처와 참고 자료