GitHub Actions 워크플로우 기초 완벽 가이드

GitHub Actions로 CI/CD 파이프라인을 구축하는 방법을 배웁니다. 워크플로우 파일의 구조부터 실제 자동화까지 초급 개발자도 쉽게 따라할 수 있도록 설명합니다.

---

목차

1. 워크플로우 파일 위치
2. YAML 기본 문법
3. name과 on 키워드
4. jobs와 steps 구조
5. runs-on 러너 선택
6. uses와 run 차이

---

1. 워크플로우 파일 위치

김개발 씨는 오늘 팀에 합류한 신입 개발자입니다. 선배가 "코드 푸시하면 자동으로 테스트 돌아가니까 걱정 마세요"라고 말했는데, 도대체 그 마법 같은 설정이 어디에 있는 걸까요?

프로젝트 폴더를 이리저리 뒤져봐도 도통 찾을 수가 없습니다.

GitHub Actions의 워크플로우 파일은 반드시 .github/workflows 디렉토리 안에 위치해야 합니다. 마치 우체부가 정해진 우편함에서만 편지를 수거하는 것처럼, GitHub도 이 특정 폴더만 바라보고 있습니다.

이 규칙을 지키지 않으면 아무리 완벽한 워크플로우를 작성해도 실행되지 않습니다.

다음 코드를 살펴봅시다.

# 프로젝트 루트에서 디렉토리 구조
my-project/
├── .github/
│   └── workflows/
│       ├── ci.yml        # CI 파이프라인
│       ├── deploy.yml    # 배포 자동화
│       └── test.yml      # 테스트 자동화
├── src/
│   └── index.ts
├── package.json
└── README.md

김개발 씨는 입사 첫날부터 신기한 경험을 했습니다. 코드를 GitHub에 푸시하자마자 자동으로 테스트가 실행되고, 문제가 없으면 스테이징 서버에 배포까지 완료된 것입니다.

마치 보이지 않는 손이 모든 것을 처리해주는 것 같았습니다. "이거 어떻게 된 거예요?" 김개발 씨가 물었습니다.

선배 개발자 박시니어 씨가 웃으며 대답했습니다. "GitHub Actions라는 거야.

설정 파일 한번 볼래?" 박시니어 씨가 프로젝트의 .github/workflows 폴더를 열어 보여주었습니다. 그 안에는 여러 개의 YAML 파일이 정리되어 있었습니다.

이것이 바로 모든 자동화의 비밀이었습니다. GitHub Actions에서 워크플로우 파일의 위치는 절대적인 규칙입니다.

반드시 프로젝트 최상위에 .github 폴더를 만들고, 그 안에 workflows 폴더를 만들어야 합니다. 이 경로를 정확히 지키지 않으면 GitHub은 워크플로우 파일을 인식하지 못합니다.

왜 이렇게 엄격할까요? 쉽게 비유하자면, 아파트 우편함과 같습니다.

우체부는 정해진 우편함에서만 편지를 수거합니다. 현관문 앞에 편지를 놓아두면 아무도 가져가지 않는 것처럼, GitHub도 오직 .github/workflows 폴더만 확인합니다.

파일 확장자는 .yml 또는 .yaml 둘 다 사용할 수 있습니다. 기능상 차이는 전혀 없으니 팀 컨벤션에 따라 선택하면 됩니다.

다만 하나로 통일하는 것이 코드베이스를 깔끔하게 유지하는 방법입니다. 하나의 프로젝트에 여러 워크플로우 파일을 둘 수 있다는 점도 중요합니다.

테스트용, 배포용, 코드 품질 검사용 등 목적에 따라 파일을 분리하면 관리가 훨씬 수월해집니다. 각 파일은 독립적으로 실행되므로 서로 영향을 주지 않습니다.

김개발 씨가 고개를 끄덕였습니다. "아, 그래서 ci.yml, deploy.yml로 나눠져 있었군요!" 이제 그 구조가 이해되기 시작했습니다.

초보 개발자들이 자주 하는 실수 중 하나는 폴더 이름을 잘못 쓰는 것입니다. github이 아니라 .github입니다.

앞에 점이 반드시 있어야 합니다. 이 점 하나 때문에 워크플로우가 작동하지 않아 몇 시간을 헤매는 경우도 있습니다.

이제 첫 번째 관문을 통과했습니다. 워크플로우 파일이 어디에 있어야 하는지 알았으니, 다음은 그 파일 안에 무엇을 써야 하는지 알아볼 차례입니다.

