GitHub Actions 사용법｜1인 사업자 웹사이트 자동 배포·예약 작업

혼자 사업을 운영하면 상품과 고객 관리뿐 아니라 웹사이트 수정, 파일 업로드, 링크 점검, 백업 같은 일도 직접 처리해야 합니다. 작업 하나는 짧아도 매주 반복되면 적지 않은 시간이 들어갑니다.

GitHub Actions는 GitHub 저장소의 파일이 바뀌거나 정해진 시간이 되면 미리 작성한 작업을 자동으로 실행하는 기능입니다. 웹사이트 파일을 검사하고 배포하거나, 매주 링크 상태를 점검하고, 결과 보고서를 보관하는 식으로 활용할 수 있습니다.

처음부터 모든 것을 자동화할 필요는 없습니다. 1인 사업자라면 자주 반복하면서 실패해도 즉시 사업에 큰 피해가 없는 작업 하나부터 시작하는 것이 안전합니다. 이 글에서는 개발 경험이 많지 않은 운영자를 기준으로 GitHub Actions의 구조와 시작 방법, 적용 가능한 사이트, 보안 주의사항을 정리합니다.

 

먼저 결론

• GitHub Actions는 웹사이트의 검사·빌드·배포·예약 작업을 자동화할 수 있습니다.
• GitHub Pages나 정적 웹사이트는 적용하기 비교적 쉽고, WordPress·티스토리·Blogger는 플랫폼과 연결 방식에 따라 범위가 달라집니다.
• 비밀번호·API 키·서버 접속키는 YAML 파일에 직접 입력하지 않고 GitHub Secrets에 저장해야 합니다.
• 처음에는 자동 게시보다 링크 검사나 테스트처럼 결과를 확인하기 쉬운 작업부터 시작하는 편이 안전합니다.
• ubuntu-latest처럼 실행환경이 바뀔 수 있는 설정은 정기적으로 점검해야 합니다.

정보 기준일: 2026년 9월 18일. GitHub Actions의 지원 기능, 러너 이미지, 요금과 사용 한도는 계정·저장소·GitHub 정책에 따라 변경될 수 있으므로 실제 적용 전 공식 문서를 다시 확인하십시오.

목차

• GitHub Actions란 무엇인가
• 1인 사업자가 활용하기 좋은 작업
• 내 블로그·웹사이트에도 적용할 수 있을까
• Workflow·Event·Job·Step 쉽게 이해하기
• 첫 번째 GitHub Actions 만들기
• 예약 작업 설정하기
• 웹사이트 자동 배포는 어떻게 작동할까
• 비밀번호와 API 키 안전하게 관리하기
• 작업 실패와 오류 로그 확인하기
• ubuntu-latest와 실행환경 변경 주의사항
• 무료 사용과 비용 확인
• 1인 사업자 도입 체크리스트
• 자주 묻는 질문

GitHub Actions란 무엇인가

GitHub Actions는 GitHub 저장소에서 발생하는 이벤트를 조건으로 자동 작업을 실행하는 기능입니다. 예를 들어 웹사이트 파일을 수정해 GitHub에 반영하면 자동으로 오류를 검사한 뒤 사이트에 배포할 수 있습니다.

단순하게 표현하면 다음 구조입니다.

파일 수정 → 자동 검사 → 사이트 배포 → 성공·실패 기록

GitHub Actions 자체가 웹사이트 제작 도구나 블로그 서비스는 아닙니다. GitHub에 저장된 파일과 외부 서비스 사이에서 미리 정한 명령을 실행하는 자동화 도구에 가깝습니다.

1인 사업자가 활용하기 좋은 작업

혼자 운영하는 사업에서는 복잡한 개발 자동화보다 반복 작업을 줄이고 실수를 예방하는 용도로 접근하는 것이 좋습니다.

자동화 작업	활용 예시	초보자 추천도
사이트 파일 검사	HTML·CSS·설정 파일의 기본 오류 확인	매우 높음
깨진 링크 검사	내부 링크와 외부 링크 오류 정기 확인	매우 높음
정적 사이트 배포	GitHub Pages·정적 호스팅에 변경 파일 반영	높음
예약 점검	매주 사이트 상태·파일·링크 검사	높음
결과 파일 보관	검사 보고서·빌드 파일을 Artifact로 저장	높음
이미지 최적화	용량 검사·압축·형식 변환	보통
서버 자동 배포	VPS·클라우드 서버에 새 버전 반영	낮음

