앱 개발에서 Artifact: 정의, 유형 및 관리 방법

개발에서 Artifact란 무엇인가

아티팩트(빌드 아티팩트)는 소스 코드 컴파일 결과물로, 배포 또는 종속성으로 사용할 준비가 된 상태입니다. 빌드 프로세스는 소스 파일(Java, Kotlin, Swift, C++ 등)을 대상 장치나 서버에서 실행할 수 있는 바이너리 패키지로 변환합니다.

아티팩트의 개념은 실행 파일을 넘어 확장됩니다. 예를 들어, JAR 라이브러리는 다른 프로젝트에서 종속성으로 사용되는 아티팩트입니다. Docker 이미지는 애플리케이션과 해당 환경을 포함하는 아티팩트입니다. 테스트 커버리지 보고서도 CI/CD 맥락에서 아티팩트로 간주될 수 있습니다.

대기업의 현대적인 개발에는 수십만 개의 아티팩트 관리가 포함됩니다. Google DORA는 아티팩트 관리의 성숙도를 DevOps 전반의 효율성과 연결합니다 — 아티팩트 레지스트리를 사용하는 팀은 릴리스를 더 빠르게 출시하고 배포 문제를 덜 겪습니다.

아티팩트 수명 주기

각 아티팩트는 여러 단계를 거칩니다: 생성(빌드, 컴파일), 검증(테스트, 보안 검사), 저장(아티팩트 레지스트리), 배포(다운로드용 게시), 보관 또는 삭제(버전이 오래된 경우).

모바일 개발의 아티팩트 유형

플랫폼과 기술에 따라 다양한 아티팩트 형식이 생성됩니다. 형식을 이해하는 것은 CI/CD 파이프라인을 올바르게 구성하고 스토리지 시스템을 선택하는 데 필수적입니다.

Android 아티팩트

APK(Android Package Kit)는 전통적인 설치 패키지 형식입니다. AAB(Android App Bundle)는 Google Play에 게시하기 위한 최신 형식으로, 특정 장치에 필요한 리소스만 포함합니다. AAB는 범용 APK에 비해 설치된 애플리케이션 크기를 평균 15-20% 줄입니다.

iOS 아티팩트

IPA(iOS App Store Package)는 iOS 장치용 코드와 리소스가 포함된 아카이브입니다. XCArchive는 Xcode에서 생성하는 중간 아티팩트로, 최종 IPA가 내보내집니다. dSYM은 크래시 로그 기호화에 필요한 디버그 심볼 파일입니다.

서버 및 라이브러리 프로젝트 아티팩트

JAR(Java ARchive) — Java/Kotlin 라이브러리용. AAR(Android ARchive) — 리소스가 포함된 Android 라이브러리용. Docker 이미지 — 마이크로서비스용 컨테이너 아티팩트. 각 유형에는 자체 레지스트리와 버전 관리 규칙이 있습니다.

CI/CD 파이프라인의 아티팩트

아티팩트는 파이프라인 단계 간의 연결 고리입니다. 각 단계는 이전 단계의 아티팩트를 소비하고 새로운 것을 생성합니다. 이 흐름을 이해하는 것은 효과적인 CI/CD 파이프라인을 설정하는 데 중요합니다.

파이프라인의 아티팩트 흐름

일반적인 흐름은 다음과 같습니다: 커밋 -> 빌드 서버가 코드를 컴파일하고 최적화되지 않은 아티팩트 생성 -> 테스트 아티팩트를 사용하여 테스트 실행 -> 성공 시 릴리스 아티팩트 생성 -> 서명 후 아티팩트 레지스트리에 게시 -> 레지스트리에서 스테이징 및 프로덕션 배포를 위해 아티팩트를 가져옴. 각 단계 전환에는 무결성 검사 및 요구 사항 준수 확인이 수반됩니다.

중간 및 최종 아티팩트

파이프라인은 다양한 단계에서 여러 아티팩트를 생성할 수 있습니다. 디버그 아티팩트에는 디버깅 정보가 포함되고, 최적화되지 않은 것은 테스트용으로 빠르게 빌드되며, 릴리스 아티팩트는 최적화 및 난독 처리가 된 최종본입니다. CI 시스템은 이를 구분하고 각 유형에 적절한 보존 정책을 적용할 수 있어야 합니다.

name: Artifact Flow
on: [push]

jobs:
  build-debug:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleDebug
      - uses: actions/upload-artifact@v4
        with:
          name: debug-apk
          path: app/build/outputs/apk/debug/app-debug.apk
          retention-days: 7

  test:
    needs: build-debug
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: debug-apk
      - run: ./gradlew testDebugUnitTest

  build-release:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk
          retention-days: 90

캐시 vs 아티팩트

종속성 캐시와 빌드 아티팩트를 구분하는 것이 중요합니다. 캐시(Gradle 캐시, CocoaPods 캐시)는 반복 빌드를 가속화하지만 배포용이 아닙니다. 아티팩트는 배포 준비가 된 최종 제품입니다. 캐시에는 며칠, 아티팩트에는 몇 주 또는 몇 개월의 TTL을 설정하세요.

아티팩트 리포지토리

