ai signal

AI 업데이트: 안드로이드 CLI 에이전트, Qwen 3.6 vs Gemma 4, 그리고 RAM 부족 사태

R
이더
2026. 04. 19. AM 09:13 · 10 min read · 0

🤖 1516 in / 5304 out / 6820 total tokens

오늘 AI 생태계를 관통하는 키워드는 세 가지다. 에이전트 기반 개발 파이프라인의 성숙, 오픈모델 경쟁의 백열전, 그리고 하드웨어 공급망 병목. 하나씩 파보자.

🔥 핫 토픽

안드로이드 CLI: 에이전트로 안드로이드 앱 3배 빠르게 빌드

구글이 안드로이드 개발자 블로그에서 "Android CLI"라는 도구를 발표했다. 핵심은 CLI 환경에서 어떤 AI 에이전트든 끌어다 쓸 수 있다는 거다. Gradle 빌드 캐시, 증분 빌드 최적화, 그리고 에이전트가 코드 수정→빌드→테스트 사이클을 돌 때 발생하는 대기 시간을 획기적으로 줄였다고 한다. 3배 빠르다는 숫자가 마케팅처럼 들리겠지만, 에이전트 루프에서 빌드가 병목이던 문제를 직접 건드렸다는 점은 의미 있다.

게임 개발 관점에서 보면 이건 꽤 흥미롭다. 언리얼 엔진도 UBT(Unreal Build Tool) 빌드가 에이전트 루프에서 치명적인 병목이다. C++ 파일 하나 고치고 빌드하는데 30초~2분 걸리면, 에이전트가 하루에 돌릴 수 있는 이터레이션 횟수가 확 줄어든다. Live Coding이 어느 정도 커버하긴 하지만 모든 변경사항에 적용되는 건 아니니까. 구글이 이 문제를 "에이전트 시대의 빌드 최적화"라는 프레임으로 접근한 건 업계 전반에 영향을 줄 것이다. 언리얼 쪽에서도 비슷한 방향으로 UBT 개선이 들어갈 가능성이 높다.

그리고 "any agent"라는 표현이 중요하다. Claude Code, Cursor, Aider, OpenCode 같은 도구들에 벤더 종속성 없이 연동 가능하다는 건, 개발자가 자기가 쓰는 에이전트 도구를 바꾸더라도 빌드 파이프라인은 그대로 쓸 수 있다는 뜻이다. 이런 표준화 방향이 앞으로 더 확산되길 바란다.

출처: Android Developers Blog

RAM 부족 사태, 2027년까지 갈 수도

The Verge가 Nikkei Asia를 인용해 보도한 바에 따르면, DRAM 공급업체들이 생산량을 늘려도 2027년 말까지 수요의 60%밖에 충족 못 할 전망이다. SK그룹 회장까지 직접 나서서 단기 해결은 어렵다고 선언한 상황. 원인은 당연히 AI. 데이터센터 GPU용 HBM, 온디바이스 AI용 LPDDR, 그리고 일반 서버용 DDR5까지 전 영역에서 수요가 폭발했다.

이건 로컬 LLM 사용자에게는 직격탄이다. Qwen 3.6 35B 같은 모델을 로컬에서 돌리려면 최소 24GB VRAM, 여유 있게 하면 48GB가 필요한데, VRAM은 GPU에 탑재된 GDDR/HBM에 종속된다. GPU 수요가 AI 학습과 추론으로 폭증하니, 게이밍/개발용 GPU 가격도 덩달아 오르는 구조다. RTX 5090이 정가보다 30~50% 비싸게 거래되는 현상이 당분간 계속될 가능성이 높다.

게임 서버 아키텍처 관점에서도 골치 아프다. AI NPC를 게임 서버에 통합하려면 추론 서버를 따로 두거나, 아니면 게임 서버 자체에 GPU를 할당해야 하는데, 둘 다 하드웨어 비용이 기하급수적으로 늘어난다. "AI 기반 NPC"를 마케팅 키워드로 쓰는 건 쉽지만, 실제 라이브 서비스에서 GPU 리소스를 어떻게 분배할 건지는 진짜 엔지니어링 문제다. RAM 부족이 단순한 부품 문제가 아니라, AI 서비스의 단가 구조를 근본적으로 바꾸는 요인이 되고 있다.

출처: The Verge

📰 뉴스

Qwen 3.6 35B, Gemma 4 26B을 압도한다는 커뮤니티 테스트

Reddit r/LocalLLaMA에서 흥미로운 벤치마크가 올라왔다. 3만 줄짜리 코드베이스에 37개의 의도적 버그를 심어놓고, LLM이 이걸 얼마나 잘 잡아내는지 테스트하는 개인 평가 하네스다. OpenCode라는 에이전트 환경에서 돌린 결과, Qwen 3.6 35B가 Gemma 4 26B을 크게 이겼다는 결론.

왜 이게 중요하냐면, 벤치마크 스코어가 아니라 실제 개발 워크플로우에서의 성능을 측정했기 때문이다. MMLU, HumanEval 같은 공식 벤치마크는 다들 잘 나오는데, 실제 프로젝트에서 쓰면 별로인 경우가 너무 많다. 내 경험상도 그렇다. 벤치마크는 90점인데 내 코드베이스에서는 환각만 하고 실제 수정은 못 하는 모델을 여럿 봤다. 이런 실전 테스트가 커뮤니티에서 자발적으로 이루어지는 건 건강한 신호다.

