자동화 스케줄이 읽는 시계는 도구마다 다르다 — n8n의 뉴욕과 Zapier의 UTC가 갈리는 5곳

자동화 도구를 하나 붙여 놓고 매일 오전 9시로 스케줄을 걸어 둔 뒤에, 로그를 열어 보면 엉뚱한 시각에 돌아 있는 일이 있어요. 코드가 틀린 것도 아니고 cron 표현식이 틀린 것도 아닌데 그래요.

결론부터 말하면 원인은 대개 표현식이 아니라 그 표현식을 읽는 시계예요. 다섯 도구가 서로 다른 시계를 기본으로 삼고 있고, 그 기본값을 덮어쓰는 층도 도구마다 다른 자리에 있어요. n8n은 인스턴스 시간대를 뉴욕으로 두고 시작하고, Zapier의 계정 기본값은 UTC이고, GitHub Actions는 UTC로 돌면서 cron 항목 옆에 시간대를 붙일 수 있고, Apps Script는 스크립트에 붙은 시간대를 읽고, Make는 조직 시간대로 실행하면서 화면 표시는 다른 설정으로 해요. 다만 도구마다 재지정이 걸리는 층이 달라서, "시간대를 맞췄다"는 말이 도구마다 다른 뜻이 돼요. 아래에서 문서 문장을 하나씩 열어 볼게요.

자동화 스케줄 시간대 — 다섯 도구가 읽는 시계를 한 표로

먼저 답부터 표로 놓을게요. 세로로 읽으면 "손대지 않았을 때"의 값이 도구마다 다르다는 게 보이고, 가로로 읽으면 한 도구 안에서 실행 시각과 표시 시각이 어디서 갈리는지가 보여요.

출처: 각 도구의 공식 문서. n8n Docs, GitHub Docs, Google Apps Script 문서, Zapier Help Center, Make Help Center를 2026년 8월 20일에 각각 직접 열었어요.

맨 오른쪽 칸을 조금 풀어 둘게요. 한 도구의 행이 문서 한 장에서 나온 게 아니라서, 그 행의 기준값을 적어 둔 페이지의 갱신일을 대표로 넣었어요. n8n 은 페이지마다 갱신일이 따로 찍혀 있어서 환경변수 문서가 2026-06-24, 노드 문서가 2026-08-18, 워크플로 설정 문서가 2026-07-10, Cloud 문서가 2026-06-23 으로 넉 장이 다 달라요. Apps Script 는 설치형 트리거 문서와 매니페스트 문서가 2026-07-22 인데 ClockTriggerBuilder 레퍼런스만 2026-04-13 이라 두 값을 나란히 적었어요. Make 는 네 페이지 다 화면에 갱신일이 없어서 칸을 비운 셈인데, 페이지 소스의 메타데이터까지 보면 Manage time zones 가 2026-08-20, Scenario settings 가 2026-07-01, Schedule a scenario 가 2026-06-30, Date and time functions 가 2026-06-09 이에요.

표에서 눈에 걸리는 건 세 가지예요. 첫째, 기본값이 하나로 수렴하지 않아요. 뉴욕과 GMT와 UTC가 한 표 안에 같이 있어요. 둘째, 재지정 층의 깊이가 다르고 개수도 달라요. n8n은 두 층이고 Apps Script도 두 층인데, Make는 스케줄 쪽에 층이 없어요. 셋째, 표시 시각을 따로 규정한 문장을 찾은 도구가 둘뿐이에요. 이번에 읽은 문서 범위에서는 Zapier와 Make만 실행 시각과 표시 시각을 갈라 놓았어요.

n8n — 손대지 않으면 뉴욕이고, 셀프호스팅과 Cloud가 서로 달라요

n8n 셀프호스팅 문서의 환경변수 표부터 볼게요. GENERIC_TIMEZONE 행의 Default 칸에 적힌 값이 America/New_York 이에요. 같은 행의 Description 원문은 이래요.

