돌미나리

매번 코드를 수정할 때마다 서버에 접속해서 git pull을 받고, 빌드를 다시 하고, 프로세스를 재시작하는 과정은 번거롭고 실수하기 쉽습니다. 이러한 반복 작업을 자동화하여 개발자가 오직 '코드'에만 집중할 수 있게 해주는 기술이 바로 CI/CD입니다.

오늘은 별도의 서버 설치 없이 GitHub에서 제공하는 강력한 자동화 도구인 GitHub Actions를 사용하여, 코드를 푸시하면 내 EC2 서버에 즉시 배포되는 환경을 만들어보겠습니다.

1. CI/CD란 무엇인가?

• CI (Continuous Integration): 지속적 통합. 개발자들이 작업한 코드를 자주 병합하고, 그때마다 자동으로 테스트와 빌드를 수행하여 코드의 품질을 검증하는 과정입니다.
• CD (Continuous Deployment): 지속적 배포. 검증된 코드를 실제 운영 서버에 자동으로 반영하는 과정입니다.

2. GitHub Actions의 핵심: Workflow 파일

GitHub Actions는 프로젝트 루트의 .github/workflows/ 디렉토리에 있는 YAML 파일을 통해 동작합니다.

2.1 배포 시나리오 (Workflow)

1. 개발자가 main 브랜치에 코드를 Push합니다.
2. GitHub Actions가 가상 환경을 실행하여 코드를 **빌드(Build)**합니다.
3. 빌드가 성공하면 SSH를 통해 내 EC2 서버에 접속합니다.
4. 서버에서 최신 코드를 받고 서비스를 재시작합니다.

3. 실전! 자동 배포 스크립트 작성하기

먼저 GitHub 저장소의 Settings > Secrets and variables > Actions에서 서버 접속 정보(IP, Username, SSH Key)를 등록해야 안전합니다.

3.1 deploy.yml 예시

name: Deploy to EC2

on:
  push:
    branches: [ main ] # main 브랜치에 푸시될 때 실행

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: 저장소 코드 가져오기
        uses: actions/checkout@v3

      - name: SSH 접속 후 배포 명령 실행
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USERNAME }}
          key: ${{ secrets.EC2_SSH_KEY }}
          script: |
            cd /home/ubuntu/my-project
            git pull origin main
            npm install
            pm2 restart all # Node.js 서비스 재시작 예시

4. CI/CD 도입 시 얻게 되는 효과

• 빠른 피드백: 코드를 올리자마자 빌드 오류나 테스트 실패 여부를 알 수 있습니다.
• 배포 실수 방지: 수동으로 명령어를 입력하다 발생할 수 있는 오타나 누락을 원천 차단합니다.
• 생산성 향상: 배포에 소요되는 시간을 줄여 핵심 로직 개발에 더 많은 시간을 투자할 수 있습니다.
• 안정적인 릴리즈: 정해진 절차에 따라 기계적으로 배포되므로 서비스의 안정성이 높아집니다.

5. 실무 꿀팁: Slack/Discord 알림 연동

배포가 성공했는지 실패했는지 매번 GitHub 사이트에서 확인할 수는 없습니다. GitHub Actions에 알림 스텝을 추가하면 배포 결과를 실시간으로 메신저로 받아볼 수 있습니다.

6. 결론: 자동화는 선택이 아닌 필수입니다

스무 차례에 걸쳐 리눅스 서버 기초부터 보안, 모니터링, 그리고 자동 배포까지 달려왔습니다. CI/CD 구축은 이 모든 여정의 마침표이자, 진정한 엔지니어로 거듭나는 시작점입니다.

서버를 운영하다 보면 매일 특정 시간에 데이터베이스를 백업하거나, 매주 월요일마다 임시 파일을 정리해야 하는 상황이 생깁니다. 이런 반복적인 작업을 사람이 일일이 수동으로 하는 것은 비효율적일 뿐만 아니라 실수할 위험도 큽니다.

