오픈소스계의 Opus 순간: GLM-5, Agentic Coding의 바통을 이어받을 수 있을까?

만약 개발자에게 AI 프로그래밍에서 가장 절망적인 순간이 언제냐고 묻는다면?

그는 아마 오류 앞에서 기계적으로 "죄송합니다, 제가 잘못 이해했습니다"라고 말하며 똑같이 잘못된 코드를 반복하는 순간이라고 답할 것입니다.

지난 1년 동안 Coding 대형 모델의 발전은 주로 "생성 능력"에 집중되었습니다. 한 문장으로 웹 페이지, 컴포넌트, 미니 게임을 생성하는 것, 즉 15초 안에 픽셀 스타일 웹 페이지, 멋진 SVG 아이콘 또는 실행 가능한 스네이크 게임을 만드는 것입니다. 이러한 데모는 충분히 놀랍지만, 충분히 "가볍습니다". 마치 Vibe Coding(분위기 코딩) 시대에 만들어진 고급 장난감과 같습니다. 그러나 고성능 동시 접속 아키텍처, 하위 드라이버 적응 또는 복잡한 시스템 재구축과 관련된 경우에는 "온실 속 화초"가 됩니다.

그래서 최근 실리콘밸리의 분위기가 바뀌었습니다.

Claude Opus 4.6이든 GPT-5.3이든, 이러한 최고 수준의 대형 모델은 Agentic Coding을 강조하기 시작했습니다. 즉, "즉시 결과"를 추구하는 것이 아니라 계획, 분해, 반복 실행을 통해 시스템 수준의 작업을 완료하는 것입니다.

이러한 "프런트엔드 미학"에서 "시스템 엔지니어링"으로의 패러다임 전환은 폐쇄형 거대 기업의 독점 영역으로 여겨졌습니다. GLM-5를 테스트해보고 나서야 오픈소스 커뮤니티의 "아키텍트 시대"가 앞당겨졌다는 것을 깨달았습니다.

01

"프런트엔드"에서 "시스템 엔지니어링"으로

이전에 AI Coding에 대해 이야기할 때, 대부분 익숙한 이야기, 즉 한 문장으로 웹 페이지 생성, 1분 안에 미니 게임 만들기, 10초 안에 멋진 동적 효과 만들기를 떠올렸습니다. 이러한 것들은 "시각적 쾌감"을 강조합니다. 버튼이 움직이고, 페이지가 예쁘고, 특수 효과가 풍부합니다.

그러나 실제로 엔지니어링 현장에 들어간 사람들은 데모를 생성할 수 있다고 해서 시스템을 지원할 수 있는 것은 아니라는 것을 알고 있습니다.

복잡한 작업의 어려움은 "코드를 작성하는 것"에 있는 것이 아니라 모듈을 어떻게 분할하고, 상태를 어떻게 관리하고, 예외를 어떻게 처리하고, 성능을 어떻게 최적화하고, 시스템이 복잡해지기 시작할 때 구조적 안정성을 유지할 수 있는지에 있습니다.

이것이 우리가 복잡한 작업을 실제 테스트 대상으로 선택한 이유입니다.

GLM-5의 포지셔닝은 많은 경쟁 제품과 다릅니다.

대부분의 모델이 "우수한 프런트엔드"와 같아서 빠른 인터랙티브 인터페이스와 시각 효과를 생성하는 데 능숙하다면, GLM-5는 "시스템 엔지니어링 역할"에 더 가깝습니다. GLM-5는 다중 모듈 협업, 긴 링크 작업, 생산 환경에서 실행 가능한 구조적 안정성을 강조합니다.

이를 검증하기 위해 완전히 다른 두 가지 차원의 실제 테스트 사례를 설계했습니다.

첫 번째 테스트는 가벼워 보이지만 실제로는 고도로 시스템화된 작업, 즉 브라우저와 카메라를 기반으로 "AI 시각적 제스처로 불꽃놀이를 제어하는" 설날 테마 인터랙티브 게임을 구현하는 것입니다.

