대규모 언어 모델은 깨끗한 벤치마크에서 강력한 결과를 낼 수 있지만, 프로덕션 환경에서 실제 사용자에게 중요한 모호한 상황에서는 어려움을 겪을 수 있습니다. 이것이 GitHub가 2026년 8월 25일 Mariko Wakabayashi와 Zixiao Chen이 작성한 자료에서 제시한 핵심 교훈입니다. 이 자료는 GitHub secret scanning에서 오탐을 줄이는 데 도움을 주는 대규모 언어 모델 기반 시스템의 평가 경험을 바탕으로 합니다.
비밀 정보 스캔은 소프트웨어 저장소에 저장되었을 수 있는 토큰과 키 같은 자격 증명을 찾습니다. 그러나 일부 문자열은 실제 자격 증명이 아니면서도 비밀 정보와 유사하기 때문에, 개발자는 처리가 필요하지 않은 알림을 검토하게 됩니다. 따라서 팀이 던진 질문은 모델이 개별 문자열을 분류할 수 있는지가 아니라, 보안상 민감한 워크플로를 안전하게 유지할 만큼 충분한 재현율을 확보하면서 잡음을 줄일 수 있는지였습니다.
모델 선택이 아니라 제품 의사결정에서 시작하라
GitHub는 프롬프트를 수정하거나 컨텍스트를 추가하거나 모델을 변경하기 전에 평가가 지원해야 할 의사결정을 정하라고 권고합니다. 비밀 정보 스캔의 경우 목표는 오탐을 줄이고 정밀도를 높이는 것이었으며, 재현율은 안전 제약 조건으로 사용되었습니다. 실제 자격 증명을 실수로 숨기는 것이 개발자에게 추가 알림을 검토하도록 요청하는 것보다 더 위험할 수 있기 때문입니다.
실제로 평가 기준은 세 계층으로 나뉘었습니다. 사용자 효용을 측정하는 기본 결과는 오탐 감소와 정밀도였고, 안전 제약 조건은 재현율이었으며, 운영상의 가드레일에는 응답 시간, 비용, 신뢰성, 프로덕션 환경과의 호환성이 포함되었습니다. 따라서 정밀도가 향상되었더라도 재현율이 허용할 수 없는 수준으로 낮아지거나 시스템이 지나치게 느리고 비싸거나 통합하기 어려워진다면 자동으로 성공으로 간주되지 않습니다.
평가를 반복 가능한 통합 테스트로 만들어라
평가는 출시 전에 한 번 수행하는 단계가 아닙니다. 프롬프트, 모델, 입력 구성 방식, 이를 둘러싼 시스템 로직은 계속 변하며, 어떤 변경이든 개선이나 후퇴를 일으키거나 오류 패턴을 다른 곳으로 옮길 수 있습니다. 따라서 GitHub는 중요한 변경이 있을 때마다 평가를 다시 실행하고, 매번 프롬프트 버전, 모델, 데이터 세트, 시스템 설정을 기록했습니다.
또한 팀은 각 실험에서 하나의 주요 변수만 분리해, 모델 업그레이드를 테스트하기 전에 프롬프트 변경을 알려진 기준선과 비교했습니다. 프롬프트와 평가 설정은 코드처럼 버전 관리되고 변경 사항이 문서화되었으며, 이전 설정을 다시 실행하고 되돌릴 수 있도록 유지되었습니다. 이러한 방식은 개선이나 후퇴의 원인을 마지막 변경 사항에 잘못 돌리지 않고 파악할 수 있게 합니다.
깨끗한 데이터에 만족하지 말고 프로덕션 작업을 모의하라
오프라인 평가 결과는 실제 작업과 유사할 때 더 유용합니다. 비밀 정보 스캔에서 모델은 고립된 값만 보는 것이 아니라, 주변 코드와 누락되거나 흩어져 있을 수 있는 보조 정보가 포함된 후보를 봅니다. 모델은 평가 대상 후보 대신 보안과 더 관련 있어 보이는 다른 값, 예를 들어 코드에 있는 테스트 토큰에 집중할 수도 있습니다.
따라서 평가에서는 평가 대상 후보, 주변 컨텍스트, 보조 정보, 입력 형식과 제약 조건을 적용하는 방식, 더 넓은 시스템 로직 등 프로덕션 작업의 특성을 유지해야 합니다. 평가가 실제보다 더 명확한 예시와 더 완전한 컨텍스트를 사용한다면, 결과는 배포 후 시스템이 마주할 문제보다 쉬운 문제를 반영할 수 있습니다.
라벨과 데이터를 검증 가능한 증거로 다뤄라
제품에서 특정 작업이 수행되었다는 결과가 신뢰할 수 있는 정답을 의미하는 것은 아닙니다. 비밀 정보 스캔에서 알림을 닫았다는 것은 자격 증명이 교체되었다는 뜻일 수도 있고, 위험이 수용되었다는 뜻일 수도 있으며, 워크플로를 시작하기 위해 알림을 닫았다는 뜻일 수도 있고, 잘못 분류되었다는 뜻일 수도 있습니다. 이러한 상황은 워크플로 데이터에서는 비슷하게 보이지만, 평가에서 동일한 질문에 답하지는 않습니다.
프로덕션 데이터를 사용하기 전에 라벨이 어떻게 생성되었는지, 평가 질문과 일치하는지, 서로 다른 결과가 하나의 범주로 합쳐졌는지를 파악해야 합니다. GitHub는 모든 라벨이 정확하다고 가정하지 말고 중요하거나 모호한 범주를 사람이 검토할 것을 제안합니다. 합성 데이터와 공개 벤치마크는 특히 누락된 컨텍스트, 비정상적인 형식, 자격 증명과 유사한 근접 값처럼 드문 사례에서 커버리지의 빈틈을 메울 수 있지만, 프로덕션에 가까운 데이터를 대체하는 것이 아니라 보완해야 합니다.
오류를 분석하고 평가자 모델은 신중하게 사용하라
종합 지표는 시스템이 개선되었는지는 알려주지만, 다음에 무엇을 바꿔야 하는지는 설명하지 않습니다. 따라서 GitHub는 일부 거짓 양성 및 거짓 음성 샘플을 검토하고, 원인을 모델, 프롬프트, 입력, 파이프라인, 데이터 세트, 라벨 중 어디에 있을 수 있는지 분류했습니다. 이러한 분류는 일반적인 품질 문제를 구체적인 엔지니어링 작업으로 바꿉니다. 예를 들어 더 나은 입력 프레이밍, 다른 컨텍스트 구성, 데이터 정제, 더 명확한 제품 정책 등이 해당합니다.
다른 대규모 언어 모델을 평가자로 사용하면 사람의 검토 부담을 줄일 수 있으며, 명확한 사례를 처리하고 모호한 사례의 우선순위를 정할 수 있습니다. 그러나 평가자 모델의 출력은 기준 진실이 아닙니다. 모델이 실수할 수 있고, 평가 대상 모델과 잘못된 이유로 같은 판단을 내릴 수도 있기 때문입니다. 더 안전한 방식은 신뢰도가 낮거나 서로 충돌하거나 영향이 큰 사례를 사람에게 넘기고, 평가자가 높은 확신으로 분류한 사례를 정기적으로 샘플링하는 것입니다. 또한 평가자와 시스템 및 검토자의 불일치를 추적하고 평가자의 프롬프트를 버전 관리해야 합니다.
이 실험이 실제로 입증한 것은 무엇인가?
GitHub는 평가한 오프라인 데이터 세트에서 재현율을 정해진 안전 제약 안에 유지하면서 오탐을 95% 줄였다고 밝혔습니다. 그러나 회사는 이 결과를 모든 프로덕션 시나리오에서 시스템이 동일하게 동작할 것이라는 증거로 제시하지 않았습니다. 더 중요한 가치는 결과에 도달한 방식에 있었습니다. 실제 작업에 더 가까운 평가, 재현 가능한 기준선, 문서화된 실패 패턴이 그것입니다.
certi.news의 편집자 해석: 여기서 실제 변화는 새로운 모델을 내놓는 것이 아니라, LLM 시스템 평가를 명확한 의사결정과 안전 및 운영 한계에 연결된 지속적인 엔지니어링 프로세스로 바꾸는 것입니다. 이는 소프트웨어, 보안, 개발자 도구 팀에 중요합니다. 하나의 지표가 개선되었다는 사실이 재현율의 위험한 하락이나 비용 증가를 가릴 수 있기 때문입니다. 반면 결과는 평가 세트와 라벨의 품질, 그리고 오프라인 테스트와 프로덕션 동작 사이에 존재하며 제거할 수 없는 격차에 의해 제한됩니다. 따라서 평가는 통제된 프로덕션 실험으로 나아가기 위한 기반이지, 출시 후 위험 모니터링을 대체하는 수단은 아닙니다.