초보자는 자동 발행이나 운영 서버 배포보다 사이트 검사 → 예약 실행 → 결과 확인 순서로 익히는 편이 좋습니다. 결과가 잘못돼도 실제 사이트가 즉시 바뀌지 않기 때문에 위험을 줄일 수 있습니다.

문서 작성·자료 분석처럼 코드 밖의 반복 업무도 함께 줄이고 싶다면 다음 실전 활용법을 확인할 수 있습니다.

자영업자 ChatGPT 업무 활용법 보기

내 블로그·웹사이트에도 적용할 수 있을까

GitHub Actions의 활용 범위는 사이트 파일이 GitHub에 저장돼 있는지, 해당 서비스가 자동 배포나 API 연결을 지원하는지에 따라 달라집니다.

사이트 유형	적합도	가능한 활용
GitHub Pages	매우 높음	검사·빌드·배포
정적 HTML 웹사이트	매우 높음	파일 검사·이미지 최적화·배포
Jekyll·Hugo·Astro 등	매우 높음	콘텐츠 빌드·테스트·배포
Vercel·Netlify 연결 사이트	높음	배포 전 검사·별도 자동화
WordPress	조건부	테마·플러그인 배포, 외부 백업
티스토리·Blogger	제한적	외부 링크·사이트 상태 검사 등
VPS·클라우드 서버	높음	SSH 배포·서버 작업·백업

주의: GitHub Actions를 연결한다고 티스토리·Blogger·WordPress 글이 자동으로 안전하게 발행되는 것은 아닙니다. 플랫폼 API, 인증 방식, 서비스 약관과 자동 게시 제한을 먼저 확인해야 합니다. 검색 노출을 위한 유사 글 대량 발행은 자동화 대상으로 삼지 않는 것이 좋습니다.

 

Workflow·Event·Job·Step 쉽게 이해하기

처음에는 영어 용어가 많아 보이지만 사이트 운영 과정에 대입하면 어렵지 않습니다.

용어	쉬운 의미	웹사이트 운영 예시
Repository	파일 저장 공간	사이트 파일·설정 보관
Workflow	전체 자동 작업표	검사 후 사이트 배포
Event	작업을 시작하는 조건	파일 변경·예약 시각·수동 실행
Job	큰 작업 묶음	검사 작업·배포 작업
Step	순서대로 실행하는 단계	파일 가져오기·검사 명령 실행
Runner	명령을 실행하는 컴퓨터	GitHub가 제공하는 Ubuntu 실행환경
Secret	비밀정보 보관함	배포 토큰·API 키·접속정보

첫 번째 GitHub Actions 만들기

GitHub Actions 워크플로 파일은 저장소의 .github/workflows 폴더 안에 YAML 형식으로 저장합니다. 처음에는 사이트를 변경하지 않고 메시지만 출력하는 안전한 예제로 시작합니다.

1단계: 워크플로 파일 만들기

저장소에 다음 경로로 파일을 만듭니다.

.github/workflows/first-check.yml

2단계: 최소 YAML 입력하기

name: First website check

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  check:
    runs-on: ubuntu-latest

    steps:
      - name: 저장소 파일 가져오기
        uses: actions/checkout@v4

      - name: 기본 확인
        run: |
          echo "GitHub Actions가 정상 실행됐습니다."
          pwd
          ls -la

3단계: 실행 결과 확인하기

1. 작성한 파일을 저장하고 main 브랜치에 반영합니다.
2. GitHub 저장소 상단의 Actions 메뉴를 엽니다.
3. First website check 워크플로를 선택합니다.
4. 실행된 작업을 열어 각 Step의 성공·실패 여부를 확인합니다.
5. 초록색 체크가 표시되면 기본 워크플로가 정상 실행된 것입니다.

위 예제는 웹사이트를 실제로 배포하지 않습니다. 자동화 파일의 위치와 실행 결과 확인법을 익히기 위한 첫 단계입니다.

예약 작업 설정하기

