프롤로그 — 레지스트리는 이미지 창고가 아니다

2015년에 컨테이너 레지스트리는 단순했다. `docker push` 한 줄, 그게 전부였다. Docker Hub가 사실상 유일했고, 사내 셀프호스팅이 필요하면 `registry:2` 컨테이너 하나 띄우면 끝났다.

2026년의 풍경은 다르다.

- **Docker Hub**의 가격 정책 변화 이후 — 무료 organization의 push pull 제한이 강화되면서 OSS 프로젝트들이 줄줄이 GHCR로 옮겼다.

- **GHCR**가 사실상 OSS 컨테이너의 기본값이 되었다. GitHub Actions와 한 몸이고, public 이미지는 무료, 인증은 `GITHUB_TOKEN` 하나로 끝난다.

- **ECR Public**이 무료 Quay의 대안으로 자리잡았다. AWS 계정 하나로 무료 글로벌 배포.

- **Harbor**가 CNCF graduated 프로젝트가 되어 셀프호스팅 표준이 되었다. 쿠버네티스 위의 사내 레지스트리는 거의 다 Harbor다.

- **Zot**이 CNCF incubating으로 올라오면서 OCI-only 단순성을 무기로 emerging 영역을 차지했다.

- **Cosign + Sigstore**가 서명의 사실상 표준이 되었다. SLSA Level 3 빌드의 기본 도구다.

- **ORAS**가 컨테이너 이미지 외의 모든 것 — Helm chart, WASM module, ML model, Terraform module — 을 OCI artifact로 저장하게 만들었다.

- **SBOM(CycloneDX, SPDX)** 이 레지스트리에 부착되어, 이미지를 받는 순간 무엇이 들어 있는지 알 수 있다.

이제 레지스트리는 **이미지 저장소가 아니라 공급망 보안의 중심 허브**다. 누가 빌드했고, 무엇이 들어 있고, 어디서 검증되었는지가 — 매니페스트와 함께 — 레지스트리에서 산다.

이 글은 13개 레지스트리·서명 도구·SBOM 표준을 한 호흡에 비교한다. 단순한 기능표가 아니라, "왜 어떤 팀이 어떤 선택을 했는가"를 따라간다.

1장 · 2026년 컨테이너 레지스트리 지도 — 매니지드 / 셀프호스팅 / 무료 OSS 3진영

먼저 한 장의 지도.

[컨테이너 레지스트리 2026]

|

+---------------------+---------------------+

| | |

[매니지드 SaaS] [셀프호스팅 OSS] [무료 OSS 호스팅]

| | |

- Docker Hub - Harbor (CNCF) - GHCR (public free)

- GHCR (private 유료) - Zot (CNCF) - ECR Public

- GitLab Registry - Distribution - Quay.io (OSS 무료)

- AWS ECR - Artifactory CE - Docker Hub (public)

- Google AR - Nexus

- Azure ACR

- Quay.io (Red Hat)

- Artifactory (JFrog)

세 진영의 핵심 차이는 단순하다.

1. **매니지드 SaaS** — 클라우드 사업자가 운영, 청구서로 비용. 가용성 책임은 사업자가 진다. 트레이드오프는 가격과 멀티클라우드 이식성.

2. **셀프호스팅 OSS** — 직접 운영, 인프라 비용만. 가용성과 보안의 책임은 본인. 트레이드오프는 운영 부담.

3. **무료 OSS 호스팅** — OSS 프로젝트는 공개 저장소를 무료로 호스팅 받는다. private은 별도 비용 또는 제한.

2026년의 새로운 흐름은 **"이 셋이 더 이상 분리되지 않는다"** 는 것이다.

- GitHub Actions가 빌드한 이미지를 GHCR에 push하고, ECR로 mirror하고, Harbor에 caching pull-through proxy로 연결한다.

- Docker Hub의 가격 변화로 OSS 프로젝트들이 GHCR과 Quay.io로 옮겼지만, 사용자 docker pull은 여전히 Docker Hub로도 간다 — `library/nginx` 같은 official image는 거기 산다.

- 엔터프라이즈는 Artifactory 위에 Harbor를 두거나, ACR을 메인으로 두고 ECR을 mirror로 둔다.

레지스트리는 **하나만 고르는 것이 아니라, 토폴로지로 설계하는 것**이 되었다.

기억할 한 줄: **"2026년 레지스트리 선택은 단일 선택이 아니라 멀티-레지스트리 토폴로지의 설계다."**

2장 · Docker Hub — 원조, 가격 변화 이후

Docker Hub은 컨테이너 레지스트리의 원조다. `docker pull nginx` 한 줄이 자동으로 가는 곳이고, Official Images(공식 이미지)의 정전이다.

2026년 Docker Hub의 위상

- 여전히 **public image의 기본 destination** — `library/`, `bitnami/`, `library/python` 같은 검증된 이미지는 여기 있다.

- Official Images 프로그램은 여전히 강력하다 — Docker가 직접 빌드·서명하는 이미지셋.

- 가격 정책이 여러 차례 바뀌었다. 무료 Team의 pull/push 제한, 무료 organization의 image retention, 비활성 이미지 자동 삭제 등이 적용 또는 철회를 반복했다.

가격 정책 변화의 임팩트

- 2023년의 무료 organization 변경 발표 → OSS 커뮤니티 반발 → 부분 철회 → 이후 단계적 제한.

- 무료 인증 사용자 pull은 시간당 100 이미지(인증), 200 이미지(인증된 무료). 비인증은 IP 기반.

- 무료 organization의 unlimited public repo는 유지되지만, 비공개 저장소 수와 자동 빌드는 제한.

