GitHub Actions으로 개발 워크플로우를 혁신하다: 자동화 시작부터 고급 활용까지

GitHub Actions을 활용해 개발 워크플로우를 자동화하는 방법을 상세히 알아봅니다. 이슈 관리부터 CI/CD, 릴리즈 노트 생성까지, 효율적인 개발 환경을 구축해 보세요.

안녕하세요! 개발자님의 소중한 시간을 절약해 드리고 싶은 IT 블로그 SEO 전문 작성자입니다. 혹시 개발하시면서 반복적인 작업에 지쳐보신 적 있으신가요? 매번 똑같은 테스트를 돌리고, 수동으로 배포하고, 릴리즈 노트를 작성하느라 진이 빠지셨던 경험이요. 분명히 이런 작업은 컴퓨터가 더 잘할 수 있을 것 같은데 말이죠!

이런 고민을 하고 계신다면, 오늘 제가 소개해 드릴 GitHub Actions가 바로 그 해답이 될 수 있습니다. 깃허브 액션은 단순한 CI/CD 도구를 넘어, 개발 워크플로우 전반을 자동화할 수 있는 강력한 플랫폼이거든요. 이슈 관리부터 코드 리뷰, 테스트, 배포, 심지어 릴리즈 노트 생성까지, 개발의 모든 단계를 자동화하여 개발팀의 생산성을 극대화하는 비법을 함께 파헤쳐 볼까요?

📑 목차

• GitHub Actions, 왜 주목해야 할까요?
• 개발 워크플로우의 혁신: 수동에서 자동으로
• 통합된 개발 환경의 장점
• GitHub Actions, 기본적인 개념부터 알아볼까요?
• 워크플로우(Workflow)와 이벤트(Event)
• 작업(Job)과 단계(Step)
• 액션(Action)이란?
• 이슈 관리와 자동화의 만남: 개발팀의 첫걸음
• 자동 라벨링과 담당자 할당으로 효율 높이기
• 오래된 이슈 자동 종료 및 안내
• CI/CD 파이프라인 구축의 핵심: 코드를 더 빠르게, 안정적으로
• 자동화된 빌드 및 테스트: 코드 품질의 첫 방어선
• 자동 배포: 개발의 최종 목표를 향해
• 릴리즈 노트 자동 생성: 개발의 마무리, 효율적으로!
• 커밋 메시지 또는 풀 리퀘스트 기반 릴리즈 노트
• GitHub Actions, 더 깊이 활용하기: 고급 기능과 팁
• 매트릭스 빌드(Matrix Build)로 효율적인 테스트
• 워크플로우 재사용(Reusable Workflows)으로 관리 용이성 확보
• GitHub Actions, 개발팀의 필수 도구로 자리매김하다

GitHub Actions, 왜 주목해야 할까요?

개발팀의 효율성은 곧 프로젝트의 성공과 직결됩니다. 반복적이고 수동적인 작업에 시간을 낭비하면, 개발자는 정작 중요한 기능 개발이나 문제 해결에 집중하기 어렵죠. 여기에 GitHub Actions가 빛을 발하는 지점이 있습니다. 왜 개발자들이 깃허브 액션에 열광하는지 그 이유를 몇 가지 짚어볼게요.

개발 워크플로우의 혁신: 수동에서 자동으로

과거에는 CI/CD 파이프라인을 구축하려면 별도의 서버를 세우고 복잡한 설정 파일을 만져야 했습니다. 하지만 깃허브 액션은 깃허브 저장소에 `.github/workflows` 디렉토리만 만들면 바로 시작할 수 있어요. YAML 파일 몇 줄로 빌드, 테스트, 배포는 물론, 특정 이벤트에 반응하여 다양한 작업을 수행하도록 설정할 수 있거든요. 예를 들어, 새로운 풀 리퀘스트가 생성되면 자동으로 테스트를 실행하고, 머지되면 프로덕션 서버에 배포하는 식이죠. 이 모든 과정이 깃허브 환경 내에서 매끄럽게 이루어지니, 개발자는 코드에만 집중할 수 있게 됩니다.

