빠른 결론

• 안정적인 장기 코딩 작업은 Claude Code 계열이 강한 편이다.
• OpenAI 생태계와 코드 리뷰·에이전트 통합을 중시한다면 Codex가 자연스럽다.
• 터미널 중심, 오픈소스 CLI, 무료 사용량, Google Search grounding을 중시한다면 Antigravity CLI가 현재 기준에 더 맞다.
• 오픈 모델, 자체 호스팅 가능성, 긴 컨텍스트·코딩 벤치마크를 보고 싶다면 GLM-5.2 계열을 검토할 만하다.
• 하지만 어느 하나가 항상 정답은 아니다. 과제 유형, 도구 권한, 테스트 환경, 비용 구조에 따라 결과가 바뀐다.

실제 가격부터 확인하자: 플랜별 차이

AI 코딩 에이전트 선택 기준에서 가격은 부가 정보가 아니라 핵심 정보다. 같은 “월 구독”이라도 포함되는 사용량, 코딩 도구 지원 범위, MCP 제공량, API 토큰 과금 여부가 다르다. 그래서 단순히 “월 100달러부터”처럼 적으면 부족하다. 아래 표는 공식 가격·구독 페이지를 직접 확인해 정리한 플랜별 차이다.

용어 정리: GLM-5.2 자체는 코딩 에이전트가 아니라 모델이다. 따라서 이 글에서 비교 대상으로 다루는 것은 GLM-5.2 모델 자체가 아니라, GLM-5.2·GLM-5-Turbo·GLM-4.7을 Claude Code, Cline, OpenCode 같은 코딩 도구에서 쓰게 해주는 Z.ai GLM Coding Plan이다. API 토큰 가격은 별도 항목으로 분리해 본다.

구독·가격 공식 페이지 링크

• Claude / Claude Code 가격 페이지 — Free, Pro, Max 5x, Max 20x 플랜을 확인할 수 있다.
• OpenAI Codex 가격 페이지 — Free, Go, Plus, Pro, Business/Enterprise 및 API Key 과금 안내를 확인할 수 있다.
• Google Code Assist / Antigravity 전환 안내 페이지 — 기존 Gemini CLI 개인 무료 티어가 Antigravity CLI로 전환되는 공지를 확인할 수 있다.
• Z.ai GLM Coding Plan 구독 페이지 — Lite, Pro, Max 월간·연간 구독 가격과 사용량 차이를 확인할 수 있다.
• Z.ai 모델/API 가격 페이지 — GLM-5.2 등 모델별 input, cached input, output 토큰 단가를 확인할 수 있다.

비교 대상 4가지

선택 기준 1. 도구 호출 안정성

AI 코딩 에이전트는 채팅 모델이 아니다. 실제로는 파일 읽기, 검색, 패치, 테스트 실행, 브라우저 확인, Git 작업을 반복하는 도구 실행 시스템이다. 따라서 모델이 똑똑해 보여도 tool call이 불안정하면 실무 생산성은 떨어진다.

확인해야 할 것은 단순하다. 파일을 잘못 덮어쓰지 않는가, 실패한 명령을 보고 원인을 좁히는가, 권한이 필요한 작업에서 멈추고 설명하는가, 장시간 작업 중 세션이 끊기지 않는가다. 특히 GLM-5.2 같은 오픈 모델을 외부 CLI에 붙여 쓸 때는 모델 능력과 클라이언트 안정성을 분리해서 봐야 한다.

선택 기준 2. 컨텍스트 관리 능력

큰 코드베이스에서 중요한 것은 많은 토큰을 넣는 능력보다 “필요한 파일을 고르고, 바뀐 요구사항을 잊지 않고, 이전 실패를 반복하지 않는 능력”이다. 긴 컨텍스트 모델이라도 근거 파일을 제대로 압축하지 못하면 결과는 흔들린다.

문서 기반 과제에서는 이 차이가 더 선명하다. 정책 문서, acceptance test, 기존 코드 스타일, 배포 규칙을 동시에 읽어야 하기 때문이다. Claude Code는 이런 장기 작업에서 강한 인상을 주는 경우가 많고, GLM 계열은 긴 컨텍스트와 코딩 벤치마크를 내세우지만 실제 에이전트 루프에서 별도 검증이 필요하다.

선택 기준 3. 수정 전략과 diff 품질

좋은 에이전트는 한 번에 거대한 코드를 밀어 넣지 않는다. 작은 단위로 변경하고, 기존 구조를 보존하고, 컨트롤러나 CLI 같은 인터페이스 계층에 비즈니스 로직을 밀어 넣지 않는다. diff가 작고 리뷰 가능해야 한다.

이 기준에서는 “코드가 돌아간다”보다 “나중에 사람이 유지보수할 수 있다”가 중요하다. 테스트는 통과했지만 도메인 로직이 CLI에 섞였거나, 기존 파일을 필요 이상으로 갈아엎었다면 실무 점수는 낮다.

선택 기준 4. 테스트 실패 복구력

AI 코딩 에이전트의 진짜 실력은 첫 코드가 아니라 실패 후에 드러난다. 좋은 에이전트는 테스트 실패를 그대로 읽고, 실패한 assertion과 관련 파일을 좁히고, 원인을 가정한 뒤 최소 수정으로 다시 검증한다.

반대로 나쁜 패턴은 테스트를 느슨하게 바꾸거나, 실패 원인을 보지 않고 코드를 대량 재작성하거나, “통과했다”고 말하면서 실제 명령을 돌리지 않는 것이다. 코딩 에이전트를 평가할 때는 반드시 독립적인 스모크 테스트를 붙여야 한다.

