🤖
1375 in / 5038 out / 6413 total tokens
🔥 핫 토픽: 초당 10토큰, 체감상 얼마나 빠른 걸까?
How fast is 10 tokens per second really?
Simon Willison이 Claude의 추론 속도에 대해 깊이 파고든 글이다. 초당 10토큰이라는 숫자가 실제 사용자 경험에서 어떤 의미를 갖는지, 그리고 이것이 "충분히 빠른가"라는 질문에 답을 시도한다. 핵심은 단순한 벤치마크 숫자를 넘어서, 토큰 속도가 사용자의 사고 흐름과 어떻게 맞물리는지에 있다.
이 글이 중요한 이유는 속도가 AI 도구의 실용성을 결정하는 핵심 변수이기 때문이다. 게임 개발에서도 16ms 프레임 예산 안에 모든 걸 넣어야 하듯, AI 응답도 사용자의 인내심 예산 안에 들어와야 한다. 체감 지연 시간이 200ms를 넘으면 사용자는 "느리다"고 느끼고, 1초를 넘으면 다른 일을 시작한다. 초당 10토큰은 영어 기준으로 대략 분당 400단어에 해당하는데, 이는 일반적인 독서 속도보다 약간 빠른 정도다. 즉, 출력을 읽으면서 따라갈 수 있을 만큼 빠르지만, 코드 리뷰나 긴 문서 생성처럼 대량의 텍스트를 기다려야 하는 시나리오에서는 여전히 답답할 수 있다.
개발자 실무 관점에서 보면, 이 속도 이슈는 스트리밍 API 설계와 직결된다. 우리가 Claude API를 호출할 때 스트리밍을 쓰는 이유가 정확히 이거다. 전체 응답을 5초 기다리는 것보다, 0.5초마다 토큰이 하나씩 들어오는 걸 화면에 뿌리면서 사용자에게 "뭔가 happening"이라는 피드백을 주는 게 훨씬 나은 경험이다. UE5에서 네트워크 리플리케이션을 설계할 때도 같은 원리가 적용된다. 한 번에 큰 패킷을 몰아서 보내는 것보다, 작은 업데이트를 자주 보내는 게 클라이언트 예측과 보간에 유리하다.
한 가지 더 짚고 넘어가면, 토큰 속도는 모델 크기, 컨텍스트 윈도우, 그리고 서버 측 배치 최적화와 복잡하게 얽혀 있다. 컨텍스트가 길어질수록 어텐션 계산 비용이 올라가서 속도가 떨어지고, 한 서버에 여러 요청이 몰리면 개별 요청의 처리 속도도 내려간다. 결국 "10 tps"는 이상적인 조건에서의 숫자지, 실제 프로덕션 환경에서는 변동이 크다.
출처: Simon Willison
📰 구글 I/O 2026: Gemini Spark와 Antigravity, 그리고 생태계 전쟁
Google I/O, Gemini Spark, Antigravity
Simon Willison이 구글 I/O 2026을 Claude 중심 시각으로 정리한 글이다. Gemini Spark는 구글의 차세대 경량 모델 라인업이고, Antigravity는 안드로이드 전체에 AI를 깊숙이 통합하는 프로젝트 코드명으로 보인다. 이 글에서 흥미로운 점은 Simon이 Claude 사용자로서 구글의 발표를 어떻게 바라보는지, 그 시선이 드러난다는 것이다.
이 뉴스가 중요한 이유는 AI 플랫폼 경쟁이 모델 성능 싸움을 넘어서 "생태계 통합" 단계로 진입했음을 보여주기 때문이다. 구글은 안드로이드, 크롬, 워크스페이스, 클라우드 등 거의 모든 제품에 Gemini를 심고 있다. 이는 Anthropic이 Claude를 독립적인 크로스 플랫폼 서비스로 유지하는 전략과 대비된다. 구글의 접근은 "AI가 OS가 된다"는 비전의 구현이고, Anthropic의 접근은 "AI가 범용 도구가 된다"는 철학이다. 둘 다 장단점이 있다. 생태계 통합은 사용자 경험이 매끄럽지만 벤더 록인 위험이 크고, 독립 서비스는 자유도가 높지만 플랫폼 파워를 활용하기 어렵다.
개발자 관점에서 이 건은 API 선택의 장기적 영향을 고민하게 만든다. 지금 Claude API로 사이드 프로젝트를 짜고 있지만, 구글이 Gemini를 안드로이드에 네이티브로 심어버리면 모바일 환경에서는 Gemini가 기본 선택지가 될 수 있다. 게임 개발에서 언리얼 vs 유니티를 고를 때 생태계와 커뮤니티 크기를 따지는 것과 같다. 기술적 우위만으로 승부가 나지 않는다. 그리고 Gemini Spark 같은 경량 모델은 엣지 디바이스에서 로컬 추론을 가능하게 만들어서, 클라우드 API 호출 없이도 오프라인에서 기본적인 AI 기능을 쓸 수 있는 길을 연다. 이는 지연 시간 문제를 근본적으로 해결하는 방향이기도 하다. 앞서 이야기한 초당 10토큰 속도 이슈도, 로컬 경량 모델이 해결책 중 하나가 될 수 있다.
기술 배경을 조금 더 풀자면, Antigravity 프로젝트는 단순히 AI 어시스턴트를 OS에 심는 수준이 아니라, 시스템 레벨의 AI 훅을 제공하는 것으로 보인다. 앱 개발자가 자신의 앱에서 Gemini의 컨텍스트를 공유받고, 사용자의 현재 상황(열려 있는 앱, 최근 활동, 위치 등)을 AI가 이해할 수 있게 된다. 이건 마치 UE5의 Gameplay Ability System이 게임 전체 시스템에 걸쳐 능력과 이펙트를 관리하는 것과 비슷한 레이어다. 중앙에서 컨텍스트를 관리하고 각 서브시스템이 그걸 소비하는 구조.
출처: Simon Willison
📱 바이브 코딩, 모바일로 온다
Vibe coding is coming to your phone
The Verge가 구글 I/O에서 발표된 안드로이드 AI 스튜디오의 새 기능을 다뤘다. 핵심은 사용자가 폰 홈스크린에서 자신만의 미니 앱을 바이브 코딩으로 만들 수 있게 된다는 것. "There's an app for that"이 앱스토어의 오래된 약속이었다면, 이제는 "There's a vibe for that"이 되는 셈이다.
이 뉴스가 업계적으로 중요한 이유는 앱 개발의 민주화가 극단적인 수준에 도달했음을 보여주기 때문이다. 기존에도 Cursor, Windsurf 같은 AI 코딩 도구가 있었지만, 이건 개발자를 위한 도구였다. 구글이 안드로이드 홈스크린 위젯 수준에서 바이브 코딩을 지원한다는 건, 비개발자가 자신의 일상적 니즈에 맞는 마이크로 앱을 즉석에서 만들 수 있다는 뜻이다. 경쟁 구도에서 보면, Apple의 App Store 생태계가 "전문 개발자가 만든 앱을 일반 사용자가 소비한다"는 모델인데, 구글은 "일반 사용자가 AI로 앱을 만든다"는 모델로 공격하는 것이다.
개발자 실무 관점에서, 이건 두 가지 층위로 영향을 미친다. 첫째, 단순한 유틸리티 앱의 시장이 사라질 수 있다. 날씨 앱, 계산기, 간단한 투두 리스트 같은 건 누구나 5분 만에 자기 입맛에 맞게 만들 수 있게 된다. 둘째, 복잡한 앱의 아키텍처와 시스템 설계는 여전히 전문 개발자의 영역으로 남는다. 게임도 마찬가지다. 간단한 2D 퍼즐 게임은 AI가 만들 수 있지만, UE5 기반 멀티플레이어 게임의 서버 아키텍처나 렌더링 파이프라인 최적화는 당분간 인간 전문가의 몫이다. 다만 이 경계가 계속 녹고 있다는 점을 부정할 수는 없다.
기술적으로 더 파고들면, 모바일 바이브 코딩이 작동하려면 온디바이스 경량 모델과 클라우드 대형 모델의 협업이 필수다. 폰에서 로컬로 코드 제안을 빠르게 보여주고, 복잡한 로직이나 API 연동은 클라우드에서 처리하는 식이다. 앞서 언급한 Gemini Spark가 정확히 이 역할을 하는 모델이다. 그리고 생성된 코드를 위젯 형태로 홈스크린에 올리려면, 안드로이드의 위젯 시스템과 단축키 API를 AI가 동적으로 호출할 수 있어야 한다. 이건 단순한 코드 생성을 넘어서, AI가 OS의 시스템 API를 이해하고 조작할 수 있어야 가능한 일이다. 마치 UE5에서 블루프린트가 C++ 클래스를 동적으로 바인딩하는 것보다 더 추상화된 레이어에서 일어나는 일이다.
마지막으로, 이 세 흐름을 하나로 묶어보면 재미있는 그림이 그려진다. 초당 10토큰의 속도 고민(Simon Willison의 첫 글)은 클라우드 AI의 한계를 보여주고, Gemini Spark와 Antigravity(두 번째 글)는 그 한계를 로컬 경량 모델과 OS 통합으로 돌파하려는 시도이며, 모바일 바이브 코딩(세 번째 글)은 그 결과물이 일반 사용자에게 어떤 형태로 도달하는지를 보여준다. 속도 → 아키텍처 → 사용자 경험, 이 세 축이 동시에 돌아가고 있다.
출처: The Verge
AI의 속도 고민은 OS 통합으로, OS 통합은 바이브 코딩으로, 바이브 코딩은 "앱이 필요 없는 세상"으로 이어진다. 개발자는 복잡성의 끝에서 살아남을 곳을 찾아야 한다.