배포 브랜치와 디버깅 브랜치 따로 만들기

 

로컬에서 npm run build를 했을 때는 아무 문제가 없었는데, GitHub에 push를 하면 빌드 오류가 발생하는 문제가 있었다. 이 문제 때문에 배포 브랜치에 여러 번 커밋을 푸시하게 되었고, 그 결과 서버 쪽에서 오류가 발생했다. 이후 백엔드 개발자로부터 "빌드 에러를 미리 잡는 방법을 고민해보는 게 어떻겠느냐"는 피드백을 받았다.

하지만 당시에는 이렇게 생각했다.

→ "로컬에서 build가 잘 되는데, 뭘 더 어떻게 하라는 거지?"

그럼에도 불구하고 개선 방법을 찾아보기로 했다.

---

🌱 해결 방법을 찾기까지

• build 에러가 GitHub Actions에서만 발생하는 것이라면, GitHub Actions에서만 실행되는 환경 차이를 먼저 의심해볼 수 있다.
• 따라서 디버깅용 빌드 전용 브랜치를 따로 만들어, 배포와 상관없이 GitHub Actions에서 빌드만 테스트할 수 있도록 해보기로 했다.
• 하지만 .yml 파일이 익숙하지 않았기 때문에 우선 문법을 공부하고, 백엔드 개발자와 직접 논의하면서 진행했다.

---

🔧 디버깅용 GitHub Actions 브랜치 만들기

회사 코드를 공유할 수 없어 예시 코드로 설명한다.

원래 사용 중이던 GitHub Actions (배포 포함)

name: client
on:
  push:
    branches:
      - reference
jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout source code.
        uses: actions/checkout@v2

      - name: Install dependencies
        run: npm install
        working-directory: ./my-agora-states-client

      - name: Build
        run: npm run build
        working-directory: ./my-agora-states-client

      - name: SHOW AWS CLI VERSION
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws --version

      - name: Sync Bucket
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws s3 sync \
            --region ap-northeast-2 \
            build s3://fe-43-pikadev1771-s3 \
            --delete
        working-directory: ./my-agora-states-client

---

디버깅 전용 브랜치 설정 (배포 로직 제거)

디버깅 전용 브랜치를 만들어 아래처럼 설정한다.

name: client
on:
  push:
    branches:
      - debug  # 디버깅용 브랜치
jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout source code.
        uses: actions/checkout@v2

      - name: Install dependencies
        run: npm install
        working-directory: ./my-agora-states-client

      - name: Build
        run: npm run build
        working-directory: ./my-agora-states-client

      - name: SHOW AWS CLI VERSION
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws --version

→ 핵심은 마지막 Sync Bucket 단계, 즉 배포 명령어를 제거하는 것이다.

이렇게 하면 디버깅 브랜치에서는 빌드만 수행되고 배포는 되지 않는다. 빌드 에러 여부를 안전하게 확인할 수 있다.

---

🔍 배포 로직을 확인하는 방법

배포 코드가 어디에 있는지 파악하려면 아래 4가지를 확인하면 된다.

1. 백엔드 개발자와 직접 논의
   • 현재 프로젝트에서 어떤 방식으로 배포를 하고 있는지 확인한다.
2. 어떤 배포 도구를 사용하는지 확인
   • AWS, SCP, Firebase Deploy, Vercel, gh-pages 등 도구 이름이 run: 안에 있거나 명령어로 작성되어 있을 수 있다.
3. env:에 외부 서비스 관련 키가 있는지 확인
   • 예: AWS_ACCESS_KEY_ID, SSH_KEY, FIREBASE_TOKEN 등
4. run: 명령어가 외부에 뭔가를 "전송"하고 있는지 확인
   • 예: aws s3 sync, scp, firebase deploy, curl 등

---

✅ 정리

• 로컬에서는 build가 잘 되지만, CI/CD 환경(GitHub Actions)에서는 문제가 발생할 수 있다.
• 이럴 때는 디버깅 전용 GitHub Actions 브랜치를 만들어 배포 없이 빌드만 수행해보는 것이 유용하다.
• .yml 파일이 익숙하지 않아도, 핵심은 복잡하지 않다.
  • 어떤 브랜치에서 실행할지 설정하고
  • 배포 명령어를 제거하면 끝이다.
• 앞으로도 배포 전 오류를 미리 발견하고 서버 상태에 영향을 주지 않기 위해 이런 디버깅 워크플로우를 계속 사용할 예정이다.