Grok Bot이 다운되었나요? 서비스 중단처럼 보이는 네 가지 장애와 먼저 확인해야 할 사항

오늘 아침 Grok Bot이 응답을 멈췄다면 플랫폼 장애일 가능성은 낮으며, 그 이유는 구조적입니다. Grok Bot은 2026년 8월 11일에 출시된 SpaceXAI의 상시 작동 에이전트로, 귀하의 계정에 할당된 클라우드 컴퓨터에서 이름이 붙은 소규모 봇 무리로 실행됩니다. 이 봇이 실패하는 거의 모든 방식은 플랫폼 자체는 완전히 정상인데도 같은 증상인 침묵을 만들어내는 방식입니다. 따라서 "다운된 건가요?"에 대한 정직한 첫 대답은 증상만으로는 알 수 없다는 것이며, 약 3분 만에 답에 도달할 수 있는 점검 순서가 있습니다.

체크리스트 전에 한 가지 유의점이 있습니다. 우리가 읽은 바로는 SpaceXAI의 Bot 문서는 계정 수준 사용량 표시와 루틴별 실행 기록을 제공하지만, 공개된 업타임이나 장애 피드는 제공하지 않습니다. 서비스가 저하되었는지 알아보기 위해 새로고침할 수 있는 페이지가 없습니다. 바로 그런 부재 때문에 이 글은 상태 페이지 링크 대신 존재합니다.

네 가지 실패, 실제로 일어나는 순서대로

첫째: 계정의 포함 사용량이 소진되었습니다. 가장 흔한 경우이며, 장애를 가장 그럴듯하게 재현하는 경우입니다. 한도에 도달한 봇은 그냥 멈추기 때문입니다. Grok Bot 액세스는 유료 Cursor 플랜과 SuperGrok 등급에 포함되어 있으며, 문서에서 설명하는 측정 기준은 봇별이 아니라 계정의 주간 포함 사용량입니다. 이 구분이 곧 함정입니다. 대화를 많이 하는 봇 하나가 다섯 봇이 공유하는 허용량을 모두 소진할 수 있고, 외부에서는 봇들이 한꺼번에 작동을 멈춘 것처럼 보입니다. Usage & Billing에는 자격이 되는 계정의 주간 포함 사용량과 온디맨드 사용량이 표시되며, 계정 메뉴에서 주간 수치를 확인할 수 있습니다. 포함 사용량을 소진한 플랜은 모델 및 토큰 비용을 기준으로 청구되는 온디맨드 지출을 추가할 수 있습니다. 같은 FAQ의 한 문장은 둘 모두에 비용을 지불하는 경우 알아둘 가치가 있습니다. Cursor 구독과 SuperGrok 구독을 보유하고 있다면 Bot은 사용량이 더 많은 쪽에서 차감합니다.

둘째: 루틴은 중단된 것이 아니라 일시중지된 것입니다. 루틴은 봇이 일정에 따라 또는 이벤트 후에 실행되는 방식이며, 사용자가 자리를 비운 동안 계속 실행된다는 보장은 없습니다. 문서에 따르면 Grok Bot은 장기간 부재 후 루틴을 계속 실행할지 물을 수 있으며, 답하지 않으면 해당 루틴을 일시중지할 수 있습니다. 휴일, 긴 주말 또는 읽지 않은 프롬프트 이후 조용해진 봇은 대개 바로 그 상태에 놓여 있을 가능성이 큽니다.

셋째: 컴퓨터가 재설정되어 설치한 항목도 함께 사라졌습니다.계정의 모든 봇은 한 대의 컴퓨터를 공유하며, 여기에는 영구적인 Linux 환경, 브라우저, 명령줄, 그리고 다음 위치의 공유 작업 공간이 포함됩니다: code>/workspace/code>. 문서에는 임시 디렉터리, 수동으로 설치한 패키지, 커밋되지 않은 애플리케이션 상태를 교체 가능한 것으로 취급해야 한다고 분명히 나와 있으며, 두 복구 경로가 서로 다르다고 설명합니다: Reset은 마지막으로 저장된 스냅샷을 복원하고, Recreate는 “회원이 스스로 설치한 앱과 패키지를 제거합니다.” 봇이 직접 설치한 항목 — 타사 코딩 에이전트, CLI, 라이브러리 — 에 의존하는 경우, 복구를 하면 해당 항목이 제거되어 응답은 하지만 본래 작업을 수행할 수 없는 봇만 남을 수 있습니다. 이는 부분 장애처럼 보이지만 실제로는 바이너리가 누락된 것입니다.

