---

• 기존 Koco 서비스에는 로컬 빌드 → Git pull → 수동 재시작 등 여러 단계를 사람이 직접 수행
• 이 과정에서 실수 가능성이 존재하고, 시간이 오래 걸림 (약 10분 소요)
• CD 파이프라인을 통해 배포 과정을 자동화하면, 클릭 한 번 또는 Git 태그 푸시만으로 3~5분 내 안정적으로 배포 가능
• 또한, 매일 새로운 코테 정답 업데이트, 챗봇, 커뮤니티 기능을 갖춘 본 서비스는 기능 개발을 자주 업데이트할 필요가 있어, 빠르고 신뢰성 있는 자동 배포 체계가 필요하다.

• 서비스는 매일 오전 9시 30분~10시 사이가 최대 트래픽 시간대(동시 접속자 약 150명 예상)
• 정기 배포는 금요일 18시로 설정되어 있지만, 배포 실패 시 복구가 느리면 사용자에게 영향이 갈 수 있음
• CD를 통해 헬스 체크 + 롤백 전략 포함된 Blue-Green 배포를 구성함으로써(추후 카나리 배포 적용), 배포 중에도 서비스 중단 없이 안정적인 전환 가능

• 해설 제공 서비스는 정확성과 신뢰가 핵심인데, 배포 오류나 장애가 빈번하면 사용자 신뢰가 급격히 저하됨
• 자동화된 CD 파이프라인은 테스트, 헬스 체크, 모니터링까지 포함하여 배포 이후 안정성을 확보하고, 이상 징후 발생 시 빠르게 대응 가능함

• 수동 배포는 각 과정별 (3명)담당자가 없으면 실행이 어렵고, 주석/명령 실수로 배포 상태가 달라질 수 있음
• CD는 누가 해도 동일한 결과가 나오는 반복 가능한 배포 환경을 제공하여, 팀워크와 생산성 향상에 기여함

• 현재는 MVP 단계로, 기능 개선과 수정이 빈번하게 이뤄짐
• CD 파이프라인을 통해 작은 변경도 빠르게 반영하고 즉시 배포 가능, 사용자 피드백을 빠르게 반영하는 애자일한 개발/배포 사이클을 구축할 수 있음

기대 효과 요약:

• 배포 프로세스의 표준화 및 문서화로 협업 효율성 향상

• 장기적으로는 운영 자동화 전환 가능성을 고려한 확장성 확보

---

전략	설명	장점	단점
Blue-Green	두 개의 동일한 환경을 번갈아 사용	무중단 배포, 쉬운 롤백	인프라 비용 증가
Canary	점진적 배포로 모니터링 병행	빠른 문제 감지	설정 복잡도 있음
Rolling Update	순차적 교체 배포	자원 절약	롤백 어려움

• 초기: Blue-Green 배포 전략 적용
  • 기존 서비스 버전(Green)을 유지한 상태에서 새로운 버전(Blue)을 별도로 배포
  • 배포 완료 후 검증을 거쳐 트래픽을 새로운 버전으로 전환
  • 오류 발생 시 즉시 기존 버전으로 복귀 가능


• 추후: 카나리 배포 전략 도입 예정
  • 초기에는 일부 사용자에게만 새로운 버전을 노출하여 안정성을 검증
  • 점진적으로 전체 사용자로 트래픽을 확장
  • 장애 발생 시 영향을 최소화하고 빠르게 복구 가능

우리 서비스는 코딩테스트 해설집을 제공하는 플랫폼으로, 매일 오전 9시 30분부터 10시까지가 최대 트래픽 시간대이며, 이때 최대 동시 접속자 수는 약 150명으로 예상됩니다.

사용자는 짧은 시간 안에 문제 풀이 및 해설을 확인하기 때문에, 순간적인 접속 지연이나 서비스 중단은 사용자 경험에 매우 치명적일 수 있습니다.

MVP 초기에는 서비스 신뢰성과 무중단을 최우선으로 해야 하므로, 검증 후 한 번에 전체 트래픽을 전환하는 Blue-Green 배포를 적용합니다. 이를 통해 빠른 롤백이 가능하고, 서비스 초기 품질을 안정적으로 관리할 수 있습니다.

서비스가 점차 안정되고 기능 개선 및 버그 수정이 잦아질 경우,

• 운영 환경의 변경 주기가 짧아지고, 다양한 코드 변경이 누적되면서 단번에 전체 사용자에게 배포할 경우, 예상치 못한 오류나 성능 저하가 전체 사용자에게 즉시 영향을 미칠 위험이 커집니다.
• 특히, 모든 사용자가 동시에 새로운 버전을 사용하게 되면, 소수의 이상 징후만으로도 서비스 전체에 장애가 발생할 수 있어, 복구 작업 부담과 장애 리스크가 급격히 증가합니다.

