AI 코딩 에이전트 비교, 공개 점수 대신 우리 PR로 벤치마크를 만드는 실행 청사진

AI 코딩 에이전트 도입 회의에서 가장 빨리 나오는 질문은 “어느 모델 점수가 더 높은가”입니다. 그러나 운영 중인 저장소에서 더 중요한 질문은 다릅니다. 우리 티켓을 읽고, 우리 테스트를 통과하며, 우리 코드 규칙과 배포 위험을 감안한 변경을 만들 수 있는가입니다.

공개 벤치마크는 모델의 일반적인 능력을 살피는 출발점으로는 쓸 수 있습니다. 다만 내부 모듈의 의존관계, 테스트 관례, 리뷰 기준, 티켓의 불완전함, 보안 규칙까지 대신 평가해 주지는 않습니다. 같은 모델도 하네스, 스킬, 권한 범위, 추론 강도, 작업 난도에 따라 비용과 결과가 달라질 수 있습니다.

운영 단계의 팀이라면 AI 코딩 에이전트를 하나의 범용 도구로 선정하기보다, 실제 업무를 재현하는 평가 세트를 만들고 작업 유형별로 배치하는 편이 낫습니다. 아래 청사진은 “가장 높은 점수의 모델”을 찾는 절차가 아니라, “우리 팀에서 어느 설정을 어느 업무에 맡길지” 결정하는 절차입니다.

1. 평가 목표를 모델 선정이 아니라 배치 결정으로 바꾼다

벤치마크의 첫 산출물은 모델 순위표가 아닙니다. 어떤 조건의 티켓을 어떤 에이전트 설정에 보낼지 정한 업무 배치 정책이어야 합니다.

먼저 에이전트가 처리할 업무를 기능 이름이 아니라 변경 성격으로 나눕니다. 예를 들면 다음과 같습니다.

• 국소 수정: 문구, 설정값, 작은 버그처럼 수정 범위가 좁고 회귀 테스트가 갖춰진 작업
• 기능 확장: 여러 파일을 바꾸지만 기존 패턴을 따라 구현할 수 있는 작업
• 횡단 변경: API, 데이터 모델, 권한, 프런트엔드 등 여러 계층을 함께 건드리는 작업
• 위험 변경: 인증, 결제, 개인정보, 데이터 삭제, 권한 상승, 배포 설정처럼 검토와 승인 조건이 엄격한 작업
• 탐색 작업: 원인 분석, 리팩터링 후보 조사, 테스트 누락 탐색처럼 코드 변경보다 판단 근거가 필요한 작업

이 분류가 없으면 비용이 낮은 설정이 좋은지, 품질이 높은 설정이 좋은지 비교할 수 없습니다. 국소 수정에는 저비용 설정이 적합할 수 있지만, 위험 변경에는 사람의 설계 검토와 제한된 실행 권한이 더 중요할 수 있습니다.

이 단계에서 남겨야 할 산출물은 업무 분류표입니다. 각 유형마다 다음을 적습니다.

항목	결정할 내용
입력	티켓, 장애 기록, 설계 문서, 관련 파일 목록 중 무엇을 제공할지
성공 조건	테스트 통과 외에 요구사항 충족, 리뷰 가능성, 문서 갱신 등을 어디까지 볼지
허용 권한	파일 수정, 명령 실행, 외부 네트워크, 배포 접근을 어디까지 허용할지
사람 승인	계획 승인, 코드 승인, 병합 승인 중 어느 지점에서 필요한지
실패 비용	잘못된 변경이 사용자, 데이터, 보안, 일정에 미치는 영향

2. 병합된 PR을 평가 세트로 전환하되, 정답 패치를 보여주지 않는다

가장 실용적인 평가 재료는 이미 병합된 PR입니다. 병합 전 저장소 상태, 당시 티켓, 이후 병합된 변경 사항을 확보할 수 있기 때문입니다. 다만 병합된 diff는 에이전트에 보여주는 정답이 아니라, 평가자가 결과를 판단할 때 참고할 기록으로만 사용해야 합니다.

