요약 (TL;DR)

• GLM 5.2는 현재 모두가 벤치마킹하고 있는 오픈 웨이트 (open-weight) 모델입니다. Claude 가격의 10분의 1 수준이며, 100만 토큰의 컨텍스트 윈도우 (context window)를 제공합니다. 타인의 리뷰를 읽는 대신, 저는 제 자체 SDK에서 직접 실행해 보았습니다.
• 설정은 Claude Code 설정에서 다섯 줄이면 충분하며, OpenRouter를 통해 라우팅됩니다. Z.ai 프로바이더 (provider)를 고정하고 폴백 (fallback)을 꺼야 합니다. 그렇지 않으면 양자화 (quantized)된 가짜 모델을 테스트하게 될 수도 있습니다.
• 아키텍처 분석: 41개 파일, 모든 인용은 실제이며, 59센트, 6분 소요되었습니다. 구축 (build): 작동은 했고 92개의 테스트가 통과(green)되었지만, 비용은 4달러가 들었습니다. 대부분은 테스트 루프 (test-loop)의 지구력 때문이었습니다.
• 현재 저의 분할 방식: 읽기에는 GLM을, 구축에는 Claude를 사용합니다. 코드가 저렴하든 아니든, 개인적인 코드는 절대 제 기기를 떠나지 않습니다.

제 Claude Code 청구서가 한동안 저를 괴롭혔습니다. 무서운 액수는 아니었지만, 야금야금 올라가고 있었습니다. 저는 많은 에이전트 (agents)를 실행하며, 때로는 전체 하네스 (harness)를 한꺼번에 돌리기도 하는데, 월말에 찍히는 금액이 계속 올라가고 있었습니다. 그래서 더 저렴한 엔진을 찾아 나섰고, 모두가 가리키고 있는 것은 GLM 5.2라는 중국산 오픈 웨이트 (open-weight) 모델이었습니다.

제가 이것을 시도하고 싶었던 두 가지 이유가 있습니다. 하나는 순수하게 비용 때문입니다. 만약 가격이 10분의 1인 모델이 제 업무의 절반이라도 수행할 수 있다면, 그것은 실제로 돈을 아끼는 일입니다. 다른 하나는 솔직히 말해서 제가 피해왔던 호기심 때문이었습니다. 중국 연구소들은 빠르게 제품을 출시하고 있고, 벤치마크 (benchmarks) 결과는 터무니없이 좋아 보입니다. 저는 마케팅 너머의 실체를 확인하기 위해 그들의 모델을 제 코드에 실제로 실행해 본 적이 없었습니다.

그래서 저는 OpenRouter에 5달러를 충전하고, 타인의 리뷰를 읽는 것을 그만두기로 했습니다. 제가 누구보다 잘 아는 단 하나의 코드베이스, 즉 저의 자체 생성형 UI SDK에서 GLM을 실행하고, 모델이 내놓은 결과물의 모든 줄을 확인해 보기로 했습니다.

이것은 제가 무엇을 했는지, 비용이 얼마나 들었는지, 그리고 시작하기 전에 제가 잘못 생각했던 부분에 대한 기록입니다.

설정, 생각보다 간단하니까

GLM 5.2는 Z.ai에서 출시한 오픈 웨이트 (open-weight) 모델입니다. 6월 중순에 출시되었으며, 100만 토큰의 컨텍스트 윈도우 (context window)를 가지고 있습니다. 사람들이 이 모델에 대해 계속 이야기하는 핵심은, 아주 적은 비용으로 프론티어 모델 (frontier model) 수준의 코딩 능력을 보여준다는 점입니다. 공개된 수치들도 이러한 소문을 뒷받침합니다. OpenRouter의 Design Arena 보드에 따르면, 3,000회 이상의 헤드 투 헤드 (head-to-head) 토너먼트에서 코딩 부문 상위 1%에 위치하고 있습니다. 저 역시 이를 맹목적으로 믿고 싶지는 않았습니다. 벤치마크 (Benchmarks)란 결국 다른 누군가가 작성한 코드일 뿐이니까요.