GitHub Actions는 schedule 이벤트를 이용해 정해진 주기로 작업을 실행할 수 있습니다. 사이트 링크 검사나 정기 보고서 생성처럼 정확한 분 단위 실행보다 주기적인 점검이 중요한 작업에 적합합니다.

name: Weekly website check

on:
  schedule:
    - cron: '0 0 * * 1'
  workflow_dispatch:

jobs:
  check:
    runs-on: ubuntu-latest

    steps:
      - name: 저장소 파일 가져오기
        uses: actions/checkout@v4

      - name: 점검 시작 기록
        run: |
          echo "웹사이트 주간 점검을 시작합니다."
          date

위 cron 표현식은 매주 월요일 00:00 UTC를 의미합니다. 한국 표준시는 UTC보다 9시간 빠르므로 한국시간으로는 월요일 오전 9시에 해당합니다.

• schedule은 기본 브랜치에 있는 워크플로를 기준으로 실행됩니다.
• 예약 작업은 시스템 상황에 따라 지연될 수 있습니다.
• 정확한 시각이 중요한 고객 알림이나 결제 작업을 단순 cron에만 의존하면 안 됩니다.
• workflow_dispatch를 함께 넣으면 Actions 화면에서 수동으로 시험할 수 있습니다.

웹사이트 자동 배포는 어떻게 작동할까

자동 배포는 파일이 바뀌자마자 무조건 운영 사이트에 복사하는 작업만을 의미하지 않습니다. 안전한 자동 배포는 검사와 승인 단계를 포함해야 합니다.

1. 사이트 파일을 GitHub 저장소에 반영합니다.
2. GitHub Actions가 변경을 감지합니다.
3. 필요한 프로그램과 패키지를 준비합니다.
4. 링크·코드·빌드 오류를 검사합니다.
5. 검사를 통과한 결과물만 배포합니다.
6. 성공 또는 실패 기록을 남깁니다.

GitHub Pages는 GitHub Actions 기반의 사용자 지정 워크플로로 사이트를 빌드하고 배포할 수 있습니다. 그러나 WordPress, VPS, 외부 호스팅은 FTP·SFTP·SSH·API 등 각 서비스에 맞는 연결 설정이 필요합니다.

운영 사이트 보호: 자동 배포를 처음 연결할 때는 테스트 저장소나 별도 스테이징 사이트에서 먼저 확인하십시오. 배포 명령이 정상이라는 이유만으로 실제 화면·링크·결제·문의 기능까지 정상이라고 단정할 수는 없습니다.

비밀번호와 API 키 안전하게 관리하기

외부 서버나 서비스를 연결하려면 토큰·API 키·접속정보가 필요할 수 있습니다. 이 값을 YAML이나 공개 저장소 파일에 직접 적으면 외부에 노출될 위험이 있습니다.

Secrets 등록 경로

1. GitHub 저장소의 Settings를 엽니다.
2. Secrets and variables를 선택합니다.
3. Actions로 이동합니다.
4. New repository secret을 선택합니다.
5. 이름과 비밀값을 입력해 저장합니다.

워크플로에서는 실제 값을 쓰지 않고 등록한 이름으로 불러옵니다.

env:
  DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

• Secret 값을 echo 명령으로 출력하지 않습니다.
• 필요한 권한만 가진 별도 토큰을 사용합니다.
• 관리자 전체 권한이 있는 장기 토큰 사용을 피합니다.
• 사용하지 않는 키는 삭제하고 필요한 경우 정기적으로 교체합니다.
• 고객 개인정보와 결제정보를 저장소나 Artifact에 포함하지 않습니다.

작업 실패와 오류 로그 확인하기

GitHub Actions가 실패하면 무작정 YAML을 전부 바꾸기보다 실패한 Step과 첫 오류 메시지를 먼저 확인합니다.

증상	확인할 항목	우선 조치
워크플로가 나타나지 않음	파일 경로·확장자·YAML 문법	.github/workflows 경로 확인
실행 조건이 작동하지 않음	브랜치명·이벤트 조건	main·master 등 실제 브랜치 확인
command not found	필요 도구 설치 여부	설치 Step 추가
권한 오류	토큰·Secret·저장소 권한	최소권한으로 다시 설정
배포는 성공했지만 사이트가 이상함	빌드 경로·캐시·배포 결과물	이전 버전으로 롤백 후 비교