선택 기준 5. 최종 보고서와 리뷰 가능성

실무에서는 결과 코드만큼 최종 보고서도 중요하다. 어떤 파일을 바꿨는지, 어떤 명령을 돌렸는지, 어떤 테스트가 통과했는지, 남은 리스크가 무엇인지가 명확해야 한다. 이 정보가 없으면 사람 리뷰어는 다시 처음부터 확인해야 한다.

좋은 보고서는 “완료했다”가 아니라 “무엇을 근거로 완료라고 판단했는지”를 보여준다. 예를 들어 npm run build, npm test, 별도 CLI smoke test, public URL 확인 같은 실제 명령 결과가 포함되어야 한다.

선택 기준 6. 생태계와 보안

MCP, 브라우저, 쉘, 클라우드 API를 붙이면 에이전트의 능력은 커진다. 동시에 위험도 커진다. 로컬 파일, GitHub 토큰, 클라우드 권한, 브라우저 세션이 에이전트 도구에 노출될 수 있기 때문이다.

따라서 “도구가 많다”는 장점이면서 리스크다. MCP 서버는 필요한 것만 연결하고, 쓰기 권한은 최소화하고, 결제·배포·삭제 같은 파괴적 작업은 사람이 확인하는 방식이 안전하다. 회사 코드에서는 오픈 모델 자체 호스팅 여부보다 권한 설계가 더 중요할 수 있다.

선택 기준 7. 비용, 속도, 반복 가능성

한 번 멋진 결과를 내는 것보다 매일 반복해서 쓸 수 있는지가 중요하다. 에이전트가 너무 비싸거나, 너무 느리거나, 자주 끊기면 팀의 기본 도구가 되기 어렵다. 반대로 약간 덜 똑똑해도 빠르고 저렴하며 안정적인 도구가 작은 작업에서는 더 유용할 수 있다.

Antigravity CLI처럼 Google 개인 무료 티어 흐름을 이어받는 도구는 조사·작은 수정·개인 자동화에 강점이 있다. Claude Code나 Codex는 더 복잡한 작업 루프에서 강점을 보일 수 있다. GLM 계열은 자체 배포와 비용 통제 가능성이 매력적이지만, 실제 운영 비용과 안정성은 별도 실험이 필요하다.

상황별 추천

평가 체크리스트

1. 같은 저장소를 복사해 모델별 독립 워크스페이스를 만든다.
2. 같은 프롬프트와 같은 문서 세트를 제공한다.
3. 빌드, 테스트, lint 명령을 명확히 지정한다.
4. 에이전트가 만든 자기 테스트와 별도 외부 스모크 테스트를 분리한다.
5. 완료 시간, 중단 여부, 토큰/비용, 테스트 수, 최종 결함을 따로 기록한다.
6. 최종 점수는 실행 안정성과 코드 품질을 분리해서 매긴다.
7. 한 번의 결과로 모델 전체 우열을 단정하지 않는다.

결론

가격까지 포함하면 선택 기준은 더 현실적이다. AI 코딩 에이전트 선택의 핵심은 “어떤 모델이 가장 똑똑한가”가 아니다. 내 코드베이스에서 안전하게 도구를 쓰고, 실패를 복구하고, 테스트로 검증하고, 리뷰 가능한 diff를 남기는가다.

Claude Code, Codex, Antigravity CLI, GLM-5.2는 서로 다른 강점을 가진다. 따라서 실무에서는 하나를 절대 정답으로 고르기보다, 작업 유형별로 기본 도구와 보조 도구를 나누는 편이 현실적이다. 장기 구현은 안정적인 에이전트에 맡기고, 조사·작은 수정·오픈 모델 실험은 더 가볍고 저렴한 도구로 분리하는 식이다.

관련 글로는 GLM-5.2 vs Opus 4.8 코딩대결, GLM-5.2 총정리, AI 코딩 에이전트 비교 2026을 함께 보면 좋다.

공식 참고 자료

• Claude Code 공식 문서
• OpenAI Codex 개발자 페이지
• Google Code Assist / Antigravity 전환 안내
• Z.ai GLM GitHub
• Model Context Protocol 공식 문서

FAQ

AI 코딩 에이전트는 벤치마크 1등 모델을 고르면 되나?

아니다. 벤치마크는 참고 지표지만 실제 코딩 에이전트 품질은 도구 호출 안정성, 컨텍스트 관리, 테스트 실패 복구력, diff 품질, 비용과 속도에 따라 달라진다.

Claude Code, Codex, Antigravity CLI, GLM-5.2 중 하나만 추천한다면?

하나로 단정하기 어렵다. 안정적인 장기 작업은 Claude Code, OpenAI 생태계와 코드 리뷰 흐름은 Codex, 터미널 중심 Google 무료 티어 흐름은 Antigravity CLI, 오픈 모델·자체 호스팅 가능성은 GLM 계열이 강점이다.

AI 코딩 에이전트를 평가할 때 가장 중요한 기준은 무엇인가?

실무에서는 테스트 실패를 스스로 재현하고 고치는 능력, 작은 단위로 안전하게 수정하는 diff 품질, 최종 변경 사항을 사람이 리뷰하기 쉽게 설명하는 능력이 특히 중요하다.

The post AI 코딩 에이전트 선택 기준 7가지 appeared first on .