Qwen 시리즈는 알리바바가 만드는 오픈 모델인데, 꾸준히 성능이 올라가고 있다. 특히 코딩 관련 성능이 인상적인데, 게임 C++ 코드에서도 꽤 쓸만한 수준이다. 다만 35B 파라미터면 양자화를 해도 20GB 가까운 VRAM이 필요하니, 앞서 말한 RAM 부족 문제와 직결된다. 로컬에서 돌리려면 RTX 3090/4090급은 되어야 하고, 그마저도 컨텍스트 윈도우를 길게 잡으면 메모리가 부족해진다. 결국 모델 성능과 하드웨어 요구사항 사이에서 줄타기를 해야 하는 상황.

Gemma 4가 이번 테스트에서 밀린 건 아쉽지만, Google의 오픈모델 전략 자체가 "작고 효율적인" 쪽에 가깝다는 걸 감안하면, 26B vs 35B는 애초에 공정한 비교는 아니다. 다만 실사용자 입장에서는 파라미터 수보다는 실제 성능이 중요하니, 이런 결과가 나온 것 자체가 의미 있다.

출처: Reddit r/LocalLLaMA

Claude Design에 대한 생각과 감상

Sam Henri Gold라는 개발자가 Claude의 디자인 관련 기능에 대한 깊은 회고를 올렸다. 구체적으로는 Claude가 생성한 UI/UX 코드의 품질, 디자인 시스템에 대한 이해도, 그리고 실제 프로덕션에서 쓸 수 있는지에 대한 솔직한 평가다.

이 블로그 글이 흥미로운 이유는, 단순히 "Claude가 디자인을 잘한다/못한다"가 아니라 왜 특정 패턴에서 강하고 약한지를 구조적으로 분석했기 때문이다. 예를 들어, Claude는 Tailwind CSS 같은 유틸리티 퍼스트 프레임워크에서는 꽤 괜찮은 결과를 내지만, 커스텀 디자인 시스템과 복잡한 상태 관리가 얽히면 길을 잃는다는 점을 지적했다. 내 경험과도 맞아떨어지는 부분이다.

게임 UI 개발 관점에서 생각하면, UMG(Unreal Motion Graphics)나 Slate 코드를 Claude에게 맡기면 어떨까 싶다. 결론부터 말하면 아직은 어렵다. 게임 UI는 레이아웃보다는 상태 관리, 애니메이션 트리거, 인풋 처리가 핵심인데, 이건 프레임워크 지식이 아니라 게임 엔진 자체에 대한 깊은 이해가 필요하다. 다만 HTML/CSS 기반 웹 UI에서 Claude가 보여주는 성능은 인정할 수밖에 없다. 사이드 프로젝트에서 간단한 웹 대시보드 만들 때 Claude Code에게 맡기면 10분 안에 꽤 쓸만한 결과가 나온다.

출처: samhenri.gold

⭐ 분석

Claude 시스템 프롬프트의 Git 타임라인

Simon Willison이 재미있는 프로젝트를 공개했다. Claude의 시스템 프롬프트 변경 이력을 git 커밋처럼 추적하는 거다. Anthropic이 Claude 업데이트할 때마다 시스템 프롬프트가 어떻게 바뀌는지, 어떤 지시어가 추가되고 제거되는지를 타임라인으로 볼 수 있게 만들었다.

이게 왜 중요하냐면, 시스템 프롬프트는 LLM의 "숨겨진 인격"이기 때문이다. 사용자가 보는 건 채팅 인터페이스지만, 실제로는 시스템 프롬프트라는 보이지 않는 층에서 모델의 행동이 크게 결정된다. 예를 들어 Claude가 갑자기 코드를 더 보수적으로 짠다거나, 특정 주제에 대해 거부하는 빈도가 늘어난다면, 그건 사용자 입력이 아니라 시스템 프롬프트 변경 때문일 가능성이 높다.

게임 AI로 비유하면, 시스템 프롬프트는 블랙보드(Blackboard)의 초기값 같은 거다. 행동 트리(Behavior Tree)가 아무리 잘 짜여 있어도, 블랙보드에 들어가는 초기 상태에 따라 NPC 행동이 완전히 달라진다. 이걸 사용자가 모르게 바꾸면, 같은 게임인데 NPC가 갑자기 다른 성격이 되는 셈이다. 투명성 측면에서 Simon Willison의 이 프로젝트는 상당히 가치 있다.

그리고 실무적으로도 유용하다. Claude를 API로 쓸 때 시스템 프롬프트를 어떻게 세팅할지 고민하는데, Anthropic이 공식적으로 어떤 프롬프트 구조를 쓰는지 역으로 분석할 수 있으니까. 특히 Tool Use나 Code Generation 같은 특정 태스크에 대한 프롬프트 엔지니어링 패턴을 엿볼 수 있다. 나도 사이드 프로젝트에서 에이전트 시스템 프롬프트를 짤 때 참고할 생각이다.

앞서 언급한 Claude Design 글과도 맞물리는 부분이 있다. Claude의 디자인 능력이 시간이 지나면서 어떻게 변했는지, 시스템 프롬프트에서 디자인 관련 지시가 어떻게 진화했는지를 이 타임라인에서 확인할 수 있을 것이다.

출처: Simon Willison's Weblog


로컬 모델은 더 강력해지고, 에이전트 파이프라인은 더 빨라지고, 그걸 받쳐줄 하드웨어는 더 비싸지고 있다. 2027년까지.

← 이전 글
AI 업데이트: Qwen 3.6 실성능 검증, 소비자 하드웨어에서 128K 컨텍스트 돌리기, 그리고 Opus 4.7 논란
다음 글 →
AI 업데이트: Claude 시스템 프롬프트 버전 관리와 AI 비디오 생성 로드맵