- **결과**: OSS 프로젝트들이 GHCR, Quay.io, ECR Public으로 분산. Docker Hub은 여전히 "기본 destination"이지만 "유일한 destination"은 아니다.

그래도 Docker Hub인 이유

- **Discoverability** — 사람들이 첫 번째로 찾는 곳. brand recognition.

- **Official Images** — 수년간 쌓인 검증된 이미지 카탈로그.

- **Docker Desktop 통합** — `docker login` 한 줄로 push.

- **자동 빌드(Automated Build)** — GitHub/GitLab 연동 빌드.

`docker push` 기본 흐름

1. 로그인

docker login docker.io

Username, Password (또는 PAT)

2. tag

docker tag myapp:latest myorg/myapp:v1.0.0

3. push

docker push myorg/myapp:v1.0.0

4. pull (다른 곳에서)

docker pull myorg/myapp:v1.0.0

Pull-through cache의 부상

레지스트리 hop을 줄이기 위해, 많은 팀이 사내 Harbor/Zot을 Docker Hub의 pull-through cache로 둔다. 한 번 받은 이미지는 사내에 캐싱되어, 다음부터는 Docker Hub의 rate limit을 신경 쓸 필요가 없다.

Harbor config — Docker Hub proxy

proxy:

remote_url: https://registry-1.docker.io

username: ""

password: ""

Docker Hub의 자리

**무료 OSS 단일 정전이었던 시절은 끝났다.** 그러나 "공개 이미지를 사람들에게 노출시키고 싶을 때 무시할 수 없는 곳"이라는 위상은 유지된다. 2026년 패턴은 흔히 이렇다: GHCR에 빌드·push → Docker Hub에도 mirror → README에 둘 다 표기.

3장 · GitHub Container Registry (GHCR) — GH Actions 친화

GHCR는 GitHub Packages의 컨테이너 부분이다. 2021년 GA 이후 2026년에 OSS 레지스트리의 사실상 표준이 되었다.

GHCR의 강점

- **GitHub Actions와 한 몸** — `GITHUB_TOKEN`으로 별도 자격증명 없이 push. OIDC로 외부 인프라에도 federate.

- **Public 이미지 무료** — 저장과 트래픽 무제한.

- **Repository 권한 자동 상속** — 코드 repo에 access 있으면 이미지도 pull 가능.

- **OCI 1.1 완벽 지원** — Cosign signature, SBOM attachment, multi-arch 모두 자연스럽다.

Actions에서 push하는 표준 패턴

.github/workflows/build.yml

name: build-and-push

on:

push:

branches: [main]

permissions:

contents: read

packages: write

id-token: write # OIDC용

jobs:

build:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- uses: docker/setup-buildx-action@v3

- uses: docker/login-action@v3

with:

registry: ghcr.io

username: $GITHUB_ACTOR

password: $GITHUB_TOKEN

- uses: docker/build-push-action@v5

with:

push: true

tags: ghcr.io/myorg/myapp:latest

platforms: linux/amd64,linux/arm64

`ghcr.io/owner/image` 명명 규칙

GHCR의 이미지 경로는 정해진 형식이다:

- `ghcr.io/USERNAME/IMAGE_NAME` (개인 계정)

- `ghcr.io/ORG_NAME/IMAGE_NAME` (조직 계정)

이 단순함이 강력하다. `git clone github.com/foo/bar` 한 사용자는 `docker pull ghcr.io/foo/bar` 도 할 줄 안다.

Private 이미지 가격

- Private 이미지는 GitHub 플랜에 묶인다.

- Storage와 data transfer 비용이 부과되며, GitHub plan에 따른 무료 quota가 있다.

- 무료 quota 초과 시 GB-month 기반으로 청구.

GHCR의 한계

- **Pull 성능** — Docker Hub와 거의 동등, 단 트래픽 폭주에는 Cloudflare 캐시에 의존.

- **사내 셀프호스팅 불가** — 매니지드 only.

- **Tag immutability** — repository-wide만 가능, 세밀한 정책은 부족.

OSS 마이그레이션의 표준 경로

Docker Hub에서 GHCR로 옮기는 OSS 프로젝트의 표준 경로:

1. GitHub Actions로 멀티 아키텍처 빌드.

2. `ghcr.io/owner/project:tag`로 push.

3. README에 pull 명령을 GHCR 우선으로 갱신.

4. Docker Hub에도 mirror push (이중 게재).

5. Cosign keyless로 signature 부착.

기억할 한 줄: **"GHCR는 GitHub Actions를 쓰는 OSS의 사실상 표준이다. 빌드 자격증명 한 줄로 push 끝."**

4장 · GitLab Container Registry

GitLab 내장 컨테이너 레지스트리는 별도 설정 없이 GitLab 프로젝트마다 따라온다.

GitLab Registry의 강점

- **프로젝트 단위 자동 분리** — `registry.gitlab.com/group/project/image:tag` 경로 그대로.

- **CI/CD와 깊은 통합** — `$CI_REGISTRY`, `$CI_REGISTRY_USER`, `$CI_REGISTRY_PASSWORD` 환경변수가 자동 주입.

- **Cleanup policy** — 프로젝트마다 retention rule을 GUI로 설정.

- **Self-managed GitLab도 동일** — GitLab CE를 사내에 깔면 레지스트리도 같이 온다.

`.gitlab-ci.yml` 표준 push 패턴

build:

image: docker:24.0.5

services:

- docker:24.0.5-dind

variables:

DOCKER_TLS_CERTDIR: "/certs"

script:

- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .

- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

- docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA $CI_REGISTRY_IMAGE:latest

- docker push $CI_REGISTRY_IMAGE:latest

Dependency Proxy

