LLM 워크플로 “텍스트 방화벽” 만들기: n8n Guardrails 아키텍처

🛡️ n8n Guardrails 노드 종합 가이드 (안전·보안·정책 “텍스트 방화벽”)

🕵️ PII·Secret Key·URL 유출 차단: Guardrails로 만드는 안전 파이프라인

300x250

n8n의 Guardrails 노드는 LLM(챗모델)을 쓰는 워크플로에서 입력/출력 텍스트를 검사하거나(차단/분기), 민감정보를 정제(마스킹)하는 정책 레이어입니다. 즉, “모델을 부르기 전/후”에 두어 프롬프트 인젝션·정보유출·부적절 콘텐츠·범위 이탈을 줄이는 용도입니다.

노드가 하는 일(핵심 개념)

Check Text for Violations (위반 검사 → Fail 분기)

선택한 가드레일에 하나라도 걸리면 Fail 브랜치로 라우팅합니다. “차단/보류/수동검토/알림” 같은 제어 흐름을 만들기 좋습니다.

Sanitize Text (정제 → 플레이스홀더로 치환)

URL/정규식/시크릿/PII 등을 탐지해서 마스킹(placeholder로 치환)합니다.
→ “LLM 호출 전에 개인정보/키 유출을 막는 전처리”에 특히 유용합니다.

“Chat Model 연결”이 필요한 경우(중요)

LLM 기반 가드레일(Jailbreak / NSFW / Topical Alignment / Custom)은, Operation이 “Check Text for Violations”일 때 Guardrails 노드의 Model 입력에 Chat Model 노드가 연결되어야 동작합니다.

반대로, URLs / Custom Regex / (일부) PII / Secret Keys 등은 LLM 없이도 동작 가능한 성격의 체크가 포함됩니다. (정제 모드 중심)

파라미터 완전 정리

Operation

• Check Text for Violations: 위반이면 Fail 브랜치
• Sanitize Text: 위반을 치환하고 계속 진행

Text To Check

• 보통 이전 노드의 값(예: 사용자 질문, LLM 답변)을 Expression으로 매핑합니다.

Guardrails 종류별 “무엇을 막고, 어떻게 쓰는지”

아래 항목들은 n8n 공식 문서에 있는 Guardrails 목록과 설정 옵션을 기반으로 정리했습니다.

Keywords (키워드 차단)

특정 단어가 포함되면 위반 처리.

• 예: password, api_key, 주민등록번호, ssh-rsa, BEGIN PRIVATE KEY
• 내부 운영 규정/금칙어/고객응대 금지표현 같은 “규칙 기반”에 강함.

Jailbreak (탈옥 탐지, LLM 기반)

“안전장치 우회” 시도(프롬프트 인젝션)를 탐지합니다.

• Customize Prompt: 탐지 프롬프트 튜닝
• Threshold (0.0~1.0): 높을수록 더 엄격

NSFW (유해/성인, LLM 기반)

부적절(성인/선정) 콘텐츠 요청/생성을 탐지합니다.

• Customize Prompt / Threshold 제공

PII (개인정보 탐지)

이메일/전화번호/카드번호 등 개인정보 엔티티 탐지

• All 또는 Selected(특정 엔티티만) 선택 가능

Secret Keys (시크릿/자격증명 탐지)

API Key, 토큰, 크리덴셜 흔적을 탐지

• Permissiveness: Strict / Balanced / Permissive
• 초기엔 Balanced로 시작 → 오탐/누락을 보고 Strict/Permissive로 조정하는 운영이 현실적입니다.

Topical Alignment (업무 범위 강제, LLM 기반)

“이 워크플로의 허용 범위(업무 스코프)”를 프롬프트로 정의하고, 벗어나면 위반 처리

• Prompt(허용 주제) + Threshold
  활용: 고객상담 봇이 “법률/의료/정치 선동/해킹 지시” 등으로 튀는 걸 제어

URLs (URL 정책)

기본적으로 URL을 위반으로 탐지하고, 예외 허용(allowlist) 가능

• Block All URLs Except: 허용할 URL 리스트
• Allowed Schemes: http/https/mailto 등
• Block userinfo: user:pass@host 형태 차단(크리덴셜 인젝션 방지)
• Allow subdomain: 서브도메인 허용

Custom (사용자 정의, LLM 기반)

“무례한 표현”, “규정 위반 안내”, “브랜드 톤 위반”, “허위/과장 광고” 등 조직 맞춤 규칙을 프롬프트로 정의

• Name / Prompt / Threshold

Custom Regex (사용자 정의 정규식)

특정 패턴(예: 내부 키 포맷, 사번, 티켓번호, DB 커넥션스트링)을 정규식으로 탐지

• Sanitize 모드에서 ‘Name’이 placeholder로 치환됩니다.

“어디에 두면 좋은가?” 대표 아키텍처 패턴