이번 주 기준 공개된 주장: Design Arena에서 코딩 부문 상위 1%, 3,243개 토너먼트 결과. 이 글은 제가 직접 제 리포지토리 (repo)를 통해 이를 검증하는 과정입니다.

Claude Code는 그 뒤에 어떤 모델이 있는지 신경 쓰지 않습니다. 이 도구는 Anthropic API 형식을 따르며, 요청을 어디로 보낼지 결정하기 위해 두 개의 환경 변수 (environment variables)를 읽습니다. 이 변수들을 다른 엔드포인트 (endpoint)로 지정하기만 하면, 동일한 에이전트 (agent), 동일한 파일 편집, 동일한 테스트 실행 기능을 유지하면서 '두뇌'만 바꾸어 도구 전체를 계속 사용할 수 있습니다.

저는 엔드포인트로 OpenRouter를 사용했습니다. 이유는 간단합니다. 하나의 계정과 하나의 API 키만 있으면 Z.ai를 포함한 수십 개의 모델 제공업체로 해당 키를 라우팅 (route)할 수 있기 때문입니다. 단 하나의 실험을 위해 중국 연구소와 별도의 결제 관계를 맺고 싶지는 않았습니다. OpenRouter가 중간에서 역할을 해주므로, 저는 몇 달러만 충전하면 하나의 키로 그 뒤에 있는 어떤 모델이든 시도해 볼 수 있습니다.

시작부터 끝까지의 전체 과정은 다음과 같습니다.

설정하는 데 필요한 세 단계입니다.

첫째, 키(key)를 만듭니다. OpenRouter에서 API 키를 생성하고 계정에 몇 달러의 크레딧(credit)을 충전합니다. 무료 GLM 5.2 티어(tier)는 없지만, 크레딧은 매우 오래 갑니다. 제 실험 전체는 5달러로 진행되었음에도 다 쓰지 못했습니다.

키를 생성하는 과정. 크레딧 한도(credit limit) 필드는 안전장치 역할을 합니다. 저는 5달러로 하드 캡(hard cap)을 설정했습니다.

실험 후 동일한 키: 5달러 한도 중 4.59달러 사용. 이 글의 모든 내용은 그 범위 내에서 실행되었습니다.

둘째, Claude Code가 이를 가리키도록 설정합니다. Claude Code 설정에 다음 다섯 줄을 추가하면 됩니다:

ANTHROPIC_BASE_URL = https://openrouter.ai/api
ANTHROPIC_AUTH_TOKEN = your_openrouter_key
ANTHROPIC_DEFAULT_OPUS_MODEL = z-ai/glm-5.2
...

이를 입력하고 Claude Code를 시작하면 GLM과 대화할 수 있습니다. 다시 Claude로 돌아가려면 해당 부분을 주석 처리하면 됩니다. 이것이 전환의 전부입니다.

셋째, 그리고 대부분의 사람들이 건너뛰는 단계인데, 제공자(provider)를 고정(pin)해야 합니다. OpenRouter에서는 동일한 모델 이름이라도 수많은 서로 다른 기업들이 서비스를 제공할 수 있으며, 가격은 100만 토큰당 1달러 미만부터 3달러 이상까지 천차만별입니다. 이러한 가격 차이는 우연이 아닙니다. 일부 호스트는 모델의 양자화(quantized) 버전을 실행하는데, 이는 더 작고 빠르지만 측정 가능한 수준으로 더 멍청합니다. 이 때문에 Providers 탭에는 양자화 필터(quantization filter)까지 있습니다. 만약 OpenRouter의 자동 라우팅(auto-route)에 맡긴다면 이러한 모델 중 하나에 연결될 수 있으며, 그러면 당신은 진짜를 테스트하고 있다고 생각하면서 실제로는 압축된 가짜(knockoff)를 테스트하게 되는 것입니다.

