Cognition SWE-2의 승부처, 코딩 순위표보다 퇴근 시간

핵심 요약

• 벤치마크 점수는 사용 도구와 시도 횟수 등 평가 조건을 함께 봐야 의미가 있습니다.
• 업무용 코딩 AI는 기능 구현뿐 아니라 기존 코드와의 호환성도 평가해야 합니다.
• 비용을 비교할 때는 모델 사용료에 사람의 검토와 재작업 시간을 더해야 합니다.
• 코딩 특화 모델의 경쟁력은 우리 팀의 반복 업무를 얼마나 줄여주는지로 판단할 수 있습니다.

코딩 AI를 고를 때는 높은 벤치마크 점수에 먼저 눈이 갑니다. 정작 업무에서 중요한 건 그 코드로 일을 얼마나 빨리 끝내느냐입니다. Cognition SWE-2와 Fable 5.1, GPT-Astra를 비교할 때도 순위표와 함께 이 점을 살펴봐야 합니다.

1. 점수 옆에 붙은 평가 조건부터 봐야 합니다

벤치마크는 모델의 능력을 비교하려고 정해놓은 시험입니다. 코딩 시험에서는 주어진 문제를 얼마나 잘 해결하는지, 기존 코드의 오류를 제대로 고치는지 등을 측정합니다.

점수만큼 중요한 건 시험을 치른 조건입니다. 모델이 답을 한 번만 제출했는지, 실행 결과를 확인하며 여러 번 고쳤는지에 따라 점수를 다르게 읽어야 합니다. 어떤 도구를 쓸 수 있었고 작업 시간은 얼마나 주어졌는지도 살펴봐야 합니다.

회사 업무에 빗대어 생각하면 이해하기 쉽습니다. 면접 자리에서 바로 작성한 코드와 반나절 동안 실행하고 수정한 코드는 평가 조건부터 다릅니다.

SWE-2, Fable 5.1, GPT-Astra 중 어느 모델이 더 나은지 판단하려면 같은 문제를 풀었는지만 확인해서는 부족합니다. 시간은 얼마나 줬는지, 몇 번까지 시도할 수 있었는지도 비교해야 합니다. 벤치마크로 후보를 추릴 수는 있지만, 그 점수를 우리 팀의 생산성으로 곧바로 환산하기는 어렵습니다.

2. 새 코드를 잘 쓰는 것과 기존 서비스에 잘 넣는 것은 다릅니다

실무에서는 이미 운영 중인 코드에 기능을 추가하는 일이 많습니다. 새 기능이 제대로 동작하는지 확인하는 데서 끝나지 않고, 기존 기능에 어떤 영향을 주는지까지 봐야 합니다.

예를 들어 쇼핑몰에 할인 기능을 추가한다고 해보겠습니다. 할인 금액을 정확히 계산해도 취소 주문의 환불 처리가 어긋나면 작업을 마쳤다고 할 수 없습니다. 기존 결제 흐름과 맞는지, 예외 상황도 처리하는지까지 확인해야 합니다.

코딩 AI를 평가할 때도 이런 업무를 맡겨봐야 합니다. 팀의 코드 작성 방식을 따르는지 살펴보고, 요청과 관계없는 파일까지 고치지는 않는지 확인해야 합니다. 사람이 변경 이유를 이해할 수 있도록 설명하는지도 중요합니다.

특히 눈여겨볼 부분은 수정 범위의 적절성입니다. 작은 오류를 고치면서 주변 구조까지 크게 바꾸면 사람이 검토할 코드가 늘어납니다. 코드를 많이 바꿨다는 이유만으로 일을 더 잘했다고 보기는 어렵습니다.

3. 응답 속도보다 작업 완료까지 걸린 시간을 재야 합니다

모델이 답을 빨리 내놓으면 쓰는 입장에서는 편합니다. 하지만 답이 도착했다고 업무까지 끝나는 건 아닙니다.

가상의 두 결과를 비교해보겠습니다. 한 모델은 5분 만에 코드를 만들었지만, 사람이 검토하고 고치는 데 30분을 썼습니다. 다른 모델은 코드를 만드는 데 10분이 걸렸고, 이후 검토와 수정에는 5분이 들었습니다.

작업을 순서대로 진행했다고 가정하면 총소요 시간은 각각 35분과 15분입니다. 코드를 빨리 만든 모델을 골라도 실제 작업은 더 늦게 끝날 수 있습니다. 실제 모델의 측정값이 아니라, 비교 기준에 따라 결론이 어떻게 달라지는지 보여주는 예시입니다.

비용을 비교할 때도 마찬가지입니다. 모델 사용료가 낮아도 여러 번 다시 시도하고 검토에 오랜 시간을 쓰면 전체 비용은 커질 수 있습니다. 반대로 사용료가 높더라도 사람이 코드를 고치는 시간을 충분히 줄여준다면 선택할 만합니다.

도입을 검토할 때는 응답 시간과 함께 검토·재작업 시간을 기록하는 편이 좋습니다. 그래야 답을 빨리 내놓는 모델과 업무를 빨리 끝내주는 모델을 구분할 수 있습니다.

4. 코딩 특화의 가치는 우리 팀의 작업으로 확인해야 합니다

코딩에 특화했다는 설명만으로 모든 개발 업무에서 더 낫다고 볼 수는 없습니다. 오류를 수정할 때와 기능을 추가할 때 필요한 능력은 다릅니다. 테스트 작성에도 그에 맞는 능력이 필요합니다.

SWE-2의 경쟁력을 살펴보려면 업무를 나눠서 평가하는 게 좋습니다. 최근 팀에서 처리한 작업을 골라 같은 코드와 요구사항을 주고 맡겨보는 겁니다. 비교할 모델에도 같은 도구를 제공하고 시간 한도를 똑같이 정해야 결과를 해석하기 쉽습니다.

먼저 기능이 제대로 동작하는지 확인합니다. 그런 다음 기존 기능에 문제가 생기지 않았는지 살펴보고, 사람이 얼마나 고쳐야 했는지도 확인합니다. 테스트를 통과했더라도 그 테스트가 요청한 동작을 충분히 검사했는지는 따로 검토해야 합니다.

이렇게 비교하면 어떤 강점이 우리 팀에 도움이 되는지 알 수 있습니다. 작은 오류를 자주 고치는 팀이라면, 사람이 손댈 부분을 적게 남기고 그 작업을 마치는 능력을 더 중요하게 볼 수 있습니다. 코딩 특화 모델의 경쟁력도 이런 반복 업무를 얼마나 잘 처리하는지에 달려 있습니다.

SWE-2를 평가할 때는 벤치마크 순위와 함께 실제 작업 시간이 얼마나 줄었는지도 봐야 합니다. 기능을 완성하고 검토를 통과하기까지 든 비용을 확인하면 도입 여부를 더 직접적으로 판단할 수 있습니다. 팀에서 자주 하는 업무를 맡겨보면 모델마다 어떤 차이가 있는지 더 분명하게 확인할 수 있습니다.