n8n의 "판단" 단계를 Jev로 바꿔 보기, LLM 노드와 나란히 잰 기록

n8n으로 고객 문의를 분류하거나 라우팅할 때는 보통 LLM 노드에 Structured Output Parser를 붙입니다. 이 글에서는 그 자리에 판단만 하는 작은 모델인 Jev를 넣어 봤습니다. 커뮤니티 노드 없이 HTTP Request 노드 하나로 붙였고, 같은 캔버스에 기존 LLM 방식을 나란히 놓고 같은 문의로 비교했습니다.

워크플로 파일은 아래에서 바로 받을 수 있습니다. 가져온 뒤 자격증명 두 개만 고르면 실행됩니다.

💡 결론부터 말씀드리면 정확도는 LLM 방식과 구분되지 않았고, 비용은 4배에서 74배까지 쌌습니다. 차이가 가장 컸던 건 속도가 아니라 "애매하면 사람에게" 보내는 분기를 만들 수 있다는 점과 같은 문의에 매번 같은 답을 낸다는 점이었습니다. 속도는 n8n이 도는 서버 위치에 따라 달라서 직접 재 보셔야 합니다.

위는 이 데모의 실제 캔버스입니다. 인터랙티브 캔버스 열기를 누르면 n8n 공식 뷰어로 바뀌어 확대·이동하거나 노드를 더블클릭해 설정을 볼 수 있습니다. 뷰어는 불러오는 데 30초쯤 걸립니다. 전체 화면으로 보기

Jev가 무엇인가요

Jev는 TypeSafe가 만든 판단 전용 모델입니다. 글을 쓰지 않습니다. 질문을 받으면 정해진 형식의 답과 확률을 돌려줍니다. 예를 들어 "이 문의는 어느 팀이 처리해야 하나"를 물으면 billing, technical, sales, none 중 하나를 고르고, 각 선택지의 확률과 확신도(confidence)를 함께 줍니다.

이 데모에서는 문의 한 건에 질문 세 개를 한 번에 묻습니다.

💡 공식 문서는 docs.typesafe.ai에 있습니다. API 키는 TypeSafe에서 직접 발급받으셔야 합니다.

1단계. 워크플로 가져오기

워크플로 파일 주소는 아래와 같습니다.

https://storage.googleapis.com/dante-edu/n8n-jev-triage-demo/jev-vs-llm.json

n8n 편집 화면 오른쪽 위 메뉴에서 Import from URL을 고르고 이 주소를 붙여 넣으면 됩니다. 파일로 받아서 Import from File로 가져와도 같습니다.

가져오면 캔버스가 위아래 두 레인으로 나뉘어 있고, 왼쪽에 안내 노트가 붙어 있습니다.

2단계. 자격증명 두 개 만들기

⚠️ API 키는 꼭 자격증명에만 넣으세요. HTTP Request 노드의 헤더 칸이나 Code 노드에 직접 적으면, 워크플로를 내보낼 때 키가 파일에 함께 섞여 나갑니다.

3단계. 실행하기

수동 실행을 누르면 샘플 문의 10건이 두 레인을 동시에 탑니다. 각 레인의 마지막 노드를 눌러 보시면 같은 문의가 어느 팀으로 갔는지, P1이 붙었는지 비교할 수 있습니다.

캔버스 둘러보기

위 레인, Jev

요청 본문 조립(Code 노드)이 질문 세 개를 한 요청에 묶고, Jev 판단(HTTP Request 노드)이 https://api.typesafe.ai/v1/systemone을 한 번 호출합니다. 그다음 결과 정리에서 답을 꺼내고 IF·Switch 노드가 분기합니다.

직접 바꿔 보시면 좋은 곳은 결과 정리 노드의 임계값 세 개입니다.

• 임계값_확신도 0.6, 이보다 낮으면 자동 분류하지 않고 사람 검토로 보냅니다
• 임계값_긴급 0.5
• 임계값_분노 2

임계값을 Jev 안이 아니라 캔버스의 노드에 둔 이유는, 얼마나 사람에게 넘길지가 업무마다 다른 결정이기 때문입니다.

Jev 호출이 실패하면 확신도가 0으로 처리되어 자동으로 사람 검토로 갑니다. 별도의 에러 분기 없이, 잘못 분류하느니 분류하지 않는 쪽으로 떨어지게 만든 구조입니다.

아래 레인, n8n 기본 방식

Basic LLM Chain에 OpenRouter Chat Model과 Structured Output Parser를 붙인, 입문자가 가장 흔히 만드는 구성을 그대로 뒀습니다. 프롬프트의 분류 기준은 Jev 질문과 같은 문장을 썼습니다.

LLM은 보정된 확신도를 주지 않기 때문에, 이 레인에는 확신도 검사 자리에 형식 검증 IF 노드가 들어갑니다. 출력이 깨졌는지만 볼 수 있고 "애매한가"는 물을 수 없습니다. 두 레인을 위아래로 놓고 보면 이 차이가 캔버스에 그대로 드러납니다.

어떻게 쟀나요

• 문의: 한국어 합성 문의 40건. 절반 이상(23건)을 일부러 애매하게 썼습니다. 결제 오류처럼 보이지만 실제로는 버그인 글이나 두 팀에 걸친 글, 반어법이 섞인 글이 들어 있고, 조치가 필요 없는 글도 8건 넣었습니다
• 정답: 모델 출력을 보기 전에 달았습니다. 두 팀 모두 정답으로 볼 수 있는 14건은 미리 표시해 두고 "관대 기준"으로 따로 셌습니다
• 비교 대상: gpt-4o-mini(입문자가 흔히 고르는 소형), gpt-4o(중형). OpenRouter 경유
• 규모: n8n 밖에서 네 방식 × 40건 × 3회 = 480회, n8n 안에서 두 레인을 번갈아 160회

