LangFlow에서는 통과하지만 n8n 프로덕션에서는 실패하는 3가지 테스트

당신은 LangFlow 프로토타입을 구축했습니다. 모든 테스트를 통과했습니다. 플로우(flow)를 내보내어 n8n에 넣었더니, 첫 번째 프로덕션 실행에서 오류가 발생했습니다.

이것은 버그 리포트가 아닙니다. 하나의 패턴입니다.

LangFlow 프로토타입을 구축했지만 동일한 로직을 n8n 프로덕션에 배포할 때 미스터리한 실패를 겪어본 3년 차 SDET(Software Development Engineer in Test)라면 이미 그 기분을 알고 있을 것입니다. 프로토타입은 견고하게 느껴졌습니다. 하지만 프로덕션 파이프라인은 마치 다른 언어처럼 느껴졌습니다.

그렇지 않습니다. 차이점은 실행 컨텍스트(execution context)에 있습니다. LangFlow는 상태(state)가 관대하고 재시도(retries)가 보이지 않는 노트북(notebook)과 유사한 환경에서 실행됩니다. 반면 n8n은 모든 노드(node)가 트랜잭션 경계(transaction boundary)이며, 명시적으로 처리하지 않는 한 모든 실패가 최종적인 워크플로 엔진(workflow engine)에서 실행됩니다.

다음은 LangFlow에서는 통과하지만 n8n 프로덕션에서는 실패하는 세 가지 테스트이며, 이것이 신뢰할 수 있는 AI 파이프라인을 구축하는 것에 대해 무엇을 가르쳐주는지에 대한 내용입니다.

테스트 1: "LLM이 유효한 JSON을 반환하는가" 테스트

LangFlow에서 통과하는 경우: 모델에게 JSON을 반환하도록 요청하는 프롬프트(prompt)를 보냅니다. 응답이 문자열(string)로 돌아옵니다. json.loads()로 이를 파싱(parse)합니다. 작동합니다. 다음 단계로 넘어갑니다.

n8n에서 실패하는 경우: 모델이 코드 블록(code block)으로 시작하는 문자열을 반환합니다. 또는 마지막에 쉼표(trailing comma)가 붙거나, 마크다운 펜스(markdown fence)가 포함되거나, JSON 앞에 서문(preamble sentence)이 붙거나, 컨텍스트 윈도우(context window) 초과로 인해 아무것도 반환하지 않을 수 있습니다.

차이가 발생하는 이유: LangFlow의 Python 노드는 잘못된 형식의 출력을 조용히 허용합니다. 만약 json.loads()가 실패하면, 출력 패널에서 오류를 확인하고 프롬프트를 수정하면 됩니다. n8n의 JSON 노드는 재시도하지 않습니다. 폴백(fallback)도 수행하지 않습니다. 워크플로 전체를 중단시키는 구조화된 오류(structured error)를 발생시킵니다.

해결책은 더 나은 프롬프트가 아닙니다. 해결책은 파싱하기 전에 LLM 출력을 정규화(normalize)하는 검증 레이어(validation layer)를 두는 것입니다.

import json
import re

...
```
(?:json)?\s*', '', raw.strip())
    cleaned = re.sub(r'\s*

```$', '', cleaned)

    # 첫 번째 { 와 마지막 } 를 찾음
    start = cleaned.find('{')
...

이 함수는 n8n의 공유 유틸리티 노드(shared utility node)에 존재합니다. 모든 LLM 호출은 이 노드를 거쳐 라우팅됩니다. 이 노드는 LangFlow에서는 조용히 흡수되었던 예외 케이스(edge cases)들을 잡아냅니다.

이것이 주는 교훈: 프로토타입 환경은 취약성을 숨깁니다. LangFlow에서 통과하는 테스트는 출력 형식(output format)을 테스트하는 것이 아닙니다. 그것은 모델이 '보통' 파싱 가능한 무언가를 반환하는지를 테스트하는 것입니다. 프로덕션(Production)에는 희망이 아닌 계약(contract)이 필요합니다.

