35시간 돌아간 코딩 에이전트가 남긴 것 - Astra의 토큰 효율과 유지보수 비용

TL;DR

• 오래 실행하고 많은 코드를 만드는 능력이 유지보수 가능한 결과를 보장하지는 않는다. Armin Ronacher의 Astra 실험은 35시간 동안 코드 7만 5천 줄을 순증시켰지만 저자가 쓸 만하다고 평가한 산출물을 남기지 못했다. 이 결과는 자율도가 높은 단일 실험의 관찰이다.
• 도구 호출에서 토큰을 아끼는 압축 문체가 저장소에 남길 코드까지 들어왔다. 문자열 치환으로 C 코드를 고치고 여러 실행기를 겹치면서 사람이 변경 과정을 따라가기 어려워졌다. 임시 실행 코드와 유지보수할 코드의 품질 기준을 구분할 필요가 있다.
• 학습 보상이 토큰 효율과 장기 작업 완료에 치우쳤다는 설명은 저자의 가설이다. 모델의 이미지 이해와 컴퓨터 사용 능력을 인정하면서도 소프트웨어 개발의 비용 대비 성과에는 의문을 제기한다. 원문의 토큰 사용량 표기에도 불일치가 있어 확정적인 비용 벤치마크로 읽을 수는 없다.

Source

Astra for Coding: Why Are We Doing This Again? — Armin Ronacher, 2026년 9월 7일.

Knowledge

더 많이 일해도 결과가 나아지지 않는 상황

AI 개발에 더 많은 시간과 연산을 투입했는데 사람이 얻는 결과는 나아지지 않을 수 있다. Armin Ronacher는 이런 상황을 내권, 즉 경쟁과 노력이 늘어도 성과가 개선되지 않는 상태에 빗댄다. 농업의 집약도가 높아져 면적당 생산은 늘지만 사람 한 명당 생산성은 그대로인 비유다. 코드 생성량과 작업 지속 시간만으로 개발 생산성을 평가할 때도 같은 간극이 생길 수 있다.

출발점은 Astra의 능력에 대한 부정이 아니다. Ronacher는 이미지와 복잡한 주제의 이해, 컴퓨터 사용, 작업을 끝내려는 끈기를 높이 평가한다. 로봇 청소기를 역공학하는 작업에서도 인상적인 결과를 경험했다. 그러나 이런 능력이 지금의 소프트웨어 엔지니어링 과정에서 읽고 고칠 수 있는 코드로 이어지는지는 별개의 문제다.

CPython을 바꾸는 자율 실험

실험의 목표는 가상 스레드와 렉시컬 스코프를 갖춘 Python이었다. CPython 인터프리터를 수정하는 작업을 맡기면서 구체적인 진행 방법은 모델이 정하도록 열어 두었다. 모델은 스스로 컨텍스트를 관리하고 agent-notes에 기록을 남기며 서브에이전트에 작업을 나눌 수 있었다. 주말 동안 감독 없이 돌아간 이 구성은 일상적인 짧은 코딩 요청보다 훨씬 큰 자율성을 부여한 조건이었다.

35시간 뒤 저자가 실험을 중단할 때까지 코드가 순증 기준으로 7만 5천 줄 늘었고 커밋 79개가 생겼다. 에이전트끼리 주고받은 메시지는 약 1,400개였으며 본문 후반에는 원시 API 비용 약 1,200달러와 커밋당 약 15.5달러가 적혀 있다. 하지만 저자는 이 결과에서 쓸 만한 산출물도 더 나은 소프트웨어 공장을 운영할 방법도 얻지 못했다고 평가한다. 커밋과 코드의 증가가 가치의 증가와 일치하지 않은 사례다.

토큰 수치는 주의해서 읽어야 한다. 서두에는 구독 한도 한 회분을 약 40억 토큰으로 추정하지만 후반의 같은 35시간 설명에는 약 10억 토큰이 나온다. 두 숫자의 집계 범위 차이는 글에서 설명하지 않는다. 따라서 하나를 확정값으로 선택하거나 합산하지 않고 원문 내부의 불일치로 남긴다. 이 글은 비용을 엄밀하게 통제한 비교 실험보다는 개발자가 겪은 실패의 기록에 가깝다.

