InfoGrab Docs

n8n v2.0 호환성 변경 사항

요약

n8n v2.0이 출시되었으며, 이와 함께 몇 가지 중요한 변경 사항이 적용되었습니다. n8n 2.0의 출시는 안전하고 신뢰할 수 있으며 프로덕션에 적합한 자동화 플랫폼을 제공하겠다는 n8n의 약속을 이어갑니다. 이전에는 실행(부모)이 서브 실행(자식)을 호출하고, 해당 서브 실행에 서브 실행을 대기 상태로 만드는 노드가 포함되어 있으며, 부모 실행이 서브 실행의 완료를 기다리도록 설정된 경우, 부모 실행이 잘못된 결과를 받는 문제가 있었습니다.

n8n v2.0이 출시되었으며, 이와 함께 몇 가지 중요한 변경 사항이 적용되었습니다. 이 문서에서는 전환을 준비하기 위해 취해야 할 중요한 호환성 변경 사항과 조치 사항을 설명합니다. 이러한 업데이트는 보안 강화, 설정 단순화, 레거시 기능 제거를 목적으로 합니다.

n8n 2.0의 출시는 안전하고 신뢰할 수 있으며 프로덕션에 적합한 자동화 플랫폼을 제공하겠다는 n8n의 약속을 이어갑니다. 이 메이저 버전에는 중요한 보안 개선 사항과 지원 중단된 기능 정리가 포함되어 있습니다.

동작 변경 사항#

서브 워크플로가 대기 상태에서 재개될 때 예상되는 서브 워크플로 데이터 반환 (웹훅 대기, 폼, HITL 등)#

이전에는 실행(부모)이 서브 실행(자식)을 호출하고, 해당 서브 실행에 서브 실행을 대기 상태로 만드는 노드가 포함되어 있으며, 부모 실행이 서브 실행의 완료를 기다리도록 설정된 경우, 부모 실행이 잘못된 결과를 받는 문제가 있었습니다.

예를 들어 서브 실행에 65초 이상의 타임아웃이 설정된 Wait 노드, 웹훅 호출, 폼 제출, 또는 Slack 노드와 같은 HITL(Human-in-the-Loop) 노드가 포함된 경우 대기 상태가 발생합니다.

Parent-Workflow: Parent-Workflow

Sub-Workflow: Sub-Workflow

v1: 부모 실행이 서브 실행의 입력을 출력으로 재현합니다.: v1: Parent execution won't receive the result of the child execution

v2: 부모 실행이 자식 실행의 결과를 수신합니다: v2: Parent execution will receive the result of the child execution

이를 통해 서브 워크플로에서 HITL 노드를 사용하고, 그 결과(예: 작업 승인 또는 거부)를 부모 워크플로에서 활용할 수 있습니다.

마이그레이션 방법: 서브 워크플로를 호출하면서 서브 워크플로의 입력을 수신하기를 기대하는 워크플로를 검토하세요. 부모 워크플로가 서브 워크플로의 입력 대신 자식 워크플로의 끝에서 출력을 받는 새로운 동작을 처리하도록 해당 워크플로를 업데이트하세요.

Start 노드 제거#

Start 노드는 더 이상 지원되지 않습니다. 이 노드는 워크플로를 시작하는 기존 방식이었지만, 이제 더 구체적인 트리거 노드로 대체되었습니다.

마이그레이션 방법: 워크플로 사용 방식에 따라 Start 노드를 교체하세요:

  • 수동 실행: Start 노드를 Manual Trigger 노드로 교체하세요.
  • 서브 워크플로: 다른 워크플로가 이 워크플로를 서브 워크플로로 호출하는 경우, Start 노드를 Execute Workflow Trigger 노드로 교체하고 워크플로를 활성화하세요.
  • 비활성화된 Start 노드: Start 노드가 비활성화된 경우, 워크플로에서 삭제하세요.

워크플로 저장 및 게시#

새로운 워크플로 게시 시스템이 기존의 활성/비활성 토글을 대체합니다. 이는 기존의 "활성화/비활성화" 토글이 새로운 "게시/게시 취소" 버튼으로 변경됨을 의미합니다. 이 변경으로 워크플로 변경 사항이 언제 적용될지를 더 잘 제어할 수 있어, 작업 중인 변경 사항이 실수로 프로덕션에 배포되는 위험을 줄일 수 있습니다. 자세한 내용은 다음을 참조하세요: 워크플로 저장 및 게시

서비스 종료로 인한 노드 제거#

