Gemini가 6월 10일에 멈춘 날, 실제로 확인된 것

갑자기 안 되는 날은 생각보다 바로 티가 난다

6월 10일 Gemini 장애를 두고 잠깐 버벅인 거 아니냐고 볼 수도 있다. 실제 사용자 반응은 그보다 거칠었다.

Tom's Guide가 받은 제보 가운데 하나는 이랬다. 팀 단위로 Gemini Pro를 쓰던 사용자가 계속 프롬프트를 보내도 Something went wrong (1099)만 나온다고 했다. 한 명의 앱 문제가 아니라, 같은 팀에서 같이 막혔다는 얘기다. Tom's Guide 정리 (영어주의)

이런 장면이 중요하다. AI 도구는 채팅창처럼 보여도, 실제로는 검색, 문서 정리, 코드 확인, 회의 준비 같은 중간 업무를 꽤 많이 먹고 들어간다. 그래서 몇 시간 멈추면 잠깐 안 열렸다보다 하던 일이 끊겼다는 쪽에 가깝다.

공식 기록부터 보면 장애 자체는 분명했다

가장 먼저 볼 자료는 Google Workspace 상태 기록이다.

Google의 공개 incident JSON에는 Gemini App in Workspace and Gemini Side Panel 고객이 Something Went Wrong 오류를 겪고 있다고 적혀 있다. 시작 시각은 2026년 6월 10일 03:26 PDT, 종료 시각은 2026년 6월 10일 10:30 PDT로 남아 있다. 상태 영향은 SERVICE_DISRUPTION으로 표시돼 있고, 우회 방법은 없음으로 기록됐다. Google Workspace Status Dashboard incident log (영어주의)

즉 정말 장애였나는 이미 여기서 끝난다. 장애는 있었다.

다만 범위는 조금 나눠서 봐야 한다. 공식 기록이 직접 가리킨 대상은 Workspace 안의 Gemini 앱과 Gemini 사이드 패널이다. 반면 외부 보도는 웹, 앱, 일부 유료 계정, Gemini in Chrome까지 같이 흔들렸다고 전했다. TechRadar 정리 (영어주의) Tom's Guide 정리 (영어주의)

그래서 안전하게 말하면 이 정도가 맞다.

먼저 갈라서 봐야 하는 건 원인보다 범위다

사람들이 가장 궁금해한 건 그래서 왜 멈췄나다. 여기서는 선을 그어야 한다.

Google은 이번 장애의 정확한 기술 원인을 공개하지 않았다. 상태 기록에도 엔지니어링 팀이 조사 중이라는 수준만 남아 있고, 6월 12일 수정된 incident JSON에도 세부 원인 보고는 없다. Google Workspace Status Dashboard incident log (영어주의)

반대로 기사와 소셜 반응에서는 서버 문제, 세션 충돌, 특정 지역 문제, 데이터센터 이슈처럼 여러 말이 빠르게 돌았다. 그런데 이 가운데 공식 확인으로 올라온 것은 많지 않다. 예를 들어 Tom's Guide도 여러 우회 시도와 추정이 돌았다고 정리했지만, 확정 원인으로 못 박지는 않았다. Tom's Guide 정리 (영어주의)

여기서 독자가 가져갈 핵심은 단순하다. 왜 멈췄는지는 아직 공개되지 않았고, 몇 시간 동안 실제 서비스 장애가 있었다는 점만은 공식 기록으로 확인된다.

왜 여러 화면이 한꺼번에 같이 멈출까

이 부분은 공식 발표가 아니라, 확인된 정황을 바탕으로 한 해석이다.

같은 날 나온 보도를 보면 오류는 특정 채팅 하나보다 여러 진입면에서 동시에 나타났다. 웹과 모바일에서 프롬프트가 다시 입력창으로 튕기거나, 1076, 1099 같은 오류가 반복됐고, 일부 사용자는 같은 계정으로 계속 막혔다고 했다. TechRadar 정리 (영어주의) Tom's Guide 정리 (영어주의)

