Talk Lowy(kr)

Antigravity IDE에 메신저 붙여봤더니... MCP 연동 실전 후기 Auto Accept가 사라진 날 어제 갑작스럽게 Antigravity IDE가 업데이트되면서 Auto Accept 기능이 비활성화 됐습니다. AI가 코드를 제안할 때마다 일일이 Accept 버튼을 눌러야 하는 상황. 처음엔 별거 아니라 생각했는데... 막상 닥쳐보니 그 귀찮음이 엄청났습니다. (초반에 이걸 어떻게 다 누르고 살아왔는지 새삼 신기할 지경;;) 그래서 어쩔 수 없이 새 기능 탭을 뒤적이기 시작했습니다. 발견: 외부 메신저 연동 기능! 업데이트 노트를 보던 중 흥미로운 기능 하나를 발견했습니다. 외부 메신저 연동 지원 — MCP(Model Context Protocol)를 통해 Slack, Discord 등 외부 메신저와 AI 에이전트를 직접 연결할 수 있게 됐습니다. 이 기능, 사실 OpenClaw(Claude 기반 자율 에이전트)를 겨냥한 포지셔닝처럼 보입니다. 메신저에서 AI에게 직접 업무를 지시하는 방식은 이미 OpenClaw가 핵심 경쟁력으로 내세우던 부분이거든요. "오, 이거 재밌겠는데?" 하고 바로 시도에 들어갔습니다. MCP 연동 실전 — 헤매고 또 헤매고... MCP 서버 설정은 생각보다 쉽지 않았습니다. Antigravity의 에이전트 패널에서 MCP 스토어를 찾고, Slack MCP 서버를 연결하는 과정에서 인증 토큰 설정, 워크스페이스 권한 설정 등 몇 가지 허들이 있었습니다. 솔직히 꽤 헤맸습니다. 공식 문서가 아직 부족한 탓에 설정 파일을 직접 수정해야 하는 부분도 있었고요. 하지만 결국 성공! 메신저에서 Antigravity AI 에이전트에게 직접 메시지를 보낼 수 있게 됐습니다. 연동 후 첫 인상 처음 메시지를 던졌을 때, AI의 반응은 꽤 인상적이었습니다. 질문에 대해 조목조목 상세하게, 심지어 장황할 정도로 답변해줬거든요. OpenClaw + ChatGPT 조합보다 오히려 나을 수...

[AI 꿀팁] Gemini 3.5 Flash vs 3.1 Pro, 내 토큰이 순식간에 녹아내린 이유와 똑똑한 모델 선택 가이드 안녕하세요! 최근 구글의 차세대 AI 라인업인 Gemini 3.5 Flash 와 Gemini 3.1 Pro 를 사용해 보시면서 "어? 왜 이렇게 토큰(비용)이 순식간에 사라지지?" 하고 당황하셨던 분들 많으실 겁니다. 질문 몇 개 안 한 것 같은데 토큰 제한이 걸리거나 비용이 청구되는 눈물 나는 상황... 도대체 왜 이런 일이 발생하는지, 그리고 내 지갑을 지키면서 AI 효율을 극대화하는 모델 및 옵션 선택 기준 을 총정리해 드립니다! 1. 내 토큰은 어디로 사라졌을까? 범인은 'Thinking 모드' 구글 Gemini 3.x 라인업의 가장 강력한 무기는 바로 '내장형 고도화 추론(Thinking) 기능'입니다. AI가 정답을 내기 전에 내부적으로 깊게 고민하는 단계를 거치는 것인데요. 여기서 반전이 있습니다. AI가 내부적으로 머리를 굴리며 쓴 혼잣말(추론 토큰)이 모두 '출력(Output) 토큰 사용량'에 포함되어 계산 된다는 점입니다! Thinking (High) 모드의 무서움: 사용자가 질문을 한 줄만 던졌어도, AI는 완벽한 정답을 내기 위해 백그라운드에서 스스로 에이전트 루프를 돌리며 수만 토큰을 써버립니다. 겉보기엔 짧은 답변이라도 실제로는 엄청난 토큰이 소모되는 주범이죠. 늘어난 출력 창: Gemini 3.5 Flash는 한 번에 뿜어낼 수 있는 출력 한도가 65,536 토큰 으로 대폭 늘어났습니다. 모델이 글을 길게 쓰거나 깊게 생각하기 시작하면 한 번의 대화로도 토큰이 텅텅 비게 됩니다. 2. Gemini 모델별 'Thinking 레벨'에 따른 토큰 소모량 비교 모든 모델의 최대 입력은 100만 토큰, 최대 출력은 65,536 토큰으로 동일하지만, Thinking 설정에 따라 내부 토큰 배분이 완전히 달라집니다. ...

