읽는 데 약 11분
매일 아침 7시에 휴대폰으로 브리핑이 도착하도록 예약 실행을 걸어두었다. 밤사이 흐름과 그날 볼 만한 뉴스를 AI가 정리해 Notion에 저장하고 Telegram으로 보내주는 구성이었고, 처음 며칠은 기대한 대로 돌아갔다.
그러다 하루는 리포트 맨 위 날짜가 오늘이 아니라 어제로 찍혀 있었다. 어제 것이 다시 온 줄 알았는데, 확인해 보니 그날 아침 7시에 정상적으로 실행된 리포트였다.
이상한 점은 같은 AI에게 대화창에서 오늘이 며칠이냐고 물으면 한 번도 틀리지 않았다는 것이다. 날짜가 틀리는 것은 예약 실행으로 만든 리포트뿐이었다.
이 AI 날짜 오류는 루틴을 직접 설정해본 글에서 한 문단으로 지나갔지만, 실제로는 다섯 번을 고쳤다. 다섯 번 모두 AI가 인터넷에서 찾은 날짜를 보고 오늘이 며칠인지 판단하게 하는 방식이었고, 바뀐 것은 날짜를 찾는 곳뿐이었다.
목차
겉으로는 멀쩡했던 AI 날짜 오류
리포트의 형식은 평소와 같았다. 6월 12일 아침에 받은 리포트를 예로 들면, 뉴스와 지수는 빠짐없이 정리돼 있었는데 모든 항목이 하루씩 전날로 당겨져 있었다.
| 항목 | 기대한 값 | 실제로 나온 값 |
|---|---|---|
| 발행일 | 6월 12일 | 6월 11일 |
| 미국 지수 | 6월 11일 종가 | 6월 10일 종가 |
| 국내 지수 | 6월 11일 종가 | 6월 10일 종가 |
| 뉴스 범위 | 11일 저녁 ~ 12일 오전 | 10일 저녁 ~ 11일 오전 |
네 항목이 똑같이 하루씩 밀려 있어서, 리포트 안에서는 앞뒤가 서로 맞았다. 틀린 값끼리 맞물려 있었던 셈이다.
처음엔 그냥 넘겼다.
그런데 그 뒤로도 비슷한 일이 반복되니 점점 거슬렸다. 날짜가 틀린 리포트라면 그 안의 내용도 믿기 어렵고, 그래서 AI 날짜 오류를 제대로 고쳐보기로 했다.
AI 날짜 오류는 왜 예약 실행에서만 생겼나
AI는 엄청난 양의 책을 읽은 도서관 사서와 비슷하다. 무엇을 물어도 막힘없이 대답하지만, 지금 몇 시냐고 물으면 사서도 시계를 봐야 한다. 오늘 날짜는 AI가 배운 지식이 아니라 실행되는 그 순간의 정보이기 때문이다.
대화창에서는 앱이 그 시계를 대신 보여준다. Anthropic 공식 안내에 따르면 Claude 웹과 앱은 대화를 시작할 때마다 오늘 날짜를 AI에게 먼저 넘겨준다.
예약 실행에서는 정해진 시각에 클라우드 서버에서 루틴이 혼자 시작된다. 이때 루틴이 AI에게 넘겨주는 날짜가 문제였다.
이 AI 날짜 오류의 원인은 다섯 번을 다 고친 뒤에야 알았다. 처음 문제를 붙잡았을 때는 루틴에 날짜를 넘겨주는 기능이 아예 없다고 생각했고, 그래서 AI가 인터넷에서 날짜를 찾아오게 하는 쪽으로만 고쳤다.
나중에 확인한 Claude Code의 GitHub 이슈에 따르면, 루틴도 날짜를 넣어주긴 하지만 사용자가 있는 곳의 시간이 아니라 세계 표준시(UTC) 기준이다. 한국 아침 7시는 세계 표준시로 전날 밤 10시라서, 루틴이 받는 날짜는 늘 어제가 된다.
일본 시간 새벽 5시 30분에 돌린 루틴에서 날짜가 하루 밀렸다는 보고가 그 이슈의 출발점이었다. 내 리포트가 아침 7시마다 딱 하루씩 밀린 것과 같은 모양이다. 이슈에는 루틴 안에서 한국 시간대를 지정해 날짜를 다시 확인하게 하는 우회 방법도 적혀 있었다.
AI 날짜 오류를 다섯 번 고쳤다
처음에는 AI 날짜 오류를 단순한 설정 실수라고 생각했다. 프롬프트 어딘가에서 날짜를 계산하는 부분이 잘못됐겠지 하고 고쳤는데, 고치고 나면 새로운 방식으로 또 틀렸다.
오늘 기사를 찾으면 오늘을 알 것 같았다
검색 도구가 연결돼 있으니 가장 최근 기사의 날짜를 오늘로 잡으면 된다고 봤다. 그런데 오전 7시에는 당일 기사가 아직 거의 올라오지 않는다.
검색 결과에서 가장 최신이 어제 저녁 기사였고, AI는 그 날짜를 오늘로 확정했다. 새벽의 예약 실행은 당일 콘텐츠가 아직 없는 시간대라는 것을 놓친 것이다.
주가 종가에 하루를 더했다
다음에는 미국 지수의 최신 종가 날짜를 가져와 하루를 더하게 했다. 어제 장이 마감됐으니 종가 날짜에 하루를 더하면 오늘이라는 계산이다.
이 방법은 주말과 미국 공휴일에 무너졌다. 금요일 종가를 보고는 오늘이 토요일인지 일요일인지 월요일인지 구분하지 못했고, 월요일이 미국 휴장일이면 화요일 아침에도 토요일이라는 답이 나왔다.
두 곳이 하루 차이면 맞다고 봤다
한 곳은 틀릴 수 있으니 날씨 페이지에서는 오늘 날짜를, 주가에서는 미국 장이 마감된 날짜를 읽게 했다. 한국 아침이면 미국 장은 전날 마감이니, 두 날짜가 하루 차이일 때만 통과시켰다.
6월 11일 아침에 이 확인이 무너졌다. 당시 따져본 바로는 주가 쪽이 저장돼 있던 옛 데이터로 9일을 돌려주고 날씨 쪽은 10일을 읽었다. 둘 다 하루씩 밀려 있으니 차이는 여전히 하루였다.
틀린 두 값이 서로 맞다고 확인해 준 꼴이다. 그날 아침 브리핑은 10일 날짜로 나왔고, 확인 장치를 하나 더 붙였는데 오히려 틀린 날짜가 확인된 값처럼 통과했다.
날씨 페이지는 늘 오늘일 거라 믿었다
그래서 주가는 빼고 날씨 페이지 하나로 오늘 날짜를 정하게 했다. 날씨 예보 페이지는 새벽에도 그날 날씨를 보여주니, 페이지에 적힌 날짜는 늘 오늘일 거라고 생각했다.
그런데 인터넷 페이지는 빨리 열리도록 전에 만든 화면을 저장해 두었다가 그대로 보여주는 경우가 있다. 이렇게 저장해 둔 옛 화면을 캐시라고 부른다. AI가 검색 도구로 가져오는 페이지도 검색 서비스가 전에 저장해 둔 사본일 때가 많다.
6월 12일 아침 AI가 읽은 날씨 페이지가 그런 화면이었다. 제목에는 「6월 11일 목요일」이 적혀 있었고, 예보 문장에는 「내일(12일) 흐림」이 들어 있었다.
12일을 내일이라고 부르고 있으니 전날인 11일에 만들어진 화면이다. 사람이라면 어제 페이지가 떴다는 것을 바로 알아챘겠지만, AI는 이 페이지를 오늘 것으로 믿고 제목의 11일을 오늘 날짜로 정했다.
앞에서 표로 본 6월 12일 리포트의 AI 날짜 오류가 바로 이 경우였다.
주소에 날짜가 박힌 페이지로 옮겼다
환율이나 증시 시세 페이지는 인터넷 주소 자체에 날짜가 들어가는 경우가 많다. 제목에는 저장된 옛 내용이 남을 수 있어도 주소는 그렇지 않으니 이쪽이 낫다고 판단했다.
어제·전일·전날이라는 말이 붙은 날짜는 최신처럼 보여도 채택하지 않도록 조건도 붙였다. 그래도 검색 결과의 요약문이 전날 날짜를 보여줄 때는 또 틀렸다.
다섯 번 모두 같은 방식이었다
AI 날짜 오류를 막으려던 다섯 방법의 공통점은 인터넷에 있는 기사·주가·날씨·주소에서 날짜를 찾아 와, 그것을 보고 AI가 오늘이 며칠인지 판단하게 했다는 것이다. 찾는 곳만 바뀌었을 뿐, 정확한 날짜를 AI에게 직접 알려주는 방법은 한 번도 쓰지 않았다.
검색 결과에는 저장된 옛 내용이 섞이고 요약문은 실시간이 아니다. 프롬프트에 조건을 아무리 자세히 적어도, AI가 판단하는 과정에서 다른 날짜가 끼어들 여지는 늘 남아 있었다.
요청 문장을 다듬는 방법은 프롬프트 패턴을 정리한 글에 적어두었지만, 이 문제는 문장을 다듬어서 풀리는 종류가 아니었다.
이 공통점이 보인 것은 실행 기록 덕분이다. AI 날짜 오류가 난 리포트에는 틀린 날짜만 찍혀 있을 뿐 그 날짜가 어디서 왔는지는 나오지 않는다.
그래서 리포트를 만들 때마다 날짜를 어디서 가져왔는지 한 줄씩 남기도록 해두었고, 다섯 번의 수정 동안 그 한 줄이 매번 틀린 곳을 가리켜 줬다.
날짜를 밖에서 알려주는 방법은 공사가 컸다
AI 날짜 오류를 없애는 근본적인 방법은 오늘 날짜를 AI가 찾게 하지 않고, 정확한 날짜를 AI 밖에서 정해 넘겨주는 것이다. 처음 검토한 것은 구글의 무료 자동화 도구인 Google Apps Script였다.
매일 아침 이 도구가 한국 시간으로 오늘 날짜를 계산한 뒤, AI를 불러 오늘이 몇 월 며칠인지부터 알려주고 브리핑을 시키는 방식이다. 날짜를 AI가 찾을 필요가 아예 없어진다.
문제는 브리핑이 돌아가는 구성이었다. 지금은 Claude 루틴 하나가 자료를 모으고 정리해서 Notion에 저장하고 Telegram으로 보내는 일까지 전부 맡고 있다.
Apps Script가 AI를 부르는 쪽이 되면, 루틴이 하던 Notion 저장과 Telegram 발송을 Apps Script에서 처음부터 다시 만들어야 했다. AI 날짜 오류 하나를 고치려고 이미 돌아가는 브리핑을 통째로 옮기는 일이라 이 방법은 보류했다.
그래서 이 문제는 해결됐을까
내 브리핑의 AI 날짜 오류는 다섯 번의 수정으로는 끝나지 않았다. 평일 날짜가 제자리를 찾은 것은 Apps Script보다 훨씬 작은 방법으로, 브리핑은 그대로 둔 채 오늘 날짜만 AI 밖에서 정해 넣어주고 나서였다.
GitHub에 날짜 파일을 두고 루틴이 그 파일을 가장 먼저 읽게 한 방식인데, 그 과정은 따로 적는다.
완전히 끝난 것은 아니었다. 6월 19일 미국 휴장일이 낀 며칠 동안 날짜가 하루 앞서 찍힌 리포트가 나왔고, 같은 날짜의 리포트가 두 번 만들어지기도 했다. 두 번째 시도에서 공휴일에 무너졌던 것처럼, 휴장일이 끼면 다시 흔들렸다.
7월 초에는 날짜와 다른 문제가 나왔다. 7월 5일과 6일 이틀 동안 루틴 기록은 완료로 떠 있는데 리포트가 오지 않았다.
확인해 보니 GitHub의 날짜 파일은 7월 6일로 정확히 바뀌어 있었다. 그런데 루틴이 날짜 확인부터 발송까지의 단계를 하나도 실행하지 않고, 이 지시문으로 무엇을 해야 하느냐는 질문만 남긴 채 끝나 있었다.
AI 날짜 오류가 아니라 루틴 실행 자체의 문제였고, 원인은 끝내 확정하지 못했다. 그 뒤로도 간혹 문제가 생겨 지금은 이 아침 브리핑 예약 작업을 쓰지 않고 있다.
날짜를 넘겨주는 플랫폼 쪽도 아직이다. 앞에서 본 GitHub 이슈는 2026년 9월 현재도 열린 상태로 남아 있다. 같은 구성을 새로 만든다면, 예약 실행이 받는 날짜가 한국 시간 기준인지부터 확인해 보는 것이 좋다.
다섯 번을 겪으며 남은 교훈은, 같은 증상이 되풀이될 때는 새 방법을 하나 더 붙이기보다 근본 원인을 찾는 데 시간을 써야 한다는 것이다. 이 경우 근본 원인은 날짜를 찾는 방법이 아니라 날짜를 넘겨받는 구조에 있었다.
지금 예약해 둔 작업에도, AI가 스스로 알아내도록 맡겨 둔 날짜 같은 값이 숨어 있지 않을까?