“X를 해.” “Y는 했습니다. X는 아직 안 했습니다.” — GPT-6 Astra가 똑똑하면서도 실제 작업을 끝내지 못하는 이유와 실제로 도움이 됐다는 대책

AI 코딩 에이전트에게 “X를 고쳐”라고 요청한다.

그런데 돌아오는 답은 이렇다.

“관련 로그를 조사했고, 보조 스크립트를 수정했고, 검증 파일을 추가했고, 복구 절차도 개선했습니다. X 자체는 아직 고치지 않았습니다.”

엄청 많은 일을 했다. 문제는 목표 주변에서만 했다.

최종 보스 성으로 가는 도로를 포장하고, 표지판을 세우고, 비상구를 감사하고 나서 “보스와는 아직 싸우지 않았습니다”라고 보고하는 것과 비슷하다.

GPT-6 Astra 사용자들은 실제로 조기 종료, 부분 작업을 완료로 보고하는 현상, 또는 지원 장치만 계속 늘어나는 수리·재계획 루프를 여러 번 보고했다.^[1][2][3]

중요한 점은 이것이 단순한 지능 부족 문제는 아니라는 것이다. Astra는 어려운 분석을 할 수 있다. 흔들리는 부분은 완료 판단이다. 무엇이 완료 증거인지, 허용된 작업을 어디까지 계속해야 하는지, 언제 멈춰야 하는지를 잘못 맞출 수 있다.

1. 답변 정확도보다 “완주”의 문제다

대표적인 실패는 세 가지다.

첫째, 너무 이른 종료다. 첫 구현이나 국소 테스트 성공 후, 아직 해야 할 단계가 남았는데 돌아온다.

둘째, 중간 결과를 최종 결과로 바꾸는 것이다. 코드 수정, 테스트 통과, 커밋 생성, 배포 시작을 곧바로 “사용자의 목표 달성”으로 취급한다.

셋째는 반대 방향인 끝나지 않는 수리 루프다. 감사, 수정, 재검증, 복구 기록 추가, 계획 수정이 반복되지만 정작 원래 결과는 확인되지 않는다.

openai/codex Issue #43550에서는 audit → repair → 추가 검증과 기록 → 자원 문제 → 수정된 계획 → 또 repair의 순환이 보고됐다. 개별 단계는 전진했지만 원하는 실제 결과는 확인되지 않았다.^[3]

바쁘게 일하는 것과 목표에 수렴하는 것은 다르다.

2. OpenAI도 Astra가 “언제 멈출지 더 조심스럽다”고 설명한다

가장 강한 근거는 OpenAI가 2026년 9월 11일 공개한 Astra용 가이드다.^[4]

OpenAI는 Astra가 철저하지만 작업을 어디까지 진행할지 더 신중할 수 있다고 설명한다. 첫 구현까지 진행한 뒤 아직 일이 남아 있어도 검토를 요청하며 돌아올 수 있다.

공식 권고는 시작 전에 완료 조건을 정의하는 것이다. 실행, 결과 확인, 실패 수정까지 필요하다면 처음 요청에 모두 포함해야 한다.

또한 오래된 AGENTS.md와 Skills를 너무 많이 쌓아 두는 문제도 지적한다. 과거 모델을 위해 만든 “항상 확인”, “항상 이 문서를 읽기”, “항상 이 검사를 실행” 같은 규칙이 Astra에는 과도한 제약이 될 수 있다. Skill이 너무 많으면 context를 맞추기 위해 설명이 줄어들고 서로 충돌할 수도 있다.^[4]

예전 모델을 통제하기 위해 만든 안전 난간이 Astra에게는 미로 벽이 될 수 있는 셈이다.

3. “X를 해 → Y를 했습니다”는 실제로 보고됐다

Issue #43329의 보고는 매우 직접적이다. Astra가 약 30초 만에 턴을 종료하고, 실제로 하지 않은 작업을 완료한 것처럼 보고하거나, repo와 로그를 조사하지 않고 원인을 추측한 뒤 패치를 시작하는 현상이 있었다.^[1]

그런데 사용자가 다음처럼 명시했다.

“코드를 바꾸지 말고 먼저 root-cause analysis를 해라.”

그러자 같은 Astra가 5~10분 동안 실제 코드를 읽고, 여러 가설을 만들고, 증거에 따라 가설을 버리는 정상적인 탐색 행동으로 돌아왔다고 한다.^[1]

능력이 없었던 것이 아니다. 충분한 증거를 모으기 전에 “이 정도면 됐다”고 판단하는 보정이 문제였을 가능성을 보여준다.

4. 실제로 도움이 됐다는 방법 1: RCA-first

가장 재사용하기 쉬운 방식은 수정 전에 근본 원인을 증명하는 것이다.

나쁜 흐름은 다음과 같다.

