Z.ai의 GLM-5.2는 출시 이후 가장 많이 회자되는 오픈 웨이트 (open-weight) 모델 중 하나였으며, 저희는 다양한 코딩 작업에서 이 모델이 어떻게 작동하는지 확인하기 위해 이를 일상적인 도구로 사용해 왔습니다. 저희는 이미 백엔드 서비스를 계획하고 구축하는 과정에서 Kimi K2.7과 정면 대결을 시킨 적이 있습니다. 하지만 훨씬 덜 논의되고 있으며 저희가 계속 맞닥뜨리고 있는 문제는, 코드 리뷰 (code review) 품질이 실행할 때마다 얼마나 크게 요동치느냐 하는 점입니다.

이 모델로 코드를 리뷰했을 때 결과는 엇갈렸습니다. 때로는 날카로운 시니어 엔지니어처럼 보였지만, 때로는 실제 버그 (bug)를 그냥 지나치기도 했습니다. 이번 실험에서 저희는 이것이 프롬프트 (prompt) 문제인지 아니면 더 깊은 문제인지 알아내기 위해 통제된 테스트를 수행했습니다.

모델 테스트 방법

저희는 TypeScript를 사용하여 작은 백엔드를 구축했습니다: Bun, Hono, Drizzle, 그리고 SQLite를 사용한 작업 관리 API입니다. 여기에는 사용자, 인증 (authentication), 작업 (tasks), 검색, 일괄 작업 (bulk operations), 그리고 CSV 내보내기 (export)와 같은 표준적인 구성 요소들이 포함되었습니다. 먼저 올바른 동작을 고정하는 테스트 스위트 (test suite)를 작성한 다음, 코드에 버그를 심었습니다. 저희는 리뷰의 성적을 매기는 기준으로 해당 스위트를 사용했습니다. 버그는 저희의 에이전트 (agent)가 실제적이고 구체적인 문제를 지적했을 때만 포착된 것으로 간주했습니다.

저희는 Kilo Code CLI를 통해 오류가 있는 코드베이스를 GLM-5.2에 전달하고 코드를 감사 (audit)하도록 요청했습니다. 저희는 모델이 제공하는 모든 추론 노력 (reasoning effort) 단계(low, medium, high)를 세 가지 프롬프트 구성에 대해 실행했습니다:

• Casual (일상적): "방금 이 Bun + Hono + Drizzle 작업 API를 마쳤습니다. 구현이 꽤 깔끔하고 코드베이스의 나머지 부분과 일관성이 있다고 생각합니다. 한번 살펴보고 어떻게 생각하는지 알려주시겠어요?"

• Consistency-focused (일관성 중심): "이 저장소에서 실제 버그, 보안 문제, 데이터 일관성 문제 및 프로덕션 (production) 엣지 케이스 (edge cases)를 검토해 주세요. 동작이 모든 라우트 (routes)에서 일관된지 주의 깊게 살펴봐 주세요."

• Strict production (엄격한 프로덕션): "당신이 프로덕션 PR (Pull Request)을 차단하거나 승인하는 담당자라고 가정하고 이 저장소를 검토하세요."

코드는 전혀 변경되지 않았으며, 우리가 변경한 유일한 요소는 추론 노력 (reasoning effort)과 요청의 문구였습니다.

1라운드: GLM-5.2는 잘 해냈으며, 일관되게 수행했습니다

첫 번째 코드베이스에는 일반적인 카테고리에 걸쳐 16개의 의도적인 버그가 심어져 있었습니다: 검색 쿼리의 SQL 인젝션 (SQL injection), 비밀번호 해시를 반환하는 사용자 검색, 관리자 전용 내보내기 기능에서의 인증 체크 누락, 모든 사용자가 다른 사용자의 작업을 수정할 수 있게 하는 권한 부여 허점 (authorization hole), CSV 수식 인젝션 (CSV formula injection), 페이지네이션 (pagination) 오프 바이 원 (off-by-one) 오류, 그리고 몇 가지 대량 작업 (bulk-operation) 정확성 버그가 포함되었습니다.

GLM 5.2 Low Auditing First Codebase

GLM-5.2는 이를 깔끔하게 처리했습니다. 모든 실행에서 모든 심각한 보안 버그를 잡아냈으며, 최악의 실행과 최선의 실행 사이의 편차도 작았습니다.

일상적으로 요청하든 엄격하게 요청하든, 낮은 노력(low effort)이든 높은 노력(high effort)이든, 16개 중 13개에서 15개 사이를 찾아냈습니다. 직관적인 코드베이스에서 GLM-5.2는 우리가 원하는 만큼 코드를 잘 검토했으며, 프롬프트는 거의 영향을 미치지 않았습니다.

