모델이 내 밑에서 바뀐 경험: n8n에서 LLM 버전 및 회귀 테스트 핀 지정하기

이 글은 프로덕션 환경에서 n8n으로 LLM 워크플로우를 실행하는 방법에 대한 저의 '공개 빌드(build-in-public)' 시리즈 중 일부입니다. 여기에 있는 모든 것은 제가 판매하고 지원하는 실제 템플릿에서 가져온 것입니다. 실수한 부분은 제 것이고, 수정된 부분은 테스트를 거쳤습니다.

금요일에는 작동했지만 월요일에는 작동하지 않았고, 저는 아무것도 변경하지 않았습니다.

워크플로우는 금요일에 모든 검사를 통과했습니다. 하지만 월요일이 되자 초안(drafts)들이 다른 형태로 돌아왔습니다. 프롬프트도 같고, 입력 데이터도 같은데 구조가 다르고, 톤이 다르며, 핵심 필드 하나가 누락되었습니다. 저는 워크플로우를 먼저 확인했고, 다음으로 입력 데이터를 확인했으며, 마지막으로 프롬프트를 확인했습니다. 세 가지 모두 손대지 않은 상태였습니다.

변화는 제 밑에서 일어났습니다. 제가 호출하던 모델 별칭(model alias)이 주말 사이에 더 새로운 버전으로 이동했기 때문입니다. 제공업체(provider)가 업데이트를 배포했고, 저의 "안정적인(stable)" 모델 이름은 이제 다른 가중치(weights)를 가리키고 있었으며, 제 워크플로우는 제가 승인한 적 없는 변경 사항을 조용히 배포했습니다.

이것이 한 문장으로 요약되는 교훈입니다. 고정되지 않은 모델 이름은 고정되지 않은 종속성(dependency)입니다. 생산 환경에서 라이브러리를 배포할 때 "최신(latest)"이라고 작성하고 다음 릴리스가 호환되기를 바라는 식으로는 하지 않을 것입니다. 모델 별칭도 같은 도박이지만, 상황이 더 나쁩니다. 왜냐하면 모델 업데이트는 크게 오류를 발생시키지 않고 — 스키마를 통과하고 고객에게 실패할 만큼 충분히 출력을 변경하기 때문입니다.

정확한 버전을 고정하고 작업 기록에 남기세요.

첫 번째 해결책은 지루하지만 필수적입니다. 모델 패밀리 이름이 아닌, 정확한 모델 버전을 고정해야 합니다. 제공업체가 날짜가 지정된 스냅샷(dated snapshots)을 제공한다면, 그 스냅샷을 호출하세요. 만약 별칭만 제공한다면, 그것을 기본값으로 받아들일 위험이 아니라 관리해야 할 위험으로 간주하고 — 그리고 이 별칭에 달력 알림을 설정하세요. 왜냐하면 그것은 반드시 이동할 것이기 때문입니다.

이만큼이나 중요합니다. 제공업체, 시도 횟수, 최종 상태 옆의 작업 행에 모델 버전을 기록해야 합니다. 출력 품질이 변동할 때 가장 먼저 던지는 질문은 언제나 “무엇이 바뀌었는가?”입니다. 만약 작업 행에 어떤 모델 버전이 각 초안을 생성했는지 명시되어 있지 않다면, 그 답을 할 수 없습니다. 모델이 이동한 것을 발견하기까지 일주일 동안 프롬프트, 입력, 그리고 워크플로우를 다시 검토하게 될 것입니다. 저는 요청한 모델이 아닌, 제공업체에서 반환된 모델 문자열을 기록합니다. 왜냐하면 별칭(alias)이 해결될 때 이 둘은 다를 수 있기 때문입니다.

감(感)에 의존하는 테스트가 아닌 회귀 테스트 세트

모델 버전을 고정(Pinning)하는 것은 조용한 드리프트(drift, 이탈)를 막아줍니다. 하지만 새로운 버전이 채택하기 안전한지 여부를 알려주지는 않습니다. 이를 위해 저는 고정된 회귀 테스트 세트를 유지합니다. 이는 실제 입력값으로 구성된 작은 모음집이며, 프로덕션에 적용되기 전에 모든 후보 모델 버전에 대해 실행됩니다.

이 세트는 의도적으로 작습니다. 중요하게 다루어야 할 형태를 포괄하는 10개에서 20개의 입력값이 포함됩니다: 길고 복잡한 것, 짧지만 모호한 것, 지난번에 문제가 되었던 엣지 케이스(edge case)가 있는 것, 그리고 다른 언어로 된 것 등. 각 입력값에는 검증 조건(assertion)이 있으며, 이 검증 조건 부분이 사람들이 가장 많이 실수하는 부분입니다.

정확히 일치하는 출력 텍스트를 검증 조건으로 삼지 마십시오. LLM의 출력은 결정론적(deterministic)이지 않으며, 정확히 일치하는 매칭 테스트는 좋은 버전에서도 실패할 것이고, 결국 여러분이 테스트 스위트를 무시하도록 가르칠 것입니다. 대신 불변성(invariant)을 검증하세요:

• 출력이 스키마에 맞게 파싱되며, 필수 필드가 존재하고 올바르게 유형 지정되어 있는지.
• 금지된 패턴은 부재함 — JSON 주변의 마크다운 코드 펜스, 임의로 만들어진 필드, 자리 표시자 텍스트가 없어야 함.
• 입력값의 핵심 사실들은 살아남아야 함: 이름, 날짜, 금액 등이 출력에 나타나야 하며, 다른 것으로 의역되어서는 안 됨.
• 길이는 합리적인 범위 내를 유지해야 함: 요약이 길이가 세 배로 늘어나거나 한 문장으로 축소되는 경우, 파싱은 되더라도 회귀(regression)로 간주되어야 합니다.
• 동일한 입력값을 두 번 실행해도 모순되는 구조화된 필드를 생성해서는 안 됨.

