AI가 코드를 잘 짠다는 말, 어디까지 믿어야 하나
AI 코딩 에이전트가 실제로 얼마나 잘 동작하는지를 실전 PR 기반으로 측정한 벤치마크가 공개됐다. octomind이 공개한 octobench는 기존 벤치마크의 두 가지 고질적 문제—훈련 데이터 오염과 '정답 흉내'를 측정하는 채점 방식—를 걷어낸 뒤, 2026년에 실제로 머지된 PR 25개를 5개 언어에서 추려 에이전트에게 풀게 했다. 채점은 각 오픈소스 프로젝트의 실제 테스트 스위트가 한다. 신선도와 공정성 모두를 잡으려 한 설계다.
결과는 흥미롭다. octomind(glm-5.2) 24/25, Claude Code(Opus) 23/25, Codex(gpt-5.5) 21/25, opencode(glm-5.2) 19/25. 숫자 자체보다 더 중요한 맥락이 있다.
벤치마크가 실제로 말하는 것
같은 모델(glm-5.2)을 쓴 octomind와 opencode의 점수 차이가 24 대 19다. 모델이 아니라 하네스(harness), 즉 에이전트 실행 프레임워크가 결과를 가른다. octomind는 컨텍스트 토큰을 8M 쓸 때 opencode는 30M을 썼고, opencode가 틀린 케이스들은 정확히 '루트 원인까지 파고들어야 하는' 문제들이었다. 에이전트가 중간에 '해결했다'고 선언하고 멈춘 것이다.
속도도 비슷한 함정을 드러낸다. Codex는 케이스당 2~4분, 비용도 최저지만 실패한 4건은 모두 '한 곳 더 확인해야 했던' 문제들이다. 빠른 에이전트는 철저함에 세금을 낸다. 팀이 AI 코딩 도구를 선택할 때 '어떤 모델을 쓰냐'보다 '어떤 하네스 위에서 어떻게 작동하냐'를 먼저 봐야 하는 이유다.
코드가 '통과'해도 '안전'하지 않을 수 있다
벤치마크가 기능적 정확성을 측정하는 동안, 보안 연구자들은 다른 질문을 던지고 있었다. dev.to에 공개된 WordPress 플러그인 대상 AI 코드 생성 연구는 AI가 만들어내는 코드의 컨텍스트 무감각을 파고든다.
핵심은 단순하다. esc_html($url)은 이스케이핑 함수다. grep으로 찾히고, 리뷰도 통과한다. 하지만 $url이 javascript:alert(document.cookie)이면 XSS가 발생한다. URL 컨텍스트에는 esc_url()이 필요하다. '이스케이핑을 했느냐'가 아니라 '어느 컨텍스트에 맞는 이스케이핑을 했느냐'가 보안을 가른다.
JavaScript 인라인 삽입은 더 복잡하다. wp_json_encode()의 기본값은 슬래시를 이스케이프해 </script> 브레이크아웃을 막는다—하지만 개발자가 URL 가독성을 위해 JSON_UNESCAPED_SLASHES 플래그를 추가하는 순간, 그 보호가 조용히 사라진다. 안전한 코드가 의도가 아닌 부작용으로 안전했던 것이고, 플래그 하나로 취약점이 복귀한다. 연구에서 Claude Code, Codex CLI, Gemini CLI 세 어시스턴트를 테스트한 결과, 이 '우연한 안전'과 '의도된 안전'을 구분하는 어시스턴트는 소수였다.
'첫 작동'과 '프로덕션 준비' 사이의 거리
geekNews에 소개된 관점은 이 두 데이터를 꿰는 프레임을 제공한다. AI는 프로토타입을 빠르게 만든다. 하지만 프로토타입에서 프로덕션까지의 거리를 줄여주지는 않는다.
실제 엔지니어링의 어려움—확장성, 오류 처리, 관측 가능성, 보안, 인증, 데이터 아키텍처—은 애초에 문법 작성의 문제가 아니었다. AI가 문법 작성을 대신해줘도 이 문제들은 그대로 남는다. 5천만 행 테이블에서 풀 스캔을 일으키는 쿼리, 동시 부하에서 경쟁 조건을 만드는 캐시 전략, 현재 요구사항은 해결하지만 다음 문제를 훨씬 어렵게 만드는 아키텍처—이것들은 AI가 생성한 코드 안에 조용히 숨어 있다가 프로덕션에서 터진다.
문제를 알아볼 지식이 없으면, 진단에 며칠이 걸린다.
팀이 설계해야 할 신뢰의 기준
세 가지 소스를 놓고 보면 하나의 패턴이 보인다. AI 생성 코드를 신뢰하는 것은 기술적 판단이 아니라 팀 설계의 문제다.
벤치마크는 에이전트가 기능적으로 상당히 잘 작동한다는 것을 보여주지만, 동시에 '하네스 설계'와 '감독 구조'가 결과를 좌우한다는 것도 드러낸다. 보안 연구는 기능 테스트를 통과한 코드가 컨텍스트 인식 없이는 여전히 취약할 수 있다는 것을 보여준다. 프로토타입-프로덕션 격차 논의는 그 검증 책임이 결국 엔지니어의 판단력에 있다는 것을 확인시킨다.
실용적으로 풀면 세 개의 검증 레이어가 필요하다.
첫째, 기능 정확성 레이어. AI가 요구사항을 기능적으로 구현했는지는 자동화 테스트로 검증 가능하다. octobench처럼 실제 프로젝트의 테스트 스위트를 기준으로 삼는 것이 가장 신뢰도가 높다.
둘째, 컨텍스트 보안 레이어. 기능이 통과해도 보안은 별도로 검토해야 한다. 특히 출력 이스케이핑, 인증, API 키 노출처럼 컨텍스트 판단이 필요한 영역은 자동화 린터만으로는 부족하다. 팀 내에 이 기준을 명시적으로 정의해두지 않으면 리뷰어마다 판단이 달라진다.
셋째, 아키텍처 판단 레이어. 확장성, 데이터 모델, 오류 처리 전략은 코드 수준 리뷰로는 잡기 어렵다. AI가 생성한 코드를 '주니어 개발자의 PR'처럼 아키텍처 맥락에서 리뷰하는 습관이 필요하다.
전망: AI를 증폭기로 쓰는 팀이 이긴다
AI 코딩 도구의 성능은 빠르게 올라가고 있다. 24/25를 맞히는 에이전트가 나왔고, 내년에는 25/25가 나올 것이다. 하지만 그게 팀의 검증 책임을 없애주지는 않는다. 오히려 반대다—AI가 빠르게 코드를 쏟아낼수록, 그 코드가 '기능적으로 옳음'을 넘어 '프로덕션에서 신뢰할 수 있음'을 판단하는 역량이 팀의 차별점이 된다.
뒤처질 팀은 AI 도구를 안 쓰는 팀이 아니다. AI가 만든 코드를 이해 없이 통과시키는 팀이다. 신뢰의 기준을 설계하지 않은 팀은 속도를 얻는 대신 품질과 보안을 운에 맡기게 된다. AI는 도구이자 동료지만, 그 동료의 결과물을 검증하는 프로세스를 설계하는 것은 여전히, 그리고 앞으로도 팀의 몫이다.