에이전트의 Memory를 잃지 않고 GLM-5.3으로 전환하는 방법 (2026)

먼저 GLM-5.3이 무엇인지부터 시작하겠습니다. 이것이 답변의 방향을 결정하기 때문입니다. Z.ai는 "GLM-5.3을 위해 우리가 한 일은 사후 학습(post-training)의 스케일링뿐입니다"라고 말합니다. 즉, GLM-5.2와 동일한 베이스 모델을 사용하며 모든 성능 향상은 사후 학습에서 비롯되었습니다. 보고된 성능 향상은 실질적이고 구체적입니다. Terminal-Bench 3.0은 4.6에서 28.3으로, DeepSWE v1.1은 46.2에서 66.9로, Agents' Last Exam (CLI)은 23.8에서 28.5로 상승했으며, Z.ai는 "자체 Z.ai Code Bench에서 GLM-5.2 대비 50% 향상되었다"고 주장합니다. 이 마지막 수치에 대해 솔직하게 짚고 넘어갈 두 가지가 있습니다. Z.ai Code Bench는 Z.ai의 자체 비공개 벤치마크로, 회사 측은 이를 "공개 테스트 세트로부터의 오염 위험을 줄이기 위한 것"이라고 설명합니다. 또한 동일한 섹션에서 "GLM-5.3은 Max effort에서 39.5%에 도달하는 Claude Fable 5보다 여전히 뒤처져 있다"고 명시하고 있습니다. 가중치(Weights) 역시 아직 공개되지 않았습니다. "안전성 평가 및 강화 작업이 완료되는 대로 출시 후 2주 이내에 가중치를 공개할 예정입니다."

이 중 어느 것도 에이전트가 알고 있는 정보를 바꾸지 않습니다. 모델 교체는 추론을 수행하는 주체를 바꿀 뿐, 추론이 읽어오는 기반 데이터에는 손을 대지 않습니다. Z.ai의 자체 개발자 문서에서도 Memory에 관한 페이지에서 대부분의 벤더 문서보다 이 메커니즘을 더 잘 설명하고 있습니다. "Memory는 코딩 에이전트가 작업 및 세션 전반에 걸쳐 context를 유지할 수 있도록 하여 반복적인 입력을 줄이고 실행 효율성을 향상시킵니다." 그리고 주요 예시로 사용하는 도구에 대해 "각 세션은 새로운 context 창으로 시작됩니다. 세션 간 지식 전달은 주로 영구적인 지침 파일을 통해 이루어집니다"라고 설명합니다.

따라서 이전 목록은 명확하게 나뉩니다.

리포지토리나 홈 디렉토리에 있으므로 무료로 이동하는 것. 지침 파일(CLAUDE.md, AGENTS.md, .cursor/rules 등 도구가 읽는 모든 파일), 경로 범위 규칙, 스킬, MCP 서버 구성(이는 모델 기능이 아니라 서버를 가리키는 설정 파일입니다), git 이력, 테스트 스위트, 빌드 명령 등입니다. 에이전트가 프로젝트에 대해 알고 있는 지식이 diff에 표시될 수 있는 어딘가에 기록되어 있다면, 모델 교체는 에이전트에게 보이지 않게 진행됩니다.

이동하지 않으며, 아무도 알려주지 않는 것. 이전 모델이 실행 중인 세션 내에서 축적한 모든 것(수립한 계획, 배제한 막다른 길, 한 시간 전에 제공한 수정 사항 등)입니다. 이는 context였으며, context는 다음에 어떤 모델을 사용하든 세션 종료와 함께 끝납니다. 도구가 로컬의 도구 전용 Memory 저장소에 기록한 모든 것도 그대로 남습니다. 디스크에는 여전히 존재하지만 다른 설정을 위해 작성된 것이므로, 모델과 도구를 동시에 변경했다면 전혀 읽히지 않습니다.

애매한 중간 영역. 자동 생성된 Memory 파일이 이 중간에 위치합니다. 파일이기 때문에 보존되지만, 다른 모델과의 세션을 압축하여 작성된 것이므로 그 유용성은 해당 노트가 지속적인 사실("API 테스트에는 로컬 Redis 인스턴스가 필요함")인지 아니면 특정 모델의 행동에 대한 반응("파일 전체를 다시 포맷하지 않도록 상기시킬 것")인지에 따라 달라집니다. 첫 번째 종류는 보관할 가치가 있습니다. 두 번째 종류는 그런 습관이 전혀 없는 새 모델로 가져가게 될 노이즈에 불과합니다.

다음 순서대로 두 단계를 진행합니다. 첫 번째 단계는 필수 사항입니다. 건너뛰면 요청이 완전히 실패합니다.

