n8n 워크플로우 자동복구 템플릿 — AI가 승인 없이 운영 워크플로우를 직접 고친다

n8n.io 공식 템플릿 마켓플레이스에 공개된 이 워크플로우를 가져오면, 인스턴스 안 어떤 워크플로우가 에러를 내든 그 원인을 Azure OpenAI가 진단해 일시적 문제면 재시도하고 로직 결함이면 워크플로우 JSON을 직접 고치는 자동복구 구조를 만들 수 있습니다. 이 시리즈에서 지금까지 다룬 승인 게이트 템플릿들은 AI의 결과물을 사람이 먼저 확인해야 다음 단계로 넘어갔는데, 이 템플릿은 정반대입니다. 패치는 이미 적용된 뒤에야 슬랙 알림이 옵니다.

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

"n8n으로 에러 핸들링도 해봤어요"라고 말하면 보통은 슬랙 알림 하나 붙인 정도로 끝납니다. 이 템플릿은 그보다 훨씬 앞서 나갑니다. "에러가 나면 AI가 원인을 진단해서, 일시적 문제면 재시도하고 로직 문제면 워크플로우 자체를 고칩니다"라고 답할 수 있게 해줍니다.

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

• 글로벌 에러 감지 설계 — 노드 하나가 아니라 인스턴스 전체 워크플로우의 실패를 한곳에서 받아 처리하는 구조를 설계해본 경험
• AI 기반 원인 분류와 분기 — 에러가 "일시적 문제(RETRY)"인지 "로직 결함(FIX)"인지 AI로 나누고, 각각 다른 후속 조치로 보내는 조건 분기를 짜본 경험
• n8n API로 워크플로우 자체를 다루는 경험 — 워크플로우를 실행 대상이 아니라 읽고 쓰는 데이터로 다뤄본 경험. 자기 자신이 속한 인스턴스를 대상으로 자동화를 만든 셈입니다

이 세 가지가 중요한 이유는 따로 있습니다. 이 템플릿은 동시에 "완전 자율 자동화가 항상 정답은 아니다"라는 반례이기도 해서, 그 위험을 설명할 수 있는 것 자체가 무거운 면접 소재가 됩니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Auto-heal failing workflows with Azure OpenAI, n8n API, and Slack alerts라는 이름으로 공개된 템플릿이고, 제작자는 Rahul Joshi입니다. 카테고리는 DevOps와 AI Summarization으로 등록돼 있어서, 운영 자동화나 인시던트 대응 사례를 찾다가 마주치는 경우가 많은 템플릿입니다.

공식 설명에 따르면 이 템플릿은 "AI 기반 자율 복구 엔진"으로, n8n 인스턴스 전체의 실패를 모니터링하다가 Azure OpenAI로 근본 원인을 분석하고, 실시간으로 고장 난 워크플로우를 고칩니다. 일시적인 네트워크 문제와 로직 에러를 구분해서, 전자는 재시도하고 후자는 n8n API를 통해 워크플로우 JSON을 동적으로 패치합니다. 제작자는 이걸 "닫힌 루프(closed-loop)" 자동화라고 부르는데, 사람 개입 없이도 핵심 프로세스를 계속 돌아가게 한다는 의미입니다.

n8n 설치나 기본 노드 조작법은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글은 이 템플릿의 자동 진단·패치 구조와 그 구조가 감수하는 위험에 집중합니다.

구조 — Trigger / Task / Target

공식 문서의 "What this template does"와 "Features"를 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 정리하면 이렇습니다. 이 템플릿의 핵심은 Task 끝에서 흐름이 RETRY와 FIX 두 갈래로 갈리고, 사람은 그 갈래 어느 쪽에도 끼어들지 않는다는 점입니다.

