- 증상: 아침 7시 30분에 돌기로 한 제미나이 예약 작업이 Something went wrong. Please try again later. 한 줄만 남기고 실패했습니다. 목록에는 «실패» 배지 옆에 «성공적으로 갱신했다»가 나란히 떠 있었고요
- 원인: 못 밝혔습니다. 수동 실행도, 지시문 직접 전송도, 한 줄짜리 질문도 이틀에 걸쳐 다섯 번 다 죽었습니다. 다만 일반 제미나이 대화창에서는 같은 지시문이 돌았습니다 — 제가 좁힌 건 거기까지입니다
- 해결: 없습니다. 위임을 접었습니다. 그런데 그날 아침 브리핑은 평소대로 왔습니다. 맡기기 전에 «안 되면 직접 읽는다»를 먼저 깔아 뒀거든요

혹시 이런 상황인가요?
AI에게 아침 일을 하나 맡겨 두고 잤는데, 일어나서 열어 보니 이 한 줄만 있습니다.
Something went wrong. Please try again later.
어느 단계에서 죽었는지, 무슨 도구를 부르다 실패했는지, 아무것도 안 알려 줍니다. 더 헷갈리는 건 그 옆입니다. 작업 목록에는 빨간 «실패» 배지가 붙어 있는데, 바로 아래 설명은 «워크스페이스 데이터를 분석하여 문서에 성공적으로 갱신했다»입니다.

저 설명은 직전에 성공했던 실행의 요약이 그대로 남아 있는 것입니다. 화면은 «지금 상태»와 «마지막으로 잘 됐을 때의 말»을 한 자리에 붙여 놓고, 어느 쪽이 오늘 것인지는 말해 주지 않습니다.
저도 똑같이 당했습니다 — 다행히 «안 될 때»를 먼저 정해 뒀습니다
저는 클로드와 이것저것 만들어 보고 있는데, 토큰 한도가 늘 문제였습니다.(이번에 큰 맘 먹고 MAX 20x로 업그레이드 했지만, 언제 또 자금난으로 Pro로 돌아갈지 모르기에…^^;) 그런 와중에 Gemini Spark의 루틴 작업 성능도 파악하고 현재 클로드와 구축해 놓은 브리핑과 연동도 시켜 보고 클로드 토큰도 아낄겸, 제미나이의 예약 작업 기능(«Spark»라고 부릅니다)에 일을 하나 맡겼습니다.
평일 아침 7시 30분에 캘린더와 메일을 훑어서, «내 폴더»에 있는 문서 하나를 오늘 내용으로 덮어쓰기. 매일 새 파일을 만들면 폴더가 금방 쓰레기통이 되니까, 지시문에 «기존 문서를 덮어써서 갱신하고, 절대 중복 문서를 추가로 만들지 말 것»을 넣어 두게 했습니다.
맡기기 전에 두 가지를 먼저 정했습니다.
- 폴백(안 될 때 돌아갈 자리)을 먼저 깐다. 그 문서(Spark에게 맡긴 작업의 생성물)가 없거나 날짜가 어제 것이면, 아침 브리핑은 그냥 캘린더와 메일을 직접 읽는다. 원래 하던 방식을 지우지 않는다. → “스파크가 일 잘 못하면 그냥 클로드 하던대로 하라!”
- 대체 실행자는 안 세운다. 이게 안 되면 다른 AI로 갈아타는 게 아니라, 그냥 원래대로 돌아간다. → 이게 뭔 말이냐? 스파크의 작업이 실패하면 그냥 기존에 하던대로 클로드 브리핑 루틴(지메일, 캘린더 스캔 및 요약)이 돌면 되는데, 굳이 또 거창한 이름을 붙여서(구글 워크스페이스 스캔 에이전트) 별도 에이전트를 또 생성하고자 하길래, 클로드에게 말했습니다. “새로 만들지 말고 그냥 원래대로 하면 되잖아?”
사흘을 지켜보기로 했습니다. 첫날은 예약 시각보다 12분 늦게 문서가 만들어졌고, 둘째 날은 1분 늦게 갱신됐고, AI에게 실제 메일·일정과 대조해 달라고 했더니 지어낸 일정도 빠뜨린 메일도 없다고 했습니다. 여기서 «둘째 날은 멀쩡했다»는 사실이 중요합니다. 나중에 «지시문이 잘못됐나»를 의심할 때, 같은 지시문으로 하루는 완벽했다는 기록이 그 가능성을 지워 주거든요.
그리고 셋째 날 아침, 위의 그 화면을 봤습니다. (참고로 같은 날 아침 카톡으로 온 리포트 링크도 도메인만 남은 채 와서 404가 떴습니다. 틀린 건 글자 한 줄이었는데, 다른 이야기라 넘어갑니다.)
원인을 여기까지 좁혔습니다
실패 화면이 아무 말도 안 해 주니, 다시 돌려 보는 게 유일한 진단이었습니다. 순서대로 좁혀 갔습니다.
① 수동으로 «지금 실행»을 눌렀습니다. «사고 중» 표시가 잠깐 뜨더니 멈췄고, 채팅 입력창에 예약해 둔 지시문만 덩그러니 채워진 채 대기 상태가 됐습니다. 정시 스케줄러가 아니라 실행 자체에서 죽는다는 뜻입니다.
② 지시문을 직접 붙여넣어 보냈습니다. 메시지는 올라갔는데 답이 없고, 입력창 오른쪽에 ■ 중지 버튼만 남은 채 멈췄습니다. 34분 뒤에 목록에 «실패» 배지가 붙었습니다. 같은 모양으로 세 번째였습니다.

