n8n 컨퍼런스 In The Loop 2026에서 밝힌 제품 방향: 관건은 신뢰

n8n이 2026년 10월 13~14일 독일 베를린에서 첫 대형 컨퍼런스 In The Loop 2026을 열었습니다. n8n 사용자·커뮤니티·파트너·기업 고객이 한자리에 모인 이 행사에서 n8n은 지난 1년의 성과와 앞으로의 제품 방향을 공유했습니다.

n8n이 이번에 공개한 제품 방향은 AI 덕분에 자동화를 만드는 일이 더 이상 병목이 아니며, 이제는 자동화와 에이전트를 믿고 작업을 맡길 수 있느냐가 관건이라는 진단에서 출발하는데요. 이에 n8n은 AI로 자동화를 만드는 경험을 계속 향상하는 한편, 조직이 구축한 자동화를 검증하고 실행하고 모니터링하고 관리하는 단계별로 새로운 계획을 선보였습니다.

In The Loop 2026 'Inside n8n's Next Chapter' 세션. 화면은 자동화 생애주기 단계별로 발표 내용을 요약한 장표

인포그랩은 n8n 공식 Expert Partner로 초청받아 n8n이 앞으로 제품을 어떻게 바꿔 갈지 In The Loop 2026 현장에서 직접 보고 들었습니다. 이 글에서는 행사에서 공개한 n8n 제품 방향과 계획을 살펴보고, 현재 n8n을 도입했거나 다른 도구로 자동화를 운영하는 조직에 지금 필요한 조치를 정리했습니다.

n8n이 밝힌 앞으로의 제품 방향과 그 배경은 무엇일까?

n8n은 In The Loop 2026에서 자동화 생애주기의 다섯 단계별로 제품 방향을 소개했습니다. 자동화 생애주기는 자동화를 만들어 운영하기까지 거치는 일련의 단계인데요. 행사 둘째 날 'Inside n8n's Next Chapter' 세션 발표를 맡은 n8n 제품·디자인 부사장(VP Product and Design) David Roberts는 이 생애주기가 소프트웨어 개발 생애주기와 거의 같다고 설명했습니다. 그는 n8n이 처음부터 자동화 생애주기 전체를 한 제품에서 다루도록 설계됐다고 밝혔는데요. 이 생애주기의 다섯 단계와 단계별 제품 방향은 다음과 같습니다.

• 빌드(자동화를 만드는 단계): 누구나 n8n 안에서든 외부 코딩 에이전트에서든 AI로 자동화를 만들게 합니다.
• 감사(자동화가 의도대로 동작한다는 확신을 얻는 단계): 캔버스(워크플로를 그래프로 보여 주는 편집 화면)는 유지하고, AI 워크플로를 시험하는 평가(Evaluations) 기능은 더 쉽게 쓸 수 있게 만듭니다.
• 배포(만든 자동화를 운영 환경에서 실행하는 단계): 실행 엔진을 처음부터 새로 만들어 실행 중인 작업이 멈추거나 유실되지 않게 합니다.
• 모니터링(실행 중인 자동화를 지켜보고 실패를 조사하는 단계): 여러 n8n 인스턴스를 한곳에서 관측하게 합니다.
• 관리·거버넌스(조직 안에서 자동화를 운영하는 단계): 에이전트에게 전용 아이덴티티를 주고, 정책과 한도로 행동 범위를 정합니다.

자동화 생애주기 5단계와 단계별 n8n의 발표 내용(인포그랩 재구성)

빌드: 누구나, 어디서든 AI로 자동화를 만들게 합니다

자동화 생애주기의 첫 단계인 빌드는 그동안 가장 어렵고 시간이 오래 걸리는 단계였습니다.

제품 방향

n8n은 빌드 단계에서 자동화를 만드는 기본 방식을 AI로 옮기고 있습니다. David Roberts는 n8n 안에서 쓰는 n8n Assistant와 n8n 외부의 코딩 에이전트를 잇는 MCP 서버에 계속 투자하겠다고 밝혔는데요. 사용자가 어디서 자동화를 만들지 n8n이 정하지 않겠다는 원칙입니다.

배경