실전 팁

💡 - 폴더 이름은 반드시 .github/workflows여야 합니다. 오타에 주의하세요.

• 여러 워크플로우 파일을 만들어 목적별로 분리하면 유지보수가 편합니다.

---

2. YAML 기본 문법

워크플로우 파일을 열어본 김개발 씨는 당황했습니다. JSON도 아니고 JavaScript도 아닌 이상한 형식의 파일이었기 때문입니다.

들여쓰기로 구조를 표현하는 이 문법, 도대체 어떻게 읽어야 하는 걸까요?

YAML은 "YAML Ain't Markup Language"의 약자로, 사람이 읽기 쉽도록 설계된 데이터 직렬화 형식입니다. 마치 깔끔하게 정리된 메모장처럼 들여쓰기만으로 계층 구조를 표현합니다.

중괄호나 괄호 대신 공백으로 구조를 나타내기 때문에 처음엔 어색하지만 익숙해지면 JSON보다 훨씬 읽기 편합니다.

다음 코드를 살펴봅시다.

# 문자열 값 (따옴표 선택사항)
name: My Workflow
description: "이것은 설명입니다"

# 숫자와 불리언
timeout: 30
enabled: true

# 리스트 (배열)
fruits:
  - apple
  - banana
  - orange

# 중첩된 객체
person:
  name: Kim
  age: 25
  skills:
    - JavaScript
    - Python

김개발 씨는 처음 YAML 파일을 보고 멍해졌습니다. 중괄호도 없고, 세미콜론도 없고, 그냥 텍스트가 들여쓰기되어 나열되어 있을 뿐이었습니다.

"이게 정말 프로그래밍 파일 맞아요?" 박시니어 씨가 차근차근 설명해주었습니다. "YAML은 사람이 읽기 편하도록 만들어진 포맷이야.

JSON이랑 똑같은 정보를 담을 수 있는데, 훨씬 깔끔하게 생겼지." YAML의 핵심은 들여쓰기입니다. 탭이 아닌 스페이스로 들여쓰기를 하며, 보통 2칸을 사용합니다.

들여쓰기가 같은 항목들은 같은 레벨에 있고, 더 들여쓰기된 항목은 부모의 자식이 됩니다. 마치 책의 목차에서 소제목이 대제목 아래에 들여쓰기되어 있는 것과 같습니다.

키-값 쌍은 콜론으로 구분합니다. name: My Workflow라고 쓰면 name이라는 키에 My Workflow라는 값이 할당됩니다.

문자열에 특수문자가 없다면 따옴표 없이 그냥 써도 됩니다. 하지만 콜론이나 특수기호가 포함된 경우에는 따옴표로 감싸주어야 합니다.

리스트는 하이픈으로 표현합니다. 하이픈 뒤에 공백 하나를 두고 항목을 적습니다.

JSON의 대괄호 배열과 같은 역할을 합니다. 여러 개의 하이픈이 같은 들여쓰기 레벨에 있으면 하나의 배열을 구성합니다.

YAML에서 가장 주의해야 할 점은 들여쓰기 일관성입니다. 스페이스 2칸을 쓰기로 했다면 전체 파일에서 동일하게 유지해야 합니다.

탭과 스페이스를 섞어 쓰면 파싱 에러가 발생합니다. 이 때문에 많은 개발자들이 처음에 고생합니다.

김개발 씨가 물었습니다. "그러면 JSON이랑 뭐가 다른 거예요?" 박시니어 씨가 대답했습니다.

"내용은 같아. 표현 방식만 다를 뿐이지.

YAML이 더 읽기 쉬워서 설정 파일에 많이 쓰여." 실제로 YAML은 Docker Compose, Kubernetes, GitHub Actions 등 DevOps 도구들의 표준 설정 파일 형식으로 자리 잡았습니다. 한번 익혀두면 여러 곳에서 활용할 수 있으니 시간을 들여 제대로 배워둘 가치가 있습니다.

주석은 샵 기호로 시작합니다. 코드에 설명을 달아두면 나중에 다른 팀원이나 미래의 자신이 이해하기 쉬워집니다.

워크플로우 파일에도 적극적으로 주석을 활용하세요. "아, 들여쓰기가 핵심이군요!" 김개발 씨가 이해한 듯 고개를 끄덕였습니다.

이제 YAML 문법의 기초를 익혔으니, 본격적으로 워크플로우 파일의 내용을 채워볼 차례입니다.

실전 팁

