Codex 또 초기화 예고…외출 중인데 20% 남았다고요!

Astra 품질 문제 수정 소식, 그런데 내 정규 리셋은 내일이다

호외요, 호외!

Codex에 또 리셋 소식이 들려왔습니다.

이번에는 단순한 출시 기념 이벤트가 아니라, Astra의 품질 문제를 점검하고 수정했다는 안내와 함께 나온 초기화 예고입니다.

반가운 소식입니다.

문제를 고쳤다니 좋고, 사용량도 다시 채워준다니 좋습니다.

그런데 지금 제 상황은 이렇습니다.

외출 중입니다.
사용량은 약 20% 남았습니다.
원래 정규 주간 리셋은 내일입니다.

……티보 양반.

혹시 제 외출 일정을 알고 계십니까?

컴퓨터 앞에 있을 때는 사용량이 부족하고, 밖에 나오면 리셋 소식이 들립니다. 이번에는 내일이면 원래 다시 채워질 사용량까지 남겨두고 나온 참입니다.

“아, 지금 밖인데에에. 아직 20% 남았는데에에.”

리셋 공지를 보고 환호해야 하는데, 먼저 나오는 말이 이겁니다.

---

이번 공지는 ‘리셋’보다 앞부분도 중요하다

공유된 게시물은 Astra의 품질 문제에 대한 설명으로 시작합니다.

캡처에 담긴 안내를 정리하면, 사용자들과 함께 문제를 살펴보는 과정에서 스킬 설정, 실험적인 컨텍스트 관리, 일부 엔진 구성과 관련된 문제를 찾아 조치했다는 내용입니다.

그리고 마지막에 리셋도 적용하겠다는 이야기가 붙었습니다.

사람의 눈은 참 정직합니다.

저도 긴 기술 설명을 읽다가 마지막의 **‘리셋’**에서 멈췄습니다.

하지만 개발자로서는 앞부분도 놓치기 아깝습니다. 모델이 이상하게 행동했을 때, 그 원인이 반드시 “내 프롬프트가 부족해서”만은 아닐 수 있다는 설명이 담겨 있기 때문입니다.

확인 범위 안내
이번 소식은 공유된 번역 캡처를 바탕으로 정리했습니다. 캡처에는 ‘오늘 자정까지 리셋 적용 예정’이라는 표현이 있지만, 원문 게시 시각과 기준 시간대, 대상 플랜 및 지급 방식까지 확인되지는 않습니다. 따라서 한국시간 오늘 자정에 전 계정 자동 초기화가 확정됐다는 의미로 읽어서는 안 됩니다.

반응형

Astra가 이상했던 이유, 세 가지가 언급됐다

캡처 속 설명은 다음과 같습니다.

언급된 문제사용자에게 나타날 수 있었던 현상게시물에 설명된 조치

이전 모델용으로 작성된 일부 스킬	불필요하게 자주 실행되거나 작업 확인을 방해	문제를 발견하고 수정
선택 참여형 컨텍스트 관리 실험	작업을 너무 일찍 끝내거나 이전 메시지에 응답	해당 실험 비활성화
일부 잘못 구성된 엔진	일부 요청에서 품질 저하	문제가 있는 엔진 제거

여기서 약 4천~5천 명이라는 추정치는 컨텍스트 관리 실험의 영향을 받은 사용자에 관한 설명입니다. Astra 전체 장애 피해 규모나 전체 이용자 수를 뜻하는 것은 아닙니다.

또한 ‘잘못 구성된 엔진’이라는 표현만으로 내부에서 무슨 일이 있었는지까지 단정하기는 어렵습니다.

저가 모델로 몰래 바꿨다거나, 의도적으로 성능을 낮췄다는 결론으로 바로 넘어갈 근거도 없습니다.

현재 캡처에서 읽을 수 있는 핵심은 이 정도입니다.

일부 품질 문제를 확인했고, 관련 설정과 실험에 조치했다는 것.

물론 이것이 모든 사용자의 모든 문제가 해결됐다는 뜻은 아닙니다. 실제 체감은 각자의 작업에서 다시 확인해야 합니다.

모델만 새것으로 바꾸면 끝나는 게 아니었다

특히 스킬 관련 설명이 눈에 들어왔습니다.

AI를 오래 사용하다 보면 지침이 계속 늘어납니다.

한 번 실수하면 규칙을 추가합니다. 또 다른 실수를 하면 예외 조건을 붙입니다. 그러다 어느 순간 AGENTS.md와 스킬 문서가 제법 두꺼워집니다.

처음에는 도움이 됐습니다.

