NxtCloud NxtCloud Workshop / Bedrock RAG: 콘솔부터 직접 구현까지
로그인

Lab 02: Guardrail 적용

학습 흐름

Lab 01에서 Knowledge Base를 만들어 문서 기반 질의응답을 체험했습니다. 이번 Lab에서는 그 위에 Guardrail(안전장치) 를 얹습니다.

  1. Guardrail을 만든다 → 검증: Bedrock 콘솔에 내 Guardrail이 보이고 버전이 생성됨
  2. KB Test에 Guardrail을 연결한다 → 검증: 테스트 설정에 Guardrail 이름+버전이 적용됨
  3. 같은 질문을 적용 전/후로 던져 비교한다 → 검증: 정상 질문은 통과, 차단 대상은 차단 문구 출력
  4. 과차단(false positive)을 관찰한다 → 검증: 막히지 말아야 할 질문이 막히는 경우를 메모

이번 Lab은 코드 없이 콘솔 클릭만으로 진행합니다. 리전은 Lab 01과 동일하게 us-east-1(N. Virginia) 이며, 루트 사용자가 아닌 IAM 사용자로 접속합니다.

⚠️ 한국어 실습 전제 — Standard 티어 필수. 이 Lab은 한국어로 질문을 던집니다. Bedrock Guardrails의 콘텐츠 필터와 금지 주제는 Standard 티어(Safeguard tier)에서만 한국어를 평가합니다(Classic 티어는 영어·프랑스어·스페인어만 지원). 가드레일을 만들 때 반드시 Standard 티어를 선택하세요 — 그러지 않으면 한국어 입력이 그대로 통과해 “차단이 안 되는” 현상이 생깁니다.

학습 목표
  • AI 시스템에 안전장치가 왜 필요한지, Guardrail이 무엇을 막아 주는지 이해합니다
  • 콘텐츠 필터 5개 범주와 강도(None/Low/Medium/High)의 의미를 이해하고 직접 설정합니다
  • 금지 주제(Denied topics)와 민감정보(PII) 필터의 역할을 이해합니다
  • Guardrail을 Knowledge Base 테스트에 적용하고, 같은 질문으로 적용 전/후를 비교합니다
  • “안전 vs 사용성”의 트레이드오프와 과차단(false positive)을 직접 관찰하고 메모합니다
Guardrail의 개념과 필요성

RAG 시스템을 만들면 AI는 우리가 넣어 준 문서를 근거로 그럴듯한 답을 잘 만들어 냅니다. 그런데 “잘 만든다”는 것과 “안전하게 만든다”는 것은 다른 문제입니다. 사용자는 욕설을 섞어 입력할 수도 있고, 시스템 프롬프트를 무력화하려는 공격적인 입력(프롬프트 인젝션)을 시도할 수도 있으며, AI가 답변에 개인정보를 그대로 노출하거나 회사가 책임질 수 없는 조언(예: 개인화된 투자 권유)을 할 수도 있습니다.

Guardrail은 AI의 입력(프롬프트)과 출력(응답) 사이에 두는 안전장치입니다. 모델 자체를 바꾸지 않고, 모델 앞뒤에 정책 기반 검사를 끼워 넣어 위험한 입력을 막거나 위험한 출력을 차단·마스킹합니다. 핵심은 이 모든 것을 코드 없이 정책(policy)으로 건다는 점입니다.

Guardrail이 다루는 대표적인 위험은 다음과 같습니다.

위험Guardrail의 대응
유해 콘텐츠(증오/모욕/성적/폭력/위법)콘텐츠 필터로 강도별 차단
프롬프트 공격(인젝션, 탈옥)프롬프트 공격 필터로 차단
책임질 수 없는 주제(투자 조언 등)금지 주제(Denied topics)로 차단
개인정보 노출(이메일/전화 등)민감정보(PII) 필터로 마스킹/차단
환각(맥락에 없는 내용 생성)맥락 근거 검사(Contextual grounding)

