적대적 검토 프롬프트가 검열에 걸리다

저녁 6시 37분, 한 참여자가 황당하다는 반응과 함께 상황을 전했다. 문제가 된 것은 내용이 아니라 표현이었다는 설명이다.

"적대적 검토란 표현 썼다고 걸렸네요..... 어이가 없네요"

곧이어 어떤 지시가 걸렸는지가 구체적으로 공개됐다. 자기 설계문서를 공격해 보고, 뚫리는 경로를 찾아 그 구멍을 막으라는 요청이었다.

"설계문서 공격해라 우회할 방법을 찾아서 막아라 -> 공격 우회법 여기서 걸리고"

목적은 방어인데 문장의 앞부분은 공격 요청과 구분되지 않는다. 우회 방법을 찾으라는 말은 그 자체로 우회법을 요구하는 문장이고, 뒤에 붙은 막으라는 지시가 의도를 뒤집지만 필터가 그 반전까지 읽어 주지는 않은 것으로 보인다.

같은 경험은 곧 여러 건 모였다. 한 참여자는 짧게 확인을 보탰고, 다른 참여자는 하네스(harness) 리뷰를 맡길 때 같은 벽에 부딪혔다고 전했다.

"검열 걸리긴 하더라구요 ㅋㅋ"

"저도 하네스 리뷰할때 걸리더라구요"

각 잡고 짠 프롬프트에서도 같은 일이 생긴다는 말이 뒤따랐다. 한 번 쓰고 버리는 질문이 아니라 검토 절차로 다듬어 둔 지시문일수록 같은 벽에 닿는다는 이야기로 읽힌다. 방 안에서는 모든 세션이 막혔다는 사람까지 나왔고, 우회는 쉽지 않다는 반응으로 이어졌다.

"검열 회피 어렵네요"

여기서 드러나는 것은 필터가 무엇을 보고 판정하는지에 대한 단서로 보인다. 판정 기준이 요청의 목적이 아니라 문장에 등장하는 행위 표현에 가깝게 작동한다면, 방어를 위해 쓴 글과 침해를 위해 쓴 글은 같은 어휘를 공유하므로 구분이 어렵다. 적대적 검토는 원래 자기 결과물을 스스로 공격해 약점을 찾는 방법이라, 이 충돌은 우연이 아니라 구조적으로 예정된 자리에 가깝다.

여러 사람이 같은 벽에 부딪혔다는 점도 이 해석을 뒷받침한다. 한 사람의 표현이 유별났다면 다른 문장으로 바꿔 쓰면 그만이지만, 설계문서 검토와 하네스 리뷰처럼 대상이 다른 작업에서 같은 결과가 나왔다면 걸리는 지점은 개별 문장이 아니라 요청의 유형 쪽에 가깝다.

문제는 그 자리가 하필 품질 관리 공정이라는 점이다. 설계문서를 스스로 공격해 보는 일이나 실행 환경을 점검하는 리뷰는 모두 결과물을 튼튼하게 만들려는 작업인데, 안전장치가 이 단계를 먼저 막으면 검토 없는 산출물이 오히려 쉽게 통과한다. 방의 반응이 분노보다 체념에 가까웠던 것도 우회할 방법이 마땅치 않기 때문으로 읽힌다.

당장의 대응책은 표현을 바꿔 다시 물어보는 정도에 머무는 것으로 보인다. 다만 그 방식은 같은 요청을 매번 다르게 포장해야 한다는 뜻이라, 검토 절차를 자동화하려는 시도와는 어긋난다. 이날의 제보는 안전 정책이 촘촘해질수록 선의의 사용자가 먼저 비용을 치를 수 있음을 시사한다.