073. GitHub Actions 기반 CI/CD 워크플로우 (GitHub Actions CI/CD)

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

본질: GitHub Actions는 소스 코드 저장소(GitHub) 안에서 특정 이벤트(Push, PR)가 발생했을 때, 코드를 빌드하고 테스트한 뒤 클라우드 서버에 배포하는 모든 CI/CD 파이프라인을 YAML 파일 하나로 자동화하는 내장형 쇳덩어리 엔진이다.

가치: 과거 개발자들이 Jenkins(젠킨스) 서버를 따로 구축하고 관리(플러그인 충돌, 서버 다운)하느라 피를 토하던 인프라 운영 부담을 완전히 소멸시키고, 코드가 있는 곳에서 파이프라인이 즉시 도는 'Serverless CI/CD'의 시대를 열었다.

판단 포인트: 전 세계 수백만 개발자가 만들어 놓은 조립 블록(Action Marketplace)을 레고처럼 가져다 끼우기만 하면 되므로 구축 속도가 압도적이지만, 클라우드 종속성(Lock-in)이 발생하며 대규모 병렬 빌드 시 요금 폭탄을 맞을 수 있는 비용 거버넌스 통제가 필수적이다.

Ⅰ. 개요 및 필요성

소프트웨어를 개발해서 사용자에게 전달하는 과정은 지옥의 가내수공업이었다. 개발자가 코드를 짜서 GitHub에 올리면, 인프라 담당자는 별도의 Jenkins 서버에 접속해서 코드를 당겨오고(Pull), 명령어를 쳐서 빌드(Build)하고, 테스트를 돌린 다음, 만들어진 파일을 FTP나 SSH로 운영 서버에 복사해 넣어야 했다. 누군가 휴가를 가거나 명령어를 삐끗하면 배포는 터졌다.

이 끔찍한 수작업을 자동화(CI/CD)하기 위해 수많은 도구가 나왔지만, 결국 "코드가 저장되는 곳(GitHub)에서 아예 배포까지 논스톱으로 처리해 버리면 안 되나?"라는 궁극의 귀차니즘이 발동했다. Microsoft(GitHub 인수)는 코드 저장소 뒷단에 수십만 대의 가상머신(Runner) 군단을 배치하고, "너희는 .github/workflows/ 폴더에 deploy.yml이라는 작전 지시서만 넣어놔. 네가 코드를 푸시(Push)하는 순간, 우리가 뒤에서 로봇들을 깨워 알아서 빌드하고 서버에 꽂아줄게!"라고 선언했다. 이것이 데브옵스(DevOps) 생태계를 평정해 버린 GitHub Actions의 탄생이다.

📢 섹션 요약 비유: Jenkins가 집 뒷마당에 내가 직접 벽돌을 쌓아 만든 '개인 빵 굽는 화덕(유지보수 힘듦)'이라면, GitHub Actions는 내가 밀가루(코드)와 레시피(YAML)만 냉장고(GitHub)에 넣어두면, 밤사이에 마법의 요정(Runner)들이 나타나 빵을 구워서 손님 식탁(운영 서버)에까지 올려놓고 사라지는 '전자레인지급 구독형 베이커리 서비스'다.

Ⅱ. 아키텍처 및 핵심 원리

YAML 기반의 선언적 파이프라인과 Runner 아키텍처

GitHub Actions는 4개의 핵심 쇳덩어리 기어로 맞물려 돌아간다.

┌────────────────────────────────────────────────────────┐
│           GitHub Actions의 CI/CD 동작 아키텍처 흐름도            │
├────────────────────────────────────────────────────────┤
│  [ 1. Event (방아쇠) ]                                  │
│   - 개발자가 `main` 브랜치에 코드를 Push 하거나 PR을 날림     │
│             │                                          │
│             ▼                                          │
│  [ 2. Workflow (작전 지시서 - YAML 파일) ]              │
│   - `.github/workflows/main.yml` 감지 및 실행 시작        │
│             │                                          │
│             ▼                                          │
│  [ 3. Runner (가상머신 작업자 - Ubuntu, Windows 등) ]      │
│   - GitHub가 클라우드에서 빈 깡통 서버(VM)를 즉시 하나 띄움     │
│   ┌──────────────────────────────────────────────────┐ │
│   │ [ 4. Job (작업 단위) ] - 병렬 또는 순차 실행          │ │
│   │  ├─ Step 1: 소스코드 체크아웃 (actions/checkout@v3)  │ │
│   │  ├─ Step 2: Node.js 설치 (actions/setup-node@v3)   │ │
│   │  ├─ Step 3: npm run test (자동 테스트)              │ │
│   │  └─ Step 4: AWS S3로 배포 (aws-actions/...)       │ │
│   └──────────────────────────────────────────────────┘ │
│             │ (성공 시)                                 │
│             ▼                                          │
│  [ 클라우드 운영 서버 (AWS, K8s) 배포 완료 및 슬랙 알림! ]   │
└────────────────────────────────────────────────────────┘

