76. 아티팩트 리포지토리 - Nexus, JFrog, AWS ECR 이미지 저장소

핵심 인사이트 (3줄 요약)

1. 본질: 아티팩트 리포지토리(Artifact Repository)는 CI가 만든 .jar, .war, Docker image 같은 실행 결과물을 버전과 해시로 고정해 두는 중앙 보관소다.
2. 가치: 같은 소스라도 빌드 시점과 환경이 달라지면 결과가 달라질 수 있으므로, 불변(immutable) 저장과 프로모션(promote) 구조가 있어야 재현 가능한 배포와 즉시 롤백이 가능하다.
3. 판단 포인트: Nexus, JFrog Artifactory, Amazon Elastic Container Registry(Amazon ECR)는 모두 쓰이지만, 팀은 아티팩트 종류, 온프레미스/클라우드 경계, 보안·보존 정책에 따라 골라야 한다.

Ⅰ. 개요 및 필요성

아티팩트 리포지토리는 소스 저장소와 배포 저장소를 분리한다. Git이 사람의 변경 이력을 보관한다면, 아티팩트 리포지토리는 빌드된 바이너리의 이력과 배포 승인 상태를 보관한다. 이 둘을 섞어 버리면 "어떤 커밋이 어떤 바이너리를 만들었는가"를 다시 증명하기 어렵다.

빌드 산출물을 CI 서버 디스크나 개발자 노트북에 둔 채 배포하면 재현성, 롤백, 감사가 동시에 무너진다. 운영 장애가 발생했을 때 동일한 소스와 동일한 의존성으로 다시 빌드한 결과가 과거 배포본과 다를 수 있기 때문이다. 그래서 중앙 저장소에 올릴 때는 해시, 서명, 메타데이터를 함께 남겨야 한다.

┌────────────────────── 배포 가능한 바이너리의 생명주기 ──────────────────────┐
│ Git 소스 ─▶ CI 빌드 ─▶ 테스트/서명 ─▶ 아티팩트 저장소 ─▶ 프로모션 ─▶ CD 배포 │
│                ▲                         │                   │             │
│                └── 같은 소스, 같은 결과를 재사용 ──────────────┘             │
└──────────────────────────────────────────────────────────────────────────────┘

이 그림의 핵심은 "배포는 빌드 결과를 가져오는 행위"라는 점이다. 배포 서버가 다시 빌드를 시작하면 환경 차이와 의존성 오염 때문에 동일성을 잃는다.

• 📢 섹션 요약 비유: 반찬을 매번 새로 요리해 배달하면 맛이 들쑥날쑥하다. 냉동창고에 같은 번호의 반찬을 넣어 두면, 언제 꺼내도 같은 맛과 같은 양을 다시 낼 수 있다.

Ⅱ. 아키텍처 및 핵심 원리

아티팩트 리포지토리는 보통 저장소 엔진, 메타데이터 인덱스, 인증·권한, 프록시 캐시로 나뉜다. 저장소 엔진은 파일을 저장하고, 메타데이터는 버전·체크섬·작성자·승인 상태를 추적하며, 캐시는 외부 패키지 서버를 대신해 의존성을 빠르게 공급한다.

┌────────────── 저장소 내부 구조 ──────────────┐
│ 업로드된 아티팩트                              │
│   ├─ Blob(실제 바이너리)                      │
│   ├─ Checksum(SHA-256)                        │
│   ├─ Signature(서명)                         │
│   └─ Metadata(버전/태그/권한/승격 이력)       │
└───────────────────────────────────────────────┘

실무에서는 태그(tag)보다 불변 식별자(digest)를 더 신뢰해야 한다. latest 같은 가변 태그는 사람이 읽기 쉽지만, 감사와 재현성 측면에서는 위험하다. 배포 승인 과정이 길어질수록 "같은 태그가 다른 파일을 가리키는" 사고가 커진다.

• 📢 섹션 요약 비유: 창고에 상자만 쌓아 두면 찾기 어렵다. 상자마다 바코드, 입고일, 출고 허가 스탬프를 붙여야 나중에 같은 물건을 정확히 다시 꺼낼 수 있다.

