Safety 정책 | CannotBeHidden

1. 서문

앞선 글에서는 Safety 정책과 폴백·쿠션멘트 설계를 다뤘습니다.
이번에는 이 요소들이 RAG 파이프라인 속에서 어떻게 연결되는지를 이야기하려 합니다.

먼저 간단히 복습하자면:

LLM (Large Language Model): 대규모 언어 모델. 질문을 이해하고 답변을 생성하는 엔진
RAG (Retrieval-Augmented Generation): LLM이 답변을 생성하기 전, 검색으로 근거 자료를 찾아 활용하는 최신화 프레임워크
→ 즉, “검색 기반 + 생성형”을 결합해 답변의 신뢰도를 높이는 방식입니다.

파이프라인 자체는 개발팀이 주도적으로 설계·구현했지만,
제가 맡은 역할은 그 흐름이 사용자 경험 차원에서 안정적으로 작동할 수 있도록 기준과 필요사항을 정의하는 것이었습니다.

2. RAG 파이프라인 개요

RAG는 보통 다음 단계를 거칩니다:

Input 처리 – 사용자 발화 전처리
Retriever – 검색 및 문서 매칭
Augment – 검색 결과 정제 및 후보 선택
Generator – LLM 응답 생성
Output Post-processing – 응답 후처리 및 검증

이 중 기획자의 역할은 각 단계에서 “어떤 경우를 어떻게 처리할지” 기준을 제공하는 것입니다.

3. 단계별 기획자의 터치포인트

각 단계는 개발팀이 주도적으로 구현했지만,
기획자는 사용자 경험 관점에서 기준을 정의하는 역할을 했습니다.

단순 요약이 아니라, 실제로 어떤 일이 일어나는지를 예시와 함께 풀어보겠습니다.

① Input (전처리 & Safety 1)

개발팀: 언어 탐지, 금칙어/개인정보(PII) 검출, 입력 포맷 정규화
기획:
- 미지원 언어 → “현재 한국어만 지원합니다. 다시 입력해 주세요.”
- 특수문자/형식 오류 → “입력하신 문구를 확인해 주세요.”
- 금칙어/불법 발화/개인정보 → “안전한 서비스 제공을 위해 해당 내용은 안내드릴 수 없습니다.”
- 계정/결제 등 사람 개입 필요 → 상담사 이관

👉 핵심은 차단/재시도/이관 플로우를 정의하는 것입니다. 이렇게 해야 사용자 경험을 보호하고 시스템 자원도 절약할 수 있습니다.

② Retriever (검색/매칭)

개발팀: 쿼리 빌드, 인덱스 검색, 스코어링, Top-K 후보 산출
기획:
- IDK (도메인 안인데 답 없음) vs OOD (도메인 밖 질문) 구분
- 검색 신뢰도 임계치(Threshold) → 기준 이상 = 답변 생성, 기준 이하 = 추천 리스트 제공
- 소스 우선순위 = 공식 문서 > 공지 > 커뮤니티

👉 임계치는 초기엔 개발팀이 임의로 정했지만, 실제 운영에서는 “언제 답변을 막고 언제 추천으로 돌릴지”가 사용자 경험에 직결됩니다.

📦 Top-K & Score Threshold란?

Top-K Retrieval: 검색 결과 중 상위 K개만 가져오는 방식.
예: 200개 검색 → 상위 5개만 선택 = Top-5. (보통 K=3~10)
Score Threshold(임계치): 검색 결과의 유사도 점수(score)가 기준 T 이상일 때만 “신뢰 가능”으로 간주.
예: 0.85 ≥ 0.8 → 답변 생성
예: 0.55 < 0.8 → “정확한 답변을 찾지 못했습니다. 대신 [추천 리스트]를 확인해 주세요.”
왜 기획자가 알아야 할까? 이 값들은 사용자 경험에 직접 영향을 주는 값이기 때문입니다.
예: T가 너무 높으면 → 답변이 자주 막힘
예: T가 너무 낮으면 → 엉뚱한 답변까지 노출

③ Augment (컨텍스트 구성)

