자동화가 멈췄다는 걸 알고 나면, 다음 질문은 「어디를 보면 되나」입니다. 구글 시트의 Apps Script, n8n, 윈도우 작업 스케줄러로 자동화를 만들면서 이 질문을 여러 번 했고, 도구마다 답이 달랐습니다. 기록이 자세한 곳도 있었고, 결과 숫자 하나만 남는 곳도 있었습니다.
이 글은 그 세 도구에서 「멈췄을 때 본 기록」을 모은 것입니다. 각각 다른 자동화를 만들 때 본 것입니다.
한 가지는 따로 쓴 글이 있어 한 줄로 적습니다. 목록에 보이는 상태나 「마지막 실행 시간」보다 실행 기록의 시작 시각이 맞았습니다(시간 어긋남 글).
1. Apps Script — 실행 기록 페이지와 실행 로그
Apps Script 편집기 왼쪽 메뉴에 「실행」이 있습니다. 누르면 실행 기록 페이지가 열리고, 한 번 돌 때마다 한 줄이 쌓입니다.
onFormSubmit 실행 2026. 9. 14. 오후 10:11:55 1.751초 완료됨
함수 이름, 유형, 시작 시각, 걸린 시간, 상태입니다. 실패한 줄을 누르면 그 실행의 로그가 펼쳐집니다. 시트 알림이 처음 메일을 못 보냈을 때, 원인(권한 없이 메일을 부름)을 본 곳이 여기였습니다.
이 페이지에서 가장 쓸모 있었던 것은 유형 칸이었습니다.
- 매일 아침 도는 트리거를 시험할 때, 편집기에서 누른 실행은 「편집기」, 트리거가 돌린 실행은 「시간 기반」으로 찍혔습니다. 누가 돌렸는지를 여기서 구분할 수 있었습니다
- 시트 알림에서는 편집 한 번에 두 줄이 찍혔습니다. 「단순 트리거 — 실패」와 「실행 — 완료됨」. 함수 이름이 구글이 자동으로 부르는 이름(onEdit)이라, 제가 건 트리거와 구글이 부르는 것이 같이 돌고 있다는 것을 이 두 줄로 알았습니다
다만 이 기록은 오래 남는 곳이 아닙니다. 공식 문서는 기본 실행 로그를 이렇게 설명합니다.
오래 두고 볼 기록이 필요하면 따로 남겨야 한다는 뜻입니다. 문서도 「writes information to a logging Spreadsheet」처럼 직접 로그를 남기는 방법을 들고 있습니다. 저희는 로그 전용 시트를 만들지는 않았습니다.
2. 로그는 직접 찍어야 보입니다
실행 기록의 「완료됨」은 코드가 끝까지 돌았다는 뜻일 뿐, 무엇을 했는지는 말해 주지 않았습니다. 그래서 코드 안에서 직접 찍었습니다.
폼 접수 알림에서는 제출 한 건마다 줄 번호, 받은 값 전체, 남은 메일 한도를 찍었습니다. 폼 중간에 칸을 넣었을 때 값이 시트 맨 끝 열에 붙은 것을 이 로그의 값 원문으로 확인했습니다.
매일 아침 합계 메일이 「0건」으로 왔을 때는 줄마다 이렇게 찍었습니다.
raw=Mon Sep 14 00:00:00 GMT+09:00 2026 type=[object Date] fmt=- isDate=false
값의 원문, 종류, 변환 결과, 검사 결과를 한 줄에 둔 것입니다. 이 한 줄로 날짜 검사가 false를 내고 있다는 것이 보였고, 원인을 좁힐 수 있었습니다. 「완료됨 · 0건」만 보고는 알 수 없었던 것입니다.
프로그램이 넣은 줄을 잡는 트리거를 시험할 때는, 어떤 경로로 보냈는지까지 찍었습니다.
sent row=3.0 via change:INSERT_ROW at 2026-09-12T00:04:31.320Z
어느 줄을, 어떤 이벤트로, 언제 보냈는지가 한 줄에 있습니다. 돌아보면 원인을 찾는 데 쓸모 있었던 로그는 모두 무엇을·왜·언제를 한 줄에 담고 있었습니다.
3. 시트에 남긴 기록 — 보낸 표시와 「기록 없음」
실행 로그는 사라지지만, 시트에 적은 것은 남습니다. 두 곳에서 시트나 메일 자체를 기록으로 썼습니다.
시트 알림에서는 알림을 보낸 줄의 D열에 보낸 시각을 적었습니다. 원래는 같은 줄에 메일이 두 번 가지 않게 하려는 것이었는데, 결과적으로 어느 줄이 언제 알림으로 나갔는지가 시트에 남았습니다.
매일 아침 합계 메일은 어제 기록이 없는 날에도 「(기록 없음)」을 붙여 보내게 했습니다. 메일이 안 오면 「기록이 없는 날」인지 「트리거가 멈춘 날」인지 구분할 수 없어서입니다. 매일 오는 메일 자체가 「오늘도 돌았다」는 기록이 됩니다.
「완료됨」인데 메일이 한참 늦게 온 경우도 있었습니다(메일 알림 한계 글). 그때 원본으로 본 것도 시트였습니다.
4. n8n — 실행 목록과 실행 번호
n8n에는 워크플로마다 실행 목록이 있고, 한 번 돌 때마다 번호가 붙습니다. 실패 알림을 만들 때 이 목록에서 본 것이 둘 있습니다.
첫째, 편집기에서 버튼으로 돌린 실행은 목록에 manual로, 스스로 돈 실행은 트리거 실행으로 따로 찍혔습니다. 버튼으로 일부러 실패시켰는데 알림이 안 왔을 때, 목록에는 그 실행이 「manual · error」로 있고 알림 워크플로는 실행조차 안 된 것이 보였습니다. 알림이 안 온 이유가 여기 있었습니다.
둘째, 실행 번호로 두 워크플로를 이었습니다. 실패한 실행이 4번, 그 실패를 받아 메일을 보낸 알림 워크플로의 실행이 5번이었고, 알림 메일 본문에도 「실행 ID: 4」를 넣어 두었습니다. 메일에서 번호를 보고 목록에서 그 번호를 찾으면 됩니다.
시트에서 n8n을 부르게 하기 전에 시트 대신 터미널에서 웹훅을 불러 시험했는데, 그때 목록에는 다섯 건이 전부 webhook · success로 남아 있었습니다. 보낸 수와 목록의 수를 맞춰 보면 빠진 것이 없는지 볼 수 있습니다.
조심할 것도 있었습니다. 알림으로 이어지지 않는 실패가 있습니다. 알림 워크플로가 메일 서버에 닿지 못해 실패했을 때, 그 실패는 목록에 error로 남을 뿐 어디에도 알려지지 않았습니다. 그리고 워크플로를 지우면 그 실행 기록도 같이 사라졌습니다. 지웠다가 되살린 워크플로의 실행 기록은 0건이었습니다. n8n 문서도 같은 내용을 적고 있습니다.
같은 문서에 따르면 실행 목록은 상태(Failed, Running, Success, Waiting)와 시작 시각으로 거를 수 있습니다. 저희는 목록을 눈으로 훑었지만, 워크플로가 많아지면 실패만 걸러 보는 편이 빠를 것입니다.
5. 작업 스케줄러 — 숫자 하나뿐일 때는 스스로 남긴 파일
n8n을 PC가 켜질 때 뜨게 하려고 윈도우 작업 스케줄러에 걸었습니다. 처음 「실행」했을 때 2초 만에 끝났고, 남은 것은 이것뿐이었습니다.
마지막 실행 결과 1
원인을 보려고 작업의 「기록」 탭을 열었더니 탭 이름이 「기록(사용 안 함)」이었습니다. 작업 기록은 기본으로 꺼져 있었고, 켜는 것은 관리자 권한이 필요한 일로 알고 있어서 켜지 않았습니다. 스케줄러 쪽에서는 볼 것이 없었습니다.
스크립트가 스스로 남기게 만든 로그 파일도 없었습니다. 첫 줄도 못 갔다는 뜻입니다. 그래서 같은 스크립트를 명령 창에서 직접 돌렸고, 거기서 원인(파일의 줄 끝 문자)이 보였습니다. 창 없이 도는 작업은, 스케줄러 밖에서 한 번 직접 돌려 보는 것이 가장 빠른 확인이었습니다.
그 뒤로 스크립트가 자기 기록을 남기게 했습니다. 처음에는 스크립트의 기록과 n8n의 출력을 한 파일에 붙였는데, n8n이 도는 동안 그 파일을 잡고 있어서 다른 스크립트가 한 줄도 못 적었습니다.
다른 프로세스가 파일을 사용 중이기 때문에 프로세스가 액세스 할 수 없습니다.
그래서 둘로 나눴습니다. 스크립트가 언제 시작했고 무엇을 판단했는지는 start.log, n8n의 출력은 n8n.log. 이미 켜져 있어서 새로 띄우지 않고 끝낸 경우도 start.log에 이렇게 남았습니다.
[2026-09-16 2:48:19.14] 시작 (USER=(사용자))
[2026-09-16 2:48:19.20] 5678 포트가 이미 열려 있음 - 중복 실행하지 않고 끝냅니다
반대로 스케줄러 쪽에는 같은 상황에서 이런 결과가 남기도 했습니다.
마지막 실행 결과 운영자 또는 관리자가 요청을 거부했습니다. (0x800710E0)
「거부」라는 말과 달리 실제로는 「이미 돌고 있어서 새로 띄우지 않았다」는 뜻이었고, n8n은 멀쩡했습니다. 스케줄러의 결과 칸만 보면 오해하기 쉬웠고, 무슨 일이 있었는지는 스크립트가 남긴 파일에 있었습니다.
멈췄을 때 볼 곳 — 점검표
- Apps Script는 왼쪽 「실행」 메뉴. 유형 칸(편집기·시간 기반·단순 트리거)으로 누가 돌렸는지부터 봅니다
- 「완료됨」은 끝까지 돌았다는 뜻일 뿐입니다. 무엇을 했는지는 코드에서 직접 찍어야 보입니다
- 로그 한 줄에는 무엇을·왜·언제를 넣습니다. 값의 원문과 종류를 같이 찍으면 원인이 좁혀집니다
- 실행 로그는 오래 남지 않습니다. 오래 볼 것은 시트에 적습니다(보낸 시각, 「기록 없음」 메일)
- n8n은 실행 목록을 상태로 걸러 실패만 봅니다. 알림 메일에 실행 번호를 넣어 두면 찾기 쉽습니다
- 워크플로를 지우면 실행 기록도 사라집니다. 지우기 전에 볼 것은 보고 지웁니다
- 작업 스케줄러는 결과 숫자 하나뿐일 수 있습니다. 스크립트가 스스로 로그 파일을 남기게 하고, 여러 프로세스가 같은 파일에 쓰지 않게 나눕니다
- 창 없이 도는 작업은 스케줄러 밖에서 한 번 직접 돌려 봅니다
이 글이 다루지 않은 것
Apps Script의 Cloud Logging과 Error Reporting은 써 보지 않았습니다. 로그를 따로 시트에 쌓는 로거도 만들지 않았습니다.
작업 스케줄러의 작업 기록을 켜 보지 않았습니다. 켰을 때 무엇이 보이는지는 확인하지 못했습니다.
n8n 실행 기록이 얼마나 오래 보관되는지는 확인하지 않았습니다.
요약
| 도구 | 기본으로 남는 것 | 부족했던 것 | 보탠 것 |
|---|---|---|---|
| Apps Script | 실행 기록 한 줄(유형·시각·기간·상태), 실패 시 로그 | 「완료됨」이 무엇을 했는지 모름, 오래 안 남음 | Logger.log 로 값 원문·종류, 시트에 보낸 시각, 「기록 없음」 메일 |
| n8n | 실행 목록(번호·모드·상태) | 알림 워크플로 자신의 실패는 목록에만, 지우면 기록도 사라짐 | 알림 메일에 실행 번호 |
| 작업 스케줄러 | 마지막 실행 결과 숫자 하나 | 작업 기록은 기본 꺼짐 | start.log / n8n.log 로 나눠 스스로 기록 |
도구가 남겨 주는 기록은 「돌았다」까지인 경우가 많았습니다. 「무엇을 했나」는 만든 쪽이 직접 남겨야 보였습니다.
참고 (2026-09-23 확인)
– Google Apps Script 공식 문서 — Logging (developers.google.com/apps-script/guides/logging): 「The built-in Apps Script execution log. This log is lightweight and streams in real time, but persists only for a short time.」 · 「build your own logger code that, for example, writes information to a logging Spreadsheet」
– n8n 공식 문서 — View all executions (https://docs.n8n.io/build/understand-workflows/understand-executions/view-all-executions): 「When you delete a workflow, n8n deletes its execution history as well. This means you can’t view executions for deleted workflows.」 · Status 로 필터(Failed, Running, Success, Waiting)