n8n이 AI 빌드에 힘을 싣는 이유는 이제 자연어로 자동화를 만들 수 있게 되면서 빌드 방식이 근본적으로 달라졌기 때문입니다. David Roberts는 예전에는 도구로 무언가를 만들려면 그 도구의 문법과 사고방식부터 익혀야 했지만, 자연어 입력이 이를 바꿨다고 설명했습니다. 그는 "앞으로는 누구도 자동화를 손으로 만들지 않을 것"이라고 내다봤는데요. 발표에 따르면 n8n Assistant와 나눈 대화는 160만 건이 넘고, n8n Assistant가 만든 워크플로는 80만 개가 넘죠. 코딩 에이전트로 MCP를 거쳐 빌드하는 사용자는 평균 사용자보다 워크플로를 3배 더 많이 만든다고 합니다.

n8n 안팎에서 AI로 워크플로를 만드는 두 경로(인포그랩 재구성)

제품 계획

n8n이 빌드 단계에서 개선하겠다고 밝힌 기능은 다음 세 가지입니다.

• n8n Assistant(v2.40 전 이름은 AI Assistant): 자연어 설명으로 워크플로를 만들어 주는 n8n의 AI 비서입니다. 이는 지난 6개월 사이 n8n에서 워크플로를 만드는 기본 방식이 됐죠. n8n Cloud는 Starter·Pro, 셀프 호스트는 Community·Registered Community·Business 플랜에서 쓸 수 있습니다. David Roberts는 Enterprise 플랜에도 곧 제공한다고 밝혔습니다.
• n8n MCP 서버: MCP(Model Context Protocol)는 AI 애플리케이션이 외부 도구와 데이터에 연결하는 표준 프로토콜입니다. Claude Code나 Codex 같은 코딩 에이전트를 n8n MCP 서버에 연결하면 그 에이전트로 워크플로를 만들고 수정하며, 테스트하고 게시할 수 있죠. 인스턴스 소유자나 관리자가 MCP 접근을 활성화해야 쓸 수 있습니다.
• n8n Agents: 워크플로와 별개로 에이전트를 만드는 기능입니다. n8n은 그동안 워크플로 안에서만 쓰던 에이전트를 워크플로 밖으로 꺼내 워크플로와 나란히 만들 수 있게 했습니다. 9월에 모든 사용자에게 배포된 n8n Agents로 기존 방식보다 에이전트를 쉽게 만들 수 있고요. 스킬도 지원하고, MCP로 도구를 연결하기도 더 쉽습니다. n8n Agents는 공식 문서 기준으로 아직 Preview(정식 출시 전 단계로, 동작이 바뀔 수 있음) 상태입니다.

n8n은 위 기능을 개선하는 것 외에도 세 가지 계획을 예고했습니다.

• 시작 문턱 낮추기: 자동화를 처음 만드는 사용자도 쉽게 시작하도록 지원합니다. 그 예로 든 automation mining 스킬은 9월 n8n 공식 GitHub에 n8n Labs 실험으로 공개됐는데요. 이 스킬을 쓰면 코딩 에이전트가 세션 기록·Slack 채널·메일함을 읽기만 하며 반복되는 수작업을 찾아 자동화 후보를 제안합니다.
• 사용자 컨텍스트 가져오기(bring your own context): 사용자의 컨텍스트를 에이전트에 가져오게 합니다. 에이전트는 사용자를 더 많이 알수록 일을 훨씬 더 잘하기 때문인데요. 지금은 Settings에 저장한 선호(preferences) 한 가지만 n8n Assistant와 MCP 클라이언트에 전하는 컨텍스트 관리 기능이 Preview로 있습니다.
• 스스로 고치는 자동화(self-healing): 사용자가 실행 기록을 늘 들여다보지 않아도 되도록 자동화가 스스로 문제를 고치게 합니다. 지금은 n8n Assistant에게 실패한 실행을 살펴보게 하면 오류를 찾아 수정할 방법을 제안받을 수 있는데요. 사용자가 직접 요청해야 동작하는 기능입니다.

감사: 캔버스는 유지하고 평가 기능은 더 쉽게 쓸 수 있게 만듭니다

자동화를 만들었다면 다음은 그 자동화를 믿고 작업을 맡겨도 되는지 확인할 차례입니다.

제품 방향

n8n은 감사 단계에서 자동화의 로직과 흐름을 읽어 보는 검사(inspection)는 캔버스로, 자동화를 실제로 실행해 결과를 확인하는 테스트는 평가 기능으로 지원하겠다고 밝혔습니다. 캔버스는 지금처럼 유지하고, 평가 기능은 더 쉽게 쓸 수 있게 만든다는 계획이죠.

배경

