Jenkins 기반 CI/CD 구축 시도 및 트러블슈팅

개요

이번 프로젝트에서는 Spring Boot 기반 식당 예약 플랫폼을 개발하며 Jenkins를 이용한 CI/CD 자동화에 도전했습니다. 현재는 CI(지속적 통합)까지 성공한 상태이며, CD(지속적 배포)는 구현 중입니다. 이 포스트에서는 현재까지의 구현 내용과 CD 단계에서 마주한 문제점들, 그리고 해결을 위한 트러블슈팅 과정을 정리했습니다.

1. CI/CD 도입 배경

• 수동 배포의 반복적인 작업을 줄이고, 자동화된 빌드/배포 파이프라인 구축

• 푸시(Push)만으로 서버에 새로운 버전이 배포되는 효율적인 운영 환경 구현 목표

• Jenkins를 통해 백엔드 .jar 파일 자동 빌드 + EC2에 자동 배포 계획

2. 현재 진행 상황

✅ CI 완료: Jenkins가 GitHub의 코드 변경을 감지하여 .jar 파일을 자동 빌드

• GitHub에 코드 푸시 시 Jenkins가 자동으로 빌드 수행

• ./gradlew build를 통해 .jar 파일 생성

• Jenkins Job 설정 완료 (GitHub 연동, 빌드 스크립트 구성)

❌ CD 미완료: Jenkins가 빌드된 .jar 파일을 EC2에 자동 배포하는 단계는 아직 구현되지 않음

3. Jenkins

Jenkins는 CI/CD를 위한 오프 소스 도구로, 소프트웨어 개발 생명주기를 자동화

Job/Pipeline 생성

1. New Item에서 Pipeline 타입으로 프로젝트 생성

2. GitHub와 연동하여 푸시 이벤트 감지 및 자동 빌드 설정

3. build.gradle 기반으로 .jar 파일 자동 생성

4. CD를 위한 쉘 스크립트 실행 시도 중

4. 아직 완료되지 않은 CD 단계

현재 미완료 부분

• .jar 파일을 EC2로 전송 (scp)

• EC2에서 기존 프로세스 종료 및 새 .jar 실행 (pkill, nohup)

정리 및 다음 단계

• CI는 성공적으로 구축되어 Jenkins를 통해 자동 빌드 완료

• CD 단계는 SSH 권한 설정, 파일 전송 및 서버 내 실행 흐름에서 트러블 발생

• 현재 문제 해결 중이며, 해결 후 전체 CI/CD 자동화를 마무리할 예정

• 이후 GitHub Actions, CodeDeploy 등 대안 도구도 검토할 계획

회고

자동화는 단순히 “자동으로 빌드된다” 이상의 고민이 필요하다는 것을 체감했습니다. 특히 서버 접근 권한, 스크립트 안정성 등 실제 운영 환경에 필요한 부분들을 경험하며, DevOps 관점에서 시스템을 설계하는 안목을 기를 수 있었습니다.