リポジトリとは結局インデックスファイル一つだ

한 줄 요약

apt 저장소의 실체는 .deb 파일이 놓인 디렉터리 + Packages 라는 색인 파일이다. 그것만 있으면 file:/// 도 훌륭한 저장소가 된다.

왜 이게 필요했나

폐쇄망, 에어갭, 사내 표준 이미지, CI 캐시 — 인터넷에 나가지 못하거나 나가면 안 되는 환경은 생각보다 흔하다. 이때 선택지는 두 개다. 필요한 .deb 를 하나씩 손으로 옮기거나, 저장소 자체를 안쪽에 세우거나. 첫 번째는 세 번쯤 반복하면 못 견디게 되고, 두 번째는 한 번 만들면 계속 쓴다.

어떻게 동작하나

apt 가 저장소에서 실제로 읽는 것은 놀랄 만큼 단순하다.

저장소 루트/
  Packages         <- 각 .deb 의 control 필드 + Filename + Size + SHA256
  Packages.gz      <- 위의 압축본 (apt 는 압축본을 선호한다)
  Release          <- 저장소 메타데이터 (Origin, Suite, Components, 체크섬)
  *.deb            <- 실제 패키지 파일

Packages 는 각 패키지의 control 필드를 이어 붙이고 여기에 Filename(저장소 루트 기준 상대 경로), Size, SHA256 을 더한 텍스트 파일이다. 이걸 만들어 주는 도구가 dpkg-scanpackages(간단) 와 apt-ftparchive(대규모) 다.

cd /root/repo
dpkg-scanpackages . /dev/null > Packages
gzip -kf Packages

그리고 sources.list 한 줄을 추가한다.

deb [trusted=yes] file:/root/repo ./

마지막의 ./ 가 flat 저장소(dists/ 계층 없이 루트에 Packages 가 있는 형태)를 뜻한다. [trusted=yes] 는 GPG 서명이 없는 저장소를 신뢰하겠다는 표시다. 실습이나 사내 임시 저장소에서는 흔히 쓰지만, 운영 저장소라면 반드시 서명해야 한다. 서명 없는 저장소는 중간에 누가 .deb 를 바꿔치기해도 알 수 없다.

여기서 두 층의 검증을 구분해야 한다.

층	무엇을 보증하나	도구
체크섬(SHA256)	전송 중 손상이 없었다	sha256sum -c
서명(GPG)	출처가 내가 아는 그곳이다	gpg --verify, apt-key/signed-by

같은 매체에만 담긴 체크섬은 매체가 통째로 바뀌면 함께 바뀐다. 그래서 무결성의 마지막 보루는 항상 서명이다.

현장에서 만나는 모습

"저장소에 패키지를 넣었는데 서버에서 안 보인다." 폐쇄망 운영에서 가장 많이 들어오는 신고다. 원인의 대부분은 둘 중 하나다. 색인을 다시 만들지 않았거나(dpkg-scanpackages / createrepo_c --update 를 빼먹음), 클라이언트가 캐시를 갱신하지 않았거나(apt-get update 를 안 함). 둘 다 "파일은 분명히 거기 있는데" 라는 억울한 상황을 만든다.

저장소 이름에 스냅샷 날짜를 박아 두는 습관. name=LabHub local (snapshot 2026-08-15) 처럼 적어 두면, 6개월 뒤 "이 서버는 언제 시점의 콘텐츠로 설치됐지?" 라는 질문에 apt-cache policy 한 줄로 답할 수 있다.

폐쇄망 반입을 절차로 만들기

앞 모듈에서 USB 를 서너 번 왕복하는 이야기를 했다. 그것을 없애려면 반입을 즉흥적인 심부름이 아니라 재현되는 절차로 만들어야 한다. 요령은 "무엇을 가져갈지" 를 바깥에서 기계적으로 계산해 두는 것이다.

의존성을 통째로 푼 결과를 받는다. 바깥의 같은 배포판·같은 버전 환경에서 필요한 패키지를 설치해 보고, 그때 받아진 모든 파일을 모은다. 실제로 설치까지 해 보는 것이 중요하다. 목록만 계산하면 안쪽 환경에 이미 있는 것과 없는 것의 차이 때문에 어긋나기 쉽다. 그래서 안쪽과 같은 상태의 컨테이너를 바깥에 하나 만들어 두는 것이 이 작업의 핵심 장치다.

번들에 매니페스트를 함께 넣는다. 파일 목록, 각 파일의 체크섬, 어느 배포판·어느 시점의 저장소에서 받았는지, 그리고 무엇을 설치하려던 것인지. 이 문서가 없으면 몇 달 뒤 그 USB 가 무엇인지 아무도 모른다.

안쪽에서 검증하고 설치한다. 매니페스트의 체크섬으로 전송 손상을 확인하고, 가능하면 서명까지 확인한 뒤 저장소를 갱신한다. 앞에서 본 대로 체크섬은 손상만, 서명은 출처를 보증한다.

설치 결과를 기록으로 남긴다. 어느 서버에 언제 어떤 번들을 넣었는지가 남아 있어야, 다음에 문제가 생겼을 때 "이 서버는 어느 시점의 것" 인지를 답할 수 있다. 앞에서 말한 저장소 이름에 스냅샷 날짜를 박아 두는 습관이 이 기록의 가장 값싼 형태다.

이 절차의 값어치는 시간 절약만이 아니다. 폐쇄망에서 가장 위험한 것은 급하다는 이유로 검증을 건너뛰는 것이고, 절차가 문서로 있으면 급할 때도 건너뛸 단계가 무엇인지 스스로 알게 된다.

다음 실습에서 할 것

두 개의 실습을 이어서 한다. 먼저 직접 빌드한 .deb 로 flat 저장소를 세워 설치까지 하고, 그다음에는 이미 설치된 패키지의 의존성을 통째로 내려받아 매니페스트와 체크섬을 갖춘 반입 번들을 만들어 오프라인 설치를 재현한다.