실행 요약 (Executive Summary)

이 문서의 목적: 개발에 적용되는 AI 도구들(Codex, Devin, Claude 등)의 실제 능력을 비교 가능하고 재현 가능한 방식으로 평가하기 위한 표준화된 모델입니다. 각 도구가 무엇을 잘하는지, 무엇을 못하는지, 혹은 무엇을 하지 못하는지를 정확하게 식별합니다.

이 방법론을 사용하는 이유: 현재 시장에서는 일반적인 능력의 기준으로 활용되는 공개 벤치마크(SWE-bench 및 Terminal-Bench 등) 수치를 발표하고 있지만, 비즈니스 의사 결정 측면에서 두 가지 중요한 한계점이 있습니다.

1. 제3자의 오픈 프로젝트(대부분 Python)에서의 성능을 측정하며, 기업의 고유한 코드베이스(Proprietary codebases), 레거시(Legacy), 그리고 기업 특유의 스택(Stack)에서의 동작을 반영하지 못합니다.
2. 발표된 결과는 모델 자체뿐만 아니라 모델 주변에서 사용되는 도구(AI가 운영되는 방식)에 크게 의존합니다. 따라서 공급업체 간의 "가공되지 않은(Raw)" 비교는 오해를 불러일으키기 쉽습니다.

따라서 이 템플릿은 시장에서 인정받는 세 가지 기준을 결합합니다. 출발점으로서의 공개 벤치마크, 도구가 어디까지 견딜 수 있는지 측정하기 위해 AI 평가 기관(METR)에서 사용하는 난이도 척도(Difficulty scale metric), 그리고 기업의 AI 도구 선정 과정에서 사용되는 평가 구조(신뢰성, 추적 가능성, 보안 및 실제 비용과 같은 차원)를 결합합니다. 여기에 우리 운영의 실제 코드를 바탕으로 실행되는 통제된 파일럿 테스트를 더하며, 테스트된 모든 도구에 대해 동일한 기준과 검토자를 적용합니다.

기대 결과: 어떤 도구를 어떤 목적으로 채택해야 하는지, 그리고 알려진 한계점은 무엇인지에 대한 권장 사항을 뒷받침하는, 문서화된 증거를 포함한 객관적인 매트릭스(Matrix)를 생성합니다.

방법론적 원칙: 테스트는 단순화된 데모 프로젝트가 아닌, 백로그(Backlog)의 실제 작업에 대해 수행되어야 합니다. 비교 가능성을 보장하기 위해 모든 도구에 대해 동일한 검토자가 동일한 기준으로 평가를 진행해야 합니다.

1. 테스트 준비

• 실제 저장소 (Real Repository): 단순화된 새 프로젝트가 아닌, 레거시 코드 (Legacy code), 특이 사항 및 고유한 컨벤션 (Conventions)이 포함된 실제 저장소를 사용해야 합니다. 각 도구의 한계는 이러한 실제 복잡성 앞에서 드러납니다.
• 인간 기준점 (Human baseline): 비교를 위한 참조값으로서, 미들급 (Pleno) 개발자가 동일한 작업을 수행하는 데 걸리는 시간을 측정합니다.
• 단일 검토자 (Single reviewer): 테스트하는 모든 도구에 대해 동일한 사람과 동일한 평가 기준 (PR 체크리스트)을 적용해야 합니다.
• 반복 (Repetition): 도구당 각 작업을 2~3회 반복하여 실행합니다. 생성형 AI (Generative AI)의 결과는 동일한 요청에 대해서도 실행 시마다 달라질 수 있으므로, 단 한 번의 시도로는 평가가 왜곡될 수 있습니다.

2. 도구별 역량 매트릭스 (Capability Matrix)

척도: 0 = 수행 불가 | 1 = 낮은 품질로 수행, 재작성 필요 | 2 = 적절한 수준으로 수행, 조정 필요 | 3 = PR 가능한 수준으로 수행