동일한 모델 이름, 수십 개의 호스트, 실제 가격 차이. 이것이 바로 당신이 제공업체(provider)를 고정해야 하는 이유입니다.

저는 라우팅(routing)을 퍼스트 파티 호스트(first-party host)인 Z.ai로 직접 설정하고, 폴백(fallback) 기능을 껐습니다. 모든 요청은 실제 풀 프리시전(full-precision) 모델에만 도달했으며 그 외의 것은 없었습니다. 공정한 비교가 목적이라면, 이 토글(toggle) 설정이 게임의 전부입니다.

내가 틀렸던 부분: 내 코드라고 해서 모두 공유할 수 있는 것은 아니다

여기 제가 저지를 뻔한 실수가 있습니다. 저는 제 전체 모노레포(monorepo)를 제3자 모델(third-party model)로 향하게 하려 했습니다.

제 SDK는 오픈 소스(open source)입니다. 하지만 동일한 레포지토리(repo) 안에는 오픈되지 않은 것들이 함께 들어 있습니다. 동적 온보딩 키트(dynamic onboarding kit), 결제(billing), 테넌트 로직(tenant logic), 즉 돈을 벌기 위해 만들어진 작업물들 말입니다. 이를 다른 나라에 있는 호스팅 모델(hosted model)로 보내는 것은, 이미 유출된 후에야 깨닫게 되는 바로 그 종류의 무심한 유출(casual leak)입니다.

그래서 어떤 것도 실행하기 전에, 저는 깨끗한 복사본을 만들었습니다. 보여줄 수 있는 부분인 SDK 패키지와 에이전트 백엔드(agent backend)를 포함한 멘탈 코치(mental coach) 예제만을 추출했고, 상업용 코드는 원래 있어야 할 제 디스크에 남겨두었습니다. 그런 다음 지루하지만 중요한 단계를 수행했습니다. 복사본에서 정체를 드러낼 수 있는 단어들인 onboarding, billing, tenant, stripe를 검색했고, 단 하나의 토큰(token)이라도 제 기기를 떠나기 전에 검색 결과가 0건임을 확인했습니다.

그 습관이 핵심입니다. 모델이 저렴하다고 해서 규칙이 바뀌지는 않습니다. 공개된 코드(Public code)는 호스팅된 API로 보낼 수 있습니다. 하지만 비공개 코드(Private code)는 로컬에 남겨두거나, 아예 보내지 말아야 합니다. 저는 얼마 전에도 같은 이유로 클라이언트 백엔드를 위해 더 비싸지만 EU 보안 기준을 준수하는 모델을 선택하는 방법에 대해 글을 썼으며, 이번 모델이 테스트해 보기 즐거웠다고 해서 그 논리가 변하지는 않습니다.

작업 1: 내 SDK를 읽고 어디서 문제가 발생하는지 말해줘

첫 번째 작업은 순수한 읽기 테스트였습니다. 저는 GLM에게 마치 제가 그 위에 차세대 도구를 구축하려는 것처럼 아키텍처를 감사(Audit)하라고 지시했습니다. 하중을 견디는 이음새(load-bearing seams)를 찾아내고, 파일 이름을 명시하며, 무엇이 가장 먼저 깨질지 말해달라고 했습니다. 그리고 가장 중요한 규칙은 다음과 같았습니다: 모든 주장에는 실제 파일과 줄 번호를 인용할 것, 그리고 확실하지 않다면 무언가를 지어내지 말고 모른다고 말할 것.

모델은 41개의 파일을 읽었습니다. 그러고 나서 제가 이미 존재한다는 것을 알고 있었던 세 가지 실제 문제점을 찾아낸 감사 보고서를 제출했습니다.

