n8n dataTable로 외부 DB 없이 자동화 데이터 쌓기

자동화를 짜다 보면 "이 결과를 어딘가 저장해 두고 다음 실행 때 다시 꺼내 쓰고 싶다"는 순간이 와요. 그런데 그때마다 PostgreSQL 인스턴스를 새로 띄우고 연결 정보를 관리하는 건 부담스럽죠. 라이프케어로그 마케팅 자동화도 같은 고민을 했고, 작은 저장소는 n8n 내장 dataTable로 해결했어요.

dataTable이 맞는 자리

dataTable은 n8n 안에서 행/열로 데이터를 저장하는 가벼운 표예요. 풀스펙 DB는 아니지만, 다음 같은 상황에 잘 맞아요.

• 워크플로우끼리 주고받을 중간 상태를 남길 때
• 주기적으로 집계한 요약 결과를 누적할 때
• 외부 DB까지 갈 필요 없는 수백~수천 행 규모일 때

저는 게시 기록과 거기서 뽑은 학습(어떤 형식이 반응이 좋았는지)을 dataTable에 쌓아요. 별도 DB 없이 n8n 하나로 수집·집계·소비가 한 바퀴 돌아요.

쌓고 → 집계하고 → 다시 꺼내 쓰는 한 바퀴

패턴은 단순해요.

1. 스케줄 트리거가 주기적으로 깨워요.
2. 게시 로그를 읽어 차원별(채널·길이·훅 유형)로 평균 반응을 집계해요.
3. 결과를 학습 테이블에 upsert해요. 키를 결정적으로 만들어 두면 같은 주기에 다시 돌려도 행이 중복되지 않아요.
4. 콘텐츠 생성 단계가 그 테이블을 읽어 "지난 반응" 한 줄을 참고로 받아요.

스케줄 트리거→로그 읽기→차원별 집계→dataTable upsert→생성단계가 다시 읽기

실전에서 한 번 데인 부분

API로 행을 읽을 때 한 가지 함정이 있었어요. 한 번에 가져오는 행 수 상한을 넘기면, 에러 메시지 없이 빈 응답이 오기도 해요. 그걸 "데이터 0건"으로 오해하면 학습이 통째로 비어 버려요. 그래서 행이 많아지면 커서로 페이지를 나눠 끝까지 읽도록 바꿨어요. 응답이 비었을 때 "정말 없는 건지, 상한을 넘은 건지"를 구분하는 게 핵심이에요.

언제 진짜 DB로 갈까

dataTable은 만능이 아니에요. 복잡한 조인이 필요하거나, 동시 쓰기가 많거나, 수만 행을 넘어가면 PostgreSQL로 옮기는 게 맞아요. 중요한 건 처음부터 크게 시작하지 않는 것이에요. 작은 표로 한 바퀴를 먼저 돌려 보고, 한계가 보일 때 옮겨도 늦지 않아요.

혼자 만들 때는 "지금 필요한 가장 작은 저장소"가 대개 정답이에요. 일단 데이터가 한 곳에 결정적으로 모이기 시작하면, 그 위에 자동화를 얹는 건 훨씬 쉬워져요.