The n8n instance timezone. Important for schedule nodes (such as Cron).

인스턴스 시간대이고 Cron 같은 스케줄 노드에 중요하다는 뜻이에요. 여기서 뉴욕이 나오는 게 좀 뜬금없어 보이는데, 이게 이 도구의 출고 기본값이에요. 서버를 어디에 올렸는지, 운영체제 시간대가 무엇인지와 상관없이 이 환경변수를 지정하지 않으면 이 값으로 동작해요.

노드 쪽 문서는 읽는 순서를 더 명확하게 적어요.

The node relies on the timezone setting. n8n uses either: 1. The workflow timezone, if set.

The n8n instance timezone, if the workflow timezone isn't set. The default is America/New York for self-hosted instances.

워크플로 시간대가 먼저이고, 없으면 인스턴스 시간대예요. 두 층 구조라는 뜻이에요. 그리고 바로 다음 문장이 Cloud를 따로 떼어내요.

n8n Cloud tries to detect the instance owner's timezone when they sign up, falling back to GMT as the default.

Cloud는 가입 시점에 인스턴스 소유자의 시간대를 감지하려 하고, 그게 안 되면 GMT로 떨어진다고 적혀 있어요. 같은 제품인데 설치 형태에 따라 기본값이 뉴욕과 GMT로 갈려요. 셀프호스팅에서 만든 워크플로를 Cloud로 옮기거나 그 반대로 옮길 때 이 자리를 안 보면 같은 JSON이 다른 시각에 돌아요.

워크플로 설정 문서 쪽 문장은 더 직접적이에요.

Sets the timezone for this workflow. The timezone setting is important for the Schedule Trigger node... If you don't configure the workflow or instance timezone, n8n defaults to the EDT (New York) timezone.

두 층을 모두 비워 두면 뉴욕으로 떨어진다는 걸 문서가 직접 적어 둔 셈이에요.

Cloud에서 값을 바꾸는 경로도 문서에 있어요. 대시보드에서 Manage 를 고르고 Timezone 드롭다운을 원하는 시간대로 바꾸는 순서예요. 문서는 이 설정이 Schedule Trigger와 Date & Time 노드에 영향을 준다고 적어요. 스케줄만이 아니라 날짜를 다루는 노드까지 같은 설정을 본다는 뜻이라, 시간대를 바꾸면 확인할 자리가 하나 더 늘어요.

GitHub Actions — UTC가 기본인데, cron 항목 옆에 키가 하나 생겼어요

여기가 이 글에서 가장 자주 낡는 자리예요. 워크플로 문법 문서의 on.schedule 절이 이렇게 적어요.

By default, scheduled workflows run in UTC. You can optionally specify a timezone using an IANA timezone string for timezone-aware scheduling.

기본은 UTC이고, IANA 시간대 문자열로 시간대를 선택 지정할 수 있다는 문장이에요. 문서가 함께 실은 예제는 이런 형태예요.

on:
  schedule:
    - cron: '30 5 * * 1-5'
      timezone: "America/New_York"

문서는 이 예제를 두고 America/New_York 시간대 기준 오전 5시 30분에 월요일부터 금요일까지 실행된다고 설명해요. 키가 놓이는 자리를 눈여겨봐 주세요. timezone 은 워크플로 전체에 한 번 거는 값이 아니라 각 cron 항목 옆에 붙어요.

바로 아래에 문서가 실은 다음 예제가 이 구조를 한 번 더 보여 줘요. 하나의 워크플로가 여러 schedule 이벤트로 트리거될 수 있다고 적으면서 cron 두 줄을 나란히 놓는데, 이 예제에는 timezone 이 붙어 있지 않고 문서는 두 시각을 UTC로 설명해요. 그러니까 항목마다 따로 붙는 키이고, 안 붙인 항목은 기본값인 UTC로 남아요. 다만 항목 일부에만 붙였을 때를 콕 집어 적은 문장이 있는 건 아니에요. 키가 cron 항목 안에 놓이는 구조와 기본이 UTC라는 문장을 겹쳐 읽은 결과예요.

