On this page
AI 에이전트와 작업하다 보면 계속 켜 두고 사용할 서버가 필요해집니다. 외부에서 데이터를 받아 쌓거나, 정해진 시간에 작업을 실행하거나, 진행 상황을 확인해 알려주는 일들입니다.
저는 이런 작업을 실행하는 기반으로 n8n을 사용하고 있습니다. 노드를 연결하고 JavaScript로 필요한 로직을 작성할 수 있으니, 상시 동작하는 작은 애플리케이션을 만드는 데도 쓸 수 있겠다는 생각이었습니다.
다만 워크플로우를 작성하고 운영하는 방식은 조금 다르게 구성했습니다. 제가 n8n 화면에서 노드를 하나씩 연결하는 대신, AI 에이전트가 작업을 만들고 배포한 뒤 동작을 확인하는 과정까지 맡도록 했습니다.
AI가 작업할 수 있는 형태
n8n의 시각적 편집기는 흐름을 살펴보기에 좋습니다. 하지만 노드 안의 코드를 수정하고, 여러 워크플로우의 변경 사항을 관리하는 일까지 화면 안에서 해결하려면 불편한 점이 있었습니다.
그래서 실행 로직은 일반 JavaScript 파일로, 노드와 연결 구조는 JSON 템플릿으로 분리했습니다. 실행 환경마다 달라지는 설정도 따로 관리합니다. 빌드 과정에서 이들을 조합해 n8n이 실행할 워크플로우를 만듭니다.
이렇게 구성하면 에이전트는 평소 코드를 작업하듯 파일을 읽고 수정할 수 있습니다. 변경 내용은 Git에 남고, 이전과 무엇이 달라졌는지도 비교할 수 있습니다. 로직뿐 아니라 필요한 노드와 연결 구조도 에이전트가 다룹니다.
소스 파일을 정본으로 삼았기 때문에, 에이전트가 만든 코드를 제가 화면에서 노드마다 복사해 넣는 과정도 필요하지 않습니다.
작성에서 배포와 진단까지
작업 흐름은 일반적인 애플리케이션 개발과 비슷합니다. 원하는 작업을 에이전트와 논의하고, 에이전트가 소스를 수정해 GitHub에 푸시합니다. 그러면 n8n에 구성해 둔 배포 흐름이 변경을 받아 실행 환경에 반영합니다.
워크플로우를 조합하는 과정에는 JavaScript 구문 검사도 넣었습니다. 물론 구문이 맞는다고 원하는 대로 동작한다는 뜻은 아닙니다. 배포 후 확인도 필요합니다.
n8n은 API를 제공하므로 에이전트가 원격으로 상태를 확인하고 제어할 수 있습니다. API만으로 상황을 파악하기 어렵다면 서버 관리 에이전트에게 확인을 요청하거나, SSH로 접속해 로그와 실행 환경을 살펴봅니다. 여기서 작업하고 원인을 찾는 주체도 저 대신 AI 에이전트입니다.
저는 무엇을 자동화하고 싶은지 설명하고 결과를 봅니다. 워크플로우 작성부터 배포, 동작 확인과 문제 진단까지 이어질 수 있도록 주변 환경을 갖춘 셈입니다.
이 그림의 확인과 진단은 에이전트가 수행하는 작업입니다. 문제가 생길 때마다 무조건 자동 재시도하는 흐름을 뜻하지는 않습니다.
실제로 맡긴 작업들
Mac mini 서버(루나)에서 n8n을 상시 운영하고 있습니다. 블로샤퍼에서는 비컨 수집과 빌드 파이프라인 모니터링·알림에 사용합니다.
오래 돌아가는 테스트의 신호를 받아 두고, 빌드 진행 상황을 확인해 알림을 보내는 일입니다. 제가 계속 화면을 지켜보고 있지 않아도 기록이 쌓이고, 확인할 일이 생기면 알 수 있도록 구성했습니다.
별도의 실험에 활용한 적도 있습니다. 블로샤퍼를 개발하다가 슬럼프가 와서 잠시 진행했던 DantAI라는 프로젝트입니다. 당시 반도체와 삼성전자 주가 이야기를 자주 접하면서 저도 자연스럽게 관심이 생겼고, AI를 이용한 주식 자동투자의 가능성을 검토해 봤습니다.
DantAI에는 과거 데이터로 가상 매매를 재현하는 웹 백테스터가 있습니다. n8n 쪽에서는 데이터를 수집하고 작업 흐름을 실행하며, 양쪽이 같은 판단 로직을 사용하도록 구성했습니다. 지금은 손을 놓고 있지만, n8n을 애플리케이션의 실행 기반으로 활용해 본 사례입니다. 여기서 이야기하려는 것은 투자 수익이 아니라, 그런 실험을 실행할 환경을 만들었다는 점입니다.
운영하면서 함께 고친 것들
처음부터 매끄럽게 돌아가지는 않았습니다. 웹훅을 등록하고 응답을 돌려주는 방식부터 예상과 다른 부분이 있었습니다. 작업을 받을 머신이 꺼져 있다면 깨워서 준비될 때까지 기다려야 했고, 그동안 요청을 붙잡아 둘지 먼저 응답할지도 정해야 했습니다.
자동 배포를 붙이는 과정에서는 서비스가 재시작을 반복하거나 권한 문제로 멈추기도 했습니다. 머신 사이의 호출에는 실패와 타임아웃 처리가 필요했습니다. 다른 머신에서 작업을 이어가려니, 앞서 왜 그렇게 구성했는지에 대한 맥락이 없어 문서를 보강한 일도 있었습니다.
에이전트가 작업할 수 있게 만드는 과정에도 이런 운영 문제가 따라왔습니다. 문제가 생기면 함께 원인을 찾고, 수정한 내용을 소스와 문서에 남겼습니다. 한 번 돌아가는 워크플로우를 만드는 것과 다음에도 수정하고 운영할 수 있는 상태로 유지하는 것은 다른 일이었습니다.
자동화를 만드는 작업 환경
이 구성에서 제가 중요하게 생각하는 부분은 n8n 화면을 얼마나 적게 클릭하느냐보다, 에이전트가 작업을 이어갈 수 있느냐입니다.
코드를 고칠 수 있어도 배포는 제가 해야 하고, 문제가 생겨도 제가 로그를 가져다줘야 한다면 매번 제 손을 기다리게 됩니다. 작성할 수 있는 소스, 배포 절차, 상태를 확인할 API, 원인을 찾을 수 있는 접근 수단이 함께 있어야 했습니다.
AI에게 일을 맡기는 범위가 넓어지면서, 제가 고민하는 대상도 바뀌었습니다. 어떤 작업을 시킬지뿐 아니라 그 작업을 끝까지 수행하려면 어떤 환경이 필요한지 생각하게 됐습니다.
이 서버의 n8n은 그렇게 만든 작업 환경 중 하나입니다. 필요한 자동화를 에이전트와 이야기하고, 에이전트가 만들고 운영할 수 있는 곳으로 사용하고 있습니다.