테스트 2: "컨텍스트 윈도우 적합성" 테스트

LangFlow에서 통과하는 경우: 프롬프트에 문서를 입력합니다. 문서의 길이는 8,000 토큰(tokens)입니다. 모델이 이를 처리합니다. 12,000 토큰으로 다시 테스트합니다. 여전히 괜찮습니다. 당신은 파이프라인(pipeline)이 준비되었다고 선언합니다.

n8n에서 실패하는 경우: 프로덕션 문서가 18,000 토큰입니다. 모델은 조용히 내용을 잘라냅니다(truncates). 또는 컨텍스트 윈도우(context window)가 시스템 프롬프트(system prompts)와 대화 기록으로 가득 차서 실제 입력을 위한 공간이 남지 않게 됩니다. 출력은 일반적인 내용으로 변합니다. 통과했던 테스트가 이제 쓰레기(garbage)를 생성합니다.

차이점이 발생하는 이유: LangFlow는 각 프롬프트를 격리된 상태로 실행합니다. 당신은 무엇이 들어가는지 정확히 제어합니다. 반면 n8n 워크플로우(workflows)는 상태(state)를 축적합니다. 대화 기록을 앞에 붙이는 노드, 메타데이터(metadata)를 추가하는 서브 워크플로우(sub-workflow), 이전 출력들을 연결(concatenate)하는 루프(loop) — 이들 각각이 컨텍스트를 잡아먹습니다. 프로토타입은 전체 체인(full chain)을 실행한 적이 없기 때문에 이를 테스트하지 못했습니다.

해결책은 더 큰 모델을 사용하는 것이 아닙니다. 해결책은 측정되고 강제되는 컨텍스트 예산(context budget)을 설정하는 것입니다.

// n8n 노드: 컨텍스트 예산 확인기 (Context Budget Checker)
// 모든 LLM 호출 이전에 이 노드를 배치하세요

...

이 노드는 빠르게 실패(fails fast)합니다. LLM이 과하게 채워진 컨텍스트로 실행되도록 내버려 두지 않습니다. 에러 메시지는 운영자에게 정확히 무엇을 수정해야 하는지 알려줍니다.

이것이 주는 교훈: 격리된 상태에서 통과하는 테스트는 시스템에 대한 테스트가 아닙니다. 시스템은 컨텍스트에 닿는 모든 노드를 포함합니다. LangFlow는 프롬프트를 테스트합니다. n8n은 파이프라인을 테스트합니다. 이 둘은 서로 다른 것입니다.

테스트 3: "재시도는 공짜" 테스트

LangFlow에서 통과하는 경우: LLM 호출이 실패합니다. 다시 "Run"을 클릭합니다. 작동합니다. 당신은 일시적인 오류가 네트워크의 일시적인 문제(network blip)였다고 가정합니다. 재시도 핸들러 (retry handler)를 작성하지 않습니다.

n8n에서 실패하는 경우: 새벽 2시에 LLM 호출이 실패합니다. 워크플로우 (workflow)가 중단됩니다. 아침이 될 때까지 아무도 알아차리지 못합니다. 처리되었어야 할 데이터가 오류 큐 (error queue)에 갇힙니다. LangFlow에서 통과했던 테스트는 새벽 2시에 실행되지 않았습니다.

차이점의 이유: LangFlow는 개발 환경 (development environment)입니다. 당신이 재시도 핸들러 (retry handler) 역할을 합니다. 오류를 보고, 무엇을 할지 결정하고, 버튼을 클릭합니다. n8n은 프로덕션 환경 (production environment)입니다. 관리자 없이 실행됩니다. 실패 시 무엇을 해야 할지 알려주지 않았다면, n8n은 아무것도 하지 않습니다.

해결책은 단순한 재시도가 아닙니다. 해결책은 지수 백오프 (exponential backoff)와 데드 레터 큐 (dead-letter queue)를 포함한 재시도입니다.

