아스트라 성능 저하 체감에 계획은 아스트라·실행은 오푸스로 나눈다

16일 오후 더배러에서는 코딩 에이전트 아스트라(Astra)의 체감 성능 저하를 두고 대응법을 나누는 대화가 이어졌다. 한 참여자가 아스트라가 예전만큼 지시를 끝까지 수행하지 않고 에이전트 기능이 눌린 것 같다고 운을 떼자, 오후 3시 58분 다른 참여자가 원인을 추정하며 자신의 대응을 밝혔다.

수요는 많은데 컴퓨팅 파워는 한정되어있어서 성능을 떨어뜨린 것이 아닐까 싶습니다.

그는 아스트라 배포 초기와 현재의 성능 차이가 크다는 반응들을 봤고 본인도 성능 저하를 체감해, 다시 클로드 페이블(Fable)을 메인 에이전트로 쓰고 있다고 전했다.

저도 성능 저하 심해진거 체감하고 다시 Fable을 메인 에이전트로 쓰고 있어요.

또 다른 참여자도 그날 아스트라의 capacity(처리 용량) 오류가 잦았다고 거들었다. 배포 초기와의 성능 비교, 그리고 그날의 capacity 오류 빈도까지 구체적인 근거가 함께 제기됐다는 점은, 이 불만이 막연한 토로가 아니라 관찰에 기반한 진단에 가깝다는 것을 보여준다. 오후 4시 3분에는 다른 참여자가 토큰 소모 부담을 이유로 든 구체적인 절충안을 공유했다.

아스트라 토큰 소모가 너무 심해서 계획만 아스트라로 짜고

계획 수립은 아스트라에 맡기되 실제 개발은 오푸스(Opus, 클로드의 상위 모델)로 넘긴다는 것이다. 저녁으로 넘어가며 대화는 모델 간 인수인계 정확도를 높이는 방법으로 이어졌다. 오후 5시 18분, 한 참여자는 계획서를 다른 모델에 바로 넘기면 오해가 생긴다며 간단한 보완책을 소개했다.

처음 지시문 보낼 때 상대모델이 제대로 이해했는지 질문검수하는 단계 딱 하나만 추가했는데 미친 효율이 나왔읍니다 ㅎㅎ 강추해유

19분 뒤 다른 참여자는 이 검수 단계를 아예 자동화한 방식을 덧붙였다.

지시문을 만든 후에 hook을 발동해서 스킬로 자동으로 검수하게 진행해놨는데

그는 "당신이 보기에 이 것으로 충분히 개발이 가능한가"를 기준으로 훅(Hook, 특정 시점에 자동 실행되는 스크립트)이 지시문을 검수하게 한 뒤, 다음 세션에서 오푸스에게 넘긴다고 설명했다. 성능 저하 체감이 메인 에이전트 교체론에서 끝나지 않고 계획과 실행을 모델별로 나누고 그 사이에 질문검수 단계를 끼워 넣는 구체적 노하우로 이어졌다는 점은, 이 커뮤니티가 도구 불만을 작업 방식 개선으로 소화하고 있음을 시사한다.

한 참여자가 수동으로 되묻는 방식을 소개하자 곧이어 다른 참여자가 이를 hook으로 자동화한 방식을 덧붙인 순서도 눈에 띈다. 개별 노하우가 공유되자마자 서로 다른 참여자의 손에서 한 단계 더 다듬어지는 흐름은, 이 방의 문제 해결이 한 사람의 발견에서 끝나지 않고 곧바로 다음 참여자의 개선으로 이어지는 식으로 굴러가고 있음을 보여준다.

이 화두에는 9명이 참여해 29건의 메시지를 남겼다.