새로운 오픈 모델을 사내 서비스에 붙이는 일은 이제 어렵지 않습니다. 모델 저장소에서 파일을 내려받고, 추론 서버를 띄우고, API에 연결하면 데모가 나옵니다. 그런데 운영 배포 전에 한 가지 질문을 해보면 분위기가 달라집니다. 지금 실행하는 모델 파일이 누가 만든 어떤 버전인지, 다운로드 후 바뀌지 않았는지, 파일을 여는 과정에서 무엇이 실행되는지 설명할 수 있을까요?
모델은 단순한 숫자 배열 한 개가 아닙니다. 가중치, 설정 파일, 토크나이저, 전처리 코드, 라이브러리 버전, 추론 서버 이미지가 함께 결과를 만듭니다. 한 부분만 바뀌어도 보안 문제뿐 아니라 답변 품질이나 재현성이 달라질 수 있습니다. 기업 AI를 운영한다면 모델을 소프트웨어 공급망의 배포 자산으로 취급해야 하는 이유입니다.
이 글은 외부 모델을 사내로 반입해 서비스에 적용할 때 필요한 확인 순서를 정리합니다. 특정 제품 도입을 전제하지 않고, 공식 문서로 확인할 수 있는 파일 형식과 서명·출처 증명 원칙을 실무 흐름으로 연결합니다.
‘가중치 파일 하나’라는 생각이 왜 위험할까
모델을 내려받아 로드하는 순간 크게 두 종류의 위험이 있습니다. 첫째는 실행 위험입니다. 로더가 파일 안의 객체를 복원하면서 예상하지 않은 코드를 실행할 수 있습니다. 둘째는 변경·출처 위험입니다. 같은 이름의 파일을 다시 내려받았는데 내용이 바뀌거나, 검증되지 않은 복제 저장소에서 받아도 서비스가 이를 모를 수 있습니다.
실행 위험은 추상적인 걱정이 아닙니다. PyTorch의 torch.load 공식 문서는 내부적으로 역직렬화 기능을 사용하므로 신뢰할 수 없는 출처의 데이터를 로드하지 말라고 경고합니다. Hugging Face의 pickle 보안 문서도 pickle 파일에 임의 코드 실행 위험이 있음을 설명합니다.
그러나 확장자 하나로 모든 것을 판정할 수는 없습니다. 모델 저장소가 추가 코드 실행을 요구하는지, 토크나이저나 전처리기가 별도 파일을 읽는지, 추론 컨테이너에 어떤 라이브러리가 들어 있는지까지 봐야 합니다. 파일은 안전한 형식이어도 모델 자체가 잘못된 결과를 내거나, 라이선스가 사내 용도와 맞지 않을 수 있습니다. 위험의 종류를 섞지 않고 각각 검사해야 합니다.
첫 관문: ‘어디서 무엇을 받았는가’를 고정한다
운영 환경에서 모델을 받을 때는 “최신 버전” 같은 움직이는 별칭보다 정확한 저장소·리비전·파일 목록을 고정하는 편이 좋습니다. 같은 모델 이름이어도 게시자가 새 가중치로 바꾸거나 설정을 수정할 수 있기 때문입니다. 반입 기록에는 제공자, 공식 저장소 주소, 커밋 또는 불변 리비전, 다운로드 시각, 파일별 해시, 사용 허가 조건을 남깁니다.
이 기록은 재현성을 위한 문서이기도 합니다. 나중에 품질 문제가 생겼을 때 “그때 어떤 모델을 썼는가?”에 정확히 답할 수 있어야 같은 문제를 재현하고 되돌릴 수 있습니다. 특히 파인튜닝 모델이라면 기반 모델의 버전과 추가 학습 데이터·코드 버전도 별도로 연결합니다. 원본 모델과 사내 수정본을 하나의 이름으로 덮어쓰면 변경 이유를 추적하기 어렵습니다.
실무에서는 반입 대상을 하나의 묶음으로 적는 것이 좋습니다. 가중치, 모델 설정, 토크나이저, 전처리·후처리 코드, 추론 런타임, 관련 라이선스를 모델 패키지로 정의합니다. 이 가운데 하나라도 예상과 다르면 승인된 모델과 같은 것으로 간주하지 않습니다.
두 번째 관문: 로드 방식을 안전하게 정한다
가중치 파일을 안전하게 보관해도 로드 단계에서 불필요한 객체를 복원하면 문제가 남습니다. PyTorch는 가중치만 읽는 weights_only=True 옵션을 제공하며, 공식 튜토리얼은 state_dict를 저장하고 제한된 로드 방식으로 불러오는 접근을 권장합니다. 다만 제한된 로드 방식도 모든 악성 파일과 모든 모델 동작을 검증해 주는 만능 장치는 아닙니다.
텐서 데이터만 교환한다면 safetensors 같은 형식을 검토할 수 있습니다. 이 형식은 pickle과 달리 텐서 저장을 위한 단순한 형식으로 설계됐습니다. Hugging Face 직렬화 문서도 안전한 직렬화를 권장하고, pickle 체크포인트를 허용하는 설정은 별도로 명시하게 합니다.
하지만 파일 형식을 바꿨다고 모델 전체를 신뢰해도 된다는 뜻은 아닙니다. 설정 파일과 사용자 정의 코드, 컨테이너 이미지가 별도로 실행될 수 있고, 가중치가 특정 결과를 유도할 수도 있습니다. 호환성 때문에 위험한 로드 옵션이 필요하다면 운영 서버에서 바로 실행하지 말고 격리된 검증 환경에서 출처와 동작을 먼저 평가합니다.
세 번째 관문: 해시·서명·출처 증명은 서로 다른 질문에 답한다
해시는 파일 내용이 같은지 확인합니다. 반입 시 계산한 해시와 배포 직전 해시가 다르면 파일이 바뀌었다는 사실을 알 수 있습니다. 그러나 해시만으로는 최초 파일이 믿을 만한 제작자에게서 왔는지 알 수 없습니다.
전자서명은 특정 신원 또는 키가 그 파일을 승인했다는 주장을 검증합니다. Sigstore Cosign 문서는 일반 파일을 서명하는 방법을 제공하고, 검증 문서는 서명과 인증서·발급자 신원을 확인하는 방법을 설명합니다. 모델 파일에도 이런 원칙을 적용할 수 있습니다. 검증할 때는 단순히 “서명 있음”이 아니라 기대한 서명자와 발급자인지까지 확인해야 합니다.
출처 증명(provenance)은 산출물이 어디서, 언제, 어떤 과정으로 만들어졌는지 설명합니다. SLSA 1.2의 provenance 설명은 검증 가능한 생성 이력을 공급망 추적에 사용합니다. 모델 분야에서는 이를 그대로 복사하기보다 기반 모델, 데이터 스냅샷, 학습·변환 작업, 생성된 파일을 연결하는 기록으로 응용할 수 있습니다. 모델 학습의 모든 과학적 타당성을 증명한다는 의미는 아닙니다.
세 검사는 목적이 다릅니다. 해시가 맞아도 악성 파일이 원래 그 파일일 수 있고, 서명이 맞아도 서명자의 품질 검증이 부족할 수 있으며, 출처 기록이 있어도 개인정보나 편향 문제는 남을 수 있습니다. 따라서 기술적 무결성과 모델 품질·법적 사용 조건을 각각 확인해야 합니다.
네 번째 관문: 격리 환경에서 실제로 열고 시험한다
운영 추론 서버에서 처음으로 모델을 여는 흐름은 피하는 편이 좋습니다. 다운로드와 압축 해제, 파일 검사, 로드 테스트를 격리된 환경에서 먼저 수행합니다. 이 환경에는 불필요한 내부 자격증명을 넣지 않고, 네트워크와 파일 접근 권한을 최소화합니다. 실행 여부뿐 아니라 로드 시간이 과도하지 않은지, 예상 밖의 외부 접속이나 파일 쓰기가 있는지도 살핍니다.
보안 검사 뒤에는 품질 검증이 이어집니다. 사내 업무에 맞는 평가 데이터로 정답률뿐 아니라 금지 응답, 형식 준수, 지연 시간, 비용을 확인합니다. 기존 모델과 비교할 때는 같은 입력 세트와 같은 평가 기준을 사용해야 차이가 의미 있습니다. 문서 검색 모델이라면 권한이 없는 문서를 인용하는지, 산업용 분류 모델이라면 드문 고장 유형을 놓치는지도 봐야 합니다.
라이선스와 데이터 사용 조건도 이 단계에서 확인합니다. 외부 모델의 상업적 이용, 재배포, 파생 모델 공개, 입력 데이터 보관 조건은 모델마다 다를 수 있습니다. 기술적으로 실행 가능하다는 것과 회사가 해당 용도로 써도 된다는 것은 별개의 판단입니다.
다섯 번째 관문: 승인된 묶음만 배포한다
검증을 통과한 파일은 내부 승인 저장소에 올리고, 배포 선언서에는 모델 파일 해시, 토크나이저·설정 버전, 추론 컨테이너 이미지 식별자, 평가 보고서, 승인자를 연결합니다. 운영 서버는 인터넷에서 임의로 최신 파일을 내려받지 않고, 이 선언서에 명시된 불변 산출물만 가져오도록 합니다.
배포도 한 번에 전체 트래픽을 바꾸지 않습니다. 소수 요청이나 내부 테스트에서 시작해 실제 오류와 지연을 살펴보고 확대합니다. 품질이나 보안 지표가 기준을 벗어나면 이전에 검증된 묶음으로 돌아갈 수 있어야 합니다. 여기서 롤백은 가중치 한 파일만 되돌리는 일이 아닙니다. 토크나이저, 설정, 컨테이너를 함께 맞추지 않으면 이전 버전의 동작을 재현하지 못할 수 있습니다.
이 방식은 보안뿐 아니라 장애 대응에도 효과가 있습니다. 사용자가 “어제와 오늘 답변이 달라졌다”고 말할 때 모델 해시와 토크나이저·프롬프트·코드 버전 중 무엇이 바뀌었는지 확인할 수 있기 때문입니다. 모델의 출처 이력이 운영의 재현성으로 이어집니다.
우리 회사 업무에 적용하면 어디서 시작할까
기업용 RAG, 사내 AI 에이전트, 제조 비전 AI 중 무엇을 만들든 외부 모델을 가져오는 지점은 있습니다. 새 모델을 실험하는 팀과 운영에 올리는 팀이 같은 파일을 보고 있는지부터 확인해 봅니다. 실무에서 처음 시작한다면 아래 여섯 가지를 최소 기준으로 삼을 수 있습니다.
- 모델 목록: 운영 중인 모델의 제공자, 용도, 리비전, 파일 해시를 한곳에 기록합니다.
- 반입 경로: 외부 다운로드 권한을 제한하고, 승인되지 않은 저장소의 파일은 격리합니다.
- 안전한 로드: 가능한 경우 텐서 전용 형식과 제한된 로더를 사용하고, 사용자 코드 실행이 필요한 경우 별도 검토합니다.
- 증거 연결: 가중치·설정·토크나이저·컨테이너·평가 결과를 하나의 배포 단위로 묶습니다.
- 검증과 승인: 무결성·서명자·라이선스·품질을 서로 다른 체크 항목으로 둡니다.
- 운영 복귀: 새 버전의 확대 기준과 이전 승인 버전으로 돌아가는 절차를 시험합니다.
규모가 작다면 거창한 시스템부터 만들 필요는 없습니다. 처음에는 승인된 저장소와 파일 해시 목록, 간단한 평가 보고서, 배포 전 검증 자동화만으로도 “누가 어떤 모델을 운영에 넣었는가”를 설명할 수 있습니다. 이후 모델 수와 담당 팀이 늘어나면 서명 검증과 provenance 정책, 승인 워크플로를 더 체계화하면 됩니다.
결국 모델 배포는 신뢰의 연결고리를 만드는 일이다
모델 파일이 안전한 형식인지, 서명이 있는지, 성능이 좋은지는 각각 중요한 질문입니다. 그러나 어느 하나만 통과했다고 운영 준비가 끝나지는 않습니다. 외부 반입부터 실제 추론까지 이어지는 체인 안에서 파일이 바뀌지 않았고, 기대한 사람이 만든 승인된 버전이며, 우리 업무에서 검증됐고, 문제 발생 시 되돌릴 수 있어야 합니다.
모델을 운영 자산으로 다루는 가장 쉬운 시작점은 정확한 리비전과 해시를 고정하고, 그 파일을 어떤 코드·설정·평가와 함께 배포했는지 기록하는 것입니다. 그 기록이 있어야 보안도, 품질 개선도, 사고 대응도 같은 사실에서 출발할 수 있습니다.
참고 자료
#AI보안 #모델공급망 #모델보안 #MLOps #LLMOps #오픈모델 #safetensors #PyTorch #Sigstore #SLSA #모델배포 #AI거버넌스