[AI 꿀팁] Gemini 3.5 Flash vs 3.1 Pro, 내 토큰이 순식간에 녹아내린 이유와 똑똑한 모델 선택 가이드 안녕하세요! 최근 구글의 차세대 AI 라인업인 Gemini 3.5 Flash 와 Gemini 3.1 Pro 를 사용해 보시면서 "어? 왜 이렇게 토큰(비용)이 순식간에 사라지지?" 하고 당황하셨던 분들 많으실 겁니다. 질문 몇 개 안 한 것 같은데 토큰 제한이 걸리거나 비용이 청구되는 눈물 나는 상황... 도대체 왜 이런 일이 발생하는지, 그리고 내 지갑을 지키면서 AI 효율을 극대화하는 모델 및 옵션 선택 기준 을 총정리해 드립니다! 1. 내 토큰은 어디로 사라졌을까? 범인은 'Thinking 모드' 구글 Gemini 3.x 라인업의 가장 강력한 무기는 바로 '내장형 고도화 추론(Thinking) 기능'입니다. AI가 정답을 내기 전에 내부적으로 깊게 고민하는 단계를 거치는 것인데요. 여기서 반전이 있습니다. AI가 내부적으로 머리를 굴리며 쓴 혼잣말(추론 토큰)이 모두 '출력(Output) 토큰 사용량'에 포함되어 계산 된다는 점입니다! Thinking (High) 모드의 무서움: 사용자가 질문을 한 줄만 던졌어도, AI는 완벽한 정답을 내기 위해 백그라운드에서 스스로 에이전트 루프를 돌리며 수만 토큰을 써버립니다. 겉보기엔 짧은 답변이라도 실제로는 엄청난 토큰이 소모되는 주범이죠. 늘어난 출력 창: Gemini 3.5 Flash는 한 번에 뿜어낼 수 있는 출력 한도가 65,536 토큰 으로 대폭 늘어났습니다. 모델이 글을 길게 쓰거나 깊게 생각하기 시작하면 한 번의 대화로도 토큰이 텅텅 비게 됩니다. 2. Gemini 모델별 'Thinking 레벨'에 따른 토큰 소모량 비교 모든 모델의 최대 입력은 100만 토큰, 최대 출력은 65,536 토큰으로 동일하지만, Thinking 설정에 따라 내부 토큰 배분이 완전히 달라집니다. ...

"GPU를 가진 자가 승리한다"는 환상 현재 시장의 지배적인 시각은 "가장 많은 GPU 컴퓨팅 파워를 확보하는 자가 AI 시대의 패권을 쥔다"는 것입니다. 하지만 이는 곧 깨어질 치명적인 착각입니다. 다가오는 진정한 병목(Bottleneck)은 연산 장치가 아니라, 물리적인 **'전력(Power)'**입니다. 엄청난 자본을 들여 최신 GPU 데이터센터를 구축하더라도, 이를 풀가동할 수 있는 막대하고 안정적인 전력을 공급받지 못한다면 그 비싼 GPU들은 그대로 고철로 썩어가게 됩니다. 전력 폭식: AI가 송전망에 미치는 충격 최근 글로벌 동향을 살펴보면, AI 인프라의 전력 수요는 기존 클라우드 시설의 그것을 가볍게 뛰어넘고 있습니다. 더 크고 복잡한 모델(LLM)을 학습시키고 추론(Inference)하는 과정은 막대한 에너지를 요구합니다. 2030년까지 전 세계 데이터센터의 전력 소비량은 지금의 두 배 이상 증가할 것이며, 그 성장의 핵심 동력은 단연 AI입니다. 더욱 치명적인 문제는 AI 워크로드의 **불규칙성(Spikiness)**입니다. 기존의 산업용 전력은 예측 가능하게 서서히 변동하지만, AI 시스템은 집중적인 모델 훈련 시 순간적으로 거대한 전력을 빨아들이는 '전력 폭식' 패턴을 보입니다. 노후화된 송전망과 배전 인프라는 이러한 급격하고 거대한 전력 부하 변동을 감당하도록 설계되지 않았기 때문에, 언제든 지역 전력망에 치명적인 불안정을 초래할 수 있습니다. 권력의 이동: 하드웨어에서 에너지로 이러한 물리적 한계로 인해, 머지않아 AI 시장의 진정한 권력은 'GPU 소유자'에서 **'에너지(전력망) 확보자'**로 완전히 이동하게 될 것입니다. 세계적인 테크 기업들은 자신들이 확보한 막대한 GPU 자산을 놀리지 않기 위해, 아무리 비싼 대가를 치르더라도 '안정적으로 GPU를 돌려줄 수 있는 물리적 전력망(Grid)을 갖춘 거점'을 ...