통합된 개발 환경의 장점

깃허브는 개발자들에게 이미 너무나 익숙한 플랫폼이죠. 코드 저장소, 이슈 트래커, 프로젝트 보드, 코드 리뷰 기능까지, 개발에 필요한 모든 것이 한곳에 모여 있습니다. 여기에 깃허브 액션이 추가되면서, 별도의 도구를 오갈 필요 없이 개발 워크플로우 전체를 깃허브 내에서 관리할 수 있게 된 겁니다. 이런 통합된 환경은 컨텍스트 스위칭 비용을 줄여주고, 팀원 간의 협업 효율을 비약적으로 높여줍니다.

수동 워크플로우와 깃허브 액션을 활용한 자동화 워크플로우를 비교해 볼까요?

항목	수동 워크플로우	GitHub Actions 자동화 워크플로우
이슈 관리	새로운 이슈 발생 시 수동으로 라벨 부여, 담당자 할당	특정 키워드 포함 시 자동 라벨링, 담당자 할당 제안
코드 리뷰	별도 알림, 수동으로 코드 컨벤션 체크	풀 리퀘스트 생성 시 자동 코드 포맷팅, 린트 검사, 알림 발송
테스트	로컬 환경에서 수동으로 테스트 실행, 결과 확인	풀 리퀘스트 푸시 시 자동 유닛/통합 테스트 실행, 결과 리포팅
배포	스크립트 수동 실행, 서버 접속 후 배포	특정 브랜치 머지 시 자동 빌드 및 배포
릴리즈 노트	수동으로 변경 사항 취합, 문서 작성	머지된 풀 리퀘스트 기반 자동 릴리즈 노트 생성

어때요? 깃허브 액션이 개발팀의 일상에 얼마나 큰 변화를 가져올 수 있는지 확 와닿으시죠?

GitHub Actions, 기본적인 개념부터 알아볼까요?

본격적으로 깃허브 액션을 활용하기 전에, 몇 가지 핵심 용어를 정리하고 가면 훨씬 이해하기 쉬울 거예요.

워크플로우(Workflow)와 이벤트(Event)

워크플로우는 하나 이상의 작업을 수행하는 자동화된 프로세스를 의미합니다. 이 워크플로우는 특정 이벤트가 발생했을 때 트리거됩니다. 예를 들어, `push` 이벤트(코드를 푸시했을 때), `pull_request` 이벤트(풀 리퀘스트가 생성되거나 업데이트되었을 때), `issue_comment` 이벤트(이슈에 댓글이 달렸을 때) 등이 있죠. 이벤트를 기반으로 워크플로우를 실행함으로써, 개발자는 원하는 시점에 원하는 작업을 자동화할 수 있습니다.

# .github/workflows/my-first-workflow.yml
name: My First Workflow

on: [push] # push 이벤트가 발생했을 때 워크플로우 실행

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Run a one-line script
      run: echo Hello, GitHub Actions!

위 코드는 아주 기본적인 워크플로우 예시인데요. `push` 이벤트가 발생하면 `Hello, GitHub Actions!`라는 문구를 출력하는 간단한 스크립트를 실행합니다. 이렇게 `on` 키워드로 이벤트를 지정하는 것이 핵심이죠.

작업(Job)과 단계(Step)

하나의 워크플로우는 여러 개의 작업(Job)으로 구성될 수 있습니다. 각 작업은 독립적으로 실행되며, 특정 운영체제 환경(`runs-on`)에서 실행됩니다. 예를 들어, `build` 작업, `test` 작업, `deploy` 작업 등을 병렬로 또는 순차적으로 실행할 수 있죠.

각 작업은 다시 여러 개의 단계(Step)로 이루어집니다. 단계는 워크플로우의 최소 실행 단위로, 쉘 명령어를 실행하거나 액션(Action)을 호출하는 등의 작업을 수행합니다. 예를 들어, 코드를 체크아웃하는 단계, 종속성을 설치하는 단계, 테스트를 실행하는 단계 등이 있을 수 있습니다.

액션(Action)이란?