개발팀: Top-K 결과 중 프롬프트에 넣을 자료 정제
기획:
- 최신 자료/공식 자료 우선 순위 설정 (이번 달 공지 > 작년 글, 공식 FAQ > 커뮤니티)
- 중복 제거 (비슷한 문서 여러 개일 경우 1개만 남김)
- 신뢰도 낮음 → 다운그레이드 응답 (“정확한 답변은 제공되지 않습니다. 대신 [공식 문서]를 참고하세요.”)

👉 즉, 어떤 자료를 남기고/빼고, 불충분할 때 어떻게 보여줄지를 정하는 단계입니다.

④ Generator (LLM 생성)

개발팀: 프롬프트 구성 및 LLM 호출
기획:
- 브랜드 톤·쿠션멘트 정의
  - 게임 = 친근/재밌게 (“이 부분은 아직 준비되지 않았어요 😅”)
  - 금융 = 단정/공식 (“현재 해당 정보는 제공되지 않습니다.”)
- 신뢰도 낮음 → 정중 거절 + 대체 링크 안내
- 프롬프트 가드레일
  - 범위 벗어난 질문은 거절
  - 모르면 IDK
  - 출처 없이 단정 금지

👉 답변 자체는 모델이 생성하지만, “어떤 톤과 규칙 안에서 말하게 할지”는 기획이 정합니다.

⑤ Output (후처리 & Safety 2)

개발팀: 최종 응답 필터링, 금칙어/민감정보 제거, 마스킹 처리
기획:
- 차단 발생 시 대체 문구 정의
  - “안전한 서비스 제공을 위해 일부 내용은 표시되지 않습니다.”
- 필요 시 공식 링크/상담 버튼 제공
- 책임 문구/출처 표기 여부 결정

👉 Output은 마지막 안전망입니다. Input에서 걸러지지 않은 리스크가 여기서 최종적으로 검수됩니다.

5. 경험담 & 마무리

처음엔 “개발팀이 기술적으로 잘 만들겠지”라고 생각했습니다.
하지만 막상 업무를 진행하다 보니, 사용자 안내 기준이 빠진 채로는 파이프라인이 온전히 작동하지 않는다는 걸 알게 되었습니다.

결국 기획자의 역할은 직접 파이프라인을 설계하는 것이 아니라,
각 단계가 사용자 경험 차원에서 일관되게 동작하도록 기준과 필요사항을 정의하고 정리하는 것이었습니다.

겉으로 보면 RAG 파이프라인은 기술 중심 프로세스처럼 보입니다.
그러나 실제로는 Safety 정책, 폴백, 쿠션멘트 같은 사용자 경험 설계가 파이프라인 속에 녹아 있어야 비로소 서비스가 제대로 굴러갑니다.

결국 기획자는 기술의 빈 공간을 채우는 사람이 아니라,
서비스 전체가 일관된 경험을 주도록 연결해주는 역할을 맡습니다.

P.S.

RAG 2.0이 아직 일반화되지도 않았는데, 벌써 RAG 3.0이 논의될 정도로
AI는 지금도 하루가 다르게 발전하고 있습니다.

따라서 지금의 RAG 파이프라인 구축은 어디까지나 하나의 프레임워크이자 레퍼런스일 뿐입니다.
앞으로 새로운 기술 트렌드에 맞춰 계속 진화할 것이고,
기획자는 급변하는 흐름 속에서 유연하게 기준과 해결책을 설계하는 태도를 가져야 할 것입니다.

1. 서문

챗봇 기획에서 폴백(Fallback) 과 쿠션멘트(Cushion Message) 는 단순한 보조 장치가 아닙니다.
서비스가 복잡해질수록 이 두 장치는 사용자 경험을 지키는 안전망이 됩니다.
저는 CS 챗봇 시절부터 AI 챗봇까지 이어지는 과정에서 이 두 요소를 어떻게 설계·운영했는지를 경험했고, 그 과정에서 얻은 시행착오와 교훈을 공유하고자 합니다.

2. 타임라인: Rule 기반 → AI 기반

CS 챗봇 (Rule-Based)

매칭 실패 → 폴백 동작 or 무조건 상담사 연결
폴백과 쿠션멘트의 구분이 명확했음

