워크플로우 자동화 세대교체 n8n 2.0 업그레이드 및 보안 강화 포인트

n8n 2.0 개요

1) 출시 일정

• 2.0.0 Beta
  • 목표: 12월 8일 경 (early December)
• 2.0.x Stable
  • 목표: 12월 15일 경 (mid December)
• 최신 일정·변경 사항: Release Notes 페이지 참조

2) 왜 2.0인가?

• 1.0.0 이후 2년 동안 커뮤니티 피드백 + 엔지니어링/프로덕트 팀 작업으로 Automation + Agentic AI Orchestration 분야에서 꽤 성숙한 플랫폼으로 자리잡음.
• 2.0의 키워드
  • More mature
  • More secure
  • More reliable
• 이를 위해
  • 오래된/위험한 기능 정리
  • 보안 강제 옵션 강화
  • 스토리지 및 환경 설정 구조 개선
  • 일부 동작 방식 변경(Behaviour changes)

3) 1.x 버전 지원

• v2.0 출시 이후 3개월간 1.x 유지보수
  • 내용: 버그 및 보안 패치만 제공,
  • 새로운 기능은 전부 2.x에만 추가.

4) 커뮤니티/에디션 영향

• v2.0의 모든 변경 사항은
  • Community / Cloud / Enterprise/Business 버전 모두에 동일하게 적용.

v2.0 신규 기능

1. Autosave (자동 저장)
   • Stable 릴리즈 직후 제공 예정.
   • 워크플로우 편집 중 브라우저 크래시/세션 종료로 인한 작업 손실 위험 감소.
2. 개선된 Canvas UI
   • 노드 배치, 연결선, 읽기 가독성이 좋아지는 방향으로 업데이트.
3. 업데이트된 Sidebar
   • 노드 검색·탐색, 프로젝트 관리, 자주 쓰는 메뉴 접근성이 향상.
4. 추가 “서프라이즈” 기능
   • 차후 별도 공지 예정.

기능 관점에서는 “사용성 개선 + 작성 경험 개선” 쪽이고,
보안·운영 관점의 큰 변화는 대부분 ‘Breaking Changes’ 문서에 정리된 부분입니다.

Behaviour Changes (동작 방식 변경)

1. 서브 워크플로우 + Wait/Webhook/HITL 동작 변경

기존(v1.x)

• Parent Workflow → Sub-workflow 호출
• Sub-workflow가 Wait, Webhook, Form, Slack HITL(사람 승인) 같은 노드로 waiting 상태에 들어갔다 다시 재개되는 경우
  • Parent가 받는 결과가 Sub-workflow의 “입력”이었음 (즉, 최종 결과가 아니라 시작 시점 input).

v2.0 이후

• Parent는 Sub-workflow가 끝난 시점의 “출력”을 받음.
• 즉, 서브 워크플로우 안에서 사람이 승인/거절을 선택하면 그 결과가 Parent에 제대로 전달되는 방향으로 바뀜.

영향 예시

기존

• Sub-workflow: “승인 요청 → Slack HITL → 결과 저장 → 종료”
• Parent는 “요청 전 데이터(input)”만 다시 받으므로, 승인/거절 여부를 Parent에서 사용하려면 추가 꼼수를 써야 했음.

변경 후

• Parent는 Sub-workflow 끝에서 나온 결과 데이터(예: { decision: 'approved' })를 직접 받음.
• Parent는 바로 이후 If/ Switch 노드로 분기 가능.

마이그레이션 가이드

• 기존에 “Sub-workflow의 입력값이 다시 돌아오는” 전제로 짜 놓은 워크플로우는 로직 점검 필요.
• 예)
  • v1: Parent에서 Sub 호출 후, “입력값 그대로” 돌아올 것을 기대하고 Set/If 노드 구성
  • v2: Parent에서 Sub 호출 후, “실행 후 최종 결과”를 기준으로 If/Set 등을 다시 설계

2. Retired 서비스용 노드 제거

아래 노드들이 삭제됨(연결 대상 서비스 종료)

• Spontit node
• crowd.dev node
• Kitemaker node

영향/대응

• 혹시라도 과거에 만든 워크플로우에 이 노드가 남아 있으면
  → v2에서 에러가 발생할 수 있음.
• 실무 팁
  1. Migration Report(설정 메뉴)에서 해당 노드 사용 워크플로우 있는지 확인
  2. 대체 서비스/노드로 교체하거나 노드 삭제