이 키가 언제 들어왔는지가 중요해요. GitHub 체인지로그 글의 게시일이 2026년 3월 19일이고, 그 글이 이렇게 적어요.

You can now specify an IANA timezone on your cron schedules instead of being locked to UTC.

이제 UTC에 묶이는 대신 cron 스케줄에 IANA 시간대를 지정할 수 있다는 문장이에요. 그 전에 쓰인 글과 사내 위키가 지금도 "UTC 고정"이라고 적어 두고 있는 이유가 여기 있어요. 검색으로 답을 찾을 때 가장 위에 뜨는 글이 그 시점 이전 것이면 낡은 답을 그대로 받게 돼요.

서머타임 처리도 같은 절에 적혀 있어요.

For schedules that set timezone to a time zone that observes daylight saving time (DST), during DST spring-forward transitions, scheduled workflows in skipped hours advance to the next valid time. For example, a 2:30 AM schedule advances to 3:00 AM.

서머타임을 쓰는 시간대를 지정했을 때, 봄에 시계가 앞으로 뛰면서 사라진 시각에 걸린 스케줄은 다음 유효한 시각으로 밀린다는 뜻이에요. 문서가 든 예가 새벽 2시 30분 스케줄이 3시로 밀리는 경우예요. 가을에 시계가 뒤로 갈 때는 어떻게 되는지를 적은 문장은 이 절에서 찾지 못했어요. 다른 판본의 같은 절을 한 번 더 열어도 없었어요.

시간대와 별개인 제약 세 가지도 같이 적어 둘게요. 스케줄이 안 도는 원인이 시간대가 아니라 이쪽인 경우가 많거든요.

출처: GitHub Docs의 Events that trigger workflows 문서 중 schedule 절. 2026년 8월 20일 조회.

세 번째 줄이 특히 조용히 물어요. 공개 저장소에 스케줄만 걸어 두고 커밋을 오래 안 하면, 시간대를 아무리 맞춰도 워크플로 자체가 꺼져 있어요. 두 번째 줄도 실무에서 체감되는데, 매시 정각이 혼잡 시간대라고 문서가 직접 적어 뒀으니 정각을 피해 거는 편이 나아요.

Google Apps Script — 시계는 스크립트에 붙어 있고, 시각은 정확히 그 시각이 아니에요

Apps Script의 시간 기반 트리거는 읽는 시계가 스크립트에 붙어 있어요. 설치형 트리거 문서가 실행 시각을 설명하면서 쓰는 표현이 in the time zone that your script is set to, 곧 스크립트에 설정된 시간대라는 표현이에요.

그 시간대가 어디에 저장되는지는 매니페스트 문서에 있어요. appsscript.json 의 최상위 필드 timeZone 이고, 타입은 문자열이에요. 설명 원문은 이래요.

The script time zone in a ZoneId value such as "America/Denver".

파일 하나에 한 줄로 들어 있다는 게 포인트예요. 프로젝트를 복제하거나 템플릿에서 시작했다면 그 한 줄이 원본의 값 그대로 따라와요.

여기서 정찰 단계에 한 번 틀릴 뻔한 자리가 있어요. 설치형 트리거 문서만 읽으면 "스크립트 시간대 하나뿐"이라고 결론 내기 쉬운데, 레퍼런스를 열면 달라요. ClockTriggerBuilder 에 이런 메서드가 있어요.

inTimezone(timezone) — Specifies the timezone for the specified dates/time when the trigger runs. By default, the timezone is that of the script.

트리거 단위로 시간대를 따로 줄 수 있고, 기본값이 스크립트의 시간대예요. 그러니까 Apps Script도 두 층이에요. 다만 두 번째 층은 화면 설정이 아니라 코드로만 열려요.

