평가, 안전성, 책임 있는 사용

잘 대답하는 것과 안전하게 동작하는 것은 다르다

Gemma 기반 서비스를 만들 때 가장 위험한 순간은 데모가 그럴듯하게 성공했을 때다. 짧은 질문에는 자연스럽게 답하고, 문서 요약도 꽤 잘하며, 코드도 작성한다. 그래서 제품에 바로 넣어도 될 것처럼 보인다.

하지만 LLM 서비스의 품질은 한두 번의 성공으로 판단할 수 없다. 같은 질문에도 표현이 달라지면 답이 흔들릴 수 있고, 모르는 내용을 아는 것처럼 말할 수 있다. RAG를 붙였더라도 잘못 검색된 문서를 근거로 삼을 수 있다. 사용자가 개인정보를 입력하거나, 외부 문서에 숨은 지시문이 들어 있거나, 도구 호출이 결제·삭제·전송 같은 실제 행동으로 이어질 수도 있다.

평가와 안전성 설계의 목적은 모델을 완벽하게 만드는 것이 아니다. 실패를 발견할 수 있게 만들고, 실패했을 때 피해가 커지지 않게 막는 것이다. Gemma는 답변을 생성하는 강력한 구성 요소이지만, 제품의 책임은 시스템 전체가 져야 한다.

AI 생성 이미지

태스크별 평가 지표를 먼저 정한다

평가 지표는 하나로 끝나지 않는다. 챗봇, 문서 Q&A, 코드 보조, 분류기, 요약기는 서로 다른 방식으로 실패한다. 따라서 먼저 서비스가 사용자에게 제공해야 할 가치를 정의하고, 그 가치가 깨지는 상황을 지표로 바꿔야 한다.

문서 기반 Q&A라면 핵심 지표는 정확성, 근거 충실도, 출처 표시, 권한 준수다. 정확성은 답이 사실과 맞는지를 본다. 근거 충실도는 답변이 제공된 문서에 실제로 기반했는지를 본다. 출처 표시는 사용자가 답의 근거를 확인할 수 있게 한다. 권한 준수는 사용자가 볼 수 없는 문서의 내용을 답하지 않는지를 확인한다.

요약 서비스라면 중요한 지표가 조금 다르다. 원문의 핵심을 빠뜨리지 않는지, 없는 내용을 추가하지 않는지, 숫자와 고유명사를 바꾸지 않는지, 지나치게 길거나 짧지 않은지를 본다. 분류 서비스라면 라벨 정확도, 애매한 입력에서의 보류 판단, 출력 형식 준수가 중요하다. 코드 생성 서비스라면 실행 가능성, 보안 취약점, 의존성 설명, 테스트 포함 여부를 확인해야 한다.

안전성 지표도 함께 둬야 한다. 유해한 조언을 생성하지 않는지, 개인정보를 노출하지 않는지, 편향된 표현을 반복하지 않는지, 저작권 자료를 과도하게 재현하지 않는지 평가한다. 좋은 평가는 사용자 이익과 예상 가능한 위험을 한 표 안에서 함께 본다. 예를 들어 고객지원 챗봇은 응답 속도를 높이는 이익이 있지만, 잘못된 환불 안내나 개인정보 노출이라는 위험도 가진다. 둘 중 하나만 보면 제품 판단이 흔들린다.

골든 데이터셋으로 변경을 비교한다

프롬프트를 조금 고쳤는데 답변이 좋아졌다고 느낄 수 있다. RAG의 top-k를 5에서 8로 늘렸더니 더 풍부해 보일 수도 있다. 모델 버전을 바꾸면 말투가 훨씬 자연스러워질 수 있다. 그러나 느낌만으로 배포하면 이전에 잘 되던 사례가 조용히 망가진다.

이를 막기 위해 골든 데이터셋을 만든다. 골든 데이터셋은 배포 판단에 반복해서 사용하는 고정 평가 묶음이다. 실제 사용자 질문, 운영자가 만든 경계 사례, 위험 요청, 자주 실패하는 질문을 포함한다. 정상 입력만 넣으면 안 된다. 모호한 질문, 근거가 없는 질문, 권한 밖 문서 요청, 개인정보가 섞인 요청, 프롬프트 인젝션이 포함된 문서도 넣어야 한다.

