🤖 1640 in / 5891 out / 7531 total tokens

AI 업데이트: AI 도구의 실용성 경계와 멀티모델 라우팅

OpenClaw 같은 AI 코딩 도구가 숙련자에게는 거의 쓸모없다는 불편한 진실부터, Starbucks AI 주문의 참혹한 실패까지. 이번 주 AI 생태계는 "AI가 진짜 유용한 지점은 어디인가"라는 질문을 여러 방향에서 던지고 있다. 게임 개발자 시각에서 하나씩 파보자.

🔥 핫 토픽: OpenClaw 논쟁 — 숙련자에게 AI 래퍼 도구는 필요한가

원문: Unpopular opinion: OpenClaw and all its clones are almost useless

Reddit r/LocalLLaMA에서 화제가 된 글이다. 핵심 주장은 이것이다: OpenClaw와 그 클론들은 CLI, Claude Code, Codex를 이미 쓰는 사람에게는 거의 무용하다. n8n이나 Make 같은 워크플로우 툴도 마찬가지. 이 도구들은 "AI를 처음 접하는 사람"에게는 인상적일 수 있지만, 이미 자기 워크플로우가 있는 개발자에게는 오히려 마찰만 추가한다.

이건 게임 개발에서도 동일한 맥락으로 봐야 한다. 언리얼 엔진에서 Blueprint 위주로 작업하던 팀이 갑자기 C++ 기반 AI 에이전트 도구를 도입하면, 오히려 빌드 파이프라인이 꼬이고 디버깅이 어려워지는情况과 같다. 도구는 기존 워크플로우에 녹아들어야지, 위에 얹히면 안 된다.

왜 중요한가: AI 코딩 도구 시장이 폭발적으로 늘어나면서 "래퍼(wrapper)" 제품이 넘쳐난다. API 몇 개 엮어서 UI 올린 수준의 제품이 $20/월을 받는 구조다. 이 글은 그 현상에 대한 일침이다. 실제로 Claude Code를 터미널에서 직접 쓰는 개발자에게 굳이 GUI 래퍼가 필요할까? 답은 "초보자한테는 yes, 숙련자한테는 no"다. 개발자라면 자기가 어느 쪽인지 솔직하게 판단해야 한다.

개발자에게 미치는 영향: 현재 AI 코딩 도구 생태계는 크게 두 갈래다. 하나는 Cursor, Claude Code, Codex처럼 기존 개발 환경에 깊이 통합되는 방향이고, 다른 하나는 OpenClaw처럼 별도 플랫폼으로 감싸는 방향이다. 전자는 생산성을 올려주지만 후자는 컨텍스트 스위칭 비용만 추가한다. 나도 초기에 비슷한 래퍼 도구를 시도했다가, 결국 CLI + 커스텀 스크립트로 회귀했다. 게임 서버 아키텍처 설계할 때도 마찬가지다 — 중간 레이어가 얇을수록 디버깅이 쉽다.

한줄 평: 도구는 기존 워크플로우를 대체하는 게 아니라 확장해야 한다. 그렇지 않으면 또 다른 부채다.

📰 뉴스: llm-openrouter 0.6 — 멀티 모델 라우팅의 진화

원문: llm-openrouter 0.6

Simon Willison이 관리하는 llm CLI 도구의 OpenRouter 플러그인이 0.6으로 업데이트됐다. 핵심은 다양한 LLM 제공자를 하나의 인터페이스로 라우팅할 수 있다는 것. Claude, GPT, Gemini, 오픈소스 모델까지 싱글 커맨드로 전환이 가능하다.

왜 중요한가: 이건 게임 개발의 "서비스 디스커버리" 패턴과 정확히 일치한다. 게임 서버에서 매치메이킹, 인증, 로깅 서비스를 각각 다른 엔드포인트로 라우팅하듯이, AI 모델도 용도에 따라 라우팅하는 구조다. 코딩 작업에는 Claude Sonnet, 간단한 스크립트에는 Haiku, 이미지 생성에는 다른 모델 — 이런 식으로 비용과 성능을 최적화할 수 있다.

