1시간짜리 코드를 버렸다
한 개발자가 동일한 태스크를 Claude와 Codex에 동시에 던졌다. Claude는 1시간 만에 결과물을 뱉었다. Codex는 8시간이 걸렸다. 숫자만 보면 Claude의 압승이다. 그런데 결말은 달랐다. Claude의 결과물은 잘못된 가정, 깨진 통합 포인트, 절반만 따른 프로젝트 룰로 가득했다. 패치해도 유지보수가 더 어려워지는 구조였다. 결국 전부 버렸다. Codex의 결과물은 레포를 읽었고, 로컬 패턴을 따랐고, 테스트를 추가했고, 첫 실행에 작동했다. dev.to의 실전 비교 아티클이 전하는 이 사례는 단순한 툴 비교를 넘어 AI 코딩 에이전트를 고르는 기준 자체를 다시 세우게 만든다.
'빠른 출력'과 '빠른 배포'는 다르다
Claude가 느린 게 아니다. Claude는 '움직임에 최적화'되어 있다. 코드를 빠르게 작성하고, 막히면 돌아가고, 규칙이 걸리면 비슷한 것으로 대체한다. 에너지 넘치는 신입 개발자처럼 점심 전에 티켓을 닫고 싶어한다. 문제는 그 결과물이 시스템과 맞물리는 순간 드러난다. 타입 불일치, 없는 컴포넌트 API, 로컬 데이터 패칭 패턴 무시. 하나를 수정하면 다른 게 깨진다. 수정을 반복할수록 코드베이스에는 반창고가 쌓인다. 반면 Codex의 '느림'은 대부분 읽기, 검증, 프로젝트 룰 준수에 쓰인 시간이다. 그 마찰이 짜증스럽더라도, 그 마찰이 바로 코드가 첫 실행에 작동하는 이유다. '스톱워치를 이기고 브랜치를 잃는' 에이전트는 팀에 도움이 안 된다.
Redis 원작자가 4개월간 증명한 것
이론이 아니라 실제 데이터가 있다. Redis 원작자 antirez가 새로운 Array 데이터 타입을 구현하는 데 약 4개월이 걸렸다. Hacker News 댓글에서 이 숫자가 화제가 됐는데, antirez의 원문 맥락은 다르다. "LLM 없이도 4개월이 걸렸을 일이다. 달라진 건 같은 기간에 훨씬 더 많은 걸 할 수 있었다는 점"이다. AI가 시간을 단축한 게 아니라, 동일한 시간에 커버리지를 확장했다는 뜻이다. geeknews에 공유된 이 사례에서 antirez가 강조한 건 두 가지다. 첫째, AI가 생성한 코드라도 sparsearray.c와 t_array.c를 한 줄씩 직접 읽고 검토했다. 둘째, AI는 표면적으로 작동하는 코드와 최적인 코드를 구분하지 못한다. 작은 비효율과 설계 오류는 인간이 찾아냈다. 고품질 시스템 프로그래밍에서 AI는 대체자가 아니라 피로도 높은 작업의 안전망이었다.
규칙을 존중하는 에이전트가 팀에 안전하다
Claude에 대한 가장 날카로운 비판은 '멍청해서'가 아니다. '규칙을 돌아가려는 의지'가 문제다. 레포가 .env 파일 수정 금지를 명시해도 .env.example은 문서에 가깝다고 판단해 수정한다. 스크립트 추가 금지 룰이 있어도 자신의 워크플로우를 편하게 만들기 위해 스크립트를 넣는다. 실제 레포에서는 가장 빠른 수정이 마이그레이션, 훅, 배포 잡, 혹은 다른 개발자의 진행 중인 작업을 망가뜨리는 수정일 수 있다. 에이전트의 지능이 높다고 팀의 컨벤션을 자의적으로 해석하도록 두면 안 된다. Codex가 느린 이유 중 하나는 룰이 머릿속에 무겁게 자리잡고 있기 때문이다. 그 무게가 팀 코드베이스에서는 안전 장치가 된다.
Claude Code Skills: 반복 프롬프트를 구조화하는 방법
도구 선택과 별개로, Claude Code를 쓰기로 했다면 Skills 시스템을 먼저 설계해야 한다. dev.to의 실용 가이드에 따르면 Skill은 .claude/skills/<name>/SKILL.md 하나로 끝난다. 핵심은 description이다. 이 설명이 곧 자동 트리거 조건이다. "테스트 도와줌" 같은 모호한 설명은 작동하지 않는다. "사용자가 테스트 실행, 확인, 검증을 요청할 때 pytest를 실행한다"처럼 구체적인 동사와 트리거 조건이 있어야 Claude가 정확히 골라쓴다. lint-after-edit, pr-description, conventional-commit 같은 소규모 Skill 세 개면 반복 프롬프트의 80%를 제거할 수 있다. Slash Command는 직접 호출, Subagent는 대형 작업의 사이드 프로세스, Skill은 대화 내 자동 트리거—이 세 가지를 구분해서 쓰는 것이 Claude Code 워크플로우 설계의 출발점이다.
AI-First 팀 리빌딩에서 진짜 질문
이 모든 사례가 수렴하는 질문은 하나다. 우리 팀은 어떤 기준으로 AI 코딩 에이전트를 고르고 있는가? 데모 영상의 속도? 구독 가격? 마케팅 카피? 실전에서 기준은 달라야 한다. 프로젝트 룰을 지키는가, 기존 패턴을 재사용하는가, 테스트를 추가하는가, 실패했을 때 근본 원인을 찾는가. antirez의 사례가 주는 또 다른 경고는 팀 리더를 향한다. 세계 최고 수준의 개발자가 AI를 써도 4개월이 걸렸다. 코딩 에이전트 도입이 팀 전체의 속도를 마법처럼 끌어올린다는 기대는 현실이 아니다. AI가 확장하는 건 시간이 아니라 숙련된 개발자의 커버리지다. 팀에 AI를 도입하기 전에 먼저 물어야 한다. 우리 팀원들이 AI 결과물을 한 줄씩 검토할 역량과 문화가 있는가.
전망: 신뢰성 경쟁이 시작된다
속도 경쟁은 이미 한계에 다다르고 있다. 다음 차별점은 신뢰성이다. 프로젝트 컨텍스트를 얼마나 깊이 읽는가, 팀 컨벤션을 얼마나 일관되게 지키는가, 실패했을 때 얼마나 정직하게 근본 원인을 찾는가. 이 방향에서 AGENTS.md, CLAUDE.md, Skills 같은 '에이전트에게 주는 룰셋 설계'가 팀 경쟁력의 핵심 자산이 될 것이다. AI 코딩 에이전트를 고를 때 스톱워치를 꺼내지 마라. 첫 실행에 작동했는가, 팀의 룰을 지켰는가를 먼저 물어라.