n8n이 감사에 힘을 싣는 이유는 빌드가 빨라지면서 감사가 새 병목이 됐기 때문입니다. David Roberts는 병목 하나를 없애면 다른 곳에 새 병목이 생긴다며, 에이전트가 만든 코드를 리뷰하느라 일이 밀린 엔지니어들처럼 에이전트가 40초 만에 만든 자동화를 사람이 40분 동안 확인하는 일이 생긴다고 설명했습니다.

에이전트는 40초 만에 자동화를 만들고 사람은 40분 동안 확인한다는 발표 장표

그는 감사가 신뢰의 문제라 AI에게 가장 마지막에 넘길 단계라고 봤습니다. 그만큼 사람이 직접 확인할 수단이 중요한데 캔버스가 그 역할을 할 수 있죠. n8n이 사용자 약 1000명에게 설문조사를 진행한 결과, 55%가 AI가 완벽하더라도 캔버스가 없으면 n8n을 쓸 이유가 상당 부분 사라진다고 응답해 캔버스를 향한 높은 선호를 드러냈습니다. 한편, David Roberts는 AI 에이전트를 제대로 테스트해야 한다는 말은 모두가 하지만, 개념이 복잡하고 결과를 일일이 훑어야 해 실제로 하는 팀은 드물다고 짚었습니다.

제품 계획

n8n이 준비하는 두 기능의 계획은 다음과 같습니다.

• 캔버스: n8n은 사용자가 캔버스가 필요한 이유로 꼽은 상위 세 가지에 힘을 싣겠다고 밝혔는데요. 그 세 가지는 단계 사이 데이터 흐름 이해(24%), 워크플로가 하는 일 이해(18%), 문제가 생겼을 때 디버깅(18%)입니다. 다만 n8n은 이를 위해 캔버스에 어떤 기능을 더할지는 아직 발표하지 않았습니다. 지금도 사용자는 실패한 실행의 데이터를 캔버스로 불러와(Debug in editor) 워크플로를 고친 뒤 같은 데이터로 다시 실행해 볼 수 있습니다. 이 기능은 n8n Cloud 전 플랜과 셀프 호스트 Registered Community·Business·Enterprise 플랜에서 쓸 수 있습니다.
• 평가 기능: n8n은 업무 판단이 필요한 결정만 사용자에게 보여 주고 나머지는 AI가 처리하게 해 평가 기능을 이해하기 더 쉽고 사용하기 덜 번거롭게 개선하고 있습니다. 평가 기능은 테스트용 입력 여러 건을 모은 데이터 세트로 AI 워크플로를 실행하고, 그 출력을 확인해 품질을 검증하는데요. 지금 쓸 수 있는 평가 방식은 배포 전에 예시 몇 개로 결과를 비교하는 가벼운 평가와 운영 데이터로 품질을 수치로 재는 지표 기반 평가입니다. n8n은 바뀐 평가 기능의 출시 일정은 밝히지 않았고, 곧 자세히 소개하겠다고 밝혔습니다.

배포: 실행 엔진을 처음부터 새로 만듭니다

감사를 마친 자동화를 이제 운영 환경에서 실행해야 하죠. David Roberts는 자동화에 익숙하지 않은 사람일수록 안정적인 실행의 중요성을 놓치기 쉽다고 짚었습니다.

제품 방향

n8n은 배포 단계에서 실행 엔진을 처음부터 새로 만들어 실행 중인 작업이 멈추거나 유실되지 않게 하겠다고 밝혔습니다. 실행 엔진은 n8n에서 가장 먼저 만들어진 핵심 장치로, 지금도 상당 부분이 창업자 Jan Oberhauser가 처음 쓴 코드로 이뤄졌는데요. n8n은 지금 엔진에도 단일 장애 지점은 없지만, 새 엔진으로 실행을 더 견고하게 만들겠다고 밝혔습니다.

배경

n8n이 실행 엔진을 처음부터 새로 만드는 이유는 실행의 신뢰성이 엔진 설계에서 정해지기 때문입니다. n8n은 엔진 대신 AI가 쓴 코드를 그대로 실행하는 방식도 실제로 시도했지만, 코드를 실행할 때 갖춰야 할 요구 사항을 적어 보니 결국 워크플로와 많이 닮아 있었다고 설명했습니다. 즉, 실행 중인 모든 단계를 보고 이해할 수 있어야 멈춘 곳에서 다시 시작하고 실패를 자동으로 재시도할 수 있다는 거죠. n8n은 새 엔진을 설계하며 신뢰성 원칙 여섯 가지를 세웠는데요. 발표에서는 이를 식당에 빗대 설명했습니다.