AI 코딩 에이전트를 비교할 때는 “어느 모델이 똑똑한가”보다 “주어진 개발 작업을 끝까지 얼마나 효율적으로 완수하는가”를 봐야 한다. GitHub가 공개한 Copilot agentic harness 평가는 모델별 성능뿐 아니라 작업 유형, 비용, 효율까지 함께 보려는 흐름을 잘 보여준다.

Agentic Harness란 무엇인가?

일반 LLM 벤치마크는 문제를 넣고 답을 맞혔는지 보는 방식이 많다. 하지만 코딩 에이전트는 다르다. 파일을 읽고, 수정하고, 테스트를 실행하고, 실패하면 다시 고치는 과정을 반복한다. 따라서 평가는 모델 하나의 지식이 아니라 에이전트 루프 전체의 결과를 봐야 한다.

왜 기존 LLM 벤치마크만으로 부족한가

직접 실험 준비: GLM과 Claude를 같은 조건으로 세팅

이번 글은 단순히 GitHub의 agentic harness 글을 요약하는 데서 멈추지 않고, 실제로 같은 작업을 두 모델에 맡겨 비교하는 실험으로 이어갈 예정이다. 실험은 ~/agent-test/glm과 ~/agent-test/claude 두 작업 공간을 분리하고, 공통 기획 문서는 ~/agent-test/doc에 둔 뒤 동일한 /goal 프롬프트를 넣는 방식으로 설계했다.

다만 GLM-5.2가 1M 컨텍스트를 잘 활용해 정책 문서를 빠짐없이 반영하고 npm run build, npm test까지 깔끔하게 통과시킨다면 결과는 충분히 접전이 될 수 있다. 어느 쪽이 이기든 이 실험의 핵심은 “벤치마크 숫자”가 아니라 “동일 조건에서 나온 실제 산출물”이다.

동일하게 투입한 goal 문서 세트: 11개, 총 627줄

이번 비교는 단순한 한 줄 프롬프트가 아니라, 두 모델에 같은 goal과 같은 정책 문서 세트를 제공한 상태에서 진행했다. 입력 문서의 총량은 11개 Markdown 파일, 총 627줄이다. 따라서 “작은 샘플 코드 생성”이 아니라, 여러 정책 문서를 읽고 요구사항을 구현·검증하는 에이전트 과제에 가깝다.

특히 07-acceptance-tests.md의 8개 시나리오와 04-api-cli-policy.md의 thin interface 규칙, 05-lint-policy.md의 lint rule이 최종 코드 품질을 가르는 핵심 기준이었다. 이후 채점에서는 두 모델이 이 문서 세트를 얼마나 잘 해석했는지, 그리고 실제 빌드·테스트·스모크 테스트에서 그 해석이 맞았는지를 함께 봤다.

초반 관찰: 둘 다 먼저 문서를 읽고 작업 공간을 확인했다

흥미롭게도 시작 단계에서는 두 모델의 행동이 꽤 비슷했다. 왼쪽 Claude Opus 4.8은 문서 목록을 확인한 뒤 기획 문서들을 병렬로 읽는 흐름을 보였고, 오른쪽 GLM-5.2는 기획 문서를 먼저 읽은 뒤 남은 정책 문서를 이어서 확인하는 흐름을 보였다. 이후 두 세션 모두 기존 작업 공간 파일을 확인하고 Node/npm 환경을 점검하는 흐름으로 넘어갔다.

초반만 보면 둘 다 “먼저 요구사항을 충분히 읽고, 그 다음 현재 프로젝트 상태를 확인한다”는 안정적인 코딩 에이전트 패턴을 따랐다. 진짜 차이는 이후 설계 선택, 테스트 범위, 에러 복구, 최종 npm test 결과에서 드러날 가능성이 크다.

13분 시점: Claude는 build pass, GLM은 아직 코드 수정 전

초반 13분만 놓고 보면 속도 차이는 꽤 크게 벌어졌다. 왼쪽 Claude Opus 4.8은 의존성을 설치하고 npm run build를 통과한 뒤, 직접 스모크 테스트를 돌리면서 entity extraction 버그를 발견하고 src/domain/markdown.ts를 수정하는 단계까지 진행했다.

반면 오른쪽 GLM-5.2는 같은 시점에 아직 기획 문서와 작업 공간을 확인하는 단계에 머물러 있었고, 코드 수정은 시작하지 못한 상태였다. 이 장면만 보면 내가 사전에 예상했던 “Claude는 최종 완성도와 마무리에서 우세, GLM은 초기 구현 속도에서 선전할 수 있다”는 가설 중 초기 속도 부분은 오히려 Claude 쪽으로 기울었다.

다만 최종 평가는 결국 완성도의 문제이므로, GLM이 늦게 시작하더라도 요구사항을 더 넓게 반영하거나 테스트를 더 충실히 만들 가능성은 남아 있다. 따라서 이 시점의 관찰은 “초기 실행 속도와 첫 build pass까지의 시간”에 대한 중간 기록으로 보는 것이 맞다.

18분 시점: GLM도 드디어 스캐폴딩을 시작했다

18분이 지나자 오른쪽 GLM-5.2도 드디어 구현 단계에 들어갔다. 화면상 GLM은 “Project scaffolding(package.json, tsconfig, gitignore)”를 1번 작업으로 표시하고, domain modules, io/fs helpers, services, thin CLI, library exports를 순서대로 만들 계획을 세웠다. 이 시점의 토큰 사용량은 약 45.0k였다.