AI 챗봇 (LLM + RAG 도입)

단순 실패가 아니라, 다양한 케이스가 발생
- 검색은 됐는데 결과 신뢰도가 낮음
- 답변 후보가 너무 많음
- 외부 도메인 질문이 들어옴 등
결국 “각 케이스별로 사용자에게 어떻게 안내할 것인가?”라는 복잡도가 급격히 늘어남

👉 여기서 중요한 개념이 I.D.K vs. O.O.D

IDK (I Don’t Know): 챗봇이 “내가 모른다”를 스스로 인지하는 상황 (답변 범위 안인데 답을 못 찾음)
OOD (Out of Domain): 아예 서비스 영역 밖의 질문이 들어온 상황 (예: 게임 가이드 챗봇인데 ‘날씨 어때?’ 물어봄)
이 둘을 구분하지 않으면, 같은 폴백으로 처리되어 사용자 경험이 무너집니다.

3. 매칭 구분표 작성

AI 챗봇에서 가장 어려웠던 부분은, 이 다양한 케이스를 기술·운영·기획이 이해할 수 있는 “매칭 구분표”를 정의하는 일이었습니다.

실제 구분표(단순화 예시)

구분	케이스	처리 기준	사용자 노출
IDK	FAQ 범위 내, 매칭 실패	유사 질문 추천	쿠션멘트 + 추천 리스트
OOD	FAQ 범위 밖 질문	폴백 → 종료/이관	쿠션멘트 + 상담 안내
RAG Low Score	검색결과 신뢰도 낮음	답변 차단	쿠션멘트 + 공식 링크

효과
- 혼선 제거 → 기획/개발/운영이 같은 기준을 공유
- 개발 속도 향상 → 케이스별 기준이 명확해 구현 지연 최소화

4. 최종 구조도 & 사용자 안내 예시

챗봇 질문이 들어오면, 아래 흐름처럼 6가지 케이스로 분류 후 처리됩니다.
(단순화 된 예시입니다.)

구분	케이스	처리 기준	사용자 안내(쿠션/블럭 예시)
SAFETY 차단	비윤리 발화/금칙어/현금거래 등	즉시 차단(선차단) + 로그	“안전한 서비스 제공을 위해 해당 내용은 안내드릴 수 없습니다.” 필요 시: “정확한 내용은 {official_link}에서 확인해 주세요.”
입력 부적합‧미지원 언어	미지원 언어, 특수기호/형식 오류	언어 탐지/형식 검증 → 안내 후 재시도	미지원 언어: “죄송합니다. 해당 언어는 현재 지원하지 않습니다.” 형식 오류: “지원하지 않는 문자입니다. 다시 입력해 주세요.”
OOD (Out of Domain)	도메인 밖 질문·일상대화·의미 없는 발화	LLM 기반 폴백(종료 또는 재질문 유도)	“안녕하세요! 저는 {ip_name} {bot_scope} 정보를 안내하는 AI입니다. {bot_scope} 관련 질문을 해 주세요.”
도메인 내이지만 챗봇 처리 불가	계정/결제/신고 등 사람 개입 필요	초동수사/상담 이관	“이 요청은 챗봇이 처리하기 어려워 상담사에게 연결해 드릴게요.” (상담사 바로 연결 or 버튼 제공)
IDK (검색 실패/저신뢰)	자료 없음·오래됨·커뮤니티 글 등	응답 차단 + 쿠션멘트 + 추천/링크 안내	“질문 범위는 맞지만 적합한 답변을 찾지 못했습니다. 대신 도움이 될 수 있는 항목을 안내드릴게요: {추천_리스트}” “정확한 정보는 {official_link}에서 확인해 주세요.”
정상 응답	검색·생성 정상	정상 RAG 응답 생성	일반 답변 제공 (RAG 환각을 감안하여, 부정확할 수 있음을 쿠션멘트로 안내)
출력 체크(2차 SAFETY)	생성 응답에 금칙어/민감 정보 포함	후처리 차단/마스킹	“안전한 서비스 제공을 위해 일부 내용은 비공개 처리되었습니다.”

5. 협업 포인트 (R&R)