평가 역량	Codex	Devin	Claude	기타
단일 파일 내 간단한 버그 수정
...

3. 역량 한계 테스트 (Capability Limit Test)

도구가 실패할 때까지 작업의 난이도를 점진적으로 높여야 합니다. 목표는 각 도구가 어느 단계에서 신뢰할 수 있는 성능을 내지 못하는지 기록하는 것입니다.

1. 1개 파일 작업, 인간의 작업 시간 30분 미만과 대등
2. 23개 파일 작업, 인간의 작업 시간 12시간과 대등
3. 여러 서비스/저장소를 가로지르는 작업, 인간의 작업 시간 반나절과 대등
4. 명확한 사양 없이 디자인 의사결정이 필요한 작업, 인간의 작업 시간 하루와 대등

이 접근 방식은 연구 기관인 METR에서 사용하는 타임 호라이즌 (Time Horizon) 개념에 기반합니다. 이는 AI가 "맞추는지"를 측정하는 것이 아니라, 도구가 어느 정도의 복잡성/지속 시간을 가진 인간의 작업까지 수용 가능한 성공률을 유지하는지를 측정하는 지표입니다. 각 도구가 실패하는 단계를 식별하는 것은 단일 점수를 매기는 것보다 의사결정에 더 많은 정보를 제공합니다.

4. 보완적인 기업용 기준 (Critérios Corporativos Complementares)

차원 (Dimensão)	평가 기준 (Critério de avaliação)	Codex	Devin	Claude
일관성 (Consistência)	동일한 요청에 대해 실행할 때마다 결과가 크게 달라지는가?
...

5. 방법론적 유의사항 (Ressalvas Metodológicas)

• 운영 계층 (제품)은 모델 자체만큼이나 중요합니다. 동일한 모델(예: Claude)이라도 서로 다른 제품을 통해 실행될 경우 결과가 다를 수 있습니다. 따라서 단순히 "어떤 AI인가"뿐만 아니라 "어떤 AI를 어떤 제품에서 사용하는가"를 기록할 것을 권장합니다.
• 공개 벤치마크 (Benchmarks)는 특정 유스케이스 (Use case)를 예측하지 못합니다. 시장의 벤치마크는 주로 Python 기반의 오픈 소스 프로젝트를 평가하며, Kafka 및 IBM MQ를 사용하는 레거시 핀테크의 Java 환경에서의 동작을 반영하지 않습니다. 벤치마크는 일반적인 참고 자료로 취급해야 하며, 의사결정의 절대적 기준으로 삼아서는 안 됩니다.
• 공급업체가 발표하는 수치는 주의해서 다뤄야 합니다. 특히 재현 가능한 방법론이 수반되지 않은 경우에는 더욱 그렇습니다.
• 공급업체의 데모 (Demonstration)가 통제된 파일럿 (Pilot) 테스트와 동일한 것은 아닙. 데모에서 제시되는 시나리오는 유리한 조건(최근의 단순한 프로젝트)인 경향이 있습니다. 평가는 기술 부채 (Technical debt)를 포함하여 실제 운영 중인 코드를 대상으로 이루어져야 합니다.
• 숨겨진 비용을 측정해야 합니다. AI가 생성한 결과물을 수정하기 위해 시니어 개발자가 추가로 투입하는 검토 시간은 비용입니다. 이는 단순히 절약된 명목상의 시간만이 아니라, 최종 생산성 이득 계산에 반드시 포함되어야 합니다.

6. 테스트 실행을 위한 표준화된 프롬프트 (Prompts Padronizados)

테스트 간의 비교 가능성을 보장하기 위해 Codex, Devin, Claude에 동일한 프롬프트(파일명/함수명만 조정)를 적용할 것을 권장합니다.

단순 버그 수정 (파일 1개)

"[경로] 파일에서 [테스트 이름] 테스트가 실패하고 있습니다. 테스트의 기대 동작을 변경하지 말고 원인을 조사하여 수정하세요."

크로스 서비스 (Cross-service) 버그 수정