넷째: 봇 뒤에 있는 모델이 바뀌었거나 성능이 저하된 경우입니다. Cursor는 모델 선택을 관리합니다. "Grok 4.7과 다른 모델 중 어디서 고르나요"라는 질문에 대한 문서의 답변은 명확합니다. 모델 선택기가 없고, 봇별 설정도, 루틴별 설정도, 스킬별 설정도 없습니다. 10월 7일 Elon Musk는 Grok Bot이 SpaceXAI 자체 모델에만 국한되지 않고 "어떤 주어진 작업에도 최적의 백엔드 모델"을 찾아갈 것이라고 공개적으로 말했지만, 그 발언에는 요금표도, 변경 로그 항목도, 외부 측정치도 붙지 않았습니다. 따라서 엔진은 사용자가 볼 수 없는 플랫폼 측의 결정입니다. 엔진이 바뀌면 관찰되는 것은 오류 메시지가 아니라, 같은 작업에서 출력 품질과 지연 시간, 비용이 흔들리는 현상입니다. 갑자기 글이 나빠지거나 더 오래 걸리는 봇이 반드시 다운된 것은 아닙니다.

3분 점검

이것들을 순서대로 실행하고, 보이는 것을 설명해 주는 첫 번째 항목에서 멈추세요:

• 계정 사용량부터 확인하세요. 다른 무엇보다 먼저 계정 메뉴를 열어 주간 포함 사용량 수치를 확인하세요. 사용량이 소진되었거나 거의 소진된 상태라면, 그 이후의 모든 것—모든 봇, 모든 루틴—이 단 하나의 이유로 실패하고 있는 것이며, 봇을 아무리 디버깅해도 도움이 되지 않습니다. 종량제 지출이 해결책이며, 이는 기술적 결정이 아니라 청구 관련 결정입니다.

• 실행 기록을 두 번째로 확인하세요. 각 루틴은 최근 실행 기록 20개를 보관합니다. 이는 의도적으로 얕은 감사 추적이며, 그래도 중요한 질문에 답하기에는 충분합니다. 루틴이 실행되었다가 실패한 것인지, 아니면 아예 시작되지 않은 것인지 말입니다. 최근 기록이 없는 루틴은 일시 중지되었거나 트리거된 적이 없는 것입니다. 기록이 있지만 실패로 끝나는 루틴은 봇 문제입니다. 성공 기록은 있으나 눈에 보이는 출력이 없는 루틴은 출력 전달 문제입니다.

• 세 번째는 컴퓨터입니다. 봇에게 무엇을 볼 수 있는지 직접 물어보세요 — code>/workspace/code> 내용, 설치된 도구가 아직 있는지, 로그인이 유지되었는지 등. 컴퓨터는 계정 전체에 걸쳐 하나뿐인 머신이고 파일은 모든 봇에게 보이므로, 이를 통해 다른 봇이 한 일이 이 봇에 영향을 주었는지도 알 수 있습니다.

• 트리거, 네 번째. 봇이 일정이 아니라 이벤트로 실행된다면 트리거의 범위를 확인하세요. 문서에서는 "모든 새 메시지"와 같이 범위가 넓은 리스너를 경고합니다. 이런 리스너는 노이즈를 만들어내고 사용량을 소모하며 관련 없는 입력에 반응합니다. 끊임없이 실행되면서 유용하게는 전혀 실행되지 않는 봇, 또는 그 반대의 경우는 대개 서비스 문제가 아니라 트리거 범위 설정 문제입니다.

네 가지 모두가 깨끗한 뒤에야 ‘플랫폼’이 합리적인 가설이 됩니다 — 그리고 그때조차 이를 대조해 확인할 상태 피드가 없기 때문에, 가지고 있는 증거는 정황 증거일 뿐입니다.

공유 컴퓨터가 이 일을 필요 이상으로 어렵게 만드는 이유

Grok Bot에서 단일 컴퓨터 설계는 가장 중대한 사안이면서, 문제가 생기기 전까지는 가장 알아차리기 어려운 부분입니다. 컴퓨터 한 대가 개별 봇이 아니라 계정에 할당되며, 각 봇이 보는 화면은 "별도의 작업 공간이지 별도의 보안 경계가 아니다"라고 설명됩니다. Team Bot에서는 어떤 비밀 값이든 동료 누구의 대화에서든 사용할 수 있습니다. 이는 진단에 두 가지 영향을 미칩니다.

