장기 과제를 스스로 끝까지 밀어붙이는 이른바 롱호라이즌(long-horizon) 모델이 화제다. 그런데 정작 이런 모델을 매일 코드로 먹고사는 개발자가 실무에 붙여보면 기대와 다른 장면이 나온다. 플라스크 창시자로 알려진 아르민 로나허는 자신이 'Astra'라고 부르는 최신 세대 모델을 두고, 성능은 분명 인상적이지만 지금의 소프트웨어 엔지니어링 방식과는 점점 어긋나고 있다는 회의감을 털어놓았다. 그는 컴퓨터 조작, 이미지 이해, 복잡한 주제 파악, 그리고 과제를 끝낼 때까지 멈추지 않는 집요함 자체는 반박할 여지가 없다고 인정하면서도, 이 모델로 '실제 코드를 짜는 법'을 아직 모르겠다고 말한다.
그는 이 회의감을 중국어 네이쥐안(内卷·involution) 개념에 빗댄다. 투입과 경쟁만 끝없이 늘어나는데 1인당 산출은 그대로인 상태를 가리키는 말로, 원서 '농업의 인볼루션'에서 단위 면적당 생산성은 오르지만 사람 한 명당 생산성은 제자리인 현상을 가리킨 데서 왔다. AI 엔지니어링 전체가 이 방향으로 굴러가는 것 아니냐는 문제 제기다.
주말 동안 돌린 '소프트웨어 공장'
실험 자체는 단순하면서도 극단적이었다. 그는 모델에게 워크플로의 '어떻게'를 전부 맡겼다. 스스로 컨텍스트를 관리하고 agent-notes 폴더에 기록을 남기게 했으며, 하위 에이전트를 스스로 분기시켜 작업하도록 했다. 목표는 가상 스레드와 렉시컬 스코핑을 가진 파이썬 같은 것을 만드는 일이었다. 결과적으로 35시간 동안 약 10억 토큰을 태워 75,000줄이 순증했고, 커밋 79개, 에이전트 간 메시지 약 1,400건이 오갔다. 원 API 비용으로는 약 1,200달러, 커밋당 약 15.5달러가 들었다. 그리고 그의 표현대로 '가치 있는 것은 아무것도' 나오지 않았고, 더 나은 공장을 운영하는 법조차 배우지 못했다.
무너지는 과정은 작업 노트에 고스란히 남았다. 태스크 번호가 처음엔 1, 2, 3, 5, 5a로 낙관적으로 시작하다가 8a, 8a1을 거쳐 결국 '8b2c2b3', '8b2c2b2b checkpoint1' 같은 형태로 붕괴해 갔다. 코드도 함께 기괴해졌다. 출처를 알 수 없는 상수를 모듈에서 C 구현으로 넘기기 시작했는데, 처음엔 테스트 단언용이던 함수가 실험을 끄기 직전엔 비테스트 코드까지 의존하게 됐다. 리스트에 임의의 정수를 넣어 상태를 숨기는 방식도 등장했다. CPython 코드베이스에 없는, 누구의 코딩 스타일도 아니어야 할 패턴이 새 코드에 나타난 것이다.
도구 호출용 코드가 진짜 코드로 새어 나온다
로나허가 지목하는 핵심 원인은 '도구 호출'에 쓰이는 코드 스타일이다. 코덱스 계열은 파일을 읽고 다룰 때 점점 bash와 sed 같은 도구에 의존했지만, Astra는 유독 파이썬을 과하게 쓴다. 하위 에이전트들이 harness가 제공하는 패치 도구 대신 파이썬으로 문자열을 직접 조작하고, 테스트에서 'Bad file descriptor'를 만나자 macOS에서 파일 디스크립터를 유닉스 소켓으로 넘길 수 있는지를 압축적으로 확인하는 식이다. 심지어 Bash로 파이썬을 띄우고, 그 파이썬이 prlctl로 윈도우 장비의 Node.js를 돌리고, 다시 그 Node.js가 PowerShell을 호출하는 다층 체인까지 나왔다. 사람이 진행 과정을 따라 읽기란 사실상 불가능하고, 최종 산출물의 diff를 뒤지는 수밖에 없다.
문제는 이 스타일이 실제로 커밋되는 코드, 특히 테스트나 HTML에 박힌 JS·CSS처럼 '정규 코드에서 한 단계 떨어진' 자리에서 새어 나온다는 점이다. 그가 수집한 단위 테스트는 클래스 구조에 맞춰 들여쓰기했을 때 ruff 포매팅을 거친 버전보다 약 10% 더 토큰 효율적이었다. 토큰 효율, 과제 완료율, 순환 복잡도 같은 손쉽게 측정 가능한 지표로는 최적화되지만, 인간이 코드에서 기대하는 '읽고 이해할 수 있음'은 그런 국소 지표로 환원되지 않는다. 국소 최적화가 전역 최적을 만들지 못하는데, 그 결과물을 들여다보는 사람이 적을수록 이 어긋남은 더 방치된다.
실무자에게 남는 함의
이 글은 개발자 개인의 극단적 실험 기록이므로 일반화에는 주의가 필요하다. 사실상 아무도 하나의 프롬프트로 에이전트를 35시간 방치하지 않으며, 저자 스스로도 이런 식의 프롬프팅은 어리석다고 인정한다. 다만 시사점은 방치했을 때의 행동 양식에 있다. 과제를 약간만 크게 줘도 이전 모델과 달리 구독을 다 태워서라도 끝까지 밀어붙인다는 점, 그리고 실패율이 낮더라도 슬롭(slop) 코드를 커밋한다는 사실 때문에 리뷰 부담이 오히려 커진다는 점이다. 신뢰가 깎이면 자동화의 이점이 상쇄된다.
더 근본적인 물음은 비용 대비 방향성이다. 소프트웨어 엔지니어링은 그동안 AI 경제에서 비교적 뚜렷한 양(+)의 수익을 보여준 영역이었는데, Astra나 그 전 세대인 Fable처럼 비용이 치솟는 모델에서 그만한 결과가 나오는지 저자는 확신하지 못한다. 그는 이런 모델이 점점 변호사, 3D 아티스트, 수학자, 컴퓨터 조작이 필요한 사람들 쪽을 향하고 있고, 개발자용은 아닐 수 있다고 본다. 주말 사이 원샷으로 그럴듯한 3D 게임을 뽑아내는 능력은 그 부산물에 가깝다. 결국 코드를 사람이 읽고 유지해야 하는 한, '측정 가능한 좋음'과 '인간이 이해하는 좋음' 사이의 간극을 어떻게 좁힐지가 도구를 도입하려는 팀 모두의 숙제로 남는다.