75. 아티팩트 (Artifact) 관리 체계

⚠️ 이 문서는 개발자가 작성한 순수한 인간의 언어인 소스코드(Source Code) 텍스트 파일들이 CI/CD(지속적 통합) 공장의 펄펄 끓는 컴파일러와 빌드 툴을 거쳐 기계가 읽고 즉시 실행할 수 있는 상태로 구워져 나온 **완제품 형태의 전리품, 즉 '.jar', '.war', 'Docker Image'와 같은 최종 실행 바이너리 결과물인 '아티팩트(Artifact)'**와 이를 중앙에서 영구 보관하는 아티팩트 저장소 기술을 다룹니다.

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

  1. 본질: 소스코드가 밀가루와 설탕(재료)이라면, 아티팩트는 오븐에서 구워져 나와 당장 손님 입에 들어갈 수 있는 예쁘게 포장된 '완성된 케이크'다. 빌드 파이프라인의 종착역이자 배포(CD) 파이프라인의 출발점이다.
  2. 가치: 운영 서버 100대에 앱을 배포할 때, 각 서버에 소스코드를 던져주고 100번씩 따로 컴파일(빌드)하게 만들면 시간 낭비와 버전 충돌의 지옥이 열린다. 젠킨스 중앙 공장에서 딱 1번 완벽하게 구워낸 황금 아티팩트 1개를 복사해서 100대에 꽂아 넣는(Immutable Infrastructure) 불변 배포의 핵심 자산이다.
  3. 기술 체계: 구워진 아티팩트는 젠킨스 서버 안에 방치하지 않고, 버전 번호(v1.0.1)를 예쁘게 붙여 Nexus(넥서스)나 JFrog Artifactory, 또는 컨테이너 시대의 **Docker Registry(ECR 등)**라는 거대한 중앙 냉동 창고에 무조건 영구 보관(Archiving)해야 한다.

Ⅰ. 소스코드와 아티팩트의 절대적 분리

밀가루(코드)를 씹어 먹을 수는 없다. 반드시 한 번 구워야 한다.

  1. 소스코드(Git)는 완제품이 아니다:
    • 주니어 개발자들은 "서버에 내 깃허브 코드(git clone)를 바로 다운받아서 npm start 치면 서버가 뜨는데, 아티팩트가 왜 필요하죠?"라고 묻는다.
    • 이는 서버가 스스로 인터넷(npm)을 뒤져 라이브러리(의존성)를 10분 동안 다운받고 압축을 푸는 뻘짓(빌드)을 실시간으로 운영 서버 위에서 위험하게 수행하는 아마추어 방식이다. 만약 npm 저장소가 그 순간 터지면 배포는 실패한다.
  2. 아티팩트 (Artifact)의 불변성 (Immutability):
    • 진정한 데브옵스는 CI 서버(젠킨스) 안전한 방에서 라이브러리 다운로드, 코드 난독화, 압축을 몽땅 끝내고 1개의 묵직한 .jar 파일이나 Docker Image 덩어리(아티팩트)로 꽝! 도장을 찍어 만들어낸다.
    • 이 덩어리는 외부 인터넷이 끊겨도 100% 무조건 실행을 보장하는 완전체다.
  3. 분리의 미학:
    • 깃허브(Git)는 텍스트 파일(소스코드)의 버전을 관리하는 문서고다.
    • 넥서스(Nexus)나 아티팩토리는 메가바이트(MB) 단위의 묵직한 바이너리 덩어리(아티팩트)들을 v1.0, v2.0 버전별로 층층이 얼려 보관하는 거대한 냉동 창고다. 이 둘은 철저히 분리된다.

📢 섹션 요약 비유: 소스코드는 요리사의 '레시피 적힌 종이'이고, 깃허브는 그 레시피 종이철입니다. 아티팩트는 그 레시피대로 중앙 공장에서 방금 막 쪄낸 따끈따끈하고 포장까지 끝난 '완제품 호빵'입니다. 전국 100개의 편의점(운영 서버)에 레시피 종이와 생 밀가루를 배달해 편의점 알바생에게 각자 찌라고(실시간 빌드) 시키는 건 미친 짓입니다. 공장에서 완제품 호빵(아티팩트)을 한 번에 대량 생산해 냉동 트럭으로 뿌리는 것이 가장 빠르고 안전한 배포의 진리입니다.

Ⅱ. 파이프라인의 바통 터치: CI와 CD를 잇는 매개체