그런데 모델이 바뀌어도 그 지침을 그대로 사용하면 어떨까요?

OpenAI는 9월 11일 공개한 공식 개발자 글에서, Astra를 사용할 때 기존 스킬 설명과 AGENTS.md, 작업 프롬프트를 다시 검토할 필요가 있다고 안내했습니다. 지나치게 넓은 실행 조건이나 과도하게 세세한 절차가 오히려 작업을 방해할 수 있다는 설명입니다. 

예를 들어 제가 이런 규칙을 만들어뒀다고 가정해보겠습니다.

“파일을 수정하기 전에 프로젝트 전체 구조와 모든 설계 문서를 확인할 것.”

큰 구조 변경에는 유용할 수 있습니다.

그런데 버튼 문구 하나를 바꿀 때마다 전체 프로젝트를 다시 읽는다면 이야기가 달라집니다. 오타 하나 고치러 왔다가 인수인계부터 다시 받는 셈입니다.

스킬의 실행 조건도 중요합니다. 공식 문서상 Codex는 작업과 스킬의 설명이 맞는다고 판단하면 스킬을 자동 선택할 수 있습니다. 설명을 너무 넓게 써두면 원하지 않는 작업에서도 호출될 여지가 있는 것입니다. citeturn343805view1

모델은 업그레이드했는데, 업무 매뉴얼은 예전 모델 기준으로 계속 누적된 상태.

이번 안내를 보며 제 프로젝트에도 그런 부분이 없는지 생각하게 됐습니다.

그렇다고 안전장치까지 지우라는 이야기는 아니다

여기서 방향을 잘못 잡으면 안 됩니다.

“새 모델은 알아서 잘하니 승인도 빼고, 테스트도 빼고, 제한도 다 풀자.”

이건 제가 받아들인 결론이 아닙니다.

불필요하게 반복되는 지시와, 꼭 필요한 안전 기준은 구분해야 합니다.

운영 데이터에 접근하지 않는 것, 중요한 변경은 검토하는 것, 실제로 테스트했는지 확인하는 것은 여전히 필요합니다. 다만 작은 수정마다 모든 절차를 처음부터 반복하게 만드는 규칙은 다시 볼 만합니다.

OpenAI의 같은 글도 Astra가 첫 구현 이후 검토를 기다리며 멈출 수 있으므로, 구현·실행·검증 중 어디까지 완료해야 하는지 처음부터 명확하게 정하라고 설명합니다. 

그러니 이번에 제가 점검하고 싶은 것은 이런 부분입니다.

왜 불렀는지 모를 스킬, 같은 문서를 계속 읽게 하는 지침, 그리고 어디까지 해야 끝인지 모호한 작업 요청.

모델 탓만 하기 전에 볼 항목이 생겼습니다.

물론 반대도 같습니다. 서비스 설정이나 실험에서 문제가 있었다면, 사용자가 프롬프트를 잘못 쓴 탓으로만 돌릴 일도 아닙니다.

---

그런데 저는 지금 밖입니다

좋습니다.

품질 문제도 고쳤고, 지침을 점검할 방향도 알았습니다.

이제 돌아가서 기존 작업을 다시 돌려보면 됩니다.

그런데 돌아가기 전에 리셋이 들어올 수도 있다는 이야기를 들으니 마음이 괜히 바빠집니다.

평소에는 이랬습니다.

“20% 남았네. 내일 정규 리셋이니까 필요한 것만 조금 더 하면 되겠다.”

리셋 예고를 보고 나니 이렇게 바뀝니다.

“20% 남았네? 이거 지금 뭘 시켜야 하는 거 아닌가?”

똑같은 20%인데 갑자기 유통기한 임박 상품처럼 보입니다.

원래 없던 일이 급해집니다.

집에 있는 컴퓨터를 떠올립니다.

미뤄둔 작업이 뭐였는지 생각합니다.

그리고 잠깐 정신을 차립니다.

나 지금 외출 중인데, 왜 머릿속에서는 에이전트 작업 배분 회의를 하고 있지?

728x90

지난번에는 정규 리셋 직후, 이번에는 정규 리셋 직전

이 타이밍이 더 얄미운 이유가 있습니다.

지난번 Claude에서도 제 정규 리셋 시점과 이벤트성 초기화가 겹쳤습니다. Codex에서도 원래 사용량이 채워진 다음 날 글로벌 리셋을 받았습니다.

그때는 이런 기분이었습니다.

“어제 채워진 통에 오늘 또 채워준다고?”

이번에는 반대입니다.