💡 - 탭 대신 스페이스 2칸으로 들여쓰기하세요. 대부분의 편집기에서 설정 가능합니다.

• 특수문자가 포함된 문자열은 따옴표로 감싸주세요.
• VS Code의 YAML 확장을 설치하면 문법 오류를 바로 잡아줍니다.

---

3. name과 on 키워드

YAML 문법을 익힌 김개발 씨는 이제 워크플로우 파일을 직접 작성해보려 합니다. 하지만 빈 파일 앞에서 막막해졌습니다.

가장 먼저 무엇을 써야 할까요? 모든 워크플로우의 시작점인 name과 on을 알아봅시다.

name은 워크플로우의 이름을 정의하고, on은 워크플로우가 언제 실행될지를 결정합니다. name은 GitHub Actions 탭에서 보여지는 식별자 역할을 하고, on은 트리거 조건을 설정하는 핵심 키워드입니다.

이 두 가지가 모든 워크플로우 파일의 시작점입니다.

다음 코드를 살펴봅시다.

# 워크플로우 이름 정의
name: CI Pipeline

# 트리거 조건 설정
on:
  # push 이벤트 발생 시
  push:
    branches:
      - main
      - develop
  # PR 이벤트 발생 시
  pull_request:
    branches:
      - main
  # 수동 실행 허용
  workflow_dispatch:
  # 매일 자정에 실행 (cron)
  schedule:
    - cron: '0 0 * * *'

김개발 씨가 새 워크플로우 파일을 만들었습니다. .github/workflows/ci.yml이라는 이름으로요.

파일을 열고 커서가 깜빡이는 빈 화면을 바라봅니다. "여기서부터 뭘 써야 하지?" 박시니어 씨가 어깨너머로 화면을 봅니다.

"워크플로우 파일은 항상 name과 on으로 시작해. 이름을 짓고, 언제 실행할지 정하는 거야." name 키워드는 워크플로우의 이름을 정의합니다.

이 이름은 GitHub 저장소의 Actions 탭에서 보여집니다. 여러 워크플로우가 있을 때 구분하기 쉽도록 명확한 이름을 붙여주는 것이 좋습니다.

"CI Pipeline", "Deploy to Production", "Nightly Build" 같은 식으로요. on 키워드는 워크플로우가 언제 실행될지를 결정하는 트리거입니다.

마치 알람 시계의 설정과 같습니다. 특정 시간에 울리게 할 수도 있고, 특정 이벤트가 발생했을 때 울리게 할 수도 있습니다.

가장 많이 사용하는 트리거는 push입니다. 코드가 저장소에 푸시되면 워크플로우가 실행됩니다.

branches 옵션을 추가하면 특정 브랜치에 푸시될 때만 실행되도록 제한할 수 있습니다. main 브랜치에 푸시될 때만 배포 워크플로우를 실행하는 식으로요.

pull_request 트리거는 PR이 생성되거나 업데이트될 때 실행됩니다. 코드 리뷰 전에 자동으로 테스트를 돌려서 문제가 없는지 확인하는 용도로 많이 사용합니다.

이렇게 하면 리뷰어가 직접 테스트를 돌려볼 필요가 없어집니다. workflow_dispatch는 수동 실행을 가능하게 합니다.

GitHub 웹 인터페이스에서 버튼 하나로 워크플로우를 실행할 수 있습니다. 긴급 배포나 디버깅 상황에서 유용합니다.

schedule 트리거는 cron 표현식을 사용해 정해진 시간에 워크플로우를 실행합니다. 매일 밤 전체 테스트를 돌리거나, 주기적으로 의존성을 업데이트하는 등의 작업에 활용할 수 있습니다.

하나의 on 아래에 여러 트리거를 동시에 설정할 수 있다는 점이 중요합니다. push와 pull_request를 함께 설정하면 두 이벤트 모두에서 워크플로우가 실행됩니다.

상황에 맞게 조합해서 사용하면 됩니다. 김개발 씨가 코드를 따라 쳐보며 말했습니다.

"아, 그래서 제가 PR을 올리면 자동으로 테스트가 돌아갔던 거군요!" 이제 워크플로우가 언제 실행되는지의 비밀이 풀렸습니다.

실전 팁

💡 - name은 Actions 탭에서 보이는 이름이니 명확하게 지어주세요.

• 특정 브랜치에서만 실행하고 싶다면 branches 옵션을 활용하세요.
• workflow_dispatch를 추가해두면 긴급 상황에서 수동 실행이 가능합니다.