다음 노드들은 연결하는 외부 서비스가 더 이상 제공되지 않아 제거되었습니다:

  • Spontit node
  • crowd.dev node
  • Kitemaker node
  • Automizy node

마이그레이션 방법: 워크플로에서 이러한 노드를 사용하는 경우, 오류를 방지하기 위해 해당 워크플로를 업데이트하거나 제거하세요.

보안#

기본적으로 Code Node에서 환경 변수 접근 차단#

보안 강화를 위해 n8n은 기본적으로 Code node에서 환경 변수에 대한 접근을 차단합니다. N8N_BLOCK_ENV_ACCESS_IN_NODE의 기본값이 이제 true로 설정됩니다.

마이그레이션 방법: 워크플로에서 Code node의 환경 변수 접근이 필요한 경우, 환경 설정에서 N8N_BLOCK_ENV_ACCESS_IN_NODE=false로 설정하세요. 민감한 데이터의 경우 환경 변수 대신 자격 증명이나 다른 보안 방법을 사용하세요.

설정 파일 권한 강제 적용#

n8n은 보안 강화를 위해 설정 파일에 엄격한 파일 권한을 요구합니다. 기본적으로 설정 파일은 0600 권한을 사용해야 하며, 이는 파일 소유자만 읽고 쓸 수 있음을 의미합니다. 이 방식은 SSH가 개인 키를 보호하는 방식과 유사합니다.

마이그레이션 방법: v2.0 이전에 이 동작을 테스트하려면 N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true로 설정하세요. 환경이 파일 권한을 지원하지 않는 경우(예: Windows), N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false로 설정하여 이 요구 사항을 비활성화하세요.

기본적으로 태스크 러너 활성화#

n8n은 보안 및 격리 강화를 위해 기본적으로 태스크 러너를 활성화합니다. 모든 Code node 실행이 태스크 러너에서 실행됩니다.

마이그레이션 방법: v2.0으로 업그레이드하기 전에 N8N_RUNNERS_ENABLED=true로 설정하여 이 동작을 테스트하세요. 인프라가 태스크 러너 실행 요구 사항을 충족하는지 확인하세요. 추가적인 보안을 위해 외부 모드 사용을 고려하세요.

n8nio/n8n Docker 이미지에서 태스크 러너 제거#

v2.0부터 메인 n8nio/n8n Docker 이미지에는 외부 모드용 태스크 러너가 더 이상 포함되지 않습니다. 외부 모드에서 태스크 러너를 실행하려면 별도의 n8nio/runners Docker 이미지를 사용해야 합니다.

마이그레이션 방법: Docker의 외부 모드에서 태스크 러너를 실행하는 경우, n8nio/n8n 대신 n8nio/runners 이미지를 사용하도록 설정을 업데이트하세요.

Pyodide 기반 Python Code 노드 및 도구 제거#

n8n은 Pyodide 기반 Python Code node 및 도구를 제거하고, 더 나은 보안과 성능을 위해 네이티브 Python을 사용하는 태스크 러너 기반 구현으로 대체합니다. v2.0부터 외부 모드의 태스크 러너와 네이티브 Python 도구로만 Python Code node를 사용할 수 있습니다.

네이티브 Python Code node는 Pyodide 기반 버전에서 사용 가능했던 _input이나 점 접근 표기법과 같은 내장 변수를 지원하지 않습니다. 자세한 내용은 Code node 문서를 참조하세요.

네이티브 Python 도구는 AI Agent가 도구를 호출할 때 전달하는 입력 문자열에 대해 _query를 지원합니다.

마이그레이션 방법: Code node에서 Python을 계속 사용하려면 외부 모드에서 태스크 러너를 설정하고 기존 Python Code node 및 도구의 호환성을 검토하세요.

기본적으로 ExecuteCommand 및 LocalFileTrigger 노드 비활성화#

n8n은 보안 위험이 있는 ExecuteCommand 및 LocalFileTrigger 노드를 기본적으로 비활성화합니다. 이 노드들은 사용자가 임의의 명령을 실행하고 파일 시스템에 접근할 수 있게 합니다.

마이그레이션 방법: 이러한 노드를 사용해야 하는 경우, NODES_EXCLUDE 환경 변수를 업데이트하여 n8n 설정의 비활성화된 노드 목록에서 제거하세요. 예를 들어, 모든 노드를 활성화하려면 NODES_EXCLUDE="[]"로 설정하거나, 필요한 특정 노드만 제거하세요.

기본적으로 OAuth 콜백 URL에 인증 요구#