첫째, 장애는 좀처럼 국소적으로 발생하지 않습니다. 리서치 봇이 작성한 파일은 아웃리치 봇도 읽을 수 있고, 초기화 중에 제거된 패키지는 이를 사용한 모든 봇에 영향을 줍니다. 둘째, 복구는 계정 범위로 한정됩니다. 봇을 삭제하면 활성 프로필, 대화 및 루틴은 제거되지만, 컴퓨터 파일과 로그인은 봇별로 격리되지 않으며 계속 남아 있을 수 있습니다. 봇 숨기기는 되돌릴 수 있는 대안이며, 루틴 삭제는 즉시 이루어지고 되돌릴 수 없습니다.

새벽 2시에 디버깅하고 있다면, 그 비대칭성은 어떤 로그보다도 중요합니다: 정리처럼 보이는 작업들이 바로 되돌릴 방법이 없는 작업들이니까요.

"status"이 실제로 요구하는 것

진정한 상태 답변에는 Grok Bot이 현재 제공하지 않는 세 가지가 필요하며, 이는 여러분이 운영할 수 있는 제품과 지켜보기만 할 수 있는 제품을 구분하는 차이이기 때문에 그 이름을 짚고 넘어갈 가치가 있습니다:

• 봇별 미터입니다. 사용량은 계정 수준에서 측정되므로, 함께 실패한 봇 무리는 어느 봇이 원인인지 분해할 수 없습니다.

• 더 깊은 실행 기록.루틴당 20개의 기록은 이번 주의 실패를 잡아내기에는 충분하지만, 한 달에 걸친 드리프트를 잡아내기에는 부족합니다. 드리프트는 요란하게 드러나기보다 조용히 비용을 발생시키는 실패 유형입니다.

• 인시던트 피드. 그러한 피드가 없으면, "서비스가 성능 저하 상태다"라는 것은 관찰이 아니라 네 가지 부재로부터 나온 추론이다.

그렇다고 해서 이게 제품 설계에 대한 비판은 아닙니다. 이 제품은 그 자체로서 일관성이 있습니다. 즉, 말을 걸어서 설정하는 구독 에이전트라는 정체성에 잘 맞는 설계입니다. 다만 이는 봇이 조용해질 때마다 증명 책임이 사용자에게 돌아간다는 뜻이며, 위의 점검 순서가 그 책임을 지는 가장 저렴한 방법입니다.

라우터가 적합한 경우와 그렇지 않은 경우

Grok Bot은 구독형 제품이며, 서드파티 엔드포인트를 통해 라우팅할 수 있는 대상이 아닙니다. 정직한 가이드라면 결코 그렇게 하라고 제안해서는 안 됩니다. 모델 선택 문제가 제기하는 질문은 다릅니다. 비용 때문이든, 라이선스 때문이든, 결과의 재현성 때문이든 엔진을 의도적으로 선택해야 한다면, 그 요구사항은 봇 내부에서 전혀 표현될 수 없습니다. 그것은 하위 계층에 존재해야 합니다.

그 계층이 바로 저희가 판매하는 것입니다. OrcaRouter는 200개 이상의 모델을 아우르는 하나의 OpenAI 호환 엔드포인트이며, 제공업체 정가에 마크업을 붙이지 않으므로 벤더의 가격 인하가 같은 날 바로 반영됩니다. Grok 4.6은 이 엔드포인트에서 SpaceXAI가 공개한 자체 요율인 입력 토큰 100만 개당 2.00달러, 출력 토큰 100만 개당 6.00달러로 제공되며, 500,000토큰 컨텍스트 윈도우와 측정된 p50 최초 토큰 도달 시간 1.65초를 갖추고 있습니다. 검증되지 않은 단계가 실패할 때 중요한 것은 실패가 인시던트로 이어지지 않도록 막는 요소들입니다. 즉, 한 제공업체의 성능이 저하될 때 제공업체 전반에 걸친 자동 장애 조치, 여러 모델을 하나의 호출로 구성하는 라우팅 DSL, 그리고 함께 응답하는 패널을 위한 모델 퓨전입니다.

봇이 조용해져서 이 글을 읽는 사람에게 가장 현실적인 방법은 시시한 것입니다. 스킬을 작성하고, 신뢰하려던 모델에 대해 손으로 직접 한 번 실행한 다음에야 자동화하세요. 직접 호출할 수 있는 모델로 검증된 봇은 실패의 원인을 짚을 수 있는 봇입니다. 그리고 "다운됐나요?"가 정말 묻는 것은 가동 시간이 아니라 원인 규명입니다.