지시문에 있던 실제 폴더 이름은 «내 폴더»로 바꿔 표기했습니다.
③ 다음 날, 한 줄짜리 질문을 던졌습니다. «왜 예약된 작업이 실행 실패되는거야?» 이건 메일도 캘린더도 열 필요가 없는 질문입니다. 그런데 답이 아예 안 왔습니다.

여기서 갈림길이 정리됐습니다. 도구를 하나도 안 쓰는 질문에도 답이 없다면, 메일·캘린더 커넥터가 끊긴 게 아니라 대화 기능 자체가 이 계정에서 멈춘 것입니다(여기까지는 추정입니다). 커넥터를 하나씩 떼어 보자던 AI의 다음 계획도 의미가 없어졌습니다.
커넥터 — AI가 내 메일·캘린더·드라이브를 읽을 수 있게 연결해 주는 통로. 이게 끊기면 «읽기»만 실패합니다.
외부 사정도 AI에게 찾아봐 달라고 했는데, 딱 잘라 말할 수 있는 게 없었습니다. 화면 오른쪽 위에는 «베타» 배지가 붙어 있습니다. 구글 워크스페이스 상태 대시보드에는 그 이틀간 제미나이 장애가 0건으로 나오지만, 그 대시보드는 워크스페이스용이라 개인용 제미나이 앱과 베타 기능은 아예 범위 밖입니다. 미국 시간으로 전날 낮에 여러 AI 서비스가 동시에 흔들린 일이 있긴 했는데(기사 하나 기준입니다), 복구 선언이 제 작업 실패보다 세 시간 앞이라 원인으로 묶을 수 없었습니다.
여기서 막혔습니다 — 그런데 «되는 쪽»이 더 무서웠습니다
마지막 갈림이 하나 남아 있었습니다. 예약 작업 말고 그냥 일반 제미나이 대화창에 같은 지시문을 넣어 보기. 여기서 되면 예약 기능(베타)의 문제고, 여기서도 안 되면 계정 문제입니다.
됐습니다. 그것도 A/B 두 가지 답을 주면서, 오늘 날짜가 찍힌 요약본을 제대로 만들어 냈습니다.