GitLab은 Docker Hub의 pull-through proxy를 group 단위로 내장한다.

Docker Hub의 nginx를 GitLab proxy 경유로 받기

docker pull gitlab.com/myorg/dependency_proxy/containers/nginx:latest

이는 GitLab 그룹 단위 인증으로, Docker Hub rate limit을 우회한다.

Cleanup Policy

프로젝트 설정 > Packages and registries > Container Registry

Cleanup policy (UI에서 설정, API/Terraform으로도 가능)

keep_n_tags_older_than: 1d

older_than: 30d

name_regex_keep: "release-.*"

name_regex_delete: ".*"

90% 사용 사례를 커버하는 간단한 정책 엔진이다.

GitLab Registry의 자리

**GitLab을 이미 쓰는 팀의 자연스러운 선택**이다. CI와 권한 모델이 한 곳에서 통합된다. Self-managed로도 동일 경험. 다만 GitLab 외부 사용자에게 노출하기엔 GHCR보다 discoverability가 낮다.

5장 · AWS ECR + ECR Public — 무료 quay 대안

ECR(Elastic Container Registry)은 AWS의 private 컨테이너 레지스트리다. 2020년 ECR Public이 추가되며 public 영역도 커버한다.

ECR의 강점

- **IAM 통합** — IAM role/policy 기반 정밀 인증. EKS pod에 IRSA(IAM Roles for Service Accounts)로 자격증명 주입.

- **Cross-region replication** — 멀티 리전 자동 복제.

- **이미지 스캐닝 내장** — Amazon Inspector 통합, CVE 자동 검사.

- **Pull-through cache** — Docker Hub·GHCR·Quay·Microsoft mcr.microsoft.com을 캐싱.

- **Lifecycle policy** — JSON DSL로 retention 정책.

`aws ecr get-login-password` 흐름

1. 로그인 (12시간 유효 토큰)

aws ecr get-login-password --region us-east-1 \

| docker login --username AWS --password-stdin \

123456789012.dkr.ecr.us-east-1.amazonaws.com

2. repository 생성 (autoCreate도 가능)

aws ecr create-repository --repository-name myapp

3. push

docker tag myapp:latest 123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:v1

docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:v1

Lifecycle Policy 예시

{

"rules": [

{

"rulePriority": 1,

"description": "Keep last 10 production images",

"selection": {

"tagStatus": "tagged",

"tagPrefixList": ["prod-"],

"countType": "imageCountMoreThan",

"countNumber": 10

},

"action": { "type": "expire" }

},

{

"rulePriority": 2,

"description": "Expire untagged after 7 days",

"selection": {

"tagStatus": "untagged",

"countType": "sinceImagePushed",

"countUnit": "days",

"countNumber": 7

},

"action": { "type": "expire" }

}

]

}

ECR Public — 무료 OSS 호스팅

`public.ecr.aws/`는 AWS 계정 하나만 있으면 OSS 이미지를 무료로 글로벌 호스팅한다.

- 저장 무료 (50 GB / repo 권장 한도).

- Data transfer 무료 (anonymous pull도 무료).

- 별도 도메인(`public.ecr.aws/aws/amazonlinux:2023` 같은).

OSS 프로젝트가 Docker Hub rate limit과 GHCR private 비용을 우회하려고 ECR Public을 추가하는 패턴이 일반적이다.

ECR의 한계

- **AWS lock-in** — multi-cloud 사용 시 별도 push 필요.

- **요청량 기반 비용** — pull 요청에도 가격이 매겨질 수 있다(public은 무료).

- **UI는 콘솔 only** — Harbor·GitLab 같은 풀 GUI 부재.

ECR의 자리

**AWS에서 EKS·ECS·Lambda를 돌리는 팀의 기본값.** IRSA와의 결합이 압도적으로 깔끔하다. OSS는 ECR Public을 보조 destination으로 두는 것이 좋다.

6장 · Google Artifact Registry — GCR 후속

Google Artifact Registry(AR)는 Google Container Registry(GCR)의 공식 후속이다. GCR(`gcr.io`)은 deprecated되어 Artifact Registry로의 마이그레이션이 강하게 권장된다.

AR이 GCR을 대체한 이유

- **다중 포맷** — 컨테이너만이 아니라 Maven, npm, Python, Go, Helm, Debian, RPM, Apt까지 한 레지스트리에서.

- **VPC Service Controls** — 네트워크 경계 정책.

- **CMEK(고객 관리 암호화 키)** — 미세한 암호화 제어.

- **Regional/Multi-regional repo** — GCR보다 정밀한 지역 선택.

- **IAM 정밀 권한** — repo 단위 권한 분리.

GCR 마이그레이션

기존 gcr.io 이미지를 AR로 마이그레이션

gcloud artifacts docker upgrade migrate \

--projects=my-project

새 AR repo 생성

gcloud artifacts repositories create myrepo \

--repository-format=docker \

--location=us-central1 \

--description="Docker repo"

인증 헬퍼 설정

gcloud auth configure-docker us-central1-docker.pkg.dev

push

docker tag myapp:latest \

us-central1-docker.pkg.dev/my-project/myrepo/myapp:v1

docker push us-central1-docker.pkg.dev/my-project/myrepo/myapp:v1

GKE Workload Identity Federation

Kubernetes ServiceAccount → GCP ServiceAccount 매핑

apiVersion: v1

kind: ServiceAccount

metadata:

name: app-sa

namespace: default

annotations:

iam.gke.io/gcp-service-account: my-gcp-sa@my-project.iam.gserviceaccount.com

이걸 통해 GKE pod가 별도 secret 없이 AR에서 pull한다.

AR의 강점

