🤖
1326 in / 4197 out / 5523 total tokens
🔥 핫 토픽
AI 칩에서 메모리 비용이 전체의 2/3를 차지한다
왜 중요한가: AI 하드웨어의 병목이 연산에서 메모리로 완전히 넘어갔다. GPU 성능을 아무리 끌어올려도 메모리 대역폭과 용량이 따라주지 않으면 무용지물이다. 이건 게임 개발에서도 익숙한 패턴이다. 텍스처 스트리밍이 병목일 때 GPU 연산력을 올리는 게 의미 없는 것과 같다.
업계 맥락: HBM(High Bandwidth Memory) 공급이 NVIDIA의 AI 가속기 성장을 옥죄고 있다. SK하이닉스, 삼성, 마이크론 세 곳밖에 HBM을 제대로 생산하지 못한다. TSMC의 CoWoS(Chip on Wafer on Substrate) 패키징 공정도 병목이다. 메모리를 GPU 다이와 가까이 붙이는 2.5D 패키징 기술이 한계에 다다른 것이다. AMD, Intel, Apple 모두 같은 문제로 골머리를 앓고 있다.
개발자에게 미치는 영향: 모델 최적화의 패러다임이 바뀐다. 파라미터 수를 줄이는 양자화(quantization), KV 캐시 최적화, 어텐션 메커니즘의 메모리 효율 개선이 단순히 'nice to have'가 아니라 'must have'가 됐다. 추론(inference) 비용이 학습(training) 비용을 넘어서는 시대에, 메모리 사용량을 1% 줄이는 게 연산량을 10% 줄이는 것보다 비용 절감 효과가 클 수 있다.
관련 기술 배경: 트랜스포머 아키텍처의 어텐션 레이어는 시퀀스 길이에 대해 O(n²)의 메모리를 필요로 한다. 컨텍스트 윈도우가 128K, 1M 토큰으로 늘어나면서 이게 감당이 안 된다. FlashAttention, Ring Attention 같은 기법들이 메모리 사용량을 O(n)으로 줄이려 시도하지만, 근본적으로 메모리가 비싸다는 문제는 해결하지 못한다. HBM4 세대에서도 가격 하락은 요원하다.
한줄 코멘트: 연산은 싼데 메모리가 비싸다 — 이건 2024년 게임 개발자들이 VRAM 부족에 울부짖던 것과 정확히 같은 문제다.
출처: Epoch AI - AI Chip Component Cost Shares
📰 뉴스
Simon Willison이 Usborne의 'Mad House'를 리뷰하다
왜 중요한가: 80년대 교육용 게임이 2026년에 왜 중요한가? 이 게임이 보여주는 '제약 속의 창의성'이 지금의 AI 프롬프트 엔지니어링과 놀라울 정도로 닮아 있기 때문이다. Simon Willison은 LLM 개발자로 유명하지만, 그의 사고방식에는 이런 레트로 컴퓨팅의 DNA가 깔려 있다.
관련 기술 배경: Usborne의 'Creepy Computer Games'는 1980년대에 출간된 책으로, ZX Spectrum이나 Commodore 64 같은 8비트 컴퓨터에서 돌아가는 게임의 소스코드를 책에 인쇄해놨다. 독자가 직접 타이핑해서 게임을 실행하는 방식이었다. 메모리가 48KB인 기기에서 어떻게 공포 분위기를 연출할 것인가 — 이게 당시 개발자들의 과제였다.
AI 시대와의 연결고리: 제약은 창의성의 어머니라는데, LLM도 마찬가지다. 컨텍스트 윈도우가 제한적이고, 토큰 비용이 들고, 응답 시간이 있다. 이 제약 안에서 최고의 결과를 뽑아내는 게 프롬프트 엔지니어링이다. Usborne 게임들이 48KB로 무서운 분위기를 만들었듯, 4K 컨텍스트로도 훌륭한 결과를 내는 프롬프트 기법이 존재한다. Chain-of-Thought, Few-shot 예시 배치, 시스템 프롬프트 구조화 — 전부 '제약 속 최적화'의 일환이다.
개인적 감상: UE5로 게임 만들면서 항상 느끼는 건데, 나노이트(nanite)로 메시 몇억 폴리곤을 렌더링할 수 있게 된 지금도 결국 가장 중요한 건 '어떤 경험을 줄 것인가'다. 기술의 화려함이 아니라. 8비트 시절 개발자들이 텍스트 몇 줄로 공포를 만들었던 그 감각은, AI로 프로덕트 만들 때도 여전히 유효하다.
한줄 코멘트: 48KB로 공포를 만들던 개발자들과 4K 토큰으로 에이전트를 만드는 우리 사이에는 놀라운 유사성이 있다.
출처: Simon Willison - Mad House: Usborne Creepy Computer Games
⭐ 오픈소스
BrowserLLM — 브라우저에서 100개 이상의 오픈소스 LLM을 실행한다
왜 중요한가: 앞서 언급한 AI 칩의 메모리 비용 문제와 정확히 반대 방향의 접근이다. 서버 사이드의 비싼 GPU 메모리 대신, 사용자의 디바이스에 있는 (쉽게 말해 공짜) 메모리를 활용하는 것이다. WebGPU가 드디어 실용 단계에 올라왔다는 증거이기도 하다.
기술 배경: WebGPU는 브라우저에서 GPU 연산을 직접 수행할 수 있게 해주는 API다. WebGL이 렌더링에 집중했다면, WebGPU는 GPGPU(General Purpose GPU) 연산까지 커버한다. WebLLM 프로젝트가 이걸 이용해 LLM 추론을 브라우저에서 구현했다. TVM(Tensor Virtual Machine)으로 모델을 WebGPU 호환 형태로 컴파일하고, 브라우저에서 직접 실행한다.
게임 개발자 관점에서의 의미: UE5에서 WebGPU 백엔드가 실험적으로 지원되기 시작했다. 이건 단순히 '브라우저 게임'을 넘어선다. 게임 클라이언트 내에 LLM 기반 NPC를 넣고, 그 추론을 서버가 아니라 클라이언트 GPU에서 돌리는 게 가능해진다. 서버 비용 0원. 물론 모델 크기에 제한이 있지만, 7B 파라미터 모델의 양자화 버전이라면 충분히 현실적이다.
현실적인 한계: 브라우저에서 LLM을 돌리면 초기 로딩에 모델 가중치를 다운로드해야 한다. Llama 3.2 3B의 4비트 양자화 버전도 약 2GB. 모바일에서 이건 좀 무겁다. 그리고 WebGPU 지원이 아직 모든 브라우저에 안정적이지 않다. Safari의 WebGPU 구현은 아직 베타 수준이다.
그럼에도 불구하고: 프라이버시가 중요한 애플리케이션에서 이 접근법은 강력하다. 사용자 데이터가 서버로 전송되지 않으니까. 의료, 금융, 개인 메모 앱 — 이런 영역에서 브라우저 내 LLM은 차별화된 가치를 제공한다. 앞서 본 메모리 비용 문제를 사용자 디바이스로 전가하는, 솔직히 꽤 영리한 접근이다.
한줄 코멘트: 서버 비용이 걱정인 인디 개발자에게 '그냥 사용자 GPU 쓰면 되지 않을까?'라는, 반은 진지한 대안.
출처: GitHub - GautamVhavle/BrowserLLM
🔗 세 줄 연결
메모리가 비싸니까(첫 번째 뉴스) 서버 사이드 LLM 운영 비용이 감당이 안 된다. 그래서 브라우저에서 돌리자는 발상(세 번째 뉴스)이 나온다. 그리고 두 번째 뉴스의 48KB 게임처럼, 제약 속에서 돌파구를 찾는 건 개발자의 오랜 전통이다.
AI의 미래는 더 큰 모델이 아니라, 더 똑똑한 배치와 제약 속 최적화에 달려 있다.