Security Changes (보안 관련 큰 변경점)

이 섹션이 보안 관점에서 제일 중요합니다.

1. Code Node에서 환경변수 접근 기본 차단

• 환경변수 접근 차단 플래그: N8N_BLOCK_ENV_ACCESS_IN_NODE
• 기본값: true
  • v2부터 Code Node(예: JavaScript Code)에서 process.env 등으로 환경변수를 읽는 것이 기본적으로 막힘.

보안 의도

• 워크플로우 편집 권한을 가진 사용자가 실수/악의로 민감한 환경변수(비밀번호, 토큰 등)를 읽어내는 행위를 방지.

예시

• v1에서 이런 코드가 가능했다면
  • return [ { json: { token: process.env.SECRET_TOKEN, }, }, ];
• v2에서는 기본 설정 그대로면 위 코드가 실패하거나, process.env 접근이 허용되지 않음.

마이그레이션 가이드

• 정말 환경변수를 Code Node에서 써야 한다면:
  • N8N_BLOCK_ENV_ACCESS_IN_NODE=false 환경변수로 해제
  • 하지만 보안 관점에서는 민감값은 Credential 기능 또는 외부 Secret Manager 사용을 권장.
• 내부 가이드 예
  • “코드 노드에서는 process.env를 사용하지 말 것.
    필요한 값은 Credential / External Secret을 통해 주입.”

2. 설정 파일 퍼미션 강제

• 설정 파일(예: config 파일)의 권한이 0600이 아니면 에러/경고.
• “SSH private key와 동일한 수준”의 보호를 지향.

예시

chmod 600 /var/lib/n8n/.n8n-config

테스트용 환경변수

• v2 이전 환경에서 미리 테스트
  • N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
• 만약 파일 퍼미션을 다루기 어려운 OS(예: 일부 Windows 환경)라면
  • N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false 로 완화 가능.

보안·운영 체크 포인트

• 컨테이너 이미지/Dockerfile에서 설정 파일 생성 시 퍼미션 기본값 확인.
• Kubernetes ConfigMap/Secret 사용 시, 마운트된 파일 권한도 점검.

3. Task Runner 기본 활성화 & Docker 이미지 분리

(1) Task runners 기본 활성화

• N8N_RUNNERS_ENABLED=true 가 표준이 되고, 모든 Code Node 실행이 Task Runner 위에서 수행되는 방향.
• 목적
  • 코드 실행 격리(보안/안정성)
  • 장기적으로 Python Code, 고부하 Code 실행 안정화.

실무적으로는 “Code Node는 더 이상 n8n 메인 프로세스에서 직접 실행되지 않고 격리된 실행 엔진에서 돌아간다” 정도로 이해하면 됩니다.

300x250

(2) Docker 이미지 분리

• 기존: n8nio/n8n 이미지 내부에 external mode용 task runner 포함
• 변경: v2부터
  • n8nio/n8n : 메인 앱
  • n8nio/runners : External mode에서 task runner 실행용 별도 이미지

Docker Compose 예시(개념)

services:
  n8n:
    image: n8nio/n8n:2
    environment:
      - N8N_RUNNERS_ENABLED=true
      - N8N_RUNNERS_MODE=external
      - N8N_RUNNERS_RABBITMQ_URL=amqp://rabbitmq
    # ...

  n8n-runner:
    image: n8nio/runners:2
    environment:
      - N8N_RUNNERS_MODE=external
      - N8N_RUNNERS_RABBITMQ_URL=amqp://rabbitmq
    # ...

4. Pyodide 기반 Python Code Node 제거 → 네이티브 Python + Task Runner

• 브라우저/WebAssembly 기반 Pyodide Python Code 노드가 삭제.
• 대신 Task runner 기반 네이티브 Python Code Node만 사용 가능.
• v2에서는 External mode + task runner 설정이 필수.

기능 차이

• 기존 Pyodide 버전에서 사용하던
  • _input 같은 빌트인 변수
  • dot notation 접근 방식
• → 네이티브 Python Node에서는 동일하게 지원되지 않음 (Code 수정 필요).

마이그레이션 제안

1. Python Code Node가 있는 워크플로우 목록 파악 (Migration Report 활용).
2. 각 코드에서 _input 등 Pyodide 전용 문법 사용 여부 점검.
3. Task runner 환경 구성 + 코드 수정.