액션은 워크플로우에서 특정 작업을 수행하는 재사용 가능한 코드 조각입니다. 깃허브 마켓플레이스에는 수많은 오픈소스 액션들이 등록되어 있어, 이를 활용하면 복잡한 스크립트를 직접 작성하지 않고도 다양한 기능을 손쉽게 워크플로우에 추가할 수 있습니다. 예를 들어, `actions/checkout@v4` 액션은 저장소 코드를 워크플로우 환경으로 가져오는 역할을 하고, `actions/setup-node@v4` 액션은 Node.js 환경을 설정해 줍니다. 직접 커스텀 액션을 만들어 사용할 수도 있답니다.

이슈 관리와 자동화의 만남: 개발팀의 첫걸음

개발팀에서 이슈 관리는 프로젝트의 흐름을 결정하는 중요한 요소입니다. 깃허브 액션을 활용하면 이 과정도 훨씬 더 스마트하게 만들 수 있어요. 단순한 라벨링부터 이슈 템플릿 적용, 특정 상황에서 이슈 자동 종료까지 가능하거든요.

자동 라벨링과 담당자 할당으로 효율 높이기

새로운 이슈가 생겼을 때, 개발자가 직접 라벨을 붙이고 담당자를 지정하는 건 생각보다 번거로운 일입니다. 깃허브 액션을 이용하면 이를 자동화할 수 있어요. 예를 들어, 이슈 제목이나 내용에 특정 키워드(`bug`, `feature`, `documentation` 등)가 포함되어 있으면 자동으로 해당 라벨을 붙이고, 특정 팀원에게 담당자를 할당하는 워크플로우를 만들 수 있죠.

# .github/workflows/issue-triage.yml
name: Issue Triage

on:
  issues:
    types: [opened] # 이슈가 열렸을 때 트리거

jobs:
  label_and_assign:
    runs-on: ubuntu-latest
    steps:
    - name: Label new issues
      uses: actions/labeler@v4 # 라벨링 액션 사용
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        sync-labels: true # 라벨 동기화
        configuration-path: .github/labeler.yml # 라벨링 규칙 파일

    - name: Assign issue to team member
      if: contains(github.event.issue.title, 'bug') # 제목에 'bug'가 있으면
      run: |
        gh issue edit ${{ github.event.issue.number }} --add-assignee @your-team-member # 담당자 할당
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

위 코드에서 `.github/labeler.yml` 파일에는 이런 식으로 규칙을 정의할 수 있습니다.

# .github/labeler.yml
bug:
  - 'bug/*' # bug/로 시작하는 모든 파일
feature:
  - 'feature/*' # feature/로 시작하는 모든 파일
documentation:
  - 'docs/*'
  - 'README.md'

이렇게 설정하면 이슈가 열릴 때마다 자동으로 분류되고, 필요한 경우 특정 담당자에게 알림이 가니, 이슈 관리가 훨씬 체계적으로 이루어질 수 있겠죠?

오래된 이슈 자동 종료 및 안내

오랫동안 업데이트되지 않거나 해결되지 않은 이슈들은 프로젝트의 백로그를 지저분하게 만들 수 있습니다. 깃허브 액션을 활용하면 일정 기간 활동이 없는 이슈에 자동으로 경고 댓글을 달고, 일정 기간이 지나면 이슈를 종료하는 워크플로우를 만들 수 있습니다. 이는 팀이 중요한 이슈에 집중하고, 백로그를 깨끗하게 유지하는 데 큰 도움이 됩니다.

# .github/workflows/stale-issues.yml
name: Mark stale issues

on:
  schedule:
    - cron: '30 1 * * *' # 매일 새벽 1시 30분 실행

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@v9 # 오래된 이슈 처리 액션 사용
        with:
          days-before-stale: 60 # 60일 동안 활동 없으면 stale로 표시
          days-before-close: 7 # stale 표시 후 7일 동안 활동 없으면 닫기
          stale-issue-message: '이 이슈는 활동이 없어 곧 닫힐 예정입니다. 추가 논의가 필요하면 댓글을 남겨주세요.'
          close-issue-message: '이슈가 활동 부족으로 닫혔습니다.'
          stale-pr-message: '이 풀 리퀘스트는 활동이 없어 곧 닫힐 예정입니다.'
          close-pr-message: '풀 리퀘스트가 활동 부족으로 닫혔습니다.'
          repo-token: ${{ secrets.GITHUB_TOKEN }}

