컨테이너 레지스트리 2026 — Docker Hub / GHCR / ECR / Harbor / Quay / Zot / Cosign + Sigstore 심층 비교

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

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)

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

매니지드 SaaS — 클라우드 사업자가 운영, 청구서로 비용. 가용성 책임은 사업자가 진다. 트레이드오프는 가격과 멀티클라우드 이식성.
셀프호스팅 OSS — 직접 운영, 인프라 비용만. 가용성과 보안의 책임은 본인. 트레이드오프는 운영 부담.
무료 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 프로젝트의 표준 경로:

GitHub Actions로 멀티 아키텍처 빌드.
ghcr.io/owner/project:tag로 push.
README에 pull 명령을 GHCR 우선으로 갱신.
Docker Hub에도 mirror push (이중 게재).
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/

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

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

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

2026년 Docker Hub의 위상

가격 정책 변화의 임팩트

그래도 Docker Hub인 이유

docker push 기본 흐름

Pull-through cache의 부상

Docker Hub의 자리

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

GHCR의 강점

Actions에서 push하는 표준 패턴

ghcr.io/owner/image 명명 규칙

Private 이미지 가격

GHCR의 한계

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

4장 · GitLab Container Registry

GitLab Registry의 강점

.gitlab-ci.yml 표준 push 패턴

Dependency Proxy

Cleanup Policy

GitLab Registry의 자리

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

ECR의 강점

aws ecr get-login-password 흐름

Lifecycle Policy 예시

ECR Public — 무료 OSS 호스팅

ECR의 한계

ECR의 자리

6장 · Google Artifact Registry — GCR 후속

AR이 GCR을 대체한 이유

GCR 마이그레이션

GKE Workload Identity Federation

AR의 강점

AR의 자리

7장 · Azure Container Registry (ACR)

ACR의 강점

az acr login 흐름

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

Retention policy

한국 / 일본 사용

ACR의 자리

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

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

Harbor 설치 (Helm)

Project · Robot · Replication 전형 구조

Pull-through Proxy Cache

Harbor의 한계

Harbor의 자리

9장 · Quay (Red Hat / IBM)

Quay의 강점

Quay 사용 패턴

Robot Account 모델

Quay의 자리

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

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

Zot 실행

Zot의 자리

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

Artifactory의 강점

Artifactory의 자리

Artifactory CE — Community Edition

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

Distribution의 자리

Distribution 실행

Distribution의 한계

Distribution의 자리

13장 · Sonatype Nexus

Nexus의 강점

Nexus 사용

Nexus의 자리

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

Sigstore의 구성요소

Keyless 서명 — 2026년의 기본값

GitHub Actions 자동 서명

Admission Control 통합

Cosign + Sigstore의 자리

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

in-toto — 공급망 attestation

SBOM — Software Bill of Materials

`docker push` 기본 흐름

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

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

`aws ecr get-login-password` 흐름

`az acr login` 흐름