외부 DB 없이 완성하는 워크플로우 자동화: n8n Data Tables 활용 가이드

n8n 신규 기능 업데이트(데이터 테이블 & Python Task Runner)

1️⃣ Native Data Tables 기능 도입

n8n 내에서 구조화된 데이터를 직접 저장·조회할 수 있는 새로운 기능입니다.
외부 DB(MySQL, Postgres 등)를 따로 구축하지 않아도 되고, Credentials 설정도 필요 없습니다.

주요 기능

• n8n 내부에 데이터 테이블 생성·관리 가능
• 구조화된 데이터(JSON 기반) 저장
• 워크플로우에서 Data Table Node를 통해 CRUD 처리 가능
• 간단한 Lookup Table, 상태 저장(State Management)에 적합

생성 방법

1. Canvas → Create workflow 드롭다운 → Create Data table
2. Node Panel → Data Table Node 삽입 → 조회·삽입·업데이트·삭제 수행

저장 용량

• 모든 플랜에서 50MB 제한
• Self-hosted는 설정으로 확장 가능

실무 활용 예시

• 워크플로우 상태(State) 저장
  → "마지막으로 처리한 ID", "처리 횟수" 등
• 기준값(화이트리스트/블랙리스트) 저장
• 외부 API 매핑 테이블 관리
• 간단한 캐싱 도구로 활용
• 고객 세그먼트, 내부 코드 매핑 등 Lookup 용도

보안 체크포인트

• Cloud 환경에서는 n8n 내부 스토리지에 저장되므로 민감정보 저장 금지
• Self-hosted의 경우 DB 백엔드(storage)에 대한 접근제어 필요
• 백업/복구 규칙을 별도로 수립
• 테이블 변경 이력 생성이 필요하다면 별도 로깅 노드 연결 필요

2️⃣ Native Python Task Runner (Beta)

n8n workflow 내부에서 실제 Python 모듈을 실행할 수 있는 기능이 추가되었습니다.
이제 더 이상 제한된 "Python Sandbox"가 아니라, Self-hosted에서는 실 Python 모듈 실행이 가능합니다.

⚠️ Breaking Change
기존 Python 실행 방식과 호환되지 않는 변경이 있습니다.

적용 범위

• Self-hosted: 즉시 적용 가능
• n8n Cloud: 점진적 전환 예정

가능한 기능

• 실제 Python 라이브러리 사용 가능 (예: pandas, numpy, requests 등)
• 외부 API 고급 처리
• 데이터 분석·머신러닝 간단 적용
• 레거시 Python 스크립트 통합

실무 활용 예시

• Slack/ES/DB 데이터 가공 후 고급 Excel, PDF 생성
• 보안 로그(예: EDR, WAF 등) Python 기반 분석 후 Slack 알림
• Kafka 이벤트 처리 전 고급 필터링
• 머신러닝 모델 inference 자동화
• 기존 사내 Python 스크립트(배포·모니터링·보안 점검) n8n로 통합

보안 체크포인트

• Self-hosted에서 실제 Python 실행 = 권한 있는 환경에서 코드 실행 위험 증가
• 다음 설정 필수
  • 별도의 Python 실행 환경(venv) 격리
  • 네트워크 접근 제한 (Outbound Rule)
  • 모듈 설치 정책 화이트리스트
  • Python 노드 실행 로그 저장 및 변경 감사 적용
  • n8n API 인증(Access Token) 강화
• Cloud 환경에서는 n8n 측에서 Sandbox 보안 강화 후 점진적 제공

항목	주요 내용
Native Data Tables	n8n 내부 DB 기능. Lookup/State 용도로 유용. 50MB 제한.
Python Task Runner	실 Python 모듈 실행 가능. Self-hosted 우선 적용. 기존 방식과 호환 깨짐.
보안 관점	민감정보 저장 금지, Python 환경 격리, 모듈 사용 정책 및 실행 로그 필요.

Data tables 개념 정리

무엇을 하는 기능인가?

Data tables는 n8n 안에 내장된 “가볍고 구조화된 데이터 저장소”입니다.
즉, 외부 DB(MySQL, PostgreSQL 등)를 따로 만들지 않고도, n8n 프로젝트 내부에서

• 데이터를 저장하고
• 테이블 형태(행/열)로 관리하고
• 워크플로우에서 읽고/추가하고/수정/삭제할 수 있는 기능입니다.

어떤 상황에서 유용한가?

문서에 나온 사례를 조금 더 풀어서 설명하면

1. 워크플로 간 상태 유지 (Persisting data across workflows)
   • 예
     • “어제 마지막으로 처리한 주문 ID” 저장
     • “최근 동기화 시각(last_sync_at)” 저장
     • 여러 워크플로가 같은 기준값을 공유해야 할 때
2. 중복 실행 방지 / 트리거 제어 (Markers)
   • 이미 처리한 이벤트/ID/메시지를 테이블에 저장해두고
     • 새 이벤트가 올 때마다 WHERE id = ? 식으로 체크 → 있으면 스킵
   • 시간/카운터 기준으로 트리거 실행 주기 제어 등
