자동화를 시험하려면 무언가를 일으켜야 합니다. 시트에 줄을 넣고, 폼을 제출하고, 워크플로를 실패시킵니다. 이걸 운영 중인 시트나 워크플로에서 하면, 가짜 문의가 알림으로 나가고, 가짜 실패가 담당자를 깨우고, 시험하다 남은 것이 운영 데이터에 섞입니다.
자동화를 여러 번 만들면서 이걸 피하려고 쓴 방법이 몇 가지 있었습니다. 각각 다른 자동화를 만들 때 쓴 것이라 한 번에 한 것은 아닙니다. 그리고 시험이 끝난 뒤 정리한 것도 있고, 정리하지 않고 남긴 것도 있었습니다. 이 글은 둘 다 적었습니다.
두 가지는 따로 쓴 글이 있어 한 줄로만 적습니다. 편집기의 실행 버튼은 실제로 쓰는 방식과 다르게 돌아서 시험이 되지 않는 경우가 있었습니다(노코드 시작 글). 매일 도는 트리거는 「특정 날짜 및 시간」 트리거로 몇 분 뒤에 한 번 돌려 보는 것이 가장 빨랐습니다(시간 어긋남 글).
1. 시험용 데이터와 시험용 날짜 — 월요일을 기다리지 않기
매일 아침 어제 기록을 합쳐 메일로 보내는 자동화를 만들 때, 시험할 것이 셋이었습니다. 평일 아침, 월요일 아침(금·토·일 사흘을 합쳐야 함), 어제 기록이 없는 날. 월요일까지 기다릴 수는 없었습니다.
실제 업무 기록 대신, 업무 기록이 쌓인다고 놓고 샘플을 20줄 직접 넣은 시트로 시험했습니다. 9월 8일부터 15일까지, 항목 넷, 같은 날 같은 항목이 두 줄인 날을 일부러 넣었고, 일요일에는 한 줄도 넣지 않았습니다. 합칠 때 틀리기 쉬운 경우를 데이터에 미리 심어 둔 것입니다.
그리고 코드가 「오늘」을 밖에서 받을 수 있게 했습니다. 트리거가 부를 때는 오늘 날짜로 돌고, 시험할 때는 날짜를 넣어 부릅니다. 시험용 함수를 셋 두었습니다.
function testAsMonday() { sendDailyReport(new Date('2026-09-14T08:00:00+09:00')); }
function testEmptyDay() { sendDailyReport(new Date('2026-09-08T08:00:00+09:00')); }
function testAsSunday() { sendDailyReport(new Date('2026-09-13T08:00:00+09:00')); }
편집기에서 셋을 하나씩 돌린 결과입니다.
| 시험 | 넣은 날짜 | 결과 |
|---|---|---|
| testAsMonday | 9월 14일(월) | 9/11 ~ 9/13 합계 13건 — 금·토·일 다섯 줄 |
| testEmptyDay | 9월 8일(화) | 9/7 합계 0건 (기록 없음) |
| testAsSunday | 9월 13일(일) | 메일 없음 — 로그에 「주말 — 보내지 않음」 |
메일을 받는 쪽은 시트를 만든 계정 자기 자신이었습니다. 시험 메일이 다른 사람에게 가지 않습니다.
이 방법에는 한계가 하나 있었습니다. 편집기에서 날짜를 넣어 부르는 것과, 트리거가 부르는 것은 달랐습니다. 셋 다 통과한 코드가 트리거로 처음 돌 때 실패했습니다. 트리거는 첫 인자로 날짜가 아니라 이벤트 정보를 넣어 줬기 때문입니다. 시험 함수로 경우의 수를 보고, 트리거로도 한 번 돌려 보는 것까지가 시험이었습니다.
2. 일부러 실패하는 워크플로 — 실패를 만들어서 알림을 시험하기
n8n에서 워크플로가 실패하면 메일이 오게 만들 때는 반대로 실패가 필요했습니다. 운영 워크플로를 실패시킬 수는 없으니, 실패만 하는 워크플로를 두 개 만들었습니다.
| 이름 | 하는 일 |
|---|---|
| B | 1분마다 없는 주소를 호출 |
| C | 1분마다 잘못된 코드를 실행 |
그런데 첫 시도에서 B는 실패하지 않았습니다. 없는 주소를 불렀는데 초록 체크였습니다. 상대(n8n 자신)가 모르는 주소에도 화면용 페이지를 200으로 돌려줬기 때문입니다. 주소를 다른 경로로 바꾸고 나서야 404가 나고 실패했습니다. C도 처음 넣은 잘못된 표현식은 에러 대신 빈 값으로 넘어갔고, 같은 실수를 코드 노드에 넣었을 때 실패했습니다. 「일부러 실패」를 만드는 것부터 시험이 필요했던 셈입니다.
알림을 받는 쪽도 운영 메일이 아니었습니다. PC 안에 띄운 시험용 메일 서버(127.0.0.1:1025)로 받았습니다. 실패 알림이 1분에 두 통씩 와도 누구의 메일함도 차지 않았습니다. 그 시험용 메일 서버를 일부러 꺼서, 알림을 보내는 쪽이 실패하면 어떻게 되는지도 볼 수 있었습니다.
1분에 두 통이 계속 오니 알림을 줄이는 장치(같은 워크플로의 실패는 10분에 한 번)도 이 두 워크플로로 시험했습니다.
3. 빈 폴더로 n8n을 하나 더 — 운영 쪽을 건드리지 않고 복원 시험하기
n8n을 백업하고 다른 PC에서 되살리는 시험을 할 때, 다른 PC가 없었습니다. 그렇다고 쓰고 있는 n8n의 데이터를 지우고 되살릴 수는 없었습니다.
n8n은 데이터 폴더를 바꿀 수 있습니다. 공식 문서의 설명은 이렇습니다.
그 환경 변수(N8N_USER_FOLDER)에 빈 폴더를 주고 n8n을 하나 더 띄웠습니다. 빈 폴더라 처음 깐 PC와 같은 상태로 떴습니다. 포트는 원래 n8n이 쓰는 5678(n8n 문서의 기본값 「N8N_PORT Number 5678」)과 겹치지 않게 5680으로 바꿔, 두 n8n을 같이 띄웠습니다. 「처음 깐 PC」로 백업을 들여오는 시험은 이 빈 쪽에서 했습니다.
전부를 빈 쪽에서 한 것은 아닙니다. 워크플로를 지우고 JSON으로 되살리는 시험은 원래 n8n에서 했습니다. 지운 것이 앞서 만든 실패 알림 시험용 워크플로(A)였고, 그 과정에서 A의 실행 기록은 돌아오지 않았습니다. 시험용이었기에 괜찮았지만, 운영 워크플로였다면 되돌릴 수 없는 시험이었습니다.
빈 쪽에서는 두 가지를 확인할 수 있었습니다. 암호화 열쇠 파일 없이 들여온 자격증명은 「성공」이라고 나오는데 열리지 않는다는 것, 그리고 원래 열쇠 파일을 넣으면 열린다는 것. 둘 다 쓰고 있는 n8n에서 했다면 되돌리기 어려운 시험이었습니다.
한계도 적어 둡니다. 같은 PC, 같은 n8n 버전, 같은 경로였고, 무엇보다 원래 n8n이 옆에 살아 있었습니다. 「진짜 다른 PC」와 같지는 않습니다.
4. 터미널에서 웹훅 부르기 — 시트를 연결하기 전에
시트가 n8n을 부르게 하려던 자동화에서, n8n 쪽이 제대로 받는지부터 봤습니다. 시트 대신 PC의 터미널에서 n8n 웹훅 주소를 불렀습니다. 한 번 불러 메일이 오는 것을 보고, 세 줄을 0.5초 간격으로 연달아 보내 세 통이 순서대로 오는 것까지 봤습니다.
시트 쪽이 없어도 n8n 쪽 절반은 먼저 확인할 수 있었습니다. 시트에서 실제로 부르는 데까지는 가지 못했습니다. PC의 n8n 주소가 localhost라 구글 서버에서 닿지 않는 구조였기 때문입니다. 다만 터미널이 보내는 방식이 실제와 달라서, 첫 시도에 한글 이름 칸이 비어 왔습니다. 원인은 보내는 쪽 인코딩이었습니다(시트 값 글). 시험 도구가 실제와 다르게 보낼 수 있다는 것도 시험의 일부였습니다.
5. 뒷정리 — 한 것과 남긴 것
시험은 흔적을 남깁니다. 기록을 다시 보니 정리한 것과, 정리했다는 기록이 없는 것이 섞여 있었습니다.
정리한 것:
- 자격증명을 평문으로 내보낸 파일은 복원 시험에 쓴 뒤 지웠습니다
- n8n에서 지우는 시험을 할 때, 화면의 Archive는 목록에서만 사라지고 지워지지 않아서 한 번 더 없앴습니다
정리해야 한다고 적었지만, 지운 기록은 없는 것:
- 「특정 날짜 및 시간」 트리거는 한 번 돌고 나서도 「사용 중지됨」으로 목록에 남았습니다. 시험용으로 몇 번 걸면 그만큼 쌓이니 직접 지워야 한다고 적었습니다
- 시트 알림에서 함수 이름을 바꿨더니, 옛 이름을 찾는 트리거가 「Script function not found」로 조용히 실패했습니다. 트리거 페이지에서 옛것을 지우고(메뉴 → 트리거 삭제 → 「완전삭제」) 새 이름으로 다시 걸어야 한다고 적었습니다
정리한 기록이 없는 것:
- 일부러 실패하는 워크플로 B·C를 끈 기록은 없습니다. 백업·복원 시험 때 n8n에는 A·B·C가 그대로 있었고, 그 시험의 대상이 되었습니다
- 빈 폴더로 띄운 두 번째 n8n과 그 폴더를 지운 기록은 없습니다
- 폼에서 시험으로 넣었다 지운 질문은, 폼에서는 사라졌지만 시트의 열은 남았습니다. 폼에서 지워도 시트 열은 지워지지 않았습니다
1분마다 실패하는 워크플로가 켜진 채 남아 있으면, 그 자체가 1분마다 실패 기록을 쌓고 실패 알림을 부릅니다. 시험용으로 만든 것은 이름에 「시험」이나 「일부러 실패」를 넣어 두는 편이 낫습니다. 저희 B·C도 이름에 「일부러 실패」를 넣어 두었습니다.
시험할 때 점검표
- 운영 시트가 아니라 시험용 시트에, 틀리기 쉬운 경우(같은 날 두 줄, 빈 날)를 심은 샘플을 넣습니다
- 날짜에 따라 달라지는 코드는 「오늘」을 밖에서 넣을 수 있게 하고, 날짜별 시험 함수를 둡니다
- 시험 함수를 통과해도 트리거로 한 번 더 돌립니다
- 실패 알림은 일부러 실패하는 워크플로로 시험합니다. 그 워크플로가 정말 실패하는지부터 확인합니다
- 알림은 자기 자신이나 시험용 메일 서버로 받습니다
- 복원처럼 되돌리기 어려운 시험은 빈 데이터 폴더와 다른 포트로 띄운 두 번째 n8n에서 하고, 원래 n8n에서 해야 한다면 시험용 워크플로를 대상으로 합니다
- 시험용으로 만든 것은 이름에 표시하고, 끝나면 목록을 보고 끄거나 지웁니다. 한 번 돈 트리거, 켜 둔 실패 워크플로, 평문 파일, 두 번째 데이터 폴더, 폼에서 지운 질문의 시트 열
이 글이 다루지 않은 것
시험용 트리거, 워크플로 B·C, 두 번째 n8n 폴더를 실제로 정리한 기록은 없습니다. 위에 적은 대로 남아 있었던 것까지가 기록입니다.
「다른 PC」에서의 복원은 해 보지 않았습니다. 같은 PC 안에서 빈 폴더로 대신했습니다.
요약
| 방법 | 기록 | 뒷정리 |
|---|---|---|
| 시험용 시트 + 날짜 시험 함수 | 샘플 20줄, 월요일·빈 날·일요일 결과 | 한 번 돈 트리거는 목록에 남음 (지워야 한다고 적음) |
| 일부러 실패하는 워크플로 | B·C, 처음엔 실패하지 않아 고침 | 끈 기록 없음, 나중 시험 때 그대로 있었음 |
| 시험용 메일 서버 | PC 안 127.0.0.1:1025 로 받음 | — |
| 빈 폴더 n8n (5680) | 「처음 깐 PC」 복원 시험은 빈 쪽에서 (워크플로 지우고 되살리기는 원래 n8n에서, 시험용 A 대상) | 지운 기록 없음 |
| 터미널에서 웹훅 | 세 줄 순서대로, 한글은 인코딩 문제 | — |
| 평문 자격증명 파일 | 복원 시험에 사용 | 쓴 뒤 지움 |
시험을 운영과 떼어 놓는 방법은 여럿 있었지만, 시험이 남긴 것을 치우는 일은 기록에 절반만 있었습니다. 다음에는 시험용으로 만든 것의 목록부터 적고 시작하는 편이 낫겠습니다.
참고 (2026-09-23 확인)
– n8n 공식 문서 — Specify user folder path (https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/specify-user-folder-path): 「n8n saves user-specific data like the encryption key, SQLite database file, and the ID of the tunnel (if used) in the subfolder .n8n of the user who started n8n. It’s possible to overwrite the user-folder using an environment variable.」
– n8n 공식 문서 — Deployment environment variables (https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/deployment): 「N8N_PORT Number 5678 The HTTP port n8n runs on.」