우리 n8n 정상영업합니다: 3rd n8n Seoul Meetup 발표 정리
이 글의 독자AX를 준비하는 인사 담당자와 IT 담당자, 그리고 회사의 지원이 있든 없든 AI를 업무에 넣어야 하는 직장인
2026년 9월 4일 금요일 저녁, 강남 러닝스푼즈에서 열린 세 번째 n8n Seoul Meetup의 발표를 글로 옮겼습니다. 발표 슬라이드 48장에 들어간 도식과 짤을 그대로 실었고, 현장에서 말로 풀었던 내용을 문장으로 채웠습니다. 세 회사에서 n8n을 도입하며 겪은 시행착오가 핵심입니다. 같은 실수를 한 번 덜 하시면 이 글의 목적은 달성입니다.
목차
행사 정보
| 항목 | 내용 |
|---|---|
| 행사명 | n8n Seoul Meetup 3rd - After-Work Networking (Luma 페이지) |
| 일시 | 2026년 9월 4일(금) 19:00~22:00 |
| 장소 | 서울 강남 러닝스푼즈 (Luma에는 강남구로만 공개, 승인자에게 개별 안내) |
| 규모 | 40명, 무료, 승인제 (신청 마감) |
| 주최, 후원 | 데이터팝콘 주최, n8n Community 후원 |
프로그램은 네 토막이었습니다.
| 시간 | 내용 |
|---|---|
| 19:00 | 체크인 및 웰컴 네트워킹 |
| 19:30 | 키노트: n8n 최신 소식, n8n Fest 2026 후기, n8n CLI와 MCP 네이티브 지원 라이브 데모 |
| 19:50 | 실무 사례 발표 (임정): 기업에서는 n8n을 어떻게 도입하고 운영하는가 |
| 20:10 | After-Work Networking, 22:00 마무리 |
이번 밋업은 n8n 입문 강의가 아니라, 직접 워크플로우를 만들어 본 사람들이 경험과 문제를 나누는 자리로 기획됐습니다. 제 세션은 그중 “기업에서는 n8n을 어떻게 도입하고 운영하는지 보여주는 실제 컨설팅 사례” 자리였습니다.
현장 스케치
강남역 야경 위에 Seoul Meetup이 적힌 벽 배너와, 노드 도형이 이어진 입구 X배너가 참가자를 맞았습니다.
입구 테이블에는 n8n 스티커(noderunner, bot boss, AI AGENT ON BOARD, low code high vibes)와 데이터팝콘 명함이 깔려 있었고, 창가 쪽 긴 테이블에는 콜라와 간식 봉투가 40인분 줄지어 있었습니다.
저녁은 버거였습니다. 금요일 퇴근 후 밋업의 정석입니다.
19시 50분, 키노트 뒤에 제 순서였습니다. 스크린에 “우리 n8n 정상영업합니다”가 뜨고 20분을 시작했습니다.
발표 표지는 무너진 건물 사진입니다. 이 짤로 시작한 이유는 뒤에서 말씀드리겠습니다. 결론부터 말하면, 올해 n8n 주변에서 “이제 n8n은 끝났다”는 말이 돌았지만 제가 현장에서 본 n8n은 정상영업 중이었습니다.
발표자 소개
임정입니다. 8년차 데이터 사이언티스트이고 BuildnWrite라는 이름으로 강의와 컨설팅을 합니다. 『n8n이 다 해줌』을 썼고, 10월에 『클로드가 다 해줌』이 나옵니다. n8n과 AI 워크플로우 설계법 강의로 누적 수강생 1000명, 평점 4.9를 받았고, 삼성물산과 KCC, 삼성전자 등에 40회 이상 출강했습니다. 이전 발표로는 “왜 프로덕트 팀은 A/B 테스트를 사랑할까”와 “Claude Code와 데이터 직군의 방향성”이 있습니다.
오늘 주제
오늘 이야기는 하나입니다. n8n을 도입하는 과정에 있는 회사의 사례를 소개하고, 그 안에서 겪은 시행착오와 제 경험을 공유합니다.
신청서를 보니 참석자 39명 중 n8n 초보자가 20명, 주 용도는 사내 업무 자동화가 23명으로 가장 많았습니다. 그래서 노드 하나하나를 설명하기보다 “회사에서 n8n이 언제, 어떻게 쓰이는가”에 집중했습니다.
2025년, n8n은 AI Agent의 트렌드였다
2025년 JavaScript Rising Stars에서 n8n이 1위였습니다 (risingstars.js.org/2025). AI 에이전트 열풍과 함께 n8n이 가장 뜨거웠던 해였고, 저도 그 흐름 위에서 2026년 6월에 이인영 님과 『n8n이 다 해줌』을 냈습니다.
클로드라는 자연재해
그런데 책이 나온 직후 Claude Code가 왔습니다. 이걸 저는 자연재해라고 부릅니다. 터미널에서 “만들어줘” 한 마디로 코드가 나오니, “노코드 툴이 왜 필요하냐, n8n은 죽었다”는 말이 커뮤니티에 퍼졌습니다. 표지의 무너진 건물 사진은 그 분위기를 그대로 옮긴 겁니다. 책 저자 입장에서는 인터뷰 짤 속 표정이 딱 제 심정이었습니다.
그럼에도 저는 n8n을 계속 씁니다. 오늘 발표는 그 이유를 세 개의 사례로 증명하는 자리입니다.
3가지 기업 도입 사례
| 사례 | 조직 | 무엇을 |
|---|---|---|
| 1 | 종합병원 재무팀 | 지출 증빙 자동화 |
| 2 | 국내 대기업 경영지원 | 사내 업무 프로세스 PoC |
| 3 | 1인 기업 (저) | 제 업무 자동화 |
세 사례는 순서대로 이어집니다. 병원에서 배운 것을 대기업에서 반영했고, 대기업에서 배운 것을 제 회사에 적용했습니다.
사례 1. 병원 지출증빙
프로젝트 상황
종합병원 재경팀에서 멘토링 의뢰가 왔습니다. 요구는 명확했습니다. 회사 내 시스템 일부를 n8n으로 비개발 직군이 직접 개발하겠다는 것. 병원장님을 포함해 약 20명이 참석했고, 6주간 개발과 멘토링을 반복했습니다.
풀려는 업무는 세 구간이었습니다.
- 영수증 기록: 종이 영수증을 읽어 항목으로 정리
- 결재선 정리: 직책 체계에 따라 승인자 결정
- 결재 기안: 기존 결재 시스템으로 상신
요구사항
병원 측이 원한 것은 세 가지였습니다.
- 채팅(Chat 노드)으로 전부 처리할 것
- 각 단계를 모두 멀티 에이전트로 만들 것
- 비개발자가 운영할 수 있는 시스템일 것
세 구간을 한 덩어리로 보고, 전부 자동화하자는 요구였습니다.
결정해야 할 때
회의실에서 12명이 저를 바라봅니다. “이거 되나요?” 그 눈빛 앞에서 컨설턴트는 결정을 내려야 합니다. 되게 만들 수는 있습니다. 문제는 “되게 만든 다음”입니다. 아래는 요구사항 세 개를 하나씩 어떻게 풀었는지입니다.
문제 1. 채팅으로 전부 처리할 수 있을 것
n8n의 Chat 노드는 파일 업로드가 아주 간단하게 됩니다. 그래서 처음엔 다들 “채팅으로 다 되겠네”라고 생각합니다. 실제로 만들어 보면 이렇습니다.
- 사용자에게 특정 입력을 정확하게 요구해야 합니다. “영수증 올려주세요”라고 해도 사람은 사진을 여러 장 보내거나 엉뚱한 파일을 보냅니다.
- 파일이 많으면 분리 처리가 필요하고, 서버에 저장하는 로직이 따로 필요합니다.
- 로그인과 채팅 히스토리를 관리해야 합니다.
사실상 챗봇을 만드는 거대한 문제가 됩니다. 영수증 처리를 하려던 프로젝트가 챗봇 플랫폼 개발로 바뀌는 순간입니다.
해결 1. Survey로 돌리기
챗봇은 사용자 입장에서 유연하게 느껴지지만 AI 응답이 느립니다. 그리고 자율성이 늘어난 만큼 소프트웨어 쪽에서 대응해야 할 경우의 수가 복잡해집니다.
그래서 Chat 트리거를 버리고 On form submission 트리거로 바꿨습니다. 설문 양식처럼 정해진 칸에 영수증을 올리고 제출하는 방식입니다. 입력이 고정되니 뒤의 처리도 단순해졌습니다. 사용자는 조금 덜 자유롭지만, 시스템은 훨씬 예측 가능해집니다.
문제 2. 각 단계를 모두 멀티 에이전트로 만들기
위 도식이 실제로 만들어 봤던 구조입니다. 오케스트레이션 에이전트 아래에 영수증 인식 에이전트, 결재선 선언 에이전트, 결재 기안 에이전트가 각각 붙어 있고, 각 에이전트가 자기 모델을 물고 있습니다. 보기엔 근사합니다.
팩트 하나를 말씀드리면, AI 에이전트 하나의 성능을 95%에서 99%로 올리는 것도 매우 힘듭니다. 그런데 이 구조는 에이전트 셋을 이어 붙여서 매끄럽게 돌아가길 원합니다. 하나가 95%면 셋을 거치면 성공률은 곱해져서 떨어집니다. 하나만 흔들려도 전체가 흔들립니다.
해결 2. 멀티 에이전트 out
에이전트를 전부 걷어냈습니다. 최종 워크플로우는 위처럼 단순합니다.
- Trigger: On form submission
- Task: HTTP Request로 OCR API 호출, Edit Fields로 정리, Basic LLM Chain으로 구조화 (Gemini 모델 + Structured Output Parser)
- Target: Google Sheets에 한 행 추가
단순 OCR로 간략화하니 속도와 정확도가 같이 잡혔습니다. 컨설팅 과정에서 OCR 모델 3종을 100회씩 돌려 비교했는데, 범용 LLM으로 영수증을 읽히면 느리거나 정확도가 흔들렸고 문서 전용 파싱 API가 4초 안팎에 100회 전부 맞췄습니다. 이 수치가 “에이전트 셋 대신 OCR 하나”라는 결정의 근거였습니다.
문제 3. 비개발자가 운영할 수 있는 시스템
세 번째 요구는 기술로 풀리지 않았습니다. 실제 상황은 이랬습니다.
- 메인 개발자가 없습니다.
- 결재 기준선은 직책 체계 문제인데, 체계화된 정의 없이 표로만 존재했습니다.
- 직책이 바뀔 때 그 표를 갱신하고 관리할 담당 절차가 없었습니다.
- 쌓이는 데이터 서버(S3)의 관리 정책이 없었습니다.
- AI 에이전트는 계속 발전하는데, 그에 맞춰 구조와 프롬프트를 손볼 담당자가 없었습니다.
n8n으로 워크플로우를 만드는 것과, 그 워크플로우가 1년 뒤에도 돌아가게 하는 것은 완전히 다른 일입니다.
교훈 (병원)
- 노드가 많아진다고 뛰어난 워크플로우가 아닙니다. 오히려 관리 포인트만 늘어납니다.
- AI를 도입하기 전에 데이터 관리(결재선 정리)부터 해야 합니다.
- n8n 무용론이 아닙니다. 개발 지식이 부족하거나 운영할 인력이 없다면 어떤 도구를 써도 어렵습니다.
정리하면, n8n이나 Claude의 문제가 아닙니다. 시스템을 관리하는 영역으로서의 담당자와 설계에 대한 이해가 있어야만 도입과 운영이 가능합니다. 인사 담당자분들께 특히 이 대목을 강조하고 싶습니다. AX 프로젝트의 성패는 툴 선정보다 “이걸 누가 운영하는가”를 조직도에 그려 넣는 데서 갈립니다.
사례 2. 국내 대기업 도입 사례
프로젝트 도입 이유
회사 안에는 SAP이나 자체 구축한 ERP가 있었습니다. 구축한 지 10년이 넘어가는 시점이라, 차세대 개발을 위해 업무와 과제 프로세스를 다시 정의하는 과정에 있었습니다. 이 회사가 n8n을 고른 이유는 보안과 AI Agent를 둘 다 챙길 수 있어서였습니다. 폐쇄망에 설치할 수 있으면서 에이전트를 붙일 수 있는 도구가 많지 않습니다.
Top-down의 AI 프로젝트
- 교육과 PoC 프로젝트를 하나의 패키지로 진행
- 기존 업무를 n8n 폐쇄망, AWS, Postgres를 구축한 서버에서 재현
- 각 조직의 업무를 정의해서 End to End로 개발하는 것이 목표
위에서 결정하고 아래에서 만드는 전형적인 대기업 AI 프로젝트였습니다.
기업 문제 3가지
- 같은 업무라도 사람마다, 계열사마다 구조가 미묘하게 다릅니다. 인사관리를 예로 들면, “저는 이렇게 했는데요?” “아니 저는 이렇게 하는데요?“가 회의마다 반복됩니다.
- PoC 성공을 위한 지표가 없습니다. 기존에 하던 업무에 시간과 비용 측정이 없으니 비교할 기준이 없습니다.
- 있어빌리티가 필요합니다. 기업이 돈을 쓴 만큼 결과에 대한 명확한 지표나 결과물이 있어야 합니다.
문제 1. 일관되지 않은 업무 플로우
동일한 업무를 서로 다르게 처리한다면, 구조화할 수 있는 공통 추상화 과정이 필요합니다. 하나의 워크플로우로 정의하려면 세 가지를 정해야 합니다.
| 질문 | 뜻 |
|---|---|
| What | 어떤 기초 자료와 데이터를 가지고 |
| When | 어느 시점에 |
| How | 어떻게 정리하는지 |
예를 들면 “이메일로 계약서가 오면, 회사 내부 법무팀에 검토를 회신받고, 최종적으로 기안을 올린다”까지 한 줄로 합의하는 일입니다. 사실상 이 과정이 제일 오래 걸렸습니다. n8n 프로젝트였지만 시간의 대부분은 캔버스가 아니라 업무 정의 회의에 들어갔습니다. 대신 그 결과가 n8n 캔버스로 남아, 파편화됐던 업무가 한 장의 그림으로 정리되는 효과가 있었습니다.
문제 2. 성공 지표의 부재
PoC가 성공하기 위한 목표 지표는 무엇인가? 이 질문을 하면 대개 답이 “자동화 성공 야호?” 수준입니다. 워크플로우가 한 번 돌아가면 성공인가요? 그 다음 질문이 반드시 옵니다. “그래서 얼마나 좋아졌는데요?”
해결 2. 없으면 측정하기 (a.k.a. A/B test)
사실상 모든 업무가 기록된, 완전히 디지털화된 대기업은 없을 겁니다. 그러니 없으면 직접 잽니다.
- 정량적 방법: 기존 업무와 개발 후 실제 업무 시간을 측정해 비교
- 정성적 방법: 실제 업무자가 느끼는 n8n 도입 후 경험을 인터뷰
거창한 대시보드가 아닙니다. 스톱워치와 인터뷰 노트면 됩니다. 이 두 가지가 있어야 PoC 보고서에 숫자가 들어갑니다.
문제 3. 회사는 있어빌리티가 필요하다
현장에서는 이 대목에서 짧은 영상 하나를 틀었습니다. 백엔드 개발자가 발표하는 장면인데, 화면에 보이는 게 없으니 청중 반응이 썰렁한 그 짤입니다. 발표장에서 제일 크게 웃음이 났습니다.
회사는 결과물로 얘기합니다. 돈과 시간을 지출했으면 결과가 있어야 합니다. 그런데 n8n의 실행 흐름 그 자체는 보여주기에 부족합니다. 노드가 초록색으로 켜지는 걸 임원 앞에서 시연해 보십시오. 마치 프론트엔드 대 백엔드 비교와 같습니다. 백엔드가 아무리 잘 짜여 있어도 화면이 없으면 “한 게 뭐냐”는 소리를 듣습니다.
해결 3. 프론트 사이트를 Claude로 만들자
여기서 Claude Code를 꺼냈습니다.
- Claude Code로 과업을 반영한 웹사이트(HTML 파일)를 목업 데이터와 함께 만듭니다.
- 회사 내 인원들에게 그 웹페이지를 보여주고, 구성이 맞는지 검토받습니다.
- 검토 결과를 정리해서 다시 Claude Code에 전달합니다.
- n8n과 webhook, HTML(CSS)을 연결합니다.
화면이 생기자 놀라운 일이 벌어졌습니다. 회의에서 말로는 안 나오던 요구사항이 화면을 보자마자 쏟아졌습니다. “여기 버튼은 저기 있어야 하고요”, “이 칸은 우리 팀은 안 써요”. 요구사항 도출 연구에서 말하는 그대로입니다. 이해관계자가 스스로 표현하지 못하는 요구를 프로토타입이 드러냅니다.
교훈 (대기업)
- 업무 플로우를 가시화해야 하는 대기업에게 n8n은 매력적인 선택지입니다 (Explainability).
- 편의성은 떨어져도 사용자의 업무를 녹일 수 있는 훌륭한 스케치보드입니다.
- 그러나 있어빌리티나 사용자 경험(UX)을 위해서는 프론트 웹 개발이 불가피합니다.
이 PoC의 의의는 자동화 그 자체가 아니었습니다. 이 회사는 차세대 시스템으로 넘어가는 과정에 있었고, n8n은 그 중간 단계였습니다. 실무자들이 n8n 워크플로우 화면 하나를 같이 보면서 자기 업무를 정의하고, 그 정의를 시스템 설계로 옮겼습니다. 말로 하면 사람마다 달랐던 업무가 노드로 그려지자 하나의 그림으로 합의됐고, 그 그림이 차세대 시스템의 설계 입력이 됐습니다.
IT 담당자분들께 드리는 말씀은 이겁니다. n8n은 백엔드입니다. 백엔드만으로 프로젝트를 보고하려 하지 마시고, 화면 한 장을 먼저 만드십시오. 그 화면이 요구사항을 끌어냅니다.
사례 3. 1인 사업
도입기
세 번째는 제 이야기입니다. Claude Code를 처음 봤을 때는 무시했습니다. “그냥 코딩 툴 아니야? 써봤자 개발자의 툴이지 뭐.”
생각해보니 우리의 지적노동은 다 컴퓨터로
그러다 깨달았습니다. 우리가 작성하는 회의록(docx), 발표자료(PPT), 리서치(웹 검색), 전부 컴퓨터 위에서 일어납니다. 모든 업무는 코드화할 수 있습니다. 그때부터 모든 업무를 Claude Code로 시작했습니다. 아래는 그렇게 만든 자동화 셋입니다.
활용 사례 1. 회고 시스템
작업 세션마다 무엇을 했는지 Notion Calendar에 자동으로 기록하고, 같은 내용을 Obsidian에도 저장합니다. 비용(토큰)과 주요 결정사항까지 남습니다.
이 기록 파이프라인은 GitHub에 공개해 두었습니다. 설계는 Operations Telemetry 문서에, 세션이 끝날 때 캘린더와 업무일지에 쓰는 Stop hook 스크립트는 claude-worklog에 있습니다. 그대로 받아서 자기 캘린더에 붙일 수 있습니다.
그 기록을 모아 매주 Discord로 회고가 옵니다. 왼쪽은 정성 요약(주요 성과, 공수가 많이 들어간 테마, 다음 주 주목할 것), 오른쪽은 프로젝트별 시간 집계입니다.
월 단위로 토큰, 비용, 프로젝트 분포를 보는 리뷰 형식은 Claude Monthly Review에 익명화한 실제 보고서와 함께 올려 두었습니다.
활용 사례 2. 내 책 순위 수집
매일 아침 YES24, 알라딘, 교보문고에서 『n8n이 다 해줌』 순위를 긁어 Discord로 보내고, 추이 그래프를 그립니다. 제발 100위 안에 있거라 하는 마음으로 만들었습니다.
활용 사례 3. 업무 스케줄 공유
문제: 업무 시간 외에 근무를 하면 아내가 육아로 힘듭니다. 해결: 업무 Google Calendar를 매주 일요일에 요약해서 공유합니다. 육아 커버가 필요한 날과 향후 한 달의 중요 이벤트가 정리돼 옵니다.
Claude Code로의 전환의 장점
- 모든 업무를 자동화할 수 있습니다.
- 세상 모든 기술의 오픈소스를 쓸 수 있습니다.
- 내가 뛰어난 기술자인 것 같습니다.
세 번째가 함정이었습니다.
하나 이상했던 점
클로드가 만능이냐? 처음에는 잘 작동하는 것처럼 보였습니다. 그런데 테스트하고 운영하면서 계속 운영 구조가 깨지고 버그가 났습니다. 그리고 “해줘, 고쳐줘”를 반복하는 제 모습이 있었습니다.
인지 부채, 기술 부채, 의도 부채
AI를 써서 제가 잃어버리고 있던 것들입니다. 위 도식은 AI 시대 소프트웨어 건강을 설명하는 Triple Debt Model입니다. 의도 부채(Intent Debt), 기술 부채(Technical Debt), 인지 부채(Cognitive Debt) 셋이 서로를 증폭시킵니다. 제 경우를 하나씩 말씀드리겠습니다.
기술 부채
- 클로드를 쓰면서부터 기술적 지식의 상승이 정체됐습니다.
- 좋은 프롬프트와 설계는 공학적 지식에서 나오는데, 그 지식이 멈춘 느낌이었습니다.
- 원인 발굴과 문제 해결을 멈추자, 운영 시스템이 지속적으로 고장 나고 있었습니다.
의도 부채
- 제가 원하는 것을 알아서 잘 딱 깔끔하게 센스 있게 해주길 바랐습니다.
- 그런데 업무에는 사람과의 관계, 제가 파악하는 의도, 맥락 정보가 있고, AI는 그것을 행동으로 옮기지 못했습니다.
인지 부채
“해줘”, “만들어줘” 하며 만든 결과물을 제가 정확하게 파악하지 못했습니다. 일단 뭐 잘 해줬겠지 믿었는데, 막상 열어 보면 제대로 만들어져 있지 않았습니다.
책 순위 트래킹이 그 예입니다. Claude에게 “n8n으로 만들어줘”라고 했더니 처음엔 노드 2개짜리 워크플로우가 나왔습니다. 스케줄 트리거 하나에 코드 노드 하나. 그 코드 노드 안에 수집, 파싱, 저장이 전부 들어 있었습니다. 두 달쯤 뒤 서점 하나가 페이지를 바꾸자 통째로 죽었고, 어디서 죽었는지 알 수 없었습니다. 다시 만들어 달라고 하니 이번엔 오른쪽처럼 노드가 잔뜩 늘어난 버전이 나왔습니다. 둘 다 제가 구조를 이해하고 있지 않았다는 점은 같습니다.
1인 기업 교훈
- Claude Code를 쓰면서 생산성이 늘어난 것처럼 느꼈습니다.
- 그런데 운영이 고장 나면 n8n 워크플로우만큼 견고하지 못했습니다.
- 어디서 고장 났는지 관측을 AI에게 맡길 수밖에 없었습니다.
- 종합하면 시간과 비용에서 손해를 보고 있었다는 것을 깨달았습니다.
회사의 지원 없이 혼자 AI를 업무에 넣어야 하는 분들께 이 사례가 가장 가깝게 들릴 겁니다. “해줘”로 시작하는 건 좋습니다. 다만 만들어진 것을 내가 설명할 수 있는지 한 번씩 확인하십시오. 설명 못 하는 자동화는 고장 났을 때 내 것이 아닙니다.
사례별 교훈
| 사례 | 교훈 |
|---|---|
| 병원 | n8n은 비개발자에게 좋은 툴입니다. 하지만 적정 설계와 운영 단계는 또 다른 Stage입니다 |
| 대기업 | n8n은 흩어진 업무 플로우가 하나로 모아지는 과정 자체에 의미가 있습니다 |
| 1인 기업 | Agentic Coding 툴이 있어도 기술, 의도, 인지 부채를 극복하지 못하면 좋은 운영은 어렵습니다 |
위 3가지 사례를 겪은 저의 결론
어떤 워크플로우를 n8n에 적용하면 좋을까?
Observability가 필요한 워크플로우를 적용합니다.
위 화면은 제 지출 적재 워크플로우의 실행 목록입니다. 15분마다 돌고, 각 실행이 몇 초 걸렸고 성공했는지 왼쪽에 쌓입니다. 하나를 누르면 어느 노드에서 무엇이 오갔는지 보입니다. Claude Code로 만든 스크립트에는 이게 없습니다. 고장 나면 로그를 뒤지거나, 다시 AI에게 물어봐야 합니다.
연동과 스케줄이 있고, 이력이 남아야 하고, 사람이 나중에 “왜 이랬지”를 물어볼 처리라면 n8n 안에 둡니다. 화면이 필요하면 n8n 밖, 코드로 갑니다. 기준이 없고 관리 주체도 없는 일은 자동화 이전에 조직이 먼저 정합니다.
어떻게 n8n을 제작하면 좋을까?
n8n 특유의 단일책임원칙(SRP)을 지키며 설계합니다.
왼쪽이 나쁜 예입니다. 노드 2개, 코드 노드 하나에 모든 일이 들어 있습니다. 오른쪽이 좋은 예입니다. 환경 설정, 수집, 매핑, LLM 판정, 검증, 적재가 노드 하나에 하나씩 나뉘어 있습니다. 노드가 많아서 좋은 게 아닙니다. 하나의 노드가 하나의 일만 하기 때문에, 고장 나면 어느 노드인지 바로 보이고 그 노드만 고치면 됩니다. Claude에게 n8n을 만들게 할 때도 이 원칙을 명시하지 않으면 왼쪽 결과가 나옵니다.
향후 어떤 공부를 하면 좋을까?
Agentic 시대에는 유즈케이스보다 추상화된 지식을 다루는 책을 더 봅니다. “n8n으로 이메일 자동화하기” 같은 유즈케이스는 AI가 다 만들어 줍니다. 대신 AI가 만든 것이 맞는 구조인지 판단하는 눈은 소프트웨어 아키텍처 같은 원칙에서 나옵니다. 제가 최근에 다시 읽은 책은 『Fundamentals of Software Architecture』입니다.
독자별로 가져갈 것
| 독자 | 먼저 할 일 |
|---|---|
| AX를 준비하는 인사 담당자 | 툴 선정보다 “운영 담당자”를 조직도에 먼저 그립니다. 결재선처럼 표로만 있는 규칙을 정의서로 바꾸는 일이 AI 도입의 첫 과제입니다 |
| IT 담당자 | n8n은 백엔드입니다. PoC 보고 전에 화면 한 장(HTML 목업)을 먼저 만들고, 그 화면으로 요구사항을 받습니다. 성공 지표는 도입 전후 업무 시간 측정과 인터뷰로 직접 잽니다 |
| 회사 지원 없이 AI를 써야 하는 직장인 | “해줘”로 시작하되, 만들어진 것을 내가 설명할 수 있는지 확인합니다. 이력이 남아야 하는 자동화는 n8n에, 노드 하나에 일 하나로 둡니다 |
Q&A
발표 후 질문은 LinkedIn in/jayjunglim으로 받았습니다. 이 글에 대한 질문도 같은 곳으로 주시면 됩니다.
댓글