1. 개요
RAG(Retrieval-Augmented Generation) 기반 AI 시스템인 Lakey를 개발하면서 가장 먼저 고민했던 부분은 “LLM의 답변을 얼마나 신뢰할 수 있는가”였습니다.
초기 개발 단계에서는 단순히 문서를 검색하고 LLM이 답변을 생성하도록 구성하였습니다.
하지만 실제 테스트를 진행해보니 몇 가지 문제가 발생하기 시작했습니다.
가장 대표적인 문제는 Hallucination 현상이었습니다. LLM은 실제 문서에 존재하지 않는 정보를 자연스럽게 생성하거나, 일부 내용을 과장해서 표현하는 경우가 있었습니다.
특히 실제 업무 환경에서는 잘못된 답변이 단순 사용자 경험 문제로 끝나지 않습니다.
의사결정 과정에 영향을 줄 수 있고, 잘못된 업무 처리로 이어질 가능성도 존재했습니다.
예를 들어 내부 정책 문서를 기반으로 답변을 생성하는 경우, 존재하지 않는 정책 내용을 답변하거나 과거 정책 정보를 최신 정보처럼 설명하는 문제가 발생할 수 있었습니다.
이러한 이유로 프로젝트에서는 단순히 “답변 생성”만 수행하는 것이 아니라, 생성된 답변을 별도로 검증하는 Verifier 레이어를 추가하기로 결정하였습니다.
즉, LLM이 생성한 결과를 다시 한번 검증하고, 신뢰도가 낮거나 잘못된 응답은 필터링할 수 있는 구조를 설계한 것입니다.
프로젝트에서는 AI Agent 및 Workflow 자동화 도구인 n8n을 활용해 해당 구조를 구현하였습니다.
이번 글에서는 단순히 “어떻게 구현했는가”보다 왜 n8n을 선택했는지, 실제 운영 환경에서 느꼈던 장단점은 무엇이었는지 중심으로 정리해보려고 합니다.
2. 전체 아키텍처 구성
Verifier 시스템은 크게 다음과 같은 흐름으로 구성되었습니다.
- Lakey AI 시스템
- Kafka 기반 이벤트 전달
- n8n Workflow
- 검증용 Sub Workflow
- Error Workflow
- 결과 반환 구조
Lakey 시스템에서 답변 검증이 필요할 경우 Kafka를 통해 검증 요청 이벤트를 발행합니다.
이 이벤트에는 다음과 같은 정보가 포함됩니다.
- 사용자 질문
- 검색된 Context 문서
- LLM 생성 답변
- 요청 식별자
- 검증 메타데이터
n8n에서는 Kafka Consumer Workflow가 해당 이벤트를 수신하고, 실제 검증 로직을 수행하는 Sub Workflow를 호출하도록 구성하였습니다.
검증 로직은 독립적인 Sub Workflow 형태로 분리하였습니다.
이 구조를 선택한 이유는 검증 기준이 지속적으로 변경될 가능성이 높았기 때문입니다.
예를 들어 다음과 같은 검증 로직이 존재할 수 있었습니다.
- 답변이 Context 기반인지 검증
- 특정 키워드 포함 여부 확인
- 금지 문구 탐지
- 정책 위반 여부 검증
- 신뢰도 점수 계산
- JSON 형식 검증
이러한 검증 흐름을 각각 별도의 노드와 Sub Workflow로 분리함으로써 유지보수성을 높일 수 있었습니다.
또한 Error Workflow도 별도로 구성하였습니다.
LLM 호출 실패, Kafka 연결 오류, Timeout, JSON 파싱(Parsing) 오류 등 다양한 예외 상황이 발생할 수 있었기 때문입니다.
n8n은 Workflow 단위로 에러 핸들링 구성이 가능하기 때문에, 장애 발생 시 별도의 Error Workflow로 이동하여 로그를 남기고 알림을 전송하도록 구성하였습니다.
최종적으로 검증이 완료되면 결과를 다시 Kafka 이벤트 형태로 발행하고, Lakey 시스템이 이를 소비하도록 구성하였습니다.
즉, 전체 구조는 Event-Driven Architecture 기반으로 설계되었습니다.
3. 왜 n8n을 선택했는가
프로젝트 초기에는 Python 기반으로 직접 AI Workflow를 구현하는 방식도 검토하였습니다.
예를 들어 FastAPI 기반으로 API 서버를 만들고, 내부에서 LangChain 또는 직접 작성한 Python 로직으로 검증 흐름을 처리하는 방식이었습니다.
하지만 실제로는 프롬프트(Prompt)와 검증 기준이 매우 자주 변경되었습니다.
특히 운영 과정에서는 다음과 같은 요청이 반복적으로 발생했습니다.
- 프롬프트(Prompt) 수정
- 검증 단계 추가
- 특정 조건 예외 처리
- 로그 확인
- 응답 포맷 변경
- Workflow 순서 변경
만약 이를 모두 코드 기반으로 관리한다면 매번 다음 과정을 반복해야 했습니다.
- 코드 수정
- 빌드
- 배포
- 서버 재시작
- 테스트
반면 n8n은 Workflow 기반 구조이기 때문에 UI 상에서 노드를 수정하고 바로 반영할 수 있었습니다.
이 점이 매우 큰 장점으로 느껴졌습니다.
특히 AI Agent 기반 시스템은 아직 요구사항이 빠르게 바뀌는 경우가 많습니다. 따라서 빠른 반복 개발과 실험이 매우 중요합니다.
n8n은 이러한 요구사항에 매우 잘 맞는 도구였습니다. 또한 n8n은 다양한 외부 시스템과 연결이 매우 쉽습니다.
Kafka, HTTP API, Slack, Redis, Database, Webhook 등 수많은 노드가 기본 제공되기 때문에 별도의 Connector 코드를 직접 작성할 필요가 거의 없었습니다.
실제 프로젝트에서도 Kafka 이벤트 수신 및 발행을 매우 빠르게 구성할 수 있었습니다.
Workflow를 시각적으로 표현할 수 있다는 점도 장점이었습니다.
복잡한 AI 처리 흐름을 노드 단위로 표현할 수 있기 때문에 운영자나 다른 개발자도 전체 흐름을 쉽게 이해할 수 있었습니다.
특히 AI Workflow는 단순 코드보다 흐름 자체를 이해하는 것이 중요하기 때문에 시각화 효과가 매우 컸습니다.
결과적으로 프로젝트에서는 “빠른 반복 개발”과 “운영 편의성” 때문에 n8n을 선택하게 되었습니다.
4. 실제 운영에서 느낀 장점
실제 운영 과정에서 가장 크게 체감했던 장점은 디버깅과 로그 추적 기능이었습니다.
기존 코드 기반 Workflow에서는 특정 단계에서 어떤 데이터가 생성되었는지 확인하기 어려운 경우가 많았습니다.
반면 n8n에서는 각 노드별 입력 데이터와 출력 데이터를 모두 확인할 수 있었습니다.
즉, Workflow 실행 과정 전체를 단계별로 추적할 수 있었습니다.
예를 들어 다음과 같은 상황에서 매우 유용했습니다.
- 특정 프롬프트(Prompt) 결과 확인
- LLM 응답 데이터 검증
- JSON Parsing 실패 원인 분석
- Kafka 메시지 확인
- 조건 분기 결과 확인
- 특정 노드 Timeout 분석
특히 AI 시스템에서는 결과가 항상 동일하지 않기 때문에 중간 데이터를 확인할 수 있는 기능이 매우 중요했습니다. 실제 운영 환경에서도 문제 발생 시 대부분 n8n 실행 로그만으로 원인을 빠르게 파악할 수 있었습니다.
또한 코드 최소화 구조 역시 장점이었습니다.
기존 방식이라면 Kafka Consumer, HTTP Client, Retry Logic, Error Handling 등을 모두 코드로 작성해야 했습니다.
하지만 n8n에서는 대부분 노드 설정만으로 구현이 가능했습니다. 덕분에 개발 속도가 매우 빨라졌고, 비즈니스 로직 자체에 더 집중할 수 있었습니다.
추가적으로 Workflow 재사용성도 좋았습니다.
예를 들어 특정 검증 로직을 Sub Workflow 형태로 분리해두면 여러 Workflow에서 재사용할 수 있었습니다.
이는 프롬프트(Prompt) 기반 AI Workflow 환경에서 상당히 유용했습니다.
운영 측면에서도 큰 장점이 있었습니다. Workflow 수정 이후 즉시 반영이 가능했기 때문에 긴급 대응 속도가 매우 빨랐습니다.
특히 프롬프트(Prompt) 수정만 필요한 경우에는 별도 배포 없이 즉시 수정 가능하다는 점이 매우 편리했습니다.
5. 개발 과정에서 느낀 단점
물론 n8n이 모든 상황에서 완벽한 도구는 아니었습니다. 실제 프로젝트를 진행하면서 여러 단점도 함께 경험할 수 있었습니다.
가장 먼저 느낀 단점은 버전 관리의 어려움이었습니다.
n8n 역시 변경 이력을 저장할 수는 있지만, Java 코드처럼 Git Diff 기반으로 변경 사항을 직관적으로 비교하기는 어려웠습니다.
특히 Workflow 구조가 복잡해질수록 어떤 노드 설정이 변경되었는지 일일이 직접 확인해야 했습니다.
두 번째는 복잡한 Workflow에서 발생하는 가독성 문제였습니다.
처음에는 노드 기반 구조가 매우 직관적으로 느껴졌지만, Workflow 크기가 커질수록 오히려 화면이 복잡해지기 시작했습니다. 특히 조건 분기와 반복 로직이 많아질 경우 연결선 자체가 복잡하게 얽히는 문제가 있었습니다.
세 번째는 테스트 자동화의 부재였습니다.
일반 코드 기반 환경에서는 JUnit 같은 테스트 프레임워크를 활용해 자동화 테스트를 구성할 수 있습니다. 하지만 n8n은 기본적으로 Workflow 중심 도구이기 때문에 코드 수준 테스트 자동화가 쉽지 않았습니다.
결과적으로 대부분 수동 테스트에 의존해야 했습니다. 이는 운영 규모가 커질수록 부담이 될 수 있었습니다.
또 다른 문제는 대규모 리팩토링의 어려움이었습니다.
예를 들어 특정 변수명이나 노드 이름을 변경할 경우 IDE Refactoring 기능처럼 자동으로 전체 변경이 수행되지 않았습니다.
즉, 연결된 노드들을 직접 찾아가며 수정해야 했습니다. Workflow 규모가 커질수록 이러한 작업은 상당히 번거롭게 느껴졌습니다.
결국 n8n은 “빠른 개발”에는 매우 강력하지만, 매우 복잡한 대규모 시스템에서는 일정 수준 이상의 운영 복잡도가 발생할 수 있다는 점도 함께 경험할 수 있었습니다.
6. 마무리
이번 프로젝트를 통해 n8n은 단순 자동화 도구를 넘어 AI Workflow 플랫폼으로도 충분한 가능성을 가지고 있다는 점을 확인할 수 있었습니다.
특히 AI 시스템은 요구사항이 매우 빠르게 변합니다.
프롬프트(Prompt) 하나만 변경해도 결과 품질이 달라질 수 있고, 검증 기준 역시 지속적으로 수정되는 경우가 많습니다.
이러한 환경에서는 빠른 수정과 즉각적인 반영이 매우 중요합니다.
n8n은 이러한 요구사항에 매우 잘 맞는 구조를 제공하였습니다.
특히 다음과 같은 상황에서는 매우 큰 장점을 가진다고 느꼈습니다.
- 반복적인 프롬프트(Prompt) 수정
- 빠른 실험 환경 구축
- 다양한 시스템 연동
- 이벤트 기반 Workflow 구성
- AI Agent 흐름 시각화
- 운영 로그 추적
물론 복잡도가 지나치게 높아질 경우 코드 기반 구조보다 유지보수가 어려워질 수도 있습니다.하지만 빠른 반복 개발과 운영 자동화가 중요한 프로젝트라면 n8n은 매우 강력한 선택지가 될 수 있다고 생각합니다.
이번 경험을 통해 AI 시스템에서는 단순 모델 성능만 중요한 것이 아니라, 운영 구조와 검증 체계 역시 매우 중요하다는 점을 다시 한번 체감할 수 있었습니다.
특히 Verifier 레이어는 앞으로 AI 시스템에서 점점 더 중요한 역할을 하게 될 것으로 생각합니다.
향후에도 유사한 AI Workflow 프로젝트가 있다면 n8n을 다시 활용할 가능성이 높을 정도로 만족도가 높았던 경험이었습니다.
sby