젠킨스 공정의 전반전과 후반전을 이어주는 빛나는 릴레이 바통이다.

  1. CI 단계의 결과물 (Produce):
    • 개발자가 코드를 올리면 파이프라인 1단계가 돈다. 컴파일이 성공하고, 자동화 테스트(JUnit) 100개가 모두 통과(Pass)했다.
    • "이 코드는 결점 없는 완벽한 코드다!"라는 증명서와 함께 코드를 압축해 app-v1.2.3.jar 라는 아티팩트를 낳는다(생산).
  2. CD 단계의 소비 (Consume):
    • 파이프라인 2단계(배포)가 시작된다. CD 봇(ArgoCD나 AWS CodeDeploy)은 절대 소스코드를 쳐다보지 않는다.
    • 오직 앞 단계가 만들어 중앙 창고에 던져둔 저 app-v1.2.3.jar 아티팩트 바통만 휙 낚아채서 운영 서버 10대에 복사해 붙여넣고 재부팅시킨다(소비).
  3. 롤백 (Rollback)의 기적:
    • v1.2.3 아티팩트를 배포했더니 심각한 결제 버그가 터졌다.
    • 소스코드를 고치고 다시 빌드하려면 10분이 넘게 걸려 회사 매출이 타격을 입는다.
    • 이때 데브옵스 엔지니어는 1초 만에 중앙 창고(Nexus)를 열고, 어제 얼려둔 멀쩡했던 app-v1.2.2.jar (과거 아티팩트)를 끄집어내어 즉시 운영 서버에 덮어 씌운다(Rollback). 단 10초 만에 완벽하게 어제 상태로 복원되는 마법은 과거의 아티팩트를 영구 보관해 뒀기에 가능하다.

📢 섹션 요약 비유: 올림픽 400m 릴레이에서 1번 주자(CI 로봇)가 피땀 흘려 뛰어와서 만들어낸 빛나는 황금 바통이 바로 '아티팩트'입니다. 2번 주자(CD 배포 로봇)는 1번 주자가 어떻게 달려왔는지(컴파일 에러 등)는 관심 없고 오직 그 황금 바통만 넘겨받아 결승선(운영 서버)을 향해 냅다 달리면 끝나는, 책임을 완벽히 분리하는 환상적인 릴레이 레이스입니다.

Ⅲ. 도커(Docker)의 등장: 아티팩트의 궁극적 진화

앱만 압축하는 걸 넘어, 아예 OS(운영체제) 환경까지 통째로 얼려버린다.

  1. JAR/WAR 파일 아티팩트의 한계:
    • 옛날에는 Java 앱만 .jar로 압축해서 100대 서버에 뿌렸다.
    • 그런데 100대 서버 중 한 대가 구형 리눅스 커널을 쓰고 있거나 Java 버전이 달라서, 아티팩트를 뿌렸는데도 그 1대만 에러가 나며 뻗어버렸다 (환경 불일치의 저주).
  2. 컨테이너 이미지 (Container Image)의 등극:
    • 도커 시대가 열리며 아티팩트의 개념이 완전히 뜯어고쳐졌다.
    • 이제 CI 공장은 단순히 .jar 파일만 굽지 않는다. 그 .jar 파일을 실행할 때 완벽히 작동했던 깨끗한 리눅스 OS, Java 런타임, 환경변수 세팅까지 모두 긁어모아 하나의 거대한 쇳덩어리(Docker Image)로 통째로 얼려버린다.
    • 이것이 현대적 의미의 가장 완벽한 **'컨테이너 아티팩트'**다.
  3. 도커 레지스트리 (Docker Registry):
    • 구워진 도커 이미지는 깃허브가 아니라, 도커 전용 냉동 창고인 Docker Hub, AWS ECR, Harbor 같은 컨테이너 레지스트리에 보관된다. 쿠버네티스는 명령을 받으면 이 창고에서 냉동 아티팩트를 꺼내와 서버에 수십 개씩 찍어내어 서비스를 굴린다.

📢 섹션 요약 비유: 과거의 아티팩트(.jar)가 '완제품 카레 루'만 포장한 것이라면, 운영 서버(냄비)가 더럽거나 물 양이 다르면 맛이 망가질 위험이 컸습니다. 현대의 도커 아티팩트(Docker Image)는 아예 냄비, 생수, 버너, 카레를 완벽한 비율로 조립해 둔 '밀키트 세트' 자체를 통째로 꽝꽝 얼려놓은 것입니다. 전 세계 어디에 가져다 놔도 포장만 뜯어 불을 켜면(Run) 개발자 PC에서 맛보았던 그 완벽한 카레 맛(실행 환경)이 100% 1초의 오차 없이 재현되는 궁극의 포장 기술입니다.