기타카드뉴스

기업형 CI/CD 흐름을 10장 카드뉴스로 이해하기

GitLab·Jenkins·Nexus부터 DEV·STG·PRD, 모니터링과 롤백까지 CI/CD의 흐름을 10장 카드뉴스로 살펴봅니다.

기업형 CI/CD 흐름을 10장 카드뉴스로 이해하기 대표 이미지

한눈에 보는 요약

코드를 저장하는 일과 사용자가 쓰는 서비스에 반영하는 일 사이에는 여러 확인 단계가 있습니다. 이 카드뉴스는 GitLab → Jenkins → Nexus → DEV → STG → PRD → 모니터링 → 롤백 흐름을 10장으로 연결합니다.

이미지는 학습을 위한 구성 예시입니다. 그림 속 체크 표시와 완료 표현은 실제 서버의 성공 기록이 아니며, 각 단계는 직접 실행한 결과에 따라 PASS·FAIL·NOT TESTED로 구분해야 합니다.

카드 01 | 전체 흐름부터 보기

대표 이미지에는 소스 관리부터 빌드·테스트, 환경별 배포와 복구까지의 연결이 담겨 있습니다. 먼저 전체 지도를 읽고, 각 단계에서 무엇을 확인해야 다음 단계로 갈 수 있는지 살펴보세요.

카드 02 | 기존 통합 패키지 구조 점검

카드 02. 전체 구성, 설정 충돌, 필요한 파일·계정과 환경변수·경로를 점검하는 교육용 도해
카드 02. 전체 구성, 설정 충돌, 필요한 파일·계정과 환경변수·경로를 점검하는 교육용 도해

자동화에 앞서 현재 구성을 파악합니다. 필요한 파일과 접근 권한이 준비됐는지, 환경별 설정과 경로가 섞이지 않았는지 확인합니다. 계정이나 토큰의 실제 값을 문서와 이미지에 기록하지 않습니다.

카드 03 | GitLab·Jenkins·Nexus 연결

카드 03. GitLab 코드 변경을 Jenkins 빌드·테스트와 Nexus 결과물 저장으로 연결하는 예시
카드 03. GitLab 코드 변경을 Jenkins 빌드·테스트와 Nexus 결과물 저장으로 연결하는 예시

이 구성에서 GitLab은 소스 관리, Jenkins는 빌드·테스트 자동화, Nexus는 결과물 저장 역할을 맡습니다. 아티팩트는 배포에 사용할 빌드 결과물입니다. 코드 변경으로 작업이 시작되려면 트리거와 연동 권한을 별도로 설정해야 하며, 도구를 설치하는 것만으로 자동화가 완성되지는 않습니다.

카드 04 | DEV 자동 배포

카드 04. Nexus의 빌드 결과물을 개발 환경 DEV에 배포하고 기능과 로그를 확인하는 예시
카드 04. Nexus의 빌드 결과물을 개발 환경 DEV에 배포하고 기능과 로그를 확인하는 예시

DEV는 개발 단계에서 변경 사항을 확인하는 환경입니다. 빌드 결과물이 올라갔는지뿐 아니라 주요 기능과 로그도 확인합니다. 배포 명령의 성공과 서비스의 정상 동작은 서로 다른 점검 항목입니다.

카드 05 | STG 승인 배포

카드 05. 개발 환경에서 확인한 버전을 검증 환경 STG로 보내 기능·성능을 점검하는 예시
카드 05. 개발 환경에서 확인한 버전을 검증 환경 STG로 보내 기능·성능을 점검하는 예시

STG는 운영 반영 전 검증 환경입니다. 이미지의 흐름에서는 DEV 검증 후 승인을 거쳐 STG로 진행합니다. 기능·성능·이슈를 확인하고, 어떤 버전을 어떤 기준으로 승인했는지 남깁니다.

카드 06 | PRD 승인 배포

카드 06. 승인된 버전을 운영 환경 PRD에 반영하고 서비스와 사용자 접속을 점검하는 교육용 예시
카드 06. 승인된 버전을 운영 환경 PRD에 반영하고 서비스와 사용자 접속을 점검하는 교육용 예시