모델은 제 컴포넌트 타입(component types)이 앱이 시작될 때 번들(bundle)에 봉인(sealed)된다는 점을 찾아냈습니다. 이는 에이전트(agent)가 런타임(runtime)에 새로운 컴포넌트를 정의할 수 없음을 의미하며, 이는 제 다음 기능에 정확히 필요한 사항이었습니다. 또한 스트리밍(streaming)을 처리하는 어댑터(adapter)가 스트리밍 메서드를 구현하지 않았기 때문에, 제 메인 에이전트 경로에서 스트리밍이 조용히 작동하지 않고 있다는 점도 찾아냈습니다. 마지막으로 제가 무시해 왔던 드리프트 버그(drift bug)를 찾아냈는데, 제 SDK는 13개의 컴포넌트를 렌더링할 수 있지만 서버는 그중 11개만 허용하고 모델에게는 7개만 알려주기 때문에, 두 개의 멀쩡한 컴포넌트에 에이전트를 통해 접근할 수 없는 상태였습니다.

저는 이 모든 것을 그대로 믿지 않았습니다. 인용된 문헌들을 하나하나 살펴보고, 코드 내에서 각 항목을 검색(grep)해 보았습니다. 그것들은 실제였습니다. 파일 경로도 맞았고, 줄 번호도 정확했으며, 단 하나의 함수도 지어내지 않았습니다. 심지어 제가 표시하지 않았던 부분까지 잡아냈습니다. 제 백엔드 코드에 최신 Claude 모델을 사용한다고 자랑스럽게 적혀 있는 주석이 있었는데, 정작 그 바로 아래 코드에서는 더 저렴한 OpenAI 모델을 호출하고 있었습니다. 작은 거짓말이 되어버린 오래된 주석이었죠. 제가 곧 무시하려 했던 모델치고는 눈썰미가 좋았습니다.

그 감사(audit)에는 59센트가 들었고, 6분이 소요되었습니다.

작업 두 번째: 이제 그중 하나를 수정하라

읽는 것은 별개의 문제입니다. 읽기야말로 모든 모델이 똑똑해 보이는 영역이니까요. 그래서 저는 말했습니다. '좋아, 내 코드를 읽을 수 있다면, 이제 직접 만져봐.'

저는 모델이 스스로 수행한 감사 결과 중 가장 어려운 수정 사항을 과제로 주었습니다: 컴포넌트 드리프트(component drift)를 완전히 제거할 것. SDK를 단일 진실 공급원(single source of truth)으로 만들고, 이를 기반으로 매니페스트(manifest)를 생성한 뒤, 서버가 직접 타이핑한 목록 대신 그 매니페스트를 읽도록 하여 두 시스템이 다시는 동기화되지 않는 일이 없도록 할 것. 그리고 만약 동기화가 깨지면 실패하는 테스트를 작성할 것.

모델은 해냈습니다. 매니페스트를 생성하고, 서버가 이를 읽도록 재배선(rewire)했으며, 고립되었던 두 컴포넌트를 실제 SDK 내장 기능으로 승격시켜 마침내 접근 가능하게 만들었고, 드리프트 방지 테스트(drift guard test)를 작성했습니다. 제가 직접 테스트 스위트를 실행했을 때, 기존의 87개는 그대로 유지된 채 5개의 새로운 테스트가 추가되어 총 92개의 테스트가 통과되었습니다. 그다음 저는 일부러 시스템을 망가뜨려 보았습니다. 매니페스트에서 컴포넌트 하나를 수동으로 삭제하고 방지 테스트를 다시 실행했습니다. 테스트는 정확히 예상했던 지점에서 요란하게 실패했습니다. 안전망에 이빨이 달려 있었던 것입니다.

또한 모델은 진행 과정에서 정말 짜증 나는 툴체인(toolchain) 함정, 즉 테스트 러너가 특정 파일을 로드하지 못하게 만드는 React Native의 구문(syntax) 문제에 부딪혔습니다. 하지만 모델은 이를 숨기거나 포기하는 대신, 작은 우회 방법(workaround)을 만들어냈고, 그 문제를 주의 사항(caveat)으로 보고서에 기록했습니다. 저에게는 그런 정직함이 깔끔해 보이는 결과보다 더 가치 있습니다.

함정, 왜냐하면 함정은 항상 존재하니까