실제 테스트 비디오에서 사용자가 카메라 앞에 서서 제스처를 통해 불꽃놀이 발사 방향과 리듬을 제어하는 것을 볼 수 있습니다. 불꽃놀이가 공중에서 터지면서 입자 효과와 동적 조명 효과 피드백이 함께 제공되어 전체적인 상호 작용이 부드럽고 자연스럽습니다.

그러나 이것은 간단한 프런트엔드 동적 효과 프로젝트가 아닙니다. 여기에는 최소한 다음과 같은 몇 가지 핵심 모듈이 포함됩니다. 제스처 인식 및 시각적 입력 처리, 제스처 좌표에서 발사 로직으로의 매핑, 불꽃놀이 입자 시스템 및 폭발 효과, 실시간 렌더링 및 프레임 속도 제어, 브라우저 호환성 및 카메라 권한 예외 처리, 상호 작용 상태 관리 및 사용자 피드백 메커니즘

완전한 구조와 부드러운 경험을 제공하는 소규모 인터랙티브 시스템이라고 할 수 있습니다. 실제 테스트 과정에서 GLM-5는 코딩에 직접 들어가지 않고 먼저 전체 아키텍처를 계획합니다. 시각적 입력 모듈, 제어 로직 계층, 렌더링 계층, 특수 효과 계층을 어떻게 분리할 것인지, 데이터 흐름을 어떻게 전달할 것인지, 어떤 부분이 성능 병목 현상이 될 수 있는지 등을 계획합니다.

그런 다음 제스처 인식의 데이터 처리부터 시작하여 발사 궤적 계산, 입자 폭발 효과의 매개변수 조정에 이르기까지 로직을 계층별로 구현합니다.

렌더링이 멈추면 입자 수를 줄이고 루프 구조를 최적화하도록 적극적으로 제안합니다. 제스처 인식 오류가 발생하면 임계값과 필터링 전략을 조정합니다.

비디오에 표시되는 효과는 "매우 자연스러운 상호 작용"입니다. 그러나 그 뒤에는 계획 → 작성 → 디버깅 → 성능 최적화 → 상호 작용 교정의 완전한 엔지니어링 체인이 반영되어 있습니다.

최종적으로 생성된 코드는 직접 실행할 수 있고, 상호 작용이 안정적이고, 프레임 속도가 부드럽고, 예외 상황을 처리할 수 있습니다. 더 중요한 것은 GLM-5의 작업 방식이 명확한 시스템 사고방식을 보여준다는 것입니다. 모듈 경계가 명확하고 로직 계층화가 합리적이며 모든 기능을 하나의 파일에 쌓아두지 않습니다.

두 번째 사례 테스트는 구조 시스템 기능입니다. 이 시나리오는 미디어 작업의 일상이라고 할 수 있습니다. 인터뷰 속기를 가져와 내용을 요약하고 주제 각도와 아이디어를 출력합니다.

실제 테스트에서 볼 수 있듯이 작업 흐름은 매우 간단합니다. 얼마 전에 작성한 인터뷰 속기 내용을 붙여넣으면 모델이 분석을 시작한 다음 내용 요약과 주제 각도를 출력합니다. 결과적으로 모델이 생성한 주제 각도는 매우 실용적입니다.

시각적 상호 작용 시스템에 비해 녹음 정리는 간단해 보이지만 실제로는 모델의 "구조적 추상화 능력"을 테스트합니다. 실제 인터뷰 녹음은 종종 고도로 비구조화되어 있습니다. 관점이 엇갈리고, 정보가 반복되고, 주선과 지선이 얽혀 있습니다. 따라서 이 사례에서 GLM-5가 보여주는 능력은 시스템 수준에 있습니다.