• Trigger — Error Trigger 노드가 인스턴스 전역의 에러를 감지하며 흐름을 시작합니다. 공식 설명에는 "Global Error Listener(catch-all, instance-wide)"라고 표현돼 있습니다.
• Task — 먼저 이 에러가 자기 자신(치유 시스템)에서 난 건 아닌지 걸러내고, n8n API로 실패한 워크플로우의 최신 JSON 전체를 가져온 뒤, Azure OpenAI GPT-4o가 이 에러를 "RETRY(타임아웃·레이트 리밋 같은 일시적 문제)"인지 "FIX(잘못된 파라미터·로직 에러)"인지 진단합니다. RETRY로 판정되면 공식 설명대로 API 레이트 리밋을 존중하는 쿨다운 기간을 둔 뒤 재시도하고, FIX로 판정되면 JavaScript 엔진이 AI가 낸 수정값을 워크플로우 코드에 직접 주입해 n8n API로 저장합니다.
• Target — 두 갈래 모두 마지막엔 Slack으로 모입니다. 성공적으로 고쳤으면 그 결과를, 에러가 너무 복잡해서 자동으로 처리할 수 없으면 사람에게 도움을 요청하는 메시지를 보냅니다. FIX 경로에서는 패치된 워크플로우 자체도 결과물 중 하나입니다.

만들기

이 템플릿의 공식 페이지에는 번호가 매겨진 별도의 Setup 섹션이 없습니다. 대신 REQUIREMENTS와 WHAT THIS TEMPLATE DOES에 나온 내용을 준비 순서대로 재구성했습니다.

1. n8n API 접근 활성화와 API 키 발급

이 워크플로우는 실행되는 워크플로우가 아니라, n8n 인스턴스 자체를 API로 읽고 쓰는 워크플로우입니다. 공식 요구사항에는 "n8n Instance (Cloud or self-hosted) with API access enabled"와 "n8n API Key (to read/update workflows)"가 따로 명시돼 있습니다. n8n 설정에서 API 접근을 켜고 API 키를 발급받아, HTTP Request 노드의 인증 정보로 연결해두는 게 첫 단계입니다. 이 키가 있어야 실패한 워크플로우의 JSON을 읽고, 패치한 뒤 다시 저장할 수 있습니다.

2. Azure OpenAI 계정과 GPT-4o 배포 준비 — 일반 OpenAI 키와는 다른 절차

여기서 자주 헷갈리는 지점이 있습니다. 이 템플릿은 GPT-4o를 쓰지만, openai.com에서 발급받는 일반 API 키(sk-로 시작하는)가 아니라 Azure OpenAI 계정이 필요합니다. Azure OpenAI는 Azure 구독 안에 별도의 리소스를 만들고, 그 리소스 안에 GPT-4o 모델의 "배포(deployment)"를 하나 만들어야 실제로 호출할 수 있는 구조입니다. n8n에도 일반 OpenAI 크리덴셜과는 별개로 Azure OpenAI 전용 크리덴셜 타입이 있어서, 배포 이름·엔드포인트 URL·API 버전·API 키까지 따로 입력해야 합니다.

3. 이 워크플로우를 다른 워크플로우들의 에러 워크플로우로 지정

Error Trigger 노드는 그 자체로는 아무것도 감지하지 않습니다. n8n에서 워크플로우가 실패했을 때 어떤 에러 워크플로우를 호출할지는 그 워크플로우 자신의 설정(Settings의 Error Workflow 항목)에서 개별적으로 지정합니다. 이걸 인스턴스 전체에 한 번에 적용하는 별도 설정은 없어서, 공식 설명의 "인스턴스 전역 모니터링"을 실제로 구현하려면 인스턴스 안의 워크플로우마다 이 워크플로우를 에러 워크플로우로 하나하나 지정해야 합니다. 새로 만드는 워크플로우에도 매번 지정해야 하고, 이 작업을 빼먹은 워크플로우가 실패하면 그 실패는 이 흐름에 잡히지 않은 채 조용히 지나갑니다.

4. 자기 자신에서 난 에러 걸러내기

공식 설명에 "Prevents Infinite Loops: automatically filters out errors originating from the healing system itself"라고 돼 있는 것처럼, 이 워크플로우 자신이 실패했을 때(예: Azure OpenAI 호출이 타임아웃 나는 경우) 그 에러가 다시 자신을 트리거하면 무한 루프에 빠질 수 있습니다. 그래서 Error Trigger 다음에 필터 단계가 들어가 있습니다. 다만 정확히 어떤 값(워크플로우 ID 등)으로 "이건 내 에러다"를 판별하는지는 공식 텍스트에 나와 있지 않아서, 직접 구현할 때는 이 판별 조건을 스스로 설계해야 합니다.

5. RETRY·FIX 진단과 두 갈래 후속 처리