이 워크플로우는 `actions/stale` 액션을 사용하여 일정 주기로 오래된 이슈와 풀 리퀘스트를 관리합니다. 불필요한 노이즈를 줄이고, 개발팀이 현재 진행 중인 작업에 더 집중할 수 있도록 돕는 아주 유용한 기능이죠.

CI/CD 파이프라인 구축의 핵심: 코드를 더 빠르게, 안정적으로

깃허브 액션의 가장 강력한 활용 사례 중 하나는 바로 CI/CD(지속적 통합/지속적 배포) 파이프라인 구축입니다. 코드를 푸시할 때마다 자동으로 빌드하고, 테스트하고, 배포하는 과정을 통해 개발 사이클을 단축하고 소프트웨어 품질을 향상시킬 수 있습니다.

자동화된 빌드 및 테스트: 코드 품질의 첫 방어선

새로운 코드가 푸시되거나 풀 리퀘스트가 생성될 때마다 자동으로 빌드하고 테스트를 실행하는 것은 코드 품질을 유지하는 데 필수적입니다. 깃허브 액션은 다양한 언어와 프레임워크를 지원하며, 컨테이너 환경에서 테스트를 실행할 수 있어 일관된 환경을 보장합니다.

# .github/workflows/ci.yml
name: CI Workflow

on:
  push:
    branches: [ main, develop ] # main, develop 브랜치에 push될 때
  pull_request:
    branches: [ main, develop ] # main, develop 브랜치로 풀 리퀘스트가 생성될 때

jobs:
  build_and_test:
    runs-on: ubuntu-latest # 우분투 환경에서 실행
    steps:
    - uses: actions/checkout@v4 # 코드 체크아웃
    - name: Set up Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '18' # Node.js 18 버전 설정
    - name: Install dependencies
      run: npm ci # 의존성 설치
    - name: Run tests
      run: npm test # 테스트 실행
    - name: Build project
      run: npm run build # 프로젝트 빌드

이 워크플로우는 코드가 특정 브랜치에 푸시되거나 풀 리퀘스트가 생성될 때마다 자동으로 Node.js 환경을 설정하고, 의존성을 설치하고, 테스트를 실행한 후 프로젝트를 빌드합니다. 만약 테스트가 실패하면, 개발자는 즉시 문제를 파악하고 수정할 수 있어 버그가 프로덕션 환경으로 유입되는 것을 효과적으로 막을 수 있죠.

자동 배포: 개발의 최종 목표를 향해

테스트를 통과한 코드는 이제 사용자에게 전달될 준비를 마쳤습니다. 깃허브 액션을 이용하면 이 배포 과정도 완전 자동화할 수 있습니다. 예를 들어, `main` 브랜치에 머지될 때마다 자동으로 빌드된 애플리케이션을 클라우드 서버나 컨테이너 레지스트리에 배포하도록 설정할 수 있습니다.

# .github/workflows/cd.yml
name: CD Workflow

on:
  push:
    branches: [ main ] # main 브랜치에 push될 때 (테스트 통과 후 머지된 경우)

jobs:
  deploy_to_production:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Set up Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '18'
    - name: Install dependencies
      run: npm ci
    - name: Build project
      run: npm run build
    - name: Deploy to S3 # 예시: AWS S3에 배포
      uses: jakejarvis/s3-sync-action@master
      with:
        args: --acl public-read --follow-symlinks --delete
      env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'ap-northeast-2'

위 예시에서는 빌드된 결과물을 AWS S3 버킷에 동기화하여 배포하는 과정을 보여줍니다. 실제 배포 환경에 따라 AWS Elastic Beanstalk, Google Cloud Run, Kubernetes 등 다양한 플랫폼에 배포하는 액션을 활용할 수 있습니다. 환경 변수를 통해 민감한 정보(API 키, 비밀번호 등)를 안전하게 관리할 수 있다는 점도 큰 장점입니다.