그리고 이 도구에는 다른 넷에 없는 특징이 하나 더 있어요. 지정한 시각에 정확히 돌지 않는다는 걸 문서가 먼저 밝혀 둬요.

The time might be slightly randomized—for example, if you create a recurring 9 AM trigger, Apps Script chooses a time between 9 AM and 10 AM, then keeps that timing consistent from day to day so that 24 hours elapse before the trigger fires again.

오전 9시 반복 트리거를 만들면 오전 9시와 오전 10시 사이의 시각을 고르고, 그 타이밍을 날마다 일관되게 유지해서 다시 발화하기까지 24시간이 지나도록 한다는 뜻이에요. 코드 쪽 레퍼런스도 같은 성격의 문장을 적어요. nearMinute(minute) 은 지정한 분의 앞뒤 15분 범위라고 적고, atDate(year, month, day) 는 기본적으로 자정 근처의 앞뒤 15분이라고 적어요. nearMinute() 을 호출하지 않으면 무작위 분값이 쓰인다고도 적혀 있어요.

Zapier — Zap이 아니라 계정 시계를 읽어요

Zapier는 층이 하나예요. 그런데 그 하나가 사람들이 예상하는 자리에 없어요. 스케줄 도움말 문서가 이렇게 적어요.

Schedule triggers use the timezone set in your Zapier account, not the timezone set in your Zap.

Zap에 설정된 시간대가 아니라 계정에 설정된 시간대를 쓴다는 문장이에요. 문장 뒷부분이 부정형으로 끊어 놓은 게 눈에 띄죠. Zap 쪽에도 시간대라는 개념이 있는데 스케줄 트리거는 그걸 안 본다는 뜻이에요.

그럼 Zap 쪽 시간대는 어디 있느냐 하면, 에디터를 설명한 다른 도움말 문서에 적혀 있어요. 좌측 사이드바 컨트롤을 하나씩 소개하는 절인데, Zap details 패널을 두고 이 패널에서 Zap이 속한 폴더와 Zap 시간대를 설정하고 Zap 템플릿을 만들 수 있다고 적어요. 그러니까 설정 자리는 분명히 있고, 에디터 좌측 사이드바에 있어요. 스케줄 트리거만 그 값을 안 볼 뿐이에요. 이 자리가 헷갈리는 이유가 여기 있어요. Zap 화면 안에 시간대 설정이 보이니까 그걸 바꾸면 스케줄도 따라올 것 같은데, 실제로 스케줄이 읽는 칸은 계정 쪽이에요.

계정 기본값은 다른 문서에 있어요.

By default, your account is set to the UTC time zone.

기본적으로 계정이 UTC로 설정되어 있다는 문장이에요. 바꾸는 경로는 프로필 설정에서 Timezone 드롭다운을 열어 고르고 저장하는 순서예요.

그런데 앞서 본 스케줄 문서에 한 줄이 더 있어요. 계정 기본값 문서가 아니라 그쪽이에요. 이걸 놓치면 "바꿨는데 안 바뀐다"가 돼요.

If you change your account timezone, turn the Zap off and back on for the change to take effect.

계정 시간대를 바꿨으면 Zap을 껐다가 다시 켜야 변경이 적용된다는 문장이에요. 설정 화면만 보면 이미 바뀐 것처럼 보이는데 동작은 옛 값으로 남아 있는 상태가 생겨요. 다섯 도구 중에서 시간대 설정을 두고 이런 추가 동작을 명시한 건 여기 하나예요.

다만 성격이 같은 문장이 n8n에도 하나 있어요. Schedule Trigger 노드 문서의 Custom (Cron) 절인데, 크론 표현식에 변수를 쓸 수는 있지만 그 값은 워크플로를 퍼블리시할 때만 평가된다고 적어요. 퍼블리시한 뒤에 설정에서 변수 값을 바꾸면 크론 스케줄은 안 바뀌고, 다시 평가시키려면 워크플로를 언퍼블리시했다가 다시 퍼블리시하라고 이어서 적고요. 대상이 시간대가 아니라 변수라는 점만 다르지, "저장했는데 반영이 안 된다"가 생기는 구조는 똑같아요.

