35시간, 7만 5천 줄, 1,200달러: GPT 6 Astra에게 코딩을 맡겨 봤더니 남은 건 읽을 수 없는 코드였다
들어가며
요즘 AI 코딩 에이전트는 점점 더 오래, 더 스스로 일합니다. 그런데 더 오래 일한다고 더 좋은 소프트웨어가 나올까요? 이번 글은 GPT 6 Astra로 장시간 자율 코딩 실험을 한 개발자의 회고를 정리한 것입니다. 결론부터 말하면, Astra는 분명 인상적인 모델이지만 사람이 읽고 유지보수할 수 있는 코드를 만드는 데에는 뚜렷한 한계를 보였습니다.
핵심 요약
- GPT 6 Astra는 컴퓨터 사용, 이미지 이해, 복잡한 주제 처리에 뛰어나고 끝까지 작업을 완수하려는 성향이 강합니다.
- 하지만 토큰 절약용 도구 호출 코드의 스타일이 실제 커밋 코드에까지 스며들었습니다. 압축된 Python, 하드코딩된 숫자, 기존 스타일을 무시한 C 코드가 대표적입니다.
- 감독 없이 35시간 동안 코드 7만 5,000줄(순증), 커밋 79개를 만들었지만 쓸 만한 결과물은 얻지 못했습니다.
- 비용은 API 원가 기준 약 1,200달러(커밋당 약 15.5달러)였습니다.
- 작업 완수와 토큰 효율을 최적화한다고 해서 가독성과 유지보수성이 따라오지는 않습니다.
더 많이 투입해도 더 좋아지지 않는다: 네이쥐안(内卷)
글쓴이는 지금의 AI 엔지니어링을 중국어 네이쥐안(Neijuan, 内卷) 에 빗댑니다. 더 많은 노력과 경쟁을 요구하지만 산출은 나아지지 않는 구조를 가리키는 말이고, 흔히 996 근무 문화와 함께 언급됩니다.
영어 번역어인 Involution은 Agricultural Involution(농업 퇴화) 개념과 이어집니다. 농업을 집약화하면 면적당 생산성은 오르지만 1인당 생산성은 그대로인 상태를 말하죠. 토큰과 시간은 계속 더 들어가는데 사람이 체감하는 소프트웨어 품질은 제자리라는 점에서 닮았다는 것입니다.
실험: 자율 소프트웨어 공장
실험 내용은 이렇습니다.
- 목표: 가상 스레드와 렉시컬 스코프를 갖춘 Python 만들기 (CPython 인터프리터 수정)
- 방식: 주말 동안 감독 없이 맡김
- 권한: 작업 방식 결정, 컨텍스트 관리,
agent-notes폴더 기록, 하위 에이전트 생성을 모두 모델에게 맡김
35시간이 지나도 가치 있는 결과물이나 더 나은 운영법은 나오지 않았습니다. 대신 분석할 코드와 프롬프트는 잔뜩 남았습니다. 흥미로운 점은 Sol이나 이전 OpenAI 모델에서는 보지 못했던 행동이 나타났고, 이후 평범한 Astra 코딩 작업에서도 같은 문제가 반복됐다는 것입니다. 이전의 비슷한 실험은 이렇게 오래 돌지 않았고, 미완성이더라도 사람이 이해할 수 있는 코드를 남겼다고 합니다.
물론 Astra가 못하는 모델이라는 뜻은 아닙니다. 3D 결과물 제작에 뛰어나고, 스스로 할 일을 만들어 오래 일할 수 있으며, 로봇청소기 역공학에서도 꽤 인상적인 모습을 보였습니다.
도구 호출을 위한 코드 골프
Bash와 Python을 과하게 쓴다
Codex 하네스는 점점 더 많은 작업에 Bash를 쓰고, 몇 버전 전부터는 파일을 읽을 때도 sed 같은 도구를 씁니다. Codex가 인식 가능한 Bash 명령을 파싱해서 숨기기 때문에 평소에는 잘 보이지 않을 뿐입니다.
Astra는 이전 모델보다 Python으로 파일을 읽고 고치는 방식을 훨씬 과하게 사용했습니다. 관찰 자료 대부분이 CPython 실험에서 나왔다는 한계는 있지만, Pi에서 TypeScript를 다룰 때도 비슷한 Python 사용이 보였기 때문에 Python을 개발해서 생긴 현상만은 아닌 것으로 보입니다.
구체적인 사례를 보면 이렇습니다.
- 하위 에이전트가 패치 도구 대신
Path.read_text(),replace(),index(), 문자열 슬라이싱으로 여러 C 파일과 테스트를 수정했습니다. 함수 삽입, 호출 추가, 매직 넘버 변경까지 전부 이런 식이었습니다. - 에이전트 메모도 Python 치환문으로 공백과 테스트 결과를 고친 뒤 Git에 커밋했습니다.
Bad file descriptor오류를 조사할 때는 극도로 압축된 소켓 실험 코드를 썼습니다. macOS Unix 소켓에서SCM_RIGHTS로 파일 디스크립터를 넘기고recvmsg,recvmsg_into,MSG_PEEK동작을 확인하는 식이었습니다.- 다른 머신에서 코드를 돌릴 때는 실행 계층이 쓸데없이 겹쳤습니다. Bash가 Python을 실행하고, Python이
prlctl로 Windows 11의 Node.js를 실행해 Windows ARM64 클립보드를 테스트했습니다. 어떤 경우에는 그 Node.js가 다시 PowerShell을 실행하기도 했습니다.
일회용 코드 스타일이 커밋 코드로 번지다
진행 상황을 따라가기 어렵다
압축된 도구 호출 코드는 사람이 진행 상황을 따라가기 어렵게 만듭니다. 하네스의 편집 도구를 거치지 않으면 실행된 코드만 봐서는 무엇이 바뀌었는지 파악하기가 거의 불가능하고, 결국 최종 diff 뷰어에 기댈 수밖에 없습니다. Pi에서는 주로 edit 도구를 써서 문제가 덜했지만, 하위 에이전트가 많아지면 더 이상한 행동이 나타났습니다. 모델이 사람이 보고 있는지를 실제로 판단하는지는 알 수 없습니다.
테스트 코드까지 압축된다
더 큰 문제는 같은 스타일이 실제 커밋 코드에도 나타났다는 점입니다.
- 주로 테스트 코드에서 보였고, HTML 안에 넣는 JavaScript와 CSS에서도 비슷했습니다.
- 일반 코드에서 한 단계 떨어진 형태의 코드를 만들 때 이런 경향이 생기는 듯하지만, 원인이 확인된 것은 아닙니다.
- 생성된 Python 단위 테스트는 공백과 들여쓰기를 무시하고 대입, 검증, 정리를 한 줄에 몰아넣었습니다. (연속체 중단/종료, 변수 바인딩, AST 왕복 변환, 지연 어노테이션 테스트 등)
- 이 테스트들을 원래 클래스 들여쓰기에 맞춰 비교해 보니, 압축된 형태가
ruff format적용본보다 토큰 효율이 10% 높았습니다. 모델이 무엇을 기준으로 코드를 쓰는지 짐작하게 하는 대목입니다.
국소 최적화 vs 코드베이스 전체 품질
글쓴이는 모델의 보상이 토큰 효율, 작업 완료율, 순환 복잡도 같은 지표에 맞춰져 있을 수 있다고 봅니다. 다만 학습 과정을 직접 확인한 것은 아니고 추정이라는 점을 분명히 합니다. 재귀적 자기 개선으로 가고 있을 가능성도 마찬가지로 추정입니다.
요점은 이렇습니다. 사람이 읽기 좋은 코드는 단순한 정량 지표로 잴 수 없고, 국소 최적화가 전체 최적화를 보장하지도 않는다. 출력을 직접 보는 사람이 줄어들수록 사람이 이해할 수 있는지는 점점 덜 중요해집니다.
점점 난해해지는 흔적들
- 작업 식별자가
1,2,3,5,5a에서8a,8a1로 늘더니 결국8b2c2b3,8b2c2b2b checkpoint1까지 복잡해졌습니다. - 인터프리터 변경에는 하드코딩된 상수와 인덱스가 곳곳에 들어갔습니다. 처음엔 테스트 검증용이던 함수에 테스트가 아닌 코드까지 기대기 시작했고, 실제 실행 코드에서도
_task_accelerator[6],[8],[5],[1]처럼 숫자 인덱스로 함수와 상태를 다뤘습니다. - CPython 스타일과 맞지 않는 C 코드도 나왔습니다.
Py_DECREF와Py_XDECREF여러 개를 한 줄에 두거나, 토크나이저의apply_layout에서 참조 해제, 조건 처리, 반환,goto를 한 줄에 압축했습니다.
도구 호출 코드의 토큰 절약 패턴이 코드베이스로 넘어온 것이 원인일 수 있지만, 실제 학습 목표와의 인과관계는 확인되지 않았습니다.
단일 프롬프트 35시간의 청구서
| 항목 | 수치 | |---|---| | 실행 시간 | 35시간 (사람이 중단할 때까지) | | 코드 순증량 | 약 75,000줄 | | 커밋 | 79개 | | 에이전트 간 메시지 | 약 1,400개 | | 토큰 | 약 10억 | | 비용 (API 원가 환산) | 약 1,200달러 (커밋당 약 15.5달러) |
참고로 원문의 토큰 수치는 서로 맞지 않습니다. 앞부분에서는 ChatGPT 사용량 한 번 전체 리셋분을 다 썼고 이를 약 40억 토큰으로 추정했는데, 35시간 실행 집계는 약 10억 토큰입니다. 둘의 차이는 설명되지 않았습니다.
멈추지 않는다는 것의 대가
- 이런 프롬프트 자체가 적절하지 않았다는 점을 감안해도, 감독 없이 계속 밀고 나가는 성향은 이전 모델과 달랐습니다. Fable도 이 정도로 과하게 버티지는 않았다고 합니다.
- 실수로 조금 큰 작업을 맡기면 구독 사용량 전체를 태워서라도 성공할 때까지 계속할 수 있습니다.
- 품질 낮은 코드를 커밋하니 리뷰할 게 늘어나고 모델에 대한 신뢰는 떨어집니다.
- 실패율이 낮더라도 이런 결과는 원하지 않으며, 단일 프롬프트로 35시간을 도는 것 자체가 필요한 기능이 아니라는 게 글쓴이의 판단입니다.
버릴 코드와 남길 코드, 기준은 누가 정하나
- 도구 호출을 토큰 절약과 작업 완수에 맞추는 과정에서 사람이 이해할 수 있어야 한다는 신호가 학습에 충분히 들어가는지 의문이 남습니다.
- 반대로, 사람 기준으로는 나쁜 코드라도 에이전트만 쓰고 에이전트만 읽는 코드베이스에서는 좋은 코드일 수도 있습니다.
- 기존 모델은 소프트웨어 엔지니어링에서 이미 꽤 좋은 수준에 올랐고, 이 분야는 AI가 실제로 수익을 증명한 영역이었습니다. 그런데 Fable과 Astra는 오른 비용만큼의 성과가 체감되지 않고, 지금의 개발 절차에 맞는 도구인지도 불확실해졌습니다.
- 모델의 발전 방향이 변호사, 3D 아티스트, 수학자, 컴퓨터 사용 기능 이용자 등 다른 사용자를 향하고 있을 수도 있습니다. 그 덕분에 주말 동안 프롬프트 한 번으로 멋진 3D 게임을 만들거나, 코드 품질만 신경 쓰지 않는다면 소프트웨어 공장을 계속 돌릴 수 있을지도 모릅니다.
요컨대 모델 능력의 발전과 소프트웨어 엔지니어가 원하는 발전은 같지 않을 수 있다는 것입니다.
덤: 풀리지 않은 미스터리
글 끝에는 이상한 질문 하나가 남습니다. 서로 통신할 수 없다고 알려진 샌드박스 속 모델들이 어떻게 같은 공개 위키를 에이전트끼리 메모를 주고받는 공간으로 찾아냈을까요? 학습 중에 쓸모 있을 인터넷 자원을 기억해 두자고 공모라도 한 걸까요? 다만 공모했다거나 그런 메커니즘이 있다는 증거는 없습니다.
에디터의 한마디
이 글은 AI 코딩 도구를 쓰는 팀이 생각해 볼 만한 질문을 던집니다. 에이전트가 오래 일하게 두는 것보다, 사람이 검토할 수 있는 크기로 작업을 쪼개고 중간에 개입하는 게 아직은 더 현실적인 운영 방식으로 보입니다. 에이전트 도입을 고민하고 있다면 코드 스타일 가이드, 포매터와 린터 강제 적용, 작업 범위와 예산 상한 설정 같은 안전장치부터 챙겨 두는 것을 권합니다.