무엇이든지 질문하세요 (Q&A)
튜토리얼 & 학습 자료
워크플로우 템플릿 공유
자유 게시판
Subscribe

Iterations, hallucinations, and lessons learned: Rebuilding our AI Assistant on n8n

아무튼네이튼
우리가 만든 도구를 직접 사용하다 (Drinking our own champagne)
n8n에서는 사내 AI 어시스턴트를 재구축할 때, 우리의 워크플로 솔루션만으로 이를 완성할 수 있을지 도전해 보기로 했습니다. 명령줄에서 작업하던 기존 방식에서 벗어나, 워크플로를 통해 직접 구축해 보는 것은 개발자로서 꽤 흥미로운 일이었습니다. 몇 달간의 작업 끝에 성공적으로 만들어냈고, 그 과정에서 배운 값진 교훈들을 공유하고자 합니다. 혹시 AI 툴을 구축하시려는 분들이라면 저희 경험이 도움이 되길 바랍니다.

하드코딩, 그리고 반복의 어려움

사실 우리는 이미 사내용으로 하드코딩된 AI 어시스턴트를 운영 중이었습니다. 하지만 이건 반복(Iterate) 과정이 너무 까다로웠고, 프로젝트 매니저(PM) 동료들이 AI 로직을 조금이라도 수정하거나 개선하려면 매우 높은 진입 장벽을 마주해야 했습니다. 프롬프트를 살짝 수정하거나 효율성을 높이고 싶어도, 결국 코드를 깊이 파고들어야 했죠. 엔지니어링 퀄리티 자체는 나쁘지 않았지만, AI 어시스턴트를 가장 필요로 하는 사람들에게는 너무나도 접근성이 떨어졌습니다.
우리는 기존 어시스턴트에 사용했던 기술 스택을 좋아했기 때문에, LangChain으로 오케스트레이션을 유지하고 GPT-4를 메인으로 활용하는 방향은 고수하기로 했습니다. 하지만 동시에 “과연 n8n만으로 이처럼 복잡한 AI 사용 사례를 전부 구현할 수 있을까?”를 테스트해보고 싶었고, 결국 워크플로만으로 대규모 AI 어시스턴트를 구축하는 데 도전하게 되었습니다.

AI 어시스턴트

n8n의 AI 어시스턴트는 크게 다음 세 가지 용도로 운영됩니다:
1.
사용자 에러 디버깅
2.
자연어 기반 채팅 질문 응답
3.
사용자 자격 증명(Credentials) 설정 지원
백엔드에는 두 개의 대규모 벡터 소스가 내부 지식 베이스(KB)를 구성하고 있습니다. 하나는 n8n의 문서(Documentation)이고, 다른 하나는 n8n 포럼(Forum)입니다. 어시스턴트가 우선 문서를 먼저 살펴보도록 하여 ‘환각(Hallucination)’을 줄이고, 그 후 포럼으로부터 추가 정보를 얻도록 했습니다.
데이터는 ‘청크(Chunk)’ 단위로 쪼개서 저장하며, 각 청크에는 자신이 어떤 문서의 어느 부분인지, 그리고 주변 맥락이 무엇인지에 대한 정보가 담깁니다. 당연히 n8n 워크플로를 통해 주 3회씩 문서를 스크레이핑하여 DB를 업데이트하고, 동시에 포럼에서 ‘질문-답변’ 쌍을 찾아 KB에 함께 저장하도록 자동화했습니다. 말 그대로 우리가 만든 도구(n8n)를 적극적으로 활용한 셈이죠.
또한 AI Service와 워크플로가 호스팅되는 내부 인스턴스 모두에 개발 환경과 프로덕션 환경을 따로 두어, 바로 프로덕션 버전을 건드리지 않고도 자유롭게 실험할 수 있게 했습니다.

어시스턴트 주요 구성 요소 개요

1.
n8n 프론트엔드
사용자가 어시스턴트 채팅 사이드바에서 메시지를 보내면, 내부적으로 호스팅하는 AI Service로 먼저 전송됩니다.
2.
AI Service
들어오는 요청에 대한 인증을 처리하고, 검증된 요청만 n8n 웹훅으로 전달합니다. 여기서도 인증 과정을 거쳐, 오직 AI Service에서 오는 요청만 워크플로가 받아들일 수 있도록 합니다.
3.
어시스턴트 워크플로
내부 인스턴스에 호스팅되어 있습니다. 하나의 메인(게이트웨이) 워크플로가 웹훅 요청을 받아, 사용자 모드에 따라 적절한 에이전트로 라우팅합니다.
이렇게 내부적으로는 4개의 독립된 에이전트가 서로 다른 AI 사용 사례를 처리합니다. 각 사용 사례별로 요구되는 입력 맥락과 기능이 다르기 때문에 에이전트를 나눈 것이죠. 사용자가 어시스턴트를 켜면, n8n의 Switch 노드로 요청을 받아 4개 중 하나의 에이전트로 분기합니다. 다만 한 가지 단점은, 에이전트가 일단 대화를 시작하면, 그 세션 안에서는 다른 에이전트로 전환할 수 없다는 점입니다. 즉, 사용자가 다른 에이전트의 도움을 받으려면 새로운 세션을 시작해야 합니다.