반면 왼쪽 Claude Opus 4.8은 같은 시점에 이미 dist/와 node_modules/를 지운 뒤 fresh-clone 재현성 검사를 수행하고, --tags와 paper 타입까지 포함한 최종 end-to-end CLI smoke test를 실행하는 단계였다. 화면상 토큰 사용량은 약 88.2k였다.

이 장면은 두 모델의 차이를 꽤 선명하게 보여준다. GLM은 늦게 움직이기 시작했지만 설계 항목 자체는 요구사항과 잘 맞아 보이고, Claude는 훨씬 빠르게 구현·빌드·재현성 검증 루프까지 도달했다. 이제 남은 관전 포인트는 GLM이 늦은 출발을 구현 품질과 요구사항 커버리지로 만회할 수 있는지이다.

20분 30초: Claude Opus 4.8은 Goal achieved

20분 30초에 Claude Opus 4.8은 Goal achieved 상태에 도달했다. 최종 리포트에는 “All 48 tests pass and the build is clean”이라고 표시됐고, npm install, npm run build, npm test를 실행해 TypeScript 빌드와 Vitest 48개 테스트가 모두 통과한 것으로 정리했다. 토큰 사용량은 약 97.1k였다.

Claude가 보고한 산출물도 단순한 샘플 코드 수준은 아니었다. package.json, README.md, tsconfig.json, vitest.config.ts, IMPLEMENTATION_NOTES.md와 함께 src/domain, src/services, src/cli.ts, test/ 하위 테스트 파일들이 생성됐다. 요구사항 커버리지에는 초기화, ingest, query, lint, acceptance scenarios 1–8이 자동 테스트로 커버됐다고 명시했다.

같은 시점의 GLM-5.2는 약 50.1k 토큰을 사용하며 본격 구현 중이었다. 화면상 src/domain/hashing.ts, naming.ts, frontmatter.ts, markdown.ts를 작성했고, 다음 작업은 io/fs helpers, services, thin CLI, acceptance tests였다. 다시 말해 20분 30초 시점의 차이는 “Claude는 검증 완료, GLM은 핵심 도메인 구현 중”으로 요약된다.

최종: GLM-5.2도 Goal achieved, 그러나 한 번 끊긴 뒤 재개

최종적으로 GLM-5.2도 Goal achieved에 도달했다. 다만 중간에 API Error: Connection closed mid-response로 한 번 멈췄고, 사용자가 continue를 입력한 뒤 이어서 완료됐다는 점이 중요하다. 화면 하단에는 Goal achieved (1h · 1 turn · 76.7k tokens), Crunched for 17m 13s가 함께 표시됐다. 전체 goal 타이머는 1시간대로 남아 있고, crunched 시간은 재개 후 마지막 구간으로 해석하는 편이 안전한다.

GLM-5.2의 최종 리포트는 꽤 구체적이다. npm install은 8 packages, 0 vulnerabilities, npm run build는 exit 0, npm run typecheck도 src + tests 기준 exit 0, npm test는 40/40 pass, 0 fail로 보고했다. CLI smoke 테스트도 init/ingest/lint/query 흐름에서 fresh wiki가 0 issues로 lint됐다고 정리했다.

파일 구성은 src/types.ts, src/index.ts, src/cli.ts, src/domain, src/io/fs.ts, src/services, tests, tsconfig.json, tsconfig.test.json, IMPLEMENTATION_NOTES.md, package-lock.json까지 포함한다. 또한 “thin-interface rule respected”라고 명시해 CLI는 인자 파싱, JSON 포맷, exit code 처리만 담당하고 실제 로직은 services/domain에 둔 구조라고 설명했다.

따라서 최종 결론은 “GLM-5.2도 완성은 했다”이다. 하지만 실험 관찰 기준으로는 Claude Opus 4.8이 약 20분 30초에 48/48 테스트와 clean build로 먼저 완료했고, GLM-5.2는 약 30분 지점에서 한 차례 API 오류로 끊긴 뒤 continue로 재개해 1시간대에 최종 리포트를 냈다. 결과물 품질은 별도 코드 리뷰가 필요하지만, 에이전트 실행 안정성과 완료까지의 속도에서는 Claude가 더 안정적인 흐름을 보였다.

결과물 채점: Claude 78점, GLM 81점

두 결과물을 같은 기준으로 직접 빌드·테스트·CLI 스모크 테스트까지 돌려본 뒤 채점했다. 점수는 “에이전트 실행 속도”가 아니라 최종 코드 산출물 품질 기준이다. 실행 흐름은 Claude가 압도적으로 빨랐지만, 코드 산출물만 놓고 보면 GLM-5.2 쪽이 근소하게 더 높은 점수를 줄 수 있었다.

Claude 결과물의 가장 큰 감점 요인은 wikilink 해석이다. 스모크 테스트에서 entities/retrieval-augmented-generation.md와 entities/claude-code.md가 실제로 생성됐는데도, lint는 [[Retrieval Augmented Generation]]과 [[Claude Code]]를 broken-wikilink 경고로 보고했다. 즉 파일명은 slug인데 링크 해석은 단순 lowercase basename에 가까워, 사람이 자연스럽게 쓰는 title형 wikilink를 제대로 resolve하지 못했다.

GLM 결과물의 가장 큰 감점 요인은 lint API의 의미 오류이다. SCHEMA.md를 삭제한 뒤 lint --strict를 실행하면 exit code는 1로 올바르게 실패하지만, JSON payload는 {"ok": true, "issues": [{"severity":"error", ...}]} 형태로 출력된다. CLI 종료 코드는 맞지만, machine-readable API를 쓰는 소비자 입장에서는 ok 의미가 틀린 셈이다.