이 정도면 문제를 단말기 버그 하나로 보기는 어렵다. 보통 이런 패턴은 공통 백엔드나 요청 처리 계층에서 문제가 생겼을 때 더 자주 보인다. 같은 모델 호출 경로를 여러 제품이 함께 쓰고 있었다면, 한 지점의 장애가 웹과 앱, 사이드 패널 쪽에 같이 번질 수 있다.

물론 이건 어디까지나 추정이다. Google이 사후 원인 보고서를 내지 않은 이상 정확히 어느 계층이 고장 났다고 단정할 수는 없다.

그래도 실무 감각으로는 한 가지가 또렷하다. 요즘 AI 제품은 겉으로는 여러 앱처럼 보여도 안쪽은 꽤 많이 공유한다. 그래서 장애도 한 화면에서만 예쁘게 멈추지 않는다. 문서 옆 사이드 패널, 브라우저, 메인 앱이 같이 주저앉는 날이 나오는 이유가 여기에 가깝다.

그날 실제로 확인된 흐름

공개 자료를 시간순으로 붙이면 흐름은 대체로 이렇다.

1. Google 공식 기록상 장애 시작은 2026년 6월 10일 03:26 PDT였다. Google Workspace Status Dashboard incident log (영어주의)
2. 외부에서는 오전부터 1076, 1099, Something went wrong 오류 제보가 빠르게 늘었다. TechRadar 정리 (영어주의) Tom's Guide 정리 (영어주의)
3. Google 상태 페이지는 조사 중이라고 알렸지만, 한동안 우회책은 없다고 적었다. Google Workspace Status Dashboard incident log (영어주의)
4. 보도 기준으로는 중간에 복구 예정 시각이 여러 번 밀렸고, 이 때문에 답답하다는 반응도 커졌다. TechRadar 정리 (영어주의)
5. 공식 기록상 종료 시각은 2026년 6월 10일 10:30 PDT였다. Google Workspace Status Dashboard incident log (영어주의)

이 흐름만 봐도 잠깐 오류 코드가 떴다가 지나간 일이라고 축소해 말하긴 어렵다. 최소한 몇 시간 동안은 실제 업무 연속성이 흔들린 사건으로 보는 편이 맞아 보인다.

다음에 비슷한 일이 생기면 먼저 볼 것

장애가 날 때 보통 제일 먼저 하는 일은 로그아웃, 새로고침, 브라우저 교체다. 완전히 틀린 대응은 아니지만, 이번 사례처럼 공식 우회책이 없는 장애에서는 그보다 먼저 볼 순서가 있다.

• 상태 페이지에 incident가 올라왔는지 먼저 본다. Google Workspace Status Dashboard (영어주의)
• 같은 팀 계정도 같이 막히는지 확인한다. 혼자만의 세팅 문제인지 가늠하기 쉽다.
• 문서 초안, 조사 메모, 코드 질문처럼 바로 멈추면 곤란한 일은 다른 도구나 로컬 초안으로 잠깐 우회해 둔다.
• 오류 코드 뜻을 너무 깊게 해석하기보다, 장애 범위가 넓은지부터 본다.

특히 마지막이 중요하다. 1076이니까 브라우저 문제, 1099니까 내 계정 문제처럼 단정해 버리면 오히려 시간을 더 쓴다. 이번처럼 서비스 전체가 흔들리는 날에는 개인 세팅보다 공용 장애 여부를 먼저 보는 편이 낫다.

내 생각

이번 Gemini 장애는 AI가 아직 불안하다는 추상적인 말보다 더 실감 나는 사례였다. 이유는 간단하다. 고장 원인보다 먼저, 사람들이 이미 업무 중간 단계에 Gemini를 꽤 깊게 넣고 있었기 때문이다.

공식 기록만 놓고 봐도 장애는 분명했고, 몇 시간 이어졌다. 그런데 원인은 아직 공개되지 않았다. 요즘 AI를 자주 쓰는 사람이라면 성능 비교표만 볼 게 아니라, 상태 페이지를 보는 습관도 같이 가져가는 편이 좋겠다.

눈길을 끈 건 AI가 틀렸다가 아니라 AI가 아예 없어진 몇 시간이었다. 그 몇 시간이 길게 느껴졌다면, 이미 이 도구가 내 일 흐름 안으로 꽤 들어와 있다는 뜻이기도 하다.