[개발 일지] 큰 파일을 앱에 넣지 않기로 했다: 받은 것을 계속 아는 상태 만들기

큰 모델 파일을 앱에 넣지 않고 필요할 때 내려받게 한 결정을 나타낸 대표 이미지
앱은 가볍게 두고, 무거운 것은 필요할 때만 받습니다.

앱 안에 큰 파일을 넣을지 말지는 생각보다 큰 결정이었습니다. AI 모델 파일은 수백 메가에서 기가 단위입니다. 앱에 통째로 넣으면 설치가 확실하지만 쓰지도 않을 사람까지 그 용량을 받게 됩니다. 저는 넣지 않기로 했고, 대신 지켜야 할 조건을 몇 가지 붙였습니다.

왜 넣지 않았나

이유는 세 가지였습니다.

  • 설치 용량 — 앱을 깔자마자 기가 단위를 차지하면 지워질 확률이 올라갑니다.
  • 기기마다 필요한 것이 다름 — 성능이 낮은 기기와 높은 기기가 쓰는 모델이 다릅니다. 전부 넣으면 대부분이 낭비입니다.
  • 교체 — 모델은 계속 바뀝니다. 앱에 넣어 두면 모델을 바꿀 때마다 앱 전체를 다시 배포해야 합니다.
목록 확인, 버전 고정 내려받기, 무결성 검증, 실행으로 이어지는 절차
받는 순간이 아니라 검증까지 끝나야 실행합니다.

대신 붙인 조건

필요할 때 받는 방식은 편하지만 “무엇을 받았는지 모르는 상태”가 되기 쉽습니다. 그래서 세 가지를 걸었습니다.

첫째, 목록을 따로 관리합니다. 어떤 모델이 있고 어디서 받는지, 크기와 라이선스가 무엇인지를 한 곳에 적어 두었습니다. 코드 여기저기에 주소가 흩어지지 않게 하기 위해서입니다.

둘째, 버전을 고정합니다. “최신”을 가리키는 이름으로 받지 않고 특정 시점을 콕 집어 받습니다. 최신으로 받으면 어제와 오늘 받은 파일이 달라질 수 있고, 그러면 문제가 생겼을 때 무엇이 바뀌었는지 추적할 수 없습니다.

셋째, 받은 뒤 검증합니다. 목록에 적어 둔 해시값과 실제로 받은 파일을 비교해서, 다르면 쓰지 않습니다. 큰 파일은 받다가 깨져도 겉으로는 멀쩡해 보입니다.

받은 파일이 같은지 확인하는 방법: 공식 문서가 설명하는 해시 비교

해시 검증은 새로운 아이디어가 아니라 공식 문서가 이미 설명하는 표준적인 방법입니다. 마이크로소프트의 PowerShell 문서에 따르면 Get-FileHash 명령은 지정한 해시 알고리즘으로 파일의 해시값을 계산합니다. 파일 이름이나 확장자가 같아도 내용이 한 글자만 달라지면 해시값이 달라지고, 두 파일의 해시값이 같으면 내용도 같다고 볼 수 있습니다. 알고리즘을 따로 지정하지 않으면 기본값은 SHA256이며, 선택할 수 있는 값은 SHA1, SHA256, SHA384, SHA512, MD5입니다. 같은 문서는 MD5와 SHA1이 더 이상 안전하다고 보지 않으므로 단순한 변경 확인에만 쓰고, 변조 방지가 필요한 파일에는 쓰지 말라고 안내합니다. 릴리스 페이지에 게시된 SHA256 값과 직접 계산한 값을 비교하는 예시도 실려 있습니다.

웹 쪽에도 같은 원리가 있습니다. MDN 문서의 Subresource Integrity는 CDN처럼 외부에서 받은 자원이 조작되지 않았는지 브라우저가 확인하는 기능입니다. integrity 속성에는 sha256, sha384, sha512 중 하나의 접두어와 base64로 인코딩한 해시값을 적습니다. 해시가 기대한 값과 맞지 않으면 브라우저는 그 자원을 불러오지 않고 네트워크 오류를 돌려줍니다. 큰 모델 파일을 필요할 때 내려받는 앱이 “목록에 적힌 해시와 다르면 쓰지 않는다”는 규칙을 두는 것도 같은 논리입니다.

공식 문서설명하는 내용이 글의 조건과 연결되는 점
Microsoft Learn, Get-FileHash파일 내용으로 해시를 계산하며 기본 알고리즘은 SHA256목록에 적어 둔 해시와 받은 파일의 해시를 비교
Microsoft Learn, Get-FileHashMD5·SHA1은 단순 변경 확인용으로만 권장검증에는 SHA256 이상을 쓰는 편이 안전
MDN, Subresource Integrity해시가 맞지 않으면 자원을 불러오지 않음불일치하면 모델을 실행하지 않음
MDN, Subresource Integrity여러 해시 중 가장 강한 알고리즘의 해시만 사용알고리즘 이름을 목록에 함께 적어 둠

위 설명은 2026년 10월 18일 기준 두 공식 문서의 기재 내용을 옮긴 것입니다. 앱이 실제로 어떤 알고리즘을 쓰는지는 각자의 구현에 따라 다르므로, 이 표는 방식의 근거를 보여 주는 용도로만 보시면 됩니다.

라이선스도 목록에 넣었다

처음에는 빠뜨렸던 항목입니다. 모델마다 쓸 수 있는 조건이 다릅니다. 상업적으로 자유로운 것도 있고, 조건이 붙는 것도 있습니다.

이걸 코드로 관리하지 않으면 나중에 “이 모델 써도 되나”를 사람이 매번 기억해야 합니다. 그래서 목록에 라이선스를 함께 적고, 조건이 붙은 모델은 자동으로 받아 실행하지 않도록 따로 표시해 두었습니다.

목록 관리, 버전 고정, 무결성 검증, 라이선스 표기의 네 가지 조건
네 가지를 지키면 나중에 무엇을 받았는지 되짚을 수 있습니다.

정리하면

“필요할 때 받는다”는 선택 자체는 어렵지 않습니다. 어려운 것은 받은 것이 무엇인지 계속 알고 있는 상태를 유지하는 일입니다. 목록·버전 고정·검증·라이선스, 이 네 가지가 그 상태를 만들어 줍니다.

아직 실제 기기에서 대용량 파일을 받는 동안의 실패 처리와 재시도는 충분히 시험하지 못했습니다. 그 부분은 미검증으로 남겨 두었습니다.

확인 자료