리눅스 시스템에는 이러한 작업을 예약하고 자동으로 실행해 주는 **크론(Cron)**이라는 강력한 도구가 있습니다. 오늘은 크론의 설정 파일인 **크론탭(Crontab)**의 문법부터 실전 활용 사례까지 상세히 알아보겠습니다.

1. 크론탭(Crontab)이란 무엇인가?

**크론(Cron)**은 리눅스용 시간 기반 잡 스케줄러입니다. 그리고 **크론탭(Crontab)**은 크론 작업(Cron Job)을 설정하는 테이블(Table) 형태의 파일을 말합니다.

사용자가 크론탭에 특정 시간과 실행할 명령어를 등록해 두면, 시스템은 백그라운드에서 대기하다가 정해진 시간에 맞춰 해당 명령을 자동으로 수행합니다.

2. 크론탭 기본 명령어

터미널에서 크론탭을 관리하기 위한 기본 명령어 3가지는 다음과 같습니다.

• crontab -e: 크론탭 설정을 편집합니다. (가장 많이 사용)
• crontab -l: 현재 예약된 크론 작업 목록을 출력합니다.
• crontab -r: 예약된 모든 크론 작업을 삭제합니다. (주의해서 사용)

3. 크론탭 주기 설정 문법 (별 5개의 의미)

크론탭 설정은 한 줄에 5개의 시간 단위와 실행할 명령어를 공백으로 구분하여 작성합니다.

* * * * * [실행할 명령어]
┬  ┬  ┬  ┬  ┬
│  │  │  │  └─ 요일 (0-6, 0:일요일)
│  │  │  └─ 월 (1-12)
│  │  └─ 일 (1-31)
│  └─ 시 (0-23)
└─ 분 (0-59)

3.1 실전 설정 예시

• 매분 실행: * * * * * /path/to/script.sh
• 매일 새벽 3시에 실행: 0 3 * * * /path/to/backup.sh
• 매주 월요일 오전 9시에 실행: 0 9 * * 1 /path/to/report.sh
• 10분마다 실행: */10 * * * * /path/to/check.sh
• 평일(월~금) 오후 6시에 실행: 0 18 * * 1-5 /path/to/work.sh

4. 크론탭 작성 시 주의사항 (트러블슈팅)

초보자들이 크론탭을 설정하고 가장 당황하는 순간은 "명령어가 제대로 실행되지 않을 때"입니다. 이를 방지하기 위한 팁입니다.

4.1 절대 경로 사용

크론은 일반적인 터미널 환경과 환경 변수(PATH)가 다릅니다. 따라서 python이나 node 같은 명령어를 쓸 때도 반드시 절대 경로를 사용해야 합니다.

• 잘못된 예: python3 script.py
• 올바른 예: /usr/bin/python3 /home/user/script.py

4.2 실행 로그 남기기

크론은 백그라운드에서 돌아가기 때문에 성공 여부를 알기 어렵습니다. 리다이렉션을 사용해 로그를 남기는 습관을 들이세요.

0 3 * * * /home/user/backup.sh >> /home/user/logs/cron.log 2>&1

4.3 권한 확인

실행하려는 스크립트 파일(.sh 등)에 실행 권한(chmod +x)이 있는지 확인해야 합니다.

5. 실전 활용 사례: DB 자동 백업 및 로그 정리

서버 관리자가 가장 흔히 사용하는 자동화 조합입니다.

# 매일 밤 12시에 DB 백업 스크립트 실행
0 0 * * * /home/user/scripts/db_backup.sh

# 매주 일요일 새벽 4시에 7일 지난 임시 파일 삭제
0 4 * * 0 find /tmp -mtime +7 -delete

6. 결론: 자동화로 서버 관리의 자유를 찾으세요

크론탭은 한 번 제대로 설정해 두면 서버가 돌아가는 동안 묵묵히 제 역할을 수행하는 든든한 조수입니다. 반복 업무를 자동화함으로써 여러분은 더 중요한 개발 업무에 집중할 수 있는 시간을 벌게 됩니다.