PR을 고를 때는 “잘 끝난 작업”만 모으는 방식도 피해야 합니다. 지나치게 정리된 티켓만 모으면 실제 운영에서 자주 마주치는 모호한 요구사항, 레거시 의존성, 테스트 부족 문제가 사라집니다. 반대로 장애성 핫픽스나 대규모 마이그레이션만 넣으면 소수의 특수 사례가 전체 판단을 왜곡할 수 있습니다.

평가 세트에는 다음 신뢰 조건을 둡니다.

1. 병합 당시 요구사항과 논의 기록을 확인할 수 있다.
2. 병합 전 커밋 또는 브랜치를 재현할 수 있다.
3. CI, 테스트, 린트 등 최소한의 검증 경로가 남아 있다.
4. 사람이 병합한 이유와 남은 우려를 알 수 있다.
5. 비밀정보, 고객 데이터, 접근 토큰을 제거하거나 격리할 수 있다.

티켓은 가능한 한 당시 모습으로 제공합니다. 에이전트 성능을 높이기 위해 나중에 상세한 힌트를 덧붙이면, 실제 티켓 품질이 아닌 편집된 프롬프트 품질을 측정하게 됩니다. 티켓 문장을 개선한 조건도 시험하고 싶다면 원본 티켓과 개선 티켓을 별도 조건으로 두고 결과를 분리해 봐야 합니다.

이 단계의 산출물은 익명화된 평가 티켓 묶음, 재현 가능한 기준 브랜치, 작업 난도 태그입니다. 난도는 파일 수만으로 매기지 말고 변경 범위, 로직 깊이, 외부 영향, 실패 시 복구 난도를 함께 기록하는 편이 좋습니다.

3. 품질, 비용, 시간을 같은 실행 단위에서 측정한다

에이전트 비교에서 흔한 실패는 테스트 통과율 하나로 결과를 정하는 일입니다. 테스트를 통과해도 요구사항 일부를 놓치거나, 예외 처리를 망치거나, 유지보수하기 어려운 구조를 추가할 수 있습니다. 반대로 테스트가 부족한 저장소에서는 통과율 자체가 품질을 충분히 설명하지 못합니다.

평가표에는 최소한 세 축을 둡니다.

• 품질: 요구사항 충족, 회귀 여부, 보안·권한 영향, 코드 일관성, 테스트와 문서의 적절성
• 비용: 모델 사용 비용뿐 아니라 재시도 횟수, 사람 리뷰 시간, 수정 후 재검증 비용
• 시간: 요청부터 결과 제출까지의 경과 시간과 사람이 개입한 시간

품질은 자동 검사와 사람 판단을 분리해 기록합니다. 자동 검사는 빌드, 단위 테스트, 통합 테스트, 정적 분석, 포맷 검사처럼 재현 가능한 항목을 담당합니다. 사람은 티켓 충족 여부, 변경 범위의 적절성, 리뷰 난이도, 위험한 가정 여부를 봅니다.

리뷰어에게 “좋은 코드인가”라고만 묻기보다 다음처럼 남은 일을 판정하게 하면 비교가 선명해집니다.

• 바로 병합 가능
• 경미한 수정 후 병합 가능
• 요구사항 또는 테스트 보완 후 재검토 필요
• 설계 오류나 위험 때문에 다시 구현 필요

한 공개 실험에서도 에이전트 조합별 성능은 작업 복잡도에 따라 달랐고, 일부 저비용 조합은 특정 조건에서 고가의 최상위 모델과 비슷한 품질을 보였습니다. 그러나 표본이 작고 특정 코드베이스에 한정된 결과였으므로, 이를 다른 조직의 비용 절감률이나 모델 순위로 일반화할 수는 없습니다. 여기서 가져갈 판단은 숫자가 아니라 방법입니다. 단일 우승자를 찾기보다, 우리 작업에서 허용 가능한 품질선과 비용선을 함께 확인해야 합니다.

이 단계의 산출물은 실행 기록표입니다. 모델명만 적지 말고 모델 버전, 하네스, 스킬, 프롬프트 규칙, 추론 설정, 권한, 실행 환경, 재시도 정책을 하나의 “설정”으로 기록해야 합니다. 같은 모델이라도 이 조합이 달라지면 별개의 후보입니다.

