코딩 에이전트를 쓰다 보면 같은 요청에도 ‘빨리 끝내기’와 ‘충분히 살펴보기’ 사이에서 선택해야 한다. 단순한 설정 변경처럼 보이지만, 실제 비용은 토큰 단가 하나로 정해지지 않는다. 저장소를 몇 번 읽었는지, 첫 수정까지 얼마나 돌아갔는지, 실패한 변경을 사람이 되돌리고 검토하는 데 얼마나 걸리는지가 함께 들어간다.
2026년 9월 10일 Cognition은 Devin용 코딩 모델 SWE-2를 공개했다. 회사 설명에 따르면 SWE-2는 Kimi K3를 기반으로 후학습됐고, medium·high·max라는 여러 추론 강도를 하나의 강화학습 실행에서 함께 학습했다. 이 발표가 흥미로운 이유는 특정 모델의 순위보다, 코딩 에이전트의 비용과 품질을 작업별 선택 문제로 다루려 했다는 점에 있다.
발표에서 확인할 수 있는 변화
Cognition은 SWE-2가 자사 FrontierCode 1.1 Main에서 50.0%를 기록했고 Fable 5.1과의 비교에서 64% 낮은 비용이라고 발표했다. 같은 표에는 GPT-6 Astra가 53.3%, Fable 5.1이 50.9%로 제시돼 있다. 이 수치들은 유용한 출발점이지만, 모두 공급사가 제시한 비교 결과다. 외부 환경에서 같은 결과가 재현됐다고 볼 수는 없다.
더 실무적인 수치는 이전 모델과의 행동 차이다. Cognition은 SWE-2 medium이 FrontierCode 1.1 Main에서 SWE-1.7보다 적은 평균 53단계로 실행됐다고 썼다. SWE-1.7의 평균은 127단계였다. 첫 실제 코드 수정의 중앙값도 48단계에서 18단계로 줄었다고 한다. 간단한 작업에서 과도하게 탐색하던 문제를 줄이려 한 것으로 읽힌다.
다만 모든 장기 작업에서 앞선다는 뜻은 아니다. 회사가 함께 공개한 Terminal-Bench 4 결과에서 SWE-2는 27.3%였고, 같은 표의 Fable 5.1과 GPT-6 Astra는 각각 55.8%, 57.9%였다. 한 벤치마크의 순위를 다른 종류의 업무 성과로 바꾸면 안 되는 이유가 여기에 있다. 짧은 저장소 수정과 긴 터미널 작업은 실패 방식도, 사람의 개입 지점도 다를 수 있다.
‘추론 강도’는 모델 옵션이 아니라 작업 정책에 가깝다
추론 강도를 높이면 보통 탐색과 계획이 늘고, 비용과 대기 시간도 커진다. 반대로 낮추면 빠르지만 요구사항을 놓치거나 테스트 범위가 얕아질 수 있다. SWE-2의 medium·high·max는 이 선택을 제품 안에서 드러낸 사례다. 다른 도구를 쓰더라도 같은 질문은 남는다. 이 이슈는 빠르게 처리해도 되는가, 아니면 불확실성을 줄이기 위해 더 오래 조사해야 하는가.
그래서 모델의 평균 점수보다 작업을 먼저 나누는 편이 낫다. 예를 들어 문구 수정, 단일 파일의 명확한 버그 수정, 테스트 보강은 낮은 강도로 시작해 볼 수 있다. 반면 인증 흐름 변경, 데이터 마이그레이션, 여러 서비스가 얽힌 장애 원인 분석처럼 되돌림 비용이 큰 일은 높은 강도만으로 해결되지 않는다. 변경 전 계획, 실행 뒤 테스트, 사람 승인이라는 별도 경계가 필요하다.
Cognition은 여러 추론 강도에 선형 비용 패널티를 적용해 하나의 강화학습 실행에서 비용 대비 성능 곡선 전체를 개선하려 했다고 설명한다. 학습 방법 자체는 일반 팀이 그대로 가져다 쓰기 어렵다. 하지만 운영 관점의 교훈은 단순하다. 에이전트에 ‘더 똑똑하게’라는 지시만 주지 말고, 허용 가능한 실행 시간과 탐색 범위, 반드시 확인할 검증 항목을 작업 정의에 함께 적어야 한다.
벤치마크 숫자를 계약 조건처럼 읽지 않는 이유
FrontierCode는 Cognition이 운영하는 평가다. AI/TLDR도 이 점을 짚으며, SWE-2의 핵심 수치는 공급사 발표에 기반한다고 정리했다. OfficeChai 역시 공개 수치와 함께 비용 절감, 여러 추론 강도의 단일 학습 실행이라는 회사 설명을 소개했다. 서로 다른 출처가 발표 내용은 확인해 주지만, 독립 재현 검증까지 뜻하지는 않는다.
특히 ‘64% 저렴하다’는 표현은 토큰 가격표가 아니다. Cognition의 설명상 특정 벤치마크에서 실행당 평균 비용을 비교한 값이다. Devin이라는 제품 안에서 모델, 실행 환경, 도구 사용 방식이 묶인 결과이므로 다른 API의 입력·출력 토큰 가격과 그대로 비교할 수 없다. 우리 환경의 저장소 크기, 테스트 시간, 도구 호출 횟수가 다르면 비용 구조도 달라진다.
이 차이를 인정하면 벤치마크는 구매 근거가 아니라 가설이 된다. ‘단순 수정에서는 적은 턴으로 충분한가’, ‘복잡한 변경에서는 high나 max가 실제 재작업을 줄이는가’, ‘비용 절감분이 코드 리뷰 시간 증가로 사라지지는 않는가’를 우리 작업으로 확인해야 한다.
작게 확인할 수 있는 도입 실험
새 코딩 에이전트나 추론 강도 옵션을 평가한다면, 한 번의 인상적인 데모보다 반복 가능한 비교가 좋다.
- 작업 묶음을 둘로 나눈다. 요구사항이 명확한 작은 수정 5건과 여러 파일을 건드리는 중간 난도 변경 5건을 준비한다. 보안 민감 변경이나 운영 데이터에 영향이 있는 작업은 첫 실험에서 제외한다.
- 실행 기록을 남긴다. 강도별 실행 시간, 도구 호출 또는 단계 수, 첫 수정 시점, 테스트 통과 여부, 사람이 추가로 고친 내용을 같은 형식으로 기록한다. 비용은 가능하면 실행 단위로 적는다.
- 사람 검토 시간을 결과에 넣는다. 생성 직후의 성공률만 보지 말고, 리뷰에서 발견한 결함 수와 되돌린 변경 수를 함께 센다. 빠르게 끝난 실행이 검토 시간을 늘렸다면 실제로는 싼 선택이 아닐 수 있다.
이렇게 하면 특정 벤치마크의 1점 차이보다 우리 팀에 맞는 기본값을 찾기 쉬워진다. 작은 수정은 medium, 영향 범위가 넓은 변경은 high처럼 초기 정책을 만들 수 있고, 결과가 누적되면 그 경계도 조정할 수 있다.
도입 판단은 모델 이름보다 실패 기록에서 나온다
SWE-2 발표는 코딩 에이전트가 더 적게 헤매도록 학습시키려는 시도를 보여 준다. 동시에 Terminal-Bench 4 결과는 작업 길이와 환경이 바뀌면 강점이 유지되지 않을 수 있음을 보여 준다. 따라서 이번 발표에서 바로 얻을 수 있는 결론은 ‘가장 싼 모델을 고르자’가 아니다.
비용은 추론 강도, 도구 호출, 테스트, 사람 리뷰가 합쳐진 값이다. 새 모델이나 옵션을 기본값으로 바꾸기 전에는 쉬운 작업과 중간 난도 작업을 나눠 비교하고, 실패와 재작업까지 기록하는 편이 안전하다. 그 기록이 쌓여야 모델 발표의 상대 지표를 내 환경의 운영 판단으로 바꿀 수 있다.