운영 사이트 자동 배포 전에는 이전 정상 버전으로 돌아갈 방법을 먼저 준비해야 합니다. 자동화는 작업 시간을 줄이기 위한 도구이지, 확인과 복구 절차를 없애는 기능이 아닙니다.

ubuntu-latest와 실행환경 변경 주의사항

예제에 사용한 ubuntu-latest는 하나의 Ubuntu 버전에 영구 고정된 이름이 아닙니다. GitHub가 기본 이미지의 대상을 바꾸면 YAML을 수정하지 않아도 운영체제와 사전 설치 도구가 달라질 수 있습니다.

GitHub는 Ubuntu 26.04 러너를 정식 지원하고, ubuntu-latest를 2026년 10월 19일부터 11월 19일까지 Ubuntu 24.04에서 26.04로 순차 전환한다고 발표했습니다.

• 중요한 배포 작업은 검증한 운영체제 버전을 명시합니다.
• Node.js·Python·Java 같은 런타임도 별도로 버전을 지정합니다.
• 자동 전환 전 새 러너에서 검사 작업을 먼저 실행합니다.
• 실패하면 기존 운영체제로 되돌릴 수 있게 준비합니다.

Ubuntu 26.04의 사전 설치 도구 차이와 실제 고정·병렬 테스트 YAML은 ITNAI 전문 글 발행 후 별도 가이드로 연결하는 것이 적합합니다. 확인되지 않은 예상 URL은 현재 본문에 넣지 않았습니다.

무료 사용과 비용 확인

GitHub Actions 비용은 저장소 공개 여부, 계정 요금제, 러너 운영체제, 저장공간과 사용 시간에 따라 달라질 수 있습니다. 공개 저장소에서 표준 GitHub 호스팅 러너를 사용하는 경우와 비공개 저장소에서 사용하는 경우의 조건도 다릅니다.

따라서 “GitHub Actions는 무조건 무료”라고 이해하면 안 됩니다. 비공개 저장소는 요금제에 포함된 사용량을 넘거나 별도 러너·저장공간을 사용하면 비용이 발생할 수 있으므로 GitHub의 Billing 화면에서 실제 사용량과 지출 한도를 확인해야 합니다.

• 필요 이상으로 자주 실행되는 예약 작업이 없는지 확인합니다.
• 불필요한 브랜치에서도 워크플로가 실행되지 않도록 제한합니다.
• Artifact 보관 기간과 용량을 관리합니다.
• 실패를 반복하는 작업은 원인을 해결한 뒤 다시 활성화합니다.
• 비공개 저장소는 포함 사용량과 현재 소비량을 확인합니다.

1인 사업자 도입 체크리스트

• 매주 반복하는 사이트 운영 작업을 한 가지 선택했는가?
• 내 사이트가 GitHub 저장소와 연결될 수 있는 구조인가?
• 자동화 실패 시 실제 사업에 미치는 영향을 확인했는가?
• 처음에는 사이트를 변경하지 않는 검사 작업으로 시험했는가?
• API 키·비밀번호를 Secrets에 저장했는가?
• 토큰에 필요한 최소 권한만 부여했는가?
• 배포 전 테스트 또는 승인 단계를 두었는가?
• 이전 정상 버전으로 돌아가는 방법을 준비했는가?
• Actions 실행 기록과 비용을 정기적으로 확인하는가?
• 자동 게시 결과를 사람이 최종 검토하는가?

파일 작업과 외부 도구 실행을 AI 에이전트까지 연결하려면 실행환경·권한·비용 구조를 먼저 구분해야 합니다.

Agents API 실행환경과 자동화 구조 보기

 

자주 묻는 질문

코딩을 몰라도 GitHub Actions를 사용할 수 있나요?

기본 예제를 복사해 실행하는 것은 가능하지만 YAML 구조, 저장소 파일, 실행 로그를 확인할 수 있어야 합니다. 실제 서버 배포나 외부 API 연결은 잘못 설정했을 때 사이트 장애나 정보 노출로 이어질 수 있으므로 작은 검사 작업부터 익히는 편이 좋습니다.