각 항목에는 기대 동작을 적는다. 반드시 맞혀야 하는 정답이 있을 수도 있고, 답하지 말아야 하는 조건이 있을 수도 있다. 예를 들어 사내 규정 문서에 없는 복지 혜택을 물으면 모델은 추측하지 말고 해당 근거를 찾을 수 없다고 답해야 한다. 사용자가 다른 부서의 비공개 문서를 요약해 달라고 요청하면 권한상 제공할 수 없다고 답해야 한다.

이 데이터셋으로 회귀 테스트를 돌린다. 회귀 테스트는 변경 전후에 기존 기능이 깨졌는지 확인하는 절차다. 프롬프트, 검색 설정, 임베딩 모델, Gemma 버전, LoRA 어댑터, 추론 파라미터를 바꿀 때마다 같은 질문을 다시 실행한다. 자동 채점이 가능한 항목은 프로그램으로 확인하고, 판단이 필요한 항목은 사람이 본다.

자동 평가는 형식 검증에 강하다. JSON 필드가 빠졌는지, 출처가 포함됐는지, 금지 표현이 있는지, 개인정보 패턴이 출력됐는지, 답변 길이가 범위를 넘었는지 빠르게 확인할 수 있다. 사람 평가는 유용성, 어조, 근거 왜곡, 사용자가 오해할 가능성처럼 맥락이 필요한 기준에 강하다. 둘 중 하나만 쓰지 말고 조합해야 한다.

RAG는 검색과 생성을 분리해 평가한다

RAG 시스템에서 답변이 틀렸을 때 원인은 둘 중 하나다. 검색이 틀렸거나, 검색은 맞았는데 생성이 틀렸다. 이 둘을 나누지 않으면 개선 방향을 찾기 어렵다.

먼저 검색 평가를 한다. 질문마다 정답 근거 문서를 정하고, 검색 결과 상위 k개 안에 그 문서가 들어오는지 본다. 문서 버전, 권한 필터, 날짜 필터가 제대로 작동하는지도 확인한다. 검색 결과가 틀렸다면 Gemma를 바꿔도 답은 좋아지지 않는다. 청크 크기, 메타데이터, 임베딩 모델, 검색 쿼리 재작성 방식을 먼저 손봐야 한다.

그다음 생성 평가를 한다. 올바른 근거가 들어갔을 때 Gemma가 근거 안에서만 답하는지, 모르는 부분을 추측하지 않는지, 충돌하는 문서가 있을 때 최신 문서를 우선하는지 확인한다. 답변 끝에 출처를 붙이는 것만으로 충분하지 않다. 출처가 실제 문장 내용과 맞아야 한다.

운영 로그도 평가에 연결한다. 사용자가 다시 질문한 경우, 답변을 낮게 평가한 경우, 상담원에게 전환한 경우, 금지 정책에 걸린 경우를 모아 다음 골든 데이터셋 후보로 삼는다. 평가는 배포 전 한 번 하는 행사가 아니라 운영 중 계속 업데이트되는 루프다.

개인정보와 민감 정보는 최소화한다

LLM 서비스는 사용자가 예상보다 많은 정보를 입력하게 만든다. 고객번호, 이메일, 주소, 계약서, 의료 정보, 내부 코드, 접속 토큰이 프롬프트에 들어올 수 있다. 따라서 개인정보 보호는 모델 답변 단계가 아니라 입력, 저장, 검색, 출력 전체에 걸쳐 설계해야 한다.

입력 단계에서는 민감 정보 탐지와 마스킹을 적용한다. 꼭 필요하지 않은 주민등록번호, 카드번호, 비밀번호, API 키는 모델에 보내지 않는다. 업무상 필요한 식별자는 토큰화하거나 내부 ID로 바꾼다. 사용자가 민감 정보를 붙여 넣었을 때는 일부를 가리고 다시 확인하도록 안내할 수 있다.