💡 왜 모델 밖에 두는가? 모델을 재학습하거나 프롬프트를 매번 길게 쓰는 대신, 정책을 한 번 정의해 여러 애플리케이션에 재사용할 수 있기 때문입니다. Guardrail은 하나 만들어 두면 KB, 일반 대화, 에이전트 등 여러 곳에 똑같이 붙일 수 있습니다.

Guardrail이 동작하는 위치

Guardrail은 사용자 입력과 모델, 그리고 모델 응답 사이의 양방향에서 동작합니다. 입력 단에서는 들어오는 프롬프트를 검사해 정책 위반이면 모델에 전달조차 하지 않고 차단 문구를 돌려줍니다. 출력 단에서는 모델이 생성한 응답을 검사해 위반이면 차단하거나 민감정보를 가립니다.

graph LR
  A["사용자 질문"] --> B{"Guardrail<br/>입력 검사"}
  B -->|통과| C["모델 / KB"]
  B -->|위반| X["차단 문구"]
  C --> D{"Guardrail<br/>출력 검사"}
  D -->|통과| E["정상 답변"]
  D -->|위반| X

이 구조 때문에 같은 질문이라도 Guardrail 적용 전에는 답이 나오고, 적용 후에는 차단 문구가 나오는 차이를 만들 수 있습니다. 이번 Lab의 핵심 실습이 바로 이 “전/후 차이”를 직접 만들어 눈으로 확인하는 것입니다.

Step 1: Guardrail 생성 — 이름과 차단 메시지

Bedrock 콘솔 좌측 내비게이션에서 GuardrailsCreate guardrail 를 누릅니다. 첫 화면(“Provide guardrail details”)에서 Guardrail의 기본 정보를 입력합니다.

  • Name: 본인 것을 알아볼 수 있게 짓습니다(예: rag-user-01-guardrail).
  • Messaging for blocked prompts: 입력이 차단됐을 때 사용자에게 보여줄 문구입니다. 예: 죄송합니다. 해당 요청은 정책상 답변할 수 없습니다.
  • Apply the same blocked message for responses 를 체크하면, 출력(응답)이 차단될 때도 같은 문구를 씁니다. 실습에서는 체크해 둡니다.
  • Cross-Region inference를 활성화합니다. (체크)

입력 후 Next 를 누릅니다.

Guardrail 생성 첫 화면 — Name, 차단 메시지 입력과 Apply the same blocked message for responses 체크

차단 메시지는 사용자가 실제로 보게 되는 문구입니다. 너무 기술적인 표현(“Policy violation: HATE filter triggered”)보다, 정중하고 모호한 안내 문구가 실제 서비스에서는 더 안전합니다. 차단 사유를 너무 자세히 알려 주면 공격자가 우회 방법을 찾는 단서가 되기 때문입니다.

Step 2: 콘텐츠 필터 — 5개 범주와 강도

다음 화면 Configure content filters 에서 유해 콘텐츠를 거르는 필터를 설정합니다.

  1. Content filter tier(보호 등급)에서 Standard를 선택합니다 — 한국어 입력을 평가하려면 반드시 Standard여야 합니다. (이 티어 설정은 금지 주제에도 함께 적용됩니다.)
  2. Configure harmful categories filter 를 선택하고 Text 를 체크합니다.
  3. 5개 범주 각각에 대해 강도를 None / Low / Medium / High 중에서 고릅니다. 강도는 프롬프트(입력)응답(출력) 에 대해 따로 설정할 수 있습니다.
  4. Prompt attacks(프롬프트 공격) 필터도 함께 켜는 것을 권장합니다 — 인젝션/탈옥 시도를 막습니다.
  5. 동작은 Block(차단)을 선택합니다.

실습에서는 5개 범주를 모두 Medium 정도로 둡니다.

범주의미
Hate정체성(인종·종교·성별 등)에 근거한 증오·차별 표현
Insults모욕적·비하적 표현
Sexual성적으로 노골적인 내용
Violence폭력 묘사·조장
Misconduct범죄·불법 행위에 대한 안내