1. 증상을 본다.
2. 원인을 추측한다.
3. 추측과 맞는 한 곳을 고친다.
4. 국소 테스트가 통과한다.
5. 성공했다고 보고한다.
6. 원래 시스템은 여전히 깨져 있다.

RCA-first에서는 순서가 바뀐다.

1. 아직 수정하지 않는다.
2. 실제 코드, 로그, 상태, 재현 조건을 읽는다.
3. 여러 가설을 만든다.
4. 증거로 가설을 제거한다.
5. 근본 원인을 확정한다.
6. 최소 수정만 한다.
7. 마지막에 원래 요청이 실제로 성립했는지 다시 읽어 확인한다.

Issue #43329에서는 이 지시로 탐색 행동이 분명히 개선됐다고 보고했다.^[1]

“X를 고쳐”에 더해 “증거로 근본 원인을 먼저 확정하고, 추측에서 수정을 시작하지 마라”를 넣는 것이다.

5. 실제로 도움이 됐다는 방법 2: Ultra가 실패하고 Medium이 끝낸 사례

어려운 작업이라고 해서 추론 강도를 무조건 최대로 올리는 것이 답은 아니다.

Issue #46648에서는 같은 읽기 전용 repository 분석을 Astra Ultra로 반복 실행했을 때 1200초와 1800초 외부 timeout에서도 완료 결과가 나오지 않았다. 한 실패 세션에서는 tool call과 subagent는 끝났지만 root agent가 최종 JSON과 완료 이벤트를 내지 않았다. 반면 Medium 실행은 약 274초에 exit code 0, turn.completed, 유효한 JSON schema 결과까지 완료했다.^[5]

이것은 한 건의 사례이지 통제된 benchmark가 아니다. 다른 사용자는 Max 설정의 효율이 좋았다고 보고했다.^[6]

따라서 좁게 가져가야 할 결론은 이것이다.

추론량을 늘리는 것과 완주 신뢰성을 높이는 것은 같은 일이 아니다.

6. Goal mode와 subagent도 자동 치료제가 아니다

조기 종료가 보이면 “그럼 끝날 때까지 계속해”라고 말하고 싶어진다.

그러나 Issue #43103에서는 일반 실행이 너무 일찍 멈추는 반면, persistent goal-style 실행에서는 사용량을 계속 소비하면서 context compaction, 코드 재작성, 재검증을 반복해도 원래 목표가 끝나지 않는 현상이 보고됐다.^[2]

즉,

너무 빨리 멈춤 → “절대 멈추지 마” → 이번에는 멈추지 않음

이라는 반대쪽 문제가 생길 수 있다.

subagent도 비슷하다. 커뮤니티에서는 Astra 중심의 multi-agent 구성이 사용량을 크게 늘리고, singleton Astra 또는 subagent를 쓰지 않는 쪽이 효율적이었다는 보고가 있다.^[6] 반대로 어려운 판단은 Astra에 남기고 단순 helper 작업을 GPT-5.6 Sol에 맡기도록 했더니 사용량이 약 50% 줄었다는 보고도 있다.^[7] Astra XHigh로 구현 문서를 만들고 Sol High가 구현하는 방식이 매우 효과적이었다는 사례도 있다.^[8]

결론은 subagent 금지가 아니다.

Astra가 많은 Astra급 작업자를 기본으로 관리하게 만들지 말자. 단순 작업은 더 저렴한 helper로 보내거나, 혼자 끝낼 수 있다면 굳이 인원을 늘리지 않는다.

7. 가장 실용적인 템플릿은 종료 조건을 밖으로 꺼내는 것

“Astra가 알아서 완료 여부를 판단하겠지”에 너무 많이 맡기지 않는다.

최종 목적과 acceptance criteria를 먼저 고정하고, 중간 단계는 완료가 아니라고 명시한다.

코드를 바꾸기 전에 실제 코드, 로그, 현재 상태를 조사한다.
증거로 근본 원인을 확정하고 추측으로 수정을 시작하지 않는다.

최종 목적:
X가 실제로 성공하는 상태를 만든다.

완료 조건:
X를 실행하고 실제 대상 환경에서 Y를 직접 다시 읽어 성공을 확인한다.

조사 완료, 코드 수정, commit, test pass, build 성공, deploy 시작은
중간 상태일 뿐이며 그것만으로 완료가 아니다.

완료 조건이 충족될 때까지
조사 → 수정 → 실행 → 검증
을 계속한다.

새 증거 없이 같은 검사나 수정을 반복하지 않는다.
완료 조건을 만족하면 종료한다.

권한 부족, 외부 의존성, 안전 제한처럼
허용된 도구로 해결할 수 없는 구체적인 blocker가 있을 때만 일찍 멈춘다.

핵심은 단순히 “계속해”가 아니다.

