n8n 워크플로우를 다 만들고 Test workflow 버튼을 눌렀더니 노드가 초록불로 쭉 켜지며 완벽하게 돌아갑니다. "됐다" 싶어 브라우저를 닫고 다음 날 확인해 보면, 실행 기록(Executions)이 텅 비어 있습니다. 분명 편집기에선 잘 됐는데 실제로는 한 번도 안 돈 거죠. n8n을 조금 써 본 사람이라면 거의 다 한 번쯤 겪는 상황입니다. 이 글에서는 n8n 워크플로우가 편집기에선 되는데 켜두면 안 도는 이유를, '테스트 실행'과 '활성화(Active)'가 완전히 다른 동작이라는 관점에서 풀어보겠습니다.
왜 편집기에선 되는데 실제로는 안 돌까
핵심은 하나입니다. 편집기에서 수동으로 실행하는 것과, 워크플로우를 켜두고(활성화) 트리거가 스스로 도는 것은 완전히 별개의 동작이라는 점입니다. 'Test workflow'나 트리거 노드의 'Listen for test event'는 딱 그 순간, 여러분이 화면을 보고 있는 동안만 작동하는 임시 실행입니다. 창을 닫으면 끝납니다.
반면 스케줄에 맞춰 알아서 돌거나, 외부에서 웹훅으로 호출되는 '프로덕션 실행'은 워크플로우가 Active 상태일 때만 일어납니다. 그래서 테스트만 하고 활성화 토글을 켜지 않으면, 아무리 편집기에서 잘 돌았어도 실제 자동화는 0회가 됩니다. n8n 공식 문서도 편집·디버깅용 실행과 활성화된 프로덕션 실행을 분리해 설명합니다(n8n Webhook 개발 문서).
테스트 실행이 주는 '가짜 안심'
이 착각이 생기는 이유는 테스트 실행이 너무 잘 되기 때문입니다. 수동 실행은 활성화 여부와 무관하게 한 번은 돌아가도록 설계돼 있습니다. 그래서 만드는 사람은 "노드도 다 초록불, 데이터도 잘 넘어감 → 완성"이라고 결론을 내립니다. 하지만 그건 '이 워크플로우가 논리적으로 맞다'는 확인이지, '이제 자동으로 돈다'는 확인이 아닙니다. 이 둘을 구분하는 게 n8n 디버깅의 출발점입니다.
웹훅: 테스트 URL과 프로덕션 URL은 다른 주소다
웹훅으로 외부 서비스(결제, 폼, 챗봇 등)를 연결할 때 가장 많이 막히는 지점입니다. n8n의 Webhook 노드는 주소가 두 개입니다.
- Test URL — 경로에
/webhook-test/가 들어갑니다. 편집기에서 'Listen for test event'를 누른 동안에만 살아 있고, 딱 한 번의 호출만 받은 뒤 멈춥니다. 이 대기 상태도 약 120초 후에는 자동으로 종료됩니다. - Production URL — 경로에
/webhook/가 들어갑니다. 워크플로우를 저장하고 활성화(Active)했을 때만 상시 작동합니다.
흔한 실수는 편집기에 떠 있는 Test URL을 그대로 복사해 결제 서비스나 외부 앱에 등록하는 것입니다. 이러면 첫 이벤트 한 번만 들어오고, 그 뒤로는 계속 404가 나면서 외부 서비스가 재시도만 반복하게 됩니다. 실제 연동에는 반드시 /webhook/ 경로의 Production URL을 쓰고, 워크플로우를 활성화해 두어야 합니다.
프로덕션 웹훅은 편집기에 데이터가 안 보인다
또 하나 헷갈리는 점. 프로덕션 URL로 실제 호출이 들어와도 편집기 화면에는 데이터가 표시되지 않습니다. 편집기에서 노드 사이로 데이터가 흐르는 걸 보여주는 건 테스트 실행일 때뿐입니다. 그래서 "프로덕션 URL을 등록했는데 편집기에 아무것도 안 뜬다 → 안 되는 건가?" 하고 오해하기 쉽습니다. 실제로 잘 들어오고 있는지는 편집기가 아니라 Executions(실행 기록) 탭에서 확인해야 합니다.
스케줄 트리거가 조용히 멈춰 있는 이유
정해진 시간에 도는 Schedule Trigger도 같은 함정에 빠집니다. 수동으로 'Test workflow'를 누르면 당연히 돌지만, 활성화 토글을 켜지 않으면 예약된 시각이 와도 아무 일도 일어나지 않습니다. Executions 탭이 계속 비어 있다면 십중팔구 활성화 토글이 꺼져 있는 경우입니다. 활성화되면 토글이 주황색으로 바뀝니다.
토글은 켰는데도 예약 시각과 실제 실행 시각이 어긋난다면, 그다음으로 의심할 것은 타임존입니다. 셀프호스팅 환경이라면 서버 기준 시간이 UTC로 잡혀 있어, 한국 시간으로 설정한 스케줄이 9시간 밀려 도는 일이 자주 생깁니다. n8n은 이럴 때 쓰라고 GENERIC_TIMEZONE 환경변수를 제공합니다. 이 값을 Asia/Seoul 같은 지역으로 맞춰두면 스케줄 노드가 그 기준으로 시간을 해석합니다.
실행 기록에서 '수동'과 '자동'을 구분하기
여기서 한 걸음 더 나가면 디버깅이 훨씬 빨라집니다. Executions 탭의 각 실행에는 어떤 방식으로 시작됐는지(실행 모드)가 함께 남습니다. 편집기에서 직접 돌린 것은 수동(manual) 실행으로, 웹훅이나 스케줄로 자동으로 돈 것은 각각 웹훅·트리거 실행으로 표시됩니다. 그래서 기록을 열었을 때 전부 '수동'뿐이고 자동 실행이 하나도 없다면, 로직이 아니라 활성화·트리거 설정 문제라는 게 바로 드러납니다.
반대로 자동 실행 기록은 남는데 결과가 빨간불(실패)이라면, 그때는 활성화 문제가 아니라 노드 안에서 데이터가 막힌 것입니다. 즉 '실행 기록이 있느냐 없느냐'가 문제를 크게 두 갈래로 나눠주는 첫 번째 갈림길입니다. 이 구분만 익혀도 "왜 안 되지"를 붙잡고 헤매는 시간이 확 줄어듭니다. 무작정 노드를 다시 뜯어보기 전에, 기록부터 열어 자동 실행이 찍혔는지를 먼저 보는 습관이 중요합니다.
실전 체크리스트: 안 돌 때 이 순서로 본다
워크플로우가 자동으로 안 돌 때, 아래 순서대로 확인하면 대부분 원인이 잡힙니다.
- 활성화 토글부터 확인. 화면 우상단 토글이 주황색(Active)인가? 저장만 하고 활성화를 안 한 경우가 압도적으로 많습니다.
- 트리거 노드가 맞는지 확인. Manual Trigger로 만들어 놓고 자동 실행을 기대하는 경우가 있습니다. 자동화하려면 Schedule Trigger, Webhook 등 '스스로 도는' 트리거여야 합니다.
- 웹훅이면 URL 경로 확인. 외부에 등록한 주소가
/webhook-test/가 아니라/webhook/인지 봅니다. - Executions 탭을 본다. 실행이 아예 없는지, 실행은 됐는데 에러로 멈췄는지에 따라 원인이 갈립니다. 기록이 0건이면 트리거·활성화 문제, 기록은 있는데 빨간불이면 노드 로직 문제입니다.
- 스케줄이 밀리면 타임존. 셀프호스팅이면
GENERIC_TIMEZONE을 점검합니다.
이 순서가 유용한 이유는, 위에서부터 '자동화가 켜져 있는가 → 트리거가 맞는가 → 주소가 맞는가 → 실제로 뭐가 일어났는가'로 좁혀가기 때문입니다. 많은 사람이 4번(로직)부터 붙잡고 시간을 쓰지만, 실제 원인은 1번(활성화)인 경우가 가장 흔합니다.
더 확실히 하고 싶다면, 활성화한 직후에 스스로 트리거를 한 번 발생시켜 자동 실행 기록이 찍히는지 눈으로 확인해 보세요. 웹훅이면 프로덕션 URL로 실제 요청을 한 번 보내보고, 스케줄이면 잠깐 몇 분 뒤 시각으로 바꿔 한 번 돌게 한 뒤 원래 값으로 되돌리는 식입니다. '켜뒀으니 되겠지'가 아니라 '자동 실행이 실제로 한 번 찍혔다'까지 확인하고 넘어가면, 며칠 뒤에야 그동안 안 돌고 있었다는 걸 발견하는 상황을 막을 수 있습니다.
결론: '테스트됨'과 '자동화됨'을 분리해서 보자
n8n 워크플로우가 편집기에선 되는데 실제로는 안 도는 문제의 뿌리는 결국 하나입니다. 수동 테스트 실행과, 활성화된 프로덕션 실행을 같은 것으로 착각하는 것이죠. Test workflow가 초록불이라는 건 '논리가 맞다'는 뜻일 뿐, '이제 자동으로 돈다'는 뜻이 아닙니다. 웹훅은 /webhook/ 프로덕션 URL을 쓰고, 스케줄이든 웹훅이든 활성화 토글을 켜고, 결과는 Executions 탭에서 확인하는 습관을 들이면 이 헷갈림의 대부분이 사라집니다.
오늘 만들어 둔 워크플로우가 있다면, 지금 바로 활성화 토글이 주황색인지부터 확인해 보세요. 그 한 번의 확인이 '분명 만들었는데 안 도는' 며칠을 줄여줄 겁니다.
※ 본 글의 화면 명칭·경로·환경변수는 작성 시점(2026년 7월) n8n 기준이며, 버전에 따라 UI 문구가 다를 수 있습니다.