따라서 일부 사용자 그룹에만 새 버전을 노출하여 안정성을 검증하고, 문제가 없을 때 점진적으로 배포를 확장하는 카나리 배포 전략을 통해 운영 리스크를 최소화할 필요가 있습니다.

또한, 우리 서비스는 매일 새로운 문제와 해설 업데이트가 필요한 구조이기 때문에,

• 콘텐츠 특성상 사용자에게 매일 새로운 문제를 제공해야 하며,
• 이에 따라 문제 데이터, 해설 데이터뿐 아니라 관련 기능(출제 로직, 해설 페이지 렌더링 등) 업데이트도 빈번하게 발생할 가능성이 높습니다.
• 결과적으로 배포 주기가 짧아지고, 배포 빈도 또한 점차 증가할 수밖에 없습니다.

빈번한 배포 환경에서는, 대규모 일괄 배포 방식보다는 소규모 분산 배포를 통한 리스크 통제가 필수적이기 때문에, 카나리 배포 방식이 점진적으로 필요하게 됩니다.

마지막으로, 금요일 오후 18시 정기 배포 이후 비교적 사용자 접속이 적은 야간 시간대를 활용하여 모니터링 및 안정성 확보 시간을 가질 수 있어, 운영 효율성 측면에서도 유리합니다.

---

CD(Continuous Delivery/Deployment) 파이프라인은 Blue-Green 또는 카나리 배포 → QA 및 모니터링 → 최종 확정까지 체계적으로 관리하는 구조로 설계되었습니다.

특히, Blue-Green 배포와 카나리 배포를 적용하든, 수동 배포를 진행하든 관계없이, Slack 알림 발송, 운영 QA 점검, 초기 집중 모니터링 등의 운영 흐름은 동일하게 필수 절차로 포함되어야 합니다. 수동 배포 환경에서도 이러한 운영 프로세스를 엄격히 준수하여 서비스 안정성과 배포 신뢰성을 확보합니다.

• 개발자가 release 태그를 Push하면 CI 파이프라인이 실행됩니다.

• 소스 코드를 빌드하여 배포 가능한 아티팩트(JAR, Docker 이미지 등)를 생성합니다.

• 생성된 아티팩트는 서버 환경에 자동으로 배포됩니다.

• 배포 스크립트 실행 후, 서비스가 기동되고 정상 상태가 확인됩니다.

• /health 엔드포인트를 통한 상태 점검 수행

• 사전 정의된 E2E 테스트 또는 API 테스트가 자동으로 실행됩니다.

• 성공 시: 운영 배포 승인 요청 자동 알림(Slack)

• 실패 시: 배포 중단 및 Slack으로 실패 알림 전송 (운영 배포 차단)

• 승인 완료 후, 기존 Green 버전과 병렬로 새로운 Blue 버전이 배포됩니다.

• 배포 후 Blue 버전에 대해 헬스 체크를 수행합니다.

• Blue 버전의 상태가 정상인 경우, 트래픽을 Green에서 Blue로 전환합니다.

• 전환 후 QA 검증 및 초기 집중 모니터링을 진행합니다.

• 이상 징후 발생 시 즉시 Green 버전으로 롤백됩니다.

• 운영 안정화 이후, Canary 전략으로 전환 계획이 있습니다.

• 초기 5~10% 트래픽만 신규 버전에 전달

• 이상 없을 시 점진적으로 30% → 70% → 100%까지 확장

• 문제 발생 시 해당 버전 롤백

• Health Check 실패 또는 SLA 위반 시, 자동 배포 중단 및 이전 버전으로 롤백

• 배포 후 초기 모니터링 중 문제 감지 시, 긴급 핫픽스 또는 수동 롤백 실행

단계	Blue-Green	카나리 배포
초기 배포 방식	전체 트래픽 한 번에 전환	소수 트래픽부터 점진적 전환
장애 대응	Green으로 전체 복귀	카나리 트래픽만 롤백
리스크 관리	빠른 롤백 가능	점진적 확장으로 리스크 최소화
적용 시점	MVP 배포 이후 적용	서비스 고도화 이후 적용

---

• main → 운영 환경 배포

• CI 도구: GitHub Actions
• 배포 흐름: push to GitHub → GitHub Actions → build → upload to S3 → trigger AWS CodeDeploy → deploy to EC2

