05. [CI/CD] GitHub Actions 기반 자동 배포 시스템 구축: "내 코드가 잠든 사이 서버에 도착합니다"

안녕하세요! 보배로의 북테크랩입니다.

지난 시간, 우리는 도커(Docker)를 통해 어떤 환경에서도 똑같이 돌아가는 '수익 엔진 박스'를 만들었습니다. 하지만 매번 코드를 수정할 때마다 서버에 직접 접속해서 이미지를 다시 빌드하고 실행하는 건 너무나 번거로운 일입니다. 무엇보다 사람이 직접 명령어를 치다 보면 오타나 설정 실수가 발생하기 마련이죠.

오늘은 우리가 짠 코드를 GitHub에 올리기만 하면, 시스템이 알아서 검증하고 서버까지 안전하게 배포해 주는 CI/CD(지속적 통합/지속적 배포) 시스템을 구축해 보겠습니다.

---

1. CI/CD가 정확히 뭔가요? : "자동 검수원과 자동 배달원"

용어부터 정리해 봅시다. 흔히 붙여서 말하지만, 이 둘은 각기 다른 중요한 역할을 수행합니다.

• CI(지속적 통합): 코드가 합쳐질 때마다 자동으로 테스트하고 검증하는 과정입니다. 쉽게 말해 "이 코드, 안전한가?"를 기계가 대신 판단해 주는 것입니다.
• CD(지속적 배포): 검증된 코드를 실제 서버까지 자동으로 배포하는 과정입니다. 즉, "안전함이 확인되었으니, 자동으로 서버에 올려라"라고 명령하는 것입니다.

이 과정이 구축되어야만 우리는 차트나 코드 앞에 묶여있지 않고, 진정한 '자동화된 자산 증식'의 궤도에 오를 수 있습니다.

---

2. [실습] GitHub Actions 배포 파이프라인 구축

GitHub Actions는 GitHub에서 제공하는 강력한 자동화 도구입니다. 아래 설정 파일을 통해 우리의 봇을 AWS 서버로 자동 배포해 보겠습니다.

1단계: 배포 시나리오 (Workflow) 작성

.github/workflows/deploy.yml 파일을 만들어 아래 내용을 입력합니다.

YAML

 

name: Crypto-Bot CI/CD

on:
  push:
    branches: [ main ] # 메인 브랜치에 코드가 올라오면 실행

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Pytest
        run: |
          pip install -r requirements.txt
          pytest # 💡 배포 전 '자동 테스트' 단계 추가

  deploy:
    needs: test # 💡 테스트가 성공해야만 배포를 시작함
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Build and Push Docker Image
        run: |
          echo "${{ secrets.DOCKER_PASSWORD }}" | docker login -u "${{ secrets.DOCKER_USERNAME }}" --password-stdin
          docker build -t ${{ secrets.DOCKER_USERNAME }}/bobaero-bot:latest .
          docker push ${{ secrets.DOCKER_USERNAME }}/bobaero-bot:latest

      - name: Deploy to AWS EC2
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ubuntu
          key: ${{ secrets.EC2_SSH_KEY }}
          script: |
            cd /home/ubuntu/app
            docker-compose pull
            docker-compose up -d

2단계: 보안을 위한 GitHub Secrets 설정

코드 파일에 직접 서버 주소나 비밀번호를 적는 것은 자살 행위입니다. GitHub 저장소의 [Settings] -> [Secrets and variables] 메뉴에서 아래 항목들을 안전하게 등록해야 합니다.

• DOCKER_USERNAME / DOCKER_PASSWORD: 도커 이미지를 저장할 저장소 계정
• EC2_HOST: 우리 AWS 서버의 IP 주소
• EC2_SSH_KEY: 서버 접속용 .pem 키 내용 전체

---

3. 고수의 한 끗: 배포보다 중요한 '롤백(Rollback)' 전략

💡 배포는 기술이지만, 롤백은 철학입니다.

좋은 시스템은 배포를 잘하는 시스템이 아닙니다. 문제가 생겼을 때 30초 안에 이전 상태로 되돌릴 수 있는 시스템입니다.

금융 시스템에서 '롤백'이 중요한 이유는 명확합니다. 아무리 완벽하게 테스트해도 실거래 환경에서는 변수가 생길 수 있습니다. 이때 당황하지 않고 즉시 이전 버전의 이미지를 실행하여 손실을 막는 구조가 갖춰져야 합니다. (이것이 우리가 v1.0, v1.1 처럼 이미지 버전을 관리해야 하는 이유입니다.)

---

📖 실제 장애 사고 사례: "테스트 없는 배포가 부른 대참사"

과거 한 개발자가 새벽 2시에 잠결에 코드를 수정하고 서버에서 직접 배포를 실행했습니다. 하지만 오타로 인해 [Stop-Loss(손절)] 로직이 주석 처리된 채 배포되었고, 그날 밤 발생한 급락장에서 봇은 손절 없이 끝까지 버티다 계좌가 청산되고 말았습니다.

실제 자동매매 시스템에서 가장 위험한 것은 ‘실행은 되지만 잘못 동작하는 코드’입니다. 만약 위에서 구현한 CI 파이프라인이 있었다면? 배포 전 단계에서 실행된 자동 테스트가 "돈을 잃지 않게 동작하는지"를 검증했을 것이고, "손절 로직 오작동"을 감지해 배포 자체를 중단시켰을 것입니다.

---

🛡️ CI/CD 보안 & 운영 체크리스트

• [ ] CI 테스트 강제: pytest 등 자동 테스트가 실패하면 배포가 절대 안 되게 설정했는가?
• [ ] Secrets 사용: 모든 민감 정보는 GitHub Secrets에 암호화하여 저장했는가?
• [ ] 롤백 프로세스: 문제가 생겼을 때 즉시 이전 버전(Tag)으로 되돌릴 준비가 되었는가?
• [ ] 배포 알림: 배포 성공/실패 여부를 텔레그램으로 즉시 받아보게 설정했는가? (14강 연동)

---

📝 보배로의 통찰: "배포는 기술이 아니라 철학이다"

"내가 직접 하면 되지"라는 생각은 시스템의 신뢰성을 무너뜨립니다. 코드가 완성되는 순간부터 서버에 안착하기까지의 모든 과정을 자동화하고 감시하는 것, 그것이 바로 DevSecOps의 완성입니다.

다음 시간에는 새 전략을 가장 안전하게 실전에 적용하는 기술, [06. Canary Deploy] 새 전략을 전체 자산에 바로 적용하면 안 되는 이유에 대해 알아보겠습니다.

---

보배로의 북테크랩(Booktech-lab) 공학적으로 투자하고, 데이터로 증명하며, 시스템으로 승리합니다.