Claude Code는 정말 '운영체제(OS)'일까? 기술적 진실과 새로운 패러다임의 경계 최근 개발자 커뮤니티에서 Claude Code 를 두고 흥미로운 논쟁이 벌어지고 있습니다. 누군가는 이를 "혁신적인 AI 운영체제"라고 부르고, 또 누군가는 "그저 터미널에서 실행되는 앱일 뿐"이라며 선을 긋습니다. 과연 누구의 말이 맞을까요? 결론부터 말씀드리면, 두 시각 모두 각자의 진실을 담고 있습니다. 우리가 이 도구를 어떻게 정의하느냐에 따라 개발의 미래를 바라보는 눈이 달라질 수 있죠. 1. 기술적 사실: Claude Code는 운영체제가 아닙니다 엄격한 기술적 관점에서 운영체제(OS)는 하드웨어 자원(CPU, 메모리, 저장장치 등)을 직접 관리하고 사용자 앱에 할당하는 소프트웨어를 말합니다. macOS, Windows, Linux가 바로 그것이죠. Claude Code는 이러한 운영체제 '위'에서 실행되는 하나의 애플리케이션 입니다. 하드웨어를 직접 제어하기보다는, 터미널(Shell)을 통해 운영체제의 명령어를 대신 수행해주는 '에이전트'에 가깝습니다. 따라서 "기술적으로는 OS가 아니다"라는 말은 100% 사실입니다. 2. 패러다임의 변화: 왜 'OS'처럼 느껴지는가? 그런데 왜 많은 이들이 이를 OS라고 부르고 싶어 할까요? 그것은 우리가 컴퓨터를 사용하는 **'방식'**이 근본적으로 변하고 있기 때문입니다. 과거에는 사용자가 직접 OS 명령어를 입력하고 파일을 관리했습니다. 하지만 Claude Code를 사용하면 우리는 AI에게 의도(Intent)를 말하고, AI가 뒤에서 파일 시스템을 뒤지고, Git을 조작하며, 코드를 수정합니다. 즉, 사용자 입장에서 Claude Code는 실제 OS를 완전히 추상화하여 가려버리는 새로운 인터페이스 층 이 됩니다. 우리가 더 이상 커널(Kernel)을 신경 쓰지 않듯이, 이...

Chrome은 왜 내 PC에 4GB AI 모델을 몰래 다운로드했을까? — Gemini Nano, Local AI, 그리고 브라우저의 미래 최근 X(구 Twitter)와 LinkedIn을 중심으로 꽤 흥미롭고, 한편으로는 우려 섞인 글이 확산되고 있습니다. 요약하자면 다음과 같습니다. "Chrome이 사용자 허락 없이 약 4GB 규모의 AI 모델(weights.bin)을 백그라운드에서 다운로드하고 있으며, 이는 Google의 온디바이스(on-device) AI인 Gemini Nano 모델이다." 동시에 다음과 같은 비판이 쏟아집니다: 사용자가 명확히 동의한 적이 없다. 수동으로 삭제해도 다시 다운로드된다. 'AI 모드'는 사실 클라우드 기반인데 사용자를 로컬 처리로 오해하게 만든다. 브라우저가 점점 사용자 PC의 자원을 잠식하는 플랫폼처럼 변하고 있다. 단순히 "구글이 또 무언가를 몰래 심었다"는 음모론으로 치부하기에는, 이 논란의 기저에는 브라우저 기술의 거대한 패러다임 변화가 깔려 있습니다. 이번 글에서는 기술적 관점에서 무엇이 사실이고, 우리는 이를 어떻게 바라봐야 하는지 정리해 보겠습니다. 1. 실제로 Chrome은 로컬 AI 모델을 다운로드한다 결론부터 말씀드리면, 이 주장은 사실에 가깝습니다. 현재 Chrome 내부에는 Gemini Nano를 위한 로컬 추론 모델 파일이 실제로 존재합니다. 사용자 PC의 다음 경로를 확인해 보면 실체를 확인할 수 있습니다: Windows: %LOCALAPPDATA%\Google\Chrome\User Data\Default\OptGuideOnDeviceModel macOS: ~/Library/Application Support/Google/Chrome/Default/OptGuideOnDeviceModel 이 폴더 안에는 weights.bin 이라는 파일이 존재하며, 그 크기는 약 4GB 내외입니다. 이 파일은 Google이...