티스토리와 Blogger 글도 자동 발행할 수 있나요?

GitHub Actions만으로 모든 블로그 서비스에 글을 발행할 수 있는 것은 아닙니다. 해당 플랫폼이 제공하는 API와 인증 방식, 계정 권한 및 서비스 약관을 확인해야 합니다. 자동 발행이 가능하더라도 유사 콘텐츠 대량 게시나 검수 없는 게시 방식은 권장하지 않습니다.

WordPress 전체를 GitHub에 백업해도 되나요?

WordPress는 테마·플러그인 파일과 데이터베이스·업로드 파일을 구분해야 합니다. 데이터베이스에는 고객정보나 주문정보가 포함될 수 있으므로 공개 저장소에 저장하면 안 됩니다. 호스팅 백업 기능과 암호화된 별도 저장소를 우선 검토하십시오.

GitHub Actions로 예약 글을 정확한 시간에 발행할 수 있나요?

예약 워크플로는 시스템 상황에 따라 지연될 수 있습니다. 정확한 발행 시각이 중요하다면 블로그·CMS 자체 예약 기능을 우선 사용하고, GitHub Actions의 schedule은 정기 검사나 유지관리 작업에 사용하는 편이 안전합니다.

작업에 실패하면 웹사이트도 바로 중단되나요?

검사 작업만 실행한다면 기존 사이트는 그대로 유지됩니다. 그러나 실패한 배포 과정에서 운영 파일을 변경하도록 설정했다면 영향을 받을 수 있습니다. 검사와 배포를 분리하고 검사를 통과한 결과만 배포하도록 구성해야 합니다.

Secret에 저장하면 API 키가 완전히 안전한가요?

YAML에 직접 입력하는 것보다 안전하지만 모든 위험이 사라지는 것은 아닙니다. 워크플로가 Secret을 외부로 전송하거나 로그에 출력하지 않는지 확인하고, 토큰에는 최소 권한만 부여해야 합니다.

가장 먼저 자동화할 작업은 무엇인가요?

사이트를 직접 변경하지 않는 주간 링크 검사나 파일 오류 검사부터 시작하는 것이 좋습니다. 실행 결과와 오류 로그 확인에 익숙해진 다음 테스트 사이트 배포, 운영 사이트 배포 순서로 확대하십시오.

정리

GitHub Actions는 개발자만을 위한 기능이 아닙니다. 웹사이트를 직접 관리하는 1인 사업자도 파일 검사, 깨진 링크 점검, 정적 사이트 배포, 예약 작업과 결과 보고서 보관에 활용할 수 있습니다.

다만 모든 일을 한 번에 자동화하면 오류 원인을 찾기 어렵고 운영 사이트에 예상하지 못한 문제가 생길 수 있습니다. 먼저 메시지를 출력하는 기본 워크플로를 실행하고, 사이트를 변경하지 않는 검사 작업을 추가한 뒤, 테스트 배포와 운영 배포 순서로 확대하는 것이 안전합니다.

자동화의 목적은 사람의 검토를 없애는 것이 아니라 반복 작업을 줄이고 중요한 확인에 더 많은 시간을 쓰는 것입니다. 비밀정보는 Secrets로 관리하고, 실행환경과 비용, 실패 로그와 복구 방법까지 함께 관리해야 지속 가능한 운영 자동화가 됩니다.

공식 출처

• GitHub Docs｜Quickstart for GitHub Actions
• GitHub Docs｜Understanding GitHub Actions
• GitHub Docs｜Workflow syntax for GitHub Actions
• GitHub Docs｜Events that trigger workflows
• GitHub Docs｜Using secrets in GitHub Actions
• GitHub Docs｜Deploying with GitHub Actions
• GitHub Docs｜GitHub Actions billing
• GitHub Changelog｜Ubuntu 26 generally available and latest migration

함께 보면 좋은 글

• ChatGPT로 업무 시간 줄이는 법｜직장인·자영업자 실전 활용 7가지
• OpenAI Agents API 사용법｜Codex 하네스·장기 실행·MCP·서브에이전트
• Google Workspace Gemini MCP 연동｜Asana·Salesforce·HubSpot 연결법