구글·마벨 AI 칩 해설: 추론 시대에 AI 인프라팀이 이제 FLOPS보다 메모리 병목부터 다시 설계해야 하는 이유

발행일: 2026-04-20 | 카테고리: 개발정보

1) 문제 정의

핵심 요약: AI 서비스가 커질수록 병목은 모델 계산량 자체보다, 가중치와 KV 캐시를 얼마나 빨리 옮기고 붙잡아 두느냐로 이동합니다.

AI타임스는 2026년 4월 20일, 구글이 마벨과 함께 TPU와 짝을 이루는 메모리 처리 유닛(MPU)과 차세대 TPU를 논의 중이라고 보도했습니다. 이 소식이 중요한 이유는 단순히 새로운 칩 하나가 나온다는 데 있지 않습니다. 구글이 추론 인프라를 볼 때 이제 연산 칩 하나만 세게 만드는 방식으로는 부족하다고 공개적으로 드러냈다는 점이 더 중요합니다.

이 글은 AI 인프라팀, 플랫폼 엔지니어, MLOps 리드, 추론 비용을 관리해야 하는 백엔드 팀을 위한 해설입니다. 범위는 왜 메모리 병목이 추론 경쟁의 핵심이 되었는지, TPU+메모리 보조 칩 구조가 무엇을 해결하려는지, 기존 GPU 중심 설계와 비교해 어떤 판단 기준이 필요한지입니다. 반대로 개인 개발자의 소규모 데모 서비스에는 여기서 말하는 하드웨어 분리 설계가 과할 수 있습니다.

2) 먼저 결론

핵심 요약: 이번 뉴스의 본질은 구글이 칩 숫자를 늘린다는 뜻이 아니라, 추론 성능을 계산 성능과 메모리 성능으로 분리해서 최적화하겠다는 방향 전환입니다.

• 지금 바로 참고해야 할 팀: 긴 문맥, 대형 모델, 멀티모달 추론, 에이전트형 워크로드를 운영하는 팀
• 아직 관찰이 더 나은 팀: 모델 크기가 작고, GPU 한 종류로도 비용과 지연시간이 충분히 맞는 초기 서비스
• 제 판단: 앞으로 추론 인프라의 핵심 질문은 "어느 칩이 더 많은 TFLOPS를 내나"보다 "메모리 대역폭, 캐시 유지, 데이터 이동 경로를 어떻게 줄이느냐"가 됩니다.

즉, 인프라팀은 이제 모델 선택과 칩 선택만 보지 말고 연산 계층, 메모리 계층, 칩 간 연결 계층을 따로 봐야 합니다. 이 관점이 없으면 GPU를 더 사도 실제 서비스 지연시간과 비용이 기대만큼 줄지 않는 이유를 설명하기 어렵습니다.

3) 핵심 구조 분해

핵심 요약: 구글이 노리는 구조는 "큰 두뇌 하나"보다 "계산 담당과 메모리 담당을 나눠 붙이는 구조"에 가깝습니다.

1. 계산 레이어: TPU가 행렬 연산과 모델 실행의 중심을 담당합니다.
2. 메모리 레이어: 기사에서 언급된 MPU는 데이터 이동과 메모리 처리 병목 완화에 초점을 둡니다.
3. 연결 레이어: TPU와 메모리 보조 칩 사이를 어떻게 연결하느냐가 실제 체감 성능을 좌우합니다.
4. 배치 레이어: 긴 문맥, 큰 KV 캐시, 대형 배치, 멀티모달 입력이 들어올수록 메모리 압박이 커집니다.
5. 운영 레이어: 목표는 벤치마크 점수보다, 같은 전력과 같은 랙에서 더 많은 추론 요청을 안정적으로 처리하는 것입니다.

초보 개발자 기준으로 쉽게 말하면, TPU는 계산기이고 MPU는 그 계산기가 자료를 기다리며 멈추지 않게 도와주는 창고 관리자에 가깝습니다. 계산기가 아무리 빨라도 필요한 데이터가 제때 안 오면 전체 속도는 느려집니다. 대형 언어모델의 추론은 특히 이 문제가 심합니다. 첫 토큰 이전보다, 이후 토큰을 계속 뽑아내는 decode 단계에서 메모리 접근이 훨씬 중요해지기 때문입니다.

4) 설계 의도 해설

핵심 요약: 구글의 설계 의도는 연산 성능 자랑보다, 추론 수요 폭증 시 메모리 벽 때문에 생기는 낭비를 줄이려는 데 있습니다.

Google은 2025년 공개한 Ironwood TPU에서 이미 추론 시대를 전면에 내세웠습니다. 공식 블로그에 따르면 Ironwood는 추론 전용으로 설계된 첫 TPU이며, 칩당 HBM 용량 192GB, 대역폭 7.37TB/s를 제공합니다. 그런데 같은 Google Cloud 문서도 HBM이 여전히 메모리 집약적 워크로드의 병목이 될 수 있다고 직접 설명합니다. 즉, 메모리를 크게 늘려도 문제는 끝나지 않았다는 뜻입니다.

