들어가며
AI 하드웨어를 이야기할 때 우리는 흔히 TFLOPS, 즉 초당 부동소수점 연산 횟수를 봅니다. "이 칩은 몇 페타플롭이다"라는 식이죠. 하지만 현장에서 모델을 돌려본 사람이라면 누구나 같은 좌절을 겪습니다. 스펙시트상 연산 능력은 어마어마한데, 실제로 모델을 돌리면 그 능력의 일부밖에 못 씁니다. GPU 사용률이 30%를 넘기지 못하는 일도 흔합니다. 왜일까요.
답은 거의 항상 같습니다. **연산 유닛이 데이터를 기다리고 있기 때문입니다.** 계산할 곱셈기는 충분한데, 그 곱셈에 넣을 숫자(가중치, 활성값)를 메모리에서 충분히 빨리 가져오지 못하는 것입니다. 이것이 메모리 월(memory wall)이며, 2026년 AI 성능을 실질적으로 가르는 진짜 병목입니다. 이 글은 메모리 월의 정체와, 개발자가 그것을 이해하고 다루는 법을 정리합니다.
이 주제가 특히 중요한 이유는, 메모리 월이 칩 설계자만의 문제가 아니기 때문입니다. 모델을 학습하지도 칩을 만들지도 않는 평범한 애플리케이션 개발자조차, 이 원리를 이해하면 같은 하드웨어에서 추론을 몇 배 빠르고 싸게 돌릴 수 있습니다. 반대로 이 원리를 모르면, 비싼 칩을 사고도 그 잠재력의 일부만 쓰며 비용을 낭비하기 쉽습니다. 메모리 월은 추상적인 하드웨어 이론이 아니라, 당장 내 추론 청구서를 좌우하는 실전 지식입니다.
이 글의 목표는 단순합니다. 여러분이 다음 한 가지 질문을 본능적으로 던질 수 있게 만드는 것입니다. "이 워크로드의 진짜 병목은 연산인가, 메모리인가?" 이 질문 하나가 추론 비용을 절반으로 줄이고, 엉뚱한 칩을 사는 실수를 막아 줍니다. 화려한 TFLOPS 숫자에 가려진 진짜 병목을 보는 눈, 그것이 이 글이 전하려는 핵심 역량입니다.
전체 흐름은 이렇습니다. 먼저 "연산은 싸고 데이터 이동은 비싸다"는 근본 비대칭을 짚고, 메모리 월의 정체와 그에 맞서는 무기인 HBM을 살핍니다. 이어 연산 바운드인지 메모리 바운드인지 판단하는 도구(roofline 모델)와 KV 캐시, 양자화, 메모리 계층을 다루고, 차세대 메모리 동향과 개발자를 위한 실천 정리로 마무리합니다.
1. 연산은 싸고 데이터 이동은 비싸다
칩 설계의 한 가지 불편한 진실은, 수십 년간 연산 능력은 메모리 능력보다 훨씬 빠르게 발전해 왔다는 것입니다. 트랜지스터를 더 넣어 곱셈기를 늘리는 것은 비교적 쉬웠지만, 데이터를 칩 안으로 빠르게 실어 나르는 것은 그만큼 빨리 좋아지지 못했습니다.
에너지 관점에서 보면 더 극적입니다. 두 숫자를 곱하는 연산이 소비하는 에너지보다, 그 숫자를 멀리 있는 메모리에서 가져오는 데 드는 에너지가 훨씬 큽니다. 데이터가 멀리 있을수록 비용이 커집니다.
데이터 이동 에너지 (상대적, 개념)
칩 내부 연산(곱셈) ▪ 가장 쌈
온칩 SRAM 접근 ▪▪▪
HBM(패키지 내) 접근 ▪▪▪▪▪▪▪▪▪▪
칩 밖(다른 노드) 접근 ▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪... 가장 비쌈
→ 멀리서 데이터를 가져올수록 에너지·시간 비용이 폭증한다.
이 비대칭이 모든 것을 설명합니다. 좋은 AI 하드웨어와 좋은 AI 코드의 상당 부분은 "연산을 줄이는 것"이 아니라 "데이터 이동을 줄이는 것"에 관한 것입니다.
왜 이 비대칭이 생겼나
이 비대칭은 우연이 아니라 물리와 공정의 결과입니다. 트랜지스터를 더 작게 만들어 칩에 더 많이 욱여넣는 것은 수십 년간 비교적 꾸준히 발전했습니다. 그래서 연산기를 늘리는 것은 상대적으로 쉬웠습니다. 반면 데이터를 칩 안팎으로 빠르게 실어 나르는 것은 핀의 개수, 배선의 물리적 한계, 전력과 발열 같은 제약에 묶여 그만큼 빠르게 좋아지지 못했습니다.
그 결과 연산 능력과 메모리 공급 능력 사이의 간극이 세대를 거듭하며 벌어졌습니다. 칩은 점점 더 많이 계산할 수 있게 됐지만, 그 계산기에 데이터를 먹이는 능력은 따라가지 못했습니다. 이 누적된 간극이 바로 메모리 월입니다. 그리고 모델이 거대해질수록(가중치가 많아질수록) 읽어야 할 데이터가 늘어나므로, 이 문제는 시간이 갈수록 더 심해집니다.
2. 메모리 월이란 무엇인가
메모리 월은 연산 속도와 메모리 공급 속도 사이의 점점 벌어지는 간극을 가리킵니다. 칩의 연산 능력은 빠르게 늘었지만, 그 연산기를 먹여 살릴 데이터 공급 능력(메모리 대역폭)은 그만큼 빨리 늘지 못했습니다. 그 결과 강력한 연산기들이 데이터를 기다리며 노는 시간이 길어집니다.
비유하자면 이렇습니다. 주방에 요리사 100명이 있는데(연산기), 식재료를 나르는 통로가 하나뿐이라(메모리 대역폭) 대부분의 요리사가 재료를 기다리며 서 있는 상황입니다. 요리사를 200명으로 늘려봐야 통로가 그대로면 음식이 더 빨리 나오지 않습니다. 늘려야 할 것은 통로입니다.
이것이 2026년 칩 설계가 연산기 증설보다 메모리 대역폭과 인터커넥트, 패키징에 집중하는 이유입니다.
사용률 30%의 비밀
서두에서 말한 "GPU 사용률 30%" 현상을 메모리 월로 다시 설명해 봅니다. 사용률이 낮다는 것은 연산기가 노는 시간이 많다는 뜻입니다. 그런데 연산기가 노는 이유는 일이 없어서가 아니라, 일에 필요한 데이터가 아직 도착하지 않아서입니다.
사용률이 낮은 이유 (개념)
시간축 →
연산기: [계산][ 대기 ][계산][ 대기 ][계산]
메모리: [ 데이터 나르는 중 ][ 나르는 중 ]
연산기는 데이터를 기다리며 자주 멈춘다.
→ "더 빠른 연산기"가 아니라 "더 빠른 데이터 공급"이 필요하다.
따라서 "GPU 사용률을 어떻게 높이지?"라는 질문의 답은 대개 "연산기를 더 바쁘게"가 아니라 "데이터를 더 빨리 공급하거나, 읽을 데이터를 줄이거나, 한 번 읽은 데이터를 더 재사용하기"입니다. 이 관점의 전환이 메모리 월을 이해하는 첫걸음입니다.
3. HBM — 메모리 월에 맞서는 무기
이 통로를 넓히기 위한 가장 중요한 무기가 HBM(High Bandwidth Memory)입니다. 일반 메모리(DRAM)를 칩 옆에 평면으로 두는 대신, HBM은 메모리 칩을 수직으로 쌓고(3D 스택), 그것을 연산 칩 바로 옆에 패키지로 붙입니다(예: CoWoS 패키징). 그 결과 데이터가 오가는 거리가 짧아지고, 매우 넓은 폭의 연결을 둘 수 있어 대역폭이 폭발적으로 커집니다.
HBM 세대
HBM 세대 흐름 (개념)
HBM2 → HBM2e → HBM3 → HBM3e → HBM4
세대가 올라갈수록:
- 적층 단수 증가 → 용량 증가
- 핀당 속도 증가 → 대역폭 증가
- 패키징 정교화 → 효율 증가
2026년의 핵심은 HBM3e에서 HBM4로의 전환입니다. HBM4는 인터페이스 폭을 넓히고 적층을 더 높여, 대역폭과 용량을 동시에 끌어올립니다. 앞 글에서 다룬 차세대 플랫폼들(Vera Rubin 등)이 HBM4를 채택하는 이유가 바로 메모리 월 완화입니다.
왜 HBM은 비싸고 귀한가
HBM은 강력하지만 공짜가 아닙니다. 메모리를 수직으로 쌓고 연산 칩 옆에 정밀하게 붙이는 공정은 일반 메모리보다 훨씬 까다롭고 비쌉니다. 적층 과정에서 하나라도 불량이 나면 전체 스택을 버려야 하므로 수율 관리도 어렵습니다. 게다가 HBM과 연산 다이를 하나로 묶는 고급 패키징(예: CoWoS) 생산 능력 자체가 제한적입니다.
HBM이 귀한 이유 (개념)
- 3D 적층: 수직으로 쌓는 정밀 공정, 불량 시 스택 전체 손실
- 고급 패키징: 연산 다이와 한 패키지로 묶는 능력이 희소
- 수요 폭증: 모든 AI 가속기가 HBM을 원함
→ HBM과 패키징 생산 능력이 AI 가속기 공급의 실질적 병목.
그래서 2026년 AI 가속기 부족 이야기의 상당 부분은 사실 "칩 자체"보다 "HBM과 패키징"의 부족입니다. 연산 다이를 찍어낼 수 있어도 거기에 붙일 HBM과 패키징 능력이 모자라면 완성품을 못 만듭니다. 메모리 월은 성능의 문제일 뿐 아니라, 공급망의 문제이기도 한 것입니다.
대역폭 vs 용량
HBM에는 두 가지 다른 자원이 있고, 이 둘을 혼동하면 안 됩니다.
- **용량(GB)**: 모델 가중치와 활성값, KV 캐시가 들어갈 공간. 모자라면 모델이 칩에 안 올라가거나 여러 칩으로 쪼개야 합니다.
- **대역폭(TB/s)**: 그 공간에서 데이터를 얼마나 빨리 읽고 쓰는가. 추론 속도를 직접 결정하는 경우가 많습니다.
추론에서 흔한 오해는 "용량만 크면 된다"는 것입니다. 모델이 들어가도, 대역폭이 부족하면 토큰 생성이 느립니다. 두 자원을 함께 봐야 합니다.
용량 vs 대역폭 (비유)
용량 = 창고의 크기 (얼마나 많이 보관하는가)
대역폭 = 출입문의 폭 (얼마나 빨리 꺼내 쓰는가)
큰 창고에 좁은 문이면, 물건은 많이 넣어도 빨리 못 꺼낸다.
추론 속도는 종종 "창고 크기"가 아니라 "문의 폭"이 결정한다.
이 비유의 교훈은, 칩 스펙을 볼 때 "메모리 몇 GB"라는 용량 숫자에만 현혹되지 말라는 것입니다. 그 옆의 "대역폭 몇 TB/s"가 추론 속도에는 더 직접적인 영향을 주는 경우가 많습니다. 모델이 들어가느냐는 용량의 문제이고, 충분히 빠르냐는 대역폭의 문제입니다. 둘은 다른 질문이며, 둘 다 만족해야 좋은 추론 경험이 나옵니다.
4. 산술 강도와 roofline 모델
연산 바운드인지 메모리 바운드인지를 판단하는 도구가 roofline 모델이고, 그 핵심 개념이 산술 강도(arithmetic intensity)입니다. 산술 강도는 "메모리에서 가져온 바이트 하나당 몇 번의 연산을 하는가"입니다.
산술 강도 정의
I = (수행한 연산 수) / (이동한 바이트 수)
= FLOPs / Bytes
I 가 크다 → 가져온 데이터를 많이 재사용 → 연산 바운드
I 가 작다 → 데이터를 가져오자마자 한 번 쓰고 버림 → 메모리 바운드
roofline 모델은 이 산술 강도에 따라 달성 가능한 성능의 상한을 그립니다.
roofline 모델 (개념)
달성 가능 성능
^
| ______________ 연산 상한(peak FLOPS)
| /
| / ← 이 비탈의 기울기 = 메모리 대역폭
| /
| /
+---------+------------------> 산술 강도 (FLOPs/Byte)
전환점
산술 강도가 전환점보다 작으면(비탈 영역) 메모리 대역폭이 성능을 제한한다.
크면(평평한 영역) 연산 능력이 성능을 제한한다.
LLM 추론, 특히 토큰을 하나씩 생성하는 디코딩 단계는 산술 강도가 매우 낮습니다. 거대한 가중치를 한 번 읽어와서 작은 입력과 곱하고 버리기 때문입니다. 그래서 LLM 추론은 거의 항상 roofline의 왼쪽 비탈, 즉 메모리 바운드 영역에 위치합니다. 이 한 가지 사실이 추론 최적화의 거의 모든 것을 설명합니다.
roofline로 보는 최적화의 방향
roofline 모델의 진짜 가치는 "어디를 고쳐야 하는가"를 알려주는 데 있습니다. 내 워크로드가 비탈 영역(메모리 바운드)에 있다면, 연산기를 더 늘려봐야 소용이 없습니다. 비탈의 기울기, 즉 메모리 대역폭을 높이거나, 산술 강도를 끌어올려 오른쪽으로 이동해야 합니다.
메모리 바운드일 때 효과 있는 것 / 없는 것
효과 없음: 연산기 추가, peak FLOPS 자랑하는 더 비싼 칩
(이미 연산기는 놀고 있다)
효과 있음: - 메모리 대역폭 높은 칩
- 양자화로 읽을 바이트 줄이기
- 데이터 재사용을 높여 산술 강도 올리기(SRAM 활용)
- 불필요한 메모리 접근 제거
이 단순한 통찰이 추론 최적화의 나침반이 됩니다. 비싼 칩을 사기 전에, 내 워크로드가 roofline의 어디에 있는지부터 확인하는 것이 순서입니다. 대부분의 LLM 추론은 왼쪽 비탈에 있으므로, 답은 거의 항상 "연산을 늘리지 말고 데이터 이동을 줄여라"입니다.
5. KV 캐시 — 추론 메모리의 숨은 주인공
LLM 추론에서 메모리를 이야기할 때 빼놓을 수 없는 것이 KV 캐시입니다. 트랜스포머는 토큰을 생성할 때, 이전 토큰들에 대한 key와 value를 저장해 두고 재사용합니다. 매번 처음부터 다시 계산하지 않기 위해서입니다.
문제는 이 캐시가 문맥 길이에 비례해 커진다는 점입니다.
KV 캐시 크기 (개념)
캐시 크기 대략 ∝ (배치 크기) x (문맥 길이) x (레이어 수)
x (헤드 차원) x (2: key와 value) x (정밀도 바이트)
긴 문맥 + 많은 동시 사용자 → KV 캐시가 가중치만큼, 때로는 더 커진다.
긴 문맥과 많은 동시 사용자를 다루는 2026년 서비스에서는, KV 캐시가 메모리 용량과 대역폭을 모두 잡아먹는 주범이 됩니다. 그래서 KV 캐시를 압축하거나, 정밀도를 낮추거나(예: INT8 캐시), 페이지 단위로 효율적으로 관리하는 기법들이 추론 최적화의 핵심으로 떠올랐습니다.
KV 캐시가 대역폭을 먹는 방식
KV 캐시는 용량만 먹는 것이 아니라 대역폭도 먹습니다. 토큰을 하나 생성할 때마다 지금까지 쌓인 모든 key와 value를 다시 읽어야 하기 때문입니다. 문맥이 길수록 매 토큰마다 읽어야 할 캐시가 커지고, 이것이 그대로 대역폭 부담으로 이어집니다.
KV 캐시와 대역폭 (개념)
짧은 문맥: 토큰 생성 시 작은 캐시 읽기 → 가벼움
긴 문맥: 토큰 생성 시 거대한 캐시 읽기 → 매 토큰마다 무거움
→ 긴 문맥은 "용량"뿐 아니라 "매 토큰의 대역폭"을 함께 소모한다.
생성이 길어질수록 토큰당 비용이 점점 늘어나는 이유.
이 때문에 긴 문맥 서비스에서는 생성 후반부로 갈수록 토큰 생성이 느려지는 현상이 나타납니다. 캐시가 계속 커지기 때문입니다. KV 캐시 최적화가 단순한 메모리 절약이 아니라 속도와 비용의 문제인 이유가 여기에 있습니다. 정밀도를 낮춘 캐시나 압축은 용량과 대역폭을 동시에 줄여, 긴 문맥 추론의 비용 곡선을 완만하게 만듭니다.
6. 양자화로 대역폭을 절감하다
메모리 바운드 세계에서 양자화는 단순한 메모리 절약 기법이 아니라 속도 향상 기법입니다. 이 점이 직관과 어긋나서 중요합니다.
가중치를 FP16에서 INT8로 낮추면 메모리 사용량이 절반이 됩니다. 그런데 추론이 메모리 바운드라면, 절반의 바이트를 읽는다는 것은 곧 두 배 빠르게 읽는다는 뜻입니다. 즉 양자화는 메모리 바운드 구간에서 처리량을 직접 끌어올립니다.
양자화의 이중 효과 (메모리 바운드 추론)
FP16 가중치: [██] 8바이트 읽기 → 1단위 시간
INT8 가중치: [█] 4바이트 읽기 → 0.5단위 시간 (2배 빠름)
FP4 가중치: [▌] 2바이트 읽기 → 0.25단위 시간 (4배 빠름)
메모리가 병목일 때, 정밀도를 낮추면 용량도 절약되고 속도도 빨라진다.
물론 정밀도를 낮추면 정확도 손실 위험이 있습니다. 그래서 2026년 추론 스택은 정확도 손실을 최소화하는 정교한 양자화 기법(가중치별·채널별 스케일링 등)과, 하드웨어가 직접 지원하는 저정밀 포맷(FP8/FP4)을 결합해 씁니다. 앞 글에서 본 Blackwell의 2세대 Transformer Engine이 바로 이 흐름의 하드웨어적 답입니다.
토큰 생성 속도를 대역폭으로 추정하기
메모리 바운드의 위력을 체감하기 위해, 토큰 생성 속도를 대역폭만으로 거칠게 추정하는 사고 실험을 해봅니다. 핵심 직관은 이렇습니다. decode 단계에서 토큰 하나를 생성하려면 모델의 모든 가중치를 한 번씩 읽어야 합니다.
대역폭으로 토큰 생성 속도 추정 (개념)
토큰 하나당 읽어야 할 바이트 ≈ 모델 전체 가중치 크기
초당 생성 가능 토큰 수 ≈ (메모리 대역폭) / (모델 가중치 크기)
예) 가중치를 절반 크기로 양자화하면
→ 토큰당 읽을 바이트가 절반
→ 같은 대역폭으로 약 두 배의 토큰을 생성
이 단순한 추정은 왜 양자화가 곧 속도인지를 명확히 보여줍니다. 토큰당 읽을 바이트를 절반으로 줄이면, 대역폭이 같아도 초당 생성 토큰이 약 두 배가 됩니다. 물론 실제로는 KV 캐시, 활성값, 오버헤드 등 다른 요소가 끼지만, "토큰 생성 속도는 대역폭에 비례하고 가중치 크기에 반비례한다"는 큰 그림은 변하지 않습니다. 더 빠른 토큰 생성을 원한다면, 더 비싼 연산기보다 더 넓은 대역폭이나 더 작은 가중치가 답인 경우가 많습니다.
7. 메모리 계층과 온칩 SRAM
메모리는 하나가 아니라 계층입니다. 빠르고 작은 것부터 느리고 큰 것까지 층층이 쌓여 있습니다.
메모리 계층 (빠르고 작음 → 느리고 큼)
레지스터 가장 빠름, 극소 용량
온칩 SRAM 매우 빠름, 작은 용량 (수 MB ~ 수십 MB)
HBM 빠름, 큰 용량 (수십 ~ 수백 GB)
호스트 메모리 느림, 매우 큰 용량
다른 노드 가장 느림, 사실상 무제한
좋은 추론 커널의 비결은 데이터를 가능한 한 빠른 계층에 오래 머무르게 하는 것입니다. 한 번 HBM에서 온칩 SRAM으로 가져온 데이터를, 다시 HBM에 다녀오지 않고 최대한 재사용하는 것이죠. 이것이 어텐션 연산을 메모리 효율적으로 재구성하는 기법들(데이터를 작은 블록으로 나눠 SRAM 안에서 처리)의 핵심 아이디어입니다. 산술 강도를 인위적으로 끌어올려 roofline의 오른쪽으로 옮기는 셈입니다.
이 아이디어가 강력한 이유는, 똑같은 수학적 결과를 내면서도 메모리 접근 방식만 바꿔 속도를 끌어올리기 때문입니다. 연산의 양은 그대로인데, 데이터를 어떻게 옮기고 재사용하느냐를 영리하게 바꾸는 것만으로 큰 차이가 납니다. 메모리 월 시대의 좋은 커널 설계가 "수학"보다 "데이터 이동의 안무"에 가까운 이유가 여기에 있습니다.
극단적 사례로, 일부 웨이퍼스케일 칩(예: Cerebras WSE-3)은 아예 거대한 온칩 SRAM(약 44GB)과 어마어마한 온칩 대역폭(약 21 PB/s)을 둬서, HBM을 오가는 비용 자체를 없애려는 접근을 취합니다. 메모리 월에 대한 또 다른 종류의 답입니다.
이 접근의 발상은 근본적입니다. 일반 칩은 작은 SRAM과 큰 HBM 사이를 끊임없이 데이터가 오가야 하지만, 웨이퍼스케일 칩은 칩 전체가 워낙 거대해서(웨이퍼 한 장 통째) 모델을 통째로 온칩 SRAM에 올릴 여지를 만듭니다. 그러면 가장 비싼 데이터 이동인 "칩 밖 메모리 왕복"이 사라집니다.
일반 칩 vs 웨이퍼스케일 (메모리 접근 관점)
일반 칩: 연산 ↔ 작은 SRAM ↔ HBM(칩 밖) ← HBM 왕복 비용 큼
웨이퍼스케일: 연산 ↔ 거대한 온칩 SRAM ← 칩 밖 왕복 최소화
→ 데이터를 칩 안에 가둬, 메모리 월의 가장 비싼 부분을 우회한다.
물론 이 방식에도 대가가 있습니다. 거대한 단일 칩은 제조가 어렵고 비싸며, 모든 워크로드와 예산에 맞지는 않습니다. 하지만 "메모리 월을 우회하는 가장 직접적인 방법은 데이터를 아예 칩 밖으로 내보내지 않는 것"이라는 발상은, 메모리 중심 사고가 어디까지 갈 수 있는지를 보여주는 좋은 사례입니다.
8. 차세대 메모리 동향
메모리 월을 넘기 위한 연구는 HBM 세대 갱신을 넘어 더 근본적인 방향으로도 향합니다.
- **인메모리 컴퓨팅**: 데이터를 연산기로 가져오는 대신, 메모리 안에서 직접 연산하려는 접근입니다. 데이터 이동 자체를 줄이는 가장 급진적인 방법입니다. "데이터를 옮겨 계산한다"는 폰 노이만 구조의 전제 자체를 뒤집으려는 시도라, 성공하면 메모리 월을 근본부터 무너뜨릴 잠재력이 있습니다.
- **포토닉 인터커넥트**: 전기 대신 빛으로 데이터를 실어 날라, 칩 사이 통신의 대역폭과 에너지 효율을 끌어올리려는 연구입니다(Lightmatter 등, DARPA 관련 프로젝트 포함).
- **광/포토닉 텐서코어**: 빛으로 행렬 연산 자체를 수행하려는 더 먼 미래의 연구입니다.
- **칩렛·고급 패키징**: 여러 작은 칩(chiplet)을 한 패키지에 촘촘히 붙여, 칩 간 거리를 줄이고 대역폭을 높입니다.
이 연구들은 아직 대부분 상용화 초기이거나 연구 단계지만, 방향은 일관됩니다. 결국 메모리 월의 본질, 즉 데이터 이동 비용을 줄이는 것입니다.
세 가지 접근의 큰 그림
차세대 메모리 연구를 큰 그림으로 묶으면, 메모리 월에 맞서는 전략은 결국 세 갈래입니다.
메모리 월에 맞서는 세 가지 전략 (개념)
1. 더 빨리 나르기: HBM 세대 갱신, 포토닉 인터커넥트
(데이터 이동을 더 빠르고 효율적으로)
2. 덜 나르기: 양자화, 희소성, 데이터 재사용, 온칩 SRAM
(애초에 이동할 데이터를 줄임)
3. 안 나르기: 인메모리 컴퓨팅, 웨이퍼스케일
(데이터를 옮기는 대신 제자리에서 처리)
흥미로운 점은, 이 세 전략이 서로 배타적이지 않다는 것입니다. 실제 시스템은 셋을 조합합니다. 빠른 HBM을 쓰면서(1번), 양자화로 읽을 바이트를 줄이고(2번), 온칩 SRAM에 데이터를 가둬 재사용합니다(3번에 가까움). 개발자가 직접 통제할 수 있는 것은 주로 2번입니다. 하드웨어가 1번과 3번을 제공하더라도, 양자화·캐시 관리·데이터 지역성 같은 소프트웨어 선택으로 "덜 나르기"를 실천하는 것은 우리 몫입니다. 그래서 메모리 월은 칩 설계자만의 문제가 아니라 모든 AI 개발자의 문제입니다.
9. 개발자가 이해할 시사점
칩을 설계하지 않는 개발자에게도 메모리 월의 이해는 실질적인 무기가 됩니다.
- **추론은 보통 메모리 바운드입니다.** 그래서 더 빠른 칩을 사기 전에, 양자화·KV 캐시 관리·배칭으로 먼저 대역폭을 아끼는 것이 비용 대비 효과가 큽니다.
- **양자화는 메모리를 줄이는 동시에 속도를 올립니다.** FP8/INT8 서빙을 진지하게 검토하세요. 이는 메모리 바운드 세계에서만 성립하는 다소 반직관적인 사실이므로, 한 번 제대로 이해해 두면 평생 써먹습니다.
- **문맥 길이는 공짜가 아닙니다.** 긴 문맥은 KV 캐시를 통해 메모리와 대역폭을 직접 소모합니다. 정말 필요한 길이인지 따져보세요.
- **용량과 대역폭을 구분하세요.** "모델이 들어가는가"와 "충분히 빠른가"는 다른 질문입니다.
- **데이터 지역성을 의식하세요.** 같은 데이터를 반복해 쓰도록 코드를 구성하면, 비싼 메모리 왕복을 줄일 수 있습니다.
메모리 최적화 체크리스트
추론 비용이 고민될 때, 칩을 바꾸기 전에 다음을 순서대로 점검하면 효과가 큽니다.
- [ ] 이 워크로드는 메모리 바운드인가 연산 바운드인가? (프로파일링으로 확인)
- [ ] 저정밀(FP8/INT8) 서빙을 적용했는가? 정확도는 검증했는가?
- [ ] KV 캐시를 압축하거나 정밀도를 낮출 여지가 있는가?
- [ ] 정말 필요한 문맥 길이만 쓰고 있는가? 과한 문맥은 없는가?
- [ ] 배칭으로 가중치 읽기를 여러 요청이 공유하게 했는가?
- [ ] 같은 데이터를 반복해 읽는 비효율은 없는가?
이 체크리스트의 항목 대부분은 더 비싼 하드웨어 없이, 소프트웨어만으로 적용할 수 있습니다. 메모리 월을 이해한다는 것은, 곧 이 항목들을 본능적으로 점검하게 된다는 뜻입니다. 그리고 이 점검을 습관화한 팀은, 같은 예산으로 경쟁사보다 더 빠르고 싼 AI 서비스를 운영하게 됩니다. 하드웨어는 누구나 같은 것을 살 수 있지만, 그것을 메모리 월의 관점에서 영리하게 쓰는 능력은 쉽게 복제되지 않는 진짜 경쟁력입니다.
10. 자주 묻는 질문
**Q. 그냥 메모리 용량이 큰 칩을 사면 메모리 문제가 해결되나요?**
A. 아니요. 용량과 대역폭은 다른 자원입니다. 용량이 커서 모델이 들어가도, 대역폭이 부족하면 토큰 생성이 느립니다. 메모리 바운드 추론에서는 대역폭이 속도를 직접 결정하는 경우가 많습니다.
**Q. 양자화하면 정확도가 떨어지지 않나요?**
A. 정밀도를 낮추면 손실 위험은 있지만, 2026년의 정교한 양자화 기법은 그 손실을 매우 작게 유지합니다. 많은 경우 사용자가 체감하기 어려운 수준이며, 그 대가로 얻는 속도·비용 이득이 훨씬 큽니다. 다만 자신의 작업으로 품질을 검증하는 것은 필수입니다.
**Q. 메모리 바운드인지 연산 바운드인지 어떻게 아나요?**
A. 프로파일링 도구로 메모리 대역폭 사용률과 연산기 사용률을 보면 됩니다. 대역폭은 거의 포화인데 연산기가 놀고 있다면 메모리 바운드입니다. 일반적으로 LLM의 토큰 생성 단계는 메모리 바운드, 긴 프롬프트의 prefill 단계는 연산 바운드에 가깝습니다.
**Q. 문맥을 길게 쓰는 것이 왜 비싼가요?**
A. 긴 문맥은 KV 캐시를 키우고, 그 캐시는 용량과 대역폭을 동시에 소모합니다. 게다가 매 토큰 생성 때마다 커진 캐시를 다시 읽어야 하므로, 생성이 길어질수록 토큰당 비용이 늘어납니다. 정말 필요한 문맥 길이인지 따져보는 것이 비용 절감의 출발점입니다.
**Q. 웨이퍼스케일 칩이 메모리 월의 정답인가요?**
A. 하나의 흥미로운 접근이지만 유일한 답은 아닙니다. 거대한 온칩 SRAM으로 HBM 왕복을 없애는 것은 강력하지만, 모든 워크로드·예산에 맞지는 않습니다. HBM 세대 갱신, 양자화, 인메모리·포토닉 연구 등 여러 갈래가 같은 문제를 향해 동시에 나아가고 있습니다.
**Q. 그러면 결국 무엇부터 해야 하나요?**
A. 순서가 있습니다. 첫째, 프로파일링으로 내 워크로드가 메모리 바운드인지 확인합니다. 둘째, 메모리 바운드라면 저정밀 서빙과 KV 캐시 최적화로 읽을 바이트를 줄입니다. 셋째, 배칭으로 가중치 읽기를 공유합니다. 이 세 가지를 다 했는데도 부족할 때, 비로소 더 높은 대역폭의 칩을 고려합니다. 하드웨어 교체는 보통 마지막 카드입니다.
**Q. 이 내용이 학습에도 적용되나요?**
A. 부분적으로요. 학습은 큰 배치로 산술 강도가 높아 추론보다 연산 바운드인 경우가 많습니다. 하지만 학습에서도 활성값·그래디언트의 메모리 이동, 칩 간 통신은 여전히 큰 비용이라, "데이터 이동을 줄여라"는 원리는 학습과 추론 모두에 통합니다. 다만 추론에서 그 효과가 더 직접적이고 극적입니다.
마치며
AI 성능을 가르는 진짜 병목은 흔히 생각하는 연산 능력이 아니라 메모리입니다. 연산은 싸지고 데이터 이동은 비싸진 시대에, 좋은 하드웨어와 좋은 코드는 모두 데이터 이동을 줄이는 방향으로 진화합니다. HBM4 같은 새 메모리, 양자화 같은 소프트웨어 기법, 온칩 SRAM 활용 같은 커널 설계, 그리고 인메모리·포토닉 같은 미래 연구가 모두 이 한 가지 문제를 향합니다.
개발자로서 우리가 할 일은 화려한 TFLOPS 숫자에 현혹되지 않고, "이 워크로드의 진짜 병목이 연산인가 메모리인가"를 물어보는 것입니다. 그 질문 하나가 추론 비용을 절반으로 줄일 수도 있습니다. 메모리 월을 이해하는 것은, 2026년 AI 시스템을 다루는 모든 개발자의 기본기입니다.
기억할 한 문장으로 글을 닫겠습니다. **연산은 싸고 데이터 이동은 비싸다.** 이 한 줄을 마음에 새기면, 새로운 칩이 나오든 새로운 모델이 나오든, 그 아래에서 작동하는 원리를 꿰뚫어 볼 수 있습니다. 칩의 이름은 매년 바뀌지만 이 원리는 변하지 않습니다. 그리고 이 원리를 아는 개발자는, 같은 예산으로 더 빠르고 더 싼 AI 시스템을 만들 수 있습니다.
참고 자료
- roofline 모델(원논문 소개, ACM): [https://dl.acm.org/doi/10.1145/1498765.1498785](https://dl.acm.org/doi/10.1145/1498765.1498785)
- NVIDIA Blackwell 아키텍처: [https://www.nvidia.com/en-us/data-center/technologies/blackwell-architecture/](https://www.nvidia.com/en-us/data-center/technologies/blackwell-architecture/)
- Cerebras (웨이퍼스케일 엔진): [https://www.cerebras.ai/](https://www.cerebras.ai/)
- Lightmatter (포토닉 컴퓨팅): [https://lightmatter.co/](https://lightmatter.co/)
- Google Cloud TPU: [https://cloud.google.com/tpu](https://cloud.google.com/tpu)
- arXiv (AI 시스템·메모리 연구): [https://arxiv.org/list/cs.AR/recent](https://arxiv.org/list/cs.AR/recent)
- SemiAnalysis (메모리·AI 인프라 분석): [https://www.semianalysis.com/](https://www.semianalysis.com/)
현재 단락 (1/180)
AI 하드웨어를 이야기할 때 우리는 흔히 TFLOPS, 즉 초당 부동소수점 연산 횟수를 봅니다. "이 칩은 몇 페타플롭이다"라는 식이죠. 하지만 현장에서 모델을 돌려본 사람이라면 ...