"[A] 서비스가 [B]를 호출할 때 에러를 반환하고 있습니다. 두 서비스 사이의 전체 흐름을 추적하여 문제의 원인을 식별하고 수정 방안을 제안하세요. 수정하기 전에 어떤 파일들을 변경할 계획인지 명시하세요."

시그니처 변경 영향 분석 (Analysis of impact of change of signature)

"[nome] 메서드의 시그니처 (signature)를 [assinatura atual]에서 [nova assinatura]로 변경하고 싶습니다. 변경을 수행하기 전에, 이 메서드를 호출하는 프로젝트 내의 모든 지점과 그로 인해 영향을 받는 부분을 나열하세요."

기존 패턴 준수 (Adherence to existing pattern)

"이 프로젝트의 다른 엔드포인트 (endpoint)에서 이미 사용 중인 아키텍처, 명명 규칙 (naming convention), 에러 처리 (error handling) 패턴을 정확히 따라서 새로운 엔드포인트 [descrição]를 생성하세요. 새로운 패턴을 도입하지 마세요."

컨텍스트 유지 (새 세션에서 실행) (Retention of context)

"내가 컨텍스트를 다시 제공하지 않아도 답변하세요: 이 프로젝트가 예외 처리 (exception handling)를 위해 사용하는 컨벤션 (convention)은 무엇인가요? 그리고 브랜치 (branch) 명명 규칙은 무엇인가요?"
(도구가 세션 간 메모리를 보유하고 있는 경우에 적용됩니다. 만약 도구가 컨텍스트를 다시 요청한다면, 그 자체로 도구의 한계에 대한 유의미한 데이터가 됩니다.)

지식 한계 인식 (Recognition of knowledge limitation)

"[최근에 변경되었거나 존재하지 않는 것으로 알고 있는 라이브러리 또는 API에 의존하는 기능]을 구현하세요."
목적: 도구가 불확실성을 표시하는지, 아니면 그럴듯해 보이지만 틀린 코드를 생성하는지 확인합니다.

실행 없는 분석 (Analysis without execution)

"아직 아무런 변경도 수행하지 마세요. 단지 설명만 하세요: 만약 내가 [função]의 반환 타입 (return type)을 X에서 Y로 변경한다면, 프로젝트의 어떤 부분에 영향이 가나요?"

테스트 커버리지 (Test coverage)

"[classe/função]에 대한 단위 테스트 (unit tests)를 작성하세요. 널 입력 (null input), 빈 리스트 (empty list), 동시성 (concurrency) 또는 타임아웃 (timeout)과 같이 명확하지 않은 경계 사례 (edge case)를 최소 하나 이상 포함하세요."

복잡도 한계 테스트 (3섹션 4단계)

"[상세한 사양 없이 디자인 결정이 필요한 새로운 기능]이 필요합니다. 의도적으로 모든 세부 사항을 제공하지는 않겠습니다. 구현을 시작하기 전에 필요하다고 판단되는 질문을 모두 해주세요."
목표: 도구가 실행하기 전에 명확한 설명을 요청하는지, 아니면 검증되지 않은 전제 조건(assumptions)을 바탕으로 진행하는지 확인.

7. 출처

• SWE-bench / SWE-bench Verified / Pro — arxiv.org/pdf/2509.16941, swebench.com
• Terminal-Bench 2.1 — tbench.ai, arxiv.org/html/2601.11868v1
• METR Time Horizon — metr.org/time-horizons, arxiv.org/html/2503.14499v1
• Checklist enterprise 6 dimensões (adaptado) — augmentcode.com/guides/cto-ai-coding-checklist
• Pilot enterprise (metodologia de rollout) — lumenalta.com/insights/how-to-evaluate-ai-coding-tools-for-enterprise-teams
• Governança de benchmarks / harness effect — digitalapplied.com/blog/swe-bench-terminal-bench-benchmark-guide-2026
• Devin SWE-bench technical report — cognition.ai/blog/swe-bench-technical-report