5. ExecuteCommand / LocalFileTrigger 기본 비활성화

• ExecuteCommand / LocalFileTrigger 노드는 기본 disabled.
• 이유
  • 임의 명령 실행 및 로컬 파일 시스템 접근은
    멀티테넌시·공유환경에서 고위험 기능.

활성화가 꼭 필요할 때

• 환경변수 NODES_EXCLUDE를 수정하여 제외 목록에서 빼야 함.

  # 모든 노드 활성화 (보안상 추천 X)
  NODES_EXCLUDE="[]"
  
  # 특정 노드만 활성화 예시 (개념)
  NODES_EXCLUDE='["n8n-nodes-base.executeCommand"]'

실제 Node 이름은 문서를 참고해야 하지만, “이 노드들은 반드시 명시적으로 허용해야 한다”는 통제 포인트로 삼으면 좋습니다.

6. OAuth Callback URL 인증 강제

• 환경변수: N8N_SKIP_AUTH_ON_OAUTH_CALLBACK
• 기존 기본값: true (인증 없이 OAuth callback 허용)
• v2 기본값: false (인증 필수)

보안 의도

• OAuth callback URL이 공격자에 의해 임의로 호출되는 것을 방지.
• 최소한 n8n 쪽 사용자 인증을 거치도록 강제.

대응

• 업그레이드 전:로 미리 바꿔서 기존 OAuth 연동이 문제 없이 동작하는지 테스트.
• N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false

7. 파일 접근 경로 제한 (N8N_RESTRICT_FILE_ACCESS_TO)

• ReadWriteFile, ReadBinaryFiles 노드가 접근할 수 있는 디렉토리를 제한.
• 기본값
  • ~/.n8n-files 디렉토리만 접근 허용.

보안 의미

• 워크플로우에서 서버의 임의 경로를 읽고/쓰는 위험을 줄임.
• “n8n가 접근 가능한 샌드박스 디렉토리”를 강제하는 개념.

환경변수 예시

# 특정 경로로 제한
N8N_RESTRICT_FILE_ACCESS_TO=/data/n8n-files

운영 포인트

• n8n 컨테이너에 /data/n8n-files 볼륨 마운트
• 내부 사용자에게 “파일은 이 경로 하위에서만 사용 가능”이라고 안내.

8. Git Node의 Bare Repository 기본 차단

• N8N_GIT_NODE_DISABLE_BARE_REPOS 기본값이 true.
• Bare repo는 일반적으로 CI/서버에서 사용되지만, 잘못 구성되면
  접근제어/권한 문제 위험이 있어 기본 차단.

Bare repo가 꼭 필요하면

N8N_GIT_NODE_DISABLE_BARE_REPOS=false

Data / Storage 관련 변경

1. MySQL / MariaDB 지원 중단

• v2부터 MySQL·MariaDB를 공식 지원하지 않음.
• v1.0에서 이미 deprecated 상태였고, 이제 완전히 제거.

추천 백엔드

• PostgreSQL (장기 지원 + 호환성 관점에서 최우선)
• 또는 SQLite (소규모/개발용)

마이그레이션

• 제공되는 DB migration tool을 사용하여
  MySQL/MariaDB → PostgreSQL 또는 SQLite로 데이터 이전 후 업그레이드.

2. SQLite Legacy Driver 제거 & Pooled Driver 기본화

• 기존의 레거시 SQLite 드라이버는 신뢰성 문제로 제거.
• sqlite-pooled 드라이버가 기본이자 유일한 드라이버.
  • WAL 모드 + 단일 write connection + read pool 활용
  • 벤치마크 기준 최대 10배 성능 향상.

환경변수 예시

# 이미 v1에서도 미리 적용 가능
DB_SQLITE_POOL_SIZE=2    # 기본 pool size 2

3. In-memory Binary Data Mode 제거

• N8N_DEFAULT_BINARY_DATA_MODE=default 옵션(실행 중 메모리에 Binary 저장)이 제거.
• v2에서 허용되는 모드
  • filesystem
  • database
  • s3 (S3 호환 스토리지)
• N8N_AVAILABLE_BINARY_DATA_MODES 설정도 제거 →
  이제 N8N_DEFAULT_BINARY_DATA_MODE만으로 모드 결정.