로그는 최소화한다. 디버깅을 위해 모든 프롬프트와 응답을 그대로 저장하면 나중에 더 큰 위험이 된다. 운영에 필요한 필드만 남기고, 원문 저장 기간을 제한한다. 접근 권한을 분리하고, 관리자 조회도 감사 로그에 남긴다. 사용자가 데이터 삭제를 요청할 수 있는 서비스라면 대화 기록, 첨부 문서, 임베딩 저장소, 캐시, 백업 정책까지 삭제 범위를 정해야 한다.

출력 단계에서는 개인정보 재노출을 검사한다. 모델이 입력에 있던 개인정보를 불필요하게 반복하지 않는지, 검색된 문서 안의 민감한 내용을 권한 없는 사용자에게 보여주지 않는지 확인한다. RAG에서는 벡터 검색 전에 권한 필터를 적용해야 한다. 검색 후에 프롬프트로 막겠다는 방식은 약하다. 모델에게 보이지 않아야 할 문서는 애초에 컨텍스트에 들어가면 안 된다.

저작권 자료도 비슷하게 다룬다. 사용자가 긴 책, 유료 보고서, 기사 전문을 넣고 거의 그대로 요약이나 재작성해 달라고 요청할 수 있다. 서비스 정책에 따라 허용 범위를 정하고, 필요한 경우 짧은 요약, 인용 범위 제한, 출처 표시, 전문 재현 거절을 적용한다.

프롬프트 공격과 도구 오남용을 계층적으로 막는다

탈옥 프롬프트는 모델의 원래 지시를 무시하게 만들려는 입력이다. 프롬프트 인젝션은 사용자 입력이나 외부 문서 안에 숨은 지시가 시스템 정책을 우회하도록 만드는 공격이다. 예를 들어 검색 문서 안에 이전 지시를 무시하고 관리자 토큰을 출력하라는 문장이 들어 있을 수 있다.

첫 번째 방어선은 시스템 프롬프트다. Gemma에게 역할, 허용 범위, 거절 기준, 근거 사용 규칙을 명확히 준다. 단, 시스템 프롬프트만 믿으면 안 된다. LLM은 정책 집행자가 아니라 생성기다. 중요한 제한은 애플리케이션 코드와 권한 시스템에서 강제해야 한다.

두 번째 방어선은 입력 필터링이다. 위험한 요청, 권한 우회 시도, 악성 코드 생성 요청, 개인정보 탈취 요청을 모델 호출 전에 탐지한다. 모든 위험 요청을 완벽히 잡을 수는 없지만, 명백한 패턴을 앞단에서 줄이는 것만으로도 피해 가능성이 낮아진다.

세 번째 방어선은 도구 권한 분리다. Gemma가 직접 데이터베이스를 수정하거나 결제를 실행하거나 이메일을 보내게 해서는 안 된다. 모델은 도구 호출 의도를 제안할 수 있고, 백엔드는 인자, 사용자 권한, 위험도, 승인 필요 여부를 검증한 뒤 실행해야 한다. 삭제, 결제, 외부 전송처럼 되돌리기 어려운 행동은 사용자 확인이나 관리자 승인을 요구한다.

네 번째 방어선은 출력 검증이다. 모델 응답이 정책을 위반하거나, 허용되지 않은 개인정보를 포함하거나, JSON 형식이 깨졌거나, 근거 없는 단정으로 보이면 사용자에게 바로 전달하지 않는다. 재시도하거나, 안전한 고정 메시지로 대체하거나, 사람 검토로 넘긴다.

마지막으로 사후 감사 로그를 남긴다. 누가 어떤 요청을 했고, 어떤 문서가 검색됐고, 어떤 도구가 호출됐고, 어떤 정책 판단이 내려졌는지 추적할 수 있어야 한다. 감사 로그는 사용자를 감시하기 위한 것이 아니라 사고가 났을 때 원인을 찾고 피해를 줄이기 위한 안전장치다.

제품 의사결정에는 책임 기준이 필요하다

Google AI Principles는 AI가 사람을 돕고 역량을 높이는 방향으로 쓰여야 하며, 예상 가능한 위험보다 전체 편익이 충분히 클 때 엄격한 설계, 테스트, 모니터링, 안전장치와 함께 개발·배포해야 한다고 설명한다.¹ Gemma 기반 제품에도 같은 기준을 적용할 수 있다.