릴리즈 노트 자동 생성: 개발의 마무리, 효율적으로!

새로운 버전을 릴리즈할 때마다 어떤 기능이 추가되었고, 어떤 버그가 수정되었는지 릴리즈 노트를 작성하는 것은 필수적이지만, 때로는 귀찮고 시간이 많이 드는 작업이 될 수 있습니다. 깃허브 액션을 활용하면 이 릴리즈 노트 생성 과정마저 자동화할 수 있답니다!

커밋 메시지 또는 풀 리퀘스트 기반 릴리즈 노트

깃허브 액션은 특정 브랜치에 머지된 풀 리퀘스트나 커밋 메시지를 분석하여 릴리즈 노트를 자동으로 생성할 수 있습니다. 예를 들어, Conventional Commits와 같은 커밋 컨벤션을 사용하면, `feat:`, `fix:`, `chore:` 등의 접두사를 기반으로 변경 사항을 분류하고 깔끔하게 정리된 릴리즈 노트를 만들 수 있습니다.

# .github/workflows/release-drafter.yml
name: Release Drafter

on:
  push:
    branches:
      - main # main 브랜치에 푸시될 때 (새로운 버전 릴리즈 시점)

jobs:
  update_release_draft:
    runs-on: ubuntu-latest
    steps:
      - uses: release-drafter/release-drafter@v5 # 릴리즈 드래프터 액션 사용
        with:
          config-name: release-drafter-config.yml # 설정 파일
          disable-pr-comment: true # 풀 리퀘스트 댓글 비활성화
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

이 워크플로우는 `release-drafter/release-drafter` 액션을 사용하여 자동으로 릴리즈 초안을 생성합니다. `.github/release-drafter-config.yml` 파일에는 릴리즈 노트에 포함될 내용을 어떤 방식으로 분류할지, 어떤 라벨을 기반으로 섹션을 나눌지 등을 정의할 수 있습니다.

# .github/release-drafter-config.yml
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'

categories:
  - title: '🚀 Features'
    labels: ['feature', 'feat']
  - title: '🐛 Bug Fixes'
    labels: ['bug', 'fix']
  - title: '📝 Documentation'
    labels: ['docs']
  - title: '📦 Chores'
    labels: ['chore']

change-template: '- {{emoji}} {{title}} (#{{number}})'
template: |
  ## What's Changed

  $CHANGES

  **Full Changelog**: https://github.com/$OWNER/$REPO/compare/$PREVIOUS_TAG...v$NEXT_PATCH_VERSION

이렇게 설정하면 풀 리퀘스트가 머지될 때마다 자동으로 다음 릴리즈 초안이 업데이트되고, 개발자는 최종적으로 검토하고 게시 버튼만 누르면 되는 거죠. 릴리즈 노트 작성에 드는 시간을 획기적으로 줄여줄 뿐만 아니라, 일관되고 상세한 릴리즈 노트를 제공할 수 있게 됩니다.

GitHub Actions, 더 깊이 활용하기: 고급 기능과 팁

지금까지 기본적인 워크플로우부터 CI/CD, 릴리즈 노트 자동화까지 살펴봤는데요. 깃허브 액션은 여기서 멈추지 않고, 더 다양한 방법으로 개발 워크플로우를 개선할 수 있는 강력한 기능들을 제공합니다.

매트릭스 빌드(Matrix Build)로 효율적인 테스트

여러 버전의 언어, 운영체제, 라이브러리 조합에서 코드를 테스트해야 할 때가 있죠. 예를 들어, Node.js 애플리케이션을 Node.js 16, 18, 20 버전에서 모두 테스트하고 싶을 수 있습니다. 이때 매트릭스 빌드 기능을 활용하면, 하나의 워크플로우 파일로 여러 조합에서 동시에 테스트를 실행할 수 있습니다.