제품 계획

새 엔진의 일곱 가지 기능은 위의 신뢰성 원칙을 엔진에 적용한 것으로, 모두 출시 전입니다.

새 워크플로 엔진의 일곱 가지 기능을 정리한 발표 장표

1. 단계마다 진행 저장(save after every step): 지금은 선택 항목인 실행 진행 저장이 새 엔진에서는 핵심 기능이 됩니다. 다만 항상 활성화되는지는 발표되지 않았습니다.
2. 복구 스윕(reconciliation sweep): 어떤 이유로든 멈춘 작업을 찾아 바로잡습니다.
3. 안전한 재시도(safe retries): 안전하다고 표시한 단계만 자동으로 재시도해 결제나 메일 발송 같은 일이 두 번 일어나지 않게 합니다.
4. 샌드박스 코드 실행(code in sandbox): 코드를 샌드박스에 격리해 완전히 믿기 어려운 코드도 안전하게 실행할 수 있게 합니다.
5. 워커 풀(worker pools): 특정 워크플로에 실행 용량을 따로 배정해 다른 워크플로의 영향을 받지 않게 합니다.
6. 리소스 격리와 한도(resource isolation and limits): 리소스를 격리하고 사용 한도를 둡니다.
7. 스케줄러에서 대기(waits in the scheduler): 워크플로가 기다려야 할 때 대기를 메모리에 두지 않고 시간이 정해진 작업으로 저장합니다.

모니터링: 여러 n8n 인스턴스를 한곳에서 관측하게 합니다

운영 환경에서 실행하는 자동화도 계속 모니터링하다가 실패하면 원인을 찾아야 합니다.

제품 방향

n8n은 모니터링 단계에서 여러 n8n 인스턴스를 한곳에서 관측하게 하겠다고 밝혔습니다. 이를 위해 여러 인스턴스를 아우르는 관측 앱으로 새로 발표한 것이 Manifest입니다.

배경

n8n이 Manifest를 내놓는 이유는 인스턴스를 여럿 쓰는 조직에 모든 인스턴스를 한 번에 보는 관측 계층이 필요하기 때문입니다. 조직은 개발과 운영을 나누거나 부서마다 인스턴스를 따로 두는데요. 발표장에서도 인스턴스를 둘 이상 쓰는지 묻는 질문에 많은 사람이 손을 들었습니다. David Roberts는 n8n에 관측 기능은 이미 여럿 있지만, 여러 인스턴스를 모두 아우르는 관측 계층이 필요하다는 요청을 사용자들에게서 들어 왔다고 설명했습니다.

제품 계획

Manifest는 n8n 인스턴스와 함께 쓰는 별도 앱으로, 어떤 자동화가 있고 실행 중인지, 누가 소유하는지, 어떤 자동화가 어떤 시스템을 건드리는지 보여 줍니다. n8n은 처음에는 n8n 자동화부터 다루고, 이후 조직 안의 모든 종류의 자동화로 범위를 넓히고 싶다고 밝혔습니다. n8n이 자사의 자동화 운영 방식을 공개한 핸드북은 Manifest를 읽기 전용 관측·관리 계층으로 소개하며, 아직 탐색 단계라 기능이 바뀔 수 있다고 설명하고 있습니다. n8n은 발표 당시 여러 인스턴스를 쓰는 사용자를 대상으로 트라이얼 참가자를 모집했습니다.

한 인스턴스 안을 들여다보는 기능은 지금도 n8n에 있습니다. 공식 문서 기준으로 인사이트 대시보드(n8n Cloud Pro·Enterprise, 셀프 호스트 Business·Enterprise)와 감사 이벤트도 내보내는 로그 스트리밍(Enterprise)이 있죠. 몇 달 전에는 관측 데이터 수집 표준인 OpenTelemetry로 실행을 추적하는 기능(v2.19.0 이상, Preview)도 추가됐고, 메트릭은 이후 릴리즈에서 추가할 예정입니다.

인스턴스마다 쓰는 지금의 관측 기능과 여러 인스턴스를 아우르는 Manifest(인포그랩 재구성)

관리·거버넌스: 에이전트에게 전용 아이덴티티를 주고 행동 범위를 정합니다

