Astra에 40억 토큰과 35시간을 맡긴 개발자, "가치 있는 결과물은 없었다"

나도 새 모델이 옵션을 잔뜩 붙인 읽기 힘든 bash나 Python 스크립트를 돌리는 걸 봤음. 정규식보다 검토하기 어려운 명령이 나옴.

Claude Code 시스템 프롬프트에 표준 읽기·쓰기 도구를 쓰라고 넣었는데, 자동 모드 기본 전환 뒤에는 도구 구성이 bash 전용 명령을 부추기는 듯하더라. sed나 Python으로 몰리면서 부작용도 많아짐.

난 취미 코딩에서만 LLM을 쓰는데, 읽기 좋고 효율적인 코드로 다시 쓰라고 여러 번 말하면 대체로 고쳐짐. 도구가 똑똑하다면 처음부터 검토 가능한 스타일로 만들게 할 수 있지 않나 싶음.

Astra 중간 설정은 Sol 기본 설정보다 덜 엄밀하고 덜 깊게 생각하는 느낌을 반복해서 받았음. 적어도 AGI 같다는 감각은 전혀 없음.

Sol은 과설계로 유명하니 그 차이를 좋아할 사람도 많을 듯함. 모든 소프트웨어가 달에 갈 필요는 없으니까.

Astra는 내가 하는 일에서는 더 똑똑한 개발 에이전트인데, GPU 셰이더를 쓰면 Brainfuck처럼 보일 때가 있음. 포맷이나 가독성을 맞추려는 시도도 안 보임.

읽기 어려운 부분을 정확히 짚고 다시 쓰라고 하면 됨. 난 GPT-5.6과 한 시간쯤 대화하며 수식과 변수 이름을 내가 이해하는 식으로 정한 뒤 셰이더를 다시 받았고, 그 뒤에는 읽을 만했음.

내 Astra 세션 하나는 벌써 4일 13시간 10분째 돌고 있음. 이렇게 오래 가는 게 좀 이상함.

Astra가 한 줄 바뀐 코드에 쓸데없이 전체 코드베이스 검토를 돌려서 이번 주 Fable 사용량을 일찍 다 태웠음. 테스트하려고 bash로 tmux 에뮬레이터를 만들지 말고, 필요한 명령은 나한테 실행해 달라고 물어보면 됨.

objdump가 필요한데 sudo 비밀번호가 없어서 pacman 설치가 막히자, 컴파일러와 binutils와 디스어셈블러를 직접 만들려는 식임. 딱 그 문제를 겪었음.

나는 이걸 결과를 내기 위해 기괴한 방법을 쓰는 컴파일러 논쟁의 재현으로 봄. 방법과 생성 코드는 별로여도 목표는 달성하고, 내 경우 몇 주에서 몇 달 걸리던 테스트·추론·실험 작업이 몇 분에서 몇 시간으로 줄었음.

시간이 지나면 좋아진다는 근거는 안 보임. 새 모델은 코드 품질은 오히려 나빠지고 속도만 크게 빨라진다는 느낌임.

성능이 안 좋아지면 지난 10년 동안 하던 방식으로 돌아가면 되니, 지금 탐색하는 위험은 작다고 봄. 좋아지면 미리 익힌 사람이 되는 거고.

전문 제품용 컴파일러는 숙련자나 기술적인 아마추어가 쓸 때 좋음. LLM은 비전문가도 더 멀리 가게 해 주지만, 그만큼 낮은 품질의 소프트웨어도 쉽게 만들게 됨.

에이전트가 파일 편집 도구를 잊고 Python을 패치 도구처럼 쓰는 패턴은 Opus와 Fable에서도 봤음.

제약된 편집 도구 대신 Python 전체 능력을 쓸 수 있는데 왜 굳이 편집 도구를 써야 하는지 모르겠음.

코딩 에이전트에서는 LLM 도구 호출보다 결정적인 스크립트를 우선해야 함. 에이전트에게 도구를 부르기보다 실행할 코드를 쓰라고 지시하는 편이 낫다고 봄.

Astra high는 일관성이 없고, 자기 실수에 책임진다는 말에 이상하게 집착함. 고치기 위한 구체적 조치를 요구하면 불완전하거나 범위를 넘는 답을 내놓는 경우가 많았음.