n8n 임베딩 검색 파이프라인 점검 기록

문제 배경: 왜 검색은 되는데 결과가 불안정했나

이번 점검의 목표는 임베딩을 새로 대량 생성하는 것이 아니라, 이미 저장된 벡터를 안정적으로 검색해 실무에 바로 쓰는 상태를 만드는 것이었습니다. 실제 운영에서는 파이프라인이 길어질수록 장애 지점이 늘어나고, 한 노드의 출력 형태가 조금만 달라도 다음 노드에서 연쇄 실패가 발생합니다.

특히 n8n에서는 노드 간 데이터 구조가 엄격하지 않게 흘러가다 보니, 테스트 때는 통과하더라도 실데이터에서 깨지는 케이스가 반복됩니다. 그래서 이번에는 기능 확장보다 경로 고정과 검증 규칙을 우선했습니다.

1차 장애: 임베딩 응답 경로 불일치

Cloudflare 임베딩 응답이 상황에 따라 result.data[0].embedding 또는 data[0].embedding 형태로 들어와 Parse 단계에서 실패가 발생했습니다. 단일 경로만 가정하면 즉시 에러가 발생하고 후속 검색 노드가 전부 멈춥니다.

해결은 단순합니다. Parse 노드에서 두 경로를 모두 허용하고, 배열 검증을 통과한 경우에만 다음 노드로 넘기도록 만들면 됩니다. 이 조치만으로 “임베딩 없음” 계열 오류를 크게 줄일 수 있습니다.

2차 장애: PGVector 캐스팅 문법 오류

다음 문제는 SQL에서 벡터 문자열이 실제 값으로 평가되지 않고 문자열 그대로 전달되는 케이스였습니다. 이 경우 PostgreSQL에서 invalid input syntax for type vector가 발생합니다.

핵심은 쿼리 템플릿에서 임베딩 배열을 정확히 조인해 '[ ... ]'::vector 형식으로 캐스팅하는 것입니다. 문법이 맞더라도 공백/쉼표 처리 실수가 있으면 바로 실패하므로, 실제 쿼리 문자열 로그를 반드시 확인해야 합니다.

검색 우선 전략: 생성보다 조회를 먼저 안정화

운영 관점에서는 신규 임베딩 생성보다 기존 데이터 검색의 성공률을 먼저 확보하는 것이 효율적입니다. 검색이 안정화되면 이후 생성 파이프라인은 점진적으로 붙여도 전체 서비스 신뢰도를 해치지 않습니다.

그래서 본 워크플로우는 “검색 전용 최소 경로”를 기준으로 재정렬했고, 우회 노드는 필요할 때만 활성화하는 방식으로 바꿨습니다. 이 구조는 장애 원인 추적 속도를 확실히 높여줍니다.

워드프레스 등록 포맷: 운영 고정 규칙

이 포맷을 품질 게이트에 하드룰로 넣으면, 글 품질이 들쭉날쭉해지는 문제를 줄일 수 있습니다. 게시 실패 시에는 즉시 중단하고 실패 사유만 응답하도록 설계하는 것이 안전합니다.

실행 체크리스트

1. Parse 노드에서 임베딩 경로 2가지 모두 허용했는지 확인
2. PGVector 쿼리의 벡터 캐스팅 문자열을 실행 로그에서 검증
3. 검색 전용 경로와 생성 경로를 분리해 장애 범위를 축소
4. 워드프레스 포맷 규칙(길이/구조/금지어)을 품질게이트에 고정
5. 게시 전 draft 검수, 승인 후 publish로 승격