1단계: 모델 ID를 변경하기 전에 thinking 설정을 수정하세요

GLM-5.3은 요청 형태의 기본값을 변경했으며, Z.ai는 이를 주요 변경 사항(breaking change)으로 표시했습니다. 발표 내용에 따르면 다음과 같습니다. "GLM-5.3은 세 가지 thinking effort 수준(low, high, max)을 지원합니다. GLM-5.3에서는 thinking 비활성화를 더 이상 지원하지 않습니다." 문서화된 마이그레이션 참고 사항은 명확합니다. "마이그레이션 필요: 현재 애플리케이션에서 thinking.type: "disabled"를 사용하는 경우, 모델 ID를 glm-5.3으로 업데이트하기 전에 이를 enabled로 변경하고 reasoning_effort를 low로 설정해야 합니다. 그렇지 않으면 요청이 실패합니다."

설정을 먼저 변경한 다음 모델 ID를 변경하세요. 순서를 바꾸면 서비스 장애처럼 보이는 요청 실패가 발생합니다. 기본 reasoning_effort는 max이며, Z.ai는 코딩 작업에 이를 권장하지만, 이는 이전에 thinking을 끈 상태로 실행되던 파이프라인과 바로 호환되지 않습니다. 자체 코드가 아닌 기존 도구에 이를 연결하는 경우, Z.ai 문서에 따르면 "GLM Coding Plan은 Anthropic 및 OpenAI 프로토콜을 모두 지원"하며 프로토콜별로 별도의 베이스 URL을 제공합니다. Anthropic Messages 엔드포인트는 https://api.z.ai/api/anthropic이므로, 도구 측 변경 사항은 대개 베이스 URL과 키를 입력하는 것입니다. Team Plan 사용자는 "Team Plan Key는 다른 Z.AI의 API Key와 혼용할 수 없다"는 문서상의 제한 사항에 유의해야 합니다.

2단계: 파일 외부에 존재하던 정보의 인벤토리 작성하기

이 단계는 사람들이 흔히 건너뛰는 단계이며, 일주일 후에 대가를 치르게 되는 단계입니다. 전환하기 전에 리포지토리를 열고 네 가지 질문에 대한 답변을 작성해 보세요. 머릿속이 아니라 파일에 작성해야 합니다.

에이전트가 알고 있었지만 어디에도 기록되지 않은 것은 무엇인가요? 커밋하는 대신 채팅에서 수정한 모든 컨벤션, 세션 중간에 언급한 "여기서는 그런 식으로 하지 않습니다"와 같은 모든 내용이 해당됩니다. 유일한 기록이 곧 종료될 세션뿐이라면, 그 정보는 사라집니다.

선택하지 않기로 결정한 방식은 무엇이며, 그 이유는 무엇인가요? 거부된 접근 방식은 모든 프로젝트에서 가장 가치 있으면서도 가장 보존되기 어려운 지식입니다. 새 모델은 여러분이 이미 큐(queue) 기반 버전을 시도했다가 포기했다는 사실을 알지 못하므로, 이를 다시 열정적으로 제안할 것입니다. 거부한 사실과 그 이유를 기록해 두세요. 그 이유가 반복되는 루프를 막아주기 때문입니다.

어떤 지침이 프로젝트가 아닌 이전 모델에 관한 것이었나요? 지금 이러한 지침을 정리하세요. 특정 모델의 습관을 우회하기 위해 존재하는 지침은 잘해야 쓸모없는 짐이고, 최악의 경우 오해를 불러일으킵니다. 새 모델에게 발생하지도 않는 문제를 방어하도록 가르치는 꼴이 되기 때문입니다. Z.ai의 Memory 페이지에는 다음과 같은 경고가 있습니다. 에이전트는 "지침을 읽고 따르려고 노력하겠지만, 규칙이 모호하거나 불분명하거나 상충되는 경우 엄격한 준수를 보장할 수 없습니다." 오래된 우회책들이 쌓이면 바로 지침이 상충되는 원인이 됩니다.

여러 기기에 분산되어 있는 것은 무엇인가요? 노트북과 워크스테이션을 모두 사용한다면, 도구가 생성한 Memory가 기기 로컬에 저장되어 있는지 확인하세요. 대부분은 그렇습니다. 모델 교체는 에이전트가 축적한 지식의 절반이 단 한 대의 컴퓨터에만 존재한다는 사실을 깨닫기에 좋은 타이밍입니다. 이는 Claude Code가 기기 간에 망각하는 이유에서 다룬 문제와 동일하며, 저절로 해결되지 않습니다.