“내일 채워질 통인데, 지금 밖에 있고 아직 20% 남았다고?”

물론 회사가 제 일정을 보고 리셋할 리는 없습니다.

압니다.

다 아는데, 이 정도면 제 리셋 캘린더만 절묘하게 피해 다니는 것 같습니다.

리셋은 공평하게 온다는데, 왜 제 타이밍은 늘 unfair한 걸까요.

자동 초기화인지, 저장형 초기화권인지부터 구분해야 한다

다만 여기서는 기대와 사실을 나눠야 합니다.

이번 캡처의 ‘리셋’이라는 단어만으로 자동 초기화인지, Banked Reset 지급인지까지 확정하기는 어렵습니다.

두 방식은 체감이 꽤 다릅니다.

방식현재 남은 20%와의 관계

자동·글로벌 초기화	대상 사용량에 바로 적용되며, 저장형 리셋권이 생기는 것은 아님
Banked Reset 지급	계정에 보관했다가 사용자가 필요한 시점에 적용

OpenAI 공식 도움말도 두 방식을 별개로 설명합니다. 한 공지에 둘 다 포함될 수도 있으므로, 구체적인 이벤트 안내와 실제 계정 화면을 확인해야 합니다.

이번에도 자동 초기화로 현재 한도를 100%까지 채워주는 방식이라면, 잔여 20%가 있는 제 계정에서는 표시상 약 80%포인트가 늘어나는 셈입니다.

적지 않은 혜택입니다.

20%를 빼앗기는 것은 아닙니다.

제가 아쉬운 것은 그 20%를 실제 필요한 일에 쓰기도 전에 이벤트가 지나갈 수 있다는 점입니다. 내일 정규 리셋까지 가까우니, 추가 사용량을 활용할 여유도 함께 따지게 됩니다.

반대로 저장형 초기화권이라면 외출 중에 급하게 움직일 이유가 훨씬 적습니다. 나중에 필요한 때 쓰면 되니까요.

또 내일로 표시됐던 정규 리셋 시각이 이번 이벤트 이후에도 유지되는지는 실제 화면에서 다시 확인해야 합니다. Full Banked Reset을 직접 사용하면 주간 리셋 날짜가 바뀐다는 공식 안내가 있지만, 그것을 이번 이벤트에 그대로 대입할 수는 없습니다.

“80%나 받으면 좋은 거 아니야?” 잠깐만요

이쯤 되면 아주 합리적인 답변이 나옵니다.

“그래도 사용량 늘어나면 이득이잖아.”

맞습니다.

고맙습니다.

문제를 고쳤다는 것도, 사용량을 더 준다는 것도 반갑습니다.

그런데 지금 제가 듣고 싶은 말은 그것만은 아닙니다.

“하필 외출 중이냐. 내일 정규 리셋인데 또 타이밍 겹쳤네.”

이 정도면 됩니다.

무료 혜택을 받는 사람도 잠깐 투덜거릴 수는 있잖아요.

너 T야? 오늘은 퍼센트 계산보다 공감이 먼저입니다.

---

그래도 20%를 쓰려고 외출을 망치지는 말자

얼마 전에는 AI 구독료를 더 올려야 할지 고민하는 글을 썼습니다.

그때 스스로 정리한 생각이 있었습니다.

도구의 가능성에 끌려다니지 말고, 실제 필요한 결과를 기준으로 사용하자.

그런데 리셋 소식 한 번에 바로 흔들립니다.

역시 다짐과 실천은 별개입니다.

그래도 이번에는 기준을 잡아보려고 합니다.

이미 준비된 작업이 있고, 결과를 확인할 수 있는 여건이 된다면 진행하면 됩니다. 하지만 외출 중에 사용량을 없애겠다고 새 프로젝트를 급조하거나, 검토할 수 없는 대규모 수정을 걸어둘 필요는 없습니다.

집에 돌아왔을 때 아직 사용량이 남아 있다면, 이번 공지와 직접 연결되는 작은 작업부터 할 생각입니다.

기존 스킬과 프로젝트 지침을 읽고, 불필요하게 넓은 실행 조건이나 중복 지시가 있는지 점검하는 것.

예를 들면 이런 요청입니다.

현재 프로젝트의 AGENTS.md와 사용자 정의 스킬을 검토해줘.
이번에는 파일을 수정하지 말고 점검 결과만 작성해줘.

확인할 내용:
- 작업과 무관하게 자주 실행될 수 있는 스킬 설명
- 같은 문서나 전체 저장소를 반복해서 읽게 하는 지시
- 서로 충돌하는 규칙과 불명확한 완료 조건

