저장소는 결국 색인 파일 하나다

한 줄 요약

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/repodpkg-scanpackages . /dev/null > Packagesgzip -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 한 줄로 답할 수 있다.

다음 실습에서 할 것

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