트리거 간격 자체가 왜 어긋나 보이는지를 따로 파고들었다면 웹훅과 폴링의 차이와 도구별 실행 주기를 다룬 글도 같이 보면 축이 갈려요. 시간대는 "언제로 읽느냐"의 문제이고, 실행 주기는 "얼마나 자주 확인하느냐"의 문제라서 원인이 서로 달라요.

실행하는 시계와 보여 주는 시계가 갈리는 자리

이 절이 이 글의 핵심이라고 생각해요. 스케줄이 실제로는 맞게 도는데 화면이 다르게 보여서, 맞은 걸 틀렸다고 판단하고 손대다가 진짜로 틀리는 경우가 많거든요.

Zapier 문서가 그 자리를 이렇게 적어요.

Zap run timestamps in Zap history display in UTC, which may differ from your local time even when the Zap is running on the correct schedule.

Zap 이력의 실행 타임스탬프는 UTC로 표시되고, Zap이 올바른 스케줄로 돌고 있을 때에도 현지 시각과 다를 수 있다는 문장이에요. 문서가 "올바른 스케줄로 돌고 있을 때에도"라는 조건절을 굳이 붙여 둔 건, 이걸 오해하는 사례가 많다는 뜻으로 읽혀요.

Make는 아예 설정을 둘로 갈라 놨어요.

The organization time zone defines the time used when executing scenarios and modules.

The user time zone is similar to locale and defines how Make displays time, for example, in the scenario execution history.

조직 시간대는 실행할 때 쓰는 시간을 정의하고, 사용자 시간대는 Make가 시간을 어떻게 표시할지를 정의해요. 문서가 표시 예로 든 게 시나리오 실행 이력이에요. 그러니까 팀원 둘이 같은 시나리오의 같은 실행 기록을 봐도 화면에 찍힌 시각이 서로 다를 수 있어요. 사용자 시간대가 사람마다 다르니까요.

정리하면 이래요.

출처: Zapier Help Center의 스케줄 문서, Make Help Center의 Manage time zones 문서. 2026년 8월 20일 조회.

나머지 셋은 표시 시각을 따로 규정한 문장을 이번에 읽은 문서 범위에서 찾지 못했어요. 못 찾았다는 것과 규정이 없다는 것은 다르니까, 이 표에는 확인된 둘만 넣었어요.

Make — 시간대를 개별로 손대는 자리가 스케줄에 없어요

Make의 기본 실행 간격부터 볼게요. 문서 원문이에요.

By default, a scenario runs every 15 minutes, but you can customize the run schedule and interval in this panel.

기본값으로 시나리오가 15분마다 돈다는 뜻이에요. 스케줄 옵션은 At regular intervals, Once, Daily, Weekdays (Mon-Fri), Weekly, Monthly, Specified dates, On demand 여덟 가지고요. 최소 간격에 대해서는 플랜에 따라 다르다고만 적혀 있어서, 구체적인 값은 이 글에서 다루지 않을게요.

여기서 부정 확인을 하나 했어요. 시나리오 설정 화면에 시간대 항목이 있나 없나예요. 시나리오 설정 문서를 열어 항목을 전수로 대조했더니 아홉 개였어요. Process data in order, Keep data confidential, Store incomplete executions, Discard data if storage is full, Use updated variable values, Errors before deactivation, Commit after each module, Commit trigger last, Cycles per run이에요. 이 아홉 개 어디에도 시간대 항목이 없어요.

그런데 여기서 멈추면 틀려요. 다른 경로로 한 번 더 열어 보니 개별 지정 자리가 다른 데 있었어요. 날짜 함수 쪽이에요.

