가드레일 달았더니 사용자가 떠났다

우리 팀이 LLM 기반 고객 상담 봇에 가드레일을 본격적으로 달기 시작한 건 올해 1월이었다. 프롬프트 인젝션 사고가 한 번 터지고 나서 경영진이 "당장 막아"라고 했고, 2주 만에 독성 필터, PII 마스킹, 탈옥 탐지, 주제 이탈 차단까지 4겹을 쌓았다. 결과? 사용자 만족도가 38% 빠졌다. 차단당한 사용자 중 실제 악의적 의도가 있었던 비율은 4%도 안 됐다.

#가드레일은 왜 과잉 방어로 흐르나

개발자 입장에서 가드레일의 인센티브 구조가 비대칭이다. 악성 쿼리 하나를 놓치면 슬랙에 인시던트 알림이 울리고 포스트모템을 써야 한다. 반면 정상 쿼리 100개를 오차단해도 "사용자가 좀 불편했겠네" 수준으로 넘어간다. 그러니 threshold를 빡빡하게 잡는 게 합리적 선택이 된다.

문제는 이게 누적된다는 거다. 독성 필터 따로, PII 필터 따로, 주제 필터 따로 — 각각은 오탐률 5%인데, 직렬로 연결하면 정상 쿼리가 세 관문을 모두 통과해야 하니까 실질 오탐률이 15%에 육박한다. 거기에 탈옥 탐지까지 붙이면 사용자 5명 중 1명은 한 번쯤 "죄송합니다, 해당 질문에는 답변드리기 어렵습니다"를 본다.

우리가 놓친 건 단순하다. 각 가드레일을 독립적으로 테스트했지, 파이프라인 전체의 오탐률을 측정하지 않았다.

#3주간의 리팩토링

결국 가드레일 아키텍처를 갈아엎었다. 핵심은 세 가지였다.

첫째, 직렬에서 병렬로. 독성·PII·탈옥 탐지를 동시에 돌렸다. 레이턴시가 650ms에서 180ms로 줄었고, 각 모듈이 독립 판정을 내리니 "하나가 긴가민가할 때 다른 둘이 통과했으면 넘긴다"는 로직을 짤 수 있게 됐다.

둘째, 리스크 기반 라우팅. 모든 쿼리에 같은 강도의 가드레일을 적용하는 게 문제였다. "배송 언제 와요"에 탈옥 탐지 full scan을 돌릴 이유가 없다. 쿼리를 저위험·중위험·고위험으로 분류하는 경량 분류기를 앞단에 뒀다. 저위험은 PII 마스킹만, 고위험은 전체 파이프라인 — 이렇게 나누니 평균 처리 시간이 40% 줄고 오탐률도 반으로 떨어졌다.

risk = classify_risk(query)  # lightweight classifier, ~15ms
if risk == "low":
    checks = [pii_mask]
elif risk == "medium":
    checks = [pii_mask, toxicity]
else:
    checks = [pii_mask, toxicity, jailbreak, topic_guard]

results = await asyncio.gather(*[c(query) for c in checks])

셋째, 소프트 블록. 이전에는 차단 = 대화 종료였다. "답변드리기 어렵습니다"가 끝. 바꾼 후에는 차단 시에도 맥락을 유지하면서 "이 부분은 제가 도와드리기 어렵지만, 혹시 [대안 질문] 의도이셨나요?"로 전환한다. 사용자 이탈률이 눈에 띄게 줄었다.

#측정하지 않으면 과잉 방어를 모른다

가드레일 팀에서 지금 보는 지표는 네 개다.

처음에는 FNR만 집착했다. "악성 쿼리 하나라도 놓치면 안 돼." 맞는 말이다. 근데 FPR을 같이 안 보면 사용자 경험이 조용히 죽는다. 슬랙에 인시던트가 안 올리는 종류의 장애 — 사용자가 그냥 안 쓰게 되는 장애.

리팩토링 후 2주 지나서 만족도가 이전 수준으로 돌아왔고, 동시에 실제 악성 쿼리 차단율은 오히려 올라갔다. 리스크 라우팅 덕분에 고위험 쿼리에 더 많은 리소스를 집중할 수 있게 된 거다.

#가드레일도 결국 프로덕트다

보안팀이 가드레일을 설계하면 "최대한 막는" 방향으로 간다. 프로덕트팀이 설계하면 "최대한 안 막는" 방향으로 간다. 둘 다 틀렸다.

가드레일은 보안 기능이 아니라 프로덕트 기능이다. 사용자와 직접 맞닿는 인터페이스고, 차단 메시지 하나가 서비스 전체의 인상을 결정한다. 그래서 PM이 관여해야 하고, A/B 테스트를 해야 하고, 사용자 피드백 루프가 있어야 한다.

지금 가드레일을 달고 있다면 한 가지만 체크하자. FPR을 측정하고 있는가? 안 하고 있다면, 사용자가 조용히 떠나고 있을 가능성이 높다.