강도의 의미를 직관적으로 이해하면 다음과 같습니다.

  • None — 그 범주는 거르지 않습니다(필터 끔).
  • Low — 아주 명백한 위반만 차단합니다. 통과가 많아 사용성은 높지만, 놓치는 경우가 생깁니다.
  • Medium — 균형점. 실습 기본값.
  • High — 조금이라도 의심되면 차단합니다. 가장 안전하지만, 멀쩡한 질문까지 막히는 과차단(false positive) 이 늘어납니다.

입력 후 Next 를 누릅니다.

Configure content filters — Safeguard tier Standard, 5개 범주 강도 Medium, Prompt attacks 켜짐, Action Block

강도를 높일수록 안전하지만 멀쩡한 대화까지 막힙니다. 이 절충이 바로 이번 Lab의 핵심 주제인 “안전 vs 사용성” 트레이드오프입니다. 정답은 없으며, 서비스의 성격(아동 대상인지, 의료인지, 사내 도구인지)에 따라 다르게 잡아야 합니다.

Step 3: 금지 주제

특정 콘텐츠 범주가 아니라 주제 자체를 막고 싶을 때 사용합니다. 콘텐츠 필터(증오·모욕 등 유해성)로는 정중한 투자 질문을 막을 수 없으므로, “투자 조언”처럼 유해하지는 않지만 책임질 수 없는 주제는 금지 주제로 다뤄야 합니다. 이것이 Step 6 차단 데모의 핵심이므로 꼭 추가합니다.

Add denied topic 을 눌러 다음을 입력합니다.

  • Name: Investment Advice — 이름은 주제를 가리키는 명사구로 적고, 설명을 쓰지 않습니다.
  • Definition: 투자 조언은 수익 창출이나 특정 재무 목표 달성을 위해 자금·자산의 운용·배분에 관해 묻거나, 안내하거나, 추천하는 내용입니다. — 지시문(“~를 막아라”)이나 예시가 아닌 완결된 정의문으로 적습니다.
  • Sample phrases(대표 예시 문구, 최대 5개): 한국어 실습이므로 한국어 예시를 2~3개 넣습니다. 짧은 구어체 질문은 정의만으로는 탐지가 약한데, 예시를 넣으면 같은 의미의 변형 질문까지 안정적으로 걸립니다.
    • 이 회사 주식 지금 사도 돼?
    • 지금 아마존 주식 사야 해?
    • 어떤 종목에 투자하면 좋을까?
  • Input / Output: 둘 다 Block(기본값)으로 둡니다 — 입력과 출력 양쪽에서 차단됩니다.
  • Denied topics tier(보호 등급)에서 Standard를 선택합니다 — 한국어 입력을 평가하려면 반드시 Standard여야 합니다.

💡 이 데모가 RAG와 잘 어울리는 이유: 우리 KB에는 아마존 주주서한이 들어 있어, AI가 그 문서를 근거로 “이 주식을 사라”는 식의 조언을 그럴듯하게 만들어 낼 수 있습니다. 금지 주제는 바로 그런 책임질 수 없는 답을 못 하게 막습니다.

나머지 화면은 Skip to Review and create 로 건너뛰고, 내용을 확인한 뒤 Create guardrail 를 누릅니다. (시간이 되면 Sensitive information filters 에서 이메일·전화 같은 PII 마스킹도 켜 볼 수 있습니다 — 선택.)

Denied topics에 Investment Advice 주제와 한국어 sample phrases 입력 화면

금지 주제는 “콘텐츠가 유해한가”가 아니라 “이 주제를 다뤄도 되는가”라는 다른 축의 통제입니다. 유해하지 않아도 회사 정책상 금지할 수 있습니다(법률 조언, 의료 진단, 투자 권유 등). 콘텐츠 필터만으로는 막기 어려운 영역을 보완합니다.

Step 4: 버전 생성

생성이 끝나면 Guardrail 상세 화면에서 Create version 을 눌러 버전(예: 1)을 만들어 둡니다.

Guardrail은 작업 중인 DRAFT(초안)와, 그 시점의 정책을 고정해 둔 버전으로 구분됩니다. KB나 애플리케이션에 적용할 때는 보통 이름 + 버전 을 지정하므로, 적용에 쓸 버전을 미리 하나 만들어 두는 것이 깔끔합니다.

  • DRAFT — 계속 수정되는 초안. 실험·튜닝용.
  • 버전(1, 2, …) — 특정 시점의 정책을 동결한 스냅샷. 운영 적용용.
