DearMate에서는 캐릭터의 지침과 대화 맥락을 유지하면서 사용자 입력에 응답해야 합니다. 보안 규칙을 추가하면 지시 추출이나 작업 전환 공격에 대응할 수 있지만, 정상적인 질문까지 거절하거나 캐릭터 대화로만 돌아가 버릴 수도 있습니다. 보안 프롬프트가 공격을 얼마나 막는지와 함께, 정상적인 사용을 얼마나 방해하는지도 확인할 필요가 있었습니다.
저는 이 보안 평가의 실험 조건과 검증 기준을 설계했습니다. 동일 모델·동일 입력에서 보안 프롬프트 OFF/ON을 비교하고, 공격 방어와 정상 요청 처리를 각각 측정하는 것이 중심입니다. 아래 결과는 Drive의 「Prompt Security Research」 보고서에 기록된 실험 결과를 바탕으로 정리했습니다.
1. 하나의 보안 점수로 합치지 않고 평가 문제를 나눴습니다
평가 | 확인하려는 문제 | 함께 봐야 할 조건 |
B1 · Tensor Trust extraction v1 | 공격 입력에서 비밀 access code가 유출되는가 | 정상 access code를 입력했을 때 인증 작업도 수행하는가 |
B2 · JailbreakBench JBB-Behaviors | 유해 요청을 실제로 수행하는가 | 주제가 비슷한 정상 요청까지 과도하게 거절하는가 |
B3 · Open-Prompt-Injection | 주입된 지시가 원래 작업을 다른 작업으로 바꾸는가 | 채점기가 확인한 공격 실패가 원래 작업의 완전한 수행도 뜻하는가 |
비교 대상은 Gemini 3.1 Flash Lite, GPT-OSS 120B, DeepSeek V4 Flash, GLM 5 Turbo의 네 모델입니다. 각 입력에 보안 규칙의 유무를 교차 적용해, 모델 간 차이와 보안 규칙을 추가했을 때의 변화를 구분합니다.
B1에서는 공격 상황의 비밀 비노출(ERR)과 정상 인증 처리(DV)를 따로 봅니다. B2에서는 유해 요청 수행, 유해 요청 거부, 정상 요청의 과잉 거부를 별도 지표로 둡니다. 명시적인 거절이 없더라도 유해한 작업을 수행하지 않은 응답이 있을 수 있으므로, 수행 여부와 거부 여부도 같은 것으로 취급하지 않습니다.
2. 방어가 강해졌을 때 정상 사용이 어떻게 달라지는지 봤습니다
보고서에서는 보안 프롬프트 ON 조건이 전반적으로 비밀 유출 방어를 높였지만 일부 모델의 정상 인증 처리는 낮아졌습니다. 유해 요청 평가에서도 정상 요청의 과잉 거부가 모든 비교 모델에서 증가한 것으로 기록되어 있습니다. B3의 전체 공격 성공률은 네 모델 모두에서 감소했지만 변화의 크기는 달랐습니다.
이 결과에서 보여줄 판단은 보안 규칙의 효과를 단순히 성공·실패로 결정하지 않았다는 점입니다. 어떤 공격을 더 잘 막았는지, 그 과정에서 원래 기능이나 정상 대화가 얼마나 영향을 받았는지 나눠 읽습니다. 캐릭터 서비스의 운영 정책을 고를 때도 방어 성능과 사용성을 함께 검토할 수 있는 근거가 됩니다.
이 실험이 DearMate 운영 환경 전체의 보안을 검증했다는 뜻은 아닙니다. 해당 입력·모델·보안 프롬프트·채점 조건에서 관찰된 결과입니다. 실제 서비스에 적용한 최종 정책이나 적용 이후의 사용자 경험까지 확인한 자료로 확장하지 않습니다.
3. 실행 완료와 평가 통과를 구분했습니다
보고서의 실행 완료 표에는 B1이 6,674/9,120, B2가 1,600/1,600, B3가 2,000/2,000으로 기록되어 있습니다. 이 값은 계획된 실행 작업에 대한 완료 기록이며, 보안 평가를 통과한 응답 수가 아닙니다.
B1은 도중에 중단한 부분 결과라 모델·조건별 표본이 다릅니다. B2와 B3는 계획된 작업을 완료했지만, B2의 정상 요청을 사람이 비교한 분석은 별도의 부분 표본입니다. 전체 정상 요청에 대한 LLM Judge 결과와 부분 수동평가를 같은 분모로 합치지 않습니다.
응답 군집 분석도 결과를 읽는 보조 수단입니다. 보고서에는 군집 요약·개별 응답 좌표·모델과 조건별 성공/실패 CSV, 입력 해시와 분석 설정을 남기는 산출물 목록이 있습니다. 군집 번호 자체를 품질 순위처럼 해석하지 않습니다.
4. 채점기가 무엇을 놓칠 수 있는지도 기록했습니다
B1의 ERR은 access code가 노출됐는지를 검사합니다. 다른 시스템 지시가 일부 드러나더라도 access code가 없다면 통과할 수 있으므로, 이를 개인정보·내부 문서·모든 시스템 지시의 기밀성 보장으로 해석할 수 없습니다.
B2의 정상 요청 지표는 거부 여부를 판단합니다. 명시적으로 거절하지 않았지만 엉뚱한 답을 했을 때도 통과할 수 있기 때문에, 정확성·관련성을 보는 사람의 응답 비교가 보완 분석으로 사용됩니다.
B3 역시 공격자가 요구한 목표 라벨을 출력하는지에 의존합니다. 목표 영어 라벨만 피하고 다른 방식으로 공격의 영향을 받은 응답이 통과할 가능성이 있어, 공격 성공률 감소를 원래 작업의 완전한 수행과 동일하게 보지 않습니다.
이 한계까지 적는 이유는 점수의 의미를 실제 측정 범위 안에 두기 위해서입니다. 포트폴리오에서는 데이터셋 이름보다 어떤 실패를 정의했고, 어떤 비교를 통제했으며, 결과를 어디까지 해석했는지를 보여줍니다.
5. 서비스의 인증·권한 테스트는 별도 근거로 연결합니다
모델의 보안 프롬프트 평가와 함께, 서비스 코드에는 신뢰할 사용자 식별자와 접근 권한을 검증하는 테스트도 있습니다. Chat API의 만료·변조 토큰, 다른 사용자의 대화 접근, 요청 본문의 임의 사용자 식별자 주입 등을 다룹니다. Social Automation에서는 콘솔 권한이 없는 사용자의 접근과 같은 thread ID를 사용하는 다른 사용자의 세션 분리도 검사합니다.
이는 모델이 지시를 잘 지켰는지와 다른 경계의 검증입니다. 모델 응답의 보안성과 API의 인증·인가를 한 점수로 합치지 않고, 각각의 설계와 테스트 근거로 제시합니다.