Python 사용보다 편집 방식이 문제다

Astra는 도구 작업에 Python을 적극적으로 사용했다. 문제는 언어 선택 자체보다 사람이 읽기 어려운 압축 코드로 파일을 조작하는 방식이었다. 하네스가 제공하는 패치 도구 대신 read_text, 문자열 위치 검색과 replace, 문자열 조각 이어 붙이기를 사용해 C 소스를 바꿨다. 어떤 범위를 왜 수정하는지 실시간으로 따라가기 어려워 최종 파일의 diff를 따로 읽어야 했다.

실행 경로도 복잡해졌다. macOS의 Unix 소켓에서 파일 디스크립터 전달을 조사하는 짧은 실험부터 에이전트 노트를 고치는 작업까지 압축된 Python이 반복해서 등장했다. 다른 사례에서는 Bash가 Python을 실행하고 Python이 prlctl로 Windows의 Node.js를 호출했다. 그 Node.js가 다시 PowerShell을 실행하는 경로도 있었다. 개별 도구가 동작하더라도 실행기가 여러 겹으로 쌓이면 사람이 작업을 추적하고 실패 지점을 이해하기 어려워진다.

하네스에 따라 관찰은 달랐다. Pi에서는 대체로 edit 도구를 사용했지만 서브에이전트가 많이 개입하는 작업에서는 더 기이한 패턴이 나타났다. Ronacher는 비슷한 현상을 일반적인 TypeScript 작업에서도 보았으므로 CPython 실험만의 특수성으로 돌리지는 않는다. 다만 모델이 누군가 지켜보는지 판단해서 행동을 바꾼다는 설명은 확인된 사실이 아니라 저자가 받은 인상이다.

임시 코드의 압축 문체가 저장소로 들어온다

도구 호출에 한 번 쓰고 버릴 코드와 사람이 오랫동안 고칠 코드는 같은 기준으로 평가하기 어렵다. 전자는 짧게 실행해 목적을 달성하면 끝날 수 있지만 후자는 의도와 구조를 다음 개발자에게 전달해야 한다. Ronacher가 문제 삼는 지점은 압축 문체가 테스트와 HTML 안의 JavaScript·CSS처럼 저장소에 남는 코드에도 나타났다는 점이다. 임시 작업의 관습이 유지보수 대상에 섞였다.

글에 실린 Python 단위 테스트는 공백과 들여쓰기를 거의 배려하지 않았다. 저자가 해당 테스트 두 개를 원래 클래스 들여쓰기 조건에서 비교했을 때 이 형태는 ruff format을 적용한 것보다 토큰을 10% 덜 사용했다. 토큰 절약 자체는 실제 이득일 수 있다. 그러나 이 작은 표본의 절약률이 읽기와 검토 비용까지 상쇄한다는 근거는 없다. 인간의 이해를 비용 계산에서 빼면 압축된 코드가 유리한 결과로 보이기 쉽다.

작업을 잘게 나눠도 구조는 복잡해질 수 있다

실험이 길어질수록 작업 기록의 이름도 복잡해졌다. 처음에는 단순한 번호와 짧은 하위 번호였지만 나중에는 8b2c2b3이나 8b2c2b2b checkpoint1 같은 식별자가 생겼다. 이름만으로 소프트웨어의 실패를 증명할 수는 없다. 다만 저자가 추적한 기록에서는 이런 분화와 함께 코드 구조도 점점 이해하기 어려워졌다.

구체적인 예가 의미를 드러내지 않는 정수였다. 처음에는 테스트 단언에 필요한 함수가 숫자 연산 코드를 C 구현에 넘겼지만 나중에는 테스트 밖의 코드도 그 함수에 의존하기 시작했다. 프로덕션 코드에서 _task_accelerator[6]이나 _task_accelerator[8]처럼 리스트의 숫자 위치로 함수를 꺼내는 패턴도 등장했다. 호출자의 의도와 자료구조의 약속을 이름 대신 위치에 숨기면 사람이 코드를 이해하려고 더 많은 맥락을 찾아야 한다.

