같은 날 나온 두 글 — 파레토 프런티어와 읽을 수 없는 코드
같은 날 나온 두 글 — 파레토 프런티어와 읽을 수 없는 코드
코딩 모델의 경쟁이 비용 대비 점수로 수렴할 때, 점수가 세지 않는 비용은 누가 지불하는가?
도입
2026년 9월 11일 해커뉴스 1면에 코딩 에이전트를 다룬 글 두 개가 나란히 올라왔다. 하나는 Cognition의 「SWE-2 소개: 파레토 프런티어를 밀어내기」로 427점을 받았다. 다른 하나는 Armin Ronacher의 「Astra for Coding: 우리는 왜 또 이걸 하고 있나」로 388점을 받았다.
전자는 숫자의 글이다. SWE-2는 FrontierCode 1.1 Main에서 50.0%를 기록해 Fable 5.1과 1점 이내이면서 64% 저렴하다고 밝힌다. 발표문은 RL을 처음으로 다조(多兆) 파라미터 영역까지 확장했으며, 핵심 추가분은 모든 추론 노력 수준을 한 번의 실행으로 학습시키는 RL 알고리즘이라고 설명한다. 비용-성능 프런티어 전체를 함께 끌어올렸다는 주장이다. 기반 모델은 Kimi K3로, 이미 에이전틱 코딩을 위한 광범위한 RL을 거친 2.8조 파라미터 모델이다.
후자는 숫자가 없는 글이다. Ronacher는 주말 동안 「소프트웨어 공장」을 돌렸다. 모델이 워크플로의 방식을 전적으로 결정하도록 두고, 자기 컨텍스트를 관리하며 agent-notes 폴더에 기록을 남기고 서브에이전트를 띄우게 했다. 목표는 가상 스레드와 렉시컬 스코핑을 갖춘 Python을 만드는 것이었다. 그는 ChatGPT 토큰 한 사이클 분량을 통째로 태웠고, 그것은 약 40억 토큰이었다고 적는다. 그리고 35시간 뒤, 이 공장은 가치 있는 것을 아무것도 내놓지 않았으며 더 나은 공장을 운영하는 법도 가르쳐 주지 않았다.
두 글을 나란히 읽으면 질문이 생긴다. 벤치마크는 오르는데, 왜 이런 보고가 같은 날 같은 자리에 올라오는가.
발표된 숫자와 그 숫자의 출처
먼저 Cognition이 제시한 표를 그대로 옮겨 두자. SWE-2 기준으로 FrontierCode 1.1 Main 50.0%, DeepSWE 1.1 73.0%, Terminal-Bench 2.1 92.8%, Terminal-Bench 4 27.3%다. 비교 대상은 Kimi K3(44.2 / 68.5 / 88.3 / 21.5), Grok 4.6(48.0 / 67.5 / 88.4 / 20.3), Fable 5.1(50.9 / 67.4 / 91.4 / 55.8), GPT-5.6 Sol(47.5 / 72.7 / 88.8 / 37.3), GPT-6 Astra(53.3 / 74.1 / 89.9 / 57.9), 그리고 직전 세대 SWE-1.7(42.0 / 37.7 / 81.5 / 7.6)이다.
표를 가로로 읽으면 발표문의 주장이 보인다. SWE-2는 두 벤치마크에서 점수와 비용 모두 SWE-1.7과 Grok 4.6을 이기고, GPT-5.6 Sol 및 Fable 5/5.1과 대등한 점수를 훨씬 낮은 가격에 낸다. 하지만 표를 세로로 읽으면 다른 것이 보인다. Terminal-Bench 4에서 SWE-2는 27.3%인데, Fable 5.1은 55.8%, GPT-6 Astra는 57.9%다. 두 배 차이다. 발표문 스스로 제시한 표 안에 「일부 과제에서는 프런티어와 여전히 멀다」는 사실이 들어 있다.
해커뉴스의 첫 반응들도 이 지점을 겨눴다. 한 이용자는 FrontierCode가 Cognition 자체적으로 만든 벤치마크라는 점을 짚었고, 이 모델이 같은 날 출시된 DeepSeek v4.1 Flash보다 모든 면에서 못한 듯 보인다고 덧붙였다. 제출자 계정이 매우 새것이라 자기 홍보가 의심스럽다는 말도 함께였다(@harmonic18374). 자사 벤치마크에서 자사 모델이 프런티어에 근접한다는 주장은 구조적으로 검증력이 약하다. 표의 맨 왼쪽 열 이름이 회사 이름과 같을 때, 그 열은 측정이 아니라 정의에 가까워진다.
다른 이용자는 기대치를 조정하는 쪽이었다. SWE 작업에서 모델 성능은 들쭉날쭉할 것으로 예상하며, 적어도 모델 이름에서 그것을 인정하고 있다는 것이다. 이미 증류된 모델로부터 다시 증류한 것이지만, 64% 저렴하다는 수치가 유지된다면 그래도 가치가 있을 수 있다고 봤다(@airstrafer). 이 표현을 두고 용어 논쟁이 이어졌는데, 그 자체가 유익하다. 한 이용자는 증류란 교사 모델의 가중치를 갖지 않고 교사의 답변만으로 작은 모델을 가르치는 것이고, 파인튜닝은 원본 모델의 가중치를 실제로 가진 상태에서 다르게 답하도록 훈련시키는 것이라고 정리했다(@FergusArgyll). 다른 이용자는 더 엄밀하게, 증류는 교사 모델의 토큰별 로짓을 요구하며 실무적으로는 모델 자체를 보유한다는 뜻이고, 앞의 설명은 그냥 합성 데이터라고 바로잡았다(@Bolwin).
용어가 중요한 이유는 이것이 SWE-2의 정체를 결정하기 때문이다. 발표문에 따르면 SWE-2는 Kimi K3에서 사후 학습되었고, RL이 많은 벤치마크에서 5~6점을 더하며 K3의 비용-성능 프런티어 전체를 이동시켰다. 즉 이것은 기반 모델을 만든 작업이 아니라 남이 만든 기반 모델 위에 RL 층을 얹은 작업이다. 그 자체는 정당한 공학이지만, 「프런티어를 밀었다」는 표현이 가리키는 범위는 그만큼 좁아진다.
벤치마크가 세지 않는 비용
이제 Ronacher의 글로 가자. 그의 진단은 점수가 아니라 학습 목표를 겨눈다.
그는 훈련 과정에서 무언가 잘못되고 있다고 의심한다고 적었다. 모델은 장기 과제를 성공시키는 데 대해 크게 보상받지만, 「형편없는 코드」에 대해 벌을 주는 장치는 거의 없어 보인다는 것이다. 그 결과로 나타나는 것이 그가 수집해 둔 출력물이다. 가장 인상적인 사례는 서브에이전트들이 패치 도구를 쓰는 대신 Python의 수동 문자열 조작으로 C 코드를 편집한 경우다. Path(...).read_text().replace(...) 로 헤더 파일의 상수 정의를 바꾸고, s.index(...) 로 찾은 위치에 문자열을 이어 붙여 C 함수를 삽입하는 식이다.
이 관찰은 그만의 것이 아니었다. 해커뉴스에서 여러 이용자가 같은 증상을 보고했다. 한 이용자는 새 모델들이 읽을 수 없고 존재하는 모든 옵션 플래그를 동원한 bash 명령이나 Python 스크립트를 돌리려 한다며, 리뷰가 불가능하고 정규식보다도 덜 읽힌다고 적었다(@Gigachad). 다른 이용자는 도구 선택이 하네스 설정과 얽혀 있다는 점을 짚었다. 표준 읽기/쓰기 도구를 쓰라고 시스템 프롬프트에 덧붙여 두었지만, 특정 모드에서는 도구 구성이 bash 위주 명령을 조장하는 쪽으로 기울더라는 것이다(@chambored, @IceDane). 세 번째 이용자는 결과물의 질을 두고 이렇게 정리했다. 특정 모델은 자신이 하는 여러 작업에서 전반적으로 더 똑똑한 소프트웨어 개발 에이전트지만, GPU 셰이더 같은 것을 쓸 때 나오는 코드는 포맷도 가독성도 전혀 시도하지 않은 상태라는 것이다(@meowface).
여기서 두 글이 만난다. Cognition의 발표문에서 가장 공들여 설명된 기법은 비용 페널티다. 단일 RL 실행 안에서 노력 수준별로 선형 비용 페널티를 적용하고, 각 페널티를 기반 모델 파레토 프런티어의 국소 기울기에 맞춰 조정한다는 것이다. 목표는 실제 사용자 비용을 학습에 최대한 직접적으로 반영하는 것이라고 밝힌다.
훌륭한 설계다. 그런데 여기서 「실제 사용자 비용」은 토큰 비용이다. Ronacher가 지적하는 비용은 토큰이 아니라 리뷰다. 문자열 조작으로 C 코드를 편집한 패치는 토큰을 적게 쓸 수 있지만, 사람이 그 변경을 검토하는 데 드는 시간은 늘어난다. 그리고 그 시간은 어떤 벤치마크에도 잡히지 않는다. 과제가 통과했는가만 채점되기 때문이다.
Ronacher가 이 상황에 붙인 이름이 정확하다. 그는 중국어의 내권(內卷, neijuan)과 영어의 involution을 끌어온다. 원래 농업 내권화는 단위 면적당 생산성은 올리면서 1인당 생산성은 그대로 두는 집약화를 가리킨다. 노력과 경쟁은 계속 늘어나는데 산출은 나아지지 않는 상태다. 지금의 AI가 그렇게 느껴진다는 것이다. 그는 Astra 자체가 대단히 인상적인 모델임을 여러 번 인정한다. 컴퓨터 사용에 능하고 이미지와 복잡한 주제를 이해하며 완수를 향해 집요하다는 것이다. 다만 당장은 실제 소프트웨어 엔지니어링에서 그것과 어떻게 일해야 할지를 모르겠다고 적는다.
무엇을 측정으로 삼을 것인가
실무자에게 남는 문제는 모델 선택이 아니다. 평가 기준이다.
첫째, 벤더 자체 벤치마크와 독립 벤치마크를 분리해 기록해야 한다. SWE-2의 대표 수치가 나온 FrontierCode는 Cognition이 만든 것이다. 이것이 부정행위라는 뜻은 아니다. 다만 그 숫자로 조달 결정을 내릴 때는, 제3자 벤치마크에서의 순위와 자사 벤치마크에서의 순위가 갈리는지 확인해야 한다. 그리고 발표문이 함께 제시한 Terminal-Bench 4의 27.3% 대 55.8% 같은 격차는, 벤더가 숨기지 않고 표에 넣어 둔 정보다. 표의 모든 열을 읽는 것만으로도 상당한 검증이 된다.
둘째, 「저렴하다」의 분모를 확인해야 한다. 64% 저렴하다는 주장은 같은 과제를 같은 횟수에 해결한다는 전제에서만 성립한다. 과제가 스파이크가 심한 영역이라면, 싼 모델을 세 번 돌리는 비용이 비싼 모델을 한 번 돌리는 비용을 넘는다. Ronacher의 사례는 이 계산의 극단이다. 40억 토큰과 35시간을 써서 산출물이 0이었다면, 토큰 단가는 결정에 아무 영향이 없다.
셋째, 리뷰 가능성을 별도 지표로 승격시켜야 한다. 이것이 이번 두 글이 함께 가리키는 결론이다. 팀에서 실제로 측정할 수 있는 형태로 바꾸면 이런 질문들이 된다. 에이전트가 만든 변경 중 사람이 읽고 승인한 비율은 얼마인가. 승인까지 걸린 리뷰 시간의 중앙값은 모델을 바꾼 뒤 늘었는가 줄었는가. 도구 호출이 표준 편집 도구 대신 임시 스크립트로 파일을 고친 비율은 얼마인가. 마지막 항목은 특히 실용적이다. 해커뉴스 논의가 보여 주듯 이것은 하네스 설정으로 상당 부분 통제할 수 있는 변수이며, 통제 가능한 변수는 지표로 삼을 가치가 있다.
전망은 갈린다. 낙관적으로 보면 이 문제는 학습 목표의 문제이므로 학습으로 고칠 수 있다. 코드 품질과 리뷰 용이성에 대한 보상 신호를 넣으면 된다. Cognition이 비용 페널티를 RL에 직접 넣은 것처럼, 가독성 페널티를 넣지 못할 이유는 원리적으로 없다. 비관적으로 보면 그 신호는 자동 채점이 어렵다. 과제 통과 여부는 기계가 판정하지만 「읽을 만한가」는 그렇지 않고, 채점할 수 없는 것은 최적화되지 않는다. 현실적으로는 경쟁이 당분간 지금의 축을 따라 계속된다. 벤치마크 점수와 토큰 단가는 표에 넣을 수 있고 리뷰 시간은 그렇지 않기 때문이다.
결론
Cognition의 발표문은 파레토 프런티어를 밀었다고 말한다. 그 주장은 그들이 선택한 축 위에서는 참일 수 있다. 문제는 축의 선택이다. 능력과 비용이라는 두 축으로 그린 프런티어에는 「사람이 결과를 검토하는 데 드는 비용」이라는 차원이 없다.
Ronacher가 내권화를 끌어온 이유가 여기 있다. 단위 면적당 산출은 계속 오르는데 한 사람이 가져가는 몫은 그대로인 상태. 벤치마크 점수는 매 분기 오르고, 토큰 단가는 내려가며, 그럼에도 주말 내내 40억 토큰을 태운 결과가 0일 수 있다. 이 두 사실은 모순이 아니다. 서로 다른 것을 재고 있을 뿐이다.
당신의 팀이 코딩 에이전트를 평가할 때 어떤 숫자를 보는가. 그 숫자 목록에 「이 변경을 사람이 읽고 이해하는 데 걸린 시간」이 들어 있는가. 들어 있지 않다면, 지금 줄이고 있는 비용이 어디로 옮겨 갔는지는 아직 측정되지 않은 것이다.
출처: