n8n 3.0 업그레이드, 워크플로를 내보냈다고 끝일까? 운영을 멈추지 않는 8칸 수용 시트

읽는 데 약 9분

질문: n8n 3.0으로 올린 뒤 자동화가 이전과 같은 결과를 내고, Code node·파일·웹훅·스케줄의 경계가 달라지지 않았다는 사실을 무엇으로 확인할까요?
답: export와 Migration Report를 출발점으로 삼되, 각 핵심 업무를 고정 입력·기대 결과·허용 가능한 부작용·권한 관찰값·중단선으로 기록한 수용 시트로 재실행한 뒤에만 올리시면 됩니다.

업그레이드는 이미지 태그를 바꾸는 작업처럼 보이기 쉽습니다. 하지만 실제 운영에서 중요한 것은 “컨테이너가 떴는가”가 아니라 같은 입력이 같은 업무 결과로 이어지는가입니다. 특히 n8n 3.0은 2026년 10월 전환을 앞두고 제거 노드, 기본값, 저장소, task runner, SSRF 범위를 바꾸고 있습니다. 이 글은 그 변화 목록을 업무별 판정표로 바꾸는 방법을 정리합니다.

핵심 요약

export는 복구 재료이고, Migration Report는 영향 목록입니다. 둘만으로 업무 결과의 동일성은 확인되지 않습니다.
수용 시트에는 고정 입력과 기대 산출물뿐 아니라 권한·네트워크·파일 경계와 rollback 중단선을 함께 적어야 합니다.
최소한 스케줄, 다중 item Code, 긴 Code 작업, 파일, 허용/차단 HTTP, AI Agent 또는 chat 흐름은 대표 입력으로 다시 돌려보세요.
queue mode라면 main·worker·Redis·공유 저장소가 연결된 실행 경로 자체를 증거로 남겨야 합니다.
보안 점검 결과는 기능 재현 결과와 다른 증거입니다. 둘을 한 장의 승인 묶음으로 합치되 서로를 대체하지 않게 두세요.

왜 export 성공만으로는 부족할까요?

n8n의 공식 v3 변경 안내는 self-hosted 배포 방식, 여러 레거시 노드, 기본 timeout, binary data, SSRF 보호, chat frame 등 실제 실행 결과에 영향을 줄 수 있는 항목을 담고 있습니다. 예를 들어 Function/Function Item은 Code node로, Cron/Interval은 Schedule Trigger로 옮겨야 하며, task runner 기본 timeout도 달라질 수 있습니다. 공식 변경 안내가 플래그를 잡아 주더라도, 변환된 workflow가 귀사의 주문 알림·파일 처리·보고서 발송에서 같은 결과를 낸다는 증거까지 만들지는 않습니다.

실무 판단 기준
비용은 재실행이 만든 외부 호출과 작업자 자원으로, 권한은 Code node가 접근 가능한 값으로, 신뢰성은 timeout·재시도·중복 실행으로, 운영 품질은 담당자와 복구 가능성으로 나눠 확인하세요. 한 번의 “성공” 로그로 네 기준을 묶어 통과시키지 않는 것이 핵심입니다.

가장 안전한 시작은 민감한 실제 데이터나 외부 쓰기 대상이 아닌 sandbox 입력입니다. 같은 날짜 범위, 같은 가짜 주문 번호, 같은 파일 크기처럼 재현 가능한 값을 정하고, 이전 버전에서 관찰한 결과를 먼저 적어 둡니다. 그 다음 전환 환경에서 차이를 비교합니다.

FLOWIT 8칸 수용 시트: 한 업무를 한 줄로 판정하기

아래 표는 스프레드시트, 이슈, 변경 요청 어디에든 옮길 수 있는 최소 형식입니다. 열이 넓으므로 모바일에서는 표 전체를 줄이기보다 좌우로 넘겨 읽도록 두는 편이 낫습니다.

업무·담당	기존 관찰값·고정 입력	영향 항목	기대 결과·허용 부작용	runner·권한·네트워크	데이터·파일 경계	중단선	재검증 기록
월간 CSV 정리 운영 담당	샘플 CSV 20행, 빈 값 2개	Function → Code 파일 처리 변경	20행 출력, 빈 값 2개 유지 새 외부 쓰기 없음	runner health 정상 비밀값 노출 없음	허용된 staging 경로만 읽기·쓰기	행 수/컬럼이 달라지거나 권한 경계가 불명확하면 중단	실행 ID, 결과 파일 hash, 시각
매일 09:00 보고 업무 담당	고정 날짜·수신자 sandbox	Cron → Schedule Trigger	한 번만 발송 예약 시각 기록	worker가 실행했는지 확인	실제 수신자 제외	중복 발송 또는 누락이면 중단	발송 로그, 수신 sandbox 확인