그래서 최종 판정은 이렇게 정리했다. 에이전트 실행 성능은 Claude Opus 4.8 승이다. Claude는 약 20분 30초에 중단 없이 Goal achieved에 도달했다. 반면 최종 코드 산출물 품질은 GLM-5.2가 근소 우세이다. GLM은 훨씬 늦고 중간에 API 오류로 한 번 끊겼지만, 최종 구현은 fresh wiki lint가 더 깨끗하고 링크 정규화가 실제 사용 관점에서 더 낫다.

이번 실험의 한계: 이 결과 하나로 모델 우열을 단정할 수는 없다

이 실험은 GLM-5.2와 Claude Opus 4.8의 실제 코딩 에이전트 사용감을 비교하는 하나의 사례다. 하지만 이 결과만으로 “GLM-5.2가 Claude Opus 4.8보다 항상 뛰어나다”거나, 반대로 “Claude Opus 4.8이 모든 상황에서 더 낫다”고 단정할 수는 없다.

첫째, 과제 유형이 결과를 크게 좌우한다. 이번 과제는 627줄의 정책 문서를 읽고 TypeScript 기반 CLI/서비스를 구현한 뒤 테스트를 통과시키는 작업이었다. 프론트엔드 UI, 대규모 리팩터링, 알고리즘 최적화, 레거시 코드 디버깅, 멀티모듈 백엔드 수정, 배포 자동화 같은 과제에서는 다른 결과가 나올 수 있다.

둘째, 실행 환경과 도구 안정성도 영향을 준다. GLM-5.2는 중간에 API Error: Connection closed mid-response로 한 번 끊겼고, 사용자가 continue를 입력한 뒤 완료됐다. 이것이 모델 자체의 추론 능력 문제인지, API/클라이언트/네트워크/세션 유지 문제인지는 이 실험 하나만으로 분리하기 어렵다.

셋째, 점수는 “최종 코드 산출물” 기준이다. Claude Opus 4.8은 훨씬 빠르게, 중단 없이, 더 많은 테스트를 생성하고 완료했다. 반면 GLM-5.2는 늦고 한 번 끊겼지만, 최종 산출물의 wikilink/slug 처리에서는 더 나은 부분이 있었다. 따라서 “에이전트 실행 안정성”과 “최종 코드 품질”은 같은 지표가 아니다.

넷째, 두 모델 모두 자기 테스트를 통과했지만, 자기 테스트 통과가 곧 완전한 품질을 의미하지는 않는다. 실제 채점에서는 별도 스모크 테스트를 돌려 Claude의 broken-wikilink 오탐과 GLM의 ok: true 의미 오류를 발견했다. 더 엄격한 외부 테스트 세트나 장기 유지보수 관점의 코드 리뷰를 붙이면 점수는 달라질 수 있다.

따라서 이 글의 결론은 중립적으로 읽는 것이 맞다. 이번 실험에서는 Claude Opus 4.8이 실행 속도와 중단 없는 완료 능력에서 앞섰고, GLM-5.2는 최종 코드 산출물 평가에서 근소하게 앞섰다. 다만 이는 특정 입력 문서, 특정 과제, 특정 실행 환경에서의 관찰 결과이며, 모델의 일반적 우열을 단정하는 결론은 아니다.

벤치마크 1등이 실제 에이전트 결과물 1등은 아니다

최근에는 특정 모델이 코딩 벤치마크에서 Claude를 넘어섰다는 식의 뉴스가 자주 나온다. 예를 들어 GLM-5.2처럼 긴 컨텍스트와 코딩 벤치마크를 강점으로 내세우는 모델은 숫자만 보면 매우 매력적으로 보이다. 하지만 실제 코딩 에이전트로 프로젝트를 맡겨보면 결과가 꼭 벤치마크 순서대로 나오지는 않다.

그래서 코딩 에이전트를 평가할 때는 “벤치마크 점수에서 어느 모델이 이겼는가”보다 “내 저장소에서 같은 작업을 맡겼을 때 어떤 에이전트가 더 적은 수정으로 리뷰 가능한 결과물을 냈는가”를 봐야 한다. Agentic harness가 중요한 이유도 여기에 있다.

개발자가 봐야 할 5가지 지표

• 작업 완료율: 테스트까지 통과하는가?
• 수정 반복 횟수: 몇 번의 루프로 해결하는가?
• 토큰 비용: 같은 작업을 끝내는 데 얼마가 드는가?
• 실패 복구력: 테스트 실패나 타입 오류를 스스로 고치는가?
• 업무 유형별 적합도: 버그 수정, 리팩터링, 신규 기능 구현 중 어디에 강한가?

Claude Code·Codex·Gemini CLI 비교에 주는 의미

이 관점은 기존의 AI 코딩 에이전트 비교 글과도 연결된다. 단순히 “어느 도구가 더 똑똑하다”가 아니라, 내 프로젝트에서 어떤 작업을 맡길 때 성공률과 비용이 좋은지를 봐야 한다.

실무 적용 체크리스트

• 반복되는 버그 수정 작업 10개를 샘플로 만든다.
• 각 에이전트에 같은 브랜치와 같은 지시문을 준다.
• 테스트 통과 여부, 수정 파일 수, 실행 시간, 토큰 비용을 기록한다.
• 성공률만 보지 말고 리뷰 가능한 코드인지 확인한다.
• 팀 규칙과 이전 의사결정을 에이전트가 참조할 수 있게 문서화한다.