마지막 단계인 관리·거버넌스는 자동화를 운영하는 사람과 조직의 일을 다룹니다.

제품 방향

n8n은 관리·거버넌스 단계에서 에이전트에게 전용 아이덴티티를 주고, 정책과 한도로 행동 범위를 정하겠다고 밝혔습니다. 거버넌스 계획은 접근·가드레일·소유와 품질·보안 네 영역에 걸쳐 있으며, 에이전트뿐만 아니라 사용자 관리와 워크플로 테스트도 다룹니다.

배경

n8n이 거버넌스에 힘을 싣는 이유는 에이전트가 늘어날수록 관리할 대상도 증가하고, 에이전트에게 맡길 수 있는 일의 한계가 결국 신뢰로 귀결되기 때문입니다. David Roberts는 예전의 섀도 IT(IT 부서가 모르는 사이 쓰이는 시스템)가 스프레드시트 매크로였다면 지금은 민감한 시스템에 접근하는 수많은 에이전트일 수 있다며, 에이전트가 유능해질수록 우리가 던져야 할 질문도 '(에이전트가 이걸) 할 수 있는가'에서 '(에이전트가 하는 일을) 믿을 수 있는가'로 바뀐다고 짚었습니다. 그러나 사람이 매번 승인하는 방식에는 한계가 있죠. 같은 승인을 100번 요청받으면 생각 없이 버튼을 누르게 되는 '승인 피로'가 생깁니다.

제품 계획

n8n이 거버넌스 영역을 구분하는 네 가지 질문과 영역별 장치는 다음과 같습니다.

접근·가드레일·소유와 품질은 시스템이 설계대로 동작할 때를, 보안은 누군가 시스템을 악용하려 할 때를 다룹니다. n8n이 영역별로 예고한 계획 가운데 발표에서 직접 설명한 것은 다섯 가지인데요.

• 에이전트 전용 아이덴티티(접근): 지금 에이전트는 대개 사람의 로그인을 빌려 써서 누가 한 일인지 구분할 수 없고 그 사람의 권한을 모두 갖습니다. n8n은 권한 범위가 좁고 누가 한 일인지 추적할 수 있으며 언제든지 회수할 수 있는 에이전트 전용 아이덴티티를 만들겠다고 밝혔습니다.
• SCIM 프로비저닝과 사용자 그룹(접근): SCIM(System for Cross-domain Identity Management)은 ID 공급자의 사용자 계정을 다른 서비스에 자동으로 만들고 지우는 표준입니다. SCIM 프로비저닝은 퇴사자의 시스템 접근이 끊기는지, 그 사람의 자동화가 계속 실행되는지를 다루고, 사용자 그룹은 사용자 관리를 쉽게 합니다.
• 정책과 한도(가드레일): 정책은 작업을 실행 전에 막고, 한도는 일이 잘못됐을 때 피해의 상한을 정합니다. 반복과 재시도에 빠진 에이전트의 비용이 모르는 사이 급증하지 않도록 넘을 수 없는 한도를 둡니다.
• 워크플로 테스트(소유와 품질): 소프트웨어 개발의 규율을 자동화와 에이전트에도 들여오고, 엄격한 평가를 결정론적(같은 입력에 늘 같은 결과를 내는) 워크플로에도 적용합니다.
• 코드 샌드박스(보안): 완전히 믿기 어려운 코드도 샌드박스 안에서는 안전하게 실행되기에 코드를 더 자유롭게 쓸 수 있습니다. 예를 들어, 자동화에 원하는 라이브러리를 자유롭게 불러올 수 있는데요. David Roberts는 이것이 n8n이 오래전부터 넣고 싶었던 기능이라고 밝혔습니다.

발표 끝 무렵 나온 요약 장표의 관리·거버넌스 단계에는 에이전트 전용 아이덴티티와 함께 'Advanced promotion'과 'Reviews'도 적혀 있었지만, 발표에서 구체적으로 설명하지는 않았습니다.

정책과 한도 가운데 일부 기능은 이미 적용돼 있습니다. v2.43부터 에이전트 설정에서 월 예산과 세션 지출 상한을 정할 수 있고, v2.44부터는 정책으로 막은 크리덴셜 종류의 모델 공급자가 에이전트 모델 선택 목록에서 잠금 표시와 함께 비활성화됩니다. 크리덴셜 종류 정책과 노드 종류 정책은 Preview 상태입니다.