여덟 칸이 번거롭게 느껴진다면, 그 업무는 아직 승격하기에 복잡한 상태일 수 있습니다. 반대로 한 줄로 설명할 수 있다면 담당자가 바뀌어도 같은 기준으로 확인할 수 있습니다.

전환 전에 돌릴 6개 최소 재실행

모든 workflow를 한 번에 실험할 필요는 없습니다. 다만 아래 여섯 가지는 제거·변경·격리 경계를 대표하므로, 사용 중인 경우 우선순위를 높이세요.

대표 흐름	고정 입력	기대 결과	즉시 멈출 조건
Schedule Trigger	sandbox 일정 1회	한 실행만 생성되고 대상 시간이 기록됨	누락·중복 또는 시간대 해석 불명
다중 item Code	3개 item, 한 항목은 빈 필드	순서·개수·빈 값 처리가 이전과 일치	item 유실·합쳐짐·예상 밖 분기
긴 Code 작업	의도적으로 경계 시간을 넘는 mock 작업	설정한 제한 안에서 완료 또는 예측 가능한 실패	제한이 바뀌었는데 원인·대응 미확정
파일·binary 처리	무해한 샘플 파일과 hash	읽기·변환·저장 결과가 hash 기준으로 일치	경로·저장소·권한이 달라짐
HTTP/SSRF 경계	허용 대상 1개, 차단 대상 1개	허용 요청만 성공하고 차단 요청은 거부됨	예상 밖 접근 허용 또는 필수 대상 차단
AI Agent·chat	정해진 질문과 mock 도구 응답	도구 호출·응답 형식이 소비자와 호환	구형 mode·frame 가정으로 소비자 오류

실패 조건을 먼저 적어 두세요. “다시 돌려 보자”는 판단이 아닙니다. 외부 쓰기 결과가 다르거나, 파일 위치를 설명할 수 없거나, runner의 격리를 확인할 수 없을 때는 production 전환과 자동 재실행을 멈추는 것이 맞습니다.

queue mode와 external runner에서는 실행 경로도 결과입니다

queue mode에서는 main 인스턴스가 트리거를 받고 Redis를 거쳐 worker가 실행한 뒤 결과를 데이터베이스에 기록합니다. 공식 문서는 queue mode에서 filesystem binary storage를 지원하지 않는다고 안내합니다. 파일을 다루는 workflow라면 “테스트가 통과했다”보다 어느 worker가 어떤 저장소를 읽고 썼는가를 함께 남기셔야 합니다.

중앙 orchestration 노드에서 main 프로세스, worker, 메시지 큐, 격리된 task runner로 작업이 나뉘는 개념도 — 섹션 이미지: 같은 workflow라도 실행 경로가 달라지면 관찰해야 할 증거도 달라집니다.

Code node를 쓰는 환경은 task runner를 별도 검증 대상으로 두세요. n8n은 production에서 사용자 제공 코드 실행을 위해 external mode와 hardening을 권고하며, 외부 runner 이미지의 버전 일치와 health 확인을 안내합니다. 여기서 중요한 것은 특정 구성 값을 복사하는 일이 아니라, 귀사의 runner가 실제로 살아 있고 필요한 모듈만 허용하며 민감한 값에 과도하게 닿지 않는지를 확인하는 일입니다. 자세한 구조는 task runner 공식 문서와 queue mode 공식 문서에서 교차 확인할 수 있습니다.

Report·재실행·점검 결과를 하나의 승인 묶음으로 만들기

변경 보고서는 “무엇이 영향을 받는지”, 재실행은 “업무가 같은 결과를 냈는지”, 보안 점검은 “어떤 위험 표면이 남았는지”를 보여 줍니다. 세 자료를 한 PDF나 이슈에 붙이되, 어느 하나가 다른 하나의 면제증이 되지 않게 구분하세요.

