n8n 워크플로우 백업 자동화 — n8n으로 n8n 자신을 구글드라이브에 저장하기

n8n.io 공식 템플릿 마켓플레이스에 공개된 백업 워크플로우를 가져오면, n8n 노드로 자기 자신의 전체 워크플로우 목록을 조회해 JSON으로 export하고, 구글드라이브에 시각별 폴더로 쌓은 뒤 직전 백업은 자동으로 정리하는 자기 관리형 백업 자동화를 만들 수 있습니다.

이 템플릿 하나로 보여줄 수 있는 것

자동화를 하나둘 만들다 보면 반드시 한 번은 겪는 사고가 있습니다. 워크플로우를 수정하다가 실수로 지우거나, 다른 사람이 덮어써서 어제까지 잘 돌던 버전이 사라지는 경우입니다. 워크플로우가 한두 개일 때는 다시 만들면 그만이지만, 열 개 스무 개로 늘어나면 이야기가 달라집니다. 이 템플릿은 그 문제를 "n8n으로 n8n을 백업한다"는 메타적인 방식으로 풉니다.

면접에서 "자동화를 여러 개 운영해본 적 있어요?"라는 질문을 받으면, 이 템플릿은 이렇게 답할 근거가 됩니다. "워크플로우가 늘어나면서 백업 자동화까지 함께 운영했습니다. n8n 자체 API로 전체 워크플로우를 주기적으로 구글드라이브에 JSON으로 저장하게 만들었습니다."

문장 하나지만 안에 들어간 역량은 세 가지입니다.

• n8n 자체 API 활용 — n8n 노드로 자기 자신의 워크플로우 목록·정의를 조회하는, 도구를 도구 대상으로 쓰는 메타 자동화 경험
• 배치 순회 처리 — Loop Over Items 노드로 여러 항목을 하나씩 순회하며 각각 파일로 만들어 업로드하는 경험
• 운영 위생 관리 — 오래된 산출물을 자동으로 정리해서 스토리지가 무한정 쌓이지 않게 설계하는 경험

이 세 가지는 워크플로우 백업뿐 아니라 로그 파일 정리, 오래된 리포트 삭제, 일정 기간 지난 백업 로테이션처럼 "정기적으로 스냅샷을 남기고 낡은 것은 치우는" 유형의 운영 자동화 전부에 그대로 쓰입니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Backup all n8n workflows to Google Drive every 4 hours라는 이름으로 공개된 템플릿이고, 제작자는 Zacharia Kimotho입니다. 카테고리는 DevOps로 등록돼 있습니다.

공식 설명에 따르면 이 템플릿은 원래 GitHub에 정기적으로 워크플로우를 백업하던 작업을 대신해, 구글드라이브를 백업 저장소로 쓰도록 만든 것입니다. n8n 인스턴스에 문제가 생기더라도 워크플로우를 잃어버리지 않게 해주는 것이 목적이라고 설명합니다. Git 리포지토리를 따로 관리할 필요 없이, 이미 쓰고 있는 구글드라이브 계정 하나로 백업을 끝낸다는 점이 이 템플릿의 포인트입니다.

n8n 설치나 기본 노드 조작법은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글은 이 템플릿의 구조 자체에 집중합니다.

구조 — Trigger / Task / Target

공식 문서의 "How it works"는 세 문장뿐입니다. 새 폴더를 만들고, 전체 워크플로우를 순회하며 JSON으로 업로드하고, 이전 백업을 지운다는 것입니다. 이걸 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 재구성하면 아래와 같습니다.

• Trigger — 스케줄 트리거입니다. 공식 Setup 단계가 "필요한 스케줄을 정하라"고 안내하고 템플릿 이름 자체가 "4시간마다"이므로, 기본값은 4시간 간격으로 보이며 워크플로우 개수나 변경 빈도에 따라 조정하는 걸 전제로 합니다.
• Task — 먼저 백업 시각을 이름으로 새 폴더를 만듭니다. 그다음 n8n 노드로 현재 인스턴스의 전체 워크플로우 목록을 가져와 Loop Over Items로 하나씩 순회하면서, 각 워크플로우를 JSON 파일로 변환해 방금 만든 폴더에 업로드합니다. 마지막으로 이전 백업 폴더를 찾아 삭제합니다.
• Target — 구글드라이브의 백업 폴더입니다. 순회가 끝나면 그 안에는 타임스탬프 이름의 하위 폴더 하나와, 워크플로우 개수만큼의 JSON 파일이 남습니다. 직전 백업은 새 백업이 완성되는 순간 삭제되므로, 드라이브에는 항상 최신 백업 폴더 하나만 남는 구조입니다.

노드 미리보기에 이름이 확인되는 것은 Loop Over Items(Split in Batches), Google Drive, n8n 세 종류이고, 그 밖에 노드가 4개 더 있다고 표시돼 있습니다. 정확히 어떤 노드가 4개 더 있는지는 공식 카드 미리보기만으로는 확인되지 않습니다. 폴더 생성·목록 조회·삭제처럼 Google Drive 안에서도 조작이 여러 번 갈라지는 걸 감안하면, 위 다이어그램의 Google Drive 박스 여러 개가 실제로는 서로 다른 개별 노드일 가능성이 큽니다.

만들기

공식 Setup 단계는 총 6개입니다. 순서는 그대로 두고 각 단계에서 무엇을 확인해야 하는지를 풀어씁니다.

1. 백업을 모아둘 구글드라이브 폴더 만들기

구글드라이브에 이 워크플로우 전용 폴더를 하나 만듭니다. 그 안에 백업 시각 이름의 하위 폴더가 실행할 때마다 새로 만들어지는 구조라서, 최상위 폴더는 처음에 한 번만 준비하면 됩니다.

