[리눅스 기초 #52] "git push"면 배포 끝: GitHub Actions로 나만의 CI/CD 구축하기

 

리눅스 기초 시리즈의 52번째 시간입니다! 지난 시간에는 서버의 모든 설정 파일을 Git으로 관리하며 GitOps의 기초를 다졌습니다. 이제 우리 서버의 모든 기록은 버전 관리 시스템 안에 안전하게 보관되어 있습니다. 그런데 코드를 수정하고 Git에 커밋한 뒤, 실제 서버에 반영하기 위해 또다시 SSH로 접속하고 명령어를 치고 계신가요?

진정한 자동화의 완성은 내가 코드를 "Push" 하는 순간, 서버가 알아서 최신 코드를 가져와 재시작하는 것입니다. 오늘은 현대 개발 환경의 필수 요소인 GitHub Actions를 활용해, 내 리눅스 서버에 자동으로 코드를 배포하는 CI/CD 파이프라인 구축 과정을 저의 경험담과 함께 정리해 보겠습니다.

---

1. 나의 경험담: "새벽의 배포 트라우마를 극복하다"

 

최근 제 사이트인 sunyjini.com에 새로운 기능을 추가하고 운영 서버에 배포하던 날이었습니다. 수동으로 FTP에 접속해 파일을 올리고, SSH 터미널에서 서비스를 재시작했는데 실수로 오타가 섞인 구버전 파일을 올려버렸습니다. 사이트는 뻗어버렸고, 새벽 2시에 원인을 찾느라 식은땀을 흘려야 했죠.

이후 저는 GitHub Actions를 도입했습니다. 이제는 로컬에서 충분히 테스트하고 git push만 하면, 깃허브의 로봇(Runner)이 제 서버에 대신 접속해 코드를 안전하게 내려받고 서비스를 갱신해 줍니다. 배포 중 에러가 나면 즉시 알림이 오고, 저는 그저 결과만 확인하면 됩니다. 수동 배포의 불안함이 사라지고 나니, 개발의 즐거움이 다시 살아나는 것을 느꼈습니다.

---

2. Before: "반복되는 수동 접속과 휴먼 에러"

자동 배포를 구축하기 전에는 코드를 한 줄 고칠 때마다 서버에 들어가서 git pull을 하고, Docker 컨테이너를 내렸다가 다시 올리는 소모적인 작업을 반복해야 했습니다. 이 과정에서 한두 단계를 빼먹으면 서버 환경이 꼬이는 사고가 잦았죠.

수동 배포의 고된 루틴:

Terminal

 

# 1. SSH 접속
ssh user@myserver.com

2. 프로젝트 폴더 이동
cd ~/my-project

3. 코드 업데이트
git pull origin main

4. 서비스 재시작
docker-compose up -d --build

"아... 이걸 매번 해야 한다니..."

(▲ Before: 사람이 직접 관리하기에는 너무나 번거롭고 실수가 발생하기 쉬운 환경이었습니다.)

---

3. Action: GitHub Actions로 배포 자동화 설계

 

이제 GitHub 저장소의 .github/workflows/deploy.yml 파일을 만들어 배포 시나리오를 작성해 보겠습니다. 서버의 SSH 정보는 Settings > Secrets에 안전하게 보관해야 합니다.

자동 배포 워크플로우 코드:

deploy.yml

 

name: Deploy to Linux Server

on:
push:
branches: [ main ] # 메인 브랜치에 푸시될 때 작동!

jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: SSH 접속 후 배포 명령어 실행
uses: appleboy/ssh-action@master
with:
host: ${{ secrets.HOST }}
username: ${{ secrets.USERNAME }}
key: ${{ secrets.SSH_KEY }}
script: |
cd ~/my-project
git pull origin main
docker-compose up -d --build
echo "✅ 배포가 성공적으로 완료되었습니다!"

(▲ Action: 이 파일 하나로 깃허브와 내 서버가 동기화되었습니다. 이제 서버 접속용 비밀번호 없이 41편에서 배운 SSH 키를 이용해 안전하게 배포가 진행됩니다.)

---

4. After: "Push and Forget" 생산성 혁명

CI/CD를 구축한 뒤 제 개발 환경은 '안전함'을 넘어 '쾌속' 모드로 진입했습니다. 이제 더 이상 배포를 위해 하던 일을 멈추고 터미널을 열 필요가 없습니다.

달라진 점들:

• 일관된 배포 프로세스: 언제 배포하든 정해진 스크립트대로만 작동하므로 의외의 변수가 사라졌습니다.
• 실시간 모니터링: GitHub 앱을 통해 폰으로도 배포 성공 여부를 즉시 확인합니다.
• 진정한 데브옵스의 실현: 개발(Dev)과 운영(Ops)의 경계가 무너지고 하나로 연결되는 경험을 하게 되었습니다.

---

5. 실험 요약 및 팁

용어	의미	비유
CI	지속적 통합 (빌드/테스트 자동화)	재료 손질 자동화
CD	지속적 배포 (운영 서버 자동 반영)	서빙 자동화
Workflow	GitHub Actions의 전체 실행 흐름	표준 작업 지시서
Secrets	민감한 정보를 보관하는 금고	비밀번호 보관소

---

6. 마치며: 최신 엔진으로 달릴 준비가 되었나요?

리눅스 기초 52단계를 거치며 우리는 이제 단순히 리눅스를 쓰는 것을 넘어, 전 세계에서 가장 진보된 방식으로 인프라를 운영하는 능력을 갖췄습니다. 엔진(커널)이 좋아졌으니 이제 그 위에서 돌아가는 우리의 워크플로우도 더 스마트해져야 합니다. 자동화는 귀찮음을 해결하는 수단이 아니라, 여러분의 창의적인 시간을 벌어주는 투자입니다.

오늘의 인사이트: "배포는 이벤트가 아니라 일상이 되어야 한다. 그리고 그 일상은 보이지 않을 만큼 자동화되어야 한다."

---

52번째 이야기를 마칩니다. 이제 여러분의 리눅스 월드는 완벽한 자율 주행 상태입니다. 다음 시간에는 리눅스 서버의 영원한 숙제, '클라우드 오브젝트 스토리지(S3)와 rclone을 연동하여 서버 데이터를 무제한으로 외부에 보관하는 오프사이트 백업'에 대해 다뤄보겠습니다.

이 글이 여러분의 배포 스트레스를 날려버리는 데 도움이 되었나요? 혹시 GitHub Actions 실행 중 SSH 연결 오류 때문에 고생하고 계신가요?

서버의 방화벽(UFW)에서 GitHub의 IP 대역만 안전하게 허용하는 방법을 다음 포스팅 부록으로 준비해 드릴까요?