---

4. jobs와 steps 구조

트리거 설정을 마친 김개발 씨는 이제 실제로 무엇을 할지 정의해야 합니다. "테스트 돌리고, 빌드하고, 배포해야 하는데 이걸 어떻게 구조화하지?" 워크플로우의 핵심 뼈대인 jobs와 steps에 대해 알아봅시다.

jobs는 워크플로우 내에서 실행되는 작업 단위이고, steps는 각 job 안에서 순차적으로 실행되는 개별 명령들입니다. 마치 요리 레시피에서 jobs가 "전채요리", "메인요리", "디저트"라면, steps는 각 요리를 만드는 세부 조리 과정과 같습니다.

이 구조를 이해하면 복잡한 CI/CD 파이프라인도 깔끔하게 설계할 수 있습니다.

다음 코드를 살펴봅시다.

name: CI Pipeline

on:
  push:
    branches: [main]

jobs:
  # 첫 번째 job: 테스트
  test:
    runs-on: ubuntu-latest
    steps:
      - name: 코드 체크아웃
        uses: actions/checkout@v4
      - name: Node.js 설치
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: 의존성 설치
        run: npm install
      - name: 테스트 실행
        run: npm test

  # 두 번째 job: 빌드
  build:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - name: 코드 체크아웃
        uses: actions/checkout@v4
      - name: 빌드 실행
        run: npm run build

김개발 씨는 이제 워크플로우의 실제 내용을 채워야 합니다. 테스트도 돌려야 하고, 빌드도 해야 하고, 배포도 해야 합니다.

"이걸 어떻게 정리하면 좋을까요?" 박시니어 씨가 화이트보드에 그림을 그리며 설명합니다. "워크플로우는 크게 jobs로 나눠.

각 job은 독립적인 작업 단위야. 그리고 job 안에 steps가 있어.

steps는 순서대로 실행되는 명령들이지." jobs는 워크플로우의 주요 작업 단위입니다. 마치 공장의 생산 라인처럼, 각 job은 자신만의 환경에서 독립적으로 실행됩니다.

test라는 job, build라는 job, deploy라는 job을 따로 만들 수 있습니다. 중요한 점은 기본적으로 jobs는 병렬로 실행된다는 것입니다.

test와 build 두 개의 job이 있다면 동시에 시작됩니다. 하지만 빌드는 테스트가 통과한 후에 실행되어야 하겠죠?

이때 needs 키워드를 사용합니다. needs: test라고 쓰면 "test job이 성공한 후에 실행하라"는 의미입니다.

이렇게 job 간의 의존성을 설정할 수 있습니다. test가 실패하면 build는 아예 실행되지 않습니다.

steps는 job 안에서 순차적으로 실행되는 개별 작업입니다. 각 step은 name을 가질 수 있고, 이 이름이 GitHub Actions 화면에서 보여집니다.

어떤 단계가 실패했는지 쉽게 파악할 수 있도록 명확한 이름을 붙여주세요. steps는 위에서 아래로 순서대로 실행됩니다.

첫 번째 step이 완료되어야 두 번째 step이 시작됩니다. 만약 어느 step에서 에러가 발생하면 이후 steps는 실행되지 않고 job 전체가 실패로 표시됩니다.

김개발 씨가 질문합니다. "그러면 test job과 build job이 각각 다른 머신에서 돌아가는 건가요?" 박시니어 씨가 고개를 끄덕입니다.

"맞아. 각 job은 완전히 새로운 환경에서 시작해.

그래서 코드 체크아웃을 매번 해줘야 해." 이것이 바로 초보자들이 헷갈리는 부분입니다. job 간에는 파일이나 데이터가 공유되지 않습니다.

이전 job에서 빌드한 결과물을 다음 job에서 사용하려면 별도의 artifact 업로드/다운로드 과정이 필요합니다. 이제 워크플로우의 전체 구조가 그려지기 시작합니다.

on으로 언제 실행할지 정하고, jobs로 무슨 작업을 할지 나누고, steps로 각 작업의 세부 과정을 정의합니다. 레고 블록처럼 조립하는 것이죠.

실전 팁

💡 - job 이름은 영문 소문자와 하이픈으로 간결하게 지어주세요.

• needs를 사용해 job 실행 순서를 제어할 수 있습니다.
• 각 step에 명확한 name을 붙이면 디버깅이 쉬워집니다.

---

5. runs-on 러너 선택

