딥러닝 최적화 글이 다시 뜬 이유

Horace He의 2022년 글 Making Deep Learning Go Brrrr From First Principles이 다시 공유된 것은 우연이 아니다. 글의 핵심은 딥러닝 성능을 마법 같은 팁 모음으로 보지 말고 compute, memory bandwidth, overhead 세 영역으로 나누라는 것이다. GPU가 312테라플롭스를 낼 수 있어도 데이터 이동과 파이썬 오버헤드에 막히면 돈 낸 만큼의 연산을 쓰지 못한다.

2026년 AI 인프라 시장에서 이 메시지는 더 중요해졌다. 대형 모델 경쟁은 여전히 계속되지만, 실제 기업은 제한된 GPU 예산으로 추론 지연시간과 학습 비용을 줄여야 한다. AI 에이전트도 클라우드 비용을 알아야 한다가 비용 인식을 말했듯, 딥러닝 최적화는 연구자의 취미가 아니라 제품 손익의 일부가 됐다.

병목을 모르면 최적화는 미신이 된다

글은 성능을 세 가지 시간으로 나눈다. compute는 실제 행렬곱과 부동소수점 연산에 쓰는 시간이다. memory는 텐서를 GPU 내부에서 옮기는 시간이다. overhead는 파이썬 런타임, 커널 런치, 프레임워크 디스패치, 작은 연산들이 만드는 기타 비용이다. PyTorch Performance Tuning Guide도 같은 방향을 제시한다. 병목이 어디인지 측정하지 않고 in-place 연산, 특정 버전 고정, 무작정 C++ 재작성으로 뛰어들면 시간만 쓴다.

Roofline model 논문은 이 사고방식의 고전적 배경이다. 연산량 대비 메모리 이동량을 보면 하드웨어 한계 중 어디에 막혔는지 감을 잡을 수 있다. AI 팀이 매번 새 모델을 붙일 때 이 분석을 하지 않으면 GPU 증설만 반복하게 된다.

에이전트 시대에는 추론 최적화도 중요하다

과거 성능 최적화는 주로 학습팀의 일이었다. 이제는 다르다. 코딩 에이전트, RAG 검색, 음성 에이전트, 멀티모달 UI는 모두 짧은 지연시간과 낮은 비용을 요구한다. Multi-Stream LLM, 에이전트 병목을 구조로 풀려는 시도는 모델 내부 병목을 구조적으로 나누려는 흐름을 보여준다. 하지만 제품팀이 먼저 해야 할 일은 프로파일러로 현재 병목을 보는 것이다.

NVIDIA의 성능 분석 문서는 GPU 활용률, kernel timeline, 메모리 대역폭을 함께 보라고 권한다. 로컬 모델을 쓰는 팀이라면 Forge, 작은 로컬 모델을 에이전트로 쓰는 법에서처럼 작은 모델의 장점을 살리되, 토큰 생성·도구 호출·검색 대기 시간이 어디서 발생하는지 분해해야 한다.

한국 개발팀의 실무 변화

한국 기업은 GPU를 대량으로 선점한 빅테크와 같은 방식으로 경쟁하기 어렵다. 그래서 최적화 역량은 방어 전략이다. 모델 선택 단계에서 파라미터 수만 비교하지 말고 실제 workload의 토큰 길이, batch 크기, 동시 사용자, retrieval 횟수, 도구 호출 대기시간을 측정해야 한다. Models.dev, 모델 선택을 데이터 문제로 바꾸다가 모델 비교를 데이터화하려 한 이유도 여기에 있다.

개발 문화도 바뀐다. “GPU가 느리다”는 말은 더 이상 충분한 버그 리포트가 아니다. 어떤 shape의 연산에서, 어떤 batch에서, GPU utilization과 memory bandwidth가 얼마였는지 남겨야 한다. PyTorch profiler나 Nsight 같은 도구가 제품 로그만큼 중요해진다.

결론

이 글이 다시 읽히는 이유는 단순하다. AI 인프라 비용이 커질수록 성능 최적화는 더 근본적인 제품 역량이 된다. 좋은 팀은 트릭을 많이 아는 팀이 아니라, 병목을 분류하고 측정하며 비용으로 번역하는 팀이다.

FAQ

Horace He 글의 핵심 메시지는 무엇인가?

딥러닝 성능을 compute, memory bandwidth, overhead로 나누고 현재 병목에 맞는 최적화를 하라는 것이다.

왜 2022년 글이 지금도 중요하나?

GPU 비용과 추론 지연시간이 제품 경쟁력의 핵심이 되면서 기본 원리가 더 중요해졌기 때문이다.

compute bound와 memory bound는 어떻게 다르나?

compute bound는 연산 장치가 바쁜 상태이고, memory bound는 데이터 이동이 연산보다 더 큰 병목인 상태다.

에이전트 제품에도 적용되나?

그렇다. 에이전트는 모델 추론, 검색, 도구 호출, 후처리가 결합되어 있어 각 단계의 병목을 나눠 봐야 한다.

개발팀의 첫 단계는 무엇인가?

프로파일러로 실제 workload를 측정하고, 병목 유형을 확인한 뒤 최적화 실험을 작은 단위로 기록하는 것이다.