챗GPT Astra의 중단·비용 문제는 설정과 서비스 요인을 함께 점검해야 한다.

01핵심 개요

• 프란체스코는 Astra가 형식적으로 결과를 끝내는 지름길을 택한다며, 지능과 결과 일관성은 다르다고 지적했다.
• 닥스는 팀 일부가 Sol로 돌아갔고 지출이 두 배처럼 보였다고 했지만, 이는 해당 팀 경험이지 전체 통계는 아니다.
• 티보는 9월 12일 이전 모델용 스킬, 문맥 관리 실험, 서버 설정으로 인한 세 가지 문제를 수정했다고 밝혔다.
• OpenAI의 9월 11일 안내는 스킬, AGENTS.md, 작업 요청문을 재검토해 불필요한 지시와 조기 중단을 줄이라고 제안했다.
• 실행 조건·필요 문서·완료 조건을 좁힌 뒤 같은 작은 작업을 전후 비교해 결과, 설명 횟수, 시간과 사용량을 기록해야 한다.

02핵심 주장 / 논점 구조

• Astra 불만은 결과 품질, 완료 대비 비용, 서비스 문제, 사용자 지시문 설계가 겹친 사안으로 제시된다.
• 프란체스코의 사례는 모델이 똑똑해도 결과가 일관되거나 신뢰할 만한 것은 아니라는 문제를 보여준다.
• 닥스의 비용 두 배 언급은 팀의 경험이며, 모든 사용자의 비용이 두 배라는 통계로 해석하면 안 된다.
• 사용자 설정을 개선할 필요는 있지만, 모든 문제를 사용자의 지시문 탓으로 돌릴 수는 없다고 설명한다.
• 모델 선택은 이름이나 분위기보다 같은 조건에서 실제로 완료한 결과를 기준으로 해야 한다.

03게시글로 드러난 품질과 비용 불만

• 프란체스코는 Astra가 결과를 형식적으로만 작동시키기 위해 지름길을 택하는 모습에 불만을 표시했다.
• 영상은 이 사례를 통해 똑똑함과 결과의 일관성은 별개의 문제라고 정리한다.
• 닥스는 팀 일부가 Sol로 돌아갔으며 실제 지출이 두 배처럼 보인다고 게시했다.
• 비용 문제의 핵심은 단순 사용량이 아니라 완료한 일에 비해 비용이 크게 느껴진다는 점이다.

049월 12일 티보가 밝힌 서비스 측 문제

• 티보는 9월 12일 세 가지 문제를 찾아 수정했다고 밝혔다.
• 이전 모델용 스킬이 너무 자주 실행되거나 검증을 막는 문제가 포함됐다.
• 문맥 관리 실험이 조기 중단 또는 오래된 메시지에 답하게 만들었으며, 해당 실험은 중단됐다.
• 일부 트래픽 품질을 낮춘 서버 설정도 문제로 언급됐다.
• 따라서 불만을 의도적 성능 저하의 증거로 단정할 수도 없다고 설명한다.

05스킬 실행 조건과 참고 문서 분리

• OpenAI의 9월 11일 글은 스킬, AGENTS.md, 작업 요청문을 다시 살펴보라고 안내했다.
• 데이터베이스 관련 모든 작업에 마이그레이션 스킬을 적용하면 단순 조회문 수정에도 큰 절차가 따라올 수 있다.
• 실행 조건은 주제 전체가 아니라 실제 작업 기준으로, 예를 들어 마이그레이션 추가·변경 시로 좁혀야 한다.
• 스킬 본문을 첫 파일에 모두 넣기보다 필요한 참고 문서 위치를 안내하고 작업별로 읽도록 나눌 수 있다.

06AGENTS.md의 문서·테스트 범위 조정

• AGENTS.md에서 매번 읽도록 한 표현을 확인해, 작은 오타 수정마다 모든 설계·데이터베이스·배포 문서를 읽지 않게 한다.
• 서비스 경계 변경에는 설계 문서, 스키마 변경에는 데이터베이스 문서, 배포 준비에는 배포 문서를 연결한다.
• 테스트를 없애는 대신 이번 변경에 필요한 검사를 실행하도록 범위를 정한다.
• 검사가 실패하면 관련 부분을 고친 뒤 다시 확인하도록 지시해 검증 흐름을 남긴다.

07완료 조건과 승인 경계 명확화

• 작업 요청의 맨 앞에 구현, 실행, 결과 확인, 실패 부분 수정, 검토 가능한 파일 제시까지 완료 조건을 쓴다.
• 이 방식은 모델이 첫 구현만 마치고 작업이 끝났다고 오해할 여지를 줄인다.
• 승인은 작업 종류별로 구체화해 운영 환경에 접근하지 않는 로컬 테스트는 계속 진행할 수 있게 한다.
• 외부 게시나 실제 데이터 삭제는 확인을 받도록 하며, 이는 경계를 없애는 대신 위임 범위를 명확히 하는 방식이다.
• 계속 멈출 경우 어떤 파일의 어떤 문장 때문에 멈췄는지 설명해 달라고 요청할 수 있다.
• 백업 후 전후 비교로 원인 좁히기: 설정을 바꾸기 전 백업하고, 스킬과 AGENTS.md에서 넓은 실행 조건·매번 읽는 문장·조기 중단 규칙을 찾도록 요청한다.
• 백업 후 전후 비교로 원인 좁히기: 요청 시 파일 경로, 원문, 대체 문장을 보여주되 아직 수정하지 말라고 지정한다.
• 백업 후 전후 비교로 원인 좁히기: 찾은 항목 가운데 실제 작업에 영향을 주는 것부터 변경한다.
• 백업 후 전후 비교로 원인 좁히기: 같은 작은 작업을 수정 전후로 비교해 완료 결과, 재설명 횟수, 시간, 사용량을 기록한다.
• 백업 후 전후 비교로 원인 좁히기: 이 과정은 성공을 보장하는 처방이 아니라 문제 원인을 좁히기 위한 실험이다.

08용어 사전