2. 구글 서비스 계정 만들기

공식 Setup은 서비스 계정(Service Account) 크리덴셜을 만들라고 안내합니다. 구글 노드에서 흔히 쓰는 OAuth2 대신 서비스 계정을 쓰면, 사람이 브라우저로 로그인하고 동의하는 절차 없이 발급받은 키만으로 서버끼리 인증할 수 있습니다. 몇 시간마다 조용히 도는 백그라운드 자동화에는 사람의 로그인·동의 절차에 묶이는 OAuth2보다 서비스 계정 쪽이 잘 맞습니다. 구글 클라우드 콘솔에서 서비스 계정을 만들고 관련 키를 발급받습니다.

3. 폴더를 서비스 계정과 공유하기

1번에서 만든 폴더를 2번에서 발급받은 서비스 계정 이메일과 공유합니다. 서비스 계정은 사람 계정이 아니기 때문에, 이 공유 절차를 건너뛰면 업로드 노드가 폴더에 접근하지 못해 실패합니다.

4. 템플릿 임포트하고 크리덴셜 매핑하기

템플릿을 자신의 n8n 캔버스로 가져온 뒤, Google Drive 노드들에는 2번에서 만든 서비스 계정 크리덴셜을 연결합니다. n8n 노드에는 자신의 n8n API 크리덴셜을 연결하는데, 이 크리덴셜은 인스턴스 설정 메뉴에서 API 키를 발급받아 등록하는 방식입니다. 이 템플릿이 "n8n으로 n8n을 다룬다"는 메타적인 성격을 갖게 되는 지점이 바로 이 크리덴셜입니다.

5. 백업 주기 정하고 관리하기

Schedule Trigger에서 백업을 얼마나 자주 돌릴지 정합니다. 템플릿 이름대로 4시간이 기본값으로 보이지만, 워크플로우 개수가 적고 변경이 드물다면 하루 한 번으로 늘려도 되고, 반대로 여러 명이 동시에 캔버스를 수정하는 시기라면 더 짧게 잡는 게 안전합니다.

6. 활성화

설정을 마쳤으면 Active로 전환합니다. 이후로는 정해진 주기마다 자동으로 새 백업 폴더가 쌓이고 직전 폴더는 정리됩니다.

주의할 점 · 제약

공식 문서에서 확인되는 제약을 정리하면 세 가지입니다.

• 최신 백업 하나만 남는다 — 공식 설명이 "keeps only latest, no accumulating cache on Drive"라고 명시합니다. 즉 이 템플릿은 여러 시점의 이력을 쌓아두는 버전 관리가 아니라, 항상 가장 최근 스냅샷 하나만 유지하는 방식입니다. 지난주 상태로 되돌리고 싶은 경우까지 대비하려면, 삭제 단계를 "가장 오래된 것만 지우고 최근 N개는 남기는" 방식으로 직접 바꿔야 합니다.
• 자격 증명 준비가 다른 템플릿보다 손이 간다 — 구글 계정 하나만 OAuth2로 연결하면 끝나는 템플릿과 달리, 서비스 계정을 별도로 만들고 폴더 공유까지 해줘야 합니다. 여기에 n8n API 크리덴셜까지 더해져 준비할 인증 정보가 두 종류입니다.
• 성공·실패 순서에 대한 설명은 없다 — 공식 문서는 "업로드 후 이전 백업을 삭제한다"는 순서만 밝힐 뿐, 업로드가 중간에 실패했을 때 삭제 단계가 어떻게 처리되는지는 언급하지 않습니다. 이 템플릿을 실제 백업 용도로 쓰려면, 업로드가 확실히 끝난 뒤에만 이전 폴더가 삭제되는지 직접 확인해보는 걸 권합니다.

포트폴리오·면접 포인트

포트폴리오에는 구글드라이브에 쌓인 타임스탬프 폴더 스크린샷과, 그 안에 든 워크플로우 JSON 파일 목록 캡처 한 장이면 충분합니다. 시간을 두고 두 번 실행해서 직전 폴더가 실제로 사라지고 최신 폴더만 남는 장면까지 보여주면, 템플릿을 가져오기만 한 게 아니라 동작 방식을 이해했다는 인상을 줍니다.

면접에서는 "왜 GitHub 대신 구글드라이브에 백업했나요?" 같은 질문이 나올 수 있습니다. 공식 설명을 근거로 "별도의 Git 저장소를 관리하지 않고도, 이미 쓰고 있는 클라우드 스토리지 계정 하나로 백업을 끝낼 수 있어서"라고 답할 수 있습니다. 또는 "왜 최신 백업 하나만 남기나요?"라는 질문에는 "스토리지가 무한정 쌓이는 걸 막기 위한 설계이고, 여러 시점을 남기고 싶다면 삭제 조건을 직접 바꿔야 한다는 한계까지 파악했다"고 답하면, 노드를 그대로 따라 만든 사람과 구조를 이해한 사람이 갈립니다.

같은 패턴은 워크플로우 백업 말고도 응용할 수 있습니다. 정기적으로 상태를 스냅샷으로 남기고 오래된 것은 정리해야 하는 대상이면 무엇이든 이 구조를 그대로 가져다 쓸 수 있습니다. Airtable 베이스 export, Notion 페이지 백업, 서버 로그 로테이션이 대표적인 예입니다.

다음 액션

다음 편에서는 같은 DevOps 카테고리의 템플릿을 다룹니다. 워크플로우가 실패했을 때 텔레그램으로 바로 알려주는 에러 알림 템플릿인데, 이번 편이 "평소에 조용히 스냅샷을 쌓아두는" 자동화였다면 다음 편은 "문제가 생긴 순간 알려주는" 자동화로, 운영 자동화의 또 다른 축을 보여줍니다.