Guardrail 상세 화면 — Create version 후 Version 1이 목록에 생성된 상태
🎯 체크포인트
  • Safeguard tier를 Standard로 선택했다 (한국어 평가)
  • 콘텐츠 필터 5개 범주를 Medium으로, 프롬프트 공격 필터를 켰다
  • 금지 주제 Investment Advice를 추가했다 (한국어 sample phrases 포함)
  • Guardrail을 생성했고 콘솔 목록에 보인다
  • 버전(예: 1)을 생성했다

정책을 동결하는 이유: 운영 중인 서비스가 DRAFT를 바라보고 있으면, 누군가 초안을 만지는 순간 운영 동작이 갑자기 바뀝니다. 버전을 박아 두면 “이 서비스는 버전 1 정책으로만 동작한다”가 보장됩니다.

Step 5: KB 테스트에 Guardrail 적용

이제 Lab 01에서 만든 Knowledge Base의 Test 패널로 돌아갑니다.

  1. KB 상세 화면 우측의 Test 패널을 엽니다.
  2. 테스트 설정(⚙️ Other configurations) 섹션을 확인합니다.
  3. Guardrails 영역에서 방금 만든 Guardrail 이름 + 버전(예: my-guardrail-01, 버전 1)을 선택합니다.
  4. 모델은 Lab 01과 동일하게 Claude Haiku 4.5를 고릅니다.

이렇게 하면 같은 KB Test 패널에서 Guardrail을 켰다 껐다 하며 같은 질문을 던질 수 있습니다. 전/후 비교의 준비가 끝났습니다.

KB Test 패널의 Configurations → Guardrails에서 Guardrail 이름과 버전이 선택된 상태
Step 6: 적용 전/후 비교 — 정상 질문 vs 차단 대상

핵심 실습입니다. 같은 질문을 Guardrail 끈 상태켠 상태로 각각 던져, 출력이 어떻게 달라지는지 비교합니다.

A. 정상 질문 (통과해야 함)

  • 예: 아마존이 말하는 'Day 1'은 무엇인가?
  • 기대: Guardrail 전/후 모두 정상 답변. Guardrail이 정상 대화를 방해하지 않아야 합니다.

이것이 통과하는 것을 확인하는 이유: Guardrail의 목적은 위험을 막는 것이지, 멀쩡한 사용을 막는 것이 아닙니다. 정상 질문이 막힌다면 그 Guardrail은 실패입니다.

정상 질문 'Day 1' — Guardrail ON 상태에서도 정상 답변이 나온 화면

B. 차단 대상 질문 (적용 후에만 차단)

  • 금지 주제 데모: 이 회사 주식 지금 사도 돼? (앞서 건 Investment Advice 주제에 걸림)
  • 또는 욕설/유해 표현이 섞인 입력
  • 기대: Guardrail 에는 답변이 나오고, 에는 차단 문구(Step 1에서 정한 메시지)가 나옵니다.
질문Guardrail OFFGuardrail ON
”Day 1이 뭐야?” (정상)정상 답변정상 답변
”이 주식 지금 사도 돼?” (투자 조언)답변 시도차단 문구
욕설 섞인 입력답변 시도차단 문구
차단 대상 질문 — Guardrail OFF는 답변, ON은 차단 문구로 막히는 전/후 비교

⚠️ 차단이 안 된다면 다음을 차례로 확인하세요.

  1. 가드레일이 Standard 티어인가? (Classic은 한국어를 평가하지 않아 그냥 통과합니다 — 가장 흔한 원인)
  2. 금지 주제(Investment Advice)를 실제로 추가했고, 한국어 sample phrases를 넣었는가?
  3. KB Test에서 가드레일이 DRAFT가 아닌 버전(예: 1)으로 적용됐는가?
  4. 투자 질문은 콘텐츠 필터(유해성)로는 안 걸립니다 — 반드시 금지 주제로 막아야 합니다.