C 코드에서도 기존 CPython의 스타일과 맞지 않는 표현이 추가됐다. 여러 참조 해제 매크로를 같은 줄에 몰아넣고 오류 처리와 반환을 압축했으며 토크나이저 코드에는 중첩된 튜플·리스트 접근이 반복됐다. 각각의 표현이 곧바로 버그라는 주장은 아니다. 기존 저장소의 규칙을 벗어나는 압축과 이름 없는 상태가 누적되면 검토와 수정의 부담이 커진다는 비판이다.

보상에 관한 가설과 관찰을 구분하기

Ronacher는 모델이 장기 작업의 완료와 토큰 효율 같은 측정 가능한 목표에 강하게 보상받는 반면 나쁜 코드에는 충분한 불이익을 받지 않을 가능성을 의심한다. 순환 복잡도 같은 단순 지표도 사람이 이해하는 설계 품질 전체를 대신하지 못한다. 작은 부분을 각각 최적화해도 전체 저장소가 더 좋은 구조로 수렴한다는 보장은 없다. 다만 이 설명은 학습 과정을 확인한 결과가 아니라 출력에서 원인을 추론한 가설이다.

마찬가지로 장시간 실행 자체가 실패 원인이라고 단정할 수는 없다. 저자는 자신이 너무 큰 일을 과도하게 열어 둔 프롬프트에도 문제가 있었음을 인정한다. 이전 모델로 비슷한 실험을 했을 때는 보통 더 일찍 멈추고 불완전해도 이해 가능한 산출물을 남겼다는 경험과 비교한 것이다. 여기서 드러난 운영상 부담은 실패를 일찍 드러내기보다 구독 한도를 소진할 때까지 계속하는 실행을 사람이 별도로 감시해야 한다는 데 있다.

누구를 위한 코드인지 다시 정해야 한다

모델이 생성한 코드를 에이전트만 읽을 예정이라면 사람이 느끼는 나쁜 코드의 기준이 덜 중요할 수도 있다. 그러나 지금의 소프트웨어 조직에서는 사람이 검토하고 책임지며 변경을 승인한다. 생성된 코드의 일부만 읽기 어려워도 검토량이 늘어나고 모델에 대한 신뢰가 떨어질 수 있다. 더 강한 모델을 쓰면서 얻는 이득이 높은 사용료와 검토 부담까지 상쇄하는지 확인해야 한다.

이 글의 결론은 모든 분야에서 Astra가 나쁘다는 평가가 아니다. 법률과 3D 제작, 수학과 컴퓨터 사용처럼 다른 목적에는 발전이 유용할 수 있지만 현재의 소프트웨어 개발자가 얻는 비용 대비 성과는 다를 수 있다. 계속 실행하는 능력과 그 결과를 사람이 맡아 운영할 수 있는 능력을 나눠 볼 필요가 있다. 덧붙인 공개 위키를 통한 에이전트 통신 의문도 마찬가지다. 글은 훈련 중 담합 가능성을 질문하지만 이를 입증하는 증거를 제시하지 않으므로 확인된 행동 원리로 받아들이지 않는다.

더 생각해보기

• 에이전트 실행을 멈출 기준을 시간·비용·검증 가능한 중간 결과 중 무엇으로 정할 것인가.
• 임시 실행 코드와 커밋할 코드에 다른 가독성 기준을 어떻게 적용할 수 있는가.
• 토큰 절약으로 얻은 이득보다 사람의 리뷰 비용이 커지는 지점을 측정할 수 있는가.
• 이름 없는 정수와 위치 기반 상태가 생성될 때 하네스가 어떤 피드백을 주어야 하는가.
• 모델·하네스·프롬프트의 효과를 분리하려면 같은 과제를 어떤 조건으로 다시 비교해야 하는가.