- **Container Analysis 통합** — 자동 vulnerability scan.

- **Binary Authorization** — admission control로 서명된 이미지만 배포 허용.

- **Cosign 지원** — keyless 서명을 GAR에 부착.

- **Remote/Virtual repo** — Docker Hub의 pull-through proxy.

AR의 자리

**GKE 위주 GCP 사용자의 자연스러운 선택.** Binary Authorization과 결합하면 admission 단계에서 서명·취약점·정책을 한꺼번에 검사할 수 있다.

7장 · Azure Container Registry (ACR)

ACR은 Azure의 매니지드 컨테이너 레지스트리다. AKS, App Service, Functions, Container Apps 등 Azure의 모든 컨테이너 워크로드의 기본 source다.

ACR의 강점

- **Geo-replication** — Premium 티어에서 글로벌 자동 복제, single endpoint URL.

- **ACR Tasks** — 레지스트리 내부 빌드(클라우드 사이드 빌드).

- **Content trust(Notary v1) 와 Cosign 모두 지원.**

- **Helm chart, OCI artifact 지원.**

- **Private link** — 완전한 사설 네트워크 접근.

`az acr login` 흐름

1. 로그인 (Azure CLI 자격증명 사용)

az acr login --name myregistry

2. ACR 리포 push

docker tag myapp:latest myregistry.azurecr.io/myapp:v1

docker push myregistry.azurecr.io/myapp:v1

3. AKS에서 pull (Managed Identity)

ImagePullSecret 없이 IAM 통합 사용

ACR Tasks — 레지스트리 내부 빌드

Git commit에 대응해 자동 빌드

az acr task create \

--name buildmyapp \

--registry myregistry \

--image myapp:$ID \

--context https://github.com/myorg/myapp.git \

--file Dockerfile \

--git-access-token $TOKEN

이 모델은 빌드 머신을 별도로 둘 필요가 없다. Buildah 기반 cloud-side build.

Retention policy

az acr config retention update \

--registry myregistry \

--status enabled \

--days 30 \

--type UntaggedManifests

한국 / 일본 사용

- **카카오 페이**는 Azure를 메인 클라우드 중 하나로 사용하며 ACR로 사내 이미지를 관리한다(공개된 컨퍼런스 발표 기반).

- 일본 게임사 일부도 Azure를 메인으로 두고 ACR을 사용.

ACR의 자리

**AKS·Azure DevOps를 쓰는 팀의 기본값.** Geo-replication이 single endpoint URL로 동작하는 점은 ECR보다 운영이 단순하다.

8장 · Harbor (CNCF graduated) — 셀프호스팅의 표준

Harbor는 VMware가 시작해 CNCF로 기증된 OSS 레지스트리다. 2020년 CNCF graduated 프로젝트가 되었고, 2026년 셀프호스팅 표준이 되었다.

Harbor가 셀프호스팅 표준이 된 이유

- **풀 GUI** — 사용자·프로젝트·권한·정책·복제까지 웹 UI로.

- **Project 단위 격리** — multi-tenancy.

- **Vulnerability scanner 통합** — Trivy 기본, Clair·Snyk·Anchore도 plugin.

- **Cosign·Notary 지원** — 서명 검증을 admission 단계에 통합.

- **Replication policy** — Docker Hub, GHCR, ECR, GAR, ACR, Quay 등으로 단방향/양방향 복제.

- **Proxy cache** — 외부 레지스트리의 pull-through cache.

- **Robot account** — CI용 long-lived 자격증명, 권한 정밀 조정.

Harbor 설치 (Helm)

helm repo add harbor https://helm.goharbor.io

helm install harbor harbor/harbor \

--namespace harbor --create-namespace \

--set expose.type=ingress \

--set expose.ingress.hosts.core=harbor.example.com \

--set externalURL=https://harbor.example.com \

--set persistence.persistentVolumeClaim.registry.size=200Gi \

--set persistence.persistentVolumeClaim.chartmuseum.size=10Gi \

--set persistence.persistentVolumeClaim.trivy.size=20Gi

Project · Robot · Replication 전형 구조

[Harbor Project: production]

├─ Member: dev-team (Developer)

├─ Member: ops-team (Master)

├─ Robot: ci-build (push)

├─ Robot: ci-deploy (pull)

├─ Vulnerability Scanner: Trivy

├─ Cosign Signature: required (deploy 시 검증)

└─ Replication:

└─ to: ghcr.io/myorg (push, on push)