첫째, 주제 식별 및 주선 추출 능력입니다. 모델은 원본 텍스트 순서대로 요약을 생성하지 않고 먼저 핵심 의제가 무엇인지 판단한 다음 이 의제를 중심으로 내용을 재구성합니다. 즉, 내부적으로 스캔을 완료하여 어떤 정보가 주선에 속하고 어떤 정보가 보충 또는 노이즈에 속하는지 식별합니다. 이러한 능력은 본질적으로 계획 능력, 즉 출력을 생성하기 전에 추상적 구조 프레임워크를 구축하는 능력입니다.

둘째, 모듈화 재구성 능력입니다. 서로 다른 단락에 흩어져 있는 관련 관점을 동일한 모듈로 분류합니다. 이러한 단락 간 통합 능력은 모델이 긴 텍스트를 처리할 때 전역적 일관성을 갖는다는 것을 의미합니다.

셋째, 논리적 순서를 능동적으로 조정하는 능력입니다. 실제 출력된 개요는 종종 원본 녹음 순서와 다릅니다. GLM-5가 인과 관계 또는 논증 로직에 따라 계층을 재정렬하고 있음을 알 수 있습니다. 이는 "원본 입력 순서보다 논리를 우선시하는" 판단력을 반영합니다. 이러한 "구조 우선, 출력 후" 모드는 시스템 엔지니어링 사고방식의 핵심입니다.

이 두 가지 사례는 하나는 실시간 시각적 상호 작용 시스템이고 다른 하나는 미디어 정보 구조 처리 시스템으로 완전히 다르게 보입니다. 그러나 GLM-5가 계획 → 실행 → 디버깅 → 최적화의 완전한 작업 폐쇄 루프 능력을 갖추고 있다는 동일한 사실을 검증합니다.

불꽃놀이 게임에서는 모듈 계층화, 성능 최적화 및 예외 처리에 반영되고, 녹음 프로세서에서는 주제 판단, 구조 분해 및 논리 재구성에 반영됩니다. 이들의 공통점은 모델이 "결과 생성"에 머무르지 않고 지속적으로 진화할 수 있는 구조를 유지한다는 것입니다.

나는 비교적 복잡한 작업인 "최소한의 운영 체제 커널 구축"을 계속 시도했습니다. 이 실제 테스트에서 실제로 주목해야 할 것은 비디오에서 코드가 최종적으로 실행되는 것이 아니라 GLM-5가 전체 과정에서 행동하는 방식입니다.

GLM-5는 작업을 받자마자 즉시 생성 상태로 들어가지 않고 먼저 작업 경계를 명확히 하고 모듈을 능동적으로 분할하고 시스템 구조를 계획한 다음 구현 단계로 들어갑니다. 이러한 "구조 우선" 경로는 본질적으로 앞에서 언급한 엔지니어링 사고방식, 즉 구체적인 구현 세부 사항을 논의하기 전에 시스템이 어떻게 구성되는지 먼저 정의하는 것이지 작성하면서 조립하는 것이 아닙니다.

여러 번의 작성, 실행, 오류 발생, 수정 루프에서 GLM-5는 구조 붕괴를 일으키지 않았습니다. 모든 수정은 기존 아키텍처를 중심으로 전개되었으며 처음부터 다시 시작하거나 부분적으로 패치를 적용하지 않았습니다. 이는 내부적으로 완전한 시스템 모델을 유지하고 긴 링크 작업에서 일관성을 유지할 수 있음을 의미합니다. 많은 모델이 컨텍스트가 길어지면 앞뒤가 맞지 않기 쉽지만 비디오의 표현은 전체 구조에 대한 지속적인 기억 능력을 정확하게 반영합니다.

오류를 처리하는 방식도 있습니다. 오류가 발생하면 "특정 코드 줄의 문제일 수 있다"는 표면적인 추측에 머무르지 않고 먼저 오류 유형을 판단하고 논리 문제, 환경 문제 또는 종속성 충돌을 구분한 다음 조사 경로를 계획합니다. 이는 문제 경로를 수정하기 위한 전략적 디버깅입니다.