실무 관점: API 키 하나로 여러 모델에 접근할 수 있다는 건 사이드 프로젝트에 큰 이점이다. 나도 AI 기반 NPC 대화 시스템을 프로토타이핑할 때, 대화 생성은 Claude, 임베딩은 로컬 모델, 요약은 GPT-mini로 분산시킨 적이 있다. 각 모델의 강점을 조합하는 아키텍처가 점점 표준이 되고 있고, OpenRouter는 그 라우팅 레이어를 깔끔하게 추상화해준다.

기술 배경: OpenRouter는 기본적으로 LLM API들의 리버스 프록시 역할을 한다. 클라이언트는 OpenRouter API 하나만 바라보고, 백엔드에서 각 제공자의 API 스펙에 맞게 요청을 변환한다. 마치 API Gateway 패턴 그 자체다. 0.6 업데이트에서 스트리밍 응답 처리와 에러 핸들링이 개선됐다고 하니, 프로덕션 수준에서도 쓸 만해졌다는 뜻이다.

한줄 평: 멀티 모델 라우팅은 이제 선택이 아니라 기본 전략이다. 비용 최적화의 핵심.

📰 뉴스: Starbucks ChatGPT 앱 — AI UX의 참혹한 실패 사례

원문: Ordering with the Starbucks ChatGPT app was a true coffee nightmare

The Verge 기자가 Starbucks의 ChatGPT 연동 주문 앱을 테스트해봤다가 악몽을 경험했다. "벤티 아이스 커피, 라이트 스킴 밀크" 하나 시키는 게 목표였는데, AI가 이것저것 추가 질문을 하고, 옵션을 잘못 이해하고, 결국 주문이 꼬였다.

왜 중요한가: 이건 단순한 커피 주문 문제가 아니다. AI 인터페이스 설계의 근본적 한계를 보여준다. 기존 UI가 버튼 3개로 처리하던 것을 자연어 대화로 바꾸면, 사용자는 "어떻게 말해야 하는지"를 고민해야 한다. 이건 게임 UX에서도 동일한 교훈을 준다. 플레이어가 버튼 하나로 스킬을 발동하던 것을 음성 명령으로 바꾼다고 더 편해지지 않는다.

개발자 관점에서의 해석: 자연어 인터페이스는 모호성을 허용하는 게 핵심 강점인데, 주문 시스템은 정확성이 생명이다. 이 두 가지가 충돌하는 지점이 바로 여기다. 구조화된 데이터(사이즈, 옵션, 수량)를 다룰 때는 폼 UI가 압도적으로 우위다. AI를 끼워넣을 때 "이게 정말 기존 방식보다 나은가?"를 물어봐야 한다. 기술적 가능성과 실제 유용성은 다른 차원의 문제다.

앞서 언급한 OpenClaw 논쟁과 맞물려: 두 사례는 같은 맥락에 있다. 불필요한 곳에 AI 레이어를 끼워넣으면, 기존에 1초면 되던 작업이 10초가 된다. OpenClaw가 CLI에 GUI 래퍼를 씌워 느려지는 것과, Starbucks가 버튼 주문에 대화형 AI를 씌워 복잡해지는 것 — 본질적으로 같은 실수다. 레이어를 추가할 때는 그 레이어가 제거하는 마찰보다 더 큰 마찰을 만들면 안 된다.

한줄 평: AI가 들어갈 자리와 아닌 자리를 구분하는 안목이 핵심 역량이 되고 있다.

🔒 보안: AES-128은 양자 시대에도 괜찮다

원문: AES-128 is just fine in a post-quantum world

