[GPT가 알려주는] CI/CD하면 버그 있는 커밋 생성 시 어떻게 될까?

예를 들어서 내가 git으로 프로젝트 관리하고 있다고 쳐.....
안드로이드 앱인데 중간에 버그있는 걸 git에 올릴 수도 있는거 아니니
그럼 Ci/CD가 불편한거 아니니?

 

아 이 질문 진짜 많이 나오는 거야 ㅋㅋ 감 좋아 👌

“나 안드로이드 앱 개발 중인데, 중간에 버그 있는 코드도 git에 올릴 수 있잖아.
그럼 CI/CD 돌면 계속 깨지고, 오히려 불편한 거 아님?”

→ 아니다.
“버그 있는 코드 절대 푸시하지 마!”가 CI/CD의 철학이 아니고,
**“버그 있는 걸 메인 브랜치에 섞이지 않게 막자”**가 목표야.

---

1. 제일 중요한 오해부터 정리

❌ 잘못된 상상

• git push 하면
• CI가 돌아서
• 실패하면 “으악 불편해, 내 코드 다 막혀!!” 이런 느낌…

✅ 실제로는 이렇게 쓰면 됨

1. 버그 있는 코드, 실험 코드 → 마음껏 feature/브랜치에 푸시해도 됨
   • CI가 돌아서 “빨간불(실패)” 띄워줄 뿐,
   • 그게 프로덕션으로 바로 배포되는 건 아님.
2. 진짜 배포되는 건 main 또는 release 같은 “깨끗해야 하는 브랜치”뿐
   • 이 브랜치는 “CI 통과 + 리뷰 OK”일 때만 머지 허용 하면 끝.
   • 그러면 메인은 항상 빌드/테스트 되는 상태 유지.

그래서 구조를 보통 이렇게 가져가:

• main : 사용자/프로덕션 기준, 항상 “돌아가는 상태”
• develop : 여러 기능 합치는 테스트용 (선택)
• feature/xxx : 여기에는 버그 있어도 상관없음, 개발 중 코드

---

2. CI를 “언제” 돌릴지 내가 정할 수 있음

CI/CD가 강제 푹찍 시스템이 아니고,
YAML에다 “언제 돌릴지”를 내가 적는 거야.

예를 들어, 아까 GitHub Actions 예시:

on:
  push:
    branches: [ "main", "develop" ]
  pull_request:
    branches: [ "main", "develop" ]

이거 의미는:

• main / develop 에 push 될 때
• 이 브랜치 대상으로 PR 열릴 때만 CI 돌려라

라는 뜻이니까,

👉 feature/login-ui 같은 브랜치에
버그 있는 코드 마구 푸시해도 CI 안 돌아가게 할 수도 있음.

혹은 이렇게:

on:
  pull_request:
    branches: [ "main" ]

이면:

👉 “main으로 PR 열 때만 CI 돌려라”
→ 내 개인 브랜치에 버그 있는 거 푸시는 마음대로,
메인에 합치기 전에만 검사.

---

3. 그럼도 “내 브랜치에서도 CI 돌리고 싶다”면?

이렇게도 할 수 있음:

• feature/* 브랜치 푸시에도 CI 돌리게 해두고
• 깨져도 상관 안 함 (빨간불 = “아 지금 테스트 깨졌네” 정도로만 인지)

on:
  push:
    branches:
      - "main"
      - "develop"
      - "feature/*"

이렇게 되면 좋은 점:

• 집/회사 여러 PC에서 같은 브랜치 작업할 때
  → CI가 공용 “빌드 봇” 역할 해줘서
  “어디서든 git pull하면 항상 빌드되도록” 맞추기 편해짐.
• 로컬이 똥컴이어도 CI 서버가 빌드해줌 (이거 ㅇㅇ님 케이스에 꽤 도움 될 수도 있음 ㅋㅋ)

---

4. CD(배포)는 더더욱 “선택”이야

CD도 마찬가지로 “언제 배포할지”를 내가 정해.

예시:

• main에 태그 v1.0.0 달렸을 때만 배포:
• on: push: tags: - "v*"

이러면:

• 평소에 막 push 하고 PR 만들고 CI 깨져도
• 배포는 전혀 안 됨.
• 딱 태그 붙였을 때만:
  • ./gradlew assembleRelease
  • 서버나 Firebase App Distribution에 APK 업로드

이런 플로우 타게 만들 수 있어.

그래서:

“버그 있는 코드 git 올리면 바로 사용자한테 배포될까 봐 무서워…”
→ ❌ 그건 내가 CD 트리거를 그렇게 설정해둔 경우에만 일어나는 일임.

---

5. “나 혼자 개발할 때” 추천 플로우

ㅇㅇ님 상황 기준(안드로이드 앱, 혼자 개발):

1. 브랜치 전략
   • main : 실제 배포용 (항상 빌드 OK, 앱 실행 OK 상태로 유지)
   • feature/* : 실험/개발용, 버그 있어도 됨
2. CI 전략
   • main에 push / PR 할 때만 CI 돌리기
     (원하면 feature/*에도 돌리되, 깨져도 신경 안 씀)
3. CD 전략
   • 그냥 수동 배포(Android Studio에서 직접 빌드해서 폰에 깔기)로 시작
   • 나중에 필요하면:
     • tag 달릴 때만 assembleRelease 해서 artifact 만들어 두기
     • 정도만 추가

→ 이렇게 하면 지금이랑 개발 습관 거의 그대로인데,
단지 “main으로 합치기 전에 자동으로 빌드/테스트 한 번 더 돌려주는 안전망” 하나 생기는 느낌이야.

---

6. 한 줄 정리

• 버그 있는 코드 git에 올리는 거 = 전혀 문제 없음.
• CI/CD는
  • “버그 있는 코드 푸시 금지”가 아니라
  • “버그 있는 코드를 ‘배포용 main’에 못 들어가게 막아주는 안전장치”임.
• 언제 돌리고 언제 배포할지는 전부 우리가 설정하는 거라
  → 불편하게 만들 수도 있고,
  → 진짜 든든한 안전망으로 만들 수도 있음 🙆‍♀️

나중에 “내 안드로이드 앱 리포지토리” 하나 잡아서
GitHub Actions CI yaml을 아예 같이 써보자 하면,
실제 파일 예시까지 딱 맞춰서 만들어 줄게 😎