formatDate 와 parseDate 의 시그니처가 각각 formatDate(date; format; [timezone]) 과 parseDate(text; format; [timezone]) 이고, 세 번째 인자가 선택 인자예요. 문서는 이 인자에 tz database 시간대 이름을 넣을 수 있다고 적고, 생략하면 조직의 시간대를 쓴다고 적어요. 조직 시간대 규칙을 다른 페이지가 한 번 더 확인해 주는 셈이기도 해요.

그래서 Make의 성격은 이렇게 정리돼요. 시간대를 바꾸는 층은 조직 하나이고, 값 단위로 다른 시간대를 쓰고 싶으면 스케줄이 아니라 함수 인자에서 처리해요. "시나리오마다 시간대를 다르게 주고 싶다"는 요구가 이 구조에서는 스케줄이 아니라 데이터 변환 쪽 문제로 넘어가요.

신규 조직의 기본 시간대 값이 무엇인지는 이번에 확인하지 못했어요. Manage time zones 문서에 그 값을 못 박은 문장이 없어서, 여기에 특정 값을 적지 않을게요.

뉴욕 기준으로 걸어 두면 한국에서 몇 시에 도나요

한국에서 쓰는 입장에서 가장 실감 나는 자리예요. 그런데 여기서 조심할 게 있어요. 이 환산값은 벤더 문서에 적힌 값이 아니라 시간대 오프셋으로 계산한 값이에요.

GitHub 문서가 IANA 시간대 문자열의 근거로 직접 링크해 둔 tz database 목록에서 America/New_York 행을 확인하면, 표준시 오프셋이 UTC-05:00이고 서머타임 오프셋이 UTC-04:00이에요. 오프셋이 두 값을 오간다는 게 핵심이에요. 한국 쪽은 표준시가 UTC+9 하나뿐이고 현재 서머타임을 시행하지 않아요.

그래서 이런 식으로 계산돼요.

계산 방식: 오전 9시에서 해당 오프셋을 빼 UTC 시각을 구한 뒤 9시간을 더했어요. 오프셋 값은 tz database 목록의 America/New_York 행에서 읽었고, 한국의 오프셋과 서머타임 미시행은 별도 자료에서 확인했어요.

두 줄을 나란히 놓으면 차이가 보여요. 같은 "오전 9시"인데 뉴욕 기준으로 걸었을 때와 UTC 기준으로 걸었을 때 한국 도착 시각이 네다섯 시간 벌어져요. 그리고 뉴욕 기준 쪽은 한 해에 두 번, 서머타임이 시작하고 끝날 때 한국에서 보는 실행 시각이 한 시간씩 움직여요. 한국 쪽에 상쇄해 줄 전환이 없으니 그 한 시간이 그대로 남아요.

그래서 n8n 셀프호스팅에 아무 설정도 안 하고 "매일 오전 9시"를 걸어 두면, 한국에서는 아침이 아니라 밤에 도는 일이 벌어져요. 게다가 그 시각이 계절에 따라 한 시간 움직이고요. 이게 이 글을 쓰게 만든 상황이에요.

배치 작업이 밤으로 밀리는 게 문제가 되는 자리라면, 같은 김에 자동화에서 공휴일을 빼는 방법을 다룬 글도 함께 보면 스케줄 조건을 한 번에 정리할 수 있어요. 시간대와 휴일은 둘 다 "언제 돌 것인가"를 정하는 조건인데 서로 다른 자리에서 처리되거든요.

지금 걸어 둔 스케줄을 점검하는 6단계

문서를 다 읽었으니 이제 자기 설정을 확인할 차례예요. 순서대로 하면 5분이면 끝나요.