디버깅 에이전트

1.
일반 에러 헬퍼(Generic error helper)
Node 실행 결과 패널에서 “Ask Assistant” 버튼을 눌러 에러 상황일 때 호출됩니다. 노드 에러를 디버깅하는 데 특화되어 있으며, 에러 정보를 알고 있고, n8n 문서와 포럼 데이터를 활용합니다.
2.
코드 노드 에러 헬퍼(Code node error helper)
코드 노드에서 에러가 발생했을 때, 동일한 방식으로 “Ask Assistant”를 누르면 동작하는 에이전트입니다. 사용자 코드에 대한 맥락을 알고 있고, n8n 문서에도 접근할 수 있습니다. 단순히 답변을 제공하는 것뿐 아니라, 코드를 수정해 제안하고 사용자가 원하면 즉시 해당 노드에 코드를 적용할 수도 있습니다.

자연어 기반 채팅 Q&A 에이전트

지원 에이전트(Support agent)
단순히 사용자가 채팅창을 열고 질문을 던질 때 동작합니다. 사용자가 보고 있는 워크플로나 노드에 대한 정보를 참조할 수 있고, n8n 문서와 포럼 데이터를 검색해 답을 제공합니다.

자격 증명 설정 지원 에이전트

자격 증명 헬퍼(Credentials helper)
자격 증명 설정 창에서 “Ask Assistant” 버튼을 누르면 호출됩니다. 사용자 노드와 설정하려는 자격 증명에 대한 맥락을 알고 있으며, n8n 문서를 검색할 수 있습니다.

구현 (Implementation)

AI를 다루면서 가장 까다로운 점은, 모델이 내놓는 답변이 전혀 예측 불가능할 수 있다는 것입니다. 같은 질문을 약간만 다르게 묻거나, 프롬프트에 숫자만 살짝 바꿔도 완전히 다른 답이 나올 수 있죠.
이를 최소화하기 위해, 처음에는 매우 단순한 예시(“이게 왜 뜨는 거야?” 정도의 질문)에 특화된 에이전트를 만들며 시작했습니다. 곧, 어시스턴트가 사용자 화면에 보이는 정보를 자동으로 인지하진 않는다는 사실을 깨달았습니다. 그래서 AI가 KB를 검색하기 전에 먼저 사용자 워크플로 정보 같은 맥락을 읽을 수 있도록, “workflow info”라는 별도의 툴(도구)을 만들어주었습니다.
이제 사용자가 “왜 이 워크플로에서 이런 에러가 나오는 거죠?”처럼 구체적 정보를 제시하지 않더라도, 어시스턴트가 “workflow info” 툴을 활용해 현재 열려 있는 워크플로나 오류 메시지를 자체적으로 조회합니다. 현재는 사용자가 화면에서 보는 스키마 정보를 AI가 읽고, 이를 검색 맥락으로 사용함으로써 보다 정확한 답을 제공할 수 있습니다. 아래 예시처럼, 에이전트가 문제를 디버깅하기 위해 여러 툴을 활용하는 과정을 확인할 수 있습니다.

AI로 AI를 평가하기

우리는 모든 실행 결과를 n8n 안에 저장하기 때문에, 내부적으로 방대한 트레이스 로그를 갖추고 있습니다. 여기엔 AI가 어떤 프롬프트에 어떻게 답변했는지에 대한 정보도 포함되어 있죠. “그렇다면 왜 이걸 이용해 AI 답변 품질을 평가하지 않을까?”라는 생각이 들어, LLM을 활용해 우리 LLM(어시스턴트)의 답변을 심사(Judge)하는 실험을 진행했습니다.
하지만 처음엔 어시스턴트와 심사자(Judge) 모두에게 “답변을 간결하고 유용하게 작성하라” 같은 동일한 지침을 주는 실수를 저질렀습니다. 그러자 심사자가 모든 답변에 만점을 줘버렸죠. 결국 이 부분을 좀 더 구체적으로 다듬어야 했습니다.
지금은 LangSmith에서 자체적으로 커스텀 검증 프로젝트를 운영하며, 샘플 요청에 대해 어시스턴트 답변을 생성한 뒤, 심사 LLM이 해당 답변을 평가해 점수를 매기는 방식을 취하고 있습니다. 이렇게 하면 다른 프롬프트나 모델을 실험할 때, 여러 테스트 케이스에 대해 더 빠르게 품질을 확인할 수 있죠. 물론 제대로 된 평가 프레임워크를 만들기까지 많은 시행착오가 있었고, 지금도 새로운 변경사항이 생길 때마다 항상 재시험을 거쳐야 합니다. 현재는 거의 50개 정도의 시나리오를 가지고, 변경할 때마다 이 프레임워크로 확인해봅니다.
결과적으로, 지금의 심사 LLM은 사용자 프롬프트와 어시스턴트 답변을 함께 입력받은 뒤, “이 답변에 X가 포함되어야 하는지, 이 항목은 우선순위가 높은지, 이 답변이 실행 가능(Actionable)한지” 등의 평가 기준에 따라 점수를 매깁니다. 현재는 이렇게 평가 과정을 도입한 덕분에, 이전 모델보다 응답 품질이 한결 더 좋아졌습니다.

