GitHub Actions로 개발 효율화하기

GitHub Actions를 처음에는 PR Lint test 용도로 도입했지만, Runner 구축과 중복 실행, 불필요한 트리거 같은 개선점이 보이면서 더 넓은 자동화로 확장했다. 약 6개월 동안 적용해보며 개발 효율을 높인 워크플로우와 액션 활용 사례를 정리한다.

GitHub Actions는 GitHub 안에서 CI/CD를 끝낼 수 있는 플랫폼이다. 리포지토리에 이벤트가 발생하면 Runner에서 workflow가 실행되며, 실행 환경은 GitHub-hosted Runner와 Self-hosted Runner로 나뉜다. 사내 리포지토리처럼 코드 노출이 민감한 환경에서는 보안상 Self-hosted Runner가 필요하지만, 외부 노출이 문제되지 않으면 GitHub-hosted Runner를 간편하게 쓸 수 있다.

workflow 작성의 핵심은 name, on, jobs, steps다. on으로 push, pull_request, schedule, workflow_dispatch 같은 트리거를 세밀하게 제어할 수 있고, 브랜치 필터와 이벤트 타입까지 지정할 수 있다. 예를 들어 PR이 opened, reopened, synchronize, ready_for_review일 때만 실행하거나, cron으로 매주 특정 시각에 작업을 돌리거나, 버튼으로 수동 실행하는 식이다.

GitHub Contexts를 활용하면 workflow를 훨씬 유연하게 만들 수 있다. github.event.number로 PR 번호를 가져오고, secrets.GITHUB_TOKEN으로 GitHub API 권한을 받아오며, github.event.sender.login과 github.ref_name을 환경 변수로 재사용해 조건부 로직과 분기 처리를 단순화한다. secrets.GITHUB_TOKEN은 사용자가 직접 관리하는 PAT와 달리 workflow 실행 시 자동 생성되고 종료 후 제거되며, 실행 리포지토리 범위로 권한이 제한된다는 점이 장점이다.

실제 사례로는 auto-approve-action을 써서 develop <- main 자동 생성 PR을 봇이 승인하도록 했다. git flow 구조상 main이 머지되면 develop 현행화 PR이 자동 생성되는데, 2명의 리뷰 승인이 강제되어 불편했기 때문에 이 과정을 자동화했다.

GitHub Actions Marketplace는 필요한 기능을 직접 구현하지 않고도 바로 가져다 쓸 수 있는 강점이 있다. 예시로는 wait-for-green으로 status check 완료를 확인하고, create-or-update-comment로 "머지 준비 완료" 코멘트를 남겨 PR 흐름을 자동화했다. 복잡한 GitHub API 스크립트를 직접 짜지 않아도 되어 구현 비용이 크게 줄어든다.

다만 GitHub Enterprise 환경에서는 보안상 공식 액션 외의 외부 액션을 바로 쓰기 어려울 수 있다. 이 경우 액션을 별도로 클론해 내부에서 관리해야 하며, 중복 복제를 막기 위해 중앙 그룹에서 통합 관리하는 방식이 필요하다. 외부 액션을 도입할 때는 octokit 같은 GitHub API 라이브러리만 쓰는지, 불필요한 패키지가 섞이지는 않았는지도 함께 검토해야 한다.

결국 GitHub Actions는 단순한 CI 도구가 아니라, PR 승인, 알림, 브랜치 동기화, 이슈 정리, 주간보고 생성, PR 라벨링 같은 반복 업무까지 자동화하는 기반이 된다. Runner만 준비되어 있다면 진입장벽이 낮고, Marketplace와 Context를 함께 쓰면 저장소 운영의 많은 부분을 몇 개의 workflow로 정리할 수 있다.