3. 프롬프트/메시지 재사용 (Reusing prompts/messages)
   • LLM 프롬프트, 안내 문구, 템플릿 문자열 등을 테이블에 저장
   • 다른 워크플로에서 공통으로 Data table node로 읽어와서 사용
4. AI 평가 데이터 저장 (Storing evaluation data)
   • AI 응답 품질 평가 점수, reviewer 코멘트 등 저장
   • 나중에 품질 분석, 모델 비교, 프롬프트 개선에 활용
5. 워크플로 실행 결과 저장 (Storing generated data)
   • 외부로 바로 내보내지 않고, “중간 저장소”로 Data table 활용
   • 일정 주기로 테이블의 데이터를 모아서 다른 시스템으로 Export
6. 여러 소스 데이터를 결합/정제 (Combining data sources)
   • API A와 API B 결과 데이터를 테이블에 저장한 뒤
   • n8n에서 조합하거나, 후처리/레포팅 용도로 사용
7. Lookup Table (참조 테이블)
   • 지사 코드 ↔ 국가명, 에러 코드 ↔ 설명, 고객 타입 ↔ 정책 등
   • 조건 분기/매핑을 위한 “빠른 참조” 용도로 사용

Data tables 사용 방법

크게 두 단계입니다.

1️⃣ 테이블 생성 (관리 화면에서)
2️⃣ 워크플로에서 Data table node로 조작

1. Step 1: Data table 생성

1. n8n 프로젝트에서 상단 탭 중 Data tables 탭을 선택합니다.
2. 화면 우측 상단의 split button(분할 버튼)을 클릭하고
   → Create Data table 선택
   

   

3. 새 Data table 생성 화면이 열리면
   • 테이블 이름을 입력 (나중에 워크플로에서 구분하기 쉽게)
     • 예: ai_prompt_library, processed_order_marker, webhook_event_log 등
4. 테이블 뷰에서 할 수 있는 작업
   • 열(Column) 추가 및 순서 변경
   • 행(Row) 추가, 삭제, 수정
   • 기존 데이터 값 편집

즉, 간단한 “웹 UI 기반 스프레드시트” 느낌으로 관리할 수 있습니다.

운영 팁

열 이름은 나중에 워크플로에서 JSON key처럼 쓰일 것을 고려해 소문자+스네이크 케이스 권장

• 예: id, created_at, status, prompt_text, score

2. Step 2: 워크플로에서 Data table 접근 (Data table node)

워크플로 안에서는 Data table 노드를 사용해서 테이블을 조작합니다.

이 노드를 통해

• 특정 조건으로 데이터 조회 (Select / Get)
• 새 행 추가 (Insert)
• 조건에 맞는 행을 업데이트(Update)
• 필요 시 삭제(Delete)

를 할 수 있습니다.

300x250

대표적인 활용 패턴 예시

1. 중복 실행 방지
   • Webhook → Data table node(Get)로 event_id 존재 여부 확인
   • 없다면 처리 + Data table node(Insert)로 event_id 저장
   • 있다면 바로 종료/무시
2. Lookup 기반 분기
   • Incoming 데이터에서 error_code를 받음
   • Data table node로 WHERE error_code = X 조회
   • 결과 row의 severity나 description을 기준으로 분기 처리
3. AI 평가 결과 축적
   • LLM 응답, 사용자 피드백, 메타 정보 등을 Data table에 Insert
   • 이후 별도 워크플로에서 정기적으로 Export → 외부 분석 시스템으로 전송

제한사항 및 동작 특성

1. 용량 제한 (Storage Limit)

• 기본 최대 용량: 50MB (전체 Data tables 기준)
• Self-hosted 환경에서는 아래 환경변수로 조정 가능
  • N8N_DATA_TABLES_MAX_SIZE_BYTES

예시 (Docker Compose)

services:
  n8n:
    image: n8nio/n8n
    environment:
      - N8N_DATA_TABLES_MAX_SIZE_BYTES=104857600  # 100MB

2. 사용량 경고/차단 동작

• 80% 도달 시: 경고 발생
• 100% 도달 시
  • UI에서 수동 추가 불가
  • 워크플로 내에서 Data table에 insert/update 시 오류 발생
    • 즉, 해당 워크플로 실행이 실패할 수 있음

운영 팁

용량 모니터링용 워크플로를 하나 만들어서

• Data tables 상태를 정기적으로 확인 → Slack/메일 알림
• 기간이 지난 데이터(예: 30일 이전) 정리/삭제 로직을 자동화하면 좋습니다.

3. 접근 범위(권한 스코프)

• 프로젝트 내 Data tables
  • 같은 프로젝트의 모든 팀원이 접근 가능 (기본 설정)
• Personal space에서 만든 테이블
  • 본인만 접근 가능

즉, 팀 단위 공유 데이터와 개인 작업용 데이터가 분리됩니다.

🔐 보안 관점