스키마를 통과했지만 필수 필드를 누락하거나, 날짜를 임의로 만들거나, 길이가 두 배가 된 버전은 n8n의 모든 노드가 녹색으로 표시되었더라도 실패한 것입니다.

프로모션 전에 비교하고 이전 버전을 유지하세요

프로모션 규칙은 테스트에서 비롯됩니다. 즉, 제공업체의 일정에 맞춰 운영 워크플로우를 새로운 모델 버전으로 절대 전환해서는 안 됩니다. 후보(candidate) 모델을 대상으로 회귀 세트(regression set)를 실행하고, 동일한 입력값에 대해 출력값을 현재 버전의 출력값과 비교(diff)하며, 그 차이점을 직접 읽어보아야 합니다. 진짜 변화는 바로 이 차이점 속에 숨겨져 있습니다. 필드가 더 장황해졌거나, 어조가 바뀌었거나, 특정 카테고리가 다르게 사용되기 시작했을 수 있습니다. 자동화된 단언(automated assertions)은 오류(breakage)를 잡아내지만, 차이점 분석(diff)은 아직 오류는 아니지만 발생한 미묘한 변화(drift)를 포착합니다.

새로운 버전이 안정적으로 운영 환경에서 충분히 실행되기 전까지는 이전 핀 지정된 버전을 계속 사용해야 합니다. 모델 변경은 배포(deploy)와 같으며, 모든 배포에는 롤백(rollback)이 필요합니다. 이는 프롬프트와 모델을 함께 버전 관리해야 함을 의미합니다. 한 버전에 맞춰 조정된 프롬프트가 다음 버전에서도 동일하게 작동한다고 보장할 수 없기 때문에, '모델 되돌리기'는 반드시 '그 모델과 테스트되었던 프롬프트로 되돌리기'를 의미해야 합니다. 저는 프롬프트 버전과 모델 버전을 쌍으로 저장하고, 롤백은 이 두 가지 모두를 복원합니다.

품질뿐만 아니라 비용과 지연 시간(latency)도 확인하세요

사람들이 놓치는 또 다른 축이 있습니다. 새로운 버전이 정확하더라도 여전히 잘못된 배포일 수 있다는 것입니다. 더 느릴 수 있으며, 이는 워크플로우가 실행을 대기하는 경우 중요합니다. 또는 토큰당 비용이 더 많이 들 수 있는데, 이는 하루에 천 번씩 실행할 때 중요한 문제입니다. 저의 회귀 실행은 입력별로 사용된 토큰(tokens in), 출력된 토큰(tokens out), 그리고 실제 경과 시간(wall-clock time)을 기록하며, 저는 이 값들을 프로모션 전에 현재 버전과 비교합니다. 동일한 품질에 대해 두 배의 비용이 드는 버전은 무료 업그레이드가 아니라 가격 책정 결정이며—이는 다음 달 청구서에서 발견되어서는 안 되고 의도적으로 이루어져야 합니다.

테스트는 새로운 실행이 아닌 버전 교체입니다

제대로 테스트하려면 실제로 저에게 피해를 입혔던 이벤트를 시뮬레이션하는 것이 의미합니다. 즉, 작동 중인 워크플로우의 모델 버전을 변경하여 무엇이 깨지는지 확인해야 합니다. 테스트 하네스는 간단합니다. 회귀(regression) 세트를 가져와 현재 고정된 버전(pinned version)으로 실행한 다음, 동일한 세트를 후보 버전(candidate version)으로 실행하고 세 가지를 단언해야 합니다: 모든 불변성(invariant)이 여전히 유지되는지, 출력의 차이점(diff in outputs)이 읽고 수락한 것인지, 그리고 비용과 지연 시간(latency)이 예산 내에 있는지입니다. 이 중 하나라도 실패하면 후보 버전은 배포되지 않으며, 워크플로우는 이미 통과한 고정된 버전을 계속 사용합니다.

이는 n8n이 아닌 제공업체(provider) 측에서 계산해야 합니다. 요청된 이름과 실제로 서비스되는 버전이 항상 같지 않기 때문에, 어떤 모델 버전이 각 호출에 실제로 사용되었는지 기록해야 합니다.

원칙

모델은 의존성(dependency)입니다. 마치 의존성처럼 고정하고, 배포(deploy)하듯이 새 버전을 테스트하며, 새로운 버전이 자리를 얻을 때까지 이전 버전을 유지해야 합니다. 목표는 진행을 멈추는 것이 아닙니다—새로운 버전이 더 나은 경우가 많습니다. 목표는 출력이 변경될 때, 그것이 당신이 선택한 날에, 되돌리기(rollback) 준비가 된 상태에서 그렇게 하도록 결정했기 때문인지 확인하는 것입니다. 주말 동안 제공업체가 업데이트를 배포하여 워크플로우가 조용히 다른 질문에 답하기 시작했기 때문이 아니어야 합니다.

저는 AI Automation Lab — 프로덕션 레디 n8n 워크플로우 템플릿을 만들고 있습니다. 무료 AI Hook Generator는 제가 실제 워크플로우를 구성하는 방법을 보여주며, 저의 오픈 소스 템플릿은 github.com/zhp910318/n8n-ai-automation-lab에 있습니다.