1. 개발자가 main 브랜치에 push 또는 PR merge
2. GitHub Actions 워크플로우 실행
   • 빌드 산출물 S3에 업로드
3. S3 업로드 완료 후 AWS CodeDeploy 트리거
   • appspec.yml 기반으로 배포 수행
   • BeforeInstall, AfterInstall, ApplicationStart 스크립트 실행
4. 배포 성공 시 헬스 체크 및 Slack 알림 전송

• .github/workflows/deploy.yml : GitHub Actions 설정 파일
• appspec.yml : CodeDeploy 배포 구성 파일
• scripts/start.sh, scripts/stop.sh : EC2 배포용 스크립트

• GitHub Actions

  • GitHub 저장소와 완벽하게 통합됨
  • 간단한 YAML 기반 설정으로 유지보수 용이
  • Secret 관리 및 브랜치 조건별 워크플로우 구성 용이

• AWS CodeDeploy

  • EC2 인스턴스에 자동 배포 가능
  • AppSpec.yml 기반의 상세한 배포 제어 제공
  • 배포 그룹 기반 롤백 및 헬스체크 설정 가능

---

---

• /health 엔드포인트를 통한 상태 확인

• 테스트 트래픽을 통한 실제 기능 확인

• CloudWatch 또는 Grafana 사용

• Slack 또는 이메일 알림 설정

• 배포 실패 시 Slack으로 자동 알림 전송

• 수동 롤백 유도 또는 자동 재배포 실행

항목	체크 여부	설명
배포 브랜치 확인 (main, develop)	✅	의도한 브랜치인지 확인
빌드 완료 및 에러 없음	✅	CI 통과 여부 확인
환경변수 설정 파일 확인	✅	.env, application-prod.yml 등 존재 여부
대상 서버 정상 작동 여부	✅	SSH 접속, 디스크/메모리 여유 확인
롤백 버전 존재 여부	✅	이전 버전 JAR 또는 Docker 이미지 확인
DB 백업 파일 존재 화인	✅	sql파일 사전 확인
외부 연동 API 상태 확인	✅	kakao ouath 로그인 정상 여부

항목	체크 여부	설명
애플리케이션 기동 여부	✅	systemctl, 프로세스 확인 등
/health 엔드포인트 정상 응답	✅	HTTP 200 응답
주요 기능 정상 동작 여부	✅	회원가입, 문제풀이 등 실제 기능 테스트
에러 로그 발생 여부 확인	✅	로그 파일 확인
리소스 사용량 점검	✅	CPU, 메모리, 디스크 등
모니터링 알람 없음	✅	Slack, CloudWatch 등 알람 확인
롤백 가능 상태 유지	✅	직전 배포 파일 또는 이미지 확인

항목 번호	체크 항목	확인 여부
1	메인 페이지 정상 접속 여부	✅ / ❌
2	로그인/회원가입 정상 작동 여부	✅ / ❌
3	오늘의 문제 리스트 정상 표시 여부	✅ / ❌
4	문제 상세 페이지 정상 조회 여부	✅ / ❌
5	해설 페이지 정상 조회 여부	✅ / ❌
6	주요 버튼(제출, 해설 확인 등) 정상 동작 여부	✅ / ❌
7	에러 페이지(404, 500) 발생 여부	✅ / ❌
8	응답 속도 지연 여부 확인 (API 호출)	✅ / ❌
9	배포 후 신규 에러 로그 유입 여부	✅ / ❌
10	기타 이상 현상 발생 여부	✅ / ❌

---

항목	역할 설명	담당자
배포 승인자	최종 배포 승인	evan.kim
모니터링 담당자	배포 직후 시스템 상태 모니터링	noah.hwang, sophie.kim
롤백 담당자	장애 발생 시 즉시 롤백	evan.kim, noah.hwang
긴급 핫픽스 담당자	빠른 수정 및 재배포 담당	noah.hwang
사용자 문의 대응 담당자 (CS)	사용자 문제 대응	sophie.kim
리포트 정리 담당자	배포/QA 결과 기록 및 공유	sophie.kim
Slack 알림 담당자	배포 완료 등 알림 발송	evan.kim
QA 체크리스트 작성자	운영 QA 체크리스트 작성 및 점검	noah.hwang

---

구분	기존 방식	CD 도입 후
배포 시간	수동 배포, 30분 이상	자동화로 5분 이내
오류 대응	수동 확인 및 복구	자동 알림 및 롤백 가능
배포 빈도	주 1회	하루 1~2회 가능

• 배포 실수 감소

• 빠른 롤백 가능

• 팀 생산성 향상