n8n은 기본적으로 OAuth 콜백 엔드포인트에 인증을 요구합니다. N8N_SKIP_AUTH_ON_OAUTH_CALLBACK의 기본값이 true(인증 불필요)에서 false(인증 필요)로 변경됩니다.

마이그레이션 방법: v2.0으로 업그레이드하기 전에 N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false로 설정하고 인증이 활성화된 상태에서 OAuth 통합이 작동하는지 테스트하세요.

N8N_RESTRICT_FILE_ACCESS_TO 기본값 설정#

n8n은 파일 작업이 발생할 수 있는 위치를 제어하기 위해 N8N_RESTRICT_FILE_ACCESS_TO의 기본값을 설정합니다. 이는 ReadWriteFile 및 ReadBinaryFiles 노드에 영향을 줍니다. 기본적으로 이 노드들은 ~/.n8n-files 디렉토리의 파일에만 접근할 수 있습니다.

마이그레이션 방법: 파일 노드를 사용하는 워크플로를 검토하고 허용된 디렉토리의 파일에만 접근하는지 확인하세요. 다른 디렉토리에 대한 접근을 허용해야 하는 경우, N8N_RESTRICT_FILE_ACCESS_TO 환경 변수를 원하는 경로로 설정하세요.

N8N_GIT_NODE_DISABLE_BARE_REPOS 기본값을 true로 변경#

기본적으로 Git node는 이제 보안상의 이유로 bare 리포지토리를 차단합니다. N8N_GIT_NODE_DISABLE_BARE_REPOS의 기본값이 true로 설정되어, 이 설정을 변경하지 않는 한 bare 리포지토리가 비활성화됩니다.

마이그레이션 방법: 워크플로에서 bare 리포지토리를 사용해야 하는 경우, 환경 설정에서 N8N_GIT_NODE_DISABLE_BARE_REPOS=false로 설정하여 활성화하세요.

데이터#

MySQL/MariaDB 지원 중단#

n8n은 더 이상 MySQL 및 MariaDB를 스토리지 백엔드로 지원하지 않습니다. 이 지원은 v1.0에서 지원 중단으로 예고되었습니다. 최상의 호환성과 장기 지원을 위해 PostgreSQL을 사용하세요. MySQL node는 기존과 같이 계속 지원됩니다.

마이그레이션 방법: v2.0으로 업그레이드하기 전에 데이터베이스 마이그레이션 도구를 사용하여 MySQL 또는 MariaDB에서 PostgreSQL 또는 SQLite로 데이터를 이전하세요.

SQLite 레거시 드라이버 제거#

n8n은 신뢰성 문제로 인해 레거시 SQLite 드라이버를 제거합니다. 풀링 드라이버가 기본 및 유일한 SQLite 드라이버가 됩니다. 풀링 드라이버는 WAL 모드, 단일 쓰기 연결, 읽기 연결 풀을 사용합니다. 벤치마크 결과 최대 10배 빠른 속도를 보여줍니다.

마이그레이션 방법: sqlite-pooled 드라이버가 자동으로 기본값이 됩니다. DB_SQLITE_POOL_SIZE를 0보다 큰 값으로 설정하여 지금 바로 풀링을 활성화할 수 있습니다. 기본 풀 크기는 2로 설정됩니다.

인메모리 바이너리 데이터 모드 제거#

n8n은 실행 중 바이너리 데이터를 메모리에 보관하는 N8N_DEFAULT_BINARY_DATA_MODE의 default 모드를 제거합니다. 더 나은 성능과 안정성을 위해 v2부터 다음 옵션들이 제공됩니다:

  • filesystem: 바이너리 데이터가 파일 시스템에 저장됩니다. 일반 모드의 기본 옵션입니다.
  • database: 바이너리 데이터가 데이터베이스에 저장됩니다. 큐 모드의 기본 옵션입니다.
  • s3: 바이너리 데이터가 S3 호환 스토리지에 저장됩니다.

N8N_AVAILABLE_BINARY_DATA_MODES 설정도 제거되므로, 이제 모드는 N8N_DEFAULT_BINARY_DATA_MODE에 의해서만 결정됩니다.

마이그레이션 방법: 설정에 따라 파일 시스템 또는 데이터베이스 모드가 자동으로 사용됩니다. n8n 인스턴스에 바이너리 데이터를 저장할 충분한 디스크 공간이 있는지 확인하세요. 자세한 내용은 바이너리 데이터 설정을 참조하세요.

설정 및 환경#

