AI 에이전트, 감으로 만들지 마세요! n8n Evaluation으로 숫자로 검증하고 개선하기
1. AI 에이전트 평가의 필요성
AI 에이전트를 제작한 후 그 퀄리티가 실제로 괜찮은지, 프롬프트가 최선인지, 다른 모델로 바꾸면 더 나아질지에 대한 의문은 항상 존재한다. 개인 프로젝트라면 큰 문제가 없을 수 있지만, 실무에서 AI 에이전트를 활용하려면 **정량적 평가(Quantitative Evaluation)**와 **지속적 개선(Continuous Improvement)**이 필수적이다.
n8n을 활용하여 AI 시스템을 구축하다 보면 다양한 선택지 앞에서 고민하게 된다. 시스템 프롬프트가 최선인지, 현재 AI 모델이 가장 적합한지, RAG 시스템의 청킹 사이즈(Chunking Size)는 몇으로 설정하는 것이 최적인지 등의 질문이 끊임없이 발생한다. 이러한 선택을 “감”에 의존하게 되면 세 가지 치명적인 문제가 발생한다.
첫째, 최적 여부를 확인할 방법이 없다. 감으로 선택했기 때문에 현재 설정이 최선인지 검증할 수단이 부재하다. 둘째, 개선 여부를 판단하기 어렵다. 파라미터를 변경했을 때 실제로 시스템이 나아졌는지 객관적으로 측정할 수 없다. 셋째, 시간 경과에 따른 품질 변화를 추적할 수 없다. AI 에이전트를 운영하면서 퀄리티가 떨어지는지, 개선되는지를 모니터링하기 어렵다.
2. AI 평가 방법론: 사람 vs. 지표
AI 모델을 평가하는 방법은 크게 두 가지로 나뉜다.
2.1 사람에 의한 평가(Human Evaluation)
도메인 전문가가 직접 프롬프트 입력과 결과물을 기록하고 평가하는 방식이다. 소량의 테스트 케이스에는 유효할 수 있지만, 테스트 케이스가 증가하면 확장성(Scalability)이 떨어진다. 또한 전문가라 하더라도 항상 객관적인 평가를 유지하기 어렵다는 한계가 있다.
2.2 지표 기반 평가(Metric-Based Evaluation)
지표 기반 평가는 다시 두 가지 방식으로 세분화된다.
2.2.1 규칙 기반 평가(Rule-Based Evaluation)
is_equal, contains, is_json 등의 수식을 활용하여 계산식에 따라 평가하는 방식이다. 예를 들어 AI가 특정 카테고리로 분류하는 작업을 수행한다면, 정답 카테고리와 AI가 생성한 카테고리가 동일한지 비교하여 일치하면 1점, 불일치하면 0점을 부여하는 식이다. 명확한 정답이 존재하는 분류(Classification) 작업이나 구조화된 출력(Structured Output) 검증에 적합하다.
2.2.2 LLM-as-Judge 평가
정성적인 요소를 고려해야 하거나 수식으로 표현하기 어려운 경우, LLM 자체를 판사(Judge)로 활용하는 방식이다. 사람이 직접 평가하는 부분을 LLM이 대신 수행하는 것으로, AI 모델을 선택하고 평가 가이드라인을 제시하면 그 지침에 따라 AI 모델이 스코어를 산출한다. 가이드만 잘 지정한다면 사람보다 훨씬 스케일이 용이하며, 10개, 100개, 1000개의 데이터셋이 있어도 LLM을 통해 자동으로 평가할 수 있다.
3. 실습 1: 이메일 자동 분류 에이전트 - 규칙 기반 평가
3.1 시나리오 설정
개인 사업가가 매일 수십 통의 메일을 받아 일일이 확인하고 분류하며 우선순위를 매기는 작업은 시간 소모가 크다. 이를 해결하기 위해 이메일을 자동으로 분류하는 AI 에이전트를 제작했다. 이 워크플로우는 이메일을 받아 **카테고리(Category)**와 **우선순위(Priority)**를 자동으로 분류한다.
3.2 평가 프로세스의 3단계
AI 에이전트의 퀄리티를 평가하기 위해서는 세 가지 프로세스를 거쳐야 한다.
- 테스트 데이터셋 구축: 평가할 샘플 데이터와 정답(Expected Answer)을 준비한다.
- 평가 지표 계산: 데이터셋을 대상으로 AI 에이전트 워크플로우를 실행하고 평가 지표를 산출한다.
- 분석 및 개선: 평가 지표를 분석하여 개선 포인트를 도출하고, 재평가를 통해 시스템을 최적화한다.
3.3 테스트 데이터셋 구축
n8n의 Data Table을 활용하여 테스트 데이터셋을 구축한다. Data Table은 n8n 내장 스프레드시트 기능으로, 테스트 데이터 활용 시 속도가 매우 빠르다. 홈 화면에서 Data Table을 선택하고 CREATE 버튼을 눌러 생성한다. 대량의 데이터를 임포트하려면 Import CSV 기능을 사용하여 CSV 파일을 업로드할 수 있다.
데이터셋은 다음 구조로 설계한다:
- Subject: 이메일 제목
- Body: 이메일 본문
- Expected Category: 정답 카테고리 (예: Business Inquiry, Spam, Advertisement)
- Expected Priority: 정답 우선순위 (예: High, Medium, Low)
정답지(Expected Answer)를 미리 작성해둠으로써, AI 에이전트가 출력한 값과 비교하여 평가할 수 있는 기반을 마련한다.
3.4 워크플로우 구성
3.4.1 데이터셋 불러오기: Evaluation Trigger
Evaluation 노드에서 Fetching a Dataset Row 트리거를 선택한다. 소스를 Data Table로 지정하고, 앞서 생성한 이메일 데이터셋을 선택한다. 이 트리거는 평가 실행 시 데이터셋의 각 row를 순차적으로 워크플로우에 공급한다.
3.4.2 변수 가공: Set Node
Gmail에서 받아오는 이메일 필드 구조와 통일하기 위해 Set 노드를 활용하여 변수를 가공한다. 예를 들어:
headers.subject: 이메일 제목body.text: 이메일 본문
이렇게 구조를 맞춤으로써, 평가용 데이터든 실제 Gmail 데이터든 동일한 워크플로우를 사용할 수 있다.
3.4.3 AI 에이전트 설정
시스템 프롬프트에서 이메일 분류 지침을 제공한다. 초기 프롬프트는 간단하게 카테고리와 우선순위 옵션만 안내하는 수준이었다:
카테고리: Business Inquiry, Spam, Advertisement
우선순위: High, Medium, Low
제목과 본문을 참고하여 카테고리와 우선순위를 출력하라.
모델은 GPT-4o-mini를 선택했다. 이메일 분류는 상대적으로 단순한 작업이므로 저렴한 모델로도 충분할 것으로 판단했다.
3.4.4 결과 기록: Set Outputs Node
Evaluation 섹션의 Set Outputs 노드를 사용하여 AI 에이전트가 출력한 값을 Data Table의 Actual Column에 기록한다. 데이터 테이블을 지정하고, 컬럼 이름을 설정한 후 AI 에이전트의 출력값(Category, Priority)을 매핑한다.
3.4.5 평가 지표 계산: Set Metric Node
Evaluation 섹션의 Set Metric 노드를 사용하여 규칙 기반 평가를 수행한다. Categorization 메트릭을 선택하면, 정답과 AI 출력이 정확히 일치하면 1점, 불일치하면 0점을 부여한다.
- Expected Answer: Data Table의
Expected Category컬럼 값 - Actual Answer: AI 에이전트의
Category출력값 - Metric Name:
category
동일한 방식으로 Priority에 대한 Set Metric 노드를 하나 더 추가하여 우선순위 평가를 설정한다.
3.5 평가 실행 및 결과 분석
워크플로우를 저장한 후, 상단 탭의 Evaluation 섹션으로 이동한다. 체크리스트를 확인하여 테스트 데이터셋 연동, Output 설정, Metric 설정이 모두 완료되었는지 확인한 후 Run Evaluation을 클릭한다.
10개의 샘플 데이터에 대해 평가를 실행한 결과:
- Category 점수: 0.9 (10개 중 9개 정답)
- Priority 점수: 0.6 (10개 중 6개 정답)
Priority 점수가 낮게 나온 이유를 분석하기 위해 개별 Execution 로그를 확인했다. 예를 들어 Spam 카테고리 이메일의 우선순위를 “High”로 잘못 분류한 케이스가 발견되었다. 정답은 “Low”여야 했다.
3.6 개선 1: 시스템 프롬프트 개선
우선순위 판단을 더 정확하게 하기 위해 시스템 프롬프트를 개선했다. 카테고리 정의를 구체화하고, 우선순위 판단 기준을 명확히 제시했다:
카테고리 정의:
- Business Inquiry: 사업 관련 문의
- Spam: 광고성 또는 불필요한 메일
- Advertisement: 홍보 메일
우선순위 판단 기준:
- High: 즉시 응답이 필요한 중요 문의
- Medium: 일반적인 업무 관련 문의
- Low: 광고, 스팸 등 긴급하지 않은 메일
재평가 결과:
- Priority 점수: 0.6 → 0.7
개선되었지만 여전히 아쉬운 수준이다.
3.7 개선 2: 모델 업그레이드
모델을 GPT-4o-mini에서 GPT-4o로 업그레이드했다. 비용은 증가하지만 더 정확한 판단을 기대할 수 있다.
재평가 결과:
- Category 점수: 0.9 → 1.0
- Priority 점수: 0.7 → 0.9
Priority에서 10개 중 9개를 맞추며 대폭 개선되었다. 실행 시간은 다소 증가했지만, 정확도가 크게 향상되었다.
3.8 평가 기반 개선의 가치
만약 이러한 개선 작업을 “감”에 의존해서 진행했다면, 프롬프트를 바꾸거나 모델을 변경했을 때 얼마나 개선되었는지 가늠하기 어렵다. n8n의 Evaluation 기능을 활용하면 **정량적 분석(Quantitative Analysis)**을 통해 미묘한 변화도 캐치할 수 있으며, 다음 개선 포인트를 데이터 기반으로 도출할 수 있다.
4. 실습 2: RAG 에이전트 평가 - LLM-as-Judge 방식
4.1 시나리오 설정
소규모 회사를 운영하면서 회사의 정책이나 프로세스를 매번 신입사원에게 설명하는 것은 번거롭다. CS 응대 매뉴얼과 같은 정책 문서를 기반으로 답변하는 RAG(Retrieval-Augmented Generation) 에이전트를 구축하여, 직원이 질문하면 자동으로 답변받을 수 있는 시스템을 만들었다.
RAG 에이전트의 성능을 평가할 때는 두 가지 측면을 고려해야 한다:
- 정확성(Correctness): AI가 문서를 참조하여 정확한 답변을 생성했는지
- 관련성(Relevance): AI가 참조한 문서 청크가 질문과 얼마나 관련이 있는지
결과물이 우연히 잘 나왔을 수도 있기 때문에, 실제로 제대로 된 문서 내용을 참조했는지를 별도로 평가하는 것이 중요하다.
4.2 RAG 워크플로우 구성
4.2.1 문서 임베딩: Simple Vector Store
Google Drive에서 CS 응대 매뉴얼 문서를 다운로드한 후, n8n의 Simple Vector Store를 활용하여 벡터화한다. Simple Vector Store는 테스트 목적으로 사용할 수 있는 간단한 벡터 스토어로, n8n을 재시작하면 내용이 사라지므로 실험용으로만 사용해야 한다.
설정:
- Embedding Model: OpenAI Embedding Model
- Document Format: Binary
- Chunk Size: 1000
- Chunk Overlap: 200
청크 크기와 오버랩 값도 나중에 결과를 보고 조정할 수 있다.
4.2.2 답변 생성: AI Agent with Retrieve Document
질문이 들어오면 AI 에이전트가 Simple Vector Store에서 관련 문서를 검색(Retrieve)하여 답변을 생성한다.
설정:
- Retrieve Document: Simple Vector Store의 Memory Key 지정
- Embedding Model: 문서 임베딩 시 사용한 것과 동일한 모델
- Chat Model: GPT-4o
- System Prompt: “벡터 데이터베이스에 있는 값을 바탕으로 항상 답변하라”
중요한 설정은 Return Intermediate Steps를 활성화하는 것이다. 이 옵션을 켜면 AI 에이전트가 어떤 문서 청크를 참조했는지를 워크플로우 아웃풋으로 받을 수 있다. 이 정보는 관련성(Relevance) 평가에 필수적이다.
4.2.3 Check If Evaluating Node
Check If Evaluating 노드를 추가하면 평가 모드와 일반 운영 모드를 구분할 수 있다.
- Evaluation 경로: 평가 실행 시 Set Outputs 및 Set Metric 노드로 진행
- Normal 경로: 실제 운영 시 답변만 반환하거나, Data Table에 Insert하여 실제 데이터를 샘플로 축적
이를 통해 실제 운영 중에도 데이터를 쌓아 나중에 평가용 샘플로 활용할 수 있다.
4.2.4 청크 정보 추출: Set Node
Intermediate Steps에서 벡터 데이터베이스에서 가져온 청크 정보를 추출하여, 관련성 평가에 사용할 수 있도록 가공한다.
4.3 LLM-as-Judge 평가 설정
4.3.1 정확성(Correctness) 평가
Set Metric 노드에서 Correctness 메트릭을 선택한다. LLM-as-Judge 방식으로 AI 모델이 답변의 정확성을 평가한다.
설정:
- Expected Answer: Data Table의
Expected Answer컬럼 - Actual Answer: AI 에이전트의 답변 출력
- Evaluation Prompt: 평가 가이드라인을 제공하여 1~5점 척도로 평가하도록 지시
- Metric Name:
correctness - Model: GPT-4o
평가 프롬프트 예시:
1점: 완전히 틀린 답변
2점: 부분적으로 맞지만 중요한 정보 누락
3점: 기본적인 정보는 맞지만 세부사항 부족
4점: 대부분 정확하나 약간의 개선 필요
5점: 완벽하게 정확한 답변
4.3.2 관련성(Relevance) 평가
Set Metric 노드를 하나 더 추가하여 Custom Metric으로 관련성을 평가한다.
설정:
- System Prompt: 1~5점 척도로 검색된 청크가 질문과 얼마나 관련 있는지 평가하는 가이드라인
- User Prompt: 질문과 실제로 검색된 청크(Facts) 정보를 제공
- Metric Name:
relevance - Model: GPT-4o
평가 프롬프트 예시:
1점: 질문과 전혀 관련 없는 문서 검색
2점: 약간의 관련성은 있으나 주요 정보 부족
3점: 기본적인 관련성은 있으나 최적은 아님
4점: 대부분 관련된 정보를 검색
5점: 질문에 완벽하게 부합하는 정보 검색
4.3.3 Set Outputs 및 Set Metric 설정
Set Outputs 노드에서 Actual Answer와 Retrieve Chunks를 Data Table에 기록한다.
Set Metric 노드는 두 개를 사용:
- Correctness: LLM이 직접 평가한 정확도 점수
- Relevance: Custom Metric으로 계산한 관련성 점수
4.4 평가 실행 및 결과
Data Table에 RAG 평가용 샘플 데이터를 생성한 후 Run Evaluation을 실행했다.
평가 결과:
- Relevance: 5.0점 (완벽한 문서 검색)
- Correctness: 4.8점 (10개 중 대부분 정확)
매우 높은 점수가 나왔다. 4점대를 받은 케이스 2개를 확인하여, 어떤 문서를 참조했고 왜 감점되었는지 분석할 수 있다.
이 사례는 간단한 문서 하나를 대상으로 한 RAG 시스템이었기 때문에 GPT-4o에게는 비교적 쉬운 작업이었다. 그러나 이처럼 간단한 RAG 시스템이더라도 Evaluation을 제대로 구축하지 않으면, 답변이 제대로 생성되고 있는지 일일이 확인하는 데 한계가 있다. 실제 데이터를 쌓으면서 운영하다가 답변 퀄리티가 떨어지는 것이 느껴질 때 다시 평가를 실행하여 지속적으로 모니터링할 수 있다.
5. 핵심 요약
5.1 n8n Evaluation의 가치
n8n의 Evaluation 기능을 활용하면 AI 에이전트의 성능을 감이 아니라 숫자로 측정할 수 있다. 정량적 지표를 통해 객관적이고 반복 가능한 평가가 가능해진다.
5.2 두 가지 평가 방식
평가는 **규칙 기반(Rule-Based)**과 LLM-as-Judge 방식으로 나뉜다. 규칙 기반은 명확한 정답이 있는 분류 작업에, LLM-as-Judge는 정성적 평가가 필요한 자유 응답 평가에 적합하다.
5.3 평가-개선 사이클
평가 결과를 바탕으로 개선 포인트를 도출하고, 시스템 프롬프트, 모델, 청킹 파라미터 등을 조정한 후 재평가를 통해 개선 여부를 확인한다. 이러한 Evaluation-Improvement Cycle을 반복하여 AI 시스템을 지속적으로 최적화할 수 있다.
5.4 실제 운영 데이터 활용
사전에 만든 샘플 데이터로만 평가하는 것이 아니라, 실제 운영 데이터를 쌓으면서 샘플 데이터를 확장하고 이를 기반으로 테스트를 진행함으로써 AI 시스템을 지속적으로 업그레이드할 수 있다.
5.5 유의사항: 셀프 호스팅 제약
셀프 호스팅 버전에서는 하나의 Evaluation만 동시에 실행할 수 있다. 두 번째 워크플로우에서 Evaluation을 실행하려고 하면 업그레이드를 요구하는 메시지가 나타난다. 클라우드 버전에서 플랜을 업그레이드하거나, 중요한 워크플로우 평가 시에만 템플릿을 다운로드하여 필요할 때 임포트해서 테스트하는 방식으로 활용할 수 있다.
6. 결론
AI 에이전트를 단순히 만드는 것을 넘어, 그 품질을 정량적으로 평가하고 지속적으로 개선하는 것은 실무 AI 시스템 운영의 핵심이다. n8n의 Evaluation 기능은 코딩 없이도 규칙 기반 평가와 LLM-as-Judge 평가를 손쉽게 구현할 수 있게 해주며, 프롬프트 엔지니어링, 모델 선택, RAG 파라미터 튜닝 등의 의사결정을 데이터 기반으로 할 수 있도록 돕는다. 감이 아닌 숫자로, 추측이 아닌 측정으로 AI 에이전트를 업그레이드하는 것이야말로 신뢰할 수 있는 AI 시스템 구축의 시작점이다.