1. 도구별로 "손대지 않았을 때의 값"부터 확인하세요. n8n 셀프호스팅이면 GENERIC_TIMEZONE 환경변수가 실제로 들어가 있는지, Zapier면 계정 프로필의 Timezone이 UTC 그대로인지 보는 거예요. 화면에 값이 보인다고 그게 내가 정한 값이라는 뜻은 아니에요.
2. 재지정 층이 몇 개인지 세어 보세요. n8n은 인스턴스와 워크플로 두 층, Apps Script는 매니페스트와 트리거 두 층이에요. 위층만 고치고 아래층에 옛 값이 남아 있으면 그 워크플로만 다르게 돌아요.
3. GitHub Actions라면 cron 항목마다 timezone 키가 붙었는지 보세요. 스케줄이 여러 개인데 첫 항목에만 붙였다면 나머지는 기본값인 UTC로 도는 셈이에요. 이 경우를 따로 적은 문장이 문서에 있는 건 아니고, 키가 항목 안에 놓이는 구조에서 나오는 해석이에요.
4. 이력 화면의 시각을 근거로 판단하지 마세요. Zapier 이력은 UTC로 표시되고, Make는 사용자 시간대로 표시돼요. 실행 시각을 확인하려면 실행 시계 쪽 설정을 봐야 해요.
5. Zapier에서 계정 시간대를 바꿨다면 Zap을 껐다 켜세요. 문서가 명시한 단계라서 건너뛰면 반영이 안 돼요.
6. 정시를 전제로 다른 시스템과 물려 뒀는지 보세요. Apps Script는 시각이 무작위화되고, Zapier는 정확한 분을 보장하지 않는다고 적혀 있고, GitHub Actions는 혼잡할 때 지연될 수 있다고 적혀 있어요. 셋 다 문서가 먼저 밝혀 둔 성질이에요.

워크플로가 실패했을 때 그걸 알아채는 장치까지 같이 두고 싶다면 n8n에서 워크플로가 멈추지 않게 하는 에러 처리 패턴을 정리한 글이 그 축을 다뤄요. 시간대가 어긋나면 대개 "안 돈 것"이 아니라 "엉뚱한 때 돈 것"이라 조용히 지나가거든요.

이 글에서 확인하지 못한 것

솔직하게 남겨 둘게요.

첫째, 각 도구의 요금제와 플랜별 최소 간격이에요. Make 문서는 최소 간격이 플랜에 따라 다르다고만 적었고, 저는 요금 페이지를 열지 않았어요.

둘째, Make 신규 조직의 기본 시간대 값이에요. 그 값을 못 박은 문장을 문서에서 찾지 못했어요.

셋째, Zapier의 Zap 단위 시간대가 어느 동작에 쓰이는지예요. 설정 자리는 에디터 문서가 Zap details 패널이라고 적어 뒀고, 스케줄 트리거가 그 값을 안 본다는 것도 스케줄 문서에 적혀 있어요. 그러면 그 값을 실제로 읽는 자리가 어디인지가 남는데, 그걸 못 박은 문장은 이번에 읽은 범위에서 못 찾았어요.

넷째, GitHub Actions의 가을 서머타임 종료 시 동작이에요. 봄 전환은 문서에 적혀 있는데 가을 전환은 같은 절에 없었어요.

다섯째, n8n과 GitHub Actions와 Apps Script의 이력 화면이 어느 시간대로 표시되는지예요. 실행 시각 규정은 확인했지만 표시 시각을 따로 규정한 문장은 이번에 읽은 범위에서 못 찾았어요.

정리

