senpi start-work, 20분 만에 클로드 한도 20% 소모 — 병렬 실행이냐 한도 버그냐

오전 10시 5분, 한 참여자가 senpi에서 오푸스(Opus) 5 high 모델로 start-work 기능을 실행했더니 20분 만에 클로드 5시간 사용 한도의 20%가 사라졌다며 의아함을 토로했다.

"ㅠㅜ 이거 정상인지 모르겠네요.. gpt 에서 5시간 제한을 가려서 그런건가?? senpi 에서 opus 5 high 로 start work 했는데 20분만에 5시간 제한 20퍼네요"

해당 도구 개발에 참여 중인 한 참여자는 start-work가 여러 작업을 쉬지 않고 병렬로 돌리는 기능이라 토큰 소모가 큰 것은 당연하다고 설명했다. 하지만 다른 참여자는 병렬 실행과는 별개로 클로드 자체 한도가 비정상적으로 빨리 닳는 문제가 따로 있다고 지적하며 논란에 다른 축을 보탰다.

"start-work 가 하는 일이 일을 쉬지않게 병렬로 시키는거잖습니까?"

"클로드 자체 한도도 비정상적으로 닳는게 있는거같아여"

오전 11시대에는 구독 문제까지 겹친 사례가 나왔다. 한 참여자는 클로드 구독을 취소했다가 다시 구독했는데도 예전 계정에 남아 있던 주간 리밋에 그대로 묶여, 30만 원을 내고도 나흘째 사용을 못 하고 있으며 환불 요청도 계속 거절당했다고 토로했다.

"클로드 구독 취소했다가 다시 구독해도 예전에 계정에 남아있던 주간리밋에 걸리네요 30만원 내고 지금 4일동안 사용을 못하는데 이거 해결방법 없을까요ㅜㅜ 환불도 계속 거절당하구요…"

저녁 5시 41분에는 클로드 공식 상태 페이지에 성능저하 공지가 올라왔다는 제보가 이어지며, 하루 종일 이어진 한도·리밋 관련 불만이 공식 장애 인정으로 마무리됐다.

"성능저하 발생떳네요"

이날 나온 세 가지 사례 — 20분 만의 20% 소모, 재구독 후에도 풀리지 않는 주간 리밋, 저녁의 공식 성능저하 공지 — 는 서로 다른 현상처럼 보이지만 모두 클로드 사용량 관리 체계에 대한 신뢰 문제로 모인다. start-work의 높은 소모량은 기능 설계상 예견된 결과라는 설명이 붙었지만, 재구독 후에도 옛 리밋이 유지되는 사례는 설계가 아니라 시스템 오류에 가까워 보이며 사용자가 자력으로 해결할 수 없는 영역이라는 점에서 성격이 다르다.

하루 동안 한도 소모 속도, 구독·리밋 연동 오류, 공식 성능저하 공지가 연달아 겹쳤다는 사실은, 참여자들이 각자 다른 지점에서 클로드 인프라의 불안정성을 체감하고 있었다는 것을 보여준다. 병렬 실행 기능이 늘어날수록 한도 소모 속도에 대한 설명 책임은 더 커질 수밖에 없고, 구독·리밋 동기화 문제가 반복될 경우 이는 개별 버그를 넘어 신뢰의 문제로 번질 수 있다는 점을 이날의 논의는 시사한다.