Ⅲ. 비교 및 연결

소스 저장소(Git)와 아티팩트 리포지토리는 역할이 다르다. Git은 텍스트 기반 변경 이력을 관리하고, 아티팩트 리포지토리는 실행 가능한 결과물을 관리한다. 둘을 섞어서 "Git만 있으면 다 된다"고 생각하면, 배포 재현성과 롤백 속도가 급격히 떨어진다.

Nexus와 JFrog Artifactory는 범용 패키지 저장에 강하고, Amazon ECR은 컨테이너 이미지 배포와 AWS 생태계 연동에 강하다. 즉 "무엇을 담느냐"와 "어디서 운영하느냐"가 선택 기준이지, 이름값이 기준이 아니다.

• 📢 섹션 요약 비유: Git은 레시피 책, 아티팩트 리포지토리는 완성된 도시락 보관함, 레지스트리는 냉장 탑차다. 레시피만 지켜서는 배달이 안 되고, 도시락만 있어서는 새 메뉴를 만들 수 없다.

Ⅳ. 실무 적용 및 기술사 판단

도입 판단의 핵심은 "재빌드보다 재사용이 더 안전한가"다. 배포 전에 항상 동일한 산출물을 다시 꺼낼 수 있어야 한다면 아티팩트 리포지토리는 필수다. 반대로 파일 하나만 임시로 옮기는 수준이라면 과도한 플랫폼이 될 수 있다.

체크리스트

1. 릴리스 아티팩트가 불변 버전으로 저장되는가?
2. 체크섬과 서명이 검증되는가?
3. dev / stage / prod 승격이 재빌드가 아닌 프로모션인가?
4. 저장소 접근 권한과 감사 로그가 남는가?
5. 보존 정책과 폐기 정책이 분리되어 있는가?

안티패턴

• Jenkins 작업공간에서 바로 운영 서버로 복사

• 같은 버전을 덮어쓰기

• latest 태그만 믿고 배포

• 의존성 캐시와 릴리스 저장소를 혼용

• 📢 섹션 요약 비유: 중요한 서류를 책상 위에 흩어 놓는 대신, 잠금장치가 있는 서류함에 넣어 두고 승인 도장까지 받는 방식이 안전하다.

Ⅴ. 기대효과 및 결론

아티팩트 리포지토리는 배포 속도를 높이기보다, 배포를 예측 가능하게 만든다. 그 결과 롤백, 재현, 감사, 보안 스캔이 한 흐름으로 연결된다. 특히 공급망 공격이 늘어난 지금은 "어떤 바이너리를 언제 누가 배포했는가"가 품질만큼 중요하다.

한계도 있다. 저장 용량과 메타데이터 관리 비용이 들고, 팀이 승격 절차를 지키지 않으면 오히려 복잡도만 늘어난다. 그래서 이 개념은 "창고를 크게 만드는 기술"이 아니라 "같은 산출물을 끝까지 추적하는 운영 규율"로 기억해야 한다.

• 📢 섹션 요약 비유: 냉장창고가 커질수록 물건이 오래가지만, 입출고 표가 없으면 거대한 창고도 금세 혼란스러워진다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

소스 코드 관리
    │
    ▼
CI 빌드/테스트
    │
    ▼
패키지 저장소(Nexus/JFrog)
    │
    ▼
컨테이너 레지스트리(ECR)
    │
    ▼
승격/서명/보안 스캔
    │
    ▼
재현 가능한 배포와 롤백

이 흐름은 "만드는 곳"과 "보관하는 곳"을 분리하는 방향으로 진화했다. 앞으로는 저장소 자체보다 서명, 정책, 공급망 추적이 더 중요한 평가 기준이 된다.

👶 어린이를 위한 3줄 비유 설명

1. 레고를 만들고 바로 바닥에 두면 잃어버리기 쉬워요.
2. 번호가 붙은 상자에 넣어 두면 다음에도 같은 레고를 다시 꺼낼 수 있어요.
3. 아티팩트 리포지토리는 컴퓨터의 레고 상자예요.