각 항목에 파일 위치, 문제 이유, 수정 제안을 남겨줘.
보안·권한 제한과 필요한 테스트 기준은 제거하지 마.
관련 없는 파일과 비밀정보는 읽지 말고,
점검이 끝나면 후속 작업을 자동으로 시작하지 마.

남은 사용량을 소모하는 데 그치지 않고, 다음 작업의 품질을 높이는 데 쓸 수 있습니다.

그리고 이미 리셋됐다면?

그냥 새로 채워진 사용량으로 하면 됩니다.

토큰을 다 못 쓴 아쉬움보다, 필요 없는 코드를 잔뜩 만든 뒤의 후회가 더 오래갈 테니까요.

이번에는 리셋보다 ‘같은 일을 다시 시켜보는 것’이 중요하다

품질 개선 소식이 나왔으니, 돌아가서 해볼 만한 일은 또 있습니다.

기존에 아쉬웠던 작업을 작은 범위에서 다시 실행해보는 것입니다.

가령 이전 요구사항에 답하거나, 구현만 하고 검증을 끝내지 않거나, 불필요한 스킬을 계속 부르던 사례가 있었다면 그 부분을 다시 확인해볼 수 있습니다.

새로운 대형 프로젝트를 던지는 것보다 비교하기도 쉽습니다.

제가 보고 싶은 것은 “오늘은 왠지 더 똑똑한 것 같다”는 느낌만이 아닙니다.

최신 요청을 제대로 따라왔는지, 합의한 완료 조건까지 진행했는지, 실제로 확인한 결과를 보고했는지.

그걸 봐야 이번 수정이 제 작업에도 도움이 됐는지 알 수 있습니다.

원인이 여러 개였다는 공지라면, 해결 여부도 한 번의 인상으로 판단하지 않는 편이 맞겠습니다.

사용자도 할 일이 있지만, 서비스의 책임도 남는다

스킬과 지침을 정리하라는 조언은 유용합니다.

하지만 모든 문제를 사용자 설정 탓으로 끝내서는 안 된다고 생각합니다.

이번 캡처에는 서비스 측 컨텍스트 실험과 엔진 구성 문제도 함께 언급돼 있습니다. 그렇다면 사용자가 해야 할 일과 제공자가 해야 할 일은 나눠서 볼 필요가 있습니다.

저는 프로젝트의 요구사항과 지침을 정리하고, 결과를 검증하겠습니다.

서비스 쪽에서는 어떤 문제가 있었고, 무엇을 수정했으며, 누구에게 어떤 리셋을 언제 적용하는지 분명하게 알려줬으면 합니다.

특히 리셋 공지는 이 세 가지만 알아도 훨씬 편합니다.

정확한 시간대. 자동 초기화인지 저장형인지. 기존 정규 리셋 일정이 바뀌는지.

사용자가 밖에서 휴대전화로 번역 캡처를 확대하며 이걸 추리하지 않아도 되면 좋겠습니다.

호외의 결론: Astra도 고치고, 내 리셋 운도 좀 고쳐주세요

이번에 공유된 소식은 두 가지입니다.

Astra의 일부 품질 문제를 찾아 조치했다는 것.

그리고 리셋도 적용하겠다고 예고했다는 것.

다만 캡처만으로는 이번 리셋의 정확한 한국시간과 대상, 지급 방식까지 확인되지 않습니다. 특히 번역된 ‘오늘 자정’은 곧바로 한국시간 자정이라는 뜻이 아닙니다. 실제 적용 공지와 계정 사용량 화면을 함께 봐야 합니다.

그 사이 제 상황은 변함없습니다.

외출 중입니다.

사용량은 약 20% 남았습니다.

정규 리셋은 내일입니다.

이번에도 타이밍이 아주 예술입니다.

그래도 문제를 찾아 고쳤다는 소식은 반갑습니다. 사용량만 다시 채워지는 것보다, 다음 작업을 제대로 끝낼 수 있는 상태로 돌아오는 게 더 중요하니까요.

티보 양반.

수정 감사합니다.

리셋도 감사합니다.

그런데 다음번에는 사용량 게이지 옆에 버튼 하나만 더 만들어주시면 안 될까요?

“지금 외출 중입니다. 선물은 귀가 후 받을게요.”

모델은 점점 사용자의 맥락을 잘 이해한다는데, 리셋 일정은 아직 제 맥락을 전혀 모릅니다.

호외요, 호외.
Codex에 또 리셋 예고가 왔습니다.
그리고 저는 또 밖입니다.