2026년 6월 22일, Hacker News 첫 페이지에 동시에 세 개의 글이 올라왔다. 각각 다른 사용자, 다른 제품을 가리켰지만, 마치 퍼즐 조각처럼 맞물려 있었다.
첫 번째, Codex의 SQLite 로그가 백그라운드에서 연간 640TB 속도로 로컬 SSD에 데이터를 쓰고 있었고, 실제로 유지된 유효 데이터는 0.5M 행에 불과했다 — AUTOINCREMENT 카운터는 이미 55억을 돌파했다. 10,000배의 쓰기 증폭이었다. 1TB 소비자용 SSD의 정격 쓰기 수명은 600TBW인데, Codex는 10개월 안에 그것을 소진할 수 있었다. 수정 PR은 당일 병합되었고, 로그 양이 85% 감소했다고 주장했다. 두 번째, Patrick McCanna는 Claude Code의 “Extended Thinking” 출력이 사후에 생성된 요약지, 모델의 실제 추론 과정이 아님을 발견했다. 실제 추론은 600자의 서명 블록으로 암호화되어 있었고, 키는 Anthropic이 쥐고 있었으며, 사용자는 로컬에서 원문을 얻을 수 없었다. Patrick은 이 변환을 “JPEG를 BMP로 저장한 후 BMP를 편집하고 JPEG라고 주장하는 것 — 데이터 손실은 변환 과정에서 발생한다”고 비유했다. 세 번째, Tech Stackups는 GLM-5.2와 Claude Opus 4.8의 비교 테스트를 발표했다. 동일한 one-shot 프롬프트로 WebGL 3D 플랫폼 게임을 처음부터 구축했다. GLM-5.2는 1시간 10분, 5.39달러가 걸렸다. Opus 4.8은 33분, 약 21.92달러가 들었다. 최종 결론은 “우리는 주력을 Opus에서 옮기지 않을 것”이었지만, GLM-5.2는 MIT 오픈소스 가중치로 “빼앗을 수 없는 사용 가능성”을 얻었다.
세 글은 각각 456점, 253점, 474점을 받았다. 점수 자체는 큰 의미가 없다 — HN의 투표는 결코 진리의 측정기가 아니다. 하지만 같은 날의 공명은 같은 문제를 가리켰다: 개발자는 더 이상 “어느 모델이 더 강한가”만 묻지 않는다. 그들은 “어느 도구를 신뢰할 수 있는가”라고 묻기 시작했다.
이러한 전환은 데이터로 뒷받침된다. Stack Overflow 2025년 개발자 설문조사에 따르면, 84%의 개발자가 AI 코딩 도구를 사용하거나 계획 중이지만, 오직 29%만이 그 출력을 신뢰한다 — 1년 전 40%에서 11%p 하락한 수치다. Veracode의 평가는 AI 생성 코드의 45%가 보안 테스트를 통과하지 못함을 발견했다. Sonar의 조사는 더 위험한 균열을 드러냈다: 개발자의 96%가 AI 생성 코드의 기능적 정확성을 완전히 신뢰하지 않지만, 오직 48%만이 항상 커밋 전에 검사한다고 응답했다. METR의 무작위 대조 실험에 따르면, AI 도구를 사용하는 개발자는 실제로 AI를 사용하지 않는 동료보다 19% 더 느렸지만, 스스로는 20% 더 빠르다고 생각했다. 필자에게 이것은 신뢰 메커니즘의 공학적 문제다 — 도구의 출력을 검증할 수 없을 때, 생산성 이득은 검증 비용에 잠식된다.
다시 세 편의 글로 돌아가면, 각각은 신뢰의 다른 차원을 찔렀다.
Codex의 로그 버그는 신뢰성을 찔렀다. 55억 행의 로그를 기록하면서 50만 행만 유지한 시스템은 악의가 아니라 태만이다. 하지만 이 태만의 신호는 강력하다: 로컬 로그라는 인프라 수준의 코드가 이 정도 규모의 결함을 6개월 동안 방치했다면 — 그 사이에 Mac GPU를 100% 사용하는 spinner 버그도 수정되지 않은 채 방치됐었다면 — 이 도구가 생성한 비즈니스 코드에 개발자가 같은 규모의 낭비가 숨겨져 있지 않다고 믿을 근거가 무엇인가? 한 HN 사용자는 강한 표현을 썼다: “slopware”. 거친 표현이지만, 커뮤니티 감정의 핵심을 정확히 찔렀다 — Codex의 출력물 자체가 쓰레기라는 비판이 아니라, 그 엔지니어링 규율이 쓰레기 같다는 비판이다. 이 두 판단 사이에는 거리가 있지만, 그 거리는 줄어들고 있다.
Claude Code의 생각 요약은 투명성을 찔렀다. Anthropic의 기술적 이유는 이해할 수 있다 — 추론 체인을 숨기면 경쟁사가 모델을 증류하는 것을 막고, 사용자가 추론 내용으로 보안 공격을 하는 것도 방지할 수 있다. 하지만 이해는 별개로, Patrick의 발견은 현실적인 문제를 던졌다: AI Agent의 행동을 감사할 때, 당신은 실제 생각을 보는가, 아니면 미화된 요약을 보는가? 이것은 단순한 철학적 문제가 아니다. AI Agent가 앞으로 데이터베이스를 조작하고, API 요청을 보내고, 파일 시스템을 수정한다면, 그 의사결정 과정은 감사 가능해야 한다 — “볼 수 있음”만으로는 부족하고 “정확함”이 필요하다. HN의 한 사용자는 단호하게 말했다: “나는 추론을 숨기는 모델을 사용하거나 추천하지 않을 것이다.” 다소 절대적인 표현이지만, 합리적인 공학적 직관을 반영한다: 시스템의 내부 상태를 관찰할 수 없다면, 그 시스템에 대한 신뢰 모델을 구축할 수 없다.
GLM-5.2의 벤치마크 논란은 평가 방법 자체의 정직성을 찔렀다. Tech Stackups의 비교 테스트는 성실하게 이루어졌다 — 같은 프롬프트, 같은 작업, 소스 코드 공개, 게임 플레이 가능. 하지만 HN 커뮤니티의 비판은 테스트 실행이 아니라 테스트 설계를 향했다. 한 높은 추천을 받은 댓글은 술 취한 사람이 가로등 밑에서 열쇠를 찾는 우스개를 들려줬다: 경찰이 뭐 하는지 묻자 열쇠를 찾는다고 대답하고, 경찰이 여기서 잃어버렸냐고 묻자 “아니요, 하지만 여긴 불이 켜져 있어서요”라고 대답했다는 것이다. One-shot 벤치마크가 바로 그 가로등이다 — 측정하기 쉽고, 재현하기 쉽고, 차트로 만들기 쉽지만, 실제 소프트웨어 엔지니어링 워크플로우를 반영하지 않는다. 실제 프로그래밍은 여러 번의 반복, 기존 코드 이해, 버그 수정, 아키텍처 리팩토링을 수반하며, 하나의 프롬프트로 전체 애플리케이션을 생성하는 것이 아니다. 테스트 방법이 AI 코딩 능력의 5%만 커버한다면, 나머지 95%는 무엇인가? 우리는 모른다. 이 ‘모름’이 핵심이다.
세 가지 일은 같은 결론을 가리킨다: AI 코딩 도구의 능력 차원은 과도하게 개발되었고, 신뢰 차원은 심각하게 적자가 났다.
이것은 “AI 코딩 도구가 쓸모없다”는 말이 아니다. 그것들은 유용하다. 84%의 개발자가 사용하는 데는 이유가 있다. 하지만 “유용함”과 “신뢰할 수 있음”은 독립적인 변수다. 도구는 유용하면서도 동시에 신뢰할 수 없을 수 있다 — 이것이 바로 현재의 상황이다. 그리고 이 조합은 “쓸모없으면서 신뢰할 수 없는” 것보다 다루기 더 어렵다. 단기 효율성을 위해 장기적인 검증 부채를 쌓도록 유혹하기 때문이다. Werner Vogels는 이것을 “verification debt”라고 부른다. 이자는 복리로 붙는다 — 검증되지 않은 AI 출력이 하류 코드에서 참조되고, 복사되고, 의존되면서 오류가 의존성 체인을 따라 단계적으로 증폭된다.
GLM-5.2는 가장 적은 비판을 받았다. 테스트 결과는 Opus보다 떨어진다는 것을 분명히 보여줬지만, 커뮤니티의 감정은 성능이 아니라 오픈소스 가중치 자체를 향했다. 오픈소스가 자동으로 신뢰할 수 있음을 의미하지는 않지만, 폐쇄형 모델이 제공할 수 없는 한 가지를 제공한다: 적어도 이해하려고 시도할 수 있다. Codex는 폐쇄형이라 spinner 버그를 고칠 수 없다. Claude Code의 추론은 암호화되어 있어 어떻게 생각하는지조차 볼 수 없다. GLM-5.2는 적어도 가중치를 공개해 놓았다. 대부분의 사람이 보지 않더라도, “볼 수 있다”는 선택지 자체가 신뢰 인프라의 일부다.
필자는 이것이 “AI 코딩의 겨울이 온다”는 의미라고 생각하지 않는다. 신뢰 위기는 신뢰의 죽음이 아니다. 그것은 신뢰의 재평가다 — 개발자들이 “빠르지만 부정확한” 것에 대해 얼마의 비용을 지불할 의향이 있는지 다시 계산하고 있다. 이 재평가 과정은 벤치마크 순위표의 변동보다 더 주목할 만하다. 28일 전, CVE-2026-35603이 공개되었다 — AI 코딩 도구의 권한 상승 취약점이었다. 16일 전, Cymulate가 상세 분석을 발표했다. 오늘, HN의 세 글이 한 페이지에 모였다. 이것들은 고립된 사건이 아니라, 같은 신호의 연속적인 펄스다.
이 관찰은 2026년 6월 22일의 공개 정보에 기반한다. 필자는 이 도구들을 장기간 실전에서 사용한 데이터를 가지고 있지 않으며, 그 방향을 예측할 수 있다고 주장하지도 않는다. 엔지니어링 신뢰는 누적 변수다 — 내일의 발견이 오늘의 판단을 강화할 수도, 뒤집을 수도 있다. 유일하게 확실한 것은, 개발자가 더 이상 SOTA 점수를 쫓지 않고 “이게 정말 믿을 수 있는 건가”를 쫓기 시작했을 때, 게임의 규칙이 이미 바뀌었다는 것이다.