# .github/workflows/matrix-test.yml
name: Matrix Test

on: [push]

jobs:
  test:
    runs-on: ${{ matrix.os }} # 매트릭스의 OS 사용
    strategy:
      matrix:
        node-version: [16, 18, 20] # 테스트할 Node.js 버전
        os: [ubuntu-latest, windows-latest] # 테스트할 OS
    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }} on ${{ matrix.os }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - name: Install dependencies
      run: npm ci
    - name: Run tests
      run: npm test

이 워크플로우는 Node.js 16/18/20 버전과 Ubuntu/Windows 최신 버전의 총 6가지 조합에서 동시에 테스트를 실행합니다. 이렇게 하면 다양한 환경에서 코드의 호환성을 빠르게 검증할 수 있어, 시간과 리소스를 절약하면서도 테스트 커버리지를 넓힐 수 있죠.

워크플로우 재사용(Reusable Workflows)으로 관리 용이성 확보

여러 저장소에서 비슷한 CI/CD 워크플로우를 사용해야 할 때가 있습니다. 예를 들어, 모든 마이크로서비스 저장소에 동일한 빌드 및 테스트 워크플로우를 적용하고 싶다면, 각 저장소마다 워크플로우 파일을 복사해서 붙여넣는 대신 재사용 가능한 워크플로우를 만들 수 있습니다. 이는 워크플로우의 중복을 줄이고, 일관성을 유지하며, 중앙에서 관리를 더 용이하게 만듭니다.

재사용 가능한 워크플로우는 별도의 저장소에 정의하거나, 현재 저장소의 특정 경로에 정의할 수 있으며, 다른 워크플로우에서 `uses` 키워드를 통해 호출할 수 있습니다.

# .github/workflows/main.yml (호출하는 워크플로우)
name: My App CI

on: [push]

jobs:
  call-ci:
    uses: octo-org/my-common-workflows/.github/workflows/ci-template.yml@main # 다른 저장소의 워크플로우 호출
    with:
      node-version: '18'

이렇게 하면 공통된 로직은 한 곳에서 관리하고, 필요한 부분만 각 프로젝트에 맞게 파라미터로 넘겨줄 수 있으니, 워크플로우 관리가 훨씬 깔끔해지겠죠?

GitHub Actions, 개발팀의 필수 도구로 자리매김하다

지금까지 GitHub Actions를 활용하여 개발 워크플로우를 어떻게 자동화하고 효율성을 극대화할 수 있는지 상세히 살펴보았습니다. 이슈 관리의 첫 단계부터, CI/CD 파이프라인을 통한 안정적인 코드 배포, 그리고 마지막 릴리즈 노트 생성까지, 깃허브 액션은 개발의 모든 순간에 함께할 수 있는 강력한 도구라는 것을 알 수 있습니다.

개발팀의 생산성을 높이고, 반복적인 수동 작업을 줄여 개발자들이 더 창의적이고 중요한 일에 집중할 수 있도록 돕는 것. 이것이 바로 깃허브 액션이 제공하는 핵심 가치입니다. 아직 깃허브 액션을 사용해보지 않으셨다면, 작은 워크플로우부터 시작하여 점진적으로 자동화 범위를 넓혀보는 것을 강력히 추천합니다. 분명 개발 경험이 한층 더 즐거워지고, 팀의 효율성도 크게 향상될 거예요!

혹시 깃허브 액션을 활용하면서 겪었던 재미있는 경험이나 유용한 팁이 있다면 댓글로 공유해 주세요. 다른 개발자들에게도 큰 도움이 될 겁니다. 다음에도 더 유익한 정보로 찾아뵙겠습니다. 감사합니다!

📌 함께 읽으면 좋은 글

• [생산성 자동화] Pre-commit 훅과 Git 자동화: 개발 생산성을 높이는 코드 품질 관리 전략
• [생산성 자동화] API 문서화 자동화: 코드에서 시작하는 효율적인 개발 워크플로우
• [커리어 취업] 개발자 연봉 협상 성공 전략: 시장 분석부터 제안 수락까지 실전 가이드

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.