프로젝트 리딩 = PM
서비스 리딩 = 기획
사용자 접점 최종 결정 = 운영실
→ 즉, 기획자가 초안을 설계하되 최종 컨펌은 운영실이 맡았습니다.

구조/플로우: 기획자가 주도
사용자 톤·멘트: 운영실이 최종 결정
→ 실제로도 약 80% 이상은 운영실이 최종 톤을 확정했고, 기획자는 시스템적 일관성을 맞추는 역할에 집중했습니다.

6. Tip & 시행착오

제가 직접 겪으면서 깨달은 몇 가지 포인트입니다.

기획자의 핵심 역할
복잡한 내용을 단순화하여, 가시성을 제공하고 팀이 속도를 낼 수 있도록 돕는 것.
기획은 결국 ‘지도’와 같은 역할이라는 점을 다시 한 번 확인했습니다.
RAG 파이프라인 도입 시 복잡도 폭발
설계 초기부터 기술팀과 협의하며, 폴백 & 쿠션멘트 정의를 동시에 진행했어야 했습니다.
초반엔 따로 움직이다 보니 기준이 꼬였고, 나중에 통합 정리하는 데 시간을 더 썼습니다.

폴백과 쿠션멘트는 사용자 경험의 시작이자 마지막 방어선입니다.
특히 Rule 기반 → AI 기반으로 넘어가면서 복잡도가 커질수록, 기획자가 기준을 정리하고 협업 구조를 잡아주는 역할이 필수적이었죠.
결국 기획자가 길을 정리해주고, 개발팀이 빠르게 구현하고, 운영실이 최종 목소리를 결정하는 구조가 가장 효율적이었습니다.

P.S. 🙂

요즘 AI가 하루가 다르게 빠르게 발전하고 있습니다.
모든 내용은 단순한 경험과 프레임워크의 참고서일 뿐이며, 실제 진행 방식은 언제든지 바뀔 수도 있고 더 효율적인 방식으로 진화되어야 합니다.

실무에서 바로 쓰는 AI 챗봇 Safety 정책

서문

이전 글에서 Safety 정책을 개념 수준으로 다뤘지만,
실제 서비스 도입 시에는 정책의 깊이와 디테일이 서비스 품질에 직접적인 영향을 줍니다.

제가 처음 Safety 정책을 접한 건 CS 챗봇 구축 시 Fallback 시나리오 설계 단계였습니다.
그 당시, 비윤리 발화나 악성 발화를 걸러내는 기본 카테고리를 Fallback으로 제공했고,
이것이 나중에 LLM 챗봇에서 말하는 Safety 정책과 동일하다는 것을 뒤늦게 알게 됐죠.

이러한 기본적인 스펙은 내부적으로 #Safety 기본 스펙으로 정의했고,
프로젝트 특성에 맞춰 #Safety 특화 스펙을 추가로 정의하였습니다.
두 가지 모두 정의 및 구축이 필요하며,
LLM 챗봇 도입 당시 저는 특히 Safety 특화 스펙 설계에 집중했습니다.

Safety 정책의 목적

챗봇 도입 시 선택이 아닌 필수 요소로, 사용자와 서비스 공급자 모두를 보호합니다.

리스크 최소화: 법적 문제, 브랜드 이미지 손상, 사용자 피해 방지
사용자 신뢰 확보: 안전하게 설계된 챗봇은 재방문·재사용 의도를 높임
내부 규제 준수: 게임, 금융, 의료 등 도메인별 필수 규제 대응

Safety 기본 스펙

CS 챗봇 시절부터 운영해 온 범용 안전 정책입니다.
대부분의 서비스에 적용 가능하며, LLM 도입 후에도 유지·보완됩니다.
특히 ‘아동/청소년 성착취’, ‘혐오 & 차별’ 등과 같은 민감하고 주요한 주제는 별도로 심도있게 정책 구성 및 검토, 사후 테스트가 필요합니다.

