기타인포그래픽
CI/CD 8단계 인포그래픽: 도구와 배포 흐름 한눈에 보기
CI/CD의 8단계를 인포그래픽 한 장으로 정리하고 도구별 역할, 승인 배포와 검증 상태를 설명합니다.
한눈에 보는 요약
대표 인포그래픽은 기업형 CI/CD 실습을 8단계로 정리합니다. 상단에는 GitLab·Jenkins·Nexus와 DEV·STG·PRD, 모니터링·롤백을 배치하고, 아래에는 단계별 작업과 결과물을 연결했습니다.
이 자료는 교육용 구성입니다. 이미지에도 실제 서버에서 전 단계가 PASS한 상태가 아님을 명시했습니다. 설계된 흐름과 실제 검증 결과를 구분해서 읽어 주세요.
인포그래픽 읽는 순서
위쪽의 도구 흐름을 먼저 보고, 세로로 이어지는 8개 작업을 따라가면 됩니다. 마지막 상태 구분은 각 작업을 실제 실행한 뒤 기록할 기준입니다. 아이콘이나 예시 결과물의 이름만으로 운영 검증이 끝났다고 판단하지 않습니다.
8단계 핵심 흐름
- 기존 통합 패키지 구조 점검: 전체 구성과 설정 충돌을 확인합니다.
- GitLab → Jenkins → Nexus 통합: 소스 변경, 빌드·테스트, 결과물 저장을 연결합니다.
- DEV 자동 배포: 개발 환경에 결과물을 올리고 주요 기능을 확인합니다.
- STG 승인 배포: 검증 환경에서 기능·성능을 점검합니다.
- PRD 승인 배포: 승인한 버전을 실제 운영 환경에 반영하고 확인합니다.
- 장애 감지와 롤백: 상태를 관찰하고 필요할 때 이전 버전으로 복구합니다.
- 전체 E2E 크로스 QA: 개별 단계뿐 아니라 처음부터 끝까지 연결해 검증합니다.
- 최종 통합 패키지 확정: 설정·스크립트·문서·검증 기록을 함께 정리합니다.
도구와 환경은 역할이 다릅니다
GitLab은 이 그림에서 소스 코드 관리 역할입니다. Jenkins는 빌드·테스트 등 반복 작업을 실행하고, Nexus는 아티팩트라고 부르는 결과물을 보관합니다. 이 조합은 하나의 구성 예시이며, CI/CD에 반드시 이 세 제품을 모두 써야 하는 것은 아닙니다.
DEV는 개발 확인, STG는 운영 전 검증, PRD는 실제 서비스 환경입니다. 환경이 달라도 어떤 소스와 결과물을 사용했는지 추적할 수 있어야 합니다. 모니터링은 배포 뒤 상태를 확인하고, 롤백은 이상이 있을 때 변경을 되돌리는 절차입니다.
승인 단계가 들어가는 이유
자동화는 모든 결정을 기계에 맡긴다는 뜻이 아닙니다. 빌드·테스트 같은 반복 작업을 자동화하면서도 운영 반영 전에는 사람이 확인하도록 구성할 수 있습니다.
이 이미지의 STG·PRD 승인 단계는 그런 운영 방식을 보여 줍니다. 승인 주체와 확인 항목을 정하지 않은 채 버튼만 추가하면 검증 근거가 남지 않을 수 있습니다.
실무 적용 포인트
- 각 단계의 입력과 결과물을 적어 연결이 끊긴 곳을 찾습니다.
- 빌드 결과물에는 소스 버전과 식별 가능한 버전을 함께 기록합니다.
- 배포 뒤 확인할 기능·로그·알림 항목을 미리 정합니다.
- 롤백은 데이터 변경 영향까지 검토하고 안전한 환경에서 절차를 확인합니다.
- 실제 계정·토큰을 공유 자료에 넣지 않습니다.
결과를 기록하는 기준
PASS는 실제 확인한 범위가 정상인 상태입니다. FAIL은 오류가 있어 수정이 필요한 상태이고, NOT TESTED는 아직 실행하지 않은 상태입니다. 예를 들어 DEV를 확인했더라도 STG를 실행하지 않았다면 STG는 NOT TESTED로 남겨야 합니다.
이미지에 적힌 CI_CD_LAB_INTEGRATED는 실습 패키지 이름입니다. 이름 자체가 배포 성공이나 검증 완료를 보증하지 않습니다.
핵심 요약
이 한 장은 CI/CD의 구성과 검증 순서를 읽는 지도입니다. 전체 흐름을 이해한 다음, 실제 환경에서는 단계별 실행 근거와 승인 기록을 별도로 확보하세요.