생성한 코드는 그럴듯하지만 테스트 통과 여부와 수정 시간이 모델마다 달라 선택이 어렵습니다.
빠른 해법은 Gemini, Claude, GPT를 같은 과제와 도구 조건으로 시험하고 통과율, 사람 손질, 지연, 호출 비용을 함께 비교하는 것입니다. 한 모델이 모든 코드 작업에서 가장 낫다고 가정하지 마세요.
코드 생성 API를 도입하려는 개발자는 실제 작업을 평가 과제로 바꿀 수 있습니다.
기술 책임자는 품질과 속도, 총비용을 같은 기준으로 검토할 수 있습니다.
프로그래밍 도우미를 만드는 팀은 과제에 따라 단일 모델과 여러 모델 분기를 결정할 수 있습니다.
코드 생성 결과를 어떻게 판정할까요?
완성된 코드가 자연스럽게 보이는지는 합격 기준이 아닙니다. 실제 저장소에서 요구한 동작을 수행하고, 기존 동작을 깨뜨리지 않는지가 중요합니다. 평가 전에 판정 규칙을 정하고 결과를 남겨야 나중에 모델이나 프롬프트를 바꿔도 비교가 이어집니다.
과제마다 다음 항목을 기록하세요.
- 과제 완료: 요구된 파일과 기능이 빠짐없이 수정되었는지 확인합니다.
- 테스트 통과: 기존 테스트와 새로 추가한 테스트를 각각 실행합니다. 생성 코드가 테스트를 통과해도 테스트가 중요한 실패 조건을 다루는지 확인해야 합니다.
- 결함 심각도: 오동작, 데이터 손실 가능성, 보안 문제, 스타일 차이를 구분합니다. 사소한 형식 문제와 배포를 막는 결함을 같은 점수로 처리하지 마세요.
- 사람 손질: 검토, 수정, 재실행에 실제로 든 시간을 적습니다. 통과 여부만으로는 검토 부담을 파악하기 어렵습니다.
공개 평가도 후보를 찾는 출발점으로 쓸 수 있습니다. SWE-bench 원 연구는 실제 소프트웨어 저장소의 문제를 바탕으로 과제를 구성했으며, 연구에 포함된 범위는 12개 저장소의 2,294개 문제입니다. 이 숫자는 해당 연구의 평가 범위를 설명할 뿐, 네 언어와 저장소에서의 성능을 보장하지 않습니다. 정제된 과제 집합인 SWE-bench Verified의 평가 설명 역시 500개 과제를 다루므로, 결과를 그대로 구매 기준으로 삼기보다 네 과제와 얼마나 비슷한지 확인해야 합니다.
응답 속도와 실제 완료 시간의 차이
모델이 먼저 문자를 보내기까지의 시간만 재면 작업 속도를 잘못 판단할 수 있습니다. 코드가 모두 생성될 때까지 기다리는 시간, 사람이 내용을 살피고 고치는 시간까지 따로 기록하세요. 결과물을 받는 속도와 배포 가능한 변경을 얻는 속도는 다를 수 있습니다.
예를 들어 팀이 오류 수정 요청을 보냈을 때 한 모델은 빠르게 패치를 내놓더라도 테스트 누락이 반복될 수 있습니다. 다른 모델의 생성은 늦더라도 검토와 재작업이 적다면, 실제 작업 완료는 후자가 더 빠를 수 있습니다. 이때 모델 응답 시간만 비교하면 중요한 비용이 가려집니다.
공정한 측정을 위해 과제 입력, 저장소의 기준 상태, 테스트 명령, 도구 권한을 고정하세요. 첫 응답까지의 지연, 전체 생성 시간, 사람의 검토·수정 시간을 구분해 기록하고 같은 과제를 반복해 결과의 흔들림도 확인합니다. 실행 환경과 시간 측정의 시작·종료 시점이 달라지면 비교 기록에 그 차이를 명시하세요.
주의: 서로 다른 프롬프트, 모델 버전, 도구 권한으로 얻은 응답 시간을 한 줄에 놓고 순위를 매기지 마세요. 측정 조건이 다르면 속도 차이가 모델 때문인지 실험 설정 때문인지 알 수 없습니다.
호출 요금과 사람 손질 비용
호출 비용을 비교할 때는 네가 실제로 보낸 입력과 받은 출력의 양을 사용하세요. 제공업체별 요금은 모델과 과금 조건에 따라 달라질 수 있으므로, 계산 시점의 공식 요금표에서 입력·출력 항목과 적용 조건을 확인해야 합니다. Gemini API 요금 안내, Claude API 요금 안내, OpenAI API 요금 안내를 각각 확인하고 서로 다른 과금 조건을 같은 것으로 가정하지 마세요.
그리고 API 청구액만으로 최저 비용 모델을 정하지 마세요. 코드 검토, 수정, 테스트 실패 후 재호출에 든 시간을 별도 항목으로 계산해야 합니다. 팀의 인건비 산정 방식에 따라 호출료가 낮은 모델이 총비용에서는 불리해질 수도 있습니다. 모델별 사용량과 재시도 횟수를 남기면 호출 비용이 늘어난 원인도 확인할 수 있습니다.
모델 이름과 버전, API 방식도 기록 대상입니다. Gemini 모델 문서와 Claude 모델 식별자 및 버전 안내를 확인하고, 평가에 사용한 정확한 모델 식별자를 결과와 함께 저장하세요. 모델이나 가격이 바뀌면 예전 기록을 현재 조건의 결과인 것처럼 비교하지 말고 다시 확인해야 합니다.
과제 성격에 따른 모델 선택 기준
세 모델을 브랜드 평판으로 줄 세우는 대신, 먼저 코드베이스와 과제 종류에 맞는 후보를 정하세요. 저장소의 여러 파일을 이해해야 하는지, 도구를 이용해 테스트를 실행해야 하는지, 팀이 쓰는 언어와 개발 흐름에 맞는지도 평가에 포함해야 합니다. 특정 API 기능이나 도구 연동이 필요한 경우에는 현재 문서에서 지원 여부와 제한을 직접 확인하세요.
실무에서는 저장소 맥락이 길어 필요한 정보가 입력에 충분히 들어가지 않거나, 도구 권한이 제한되어 모델이 테스트를 실행하지 못할 수 있습니다. 호출 제한이나 재시도는 완료 시간을 늘릴 수 있고, 개발자가 익숙한 언어가 과제에 섞이면 손질 시간도 달라질 수 있습니다. 따라서 통과율 하나만 비교하지 말고, 실패 원인을 맥락 부족, 생성 오류, 도구 사용, 실행 환경 문제로 나눠 남기세요.
과제 구성이 공개 벤치마크와 다르다는 점도 고려해야 합니다. 예를 들어 SWE-rebench 연구는 평가 과제의 최신성과 재현성 문제를 연구 대상으로 삼습니다. 공개 연구는 평가 방법과 잠재적 한계를 이해하는 데 도움이 되지만, 네 서비스의 저장소와 작업을 직접 검증하는 절차를 대신하지는 않습니다.
선택 조건별 결정 도구
아래 항목을 실제 평가 결과로 확인한 뒤, 조건에 따라 채택 여부를 정하세요.
- [ ] 품질 기준: 대표 과제에서 테스트를 통과하고, 허용할 수 없는 심각한 결함이 없습니다. 충족하면 해당 과제 유형의 후보로 남기고, 충족하지 못하면 다른 후보를 평가하거나 작업 범위를 조정합니다.
- [ ] 손질 시간: 검토와 수정 시간이 팀이 정한 허용 범위 안에 있습니다. 넘으면 호출료가 낮더라도 총비용 후보에서 제외하거나 사람 손질이 적은 모델로 되돌립니다.
- [ ] 단순 작업의 비용: 반복적인 작은 수정에서 가벼운 후보가 품질 기준을 통과하고 총비용도 낮습니다. 둘 다 충족하면 그 작업에 배정하고, 통과가 불안정하거나 재작업이 늘면 더 복잡한 작업에 쓰는 후보로 전환합니다.
- [ ] 복잡한 작업의 품질: 여러 파일 수정이나 까다로운 테스트 추가에서 재작업이 적은 후보가 확인됩니다. 그렇다면 복잡한 과제에만 분기하고, 결과 차이가 작다면 운영 부담을 줄이도록 기존 모델을 유지합니다.
- [ ] 운영 호환성: 필요한 언어, 도구, 저장소 맥락과 API 기능을 지원합니다. 충족하지 못하면 평가 점수가 높아도 운영 후보에서 제외하고, 문서에서 제한을 확인한 뒤 다시 시험합니다.
즉, 품질 기준을 충족하지 못하면 다른 후보로 돌아가고, 사람 손질이 과도하면 낮은 호출료만으로 채택하지 마세요. 단순 작업과 복잡한 작업에서 결과 차이가 확인될 때만 분기하는 편이 관리하기 쉽습니다.
반복 평가 절차
운영 절차는 평가 결과가 다음 선택에 이어지도록 구성해야 합니다.
- 실제 팀 업무에서 반복되는 코드 과제를 모으고, 입력 자료와 완료 조건을 함께 저장합니다.
- 기존 저장소 상태와 실행할 테스트를 고정합니다. 평가 도중 프롬프트나 권한이 달라지면 해당 결과를 별도 조건으로 기록합니다.
- 사용할 모델의 정확한 식별자, API 방식, 프롬프트와 도구 권한을 기록합니다. 모델 버전이 바뀌면 새 평가 기록을 시작합니다.
- 각 후보에 동일한 과제를 실행하고, 테스트 결과와 결함 심각도, 생성 시간, 사람의 검토·수정 시간을 남깁니다.
- 공식 요금표와 실제 사용량으로 호출료를 계산하고 사람 손질 비용 및 재시도 내역과 함께 검토합니다. 기준을 넘긴 모델은 해당 과제에서 제외하거나 다른 후보로 전환합니다.
실제 서비스를 붙이기 전에는 배포와 운영 조건도 점검하세요. 실행 환경과 접속 경로에 관한 인프라 안내를 살펴보고, 운영 중 필요한 절차는 도움말 안내에서 확인할 수 있습니다. 모델 변경이나 요금 변경이 생기면 관련 평가와 계산만 다시 검증하면 됩니다.
자주 묻는 평가 질문
모델 선택은 한 번의 점수로 끝나지 않습니다. 평가 결과가 실제 업무와 맞는지, 측정 방식이 공정한지, 팀의 검토 비용까지 반영했는지 확인한 뒤 적용 범위를 정하세요.
코드 생성 결과의 신뢰도
모델이 바뀌어도 같은 기준으로 판단할 수 있도록 저장소 상태와 테스트 조건을 고정하세요. 특히 테스트 통과와 결함 심각도를 분리해야 합니다. 기존 테스트가 통과해도 요구사항의 핵심 동작이 검증되지 않을 수 있기 때문입니다. 대표 과제에서 반복적으로 기준을 충족하는지 확인하고, 결과를 프롬프트와 모델 식별자에 연결해 두면 재평가가 쉬워집니다.
코딩 속도의 공정한 측정
응답을 기다리는 시간, 생성 완료까지 걸린 시간, 사람이 검토하고 수정한 시간을 별도로 기록하세요. 동일한 과제라도 입력 자료나 실행 환경이 달라지면 시간을 직접 비교하기 어렵습니다. 같은 조건에서 반복해 변동을 살피고, 도구 호출이나 테스트 실행을 시간에 포함했는지 기록해야 합니다. 그래야 빠른 출력과 빠른 작업 완료를 구분할 수 있습니다.
경험: 작은 평가 과제에서 한 후보가 통과 기준을 만족하더라도 복잡한 저장소 작업까지 같은 결과를 낸다고 확대 해석하지 마세요. 적용 범위를 과제 유형으로 나누면 실패 원인과 비용을 더 정확히 찾을 수 있습니다.
클라우드 API만 쓰면 초기 장비 관리 부담은 적지만, 호출료와 사용 제한을 계속 살펴야 하고 코드 맥락을 외부 서비스로 보내는 정책 검토도 필요합니다. 반대로 자체 장비는 구매와 유지 관리가 따르고, 단기간 시험을 위해 마련하면 활용도가 낮을 수 있습니다. 장기적으로 일정한 고부하를 처리하거나 물리 장비가 꼭 필요한 경우에는 구매나 자체 운영을 검토하는 편이 낫습니다. 여러 모델과 개발 환경을 단기간 검증하려는 단계라면 Kvmjet의 맥 대여로 시험 환경을 마련하는 선택도 가능합니다. 먼저 이 글의 같은 과제 평가를 적용하고, 운영 방식은 Kvmjet 안내에서 비교해 보세요.
인공지능 코드 검증을 위한 전용 맥 환경을 마련해 보세요
Kvmjet의 실제 맥 미니 기반 원격 환경에서 생성된 코드를 실행하고 빌드 결과를 직접 확인합니다.
전용 자원을 활용해 작업 환경을 분리하고 성능과 처리 시간을 일관된 기준으로 비교합니다.