[BASIC #1] CI/CD 개념부터 GitHub Actions 이해하기 - 이론편

0. 들어가며

현대 소프트웨어 개발에서 빠른 개발과 안정적인 배포는 필수 요소다. 여러 명의 개발자가 동시에 코드를 수정하고, 새로운 기능을 빠르게 릴리스해야 하는 상황에서, 자동화된 테스트와 배포는 선택이 아닌 필수다.

하지만 막상 "CI/CD를 도입하자"라고 하면, "그게 뭔데?"라는 질문이 먼저 나오기 마련이다. 이번 포스팅에서는 CI/CD의 개념부터 시작해, 이를 구현하는 대표적인 도구인 GitHub Actions가 무엇인지, 왜 사용하는지, 어떤 구조로 동작하는지 이론적으로 알아보겠다.

---

1. CI/CD란 무엇인가?

1.1. CI (Continuous Integration) - 지속적 통합

CI(지속적 통합)는 개발자들이 작성한 코드 변경 사항을 하루에 여러 번 공유 저장소에 자주 통합하는 방식이다.

핵심 개념:

• 여러 개발자가 동시에 작업하는 코드를 정기적으로 통합한다.
• 통합할 때마다 자동화된 빌드와 테스트를 실행한다.
• 이를 통해 코드 충돌이나 오류를 조기에 발견하고 빠르게 수정할 수 있다.

CI가 없을 때의 문제점:

• 개발자 A, B, C가 각자 기능을 개발하고 몇 주 후에 통합하려고 한다.
• A의 코드와 B의 코드가 충돌하고, C의 코드는 테스트를 깨뜨린다.
• 충돌 해결과 버그 수정에 예상보다 훨씬 많은 시간이 소요된다.
• "어? 내 컴퓨터에서는 잘 됐는데?"라는 말이 반복된다.

CI 도입 후:

• 개발자가 코드를 push할 때마다 자동으로 빌드와 테스트가 실행된다.
• 문제가 발생하면 즉시 알림을 받고 빠르게 수정할 수 있다.
• 항상 안정적인 코드 상태를 유지할 수 있다.

1.2. CD (Continuous Deployment) - 지속적 배포

CD(지속적 배포)는 CI를 통과한 코드를 자동으로 배포 환경에 반영하는 방식이다.

핵심 개념:

• 테스트를 통과한 코드는 사람의 개입 없이 자동으로 배포된다.
• 배포 주기를 단축하고, 수동 배포에서 발생할 수 있는 실수를 방지한다.
• 사용자에게 새로운 기능을 더 빠르게 전달할 수 있다.

CD의 단계:

1. Continuous Delivery (지속적 전달): 배포 가능한 상태로 준비만 하고, 실제 배포는 수동으로 승인하는 방식
2. Continuous Deployment (지속적 배포): 모든 단계를 자동화하여 실제 운영 환경까지 자동 배포하는 방식

1.3. CI/CD 전체 흐름

코드 작성 → Git Push → 자동 빌드 → 자동 테스트 → 자동 배포 → 사용자

이 전체 과정이 자동화되면 개발자는 코드 작성에만 집중할 수 있고, 운영팀은 배포 리스크 없이 지속적으로 서비스를 개선할 수 있다.

---

2. GitHub Actions란?

2.1. 정의

GitHub Actions는 GitHub에서 자체적으로 제공하는 CI/CD 자동화 플랫폼이다.

코드 저장소인 GitHub 안에서, 특정 이벤트(예: push, pull_request)가 발생할 때마다 자동으로 특정 작업을 수행하도록 설정할 수 있다.

2.2. 왜 GitHub Actions를 사용하는가?

① 통합된 환경

• 별도의 CI/CD 도구(Jenkins, Travis CI, Circle CI 등)를 설치하거나 관리할 필요가 없다.
• 코드 저장소와 CI/CD 파이프라인이 같은 플랫폼에 있어 관리가 편리하다.

② 풍부한 액션 생태계

• GitHub Marketplace에서 수많은 재사용 가능한 액션(Action) 을 제공한다.
• 복잡한 작업도 몇 줄의 코드로 구현할 수 있다. (예: AWS 배포, Slack 알림, Docker 빌드)

③ GitHub과의 긴밀한 통합

• PR 생성, 이슈 생성, 릴리스 등 GitHub의 모든 이벤트를 트리거로 사용할 수 있다.
• PR에 테스트 결과를 자동으로 코멘트로 남기는 등 세밀한 연동이 가능하다.

④ 무료 사용

• 공개 저장소는 무제한 무료로 사용할 수 있다.
• 비공개 저장소도 월 2,000분까지 무료로 제공된다.

2.3. GitHub Actions로 할 수 있는 작업들

작업 유형	예시
테스트 자동화	PR 생성 시 테스트 실행, 테스트 결과 코멘트
빌드 자동화	main 브랜치 push 시 자동 빌드
배포 자동화	빌드 성공 시 AWS, GCP, Heroku 등에 자동 배포
정기 작업	매일 새벽 데이터 백업, 주간 리포트 생성
이슈 관리	특정 라벨 추가 시 자동 알림, 이슈 템플릿 처리

---

 

3. GitHub Actions의 핵심 구성 요소

GitHub Actions는 여러 구성 요소들이 상호작용하며 동작한다.

3.1. Workflow (워크플로우)

• 정의: 하나 이상의 Job으로 구성된 자동화 프로세스 단위다.
• 위치: 저장소 내 .github/workflows 디렉토리에 YAML 파일로 저장한다.
• 특징: 하나의 저장소에 여러 개의 워크플로우 파일을 둘 수 있다.

3.2. Event (이벤트)

• 정의: 워크플로우 실행을 트리거하는 특정 활동이다.
• 종류:
  • push: 코드를 push할 때
  • pull_request: PR이 생성, 수정, 재오픈될 때
  • schedule: cron 표현식으로 정기적 실행
  • workflow_dispatch: 수동으로 실행
  • release: 릴리스 생성 시

3.3. Job (잡)

• 정의: 하나의 실행 단위다. 여러 Step으로 구성된다.
• 특징: 기본적으로 여러 Job은 병렬 실행되며, 필요시 needs 키워드로 순차 실행도 가능하다.

3.4. Step (스텝)

• 정의: Job 내에서 실제 실행되는 작업의 최소 단위다.
• 구성:
  • Shell 명령어(run) 실행
  • 미리 정의된 Action(uses) 사용

3.5. Action (액션)

• 정의: 재사용 가능한 코드 블록 모듈이다.
• 특징: 복잡한 작업을 단순화하기 위해 패키징된 것이다.
• 예시:
  • actions/checkout@v4: 저장소 코드를 Runner로 가져온다.
  • actions/setup-java@v4: Java 환경을 설정한다.
  • docker/build-push-action@v5: Docker 이미지를 빌드하고 Push한다.

3.6. Runner (러너)

• 정의: 워크플로우 Job을 실제로 실행하는 서버다.
• 종류:
  • GitHub-hosted runner: GitHub에서 제공하는 가상 머신 (Ubuntu, Windows, macOS)
  • Self-hosted runner: 사용자가 직접 구성한 서버

3.7. 구성 요소들의 관계

[이벤트 발생] (push, pull_request 등)
       ↓
[워크플로우 실행] (.github/workflows/*.yml)
       ↓
[Job 실행] (병렬 또는 순차적)
       ↓
[Step 실행] (run 또는 uses)
       ↓
[Action 실행] (재사용 가능한 모듈)

---

 

4. GitHub Actions의 장점과 한계

4.1. 장점

장점	설명
통합성	GitHub에 내장되어 있어 별도 도구 설치 불필요
확장성	Marketplace의 다양한 Action 활용 가능
유연성	거의 모든 언어와 프레임워크 지원
가시성	Actions 탭에서 실행 상태, 로그, 결과를 한눈에 확인
커뮤니티	방대한 예제와 템플릿 존재

4.2. 한계

한계	설명
복잡한 파이프라인	매우 복잡한 파이프라인은 YAML로 표현하기 어려울 수 있음
디버깅	로컬에서 테스트하기 어렵고, 실행 후에야 문제 확인 가능
시간 제한	Job당 최대 실행 시간 6시간 (대부분의 경우 충분)

---

 

5. 정리

이번 포스팅에서는 다음과 같은 내용을 알아보았다.

1. CI/CD 개념: 지속적 통합과 지속적 배포가 무엇이고 왜 필요한지
2. GitHub Actions 정의: GitHub에서 제공하는 CI/CD 자동화 플랫폼
3. 핵심 구성 요소: Workflow, Event, Job, Step, Action, Runner
4. 장점과 한계: 왜 GitHub Actions를 사용하는지, 어떤 제약이 있는지