"코드를 작성한다"는 것은 더 이상 놀라운 일이 아닙니다. 2026년의 질문은, 직접 코드를 작성하는 데 드는 시간보다 검토하고 수정하는 데 더 많은 시간을 쓰지 않고도, 실제로 프로덕션 코드베이스 (production codebase)에 병합할 수 있는 코드를 작성하느냐 하는 것입니다.

우리는 세 가지 자율 코딩 에이전트 (autonomous coding agents)에게 동일한 프로덕션 작업을 부여하고, 유일하게 중요한 지표인 "우리가 이것을 배포할 것인가?"를 기준으로 결과를 평가했습니다.

작업 내용: Redis를 백엔드로 사용하는 기존 Express.js API에 엔드포인트별 설정 가능한 제한, 적절한 HTTP 응답 헤더, Redis 사용 불가 시의 우아한 성능 저하 (graceful degradation), 그리고 포괄적인 테스트를 포함한 속도 제한 (rate limiting) 기능을 추가하는 것입니다.
이것은 단순한 장난감 벤치마크가 아닙니다. 실제 팀의 분기별 스프린트 (sprint)에 등장하는 기능 요청 사항입니다.

에이전트: Devin (Cognition의 리브랜딩된 Windsurf 플랫폼인 Devin Desktop을 통해 사용, 월 $20), Claude Code (Opus 4.8이 포함된 Max 플랜, 월 $100), 그리고 Cursor Agent 모드 (Composer 2.5가 포함된 Pro 플랜, 월 $20).

동일한 리포지토리 (repo). 동일한 요구사항 문서. 동일한 평가 루브릭 (rubric). 실행 과정 중 어떠한 도움도 주지 않았으며, 각 에이전트에게 작업을 부여하고 스스로 작업하게 두었습니다.

작업 사양 (task specification)

우리는 각 에이전트에게 동일한 요구사항을 제공했습니다:

Express API에 속도 제한 미들웨어 (rate limiting middleware)를 추가하십시오.
요구사항:
- Redis 기반의 슬라이딩 윈도우 (sliding window) 알고리즘
...

기존 코드베이스에는 미들웨어 등록, 에러 응답 포맷팅, 테스트 구성에 대한 확립된 패턴이 있었습니다. 우리는 어떤 에이전트가 자신의 관습을 강요하는 대신 이러한 패턴을 존중하는지 확인하고자 했습니다.

Devin의 결과물

Devin은 약 22분 동안 자율적으로 작업했습니다. 코드베이스를 탐색하고, 기존 미들웨어 패턴을 식별하며, 구현 파일을 생성하고, 작업 내용을 검증하기 위해 테스트 스위트 (test suite)를 실행했습니다.

구현에는 Redis 정렬된 집합 (sorted sets)을 사용한 슬라이딩 윈도우 알고리즘이 사용되었는데, 이는 견고한 기술적 선택이었습니다. 엔드포인트별 구성은 코드베이스의 기존 미들웨어 접근 방식과 일치하는 데코레이터 패턴 (decorator pattern)을 사용했습니다.

잘 작동한 부분: Redis 상호작용 코드가 깔끔했고, 정렬된 집합 (sorted set) 구현이 정확했으며, HTTP 헤더가 적절하게 포맷팅되었습니다. 데코레이터 패턴 (decorator pattern)은 기존 코드베이스의 컨벤션과 일치했습니다. Devin은 자체 코드를 작성하기 전에 기존 미들웨어 구조를 명확하게 분석했습니다.

배포되지 못한 부분: Redis 장애 시의 우아한 성능 저하 (graceful degradation) 구현에 심각한 문제가 있었습니다. Redis를 사용할 수 없을 때, 미들웨어는 요구사항에 명시된 '경고와 함께 허용 (allow-with-warning)' 동작으로 넘어가는 대신 처리되지 않은 프로미스 거부 (unhandled promise rejection)를 발생시켰습니다. 에러 핸들링 경로가 부분적으로 구현되어 try-catch 문은 있었으나, catch 블록이 호출하는 로깅 함수 자체가 다시 Redis에 쓰기를 시도하면서 재귀적 실패 (recursive failure)를 일으켰습니다.