PRD는 실제 사용자가 이용하는 운영 환경입니다. 검증된 버전과 운영 설정을 확인한 뒤 승인 절차에 따라 반영합니다. 카드 속 완료 장면은 학습용이며, 실제 적용 여부는 배포 기록·서비스 응답·운영 로그로 확인해야 합니다.

카드 07 | 장애 감지와 롤백

카드 07. 상태 모니터링과 알림, 이전 버전 복구 절차를 연결한 교육용 도해
카드 07. 상태 모니터링과 알림, 이전 버전 복구 절차를 연결한 교육용 도해

모니터링은 서비스 상태를 관찰하는 일이고, 롤백은 문제가 있는 변경을 이전 버전으로 되돌리는 일입니다. 어떤 신호를 장애로 볼지, 누가 복구를 결정할지 미리 정합니다. 데이터 구조가 바뀐 배포는 애플리케이션만 되돌려도 복구되지 않을 수 있어 별도 확인이 필요합니다.

카드 08 | E2E 크로스 QA

카드 08. 코드 푸시부터 빌드, 저장, 환경별 배포와 복구까지 연결해 확인하는 E2E 검증 예시
카드 08. 코드 푸시부터 빌드, 저장, 환경별 배포와 복구까지 연결해 확인하는 E2E 검증 예시

각 도구가 따로 작동하는 것과 전체 흐름이 이어지는 것은 다릅니다. End-to-End, 즉 E2E 검증에서는 코드 변경부터 최종 동작까지 연결해 확인합니다. 실제로 실행하지 않은 구간에는 성공 표시를 붙이지 않습니다.

카드 09 | 통합 패키지 정리

카드 09. 설정 파일, 스크립트, 문서와 QA 결과를 하나의 통합 패키지로 정리하는 예시
카드 09. 설정 파일, 스크립트, 문서와 QA 결과를 하나의 통합 패키지로 정리하는 예시

파일을 모으는 데서 끝내지 않고 설정·스크립트·문서의 버전이 서로 맞는지 확인합니다. 이미지의 CI_CD_LAB_INTEGRATED는 실습 결과물의 이름이며, 이 글에서 다운로드 가능한 완성 패키지를 제공한다는 의미는 아닙니다.

카드 10 | 흐름과 검증 상태 함께 관리

카드 10. CI/CD 전체 흐름과 PASS·FAIL·NOT TESTED 상태를 구분하는 안내
카드 10. CI/CD 전체 흐름과 PASS·FAIL·NOT TESTED 상태를 구분하는 안내

PASS는 확인한 범위가 정상이라는 뜻이고, FAIL은 수정이 필요한 오류, NOT TESTED는 아직 실행하지 않은 상태입니다. 일부 단계의 성공을 전체 운영 환경 검증 완료로 확대하지 않습니다.

CI와 CD, 무엇이 다를까요?

CI는 변경한 코드를 통합하고 빌드·테스트하는 과정을 반복할 수 있게 만드는 방식입니다. CD는 검증된 변경을 전달·배포하는 흐름을 이어 줍니다.

CD에는 승인 후 배포하는 Continuous Delivery와 조건을 통과하면 자동 배포하는 Continuous Deployment가 구분됩니다. 이 카드뉴스는 STG·PRD 승인 단계를 포함한 예시이며, 모든 환경을 무조건 자동 배포하라는 뜻이 아닙니다. GitLab 자체 CI/CD를 활용하는 등 다른 구성도 가능합니다.

실무 적용 전 확인할 점

  • 소스 버전과 배포할 아티팩트 버전을 연결해 기록합니다.
  • DEV·STG·PRD의 설정과 권한을 구분합니다.
  • 승인 조건과 배포 후 점검 항목을 미리 정합니다.
  • 복구할 버전과 데이터 복구 필요 여부를 확인합니다.
  • 실행하지 않은 구간은 NOT TESTED로 남깁니다.

핵심 요약

CI/CD의 핵심은 도구 이름을 외우는 것보다 변경·검증·배포·복구가 이어지는 흐름을 이해하는 데 있습니다. 먼저 DEV 구간을 실제로 확인하고, 근거가 남은 범위만 다음 환경으로 확대하세요.

기술 개념 참고

함께 읽고 적용하기

전산가이 블로그에서 웹서비스 운영 관련 글을 확인해 보세요. 현재 서비스의 배포·검증 절차를 정리하고 싶다면 문의하기에 상황을 남겨 주세요.