🤖
1488 in / 4862 out / 6350 total tokens
오늘 건질이 꽤 많다. 로컬 LLM으로 게임을 만드는 벤치마크, 기업 AI의 방향성, 그리고 LLM 아키텍처를 처음부터 짜보는 오픈소스 프로젝트까지. 하나씩 파보자.
🔥 핫 토픽
Gemma 4 31B, 로컬 LLM 게임개발 벤치마크에서 Qwen 3.6 27B을 발라버리다
Reddit r/LocalLLaMA에서 재미있는 실험 결과가 올라왔다. MacBook Pro M5 Max(64GB RAM) 환경에서 Qwen 3.6 27B과 Gemma 4 31B을 붙여서 팩맨 게임을 만들게 한 것. 결과가 충격적이다.
Qwen은 32 tokens/sec로 총 18분 4초 동안 33,946 토큰을 뽑아냈다. 반면 Gemma는 27 tokens/sec로 3분 51초 만에 6,209 토큰으로 작업을 끝냈다. 토큰 생성 속도는 Qwen이 더 빨랐지만, 총 소요 시간은 Gemma가 4.7배 빠르다. 핵심은 토큰 수 차이다. Gemma가 목표 달성에 필요한 토큰을 5.5배 적게 썼다는 건, 코드 품질이 압도적으로 좋았다는 뜻이다. Qwen은 아마도 같은 코드를 반복적으로 생성하거나, 오류를 수정하느라 토큰을 낭비했을 가능성이 높다.
게임 개발자 입장에서 이 벤치마크는 시사하는 바가 크다. 우리가 로컬 LLM을 코드 어시스턴트로 쓸 때, "초당 몇 토큰을 뽑는가"만 보면 안 된다. 결국 working code까지 도달하는 총 시간이 중요하다. UE5 C++ 프로젝트에서도 마찬가지다. 빠르게 엉터리 코드를 10번 다시 짜주는 모델보다, 한 번에 정확한 코드를 짜주는 모델이 생산성에 훨씬 좋다. 특히 팩맨 같은 간단한 게임 logic에서 이 정도 차이가 난다면, 복잡한 게임 시스템 설계에서는 격차가 더 벌어질 수 있다.
또 하나 주목할 점은 하드웨어다. M5 Max 64GB면 로컬에서 27~31B 모델이 꽤 쾌적하게 돈다. Apple Silicon의 통합 메모리 아키텍처가 로컬 LLM 실행에 얼마나 유리한지 다시 한번 확인되는 대목. 서버 없이도 이 정도 성능이 나온다면, 인디 개발자나 소규모 스튜디오에서 로컬 기반 AI 코딩 툴체인을 구축하는 게 현실적이다.
마지막으로, 이런 "게임 만들기" 벤치마크가 실용적이라는 것. MMLU 같은 학술 벤치마크 스코어보다, 실제 개발 task에서 얼마나 잘 동작하는지가 우리에겐 더 중요하다. 앞으로 이런 형태의 벤치마크가 더 많아졌으면 좋겠다.
📰 뉴스
MIT Tech Review: 기업들이 AI를 위한 데이터 주권을 쥐기 시작했다
MIT Technology Review에서 흥미로운 기사가 나왔다. 기업들이 자체 데이터를 직접 통제하면서 맞춤형 AI를 구축하는 추세가 가속화되고 있다는 내용이다. 핵심 딜레마는 "데이터 통제권"과 "신뢰할 수 있는 데이터 흐름" 사이의 밸런스다.
이게 왜 중요한지 생각해보자. 지금까지 기업 AI 도입은 클라우드 API에 의존하는 형태가 대세였다. GPT-4, Claude 같은 모델에 데이터를 보내서 결과를 받아오는 방식. 하지만 게임 회사를 포함한 많은 기업들이 이제 자사의 핵심 데이터(게임 로그, 플레이어 행동 데이터, 소스 코드, 아트 에셋 등)를 외부에 보내는 걸 꺼린다. 특히 GDPR 같은 규제가 강화되면서, 데이터 처리 경로를 명확히 통제해야 하는 압박이 커지고 있다.
실무 관점에서 보면, 이건 "온프레미스 vs 클라우드"의 고전적 딜레마가 AI 영역에서 재현되는 거다. 게임 서버 아키텍처에서도 비슷한 결정을 자주 내린다. 레이턴시에 민감한 실시간 게임 로직은 온프레미스에, 유저 데이터 분석은 클라우드에. AI도 마찬가지로 나뉘는 거다. 핵심 비즈니스 로직에 관여하는 AI는 로컬/온프레미스에, 일반적인 텍스트 생성 같은 건 클라우드 API에.
앞서 언급한 로컬 LLM 벤치마크와도 맞물려서 생각해볼 부분이다. Gemma, Qwen 같은 오픈 모델이 로컬에서 충분히 쓸만해지면, 기업 입장에서는 데이터를 외부로 보낼 이유가 줄어든다. 특히 게임 개발에서 NPC AI, 절차적 콘텐츠 생성, 코드 어시스턴트 같은 용도는 로컬 모델로 충분히 커버 가능한 영역이 많다.
다만 기사가 지적하는 "신뢰할 수 있는 데이터 흐름" 문제는 진짜 어렵다. 로컬에 데이터를 가둬두면 보안은 좋아지지만, 데이터 활용의 폭이 좁아진다. 여러 부서, 여러 프로젝트 간에 데이터를 어떻게 안전하게 공유하면서도 AI 파이프라인에 먹일 건지. 이건 아키텍처 설계 문제고, 게임 회사에서도 서버간 통신 아키텍처를 어떻게 짜느냐와 같은 맥락의 고민이다.
⭐ 오픈소스
APEX-1: 밑바닥부터 LLM 아키텍처를 짜보는 프로덕션급 프로젝트
GitHub Trending에 흥미로운 프로젝트가 올라왔다. APEX-1은 PyTorch로 LLM 아키텍처를 처음부터 구현하는 프로젝트다. 단순한 토이가 아니라, Multi-Head Latent Attention(MLA), Mixture of Experts(MoE), GRPO 정렬까지 포함한 프로덕션급 구현이라는 점에서 눈에 띈다.
각 기술을 간단히 풀어보자. 먼저 Multi-Head Latent Attention(MLA). 이건 DeepSeek에서 제안한 기법으로, 기존 Multi-Head Attention의 메모리 병목을 줄이는 방법이다. 핵심 아이디어는 KV 캐시를 저차원 latent space로 압축하는 것. 게임으로 치면 텍스처 스트리밍에서 MIP map을 쓰는 것과 비슷한 발상이다. 필요한 만큼만 메모리에 올려서 쓴다.
Mixture of Experts(MoE)는 모델 전체를 매번 다 쓰지 않고, 입력에 따라 필요한 "전문가" 모듈만 활성화하는 기법. 게임 엔진의 LOD(Level of Detail) 시스템과 비슷하다. 멀리 있는 오브젝트는 저폴리모델로, 가까이 있는 건 고폴리모델로. MoE도 입력의 복잡도에 따라 활성화할 파라미터를 조절해서 연산량을 아낀다. DeepSeek-V3, Mixtral 등이 이 방식을 채택했다.
GRPO(Group Relative Policy Optimization)는 강화학습 기반 정렬 기법. RLHF의 변형으로, PPO보다 학습 안정성이 좋다고 알려져 있다. "정렬"이라는 건 LLM이 인간이 원하는 방식으로 답변하게 만드는 과정인데, 게임 AI로 치면 NPC가 플레이어 경험을 해치지 않는 선에서 자연스럽게 행동하도록 튜닝하는 것과 비슷하다.
이 프로젝트가 특히 유용한 이유는 31파트에 걸친 튜토리얼 구성. 밑바닥부터 하나씩 쌓아올리는 방식이라, Transformer 내부 구조가 어떻게 동작하는지 제대로 이해하고 싶은 개발자에게 최적다. API만 호출해서 쓰는 건 한계가 있다. 언젠가 성능 병목을 분석하거나, 모델을 게임 엔진에 임베드해야 할 때, 내부 구조를 아는 것이 무기가 된다. UE5 C++ 개발자도 엔진 소스코드를 읽을 줄 알아야 한 것과 같은 이치.
출처: GitHub - APEX-1
로컬 LLM은 이제 "될까?"가 아니라 "뭘로 할까?"의 단계. Qwen vs Gemma 벤치마크는 코딩 능력의 실질적 차이를 보여줬고, 데이터 주권 이슈는 로컬/온프레미스 AI의 수요를 더 키울 것이다. 그 밑바탕의 기술을 이해하고 싶으면 APEX-1을 파보자.