변경 보고서, 고정 입력 재실행, 보안 검토 증거가 승인 묶음으로 합쳐지고 canary, 보류, rollback으로 나뉘는 흐름도 — 섹션 이미지: 서로 다른 증거를 모아도 최종 선택은 canary·보류·복구로 명확해야 합니다.

복구점 확정: 전환 전 이미지, 데이터베이스, volume, 설정의 복구 방법과 책임자를 확인합니다.
영향 목록 분류: Migration Report와 workflow inventory를 보고 레거시 노드·파일·네트워크·Code·chat 흐름에 라벨을 붙입니다.
고정 입력 재실행: 부작용 없는 대상에서 한 번 실행하고 결과물, 실행 ID, 관찰값을 시트에 기록합니다.
canary 또는 보류: 핵심 흐름이 모두 통과하면 제한된 대상에서 진행합니다. 한 항목이라도 중단선에 닿으면 원인을 분리할 때까지 보류하고 복구점으로 돌아갑니다.

n8n의 security audit는 credentials, database, file system, nodes, instance 범주의 위험을 보고합니다. 이는 좋은 운영 근거이지만 파일 hash나 수신자별 결과를 대신 확인해 주지는 않습니다. 공식 audit 문서를 기준으로 결과를 별도 첨부하고, 해결하지 못한 항목은 담당자와 기한을 남기세요.

배포 전 체크리스트

복구점과 복구 담당자가 실제로 확인되었나요?
제거·변경된 노드가 쓰이는 workflow를 모두 inventory에 올렸나요?
각 핵심 업무에 고정 입력, 기대 산출물, 허용 가능한 부작용을 적었나요?
외부 쓰기는 sandbox 또는 canary 대상으로 한 번만 실행했나요?
queue mode라면 main·worker·Redis·저장소 연결을, Code node가 있다면 runner health와 격리를 확인했나요?
중단선에 닿았을 때 자동 재시도하지 않고 보류·복구할 책임자가 정해졌나요?

다음 읽기
Docker 기반 n8n 환경 자체를 정리해야 한다면 n8n과 Ollama 로컬 자동화 가이드를, 실행 결과를 담당자에게 남기는 방법은 정기 실행 business receipt를 함께 보세요.

자주 묻는 질문

Migration Report가 깨끗하면 바로 올려도 될까요?

아닙니다. 영향 항목이 없거나 해결됐다는 신호와 실제 업무 결과가 같다는 증거는 다릅니다. 대표 업무의 고정 입력 재실행과 복구 기준을 함께 확인하시는 편이 안전합니다.

모든 workflow를 완전히 재현해야 하나요?

변경 영향을 받는 핵심 흐름부터 시작하세요. 다만 파일·외부 쓰기·Code·스케줄·webhook처럼 실패 비용이 큰 경계는 표본만으로 끝내지 말고 업무별로 기록을 남기는 것이 좋습니다.

Code node가 있으면 무엇을 추가로 봐야 하나요?

결과값뿐 아니라 실행 격리, runner health, 이미지 버전, 필요한 모듈의 허용 범위, 민감한 값에 대한 접근 경계를 확인하세요. production 환경의 구성은 mock 환경에서 통과한 코드와 다를 수 있습니다.

queue mode에서 파일을 다루는 workflow는 왜 별도 확인이 필요한가요?

실행 주체와 저장소가 나뉘기 때문입니다. 공식 문서의 binary data 제약을 확인하고, 실제 worker에서 샘플 파일의 읽기·쓰기·결과 hash가 기대와 같은지 보세요.

언제 rollback을 선택해야 하나요?

핵심 산출물이 달라졌는데 차이를 설명할 수 없거나, 권한·네트워크·파일 경계가 불명확하거나, 복구 방법이 검증되지 않았을 때입니다. 원인을 분리하기 전에는 다음 변경을 겹치지 마세요.

참고 자료

n8n v3.0 Breaking changes — 2026년 10월 예정 전환의 제거 노드, 저장소, timeout, SSRF, chat 관련 변경과 준비 항목입니다.
n8n Set up task runners — Code node 실행 격리, external mode, sidecar 버전·health 확인의 공식 설명입니다.
n8n Enable queue mode — main·worker·Redis 실행 흐름과 binary data 저장소 제약을 확인하는 자료입니다.
n8n Run security audits — credentials, database, file system, nodes, instance 위험 보고 범위를 설명합니다.