4. 반복 실행으로 변동성을 확인하고, 조기 실패 신호를 잡는다

에이전트 결과는 한 번의 성공이나 실패로 판단하기 어렵습니다. 같은 티켓과 같은 설정에서도 실행마다 탐색 경로, 도구 호출, 토큰 사용량, 결과 코드가 달라질 수 있습니다. 특히 복잡한 티켓은 한 번의 인상적인 결과가 평균 성능을 가릴 수 있습니다.

후보 설정마다 같은 티켓을 반복 실행하고, 평균 점수만 보지 말고 실패 분포를 확인해야 합니다. 평균 품질이 높아도 일정 비율의 실행이 병합 불가 수준이라면, 무인 처리 대상에는 맞지 않을 수 있습니다.

다음 신호가 보이면 라우팅 전에 원인을 먼저 조사하는 편이 안전합니다.

• 테스트는 통과하지만 리뷰에서 요구사항 누락이 반복된다.
• 작은 티켓에서 토큰과 실행 시간이 과도하게 늘어난다.
• 특정 스킬이나 프롬프트를 붙인 뒤 품질이 일관되게 좋아지지 않는다.
• 모델 버전을 바꾼 뒤 이전 설정의 성능 방향이 뒤집힌다.
• 계획 단계는 그럴듯하지만 구현 단계에서 관련 파일을 빠뜨린다.
• 위험 작업에서 권한 확대나 검증 우회 제안을 한다.

특히 스킬과 추론 강도는 품질을 올리는 고정 레버가 아닙니다. 공개된 비교에서도 어떤 조합에서는 스킬이 품질이나 시간을 개선했지만, 다른 모델 버전이나 난도에서는 반대 효과가 나타났습니다. 따라서 “이 스킬을 붙이면 좋아진다”는 규칙보다 “이 설정은 이 업무군에서 재검증됐다”는 기록이 더 오래 갑니다.

5. 라우터는 자동 배정기가 아니라 변경 가능한 운영 규칙으로 시작한다

평가가 끝나면 티켓을 받아 적절한 에이전트 설정으로 보내는 라우팅 규칙을 만듭니다. 처음부터 복잡한 분류 모델을 만들 필요는 없습니다. 티켓의 변경 범위, 위험 태그, 테스트 유무, 의존 서비스 수, 승인 필요 여부를 기준으로 한 규칙표로 시작할 수 있습니다.

예를 들어 국소 수정이며 테스트가 있고 위험 태그가 없는 작업은 저비용 설정에 보낼 수 있습니다. 여러 계층을 바꾸거나 권한과 데이터가 얽힌 작업은 계획 작성용 설정과 구현용 설정을 나누고, 사람의 설계 승인을 거치게 할 수 있습니다. 배포 권한이나 운영 데이터 접근은 품질 점수가 높더라도 별도 통제 대상으로 남겨야 합니다.

운영 산출물은 라우팅 정책, 예외 처리 규칙, 재평가 일정입니다. 정책에는 “어떤 작업을 어디로 보낼지”뿐 아니라 “어떤 조건이면 사람에게 되돌릴지”를 명시합니다. 예외 처리에는 테스트 실패, 비용 상한 초과, 실행 시간 초과, 위험 파일 변경, 요구사항 불명확을 넣을 수 있습니다.

모델과 도구는 계속 바뀝니다. 저장소의 구조, 테스트 범위, 티켓 작성 방식도 바뀝니다. 따라서 내부 벤치마크는 도입 시 한 번 만드는 문서가 아니라, 병합된 PR이 쌓일수록 갱신하는 운영 장치에 가깝습니다.

다음 스프린트에서 할 일은 후보 모델을 더 늘리는 것이 아닙니다. 최근 병합 PR 중 재현 가능하고 위험을 통제할 수 있는 작업부터 골라, 티켓·기준 브랜치·품질 판정표를 한 세트로 만드는 일입니다. 그 세트가 있어야 비용 절감 제안도, 고성능 모델 유지 결정도 팀의 실제 업무를 근거로 설명할 수 있습니다.