보안 권고는 이미 체계를 갖췄습니다. n8n은 늘어난 취약점 제보를 모두 분류해 고치고 대응 정보를 담은 보안 권고를 메일로 보내며, 코드가 공개돼 있어 누구나 수정 내용을 확인할 수 있다고 설명했습니다. 제보 증가세는 차츰 잦아들고 있지만, 그 흐름이 이어질 거라고 가정하지 않고 보안 투자를 계속하겠다고 밝혔습니다.

단계별로 지금 쓸 수 있는 기능과 예고된 기능

단계별로 지금 사용할 수 있는 기능과 예고된 기능을 표로 정리하면 다음과 같습니다(2026년 11월 4일 기준).

n8n을 운영하는 조직에는 지금 어떤 조치가 필요할까?

n8n이 예고한 기능은 아직 출시 전이지만, 발표에서 n8n이 제시한 관점은 지금 자동화 운영에도 적용할 수 있습니다. 에이전트에게 무엇을 맡기고 무엇을 결정론적으로 만들지, 어떤 자동화부터 검증할지, 조직의 자동화 현황을 어떻게 모니터링할지, 에이전트에게 권한을 얼마나 줄지는 n8n을 사용하지 않더라도 에이전트와 워크플로를 함께 운영하는 조직이라면 같이 고민할 문제이기도 하죠.

n8n의 발표 내용과 공식 문서를 바탕으로 현재 n8n을 운영하는 조직에 필요한 조치를 정리했습니다.

n8n을 운영하는 조직에 지금 필요한 네 가지 조치와 해당 생애주기 단계(인포그랩 정리)

1. 에이전트에게 맡길 일과 워크플로로 만들 일을 구분해야 합니다

에이전트와 워크플로는 용도가 다르기에 자동화를 설계할 때 어디에 무슨 작업을 맡길지부터 정해야 하는데요. 입력이 들어올 때마다 무엇을 어떻게 처리할지 새로 판단해야 하는 일은 에이전트로, 처리 방법을 설계할 때 한 번 정해 두면 되는 일은 워크플로로 만듭니다.

n8n이 발표에서 비교한 두 방식의 차이는 다음과 같습니다.

이유

에이전트 단계를 여러 번 이어 붙일수록 작업 전체가 정확하게 끝날 확률은 떨어집니다. AI는 같은 입력에도 다른 결과를 낼 수 있어 단계마다 성공 확률이 곱해지면서 작은 오류 가능성이 쌓이기 때문인데요. David Roberts는 정확도가 95%인 에이전트 단계를 열 번 이어 붙이면 작업 전체가 정확하게 끝날 확률이 약 60%로 떨어진다며 "지능이 흔해지면 확실성이 귀해진다"라고 설명했습니다. 이에 그는 결정론적으로 만들 수 있는 부분은 모두 결정론적으로 만들라고 권했죠.

비용도 문제입니다. 에이전트는 실행할 때마다 모델을 호출해 같은 판단을 되풀이하는데요. 같은 일을 반복할수록 모델 사용료와 처리 시간이 늘어납니다. David Roberts도 같은 일을 하루 1만 번 하는 에이전트는 아주 비싼 워크플로일 뿐이라고 지적했습니다.

2. 감사가 필요한 AI 워크플로부터 평가 기능으로 테스트해야 합니다

모든 자동화를 같은 수준으로 테스트하기보다 감사가 필요한 AI 워크플로를 골라 평가 기능부터 적용해야 합니다. 배포 전에는 예시 몇 건으로 가볍게 확인하고, 운영 데이터가 쌓이면 지표로 품질을 정밀하게 측정하는 식으로 테스트 단계를 높입니다.

이유

테스트에는 데이터 세트를 만들고 결과를 일일이 확인하는 품이 들어 모든 자동화에 같은 수준으로 적용하기 어렵습니다. David Roberts도 감사가 늘 중요한 것은 아니라며, 작업이 복잡해 잘못될 여지가 있을 때, 잘못되면 업무에 피해가 생길 때, 여러 사람이 함께 만들어 모두가 전체 맥락을 알지는 못할 때 감사가 중요하다고 꼽았죠.

특히 AI 워크플로는 로직을 읽어 보는 것만으로는 결과를 장담할 수 없는데요. n8n 공식 문서도 코드는 결정론적이라 동작을 추론할 수 있지만 AI 모델은 그렇지 않아 여러 입력을 넣어 실행해 보며 출력을 평가해야 한다고 설명합니다.