테스트는 해피 패스 (happy path)와 속도 제한 초과 (rate-exceeded) 경로를 잘 다루었습니다. Redis 장애 테스트가 존재했으나 잘못된 동작을 테스트하고 있었습니다. 즉, Redis가 다운되었을 때 요청이 차단되어야 한다고 단언(assert)했는데, 이는 우아한 성능 저하에 대한 요구사항과 모순되었습니다. 두 개의 테스트에는 하드코딩된 타이밍 단언 (timing assertions)이 포함되어 있어, 속도가 느린 CI 러너에서 불안정한 실패 (flaky failures)를 유발할 수 있었습니다.

코드 품질 점수: 3.5/5. PR 준비 완료까지 걸린 시간: Redis 폴백 (fallback) 수정, 테스트 단언 업데이트, 타이밍 의존성 제거 후 45분 소요.

Claude Code의 출력

Claude Code는 약 18분 만에 작업을 완료했습니다. 전체 프로젝트 컨텍스트를 로드했으며, 명확히 하기 위한 질문을 하지 않았고 (사양서가 충분히 상세했기 때문), 단 한 번의 패스 (single pass)로 구현을 완료했습니다.

슬라이딩 윈도우 (sliding window) 구현은 원자성 (atomicity)을 위해 Redis MULTI/EXEC 트랜잭션을 사용했는데, 이는 고동시성 (high-concurrency) 시나리오에서 Devin의 정렬된 집합 방식보다 더 견고한 접근 방식입니다. 엔드포인트별 구성은 기존의 데코레이터 패턴 (decorator pattern)을 사용했습니다.

잘 작동한 부분: Redis 장애 처리(failure handling)가 세 가지 중 가장 뛰어났습니다. 서킷 브레이커 패턴 (circuit breaker pattern)을 사용하여, Redis 장애가 3회 연속 발생하면 미들웨어(middleware)가 30초 동안 모든 요청을 허용하는 모드로 전환한 후 재시도합니다. 이는 요구 사항보다 더 정교한 방식이며, Redis가 실제로 다운되었을 때 연쇄적인 재시도 폭풍 (retry storms)을 방지할 수 있는 올바른 프로덕션 패턴입니다. 테스트에는 Promise.all을 사용한 동시 요청 테스트가 포함되어 실제로 경합 조건 (race condition) 경로를 실행했습니다.

검토가 필요했던 부분: 서킷 브레이커가 요구 사항에 명시되지 않은 복잡성을 추가했습니다. 이를 유지할지에 대해 논의했습니다. 결과적으로 유지하기로 결정했는데, 요청되지 않았더라도 이는 올바른 엔지니어링 결정입니다. 한 테스트에서는 실제 클라이언트의 에러 발생 동작을 완벽하게 재현하지 못하는 모의 (mock) Redis 클라이언트를 사용하여, 에러 경로 테스트에서 거짓 양성 (false positive)이 발생했습니다.

코드 품질 점수: 4.5/5. PR 준비 완료까지 걸린 시간: 15분 (모의 클라이언트 문제를 수정하고 서킷 브레이커 설계 결정에 대한 주석을 추가하는 시간 포함).

Cursor Agent의 출력

Cursor의 Composer 에이전트 모드는 약 14분 만에 작업을 완료하여 세 가지 중 가장 빨랐습니다. 인라인 IDE 경험 덕분에 구현 과정을 실시간으로 지켜볼 수 있었으며, 반복 주기 (iteration cycle)가 가장 유연했습니다.

슬라이딩 윈도우 (sliding window)는 TTL을 사용하는 Redis INCR 방식을 사용했는데, 이는 다른 두 구현 방식보다 더 단순하며, 이는 장점(코드량이 적고 이해하기 쉬움)인 동시에 한계점(높은 동시성 환경에서 윈도우 경계가 덜 정밀함)이기도 합니다.

잘 작동한 부분: 코드가 세 가지 구현 방식 중 가장 가독성이 좋았습니다. 명확한 변수 이름, 좋은 주석, 그리고 기존 코드베이스 스타일과의 일관성을 보여주었습니다. 테스트 구조는 프로젝트의 기존 패턴을 정확히 따랐습니다. HTTP 헤더도 올바르게 구현되었습니다.