첫 번째 코드베이스에서 GLM 5.2의 낮은 감사 (Low Audit) 수준

이러한 버그들은 하나하나가 운영 환경(production)에 도달하여 실제 장애를 일으킬 수 있는 종류이며, GLM-5.2는 우리가 어떻게 질문하든 상관없이 이를 일관되게 잡아냈습니다. 우리는 모델이 어디서부터 무너지기 시작하는지 찾아내고 싶었기에, 다음 코드베이스를 상당히 더 어렵게 만들었습니다.

라운드 2: 더 미묘한 버그들이 포함된 더 어려운 코드베이스

우리는 동일한 프로젝트를 더 큰 제품으로 확장했습니다. 소프트 삭제 (soft deletion, 모든 곳에서 행을 숨기는 deletedAt 타임스탬프), 아카이브 플래그 (archive flag,

• 삭제가 실제로 이루어지지 않음. 삭제 엔드포인트(endpoint)가 작업을 아카이브(archived) 상태로 표시하기는 했으나, 앱의 나머지 부분에서 삭제된 행을 숨기기 위해 사용하는 deletedAt 타임스탬프를 설정하지 않았습니다. 그 결과 "삭제된" 작업들이 계속해서 나타났습니다.

• 낙관적 잠금 (optimistic-lock) 체크가 반대로 되어 있었음. 버전 비교 로직이 잘못 작성되어, 오래된 복사본을 편집 중인 클라이언트(stale client)가 그대로 통과되었습니다. 이는 해당 체크가 방지해야 하는 바로 그 상황입니다.

• 절대 실행될 수 없는 권한 가드 (permission guard). 일반 사용자가 완료된 작업을 다시 여는 것을 방지하려는 규칙의 조건이 항상 거짓(false)이 되어, 아무런 역할도 하지 못했습니다.

• 감사 로그 (audit log)가 잘못된 사람을 지목함. 일괄 할당 (bulk assignment) 시, 실제 작업을 수행한 사용자가 아닌 할당된 대상(assignee)을 행위자(actor)로 기록했습니다.

• 아카이브된 작업이 일반 뷰 (views)에 노출됨. 아카이브는 작업을 보이지 않게 옮기는 것이 목적임에도 불구하고, 아카이브된 작업이 기본 검색 결과, CSV 내보내기, 그리고 연체 목록 (overdue list)에 여전히 나타났습니다.

우리는 이 버그들을 발견하기 점점 더 어렵게 배치했습니다. 잘못된 잠금 체크나 실행되지 않는 권한 가드처럼 단일 함수를 주의 깊게 읽음으로써 찾을 수 있는 로컬 버그 (local bugs)도 있습니다. 하지만 나머지는 점차 더 복잡해졌습니다. 예를 들어, 마지막 버그는 여러 엔드포인트에 걸쳐 퍼져 있는 제품 규칙이며, 주의 깊은 리뷰어가 추론해야 하는 이 규칙은 설명하기는 쉽지만 찾아내기는 어렵습니다. 아카이브된 작업은 일반 뷰에서 제외되어야 하며, 삭제된 작업은 모든 곳에서 사라져야 합니다. 코드의 단 한 줄로 명시되어 있지 않기 때문에, 시스템이 고장 났다는 것을 알아차리려면 전체 시스템을 머릿속에 담고 있어야 합니다.

두 번째 코드베이스에서의 GLM 5.2 높은 감사 (High Audit)

GLM-5.2가 심어놓은 10개의 버그에 대해 어떻게 수행했는지는 다음과 같습니다.

커버리지(Coverage)가 하락했으며, 프롬프트의 문구(wording)에 따라 결과가 움직였습니다.

문구(Wording)가 추론(Reasoning)을 압도함

두 라운드 모두에서, 프롬프트의 문구가 추론 노력(reasoning effort)보다 GLM-5.2의 리뷰에 더 큰 영향을 미쳤습니다.

"이 프로덕션 PR을 차단(block)할지 승인(approve)할지 결정하라"는 엄격한 프레임워크(framing)는 최상의 버그 커버리지를 만들어내지 못했습니다. 이는 GLM-5.2를 보안 및 하드닝(hardening) 리뷰로 몰아넣었습니다. 모델은 하드코딩된 폴백 비밀값(hardcoded fallback secret), 취약한 비밀번호 해싱(weak password hashing), 누락된 속도 제한(missing rate limiting), 그리고 누락된 트랜잭션(missing transactions)을 찾아냈습니다. 이것들은 수정할 가치가 있는 실제 버그들이지만, 우리가 의도적으로 심어놓은 제품 버그는 아니었습니다. 이러한 버그들을 쫓느라 우리가 실제로 망가뜨려 놓은 동작으로부터 주의가 분산되었습니다. 반면, 캐주얼하고 일관성에 초점을 맞춘 프레임워크는 심어놓은 버그 세트에 대해 조금 더 나은 점수를 기록했는데, 이는 모델이 보안 체크리스트를 수행하는 대신 코드가 어떻게 동작하는지에 집중하도록 유지했기 때문입니다.

이러한 추가적인 발견 사항들은 노이즈(noise)가 아니었습니다. 모델이 지적한 하드코딩된 비밀값, 낮은 bcrypt 비용, 누락된 트랜잭션, 그리고 등록 레이스 컨디션(registration race)은 모두 우리가 수정하기를 원하는 정당한 문제들이었습니다. GLM-5.2가 심어놓은 버그를 놓친 실행에서도, 리뷰는 우리가 채점하려던 것 이외의 실제 문제들을 여전히 찾아냈습니다.

이와 대조적으로, 추론 노력(reasoning effort)은 훨씬 적은 차이를 만들었습니다. 높은 추론(High reasoning)은 때로는 약간 더 나았고, 때로는 약간 더 나빴습니다. 프롬프트 문구에 따른 변동 폭은 추론 노력에 따른 변동 폭보다 일관되게 더 컸습니다. 이는 코드 리뷰 전반에서 GLM-5.2를 통해 확인한 결과와 일치합니다. 요청의 프레임워크(framing)가 모델에게 얼마나 오래 생각하게 하느냐보다 리뷰의 형태를 더 크게 결정합니다.

무엇을 찾아냈고 무엇을 놓쳤는가

이 차이는 실행 전반에 걸쳐 명확하고 반복 가능했습니다.

안정적으로 찾아냄 (함수 하나를 읽음으로써 식별 가능한 로컬 버그):

• 소프트 삭제 (soft-deleting) 대신 아카이브를 수행하는 삭제

• 역방향 버전 체크 (backwards version check)

• 절대 실행될 수 없는 권한 가드 (permission guard)

• 감사 로그 (audit log) 내 잘못된 액터 (actor)

• 일괄 아카이브 (bulk archive) 시 일관되지 않은 감사 작업 (audit action) 명명

놓친 부분 (시스템 전체를 이해해야만 포착할 수 있는 교차 경로 규칙):

• 기본 검색 결과에 나타나는 아카이브된 작업들

• 내보내기 (exports) 결과에 나타나는 아카이브된 작업들

• 미결제 목록 (overdue list)에 나타나는 아카이브된 작업들

GLM-5.2는 로컬 버그 (local bugs)에는 강하지만, 여러 엔드포인트 (endpoints)에 걸쳐 존재하는 제품 규칙 (product rules)에는 훨씬 취약하며, 이는 우리가 이를 실행하며 얻은 나머지 경험과 일치합니다.

이 모델은 필요한 모든 정보가 한곳에 모여 있을 때 최선의 성능을 발휘합니다. 실수와 수정 사항이 몇 줄 차이로 인접해 있는 단일 함수 내부의 버그는 모델의 강점을 활용하는 사례입니다. 문제는 관련 컨텍스트 (context)가 퍼져 나갈 때 시작됩니다. 버그를 잡기 위해 여러 파일이 어떻게 동작하는지 종합하고 이를 동시에 추론해야 할 때, GLM-5.2는 신뢰도가 떨어지며, 이는 OpenAI나 Anthropic 같은 연구소의 모델들이 안정성을 유지하는 지점과 동일합니다. GLM-5.2를 통해 얻는 경험은 당신의 코드가 모델에게 얼마나 많은 점 연결 (dot-connecting) 작업을 강요하느냐에 크게 좌우됩니다. 밀접하고 자기 완결적인 (self-contained) 변경 사항에 대해서는 최고 수준의 모델들과 대등하게 버팁니다. 하지만 정확성이 시스템 전반에 걸쳐 분산되어 있는 변경 사항에 대해서는 품질이 흔들리기 시작합니다.

프런티어 모델 (Frontier Models) 비교

우리는 일관성에 초점을 맞춘 프롬프트 (prompt)를 사용하여, 동일한 더 어려운 코드베이스를 GPT-5.5와 Opus 4.8에 각각 한 번씩 통과시켜 테스트했습니다.