가장 강력한 무기는 **액션 마켓플레이스(Action Marketplace)**다. "AWS에 로그인해 줘", "슬랙으로 메시지 보내줘" 같은 스크립트를 내가 짤 필요 없이, 다른 사람이 만들어둔 액션(예: uses: aws-actions/configure-aws-credentials@v1)을 레고 블록처럼 한 줄만 끼워 넣으면 복잡한 쇳덩어리 연동이 끝난다.

📢 섹션 요약 비유: 아키텍처는 '자동 세차장'과 같다. 차(코드)가 입구에 들어오면(Event), 세차장 기계(Runner)가 깨어난다. 그리고 매뉴얼(Workflow)에 따라 비눗물 뿌리기(Step 1), 솔질하기(Step 2), 물기 닦기(Step 3)라는 레고 블록 부품들이 순서대로 작동하여 반짝이는 자동차(배포 완료)를 토해내는 시스템이다.

Ⅲ. 비교 및 연결

전통의 제왕 Jenkins vs 모던 서버리스 GitHub Actions

데브옵스 엔지니어의 퇴근 시간을 결정짓는 아키텍처 전쟁이다.

비교 항목	Jenkins (젠킨스)	GitHub Actions
설치 및 인프라 관리	개발자가 직접 서버 파고 설치/유지보수 해야 함	Zero (GitHub가 다 해주는 SaaS)
플러그인/확장성	수만 개의 플러그인 (근데 서로 충돌해서 자주 뻗음)	마켓플레이스 (깔끔한 컨테이너 기반 액션 조립)
설정 방식	Groovy 스크립트 기반 (Jenkinsfile)	직관적인 YAML 파일
보안 및 자격 증명	Jenkins 서버 안에 비밀번호(Secret) 저장	GitHub 리포지토리 Settings에 안전하게 보관
비용 구조	무료 (단, 서버 호스팅/전기세/인건비 듬)	오픈소스는 완전 무료, 비공개(Private)는 시간당 과금

Jenkins는 거대한 항공모함이다. 할 수 없는 게 없지만 그 배를 유지보수하는 기관사(데브옵스 엔지니어)의 뼈를 깎아 먹는다. 반면 GitHub Actions는 내가 부를 때만 나타나는 렌터카다. 코드가 있는 곳에 CI/CD가 기본 탑재되면서, 인프라를 1도 모르는 프론트엔드 개발자도 YAML 파일 20줄만 복붙하면 10분 만에 AWS 배포 자동화를 세팅하는 기적을 낳았다.

📢 섹션 요약 비유: Jenkins는 '집에서 직접 끓여 먹는 사골국'이다. 가스레인지 불도 지켜야 하고 냄비(서버)가 넘치지 않게 계속 관리해야 한다. GitHub Actions는 '배달앱(SaaS)'이다. 메뉴(YAML)만 골라서 주문하면 식당(GitHub)에서 알아서 요리해서 문 앞(운영 서버)에 놔주고 간다. 나는 설거지(서버 관리)를 할 필요가 없다.

Ⅳ. 실무 적용 및 기술사 판단

실무 시나리오

Self-hosted Runner를 활용한 망분리(보안망) CI/CD 돌파: 금융권은 보안(망분리) 때문에 외부 인터넷에 있는 GitHub 클라우드 가상머신(Hosted Runner)이 사내 운영 서버(DB 등)에 접근할 수 없다. 아키텍트는 회사 내부망 서버에 'Self-hosted Runner'라는 에이전트 프로그램을 깔아둔다. 이 내부 에이전트가 GitHub 쪽에 "저한테 일주실 거 있나요?"라고 묻는 아웃바운드(Outbound) 통신만 열어주면, 코드는 GitHub에 올리되 실제 빌드와 배포(쇳덩어리 작업)는 사내 보안망 안에서 돌아가게 만드는 극강의 하이브리드 CI/CD 우회로를 완성한다.
OIDC (OpenID Connect) 기반의 무인증(Keyless) AWS 배포: 과거엔 GitHub Actions가 AWS에 배포하려면 AWS Access Key(비밀번호)를 GitHub에 저장해야 했다. 이 키가 해커에게 털리면 AWS에서 비트코인이 채굴되며 1억 원의 요금 폭탄을 맞는다. 최신 아키텍처는 OIDC를 도입한다. 키를 저장하지 않고, GitHub와 AWS가 서로 신뢰(Trust) 관계만 맺어둔다. 배포할 때마다 GitHub가 "나 믿지? 문 열어"라고 임시 토큰(1시간짜리)을 발급받아 배포하고 버리는 완벽한 제로 트러스트(Zero Trust) 보안 배포 파이프라인을 구축한다.

안티패턴