• 손대지 않았을 때의 기본값이 도구마다 달라요. n8n 셀프호스팅은 America/New_York, n8n Cloud는 감지 실패 시 GMT, GitHub Actions는 UTC, Apps Script는 스크립트 시간대, Zapier 계정 기본은 UTC, Make는 조직 시간대예요.
• n8n은 두 층이에요. 워크플로 시간대가 먼저이고 없으면 인스턴스 시간대예요. 둘 다 비우면 뉴욕으로 떨어진다고 문서가 직접 적어요.
• GitHub Actions는 이제 UTC 고정이 아니에요. cron 항목 옆에 timezone 키를 붙일 수 있고, 이 키를 알린 체인지로그 게시일이 2026년 3월 19일이에요. 그 이전에 쓰인 안내가 아직 많이 남아 있어요.
• Apps Script는 코드로 층이 하나 더 열려요. ClockTriggerBuilder 의 inTimezone() 이 트리거 단위 시간대를 받고, 기본값이 스크립트의 시간대라고 레퍼런스가 적어요.
• Apps Script는 시각이 무작위화돼요. 오전 9시 트리거는 9시와 10시 사이에서 시각이 정해지고 그 타이밍이 날마다 유지된다고 문서가 적어요.
• Zapier는 Zap이 아니라 계정 시계를 읽어요. Zap 쪽 시간대 설정은 에디터 좌측 사이드바의 Zap details 패널에 따로 있는데 스케줄 트리거가 그걸 안 봐요. 그리고 계정 시간대를 바꿨으면 Zap을 껐다 켜야 반영돼요.
• Zapier 이력은 UTC로 표시돼요. 올바른 스케줄로 돌고 있을 때에도 현지 시각과 다를 수 있다고 문서가 조건절까지 붙여 적어요.
• Make는 실행과 표시를 두 설정으로 갈라 놨어요. 조직 시간대가 실행을 정하고 사용자 시간대가 표시를 정해요. 시나리오 설정 아홉 항목에는 시간대가 없고, 값 단위 지정은 날짜 함수의 선택 인자로 해요.
• 한국 환산은 계산값이에요. America/New_York 은 오프셋이 UTC-05:00과 UTC-04:00을 오가고 한국은 오프셋이 하나뿐이라, 뉴욕 기준으로 걸어 둔 스케줄은 한국에서 한 해에 두 번 한 시간씩 움직여요.
• 시간대가 아닌 원인도 같이 보세요. GitHub Actions는 최소 간격과 혼잡 시 지연, 공개 저장소의 활동 없는 60일 자동 비활성화가 문서에 함께 적혀 있어요.
• 모든 인용의 확인 시각은 2026년 8월 20일이에요. 벤더가 다섯 곳이라 갱신 주기가 제각각이니, 판단이 필요한 날에는 해당 페이지를 다시 열어 보세요.

가장 짧은 확인은 이거예요. 지금 쓰는 도구에서 아무것도 설정하지 않았을 때의 값을 문서에서 한 줄 찾아 읽어 보세요. 그 값이 내가 예상한 값과 다르다면, 스케줄이 어긋나는 이유는 이미 거기 있어요.

함께 보면 좋은 글

• 웹훅과 폴링의 차이, 도구별 실행 주기 정리 — 스케줄이 늦게 도는 또 다른 축을 다뤄요.
• 업무 자동화에서 공휴일 빼는 법 — 실행 조건을 날짜 쪽에서 거르는 방법이에요.
• n8n 자동화 에러 처리 패턴 — 워크플로가 멈췄을 때 알아채는 장치를 다뤄요.

확인한 자료: n8n Docs의 Timezone and localization environment variables, Schedule Trigger 노드, Configure workflow settings, Set your timezone 네 페이지. GitHub Docs의 Workflow syntax 중 on.schedule 절과 Events that trigger workflows 중 schedule 절, 그리고 2026년 3월 19일자 GitHub Actions 체인지로그. Google Apps Script의 Installable triggers, Manifest structure, ClockTriggerBuilder 세 페이지. Zapier Help Center의 스케줄 문서, 날짜·시각 오류 문서, 그리고 에디터 사용법 문서 세 편. Make Help Center의 Manage time zones, Schedule a scenario, Date and time functions, Scenario settings 네 페이지. 오프셋은 GitHub 문서가 IANA 문자열의 근거로 링크한 tz database 목록에서 읽었어요. 전부 2026년 8월 20일에 직접 열어 확인했어요.