도구 호출과 결합하면 이러한 능력이 더욱 분명해집니다. 명령 제안을 제공할 뿐만 아니라 터미널 실행을 능동적으로 예약하고, 로그를 분석하고, 환경을 복구한 다음 작업을 계속 진행합니다. 이러한 행동은 이미 일종의 "자율 주행"식 엔지니어링 추진에 가깝습니다. 목표가 완료되지 않으면 계속 반복합니다.

먼저 계획한 다음 실행하고, 긴 링크에서 구조적 안정성을 유지하고, 전략적 방식으로 문제를 조사하고, 목표를 중심으로 지속적으로 추진하는 것은 시스템 엔지니어링에 필요한 네 가지 핵심 능력이 중첩되어 GLM-5가 엔지니어의 작업 방식에 가까운 행동 패턴을 보이기 시작합니다.

GLM-5가 "아키텍트"의 바통을 이어받을 수 있는 이유는 무엇일까요?

첫 번째 부분의 실제 테스트에서 GLM-5가 "복잡한 작업을 수행할 수 있다"는 것을 증명했다면 다음 질문은 **무엇을 근거로 할 수 있는가?**입니다. 그 답은 출력 뒤에 숨겨진 전체 "엔지니어링 수준의 행동 패턴"에 있습니다.

핵심은 GLM-5가 Claude Opus 4.6과 유사한 사고 사슬 자체 검사 메커니즘을 명확하게 도입했다는 것입니다.

실제로 사용해 보면 작업을 받자마자 즉시 "코드를 채우기" 시작하는 것이 아니라 백그라운드에서 여러 번의 논리적 추론을 수행합니다. 모듈 간의 결합 관계를 예측하고, 데드 루프 경로를 능동적으로 피하고, 리소스 충돌 및 경계 조건 문제를 미리 발견합니다. 이러한 행동으로 인해 발생하는 직접적인 변화는 솔루션이 엔지니어링 측면에서 견고한지 확인하기 위해 속도를 늦추고 문제를 완전히 생각하려는 의지가 있다는 것입니다.

복잡한 작업에서 GLM-5는 먼저 시스템이 어떤 하위 모듈로 구성되어 있는지, 각 모듈의 입력 및 출력은 무엇인지, 어떤 부분을 병렬로 추진할 수 있는지, 어떤 부분을 직렬로 완료해야 하는지 등 명확한 모듈 분해를 제공합니다. 그런 다음 작성하면서 생각하는 것이 아니라 하나씩 극복합니다. 이를 통해 GLM-5의 작업 방식은 실제 엔지니어와 더 유사해집니다. 먼저 아키텍처 다이어그램을 그린 다음 구현 세부 사항을 작성합니다. 문제를 깨끗하게 해결하지 않으면 멈추지 않으려는 끈기가 분명히 느껴집니다. 겉보기에 올바른 부분을 완료하면 대충 마무리하는 것이 아닙니다.

이러한 차이점은 기존 Coding 모델과의 비교에서 특히 분명합니다. 과거의 많은 모델은 오류가 발생하면 사과하고, 오류 정보를 반복하고, 검증되지 않은 수정 제안을 제공하는 익숙한 모드로 빠르게 빠져들었습니다. 다시 실패하면 유사한 답변을 반복적으로 출력하기 시작했습니다. GLM-5의 처리 방식은 노련한 아키텍트와 더 유사합니다. 실제 테스트에서 프로젝트가 환경 종속성 문제로 인해 실행되지 않으면 표면적인 오류 정보에 머무르지 않고 종속성 트리(Dependency Tree)를 능동적으로 분석하고 충돌 원인을 판단한 다음 OpenClaw를 지시하여 환경을 복구합니다.

전체 과정은 "자율 주행"식 배포와 더 유사합니다. 모델은 수동적으로 응답하는 것이 아니라 지속적으로 로그를 읽고, 경로를 수정하고, 결과를 검증합니다.

또 다른 간과하기 쉽지만 시스템 엔지니어링에서 매우 중요한 능력은 컨텍스트 완전성입니다.