배포되지 못한 부분: 속도 제한 (Rate limiting) 알고리즘에 윈도우 경계(window boundaries)에서 미묘한 문제가 있었습니다. 진정한 슬라이딩 윈도우 (Sliding window) 대신 고정된 TTL과 함께 INCR을 사용했기 때문에, 한 윈도우의 끝과 다음 윈도우의 시작 부분에서 요청이 폭주할 경우 의도한 제한을 초과할 수 있었습니다. 트래픽이 적을 때는 문제가 되지 않지만, 엄격한 속도 제한 요구 사항이 있는 높은 트래픽 상황에서는 버그가 됩니다.

Redis 장애 처리 (Failure handling)는 작동했지만 단순했습니다. 경고를 로그로 남기고 요청을 통과시키는 try-catch 방식이었습니다. 서킷 브레이커 (Circuit breaker), 백오프 (Backoff), Redis 상태 추적 기능이 없었습니다. 기능적으로는 작동하지만 프로덕션 수준으로 견고하게 다듬어지지는 않았습니다.

테스트는 잘 구조화되어 있었고 주요 경로를 커버했지만, 동시 요청 (Concurrent request) 테스트는 포함되지 않았습니다. 경계 조건 (Boundary condition) 문제는 생성된 테스트로는 잡아낼 수 없었을 것입니다.

코드 품질 점수: 3.5/5. PR 준비 완료까지 걸린 시간: INCR 방식을 적절한 슬라이딩 윈도우로 교체하고 동시 테스트를 추가한 후 35분 소요.

비교 매트릭스

이것이 실제로 우리에게 알려주는 것

Claude Code는 최소한의 수정만으로 병합(merge)할 수 있는 유일한 결과물을 만들어냈습니다. 서킷 브레이커 패턴, 원자적 트랜잭션 (Atomic transactions), 그리고 동시 테스트는 다른 두 에이전트가 보여주지 못한 프로덕션 관련 고려 사항에 대한 이해도를 입증했습니다.

Cursor는 초기 출력 속도가 가장 빨랐지만, 윈도우 경계 문제는 더 많은 인간의 검토 시간을 필요로 했습니다. 코드는 가장 가독성이 높았고 기존 스타일과 가장 일관성이 있었는데, 이는 장기적인 유지보수성 측면에서 중요한 요소입니다.

Devin의 재귀적인 Redis 실패는 만약 그대로 배포되었다면 프로덕션 장애(production incident)를 일으켰을 법한 종류의 버그입니다. 또한, 에러 핸들링(error handling) 코드가 언뜻 보기에는 올바르게 보이기 때문에 리뷰 과정에서 포착하기 어려운 종류의 버그이기도 합니다. 로깅 함수를 통해 실행 경로(execution path)를 추적하여, 해당 코드가 실패하는 Redis 연결로 다시 진입한다는 사실을 확인해야만 알 수 있습니다.

세 가지 모델 모두에서 나타나는 공통된 패턴: 모든 에이전트의 "해피 패스 (happy path)" 구현은 견고합니다. 차별점은 에러 핸들링 (error handling), 엣지 케이스 (edge cases), 그리고 프로덕션 강화 (production hardening) 단계에서 나타납니다. 이들은 엔지니어링 경험이 가장 중요하게 작용하는 차원이며, 에이전트 간의 격차가 가장 크게 벌어지는 차원이기도 합니다.

자율 코딩 에이전트 (Autonomous coding agents)는 빠르게 발전하고 있지만, "프로덕션 코드 배포 (shipping production code)"는 SWE-bench를 통과하는 것보다 훨씬 더 높은 기준을 요구합니다. 벤치마크는 에이전트가 정의된 문제를 해결할 수 있는지를 테스트합니다. 반면 프로덕션 준비성 (Production readiness)은 정의되지 않은 문제, 엣지 케이스 (edge cases), 실패 모드 (failure modes), 그리고 숙련된 엔지니어들이 암묵적으로 처리하는 요구사항에 명시되지 않은 동시 접속 패턴 (concurrent access patterns)을 에이전트가 얼마나 잘 처리하는지를 테스트합니다.

저희는 엔터프라이즈 규모에서 자율 코딩 에이전트를 평가하는 팀들을 위해, 단순히 출력 품질뿐만 아니라 20~200명 규모의 엔지니어 팀에 중요한 조달 기준을 다루는 **10가지 도구를 포함한 전체 CTO 비교 분석**을 작성했습니다.

Published by Dextra Labs, AI Consulting and Enterprise Agent Development