3. 자동화 현황을 파악하고 기록으로 관리해야 합니다

인스턴스를 여럿 운영한다면 어떤 자동화가 실행되고 있는지, 누가 소유하는지, 어떤 시스템에 연결되는지 등 현황을 자동화마다 기록해야 합니다. 이 정보는 인스턴스별 목록으로 정리해 담당자가 바뀔 때마다 갱신하고, 여러 인스턴스의 실행 기록은 로그 스트리밍이나 OpenTelemetry로 한곳에 모아 확인합니다.

이유

자동화와 에이전트가 늘어날수록 무엇이 어디서 실행되고 있는지 파악하기 어려워집니다. 이 정보가 없으면 장애가 났을 때 책임자를 찾기 어렵고, 퇴사자가 만든 자동화가 주인 없이 계속 실행되는지도 알기 어렵죠. 그러면 장애 대응이 늦어지고, 아무도 관리하지 않는 자동화가 민감한 시스템에 계속 접근하는 섀도 IT로 남을 수 있습니다.

David Roberts가 SCIM 프로비저닝이 다룰 문제로 퇴사자의 시스템 접근 단절 여부와 그 사람의 자동화 실행 여부를 함께 꼽을 만큼 n8n도 이 문제를 중요하게 보고 있습니다.

4. 에이전트와 사용자에게는 필요한 권한만 줘야 합니다

에이전트에게는 맡긴 일에 필요한 만큼만, 사용자에게는 지금 하는 일에 필요한 만큼만 권한을 줘야 합니다. 에이전트 도구에는 사람 계정의 크리덴셜을 빌려 쓰지 말고 그 일에 필요한 권한만 가진 전용 계정의 크리덴셜을 사용하고, 퇴사자는 ID 공급자와 n8n 양쪽에서 계정을 삭제하는 식입니다.

이유

지금 에이전트는 대개 사람의 로그인을 빌려 쓰는데요. 문제가 생겨도 사람이 한 일인지 에이전트가 한 일인지 구분할 수 없고요. 에이전트는 그 사람의 권한을 모두 갖게 됩니다. n8n Agents도 도구를 추가할 때 사용한 크리덴셜로 외부 시스템에 접근하기에 권한 범위가 넓은 크리덴셜을 쓰면 에이전트가 실수하거나 프롬프트 인젝션에 넘어갔을 때 맡긴 일과 상관없는 데이터까지 바꾸거나 유출할 수 있죠.

사용자도 마찬가지입니다. 편집 권한을 넓게 주면 실수 하나가 워크플로에 연결된 여러 시스템으로 확산될 수 있고요. SAML 기반 SSO에서는 ID 공급자에서 지운 퇴사자가 n8n에 로그인된 상태로 남아 워크플로를 계속 실행하거나 바꿀 수 있습니다.

맺음말

지금까지 In The Loop 2026에서 n8n이 밝힌 제품 방향과 그 배경, n8n을 운영하는 조직에 지금 필요한 조치를 살펴봤습니다. 정리하면 다음과 같습니다.

1. n8n은 AI로 자동화를 만드는 경험을 계속 다듬는 한편, 감사부터 관리·거버넌스까지 단계마다 만든 자동화를 믿고 맡기는 데 필요한 계획을 내놓았습니다. 더 쉽게 쓸 수 있는 평가 기능, 처음부터 새로 만드는 실행 엔진, 여러 인스턴스를 한곳에서 관측하는 Manifest, 에이전트 전용 아이덴티티와 정책·한도가 대표적입니다.
2. n8n이 이런 방향을 잡은 것은 빌드가 빨라지면서 감사가 새 병목이 됐고, 에이전트가 유능해질수록 AI에게 맡길 수 있는 일의 한계가 결국 신뢰로 귀결되기 때문입니다. 에이전트 단계가 이어질수록 작업 전체가 정확하게 끝날 확률이 떨어지니 결정론적으로 만들 수 있는 부분은 모두 결정론적으로 만들라는 것이 n8n의 권고입니다.
3. 에이전트에게 맡길 일과 워크플로로 만들 일을 구분하고, 감사가 필요한 AI 워크플로부터 평가 기능으로 테스트하며, 자동화 현황을 파악해 기록으로 관리하고, 에이전트와 사용자에게 필요한 권한만 주는 일은 예고된 기능의 출시와 상관없이 운영 조직이 지켜야 할 원칙입니다.