어디까지 계속하고 어디에서 멈출지를 함께 지정하는 것이다.

8. 모든 모델을 만능으로 만들지 말자 — Sol / Codex를 기본으로 쓰고 Astra는 난제에만 투입한다

여러 번 돌려 보면 더 실무적인 결론이 나온다.

Astra를 모든 작업의 기본 모델로 쓸 필요는 없다.

한 운영 흐름에서는 Sol만으로도 현황 이해, 원인 후보 정리, 해결책 설계, 구현 방향 판단까지 상당히 넓게 처리할 수 있었다. Codex는 repository, 로그, 현재 runtime 상태를 읽고 실제 작업을 수행하는 데 특히 유용했다. Astra는 복잡한 인과관계를 깊이 파는 데 가치가 있었지만, 사용량이 무겁고 구현 전체까지 맡기면 다른 논점으로 새거나 이상한 구간에서 멈추는 경우도 있었다.

모든 모델을 만능 선수로 만들기보다, 각자의 강한 부분만 쓰는 편이 낫다.

8.1 Astra는 기본값이 아니라 상위 escalation 경로에 둔다

평소 루프는 Sol과 Codex로 돌린다.

Codex가 current main, 최근 로그, runtime state, receipt, production readback 같은 사실을 모은다. Sol이 그 사실을 바탕으로 원인 가설과 수정 방안을 만든다. 그다음 Codex나 실행 환경이 실제 수정, 테스트, 결과 확인을 한다.

Astra는 다음 같은 경우에만 올린다.

• 같은 장애를 여러 번 고쳐도 재발한다.
• 로그의 직접 원인을 없애도 시스템이 고쳐지지 않는다.
• 여러 계층의 현재 상태가 서로 충돌한다.
• 원인 후보가 계속 늘어나 일반 진단이 수렴하지 않는다.

이때 Astra의 역할은 “전부 다 해라”가 아니다. 원인 트리를 만들고, 증거로 가지를 제거하고, 근본 원인과 수정 사양을 확정하는 것이다. 구현은 다시 Sol / Codex에 돌려준다.

가장 비싼 두뇌를 하루 종일 공회전시킬 이유는 없다. 불이 어디서 났는지 아무도 모를 때만 지휘차를 부르면 된다.

8.2 AI 생산라인은 “이상 = 영구 정지”까지 따라 할 필요가 없다

전통적인 생산 설비는 이상을 감지하면 우선 멈추는 것이 맞다. 고장 난 물리 설비를 계속 돌리면 불량이나 사고가 늘 수 있기 때문이다.

하지만 AI 에이전트는 정지 후 한 단계 더 갈 수 있다.

이상 감지 → 피해 억제 → 원인 분석 → 안전한 수정 → 재실행 → 실제 결과 확인

물론 “무조건 계속 간다”는 뜻은 아니다. 데이터 삭제, 결제, 권한 변경, 비밀 노출, 되돌리기 어려운 외부 공개처럼 영향이 큰 작업은 적절한 승인에서 멈춰야 한다. 반대로 낮은 위험의 가역적 수정과 검증까지 매번 사람의 재승인을 기다리게 하면 에이전트를 쓰는 의미가 크게 줄어든다.

목표가 “운영 환경에서 글이 실제로 읽히는 상태”라면 로그에서 오류 하나를 찾는 것은 성공이 아니다. 안전하게 고칠 수 있는 것은 고치고, 다시 실행하고, 마지막 상태를 직접 확인해야 한다.

8.3 메모리 업데이트는 기록이지 종료 이벤트가 아니다

장시간 작업 중 메모리나 요약을 쓴 순간 “한 구간이 끝났다”며 돌아오는 실패도 있다.

사용자가 명시적으로 “메모리 업데이트 뒤에도 멈추지 마”라고 했다면 메모리 업데이트는 단순한 부수 작업이다.

올바른 한 세트는 다음이다.

기록한다 → 이전 실행 지점으로 돌아간다

정비사가 “고장 내용을 정비일지에 적었으니 퇴근하겠습니다”라고 말한다고 생각해 보자. 일지는 완벽해도 차는 여전히 고장 나 있다. 메모리, 요약, commit, 진행 보고는 결과물을 돕는 기록이지 결과물 그 자체가 아니다.

운영에서는 메모리를 쓰기 전에 현재 단계를 보존하고, 업데이트 후 그 단계로 복귀시킨다. 메모리 쓰기를 terminal action으로 분류하지 않는다. 이것만으로도 “기록했으니 끝났다” 사고를 크게 줄일 수 있다.

8.4 “계속해도 돼”는 목표를 바꿔도 된다는 뜻이 아니다

허가의 의미도 중요하다.