jobs 구조를 배운 김개발 씨가 코드를 다시 보니 모든 job에 runs-on: ubuntu-latest라는 줄이 있습니다. "이게 뭐예요?

우분투라면 리눅스 아닌가요?" 워크플로우가 실제로 어디서 실행되는지 알아봅시다.

runs-on은 job이 실행될 가상 머신 환경을 지정합니다. GitHub은 Linux, Windows, macOS 러너를 무료로 제공하며, 각각 다른 운영체제 환경에서 코드를 테스트할 수 있습니다.

마치 클라우드에 잠시 빌려 쓰는 컴퓨터라고 생각하면 됩니다. job이 끝나면 깨끗이 사라지는 일회용 환경입니다.

다음 코드를 살펴봅시다.

jobs:
  # Linux 환경에서 실행
  test-linux:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Running on Ubuntu"

  # Windows 환경에서 실행
  test-windows:
    runs-on: windows-latest
    steps:
      - run: echo "Running on Windows"

  # macOS 환경에서 실행
  test-macos:
    runs-on: macos-latest
    steps:
      - run: echo "Running on macOS"

  # 특정 버전 지정
  test-specific:
    runs-on: ubuntu-22.04
    steps:
      - run: cat /etc/os-release

김개발 씨가 궁금해졌습니다. "워크플로우가 실행되는 건 알겠는데, 대체 어디서 실행되는 거예요?

제 컴퓨터는 아닌 것 같은데요." 박시니어 씨가 설명합니다. "GitHub이 서버를 빌려주는 거야.

우리가 runs-on에 적은 환경으로. 러너라고 불러." **러너(Runner)**는 워크플로우를 실행하는 서버입니다.

GitHub이 제공하는 호스팅 러너를 사용하면 별도의 서버 관리 없이 바로 CI/CD를 구축할 수 있습니다. 매번 깨끗한 상태에서 시작하므로 이전 실행의 영향을 받지 않습니다.

ubuntu-latest는 가장 많이 사용되는 러너입니다. 대부분의 웹 프로젝트는 리눅스 환경에서 문제없이 동작하기 때문입니다.

latest를 붙이면 GitHub이 안정적인 최신 버전을 자동으로 선택해줍니다. 현재는 Ubuntu 22.04가 latest로 지정되어 있습니다.

특정 버전이 필요하다면 ubuntu-22.04처럼 명시적으로 지정할 수 있습니다. 프로덕션 환경과 동일한 OS 버전에서 테스트하고 싶을 때 유용합니다.

버전을 고정하면 GitHub의 latest 변경에 영향받지 않는 장점도 있습니다. windows-latest는 Windows 전용 애플리케이션을 개발할 때 필요합니다.

.NET 프로젝트나 Windows 설치 파일을 빌드할 때 주로 사용합니다. PowerShell 명령어를 사용할 수 있습니다.

macos-latest는 iOS나 macOS 앱을 빌드할 때 필수입니다. Xcode가 설치되어 있어 Swift 프로젝트도 빌드할 수 있습니다.

다만 macOS 러너는 리눅스보다 사용 비용이 높으므로 꼭 필요한 경우에만 사용하는 것이 좋습니다. 흥미로운 점은 하나의 워크플로우에서 여러 OS를 동시에 테스트할 수 있다는 것입니다.

매트릭스 전략을 사용하면 Ubuntu, Windows, macOS에서 한 번에 테스트를 돌릴 수 있습니다. 크로스 플랫폼 라이브러리를 개발할 때 매우 유용합니다.

김개발 씨가 감탄합니다. "와, 제가 맥북이 없어도 macOS에서 테스트할 수 있다는 거네요?" 박시니어 씨가 웃으며 대답합니다.

"그렇지. 클라우드의 힘이야." 러너에는 다양한 소프트웨어가 미리 설치되어 있습니다.

Node.js, Python, Java 등 주요 런타임과 Git, Docker 같은 도구들이 포함되어 있습니다. 대부분의 경우 별도 설치 없이 바로 사용할 수 있습니다.

실전 팁

💡 - 특별한 이유가 없다면 ubuntu-latest를 사용하세요. 가장 빠르고 저렴합니다.

• 프로덕션 환경과 동일한 테스트가 필요하면 특정 버전을 명시하세요.
• macOS 러너는 비용이 높으니 iOS 빌드 등 필수적인 경우에만 사용하세요.

---

6. uses와 run 차이

steps를 작성하던 김개발 씨가 혼란에 빠졌습니다. 어떤 step은 uses로 시작하고, 어떤 step은 run으로 시작합니다.