메일 발신자와 제목 줄은 회색으로 가렸고, 폴더 이름은 «내 폴더»로 바꿔 표기했습니다.
«아, 그럼 여기로 옮기면 되겠네» 하고 넘어갈 뻔했습니다. 그런데 드라이브를 열어 보고 손이 멈췄습니다.
«내 폴더»의 원래 문서는 그대로였고, 드라이브 맨 바깥에 «V2»라는 이름의 새 문서가 만들어져 있었습니다. 지시문에 «기존 문서를 덮어쓰고 중복은 만들지 마라»라고 분명히 적어 둔 그 항목을, 정확히 어긴 겁니다. 게다가 A/B로 답을 두 개 준 탓에 새 문서도 그만큼 늘었습니다.
그러니까 이건 «실패»가 아니었습니다. 답도 나왔고, 내용도 맞았고, 계약만 틀렸습니다. 눈에 보이는 결과물만 보면 성공처럼 생겼는데, 며칠 두면 폴더가 사본으로 불어나는 종류의 성공이요. 문제가 있으면 최소한 문제가 있다는걸 알고 가야합니다. 이건 성공이라 할 수 없었습니다.(그리고 내용에 할루시네이션도 다소 포함되어 있었고요.)
그래서 «일반 대화창으로 옮기면 된다»는 성립하지 않았고, 저는 이렇게 정리했습니다.
Spark가 예약작업 에이전트로서 부적합해. 예약된 작업 모두 수동실행해도 안되고 있어. 원인은 몰라.
원인을 모른 채로 접었습니다. 베타 기능이고, 파고드는 비용이 이 위임으로 얻을 이득보다 커졌으니까요.
그런데 접는 데 든 값이 얼마였냐면 — 거의 0이었습니다. 아침 브리핑은 애초에 캘린더와 메일을 직접 읽고 있었으니 기능이 빠진 게 없고, «문서를 먼저 보고 없으면 직접 읽는» 연결 코드는 검증 전이라 아직 넣지도 않았으니 고칠 코드도 없었습니다. 실질적으로 줄어든 건 주 1회로 걸어 뒀던 자료 확인 하나인데, 그마저 첫 실행 전이었습니다. 분기에 한 번 직접 보는 것으로 내렸습니다.
다른 AI로 옮기지 않은 이유도 같은 계산입니다. 옮기면 아침 7시 30분 루틴과 8시 브리핑이 같은 메일함을 두 번 읽습니다. 직접 읽는 것보다 비싸지죠. 위임해서 얻는 게 없어지면 그건 위임이 아니라 그냥 부품 하나 더입니다.
제미나이의 예약 작업(Spark)은 관찰 시점(2026년 9월 초)에 베타 기능이었고, 여기 적은 건 한 계정에서 사흘 관찰한 결과입니다. 다른 계정에서도 같다는 뜻이 아닙니다.
같은 실수를 막는 체크리스트
AI에게 반복 작업을 맡기기 전에 저는 이제 이렇게 봅니다.
- «안 되면 뭘 하지»를 맡기기 전에 적었는가. 맡긴 다음에 생각하면 늦습니다. 저는 «원래 하던 방식을 지우지 않는다» 한 줄로 뒀습니다.
- 결과물의 계약을 한 줄로 못박았는가. 파일은 한 개, 첫 줄에 만든 시각, 내용 없으면 «없음»이라고 적기. 형식을 정해 두면 어긋난 걸 눈이 아니라 규칙으로 잡습니다.
- «됐는지»가 아니라 «계약대로 됐는지»를 보는가. 저는 결과 화면만 보고 넘어갈 뻔했습니다. 폴더에서 파일 개수를 세는 것이 답을 읽는 것보다 정확했습니다.
- 실패 화면의 문장을 믿지 않는다. 목록에 붙은 설명은 직전에 성공했던 실행의 것일 수 있습니다.
- 재실행이 진단이고, 증상이 달라지는 순간이 갈림길이다. 제 경우엔 세 번이 같은 모양이라 실행하는 쪽을 의심했고, 마지막에 «아무 답도 없음»으로 바뀌면서 방향이 정해졌습니다.
- 원인 규명 비용이 위임 이득보다 커지면 접는다. 안 밝히고 접는 것도 결정입니다.
FAQ
Q. 그럼 제미나이 예약 작업은 쓰지 말라는 건가요?
아닙니다. 베타 기능을 한 계정에서 사흘 본 게 전부고, 일반 대화창은 지시문을 수행하기는 했고요. 제가 접은 건 제미나이가 아니라 확인 장치 없이 아침을 통째로 맡기는 방식입니다.
Q. 원인을 더 파 보지 그랬어요?
파고 싶었죠. 그런데 화면이 어느 단계에서 죽었는지를 끝내 안 알려 줬습니다. 볼 수 있는 게 «실패»라는 결과뿐이라, 파는 시간이 자동화로 아끼는 시간보다 길어졌습니다.
Q. 폴백은 어떻게 만드나요?
거창한 게 아닙니다. 맡기기 전에 하던 방법을 안 지우면 그게 폴백입니다. 저는 «직접 읽기»를 그대로 뒀고, 그래서 예약 작업이 죽은 날에도 아침은 평소와 똑같았습니다. AI 루틴이 어떤 식으로 넘어지는지는 AI 루틴이 죽는 3가지 방식에도 정리해 뒀습니다.
한 줄 교훈
«된다»와 «계약대로 된다»는 다릅니다. 그리고 안 될 때 돌아갈 자리를 만들어 둔 위임만 위임입니다 — 그게 없으면 그냥 아침을 걸고 하는 도박이더라고요.
원인을 못 밝히고 접었는데도 손해가 아니었던 건, 맡기기 전에 «안 되면 직접 읽는다» 한 줄을 적어 뒀기 때문입니다. 그 한 줄이 사흘 뒤에 값을 다 했습니다.