dotenv 업그레이드#

n8n은 dotenv 라이브러리를 사용하여 .env 파일에서 환경 설정을 로드합니다. 라이브러리가 버전 8.6.0에서 최신 버전으로 업그레이드되며, 이로 인해 .env 파일 파싱 방식이 변경될 수 있습니다. 주요 호환성 변경 사항은 다음과 같습니다:

  • 백틱 지원 (#615): 값에 백틱이 포함된 경우 단일 또는 이중 따옴표로 감싸세요.
  • 멀티라인 지원: 이제 멀티라인 값을 사용할 수 있습니다.
  • #는 주석의 시작을 나타냅니다: #으로 시작하는 줄은 주석으로 처리됩니다.

마이그레이션 방법: dotenv 변경 로그를 검토하고 새 버전과의 호환성을 보장하도록 .env 파일을 업데이트하세요.

n8n --tunnel 옵션 제거#

n8n --tunnel 커맨드라인 옵션이 v2.0에서 제거됩니다.

마이그레이션 방법: 현재 개발 또는 테스트에 --tunnel 옵션을 사용하는 경우, ngrok, localtunnel 또는 Cloudflare Tunnel과 같은 대체 터널링 솔루션으로 전환하세요. 이 변경 사항을 반영하도록 워크플로 및 문서를 업데이트하세요.

QUEUE_WORKER_MAX_STALLED_COUNT 제거#

QUEUE_WORKER_MAX_STALLED_COUNT 환경 변수와 중단된 작업에 대한 Bull 재시도 메커니즘이 제거됩니다. 이는 종종 혼란을 야기하고 안정적으로 작동하지 않았기 때문입니다.

마이그레이션 방법: 설정에서 이 환경 변수를 삭제하세요. 업그레이드 후 n8n은 더 이상 중단된 작업을 자동으로 재시도하지 않습니다. 중단된 작업을 처리해야 하는 경우, 자체 재시도 로직 구현이나 모니터링을 고려하세요.

N8N_CONFIG_FILES 제거#

N8N_CONFIG_FILES 환경 변수가 제거되었습니다.

마이그레이션 방법: 설정에서 이 환경 변수를 삭제하세요. 설정을 환경 변수, .env 파일 또는 _FILE 기반 설정으로 이전하세요.

CLI 및 워크플로#

CLI 명령어 update:workflow 교체#

update:workflow CLI 명령어가 지원 중단되고 유사한 기능을 더 명확하게 제공하는 두 개의 새 명령어로 교체됩니다:

  • publish:workflow with parameters id and versionId (optional)
    • --all 파라미터는 프로덕션 환경에서 실수로 워크플로가 게시되는 것을 방지하기 위해 제거됩니다
  • unpublish:workflow with parameters id and all

마이그레이션 방법: 새 publish:workflow 명령어를 사용하여 ID별로 개별 워크플로를 게시하고, 선택적으로 버전을 지정하세요. 게시 취소의 경우 새 unpublish:workflow 명령어를 사용하세요. 이를 통해 워크플로 게시 상태에 대한 더 나은 명확성과 제어가 가능합니다.

외부 훅#

지원 중단되는 프론트엔드 워크플로 훅#

workflow.activeChange 및 workflow.activeChangeCurrent 훅이 지원 중단됩니다. 이는 새 훅 workflow.published로 대체됩니다. 새 훅은 워크플로의 모든 버전이 게시될 때 트리거됩니다.

마이그레이션 방법: workflow.activeChange 및 workflow.activeChangeCurrent 대신 새 workflow.published 훅을 사용하도록 코드를 업데이트하세요. 이 훅은 더 일관된 동작을 제공하며 워크플로 버전이 게시될 때마다 트리거됩니다.

릴리즈 채널#

n8n은 릴리즈 채널 이름을 각각 latest에서 stable로, next에서 beta로 변경했습니다.

stable 태그는 최신 안정 릴리즈를 나타내며, beta 태그는 최신 실험적 릴리즈를 나타냅니다. 이 태그들은 npm과 Docker Hub 모두에서 사용 가능합니다. 현재는 n8n이 계속해서 릴리즈에 latest 및 next 태그를 붙입니다. 이 태그들은 향후 메이저 버전에서 제거될 예정입니다.

권장 사항: n8n 버전을 특정 버전 번호로 고정하세요. 예: 2.0.0

문제 보고#

n8n 2.0으로 업데이트하는 동안 문제가 발생하면 커뮤니티 포럼에서 도움과 지원을 받으세요.

n8n v2.0 호환성 변경 사항

원문 보기
요약

n8n v2.0이 출시되었으며, 이와 함께 몇 가지 중요한 변경 사항이 적용되었습니다. n8n 2.0의 출시는 안전하고 신뢰할 수 있으며 프로덕션에 적합한 자동화 플랫폼을 제공하겠다는 n8n의 약속을 이어갑니다. 이전에는 실행(부모)이 서브 실행(자식)을 호출하고, 해당 서브 실행에 서브 실행을 대기 상태로 만드는 노드가 포함되어 있으며, 부모 실행이 서브 실행의 완료를 기다리도록 설정된 경우, 부모 실행이 잘못된 결과를 받는 문제가 있었습니다.

n8n v2.0이 출시되었으며, 이와 함께 몇 가지 중요한 변경 사항이 적용되었습니다. 이 문서에서는 전환을 준비하기 위해 취해야 할 중요한 호환성 변경 사항과 조치 사항을 설명합니다. 이러한 업데이트는 보안 강화, 설정 단순화, 레거시 기능 제거를 목적으로 합니다.

n8n 2.0의 출시는 안전하고 신뢰할 수 있으며 프로덕션에 적합한 자동화 플랫폼을 제공하겠다는 n8n의 약속을 이어갑니다. 이 메이저 버전에는 중요한 보안 개선 사항과 지원 중단된 기능 정리가 포함되어 있습니다.

동작 변경 사항#

서브 워크플로가 대기 상태에서 재개될 때 예상되는 서브 워크플로 데이터 반환 (웹훅 대기, 폼, HITL 등)#

이전에는 실행(부모)이 서브 실행(자식)을 호출하고, 해당 서브 실행에 서브 실행을 대기 상태로 만드는 노드가 포함되어 있으며, 부모 실행이 서브 실행의 완료를 기다리도록 설정된 경우, 부모 실행이 잘못된 결과를 받는 문제가 있었습니다.

예를 들어 서브 실행에 65초 이상의 타임아웃이 설정된 Wait 노드, 웹훅 호출, 폼 제출, 또는 Slack 노드와 같은 HITL(Human-in-the-Loop) 노드가 포함된 경우 대기 상태가 발생합니다.

Parent-Workflow: Parent-Workflow

Sub-Workflow: Sub-Workflow

v1: 부모 실행이 서브 실행의 입력을 출력으로 재현합니다.: v1: Parent execution won't receive the result of the child execution

v2: 부모 실행이 자식 실행의 결과를 수신합니다: v2: Parent execution will receive the result of the child execution

이를 통해 서브 워크플로에서 HITL 노드를 사용하고, 그 결과(예: 작업 승인 또는 거부)를 부모 워크플로에서 활용할 수 있습니다.

마이그레이션 방법: 서브 워크플로를 호출하면서 서브 워크플로의 입력을 수신하기를 기대하는 워크플로를 검토하세요. 부모 워크플로가 서브 워크플로의 입력 대신 자식 워크플로의 끝에서 출력을 받는 새로운 동작을 처리하도록 해당 워크플로를 업데이트하세요.

Start 노드 제거#

Start 노드는 더 이상 지원되지 않습니다. 이 노드는 워크플로를 시작하는 기존 방식이었지만, 이제 더 구체적인 트리거 노드로 대체되었습니다.

마이그레이션 방법: 워크플로 사용 방식에 따라 Start 노드를 교체하세요:

  • 수동 실행: Start 노드를 Manual Trigger 노드로 교체하세요.
  • 서브 워크플로: 다른 워크플로가 이 워크플로를 서브 워크플로로 호출하는 경우, Start 노드를 Execute Workflow Trigger 노드로 교체하고 워크플로를 활성화하세요.
  • 비활성화된 Start 노드: Start 노드가 비활성화된 경우, 워크플로에서 삭제하세요.

워크플로 저장 및 게시#

새로운 워크플로 게시 시스템이 기존의 활성/비활성 토글을 대체합니다. 이는 기존의 "활성화/비활성화" 토글이 새로운 "게시/게시 취소" 버튼으로 변경됨을 의미합니다. 이 변경으로 워크플로 변경 사항이 언제 적용될지를 더 잘 제어할 수 있어, 작업 중인 변경 사항이 실수로 프로덕션에 배포되는 위험을 줄일 수 있습니다. 자세한 내용은 다음을 참조하세요: 워크플로 저장 및 게시

서비스 종료로 인한 노드 제거#

다음 노드들은 연결하는 외부 서비스가 더 이상 제공되지 않아 제거되었습니다:

  • Spontit node
  • crowd.dev node
  • Kitemaker node
  • Automizy node

마이그레이션 방법: 워크플로에서 이러한 노드를 사용하는 경우, 오류를 방지하기 위해 해당 워크플로를 업데이트하거나 제거하세요.

보안#

기본적으로 Code Node에서 환경 변수 접근 차단#

보안 강화를 위해 n8n은 기본적으로 Code node에서 환경 변수에 대한 접근을 차단합니다. N8N_BLOCK_ENV_ACCESS_IN_NODE의 기본값이 이제 true로 설정됩니다.

마이그레이션 방법: 워크플로에서 Code node의 환경 변수 접근이 필요한 경우, 환경 설정에서 N8N_BLOCK_ENV_ACCESS_IN_NODE=false로 설정하세요. 민감한 데이터의 경우 환경 변수 대신 자격 증명이나 다른 보안 방법을 사용하세요.

설정 파일 권한 강제 적용#

n8n은 보안 강화를 위해 설정 파일에 엄격한 파일 권한을 요구합니다. 기본적으로 설정 파일은 0600 권한을 사용해야 하며, 이는 파일 소유자만 읽고 쓸 수 있음을 의미합니다. 이 방식은 SSH가 개인 키를 보호하는 방식과 유사합니다.

마이그레이션 방법: v2.0 이전에 이 동작을 테스트하려면 N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true로 설정하세요. 환경이 파일 권한을 지원하지 않는 경우(예: Windows), N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false로 설정하여 이 요구 사항을 비활성화하세요.

기본적으로 태스크 러너 활성화#

n8n은 보안 및 격리 강화를 위해 기본적으로 태스크 러너를 활성화합니다. 모든 Code node 실행이 태스크 러너에서 실행됩니다.

마이그레이션 방법: v2.0으로 업그레이드하기 전에 N8N_RUNNERS_ENABLED=true로 설정하여 이 동작을 테스트하세요. 인프라가 태스크 러너 실행 요구 사항을 충족하는지 확인하세요. 추가적인 보안을 위해 외부 모드 사용을 고려하세요.

n8nio/n8n Docker 이미지에서 태스크 러너 제거#

v2.0부터 메인 n8nio/n8n Docker 이미지에는 외부 모드용 태스크 러너가 더 이상 포함되지 않습니다. 외부 모드에서 태스크 러너를 실행하려면 별도의 n8nio/runners Docker 이미지를 사용해야 합니다.

마이그레이션 방법: Docker의 외부 모드에서 태스크 러너를 실행하는 경우, n8nio/n8n 대신 n8nio/runners 이미지를 사용하도록 설정을 업데이트하세요.

Pyodide 기반 Python Code 노드 및 도구 제거#

n8n은 Pyodide 기반 Python Code node 및 도구를 제거하고, 더 나은 보안과 성능을 위해 네이티브 Python을 사용하는 태스크 러너 기반 구현으로 대체합니다. v2.0부터 외부 모드의 태스크 러너와 네이티브 Python 도구로만 Python Code node를 사용할 수 있습니다.

네이티브 Python Code node는 Pyodide 기반 버전에서 사용 가능했던 _input이나 점 접근 표기법과 같은 내장 변수를 지원하지 않습니다. 자세한 내용은 Code node 문서를 참조하세요.

네이티브 Python 도구는 AI Agent가 도구를 호출할 때 전달하는 입력 문자열에 대해 _query를 지원합니다.

마이그레이션 방법: Code node에서 Python을 계속 사용하려면 외부 모드에서 태스크 러너를 설정하고 기존 Python Code node 및 도구의 호환성을 검토하세요.

기본적으로 ExecuteCommand 및 LocalFileTrigger 노드 비활성화#

n8n은 보안 위험이 있는 ExecuteCommand 및 LocalFileTrigger 노드를 기본적으로 비활성화합니다. 이 노드들은 사용자가 임의의 명령을 실행하고 파일 시스템에 접근할 수 있게 합니다.

마이그레이션 방법: 이러한 노드를 사용해야 하는 경우, NODES_EXCLUDE 환경 변수를 업데이트하여 n8n 설정의 비활성화된 노드 목록에서 제거하세요. 예를 들어, 모든 노드를 활성화하려면 NODES_EXCLUDE="[]"로 설정하거나, 필요한 특정 노드만 제거하세요.

기본적으로 OAuth 콜백 URL에 인증 요구#

n8n은 기본적으로 OAuth 콜백 엔드포인트에 인증을 요구합니다. N8N_SKIP_AUTH_ON_OAUTH_CALLBACK의 기본값이 true(인증 불필요)에서 false(인증 필요)로 변경됩니다.

마이그레이션 방법: v2.0으로 업그레이드하기 전에 N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false로 설정하고 인증이 활성화된 상태에서 OAuth 통합이 작동하는지 테스트하세요.

N8N_RESTRICT_FILE_ACCESS_TO 기본값 설정#

n8n은 파일 작업이 발생할 수 있는 위치를 제어하기 위해 N8N_RESTRICT_FILE_ACCESS_TO의 기본값을 설정합니다. 이는 ReadWriteFile 및 ReadBinaryFiles 노드에 영향을 줍니다. 기본적으로 이 노드들은 ~/.n8n-files 디렉토리의 파일에만 접근할 수 있습니다.

마이그레이션 방법: 파일 노드를 사용하는 워크플로를 검토하고 허용된 디렉토리의 파일에만 접근하는지 확인하세요. 다른 디렉토리에 대한 접근을 허용해야 하는 경우, N8N_RESTRICT_FILE_ACCESS_TO 환경 변수를 원하는 경로로 설정하세요.

N8N_GIT_NODE_DISABLE_BARE_REPOS 기본값을 true로 변경#

기본적으로 Git node는 이제 보안상의 이유로 bare 리포지토리를 차단합니다. N8N_GIT_NODE_DISABLE_BARE_REPOS의 기본값이 true로 설정되어, 이 설정을 변경하지 않는 한 bare 리포지토리가 비활성화됩니다.

마이그레이션 방법: 워크플로에서 bare 리포지토리를 사용해야 하는 경우, 환경 설정에서 N8N_GIT_NODE_DISABLE_BARE_REPOS=false로 설정하여 활성화하세요.

데이터#

MySQL/MariaDB 지원 중단#

n8n은 더 이상 MySQL 및 MariaDB를 스토리지 백엔드로 지원하지 않습니다. 이 지원은 v1.0에서 지원 중단으로 예고되었습니다. 최상의 호환성과 장기 지원을 위해 PostgreSQL을 사용하세요. MySQL node는 기존과 같이 계속 지원됩니다.

마이그레이션 방법: v2.0으로 업그레이드하기 전에 데이터베이스 마이그레이션 도구를 사용하여 MySQL 또는 MariaDB에서 PostgreSQL 또는 SQLite로 데이터를 이전하세요.

SQLite 레거시 드라이버 제거#

n8n은 신뢰성 문제로 인해 레거시 SQLite 드라이버를 제거합니다. 풀링 드라이버가 기본 및 유일한 SQLite 드라이버가 됩니다. 풀링 드라이버는 WAL 모드, 단일 쓰기 연결, 읽기 연결 풀을 사용합니다. 벤치마크 결과 최대 10배 빠른 속도를 보여줍니다.

마이그레이션 방법: sqlite-pooled 드라이버가 자동으로 기본값이 됩니다. DB_SQLITE_POOL_SIZE를 0보다 큰 값으로 설정하여 지금 바로 풀링을 활성화할 수 있습니다. 기본 풀 크기는 2로 설정됩니다.

인메모리 바이너리 데이터 모드 제거#

n8n은 실행 중 바이너리 데이터를 메모리에 보관하는 N8N_DEFAULT_BINARY_DATA_MODE의 default 모드를 제거합니다. 더 나은 성능과 안정성을 위해 v2부터 다음 옵션들이 제공됩니다:

  • filesystem: 바이너리 데이터가 파일 시스템에 저장됩니다. 일반 모드의 기본 옵션입니다.
  • database: 바이너리 데이터가 데이터베이스에 저장됩니다. 큐 모드의 기본 옵션입니다.
  • s3: 바이너리 데이터가 S3 호환 스토리지에 저장됩니다.

N8N_AVAILABLE_BINARY_DATA_MODES 설정도 제거되므로, 이제 모드는 N8N_DEFAULT_BINARY_DATA_MODE에 의해서만 결정됩니다.

마이그레이션 방법: 설정에 따라 파일 시스템 또는 데이터베이스 모드가 자동으로 사용됩니다. n8n 인스턴스에 바이너리 데이터를 저장할 충분한 디스크 공간이 있는지 확인하세요. 자세한 내용은 바이너리 데이터 설정을 참조하세요.

설정 및 환경#

dotenv 업그레이드#

n8n은 dotenv 라이브러리를 사용하여 .env 파일에서 환경 설정을 로드합니다. 라이브러리가 버전 8.6.0에서 최신 버전으로 업그레이드되며, 이로 인해 .env 파일 파싱 방식이 변경될 수 있습니다. 주요 호환성 변경 사항은 다음과 같습니다:

  • 백틱 지원 (#615): 값에 백틱이 포함된 경우 단일 또는 이중 따옴표로 감싸세요.
  • 멀티라인 지원: 이제 멀티라인 값을 사용할 수 있습니다.
  • #는 주석의 시작을 나타냅니다: #으로 시작하는 줄은 주석으로 처리됩니다.

마이그레이션 방법: dotenv 변경 로그를 검토하고 새 버전과의 호환성을 보장하도록 .env 파일을 업데이트하세요.

n8n --tunnel 옵션 제거#

n8n --tunnel 커맨드라인 옵션이 v2.0에서 제거됩니다.

마이그레이션 방법: 현재 개발 또는 테스트에 --tunnel 옵션을 사용하는 경우, ngrok, localtunnel 또는 Cloudflare Tunnel과 같은 대체 터널링 솔루션으로 전환하세요. 이 변경 사항을 반영하도록 워크플로 및 문서를 업데이트하세요.

QUEUE_WORKER_MAX_STALLED_COUNT 제거#

QUEUE_WORKER_MAX_STALLED_COUNT 환경 변수와 중단된 작업에 대한 Bull 재시도 메커니즘이 제거됩니다. 이는 종종 혼란을 야기하고 안정적으로 작동하지 않았기 때문입니다.

마이그레이션 방법: 설정에서 이 환경 변수를 삭제하세요. 업그레이드 후 n8n은 더 이상 중단된 작업을 자동으로 재시도하지 않습니다. 중단된 작업을 처리해야 하는 경우, 자체 재시도 로직 구현이나 모니터링을 고려하세요.

N8N_CONFIG_FILES 제거#

N8N_CONFIG_FILES 환경 변수가 제거되었습니다.

마이그레이션 방법: 설정에서 이 환경 변수를 삭제하세요. 설정을 환경 변수, .env 파일 또는 _FILE 기반 설정으로 이전하세요.

CLI 및 워크플로#

CLI 명령어 update:workflow 교체#

update:workflow CLI 명령어가 지원 중단되고 유사한 기능을 더 명확하게 제공하는 두 개의 새 명령어로 교체됩니다:

  • publish:workflow with parameters id and versionId (optional)
    • --all 파라미터는 프로덕션 환경에서 실수로 워크플로가 게시되는 것을 방지하기 위해 제거됩니다
  • unpublish:workflow with parameters id and all

마이그레이션 방법: 새 publish:workflow 명령어를 사용하여 ID별로 개별 워크플로를 게시하고, 선택적으로 버전을 지정하세요. 게시 취소의 경우 새 unpublish:workflow 명령어를 사용하세요. 이를 통해 워크플로 게시 상태에 대한 더 나은 명확성과 제어가 가능합니다.

외부 훅#

지원 중단되는 프론트엔드 워크플로 훅#

workflow.activeChange 및 workflow.activeChangeCurrent 훅이 지원 중단됩니다. 이는 새 훅 workflow.published로 대체됩니다. 새 훅은 워크플로의 모든 버전이 게시될 때 트리거됩니다.

마이그레이션 방법: workflow.activeChange 및 workflow.activeChangeCurrent 대신 새 workflow.published 훅을 사용하도록 코드를 업데이트하세요. 이 훅은 더 일관된 동작을 제공하며 워크플로 버전이 게시될 때마다 트리거됩니다.

릴리즈 채널#

n8n은 릴리즈 채널 이름을 각각 latest에서 stable로, next에서 beta로 변경했습니다.

stable 태그는 최신 안정 릴리즈를 나타내며, beta 태그는 최신 실험적 릴리즈를 나타냅니다. 이 태그들은 npm과 Docker Hub 모두에서 사용 가능합니다. 현재는 n8n이 계속해서 릴리즈에 latest 및 next 태그를 붙입니다. 이 태그들은 향후 메이저 버전에서 제거될 예정입니다.

권장 사항: n8n 버전을 특정 버전 번호로 고정하세요. 예: 2.0.0

문제 보고#

n8n 2.0으로 업데이트하는 동안 문제가 발생하면 커뮤니티 포럼에서 도움과 지원을 받으세요.