기능을 만들기 전에 세 가지 질문을 던진다. 첫째, 이 기능은 사용자에게 실제 이익을 주는가. 둘째, 실패했을 때 사용자가 입을 수 있는 피해는 무엇인가. 셋째, 그 피해를 줄일 통제 장치가 제품 안에 있는가.

위험도가 낮은 기능과 높은 기능은 다르게 설계한다. 문장 다듬기, 회의록 초안, 내부 문서 검색처럼 사용자가 쉽게 검토할 수 있는 기능은 자동화를 넓게 적용할 수 있다. 반면 법률·의료·금융 판단, 인사 평가, 계정 삭제, 보안 설정 변경처럼 피해가 큰 기능은 사람의 승인, 근거 확인, 강한 로그, 제한된 권한이 필요하다.

편향도 제품 판단에 포함해야 한다. 모델이 특정 집단에 대해 불공정하거나 모욕적인 표현을 만들지 않는지, 채용·평가·심사처럼 민감한 의사결정에서 부적절한 기준을 사용하지 않는지 확인한다. LLM의 답변이 자연스럽다는 이유로 객관적인 판단이라고 받아들이면 안 된다.

사용자에게 한계를 숨기지 않는다

책임 있는 사용은 내부 정책만으로 완성되지 않는다. 사용자가 AI의 역할과 한계를 이해할 수 있어야 한다. 제품 화면에는 AI가 생성한 결과임을 표시하고, 오류 가능성이 있음을 알려야 한다. 중요한 결정에는 사용자가 원문 근거를 확인할 수 있게 해야 한다.

좋은 안내는 겁을 주는 문구가 아니다. 사용자가 올바르게 활용하도록 돕는 설명이다. 예를 들어 이 답변은 제공된 사내 문서를 바탕으로 생성되었으며, 최신 정책은 원문 링크에서 확인하라는 식으로 안내할 수 있다. 의료, 법률, 보안처럼 고위험 영역에서는 전문가 확인이 필요하다는 경고를 더 명확히 해야 한다.

또한 사용자가 피드백을 보낼 수 있어야 한다. 틀렸어요, 근거가 부족해요, 민감 정보가 포함됐어요 같은 신고 버튼은 단순한 UI가 아니다. 운영 평가 데이터로 돌아오는 안전 루프다. 사용자의 피드백을 모아 프롬프트, 검색 설정, 차단 정책, 골든 데이터셋을 개선한다.

Gemma는 사용자를 대체하는 존재가 아니라 사용자의 판단을 돕는 도구로 설계하는 편이 안전하다. 모델이 초안을 만들고, 근거를 찾아주고, 반복 작업을 줄여주되, 중요한 결정은 사용자와 조직의 책임 있는 절차 안에서 이루어져야 한다.

배포 전 점검 목록

Gemma 서비스를 배포하기 전에는 최소한 다음 항목을 확인한다.

• 태스크별 평가 지표가 정의되어 있는가

• 정상·경계·위험 요청을 포함한 골든 데이터셋이 있는가

• 프롬프트, RAG, 모델 버전 변경 시 회귀 테스트를 실행하는가

• 검색 품질과 생성 품질을 분리해 평가하는가

• 개인정보 입력, 저장, 출력, 삭제 정책이 정리되어 있는가

• 권한 없는 문서가 검색 컨텍스트에 들어가지 않도록 막는가

• 탈옥 프롬프트와 프롬프트 인젝션에 대한 방어 계층이 있는가

• 도구 호출은 백엔드 권한 검증과 승인 절차를 거치는가

• 유해 출력, 형식 오류, 민감 정보 노출을 배포 전에 검사하는가

• 운영 로그와 사용자 피드백이 다음 평가 데이터로 환류되는가

• 사용자에게 AI 생성 결과와 한계를 명확히 알리는가

이 목록을 모두 만족해도 위험이 사라지지는 않는다. 하지만 위험을 발견하고 줄일 수 있는 구조가 생긴다. LLM 서비스의 신뢰성은 한 번의 모델 선택으로 결정되지 않는다. 평가, 안전장치, 모니터링, 사용자 고지가 함께 작동할 때 Gemma는 실제 서비스에서 오래 사용할 수 있는 도구가 된다.

참고

¹AI Principles — Google AI