[Devops] NCP Container Registry를 활용한 Frontend CI/CD 파이프라인 최적화

[flowersayo]

🛠 개발 기능(작업 내용)

🧭 Summary

NCP Container Registry를 활용한 Frontend CI/CD 파이프라인 최적화 및 하이브리드 배포 전략 구현

🔗 Linked Issue

• [Devops] NCLOUD 서버 생성 및 CD 워크플로우(GitHub Actions ↔ SSH ↔ Docker Compose)연동 #53

🛠 개발 기능(작업 내용)

1. Frontend NCP Container Registry 도입

• 문제: 프론트엔드 서버 스펙이 작아 Docker 이미지 빌드에 1시간 이상 소요
• 해결: CI 단계에서 이미지를 빌드하여 NCP Container Registry에 푸시, CD는 pre-built 이미지를 pull하여 배포

2. CI/CD 워크플로우 분리 및 최적화

• dev → main PR (CI): 이미지 빌드 + NCP Registry 푸시 + 검증
• main merge (CD): Registry에서 검증된 이미지 pull + 컨테이너 실행
• feature → dev PR (CI): Docker 빌드 테스트만 수행 (푸시 안 함)
• CI: PR의 target 브랜치(base_ref)와 비교하도록 변경
  • feature->dev PR: dev 브랜치와 비교
  • dev->main PR: main 브랜치와 비교
  • 변경된 서비스만 정확하게 감지하여 CI 실행

3. 하이브리드 배포 전략

• Frontend: Registry 기반 배포 (빌드 시간 최소화)
• Backend: 서버 직접 빌드 방식 유지 (설정 단순화)

4. CI/CD 문서화

• CICD_GUIDE.md: 전체 파이프라인 가이드 작성
• CICD_DIAGRAM.md: 9가지 머메이드 다이어그램으로 워크플로우 시각화

5.기타

• SSH 키를 공통 키로 통합하고 문서 업데이트

🧩 주요 고민과 해결 방법

1. 빌드 시간 최적화

고민: 소형 프론트엔드 서버에서 1시간 빌드 → 배포 병목
해결:

• GitHub Actions의 고성능 환경에서 이미지 빌드
• Registry의 빌드 캐시 활용 (최초 실행 후 캐시 활성화)
• 서버는 이미지만 pull하여 배포 시간 대폭 단축

2. CI와 CD의 책임 분리

고민: CD에서 빌드하면 배포 시간이 길고, 빌드 실패 시 롤백 복잡
해결:

• CI: 빌드 + 테스트 + 이미지 푸시 (검증 완료)
• CD: 검증된 이미지만 배포 (빠르고 안전)
• 이미지 태그로 commit SHA 사용하여 추적성 확보

3. 하이브리드 전략 설계

고민: 모든 서비스를 Registry로 전환해야 하나?
해결:

• Frontend만 Registry 사용 (빌드 시간이 긴 서비스)
• Backend는 서버 빌드 유지 (간단한 구조, 레지스트리 비용 절감)
• 서비스 특성에 맞는 최적의 방식 선택

4. 캐시 전략

고민: Registry 캐시가 없는 첫 실행은 느림
해결 방안 (향후 적용 고려):

cache-from: |
  type=registry,ref=${{ secrets.NCP_REGISTRY_URL }}/beastcamp-frontend:buildcache
  type=gha
cache-to: |
  type=registry,ref=${{ secrets.NCP_REGISTRY_URL }}/beastcamp-frontend:buildcache,mode=max
  type=gha,mode=max

• Registry 캐시 + GitHub Actions 캐시 병행 사용

🔍 리뷰 포인트

1. CI 워크플로우 (.github/workflows/ci.yml)

• Lines 72-96: dev→main PR에서만 NCP Registry 로그인 및 푸시
• Lines 98-111: feature→dev PR에서는 빌드 테스트만 수행
• 조건문 검증: github.base_ref == 'main' && github.event_name == 'pull_request'

2. CD 워크플로우 (.github/workflows/cd.yml)

• Lines 39-81: Frontend 배포 로직 단순화 (빌드 제거, pull & run만)
• 환경변수 전달: Registry 인증 정보 및 이미지 태그
• 이미지 태그: ${{ github.sha }} 사용하여 커밋 추적

3. 문서화

• CICD_GUIDE.md: 설정 가이드, 시나리오, 트러블슈팅
• CICD_DIAGRAM.md: 9가지 다이어그램 (워크플로우, 시퀀스, 배포 전략 비교 등)

4. GitHub Secrets 추가 필요

• NCP_REGISTRY_URL: NCP Container Registry URL
• NCP_REGISTRY_USERNAME: Registry 사용자명
• NCP_REGISTRY_PASSWORD: Registry 비밀번호 또는 Access Token

📊 성능 개선 효과

항목	기존 (서버 빌드)	개선 (Registry)	효과
Frontend 배포 시간	~60분	~3분 (pull + run)	20배 개선
CD 워크플로우	빌드 + 배포	배포만	단순화
안정성	서버 빌드 실패 위험	CI 검증 완료	향상
서버 리소스	고부하	최소 부하	절감

⚠️ 배포 전 체크리스트

• GitHub Secrets 3개 추가 (NCP_REGISTRY_URL, NCP_REGISTRY_USERNAME, NCP_REGISTRY_PASSWORD)
• NCP Console에서 Container Registry 생성 및 Access Token 발급
• 프론트엔드 서버에서 Registry 로그인 테스트
• dev → main PR 생성하여 이미지 빌드/푸시 확인
• main merge 후 CD 워크플로우 정상 동작 확인

📝 후속 작업 (Optional)

1. 캐시 최적화: GitHub Actions 캐시와 Registry 캐시 병행 사용
2. 모니터링: Registry 이미지 용량 및 트래픽 모니터링
3. 비용 최적화: 오래된 이미지 자동 정리 정책 설정
4. Backend Registry 고려: Backend 빌드 시간이 증가하면 Registry 도입 검토

---

📋 Code Review Priority Guideline

• 🚨 P1: Request Change
  • 필수 반영: 꼭 반영해주시고, 적극적으로 고려해주세요 (수용 혹은 토론).
• 💬 P2: Comment
  • 권장 반영: 웬만하면 반영해주세요.
• 👍 P3: Approve
  • 선택 반영: 반영해도 좋고 넘어가도 좋습니다. 그냥 사소한 의견입니다.

[shininghyunho]

LGTM

[viixix]

bb