카테고리	설명
폭력 범죄	살인, 폭행 등 물리적 위협 발언
비폭력 범죄	사기, 절도, 해킹 등
성범죄	성희롱, 성폭행, 불법 촬영 등
아동/청소년 성착취	미성년자 관련 성적 발언
명예 훼손	허위사실 유포
전문적 조언	법률, 의료, 금융 등 전문 자문
개인정보 & 사생활	주민번호, 계좌번호, 주소, 전화번호 등
지식재산 & 저작권	불법 복제, 저작물 무단 사용
무차별적/대량살상무기	폭발물, 생화학무기 등
혐오 & 차별	인종, 성별, 종교 등 차별 발언
자살 & 자해	자해, 자살 시도 관련 발언
선거 & 정치적 편향	특정 정당·후보 지지/비방
선정성 & 성적 콘텐츠	노골적인 성적 묘사
부적절한 언어 & 폭언	욕설, 비속어
프롬프트 주입 공격	모델 조작 시도

Safety 특화 스펙

LLM 챗봇 기획에서 추가로 정의한 게임 서비스 전용 정책입니다.

카테고리	설명
당사 가치 평가	회사에 대한 긍정/부정 평가
임직원·특정인 평가/인신 공격	특정인 비방
게임 서비스 가치 평가	품질·운영에 대한 평가
유료 재화 가치 평가	과금 정책 평가
유저·그룹 간 인신 공격	길드, 팀, 국가 등 단위 비난
운영 정책·CS 대응 발언	고객센터, 운영 정책 불만
게임 내 편법/금지 행위	버그, 어뷰징, 불법 프로그램
내부 개발 정보 문의	비공개 개발 진행·기술 문의

Safety 특화 스펙 사례 – 게임 내 편법/금지 행위 발언

허용: 공식 기능 설명, 이용 제한 기준 안내
금지: 매크로, 자동사냥, RMT, 버그 악용 등

✅ 허용 예시

질문	응답
자동사냥은 지원돼?	일부 콘텐츠에서는 공식 지원 자동 전투 기능이 있습니다.
거래소 이용 조건은?	특정 레벨 이상부터 거래소 이용이 가능합니다.
버그 악용 신고는 어디서?	홈페이지 고객센터를 통해 신고 가능합니다.

⛔ 금지 예시

질문	유형	차단 방식	응답 예시
매크로 없이 돌림판 못 돌려?	편법 문의	프롬프트 차단	해당 표현은 사용할 수 없습니다.
스킬 하나에 100만 원?	비아냥	응답 차단	불편 사항은 고객센터로 접수 부탁드립니다.
각신수도끼 팝니다	현금거래	프롬프트 차단	해당 표현은 사용할 수 없습니다.

차단 방식 설계

프롬프트 차단 (Input Filtering)

입력 단계에서 금칙 카테고리 감지 → 메시지 삭제 + 차단 안내
예: “해당 표현은 사용할 수 없습니다.”
장점: 모델 호출 불필요, 속도 빠름
적용: 명확한 위반 키워드(예: ‘현금거래’, ‘매크로’)

응답 차단 (Output Filtering)

모델이 응답 생성 후, 위험 요소 포함 시 사전 정의 메시지로 대체
예:
사용자: “스킬 하나에 100만 원?”
→ LLM 생성 → “서비스 문의는 고객센터로 접수 부탁드립니다” 출력
장점: 문맥 기반 발언 필터링 가능

혼합 전략

고위험: 프롬프트 차단
중·저위험: 응답 차단
필요 시 계단식 필터링(프롬프트 → 응답 → 쿠션멘트) 설계

기획자의 고민과 역할

Safety 정책은 그냥 막는 것이 아니라,
브랜드 신뢰를 지키면서도 대화 흐름을 유지하는 설계입니다.

기본 스펙만 적용 시: 게임 특수 발화 반영 안 됨 → 특화 스펙 추가
딱딱한 차단 문구: 사용자 불만 증가 → 쿠션멘트 삽입
오탐/미탐 로그 분석: 차단 조건·문구·시나리오 지속 개선

결론
범용 스펙 + 특화 스펙은
서비스 도메인을 가장 잘 아는 기획자가 주도해야 하며,
LLM 서비스의 핵심 중 하나입니다.

[태그:] Safety 정책

AI 챗봇, RAG 파이프라인 속 기획자의 역할

1. 서문

2. RAG 파이프라인 개요