이 인벤토리가 리포지토리 내의 파일로 존재하게 되면, 모델 교체는 진정으로 단순한 설정 변경이 됩니다. 그렇지 않다면 수개월 동안 도구에 아웃소싱해 왔던 기억들을 직접 기억해 내야 하는 상황에 처하게 됩니다.

위의 인벤토리 작성은 효과가 있으며, 한 번은 꼭 해야 합니다. 하지만 매번 이 작업을 반복해서는 안 됩니다. GLM-5.3의 출시 속도로 보아 이제 "매번"은 몇 주 간격을 의미하게 될 것입니다. 대안은 에이전트의 지식을 실행 중인 모델의 속성으로 취급하는 것을 멈추고, 어떤 모델이든 읽을 수 있는 독립적인 공간을 제공하는 것입니다.

이것이 바로 MemoryLake가 존재하는 이유입니다. 도구가 연결되는 Memory 레이어를 제공하여 프로젝트에 대한 지식은 한 곳에 머물고, 그 뒤의 모델은 언제든 교체 가능한 부품이 되도록 합니다. 오늘 GLM-5.3으로 전환하고 다음 달에 다른 모델로 돌아가더라도 Memory는 이동하지 않습니다. 모델 내부에 있었던 적이 없기 때문입니다. 설정은 세 단계로 진행됩니다.

1단계: API 키 생성하기

MemoryLake에 로그인하고 API 키를 생성합니다. 이 키는 도구가 Memory를 읽고 쓰기 위해 사용하는 인증 정보이며, 특정 에디터에 종속되지 않는 유일한 설정 요소입니다. 현재 선택한 도구보다 더 오래 지속되는 레이어를 구축하는 것이 핵심 목적이기 때문입니다.

2단계: 첫 번째 Memory 업로드하기

방금 작성한 인벤토리와 함께 아키텍처 노트, 결정 로그, 온보딩 문서, 지금까지 아무도 기록하지 않았던 디자인 제약 조건 등 프로젝트를 실제로 설명하는 문서를 업로드합니다. "왜 거부했는가"에 대한 항목들이 바로 여기에 들어가야 합니다. 새 모델이 가장 필요로 하면서도 스스로 유추하기 가장 어려운 정보이기 때문입니다. 항목은 짧고 사실 중심으로 유지하세요. Memory 레이어는 긴 분량이 아니라 검색 가능성(retrievability)으로 가치를 증명합니다.

3단계: AI 및 에이전트 연결하기

실제로 사용하는 도구들을 연결합니다. MemoryLake는 MCP 및 API를 통해 Memory를 노출하므로, Claude Code, Codex, OpenClaw 등 네이티브 MCP를 지원하는 에이전트는 MCP 서버를 가리키는 방식으로 연결하고, 그 외의 도구는 API를 통해 동일한 Memory를 읽을 수 있습니다. 이러한 도구 중 하나에서 GLM-5.3을 실행하는 경우, 모델 교체는 매우 단순해집니다. 에이전트는 어제 읽었던 것과 동일한 Memory를 계속 읽고, 단지 읽는 모델만 바뀔 뿐입니다. MCP 설정에 대한 자세한 안내는 MCP로 크로스 AI Memory 설정하는 방법을 참조하세요.

한 가지 분명한 한계는, MemoryLake는 사용자나 에이전트가 입력한 정보만 저장한다는 점입니다. 이전 모델의 종료된 세션에 접근하여 나눈 대화를 복구해 주지 않으며, 규칙을 직접 기록하는 일을 대신해 주지도 않습니다. 이는 다시 설명하는 번거로움을 없애줄 뿐, 의사결정 자체를 대신해 주지는 않습니다.

실질적인 차이는 첫 번째가 아니라 세 번째나 네 번째로 모델을 변경할 때 나타납니다.

모델 선택을 되돌릴 수 있게 됩니다. 현재 대부분의 팀은 모델 전환을 되돌리기 힘든 결정으로 여깁니다. 이전 모델로 돌아가려면 context를 다시 두 번 구축해야 하기 때문입니다. context가 모델 외부에 존재하면, 일주일 동안 하나의 리포지토리에서 GLM-5.3을 실행해 보고 이전 모델과 비교한 뒤, 어느 쪽으로든 추가 비용 없이 다시 전환할 수 있습니다. 출시 시점에 GLM-5.3의 가중치 공개가 아직 2주 남았다는 점을 고려하면, 선택지를 열어두는 것은 분명한 가치가 있습니다.

