CI/CD 도입 기능 설계 문서

kkrap 프로젝트에서 EC2에 docker-compose와 docker를 사용하여 elasticsearch, postgreSQL, spring boot, redis, kafka, react/vite를 띄우고 있다. 각 프론트엔드 백엔드에서 수동으로 배포를 해서 쓰고 있었는데 자동화를 위해 CI/CD를 도입하는 과정의 문서이다.

 

개요

무엇을 위한 기능인가?

Kkrap 프로젝트는 EC2 환경에서 docker-compose를 기반으로 Elasticsearch, PostgreSQL, Spring Boot, Redis, Kafka, React/Vite 등 여러 서비스를 동시에 운영하고 있다. 지금까지는 프론트엔드와 백엔드를 각각 수동으로 빌드 및 배포했기 때문에, 배포 과정에서 많은 시간이 소요되고 환경별 일관성을 유지하기 어려웠다.

CI/CD 파이프라인을 도입함으로써 코드가 변경될 때마다 자동으로 빌드 → 테스트 → 보안 검증 → 도커 이미지 생성 → 서버 배포까지 이어지도록 하여 개발 효율성을 높이고, 운영 환경을 안정적으로 관리할 수 있다.

 

목적 및 배경

왜 이 기능이 필요해졌는가?

현재 수동 배포 방식에서는 다음과 같은 문제가 있었다:

1. 배포 시간 지연 – 매번 EC2에 SSH로 접속해 수동으로 컨테이너를 내리고 다시 빌드해야 했음
2. 사람 실수 발생 가능성 – 환경 변수 누락 때문에 배포를 했음에도 안되는 경우가 발생 또한 버전 불일치로 어디까지 된 기능인지 알 수가 없어 문제가 발생했음
3. 확장성 부족 – 서비스 컴포넌트가 늘어나면서 수동 배포 방식으로는 유지보수가 어려워짐

따라서 CI/CD 도입으로 개발–테스트–운영 간 파이프라인을 자동화하고, 서비스 변경 사항을 안전하고 빠르게 사용자에게 제공하는 것이 필요해졌다.

 

 

CI/CD 방법론

CI/CD를 찾아보니 Github Actions나 Jenkins를 많이 사용하였다. 그러면 이 2가지 중 선택을 해야되는데

• Github Actions
  • Github 저장소와 높은 연동성으로 별도 서버 관리가 불필요하고 설정이 간단
  • 소규모 단일 서비스 배포 적합
• Jenkins
  • EC2 내부에서 동작하며 PostgreSQL, Redis, Kafka 여러 컨테이너 리소스 직접 연결 가능
  • 단순 빌드 배포 말고도 보안 스캔, DB 마이그레이션 까지 유연하게 구성 가능
  • 프론트엔드와 백엔드, 인프라를 하나의 워크 플로우로 제어 가능
  • 빌드가 잦아질 경우 Actions 러너 비용 보다 EC2 내 Jenkins 에이전트 활용 유리

2가지를 봤을 때 Actions가 좀 더 적합할 수는 있지만 EC2에서 진행을 많이 하는 것과 kkrap 기능에서 복잡한 기능들이 많기에 나중에 로드 밸런싱까지 추가한다고 고려하면 Jenkins가 더욱 적합하다고 판단하였기에 Jenkins로 CI/CD를 구축