└─ from: docker.io/library/* (pull, on demand)

Pull-through Proxy Cache

Harbor Project = "dockerhub-proxy"

외부 endpoint: https://registry-1.docker.io

Cache TTL: 24h

사용자 사용:

docker pull harbor.example.com/dockerhub-proxy/library/nginx:latest

첫 pull → Docker Hub 거쳐서 캐싱

둘째 pull → Harbor 내부에서 바로

이 패턴 하나로 Docker Hub rate limit이 해결된다.

Harbor의 한계

- **운영 부담** — Postgres·Redis·Trivy·Notary·Chartmuseum 등 여러 컴포넌트.

- **upgrade 까다로움** — 메이저 버전 간 schema 변경이 종종 있다.

- **자체 backup 전략 필요** — 이미지 blob과 메타데이터 모두.

Harbor의 자리

**셀프호스팅 컨테이너 레지스트리의 기본값.** GUI와 replication이 강력해서 운영팀이 비개발자여도 사용 가능. 대형 사내 인프라에서 흔히 쓰인다.

9장 · Quay (Red Hat / IBM)

Quay는 Red Hat이 인수한 컨테이너 레지스트리다. Quay.io는 매니지드 SaaS, Red Hat Quay는 셀프호스팅 enterprise edition, Project Quay는 OSS upstream.

Quay의 강점

- **OpenShift와 한 몸** — OpenShift 사용 시 자연스러운 선택.

- **Quay.io OSS free** — public repository는 무료(특히 Red Hat ecosystem).

- **OSS organization 무료 unlimited private** — 일부 OSS 프로젝트에 제공.

- **Clair scanner 내장** — Quay 팀이 만든 vulnerability scanner.

- **Geo-replication** — multi-region replication 내장.

- **Notary v2 + Cosign 지원.**

Quay 사용 패턴

Quay.io

docker login quay.io

docker push quay.io/myorg/myapp:v1

Self-managed Red Hat Quay

docker login quay.mycompany.com

docker push quay.mycompany.com/team/myapp:v1

Robot Account 모델

Harbor와 비슷하다. CI용 장기 토큰을 발급하고, repository 단위 권한을 부여.

Quay의 자리

- **Red Hat ecosystem(OpenShift, RHEL)에서는 기본값.**

- 셀프호스팅 enterprise에서 Harbor와 양분.

- OSS 호스팅으로 Docker Hub의 무료 대안 중 하나.

10장 · Zot (CNCF incubating) — OCI-only 단순

Zot은 OCI-only 컨테이너 레지스트리다. 2024년 CNCF incubating 프로젝트가 되었고, "단순하고 작고 빠른" 셀프호스팅 옵션으로 떠올랐다.

Zot이 단순함의 무기로 부상한 이유

- **OCI distribution spec만 구현** — Docker registry v1, 자체 확장 없음.

- **단일 바이너리** — Go 단일 파일. Postgres·Redis 의존성 없음.

- **읽기 전용 모드** — air-gapped 환경에 적합.

- **Sync** — 다른 레지스트리에서 sync해서 mirror.

- **메타데이터 plugin** — Cosign signature, SBOM 검색.

Zot 실행

단일 binary

./zot serve config.json

config.json

{

"storage": {

"rootDirectory": "/var/lib/zot"

},

"http": {

"address": "0.0.0.0",

"port": "5000"

},

"log": {

"level": "info"

},

"extensions": {

"search": { "enable": true },

"sync": {

"enable": true,

"registries": [

{

"urls": ["https://docker.io"],

"content": [{ "prefix": "library/nginx" }],

"onDemand": true

}

]

}

}

}

이게 전부다. Postgres도, Redis도, 별도 컴포넌트도 없다.

Zot의 자리

- **Air-gapped 환경** — 단일 binary, 읽기 전용 모드.

- **Edge / IoT** — 작은 리소스로 동작.

- **개발 환경 로컬 registry** — Harbor가 과한 경우.

- **GitHub Actions runner에 묶어 일회용 registry로** — 단위 테스트.

기억할 한 줄: **"Harbor가 풀 GUI 종합 레지스트리라면, Zot은 OCI distribution spec의 reference 같은 단순함이다."**

11장 · JFrog Artifactory — 모든 언어 엔터프라이즈

Artifactory는 JFrog의 universal 아티팩트 레지스트리다. Docker 컨테이너만이 아니라 Maven·Gradle·npm·NuGet·PyPI·CocoaPods·Conan·Cargo·Helm 등 모든 패키지 매니저를 한 곳에서 관리한다.

Artifactory의 강점

- **모든 언어 한 곳에서** — 컨테이너만 분리할 필요 없다.

- **Remote repo** — 모든 외부 레지스트리의 pull-through cache.

- **Virtual repo** — 여러 repo를 하나의 endpoint로 묶기.

- **Build info 추적** — 어떤 빌드가 어떤 아티팩트를 생산했는가 그래프.

- **JFrog Xray** — vulnerability scanning, SBOM 통합.

- **JFrog Distribution** — 글로벌 배포 entry point.

- **JFrog Pipelines** — CI/CD 통합.

Artifactory의 자리

- **대형 엔터프라이즈** — 컨테이너 외의 아티팩트가 많을 때.

- **금융권, 통신사, 제조업** — 자바와 컨테이너를 같이 관리할 때.

- **라이선스 비용 부담 가능** — 가격이 부담스러우면 Harbor가 대안.

Artifactory CE — Community Edition

Docker만 무료. 풀 기능은 유료 라이선스 필요.

12장 · Distribution (CNCF) — OCI 참조 구현

Distribution은 Docker가 만든 OSS 레지스트리 구현이다. 2018년 CNCF로 기증되어 Distribution이라는 이름으로 재출범, OCI distribution spec의 reference implementation 역할을 한다.

Distribution의 자리

- **`registry:2` 컨테이너** — 가장 단순한 사내 레지스트리.

- **OCI spec reference** — spec 변경 시 가장 먼저 구현.

- **다른 레지스트리의 base** — Harbor, Zot, GHCR 등이 내부적으로 distribution 또는 그 분기를 사용.

Distribution 실행

가장 단순한 사내 registry

docker run -d -p 5000:5000 --restart=always \

-v /opt/registry-data:/var/lib/registry \

--name registry \

registry:2

사용

docker tag myapp:latest localhost:5000/myapp:v1

docker push localhost:5000/myapp:v1

Distribution의 한계

- **인증/권한 모델 부재** — basic auth 또는 reverse proxy로 직접 구현.

- **UI 없음** — 별도 frontend 필요.

- **scanner 부재** — 별도 도구 통합 필요.

Distribution의 자리

- **개발용 단일 노드 registry.**

- **다른 레지스트리의 building block.**

- **OCI spec 학습 또는 reference 구현 확인용.**

대부분의 production 사례에서는 Harbor·Zot·GHCR로 이동했다.

13장 · Sonatype Nexus

Nexus Repository는 Sonatype의 universal 아티팩트 레지스트리다. Artifactory와 같은 위치 — 모든 패키지 매니저 + Docker.

Nexus의 강점

- **Nexus Repository OSS** — 무료, Docker proxy/host/group 지원.

- **Maven 생태계의 사실상 표준** — 자바 백엔드 회사는 이미 Nexus가 있다.

- **상대적으로 가벼움** — Artifactory보다 운영 단순.

- **Nexus IQ Server** — vulnerability·license·policy 검사.

Nexus 사용

Nexus에 hosted docker repo 생성 후

docker login nexus.example.com:8082

docker push nexus.example.com:8082/myapp:v1

Nexus의 자리

- **이미 Nexus를 쓰는 Maven/Gradle 팀** — Docker도 자연스럽게 추가.

- **Artifactory의 무료 대안.**

- **다만 컨테이너 전용 기능(scanner, replication)은 Harbor에 비해 약하다.**

14장 · Cosign + Sigstore — 이미지 서명 표준

Sigstore는 OSS 공급망 보안을 위한 비영리 프로젝트다. Cosign은 그 컨테이너 이미지 서명 도구다.

Sigstore의 구성요소

- **Cosign** — 서명/검증 CLI.

- **Fulcio** — short-lived 인증서 CA (OIDC identity → X.509 cert).

- **Rekor** — append-only transparency log.

- **TUF** — root of trust 배포.

Keyless 서명 — 2026년의 기본값

1. 키 없이 서명 (OIDC identity 사용)

cosign sign ghcr.io/myorg/myapp:v1

브라우저 열림 → GitHub/Google/Microsoft OIDC 로그인

Fulcio가 short-lived cert 발급

Rekor에 서명 기록

Cosign이 cert + signature를 레지스트리에 push

2. 검증

cosign verify ghcr.io/myorg/myapp:v1 \

--certificate-identity=user@example.com \

--certificate-oidc-issuer=https://accounts.google.com

키를 들고 다닐 필요가 없다. **OIDC identity가 곧 서명자다.**

GitHub Actions 자동 서명

permissions:

id-token: write # OIDC token 발급용

contents: read

packages: write

jobs:

build-and-sign:

runs-on: ubuntu-latest

steps:

- uses: docker/build-push-action@v5

id: build

with:

push: true

tags: ghcr.io/myorg/myapp:latest

- uses: sigstore/cosign-installer@v3

- run: cosign sign --yes ghcr.io/myorg/myapp@$DIGEST

env:

DIGEST: ${{ steps.build.outputs.digest }}

GitHub Actions의 OIDC identity가 서명에 박힌다. 검증 시 `--certificate-identity-regexp=https://github.com/myorg/.*`로 "이 organization의 GitHub Actions가 빌드한 것"임을 보장.

Admission Control 통합

Kyverno policy 예시

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

name: require-cosign-signature

spec:

validationFailureAction: enforce

rules:

- name: verify-image

match:

any:

- resources:

kinds: [Pod]

verifyImages:

- imageReferences:

- "ghcr.io/myorg/*"

attestors:

- entries:

- keyless:

subject: "https://github.com/myorg/.*"

issuer: "https://token.actions.githubusercontent.com"

이 policy 하나로 클러스터에는 "myorg의 GitHub Actions로 빌드된 이미지"만 배포된다.

Cosign + Sigstore의 자리

**2026년 컨테이너 서명의 사실상 표준.** Docker Content Trust(Notary v1)는 사실상 deprecated, Notary v2는 OCI spec 표준화 진행 중. 실전에서는 Cosign이 가장 널리 쓰인다.

15장 · in-toto / SBOM (CycloneDX, SPDX) / Notary v2 — 공급망 보안

서명만으로는 부족하다. "누가 이 이미지를 빌드했나?" 위에 "이 이미지 안에 무엇이 들어 있나?", "이 이미지가 어떤 과정을 거쳐 빌드되었나?"가 필요하다.

in-toto — 공급망 attestation

in-toto는 빌드 파이프라인 각 단계의 attestation을 만드는 framework다.

{

"_type": "https://in-toto.io/Statement/v1",

"subject": [{

"name": "ghcr.io/myorg/myapp",

"digest": { "sha256": "abc123..." }

}],

"predicateType": "https://slsa.dev/provenance/v1",

"predicate": {

"buildDefinition": {

"buildType": "https://github.com/Attestations/GitHubActions/v1",

"externalParameters": {

"workflow": ".github/workflows/build.yml",

"ref": "refs/heads/main"

}

},

"runDetails": {

"builder": { "id": "https://github.com/actions/runner@v2.319.0" },

"metadata": {

"invocationId": "https://github.com/myorg/myapp/actions/runs/12345"

}

}

}

}

SLSA(Supply-chain Levels for Software Artifacts) Level 3 빌드의 핵심.

SBOM — Software Bill of Materials

이미지 안의 모든 의존성 목록.

CycloneDX

OWASP가 만든 SBOM 표준.

Syft로 SBOM 생성 (CycloneDX 포맷)

syft ghcr.io/myorg/myapp:v1 -o cyclonedx-json > sbom.cdx.json

이미지에 attach (Cosign)

cosign attach sbom --sbom sbom.cdx.json \

--type cyclonedx ghcr.io/myorg/myapp:v1

SPDX

Linux Foundation의 SBOM 표준.

syft ghcr.io/myorg/myapp:v1 -o spdx-json > sbom.spdx.json

cosign attach sbom --sbom sbom.spdx.json \

--type spdx ghcr.io/myorg/myapp:v1

두 포맷 모두 ISO 표준화. 어느 쪽을 선택해도 도구 호환성은 좋다. CycloneDX가 vulnerability 통합이 강하고, SPDX가 라이선스 추적이 강하다.

Notary v2 — OCI 서명 표준

Notary v1(Docker Content Trust)은 사실상 deprecated. Notary v2는 OCI artifact spec 위에서 서명을 표준화한다.

- **OCI artifact spec 활용** — 서명을 별도 manifest로 저장.

- **ACR, Quay에서 기본 지원** — `notation` CLI로 서명/검증.

- **Cosign과 공존** — Notary v2 spec에 Cosign이 alternate signer로 등록.

Notation CLI (Notary v2 reference impl)

notation sign --plugin azure-kv \

--id "https://myvault.vault.azure.net/keys/mykey/abc123" \

myregistry.azurecr.io/myapp:v1

notation verify \

--signature myregistry.azurecr.io/myapp:v1

in-toto / SBOM / Notary v2의 자리

- **in-toto** — SLSA Level 3 빌드 증언. SLSA L3을 달성하려면 사실상 필수.

- **SBOM** — 규제(EO 14028, EU CRA) 대응 필수.

- **Notary v2** — ACR·Quay 중심으로 채택. Cosign이 사실상 더 널리 쓰이지만 ecosystem 분포는 비슷.

기억할 한 줄: **"2026년 공급망 보안은 서명(Cosign) + 증언(in-toto) + 자재명세서(SBOM) 셋이 한 패키지다."**

16장 · ORAS — generic OCI artifact

ORAS(OCI Registry As Storage)는 컨테이너 이미지 외의 모든 것 — Helm chart, WASM module, ML model, Terraform module, OPA bundle — 을 OCI artifact로 저장하는 도구다.

ORAS의 동기

OCI distribution spec은 이미지뿐 아니라 임의 artifact를 저장할 수 있다. 그러나 클라이언트 도구가 부족했다. ORAS가 그 빈자리를 채운다.

임의 파일을 OCI artifact로 push

oras push ghcr.io/myorg/wasm-modules:v1 \

./module.wasm:application/wasm

pull

oras pull ghcr.io/myorg/wasm-modules:v1

manifest 확인

oras manifest fetch ghcr.io/myorg/wasm-modules:v1

ORAS의 활용 사례

- **Helm chart** — `helm push my-chart-1.0.0.tgz oci://registry.example.com/charts`

- **WASM module** — wasmCloud, Krustlet이 OCI registry에서 module pull.

- **ML model** — KServe, ModelMesh가 model을 OCI artifact로 분배.

- **OPA bundle, Cosign signature, SBOM** — 이미 OCI artifact다.

ORAS의 자리

**컨테이너 레지스트리가 universal artifact registry로 진화하는 추진력.** Helm·WASM·ML model 등이 모두 OCI registry 위로 옮겨가는 흐름의 중심.

17장 · 한국 / 일본 — 토스, 카카오 페이, 메르카리, LINE

한국

- **토스** — 내부 자체 레지스트리를 운영(자체 빌드한 사내 도구 + Harbor 기반)하며, OSS 이미지의 pull-through proxy로도 활용한다. 사내 개발 컨퍼런스 발표에서 사내 빌드 파이프라인이 자체 registry로 push되는 구조가 공유되었다.

- **카카오 페이** — Azure를 메인 클라우드 중 하나로 사용하여 ACR을 핵심 컨테이너 레지스트리로 운영한다(공개된 사내 기술 블로그 기반).

- **네이버 / 라인 한국** — 멀티 클라우드(NCP 포함)와 사내 registry 조합.

- **국내 OSS 프로젝트** — GHCR 우선, Docker Hub mirror 패턴이 증가.

일본

- **메르카리** — 멀티 클라우드 + GitHub Actions + GHCR을 중심으로 한 빌드 파이프라인. 일부 워크로드는 GCP Artifact Registry로 직접.

- **LINE** — 사내 자체 컨테이너 플랫폼 위의 자체 레지스트리를 운영. Harbor 기반 구조가 사내 컨퍼런스 발표에서 언급된 바 있다.

- **CyberAgent / DeNA** — GKE·EKS 혼용, GAR·ECR 혼용.

- **일본 OSS 프로젝트** — GHCR + Docker Hub 이중 게재 흔함.

한국·일본 공통 패턴

- 사내 코어 인프라는 **셀프호스팅(Harbor) 또는 매니지드(ACR/ECR/GAR)** 하나 + **외부 mirror로 GHCR**.

- OSS 빌드는 **GitHub Actions + GHCR + Cosign keyless** 가 사실상 표준.

- Docker Hub은 "공개 노출용 보조 destination".

18장 · 누가 무엇을 골라야 하나 — 오픈소스 / 스타트업 / 엔터프라이즈 / 에어갭

오픈소스 프로젝트 — GHCR

- 빌드 무료(Actions), 저장 무료(public).

- Cosign keyless 서명이 OIDC로 자동.

- README에 `ghcr.io/org/project` 한 줄로 안내.

- 부가적으로 Docker Hub에도 mirror push (사용자 노출용).

스타트업 — 메인 클라우드의 매니지드 + GHCR

- AWS면 ECR, GCP면 GAR, Azure면 ACR.

- CI는 GitHub Actions → GHCR → 메인 클라우드 registry로 mirror.

- 운영 부담 최소.

중견 기업 — Harbor + 메인 클라우드

- 사내 Harbor 하나, 메인 클라우드 매니지드 하나.

- Pull-through proxy로 Docker Hub rate limit 우회.

- Cosign + Trivy로 admission control.

대형 엔터프라이즈 — Artifactory 또는 Harbor + 멀티 클라우드

- 컨테이너 외의 아티팩트(Maven, npm)가 많으면 Artifactory.

- 컨테이너 중심이면 Harbor + 클라우드 매니지드.

- Cosign + Notary v2 + SBOM + in-toto attestation 풀 스택.

에어갭 / 정부·금융 보안망 — Zot 또는 Harbor offline

- Zot의 read-only mode + 단일 binary가 air-gapped에 강하다.

- Harbor의 offline installer + replication for sync.

- SBOM, Cosign signature까지 air-gapped로 sync.

의사결정 매트릭스

| 조건 | 추천 |

| --- | --- |

| OSS 프로젝트 | GHCR (+ Docker Hub mirror) |

| AWS 단일 클라우드 | ECR (+ ECR Public for OSS) |

| GCP 단일 클라우드 | Google Artifact Registry |

| Azure 단일 클라우드 | ACR |

| GitLab 사용 중 | GitLab Container Registry |

| OpenShift 사용 중 | Red Hat Quay |

| 셀프호스팅, 풀 GUI 필요 | Harbor |

| 셀프호스팅, 단순함 우선 | Zot |

| 모든 언어 + 컨테이너 통합 | Artifactory 또는 Nexus |

| Air-gapped | Zot read-only 또는 Harbor offline |

| 서명 / 검증 | Cosign + Sigstore |

| 공급망 attestation | in-toto + SLSA |

| 자재명세서 | CycloneDX 또는 SPDX |

| Helm/WASM/ML model 저장 | ORAS + OCI registry |

에필로그 — 레지스트리는 이미 공급망 보안의 중심이다

2026년 컨테이너 레지스트리는 더 이상 "이미지를 저장하는 곳"이 아니다.

- 이미지에 **서명**이 붙고(Cosign),

- 이미지에 **자재명세서**가 붙고(SBOM),

- 이미지에 **빌드 증언**이 붙고(in-toto),

- 이미지가 **여러 레지스트리로 mirror**되고(Harbor replication),

- 이미지가 **admission 단계에서 검증**되며(Kyverno, Binary Authorization),

- 컨테이너 외의 모든 것(Helm, WASM, ML model)도 같은 registry 위에 산다(ORAS).

레지스트리 하나를 고르는 게 아니라, **공급망 보안 토폴로지의 중심 노드를 설계**하는 일이다.

그리고 도구 선택은 단순한 기능표가 아니라, **클라우드 선택 + CI 선택 + 운영 역량 + 규제 요구사항**의 함수다. 이 글이 그 함수의 입력값을 잡는 데 도움이 되길 바란다.

마지막 한 줄: **레지스트리는 끝점이 아니라 시작점이다.** 이미지가 그 안에 들어가는 순간, 공급망의 모든 사슬이 거기서부터 검증된다.

참고 / References

- Docker Hub Documentation — https://docs.docker.com/docker-hub/

- Docker Hub Subscription Pricing — https://www.docker.com/pricing/

- GitHub Container Registry Docs — https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry

- GHCR for Actions — https://docs.github.com/en/actions/publishing-packages/publishing-docker-images

- GitLab Container Registry — https://docs.gitlab.com/ee/user/packages/container_registry/

- GitLab Dependency Proxy — https://docs.gitlab.com/ee/user/packages/dependency_proxy/

- AWS ECR User Guide — https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html

- ECR Public Gallery — https://gallery.ecr.aws/

- ECR Lifecycle Policies — https://docs.aws.amazon.com/AmazonECR/latest/userguide/LifecyclePolicies.html

- Google Artifact Registry — https://cloud.google.com/artifact-registry/docs

- GAR Migration from GCR — https://cloud.google.com/artifact-registry/docs/transition/transition-from-gcr

- Binary Authorization — https://cloud.google.com/binary-authorization

- Azure Container Registry — https://learn.microsoft.com/en-us/azure/container-registry/

- ACR Tasks — https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-overview

- Harbor Project — https://goharbor.io/

- Harbor Docs — https://goharbor.io/docs/

- CNCF Harbor Graduation Announcement — https://www.cncf.io/announcements/2020/06/23/cloud-native-computing-foundation-announces-harbor-graduation/

- Project Quay — https://www.projectquay.io/

- Red Hat Quay — https://www.redhat.com/en/technologies/cloud-computing/quay

- Zot Registry — https://zotregistry.dev/

- CNCF Zot Incubation — https://www.cncf.io/projects/zot/

- JFrog Artifactory — https://jfrog.com/artifactory/

- Sonatype Nexus Repository — https://www.sonatype.com/products/sonatype-nexus-repository

- CNCF Distribution — https://distribution.github.io/distribution/

- OCI Distribution Spec — https://github.com/opencontainers/distribution-spec

- OCI Image Spec — https://github.com/opencontainers/image-spec

- Sigstore — https://www.sigstore.dev/

- Cosign Docs — https://docs.sigstore.dev/cosign/

- Rekor Transparency Log — https://docs.sigstore.dev/rekor/overview

- Fulcio CA — https://docs.sigstore.dev/fulcio/overview

- in-toto — https://in-toto.io/

- in-toto attestations — https://github.com/in-toto/attestation

- SLSA Framework — https://slsa.dev/

- CycloneDX — https://cyclonedx.org/

- SPDX — https://spdx.dev/

- Syft (SBOM tool) — https://github.com/anchore/syft

- Notary Project (v2) — https://notaryproject.dev/

- ORAS Project — https://oras.land/

- Kyverno verifyImages — https://kyverno.io/docs/policy-types/verify-images/

- Trivy Scanner — https://trivy.dev/