모든 커밋(Commit)마다 무거운 E2E 테스트 돌리기 (요금 폭탄 및 병목): 개발팀이 "품질을 올리자!"며 띄어쓰기 하나 수정한 커밋을 푸시할 때마다, 30분이 걸리는 모바일 앱 전체 UI 테스트(E2E) 워크플로우를 돌려버리는 만행. GitHub Actions는 프라이빗 저장소에서 '실행 시간'만큼 달러($) 단위로 요금이 청구된다. 한 달 뒤 회사로 수백만 원의 빌드 요금 청구서가 날아오고 파이프라인 큐가 꽉 차서 다른 팀은 배포를 못 해 멈춰버린다. CI/CD는 paths 필터링(특정 폴더 변경 시만 실행)이나 pull_request 타겟팅을 통해 꼭 필요한 순간에만 쇳덩어리가 돌게 트리거(Trigger)를 최적화해야 한다.
📢 섹션 요약 비유: 커밋마다 E2E 테스트를 돌리는 것은, 요리사가 스프에 '소금 한 꼬집' 더 넣을 때마다 알바생(GitHub Runner)에게 시급 1만 원을 주며 30분짜리 전체 코스 요리 맛 평가를 시키는 짓이다. 비용도 파산이지만, 맛 평가를 기다리느라 주방(개발)이 완전히 멈춰버린다.

Ⅴ. 기대효과 및 결론

GitHub Actions는 CI/CD라는 거대하고 무거운 인프라 엔지니어링의 영역을, 개발자 누구나 숨 쉬듯 사용할 수 있는 '코드의 일부(Pipeline as Code)'로 추락(대중화)시킨 가장 위대한 데브옵스 혁명이다.

개발자들은 더 이상 배포 스크립트를 짜느라 밤을 새우거나 Jenkins 서버가 죽었다고 절망하지 않는다. main 브랜치에 코드가 머지(Merge)되는 순간, 수십 개의 가상머신이 클라우드 위에서 병렬로 깨어나 코드를 컴파일하고, 보안 취약점을 검사하고, 도커(Docker) 이미지를 말아 K8s 클러스터에 꽂아 넣은 뒤 조용히 사라진다. 결론적으로 GitHub Actions는 인간의 나약함(실수, 귀찮음)을 쇳덩어리 자동화로 완벽하게 대체하여, 개발자가 오직 '비즈니스 로직(코드)' 창조에만 미쳐있을 수 있게 만드는 데브옵스의 최종 진화 형태다.

📢 섹션 요약 비유: GitHub Actions는 롤플레잉 게임의 '자동 사냥(Auto-play) 매크로'다. 과거엔 레벨업(배포)을 위해 몬스터를 클릭(빌드/테스트/복사)하느라 마우스가 박살 났지만, 이제는 매크로 스위치(YAML)만 켜두면 내가 자는 동안에도 캐릭터가 알아서 싸우고 아이템을 주워 창고(서버)에 꽉꽉 채워두는 축복이다.

📌 관련 개념 맵

개념	연결 포인트
CI/CD (지속적 통합/지속적 배포)	개발자가 코드를 합칠 때마다 기계가 자동으로 테스트(CI)하고, 통과하면 사용자 서버에 무중단으로 밀어 넣는(CD) 현대 소프트웨어 공학의 절대 숨결
YAML (Ain't Markup Language)	들여쓰기 2칸으로 모든 로직의 계층 구조를 표현하는, GitHub Actions 작전 지시서(Workflow)를 작성하는 표준 선언적 언어
Docker (도커)	GitHub Actions의 가상머신(Runner) 위에서 가장 많이 굴러가는 쇳덩어리 포장지. 코드를 빌드해서 컨테이너 이미지로 구워낸 뒤 클라우드에 쏴버리는 CI/CD 배포의 핵심 매개체

📈 관련 키워드 및 발전 흐름도

수작업 배포의 한계 및 인간의 실수(Human Error)로 인한 서비스 장애 폭증
    │
    ▼
서버 설치형 CI/CD 도구의 등장 (Jenkins 등) ──▶ 인프라 유지보수 고통 발생
    │
    ▼
클라우드 벤더의 관리형 파이프라인 서비스 등장 (AWS CodePipeline, Travis CI)
    │
    ▼
코드 저장소(Git)와 CI/CD 파이프라인의 물리적 결합 ──▶ GitHub Actions 발표 (2018)
    │
    ▼
마켓플레이스(생태계)를 통한 레고식 조립 및 서버리스(Serverless) CI/CD의 클라우드 천하통일

이 흐름도는 "가내수공업 → 거대 기계 도입(유지보수 고통) → 클라우드 아웃소싱 → 코드 저장소와의 궁극의 융합(SaaS화)"이라는 인프라 추상화의 역사를 완벽하게 보여준다.

👶 어린이를 위한 3줄 비유 설명

GitHub Actions는 우리가 만든 레고 조각(코드)을 조립 설명서(YAML)와 함께 마법 상자에 넣어두면 켜지는 요술 공장이에요.
예전에는 내가 직접 레고를 조립하고 페인트를 칠해서 전시장에 갖다 놔야 해서 너무 힘들고 실수도 많았죠.
이제는 상자에 레고를 던져넣기만 하면, 공장의 요정들이 순식간에 나타나 조립하고 튼튼한지 검사한 다음 예쁘게 포장해서 백화점(서버) 진열대까지 알아서 올려놓는답니다!