AES-128이 양자 컴퓨터 시대에도 안전하다는 Ars Technica 분석 기사. Grover's algorithm이 이론적으로 AES-128의 보안을 64비트로 낮추지만, 그래도 실제로 브레이크하는 건 현재 기술로 불가능에 가깝다. 그럼에도 업계에서 "AES-128은 위험, 무조건 256 써라"는 미신이 퍼져 있다.

왜 중요한가: 이건 게임 서버 인프라에도 직결된다. 게임 클라이언트-서버 간 통신 암호화, 플레이어 데이터 저장, 인증 토큰 서명 — 모든 곳에 암호화가 들어간다. AES-256을 무조건 쓰면 성능 오버헤드가 발생하고, 특히 모바일 게임에서 배터리 소모에 영향한다. AES-128로 충분한 시나리오에서 256을 강제하는 건 낭비다.

기술 배경: 대칭키 암호(AES)와 비대칭키 암호(RSA, ECC)는 양자 컴퓨터에 대한 내성이 완전히 다르다. RSA-2048은 Shor's algorithm에 의해 완전히 깨지지만, AES는 Grover's algorithm이 키 공간을 제곱근으로 줄이는 것만 가능하다. AES-128의 2^128 키 공간이 2^64가 되어도, 여전히 brute-force는 현실적으로 불가능하다. 2^64는 초당 10억 번 연산해도 수백 년이 걸린다.

실무 코멘트: 양자 내성(post-quantum) 암호 마이그레이션은 비대칭키부터 진행하면 된다. 대칭키는 AES-128 유지해도 된다. AES-256을 쓰면 좋긴 하지만, "안 쓰면 위험"은 잘못된 주장이다. 게임 서버에서 TLS 1.3 + AES-128-GCM 조합은 당분간 문제없다. 불필요한 보안 강박으로 복잡도를 올리지 마라.

한줄 평: 보안 결정은 위협 모델 기반으로. 미신 기반이 아니라.

🎮 크리에이티브: pelicans_riding_bicycles — AI로 만드는 몽환적 이미지

원문: scosman/pelicans_riding_bicycles

Simon Willison이 Claude를 이용해 "자전거 타는 펠리컨" 이미지를 생성하는 프로젝트를 공유했다. 제목 그대로다. 펠리컨이 자전거를 타는 몽환적이고 기괴한 이미지들을 생성하는 실험이다.

왜 언급하나: 이건 AI 도구의 "빈둥거리며 탐색하는" 용도를 보여주는 좋은 예시다. 앞선 뉴스들이 AI의 실용적 한계를 다뤘다면, 이건 AI의 놀이적 측면이다. 그리고 이런 장난스러운 실험에서 의외의 인사이트가 나온다. 프롬프트 엔지니어링의 한계, 이미지 생성 모델의 일관성 문제, 조합적 창의성의 가능성 — 다 실험으로 체감할 수 있다.

게임 개발 연결고리: 게임에서도 프로시저럴 콘텐츠 생성에 비슷한 접근이 가능하다. "자전거 타는 펠리컨" 같은 조합을 프롬프트로 던져서 NPC 외형, 몬스터 컨셉, 이색 무기 디자인 등을 빠르게 프로토타이핑할 수 있다. 실제로 나도 AI로 몬스터 컨셉 아트를 50개쯤 뽑아본 뒤 아티스트에게 방향성을 전달한 적이 있다. 결과물 자체를 쓰는 게 아니라, 의사소통의 시작점으로 쓰는 것이다.

한줄 평: 놀이와 실험이 결합될 때 진짜 인사이트가 나온다.

이번 주 교훈: AI 도구는 기존 워크플로우를 보완하는 데 쓰이면 강력하고, 대체하려 들면 참사가 난다. 커피 주문에 AI를 끼워넣은 Starbucks나, CLI 위에 불필요한 GUI를 씌운 OpenClaw나 같은 실수다. "이게 정말 더 나은가?"를 끊임없이 물어라.