안전, 거부, 폴백

중급

프로덕션에서, 당신의 코드는 Claude가 예상대로 답하지 못하는(또는 안 하는) 경우를 처리해야 합니다. 잘하면 사용자에게 보이지 않고, 못하면 크래시나 혼란스러운 응답이 됩니다.

What you'll learn

모델 거부와 분류기/안전 차단을 구분 — 그리고 왜 그것이 중요한지
거부를 크래시나 빈 응답 대신 정상 결과로 처리
원하지 않은 거부는 줄이되, 원한 거부를 탈옥하려 하지 않기
폴백 선택: 명확화 질문, 안전한 대안, 또는 사람에게 인계

두 가지 서로 다른 것

모델 거부 — Claude가 요청을 거절합니다(예: 유해하다고 판단). 응답이 이를 신호로 보냅니다(일반적으로 refusal stop_reason/콘텐츠). 오류가 아닌 정상 결과로 취급하세요.
분류기/안전 차단 — 별도의 안전 계층이 콘텐츠를 차단할 수 있습니다. 이는 모델 거부와 다르게 보일 수 있습니다.

어느 쪽을 받았는지 아는 것이 맹목적으로 재시도하는 대신 적절히 대응하게 해줍니다.

우아하게 처리하기

resp = client.messages.create(...)
if getattr(resp, "stop_reason", None) == "refusal":
    # Don't show a raw/empty result. Offer a safe fallback or a clarifying ask.
    show_user("I can't help with that as asked. Here's what I can do instead…")
else:
    render(resp)

원하지 않은 거부 줄이기

정당한 맥락을 추가하세요. 요청이 민감한 무언가에 패턴 매칭될 수 있지만 의도가 무해할 때, 실제 정당한 목적을 진술하는 것이 도움이 됩니다.
구체적으로. 모호하거나 도발적인 표현은 조심을 부릅니다.
싸우지 마세요. 요청이 정말로 허용되지 않는다면 거부는 옳습니다 — 우아한 경로를 설계하되, 탈옥하지 마세요.

정당한 맥락을 앞에 두기

I am a security engineer at [company] reviewing our own authentication code
before a release. Below is a function we wrote and own.

Identify weaknesses in it and explain how an attacker would exploit each one,
so we can fix them before we ship.

[code]

폴백 패턴

명확화 질문 대신 막다른 골목.
안전한 대안("대신 공개 정보를 요약할 수 있습니다").
파이프라인에서는, 신뢰도/자격이 낮을 때 사람에게 라우팅.

Guided walkthrough1 of 4

렌더링하기 전에 응답에서 거부 신호를 검사하세요. 검사되지 않은 응답을 UI에 바로 넣지 마세요 — 그것이 사용자가 빈 상자나 원시 객체를 보게 되는 방식입니다.

스스로 확인해 보세요

0/3

코드가 Claude에서 거부를 돌려받았습니다. 이를 다루는 올바른 방법은?
무해한 요청이 계속 거부됩니다. 먼저 시도할 일은?
모델 거부를 받았는지 분류기/안전 차단을 받았는지가 왜 중요합니까?

Key takeaways

거부는 오류가 아닌 결과입니다 — 렌더링 전에 항상 감지하세요.
모델 거부와 분류기 차단은 서로 다른 것입니다; 어느 쪽을 받았는지 식별하세요.
원치 않는 거부는 보통 정당한 맥락을 추가하고 구체적으로 만들면 줄어듭니다.
요청이 정말로 허용되지 않는다면 거부는 옳습니다 — 탈옥하지 말고 우아한 경로를 만드세요.
폴백 순서: 명확화 질문, 안전한 대안, 사람에게 인계.

두 가지 서로 다른 것​

우아하게 처리하기​

원하지 않은 거부 줄이기​