// n8n 서브 워크플로우 (sub-workflow): 재시도를 포함한 LLM 호출
// LLM 노드를 래핑 (wraps)

...

데드 레터 큐 (dead-letter queue)는 매우 중요합니다. 이는 실패한 입력을 보존하여 문제를 해결한 후 다시 재생 (replay)할 수 있게 해줍니다. 이것이 없다면 오류는 블랙홀이 됩니다.

이것이 가르쳐 주는 것: 프로토타입 (prototype)에는 실패 모드 (failure modes)가 없습니다. 프로덕션에는 있습니다. LangFlow에서 통과하는 테스트는 해피 패스 (happy path)를 테스트하는 것입니다. n8n에서 중요한 테스트는 언해피 패스 (unhappy path)를 테스트하는 것입니다. 해피 패스만 테스트한다면, 당신은 테스트를 하고 있는 것이 아닙니다.

이 세 가지 테스트가 가르쳐 주는 것

이러한 각각의 실패는 하나의 근본 원인을 공유합니다. 바로 프로토타입 환경과 프로덕션 환경이 신뢰성 (reliability)에 대해 서로 다른 가정을 하고 있다는 점입니다.

LangFlow는 당신이 지켜보고 있다고 가정합니다. 당신이 엣지 케이스 (edge case)를 수동으로 처리할 것이라고 가정합니다. 입력 데이터가 깨끗하고 모델이 협조적이라고 가정합니다.

n8n은 당신이 지켜보고 있지 않다고 가정합니다. 모든 엣지 케이스 (edge case)가 명시적으로 처리되어야 한다고 가정합니다. 입력 데이터가 지저분하고 모델이 신뢰할 수 없다고 가정합니다.

LangFlow 프로토타입을 만들고 n8n 프로덕션에서 미스터리한 실패를 겪은 3년 차 SDET는 실수를 하고 있는 것이 아닙니다. 그들은 프로토타입과 프로덕션 시스템의 차이를 배우고 있는 것입니다. 그 차이는 도구가 아니라, 계약 (contract)에 있습니다.

LangFlow는 다음과 같이 말합니다: "모델이 무엇을 반환하는지 보여드리겠습니다."

n8n은 다음과 같이 말합니다: "묻지 않고, 매번, 당신이 말한 그대로를 수행하겠습니다."

두 번째 방식이 더 어렵습니다. 또한 새벽 2시에 실행되는 것도 바로 이 방식입니다.

다음에 해야 할 일

LangFlow 프로토타입을 n8n으로 옮기려 한다면, 단순히 플로우(flow)를 내보내고(export) 요행을 바라지 마세요. 대신 다음과 같이 하십시오:

1. 검증 레이어 (validation layer) 추가: 모든 LLM 출력에 대해 검증 레이어를 추가하세요. 파싱(parsing)하기 전에 정규화(normalize)를 수행하십시오.
2. 컨텍스트 사용량 측정: 모든 LLM 호출 전에 컨텍스트 (context) 사용량을 측정하세요. 조용히 실패하지 말고, 빠르게 실패(fail fast)하게 만드십시오.
3. 지수 백오프 (backoff)를 포함한 재시도 및 데드 레터 큐 (dead-letter queue) 구현: 지수 백오프를 적용한 재시도 로직과 데드 레터 큐를 구현하세요. 모든 호출은 최소 한 번은 실패할 것이라고 가정하십시오.

이 세 가지 변화는 LangFlow에서는 통과하지만 n8n에서는 실패하는 테스트들을 잡아낼 것입니다. 또한 이는 프로토타입에서는 절대 드러나지 않았던 여러분의 파이프라인 (pipeline)에 대해 무언가를 가르쳐 줄 것입니다.

프로토타입은 스케치입니다. 프로덕션은 건물입니다. 이 둘을 혼동하지 마십시오.

여러분의 LangFlow 테스트 중 새벽 2시에 한 번도 실행해 보지 않은 것은 무엇입니까?