벤치마크가 결정의 전부가 되지 않습니다. Terminal-Bench 점수는 모델의 역량에 대해 실질적인 정보를 제공합니다. 하지만 그 모델이 여러분의 결제 모듈이 핵심적인 역할을 한다는 사실을 알고 있는지에 대해서는 아무것도 알려주지 않습니다. 이 두 가지를 분리하는 팀은 더 나은 모델 결정을 내릴 수 있습니다. 잃게 될 프로젝트 지식의 양을 걱정하는 대신, 모델 자체의 장단점만을 기준으로 모델을 평가할 수 있기 때문입니다.

토큰 소비가 당연한 이유로 감소합니다. Z.ai가 설명하는 GLM-5.3의 효율성은 "모든 effort 수준에서 GLM-5.2보다 현저히 강력한 에이전트 코딩 결과를 제공하는 동시에 더 적은 출력 토큰을 소비한다"는 것입니다. 검색된 Memory는 다른 측면에서 동일한 효과를 냅니다. 컨벤션을 찾아볼 수 있는 에이전트는 모든 프롬프트에 컨벤션을 붙여넣을 필요가 없습니다. 어시스턴트에게 context를 계속 다시 설명해 왔다면, 그 습관에는 측정 가능한 비용이 따릅니다.

새로운 모델 출시 주기가 더 이상 혼란을 주지 않습니다. 이번 분기에만 벌써 네다섯 번째 주목할 만한 코딩 모델 출시입니다. 매번 출시를 마이그레이션이 아닌 업그레이드로 받아들이는 팀은 지식 레이어가 더 이상 벤더의 세션 저장소에 묶여 있지 않은 팀들입니다.

한 번에 하나의 변수만 변경하세요. 같은 날 오후에 모델과 도구를 동시에 바꾸지 마세요. 성능이 저하되었을 때 어떤 변경 사항이 원인인지 파악해야 하기 때문입니다.

전환 후 지침 파일을 다시 읽어보세요. 특정 모델에 맞춘 우회책들이 보이지 않게 쌓여 있을 수 있습니다. 새 모델로 전환하는 시점은 이를 삭제할 수 있는 가장 좋은 기회이며, 불필요한 우회책을 삭제하면 남은 규칙에 대한 준수율이 눈에 띄게 향상됩니다.

가정하지 말고 로드된 내용을 확인하세요. 어떤 도구를 사용하든 대개 세션에 로드된 지침 및 Memory 파일을 나열하는 방법이 있습니다. 전환 후 한 번 확인해 보세요. 소리 없이 로드되지 않은 규칙 파일은 마치 모델이 지침을 따르지 않는 것처럼 보일 수 있습니다.

지속적인 사실과 세션 반응을 분리하세요. "npm 대신 항상 pnpm을 사용하라"는 지속적인 사실입니다. "파일 전체를 다시 작성하지 말라"는 특정 모델의 행동에 대한 반응입니다. 이 둘을 같은 곳에 보관하면 지침 파일이 쓸모없어집니다.

effort 수준을 의도적으로 설정하세요. GLM-5.3은 기본값이 max이며, Z.ai는 코딩 작업에 max를 권장합니다. 작업이 주로 짧은 조회 위주라면 low가 존재하는 이유가 있습니다. 또한 thinking: disabled 설정에서 마이그레이션한 경우, 문서에 명시된 상응하는 시작점은 low입니다.

거부된 사항을 주요 항목으로 기록해 두세요. 여러분이 이미 배제한 방식을 모델이 읽을 수 있는 곳에 기록해 두지 않으면, 앞으로 사용할 모든 모델이 이를 다시 제안할 것입니다. 이 한 가지 습관이 그 어떤 설정 튜닝보다 더 많은 시간을 절약해 줍니다.

GLM-5.3은 여러분의 환경이 얼마나 이식성이 높은지 테스트해 볼 수 있는 매우 명확한 기회입니다. 도구를 변경할 필요가 없으므로 답은 명확해집니다. 모델을 교체한 후에도 프로젝트에 대한 에이전트의 지식이 유지된다면 그것은 지속 가능한 어딘가에 기록되어 있었던 것이고, 그렇지 않다면 그동안 세션 내에 임시로 머물러 있었던 것입니다.

모델 ID를 변경하기 전에 thinking 설정을 수정하고, 인벤토리를 한 번 작성한 뒤, 현재 벤치마크에서 우세를 보이는 모델에 종속되지 않는 곳에 그 결과를 저장하세요. 그렇게 하면 조만간 있을 다음 모델 출시 때는 일주일 동안 다시 설명하는 대신 설정 파일의 한 줄만 수정하면 됩니다. 여러 모델 전환을 동시에 고민하고 있다면 context 분실 없이 AI 모델 간 전환하기에서 일반적인 패턴을 다루고 있으며, Kimi K3 및 GPT-5.6에 대한 모델별 가이드도 준비되어 있습니다.