아티팩트는 빌드 서버에 저장하면 안 됩니다 — 이를 위한 전문 시스템이 존재합니다. 리포지토리 관리자는 중앙 집중식 저장, 인덱싱, 액세스 제어 및 CI/CD 도구와의 통합을 제공합니다.

인기 있는 아티팩트 레지스트리

JFrog Artifactory — Maven, Gradle, Docker, NuGet, npm, APT, YUM을 지원하는 범용 관리자. Sonatype Nexus — 주요 형식을 지원하는 오픈 소스 대안. GitHub Packages — GitHub에 내장된 레지스트리로, 이미 GitHub를 사용하는 팀에 편리합니다. GitLab Container Registry — Docker 이미지용.

레지스트리 선택 기준

주요 요소: 지원되는 형식, 라이선스 모델(오픈 소스/엔터프라이즈), 기존 CI/CD와의 통합, 리전 간 복제 기능, 이전 버전 자동 정리 정책 가용성 및 규정 준수 보고서.

// Jenkins pipeline — Artifactory에 APK 게시
def server = Artifactory.newServer(
    url: 'https://artifactory.company.com',
    credentialsId: 'artifactory-api-key'
)

def uploadSpec = """
{
  "files": [
    {
      "pattern": "app/build/outputs/apk/release/*.apk",
      "target": "mobile-apps/android/release/""
    }
  ]
}
"""
server.upload(uploadSpec)

버전 관리 및 명명

적절한 아티팩트 버전 관리 전략은 빌드 재현성과 변경 추적에 매우 중요합니다. 버전 관리가 없으면 프로덕션에서 문제를 일으킨 코드 버전을 확인하는 것이 불가능합니다.

시맨틱 버전 관리(SemVer)

MAJOR.MINOR.PATCH 표준: MAJOR는 호환되지 않는 API 변경 시, MINOR는 하위 호환 가능한 기능 추가 시, PATCH는 하위 호환 가능한 버그 수정 시 변경됩니다. CI/CD의 경우 버전에 빌드 메타데이터가 추가됩니다: 2.4.1+build.20260703.1. 이를 통해 특정 아티팩트를 생성한 커밋과 생성 시점을 정확히 확인할 수 있습니다.

추적 가능성 — Git 연결

각 아티팩트는 출처에 대한 메타데이터(커밋 SHA, CI 빌드 번호, 브랜치 이름, 빌드 날짜)를 포함해야 합니다. 이 정보는 아티팩트 매니페스트에 기록되며, 언제든지 생성 컨텍스트를 재구성할 수 있습니다. 추적 가능성이 없으면 아티팩트 작업이 버전 추측이 되어, 감사 요구 사항이 있는 프로덕션 시스템에서는 허용되지 않습니다.

아티팩트 명명

명명 규칙: {project}-{module}-{version}.{ext}. 예: messaging-sdk-2.4.1.aar 또는 app-release-2.4.1.apk. 빌드 서버는 Git 태그 또는 CI 시스템 빌드 번호를 기반으로 자동으로 버전을 생성할 수 있습니다.

• Git 태그를 버전 소스로 사용 — 아티팩트를 특정 코드 상태에 연결합니다
• 커밋 SHA를 메타데이터에 추가 — 디버깅 중 정확한 식별 가능
• 보존 정책 구성 — 최신 N개 버전 유지, 나머지는 보관

스냅샷 vs 릴리스

Maven/Gradle 아티팩트 레지스트리에서는 릴리스 버전(고정, 불변)과 스냅샷 버전(현재 개발 중, 덮어쓰기 가능)을 구분합니다. CI/CD 파이프라인에서 스냅샷 아티팩트는 개발에 편리하지만, 프로덕션에서는 릴리스 버전만 사용해야 합니다.

아티팩트 보안

아티팩트는 소프트웨어 공급망의 핵심 요소입니다. 아티팩트 손상은 악성 코드가 프로덕션에 유입되는 원인이 될 수 있습니다. 아티팩트 보안에는 여러 보호 수준이 포함됩니다.

아티팩트 서명

APK 파일은 jarsigner 또는 apksigner로 서명되고, IPA 파일은 Apple 인증서로 서명되며, Docker 이미지는 Docker의 Content Trust(Notary)로 서명됩니다. 서명은 무결성을 보장하고 아티팩트 작성자를 확인합니다. CI/CD 파이프라인에는 모든 타사 종속성의 서명 확인이 포함되어야 합니다.

취약점 스캔

게시 전에 아티팩트는 자동 스캐너(Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot)로 확인됩니다. 이들은 포함된 종속성, 사용된 라이브러리 버전 및 알려진 CVE 취약점을 분석합니다. 심각한 취약점이 발견되면 개발자가 수정할 때까지 릴리스가 즉시 차단됩니다.

공급망 수준

SLSA(Supply chain Levels for Software Artifacts)는 SLSA 1(기본)부터 SLSA 4(최대)까지 신뢰 수준을 정의하는 보안 프레임워크입니다. 빌드 서버는 아티팩트가 어떻게, 어떤 코드로 빌드되었는지에 대한 암호학적으로 서명된 증명(provenance attestation)을 생성해야 합니다.