여기서 기사 속 MPU 논의가 의미를 갖습니다. 추론 workloads에서는 모델 파라미터, KV 캐시, 임베딩, 중간 활성값이 계속 움직입니다. 구글은 TPU만 키우는 대신, 이 데이터 이동 계층을 별도로 최적화해 전체 효율을 올리려는 것으로 읽힙니다.

• 얻는 것: 메모리 병목 완화, 추론 처리량 개선, 전력 대비 효율 향상 가능성
• 포기하는 것: 칩 구조 복잡도 증가, 소프트웨어 최적화 부담, 공급망과 패키징 난도 상승
• 실무 해석: 앞으로 추론 하드웨어는 단일 범용 가속기보다, 여러 역할을 나눈 조합형 설계가 늘어날 가능성이 큽니다.

이 흐름은 구글만의 예외가 아닙니다. Marvell은 2024년 말 공식 발표에서 커스텀 HBM 아키텍처를 통해 최대 25% 더 많은 연산 영역, 최대 33% 더 많은 메모리, 최대 70% 낮은 인터페이스 전력을 언급했습니다. 즉, 업계 전체가 이미 "계산 칩만 빠르면 된다"는 단계를 지나고 있습니다.

5) 근거 및 비교

핵심 요약: 비교 기준은 브랜드가 아니라, 메모리 병목을 어떤 방식으로 푸느냐입니다.

공식 자료를 묶어 보면 판단 기준은 더 선명해집니다.

• Google TPU7x 문서: 칩당 HBM 192GB, 약 7.37TB/s, 그리고 HBM이 여전히 병목이 될 수 있다고 명시
• NVIDIA Blackwell 공식 페이지: 5세대 NVLink로 최대 576 GPU 확장, NVL72에서 130TB/s GPU 대역폭 강조
• Marvell 공식 발표: 커스텀 HBM 아키텍처로 최대 25% 추가 연산 영역, 33% 메모리 증가, 70% 인터페이스 전력 절감 주장
• Groq 공식 페이지: GPU만이 아니라 추론 전용 커스텀 실리콘 스택이 필요하다는 점을 전면에 내세움

결국 차이는 이렇습니다. NVIDIA는 거대한 연결망으로 대형 GPU를 묶는 방향이 강하고, Groq는 추론 특화 전용 칩을 밀고 있으며, 구글은 TPU 기반에서 메모리 계층을 더 세분화하는 방향으로 보입니다. 즉 경쟁의 축이 "누가 더 큰 GPU를 만드나"에서 "누가 메모리 벽을 더 영리하게 우회하나"로 이동 중입니다.

6) 단계별 실행 방법

핵심 요약: 지금 팀이 당장 해야 할 일은 새 칩을 기다리는 것이 아니라, 현재 추론 병목이 계산인지 메모리인지 먼저 분해하는 것입니다.

1. 워크로드를 둘로 나눕니다.
   prefill 중심인지, decode 중심인지 구분합니다. 긴 대화형 서비스는 보통 decode 병목이 더 큽니다.
2. 메모리 지표를 따로 봅니다.
   GPU 활용률만 보지 말고 HBM 사용량, KV 캐시 크기, 배치 크기별 토큰 처리량을 측정합니다.
3. 데이터 이동 경로를 줄입니다.
   모델 파티셔닝, 캐시 오프로딩, 프롬프트 압축, 세션 만료 정책을 함께 점검합니다.
4. 하드웨어보다 요청 패턴을 먼저 조정합니다.
   짧은 응답이 중요한 경로와 긴 추론이 필요한 경로를 분리하면 메모리 압박을 줄이기 쉽습니다.
5. 대체 아키텍처를 소규모로 시험합니다.
   GPU 단일 경로, TPU 경로, 추론 특화 공급자를 같은 평가셋으로 비교합니다.

# 최소 운영 점검 질문
1. 우리 서비스의 p95 지연시간은 prefill 때문인가 decode 때문인가
2. 배치를 키웠을 때 GPU 사용률은 오르는데 토큰당 비용이 왜 안 내려가는가
3. KV 캐시가 전체 메모리의 몇 퍼센트를 잡아먹는가
4. 긴 문맥 사용자가 전체 요청의 몇 퍼센트인가
5. 캐시 만료 정책을 조정하면 HBM 압박이 줄어드는가

많은 팀이 여기서 실수합니다. 하드웨어 세대가 바뀌면 자동으로 비용이 좋아질 거라고 기대합니다. 하지만 실제로는 요청 패턴, 캐시 정책, 모델 라우팅을 먼저 손보는 쪽이 효과가 더 클 때가 많습니다.

7) 함정과 실수

핵심 요약: 추론 인프라의 실패는 연산 부족보다 메모리 병목을 너무 늦게 보는 데서 자주 나옵니다.

• 실수 1: GPU 활용률이 높으면 잘 쓰고 있다고 착각
  예방: 토큰당 비용, decode 속도, 메모리 압박을 같이 봐야 합니다. 복구: 배치 크기와 KV 캐시 지표를 추가해 병목을 다시 해석합니다.