GLM-5의 백만 토큰 창을 통해 동일한 컨텍스트에서 전체 프로젝트의 코드 구조, 수정 기록, 구성 파일 및 실행 로그를 이해할 수 있습니다. 즉, 전체적인 관점에서 수정이 어떤 모듈에 연쇄 반응을 일으킬지 판단할 수 있습니다. 긴 링크 작업에서 이러한 능력은 모델이 "똑똑하지만 근시안적인지" 또는 "안정적이고 제어 가능한지"를 직접적으로 결정합니다.

종합적으로 볼 때 GLM-5가 "아키텍트" 역할을 실제로 이어받은 것은 아키텍트처럼 문제를 생각하기 시작했기 때문입니다. 먼저 계획하고, 그런 다음 실행합니다. 지속적으로 확인하고, 끊임없이 수정합니다. 단일 지점의 성공이 아닌 시스템 전체에 집중합니다.

이것이 첫 번째 부분에서 시스템 수준의 실제 테스트 작업을 완료할 수 있었던 근본적인 이유입니다.

03

오픈소스계의 Opus?

2026년의 대형 모델 생태계에서 GLM-5의 가치는 이전에는 거의 당연하게 받아들여졌던 사실, 즉 시스템 수준의 지능은 폐쇄형 모델에만 존재할 수 있다는 사실을 깨뜨리는 데 더 있습니다.

이전에 Claude Opus 4.6과 GPT-5.3은 실제로 "Agentic Coding" 경로를 성공적으로 실행했습니다. 모델은 즉각적인 피드백을 추구하는 것이 아니라 계획, 분해, 반복 실행을 통해 진정으로 복잡한 엔지니어링 작업을 완료합니다. 그러나 대가도 큽니다. 고강도 작업의 토큰 소비량이 매우 높고 완전한 시스템 수준의 시도는 종종 상당한 호출 비용을 의미합니다.

GLM-5는 여기서 다른 솔루션을 제공합니다. 오픈소스 모델로서 "시스템 아키텍트 수준의 AI"를 클라우드와 청구서에서 개발자 자신의 환경으로 되돌립니다. 로컬에 배포하여 로그 조정, 종속성 확인, 오래된 코드 수정, 경계 조건 보완 등 지저분하고 힘들고 큰 작업을 수행하는 데 시간을 할애할 수 있습니다.

이는 비용 효율성 측면에서 구조적인 변화로 볼 수 있습니다. 아키텍트 수준의 지능은 더 이상 소수의 팀의 특권이 아닙니다.

직업적 은유를 사용하여 이러한 차이점을 이해하면 더욱 직관적입니다. Kimi 2.5와 같은 모델은 미적 감각이 뛰어나고 상호 작용 감각이 매우 강한 우수한 프런트엔드 엔지니어와 더 유사하며 One-shot 생성, 시각적 표현 및 빠른 피드백에 능숙합니다. 반면 GLM-5의 스타일은 분명히 다릅니다. 모듈 관계, 예외 경로, 유지 관리 가능성 및 장기적인 안정적인 실행에 집중하는 노련한 시스템 아키텍트와 더 유사합니다.

그 뒤에는 프로그래밍 AI의 명확한 직업적 발전이 있습니다. "보기에는 멋진" Vibe Coding을 추구하는 것에서 견고성과 엔지니어링 규율을 강조하는 Engineering으로 나아가는 것입니다.

더 중요한 것은 GLM-5의 등장으로 1인 회사의 개념이 더욱 실현 가능해졌다는 것입니다.개발자가 로컬에서 시스템 설계를 이해하고, 장기간 실행 가능하며, 자체 수정이 가능한 AI 파트너를 보유할 수 있을 때, 원래 팀 규모가 필요했던 많은 엔지니어링 작업이 개인적으로 제어 가능한 범위로 압축되기 시작합니다. 앞으로 GLM-5는 1인 기업에서 핵심 엔지니어링 구현을 담당하는 '디지털 파트너'가 될 잠재력이 있습니다.