🎯 체크포인트
  • 정상 질문이 Guardrail ON에서도 정상 답변된다
  • 차단 대상 질문이 Guardrail ON에서만 차단 문구로 막힌다
  • 동일 질문에 대해 전(답변)→후(차단)의 차이를 직접 만들어 봤다
안전 vs 사용성 — 과차단(false positive) 관찰

Guardrail을 강하게 걸수록 위험은 줄지만, 막히지 말아야 할 질문까지 막히는 일이 늘어납니다. 이를 과차단(false positive) 이라고 합니다. 반대로 너무 약하게 걸면 위험한 입력이 새어 나갑니다(이는 false negative). 이 둘 사이의 균형이 Guardrail 설계의 본질입니다.

직접 관찰해 봅니다. 강도를 Medium에서 High로 올려 보거나, 금지 주제의 정의를 넓게(예: “투자”라는 단어만 들어가도 막히게) 잡아 본 뒤, 다음과 같은 경계선 질문을 던져 보세요.

  • 아마존은 왜 자유현금흐름(FCF)을 강조하나? — 투자 관련 단어가 있지만 사실 질의입니다. 막히면 과차단입니다.
  • AWS는 어떻게 시작됐나? — 완전히 정상이어야 합니다.

〔관찰 메모〕 다음을 적어 두세요. 이 메모는 이후 Lab에서 RAG의 한계와 운영 고려사항을 다룰 때 다시 사용됩니다.

  • 어떤 질문이 막히고, 어떤 질문은 통과했는가?
  • 과하게 막히는(false positive) 경우는 없었는가?
  • 그 경우를 줄이려면 강도나 주제 정의를 어떻게 조정해야 하는가?
설정 방향안전사용성위험
강하게(High, 넓은 금지 주제)높음낮음과차단↑ (정상 질문 막힘)
약하게(Low, 좁은 금지 주제)낮음높음누락↑ (위험 입력 통과)

Guardrail에 “완벽한 설정”은 없습니다. 서비스의 위험 허용 범위에 맞춰 강도를 정하고, 운영하면서 막힌 질문 로그를 보고 계속 조정하는 것이 현실적인 운영 방식입니다.

🎯 체크포인트
  • 강도/주제를 조정하며 과차단 사례를 한 번 이상 만들어 관찰했다
  • 안전 vs 사용성 트레이드오프를 관찰 메모로 정리했다
핵심 정리
단계동작콘솔 위치
생성이름 + 차단 메시지 입력Guardrails → Create guardrail
티어Safeguard tier = Standard (한국어 평가)Configure content filters
콘텐츠 필터5개 범주 강도(Medium) + 프롬프트 공격Configure content filters
금지 주제투자 조언 주제 차단 (+ 한국어 sample phrases)Denied topics
PII(선택)이메일/전화 마스킹Sensitive information filters
버전정책 동결 스냅샷 생성Create version
적용KB Test에 이름+버전 연결KB Test → Configurations → Guardrails
비교같은 질문 전/후 비교, 과차단 관찰KB Test 패널

이번 Lab에서 Guardrail은 모델을 바꾸지 않고 정책으로 거는 안전장치이며, 핵심은 “안전 vs 사용성”의 균형이라는 점을 콘솔로 직접 체험했습니다.

🤔 생각해 보기 (다 끝냈다면)
  • 정상적인 질문인데도 **과하게 차단(false positive)**되는 경우를 만들어 볼 수 있나요? 어디서 생길까요?
  • Guardrail로도 막지 못하는 위험은 무엇이 있을까요?

다음 단계

지금까지 Lab 01·02에서 콘솔 클릭만으로 관리형 RAG를 만들고 Guardrail로 안전장치까지 걸어 봤습니다. 콘솔이 “대신 해 주던 일” — 문서 청킹, 임베딩, 벡터 검색, 검색+생성 — 이 실제로 어떻게 동작하는지 궁금할 차례입니다.

Lab 03에서는 이 “마법”의 내부를 들여다봅니다. RAG가 임베딩 + 벡터 검색 + 프롬프트 조립의 합이라는 것을, 이론으로 차근차근 분해해 이해합니다. 이후 Lab에서 같은 과정을 직접 코드로 조립하게 됩니다.