• 실수 2: 긴 문맥 요청을 일반 요청과 같은 경로로 처리
  예방: 긴 문맥 전용 경로 또는 고메모리 노드를 분리합니다. 복구: 라우팅 규칙을 추가해 HBM 압박을 분산합니다.
• 실수 3: 벤더 비교를 FLOPS 숫자만으로 끝냄
  예방: 메모리 용량, 대역폭, 칩 간 연결, 소프트웨어 성숙도를 함께 봅니다. 복구: 평가표를 다시 만들고 추론형 워크로드 지표를 넣습니다.
• 실수 4: 캐시 정책 없이 에이전트형 워크로드를 확장
  예방: 세션 길이와 재사용률을 기준으로 캐시 수명을 설계합니다. 복구: 오래된 세션과 긴 문맥 요청을 분리해 비용을 낮춥니다.

8) 강점과 한계

핵심 요약: 메모리 중심 설계는 추론 시대에 맞지만, 모든 팀이 바로 전용 구조를 따라갈 필요는 없습니다.

• 강점: 실제 추론 병목을 더 정확히 겨냥하고, 전력과 랙 공간 대비 처리량 개선 여지가 큽니다.
• 강점: 긴 문맥, 멀티모달, 에이전트형 서비스처럼 메모리 집약적 워크로드에 특히 의미가 큽니다.
• 한계: 하드웨어와 소프트웨어 공동 최적화가 필요하고, 범용 생태계가 늦게 따라올 수 있습니다.
• 반례: 짧은 응답 중심, 작은 모델 중심 서비스는 여전히 일반 GPU 운영이 더 단순하고 싸게 맞을 수 있습니다.

따라서 제 추천은 단순합니다. 대형 추론 서비스를 운영하는 팀은 지금부터 메모리 병목 관점의 지표 체계를 갖춰야 하지만, 소형 서비스는 하드웨어 교체보다 요청 설계와 캐시 정책부터 손보는 편이 낫습니다.

9) 더 깊게 공부할 포인트

핵심 요약: 다음 단계 학습은 칩 이름 외우기가 아니라, 추론이 메모리 집약적으로 변하는 이유를 운영 지표로 이해하는 것입니다.

• KV 캐시 크기와 긴 문맥이 실제 비용에 주는 영향
• HBM 대역폭과 칩 간 인터커넥트가 decode 성능에 미치는 차이
• 범용 GPU, TPU, 추론 특화 칩을 같은 평가셋으로 비교하는 방법
• 에이전트형 워크로드에서 세션 재사용과 캐시 정책을 어떻게 설계할지

10) 실행 체크리스트 + 작성자 관점

핵심 요약: 추론 시대 인프라팀의 기본 자세는 더 큰 칩을 기다리는 것이 아니라, 메모리 벽을 숫자로 확인하고 우회하는 것입니다.

• 우리 서비스의 병목을 prefill과 decode로 분리해 보고 있는가?
• GPU 또는 TPU 사용률 외에 HBM 사용량과 KV 캐시 지표를 수집하는가?
• 긴 문맥 요청과 일반 요청을 다른 경로로 라우팅할 수 있는가?
• 하드웨어 비교 시 FLOPS 외에 메모리 용량, 대역폭, 인터커넥트를 함께 보고 있는가?
• 에이전트형 세션의 캐시 만료 정책과 재사용 정책이 문서화되어 있는가?
• 새 하드웨어 도입 전, 현재 요청 패턴과 캐시 정책부터 최적화했는가?

Definition of Done: 팀이 현재 추론 병목이 계산인지 메모리인지 수치로 구분하고, 긴 문맥과 일반 요청의 분리 운영 전략을 문서화했다면 1차 준비가 된 것입니다.

제 추천은 명확합니다. 이번 구글·마벨 뉴스는 새 칩 소식이 아니라, 인프라 평가 기준이 이미 메모리 중심으로 이동했다는 신호로 읽어야 합니다. 따라서 중대형 AI 서비스 팀은 지금부터 메모리 병목 관측, 캐시 정책, 요청 라우팅 체계를 먼저 손보는 편이 맞습니다. 반대로 아직 작은 서비스라면 새 칩 뉴스에 흔들리기보다 현재 스택에서 병목을 정확히 측정하는 것이 우선입니다.

참고자료

• AI타임스 - 구글, 마벨과 AI 칩 2종 개발 논의 중...추론 수요 확대 대비 (기사일: 2026-04-20, 확인일: 2026-04-20)
• Google Blog - Ironwood: The first Google TPU for the age of inference (게시일: 2025-04-09, 업데이트: 2025-04-23, 확인일: 2026-04-20)
• Google Cloud Docs - TPU7x (Ironwood) (확인일: 2026-04-20)
• Marvell - Breakthrough custom HBM compute architecture to optimize cloud AI accelerators (게시일: 2024-12-10, 확인일: 2026-04-20)
• NVIDIA - Blackwell Architecture (확인일: 2026-04-20)
• Groq - Fast, low cost inference with custom silicon (확인일: 2026-04-20)