패턴 1: 입력 보호(Pre-LLM) — Sanitize → (필요시) Violations

사용자가 적어 넣은 텍스트에서 PII/시크릿/URL을 먼저 마스킹 → 모델로 전달

• 장점: 유출 자체를 원천 차단
• 추천: 고객상담/내부 헬프데스크/티켓 자동화에 기본 탑재

패턴 2: 출력 보호(Post-LLM) — Violations로 “나갈 말” 검사

모델이 만든 답변을 사용자에게 보내기 전에

• NSFW / 정책위반 / 범위이탈 / URL 포함 여부 등을 검사
• 걸리면 Fail로 보내 수정 재요청(자동 재작성) / 수동 승인(HITL) 흐름 구현

패턴 3: 이중 가드(권장) — Pre + Post

입력에서 유출 막고, 출력에서 사고 막는 “샌드위치” 구조가 가장 안전합니다.

실전 설정 예시

Topical Alignment 프롬프트 예시(업무 스코프)

(예) “사내 보안 헬프데스크” 스코프

• 허용: 계정/권한 요청 절차, 보안 정책 안내, 로그 수집 방법, 보안툴 사용 가이드
• 금지: 악성코드 제작, 침투 방법 상세 지시, 크리덴셜 공유 유도, 고객정보 요청

➡️ Topical Alignment Prompt에 위 내용을 정책 문장 형태로 넣고, Threshold를 중간~높게 둔 뒤 튜닝합니다.

URLs allowlist 운영 예시

“우리 회사 도메인과 공인 벤더만 허용”

• Block All URLs Except: pages.kr, docs.n8n.io, (사용하는 도메인)
• Allowed Schemes: https 중심
• Block userinfo: ON
• Allow subdomain: 필요 시 ON

Custom Regex 예시(보안 관점)

아래는 “형태” 예시입니다(조직 포맷에 맞게 조정하세요).

• Private key 흔적
  • Name: PRIVATE_KEY
  • Regex: -----BEGIN (RSA|OPENSSH|EC|DSA|PRIVATE) KEY-----
• Connection string 흔적
  • Name: CONNECTION_STRING
  • Regex: (Server|Host|Data Source)\s*=\s*[^;]+;.*(Password|Pwd)\s*=\s*[^;]+;
• 사번/티켓 패턴
  • Name: EMP_ID / TICKET_ID
  • Regex는 사내 규칙에 맞춰 구성

Fail 브랜치 설계

“막는 것”보다 중요한 게 막힌 다음 처리입니다.

• Fail → Slack/메일 알림(요약만, 원문 노출 최소화)
• Fail → 티켓 생성(원문은 암호화 저장 또는 접근제어)
• Fail → Human-in-the-loop 승인(관리자 확인 후 재전송)
• Fail → “안전한 형태로 재작성”을 LLM에 재요청(단, 재요청에도 Guardrails 재적용)

보안 관점 체크리스트

기본 원칙

1) LLM에 원문(PII/시크릿)을 보내지 않는다 → Sanitize 우선
2) 사용자에게 나가기 전 출력 검열 → Violations 후단
3) 허용 범위(Topical Alignment)를 문장으로 명시하고, 예외처리 절차를 둔다

운영 점검

1) 임계값(Threshold) 변경 이력 관리(언제/왜 완화했는지)
2) 오탐/미탐 샘플 수집 → 월 1회 룰 튜닝
3) Fail 로그에 민감 원문을 그대로 남기지 않기(마스킹/암호화/접근통제)

위험 시나리오 대응

1) “시크릿이 탐지되면” → 즉시 폐기/회전(rotate) 프로세스 연결
2) “userinfo URL 탐지되면” → 크리덴셜 인젝션 시도로 분류하고 알림 강화

자주 생기는 함정(실무 팁)

1) JSON/객체를 그대로 넣으면 의도치 않게 문자열화/누락이 생길 수 있어요 → 필요 시 JSON.stringify()로 명시적으로 텍스트화 후 검사하는 패턴이 실무에서 쓰입니다.
2) Keywords를 과하게 넣으면 정상 흐름이 자주 Fail로 떨어집니다 → 짧게 시작해서 점진 확장이 좋습니다.
3) Topical Alignment는 프롬프트 품질이 곧 정책 품질입니다 → “허용/금지/예외 처리”를 문장으로 명확히 쓰세요.

추천 “기본 세트”

입력(Pre-LLM): Sanitize Text

• PII(All 또는 Selected)
• Secret Keys(Balanced)
• URLs(필요 시)
• Custom Regex(사내 키/커넥션스트링)

출력(Post-LLM): Check Text for Violations

• Topical Alignment(업무범위)
• Jailbreak(입력에도 적용 가능)
• URLs(외부 링크 정책)
• Custom(조직 톤/정책)