FAQ

Agentic harness는 일반 벤치마크와 무엇이 다른가요?

일반 벤치마크가 모델의 답변 능력을 본다면, agentic harness는 에이전트가 실제 개발 작업을 수행하는 전체 과정을 평가한다.

개인 개발자도 이런 평가가 필요한가요?

필요한다. 특히 유료 모델을 여러 개 쓰는 경우, 작업 유형별 성공률과 비용을 기록하면 어떤 에이전트에 어떤 일을 맡길지 판단하기 쉬워집니다.

출처

• GitHub Blog: Evaluating performance and efficiency of the GitHub Copilot agentic harness across models and tasks

The post GLM-5.2 vs Opus 4.8 코딩대결: AI 코딩 에이전트 평가 appeared first on .

1. 복잡한 리팩토링과 프로젝트 이해력은 Claude Code, 안전한 자동화·격리 실행은 Codex, 무료/저비용 탐색은 Gemini CLI가 강하다.
2. 벤치마크 숫자보다 중요한 것은 실제 워크플로우다. 대규모 코드베이스는 Claude Code, 반복 자동화는 Codex, 빠른 실험은 Gemini CLI가 유리하다.
3. 하나만 고르기보다 탐색은 Gemini CLI → 본격 개발은 Claude Code → 자동화는 Codex로 조합하는 방식이 2026년 기준 가장 현실적이다.

결론부터 말하면

세 도구를 수개월간 실무에서 돌려본 결론은 명확하다. 복잡한 프로젝트를 맡길 땐 Claude Code, 빠른 실험과 탐색은 Gemini CLI, 안전한 자동화 파이프라인은 Codex. 만능은 없다. 각자 철학이 다르고, 그 철학이 실사용에서 고스란히 드러난다.

왜 지금 CLI 에이전트인가

Cursor, Windsurf 같은 IDE 기반 도구와 달리, CLI 에이전트는 터미널에서 직접 돌아간다. GUI가 없다. 그 대신 프로젝트 전체를 읽고, 파일을 수정하고, 테스트를 실행하고, 결과를 보고 스스로 수정한다.

2025년까지는 “자동완성 잘 되는 IDE”가 주류였다면, 2026년은 “시키면 알아서 하는 에이전트”의 시대다. GitHub Copilot도 Agent Mode를 추가했고, Cursor도 Background Agent를 출시했다. 업계 전체가 에이전트로 수렴하고 있다.

그 중심에 있는 3대 CLI 에이전트를 직접 비교한다.

Claude Code — 일 잘하는 시니어 개발자

Anthropic이 만든 Claude Code는 현재 개발자 점유율 46%로 1위를 달리고 있다. Cursor(19%), GitHub Copilot(9%)을 큰 차이로 앞선다.

실사용 체감

처음 쓰면 좀 느리다는 인상을 받는다. 다른 도구들이 바로 코드를 뱉어내는 것과 달리, Claude Code는 먼저 프로젝트 구조를 파악한다. CLAUDE.md를 읽고, 디렉토리를 탐색하고, 기존 패턴을 학습한 다음에야 코드를 작성한다.

그 대신 결과물의 정확도가 확실히 다르다. 기존 코드 스타일을 따르고, 파일 간 의존성을 이해하고, 변경 사항이 다른 부분에 미치는 영향까지 고려한다. 대규모 리팩토링에서 이 차이가 극명하게 드러난다.

강점

시맨틱 프로젝트 그래프: Claude Code는 프로젝트의 의미 구조를 파악하는 내부 그래프를 구축한다. 덕분에 1M 토큰 컨텍스트를 다 채우지 않아도 관련 파일만 정확히 찾아낸다. “이 함수를 수정하면 어디가 영향받지?” 같은 질문에 정확히 답할 수 있는 이유다.
멀티 에이전트 워크플로우: 서브 에이전트를 병렬로 띄워서 독립적인 작업을 동시에 처리할 수 있다. PR 리뷰를 맡기면 보안, 성능, 코드 스타일을 각각 다른 에이전트가 검토한다.
프롬프트 캐싱: 세션 내에서 시스템 프롬프트와 프로젝트 컨텍스트가 캐싱되어 입력 비용이 80~90% 절감된다. API로 쓸 때 비용 차이가 크다.

단점

무료 티어 없음. 최소 Pro $20/월이 필요하다. 그마저도 Opus 4.6를 많이 쓰면 며칠 만에 한도에 걸린다. 제대로 쓰려면 Max $100/월은 각오해야 한다.
독점 소스. 내부에서 무슨 일이 일어나는지 볼 수 없다. 엔터프라이즈 환경에서 보안 감사가 필요한 경우 걸림돌이 된다.
변경 전 매번 확인 요청. 안전하지만 느리다. 자동 승인 모드가 있긴 하지만, 처음 쓰는 프로젝트에서는 일일이 확인하게 된다.

Codex — 안전 제일주의자

OpenAI의 Codex는 철학부터 다르다. 모든 코드 실행을 샌드박스 안에서 한다. 실수로 프로덕션 DB를 날릴 걱정이 없다는 뜻이다.

실사용 체감

Codex에 작업을 던지면 레포를 클론해서 격리된 환경에 넣고, 거기서 파일을 수정하고 테스트를 돌린다. 완료되면 diff를 보여주고, 사용자가 확인한 후에 반영된다.

