AI 엔지니어링은 왜 내卷(Neijuan)에 빠졌는가

이건 지금까지 Astra에 대해 내가 겪은 경험과도 일치한다.

> 나는 훈련 과정에서 뭔가 "잘못"되고 있는 게 아닌가 의심하고 있다. 모델은 장기적 과제를 성공시키는 데 크게 보상을 받지만, 아마도 "엉망인 코드"에 대해서는 거의 벌을 받지 않는 것 같다.

내 추측은 OpenAI와 Anthropic 모두 지난 몇 달 사이에 RL 의제를 "인간 피드백에 따라 유용하다고 평가받기"에서 "장기적 과제를 성공시키기"로 옮겼다는 것이다. 그 결과 에이전트들은 자율적 과제 완수라는 의미에서는 AGI에 더 가까워졌지만, 이상하게도 소통은 형편없어졌다.

그 결과 이들은 장기적 과제, 컴퓨터 사용, 어려운 수학/ARC-AGI 유형 문제 해결에는 놀랄 만큼 뛰어나지만, 함께 작업하기는 점점 더 이상해지고 있다.

> 나는 AI 엔지니어링 전체가 내卷(内卷, 안으로 말린다는 뜻)이라고 점점 더 확신하게 된다. 중국에서 이는 산출을 개선하지 않으면서 점점 더 많은 노력과 경쟁을 요구하는 시스템을 뜻한다. 서구에서 이것이 때때로 나타나는 방식이 바로 996 헛소리다. Neijuan의 영어 표현은 책 『Agricultural Involution』에서 온 "Involution"이다. 농업 인볼루션은 평방미터당 생산성은 높이면서도 1인당 생산성은 그대로 두는 농업의 집약화를 묘사한다.

이건 와닿는다

나는 Sonnet으로 빠르게 만든 프로토타입을 위해 Astra에게 앱을 만들어달라고 요청했다.

이틀过去了 실제 앱에는 실질적인 진전이 없었다. 문서, 스크립트, 워크플로를 만들었고, 모든 PR마다 잔뜩 리뷰를 하고 있다.

나는 그냥 MVP가 필요하다고 말했다.

평범한 시니어 엔지니어라면 그 작업을 훨씬 빨리 끝냈을 것이고, 더 읽기 쉽고 더 높은 품질의 코드로 보장했을 거라고 확신한다. 한편 나는 지금까지 아무것도 아닌 것에 100k 토큰을 가볍게 넘긴 것 같다.

이게 "SOTA"이고 "AGI"라는 게 참 웃긴 세상이다.

나는 이 OAI와 A/ 엔지니어들이 이 모델들을 그렇게까지 칭찬할 만큼 대체 뭘 하고 있는지 진심으로 궁금하다. 나는 Opus 4.5 이후로 어떤 개선도 보지 못했다.

또한, 세상에 나와 있는 어떤 "원샷" 데모에도 전혀 감동하지 않는다. 그건 진지한 소프트웨어 엔지니어링에는 아무 의미가 없다.

나는 Opus와 Fable에서도 정확히 이런 패턴을 관찰했다. 예를 들어, 파일을 편집할 수 있다는 걸 잊고 대신 python 스크립트를 패치 도구로 사용하는 식이다…

AI 엔지니어링에서 일찍 배운 교훈은, 잘 다듬어진 에픽을 에이전트에게 주는 것에 대한 대안은 없다는 것이다. 그냥 '내 제품에 테마를 구현해줘'라고 말하는 대신 구체적으로, 사실 평소보다 더 구체적으로 말해야 한다. 범위에 무엇이 포함되고 무엇이 포함되지 않는지, 심지어 버튼, 이벤트, 레이아웃 수준까지 정확히 말해야 한다.

AI의 도움을 받아 에픽을 다듬을 수는 있지만, 최종 검토는 스펙에 대한 책임을 지고 따라서 뭔가 빠졌을 때 책임질 수 있는 사람이 해야 한다. AI의 응답은 그 특정 에이전트의 출력 토큰에 의해 제한될 것이고, AI가 자신의 실수를 인정하더라도 아무런 불이익도 없을 것이다.

나는 반론을 제기하고 싶다. 나는 새로운 기능을 만들고 버그를 고치는, 이미 자리 잡은 코드베이스에서 일한다. 여기에는 우리 스토리 보드, git, 그리고 몇 가지 다른 mcp에 대한 접근 권한이 있다. 스토리가 명확한 요구사항과 기대치를 갖고 잘 작성되어 있기만 하면, 항상 내가 다양한 자동 및 수동 테스트로 사람으로서 검증하는 양질의 코드를 만들어낸다. 나는 코드를 피어 리뷰한다. 그리고 내 동료들이 그것을 다시 피어 리뷰한다.

나는 두 가지를 알아차렸다. 새 기능은 이전에 내가 걸리던 시간의 최소 절반이 걸리고, 버그는 훨씬 덜 빈번하다. 버그 수정은 훨씬 더 빠르다.

내 결론은 견고한 요구사항, 명확한 맥락, 그리고 주로 계획 단계에서, 또한 검증 단계에서도 사려 깊은 인간의 감독이 필요하다는 것이다

엉망인 것이든 뭐든 컨텍스트 윈도우에 들어가면 전체가 엉망으로 바뀐다.

지금까지 이건 거의 모든 모델에서 겪은 내 경험이다.

컨텍스트는 자기 출력을 먹고 자란다.

일단 그 길로 들어서면, 멈추고 충분한 반례와 원하는 것에 대한 세부사항을 주지 않는 한(즉, 잠재 공간에서 더 나은 지점으로 밀어주지 않는 한), 계속 퇴화한다.

수정할 기회를 얻기 전에 컨텍스트 윈도우가 압축되면 더욱 나빠진다.

장기적 과제 에이전트는 기계 속도로 퇴화할 수 있다.

나는 여전히 짧은 지평의, 잘 명세된 과제를 주면 훨씬 더 나은 결과를 얻는다고 생각한다.

나는 새 모델들이 완전히 읽을 수 없고 존재하는 모든 옵션 플래그를 활용하는, 가관인 bash 명령이나 python 스크립트를 실행하려 한다는 같은 점을 관찰했다.

검토가 불가능하다. 이런 명령은 regex보다 읽기 어렵다.

gpt-6-astra는 정말 골칫거리다. 그 빌어먹을 반짝임을 주려고 "또 하나의 것"으로 끊임없이 스코프를 늘린다. 결과는 결국 조금 더 낫지만 그 대가는 무엇인가? 계산을 해보자.

gpt-5.6-sol: 기본 1배

gpt-6-astra 구독에서 기본 2.5배

그리고 gpt-6-astra는 서브에이전트를 자주 생성하는 경향이 있는데, 종종 gpt-5.6, 5.3-codex 등 온갖 모델을 동원한다. 이건 멋지다. 좋은 코디네이터지만 비용은 더 든다.

그리고 나서 _전체 테스트 스위트_를 반복해서 실행하는 경향이 있다(각각 15분 정도 걸린다). 단지 _하나의 테스트_가 고쳐졌는지 검증하려고, 테스트가 고쳐질 때까지 그렇게 하다가 결국 2시간 정도를 쌓는다.

어제 나는 저장소의 내 변경사항을 최신 업스트림 변경 위로 rebase하는 작업을 할당했다. gpt-5.6-sol은 일관되게 끝에서 끝까지 한 시간 정도 걸렸는데, astra는 6시간 넘게 돌았는데도 끝나지 않았다. 내가 요청하지도 않은 금칠을 할 "또 하나의 것"을 계속 찾아냈다.