← wiki

GitHub Actions — 푸시 한 번에 테스트·빌드·배포가 알아서 돌게

코드를 고쳐 올릴 때마다 해야 하는 일들이 있다. 테스트를 돌려 깨진 데 없나 확인하고, 빌드해서 산출물을 만들고, 문제없으면 서버에 배포한다. 이걸 사람이 매번 손으로 하면 어떻게 될까. 느리고, 빠뜨리고, 사람마다 절차가 미묘하게 다르다. "테스트 깜빡하고 배포했다가 장애" 같은 사고가 여기서 난다.

CI/CD는 이 반복 작업을 자동화한다. CI(지속적 통합)는 "코드가 합쳐질 때마다 자동으로 테스트·빌드해 깨짐을 빨리 잡는" 것이고, CD(지속적 배포)는 "통과한 코드를 자동으로 내보내는" 것이다. GitHub Actions는 이 자동화를 GitHub 저장소 안에서 해준다. "push하면 / PR이 열리면 이런 일들이 일어나라"를 YAML 파일로 적어두면, 그 사건이 생길 때마다 GitHub가 알아서 실행한다.

이벤트push/PR
→
워크플로트리거됨
→
잡 실행러너에서
→
결과통과/실패
구조: 워크플로 > 잡 > 스텝

워크플로(workflow) 는 "언제 무엇을 한다"의 전체 묶음(YAML 한 파일). 그 안에 잡(job) 이 있고(예: test, build), 각 잡은 스텝(step) 들의 순서다(체크아웃 → 설치 → 테스트). 이 3층 구조만 잡으면 전체가 읽힌다.

1. 손으로 하면 생기는 일

자동화의 값어치를 알려면, 수동으로 할 때의 문제를 먼저 봐야 한다. 자동화는 "편하려고"가 아니라 "안전하려고" 하는 것이다.

  1. 1
    사람은 빠뜨린다

    바쁘면 테스트를 건너뛰고 배포한다.

    "이번엔 작은 수정이니까" 하고 검증을 생략하는 순간 사고가 난다. 자동화는 빠뜨리지 않는다 — 항상 같은 절차를 그대로 실행한다.

  2. 2
    절차가 사람마다 다르다

    배포 방법이 머릿속·위키에만 있어 제각각이다.

    누가 하느냐에 따라 빌드 옵션·순서가 달라진다. 워크플로로 박아두면 누가 올리든 똑같은 파이프라인을 탄다.

  3. 3
    깨짐을 늦게 안다

    한참 뒤에야 'main이 빌드 안 된다'를 발견.

    CI는 코드가 합쳐지는 매 순간 검증해, 깨짐을 가장 싼 시점(방금 그 변경)에서 잡는다. 늦게 발견할수록 원인 찾기가 비싸진다.

요약하면 자동화의 핵심 가치는 속도보다 일관성과 빠른 피드백이다. 매번 같은 절차를, 변경 즉시 돌려준다.

2. push 한 번이 파이프라인을 돌리는 흐름

워크플로가 실제로 어떻게 깨어나 도는지 따라가자. 핵심은 "특정 이벤트가 방아쇠가 된다"는 것이다.

개발자 / GitHubActions 러너
→ git push (또는 PR 열기)

정의해 둔 트리거 이벤트 발생

→ 워크플로 트리거

on: push 조건에 매칭

← 러너 할당 + 코드 체크아웃

깨끗한 가상 머신을 새로 준비

← 스텝 순차 실행

설치 → 테스트 → 빌드 → (배포)

→ 결과 보고 (✓/✗)