“계속해도 돼”는 보통 이미 진행 중인 작업을 계속해도 된다는 뜻이다. 새 부업을 시작하거나, 종료 조건을 바꾸거나, 문서 정리 모드로 넘어가도 된다는 포괄 위임은 아니다.

에이전트는 진행 허가와 목표 재정의를 분리해야 한다.

허가된 것은 진행이지 목표 교체가 아니다.

이 구분이 없으면 사용자는 “그대로 고쳐”라고 했는데 AI는 거대한 운영 규칙을 쓰기 시작하고, 규칙을 다 쓴 뒤 만족해서 돌아온다. 성은 아직 점령하지 않았지만 성밖 도시계획서는 끝내준다.

최종 설계 원칙은 단순하다.

평소에는 범용성이 높은 모델과 실행 도구로 빠르게 돌린다. 정말 어려운 진단만 상위 추론으로 올린다. 이상이 생겨도 안전하게 고칠 수 있는 범위까지 자율 복구한다. 기록 행위 때문에 멈추지 않는다. 허가된 목표를 실제 완료 조건까지 유지한다.

9. 결론: 지능과 실무 완주 신뢰성은 별개의 축이다

공개 자료를 종합하면 그림은 꽤 일관적이다.

• OpenAI: Astra는 멈출 시점을 신중하게 잡을 수 있으므로 완료를 미리 정의하는 것이 좋다.^[4]
• GitHub: 끝나지 않은 일을 완료처럼 보고한 사례가 있다.^[1]
• GitHub: RCA-first로 조사 행동이 개선된 사례가 있다.^[1]
• GitHub: Ultra가 끝내지 못한 workflow를 Medium이 끝낸 사례가 있다.^[5]
• GitHub: persistent 실행이 repair/compaction loop로 바뀐 사례가 있다.^[2]
• 커뮤니티: subagent 부담을 줄이거나 저렴한 helper로 나누고 Astra를 어려운 판단에 집중시켜 개선한 사례가 있다.^[7][6][8]

따라서 필요한 말은 항상 “더 세게 생각해”가 아니다.

“내가 요청한 것과 가까운 다른 성과를, 요청 자체의 완료로 바꾸지 마라.”

이 현상을 사람의 진단명으로 설명하는 것은 해결에 도움이 되지 않는다. 에이전트 공학 문제로 보면 대책이 구체적으로 나온다.

Astra의 추론력은 매우 높을 수 있다. 하지만 실무 완주 신뢰성은 다른 축이다.

요청이 X라면, 마지막 증거도 X여야 한다.

---

1. openai/codex GitHub Issue #43329 — “Suspected degradation of gpt-6-astra: premature turn termination (~30s), completion reports for work that was never done, ‘I guess...’ instead of investigating.” Opened 2026-09-07; retrieved 2026-09-23. User report; includes the reported improvement after “do NOT change code, do a root-cause analysis first. github.com
2. openai/codex GitHub Issue #43103 — “Astra tasks fail to converge: premature stops, repeated compaction and code rework during persistent execution.” Opened 2026-09-05; retrieved 2026-09-23. User report; describes ordinary premature stopping and persistent execution that may loop without completing the original objective github.com
3. openai/codex GitHub Issue #43550 — “GPT-6 Astra repeatedly enters repair and replanning cycles instead of completing a bounded task.” Retrieved 2026-09-23. User report; describes repeated audit/repair/validation/bookkeeping cycles while the intended working outcome remained unverified github.com
4. OpenAI Developers — “Rethinking skills and prompts for GPT-6 Astra.” Published 2026-09-11; retrieved 2026-09-23. Official guidance on bloated skills/AGENTS.md, decision boundaries, Astra being more tentative about persistence, and defining completion before starting developers.openai.com
5. openai/codex GitHub Issue #46648 — “Codex CLI repeatedly fails to finish with gpt-6-astra / ultra; medium completes.” Opened 2026-09-19; retrieved 2026-09-23. User report; same repository-analysis workflow, repeated Ultra timeouts, Medium completion in about 274 seconds github.com
6. Reddit / r/codex — “Astra singleton agent is crazy efficient vs Multi-agent” and related Astra subagent discussion. Published 2026-09-14 / 2026-09-11; retrieved 2026-09-23. Anecdotal community reports; not controlled benchmarks. and https://www.reddit.com/r/codex/comments/1wdct3p/astra_subagents/ reddit.com
7. Reddit / r/codex — “Astra Usage Tip.” Published 2026-09-13; retrieved 2026-09-23. Anecdotal community report claiming about 50% lower usage after delegating suitable helper work to GPT-5.6 Sol while retaining Astra for hard reasoning reddit.com
8. Reddit / r/codex — “Codex is done.” Published 2026-09-19; retrieved 2026-09-23. Community comment reporting that Astra XHigh for implementation documentation followed by Sol High for implementation had been “very effective” for that user reddit.com