• 민감 데이터(개인정보, 액세스 토큰 등)는 가능한 프로젝트 공유 테이블에 저장하지 않는 것이 좋습니다.
• 정말 필요한 경우, 프로젝트 구조를 잘 분리하고 권한 모델(누가 어느 프로젝트에 접근하는지)과 함께 관리해야 합니다.

Data tables vs Variables 비교

문서에 나온 표를 실제 사용 시 관점으로 해석해보겠습니다.

항목	Data tables	Variables
UI에서 표 형태로 보기 (Tabular view)	✅ 지원	❌
행/열 기반 구조	✅	❌ (주로 개별 값)
Cross-project 접근	❌ (프로젝트 스코프)	✅ (프로젝트 간 공유 가능)
개별 값 표시/관리	❌ (항상 테이블)	✅
짧은 값에 최적화	❌	✅
구조화된 데이터(다수 컬럼, 레코드)	✅	❌
프로젝트 단위로 스코프	✅	❌ (프로젝트 외부에서도 사용 가능)
값을 Expression으로 직접 사용	❌	✅ (예: {{$vars.myValue}})

정리하자면

• Variables
  • “키–값 형태의 설정값 / 짧은 텍스트” 관리에 적합
  • 예: API Base URL, 토큰, 플래그 값, 상수 등
  • 워크플로 Expression에서 바로 쓰기 좋음
• Data tables
  • “행/열 구조의 다수 레코드” 관리에 적합
  • 예: 여러 개의 프롬프트, 여러 개의 코드 매핑, 로그성 데이터, AI 평가 결과 등

간단 키–값이면 Variables, 여러 줄·여러 컬럼이면 Data tables로 생각하면 됩니다.

Data tables와 외부 시스템 간 Import/Export

Data tables는 자체적인 “파일로 내보내기/불러오기 버튼” 개념이 아니라, 워크플로로 데이터를 import/export 하는 방식입니다.

1. Export 패턴 (n8n → 외부 시스템)

1. Data table node로 데이터 조회
2. 그 데이터를 이용해
   • HTTP Request node로 외부 API에 전송
   • Spreadsheet/File node로 CSV/XLSX 등 파일 생성
   • S3/FTP/SMTP 등으로 업로드/발송

예

• “매일 자정에 Data table의 지난 하루 평가 로그를 조회 → CSV로 만들고 → S3에 업로드 → Slack 알림”

2. Import 패턴 (외부 시스템 → n8n Data table)

1. 외부 시스템/파일/DB에서 데이터 조회
   • HTTP Request, MySQL/Postgres node, Read Binary File node 등
2. 데이터를 JSON/행 구조로 변환
3. Data table node에서 Insert/Update 실행

예

• “매일 새벽, 운영 DB에서 ‘코드-설명 매핑 테이블’을 조회 → Data table에 업데이트 → 나머지 워크플로는 이 테이블 기준으로 Lookup 수행”

보안·운영 체크리스트

보안팀장/보안관리자 시각에서 보면, Data tables는 “작은 내장 DB”라서 다음 항목들이 중요합니다.

1. 데이터 분류
   • 어떤 Data table에 “어떤 등급의 데이터”가 들어가는지 정의
   • 민감정보(PII, 인증정보 등)는極力 배제
   • 불가피하게 사용할 경우 → 암호화, 마스킹, 접근통제 전략 필요
2. 용량 관리
   • 80% 경고 발생 시 Alert를 받아볼 수 있는 워크플로 구축
   • 오래된 데이터 자동 삭제 또는 외부 장기 보관 저장소로 이동
3. 권한/프로젝트 구조
   • Data tables는 프로젝트 단위로 공유되므로
   • 프로젝트 멤버 구성 = Data table 접근자 목록과 동일
   • 민감한 테이블은 별도의 프로젝트 또는 Personal space 사용 고려
4. 변경 이력/감사
   • Data tables 자체에 Change Log는 없으므로
   • 중요한 테이블은
     • 변경 시 로그 남기는 워크플로 구성 (누가, 언제, 무엇을 변경)
     • 또는 변경 이벤트가 발생할 때마다 별도 “audit 테이블/외부 SIEM”으로 기록
5. 백업/복구 전략
   • Self-hosted 환경에서는 n8n 데이터 저장소(주로 DB나 파일)에 대한 백업 정책 필요
   • 특히 Lookup/마커/상태 데이터가 워크플로 동작을 좌우한다면, 주기적 백업 필수

마무리 요약

• Data tables는 n8n 안에 내장된 경량 구조화 데이터 저장소
• 워크플로 간 상태 공유, 중복 실행 방지, 프롬프트/매핑 관리, AI 평가 로그, Lookup에 매우 적합
• UI에서 생성·편집하고, 워크플로에선 Data table node로 CRUD
• 기본 50MB 제한, Self-hosted는 N8N_DATA_TABLES_MAX_SIZE_BYTES로 조정 가능
• Variables는 “짧고 개별적인 값”, Data tables는 “행/열 구조 데이터”에 최적
• Export/Import는 워크플로를 통해 API/파일/DB와 연동하는 방식
• 보안 관점에서는 데이터 분류, 접근권한, 용량·백업·로그 정책을 반드시 같이 설계해야 함