운영 포인트

• 바이너리(파일, 이미지 등) 데이터를 어디에 저장할지 명확히 설계 필요.
• Filesystem 모드 사용 시
  • 디스크 용량, 백업, 로그/데이터 보관 주기 정의.
• S3 모드 사용 시
  • 버킷 권한, 암호화, 네트워크 접근 통제까지 포함해 보안 정책 수립.

Configuration & Environment 변경

1. dotenv 업그레이드

• .env 파싱 라이브러리 dotenv가 8.6.0 → 최신 버전으로 업그레이드.
• 주요 변경점
  • 백틱() 처리 방식 변경 → 값에 백틱이 포함되면'또는"`로 감싸야 함.
  • 멀티라인 값 지원.
  • # 시작 줄은 주석으로 처리.

실무 체크

• 기존 .env에
  • # 뒤에 값을 쓰던 라인
  • 백틱이 포함된 값
• 이 있다면 전부 재점검 필요.

2. n8n --tunnel 옵션 제거

• CLI의 --tunnel 옵션이 v2에서 삭제.
• 개발 환경에서 외부에서 callback(예: Webhook, OAuth)을 받기 위해 사용하던 임시 터널 기능이 사라짐.

대체 방안

• ngrok
• localtunnel
• Cloudflare Tunnel
  등 외부 터널링 도구 사용.

3. QUEUE_WORKER_MAX_STALLED_COUNT 제거

• Bull 큐에서 stalled job을 자동 재시도하는 메커니즘이 혼란/신뢰성 문제로 제거.
• 해당 환경변수도 삭제.

영향

• v2 이후: n8n이 자동으로 “stalled job 재시도”를 알아서 처리해주지 않음.
• 필요하다면
  • 실패/정지 상태의 실행을 모니터링해서
  • 커스텀 재시도 로직 또는 모니터링 알림 구축 필요.

CLI & Workflow 관련 변경

1. “모든 워크플로우 활성화” CLI 명령 제거

• n8n update:workflow --all --active=true → v2에서 제거

이유

• 실수로 Production 환경 워크플로우를 전부 활성화하는 위험이 큼.
• 특히 마이그레이션/테스트 중 대량 활성화는 치명적일 수 있음.

대응

• 워크플로우는
  • UI에서 개별/프로젝트 단위로 활성화,
  • 또는 API를 사용해 소규모 batch로 관리.

보안·운영 관점 체크리스트

1. 사전 점검

1. Migration Report 확인 (Settings → Migration Report)
   • Sub-workflow 동작 변경 영향
   • Deprecated 노드(Spontit, crowd.dev, Kitemaker, Pyodide Python 등) 사용 여부
2. DB 백엔드 파악
   • MySQL/MariaDB 사용 여부 확인
   • PostgreSQL/SQLite로 이전 계획 수립 및 테스트
3. Code Node 사용 패턴 점검
   • process.env 사용 여부 → Credential/Secret 기반으로 전환
   • Python Code Node 중 Pyodide 의존 코드 존재 여부
4. 파일 노드 사용 점검
   • Read/Write Files, ReadBinaryFiles 노드가 접근하는 경로 파악
   • N8N_RESTRICT_FILE_ACCESS_TO 설계 및 안내

2. 보안 정책/설정 정리

services:
  n8n:
    image: n8nio/n8n:2
    environment:
      # 보안 관련 권장 기본값
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=true
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false
      - N8N_RESTRICT_FILE_ACCESS_TO=/data/n8n-files
      - N8N_GIT_NODE_DISABLE_BARE_REPOS=true

      # Task runner / Python Code 사용 시
      - N8N_RUNNERS_ENABLED=true
      - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

      # DB: PostgreSQL 예시
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=********
    volumes:
      - ./n8n-files:/data/n8n-files

한 줄 요약

• 기능 관점: Autosave, UI 개선 등으로 사용성 향상.
• 보안 관점
  • Code Node의 환경변수 접근 차단
  • 설정 파일 퍼미션 강제(0600)
  • 위험 노드/기능 기본 비활성화
  • OAuth callback 인증 강제
  • 파일 접근 경로 제한
• 운영/인프라 관점
  • MySQL/MariaDB 지원 중단 → PostgreSQL 전환 필요
  • Task runner/runner 전용 Docker 이미지 도입
  • dotenv, queue 설정, CLI 동작 변경