안전하다. 확실히 안전하다. 하지만 이 안전함이 속도를 먹는다. 매번 샌드박스를 띄우고 환경을 세팅하는 오버헤드가 있다. 빠른 반복 작업에는 답답함을 느낄 수 있다.

강점

OS 수준 샌드박스: macOS에서는 Apple의 Seatbelt 프레임워크, Linux에서는 Landlock과 seccomp을 사용한다. 읽기 전용(suggest), 작업공간 쓰기(기본), 전체 접근(danger) 세 단계의 권한 모델이 있다. CI/CD 파이프라인에 통합하기 좋은 구조다.
오픈소스(Apache 2.0): 코드를 직접 읽고, 포크하고, 기여할 수 있다.
ChatGPT 생태계 통합: ChatGPT Plus/Pro 구독만 있으면 별도 설정 없이 바로 쓸 수 있다. 웹 UI에서 작업을 시작하고 CLI에서 이어가는 것도 가능하다.

단점

컨텍스트 윈도우가 상대적으로 작다. 192K~400K 토큰으로, Claude Code와 Gemini CLI의 1M에 비하면 절반 이하다. 대형 모노레포에서는 프로젝트 전체를 한 번에 파악하지 못한다.
품질 저하 보고. OpenAI 커뮤니티 포럼에서 “Codex is rapidly degrading”이라는 스레드가 주목받았다. 최근 몇 주간 출력 품질이 떨어졌다는 다수의 개발자 보고가 있다. 존재하지 않는 동시성 버그를 잡아냈다고 했는데 30분 확인해보니 환각(hallucination)이었다는 사례도 있다.
샌드박스 우회 이력. v0.106.0에서 zsh 샌드박스 우회 취약점이 패치됐다. 보안이 핵심 셀링포인트인 도구에서 이런 이력은 신뢰에 금이 간다.

Gemini CLI — 파격적인 무료 플레이어

Google이 오픈소스로 공개한 Gemini CLI는 무료로 하루 1,000회 요청이 가능하다. 신용카드 등록도 필요 없다. 개인 Google 계정만 있으면 된다.

실사용 체감

처음 써보면 “이게 진짜 무료?”라는 생각이 든다. Gemini 3.1 Pro와 1M 토큰 컨텍스트가 무료로 풀려있다. 설치도 npm install -g @anthropic-ai/claude-code… 가 아니라 npm install -g @google/gemini-cli 한 줄이면 끝이다.

v0.34.0부터 Plan Mode가 기본이다. 코드를 바로 수정하지 않고, 먼저 코드베이스를 읽고 변경 계획을 제안한다. 계획을 확인한 후에야 실행으로 넘어간다. 안전하면서도 Codex처럼 샌드박스 오버헤드가 없다.

강점

파격적 무료 티어: 60회/분, 1,000회/일. 대부분의 개인 개발자는 이 한도 안에서 충분히 쓸 수 있다. 유료 전환 없이도 실전 프로젝트에 투입 가능한 수준이다.
Google Search grounding: 다른 CLI 에이전트에 없는 기능이다. 코딩 중에 최신 라이브러리 문서나 API 변경 사항을 실시간으로 검색해서 반영한다. 빠르게 변하는 프레임워크를 다룰 때 유용하다.
1M 컨텍스트 + 오픈소스: Claude Code와 동일한 1M 토큰이면서, 소스 코드가 공개되어 있다. 엔터프라이즈에서 보안 감사를 통과해야 할 때 큰 장점이다.
MCP(Model Context Protocol) 지원: 커스텀 도구를 MCP 서버로 연결해서 확장할 수 있다. 사내 API, DB, 모니터링 도구 등을 에이전트가 직접 호출하도록 설정 가능하다.

단점

자율 실행 능력은 Claude Code에 미치지 못한다. 복잡한 멀티파일 리팩토링에서 간혹 엉뚱한 파일을 수정하거나, 기존 코드 패턴을 무시하는 경우가 있다. Claude Code가 프로젝트 구조를 의미적으로 이해하는 것과 대조된다.
컨텍스트 활용 방식. 1M 토큰이라는 거대한 창문이 있지만, 어떤 파일에 집중해야 하는지는 개발자가 명시적으로 알려줘야 할 때가 많다. 창문은 크지만 초점이 흐릴 수 있다.
무료 티어의 함정. 1,000회가 많아 보이지만, 에이전트가 내부적으로 여러 번 API를 호출하기 때문에 복잡한 작업 몇 개면 소진될 수 있다. 실질적으로는 하루 중간 규모 작업 10~15건 정도다.

비용 비교 — 월 얼마나 드나

구독 기준

API 토큰 기준 (100만 토큰당)

토큰 단가만 보면 Gemini가 가장 저렴하다. 하지만 Claude Code의 프롬프트 캐싱(80~90% 절감)을 고려하면 실사용 비용 차이는 줄어든다.

현실적인 월 비용 시나리오

취미 개발자 (주 5~10시간 코딩): Gemini CLI 무료 티어로 충분하다. 비용 $0.
풀타임 개발자 (주 30시간+): Claude Code Max 5x $100/월이 가성비가 좋다. Codex Pro $200/월은 같은 돈 대비 쓸 수 있는 양이 적다.
팀/회사: API 기반으로 가는 게 낫다. Gemini 3.1 Pro가 토큰 단가 최저, Claude Code가 품질 최고. 작업 유형에 따라 라우팅하는 팀이 늘고 있다.

