🤖
1566 in / 4870 out / 6436 total tokens
🔥 핫 토픽: Qwen 3.6이 바이브 코딩에서 Claude를 위협한다
Qwen 3.6 is actually useful for vibe-coding, and way cheaper than Claude
바이브 코딩(vibe-coding)이 2025년 게임 개발 커뮤니티에서 일상이 됐다. 프롬프트 몇 줄로 프로토타입을 뚝딱 만들어내는 이 방식은 Claude Code가 사실상 표준 도구로 굳어지는 분위기였다. 그런데 r/LocalLLaMA에서 한 유저가 Qwen 3.6-35B-A3B(Q4)와 27B(Q8) 모델을 Claude Code에 연결해서 로컬로 돌려보니, "완벽하게 잘 돌아간다"는 보고가 올라왔다. 점수 261점, 댓글이 폭발한 이 포스트는 단순한 팁 공유가 아니라 비용 구조의 근본적인 전환을 시사한다.
왜 이게 중요하냐. Claude API 호출 비용은 프로젝트 규모가 커지면 하루에 수만 원씩 쌓인다. 필자도 사이드 프로젝트 하나에 Claude Code를 물려놓고 밤새 돌린 적이 있는데, 다음 날 아침에 요금 확인하고 등골이 서늘해졌다. 반면 Qwen 3.6은 로컬 GPU에서 돌리면 호출당 비용이 0원이다. 35B-A3B 모델의 A3B는 "활성 파라미터 3B"라는 뜻으로, MoE(Mixture of Experts) 아키텍처를 써서 추론 시 전체 파라미터 중 일부만 활성화하는 방식이다. 이게 왜 혁신적이냐면, 35B급 성능을 3B급 연산량으로 뽑아낸다는 거다. RTX 4090 하나로 충분히 돌아간다.
개발자 실무 관점에서 보면, 이건 "Claude를 안 쓴다"가 아니라 "용도에 따라 분산한다"는 전략이 된다. 핵심 아키텍처 설계나 복잡한 리팩토링은 Claude Sonnet/Opus에 맡기고, 반복적인 보일러플레이트 코드 생성이나 간단한 스크립트 작성은 로컬 Qwen에 돌리는 식이다. 게임 서버 아키텍처에서 CPU-바운드 작업과 I/O-바운드 작업을 분배하듯, AI 호출도 비용-성능 곡선에 따라 분산하는 게 이제는 상식이 되고 있다.
다만 솔직히 말하면, Qwen 3.6이 Claude Opus 수준의 복잡한 추론을 완벽히 대체하진 못한다. UE5 C++에서 템플릿 메타프로그래밍이나 리플렉션 시스템 관련 복잡한 질문을 던지면 여전히 Claude가 한 수 위다. 하지만 "바이브 코딩"이라는 용도 자체가 빠른 반복과 직관적 피드백에 초점이 맞춰져 있으니, 로컬 모델의 응답 속도와 비용 우위가 매력적일 수밖에 없다.
📰 뉴스: AI 토큰 경제학의 머니 스퀴즈
You're about to feel the AI money squeeze
The Verge가 "AI 머니 스퀴즈"라는 제목으로 AI 업계의 수익화 압박에 대한 심층 분석을 내놨다. 핵심 내용은 OpenAI와 Anthropic이 무료 및 저가 티어 사용자에게 제공하던 과감한 토큰 할당을 대폭 축소하고 있다는 거다. 특히 Anthropic이 Claude 사용량에 제한을 강화한 부분이 눈에 띈다. 수백만 사용자가 무료로 AI를 쓰며 버릇이 들었는데, 이제 그 파티가 끝나가고 있다.
이건 단순히 "기업이 돈을 더 벌려고 한다"가 아니다. LLM 추론 비용은 반비례 법칙을 따르지 않는다. 반도체 공정이 발전해도 트랜스포머 아키텍처의 계산 복잡도는 시퀀스 길이에 대해 이차적으로 증가한다. 컨텍스트 윈도우가 200K 토큰으로 늘어나면, 어텐션 연산량은 입력 길이의 제곱에 비례해서 폭발한다. Flash Attention이나 KV 캐시 최적화로 어느 정도 완화하긴 했지만, 근본적인 O(n²) 문제는 해결 안 됐다. 결국 긴 컨텍스트를 처리할수록 GPU 시간이 선형 이상으로 소모되고, 그 비용을 누군가는 감당해야 한다.
앞서 언급한 Qwen 로컬 실행 뉴스와 맞물려 생각해보면 이 흐름이 더 선명해진다. 클라우드 API 비용이 오르는 만큼 로컬 모델로 빠져나가는 유저가 늘어나는 건 자연스러운 현상이다. Anthropic 입장에서는 고가의 Opus 모델로 수익을 내고, 무료 티어는 브랜드 인지도 유지용으로 최소한만 남기는 전략을 취하는 거다. 게임 서비스의 "페이 투 윈" 논란보다 더 민감한 게 "페이 투 코드"가 될 수 있다. 개발자가 AI 도구에 월 구독료로 10만 원 이상 지출하기 시작하면, 그건 이미 개발 도구 비용이 아니라 인건비 절감 투자로 회계 처리해야 하는 수준이다.
필자의 경우, Claude Pro 구독 + API 호출비 + 로컬 GPU 전기세를 합치면 월 20만 원 가까이 AI 관련 비용이 나온다. UE5 프로젝트 하나에 C++ 템플릿 에러 해석하느라 매일 Claude를 호출하고, 밤에는 스크립트 자동화를 위해 별도 API를 돌리니까. 이 비용이 두 배로 뛰면 진지하게 로컬 모델 혼합 방식으로 전환을 고려할 수밖에 없다. The Verge 기사가 말하는 "머니 스퀴즈"는 바로 이 지점을 짚는 거다.
출처: The Verge AI
📰 뉴스: Microsoft의 "바이브 워킹" 오피스 에이전트
Microsoft launches 'vibe working' in Word, Excel, and PowerPoint
Microsoft가 Word, Excel, PowerPoint에 "Agent Mode"를 론칭했다. 이전에 "바이브 워킹(vibe working)"이라고 불렸던 이 기능은, 바이브 코딩의 개념을 사무 생산성 전반으로 확장한 거다. 프롬프트 하나로 문서를 작성하고, 스프레드시트 수식을 생성하고, 프레젠테이션 슬라이드를 자동 구성하는 에이전트가 오피스 앱 안에 직접 들어간다.
이 뉴스가 Claude 생태계에 미치는 영향을 분석해보자. 현재 바이브 코딩 도구 시장은 Claude Code, Cursor, Windsurf가 삼파전을 벌이고 있다. 이 시장의 본질은 "AI가 사용자 의도를 이해하고 코드를 생성/수정하는 에이전트"인데, Microsoft가 같은 패턴을 오피스 도구에 적용한 거다. 기술적으로 보면, 이 에이전트 모드는 문서의 DOM 구조를 컨텍스트로 이해하고, 사용자의 자연어 지시를 편집 명령 시퀀스로 변환하는 LLM 오케스트레이션 레이어다. 게임으로 치면 UE5의 블루프린트 노드를 자연어로 조작하는 거랑 비슷한 맥락이다.
경쟁 구도 측면에서, Microsoft가 Copilot 브랜드로 에이전트 기능을 오피스에 깊숙이 박아넣으면 Anthropic의 Claude for Work 포지셔닝이 흔들릴 수 있다. 기업 고객은 이미 Microsoft 365 구독료를 내고 있고, 거기에 에이전트 기능이 번들로 들어오면 Claude를 별도로 도입할 명분이 약해진다. 다만 Claude의 강점은 코드 생성 정확도와 긴 컨텍스트 처리 능력이니까, 문서 작성은 Copilot, 코드는 Claude로 양분되는 시나리오도 가능하다.
개발자 관점에서 더 흥미로운 건 이 에이전트 아키텍처가 어떻게 구현됐는지다. 오피스 문서는 비정형 데이터와 정형 데이터가 뒤섞인 복잡한 도메인이다. Excel 수식은 함수형 프로그래밍의 일종이고, Word 문서는 계층적 트리 구조다. 이걸 자연어로 조작하려면 LLM이 각 도메인의 문법과 의미론을 이해해야 한다. 게임 개발에서도 비슷한 패턴이 나온다. UE5의 블루프린트를 자연어로 생성하는 도구, 레벨 에디터의 배치를 프롬프트로 제어하는 도구. Microsoft의 오피스 에이전트 성공 여부가 게임 개발 도구의 에이전트화 속도에도 영향을 줄 거다.
출처: The Verge
📄 에세이: Maggie Appleton이 말하는 AI 인터페이스의 미래
Simon Willison이 자신의 블로그에서 Maggie Appleton의 글을 인용하며 AI 인터페이스 설계에 대한 논의를 이어갔다. Appleton은 디지털 인류학자이자 UX 디자이너로, AI 도구의 인터페이스가 어떻게 인간의 사고 방식을 형성하는지에 대해 깊이 있게 다루는 인물이다. 이 글은 구체적인 뉴스라기보다는, 앞서 다룬 바이브 코딩과 에이전트 모드가 가져올 UX 패러다임 전환을 이론적으로 뒷받침하는 맥락으로 읽을 수 있다.
Appleton의 핵심 주장은 "인터페이스가 곧 사고방식"이라는 거다. CLI(명령줄) 시대의 개발자는 텍스트로 사고했고, GUI 시대의 개발자는 시각적 레이아웃으로 사고했다. 그렇다면 AI 에이전트 시대의 개발자는 무엇으로 사고하는가. "바이브"로 사고한다. 구체적인 구현 세부사항을 AI에 위임하고, 개발자는 의도와 분위기를 조절하는 큐레이터 역할로 전환한다. 이건 코딩 능력의 저하가 아니라 추상화 레벨의 상승이다. 어셈블리를 모르는 C++ 프로그래머가 무능한 게 아니듯, CSS를 모르는 바이브 코더도 무능한 게 아니다.
다만 Appleton은 여기에 경고도 덧붙인다. 추상화가 너무 높아지면 하위 레이어를 이해할 수 없는 "불투명한 의존"이 생긴다. 게임 서버 개발에서 이 현상을 종종 본다. AWS Lambda로 서버리스 아키텍처를 구축한 개발자가, 정작 Cold Start 문제가 발생했을 때 왜 느려지는지 원인을 파악 못 하는 거다. AI 생성 코드도 마찬가지다. Claude가 만들어준 UE5 서브시스템 코드가 메모리 누수를 일으킬 때, 그 코드를 이해하지 못하면 디버깅 자체가 불가능해진다.
Simon Willison이 이 글을 인용한 이유는, 그가 LLM 도구의 선구자적 개발자이면서도 도구에 대한 비판적 거리를 유지하기 때문이다. 필자 역시 같은 태도를 유지하려 노력한다. Claude Code로 프로토타입을 빠르게 찍어내면서도, 생성된 코드를 라인 바이 라인으로 리뷰하는 습관은 버리지 않는다. 바이브 코딩의 진정한 가치는 "코드를 안 짜도 된다"가 아니라, "지루한 부분은 AI에게 맡기고 핵심 로직에 집중할 수 있다"에 있다.
바이브 코딩은 개발의 민주화가 아니라 추상화의 다음 단계다. 추상화의 이점을 누리려면 그 아래 레이어를 이해하는 사람만이 진정한 마스터가 된다.