결과

n8n 안에서 두 레인 나란히 (1회, 각 40건)

가격은 2026년 9월 21일 공시 단가 기준입니다. Jev는 입력 100만 토큰당 $0.042이고 출력은 무료입니다.

1. 정확도는 구분되지 않았습니다

40건 규모에서 2건 차이는 잡음입니다. 세 방식 모두 약 90% 안팎이라 "Jev가 더 정확하다"도 "덜 정확하다"도 말할 수 없습니다. 걱정했던 한국어 질문도 문제가 없었습니다. 같은 문의를 영어 질문으로 물었을 때와 팀 정확도가 같았습니다(89.2%).

2. 비용은 4배에서 74배 쌌습니다

재미있는 건 Structured Output Parser가 토큰을 먹는다는 점입니다. 파서는 프롬프트 뒤에 "이 JSON 스키마에 맞춰 답하라"는 지시문을 붙이는데, 이 때문에 같은 프롬프트의 입력이 411토큰에서 607토큰으로 약 48% 늘었습니다. n8n에서 LLM으로 판단하면 파서 몫까지 내는 셈입니다.

3. "애매하면 사람에게"를 만들 수 있습니다

확신도 0.6을 기준으로 40건을 흘려보냈더니 이렇게 나뉘었습니다.

보류된 9건 중 8건이 제가 정답을 달면서 미리 "애매하다"고 표시해 둔 문의였습니다. 확신도가 사람의 애매함 감각과 꽤 겹친다는 뜻입니다.

다만 보류된 9건도 Jev 답은 다 맞았으니, 이 데이터에서 0.6은 보수적인 값입니다. 틀린 라우팅 0건을 얻는 대신 22.5%를 사람에게 넘긴 셈입니다. 이 숫자를 캔버스에서 바꿔 가며 "얼마나 넘길 것인가"를 직접 정해 보시는 게 이 데모의 핵심입니다.

4. 같은 문의에 같은 답을 냅니다

같은 40건을 세 번씩 물었을 때 "오늘 안에 답해야 하나"의 답이 바뀐 문의 수입니다.

gpt-4o는 40건 중 10건에서 실행할 때마다 답이 달랐습니다. 같은 티켓이 어떤 날은 P1이고 어떤 날은 일반 처리가 되는 겁니다. 자동화 워크플로에서는 이런 흔들림이 형식 오류보다 더 곤란합니다.

5. 속도는 서버 위치에 달렸습니다

n8n 실행 기록에서 노드별 시간을 뜯어 보면, HTTP Request를 뺀 나머지 노드 14개를 전부 합쳐도 35ms였습니다. n8n 자체는 거의 시간을 쓰지 않습니다.

반면 같은 Jev 호출이 제 맥북에서는 234ms, n8n이 도는 미니 PC에서는 562ms가 걸렸습니다. 판단 노드끼리 비교하면 Jev가 1.8~1.9배 빨랐지만, 이 비율은 n8n이 어디서 도는지에 따라 달라집니다. n8n Cloud나 각자의 서버에서는 다른 값이 나올 테니 직접 재 보시길 권합니다.

6. 형식 실패는 거의 없었습니다

LLM 출력이 파서에서 깨지는 경우를 기대하고 셌는데, 640회 중 1회였습니다. gpt-4o급 모델에서는 형식 오류를 걱정할 이유가 크지 않았습니다. 그래서 이 글에서는 이걸 Jev의 장점으로 내세우지 않았습니다.

한계

• 문의는 합성이고, 정답은 한 사람(저)이 달았습니다. 애매한 문의는 정답 자체가 논쟁적일 수 있습니다
• 40건은 작은 표본입니다. 정확도 차이는 전부 "구분 안 됨"으로 읽어 주세요
• LLM 레인의 프롬프트는 입문자가 쓸 법한 평범한 것 하나로 고정했고, 튜닝하지 않았습니다
• LLM은 OpenRouter를 거쳐 호출했습니다. 제공사 API를 직접 쓰면 시간이 조금 달라질 수 있습니다
• Jev는 영어 주력 모델이라고 공식 문서에 나와 있습니다. 이 실험의 한국어 결과가 다른 도메인에도 그대로 이어진다고 보장할 수 없습니다

마무리, 판단은 작은 모델에게

정리하면 n8n에서 Jev로 바꿔서 얻는 건 "빠른 LLM"이 아닙니다. 같은 정확도를 훨씬 싸게, 확신도와 함께, 흔들림 없이 얻는 것입니다. 답장 초안처럼 글을 써야 하는 단계는 여전히 LLM의 몫이고, 그 앞에서 분류하고 걸러내는 단계를 Jev에게 맡기는 구성이 가장 잘 맞았습니다.

워크플로를 가져와서 임계값을 바꿔 보고, 여러분의 문의 데이터로도 한번 돌려 보세요. 실제 고객 문의를 외부 API로 보낼 때는 개인정보 처리 방침을 먼저 확인하시고요.

궁금한 점이나 여러분 환경에서 잰 결과가 있으면 카카오톡 오픈채팅방 Agentic AI 커뮤니티에 남겨 주세요.