벤치마크 — 숫자로 보는 성능

SWE-bench Verified는 실제 GitHub 이슈를 해결하는 능력을 측정한다. Claude와 Gemini가 0.2%p 차이로 거의 동급이다. 반면 Codex는 터미널 자동화(Terminal-Bench)에서 강세를 보인다. 추상적 추론(ARC-AGI-2)은 Gemini가 압도적이다.

벤치마크 점수가 비슷하다고 체감이 같은 건 아니다. 실무에서는 프로젝트 맥락을 얼마나 잘 이해하느냐, 첫 시도에 동작하는 코드를 내놓느냐가 더 중요하다. 이 부분에서는 Claude Code가 아직 한 수 위라는 게 다수의 의견이다.

어떤 상황에서 어떤 도구를 쓸까

Claude Code가 맞는 경우

• 대규모 코드베이스 리팩토링
• 기존 프로젝트의 아키텍처를 이해하고 수정해야 할 때
• 코드 리뷰 자동화가 필요할 때
• “한 번에 제대로 동작하는 코드”가 중요할 때
• 비용보다 품질이 우선인 프로젝트

Codex가 맞는 경우

• CI/CD 파이프라인에 AI를 통합할 때
• 프로덕션 환경에서 절대 사고가 나면 안 될 때
• 이미 ChatGPT Pro를 쓰고 있을 때
• 웹 UI → CLI 전환이 자연스러운 워크플로우를 원할 때

Gemini CLI가 맞는 경우

• AI 코딩 에이전트를 처음 써보는 경우 (무료 진입)
• 빠른 프로토타이핑과 탐색이 목적일 때
• 최신 라이브러리/API 문서가 필요한 작업 (Search grounding)
• 오픈소스 + 보안 감사가 필수인 엔터프라이즈 환경
• 비용에 민감한 개인 개발자나 학생

개인 개발자·팀·자동화 파이프라인별 선택 기준

AI 코딩 에이전트는 “가장 성능 좋은 하나”를 고르는 문제가 아니라, 내 개발 환경에서 어떤 리스크를 줄이고 어떤 시간을 아낄 것인지를 기준으로 고르는 것이 맞다.

실전 팁 — 같이 쓰면 더 좋다

세 도구 중 하나만 고르라는 법은 없다. 실제로 2026년 개발자들 사이에서는 2~3개를 작업 유형별로 나눠 쓰는 패턴이 자리잡고 있다.

추천 조합:

• 탐색/프로토타이핑: Gemini CLI (무료 + Search grounding)
• 본격 개발/리팩토링: Claude Code (정확도 + 프로젝트 이해)
• 배포/자동화: Codex (샌드박스 안전성)

이렇게 쓰면 Gemini CLI로 비용을 아끼면서, 핵심 작업은 Claude Code의 품질로 처리하고, 자동화 파이프라인은 Codex의 안전망 위에서 돌릴 수 있다.

2026년 기준 주의할 점

• 요금제와 무료 한도는 자주 바뀐다. 실제 도입 전 각 도구의 공식 가격 페이지와 계정 한도를 확인해야 한다.
• 벤치마크는 참고 지표일 뿐이다. SWE-bench, Terminal-Bench 점수가 좋아도 내 프로젝트의 프레임워크, 테스트 환경, 코드 스타일에 따라 체감은 달라진다.
• 시크릿과 운영 권한을 그대로 넘기면 안 된다. API 키, 배포 토큰, 운영 DB 접근 권한은 에이전트 실행 환경에서 분리하는 것이 안전하다.
• 자동 실행보다 검토 가능한 diff 중심 워크플로우가 안전하다. 특히 팀 환경에서는 테스트 결과, 변경 파일, 롤백 가능성을 확인한 뒤 반영해야 한다.

자주 묻는 질문 (FAQ)

Q. 비개발자도 쓸 수 있나?

A. 세 도구 모두 터미널 기반이라 CLI에 익숙하지 않으면 진입 장벽이 있다. 비개발자라면 Cursor나 Windsurf 같은 IDE 기반 도구가 더 적합하다.

Q. 셋 중 하나만 골라야 한다면?

A. 돈을 쓸 수 있다면 Claude Code. 무료로 시작하고 싶다면 Gemini CLI. 안전이 최우선이면 Codex.

Q. 한국어 코드 주석이나 문서 작성은 잘 되나?

A. Claude Code가 한국어 처리에서 가장 자연스럽다. Gemini CLI도 무난한 수준. Codex는 영어 중심으로 최적화되어 있어 한국어 주석 품질이 상대적으로 떨어진다.

Q. 기존 IDE(VS Code 등)와 같이 쓸 수 있나?

A. 세 도구 모두 터미널에서 독립적으로 동작하므로 어떤 IDE와도 병행 가능하다. Claude Code와 Codex는 VS Code 확장도 지원한다.

참고 자료

• Claude Code 공식 문서
• OpenAI Codex 개발자 문서
• Gemini CLI GitHub 저장소
• SWE-bench Verified 리더보드
• AI Coding Benchmarks 2026 (byteiota)

이 글은 2026년 6월 기준으로 업데이트했습니다. AI 코딩 에이전트의 모델, 요금제, 무료 한도, 벤치마크는 빠르게 바뀌므로 실제 도입 전 각 도구의 공식 문서를 함께 확인하세요.

The post AI 코딩 에이전트 비교 2026 최신판: Claude Code vs Codex vs Gemini CLI appeared first on .