배운 점

1. 다소 느려도 괜찮다(Time lag is ok)

우리는 처음에 “응답이 몇 초씩 늦어지면 사용자가 불편해하지 않을까?”라고 걱정했지만, 실제로는 조금 기다리더라도 유용한 답변만 받으면 크게 개의치 않는다는 사실을 알게 됐습니다. 실제로 10초 정도 걸려도 사용성에 큰 문제는 없었고, 에러 해결률 또한 크게 떨어지지 않았습니다.

2. 반복, 또 반복 (Iterate, iterate, iterate!)

엔지니어로서 코드를 다룰 때는, 어디를 어떻게 수정하면 어떤 변화가 생길지 직감적으로 파악하기가 비교적 쉽습니다. 하지만 AI에서는 같은 질문도 조금만 바꿔도 결과가 달라지고, 한 프롬프트를 조금 고쳤더니 특정 사례는 더 나아지지만 다른 여러 사례가 오히려 악화되는 상황이 발생하기도 합니다.
즉, AI는 훨씬 덜 결정론적(deterministic)이며, 제대로 동작하도록 만들려면 다른 접근법이 필요합니다. 저희는 매 순간 시행착오를 거치며, 프롬프트부터 시스템 구조까지 전부 실험하고 개선했습니다. 그만큼 시간이 들긴 했지만, 덕분에 지금은 높은 품질의 응답을 안정적으로 제공할 수 있고, 응답 속도 역시 점차 개선되고 있습니다.

3. 코드 이외에도 마음을 열어라 (Be open beyond code)

우리는 엔지니어이기 때문에, 코드 중심으로 일하는 데 익숙했습니다. 그러나 워크플로 기반으로 AI 프로젝트를 진행하며, 로우코드(Low-code) 접근의 장점을 제대로 체험하게 됐습니다. 처음엔 “정말 워크플로만으로 가능할까?”라며 반신반의했지만, 생각보다 훨씬 간단하게 대규모 AI 어시스턴트를 구축하고 이전(마이그레이션) 할 수 있었습니다. 결과물 역시 놀라울 정도로 잘 작동했고요.

다음 단계 (What’s next?)

우리의 새로운 AI 어시스턴트는 소문이 금세 퍼져, n8n 지원팀도 KB와 AI 워크플로를 적극 활용해 고객 응답 품질과 속도를 개선하고 있습니다.
이제 우리는 어시스턴트 기능을 더욱 확장해, 예를 들어 “프롬프트만으로 워크플로를 자동 생성”하는 기능도 가능할지 고민 중입니다. 또한 워크플로로 모든 것이 구성되어 있기 때문에, 부수적 업무(토큰 카운트, 일부 요약 작업 등)에 다른 LLM을 접목하는 실험도 용이합니다. 그리고 현재의 4개 에이전트 이외에 또 다른 AI 에이전트를 추가하여, 사용자가 세션 도중에도 다른 에이전트로 전환할 수 있게 하는 방안도 검토하고 있습니다.

직접 시도해보기 (Give it a spin)

우리는 오픈소스를 사랑합니다! 그래서 AI 어시스턴트 워크플로를 공개해두었죠. 아래 인기 템플릿 몇 가지를 소개하니, 관심 있으시면 살펴보시고 의견을 알려주세요.
RAG Chatbot for Company Documents using Google Drive and Gemini
→ 이 워크플로는 사내에 저장된 문서를 기반으로 직원들의 질문에 자동 답변해 주는 Retrieval Augmented Generation(RAG) 챗봇을 구현합니다.
BambooHR AI-Powered Company Policies and Benefits Chatbot
→ 이 워크플로는 회사 정책 및 복지 혜택에 대한 질문에 빠르게 답변해주는 HR 전용 챗봇을 제공합니다.
또 궁금한 점이 있으시면 Niklas나 Milorad의 LinkedIn을 통해 직접 질문하실 수도 있습니다!
n8nkorea
Subscribe to 'n8nkorea'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'n8nkorea'!
Subscribe
👍