LabHub

블로그

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

2026-05-16 · 39 분 읽기 · #container#registry#docker-hub#ghcr#ecr#gcr#acr#harbor#quay#zot#artifactory#distribution#cosign#sigstore#in-toto#sbom#cyclonedx#spdx#notary#oras#deep-dive

한국어English日本語

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

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

2026년의 풍경은 다르다.

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

이 글은 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년의 새로운 흐름은 "이 셋이 더 이상 분리되지 않는다" 는 것이다.

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

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

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

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

2026년 Docker Hub의 위상

가격 정책 변화의 임팩트

그래도 Docker Hub인 이유

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의 강점

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의 이미지 경로는 정해진 형식이다:

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

Private 이미지 가격

GHCR의 한계

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의 강점

.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의 강점

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 이미지를 무료로 글로벌 호스팅한다.

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

ECR의 한계

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을 대체한 이유

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의 강점

AR의 자리

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

7장 · Azure Container Registry (ACR)

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

ACR의 강점

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

한국 / 일본 사용

ACR의 자리

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

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

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

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

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의 한계

Harbor의 자리

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

9장 · Quay (Red Hat / IBM)

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

Quay의 강점

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의 자리

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

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

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

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의 자리

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

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

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

Artifactory의 강점

Artifactory의 자리

Artifactory CE — Community Edition

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

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

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

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의 한계

Distribution의 자리

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

13장 · Sonatype Nexus

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

Nexus의 강점

Nexus 사용

# Nexus에 hosted docker repo 생성 후
docker login nexus.example.com:8082
docker push nexus.example.com:8082/myapp:v1

Nexus의 자리

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

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

Sigstore의 구성요소

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 위에서 서명을 표준화한다.

# 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의 자리

기억할 한 줄: "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의 활용 사례

ORAS의 자리

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

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

한국

일본

한국·일본 공통 패턴

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

오픈소스 프로젝트 — GHCR

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

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

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

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

의사결정 매트릭스

조건추천
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-gappedZot read-only 또는 Harbor offline
서명 / 검증Cosign + Sigstore
공급망 attestationin-toto + SLSA
자재명세서CycloneDX 또는 SPDX
Helm/WASM/ML model 저장ORAS + OCI registry

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

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

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

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

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

참고 / References

원문 보기: https://www.youngju.dev/blog/culture/2026-05-16-container-registries-2026-docker-hub-ghcr-ecr-harbor-quay-zot-cosign-sigstore-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다