Azure OpenAI GPT-4o가 가져온 워크플로우 JSON과 에러 내용을 보고 RETRY와 FIX 중 하나로 판정합니다. RETRY면 API 레이트 리밋을 존중하는 대기 시간을 둔 뒤 원래 워크플로우를 재시도하고, FIX면 JavaScript 엔진이 AI가 제안한 수정값을 워크플로우 JSON에 주입한 뒤 n8n API로 그 워크플로우를 업데이트합니다. 공식 설명은 이 패치 엔진을 "구조화된 출력 파싱으로 유효하고 배포 가능한 코드 변경을 보장한다"고 소개합니다.

6. Slack 앱 연결

마지막은 결과를 알리는 Slack 앱 연결입니다. 성공적으로 고쳤을 때와, 에러가 너무 복잡해서 사람 도움이 필요할 때 각각 다른 메시지를 보내도록 구성돼 있고, 공식 설명에는 특정 실행(execution)으로 바로 이동하는 딥링크까지 포함된다고 돼 있습니다.

주의할 점 · 제약

이 템플릿에서 가장 눈여겨봐야 할 부분은 개별 노드 설정이 아니라 설계 철학 자체입니다.

• 승인이 아니라 사후 통보다 — Slack 알림은 패치가 이미 적용된 다음에 옵니다. 사람이 먼저 확인하고 승인해야 다음 단계로 넘어가는 이 시리즈의 다른 템플릿들과 정확히 반대되는 설계입니다. AI가 원인을 잘못 진단하거나(예: 실제로는 로직 에러인데 일시적 문제로 오판) 잘못된 값을 주입하면, 사람이 알아채기도 전에 운영 워크플로우가 이미 바뀌어 있을 수 있습니다.
• 에러가 "너무 복잡하다"는 기준이 불명확하다 — 공식 설명은 "요청이 너무 복잡하면 사람에게 도움을 요청한다"고만 돼 있고, 어떤 에러가 그 기준을 넘는지는 확인되지 않았습니다.
• Azure OpenAI 전용이다 — 앞서 설정 단계에서 본 것처럼 일반 OpenAI 계정으로는 그대로 가져다 쓸 수 없고, Azure 쪽 리소스·배포 절차를 따로 거쳐야 합니다.
• n8n API 접근이 전제 조건이다 — API 접근이 막혀 있는 인스턴스에서는 이 템플릿을 애초에 쓸 수 없습니다.
• 자기 자신 필터링의 구체적인 판별 로직은 공식 텍스트에 없다 — 앞서 밝힌 대로, "자기 자신에서 난 에러를 걸러낸다"는 원리만 확인되고 정확한 구현은 확인되지 않았습니다.

포트폴리오·면접 포인트

이 템플릿을 포트폴리오에 넣을 때는 그대로 베꼈다는 인상보다, 이 설계가 어디까지 위험을 감수하는지 이해하고 있다는 인상을 주는 게 더 중요합니다. 예를 들어 FIX 경로 앞에 승인 스텝을 하나 끼워 넣어 "재시도는 완전 자동, 로직 패치는 사람 확인 후 적용"하는 절충안으로 바꿔보고, 원래 설계와 무엇이 달라졌는지 비교하는 것 자체가 좋은 포트폴리오 소재입니다.

면접에서는 "왜 이 템플릿은 사람 승인을 거치지 않나요?"보다 "이런 완전 자율 설계를 실제로 쓴다면 어떤 조건에서 써야 할까요?"라는 질문이 나올 가능성이 큽니다. 이렇게 답할 수 있습니다. 되돌리기 쉬운 액션(재시도)과 되돌리기 어려운 액션(운영 로직을 바꾸는 패치)을 구분해서, 전자는 완전 자동으로 두고 후자에만 승인 게이트나 최소한의 사후 검토를 추가하는 식으로 설계할 수 있다는 답입니다. 이렇게 답하면 이 템플릿의 화려함이 아니라 그 안에 숨은 트레이드오프를 알고 있다는 인상을 줍니다.

다음 액션

다음 편에서는 정반대 방향의 템플릿을 다룹니다. AI가 하나도 들어가지 않고, Wait 노드로 여러 단계에 걸친 이메일 시퀀스를 순서대로 실행하는 순수 오케스트레이션 자동화입니다. 이번 편에서 본 "완전 자율이 항상 정답은 아니다"라는 교훈과 짝을 이뤄, "자동화가 곧 AI는 아니다"라는 반대쪽 교훈을 확인하게 됩니다.