"이 둘이 뭐가 다른 거예요? 둘 다 뭔가를 실행하는 것 같은데요."

uses는 미리 만들어진 액션을 가져다 쓰는 것이고, run은 쉘 명령어를 직접 실행하는 것입니다. uses는 마치 레고의 조립된 블록을 가져다 쓰는 것처럼 복잡한 작업을 한 줄로 처리할 수 있습니다.

run은 터미널에 직접 명령어를 입력하는 것과 같습니다. 두 가지를 상황에 맞게 조합하여 사용합니다.

다음 코드를 살펴봅시다.

steps:
  # uses: 미리 만들어진 액션 사용
  - name: 코드 체크아웃
    uses: actions/checkout@v4

  - name: Node.js 설치
    uses: actions/setup-node@v4
    with:
      node-version: '20'
      cache: 'npm'

  # run: 쉘 명령어 직접 실행
  - name: 의존성 설치
    run: npm ci

  - name: 테스트 실행
    run: npm test

  # 여러 줄 명령어
  - name: 빌드 및 배포 준비
    run: |
      npm run build
      echo "Build completed"
      ls -la dist/

김개발 씨가 steps 코드를 유심히 살펴봅니다. actions/checkout, actions/setup-node 같은 것들이 uses 다음에 오고, npm install, npm test 같은 명령어는 run 다음에 옵니다.

"왜 이렇게 구분하는 거죠?" 박시니어 씨가 비유를 들어 설명합니다. "uses는 이미 만들어진 요리를 배달시키는 거야.

run은 직접 요리하는 거고. 어떤 건 남이 만든 게 더 맛있고, 어떤 건 직접 해야 해." uses는 GitHub 마켓플레이스에 등록된 액션을 사용하는 키워드입니다.

액션은 재사용 가능하도록 패키징된 코드 묶음입니다. 복잡한 로직을 직접 구현할 필요 없이 이미 검증된 솔루션을 가져다 쓸 수 있습니다.

가장 대표적인 예가 actions/checkout입니다. 저장소의 코드를 러너로 가져오는 작업인데, 직접 구현하려면 Git 명령어를 여러 줄 작성해야 합니다.

하지만 이 액션을 사용하면 한 줄로 끝납니다. 인증 처리, 서브모듈 관리 등 복잡한 부분도 알아서 처리해줍니다.

actions/setup-node도 많이 쓰이는 액션입니다. Node.js를 설치하고 버전을 관리해줍니다.

with 키워드를 통해 옵션을 전달할 수 있습니다. node-version으로 버전을 지정하고, cache: 'npm'을 추가하면 의존성 캐싱까지 자동으로 처리됩니다.

액션 이름 뒤에 붙는 @v4는 버전을 의미합니다. 메이저 버전을 지정하면 해당 버전의 최신 마이너 업데이트를 자동으로 받습니다.

안정성이 중요하다면 @v4.1.0처럼 정확한 버전을 명시할 수도 있습니다. run은 쉘 명령어를 직접 실행합니다.

npm install, npm test 같은 명령어는 그냥 run으로 실행하면 됩니다. 마치 터미널에 직접 입력하는 것과 똑같습니다.

여러 줄의 명령어를 실행하고 싶다면 **파이프 기호(|)**를 사용합니다. run: | 다음에 들여쓰기하여 여러 명령어를 나열하면 순차적으로 실행됩니다.

빌드 후 결과물 확인 같은 연속 작업에 유용합니다. 언제 uses를 쓰고 언제 run을 쓸까요?

간단한 명령어 한두 줄은 run으로 충분합니다. 하지만 복잡한 설정이 필요하거나 자주 사용되는 패턴이라면 검증된 액션을 찾아보세요.

직접 구현하는 것보다 안정적이고 유지보수도 쉽습니다. 김개발 씨가 마켓플레이스를 둘러보며 감탄합니다.

"AWS 배포, Slack 알림, Docker 빌드... 없는 게 없네요!" 개발자 커뮤니티가 만든 수많은 액션들이 여러분의 CI/CD를 더 강력하게 만들어줄 것입니다.

실전 팁

💡 - 복잡한 작업은 마켓플레이스에서 검증된 액션을 찾아 사용하세요.

• 공식 액션(actions/*)은 GitHub이 관리하므로 신뢰할 수 있습니다.
• 여러 명령어는 run: |을 사용해 한 step에서 처리하세요.

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!