대부분의 개발자들은 AI 코딩 에이전트를 잘못된 방식으로 평가합니다. 도구 세 개를 설치하고, 터미널을 열고, 똑같은 단순한 테스트용 프롬프트인 랜딩 페이지를 만들어줘를 실행합니다. 그러고 나서 결과물이 가장 예뻐 보이는 것을 선택하죠. 하지만 그런 테스트로는 실제 코드베이스 내에서 이 시스템들이 어떻게 작동하는지에 대해 거의 아무것도 알 수 없습니다.
더 나은 질문은 어떤 모델이 코딩 벤치마크에서 가장 높은 점수를 받았느냐가 아닙니다. 바로 어떤 시스템이 가공되지 않은 지능을 가져와 복잡하고 파일이 여러 개인 소프트웨어 프로젝트에 실제로 적용할 수 있느냐입니다. 모델은 두뇌를 제공합니다. 하네스(harness)—컨텍스트 관리, 도구 액세스, 에러 처리 및 권한 계층—는 손과 눈을 제공합니다. 서툰 손을 가진 천재적인 두뇌는 평범한 두뇌만큼이나 빠르게 여러분의 프로덕션 코드를 망가뜨릴 것입니다.
단순한 데모를 넘어 실제 엔지니어링 작업으로 들어갔을 때, 선두 도구들을 실제로 구분 짓는 요소는 다음과 같습니다.
하네스가 곧 제품이다
에이전트 하네스는 리포지토리 내에서 지능이 어떻게 작동할지를 결정합니다. 에이전트가 얼마나 많은 컨텍스트를 기억하는지, 어떤 파일에 접근할 수 있는지, 실패한 터미널 명령에서 어떻게 복구하는지, 그리고 .env 파일을 삭제하기 전에 멈춰야 한다는 것을 아는지 등을 제어합니다. 두 에이전트가 비슷한 벤치마크 점수를 가진 모델에서 실행될 수 있지만, 한 에이전트가 세 번의 파일 수정 후 모듈 간의 관계를 놓치는 반면 다른 에이전트는 아키텍처의 일관된 지도를 유지한다면, 후자는 리팩토링을 완료할 것이고 전자는 회귀(regression)를 유발할 것입니다.
이렇게 생각해보세요. 모델은 엔진이지만, 하네스는 서스펜션, 브레이크, 스티어링입니다. 도로 위에 머물 수 없다면 출력(power)은 아무런 의미가 없습니다.
Claude Code: 심층적인 리포지토리 추론
Claude Code는 단순히 코드를 추가하는 것이 아니라 복잡한 코드베이스를 이해해야 할 때 빛을 발합니다. 강점은 모듈 간 관계에 대한 멘탈 모델(mental model)을 유지하는 것입니다. 인증 미들웨어에서 시작되어 데이터베이스 래퍼를 거쳐 유효성 검사 유틸리티에서 나타나는 버그를 추적하고 있다면, Claude Code는 그 맥락을 놓치지 않고 유지하는 경향이 있습니다. 내부 API의 이름을 변경하고, 모든 호출부를 업데이트하며, 잊혀진 유틸리티 폴더의 섀도잉된 임포트(shadowed import)를 놓치지 않고 테스트를 조정해야 하는 대규모 리팩토링을 계획할 때 특히 유용합니다.
이를 최대한 활용하는 실질적인 방법은 프로젝트 루트에 CLAUDE.md 파일을 사용하는 것입니다. 이 문서는 여러분이 코드화할 수 있는 조직의 기억(institutional memory) 역할을 합니다. 모든 로깅은 console.log 대신 내부 래퍼를 사용해야 한다거나, 데이터베이스 마이그레이션은 /infra/migrations에만 존재해야 한다거나, 모든 새로운 React 컴포넌트에는 그에 상응하는 Storybook 파일이 필요하다는 등의 규칙을 지정할 수 있습니다. 이러한 가드레일이 없다면 어떤 에이전트든 학습된 기본값으로 흘러가 버릴 것입니다. 하지만 이 파일이 있다면, Claude Code는 팀이 구축하는 데 수개월이 걸린 컨벤션을 존중할 수 있습니다.
작업이 탐색적이고 아키텍처 중심적일 때 이 도구를 선택하세요. 까다로운 로직을 디버깅하거나 모노레포 패키지 간의 의존 관계를 재구성하고 있다면, 깊이 있는 컨텍스트 처리 능력이 결국 큰 도움이 될 것입니다.
OpenAI Codex: 구조화된 자동화
Codex는 대규모로 반복 가능한 결과가 필요한 팀을 위해 구축되었습니다. Claude Code가 탐색에 치중한다면, Codex는 자동화에 치중합니다. 새로운 마이크로서비스를 위한 보일러플레이트 생성, 특정 미들웨어 스택을 사용한 CRUD 엔드포인트 스캐폴딩, 또는 다수의 서비스에 걸친 설정 파일 업데이트와 같이 기존 팀 시스템에 끼워 맞춰야 하는 명확하게 정의된 작업이 있을 때 가장 잘 작동합니다.
주의할 점은 정밀함이 필요하다는 것입니다. 수용 기준(acceptance criteria)이 모호하면, Codex는 기술적으로는 실행되지만 여러분의 컨벤션을 위반하는 코드를 기꺼이 생성할 것입니다. 구조, 명명 규칙, 에러 처리 패턴, 테스트 기대치를 미리 정의하세요. 그런 환경에서 Codex는 페어 프로그래머라기보다는 자연어 지시를 이해하는 조립 라인처럼 작동합니다. 이는 내부 도구 제작, CI 관련 워크플로우, 그리고 창의적인 문제 해결보다 일관성이 더 중요한 모든 상황에서 강력한 힘을 발휘합니다.
Gemini CLI: 개방적이고 스크립트 작성이 가능한 워크플로우
Gemini CLI는 완전히 다른 형태를 띱니다. 대화형 코딩 어시스턴트라기보다는 터미널 환경 내의 확장 가능한 컴포넌트에 가깝습니다. 스크립트 작성이 매우 용이하여 표준 Unix 워크플로우로 파이프(pipe)를 연결하거나, grep, awk, jq와 체이닝하여 채팅창 사이를 복사하고 붙여넣을 필요가 없는 커스텀 툴체인을 구축할 수 있습니다.
터미널을 주 인터페이스로 사용하는 엔지니어들에게 이러한 개방성은 매우 중요합니다. 스테이징된 diff에서 커밋 메시지를 자동 생성하거나, 레거시 셸 스크립트를 인라인 설명이 포함된 Python 코드로 재작성하거나, 실패한 Kubernetes pod의 로그 출력을 요약하는 데 사용할 수 있습니다. 비대화형(non-interactive) 모드는 CI 파이프라인에서 특히 유용합니다. GitHub Action이나 Makefile 단계에 포함하여 가벼운 코드 변환을 수행하거나, 소스에서 문서 스니펫을 생성하거나, Slack 채널에 게시하기 전에 에러 출력을 정제할 수 있습니다.
이미 셸 스크립트와 조합 가능한 도구들을 중심으로 워크플로우가 구축되어 있다면, Gemini CLI는 기존 습관을 바꿀 필요 없이 자연스럽게 녹아듭니다.
실제로 중요한 작업
AI 에이전트 수용률에 관한 연구를 보면 숙련된 엔지니어들에게는 놀랍지 않은 패턴이 나타납니다. 바로 새로운 기능 개발보다 문서 변경 사항이 훨씬 더 자주 승인된다는 점입니다. docstring을 업데이트하거나, 주석을 수정하거나, README를 확장하는 작업은 컨텍스트가 제한적이고 저장소에 이미 스타일이 정립되어 있기 때문에 에이전트의 강점을 잘 활용할 수 있습니다. 반면 새로운 기능 개발은 발명, 엣지 케이스 예측, 그리고 어디에도 기록되어 있지 않을 수 있는 사용자 의도에 대한 이해를 요구합니다. 두 카테고리의 하네스(harness) 요구 사항이 근본적으로 다르기 때문에, 어느 한 도구가 두 분야 모두에서 압도적인 우위를 점하기는 어렵습니다.
이는 평가 방식이 실제 수행하는 작업과 일치해야 함을 의미합니다. 제약된 작업으로만 테스트한다면, 모든 도구가 천재처럼 보일 것입니다.
에이전트가 실제로 실패하는 지점
대부분의 실패는 모델 계층이 아닌 실행 계층에서 발생합니다. 코드는 문법적으로 완벽할지 몰라도, 내부 API에 대한 네트워크 타임아웃, macOS에서는 작동하지만 GNU/Linux에서는 실패하는 sed 명령, 또는 에이전트가 인식하지 못하는 권한 경계 등으로 인해 에이전트가 무너질 수 있습니다. 에이전트는 다음과 같은 상황에서 어려움을 겪습니다:
- API가 일시적인 오류를 반환할 때, 지수 백오프(backoff)를 수행하는 대신 루프가 계속 도는 경우.
- 도구가 에이전트가 오해할 수 있는 방식으로 포맷된 에러 스트림을 반환하는 경우.
- 명령에 에이전트가 권한이 없는
sudo액세스가 필요하여 아무런 반응 없이 멈춰버리는(silent hang) 경우. - 생성된 테스트가 단독으로는 통과하지만, 하네스가 연결 문자열을 제대로 노출하지 않아 실제 데이터베이스와 함께 실행할 때 실패하는 경우.
이것들은 통합 문제입니다. 에러를 읽고, 경계를 존중하며, 무모하게 진행하는 대신 인간의 개입을 요청할 줄 아는 하네스가 필요합니다.
이 도구들을 제대로 평가하는 방법
랜딩 페이지를 만들어줘와 같은 프롬프트로 에이전트를 테스트하는 것을 멈추십시오. 그것은 엔지니어링 능력이 아닌 시각적 결과물을 측정하는 것입니다. 대신, 각 도구에 다음과 같은 실제 작업이라는 동일한 시련(gauntlet)을 부여하십시오:
- 근본 원인과 증상이 스택의 서로 다른 계층에 존재하는, 여러 파일에 걸친 버그를 수정하십시오.
- 외부 동작을 변경하지 않고 지원 중단된(deprecated) 의존성을 제거하도록 모듈을 리팩터링한 다음, 테스트 스위트가 여전히 통과하는지 확인하십시오.
- 서드파티 API의 응답 구조가 변경된 후, 모든 모크 픽스처(mock fixture), 타입 정의 및 통합 테스트를 업데이트하십시오.
- 버전 충돌로 인한 빌드 오류를 진단하고 실제로 컴파일 가능한 수정안을 제시하십시오.
느낌(vibes)이 아닌 확실한 지표(hard metrics)를 추적하십시오. 완료율을 계산하십시오: 에이전트가 작업을 마쳤습니까, 아니면 중간에 포기했습니까? 코드가 병합 가능해지기까지 얼마나 많은 인간의 수정이 필요했는지 기록하십시오. 테스트가 첫 시도에 통과했는지, 아니면 여러 차례의 패치 작업이 필요했는지 확인하십시오. 시니어 엔지니어가 결과물을 검토하는 데 소비한 시간을 측정하십시오. 건드리지 말아야 할 파일을 건드리지 않았는지 확인하는 데 한 시간을 소비해야 한다면, 결점 없는 코드 200줄을 작성하는 도구는 가치가 없습니다.
핵심 요약
승리하는 도구는 가장 많은 글자를 생성하거나 가장 화려한 데모를 보여주는 도구가 아닙니다. 리뷰 마찰(review friction)이 가장 적으면서 병합 가능한 코드를 가장 많이 생성하는 도구입니다. 이 분야의 경쟁은 원시적인 모델 지능에서 신뢰할 수 있는 엔지니어링 하네스로 이동하고 있습니다. 시스템 설계가 실제 작업의 성격과 일치하는 에이전트를 선택하십시오: 아키텍처 수술을 위한 깊은 추론, 팀 자동화를 위한 구조적 정밀함, 또는 커스텀 워크플로우를 위한 터미널 확장성 중 하나를 말입니다. 그런 다음 장난감 같은 문제가 아닌 실제 실패 사례로 테스트하십시오.
이 분석은 이 상세 분석에 설명된 직접적인 비교 및 에이전트 행동 연구를 바탕으로 합니다.
엔지니어링 도구 및 AI 워크플로우에 대한 더 많은 논의를 원하시면 GyaanSetu 학습 커뮤니티에 참여하세요.