PR·커밋에 상태 표시

  1. 1
    트리거 — 무엇이 워크플로를 깨우나

    on: push / pull_request / schedule 등으로 시작 조건을 정한다.

    특정 브랜치 push, PR 열림, 정해진 시각 등 사건이 방아쇠다. "main에 push되면 배포", "PR 열리면 테스트"처럼 상황별로 다른 워크플로를 둘 수 있다.

  2. 2
    러너 — 깨끗한 환경에서 실행

    잡마다 새 가상 머신(러너)이 할당돼 명령을 돌린다.

    매번 깨끗한 환경에서 시작하므로 "이전 실행 찌꺼기" 문제가 없다. GitHub가 제공하는 러너를 쓰거나, 직접 띄운 러너(self-hosted)를 쓸 수도 있다.

  3. 3
    스텝 — 한 줄씩 차례로

    체크아웃 → 의존성 설치 → 테스트 → 빌드 순으로 실행.

    각 스텝은 명령 한 묶음이다. 미리 만들어진 액션(action) 을 가져다 쓰면(예: 체크아웃·캐시·배포), 자주 하는 일을 직접 안 짜도 된다 — 이게 "Actions"라는 이름의 유래다.

잡은 병렬, 스텝은 순차

한 워크플로 안의 잡들은 기본적으로 병렬로 돈다(예: 리눅스·맥 테스트 동시에). 잡 안의 스텝은 순서대로 돈다. 의존이 있으면 needs 로 "이 잡이 끝나야 다음 잡" 같은 순서를 줄 수 있다.

3. 빌드를 넘어 배포까지 — CD와 안전장치

여기까지가 주로 CI(테스트·빌드)다. 통과한 결과를 실제로 내보내는 CD를 붙이면 "push → 배포"가 한 줄로 이어진다. 다만 배포는 사고가 곧 장애이므로 안전장치가 중요하다.

  1. 1
    산출물을 만들고 넘기기

    Docker 이미지를 빌드해 레지스트리에 올린다.

    CI 단계에서 만든 이미지를 저장소에 푸시하고, 배포 단계가 그걸 끌어와 서버에 띄운다. Docker로 굳혀둔 "어디서나 같은 상자"가 여기서 빛을 발한다.

  2. 2
    비밀값은 시크릿으로

    배포 키·토큰을 코드가 아니라 Secrets에 둔다.

    배포엔 서버 접근 키·클라우드 토큰이 필요한데, 이걸 YAML에 평문 으로 적으면 유출된다. GitHub Secrets에 저장해 워크플로가 안전하게 꺼내 쓰게 한다.

  3. 3
    조건·승인으로 배포를 통제

    특정 브랜치만, 또는 사람 승인 후에만 배포.

    "main 브랜치일 때만 운영 배포", "승인 버튼을 눌러야 진행" 같은 게이트를 둔다. 자동화하되 위험한 단계엔 사람의 확인을 끼워, 자동의 속도와 통제를 함께 가져간다.

자동 배포일수록 되돌릴 길을 먼저 만든다

배포가 자동이면 나쁜 변경도 빠르게 운영에 도달한다. 그래서 문제를 빨리 발견할 모니터링(앞 글의 Grafana)과, 잘못됐을 때 이전 버전으로 되돌리는 길(rollback) 을 먼저 갖춰야 한다. "빨리 배포"보다 "빨리 되돌리기"가 안전망이다.

정리하면 GitHub Actions는 "push/PR 같은 사건 → 정해둔 작업 자동 실행"을 저장소 안에서 해주는 CI/CD 도구다. 워크플로·잡·스텝의 3층으로 절차를 코드화해, 매번 같은 검증을 변경 즉시 돌린다. CD까지 붙이면 배포가 한 줄로 이어지지만, 그만큼 시크릿 관리·승인 게이트·롤백 같은 안전장치를 함께 갖춰야 한다.

한 장 요약

  1. 1
    문제

    테스트·빌드·배포를 손으로 하면 빠뜨리고 제각각이고 늦게 깨진다.

  2. 2
    자동화

    'push/PR하면 이런 일을 하라'를 YAML로 적어두면 GitHub가 알아서 실행.

  3. 3
    구조

    워크플로(언제 무엇) > 잡(test/build, 병렬) > 스텝(순차).

  4. 4
    흐름

    이벤트 트리거 → 깨끗한 러너 할당 → 체크아웃·설치·테스트·빌드 → 결과 보고.

  5. 5
    CD

    이미지 빌드·푸시 후 배포까지 연결 — 비밀은 Secrets, 위험 단계엔 승인 게이트.

  6. 6
    안전망

    자동 배포일수록 모니터링과 롤백을 먼저 갖춰 '빨리 되돌리기'를 확보.